OpenVPN avisa dun uso incoherente do MTU: que compara o aviso

Ese aviso informa dunha comparación entre as opcións dos pares, non dunha medición da ruta entre eles. A xente leuno como «o MTU está mal» e cambia o número ata que a liña desaparece. Iso trata unha comparación de configuración como unha medición de rede, e a miúdo empeora o túnel mentres deixa o rexistro máis silencioso. O primeiro paso útil é decidir cal deses dous problemas ten realmente.

Tres condicións deciden a resposta: que comparan os pares, se o valor é herdado e que síntoma existe máis aló do aviso.

O aviso compara opcións, non paquetes

Os pares de OpenVPN intercambian as súas cadeas de opcións durante o saúdo e compáranas como parte da comprobación de coherencia de opcións. Cando un lado informa de link-mtu ou tun-mtu de forma distinta ao outro, a discrepancia rexístrase con ambos valores. Ese intercambio nunca envía un paquete grande para ver que pasa, así que o aviso describe configuración, non capacidade. Un túnel pode transportar tráfico de tamaño completo e aínda así imprimilo, ou fallar con paquetes grandes e non imprimir nada.

Conserve o aviso completo cos seus valores local e remoto. O par é a proba; o número solto que recorda, non.

Por que link-mtu está obsoleto

OpenVPN 2.6 marca link-mtu como obsoleto porque as cabeceiras variables e os cifrados negociados fan que un valor de enlace fixo non sexa fiable. A opción supuña unha disposición de paquete que o protocolo xa non garante, así que un perfil antigo cun link-mtu literal describe unha intención que o código actual non pode cumprir. Copiar ese número a un perfil novo propaga unha suposición obsoleta. Lérao como parte da historia do perfil antigo, non como unha recomendación.

A comprobación de coherencia tamén ten un valor OCC opcional ligado a tun-mtu, que cambia que se compara sen cambiar que transporta a rede. Fixalo non fai que caiban paquetes maiores.

Repare o perfil antes de probar a ruta

Corrixa unha discrepancia non intencionada a través de quen posúe os perfís, e lembre que un cambio no servidor afecta todos os clientes. Edite o perfil que a instancia carga realmente, non unha exportación que está nun cartafol de descargas. Despois reconecte un cliente de proba e anote que aviso sobrevive. Se a mensaxe cambia de forma en vez de desaparecer, está comparando opcións distintas das que cre.

Un servidor compartido necesita que se revise o seu inventario de clientes antes de mover un valor global, porque o valor que serve a un sitio pode romper outro.

Despois probe o síntoma que ten de verdade

Se as transferencias grandes se atascan mentres as peticións pequenas funcionan, mida o tamaño de paquete contra un destino controlado. Unha sonda que fixa o bit de non fragmentar e aumenta o tamaño da carga atopa o MTU utilizable da ruta moito máis fiablemente que un ping que simplemente acerta. Inclúa a aplicación que falla na proba: un tempo de espera ICMP pode reflectir filtrado, e un ping pequeno exitoso non di nada sobre un paquete de aplicación de tamaño completo.

mssfix limita o MSS anunciado para as sesións TCP dentro do túnel, o que axuda a TCP e non fai nada por unha carga UDP interna. A fragmentación e o offload teñen as súas propias condicións de compatibilidade. Escolla un mecanismo para o problema demostrado en lugar de cambiar varios á vez para silenciar unha liña do rexistro.

Conserve os valores efectivos co resultado

Anote os valores efectivos orixinais e corrixidos xunto ao resultado dunha transferencia real. Ese emparellamento é o que separa unha opción de perfil obsoleta dun problema de MTU na ruta que existe de forma independente. Sen el, o seguinte lector ve un aviso que desapareceu e supón que a rede cambiou.

Suprimir a comprobación de coherencia non concilia nada. Elimina a observación e deixa ambas configuracións como estaban.