eth0:0 — це мітка, а не пристрій: виправте збіг SNAT

Нульовий лічильник означає, що правило називає інтерфейс, якого не може бути. Прочитайте справжній пристрій, виправте збіг -o і потім свідомо виберіть перекладну адресу.

Правило NAT, яке мало дати одному пулу клієнтів VPN власну публічну адресу, стоїть на нулі пакетів, а той самий пул продовжує виходити з неправильним джерелом. Зазвичай правило помиляється не в адресі, а в інтерфейсі. -o eth0:0 вказує на пристрій, якого не існує, бо eth0:0 це мітка, прив'язана до адреси на eth0. Дивитися на лічильники — найшвидший спосіб це підтвердити, а виправлення менше, ніж припускає розслідування.

Перевірте, як ядро називає пристрій

Прочитайте два подання окремо, перш ніж щось змінювати:

ip link show
ip address show dev eth0
ip route get 203.0.113.20

Список зв'язків показує інтерфейси. Список адрес може показати другу адресу IPv4, що несе мітку eth0:0, і пристроєм для цієї адреси досі є eth0. Довідник адрес iproute2 трактує мітку як ім'я адреси, а не як другий зв'язок, і саме на цій різниці тримається вся проблема.

Історія пояснює плутанину. Старий ifconfig eth0:0 синтаксис справді виглядав як новий інтерфейс, і скрипти тієї епохи досі на нього посилаються. У сучасній системі псевдонім — це мітка на адресі, і ніщо на шляху маршрутизації чи netfilter не вважає її окремою точкою виходу.

Перевірте, з чим правило насправді збіглося

Читайте лічильники разом зі списком правил, а не з пам'яті:

iptables -t nat -L POSTROUTING -v -n --line-numbers

Правило, лічильник пакетів якого лишається на нулі, поки йде відповідний трафік, не оцінюється, і умова вихідного інтерфейсу, що називає eth0:0 часта причина. Вихідний пристрій, вибраний маршрутом, — eth0, тому умова, що шукає інше ім'я, ніколи не стає істинною, яку б адресу джерела не вибрало ядро.

Змініть умову на справжній пристрій і залиште мітку поза нею. Якщо треба розрізнити два пули клієнтів, що ділять цей пристрій, розрізняйте їх за префіксом джерела, а не за іменем інтерфейсу, якого не може бути. Два правила з неперетинними -s збігами читаються і перевіряються; одне правило з вигаданим пристроєм — ні те, ні інше. Додайте кожному правилу коментар з іменем пулу, бо за півроку сам префікс нікому не скаже, чому воно там.

Перевірте маршрут, що вибрав пристрій

NAT postrouting виконується після того, як маршрут уже вибрав вихідний інтерфейс, тому інтерфейс у правилі має бути тим, який вибрав маршрут. Запитайте ядро безпосередньо за допомогою ip route get для показової адреси клієнта і прочитайте і пристрій, і джерело, яке воно повідомляє.

Якщо відповідь називає eth0, частину правила щодо інтерфейсу вирішено. Якщо вона називає тунельний пристрій, пакет ніколи не доходить до правила, яке ви редагуєте, і пошук переходить до таблиці маршрутизації та її пріоритетів. Правило, що ніколи не збігається, бо пакет вийшов інде, у виводі лічильників виглядає так само, як правило з неправильно написаним пристроєм. Перш ніж щось змінювати, підтвердьте, який із двох випадків у вас, бо другий вимагає зміни маршрутизації, а не тексту.

Свідомо виберіть перекладне джерело

Коли пристрій правильний, адреса джерела — окреме рішення. Це лише ілюстративний пул IPv4 і приклад адреси:

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

Запис адреси в --to-source не змусить когось маршрутизувати її назад до вас. Постачальник вищого рівня або власник адреси має доставляти відповіді для цієї адреси на цей хост, і адреса має бути такою, яку вам дозволено використовувати. Якщо ні, правило збігнеться і перекладе, а відповіді все одно підуть інде.

Зміна адреси джерела — не те саме, що зміна висхідного каналу. Коли справжня вимога — інший фізичний шлях, політика маршрутизації має спершу вибрати цей шлях; потім SNAT переписує джерело на тому пристрої, який вибрала політика. Нові мітки на eth0 не дають ні маршруту, ні дозволу.

Перевірте на щойно відкритому з'єднанні

Відкрийте нове клієнтське з'єднання замість повторного використання наявного. Відстеження з'єднань зберігає переклад, записаний на старті потоку, тож стара сесія може далі використовувати попередню адресу джерела і змушувати правильне нове правило виглядати зламаним. Стежте, як зростає лічильник, потім подивіться на перекладене джерело на лінії або на дальньому кінці.

Коли кілька пулів ділять один інтерфейс, дайте кожному явний збіг за джерелом і власну адресу перекладу, тримайте їх в керованій конфігурації міжмережевого екрана і записуйте порядок їх обчислення. Потім запишіть, що ви перевірили: пристрій з ip route get, лічильник, що зрушив, і джерело, яке побачила віддалена сторона. Цей запис відповідає на наступний звіт, не повторюючи плутанину з псевдонімом.

Схожі статті