SNAT, DNAT і Masquerade: що робить кожне правило NAT у VPN

Поставте перехоплення з обох боків шлюзу VPN, і один потік може показати чотири різні адреси. NAT джерела переписує, звідки пакет, за його словами, надходить; NAT призначення переписує, куди він іде. Masquerade — не третій напрям, а правило NAT джерела, яке бере адресу з вихідного інтерфейсу замість фіксованого значення. Назвіть, яке з трьох вам справді потрібне, і більшість заявок «VPN зламано» зводяться до питання про зворотний шлях.

Що переписує кожне правило

NAT джерела, зазвичай записуваний як SNAT, змінює адресу джерела потоку, коли той залишає маршрутизатор або шлюз. Сервіс, що приймає, відповідає на перекладену адресу, а вузол, що перекладає, скасовує зміну, використовуючи стан, який зберігав для цього з’єднання. У Linux цей стан живе в conntrack, тому conntrack -L друкує початкові та відповідні кортежі поруч.

NAT призначення, DNAT, натомість змінює призначення. Пакет, адресований публічній адресі на UDP 51820, можна переписати на внутрішній сервер WireGuard за адресою 10.8.0.2:51820. Так домашній маршрутизатор або хмарний балансувальник публікує слухача VPN, і це нічого не каже про те, що тунель може нести далі.

Masquerade належить до родини SNAT. Правило не називає адреси; воно використовує ту, яку має вихідний інтерфейс на момент виходу пакета. Linux дає йому власну ціль, і це звичний вибір на інтерфейсі WAN, який отримує адресу через DHCP або PPPoE.

Де живе відображення, там визначається збій

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

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

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

Masquerade чи явний SNAT

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

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

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

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

Читання правил на шлюзі Linux

Шлюзу віддаленого доступу з клієнтами в 10.8.0.0/24 та інтерфейсом WAN на ім’я eth0 потрібні ввімкнене пересилання і політика фільтрації, що дозволяє потік, перш ніж якесь правило NAT допоможе. Версія з iptables тримає обидва напрями в таблиці nat:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

Форма nftables використовує ті самі два гачки з іменованим інтерфейсом і явним ланцюжком:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Обидва фрагменти припускають, що ланцюжок фільтрації вже приймає пересланий потік. NAT не є правилом дозволу, і коректно перекладений пакет усе одно може бути відкинутий однією таблицею далі. Підтвердьте живе відображення за допомогою conntrack -L, підтвердьте, що завантажено, за допомогою nft list ruleset або iptables-save -t nat, а потім зніміть перехоплення на обох інтерфейсах, щоб побачити, що адреса справді змінюється.

Режими збою, схожі на погане правило

Трафік «шпилькою» — класика. Внутрішньому клієнту, який досягає внутрішнього сервера через його публічну адресу, потрібен DNAT на вході й переклад джерела на зворотному виході, інакше сервер відповідає прямо клієнтові і відповідь відхиляється. Виправлення — друге, вужче правило для цього випадку «внутрішній до публічного», а не ширше правило Masquerade для всього.

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

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

Контрольний список перед збереженням правила

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

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