Raggiungere un sito HTTPS accessibile solo via VPN con un inoltro SSH

Una macchina ha già un accesso VPN approvato, una seconda macchina ha bisogno di esattamente un servizio HTTPS privato, e un inoltro SSH locale può colmare questa lacuna senza dare alla seconda macchina un tunnel. L'inoltro trasporta una sola destinazione TCP invece dell'intera rete, e proprio questo limite è il punto. Seguite i cinque passaggi qui sotto in ordine, perché ognuno fallisce per un motivo diverso e un passaggio successivo non può salvare una lacuna precedente. Se manca una qualsiasi condizione preliminare, questo progetto non la risolve e nessuna messa a punto dei comandi servirà.

Passo uno: confermate le tre condizioni preliminari

Tre cose devono già essere vere prima che qualsiasi comando conti. Serve l'autorizzazione a usare la prima macchina come host di inoltro, un accesso SSH funzionante ad essa e una politica del server che consenta la destinazione prevista. Un account SSH creato per il trasferimento di file può avere l'inoltro disabilitato, e un server che consente l'inoltro può comunque limitare quali destinazioni sono raggiungibili attraverso di esso. Chiedete prima di provare, perché usare la postazione di un collega come punto di salto senza accordo è un problema di politica, anche quando il comando funziona senza intoppi.

Due comandi risolvono la metà tecnica di quell'elenco. Il primo dimostra che l'account e la chiave funzionano senza un prompt interattivo, e il secondo stampa la politica effettiva del server invece dell'esempio commentato nel file di configurazione.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Passo due: collegate una porta di loopback e mantenete viva la sessione

Sulla macchina che esegue l'applicazione client, aprite un inoltro locale verso il servizio privato. Collegatelo esplicitamente al loopback perché non venga pubblicato sulla rete locale, e scegliete una porta alta che nessun servizio locale occupi già. Mantenete la sessione in esecuzione mentre lavorate, perché chiuderla chiude l'ascoltatore. ExitOnForwardFailure trasforma un collegamento rifiutato o una porta occupata in un'uscita immediata invece che in una sessione che resta attiva senza inoltro, e questa è la modalità di guasto che fa perdere più tempo.

La connessione privata viene stabilita dall'host di salto, quindi il suo DNS, le sue rotte, la sua politica VPN e il suo accesso al servizio devono funzionare tutti. La sessione SSH non crea raggiungibilità che l'host di salto non ha, e non può riparare una rotta che la VPN non ha mai spinto. Confermate l'ascoltatore dove si trova davvero invece di fidarvi del silenzio del comando.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Passo tre: conservate il nome HTTPS quando il socket è locale

Navigare verso https://127.0.0.1:9443/ cambia il nome del server TLS e l'autorità dell'applicazione. Un certificato emesso per portal.lab.example non verrà convalidato contro un indirizzo di loopback, e l'errore risultante sembra un certificato rotto più che una scorciatoia di inoltro. Per una prova da riga di comando, conservate l'URL reale e cambiate solo la destinazione del socket. È ciò che fa --connect-to, e il manuale di curl documenta la forma a quattro campi usata qui sotto.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

Il nome resta nell'URL, nella stretta di mano TLS e nell'intestazione Host, mentre la connessione TCP va all'ascoltatore locale. L'opzione senza proxy mantiene la prova su questo inoltro invece di lasciare che un proxy HTTP configurato la intercetti, e tenere attiva la verifica dei certificati è ciò che rende significativo il risultato.

Passo quattro: sappiate cosa non può coprire un solo inoltro

Un solo inoltro TCP copre una porta di destinazione. Una pagina che reindirizza a un secondo nome host, carica risorse da un host all'interno della rete privata o invia a un'altra porta ha bisogno del proprio inoltro, e ciascuno di essi richiede lo stesso controllo di politica del primo. I flussi di lavoro del browser aggiungono requisiti propri, perché al browser va detto di inviare il nome reale alla porta locale tramite una configurazione proxy o una mappatura locale. Una prova da riga di comando riuscita non dimostra quindi che il browser ci riuscirà, anche se dimostra il percorso.

UDP, l'individuazione SMB e l'accesso al dominio non passano affatto attraverso un inoltro TCP. Se il requisito reale è l'accesso generale alla rete, questo progetto è lo strumento sbagliato e un gateway di accesso remoto supportato è quello giusto.

Passo cinque: pulite e annotate

Fermate la sessione quando la prova è finita e confermate che l'ascoltatore è sparito. Se la porta scelta era già occupata, scegliete un'altra porta di loopback inutilizzata e aggiornate insieme l'URL, il comando di prova e la nota, invece di fermare un servizio locale non correlato per liberare il numero. Lasciare un inoltro aperto su un portatile trasforma una diagnosi in un servizio non gestito.

Annotate l'host di salto, la destinazione inoltrata, la porta locale e chi ha approvato l'accordo. Un inoltro che esiste solo nella cronologia shell di qualcuno è a un riavvio da un'indagine ripetuta, e la persona successiva non saprà quale delle tre condizioni preliminari è già stata verificata.