Verständnisfrage DYNDNS auf pfS hinter Provider Modem

noplan

Mal was entspannendes für den Start.

wenn die pfS hinter einem Provider Modem hängt (ignrieren wir jetzt malSinn / Unsinn d doppelten NAT etc.pp.)

ist es noch notwendig auf dem Provider Modem den dynDNS zu aktivieren,
müsste doch ausreichen das nur auf der pfS durchzuführen.

woher der DYNDS Provider die Anfrage bekommt müsste ihm doch eigentlich egal sein.

würd mich über Gedanken (verschriftlicht hier;) freuen

lgNP

NOCling

Also mein Cabel Modem kann genau so viel wie ein Modem können muss und das ist nicht viel.
Werte der Kanäle anzeigen, das Profil und das wars auch schon, da ist nix mit NAT.

Hört sich also eher nach Router an was du davor schnallst.

Und ja es ist egal wo du den Dyndns Deamon laufen lässt.
Er bekommt halt bei dir nicht direkt mit das sich die IP am WAN ändert.
Aber dafür fragt er dann einen Server und schaut nach seiner IP die der Server zurück liefert.

Das dauert dann ggf. einen Moment bis die neue dann erreichbar ist. Aber die ändert sich ja inzwischen nicht mehr täglich, da fällt die 1 Min die es dann ca. dauert sicherlich nicht großartig auf.

noplan

@nocling

ja stimmt,
manchmal ist es ein Cabel Modem
manchmal ist es eine Provider Wunder Box also ein Router
manchmal ist es auch eine Provider Wunder Box die in den Bridge Mode gesetzt wird und die WAN IP direkt an die Box liefert.

Er bekommt halt bei dir nicht direkt mit das sich die IP am WAN ändert.

das könnte man ja mittels Cron in einem kürzeren Update Intervall regeln ?
vom DYNDNSPorvider aus gäbe es ja auch noch die Möglichkeit eine TTL zu setzen (is halt fraglich was das wirklich bewirkt und welche Kombi (pfS Cron Update Intervall + TTL d DYNDNS Providers) zu bevorzugen ist

Aber die ändert sich ja inzwischen nicht mehr täglich

in Ösi-Land haben wir noch immer ein paar GroßBauern die alle 6 STD die IP wechseln oder wenn Ihren Technikern mal wieder was deneben geht auch darunter (<6STD)

Eine unpassende aber scheinbar weit verbreitetet Kombi dürfte dynDns-client am porvider (modem/ Router/ wunderbox) und zusätzlich ein dynDns-client auf der pfS zu sein.

wkn

Standardmäßig wird der DynDNS-Update einmal am Tag (01.01) oder beim Ändern der WAN-IP gestartet. Ist die pfSense kaskadiert hinter einem Router wird die Neuverbindung nicht erkannt.
Meiner Meinung nach sollte der DynDNS-Service immer auf dem Router laufen, der die Internetverbindung aufbaut. Oder aber man nutzt den ersten Router nur als Bridged Modem und lässt die pfSense dann Alles machen.

noplan

@wkn

wird die Neuverbindung nicht erkannt.

Die Lösung für das wäre dann einen kürzeren Intervall auf der pfS mittel Cron einzurichten,
das die pfS die Änderung aktiv mitbekommt ? Oder seh ich das falsch.

Meiner Meinung nach sollte der DynDNS-Service immer auf dem Router laufen, der die Internetverbindung aufbaut.
Auch wenn dieser nicht im Bridge Mode läuft ?

Es gibt in der freien Wildbahn echt immer wieder Kombinationen die sollte es nicht geben.
(zB Bridge Mode wird vom ISP nicht erlaubt / unterstützt )

NOCling

Bin in dem Fall für einen Chron auf der Sense, die hast du unter Kontrolle.
Bei dem Provider Modem kann ja alles über die Anbieterwartung passieren.
Ggf. ist nach jedem Neustart der Dyndns Dienst wieder nackig.

Alles schon erlebt bei den Pferdekutschen dieser Großbauern.

noplan

@nocling

Bin in dem Fall für einen Chron auf der Sense, die hast du unter Kontrolle.

Jetzt ist nur mal die Frage offen in welchem Intervall der corn job auf der pfS Sinn macht,
das daily um 01.01 stellen wir mal als nich zielführend hin.

Alle 3 STD ? oder doch länger, drunter wäre ja möglich aber der Sinn ?

NOCling

Hängt halt wieder vom Anspruch ab.
1h, 5Min, Minütlich.

Er soll ja nur nachsehen ob die WAN IP ne andere ist.
Wenn ja dann Update, wenn nicht wieder hinlegen bis zum nächsten Wecker.

Bob.Dig

@nocling said in Verständnisfrage DYNDNS auf pfS hinter Provider Modem:

Er soll ja nur nachsehen ob die WAN IP ne andere ist.

Moin, aber kann pfSense das ganz alleine oder muss dafür ein Dritter beansprucht werden und wenn zweites, meckert der dann, wenn minütlich abgefragt wird?

Hab mir hier so beholfen, dass ich den Reconnect in der Nacht mache und nur in diesem Zeitraum dann erhöht mit cron geprüft wird. Darüber hinaus habe ich noch DDNS in der Fritzbox eingerichtet, um zumindest eine Adresse akkurat auflösen zu können. Aber alles nicht perfekt in der Router-Kaskade.

wkn

@noplan

Aber worin besteht nun eigentlich das Problem, deinen Einwahl-Router das ganze DynDNS-Geschehen ausführen zu lassen? Kannst du den Roter da nicht als Modem benutzen? Benötigst du Funktionalität auf dem Router?
In einer Router-Kaskade ist da nun mal nur "Trickserei" auf der pfSense.

noplan

@wkn said in Verständnisfrage DYNDNS auf pfS hinter Provider Modem:

deinen Einwahl-Router das ganze DynDNS-Geschehen ausführen zu lassen

a)
die holen je nach ISP unterschiedlich bis gar nicht ab (also da rennt mehrso auf "gut Glück" als ja es ist jetzt wirklich passend)

b) nein bei einigen Provider Kasterl ist es nicht gewünscht / nicht möglich diese als Bridge zu betreiben somit bleibt nur Kaskade wenn man so will

c) ja ich "trickse" lieber auf der pfS mittels cron job alle 3 Std als mich auf die ISP Kiste zu verlassen, weil die pfS tut für gewöhnlich das was sie soll / ich manchmal will, was ich von den Provider Kutschen nicht so sagen kann

noplan

@bob-dig said in Verständnisfrage DYNDNS auf pfS hinter Provider Modem:

meckert der dann, wenn minütlich abgefragt wird?

wenn ich das richtig verstehe musst du beim dynDns provider das Abfrage Intervall (aus deren Sicht die TTL) richtig einstellen sonst ,passiert was auch immer,

also wenn TTL alle 60 sec auf dynDNS Provider fpr die Adresse eingestellt;
dann sollte cron alle 65 sec passen ;)

wenn TTL auf 4STD dann naja wirds mit alle 60sec cron irgendwas auslösen (was auch immer)

Zusammengefasst, werd ich mal testen wie sich die boxen unsere Großbauern hier schlagen wenn der cronJob für dynDns alle 4 STD auf der pfS rennt und die dynDNS Clients auf der Provider (Großbauer) Box deaktiviert wird. (TTL wird wohl so auf 2 STD gesetzt) mal schauen ob da was bei rauskommt.

viragomann

@noplan
TTL hat mit dem DynDNS-Update nicht direkt was zu tun. TTL ist die Zeit, die ein DNS Client den Eintrag in seinem Cache behalten darf. Ist sie abgelaufen, muss er also erneut den Server abfragen, wenn ein Aufruf des Hostnamens kommt.
Bei einem DynDNS Provider habe ich bislang noch keinen größeren Standardwert als 120 gesehen.

Für den Cronjob habe ich mal Empfehlungen von 5 oder 3 Minuten gesehen, falls die pfSense hinter einem Router installiert ist und selbst das DynDNS-Udate macht.

noplan

@viragomann

danke du hast natürlich recht ...

hier der screenshot vom dynDNS provider des vertrauens ;)

alle 5 Minuten ok ... spannend und cool zugleich

JeGr

@nocling said in Verständnisfrage DYNDNS auf pfS hinter Provider Modem:

1h, 5Min, Minütlich.

1h OK. 5min nope. 1min? HELL NO!
Da läuft jedes Mal ein rc.init Skriptgedöns los, das von allen konfigurierten DynDNS Settings die IP prüft. Das WILL man nicht alle Minute oder alle 5 Minuten machen. Hat damals schon mein Prof gesagt, wenn du was alle 1/2/3 Minuten pollen musst, dann machst du was falsch und bräuchtest nen Push oder ne andere Methode.

Wenn der DynDNS Anspruch haben muss auf "geht annähernd sofort wieder", dann muss er vorne hin auf den Router der die Einwahl mitbekommt. Wenn 15-30 Minuten noch OK sind, dann mit Cron alle Stunde maximal auf die Sense. Ansonsten ein leichtgewichtiges Skript/Monitoring selbst bauen was minimal was tut und erst DAS löst dann bei Action das Init Script für den DynDNS aus. Ansonsten kannst du dein Syslog wegwerfen weil alle 5min 10 Zeilen Blubb von DynDNS prüfen drinsteht und man nix mehr sonst sieht.

Moin, aber kann pfSense das ganz alleine oder muss dafür ein Dritter beansprucht werden und wenn zweites, meckert der dann, wenn minütlich abgefragt wird?

Wer soll denn meckern? Du rufst nicht alle Intervall die Update Routine des DynDNS Anbieters auf, sondern machst einen Check mit einer CheckIP Seite ob sich die gecachte IP des IFs geändert hat oder nicht. Erst DANN wird auch ein Update angestoßen. Nur blubbert das eben immer einen Haufen Logkram los, deshalb würde ich das nicht in Minuten sondern höchtens in Stunden machen.

TTL beim Provider ist ja NUR relevant dafür um die Volatilität des DNS Eintrags anzuzeigen. Wenn da dei TTL bei 60 oder 120(s) steht, dann weiß jeder Cache oder Resolver, alles klar, brauch ich nicht (lang) zu cachen, sondern muss ich neu abrufen, weil könnte sich geändert haben. Das hat aber keinerlei Auswirkung auf DynDNS Dienste oder den Sinn, wie oft man seinen eigenen Check etc. machen sollte.

Es kommt eben drauf an, mit was man rechnet. Wenn man damit rechnen muss, dass beim Bauer das WAN Dings alle 3h sich neu einwählt und das Mist ist, dann würde ich ggf. auf ne Stunde runter. Dann hat man im schlechtesten Fall 59min in denen die IP nicht stimmt. Wenn das zu viel ist warum auch immer, muss man eben abwägen, was noch OK ist.
Das ist eigentlich ne simple Matheaufgabe und SLA Abwägung, was wann wie und wie schnell (wieder) funktionieren muss. Oder ob ich darauf überhaupt angewiesen bin (e.g. weil das Ding eh von sich aus die Verbindung aufbaut und daher die DynDNS nicht zwangsweise nötig o.ä.)

noplan

@jegr said in Verständnisfrage DYNDNS auf pfS hinter Provider Modem:

das von allen konfigurierten DynDNS Settings die IP prüft.

kann man das eigentlich durch ein eigenes script ersetzen, das zB
WAN-1 im default bleibt
WAN-2 alle 6 STD
WAN-3 alls 3 STD

Wenn 15-30 Minuten noch OK sind, dann mit Cron alle Stunde maximal auf die Sense

wenn du geringere Zeiten brauchst wird es mit dynDNS ja sowieso etwas ...

Ansonsten kannst du dein Syslog wegwerfen

kannst meiner Meinung nach bereits bei allen Zeiten < 4 STD (wenn du auch noch mail notification an hast bringt das außer Nachteil im Log NIX NIX NIX)

TTL beim Provider ist ja NUR relevant dafür um die Volatilität des DNS Eintrags anzuzeigen.

Danke für den Hinweis .. hab ich falsch bzw. nicht richtig verstanden, wurde mir erst durch den Einwurf v @viragomann deutlich.

Das ist eigentlich ne simple Matheaufgabe und SLA Abwägung

ja du hastRecht, man muss halt nur wissen das es eine Mathe Aufgabe ist,
und wenn SLA mitschwingt jop biste dabei, wobei ein Opfer bringst immer, wenn du die Settings unter eine Stunde drehst um nicht zB 59 Minuten warten zu müssen bis die dynDNS passt, dann ist wahrscheinlich dein LOG ziemlich wertlos.

Die Lösung ist also wirklich ein zu bauen Script das alle x Minuten gegen die gleiche CheckIP wie das dynDNS script prüft, und erst wenn diese Prüfung negativ ist löst ...

DAS löst dann bei Action das Init Script für den DynDNS aus
und der kann dann unbehelligt ins logfile schreiben

Damit würde man mE auch die multi WANmulti dynDNS Sache (oben angesprochen) lösen oder.

Gute Frage, wer schreibt das Script für 1 Bier oder 2 ???

lgNP

NOCling

Du musst doch dann nur das Skript bauen und dann im Custom Dnydns Dienst nicht die WAN IP sondern deine ermittelte eintragen.

Das sollte doch dann laufen.

Nach dem ersten Einrichten und testen kannst für das Skript dann das Logging abschalten und dann ist es transparent, kann aber alle x Minuten rennen ohne groß Ressourcen zu verbraten und das Log zu bomben.
Oder übersehe ich hier etwas?

JeGr

@nocling said in Verständnisfrage DYNDNS auf pfS hinter Provider Modem:

Du musst doch dann nur das Skript bauen und dann im Custom Dnydns Dienst nicht die WAN IP sondern deine ermittelte eintragen.

Warum soll man im DynDNS Dienst mit Custom irgendwas rumbasteln? Verstehe die Logik gerade nicht. Was soll das bringen?

NOCling

Na da kann man doch dann die eigene Variable laden und muss nicht die WAN-IP fressen die bei den vordefinierten gegeben ist.
Oder bin ich gerade auf der Holzbrücke unterwegs?

JeGr

@nocling Versteh ich gerade nicht, sorry, vielleicht zu spät heute. Warum welche WAN IP die man nicht will? Hä?

Man stellt das Interface ein (WAN1/WAN2/blubb) und wenn pfSense ne RFC1918 Adresse am Interface erschnüffelt, wird automatisch gegen den IP Service der eingestellt ist gegangen (default checkip.dyndns.org, kann man beliebig eigene hinterlegen). Ergo stimmt die rückgelieferte IP4 immer mit dem überein, was das Interface hat. Hab da noch nie Probleme gehabt egal an welchem der drei WANs.