ASA سائٹ ٹو سائٹ VPN کے ذریعے اندرونی سروس شائع کرنا

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

جانچ 1: ٹنل ماخذ کے پتے کی حفاظت کرتا ہے

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

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

اگر محفوظ رینج اور ماخذ کا پتہ میل نہ کھائیں تو یہیں رکیں۔

جانچ 2: طے کریں کہ شاخ کون سا ماخذ دیکھے گی

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

ترجمہ یہ بھی بدلتا ہے کہ ماخذ کیا لاگ کر سکتا ہے اور ماخذ پر مبنی قواعد کس سے میل کھا سکتے ہیں۔ اگر ایپلیکیشن کو درخواست کے پیچھے موجود شخص جاننا ہو تو اس کی جگہ تصدیق شدہ ریورس پراکسی ہے، NAT کا فیصلہ نہیں۔

جانچ 3: ترجمہ اصل انٹرفیس کے مطابق لکھیں

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

جس راستے کو آپ بنا رہے ہیں اس کے چار حصے ہیں، اور چاروں کو میل کھانا چاہیے:

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

جانچ 4: رسائی کے قاعدے کو شائع شدہ پورٹ تک محدود کریں

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

اسی وقت قواعد کی ترتیب بھی جانچیں۔ آپ کے مخصوص قاعدے کے اوپر بیٹھی وسیع اجازت مخصوص قاعدے کو نظر نہ آنے والا بنا دیتی ہے۔

جانچ 5: ایک درخواست اور اس کا جواب ٹریس کریں

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

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

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

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