Dynamisk SSH-viderekobling som SOCKS-proxy over VPN-en din
En app som bare snakker SOCKS, har ingen proxy-endepunkt på en vanlig VPN. To hopp, én loopback-lytter og ett navneoppslag som SSH-serveren må gjøre selv.
En applikasjon som bare snakker SOCKS, har ingenting å snakke med på en vanlig VPN, fordi tunnelen bærer pakker og appen vil ha et proxy-endepunkt. OpenSSH kan levere det endepunktet når tilgangseieren tillater det, fordi dynamisk viderekobling gjør én SSH-sesjon om til en lokal proxy. Deretter er det to hopp som må holdes fra hverandre: tunnelen som når SSH-verten, og forbindelsen som den verten åpner videre. Å skille dem forklarer både hvorfor ordningen virker og hva den aldri kommer til å gjøre.
Hva SSH-lytteren blir, og hva den ikke blir
Dynamisk viderekobling får SSH-klienten til å lytte lokalt og snakke SOCKS4 eller SOCKS5 med alt som kobler til. Hver forespørsel navngir en destinasjon, og SSH-serveren åpner den videre forbindelsen, og derfor kan destinasjonsoppslaget skje på den andre siden. Dette er TCP-viderekobling på applikasjonsnivå, ikke en VPN for hele enheten. Den bærer ingen UDP-tilknytning, ingen ICMP og ingenting for applikasjoner som helt ignorerer proxyinnstillinger. Hoppet fra SSH-serveren til applikasjonen er heller ikke inne i tunnelen din, noe som betyr noe når destinasjonen bare godtar trafikk fra kjente nettverk.
Forutsetningene er reelle: en rute til SSH-verten, en autorisert konto, en verifisert vertsnøkkel for serveren og tillatelse til å videresende. Ingen av dem skapes av proxyen, og den siste mangler vanligvis først. Bekreft alle fire før du feilsøker noe annet, fordi feilen ser lik ut fra klienten, uansett hvilken som mangler.
Start den på loopback med en eksplisitt port
Velg en ubrukt lokal port og bind den eksplisitt til loopback i stedet for å utelate adressen. De tre alternativene nedenfor finnes hvert av én grunn.
ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
[email protected]-N hopper over fjernkommandoen, og -T hopper over pseudoterminalen, slik at sesjonen bare finnes for å videresende. ExitOnForwardFailure får klienten til å avslutte når lytteren ikke kan opprettes, i stedet for å kjøre uten viderekoblingen du ba om. ControlPath=none holder sesjonen utenfor en eksisterende multiplekset forbindelse som kan legge til sine egne viderekoblinger. Loopback holder lytteren utenfor LAN-et, men på en delt maskin er det ingen autorisasjonsgrense, fordi andre lokale prosesser også kan nå den. Referansen for OpenSSH-klienten dokumenterer alle disse flaggene, og loopback-advarselen følger av hva en lyttende socket er.
Send navn gjennom proxyen, ikke utenom den
En SOCKS5-klient kan slå opp destinasjonen selv eller be proxyen gjøre det, og det valget avgjør hvilken resolver som svarer. Med socks5h sender curl vertsnavnet gjennom proxyen, slik at oppslaget skjer på SSH-serveren. Med vanlig socks5 slår laptopen opp først, og bare forbindelsen reiser, noe som stille undergraver poenget når navnet er internt. Forespørselen nedenfor tømmer også listen uten proxy, slik at en nedarvet NO_PROXY-verdi ikke kan lede den utenom proxyen.
curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/healthSertifikatvalidering og applikasjonens egen innlogging gjelder fortsatt, fordi proxyen ikke erstatter noen av dem. Det gjenstår to oppslag: laptopen må nå SSH-verten gjennom den tillatte VPN- og DNS-veien, og SSH-serveren må slå opp applikasjonsnavnet selv. Det andre kan testes alene før noe trafikk går gjennom proxyen.
ssh [email protected] getent hosts app.corp.exampleBevis én tillatt destinasjon, og lukk deretter sesjonen
Test en destinasjon som policyen tillater og en den bør avvise, fordi en fungerende viderekobling bare beviser at lytteren virker, og ikke noe mer. Applikasjonen ser kildeadressen SSH-serveren velger, og det er ikke tunneladressen til laptopen din. Der den andre enden logger forbindelser etter kilde, er den forskjellen det første som må sjekkes når en forespørsel avvises.
Stopp sesjonen gjennom prosessen som eier den, i stedet for å drepe et urelatert skall. Bekreft deretter at lytteren er borte, fordi en port som fortsatt svarer, er en sesjon du ikke egentlig har lukket. Fjern bare proxyinnstillingen som denne øvelsen innførte, og la resten av applikasjonskonfigurasjonen være. En terminal uten tilsyn som holder på en viderekoblingsregel, er ikke en tjeneste, og en permanent proxy trenger en godkjent livssyklus, ikke et glemt vindu.
ss -ltn | grep 1080Feil som denne ordningen ikke kan rette
Noen symptomer peker rett på grensene ovenfor, og å kjenne dem igjen tidlig sparer en ettermiddag med proxy-feilsøking. Tabellen kobler det du ser til det det vanligvis betyr. Alt i den siste kolonnen er et designspørsmål, ikke en 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 |
De tre første radene er dem folk feildiagnostiserer, fordi hver av dem gir et tilkoblingsforsøk i stedet for en feil om selve proxyen. Et navn som løses opp på laptopen, sier ingenting om serverens resolver, og feilen leses i stedet som et sertifikat- eller tidsavbruddsproblem. Applikasjoner med bare UDP står utenfor designet, ikke ødelagt inni det, og ingen ekstra ssh-opsjon endrer det. Nettleserraden er den vanlige påminnelsen om at proxyinnstillinger gjelder per applikasjon. Den siste raden er grunnen til at avslutningssjekken finnes: en port som fortsatt lytter, betyr at noe annet eier den nå.