sshuttle kontra teljes VPN: mit fed le valójában a módszere

Az sshuttle-t azért választják, mert az SSH már működik, és a titkosítás ismerősnek tűnik, és ez az érvelés kihagyja az egyetlen kérdést, amely eldönti az alkalmasságot. Mely csomagok hagyják el a gépet, melyik fiók viszi őket a túloldalon, és mennyi helyi jogosultságot igényel az eszköz. Ez a három válasz továbbítási módszerenként eltér, ezért az egyik alkalmazásnál működő beállítás a következőnél csendben elbukhat. Az alábbi áttekintés abból a protokollból indul ki, amelyre az alkalmazásnak valóban szüksége van.

Kezdje azzal a protokollal, amelyre az alkalmazásnak szüksége van

A protokolltámogatás az sshuttle 2.0-ban a választott módszertől függ. A Linux NAT és nft módszerei a TCP-t és a DNS-t kezelik, a TPROXY pedig általános UDP-t ad hozzá. Minden platformnak és módszernek megvannak a saját határai, és a macOS teljesen más mechanizmussal fog el. Jegyezze fel a telepített verziót, a választott módszert és az alkalmazás által igényelt protokollokat, mielőtt bármit választana.

Egy működő TCP-kérés tehát nagyon keveset bizonyít egy UDP-alkalmazásról vagy minden DNS-lekérdezésről. Az sshuttle a TCP-t is folyamként kezeli ahelyett, hogy teljes IP-csomagokat tunnelezne, ezért a hagyományos VPN-től kölcsönzött átviteli következtetés nem vihető át. Hasonlítsa össze a ténylegesen futtatott mechanizmust a ténylegesen meglévő terheléssel.

Mire van szüksége az ügyfélnek helyben

A dokumentált ügyfél-elrendezés root vagy sudo jogosultságot igényel, mert helyi elfogási szabályokat telepít ahelyett, hogy tunelinterfészt hozna létre. Ez az egyetlen tény megváltoztatja a biztonsági történetet: az ilyen jogosultságú folyamat az egész gép forgalmát átirányíthatja, nem csak egy alkalmazásét. Kezelje a jogosultságot a tervezés részeként, és ne telepítési részletként.

Erősítse meg, mely szabályokat telepítette az eszköz, és hogy kilépéskor eltűnnek-e. Az összeomlott munkamenet, amely elfogási szabályokat hagy maga után, jóval azután is fekete lyukba küldheti a forgalmat, hogy az üzemeltető azt hiszi, a kapcsolat megszűnt, és a tünet hálózati kiesésnek látszik, nem hátramaradt szabálynak.

sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip route

Az első parancs egy tipikus hívás formája, a valóban szükséges előtaggal. A második megmutatja, mit telepített az eszköz, a harmadik pedig megerősíti, hogy nem jelent meg tunelinterfész, ami ennél a tervezésnél a várt eredmény.

Mit futtat a távoli oldal

A távoli oldal egy engedélyezett SSH-fiók és egy kompatibilis Python-segédkörnyezet. A korlátozott shell alatt sikeres bejelentkezés nem ad automatikusan engedélyt a segéd futtatására, és a segéd futtatására képes fiók sem ér el automatikusan minden célzott szolgáltatást. Mindkét tény a hozzáférési kérésbe tartozik, nem a hibaelhárítási jegyzetekbe.

Védje a gazdagép identitásának ellenőrzését és a fiók hitelesítését. Egy ismeretlen gazdagépkulcs elfogadása az első kapcsolat működéséért eltávolítja annak ellenőrzését, hogy a távoli oldal a szándékolt gép-e, és ez itt súlyosabban esik latba, mint egyetlen célú továbbításnál.

Korlátozza a távoli fiókot a munkafolyamat által igényelt szolgáltatásokra, és egyeztesse ezt a kört a gazdagépet üzemeltetőkkel. Ők a bizalmi kapcsolat részei, és semmilyen ügyféloldali beállítás nem változtat ezen.

Hol húzódik a bizalmi határ

Egy privát API-kapcsolat SSH-n át történő továbbítása nem engedélyez minden API-műveletet. Az alkalmazás TLS-e és az alkalmazásba való bejelentkezés továbbra is érvényes, és az eszköz nem tud biztonságossá tenni egy hitelesítés nélküli szolgáltatást. A távoli gazdagéptől induló további ugrás sem azonos automatikusan az SSH-csatornáéval megegyező védett szegmenssel, mert az a második kapcsolat a távoli gazdagép mindenkori házirendjét követi.

Írja le a határt egyetlen mondatban: a forgalom ezekhez az előtagokhoz ezen a fiókon keresztül hagyja el azt a gazdagépet. Ha a mondathoz egy bekezdésnyi kivétel kell, a tervezés többet tesz, mint amit a dokumentációja állít, és érdemes másodszor is megnézni, mielőtt élesbe kerül.

Protokollonként bizonyítsa, aztán válasszon eszközt

Teszteljen minden szükséges protokollt egy ártalmatlan kéréssel, beleértve a feloldó útvonalát és az alkalmazás által használt címcsaládokat. Ikessen be egy bontást is a tesztbe, hogy az alkalmazás engedélyezett hiba-viselkedése ismert eredmény legyen, ne pedig meglepetés egy incidens közben. Egy munkamenet, amely működése alatt helyesen továbbított, semmit nem mond arról, mi történik, ha elesik.

Néhány kifejezetten megnevezett szolgáltatás esetén egy közönséges helyi továbbítás könnyebben birtokolható és auditálható. Az olyan alkalmazásforgalomhoz, amely illik a módszeréhez, az sshuttle legitim középutat kínál. Ha a követelmény széles IP-kapcsolat, a VPN-tervezés az őszinte válasz, és a választás a lefedettséget és az üzemeltetési felelősséget követi, nem a titkosítási algoritmusok rangsorát.