Hvordan en lokal SSH-videresending bærer en TCP-OpenVPN-økt

Her stabler tre transporter seg, og hver har sin egen innramming. VPN-nyttelasten reiser inne i en TLS-økt, den TLS-økten reiser inne i en TCP-forbindelse til en loopback-port, og bytene i den forbindelsen reiser inne i SSH til en relay-vert, som åpner den egentlige TCP-forbindelsen til VPN-lytteren. Ingenting ved oppsettet endrer det som OpenVPN autentiserer, og ingenting ved det gjør en UDP-lytter tilgjengelig over TCP. Les resten som en beskrivelse av byteveien, ikke som en oppskrift på å omgå en nettverkskontroll.

Hva den lokale videresendingen faktisk flytter

SSH-klienten lytter på en lokal port. Når en lokal prosess kobler til, pakker klienten bytene i sin krypterte kanal, og serversiden åpner en ny TCP-forbindelse til målet som er navngitt i videresendingsforespørselen.

Det målet løses opp av relayen, ikke av maskinen din, og derfor virker et navn som bare finnes inne i det eksterne nettverket fortsatt. Det betyr også at relayen må kunne nå VPN-lytteren og ha en returrute til den. Et navn som løses opp på maskinen din sier ingenting om hva relayen kan se.

Å starte SSH-økten beviser bare at relayen er tilgjengelig og autentisert. Det sier ingenting om hvorvidt den neste lytteren er oppe, om en brannmur mellom relayen og lytteren godtar forbindelsen, eller om VPN-en godtar profilen din.

Rett klienten mot den lokale lytteren

Et erklært eksempel: relayen kan nå en TCP-lytter på gw.internal.example:443, og en høy lokal port eksponerer den veien bare for denne maskinen.

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

OpenSSH-håndboken beskriver den lokale videresendingen som å godta TCP-forbindelser lokalt og åpne den neste forbindelsen fra den eksterne siden. Bind lytteren til loopback i stedet for til alle grensesnitt, fordi en videresending som er tilgjengelig fra nettverket er en åpen relay med navnet ditt på. En jokertegnbinding eksponerer også porten for enhver annen lokal konto på en delt maskin.

Sett deretter VPN-klienten i TCP-modus og rett den mot 127.0.0.1:24011. Hvis profilen bruker UDP, kan dette designet ikke hjelpe: videresendingen bærer en bytestrøm, og det finnes ingen datagramvei gjennom den.

Hold de to autentiseringene atskilt

SSH autentiserer relay-verten. OpenVPN autentiserer fortsatt VPN-motparten, og loopback-målet endrer ikke det kravet. Å slå av sertifikatkontroller fordi sokkelen nå peker på localhost er den verste snarveien i dette designet. Det gjør et transportoppsett til et tillitsoppsett, og ingen har godkjent det andre.

Hold profilens tillitsanker, serverrollekontroll og navneverifisering intakt. Hvis klienten din sammenligner servernavnet med adressen den ringte, kan loopback trenge en eksplisitt navneinnstilling i stedet for en deaktivert kontroll, og profildokumentasjonen er stedet for å bekrefte hvilket felt som sammenlignes.

Behandle relayen som en andre part i tillitshistorien: administratoren kan se tilkoblingsmetadata og kan omdirigere videresendingen hvis konfigurasjonen endres. Oppsettet trenger godkjenning fra både relayen og eieren av VPN-tjenesten, ikke bare fra den som trenger det i dag.

Ikke bygg en løkke under tunnelen

Når VPN-en installerer ruter, trenger SSH-forbindelsen som bærer den fortsatt en vei til relayen som ikke går gjennom tunnelen. Hvis standardruten flyttes til VPN-en og relayen bare er tilgjengelig gjennom den samme tunnelen, kollapser transporten og VPN-en går med. Feilen ser ut som en droppet tunnel snarere enn en rute feil, og derfor diagnostiseres den feil.

Den vanlige løsningen er en vertsrute til relay-adressen festet til det fysiske grensesnittet før tunnelen kommer opp, pluss en kontroll av at ruten overlever en gjenoppkobling. Bekreft det med et ruteoppslag for relay-adressen i stedet for å anta at rekkefølgen var riktig.

Forvent også at denne stabelen er tregere og mer skjør enn en direkte forbindelse, fordi det nå er to ordnede transporter og ett endepunkt til å vedlikeholde. Det er en måte å krysse en nettverksgrense på, ikke en ytelsesteknikk.

Lukk lytteren når du er ferdig

Stopp SSH-økten når tunnelen ikke lenger er nødvendig, og bekreft at den lokale porten er frigitt. En glemt videresending holder en autentisert vei åpen på en maskin som kan være delt.

Gå også gjennom relayens tillatte videresendingsmål, fordi en ettergivende konfigurasjon gjør enhver kompromittert konto til et generelt dreiepunkt. Noter porten, relayen og målet sammen, slik at neste person kan se hva videresendingen var til og om den fortsatt er godkjent.