HTTP proxy, SSH tunel ili VPN: izaberite pravi sloj

Pitajte tri inženjera kako doći do internog servisa i dobićete tri rješenja: web proxy, SSH tunel ili puni VPN. Sva tri mogu približiti udaljeni servis i sva tri mogu učiniti da saobraćaj izgleda kao da dolazi s drugog mjesta. Razlike se pokažu kasnije, kada protokol koji se koristi nije onaj koji odabrani alat pretpostavlja. Rješenje koje prođe brzu provjeru u pregledaču redovno zakaže u aplikaciji zbog koje je zatraženo.

Odlučite na osnovu dvije činjenice: koji protokoli moraju proći i ko može razriješiti imena koja su uključena. Sve ostalo je sklonost.

Proxy prenosi samo ono što razumije

Web proxy parsira protokol zbog kojeg je napravljen. Klijent mu preda zahtjev, a on ga proslijedi dalje, pa aplikacija bez proxy postavki uopšte ne učestvuje. Za HTTPS klijentu treba neproziran kanal, koji proxy obezbjeđuje kroz CONNECT, a ne čitanjem zahtjeva.

SSH dinamički forward otvara lokalni port koji govori SOCKS, a taj port prenosi TCP tok ka bilo kojoj destinaciji koju klijent navede. Protokoli izgrađeni na TCP-u obično rade kroz njega. UDP ne, osim ako alat izričito doda podršku. Lokalni forward je još uži: jedan lokalni port mapiran na jedan fiksni host i port, što služi jednom poznatom servisu i ničemu više.

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

VPN prenosi pakete. Sve što klijent usmjeri u tunel prolazi kroz njega, uključujući UDP i ICMP, zato odgovara mrežnom zahtjevu, a ne jednom spoju.

Neko mora razriješiti ime

Kada ciljno ime postoji samo u DNS-u udaljene mreže, mašina koja obavlja pretragu mora vidjeti tu zonu. Web proxy pretragu obavlja sam, pa interno ime radi kroz njega čak i kada laptop ne može uopšte razriješiti ime. SOCKS se može ponašati isto, ali samo ako klijent proslijedi ime umjesto da se spoji na adresu koju je već razriješio. Taj izbor je u klijentu, ne u serveru.

curl jasno pokazuje podjelu: jedan flag predaje ime hosta proxyju, drugi ga prvo razrješava lokalno. Uz lokalno razrješavanje interno ime zakaže prije nego što se tunel uopšte dotakne, a greška okrivljuje proxy za nešto što je zapravo bila DNS odluka.

VPN bira treći put: instalira privatni resolver i domen pretrage pored ruta. To je zgodno i stvara poznatu iluziju: ruta koja postoji uz resolver koji ne odgovara izgleda tačno kao mrtav tunel, iako paketi stižu na drugu stranu.

Kada mreža dozvoljava samo jedan izlaz

Mnoge korporativne mreže dozvoljavaju odlazne veze isključivo kroz autentifikovani web proxy. OpenVPN i SSH mogu oba raditi tamo, prvi tuneliranjem vlastitog transporta kroz proxy, drugi kroz proxy naredbu koja pokreće mali CONNECT pomoćnik.

Tuneli izgrađeni na TCP-u preživljavaju to ograničenje, a VPN zasnovan na UDP-u ne, što objašnjava mnoge konfiguracije koje rade kod kuće i zakažu u kancelariji. Drugi trošak je lako previdjeti: TCP tunel nošen unutar proxiranog TCP spoja sada ima dva sloja koja ponovo prenose, a pod gubicima taj par stane na način koji nijedan sloj sam ne proizvodi.

Lančanje posrednika je drugo pitanje od biranja sloja. Dodavanje drugog proxyja ili Tora mijenja ko šta posmatra, a položaj u lancu odlučuje koji skok vidi šifrat.

Redoslijed je važniji od broja skokova. Spoljni skok gleda šifrovan tok dok unutrašnji vidi otvoreni tekst koji nosi, pa je lanac privatan samo koliko i njegova najneopreznija karika. Miješanje protokola između skokova to ne poboljšava automatski. Uglavnom samo otežava razmišljanje o načinima otkaza.

Lažna adresa nije jedna od opcija

Kreiranje paketa sa tuđom izvornom adresom ne postiže ništa korisno: odgovori idu pravom vlasniku, a većina mreža jednostavno odbaci saobraćaj. Posrednik je potreban upravo zato što se izvor ne može izmisliti, i to je pošteno opravdanje za sva tri rješenja.

To ujedno ograničava šta bilo koje od njih može tvrditi. Izgledati kao da potiče s određene adrese pitanje je o tome gdje je ta adresa legitimno dodijeljena i ko njome može rutovati, a ne o tome koji alat umije falsifikovati zaglavlje. Ako rješenje pretpostavlja drugačije, pretpostavka pada kod prvog provajdera koji je filtrira. Zapišite pretpostavku da otkaz bude prepoznatljiv kada dođe.

Odlučite po protokolima i imenima

Posegnite za proxyjem kada jednom web klijentu treba jedan web servis i ima proxy postavke. Posegnite za SSH tunelom kada je nekoliko poznatih TCP servisa dovoljno i SSH pristup već postoji. Posegnite za VPN-om kada je više aplikacija, ne-TCP saobraćaj, privatni DNS ili putanja koja se može ponovo koristiti dio zahtjeva.

Zatim provjerite stvarnim klijentom i stvarnim imenom. Učitavanje stranice kroz proxy ne uči vas ništa o UDP-u, a pokretanje jednog alata kroz SOCKS ne uči vas ništa o sistemskom resolveru. Pročitajte koju je lokalnu adresu proces vezao i koji je resolver odgovorio. To je razlika između putanje koja radi i one koja je slučajno proradila jednom.