איך לבדוק אם לוויין Mesh Wi-Fi עובר דרך נתב ה-VPN
עקבו אחרי שער ברירת המחדל, מצב ההעברה של הצומת וטבלת המצבים של הנתב כדי להוכיח אם הלקוחות של לוויין Mesh עוברים דרך ה-VPN.
לוויין שעונה לאותו שם Wi-Fi כמו הנתב הבסיסי לא אומר כמעט דבר על היעד של החבילות של הלקוחות שלו. הצומת הוא רדיו וגשר עד שיוכח אחרת. מה שקובע את היציאה הוא שער ברירת המחדל שכל לקוח מקבל ומצב ההעברה של הצומת שלפניו. בצעו את חמש הבדיקות האלה מהלקוח החוצה ותקבלו תשובה שאפשר להגן עליה, לא רושם מבדיקת מהירות.
קראו את השער שהלקוח באמת קיבל
בלקוח, הדפיסו את טבלת המסלולים ואת טבלת השכנים. מסלול ברירת המחדל מציין את הכתובת שמעבירה תעבורה; רשומת השכן מציינת את כתובת ה-MAC ששייכת לכתובת הזו. השתמשו בלקוח ולא ברשימת ההתקנים של הנתב, כי רשימת התקנים מציגה שיוכים ולא נתיבים.
ip route show default
ip -6 route show default
ip neigh showWindows מדפיס את אותן עובדות בצורה אחרת: ipconfig /all נותן את שער ברירת המחדל, וכן arp -a נותן את כתובת ה-MAC. ב-macOS route -n get default וכן arp -an מכסים את אותו הדבר.
השוו את השער הזה לשני כתובות שאתם כבר מכירים: כתובת ה-LAN של הנתב הבסיסי וכתובת הניהול של הלוויין. אם השער הוא כתובת ה-LAN של הנתב, הלקוח מגושר לנתב והמדיניות של הנתב לאותה רשת חלה ללא שינוי. אם השער הוא הכתובת של הלוויין, הלוויין מנתב והנתב לעולם לא רואה את החבילות של הלקוח כתעבורת LAN; ההחלטה חייבת להתקבל בצומת, אחרת היא לא מתקבלת בכלל.
ודאו באיזה מצב הצומת באמת נמצא
מוצרי Mesh משתמשים בשלוש מילים להתנהגויות שונות, אז תסמכו על נתיב החבילה יותר מאשר על התווית באפליקציה. מצב גשר או נקודת גישה מעביר פריימים. מצב נתב מסיים תת-רשת ומריץ DHCP. מצב אורח בדרך כלל ממקם לקוחות ב-VLAN נפרד עם כללים משלו. צומת במצב נתב מאחורי נתב אחר הוא NAT כפול, והלקוחות שלו מגיעים לנתב ה-VPN כשהם כבר מתורגמים, מה שמבטל מדיניות שמבוססת על כתובת המקור.
| What you see | What it means | Next check |
|---|---|---|
| Gateway is the router's LAN address, one MAC for every node | The node bridges; the router owns the policy | Router policy for that LAN and VLAN |
| Gateway is the node's address and DHCP comes from the node | The node routes; double NAT | Node's own VPN client, or a static route plus policy on the router |
| Gateway is a different subnet on a guest SSID | Guest VLAN, often client-isolated | Whether that VLAN is inside the tunnel policy |
| Gateway changes when you walk into another room | Roaming across segments | Repeat the check per node |
כדי לקבוע את כתובת ה-MAC, קראו את התווית על הצומת והשוו אותה עם ip neigh. יצרנים מדפיסים את כתובת ה-MAC הבסיסית וגוזרים את כתובות ה-MAC של כל רדיו בהגדלה של בייט, ולכן הספרה ההקסדצימלית האחרונה שונה; השוו קידומת ולא את הכתובת כולה. אם כתובת ה-MAC של השער שייכת לממשק ה-LAN של הנתב, הצומת לא מנתב עבור הלקוח הזה.
הוכיחו את היציאה בנתב, לא בבדיקת מהירות
המצב בצד הנתב הוא המקום היחיד שמראה את התרגום. ב-OpenWrt הדפיסו את כללי המדיניות ואת טבלאות הניתוב, ואז ודאו שלמנהרה יש handshake עדכני:
ip rule show
ip route show table all | grep default
wg showב-pfSense או OPNsense אותן הראיות נמצאות בתוך pfctl -sr לכללים, pfctl -ss למצבים פעילים ובעמוד המצב של WireGuard למוני עמיתים, לפי תיעוד הלקוח של WireGuard. סננו את טבלת המצבים לפי הכתובת של הלקוח. אם המצב מראה את הלקוח מתורגם לכתובת המנהרה, התעבורה בתוך המנהרה; אם הוא מראה את כתובת ה-WAN, היא לא, ולא משנה מה התג בדשבורד אומר.
traceroute מהלקוח מוסיף עובדה שטבלת המצבים לא יכולה לתת: הקפיצה הראשונה. אם הקפיצה הראשונה היא כתובת ה-LAN של הנתב, הלקוח הגיע לנתב ישירות. אם זו הכתובת של הצומת ואחריה קפיצה פרטית נוספת, אתם על קטע מנותב, והקפיצה השנייה היא ההתקן שחייב להחזיק את המדיניות.
בדקו מה הצומת מחלק מלבד כתובת
אפשרויות DHCP נוסעות עם החכירה, ולכן צומת שמשרת DHCP משלו יכול לשרת גם DNS משלו ומודעות נתב IPv6 משלו. לכן לקוח יכול לצאת דרך המנהרה ובכל זאת לשלוח שאילתות ל-resolver שעל הצומת, או לקבל כתובת IPv6 גלובלית שהמדיניות של המנהרה אף פעם לא מכסה. הדפיסו את שניהם בלקוח:
cat /etc/resolv.conf
ip -6 addr show scope globalאם ה-resolver הוא הצומת והצומת מעביר לנתב, ה-DNS הולך אחרי המנהרה. אם הצומת פותר באופן מקומי או מצביע ל-resolver של הספק, השאילתות יוצאות מחוץ למנהרה גם כשה-HTTP לא. IPv6 ראוי לאותה בדיקה: כתובת גלובלית ועוד מסלול ברירת מחדל שעוקף את המנהרה הם דליפה, והקושחה של Mesh לעתים קרובות משאירה את IPv6 דלוק בעוד שמדיניות ה-VPN מכסה רק IPv4.
שברו את המנהרה בכוונה, ואז רשמו את התוצאה
הורידו את המנהרה והתבוננו בלקוח שמשויך לצומת הזה, לא בלקוח שליד הנתב. ping וכן curl עם פסק זמן קצר מספיקים; השאלה היא אם התעבורה נעצרת או נופלת חזרה ל-WAN. עצרו את המנהרה עם פקודת השירות של הנתב עצמו, למשל wg-quick down wg0 או עצירת שירות OpenVPN, והשאירו את הבדיקה קצרה.
אם הלקוח ממשיך לעבוד, הצומת או הנתב נכשל בפתוח עבור הקטע הזה, וה-mesh ביטל בשקט את מפסק ההרג. החזירו את המנהרה, ודאו שמונה ה-handshake זז, וחזרו על בדיקת טבלת המצבים מהשלב השלישי.
רשמו שורה אחת לכל צומת: תווית, SSID, כתובת שער, קידומת MAC, יציאה מאומתת כן או לא, IPv6 מכוסה והתנהגות כשהמנהרה למטה. נדידה היא המקום שבו התשובה משתנה, אז בדקו את החדרים שאתם באמת משתמשים בהם. כשרשומה אחת לא מתיישבת עם האחרות, הצומת הזה הוא זה שצריך לחקור, והתיקון שייך להתקן שמחזיק את השער של אותה שורה.