NAT simètric i VPN: mesureu el mapatge, no l’etiqueta

Un fil de suport acaba amb el veredicte «NAT simètric, la VPN no funcionarà aquí», i després el client es reinstal·la tres vegades sense cap motiu. L’etiqueta fa mal perquè respon una pregunta que ningú no ha fet. Un client que es connecta cap a fora a un servidor fix crea un mapatge en el moment que envia el primer paquet, i la resposta es deixa tornar segons unes regles que gairebé totes les xarxes implementen. El que el mapatge dependent de l’extrem complica de debò és que dos iguals intentin arribar-se alhora, i això és una prova diferent.

Dues preguntes s’amaguen darrere d’una etiqueta

La primera pregunta és si un amfitrió darrere d’aquesta xarxa pot obrir una sessió cap a una adreça pública i un port coneguts. Per a un client de túnel aquest és el cas normal, i la resposta és gairebé sempre sí. L’encaminador enregistra l’origen intern, assigna un port extern i deixa passar la resposta perquè pertany a una sessió que ha començat des de dins.

La segona pregunta és si dos amfitrions darrere de xarxes diferents poden descobrir un camí compartit i enviar-se coses sense cap servidor al mig. Això depèn de com cada xarxa assigna aquests ports externs, i és l’únic lloc on el comportament del mapatge té importància.

Confondre les dues coses produeix el diagnòstic equivocat clàssic: una funció d’igual a igual falla, algú executa una prova de tipus de NAT, veu la pitjor categoria i conclou que el túnel corrent tampoc no pot funcionar. El túnel no era mai allò que fallava.

El mapatge i el filtratge són propietats separades

La terminologia de l’RFC és més precisa que els noms que fan servir els fabricants, i val la pena portar-la al tiquet perquè resol discussions. El mapatge és com s’assigna el port extern. El filtratge és quins paquets entrants es deixen passar. Una xarxa pot ser estricta en un i liberal en l’altre, i la combinació és el que un protocol d’igual a igual ha de sobreviure.

La tercera fila és el que la majoria d’encaminadors de consum i operadors mòbils volen dir amb simètric. Fixeu-vos que l’etiqueta només descriu l’assignació. Una xarxa amb aquest mapatge i un filtratge liberal encara pot acceptar paquets entrants al port que acaba d’assignar, i per això el foradat de forats funciona en algunes i falla en altres.

El filtratge té els seus tres casos i el seu nom per a cadascun. Escriure «NAT simètric» en un tiquet quan vols dir «filtratge dependent d’adreça i port» envia la persona següent al capítol equivocat del manual. Els dos es comporten de manera diferent sota prova, així que l’error no és acadèmic.

Mesureu el mapatge en lloc de posar-li nom

Podeu observar el port assignat directament des del costat servidor de qualsevol servei UDP que controleu. Engegueu una captura a l’amfitrió públic, envieu des del client i llegiu el port d’origen amb què ha arribat el paquet:

sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820

La línia de l’extrem és la més útil de les tres, perquè WireGuard enregistra l’última adreça i el port que ha rebut de cada igual. Compareu aquest port amb el que el client creu que fa servir. Diferiran sempre que hi hagi qualsevol traducció, i la pregunta important és si el valor es manté estable.

Repetiu l’observació contra un segon port de destí o un segon servidor i torneu a comparar. Si el port extern canvia per destí, el mapatge depèn de l’adreça i del port. Si es manté igual, la xarxa us dona un sol mapatge i el descobriment té una oportunitat.

Les eines basades en STUN informen de la mateixa classificació en un sol pas, i es poden fer servir quan la xarxa permet UDP de sortida cap a un servidor STUN públic. Quan no ho permet, el mètode de captura anterior encara funciona i no requereix res més que un amfitrió que ja controleu.

Trieu una solució que encaixi amb la fallada

Si la funció que falla és d’igual a igual, les respostes admeses són un relé, un servei de trobada al qual puguin arribar tots dos iguals, o una topologia diferent. TURN existeix exactament per a això, i un producte que inclou el seu propi relé us està dient que espera que algunes xarxes siguin hostils.

Si la funció que falla és un túnel corrent, el comportament del mapatge no és el vostre problema i res de l’anterior no s’aplica. Comproveu que el client envia de debò, que el servidor veu el paquet i que la resposta torna. Aquesta seqüència són tres observacions i no exigeix saber res sobre la categoria NAT de l’encaminador.

El que no funciona és escampar canvis de port local fins que alguna cosa es connecta. Canviar el port d’origen del client no canvia com la xarxa assigna els mapatges. Un èxit casual al cinquè intent és un fals positiu, i es citarà com a solució durant mesos.

Enregistreu l’arquitectura, no el veredicte

Una nota útil diu quin protocol, en quina direcció comença la sessió, si hi ha un relé al camí i què s’ha observat al cable. «NAT simètric, no funciona» és inutilitzable, perquè alhora és equivocat sobre el túnel i no informa sobre el camí entre iguals.

Incloeu l’estabilitat del port mesurada i el comportament del filtratge si els heu provat. Aquests dos fets permeten a algú altre predir si una funció nova funcionarà en aquella xarxa sense repetir tota la investigació. També envelleixen millor que una categoria de fabricant que vol dir una cosa lleugerament diferent a cada pàgina d’ajuda.

Finalment, tingueu a mà la terminologia de l’RFC 4787 quan ho escriviu. Fer servir els termes precisos costa una frase i evita que el lector següent repeteixi el mateix diagnòstic equivocat, que és tot el sentit d’escriure la nota.