Симетричний NAT і VPN: вимірюйте відображення, а не ярлик
Відображення, що залежить від кінцевої точки, впливає на пошук партнерів, а не на звичайний тунель від клієнта до сервера. Виміряйте порт і, якщо прямий шлях не працює, використайте ретранслятор.
Тема підтримки закінчується вердиктом «симетричний NAT, VPN тут не працюватиме», після чого клієнт тричі без причини перевстановлюють. Ярлик завдає шкоди, бо відповідає на питання, якого ніхто не ставив. Клієнт, який підключається назовні до фіксованого сервера, створює відображення в момент надсилання першого пакета, і відповідь дозволяється назад за правилами, які реалізує майже кожна мережа. Те, що відображення, залежне від кінцевої точки, справді ускладнює, — це два партнери, які намагаються дістатися один одного одночасно, і це інша перевірка.
За одним ярликом ховаються два питання
Перше питання — чи може хост за цією мережею відкрити сеанс до відомої публічної адреси й порту. Для клієнта тунелю це звичайний випадок, і відповідь майже завжди так. Маршрутизатор записує внутрішнє джерело, виділяє зовнішній порт і пропускає відповідь, бо вона належить сеансу, що почався зсередини.
Друге питання — чи можуть два хости за різними мережами знайти спільний шлях і надсилати один одному без сервера посередині. Це залежить від того, як кожна мережа виділяє ті зовнішні порти, і лише там поведінка відображення має значення.
Змішування обох дає класичний хибний діагноз: функція між партнерами не працює, хтось запускає тест типу NAT, бачить найгіршу категорію і робить висновок, що й звичайний тунель не може працювати. Тунель ніколи не був тим, що зламалося.
Відображення й фільтрація — різні властивості
Термінологія RFC точніша за назви, які використовують постачальники, і її варто переносити в тікет, бо вона припиняє суперечки. Відображення — це те, як виділяється зовнішній порт. Фільтрація — це те, які вхідні пакети пропускаються. Мережа може бути суворою в одному й ліберальною в іншому, і саме ця комбінація — те, що протокол між партнерами має пережити.
| Behaviour | What it means | Effect on a direct peer path |
|---|---|---|
| Endpoint-independent mapping | One external port for every destination | Discovery works if the port is advertised |
| Address-dependent mapping | New port per remote address | Works only if both sides probe the same pair |
| Address-and-port-dependent | New port per remote address and port | Usually needs a relay |
Третій рядок — це те, що більшість домашніх маршрутизаторів і мобільних операторів розуміють під словом симетричний. Зауважте, що ярлик описує лише виділення. Мережа з таким відображенням і ліберальною фільтрацією все ще може приймати вхідні пакети на порт, який вона щойно виділила, тому пробивання отворів вдається на одних і не вдається на інших.
Фільтрація має свої три випадки й свою назву для кожного. Написати в тікеті «симетричний NAT», коли мається на увазі «фільтрація, залежна від адреси й порту», відправляє наступну людину в неправильний розділ посібника. Обидва поводяться по-різному під час перевірки, тож помилка не академічна.
Вимірюйте відображення, а не називайте його
Виділений порт можна спостерігати безпосередньо з боку сервера будь-якої служби UDP, якою ви керуєте. Почніть захоплення на публічному хості, надішліть із клієнта й прочитайте порт джерела, з яким прийшов пакет:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820Рядок кінцевої точки — найкорисніший із трьох, бо WireGuard записує останню адресу й порт, отримані від кожного партнера. Порівняйте цей порт із тим, який клієнт вважає, що використовує. Вони різнитимуться щоразу, коли відбувається будь-яке перетворення, і важливе питання — чи залишається значення стабільним.
Повторіть спостереження щодо другого порту призначення або другого сервера й порівняйте знову. Якщо зовнішній порт змінюється залежно від призначення, відображення залежить від адреси й порту. Якщо він залишається тим самим, мережа дає одне відображення, і пошук має шанс.
Інструменти на основі STUN повідомляють ту саму класифікацію за один крок, і ними можна користуватися, коли мережа дозволяє вихідний UDP до публічного сервера STUN. Коли не дозволяє, описаний вище метод захоплення все ще працює й не потребує нічого, крім хоста, який ви вже контролюєте.
Виберіть виправлення, що відповідає збою
Якщо збійна функція — зв'язок між партнерами, підтримувані відповіді — ретранслятор, служба зустрічі, до якої можуть дістатися обидва партнери, або інша топологія. TURN існує саме для цього, і продукт, який постачає власний ретранслятор, говорить вам, що очікує ворожості деяких мереж.
Якщо збійна функція — звичайний тунель, поведінка відображення не ваша проблема, і ніщо з переліченого не застосовується. Перевірте, що клієнт справді надсилає, що сервер бачить пакет і що відповідь повертається. Ця послідовність — три спостереження, і вона не вимагає знати що-небудь про категорію NAT маршрутизатора.
Що не працює — це розкидання змін локального порту, доки щось не підключиться. Зміна порту джерела клієнта не змінює того, як мережа виділяє відображення. Випадковий успіх з п'ятої спроби — хибнопозитивний результат, і його місяцями цитуватимуть як рішення.
Записуйте архітектуру, а не вердикт
Корисна нотатка каже, який протокол, у якому напрямку починається сеанс, чи є на шляху ретранслятор і що спостерігалося на дроті. «симетричний NAT, не працює» непридатне, бо воно одночасно хибне щодо тунелю й нічого не повідомляє про шлях партнера.
Включіть виміряну стабільність порту й поведінку фільтрації, якщо ви їх перевіряли. Ці два факти дозволяють комусь іншому передбачити, чи працюватиме нова функція в тій мережі, не повторюючи все розслідування. Вони також старіють краще, ніж категорія постачальника, яка на кожній сторінці довідки означає трохи інше.
Нарешті, тримайте під рукою термінологію RFC 4787, коли будете це записувати. Використання точних термінів коштує одного речення й не дає наступному читачеві повторити той самий хибний діагноз, і в цьому весь сенс написання нотатки.