Ge en fjärransluten Pi en SOCKS-proxy via din SSH-klient

En fjärran dynamisk vidarebefordran placerar SOCKS-lyssnaren på Pi:n och gör nästa anslutning från din laptops godkända VPN-väg. Ingen andra SSH-server.

Du utgår från att en SOCKS-proxy måste köra där nätverksåtkomsten redan finns. OpenSSH kan placera lyssnaren någon helt annanstans. En fjärran dynamisk vidarebefordran öppnar SOCKS-porten på en fjärrvärd och låter varje anslutning utgå från din lokala SSH-klient, som bär din laptops godkända VPN-väg. Pi:n får en avgränsad proxy; den ärver inte din tunnel eller dina privilegier.

Lyssnaren och sidan som anslutningen utgår från kan skilja sig

En vanlig ssh -D 1080 kör lyssnaren på din egen maskin och skickar anslutningar därifrån. En fjärran dynamisk vidarebefordran vänder på det: lyssnaren dyker upp på fjärrvärden och varje anslutning den tar emot öppnas från den lokala sidan. manualen för OpenSSH-klienten dokumenterar -R utan ett fast mål som just detta SOCKS4/5-arrangemang.

Ett kommando som stöds från laptopen ser ut så här, där kontot, värdarna och porten behandlas som platshållare:

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

Tre detaljer gör nyttigt arbete där. -S none håller sessionen borta från en delad kontrollmaster, ExitOnForwardFailure misslyckas snabbt i stället för att lämna dig med en halvöppen session, och PermitRemoteOpen begränsar vad fjärrlyssnaren kan nå. Använd ett auktoriserat Pi-konto och verifiera värdnyckeln innan du lägger till något av detta.

Vad fjärrlyssnaren egentligen exponerar

Kontrollera serverns vidarebefordringspolicy innan du förlitar dig på lyssnaren. Med GatewayPorts no förblir den fjärran vidarebefordran bunden till loopback, och det är den exponering du vill ha. En server som är inställd på att tvinga fram jokerteckenvidarebefordran publicerar samma port på varje gränssnitt, vilket gör en personlig proxy till något det lokala nätverket kan nå.

Loopback är inte heller någon gräns per användare. En annan process på Pi:n kan ansluta till 127.0.0.1:1080 om den känner till porten, så Pi:ns lokala konton och allt som körs där är en del av din åtkomstmodell. Det är ett skäl att hålla mållistan smal, inte ett skäl att hoppa över policykontrollen.

Håll det tillåtna målet specifikt för programmet du försöker nå. Att ersätta det med obegränsad vidarebefordran för att få ett orelaterat program att fungera vidgar vägen långt bortom problemet du började med. En mållista registrerar också vad sessionen var till för, vilket hjälper den som granskar den senare. Skriv ner den bredvid kontot du använde.

Skicka ett program genom proxyn

En proxyvetande klient på Pi:n kan då skicka begäran. Prefixet socks5h lämnar över målnamnet till proxyn, så uppslagningen och anslutningen sker båda på laptopsidan, och det matchar det namngivna målet i PermitRemoteOpen:

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

Behåll normal certifikatvalidering och programmets egen autentisering. Proxyn ändrar var TCP-anslutningen upprättas; den gör inte en oautentiserad tjänst säker och förvandlar inte en självsignerad slutpunkt till en betrodd.

Laptopen behöver fortfarande sin egen rutt och resolveråtkomst till både SSH-servern och programmet. Dess SSH-klients trafik måste väljas av den godkända VPN-policyn, och ett split-tunnel-undantag kan skicka den trafiken en annan väg än den du testade.

Bevisa vägen och stäng den

Bekräfta att lyssnaren finns där du förväntar dig och att bara det avsedda målet svarar:

$ 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/

ExitOnForwardFailure kan bevisa att vidarebefordran upprättades, och kan ändå inte intyga att inloggningen i programmet lyckas längre fram. Testa programmet, inte bara porten. En lyssnare som tar emot och sedan misslyckas med varje begäran betyder oftast att målnamnet eller laptopens rutt är fel, inte att tunneln misslyckades.

Det här arrangemanget bär bara TCP. UDP, ICMP och program som ignorerar proxyinställningar håller sig utanför, och vidarebefordran slutar i samma ögonblick som SSH-sessionen slutar. Stoppa den sessionen när du är klar och ta bort proxyinställningen du lade till i programmet.

För permanent åtkomst, använd i stället nätverksägarens stödda registrering eller en hanterad gateway. En omvänd proxy är fel verktyg för att kringgå en VPN:s enhets- eller resursbegränsningar; använd inom dem är den helt enkelt en auktoriserad programväg med uttryckliga gränser.

Relaterade artiklar