NAT هویتی در ASA در برابر استثنای NAT در IOS برای ترافیک VPN

یک شعبه PAT اینترنت و VPN سایت‌به‌سایت را روی همان دروازه Cisco نگه می‌دارد و VPN درست در لحظه‌ای که NAT اضافه می‌شود از کار می‌افتد. آدرس‌های داخل تونل دیگر با آنچه crypto ACL محافظت می‌کند نمی‌خوانند، یا طرف مقابل آدرس‌های ترجمه‌شده‌ای را می‌بیند که مسیری برایشان ندارد. Cisco این را در دو جا حل می‌کند: ASA قاعده‌ای برای NAT انتخاب می‌کند که آدرس را به خودش نگاشت می‌کند، و IOS جریان را با یک deny در ACL بیرون از قاعده ترجمه نگه می‌دارد. هر دو آدرس‌های اصلی را حفظ می‌کنند و هیچ‌کدام دور زدن پردازش NAT نیست.

پیش از انتخاب قاعده، جریان را ثبت کنید

با نوشتن جریانی که انتظار دارید محافظت شود شروع کنید: مبدأ LAN، مقصد دور و جفت آدرس دقیقی که سیاست IPsec محافظت می‌کند. این کار را پیش از ویرایش قاعده انجام دهید، زیرا این چندتایی نشان می‌دهد کدام طبقه‌بند یا قاعده NAT باید تطبیق می‌یافت.

سپس قاعده‌ای را پیدا کنید که واقعاً تطبیق یافته، نه قاعده‌ای که در نظر داشتید. در هر دو سکو NAT به ترتیب ارزیابی می‌شود و ممکن است قاعده‌ای پیشتر پیش از بررسی استثنای شما برنده شود. استثنایی که درست به نظر می‌رسد اما به قاعده دیگری می‌بازد هرگز بسته مورد انتظار را به سیاست حفاظت نمی‌رساند. نشانه آن با نبودن استثنا یکسان است، به همین دلیل ترتیب قاعده‌ها باید پیش از تغییر پیکربندی خوانده شود.

NAT هویتی در ASA یک قاعده است، نه دور زدن

در ASA، NAT هویتی قاعده‌ای است که آدرس ترجمه‌شده‌اش با آدرس اصلی برابر است. مانند هر قاعده دیگری انتخاب می‌شود و هنوز یک ورودی ترجمه نصب می‌کند، پس بسته از پردازش NAT نمی‌گذرد. آنچه تغییر می‌کند این است که آدرس‌ها روی سیم یکسان می‌مانند و این همان چیزی است که سیاست IPsec نیاز دارد.

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

رابط‌های قاعده و تنظیم route-lookup آن باید با طراحی ارسال بخواند. قاعده‌ای که آدرس را درست نگاشت می‌کند اما روی جفت رابط نادرست اعمال می‌شود برای جریان شما انتخاب نخواهد شد. route-lookup تعیین می‌کند بسته ترجمه‌شده مسیریابی شود یا مقصد اصلی استفاده شود، و همین تعیین می‌کند ترافیک بازگشتی از تونل برگردد یا نه.

دسترسی مدیریتی به خود ASA مورد جداگانه‌ای است. اگر برای ترافیک مدیریت از NAT هویتی استفاده می‌کنید، شرط route-lookup وابسته به نسخه اعمال می‌شود و یک استثنای گسترده کپی‌شده از نمونه VPN مشکل SSH را حل نمی‌کند.

deny در ACL NAT در IOS یعنی اینجا انتخاب نشده

در IOS، NAT اینترنت با یک فهرست مبدأ اداره می‌شود و آن ACL یک طبقه‌بند است، نه صافی. خط permit ترافیک را برای ترجمه انتخاب می‌کند؛ خط deny یعنی بسته اینجا انتخاب نشده است. این deny دستور دور انداختن بسته نیست، آن‌گونه که deny در ACL رابط است.

اینجا انتخاب نشده همچنین باریک‌تر از هیچ‌جا ترجمه نمی‌شود است. قاعده 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 قرار دارد و هرگز تطبیق نمی‌یابد. طبقه‌بند در جهت نادرست اعمال می‌شود، پس جریان بازگشتی ترجمه می‌شود. قاعده هویتی آدرس‌های درست اما جفت رابط نادرست را پوشش می‌دهد. crypto ACL زیرشبکه‌ای را محافظت می‌کند که دیگر با آنچه قاعده NAT عرضه می‌کند نمی‌خواند.

جفت آدرس اصلی و عرضه‌شده را کنار صاحب قاعده ثبت کنید تا مهندس بعدی ببیند چرا یک طبقه‌بند ترجمه را رد می‌کند در حالی که دیوار آتش برنامه را مجاز می‌داند. آن را در تیکت تغییر نگه دارید، نه در یادداشت شخصی. سپس پس از هر تغییر NAT جریان را دوباره اجرا کنید، زیرا ترتیب قاعده‌ها بخشی از پیکربندی است حتی وقتی متن قاعده تغییر نکرده باشد. تونلی که بالا می‌آید دلیل بر جان سالم به در بردن آدرس‌ها نیست؛ تنها بسته ضبط‌شده و دید رمزگشایی‌شده طرف مقابل دلیل است.