SSH lokalno prosljeđivanje prema postojećem HTTP proxyju: dvije loopback adrese

Vaš odobreni proxy radi na jump hostu gdje sluša samo na loopbacku, pa mu ništa izvan tog računala ne može pristupiti. Ne trebate VPN ili novi proxy; treba vam jedan port tog računala prenesen na jedan vaš port. Lokalno prosljeđivanje radi upravo to i traži jednu naredbu plus jednu postavku aplikacije. Zabuna obično nastaje miješanjem koja loopback adresa pripada kojem računalu.

Utvrdite postoji li već fiksni proxy

Ova tehnika prosljeđuje uslugu koja već radi. Ako udaljeni host ima samo SSH daemon i nema proxy, nikakvo prosljeđivanje ga ne stvara, a veza će biti odbijena s udaljene strane. Potvrdite da je proxy vezan, na kojem portu i sluša li na 127.0.0.1 ili na određenoj adresi sučelja, jer ta adresa mora biti cilj prosljeđivanja.

Ako to potvrdite prvo, uštedjet ćete si otklanjanje pogrešaka na tunelu koji nikada nije bio povezan ni s čim.

Izgradite prosljeđivanje i pročitajte naredbu

Oblik koji želite veže loopback port na vašem prijenosniku i povezuje ga, sa strane poslužitelja, s adresom proxyja onako kako je poslužitelj vidi.

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

-N potiskuje udaljenu naredbu, a -T potiskuje dodjelu termiosa, jer želite tunel, a ne ljusku. Prva loopback adresa je mjesto gdje prijenosnik sluša; druga se razrješava s SSH poslužitelja, pa 127.0.0.1 tamo znači proxy na tom računalu. ExitOnForwardFailure čini da naredba glasno ne uspije ako je lokalni port već zauzet, umjesto da pokrene sesiju koja ništa ne prosljeđuje. Zapišite ciljnu adresu onako kako je poslužitelj razrješava, jer ime koje samo vaš prijenosnik može razriješiti neće uspjeti na drugoj strani.

Vlastita politika poslužitelja primjenjuje se prije nego išta od ovoga proradi. AllowTcpForwarding to mora dopustiti, a PermitOpen može ograničiti koja odredišta i portove sesija smije dosegnuti, pa prosljeđivanje koje klijent prihvati poslužitelj ipak može odbiti. Odbijanje se pojavljuje kao pogreška prosljeđivanja ili kanala na klijentu, a čitanje te poruke brže je od uređivanja naredbe.

Usmjerite jednu aplikaciju na prosljeđivanje

Konfigurirajte aplikaciju da koristi HTTP proxy na http://127.0.0.1:13128, s vjerodajnicama ako ih udaljeni proxy zahtijeva. Zadržite vlastitu provjeru certifikata aplikacije za HTTPS odredišta, jer proxy tunel je ne zamjenjuje. Ovo je fiksno prosljeđivanje jedne usluge, pa aplikaciji treba reći za proxy umjesto da je ostavite da ga sama otkrije.

Brza provjera prije bilo kakve trajne postavke: curl -x http://127.0.0.1:13128 -I https://example.com, što isprobava HTTP CONNECT metodu koju proxy mora podržavati.

Zadržite ovlasti tamo gdje su bile

Udaljeni proxy i dalje odlučuje koja odredišta i metode dopušta, a SSH prijava ne bi smjela tiho dati svakom računu opći web relay. Vezanje na 127.0.0.1 na prijenosniku izbjegava objavljivanje porta na vašu lokalnu mrežu, ali port ne čini privatnim od drugih procesa na istom računalu. Zamjena tog vezanja wildcard adresom radi dijeljenja proxyja način je na koji nastaje neupravljani otvoreni relay.

SSH prijenos štiti skok do poslužitelja. Nakon te točke proxy otvara vlastitu vezu, pa običan HTTP zahtjev prema odredištu ostaje običan i nakon poslužitelja, iako je prvi segment bio šifriran.

Provjerite oba kraja, zatim počistite

Postavljanje lokalnog tunela i uspjeh udaljene usluge različiti su rezultati, a izlazni status naredbe govori samo o prvome. Provjerite postoji li slušatelj pomoću ss -ltn, zatim uputite dopušteni zahtjev aplikacije i zahtjev koji proxy treba odbiti. Ako se oba ponašaju kako se očekuje, put je stvaran; ako je tunel aktivan i svaki zahtjev ne uspije, proxy odbija ili ne može dosegnuti odredište.

Kada završite, zaustavite SSH proces koji ga drži, uklonite postavku proxyja iz aplikacije i potvrdite da je lokalni port nestao umjesto da ostavite slušatelja koji nadživi zadatak.