SSH helyi továbbítás egy meglévő HTTP-proxyhoz: két loopback-cím

A jóváhagyott proxy egy ugrógazdagépen fut, ahol csak a loopbacken figyel, így azon a gépen kívülről semmi sem érheti el. Nem VPN-re vagy új proxyra van szüksége; arra van szüksége, hogy a gép egyik portja az Ön egyik portjára legyen átvezetve. A helyi továbbítás pontosan ezt teszi, és egy parancsot plusz egy alkalmazásbeállítást igényel. A zavar általában abból ered, hogy összekeverjük, melyik loopback-cím melyik géphez tartozik.

Döntse el, létezik-e már rögzített proxy

Ez a technika egy már futó szolgáltatást továbbít. Ha a távoli gazdagépen csak SSH-démon van, proxy pedig nincs, semmilyen mennyiségű továbbítás nem hoz létre egyet, és a kapcsolatot a távoli oldal el fogja utasítani. Erősítse meg, hogy a proxy kötve van, melyik a portja, és hogy a 127.0.0.1-en vagy egy adott interfészcímen figyel-e, mert a továbbításnak ezt a címet kell megcéloznia.

Ennek előzetes megerősítése megkíméli attól, hogy olyan alagutat hibakeressen, amely soha nem kapcsolódott semmihez.

Építse fel a továbbítást, és olvassa el a parancsot

A kívánt forma egy loopback-portot köt a laptopján, és a kiszolgáló oldaláról a proxy címéhez kapcsolja, ahogyan a kiszolgáló látja.

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

A -N elnyomja a távoli parancsot, a -T pedig elnyomja a termios kiosztását, mert alagutat akar, nem héjat. Az első loopback-cím az, ahol a laptop figyel; a másodikat az SSH-kiszolgáló oldja fel, tehát a 127.0.0.1 ott az adott gépen lévő proxyt jelenti. A ExitOnForwardFailure hangosan meghiúsítja a parancsot, ha a helyi port már foglalt, ahelyett hogy olyan munkamenetet indítana, amely semmit nem továbbít. A célcímet úgy írja, ahogyan a kiszolgáló feloldja, mert egy név, amelyet csak a laptopja tud feloldani, a túloldalon meghiúsul.

A kiszolgáló saját szabályzata érvényes, mielőtt bármi ebből működne. A AllowTcpForwarding engedélyeznie kell, a PermitOpen pedig korlátozhatja, hogy egy munkamenet mely célokat és portokat érheti el, így egy továbbítást, amelyet az ügyfél elfogad, a kiszolgáló még mindig elutasíthat. Az elutasítás továbbítási vagy csatornahibaként jelenik meg az ügyfélnél, és ezt az üzenetet gyorsabb elolvasni, mint a parancsot szerkeszteni.

Irányítson egy alkalmazást a továbbításra

Állítsa be az alkalmazást, hogy HTTP-proxyt használjon a http://127.0.0.1:13128 címen, hitelesítő adatokkal, ha a távoli proxy megköveteli azokat. Tartsa meg az alkalmazás saját tanúsítvány-ellenőrzését a HTTPS-célokhoz, mivel a proxy alagút nem helyettesíti azt. Ez egy szolgáltatás rögzített továbbítása, ezért meg kell mondani az alkalmazásnak, hogy van proxy, nem pedig magára hagyni, hogy felfedezzen egyet.

Gyors ellenőrzés bármilyen tartós beállítás előtt: curl -x http://127.0.0.1:13128 -I https://example.com, amely gyakorolja azt az HTTP CONNECT metódust, amelyet a proxynak támogatnia kell.

Tartsa a felhatalmazást ott, ahol volt

A távoli proxy továbbra is eldönti, mely célokat és metódusokat engedélyez, és egy SSH-bejelentkezés nem adhat csendben minden fióknak általános webes relayt. A laptopon a 127.0.0.1-hez kötés elkerüli a port közzétételét a helyi hálózatán, és nem teszi a portot priváttá ugyanazon gép más folyamataitól. Ennek a kötésnek wildcard-címmel való helyettesítése a proxy megosztásához az, ahogyan egy nem kezelt nyílt relay létrejön.

Az SSH-szállítás védi az ugrást a kiszolgálóig. Ezen a ponton túl a proxy saját kapcsolatot nyit, így egy cél felé menő egyszerű HTTP-kérés a kiszolgálón túl is egyszerű marad, pedig az első szakasz titkosítva volt.

Ellenőrizze mindkét végét, majd tisztítson

A helyi alagút beállítása és a távoli szolgáltatás sikere különböző eredmények, és a parancs kilépési állapota csak az elsőről mond valamit. Ellenőrizze a ss -ltn segítségével, hogy létezik-e a figyelő, majd végezzen egy engedélyezett alkalmazáskérést és egy kérést, amelyet a proxynak el kell utasítania. Ha mindkettő a várt módon viselkedik, az útvonal valódi; ha az alagút fut, és minden kérés meghiúsul, a proxy elutasít, vagy nem éri el a célt.

Amikor végzett, állítsa le a tulajdonos SSH-folyamatot, távolítsa el a proxybeállítást az alkalmazásból, és erősítse meg, hogy a helyi port eltűnt, ahelyett hogy egy figyelőt hagyna, amely túléli a feladatot.