Pi-hole אינו חוסם פרסומות לאחר חיבור ה-VPN: חמש בדיקות

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

1. קראו את הפותר שהלקוח באמת משתמש בו

שאלו את הלקוח, לא את הנתב. ב-Linux הפקודה resolvectl status מדפיסה את שרתי ה-DNS לכל קישור ואיזה קישור מנצח; /etc/resolv.conf לבדו הוא בדרך כלל stub שמצביע ל-127.0.0.53. ב-Windows הפקודה ipconfig /all מפרטת את השרתים שסופקו על ידי DHCP לכל מתאם, וב-macOS הפקודה scutil --dns מציגה את אותו הדבר לפי היקף. אם התשובה אינה הכתובת של Pi-hole, יש לכם בעיית הקצאה ושלב 2 הוא המקום שבו היא נמצאת.

שני דברים מביסים את פותר המערכת גם כשהוא מוגדר כראוי. דפדפנים עם DNS מאובטח משלהם (האפשרות “Use secure DNS” ב-Chrome, network.trr.mode ב-Firefox) שולחים שאילתות דרך HTTPS לפותר ציבורי ולעולם לא פותחים את פורט 53. ולקוח VPN על הלקוח עצמו עשוי להתקין שרת DNS בממשק המנהרה שלו עם דומיין ניתוב ~., מה שהופך את הקישור הזה לסמכותי לכל שם.

בדקו את המסלול שהאפליקציות עוברות בו, לא את המסלול שכלי דיבוג עובר בו. resolvectl query example.com מראה איזה קישור ענה, ו-getent hosts example.com עובר באותו מסלול NSS שאפליקציה עוברת בו; ב-macOS הפקודה dscacheutil -q host -a name example.com קוראת את הפותרים לפי היקף ש-scutil --dns מפרט. dig חשוף לא עושה זאת: הוא קורא את /etc/resolv.conf ומדלג על הבחירה לפי קישור, ולכן הוא עשוי לענות מ-Pi-hole בעוד כל אפליקציה משתמשת בפותר הנדחף, וזה בדיוק הכשל שהרשימה הזאת קיימת כדי לתפוס. שמרו את dig @192.168.1.53 לבדיקת שרת ספציפי אחד.

2. אשרו מי מחלק את התשובה

ההקצאה מגיעה מכל מה שעונה ל-DHCP. ב-dnsmasq זה שורה אחת, dhcp-option=6,192.168.1.53; בממשק האינטרנט של נתב זה שדה ה-DNS בקטע ה-DHCP של ה-LAN. לקוחות חייבים לחדש לפני שהם רואים את זה. מכשיר שפועל כבר ימים עדיין מחזיק בחכירה הישנה, ומכשיר עם פותר שהוקלד ידנית מחזיק בה לנצח. חדשו בלקוח בדיקה במקום להניח שההגדרה מתפשטת.

IPv6 הוא החצי שמפספסים. הודעות הנתב עשויות לשאת שרת DNS משלהן (RDNSS), וב-OpenWrt זו האפשרות ra_dns של odhcpd; לקוח שמעדיף IPv6 משתמש בשרת הזה בעוד האפשרות DHCPv4 שזה עתה הגדרתם נשארת ללא שימוש. אם אינכם מוכנים לשרת DNS ב-IPv6, נקו רק את הודעת ה-DNS: ra_dns ב-odhcpd, או האפשרות RDNSS בכל מה שעונה להודעות הנתב. כיבוי ההודעה כולה מסיר גם את כתובות ה-IPv6 מה-LAN, וזה שינוי גדול בהרבה מזה שהתכוונתם לעשות, בעוד ניקוי רק של אפשרות ה-DNS משאיר את הכתובות שלמות והופך את ה-RDNSS החסר לגלוי בלכידת חבילות.

3. הוכיחו שהשאילתה מגיעה ל-Pi-hole

שאילתה מה-Pi אינה מוכיחה דבר על מסלול הרשת. הריצו אותה מהלקוח וקראו את קוד התגובה:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

פסק זמן מצביע על סינון או על נתיב; REFUSED מצביע על כלל גישה; SERVFAIL מצביע על הפותר במעלה הזרם שמאחורי Pi-hole; תשובה נכונה שלעולם אינה מופיעה ביומן השאילתות פירושה שהלקוח שאל משהו אחר. בדקו UDP ו-TCP 53, כי תשובות גדולות וחלק מהפותרים נופלים חזרה ל-TCP, ופרסמו את שניהם כאשר Pi-hole פועל במכולה. מיפוי שמכסה רק UDP יוצר כשלים לסירוגין שנראים כמו אובדן חבילות.

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

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

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

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

בחרו תיקון אחד ולא את שניהם. או הרחיקו את המנהרה מה-DNS — עם pull-filter ignore “dhcp-option DNS” ב-OpenVPN ובלי תחילית LAN ב-AllowedIPs ב-WireGuard —, או קבלו את הפותר הנדחף ווותרו על סינון מקומי ללקוחות שמאחורי הנתב הזה. בכל בחירה שתבחרו, כתבו אותה לצד הפרופיל, כי האדם הבא שיערוך אותו יהפוך אחרת את ההחלטה בטעות.

5. חזרו על הבדיקה לאחר התחברות מחדש

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

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