Nessun internet su una VPN Windows? Il pool di indirizzi è il sospetto

Windows mostra il tunnel come connesso e lo etichetta Nessun accesso a Internet, che le persone leggono come una stranezza di Windows. È un'affermazione su ciò che il client ha ricevuto: nessun gateway predefinito utilizzabile, nessun resolver funzionante, o nessun percorso di ritorno per gli indirizzi dentro il tunnel. Quando il server è una Incoming Connection di Windows, una sola impostazione spiega la maggior parte di questi rapporti. L'etichetta non è una diagnosi, ma restringe la ricerca a tre punti.

Leggi la lease prima di cambiarla

Esegui ipconfig /all sul client e trova l'adattatore VPN tra le voci. L'indirizzo, il gateway predefinito e il server DNS che elenca sono i fatti che ti servono, e spesso sono diversi da ciò che l'amministratore presume sia stato assegnato.

Tre schemi corrispondono a tre guasti. Un indirizzo in 169.254.0.0/16 significa che il client non ha ricevuto nulla e si è assegnato un indirizzo link-local. Un indirizzo plausibile senza gateway significa che il pool è stato servito senza l'opzione che dà al client una rotta predefinita. Una lease completa che comunque non raggiunge nulla indica inoltro o traduzione sul lato server.

Annota i valori prima di toccare il server. Il passo successivo li confronta con l'intervallo che il server crede di distribuire, e la memoria è un cattivo sostituto di una lease.

Perché l'assegnazione automatica può lasciare senza gateway

La voce Incoming Connections ha le proprie proprietà IPv4, separate dall'adattatore fisico. L'impostazione predefinita lì offre di assegnare gli indirizzi automaticamente, il che si affida all'allocatore integrato della connessione per fornire indirizzo, maschera, gateway e DNS.

Su una workstation autonoma quell'allocatore non ha un ambito da cui attingere a meno che qualcos'altro sulla macchina non ne fornisca uno, così il client può finire con un indirizzo link-local o con un indirizzo ma senza gateway. La connessione sembra stabilita perché il link è salito, mentre la configurazione dietro è incompleta.

Ecco perché passare a un intervallo specificato risolve tanti di questi rapporti. Smeti di chiedere a un servizio che forse non è in esecuzione di inventare una lease e inizi a dichiarare tu stesso la lease.

La stessa confusione compare quando qualcuno si aspetta che il server DHCP del router LAN serva i client del tunnel. L'individuazione broadcast non attraversa un tunnel instradato, quindi quel server non vede mai la richiesta. Presumere il contrario è la ragione più comune per cui si dà la colpa a un pool per un client che non gli ha mai chiesto nulla.

Imposta un intervallo esplicito che il server può instradare

Scegli un blocco piccolo dentro una sottorete raggiungibile dal server, fuori dall'intervallo che il router LAN distribuisce e fuori da qualsiasi altro pool sulla rete. Se il server sta su 172.20.10.0/24 e il router tiene 172.20.10.1, un blocco corto vicino alla cima di quella sottorete, diciamo da 172.20.10.201 a 172.20.10.209, tiene le lease del tunnel lontane dalla distribuzione che il router già gestisce.

Inseriscilo nelle proprietà IPv4 della Incoming Connection, riconnetti il client e rileggi l'adattatore prima di cambiare altro. Una seconda lettura è ciò che ti dice se il pool era il guasto o solo uno dei tanti.

Questi comandi stampano la configurazione risultante e le rotte che il client ha ora:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

Il gateway nella lease dovrebbe essere un indirizzo che il server possiede, e la rotta predefinita del client dovrebbe puntare a esso. Se la lease è completa ma non esiste alcuna rotta, il server ha assegnato senza spingere un gateway, e le impostazioni del pool sono ancora il posto da guardare.

Un indirizzo non è un percorso internet

Ricevere una lease sposta solo i pacchetti dal client al server. Per l'accesso a internet il server deve inoltrare quei pacchetti e tradurli verso il proprio uplink, e questa è una configurazione separata con le sue modalità di guasto.

Internet Connection Sharing è la scorciatoia. Trasforma l'adattatore rivolto a internet in un gateway condiviso e gestisce il proprio indirizzamento, che può riscrivere l'indirizzo di quell'adattatore e lasciare una regola NAT esistente che punta a un valore che non esiste più. Registra le impostazioni originali prima di abilitarla.

L'alternativa instradata mantiene l'indirizzamento stabile e ti chiede di configurare inoltro e traduzione in modo esplicito. Nessuno dei due approcci è sbagliato; mescolarli a metà produce un tunnel con una lease e senza uscita, che è esattamente il sintomo con cui hai iniziato. Scegli un modello e portalo a termine prima di aggiungere l'altro.

Escludi prima il percorso esterno

Nessun pool può aiutare se il tunnel non si forma mai. Il protocollo decide cosa deve trasportare il percorso: PPTP vuole TCP 1723 e GRE, che è il protocollo IP 47 e non una porta; L2TP/IPsec vuole UDP 1701 più 500 e 4500; SSTP vuole TCP 443.

Un router che inoltra la porta ma non il protocollo produce un tentativo di connessione che non si autentica mai. È un guasto diverso da un tunnel che si forma e poi non raggiunge nulla, e i due non vanno diagnosticati insieme.

Prova dalla stessa LAN e dalla rete remota. Se il tentativo dalla LAN funziona e quello remoto non arriva mai all'autenticazione, il percorso esterno è il problema. Se entrambi si autenticano e solo il client remoto non ha internet, torna al pool e all'uscita.