MTU per rûte op Linux: trije gruttebehearders, ien rûte
Yngongs-MTU, rûte-MTU en de MSS-beheining wurkje op ferskillende lagen. Keppelje in budzjet oan 'e rûte dy't de syktocht wint, en hâld de wiziging weromdraaiber.
Trije ynstellings op in Linux-klant klinke allegear as „meitsje de pakketten lytser“, en se wurkje op ferskillende lagen. De yngongs-MTU beheint elk pakket dat it apparaat stjoert. In rûte-MTU beheint pakketten dy't dy rûte brûke, wat faaks is wat jo eins wolle foar ien VPN-bestimming. De TCP MSS-beheining feroaret wat de twa einen ôfprate, en it docht neat foar UDP.
Trije behearders dy't op deselde knop lykje
Set se njonken elkoar foar't jo kieze, want de ferkearde rige kieze ferklearret it measte fan it advys dat net wurket:
| 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 |
De Ethernet-MTU ferleegje foar de hiele masine is de grove ferzje fan dizze oplossing. It wurket, en it bestraftet ek elke oare applikaasje op 'e host, ek dy't har paden goed wiene. In wearde per rûte drukt deselde bedoeling út sûnder de bykommende kosten.
De ferliking jildt allinnich foar ferkear dat de host sels generearret. In pakket trochstjoere foar in oare klant omfettet syn eigen paad en it bûtenste budzjet fan 'e tunnel, en in rûtemetryk op dizze host rikket net oer dy grins.
Keppelje it budzjet oan 'e rûte dy't de syktocht wint
In yllustratyf IPv4-rûterekord sjocht der sa út:
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 1380Lês it rekord as in beskriuwing fan bedoeling, net as in wearde om te plakken. It foarheaksel, it apparaat en de foarkarsboarne moatte by de echte konfiguraasje passe, en it getal moat út bewiis oer it ynkapslele paad komme, net út in blogberjocht. De rûte-MTU beheint it binnenste IP-pakket, wat net itselde is as in TCP-lading fan 1380 bytes of in fersifere bûtenste pakket fan 1380 bytes.
Sjoch wêr't de syktocht eins oplost foar't jo wat tafoegje. In host mei beliedsregels kin in opjûn bestimming troch in oare tabel as main stjoere, en in metryk dy't allinnich yn main bestiet, is ûnsichtber foar dat fersyk. Ferlykje ip -4 route show table all mei it antwurd fan ip route get, ynklusyf de mark- of nammeromtekst as de regels se brûke. As de twa it net iens binne, is de tabel dy't antwurde dejinge dy't de metryk nedich hat, net dy't der oarderliker útsjocht.
mtu is net mtu lock
Standert kin de kearn it paad-MTU noch bywurkje út ICMP-feedback, dêr is paad-MTU-ûntdekking foar. It tafoegjen fan lock stoppet dat. It is in oare beslissing, net in sterker manier om itselde getal te bewarjen, en foar IPv4 feroaret it de dokumintearre behanneling fan 'e don't-fragment-bit.
Beskoattelje is ridlik as jo it paad mjitten hawwe en wolle dat de wearde stean bliuwt wat der ek komt. It is in minne standert as it netwurk legitime grutte-feedback stjoert, want de kearn kin net mear oanpasse en it falen ferpleatst him nei in oar symptoom.
As ICMP earne op it paad filtere wurdt, reparearret gjin rûte-ynstelling dat. De reparaasje heart by it filter, en in lytsere MTU is in wurkomgong dy't de echte flater ferberget oant it folgjende paad feroaret.
Tunnelsoftware foeget syn eigen gruttebehearders ta
OpenVPN- mssfix past de TCP-segmintgrutte oan foar syn dokumintearre UDP-tunnelgefal. It wurket op it TCP-petear, dus it is gjin oare stavering fan 'e rûte-MTU fan it bestjoeringssysteem, en it kin in UDP-tsjinst dy't de ôfspraak negearret net helpe.
Stapelje gjin rûte-MTU, in wiziging fan 'e yngongs-MTU en in MSS-beheining yn ien wizigingsfinster. As it probleem ferdwynt, witte jo net hokker fan belang wie, en dy't jo hâlde sille ferkear jierren beheine sûnder in reden dy't immen ûnthâldt.
Meitsje it weromdraaiber, bewiis it dan
De echte eigner fan 'e rûte beslút oft de wiziging in werferbining oerlibbet. In VPN-klant dy't de rûte dynamysk ynstallearret, sil it meastentiids opnij bouwe sûnder jo metryk, en in hânmjittige ip route add sjocht der dan út as in reparaasje dy't in dei letter mislearre. Set de wearde yn 'e konfiguraasje fan 'e behearder, en as jo in tydlik eksperimint nedich hawwe, skriuw dan earst de oarspronklike rûte op.
Test mei in nije ferbining dy't de bewurking útfiert dy't fêst siet, en befêstigje dan dat de bedoelde partikuliere rûte noch altyd wint en net-relatearre bestimmingen ûnferoare binne. Ferbynje de tunnel opnij en lês de rûte wer, want in wearde dy't by werferbining ferdwynt is gjin reparaasje.
As it bewiis de wiziging net stipet, ferwiderje de oerskriuwing fia syn behearder en restaurearje de oarspronklike rûte-attributen ynstee fan de rûte te wiskjen. Skriuw dan op wat jo mjitten hawwe, op hokker paad, sadat de folgjende persoan in echte ferbettering ûnderskiede kin fan in eksperimint dat rinne litten is.