Windows-VPN weist 255.255.255.255: ass d’Mask falsch?

Den Tunnel verbënnt, Dir öffnet d’Adapterdetailer, an d’Mask weist 255.255.255.255. Verglach mat der 255.255.255.0 vum Büro-LAN gesäit dat futti aus, an do fänkt de Feeler meeschtens un. Bei enger Punkt-zu-Punkt-Verbindung ass eng Hostmask déi richteg Beschreiwung vum lokalen Endpunkt, an déi entfernt Netzwierker komme als Routen un statt als ugeschlossene Subnetz. D’Prozedur hei drënner trennt déi zwou Froen, sou datt Dir keen funktionéierende DHCP-Beräich nei opbaut just fir en ugewiesene Wäert ze korrigéieren.

Eng Punkt-zu-Punkt-Verbindung ass keen Ethernet-Segment

En Ethernet-Interface brauch eng Subnetzmaske, well all Adress an deem Beräich potenziell um selwechte Kabel erreechbar ass. En Tunnel am PPP-Stil huet genau ee Peer um aneren Enn. Et gëtt keng Broadcast-Domän, keen ARP an kee Grond firwat d’lokal Adress e Beräich soll beschreiwen.

D’Adressverhandlung fir dee Modell ass an RFC 1332 definéiert, déi beschreift wéi sech déi zwou Säiten iwwer hir Adressen eeneg ginn. Wat se net mécht, ass dem Client d’Büro-LAN als direkt ugeschlossene Netzwierk ze ginn. De Client léiert wou d’Büro ass, andeems en Routen iwwer d’Verbindung installéiert, an déi Routen entscheeden tatsächlech d’Erreechbarkeet.

Dat heescht net, datt all Mask déi Dir gesitt korrekt ass. En falsch konfiguréierte Client kann och komesch Adresséierung produzéieren. De Punkt ass méi enk: eng Hostmask op dësem Adaptertyp ass ze erwaarden, also ass se fir sech geholl kee Beweis fir e Feeler.

Schrëtt 1: bestätegt den Interfacemodell

Kuckt wat den Adapter ass ier Dir beurteelt wat en seet. D’Beschreiwungszeechenket identifizéiert den Treiber, an d’Präfixlängt vun der zougewisener Adress bestätegt wat de Client ausgehandelt huet:

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

Den drëtten Kommando ass deen, deen déi meescht Diskussiounen entscheet. Eng niddreg maximal Transmissiounseenheet ass typesch fir eng gekapselt Verbindung, wärend en Ethernet-änleche Wäert op en anert virtuelle Adaptermodell hindeit. Wann d’Beschreiwung en PPP- oder RAS-Treiber nennt an de Präfix 32 ass, gesitt Dir genau deen uewe beschriwwenen Design a kënnt ophale sech Suergen iwwer d’Mask ze maachen.

Schrëtt 2: liest d’Route fir déi feelend Destinatioun

Erreechbarkeet gëtt pro Destinatioun entscheet, an eng eenzeg ugeschlossen Interface seet Iech do driwwer näischt. Frot d’Routentabel direkt no der Adress déi de Benotzer tatsächlech wëll erreechen:

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

Find-NetRoute ass déi direkt Äntwert: se nennt d’Interface an d’Quelladress déi de System fir déi Destinatioun géif benotzen. Wa se den Tunnel zréckgëtt, geet den Traffic zu deem Host duerch den Tunnel an d’Mask war ni de Problem.

Wa se den physischen Adapter zréckgëtt, vergläicht déi zwou Kandidaterouten an hir Metriken. Eng méi spezifesch lokal Route, en Iwwerrescht vun engem anere Client oder eng méi niddreg Metrik um physische Wee gewannen all géint eng breet Tunnelroute. D’siichtbart Resultat ass eng Ressource déi net erreechbar ass, während alles anescht funktionéiert. Méi laang Präfixen gewannen ëmmer, sou datt de Gewënner dacks eng Hostroute ass déi een viru Méint bäigefüügt an vergiess huet.

Kontrolléiert och béid Richtungen während Dir hei sidd. Eng Route op d’Serversäit ass néideg awer net genuch, well d’Äntwert och duerch den Tunnel zréck muss. Wann een internen Host funktionéiert an en aneren net, läit den Ënnerscheed meeschtens an dëser Tabell an net an der Adapterkonfiguratioun.

Schrëtt 3: trennt d’Nammopléisung vum Servicezougang

Eng Applikatioun déi eng Deele net opmécht, kann an enger vun zwou ganz ënnerschiddleche Phasen feelen. Léist den Numm op an erreech dann d’Adress. Wa fir d’éischt feelt an dat zweet funktionéiert, ass den Tunnel a just an de Resolver net:

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

En erfollegräichen Adresstest plus en feelgeschloenen Nummtest lokaliséiert de Problem an der Opléisung, an den zweeten Kommando weist ob d’Tunnelinterface iwwerhaapt e Server kritt huet. Vill Clienten schécken DNS als Deel vun der Tunnelkonfiguratioun, an e Profil deen déi geschéckt Optiounen ignoréiert, léisst d’Maschinn en Resolver benotzen deen d’privat Zone net gesäit.

Behandelt eng funktionéierend Adress net als déi permanent Léisung. Verbannen iwwer d’Adress ëmgeet d’Nammopléisung a kann d’Serveridentitéitskontroll ënnergruewen déi d’Applikatioun soss maache géif. Dat ass eng Sécherheetsregressioun verkleet als Workaround. Benotzt se fir de Feeler ze lokaliséieren, a reparéiert duerno d’Opléisung.

Zeréckbau: baut DHCP net nei op wéinst engem gewisenen Wäert

Wann Dir schonn ugefaang hutt den Adressservice ze änneren, stoppt a kontrolléiert ob eppes vun deem wat Dir geännert hutt dréit. E Beräich nei ze erstellen, Leases nei auszeginn oder de Pool ze verréckelen ännert Zoustand vun deem aner Clienten ofhänken, an näischt dovun ass duerch eng Hostmask op engem Punkt-zu-Punkt-Adapter gerechtfäerdegt.

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

Fëllt dës dräi no all geriichten Ännerung aus a vergläicht mam Laf virdrun. D’nëtzlech Resultat ass en dokumentéierte Wee zu der Ressource, net en Adapter deem seng Mask dem Büro-LAN gläicht.

Schreift dann op wat d’Mask tatsächlech bedeit huet, well déi nächst Persoun dee selwechten Dialog opmécht an zum selwechten falsche Schluss kënnt. Een Saz an de Profilnotizen, datt den Tunnel Punkt-zu-Punkt ass an d’entfernt Subnetzer als Routen ukommen, spuert déi ganz Enquête déi nächst Kéier.