מה מסך iftop יכול להוכיח על VPN ומה הוא לא יכול

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

שלושה תנאים קובעים מה המשמעות של המסך

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

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

תנאי ראשון: איזה ממשק מוצג

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

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

תנאי שני: מה המסנן והכלי מסתירים

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

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

תנאי שלישי: מה הבדיקה הפעילה בפועל

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

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

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

שימוש ב-iftop כראיה תומכת

רק אז iftop מוסיף ערך, והוא מוסיף אותו כאימות. sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" מראה אם הזרימה שציפיתם לה מופיעה בממשק שציפיתם לו, עם ספירות בייטים שהופכות טענת חוסר פעילות לניתנת לבדיקה.

השוו זאת עם ss -tnp לתצוגה ברמת השקע ועם ip route get למסלול שהגרעין היה בוחר, ויש לכם שלוש תצפיות של בקשה אחת במקום רושם אחד של מכונה. המדריך של iftop מתעד את בחירת הממשק, את תחביר המסנן ואת התנהגות החיפוש, שהם שלושת הדברים שבדיקת דליפה תלויה בהם. מסך רוחב פס מאתר פעילות; המסלול, החריגים והתנהגות הכשל קובעים אם אותה פעילות עומדת בדרישה.