Lokální přesměrování SSH k existujícímu HTTP proxy: dvě adresy loopback

Vaše schválená proxy běží na přeskakovacím hostiteli, kde naslouchá jen na loopback, takže nic mimo tento stroj se k ní nedostane. Nepotřebujete VPN ani novou proxy; potřebujete jeden port tohoto stroje přenesený na jeden svůj port. Lokální přesměrování dělá přesně to a vyžaduje jeden příkaz a jedno nastavení aplikace. Zmatek obvykle vzniká záměnou toho, která adresa loopback patří kterému stroji.

Rozhodněte, zda už existuje pevná proxy

Tato technika přesměrovává službu, která už běží. Pokud má vzdálený hostitel jen daemona SSH a žádnou proxy, sebevětší přesměrování ji nevytvoří a spojení bude ze vzdálené strany odmítnuto. Ověřte, že proxy je navázaná, na kterém portu a zda naslouchá na 127.0.0.1 nebo na konkrétní adrese rozhraní, protože právě na tuto adresu musí přesměrování mířit.

Když to ověříte nejdřív, ušetříte si ladění tunelu, který nikdy nebyl k ničemu připojen.

Sestavte přesměrování a přečtěte příkaz

Forma, kterou chcete, naváže port loopback na vašem notebooku a spojí ho ze strany serveru s adresou proxy tak, jak ji server vidí.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N potlačí vzdálený příkaz a -T potlačí přidělení termios, protože chcete tunel, ne shell. První adresa loopback je místo, kde naslouchá notebook; druhá se překládá na serveru SSH, takže 127.0.0.1 tam znamená proxy na onom stroji. ExitOnForwardFailure způsobí, že příkaz hlasitě selže, pokud je místní port už obsazen, místo aby spustil relaci, která nic nepřesměrovává. Cílovou adresu pište tak, jak ji překládá server, protože jméno, které dokáže přeložit jen váš notebook, na druhé straně selže.

Než cokoli z toho začne fungovat, platí zásady samotného serveru. AllowTcpForwarding to musí povolit a PermitOpen může omezit, na které cíle a porty relace dosáhne, takže přesměrování, které klient přijme, může server přesto odmítnout. Odmítnutí se na klientu projeví jako chyba přesměrování nebo kanálu a přečíst tuto zprávu je rychlejší než upravovat příkaz.

Namiřte jednu aplikaci na přesměrování

Nastavte aplikaci, aby používala HTTP proxy na http://127.0.0.1:13128, s přihlašovacími údaji, pokud je vzdálená proxy vyžaduje. Zachovejte vlastní ověřování certifikátů aplikace pro cíle HTTPS, protože tunel proxy je nenahrazuje. Toto je pevné přesměrování jedné služby, takže aplikaci je třeba o proxy říct, ne ji nechat, aby si ji objevila.

Rychlá kontrola před jakýmkoli trvalým nastavením: curl -x http://127.0.0.1:13128 -I https://example.com, což procvičí metodu HTTP CONNECT, kterou proxy musí podporovat.

Ponechte pravomoc tam, kde byla

Vzdálená proxy stále rozhoduje, které cíle a metody povoluje, a přihlášení SSH by nemělo každému účtu tiše dát obecný webový relay. Navázání na 127.0.0.1 na notebooku se vyhne zveřejnění portu do vaší místní sítě a nečiní port soukromým vůči jiným procesům na stejném stroji. Nahrazení tohoto navázání adresou wildcard kvůli sdílení proxy je způsob, jak vzniká neřízený otevřený relay.

Transport SSH chrání skok k serveru. Za tímto bodem si proxy otevírá vlastní spojení, takže obyčejný požadavek HTTP na cíl zůstává za serverem obyčejný, i když byl první úsek šifrovaný.

Ověřte oba konce a pak ukliděte

Nastavení místního tunelu a úspěch vzdálené služby jsou různé výsledky a návratový kód příkazu vám řekne jen o prvním. Pomocí ss -ltn zkontrolujte, že naslouchač existuje, pak odešlete povolený požadavek aplikace a požadavek, který má proxy odmítnout. Pokud se oba chovají podle očekávání, cesta je skutečná; pokud tunel běží a každý požadavek selže, proxy odmítá nebo se k cíli nedostane.

Až skončíte, zastavte proces SSH, který jej vlastní, odstraňte nastavení proxy z aplikace a ověřte, že místní port zmizel, místo abyste nechali naslouchač, který úkol přežije.