Dynamické přesměrování SSH jako proxy SOCKS přes vaši VPN
Aplikace, která mluví jen SOCKS, nemá na běžné VPN žádný koncový bod proxy. Dva skoky, jeden loopbackový posluchač a jedno hledání jména, které musí provést sám server SSH.
Aplikace, která mluví jen SOCKS, nemá na běžné VPN s kým mluvit, protože tunel přenáší pakety a aplikace chce koncový bod proxy. OpenSSH může takový bod poskytnout, když to vlastník přístupu dovolí, protože dynamické přesměrování mění jednu relaci SSH v místní proxy. Pak je třeba držet rovně dva skoky: tunel, který dosáhne hostitele SSH, a spojení, které tento hostitel následně otevře. Jejich oddělení vysvětluje jak to, proč uspořádání funguje, tak to, co nikdy neudělá.
Čím se posluchač SSH stává a čím ne
Dynamické přesměrování nutí klienta SSH naslouchat lokálně a mluvit SOCKS4 nebo SOCKS5 se vším, co se připojí. Každý požadavek pojmenuje cíl a server SSH otevře další spojení, a proto se hledání cíle může odehrát na vzdálené straně. To je přesměrování TCP na úrovni aplikace, ne VPN pro celé zařízení. Nepřenáší žádnou asociaci UDP, žádné ICMP ani nic pro aplikace, které nastavení proxy úplně ignorují. Skok ze serveru SSH do aplikace také není uvnitř vašeho tunelu, což je důležité, když cíl přijímá provoz jen ze známých sítí.
Předpoklady jsou skutečné: trasa k hostiteli SSH, autorizovaný účet, ověřený klíč hostitele serveru a oprávnění přesměrovávat. Žádný z nich proxy nevytváří, a ten poslední obvykle chybí jako první. Potvrďte všechny čtyři, než začnete ladit cokoli jiného, protože z pohledu klienta selhání vypadá stejně, ať chybí kterýkoli.
Spusťte ho na loopbacku s výslovným portem
Vyberte nepoužívaný místní port a výslovně ho svažte s loopbackem, místo abyste adresu vynechali. Tři možnosti níže existují každá z jednoho důvodu.
ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
[email protected]-N vynechá vzdálený příkaz a -T vynechá pseudoterminál, takže relace existuje jen kvůli přesměrování. ExitOnForwardFailure přiměje klienta ukončit se, když posluchače nelze vytvořit, místo aby běžel bez požadovaného přesměrování. ControlPath=none drží relaci mimo existující multiplexované spojení, které by mohlo přidat vlastní přesměrování. Loopback drží posluchače mimo LAN, ale na sdíleném stroji to není hranice oprávnění, protože se k němu dostanou i jiné místní procesy. Reference klienta OpenSSH dokumentuje všechny tyto přepínače a varování ohledně loopbacku vyplývá z toho, co je naslouchající socket.
Posílejte jména skrz proxy, ne kolem ní
Klient SOCKS5 může cíl vyřešit sám nebo o to požádat proxy, a tato volba rozhoduje, který resolver odpoví. S socks5h posílá curl jméno hostitele skrz proxy, takže hledání proběhne na serveru SSH. S obyčejným socks5 notebook nejdřív vyřeší sám a cestuje jen spojení, což tiše ruší smysl, když je jméno interní. Požadavek níže také čistí seznam bez proxy, takže zděděná hodnota NO_PROXY ho nemůže vést kolem proxy.
curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/healthOvěření certifikátu i vlastní přihlášení aplikace platí dál, protože proxy nenahrazuje ani jedno. Zůstávají dvě hledání: notebook musí dosáhnout hostitele SSH povolenou cestou VPN a DNS a server SSH musí sám vyřešit jméno aplikace. Druhé lze otestovat samostatně, než přes proxy proteče jakýkoli provoz.
ssh [email protected] getent hosts app.corp.exampleDokažte jeden povolený cíl a pak relaci ukončete
Otestujte cíl, který politika povoluje, i ten, který má odmítnout, protože funkční přesměrování dokazuje jen to, že posluchač funguje, a nic víc. Aplikace vidí zdrojovou adresu, kterou zvolí server SSH, a to není adresa tunelu vašeho notebooku. Když vzdálená strana loguje spojení podle zdroje, je tento rozdíl první věcí, kterou je třeba zkontrolovat, když je požadavek odmítnut.
Ukončete relaci přes proces, který ji vlastní, místo abyste zabíjeli nesouvisející shell. Pak potvrďte, že posluchač zmizel, protože port, který stále odpovídá, je relace, kterou jste ve skutečnosti nezavřeli. Odstraňte jen nastavení proxy, které zavedlo toto cvičení, a zbytek konfigurace aplikace nechte být. Neobsluhovaný terminál s pravidlem přesměrování není služba a trvalá proxy potřebuje schválený životní cyklus, ne zapomenuté okno.
ss -ltn | grep 1080Selhání, která toto uspořádání nedokáže opravit
Některé příznaky míří přímo na výše uvedené meze a jejich včasné rozpoznání ušetří odpoledne ladění proxy. Tabulka spojuje to, co vidíte, s tím, co to obvykle znamená. Cokoli v posledním sloupci je otázka návrhu, ne chyba konfigurace.
| 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 |
První tři řádky jsou ty, které lidé špatně diagnostikují, protože každý vytváří pokus o spojení, ne chybu o samotné proxy. Jméno, které se vyřeší na notebooku, nic neříká o resolveru serveru a selhání se místo toho čte jako problém s certifikátem nebo časovým limitem. Aplikace jen s UDP stojí mimo návrh, ne pokažené uvnitř něj, a žádná další volba ssh to nezmění. Řádek s prohlížečem je obvyklá připomínka, že nastavení proxy platí pro každou aplikaci zvlášť. Poslední řádek je důvod, proč kontrola při ukončení existuje: port, který stále naslouchá, znamená, že ho teď vlastní něco jiného.