מדוע VPN יכול להיראות מחובר כששום דבר לא עובד

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

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

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

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

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

איזה מונה מוכיח שהחבילות זזו

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

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

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

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

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

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

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

רשמו את הטריגר, ואז שנו דבר אחד

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

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

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