VPN חסום ברשת web בלבד? עבדו לפי השכבות

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

הוכיחו איזו שכבה דוחה את החיבור

אל תתחילו בלקוח ה-VPN. התחילו בבקשת HTTPS פשוטה לאותו מארח וקראו את שלבי הזמן, כי השלב שנכשל אומר איזה התקן אחראי:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

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

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

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

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

לקוח שמודע לפרוקסי משנה את החבילה הראשונה, לא את המדיניות

אם הרשת דורשת CONNECT דרך פרוקסי מאומת, חייבים לומר זאת ללקוח ה-VPN, אחרת ינסה לפתוח socket לכתובת שאינו יכול לנתב. בדקו את הפרוקסי בנפרד מהלקוח, כדי שלכשל תהיה סיבה אחת:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

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

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

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

פורט 443 נגיש, לא מותר

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

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

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

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

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

ודאו מה באמת יצא מהמכונה

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

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

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

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

חזרה לאחור, וההערה ששווה לשמור

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

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

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

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