אזהרת AF_INET של OpenVPN: נפילה לאחור לא מזיקה או socket כושל?

שתי שורות יומן של OpenVPN נפתחות באותן מילים, ורק אחת מהן מדווחת על בעיה. Could not determine IPv4/IPv6 protocol. Using AF_INET היא הודעת נפילה לאחור: הפרופיל השאיר את משפחת הכתובות פתוחה, ולכן הדמון בחר אחת והמשיך. ענף הכשל מדווח שלא נוצר socket ומבקש הפעלה מחדש. כל מה שאחרי הקידומת המשותפת מפריד ביניהן, לכן קראו מעבר לה לפני שתשנו משהו.

מה מדווחת הודעת הנפילה לאחור

OpenVPN מקבל משפחה מפורשת דרך proto udp4 או proto udp6, ומקבל proto udp כאשר יש לגזור את המשפחה בעת האתחול. במקרה השני הדמון בוחן את פרטי הקישור המקומיים ובוחר.

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

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

איך נראה ענף הכשל

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

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

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

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

שרת פועל עונה על שאלת המשפחה ישירות, בלי הסקה מטקסט היומן.

ss -lunp | grep openvpn
ss -ltnp | grep openvpn

התאימו את המשפחה, הכתובת והפורט לפרופיל. שורת 0.0.0.0:1194 היא IPv4 בלבד, בעוד ששורת [::]:1194 על מארח דו-מחסנית עשויה לקבל את שתי המשפחות בהתאם להגדרת bindv6only. אם הפרופיל אומר udp וה-socket הוא IPv4, לקוחות שהפותרן שלהם מחזיר רק רשומת AAAA ייכשלו לפני שהמנהרה בכלל תנוהל משא ומתן.

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

מתי נכון לכפות משפחה

נעיצת proto udp4 מתאימה לפריסה של IPv4 בלבד: שם DNS מסוג A בלבד, כללי חומת אש לכתובת v4 אחת, לקוחות מאחורי ספקים שנותנים כתובות v4 בלבד. זה מסיר את העמימות והופך את קבוצת שורות היומן הבאה לצפויה.

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

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

שמרו על התיעוד מצומצם

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

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

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