HTTP proxy, SSH tunel, nebo VPN: vyberte správnou vrstvu

Zeptejte se tří inženýrů, jak se dostat k interní službě, a dostanete tři návrhy: webový proxy, SSH tunel nebo plnohodnotnou VPN. Všechny tři umí zpřístupnit vzdálenou službu a všechny tři umí provoz ukázat, jako by přicházel odjinud. Rozdíly se objeví později, když používaný protokol není ten, který zvolený nástroj předpokládá. Návrh, který projde rychlou kontrolou v prohlížeči, pravidelně selhává v aplikaci, která požadavek vyvolala.

Rozhodujte ze dvou faktů: které protokoly musí projít a kdo dokáže přeložit dotčená jména. Vše ostatní je preference.

Proxy přenáší jen to, čemu rozumí

Webový proxy analyzuje protokol, pro který byl postaven. Klient mu předá požadavek a on jej předá dál, takže aplikace bez nastavení proxy se vůbec neúčastní. Pro HTTPS klient potřebuje neprůhledný kanál a proxy jej poskytne přes CONNECT, nikoli čtením požadavku.

Dynamické přesměrování SSH otevře místní port, který mluví SOCKS, a ten přeposílá TCP proud na libovolné cílové místo, které klient jmenuje. Protokoly postavené na TCP přes něj obvykle fungují. UDP ne, pokud nástroj výslovně nepřidá podporu. Místní přesměrování je ještě užší: jeden místní port namapovaný na jeden pevný hostitel a port, což obsluhuje jednu známou službu a nic víc.

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

VPN přenáší pakety. Vše, co klient pošle do tunelu, jím projde, včetně UDP a ICMP, proto se hodí pro požadavek sítě, nikoli jednoho spojení.

Někdo musí jméno přeložit

Když cílové jméno existuje jen v DNS vzdálené sítě, stroj, který dotaz provádí, musí onu zónu vidět. Webový proxy dotaz provádí sám, takže interní jméno přes něj funguje, i když laptop jméno vůbec přeložit nedokáže. SOCKS se může chovat stejně, ale jen pokud klient jméno předá dál, místo aby se připojil k adrese, kterou už přeložil. Tato volba je v klientu, ne v serveru.

curl rozdíl ukazuje jasně: jeden přepínač předá jméno hostitele proxy, druhý je nejprve přeloží lokálně. Při lokálním překladu interní jméno selže dřív, než se čehokoli tunelového dotkne, a chyba obviňuje proxy z toho, co bylo ve skutečnosti rozhodnutím DNS.

VPN jde třetí cestou: vedle tras nainstaluje privátní resolver a doménu hledání. To je pohodlné a vytváří známou iluzi: trasa, která existuje s resolverem, jenž neodpovídá, vypadá přesně jako mrtvý tunel, i když pakety na druhou stranu dorazí.

Když síť povoluje jen jeden východ

Mnoho podnikových sítí povoluje odchozí spojení pouze přes ověřený webový proxy. OpenVPN a SSH tam obojí lze zprovoznit: první tunelováním vlastního transportu přes proxy, druhé příkazem proxy, který spouští malý pomocník CONNECT.

Tunely postavené na TCP toto omezení přežijí, VPN postavená na UDP ne, což vysvětluje mnoho konfigurací, které doma fungují a v kanceláři selžou. Druhou cenu snadno přehlédnete: TCP tunel nesený v TCP spojení přes proxy má nyní dvě vrstvy, které přeposílají, a při ztrátách se tato dvojice zasekne způsobem, který žádná vrstva sama nevytváří.

Řetězení prostředníků je jiná otázka než volba vrstvy. Přidání druhého proxy nebo Toru mění, kdo co pozoruje, a pozice v řetězu rozhoduje, který skok vidí šifrovaný text.

Pořadí je důležitější než počet skoků. Vnější skok sleduje šifrovaný proud, zatímco vnitřní vidí otevřený text, který nese, takže řetěz je soukromý jen tak jako jeho nejméně pečlivý článek. Míchání protokolů mezi skoky to automaticky nezlepší. Většinou jen ztíží přemýšlení o režimech selhání.

Padělaná adresa není jednou z možností

Vytváření paketů s cizí zdrojovou adresou nic užitečného nedosáhne: odpovědi putují skutečnému majiteli a většina sítí provoz rovnou zahodí. Prostředník je nutný právě proto, že zdroj nelze vymyslet, a to je poctivé odůvodnění všech tří návrhů.

Také to omezuje, co si který z nich může nárokovat. Vypadat, že provoz pochází z určité adresy, je otázka toho, kde je tato adresa legálně přidělena a kdo ji smí směrovat, ne toho, který nástroj umí zfalšovat hlavičku. Pokud návrh předpokládá opak, předpoklad selže u prvního poskytovatele, který jej filtruje. Předpoklad si zapište, aby byla porucha rozpoznatelná, až přijde.

Rozhodujte podle protokolů a jmen

Sáhněte po proxy, když jeden webový klient potřebuje jednu webovou službu a má nastavení proxy. Sáhněte po SSH tunelu, když stačí hrstka známých TCP služeb a SSH přístup už existuje. Sáhněte po VPN, když je součástí požadavku několik aplikací, provoz mimo TCP, privátní DNS nebo znovupoužitelná cesta.

Pak ověřte skutečným klientem a skutečným jménem. Načtení stránky přes proxy vás nenaučí nic o UDP a zprovoznění jednoho nástroje přes SOCKS vás nenaučí nic o systémovém resolveru. Přečtěte si, na kterou místní adresu se proces navázal a který resolver odpověděl. To je rozdíl mezi cestou, která funguje, a tou, která jednou náhodou fungovala.