Proxy HTTP, túnel SSH o VPN: tria la capa correcta

Pregunta a tres enginyers com arribar a un servei intern i obtindràs tres dissenys: un proxy web, un túnel SSH o una VPN completa. Els tres poden posar un servei remot a l'abast, i els tres poden fer que el trànsit sembli venir d'un altre lloc. Les diferències apareixen més tard, quan el protocol en ús no és el que l'eina triada pressuposa. Un disseny que supera una comprovació ràpida al navegador falla habitualment a l'aplicació que va motivar la petició.

Decideix a partir de dos fets: quins protocols han de travessar i qui pot resoldre els noms implicats. La resta és preferència.

Un proxy només mou allò que entén

Un proxy web analitza el protocol per al qual es va construir. El client li lliura una petició i ell la lliura endavant, així que una aplicació sense configuració de proxy no hi participa gens. Per a HTTPS el client necessita un canal opac, que el proxy proporciona mitjançant CONNECT en lloc de llegir la petició.

Un reenviament dinàmic SSH obre un port local que parla SOCKS, i aquest port retransmet un flux TCP a qualsevol destinació que el client anomeni. Els protocols basats en TCP generalment hi funcionen. UDP no, tret que una eina afegeixi suport explícitament. Un reenviament local és encara més estret: un port local mapat a un host i un port fixos, que serveix un sol servei conegut i res més.

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

Una VPN mou paquets. Tot el que el client encamina cap al túnel el travessa, UDP i ICMP inclosos, i per això s'ajusta a un requisit de xarxa i no a una connexió única.

Algú ha de resoldre el nom

Quan el nom objectiu només existeix al DNS de la xarxa remota, la màquina que fa la consulta ha de poder veure aquella zona. Un proxy web fa la consulta ell mateix, així que un nom intern hi funciona fins i tot quan l'ordinador portàtil no pot resoldre el nom de cap manera. SOCKS es pot comportar igual, però només si el client reenvia el nom en lloc de connectar-se a una adreça que ja ha resolt. Aquesta elecció és al client, no al servidor.

curl mostra la divisió amb claredat: una opció passa el nom d'host al proxy, una altra el resol primer localment. Amb resolució local, un nom només intern falla abans de tocar cap túnel, i l'error culpa el proxy d'allò que en realitat era una decisió de DNS.

Una VPN pren la tercera via instal·lant el resolutor privat i el domini de cerca al costat de les rutes. Això és còmode i fabrica una il·lusió familiar: una ruta que existeix amb un resolutor que no respon sembla exactament un túnel mort, tot i que els paquets arriben a l'altre costat.

Quan la xarxa només permet una sortida

Moltes xarxes corporatives permeten connexions sortints només a través d'un proxy web autenticat. OpenVPN i SSH es poden fer funcionar allà: el primer tunelitzant el seu propi transport a través del proxy i el segon mitjançant una ordre de proxy que executa un petit auxiliar CONNECT.

Els túnels basats en TCP sobreviuen a aquesta restricció, i una VPN basada en UDP no, cosa que explica moltes configuracions que funcionen a casa i fallen a l'oficina. Un segon cost és fàcil de passar per alt: un túnel TCP portat dins d'una connexió TCP amb proxy té ara dues capes que retransmeten, i sota pèrdues aquesta parella s'encalla d'una manera que cap capa produeix sola.

Encadenar intermediaris és una qüestió diferent de triar una capa. Afegir un segon proxy o Tor canvia qui observa què, i la posició a la cadena decideix quin salt veu el text xifrat.

L'ordre importa més que el nombre de salts. Un salt extern observa un flux xifrat mentre un d'intern veu el text pla que porta, així que una cadena és tan privada com el seu enllaç menys curós. Barrejar protocols entre salts no ho millora automàticament. Sobretot fa que els modes de fallada siguin més difícils de raonar.

Una adreça falsificada no és una de les opcions

Crear paquets amb l'adreça d'origen d'una altra persona no aconsegueix res útil: les respostes viatgen al propietari real, i la majoria de xarxes descarten el trànsit directament. Cal un intermediari precisament perquè l'origen no es pot inventar, i aquesta és la justificació honesta dels tres dissenys.

També limita què pot pretendre cadascun d'ells. Semblar que s'origina en una adreça concreta és una qüestió sobre on s'assigna legítimament aquesta adreça i qui pot encaminar-la, no sobre quina eina pot falsificar una capçalera. Si un disseny pressuposa el contrari, el pressupòsit falla al primer proveïdor que el filtra. Anota el pressupòsit perquè la fallada sigui recognoscible quan arribi.

Decideix per protocols i noms

Tria un proxy quan un sol client web necessita un sol servei web i té configuració de proxy. Tria un túnel SSH quan una grapat de serveis TCP coneguts és suficient i l'accés SSH ja existeix. Tria una VPN quan diverses aplicacions, trànsit no TCP, DNS privat o un camí reutilitzable formen part del requisit.

Després verifica amb el client real i el nom real. Carregar una pàgina a través d'un proxy no t'ensenya res sobre UDP, i fer funcionar una eina sobre SOCKS no t'ensenya res sobre el resolutor del sistema. Llegeix quina adreça local ha lligat el procés i quin resolutor ha respost. Aquesta és la diferència entre un camí que funciona i un que va funcionar per casualitat una vegada.