VPN על UDP נתקע במצב סרק: חומת האש שכחה את הזרימה שלך

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

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

איך נראית תקיעה במצב סרק

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

שניהם קשורים לחוסר פעילות, והם דורשים תיקונים שונים.

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

מצאו את ההתקן ששכח

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

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

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

בדקו את הטיימרים בנתיב בפועל

ב-Linux, טיימרי המעקב של netfilter גלויים וניתנים לכוונון: sysctl net.netfilter.nf_conntrack_udp_timeout ו net.netfilter.nf_conntrack_udp_timeout_stream. השני חל ברגע שנצפתה תעבורה בשני הכיוונים, ולכן מנהרה מבוססת יכולה לשרוד בדיקה פשוטה.

RFC 4787 מגדיר את התנהגות UDP NAT ואת המינימומים המומלצים. זו ההפניה לצטט כאשר ברירת המחדל של ספק נראית קצרה באופן חריג.

Keepalive וחיבור מחדש הם כלים שונים

Keepalive שומר על המיפוי בחיים; חיבור מחדש בונה הפעלה מתה מחדש. הם פותרים תקלות שונות ואינם הגדרות מהירות הניתנות להחלפה. האפשרות PersistentKeepalive של WireGuard שולחת מנה במרווח קבוע כדי להחזיק את קישור ה-NAT פתוח. האפשרות keepalive של OpenVPN עושה את אותה עבודה בדרכה שלה. אף אחת מהן לא עוזרת אם ההתקן שבאמצע כבר שכח את הזרימה ומפיל את שני הכיוונים.

בדיקות תכופות מאוד מוסיפות עבודה בלי לתקן את הגבול הלא נכון.

אמתו עם בקשה חדשה, לא עם רענון דף

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

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