След смяна на IP адреса на сървъра правилото SNAT все още сочи стария

Сървърът се премести на нов адрес, клиентите все още се свързват и нищо от изпратеното от тях не стига до интернет. Това разделение е уликата: слушащият сокет и препращането на порт преживяха преместването, затова тунелът се вдига, докато транслацията на източника, прилагана към препратените пакети все още сочи адрес, който хостът вече не притежава. Отговорите към тези пренаписани пакети отиват към машина, която вече не е там.

Свързването и препращането се провалят на различни места

Установяването зависи от крайната точка, която клиентите вече знаят: публичния адрес, препращането на порт пред него и слушателя отвътре. Препратеният трафик зависи от второ решение, взето след като пакетът влезе в тунела, когато хостът пренаписва източника си, за да могат отговорите да намерят пътя обратно.

Смяната на адреса чупи само второто решение и затова симптомът се чете като "свързано, но без интернет". Това също обяснява защо обичайните проверки от страна на клиента изглеждат наред: ръкостискането завършва, клиентът получава адрес и дори ping към тунелния адрес на сървъра може да отговори. Часове се харчат по клиента заради повреда, която живее от другата страна, затова таблицата с правила е първото място за гледане.

Прочетете правилото и броячите му преди редакция

Избройте правилата за транслация с броячите им и сравнете конфигурирания източник с адресите, които хостът действително притежава. Правило, пренаписано към мъртъв адрес, обикновено показва трафик по входящия път, защото пакетите го достигат и се транслират, и нищо по обратния път.

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

Проверете три полета, докато сте там: пула в съвпадението на източника, изходния интерфейс, ако правилото сочи такъв, и изключването, което пази трафика между тунели от пренаписване. Това изключване лесно се губи при редакция, а загубата му кара трафика между партньори да изглежда работещ, докато отговорите му поемат странен път.

Ако броячите стоят на нула, пакетите никога не достигат това правило и адресът не е текущият проблем. Търсете конкурентно правило по-рано във веригата, което се случва, когато някой добави замяна, вместо да редактира оригинала. Сравнете номерата на правилата с изхода, който записахте преди минута. Редът е част от конфигурацията, а не козметична подробност.

Заменете източника или спрете да сочите такъв

Когато хостът има стабилен адрес, заменете правилото на място, вместо да добавяте още едно. Замяната по номер на правило запазва подредбата, от която зависи останалата част от веригата.

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

Когато адресът се задава динамично, не сочете източник изобщо и оставете ядрото да избере текущия от изходния интерфейс. Този вариант преживява следващото преместване без редакция, на цената да скрива кой адрес е използван.

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

Потвърдете, че препращането на IPv4 все още е включено чрез управлявана конфигурация, после направете правилото постоянно със собствения механизъм на дистрибуцията. Промяна, направена само в работещото ядро, се връща при следващото рестартиране, обикновено в поддръжен прозорец, който никой не свързва с промяната.

Два начина да сгрешите замяната

Транслирането на пула към тунелния адрес на сървъра вместо към LAN адреса му изпраща отговорите направо обратно в тунела, където се маршрутизират към клиент, който никога не ги е искал. Връзката засича по начин, който изглежда като маршрутна примка, защото е такава.

Натрупването на втора транслация върху старата е другата грешка. Първото съвпадащо правило печели, затова остарелият запис продължава да обработва пакети, докато бъде изтрит, а броячите на новото правило стоят на нула, докато всички обвиняват замяната. Изтрийте дубликата, преди да добавите нещо ново. После прочетете списъка още веднъж и потвърдете, че точно една транслация съвпада с пула.

Ако тунелът носи и IPv6, повторете целия преглед на другия стек. Маршрут по подразбиране IPv6 без транслация и без маршрутизиран префикс се проваля също толкова тихо и лесно се забравя, защото всичко над него изглежда идентично.

Входящите услуги се нуждаят от обратната транслация

Услуга на клиент VPN, която трябва да е достъпна отвън, се нуждае от транслация на местоназначението, не на източника: публичният порт се пренаписва към тунелния адрес на клиента, преди да влезе. После пътят за препращане се нуждае от явно правило, разрешаващо този трафик.

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

Никога не транслирайте порта, който носи самия тунел, защото това пренаписване прекъсва връзката, която държи услугата достъпна. Дръжте тунелния порт напълно извън правилата за местоназначение. Накрая проверете от двата края: броячи на новото правило, кратък запис на тунелното устройство и една заявка към адрес вътре в тунела, преди да опитате публичния.