VPN מחובר אבל אין אינטרנט? עברו על ארבע השכבות

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

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

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

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

החליטו אם הכשל הוא בפתרון שמות

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

nslookup example.com

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

מנהרה מלאה או רק תת-רשתות של החברה

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

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

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

כשהשרת לא מעביר שום דבר

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

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

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

בדקו שכבה אחת בכל פעם

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

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

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