AWS Client VPN או bastion להגעה ל-VPC עם peering
שני המסלולים עובדים, אך נשברים במקומות שונים. השוו מסלולי endpoint, ניתוב חזור ושלושת המקרים שבהם bastion הוא הגבול הכנה.
נקודת קצה אחת של Client VPN יכולה להגיע ל-VPC שמקושר ב-peering עם ה-VPC המשויך שלו, ואין צורך ב-bastion כדי לעשות זאת לגיטימי. הבחירה ששווה לעשות היא היכן התעבורה מחליפה ידיים: מסלול endpoint שנוחת בתת-הרשת של השיוך וחוצה את חיבור ה-peering, או host ב-VPC המקושר שמסיים את ההפעלה. שני המסלולים עובדים והם נכשלים במקומות שונים, ולכן ההחלטה היא על בעלות וביקורת, לא על מה ש-AWS מתיר. כך אני בוחר ביניהם, וארבע הרשומות שהופכות את המסלול המנותב לעובד.
שני מסלולים, נקודת קצה אחת, בעלים שונים
במסלול המנותב התעבורה של הלקוח מגיעה לנקודת הקצה, מתורגמת לכתובת ממשק הרשת של Client VPN בתת-הרשת של השיוך, ויוצאת מאותה תת-רשת דרך חיבור ה-peering מ-A ל-B. VPC B אינו מסיים שום הפעלת VPN; הוא רואה תעבורה רגילה מ-VPC A, ולכן מסלול החזור שלו מצביע על VPC A ולא על מאגר הלקוחות.
במסלול ה-bastion הלקוח מגיע תחילה ל-host. bastion ב-A עדיין משאיר את הקפיצה האחרונה חוצה את חיבור ה-peering, כך שאתם שומרים על עבודת ה-peering ומוסיפים הפעלה. bastion ב-B גם זקוק למסלול מהלקוח, וכאשר המסלול הזה הוא אותו מסלול endpoint, יש לכם את העיצוב המנותב ועוד קפיצה. ה-bastion מסיר עבודה רק כאשר הוא כבר קיים, כבר מאושר, והדבר שמאחוריו זקוק לגבול הפעלה ולא לגבול רשת.
ארבעה רשומות הופכות את המסלול המנותב לעובד
AWS מתעד את התרחיש הזה בעמוד Client VPN how-it-works, ובפועל זה מסתכם בארבעה רשומות שבבעלות שניים או שלושה צוותים. הטווחים להמחשה; הטווח המקושר חייב להיות ייחודי וטווח החזור חייב להתאים לתוכנית שלכם.
| Control | What it must say |
|---|---|
| Endpoint route | 10.70.0.0/16 targets the association subnet |
| Authorization rule | The approved group may reach 10.70.0.0/16 |
| VPC A association-subnet table | 10.70.0.0/16 targets the peering connection |
| VPC B resource-subnet table | VPC A's range targets the same peering connection |
מסלול והרשאה הם בקרות נפרדות. מסלול endpoint נכון בלי כלל הרשאה תואם לא נותן ללקוח דבר; כלל הרשאה ליעד שנקודת הקצה לא יכולה לנתב נותן לו חור שחור. שניהם חייבים לציין את אותו טווח.
מסלול נקודת הקצה מצביע על תת-רשת ב-VPC של נקודת הקצה עצמה, ולעולם לא על חיבור ה-peering. טבלאות המסלולים של VPC מצביעות על חיבור ה-peering, ולעולם לא על instance או ממשק. העתקת ערך בין השניים נשמרת בלי תלונה ולא מנתבת דבר.
מכיוון שתת-הרשת של השיוך מתרגמת את מקור הלקוח, B חייב לנתב חזרה ל-VPC A, ולא למאגר הלקוחות. שליחת טווח הלקוחות דרך חיבור ה-peering נראית סימטרית, עוברת סקירה ונכשלת בשקט כי B לא רואה לעולם חבילה שמקורה בלקוח.
קבוצות אבטחה והמטר האחרון של הרשאה
ניתוב מכניס חבילות ל-B; B עדיין מחליט. עבור חיבור peering פעיל באותו אזור, קבוצת אבטחה ב-B יכולה להפנות לקבוצה שמוחלת על שיוך ה-Client VPN, מה ששומר על הכלל צר ושורד שינויי כתובות. במקום שבו הפניה לקבוצה אינה אפשרית, אפשרו את טווח תת-הרשת של השיוך במפורש במקום להרחיב ל-0.0.0.0/0, מה שהופך טעות ניתוב לזמן המתנה בלתי מוסבר.
לאחר מכן בדקו מה שהניתוב לעולם לא נוגע בו: ACL-ים של רשת בשתי תת-הרשתות, רשימת ההיתרים של היישום או קהל ה-token, ו-DNS. peering לא מעתיק אזורים מתארחים פרטיים, כך שהמחשב הנייד יכול להחזיק מסלול עובד לכתובת שהוא לא יכול לפתור, וחיבור peering לא מוסיף אמון לתעודה. כוונו את נקודת הקצה ל-resolver שעונה עבור B, ואז אשרו שהשם הפרטי והתעודה תואמים.
מתי ה-bastion הוא התשובה הכנה
אני שומר שלושה טריגרים לבחירה מכוונת ב-bastion. ה-VPC המקושר שייך לצוות שלא יוסיף מסלול חזור לטווח שלכם או לא יקבל הפניה לקבוצה. הגישה חייבת להיות מאושרת או מתועדת לכל הפעלה והיישום לא יכול לשאת בכך בעצמו. או שהקפיצה האחרונה חייבת להישאר בתוך B כי השירות נפתר רק שם וזהות ה-TLS שלו מוצמדת לשם פנימי.
שום דבר מזה אינו עקיפה של העובדה ש-peering אינו טרנזיטיבי. אי-טרנזיטיביות מגבילה מה משאבים ב-B רשאים לעשות: הם לא יכולים להשתמש ב-A כטרנזיט ל-VPC שלישי ש-A מקושר איתו ב-peering. זה מעולם לא אמר שמשתמש VPN לא יכול להגיע ל-VPC מקושר ישירות, ו-bastion שנבנה כדי לעקוף את הקריאה השגויה הזו הוא host שמתעדכן ללא סיבה.
הטעות ההפוכה עולה יותר עם הזמן: העבירו כל צוות דרך ה-bastion היחיד שכבר קיים, ואז גלו שקבוצת האבטחה, טבלת המסלולים וחלון העדכון שלו הם התלות בייצור. רשמו איזה טריגר ה-host משרת, והוציאו אותו משירות כשהטריגר נעלם.
Transit Gateway ומספר שיוכים משנים את החשבון
אם נקודת הקצה מחוברת ישירות ל-Transit Gateway ולא לתת-רשת, המודל משתנה: לקוחות כבר לא מתורגמים לכתובת ממשק בתת-רשת של שיוך, וטבלאות המסלולים של השער חייבות לשאת את טווח הלקוחות ועוד את החיבור שמוביל ל-VPC המקושר. זה נקי יותר בקנה מידה, אבל העבודה עוברת מארבעה רשומות לטבלאות מסלולים של השער.
מספר שיוכים מכפיל את הבדיקות. מסלול נקודת הקצה שייך לנקודת הקצה, אך כל תת-רשת שיוך זקוקה לטבלת מסלולים עם קפיצה הבאה אמיתית של peering. הפעלה יכולה להצליח דרך שיוך אחד בעוד לאחר אין מסלול חזור, אז בדקו כל אחד.
סדר אימות שמוצא את השבר מהר
הריצו את אלה לפי הסדר; כל שלב יכול לעבור בעוד הבא נכשל, וזמן המתנה של לקוח כמעט אף פעם לא אומר איזה נשבר.
- פתרו את שם היישום מהלקוח ובדקו שהכתובת נמצאת בטווח המקושר.
- התחברו, ואז קראו את יומן החיבורים של נקודת הקצה עבור השיוך שסיים את ההפעלה.
- בתת-רשת השיוך ההיא, אשרו שטבלת המסלולים מפנה את הטווח המקושר לחיבור peering פעיל.
- בתת-הרשת של המשאבים ב-B, אשרו רשומת חזור לטווח הממשק וכללי קבוצה תואמים.
- בדקו פעולה מותרת אחת ומשאב אחד שחייב להישאר בלתי נגיש; השני תופס שאריות דיבוג.
- התחברו מחדש לאחר כל שינוי מסלול split-tunnel, כי מנהרה פועלת לא תקלוט סט מסלולים חדש.
שני תסמינים שווה לזכור. SYN שמגיע ל-B בלי תשובה הוא כמעט תמיד מסלול החזור החסר. חיבור שמסתיים ואז מתאפס הוא בדרך כלל הקבוצה, ה-ACL או היישום. אף אחד מהם לא מופיע ביומן נקודת הקצה כסיבה, אז שמרו את ארבעת הרשומות עם בעלים לצד כל אחת.
אם אף אחד משלושת הטריגרים לא מתקיים, השלימו את המסלול המנותב ותעדו את ארבעת הרשומות. אם אחד מתקיים, שמרו את ה-bastion רק לאותו גבול והשאירו את מסלול נקודת הקצה לשירותים שלא צריכים הפעלה לפני.