למה ה-DNS של הנתב עצמו עוקף את מנהרת ה-VPN?

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

לאיזה זרם שייכת תפיסת החבילות באמת

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

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

הבדיקה המעשית היא לצפות בשני הצדדים בו-זמנית. בנתב, פרטו את הסוקט של הפותר, שאלו אותו מקומית ותפסו את ממשק ה-WAN:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

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

למה ניתוב המדיניות לא רואה את השאילתה השנייה

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

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

היכן הפותר של pfSense קובע את מסלול המעלה שלו

pfSense הופך את הפיצול לגלוי. ניתן לנתב תעבורת לקוחות לפי מדיניות דרך שער VPN, בעוד התעבורה של חומת האש עצמה עוקבת אחר הגדרת היציאה של הפותר ולא אחר כללי ה-LAN. בממשק האינטרנט ההגדרה הזו נמצאת תחת Services > DNS Resolver > Outgoing Network Interfaces, וערכה הוא רשימת הממשקים שהפותר רשאי להשתמש בהם לשאילתות המעלה.

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

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

בחרו את התנהגות הכשל לפני ההגדרה

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

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

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

בדקו את שני המסלולים ושמרו על תוצאות נפרדות

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

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

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

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

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