Pi-hole ו-VPN על Pi אחד: האם מערכת ההפעלה עדיין נתמכת?

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

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

שאלו נגד איזו גרסה הפרויקט עדיין בודק, ואז רשמו את התשובה כמחרוזת גרסה ולא כ-Debian. עמוד הדרישות המוקדמות של Pi-hole מפרט מערכות הפעלה נתמכות וארכיטקטורות FTL שנבנו מראש כשני דרישות נפרדות, מגביל את התמיכה לגרסאות שההפצה עצמה עדיין מתחזקת, ומזהיר שווריאציות או תצורות לא שגרתיות עלולות להיכשל אפילו בתוך הרשימה הנתמכת. הניסוח הזה חשוב: משפחה נתמכת אינה מכסה כל חבר בה.

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

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

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

ארכיטקטורה היא הכשל השקט יותר. קרנל 64 סיביות עם מרחב משתמש של 32 סיביות הוא שילוב אמיתי ונתמך בכמה לוחות, והוא מריץ בינארי FTL של 32 סיביות בלי תלונה, עד הרגע שבו תתקינו משהו שמפורסם רק ל-arm64. הדפיסו את שני החצאים לפני שתבחרו תמונה, ושמרו את הפלט לצד ההערות.

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

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

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

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

החליטו מי מחזיק בכתובות, ברזולבר ובמנהרה לפני שהחבילה הראשונה עולה, אחרת שני שירותים יתבעו את אותה חובה ואף אחד לא ינצח נקי. תנו ל-Pi כתובת סטטית מחוץ למאגר ה-DHCP שהראוטר שלכם מחלק, והחזיקו את המנהרה בתת־הרשת שלה: 192.168.50.10 ל-Pi ו-10.42.0.0/24 למנהרה הוא פיצול ישים, והמספרים עצמם שרירותיים כל עוד הם לא מתנגשים במה שהראוטר שלכם כבר משרת. אחר כך רשמו איזה רכיב עונה בפורט 53, איזה מחלק DHCP אם אתם משתמשים בו, ואיזה מחזיק בנתיב ברירת המחדל כל עוד המנהרה למעלה. בתמונה ללא מסך, התפקיד האחרון שייך ל-NetworkManager או ל-systemd-networkd, וכן התקנת לקוח ספק שגם כותב מחדש את תצורת הרזולבר היא הדרך שבה אנשים מגיעים למנהרה חיה ו-DNS מת.

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

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

הפכו את השדרוג הבא לחלק מהבחירה

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

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

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

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

כשאף גרסה אחת לא מתאימה לשני השירותים

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

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

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