Probar un problema de MTU sospeitoso na VPN sen adiviñar valores

Probar unha lista de valores de MTU de internet ata que un pareza máis rápido non é unha proba, é unha busca sen regra de parada. O método que funciona cambia unha condición de tamaño controlada e compara o resultado co mesmo camiño. Comeza por un fallo repetible e inocuo e mantén a configuración que funciona e que che permite desfacer o experimento. Todo o que segue presupón esa disciplina, porque sen ela acabas cun número que non podes defender.

Fixa o camiño antes de cambiar un número

Anota o dispositivo, a ligazón de acceso, o protocolo do túnel, o punto final, o destino e a familia de enderezos antes de tocar un axuste. Eses seis datos son o camiño, e unha sonda dirixida a outro camiño mide outro problema. Tamén fan que o resultado sexa reproducible, e iso é o que separa unha proba dunha tarde a fedellar. Mantén a nota xunto ao terminal en lugar de na cabeza.

Comeza pola proba máis estreita que tes autorización para executar. Un cambio no lado do servidor chega a todos os usuarios dese punto final, así que pertence ao final da investigación, non ao principio.

Sondea cun tamaño que controles

En Linux a sonda parécese a ping -M do -s 1400 host, e en Windows a ping -f -l 1400 host. En ambos os casos estás a fixar a carga útil e non o tamaño do paquete, porque as cabeceiras IP e ICMP engádense por riba.

Le a documentación do sistema que tes diante en lugar de copiar un indicador dunha publicación de foro. Escolle un destino que controles, para que unha resposta ausente sexa un sinal e non un misterio. Rexistra o comando exacto e o tamaño exacto na mesma nota que o camiño. Un resultado sen tamaño é unha anécdota. Se cambias dúas cousas nunha soa execución, non saberás cal delas produciu o resultado.

Unha sonda fallida non demostra un límite de MTU

Unha sonda descartada pode significar filtrado ICMP e non un límite de tamaño, e ese erro leva a xente a axustar un valor que nunca foi o problema. Compara a sonda coa aplicación real, e cunha mensaxe de erro relacionada co tamaño ou unha captura acoutada, antes de cambiar nada. Os pings pequenos correctos tampouco demostran nada, porque poden quedar comodamente por debaixo do límite. Dúas observacións independentes son o mínimo antes de mover unha configuración.

Se a aplicación falla mentres a sonda ten éxito, tes evidencia de que non é un límite de tamaño simple nese camiño. Anótao, porque elimina toda unha rama de cambios candidatos.

Axusta un só parámetro que o cliente xa admite

Cambia o axuste que o cliente documenta para este protocolo e deixa intactos o punto final e o destino, ou terás cambiado dúas cousas á vez. Un clamp de MSS de TCP non cobre toda a carga UDP, e por iso un navegador que comeza a funcionar pode deixar o protocolo do túnel exactamente igual de roto. IPv4 e IPv6 son camiños separados aquí, porque as cabeceiras difiren antes de que o faga calquera encamiñamento.

Proba ambas as familias se publicas ambas, xa que un resultado dunha non di nada sobre a outra. Un valor que funcionou neste camiño esta noite é un dato, non unha MTU para toda a VPN. Non o promovas a axuste global pola forza dunha soa transferencia exitosa. Anota o valor xunto ao camiño do que saíu.

Desfacer, verificar e anotalo

Devolve o valor orixinal se a comparación non respalda a hipótese. Comproba que un xestor de rede non gardase unha anulación persistente noutro sitio, porque así é como un experimento se converte en política. Volve conectarte e exercita aplicacións normais, non só a que estabas probando. Despois rexistra o síntoma, o camiño efectivo, o valor antigo e o novo e ata que punto foi repetible o resultado.

Conserva ese rexistro coa solicitude de cambio antes de que alguén amplíe o cambio. O mecanismo de descubrimento de MTU do camiño na RFC 1191 explica por que un valor menor pode rescatar un camiño e non facer nada por outro, e unha lista de números non substitúe ese modelo. A proba remata cando podes nomear o camiño, o tamaño, a observación e o valor que restauraches.