Melyik alkalmazásforgalmat viszi valójában egy SSH-továbbítás?

A héj, a helyi továbbítás, a SOCKS és az alagút-eszköz mód különböző felületeket kínál. Nevezze meg azt, amelyet az alkalmazása használhat, mielőtt egy irányított VPN-hez hasonlítja.

A terminál csatlakozik, megjelenik a parancssor, és mindenki egyetért abban, hogy az SSH-hozzáférés működik. Aztán a laptop adatbázis-kliense mégsem éri el a privát gazdagépet, és a munkamenetet okolják. Amit építettek, az egy héj volt, és ez a négy meglehetősen különböző felület egyike, amelyet az SSH kínálhat. Először nevezze meg a felületet, aztán ellenőrizze, hogy az alkalmazás valóban használja-e. A sorrend számít, mert minden felület a maga módján hibázik.

Nevezze meg a felületet, mielőtt bármit összehasonlít

Az OpenSSH kliens kézikönyve négy mechanizmust különböztet meg, amelyeket könnyű összekeverni. A héj vagy a távoli parancs az SSH-gazdagépen fut. A helyi továbbítás figyelő socketet nyit a kliensen, és a további kapcsolatot a távoli oldalról hozza létre. A távoli továbbítás ennek az ellenkezőjét teszi, a kiszolgáló oldalán figyelve. A dinamikus továbbítás SOCKS-végpontot tesz elérhetővé azoknak a programoknak, amelyek tudják használni.

  • Héj: a program a távoli gépen fut, helyben semmi nem figyel.
  • Helyi továbbítás: a laptopján van egy port, a távoli gazdagép hozza létre a kimenő kapcsolatot.
  • Távoli továbbítás: a távoli oldalon van egy port, a forgalom visszafelé, önhöz jön.
  • Dinamikus: SOCKS-proxy a kliensen, csak proxy-tudatos alkalmazások használják.

Ezek egyike sem telepít útvonalat. Egy program, amely figyelmen kívül hagyja a proxybeállításokat, UDP-t beszél, vagy maga oldja fel a neveket, nincs hatással egy aktív SSH-munkamenetre. Ez nem hiba az SSH-ban; ez a választott felület hatóköre.

A helyi, távoli és dinamikus továbbítás abban különbözik, ki figyel

A legtöbb esetet eldöntő különbség az, hogy ki birtokolja a figyelő socketet. Helyi továbbításnál a kliens figyel, és a távoli vég tárcsázza a célt, ezért a célcímet a kiszolgáló szemszögéből oldja fel a rendszer. Távoli továbbításnál a kiszolgáló figyel, és a kapcsolatot visszaviszik az ön oldalára, és így tesz elérhetővé egy helyi szolgáltatást anélkül, hogy közvetlenül közzétenné.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

Az első parancs az 5432-es portot köti a laptopon, és továbbítja az adatbázis felé úgy, ahogy a bástyáról látszik. A második SOCKS-proxyt hoz létre az 1080-as porton. A harmadik parancs megerősíti, mely folyamatok figyelnek valójában, és ez az egyetlen bizonyíték arra, hogy a továbbítás létezik, és nem bukott el csendben egy portütközés miatt.

A dinamikus továbbítás megérdemli a saját figyelmeztetését: csak azokat az alkalmazásokat fedi le, amelyek tiszteletben tartják a SOCKS-t. Egy böngésző ráirányítható, egy parancssori eszköznek megmondható, hogy használja, de egy saját kapcsolati vermet használó adatbázis-illesztőprogram általában nem képes rá. Az a feltételezés, hogy a gépen minden program most az alagutat használja, a leggyakoribb hiba ezen a területen.

Az alagút-eszköz mód az egyetlen valódi hálózati kivétel

Az OpenSSH az -w alagút-eszköz továbbítást is támogatja, amely pont-pont felületet ad át TCP-figyelő helyett. Ez valódi hálózati alagút, és szándékosan konfigurálják, nem egy héj megnyitásának mellékhatása.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Ehhez a megfelelő felületszámoknak mindkét végén elérhetőnek kell lenniük, a kiszolgálón a helyes konfigurációnak, a kliensen pedig elegendő jogosultságnak kell lennie az eszköz létrehozásához. Címzési és útvonaltervre is szükség van, mert egy csupasz felület nem hordoz semmilyen szabályt arról, mely célok használják.

Még ekkor is a távoli gazdagépnél végződik az alagút. Az SSH-szállítás nyújtotta védelem ott véget ér, és a további kapcsolat külön ugrás. Egy VPN-átjáró határának ugyanilyen az alakja, ezért az összehasonlításnak a hatókörről és a végződésről kell szólnia, nem arról, melyik eszköz erősebb. A határ hangos megnevezése azt a vitát is lezárja, hogy egy alagút «mindent titkosít-e», mert nyilvánvalóan nem.

Ellenőrizze, hogy az alkalmazása a felépített felületet használja

Az ellenőrzés alkalmazásonként történik, nem munkamenetenként. Egy működő továbbítás bizonyítja, hogy a port kötve van és a távoli oldal tárcsázni tud; azt nem bizonyítja, hogy az ön számára fontos program azon keresztül kapcsolódott.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

Az első parancs kérést küld a SOCKS-végponton keresztül, a gazdagépnevet távolról feloldva, a második pedig a továbbított adatbázis-portot gyakorolja, miközben a TLS továbbra is kötelező. Futtassa ugyanezeket a teszteket leállított továbbítás mellett, hogy megerősítse, hogy elbuknak, mert egy teszt, amely mindkét módon átmegy, soha nem használta az alagutat.

Ezután csak azokban a dimenziókban hasonlítsa össze egy irányított VPN-nel, amelyek számítanak: mely célok vannak lefedve, mely protokollok működnek, hol végződik a védelem, és kinek kell jóváhagynia a hozzáférést. Egyetlen szolgáltatás továbbítása lehet a szűkebb és jobb válasz, míg a VPN a megfelelő forma, amikor sok alkalmazásnak ugyanarra a hálózati útra van szüksége. Egyik sem ad mindent, ami a távoli végpontjáról elérhető.

Kapcsolódó cikkek