Windows VPN zobrazuje 255.255.255.255: je maska nesprávna?
Pri tuneli typu bod-bod je hostiteľská maska normálna. Overte model rozhrania, prečítajte trasu pre zlyhávajúceho hostiteľa a oddeľte DNS od prístupu k službe.
Tunel sa pripojí, otvoríte podrobnosti adaptéra a maska ukazuje 255.255.255.255. V porovnaní s 255.255.255.0 kancelárskej LAN to vyzerá rozbité a práve tam sa chyba zvyčajne začína. Na spoji bod-bod je hostiteľská maska správnym popisom miestneho koncového bodu a vzdialené siete prichádzajú ako trasy, nie ako pripojená podsiet. Nasledujúci postup oddeľuje obe otázky, aby ste neprebudovávali funkčný rozsah DHCP len kvôli oprave zobrazovanej hodnoty.
Spoj bod-bod nie je segment Ethernetu
Rozhranie Ethernet potrebuje masku podsiete, pretože každá adresa v tomto rozsahu je potenciálne dostupná na tom istom kábli. Tunel v štýle PPP má na druhom konci presne jedného partnera. Neexistuje doména vysielania, žiadne ARP ani dôvod, aby miestna adresa popisovala rozsah.
Vyjednávanie adries pre tento model je definované v RFC 1332, ktorá popisuje, ako sa oba konce dohodnú na svojich adresách. Čo nerobí, je odovzdanie kancelárskej LAN klientovi ako priamo pripojenej siete. Klient sa učí, kde kancelária je, inštaláciou trás cez spoj, a práve tieto trasy rozhodujú o dosiahnuteľnosti.
To neznamená, že každá maska, ktorú uvidíte, je správna. Zle nakonfigurovaný klient môže tiež produkovať zvláštne adresovanie. Pointa je užšia: hostiteľská maska na tomto type adaptéra je očakávaná, takže sama o sebe nie je dôkazom poruchy.
Krok 1: overte model rozhrania
Pozrite sa, čo adaptér je, skôr než posúdite, čo hovorí. Popisný reťazec identifikuje ovládač a dĺžka prefixu priradenej adresy potvrdzuje, čo klient vyjednal:
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,NlMtuTretí príkaz je ten, ktorý ukončí väčšinu sporov. Nízka maximálna prenosová jednotka je charakteristická pre zapuzdrený spoj, zatiaľ čo hodnota podobná Ethernetu naznačuje iný model virtuálneho adaptéra. Ak popis uvádza ovládač PPP alebo RAS a prefix je 32, pozeráte sa presne na vyššie opísaný návrh a môžete prestať riešiť masku.
| 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 |
Krok 2: prečítajte trasu pre zlyhávajúci cieľ
Dosiahnuteľnosť sa rozhoduje podľa cieľa a jediné pripojené rozhranie o tom nič nehovorí. Spýtajte sa priamo smerovacej tabuľky na adresu, ktorú sa používateľ skutočne snaží dosiahnuť:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute je priama odpoveď: uvádza rozhranie a zdrojovú adresu, ktorú by systém pre tento cieľ použil. Ak vráti tunel, prevádzka k tomuto hostiteľovi ide tunelom a maska nikdy nebola problém.
Ak vráti fyzický adaptér, porovnajte dve kandidátske trasy a ich metriky. Konkrétnejšia miestna trasa, zvyšok po inom klientovi alebo nižšia metrika na fyzickej ceste všetky zvíťazia nad širokou trasou tunela. Viditeľným výsledkom je nedostupný prostriedok, zatiaľ čo všetko ostatné funguje. Dlhšie prefixy vždy vyhrávajú, takže víťazom je často hostiteľská trasa, ktorú niekto pridal pred mesiacmi a zabudol.
Skontrolujte tu aj oba smery. Trasa k serverovej strane je nutná, ale nie postačujúca, pretože odpoveď sa musí vrátiť tiež tunelom. Keď jeden interný hostiteľ funguje a iný nie, rozdiel je zvyčajne v tejto tabuľke, nie v konfigurácii adaptéra.
Krok 3: oddeľte preklad mien od prístupu k službe
Aplikácia, ktorá neotvorí zdieľaný priečinok, môže zlyhávať v jednej z dvoch veľmi odlišných fáz. Vyriešte meno a potom dosiahnite adresu. Ak prvé zlyhá a druhé funguje, tunel je v poriadku a prekladač nie:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445Úspešný test adresy spolu s neúspešným testom mena lokalizuje problém do prekladu a druhý príkaz ukáže, či rozhranie tunela vôbec dostalo server. Mnoho klientov posiela DNS ako súčasť konfigurácie tunela a profil, ktorý tieto poslané voľby ignoruje, nechá stroj používať prekladač, ktorý privátnu zónu nevidí.
Neberte funkčnú adresu ako trvalú opravu. Pripojenie cez adresu obchádza preklad mien a môže podkopať overenie identity servera, ktoré by aplikácia inak vykonala. To je bezpečnostná regresia prezlečená za dočasné riešenie. Použite ju na lokalizáciu poruchy a potom opravte preklad.
Vrátenie späť: neprebudovávajte DHCP kvôli zobrazovanej hodnote
Ak ste už začali meniť adresnú službu, zastavte sa a skontrolujte, či je niečo z toho, čo ste zmenili, nosné. Znovuvytvorenie rozsahu, opätovné vydanie leasingov alebo presun fondu mení stav, na ktorom závisia iní klienti, a nič z toho neospravedlňuje hostiteľská maska na adaptéri bod-bod.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445Spustite tieto tri po každej cielenej zmene a porovnajte s predchádzajúcim behom. Užitočným výsledkom je zdokumentovaná cesta k zdroju, nie adaptér, ktorého maska sa podobá kancelárskej LAN.
Potom si zapíšte, čo maska skutočne znamenala, pretože ďalší človek otvorí ten istý dialóg a dospeje k rovnakému chybnému záveru. Jedna veta v poznámkach profilu, že tunel je bod-bod a vzdialené podsiete prichádzajú ako trasy, ušetrí celé vyšetrovanie nabudúce.