SSH lokal vidarebefordran till en befintlig HTTP-proxy: två loopback-adresser
En befintlig proxy på en SSH-värd kan betjäna en applikation via en enda lokal vidarebefordran. Håll de två loopback-adresserna och proxyprotokollet isär.
Din godkända proxy körs på en språngvärd där den bara lyssnar på loopback, så ingenting utanför den maskinen kan nå den. Du behöver ingen VPN eller ny proxy; du behöver en port från den maskinen överförd till en port hos dig. En lokal vidarebefordran gör precis det, och den kräver ett kommando plus en inställning i applikationen. Förvirringen kommer oftast av att man blandar ihop vilken loopback-adress som hör till vilken maskin.
Avgör om det redan finns en fast proxy
Den här tekniken vidarebefordrar en tjänst som redan körs. Om fjärrvärden bara har en SSH-demon och ingen proxy skapar ingen mängd vidarebefordran någon, och anslutningen kommer att avvisas från fjärrsidan. Bekräfta att proxyn är bunden, vilken port den använder och om den lyssnar på 127.0.0.1 eller på en viss gränssnittsadress, eftersom det är den adressen som vidarebefordran måste rikta sig mot.
Bekräftar du detta först slipper du felsöka en tunnel som aldrig var ansluten till något.
Bygg vidarebefordran och läs kommandot
Den form du vill ha binder en loopback-port på din laptop och ansluter den, från serversidan, till proxyns adress så som servern ser den.
ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
-L 127.0.0.1:13128:127.0.0.1:3128 [email protected]-N undertrycker ett fjärrkommando och -T undertrycker termios-tilldelning, eftersom du vill ha en tunnel och inte ett skal. Den första loopback-adressen är där laptopen lyssnar; den andra löses upp av SSH-servern, så 127.0.0.1 där betyder proxyn på den maskinen. ExitOnForwardFailure får kommandot att misslyckas högljutt om den lokala porten redan är upptagen, i stället för att starta en session som inte vidarebefordrar något. Skriv mål-adressen så som servern löser upp den, eftersom ett namn som bara din laptop kan lösa upp kommer att misslyckas på andra sidan.
Serverns egen policy gäller innan något av detta fungerar. AllowTcpForwarding måste tillåta det, och PermitOpen kan begränsa vilka mål och portar en session får nå, så en vidarebefordran som klienten accepterar kan ändå avvisas av servern. Avvisandet visas som ett vidarebefordrings- eller kanalfel på klienten, och att läsa det meddelandet går snabbare än att redigera kommandot.
Rikta en applikation mot vidarebefordran
Konfigurera applikationen att använda en HTTP-proxy på http://127.0.0.1:13128, med inloggningsuppgifter om fjärrproxyn kräver det. Behåll applikationens egen certifikatverifiering för HTTPS-mål, eftersom proxytunneln inte ersätter den. Detta är en fast vidarebefordran av en tjänst, så applikationen måste få veta att det finns en proxy i stället för att lämnas att upptäcka en själv.
En snabb kontroll innan du konfigurerar något permanent: curl -x http://127.0.0.1:13128 -I https://example.com, som övar den HTTP CONNECT-metod som proxyn måste stödja.
Behåll auktoriteten där den var
Fjärrproxyn bestämmer fortfarande vilka mål och metoder den tillåter, och en SSH-inloggning bör inte tyst ge varje konto en allmän webb-relä. Bindning till 127.0.0.1 på laptopen undviker att publicera porten på ditt lokala nät, och det gör inte porten privat från andra processer på samma maskin. Att ersätta den bindningen med en jokerteckenadress för att dela proxyn är hur en ohanterad öppen relä uppstår.
SSH-transporten skyddar språnget till servern. Bortom den punkten öppnar proxyn sin egen anslutning, så en vanlig HTTP-förfrågan till ett mål förblir vanlig bortom servern, även om det första segmentet var krypterat.
Verifiera båda ändarna och städa sedan
Lokal tunneluppsättning och framgång för fjärrtjänsten är olika resultat, och kommandots slutstatus säger dig bara om det första. Kontrollera att lyssnaren finns med ss -ltn, och gör sedan en tillåten applikationsförfrågan och en förfrågan som proxyn borde avvisa. Om båda beter sig som väntat är vägen verklig; om tunneln är uppe och varje förfrågan misslyckas avvisar proxyn eller når inte målet.
När du är klar stoppar du SSH-processen som äger den, tar bort proxyinställningen från applikationen och bekräftar att den lokala porten är borta i stället för att lämna en lyssnare som överlever uppgiften.