Verständnisfrage DYNDNS auf pfS hinter Provider Modem

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.

noplan

@jegr @NOCling

So ich les das morgen noch mal in Ruhe
Vielleicht versteh ich es dann und mich lenkt dieses the masked singer Austria nicht sooo ab

NOCling

Ok wie das im Detail funktioniert habe ich noch nicht nachgelesen bzw. untersucht.

Bin jetzt von Doppeltem NAT ausgegangen und da ist die WAN IP nur über den Server per Abfrage zu ermitteln.

Hatte Noplan so verstanden, das er so einen Fall hat und dann der Dienst das nicht schnell automatisch checkt und wie du sagst das Log zumüllt.
Was ich nicht verstehe, was ist so schwer dran alle 5 min zu schauen ob die IP noch der im Service entspricht, wenn ja weiter pennen, wenn nicht Dyndns Update starten.

noplan

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

Bin jetzt von Doppeltem NAT ausgegangen und da ist die WAN IP nur über den Server per Abfrage zu ermitteln.

ja das ist korrekt (Großbauern-Box ---- pfS ----- LAN (whatever)

was ist so schwer dran

kann ich dir noch nicht sagen, weil noch nicht ausporbiert.
... aber ... zuerst nutz ich mal die Forum Suche ob irgendwer das schon hier gepostet hat, vielleicht wird man ja fündig if not naja probier ich es halt selbst, wie du sagst ist das script ja keine rocket science udn was es machen muss ist in diesem Post ja sauber genug beschrieben.

no dennNP

Bob.Dig

Ich führe auch öfters /etc/rc.dyndns.update aus. Wenn es da was eleganteres gäbe, ich wäre ebenfalls interessiert.

wkn

Das eigentliche Update-Script besteht ja aus zwei Komponenten, die Ermittlung der eigenen IP und der Vergleich mit der gecacheten DynDNS-IP und wenn die voneinander abweichen die Ausführung des Updates beim DynDNS-Provider.

Den ersten Teil könnte man auslagern in ein eigenes Script. Die Ermittlung ist eigentlich nur ein HTTP GET auf die Adresse http://checkip.dyndns.org und dem ausparsen der IP aus der Rückgabe ("Current IP Address: xxx.xxx.xxx.xxx"). Man macht also den Vergleich da einfach nur vorweg und führt das eigentliche Script nur bei Abweichung dann aus. Da der Check wirklich nur aus dem Get besteht kann man den auch in sehr kurzen Perioden ausführen.