HTTP-proxy, SSH-tunnel eller VPN: vælg det rigtige lag

Spørg tre ingeniører, hvordan man når en intern tjeneste, og du får tre design: en webproxy, en SSH-tunnel eller en fuld VPN. Alle tre kan bringe en ekstern tjeneste inden for rækkevidde, og alle tre kan få trafik til at se ud som om den kommer fra et andet sted. Forskellene viser sig senere, når protokollen i brug ikke er den, det valgte værktøj forudsætter. Et design, der består en hurtig browservalidering, fejler rutinemæssigt i den applikation, der udløste anmodningen.

Beslut ud fra to fakta: hvilke protokoller skal passere, og hvem kan opløse de involverede navne. Alt andet er præference.

En proxy flytter kun det, den forstår

En webproxy parser den protokol, den er bygget til. Klienten giver den en anmodning, og den sender anmodningen videre, så en applikation uden proxyindstilling deltager slet ikke. Til HTTPS har klienten brug for en uigennemsigtig kanal, som proxyen leverer via CONNECT i stedet for ved at læse anmodningen.

En dynamisk SSH-videresendelse åbner en lokal port, der taler SOCKS, og den port videresender en TCP-strøm til enhver destination, klienten navngiver. Protokoller bygget på TCP fungerer normalt gennem den. UDP gør ikke, medmindre et værktøj tilføjer støtte eksplicit. En lokal videresendelse er endnu snævrere: en lokal port knyttet til én fast vært og port, hvilket betjener én kendt tjeneste og intet mere.

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

En VPN flytter pakker. Alt, hvad klienten sender ind i tunnelen, passerer den, inklusive UDP og ICMP, og derfor passer den til et netværkskrav frem for en enkelt forbindelse.

Nogen skal opløse navnet

Når målnavnet kun findes i fjernnetværkets DNS, skal den maskine, der slår op, kunne se zonen. En webproxy slår selv op, så et internt navn virker gennem den, selv når laptop'en slet ikke kan opløse navnet. SOCKS kan opføre sig på samme måde, men kun hvis klienten videresender navnet i stedet for at forbinde til en adresse, den allerede har opløst. Det valg ligger i klienten, ikke i serveren.

curl viser opdelingen tydeligt: et flag sender værtsnavnet til proxyen, et andet opløser det først lokalt. Med lokal opløsning fejler et kun internt navn, før nogen tunnel berøres, og fejlen giver proxyen skylden for det, der i virkeligheden var en DNS-beslutning.

En VPN tager den tredje vej ved at installere den private resolver og søgedomænet ved siden af ruterne. Det er bekvemt, og det skaber en velkendt illusion: en rute, der findes med en resolver, som ikke svarer, ligner præcis en død tunnel, selv om pakkerne når den anden side.

Når netværket kun tillader én udgang

Mange virksomhedsnetværk tillader kun udgående forbindelser gennem en autentificeret webproxy. OpenVPN og SSH kan begge bringes til at virke der, den første ved at tunele sin egen transport gennem proxyen og den anden gennem en proxykommando, der kører en lille CONNECT-hjælper.

Tunneler bygget på TCP overlever den begrænsning, og en UDP-baseret VPN gør ikke, hvilket forklarer mange konfigurationer, der virker derhjemme og fejler på et kontor. En anden pris er let at overse: en TCP-tunnel båret inde i en TCP-forbindelse gennem en proxy har nu to lag, der gensender, og under tab går det par i stå på en måde, som intet lag frembringer alene.

At kæde mellemled er et andet spørgsmål end at vælge et lag. Et ekstra proxy eller Tor ændrer, hvem der observerer hvad, og placeringen i kæden afgør, hvilket hop der ser ciphertext.

Rækkefølgen betyder mere end antallet af hop. Et ydre hop ser en krypteret strøm, mens et indre ser den klartekst, den bærer, så en kæde er kun så privat som dens mindst omhyggelige led. At blande protokoller på tværs af hop forbedrer det ikke automatisk. Det gør mest fejlmåderne sværere at gennemtænke.

En forfalsket adresse er ikke en af mulighederne

At bygge pakker med en andens kildeadresse opnår intet nyttigt: svar rejser til den rigtige ejer, og de fleste netværk dropper trafikken helt. Et mellemled er netop nødvendigt, fordi kilden ikke kan opfindes, og det er den ærlige begrundelse for alle tre design.

Det begrænser også, hvad nogen af dem kan påstå. At fremstå som om det stammer fra en bestemt adresse er et spørgsmål om, hvor den adresse er lovligt tildelt, og hvem der må route den, ikke om hvilket værktøj der kan forfalske en header. Hvis et design antager andet, fejler antagelsen hos den første udbyder, der filtrerer den. Skriv antagelsen ned, så fejlen kan genkendes, når den kommer.

Beslut efter protokoller og navne

Grib en proxy, når en enkelt webklient har brug for en enkelt webtjeneste, og den har proxyindstillinger. Grib en SSH-tunnel, når en håndfuld kendte TCP-tjenester er nok, og SSH-adgang allerede findes. Grib en VPN, når flere applikationer, ikke-TCP-trafik, privat DNS eller en genbrugelig vej er en del af kravet.

Verificér derefter med den rigtige klient og det rigtige navn. At indlæse en side gennem en proxy lærer dig intet om UDP, og at få ét værktøj til at virke over SOCKS lærer dig intet om systemets resolver. Læs, hvilken lokal adresse processen bandt, og hvilken resolver der svarede. Det er forskellen mellem en vej, der virker, og en, der tilfældigt virkede én gang.