Pi כלקוח VPN: מנהל אחד או סקריפט מותאם?

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

שני בעלים למנהרה אחת

עיצוב A הוא פרופיל בתוך מנהל הרשת של המערכת: פרופיל OpenVPN מיובא או חיבור WireGuard מקורי, שמופעל באתחול על ידי אותה שירות שמעלה Ethernet ו-Wi-Fi. עיצוב B הוא יחידה משלך שמריצה את הלקוח ישירות, עורכת את תצורת הפותר ומתקינה נתיבים וכללי חומת אש משל עצמה. שניהם עיצובים לגיטימיים; הם נבדלים במי רשאי לשנות את טבלת הניתוב.

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

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

מה ייבוא יוצר, ומה הוא לא יוצר

ב-Raspberry Pi OS Bookworm ואילך כלי תצורת הרשת המוגדר כברירת מחדל הוא NetworkManager, ולכן פרופיל הוא הבית הטבעי למנהרת לקוח. הייבוא דורש את התוסף המתאים מותקן; בלעדיו הייבוא נכשל עם הודעה על סוג חיבור לא נתמך, וזה האות הכנה לעצור ולהתקין את התוסף.

nmcli connection import type openvpn file ./provider.ovpn
nmcli connection show
nmcli --ask connection up id provider-name

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

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

מנהרה מלאה, בהשוואה בין שני העיצובים

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

ip -4 route get 198.51.100.23
ip -6 route show default
resolvectl query example.org

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

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

כשל פתוח מול כשל סגור

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

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

sudo nft add table inet vpnkill
sudo nft 'add chain inet vpnkill out { type filter hook output priority 0; policy accept; }'
sudo nft add rule inet vpnkill out oifname != "tun0" ip daddr != 203.0.113.24 reject

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

בחירה ל-Pi בלי מסך

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

מעבר ביניהם הוא בעיקר עניין של סדר: השביתו את הבעלים הישן, ודאו שלא שרד שום נתיב או רשומת פותר מיושנים, ואז הפעילו את החדש והפעילו מחדש פעמיים. הפעלה מחדש אחת יכולה להסתיר מירוץ שהשנייה חושפת. סיימו בבדיקת ה-Pi ולא המנהרה: פתרו שם, הורידו משהו דרך IPv4, הורידו דרך IPv6 אם שמרתם עליו, ואז הפילו את המנהרה וודאו שההתנהגות שבחרתם באמת קורית. ממשק ב-ip link הוא תחילת הבדיקה, לא סופה.