Verständnisfrage DYNDNS auf pfS hinter Provider Modem
-
@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
-
@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.
-
@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.
-
danke du hast natürlich recht ...
hier der screenshot vom dynDNS provider des vertrauens ;)
alle 5 Minuten ok ... spannend und cool zugleich
-
@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.ä.) -
@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 STDWenn 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 schreibenDamit 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
-
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? -
@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?
-
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? -
@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.
-
-
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. -
@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 Sucheob 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
-
Ich führe auch öfters /etc/rc.dyndns.update aus. Wenn es da was eleganteres gäbe, ich wäre ebenfalls interessiert.
-
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.
-
@wkn Kannst Du sagen, warum quasi das verlinkte Script anscheinend das Update dennoch macht, selbst wenn sich die IP nicht geändert hat? Weil wäre das nicht, hätten wir ja auch das Problem nicht. Oder anders gefragt, seltsam, dass nicht ein light weight script dafür schon an Board ist.
-
weil ich um kurz vor 12:00 noch immer nicht dazu gekommen bin,
vielleicht macht hier irgendwer mal den anfang und schreibt die
script zeilen hier in den Post,dann hätt ma gleich auch wieder wieder was für die community erledigt ...
-
Laut Log wird nur die Ermittlung und der Vergleich da durchgeführt, nicht das Update, wenn sich nichts geändert hat oder noch keine 25 Tage vergangen sind. Einziges "Problem" sind die 5 oder 6 Zeilen im Log da bei jedem Aufruf des Scripts. Darum sollte man da ein eigenes Script vorschalten, das quasi den ersten Teil macht:
- Holen der Current IP (über checkip.dyndns.org)
- Holen der Cached IP (muss man schauen wie)
- Vergleichen und wenn unterschiedlich das originale Script dann erst aufrufen
Und dieses Script könnte man dann im Cron platzieren und ggf. im Minutenbereich aufrufen lassen
-
@wkn Verstanden! Mich stört das mit den Log-Einträgen nicht, die lösche ich eh täglich, wenn ich mir das Firewall-Log angeschaut habe.
-
Ich mache das DYNDNS-Update auch mit einem kleinen Script per cron - im vorliegenden Fall alle vier Stunden, aber das Script kann prinzipiell auch minütlich aufgerufen werden. Die Logdatei wird - ebenfalls per Script und cron - automatisch auf eine bestimmte Zahl an Einträgen gekürzt.
Gruß Jürgen
<?php $timestamp = time(); $datum = date("d.m.Y",$timestamp); $uhrzeit = date("H:i",$timestamp); $Host = "xyz.nsupdate.info"; $IP_Abfrage = "https://ipv4.nsupdate.info/myip"; $IP1 = file_get_contents($IP_Abfrage); $IP2 = gethostbyname($Host); $check1 = ip2long($IP1); $check2 = ip2long($IP2); if ($check1 == -1 || $check1 === FALSE) { $resonse = "IP konnte nicht ermittelt werden"; } elseif ($check2 == -1 || $check2 === FALSE) { $response = "Service nicht erreichbar"; } else { if ($IP1 == $IP2) { $response = "IP noch aktuell"; } else { $response = file_get_contents('https://xyz.nsupdate.info:xxxxxxx@ipv4.nsupdate.info/nic/update'); if (strpos($response,"good") !== FALSE || strpos($response,"nochg") !== FALSE) { $response = "IP aktualisiert - " . $response; } else { $response = "Update fehlgeschlagen"; } } }; $info = $datum . " " . $uhrzeit . " - " . $response; $URL = 'https://user:pass@meinedomain.tld/verzeichnis/nsupdate_log.php?response='.urlencode($info); $handle = fopen($URL, "r"); ?>
<?php $Log = $_GET['response']; $logfile = "nsupdate.log"; $zeilen = 60; $handle = fopen($logfile, "a+") or die('Datei kann nicht zum Schreiben geöffnet werden'); fwrite($handle, $Log . "\n"); fclose($handle); file_put_contents($logfile, implode("\n", array_slice(explode("\n", file_get_contents($logfile)), -($zeilen+1)))); ?>