OpenVPN کلائنٹس کو Cloudflare کے ذریعے روٹ کریں؟ پہلے کردار جانچیں

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

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

ایک میزبان پر دو سروسز ٹرانزٹ راستہ نہیں ہیں

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

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

Cloudflare کا کون سا کردار آگے بھیجنے کا مجاز ہے

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

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

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

بیرونی ٹنل کو نئے راستے سے آزاد رکھیں

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

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

آگے بھیجنا اور ترجمہ ایک ہی بہاؤ تک محدود کریں

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

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

وہ چار جواب لکھیں جن پر آپ ٹھہرے اور وہ مشاہدہ جو ہر ایک کو ثابت کرتا ہے۔ جو ٹرانزٹ راستہ آپ بیان کر سکتے ہیں وہی اگلے واقعے کے جائزے میں آپ بچا سکتے ہیں۔