Після зміни 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

Ніколи не транслюйте порт, який несе сам тунель, бо це переписування перериває з'єднання, що тримає службу доступною. Тримайте тунельний порт повністю поза правилами призначення. Наприкінці перевірте з обох боків: лічильники на новому правилі, короткий запис на тунельному пристрої й один запит на адресу всередині тунелю, перш ніж пробувати публічну.