Korleis ei lokal SSH-vidaresending ber ein TCP-OpenVPN-økt
Éin lokal port, to autentiserte relasjonar, tre transportar. Kva SSH-vidaresendinga flyttar, og kvar løkka og sertifikatkontrollane framleis gjeld.
Her stablar tre transportar seg, og kvar har si eiga innramming. VPN-nyttelasta reiser inne i ei TLS-økt, den TLS-økta reiser inne i ei TCP-tilkopling til ein loopback-port, og byta i den tilkoplinga reiser inne i SSH til ein relay-vert, som opnar den eigentlege TCP-tilkoplinga til VPN-lyttaren. Ingenting ved oppsettet endrar det som OpenVPN autentiserer, og ingenting ved det gjer ein UDP-lyttar tilgjengeleg over TCP. Les resten som ei skildring av bytevegen, ikkje som ein oppskrift på å omgå ein nettverkskontroll.
Kva den lokale vidaresendinga faktisk flyttar
SSH-klienten lyttar på ein lokal port. Når ein lokal prosess koplar til, pakkar klienten byta i sin krypterte kanal, og serversida opnar ei ny TCP-tilkopling til målet som er namngjeve i vidaresendingsførespurnaden.
Det målet vert løyst opp av relayen, ikkje av maskina di, og difor verkar eit namn som berre finst inne i det eksterne nettverket framleis. Det tyder òg at relayen må kunne nå VPN-lyttaren og ha ein returveg til han. Eit namn som vert løyst opp på maskina di seier ingenting om kva relayen kan sjå.
Å starte SSH-økta beviser berre at relayen er tilgjengeleg og autentisert. Det seier ingenting om den neste lyttaren er oppe, om ein brannmur mellom relayen og lyttaren godtek tilkoplinga, eller om VPN-en godtek profilen din.
Rett klienten mot den lokale lyttaren
Eit erklært døme: relayen kan nå ein TCP-lyttar på gw.internal.example:443, og ein høg lokal port gjer den vegen berre tilgjengeleg for denne maskina.
ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]OpenSSH-handboka skildrar den lokale vidaresendinga som å ta imot TCP-tilkoplingar lokalt og opne den neste tilkoplinga frå den eksterne sida. Bind lyttaren til loopback i staden for til alle grensesnitt, fordi ei vidaresending som er tilgjengeleg frå nettverket er ein open relay med namnet ditt på. Ei jokerteiknbinding gjer òg porten tilgjengeleg for kvar annan lokal konto på ei delt maskin.
Set så VPN-klienten i TCP-modus og rett han mot 127.0.0.1:24011. Viss profilen brukar UDP, kan dette designet ikkje hjelpe: vidaresendinga ber ein bytestraun, og det finst ingen datagramveg gjennom henne.
Hald dei to autentiseringane skilde
SSH autentiserer relay-verten. OpenVPN autentiserer framleis VPN-motparten, og loopback-målet endrar ikkje det kravet. Å slå av sertifikatkontrollar fordi sokkelen no peikar på localhost er den verste snarvvegen i dette designet. Det gjer eit transportoppsett om til eit tillitsoppsett, og ingen har godkjent det andre.
Hald tillitsankret til profilen, serverrolle-kontrollen og namneverifiseringa intakte. Viss klienten din samanliknar servernamnet med adressa han ringde, kan loopback trenge ei eksplisitt namneinnstilling i staden for ein deaktivert kontroll, og profildokumentasjonen er staden for å stadfeste kva felt som vert samanlikna.
Behandle relayen som ein andre part i tillitshistoria: administratoren kan sjå tilkoplinga sin metadata og kan omdirigere vidaresendinga viss konfigurasjonen vert endra. Oppsettet treng godkjenning frå både relayen og eigaren av VPN-tenesta, ikkje berre frå den som treng det i dag.
Ikkje bygg ei løkke under tunnelen
Når VPN-en installerer ruter, treng SSH-tilkoplinga som ber han framleis ein veg til relayen som ikkje går gjennom tunnelen. Viss standardruta flyttar seg til VPN-en og relayen berre er tilgjengeleg gjennom den same tunnelen, kollapsar transporten og VPN-en går med. Feilen ser ut som ein fallen tunnel snarare enn ein rute feil, og difor vert han feil diagnostisert.
Den vanlege løysinga er ei vertsrute til relay-adressa fest til det fysiske grensesnittet før tunnelen kjem opp, pluss ein kontroll på at ruta overlever ei ny tilkopling. Stadfest det med eit ruteoppslag for relay-adressa i staden for å gå ut frå at rekkjefylgja var rett.
Rekn med at denne stabelen er tregare og meir skjør enn ei direkte tilkopling, fordi det no er to ordna transportar og eit endepunkt til å vedlikehalde. Det er ein måte å krysse ei nettverksgrense på, ikkje ein ytingsteknikk.
Lat lyttaren att når du er ferdig
Stopp SSH-økta når tunnelen ikkje lenger er naudsynt, og stadfest at den lokale porten er frigjeven. Ei gløymd vidaresending held ein autentisert veg open på ei maskin som kan vere delt.
Gå òg gjennom dei tillatne vidaresendingsmåla til relayen, fordi ein ettergjevande konfigurasjon gjer kvar kompromittert konto til eit allment dreiepunkt. Noter porten, relayen og målet saman, slik at neste person kan sjå kva vidaresendinga var til og om ho framleis er godkjend.