לקוח VPN נייד בלי הרשאות מנהל: מה בכל זאת נשבר

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

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

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

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

מצאו את העוזר המיוחד שהלקוח יקרא לו

כמעט שום לקוח VPN לא מזיז חבילות בעצמו. ב-Windows נתיב הנתונים עובר דרך מסנני WFP ומנוע Base Filtering Engine, ב-macOS דרך ספק NetworkExtension שהמשתמש מאשר בהגדרות המערכת, וב-Linux דרך התקן tun בתוספת מחסנית הניתוב. קובץ ההרצה שהעתקתם הוא משטח שליטה לאותם רכיבים, לא תחליף להם. שאלו איזה רכיב הלקוח מצפה לו, ואז ודאו שהוא מותקן, פועל ושחשבונכם יכול להשתמש בו.

Linux הוא המקום הקל ביותר להוכיח את הנקודה, מפני שהבדיקה היא קריאת מערכת אחת. פתיחת /dev/net/tun ובקשת התקן מהגרעין דורשת CAP_NET_ADMIN, וה תיעוד הגרעין ל-TUN/TAP מפרט גם את כלל הבעלות וגם את היכולת. הריצו את הבדיקה בחשבון שיפעיל את הלקוח, לא כ-root.

ls -l /dev/net/tun
ip tuntap add dev vpntest mode tun
ip link delete vpntest

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

בדקו שינויי מסלול ורזולבר לפני החיבור הראשון

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

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

ip route add 10.20.0.0/16 dev vpntest
ip route del 10.20.0.0/16
resolvectl query intranet.example.internal

אם השורה הראשונה מחזירה RTNETLINK answers: Operation not permitted, פירושו שהחשבון לא יכול להתקין את המסלול הפרטי שהפרופיל דורש. השורה השנייה מוכיחה את אותה זכות בכיוון ההפוך, וזה חשוב מפני שלקוח שיכול להוסיף מסלולים אבל לא להסיר אותם משאיר טבלה שבורה מאחוריו. לאחר מכן שאילתת הרזולבר מראה אם שמות פרטיים נפתרים דרך המנהרה או דולפים לרזולבר שהמארח כבר סומך עליו.

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

החליטו מה חייב לשרוד את ההפעלה

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

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

ip -brief addr show
ip route show table main
resolvectl status

כל דבר שקיים בלכידה השנייה וחסר בראשונה זקוק לבעלים. או שהלקוח מסיר אותו ביציאה, או שאתם מסירים אותו עם אותן פקודות שיצרו אותו, וההסרה הזו שייכת להערות הפריסה ולא לזיכרון של מישהו על מה שקרה. ב-Windows הקריאות המקבילות הן Get-NetAdapter, Get-NetRoute ו-Get-DnsClientServerAddress, שאינן דורשות הגברה אבל מראות את אותן שאריות.