NAT VPN سرور پر یا راؤٹر پر؟ دونوں کام کر سکتے ہیں

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

افسانہ: کلائنٹ روٹ ہی اخراج بناتا ہے

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

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

پہلے جواب کا راستہ بنائیں

کسی بھی سیٹنگ کو چھونے سے پہلے راستہ حقیقی پتوں کے ساتھ لکھیں، اور اس پر دو ممکنہ ترجمہ نقطے نشان زد کریں۔ یہ لیبارٹری 10.70.0.0/24 کا VPN پول استعمال کرتی ہے جس میں ایک کلائنٹ 10.70.0.37 پر، سرور کا LAN پتہ 172.16.40.10، راؤٹر 172.16.40.1 پر اور عوامی اخراج 203.0.113.40 پر ہے۔

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

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

اختیار A: VPN سرور پر ترجمہ

یہاں سرور پیکٹ راؤٹر کو سونپنے سے پہلے کلائنٹ کے ماخذ کو اپنے LAN پتے میں ترجمہ کرتا ہے، اور راؤٹر باہر جاتے وقت اپنا معمول کا ترجمہ لاگو کرتا ہے۔ جواب پر راؤٹر کی میپنگ سرور کا پتہ بحال کرتی ہے اور سرور کی میپنگ کلائنٹ کا پتہ بحال کرتی ہے۔ سلسلے میں دو حالت والے ترجمے معمول اور قابل عمل ہیں، بشرطیکہ دونوں درج ہوں؛ راؤٹر کو کبھی پول تک راستے کی ضرورت نہیں ہوتی، اور یہی اس ترتیب کی کشش ہے۔

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

NAT موجود ہونے کے مفروضے کے بجائے یہ دیکھنے کے لیے کہ سرور کے پاس پہلے سے کیا ہے، یہ پڑھائیاں استعمال کریں۔ بلاگ سے نقل کیا گیا Linux masquerade قاعدہ Windows ترتیب نہیں ہے، اور VPN سامع کے لیے ہوسٹ فائر وال میں اجازت کلائنٹ کی درخواست آگے بھیجنے کی اجازت جیسی پالیسی نہیں ہے۔ سرور کا فارورڈنگ کردار اس کے اپنے انتظامی انٹرفیس سے تصدیق کریں، پھر ترجمے کو الگ سے دیکھیں، کیونکہ دونوں اکثر تعیناتی کے مختلف حصوں سے فعال ہوتے ہیں۔

اختیار B: پول کو راؤٹر تک لے جانا

دوسری ترتیب میں سرور کلائنٹ کا اصل ماخذ پتہ آگے بھیجتا ہے، اور راؤٹر اس کا ترجمہ کرتا ہے۔ یہ کنارے پر کلائنٹ پول کو نظر آنے والا رکھتا ہے، جو مدد کرتا ہے اگر راؤٹر ہی ٹریفک پالیسی، لاگنگ یا معائنے کی جگہ ہو۔ اس کا مطلب یہ بھی ہے کہ راؤٹر کو 10.70.0.0/24 کے لیے 172.16.40.10 کی طرف اشارہ کرنے والا واپسی راستہ درکار ہے، نیز ایک انٹرنیٹ پالیسی جو واقعی وہ سابقہ شامل کرے؛ LAN ذیلی نیٹ کے لیے لکھا گیا قاعدہ خاموشی سے پول تک نہیں پھیلتا۔

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

DNS، IPv6 اور قبولیت کو واضح کریں

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

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

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