ניתוב מדיניות ב־OpenWrt: השרשרת שתופסת DNS מקומי

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

שני זרמים, כתובת פותר אחת

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

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

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

חבילות מועברות וחבילות שנוצרות מקומית נכנסות אחרת

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

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

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

בחרו בשרשרת היציאה ואז צמצמו את ההתאמה

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

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

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

השאירו את התעבורה של המנהרה עצמה מחוץ לכלל

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

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

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

בדקו את שתי האוכלוסיות, לא אחת

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

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

בדקו גם את הפורט: כלל שמתאים לפורט יעד 53 מפספס פותר שמגיעים אליו דרך DNS over TLS בפורט 853 או דרך נקודת קצה HTTPS. התאימו את התעבורה שה־upstream המוגדר באמת משתמש בה, והדליפה נסגרת מהסיבה הנכונה.