ٹنل جڑتا ہے، پھر رسائی لنک پر لیز کی تجدید اُسے مار دیتی ہے، اور لاگ راستے کے بجائے ٹائم آؤٹ کو قصوروار ٹھہراتا ہے۔ VPN کنفیگریشن میں کچھ نہیں بدلا، اور یہی اشارہ ہے: اُس کے باہر کچھ بدلا ہے۔ کسی DHCP واقعے نے پتہ یا گیٹ وے دوبارہ لکھا، اور ٹنل کے آخری نقطے کو قابلِ رسائی رکھنے والا ہوسٹ راستہ اب ایسے اگلے ہاپ کی طرف اشارہ کرتا ہے جو اب موجود نہیں۔ یہ روٹنگ مسئلے سے پہلے ملکیت کا مسئلہ ہے۔

علامت کا آدھے ڈیفالٹ راستوں سے موازنہ کریں

redirect-gateway def1 کے ساتھ، OpenVPN ڈیفالٹ راستہ بدلنے کے بجائے 0.0.0.0/1 اور 128.0.0.0/1 نصب کرتا ہے۔ دونوں مل کر پوری پتہ جگہ ڈھانپ لیتے ہیں، اور صرف سابقے کی لمبائی سے 0.0.0.0/0 کو ہرا دیتے ہیں۔ اسی لیے زیادہ مخصوص میچ کے بغیر کوئی بھی منزل ٹنل میں داخل ہوتی ہے۔

آخری نقطے کو ایک استثنا چاہیے۔ آدھے ڈیفالٹ داخل ہونے سے پہلے OpenVPN اصل رسائی گیٹ وے کے ذریعے سرور کے پتے تک ہوسٹ راستہ شامل کرتا ہے، تاکہ کیپسول شدہ پیکٹ باہر جا سکیں۔ جب وہ استثنا غائب ہو جائے، یا ایسا اگلا ہاپ رکھے جو اب موجود نہیں، تو ٹنل کے اپنے بیرونی پیکٹ آدھے ڈیفالٹ سے مل جاتے ہیں اور واپس ٹنل میں بھیج دیے جاتے ہیں۔ نتیجہ ایسا کنکشن ہے جو اگلے کیپ اَلائیو یا ہینڈ شیک پر مر جاتا ہے، اور لاگ میں روٹنگ خرابی جیسی کوئی چیز نہیں۔

کوئی اور چیز چھونے سے پہلے جدول کی شکل کی تصدیق کریں۔ ip route show کو دونوں نصف اور سرور کے پتے کے لیے ہوسٹ راستہ درج کرنا چاہیے؛ ہوسٹ راستہ نہ ہو تو باقی تحقیق کا واضح نقطہ آغاز ہے۔

آدھے ڈیفالٹ میٹرک بدلے بغیر کیوں جیتتے ہیں

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

ip route get 203.0.113.10 سے انتخاب جانچیں، اُس میں سرور کا اصل پتہ ڈال کر۔ جواب وہ انٹرفیس اور اگلا ہاپ بتاتا ہے جو کرنل واقعی استعمال کرتا، اور یہ جدول پڑھ کر اُس پر سوچنے سے زیادہ معلوماتی ہے۔

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

ایک نہیں، تین اسنیپ شاٹ لیں

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

اسنیپ شاٹس کو ٹائم اسٹیمپ کے ساتھ ایک فائل میں رکھیں، کیونکہ بعد میں دلچسپ سوال ترتیب ہے۔ DHCP واقعہ OpenVPN کے اپنا راستہ تازہ کرنے سے پہلے آیا یا بعد میں؟ جواب طے کرتا ہے کہ اِسے کس نے ٹھیک کرنا ہے۔ غلط گھڑی کا ٹائم اسٹیمپ نہ ہونے سے بدتر ہے، اس لیے اِسے روٹنگ جدول رکھنے والے ہوسٹ سے لیں۔

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

طے کریں کہ کون سا جزو استثنا تازہ کرتا ہے

dhcpcd نظام میں، ہکس ہک ڈائریکٹری اور ایگزٹ ہک سے چلتے ہیں، اور مینیجر موڈ دائرے میں فی انٹرفیس موڈ سے مختلف ہے۔ ہک جو بھی کرے، اُسے ایڈمپوٹنٹ ہونا چاہیے، کیونکہ تجدیدیں جھنڈ میں آ سکتی ہیں۔

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

مالک کو کنفیگریشن کے اندر درج کریں۔ اگلی بار دوبارہ جوڑنے کو ڈیبگ کرنے والے شخص کو معلوم ہونا چاہیے کہ استثنا راستے کا ذمہ دار VPN نہیں بلکہ ہک ہے۔

صرف دوبارہ جوڑنے نہیں، زندگی کے چکر کی جانچ کریں

dhcpcd -n eth0 سے یا لیز چھوڑ کر دوبارہ لے کر تجدید پر مجبور کریں، پھر آخری نقطے کے لیے ip route get دوبارہ جانچیں۔ اِسے دو بار کریں، کیونکہ دوسرا دور وہ ہکس پکڑتا ہے جو دہرے راستے شامل کرتے ہیں۔ پھر ری بوٹ کریں، کیونکہ استحکام درستگی سے مختلف وصف ہے۔

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

متعلقہ مضامین