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

שני השערים בלתי תלויים

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

ניתוב הוא החלטה אחרת, שמתקבלת בלקוח. טבלת הניתוב של ה-VPN מחליטה אם חבילה אל 192.168.1.50 נכנסת למנהרה או יוצאת דרך ממשק ה-Wi-Fi. אם החבילה יוצאת דרך Wi-Fi ונקודת הגישה מבודדת לקוחות, היא מתה בנקודת הגישה. אם החבילה נכנסת למנהרה, נקודת הגישה לעולם אינה רואה את היעד המקורי ואינה יכולה לבודד דבר.

מה הבידוד חוסם בנקודת גישה טיפוסית

יצרנים מספקים את זה בכמה שמות: בידוד לקוחות, בידוד AP, בידוד תחנות, או רשת אורחים שמשתמעת ממנה. ב-OpenWrt האפשרות לכל ממשק היא isolate בתוך תצורת האלחוט, כמתואר ב-תיעוד האלחוט, ו-SSID לאורחים מקבל בדרך כלל גשר ואזור חומת אש משלו. התוצאה היא שמסגרות unicast בין לקוחות אינן מגושרות, ולכן ping, חיבור SMB או עבודת הדפסה לשכן נכשלים למרות ששני המכשירים מציגים אות מלא.

פרוטוקולי הגילוי נפגעים ראשונים ובאופן הבולט ביותר. mDNS למדפסות ולהתקני מדיה נוסע ב-multicast אל 224.0.0.251, SSDP משתמש ב-239.255.255.250, והאם המסגרות האלה חוצות את הגשר תלוי ביצרן ובאם המרת multicast ל-unicast מופעלת. מכשיר שחסר מרשימה הוא ראיה חלשה יותר מחיבור ישיר שנכשל לכתובת ידועה.

מה ה-VPN משנה, ומה הוא אינו יכול לשנות

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

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

גלו איזה שער סגור

התחילו בבדיקה שמוציאה את ה-VPN מהתמונה: חברו שני מכשירים רגילים לאותה SSID ונסו להגיע מאחד לשני לפי כתובת. אם זה נכשל, נקודת הגישה מבודדת ושום הגדרת VPN לא תתקן זאת. אם זה מצליח, עברו ללקוח והריצו ip route get 192.168.1.50 ב-Linux או Find-NetRoute -RemoteIPAddress 192.168.1.50 ב-Windows; הפלט מציין את הממשק שהחבילה תשתמש בו.

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

חיבור ישיר ליציאת המדפסת הוא בדיקה טובה יותר מרשימת גילוי. nc -vz 192.168.1.50 9100 ב-Linux או Test-NetConnection 192.168.1.50 -Port 9100 ב-PowerShell אומר לכם אם הכתובת נגישה בכלל, לפני שכל התאמה ברמת היישום נכנסת לדיון.

בחרו את התיקון לרשת שאתם נמצאים בה

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

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

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

אמתו את היישום, לא רק את ה-ping

ping מוצלח מוכיח את הנתיב, לא את השירות. מדפסות מקבלות לעתים קרובות 9100 גולמי או IPP ב-631 אך מסרבות לגילוי, ושיתוף קבצים צריך 445 בתוספת פתרון שמות שעובד. אשרו את היציאה שהיישום משתמש בה, ואז נסו שוב את המשימה בפועל במכשיר.

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

מאמרים קשורים