Blokkeert de ISP UDP, of is het de app in de tunnel?

Iemand meldt dat de VPN „UDP blokkeert“, en die zin verbergt twee heel verschillende beweringen. De ene gaat over het transport dat het toegangsnetwerk kan zien, de andere over de pakketten van een applicatie nadat ze in de tunnel zijn ontsleuteld. Een versleutelde tunnel kan van buitenaf worden gefilterd zonder enige sleutel, en een binnenste UDP-applicatie kan falen om redenen die niets met filtering te maken hebben. Bepaal welke bewering je test voordat je bewijs verzamelt.

Twee headers, één woord

In een IPsec-implementatie met NAT-traversal is het buitenste pakket UDP, geadresseerd tussen de twee VPN-eindpunten, doorgaans op poort 4500. Daarbinnen draagt de versleutelde payload alles wat de tunnel doorstuurt, en dat kan zelf TCP of UDP zijn. Het woord UDP verschijnt dus twee keer, met verschillende betekenis en verschillende zichtbaarheid.

Een tussenliggend netwerk ziet de buitenste header en niets van de binnenste. Het kan de buitenste stroom toestaan, vormen of laten vallen, en het hoeft daarvoor niets te ontsleutelen. Die asymmetrie is de hele reden dat de twee beweringen door elkaar lopen: hetzelfde woord beschrijft wat het netwerk filtert en wat de applicatie verstuurt. Schrijf de laag naast het woord telkens wanneer je een bevinding vastlegt, en de verwarring verdwijnt grotendeels.

De binnenste header wordt pas zichtbaar bij het ontvangende eindpunt, na ontsleuteling. Vanaf dat punt wordt het pakket doorgegeven als elk ander, afhankelijk van routes, beleid en de eigen filtering van het eindpunt. Dat zijn afzonderlijke beslissingen die door verschillende apparaten worden genomen.

Wat het netwerk nog kan zien

Versleuteling verbergt de payload en de binnenste transportheader, niet het feit dat er een stroom bestaat. Eindpuntadressen, poorten, pakketgroottes en timing blijven zichtbaar, en dat is genoeg om verkeer heuristisch te classificeren of een specifieke bestemming te blokkeren.

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

De eerste opname toont de buitenste stroom op de fysieke interface, en de tweede de binnenste stroom op de tunnelinterface. Beide tegelijk draaien beantwoordt de vraag direct: als de buitenste stroom bestaat en de binnenste niet, heeft de applicatie nooit iets de tunnel in gestuurd. Als beide bestaan en er komt niets terug, ligt het probleem voorbij de tunnel, bij de bestemming of op de retourweg.

RFC 3948 definieert de buitenste UDP-inkapseling, en de ESP-specificatie definieert de beschermde indeling daarbinnen. Geen van beide documenten belooft dat een toegangsnetwerk de buitenste stroom doorlaat, en daarom is het de moeite waard om een bereikbaarheidstest op de buitenste tuple uit te voeren voordat je enige theorie over de binnenste hebt. Een geblokkeerde buitenste tuple levert een tunnel op die nooit tot stand komt, niet een tunnel die tot stand komt en dan één applicatie verliest.

Waarom één UDP-app faalt in een werkende tunnel

Een tunnel die een webapplicatie draagt maar geen UDP-applicatie heeft verschillende plausibele verklaringen, en filtering van het binnenste protocol door de ISP is niet de eerste. De meest voorkomende is dekking: de twee applicaties komen niet beide in dezelfde tunnel, omdat de route naar de UDP-bestemming ontbreekt of de split-tunnelregels van de client die uitsluiten.

De tweede is het eindpunt. Een VPN-server die een protocollijst toestaat, een firewall bij de bestemming, of een dienst die nooit op de verwachte poort luistert, leveren allemaal een time-out op die er identiek uitziet als een netwerkblokkade.

De derde is pakketgrootte. UDP-applicaties sturen vaak grotere datagrammen dan een webaanvraag, en inkapseling verkleint de bruikbare MTU, zodat na een geslaagde handshake stilte kan volgen bij de eerste volledige payload. Dat patroon is gemakkelijk als blokkade te lezen, omdat de kleine pakketten slagen en de grote verdwijnen. Een snelle MTU-proef beslecht het in minder dan een minuut, en het antwoord is meestal een kleinere payload of een gecorrigeerde MSS, niet een 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

Het eerste commando test of een groot pakket het pad overleeft met fragmentatie uitgeschakeld, wat een MTU-probleem snel blootlegt. Het tweede stuurt een kleine, begrensde UDP-stroom en rapporteert verlies en jitter. Een stroom die begint en dan stokt wijst op grootte, niet op een blokkade.

Rapporteer de laag, niet het protocol

Schrijf de bevinding in een van drie vormen: buitenste aflevering mislukt, binnenste doorsturing mislukt, of de applicatie mislukt. Elk heeft een andere eigenaar, en ze door elkaar halen stuurt het ticket naar het verkeerde team.

Een lokale poort wijzigen kan aan de andere kant geen passende listener maken, dus een client-side omweg die lijkt te helpen is meestal bewijs dat de oorspronkelijke bestemming onjuist was. Evenzo bewijst een geleverd alternatief profiel iets over bereikbaarheid en niets over of de applicatie correct is geconfigureerd.

Houd ook de gevolgtrekking gescheiden van de waarneming. Verkeersanalyse kan suggereren wat een stroom is zonder die te ontsleutelen, en dat is een nuttige bevinding, maar het is niet dezelfde bewering als het lezen van de binnenste header. Geef aan welke van de twee je werkelijk hebt.