VPN ٹریفک کے لیے ASA identity NAT اور IOS NAT استثنا

ایک شاخ ایک ہی Cisco گیٹ وے پر انٹرنیٹ PAT اور سائٹ ٹو سائٹ VPN چلاتی ہے، اور NAT شامل کرتے ہی VPN کام کرنا بند کر دیتا ہے۔ سرنگ کے اندر کے پتے اب crypto ACL کی حفاظت کردہ چیز سے میل نہیں کھاتے، یا سامنے والا فریق ایسے ترجمہ شدہ پتے دیکھتا ہے جن کا کوئی راستہ نہیں۔ Cisco اسے دو جگہوں پر حل کرتا ہے: ASA وہ NAT قاعدہ چنتا ہے جو پتے کو اسی پر نقش کرتا ہے، جبکہ IOS ACL میں deny کے ذریعے بہاؤ کو ترجمے کے قاعدے سے باہر رکھتا ہے۔ دونوں اصل پتے محفوظ رکھتے ہیں، اور کوئی بھی NAT پروسیسنگ کو بائی پاس نہیں کرتا۔

قاعدہ چننے سے پہلے بہاؤ درج کریں

جو بہاؤ آپ محفوظ کرنا چاہتے ہیں اسے لکھ کر شروع کریں: مقامی LAN ماخذ، دور منزل اور وہ درست پتہ جوڑی جسے IPsec پالیسی محفوظ کرتی ہے۔ قاعدہ ترمیم کرنے سے پہلے یہ کریں، کیونکہ یہ مجموعہ بتاتا ہے کہ کون سا درجہ بند کرنے والا یا NAT قاعدہ میل کھانا چاہیے تھا۔

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

ASA identity NAT ایک قاعدہ ہے، بائی پاس نہیں

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

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

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

خود ASA تک انتظامی رسائی الگ معاملہ ہے۔ اگر انتظامی ٹریفک کے لیے identity NAT استعمال کریں تو ریلیز کے مطابق route-lookup شرط لاگو ہوتی ہے، اور VPN مثال سے نقل کیا گیا وسیع استثنا SSH درست نہیں کرے گا۔

IOS NAT ACL میں deny کا مطلب ہے یہاں منتخب نہیں ہوا

IOS پر انٹرنیٹ NAT ماخذ فہرست سے چلتا ہے، اور وہ ACL فلٹر نہیں بلکہ درجہ بند کرنے والا ہے۔ Permit سطر ترجمے کے لیے ٹریفک چنتی ہے؛ deny سطر کا مطلب ہے پیکٹ یہاں منتخب نہیں ہوا۔ وہ deny انٹرفیس ACL کے deny کی طرح پیکٹ گرانے کا حکم نہیں ہے۔

یہاں منتخب نہ ہونا کہیں بھی ترجمہ نہ ہونے سے بھی تنگ ہے۔ دوسرا NAT قاعدہ، دوسرا انٹرفیس یا route-map اب بھی بہاؤ کا ترجمہ کر سکتے ہیں، اس لیے پوری NAT جدول پڑھنی ہوگی۔ پیکٹ کو اب بھی راستہ، میل کھاتا crypto ACL اور حقیقی رسائی کنٹرول کی حدود پر اجازت چاہیے۔

کم سے کم IOS ترتیب deny کو اسی فہرست میں permit کے اوپر رکھتی ہے اور overload قاعدہ اسی فہرست کی طرف اشارہ کرتا ہے۔ تب crypto ACL وہی جوڑی محفوظ کرتا ہے جسے deny ترجمے سے خارج کرتا ہے۔

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

دونوں ماڈلز کے لیے ایک قابلِ آزمائش سوال

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

ASA پر nat detail اور ترجمے کی جدول دکھائیں؛ IOS پر ip nat translations اور متعلقہ ACL شمار دکھائیں۔ جو قاعدہ کبھی نہیں بڑھتا وہ کبھی منتخب نہیں ہوا، اور یہ crypto ترتیب کی نہیں بلکہ ترتیب، انٹرفیس یا سمت کی طرف اشارہ کرتا ہے۔

ترتیب عام طور پر کہاں غلط ہوتی ہے

عام ناکامیاں میکانیکی ہیں۔ Deny permit کے نیچے ہے اور کبھی میل نہیں کھاتا۔ درجہ بند کرنے والا غلط سمت میں لاگو ہوتا ہے، اس لیے واپسی بہاؤ ترجمہ ہو جاتا ہے۔ Identity قاعدہ درست پتے مگر غلط انٹرفیس جوڑی ڈھکتا ہے۔ Crypto ACL ایسی ذیلی نیٹ کی حفاظت کرتا ہے جو اب NAT قاعدے کے پیش کردہ سے میل نہیں کھاتی۔

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