ایک Pi، دو OpenVPN انسٹنسز: ہر یونٹ کیا پڑھتا ہے
ایک Pi پر دو OpenVPN ڈیمونز الگ الگ کنفگ فائلیں پڑھتے ہیں اور الگ الگ ہکس سے باہر نکلتے ہیں۔ ہر انسٹنس کا نقشہ بنائیں، پھر پے لوڈ کا راستہ الگ سے جانچیں۔
پروفائل کو چھونے سے پہلے OpenVPN کے پروسیس گنیں۔ وہ Pi جو رومنگ صارفین کو قبول کرتا ہے اور ساتھ ہی اوپری سروس کو ڈائل کرتا ہے، دو ڈیمونز چلاتا ہے، اور ہر ایک وہ کنفگ فائل پڑھتا ہے جو آپ کے ٹائپ کردہ انسٹنس نام سے منتخب ہوتی ہے۔ پیکج کے ٹیمپلیٹس پھر ہر ڈیمون کو اپنی ورکنگ ڈائریکٹری، اپنی رن ٹائم اسٹیٹس فائل اور اپنا ٹنل ڈیوائس دیتے ہیں۔ اگر یہ تقسیم غلط ہو تو آپ ایک شام ایسی فائل میں درست سیٹنگ بدلتے ہوئے گزاریں گے جسے چلتا ہوا پروسیس کبھی نہیں کھولتا۔
ہر انسٹنس نام اپنی فائل منتخب کرتا ہے
OpenVPN 2.6 کے ساتھ آنے والی یونٹ فائلوں میں، اسٹارٹ آرگیومنٹس میں انسٹنس پلیس ہولڈر ہوتا ہے جو @ نشان کے بعد کے متن سے بھرا جاتا ہے۔ سرور ٹیمپلیٹ سرور کنفگ ڈائریکٹری سے چلتا ہے اور اپنا آرگیومنٹ وہاں موجود %i.conf کے خلاف حل کرتا ہے، جبکہ کلائنٹ ٹیمپلیٹ کلائنٹ ڈائریکٹری سے یہی کرتا ہے۔ چنانچہ [email protected] سرور ڈائریکٹری میں admits.conf پڑھتا ہے اور [email protected] کلائنٹ ڈائریکٹری میں uplink.conf پڑھتا ہے، اور ان ناموں میں سے کسی کا بھی دوسری ڈائریکٹری میں کوئی مطلب نہیں۔
پیکج نے اوپری ڈیفالٹس برقرار رکھے ہیں یہ ماننے کے بجائے مشین پر نقشہ کی تصدیق کریں۔ ڈسٹری بیوشن کا drop-in ورکنگ ڈائریکٹری یا کنفگ آرگیومنٹ کو مکمل طور پر بدل سکتا ہے۔
systemctl cat [email protected]
systemctl cat [email protected]اس آؤٹ پٹ میں WorkingDirectory لائن اور کنفگ آرگیومنٹ پڑھیں، کیونکہ کون سی فائل لوڈ ہوتی ہے یہ صرف فعال یونٹ طے کرتا ہے۔ ExecStart میں --config شامل کرنے والا drop-in ٹیمپلیٹ کے راستے کے درست دکھنے کے باوجود ٹیمپلیٹ کو ہرا دیتا ہے۔ مقامی اوور رائیڈ چل رہا ہے یا نہیں یہ جاننے کے لیے فراگمنٹ اور drop-in کے راستے پوچھیں۔ اگر دونوں کردار ایک ہی فائل پر حل ہوں تو ایک ہی پروسیس سرور اور کلائنٹ دونوں بننے کی کوشش کر رہا ہے، اور اس فائل میں بعد والا آپشن خاموشی سے جیت جاتا ہے۔
مقامی نقل و حمل اور فارورڈ شدہ پے لوڈ الگ الگ ہکس سے ٹکراتے ہیں
سرور کا ہر رومنگ صارف سے خفیہ کردہ کنکشن خود Pi پر بنتا ہے، اس لیے اس کے بیرونی جوابات مقامی آؤٹ پٹ ہک سے باہر نکلتے ہیں۔ کلائنٹ کا اپنے اوپری ساتھی سے کنکشن بھی مقامی طور پر بنا ہوا آؤٹ پٹ ہے، اگرچہ یہ دور دراز نیٹ ورک تک پہنچتا ہے۔ فارورڈ کیا گیا پے لوڈ تیسری قسم ہے، اور کرنل اسے صرف اس وقت ملاتا ہے جب وہ پیکٹ کے لیے باہر جانے والا ڈیوائس پہلے ہی منتخب کر چکا ہو۔
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
فارورڈ چین کے اندر باہر جانے والے انٹرفیس سے ملنے والا قاعدہ اس پیکٹ کو اجازت یا مسترد کر سکتا ہے جو روٹنگ پہلے ہی اس انٹرفیس کو دے چکی ہے، لیکن یہ کبھی انٹرفیس منتخب نہیں کرتا۔ جب ایک ہوسٹ ایک ٹنل ختم کر کے دوسری شروع کرتا ہے تو صارف کا پے لوڈ اوپری ٹنل میں بھیجنے والی پالیسی اور Pi کے اپنے خفیہ جوابات کی حفاظت کرنے والی پالیسی دو الگ فیصلے ہیں۔ وہ اتفاقاً ایک ہی فزیکل NIC پر آ جاتے ہیں، اسی لیے ان میں الجھن ہوتی ہے۔
یہی فرق ایک عام آدھی ناکامی کی وضاحت کرتا ہے۔ صارفین جڑتے ہیں، ہینڈ شیک مکمل ہوتا ہے، پھر بھی ان کا ٹریفک غلط راستے سے نکلتا ہے، کیونکہ ہینڈ شیک مقامی تھا اور پے لوڈ فارورڈ اور دونوں میں سے صرف ایک کی جانچ ہوئی تھی۔
درآمد شدہ راستہ آپ کے صارفین تک جانے والے جوابات نگل سکتا ہے
کلائنٹ پروفائل کی سیکیورٹی سیٹنگ طے کرتی ہے کہ اوپری طرف Pi کی روٹنگ ٹیبل میں کیا push کر سکتی ہے، اور وسیع ری ڈائریکٹ وہ آپشن ہے جو چلتے ہوئے دوہرے کردار والے ہوسٹ کو خراب بنا دیتا ہے۔ اگر push کیا گیا راستہ رومنگ صارفین کے عوامی پتوں کو ڈھانپتا ہے تو سرور کی طرف سے ان کی جانب بنائے گئے جوابات underlay سے باہر جانے کے بجائے نیا راستہ اختیار کر کے اوپری ٹنل میں داخل ہو سکتے ہیں۔ لوگ اکثر تصدیق کرتے ہیں کہ فراہم کنندہ تک ٹنل اب بھی کام کرتی ہے اور وہیں رک جاتے ہیں، کیونکہ وہ ٹریفک خود ٹنل کی نقل و حمل ہے اور باقی سب غلط برتاؤ کرنے کے باوجود بہتی رہتی ہے۔
ماخذ یا mark کی بنیاد پر پالیسی ہی دو بہاؤؤں کو الگ رکھنے کا طریقہ ہے۔ OpenVPN کا Linux mark آپشن ڈیمون کے اپنے خفیہ پیکٹوں پر فائر وال mark لگاتا ہے، جسے پھر روٹنگ قاعدہ مخصوص ٹیبل میں بھیج سکتا ہے۔ ماخذ پتے بھی اتنے ہی اچھے کام کرتے ہیں جب سرور کے بیرونی جوابات ہمیشہ ایک ہی underlay پتے سے نکلتے ہیں۔ دونوں طریقوں کو منتخب شدہ ٹیبل میں درست راستوں اور فراہم کنندہ کے endpoint کے لیے استثنا درکار ہے، ورنہ ٹنل خود ہی نہیں اٹھتی۔
کوئی بھی قاعدہ لکھنے سے پہلے کرنل سے پوچھیں کہ جواب اصل میں کون سا راستہ لے گا۔ نیچے دیے گئے پتے Pi کے underlay پتے اور ایک رومنگ صارف کے عوامی پتے کے لیے پلیس ہولڈر ہیں۔
ip rule show
ip route get 198.51.100.7 from 192.0.2.10تقسیم کی تصدیق کریں، پھر ایک وقت میں ایک کردار روکیں
تین بہاؤؤں کو الگ الگ جانچیں، کیونکہ کامیاب ہینڈ شیک باقی دو کے بارے میں کچھ ثابت نہیں کرتا۔ نئی آنے والی کنکشن قبول کریں، ایک اجازت یافتہ ایپلیکیشن اوپری اخراج سے بھیجیں، اور تصدیق کریں کہ دونوں پروسیس اب بھی اپنے ساتھیوں تک پہنچتے ہیں۔
پھر کلائنٹ کا کردار روکیں اور دیکھیں سرور کا کردار کیا برقرار رکھتا ہے۔ ایک انسٹنس کے لیے بنائے گئے مگر دونوں پر لاگو ہوئے راستے یا mark قاعدے کو تلاش کرنے کا یہی سب سے سستا طریقہ ہے۔
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerآپ یہ دیکھنا چاہتے ہیں کہ کلائنٹ کردار بند ہونے کے دوران لسنر اب بھی بندھا ہوا ہے، ٹنل ڈیوائس اب بھی موجود ہے اور لاگ نئی خرابیوں سے پاک ہے۔ اگر کلائنٹ روکنے سے سرور کے موجودہ صارفین کی جانب جوابات بھی کٹ جائیں تو دونوں کردار ایسی چیز بانٹ رہے ہیں جو صرف ایک تک محدود ہونی چاہیے تھی۔ لکھیں کہ ہر تبدیلی نے کس انسٹنس، کس کنفگ فائل اور کس بہاؤ کے مالک کو چھوا، ورنہ اس ہوسٹ کو اگلی بار ڈیبگ کرنے والا وہی دریافت صفر سے دہرائے گا۔