Gumagana ang ping ng VPN pero nag-hang ang website: tingnan ang laki

Dumarating ang mga sagot ng echo, gumagana ang remote desktop, at nananatili ang browser sa blangkong pahina hanggang sumuko ito. May dalawang paliwanag na umaangkop sa pattern na iyon, at hindi sila mga baryante ng isang problema: isang patakarang hindi kailanman pinayagan ang serbisyo, o mga packet na hindi na kasya kapag lumaki ang paglilipat. Hindi tinatanggihan ng sagot ng echo ang alinman sa dalawa.

Pumunta mula sa pinakamaliit na tanong hanggang sa pinakamalaki, at isulat kung ano talaga ang pinatunayan ng bawat hakbang.

Ang sagot ng echo ay sumasagot sa isang mas maliit na tanong

Sinasabi ng sagot ng echo na sinagot ng IP stack ng destinasyon ang isang kahilingang ICMP mula sa iyong pinagmulan. Wala itong sinasabi tungkol sa kung may tagapakinig ng TCP sa port na kailangan mo, kung pinapayagan ng isang patakaran ang port na iyon, o kung sinasala ng host ng destinasyon ang trapiko nang malaya sa gateway. Ang isang gateway na pumapayag sa isang serbisyo ay maaaring magbaba ng iba habang parehong tumutugon ang dalawang target sa ping. Basahin ang sagot bilang isang katotohanan tungkol sa isang packet at isang direksyon.

Kumpirmahin ang destinasyon at ang port ng serbisyo bago bigyang-kahulugan ang anupaman. Ang address na sinubukan mo at ang address na ginagamit ng aplikasyon ay kung minsan magkaibang rekord, at ang isang pangalang nagsasalin sa dalawang address ay ginagawang malamang iyon.

Alamin kung nagsimula ang koneksyon

Ang koneksyong agad na tinanggihan ay sagot ng tagapakinig o ng patakaran: may sumagot at nagsabing hindi. Ang koneksyong bumubukas at pagkatapos ay tumitigil kapag nagsimulang gumalaw ang data ay tumutukoy sa laki. Ang koneksyong hindi kailanman natatapos ang pakikipagkamay ay karaniwang patakaran o routing, at mukhang timeout kaysa pagtanggi.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Isulat kung alin sa tatlo ang naobserbahan mo bago hawakan ang mga setting ng MTU. Ang pagpapalit ng laki ng tunnel para ayusin ang tinanggihang koneksyon ay nagsasayang ng pagbabago at nagtatago sa tunay na dahilan nang ilang sandali.

Sukatin ang laki gamit ang nakasaad na bilang

Kapag lumitaw ang pagtigil sa ilalim ng karga, subukan ang isang laki ng packet na nakalagay ang bit na nagbabawal sa paghahati at sabihin ang aritmetika upang may kahulugan ang resulta. Sa Linux na may iputils, ang payload na 1392 byte kasama ang 8-byte na ICMP header at 20-byte na IPv4 header ay gumagawa ng panloob na packet na eksaktong 1420 byte. Sabihin ang aritmetikang iyon sa ticket, dahil ang hubad na ping na umabot sa gateway ay walang pinapatunayan tungkol sa isang aplikasyon.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Ang dalawang pagsubok ay mga punto ng pagsukat, hindi mga rekomendasyon sa laki ng tunnel. Kung sinasala ang ICMP kahit saan sa ruta, walang sinasabi ang timeout tungkol sa laki, dahil ang pagsasala at ang sobrang laking packet ay magkapareho ang hitsura mula sa kliyente. Wala rin sinasabi ang tagumpay tungkol sa kabaligtarang direksyon o sa ibang destinasyon.

Isaalang-alang ang panlabas na ruta

Nagdaragdag ang encapsulation ng sariling mga header, kaya mas malaki ang packet sa kawad kaysa sa packet na sinukat mo sa loob ng tunnel. Ang agwat ng dalawa ang gumagawa sa isang gumaganang maliit na kahilingan at isang nabibigong malaki na posible nang sabay.

Ang pagtuklas ng MTU ng ruta sa IPv4 ay nakasalalay sa feedback tungkol sa mga packet na hindi maipasa nang walang paghahati, at gumagamit ang IPv6 ng mga mensaheng Packet Too Big. Inilalarawan ng espesipikasyon ng IPv4 ang mekanismong iyon. Ang pagsasala sa feedback ay sumisira sa kakayahang matuto ng nagpapadala at iniiwan siyang muling nagpapadala ng mga packet na hindi kailanman kasya. Kaya nga nagkakasundo nang ganoon kahinahon ang gumaganang maliit na kahilingan at ang nabibigong malaki.

Palitan ang isang bilang at subukan muli ang aplikasyon

Babaan ang MTU ng tunnel, o limitahan ang pinakamataas na laki ng segment para sa TCP, pagkatapos ulitin ang orihinal na pagsubok ng aplikasyon sa halip na ang pagsubok. Ang pagsubok na nagtagumpay pagkatapos ng pagbabago at ang aplikasyong nakabitin pa rin ay magkaibang problema na may katulad na hugis, at tanging ang pagsubok ng aplikasyon ang nagtatangi sa kanila.

Itago ang aritmetika sa rekord ng pagbabago: ang sinukat na laki, ang inakala mong dagdag na bigat, at ang halagang itinakda mo. Sinu mang magrepaso nito mamaya ay masusuri ang palagay sa halip na muling kunin ito mula sa screenshot ng ping.

Kung gumagana ang aplikasyon sa bawat laki na sinubukan mo, itigil ang pag-adjust ng mga bilang at tingnan ang patakarang naghihiwalay sa gumaganang serbisyo sa nabibigo.