hostapd ו-OpenVPN על Pi אחד: למי שייך הנתיב הראשי?

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

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

הפריסה המוכרת מניחה את הרדיו האלחוטי ואת היציאה הקווית בתוך br0, מפעילה את hostapd כנגד הגשר ומחלקת חכירות מ-dnsmasq, בעוד לקוח OpenVPN יוצר את tun0. אז שלוש דרישות נפרדות נראות כמו אחת: לקוחות נקודת הגישה זקוקים ל-Pi כשער שלהם, ה-Pi זקוק לנתיב לאינטרנט כדי להגיע לשרת שלו, והגשר זקוק לכתובת שער שאותם לקוחות יכולים להשתמש בה.

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

ip -br addr
ip route show
ip link show master br0
bridge link show

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

תנו לגשר נתיב ראשי ששייך לו

Raspberry Pi OS משאיר את הגשר לעתים קרובות בלי נתיב ראשי כאשר הגשר נוצר אחרי שנכתב קובץ הממשק. הבלוק שייך ל-/etc/dhcpcd.conf, והוא צריך לציין את הנתב העליון ולא את ה-Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

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

אחרי systemctl restart dhcpcd ip route show default אמור להציג את br0 פעם אחת ובלי כפילות מהיציאה הקווית. אשרו את החיפוש ולא את הטבלה, כי רשומה ישנה יכולה לשבת ליד רשומה מנצחת: ip -4 route get 203.0.113.10 חייב לציין את br0. הכתובת הזו מגיעה מטווח התיעוד TEST-NET-3, כך שהיא לא יכולה להתנגש בשרת אמיתי בזמן שאתם קוראים את זה.

מנעו מהמנהרה לחטוף את הנתיב לשרת שלה

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

השוואה מהירה של נתיב התעבורה הזה לפני ואחרי החיבור שווה את עשר השניות. ip -4 route get 203.0.113.10 אמור לציין את התקן השכבה התחתונה בשני המצבים, ורק המדד משתנה. אם הוא מציין את tun0 אחרי שהמנהרה עולה, נתיב המארח מעולם לא הותקן והחיבור הבא ייכשל.

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

החליטו בעניין ההעברה וה-NAT

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

כלל ה-NAT הוא הקיצור שעובד כשהשרת לא יקבל את קידומת נקודת הגישה, במחיר שכל לקוח ייראה ככתובת המנהרה של ה-Pi ביומני הצד המרוחק. ניתוב הקידומת בלי NAT שומר על הכתובות גלויות ותלוי בנתיב חזרה עבור 192.168.50.0/24 בצד הבית.

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

אמתו מלקוח, ואז חזרו לאחור בצורה נקייה

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

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

אחר כך אשרו של-Pi עדיין יש נתיב יציאה משלו: ip route get 203.0.113.10 אמור לציין את התקן השכבה התחתונה, ו-ping -c 3 -I br0 203.0.113.10 אמור לענות אם השרת מתיר ICMP. אם שני שלבי הלקוח הראשונים עוברים והשלישי נכשל, התקלה נמצאת בהעברה או ב-NAT. אם השלב השני נכשל, הגשר או DHCP עדיין לא שלמים.

חזרה לאחור היא עריכת קובץ אחת ושתי פקודות: הסירו את הבלוק, הפעילו מחדש את dhcpcd, והחליפו את הנתיב הראשי במפורש עם ip route replace default via 192.168.50.1 dev br0. עשו זאת לפני שחלון התחזוקה נסגר ולא אחריו, כי Pi שאיבד את הנתיב הראשי שלו אינו נגיש מהרשת שבה הייתם משתמשים כדי לתקן אותו.