המאזין של OpenVPN 2.5 ב-DD-WRT מת? קראו את התצורה שהוא יצר

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

הדמון אינו חומת האש

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

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

קראו את התצורה ש-DD-WRT יצר

DD-WRT לא מעביר ל-OpenVPN את הטקסט שהקלדתם בממשק האינטרנט. הוא כותב תצורה שנוצרה אל /tmp/openvpn/openvpn.conf ומפעיל את הדמון עם הקובץ הזה, כך ששדות הממשק וכל טקסט ב-Additional Config ממוזגים לפני ש-OpenVPN רואה אותם. אם אתם מדבגים את הטופס במקום את הקובץ שנוצר, אתם קוראים כוונה ולא את הקלט בפועל. העתיקו את הקובץ למקום קבוע לפני שאתחול /tmp ינקה אותו.

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

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

מה OpenVPN 2.5 הפסיק לקבל

OpenVPN 2.5 החליף את ncp-ciphers ב-data-ciphers, והעלה את גרסת ה-TLS המינימלית המוגדרת כברירת מחדל ל-1.2. הוא גם שינה את הטיפול בדחיסה כך שעמית שמציע דחיסה נדחה אלא אם התצורה מתירה זאת במפורש, והוא סימן כשמות אפשרות ישנים כמו ns-cert-type כמיושנים לטובת remote-cert-tls. כל אחד מהשינויים האלה הופך תצורה שעבדה בעבר לכשל ניתוח או משא ומתן.

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

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

דרישות המוקד הייחודיות ל-Broadcom

בגרסאות Broadcom התקן המנהרה חייב להתקיים לפני שהדמון יכול להשתמש בו. בדקו שמודול tun נטען וש-/dev/net/tun קיים, כי התקן חסר יוצר כשל התנעה שאין לו שום קשר לתעודות. כך גם לגבי סקריפטי העזר ש-DD-WRT יוצר עבור מסלולים ו-DNS: אם הם חסרים או אינם ניתנים להרצה, הדמון יכול לעלות ובכל זאת לא לסיים את ההגדרה שלו.

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

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

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

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

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

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