Post ŝanĝo de la IP de la servilo, la SNAT-regulo ankoraŭ nomas la malnovan

La servilo translokiĝis al nova adreso, la klientoj ankoraŭ konektiĝas, kaj nenio, kion ili sendas, atingas la interreton. Tiu divido estas la indico: la aŭskultanta ingo kaj la pordoado travivis la translokiĝon, do la tunelo leviĝas, dum la fonta traduko aplikata al plusenditaj paketoj ankoraŭ nomas adreson, kiun la gastiganto ne plu posedas. Respondoj al tiuj reskribitaj paketoj iras al maŝino, kiu ne plu ekzistas.

Konektiĝo kaj plusendado malsukcesas en malsamaj lokoj

La starigo dependas de la finpunkto, kiun la klientoj jam konas: la publika adreso, la pordoado antaŭ ĝi kaj la aŭskultanto interne. La plusendita trafiko dependas de dua decido farita post kiam la paketo eniras la tunelon, kiam la gastiganto reskribas sian fonton por ke la respondoj trovu la vojon reen.

Adresa ŝanĝo rompas nur la duan decidon, kaj tial la simptomo legeblas kiel "konektita sed sen interreto". Ĝi ankaŭ klarigas, kial la kutimaj kontroloj ĉe la klienta flanko aspektas sanaj: la manpremo finiĝas, la kliento ricevas adreson, kaj eĉ ping al la tunela adreso de la servilo povas respondi. Horoj estas elspezataj ĉe la kliento pro misfunkcio, kiu loĝas sur la alia flanko, tial la regula tabelo estas la unua loko por rigardi.

Legi la regulon kaj ĝiajn nombrilojn antaŭ redakti

Listigu la tradukajn regulojn kun nombriloj kaj komparu la agorditan fonton kun la adresoj, kiujn la gastiganto efektive posedas. Regulo reskribita al morta adreso kutime montras trafikon en la enira vojo, ĉar paketoj atingas ĝin kaj tradukiĝas, kaj nenion en la revena vojo.

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

Kontrolu tri kampojn dum vi estas tie: la adresaron en la fonta kongruo, la elirinterfacon se la regulo nomas unu, kaj la ekskludon, kiu malhelpas reskribi trafikon inter tuneloj. Tiu ekskludo facile perdiĝas dum redakto, kaj perdi ĝin igas la trafikon inter samtavolanoj aspekti funkcia, dum ĝiaj respondoj sekvas strangan vojon.

Se la nombriloj restas ĉe nulo, la paketoj neniam atingas ĉi tiun regulon kaj la adreso ne estas la nuna problemo. Serĉu konkurencan regulon pli frue en la ĉeno, kio okazas kiam iu aldonas anstataŭaĵon anstataŭ redakti la originalon. Komparu la regulnumerojn kun la eligo, kiun vi notis antaŭ unu minuto. Ordo estas parto de la agordo, ne kosmetika detalo.

Anstataŭigu la fonton, aŭ ĉesu nomi unu

Kiam la gastiganto havas stabilan adreson, anstataŭigu la regulon surloke anstataŭ aldoni alian. Anstataŭigo laŭ regula numero konservas la ordon, de kiu dependas la resto de la ĉeno.

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

Kiam la adreso estas asignata dinamike, nomu neniun fonton kaj lasu la kernon elekti la nunan el la elirinterfaco. Tiu varianto travivas la sekvan translokiĝon sen redakto, je la kosto kaŝi, kiun adreson oni uzis.

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

Konfirmu, ke IPv4-plusendado ankoraŭ estas ŝaltita per administrata agordo, poste faru la regulon daŭra per la propra mekanismo de la distribuo. Ŝanĝo farita nur en la kuranta kerno revenas ĉe la sekva restarto, kutime dum bontenada fenestro, kiun neniu ligas al la ŝanĝo.

Du manieroj malbone fari la anstataŭigon

Traduki la adresaron al la tunela adreso de la servilo anstataŭ al ĝia LAN-adreso sendas respondojn rekte reen en la tunelon, kie ili estas itinerigitaj al kliento, kiu neniam petis ilin. La konekto haltas tiel, ke ĝi aspektas kiel itinera buklo, ĉar ĝi estas buklo.

Stakigi duan tradukon super la malnova estas la alia eraro. La unua kongrua regulo venkas, do la kaduka enskribo daŭre prilaboras paketojn ĝis ĝi estas forigita, kaj la nombriloj de la nova regulo restas ĉe nulo, dum ĉiuj kulpigas la anstataŭaĵon. Forigu la duplikaton antaŭ ol aldoni ion novan. Poste legu la liston ankoraŭfoje kaj konfirmu, ke ĝuste unu traduko kongruas kun la adresaro.

Se la tunelo ankaŭ portas IPv6, ripetu la tutan revizion sur la alia stako. IPv6-defaŭlta itinero sen traduko kaj sen itinerigita prefikso malsukcesas same silente, kaj facile forgesiĝas, ĉar ĉio super ĝi aspektas identa.

Envenantaj servoj bezonas la kontraŭan tradukon

Servo sur VPN-kliento, kiu devas esti atingebla de ekstere, bezonas cellokan tradukon, ne fontan: la publika pordo reskribiĝas al la tunela adreso de la kliento antaŭ ol ĝi eniras. La plusenda vojo tiam bezonas eksplicitan regulon, kiu permesas tiun trafikon.

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

Neniam traduku la pordon, kiu portas la tunelon mem, ĉar tiu reskribo interrompas la konekton, kiu tenas la servon atingebla. Tenu la tunelan pordon tute ekster la cellokaj reguloj. Fine kontrolu de ambaŭ flankoj: nombriloj sur la nova regulo, mallonga kapto sur la tunela aparato kaj unu peto al adreso ene de la tunelo antaŭ ol provi la publikan.