נקודת גישה ל-Wi-Fi מאחורי שער VPN: שמרו על רשת מקומית אחת

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

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

שתי דרכים להציב את ה-VPN לפני ה-Wi-Fi

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

internet
  -> vpn-capable gateway: routing, tunnel, dns, failure policy
  -> bridged access point: radio onto the same lan
  -> wifi clients

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

מה הפריסה המגושרת באמת משנה

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

הרדיו לא יורש דבר מזה אוטומטית מהמנהרה. הוא רק מפסיק להוסיף שכבות שהיו מסוות אותה.

היכן משתלב מקטע מנותב שני

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

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

בדקו מלקוח Wi-Fi, לא מהשער

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

ip -4 addr show wlan0
ip route get 1.1.1.1
curl -sS https://api.ipify.org; echo
traceroute -n -m 4 1.1.1.1

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

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