Mit o MTU pri VPN: zakaj se vaši paketi krčijo in kam gre prostor

Nekdo vam reče, da VPN "izgublja pakete zaradi MTU", vi nastavite tunel na 1400 in prenos spet deluje. Ta rezultat se zdi kot diagnoza. Običajno je to naključje v aritmetiki: izbrali ste število, dovolj majhno, da se prilega pod mejo, ki je nikoli niste prepoznali, in isto mejo boste spet srečali v naslednjem omrežju z drugačnim proračunom.

Večino tega povzročata dva mita. Prvi je, da je MTU vmesnika tunela MTU poti. Drugi je, da inkapsulacija stane "eno glavo" in da PPPoE ne stane ničesar, kar bi bilo vredno šteti. Oba sta napačna na način, ki naredi izbrano število videti samovoljno, čeprav je v resnici določeno.

Mit prvi: MTU tunela je MTU poti

Vrednost, ki jo nastavite na vmesniku tunela, je lokalna obljuba o največjem notranjem paketu, ki ga bo izvedba predala navzdol. Resnična zmogljivost poti je lastnost vsake povezave med vami in oddaljenim koncem in se lahko spremeni, ko se spremeni pot, ko se mobilna povezava preda ali ko promet zavzame drug peering. Nastavljenih 1500 vam pove, kaj bo zgradil vaš gostitelj, ne kaj bo preneslo omrežje.

Odkrivanje MTU poti obstaja zato, da uskladi oboje, in je odvisno od povratne informacije. V IPv4 naj bi usmerjevalnik, ki ne more poslati naprej paketa polne velikosti, poslal sporočilo ICMP "fragmentation needed", pošiljatelj pa zniža svojo oceno. V IPv6 je ustreznica sporočilo Packet Too Big in usmerjevalniki v tranzitu sploh ne drobijo. Ko je ta povratna informacija filtrirana, pošiljatelj še naprej ustvarja pakete, ki jih pot ne more nositi, in nič mu ne pove zakaj.

Mit drugi: inkapsulacija stane eno glavo

Pošteno preštejte zunanje plasti. Zunanja glava IP je 20 bajtov v IPv4 ali 40 v IPv6. Inkapsulacija UDP za prehod NAT doda 8. Protokol tunela doda svojo glavo, inicializacijski vektor ali nonce, zapolnitev do meje bloka ali poravnave šifre, zaključni del in vrednost preverjanja celovitosti. Glede na protokol in šifro je vsota udobno v desetinah bajtov, preden se notranji paket sploh začne.

Nato znova odštejte glave notranjega paketa samega. Segment TCP znotraj tunela nosi svojo 20-bajtno glavo IP in 20-bajtno glavo TCP, MSS v TCP pa izhaja iz MTU, ne iz nominalne koristne obremenitve tunela. Zato lahko ping z manjšo obremenitvijo uspe, medtem ko se prenos datoteke ustavi: orodja preizkušajo različne stvari in le eno od njih izvaja segment TCP polne velikosti.

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

Prvi ukaz poroča o nastavljenem MTU tunela. Dve sondi pošljeta obremenitev 1472 bajtov, kar je z 28 bajti glav IPv4 in ICMP paket 1500 bajtov, nato manjšo. Če velika sonda popolnoma odpove in mala uspe, imate napako, odvisno od velikosti, ne splošno težavo z usmerjanjem.

Mit tretji: PPPoE vam še vedno daje čistih 1500

Običajna dostopna povezava PPPoE ne prenaša paketa IP velikosti 1500 bajtov. Glava PPPoE in polje protokola PPP zavzameta 8 bajtov znotraj okvira Ethernet, kar za paket IP pusti 1492. To je tradicionalna meja, opisana v RFC 2516. Če čez tako povezavo vozite VPN, stroški tunela prihajajo iz tistih 1492, ne iz 1500.

RFC 4638 določa način za pogajanje o večji koristni obremenitvi PPP, ko to podpirata dostopni koncentrator in oprema naročnika, zato sama trditev "ta povezava uporablja PPPoE" ne dokazuje določenega števila. Lokalna nastavitev ne more prisiliti vmesne naprave, da sprejme paket, za katerega ni bila nikoli konfigurirana, zato je koristno vprašanje, o čem se je povezava dejansko dogovorila, ne kaj pravi nalepka.

Zakaj je napaka videti selektivna

Da majhne zahteve uspejo in veliki prenosi obstanejo, je klasičen podpis črne luknje MTU poti. Rokovanje, poizvedba DNS in klic API se vsi prilegajo; množični prenos ustvari segmente polne velikosti, ki umrejo na eni povezavi, sporočilo ICMP, ki bi moralo poročati o težavi, pa nikoli ne prispe. Povezava je videti v redu, prenos pa visi, kar ljudi pošlje gledat strežnik namesto pot.

Druga, povezana napaka je mešati tri števila: MTU vmesnika, MSS v TCP in lastno nastavitev razdrobljenosti ali zapolnitve protokola. Stiskanje MSS na usmerjevalniku prepiše oglašeni MSS, da pošiljatelj zgradi manjše segmente; ne spremeni MTU tunela in ne pomaga prometu UDP. Da vsem trem daste isto število, ker so videti povezana, je način, kako dobro mišljena sprememba pokvari delujočo nastavitev.

Kaj spremeniti in v kakšnem vrstnem redu

Začnite z dokazi. S sondami zgoraj potrdite, da je napaka odvisna od velikosti, nato poiščite najmanjšo velikost, ki gre skozi, in največjo, ki odpove. Preden okrivite tunel, preverite resnični MTU dostopne povezave; povezava PPPoE omeji proračun, preden se je VPN dotakne. Zapišite prvotne vrednosti, da bo spremembo mogoče razveljaviti.

Nato uporabite najmanjšo prilagoditev, ki jo dokumentira odjemalec. Veliko odjemalcev ponuja MTU tunela in možnost popravka MSS, možnost MSS pa je za TCP pogosto boljši vzvod, ker doseže pošiljatelja, ne da bi pomanjšala vsak paket. Znova preizkusite isti cilj in isti prenos ter zapišite števila, pri katerih ste se ustavili. Vrednost tunela, ki deluje v enem dostopnem omrežju, ni univerzalna konstanta, in naslednja lokacija bo imela svoj proračun.