Redirecționare locală SSH către un proxy HTTP existent: două adrese loopback

Proxy-ul dumneavoastră aprobat rulează pe un host de salt unde ascultă doar pe loopback, așa că nimic din afara acelei mașini nu îl poate atinge. Nu aveți nevoie de VPN sau de un proxy nou; aveți nevoie de un port al acelei mașini adus la un port al dumneavoastră. O redirecționare locală face exact asta și cere o comandă plus o setare a aplicației. Confuzia apare de obicei din încurcarea adresei loopback care aparține fiecărei mașini.

Decideți dacă există deja un proxy fix

Această tehnică redirecționează un serviciu care rulează deja. Dacă gazda la distanță are doar un demon SSH și niciun proxy, nicio cantitate de redirecționare nu va crea unul, iar conexiunea va fi refuzată din partea la distanță. Confirmați că proxy-ul este legat, care este portul lui și dacă ascultă pe 127.0.0.1 sau pe o adresă de interfață anume, pentru că acea adresă este ținta pe care trebuie să o vizeze redirecționarea.

Dacă verificați asta mai întâi, vă scutiți de depanarea unui tunel care nu a fost niciodată conectat la nimic.

Construiți redirecționarea și citiți comanda

Forma dorită leagă un port loopback pe laptopul dumneavoastră și îl conectează, din partea serverului, la adresa proxy-ului așa cum o vede serverul.

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

-N suprimă o comandă la distanță, iar -T suprimă alocarea termios, pentru că doriți un tunel, nu un shell. Prima adresă loopback este locul unde ascultă laptopul; a doua este rezolvată de serverul SSH, așa că 127.0.0.1 acolo înseamnă proxy-ul de pe acea mașină. ExitOnForwardFailure face comanda să eșueze zgomotos dacă portul local este deja ocupat, în loc să pornească o sesiune care nu redirecționează nimic. Scrieți adresa țintă așa cum o rezolvă serverul, pentru că un nume pe care doar laptopul dumneavoastră îl poate rezolva va eșua în cealaltă parte.

Politica serverului însuși se aplică înainte ca orice din toate acestea să funcționeze. AllowTcpForwarding trebuie să permită asta, iar PermitOpen poate restricționa la ce destinații și porturi poate ajunge o sesiune, așa că o redirecționare acceptată de client poate fi totuși refuzată de server. Refuzul apare ca eroare de redirecționare sau de canal la client, iar citirea acelui mesaj este mai rapidă decât editarea comenzii.

Îndreptați o aplicație spre redirecționare

Configurați aplicația să folosească un proxy HTTP la http://127.0.0.1:13128, cu credențiale dacă proxy-ul de la distanță le cere. Păstrați verificarea certificatelor proprie aplicației pentru destinații HTTPS, fiindcă tunelul proxy-ului nu o înlocuiește. Aceasta este o redirecționare fixă a unui serviciu, așa că aplicației trebuie să i se spună de un proxy, în loc să fie lăsată să descopere una singură.

O verificare rapidă înainte de orice configurare permanentă: curl -x http://127.0.0.1:13128 -I https://example.com, care exersează metoda HTTP CONNECT pe care proxy-ul trebuie să o accepte.

Păstrați autoritatea acolo unde a fost

Proxy-ul de la distanță decide în continuare ce destinații și metode permite, iar o autentificare SSH nu ar trebui să acorde în tăcere fiecărui cont un releu web general. Legarea la 127.0.0.1 pe laptop evită publicarea portului în rețeaua dumneavoastră locală și nu face portul privat față de alte procese de pe aceeași mașină. Înlocuirea acelei legături cu o adresă wildcard pentru a partaja proxy-ul este felul în care apare un releu deschis neadministrat.

Transportul SSH protejează saltul până la server. Dincolo de acel punct proxy-ul deschide propria conexiune, așa că o cerere HTTP simplă către o destinație rămâne simplă și dincolo de server, chiar dacă primul segment a fost criptat.

Verificați ambele capete, apoi curățați

Configurarea tunelului local și succesul serviciului la distanță sunt rezultate diferite, iar starea de ieșire a comenzii vă spune doar despre primul. Verificați că ascultătorul există cu ss -ltn, apoi faceți o cerere permisă a aplicației și o cerere pe care proxy-ul ar trebui să o refuze. Dacă ambele se comportă conform așteptărilor, calea este reală; dacă tunelul este activ și fiecare cerere eșuează, proxy-ul refuză sau nu poate ajunge la destinație.

Când terminați, opriți procesul SSH care îl deține, eliminați setarea proxy-ului din aplicație și confirmați că portul local a dispărut, în loc să lăsați un ascultător care supraviețuiește sarcinii.