MTU per ruta a Linux: tres controls de mida, una ruta
La MTU de la interfície, la MTU de la ruta i el límit MSS actuen en capes diferents. Fixeu un pressupost a la ruta que guanya la cerca i manteniu el canvi reversible.
Tres ajustos en un client Linux sonen tots a «fes els paquets més petits» i actuen en capes diferents. La MTU de la interfície limita cada paquet que envia el dispositiu. La MTU d'una ruta limita els paquets que fan servir aquesta ruta, que sovint és el que realment voleu per a una destinació VPN. El límit TCP MSS canvia el que negocien els dos extrems i no fa res per a UDP.
Tres controls que semblen el mateix botó
Poseu-los costat a costat abans de triar, perquè triar la fila equivocada explica la majoria dels consells que no funcionen:
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
Baixar la MTU d'Ethernet per a tota la màquina és la versió grollera d'aquesta solució. Funciona, i també penalitza qualsevol altra aplicació de l'amfitrió, incloses les que tenien camins correctes. Un valor per ruta expressa la mateixa intenció sense el cost col·lateral.
La comparació només val per al trànsit que genera l'amfitrió. Reenviar un paquet per a un altre client implica el camí propi d'aquest client i el pressupost exterior del túnel, i una mètrica de ruta en aquest amfitrió no arriba més enllà d'aquesta frontera.
Fixeu el pressupost a la ruta que guanya la cerca
Un registre il·lustratiu de ruta IPv4 té aquest aspecte:
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380Llegiu el registre com una descripció d'intenció, no com un valor per enganxar. El prefix, el dispositiu i la font preferida han de coincidir amb la configuració real, i el número ha de venir d'evidència sobre el camí encapsulat, no d'una entrada de blog. La MTU de la ruta limita el paquet IP interior, que no és el mateix que una càrrega TCP de 1380 octets ni un paquet exterior xifrat de 1380 octets.
Mireu on es resol realment la cerca abans d'afegir res. Un amfitrió amb regles de política pot encaminar una destinació donada per una taula diferent de main, i una mètrica que només existeix a main és invisible per a aquesta petició. Compareu ip -4 route show table all amb la resposta de ip route get, incloent-hi el context de marca o d'espai de noms quan les regles els fan servir. Si els dos no coincideixen, la taula que ha respost és la que necessita la mètrica, no la que sembla més ordenada.
mtu no és mtu lock
Per defecte el nucli encara pot actualitzar la MTU del camí a partir de la retroalimentació ICMP, que és per a què serveix el descobriment de MTU de camí. Afegir lock ho atura. És una decisió diferent, no una manera més forta de desar el mateix número, i per a IPv4 canvia el tractament documentat del bit de no fragmentació.
Bloquejar és raonable quan heu mesurat el camí i voleu que el valor es quedi fix passi el que passi. És un mal valor per defecte quan la xarxa envia retroalimentació legítima de mida, perquè el nucli ja no pot ajustar-se i la fallada es trasllada a un altre símptoma.
Si ICMP es filtra en algun lloc del camí, cap ajust de ruta ho arregla. La solució pertoca al filtre, i una MTU més petita és una solució improvisada que amaga la fallada real fins al proper canvi de camí.
El programari de túnel afegeix els seus propis controls de mida
OpenVPN- mssfix ajusta la mida dels segments TCP per al seu cas documentat de túnel UDP. Actua sobre la conversa TCP, així que no és una altra escriptura de la MTU de ruta del sistema operatiu, i no pot ajudar un servei UDP que ignora la negociació.
No apileu una MTU de ruta, un canvi de MTU d'interfície i un límit MSS en una sola finestra de canvis. Si el problema desapareix, no sabreu quin va importar, i els que conserveu limitaran el trànsit durant anys sense un motiu que algú recordi.
Feu-ho reversible i després demostreu-ho
El propietari real de la ruta decideix si el canvi sobreviu a una reconnexió. Un client VPN que instal·la la ruta dinàmicament normalment la reconstruirà sense la vostra mètrica, i una comanda ip route add manual aleshores sembla una solució que va fallar un dia després. Posa el valor a la configuració del gestor i, si necessiteu un experiment temporal, enregistreu primer la ruta original.
Proveu amb una connexió nova que faci l'operació que s'havia encallat, i després confirmeu que la ruta privada prevista encara guanya i que les destinacions no relacionades no han canviat. Torneu a connectar el túnel i llegiu la ruta, perquè un valor que desapareix en reconnectar no és una solució.
Si l'evidència no dona suport al canvi, traieu la substitució pel seu gestor i restaureu els atributs originals de la ruta en lloc d'esborrar-la. Després anoteu què heu mesurat i en quin camí, perquè la propera persona pugui distingir una millora real d'un experiment que s'ha deixat funcionant.