Nå en tjänst på en VPN-klient: omvänd tunnel eller DNAT

Även en bärbar dator bakom leverantörens NAT kan betjäna en kollega, så länge VPN-servern fungerar som mötesplats. Två mekanismer leder dit: klienten ringer ut och ber servern hålla en lyssnande port, eller servern publicerar en port och översätter den in i tunneln. Båda löser samma nåbarhetsproblem och beter sig olika vid fel, övervakning och loggning. Tre villkor avgör vilken som hör hemma i din uppsättning.

Två former, en mötesplats

I den första formen öppnar klienten en SSH-session utåt och ber servern lyssna på en vald port, och skickar varje anslutning tillbaka genom den sessionen. På servern vidarebefordras ingenting och ingen paketöversättning sker, så de enda kraven är ett SSH-konto, en tillåten vidarebefordran och en brandväggsregel för porten. Tjänsten förblir bunden till loopback på klienten, vilket vanligtvis är det man vill.

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

I den andra formen äger servern den publika porten och skriver om varje anslutning mot klientens tunneladress. Det kräver IP-vidarebefordran aktiverad, en destinationsöversättning på väg in och en källöversättning på väg ut, och det fortsätter att fungera när ingen SSH-session finns. Porten tillhör servern och inte en session, och det är den egenskapen som avgör de flesta verkliga fall.

Ingen av formerna är säkrare av naturen. Båda exponerar till slut en tjänsteport för alla som kan nå serverns publika adress, och båda är fortfarande beroende av tjänstens egen autentisering.

Villkor ett: måste porten leva längre än sessionen

En omvänd vidarebefordran lever precis så länge som SSH-sessionen som skapade den. När länken faller försvinner lyssnaren och kollegan ser en avvisad anslutning i stället för en långsam väg. Övervakning av kommandot med en systemd-enhet och en omstartsprincip löser det, och ExitOnForwardFailure=yes gör en misslyckad bindning omedelbart synlig i stället för att lämna en session utan vidarebefordran.

En översatt port överlever omstarter om reglerna sparas, men den beror på att klienten behåller samma tunneladress. En dynamisk pool som ger den bärbara datorn en annan adress efter återanslutning pekar tyst regeln mot ingenting. Reservera tunneladressen först, skriv sedan regeln, och behandla de två som en enda ändring.

Om tjänsten måste svara klockan tre på natten utan att någon tittar, är formen med serverns publicerade port den med färst rörliga delar, eftersom den enda processen som måste hållas igång är själva tunneln.

Villkor två: vem äger brandväggen och loggarna

Den omvända formen håller all policy på två ställen. sshd avgör via AllowTcpForwarding om fjärrvidaresändningar över huvud taget är tillåtna, och GatewayPorts avgör om lyssnaren binder till loopback eller till varje adress. Med standardvärdet no kan en kollega utanför servern inte nå porten trots att vidarebefordran lyckades, och det ser ut som en trasig tunnel när det i själva verket är en bindningsadress.

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

Den översatta formen kräver vidarebefordran aktiverad och två regler, och den andra regeln är där de flesta recept går fel. Att begränsa källöversättningen till conntrack-tillståndet DNAT innebär att bara de anslutningar som destinationsregeln skapade skrivs om, i stället för varje paket servern skickar in i tunneln.

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

Den omskrivningen förstör också tillskrivningen. Efteråt ser klienten varje anropare som serverns tunneladress, vilket kollapsar varje hastighetsgräns per adress i en enda hink och döljer vem som skickade vad. Om tillskrivning spelar roll, avsluta anslutningen på servern eller behåll tillståndsbeslutet där och skicka en identitet i en header som tjänsten litar på. Valet mellan dessa två rättelser beror på om tjänsten över huvud taget läser en proxy-header.

Villkor tre: en port eller många, och vem äger namnet

En enda tjänst på en enda port är fallet där omvänd vidarebefordran vinner på ansträngning. Du behöver ett kommando, ett konto och en brandväggsregel, och städningen är att döda sessionen. Flera tjänster på samma publika adress pressar dig mot formen med serverns publicerade port, eftersom varje omvänd vidarebefordran behöver sin egen serverport och mängden växer med varje tjänst.

Namn gör det mer komplicerat. En omvänd vidarebefordran kan sitta bakom en TCP-proxy som routar efter SNI, medan en översatt port vanligtvis är en port per tjänst. Om tjänsten avslutar TLS själv och behöver det ursprungliga värdnamnet, bevarar proxy-ansatsen det, och DNAT-ansatsen bevarar det bara om tjänsten accepterar det namnet på den porten.

Skriv ned vilket av de tre villkoren som avgjorde formen. Annars kommer nästa person som lägger till en andra tjänst att öppna samma jämförelse igen med mindre kontext.

Bestäm, och testa sedan utifrån

Testa vägen från ett nätverk som inte har någon rutt till den bärbara datorn, och följ räknarna på servern medan begäran körs. Att testa från servern mot dess egen publika adress bevisar ingenting här, eftersom paketet skapas lokalt och aldrig når den inkommande översättningskroken, så testet kan passera medan den verkliga vägen är trasig.

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

Räknare som står stilla betyder att paketet aldrig nådde regeln, vilket pekar på leverantören eller värdens brandvägg. Räknare som rör sig medan tjänsten vägrar pekar på klientens egen brandvägg eller adressen som tjänsten lyssnar på. En tunnel som bär paketet men inte returnerar något är ett rutt- eller returvägsproblem, och ingen av dessa tre utgångar bör felsökas genom att redigera klientadaptern. Skriv ned vilken räknare som flyttade sig innan du ändrar något, eftersom nästa test behöver den baslinjen.

När formen fungerar, registrera porten, ägaren och övervakningsmetoden bredvid tunnelkonfigurationen. En nåbarhetsrättelse som bara finns i någons skalhistorik är en omstart bort från en upprepad incident.