Pakeitus serverio IP, SNAT taisyklė vis dar nurodo senąjį

Serveris persikėlė į naują adresą, klientai vis dar jungiasi, ir niekas, ką jie siunčia, nepasiekia interneto. Būtent šis atskyrimas yra užuomina: klausantis lizdas ir prievado persiuntimas išgyveno perkėlimą, todėl tunelis pakyla, o persiųstiems paketams taikomas šaltinio vertimas vis dar nurodo adresą, kurio mazgas nebeturi. Atsakymai į tuos perrašytus paketus keliauja į mašiną, kurios nebėra.

Prisijungimas ir persiuntimas žlunga skirtingose vietose

Sujungimas priklauso nuo galinio taško, kurį klientai jau žino: viešo adreso, priešais jį esančio prievado persiuntimo ir viduje esančio klausytojo. Persiųstas srautas priklauso nuo antro sprendimo, priimamo po to, kai paketas patenka į tunelį, kai mazgas perrašo savo šaltinį, kad atsakymai rastų kelią atgal.

Adreso pakeitimas sugriauna tik antrą sprendimą, todėl simptomas skaitomas kaip "prisijungta, bet interneto nėra". Tai paaiškina ir tai, kodėl įprasti kliento pusės patikrinimai atrodo sveiki: rankos paspaudimas baigiasi, klientas gauna adresą, o ping į serverio tunelio adresą gali net atsakyti. Valandos eikvojamos kliente dėl gedimo, kuris gyvena kitoje pusėje, todėl taisyklių lentelė yra pirmoji vieta, kur reikia žiūrėti.

Prieš redaguodami perskaitykite taisyklę ir jos skaitiklius

Išvardykite vertimo taisykles su skaitikliais ir palyginkite sukonfigūruotą šaltinį su adresais, kuriuos mazgas iš tikrųjų turi. Į negyvą adresą perrašyta taisyklė paprastai rodo srautą įėjimo kelyje, nes paketai ją pasiekia ir yra išverčiami, o grįžimo kelyje nieko.

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

Kol ten esate, patikrinkite tris laukus: baseiną šaltinio atitikime, išėjimo sąsają, jei taisyklė ją nurodo, ir išimtį, kuri neleidžia perrašyti srauto tarp tunelių. Šią išimtį lengva pamesti redaguojant, o ją pametus srautas tarp partnerių atrodo veikiantis, nors jo atsakymai eina keistu keliu.

Jei skaitikliai stringa ties nuliu, paketai niekada nepasiekia šios taisyklės, ir adresas nėra dabartinė problema. Ieškokite konkuruojančios taisyklės anksčiau grandinėje, kas nutinka, kai kas nors prideda pakaitalą, o ne redaguoja originalą. Palyginkite taisyklių numerius su išvestimi, kurią užsirašėte prieš minutę. Tvarka yra konfigūracijos dalis, o ne kosmetinė smulkmena.

Pakeiskite šaltinį arba nustokite jį nurodyti

Kai mazgas turi stabilų adresą, pakeiskite taisyklę vietoje, o ne pridėkite dar vieną. Keitimas pagal taisyklės numerį išsaugo tvarką, nuo kurios priklauso likusi grandinės dalis.

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

Kai adresas priskiriamas dinamiškai, visai nenurodykite šaltinio ir leiskite branduoliui pasirinkti dabartinį iš išėjimo sąsajos. Šis variantas išgyvena kitą perkėlimą be redagavimo, už tai, kad paslepia, kuris adresas buvo naudojamas.

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

Patvirtinkite, kad IPv4 persiuntimas vis dar įjungtas per valdomą konfigūraciją, tada padarykite taisyklę ilgalaikę pačios distribucijos mechanizmu. Pakeitimas, padarytas tik veikiančiame branduolyje, grįžta per kitą paleidimą iš naujo, paprastai techninės priežiūros lange, kurio niekas nesusieja su pakeitimu.

Du būdai pakaitalą padaryti neteisingai

Vertimas baseiną į serverio tunelio adresą, o ne į jo LAN adresą, siunčia atsakymus tiesiai atgal į tunelį, kur jie maršrutizuojami link kliento, kuris jų niekada neprašė. Ryšys sustoja taip, kad atrodo kaip maršrutizavimo kilpa, nes ja ir yra.

Antro vertimo sukrovimas ant senojo yra kita klaida. Laimi pirmoji atitinkanti taisyklė, todėl pasenęs įrašas toliau apdoroja paketus, kol bus ištrintas, o naujos taisyklės skaitikliai lieka nuliuose, kol visi kaltina pakaitalą. Ištrinkite dublikatą prieš ką nors nauja pridėdami. Tada dar kartą perskaitykite sąrašą ir patvirtinkite, kad baseiną atitinka lygiai vienas vertimas.

Jei tunelis taip pat perduoda IPv6, pakartokite visą apžvalgą kitame rietuvoje. IPv6 numatytasis maršrutas be vertimo ir be maršrutizuoto prefikso žlunga taip pat tyliai, ir tai lengva pamiršti, nes viskas virš jo atrodo identiškai.

Įeinančioms paslaugoms reikia priešingo vertimo

Paslaugai VPN kliente, kuri turi būti pasiekiama iš išorės, reikia paskirties vertimo, o ne šaltinio: viešas prievadas perrašomas į kliento tunelio adresą prieš įeinant. Tada persiuntimo keliui reikia aiškios taisyklės, leidžiančios tą srautą.

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

Niekada neverskite prievado, kuris perduoda patį tunelį, nes tas perrašymas nutraukia ryšį, kuris palaiko paslaugą pasiekiamą. Laikykite tunelio prievadą visiškai už paskirties taisyklių. Galiausiai patikrinkite iš abiejų galų: skaitiklius naujoje taisyklėje, trumpą įrašą tunelio įrenginyje ir vieną užklausą į adresą tunelio viduje prieš bandydami viešąjį.