VPN-MTU-myten: wêrom't jo pakketten krimpe en wêr't de romte hinne giet

Immen fertelt jo dat de VPN "pakketten ferliest fanwegen MTU", jo sette de tunnel op 1400, en de oerdracht wurket wer. Dat resultaat fielt as in diagnoaze. It is meastal in tafal fan rekkenjen: jo hawwe in getal keazen dat lyts genôch is om ûnder in grin te passen dy't jo nea identifisearre hawwe, en jo sille deselde grin wer tsjinkomme op it folgjende netwurk mei in oar budzjet.

Twa myten feroarsaakje it measte hjirfan. De earste is dat de MTU fan 'e tunnelinterface de MTU fan it paad is. De twadde is dat enkapsulaasje "ien kop" kostet en dat PPPoE neat kostet dat it tellen wurdich is. Beide binne ferkeard op manieren dy't it getal dat jo kieze willekeurich lykje litte, wylst it eins bepaald is.

Myte ien: de MTU fan 'e tunnel is de MTU fan it paad

De wearde dy't jo op in tunnelinterface sette, is in pleatslike belofte oer it grutste ynterne pakket dat de ymplemintaasje nei ûnderen trochjout. De echte kapasiteit fan it paad is in eigenskip fan elke skeakel tusken jo en it fiere ein, en it kin feroarje as in rûte feroaret, as in mobile ferbining oerdroegen wurdt of as ferkear in oare peering nimt. In ynstelde 1500 fertelt jo wat jo host bouwe sil, net wat it netwurk drage sil.

Paad-MTU-ûntdekking bestiet om de beide te fermoedsoenjen, en it hinget fan weromkeppeling ôf. By IPv4 heart in router dy't in pakket fan folsleine grutte net trochstjoere kin in ICMP-berjocht "fragmentation needed" te stjoeren, en de ôfstjoerder ferleget syn skatting. By IPv6 is it ekwivalint in Packet Too Big-berjocht, en routers fragmintearje hielendal net ûnderweis. As dy weromkeppeling filtere wurdt, bliuwt de ôfstjoerder pakketten meitsjen dy't it paad net drage kin, en neat fertelt him wêrom.

Myte twa: enkapsulaasje kostet ien kop

Tel de bûtenste lagen earlik. In bûtenste IP-kop is 20 byte by IPv4 of 40 by IPv6. UDP-enkapsulaasje foar NAT-trochgong foeget 8 ta. It tunnelprotokol foeget syn eigen kop ta, in initialisaasjefektor of nonce, opfolle oant de blok- of rjochtingsgrins fan 'e syffer, in trailer en in yntegriteitskontrôlewearde. Ofhingje fan it protokol en de syffer leit it totaal noflik yn 'e tsientallen bytes foardat it ynterne pakket sels begjint.

Lûk dan wer ôf foar de eigen koppen fan it ynterne pakket. In TCP-segment yn 'e tunnel draacht syn eigen IP-kop fan 20 byte en TCP-kop fan 20 byte, en de MSS fan TCP wurdt ôflaat fan 'e MTU, net fan 'e nominale lading fan 'e tunnel. Dêrom kin ping mei in lytsere lading slagje wylst in bestânsferstjoering fêstrint: de helpmiddels testen ferskate dingen, en mar ien fan harren beoefenet in TCP-segment fan folsleine grutte.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

It earste kommando rapportearret de ynstelde tunnel-MTU. De twa probes stjoere in lading fan 1472 byte, wat mei 28 byte IPv4- en ICMP-koppen in pakket fan 1500 byte is, en dan in lytsere. As de grutte probe hielendal mislearret en de lytse slagget, hawwe jo in grutte-ôfhinklike fout en gjin algemien routingprobleem.

Myte trije: PPPoE jout jo noch altyd in skjinne 1500

In konvinsjonele PPPoE-toegongsskeakel draacht gjin IP-pakket fan 1500 byte. De PPPoE-kop plus it PPP-protokoljild nimme 8 byte yn it Ethernet-ramt, wat 1492 foar it IP-pakket oerlitten. Dat is de tradisjonele grin dy't yn RFC 2516 beskreaun wurdt. As jo in VPN oer sa'n skeakel rinne litte, komt de oerhead fan 'e tunnel út dy 1492, net út 1500.

RFC 4638 definiearret in manier om in gruttere PPP-lading te ûnderhanneljen as sawol de toegongskonsintrator as de apparatuer fan 'e klant it stipet, en dêrom bewiist "dizze ferbining brûkt PPPoE" allinnich gjin bepaald getal. In pleatslike ynstelling kin in tuskenapparaat net twinge in pakket te akseptearjen dêr't it nea foar konfigurearre is, dus de nuttige fraach is wat de skeakel eins ûnderhannele hat, net wat it label seit.

Wêrom't de fout selektiv liket

Lytse oanfragen dy't slagje en grutte oerdrachten dy't fêstrinne is de klassike hantekening fan in swart gat yn 'e paad-MTU. De hânskud, de DNS-fraach en de API-oprop passe allegear; de bulkoerdracht produsearret segminten fan folsleine grutte dy't by ien skeakel stjerre, en it ICMP-berjocht dat it probleem melde moatten hie, komt nea oan. De ferbining liket goed en de download hinget, wat minsken nei de tsjinner ynstee fan it paad sjen lit.

In twadde, besibbe flater is trije getallen trochinoar helje: de interface-MTU, de TCP-MSS en de eigen fragmintaasje- of opfolleynstelling fan it protokol. MSS-knelling op in router skriuwt de oankundige MSS oer sadat de ôfstjoerder lytsere segminten bout; it feroaret de tunnel-MTU net en helpt UDP-ferkear net. Alle trije itselde getal jaan om't se besibbe lykje, is hoe't in goedbedoelde feroaring in wurkjende opset brekt.

Wat te feroarjen, en yn hokker folchoarder

Begjin mei bewiis. Befêstigje mei de probes hjirboppe dat de fout grutte-ôfhinklik is, en fyn dan de lytste grutte dy't trochgiet en de grutste dy't mislearret. Kontrolearje de echte MTU fan 'e toegongsskeakel foardat jo de tunnel de skuld jouwe; in PPPoE-skeakel beheint it budzjet foardat jo VPN it oanrekket. Meitsje in notysje fan 'e oarspronklike wearden sadat de feroaring weromdraaid wurde kin.

Pas dan de lytste oanpassing ta dy't de klant dokumintearret. In protte klanten biede in tunnel-MTU plus in MSS-reparaasje-opsje, en de MSS-opsje is faak de bettere hefbeam foar TCP om't it de ôfstjoerder berikt sûnder elk pakket te ferlytsjen. Test deselde bestimming en deselde oerdracht op 'e nij, en notearje de getallen dêr't jo op útkommen binne. In tunnelwearde dy't op ien toegongsnetwurk wurket, is gjin universele konstante, en it folgjende plak sil syn eigen budzjet hawwe.