Контейнер дэх HTTPS корпорацийн VPN-д гацаж байна уу? DTLS хөлийг шалгаарай

Корпорацийн VPN-ийн ард байгаа контейнер дотор DNS шийдэгдэж, нэвтрэх хуудас ачаалагдаж, эрүүл мэндийн төгсгөлийн цэг хариулж, дараа нь HTTPS хүсэлт хугацаа дуустал гацдаг. Имижийг дахин бүтээх, прокси хувьсагчдыг өөрчлөх нь юу ч өөрчлөхгүй, учир нь эвдэрсэн хэсэг имиж дотор байхгүй. Клиент нэг тээврийн замаар баталгаажиж, том өгөгдлийг нөгөөгөөр дамжуулдаг бөгөөд зөвхөн хоёр дахь нь эвдэрсэн.

Хоёр тээврийн зам, нэг будлиантай шинж тэмдэг

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

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

Зөн совингоор биш, туршлагаар шийдээрэй

Хамгийн хямд туршилт UDP өгөгдлийн сувгийг унтрааж, хүсэлтийг давтана. Ширээний бүрхүүлийн оронд командын мөрний клиент ашиглаарай, ингэснээр туг үнэхээр хэрэгжинэ: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Хэрэв гацаж байсан хүсэлт одоо дуусвал асуудал DTLS хөл байсан, үлдсэн нь чимээ.

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

Хэрэв туг засвал яагаад гэдгийг шийдээрэй

Гурван нөхцөл ижил шинж тэмдэг үүсгэдэг бөгөөд өөр өөр хариу шаарддаг. Зам UDP-г бүрэн шүүж болох бөгөөд энэ нь тугийг тухайн сүлжээний зөв байнгын хариулт болгоно. Зам UDP-г зөвшөөрч, гэхдээ том датаграммуудыг хаяж болох бөгөөд энэ нь шүүлт биш MTU-г заана. Эсвэл зам маш их алдагдалтай байж, UDP хөл TCP-ээс муу ажиллаж болох бөгөөд энэ нь багтаамжийн шийдвэр, хүртээмжийн бус.

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

Тойрч гарах шийдлийг үлдээхээс өмнө багцын хэмжээг шалгаарай

Хэрэв шалтгаан нь хэмжээ бол туннелийн интерфейс зам дааж чадахгүй багцуудыг хүлээж авдаг бөгөөд ачаалал өсөхөд аль ч тээврийн замд асуудал эргэн ирдэг. Интерфейсүүдийг харьцуулаарай: хост дээр ip link show tun0, дараа нь сүлжээний тохиргоонд бүртгэгдсэн MTU-г уншихын тулд docker network inspect bridge. Бага зөөдөг туннелийн дор одоо ч 1500 байт дээр байгаа контейнер гүүр бол ердийн олдвор.

Туннель дотор хуваахыг хориглох туршилтаар мэдэгдэж буй сайн хэмжээнээс дээш зондлоорой, дараа нь контейнер сүлжээний MTU-г буулгах эсвэл туннель дээр TCP MSS-ийг чангалаарай. Аль ч засвар UDP замыг дахин ашиглахуйц болгож, тугийн хэрэгцээг арилгадаг нь шүүлт шалтгаан биш үед илүү сайн үр дүн юм.

Юугаар солилцоход бэлэн байгаагаа шийдээрэй

Өгөгдлийн суваг унтарсан үед туннель ачаагаа TCP холболтын дотор зөөдөг. Цэвэр замд энэ зүгээр л удаан; алдагдалтай замд нэг алдагдсан сегмент араас нь бүгдийг хойшлуулж, гадаад давтан дамжуулалт дотоодтой өрсөлддөг. Энэ солилцоо интерактив хөгжүүлэлт, жижиг API дуудлагад тохирдог, том дамжуулалт эсвэл мобайл холболт дээрх урт сессид муу тохирдог.

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