Дали 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 тек и известува за загуби и џитер. Тек што започнува и потоа запира упатува на големина, а не на блокирање.

Известете за слојот, а не за протоколот

Запишете го наодот во една од три форми: надворешната испорака не успеа, внатрешното проследување не успеа или апликацијата не успеа. Секоја има различен сопственик, а нивното мешање го праќа тикетот до погрешниот тим.

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

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