Pēc servera IP maiņas SNAT noteikums joprojām nosauc veco

Serveris pārcēlās uz jaunu adresi, klienti joprojām savienojas, un nekas no tā, ko viņi sūta, neaizsniedz internetu. Tieši šī šķirtne ir pavediens: klausošā ligzda un porta pārsūtīšana pārcelšanos pārcieta, tāpēc tunelis ceļas, kamēr pārsūtītajām paketēm piemērotais avota tulkojums joprojām nosauc adresi, kas resursdatoram vairs nepieder. Atbildes uz šīm pārrakstītajām paketēm dodas uz mašīnu, kuras vairs nav.

Savienošanās un pārsūtīšana neizdodas dažādās vietās

Izveide ir atkarīga no galapunkta, ko klienti jau zina: publiskās adreses, porta pārsūtīšanas tās priekšā un klausītāja iekšpusē. Pārsūtītā plūsma ir atkarīga no otra lēmuma, kas pieņemts pēc tam, kad pakete nonāk tunelī, kad resursdators pārraksta savu avotu, lai atbildes atrastu ceļu atpakaļ.

Adreses maiņa salauž tikai otro lēmumu, un tāpēc simptoms tiek lasīts kā "savienots, bet bez interneta". Tas arī izskaidro, kāpēc ierastās pārbaudes klienta pusē izskatās veselas: rokasspiediens noslēdzas, klients saņem adresi, un pat ping uz servera tuneļa adresi var atbildēt. Stundas tiek iztērētas klientā bojājuma dēļ, kas mīt otrā pusē, tāpēc noteikumu tabula ir pirmā vieta, kur skatīties.

Pirms rediģēšanas izlasiet noteikumu un tā skaitītājus

Uzskaitiet tulkošanas noteikumus ar skaitītājiem un salīdziniet konfigurēto avotu ar adresēm, kas resursdatoram tiešām ir. Uz mirušu adresi pārrakstīts noteikums parasti rāda plūsmu ieejas ceļā, jo paketes to sasniedz un tiek tulkotas, un neko atpakaļceļā.

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

Pārbaudiet trīs laukus, kamēr esat tur: kopu avota atbilstībā, izejas saskarni, ja noteikums kādu nosauc, un izņēmumu, kas neļauj pārrakstīt plūsmu starp tuneļiem. Šo izņēmumu rediģēšanas laikā ir viegli pazaudēt, un tā pazaudēšana liek plūsmai starp partneriem izskatīties strādājošai, kamēr tās atbildes iet dīvainu ceļu.

Ja skaitītāji iestrēguši uz nulles, paketes nekad nesasniedz šo noteikumu, un adrese nav pašreizējā problēma. Meklējiet konkurējošu noteikumu agrāk ķēdē, kas notiek, kad kāds pievieno aizstājēju, nevis rediģē oriģinālu. Salīdziniet noteikumu numurus ar izvadi, ko pierakstījāt pirms minūtes. Secība ir konfigurācijas daļa, nevis kosmētiska detaļa.

Aizstājiet avotu vai pārtrauciet to nosaukt

Kad resursdatoram ir stabila adrese, aizstājiet noteikumu tā vietā, nevis pievienojiet vēl vienu. Aizstāšana pēc noteikuma numura saglabā secību, no kuras atkarīga pārējā ķēde.

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

Kad adrese tiek piešķirta dinamiski, nenorādiet nekādu avotu un ļaujiet kodolam izvēlēties pašreizējo no izejas saskarnes. Šis variants pārdzīvo nākamo pārcelšanos bez rediģēšanas, par cenu, ka tiek slēpts, kura adrese tika izmantota.

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

Pārliecinieties, ka IPv4 pārsūtīšana joprojām ir iespējota ar pārvaldītu konfigurāciju, pēc tam padariet noteikumu pastāvīgu ar pašas distribūcijas mehānismu. Izmaiņas, kas veiktas tikai darbojošā kodolā, atgriežas nākamajā pārstartēšanā, parasti apkopes logā, kuru neviens nesaista ar izmaiņām.

Divi veidi, kā aizstāšanu izdarīt nepareizi

Kopas tulkošana uz servera tuneļa adresi, nevis uz tā LAN adresi, sūta atbildes tieši atpakaļ tunelī, kur tās maršrutējas pie klienta, kurš tās nekad nav pieprasījis. Savienojums iestrēgst tā, ka izskatās pēc maršrutēšanas cilpas, jo tā arī ir.

Otra tulkojuma uzlikšana virs vecā ir otra kļūda. Uzvar pirmais atbilstošais noteikums, tāpēc novecojušais ieraksts turpina apstrādāt paketes, līdz tas tiek izdzēsts, un jaunā noteikuma skaitītāji paliek uz nulles, kamēr visi vaino aizstājēju. Izdzēsiet dublikātu pirms kaut ko jaunu pievienojat. Pēc tam vēlreiz izlasiet sarakstu un apstipriniet, ka kopai atbilst tieši viens tulkojums.

Ja tunelis pārvadā arī IPv6, atkārtojiet visu pārskatu otrā stekā. IPv6 noklusējuma maršruts bez tulkojuma un bez maršrutēta prefiksa neizdodas tikpat klusi, un to ir viegli aizmirst, jo viss virs tā izskatās identiski.

Ienākošajiem pakalpojumiem vajag pretējo tulkojumu

Pakalpojumam VPN klientā, kuram jābūt pieejamam no ārpuses, vajag galamērķa tulkojumu, nevis avota: publiskais ports tiek pārrakstīts uz klienta tuneļa adresi pirms ieiešanas. Tad pārsūtīšanas ceļam vajag skaidru noteikumu, kas atļauj šo plūsmu.

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

Nekad netulkojiet portu, kas pārvadā pašu tuneli, jo šī pārrakstīšana pārtrauc savienojumu, kas uztur pakalpojumu pieejamu. Turiet tuneļa portu pilnībā ārpus galamērķa noteikumiem. Beigās pārbaudiet no abiem galiem: skaitītāji jaunajā noteikumā, īss ieraksts tuneļa ierīcē un viens pieprasījums uz adresi tuneļa iekšpusē pirms publiskā izmēģināšanas.