Come un inoltro locale SSH trasporta una sessione TCP OpenVPN

Qui si impilano tre trasporti, e ognuno ha la propria incorniciatura. Il carico utile della VPN viaggia dentro una sessione TLS, quella sessione TLS viaggia dentro una connessione TCP verso una porta di loopback, e i byte di quella connessione viaggiano dentro SSH verso un host di relay, che apre la vera connessione TCP verso l'ascoltatore della VPN. Nulla nell'organizzazione cambia ciò che OpenVPN autentica, e nulla in essa rende raggiungibile un ascoltatore UDP tramite TCP. Leggi il resto come descrizione del percorso dei byte, non come ricetta per aggirare un controllo di rete.

Cosa sposta davvero l'inoltro locale

Il client SSH ascolta su una porta locale. Quando un processo locale si connette, il client impacchetta i byte nel proprio canale cifrato, e il lato server apre una nuova connessione TCP verso la destinazione indicata nella richiesta di inoltro.

Quella destinazione è risolta dal relay, non dalla tua macchina, ed è per questo che un nome che esiste solo dentro la rete remota funziona ancora. Significa anche che il relay deve poter raggiungere l'ascoltatore della VPN e avere una rotta di ritorno verso di esso. Un nome che si risolve sul tuo portatile non dice nulla su ciò che il relay vede.

Avviare la sessione SSH dimostra soltanto che il relay è raggiungibile e autenticato. Non dice nulla sul fatto che l'ascoltatore successivo sia attivo, che un firewall tra il relay e l'ascoltatore accetti la connessione, o che la VPN accetti il tuo profilo.

Punta il client sull'ascoltatore locale

Un esempio dichiarato: il relay può raggiungere un ascoltatore TCP su gw.internal.example:443, e una porta locale alta espone quel percorso solo a questa macchina.

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

Il manuale di OpenSSH descrive l'inoltro locale come accettazione locale di connessioni TCP e apertura della connessione successiva dal lato remoto. Lega l'ascoltatore al loopback invece che a tutte le interfacce, perché un inoltro raggiungibile dalla rete è un relay aperto con il tuo nome sopra. Un binding con carattere jolly espone la porta anche a ogni altro account locale su una macchina condivisa.

Poi metti il client VPN in modalità TCP e puntalo su 127.0.0.1:24011. Se il profilo usa UDP, questo progetto non può aiutare: l'inoltro trasporta un flusso di byte, e non c'è alcun percorso di datagrammi attraverso di esso.

Tieni separate le due autenticazioni

SSH autentica l'host di relay. OpenVPN autentica ancora il peer VPN, e la destinazione di loopback non cambia questo requisito. Disattivare i controlli del certificato perché il socket ora punta a localhost è la scorciatoia peggiore disponibile in questo progetto. Trasforma un'organizzazione di trasporto in un'organizzazione di fiducia, e nessuno ha approvato la seconda.

Mantieni intatti l'ancora di fiducia del profilo, il controllo del ruolo server e la verifica del nome. Se il tuo client confronta il nome del server con l'indirizzo chiamato, il loopback potrebbe richiedere un'impostazione esplicita del nome invece di un controllo disattivato, e la documentazione del profilo è il posto dove confermare quale campo viene confrontato.

Tratta il relay come una seconda parte nella storia della fiducia: il suo amministratore può vedere i metadati delle connessioni e può reindirizzare l'inoltro se la configurazione cambia. L'organizzazione richiede l'approvazione sia del relay sia del proprietario del servizio VPN, non solo di chi ne ha bisogno oggi.

Non costruire un ciclo sotto il tunnel

Una volta che la VPN installa le rotte, la connessione SSH che la trasporta ha ancora bisogno di un percorso verso il relay che non passi dal tunnel. Se la rotta predefinita passa alla VPN e il relay è raggiungibile solo attraverso lo stesso tunnel, il trasporto crolla e la VPN va con esso. Il guasto sembra un tunnel caduto più che un errore di instradamento, ed è per questo che viene diagnosticato male.

La correzione abituale è una rotta host verso l'indirizzo del relay fissata all'interfaccia fisica prima che il tunnel salga, più un controllo che la rotta sopravviva a una riconnessione. Verificala con una ricerca di rotta per l'indirizzo del relay invece di supporre che l'ordine fosse corretto.

Aspettati anche che questo stack sia più lento e più fragile di una connessione diretta, perché ora ci sono due trasporti ordinati e un altro punto finale da mantenere. È un modo per attraversare un confine di rete, non una tecnica di prestazioni.

Chiudi l'ascoltatore quando hai finito

Ferma la sessione SSH quando il tunnel non serve più, e conferma che la porta locale sia stata rilasciata. Un inoltro dimenticato tiene aperto un percorso autenticato su una macchina che potrebbe essere condivisa.

Esamina anche le destinazioni di inoltro consentite del relay, perché una configurazione permissiva trasforma qualsiasi account compromesso in un pivot generale. Annota porta, relay e destinazione insieme, così la persona successiva sa a cosa serviva l'inoltro e se è ancora approvato.