Condividere la VPN di Windows con una console via cavo: gateway PC o router

Le console che non possono eseguire il client VPN a volte possono prendere in prestito il tunnel di un PC Windows, e questa soluzione fallisce più spesso di quanto riesca, per motivi che non hanno nulla a che vedere con la VPN. Il PC deve diventare un gateway: un’interfaccia dedicata verso valle, l’indirizzamento per la console, la traduzione e un client disposto a inoltrare i pacchetti di un altro dispositivo. Un tunnel che funziona per le applicazioni del PC non dimostra nulla di tutto ciò.

Il confronto che vale la pena fare è tra questa soluzione e un router che possiede il tunnel per l’intera rete. Differiscono nella manutenzione, nel comportamento in caso di guasto e in quanta parte della politica si riesce a vedere in una volta.

Che cosa deve fare il gateway PC

Un gateway ha bisogno di un’interfaccia rivolta alla console, di un intervallo di indirizzi per quel segmento e di una regola di traduzione che riscriva il traffico della console sul tunnel. Ha anche bisogno che il client inoltri pacchetti che non ha originato, e questa è un’impostazione diversa dall’accettare il proprio traffico. La risoluzione dei nomi deve percorrere lo stesso cammino, altrimenti la console risolve un servizio di gioco attraverso una rotta e poi si connette attraverso un’altra. Ognuno di questi è un passo di configurazione separato con il proprio modo di fallire.

console -> dedicated ethernet -> windows sharing / nat
        -> selected tunnel interface -> internet

La condivisione della connessione Internet di Windows offre esattamente questa forma, con una connessione designata come pubblica e un’altra come privata. Quella designazione conta più di quanto la gente si aspetti, perché l’interfaccia che raggiunge il router di casa non è automaticamente quella che trasporta il tunnel.

I confronti che decidono

Tre differenze separano un gateway PC da un gateway router, e sono quelle che emergono mesi dopo. La tabella le mette a confronto.

Il legame con la sessione è la prima differenza e quella che sorprende. Un PC che va in sospensione, si disconnette o installa un aggiornamento smette di essere un gateway, e la console perde il suo cammino senza che nessuna configurazione cambi. La visibilità della politica è la seconda, perché le regole del client e lo strato di condivisione vivono in due posti e nessuno dei due descrive l’altro. Il servizio degli indirizzi è la terza, e spiega una console che possiede un indirizzo eppure non raggiunge nulla.

Niente di tutto ciò rende sbagliata la soluzione PC. La rende un progetto temporaneo, il che è accettabile quando il requisito è temporaneo.

Il traffico inoltrato è un’altra categoria

Un client desktop può trattare i pacchetti inoltrati per un altro dispositivo in modo diverso dai propri. Un elenco di inclusione per applicazione copre i processi sul PC e non dice nulla del traffico di una console, mentre un interruttore di emergenza che protegge le applicazioni locali può non proteggere affatto il percorso inoltrato. Verificate il comportamento documentato del client per il traffico inoltrato invece di dedurlo da un caricamento di pagina riuscito sul PC. Dove quel comportamento non è chiaro, l’intera soluzione poggia su un’ipotesi.

L’indirizzamento della console deve venire dalla soluzione di condivisione, mai dalla copia dell’indirizzo del tunnel del PC su di essa. La copia produce un indirizzo duplicato, un gateway errato e un resolver che punta a qualcosa che la console non può raggiungere. Lasciate che il servizio a valle distribuisca la configurazione, poi verificate che cosa ha ricevuto davvero la console.

Verificate il traffico della console, non quello del PC

L’unico test significativo osserva il cammino della console. Sul PC, i comandi qui sotto mostrano la disposizione delle interfacce, la tabella dei vicini sul collegamento a valle e se la console risponde su una porta di servizio. Eseguiteli mentre una sessione di gioco è davvero connessa.

Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4Address
Get-NetAdapter | Select-Object Name, Status, LinkSpeed
arp -a | findstr 192.168.137.
Test-NetConnection 192.168.137.10 -Port 3074

Un’interfaccia senza indirizzo sul lato a valle significa che la condivisione non è mai partita, il che è un problema diverso da una console che non riesce a connettersi. Una voce per la console nella tabella dei vicini prova che il collegamento e l’indirizzamento sono vivi. Un test di porta che fallisce dopo indica l’inoltro o il trattamento del traffico inoltrato da parte del client, non il cavo. Confrontate l’indirizzo di uscita della console con quello del PC prima di concludere che il tunnel è il cammino in uso.

Tenete documentata la soluzione con i nomi delle interfacce e gli intervalli di indirizzi. Quando si romperà dopo il prossimo aggiornamento, quella pagina farà risparmiare un’ora di riscoperta.