OpenVPN לא מתחבר ב-Wi-Fi של מלון? נסו TCP 443

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

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

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

שורת המצב מספרת איזה שלב נכשל. לקוח שנתקע על מתחבר עדיין מפענח את שם המארח או פותח את השקע החיצוני; לקוח שמגיע לממתין לשרת יש לו נתיב אבל אין תשובה; לקוח שמזדהה ואז נופל סובל מבעיה אחרת לגמרי. יומן הלקוח ושדות remote ו-proto של הפרופיל עצמו מראים מה הלקוח מנסה לעשות, ו---verb 4 בלקוח של שורת פקודה מדפיס את אותה רמת פירוט. השוואה בין זה לבין הרשת שמולכם היא מה שהופך את 'ה-VPN חסום' לטענה מדויקת.

אחר כך בדקו את הרשת בכלים שכבר יש לכם. nc -vzu 203.0.113.10 1194 שולח נתיב נתונים של UDP, curl -v telnet://203.0.113.10:443 מדווח אם לחיצת יד של TCP מושלמת, ודפדפן שטוען עמוד HTTPS רק מוכיח שיציאה ל-443 מגיעה למארח האחד הזה. בדיקות קטנות עונות על מה שלקוח ה-VPN לא יכול: איזה פורט ואיזה פרוטוקול יוצאים מהרשת הזאת בכלל.

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

מעבירים את המאזין ואת הפרופיל יחד

בצד השרת, כוונו את המאזין למה שהרשת מתירה: port 443 ו-proto tcp בקונפיגורציית השרת, ואז הפעילו מחדש את השירות ואמתו את השקע עם ss -lntp. בצד הלקוח, הפרופיל חייב להסכים, כי שכבת התעבורה והפורט נמצאים מחוץ למנהרה: proto tcp ו-port 443 בקובץ ה-.ovpn, או השדות המתאימים במסך ההגדרות של האפליקציה. פרופיל שעדיין מכוון ל-UDP 1194 ייכשל בדיוק כמו קודם, והפיתוי הוא להאשים חומת אש שכבר תוקנה. אם אותו מארח גם עונה ב-HTTPS על 443, שני המאזינים לא יכולים לחלוק את הכתובת והפרוטוקול האלה; תנו ל-VPN כתובת שנייה או הציבו מפריד תעבורה מלפנים.

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

כשרק פרוקסי יוצא מהרשת

כמה רשתות אורחים לא מתירות דבר מלבד פרוקסי HTTP, וזו מגבלה שונה מפורט סגור והיא פוסלת יותר מאשר OpenVPN. לקוחות שמדברים רק PPTP, L2TP/IPsec או IPsec חשוף אין להם דרך לעבור דרכו, כי העיצובים האלה מצפים שהפרוטוקול החיצוני שלהם יגיע לשרת ישירות. OpenVPN כן יכול, עם http-proxy proxy.example.net 8080 בפרופיל הלקוח, בתנאי שהפרוקסי מתיר את שיטת CONNECT לפורט שלכם. פרוקסי SOCKS קל עוד יותר, כי הוא מעביר את הזרם בלי להתעניין במה שיש בתוכו.

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

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

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

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