Windows VPN zobrazuje 255.255.255.255: je maska špatná?
U tunelu typu bod-bod je hostitelská maska normální. Ověřte model rozhraní, přečtěte trasu pro selhávajícího hostitele a oddělte DNS od přístupu ke službě.
Tunel se připojí, otevřete podrobnosti adaptéru a maska ukazuje 255.255.255.255. Ve srovnání s 255.255.255.0 kancelářské LAN to vypadá rozbité a právě tam obvykle chyba začíná. Na spoji bod-bod je hostitelská maska správným popisem místního koncového bodu a vzdálené sítě přicházejí jako trasy, nikoli jako připojená podsíť. Následující postup odděluje obě otázky, abyste nepřebudovávali funkční rozsah DHCP jen kvůli opravě zobrazené hodnoty.
Spoj bod-bod není segment Ethernetu
Rozhraní Ethernet potřebuje masku podsítě, protože každá adresa v tomto rozsahu je potenciálně dostupná na stejném kabelu. Tunel ve stylu PPP má na druhém konci přesně jednoho partnera. Neexistuje doména vysílání, žádné ARP ani důvod, aby místní adresa popisovala rozsah.
Vyjednávání adres pro tento model je definováno v RFC 1332, která popisuje, jak se oba konce dohodnou na svých adresách. Co nedělá, je předání kancelářské LAN klientovi jako přímo připojené sítě. Klient se učí, kde kancelář je, instalací tras přes spoj, a právě tyto trasy rozhodují o dosažitelnosti.
To neznamená, že každá maska, kterou uvidíte, je správná. Špatně nakonfigurovaný klient může také produkovat podivné adresování. Pointa je užší: hostitelská maska na tomto typu adaptéru je očekávaná, takže sama o sobě není důkazem závady.
Krok 1: ověřte model rozhraní
Podívejte se, co adaptér je, než posoudíte, co říká. Popisný řetězec identifikuje ovladač a délka prefixu přiřazené adresy potvrzuje, co 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,NlMtuTřetí příkaz je ten, který ukončí většinu sporů. Nízká maximální přenosová jednotka je charakteristická pro zapouzdřený spoj, zatímco hodnota podobná Ethernetu naznačuje jiný model virtuálního adaptéru. Pokud popis uvádí ovladač PPP nebo RAS a prefix je 32, díváte se přesně na výše popsaný návrh a můžete přestat řešit 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: přečtěte trasu pro selhávající cíl
Dosažitelnost se rozhoduje podle cíle a jediné připojené rozhraní o tom nic neříká. Zeptejte se přímo směrovací tabulky na adresu, kterou se uživatel skutečně snaží dosáhnout:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute je přímá odpověď: uvádí rozhraní a zdrojovou adresu, kterou by systém pro tento cíl použil. Pokud vrátí tunel, provoz k tomuto hostiteli jde tunelem a maska nikdy nebyla problém.
Pokud vrátí fyzický adaptér, porovnejte dvě kandidátní trasy a jejich metriky. Konkrétnější místní trasa, zbytek po jiném klientovi nebo nižší metrika na fyzické cestě všechny zvítězí nad širokou trasou tunelu. Viditelným výsledkem je nedostupný prostředek, zatímco vše ostatní funguje. Delší prefixy vždy vyhrávají, takže vítězem je často hostitelská trasa, kterou někdo přidal před měsíci a zapomněl.
Zkontrolujte zde také oba směry. Trasa k serverové straně je nutná, ale ne postačující, protože odpověď se musí vrátit také tunelem. Když jeden interní hostitel funguje a jiný ne, rozdíl je obvykle v této tabulce, nikoli v konfiguraci adaptéru.
Krok 3: oddělte překlad jmen od přístupu ke službě
Aplikace, která neotevře sdílenou složku, může selhávat v jedné ze dvou velmi odlišných fází. Vyřešte jméno a potom dosáhněte adresy. Pokud první selže a druhé funguje, tunel je v pořádku a překladač ne:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445Úspěšný test adresy spolu s neúspěšným testem jména lokalizuje problém do překladu a druhý příkaz ukáže, zda rozhraní tunelu vůbec dostalo server. Mnoho klientů posílá DNS jako součást konfigurace tunelu a profil, který tyto poslané volby ignoruje, nechá stroj používat překladač, který privátní zónu nevidí.
Neberte funkční adresu jako trvalou opravu. Připojení přes adresu obchází překlad jmen a může podkopat ověření identity serveru, které by aplikace jinak provedla. To je bezpečnostní regrese převlečená za dočasné řešení. Použijte ji k lokalizaci závady a poté opravte překlad.
Vrácení zpět: nepřebudovávejte DHCP kvůli zobrazené hodnotě
Pokud jste již začali měnit adresní službu, zastavte se a zkontrolujte, zda je něco z toho, co jste změnili, nosné. Znovuvytvoření rozsahu, opětovné vydání leasingů nebo přesun fondu mění stav, na kterém závisí jiní klienti, a nic z toho neospravedlňuje hostitelská maska na adaptéru bod-bod.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445Spusťte tyto tři po každé cílené změně a porovnejte s předchozím během. Užitečným výsledkem je zdokumentovaná cesta ke zdroji, nikoli adaptér, jehož maska se podobá kancelářské LAN.
Potom si zapište, co maska skutečně znamenala, protože další člověk otevře stejný dialog a dojde ke stejnému chybnému závěru. Jedna věta v poznámkách profilu, že tunel je bod-bod a vzdálené podsítě přicházejí jako trasy, ušetří celé vyšetřování příště.