HTTP-proxy, SSH-tunnel eller VPN: velg riktig lag

Spør tre ingeniører hvordan de når en intern tjeneste, og du får tre ulike løsninger: en netproxy, en SSH-tunnel eller en full VPN. Alle tre kan gjøre en ekstern tjeneste tilgjengelig, og alle tre kan få trafikk til å se ut som den kommer fra et annet sted. Forskjellene viser seg først senere, når protokollen som brukes ikke er den verktøyet forutsetter. En løsning som består en rask test i nettleseren, svikter ofte på applikasjonen som var grunnen til forespørselen.

Avgjør ut fra to forhold: hvilke protokoller som må krysse, og hvem som kan slå opp navnene som er involvert. Alt annet er smak og behag.

En proxy flytter bare det den forstår

En netproxy tolker protokollen den er laget for. Klienten gir den en forespørsel, og den sender forespørselen videre, så et program uten proxyinnstilling deltar aldri i det hele tatt. For HTTPS trenger klienten en ugjennomsiktig kanal, som proxyen skaffer via CONNECT i stedet for å lese forespørselen.

En dynamisk SSH-videresending åpner en lokal port som snakker SOCKS, og den porten videresender en TCP-strøm til hvilken som helst destinasjon klienten peker på. Protokoller bygget på TCP fungerer vanligvis gjennom den. UDP gjør det ikke, med mindre et verktøy legger til støtte eksplisitt. En lokal videresending er enda snevrere: én lokal port knyttet til én fast vert og port, som betjener én kjent tjeneste og ikke noe mer.

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

En VPN flytter pakker. Alt klienten rutrer inn i tunnelen krysser den, UDP og ICMP inkludert, og derfor passer den til et nettverkskrav snarere enn til en enkelt forbindelse.

Noen må slå opp navnet

Når målnavnet bare finnes i det eksterne nettverkets DNS, må boksen som gjør oppslaget kunne se den sonen. En netproxy gjør oppslaget selv, så et internt navn virker gjennom den selv når laptopen ikke klarer å slå opp navnet i det hele tatt. SOCKS kan oppføre seg likt, men bare hvis klienten videresender navnet i stedet for å koble til en adresse den allerede har slått opp. Det valget ligger i klienten, ikke i serveren.

curl viser skillet tydelig: ett flagg sender vertsnavnet til proxyen, et annet slår det opp lokalt først. Med lokal oppslag feiler et internt navn før noen tunnel er berørt, og feilmeldingen gir proxyen skylden for noe som egentlig var en DNS-avgjørelse.

En VPN tar den tredje veien ved å installere den private resolveren og søkedomenet ved siden av rutene. Det er praktisk, og det skaper en kjent illusjon: en rute som finnes med en resolver som ikke svarer, ser nøyaktig ut som en død tunnel, selv om pakkene når den andre siden.

Når nettet bare tillater én utgang

Mange bedriftsnett tillater utgående forbindelser bare gjennom en autentisert netproxy. OpenVPN og SSH kan begge fås til å virke der, den første ved å tunnelere sin egen transport gjennom proxyen og den andre gjennom en proxykommando som kjører en liten CONNECT-hjelper.

Tunneler bygget på TCP overlever den begrensningen, og en UDP-basert VPN gjør det ikke, noe som forklarer svært mange oppsett som virker hjemme og svikter på et kontor. En annen kostnad er lett å overse: en TCP-tunnel som fraktes inne i en proxiet TCP-forbindelse har nå to lag som sender på nytt, og ved pakketap stopper den kombinasjonen på en måte som ingen av lagene lager alene.

Å kjede mellommenn er et annet spørsmål enn å velge et lag. Å legge til en ekstra proxy eller Tor endrer hvem som observerer hva, og posisjonen i kjeden avgjør hvilket hopp som ser chiffertekst.

Rekkefølgen betyr mer enn antall hopp. Et ytre hopp ser en kryptert strøm, mens et indre hopp ser klarteksten den frakter, så en kjede er bare så privat som det minst forsiktige leddet. Å blande protokoller på tvers av hopp bedrer ikke det automatisk. Det gjør mest at feilmodusene blir vanskeligere å resonnere om.

En forfalsket adresse er ikke et av alternativene

Å lage pakker med en annens kildeadresse oppnår ingenting nyttig: svar går til den virkelige eieren, og de fleste nett dropper trafikken helt. En mellommann er nettopp nødvendig fordi kilden ikke kan diktes opp, og det er den ærlige begrunnelsen for alle tre løsningene.

Det begrenser også hva noen av dem kan påstå. Å se ut som man kommer fra en bestemt adresse handler om hvor den adressen lovlig er tildelt og hvem som kan rute den, ikke om hvilket verktøy som kan forfalske en header. Hvis en løsning forutsetter noe annet, svikter forutsetningen hos den første leverandøren som filtrerer den. Skriv ned forutsetningen, så feilen kan gjenkjennes når den kommer.

Avgjør etter protokoller og navn

Velg en proxy når én nettklient trenger én netttjeneste og har proxyinnstillinger. Velg en SSH-tunnel når noen få kjente TCP-tjenester er nok og SSH-tilgang allerede finnes. Velg en VPN når flere programmer, ikke-TCP-trafikk, privat DNS eller en gjenbrukbar vei er en del av kravet.

Verifiser deretter med den ekte klienten og det ekte navnet. Å laste en side gjennom en proxy lærer deg ingenting om UDP, og å få ett verktøy til å virke over SOCKS lærer deg ingenting om systemets resolver. Les hvilken lokal adresse prosessen bandt seg til og hvilken resolver som svarte. Det er forskjellen mellom en vei som virker og en som tilfeldigvis virket én gang.