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

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

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

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

אשרו את המאזין לפני שאתם נוגעים בפרופיל

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

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

# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443

שלושה תנאים קובעים אם החלופה משתלמת

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

לכל תנאי יש בדיקה זולה. כשל בכל אחד מהם נראה אותו דבר מצד הלקוח:

ConditionHow to check itWhat a failure decides
The server offers TCPThe operator's profile list, or a listening-socket check on the serverNo client-side edit can help
The path keeps long sessionsA test connection left open for an hourReconnects will look like server faults
The fallback is deliberateA change record naming the UDP faultThe underlying fault stays invisible

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

המחיר שאתם מקבלים: TCP בתוך TCP

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

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

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

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

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

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

מאמרים קשורים