לקוחות LAN מתעלמים מה-VPN של הנתב עד שמופעל ניתוב לפי מדיניות

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

כלל סינון לא יכול לבחור ממשק

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

הדוגמה שלהלן משתמשת ברשת LAN של 192.168.8.0/24 על br-lan, בהתקן מנהרה tun0 ובממיר אחד בכתובת 192.168.8.23 שאמור לעבור במנהרה.

קרא את החיפוש לפני עריכת כללים

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

ip -4 route get 198.51.100.7 from 192.168.8.23

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

חבר טבלה ללקוחות שאתה רוצה לכסות

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

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

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

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

השאר יעדים מקומיים מחוץ למנהרה

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

ip -4 route add throw 192.168.8.0/24 table 200

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

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