UDP блокує провайдер чи застосунок усередині тунелю?

Хтось повідомляє, що VPN „блокує UDP“, і ця фраза приховує два цілком різні твердження. Одне стосується транспорту, який бачить мережа доступу, друге — пакетів застосунку після їх розшифрування всередині тунелю. Зашифрований тунель можна фільтрувати ззовні без жодного ключа, а внутрішній застосунок UDP може зазнавати збоїв із причин, що не мають нічого спільного з фільтрацією. Визначте, яке твердження ви перевіряєте, перш ніж збирати докази.

Два заголовки, одне слово

У розгортанні IPsec з NAT-traversal зовнішній пакет — це UDP, адресований між двома кінцевими точками VPN, зазвичай на порту 4500. Усередині нього зашифроване корисне навантаження несе все, що передає тунель, і це саме може бути TCP або UDP. Тому слово UDP з'являється двічі, з різним значенням і різною видимістю.

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

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

Що мережа все ще може бачити

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

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

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

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

Чому один застосунок UDP зазнає збою в робочому тунелі

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

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

Третє — розмір пакета. Застосунки UDP часто надсилають більші дейтаграми, ніж вебзапит, а інкапсуляція зменшує доступний MTU, тож після успішного рукостискання може настати тиша на першому повнорозмірному навантаженні. Цей шаблон легко прочитати як блокування, бо малі пакети проходять, а великі зникають. Швидка перевірка MTU вирішує це менш ніж за хвилину, і відповіддю зазвичай буває менше навантаження або виправлений MSS, а не мережевий фільтр.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

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

Повідомляйте рівень, а не протокол

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

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

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