Eine korrekt funktionierende DNS Auflösung ist für die Kommunikation in einem Netzwerk essentiell.
Ein überwiegender Teil der Probleme im Netzwerk lassen sich auf Fehler im DNS zurückführen.
Aus dem Grund sollte das auch über per VPN angebundene Netze funktionieren. Eine Kommunikation über IP Adressen statt über Hostnamen sollte nicht mehr genutzt werden.
Spätestens beim Zugriff auf Web-Dienste wird es Probleme mit Zertifikaten geben, also sollte das keine Option mehr sein.
Auf die Konfiguration des VPN Servers will ich hier gar nicht im Detail eingehen, wichtig ist, das dieser dem Client auch den DNS Suffix (z.B. intern.itprofi.network) und natürlich den oder die DNS Server der Domain übermittelt. So weiß dieser, welchen DNS Server er über welche Schnittstelle für die jeweilige Domain anfragen muss.
Ist alles richtig konfiguriert sollten keine Probleme auftreten, bei der Nutzung von Windows 10 oder 11 als Client Betriebssystem war das bei mir aber sehr oft der Fall. Erstaunlicherweise funktionierte es in bestimmten Konstellationen aber auf dem selben System, weshalb ich auf Fehlersuche ging.
Als Ergebnis stellte sich heraus, das sowohl auf einem Windows 10 als auch auf einem Windows 11 System die DNS Abfrage fehlschlägt, wenn der Rechner über LAN verbunden ist, allerdings funktioniert, wenn dieser über W-LAN mit dem Netzwerk kommuniziert. Über LAN wurde nachweislich der interne DNS Server angefragt, über W-LAN dagegen der richtige, über den VPN Tunnel erreichbare.
Das brachte mich zu einer verrückten These:
Das Betriebssystem geht die Netzwerkadapter der Reihe nach durch, den ersten erreichbaren DNS Server fragt es an.
Ein ipconfig /all zeigt, dass in der Liste zuerst die Ethernetadapter, dann die vom SSL VPN genutzten TUN Adapter und zum Schluss die W-LAN Adapter kommen.
Dass das Phänomen auf 2 Systemen gleich aufgetreten ist würde ich noch nicht als Beweis werten, vielleicht hat ja schon jemand ähnliche Erfahrungen damit gemacht?
Bei mir hatte ich den Vergleich mit 2 Geräten:
Laptop und PC je mit gleichem Betriebssystem (Win10Pro-64bit, gleicher Updatestand) und Surfshark Starter VPN App mit wireguard-Protokoll.
Beim PC funktionierte wireguard nicht, aber OpenVPN-UDP, beim Laptop (auch per LAN am gleichen Router (FritzBox7490) mit deaktiviertem WLAN-Adapter) funktionierte auf Anhieb beides gut.
Ich habe durch ipconfig /all herausgefunden, dass der PC den Windows-Dienst „Routing und RAS“ laufend hatte, was sich wohl auf irgendeine interne Routingtabelle auswirkt, der Laptop hatte dies deaktiviert.
Nach Deaktivierung dieses Dienstes auf dem PC lief dieser ebenfalls mit dem wireguard-Protokoll direkt (mit guten speed-Raten). Im laufenden Betrieb stellte ich den wireguard-Tunneladapter und den Ethermet-Adapter um, sodass IPv4 als auch IPv6 aktiv sind, und beim IP4u.6-Test lief während VPN auch beides.
Fazit: dieses Problem einer „falschen“ PC-Konfiguration (bzw. Windows-Dienste-Konfiguration) bzgl. dieses Dientes scheint kaum einer auf dem Schirm zu haben. Ob „Routing und RAS“ standardmäßig (= nach Installation des Betriebssystems) deaktiviert ist, kann ich nicht sagen.
Auf jeden Fall hat es kaum eine Hotline der VPN-Anbieter auf dem Schirm, dass dies das wireguard-Problem löst.
Da dieses Problem beim OpenVPN-Protokoll nicht der Fall zu sein scheint, muss es irgendein interner Sachverhalt sein, der die wireguard-Implementierung in Windows betrifft (wofür ich kein Experte bin).
Ich hoffe, hiermit einigen VPB-Anwendern diesbezüglich geholfen zu haben.