Bakit nag-hang ang mga pahina ng OpenConnect hanggang babaan mo ang MTU ng tunnel

Nagtagumpay ang pag-login, iginuhit ang front page ng portal, at pagkatapos ay nananatili sa waiting for host ang isang dashboard widget o ulat hanggang sumuko ang browser. Normal na naglo-load ang mga pampublikong site sa buong oras, at walang kredensyal na nagbago. Ang pagdating ng maliliit na sagot habang nag-hang ang malalaki ay tanda ng kisame ng laki ng packet at hindi ng patakaran sa access. Kumpirmahin ang pagbasang iyon bago mo baguhin ang anupaman sa profile.

Ihiwalay ang problema sa laki mula sa problema sa patakaran

Magsimula sa pag-alis ng posibilidad ng pagtanggi. Kung tinanggihan ka ng gateway, agad na mabibigo ang koneksyon sa halip na i-load ang pahina nang kalahati. Ang tunnel na bumabangon at pagkatapos ay nag-hang lamang sa mas malalaking paglilipat ay nagsasabi sa iyo na hindi kayang dalhin ng panlabas na landas ang panloob na packet.

Ang mekanismo ay encapsulation. Bawat panloob na packet ay nakakakuha ng mga header ng tunnel, kaya ang payload na kasya sa pisikal na link ay nagiging panlabas na packet na hindi na kasya, at anumang may bit na do-not-fragment ay itinatapon nang walang sagot na maiintindihan ng browser.

Sukatin ang kisame gamit ang do-not-fragment probes

Sukatin ang kisame sa halip na hulaan ito. Magpadala ng mga probe na tumatanggi sa fragmentation at ibaba ang payload nang hakbang-hakbang hanggang may sagot na bumalik, magsimula sa utos na tulad ng ping -M do -s 1472 host. Ang sagot na nagrereklamo na kailangan ang fragmentation habang nakatakda ang DF ay nangangahulugang masyadong mataas pa ang halaga. Ulitin sa 1462, pagkatapos 1452, at huminto sa unang laki na tumugon. Isulat ang numero kasama ang host na sinubukan mo, dahil ang sagot ay para sa landas na iyon at hindi sa protocol sa pangkalahatan.

Subukan ang address kung saan talaga nagpapadala ng trapiko ang tunnel. Ang panlabas na probe laban sa pampublikong pangalan ng gateway at ang panloob na probe laban sa panloob na server ay sumusukat ng magkaibang hop, at ang pag-filter ng ICMP sa alinman sa mga ito ay maaaring magpakita ng sirang landas kahit maayos ito.

Ilapat ang halaga sa device ng tunnel

Ilapat ang resulta sa interface na ginawa ng client, hindi sa Wi-Fi adapter. Sa isang Linux client iyon ay ip link set dev tun0 mtu 1300 na sinusundan ng ip link show tun0 upang kumpirmahin na tinanggap ang halaga. Gamitin ang anumang pangalan ng device na iniuulat ng client, dahil nag-iiba ito ayon sa implementasyon at ayon sa kung paano ginawa ang tunnel.

Ang pagbaba ng MTU ng tunnel ay nagpapaliit ng payload na dinadala ng bawat packet, kaya bahagyang bumababa ang throughput, at iyon ang presyo ng hindi pagtatapon ng malalaking sagot sa black hole. Ang mas maliit na numero ay hindi awtomatikong mas ligtas. Ang pagbabago ng pisikal na adapter sa halip ay nagkakalat ng pinsala sa bawat koneksyon sa link na iyon habang nananatiling kasinglaki ang sobrang laking panloob na packet.

Gamitin muna ang sariling mga kahilingan sa MTU ng client

Kapag ikaw ang may kontrol sa invocation, maaaring humiling ng laki ang client sa halip na patch-an pagkatapos. --mtu humihiling ng MTU ng tunnel sa server, at --base-mtu ay nagdedeklara ng MTU ng pinagbabatayang landas upang makuha ng gateway ang numero ng tunnel. Pareho silang kahilingan, at ang manual ng client ay hindi nangangako na susundin ng gateway ang alinman sa mga ito.

Ang pagkakaibang iyon ang nagtatakda ng pagkakasunod-sunod ng trabaho mo. Subukan muna ang kahilingan at siyasatin ang interface na nililikha nito, pagkatapos ay bumalik sa lokal na pagtatakda ng device kung nag-hang pa rin ang halagang pinili ng gateway.

I-verify gamit ang paglilipat na nabigo, pagkatapos gawin itong permanente

Ang lokal na pagbabago sa ip link ay tatagal hanggang muling itayo ng client ang tunnel, na nangyayari sa susunod na muling pagkonekta o pagpapatuloy. Ilagay ang halaga kung saan nagsisimula ang koneksyon: isang wrapper na nagpapatakbo ng client at pagkatapos ay nag-aayos ng device, isang systemd unit na may ExecStartPost na hakbang, o ang opsyon ng client kapag tinatanggap ito ng gateway. Panatilihin ito sa tabi ng profile sa version control upang makita ng susunod na tao kung bakit naroon ang numero.

Subukan gamit ang kahilingang nabigo, hindi ang front page. Buksan ang ulat, hilahin ang attachment, o patakbuhin ang pagkuha ng repository na nag-hang, at itala nang eksakto kung saan ito humihinto kung humihinto pa rin ito. Ang pahinang iginuhit pagkatapos ng pagbabago ay kakaunti ang pinapatunayan, dahil iginuhit din ito noon.

Kung ang parehong paglilipat ay nag-hang sa parehong punto, hindi pa napatunayan ang teorya ng MTU. Kunin ang trapiko sa tunnel at tingnan kung aling panig ang humihinto sa pagpapadala bago mo muling baguhin ang numero, at itago ang nakaraang halaga na nakatala upang ang rollback ay manatiling isang utos.