Lokálne presmerovanie SSH k existujúcemu HTTP proxy: dve adresy loopback

Vaše schválené proxy beží na preskakovacom hostiteľovi, kde počúva len na loopbacku, takže nič mimo tohto stroja sa k nemu nedostane. Nepotrebujete VPN ani nové proxy; potrebujete jeden port tohto stroja prenesený na jeden svoj port. Lokálne presmerovanie robí presne to a vyžaduje jeden príkaz a jedno nastavenie aplikácie. Zmatek zvyčajne vzniká zámenou toho, ktorá adresa loopback patrí ktorému stroju.

Rozhodnite, či už existuje pevné proxy

Táto technika presmerúva službu, ktorá už beží. Ak má vzdialený hostiteľ len daemona SSH a žiadne proxy, nijaké množstvo presmerovania ho nevytvorí a spojenie bude zo vzdialenej strany odmietnuté. Overte, že proxy je naviazané, ktorý port používa a či počúva na 127.0.0.1 alebo na konkrétnej adrese rozhrania, pretože práve na túto adresu musí presmerovanie mieriť.

Ak to overíte najskôr, ušetríte si ladenie tunela, ktorý nikdy nebol k ničomu pripojený.

Zostavte presmerovanie a prečítajte príkaz

Forma, ktorú chcete, naviaže port loopback na vašom notebooku a spojí ho zo strany servera s adresou proxy tak, ako ju 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čí vzdialený príkaz a -T potlačí prideľovanie termios, pretože chcete tunel, nie shell. Prvá adresa loopback je miesto, kde počúva notebook; druhú prekladá server SSH, takže 127.0.0.1 tam znamená proxy na tom stroji. ExitOnForwardFailure spôsobí, že príkaz hlasno zlyhá, ak je lokálny port už obsadený, namiesto toho, aby spustil reláciu, ktorá nič nepresmerúva. Cieľovú adresu píšte tak, ako ju prekladá server, pretože názov, ktorý dokáže preložiť len váš notebook, na druhej strane zlyhá.

Vlastná politika servera platí predtým, než čokoľvek z toho funguje. AllowTcpForwarding to musí povoliť a PermitOpen môže obmedziť, ku ktorým cieľom a portom sa relácia dostane, takže presmerovanie, ktoré klient prijme, môže server napriek tomu odmietnuť. Odmietnutie sa na klientovi prejaví ako chyba presmerovania alebo kanála, a prečítať túto správu je rýchlejšie než upravovať príkaz.

Nasmerujte jednu aplikáciu na presmerovanie

Nastavte aplikáciu, aby používala HTTP proxy na http://127.0.0.1:13128, s prihlasovacími údajmi, ak ich vzdialené proxy vyžaduje. Zachovajte vlastné overovanie certifikátov aplikácie pre ciele HTTPS, pretože tunel proxy ho nenahrádza. Toto je pevné presmerovanie jednej služby, takže aplikácii treba povedať o proxy, a nie ju nechať, aby si ho objavila sama.

Rýchla kontrola pred akýmkoľvek trvalým nastavením: curl -x http://127.0.0.1:13128 -I https://example.com, čo precvičí metódu HTTP CONNECT, ktorú proxy musí podporovať.

Ponechajte právomoc tam, kde bola

Vzdialené proxy stále rozhoduje, ktoré ciele a metódy povoľuje, a prihlásenie SSH by nemalo každému účtu ticho dať všeobecný webový relé. Naviazanie na 127.0.0.1 na notebooku sa vyhne zverejneniu portu vo vašej lokálnej sieti a nerobí port súkromným voči iným procesom na tom istom stroji. Nahradenie tohto naviazania adresou wildcard, aby ste proxy zdieľali, je spôsob, akým vzniká nespravované otvorené relé.

Transport SSH chráni skok k serveru. Za týmto bodom si proxy otvára vlastné spojenie, takže obyčajná požiadavka HTTP na cieľ zostáva obyčajnou aj za serverom, hoci prvý úsek bol šifrovaný.

Overte oba konce a potom upratajte

Nastavenie lokálneho tunela a úspech vzdialenej služby sú rôzne výsledky a návratový kód príkazu vám hovorí len o prvom. Pomocou ss -ltn skontrolujte, či naslúchač existuje, potom odošlite povolenú požiadavku aplikácie a požiadavku, ktorú má proxy odmietnuť. Ak sa obe správajú podľa očakávania, cesta je skutočná; ak tunel beží a každá požiadavka zlyhá, proxy odmieta alebo sa k cieľu nedostane.

Keď skončíte, zastavte proces SSH, ktorý ho vlastní, odstráňte nastavenie proxy z aplikácie a overte, že lokálny port zmizol, namiesto toho, aby ste nechali naslúchač, ktorý úlohu prežije.