RRAS במכונת Azure VM אינו נתמך: בדקו לפני התכנון
Windows Server פועל ב-Azure, אך הנחיות התמיכה של Microsoft מפרטות את RRAS כלא נתמך במכונות Azure VM. בדקו את הגבול הזה לפני שבונים סביבו VPN.
אתם פותחים את הפורטל, פורסים את Windows Server 2022 בתת-רשת, ותפקיד Remote Access מותקן בלי בעיות. הרצף הזה מוכיח שהמתקין עובד, לא ש-Microsoft תומכת בתצורה. הנחיות התמיכה המפורסמות לתוכנת שרת במכונות וירטואליות של Azure מפרטות את RRAS בין תכונות Windows Server שאינן נתמכות במכונות Azure VM, וזו החלטת ארכיטקטורה ולא פרט של פתרון תקלות. מנהרה שעולה אינה מעבירה את הפריסה אל תוך גבול התמיכה.
המדריך שלהלן מתחיל בעמוד התמיכה, ואז מתקדם אל הדרישות ואל אפשרויות ההחלפה.
התחילו בעמוד התמיכה, לא במעבדה
קראו את הנחיות התמיכה של Azure VM לפני שאתם מגדירים גדלים. הן מפרידות בין מוצרים, תפקידים ותכונות נתמכים במקום להתייחס ל-Windows Server כאל בלוק אחד בלתי מובחן. שימו לב לאיזו שורה משתייכת בפועל עומסת העבודה המיועדת, מפני ששני רכיבים שנראים קשורים בקונסולה יכולים לשבת בשורות שונות.
כתבו את הציטוט במסמך התכנון כל עוד העמוד פתוח. מצב התמיכה הוא עובדה עם מקור, וסקירת תכנון שאינה יכולה לצטט אותו תיפול בדיון מול מי שיש לו את ההדגמה.
הפרידו בין תמיכת מערכת ההפעלה לתמיכת תפקידים ותכונות
אותן הנחיות מפרטות את Network Policy and Access Services בין התפקידים הנתמכים ובמקביל מפרטות את RRAS בנפרד כלא נתמך. שתי הרשומות האלה מתארות דברים שונים, ואיחודן ל„גישה מרחוק נתמכת“ הוא הדרך שבה פרויקט מאושר על סמך קריאה שגויה. העובדה שמערכת ההפעלה נתמכת אינה אומרת דבר על תכונה שיש לה שורה משל עצמה.
המגבלה גם צרה יותר מכפי שמצטטים אותה לעיתים. היא נוגעת לאותה תכונה שרצה בתוך מכונת Azure VM; היא אינה אומרת שרשת פרטית אינה יכולה להתחבר ל-Azure, ואינה אומרת ש-RRAS אינו נתמך בכל מקום. מעבדה ותיקה שמעבירה מנות נכון היא ראיה על מנות, לא על הצהרת התמיכה.
השאירו את שתי השאלות האלה נפרדות לשאר הפרויקט: האם זה עובד, והאם זה נתמך. תצטרכו תשובות שונות ולעיתים בעלים שונים לכל אחת.
כתבו מה התכנון צריך לעשות בפועל
לפני בחירת תחליף, הפכו את רשימת האתרים לדרישות שאפשר למדוד מוצר לפיהן:
- פרוטוקולי המנהרה שציוד הסניפים כבר מדבר, והאם אתר כלשהו זקוק לניתוב דינמי.
- הקידומות המרוחקות, כולל כל מרחב כתובות חופף שזקוק לתרגום ולא לניתוב.
- חילופי מסלולים עם Azure, ומי הבעלים של כל רשומה בטבלת הניתוב.
- התפוקה ומספרי החיבורים שהשעה העמוסה ביותר חייבת להחזיק.
- התנהגות המעבר בעת כשל שהבעלים של האתרים הסכימו עליה, ולא רק זו שאתם יכולים לבנות.
NAT הוא הפריט שמדלגים עליו ואז הוא מכריע את כל התכנון. התקן שיכול להקים IPsec עדיין עשוי לתרגם כתובות אחרת מפריסת ה-RRAS שאותה הוא מחליף, וזה משנה מה הסניף רואה ככתובות מקור ומה הלוגים שלכם רושמים.
קחו את הרשימה אל בעלי הרשת ואשרו אותה לפני כל דיון במוצרים. דרישות עמומות הופכות כל השוואת ספקים לוויכוח העדפות.
העריכו תחליפים מול אותן דרישות
שירותי הקישוריות המנוהלים של Azure והתקני רשת וירטואליים נתמכי ספקים צריכים שניהם להיות מדורגים מול אותה רשימה. אל תניחו שאחד מהם הוא תחליף ישיר למכונת RRAS רק מפני שהוא יכול לסיים IPsec: מודל ה-NAT והבעלות על המסלולים ותכנון הזמינות הגבוהה קובעים כיצד האתרים הקיימים מתחברים ולאן התשובות שלהם חוזרות. דרגו כל מועמד על הנייר מול הרשימה וכתבו אילו דרישות הוא לא עומד בהן, מפני שההערה הזו היא מה שהופך את הבחירה לניתנת לבדיקה בהמשך.
מאזן עומסים לפני שתי מכונות התקן אינו זמינות גבוהה כשלעצמו. הוא מספק חזית, לא מצב מנהרה מסונכרן, ומעבר בעת כשל שמפיל כל הפעלה הוא החלטת תכנון שמישהו חייב לקבל במכוון. שאלו את ספק ההתקן מהי תבנית ה-HA הנתמכת והאם היא מתאימה לזמינות שהובטחה לאתרים. בדקו את המעבר לפני שהאתרים האלה תלויים בו, והתייחסו לכל הפעלה שאבדה כממצא ולא כהפתעה.
כשהדרישה פשוטה באמת — אתר אחד, קידומת אחת, בלי חפיפה — שירות מנוהל מנצח בדרך כלל בעלות התפעול. כשגם התרגום וגם הניתוב הדינמי נמצאים במשחק, מסלול ההתקן עשוי להיות היחיד שמתאים, וזו סיבה לתכנן הגירה ארוכה יותר במקום להשאיר את המכונה הלא נתמכת.
אם מכונת RRAS כבר פועלת
גילוי אינו סיבה למחוק אותה. תכננו את השינוי סביב התלויות שהמכונה הזו צברה: מסלולים שתת-רשתות אחרות נשענות עליהם, כללי NAT שמסתירים כתובות מקור, וכל מה שהניטור למד לצפות מכתובתה. שמרו על המסלולים הנדרשים ועל נתיב התאוששות נבדק בזמן שהיעד הנתמך מתוכנן ומאומת לצידו.
שמרו על יכולת התמיכה ועל האבחון הטכני כממצאים נפרדים לאורך כל הדרך. לסידור לא נתמך יכול להיות גם שגיאת ניתוב רגילה, ותיקון השגיאה הזו אינו משנה את מצב התמיכה שלו. שתי הקביעות שייכות לדוח, ואף אחת מהן אינה מבטלת את האחרת.
סיימו את המדריך ברישום ציטוט התמיכה, רשימת הדרישות, התחליף הנבחר וסדר המעבר. ארבעת הפריטים האלה הם מה שמבקר או חבר צוות חדש ישאל קודם.