Mehrere Probleme überlagern sich. Schrittweise Lösung notwendig

IPv64.net - Services
1

Zuerst einmal ein Hallo in die Runde.

Ich hoffe, hier hat jemand ein ähnliches Problem schon gelöst und kann mir helfen.

Die Aufgabenstellung …
Ich möchte per Fernzugriff auf einen Rechner, der unter RDP erreichbar ist.
Der „Rechner“ ist eine VM, deren Harddisk auf „Non Persistent“ gesetzt ist. Diese VM steuert eine CNC Fräse an einem Standort, der ca. 1900 km entfernt ist. Bisher habe ich mit NOIP und dem DUC Client aus einem IPv4 Netz gut darauf zugreifen können.
Neuerdings steht der Zielrechner aber hinter einem Kabel-TV-Vodafone Anschluss, der über DS-Lite ausschließlich mit IPv6 ansprechbar ist. Und da fängt mein Problem an.

Zuerst kann ich aus meinem eigenen Netz (Auch Vodafone, aber Glasfaser im Unternehmen) nur über einige wenige Ports nach außen kommunizieren. Ich verwende Port 443.
Bislang wunderbar möglich, mit IPv4 Auflösung und NAT bezw. Portfowarding am Zielrechner von PORT 443 auf 3389 recht einfach.
Die Sicherheit auf dem Zielrechner ist kein Problem, da Quasi „unzerstörbar“ (Non Persistent HDD).

Innerhalb meines eigenen Unternehmensnetzwerkes habe ich keine IPV6 DNS Auflösung. Nur am Übergang zum ISP gibt es eine 4to6 und 6to4 Schnittstelle. Wenn ich also eine IPv6 Adresse für die RDP Verbindung eingebe, komme ich nicht raus. Da kommt IPV64 ins Spiel, da ich dann eine klare DNS Auflösung erhalte. „meinekiste.ipv64.de“ → 2002:5365:xxxx:xxxx:xxxx:xxxx.etc."

Manuell funktioniert das. Das bedeutet, wenn ich den Mitarbeiter an der VM-CNC Fräse am Zielort bitte, die Seite von IPv64 aufzurufen und neben dem Domainnamen das „Anker“ Zeichen anzuklicken, dann erhält er die korrekte IPv6 Adresse. Allerdings NUR DIE TEMPORÄRE IPv6 des Zielrechners. Die Portweiterleitung auf seiner „FRITZ!BOX 6690 Cable“ verweist allerdings auf die GLOBALE IPv6 Adresse. Das ist Problem Nummer 1.

Wie sorge ich dafür, dass die Portweiterleitung am Zielanschluss an die Temporäre IPv6 gerichtet ist ? ich habe bisher noch keinen Weg gefunden.
Oder im Umkehrschluss … Wie bekomme ich IPv64.net dazu beim Update die Globale, statt det Temporären IPv6 Adresse an den Präfix des Netzwerks anzuhängen ? Beides würde dieses Problem lösen.

Ich kann nur zugreifen, wenn ich die Portweiterleitung an die Globale IPv6 Binde (Ich rede immer noch von der VM Maschine) und mich mit meinem Computer mit meinem Mobilfunkgerät verbinde (APN über IPV4 und IPv6). Da ich die komplette IPv6 Adresse des Zielrechners eingeben muss.

IPv64.net löst nämlich auch nur die Temporären IPv6 Adressen auf. Das ist Problem 2.
(wie oben schon erwähnt)

Problem 3 besteht darin, dass ich noch keinen Weg gefunden habe, wie ich der Fritzbox am Zielrechner (über die FRITZ!NET Fernwartung) beibringen konnte die IPv6 der VM Maschine mit meiner Domain zu koppeln. Der IPv6 Präfix wird zwar korrekt übernommen, aber der Dynamische Teil der Temporären IPv6 des Zielrechners wird nicht richtig angefügt. Nur beim Manuellen Aktualisieren über die IPv64.net Webseite. Nutze ich die FRITZ!BOX, dann wird die Adresse der FRITZ!BOX angefügt.

Brauche ich auf dem Zielrechner (der VM) einen eigenen Update Client, wie bei NOIP mit dem DUC), der die IPv6 Zusammensetzt ? Ich frage mich nämlich, woher die Fritzbox wissen soll, welche Adresse der Zielrechner gerade hat. Ich kann die Updatefunktion nämlich im DYNDNS Dialog der Box nicht an einen Rechner binden. Und der IPv6 Suffix ändert sich gelegentlich.

Ich hoffe auf ein paar sinnvolle Ideen um Schritt für Schritt die Probleme zu beseitigen.
Danke !

(Und bitte keine Ratschläge zu RDP und Port 443) Das Konstrukt läuft seit fast 15 Jahren problemlos. Und selbst ein „Totalschaden der VM hat uns vor einigen Jahren nur 2 Stunden Backup Wiederherstellung gekostet“. Ich bin mir des Risikos bewusst und alles ist so sicher, wie es sein muss.)

Ich bin für jeden Tipp dankbar.

Hans

2

Lies mal hier, Beitrag 50. Du brauchst den dynamischen IPv6-Prefix deines Zielnetzes und den festen Interface-Identifier des Endgeräts. Dann löst der Name auf die globale IPv6 deines Endgeräts auf.

1 „Gefällt mir“
3

Gehen wir erst einmal das erste Problem an. Unterschiedliche IPv6-Adresse am WAN und im LAN der 6690 Cable.

  1. Prüfe (oder besser lass prüfen) wie die Konfiguration des DHCPv6-Server im Heimnetz der 6690 Cable mit CNC Fräse aussieht. Dieser sollte auf DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen konfiguriert sein.
  2. Prüfe (oder besser lass prüfen) wie die CNC Fräse ihre IPv6-Adresse bezieht. Die CNC Fräse sollte die IPv6-Adresse nicht per SLAAC, sonder per DHCPv6-Client beziehen.

Beides ist Voraussetzung für das weitere Vorgehen. Kann die CNC Fräse nur SLAAC wird es schwierig. Da ich keine Ahnung habe auf welchem Betriebssystem die CNC Fräse aufsetzt muss du das vorher abklären.

1 „Gefällt mir“
4

Vielen Dank für die schon zahlreichen „Begriffe“ und Stichworte. Ich werde mich Stück für Stück dran machen, die Punkte zu prüfen und mich weiter einzuarbeiten. Mir ist auch schon das CDN -Portfowarding genannt worden, dass die Problematik der Erreichbarkeit aus meinem eigenen Netz minimieren könnte.

Ich denke ich habe eine „Kleinigkeit vergessen“. Die CNC-Fräse und die damit verbundene Software läuft unter Windows XP 32 Bit ! Die Hardware der Maschine ist eine komplette Eigenkonstruktion mit 8 Steppern und einer Drehachse und in der Lage räumlich mit einem heißen Draht große Skulpturen und Formen aus Styrodur zu schneiden. Arbeitsvolumen 2 x 2 x2m. (Für Werbung, Messestände, Theater, Filmsets, … etc.)

Ein Portieren der Software ist so ziemlich unmöglich. Aber eventuell muss ich darüber nachdenken den Host auf dem die VM Läuft (Windows 10) per Wireguard oder VPN anzubinden. Das bringt zwar andere Probleme, aber die erscheinen mir fast einfacher zu lösen als mich mit dem XP zu verbinden.

Ich bin dran und melde mich, wenn ich mehr weiß.

5

Dir ist klar, dass das Betriebssystem tot ist, sprich EOL?

Die KI sagt: Windows XP enthält keinen DHCPv6-Client als integrierten Teil des Betriebssystems. Um DHCPv6-Unterstützung in Windows XP zu ermöglichen, müssen zusätzliche Softwarepakete wie Dibbler DHCPv6 installiert werden

Da musste selbst ich die KI befragen. Als ich das letzte Mal XP genutzt habe, war gefühlt im vergangenen Jahrhundert und IPv6 war da noch kein Thema.

6

Windows 10 wird im Oktober 2025 auch sein EOL erreichen. Wenn dann steig gleich auf Windows 11 um.

7

Aber auch dafür muss das Problem gelöst werden, dass die CNC-Fräse zuverlässig per IPv6 erreichbar sein muss. Auch das CDN-Portfowarding zeigt ja auf die IPv6-Adresse der CNC-Fräse. Daher muss genau diese IPv6-Adresse der CNC-Fräse dafür aktualisiert werden, nachdem am Kabel-TV-Vodafone Anschluss eine Zwangstrennung stattgefunden hat.

Es gibt bei Kabel-TV von Vodafone meines WIssens nach aber die Möglichkeit auf Businesstarife zu wechseln, die dann nur eine IPv4-Adresse bieten.

Bei der Komplexität deiner Probleme mit veralteter Software, wäre das wohl die besten Lösung, und die paar Euro, die das im Zweifel mehr im Monat kostet, verschwindend im Vergleich zu allem anderen.

8

Vielen Dank „Eagle“ für diesen Rat (WIN 11) , … hab’ ich dem Kollegen vor Ort auch schon gesteckt. Zum Glück nicht meine Baustelle. Auch der Businesstarif ist ein guter Tipp. Wir waren nur alle etwas überrascht, als der Vermieter der Halle uns von der Änderung des Anschlusses benachrichtigt hat. In der Türkei kann es einem schon mal passieren, dass man ohne Ankündigung einen neuen Netzbetreiber hat. Und Windows XP kann IPv6 ! Und mit VM-Ware ESXi sogar mit echter Hardware und einigermaßen aktuellen Treibern.

Die Fräse ist jetzt erreichbar. Das IPv6 Protokoll in XP reicht aus, das Bridging vom Host in die VM läuft, das IPv6 Updating hat mit dem Post von Benares auch gut geklappt.

Erst die Basisadresse der F-Box anlegen, dann einen weiteren Eintrag für den Zielrechner als AAAA mit Prefix anlegen. (Bei mir mit dem Computernamen im „dahinter liegenden“ Netz → „5310“), dann die letzten 4 Ziffernblöcke der Zieladresse (INTERFACE-ID) angeben und dabei auf das Format achten „::6743:1276:e4f6:276a“.
Diese dann in der F-Box als Update URL Eintragen.
Das steht zwar alles klar auf der Seite, aber für Ungeübte und Anfänger erschließt sich das nicht unbedingt sofort. Für mich ist IPv6 auch noch relativ neu.

Damit sind zwei Probleme gelöst: Portweiterleitung auf der F-Box und IP Update des Zielrechners laufen auf die gleiche IP.

Jetzt bleibt mir nur noch das Problem der Erreichbarkeit aus meinem „restriktiven Netz“.

Ich schaue mir morgen das CDN mal an und teste ob ich damit klarkomme.
Ansonsten muss halt etwas mehr Datenvolumen aufs Handy. Ich brauche die Verbindung ohnehin nur ein paar Mal im Monat bei Problemen.

Für mich war der Problemlöser der „Screenhot“ von Benares. Leider fehlten ein paar „Ränder“, weshalb man etwas raten musste.

Vielen Dank für den schnellen Support ! Wenn ich weiter bin, schreibe ich das hier rein.

9

Freut mich. Was meinst du mit „fehlten ein paar Ränder“?
Wichtig ist halt letztendlich, dass der Name auf die globale IPv6 des Ziels auflöst (nslookup …). Das ist schon alles.

10

@Hanswinkelser nur mal als Erläuterung, warum ich wollte, dass du die Konfiguration des DHCPv6-Server im Heimnetz der 6690 Cable mit CNC Fräse prüfen lässt und auch verifizierst, dass das die CNC Fräse ihre IPv6-Adresse nicht per SLAAC sondern per DHCPv6-Client bezieht.

Bei sehr vielen Betriebssystem wird per default die IPv6-Adresse per SLAAC und nicht per DHCPv6-Client bezogen. Manche Betriebssysteme (z.B. Chrome OS, Android) können sogar nur SLAAC und kein DHCPv6. Für sich genommen wäre das noch kein Problem.

Zum Problem wird aber, das in Kombination mit SLAAC in aller Regel per default auch die Ipv6- Privacy Extensions aktiv sind. Die Privacy Extensions heben aber die Kopplung von Interface Identifier und MAC-Adresse auf und erzeugen mehr oder weniger zufällige Interface Identifier. Ist das der Fall, dann würde das was du nun machst

eben nicht funktionieren, denn genau diese Kopplung an die INTERFACE-ID („::6743:1276:e4f6:276a“) heben die Privacy Extensions ja auf.

Der sicherste und zuverlässigste Weg das zu verhindern ist die Verwendung von DHCPv6 statt SLAAC.

11

@The_eagle, aber ist es nicht so, dass eine IPv6 mit Privacy Extension immer eine weitere IPv6 ist? So kenne ich es bei meinen Geräten.

Hier mal als Beispiel ein „ip a“ von einem NAS von mir

    inet 192.168.0.81/24 brd 192.168.0.255 scope global dynamic eth0
       valid_lft 616987sec preferred_lft 616987sec
    inet6 2001:16b8:bb0c:cc00:6e1f:f7ff:fe3f:c4cd/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 7049sec preferred_lft 3449sec
    inet6 2001:16b8:bb0c:cc00:bb6:ebc5:de6c:9538/64 scope global dynamic mngtmpaddr stable-privacy
       valid_lft 7049sec preferred_lft 3449sec

Die 2. IPv6 ist die mit Privacy Extension (stable-privacy) für ausgehende Verbindungen. Bei Windows ist es ebenso (=„Temporäre IPv6-Adresse“). Ein Gerät mit nur einer IPv6 mit Privacy Extension ist mir noch nicht untergekommen. Man muss halt schauen, dass man den richtigen Interface Identifier nimmt.

12

Man hat bei SLAAC und Privacy Extension immer mehrer IPv6-Adressen. Oft mehr als zwei. Die inzwischen abgelaufenen sind mit ifconfig in meinem Linux-Notebook, mit dem ich dies her gerade schreibe auch noch sichtbar.

Davon ist allerdings KEINE einzige aus der EUI-64 MAC der verwendeten Netzwerkinterfaces (hier jetzt WIFI) abgeleitet worden, was der korrekte Weg wäre. Beispiel:
aus der EUI-64 MAC 11:22:33:44:55:66 würde korrekt die Interface-ID 13:22:33:FF:FE:44:55:66 werden müssen. Dem ist mit SLAAC und aktiven Privacy Extension auf meinem Notebook nicht so. Auf einem Linux-Server mit DHCPv6 statt SLAAC wird aber aus einer EUI-64 MAC 11:22:33:44:55:66 dann tatsächlich die Interface-ID 13:22:33:FF:FE:44:55:66.

13

Nach Auskunft des Kollegen ist eine Realtek Karte verbaut (weil bis heute aktuelle XP Treiber), dazu ist der IPv6 Windows XP Stack installiert. Die Adressen werden „natürlich“ per SLAAC bezogen und erlauben die vollständige Identifizierung des Rechners mit der MAC Adresse im Internet. Also KEINE Privacy. Ein DHCPv6 existiert unter Windows XP nicht. Und die späteren Patches und Hilfsmittel um das nachzurüsten funktionieren nicht wie gewünscht. (Kollidieren mit etwas in den VM-Ware Tools). Um das zu umgehen wurde auch auf ESXi umgestellt und die Karte per PCI Exception direkt für den Client verfügbar gemacht. Das hat aber leider auch nichts gebracht.

Der Rechner wäre damit immer ein „attraktives Ziel“, … wenn … Da aber durch die VM alles geblockt wird, was die Virtuelle Maschine verlässt und das Bridging der VM rein auf einen Port (443) beschränkt ist, ist das Risiko überschaubar.

Damit muss man leben, wenn man eine alte Maschine irgendwie erreichbar macht. Zur Spam Mailing- oder DDoS Schleuder wird sie wohl nicht mutieren. Es ist alles deinstalliert oder deaktiviert, was sich irgendwie missbrauchen lässt.

14

Hallo @Hanswinkelser zu den spezifischen Konfigurationsoptionen etc. hinsichtlich Windows XP kann und werde ich nichts sagen. Das ich damit das letzte Mal etwas zu tun hatte liegt mindestens 15 Jahre zurück (so um 2010).

Generell kann ich nur zu IPv6, dem Unterschied SLAAC und DHCPv6 und zu den Privacy Extension eine Beitrag leisten. Die Privacy Extension waren nicht von Anfang an Teil von IPv6. Sie wurden nachträglich ergänzt.

Der Hintergrund für die Ergänzung ist schlicht und einfach Datenschutz, bzw. Schutz der Privatsphäre. Da sich aus der MAC-Adresse die Interface-ID ableiten lässt, geht das natürlich auch umgekehrt. Bei IPv4 war das kein Problem, denn wenn man aus einem Firmennetz, einer heimischen Netzwerk oder sonst wo hinter einem Router oder einer Firewall per IPv4 ins Internet geht, ist nach außen hin eh immer nur die WAN-IPv-Adresse des Routers oder der Firewall sichtbar. Bei IPv6 ist das nun anders. Im Regelfall hat bei IPv6 jedes Gerät eine eigene öffentlich sichtbare IPv6-Adresse, die auch für die Betreiber der www-Seite die man gerade aufruft sichtbar ist. Damit kann man dann jederzeit wiedererkannt und die Aktivitäten im Internet können verfolgt werden.

Da kommen nun die später zu IPv6 ergänzten Privacy Extension ins Spiel. Durch Entkopplung von MAC und Interface-ID und darauf basierender IPv6-Adresse, die täglich wechselt, wird das nun wieder verunmöglicht, ähnlich wie bei IPv4.

Bei einem Server aber, wie z.B. einem Web-Server, den man zuverlässig aus dem Internet erreichbar machen will, ist das aber wiederum kontraproduktiv. Ein Server ist ja anhand seine Adresse, wie www.beispielserver.de ohnehin immer erreichbar und auffindbar. Und die Zuordnung einer IPv6-Adresse zu diesem Server soll auch bei Zwangstrennung und daher täglich neuem IPv6-Prefix sicher gewährleistet sein. Daher sind die Privacy Extensions in so einer Konfiguration nicht erwünscht und sogar überflüssig, denn via www.beispielserver.de ist der Server eh eindeutig zu identifizieren.

Für dich und die Erreichbarkeit der CNC Fräse wäre es aus meiner Sicht (so weit ich das aus der Ferne beurteilen kann) vermutlich eh besser ihr würdet ein VPN benutzen. Z.B. Wireguard oder OpenVPN. Dann müsste die Windows XP-CNC Fräse nicht mehr direlt aus dem Internet erreichbar sein, sondern wäre es nur noch via eines Wireguard- oder OpenVPN-Tunnels.

Für Wireguard spricht, dass man Wireguard relativ einfach konfigurieren kann und Wireguard es auch gestatte Tunnel zu erstellen, die intern ausschließlich IPv4 transportieren, extern aber via IPv6 die Verbindung zwischen den Standorten aufbauen. Zudem ist Wireguard im Gegensatz zu OpenVPN in den neueren Betriebssystemversion der FritzBoxen integriert. Zusätzliche Hardware also nicht nötig.