SSH lokale doorstuur naar een bestaande HTTP-proxy: twee loopbackadressen

Je goedgekeurde proxy draait op een spronghost waar hij alleen op loopback luistert, dus niets buiten die machine kan hem bereiken. Je hebt geen VPN of nieuwe proxy nodig; je hebt één poort van die machine nodig, overgebracht naar één poort van jou. Een lokale doorstuur doet precies dat, en het kost één opdracht plus één instelling van de toepassing. De verwarring komt meestal doordat je door elkaar haalt welk loopbackadres bij welke machine hoort.

Bepaal of er al een vaste proxy is

Deze techniek stuurt een dienst door die al draait. Als de externe host alleen een SSH-daemon heeft en geen proxy, maakt geen enkele hoeveelheid doorsturen er een, en de verbinding wordt vanaf de externe kant geweigerd. Controleer of de proxy gebonden is, welke poort hij gebruikt en of hij op 127.0.0.1 of op een specifiek interfaceadres luistert, want dat adres is het doel dat de doorstuur moet richten.

Als je dit eerst controleert, bespaar je jezelf het debuggen van een tunnel die nooit met iets verbonden was.

Bouw de doorstuur en lees de opdracht

De vorm die je wilt, bindt een loopback-poort op je laptop en verbindt die, vanaf de serverkant, met het adres van de proxy zoals de server dat ziet.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N onderdrukt een externe opdracht en -T onderdrukt de termios-toewijzing, want je wilt een tunnel en geen shell. Het eerste loopbackadres is waar de laptop luistert; het tweede wordt door de SSH-server opgelost, dus 127.0.0.1 betekent daar de proxy op die machine. ExitOnForwardFailure laat de opdracht luid falen als de lokale poort al bezet is, in plaats van een sessie te starten die niets doorstuurt. Schrijf het doeladres zoals de server het oplost, want een naam die alleen jouw laptop kan oplossen, zal aan de andere kant falen.

Het eigen beleid van de server geldt voordat iets hiervan werkt. AllowTcpForwarding moet het toestaan, en PermitOpen kan beperken welke bestemmingen en poorten een sessie mag bereiken, dus een doorstuur die de client accepteert, kan alsnog door de server geweigerd worden. De weigering verschijnt als een doorstuur- of kanaalfout bij de client, en dat bericht lezen is sneller dan de opdracht aanpassen.

Richt één toepassing op de doorstuur

Stel de toepassing in om een HTTP-proxy op http://127.0.0.1:13128 te gebruiken, met inloggegevens als de externe proxy die vereist. Behoud de eigen certificaatverificatie van de toepassing voor HTTPS-bestemmingen, want de proxytunnel vervangt die niet. Dit is een vaste doorstuur van één dienst, dus de toepassing moet over een proxy worden verteld in plaats van er zelf een te laten ontdekken.

Een snelle controle voordat je iets permanents instelt: curl -x http://127.0.0.1:13128 -I https://example.com, wat de HTTP CONNECT-methode test die de proxy moet ondersteunen.

Houd de autoriteit waar die was

De externe proxy beslist nog steeds welke bestemmingen en methoden hij toestaat, en een SSH-login hoort niet stilzwijgend elk account een algemene webrelay te geven. Binden aan 127.0.0.1 op de laptop voorkomt dat de poort op je lokale netwerk wordt gepubliceerd, en het maakt de poort niet privé voor andere processen op dezelfde machine. Die binding vervangen door een wildcardadres om de proxy te delen, is hoe een onbeheerde open relay ontstaat.

Het SSH-transport beschermt de sprong naar de server. Voorbij dat punt opent de proxy zijn eigen verbinding, dus een gewone HTTP-aanvraag naar een bestemming blijft gewoon voorbij de server, ook al was het eerste segment versleuteld.

Controleer beide uiteinden en ruim dan op

Lokale tunnelopzet en succes van de externe dienst zijn verschillende resultaten, en de exitstatus van de opdracht vertelt je alleen over het eerste. Controleer met ss -ltn of de luisteraar bestaat, en doe dan een toegestane aanvraag van de toepassing en een aanvraag die de proxy zou moeten weigeren. Als beide zich gedragen zoals verwacht, is het pad echt; als de tunnel actief is en elke aanvraag faalt, weigert de proxy of bereikt hij de bestemming niet.

Als je klaar bent, stop je het SSH-proces dat hem bezit, verwijder je de proxyinstelling uit de toepassing en bevestig je dat de lokale poort weg is in plaats van een luisteraar achter te laten die de taak overleeft.