OpenVPN מתחבר אבל שום דבר לא זורם: מצאו את השכבה שבה החבילה נופלת

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

השקע או כבול או לא

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

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

ss -lunp | grep 1194
ss -ltnp | grep 1194

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

לכדו את החבילה החיצונית, לא את המנהרה

סננו לפי הממשק הפיזי והפורט האמיתי, עם הממשק שלכם מוחלף: tcpdump -ni eth0 udp port 1194. חבילות יוצאות ששום דבר לא חוזר מהן מצביעות על מה שיושב במעלה הזרם: סינון של הספק, התקן NAT, או כתובת מרוחקת שאינה זו שאתם חושבים. שתיקה בשני הכיוונים מצביעה על ניתוב הלקוח או חומת אש מקומית. תשובות שמגיעות בלי התקדמות במנהרה מצביעות על ערוץ הבקרה, כלומר אי-התאמה במפתח או בצופן, ולא על סינון.

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

קודם מונים, מעקב רק כשהם משקרים

התחילו במונים, כי הם לא עולים כלום. nft list ruleset או iptables -L -n -v עונה על השאלה היחידה שחשובה כאן: האם הכלל התאים? הסדר קובע את התוצאה, כי ההתאמה הראשונה מנצחת, ולכן DROP רחב לפני ACCEPT מאוחר יותר משאיר את ה-ACCEPT הזה מת, ולכן הוספת כלל כל כך נדיר מתקנת משהו.

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

רק כשהמונים נשארים דו-משמעיים שווה היומן את הרעש, וגם אז רק לפרוסה צרה: כלל iptables שמגביל קצב ומקדים את שורות היומן שלו, או כלל nftables שנושא meta nftrace set 1 בזמן ש-nft monitor trace רץ. מעקב נותן שם לשרשרת ולכלל שקיבל או השליך את החבילה. הסירו את שניהם אחר כך והשאירו רישום מטען מחוץ לזה.

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

ניתוב והדרך חזרה

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

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

מה הרשומה חייבת לומר

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

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