מתאם OpenVPN מהבהב ב-Windows? בדקו כתובת IP כפולה

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

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

התחילו ביומן האירועים של Windows, לא ביומן הלקוח

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

שלפו את האירועים האחרונים והשוו את חותמות הזמן שלהם למחזור החידוש של המתאם: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. התנגשות כל חמש עשרה שניות מתאימה ללקוח שמנסה שוב את אותה כתובת מול בעלים שממשיך לענות עליה. התנגשות בודדת בזמן החיבור מצביעה דווקא על התנגשות חד-פעמית. כך או כך, השאלה הבאה היא מי עוד מחזיק בכתובת.

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

שאלו את השרת מי לדעתו מחזיק בכתובת, ואז שאלו את הרשת מי עונה עליה. grep -H ifconfig-push /etc/openvpn/ccd/* מפרט כל כתובת מנהרה מוצמדת ואת התעודה שאליה היא שייכת. ip -4 neigh show dev tap0 מראה מה הגשר למד בשכבה השנייה. השוואה בין שתי הרשימות האלה מוצאת את רוב הכפלים בפחות מדקה.

שלושה סידורים מסבירים כמעט את כולם: רשומה ב-client-config-dir מצמידה כתובת אחת לשתי תעודות, קטע tap מגושר נותן למכונה כתובת שכבר יש למארח אחר באופן סטטי, או קובץ חכירה מיושן מחזיר כתובת שלקוח שעדיין מחובר חושב שהוא הבעלים שלה. המקרה השלישי הוא הערמומי ביותר, כי ifconfig-pool-persist עושה שימוש חוזר בכתובות במכוון עבור לקוחות מוכרים.

הפכו את הכתובת לייחודית במקום להתחרות עליה

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

מחקו את קובץ ה-persist רק אחרי שאתם יודעים אילו חכירות הוא מחזיק, אחרת החיבור הבא מחדש יחלק שוב את אותן כתובות.

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

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

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

צפו לאורך מחזור חידוש מלא לפני סגירת הפנייה

קריאה נקייה אחת לא מוכיחה דבר. צפו במתאם לפחות עשר דקות וכפו חיבור מחדש באמצע: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. הכתובת אמורה לשרוד את החיבור מחדש ולהישאר במצב מועדף.

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

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