Windows-VPN zeigt 255.255.255.255: Ist die Maske falsch?

Der Tunnel baut auf, Sie öffnen die Adapterdetails, und die Maske zeigt 255.255.255.255. Verglichen mit der 255.255.255.0 des Büro-LANs wirkt das kaputt, und genau dort beginnt meist der Fehler. Bei einer Punkt-zu-Punkt-Verbindung ist eine Hostmaske die korrekte Beschreibung des lokalen Endpunkts, und die entfernten Netze kommen als Routen an statt als angeschlossenes Subnetz. Die folgende Anleitung trennt die beiden Fragen, damit Sie keinen funktionierenden DHCP-Bereich neu aufbauen, nur um einen angezeigten Wert zu korrigieren.

Eine Punkt-zu-Punkt-Verbindung ist kein Ethernet-Segment

Eine Ethernet-Schnittstelle braucht eine Subnetzmaske, weil jede Adresse in diesem Bereich potenziell auf demselben Kabel erreichbar ist. Ein Tunnel im PPP-Stil hat genau einen Peer am anderen Ende. Es gibt keine Broadcast-Domäne, kein ARP und keinen Grund, warum die lokale Adresse einen Bereich beschreiben sollte.

Die Adressverhandlung für dieses Modell ist in RFC 1332 definiert, die beschreibt, wie sich beide Enden auf ihre Adressen einigen. Was sie nicht tut, ist dem Client das Büro-LAN als direkt angeschlossenes Netz zu übergeben. Der Client lernt, wo das Büro liegt, indem er Routen über die Verbindung installiert, und diese Routen entscheiden tatsächlich über die Erreichbarkeit.

Das heißt nicht, dass jede Maske, die Sie sehen, korrekt ist. Ein falsch konfigurierter Client kann ebenfalls seltsame Adressierung erzeugen. Der Punkt ist enger: Eine Hostmaske auf diesem Adaptertyp ist zu erwarten, also ist sie für sich genommen kein Beweis für einen Fehler.

Schritt 1: Bestätigen Sie das Schnittstellenmodell

Schauen Sie, was der Adapter ist, bevor Sie beurteilen, was er sagt. Die Beschreibungszeichenfolge identifiziert den Treiber, und die Präfixlänge der zugewiesenen Adresse bestätigt, was der Client ausgehandelt hat:

Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtu

Der dritte Befehl ist der, der die meisten Diskussionen beendet. Eine niedrige maximale Übertragungseinheit ist typisch für eine gekapselte Verbindung, während ein Ethernet-ähnlicher Wert auf ein anderes virtuelles Adaptermodell hindeutet. Wenn die Beschreibung einen PPP- oder RAS-Treiber nennt und das Präfix 32 ist, sehen Sie genau das oben beschriebene Design und können aufhören, sich über die Maske Sorgen zu machen.

Schritt 2: Lesen Sie die Route für das fehlschlagende Ziel

Erreichbarkeit wird pro Ziel entschieden, und eine einzelne verbundene Schnittstelle sagt Ihnen darüber nichts. Fragen Sie die Routentabelle direkt nach der Adresse, die der Benutzer tatsächlich erreichen will:

Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4

Find-NetRoute ist die direkte Antwort: Sie nennt die Schnittstelle und die Quelladresse, die das System für dieses Ziel verwenden würde. Wenn sie den Tunnel zurückgibt, läuft der Datenverkehr zu diesem Host durch den Tunnel, und die Maske war nie das Problem.

Wenn sie den physischen Adapter zurückgibt, vergleichen Sie die beiden Kandidatenrouten und ihre Metriken. Eine spezifischere lokale Route, ein übrig gebliebener Eintrag eines anderen Clients oder eine niedrigere Metrik auf dem physischen Pfad gewinnen alle gegen eine breite Tunnelroute. Das sichtbare Ergebnis ist eine Ressource, die nicht erreichbar ist, während alles andere funktioniert. Längere Präfixe gewinnen immer, daher ist der Gewinner oft eine Hostroute, die jemand vor Monaten hinzugefügt und vergessen hat.

Prüfen Sie hier auch beide Richtungen. Eine Route zur Serverseite ist notwendig, aber nicht ausreichend, denn die Antwort muss ebenfalls durch den Tunnel zurückkommen. Wenn ein interner Host funktioniert und ein anderer nicht, liegt der Unterschied meist in dieser Tabelle und nicht in der Adapterkonfiguration.

Schritt 3: Trennen Sie Namensauflösung vom Dienstzugriff

Eine Anwendung, die eine Freigabe nicht öffnet, kann an einer von zwei sehr unterschiedlichen Stellen scheitern. Lösen Sie den Namen auf und erreichen Sie dann die Adresse. Wenn das erste scheitert und das zweite funktioniert, ist der Tunnel in Ordnung und der Resolver nicht:

Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Ein erfolgreicher Adresstest plus ein fehlgeschlagener Namenstest lokalisiert das Problem in der Auflösung, und der zweite Befehl zeigt, ob die Tunnelschnittstelle überhaupt einen Server erhalten hat. Viele Clients schieben DNS als Teil der Tunnelkonfiguration, und ein Profil, das diese übertragenen Optionen ignoriert, lässt die Maschine einen Resolver verwenden, der die private Zone nicht sieht.

Behandeln Sie eine funktionierende Adresse nicht als dauerhafte Lösung. Das Verbinden per Adresse umgeht die Namensauflösung und kann die Serveridentitätsprüfung aushebeln, die die Anwendung sonst durchführen würde. Das ist eine Sicherheitsregression, die als Workaround verkleidet ist. Nutzen Sie sie, um den Fehler zu lokalisieren, und reparieren Sie dann die Auflösung.

Rückabwicklung: Bauen Sie DHCP nicht wegen eines angezeigten Werts neu auf

Wenn Sie bereits begonnen haben, den Adressdienst zu ändern, halten Sie inne und prüfen Sie, ob etwas davon tragend ist. Einen Bereich neu zu erstellen, Leases neu auszugeben oder den Pool zu verschieben ändert Zustand, von dem andere Clients abhängen, und nichts davon ist durch eine Hostmaske auf einem Punkt-zu-Punkt-Adapter gerechtfertigt.

Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445

Führen Sie diese drei nach jeder gezielten Änderung aus und vergleichen Sie mit dem Lauf davor. Das nützliche Ergebnis ist ein dokumentierter Weg zur Ressource, nicht ein Adapter, dessen Maske dem Büro-LAN ähnelt.

Schreiben Sie dann auf, was die Maske tatsächlich bedeutete, denn die nächste Person öffnet denselben Dialog und kommt zum selben falschen Schluss. Ein Satz in den Profilnotizen, dass der Tunnel Punkt-zu-Punkt ist und die entfernten Subnetze als Routen ankommen, erspart die ganze Untersuchung beim nächsten Mal.