האם מפסק חירום של VPN שורד הפעלה מחדש? כיצד לבדוק

הפעלה מחדש היא הדרך הנפוצה ביותר שבה אנשים בודקים מפסק חירום, והיא הבדיקה שמשקרת בתדירות הגבוהה ביותר. תיבת הסימון בלקוח היא העדפה; מה שקובע הוא אם משהו כופה חסימה בין הרגע שבו מחסנית הרשת עולה לבין הרגע שבו המנהרה באמת מוקמת. ב-Windows הדבר הזה הוא בדרך כלל מסנן ב-Windows Filtering Platform, ב-Linux סט חוקים שנטען על ידי יחידה, ב-macOS עוגן pf, ב-Android הדגלים של המערכת עצמה למצב תמיד-פעיל ולנעילה. הסידורים האלה מתנהגים אחרת לגמרי לאורך הפעלה מחדש, ורק אלה ברמת הפלטפורמה נמצאים במקומם לפני שמישהו יכול להיכנס.

הפעלה מחדש מעלה שלוש שאלות נפרדות

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

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

מצאו את העצם שמחזיר את החסימה

ב-Linux חוקי netfilter חיים בליבה. שום דבר לא כותב אותם חזרה באתחול אלא אם סידרתם זאת: iptables-save ועוד netfilter-persistent, nftables.service טוען את /etc/nftables.conf, או יחידת systemd שמריצה את הסקריפט שלכם. בדקו מה מופעל ולא מה שאתם זוכרים שהגדרתם.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

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

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

הפקודה השנייה כותבת wfpstate.xml לספרייה הנוכחית. חפשו מסננים עם פעולת חסימה שכבר קיימים לפני שהלקוח מתחבר. Base Filtering Engine עולה מוקדם באתחול ומשחזר מסננים שנוספו עם הדגל המתמיד, ולכן מפסקי חירום מסוימים חוסמים תעבורה לפני שקיים חלון לקוח כלשהו ואחרים לא. ב-macOS sudo pfctl -s info מדווח אם pf מופעל, sudo pfctl -s rules מציג מה נטען, ולקוחות VPN בדרך כלל מצמידים את החוקים שלהם לעוגן ולא לסט הראשי. חוק שמזכיר את utun3 יכול להצביע על ממשק אחר אחרי האתחול הבא, כי המספר הזה מוקצה בזמן ריצה.

שימו לב לפער בין עליית הרשת לעליית המנהרה

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

במארחי systemd קראו את הסדר במקום לנחש אותו. הריצו systemctl cat על יחידות ה-VPN וחומת האש וחפשו After= או Before= מול network-pre.target ו- network-online.target. יחידת חומת אש שמסודרת אחרי network-online.target מפסידה לממשק; זו ש- network-pre.target דורש ושמסודרת לפניו מנצחת. ב-Windows השאלות המקבילות הן סוג האתחול של השירות והתלויות שלו, כי שירות שמוגדר ל-Manual לא יכול לחסום תהליך בזמן אתחול. אם הדרישה שלכם כוללת תעבורה לפני הכניסה, רק סידור ברמת ההתקן עונה עליה: מנהרת התקן של Always On VPN מאמתת עם תעודת מכונה ומתחברת לפני שהמשתמש נכנס, ו מיקרוסופט מתעדת את תצורת מנהרת ההתקן בנפרד ממנהרת המשתמש. Android הולך בדרך האחרת, כופה VPN תמיד-פעיל וחוסם חיבורים בלעדיו מהמערכת ולא מתהליך של אפליקציה.

הריצו את הבדיקה ואז השוו שני קווי זמן

הפעילו מחדש עם יעד שלא עולה דבר אם הוא דולף, ותעדו את המצב במהלך הפער ולא אחריו. השיטה הנקייה ביותר היא בדיקה בזמן אתחול: יחידת oneshot או משימה מתוזמנת שעולה מוקדם ככל שהפלטפורמה מאפשרת, רושמת את מסלול ברירת המחדל ואת מצב חומת האש, מנסה בקשה אחת עם פסק זמן קצר ומוסיפה שורה לקובץ מקומי. השוו את הרשומה הזו לשעת ההתחלה של שירות ה-VPN מ- journalctl -b -u או מיומן המערכת.

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

סתמו את הפער בלי לחתוך את דרך החזרה

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

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

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