A VPN de Windows mostra 255.255.255.255: a máscara está mal?

O túnel conéctase, abres os detalles do adaptador e a máscara mostra 255.255.255.255. Comparada coa 255.255.255.0 da LAN da oficina parece rota, e aí adoita comezar o erro. Nun enlace punto a punto unha máscara de host é a descrición correcta do extremo local, e as redes remotas chegan como rutas en lugar de como unha subrede conectada. O procedemento de abaixo separa as dúas preguntas para que non reconstruas un ámbito DHCP que funciona só para arranxar un valor mostrado.

Un enlace punto a punto non é un segmento Ethernet

Unha interface Ethernet precisa unha máscara de subrede porque cada enderezo dese rango é potencialmente alcanzable no mesmo cable. Un túnel de estilo PPP ten exactamente un par no outro extremo. Non hai dominio de difusión, nin ARP, nin motivo para que o enderezo local describa un rango.

A negociación de enderezos para ese modelo defínese en RFC 1332, que cobre como os dous extremos acordan os seus enderezos. O que non fai é entregar ao cliente a LAN da oficina como unha rede directamente conectada. O cliente aprende onde está a oficina instalando rutas a través do enlace, e esas rutas son as que deciden realmente a accesibilidade.

Isto non é afirmar que toda máscara que vexas sexa correcta. Un cliente mal configurado tamén pode producir un enderezo estraño. O punto é máis concreto: unha máscara de host neste tipo de adaptador é o esperado, así que por si soa non é proba dun fallo.

Paso 1: confirma o modelo de interface

Mira que é o adaptador antes de xulgar o que di. A cadea de descrición identifica o controlador, e a lonxitude de prefixo no enderezo asignado confirma o que negociou o cliente:

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

O terceiro comando é o que resolve a maioría das discusións. Unha unidade máxima de transmisión baixa é característica dun enlace encapsulado, mentres que un valor similar ao de Ethernet suxire un modelo de adaptador virtual distinto. Se a descrición nomea un controlador PPP ou RAS e o prefixo é 32, estás exactamente ante o deseño descrito arriba e podes deixar de preocuparte pola máscara.

Paso 2: le a ruta do destino que falla

A accesibilidade decídese por destino, e unha soa interface conectada non che di nada ao respecto. Pregunta directamente á táboa de rutas polo enderezo ao que o usuario intenta chegar:

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

Find-NetRoute é a resposta directa: nomea a interface e o enderezo de orixe que o sistema usaría para ese destino. Se devolve o túnel, o tráfico cara a ese host pasa polo túnel e a máscara nunca foi o problema.

Se devolve o adaptador físico, compara as dúas rutas candidatas e as súas métricas. Unha ruta local máis específica, unha entrada sobrante doutro cliente ou unha métrica máis baixa na ruta física gañan todas a unha ruta de túnel ampla. O resultado visible son recursos inaccesibles mentres todo o demais funciona. Os prefixos máis longos sempre gañan, así que o vencedor adoita ser unha ruta de host que alguén engadiu hai meses e esqueceu.

Comproba tamén ambas as direccións mentres estás aquí. Unha ruta cara ao lado do servidor é necesaria pero non suficiente, porque a resposta ten que volver polo túnel tamén. Cando un host interno funciona e outro non, a diferenza adoita estar nesta táboa e non na configuración do adaptador.

Paso 3: separa a resolución de nomes do acceso ao servizo

Unha aplicación que non abre un recurso compartido pode estar fallando nunha de dúas etapas moi distintas. Resolve o nome e despois acada o enderezo. Se o primeiro falla e o segundo funciona, o túnel está ben e o resolutor non:

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

Unha proba de enderezo correcta xunto cunha proba de nome fallida localiza o problema na resolución, e o segundo comando mostra se a interface do túnel recibiu algún servidor. Moitos clientes envían DNS como parte da configuración do túnel, e un perfil que ignora esas opcións enviadas deixará a máquina usando un resolutor que non ve a zona privada.

Non tomes un enderezo que funciona como a solución permanente. Conectarse por enderezo omite a resolución de nomes e pode anular a comprobación de identidade do servidor que a aplicación faría doutro xeito. Iso é unha regresión de seguridade disfrazada de solución temporal. Úsaa para localizar o fallo e despois repara a resolución.

Reversión: non reconstruas DHCP por un valor mostrado

Se xa comezaches a cambiar o servizo de enderezos, detente e comproba se algo do que cambiaste é esencial. Recrear un ámbito, reemitir concesións ou mover o grupo cambia un estado do que dependen outros clientes, e nada diso está xustificado por unha máscara de host nun adaptador punto a punto.

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

Executa estes tres despois de calquera cambio puntual e compáraos coa execución anterior. O resultado útil é unha ruta documentada cara ao recurso, non un adaptador cuxa máscara se pareza á LAN da oficina.

Despois anota que significaba realmente a máscara, porque a seguinte persoa abrirá o mesmo diálogo e chegará á mesma conclusión equivocada. Unha frase nas notas do perfil, dicindo que o túnel é punto a punto e que as subredes remotas chegan como rutas, aforra toda a investigación a próxima vez.