האינטרנט עובד רק כשאפליקציית ה-VPN דולקת? בדקו ארבעה רבדים

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

הלקוח משנה הגדרות שהמנהרה אינה שולטת בהן

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

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

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

שלוש שאריות, שלושה כשלים שונים

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

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

עברו על ארבעת הרבדים

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

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

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux ו-macOS צריכים פקודות משלהן, והן אינן ניתנות להחלפה. ב-Linux הנתיבים מגיעים מ-ip route והפותר מ-resolvectl status במקום שבו systemd-resolved שולט, עם נפילה ל-cat /etc/resolv.conf. ב-macOS הנתיבים מגיעים מ-netstat -rn, הפותרות מ-scutil --dns, והפרוקסי המערכתי מ-scutil --proxy. קורא ב-macOS שמריץ ip route יקבל command not found, ו-/etc/resolv.conf שם הוא שלד שנוצר ולא התצורה הקובעת. בדקו את הפלטפורמה לפני שאתם בודקים את הרובד, אחרת הפקודה הראשונה הופכת לממצא.

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

פרוקסי אינו מנהרה

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

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

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

הסירו את הרכיב, לא את הראיות

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

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

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