ASA: ایک عوامی IP پر VPN پورٹ اور DMZ اسٹیٹک PAT
ایک عوامی پتہ، دو سروسز۔ VPN سننے والے اور DMZ PAT کے لیے پتہ، ٹرانسپورٹ اور پورٹ کی فہرست بنائیں، اس سے پہلے کہ ایک دوسرے کا اندراج لے لے۔
دو سروسز، ایک عوامی پتہ، اور ایک DNS نام جو پورٹ مختص کرتا محسوس ہوتا ہے۔ ایسا نہیں کرتا۔ ASA پر VPN اندراج کے ساتھ DMZ سرور شائع کرنے سے پہلے اندراج کے ٹپل لکھیں اور انہیں ترتیب سے جانچیں؛ موجودہ سروس سے ملنے والا پہلا فیلڈ وہی جگہ ہے جہاں منصوبہ رکتا ہے. نیچے سب کچھ یہ مانتا ہے کہ VPN خود آلے پر ختم ہوتا ہے، کسی اندرونی سرور پر نہیں۔
کمانڈ لکھنے سے پہلے پانچ فیلڈز لکھیں
ہر عوامی اندراج کے لیے پتہ خاندان، عوامی پتہ، ٹرانسپورٹ، عوامی پورٹ اور مالک درج کریں۔ مالک یا ASA کا مقامی سروس ہے یا ترجمہ شدہ اندرونی سرور۔ دو اندراج ایک پتہ بانٹ سکتے ہیں اور پھر بھی مختلف ٹپل ہو سکتے ہیں، اور دو اندراج خاکے میں مختلف نظر آ سکتے ہیں جبکہ آلے پر ٹکراتے ہیں۔
اصل پورٹ کے لیے دوسرا کالم رکھیں، جس پر اندرونی سرور واقعی سنتا ہے۔ عوامی پورٹ اور اصل پورٹ خودمختار انتخاب ہیں، اور جس لمحے آپ انہیں ایک کالم میں ملا دیتے ہیں، بعد میں اپنا ترجمہ پڑھنے کی صلاحیت کھو دیتے ہیں۔
| Public entry | Owner | Real side |
|---|---|---|
| TCP 443 on the outside address | ASA VPN listener | Appliance-local, no translation |
| TCP 8443 on the outside address | Static PAT | DMZ server TCP 443 |
| UDP 443 on the outside address | Check the effective listeners | Possibly the VPN data path |
اصل اور نقشہ شدہ مقامات کو درست پڑھیں
اس سرور سے نہیں جسے آپ شامل کرنا چاہتے ہیں، بلکہ اس ٹپل سے شروع کریں جو آپ کے پاس پہلے سے ہے۔ ایک مثال کی تقسیم منظور شدہ VPN اندراج کو عوامی TCP 443 پر رکھتی ہے اور عوامی TCP 8443 پر DMZ HTTPS سرور شائع کرتی ہے جبکہ وہ سرور 443 پر سنتا رہتا ہے:
Public TCP 443 -> ASA VPN listener
Public TCP 8443 -> DMZ server TCP 443تعینات کمانڈ میں اصل سروس اور نقشہ شدہ سروس مقررہ مقامات پر ہیں، اور انہیں الٹنا ٹوٹا ہوا نہیں بلکہ دوسرا نقشہ کشی بیان کرتا ہے۔ کام کرنے والا ترجمہ پہیلی بننے کا یہی سب سے عام راستہ ہے: ترتیب درست ہے، یہ صرف کہیں اور اشارہ کرتی ہے۔
Cisco کی ASA 9.16 NAT گائیڈ اسٹیٹک PAT، انٹرفیس پتے کے استعمال اور اصل بمقابلہ نقشہ شدہ پورٹ کے معانی کی دستاویز کرتی ہے۔ جس ریلیز کو آپ واقعی چلاتے ہیں اس کا حصہ پڑھیں؛ پرانے پلیٹ فارم سے یاد کمانڈ مکمل موجودہ ترتیب نہیں ہے۔
ٹرانسپورٹ کو مختص کرنے کا حصہ گنیں
TCP 443 اور UDP 443 مختلف ٹپل ہیں، اور یہ فرق آپ کو UDP مفت نہیں دیتا۔ VPN کے الگ TLS اور DTLS سننے والے ہو سکتے ہیں، اور دیگر ترتیب شدہ سروسز وہ ٹرانسپورٹ پہلے سے رکھ سکتی ہیں جو آپ چاہتے ہیں۔ ویب صفحہ کو پورا VPN اندراج ماننے کے بجائے موثر سننے والوں اور رسائی پالیسی کی فہرست بنائیں۔
اسی پتے پر حل ہونے والا دوسرا ہوسٹ نام بھی ٹرانسپورٹ سطح کا تصادم حل نہیں کرتا۔ DNS نام سے پتے کی نقشہ کشی ہے، پورٹ کا دلال نہیں، اور PAT کے ذریعے سرور شائع کرنا VPN سننے والے کو دوسری پورٹ پر منتقل کرنے کے برابر عمل نہیں ہے۔
اگر VPN اندراج کو واقعی منتقل ہونا پڑے، تو چار چیزیں اکٹھی بدلتی ہیں: کلائنٹ پروفائل، عوامی URL، بالائی فلٹرنگ اور ہر وہ ٹرانسپورٹ جو تعیناتی استعمال کرتی ہے۔ ایک ایک کر کے نہیں، ایک ہی ونڈو میں کریں۔ جس سروس سے آپ آلے تک پہنچتے ہیں اسے چھونے سے پہلے آلے تک الگ انتظامی راستہ کھلا رکھیں۔ دوسرے راستے کے بغیر، منتقلی ایسی تبدیلی ہے جو آپ باہر سے واپس نہیں لے سکتے۔
باہر سے نئے کنکشن کے ساتھ تصدیق کریں
موثر رسائی پالیسی کے تحت صرف مطلوبہ DMZ ایپلیکیشن کی اجازت دیں، پھر ملتا ہوا ترجمہ ترتیب، سرور کا واپسی راستہ اور سرٹیفکیٹ پر ہوسٹ نام جانچیں۔ PAT نیٹ ورک کی منزل بدلتا ہے؛ یہ ایپلیکیشن رسائی نہیں دیتا اور ایسا سرٹیفکیٹ ٹھیک نہیں کرتا جس میں کسی اور ہوسٹ کا نام ہو۔
مجاز بیرونی ہوسٹ سے نئے کنکشن کے ساتھ دونوں سروسز آزمائیں: VPN کو اب بھی قائم ہونا چاہیے، اور DMZ درخواست کو اپنے مطلوبہ سننے والے تک پہنچنا چاہیے۔ قائم شدہ سیشن پچھلی حالت رکھ سکتا ہے، اس لیے یہ ایک منٹ پہلے بدلی گئی نقشہ کشی کے بارے میں کچھ ثابت نہیں کرتا۔
آپ نے جو تعینات کیا اس سے اندراج کی فہرست اپ ڈیٹ کر کے چکر بند کریں، بشمول ہر وہ سننے والا جو بنانے کے بجائے دریافت کیا۔ اس پتے پر اگلی بار سروس شائع کرنے والا شخص آپ کے جدول سے شروع کرے گا، اور وہاں کی غلط سطر یہاں کی غلط کمانڈ سے زیادہ مہنگی ہے۔