Blokkeer die ISP UDP, of is dit die app binne die tonnel?

Iemand rapporteer dat die VPN "blokkeer UDP", en dié frase verberg twee heeltemal verskillende bewerings. Die een gaan oor die transport wat die toegangsnetwerk kan sien, die ander oor ’n toepassing se pakkette nadat hulle binne die tonnel ontsyfer is. ’n Versleutelde tonnel kan van buite gefiltreer word sonder enige sleutel, en ’n binne-UDP-toepassing kan misluk om redes wat niks met filtering te doen het nie. Besluit watter bewering jy toets voordat jy bewyse insamel.

Twee koppe, een woord

In ’n NAT-traversal IPsec-ontplooiing is die buitenste pakket UDP, geadresseer tussen die twee VPN-eindpunte, tipies op poort 4500. Daarbinne dra die versleutelde vraginhoud alles wat die tonnel aanstuur, wat self TCP of UDP kan wees. Die woord UDP verskyn dus twee keer met verskillende betekenisse en verskillende sigbaarheid.

’n Tussenliggende netwerk sien die buitenste kop en niks van die binne-kop nie. Dit kan die buitenste vloei toelaat, vorm of laat val, en dit hoef niks te ontsyfer om dit te doen nie. Dié asimmetrie is die hele rede waarom die twee bewerings verwar word: dieselfde woord beskryf wat die netwerk filtreer en wat die toepassing stuur. Skryf die laag langs die woord neer wanneer jy ’n bevinding aanteken, en die verwarring verdwyn meestal.

Die binne-kop word eers by die ontvangende eindpunt sigbaar, ná ontsyfering. Van daardie punt af word die pakket soos enige ander aangestuur, onderhewig aan roetes, beleid en die eindpunt se eie filtering. Dit is aparte besluite wat deur verskillende toestelle geneem word.

Wat die netwerk steeds kan sien

Versleuteling verberg die vraginhoud en die binne-transportkop, nie die feit dat daar ’n vloei bestaan nie. Eindpuntadresse, poorte, pakketgroottes en tydsberekening bly sigbaar, en dit is genoeg om verkeer heuristies te klassifiseer of ’n spesifieke bestemming te blokkeer.

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

Die eerste opname wys die buitenste vloei op die fisiese koppelvlak, en die tweede wys die binne-vloei op die tonnelkoppelvlak. Om albei gelyk te laat loop, beantwoord die vraag direk: as die buitenste vloei bestaan en die binne-vloei nie, het die toepassing nooit iets in die tonnel gestuur nie. As albei bestaan en niks terugkom nie, is die probleem anderkant die tonnel, by die bestemming of op die terugpad.

RFC 3948 definieer die buitenste UDP-inkapseling, en die ESP-spesifikasie definieer die beskermde uitleg daarbinne. Nie een dokument belowe dat ’n toegangsnetwerk die buitenste vloei sal deurlaat nie, en daarom is dit die moeite werd om ’n bereikbaarheidstoets op die buitenste tuple te doen voordat jy enige teorie oor die binne-een het. ’n Geblokkeerde buitenste tuple lewer ’n tonnel wat nooit gevorm word nie, nie ’n tonnel wat vorm en dan een toepassing verloor nie.

Waarom een UDP-toepassing in ’n werkende tonnel misluk

’n Tonnel wat ’n webtoepassing dra maar nie ’n UDP-toepassing nie, het verskeie waarskynlike verklarings, en ISP-filtering van die binne-protokol is nie die eerste nie. Die algemeenste is dekking: die twee toepassings gaan nie albei in dieselfde tonnel in nie, omdat die roete na die UDP-bestemming ontbreek of die kliënt se split-tonnel-reëls dit uitsluit.

Die tweede is die eindpunt. ’n VPN-bediener wat ’n protokollys toelaat, ’n bestemming-firewall, of ’n diens wat nooit op die verwagte poort luister nie, sal almal ’n tydsverloop lewer wat identies lyk aan ’n netwerkblokkade.

Die derde is pakketgrootte. UDP-toepassings stuur dikwels groter datagramme as ’n webversoek, en inkapseling verklein die bruikbare MTU, so ’n werkende handdruk kan gevolg word deur stilte op die eerste volgrootte-vrag. Dié patroon is maklik om as ’n blokkade te mislees, want die klein pakkette slaag en die grootes verdwyn. ’n Vinnige MTU-toets besleg dit in minder as ’n minuut, en die antwoord is gewoonlik ’n kleiner vrag of ’n reggestelde MSS eerder as ’n netwerkfilter.

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

Die eerste opdrag toets of ’n groot pakket die pad oorleef met fragmentasie afgeskakel, wat ’n MTU-probleem vinnig blootlê. Die tweede stuur ’n klein, begrensde UDP-stroom en rapporteer verlies en jitter. ’n Stroom wat begin en dan vasval, dui op grootte eerder as op ’n blokkade.

Rapporteer die laag, nie die protokol nie

Skryf die bevinding in een van drie vorme: buitenste aflewering het misluk, binne-aanstuur het misluk, of die toepassing het misluk. Elkeen het ’n ander eienaar, en om hulle te meng stuur die kaartjie na die verkeerde span.

Om ’n plaaslike poort te verander kan nie ’n passende luisteraar aan die ander kant skep nie, so ’n kliëntkant-omweg wat te help lyk, is gewoonlik bewys dat die oorspronklike bestemming verkeerd was. Net so bewys ’n verskafde alternatiewe profiel iets oor bereikbaarheid en niks oor of die toepassing korrek opgestel is nie.

Hou afleiding ook apart van waarneming. Verkeersanalise kan voorstel wat ’n vloei is sonder om dit te ontsyfer, en dit is ’n nuttige bevinding, maar dit is nie dieselfde bewering as om die binne-kop te lees nie. Stel dit wat jy werklik het.