Proxy HTTP, túnel SSH ou VPN: escolla a capa correcta

Pregunte a tres enxeñeiros como chegar a un servizo interno e obterá tres deseños: un proxy web, un túnel SSH ou unha VPN completa. Os tres poden poñer un servizo remoto ao seu alcance, e os tres poden facer que o tráfico pareza vir doutro lugar. As diferenzas aparecen máis tarde, cando o protocolo en uso non é o que supón a ferramenta escollida. Un deseño que supera unha comprobación rápida no navegador adoita fallar na aplicación que motivou a petición.

Decida a partir de dous feitos: que protocolos deben cruzar e quen pode resolver os nomes implicados. Todo o demais é preferencia.

Un proxy só move o que entende

Un proxy web analiza o protocolo para o que foi construído. O cliente entrégalle unha petición e el entrégaa máis adiante, así que unha aplicación sen configuración de proxy non participa en absoluto. Para HTTPS o cliente necesita unha canle opaca, que o proxy fornece mediante CONNECT en lugar de ler a petición.

Un reenvío dinámico SSH abre un porto local que fala SOCKS, e ese porto retransmite un fluxo TCP a calquera destino que o cliente nomee. Os protocolos construídos sobre TCP adoitan funcionar a través del. UDP non, salvo que unha ferramenta engada soporte de forma explícita. Un reenvío local é aínda máis estreito: un porto local asignado a un host e un porto fixos, que atende un único servizo coñecido e nada máis.

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

Unha VPN move paquetes. Todo o que o cliente encamiña cara ao túnel atravesao, UDP e ICMP incluídos, por iso encaixa cun requisito de rede e non cunha conexión única.

Alguén ten que resolver o nome

Cando o nome de destino só existe no DNS da rede remota, a máquina que fai a consulta debe poder ver esa zona. Un proxy web fai a consulta el mesmo, así que un nome interno funciona a través del mesmo cando o portátil non pode resolver o nome en absoluto. SOCKS pode comportarse igual, pero só se o cliente reenvía o nome en lugar de conectarse a un enderezo que xa resolveu. Esa elección está no cliente, non no servidor.

curl mostra a división con claridade: unha opción pasa o nome de host ao proxy, outra resólveo primeiro en local. Con resolución local, un nome só interno falla antes de tocar calquera túnel, e o erro culpa o proxy do que en realidade foi unha decisión de DNS.

Unha VPN toma a terceira vía instalando o resolutor privado e o dominio de busca xunto ás rutas. Iso é cómodo, e fabrica unha ilusión familiar: unha ruta que existe cun resolutor que non responde parece exactamente un túnel morto, aínda que os paquetes chegan ao outro lado.

Cando a rede permite unha soa saída

Moitas redes corporativas permiten conexións saíntes só a través dun proxy web autenticado. OpenVPN e SSH poden facerse funcionar alí, o primeiro tunelizando o seu propio transporte a través do proxy e o segundo mediante unha orde de proxy que executa un pequeno auxiliar CONNECT.

Os túneles construídos sobre TCP sobreviven a esa restrición, e unha VPN baseada en UDP non, o que explica moitísimas configuracións que funcionan na casa e fallan nunha oficina. Un segundo custo é fácil de pasar por alto: un túnel TCP levado dentro dunha conexión TCP con proxy ten agora dúas capas que retransmiten, e baixo perdas esa parella atascase dun xeito que ningunha capa produce soa.

Encadear intermediarios é unha cuestión distinta de escoller unha capa. Engadir un segundo proxy ou Tor cambia quen observa que, e a posición na cadea decide que salto ve o texto cifrado.

A orde importa máis que o número de saltos. Un salto externo observa un fluxo cifrado mentres un interno ve o texto plano que transporta, así que unha cadea é tan privada como o seu elo menos coidadoso. Mesturar protocolos entre saltos non o mellora automaticamente. Sobre todo fai que os modos de fallo sexan máis difíciles de razoar.

Un enderezo falsificado non é unha das opcións

Crear paquetes co enderezo de orixe doutra persoa non logra nada útil: as respostas viaxan ao propietario real, e a maioría das redes descartan o tráfico sen máis. Necesítase un intermediario precisamente porque a orixe non pode inventarse, e esa é a xustificación honesta dos tres deseños.

Tamén limita o que calquera deles pode afirmar. Parecer orixinarse nun enderezo concreto é unha cuestión sobre onde se asigna lexitimamente ese enderezo e quen pode encaminalo, non sobre que ferramenta pode falsificar unha cabeceira. Se un deseño supón o contrario, o suposto falla no primeiro provedor que o filtra. Escriba o suposto para que o fallo sexa recoñecible cando chegue.

Decida por protocolos e nomes

Recorra a un proxy cando un só cliente web necesita un só servizo web e ten configuración de proxy. Recorra a un túnel SSH cando abonda unha manchea de servizos TCP coñecidos e o acceso SSH xa existe. Recorra a unha VPN cando varias aplicacións, tráfico non TCP, DNS privado ou unha ruta reutilizable forman parte do requisito.

Logo verifique co cliente real e o nome real. Cargar unha páxina a través dun proxy non lle ensina nada sobre UDP, e facer funcionar unha ferramenta sobre SOCKS non lle ensina nada sobre o resolutor do sistema. Lea que enderezo local vinculou o proceso e que resolutor respondeu. Esa é a diferenza entre unha ruta que funciona e unha que funcionou por casualidade unha vez.