HTTP-proxy, SSH-tunnel eller VPN: välj rätt lager

Fråga tre ingenjörer hur man når en intern tjänst och du får tre lösningar: en webbproxy, en SSH-tunnel eller en full VPN. Alla tre kan göra en fjärrtjänst nåbar, och alla tre kan få trafik att se ut som den kommer någon annanstans ifrån. Skillnaderna visar sig senare, när protokollet som används inte är det som verktyget förutsätter. En lösning som klarar ett snabbt brysertest misslyckas ofta i applikationen som motiverade begäran.

Avgör från två fakta: vilka protokoll som måste passera och vem som kan matcha namnen som är inblandade. Allt annat är preferens.

En proxy flyttar bara det den förstår

En webbproxy tolkar protokollet den byggdes för. Klienten lämnar en begäran och den skickar begäran vidare, så en applikation utan proxyinställning deltar inte alls. För HTTPS behöver klienten en ogenomskinlig kanal, som proxyn tillhandahåller via CONNECT i stället för att läsa begäran.

En dynamisk SSH-vidarebefordran öppnar en lokal port som talar SOCKS, och den porten vidarebefordrar en TCP-ström till vilket mål klienten än anger. Protokoll byggda på TCP fungerar vanligtvis genom den. UDP gör det inte, om inte ett verktyg lägger till stöd uttryckligen. En lokal vidarebefordran är ännu snävare: en lokal port mappad till en fast värd och port, vilket betjänar en enda känd tjänst och inget mer.

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

En VPN flyttar paket. Allt klienten dirigerar in i tunneln passerar den, UDP och ICMP inkluderat, vilket är varför den passar ett nätverkskrav snarare än en enda anslutning.

Någon måste matcha namnet

När målnamnet bara finns i fjärrnätverkets DNS måste den maskin som gör slaget kunna se zonen. En webbproxy gör slaget själv, så ett internt namn fungerar genom den även när laptopen inte kan matcha namnet alls. SOCKS kan bete sig likadant, men bara om klienten vidarebefordrar namnet i stället för att ansluta till en adress den redan matchat. Det valet ligger i klienten, inte i servern.

curl visar uppdelningen tydligt: en flagga skickar värdnamnet till proxyn, en annan matchar det lokalt först. Med lokal matchning misslyckas ett internt namn innan någon tunnel berörs, och felet skyller på proxyn för något som egentligen var ett DNS-beslut.

En VPN tar den tredje vägen genom att installera den privata resolvern och sökdomänen bredvid rutterna. Det är bekvämt och skapar en välbekant illusion: en rutt som finns med en resolver som inte svarar ser exakt ut som en död tunnel, fastän paketen når andra sidan.

När nätet bara tillåter en utgång

Många företagsnät tillåter utgående anslutningar enbart genom en autentiserad webbproxy. OpenVPN och SSH kan båda fås att fungera där, den första genom att tunnla sin egen transport genom proxyn och den andra genom ett proxykommando som kör en liten CONNECT-hjälpare.

Tunnlar byggda på TCP överlever den begränsningen, och en UDP-baserad VPN gör det inte, vilket förklarar väldigt många konfigurationer som fungerar hemma och misslyckas på ett kontor. En andra kostnad är lätt att missa: en TCP-tunnel som bärs inuti en proxad TCP-anslutning har nu två lager som sänder om, och vid förlust stannar den kombinationen på ett sätt som inget av lagren skapar ensamt.

Att kedja mellanhänder är en annan fråga än att välja lager. Att lägga till en andra proxy eller Tor ändrar vem som observerar vad, och positionen i kedjan avgör vilket hopp som ser chiffertext.

Ordningen spelar större roll än antalet hopp. Ett yttre hopp ser en krypterad ström medan ett inre ser klartexten den bär, så en kedja är bara så privat som dess minst noggranna länk. Att blanda protokoll mellan hopp förbättrar inte det automatiskt. Det gör mest fellägena svårare att resonera om.

En förfalskad adress är inte ett av alternativen

Att skapa paket med någon annans källadress uppnår inget användbart: svaren går till den verkliga ägaren, och de flesta nät släpper trafiken direkt. En mellanhand krävs just eftersom källan inte kan hittas på, och det är det ärliga skälet för alla tre lösningarna.

Det begränsar också vad någon av dem kan påstå. Att se ut att komma från en viss adress är en fråga om var den adressen är lagligt tilldelad och vem som får routa den, inte om vilket verktyg som kan förfalska ett huvud. Om en lösning förutsätter något annat brister antagandet hos den första leverantör som filtrerar det. Skriv ner antagandet så att felet går att känna igen när det kommer.

Avgör efter protokoll och namn

Välj en proxy när en enda webbklient behöver en enda webbtjänst och har proxyinställningar. Välj en SSH-tunnel när några få kända TCP-tjänster räcker och SSH-åtkomst redan finns. Välj en VPN när flera applikationer, icke-TCP-trafik, privat DNS eller en återanvändbar väg ingår i kravet.

Verifiera sedan med den riktiga klienten och det riktiga namnet. Att läsa in en sida genom en proxy lär dig inget om UDP, och att få ett verktyg att fungera över SOCKS lär dig inget om systemets resolver. Läs vilken lokal adress processen band och vilken resolver som svarade. Det är skillnaden mellan en väg som fungerar och en som råkade fungera en gång.