Pagtuklas ng MTU ng landasin sa VPN: sukat at ang puwang ng ICMP

Ang isang tunel ay nagtatapos ng handshake nito, bumabalik ang maliliit na kahilingan, at ang unang malaking paglilipat ay natigil. Ang pattern na ito ay tumuturo sa MTU ng landasin bago pa man tumuro sa throughput. Bawat kawing sa ruta ay naglilimita sa laki ng packet, at ang encapsulation ay gumagastos ng bahagi ng allowance na iyon sa mga panlabas na header, kaya ang panloob na packet ay dapat mas maliit kaysa sa ipinahihiwatig ng hilaw na landasin. Tahimik ang pagkabigo, at iyon ang dahilan kung bakit mahal itong i-diagnose.

Ano ba talaga ang sinusukat ng MTU ng landasin

Ang MTU ng landasin ay ang pinakamaliit na link MTU sa ruta sa pagitan ng dalawang host, hindi ang MTU na nakalimbag sa iyong lokal na interface. Ang lokal na halaga ang simula ng pagtatantiya, at ang landasin ang magpapasya kung saan ito dapat magtapos. Ito ang dahilan kung bakit ang magkatulad na tunel ay maaaring gumana sa isang access network at matigil sa iba: nagbago ang ruta, hindi ang configuration. Ang magsukat nang isang beses at magpalagay sa lahat ng dako ang pagkakamaling nagpapanatili sa problemang ito.

Para sa isang tunel, ang mahalagang numero ay ang panloob na MTU, na siyang allowance ng panlabas na landasin na binawasan ng kinokonsumo ng encapsulation. Ang WireGuard ay nagdaragdag ng panlabas na IP header at UDP header; ang ibang transport ay nagdaragdag ng kanilang sarili. Itakda ang panloob na sukat nang masyadong mataas at bawat full-size packet ay mangangailangan ng fragmentation na maaaring hindi kailanman mangyari.

Bakit binabawasan ng tunel ang nagagamit na packet

Kung pinapanatili ng tunnel interface ang MTU ng pisikal na kawing, bawat malaking packet ay umaasa sa kung may handang mag-fragment nito sa ibaba ng ruta. Pinapayagan ito ng IPv4 sa prinsipyo, ngunit ang router na sinabihang huwag mag-fragment ay nagbabalik ng error sa halip. Ang mga IPv6 router ay hindi kailanman nagfa-fragment sa transit, kaya ang parehong setting ay kumikilos nang iba ayon sa address family. Sa anumang paraan, walang natututuhan ang nagpapadala hanggang may mag-ulat pabalik.

Ang praktikal na bunga ay isang sukat na kasya sa handshake ngunit hindi sa payload. Ang TLS ClientHello o DNS query ay sapat na maliit upang tumawid sa pinaliit na landasin nang hindi natatamaan, samantalang ang malaking paglilipat ay hindi. Kaya nagkukumpol ang mga sintomas sa paligid ng partikular na operasyon, hindi partikular na host.

Gumagana lamang ang pagtuklas kapag dumarating ang feedback

Ang pagtuklas ng IPv4 ay umaasa sa don't-fragment bit: ang router na hindi maipadala ang packet ay nagbabalik ng ICMP fragmentation-needed kasama ang MTU ng susunod na hop, at ibinababa ng nagpapadala ang tantiya nito. Ang IPv6 ay gumagamit ng Packet Too Big na mensahe sa halip, dahil ang mga router ay hindi nagfa-fragment sa transit. Ipinapalagay ng parehong mekanismo na mahahanap ng mensahe ang daan pabalik sa nagpapadala, sa pamamagitan ng tunel at lampas sa anumang firewall sa return path. Kapag nabigo ang palagay na iyon, patuloy na sinusubukan ng nagpapadala ang sukat na hindi kayang dalhin ng landasin.

Ang firewall na pumapayag sa echo request at echo reply ay hindi kinakailangang pumayag sa mga uri ng error na iyon. Ang ICMP ay isang pamilya, at ang mga miyembrong mahalaga dito ay ang mga error, hindi ang echo pair. Suriin ang patakaran ng control traffic sa magkabilang dulo ng tunel at sa rutang nasa pagitan, at sundan ang sinusuportahang gabay ng platform sa halip na payagan ang bawat uri ng ICMP saanman.

Ang parehong pag-filter ay maaaring nasa loob ng tunel. Kung itinatapon ng panloob na landasin ang error ngunit dinadala ito ng panlabas, maaaring umangkop ang nagpapadala sa limitasyong hindi kailanman talagang nakikita ng naka-encapsulate na trapiko.

Subukan ang landasin sa halip na hulaan ang numero

Panatilihing fixed ang destinasyon, access network at tunel, pagkatapos ay baguhin lamang ang laki ng packet. Ang don't-fragment test na nabigo na may MTU hint ay nagbibigay ng limitasyon ng susunod na hop; ulitin hanggang may sukat na pumasa, at itala ang sukat at ang address family.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Ang ping na kasya ay hindi nagpapatunay na kasya ang full-size na segment ng tunay na aplikasyon, kaya ulitin ang test gamit ang paglilipat na talagang nabigo. Ihambing ang pinakamalaking gumaganang test sa MTU ng tunel na inayos mo, at panatilihing hiwalay ang dalawang numero sa iyong mga tala. Kung magkaiba sila nang humigit-kumulang isang header, natagpuan mo ang encapsulation overhead at hindi isang depekto.

Ang PLPMTUD, na inilarawan sa RFC 4821, ay sumusubok pataas at gumagamit ng transport acknowledgements sa halip na magtiwala sa naihatid na error. Nakakatulong ito sa mga landas na nagfi-filter ng ICMP, ngunit iba-iba ang suporta ayon sa stack at application. Ang TCP flow ay maaaring gumaling mag-isa habang ang UDP application na may fixed datagram size ay patuloy na nabigo.

Pumili ng halaga at itala ang katwiran

Ang pagbaba ng MTU ng tunel ay parehong diagnosis at lehitimong pag-aayos kapag alam mo na ang landasin. Hindi ito kapalit ng pag-alam kung aling landasin at aling feedback mechanism ang sangkot, dahil ang halagang naayon sa mobile link ay magiging hindi kinakailangang maliit sa fiber connection. Itala ang piniling sukat, ang test na nagpatunay nito at ang rollback step.

Ang mekanismong IPv4 ay inilarawan sa RFC 1191 at ang gabay sa IPv6 packetization sa RFC 8201; ang pagbanggit sa pareho ay pumipigil sa susunod na inhinyero na muling kunin ang palagay. Kung ang paglilipat ay natigil pa rin sa sukat na pinili mo, itigil ang pagbaba ng numero at tingnan ang susunod na layer. Ang landas na nabigo sa bawat sukat ay hindi problema sa MTU.