tun שנוצר מראש ב-OpenVPN: השוואת שני מודלי הבעלות

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

שם אינו התחברות

dev tun1 מבקש מ-OpenVPN את הממשק הנקוב הזה, ובניות מסורתיות במרחב המשתמש ינסו לפתוח אותו. אם השם אינו עוקב אחר התבנית הרגילה tun או tap, הפרופיל זקוק גם ל-dev-type מתאים, משום שהסוג אינו נגזר לעולם ממחרוזת. התקן TAP אינו התקן TUN עם תווית אחרת: חיבור ההתקן הלא נכון או נכשל מיד, או יוצר קישור שנושא פריימים שאיש אינו מצפה להם. בדקו את הסוג לפני כל דבר אחר, כי כל בדיקה מאוחרת יותר מניחה ששני הצדדים מסכימים עליו. משם, ודאו שהתהליך אכן יכול לפתוח את ההתקן, ולא רק לראות אותו.

dev tun1
dev-type tun

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

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

מי מגדיר את הקישור: שני מודלי בעלות

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

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

בדקו את ההתקן ממרחב השמות שמשנה

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

ip -details link show dev tun1
ip tuntap show

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

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

שני סוגים של התמדה

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

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

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

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

systemctl status openvpn-client@lab
ip -details link show dev tun1

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

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

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