په کارپوریټ VPN کې د کانټینر HTTPS ودرېده؟ د 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 تجربې پاتې شوی.