Proxy HTTP, tunel SSH apo VPN: zgjidh shtresën e duhur

Pyet tre inxhinierë se si arrihet një shërbim i brendshëm dhe do të marrësh tre projekte: një proxy web, një tunel SSH ose një VPN të plotë. Të tre mund ta sjellin një shërbim në distancë brenda arit, dhe të tre mund ta bëjnë trafikun të duket sikur vjen nga diku tjetër. Diferencat shfaqen më vonë, kur protokolli në përdorim nuk është ai që supozon mjeti i zgjedhur. Një projekt që kalon një provë të shpejtë në shfletues dështon rregullisht në aplikacionin që e motivoi kërkesën.

Vendos nga dy fakte: cilët protokolle duhet të kalojnë dhe kush mund t'i zgjidhë emrat e përfshirë. Çdo gjë tjetër është preferencë.

Proxy lëviz vetëm atë që kupton

Një proxy web analizon protokollin për të cilin është ndërtuar. Klienti i jep një kërkesë dhe ai e përcjell kërkesën më tej, kështu që një aplikacion pa cilësim proxy nuk merr pjesë fare. Për HTTPS klienti ka nevojë për një kanal të errët, të cilin proxy e siguron përmes CONNECT dhe jo duke lexuar kërkesën.

Një përcjellje dinamike SSH hap një portë lokale që flet SOCKS, dhe ajo portë përcjell një rrjedhë TCP drejt çdo destinacioni që klienti emërton. Protokollet e ndërtuara mbi TCP zakonisht punojnë përmes saj. UDP nuk punon, përveç rastit kur një mjet shton mbështetje në mënyrë të qartë. Një përcjellje lokale është edhe më e ngushtë: një portë lokale e hartuar në një host dhe portë fikse, që shërben një shërbim të njohur dhe asgjë më shumë.

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

Një VPN lëviz paketa. Çdo gjë që klienti drejton në tunel kalon përmes tij, përfshirë UDP dhe ICMP, prandaj i përshtatet një kërkese rrjeti dhe jo një lidhjeje të vetme.

Dikush duhet ta zgjidhë emrin

Kur emri i synuar ekziston vetëm në DNS-në e rrjetit në distancë, kutia që bën kërkimin duhet ta shohë atë zonë. Një proxy web e bën kërkimin vetë, kështu që një emër i brendshëm punon përmes tij edhe kur laptopi nuk arrin ta zgjidhë fare emrin. SOCKS mund të sillet njësoj, por vetëm nëse klienti e përcjell emrin në vend që të lidhet me një adresë që e ka zgjidhur tashmë. Kjo zgjedhje qëndron te klienti, jo te serveri.

curl e tregon ndarjen qartë: një flamur ia kalon emrin e hostit proxy-t, një tjetër e zgjidh fillimisht lokalisht. Me zgjidhje lokale, një emër vetëm i brendshëm dështon para se të preket ndonjë tunel, dhe gabimi fajëson proxy-n për diçka që ishte në të vërtetë një vendim DNS.

Një VPN merr rrugën e tretë duke instaluar zgjidhësin privat dhe domenin e kërkimit pranë rrugëve. Kjo është e përshtatshme dhe krijon një iluzion të njohur: një rrugë që ekziston me një zgjidhës që nuk përgjigjet duket saktësisht si një tunel i vdekur, edhe pse paketat po arrijnë në anën tjetër.

Kur rrjeti lejon vetëm një dalje

Shumë rrjete korporative lejojnë lidhje dalëse vetëm përmes një proxy web të autentikuar. OpenVPN dhe SSH mund të vihen të dyja në punë atje, i pari duke tunelizuar transportin e vet përmes proxy-t dhe i dyti përmes një komande proxy që ekzekuton një ndihmës të vogël CONNECT.

Tunelet e ndërtuara mbi TCP i mbijetojnë atij kufizimi, dhe një VPN i bazuar në UDP nuk i mbijeton, gjë që shpjegon shumë konfigurime që punojnë në shtëpi dhe dështojnë në zyrë. Kostoja e dytë është e lehtë të anashkalohet: një tunel TCP i mbartur brenda një lidhjeje TCP të përfaqësuar nga proxy ka tani dy shtresa që ritransmetojnë, dhe nën humbje ky çift ngec në një mënyrë që asnjë shtresë nuk e prodhon vetëm.

Zinxhirimi i ndërmjetësve është një pyetje tjetër nga zgjedhja e një shtrese. Shtimi i një proxy të dytë ose i Tor ndryshon kush vëzhgon çfarë, dhe pozicioni në zinxhir vendos cila hop sheh tekst të shifruar.

Rendi ka më shumë rëndësi se numri i hop-eve. Një hop i jashtëm sheh një rrjedhë të shifruar, ndërsa një i brendshëm sheh tekstin e qartë që ajo mbart, kështu që një zinxhir është vetëm aq privat sa hallka e tij më e pakujdesshme. Përzierja e protokolleve ndërmjet hop-eve nuk e përmirëson këtë automatikisht. Kryesisht i bën mënyrat e dështimit më të vështira për t'u arsyetuar.

Një adresë e falsifikuar nuk është një nga opsionet

Ndërtimi i paketave me adresën burimore të dikujt tjetër nuk arrin asgjë të dobishme: përgjigjet shkojnë te pronari i vërtetë, dhe shumica e rrjeteve e hedhin trafikun menjëherë. Një ndërmjetës kërkohet pikërisht sepse burimi nuk mund të shpiket, dhe ky është justifikimi i ndershëm për të tre projektet.

Kjo gjithashtu kufizon çfarë mund të pretendojë secili prej tyre. Të dukesh se buron nga një adresë e caktuar është pyetje për atë se ku ajo adresë është caktuar në mënyrë legjitime dhe kush mund ta rutojë, jo për atë se cili mjet mund të falsifikojë një header. Nëse një projekt supozon ndryshe, supozimi dështon te ofruesi i parë që e filtron. Shkruaje supozimin, që dështimi të njihet kur të vijë.

Vendos sipas protokolleve dhe emrave

Kthehu nga një proxy kur një klient i vetëm web ka nevojë për një shërbim të vetëm web dhe ka cilësime proxy. Kthehu nga një tunel SSH kur disa shërbime TCP të njohura mjaftojnë dhe aksesi SSH ekziston tashmë. Kthehu nga një VPN kur disa aplikacione, trafik jo-TCP, DNS privat ose një rrugë e ripërdorshme janë pjesë e kërkesës.

Pastaj verifiko me klientin e vërtetë dhe emrin e vërtetë. Ngarkimi i një faqeje përmes një proxy nuk të mëson asgjë për UDP, dhe vënia në punë e një mjeti përmes SOCKS nuk të mëson asgjë për zgjidhësin e sistemit. Lexo cila adresë lokale u lidh nga procesi dhe cili zgjidhës u përgjigj. Kjo është diferenca midis një rruge që punon dhe një që punoi rastësisht një herë.