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

Spør tre ingeniører hvordan man når en intern tjeneste, og du får tre design: en nettproxy, en SSH-tunnel eller en full VPN. Alle tre kan bringe en ekstern tjeneste innen rekkevidde, og alle tre kan få trafikk til å se ut som den kommer fra et annet sted. Forskjellene viser seg senere, når protokollen som brukes ikke er den verktøyet forutsetter. Et design som består en rask nettlesersjekk, feiler rutinemessig i applikasjonen som utløste forespørselen.

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

En proxy flytter bare det den forstår

En nettproxy analyserer protokollen den er bygget for. Klienten gir den en forespørsel, og den sender forespørselen videre, så en applikasjon uten proxyinnstilling deltar ikke i det hele tatt. For HTTPS trenger klienten en ugjennomsiktig kanal, som proxyen leverer via CONNECT i stedet for å lese forespørselen.

En dynamisk SSH-viderekobling åpner en lokal port som snakker SOCKS, og den porten videresender en TCP-strøm til enhver destinasjon klienten navngir. 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 viderekobling er enda smalere: én lokal port knyttet til én fast vert og port, som betjener én kjent tjeneste og ingenting mer.

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

En VPN flytter pakker. Alt klienten ruter inn i tunnelen går gjennom den, inkludert UDP og ICMP, og derfor passer den til et nettverkskrav og ikke til én enkelt forbindelse.

Noen må slå opp navnet

Når målnavnet bare finnes i DNS-en til det eksterne nettverket, må maskinen som gjør oppslaget kunne se sonen. En nettproxy gjør oppslaget selv, så et internt navn fungerer gjennom den selv når laptopen ikke kan slå opp navnet i det hele tatt. SOCKS kan oppføre seg på samme måte, 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 bare internt navn før noen tunnel berøres, og feilen gir proxyen skylden for det som egentlig var en DNS-beslutning.

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

Når nettverket bare tillater én utgang

Mange bedriftsnettverk tillater bare utgående forbindelser gjennom en autentisert nettproxy. OpenVPN og SSH kan begge fås til å virke der, den første ved å tunnele 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 konfigurasjoner som virker hjemme og feiler på et kontor. En annen kostnad er lett å overse: en TCP-tunnel båret inne i en TCP-forbindelse via en proxy har nå to lag som sender på nytt, og under tap stopper det paret 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 plasseringen i kjeden avgjør hvilket hopp som ser chifferteksten.

Rekkefølgen betyr mer enn antall hopp. Et ytre hopp ser en kryptert strøm, mens et indre ser klarteksten den bærer, så en kjede er bare så privat som det minst nøye leddet. Å blande protokoller på tvers av hopp bedrer ikke det automatisk. Det gjør mest feilmodusene vanskeligere å tenke gjennom.

En forfalsket adresse er ikke ett av alternativene

Å lage pakker med en annens kildeadresse oppnår ingenting nyttig: svar reiser til den rette eieren, og de fleste nettverk forkaster trafikken helt. En mellommann er nettopp nødvendig fordi kilden ikke kan finnes opp, og det er den ærlige begrunnelsen for alle tre designene.

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

Avgjør etter protokoller og navn

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

Verifiser deretter med den virkelige klienten og det virkelige 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 oppløser. Les hvilken lokal adresse prosessen bandt, og hvilken oppløser som svarte. Det er forskjellen mellom en vei som virker og en som tilfeldigvis virket én gang.