Proxy HTTP, tunel SSH alebo VPN: vyberte správnu vrstvu

Opýtajte sa troch inženierov, ako sa dostať k internej službe, a dostanete tri návrhy: webový proxy, tunel SSH alebo plnohodnotný VPN. Všetky tri dokážu sprístupniť vzdialenú službu a všetky tri dokážu, aby prevádzka vyzerala, akoby prichádzala odinakiaľ. Rozdiely sa ukážu neskôr, keď použitý protokol nie je ten, ktorý zvolený nástroj predpokladá. Návrh, ktorý prejde rýchlou kontrolou v prehliadači, často zlyhá v aplikácii, pre ktorú bol vyžiadaný.

Rozhodnite podľa dvoch faktov: ktoré protokoly musia prejsť a kto dokáže vyriešiť príslušné názvy. Všetko ostatné je preferencia.

Proxy prenáša len to, čomu rozumie

Webový proxy analyzuje protokol, pre ktorý bol vytvorený. Klient mu odovzdá požiadavku a on ju odovzdá ďalej, takže aplikácia bez nastavenia proxy sa vôbec nezúčastňuje. Pre HTTPS klient potrebuje nepriehľadný kanál, ktorý proxy poskytuje cez CONNECT, a nie čítaním požiadavky.

Dynamické presmerovanie SSH otvára lokálny port, ktorý hovorí SOCKS, a ten port prenáša TCP tok na ľubovoľné miesto, ktoré klient uvedie. Protokoly postavené na TCP cez neho zvyčajne fungujú. UDP nie, ak nástroj výslovne nepridá podporu. Lokálne presmerovanie je ešte užšie: jeden lokálny port mapovaný na jeden pevný hostiteľ a port, čo obsluhuje jednu známu službu a nič viac.

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

VPN prenáša pakety. Všetko, čo klient smeruje do tunela, ním prechádza, vrátane UDP a ICMP, preto sa hodí na požiadavku siete, a nie na jedno spojenie.

Niekto musí vyriešiť názov

Keď cieľový názov existuje iba v DNS vzdialenej siete, stroj, ktorý vyhľadávanie vykonáva, musí tú zónu vidieť. Webový proxy vyhľadávanie robí sám, takže interný názov cez neho funguje aj vtedy, keď ho laptop vôbec nedokáže vyriešiť. SOCKS sa môže správať rovnako, ale len ak klient prepošle názov namiesto pripojenia k adrese, ktorú už vyriešil. Táto voľba je v klientovi, nie v serveri.

curl ukazuje rozdelenie jasne: jeden prepínač odovzdá názov hostiteľa proxy, druhý ho najprv vyrieši lokálne. Pri lokálnom riešení interný názov zlyhá skôr, než sa tunel vôbec dotkne, a chyba obviňuje proxy z niečoho, čo bolo v skutočnosti rozhodnutím DNS.

VPN ide treťou cestou: nainštaluje súkromný resolver a doménu vyhľadávania vedľa trás. To je pohodlné a vytvára známu ilúziu: trasa, ktorá existuje s resolverom, ktorý neodpovedá, vyzerá presne ako mŕtvy tunel, hoci pakety sa dostávajú na druhú stranu.

Keď sieť povoľuje iba jeden východ

Mnohé podnikové siete povoľujú odchádzajúce spojenia výhradne cez autentifikovaný webový proxy. OpenVPN a SSH sa tam dajú obe rozbehnúť, prvý tunelovaním vlastnej dopravy cez proxy, druhý cez proxy príkaz, ktorý spúšťa malého pomocníka CONNECT.

Tunely postavené na TCP toto obmedzenie prežijú a VPN založený na UDP nie, čo vysvetľuje veľa konfigurácií, ktoré fungujú doma a zlyhávajú v kancelárii. Druhú cenu je ľahké prehliadnuť: TCP tunel nesený v proxyovanom TCP spojení má teraz dve vrstvy, ktoré opakovane prenášajú, a pri stratách sa táto dvojica zasekne spôsobom, ktorý žiadna vrstva sama nevytvára.

Reťazenie sprostredkovateľov je iná otázka než výber vrstvy. Pridanie druhého proxy alebo Tora mení, kto čo pozoruje, a pozícia v reťazi rozhoduje, ktorý skok vidí šifrovaný text.

Poradie je dôležitejšie než počet skokov. Vonkajší skok vidí šifrovaný tok, kým vnútorný vidí čistý text, ktorý nesie, takže reťaz je len taká súkromná, ako jej najnedbalovejší článok. Miešanie protokolov medzi skokmi to automaticky nezlepšuje. Väčšinou len sťažuje uvažovanie o režimoch zlyhania.

Falšovaná adresa nie je jednou z možností

Vytváranie paketov s cudzou zdrojovou adresou nič užitočné nedosiahne: odpovede idú skutočnému majiteľovi a väčšina sietí prevádzku jednoducho zahodí. Sprostredkovateľ je potrebný práve preto, že zdroj sa nedá vymyslieť, a to je čestné odôvodnenie všetkých troch návrhov.

To zároveň ohraničuje, čo ktorýkoľvek z nich môže tvrdiť. Vyzeráť ako niekto prichádzajúci z konkrétnej adresy je otázka toho, kde je tá adresa legitímne pridelená a kto ju môže smerovať, nie toho, ktorý nástroj dokáže sfalšovať hlavičku. Ak návrh predpokladá niečo iné, predpoklad zlyhá u prvého poskytovateľa, ktorý ho odfiltruje. Zapíšte predpoklad, aby bola porucha rozpoznateľná, keď príde.

Rozhodujte podľa protokolov a názvov

Siahnite po proxy, keď jeden webový klient potrebuje jednu webovú službu a má nastavenia proxy. Siahnite po tuneli SSH, keď stačí niekoľko známych služieb TCP a prístup cez SSH už existuje. Siahnite po VPN, keď je súčasťou požiadavky viac aplikácií, prevádzka mimo TCP, súkromný DNS alebo opakovane použiteľná cesta.

Potom overte skutočným klientom a skutočným názvom. Načítanie stránky cez proxy vás nenaučí nič o UDP a rozbehnutie jedného nástroja cez SOCKS vás nenaučí nič o systémovom resolveri. Prečítajte, akú lokálnu adresu proces pripojil a ktorý resolver odpovedal. To je rozdiel medzi cestou, ktorá funguje, a tou, ktorá raz náhodou fungovala.