מדוע חלק מהאתרים נכשלים רק כשהפעלת VPN?

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

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

תנו להודעת השגיאה לבחור את הענף

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

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

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

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

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

כשרק העברות גדולות נתקעות, בדקו את גודל החבילה

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

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

אמתו את התיקון על הבקשה שנכשלה

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

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

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

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