Два VPN-клієнти, дві публічні адреси: узгодьте SNAT

Два VPN-клієнти можуть виходити через дві різні публічні адреси IPv4, і правило, яке це робить, коротше, ніж очікує більшість. Працює воно не завдяки синтаксису iptables, а завдяки стану пакета, коли він досягає ланцюга виходу: адреса джерела там усе ще має розрізняти клієнтів. Якщо попередній masquerade вже звів обох до однієї адреси, жодне правило на клієнта не відновить розрізнення. Спершу вирішіть це питання, потім пишіть переклад.

Яка ідентичність доживає до шлюзу

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

iptables -t nat -S POSTROUTING

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

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

Трансляція не може вигадати адресу

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

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

Вставте перед загальним masquerade

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

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

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

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

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

Доведіть джерело новим потоком

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

conntrack -L -s 10.88.4.20 -p tcp --dport 443

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

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