Jy het ’n vereiste wat nie buig nie: die ander kant moet dieselfde 1,500-greep IP-pakket ontvang wat die sender uitstuur, insluitend die koptekste. ’n Tonnel kan daardie pakket plus sy eie omraming nie binne ’n tweede 1,500-greep IP-pakket toedraai nie, so iets in die ontwerp moet toegee. Die volgorde hieronder is die een wat ek in ’n veranderingsvenster gebruik: skryf die greepbegroting neer, bewys wat die onderlaag werklik kan dra, kies dan presies een vervoermeganisme en bevestig die binnepakket aan die ander kant.

Skryf die greepbegroting voordat jy ’n profiel wysig

Enkapsulering voeg grepe by verskeie lae, en die totaal is ’n eienskap van jou profiel eerder as ’n konstante wat jy kan naslaan. Adresfamilie, syferkeuse, vervoerprotokol en enige kompressie- of omramingsopsie beweeg almal die getal, en daarom is ’n aftrekking wat uit ’n ander ontplooiing gekopieer is, waardeloos as begroting. Begin by die binnevereiste, voeg die gemete oorhoofse koste per pakket van jou eie konfigurasie by, en skryf die resulterende buitenste grootte op die veranderingstiket voordat iemand ’n lêer wysig.

Twee getalle bepaal die ontwerp: die grootste buitenste pakket wat die pad sonder fragmentering dra, en die ekstra grepe wat jou enkapsulering nodig het. Wanneer die eerste kleiner is as die tweede plus 1,500, moet een van hulle verander. Die keuse is dan nou eerder as kreatief, en daarom skryf ek albei getalle neer voordat ons opsies bespreek. Niks by die tonnellaag komprimeer daardie grepe weg nie, en geen enkele MTU-heelgetal verwyder die vereiste wat jy gekry het nie.

Toets die onderlaag met do-not-fragment-pings

Meet die pad eerder as om die koppelvlak-MTU te vertrou, want die kleinste skakel in die buitenste pad is die een wat saak maak. Op Linux stel -M do die do-not-fragment-bis en -s neem die ICMP-lading, so ’n 1,500-greep raam antwoord op 1,472 grepe lading nadat die 20-greep IP-kop en 8-greep ICMP-kop afgetrek is. Stap die lading opwaarts tot die toets misluk, en spring dan na ’n jumbo-grootte om te sien of die pad dit hoegenaamd dra.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

’n Pad wat 1,472 slaag en 8,972 misluk, kan nie ’n 1,500-greep binnepakket plus oorhoofse koste in ’n enkele buitenste pakket dra nie. Dit is die antwoord wat jy nodig gehad het voordat jy die VPN-konfigurasie oopgemaak het. Dit bepaal ook watter van die volgende twee afdelings op jou van toepassing is, so hou die twee toetsresultate by die tikket. Om hier te raai kos ’n onderhoudsvenster, want ’n tonnel wat homself as op meld, sê niks oor die grootste pakket wat die pad sal aanvaar nie.

Verhoog die pad-MTU net waar elke hop saamstem

Jumbo-rame is ’n end-tot-end-eienskap, nie ’n instelling wat jy op die twee eindpunte wat jy toevallig beheer, aktiveer nie. Elke skakelaar, router en verskafferoorhandiging op die buitenste pad moet oor die groter grootte saamstem, en ’n enkele 1,500-greep hop sal die pakket wat jy pas groter gemaak het, stilweg weggooi. Om net die plaaslike koppelvlak te verhoog, is die klassieke halwe verandering wat die tonnel laat lyk of dit stukkend is terwyl die onderlaag hom stilweg laat val.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

Verander die koppelvlak, en toets dan dieselfde pad weer voordat jy enigiets anders verander. As die toets steeds misluk, draai terug met ip link set dev eth1 mtu 1500 en gaan oor na fragmentering in plaas daarvan om met ’n verskaffer te stry oor ’n skakel wat jy nie besit nie.

Gebruik tonnelfragmentering wanneer die onderlaag nie kan groei nie

’n Ondersteunde fragmenteringsmeganisme onder die binnepakket laat verskeie buitenste pakkette een binnepakket dra, en die verre tonnel-eindpunt herbou hulle voordat dit die oorspronklike aan die stapel oorhandig. Community OpenVPN se UDP-fragmentopsie is een implementering van daardie idee, en dit is nie dieselfde ding as gewone IP-fragmentering van die buitenste pakket nie. Albei eweknieë moet ’n weergawe hardloop wat die formaat ondersteun, en die datapad moet die een wees wat jy dink dit is: OpenVPN 3-kliënte en kernversnelde datakanale het verskillende perke, so ’n profiel wat op een kliënt werk, kan op ’n ander misluk.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

Gewone buitenste fragmentering is die ander opsie, en dit is die swakker een. IPv6-routers fragmenteer glad nie ’n pakket wat deurgestuur word nie, so ’n te groot buitenste pakket sterf eenvoudig en die sender leer daarvan net as die betrokke ICMPv6-boodskap die pad oorleef. Fragmente nooi ook filterering en verliesversterking uit, en daarom behandel ek dit as ’n terugvalplan eerder as ’n plan.

’n Stroomgebaseerde buitenste draer omseil die groottevraag deur sy eie greepstroom te segmenteer, en die herboude binnepakket kan steeds 1,500 grepe wees. Dit is ’n vervoerbesluit met sy eie koste, insluitend die bekende gedrag van TCP binne TCP, so neem dit doelbewus eerder as ’n neweproduk van ’n MTU-argument.

Bevestig dat die binnepakket onveranderd aankom

Verifikasie is nie ’n suksesvolle handdruk nie. Vang op die tonnelkoppelvlak aan albei kante en vergelyk die grootte en inhoud van die pakket wat die toepassing werklik gestuur het met die een wat die ander kant ontvang het.

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

As die opname die volledige binnepakket aan die ander kant wys, werk die vervoerkeuse en die oorblywende taak is om dit te dokumenteer. As dit niks wys terwyl die tonnel homself as op meld, word die buitenste pakket êrens tussen die eindpunte laat val, wat jou terugstuur na die toets eerder as na die syferinstellings.

Teken drie dinge in die veranderingstiket aan voordat jy dit sluit: die gemete buitenste begroting, die meganisme wat jy gekies het, en die opdrag wat bewys het dat die binnepakket oorleef het. Die volgende persoon wat hierdie tonnel aanraak, sal al drie nodig hê, en nie een daarvan kan uit die konfigurasielêer alleen herbou word nie.

Verwante artikels