Dynamisk SSH-vidarekopling som SOCKS-proxy over VPN-et ditt
Ein app som berre snakkar SOCKS, har ingen proxy-endepunkt på ein vanleg VPN. To hopp, éin loopback-lyttar og eitt namneoppslag som SSH-tenaren må gjere sjølv.
Ein applikasjon som berre snakkar SOCKS, har ingenting å snakke med på ein vanleg VPN, fordi tunnelen ber pakkar og appen vil ha eit proxy-endepunkt. OpenSSH kan levere det endepunktet når tilgangseigaren tillèt det, fordi dynamisk vidarekopling gjer éin SSH-sesjon om til ein lokal proxy. Deretter er det to hopp som må haldast frå kvarandre: tunnelen som når SSH-verten, og sambandet som den verten opnar vidare. Å skilje dei forklarer både kvifor ordninga verkar og kva ho aldri kjem til å gjere.
Kva SSH-lyttaren blir, og kva han ikkje blir
Dynamisk vidarekopling får SSH-klienten til å lytte lokalt og snakke SOCKS4 eller SOCKS5 med alt som koplar til. Kvar førespurnad namngir ein destinasjon, og SSH-tenaren opnar det vidare sambandet, og difor kan destinasjonsoppslaget skje på den andre sida. Dette er TCP-vidarekopling på applikasjonsnivå, ikkje eit VPN for heile eininga. Det ber ingen UDP-tilknyting, ingen ICMP og ingenting for applikasjonar som heilt ignorerer proxyinnstillingar. Hoppet frå SSH-tenaren til applikasjonen er heller ikkje inne i tunnelen din, noko som spelar rolle når destinasjonen berre godtek trafikk frå kjende nettverk.
Føresetnadene er reelle: ei rute til SSH-verten, ein autorisert konto, ein stadfesta vertsnøkkel for tenaren og løyve til å videresende. Ingen av dei blir skapte av proxyen, og den siste manglar vanlegvis først. Stadfest alle fire før du feilsøkjer noko anna, fordi feilen ser lik ut frå klienten, uansett kva som manglar.
Start han på loopback med ein eksplisitt port
Vel ein ubrukt lokal port og bind han eksplisitt til loopback i staden for å utelate adressa. Dei tre alternativa nedanfor finst kvart av éin grunn.
ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
[email protected]-N hoppar over fjernkommandoen, og -T hoppar over pseudoterminalen, slik at sesjonen berre finst for å videresende. ExitOnForwardFailure får klienten til å avslutte når lyttaren ikkje kan opprettast, i staden for å køyre utan vidarekoplinga du bad om. ControlPath=none held sesjonen utanfor ei eksisterande multipleksa tilkopling som kan leggje til sine eigne vidarekoplingar. Loopback held lyttaren utanfor LAN-et, men på ein delt maskin er det inga autorisasjonsgrense, fordi andre lokale prosessar også kan nå han. Referansen for OpenSSH-klienten dokumenterer alle desse flagga, og loopback-åtvaringa følgjer av kva ein lyttande socket er.
Send namn gjennom proxyen, ikkje utanom han
Ein SOCKS5-klient kan slå opp destinasjonen sjølv eller be proxyen gjere det, og det valet avgjer kva resolver som svarar. Med socks5h sender curl vertsnamnet gjennom proxyen, slik at oppslaget skjer på SSH-tenaren. Med vanleg socks5 slår laptopen opp først, og berre sambandet reiser, noko som stille undergrev poenget når namnet er internt. Førespurnaden nedanfor tømmer også lista utan proxy, slik at ein nedarva NO_PROXY-verdi ikkje kan leie han utanom proxyen.
curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/healthSertifikatvalidering og applikasjonen si eiga innlogging gjeld framleis, fordi proxyen erstattar ingen av dei. Det står att to oppslag: laptopen må nå SSH-verten gjennom den tillatne VPN- og DNS-vegen, og SSH-tenaren må slå opp applikasjonsnamnet sjølv. Det andre kan testast åleine før noko trafikk går gjennom proxyen.
ssh [email protected] getent hosts app.corp.exampleProv éin tillaten destinasjon, og lukk deretter sesjonen
Test ein destinasjon som politikken tillèt og ein han bør avvise, fordi ei fungerande vidarekopling berre provar at lyttaren verkar, og ikkje noko meir. Applikasjonen ser kjeldeadressa SSH-tenaren vel, og det er ikkje tunneladressa til laptopen din. Der den andre enden loggar samband etter kjelde, er den skilnaden det første som må sjekkast når ein førespurnad blir avvist.
Stopp sesjonen gjennom prosessen som eig han, i staden for å drepe eit urelatert skal. Stadfest deretter at lyttaren er borte, fordi ein port som framleis svarar, er ein sesjon du ikkje eigna har lukka. Fjern berre proxyinnstillinga som denne øvinga innførte, og la resten av applikasjonskonfigurasjonen vere. Ein terminal utan tilsyn som held på ei vidarekoplingregel, er ikkje ei teneste, og ein permanent proxy treng ein godkjend livssyklus, ikkje eit gløymt vindauge.
ss -ltn | grep 1080Feil som denne ordninga ikkje kan rette
Nokre symptom peikar rett på grensene ovanfor, og å kjenne dei att tidleg sparer ein ettermiddag med proxy-feilsøking. Tabellen koplar det du ser til det det vanlegvis tyder. Alt i den siste kolonnen er eit designspørsmål, ikkje ein konfigurasjonsfeil.
| What you see | What it usually means | Where to look |
|---|---|---|
| The app connects and nothing follows | It ignores proxy settings entirely | Its own network settings, not the SSH session |
| A name resolution error for the destination | The SSH server cannot resolve it | Server resolver and search domains |
| A UDP-only application fails | Dynamic forwarding carries TCP only | This arrangement cannot serve it |
| curl works, the browser does not | The browser is not using the socks5h endpoint | Browser proxy configuration |
| The listener answers after the session ended | Another process owns port 1080 | The ss output, then the owning process |
Dei tre første radene er dei folk feildiagnostiserer, fordi kvar av dei gir eit tilkopingsforsøk i staden for ein feil om sjølve proxyen. Eit namn som blir løyst opp på laptopen, seier ingenting om resolveren til tenaren, og feilen blir lesen som eit sertifikat- eller tidsavbrot-problem. Applikasjonar med berre UDP står utanfor designet, ikkje øydelagde inni det, og ingen ekstra ssh-opsjon endrar det. Nettlesarrada er den vanlege påminninga om at proxyinnstillingar gjeld per applikasjon. Den siste rada er grunnen til at avslutningssjekken finst: ein port som framleis lyttar, tyder at noko anna eig han no.