Moet je SNAT toepassen op een port forward naar een VPN-subnet?

Een poort doorsturen naar een host achter de eigen VPN-client van de router mislukt op een manier die op een firewallprobleem lijkt, omdat het verzoek duidelijk aankomt. De dienst logt een verbinding, de client wacht en er komt niets terug. De bestemmingsvertaling deed zijn werk; het retourpakket is het deel dat ontbrak. Eén selectieve bron-NAT-regel op de router lost het op, en het interessante deel is beslissen hoe smal die regel kan zijn.

Waarom het antwoord een andere weg neemt

Een port forward herschrijft waar een pakket naartoe gaat, nooit waar het vandaan kwam. Het adres van de internetclient blijft in het bronveld staan over de hele tunnel, dus de externe dienst ziet een vreemde en antwoordt op de enige manier die hij kent: via zijn eigen standaardgateway. Die gateway is de VPN-concentrator aan de andere kant, die geen route terug heeft naar een willekeurig openbaar adres.

Bekijk een opname op de tunnelinterface en de asymmetrie is duidelijk: verzoekpakketten naar buiten, niets naar binnen. De doorstuurketen stond de stroom toe en de tunnel droeg die, dus de drop gebeurt nadat de externe host al een retourweg heeft gekozen.

Een bronregel die smal genoeg is om te vertrouwen

Maak de router de bron waarop de externe host antwoordt. In deze opstelling is het WAN-adres 203.0.113.24, is de LAN 192.168.88.0/24, is het tunneladres van de router 172.20.5.1, en antwoordt de dienst op 172.20.5.40:8443. De regel hieronder matcht het pakket na de bestemmingsvertaling, daarom noemt hij het vertaalde adres en niet het openbare. Niets erin hangt af van het adres van de client, en dat is precies het punt.

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

Elke overeenkomst in die regel bestaat om het herschrijven lokaal te houden voor één dienst op één tunnel. Verwijder de interface of de poort en je herschrijft meer verkeer dan het probleem vereist, en zo wordt een gerichte oplossing een raadsel voor de volgende persoon.

Wanneer een algemene masquerade de eerlijke keuze is

Als de router veel diensten naar hetzelfde VPN-subnet doorstuurt, wordt een regel per dienst een lijst die niemand onderhoudt. Alles maskeren wat de tunnelinterface verlaat is eenvoudiger en voorspelbaarder, tegen de prijs dat de oorspronkelijke client voor elke host aan de andere kant verborgen wordt. Kies dat wanneer de logs daar niet voor attributie worden gebruikt; houd de smalle regel aan wanneer dat wel gebeurt.

De twee opties falen ook anders. Een ontbrekende smalle regel breekt één dienst; een brede masquerade die te veel matcht kan verkeer dat al werkte stil herschrijven, inclusief de eigen uitgaande verbindingen van de router.

Controleer de tellers voordat je publiceert

Regels die nooit matchen lijken identiek aan regels die werken tot je pakketten telt. Lees de tabel opnieuw met bytetellers voordat een client verbinding maakt, maak dan verbinding vanaf een netwerk dat niet de LAN is en lees hem opnieuw. Twee metingen zijn wat een gok in een feit verandert. Publiceer de doorstuurregel pas nadat de tweede beweegt.

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

Een nulteller op de bronregel na een echte verbinding betekent dat de overeenkomst verkeerd is, meestal omdat de bestemming of poort niet overeenkomt met het pakket na de vertaling. Als de teller stijgt maar de client nog steeds een time-out krijgt, is de retourweg gerepareerd en laat iets anders het antwoord vallen, dus kijk daarna naar het doorstuurbeleid aan de andere kant. Hairpin-toegang vanaf de LAN is een apart probleem en heeft zijn eigen regel nodig, niet een bredere versie van deze.