دوبارہ بوٹ کے بعد SSH سن نہیں رہا: VPN پتہ دیر سے آتا ہے

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

بائنڈ خرابی دراصل کیا کہتی ہے

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

ترتیب کی درستی اور رن ٹائم تیاری الگ خصوصیات ہیں۔ دونوں کو جانچیں، کیونکہ ان میں سے ایک کچھ کہے بغیر ناکام ہو جاتی ہے۔

کس عمل کے پاس پورٹ ہے

ڈیمن ہمیشہ وہ جزو نہیں ہوتا جو سننے والا بناتا ہے۔ ساکٹ ایکٹیویشن اس ذمہ داری کو ایک یونٹ پر منتقل کرتی ہے، اور پھر ڈیمن کو دوبارہ شروع کرنے سے کچھ نہیں بدلتا۔

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

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

تیاری کو واضح کریں، نیند نہیں

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

ip -4 addr show dev tun0
systemctl edit ssh.service

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

صاف بوٹ اور دوبارہ کنکشن کی جانچ کریں

سب کچھ آن لائن ہونے کے بعد دستی ری اسٹارٹ بوٹ ترتیب کے بارے میں کچھ ثابت نہیں کرتا۔ ٹنل کو خود کار طریقے سے اوپر آنے کے لیے ترتیب دے کر مشین دوبارہ بوٹ کریں اور دیکھیں کہ سننے والا بغیر مداخلت ظاہر ہوتا ہے یا نہیں۔

systemctl status ssh.service
ss -ltnp 'sport = :22'

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

کامیابی کا معیار وہ سننے والا ہے جو اپنی دستاویزی انحصار کے تحت ظاہر ہوتا ہے، نہ کہ وہ جسے کسی نے دوبارہ شروع کرنا یاد رکھا۔