VPN-MTU-mites: waarom jou pakkette krimp en waar die ruimte heen gaan

Iemand vertel jou die VPN "verloor pakkette weens MTU", jy stel die tonnel op 1400, en die oordrag werk weer. Dié uitslag voel soos 'n diagnose. Dit is gewoonlik 'n toeval van rekenkunde: jy het 'n getal gekies wat klein genoeg is om onder 'n perk te pas wat jy nooit geïdentifiseer het nie, en jy sal dieselfde perk weer teëkom op die volgende netwerk met 'n ander begroting.

Twee mites veroorsaak die meeste hiervan. Die eerste is dat die tonnelkoppelvlak se MTU die pad se MTU is. Die tweede is dat enkapsulering "een opskrif" kos en dat PPPoE niks kos wat die moeite werd is om te tel nie. Albei is verkeerd op maniere wat die getal wat jy kies arbitrêr laat lyk terwyl dit eintlik bepaal word.

Mite een: die tonnel se MTU is die pad-MTU

Die waarde wat jy op 'n tonnelkoppelvlak instel, is 'n plaaslike belofte oor die grootste binnepakket wat die implementering sal deurgee. Die pad se werklike kapasiteit is 'n eienskap van elke skakel tussen jou en die verre kant, en dit kan verander wanneer 'n roete verander, wanneer 'n mobiele verbinding oorskakel, of wanneer verkeer 'n ander peering neem. 'n Ingestelde 1500 vertel jou wat jou gasheer sal bou, nie wat die netwerk sal dra nie.

Pad-MTU-ontdekking bestaan om die twee te versoen, en dit hang van terugvoer af. Met IPv4 behoort 'n router wat nie 'n volgrootte pakket kan aanstuur nie, 'n ICMP-boodskap "fragmentation needed" te stuur, en die sender verlaag sy skatting. Met IPv6 is die ekwivalent 'n Packet Too Big-boodskap, en routers fragmenteer glad nie onderweg nie. Wanneer daardie terugvoer gefiltreer word, bly die sender pakkette produseer wat die pad nie kan dra nie, en niks vertel hom hoekom nie.

Mite twee: enkapsulering kos een opskrif

Tel die buitenste lae eerlik. 'n Buitenste IP-opskrif is 20 grepe vir IPv4 of 40 vir IPv6. UDP-enkapsulering vir NAT-deurgang voeg 8 by. Die tonnelprotokol voeg sy eie opskrif by, 'n initialiseringsvektor of nonce, opvulling tot die syfer se blok- of belyningsgrens, 'n slotstuk en 'n integriteitskontrolewaarde. Afhangend van die protokol en syfer lê die totaal gerus in die tiene grepe voordat die binnepakket eers begin.

Trek dan weer af vir die binnepakket se eie opskrifte. 'n TCP-segment binne die tonnel dra sy eie 20-grepe IP-opskrif en 20-grepe TCP-opskrif, en TCP se MSS word van die MTU afgelei, nie van die tonnel se nominale loonvrag nie. Dis hoekom ping met 'n kleiner loonvrag kan slaag terwyl 'n lêeroordrag vassteek: die gereedskap toets verskillende dinge, en net een van hulle oefen 'n volgrootte TCP-segment uit.

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

Die eerste opdrag rapporteer die ingestelde tonnel-MTU. Die twee toetse stuur 'n loonvrag van 1472 grepe, wat saam met 28 grepe IPv4- en ICMP-opskrifte 'n pakket van 1500 grepe is, en dan een kleiner. As die groot toets heeltemal misluk en die klein een slaag, het jy 'n grootte-afhanklike fout eerder as 'n algemene roeteringsprobleem.

Mite drie: PPPoE gee jou steeds 'n skoon 1500

'n Konvensionele PPPoE-toegangskakel dra nie 'n IP-pakket van 1500 grepe nie. Die PPPoE-opskrif plus die PPP-protokolveld neem 8 grepe binne die Ethernet-raam in, wat 1492 vir die IP-pakket laat. Dit is die tradisionele perk wat in RFC 2516 beskryf word. As jy 'n VPN oor so 'n skakel hardloop, kom die tonnel se oorhoofse koste uit daardie 1492, nie uit 1500 nie.

RFC 4638 definieer 'n manier om 'n groter PPP-loonvrag te beding wanneer beide die toegangskonsentrator en die kliënttoerusting dit ondersteun, en daarom bewys "hierdie verbinding gebruik PPPoE" alleen nie 'n spesifieke getal nie. 'n Plaaslike instelling kan nie 'n tussenliggende toestel laat aanvaar wat nooit vir hom opgestel is nie, so die nuttige vraag is wat die skakel werklik beding het, nie wat die etiket sê nie.

Hoekom die fout selektief lyk

Klein versoeke wat slaag en groot oordragte wat vassteek, is die klassieke handtekening van 'n pad-MTU-swartgat. Die handdruk, die DNS-navraag en die API-oproep pas almal in; die groot oordrag produseer volgrootte segmente wat by een skakel sterf, en die ICMP-boodskap wat die probleem moes rapporteer, kom nooit aan nie. Die verbinding lyk reg en die aflaai hang, wat mense na die bediener laat kyk in plaas van na die pad.

'n Tweede, verwante fout is om drie getalle te verwar: die koppelvlak-MTU, die TCP-MSS en die protokol se eie fragmentering- of opvullingsinstelling. MSS-inklemming op 'n router herskryf die aangekondigde MSS sodat die sender kleiner segmente bou; dit verander nie die tonnel-MTU nie, en dit help nie UDP-verkeer nie. Om al drie dieselfde getal te gee omdat hulle verwant lyk, is hoe 'n werkende opstelling deur 'n goedbedoelde verandering gebreek word.

Wat om te verander, in watter volgorde

Begin met bewyse. Bevestig met die toetse hierbo dat die fout grootte-afhanklik is, en vind dan die kleinste grootte wat slaag en die grootste wat misluk. Kontroleer die toegangskakel se werklike MTU voordat jy die tonnel blameer; 'n PPPoE-skakel beperk die begroting voordat jou VPN dit raak. Hou 'n nota van die oorspronklike waardes sodat die verandering teruggedraai kan word.

Pas dan die kleinste aanpassing toe wat die kliënt dokumenteer. Baie kliënte bied 'n tonnel-MTU plus 'n MSS-herstelopsie, en die MSS-opsie is dikwels die beter hefboom vir TCP omdat dit die sender bereik sonder om elke pakket te verklein. Toets dieselfde bestemming en dieselfde oordrag weer, en teken die getalle aan waarop jy besluit het. 'n Tonnelwaarde wat op een toegangsnetwerk werk, is nie 'n universele konstante nie, en die volgende werf sal sy eie begroting hê.