Nei in feroare server-IP neamt de SNAT-regel noch de âlde

De server is nei in nij adres ferhuze, klanten ferbine noch, en neat fan wat se stjoere berikt it ynternet. Dy splitsing is de oanwizing: de harkjende socket en de poarttrochstjoering oerlibben de ferhuzing, dus de tunnel komt omheech, wylst de boarnoersetting dy't op trochstjoerde pakketten tapast wurdt noch altyd in adres neamt dat de host net mear hat. Antwurden op dy oerskreaune pakketten gean nei in masine dy't der net mear is.

Ferbinen en trochstjoeren mislearje op ferskillende plakken

It opbouwen hinget ôf fan it einpunt dat klanten al kenne: it iepenbiere adres, de poarttrochstjoering dêrfoar en de harker binnenyn. Trochstjoerd ferkear hinget ôf fan in twadde beslút dat nommen wurdt neidat it pakket de tunnel yngiet, as de host syn boarne oerskriuwt sadat antwurden de wei werom fine.

In adresferoaring brekt allinnich it twadde beslút, en dêrom wurdt it symptoom lêzen as "ferbûn mar gjin ynternet". It ferklearret ek wêrom't de gewoane kontrôles oan 'e klantkant sûn lykje: de hânskodding foltôget, de klant krijt in adres, en sels in ping nei it tunneladres fan de server kin antwurdzje. Oeren wurde oan 'e klant bestege foar in stoaring dy't oan 'e oare kant wennet, en dêrom is de regeltabel it earste plak om te sjen.

Lês de regel en syn tellers foardat jo bewurkje

List de oersettingsregels mei tellers op en fergelykje de konfigurearre boarne mei de adressen dy't de host echt hat. In regel dy't nei in dea adres oerskreaun is, lit meastentiids ferkear op 'e yngong sjen, omdat pakketten him berikke en oerset wurde, en neat op 'e weromwei.

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

Kontrolearje trije fjilden wylst jo dêr binne: de pool yn 'e boarne-oerienkomst, de útgongynterface as de regel ien neamt, en de útsluting dy't foarkomt dat ferkear tusken tunnels oerskreaun wurdt. Dy útsluting is maklik te ferliezen by in bewurking, en it ferliezen derfan lit ferkear tusken peers wurkje lykje wylst syn antwurden in frjemde wei nimme.

As de tellers op nul fêst steane, berikke pakketten dizze regel nea en is it adres net it hjoeddeistige probleem. Sjoch nei in konkurrearjende regel earder yn 'e keatling, wat bart as immen in ferfanging tafoeget ynstee fan it orizjineel te bewurkjen. Fergelykje de regelnûmers mei de útfier dy't jo in minút lyn opskreaun hawwe. Oarder is part fan 'e konfiguraasje, net in kosmetysk detail.

Ferfang de boarne, of hâld op ien te neamen

As de host in stabile adres hat, ferfang de regel dan op syn plak ynstee fan in oare ta te foegjen. Ferfanging op regelnûmer hâldt de oarder yn stân dêr't de rest fan 'e keatling fan ôfhinget.

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

As it adres dynamysk tawiisd wurdt, neam dan hielendal gjin boarne en lit de kearn de hjoeddeistige út 'e útgongynterface kieze. Dy fariant oerlibbet de folgjende ferhuzing sûnder bewurking, tsjin 'e priis dat it ferberget hokker adres brûkt waard.

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

Befêstigje dat IPv4-trochstjoering noch oan is fia beheard konfiguraasje, en meitsje de regel dan duorsum mei it eigen meganisme fan 'e distribúsje. In feroaring dy't allinnich yn 'e rinnende kearn dien is, komt werom by de folgjende werstart, meastentiids yn in ûnderhâldsfinsters dat nimmen oan 'e feroaring keppelt.

Twa manieren om de ferfanging ferkeard te dwaan

It oersetten fan 'e pool nei it tunneladres fan 'e server ynstee fan syn LAN-adres stjoert antwurden streekrjocht werom de tunnel yn, dêr't se nei in klant rûte wurde dy't der nea om frege hat. De ferbining rint fêst op in wize dy't op in rûtelus liket, omdat it ien is.

In twadde oersetting boppe de âlde stapelje is de oare flater. De earste oerienkommende regel wint, dus de ferâldere ynfier bliuwt pakketten behanneljen oant er wiske wurdt, en de tellers fan 'e nije regel bliuwe op nul wylst elkenien de ferfanging de skuld jout. Wiskje it duplikaat foardat jo eat nijs tafoegje. Lês de list dan noch ien kear en befêstigje dat krekt ien oersetting by de pool past.

As de tunnel ek IPv6 ferfiert, werhelje dan de hiele beoardieling op 'e oare stack. In IPv6-standertrûte sûnder oersetting en sûnder rûtearre foarheaksel mislearret like stil, en it is maklik te ferjitten omdat alles derboppe identyk liket.

Ynkommende tsjinsten hawwe de tsjinoerstelde oersetting nedich

In tsjinst op in VPN-klant dy't fan bûten berikber wêze moat, hat oersetting fan 'e bestimming nedich, net fan 'e boarne: de iepenbiere poart wurdt nei it tunneladres fan 'e klant oerskreaun foardat er yngiet. It trochstjoerpaad hat dan in útdruklike regel nedich dy't dat ferkear tasteat.

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

Oerset nea de poart dy't de tunnel sels ferfiert, want dy oerskriuwing ûnderbrekt de ferbining dy't de tsjinst berikber hâldt. Hâld de tunnelpoart hielendal bûten de bestimmingsregels. Kontrolearje dêrnei fan beide einen: tellers op 'e nije regel, in koarte opname op it tunneltastel en ien fersyk nei in adres binnenyn de tunnel foardat jo de iepenbiere besykje.