צוות צריך קישוריות VPN לאפליקציה שרצה על מופע EC2 של Windows, מוצא תוכנת לקוח תואמת, מתקין אותה ואז שואל למה שאר ה-VPC לא יכולים להשתמש בה. ההתקנה עבדה; התפקיד מעולם לא הוחלט. תוכנה שרצה בתוך אורח יכולה להיות לקוח שמצטרף לרשת של מישהו אחר, שרת שמקבל לקוחות אחרים, או שאף אחד משני מוצרי ה-VPN המנוהלים של AWS, וכל תפקיד משאיר לכם עבודה אחרת.

התסמין הוא בדרך כלל התפקיד הלא נכון

התסמין הנפוץ הוא מנהרה שעובדת ופוטרת את הבעיה הלא נכונה. לקוח בתוך המכונה הווירטואלית נותן לאותה מכונה נתיב יציאה; הוא לא נותן למחשב הנייד, למשרד או לתת-רשת אחרת דרך פנימה. שרת בתוך המכונה נותן לאחרים דרך פנימה, אבל עכשיו אתם הבעלים של המאזין, של האימות ושל ההעברה.

שירותים מנוהלים מעבירים את תפעול השירות ל-AWS ומשאירים את התכנון אצלכם. Site-to-Site VPN מחבר רשתות דרך שער לקוח ושער AWS, ו-Client VPN נותן למכשירים מרוחקים נקודת קצה מנוהלת. בשני המקרים הנתיבים, כללי ההרשאה ומקור הזהות הם התצורה שלכם, ואף אחד מהמוצרים לא מתקין לקוח לשימוש כללי בתוך אורח Windows.

ארבע צורות אפשריות, והטבלה מפרידה ביניהן לפי מה מתחבר למה ומי נושא בנטל התפעולי.

RoleWhat connectsWho owns the VPN software
Client in the Windows VMThis VM dials out into someone else's networkYou, plus the software vendor
Server in the Windows VMInbound clients and sites attach to this VMYou, end to end
AWS Site-to-Site VPNTwo networks meet through a customer gateway and an AWS gatewayAWS operates the tunnels; you own the peer and route design
AWS Client VPNUser devices attach to an endpoint AWS operatesAWS operates it; you own the access rules

קראו את השורה ולא את שם המוצר: אותו מופע Windows יכול לשבת בשתי שורות שונות בהתאם לתוכנה שרצה בו.

לקוח בתוך המכונה: המכונה מצטרפת לרשת

לקוח יוצא צריך לבדוק את גרסת Windows, את הארכיטקטורה ואת דרישות מנהלי ההתקן לפני שמתקינים משהו. הלקוח ישנה נתיבים ו-DNS במופע, מה שעלול להשפיע על שירותים שכבר רצים שם, כולל הנתיב שבו אתם משתמשים לניהול מרחוק. רשמו את שם המתאם ואת מדד הממשק שהלקוח מגדיר, כי הממשק החדש עשוי לקבל קדימות על הקיים. אם המופע מנוהל דרך מנהל הפעלות ולא דרך SSH או RDP, ודאו שהנתיב הזה עדיין עובד לאחר שהלקוח מתחבר.

החליטו איזה תעבורה הלקוח צריך לשאת לפני שאתם מפעילים אותו. מנהרה מלאה עלולה ללכוד את הפעלת הניהול ולנעול אתכם בחוץ, ומנהרה מפוצלת עלולה להשאיר את המופע מגיע לרשת הפרטית בזמן שהתעבורה האחרת יוצאת ביציאה אחרת. בדקו עם נתיב ניהול שני זמין, ורשמו את הנתיבים שהלקוח מתקין כדי ששינוי מאוחר יותר יהיה ניתן להסבר.

שרת בתוך המכונה: לקוחות אחרים מצטרפים אליו

בשרת בניהול עצמי אתם הבעלים של המאזין, של התעודה או חומר המפתח, של מסד המשתמשים ושל כללי ההעברה. אם השרת מעביר תעבורה עבור לקוחות אחרים, המופע הופך לנתב, וזה דורש העברה ברמת האורח בתוספת שינויים בנתיבים ובקבוצות אבטחה ברמת AWS.

בדקו את המאזין מתוך האורח ושוב מתת-רשת אחרת, ואז בדקו מארח שהמופע מעביר אליו. שירות מקומי בריא לא מוכיח דבר על הנתיב המועבר, אז רשמו את שתי התוצאות בהערת השינוי.

שערים מנוהלים שומרים על השירות, לא על תכנון הגישה שלכם

AWS Site-to-Site VPN מתעד את תפקידי המנהרה של שער הלקוח ושל שער AWS, וקניית החיבור הזה לא מחליפה כל תכנון גישה מרחוק. Client VPN מתעד נקודת קצה מנוהלת עם פרסונות לקוח, בעוד כללי ההרשאה ונתיבי היעד נשארים שלכם. AWS מחזיק את נקודת הקצה והתעודות שלה פועלות; מי רשאי להגיע לאיזו אפליקציה הוא עדיין כלל הרשאה שאתם כותבים ומתחזקים.

בחרו בין המוצרים בחמישה צירים: איזה תפקיד כל אחד ממלא, אילו פרוטוקולים הוא מקבל, איזה מקור זהות הוא מצפה לו, כיצד מועברת התעבורה וכיצד מסופקת הזמינות. התעלמו מכל נתון תפוקה בודד שמצוטט בשרשור פורום, כי הקיבולת המפורסמת משתנה עם השירות. ואל תניחו שזוג מנהרות מנוהל משנה את התנהגותו של לקוח אורח שרירותי.

בחרו את התפקיד לפני המוצר

כתבו משפט אחד שממנה את הכיוון: המכונה הזו מצטרפת לרשת, המכונה הזו מקבלת לקוחות, או שער AWS מחבר רשתות מוגדרות.

המשפט הזה קובע את רשימת המוצרים הקצרה, את בעל התוכנה ואת מצבי הכשל שתנפו. אם הדרישה היא שמשתמשים מרוחקים יגיעו לאפליקציה, לקוח המותקן במכונה של האפליקציה הוא הצורה הלא נכונה. אם הדרישה היא שמכונה אחת תגיע לרשת של שותף, שער site-to-site מנוהל הוא יותר מכונות ממה שהמשימה דורשת. שתי התשובות לגיטימיות; רק אחת מהן מתאימה למשפט שכתבתם.

מאמרים קשורים