IP סטטי ב-Azure P2S VPN: מדוע כתובת הלקוח משתנה
Azure point-to-site מקצה בכל התחברות את הכתובת הפנויה הבאה מהמאגר, ולכן אין IP קבוע ללקוח. בססו את הגישה על טווחים או על זהות.
כל לקוח Azure point-to-site מקבל כתובת מהמאגר כשהוא מאמת את זהותו, ושומר עליה רק כל עוד החיבור הזה נמשך. אין טבלת שריון, אין מיפוי לפי משתמש, ואין הגדרת שער שמשמעותה „תן תמיד לאדם הזה 172.16.0.10“. אותו מנגנון יחיד מסביר את שני התסמינים שאנשים פוגשים בהמשך: כלל NSG שמפסיק להתאים למשתמש שהוא התאים לו קודם, ורשימת היתרים שמכניסה בשקט מכונה שאיש לא הוסיף בכוונה. החלפת הכלל בכלל IP חכם יותר אינה מתקנת אף אחד מהם, מפני שהדבר שהכלל נוקב בשמו מוקצה מחדש לפי לוח זמנים שאינכם שולטים בו.
המאגר הוא קיבולת, לא זהות. הוא קיים כדי שלמנהרות במקביל יהיו כתובות ייחודיות, והוא ממחזר אותן ברגע שהחכירה מסתיימת. כשזה ברור, השאלה המועילה מפסיקה להיות „איך אני נועל את הלקוח הזה“ והופכת ל„כנגד מה אני יכול לכתוב כלל שהשער לא ימחזר“.
מה השער באמת עושה כשקוח מתחבר
השער מחזיק את מאגר כתובות הלקוחות המוגדר ומתייחס אליו כאל טבלת חכירות. בהתחברות הוא לוקח את הכתובת הפנויה הבאה, בפועל הנמוכה ביותר הזמינה, ומקצה אותה למתאם המנהרה עד שהלקוח מתנתק או עד שהחכירה פוגה. הסדר קובע, לא הזהות: מי שמתחבר מחדש ראשון אחרי תקופה שקטה מקבל את הכתובת הנמוכה ביותר שמקרית פנויה באותו רגע.
גודל המאגר מסתיר את ההתנהגות. מאגר מעבדה שגדול בכתובת אחת או שתיים ממספר הבודקים נראה דטרמיניסטי, מפני שאותו מחשב נייד נוטה להתחבר מחדש באותו סדר בכל בוקר. הוסיפו מכונה שלישית, שנו את גודל המאגר, או השאירו הפעלה מחוברת לאורך הצהריים, והתבנית נשברת. הכתובת מעולם לא הייתה יציבה; התור היה.
כל שינוי בתצורת point-to-site מאפס גם את מרחב החכירות. סוג אימות אחר, מאגר בגודל אחר, טווח מאגר חדש, או שער שנהרס ונבנה מחדש — כולם מחזירים לקוחות למאגר שאינו מתאים עוד לכתובות הישנות שלהם. שום דבר בשינוי הזה אינו נוגע ב-NSG שלכם, ולכן התקלה נראית ספונטנית.
אפשר לראות את זה בכדקה בערך. התחברו, רשמו את כתובת המנהרה בפרטי החיבור של הלקוח, התנתקו, חברו מכונה שנייה, ואז חברו שוב את הראשונה. הכתובת שתקבלו בחזרה תלויה במה שהמכונה השנייה מחזיקה, וכל הגדרה בפורטל לא תשיב את הקודמת על פי דרישה.
NSG שמבוסס על IP הלקוח הוא למעשה כלל על סדר ההתחברות
הכלל שאנשים כותבים ראשון הוא המובן מאליו: כלל נכנס על ה-NIC של מכונת הניהול או על תת-הרשת שלה, עם הכתובת הפנימית של לקוח ה-VPN כמקור. הוא קצר, הוא עובר את הבדיקה ביום שבו נכתב, והוא נכשל ברגע שיש במאגר יותר מכתובת פנויה אחת.
מכאן נובעים שני מצבי כשל, ורק אחד מהם נראה כמו באג. משתמש לגיטימי נדחה מפני שמישהו אחר מחזיק באותו רגע את הכתובת שהכלל נוקב בשמה, וזה מגיע כקריאת תמיכה מעצבנת. או שמשתמש לא מכוון מתקבל מפני שהוא ירש כתובת שהכלל עוד סומך עליה, וזה לא מגיע כשום דבר עד שמישהו מבקר את הגישה.
מכיוון שהכלל הולך אחרי החכירה, המדיניות האפקטיבית אומרת „מי שמתחבר ראשון מקבל גישת ניהול“. זהו תיאור של סדר ההתחברות לבוש ככוונה, ושום היגיינת כללים לא תהפוך אותו לביטוי של כוונה.
חכירת הלקוח וכתובת השער הם אובייקטים שונים
רוב הבלבול נובע ממילה אחת. לשער יש IP ציבורי יציב יחסית; ללקוחות יש כתובות פרטיות מהמאגר שאינן יציבות. בשער VPN שאינו עמיד-אזורים, ה-IP הציבורי מוקצה דינמית, אבל הוא שורד שינוי גודל, איפוס ותחזוקה שגרתית — הוא משתנה כשהשער עצמו נמחק ונוצר מחדש. SKU של שער עמיד-אזורים ואזורי משתמשים ב-IP ציבורי מסוג Standard, וההקצאה הזו חייבת להיות סטטית.
היציבות הזו היא מה שצד מקומי צריך בתצורה שלו, והיא אינה אומרת דבר על זיהוי לקוח בודד. כששותף שואל איזו כתובת הוא יראה, התשובה היא ה-IP הציבורי של השער ב-site-to-site, או טווח NAT משותף — לעולם לא חכירת המנהרה של מחשב נייד.
מאגרי קבוצה נותנים לכם טווח שכדאי לכתוב נגדו כללים
Virtual WAN point-to-site תומך בקבוצות משתמשים, וכל קבוצה יכולה לקבל מאגר כתובות לקוחות משלה. החברות נקבעת לפי זהות, ולכן הטווח שאליו נוחת לקוח נעשה צפוי: תפעול בטווח אחד, קבלנים בטווח אחר, והטווח הוא משהו שכלל חומת אש או NSG יכול לנקוב בשמו בלי לנחש.
למערכת הכללים שמתקבלת יש צורה שאפשר לסקור:
- מאגר אחד לכל קהל, בגודל שמתאים לשיא הפעלות במקביל ולא למספר אנשים;
- חברות בקבוצה מנוהלת דרך זהות, לא בעריכת כללים בכל פעם שמישהו מצטרף;
- כללי NSG או Azure Firewall נכתבים נגד טווחי מאגר, לעולם לא נגד חכירות בודדות;
- רכז או שער נפרד לקהלים שאסור להם לעולם לחלוק טווח.
| Rule target | Survives a reconnect | What it still cannot express |
|---|---|---|
| Client tunnel address | No | Follows connection order and admits whoever holds the address next |
| Whole client pool | Yes | Grants every connected client identical access |
| Virtual WAN group pool | Yes | Only as reliable as group membership |
| Gateway public IP | Until the gateway is recreated | Identifies the site, not the person |
הכנסת מאגר שלם לרשימת ההיתרים היא כנה אבל גסה: כל לקוח מחובר בטווח הזה מקבל אותה גישה. זוהי החלטת מדיניות שראוי לומר אותה בקול ולא לגלות אותה בסקירה. כל מה שעדיין צריך תשובה לאדם בודד שייך למשאב, דרך הקצאות תפקיד, ולא למסנן החבילות.
כשהפריסה אינה יכולה לעבור ל-Virtual WAN
שערים רבים נשארים שערי VPN רגילים, ומעבר ל-Virtual WAN אינו שינוי של מה בכך. התשובה המעשית היא להעביר את ההחלטה לכל משתמש ממסנן החבילות למשהו שכבר יודע מי המשתמש.
זהות ברמת המשאב היא הגרסה הזולה ביותר. Storage, SQL ו-Key Vault כולם תומכים באימות Entra ID עם הקצאות תפקיד לכל משתמש או לכל קבוצה, ולכן ה-VPN צריך רק להוכיח נגישות רשתית. מארח קפיצה עם חשבונות בשם עושה את אותה עבודה לעבודה ניהולית, מפני שהמארח רושם את האדם והמנהרה רק נושאת חבילות. רישום לקוחות ב-DNS והתרת השם במקום המספר מעבירים את הכלל קומה אחת למעלה. זהות בשכבת היישום — נושא תעודה, טענת אסימון, חברות בקבוצה — עובדת כשהדבר שמתבקש להחליט הוא היישום, לא הרשת.
לשותף שמתעקש על כתובת מקור קבועה, התשובה היא site-to-site או ExpressRoute עם קידומת עמית מוגדרת. הם מתירים את קידומת העמית, הכתובת שמופיעה בצד שלהם שייכת לשער, והיא אינה משתנה כשמישהו מפעיל מחדש מחשב נייד.
בדקו את המאגר לפני שאתם עורכים רשימת היתרים נוספת
שתי תכונות של המאגר גורמות לרוב ההתנהגות שאנשים מאשימים בה את הלקוח. מאגר קטן מדי ממחזר חכירות מהר, ולכן כתובות נראות נעות כל הזמן וכל כלל מבוסס כתובת נראה לא יציב מלכתחילה. מאגר שחופף לטווחים המקומיים או למרחב הכתובות של הרשת הווירטואלית יוצר עמימות בניתוב שאין כלל חומת אש שמתקן אותה.
שימו שלושה דברים בעמוד אחד לפני שנוגעים בכלל: מאגר ה-point-to-site, מרחב הכתובות של הרשת הווירטואלית והטווחים המקומיים. אסור שיחפפו, והמאגר צריך מקום לכל לקוח במקביל ועוד מרווח להתחברויות חוזרות.
ואז סגרו את הלולאה בסדר הזה:
- התחברו משתי מכונות בשני הסדרים והשוו את הכתובות; אם הן יכולות להתחלף, אין כלל מבוסס כתובת שבטוח.
- בדקו אם השער הוא Virtual WAN; אם כן, השתמשו במאגרי קבוצה במקום בכללים לכל כתובת.
- שאלו מה קורה כשכלל פוגע באדם הלא נכון; אם התשובה היא אירוע גישה, העבירו את השליטה לזהות.
- תעדו איזה טווח שייך לאיזו קבוצה באותו מאגר שבו נמצאות הגדרות ה-NSG.
- בדקו שוב אחרי כל שינוי במאגר, באימות או בשער, מפני שהשינויים האלה כותבים מחדש את המיפוי בלי להודיע.