La VPN di Windows mostra 255.255.255.255: la maschera è sbagliata?
Su un tunnel punto a punto una maschera host è normale. Conferma il modello dell’interfaccia, leggi la rotta per l’host che non risponde e separa il DNS dall’accesso ai servizi.
Il tunnel si connette, apri i dettagli della scheda di rete e la maschera mostra 255.255.255.255. Confrontata con la 255.255.255.0 della LAN dell’ufficio sembra rotta, ed è di solito lì che nasce l’errore. Su un collegamento punto a punto una maschera host è la descrizione corretta dell’estremità locale, e le reti remote arrivano come rotte anziché come una sottorete collegata. La procedura qui sotto separa le due domande, così non ricostruisci un ambito DHCP funzionante solo per sistemare un valore visualizzato.
Un collegamento punto a punto non è un segmento Ethernet
Un’interfaccia Ethernet ha bisogno di una maschera di sottorete perché ogni indirizzo di quell’intervallo è potenzialmente raggiungibile sullo stesso cavo. Un tunnel in stile PPP ha esattamente un peer all’altro capo. Non c’è dominio di broadcast, né ARP, né motivo perché l’indirizzo locale descriva un intervallo.
La negoziazione degli indirizzi per quel modello è definita nella RFC 1332, che spiega come i due capi concordano i rispettivi indirizzi. Ciò che non fa è consegnare al client la LAN dell’ufficio come rete direttamente collegata. Il client impara dov’è l’ufficio installando rotte attraverso il collegamento, e sono quelle rotte a decidere davvero la raggiungibilità.
Questo non significa che ogni maschera che vedrai sia corretta. Un client mal configurato può produrre anch’esso indirizzamenti strani. Il punto è più ristretto: una maschera host su questo tipo di scheda è prevista, quindi da sola non è prova di un guasto.
Passo 1: conferma il modello dell’interfaccia
Guarda cos’è la scheda prima di giudicare ciò che dice. La stringa di descrizione identifica il driver, e la lunghezza del prefisso sull’indirizzo assegnato conferma ciò che il client ha negoziato:
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,NlMtuIl terzo comando è quello che chiude la maggior parte delle discussioni. Un’unità massima di trasmissione bassa è tipica di un collegamento incapsulato, mentre un valore simile a Ethernet suggerisce un diverso modello di scheda virtuale. Se la descrizione nomina un driver PPP o RAS e il prefisso è 32, sei esattamente nel progetto descritto sopra e puoi smettere di preoccuparti della maschera.
| 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 |
Passo 2: leggi la rotta per la destinazione che non risponde
La raggiungibilità si decide per destinazione, e una singola interfaccia connessa non ti dice nulla al riguardo. Chiedi direttamente alla tabella delle rotte, per l’indirizzo che l’utente sta davvero cercando di raggiungere:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute è la risposta diretta: indica l’interfaccia e l’indirizzo sorgente che il sistema userebbe per quella destinazione. Se restituisce il tunnel, il traffico verso quell’host passa dal tunnel e la maschera non è mai stata il problema.
Se restituisce la scheda fisica, confronta le due rotte candidate e le loro metriche. Una rotta locale più specifica, una voce rimasta da un altro client o una metrica più bassa sul percorso fisico battono tutte una rotta di tunnel ampia. Il risultato visibile è una risorsa irraggiungibile mentre tutto il resto funziona. I prefissi più lunghi vincono sempre, quindi il vincitore è spesso una rotta host che qualcuno ha aggiunto mesi fa e ha dimenticato.
Controlla anche entrambe le direzioni mentre sei qui. Una rotta verso il lato server è necessaria ma non sufficiente, perché anche la risposta deve tornare attraverso il tunnel. Quando un host interno funziona e un altro no, la differenza è di solito in questa tabella e non nella configurazione della scheda.
Passo 3: separa la risoluzione dei nomi dall’accesso al servizio
Un’applicazione che non apre una condivisione può fallire in una di due fasi molto diverse. Risolvi il nome, poi raggiungi l’indirizzo. Se la prima fallisce e la seconda funziona, il tunnel è a posto e il resolver no:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445Un test dell’indirizzo riuscito insieme a un test del nome fallito localizza il problema nella risoluzione, e il secondo comando mostra se l’interfaccia del tunnel ha ricevuto un server. Molti client inviano il DNS come parte della configurazione del tunnel, e un profilo che ignora quelle opzioni push lascia la macchina con un resolver che non vede la zona privata.
Non considerare un indirizzo funzionante come la soluzione definitiva. Connettersi per indirizzo aggira la risoluzione dei nomi e può vanificare il controllo dell’identità del server che l’applicazione farebbe altrimenti. È una regressione di sicurezza travestita da soluzione temporanea. Usala per localizzare il guasto, poi ripara la risoluzione.
Rollback: non ricostruire il DHCP per un valore visualizzato
Se hai già iniziato a modificare il servizio di indirizzamento, fermati e controlla se qualcosa di ciò che hai cambiato è essenziale. Ricreare un ambito, riemettere lease o spostare il pool cambia uno stato da cui dipendono altri client, e nulla di tutto ciò è giustificato da una maschera host su una scheda punto a punto.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445Esegui questi tre dopo ogni modifica mirata e confronta con l’esecuzione precedente. Il risultato utile è un percorso documentato verso la risorsa, non una scheda la cui maschera somiglia alla LAN dell’ufficio.
Poi scrivi cosa significava davvero la maschera, perché la prossima persona aprirà la stessa finestra e arriverà alla stessa conclusione sbagliata. Una frase nelle note del profilo, che dice che il tunnel è punto a punto e che le sottoreti remote arrivano come rotte, risparmia tutta l’indagine la volta successiva.