מכונה וירטואלית אחת ב-Azure זקוקה למנהרה: לקוח אורח או שער VPN?
שלושה תנאים קובעים אם מכונה וירטואלית אחת ב-Azure צריכה להריץ לקוח VPN משלה או אם החיבור שייך לשכבת הרשת במקום.
עומס עבודה אחד במכונה וירטואלית אחת ב-Azure צריך להגיע לרשת פרטית דרך מנהרה. השאלה שמכריעה את התכנון אינה איזה מוצר VPN טוב יותר; היא אם מכונה אחרת אי פעם תזדקק לנתיב הזה. ענו עליה קודם, ושאר הארכיטקטורה בדרך כלל בוחרת את עצמה. טעות כאן מותירה מכונה שהפכה בשקט לנתב שאיש לא תיעד.
שתי עבודות שנראות דומות
מכונה וירטואלית יכולה להיות נקודת קצה או נקודת מעבר, וההבדל אינו התוכנה שמותקנת אלא מי צורך את המנהרה. כנקודת קצה, האורח מריץ לקוח עבור התהליכים שלו. כנקודת מעבר, היא מעבירה מנות של עומסי עבודה אחרים, מה שהופך אותה לחלק מהטופולוגיה של הרשת.
| Job | What the VM does | Who owns routing |
|---|---|---|
| Workload endpoint | Runs a supported client for its own processes | Guest routes select the approved destinations |
| Transit appliance | Forwards other workloads into the site connection | Subnet route tables, NIC forwarding, guest policy and return paths |
רוב הבקשות למכונה בודדת הן העבודה הראשונה בעטיפה של השנייה. מישהו אומר "המכונה היא ה-VPN שלנו" כשהוא מתכוון לכך שאפליקציה אחת עליה צריכה להגיע למסד נתונים בצד השני.
תנאי ראשון: האם משהו אחר זקוק לצד השני?
אם התשובה שלילית, התקינו את הלקוח באורח והפסיקו לתכנן. שום דבר בבחירה הזו לא מחייב את השער המנוהל, ושום דבר בה לא הופך את המכונה לשער עבור שכנותיה. אתם מוסיפים נתיב בתוך מערכת הפעלה אחת.
אם התשובה חיובית, או כנראה חיובית בתוך שנה, התייחסו לזה כתכנון רשת עכשיו. מכונות אחרות מגיעות למכונת מעבר רק כשטבלת הנתיבים של תת-הרשת שולחת אותן לשם וכרטיס הרשת מקבל תעבורה מועברת, ולכן העבודה היא טבלאות נתיבים והרשאות העברה, לא התקנת לקוח נוסף.
תנאי שני: האם תוכלו לשמור על נתיב הניהול?
לקוח VPN שמתקין נתיב רחב עלול לתפוס את הנתיב שבו אתם מנהלים את המכונה. אם רשימת היעדים של המנהרה חופפת לרשת הניהול, הפעלת SSH או RDP שלכם נופלת ברגע שהלקוח מתחבר, והתיקון יצטרך להיעשות דרך קונסולת הסריאל או בנייה מחדש.
בדקו לפני ואחרי. בלינוקס, ip route get <management-ip> אומר לכם איזה ממשק ומקור הגרעין ישתמש בהם כעת; השוו לכך את התשובה כשהמנהרה פעילה. מנהרה מפוצלת עם רשימת יעדים מפורשת קלה יותר להגנה מנתיב ברירת מחדל, והיא בדרך כלל מה שעומס העבודה באמת צריך.
תנאי שלישי: מי מדביק טלאים בחצות?
לקוח אורח הוא מערכת ההפעלה שלכם, גרסת הלקוח שלכם והתעודות שלכם. זה בסדר כשאתם כבר מתחזקים את המכונה ואת מחזור הטלאים שלה. זו עסקה גרועה כשהמכונה קיימת רק כדי להחזיק את המנהרה. ספרו את שעות התחזוקה לפני שתקראו ללקוח האורח זול יותר. שדרוג לקוח שדורש אתחול הוא השבתה שקבעתם למכונה שקיימת כדי לשמור על המנהרה פעילה.
השער המנוהל מעביר את התחזוקה הזו לפלטפורמה. אתם עדיין הבעלים של הזהות, ההרשאה ונתיבי הרשת שמאחוריו, אבל אינכם מאתחלים מכונה כדי להחיל עדכון לקוח.
מה השער המנוהל לא עושה
Azure VPN Gateway הוא שירות קישוריות של VNet עם הסדרי site-to-site ו-point-to-site משלו. הוא לא כלל שאוסר תוכנת VPN באורח, והוא לא תחליף ישיר ללקוח שאפליקציה אחת זקוקה לו.
מה שהוא נותן הוא חיבור בשכבת הרשת, שנגיש לעומסי עבודה רבים דרך ניתוב. מה שהוא לא נותן הוא מנהרה שרק תהליך אחד במכונה אחת משתמש בה, מוגבלת לזהות של אותו תהליך. ההיקף הזה אינו מגבלה שיש להתנצל עליה; הוא בדיוק הנקודה של תכנון לקוח האורח. אפליקציה אחת, נתיב אחד, סט תעודות אחד, ללא השפעה על המכונות האחרות בתת-הרשת.
לכן ההשוואה אינה מנוהל מול תוכנה. היא קישוריות בהיקף הרשת מול קישוריות בהיקף התהליך, והשנייה לגיטימית כשרק תהליך אחד זקוק לה.
תכננו את נתיב הגדילה לפני שתזדקקו לו
אם הדרישה גדלה ממכונה אחת לתת-רשת, בנו את התכנון מחדש במקום להרחיב את הקידומות המותרות של הלקוח. שימוש חוזר בסשן נוח כנתב לא מתועד קושר כל צורך בחיי המכונה, בתעודות שלה ובחלון הטלאים שלה.
סקירת Azure VPN Gateway היא נקודת ההתחלה הנכונה ברגע שהחיבור הוא בהיקף הרשת ולא בהיקף עומס העבודה.
לפני שתבחרו, כתבו שלוש שורות: מה זקוק לצד השני, מי מנהל את המכונה, ומי מדביק טלאים למנהרה. אם כל שלוש התשובות מצביעות על עומס עבודה אחד, לקוח אורח הוא התכנון הכשר. אם אחת מהן מצביעה על תת-רשת, תכננו את שכבת הרשת עכשיו.