OpenVPN کور کې کار کوي خو په یوه شبکه کې نه: UDP که TCP؟

همغه پروفایل له کوره نښلېږي او په هوټل، کمپس یا څانګې شبکه کې ودرېږي. اعتبارنامې نه دي بدلې شوې، نو د پام وړ بدلونکی لار ده: هغه څه چې پاکټونو ته پېښېږي مخکې له دې چې OpenVPN یې ولولي. د څلورو احتمالي لاملونو پرتله کول په هغه ترتیب چې ازمویل کېدای شي، د سندونو په اړه اټکل کولو ته غوره دی. هر یو بېل نښه پرېږدي، او هغه نښه ده چې دوی جلا کوي.

کوم پړاو ناکام شو، هغه ښیي چې کومه پرتله مهمه ده

د کلاینټ لاګ لا دمخه ثبتوي چې څومره لرې ورسېدل. هغه کرښه چې وایي د TLS کیلي خبرې اترې د وخت په حد کې نه دي شوې، معنا یې دا ده چې لومړی پاکټ ووت او هېڅ ګټور نه راستون شو، چې لارې ته اشاره کوي. د سند رد کاملاً بل ډول ښکاري: ځواب راځي، بیا ځانګړې تصدیق تېروتنه لامل نوموي. د بیا هڅې دورې مخکې وروستۍ کرښه ولیکئ، ځکه هغه ارزښت دی چې د شبکو ترمنځ یې پرتله کوئ.

د بیا هڅې پر مهال ثبت کړئ، نه وروسته. په کلاینټ کې tcpdump -ni any udp port 1194 ښیي چې آیا هېڅ ځواب راستونېږي. هغه په هغه سرور کې تکرار کړئ چې تاسو یې کنټرول کوئ د WAN انټرفیس کې، چې ښیي آیا هغه پاکټونه لرې سر ته رسېږي.

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

د UDP فلټر او بند پورټ

ډېرې لاسرسي شبکې دوامداره UDP شکمن ګڼي، او ځینې ISP ورسره موافق دي. بند پورټ د کلاینټ له اړخه هماغه غلې ښیي. توپیر د انتخابیت دی: فلټر ډېری د دې په اړه غوره کوي چې کوم مقصدونه یا پورټونه پرېږدي، خو بند پورټ هر هغه څه ردوي چې هماغه پورټ ته روان وي.

په 443 پورټ کې TCP پروفایل معمول حل دی، ځکه عادي HTTPS بهیر ته ورته دی او ډېری کپټیو پورټلونه او د وتلو فلټرونه تېروي. دوه شرایط باید وي. سرور باید د proto tcp-server سره واوري او کلاینټ باید د proto tcp-client سره سمون ولري، او عملیات کوونکی باید هغه بدیل endpoint خپور کړي. د کار کوونکي UDP پروفایل بیا لیکل چې TCP 443 يې وبولو، هغه وخت هېڅ نه کوي چې بل اړخ ته څوک نه اوري.

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

زاړه پروتوکولونه په دې محور کې بد ښکاري. PPTP ته TCP 1723 او GRE ته اړتیا ده، او GRE پورټ نه، بلکې IP پروتوکول 47 دی، نو عادي پورټ فوروډ یې نه شي ښودلی.

کله چې سوئیچ پاکټونه پرېږدي

مدیریت شوی سوئیچ کولای شي په قصد ټانل پرېږدي. ځینې HPE او Aruba ماډلونه په خپل پرمختللي امنیت برخه کې د UDP سیلاب ساتنې کنټرول وړاندې کوي، ځینې وختونه د Prevent UDP Blat Attack په نښه. کله چې هغه کنټرول فعال شي، د سوئیچ شاته سرور هېڅ ځواب نه ورکوي او هر کلاینټ په همدې ډول وخت تېروي. هغه لرې کول او روان ترتیب خوندي کول ټوله ترمیم دی، خو یوازې وروسته له دې چې ثابته کړئ سوئیچ واقعاً په لار کې دی.

د مقابلې شاهد هغه څه دي چې د سوئیچ پرېښودنه د عرضه کوونکي له بند څخه جلا کوي. د ISP سره ټکټ پرانیستلو مخکې د انټرفیس شمېرونکي او د سیلاب ساتنې لاګ ولولئ. د DoS یا سیلاب ساتنې سره مصرف کوونکي روټرونه په همدې بڼه ناکامېږي، او همدارنګه هر منځګړی د لنډ UDP بېکاره وخت سره. هغه لاس ورکول چې هېڅکله نه بشپړېږي پرېښودنې ته اشاره کوي، خو هغه ټانل چې د څو دقیقو غلې وروسته مري د وخت حد ته اشاره کوي.

د پروفایل بدلولو مخکې هر وسیله چې د کلاینټ او سرور ترمنځ ده ولیکئ. په غلط طبقه کې تطبیق شوی سمون تر بلې شبکې سم ښکاري. هغه لیست بل انجنیر ته هم وایي چې پرته له ټولې څېړنې له سره چېرته وګوري.

د پتې یو بل ته ننوتل چې د DNS ناکامي په څېر ښکاري

د لاسرسي شبکه چې د 10.0.0.0/8 دننه شمېره شوې ده کولای شي د ټانل حوض سره یو بل ته ننوځي، او resolver معمولاً په هماغه حوض کې اوسېږي. کله چې لپ ټاپ په Wi-Fi کې 10.184.178.50 ته ورته پته د /8 ماسک سره ترلاسه کوي، هر 10.x مقصد د تعریف له مخې سیمه ییز دی. 10.4.0.1 ته پاکټونه بیا LAN ته ځي، ټانل پورته پاتې کېږي، او د نومونو حل ناکامېږي.

ip addr ننوتل په یوه کتنه ښکاره کوي، او ip route get 10.4.0.1 ښیي چې پاکټ به واقعاً چېرته ورسول شي. ځکه چې ښکاره نښه د resolver ناکامي ده، دا ډېری وختونه د DNS بدلونونو څو دورونه ژوندی پاتې کېږي.

حوض بیا شمېره کړئ یا هغه لاسرسي شبکه له حد څخه بهر وساتئ. هېڅ د کلاینټ اړخ ترتیب د ننوتلو څخه نه رغېږي.

د TCP بدیل او د لارې ترمیم ترمنځ انتخاب

کله چې لاره نه کنټرولوئ او کاروونکي نن کار ته اړ دي، TCP بدیل وټاکئ، او لګښتونه یې ومنئ: په TCP کې TCP د زیان سره په لینکونو کې بد چلند کوي، او بدیل ته هغه listener غواړي چې تاسو یې چلوئ. کله چې بند ستاسو په خپله زیربنا وي، د لارې ترمیم وټاکئ، ځکه د اورواګ قاعده له دویم listener څخه ارزانه ده. په هر حال، طبقات په ترتیب سره تېر کړئ: لینک، بهرنی ترانسپورت، خبرې اترې، داخلي روټینګ. هغه پړاو چې په هغه شبکه کې ناکام شو یوازینی مهم حقیقت دی.

پایله د کاروونکي له مخې نه، بلکې د شبکې له مخې ثبت کړئ. د همدې ناکامي بله راپور بیا د سند له تیوري نه نه، بلکې له پیژندل شوي پړاو څخه پیلېږي. هغه ثبت هم هغه څه دي چې د تلپاتې دویم listener توجیه کوي، که کله هم اړتیا وي.