Ná 'n IP-verandering op die bediener noem die SNAT-reël steeds die ou adres

Die bediener het na 'n nuwe adres geskuif, kliënte maak steeds verbinding, en niks wat hulle stuur bereik die internet nie. Daardie skeiding is die leidraad: die luisterende sok en die poortaanstuur het die skuif oorleef, so die tonnel kom op, terwyl die bronomsetting wat op aangestuurde pakkette toegepas word steeds 'n adres noem wat die gasheer nie meer besit nie. Antwoorde op daardie herskrewe pakkette gaan na 'n masjien wat nie meer daar is nie.

Verbinding en aansturing faal op verskillende plekke

Vestiging hang af van die eindpunt wat kliënte reeds ken: die openbare adres, die poortaanstuur daarvoor, en die luisteraar binne. Aangestuurde verkeer hang af van 'n tweede besluit wat geneem word nadat die pakket die tonnel binnegaan, wanneer die gasheer sy bron herskryf sodat antwoorde hulle pad terug kan vind.

'n Adresverandering breek net die tweede besluit, en daarom lees die simptoom as "gekoppel maar geen internet". Dit verduidelik ook waarom die gewone kliëntkant-kontroles gesond lyk: die handdruk voltooi, die kliënt ontvang 'n adres, en 'n ping na die bediener se tonneladres antwoord miskien selfs. Ure word op die kliënt spandeer vir 'n fout wat aan die ander kant woon, en daarom is die reëltabel die eerste plek om te kyk.

Lees die reël en sy tellers voordat jy iets wysig

Lys die omsettingsreëls met tellers en vergelyk die gekonfigureerde bron met die adresse wat die gasheer werklik het. 'n Reël wat na 'n dooie adres herskryf is, wys gewoonlik verkeer op die pad in, want pakkette bereik dit en word omgesit, en niks op die pad terug nie.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

Kontroleer drie velde terwyl jy daar is: die poel in die bronpassing, die uitgangskoppelvlak as die reël een noem, en die uitsluiting wat verhoed dat tonnel-tot-tonnel-verkeer herskryf word. Daardie uitsluiting is maklik om tydens 'n wysiging te verloor, en as jy dit verloor, lyk dit asof eweknie-verkeer werk terwyl sy antwoorde 'n vreemde pad volg.

As die tellers op nul vassteek, bereik pakkette nooit hierdie reël nie en is die adres nie die huidige probleem nie. Soek na 'n mededingende reël vroeër in die ketting, wat gebeur wanneer iemand 'n plaasvervanger byvoeg in plaas daarvan om die oorspronklike te wysig. Vergelyk die reëlnommers met die uitset wat jy 'n minuut gelede neergeskryf het. Orde is deel van die konfigurasie, nie 'n kosmetiese detail nie.

Vervang die bron, of hou op om een te noem

Wanneer die gasheer 'n stabiele adres het, vervang die reël in plek eerder as om nog een by te voeg. Vervanging volgens reëlnommer behou die ordening waarvan die res van die ketting afhang.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

Wanneer die adres dinamies toegewys word, noem geen bron hoegenaamd nie en laat die kern die huidige een uit die uitgangskoppelvlak kies. Daardie variant oorleef die volgende skuif sonder 'n wysiging, ten koste daarvan dat dit wegsteek watter adres gebruik is.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

Bevestig dat IPv4-aansturing steeds deur bestuurde konfigurasie geaktiveer is, en maak die reël dan met die verspreiding se eie meganisme volhoubaar. 'n Wysiging wat net in die lopende kern gemaak is, kom met die volgende herbegin terug, gewoonlik tydens 'n onderhoudsvenster waaraan niemand die verandering koppel nie.

Twee maniere om die vervanging verkeerd te kry

Om die poel na die bediener se tonneladres te vertaal in plaas van sy LAN-adres, stuur antwoorde reguit terug die tonnel in, waar hulle na 'n kliënt gerouteer word wat nooit daarom gevra het nie. Die verbinding stagneer op 'n manier wat soos 'n routeringslus lyk, want dit is een.

Om 'n tweede omsetting bo die ou een te stapel, is die ander fout. Die eerste passende reël wen, so die verouderde inskrywing hou aan om pakkette te hanteer totdat dit uitgevee word, en die nuwe reël se tellers bly op nul terwyl almal die plaasvervanger blameer. Vee die duplikaat uit voordat jy enigiets nuuts byvoeg. Lees dan die lys nog een keer en bevestig dat presies een omsetting by die poel pas.

As die tonnel ook IPv6 dra, herhaal die hele oorsig op die ander stapel. 'n IPv6-verstekroete sonder omsetting en sonder 'n gerouteerde voorvoegsel misluk net so stil, en dit is maklik om te vergeet omdat alles bokant dit identies lyk.

Inkomende dienste het die teenoorgestelde omsetting nodig

'n Diens op 'n VPN-kliënt wat van buite bereikbaar moet wees, het bestemmingsomsetting nodig, nie bronomsetting nie: die openbare poort word na die kliënt se tonneladres herskryf voordat dit binnegaan. Die aanstuurpad het dan 'n eksplisiete reël nodig wat daardie verkeer toelaat.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Moenie ooit die poort vertaal wat die tonnel self dra nie, want daardie herskrywing onderbreek die verbinding wat die diens bereikbaar hou. Hou die tonnelpoort heeltemal uit die bestemmingsreëls. Verifieer daarna van beide kante: tellers op die nuwe reël, 'n kort opname op die tonneltoestel, en een versoek na 'n adres binne die tonnel voordat jy die openbare een probeer.