סיבוב PSK של AWS VPN: איזו מנהרה נופלת, ומתי

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

מה באמת קורה כשהמפתח משתנה

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

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

קראו קודם את הערכים הנוכחיים, ואז שנו שדה אחד. הסדר הזה הוא כל המשמעת של המשימה הזו.

התאימו קודם את מנהרת AWS לעמית הנכון

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

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

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"

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

תנו קודם למנהרה האחרת לשאת את התעבורה

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

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

סובבו מנהרה אחת, ואז אמתו בתעבורה אמיתית

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

1. עדכנו את עמית שער הלקוח עבור הכתובת החיצונית שנבחרה, או הכינו את השינוי כך שייכנס לתוקף שניות לאחר קריאת ה-API.
2. שלחו את קריאת השינוי עם המפתח החדש בתוספת משכי החיים וערכי ה-DPD הנוכחיים.
3. המתינו ש-IKE ו-IPsec יחזרו, ואז אשרו את המסלולים ואת הקידומות הנדרשות.
4. העבירו זרימת יישום מייצגת דרך המנהרה הזו וצפו בשני הכיוונים.

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

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

כשהשחזור נתקע, קראו את צד ה-IKE

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

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"

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