Condividi una connessione Windows? Il percorso della VPN cambia sotto

Un portatile condivide il suo Wi-Fi, l’host naviga attraverso il tunnel senza lamentarsi e il tablet su quella condivisione non raggiunge nulla. L’host ha smesso di essere solo un client nel momento in cui è stata attivata la condivisione: ora è un router, e i pacchetti inoltrati incontrano un diverso insieme di regole. Ciò che funziona sull’host non dice nulla del dispositivo che gli sta dietro. Esegui i controlli dal client a valle e la distinzione smette di essere teorica.

Il successo dell’host non dimostra nulla

La condivisione di connessione affida quattro compiti a una macchina: assegnazione degli indirizzi, inoltro, traduzione e filtraggio. Un client VPN che protegge il traffico generato localmente può considerare il traffico inoltrato fuori dal proprio ambito, o bloccarlo di proposito come fuga. Nessuno dei due comportamenti è un bug, e nessuno è scritto nella schermata in cui è stata attivata la condivisione. Solo il test a valle ti dice quale hai.

Molti client inoltrano solo il traffico dell’host e nient’altro, quindi controlla la sezione condivisione nella documentazione del client invece di fidarti che il tunnel instradi per il tablet. Il sintomo visibile è un dispositivo che si associa, riceve un indirizzo e poi fallisce alla prima richiesta. Un client che rifiuta di inoltrare sembra ancora perfettamente sano sull’host.

Quale adattatore è condiviso, quale serve i client

Annota entrambi gli adattatori, perché portano indirizzi diversi e filtri diversi, e una modifica su quello sbagliato spiega molti risultati confusi. L’host della condivisione di solito prende un indirizzo fisso sul lato a valle e vi esegue un piccolo servizio DHCP e DNS. Windows mantiene l’inoltro per adattatore e non globalmente, quindi lo stato va letto interfaccia per interfaccia.

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfile

Se l’inoltro risulta Disattivato sull’adattatore condiviso, nulla a valle funzionerà qualunque cosa faccia il tunnel. Attivalo solo su una macchina la cui politica le consente di instradare per altri dispositivi.

Inoltro, traduzione e filtraggio

Un pacchetto inoltrato deve raggiungere il tunnel, essere tradotto in qualcosa che il lato remoto accetta e tornare attraverso la stessa traduzione. Qualsiasi di queste tre fasi può rompersi, e ogni rottura produce lo stesso timeout del browser. Una cattura di pacchetti, una ricerca di route e un log dal lato remoto valgono più di un’altra revisione della finestra di condivisione. Quale fase fallisce è ciò che ti dice di chi serve il cambiamento.

Il lato remoto può anche aver bisogno di una rotta di ritorno per la sottorete condivisa, un intervallo che il server VPN non ha mai visto. Dove il client traduce, il server vede solo l’indirizzo del tunnel e non serve alcuna rotta di ritorno. Dove non traduce, chi possiede il gateway deve aggiungere quella rotta deliberatamente, e questa è una richiesta di modifica, non un’impostazione del client.

Esegui i controlli sul client, non sull’host

Esegui ogni controllo sul client che fallisce, non sull’host che funziona. Tieni l’indirizzo di uscita, la risposta del resolver e il test dell’applicazione nella stessa sessione, perché risultati raccolti a un’ora di distanza non dicono nulla su come i tre si combinano.

Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailed

Confronta l’indirizzo di uscita con quello dell’host stesso e annota se i due coincidono. Una risposta diversa significa che il percorso inoltrato aggira il tunnel, il che è una questione di politica con un responsabile e non una correzione rapida. Una risposta coincidente accanto a un’applicazione che fallisce sposta il lavoro sulla risoluzione dei nomi o sulla politica del lato remoto. Non fermarti nemmeno al risultato IPv4: una condivisione può superare ogni controllo IPv4 mentre IPv6 esce da un’altra uscita, quindi ripeti i controlli di nomi e uscita con il record AAAA e il test di connessione dettagliato.

Su una macchina gestita, conferma che la condivisione sia consentita, perché esporre l’accesso a un altro dispositivo è una decisione amministrativa e non un interruttore di comodità. Dopo qualsiasi modifica supportata, ripeti i controlli alla riconnessione e di nuovo durante un’interruzione. Una riconnessione pulita dell’host non ripristina una rotta inoltrata che il client non ha mai supportato.