Bör du använda SNAT på en portvidarebefordran till ett VPN-subnät?

Att vidarebefordra en port till en värd som ligger bakom routerns egen VPN-klient misslyckas på ett sätt som ser ut som ett brandväggsproblem, eftersom begäran tydligt kommer fram. Tjänsten loggar en anslutning, klienten väntar och ingenting kommer tillbaka. Destinationsöversättningen gjorde sitt jobb; returpaketet är den del som försvann. En enda selektiv käll-NAT-regel på routern åtgärdar det, och det intressanta är att avgöra hur smal den regeln kan vara.

Varför svaret tar en annan väg

En portvidarebefordran skriver om vart ett paket är på väg, aldrig varifrån det kom. Internetklientens adress stannar i källfältet hela vägen genom tunneln, så den fjärran tjänsten ser en främling och svarar på det enda sätt den känner till: via sin egen standardgateway. Den gatewayen är VPN-koncentratorn på andra sidan, som inte har någon väg tillbaka till en godtycklig offentlig adress.

Titta på en inspelning på tunnelgränssnittet och asymmetrin är uppenbar: begärandepaket ut, ingenting in. Vidarebefordringskedjan tillät flödet och tunneln bar det, så släppet sker efter att fjärrvärden redan har valt en returväg.

En källregel som är smal nog att lita på

Gör routern till den källa som fjärrvärden svarar på. I den här layouten är WAN-adressen 203.0.113.24, LAN är 192.168.88.0/24, routerns tunneladress är 172.20.5.1, och tjänsten svarar på 172.20.5.40:8443. Regeln nedan matchar paketet efter destinationsöversättningen, därför namnger den den översatta adressen och inte den offentliga. Ingenting i den beror på klientens adress, och det är precis poängen.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Varje träff i den raden finns för att hålla omskrivningen lokal för en tjänst på en tunnel. Ta bort gränssnittet eller porten och du skriver om mer trafik än problemet kräver, och det är så en riktad rättelse blir ett mysterium för nästa person.

När en generell maskering är det ärliga valet

Om routern vidarebefordrar många tjänster till samma VPN-subnät blir en regel per tjänst en lista som ingen underhåller. Att maskera allt som lämnar tunnelgränssnittet är enklare och förutsägbart, till priset av att den ursprungliga klienten döljs för varje värd på andra sidan. Välj det när loggarna där borta inte används för attribution; behåll den smala regeln när de används.

De två alternativen misslyckas också olika. En saknad smal regel bryter en tjänst; en bred maskering som matchar för mycket kan tyst skriva om trafik som redan fungerade, inklusive routerns egna utgående anslutningar.

Kontrollera räknarna innan du publicerar

Regler som aldrig matchar ser identiska ut med regler som fungerar tills du räknar paketen. Läs tabellen igen med byteräknare innan någon klient ansluter, anslut sedan från ett nätverk som inte är LAN och läs den igen. Två avläsningar är det som förvandlar en gissning till ett faktum. Publicera vidarebefordran först efter att den andra rör sig.

iptables -t nat -L POSTROUTING -v -n --line-numbers

En nollräknare på källregeln efter en riktig anslutning betyder att matchningen är fel, oftast för att destinationen eller porten inte matchar paketet efter översättningen. Om räknaren stiger men klienten fortfarande får timeout är returvägen reparerad och något annat släpper svaret, så titta sedan på vidarebefordringspolicyn på andra sidan. Hårnålsåtkomst inifrån LAN är ett separat problem och behöver sin egen regel, inte en bredare version av den här.