Dynamické presmerovanie SSH ako proxy SOCKS cez vašu VPN
Aplikácia, ktorá hovorí len SOCKS, nemá na bežnej VPN žiadny koncový bod proxy. Dva skoky, jeden loopbackový poslucháč a jedno hľadanie mena, ktoré musí vykonať sám server SSH.
Aplikácia, ktorá hovorí len SOCKS, nemá na bežnej VPN s kým hovoriť, pretože tunel prenáša pakety a aplikácia chce koncový bod proxy. OpenSSH môže taký bod poskytnúť, keď to vlastník prístupu dovolí, pretože dynamické presmerovanie mení jednu reláciu SSH na miestnu proxy. Potom treba držať rovno dva skoky: tunel, ktorý dosiahne hostiteľa SSH, a spojenie, ktoré tento hostiteľ následne otvorí. Ich oddelenie vysvetľuje jednak to, prečo usporiadanie funguje, jednak to, čo nikdy neurobí.
Čím sa poslucháč SSH stáva a čím nie
Dynamické presmerovanie núti klienta SSH počúvať lokálne a hovoriť SOCKS4 alebo SOCKS5 so všetkým, čo sa pripojí. Každá požiadavka pomenuje cieľ a server SSH otvorí ďalšie spojenie, a preto sa hľadanie cieľa môže odohrať na vzdialenej strane. To je presmerovanie TCP na úrovni aplikácie, nie VPN pre celé zariadenie. Neprenáša žiadnu asociáciu UDP, žiadne ICMP ani nič pre aplikácie, ktoré úplne ignorujú nastavenia proxy. Ani skok zo servera SSH do aplikácie nie je vnútri vášho tunela, čo je dôležité, keď cieľ prijíma prevádzku len zo známych sietí.
Predpoklady sú skutočné: trasa k hostiteľovi SSH, autorizovaný účet, overený kľúč hostiteľa servera a povolenie presmerovávať. Žiadny z nich proxy nevytvára, a ten posledný zvyčajne chýba ako prvý. Potvrďte všetky štyri, než začnete ladit čokoľvek iné, pretože z pohľadu klienta zlyhanie vyzerá rovnako, ktorýkoľvek chýba.
Spustite ho na loopbacku s výslovným portom
Vyberte nepoužívaný miestny port a výslovne ho zviažte s loopbackom, namiesto toho, aby ste adresu vynechali. Tri možnosti nižšie existujú každá z jedného dôvodu.
ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
[email protected]-N vynechá vzdialený príkaz a -T vynechá pseudoterminál, takže relácia existuje len kvôli presmerovaniu. ExitOnForwardFailure prinúti klienta ukončiť sa, keď poslucháča nemožno vytvoriť, namiesto behu bez požadovaného presmerovania. ControlPath=none drží reláciu mimo existujúceho multiplexovaného spojenia, ktoré by mohlo pridať vlastné presmerovania. Loopback drží poslucháča mimo LAN, ale na zdieľanom stroji to nie je hranica oprávnení, pretože sa k nemu dostanú aj iné miestne procesy. Referencia klienta OpenSSH dokumentuje všetky tieto prepínače a varovanie o loopbacku vyplýva z toho, čo je počúvajúci socket.
Posielajte mená cez proxy, nie okolo nej
Klient SOCKS5 môže cieľ vyriešiť sám alebo o to požiadať proxy, a táto voľba rozhoduje, ktorý resolver odpovie. S socks5h posiela curl meno hostiteľa cez proxy, takže hľadanie prebehne na serveri SSH. S obyčajným socks5 notebook najprv vyrieši sám a cestuje len spojenie, čo potichu ruší zmysel, keď je meno interné. Požiadavka nižšie tiež čistí zoznam bez proxy, takže zdedená hodnota NO_PROXY ho nemôže viesť okolo proxy.
curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/healthOverenie certifikátu aj vlastné prihlásenie aplikácie platia ďalej, pretože proxy nenahrádza ani jedno. Zostávajú dve hľadania: notebook musí dosiahnuť hostiteľa SSH povolenou cestou VPN a DNS a server SSH musí sám vyriešiť meno aplikácie. Druhé možno otestovať samostatne, než cez proxy pretečie akákoľvek prevádzka.
ssh [email protected] getent hosts app.corp.exampleDokážte jeden povolený cieľ a potom reláciu ukončite
Otestujte cieľ, ktorý politika povoľuje, aj ten, ktorý má odmietnuť, pretože funkčné presmerovanie dokazuje len to, že poslucháč funguje, a nič viac. Aplikácia vidí zdrojovú adresu, ktorú zvolí server SSH, a to nie je adresa tunela vášho notebooku. Keď vzdialená strana loguje spojenia podľa zdroja, je tento rozdiel prvou vecou, ktorú treba skontrolovať, keď je požiadavka odmietnutá.
Ukončite reláciu cez proces, ktorý ju vlastní, namiesto zabíjania nesúvisiaceho shellu. Potom potvrďte, že poslucháč zmizol, pretože port, ktorý stále odpovedá, je relácia, ktorú ste v skutočnosti nezatvorili. Odstráňte len nastavenie proxy, ktoré zaviedlo toto cvičenie, a zvyšok konfigurácie aplikácie nechajte na pokoji. Neobsluhovaný terminál s pravidlom presmerovania nie je služba a trvalá proxy potrebuje schválený životný cyklus, nie zabudnuté okno.
ss -ltn | grep 1080Zlyhania, ktoré toto usporiadanie nedokáže opraviť
Niektoré príznaky ukazujú priamo na vyššie uvedené hranice a ich včasné rozpoznanie ušetrí popoludnie ladenia proxy. Tabuľka spája to, čo vidíte, s tým, čo to zvyčajne znamená. Čokoľvek v poslednom stĺpci je otázka návrhu, nie chyba konfigurácie.
| 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 |
Prvé tri riadky sú tie, ktoré ľudia diagnostikujú nesprávne, pretože každý vytvára pokus o spojenie namiesto chyby o samotnej proxy. Meno, ktoré sa vyrieši na notebooku, nič nehovorí o resolveri servera a zlyhanie sa namiesto toho číta ako problém s certifikátom alebo časovým limitom. Aplikácie len s UDP stoja mimo návrhu, nie pokazené vnútri neho, a žiadny ďalší prepínač ssh to nezmení. Riadok s prehliadačom je obvyklá pripomienka, že nastavenia proxy platia pre každú aplikáciu zvlášť. Posledný riadok je dôvod, prečo kontrola pri ukončení existuje: port, ktorý stále počúva, znamená, že ho teraz vlastní niečo iné.