Dienst oder Programm gesucht, welches automatisiert meinen Port prüft

[Bob.Dig]

Folgendes Problem habe ich ab und an: Mein ISP Pyur schaltet bei einem IP-Wechsel manchmal DS-Lite statt vollem DS. Wenn ich daraufhin manuell einen IP-Wechsel initiiere, dann habe ich wieder vollen DS.
Es kann aber leider dauern, bis ich das überhaupt mitbekomme.

Daher meine Frage, wie ich das irgendwie automatisiert mitbekommen könnte, vielleicht einen Webservice?

Eine andere Überlegung wäre, über eine bestehende VPN-Client-Verbindung meine(n) WAN-Port selbst zu testen, aber mit welchem Programm könnte ich das schön mit GUI unter Windows oder ggf ohne, aber dann per E-Mail-Benachrichtigung oder ähnlichem realisieren?

 

[Raijin]

Man könnte ganz simpel mit nslookup in einem Batch- oder PowerShell-Skript die eigene WAN-IP auslesen und auf Basis dessen wasauchimmer tun.

nslookup myip.opendns.com resolver1.opendns.com

Ein fertiges Tool ist mir nicht bekannt, aber evtl. findet man ja eine fertige Batch, o.ä., die man dann einfach im Task Planer einbauen kann.

Alternativ zu obigem nslookup kann man auch den Inhalt entsprechender checkip-Seiten parsen. http://icanhazip.com/ liefert zB ausschließlich die WAN-IP, von der die Seite aufgerufen wurde, zurück.


Bei beiden Varianten muss man natürlich noch eine Logik einbauen, die die WAN-IP als öffentlich oder CGN identifiziert. Dazu muss man die IP-Range des Anbieters kennen.

Ergänzung (22. Mai 2020)

Das ganze hat nur einen Haken: Wenn man nicht weiß welche WAN-IPs der Provider für DS bzw. DS-Lite verwendet, bringt einen das leider nicht wirklich weiter. In beiden Fällen würden man bei Check-IP-Seiten eine "normale" öffentliche IP sehen - tatsächlich die eigene oder eben die des Provider-Gateways.

Dann bleibt einem wohl nur übrig, die WAN-IP des Routers abzugreifen - wenn der Router denn in irgendeiner Form über die Kommandozeile abzufragen ist, sei es Telnet, ssh oder was weiß ich. Ist das nicht möglich, kann man ggfs noch versuchen, mittels tracert den 2. Hop auszuwerten, das Standard-Gateway des Routers und somit die Tür zum Provider. Wenn das eine private IP nach RFC1918 ist oder im offiziellen CGN-Bereich (100.64.0.0/10), dann ist man mit DS-Lite unterwegs.

 

[Bob.Dig]

Letzteres bringt mir alles nix, wenn ich dich denn richtig verstanden habe, da die DS-Lite Internet-IP nicht anders aussieht als mit DS und mein Provider eh CG-NAT-Adressen am WAN nutzt, aber dafür 1:1 NAT macht. Ich denke ich komme um einen automatisierten Port-Test nicht herum.

Dies dürfte aber dank pfSense und der dynamischen Einbindung eines VPN-Clienten gar nicht schwer sein. Ich kann z.B. nur bestimmte Ports ins VPN leiten, alle anderen nutzen das normale Gateway, damit könnte ich quasi fast jeden Porttester Client lokal ausführen, wenn es denn so was gibt. Her mit den Empfehlungen! 😁

 

[Raijin]

Und was soll der VPN-Client tun?!? Der telefoniert raus und da ist es egal ob du hinter DS-Lite oder DS sitzt. Wenn, dann musst du eine eingehende Verbindung zum Testen nutzen. Also in irgendeiner Form von außen einen Port-Test triggern.

 

[Bob.Dig]

Und was soll der VPN-Client tun?!? Der telefoniert raus und da ist es egal ob du hinter DS-Lite oder DS sitzt. Wenn, dann musst du eine eingehende Verbindung zum Testen nutzen. Also in irgendeiner Form von außen einen Port-Test triggern.

Wenn ich einen Portest mache, lokal ausgeführt, auf eine DNS-Adresse meines WAN, die aber über den VPN-Client rausgeht, dann habe ich doch einen externen Test oder habe ich Denkfehler? 😉

 

[Raijin]

Ich kann dir nicht folgen. Was haben VPN und DNS damit zu tun?


Sofern dein Router NAT-Loopback unterstützt, kannst du

a) eine Portweiterleitung für einen beliebigen Port einrichten
b) einen Dienst auf diesem Port öffnen
c) deine öffentliche IP wie oben beschrieben ermitteln
d) eine Verbindung mit der ermittelten IP auf diesem Port herstellen


Wenn der Router NAT-Loopback unterstützt und die Verbindung erfolgreich ist, ist alles gut. Wenn die Verbindung fehlschlägt, kann der Router entweder kein NAT-Loopback oder es ist DS-Lite. Es steht und fällt also mit NAT-Loopback.

 

[Bob.Dig]

Ich kann dir nicht folgen. Was haben VPN und DNS damit zu tun?

VPN-Client ist eine externe Quelle zu meinem WAN. Meine WAN-IP wird durch externes DNS aufgelöst und die Verbindung findest also über den VPN-Provider auf meine WAN-Adresse statt und damit sollte der Port-Test schon aussagekräftig sein

NAT-Loopback hattest Du und auch andere ja immer von abgeraten und ich hab es auch deswegen noch nie eingerichtet oder probiert. Bin mir auch nicht sicher ob es in diesem Fall wirklich einer gute Test wäre, bei den ganzen Besonderheiten meines ISP... WAN > 1:1 CG-NAT > Internet-IPv4 > Porttest

 

[Raijin]

VPN-Client ist eine externe Quelle zu meinem WAN

Wie jetzt extern? Willst du jetzt vom Handy aus immer VPN über Mobilfunk testen oder wie? Ich dachte du suchst eine automatisierte Lösung im Sinne eines lokalen Tools bzw. Skript? Klar, wenn di einem gemieteten vServer hast, kannst du da soviel nach Hause telefonieren wie du willst, sei es nu mit einem VPN-Client oder sonstwas.

NAT-Loopback hattest Du und auch andere ja immer von abgeraten und ich hab es auch deswegen noch nie eingerichtet oder probiert.

Dann hast du zumindest meine Ausführungen dazu nicht ganz gelesen und/oder nachvollzogen. NAT-Loopback hat in erster Linie nichts mit Sicherheit zu tun, sondern mit Geschwindigkeit. Nutzt man innerhalb des Heimnetzwerk zB die eigene DDNS-Domain, geht sämtlicher Traffic, also jedes einzelne Datenpaket, komplett durch den Router und eben nicht nur durch dessen Switch - wenn die Verbindung überhaupt quer durchs Netzwerk am Router vorbeikommt..... Langsamer Router, langsame Verbindung. Statt direkt Gerät <> Switch <> Gerät läuft es bei NAT-Loopback also Gerät <> Switch <> RouterFirewallUndNATamWANPort <> Switch <> Gerät. Das ist in deinem Fall aber unerheblich, wenn du nur einen Verbindungstest zwecks DSLite-Erkennung machen willst.

 

[Bob.Dig]

@Raijin Also für dich mal Klartext, habe einen Account bei einem VPN-Provider und in pfSense diesen als OpenVPN-Client eingerichtet. Nun kann ich nach belieben Verbindungen (z.B. abhängig vom Quell oder Zielport etc) statt über das WAN über das VPN ausleiten. Das müsste dann zum Testen über Extern ausreichend sein oder irre ich? Hoffe, das war jetzt gut zu verstehen. 😉

Auch fahre ich generell Split-DNS und habe eigentlich keine Lust auf NAT-Loopback, weil es halt weniger performant ist. Ich weiß aber weder, ob das jetzt groß eine Rolle spielt bei mir, noch ob ich es überhaupt realisieren könnte, scheint mir einfach nicht die beste Option zu sein, die ich habe.

Ergänzung (23. Mai 2020)

Folgendes Problem habe ich ab und an: Mein ISP Pyur schaltet bei einem IP-Wechsel manchmal DS-Lite statt vollem DS. Wenn ich daraufhin manuell einen IP-Wechsel initiiere, dann habe ich wieder vollen DS.
Es kann aber leider dauern, bis ich das überhaupt mitbekomme.

Daher meine Frage, wie ich das irgendwie automatisiert mitbekommen könnte, vielleicht einen Webservice?

Eine andere Überlegung wäre, über eine bestehende VPN-Client-Verbindung meine(n) WAN-Port selbst zu testen, aber mit welchem Programm könnte ich das schön mit GUI unter Windows oder ggf ohne, aber dann per E-Mail-Benachrichtigung oder ähnlichem realisieren?

Wer hier noch Empfehlungen hat, gerne her damit!

 

[Raijin]

Auch fahre ich generell Split-DNS und habe eigentlich keine Lust auf NAT-Loopback, weil es halt weniger performant ist. Ich weiß aber weder, ob das jetzt groß eine Rolle spielt bei mir, noch ob ich es überhaupt realisieren könnte, scheint mir einfach nicht die beste Option zu sein, die ich habe.

Du hast leider immer noch nicht verstanden was NAT-Loooback ist. Ja, es ist wie beschrieben potentiell langsam, aber NUR, wenn man von innen direkt auf die eigene WAN-IP zugreift, um dann über eine Portweiterleitung zB Daten vom/zu. NAS kopiert. Wenn man dazu nicht die eigene WAN-IP nimmt, sondern die lokale IP des NAS, bleibt alles beim alten.

Du willst doch quasi nur anklopfen und darüber prüfen ob überhaupt eine Verbindung zustande kommt! Verbindung auf WAN-IP, wenn hergestellt, Verbindung schließen => DS. Wenn keine Verbindung möglich => DS-Lite. Das ist im Prinzip nix anderes als wenn du jetzt von einem ausgehenden VPN aus auf deine WAN-IP zugreifen willst, nur ohne das VPN

Naja, ich hab dir eine Tür gezeigt, durchgehen musst du selbst - oder dir eine andere Tür suchen. Man könnte zB auch mit dem Provider drüber reden, weil es absolut nicht normal klingt, wenn da ständig zwischen DS und DS-Lite gewechselt wird.

 

[Bob.Dig]

@Raijin Und wie sollte nun dieser automatisierte Test ablaufen, nachdem Du mich jetzt wohl verstanden hast? Suche ja nach konkreten Vorschlägen... 😉

Ergänzung (23. Mai 2020)

Da bis jetzt niemand was vorgeschlagen hat, werde ich mal selbst ein paar Windows Traytools testen.

 

[Raijin]

1. Portweiterleitung für den Testport einrichten
2. Testserver auf dem Testport einrichten
3. NAT-Loopback aktivieren, falls nötig -- oder dein VPN
4. WAN-IP ermitteln
5. Testclient über die WAN-IP:Testport verbinden
6. Erfolgreich > DS ---- Fehlgeschlagen > DS-Lite

Abgesehen von Nr 3 musst du so oder so alle Schritte durchführen, VPN/NAT-Loopback hin oder her.


Mir wäre kein Tool bekannt, dass sowas automatisch durchführt. Wozu auch? Meiner Meinung nach ist das ein Problem des Providers. Normalerweise hat man entweder DS oder DS-Lite, aber nicht ständig wechselnd. Melde dich daher am besten beim Support, wenn nicht bereits geschehen. Zur Not so oft bis sie ihr eigenes Problem begreifen, weil sie ja die Ursache sind....

 

[Bob.Dig]

@Raijin Es tritt nur selten auf, deswegen wird der Provider, wir reden hier von Pyur, wie immer nichts machen. Der selbe Provider vergibt, vermutlich als einziger auf der Welt, auch nur einen einzigen Ipv6-Prefix. Das wollt mir auch schon keiner glauben und die Hotline hat es auch nicht interessiert. Schriftlich wird quasi direkt an die Hotline verwiesen, in Textform äußert sich da keiner. Also ich kenne meinen ISP nun schon viele Jahre.

Deine Liste ist nicht das Problem, ich würde DDNS nutzen für die WAN-IP usw.

 

[Raijin]

Das klingt ja nach einem richtig tollen Provider
Ich vermute du bist auf ihn angewiesen? Sonst hättest du wohl schon gewechselt

Deine Liste ist nicht das Problem, ich würde DDNS nutzen für die WAN-IP usw.

Sondern?

Welchen Dienst du für den Test nutzt, ist mehr oder weniger egal. Natürlich sollte es nicht sowas wie SMB sein, das nicht für das Internet gedacht ist, aber man könnte zB einfach einen Webserver benutzen.

 

[Bob.Dig]

Sondern?

Nicht sondern, ich nutze DDNS. 😁

Hab selber genug Dienste am laufen, brauch da nichts extra öffnen. Hätte ich nichts offen, müsste ich ja auch nichts unternehmen. 😉

 

[Raijin]

Sondern bezog sich auf "Deine Liste ist nicht das Problem". Was also ist das Problem?

Beispiel Webserver:

Mittels curl bzw wget unter Linux oder Invoke-Webrequest unter Windows Powershell kann man eine Webseite in einem Skript runterladen und ihren Inhalt prüfen. Das machen sich beispielsweise DDNS-Clients zu nutze, indem sie Seiten wie icanhazip.com runterladen und daraus die WAN-IP parsen. Dein Testtool kann sich derselben Mechanismen bedienen. curl/wget/invoke-webrequest auf einen Webserver im lokalen LAN, aber über die DDNS-Domain bzw. die eigene WAN-IP aufgerufen und du weißt was Sache ist.

Ich sehe gerade, dass es in Powershell zB auch Test-Netconnection gibt. Damit wird explizit ein Verbindungstest gemacht, zB auch mit einem benutzerdefinierten Port. Habe es nicht ausprobiert, aber google meint, dass sich das perfekt als Porttester eignet.

Unter Linux gibt es diverse Möglichkeiten dasselbe zu erreichen.


Kurz: Ein kleines Skript, das im TaskPlaner / cron läuft und mittels curl, etc oder eben Test-Netconnection, nping, nmap oder telnet den Port prüft und fertig

*edit
Natürlich ist ein well known port wie zB TCP 80/443 oder andere standardisierte Ports allein weniger gut geeignet als ein benutzerdefinierter Port. Wenn man den Weg des Webservers geht, sollte man daher einen beliebigen anderen Port wählen oder eben tatsächlich die Seite parsen, da steht dann nur ein banales OK drin oder so. Die zuletzt genannten Porttester liefern auch nur "Verbindung hergestellt" oder eben nicht. So kann man sich zB auch unter Windows mit telnet mit einem OpenVPN-Server verbinden im Sinne von TCP-SYN und anschließendem TCP-SYN-ACK. Um sicherzustellen, dass es sich um den richtigen Server handelt, sollte man daher einen möglichst ungewöhnlichen Port für den Test wählen oder eben die Verbindung weitergehend prüfen (wie beim Parsen der Webseite). Sonst läuft man Gefahr, falsch-positive Rückmeldungen zu bekommen, wenn zB DDNS nicht aktuell ist oder aber das Provider-CGN-Gateway zufällig ebenfalls auf dem getesteten Port antwortet.

 

[Bob.Dig]

Kurz: Ein kleines Skript, das im TaskPlaner / cron läuft und mittels curl, etc oder eben Test-Netconnection, nping, nmap oder telnet den Port prüft und fertig

Also Test-Netconnection hat soweit funktioniert, danke dafür.

(Sehe gerade, dass pfSense ebenfalls einen eingebauten Port Test hat. Hier kann ich gleich als Quelle den VPN-Client nutzen, das erspart mir das Umleiten, sofern das denn nötig ist. Wenn ich nicht Umleite, dann sehe ich als Source in der Firewall meine öffentliche IP)

Aber wie nun daraus ein Script machen mit einem nützlichen Output? Wer hier helfen kann, bitte melden! Es gibt auch nix als ein Dankeschön. 😉

 

[Bob.Dig]

Da ich DNS über cloudflare mache, habe ich mal geguckt, ob ich deren Dienste für die Lösung meines Problems nutzen kann. Hab den Proxy mal für eine Adresse aktiviert, allerdings nicht Web, und es scheint nicht zu funktionieren, die Verbindung ist immer noch direkt... was bedeuten könnte, dass bei einem Nichterreichen bei mir auch kein Alarm ausgelöst wird.... habe bis jetzt Cloudflare nie zum proxien sonder fürs reine DNS genutzt.
Ok, das scheint nur für Webserver zu funktionieren, hab ich momentan nicht nach außen geöffnet.

 

[Bob.Dig]

@Raijin Da ich mit dem Thema nicht weiter komme, habe ich mal NAT-Loopback probiert, dafür Split-DNS für eine Adresse deaktiviert, und war überrascht, dass das OOTB zu funktionieren scheint, hatte das anders in Erinnerung (pfSense hat noch etwas namens NAT Reflection, welches aber deaktiviert ist). Zumindest sehe ich, dass ein Programm, welches sich mit einem meiner lokalen Server verbunden hat, als Remote-Adresse meine eigene Internet-IP nutzt. D.h. wohl, dass NAT-Loopback funktioniert?

Nun bist Du dir sicher, dass das ganze nicht mehr funktionieren würde, wenn hier wieder der DS-Lite Fall eintritt? Mir fehlt da das Wissen. Das Prog habe ich stets und ständig laufen und es ist nur ein Instant Messenger, also traffic etc ist da völlig egal und ich hab es immer im Blick, dann wäre die Fragestellung tatsächlich "gelöst".

 

[Raijin]

Zumindest sehe ich, dass ein Programm, welches sich mit einem meiner lokalen Server verbunden hat, als Remote-Adresse meine eigene Internet-IP nutzt. D.h. wohl, dass NAT-Loopback funktioniert?

Ja, das ist richtig so. Wie beschrieben dreht der Router die vermeintlich ausgehende Verbindung im allerletzten Moment im WAN-Port um und schickt sie wie jeden anderen eingehenden Verkehr am WAN-Port durch die NAT- und Firewall-Pipeline. Zuvor hat aber bereits das Masquerade bzw. SourceNAT am WAN-Port gegriffen und somit ist der "Absender", der dann am anderen Ende der Portweiterleitug ankommt, die eigene WAN-IP.

• Verbindungsanfrage an die WAN-IP
• Client schaut in die Routing-Tabelle und schickt die Anfrage Richtung Standardgateway aka Router
• Der Router tut (fast) dasselbe und routet zum WAN-Port durch und ersetzt die Absender-IP mit seiner WAN-IP
• Nun "merkt" der Router, dass das Ziel aber gar nicht hinter dem Provider-Gateway ist, sondern er selbst gemeint ist
• Die Verbindungsanfrage wird nun also mit Quell-IP und Ziel-IP wieder in den WAN-Port geleitet, durchläuft ie Portweiterleitung und landet beim Server

Nun bist Du dir sicher, dass das ganze nicht mehr funktionieren würde, wenn hier wieder der DS-Lite Fall eintritt? Mir fehlt da das Wissen.

Ausprobiert habe ich es nicht, weil ich kein DS-Lite habe. Allerdings müsste es genau so funktionieren, weil die öffentliche IP, die man entweder über eine der oben genannten Checkip-Seiten oder eine aktualisierte DDNS-Domain bekommt, nicht die WAN-IP des Routers ist, sondern die des Provider-Gateways - und da endet der Verbindungsversuch dann.

Am WAN hat der Router bei DS-Lite entweder eine IP aus dem für CGN reservierten Bereich (100.64.0.0/10) oder auch ganz banal eine IP aus dem RFC1918 Bereich, also eine private IP (meistens dann 10.x.y.z). Genau auf diesem Umstand basierte einer meiner anderen Vorschläge, via tracert das Provider-Gateway zu identifizieren (das muss ja ebenfalls in diesen Ranges liegen).