FreeBind بمقابلہ After=: systemd ساکٹ کو VPN پتے سے باندھنا

بوٹ کے وقت مقررہ VPN پتہ باندھنے والی ساکٹ اکائی ٹنل کے اسے تفویض کرنے سے پہلے ناکام ہو سکتی ہے، اور اس کے پیچھے کی سروس کبھی شروع نہیں ہوتی۔ دو سوئچ حل لگتے ہیں اور اس مسئلے کے الگ الگ نصف حصے حل کرتے ہیں۔ FreeBind systemd کو سننے والا بنانے دیتا ہے جبکہ پتہ ابھی موجود نہیں۔ After= صرف کاموں کی ترتیب لگاتا ہے، اس لیے یہ بدلتا ہے کہ چیزیں کب شروع ہوتی ہیں، مگر پتہ جلدی نہیں آتا۔

دو الگ مسائل، دو الگ سوئچ

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

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

FreeBind: پتے سے پہلے سننے والا موجود

FreeBind کرنل سے کہتا ہے کہ غیر مقامی پتے پر باندھنے کی اجازت دے، تاکہ systemd بوٹ پر سننے والا ساکٹ بنا سکے اور جب بھی ایپلیکیشن شروع ہو اسے دے سکے۔ ساکٹ ایکٹیویشن کا مقصد یہی ہے، اور ساکٹ اپنے پیچھے کی سروس سے زیادہ دیر تک زندہ رہ سکتا ہے، اس کی وجہ بھی یہی ہے۔

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

خالی تفویض نئی اندراج شامل کرنے سے پہلے وینڈر اکائی سے وراثت میں ملنے والی سماعت کی اندراجات صاف کرتی ہے، جو ہر انٹرفیس پر جواب دینے والے بچے ہوئے wildcard سننے والے کو روکتی ہے۔ پتہ اور پورٹ اپنے سے بدلیں اور صرف drop-in فائل نہیں، موثر اکائی کی تصدیق کریں۔ پیکیج فائل کو اس کی جگہ پر ترمیم کرنے کے بجائے اکائی کے نام کے تحت drop-in استعمال کریں، کیونکہ اگلی پیکیج تازہ کاری ترمیم کو مٹا دے گی اور ارادے کا کوئی نشان نہیں چھوڑے گی۔ پھر اسے ساکٹ اکائی کی متوقع دوبارہ لوڈ اور دوبارہ شروع کرنے کی کارروائی سے نافذ کریں۔

systemd ساکٹ حوالہ اس اختیار کے پیچھے IPv4 اور IPv6 کا رویہ درج کرتا ہے، اور اہم تفصیل یہ ہے کہ یہ باندھنے پر لاگو ہوتا ہے، روٹنگ پر نہیں۔ اس میں کچھ بھی پتہ تفویض نہیں کرتا یا VPN شروع نہیں کرتا۔ FreeBind سننے والے کو دی گئی اجازت ہے، انٹرفیس کا متبادل نہیں۔

After= اور Wants=: ترتیب تیاری نہیں

ترتیب اور ضرورت الگ محور ہیں، اور انہیں ملانا ایسی اکائیاں بناتا ہے جو درست ترتیب میں شروع ہو کر بھی ناکام ہوتی ہیں۔ After=vpn-client.service کا مطلب صرف یہ ہے کہ اگر دونوں کام شروع ہوں تو یہ دوسرے کے شروع ہونے کا انتظار کرتا ہے۔ یہ VPN کو کھینچ کر نہیں لاتا، اور VPN کے جڑنے کے مکمل ہونے کا انتظار بھی نہیں کرتا۔

Wants= اور Requires= جیسی ضرورت کی ہدایات فعال کرنے کا کام کرتی ہیں، اور انحصار ناکام ہونے پر کیا ہوتا ہے اس میں مختلف ہیں: ایک جاری رہتی ہے، دوسری رک جاتی ہے۔ کسی کو بھی معلوم نہیں کہ جڑی ہوئی ٹنل کا کیا مطلب ہے۔ VPN عمل پتہ تفویض کیے بغیر بھی فعال ہو سکتا ہے، یا پتہ تفویض ہونے کے باوجود ساتھی تک راستہ نہ ہونے کی حالت میں، اور دونوں حالتیں انحصار پوری کرتی ہیں۔ اگر ایپلیکیشن کو پتے کا موجود ہونا ضروری ہو تو عمل کے شروع ہونے کو تیاری کا ثبوت سمجھنے کے بجائے اس شرط کو واضح طور پر ماڈل کریں۔

systemctl cat اور systemctl show -p After -p Wants -p Requires سے جانچیں کہ اکائی واقعی کیا اعلان کرتی ہے۔ تین الگ ڈائریکٹریوں کے drop-in ایسی ہدایات شامل کر سکتے ہیں جو آپ نے کبھی نہیں لکھیں، اور systemd صرف موثر اکائی پڑھتا ہے۔

network-online.target جو نہیں کرتا

network-online.target کے بعد ترتیب دی گئی اکائی انتظار کرتی ہے کہ نیٹ ورک مینیجر نیٹ ورک کو قابلِ استعمال قرار دے، جو بوٹ کا ہم آہنگی نقطہ ہے، مستقل شرط نہیں۔ یہ نہیں بتاتی کہ کوئی مخصوص ٹنل اوپر ہے یا نہیں، اور دوپہر کے بعد VPN کے دوبارہ جڑنے پر یہ دوبارہ نہیں چلے گی۔ اسے دوبارہ کنکشن کا مانیٹر سمجھنا اس ہدف کی سب سے عام غلط قرأت ہے۔

systemd منصوبہ اس فرق کو براہِ راست درج کرتا ہے، اور عملی نتیجہ یہ ہے کہ ٹنل کے پتے کی ضرورت رکھنے والی ہر چیز کو انحصار خود رکھنا ہوگا۔ جو اکائی network-online کا انتظار کر کے پھر ٹنل کا پتہ باندھتی ہے، وہ صرف اسی وقت درست ہے جب ٹنل اتفاقاً پہلے اوپر آئے، اور یہ اتفاق ہے، ڈیزائن نہیں۔

جو زندگی کا چکر آپ نے واقعی چنا، اسے جانچیں

صاف بوٹ، پتہ آنے کے بعد کی درخواست، اور VPN کے گر کر واپس آنے کے بعد کا رویہ جانچیں۔ وہ تین صورتیں کام کرنے والے سننے والے کو کام کرنے والی سروس سے الگ کرتی ہیں۔

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

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

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