ASA hairpin: انٹرنیٹ ایگزٹ یا سائٹ ٹو سائٹ VPN لِگ؟

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

دو لِگیں، ایک انٹرفیس

NAT قاعدہ لکھنے سے پہلے طے کریں کہ کون سی لِگ بنا رہے ہیں، کیونکہ قواعد ایک دوسرے کی جگہ نہیں لے سکتے۔ لِگ A کلائنٹ سے انٹرنیٹ ہے: پول کا پتہ اندر، ترجمہ شدہ عوامی پتہ باہر، اسی انٹرفیس سے واپس۔ لِگ B کلائنٹ سے دوسرے IPsec ساتھی کے دوسری طرف واقع نجی پریفکس تک ہے: پول کا پتہ محفوظ رہتا ہے، دوبارہ خفیف ہوتا ہے اور ایسے ساتھی تک پہنچایا جاتا ہے جسے پول کا جواب دینا آنا چاہیے۔

دونوں کو سب سے پہلے اسی انٹرفیس کی اجازت درکار ہے۔ اس کے بغیر ASA پیکٹ کو اسی انٹرفیس سے آگے بھیجنے سے انکار کرتا ہے جس پر وہ آیا تھا، اور ناکامی پالیسی کے بجائے روٹنگ کا مسئلہ دکھائی دیتی ہے:

same-security-traffic permit intra-interface

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

لِگ A: کلائنٹ کو انٹرنیٹ چاہیے

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

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

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

لِگ کا باقی حصہ عام ہے: بیرونی انٹرفیس سے قابل استعمال ڈیفالٹ یا مخصوص روٹ، بہاؤ کی اجازت دینے والی رسائی پالیسی، اور آپ کی منتخب کردہ حل کنندہ پالیسی کے مطابق سنبھالا گیا DNS۔ یہاں route-lookup نیچے کی طرح اسی وجہ سے شامل کریں، کیونکہ دخول اور اخراج انٹرفیس یکساں ہیں۔

لِگ B: کلائنٹ کو نجی سائٹ چاہیے

یہ لِگ زیادہ جگہوں پر ناکام ہوتی ہے، اس لیے اسے ترتیب سے لکھیں۔ پہلے کلائنٹ روٹ: منزل پریفکس اسپلٹ ٹنل فہرست میں ہونا چاہیے، ورنہ کلائنٹ اسے سرنگ میں نہیں رکھے گا۔ دوسرے سرنگ سلیکٹر: سائٹ ٹو سائٹ خفیہ ACL کو پول پتے سے دور دراز پریفکس تک ڈھانپنا چاہیے، صرف مقامی LAN سے دور دراز پریفکس تک نہیں۔ تیسرے شناخت، تاکہ پول کا پتہ راستے میں انٹرنیٹ PAT میں ترجمہ نہ ہو جائے۔

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

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

قواعد کی ترتیب بھی جانچیں۔ شناخت کے قاعدے کے اوپر وسیع PAT قاعدہ نجی تبادلے کا ترجمہ شناخت کے قاعدے کی جانچ سے پہلے ہی کر دے گا، اور علامت NAT خرابی نہیں بلکہ مطابق SA کے بغیر سائٹ سرنگ ہوگی۔

وہ آزمائش جو بتاتی ہے کہ آپ نے کون سی لِگ بنائی

کنفیگریشن پڑھ کر امید کرنے کے بجائے خود ASA کی راستہ جانچ استعمال کریں۔ packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed ایک بہاؤ کے لیے NAT فیصلہ، روٹ اور ACL نتیجہ دکھاتا ہے؛ نجی منزل کے ساتھ اسے دہرائیں۔ اگر NAT مرحلہ نجی سے نجی بہاؤ کو دوبارہ لکھتا ہے، تو آپ نے اس پیکٹ کے لیے لِگ A بنائی جسے لِگ B درکار تھی۔

مزید دو کمانڈز خلا کو پُر کرتے ہیں۔ show nat detail packet-tracer نے جو قواعد کی ترتیب اختیار کی اسے چھاپتا ہے، اور show crypto ipsec sa دکھاتا ہے کہ جس جوڑے کی آپ توقع کر رہے ہیں اس کے لیے سلیکٹر موجود ہے یا نہیں۔ غائب SA سلیکٹر یا ساتھی کنفیگریشن کا معاملہ ہے، ایسی چیز نہیں جو NAT قاعدہ درست کر سکے۔

ہر لِگ کی تصدیق اس ٹریفک سے کریں جس کی وہ خدمت کرتی ہے

لِگ A کو کلائنٹ کی عام عوامی درخواست سے قبول کریں، اور لِگ B کو ایسے نجی وسیلے کی درخواست سے جو واقعی موجود ہے۔ پھر ہر ایک کو مسترد وسیلے کے ساتھ دہرائیں، کیونکہ “اجازت دی گئی” اور “رسائی پالیسی سے منظور شدہ” ایک ہی ثبوت نہیں ہیں، اور مرکز سے اٹھنے والا ping کلائنٹ راستوں میں سے کسی کو بھی نہیں جانچتا۔

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