Mitovi o VPN MTU-u: zašto se vaši paketi smanjuju i kamo odlazi prostor

Netko vam kaže da VPN "gubi pakete zbog MTU-a", vi postavite tunel na 1400 i prijenos ponovno radi. Takav se rezultat čini kao dijagnoza. Obično je to slučajnost u aritmetici: odabrali ste broj dovoljno mali da stane ispod granice koju nikad niste utvrdili, a istu ćete granicu ponovno sresti na sljedećoj mreži s drukčijim proračunom.

Većinu toga uzrokuju dva mita. Prvi je da je MTU sučelja tunela MTU putanje. Drugi je da inkapsulacija stoji "jedno zaglavlje", a PPPoE ništa što vrijedi brojiti. Oba su pogrešna na način koji čini odabrani broj proizvoljnim, iako je on zapravo određen.

Prvi mit: MTU tunela jest MTU putanje

Vrijednost koju postavite na sučelju tunela lokalno je obećanje o najvećem unutarnjem paketu koji će implementacija predati niže. Stvarni kapacitet putanje svojstvo je svake veze između vas i udaljenog kraja i može se promijeniti kad se promijeni ruta, kad se mobilna veza preda drugoj mreži ili kad promet krene drugim peeringom. Postavljenih 1500 govori što će vaš host sastaviti, a ne što će mreža prenijeti.

Otkrivanje MTU-a putanje postoji kako bi pomirilo to dvoje i ovisi o povratnoj informaciji. U IPv4 usmjerivač koji ne može proslijediti paket pune veličine trebao bi poslati ICMP poruku "fragmentation needed", a pošiljatelj snizi svoju procjenu. U IPv6 ekvivalent je poruka Packet Too Big, a usmjerivači uopće ne fragmentiraju u tranzitu. Kad se ta povratna informacija filtrira, pošiljatelj nastavlja stvarati pakete koje putanja ne može prenijeti i ništa mu ne kaže zašto.

Drugi mit: inkapsulacija stoji jedno zaglavlje

Pošteno prebrojite vanjske slojeve. Vanjsko IP zaglavlje ima 20 bajtova u IPv4 ili 40 u IPv6. UDP inkapsulacija za NAT prolaz dodaje 8. Protokol tunela dodaje vlastito zaglavlje, inicijalizacijski vektor ili nonce, podstavljanje do granice bloka ili poravnanja šifre, završni dio i vrijednost provjere cjelovitosti. Ovisno o protokolu i šifri, ukupno je udobno u desecima bajtova prije nego što unutarnji paket uopće počne.

Zatim ponovno oduzmite vlastita zaglavlja unutarnjeg paketa. TCP segment unutar tunela nosi svoje 20-bajtno IP zaglavlje i 20-bajtno TCP zaglavlje, a MSS u TCP-u izvodi se iz MTU-a, ne iz nominalnog korisnog tereta tunela. Zato ping s manjim korisnim teretom može uspjeti dok prijenos datoteke zapinje: alati ispituju različite stvari i samo jedan od njih izvodi TCP segment pune veličine.

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

Prva naredba prikazuje postavljeni MTU tunela. Dvije probe šalju korisni teret od 1472 bajta, što je uz 28 bajtova IPv4 i ICMP zaglavlja paket od 1500 bajtova, a zatim manji. Ako velika proba posve ne uspije, a mala uspije, imate kvar koji ovisi o veličini, a ne opći problem usmjeravanja.

Treći mit: PPPoE vam još daje čistih 1500

Uobičajena PPPoE pristupna veza ne prenosi IP paket od 1500 bajtova. PPPoE zaglavlje plus polje PPP protokola zauzimaju 8 bajtova unutar Ethernet okvira, što za IP paket ostavlja 1492. To je tradicionalna granica opisana u RFC 2516. Ako preko takve veze vozite VPN, trošak tunela dolazi iz tih 1492, a ne iz 1500.

RFC 4638 definira način da se pregovara veći PPP korisni teret kad to podržavaju i pristupni koncentrator i oprema korisnika, zato sama tvrdnja "ova veza koristi PPPoE" ne dokazuje određeni broj. Lokalna postavka ne može natjerati međuuređaj da prihvati paket za koji nikad nije konfiguriran, pa je korisno pitanje što je veza doista pregovarala, a ne što kaže oznaka.

Zašto kvar izgleda selektivno

Mali zahtjevi koji prolaze i veliki prijenosi koji zapinju klasičan su potpis crne rupe MTU-a putanje. Rukovanje, DNS upit i API poziv svi stanu; skupni prijenos stvara segmente pune veličine koji umiru na jednoj vezi, a ICMP poruka koja je trebala prijaviti problem nikad ne stigne. Veza izgleda ispravno, a preuzimanje visi, što ljude šalje da gledaju poslužitelj umjesto putanju.

Druga, povezana pogreška jest miješanje triju brojeva: MTU-a sučelja, TCP MSS-a i vlastite postavke fragmentacije ili podstavljanja protokola. MSS stezanje na usmjerivaču prepisuje oglašeni MSS kako bi pošiljatelj sastavljao manje segmente; ono ne mijenja MTU tunela i ne pomaže UDP prometu. Postavljanje istog broja na sva tri jer se čine povezanima način je na koji dobro promišljena promjena razbije ispravnu postavku.

Što promijeniti i kojim redom

Počnite s dokazima. Probama gore potvrdite da kvar ovisi o veličini, a zatim pronađite najmanju veličinu koja prolazi i najveću koja ne prolazi. Provjerite stvarni MTU pristupne veze prije nego okrivite tunel; PPPoE veza ograničava proračun prije nego što je VPN dotakne. Zabilježite izvorne vrijednosti da se promjena može vratiti.

Zatim primijenite najmanju prilagodbu koju klijent dokumentira. Mnogi klijenti nude MTU tunela uz opciju ispravka MSS-a, a MSS je često bolja poluga za TCP jer doseže pošiljatelja bez smanjivanja svakog paketa. Ponovno ispitajte istu odredišnu točku i isti prijenos te zapišite brojeve na kojima ste se zaustavili. Vrijednost tunela koja radi na jednoj pristupnoj mreži nije univerzalna konstanta, a sljedeća će lokacija imati svoj proračun.