TCP עובד ו-UDP מגיע לשרת אחר באותה יציאה

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

מספר יציאה אחד, שני כללים בלתי תלויים

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

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

כתבו את שתי המיפויים לפני שתשנו משהו אחר. צמד השורות הוא כל ההשערה.

מה הלקוח באמת אימת

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

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

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

קשרו את הניסיון לשרת

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

השוו את זהות התעודה שנתקלתם בה לזהות המצופה בערוץ ניהולי. ההשוואה מחוץ לערוץ היא מה ששומר על האמינות של הבדיקה.

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

אל תתאימו את האמון לצד שגוי

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

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

שמרו את טקסט הדחייה. זהו התיעוד היחיד של מה שהלקוח ראה.

לאחר התיקון, בדקו זרימה חדשה

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

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