Nå en HTTPS-webbplats som bara är tillgänglig via VPN genom en SSH-vidarebefordran

En maskin har redan godkänd VPN-åtkomst, en andra maskin behöver exakt en privat HTTPS-tjänst, och en lokal SSH-vidarebefordran kan överbrygga gapet utan att ge den andra maskinen en tunnel. Vidarebefordran bär en enda TCP-destination i stället för hela nätverket, och just den begränsningen är poängen. Gå igenom de fem stegen nedan i ordning, eftersom varje steg misslyckas av olika skäl och ett senare steg inte kan rädda ett tidigare gap. Om någon förutsättning saknas löser inte den här designen den, och ingen kommandotuning hjälper.

Steg ett: bekräfta de tre förutsättningarna

Tre saker måste redan vara sanna innan något kommando spelar roll. Du behöver tillåtelse att använda den första maskinen som vidarebefordringsvärd, fungerande SSH-åtkomst till den och en serverpolicy som tillåter den avsedda destinationen. Ett SSH-konto skapat för filöverföring kan ha vidarebefordran avstängd, och en server som tillåter vidarebefordran kan ändå begränsa vilka destinationer som är nåbara genom den. Fråga innan du testar, eftersom att använda en kollegas arbetsstation som hoppunkt utan överenskommelse är ett policyproblem, även när kommandot fungerar felfritt.

Två kommandon avgör den tekniska halvan av den listan. Det första bevisar att kontot och nyckeln fungerar utan en interaktiv prompt, och det andra skriver ut den faktiska serverpolicyn i stället för det kommenterade exemplet i konfigurationsfilen.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Steg två: bind en loopback-port och håll sessionen vid liv

På maskinen som kör klientprogrammet, öppna en lokal vidarebefordran till den privata tjänsten. Bind den uttryckligen till loopback så att den inte publiceras på det lokala nätverket, och välj en hög port som ingen lokal tjänst redan håller. Håll sessionen igång medan du arbetar, eftersom att stänga den stänger lyssnaren. ExitOnForwardFailure gör en avvisad bindning eller en upptagen port till ett omedelbart avslut i stället för en session som står kvar utan vidarebefordran, och det är felläget som slösar mest tid.

Den privata anslutningen skapas från hoppvärden, så dess DNS, rutter, VPN-policy och tjänståtkomst måste alla fungera. SSH-sessionen skapar inte nåbarhet som hoppvärden saknar, och den kan inte reparera en rutt som VPN:en aldrig har pushat. Bekräfta lyssnaren där den faktiskt finns i stället för att lita på kommandots tystnad.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Steg tre: behåll HTTPS-namnet när socketen är lokal

Att surfa till https://127.0.0.1:9443/ ändrar TLS-servernamnet och programmets behörighet. Ett certifikat utfärdat för portal.lab.example valideras inte mot en loopback-adress, och felet som uppstår ser ut som ett trasigt certifikat snarare än en vidarebefordringssnabbväg. För ett kommandoradsprov, behåll den riktiga URL:en och ändra bara socketens destination. Det är vad --connect-to gör, och curl-handboken dokumenterar fyrafältsformen som används nedan.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

Namnet stannar i URL:en, i TLS-handskakningen och i Host-huvudet, medan TCP-anslutningen går till den lokala lyssnaren. Utan-proxy-alternativet håller provet på den här vidarebefordran i stället för att låta en konfigurerad HTTP-proxy avskärma det, och att hålla certifikatvalideringen på är det som gör resultatet meningsfullt.

Steg fyra: vet vad en enda vidarebefordran inte kan täcka

En enda TCP-vidarebefordran täcker en destinationsport. En sida som omdirigerar till ett andra värdnamn, laddar resurser från ett värd inuti det privata nätverket eller skickar till en annan port behöver sin egen vidarebefordran, och var och en av dem behöver samma policykontroll som den första. Webbläsarens arbetsflöden lägger till egna krav, eftersom webbläsaren måste få veta att den ska skicka det riktiga namnet till den lokala porten genom en proxykonfiguration eller en lokal mappning. Ett lyckat kommandoradsprov bevisar därför inte att webbläsaren lyckas, även om det bevisar vägen.

UDP, SMB-upptäckt och domäninloggning går inte alls genom en TCP-vidarebefordran. Om det verkliga behovet är allmän nätverksåtkomst är den här designen fel verktyg och en supporterad fjärråtkomstgateway är det rätta.

Steg fem: städa upp och skriv ned det

Stoppa sessionen när provet är klart och bekräfta att lyssnaren är borta. Om den valda porten redan var upptagen, välj en annan oanvänd loopback-port och uppdatera URL:en, testkommandot och anteckningen tillsammans, i stället för att stoppa en orelaterad lokal tjänst för att frigöra numret. Att lämna en vidarebefordran öppen på en bärbar dator gör en diagnos till en ohanterad tjänst.

Skriv ned hoppvärden, den vidarebefordrade destinationen, den lokala porten och vem som godkände arrangemanget. En vidarebefordran som bara finns i någons shell-historik är en omstart från en upprepad utredning, och nästa person vet inte vilken av de tre förutsättningarna som redan är kontrollerad.