VPN מסוג S2S ב-Azure מחובר אך אין תנועה: קראו את יומן ה-IKE

הפורטל אומר Connected, למנהרה יש מונה זמן פעילות, ו-trace מהמכונה הווירטואלית שלכם מת ב-hop השני. מצב החיבור מתאר את משא ומתן ה-IKE וה-IPsec, ולא אם מנה אחת שורדת את שכבת המדיניות באף אחד מהצדדים. שתי תקלות מסבירות את רוב הפניות האלה, ואף אחת מהן לא מתוקנת על ידי שינוי מסלול ב-Azure. שתיהן כבר כתובות ביומן שהשער הפיק, ולכן אני מתחיל שם ולא בטבלת המסלולים.

מה Connected באמת מאשר

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

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

פתחו את היומן המיוצא לפני שנוגעים במסלולים

בפורטל, פתחו את שער הרשת הווירטואלית והריצו את פעולת VPN troubleshoot על החיבור, ואז הורידו את החבילה שהוא מייצר ופתחו אותה. בפנים יש יומן IKE עם חילופי שלב 1 ושלב 2, עם חותמות זמן וקריא כטקסט פשוט. חפשו בו את שורת transform במקום לקרוא מלמעלה למטה, כי הרשומה המעניינת נמצאת בדרך כלל כמה מאות שורות פנימה. אם אין לכם גישה לפורטל, אותם אבחונים מופיעים ביעד היומן של השער כשהגדרות האבחון מופעלות.

שתי רשומות נושאות את רוב הערך. הראשונה נשמעת בערך expected ESP with combined authentication and cipher, received AH. השנייה היא שגיאת payload לא חוקי במהלך חילופי ה-IKE, שבדרך כלל פירושה שדה הצעה פגום או לא נתמך.

שתיהן מתארות מה הציע ההתקן המקומי, ולכן שתיהן הגדרות בצד העמית. יצירה מחדש של צד ה-Azure של החיבור לא משנה את ההצעה שהחומת אש שלכם שולחת, ולעשות זאת בכל זאת היא השעה המבוזבזת הנפוצה ביותר בתהליך הזה. בעמית, הגדירו את שלב 2 ל-ESP עם אימות והצפנה משולבים ותנו לו לנהל משא ומתן על האלגוריתם, ואז בדקו אם תיבת סימון של ספק בשם כמו combined mode בוחרת בשקט הצעת AH מתחתיה.

אשרו את מרחב הכתובות של הרשת הווירטואלית

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

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

אמתו את הקידומות בשני הכיוונים

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

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

בדקו נתיב, לא ping

ה-trace שמפריד בין מנהרה עובדת למסלול עובד נראה כך: ה-hop הראשון הוא השער המקומי, אחר כך כמה hops שלא מגיבים, ואז המארח המרוחק עונה. אם ה-trace לא מגיע למארח לעולם, בדקו את פורט ה-TCP שהאפליקציה באמת משתמשת בו, כי ICMP מסונן לעתים קרובות מספיק כדי ש-ping כושל יוכיח מעט מאוד. הריצו את אותו trace ממארח מרוחק לעבר מכונה וירטואלית ב-Azure. אסימטריה בין שתי התוצאות היא הדרך המהירה ביותר למצוא מסלול חזור חסר או כלל שמתיר כיוון אחד בלבד.

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

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