למה מנהרת Azure OpenVPN נופלת בערך כל שישים שניות

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

קראו את השורה הזו לפני שנוגעים בכל טיימר.

המיתוס: משהו בנתיב חוסם את המנהרה

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

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

קראו את סיבת הניתוק לפני הטיימר

OpenVPN נותן שם לסיבה שלו, וכל שם מצביע על תת-מערכת אחרת. Session invalidated: KEEPALIVE_TIMEOUT הוא טיימר שפג, ולכן השוו את ערכי ping ו-ping-restart בשני הקצוות. AUTH_FAILED הוא מצב אישורים או תעודה, ושום שינוי בטיימר לא יעזור. שגיאת TLS פירושה שהצדדים כלל לא הגיעו לשלב ה-keepalive.

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

מרווח יציב הוא טיימר. מרווח שנסחף סביר יותר שיהיה בעיית נתיב או הפעלה שהוסטה.

שני טיימרי keepalive שמעולם לא הסכימו

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

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

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

keepalive 0 0

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

שם התעודה יכול לזוז מתחת לרגליים

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

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

מה לשנות, ובאיזה סדר

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

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

יש לשנות הגדרות שער רק אחרי ארבע הבדיקות האלה.