AWS Client VPN עם מנהרה מפוצלת: אילו נתיבים לפרסם

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

דגל מנהרה מפוצלת אינו רשימת יעדים

AWS מתארת מנהרה מפוצלת כהוספת נתיבי נקודת קצה לטבלת הנתיבים של הלקוח בעת הקמת החיבור. נתיב ל-VPC הפרטי מגביל את המנהרה ליעד הזה; כל השאר הולך בדרך הרגילה של הלקוח. נתיב ברירת מחדל הוא הוראה אחרת עם השפעה אחרת, ולכן התיעוד של המנהרה המפוצלת מזהיר מפני פרסום 0.0.0.0/0 בנקודת קצה שמוגדרת למצב הזה: הוא נוטה לשבור את הקישוריות ולא להרחיב אותה. טבלת הנתיבים של נקודת הקצה היא המדיניות, וטבלת הנתיבים של הלקוח היא התוצאה שאפשר לבדוק.

קראו את טבלת הנתיבים של נקודת הקצה ואת הנתיבים המותקנים של הלקוח יחד. התווית מתארת כוונה; הנתיבים מתארים מה קורה.

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

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

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

החלטה שנייה: אילו קידומות פרטיות, ובאישור מי?

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

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

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

החלטה שלישית: איזה resolver הולך אחרי המנהרה?

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

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

שנו את מערך הנתיבים ואז אמתו את שני העולמות

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

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

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