IOS VPN ایگزٹ پر NAT کا اندرونی اور بیرونی کردار کس انٹرفیس کو ملتا ہے
ڈکرپٹ شدہ کلائنٹ پیکٹ کو ورچوئل انٹرفیس سے اپ لنک تک ٹریک کریں۔ ترجمہ اسی اندرونی بہاؤ پر ہے، ٹنل کی بیرونی نقل و حمل پر نہیں۔
مکمل ٹنل انٹرنیٹ ایگزٹ فراہم کرنے والے راؤٹر دو کام کرتے ہیں جو ایک جیسے لگتے ہیں۔ یہ ٹنل ختم کرتا ہے اور ڈکرپٹ شدہ کلائنٹ پیکٹ انٹرنیٹ کی طرف بھیجتا ہے۔ صرف دوسرے کام کو ترجمے کی ضرورت ہوتی ہے، اور ترجمہ اندرونی بہاؤ سے مطابقت رکھنا چاہیے۔ یہی فرق طے کرتا ہے کہ کون سے انٹرفیس NAT کردار اٹھاتے ہیں اور اصول میں کون سی ایڈریس رینج آتی ہے۔
ایک پیکٹ کو راؤٹر سے گزریں
10.90.0.25 پر موجود کلائنٹ کو لیں جو عوامی HTTPS سروس کھول رہا ہے۔ کیا وہ منزل ٹنل میں آتی ہے، یہ خود کلائنٹ کی پالیسی کا فیصلہ ہے۔ آنے کے بعد راؤٹر پیکٹ کو ڈکرپٹ کر کے ورچوئل انٹرفیس تک پہنچاتا ہے، جہاں سے اسے عوامی اپ لنک کی طرف روٹ کیا جاتا ہے۔
وہ ورچوئل انٹرفیس ترجمے کا اندرونی حصہ ہے۔ عوامی اپ لنک بیرونی حصہ ہے۔ اگر کردار الٹے ہوں یا غائب ہوں، تو پیکٹ یا تو نجی ماخذ کے ساتھ باہر جاتا ہے، یا ترجمے سے پہلے خارج کر دیا جاتا ہے۔
| Stage | Question to answer |
|---|---|
| VPN client | Does the client's policy put this destination inside the tunnel? |
| Decrypted ingress | Which virtual interface receives the inner packet? |
| Internet egress | Which route, access policy and source translation apply? |
| Reply | Is the client's flow translated back before it is delivered over the tunnel? |
ترجمے کی پالیسی کو کلائنٹ پول سے ہم آہنگ کریں
NAT اصول میں وہ رینج بیان ہونی چاہیے جو کلائنٹ کو واقعی ملتی ہے، نہ کہ دفتری LAN جو اتفاقاً اپ لنک بانٹتا ہے۔ صرف مقامی سب نیٹ کو ڈھکنے والا اصول دور دراز کلائنٹس کو چھوڑ دیتا ہے، چاہے دونوں ایک ہی انٹرفیس سے باہر جائیں۔
ip access-list extended NAT-TUNNEL
permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overloadنجی سائٹس کی استثنائیں الگ رکھیں۔ اندرونی منزلوں کی طرف ٹریفک اپنا اصل ماخذ برقرار رکھے، ورنہ منزل ایسے پتے کو جواب دے گی جہاں وہ پہنچ نہیں سکتی اور واپسی کا حصہ راؤٹنگ لوپ جیسا دکھنے والے انداز میں ناکام ہوگا۔
کردار تعینات شدہ ڈیزائن کے حقیقی انٹرفیسز پر لاگو کریں۔ پرانی Easy VPN کے جواب سے نقل کیا گیا Virtual-Template ٹکڑا مکمل موجودہ کنفیگریشن نہیں ہے، اور استعمال شدہ ٹنل کی قسم طے کرتی ہے کہ کون سا انٹرفیس ڈکرپٹ شدہ پیکٹ وصول کرتا ہے۔
بیرونی نقل و حمل اور اندرونی ترجمے کو الگ رکھیں
ڈکرپٹ شدہ ایپلیکیشن ماخذ کا ترجمہ کرنا، IKE یا محفوظ پیکٹوں کو اوپر کے NAT آلے سے دھکیلنے جیسا عمل نہیں ہے۔ پہلا بدلتا ہے کہ انٹرنیٹ کلائنٹ کی درخواست کے ماخذ کے طور پر کیا دیکھتا ہے؛ دوسرا درمیانی آلے کے پار ٹنل کو زندہ رکھتا ہے۔
انہیں ملانے سے دو کلاسیکی ناکامیاں پیدا ہوتی ہیں۔ اپنی ٹنل کی نقل و حمل کا ترجمہ کرنے والا راؤٹر ہم منصب کا رشتہ توڑ دیتا ہے، جبکہ اندرونی بہاؤ کا کبھی ترجمہ نہ کرنے والا راؤٹر نجی پتے انٹرنیٹ پر بھیجتا ہے۔ کوئی اصول تبدیل کرنے سے پہلے پڑھیں کہ آپ کون سا بہاؤ دیکھ رہے ہیں، اور جانچیں کہ تبدیلی کے بعد ٹنل قائم رہی یا نہیں۔ وہ اصول جو براؤزنگ ٹھیک کر کے ٹنل گرا دے، مسئلہ حل کرنے کے بجائے اسے منتقل کر دیتا ہے۔
کوئی بھی ناکامی دوسری کو بدل کر ٹھیک نہیں ہوتی۔ کوئی اصول تبدیل کرنے سے پہلے پڑھیں کہ آپ کون سا بہاؤ دیکھ رہے ہیں۔
دونوں حدود پر تصدیق کریں
انٹرنیٹ حد پر ایپلیکیشن ماخذ اور واپسی کے حصے پر بحال شدہ منزل پڑھیں۔ پہلا بتاتا ہے کہ ترجمہ ہوا یا نہیں؛ دوسرا بتاتا ہے کہ الٹا میپنگ درست کلائنٹ تک واپس آئی یا نہیں۔
پھر ایسے کلائنٹ کی جانچ کریں جو منظور شدہ اسپلٹ ٹنل راستہ استعمال کرتا ہے۔ وہ کلائنٹ اس راؤٹر کا انٹرنیٹ ترجمہ کبھی استعمال نہیں کرتا، اس لیے اسے مختلف برتاؤ کرنا چاہیے، اور فرق تصدیق کرتا ہے کہ ٹریفک کس راستے سے گزرا۔
اگر دونوں کلائنٹ یکساں برتاؤ کریں تو اسپلٹ ٹنل پالیسی وہ نہیں کر رہی جو ڈیزائن کہتا ہے۔ مزید ترجمے کے اصول شامل کرنے سے پہلے اسے ٹھیک کریں، کیونکہ غیر استعمال شدہ راستے کے لیے لکھا گیا اصول اصل مسئلہ چھپاتا ہے۔