Synology پر OpenVPN ہینڈ شیک ناکام؟ LAN فارورڈنگ چیک کریں

آپ کا لیپ ٹاپ بتاتا ہے کہ TLS ہینڈ شیک ناکام ہو گیا، اس لیے سرٹیفکیٹ دوبارہ بنانے کا لالچ ہوتا ہے۔ اس سے پہلے زیادہ بیزار کن سوال پوچھیں: Synology واقعی کس Ethernet پورٹ پر سن رہا ہے؟ دو LAN پورٹ والے NAS کے دو پتے ہوتے ہیں، اور DSM کا VPN Server پیکج اپنے OpenVPN سامع کو ان میں سے ایک سے باندھتا ہے۔ جب راؤٹر 1194 کو دوسرے پتے کی طرف فارورڈ کرتا ہے تو کوئی پیکٹ خدمت تک نہیں پہنچتا، اور کلائنٹ کے پاس بات چیت کے لیے کچھ نہیں ہوتا۔

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

وہ پتہ تلاش کریں جس سے سامع بندھا ہے

DSM اپنے پورٹس کو LAN 1 اور LAN 2 کہتا ہے، اور ہر ایک کا الگ پتہ اور سب نیٹ ہے۔ VPN Server کھولیں، OpenVPN ٹیب میں دیا گیا انٹرفیس پڑھیں، پھر Control Panel کھول کر وہ IPv4 پتہ لکھ لیں جو DSM کے پاس اسی انٹرفیس پر ہے۔ فارورڈ کو یہی دو قدریں بتانی ہیں، NAS کا ہوسٹ نام نہیں۔

دوسری کیبل لگانے سے دوسرا سامع نہیں بنتا۔ دونوں لنک جڑے دکھ سکتے ہیں جبکہ صرف ایک پتہ ٹریفک وصول کرتا ہے، اور جب دونوں انٹرفیس ایک ہی سب نیٹ میں ہوں تو دونوں پتے ایک ایسے ہندسے میں مختلف ہوتے ہیں جسے اصول محفوظ کرنے سے پہلے کوئی دوبارہ نہیں پڑھتا۔

SSH کے ذریعے خود ساکٹ کو دیکھیں، کیونکہ ڈیمون واقعی کس چیز سے بندھا ہے یہ صرف یہیں نظر آتا ہے، سیٹنگز صفحے کا ارادہ نہیں۔

sudo netstat -anp | grep 1194

نیا شامل کرنے کے بجائے موجودہ فارورڈ میں ترمیم کریں

ایک بیرونی پورٹ کے لیے دو اصول راؤٹر کو انتخاب کی آزادی دیتے ہیں، اور وہ کون سا چنے گا یہ فرم ویئر اپ ڈیٹ یا ری بوٹ کے بعد بدل سکتا ہے۔ جو اصول پہلے سے موجود ہے اسے کھولیں، اس کا اندرونی پتہ بدلیں، محفوظ کریں، پھر اسے دوبارہ کھول کر قدر پڑھیں۔ اصول کو خدمت کے نام پر رکھنا مدد کرتا ہے، کیونکہ پانچ یکساں فارورڈز کی فہرست ہی غلط کے بچنے کا طریقہ ہے۔

external 1194/udp  ->  192.0.2.20:1194/udp

اندرونی پورٹ کو سننے والے پورٹ کے برابر رکھیں، اور پروٹوکول یکساں رکھیں۔ UDP 1194 ڈیفالٹ سامع ہے، جبکہ TCP پروفائل کو پیکج کی طرف اپنا سامع اور راؤٹر پر مطابق فارورڈ درکار ہے۔ صرف UDP پر سننے والی خدمت کی طرف TCP فارورڈ کرنے سے خرابی نہیں، خاموشی ملتی ہے۔

اگر NAS کا پتہ DHCP سے آتا ہے تو اصول محفوظ کرنے سے پہلے اسے ریزرو کریں۔ لیز کی مدت ختم ہونے پر پتہ دوبارہ دیا جاتا ہے، فارورڈ پرانی قدر کی طرف اشارہ کرتا رہتا ہے، اور جس دن کسی نے NAS کو نہیں چھوا اس دن ہینڈ شیک ناکام ہونے لگتا ہے۔ NAS کی طرف مستقل ترتیب اسی مسئلے کو حل کرتی ہے، بشرطیکہ پتہ راؤٹر کی DHCP حد سے باہر ہو۔

ثابت کریں کہ پیکٹ واقعی پہنچتے ہیں یا نہیں

پہلے NAS پر کیپچر شروع کریں، پھر کلائنٹ سے جڑیں، اور آؤٹ پٹ میں ماخذ پتہ پڑھیں۔ ناکامی کے بعد شروع کیا گیا کیپچر کچھ نہیں دکھاتا اور کچھ ثابت نہیں کرتا۔

sudo tcpdump -i any -n udp port 1194

خاموشی کا مطلب ہے کہ ٹریفک خدمت تک پہنچنے سے پہلے مر گیا: غلط اندرونی پتہ، DSM فائر وال پر بند پورٹ، یا انتظامی طور پر بند انٹرفیس۔ آؤٹ پٹ میں پیکٹ ہوں تو فارورڈ کام کر رہا ہے، اور باقی خرابی نیٹ ورک تہہ سے اوپر ہے، جو بہت چھوٹا تلاش کا علاقہ ہے۔

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

جب پیکٹ پہنچیں تو فارورڈ کو الزام دینا بند کریں

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

نقل و حمل ایک اور عدم مطابقت ہے جسے واضح طور پر جانچنا چاہیے، کیونکہ پروفائل اور پیکج مختلف جگہوں پر ترمیم ہوتے ہیں۔ پیکج بدلے بغیر پروفائل کو UDP سے TCP کرنے سے کلائنٹ ایسے سامع کا انتظار کرتا ہے جو موجود نہیں، اور کلائنٹ وہی عام ہینڈ شیک متن بتاتا ہے جو ہر اور چیز کے لیے بتاتا ہے۔ فائل میں proto سطر پڑھیں، پھر سرور صفحے پر چنا گیا پروٹوکول دیکھیں، اور اسی کے بعد نتیجہ نکالیں کہ دونوں مطابق ہیں۔ DSM فائر وال اصول پڑھنا تیسری جانچ ہے: وہ اصول جو پورٹ کو مقامی سب نیٹ سے کھولتا ہے مگر انٹرنیٹ سے نہیں، جانچ کے بعد چھوڑ دینا آسان ہے، اور یہ ایسا کنکشن بناتا ہے جو باورچی خانے سے کام کرتا ہے اور ہر دوسری جگہ سے ناکام ہوتا ہے۔

وہ راستہ آزمائیں جو دور دراز صارف واقعی طے کرتا ہے

اسی LAN کے اندر کا کلائنٹ فارورڈ کو کبھی چھوئے بغیر NAS تک پہنچ سکتا ہے، اس لیے یہ دور دراز رسائی کے بارے میں کچھ ثابت نہیں کرتا۔ Wi-Fi بند والا فون استعمال کریں، یا نیٹ ورک سے باہر کسی سے پوچھیں، اور اس کوشش کے دوران راؤٹر کاؤنٹر دیکھیں۔ اگر دور دراز کوشش ناکام ہو اور مقامی کامیاب ہو تو فارورڈ یا فائر وال اب بھی تصویر میں ہے۔

جو حالت کام کر رہی ہے اسے کام کرتے وقت لکھیں: بیرونی پورٹ، اندرونی پتہ، پروٹوکول، پیکج انٹرفیس، اور پروفائل کا نام اور برآمد کی تاریخ۔ جب ہینڈ شیک دوبارہ ناکام ہو تو اس نوٹ اور موجودہ ترتیب کا فرق ہی خرابی ہے، اور کسی کو دوبارہ تلاش کرنے کی ضرورت نہیں کہ خدمت دو پورٹس میں سے کون سا استعمال کرتی ہے۔