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

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

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

ארבע עובדות רשת משתנות בין מקומות

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

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

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

הרביעית היא מיעון. תת-הרשת המקומית עשויה לחפוף לרשת שמאחורי המנהרה, או שהקישור העולה לא מספק שום נתיב IPv4 שמיש.

פתרון שמות ופורטל ההתחברות

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

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

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

סינון תעבורה: קודם UDP, TCP 443 כגיבוי

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

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

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

התנגשויות כתובות וקישורים עולים בלי IPv4

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

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

קישורים עולים של סלולר מוסיפים שני וריאנטים. NAT ברמת המפעיל פירושו שחיבורים נכנסים לא מגיעים, מה שחשוב אם אתה מארח שרת אבל לא ללקוח יוצא. APN שהוגדר כ-IPv6 בלבד עם תרגום NAT64 עלול להכשיל לקוח שמתעקש על נתיב IPv4 אמיתי, והתרופה הרגילה היא לשנות את פרוטוקול ה-APN ל-IPv4 או לערימה כפולה.

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

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

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