מסנן DNS ב-VPN: חסימת שמות אינה חוסמת פרסומות

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

מה מסנן שמות באמת שולט בו

האפשרות address=/metrics.example/, בלי דבר אחרי הלוכסן האחרון, גורמת לפותר להחזיר NXDOMAIN עבור השם הזה ותת-הדומיינים שלו. השארת הכתובת ריקה היא החלק החשוב: היא מונעת שליחת לקוחות לשרת החלפה לא קשור או הצגת כתובת loopback כיעד האמיתי. המדריך של dnsmasq מתאר צורה זו כתשובה שלילית ולא כהפניה.

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

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

במה שונה חוסם בצד הלקוח

תוסף דפדפן רואה את הבקשה לפני שהיא יוצאת, ולכן הוא יכול להתאים נתיב URL, לבטל בקשה מסוימת ולהסתיר את הרכיב שהיה מציג את התוצאה. הוא יכול לאפשר example.com/article ובמקביל לסרב ל-example.com/ads/, מה שאף תשובת DNS אינה יכולה לבטא. תצוגה זו ברמת הנתיב היא היכולת שלפותר פשוט אין. זו גם הסיבה שרשימת סינון שנבנתה לכלי אחד מתנהגת לעתים רחוקות באותו אופן בכלי האחר.

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

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

נתיב הפותר הוא שקובע אם משהו מזה חל

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

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

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

בדקו את שני הכיוונים לפני הצהרת תוצאה

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

$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53

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

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