Да ли ISP блокира 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 апликацију, има неколико веродостојних објашњења, а филтрирање унутрашњег протокола од стране ISP-а није прво. Најчешће је покривеност: две апликације не улазе обе у исти тунел, јер недостаје рута до 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 ток и извештава о губицима и џитеру. Ток који почне и затим стане указује на величину, а не на блокаду.

Пријавите слој, а не протокол

Запишите налаз у једном од три облика: спољашња испорука није успела, унутрашње прослеђивање није успело или апликација није успела. Свака има другог власника, а њихово мешање шаље тикет погрешном тиму.

Промена локалног порта не може да створи одговарајућег слушаоца на далеком крају, зато је клијентско заобилазно решење које изгледа да помаже обично доказ да је првобитна дестинација била погрешна. Исто тако, достављени алтернативни профил доказује нешто о доступности и ништа о томе да ли је апликација исправно конфигурисана.

Држите закључак одвојено од запажања. Анализа саобраћаја може да сугерише шта је ток без дешифровања, и то је користан налаз, али то није иста тврдња као читање унутрашњег заглавља. Наведите које од тога заиста имате.