AWS Client VPN או VPN על EC2: מדריך הפעלה

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

שלב 1: לכתוב את הדרישה לפני החשבון

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

היו קונקרטיים לגבי יעדים. «גישה ל-VPC» בדרך כלל אומרת שלושה דברים שונים: ה-CIDR של ה-VPC, רשת משותפת וטווח מקומי מאחורי Transit Gateway. נקודת קצה מנוהלת מגיעה לשלושתם, אבל כל אחד מהם דורש נתיב וכלל הרשאה, וכל אחד מהם הוא שורה נפרדת בדרישה שלכם.

שלב 2: למנות את מה שכבר פועל

לפני שמתכננים משהו, רשמו את נקודות הקצה הקיימות וכל שרת שמתארח ב-EC2 יחד עם קבוצות האבטחה שלו. הקריאות האלה הן לקריאה בלבד ובטוחות להרצה מחשבון עם הרשאות describe.

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

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

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

שלב 3: לחלק את האחריות

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

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

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

שלב 4: להשוות מול עומס עבודה שאתם יודעים לתאר

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

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

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

שלב 5: לעבור עם חזרה לאחור שכבר הרצתם

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

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

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