IPv6-pakket te groot: waarom groot VPN-oordragte vasdraai

Ping werk, die blaaier laai 'n klein bladsy, en die lêeroordrag hang, alles oor IPv6 deur dieselfde tonnel. Daardie patroon beteken gewoonlik dat die sender nooit die pad se werklike grootte geleer het nie, nie dat die tonnel stadig is nie. IPv6 verwag dat roetebeheerders die probleem met 'n Packet Too Big-boodskap rapporteer, en inkapseling voeg oorhoofse koste by voordat 'n pakket ooit die buitenste netwerk bereik. As daardie boodskap gefiltreer word, bly die sender 'n grootte herhaal wat nie kan deurkom nie.

Klein versoeke, groot onderbrekings

'n Tonnel draai elke pakket in nog 'n opskrif, so die bruikbare grootte binne is kleiner as die grootte buite. 'n Pakket wat voor inkapseling vir die fisiese skakel geskaal is, word daarna te groot. IPv4-roetebeheerders mag onderweg fragmenteer, terwyl IPv6-roetebeheerders dit nie namens die sender doen nie, so die sender moet eerder aanpas. Daardie aanpassing hang heeltemal daarvan af dat die terugvoer ontvang word.

Een verlore boodskap is genoeg om die klassieke simptoom te veroorsaak: handdrukke en klein antwoorde slaag, en 'n gidslys of 'n oplaai hang elke keer op dieselfde punt. Gebruikers beskryf dit as dat die VPN stadig is, en die logs wys niks verkeerd met verifikasie nie. Beide waarnemings is akkuraat, en nie een daarvan vind die fout nie.

Packet Too Big is terugvoer, nie verkeer nie

'n ICMPv6 Packet Too Big-boodskap dra die grootte wat die volgende hop kan aanvaar, en die sender gebruik dit om sy skatting te verlaag. Om dit te filtreer is die ekwivalent daarvan om 'n padteken te verwyder en dan die bestuurders te blameer. 'n Reël wat alle ICMPv6 laat val, lyk streng terwyl dit padontdekking op elke skakel wat dit nodig het, breek. Die boodskap is beheerinfligting oor die pad, nie toepassingsvrag nie.

Selektiewe filtrering bly steeds redelik. Eggo-versoeke en buurontdekking speel ander rolle as foutboodskappe, en 'n beleid kan hulle anders behandel. Volg die platform se gedokumenteerde filtreringsriglyne eerder as om die hele protokol te aanvaar of te laat val, want RFC 8201 bepaal hoe daardie terugvoer ontdekking dryf.

Toets albei adresfamilies afsonderlik

Toets IPv6 op sy eie, want 'n suksesvolle IPv4-oordrag bewys niks oor die IPv6-pad nie. Teken dan beheerboodskappe op terwyl die groot oordrag hang. Die twee rekords wys saam óf dat die terugvoer vertrek óf dat dit nooit aangekom het nie.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

Die toets stuur 'n pakket met die do-not-fragment-bis ingestel en rapporteer die grootte waarop dit misluk, dit is die getal waarvoor die tonnel plek moet maak. Die roetevraag noem die koppelvlak wat die bestemming sou dra, so jy weet watter skakel se MTU geld. Die opname filtreer ICMPv6 tipe 2, die Packet Too Big-boodskap, en wys of dit hierdie gasheer hoegenaamd bereik. As die boodskap in die opname verskyn en die oordrag hang steeds, ignoreer die sender dit, wat die ondersoek na die stapel skuif eerder as na die netwerk.

Pas die tonnelgrootte eers ná die bewyse aan

Om die tonnel se MTU te verlaag, kan 'n gefiltreerde boodskap versteek en die simptoom laat verdwyn, ten koste van meer oorhoofse koste per pakket. Dit is 'n noodoplossing eerder as 'n diagnose, en dit moet die opname volg in plaas van dit vervang. 'n Willekeurige lae waarde breek ook niks sigbaar nie, en daarom oorleef dit jare lank in opstellings. Verander dit doelbewus, teken die waarde aan, en skryf neer watter meting dit geregverdig het.

Wanneer jy die gateway beheer, ondersoek die reël wat die boodskap laat val in plaas daarvan om die firewall te deaktiveer. Een reggestelde reël is smaller as 'n beleidsuitsondering en baie makliker om later te verdedig. Dieselfde redenasie geld vir tydsverloop: nie elke onderbreking is 'n grootteprobleem nie, en 'n opname is wat die twee skei.