Bloqueja l'ISP l'UDP, o és l'aplicació dins del túnel?

Algú informa que la VPN «bloqueja l'UDP», i la frase amaga dues afirmacions completament diferents. Una tracta del transport que pot veure la xarxa d'accés, l'altra dels paquets d'una aplicació després de desxifrar-se dins del túnel. Un túnel xifrat es pot filtrar des de fora sense cap clau, i una aplicació UDP interna pot fallar per motius que no tenen res a veure amb el filtratge. Decidiu quina afirmació esteu provant abans de recollir proves.

Dues capçaleres, una paraula

En un desplegament d'IPsec amb NAT-traversal, el paquet exterior és UDP adreçat entre els dos extrems de la VPN, normalment al port 4500. A dins, la càrrega xifrada transporta tot el que reenvia el túnel, que al seu torn pot ser TCP o UDP. La paraula UDP apareix, doncs, dues vegades amb significats i visibilitat diferents.

Una xarxa intermèdia veu la capçalera exterior i res de la interna. Pot permetre, modelar o descartar el flux exterior, i no cal desxifrar res per fer-ho. Aquesta asimetria és tota la raó per la qual les dues afirmacions es confonen: la mateixa paraula descriu el que filtra la xarxa i el que envia l'aplicació. Escriviu la capa al costat de la paraula sempre que registreu una troballa, i la confusió gairebé desapareix.

La capçalera interna només es fa visible a l'extrem receptor, després del desxifratge. A partir d'aquest punt el paquet es reenvia com qualsevol altre, subjecte a rutes, política i filtratge propi de l'extrem. Són decisions separades preses per aparells diferents.

Què pot veure encara la xarxa

El xifratge amaga la càrrega i la capçalera de transport interna, no el fet que existeixi un flux. Les adreces dels extrems, els ports, les mides dels paquets i el temps continuen visibles, i això n'hi ha prou per classificar el trànsit heurísticament o per bloquejar una destinació concreta.

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

La primera captura mostra el flux exterior a la interfície física, i la segona mostra el flux interior a la interfície del túnel. Executar les dues alhora respon la pregunta directament: si el flux exterior existeix i l'interior no, l'aplicació no ha enviat mai res al túnel. Si tots dos existeixen i no torna res, el problema és més enllà del túnel, a la destinació o al camí de tornada.

RFC 3948 defineix l'encapsulament UDP exterior, i l'especificació d'ESP defineix la disposició protegida a dins. Cap dels dos documents promet que una xarxa d'accés deixi passar el flux exterior, i per això val la pena fer una prova d'abastabilitat sobre la tupla exterior abans de qualsevol teoria sobre la interna. Una tupla exterior bloquejada produeix un túnel que no es forma mai, no un túnel que es forma i després perd una aplicació.

Per què una aplicació UDP falla dins d'un túnel que funciona

Un túnel que transporta una aplicació web però no una aplicació UDP té diverses explicacions plausibles, i el filtratge del protocol intern per part de l'ISP no és la primera. La més habitual és la cobertura: les dues aplicacions no entren totes dues al mateix túnel, perquè falta la ruta cap a la destinació UDP o les regles de túnel dividit del client l'exclouen.

La segona és l'extrem. Un servidor VPN que permet una llista de protocols, un tallafoc de destinació o un servei que no escolta mai al port esperat produiran tots un temps d'espera que sembla idèntic a un bloqueig de xarxa.

La tercera és la mida del paquet. Les aplicacions UDP sovint envien datagrames més grans que una petició web, i l'encapsulament redueix l'MTU utilitzable, així que després d'un handshake correcte pot venir el silenci a la primera càrrega de mida completa. Aquest patró és fàcil de malinterpretar com un bloqueig, perquè els paquets petits passen i els grans desapareixen. Una sonda ràpida d'MTU ho resol en menys d'un minut, i la resposta sol ser una càrrega més petita o un MSS corregit, no un filtre de xarxa.

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

La primera ordre comprova si un paquet gran sobreviu al camí amb la fragmentació desactivada, cosa que exposa ràpidament un problema d'MTU. La segona envia un flux UDP petit i limitat i informa de pèrdues i jitter. Un flux que comença i després s'atura apunta a la mida, no a un bloqueig.

Informeu de la capa, no del protocol

Escriviu la troballa en una de tres formes: ha fallat el lliurament exterior, ha fallat el reenviament intern o ha fallat l'aplicació. Cadascuna té un responsable diferent, i barrejar-les envia el tiquet a l'equip equivocat.

Canviar un port local no pot crear un receptor corresponent a l'altre extrem, així que una solució provisional al costat del client que sembla ajudar sol ser evidència que la destinació original era incorrecta. Igualment, un perfil alternatiu subministrat demostra alguna cosa sobre l'abastabilitat i res sobre si l'aplicació està ben configurada.

Manteniu la inferència separada de l'observació. L'anàlisi de trànsit pot suggerir què és un flux sense desxifrar-lo, i és una troballa útil, però no és la mateixa afirmació que llegir la capçalera interna. Digueu quina de les dues teniu realment.