Pärast serveri IP muutumist nimetab SNAT-reegel ikka vana

Server kolis uuele aadressile, kliendid ühenduvad endiselt ja miski, mida nad saadavad, ei jõua internetti. Just see lõhe on vihje: kuulav pesa ja pordisuunamine elasid kolimise üle, seega tunnel tõuseb, samal ajal kui edastatud pakettidele rakendatav lähtetõlge nimetab ikka aadressi, mida host enam ei oma. Vastused nendele ümberkirjutatud pakettidele lähevad masinale, mida enam ei ole.

Ühendamine ja edastamine ebaõnnestuvad eri kohtades

Ülesehitus sõltub lõpp-punktist, mida kliendid juba teavad: avalik aadress, selle ees olev pordisuunamine ja sees olev kuulaja. Edastatud liiklus sõltub teisest otsusest, mis tehakse pärast seda, kui pakett tunnelisse siseneb, kui host kirjutab oma lähte ümber, et vastused leiaksid tee tagasi.

Aadressi muutus rikub ainult teise otsuse ja seetõttu loetakse sümptomit kui "ühendatud, aga internetti pole". See seletab ka, miks tavalised kliendipoolsed kontrollid näivad terved: käepigistus lõpeb, klient saab aadressi ja isegi ping serveri tunneli aadressile võib vastata. Tunde kulub kliendil vea peale, mis elab teisel poolel, mistõttu on reeglite tabel esimene koht, kuhu vaadata.

Enne muutmist loe reeglit ja selle loendureid

Loetle tõlkereeglid loenduritega ja võrdle seadistatud lähet aadressidega, mida host tegelikult hoiab. Surnud aadressile ümber kirjutatud reegel näitab tavaliselt liiklust sissepoole, sest paketid jõuavad selleni ja tõlgitakse, ning tagasiteel mitte midagi.

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

Kontrolli kohapeal kolme välja: lähtekattes olevat aadressikogumit, väljumisliidest, kui reegel selle nimetab, ja erandit, mis hoiab tunnelitevahelise liikluse ümberkirjutamisest. Seda erandit on muutmise käigus lihtne kaotada ja selle kaotamine paneb võrdsete vahelise liikluse töötama, samal ajal kui selle vastused lähevad kummalist teed.

Kui loendurid on nullis, ei jõua paketid kunagi selle reeglini ja aadress ei ole praegune probleem. Otsi konkureerivat reeglit ahelas varem, mis juhtub siis, kui keegi lisab asenduse selle asemel, et originaali muuta. Võrdle reeglinumbreid väljundiga, mille märkisid üles minut tagasi. Järjekord on seadistuse osa, mitte kosmeetiline detail.

Asenda lähe või lõpeta selle nimetamine

Kui hostil on püsiv aadress, asenda reegel kohapeal, selle asemel et lisada veel üks. Reeglinumbri järgi asendamine hoiab järjekorra, millest ahela ülejäänud osa sõltub.

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

Kui aadress määratakse dünaamiliselt, ära nimetagi lähet ja lase tuumal valida praegune väljumisliidesest. See variant elab järgmise kolimise üle ilma muutmiseta, hinnaga, et varjab, millist aadressi kasutati.

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

Kinnita, et IPv4 edastamine on endiselt haldatud seadistuse kaudu lubatud, seejärel tee reegel püsivaks distributsiooni enda mehhanismiga. Ainult jooksvas tuumas tehtud muudatus tuleb tagasi järgmise taaskäivitusega, tavaliselt hooldusaknas, mida keegi muudatusega ei seosta.

Kaks viisi, kuidas asendus valesti teha

Aadressikogumi tõlkimine serveri tunneli aadressile selle LAN-aadressi asemel saadab vastused otse tagasi tunnelisse, kus need marsruuditakse kliendile, kes neid kunagi ei küsinud. Ühendus takerdub nii, et see näeb välja nagu marsruutimistsükkel, sest see ongi tsükkel.

Teise tõlke ladumine vana peale on teine viga. Võidab esimene sobiv reegel, seega vananenud kirje käsitleb pakette edasi, kuni see kustutatakse, ja uue reegli loendurid jäävad nulli, samal ajal kui kõik süüdistavad asendust. Kustuta duplikaat enne, kui midagi uut lisad. Seejärel loe nimekirja veel kord ja kinnita, et kogumiga sobib täpselt üks tõlge.

Kui tunnel kannab ka IPv6, korda kogu ülevaatust teisel virnal. IPv6 vaikimisi marsruut ilma tõlke ja marsruuditud prefiksita ebaõnnestub sama vaikselt ja seda on lihtne unustada, sest kõik selle kohal näeb identne välja.

Sisenevad teenused vajavad vastupidist tõlget

VPN-kliendi teenus, mis peab olema väljastpoolt kättesaadav, vajab sihtkoha tõlget, mitte lähtetõlget: avalik port kirjutatakse enne sisenemist ümber kliendi tunneli aadressile. Seejärel vajab edastustee selgesõnalist reeglit, mis seda liiklust lubab.

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

Ära kunagi tõlgi porti, mis kannab tunnelit ennast, sest see ümberkirjutus katkestab ühenduse, mis hoiab teenuse kättesaadavana. Hoia tunneliport täielikult sihtkoha reeglitest väljas. Lõpuks kontrolli mõlemast otsast: loendurid uuel reeglil, lühike salvestus tunneliseadmel ja üks päring tunnelisisesele aadressile enne, kui proovid avalikku.