איך לגרום ל-AWS להתחיל מנהרת Site-to-Site VPN
פעולת האתחול ופעולת פסק הזמן של DPD עונות על שאלות שונות. הגדירו את זו שמפעילה את AWS, ואז בדקו את כתובת העמית ואת הנתיב של היישום.
כברירת מחדל, AWS Site-to-Site VPN ממתינה לכך שה-customer gateway יתחיל את המשא ומתן. ברירת המחדל הזו היא הגדרה, לא חוק, ושם ההגדרה הוא Startup action. לפני שאתם נוגעים בה, הפרידו שתי שאלות שמתערבבות כל הזמן: מי מקים את המנהרה, והאם לחבילות שמעניינות אתכם יש נתיב דרכה. רק הראשונה נמצאת באפשרויות המנהרה.
הפרידו בין פעולת האתחול לפעולת פסק הזמן של DPD
שתי אפשרויות לכל מנהרה שולטות בשני אירועים שונים, והגדרת האחת לא אומרת דבר על השנייה.
| Event | Option | Useful values |
|---|---|---|
| A new or modified VPN connection needs a tunnel | Startup action | add waits for the peer; start asks AWS to initiate |
| Dead peer detection times out | DPD timeout action | clear ends the session, restart reinitiates, none does nothing |
אם על AWS להקים מנהרה חדשה או שהשתנתה, בחרו start. אם על AWS גם להפעיל מחדש את המשא ומתן לאחר פסק זמן של DPD, הגדירו restart לאירוע הזה בנפרד. אף אחת מהאפשרויות אינה מדיניות ניסיונות חוזרים של היישום, ואף אחת אינה מרווח החלפת מפתח: DPD בודק אם העמית חי, בעוד החלפת מפתח מחליפה את ה-security associations במנהרה פעילה.
יישום שנגמר לו הזמן בעוד המנהרה עדיין מדווחת up סובל מבעיה בנתיב הנתונים. קיצור טיימר ה-DPD לא יתקן זאת, ועלול להוסיף תנועה שתצטרכו להסביר לאחר מכן.
בדקו של-AWS יש לאן לשלוח את המשא ומתן
אתחול מצד AWS עובד רק עם IKEv2, ו-AWS זקוקה לכתובת הציבורית של ה-customer gateway כדי לדעת לאן לשלוח את ההצעה. המקרה שכואב הוא משאב customer gateway מאומת בתעודה שנוצר בלי כתובת: התיעוד של AWS מתאר יצירת משאב customer gateway חדש עם הכתובת ואז שינוי חיבור ה-VPN כך שיצביע עליו.
תעודה מוכיחה מי העמית. היא לא אומרת ל-AWS היכן העמית נמצא, ואלה שתי דרישות שונות. לכן התיקון הוא משאב customer gateway חדש ולא תעודה חדשה. החלפת התעודה מותירה את AWS עם אותה מטרה חסרה.
אם ה-customer gateway נמצא מאחורי NAT, AWS זקוקה גם ל-responder identity מוגדר, IDr, כך שזהות העמית תתאים למה שהמכשיר מצפה לו. אשרו את הערך הזה ואת נתיב חומת האש שמאפשר תעבורת IKE לפני שאתם מאשימים את האפשרות שזה עתה שיניתם. בחירה ב- start לא יכולה לגרום לעמית שאינו נגיש או מזוהה בטעות לקבל הצעה.
החילו את השינוי על מנהרה אחת וצפו להפסקה
לחיבור VPN יש שתי מנהרות עם אפשרויות בלתי תלויות, אז אשרו לפי הכתובת החיצונית איזו מהן אתם עורכים. AWS מאפשרת לשנות מנהרה אחת בכל פעם, והקישוריות דרך המנהרה הנבחרת עלולה להיקטע לכמה דקות.
- בחרו את חיבור Site-to-Site VPN ופתחו Modify VPN tunnel options.
- בחרו את המנהרה לפי כתובת ה-IP החיצונית ואשרו את גרסת ה-IKE ואת משאב ה-customer gateway.
- הגדירו את פעולות האתחול וה-DPD שאתם באמת רוצים, ואז שמרו בחלון שאתם שולטים בו.
- אשרו שהמנהרה ששונתה מתייצבת, ובדקו את המנהרה השנייה ואת הניתוב לפני השינוי הבא.
התנהגות אחת ראויה לתשומת לב לפני תחזוקה. כשאתחול מצד AWS מופעל אין פסק זמן: AWS ממשיכה לנסות עד שהמנהרה עולה, והיא מתחילה מחדש כשה-customer gateway שולח הודעת delete-SA. אם תורידו את העמית בכוונה, AWS תמשיך לדפוק, והלוגים של העמית יראו זאת.
אמתו את הנתיב של היישום, לא רק את מצב המנהרה
מנהרה שמדווחת up אינה אותו דבר כמו בקשה שעובדת. פונקציית Lambda המחוברת ל-VPC עדיין זקוקה לנתיב subnet אל הקידומת של הלקוח, לכללי security group ו-network ACL שמתירים את התעבורה, לפתרון שמות שמחזיר את הכתובת הנכונה, ול- נתיב חזרה בצד הלקוח.
בדקו פעם אחת עם בקשה אמיתית מההקשר של היישום, ואז קראו את ה-flow logs אם היא נכשלת. תעבורת keepalive היא אפשרות לגיטימית כשאתחול מצד AWS כבוי ומנהרה לא פעילה זקוקה לחבילות כדי להישאר למעלה, אבל זו צריכה להיות החלטת ניטור שאתם יכולים לנקוב בשמה, לא לופ ping לא מוסבר שמוברג לפונקציה.
בחרו קודם מי מקים את המנהרה, ואז אבחנו את הכשל הנותר בשכבה שלו. התיעוד של AWS על אתחול מכסה את דרישות הכתובת, הזהות והניסיונות החוזרים בפירוט רב יותר מהרמזים בקונסולה.