VPN funktioniert, interne Namen nutzen falsches DNS · Linux Fix Lab

Symptome und Geltungsbereich

Öffentliche Namen werden aufgelöst, vollständig qualifizierte interne VPN-Namen scheitern.
Privater DNS-Server ist vorhanden, seine Routing-Domain fehlt aber oder wird übersteuert.

Betroffene Umgebung

NetworkManager-VPN mit systemd-resolved oder anderem Split-DNS-Plugin; einfache resolv.conf kann dieselbe Domainzuordnung nicht ausdrücken.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

Das VPN kann eine Routing-Domain auslassen, unbeabsichtigt ~. als Sammelzuordnung nutzen oder durch DNS-Prioritäten aus der Auswahl fallen.
Dem internen Server kann eine VPN-IP-Route fehlen; .local-Namen brauchen ein bewusstes Design, da resolved diese Endung gewöhnlich als Multicast-DNS behandelt.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

DNS-Server und Routing-Domains bei aktivem VPN lesen. VPN-Verbindung mit physischem Netz vergleichen, ohne Resolverzustand zu ändern.

resolvectl status

Ergebnis einordnen: ~corp.example leitet diese Endung an ihre Verbindung; die spezifischste passende Endung gewinnt. ~. ist eine Sammelzuordnung und kann andere Anfragen gewollt oder versehentlich erfassen.

Prüfschritt 2

VPN_PROFILE durch den gespeicherten VPN-Verbindungsnamen ersetzen. DNS-Richtlinien beider Familien ohne Zugangsdaten oder VPN-Aktivierung lesen.

nmcli -f ipv4.dns,ipv4.dns-search,ipv4.dns-priority,ipv4.ignore-auto-dns,ipv6.dns,ipv6.dns-search,ipv6.dns-priority connection show "VPN_PROFILE"

Ergebnis einordnen: Das aktive Resolverergebnis kann zusätzlich serverseitig übermittelte Werte enthalten. Negative DNS-Priorität kann andere Verbindungen mit höherem Zahlenwert ausschließen; vor Änderung alle aktiven Profile vergleichen.

Prüfschritt 3

DNS_IP durch die bestätigte private DNS-Serveradresse ersetzen; bei IPv6 ip -6 route get verwenden. Dies berechnet eine Route ohne Netzwerkprobe.

ip route get DNS_IP

Ergebnis einordnen: Gewähltes Gerät und Gateway sollen zum vorgesehenen VPN-Pfad passen. Korrekte Domainauswahl ersetzt keine Route, die den privaten Server außerhalb des Tunnels erreicht.

Nächste Schritte nach Befund

Vorgesehene private DNS-Domain zuordnen

Wenn die vorgegebene Routing-Domain des VPN fehlt, Profil sichern und nur diese Endung als DNS-Routing-Domain ergänzen, beispielsweise ~corp.example mit tatsächlicher Domain statt Beispiel. VPN erneut verbinden und einen internen vollständig qualifizierten Namen vergleichen.

Vorsicht: ~. nur nutzen, wenn das VPN absichtlich alle DNS-Anfragen übernimmt. Benötigte Suchdomains und verwaltete Unternehmensprofile beachten, die lokale Änderungen überschreiben können.

Wiederherstellung / Rücknahme: Gesicherte DNS-Domainliste wiederherstellen und VPN erneut verbinden, wenn öffentliche oder private Anfragen falsch geleitet werden.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

DNS-Priorität und Serverroute abstimmen

Wenn ein bestätigter Prioritätskonflikt das vorgesehene VPN-DNS ausschließt, nur dessen Profilpriorität gemäß Netzrichtlinie ändern. Wenn die Routenabfrage dagegen den Tunnel umgeht, gezielte VPN-Route zum privaten DNS-Server oder freigegebenen Subnetz korrigieren.

Vorsicht: DNS-Priorität und IP-Routenmetrik lösen verschiedene Auswahlprobleme. Nicht alle Standardrouten ändern und interne Namensabfragen nicht an öffentliche Server leiten.

Wiederherstellung / Rücknahme: Gesicherte Prioritäten und spezifische Routenliste wiederherstellen; bei Verschlechterung einer Adressfamilie VPN über funktionierenden Netzpfad erneut verbinden.