Hilfe bei ipv6 und DynDNS
-
@woodym said in Hilfe bei ipv6 und DynDNS:
vielen dank für deine Analyse und deiner konstruktiver kritik.
Sehr gern
@woodym said in Hilfe bei ipv6 und DynDNS:
Die Beschreibungen sind ja gerade noch am werden was ja der Grund für meine bitte um hilfe war ;-)
Verständlich :)
@woodym said in Hilfe bei ipv6 und DynDNS:
Ob ich die Parameter so einfach ändern kann ist fraglich, da schon einige die bisherigen verwenden (muß ich aber in den logfiles nochmal genau prüfen was genommen wird...
Nutzen "viele" das wirklich mit IPv6? Wenn nicht änders einfach und dokumentiere es entsprechend. Klare Cuts sind sinnvoller und im frühen Stadium sinnvoller als ewig alten Kram mitzuschleppen. Als Übergang kann man sicher beides etablieren und testen - wenn es geht, würde ich einfach eine kurze Infomail an die vorhandenen Accounts senden mit der Bitte die Konfiguration zu prüfen/ändern und gut. Genauso auch wegen der "automagischen" Defaults. Da würde ich definitiv zu raten, das abzuklemmen und keine Parameter einfach automatisch zu erraten - schon allein weil man diese dann versuchen könnte zu spoofen über die übergebenen Server-Header.
Was mich noch interessieren würde wie du bei pfSense jetzt den Update machst? Wie übermittelst du die ipv6? Über custom (v6) und %IP% ?
Ah natürlich. Das Wichtige bei der pfSense ist das korrekte Interface (muss v6 fähig sein) und custom(v6) Auswahl. Wählt man versehentlich nur custom aus, wird mit %IP% die IP4 übergeben, bei custom (v6) wird immer versucht, die IP6 Adresse des angegebenen Interfaces auszulesen (kann man auch als Fehler im Log nachlesen). Ich muss noch untersuchen, ob man auch in einem Aufwasch beides übergeben kann, einzeln tut es auf jeden Fall schonmal brauchbar, auch wenn der Return noch nicht sauber aus/eingelesen wird wegen Multiline. Das wollte ich mir allerdings auch noch ansehen. Evtl. kann man hier einen Parameter mitgeben (ähnlich dem JSON Parameter) der die OK/Feedback Ausgabe dann etwas informationsärmer ausgibt :)
-
Nutzen "viele" das wirklich mit IPv6? Wenn nicht änders einfach und dokumentiere es entsprechend....
Nein, nicht IPV6. Aber was viel genutzt wird das automatische erkennen der IP :-( . Die früheren DynDNS Client haben irgend wo die externe IP angefragt und dann nur bei änderungen die an DynDNS übertragen. Solche Router wie pfSense machen das etwas inteligenter, sie wissen aufgrund der etablierten Verbindung zumindest den Zeitpunkt wann die IP sich ändert und können dann aktiv werden fals Handlungsbedraf besteht. Das ermittel der IP übernimmt ja srvhome selber womit ein intelligenter Client nicht mehr nötig ist. Einfache Systeme die hinter der FW sitzen können damit eine IP mitteilen ohne sie kennen zu müssen. Genau das wird gerne genutzt.
Das sind eigentlich zwei Forderungen die sich wiedersprechen. Um dem gerecht zu werden denke ich über einen weiteren Update-Aufruf nach... der eine mit und der andere ohne automatismus.Ah natürlich. Das Wichtige bei der pfSense ist das korrekte Interface (muss v6 fähig sein) und custom(v6) Auswahl. Wählt man versehentlich nur custom aus, wird mit %IP% die IP4 übergeben, bei custom (v6) wird immer versucht, die IP6 Adresse des angegebenen Interfaces auszulesen (kann man auch als Fehler im Log nachlesen). Ich muss noch untersuchen, ob man auch in einem Aufwasch beides übergeben kann, einzeln tut es auf jeden Fall schonmal brauchbar, auch wenn der Return noch nicht sauber aus/eingelesen wird wegen Multiline. Das wollte ich mir allerdings auch noch ansehen. Evtl. kann man hier einen Parameter mitgeben (ähnlich dem JSON Parameter) der die OK/Feedback Ausgabe dann etwas informationsärmer ausgibt :)
Das ist eine gute Idee ein Parameter für eine einfach Antwort ;-).
Übrigens sollte dein Update so (custom (v6)) mit IPV4 sofort funktionieren. Du übermittelst per Variable %IP% deine IPV6. Die IPV4 würde ermittelt werden und muß nicht explizit angegeben werden ;-).Das mit dem automatischen ermitteln der IP hatte bisher bei einem Nutzer nicht funktioniert weil dessen Aufrufe über ein Zwangsproxy gesendet wurden. Da wiederum ist auch keine Verbindung direkt zu seinem Router möglich.
-
@woodym said in Hilfe bei ipv6 und DynDNS:
haben irgend wo die externe IP angefragt
meistens: http://checkip.dyndns.org
Genau das wird gerne genutzt.
Kein Grund das nicht zu unterstützen, aber dann sollte man das ggf. als Parameter wie "ip=auto" oder als extra Parameter "...&discover=auto" oder ähnliches anhängen. IMHO sollte deine Default URL nicht standardmäßig "magic" machen ;)
Um dem gerecht zu werden denke ich über einen weiteren Update-Aufruf nach... der eine mit und der andere ohne automatismus.
Oder zwei URLs. Aber mit Parametern wäre es IMHO sinnvoller. Weniger Pflegeaufwand und niemand sagt, dass man keine neuen Features über Trigger/Parameter hinzufügen kann :) So wie bspw. der Output in JSON. Hier noch ein "output=minimal" (als Beispiel) für die pfSense als Feedback mit "OK <bla>" ist ja ein anderer Punkt. Stört keine vorhandene Konfiguration. Oder umgekehrt: ein "minimum" als Standard ausrollen -> KISS. Und alles andere als schweizer Messer dranbauen mit Parametern. Das wäre zumindest die Design-Philosophie die ich verfolgen würde :)
Du übermittelst per Variable %IP% deine IPV6. Die IPV4 würde ermittelt werden und muß nicht explizit angegeben werden ;-).
Jein. Taucht sie nicht :) Nicht wenn dein Service komplett wäre, was er nicht ist. Deine Seite ist nämlich nicht Dual Stack fähig. Sprich ich kann mein DynPrefix nur via v4 einliefern. Wenn ich aber DSlite habe, will ich gerade das ja nicht ;) Somit sollte deine Adresse (www.srvhome.de) dringend DualStack liefern und per v6 erreichbar sein.
Wenn sie das ist, kann sie sinnvoll von allen genutzt werden. Vorher nicht. Und wenn sie das ist, dann funktioniert deine "automagic" leider nicht mehr, denn dann wird - je nachdem was das OS präferiert - die Verbindung bereits via IP6 aufgebaut und du erhältst beim Auslesen der Verbindung ... die IP6. Und keine IP4 mehr ;) Außer dein Check/Test würde noch weitere nachgeschaltete komplexere Sachen aufrufen, um außer der IP4 auch die IP6 und umgekehrt zu ermitteln. Würde gehen, aber nunja ... vielleicht unnötig.
Grüße
-
@woodym Ich bin auch immer noch interessiert daran, zu lesen ob/wie es weitergeht und kann gern weiter testen. Würde mich dann aber über Feedback freuen.
-
Hallo Jens,
im augenblick bin ich etwas ausgebremst mit den Aktivitäten. Ich habe bei einigen aktiven Nutzern nachgefragt wie das mit einem Umbau der Aufrufe bei ihnen aussehen würde und habe bisher noch nicht sehr viel resonanz erhalten... warte also noch auf Antworten.
Für die, die bisher geantwortet haben ist das egal; hauptsache sie müssen nichts ändern :-( .
Ich tendiere jedoch dazu einen ditry-call zu haben (wie jetzt mit automatismen) und einen clean-call so wie du ihn dir wünschen würdest.Auf dein Angebot mit weiteren tests komme ich dann gerne auf dich zurück :-) .
Bezüglich tests fällt mir noch ein das du nachsehen wolltest ob die Antwort auch so '^OK*' (also regex) geprüft werden kann.bye woodym
-
@woodym said in Hilfe bei ipv6 und DynDNS:
Bezüglich tests fällt mir noch ein das du nachsehen wolltest ob die Antwort auch so '^OK*' (also regex) geprüft werden kann.
Nein geht nicht. Ein Regex im Feld ist nicht möglich. Zudem liefert dein Ergebnis bei einem IPv6 push immer noch ein "OK <IPv4>" zurück, was an der Stelle einen Match unmöglich macht, da %IP% bei einem v6 Eintrag der pfSense die IP6 enthält und damit kein "OK %IP%" funktioniert. Ansonsten wäre es kein Problem den false/true einzubauen in der nächsten Zeile. Ich empfehle aber da eh weniger Infos und hoffe dass sich bei deinem Dienst noch was tut in der Richtung meiner Vorschläge, dann wäre das eine tolle Alternative auch für IP6 Geschädigte wie mich.
-
noch ein vorschlag.
eine ipv6 hat ja einen prefix teil und einen welches das gerät bestimmt.
Wenn man pro host den static teil angeben könnte, wäre es möglich über die pfsense ein update durchführen zu können und alle hosts wären wieder online.
ich hatte vor jahren mal vor sowas auch zu bauen, allerdings habe ich aufgegeben
Die begränzung auf 3 Hosts finde ich auch ein bissle wenig.
Ich habe Schließlich 4722366482869650000000 Adressen (und wirklich fast soviele Rechner :-) ) -
Da es evtl. auch mehrere Prefixe gibt die man updatet, wäre ein Switch schön: In der Art "prefix_update=1" könnte man dann bestimmen, dass alle hinterlegten IP6 ein neues Prefix bekommen, der Suffix aber konstant bleibt.
Dann müsste es sinnvoll allerdings sehr wahrscheinlich
- mehr IP6 Einträge geben als 3 (o.ä.)
- eine UI geben, mit der man selbst v6 Hosts anlegen kann für die sich dann nur das Prefix ändert.
Wäre sicherlich eine schöne Sache sowas zu haben.
-
@fapo
ich verstehe jetzt nur den sinn nicht so ganz. Ein DNS macht eine Zuordnung von einem Namen zu einer IP. Wenn ich nun einen Namen aufrufe, welche IP soll er dann senden? die erste der 4722366482869650000000 oder die 10'te? Woher soll der DNS wissen was er tun soll?
Ansonste müßte man den DNS-Eintrag so abändern das er den sufix vor den Namen stell. Aber wer kann sich den Namen '57ab.peterle.srvhome.de' denn nun merken.
Das ganze läßt sich viel eleganter über HOST bzw. SNI abbilden. Mehrer Namen führen zu einer IP die dann dort über z.B. Loadbalancer verteilt werden.
Das verwende ich übrigens bei mir. Ein HAProxy verwaltet alle Zugänge nach außen incl. der ganzen Zertifikate für die unterschiedlichen Domains.
Bei SRVHome können durch einen Update alle Domains gleichzeitig aktualisiert werden und PFSense erlaubt mehrere DYNDNS-Server.
Über einen Wildcard vor meine Host könnte man nachdenken. ein *.peterle.srvhome.de würde dann alle Namen mit peterle.srvhome.de zu einer IP leiten. Für die richtigen Zertifikate müßte dann PFSense oder ein anderer Rechner sorgen. Ich weiß jetzt garnicht wie weit Wildcard-Zertifikate bei Let'sEncrypt sind. Das sollte laut Zeitplan bereits gehen, ich kenne aber nicht den aktuellen Stand.bye woodym
-
@woodym
Genau dns ist für die auflösung namen in ip zuständig und zwar sowohl legacy ip wie auch ipv6.
ipv6 Adressen bestehen aus einem prefix welche einem sein Provider zuteilt und einem suffix welche sich der Rechner aussucht.
Der Suffix kann gleich bleiben auch wenn der Provider eine neue Prefix verteilt.
Die Länge des Prefix ist immer gleich z.B. bei Unitymedia in BW 56 bit lang.
ich bräuchte also eine möglichkeit fest zu sagen Host z.b. vpn hat suffix 1:2::3:4 host web hat sufix 1:3::2:4 und die länge meines prefixes ist 56 bit.
Die Prefix und ipv4 kommt dann von der pfsense.
wenn ich jetzt über dns einen aaaa für vpn.peterle.srvhome.de suche kommt zurück: prefix:1:2::3:4
Frage ich nach aaaa für web.peterle.srvhome.de kommt zurück: prefix:1:3::2:4
frage ich nach dem a recourde für egal für welchen kommt die ipv4 zurück.
Die Freigabe erfolgt dann auf seinten der Firewall über Portweiterleitung für ipv4 und eine Firewall regel für ipv6 zumindest solange noch ipv4 relevant wird.
Wenn ipv4 hoffentlich irgendwann nicht mehr wirklich wichtig wird, und die ports ausgehen, kann man einzelne hosts nur über ipv6 Freigeben.
Deine SNI Lösung funktioniert bestimmt super solange du nur webserver hast. für mich wäre u.a. aber noch interessant: vpn für den zugriff vom handy / Laptop ins komplette netzwerk.
mqtt zur standort bestimmung der Handys auf dem privaten Server.
sip u.s.w. der Telefonanlage.
Einzelne freigaben für Gameserver welche ich privat hoste.
diese Auflistung ändert sich übrigens schnell :-)Der vorschlag mittels wildcard ist bestimmt was die Zertifikate anbelangt eine super idee aber damit zerstörst du wieder die "multi host" auflösung bei ipv6.
ich würde an deiner Stelle weniger energie in die Let'sEncrypt geschichte legen und mich mehr auf ipv6 konzentrieren.
Viele Leute schalten in ihren Domains einen Cname zu dir und benutzen dich anschließend als dyndns was du ja auch bist.
so machen sie sich unabhängig von dir und können mit ihrem eigenen namen auftreten.
