IPv6 багц хэт том: том VPN дамжуулалт яагаад зогсдог
Жижиг хариултууд ирдэг ч том дамжуулалтууд нэг л туннелээр зогсдог. Илгээгч замын хэмжээг хэзээ ч мэдээгүй бөгөөд шүүгдсэн хяналтын мессеж үүнийг тайлбарладаг.
Ping ажиллаж, хөтөч жижиг хуудсыг ачаалж, файл дамжуулалт зогсдог — бүгд нэг л туннелиар IPv6 дээр. Энэ хэв маяг нь ихэвчлэн туннель удаан гэсэн үг биш, харин илгээгч замын бодит хэмжээг хэзээ ч мэдээгүй гэсэн үг. IPv6 нь чиглүүлэгчид Packet Too Big мессежээр асуудлыг мэдээлнэ гэж хүлээдэг бөгөөд инкапсуляци нь багц гадаад сүлжээнд хүрэхээс өмнө нэмэлт ачаалал нэмдэг. Хэрэв тэр мессежийг шүүж хаявал илгээгч нэвтэрч чадахгүй хэмжээг давтан илгээсээр байна.
Жижиг хүсэлт, том зогсолт
Туннель багц бүрийг өөр нэг толгойд боож, дотроос ашиглах боломжтой хэмжээ гаднаас бага байна. Инкапсуляцийн өмнө физик холбоосод хэмжсэн багц дараа нь хэт том болдог. IPv4 чиглүүлэгчид замд хувааж болох бол IPv6 чиглүүлэгчид илгээгчийн өмнөөс үүнийг хийдэггүй тул илгээгч өөрөө зохицох ёстой. Энэ зохицол нь буцах холбоо хүлээн авахаас бүрэн хамаардаг.
Нэг мессеж алдагдсан ч хангалттай сонгодог шинж тэмдэг үүснэ: гар барилт болон жижиг хариултууд амжилттай болж, харин хавтасны жагсаалт эсвэл байршуулалт тэр болгонд нэг цэг дээр зогсдог. Хэрэглэгчид үүнийг VPN удаан гэж дүрсэлдэг бөгөөд логууд баталгаажуулалтад ямар ч алдаа харуулдаггүй. Хоёр ажиглалт хоёулаа зөв бөгөөд аль нь ч алдааны байршлыг олохгүй байна.
Packet Too Big бол буцах холбоо, трафик биш
ICMPv6 Packet Too Big мессеж нь дараагийн үсрэлт хүлээн авч болох хэмжээг агуулдаг бөгөөд илгээгч үүнийг өөрийн тооцоог бууруулахад ашигладаг. Үүнийг шүүх нь замын тэмдгийг авч хаяад дараа нь жолоочдыг буруутгахтай адил. Бүх ICMPv6-г хаях дүрэм хатуу харагдах боловч түүнд хэрэгтэй холбоос бүрт зам илрүүлэлтийг эвддэг. Энэ мессеж нь замын тухай хяналтын мэдээлэл, програмын ачаа биш.
Сонгомол шүүлтүүр нь зохистой хэвээр байна. Цуурай хүсэлт болон хөршийн илрүүлэлт нь алдааны мессежээс өөр үүрэгтэй бөгөөд бодлого тэдэнд өөрөөр хандаж болно. Бүх протоколыг хүлээн авах эсвэл хаяхын оронд платформын баримтжуулсан шүүлтүүрийн зааврыг дагаарай, учир нь RFC 8201 тэр буцах холбоо илрүүлэлтийг хэрхэн удирдаж байгааг тодорхойлдог.
Хоёр хаягийн гэр бүлийг тусад нь шалгана уу
IPv6-г тусад нь шалгаарай, учир нь амжилттай IPv4 дамжуулалт IPv6 замын тухай юу ч батлахгүй. Дараа нь том дамжуулалт зогсож байх үед хяналтын мессежүүдийг барьж ав. Хоёр бичлэг хамтдаа буцах холбоо гарч байгааг харуулах эсвэл энэ нь хэзээ ч хүрээгүй гэдгийг батална.
ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'
Проб нь do-not-fragment битийг тавьсан багцыг илгээж, тэр нь бүтэлгүйтэх хэмжээг мэдээлдэг — энэ бол туннель багтаах ёстой тоо. Замын асуулга нь очих газрыг зөөх интерфейсийг нэрлэдэг тул аль холбоосын MTU үйлчилж байгааг та мэднэ. Барилт нь ICMPv6 2-р төрөл буюу Packet Too Big мессежийг шүүж, тэр нь энэ хостод хүрч байгаа эсэхийг харуулна. Хэрэв мессеж барилтад харагдаж, дамжуулалт зогссоор байвал илгээгч үүнийг үл тоомсорлож байна, энэ нь мөрдөн шалгалтыг сүлжээнээс стек рүү зөөдөг.
Туннелийн хэмжээг зөвхөн баримт нотолгооны дараа өөрчил
Туннелийн MTU-г буулгах нь шүүгдсэн мессежийг нууж, шинж тэмдгийг арилгаж болох ч багц бүрт илүү их ачааллын зардлаар. Энэ нь шийдэл биш харин тойрч гарах арга бөгөөд барилтыг орлуулахын оронд түүний дараа явах ёстой. Дур мэдэн бага утга нь харагдах зүйлийг эвддэггүй тул конфигурацид олон жил үлддэг. Үүнийг санаатайгаар өөрчилж, утгыг бичиж, ямар хэмжилт үүнийг зөвтгөснийг тэмдэглэ.
Хэрэв та гарцыг удирдаж байгаа бол галт ханыг унтраахын оронд мессежийг хаях дүрмийг шалгаарай. Нэг зассан дүрэм бодлогын үл хамаарах зүйлээс илүү нарийн бөгөөд дараа нь хамгаалахад хамаагүй хялбар. Мөн адил логик тайм-аутад хамаарна: зогсолт бүр хэмжээний асуудал биш бөгөөд хоёрыг ялгадаг зүйл нь барилт юм.