[Gelöst] be.IP - DynDNS

[_tms]

Hallo *,

nach stundenlangen Testen, Logs prüfen, usw. komme ich leider nicht weiter. Vielleicht hat hier wer eine Idee.

Mit der neuen FW 10.2.5.100 soll ja jetzt auch DynDNS mit SSL gehen.

Ich kriege es zwar zum Laufen, allerdings nur über Umwege und verstehe dabei das Verhalten der be.IP nicht.

Mit einer FB geht es ganz einfach mit:
Um die IP bei einem dyndns-kompatiblen Service anzumelden reicht der Aufruf:
http(s)://server/cgi-bin/register.cgi?domain=<domain>&username=<username>&password=<pass>&myip=<ipaddr>
Der Aufruf funktioniert gleichermaßen mit und ohne SSL.

Die be.IP benötigt OHNE SSL keinerlei Parameter im Aufrufpfad, es reicht also die Angabe des Skripts. Das klappt prima.
Mit SSL fehlt bei dieser Variante dagegen der Benutzer und das Kennwort (soweit wir das im Serverlog nachvollziehen können, wo unserer eigener dyndns-kompatible Service läuft.
Warum nur?
Mit SSL klappt es nur, wenn man im Aufrufpfad der Skriptangabe den Zusatz "?username=[name]&password=[passwort]&" mitgibt, wobei das "&" am Ende wichtig ist.
Das ist zwar insgesamt besser als die Daten im Klartext (http) zu schicken, im Router sind sie aber unmaskiert

Hat irgendwer eine Idee, was de be.IP da treibt?
Warum das unterschiedliche Verhalten?
Und weiß vielleicht jemand, was es mit den Protokollen DynDNS und Custom-DynDNS auf sich hat? Bei allen unseren Tests verhalten sich beide gleich. Die Parameter hätte ich bei "Custom" ja noch verstanden. Dann wäre aber immer noch die Frage, ob die "Echtangaben" im Aufrufpfad gegen Variablen getauscht werden können, um keine Kennworte im Klartext zu haben. "<username>" klappt schon mal nicht.

Merci

 

[stoney]

Kann zwar nicht helfen, allerdings wäre es sicherlich hilfreich, die Logs (persönliches unkenntlich, aber noch nachvollziehbar zu machen) direkt in #1 mit anzugeben.

 

[_tms]

Sorry: 'Sktipts' war schlichtweg ein Vertipper (ist korrigiert) und meint das Skript, dass auf dem Server die IP-Registrierung durchführt. Typische Namen sind "/register.cgi, /nic/update, usw.)

@stoney

Normalerweise sehe ich das auch so. In diesem Fall bringen die aber nicht viel, weil:
a) auf be.IP Seite zum Dnynds-Update nur Minimalangaben geloggt werden. Es endet nur mit "Auth-Fehler".
b) das Ganze ja per https passiert, so dass man mit dem Netzmonitor nichts lesbares erkennt. Man sieht auf der Serverseite nur, dass der Apache keinen User bekommt, worauf der Vorgang mit "Host xxxx username nicht gesetzt. exit mit badauth" endet.

Es wäre vielleicht schon hilfreich jemanden zu finden, der erfolgreich dyndns-Updates - nachweislich MIT SSL - geschafft hat (ohne den oben angegebenen Trick). Wie gesagt: Das Bintec-Log enthält hierzu keinerlei Angaben.

 

[avus]

Ich habe Two-DNS in der be.ip plus als neuen DNS-Provider angelegt und nutze die SSL-Anmeldung mit den Parametern im Bild. Der Unterschied zwischen http und https wird hier nur mittels Port 80 oder 443 eingestellt, Server und Aktualisierungspfad sind identisch.



//edit by stoney: Bild geschrumpft

 

[_tms]

Hi,

Danke für den Hinweis.
Nach meinen bisherigen Tests verhält es sich mit dem Port anders:
- http: es wird der Port verwendet, der beim Provider eingestellt wurde
- https: kommt nur zum Tragen, wenn beim Provider "unterstützt SSL" UND in den Host-Definition auch SSL aktiviert wurde. Und dann wird immer 443 verwendet unabhängig davon, was beim Provider angegeben wurde.

Daher die Frage an dich:
Hast du beim Host HTTPS/SSL aktiviert?

### Zusammenführung Doppelpost by stoney ###

Update:

Ich konnte die Abfrage von der be.IP - zumindest mit http - teilweise (also den Anfang davon) tracen.
Die Auth-Daten werden bei http nicht - wie vorher vermutet - in der URI mitgegeben werden, sondern per Basic Authentication (also Base64 codiert).

Parameter können zusätzlich beim Scriptaufruf gesetzt werden, die per URL übergeben werden.
Beispiele:

ohne Paramter:
GET /register.php?system=custom&hostname=testhost&myip=xxx.xxx.xxx.xxx&HTTP/1.0..Authorization: Basic YmVudXR6ZXI6a2VubndvcnQ=..User-Agent: ddnsd-1.1 BOSS..Host: 192.168.xxx.xxx....

mit Parameter:
GET /register.php?username="test"&?system=custom&hostname=testhost&myip=xxx.xxx.xxx.xxx& HTTP/1.0..Authorization: Basic YmVudXR6ZXI6a2VubndvcnQ=..User-Agent: ddnsd-1.1 BOSS..Host: 192.168.xxx.xxxx....

wobei die Benutzerdaten im Base64-Teil (YmVudXR6ZXI6a2VubndvcnQ=) stecken: In diesem Fall entspricht das "benutzer:kennwort"

Bei SSL sind wir noch nicht weiter, da wir da erstmal einen vollständigen Trace brauchen.

PS:
Einige Unterschiede zwischen "dyndns" und "custom-dyndns" habe ich schon gefunden:
dnydns:
- system=dyndns
- Es sind DNS Anfragen nach "members.dyndns.org" zu beobachten
- In der URI wird zusätzlich &wildcard=OFF mitgegeben

custom-dyndns:
- system=custom
- Keine DNS-Abfragen nach "members.dyndns.org" zu beobachten
- Kein "&wildcard=OFF"

 

[avus]

Bei Two-DNS wird die SSL-Anmeldung nur in den Provider-Parametern hinterlegt, nicht in den persönlichen Anmeldedaten.




Beim standardmäßig vorhandenen Provider no-ip wird SSL in den Anmeldedaten gewählt.



//edit by stoney: Bilder geschrumpft

 

[_tms]

Sorry, verstehe ich nicht ganz.

Bei der Provider-Definition muss doch "Unterstützt SSL" aktiviert sein, damit bei der Hostdefinition überhaupt HTTPS/SSL aktiviert werden kann.

Wir hatten es in der Vergangenheit (vor 10.2.5.100) schon mal damit probiert, einfach 443 als Port einzutragen. Das hat aber nicht zu einer https-Verbindung geführt.



### Zusammenführung Doppelpost by stoney ###

Update 2:

Wir haben es geschafft die https Anfrage zu tracen.
Die Basic-Auth wird auch da sauber übergeben.
Es sieht momentan danach aus, dass der Apache diese nicht richtig interpretiert und entsprechend nicht die ENV_Variable füllt, die später im Script verwendet wird.

### Zusammenführung Doppelpost by stoney ###

Juhu, es funktioniert.

Am Ende war es ein fehlender Rewrite auf dem Apache.

 

[avus]

Sorry, verstehe ich nicht ganz.

Bei der Provider-Definition muss doch "Unterstützt SSL" aktiviert sein, damit bei der Hostdefinition überhaupt HTTPS/SSL aktiviert werden kann.

.

Du hast selbstverständlich recht, in der Provider-Konfig muss die Unterstützung für SSL markiert sein, erst dann ist diese Option bei der Host-Anmeldung wählbar.