sshuttle kontra en fuld VPN: hvad dens metode egentlig dækker

sshuttle vælges, fordi SSH allerede virker, og kryptografien ser velkendt ud, og den begrundelse springer det eneste spørgsmål over, som afgør, om den passer. Hvilke pakker forlader maskinen, hvilken konto bærer dem på den anden side, og hvor mange lokale rettigheder værktøjet kræver. De tre svar afhænger af videresendelsesmetoden, så en opsætning, der virker til én applikation, kan fejle lydløst til den næste. Gennemgangen nedenfor begynder ved den protokol, applikationen faktisk har brug for.

Begynd med den protokol, applikationen har brug for

Protokolunderstøttelse i sshuttle 2.0 afhænger af den metode, du vælger. Linux-metoderne NAT og nft håndterer TCP og DNS, og TPROXY tilføjer generel UDP. Hver platform og metode har sine egne grænser, og macOS opsnapper gennem en helt anden mekanisme. Notér den installerede version, den valgte metode og de protokoller, applikationen har brug for, før du vælger noget.

En fungerende TCP-anmodning beviser derfor meget lidt om en UDP-applikation eller om hvert DNS-opslag. sshuttle behandler også TCP som strømme i stedet for at tunnelere hele IP-pakker, så en gennemstrømningskonklusion lånt fra en almindelig VPN overføres ikke. Sammenlign den mekanisme, du faktisk kører, med den belastning, du faktisk har.

Hvad klienten har brug for lokalt

Det dokumenterede klientarrangement kræver root eller sudo, fordi det installerer lokale opsnapningsregler i stedet for at oprette en tunnelgrænseflade. Den ene kendsgerning ændrer sikkerhedshistorien: en proces med den rettighed kan omdirigere trafik for hele maskinen, ikke kun én applikation. Behandl rettigheden som en del af designet og ikke som en installationsdetalje.

Bekræft, hvilke regler værktøjet har installeret, og at de forsvinder, når det afsluttes. En krasjet session, der efterlader opsnapningsregler, kan sende trafik i et sort hul længe efter, at operatøren tror, forbindelsen er væk, og symptomet ligner et netværksudfald snarere end en efterladt regel.

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

Den første kommando er formen af et typisk kald med det præfiks, du faktisk har brug for. Den anden viser, hvad værktøjet installerede, og den tredje bekræfter, at der ikke dukkede en tunnelgrænseflade op, hvilket er det forventede resultat for dette design.

Hvad fjernsiden kører

Fjernsiden er en autoriseret SSH-konto plus et kompatibelt hjælpemiljø i Python. Et login, der lykkes under en begrænset shell, giver ikke automatisk tilladelse til at køre den hjælper, og en konto, der kan køre hjælperen, når ikke automatisk hver målservice. Begge forhold hører i adgangsanmodningen og ikke i fejlfindingsnoterne.

Beskyt verifikationen af værtsidentitet og kontoens godkendelse. Accept af en ukendt værtsnøgle for at få den første forbindelse til at virke fjerner kontrollen af, at fjernsiden er den maskine, du havde tænkt på, og det betyder mere her end ved en videresendelse til et enkelt formål.

Begræns fjernkontoen til de tjenester, arbejdsgangen har brug for, og forhandl det omfang med dem, der driver værten. De er en del af tillidsforholdet, og ingen indstilling på klientsiden ændrer det.

Hvor tillidsgrænsen ligger

Videresendelse af en privat API-forbindelse gennem SSH tillader ikke hver API-handling. Applikationens TLS og applikationslogin gælder stadig, og værktøjet kan ikke gøre en ikke-godkendt tjeneste sikker. Et yderligere hop fra fjernværten er heller ikke automatisk det samme beskyttede segment som SSH-kanalen, fordi den anden forbindelse følger den politik, fjernværten nu har.

Skriv grænsen som én sætning: trafik til disse præfikser forlader gennem denne konto på den vært. Hvis sætningen har brug for et afsnit med undtagelser, gør designet mere, end dokumentationen hævder, og fortjener et andet blik, før det når produktion.

Bevis det per protokol, og vælg så værktøjet

Test hver krævet protokol med en uskadelig anmodning, inklusive resolverstien og de adressefamilier, applikationen bruger. Inkluder en afbrydelse i testen, så applikationens tilladte fejladfærd bliver et kendt resultat i stedet for en overraskelse under en hændelse. En session, der videresendte korrekt, mens den var oppe, siger intet om, hvad der sker, når den falder.

For en håndfuld udtrykkeligt navngivne tjenester er en almindelig lokal videresendelse lettere at eje og lettere at revidere. For applikationstrafik, der passer til dens metode, tilbyder sshuttle en legitim mellemvej. Når kravet er bred IP-forbindelse, er et VPN-design det ærlige svar, og valget følger dækning og operationelt ansvar snarere end en rangliste over krypteringsalgoritmer.