Proxy HTTP, tunel SSH ali VPN: izberite pravo plast
Proxy, tunel SSH in VPN prenašajo različen promet. Uskladite plast s protokoli in razreševanjem imen, ki jih naloga potrebuje, nato preverite pot.
Vprašajte tri inženirje, kako priti do notranje storitve, in dobili boste tri zasnove: spletni proxy, tunel SSH ali poln VPN. Vse tri lahko približajo oddaljeno storitev in vse tri lahko naredijo, da promet izgleda, kot da prihaja od drugod. Razlike se pokažejo pozneje, ko uporabljeni protokol ni tisti, ki ga izbrano orodje predpostavlja. Zasnova, ki prestane hitro preverjanje v brskalniku, pogosto odpove v aplikaciji, zaradi katere je bila zahtevana.
Odločite se po dveh dejstvih: kateri protokoli morajo prečkati in kdo lahko razreši vključena imena. Vse drugo je preferenca.
Proxy prenese le tisto, kar razume
Spletni proxy razčleni protokol, za katerega je bil zgrajen. Odjemalec mu izroči zahtevo in on jo posreduje naprej, zato aplikacija brez nastavitve proxy sploh ne sodeluje. Za HTTPS odjemalec potrebuje neprozoren kanal, ki ga proxy zagotovi prek CONNECT, ne z branjem zahteve.
Dinamično posredovanje SSH odpre lokalna vrata, ki govorijo SOCKS, in ta vrata posredujejo tok TCP na kateri koli cilj, ki ga odjemalec navede. Protokoli, zgrajeni na TCP, običajno delujejo skoznje. UDP ne, razen če orodje izrecno doda podporo. Lokalno posredovanje je še ožje: ena lokalna vrata, preslikana na enega fiksnega gostitelja in vrata, kar služi eni znani storitvi in ničemur več.
ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastionVPN premika pakete. Vse, kar odjemalec usmeri v tunel, gre skozenj, vključno z UDP in ICMP, zato ustreza omrežni zahtevi in ne eni povezavi.
Nekdo mora razrešiti ime
Ko ciljno ime obstaja le v DNS oddaljenega omrežja, mora stroj, ki opravi iskanje, videti to cono. Spletni proxy iskanje opravi sam, zato notranje ime deluje skozenj tudi takrat, ko prenosnik imena sploh ne more razrešiti. SOCKS se lahko obnaša enako, a le če odjemalec posreduje ime, namesto da bi se povezal na naslov, ki ga je že razrešil. Ta izbira je v odjemalcu, ne v strežniku.
curl jasno pokaže delitev: ena zastavica preda ime gostitelja proxyju, druga ga najprej razreši lokalno. Pri lokalnem razreševanju notranje ime odpove, preden se tunela sploh dotaknemo, in napaka obtoži proxy za nekaj, kar je bila v resnici odločitev DNS.
VPN ubere tretjo pot: ob trase namesti zasebni razreševalnik in iskalno domeno. To je priročno in ustvari znano iluzijo: pot, ki obstaja z razreševalnikom, ki ne odgovarja, je videti natanko kot mrtev tunel, čeprav paketi dosežejo drugo stran.
Ko omrežje dovoli le en izhod
Mnoga poslovna omrežja dovoljujejo odhodne povezave izključno prek overjenega spletnega proxyja. OpenVPN in SSH je mogoče oba spraviti v pogon tam, prvega s tuneliranjem lastnega prenosa skozi proxy, drugega s proxy ukazom, ki zažene majhnega pomočnika CONNECT.
Tuneli, zgrajeni na TCP, prestanejo to omejitev, VPN, ki temelji na UDP, pa ne, kar pojasni zelo veliko konfiguracij, ki delujejo doma in odpovedo v pisarni. Druge cene je lahko spregledati: tunel TCP, nošen v posredovani povezavi TCP, ima zdaj dve plasti, ki ponovno pošiljata, in ob izgubah se ta par ustavi tako, kot nobena plast sama ne zmore.
Veriženje posrednikov je drugo vprašanje od izbire plasti. Dodajanje drugega proxyja ali Tor spremeni, kdo kaj opazuje, položaj v verigi pa odloči, kateri skok vidi šifrirano besedilo.
Vrstni red je pomembnejši od števila skokov. Zunanji skok gleda šifriran tok, notranji pa vidi čisto besedilo, ki ga nosi, zato je veriga zasebna le toliko, kolikor je njena najmanj skrbna povezava. Mešanje protokolov med skoki tega ne izboljša samodejno. Večinoma le oteži razmišljanje o načinih odpovedi.
Ponarejen naslov ni ena od možnosti
Izdelovanje paketov s tujim izvornim naslovom ne doseže nič koristnega: odgovori gredo pravemu lastniku, večina omrežij pa promet preprosto zavrže. Posrednik je potreben prav zato, ker si izvora ni mogoče izmisliti, in to je poštena utemeljitev vseh treh zasnov.
To tudi omejuje, kaj lahko katera od njih trdi. Biti videti kot izvirajoč z določenega naslova je vprašanje, kje je ta naslov zakonito dodeljen in kdo ga lahko usmerja, ne pa katero orodje zna ponarediti glavo. Če zasnova predpostavlja drugače, predpostavka odpove pri prvem ponudniku, ki jo filtrira. Zapišite predpostavko, da bo okvara prepoznavna, ko pride.
Odločite se po protokolih in imenih
Posezite po proxyju, ko en spletni odjemalec potrebuje eno spletno storitev in ima nastavitve proxy. Posezite po tunelu SSH, ko zadošča nekaj znanih storitev TCP in dostop SSH že obstaja. Posezite po VPN, ko so del zahteve več aplikacij, promet, ki ni TCP, zasebni DNS ali pot, ki jo je mogoče znova uporabiti.
Nato preverite s pravim odjemalcem in pravim imenom. Nalaganje strani skozi proxy vas ne nauči ničesar o UDP, zagon enega orodja skozi SOCKS pa vas ne nauči ničesar o sistemskem razreševalniku. Preberite, kateri lokalni naslov je proces vezal in kateri razreševalnik je odgovoril. To je razlika med potjo, ki deluje, in tisto, ki je enkrat po naključju delovala.