OpenConnect хуудсууд туннелийн MTU-г буулгах хүртэл яагаад гацдаг вэ

Нэвтрэлт амжилттай болж, порталын нүүр хуудас зурагдана, дараа нь хянах самбарын виджет эсвэл тайлан хөтөч бууж өгөх хүртэл waiting for host төлөвт үлддэг. Нийтийн сайтууд бүх хугацаанд хэвийн ачаалагдаж, ямар ч нэвтрэх мэдээлэл өөрчлөгдөөгүй. Жижиг хариултууд ирж, том нь гацаж байгаа нь хандалтын дүрэм биш, пакетийн хэмжээний дээд хязгаарын шинж юм. Профайлд өөр зүйл өөрчлөхөөс өмнө энэ дүгнэлтийг баталгаажуулаарай.

Хэмжээний асуудлыг бодлогоос тусгаарла

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

Механизм нь инкапсуляц юм. Дотоод пакет бүр туннелийн толгойг авдаг тул физик холбоосонд багтаж байсан ачаа цаашид багтахгүй гадаад пакет болж, do-not-fragment бит агуулсан бүхэн хөтөчийн ойлгох хариултгүйгээр хаягдана.

do-not-fragment пробаар дээд хязгаарыг хэмж

Таамаглахын оронд хязгаарыг хэмж. Фрагментлэхийг үгүйсгэдэг проба илгээж, хариулт ирэх хүртэл ачааг алхам алхмаар буулга, үүнтэй төстэй командаас эхэл: ping -M do -s 1472 host. DF тогтоосон үед фрагментлэх шаардлагатай гэж гомдоллосон хариулт нь утга хараахан хэт өндөр байгааг илтгэнэ. 1462 дээр, дараа нь 1452 дээр давтаж, хариулт өгдөг эхний хэмжээ дээр зогс. Тоог туршсан хостоосоо хамт бичиж ав, учир нь хариулт тэр замд хамаарна, ерөнхийдөө протоколд биш.

Туннель үнэхээр трафик илгээдэг хаягийг шалга. Гарцын нийтийн нэрний эсрэг гадаад проб ба дотоод серверийн эсрэг дотоод проб өөр үсрэлтүүдийг хэмждэг бөгөөд аль нэгэн дээрх ICMP шүүлт эрүүл замыг эвдэрхий харагдуулж болно.

Утгыг туннелийн төхөөрөмжид хэрэглэ

Үр дүнг Wi-Fi адаптерт биш, клиентийн үүсгэсэн интерфейсд хэрэглэ. Linux клиент дээр энэ нь ip link set dev tun0 mtu 1300 , дараа нь утга хүлээн авсныг батлахын тулд ip link show tun0. Клиентийн мэдээлдэг төхөөрөмжийн нэрийг ашигла, учир нь энэ нь хэрэгжүүлэлт болон туннелийг хэрхэн бүтээснээс хамаарч өөрчлөгддөг.

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

Эхлээд клиентийн өөрийн MTU хүсэлтүүдийг ашигла

Дуудлагыг та хянаж байгаа үед клиент дараа нь засагдахын оронд хэмжээ хүсч болно. --mtu серверээс туннелийн MTU хүснэ, --base-mtu доод замын MTU-г зарлаж, гарц туннелийн тоог гаргаж чадна. Хоёулаа хүсэлт бөгөөд клиентийн гарын авлага гарц аль нэгийг нь биелүүлнэ гэж амладаггүй.

Энэ ялгаа нь ажлын дарааллыг тодорхойлно. Эхлээд хүсэлтийг туршиж, үүсгэсэн интерфейсийг шалга, дараа нь гарцын сонгосон утга гацсаар байвал төхөөрөмжийг локалаар тогтоох руу буц.

Бүтэлгүйтсэн дамжуулалтаар баталгаажуулж, дараа нь тогтвортой болго

Локал ip link өөрчлөлт нь клиент туннелийг дахин бүтээх хүртэл үргэлжилнэ, энэ нь дараагийн дахин холболт эсвэл үргэлжлэлд тохиолдоно. Утгыг холболт эхлэх газарт тавь: клиентийг ажиллуулж, дараа нь төхөөрөмжийг тохируулдаг бүрхүүл, ExecStartPost алхамтай systemd нэгж, эсвэл гарц хүлээн зөвшөөрвөл клиентийн сонголт. Профайлын хажууд хувилбарын хяналтад байлга, дараагийн хүн тоо яагаад тэнд байгааг харна.

Бүтэлгүйтсэн хүсэлтээр турш, нүүр хуудсаар биш. Тайланг нээ, хавсралтыг татаж ав, эсвэл гацсан репозитори татахыг ажиллуул, дахин гацвал яг хаана зогсдогийг тэмдэглэ. Өөрчлөлтийн дараа зурагддаг хуудас бага зүй нотолдог, учир нь өмнө нь ч зурагддаг байсан.

Хэрэв ижил дамжуулалт ижил цэг дээр гацвал, MTU онол батлагдаагүй. Туннель дээрх трафикийг барьж аваад тоог дахин өөрчлөхөөс өмнө аль тал илгээхээ зогсоохыг шалга, өмнөх утгыг бичиж үлдээ, буцаах нь нэг команд хэвээр байх болно.