Azt feltételezi, hogy a SOCKS-proxynak ott kell futnia, ahol a hálózati hozzáférés már létezik. Az OpenSSH a figyelőt egészen máshova helyezheti. A távoli dinamikus továbbítás a SOCKS-portot egy távoli gazdagépen nyitja meg, és minden kapcsolatot a helyi SSH-klienséből indít, amely a laptopja jóváhagyott VPN-útvonalát viszi. A Pi korlátozott proxyt kap; nem örökli a bújtatást vagy a jogosultságait.

A figyelő és a kapcsolatot indító oldal különbözhet

Egy közönséges ssh -D 1080 a saját gépén futtatja a figyelőt, és onnan küldi a kapcsolatokat. A távoli dinamikus továbbítás ezt fordítja meg: a figyelő a távoli gazdagépen jelenik meg, és minden kapcsolat, amelyet elfogad, a helyi oldalról nyílik. A OpenSSH-kliens kézikönyve a -R kapcsolót fix cél nélkül pontosan ennek a SOCKS4/5-elrendezésnek írja le.

Egy támogatott parancs a laptoptól így néz ki, a fiók, a gazdagépek és a port helyőrzőként kezelve:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

Három részlet végez ott hasznos munkát. A -S none távol tartja a munkamenetet egy megosztott vezérlő-mastertől, a ExitOnForwardFailure gyorsan meghiúsul ahelyett, hogy félig nyitott munkamenettel hagyná, és a PermitRemoteOpen korlátozza, hogy a távoli figyelő mit érhet el. Használjon engedélyezett Pi-fiókot, és ellenőrizze a gazdagép kulcsát, mielőtt bármit is hozzáadna ebből.

Mit tesz valójában elérhetővé a távoli figyelő

Ellenőrizze a kiszolgáló továbbítási szabályzatát, mielőtt a figyelőre támaszkodna. A GatewayPorts no beállítással a távoli továbbítás loopbackhez kötve marad, és ez az a kitettség, amelyet szeretne. A wildcard-továbbítást kényszerítő kiszolgáló ugyanazt a portot teszi közzé minden interfészen, ami a személyes proxyt a helyi hálózat számára elérhetővé teszi.

A loopback sem felhasználónkénti határ. A Pi egy másik folyamata is csatlakozhat a 127.0.0.1:1080 címhez, ha ismeri a portot, tehát a Pi helyi fiókjai és minden, ami rajta fut, a hozzáférési terv része. Ez érv a célok listájának szűken tartása mellett, nem érv a szabályzatellenőrzés kihagyása mellett.

Tartsa az engedélyezett célt ahhoz az alkalmazáshoz kötve, amelyet el akar érni. Ha korlátlan továbbításra cseréli, hogy egy nem kapcsolódó program működjön, az útvonalat messze a kiinduló probléma fölé szélesíti. A célok listája azt is rögzíti, mire szolgált a munkamenet, ami segít annak, aki később auditálja. Írja fel a használt fiók mellé.

Küldjön át egy alkalmazást a proxyn

A Pi-n futó, proxyt ismerő kliens ezután elküldheti a kérést. A socks5h előtag átadja a cél nevét a proxynak, így a névfeloldás és a kapcsolat is a laptop oldalán történik, és megfelel a PermitRemoteOpen beállításban megnevezett célnak:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

Tartsa meg a szokásos tanúsítvány-ellenőrzést és az alkalmazás saját hitelesítését. A proxy megváltoztatja, hol jön létre a TCP-kapcsolat; nem tesz biztonságossá egy hitelesítés nélküli szolgáltatást, és nem tesz megbízhatóvá egy önaláírt végpontot.

A laptopnak továbbra is szüksége van saját útvonalra és feloldó-hozzáférésre mind az SSH-kiszolgálóhoz, mind az alkalmazáshoz. SSH-kliense forgalmát a jóváhagyott VPN-szabályzatnak kell kiválasztania, és a split-tunnel kivétel ezt a forgalmat más útvonalon küldheti, mint amelyet tesztelt.

Bizonyítsa az útvonalat, és zárja le

Erősítse meg, hogy a figyelő ott van, ahol várja, és csak a tervezett cél válaszol:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

A ExitOnForwardFailure bizonyíthatja, hogy a továbbítás létrejött, és mégsem tudja igazolni, hogy az alkalmazásba való bejelentkezés lejjebb sikerül. Az alkalmazást tesztelje, ne csak a portot. Az a figyelő, amely elfogad, majd minden kérést elutasít, általában azt jelenti, hogy a cél neve vagy a laptop útvonala hibás, nem azt, hogy a bújtatás meghiúsult.

Ez az elrendezés csak TCP-t szállít. Az UDP, az ICMP és a proxybeállításokat figyelmen kívül hagyó programok kimaradnak belőle, és a továbbítás abban a pillanatban véget ér, amikor az SSH-munkamenet véget ér. Állítsa le ezt a munkamenetet, ha végzett, és távolítsa el a proxybeállítást, amelyet az alkalmazáshoz adott.

Állandó hozzáféréshez használja inkább a hálózat tulajdonosának támogatott regisztrációját vagy egy felügyelt átjárót. A fordított proxy a rossz eszköz egy VPN eszköz- vagy erőforráskorlátainak megkerülésére; ezeken belül használva egyszerűen egy engedélyezett alkalmazásútvonal kifejezett korlátokkal.

Kapcsolódó cikkek