Блокира ли доставчикът 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 поток и отчита загуби и джитер. Поток, който започва и после спира, сочи към размер, а не към блокиране.

Съобщавайте слоя, не протокола

Запишете находката в една от три форми: външната доставка се провали, вътрешното препращане се провали или приложението се провали. Всяка има различен собственик и смесването им изпраща заявката до грешния екип.

Промяната на локален порт не може да създаде съответстващ слушател в отсрещния край, затова клиентска заобиколка, която изглежда помага, обикновено е доказателство, че първоначалната дестинация е била грешна. По същия начин предоставен алтернативен профил доказва нещо за достижимостта и нищо за това дали приложението е конфигурирано правилно.

Дръжте извода отделно от наблюдението. Анализът на трафика може да подскаже какъв е потокът, без да го дешифрира, и това е полезна находка, но не е същото твърдение като четенето на вътрешния заглавен блок. Посочете кое от двете всъщност имате.