Logging der CGNAT-Adresse

  • Es mag für den einen oder anderen aus verschiedenen Gründen interessant sein, an Internet-Zugängen mit CGNAT (z.B. "Deutsche Glasfaser") die jeweils für den eigenen Kundenanschluss verwendete CGNAT-Adresse zu ermitteln, und zwar nicht nur einmalig bei Bedarf und interaktiv durch Aufruf geeigneter Websites (z.B. https://www.wieistmeineip.de/), die die eigene öffentliche IPv4-Adresse anzeigen, sondern (relativ) permanent per Logging über ein Skript, das die CGNAT-Adresse in regelmäßigen Zeitabständen ermittelt und versehen mit Datum/Uhrzeit in eine Log-Datei schreibt.

    Inspiriert durch https://www.howtogeek.com/839170/how-to-…ux-bash-script/ habe ich so eine Lösung mal für Windows umgesetzt:

    • Ich habe ein Batch-Skript "getmycgnat.cmd" erstellt, das bei Start meines Windows-PC mit gestartet wird und in regelmäßigen Zeitabständen die aktuelle CGNAT-Adresse inklusive Zeitstempel in eine LOG-Datei namens CGNAT.log schreibt.
    • Nachteil ist dabei, dass das Logging nur erfolgt, wenn mein Windows-PC läuft. Aber ich habe nun mal keinen 24/7 laufenden Linux-Server, der für so etwas natürlich deutlich besser geeignet wäre. Und meinem Windows-Desktop starte ich ohnehin nahezu täglich.

    Wen die Lösung interessiert und sie evtl. für sich adaptieren möchte, hier meine "Implementierung":

    In dem oben verlinkten "howtogeek" werden zwei zentrale Kommandos genannt, die die aktuelle CGNAT-Adresse ermitteln, hier mal unter meinem Windows gezeigt:

    Code
    C:\>dig -4 @resolver1.opendns.com myip.opendns.com +short
    94.31.113.244
    
    C:\>curl -s --ipv4 ifconfig.me
    94.31.113.244

    Der Vorteil von 'curl' ist, dass dieses Tool schon eine Weile Bestandteil von Windows ist. Möchte man hingegen 'dig' verwenden, das zudem ja auch eine deutlich bessere Alternative zum Windows-Werkzeug 'nslookup' darstelllt, muss man sich dieses Tool allerdings erst beschaffen - eine relativ einfache Möglichkeit, die ich verwendet habe, beschreibe ich unten.

    Als Ablageort für Tools und Skripte verwende ich einen Ordner C:\CMD, den ich auch in den System-Suchpfad (PATH-Variable) aufnehme (Erweiterte Systemeinstellungen | TAB Erweitert | Umgebungsvariablen | Systemvariablen | Variable "Path" bearbeiten | C:\CMD via "Neu" hinzufügen), damit die Tools auch ohne Pfadangabe gefunden werden.

    Dort habe ich also ein Skript namens "getmycgnat.cmd" mit folgendem Inhalt erstellt:

    Dazu folgende Hinweise für individuelle Anpassungen:

    • Name und Ort der Log-Datei (hier D:\Daten\Log\CGNAT.log) können natürlich beliebig individuell festgelegt werden.
    • Das Skript verwendet 'dig'. Wer 'curl' verwenden möchte, muss in der for-Schleife statt 'dig -4 @resolver1.opendns.com myip.opendns.com +short' das Kommando 'curl -s --ipv4 ifconfig.me' verwenden.
    • Das Skript ermittelt die aktuelle CGNAT-Adresse alle 3600s. Wer andere Zeitabstände wünscht, kann dies durch entsprechende Modifikation von timeout 3600 anpassen.

    Damit das Skript bei Rechnerstart und unabhängig von einem Benutzer-Login startet, habe ich einen Task in der Windows-"Aufgabenplanung" wie folgt erstellt:

    • TAB "Allgemein": Name: GETMYCGNAT; Benutzerkonto: SYSTEM; Sicherheitsoptionen: "Unabhängig von der Benutzeranmeldung ausführen"
    • TAB "Trigger": Trigger: "Beim Start" | Details: "Beim Systemstart"
    • TAB "Aktionen": Aktion: "Programm starten" | Details: "C:\CMD\getmycgnat.cmd"
    • TAB "Bedingungen": Energie: "Aufgabe nur starten, falls Computer im Netzbetrieb ausgeführt wird"
    • TAB "Einstellungen": Ausführung der Aufgabe bei Bedarf zulassen.

    Hier noch ein einfacher Weg, um an ein 'dig' für Windows heranzukommen:

    Unter https://downloads.isc.org/isc/bind9/ kann man für die letzte Version mit Windows-Unterstützung V.9.17.15 das "Windows Non-Debug Build" BIND9.17.15.x64.zip (Direktlink) herunterladen. Aus den ZIP-Archiv einfach das Tool 'dig.exe' und alle DLL-Dateien in einem gemeinsamen Ordner kopieren, zweckmäßigerweise in einen Ordner im System-Suchpfad, in meinem Fall also C:\CMD.

    Man muss nicht alle DLL-Dateien kopieren: Wenn man erst Mal nur dig.exe kopiert und aufruft, meckert es aber jede fehlende DLL an, diese kann man dann solange nachkopieren, bis dig.exe zufrieden ist (in dieser Version sind es insgesamt 11 DLL-Dateien, die mit kopiert werden müssen).

    4 Mal editiert, zuletzt von ::1 (21. Juli 2025 um 07:25)

  • Der Vorteil von 'curl' ist, dass dieses Tool schon eine Weile Bestandteil von Windows ist.

    Es sei mir die Anmerkung gestattet, das sowohl curl, als auch wget unter Windows (nicht das Subsystem for Linux) lediglich ein Alias auf das Powershellkommando:

    Invoke-WebRequest

    darstellen.

  • Ich finde aber der optimale Standort ist der Router, der weis so etwas doch immer als erster. ;)
    Aber tatsächlich gibt es da nur selten Logs/Listen.
    Ich hatte mich geärgert, dass ich diese Daten bei meinem Router (Unifi UDM SE) nur "unter der Haube" gefunden hatte.
    Bis ich eher aus Spieltrieb das Modul TALK (SIP-Telefonie) installiert habe. Da gibt es die Liste. Warum nicht auch in der Network-Oberfläche???
    Als Info für Unifi-Nutzer.

    Hier sieht man schön meine tägliche Zwangstrennung um 03:00.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Es sei mir die Anmerkung gestattet, das sowohl curl, als auch wget unter Windows (nicht das Subsystem for Linux) lediglich ein Alias auf das Powershellkommando:

    Invoke-WebRequest

    darstellen.

    Wohl "Jein", siehe https://www.andysblog.de/windows-curl-c…url-for-windows

    Da mein Skript in einer CMD-Shell läuft, kommt hier tatsächlich die "curl.exe" zum Einsatz, nicht jedoch das Cmdlet "Invoke-WebRequest".

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Der bekommt an einem Internet-Anschluss mit CGNAT doch aber auch nicht die Änderung der CGNAT-Adresse mit!

    Na ja, bei einem reinen CGNAT(IPv4) ohne IPv6 wird es sowieso schwierig etwas mit einer Namensauflösung anzufangen. Wenn man nicht von innen einen Tunnel aufbaut zu einem fixen Punkt im Netz, wird ein direkter Zugriff von außen unmöglich. Da sind reichlich Klimmzüge notwendig. ;)

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Während andere Systeme seit Jahren/Jahrzehnten richtige Shells hatten, gab es immer nur Schmerz auf Windows mit der cmd.

    Der BASIC-Interpreter auf dem C64 hat auch immer seinen Dienst getan.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Ich zitiere mal das, was ein Kollege vor einigen Jahren von einer SAP-Schulung mitgebracht hat: "Windows-Server ist erst mit Einführung der Powershell ein ernstzunehmendes Betriebssystem geworden."

    Es gibt keine gute, richtige oder falsche Shells. Es kommt immer auf den jeweiligen Einsatzzweck an. Windows *.bat oder *.cmd sind Dateien für die Batchverarbeitung. Um Anwendungen (*.exe oder *.com) automatisiert ausführen zu können. Shells bieten deutlich mehr interne Funktionen als die Batchprozessoren (command.com).

    Allerdings integriert die Powershell ganz viele Funktionen des Windows OS und ab der Version 7 ist die Powershell auch plattformübergreifend für Windows und Linux zu nutzen. Freilich gibt es da einen Bruch zwischen Version 5 und 7. In Version 5 könnte noch der Windows Task-Scheduler (Aufgabenplanung) gesteuert werden. Diese integrierte Funktionalität ist in Powershell 7 weggefallen. Allerdings gibt es wie in Perl oder Python Repositories aus denen man die fehlenden Commandlets nachladen kann.

    Sollte ich wieder ein Linux-Desktop nutzen, dann wird auf alle Fälle dort auch eine Powershell zu finden sein bzw. von mir installiert werden.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.