Windows VPN prikazuje 255.255.255.255: je maska napačna?
Pri tunelu od točke do točke je gostiteljska maska običajna. Potrdite model vmesnika, preberite pot za gostitelja, ki ne deluje, in ločite DNS od dostopa do storitve.
Tunel se poveže, odprete podrobnosti vmesnika in maska prikazuje 255.255.255.255. V primerjavi z 255.255.255.0 pisarniškega omrežja LAN je videti pokvarjena in prav tam se napaka običajno začne. Na povezavi od točke do točke je gostiteljska maska pravilen opis lokalnega končnega vozlišča, oddaljena omrežja pa pridejo kot poti, ne kot priključeno podomrežje. Spodnji postopek loči obe vprašanji, da ne boste znova zgradili delujočega obsega DHCP samo zaradi popravka prikazane vrednosti.
Povezava od točke do točke ni segment Ethernet
Vmesnik Ethernet potrebuje masko podomrežja, ker je vsak naslov v tem obsegu potencialno dosegljiv na istem kablu. Tunel v slogu PPP ima na drugem koncu natanko enega partnerja. Ni domene oddajanja, ni ARP in ni razloga, da bi lokalni naslov opisoval obseg.
Pogajanja o naslovih za ta model so opredeljena v RFC 1332, ki opisuje, kako se oba konca dogovorita o svojih naslovih. Česar ne naredi, je predaja pisarniškega omrežja LAN odjemalcu kot neposredno priključenega omrežja. Odjemalec se nauči, kje je pisarna, z namestitvijo poti prek povezave in prav te poti odločajo o dosegljivosti.
To ne pomeni, da je vsaka maska, ki jo vidite, pravilna. Napačno konfiguriran odjemalec lahko prav tako ustvari nenavadno naslavljanje. Poanta je ožja: gostiteljska maska na tej vrsti vmesnika je pričakovana, zato sama po sebi ni dokaz okvare.
Korak 1: potrdite model vmesnika
Poglejte, kaj je vmesnik, preden presodite, kaj pravi. Opisni niz identificira gonilnik in dolžina predpone pri dodeljenem naslovu potrjuje, kaj se je odjemalec dogovoril:
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,NlMtuTretji ukaz je tisti, ki konča večino prepirov. Nizka največja prenosna enota je značilna za zapakirano povezavo, medtem ko vrednost, podobna Ethernetu, nakazuje drug model navideznega vmesnika. Če opis navaja gonilnik PPP ali RAS in je predpona 32, gledate natanko na zgoraj opisano zasnovo in lahko prenehate skrbeti zaradi maske.
| Observation | What it means | Reasonable next step |
|---|---|---|
| /32 on a PPP or RAS adapter | Point-to-point endpoint addressing | Look at routes, not the mask |
| /32 on an Ethernet-like adapter | Client chose host addressing deliberately | Confirm against the server's push policy |
| Mask differs from the office LAN | Usually irrelevant to reachability | Test the destination instead |
Korak 2: preberite pot za cilj, ki ne deluje
Dosegljivost se odloča po cilju in en sam priključen vmesnik o tem ne pove ničesar. Vprašajte usmerjevalno tabelo neposredno o naslovu, ki ga uporabnik dejansko poskuša doseči:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute je neposreden odgovor: navede vmesnik in izvorni naslov, ki bi ga sistem uporabil za ta cilj. Če vrne tunel, promet do tega gostitelja poteka skozi tunel in maska ni bila nikoli težava.
Če vrne fizični vmesnik, primerjajte obe možni poti in njune meritve. Natančnejša lokalna pot, ostanek drugega odjemalca ali nižja meritev na fizični poti vse premagajo široko pot tunela. Viden rezultat je nedosegljiv vir, medtem ko vse drugo deluje. Daljše predpone vedno zmagajo, zato je zmagovalec pogosto gostiteljska pot, ki jo je nekdo dodal pred meseci in pozabil.
Tukaj preverite tudi obe smeri. Pot proti strežniški strani je potrebna, a ne zadostna, ker se mora tudi odgovor vrniti skozi tunel. Ko en notranji gostitelj deluje in drugi ne, je razlika običajno v tej tabeli, ne v konfiguraciji vmesnika.
Korak 3: ločite razreševanje imen od dostopa do storitve
Aplikacija, ki ne odpre mape v skupni rabi, lahko odpove v eni od dveh zelo različnih stopenj. Razrešite ime in nato dosezite naslov. Če prvo odpove in drugo deluje, je tunel v redu, razreševalnik pa ne:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445Uspešen preizkus naslova skupaj z neuspešnim preizkusom imena lokalizira težavo v razreševanju, drugi ukaz pa pokaže, ali je vmesnik tunela sploh dobil strežnik. Veliko odjemalcev pošilja DNS kot del konfiguracije tunela in profil, ki te poslane možnosti ignorira, pusti stroj z razreševalnikom, ki ne vidi zasebnega območja.
Delujočega naslova ne jemljite kot trajno popravilo. Povezovanje po naslovu obide razreševanje imen in lahko spodkoplje preverjanje identitete strežnika, ki bi ga aplikacija sicer izvedla. To je varnostna regresija, preoblečena v začasno rešitev. Uporabite jo za lokalizacijo napake in nato popravite razreševanje.
Vrnitev: ne zgradite znova DHCP zaradi prikazane vrednosti
Če ste že začeli spreminjati naslovno storitev, se ustavite in preverite, ali je karkoli od tega, kar ste spremenili, nosilno. Ponovno ustvarjanje obsega, ponovno izdajanje zakupov ali premikanje nabora spreminja stanje, od katerega so odvisni drugi odjemalci, in nič od tega ne upravičuje gostiteljska maska na vmesniku od točke do točke.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445Zaženite te tri po vsaki ciljni spremembi in primerjajte s prejšnjim izvajanjem. Koristen rezultat je dokumentirana pot do vira, ne vmesnik, katerega maska je podobna pisarniškemu omrežju LAN.
Nato zapišite, kaj je maska v resnici pomenila, ker bo naslednja oseba odprla isto pogovorno okno in prišla do enakega napačnega sklepa. En stavek v opombah profila, da je tunel od točke do točke in da oddaljena podomrežja pridejo kot poti, prihrani celotno preiskavo naslednjič.