מנהרת site-to-site מחוברת, ה-VM תקין, אבל הלקוח המקומי לא מקבל כלום. אתם פותחים את Network Watcher, מריצים אימות זרימת IP, והוא אומר Access allowed, ולכן הכרטיס נסגר כבעיית VPN. התוצאה הזו לא אומרת את מה שהיא נראית, כי אימות זרימת IP מעריך את כללי האבטחה של הזרימה שתיארתם ואף פעם לא בודק אם ל-Azure יש מסלול לקידומת המקומית שלכם.

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

מה אימות זרימת IP באמת מכריע

אימות זרימת IP לוקח VM, ממשק רשת, כיוון, ערכי החמישייה ופרוטוקול, ואז מדווח על החלטת כלל ה-NSG וכלל מנהל האבטחה עבור הזרימה הזו. הוא עובד על TCP ו-UDP, ולכן אינו בודק כללי ICMP ופינג חסום לא מוכיח דבר על השירות שלכם. תנו לו את הזרימה האמיתית ולא ניחוש. חיבור נכנס מהאתר המקומי לפורט של מסד נתונים הוא תיאור אחר מחיבור יוצא שה-VM יוזם.

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

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

מה הקפיצה הבאה והמסלולים האפקטיביים מוסיפים

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

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

הפקודות קצרות מספיק כדי להריץ מהקליפה. az network nic show-effective-route-table מפרט את המסלולים המיושמים על הממשק. az network watcher show-next-hop עם מקור ויעד מחזיר את הקפיצה שנבחרה. השוו את הקידומת שמעניינת אתכם לטבלה הזו ואז ודאו איזה רשומה מנצחת.

עברו את נתיב החזרה מה-NIC של ה-VM

עשו זאת מה-NIC של VM היעד, עבור קידומת הלקוח המקומי, לא עבור האינטרנט. נתיב החזרה הוא המקום שבו תקלות site-to-site מסתתרות, כי בדיקת מצב מנהרה רק מדווחת שאגודות האבטחה פעילות.

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

קראו את סוג הקפיצה הבאה במקום להעתיק דוגמה

נתיב דרך שער VPN מנוהל מציג בדרך כלל VirtualNetworkGateway כסוג הקפיצה הבאה. VirtualAppliance מתאר תכנון העברה אחר, בדרך כלל חומת אש או התקן רשת וירטואלי.

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

עברו לגבול שעדיין נכשל

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

סיימו בבקשת אפליקציה מותרת ובתצפיות משני הקצוות. תוצאת allow וקפיצה הבאה נכונה הן שתי פיסות ראיה, לא הוכחה שהחיבור הצליח.

מאמרים קשורים