Windows-VPN visar 255.255.255.255: är masken fel?

Tunneln ansluter, du öppnar adapterinformationen och masken visar 255.255.255.255. Jämfört med 255.255.255.0 i kontorets LAN ser det trasigt ut, och det är oftast där felet börjar. På en punkt-till-punkt-länk är en värdmask den korrekta beskrivningen av den lokala ändpunkten, och fjärrnäten kommer in som rutter i stället för som ett anslutet subnät. Proceduren nedan skiljer de två frågorna åt, så att du inte bygger om ett fungerande DHCP-område för att rätta ett visat värde.

En punkt-till-punkt-länk är inte ett Ethernet-segment

Ett Ethernet-gränssnitt behöver en subnätmask eftersom varje adress i det intervallet potentiellt går att nå på samma kabel. En tunnel i PPP-stil har exakt en peer i andra änden. Det finns ingen broadcastdomän, ingen ARP och ingen anledning för den lokala adressen att beskriva ett intervall.

Adressförhandlingen för den modellen definieras i RFC 1332, som beskriver hur de två ändarna kommer överens om sina adresser. Det den inte gör är att ge klienten kontorets LAN som ett direkt anslutet nät. Klienten lär sig var kontoret finns genom att installera rutter via länken, och det är dessa rutter som faktiskt avgör nåbarheten.

Det betyder inte att varje mask du ser är korrekt. En felkonfigurerad klient kan också ge märklig adressering. Poängen är snävare: en värdmask på den här typen av adapter är förväntad, så den är i sig inget bevis på ett fel.

Steg 1: bekräfta gränssnittsmodellen

Titta på vad adaptern är innan du bedömer vad den säger. Beskrivningssträngen identifierar drivrutinen, och prefixlängden på den tilldelade adressen bekräftar vad klienten har förhandlat:

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

Det tredje kommandot är det som avgör de flesta diskussioner. En låg maximal överföringsenhet är typisk för en inkapslad länk, medan ett Ethernet-likt värde tyder på en annan virtuell adaptermodell. Om beskrivningen anger en PPP- eller RAS-drivrutin och prefixet är 32, ser du exakt den konstruktion som beskrivs ovan och kan sluta oroa dig för masken.

Steg 2: läs rutten för den destination som misslyckas

Nåbarhet avgörs per destination, och ett enda anslutet gränssnitt säger ingenting om det. Fråga routingtabellen direkt om den adress som användaren faktiskt försöker nå:

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

Find-NetRoute är det direkta svaret: den anger gränssnittet och källadressen som systemet skulle använda för den destinationen. Om den returnerar tunneln går trafiken till den värden genom tunneln, och masken var aldrig problemet.

Om den returnerar den fysiska adaptern, jämför de två kandidatrutterna och deras mätvärden. En mer specifik lokal rutt, en kvarleva från en annan klient eller ett lägre mätvärde på den fysiska vägen vinner alla över en bred tunnelrutt. Det synliga resultatet är en resurs som inte går att nå medan allt annat fungerar. Längre prefix vinner alltid, så vinnaren är ofta en värdrutt som någon lade till för månader sedan och glömde.

Kontrollera också båda riktningarna medan du är här. En rutt till serversidan är nödvändig men inte tillräcklig, eftersom svaret också måste tillbaka genom tunneln. När en intern värd fungerar och en annan inte, ligger skillnaden oftast i den här tabellen och inte i adapterkonfigurationen.

Steg 3: skilj namnuplösning från tjänsteåtkomst

Ett program som inte kan öppna en delad resurs kan misslyckas i ett av två mycket olika steg. Slå upp namnet och nå sedan adressen. Om det första misslyckas och det andra fungerar är tunneln okej och resolvern inte:

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

Ett lyckat adresstest plus ett misslyckat namntest lokaliserar problemet till uppslagningen, och det andra kommandot visar om tunnelgränssnittet alls har fått en server. Många klienter skickar DNS som en del av tunnelkonfigurationen, och en profil som ignorerar dessa skickade alternativ lämnar maskinen med en resolver som inte ser den privata zonen.

Behandla inte en fungerande adress som den permanenta lösningen. Att ansluta via adress kringgår namnuplösningen och kan underminera den serveridentitetskontroll som programmet annars skulle göra. Det är en säkerhetsregression förklädd till en tillfällig lösning. Använd den för att lokalisera felet och reparera sedan uppslagningen.

Återställning: bygg inte om DHCP för ett visat värde

Om du redan har börjat ändra adresstjänsten, stanna och kontrollera om något av det du ändrade är bärande. Att återskapa ett område, utfärda nya leases eller flytta poolen ändrar tillstånd som andra klienter är beroende av, och inget av det motiveras av en värdmask på en punkt-till-punkt-adapter.

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

Kör dessa tre efter varje riktad ändring och jämför med körningen före. Det användbara resultatet är en dokumenterad väg till resursen, inte en adapter vars mask liknar kontorets LAN.

Skriv sedan ned vad masken faktiskt betydde, för nästa person öppnar samma dialog och drar samma felaktiga slutsats. En mening i profilanteckningarna om att tunneln är punkt-till-punkt och att fjärrsubnäten kommer in som rutter sparar hela utredningen nästa gång.