UDP هغه وخت چټک نه دی: د OpenVPN د ترانسپورت غوراوی

هر لارښود وايي چې د OpenVPN لپاره UDP له TCP غوره دی، او دا سلا یو ډیفالټ ده، نه اندازه کول۔ ترانسپورت بدلوي چې بنډلونه څنګه رسول کېږي او کله چې لاره هغه غورځوي څه پېښېږي، نه دا چې تونل څنګه کوډ کېږي۔ د کپټیف پورټال یا د پروکسۍ شاته چې یوازې پورټ 443 ته اجازه ورکوي، ورو غوراوی هغه دی چې اصلاً نښلېږي۔ لاندې برخه هغه څه چې پروتوکول کوي له هغه څه جلا کوي چې ستاسو د لاسرسي شبکه یې اجازه ورکوي۔

ترانسپورت واقعاً څه بدلوي

TCP یو باوري، منظم بایټ جریان وړاندې کوي او هر هغه څه بیا لېږي چې ورک شي، لکه څنګه چې RFC 9293 ټاکي۔ UDP ډاټاګرامونه شبکې ته سپاري، او OpenVPN پر هماغه ساکټ خپله باورېدونکې طبقه چلوي۔ TCP په TCP کې دننه کول دوه د بیا رغېدو کړۍ یو پر بل ږدي، نو یو ورک شوی برخه کولای شي دننی جریان ونیسي تر څو چې بهرنی بیا لېږل ورسېږي۔ همدا متقابل عمل د UDP لپاره ریښتینی دلیل دی، او دا د لېږد تېزۍ پر ځای د ځنډ په توګه څرګندېږي۔

اغېزه د ضایع کېدو او د تګ-راتګ وخت سره زیاتېږي۔ په پاکه ځایي لاره کې دواړه ترانسپورتونه یو شان احساس کېږي، نو ځکه لابراتواري ازموینه شکایت بیا کم تولیدوي۔ په بوخت موبایل لینک کې توپیر په متقابلو ناستو کې ډېر ژر څرګندېږي، تر دې چې لوی لېږد څه وپېژني۔

له دې څخه هیڅ هم محرمیت یا بشپړتیا ته نه رسېږي۔ د TLS لاس ورکول او د معلوماتو د کانال کوډ دواړو ترانسپورتونو لپاره یو شان دي، نو بدلون نشي کولای کمزوری کوډ سیټ وژغوري۔

TCP خپل ځای چېرې ګټي

د لاسرسي شبکې د TCP د غوراوي معمول دلیل دی۔ هوټل، هوایی ډګر یا د مېلمنو شبکه کېدای شي بهر وتونکي 443 ته اجازه ورکړي او نور هر څه وغورځوي، او په هغه پورټ کې TCP اورېدونکی یوازینی کار کوونکی پروفایل دی۔ دا رسېدنه ده، نه کارکردگی، او په خپله کافي ښه دلیل دی۔

TCP هغه وخت هم مرسته کوي چې لاره ثابته وي خو منځني بکسونه دښمنانه وي۔ ځینې شبکې اوږدمهاله UDP جریانونه بیا تنظیموي خو د عادي ویب ترافیک په څېر TCP ناستې زغمي۔ چې دا ورته والی بریالی کېږي که نه، د هغې ځانګړې شبکې ځانګړتیا ده، او هیڅ لارښود نشي کولای د ټولو لپاره یې ژمنه وکړي۔ د پروتوکول په تورنولو مخکې په هغه شبکه کې چې ناکامېږي ازموینه وکړئ۔

رد شوی ننوتل د ترانسپورت ستونزه نه ده۔ د اړیکې د زور د تېرولو لپاره د سند تصدیق بندول بله بدلون دی چې پایله یې ډېره بدتره ده۔

د TCP پروفایل چمتو ساتل عملي جوړجاړی دی۔ ډیری کلاینټونه دواړه ساتي او کله چې شبکه د UDP لاره رد کړي بدلون ته اجازه ورکوي، چې تر اړتیا پورې هیڅ لګښت نه لري۔ هغه څه چې نه باید وکړئ دا دي چې دوه پروفایلونه ولېږئ چې بېلو پای ټکو ته اشاره کوي، ځکه بیا ستاسو پرتله سرورونه اندازه کوي۔

وګورئ چې واقعاً کوم اورېدونکی لرئ

د کارکردگی پرتله کولو مخکې تایید کړئ چې دواړه خواوې په ترانسپورت او پورټ موافق دي۔ په کلاینټ فایل کې proto udp په proto tcp بدلول سرور اورېدونکی نه جوړوي۔ سرور باید د هغه پروتوکول لپاره تنظیم شوی وي، او پروفایل باید ورسره سمون ولري۔

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep چاپوي چې سرور ته څه د کارولو ویل شوي، په داسې حال کې چې دوه ساکټ لیستونه ښيي چې له څه سره تړلی دی۔ UDP اورېدونکی یوازې په لومړي لیست کې او TCP اورېدونکی یوازې په دویم کې ښکاري، نو ورک ليکه د هغه پروفایل موندلو تر ټولو ژر لار ده چې هیڅکله نه دی پلي شوی۔ پورټ هم پرتله کړئ، ځکه په 1194 کې TCP پروفایل په ډیرو لاسرسي شبکو کې له 443 سره توپیر لري۔ له بدلون وروسته خدمت بیا پیل کړئ او هغه لاګ کرښه ولولئ چې تړل راپور کوي۔

د کلاینټ خوا تایید ارزانه دی: اړیکه د --verb 4 سره چلاوه او په لاګ کې د ترانسپورت کرښه ولولئ۔ که کلاینټ UDP وايي خو سرور پر TCP اورېدل کوي، لاس ورکول هیڅکله نه پیلېږي او هیڅ تنظیم به مرسته ونه کړي۔

کاري بار پرتله کړئ، نه د ترانسپورت لیبل

منصفانه پرتله هر څه پرته له ترانسپورت ثابت ساتي۔ هماغه وسیله، هماغه لاسرسي شبکه، هماغه هدف هوسټ، هماغه اپلیکیشن او په غوره توګه هماغه سرور۔ که دوه پروفایلونه بېلو هوسټونو ته اشاره وکړي، تاسو هغه هوسټونه هم اندازه کوئ۔

د هر چلښت لپاره درې پایلې ولیکئ: تونل جوړېږي که نه، پاتې کېږي که نه او دنده بشپړېږي که نه۔ کوچني غوښتنې چې کار کوي خو لوی لېږدونه بندېږي، دا د ترانسپورت نه، د بنډل اندازې او MTU ښکارندوی دی۔ تکراري بیا نښلېدلې لارې یا د منځني بکس وخت پای ته اشاره کوي۔

هغه پروفایل وساتئ چې په هغو شرایطو کې کار کوي چې واقعاً ورسره مخامخ کېږئ، او بل یې هم خوندي وساتئ۔ غوراوی د شبکې دی، د کس نه، نو ځکه هر یو ډیفالټ ځواب یو ځای غلط دی۔