מה באמת קורה כשמפעילים VPN בלינוקס

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

ממשק מופיע לפני שדבר עובד

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

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

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

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

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

ip -br addr show
ip route show
ip -6 route show

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

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

הפותר מחליף ידיים

DNS הוא השינוי השלישי וזה שסביר ביותר שמנוהל במקום שלא הסתכלתם בו. בשולחן עבודה, NetworkManager יכול לדחוף הגדרות פותר לכל חיבור. במערכת שמשתמשת ב-systemd-resolved, ההגדרות מוחלות לכל קישור ו-/etc/resolv.conf עשוי להיות stub או קישור סמלי ולא קובץ שכדאי לערוך.

resolvectl status
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

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

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

מנהל אחד לכל חיבור

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

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

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

מה לבדוק כשהוא למעלה אבל לא עובד

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

nmcli connection show --active
nmcli device status
wg show

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

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