האם כדאי להפעיל יומני מנהרה של AWS VPN על מנהרה פעילה?
הפעלת יומני פעילות של המנהרה עלולה לקטוע מנהרה פעילה למספר דקות. החליטו איזו מנהרה, איזה סוג יומן ואיזה חלון זמן לפני שמשנים משהו.
הפעלת יומני פעילות מנהרה עבור VPN Site-to-Site היא שינוי קטן שעלול להפיל את המנהרה שהוא מודד. AWS מזהירה שהפעלת רישום על מנהרה קיימת עלולה לקטוע אותה למספר דקות, ולכן השאלה המעניינת אינה איך להפוך את הדגל אלא על איזו מנהרה להפוך אותו ומתי. שלושה תנאים קובעים את הסדר: אם המנהרה השנייה באמת נושאת את המסלולים, אם אתם צריכים אירועי שירות או אירועי BGP, ואם השינוי עובר דרך הקונסולה או דרך ה-API של אפשרויות המנהרה. אם תטעו בהם, תסיימו או בהפסקה או בקבוצת יומנים מלאה בכלום.
שלושה תנאים קובעים את הסדר
התחילו בזהות הדבר שאתם משנים. אתם צריכים את מזהה חיבור ה-VPN, את האזור ואת כתובת ה-IP החיצונית של המנהרה הספציפית, מפני שכל הגדרת יומן בתכונה הזו היא לפי מנהרה ולא לפי חיבור. שינוי שמוחל על הכתובת החיצונית הלא נכונה הוא שינוי במנהרה שאיש לא ניקה בה באגים.
היעד הוא קבוצת יומנים של CloudWatch באותו אזור, עם מדיניות השמירה והגישה שאתם באמת רוצים. AWS ממליצה על הקידומת /aws/vendedlogs/ עבור קבוצות אלו מפני שהיא נמנעת ממגבלות הגודל של מדיניות משאבים ששמות פשוטים עלולים להיתקל בהן. שם כמו /aws/vendedlogs/vpn/branch-a-activity הוא רק להמחשה; מה שחשוב הוא שהקבוצה קיימת, שתפקיד המסירה יכול לכתוב אליה, וששניהם מנוהלים על ידי מי שמחזיק בקונפיגורציית ה-VPN. השם לא מעניק הרשאות, וקבוצה שנוצרה בלי מדיניות המסירה מייצרת שקט ולא שגיאה.
תנאי ראשון: מנהרה עודפת שבאמת נושאת תעבורה
זה התנאי שצוותים מדלגים עליו. שתי מנהרות מוגדרות אינן הוכחה שליישום יש נתיב חלופי שמיש.
לפני שאתם נוגעים במנהרה אחת, ודאו שהשנייה נושאת את המסלולים החשובים: בדקו את טבלת הניתוב בצד שער הלקוח, ואז ודאו שהיישום באמת יכול לעבור למשנהו. חלון הקטיעה של AWS נמדד בדקות ולא בשניות, ומנהרה שקיימת רק על הנייר הופכת שינוי אבחוני להפסקה. אם הנתיב העודף לא הוכח, תכננו את השינוי באותה זהירות כמו כל שינוי ניתוב אחר במקום להתייחס לרישום כאל פסיבי. מדדו את המנהרה שאת התנהגותה אתם מנסים להסביר, לא את זו שקל יותר להגיע אליה.
תנאי שני: יומן פעילות או יומן BGP
התנאי הזה קובע מה באמת תוכלו לקרוא. רשומות פעילות מכסות אירועי שירות כמו מעברי מצב של IKE ו-IPsec והודעות DPD, וזה מה שאתם רוצים כשהמנהרה לא עולה או ממשיכה לחדש מפתחות. רשומות BGP הן זרם נפרד עם בקרות משלו, והן עונות על שאלה אחרת: אם המסלולים הוחלפו ונמשכו כמצופה.
הפעלת דגל הפעילות אינה בקשה לכל זרם שהשירות יכול לפלוט. אם החשד הוא בניתוב, הפעילו את שניהם; אם החשד הוא במשא ומתן של שלב 1 או שלב 2, זרם הפעילות הוא זה שיראה זאת.
אף אחד מהזרמים אינו לכידת מנות, וההבחנה הזו מכריעה יותר קריאות ממה שהיא צריכה. רשומות פעילות ו-BGP אומרות לכם מה השירות עשה עם המנהרה והסשן, לא מה היישום שלכם שלח דרכם. לפנות ליומני מנהרה כדי לנפות פסק זמן של יישום זו שגיאת קטגוריה, והיא בדרך כלל עולה בחלון קטיעה לפני שמישהו שם לב. בחרו קודם את השאלה, ואחר כך את הזרם שיכול לענות עליה.
תנאי שלישי: שינוי בקונסולה או ב-API של אפשרויות המנהרה
אם אדם מבצע שינוי חד-פעמי, מסלול הקונסולה מתאים: VPC console, Site-to-Site VPN connections, בחרו את החיבור, Actions, Modify VPN tunnel options, בחרו את ה-IP החיצוני, הפעילו Tunnel activity log, בחרו את הקבוצה ואת תבנית הפלט, ושמרו בתוך החלון. אם ה-VPN מנוהל כקוד, אותה לחיצה היא סטייה שתיישבו מאוחר יותר.
לאוטומציה, לחלק יומן הפעילות באפשרויות המנהרה יש צורה קבועה: LogOptions שמכיל CloudWatchLogOptions עם LogEnabled, LogGroupArn ו-LogOutputFormat. הבלוק הזה הוא שבר, לא בקשה; modify-vpn-tunnel-options עדיין צריך את מזהה החיבור ואת ה-IP החיצוני של המנהרה, ואת שאר הגדרות המנהרה חייב לשמר מי שמחזיק בתבנית. רישום BGP משתמש במפתחות שלו BgpLogEnabled, BgpLogGroupArn ו-BgpLogOutputFormat באותו מבנה. קראו את השינוי בחזרה עם describe-vpn-connections במקום להאמין שהקריאה הוחלה.
מה הרשומות יכולות ומה לא יכולות לספר לכם
לאחר שהמנהרה הראשונה הושלמה והנתיב המיועד זמין, חזרו על אותו רצף מבוקר עבור המנהרה השנייה אם גם היומנים שלה דרושים לכם. מנהרה אחת בכל פעם היא כל העניין.
רשומות מגיעות בזרמים שמזוהים על ידי החיבור וכתובת ה-IP החיצונית של המנהרה, לכן תאמו מול הזהות הזו במקום לצפות שההיסטוריה תופיע בדיעבד. שום דבר לפני השינוי לא קיים, ושום המתנה לא ממלאת את הפער. אם אתם צריכים קו בסיס, תעדו את מצב המנהרה הנוכחי ואת טבלת הניתוב לפני השינוי כדי שיהיה למה להשוות.
שמרו את קבוצת היומנים, את השמירה שלה, את הרשאות המסירה שלה ואת בלוק אפשרויות המנהרה באותו מלאי כמו ה-VPN עצמו, מפני שזו קונפיגורציה אחת הפרוסה על ארבעה מקומות. ההליך של AWS להפעלת יומנים מתעד את זרימת העבודה לכל מנהרה ואת אזהרת הקטיעה שלה, וכדאי לקרוא אותו לפני השינוי ולא אחריו. אחר כך אמתו לפי הסדר: המנהרה חזרה, רשומות מופיעות בזרם הצפוי, והרשומות עונות על השאלה שלשמה פתחתם את הקריאה. אם השלישי נכשל, הבעיה הייתה בחירת הזרם ולא ברישום.