Bakit ang pagharang sa lahat ng ICMP ay sumisira sa gumaganang VPN path
Ang mga mensahe ng feedback sa laki ay hindi ping replies. Kapag hindi sila dumarating, pumapasa ang maliliit na packet, nawawala ang malalaki, at parang nanginginig ang tunnel.
Ang tunnel na nagpapatotoo, nagdadala ng ping at pagkatapos ay natigil sa unang malaking paglilipat ay ang klasikong tanda ng nawawalang mensahe ng ICMP, hindi ng sirang VPN. Hindi kailanman nalalaman ng nagpapadala na masyadong malaki ang packet, inuulit ang parehong laki, at naghihintay ang aplikasyon. Ang pag-aayos nito ay desisyon sa patakaran ng firewall, hindi muling pag-install ng kliyente. Mahalaga ang pagkakasunod-sunod: sukatin kung saan naroon ang hangganan ng laki, pagkatapos ay paliitin ang panuntunang lumamon sa ulat.
Ano ang tunay na dinadala ng ICMP sa path na ito
Pagtuklas ng MTU ng path na IPv4 umaasa sa router na mag-ulat na ang packet na may bit na don't-fragment ay hindi maipadala. Ang ulat na iyon ay mensaheng ICMP Fragmentation Needed, at kung wala ito ay walang dahilan ang nagpapadala na bawasan ang laki ng segment. Ang IPv6 ay mas mahigpit: hindi nag-fragment ang mga router sa transit, kaya ang mensaheng ICMPv6 Packet Too Big ang tanging senyales na nagpapaliit sa nagpapadala.
Ang dalawang mensahe ay feedback ng control plane, at wala sa kanila ang diagnostic echo. Ang patakarang naghaharangan ng ping at ang patakarang naghaharangan ng lahat ng ICMP ay magkamukha sa listahan ng panuntunan ngunit ibang-iba ang kilos sa network. Ang pangalawa ay maaaring gawing one-way na path ang isang tamang sukat na tunnel para sa anumang mas malaki kaysa pinakamaliit na link sa kadena.
Ang ilang transport ay nagpapatupad ng sariling pagtuklas gamit ang probe packets, gaya ng inilalarawan ng RFC 4821, at mas kaunti ang pag-asa nila sa feedback na ito. Ito ay argumento para suriin kung aling transport ang pinapatakbo mo, hindi para ipagpalagay na immune ang bawat tunnel.
| Mensahe | Layunin sa path | Kung naharang |
|---|---|---|
| ICMPv4 uri 3 code 4 | Masyadong malaki ang packet para sa susunod na link | Patuloy na umuulit ang nagpapadala at natitigil |
| ICMPv6 uri 2 | Packet Too Big, ang katumbas sa IPv6 | Parehong pagtigil, walang alternatibong fragmentation |
| ICMP uri 11 | Lumampas ang oras, ginagamit ng traceroute | Nawawalan ng hop ang diagnostic, dumadaloy pa rin ang trapiko |
| Kahilingan at tugon ng echo ng ICMP | Pagsubok ng maabot | Nabigo ang ping, maaaring maayos ang path |
Nakadepende ang pagpalya sa laki
Itanong kung ang pagpalya ay may kaugnayan sa laki ng packet. Ang login page, DNS query at maikling API call ay pumapasa, habang ang pag-upload ng file, malaking tugon o pag-download ng larawan ay natitigil. Ang pattern na ito ay tumutukoy sa limitasyon ng laki sa pagitan ng dalawang dulo, hindi sa pagpapatotoo o routing. Ang matagumpay na maliit na ping ay halos walang sinasabi tungkol sa kung saan naroon ang hangganang iyon.
Sa loob ng tunnel may dalawang layer na dapat isaalang-alang: ang payload packet at ang panlabas na encapsulated packet. Ang panloob na nagpapadala ay maaaring kumilos nang tama habang ang panlabas na path ay mas maliit kaysa ipinapalagay ng tunnel, kaya mahalaga kapwa ang sariling MTU setting ng tunnel at ang pisikal na link sa ilalim nito.
Sukatin bago i-edit ang mga panuntunan
Subukan gamit ang bit na don't-fragment at laki ng payload na ikaw ang pipili, mula sa palpak na kliyente patungo sa protektadong address:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7Ang payload na 1472 byte kasama ang 28 byte na header ay packet na 1500 byte. Kung nabigo ang malaking probe dahil sa error sa fragmentation at pumasa ang maliit, natagpuan mo ang hangganan; isaayos para sa overhead ng tunnel at ulitin hanggang maging matatag ang gumaganang laki.
Pagkatapos ay tiyakin na ang agwat ay ang ulat mismo. Kung tahimik na nabigo ang probe, walang error at walang tugon, malamang itinatapon ang mensahe sa halip na inihahatid, at ang panuntunan ang pinaghihinalaan.
Paliitin ang panuntunan, pagkatapos ay subukan muli ang gawain
Dapat pahintulutan ng pagwawasto ang mga partikular na control message, hindi ang buong protocol. Sa host na may iptables ang anyo ay pagtanggap na partikular sa uri; iangkop ang syntax sa kung ano ang namamahala sa firewall sa iyong platform:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTHayaang harangin ang mga tugon ng echo kung iyon ang lokal na patakaran, dahil hindi ito kailangan ng path. Pagkatapos ay subukan muli ang paglilipat na orihinal na nabigo, mula sa bagong koneksyon, at tiyaking ipinapakita ng mga counter ng panuntunan na dumarating ang mga mensahe.
Kung natitigil pa rin ang malaking paglilipat matapos pahintulutan ang mga mensahe, ang natitirang limitasyon ay nasa ibang lugar: MTU ng tunnel na masyadong mataas, proxy na nagsusulat muli ng packet, o middlebox na nagtatapon sa halip na nag-uulat. Kailangan ang panuntunan ng ICMP, hindi sapat.