ה־VPN שלכם עובד רק אחרי התחברות בגלל מחזיק המפתחות

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

למה ההתחברות גורמת לזה לעבוד

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

הריצו את אותו פרופיל לפני ואחרי ההתחברות ותקבלו שתי תוצאות שונות מאותו תצורה. זהו החתימה של תלות בהרשאות, לא של מנהרה שבורה, והיא מסבירה למה בדיקה ידנית במסוף מוכיחה פחות ממה שנדמה. המנהרה בסדר; הדבר שפותח את הסוד שלה חסר.

החליטו איזה בעלים מפעיל את המנהרה

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

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

אל תריצו את שני הבעלים מול תצורה אחת. אם NetworkManager מנהל את הממשק ויחידה גם מעלה אותו, הם יריבו על מסלולים ו־DNS, והמצב שיתקבל תלוי במי סיים אחרון.

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

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

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

בדקו את האירוע שבאמת קורה

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

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

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

בדקו מסלולים ו־DNS, לא רק את הממשק

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

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

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