בדיקת המקור/היעד היא שער אחד, לא כל נתיב ה-VPN
מופע העברה צריך הרשאת AWS וכן נתיבי Linux וכללי חומת אש. בדקו את אימות המקור/היעד במופע שמעביר.
ה-VPN מסתיים במופע EC2, אפשר להגיע לכתובת המנהרה של אותו מופע, ותעבורה שאמורה לעבור דרכו אל מארח פרטי אחר נעלמת. אלה שתי בדיקות שונות, וערבובן מבזבז שעות. הראשונה שואלת אם אפשר להגיע למופע; השנייה דורשת שיעביר תעבורה ליעד שאינו שלו, מה שדורש העברה ב-Linux, מדיניות חומת אש, נתיב בצד הרחוק והרשאה ברמת AWS שאין לה שום קשר למערכת ההפעלה האורחת. שום דבר בקונסולה אינו מפנה תשומת לב להבדל הזה. התסמין נראה כמו תקלת ניתוב, ובדרך כלל אינו כזה.
הפרידו בין שתי הבדיקות לפני שתשנו משהו
ההגעה לשער מוכיחה את המנהרה, את הנתיב לכתובתו ואת קבוצת האבטחה שמתירה את ההחלפה. העברה עבור מארח אחר אינה מוכיחה דבר מזה: היא משתמשת בכתובת מקור אחרת, ביעד אחר ובמופע בתפקיד שלאו דווקא נבנה עבורו. כתבו את שתי הבדיקות בנפרד וציינו איזו נכשלת, כי התיקון של כל אחת נמצא בקונסולה אחרת. מופע שער שנבנה רק כדי לסיים מנהרות אין לו סיבה להעביר משהו אחר, והגדרות ברירת המחדל שלו משקפות זאת. לכן הבדיקה השנייה זקוקה להגדרה משלה ולא לתיקון קטן בראשונה.
פינג שעובד אל השער ופינג שנכשל אל המארח שמעבר לו אינו בעיה לסירוגין. זו ההתנהגות הצפויה של מופע שלא נאמר לו שהוא רשאי להעביר.
כתבו את הנתיב לפני שנוגעים בהגדרה
רשמו את קידומת הלקוח, את מופע ההעברה או ממשק הרשת, את תת-הרשת המיועדת ואת נתיב התשובה. רשומה בטבלת הנתיבים של VPC שמצביעה על מופע אינה מגדירה את מערכת ההפעלה של המופע להעביר, וליבה אורחת עם העברה מופעלת אינה יוצרת נתיב VPC. שני הקצוות של הקשר הזה חייבים להתקיים, ו-הם נערכים במקומות שונים בידי אנשים עם הרשאות שונות.
לאחר מכן בדקו את הגדרת בדיקת המקור/היעד ברכיב ההעברה בפועל, ולא בכל מופע ב-VPC. AWS מתעדת מדוע מופע שמעביר תעבורה עבור אחרים צריך שהבדיקה תהיה כבויה, וגם מדוע ההגדרה היא החלטה לכל מופע ולא ברירת מחדל לכל ה-VPC.
ארבעה גבולות, והבדיקה היא רק אחד מהם
התייחסו לנתיב כאל ארבע שאלות וענו עליהן לפי הסדר. התשובה הראשונה שנכשלת היא המקום שבו העבודה נמצאת, ואף אחת מהאחרות לא תפצה עליה.
| Boundary | Question it answers |
|---|---|
| VPC route tables | Do the destinations and replies select the intended gateway? |
| Forwarding instance | Do the AWS check and the guest OS both permit forwarding? |
| Access policy | Do security groups, ACLs and host rules allow the exchange? |
| Destination | Can the service accept that source and return a reply? |
הסדר חשוב כי הבדיקה זולה: נתיבים נראים בעמוד אחד, הבדיקה היא תכונה אחת, ודעתו של היעד היא בדרך כלל הדבר האחרון שמישהו שואל עליו.
התרגום משנה איזה מקור היעד רואה
תכנון מנותב משמר את כתובת המקור של הלקוח, ולכן היעד זקוק לנתיב חזרה לקידומת הלקוח. תכנון מתורגם מציג במקום זאת את כתובת השער, מה שמסיר את הדרישה הזו ומחליף אותה בטבלת מצבים בשער. החליטו לפי הארכיטקטורה שאתם מתכוונים לה, במקום להוסיף תרגום מפני שדוגמה לא קשורה השתמשה בו ונראתה עובדת.
אם אתם מתרגמים, הגבילו את הכלל לקידומת הלקוח וליעד המיועד. אם אתם משמרים, אשרו שהצד הרחוק אכן מכיר את הנתיב במקום להניח שהוא ילמד אחד.
בדקו מהלקוח המקורי, ואז שמרו את השינוי
בקשה שנוצרת בשער יכולה להצליח בזמן שבקשה מועברת נכשלת, כי זה מקור אחר ומקרה העברה אחר. לאחר תיקון ממוקד, חזרו על הבדיקה המדויקת של לקוח אל משאב שנכשלה, מאותו לקוח, ואשרו שהתשובה חוזרת ולא רק שהבקשה הגיעה.
לבסוף, הניחו את ההגדרה בקונפיגורציה המנוהלת של השער כדי שמופע חלופי יקבל אותה. בדיקה מוצלחת שתלויה בחריגה ידנית היא בדיקה שפגה בבנייה מחדש הבאה, והאדם שגילה אותה לא יהיה שם כדי לזכור מדוע.