נקודת גישה ל-VPN בגשר: באיזה נתיב ברירת מחדל משתמש הטלפון?
נתיב ברירת המחדל של ה-Pi אינו השער של הטלפון. הפרידו בין שתי ההחלטות, החזיקו את ה-uplink מחוץ לגשר, ובדקו את ה-lease לפני המנהרה.
הטלפון בנקודת הגישה המגושרת שלכם מקבל את כתובתו ואת השער שלו ממקום כלשהו, וזה אינו נתיב ברירת המחדל של ה-Pi. שינוי ברירת המחדל של ה-Pi משנה לאן ה-Pi שולח את התעבורה שלו עצמו. הטלפון ממשיך להשתמש בשער שנאמר לו, וכשהשער הזה יושב ב-LAN המרוחק, המסגרות שלו פשוט חוצות את הגשר. שני צרכנים, שתי החלטות. ההפרדה ביניהם מסבירה את רוב הדיווחים על נקודת גישה בלי אינטרנט בזמן שה-Pi עצמו תקין.
שני התקנים, שתי החלטות שער שונות
ל-Pi יש מחסנית IP משלו ונתיב ברירת מחדל משלו. לטלפון יש מחסנית IP משלו ונתיב ברירת מחדל משלו.
| Consumer | Who chooses its gateway | What carries the traffic |
|---|---|---|
| Phone on the bridged AP | The remote LAN router, delivered in its client configuration | An Ethernet frame toward that router crosses the AP and TAP bridge |
| Pi's encrypted connection | The travel uplink's route toward the VPN peer | The Pi sends its own outer transport packets over the underlay |
הטבלה הזו היא כל המודל. השער של הטלפון הוא כתובת ב-LAN המרוחק, והמסגרות שלו מועברות בשכבה 2 לעבר אותו נתב. נתיב ברירת המחדל של ה-Pi נוגע לתעבורה החיצונית של ה-Pi עצמו, שעליה להגיע לעמית ה-VPN דרך ה-uplink של הנסיעה.
גשר מעביר מסגרות, הוא לא מנתב מנות
גשר Linux מעביר מסגרות Ethernet לפי MAC היעד, וזה כל מה שהוא עושה בין הפורטים שלו. המסגרת של הטלפון הממוענת ל-MAC של הנתב המרוחק מועברת ליציאת TAP וחוצה את המנהרה בלי לגעת בטבלת הניתוב של ה-Pi. לכן נתיב ברירת מחדל פגום של ה-Pi יכול להשאיר את הטלפון עובד, ולכן נתיב נכון לא יכול לתקן טלפון שקיבל את השער הלא נכון.
TAP נושא מסגרות Ethernet ויכול להיות יציאת גשר. TUN נושא מנות IP ולא יכול. אם התכנון שלכם החליף אחד בשני, הגשר אינו גשר ושאר הדברים כאן אינם חלים.
החליטו מי מחלק את ה-lease של הטלפון
אפשרות 3 ב-DHCP היא אפשרות הנתב, והיא אומרת ללקוח באיזה שער להשתמש עבור תת-הרשת שלו. כששרת ה-DHCP של ה-LAN המרוחק הוא המחלק היחיד, הטלפון מקבל שער מרוחק והתכנון עקבי. כשמשהו אחר בצד הנסיעה עונה ראשון, הטלפון מקבל שער מקומי, תעבורת האינטרנט שלו יוצאת דרך ה-uplink של הנסיעה, ולתעבורה שלו ל-LAN המרוחק אין שום נתיב.
הריצו מחלק אחד לאותו תחום שידור, ותעדו מה הוא מחלק.
ה-Pi הוא מקרה נפרד גם כשהוא לוקח כתובת מאותו lease. החליטו במכוון אם עליו להתקין את הנתיבים שה-lease מציע, כי נתיב ברירת מחדל מרוחק מיובא יכול לגרור את תעבורת ה-VPN של ה-Pi אל תוך המנהרה שהוא מנסה להחזיק בחיים. עם systemd-networkd ההחלטה הזו היא UseRoutes= בסעיף DHCP; עם dhclient זו אפשרות routers ברשימת הבקשות.
החזיקו את ה-uplink מחוץ ל-LAN המגושר
הממשק שנושא את חיבור ה-VPN החיצוני של ה-Pi אסור שיהפוך ליציאת גשר. אם הוא הופך לכזו, התעבורה המוצפנת מועברת ל-LAN המורחב והמנהרה בסוף נושאת את המנות החיצוניות של עצמה, מה שנכשל באופן שנראה כמו אובדן מנות ולא כמו לולאה. החזיקו גם את יכולת ה-AP ואת תמיכת הגשר מפורשות. ממשק אלחוטי במצב station בדרך כלל לא יכול להיות יציאת גשר, כי בכותרת 802.11 אין מקום לכתובת ה-MAC השנייה שגשר צריך.
הגדירו את תחום השידור המורחב, תוכנית כתובות אחת, ואת סינון המסגרות שאתם באמת רוצים. אישור המאזין ל-VPN על ה-Pi לא נותן לכל לקוח מגושר גישה לשירותי הניהול של ה-Pi. אלה כללים נפרדים, והתייחסות אליהם כאחד היא הדרך שבה נקודת גישה הופכת בשקט לדלת פתוחה.
בדקו את ארבעת הדברים בנפרד כשזה נשבר
כשהטלפון לא מצליח להגיע ל-LAN המרוחק, ארבע תצפיות מפרידות בין הסיבות. הריצו אותן בסדר הזה ועצרו בראשונה שנכשלת.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpהתחילו מה-lease: האם הטלפון מחזיק כתובת ושער בתת-הרשת המרוחקת? אחר כך הסתכלו על הגשר, ואשרו שגם יציאת ה-AP וגם יציאת ה-TAP מעבירות. אחר כך קראו את טבלת השכנים, כי רשומה לא פתורה עבור הנתב המרוחק אומרת שהמסגרות יוצאות ושום דבר לא עונה. לבסוף צפו במסגרות על הגשר בזמן שהטלפון עושה ping, מה שאומר לכם אם התקלה בכלל מתחת ל-IP.
תעדו איזה התקן מחזיק בכל ברירת מחדל כשתסיימו. שורה אחת של תיעוד הופכת יציאה מקומית מול מרוחקת להחלטת לקוח מכוונת, והפניית הגשר שווה לשמור לצידה.