HTTP-proxy, SSH-tunnel või VPN: vali õige kiht

Küsi kolmelt insenerilt, kuidas sisemise teenuseni jõuda, ja saad kolm lahendust: veebiproxy, SSH-tunnel või täisvõimsusega VPN. Kõik kolm suudavad kaugteenuse kättesaadavaks teha ja kõik kolm suudavad jätta mulje, et liiklus tuleb mujalt. Erinevused ilmnevad hiljem, kui kasutatav protokoll ei ole see, mida valitud tööriist eeldab. Kiirest brauserikontrollist läbi läinud lahendus ebaõnnestub regulaarselt rakenduses, mis päringu tekitas.

Otsusta kahe fakti põhjal: millised protokollid peavad läbima ja kes suudab asjassepuutuvaid nimesid lahendada. Kõik muu on eelistus.

Proxy liigutab ainult seda, millest ta aru saab

Veebiproxy parsib protokolli, mille jaoks see loodi. Klient annab talle päringu ja proxy annab selle päringu edasi, nii et rakendus, millel puudub proxy seade, ei osale üldse. HTTPS-i jaoks vajab klient läbipaistmatut kanalit, mille proxy pakub CONNECTi kaudu, mitte päringut lugedes.

SSH dünaamiline edasisaatmine avab kohaliku pordi, mis räägib SOCKSit, ja see port edastab TCP voo ükskõik millisesse sihtkohta, mille klient nimetab. TCP-le ehitatud protokollid töötavad selle kaudu tavaliselt. UDP mitte, kui tööriist ei lisa tuge selgesõnaliselt. Kohalik edasisaatmine on veel kitsam: üks kohalik port kaardistatud ühele fikseeritud hostile ja pordile, mis teenindab üht teadaolevat teenust ja ei midagi muud.

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

VPN liigutab pakette. Kõik, mille klient tunnelisse suunab, läbib selle, sealhulgas UDP ja ICMP, seepärast sobib see võrgu nõude, mitte üksiku ühenduse jaoks.

Keegi peab nime lahendama

Kui sihtnimi eksisteerib ainult kaugvõrgu DNS-is, peab päringut tegev masin seda tsooni nägema. Veebiproxy teeb päringu ise, seega sisemine nimi töötab selle kaudu ka siis, kui sülearvuti ei suuda nime üldse lahendada. SOCKS võib käituda samamoodi, kuid ainult siis, kui klient edastab nime, selle asemel et ühenduda aadressiga, mille ta on juba lahendanud. See valik on kliendis, mitte serveris.

curl näitab jaotust selgelt: üks lipp annab hostinime proxyile, teine lahendab selle kõigepealt kohapeal. Kohaliku lahenduse korral ebaõnnestub ainult sisemine nimi enne, kui ükski tunnel puutub, ja viga süüdistab proxyt milleski, mis oli tegelikult DNS-i otsus.

VPN valib kolmanda tee, paigaldades privaatse resolveri ja otsingudomeeni marsruutide kõrvale. See on mugav ja loob tuttava illusiooni: marsruut, mis eksisteerib resolveriga, mis ei vasta, näeb täpselt välja nagu surnud tunnel, kuigi paketid jõuavad teisele poole.

Kui võrk lubab ainult üht väljapääsu

Paljud ettevõttevõrgud lubavad väljaminevaid ühendusi ainult autenditud veebiproxy kaudu. OpenVPN ja SSH saab mõlemad seal tööle panna: esimene tunneleerides oma transporti proxy kaudu ja teine proxy käsuga, mis käivitab väikese CONNECTi abilise.

TCP-le ehitatud tunnelid peavad sellele piirangule vastu ja UDP-põhine VPN mitte, mis selgitab väga paljusid seadistusi, mis töötavad kodus ja ebaõnnestuvad kontoris. Teist hinda on lihtne märkamata jätta: proxy kaudu edastatavas TCP-ühenduses kantud TCP-tunnelil on nüüd kaks kihti, mis kordussaadavad, ja kadude korral takerdub see paar viisil, mida kumbki kiht üksi ei tekita.

Vahendajate aheldamine on teine küsimus kui kihi valimine. Teise proxy või Tori lisamine muudab, kes mida jälgib, ja asukoht ahelas otsustab, milline hüpe näeb šifreeritud teksti.

Järjekord loeb rohkem kui hüpete arv. Välimine hüpe jälgib šifreeritud voogu, sisemine näeb aga lihtteksti, mida see kannab, seega on ahel sama privaatne kui selle kõige hooletum lüli. Protokollide segamine üle hüpete ei paranda seda automaatselt. See teeb enamasti tõrkerežiimid raskemini mõistetavaks.

Võltsitud aadress ei ole üks valikutest

Teise inimese lähteaadressiga pakettide valmistamine ei saavuta midagi kasulikku: vastused rändavad tõelise omaniku juurde ja enamik võrke viskab liikluse lihtsalt kõrvale. Vahendaja on vajalik just seetõttu, et lähtekohta ei saa välja mõelda, ja see on kõigi kolme lahenduse aus põhjendus.

See piirab ka seda, mida ükskõik milline neist väita tohib. Konkreetsest aadressist pärinemise mulje on küsimus sellest, kuhu see aadress seaduslikult määratud on ja kes tohib seda marsruutida, mitte sellest, milline tööriist suudab päist võltsida. Kui lahendus eeldab vastupidist, ebaõnnestub eeldus esimese teenusepakkuja juures, kes seda filtreerib. Kirjuta eeldus üles, et tõrge oleks saabudes äratuntav.

Otsusta protokollide ja nimede järgi

Vali proxy, kui ühel veebikliendil on vaja üht veebiteenust ja tal on proxy seaded. Vali SSH-tunnel, kui piisab peotäiest teadaolevast TCP-teenusest ja SSH-ligipääs on juba olemas. Vali VPN, kui nõude osaks on mitu rakendust, mitte-TCP liiklus, privaatne DNS või korduvkasutatav tee.

Seejärel kontrolli tõelise kliendi ja tõelise nimega. Lehekülje laadimine proxy kaudu ei õpeta sulle UDP kohta midagi ja ühe tööriista SOCKSi kaudu tööle saamine ei õpeta sulle süsteemse resolveri kohta midagi. Loe, millise kohaliku aadressiga protsess end sidus ja milline resolver vastas. See on vahe tee vahel, mis töötab, ja tee vahel, mis töötas kord juhuslikult.