OpenVPN گھر میں کام کرتا ہے مگر ایک نیٹ ورک پر نہیں: UDP یا TCP؟

وہی پروفائل گھر سے جڑتا ہے اور ہوٹل، کیمپس یا برانچ نیٹ ورک پر رک جاتا ہے۔ اسناد تبدیل نہیں ہوئیں، اس لیے دلچسپ متغیر راستہ ہے: OpenVPN پیکٹ پڑھنے سے پہلے ان کے ساتھ کیا ہوتا ہے۔ چار ممکنہ وجوہات کا اسی ترتیب سے موازنہ کرنا جس میں انہیں جانچا جا سکتا ہے سرٹیفکیٹس کے بارے میں اندازہ لگانے سے بہتر ہے۔ ہر ایک مختلف نشان چھوڑتا ہے، اور نشان ہی انہیں الگ کرتا ہے۔

کون سا مرحلہ ناکام ہوا یہ بتاتا ہے کہ کون سا موازنہ اہم ہے

کلائنٹ لاگ پہلے ہی درج کرتا ہے کہ آپ کتنی دور گئے۔ وہ سطر کہ TLS کلید مذاکرات وقت کی حد میں نہیں ہوئے، کا مطلب ہے پہلا پیکٹ نکلا اور کوئی قابل استعمال جواب واپس نہیں آیا، جو راستے کی طرف اشارہ کرتا ہے۔ سرٹیفکیٹ کا انکار بالکل مختلف دکھتا ہے: جواب آتا ہے، پھر کوئی مخصوص تصدیقی خرابی وجہ بتاتی ہے۔ دوبارہ کوشش کے لوپ سے پہلے آخری سطر نوٹ کریں، کیونکہ نیٹ ورکس کے درمیان آپ اسی قدر کا موازنہ کرتے ہیں۔

بعد میں نہیں، دوبارہ کوشش کے دوران کیپچر کریں۔ کلائنٹ پر tcpdump -ni any udp port 1194 دکھاتا ہے کہ کوئی جواب واپس آتا ہے یا نہیں۔ آپ جس سرور کو کنٹرول کرتے ہیں اس کے WAN انٹرفیس پر اسے دہرائیں، جو ظاہر کرتا ہے کہ وہ پیکٹ دور کے سرے تک پہنچتے ہیں یا نہیں۔

یک طرفہ ٹریفک یہاں دستیاب سب سے مفید نتیجہ ہے، کیونکہ یہ وقفے وقفے کی شکایت کو تحقیقات کی سمت میں بدل دیتا ہے۔ کیپچر فائلیں رکھیں، کیونکہ اسی مسئلے کی اگلی رپورٹ تفصیل کے بجائے ثبوت سے بند کرنا آسان ہے۔

UDP فلٹرنگ اور بند پورٹ

بہت سے رسائی نیٹ ورک مسلسل UDP کو مشکوک سمجھتے ہیں، اور کچھ ISP بھی متفق ہیں۔ بند پورٹ کلائنٹ کی طرف سے وہی خاموشی پیدا کرتا ہے۔ فرق انتخابییت ہے: فلٹر اس بارے میں چنندہ ہوتا ہے کہ کون سے منزل یا پورٹ چھوڑے، جبکہ بند پورٹ اس پورٹ کی طرف بھیجی گئی ہر چیز کو مسترد کرتا ہے۔

پورٹ 443 پر TCP پروفائل معمول کا حل ہے، کیونکہ یہ عام HTTPS بہاؤ جیسا لگتا ہے اور زیادہ تر کیپٹیو پورٹل اور اخراجی فلٹر عبور کرتا ہے۔ دو شرطیں پوری ہونی چاہئیں۔ سرور کو proto tcp-server کے ساتھ سننا چاہیے اور کلائنٹ کو proto tcp-client سے میل کھانا چاہیے، اور آپریٹر کو وہ متبادل اینڈ پوائنٹ شائع کرنا چاہیے۔ چلتی ہوئی 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 کا جواز بھی بنتا ہے۔