איך להעביר שרת VPN של Raspberry Pi ל-Ethernet

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

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

ארבע הגדרות קובעות אם המעבר ישרוד: הכתובת של ה-Pi, כתובת הכריכה של OpenVPN, יעד ההפנייה של הנתב והנתיב שהתשובות עוברות בו. רשמו את כל הארבעה לפני שתיגעו בכבל, כי ברגע שחכירת ה-Wi-Fi נעלמת לא תוכלו לקרוא את הערכים הישנים מהמכונה. ממשק הכבל לא יורש את פרופיל ה-Wi-Fi, וב-Bookworm הכתובת גרה ב-NetworkManager ואילו Bullseye שומר אותה ב-dhcpcd.conf. הזמנה שנעצה את כתובת ה-MAC האלחוטית לא אומרת דבר על eth0. התייחסו לכתובת החדשה כהקצאה חדשה שזקוקה להוכחה משלה.

Old wireless lease:   10.42.7.24/24 on wlan0
New wired address:    10.42.7.31/24 on eth0
Client endpoint:      vpn.lab.example:1194/udp

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

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

קראו את הסוקט בפועל לפני שתסמכו על הכתובת החדשה

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

sudo systemctl cat openvpn-server@server | grep -n -- '--local'
sudo ss -lunp '( sport = :1194 )'

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

בצעו את המעבר בסדר שמשאיר אתכם נגישים

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

ip -br addr show eth0
ip route get 203.0.113.10
nmcli -g ipv4.method,ipv4.addresses con show "Wired connection 1"

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

כששני הקישורים פעילים, ה-Pi עשוי להעדיף את נתיב ברירת המחדל האלחוטי כי הוא הותקן ראשון או כי לקישור הכבלי יש מדד גבוה יותר. ב-Bookworm ההגדרה הנתמכת היא ipv4.route-metric על החיבור, וב-Bullseye המקבילה היא שורת metric ספציפית לממשק ב-dhcpcd.conf. הנמיכו את העדפת הקישור האלחוטי במקום להשבית אותו, כדי שנתיב החזרה יישאר במרחק פקודה אחת.

הוכיחו את המנהרה מבחוץ, לא מה-LAN

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

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

sudo journalctl -u openvpn-server@server -n 40 --no-pager
sudo tcpdump -ni any udp port 1194 -c 20

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

שמרו על חזרה בשלב אחד והוציאו את פרופיל ה-Wi-Fi משירות

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

הוצאת התלות האלחוטית משירות היא שינוי מאפיין ולא מחיקה. הגדרת connection.autoconnect no משאירה את פרטי ההתחברות ואת היסטוריית הכתובות שלמים ובמקביל מונעת מה-Pi להתחבר מחדש לרשת שממנה עברתם.

nmcli con show
sudo nmcli con up "Wired connection 1"
sudo nmcli con mod "previously-used-wifi" connection.autoconnect no

לפני שאתם מכריזים שהעבודה הסתיימה, אשרו ארבעה דברים: יעד ההפנייה תואם לכתובת הכבלית, המאזין שרד אתחול, לקוח מבחוץ משלים לחיצת ידיים, וה-Pi עדיין עונה בכתובת הכבלית לאחר אתחול. אתחול הוא הדרך הזולה ביותר לתפוס הקצאה שהתקיימה רק בגרעין שרץ. אם אחד מהארבעה נכשל, העלו מחדש את פרופיל ה-Wi-Fi עם sudo nmcli con up והשוו את הערכים שתיעדתם לאלה החיים.