למה בקשות TACACS+ של ה-ASA עוקפות את מנהרת ה-VPN של הסניף שלכם

מנהרת הסניף פעילה, המשתמשים מאמתים מול שרת ה-TACACS+ המרוחק, וההתחברות של חומת האש עצמה עדיין נגמרת בזמן. הסיבה אינה תקלה במנהרה: מנהרת LAN-to-LAN נושאת תעבורה שתואמת את הבוררים שלה, ותעבורת הניהול שה-ASA מייצר על עצמו היא זרימה נפרדת עם כתובת מקור משלה. רוב הצוותים מגלים זאת במהלך חלון שינוי, כשחשבון המנהל היחיד הוא זה שנכשל. התייחסו לסשן ה-AAA שה-ASA יוזם כאל זרימה שעליכם לתכנן, ולא כתוצר לוואי של קישוריות שכבר עובדת.

ה-ASA הוא הלקוח, והתעבורה שלו זקוקה לנתיב משל עצמה

כשחומת האש פונה לשרת TACACS+, חומת האש היא לקוח כמו כל אחד אחר, אלא שאיש לא הגדיר לה נתיב בכוונה. החבילות שלה יוצאות מכתובת ממשק במכשיר, הן נוצרות מקומית ולא מועברות הלאה, וצריך לנתב, לתרגם ולהגן עליהן במדיניות בדיוק כמו תעבורת משתמשים. מנהרה מאתר לאתר שמגנה על תת-רשת משתמשים אינה מגנה אוטומטית על מקור הניהול הזה, כי בחירת התעבורה מבוססת על כתובות ולא על כוונה.

רשמו את הכתובת שאתם מצפים שהשרת יראה. אם אינכם יכולים לנסח אותה בשורה אחת, עדיין אין לכם תכנון.

הממשק בשורת aaa-server אינו קישוט

ב-ASA רשומת המארח aaa-server מקבלת שיוך ממשק בסוגריים, ומדריך הפקודות של מארח AAA של Cisco מתאר אותה כממשק שבו נמצא שרת האימות. השיוך הזה הוא שקושר את הבקשה לממשק ולמדיניות שאותו ממשק מיישם. בחירה לפי הממשק שפונה לאינטרנט, או השארת מה שנשאר מההעברה האחרונה, מייצרת כתובת מקור שהשרת המרוחק והמנהרה מעולם לא נבנו עבורה.

inside היא התשובה הנכונה רק כשהממשק הנקוב מחזיק בכתובת שהתכנון שלכם מתכוון להשתמש בה כמקור. במכשיר סניף זה לעתים קרובות כך; במכשיר עם כמה מקטעים פרטיים אולי לא.

שינוי השיוך פירושו יצירת הרשומה מחדש

אותו מדריך פקודות מתעד מגבלת עריכה שתופסת אנשים במעברים: שינוי הממשק במארח קיים מחייב הסרה ויצירה מחדש של רשומת המארח. תצורה שנראית ערוכה אולי לא נכנסה לתוקף, וניסיון ההתחברות הבא עדיין ייצא מהכתובת הישנה. תכננו זאת כמחיקה והוספה עם עותק של הרשומה המקורית לנגד עיניכם, ולא כשינוי במקום.

אם מוגדרים כמה שרתים, שנו אחד ובדקו אותו לפני שאתם נוגעים בשאר, כדי שטעות לא תנעל את כל נתיבי הניהול בבת אחת.

בדקו בוררים, תרגום ונתיב חזרה יחד

שלושה דברים חייבים להתלכד כדי שהבקשה תגיע. בוררי התעבורה של המנהרה, או הגנת ממשק המנהרה אם יש לכם כזו, חייבים לכלול את המקור של ה-ASA עצמו ואת כתובת השרת; רשימת בוררים שנבנתה עבור תת-רשתות משתמשים בדרך כלל לא תעשה זאת. כל כלל NAT בנתיב חייב לתרגם את המקור הזה באופן עקבי, כי השרת מאשר זהות של התקן רשת הכוללת את הכתובת שהוא רואה. ונתיב החזרה חייב להתקיים, מה שבמנהרה מבוססת מדיניות אומר שלקצה המרוחק יש בורר תואם בכיוון ההפוך.

בצד השרת, אשרו בנפרד את זהות ההתקן, את הסוד המשותף ואת המדיניות הניהולית. TACACS+ שומר על אימות, הרשאה וחשבונאות כפעולות נפרדות, ולכן דחייה שמגיעה אחרי חילוף שהושלם היא תשובת מדיניות, לא כשל תעבורה. קריאה שלה כבעיית רשת תשלח אתכם לחפש במקום הלא נכון.

הרחיקו את הסוד מלכידות, מכרטיסים ומתמלולים בזמן הניפוי, וזכרו שכתובת המקור שהשרת רושם היא זו שהתכנון שלכם חייב להסביר.

בצעו את השינוי בלי לנעול את עצמכם בחוץ

השתמשו בקונסולה או בנתיב ניהול עצמאי בזמן שאתם משנים אימות ניהולי מרוחק, והחזיקו בחלופה מקומית מאושרת עד שהנתיב החדש יישא התחברות אמיתית. אחר כך תקפו בצורה צרה: שרת אחד, התקן אחד, אימות מוצלח אחד עם כתובת המקור שנצפתה בשני הקצוות.

תעדו את הזרימה בעמוד משלה: ממשק וכתובת מקור, שרת מרוחק, נתיב מוגן, והאדם שבבעלותו מדיניות ההרשאה. אז אפשר להעריך שינוי ממשק או מנהרה מאוחר יותר בלי לנחש איזו משתי הזרימות הוא משפיע עליה.