کیا دو OpenVPN سرورز کے کلائنٹ ایک دوسرے تک پہنچ سکتے ہیں؟

دوسرا OpenVPN سرور قائم کرنا آپ کو کلائنٹ جڑنے کی دوسری جگہ دیتا ہے، اور اس سے زیادہ کچھ نہیں۔ یہ ان کلائنٹ کو پہلے سرور کے نیٹ ورک پر نہیں رکھتا، اور client-to-client نامی آپشن صرف ایک سرور پروسیس کے اندر فارورڈنگ بدلتا ہے۔ دونوں پول ایک نیٹ ورک تب بنتے ہیں جب آپ جان بوجھ کر ان کے درمیان روٹنگ کرتے ہیں، ہر سمت کے لیے ایک مالک مقرر کر کے۔ نیچے سب کچھ یوزر اسپیس TUN موڈ فرض کرتا ہے جس میں وہ اندرونی فارورڈنگ بند ہے، اس لیے فیصلہ کرنل کرتا ہے۔

افسانہ: ایک اکاؤنٹ فہرست، ایک نیٹ ورک

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

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

ہر گیٹ وے کو اپنا پول اور ٹرانزٹ پتہ دیں

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

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

دونوں طرف روٹ لگائیں

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

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

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

ملکیت کا ناٹک کیے بغیر کلائنٹ روٹ دھکیلیں

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

push "route 10.64.20.0 255.255.255.0"

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

ایک درخواست ثابت کریں اور دوسری مسترد کریں

کوئی حقیقی عمل چنیں، مثلاً 10.64.10.21 پر کلائنٹ سے 10.64.20.37 پر سروس تک HTTPS، اور دونوں ہوسٹس پر ٹھیک اسی کی اجازت دیں۔ ہر فائر وال اپنی اندرونی طرف درخواست اور واپسی کی طرف ٹریک شدہ جواب قبول کرتا ہے؛ منزل کی اپنی سروس پالیسی کو بھی اسے قبول کرنا ہوگا۔

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

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