ממסר DHCP של ASA מעל VPN מאתר לאתר: מדריך צעד אחר צעד

הממסר פועל בשלושה שלבים, ורק האמצעי חוצה את ה-VPN. לקוח משדר בשידור רחב במקטע הסניף, ה-ASA הופך את השידור לבקשת unicast אל שרת ה-DHCP, והשרת עונה לכתובת הממסר ולא ללקוח. עברו את השלבים בסדר הזה, ורוב המקרים של «הממסר שבור» מסתכמים במדיניות חסרה או בשורה setroute שנקראה לא נכון.

שלב ראשון: הפעלת הממסר בממשק הפונה ללקוח

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

בדקו את התצורה הפעילה לפני שמשנים משהו: איזה ממשק מפעיל את הממסר, איזו צורת שרת קיימת, והאם setroute מחובר לממשק הלקוח. אם ה-ASA מריץ גם שרת DHCP למקטע אחר, עצרו וקראו את רשימת המגבלות; אי אפשר להפעיל שרת וממסר בו-זמנית באותה מכונה.

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

שלב שני: העברת התעבורה שה-ASA מייצר דרך המנהרה

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

ודאו שהתעבורה המעניינת מכסה את מקור הממסר של ה-ASA ואת כתובת השרת, ושגם כיוון החזרה מותר. בתכנון מבוסס VTI החלטת הניתוב פשוטה יותר, אבל תמיכת ממסר מעל VTI הגיעה במהדורה מסוימת; מדריך ה-DHCP של ASA מציין 9.14(1), לכן בדקו את התמונה לפני שמעתיקים דוגמת VTI להתקן ישן יותר.

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

שלב שלישי: קריאת התשובה ואפשרות setroute

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

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

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

מה אני בודק לפני שאני אומר שזה תוקן

התחילו בלקוח ותפסו את השידור, ואז ודאו שה-ASA העביר אותו עם הכתובת שלו בתור giaddr. בצד המרוחק ודאו שהשרת ראה את הבקשה ובחר טווח שמתאים לסניף. בחזרה לסניף ודאו שהלקוח קיבל את ההצעה והוא מגיע לשער שלו.

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

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