Чи варто застосовувати SNAT до переадресації порту в підмережу VPN?

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

Чому відповідь іде іншою дорогою

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

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

Правило джерела, достатньо вузьке, щоб йому довіряти

Зробіть роутер джерелом, якому відповідає віддалений хост. У цій схемі адреса WAN — 203.0.113.24, LAN — 192.168.88.0/24, адреса тунелю роутера — 172.20.5.1, а служба відповідає на 172.20.5.40:8443. Правило нижче збігається з пакетом після трансляції призначення, тому в ньому вказано трансльовану адресу, а не публічну. Ніщо в ньому не залежить від адреси клієнта, і саме в цьому суть.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

Коли суцільна маскувальна маска — чесний вибір

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

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

Перевірте лічильники перед публікацією

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

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

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