OpenVPN sobre PPPoE: baixar link-mtu, tun-mtu ou mssfix?

Os pings responden, o DNS resolve e toda páxina que precisa un segmento de tamaño completo queda colgada. Nunha conexión que engade a súa propia encapsulación, a ruta perde silenciosamente unhas poucas ducias de bytes de orzamento, e un perfil escrito para Ethernet limpo segue pedindo paquetes que a liña non pode transportar. A conexión non é lenta; está descartando exactamente os paquetes que importan.

Tres opcións poden solucionar isto, e actúan en capas diferentes. Elixir a incorrecta ou non fai nada ou volve o túnel fráxil dun xeito novo, así que a decisión comeza polo que a ruta admite de verdade.

Tres controis, tres capas distintas

link-mtu é o orzamento externo: a carga cifrada máis a cabeceira de OpenVPN, a cabeceira UDP e a cabeceira IP externa. Describe o que sae da máquina, e por iso é o número que limita a ruta física.

tun-mtu é o orzamento interno: a interface que ve o seu tráfico. É maior que o que a ruta pode transportar exactamente na sobrecarga do túnel, e OpenVPN normalmente dedúceo en vez de obrigarlle a fixalo.

mssfix é un mecanismo completamente distinto. Reescribe o tamaño máximo de segmento anunciado durante as negociacións TCP, para que os pares TCP elixan segmentos que encaixen tras a encapsulación. Non cambia a MTU da interface e non ten ningún efecto sobre UDP.

Se fixa link-mtu explicitamente, OpenVPN resta a súa propia sobrecarga para deducir a MTU interna. Esa sobrecarga non é unha constante fixa; depende do cifrado e da autenticación, e por iso un valor copiado dun foro pode ser erróneo noutro perfil. Fixar tanto link-mtu como tun-mtu entrega ao cliente dúas instrucións contraditorias.

Mida a ruta antes de escoller calquera número

Mida desde a interface física, non desde dentro do túnel, e lembre que ping informa da carga útil, non do tamaño do paquete. Engada 28 bytes para as cabeceiras IPv4 e ICMP antes de comparar a carga cunha trama de 1500 bytes, e teña presente esa corrección cando un par informe dun número distinto.

Nun cliente Linux, ping -M do -s 1472 prohibe a fragmentación e falla se o paquete é demasiado grande. Baixe a carga útil ata que pase e logo engada 28 para obter a MTU da ruta. PPPoE custa 8 bytes, así que 1492 é normal en DSL. DS-Lite e algunhas rutas móbiles custan 40 ou máis, e a resposta adoita ser inferior ao que suxire a velocidade nominal da conexión.

Se todos os tamaños de ping teñen éxito pero as transferencias grandes seguen atascando, sospeite dun burato negro en lugar dun simple límite de tamaño. Unha mensaxe ICMP de fragmentación necesaria está a ser filtrada nalgún punto da ruta, así que o emisor nunca aprende a reducir, e só os fluxos que precisan un segmento grande o notan.

Limite TCP primeiro, encolla o túnel despois

As negociacións TCP son o único que toca mssfix, o que adoita convertelo no control menos invasivo para probar primeiro. Fíxeo un pouco por debaixo do orzamento real da ruta, envíe o mesmo valor desde o servidor para que ambos os extremos coincidan, e volva probar unha descarga grande. Se o atasco desaparece, o problema era o tamaño de segmento TCP e non fai falta cambiar nada máis.

Baixe a MTU interna cando o tráfico afectado non sexa TCP. Un servizo UDP, un túnel dentro do túnel ou unha aplicación que envía datagramas de tamaño completo seguirán fallando tras un límite de MSS porque nada reescribe o tamaño dos seus paquetes. Reduza tun-mtu para ese caso, ou fixe link-mtu e deixe que o cliente deduza o valor interno, pero nunca ambos.

Non recorra á antiga opción de fragmentación. Dividía paquetes dentro do túnel, engadía sobrecarga e quedou obsoleta por boas razóns; o OpenVPN moderno espera que a ruta se describa con precisión.

Por que as sondas pequenas seguen funcionando

As consultas DNS, os ecos ICMP e as negociacións TCP están moi por debaixo do tamaño que falla. O túnel parece san en calquera proba rápida mentres as negociacións TLS e as respostas HTTP fallan en silencio. Esa combinación, un traceroute que funciona e un navegador que se colga na primeira resposta grande, é o sinal que hai que buscar. Recorra a unha sonda de tamaño completo antes de recorrer a un perfil novo.

Verifique co tráfico que fallou. Cargue unha páxina grande, envíe un datagrama UDP de tamaño completo se ese é o servizo afectado, e repita desde un segundo cliente noutra conexión. Anote a MTU de ruta medida e o valor que escolleu, porque a seguinte persoa que toque o perfil tratará o número como arbitrario doutro xeito.

Nunca baixe a MTU interna por debaixo de 1280 cando IPv6 vai sobre o túnel, porque ese é o mínimo que toda conexión IPv6 debe transportar. Unha MTU menor é un feito sobre a ruta, non un axuste de rendemento que se calibra a ollo.