Túneles VPN aniñados: por que o interior atáscase con paquetes grandes

O DNS resólvese, a sesión SSH mantense e entón unha subida grande conxélase mentres un ping ao mesmo host segue respondendo. Esa división apunta ao tamaño do paquete e non a un túnel roto. Os túneles aniñados chegan a iso con tamaños que ningún dos dous alcanzaría por separado. A sesión interior está ben; o que pasa é que se lle entregan paquetes que xa non caben.

A onde vai realmente a MTU da ruta

Cada encapsulación gasta bytes antes de que a capa seguinte teña a súa quenda. Unha ruta Ethernet ofrece 1500 bytes ao paquete exterior, e o túnel exterior toma a súa parte antes de que se poida dirixir nada dentro. Un único valor de sobrecarga estimado estará mal exactamente na cantidade que importa.

Enumere as capas por orde: ruta de acceso, transporte exterior, túnel exterior, transporte interior, túnel interior, aplicación. Conte cada cabeceira unha vez e manteña UDP separado da cabeceira e da etiqueta propias do túnel.

Dúas capas de WireGuard, contadas unha vez

Tome unha ruta de acceso IPv4 cun túnel WireGuard dentro doutro. A capa exterior custa 20 bytes de IPv4, 8 de UDP e 32 pola cabeceira de datos de WireGuard máis a súa etiqueta de autenticación. Dentro diso, o túnel interior necesita a súa propia cabeceira IPv4 de 20 bytes e unha cabeceira UDP de 8 bytes antes dos seus segundos 32 bytes de sobrecarga de WireGuard. O que queda aloxa unha cabeceira IPv4, unha cabeceira TCP e os datos. Unha ruta exterior IPv6 custa 40 en lugar de 20 e deixa 1320.

A aritmética aterra en 1340 bytes. Unha soa capa coas mesmas regras deixa 1400 para a carga útil TCP, que é 1500 menos 20, 8, 32, 20 e 20, e a diferenza de 60 bytes é exactamente a encapsulación interior que engade o segundo túnel.

Aplique 1400 a unha ruta aniñada e ao túnel interior fáltanlle 60 bytes, de forma invisible ata que un paquete sexa o bastante grande como para necesitalos. O recheo e a opción de fragmentación propia dun protocolo volven mover as cifras, así que confíe na táboa.

MTU, MSS e fragmentación actúan en lugares distintos

A MTU da interface limita o que a interface emitirá, mentres que o clamping de MSS de TCP cambia o que un par TCP está disposto a enviar. O clamping arranxa as sesións TCP e non fai nada por un datagrama UDP grande, que é como unha solución parece exitosa para unha aplicación e falla en silencio para a seguinte. A opción de fragmentación propia dun protocolo é unha terceira panca cos seus propios fallos. A MTU da interface é o primeiro movemento habitual e o máis burdo.

Os túneles con ponte e os encamiñados transportan tramas distintas, así que as cifras doutra implantación raramente se trasladan. O descubrimento de MTU de ruta, descrito en RFC 8201, só axuda mentres se deixan pasar as mensaxes ICMP das que depende.

Atopar a capa que queda curta

Verifique cada túnel por separado antes de aniñalos, se os requisitos permiten unha comparación. Unha sonda de tamaño fixo resólveo: ping -M do -s 1472 -c 3 10.8.0.1 envía un paquete IPv4 completo de 1500 bytes dentro desa capa. Engada a segunda capa e repita a mesma sonda, para que calquera fallo pertenza a un cambio coñecido.

Cando unha transferencia se atasca, cambie un parámetro documentado á vez e anote o tamaño que falla. Comprobe tamén a ruta de volta, porque a recursión de rutas aniñada pode imitar un problema de tamaño de paquete coa suficiente fidelidade como para custar unha tarde. Unha resposta ICMP filtrada pode ocultar o límite real, así que a sonda importa máis que o razoamento.

Escriba o orzamento onde o atope a seguinte persoa

Unha táboa cunha fila por capa sobrevive a unha regra mnemotécnica. Téñaa xunto ao diagrama do túnel para que ninguén refaga a aritmética baixo presión.

Máis túneles significan máis dependencias, así que un plan de reversión gaña o seu sitio xunto ao orzamento. Se as cifras aínda non cadran, mida a ruta en lugar de volver adiviñar. O obxectivo é unha cifra que poida defender, non recordar.