Proxy HTTP, tunnel SSH o VPN: scegliere il livello giusto

Chiedete a tre ingegneri come raggiungere un servizio interno e otterrete tre progetti: un proxy web, un tunnel SSH o una VPN completa. Tutti e tre possono mettere un servizio remoto a portata di mano, e tutti e tre possono far sembrare che il traffico arrivi da altrove. Le differenze emergono più tardi, quando il protocollo in uso non è quello che lo strumento scelto presuppone. Un progetto che supera un rapido controllo nel browser fallisce regolarmente sull'applicazione che ha motivato la richiesta.

Decidete in base a due fatti: quali protocolli devono attraversare e chi può risolvere i nomi coinvolti. Tutto il resto è preferenza.

Un proxy sposta solo ciò che capisce

Un proxy web analizza il protocollo per cui è stato costruito. Il client gli consegna una richiesta ed esso la consegna oltre, così un'applicazione senza impostazioni proxy non partecipa affatto. Per HTTPS il client ha bisogno di un canale opaco, che il proxy fornisce tramite CONNECT invece di leggere la richiesta.

Un inoltro dinamico SSH apre una porta locale che parla SOCKS, e quella porta inoltra un flusso TCP verso qualsiasi destinazione nominata dal client. I protocolli costruiti su TCP generalmente funzionano attraverso di essa. UDP no, a meno che uno strumento aggiunga il supporto esplicitamente. Un inoltro locale è ancora più stretto: una porta locale mappata su un host e una porta fissi, che serve un solo servizio noto e nulla di più.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

Una VPN sposta pacchetti. Tutto ciò che il client instrada nel tunnel lo attraversa, UDP e ICMP inclusi, per questo si adatta a un requisito di rete e non a una singola connessione.

Qualcuno deve risolvere il nome

Quando il nome di destinazione esiste solo nel DNS della rete remota, la macchina che esegue la ricerca deve poter vedere quella zona. Un proxy web esegue la ricerca da sé, quindi un nome interno funziona attraverso di esso anche quando il portatile non riesce affatto a risolvere il nome. SOCKS può comportarsi allo stesso modo, ma solo se il client inoltra il nome invece di connettersi a un indirizzo che ha già risolto. Quella scelta sta nel client, non nel server.

curl mostra chiaramente la separazione: un'opzione passa il nome host al proxy, un'altra lo risolve prima in locale. Con la risoluzione locale un nome solo interno fallisce prima di toccare qualsiasi tunnel, e l'errore incolpa il proxy di ciò che in realtà era una decisione DNS.

Una VPN prende la terza via installando il resolver privato e il dominio di ricerca accanto alle rotte. È comodo, e fabbrica un'illusione familiare: una rotta che esiste con un resolver che non risponde sembra esattamente un tunnel morto, anche se i pacchetti raggiungono l'altro lato.

Quando la rete consente una sola uscita

Molte reti aziendali consentono connessioni in uscita solo attraverso un proxy web autenticato. OpenVPN e SSH possono entrambi essere fatti funzionare lì, il primo incanalando il proprio trasporto attraverso il proxy e il secondo tramite un comando proxy che esegue un piccolo helper CONNECT.

I tunnel costruiti su TCP sopravvivono a quel vincolo, e una VPN basata su UDP no, il che spiega moltissime configurazioni che funzionano a casa e falliscono in ufficio. Un secondo costo è facile da trascurare: un tunnel TCP portato dentro una connessione TCP con proxy ha ora due livelli che ritrasmettono, e sotto perdita quella coppia si blocca in un modo che nessun livello produce da solo.

Concatenare intermediari è una questione diversa dallo scegliere un livello. Aggiungere un secondo proxy o Tor cambia chi osserva cosa, e la posizione nella catena decide quale salto vede il testo cifrato.

L'ordine conta più del numero di salti. Un salto esterno osserva un flusso cifrato mentre uno interno vede il testo in chiaro che trasporta, quindi una catena è privata quanto il suo anello meno accurato. Mescolare protocolli tra i salti non lo migliora automaticamente. Soprattutto rende le modalità di guasto più difficili da ragionare.

Un indirizzo falsificato non è una delle opzioni

Creare pacchetti con l'indirizzo di origine di qualcun altro non ottiene nulla di utile: le risposte viaggiano verso il vero proprietario, e la maggior parte delle reti scarta il traffico senza altro. Serve un intermediario proprio perché l'origine non può essere inventata, e questa è la giustificazione onesta dei tre progetti.

Ciò limita anche ciò che ciascuno può affermare. Sembrare originato da un indirizzo particolare è una questione su dove quell'indirizzo sia legittimamente assegnato e chi possa instradarlo, non su quale strumento possa falsificare un'intestazione. Se un progetto presuppone il contrario, il presupposto fallisce al primo fornitore che lo filtra. Scrivete il presupposto perché il guasto sia riconoscibile quando arriva.

Decidete per protocolli e nomi

Scegliete un proxy quando un solo client web ha bisogno di un solo servizio web e dispone di impostazioni proxy. Scegliete un tunnel SSH quando bastano una manciata di servizi TCP noti e l'accesso SSH esiste già. Scegliete una VPN quando più applicazioni, traffico non TCP, DNS privato o un percorso riutilizzabile fanno parte del requisito.

Poi verificate con il client reale e il nome reale. Caricare una pagina attraverso un proxy non vi insegna nulla su UDP, e far funzionare uno strumento su SOCKS non vi insegna nulla sul resolver di sistema. Leggete quale indirizzo locale ha vincolato il processo e quale resolver ha risposto. Questa è la differenza tra un percorso che funziona e uno che ha funzionato per caso una volta.