La VPN de Windows mostra 255.255.255.255: la màscara és incorrecta?

El túnel es connecta, obriu els detalls de l’adaptador i la màscara mostra 255.255.255.255. Comparada amb la 255.255.255.0 de la LAN de l’oficina sembla trencada, i normalment és aquí on comença l’error. En un enllaç punt a punt, una màscara d’amfitrió és la descripció correcta de l’extrem local, i les xarxes remotes arriben com a rutes en lloc de com una subxarxa connectada. El procediment següent separa les dues preguntes perquè no reconstrueixi un àmbit DHCP que funciona només per arreglar un valor mostrat.

Un enllaç punt a punt no és un segment Ethernet

Una interfície Ethernet necessita una màscara de subxarxa perquè cada adreça d’aquest rang és potencialment abastable al mateix cable. Un túnel d’estil PPP té exactament un parell a l’altre extrem. No hi ha domini de difusió, ni ARP, ni cap motiu perquè l’adreça local descrigui un rang.

La negociació d’adreçament per a aquest model es defineix a la RFC 1332, que cobreix com les dues bandes acorden les seves adreces. El que no fa és lliurar al client la LAN de l’oficina com una xarxa directament connectada. El client aprèn on és l’oficina instal·lant rutes a través de l’enllaç, i aquestes rutes són les que decideixen realment l’abastabilitat.

Això no vol dir que tota màscara que vegeu sigui correcta. Un client mal configurat també pot produir adreçament estrany. El punt és més concret: una màscara d’amfitrió en aquest tipus d’adaptador és l’esperat, així que per si sola no és prova d’una fallada.

Pas 1: confirmeu el model d’interfície

Mireu què és l’adaptador abans de jutjar què diu. La cadena de descripció identifica el controlador, i la longitud de prefix de l’adreça assignada confirma què ha negociat el client:

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

La tercera ordre és la que resol la majoria de discussions. Una unitat màxima de transmissió baixa és característica d’un enllaç encapsulat, mentre que un valor semblant a Ethernet suggereix un model d’adaptador virtual diferent. Si la descripció anomena un controlador PPP o RAS i el prefix és 32, esteu exactament davant del disseny descrit més amunt i podeu deixar de preocupar-vos per la màscara.

Pas 2: llegiu la ruta de la destinació que falla

L’abastabilitat es decideix per destinació, i una sola interfície connectada no us diu res sobre això. Pregunteu directament a la taula d’encaminament per l’adreça a la qual l’usuari intenta arribar:

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

Find-NetRoute és la resposta directa: indica la interfície i l’adreça d’origen que el sistema faria servir per a aquesta destinació. Si retorna el túnel, el trànsit cap a aquest amfitrió passa pel túnel i la màscara mai no va ser el problema.

Si retorna l’adaptador físic, compareu les dues rutes candidates i les seves mètriques. Una ruta local més específica, una entrada sobrant d’un altre client o una mètrica més baixa al camí físic guanyaran una ruta de túnel àmplia. El resultat visible són recursos inabastables mentre la resta funciona. Els prefixos més llargs sempre guanyen, així que el guanyador sovint és una ruta d’amfitrió que algú va afegir fa mesos i va oblidar.

Comproveu també les dues direccions mentre sou aquí. Una ruta cap al costat del servidor és necessària però no suficient, perquè la resposta també ha de tornar pel túnel. Quan un amfitrió intern funciona i un altre no, la diferència sol ser en aquesta taula i no en la configuració de l’adaptador.

Pas 3: separeu la resolució de noms de l’accés al servei

Una aplicació que no obre un recurs compartit pot estar fallant en una de dues etapes molt diferents. Resoleu el nom i després arribeu a l’adreça. Si la primera falla i la segona funciona, el túnel està bé i el resolutor no:

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

Una prova d’adreça correcta juntament amb una prova de nom fallida localitza el problema en la resolució, i la segona ordre mostra si la interfície del túnel ha rebut cap servidor. Molts clients empenyen el DNS com a part de la configuració del túnel, i un perfil que ignora aquestes opcions deixarà la màquina fent servir un resolutor que no veu la zona privada.

No tracteu una adreça que funciona com l’arranjament permanent. Connectar per adreça evita la resolució de noms i pot anul·lar la comprovació d’identitat del servidor que l’aplicació faria altrament. Això és una regressió de seguretat disfressada de solució temporal. Feu-la servir per localitzar la fallada i després repareu la resolució.

Reversió: no reconstruïu el DHCP per un valor mostrat

Si ja heu començat a canviar el servei d’adreçament, atureu-vos i comproveu si alguna cosa del que heu canviat és essencial. Recrear un àmbit, reemetre concessions o moure el pool canvia un estat del qual depenen altres clients, i res d’això no es justifica per una màscara d’amfitrió en un adaptador punt a punt.

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

Executeu aquestes tres ordres després de qualsevol canvi puntual i compareu-les amb l’execució anterior. El resultat útil és un camí documentat cap al recurs, no un adaptador amb una màscara que s’assembla a la LAN de l’oficina.

Després anoteu què significava realment la màscara, perquè la propera persona obrirà el mateix diàleg i arribarà a la mateixa conclusió equivocada. Una frase a les notes del perfil, dient que el túnel és punt a punt i que les subxarxes remotes arriben com a rutes, estalvia tota la investigació la propera vegada.