VPN-ээр дамжуулах зам MTU-г илрүүлэх: хэмжээ ба ICMP-ийн завсар

Туннель гар барилтаагаа дуусгаж, жижиг хүсэлтүүд буцаж ирдэг ч эхний том дамжуулалт гацдаг. Энэ хэв маяг нь дамжуулах чадвараас хамаагүй эрт замын MTU-г зааж байна. Маршрутын дагуух холбоос бүр пакетын хэмжээг хязгаарладаг ба инкапсуляци нь тэр зөвшөөрлийн нэг хэсгийг гадаад толгойд зарцуулдаг тул дотоод пакет түүхий зам санал болгохоос бага байх ёстой. Алдаа нь чимээгүй, тэгэхээр үүнийг оношлоход үнэтэй болгодог.

Замын MTU яг юу хэмждэг вэ

Замын MTU нь хоёр хост хоорондын маршрут дахь хамгийн бага холбоосын MTU бөгөөд таны локал интерфэйс дээр хэвлэгдсэн MTU биш. Локал утга нь үнэлгээ эхлэх цэг бөгөөд зам нь хаана дуусах ёстойг шийддэг. Ийм учраас ижил туннель нэг хандалтын сүлжээнд ажиллаж нөгөөд гацаж болно: маршрут өөрчлөгдсөн, тохиргоо биш. Нэг удаа хэмжиж хаа сайгүй таамаглах нь энэ асуудлыг амьд байлгадаг алдаа юм.

Туннелийн хувьд чухал тоо нь дотоод MTU бөгөөд энэ нь гадаад замын зөвшөөрлөөс инкапсуляцийн зарцуулдаг хэмжээг хассан утга юм. WireGuard гадаад IP толгой ба UDP толгой нэмдэг; бусад тээвэр өөрсдийнхөө нэмдэг. Дотоод хэмжээг хэт өндөр болговол бүрэн хэмжээтэй пакет бүрт хэзээ ч тохиолдохгүй фрагментаци шаардлагатай болно.

Туннель яагаад ашиглагдах пакетыг багасгадаг вэ

Хэрэв туннелийн интерфэйс физик холбоосын MTU-г хадгалбал том пакет бүр доорх хэн нэгэн үүнийг фрагментлэхэд бэлэн байхаас хамаарна. IPv4 үүнийг зарчмын хувьд зөвшөөрдөг ч фрагментлэхгүй гэж заасан маршрутизатор оронд нь алдаа буцаадаг. IPv6 маршрутизаторууд дамжуулалтын үед огт фрагментлэдэггүй тул ижил тохиргоо хаягийн гэр бүлээс хамаарч өөрөөр ажилладаг. Ямар ч байсан илгээгч ямар нэгэн зүйл буцаж мэдээлэх хүртэл юу ч сурахгүй.

Практик үр дагавар нь гар барилтад багтах ч ачаанд багтахгүй хэмжээ юм. TLS ClientHello эсвэл DNS асуулга нь багассан замыг хөндөгдөхгүй туулахад хангалттай жижиг бол масс дамжуулалт тийм биш. Тиймээс шинж тэмдгүүд тодорхой хост биш тодорхой үйлдлүүдийн эргэн тойронд бөөгнөрдөг.

Буцах мэдээлэл ирсэн үед л илрүүлэлт ажиллана

IPv4 илрүүлэлт нь don't-fragment битэд тулгуурладаг: пакетыг цааш дамжуулж чадахгүй маршрутизатор дараагийн үсрэлтийн MTU-тай ICMP fragmentation-needed буцаадаг ба илгээгч үнэлгээгээ бууруулдаг. IPv6 оронд Packet Too Big мессеж ашигладаг, учир нь маршрутизаторууд дамжуулалтын үед фрагментлэдэггүй. Хоёр механизм мессеж нь туннелиэр дамжин буцах замд байгаа аливаа галт ханыг даван илгээгч рүү буцах замаа олно гэж таамагладаг. Тэр таамаг бүтэлгүйтвэл илгээгч зам дааж чадахгүй хэмжээг дахин дахин оролдсоор байна.

echo request болон echo reply-г зөвшөөрдөг галт хана тэдгээр алдааны төрлийг заавал зөвшөөрсөн байх албагүй. ICMP бол нэг гэр бүл бөгөөд энд чухал гишүүд нь алдаанууд, эхо хос биш. Туннелийн хоёр төгсгөл болон тэдгээрийн хоорондох замд хяналтын урсгалын бодлогыг шалгаж, хаа сайгүй ICMP-ийн бүх төрлийг зөвшөөрөхийн оронд платформын дэмжсэн удирдамжийг дагана уу.

Мөн адил шүүлт туннелийн дотор байж болно. Хэрэв дотоод зам алдааг хаяад гадаад зам түүнийг дамжуулбал илгээгч инкапсуляцлагдсан урсгал хэзээ ч үнэхээр хардаггүй хязгаарт дасан зохицож болно.

Тоог таамаглахын оронд замыг туршиж үзээрэй

Очих газрыг, хандалтын сүлжээ болон туннелийг тогтмол үлдээж, зөвхөн пакетын хэмжээг өөрчил. MTU зөвлөмжтэй бүтэлгүйтдэг don't-fragment туршилт танд дараагийн үсрэлтийн хязгаарыг өгнө; ямар нэг хэмжээ тэнцэх хүртэл давтаж, хэмжээ болон хаягийн гэр бүлийг хоёуланг нь тэмдэглэ.

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

Багтах ping нь бодит аппликейшны бүрэн хэмжээтэй сегментүүд багтана гэдгийг батлахгүй тул бодитоор бүтэлгүйтсэн дамжуулалттай туршилтыг давтана уу. Хамгийн том ажилласан туршилтыг таны тохируулсан туннелийн MTU-тай харьцуулж, хоёр тоог тэмдэглэлдээ тусад нь хадгал. Хэрэв тэд ойролцоогоор нэг толгойн хэмжээгээр ялгаатай бол та алдаа биш инкапсуляцийн нэмэлт зардлыг олсон байна.

RFC 4821-д тайлбарласан PLPMTUD дээшээ туршиж, хүргэгдсэн алдаануудад итгэхийн оронд тээврийн баталгаажуулалтыг ашигладаг. Энэ нь ICMP шүүдэг замд тусалдаг ч дэмжлэг нь стек болон аппликейшнаас хамаарч өөр өөр байдаг. TCP урсгал өөрөө сэргэж болох бол тогтмол датаграмын хэмжээтэй UDP аппликейшн бүтэлгүйтсээр байна.

Утгыг сонгож, үндэслэлийг тэмдэглэ

Туннелийн MTU-г бууруулах нь оношлогоо ба мөн хууль ёсны засвар юм, замыг мэдсэний дараа. Энэ нь аль зам, аль буцах мэдээллийн механизм оролцсоныг мэдэхийг орлохгүй, учир нь гар утасны холбоост тааруулсан утга шилэн холболт дээр шаардлагагүй бага байх болно. Сонгосон хэмжээ, түүнийг зөвтгөсөн туршилт, буцаах алхмыг тэмдэглэ.

IPv4 механизмыг RFC 1191-д, IPv6 пакетжуулалтын удирдамжийг RFC 8201-д тайлбарласан; хоёуланг нь нэрлэснээр дараагийн инженер таамаглалыг дахин гаргахгүй. Хэрэв таны сонгосон хэмжээнд дамжуулалт гацсаар байвал тоог бууруулахаа болиод дараагийн давхаргыг хараарай. Бүх хэмжээнд бүтэлгүйтдэг зам нь MTU-ийн асуудал биш.