מתג נפילת רשת של VPN: איזה תעבורה הוא חוסם ומתי
התחברות מחדש משחזרת מנהרה; מתג נפילה מחליט מה קורה בזמן שהיא איננה. בדקו בנפרד ניתוק, התנתקות ידנית, יציאה מהאפליקציה והחלפת רשת.
שני מאפיינים מתוארים באותה מילה ועושים עבודות שונות. התחברות מחדש אוטומטית מנסה להחזיר את המנהרה, והיא עשויה להצליח בתוך שנייה בזמן שהבקשות נכשלות באותו פרק זמן. מתג נפילה מחליט מה יקרה לתעבורה באותו פרק זמן. קריאת לקוח כאילו השניים הם הגדרה אחת היא הדרך שבה אנשים מגיעים לבטוח בסמל במקום במדיניות.
חסימה והתחברות מחדש הן החלטות נפרדות
לקוח אחד חוסם רק כשהניתוק אינו צפוי, ואז מתחבר מחדש ומסיר את החסימה. אחר מחזיק חסימה ברמת המערכת עד שמישהו משנה הגדרה ביד, ושלישי רואה בהתנתקות מכוונת רשות לשחזר גישה רגילה. אלה שלוש התנהגויות שונות, והתיעוד של הספק אומר איזו מהן הגרסה שלכם מיישמת.
ייבוא פרופיל אינו מכריע בשאלה הזו. אותו פרופיל שרת נטען לשני לקוחות עם התנהגות חסימה הפוכה, מפני שהפרופיל נושא הגדרות ולא הבטחה. זו גם הסיבה שתיבת סימון בשולחן עבודה ומתג בטלפון עם תוויות דומות עשויים ליישם כללים שונים. קראו את התיאור שליד הבקר בפלטפורמה שלכם, ואז בדקו מה הוא עושה.
אותו פרופיל מתנהג אחרת בשני לקוחות
ההגדרות של אפליקציית OpenVPN Connect מתארות מצב מנהרה שמחזיק תעבורה רגילה רק כל עוד הלקוח מדווח על מצב מושהה או מתחבר מחדש, וזה צר יותר מהבטחה כללית על כל אירוע בכל פלטפורמה. קראו את המצבים המפורטים ולא את שם המוצר. תיאור שנכתב עבור גרסת לקוח אחת אינו עובר ללקוח של ספק אחר.
אנדרואיד מציג את אותה מילה לשני בקרים, מפני ש-VPN תמיד פעיל וחסימת חיבורים ללא VPN מתועדים בנפרד. לקוח שולחני עם תיבת סימון בשם דומה עשוי ליישם משהו צר או רחב יותר מאשר כל אחד מהם. התייחסו לתווית משותפת בשתי תפריטים כמקרה עד ששני התיאורים ייקראו. מכשירים מנוהלים מוסיפים שכבה שלישית, מפני שפרופיל מכשיר יכול לכפות הגדרה שהמשתמש אינו רואה ואינו יכול לבטל.
הגדרות פלטפורמה דומות אינן שקולות
השוו את הבקר שאתם רואים למדיניות שבאמת חלה. במכשיר מנוהל המתג הנראה עשוי להיות אפור, או דלוק בזמן שפרופיל ברמה גבוהה יותר כופה את ההפך. בקשו את המדיניות האפקטיבית ולא את המקומית, וקבלו את התשובה בכתב.
רשמו מה כל שכבה טוענת לפני שתבדקו משהו, מפני ששניהם לעיתים קרובות חלוקים והאי-התאמה נעלמת בקלות ברגע שהבדיקות מתחילות. מכשיר שחוסם כראוי בבדיקה עשוי לחסום מסיבה שאיש לא תיעד.
הריצו אירוע אחד בכל פעם ורשמו את הקוד
בדקו אירוע אחד בכל הרצה, עם בקשה בלתי מזיקה, והפכו כל ניסיון לבקשה חדשה ולא לדף שאולי כבר נמצא במטמון. הפקודות שלמטה מורידות את המנהרה, מבקשות דף ומראות אם הממשק חזר.
ip link set tun0 down
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 https://example.com
ip -brief address show tun0הטבלה מקשרת כל פעולה לתצפית שחשובה ולעדות שראויה לשמירה. בקשה שנכשלת בתוך פרק הזמן מגלה שהחסימה נכנסה לפעולה; בקשה שעוברת מגלה שהתעבורה מצאה נתיב אחר, שאולי הוא מסלול מוחרג ולא חסימה מבוטלת. חזרו על כל המערך אחרי עדכון תוכנה משמעותי או שינוי במדיניות הניתוב, מפני שכל אחד מהם יכול לשנות את הענף בלי שאף הגדרה נראית תזוז. בסוף אתם רוצים התנהגות כשל צפויה, לא סמל מרגיע.
| What I do | What I watch | Evidence to keep |
|---|---|---|
| Bring the tunnel down by hand | Whether a fresh request fails at once | The HTTP code and the client state at that second |
| Choose Disconnect in the client | Whether ordinary access returns on purpose | The same request succeeding with no tunnel up |
| Quit the app, then reboot | Whether the block outlives the client | A request made from a clean boot |
| Move from Wi-Fi to cellular | Whether DNS and IPv6 follow the policy | The resolver answer, the route table and the code again |
חריגים, שערי אורחים ומה שחסימה אינה יכולה
גישה לרשת המקומית היא החריגה הנפוצה, והיא משנה את היקף ההבטחה. לקוח עשוי להגיע למדפסת באותה תת-רשת בזמן שהוא חוסם כל דבר אחר, וזה סביר בבית ומוטל בספק ברשת אורחים. החליטו אם החריגה הזו רצויה לפני שתקרית תגלה אותה עבורכם.
חסימה קפדנית גם הופכת את הכניסה לשער של רשת אורחים למסורבלת, מפני שהשער הוא בדיוק התעבורה הישירה שהחסימה קיימת כדי לעצור. למדו את הדרך הנתמכת להרשות את הרשת, ואז שחזרו את המדיניות במכוון במקום לכבות בקרים עד שדף ייטען. שמרו את תשובת הפותר ואת טבלת הניתוב באותה הערה, כפי שמופיע למטה. מה שמתג נפילה אינו יכול לעשות הוא להפוך את השירות לאנונימי, מפני שחסימת תעבורה מחוץ למנהרה אינה אומרת דבר על מה שקורה בתוכה.
resolvectl query example.com
ss -tunp | grep -v tun0