איך לבדוק אם מנהרת VPN בלינוקס באמת פעילה

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

דגלי הקישור מתארים את ההתקן, לא את הנתיב

הבדיקה שכולם מעתיקים מחפשת כתובת חומרה של אפסים בלבד. התחבולה הזאת מפרידה ממשק אמיתי ממציין מקום בחלק מהדרייברים ולא מוכיחה דבר בשאר, כי להתקן tun אין בכלל MAC לדווח עליו. ip -brief link show tun0 נותן במקום זאת דגלים: UP פירושו שמנהל הפעיל את ההתקן, וLOWER_UP פירושו שהדרייבר מחשיב את הקישור לשימושי. בקריאה משותפת הם אומרים שההתקן קיים ושאינו מכובה מנהלית. אף אחד מהם לא אומר שלחבילה יש לאן ללכת.

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

שאלו לאן חבילה תלך

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

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

טבלה 220 מספרת את הסיפור של IPsec

strongSwan מתקין מסלולים עבור סלקטורים שעברו משא ומתן בטבלה 220 כאשר התקנת מסלולים מופעלת. ip route list table 220 לכן מפרידה בין מה שעבר משא ומתן לבין מה שנותב: טבלה ריקה לצד חיבור טעון פירושה ש-SA של IKE ו-CHILD עלו בזמן ששום תעבורה לא מופנית אליהם. בדקו ip xfrm state לצדה, מפני שהיא מפרטת את אגודות האבטחה המותקנות ואת נקודות הקצה שלהן.

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

מצב המנהל ומצב הדמון הם רשימות שונות

NetworkManager מפרט רק את החיבורים שבבעלותו. nmcli -t -f NAME,TYPE connection show --active אינו מחזיר דבר עבור מנהרה שהופעלה ישירות על ידי wg-quick או על ידי דמון OpenVPN.

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

התנו את הצעד הבא בבדיקה שהוא צריך

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

ווים מנצחים סקירה כשהלקוח מציע אותם. --up ו--down סקריפטים של OpenVPN רצים אחרי שהממשק משנה מצב, מה שמסיר את המרוץ לגמרי, אבל הם רצים עם ההרשאות שהדמון שמר. אם OpenVPN ירד לחשבון לא מורשה דרך user וgroup, הוו רץ כאותו חשבון. הפעלה מחדש של שירות מערכת דורשת אז sudo כדי להתיר בדיוק את הפקודה הזאת. מסרו את הניסיון החוזר למנהל השירותים במקום ללופ cron: מדיניות הפעלה מחדש מוגבלת עם מגבלת התחלות חושפת מנהרה שבורה, בעוד לופ בלתי מוגבל מסתיר אותה ללא הגבלה.