Sådan bærer en lokal SSH-videresendelse en TCP-OpenVPN-session

Her stables tre transportlag, og hvert har sin egen indramning. VPN-nyttelasten rejser inde i en TLS-session, den TLS-session rejser inde i en TCP-forbindelse til en loopback-port, og bytes fra den forbindelse rejser inde i SSH til en relay-vært, som åbner den egentlige TCP-forbindelse til VPN-lytteren. Intet ved arrangementet ændrer det, som OpenVPN autentificerer, og intet ved det gør en UDP-lytter tilgængelig over TCP. Læs resten som en beskrivelse af bytevejen, ikke som en opskrift på at omgå en netværkskontrol.

Hvad den lokale videresendelse egentlig flytter

SSH-klienten lytter på en lokal port. Når en lokal proces forbinder, pakker klienten bytes i sin krypterede kanal, og serversiden åbner en ny TCP-forbindelse til den destination, der er nævnt i videresendelsesanmodningen.

Den destination opløses af relayen, ikke af din maskine, og derfor virker et navn, der kun findes inde i det fjernede netværk, stadig. Det betyder også, at relayen skal kunne nå VPN-lytteren og have en returrute til den. Et navn, der opløses på din bærbare, siger intet om, hvad relayen kan se.

At starte SSH-sessionen beviser kun, at relayen er tilgængelig og autentificeret. Det siger intet om, hvorvidt den næste lytter er oppe, om en firewall mellem relayen og lytteren accepterer forbindelsen, eller om VPN-en accepterer din profil.

Ret klienten mod den lokale lytter

Et erklæret eksempel: relayen kan nå en TCP-lytter på gw.internal.example:443, og en høj lokal port blotlægger den vej for kun denne maskine.

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

OpenSSH-manualen beskriver den lokale videresendelse som at acceptere TCP-forbindelser lokalt og åbne den næste forbindelse fra den fjernede side. Bind lytteren til loopback i stedet for til alle grænseflader, fordi en videresendelse, der kan nås fra netværket, er en åben relay med dit navn på. En jokertegnsbinding blotlægger også porten for enhver anden lokal konto på en delt maskine.

Sæt derefter VPN-klienten i TCP-tilstand og peg den på 127.0.0.1:24011. Hvis profilen bruger UDP, kan dette design ikke hjælpe: videresendelsen bærer en bytestrøm, og der er ingen datagramvej igennem den.

Hold de to autentificeringer adskilt

SSH autentificerer relay-værten. OpenVPN autentificerer stadig VPN-partneren, og loopback-destinationen ændrer ikke det krav. At slå certifikatkontroller fra, fordi soklen nu peger på localhost, er den værste genvej i dette design. Det gør et transportarrangement til et tillidsarrangement, og ingen har godkendt det andet.

Bevar profilens tillidsanker, serverrollekontrol og navneverifikation intakt. Hvis din klient sammenligner servernavnet med den adresse, den ringede til, kan loopback kræve en eksplicit navneindstilling i stedet for en deaktiveret kontrol, og profildokumentationen er stedet, hvor man bekræfter, hvilket felt der sammenlignes.

Behandl relayen som en anden part i tillidshistorien: dens administrator kan se forbindelsesmetadata og kan omdirigere videresendelsen, hvis konfigurationen ændres. Arrangementet kræver godkendelse fra både relayen og ejeren af VPN-tjenesten, ikke kun fra den, der har brug for det i dag.

Byg ikke en løkke under tunnelen

Når VPN'en installerer ruter, har den SSH-forbindelse, der bærer den, stadig brug for en vej til relayen, som ikke går gennem tunnelen. Hvis standardruten flytter til VPN'en, og relayen kun kan nås gennem samme tunnel, kollapser transporten, og VPN'en går med. Fejlen ligner en droppet tunnel snarere end en rutefejl, og derfor diagnosticeres den forkert.

Den sædvanlige løsning er en værtsrute til relay-adressen fastgjort til den fysiske grænseflade, før tunnelen kommer op, plus en kontrol af, at ruten overlever en genopkobling. Bekræft det med et ruteopslag for relay-adressen i stedet for at antage, at rækkefølgen var rigtig.

Forvent også, at denne stak er langsommere og mere skrøbelig end en direkte forbindelse, fordi der nu er to ordnede transports og endnu et endepunkt at vedligeholde. Det er en måde at krydse en netværksgrænse på, ikke en ydelsesteknik.

Luk lytteren, når du er færdig

Stop SSH-sessionen, når tunnelen ikke længere er nødvendig, og bekræft, at den lokale port er frigivet. En glemt videresendelse holder en autentificeret vej åben på en maskine, der kan være delt.

Gennemgå også relayens tilladte videresendelsesdestinationer, fordi en eftergivende konfiguration gør enhver kompromitteret konto til et generelt drejepunkt. Noter porten, relayen og destinationen sammen, så den næste person kan se, hvad videresendelsen var til, og om den stadig er godkendt.