سرور یا کلائنٹ: دوہرے کردار والے Pi پر کون سا OpenVPN یونٹ

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

یونٹ کے نام کو اُس ڈائریکٹری سے ملا دیں جو وہ لوڈ کرتا ہے

Upstream 2.6 دو ٹیمپلیٹ یونٹ مہیا کرتا ہے، [email protected] اور [email protected]۔ سرور ٹیمپلیٹ /etc/openvpn/server میں شروع ہوتا ہے اور وہاں سے %i.conf لوڈ کرتا ہے۔ کلائنٹ ٹیمپلیٹ /etc/openvpn/client میں شروع ہوتا ہے۔ roaming نامی انسٹینس بیک وقت دونوں جگہوں پر موجود ہو سکتا ہے، سرور اور کلائنٹ کے طور پر، دو غیر متعلقہ کنفیگریشنز کے ساتھ اور اسٹرنگ کے سوا ان کے درمیان کوئی ربط نہیں۔

فائل سسٹم کی بجائے systemd سے پوچھیں، کیونکہ پیکیج بنانے والے اضافی فائلیں شامل کرتے ہیں جو کام کرنے والی ڈائریکٹری یا بائنری کو ملنے والے دلائل بدل سکتی ہیں۔

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

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

پیکٹ کی سمت سے فیصلہ کریں، انٹرفیس کے نام سے نہیں

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

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

نظریہ بنانے سے پہلے ساکٹ دیکھیں۔ udp/1194 سے بندھا سرور سننے والا ساکٹ دکھاتا ہے۔ کلائنٹ فراہم کنندہ کے پتے کے ساتھ تعلق دکھاتا ہے اور سننے والا کچھ بھی نہیں۔

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

ایک انسٹینس کا ڈیفالٹ راستہ دوسرے کے جوابات پکڑ سکتا ہے

اوپر والا کلائنٹ جو redirect-gateway دھکیلتا ہے وہ مشین پر باقی سب کے ساتھ مقابلہ کرنے والا ڈیفالٹ راستہ نصب کرتا ہے، جن میں وہ جوابات بھی شامل ہیں جو سرور گھومنے پھرنے والے صارفین کو بھیجتا ہے۔ OpenVPN اپنے ساتھی کے پتے کے لیے استثنا کرتا ہے تاکہ سرنگ قابل رسائی رہے، لیکن وہ استثنا ہوٹل کے نیٹ ورک پر پڑے فون کے بارے میں کچھ نہیں کہتا۔

علامت عموماً غیر متناسب ہوتی ہے۔ مصافحہ مکمل ہوتا ہے، کلائنٹ جڑا ہونے کی اطلاع دیتا ہے، اور پہلے جوابی پیکٹ کے بعد ٹریفک مر جاتا ہے۔ ماخذ کی بنیاد پر پالیسی روٹنگ، یا سرور انسٹینس پر --mark کے ساتھ لگایا گیا پیکٹ مارک، دونوں بہاؤؤں کو الگ رکھتا ہے؛ ان میں سے کوئی بھی اکیلا مکمل قواعد کا مجموعہ نہیں، اور دونوں کو اس جدول میں درست راستے درکار ہیں جو وہ منتخب کرتے ہیں۔

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

ip route get 203.0.113.44
ip rule show

ایک کردار دوبارہ شروع کریں اور ثابت کریں کہ دوسرا بچ گیا

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

تبدیلی سے پہلے رکنے کی شرط لکھیں: کیا اوپر والی سرنگ کا ضائع ہونا گھومنے پھرنے والے صارفین کو روکتا ہے، یا یہ Pi کے اپنے اوپر والے لنک پر لوٹ جاتا ہے؟ DNS اور IPv6 کو بھی واضح جواب چاہیے، کیونکہ دھکیلا گیا حل کنندہ اکثر اس راستے سے زیادہ زندہ رہتا ہے جس نے اسے مفید بنایا۔

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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