למה חיבור נקודה לאתר דורש שער Azure VPN מבוסס ניתוב
לשער מבוסס מדיניות אין ממשק מנהרה עבור מסלולי לקוחות. מה צריך לבנות מחדש, באיזה סדר ואילו מגבלות שורדות את ההחלפה.
שער מבוסס מדיניות בונה מנהרת IPsec שנבחרת על ידי בוררי תעבורה, ואין לו ממשק שאליו ניתן למסור מסלולי לקוחות. חיבור נקודה לאתר הוא תכונת ניתוב: השער מחזיק במאגר כתובות לקוחות ומתקין מסלולים לאותם לקוחות ברשת הווירטואלית. אי ההתאמה הזו היא הסיבה שהפורטל אינו מציג אפשרות להוסיף אותו. שום דבר בשער הקיים אינו יכול לעבור מיתוג כדי ליצור את הממשק, ולכן השינוי הוא החלפה ולא עריכת תצורה.
הסדר חשוב יותר מהשלבים הבודדים. אם הסדר שגוי, הפסקת השירות בין האתרים תימשך מעבר לחלון התחזוקה.
מה שער מבוסס מדיניות באמת עושה
שער מבוסס מדיניות מתאים חבילות לבוררי התעבורה שהוגדרו בחיבור ושולח את ההתאמות למנהרה אחת. אין ממשק מנהרה עם כתובת, ושום מסלול לכל לקוח אינו מופיע בשום מקום ברשת הווירטואלית. טבלת הניתוב פשוט מקבלת את הקידומות המקומיות שמצביעות על השער. המודל הזה מספיק לחיבור בין אתרים בין שני מרחבי כתובות קבועים.
שער מבוסס ניתוב עובד בכיוון ההפוך: הוא מציג ממשק מנהרה, והמסלולים מחליטים מה נכנס אליו. חיבור נקודה לאתר, וכל עיצוב שקבוצת העמיתים שלו משתנה, תלויים בקיומו של הממשק הזה.
למה מאגר הלקוחות צריך את הממשק הזה
כשמחשב נייד מתחבר, השער מקצה לו כתובת ממאגר נקודה לאתר. אז הרשת הווירטואלית זקוקה למסלול שאומר שכתובת זו נגישה דרך השער. בלי ממשק מנהרה אין למה לחבר את המסלול הזה.
המאגר מגיע מטווח שאתם קובעים, והשער מקצה ממנו. אם הטווח חופף לרשת המקומית או לרשת וירטואלית מקושרת, ההתנגשות מתגלה רק אחרי שלקוח מתחבר, וזה רגע גרוע לגלות אותה. הקצו את המאגר לפני שההגירה מתחילה.
גם הסוג אינו הגדרה לכל חיבור. לשער אחד יש סוג אחד, וכל חיבור שהוא מחזיק מתנהג בהתאם, ולכן עיצוב משולב צריך שער שני ולא חיבור שני.
הסוג קבוע בזמן היצירה
Microsoft מציינת שלא ניתן לשנות שער רשת וירטואלית בין מבוסס מדיניות למבוסס ניתוב לאחר הפריסה. אין פקודת המרה ואין מתג בפורטל. יצירת שער שני באותה תת-רשת אינה פתרון חלופי גם כן, משום ש-Azure מתירה שער אחד לכל רשת וירטואלית. לכן ההגירה היא הסרה, בנייה מחדש וחיבור מחדש.
זה מכניס גם את החלטת ה-SKU לאותו בנייה. מעבר ל-SKU גדול יותר בהמשך הוא החלפת שער נוספת עם הפסקה נוספת.
שער אחד, GatewaySubnet אחד
השער יושב בתת-רשת בשם GatewaySubnet, ורק שער אחד תופס אותה. תכנון הגודל של תת-הרשת הזו שייך להכנה, משום ש-SKU גדול יותר צריך יותר כתובות ולא ניתן להקטין תת-רשת לאחר מכן. תעדו את הגדרות האתר לאתר הנוכחיות, המפתח המשותף, שער הרשת המקומית והמסלולים האפקטיביים לפני שנוגעים במשהו. לאחר מכן התייחסו לחלון כהפסקה, משום שמנהרת האתר לאתר נשארת למטה עד שהחיבור החדש יוגדר.
סדר בנייה מחדש שמגביל את ההפסקה: צרו את השער מבוסס הניתוב, צרו מחדש את חיבור האתר לאתר לאותו שער רשת מקומית, אשרו את המנהרה ובקשה אחת ממארח למארח, ורק אז הוסיפו חיבור נקודה לאתר והפיקו חבילת לקוח חדשה.
מה ההחלפה לא מתקנת
מגבלה שנייה שייכת לעמית ולא ל-Azure. התקן מקומי מבוסס מדיניות יכול להגיע רק לרשת הווירטואלית שהוא מתחבר אליה, ואינו יכול לעבור לרשתות מקומיות אחרות או לרשתות וירטואליות אחרות דרך אותו שער. החלפת הצד של Azure אינה משנה מה העמית יכול לבחור.
אם הדרישה היא באמת מעבר בין אתרים, התשובה היא התקן עמית מבוסס ניתוב או טופולוגיה שבה כל יעד מסתיים בנפרד. הכריעו בכך לפני שמבטיחים תאריך, משום שהחלפת השער לבדה לא תספק זאת.
סדר הפעולות והבדיקות
אמתו כל יכולת בנפרד. תחילה מצב מנהרת האתר לאתר ובקשה אחת ממארח למארח, אחר כך חיבור נקודה לאתר ומשאב פרטי אחד, אחר כך כל נתיב מעבר שהעיצוב טוען לו. מצב שער ירוק מוכיח רק שהתאחדות האבטחה עלתה, ולא יותר. שמרו על הבדיקות בסדר הזה כדי שכשל יצביע על השלב שהכניס אותו.
הפיקו מחדש חבילות לקוח לאחר כל שינוי טופולוגיה, והרחיקו את המאגר מכל טווח מקומי ומקושר. המגבלות וההבדלים בין SKU מרוכזים במדריך הגדרות Azure VPN Gateway.