ה-Wi-Fi לאורחים ממשיך להשתמש במסלול הראשי: תנו לו יציאה משלו

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

התסמין: האורחים עדיין יוצאים דרך ה-WAN

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

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

שלב 1: מקטע אמיתי, לא רק שם

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

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

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

שלב 2: בחרו את המנהרה לפי מקור

טבלאות ניתוב נבחרות לפי יעד, כך שכלל שאומר «שלח 0.0.0.0/0 למנהרה» חל על כולם. ניתוב לפי מדיניות מוסיף ממד שני: בחירת הטבלה לפי כתובת המקור. בנתב מבוסס Linux זהו כלל נוסף ועוד טבלה ייעודית, והסדר חשוב כי הכלל הראשון שמתאים מנצח:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

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

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

שלב 3: נתיב התשובה והתרגום

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

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

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

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

בדקו בידוד, לא רק גלישה

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

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

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

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