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 שהכתובת המתורגמת שלו שווה למקורית. הוא נבחר כמו כל כלל אחר, והוא עדיין מתקין רשומת תרגום, כך שהחבילה אינה מדלגת על עיבוד 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, משום שסדר הכללים הוא חלק מהתצורה גם כאשר טקסט הכלל לא השתנה. מנהרה שעולה אינה הוכחה שהכתובות שרדו; רק החבילה שנלכדה ותפיסת הצד השני לאחר הפענוח הן ההוכחה.