HTTP proxy-a, SSH tunela edo VPN: aukeratu geruza egokia

Galdetu hiru ingeniari zerbitzu interno batera nola iritsi eta hiru diseinu jasoko dituzu: web proxy bat, SSH tunel bat edo VPN oso bat. Hirurek jar dezakete urrutiko zerbitzua eskura, eta hirurek egin dezakete trafikoa beste leku batetik datorrela emateko. Aldeak geroago agertzen dira, erabiltzen den protokoloa hautatutako tresnak suposatzen duena ez denean. Arakatzailean egiaztapen azkar bat gainditzen duen diseinuak huts egin ohi du eskaera eragin zuen aplikazioan.

Erabaki bi egitatetik: zein protokolo igaro behar diren eta nork ebatzi ditzakeen inplikatutako izenak. Gainerako guztia lehentasuna da.

Proxy batek ulertzen duena soilik mugitzen du

Web proxy batek eraiki zen protokoloa aztertzen du. Bezeroak eskaera bat ematen dio eta hark eskaera hori aurrera pasatzen du, beraz proxy ezarpenik ez duen aplikazioak ez du batere parte hartzen. HTTPSrako bezeroak kanal opaku bat behar du, eta proxyak CONNECT bidez ematen dio, eskaera irakurri ordez.

SSH birbidalketa dinamikoak SOCKS hitz egiten duen tokiko portu bat irekitzen du, eta portu horrek TCP fluxua bezeroak izendatzen duen edozein helmugara bidaltzen du. TCPn oinarritutako protokoloak normalean haren bidez funtzionatzen dute. UDPk ez, tresnak euskarria berariaz gehitzen ez badu. Tokiko birbidalketa are estuagoa da: tokiko portu bat host eta portu finko bati mapatuta, zerbitzu ezagun bakarra zerbitzatzen duena eta besterik ez.

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

VPN batek paketeak mugitzen ditu. Bezeroak tunelera bideratzen duen guztia zeharkatzen du, UDP eta ICMP barne, horregatik sare-eskakizun baterako egokia da, konexio bakarrerako ez.

Norbaitek ebatzi behar du izena

Helmugako izena urrutiko sarearen DNSan soilik existitzen denean, bilaketa egiten duen makinak zona hori ikusi behar du. Web proxy batek berak egiten du bilaketa, beraz barneko izen bat haren bidez funtzionatzen du, ordenagailu eramangarriak izena batere ebatzi ezin duenean ere. SOCKSek gauza bera egin dezake, baina bezeroak izena aurrera pasatzen badu soilik, jada ebatzi duen helbide batera konektatu ordez. Aukera hori bezeroan dago, ez zerbitzarian.

curl-ek banaketa argi erakusten du: bandera batek ostalariaren izena proxyari pasatzen dio, beste batek lehenago lokalki ebazten du. Ebazpen lokalarekin, barneko izen soil bat huts egiten du edozein tunel ukitu aurretik, eta erroreak proxyari leporatzen dio benetan DNS erabaki bat izan zena.

VPNak hirugarren bidea hartzen du resolver pribatua eta bilaketa-domeinua bideen ondoan instalatuz. Hori erosoa da, eta ilusio ezagun bat sortzen du: resolverrak erantzuten ez duen bitartean existitzen den bide bat tunel hildako baten itxura du, nahiz eta paketeak beste aldera iristen diren.

Sareak irteera bakarra baimentzen duenean

Enpresa-sare askok irteerako konexioak web proxy autentifikatu baten bidez soilik baimentzen dituzte. OpenVPN eta SSH biak jar daitezke han funtzionatzen, lehenengoa bere garraioa proxyaren bidez tunelatuz eta bigarrena CONNECT laguntzaile txiki bat exekutatzen duen proxy komando baten bidez.

TCPn oinarritutako tunelak murrizketa horri eusten diote, eta UDPn oinarritutako VPNak ez, eta horrek azaltzen ditu etxean funtzionatzen eta bulegoan huts egiten duten konfigurazio asko. Bigarren kostu bat erraz pasatzen da oharkabean: proxy bidezko TCP konexio baten barruan garraiatutako TCP tunelak bi geruza ditu orain berriz bidaltzen, eta galerapean bikote hori blokeatu egiten da geruza bakarrak sortzen ez duen moduan.

Bitartekariak kateatzea geruza bat aukeratzea baino galdera desberdina da. Bigarren proxy edo Tor bat gehitzeak aldatzen du nork zer behatzen duen, eta katean duen posizioak erabakitzen du zein jauzik ikusten duen zifratutako testua.

Ordenak garrantzi handiagoa du jauzi kopuruak baino. Kanpoko jauzi batek zifratutako fluxua behatzen du, barneko batek daraman testu laua ikusten duen bitartean, beraz katea bere estekarik axolagabeena bezain pribatua da. Protokoloak jauzien artean nahasteak ez du hori automatikoki hobetzen. Gehienbat hutsegite moduak arrazoitzeko zailagoak egiten ditu.

Helbide faltsu bat ez da aukeretako bat

Beste norbaitek iturburu-helbidea duen paketeak egiteak ez du ezer baliagarririk lortzen: erantzunak benetako jabearengana joaten dira, eta sare gehienek trafikoa erabat baztertzen dute. Bitartekari bat beharrezkoa da iturburua asmatu ezin delako, eta hori da hiru diseinuen justifikazio zintzoa.

Era berean, mugatzen du edozeinek zer aldarrikatu dezakeen. Helbide jakin batetik datorrela emateak helbide hori non esleitzen den legez eta nork bideratu dezakeen galdera dakar, ez zein tresnak faltsutu dezakeen goiburua. Diseinu batek kontrakoa suposatzen badu, suposizioak huts egiten du iragazten duen lehen hornitzailean. Idatzi suposizioa, hutsegitea iristen denean ezagutzeko modukoa izan dadin.

Erabaki protokoloen eta izenen arabera

Erabili proxy bat web bezero bakar batek web zerbitzu bakar bat behar duenean eta proxy ezarpenak dituenean. Erabili SSH tunel bat TCP zerbitzu ezagun batzuk nahikoa direnean eta SSH sarbidea badagoenean. Erabili VPN bat hainbat aplikaziok, TCP ez den trafikoak, DNS pribatuak edo berrerabil daitekeen bide batek eskakizunaren zati bat osatzen dutenean.

Gero egiaztatu benetako bezeroarekin eta benetako izenarekin. Proxy baten bidez orri bat kargatzeak ez dizu ezer irakasten UDPri buruz, eta tresna bat SOCKSen bidez funtzionarazteak ez dizu ezer irakasten sistemaren resolverrari buruz. Irakurri prozesuak zein tokiko helbide lotu zuen eta zein resolverrek erantzun zuen. Hori da funtzionatzen duen bide baten eta behin kasualitatez funtzionatu zuen baten arteko aldea.