UDP לא תמיד מהיר יותר: בחירת התובלה של OpenVPN

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

מה התובלה באמת משנה

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

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

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

איפה TCP זוכה במקומו

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

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

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

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

בדקו איזה מאזין באמת יש לכם

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

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

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

אימות בצד הלקוח זול: הריצו את החיבור עם --verb 4 וקראו את שורת התובלה בלוג. אם הלקוח אומר UDP בזמן שהשרת מאזין ב-TCP, לחיצת היד לא מתחילה לעולם ושום כוונון לא יעזור.

השוו את עומס העבודה, לא את תווית התובלה

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

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

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