Geef een externe Pi een SOCKS-proxy via je SSH-client

Je gaat ervan uit dat een SOCKS-proxy moet draaien waar de netwerktoegang al bestaat. OpenSSH kan de listener heel ergens anders neerzetten. Een externe dynamische doorsturing opent de SOCKS-poort op een externe host en laat elke verbinding ontstaan bij je lokale SSH-client, die het goedgekeurde VPN-pad van je laptop draagt. De Pi krijgt een begrensde proxy; hij erft je tunnel of je rechten niet.

De listener en de kant waar de verbinding begint kunnen verschillen

Een gewone ssh -D 1080 draait de listener op je eigen machine en stuurt verbindingen van daaruit. Een externe dynamische doorsturing keert dat om: de listener verschijnt op de externe host, en elke verbinding die hij accepteert wordt vanaf de lokale kant geopend. De handleiding van de OpenSSH-client documenteert -R zonder vaste bestemming precies als deze SOCKS4/5-opzet.

Een ondersteund commando vanaf de laptop ziet er zo uit, waarbij het account, de hosts en de poort als plaatsaanduidingen gelden:

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

Drie details doen daar nuttig werk. -S none houdt de sessie weg van een gedeelde control-master, ExitOnForwardFailure faalt snel in plaats van je met een halfopen sessie achter te laten, en PermitRemoteOpen beperkt wat de externe listener kan bereiken. Gebruik een geautoriseerd Pi-account en verifieer de hostsleutel voordat je hier iets van toevoegt.

Wat de externe listener echt blootlegt

Controleer het doorsturingsbeleid van de server voordat je op de listener vertrouwt. Met GatewayPorts no blijft de externe doorsturing aan loopback gebonden, en dat is de blootstelling die je wilt. Een server die is ingesteld om jokerteken-doorsturing af te dwingen, publiceert dezelfde poort op elke interface, waardoor een persoonlijke proxy iets wordt dat het lokale netwerk kan bereiken.

Loopback is ook geen grens per gebruiker. Een ander proces op de Pi kan verbinding maken met 127.0.0.1:1080 als het de poort kent, dus de lokale accounts van de Pi en alles wat daarop draait maken deel uit van je toegangsontwerp. Dat is een reden om de lijst met bestemmingen smal te houden, geen reden om de beleidscontrole over te slaan.

Houd de toegestane bestemming specifiek voor de toepassing die je probeert te bereiken. Die vervangen door onbeperkte doorsturing om een ongerelateerd programma te laten werken, verbreedt het pad veel verder dan het probleem waarmee je begon. Een lijst met bestemmingen legt ook vast waarvoor de sessie diende, wat helpt wie hem later controleert. Schrijf hem op naast het account dat je gebruikte.

Stuur één toepassing door de proxy

Een proxybewuste client op de Pi kan dan het verzoek doen. Het voorvoegsel socks5h geeft de bestemmingsnaam aan de proxy, zodat de opzoeking en de verbinding beide aan de laptopkant gebeuren, en het komt overeen met de genoemde bestemming in PermitRemoteOpen:

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

Behoud de normale certificaatvalidatie en de eigen authenticatie van de toepassing. De proxy verandert waar de TCP-verbinding tot stand komt; hij maakt een niet-geauthenticeerde dienst niet veilig en verandert een zelfondertekend eindpunt niet in een vertrouwd eindpunt.

De laptop heeft nog steeds zijn eigen route en resolvertoegang nodig naar zowel de SSH-server als de toepassing. Het verkeer van zijn SSH-client moet door het goedgekeurde VPN-beleid worden geselecteerd, en een split-tunnel-uitzondering kan dat verkeer via een ander pad sturen dan het pad dat je hebt getest.

Bewijs het pad en sluit het

Bevestig dat de listener bestaat waar je hem verwacht en dat alleen de bedoelde bestemming antwoordt:

$ 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 bewijzen dat de doorsturing tot stand is gebracht, en kan nog steeds niet bevestigen dat de aanmelding bij de toepassing stroomafwaarts lukt. Test de toepassing, niet alleen de poort. Een listener die accepteert en daarna elk verzoek laat mislukken, betekent meestal dat de bestemmingsnaam of de route van de laptop fout is, niet dat de tunnel heeft gefaald.

Deze opzet draagt alleen TCP. UDP, ICMP en programma's die proxyinstellingen negeren blijven erbuiten, en de doorsturing eindigt op het moment dat de SSH-sessie eindigt. Stop die sessie als je klaar bent en verwijder de proxyinstelling die je aan de toepassing hebt toegevoegd.

Gebruik voor blijvende toegang in plaats daarvan de ondersteunde inschrijving van de netwerkeigenaar of een beheerde gateway. Een reverse proxy is het verkeerde hulpmiddel om de apparaat- of resourcebeperkingen van een VPN te omzeilen; binnen die beperkingen gebruikt, is het simpelweg één geautoriseerd toepassingspad met uitdrukkelijke grenzen.