Mitos do MTU na VPN: por que se encollen os teus paquetes e onde vai o espazo

Alguén che di que a VPN «perde paquetes por culpa do MTU», poñes o túnel en 1400 e a transferencia volve funcionar. Ese resultado parece un diagnóstico. Normalmente é unha coincidencia aritmética: escolliches un número o bastante pequeno para caber baixo un límite que nunca identificaches, e volverás atopar o mesmo límite na próxima rede cun orzamento distinto.

Dous mitos causan a maior parte disto. O primeiro é que o MTU da interface do túnel é o MTU da ruta. O segundo é que a encapsulación custa «unha cabeceira» e que PPPoE non custa nada que mereza contarse. Ambos son falsos de xeitos que fan que o número que escolliches pareza arbitrario cando en realidade está determinado.

Mito un: o MTU do túnel é o MTU da ruta

O valor que poñes nunha interface de túnel é unha promesa local sobre o paquete interno máis grande que a implementación entregará abaixo. A capacidade real da ruta é unha propiedade de cada enlace entre ti e o extremo remoto, e pode cambiar cando cambia unha ruta, cando unha conexión móbil fai un traspaso ou cando o tráfico colle outro emparellamento. Un 1500 configurado diche que construirá o teu host, non que transportará a rede.

O descubrimento do MTU de ruta existe para conciliar ambos e depende da retroalimentación. Con IPv4, un router que non pode reenviar un paquete de tamaño completo debería enviar unha mensaxe ICMP «fragmentation needed», e o emisor baixa a súa estimación. Con IPv6, o equivalente é unha mensaxe Packet Too Big e os routers non fragmentan en tránsito en absoluto. Cando esa retroalimentación se filtra, o emisor segue producindo paquetes que a ruta non pode transportar, e nada lle di por que.

Mito dous: a encapsulación custa unha cabeceira

Conta as capas externas con honestidade. Unha cabeceira IP externa son 20 bytes en IPv4 ou 40 en IPv6. A encapsulación UDP para atravesar NAT engade 8. O protocolo do túnel engade a súa propia cabeceira, un vector de inicialización ou nonce, recheo ata o límite de bloque ou aliñamento do cifrado, un tráiler e un valor de comprobación de integridade. Segundo o protocolo e o cifrado, o total sitúase comodamente en decenas de bytes antes de que o paquete interno sequera comece.

Despois resta outra vez as cabeceiras do propio paquete interno. Un segmento TCP dentro do túnel leva a súa propia cabeceira IP de 20 bytes e a súa cabeceira TCP de 20 bytes, e o MSS de TCP derívase do MTU, non da carga útil nominal do túnel. Por iso ping cunha carga menor pode ter éxito mentres unha transferencia de ficheiros se atasca: as ferramentas proban cousas distintas e só unha delas exercita un segmento TCP de tamaño completo.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

O primeiro comando informa do MTU configurado do túnel. As dúas probas envían unha carga de 1472 bytes, que con 28 bytes de cabeceiras IPv4 e ICMP é un paquete de 1500 bytes, e despois unha menor. Se a proba grande falla por completo e a pequena ten éxito, tes un fallo dependente do tamaño e non un problema xeral de encamiñamento.

Mito tres: PPPoE aínda che dá 1500 limpos

Unha ligazón de acceso PPPoE convencional non transporta un paquete IP de 1500 bytes. A cabeceira PPPoE máis o campo de protocolo PPP consomen 8 bytes dentro da trama Ethernet, o que deixa 1492 para o paquete IP. Ese é o límite tradicional descrito no RFC 2516. Se executas unha VPN sobre esa ligazón, a sobrecarga do túnel sae deses 1492, non de 1500.

O RFC 4638 define unha forma de negociar unha carga PPP maior cando tanto o concentrador de acceso como o equipo do cliente o admiten, por iso «esta conexión usa PPPoE» por si só non demostra un número concreto. Un axuste local non pode facer que un dispositivo intermedio acepte un paquete para o que nunca se configurou, así que a pregunta útil é que negociou realmente a ligazón, non que di a etiqueta.

Por que o fallo parece selectivo

Que as peticións pequenas teñan éxito e as transferencias grandes se ataquen é a sinatura clásica dun buraco negro do MTU de ruta. O aperto de mans, a consulta DNS e a chamada á API caben todos; a transferencia masiva produce segmentos de tamaño completo que morren nun enlace, e a mensaxe ICMP que debía informar do problema nunca chega. A conexión parece ben e a descarga colga, o que leva a xente a mirar o servidor en vez da ruta.

Un segundo erro relacionado é confundir tres números: o MTU da interface, o MSS de TCP e o axuste de fragmentación ou recheo do propio protocolo. O pinzamento de MSS nun router reescribe o MSS anunciado para que o emisor constrúa segmentos máis pequenos; non cambia o MTU do túnel nin axuda ao tráfico UDP. Poñer o mesmo número aos tres porque parecen relacionados é como unha configuración que funciona se rompe por un cambio benintencionado.

Que cambiar e en que orde

Comeza con probas. Confirma coas probas anteriores que o fallo depende do tamaño e despois atopa o tamaño máis pequeno que pasa e o máis grande que falla. Comproba o MTU real da ligazón de acceso antes de culpar o túnel; unha ligazón PPPoE limita o orzamento antes de que a VPN o toque. Anota os valores orixinais para que o cambio se poida desfacer.

Despois aplica o axuste máis pequeno que documente o cliente. Moitos clientes ofrecen un MTU de túnel máis unha opción de arranxo de MSS, e a opción de MSS adoita ser a mellor panca para TCP porque chega ao emisor sen reducir cada paquete. Volve probar o mesmo destino e a mesma transferencia, e anota os números cos que quedaches. Un valor de túnel que funciona nunha rede de acceso non é unha constante universal, e o próximo sitio terá o seu propio orzamento.