VPN-ийн MTU домог: таны пакетууд яагаад багасч, зай хаашаа явдаг вэ

Хэн нэгэн танд VPN "MTU-ийн улмаас пакет алдаж байна" гэж хэлэхэд та туннелийг 1400-д тавьж, дамжуулалт дахин ажиллаж эхэлдэг. Тэр үр дүн онош мэт санагддаг. Ихэвчлэн энэ нь арифметикийн санамсаргүй таарц юм: та хэзээ ч тодорхойлоогүй хязгаараас доош багтах хангалттай бага тоог сонгосон бөгөөд дараагийн сүлжээнд өөр төсөвтэйгээр мөн тэр хязгаартай дахин тааралдана.

Үүний ихэнхийг хоёр домог үүсгэдэг. Эхнийх нь туннелийн интерфейсийн MTU нь замын MTU юм. Хоёр дахь нь инкапсуляци "нэг толгой" үнэтэй, PPPoE нь тоолох үнэ цэнэтэй юу ч үнэгүй. Хоёулаа таны сонгосон тоо дур зоргоороо мэт харагдуулах боловч бодитдоо тодорхойлогдсон гэдгээрээ буруу.

Эхний домог: туннелийн MTU нь замын MTU

Туннелийн интерфейс дээр тавьсан утга нь хэрэгжилт доош өгөх хамгийн том дотоод пакетийн тухай орон нутгийн амлалт юм. Замын бодит багтаамж нь таны болон холын төгсгөлийн хоорондох холбоос бүрийн шинж чанар бөгөөд маршрут өөрчлөгдөх, гар утасны холболт шилжих, эсвэл урсгал өөр peering авах үед өөрчлөгдөж болно. Тохируулсан 1500 нь таны хост юу бүтээхийг хэлнэ, сүлжээ юу зөөхийг биш.

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

Хоёр дахь домог: инкапсуляци нэг толгой үнэтэй

Гадаад давхаргуудыг шударгаар тоол. Гадаад IP толгой нь IPv4-д 20 байт эсвэл IPv6-д 40 байт. NAT-аар гарах UDP инкапсуляци 8 нэмнэ. Туннелийн протокол өөрийн толгой, эхлүүлэх вектор эсвэл nonce, шифрийн блок эсвэл зэрэгцүүлэх хязгаар хүртэл дүүргэлт, төгсгөлийн хэсэг, бүрэн бүтэн байдлын шалгалтын утгыг нэмнэ. Протокол, шифрээс хамааран нийт дүн дотоод пакет эхлэхээс өмнө аравт байтад хүрдэг.

Дараа нь дотоод пакетийн өөрийн толгойнуудыг дахин хас. Туннелийн доторх TCP сегмент өөрийн 20 байтын IP толгой, 20 байтын TCP толгойг зөөдөг бөгөөд TCP-ийн MSS нь MTU-аас гаралтай, туннелийн нэрлэсэн ачаанаас биш. Тиймээс ping бага ачаатай амжилттай болох боловч файл дамжуулалт гацах нь: хэрэгслүүд өөр өөр зүйлийг шалгадаг бөгөөд зөвхөн нэг нь бүрэн хэмжээтэй TCP сегментийг ашигладаг.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Эхний команд нь тохируулсан туннелийн MTU-г мэдээлнэ. Хоёр шалгалт 1472 байтын ачаа илгээдэг бөгөөд энэ нь IPv4 ба ICMP толгойнуудын 28 байттайгаа 1500 байтын пакет, дараа нь бага. Том шалгалт бүрэн бүтэлгүйтэж, жижиг нь амжилттай болвол танд хэмжээнээс хамааралтай гэмтэл байна, ерөнхий маршрутын асуудал биш.

Гурав дахь домог: PPPoE одоо ч танд цэвэр 1500 өгдөг

Ердийн PPPoE хандалтын холбоос 1500 байтын IP пакет зөөдөггүй. PPPoE толгой болон PPP протоколын талбар Ethernet хүрээ дотор 8 байт эзэлдэг бөгөөд IP пакетэд 1492 үлддэг. Энэ бол RFC 2516-д тодорхойлсон уламжлалт хязгаар юм. Хэрэв ийм холбоос дээгүүр VPN ажиллуулбал туннелийн нэмэлт зардал 1500-аас биш, тэр 1492-оос гардаг.

RFC 4638 нь хандалтын концентратор болон хэрэглэгчийн төхөөрөмж хоёулаа дэмжсэн тохиолдолд илүү том PPP ачааны талаар хэлэлцэх аргыг тодорхойлдог тул "энэ холболт PPPoE ашигладаг" гэдэг нь дангаараа тодорхой тоог нотолдоггүй. Орон нутгийн тохиргоо нь завсрын төхөөрөмжийг хэзээ ч тохируулаагүй пакетыг хүлээн авахыг албадаж чадахгүй тул ашигтай асуулт нь шошго юу гэж хэлж байгаа биш, холбоос бодитоор юу тохиролцсон бэ гэдэг.

Гэмтэл яагаад сонгомол харагддаг вэ

Жижиг хүсэлтүүд амжилттай болж, том дамжуулалтууд гацах нь замын MTU-ийн хар нүхний сонгодог шинж юм. Гар барилт, DNS асуулга, API дуудлага бүгд багтана; бөөн дамжуулалт нэг холбоос дээр үхэх бүрэн хэмжээтэй сегментүүдийг үүсгэдэг бөгөөд асуудлыг мэдээлэх ёстой байсан ICMP мессеж хэзээ ч ирдэггүй. Холболт хэвийн харагдаж, татаж авалт өлгөгдөх нь хүмүүсийг зам руу биш сервер рүү харахад хүргэдэг.

Хоёр дахь, холбоотой алдаа нь гурван тоог хольж болох юм: интерфейсийн MTU, TCP-ийн MSS, протоколын өөрийн фрагментлэл эсвэл дүүргэлтийн тохиргоо. Маршрутизатор дээрх MSS шахац нь зарласан MSS-ийг дахин бичиж, илгээгч жижиг сегментүүд бүтээдэг; энэ нь туннелийн MTU-г өөрчлөхгүй, UDP урсгалд туслахгүй. Гурвуулаа хамааралтай мэт харагддаг тул ижил тоо өгөх нь сайн санаатай өөрчлөлт ажиллаж буй тохиргоог эвддэг арга юм.

Юуг, ямар дарааллаар өөрчлөх вэ

Нотолгоогоор эхэл. Дээрх шалгалтуудаар гэмтэл хэмжээнээс хамааралтайг баталж, дараа нь дахин гарч буй хамгийн бага хэмжээ болон бүтэлгүйтэх хамгийн том хэмжээг олоорой. Туннелийг буруутгахаас өмнө хандалтын холбоосын бодит MTU-г шалга; PPPoE холбоос таны VPN хүрэхээс өмнө төсвийг хязгаарладаг. Өөрчлөлтийг буцаах боломжтой байлгахын тулд анхны утгуудыг тэмдэглэ.

Дараа нь клиентийн баримталсан хамгийн бага тохируулгыг хэрэглэ. Олон клиент туннелийн MTU болон MSS засварын сонголтыг санал болгодог бөгөөд MSS сонголт нь TCP-д илүү сайн хөшүүрэг байдаг, учир нь пакет бүрийг багасгалгүйгээр илгээгчид хүрдэг. Ижил очих газрыг, ижил дамжуулалтыг дахин шалгаж, тогтсон тоонуудаа тэмдэглэ. Нэг хандалтын сүлжээнд ажилладаг туннелийн утга нь бүх нийтийн тогтмол биш бөгөөд дараагийн газар өөрийн төсөвтэй байна.