Nawawala ang malalaking packet sa IPsec habang gumagana pa rin ang maliliit na ping

Nananatiling tumutugon ang malalayong shell, sumasagot ang maliliit na probe, at pagkatapos ay gumagapang ang isang pagkopya ng file at nag-stall nang walang error na maaaring ituro ng kahit sino. Ang ping na may mas malaking payload ay agad na nagpaparami nito, at gumagana ang parehong transfer mula sa lokal na network. Walang mabagal sa encryption; may mga packet na hindi talaga dumarating. Dalawang magkaibang paghahati ang maaaring gumawa ng tandang iyon, at magkaiba ang iniwang ebidensya.

Dalawang lugar kung saan mahahati ang isang packet

Bago ang encryption, maaaring hatiin ng router ang sobrang laking panloob na packet at protektahan ang bawat piraso nang hiwalay. Pagkatapos ng encryption, ang tinatapos na panlabas na packet ang hinahati, at kailangang muling buuin ito ng malayong dulo bago ito makapag-decrypt ng anuman. Parehong sintomas, ibang trabaho para sa tatanggap at ibang kontrol para sa iyo.

Mahalaga ang pagkakaiba dahil ang pagtatamang nakadirekta sa maling panig ay nagbabago ng numero nang hindi ginagalaw ang sira. Ang packet na tinanggihan sa interface ay hindi kailanman nagiging panlabas na packet, kaya walang setting sa panlabas na panig ang makakapagligtas dito.

Saan talaga ginagawa ang desisyon sa laki

May IP MTU ang isang tunnel interface, at ang halagang iyon ay maaaring tumanggi sa sobrang laking panloob na packet bago pa man ito makita ng yugto ng IPsec. Ang paglalagay ng bit sa panlabas na header ay hindi muling sinusuri ang naunang desisyong iyon, dahil tinanggihan na ang packet. Kaya't ang pagtaas ng panloob na MTU ay minsan nagpapalala sa halip na magpabuti. Basahin ang halaga ng interface at ang panlabas na pag-uugali bago baguhin ang alinman sa dalawa, dahil ang mas murang pagbabago ang karaniwang nagpapaliwanag ng sintomas.

Suriin muna ang halaga ng interface, pagkatapos ang panlabas na pag-uugali. Dalawang numero, dalawang yugto, at karaniwang isa lang sa kanila ang may pananagutan.

Ang panlabas na badyet ay hindi ang panloob na badyet

Bawat encapsulation ay gumagastos ng byte sa mga header, at ang dami ay depende sa transport, pamilya ng address at kung may NAT traversal. Ang panloob na packet na kasya sa lokal na link ay maaari pa ring gumawa ng panlabas na packet na hindi kasya sa landas sa kabila nito. Sukatin ang karagdagang gastos sa halip na ipagpalagay ito, dahil bawat opsyonal na header ay nadaragdag sa bill. Ang tunnel na may NAT traversal ay nagbabayad ng higit sa hubad, at sapat ang pagkakaiba para sirain ang isang transfer na gumana kahapon.

Kapag ang panlabas na packet ay may bit na do-not-fragment, ang hop na hindi ito maipasa ay nagtatapon nito at dapat magbalik ng mensaheng ICMP. Kung ang mensaheng iyon ay nasala sa isang lugar, patuloy na nagtatangka ang nagpadala at nakikita ng user ang pagtigil na walang paliwanag. Ang tahimik na pagtatapong iyon ang karaniwang dahilan kung bakit ang problema sa laki ay iniuulat bilang problema sa bilis.

Tinatanggal ng IPv6 ang isa sa mga opsyon

Hindi nag-fragment ang mga router ng IPv6 habang dinaraanan, kaya ang panlabas na packet ay kasya o nawawala kasama ang mensaheng Packet Too Big. Ang mensaheng iyon ang nagiging tanging channel ng feedback, at ang pagharang dito ay sumisira sa pagtuklas ng landas para sa bawat susunod na malaking transfer. Ang mga router ng IPv4 ay maaaring mag-fragment ng malaking packet kapag malinaw ang bit, na nagtatago sa sira hanggang may ibang magtakda ng bit na iyon.

Sa pinaghalong stack, ang parehong tunnel ay maaaring kumilos nang iba para sa dalawang pamilya, kaya't ang isang pagsubok sa IPv4 ay hindi nagtatapos ng reklamo tungkol sa IPv6. Ang pagsusuring nagsasanay lamang ng isang pamilya ay nag-iiwan ng kalahati ng sagot na hindi nasukat.

Ang patakaran sa segment ng TCP ay hindi pangkalahatang sagot

Ang paglilimita sa pinakamalaking laki ng segment ay tumutulong sa mga daloy ng TCP, at ito ay lehitimong kontrol kapag ang problema ay nakulong sa kanila. Wala itong epekto sa UDP, na nagdadala ng DNS, ilang voice protocol at dumaraming bahagi ng trapik sa web.

Ilapat ito, pagkatapos subukan ang workload na nabigo. Kung nabigo pa rin ang kaso ng UDP, hindi kailanman naging sagot ang patakaran sa segment at kailangan pa rin ng pansin ang badyet ng interface. Tukuyin muna ang protocol ng nabigong workload, pagkatapos piliin ang kontrol na nababagay dito.

Ang pagkakasunod-sunod ng trabaho

Itala ang pinakamalaking payload na nakakaligtas, pagkatapos ang MTU ng interface, pagkatapos kung may bit na do-not-fragment ang panlabas na packet, at sa huli kung umaabot sa nagpadala ang feedback ng ICMP. Nililimitahan ng sekwens na iyon ang sira nang hindi nanghuhula. Itago ang bawat obserbasyon na may timestamp at dulong punto, dahil gumagalaw ang apat na numero kapag nagbago ang landas.

Baguhin ang isang halaga, subukan muli ang orihinal na transfer at itago ang resulta. Ang tunnel na pumasa sa malaking probe pero nag-stall pa rin sa application ay lumipat sa ibang problema, at iyon ay progresong dapat isulat. Mas gusto ng susunod na tao ang mga numero kaysa sa konklusyon.