Cisco ASA ל-Azure VPN: זוגות קידומות של בוררי תעבורה

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

רשמו את ארבעת האובייקטים לפני התצורה

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

אם שניים מהם עדיין ניחושים, עצרו. רשימת קידומות שגויה בשער הרשת המקומי אינה בעיית כיוונון.

בחרו מודל חיבור אחד והפסיקו לערבב תבניות

תכן crypto map ותכן tunnel interface הם תצורות שונות, ותבנית לאחד אינה הופכת תקפה לשני על ידי עריכת כתובת העמית. רשמו איזה מהם אתם בונים לפני שאתם מדביקים משהו, כי אי-ההתאמה מופיעה מאוחר יותר כבעיית בורר ולא כשגיאת תצורה. מדריך התאימות של ASA של Microsoft מכסה את שתי התבניות ומציין איזה מודל שער Azure כל אחת מניחה. אם ההערות שלכם אינן נוקבות בשם המודל, עדיין אין לכם תכן.

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

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

פרטו את זוגות הקידומות, לא את הצבירים

כתבו את המטריצה. A ו-B מקומיים אל X ו-Y של Azure הם ארבעה זוגות, וכל אחד צריך כיסוי או החרגה מפורשת. כיווץ A ו-B לצביר אחד כולל גם את כל מה שביניהם, וכך תכן מקבל חור בשקט.

בדקו מה העמיתים ניהלו משא ומתן ולא מה שמרתם. רשימת הרשתות המקומיות והמרחוקות ב-ASA היא כוונה; ה-CHILD SA הם התוצאה.

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

אמתו בפקודות שמציינות את האובייקט

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

show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed

אחר כך שאלו את Azure על מצב החיבור עם az network vpn-connection show --name <connection> --query connectionStatus. Connected עם אפס בייטים בנתיב הנתונים הוא בעיית בורר, לא בעיית ניתוב.

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

הפרידו בין היקף ההצפנה לבין הרשאת הגישה

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

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

חזרה לאחור וההוכחה שהיא עבדה

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

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