HTTP-proxy, SSH-tunnel eller VPN: vel rett lag

Spør tre ingeniørar korleis ein når ei intern teneste, og du får tre design: ein nettproxy, ein SSH-tunnel eller eit fullt VPN. Alle tre kan gjere ei fjern teneste tilgjengeleg, og alle tre kan få trafikk til å sjå ut som han kjem frå ein annan stad. Skilnadene viser seg seinare, når protokollen som blir brukt ikkje er den verktøyet føreset. Eit design som går gjennom ein rask nettlesarsjekk, feilar rutinemessig i programmet som utløyste førespurnaden.

Avgjer ut frå to fakta: kva protokollar som må krysse, og kven som kan slå opp namna som er involverte. Alt anna er preferanse.

Ein proxy flyttar berre det han forstår

Ein nettproxy analyserer protokollen han er bygd for. Klienten gir han ein førespurnad, og han sender førespurnaden vidare, så eit program utan proxyinnstilling deltek ikkje i det heile. For HTTPS treng klienten ein ugjennomsiktig kanal, som proxyen leverer via CONNECT i staden for å lese førespurnaden.

Ein dynamisk SSH-vidarekopling opnar ein lokal port som snakkar SOCKS, og den porten videresender ein TCP-straume til kvar destinasjon klienten namngir. Protokollar bygde på TCP fungerer vanlegvis gjennom han. UDP gjer det ikkje, med mindre eit verktøy legg til støtte eksplisitt. Ei lokal vidarekopling er endå smalare: éin lokal port knytt til éin fast vert og port, som tener éi kjend teneste og ingenting meir.

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

Eit VPN flyttar pakkar. Alt klienten ruter inn i tunnelen går gjennom han, inkludert UDP og ICMP, og difor passar det til eit nettverkskrav og ikkje til éi einsleg samband.

Nokon må slå opp namnet

Når målmanet berre finst i DNS-en til det eksterne nettverket, må maskinen som gjer oppslaget kunne sjå sona. Ein nettproxy gjer oppslaget sjølv, så eit internt namn fungerer gjennom han sjølv når laptopen ikkje kan slå opp namnet i det heile. SOCKS kan oppføre seg på same måte, men berre dersom klienten videresender namnet i staden for å kople til ei adresse han alt har slått opp. Det valet ligg i klienten, ikkje i tenaren.

curl viser skiljet tydeleg: eitt flagg sender vertsnamnet til proxyen, eit anna slår det opp lokalt først. Med lokal oppslåing feilar eit berre internt namn før nokon tunnel blir rørt, og feilen gir proxyen skulda for det som eigentleg var ei DNS-avgjerd.

Eit VPN tek den tredje vegen ved å installere den private oppløysaren og søkjedomenet ved sida av rutene. Det er praktisk, og det skaper ein velkjend illusjon: ei rute som finst med ein oppløysar som ikkje svarar, ser nøyaktig ut som ein daud tunnel, sjølv om pakkane når den andre sida.

Når nettverket berre tillèt éin utgang

Mange bedriftsnettverk tillèt berre utgåande samband gjennom ein autentisert nettproxy. OpenVPN og SSH kan begge fåast til å verke der, den første ved å tunnele sin eigen transport gjennom proxyen og den andre gjennom ein proxykommando som køyrer ein liten CONNECT-hjelpar.

Tunnelar bygde på TCP overlever den avgrensinga, og eit UDP-basert VPN gjer det ikkje, noko som forklarar svært mange konfigurasjonar som verkar heime og feilar på eit kontor. Ein annan kostnad er lett å oversjå: ein TCP-tunnel boren inne i ein TCP-samband via ein proxy har no to lag som sender på nytt, og under tap stoppar det paret på ein måte som ingen av laga lagar åleine.

Å kjede mellomledd er eit anna spørsmål enn å velje eit lag. Å leggje til ein ekstra proxy eller Tor endrar kven som observerer kva, og plasseringa i kjeda avgjer kva hopp som ser chifferteksten.

Rekkjefølgja betyr meir enn talet på hopp. Eit ytre hopp ser ein kryptert straum, medan eit indre ser klarteksten han ber, så ei kjede er berre så privat som det minst nøye leddet. Å blande protokollar på tvers av hopp betrar ikkje det automatisk. Det gjer mest feilmodusane vanskelegare å tenkje gjennom.

Ei forfalska adresse er ikkje eitt av alternativa

Å lage pakkar med ein annan sin kjeldeadresse oppnår ingenting nyttig: svar reiser til den rette eigaren, og dei fleste nettverk forkastar trafikken heilt. Eit mellomledd er nettopp naudsynt fordi kjelda ikkje kan finnast opp, og det er den ærlege grunngjevinga for alle tre designa.

Det avgrensar òg kva nokon av dei kan påstå. Å framstå som om det kjem frå ei bestemd adresse er eit spørsmål om kvar den adressa er lovleg tildelt og kven som kan rute henne, ikkje om kva verktøy som kan forfalske ein header. Dersom eit design føreset noko anna, feilar føresetnaden hos den første leverandøren som filtrerer han. Skriv føresetnaden ned, så feilen kan kjennast att når han kjem.

Avgjer etter protokollar og namn

Grip til ein proxy når éin nettklient treng éi netteneste og har proxyinnstillingar. Grip til ein SSH-tunnel når ein handfull kjende TCP-tenester er nok og SSH-tilgang alt finst. Grip til eit VPN når fleire program, ikkje-TCP-trafikk, privat DNS eller ein gjenbrukbar veg er ein del av kravet.

Stadfest deretter med den verkelege klienten og det verkelege namnet. Å laste ei side gjennom ein proxy lærer deg ingenting om UDP, og å få eitt verktøy til å verke over SOCKS lærer deg ingenting om oppløysaren til systemet. Les kva lokal adresse prosessen batt, og kva oppløysar som svara. Det er skilnaden mellom ein veg som verkar og ein som tilfeldigvis verka éin gong.