Moet jy SNAT toepas op 'n poortaanstuur na 'n VPN-subnet?

Die aanstuur van 'n poort na 'n gasheer agter die router se eie VPN-kliënt misluk op 'n manier wat soos 'n firewall-probleem lyk, want die versoek kom duidelik aan. Die diens teken 'n verbinding aan, die kliënt wag, en niks kom terug nie. Bestemmingvertaling het sy werk gedoen; dit is die terugkeerpakket wat weggeraak het. Een selektiewe bron-NAT-reël op die router maak dit reg, en die interessante deel is om te besluit hoe smal daardie reël kan wees.

Waarom die antwoord 'n ander pad vat

'n Poortaanstuur herskryf waar 'n pakkie heen gaan, nooit waar dit vandaan kom nie. Die adres van die internetkliënt bly in die bronveld dwarsdeur die tonnel, so die afgeleë diens sien 'n vreemdeling en antwoord op die enigste manier wat hy ken: deur sy eie verstekpoort. Daardie poort is die VPN-konsentrator aan die oorkant, wat geen roete terug na 'n willekeurige publieke adres het nie.

Kyk na 'n opname op die tonnelkoppelvlak en die asimmetrie is duidelik: versoekpakkies uitwaarts, niks inwaarts nie. Die aanstuurketting het die vloei toegelaat en die tonnel het dit gedra, so die val gebeurt nadat die afgeleë gasheer reeds 'n terugpad gekies het.

'n Bronreël wat smal genoeg is om te vertrou

Maak die router die bron waarop die afgeleë gasheer antwoord. In hierdie uitleg is die WAN-adres 203.0.113.24, die LAN is 192.168.88.0/24, die tonneladres van die router is 172.20.5.1, en die diens antwoord op 172.20.5.40:8443. Die reël hieronder pas by die pakkie ná bestemmingvertaling, en daarom noem dit die vertaalde adres eerder as die publieke een. Niks daarin hang van die kliënt se adres af nie, en dit is juis die 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 passing in daardie reël bestaan om die herskrywing plaaslik tot een diens op een tonnel te hou. Laat die koppelvlak of die poort weg en jy herskryf meer verkeer as wat die probleem vereis, en dit is hoe 'n gerigte oplossing 'n raaisel vir die volgende persoon word.

Wanneer 'n algemene masquerade die eerlike keuse is

As die router baie dienste na dieselfde VPN-subnet aanstuur, word 'n reël per diens 'n lys wat niemand onderhou nie. Om alles te masquerade wat die tonnelkoppelvlak verlaat, is eenvoudiger en voorspelbaar, teen die koste daarvan dat die oorspronklike kliënt vir elke gasheer aan die oorkant weggesteek word. Kies dit wanneer die logboeke daar nie vir toeskrywing gebruik word nie; hou die smal reël wanneer dit wel gebruik word.

Die twee opsies faal ook anders. 'n Ontbrekende smal reël breek een diens; 'n breë masquerade wat te veel pas, kan verkeer stilweg herskryf wat reeds gewerk het, insluitend die router se eie uitwaartse verbindings.

Kontroleer die tellers voordat jy publiseer

Reëls wat nooit pas nie, lyk identies aan reëls wat werk totdat jy pakkies tel. Lees die tabel terug met bytetellers voordat enige kliënt konekteer, konekteer dan vanaf 'n netwerk wat nie die LAN is nie en lees dit weer. Twee lesings is wat 'n vermoede in 'n feit verander. Publiseer die aanstuur eers nadat die tweede een beweeg.

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

'n Nul-teller op die bronreël ná 'n werklike verbinding beteken die passing is verkeerd, gewoonlik omdat die bestemming of poort nie by die pakkie ná vertaling pas nie. As die teller klim maar die kliënt nog steeds tyd uit, is die terugpad reggemaak en iets anders laat die antwoord val, so kyk volgende na die aanstuurbeleid aan die oorkant. Haarspeldtoegang van binne die LAN is 'n aparte probleem en het sy eie reël nodig, nie 'n wyer weergawe van hierdie een nie.