Контейнердеги 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 тажрыйбасынын калдыгыбы, билбейт.