לקוח OpenVPN נתקע כאשר השרת שלו פועל באותו מארח

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

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

קראו את התסמין לאחור

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

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

שקע אחד והתקן אחד לכל מופע

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

lport 1195
nobind
dev tun1

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

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

בחרו בעלים אחד למסלול ברירת המחדל

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

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

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

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

אמתו עם הטבלה, לא עם שורת המצב

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

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

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

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