Azure מנקודה לאתר מתחבר אך שום משאב פרטי לא מגיב
מחובר פירושו רק שהמנהרה עלתה. בדקו מה השער יכול לשאת, השוו מרחבי כתובות, ואז פתרו שם ובדקו את השירות עצמו.
מחובר הוא מצב של המנהרה, לא הצהרה על נגישות. לקוח מנקודה לאתר יכול לסיים IKE, לקבל כתובת ועדיין לא להגיע לשום דבר, כי השער מעביר תעבורה רק עבור רשתות שה-VNet כבר מכיר. עברו על חמש הבדיקות האלה לפי הסדר ועצרו בכשל הראשון. דילוג קדימה הוא הדרך שבה בעיית DNS מטופלת כבעיית חומת אש במשך שעה.
הסדר חשוב יותר מהרשימה.
בדיקה 1: החליטו מה המנהרה אמורה לשאת
Azure VPN Gateway מסיים את המנהרה ומעביר תעבורה ששייכת ל-VNet; הואאינו יציאה כללית לאינטרנט. אם המשתמשים מצפים שהגלישה שלהם תצא דרך Azure, התכנון שגוי עוד לפני שנכנסת הגדרה כלשהי של הלקוח. הפעילו split tunneling כדי שהאינטרנט המקומי ימשיך להשתמש בנתיב המקומי, והשתמשו במופע NAT או במנהרה מאתר לאתר כשכתובת יציאה קבועה באמת נדרשת.
רשמו לאן הלקוח אמור להגיע לפני שאתם בודקים משהו. בלי הרשימה הזו, כל תוצאה חלקית נראית כמו התקדמות.
בדיקה 2: השוו מרחבי כתובות לפני תעודות
חפיפה נשפטת לפי הטווחים הרחבים יותר, כך ששתי רשתות שנראות שונות ברמת תת-הרשת עדיין מתנגשות אם בלוקי האב שלהן חופפים. תת-הרשת של השער חייבת להיות ייעודית וגדולה מספיק ל-SKU, ומאגר הכתובות של הלקוח לא יתנגש ב-VNet או בכל דבר שנגיש דרך peering. שנו את התוכנית ופרסו מחדש, כי הוספת נתיבים כפיצוי יוצרת מנהרה שעובדת ליעדים מסוימים ובלתי מוסברת לא לאחרים. ההקצאה נכשלת כאן בקול רם, וזה המקרה הטוב.
אימות הוא השער הבא. פרופילי תעודה, RADIUS ו-Entra ID אינם ניתנים להחלפה, וחבילת הלקוח שונה לכל אחד.
בדיקה 3: פתרו שם פרטי מבפנים
הלקוח שומר על resolver משלו אלא אם הפרופיל שהורד נושא את שרתי ה-DNS של ה-VNet, והרשימה הזו מוטבעת בזמן ההורדה. הוסיפו forwarder בתוך ה-VNet, הגדירו אותו כשרת DNS של ה-VNet, ואז הורידו וייבאו את חבילת הלקוח שוב. שימוש חוזר בחבילה הישנה בודק רק את רשימת ה-resolver הישנה.
בדקו קודם כתובת, כי זה מפריד בין ניתוב לשמות בצעד אחד: Test-NetConnection 10.20.1.4 -Port 3389.
אם הכתובת עונה והשם לא, שאלו את ה-resolver ישירות עם Resolve-DnsName files.corp.example -Server 10.20.0.4. אם שניהם נכשלים, התקלה אינה ב-DNS וכדאי להפסיק לערוך הגדרות DNS. ה-DNS של פלטפורמת Azure בכתובת 168.63.129.16 עונה רק מבפנים ל-VNet, כך שלקוח מחוצה לו לא יכול להשתמש בכתובת הזו כ-resolver.
בדיקה 4: בדקו את השירות שמאחורי המנהרה
מנהרה בריאה ופורט סגור נראים זהים מצד הלקוח. בדקו את חומת האש של האורח, ואז את קבוצת האבטחה של הרשת בתת-הרשת או ב-NIC, ואז אם השירות מאזין בכתובת הפרטית ולא רק ב-loopback. אפשרו את מאגר הלקוחות כמקור במקום לפתוח כלל לאינטרנט, וזכרו ש-SMB ל-Azure Files צריך את נתיב נקודת הקצה הפרטית מנותב דרך המנהרה. כשמשאב עונה לפי IP אבל לא לפי שם, חזרו לבדיקה 3 במקום לגעת בשער.
טבלה אחת מחזיקה את השכבות בנפרד בזמן העבודה:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
בדיקה 5: תעדו את הפרופיל לפני הסלמה
רשמו בכרטיס את סוג השער, סוג המנהרה, שיטת האימות ומערכת ההפעלה של הלקוח. פרופיל IKEv2 עם תעודה ופרופיל RADIUS נכשלים מסיבות שונות, ולקוח שנבנה לסוג מנהרה אחר מתחבר רק כשהשער מציע פרוטוקול תואם.
עבור צוות קטן, התכנון העמיד הוא VNet אחד, forwarder DNS אחד ולקוח split-tunnel מתועד. אם הדרישה היא יציאה ציבורית קבועה, סיימו מנהרה מאתר לאתר בחומת אש שאתם שולטים בה ונתבו לשם את תעבורת האינטרנט, במקום לבקש מהשער מנקודה לאתר משהו שלמענו הוא מעולם לא נבנה.