Proton VPN על Pi ללא מסך: אפליקציה או קובץ WireGuard?
Pi ללא מסך הופך את שאלת אפליקציית Linux לבחירה: אפליקציה נתמכת או פרופיל WireGuard ידני. התאימו קודם את הארכיטקטורה, אחר כך את התכונות.
התקנת אפליקציית Linux נשמעת כמו הוראה אחת על Pi ללא מסך, והיא מסתירה בחירה בין שני נתיבי פריסה עם גבולות תמיכה שונים. האחד הוא האפליקציה הרשמית של הספק, שנושאת דרישות הפצה וארכיטקטורה משל עצמה. האחר הוא קובץ תצורה ידני שמשמש לקוח סטנדרטי שמערכת ההפעלה כבר אורזת. שניהם מגיעים לאותו שירות, והם אינם ניתנים להחלפה מבחינת תחזוקה.
שאלת הארכיטקטורה באה קודם, מפני שלוח 64 סיביות עשוי להריץ מרחב משתמש של 32 סיביות והאפליקציה מסופקת רק עם אחד מהם.
שני גבולות תמיכה, לא שני מתקינים
קראו את עמוד ההתקנה הנוכחי של הספק עבור האפליקציה שבה אתם מתכוונים להשתמש והשוו אותו ללוח: מהדורת ההפצה, ארכיטקטורת החבילה וכל דרישת שולחן עבודה או הפעלה. העובדה ש-Pi תומך בפעולה של 64 סיביות אינה אומרת איזה מרחב משתמש מותקן כעת, וזה הערך שמנהל החבילות בודק. dpkg --print-architecture ו uname -m עונים על כך בשורה אחת כל אחד. אם המהדורה או הארכיטקטורה מחוץ לקבוצה המתועדת, האפליקציה אינה נתמכת שם גם כשההתקנה מצליחה.
התמיכה משתנה גם לפי שיטת האריזה. מגבלה שמתועדת עבור תבנית חבילה אחת אינה חלה אוטומטית על בנייה ממאגר, והפצה שנגזרת מ-Debian אינה אוטומטית סביבה נתמכת. חבילות קהילה ומתכוני התקנה ישנים מביאים מודל תחזוקה משלהם, שאפשר לקבל במכוון אך לא ראוי לאמץ בטעות.
מה האפליקציה נותנת ומה פרופיל לא
האפליקציה הרשמית היא יותר מחיבור: היא בדרך כלל נושאת את מתג ההרג של הספק, טיפול DNS ומתגי תכונות, והספק תומך בהתנהגויות האלה כקבוצה. פרופיל ידני שנמסר ללקוח סטנדרטי אינו יורש מהן דבר. הלקוח הידני מחזיק במחזור חיי החיבור ובמדיניות הכשל המקומית, וזה בסדר כשאתם מגדירים אותם בעצמכם ומפתיע כשאתם מניחים שהם הגיעו יחד. שתי האפשרויות מגיעות לאותם שרתים; רק אחת כוללת את ההיגיון שמסביב.
אם תכונה חשובה, למשל חסימת תעבורה מחוץ למנהרה, היא חייבת להתקיים בתצורה שלכם ולא באפליקציה של הספק.
WireGuard ידנית: הצעדים שחשובים
הספק מתעד יצירת תצורת WireGuard ללקוח תואם תקן וממליץ על הנתיב הזה להתקנות ידניות, תוך שמירת OpenVPN למכשירים ישנים יותר. צרו את הפרופיל בלוח הבקרה של החשבון, הביאו אותו ל-Pi והניחו אותו במקום שרק הבעלים יכול לקרוא. לעולם אל תדביקו את הקובץ בשרשור תמיכה, מפני ששם קובץ ידידותי אינו הופך את המפתח הפרטי המוטבע לניתן לפרסום. אחר כך בדקו את המנהרה בבקשה אחת לפני שתחברו אליה משהו אחר.
הוצאה משימוש של שרתים היא פרט תפעולי שאנשים שוכחים. נקודת קצה שנבחרה ידנית עשויה להיגרע, והספק מציין שייתכן שיידרש תצורה חלופית. רשמו באיזו נקודת קצה הפרופיל משתמש כדי שכשל מאוחר יותר יהיה ניתן לאבחון.
החליטו אם ה-Pi הוא גם שער
מנהרה שמשמשת את האפליקציות של ה-Pi עצמו אינה הופכת אוטומטית לשער עבור מכשירים שיושבים מאחוריו. העברה, ניתוב חוזר, בעלות על הפותר וכל מדיניות שמונעת מתעבורה להימלט מחוץ למנהרה הם תכנון נפרד עם מצבי הכשל שלו. אם מכשירים אחרים בטווח, העריכו אותם כמקרה בפני עצמו במקום להניח שהחיבור של ה-Pi מכסה אותם. ההפרדה הזו היא שמשמרת פריסה קטנה כבת תחזוקה.
אחר כך קבלו את מחזור החיים: בקשה טרייה מה-Pi, פתרון שמות דרך הפותר המיועד ו התנהגות האתחול או ההתחברות מחדש שתכננתם. אמתו כל אחד מהם במקום להניח שהאפליקציה או הפרופיל מספקים אותו.
המיתוס שכדאי לוותר עליו הוא שמתקין Linux וקובץ WireGuard מייצגים אותה החלטה. אלה שני מודלים תפעוליים עם שני בעלים שונים.