Proxy HTTP, tunel SSH sau VPN: alege stratul potrivit

Întreabă trei ingineri cum se ajunge la un serviciu intern și vei primi trei proiecte: un proxy web, un tunel SSH sau o VPN completă. Toate trei pot pune un serviciu la distanță la îndemână și toate trei pot face traficul să pară că vine din altă parte. Diferențele apar mai târziu, când protocolul folosit nu este cel pe care îl presupune unealta aleasă. Un proiect care trece un test rapid de browser eșuează de obicei la aplicația care a motivat cererea.

Decide pe baza a două fapte: ce protocoale trebuie să traverseze și cine poate rezolva numele implicate. Restul este preferință.

Un proxy mută doar ce înțelege

Un proxy web analizează protocolul pentru care a fost construit. Clientul îi înmânează o cerere, iar el o trimite mai departe, așa că o aplicație fără setări de proxy nu participă deloc. Pentru HTTPS clientul are nevoie de un canal opac, pe care proxy-ul îl oferă prin CONNECT în loc să citească cererea.

Un forward dinamic SSH deschide un port local care vorbește SOCKS, iar acel port retransmite un flux TCP către orice destinație numită de client. Protocoalele construite pe TCP funcționează de obicei prin el. UDP nu, decât dacă unealta adaugă suport în mod explicit. Un forward local este și mai îngust: un port local mapat pe un host și un port fixe, care deservește un singur serviciu cunoscut și nimic mai mult.

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

O VPN mută pachete. Tot ce clientul rutează în tunel traversează tunelul, inclusiv UDP și ICMP, de aceea se potrivește unei cerințe de rețea, nu unei singure conexiuni.

Cineva trebuie să rezolve numele

Când numele țintă există doar în DNS-ul rețelei la distanță, mașina care face căutarea trebuie să vadă acea zonă. Un proxy web face căutarea el însuși, așa că un nume intern funcționează prin el chiar și atunci când laptopul nu poate rezolva deloc numele. SOCKS se poate comporta la fel, dar numai dacă clientul trimite numele înainte, în loc să se conecteze la o adresă pe care a rezolvat-o deja. Această alegere stă în client, nu în server.

curl arată clar împărțirea: un flag transmite numele gazdei proxy-ului, altul îl rezolvă mai întâi local. Cu rezolvare locală, un nume doar intern eșuează înainte de a atinge vreun tunel, iar eroarea dă vina pe proxy pentru ce a fost de fapt o decizie DNS.

O VPN ia a treia cale instalând resolverul privat și domeniul de căutare lângă rute. Asta este comod și fabrică o iluzie familiară: o rută care există cu un resolver care nu răspunde arată exact ca un tunel mort, deși pachetele ajung pe partea cealaltă.

Când rețeaua permite o singură ieșire

Multe rețele corporative permit conexiuni externe doar printr-un proxy web autentificat. OpenVPN și SSH pot fi amândouă făcute să funcționeze acolo, primul tunelându-și propriul transport prin proxy, al doilea printr-o comandă proxy care rulează un mic ajutor CONNECT.

Tunelurile construite pe TCP supraviețuiesc acelei constrângeri, iar o VPN bazată pe UDP nu, ceea ce explică foarte multe configurații care funcționează acasă și eșuează la birou. Un al doilea cost este ușor de ratat: un tunel TCP purtat într-o conexiune TCP proxiată are acum două straturi care retransmit, iar sub pierderi această pereche se blochează într-un mod pe care niciun strat nu îl produce singur.

Înlănțuirea intermediarilor este o altă întrebare decât alegerea unui strat. Adăugarea unui al doilea proxy sau a Tor schimbă cine observă ce, iar poziția în lanț decide care hop vede text cifrat.

Ordinea contează mai mult decât numărul de hopuri. Un hop exterior vede un flux criptat, în timp ce unul interior vede textul clar pe care îl transportă, așa că un lanț este doar atât de privat cât veriga lui cea mai neatentă. Amestecarea protocoalelor între hopuri nu îmbunătățește asta automat. Cel mai mult face modurile de eșec mai greu de judecat.

O adresă falsificată nu este una dintre opțiuni

A construi pachete cu adresa sursă a altcuiva nu obține nimic util: răspunsurile merg la adevăratul proprietar, iar majoritatea rețelelor aruncă traficul direct. Un intermediar este necesar exact pentru că sursa nu poate fi inventată, iar aceasta este justificarea onestă pentru toate trei proiectele.

Asta limitează și ce poate pretinde fiecare dintre ele. A părea că provii dintr-o anumită adresă este o întrebare despre unde este atribuită legitim acea adresă și cine o poate ruta, nu despre ce unealtă poate falsifica un antet. Dacă un proiect presupune altfel, presupunerea eșuează la primul furnizor care o filtrează. Notează presupunerea, ca eșecul să fie recunoscut când apare.

Decide după protocoale și nume

Apelează la un proxy când un singur client web are nevoie de un singur serviciu web și are setări de proxy. Apelează la un tunel SSH când câteva servicii TCP cunoscute sunt suficiente și accesul SSH există deja. Apelează la o VPN când mai multe aplicații, trafic non-TCP, DNS privat sau un traseu reutilizabil fac parte din cerință.

Apoi verifică cu clientul real și numele real. Încărcarea unei pagini prin proxy nu te învață nimic despre UDP, iar faptul că o unealtă funcționează prin SOCKS nu te învață nimic despre resolverul sistemului. Citește ce adresă locală a legat procesul și ce resolver a răspuns. Aceasta este diferența dintre un traseu care funcționează și unul care a funcționat din întâmplare o dată.