Transporti fiksa 1,500-bajtan internan paketon tra VPN

Vi havas postulon, kiu ne fleksiĝas: la malproksima flanko devas ricevi la saman 1,500-bajtan IP-paketon, kiun la sendanto elsendas, inkluzive de la kaplinioj. Tunelo ne povas volvi tiun paketon kune kun sia propra kadrigo en duan 1,500-bajtan IP-paketon, do io en la dezajno devas cedi. La ordo sube estas tiu, kiun mi uzas en ŝanĝa fenestro: skribu la bajtan buĝeton, pruvu, kion la suba tavolo fakte povas porti, poste elektu precize unu transportan mekanismon kaj konfirmu la internan paketon ĉe la kontraŭa flanko.

Skribu la bajtan buĝeton antaŭ ol redakti profilon

Enkapsuligo aldonas bajtojn en pluraj tavoloj, kaj la sumo estas eco de via profilo, ne konstanto, kiun vi povas serĉi. Adresfamilio, ĉifra elekto, transporta protokolo kaj iu ajn kunprema aŭ kadriga opcio movas la nombron, tial subtraho kopiita el alia deplojo estas senutila kiel buĝeto. Komencu de la interna postulo, aldonu la mezuritan superkoston po paketo de via propra agordo, kaj skribu la rezultan eksteran grandecon sur la ŝanĝbileton antaŭ ol iu redaktas dosieron.

Du nombroj decidas la dezajnon: la plej granda ekstera paketo, kiun la vojo portas sen fragmentado, kaj la kromaj bajtoj, kiujn via enkapsuligo bezonas. Kiam la unua estas pli malgranda ol la dua plus 1,500, unu el ili devas ŝanĝiĝi. La elekto tiam estas mallarĝa, ne kreema, tial mi skribas ambaŭ nombrojn antaŭ ol diskuti opciojn. Nenio ĉe la tunela tavolo kunpremas tiujn bajtojn for, kaj neniu unuopa MTU-entjero forigas la postulon, kiun vi ricevis.

Sondi la suban tavolon per pingoj sen fragmentado

Mezuru la vojon anstataŭ fidi la MTU de la interfaco, ĉar la plej malgranda ligo en la ekstera vojo estas tiu, kiu gravas. En Linux -M do agordas la biton por malpermesi fragmentadon kaj -s prenas la ICMP-ŝarĝon, do 1,500-bajta kadro respondas je 1,472 bajtoj da ŝarĝo post kiam oni subtrahas la 20-bajtan IP-kaplinion kaj la 8-bajtan ICMP-kaplinion. Supreniru kun la ŝarĝo ĝis la testaĵo malsukcesas, poste saltu al jumbo-grando por vidi, ĉu la vojo entute portas ĝin.

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

Vojo, kiu trapasas 1,472 kaj malsukcesas ĉe 8,972, ne povas porti internan paketon de 1,500 bajtoj plus superkosto en unu ekstera paketo. Tio estas la respondo, kiun vi bezonis antaŭ ol malfermi la VPN-agordon. Ĝi ankaŭ decidas, kiu el la du sekvaj sekcioj aplikiĝas al vi, do tenu la du sondajn rezultojn apud la bileto. Diveni ĉi tie kostas prizorgan fenestron, ĉar tunelo, kiu raportas sin aktiva, diras nenion pri la plej granda paketo, kiun la vojo akceptos.

Altigu la MTU de la vojo nur tie, kie ĉiu salto konsentas

Jumbo-kadroj estas eco de unu ekstremo al la alia, ne agordo, kiun vi ŝaltas ĉe la du finpunktoj, kiujn vi hazarde kontrolas. Ĉiu ŝaltilo, enkursigilo kaj provizanta transdono en la ekstera vojo devas konsenti pri la pli granda grando, kaj unu sola salto de 1,500 bajtoj silente forĵetos la paketon, kiun vi ĵus pligrandigis. Altigi nur la lokan interfacon estas la klasika duona ŝanĝo, pro kiu la tunelo aspektas rompita dum la suba tavolo silente faligas.

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

Ŝanĝu la interfacon, poste resendu la saman vojon antaŭ ol ŝanĝi ion alian. Se la testo ankoraŭ malsukcesas, restarigu per ip link set dev eth1 mtu 1500 kaj transiru al fragmentado anstataŭ disputi kun provizanto pri ligo, kiun vi ne posedas.

Uzu tunelan fragmentadon, kiam la suba tavolo ne povas kreski

Subtenata fragmentada mekanismo sub la interna paketo ebligas al pluraj eksteraj paketoj porti unu internan paketon, kaj la malproksima tunela finpunkto rekunmetas ilin antaŭ ol transdoni la originalon supren en la stakon. La UDP-fragmenta opcio de Community OpenVPN estas unu efektivigo de tiu ideo, kaj ĝi ne estas la sama afero kiel ordinara IP-fragmentado de la ekstera paketo. Ambaŭ partneroj devas ruli version, kiu subtenas la formaton, kaj la datenvojo devas esti tiu, kiun vi pensas: OpenVPN 3-klientoj kaj kernakcelitaj datenkanaloj havas malsamajn limojn, do profilo, kiu funkcias ĉe unu kliento, povas malsukcesi ĉe alia.

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

Ordinara ekstera fragmentado estas la alia opcio, kaj ĝi estas la pli malforta. IPv6-enkursigiloj tute ne fragmentas plusenditan paketon, do trogranda ekstera paketo simple mortas kaj la sendanto ekscias pri tio nur se la koncerna ICMPv6-mesaĝo postvivas la vojon. Fragmentoj ankaŭ invitas filtradon kaj perdo-amplifadon, tial mi traktas tion kiel rezervan eblon, ne kiel planon.

Flubazita ekstera portanto preteriras la granddemandon per segmentado de sia propra bajta fluo, kaj la rekonstruita interna paketo povas ankoraŭ esti 1,500 bajtoj. Tio estas transporta decido kun propra kosto, inkluzive de la konata konduto de TCP ene de TCP, do faru ĝin konscie kaj ne kiel flanka efiko de MTU-disputo.

Konfirmu, ke la interna paketo alvenas senŝanĝe

Kontrolo ne estas sukcesa manpremo. Kaptu sur la tunela interfaco ĉe ambaŭ finoj kaj komparu la grandecon kaj enhavon de la paketo, kiun la aplikaĵo fakte sendis, kun tiu, kiun la malproksima flanko ricevis.

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'

Se la kaptaĵo montras la plengrandan internan paketon ĉe la malproksima fino, la transporta elekto funkcias kaj restas nur registri ĝin. Se ĝi montras nenion dum la tunelo raportas sin aktiva, la ekstera paketo estas forĵetata ie inter la finpunktoj, kio resendas vin al la testo kaj ne al la ĉifraj agordoj.

Registru tri aferojn en la bileto antaŭ ol fermi ĝin: la mezuritan eksteran buĝeton, la mekanismon, kiun vi elektis, kaj la komandon, kiu pruvis, ke la interna paketo postvivis. La sekva persono, kiu tuŝos ĉi tiun tunelon, bezonos ĉiujn tri, kaj neniu el ili povas esti rekonstruita nur el la agorda dosiero.