למה Pi-hole v6 מתעלם משאילתות DNS של לקוחות WireGuard

Pi-hole v6 מקבל שאילתת DNS בפורט 53 ואז מחליט אם מותר להשיב לחבילה שהגיעה. במארח WireGuard ההחלטה השנייה הזו היא בדרך כלל הסיבה לכך שלקוח מקבל פסק זמן בעוד הפותר נראה בריא מה-LAN. הפורט פתוח, FTL פועל, ובכל זאת שום דבר לא חוזר מ-10.90.0.1. שלושה דברים פועלים זה על זה לפני שהתשובה יוצאת: dns.interface, dns.listeningMode והחומת אש שלפני שניהם.

השקע המאזין לא קובע מי מקבל תשובה

FTL פותח מאזינים UDP ו-TCP בפורט 53. בתצורת ברירת המחדל השקע הוא לעתים קרובות wildcard, ולכן ss -lunp | grep :53 מציג 0.0.0.0:53 ו-[::]:53 בין אם לקוחות VPN מקבלים שירות ובין אם לאו. שקע wildcard מקבל את החבילה, ואז FTL מיישם את כללי הממשק והמקור שלו לפני שהוא משיב. לכן הביטוי "הפורט מאזין" מוכיח מעט מאוד על לקוח מנהרה.

קראו את התצורה שרצה ולא את הקובץ שלדעתכם פעיל. pihole-FTL --config dns.interface ו-pihole-FTL --config dns.listeningMode מדפיסים את הערכים האפקטיביים, והם עשויים להיות שונים מקובץ המארח כשקונטיינר, משתנה סביבה או מנהל פריסה מחזיק בהגדרה. מדריך התצורה של Pi-hole FTL מפרט את המצבים ומי מהם מבוסס על הממשק.

LOCAL שואל איזו תת-רשת, SINGLE שואל איזה ממשק

LOCAL, ברירת המחדל, משיב לשאילתות שכתובת המקור שלהן שייכת לתת-רשת שמוגדרת באחד מממשקי המארח. wg0 פשוט עם 10.90.0.1/24 עובר את המבחן הזה, מפני שהלקוח ב-10.90.0.2 נמצא בתוך תת-הרשת של המנהרה. לקוח מנותב בצד השני של עמית, או לקוח מוסתר מאחורי NAT בקידומת אחרת, לא עובר אותו למרות שהחבילה הגיעה ל-wg0, ואין שאילתה ביומן.

SINGLE משנה את השאלה. הוא מקבל שאילתות שמגיעות בממשק הנקוב ב-dns.interface, כולל loopback, ומתעלם מתת-רשת המקור. זה המצב ששורד טופולוגיית VPN משורשרת או מנותבת. הגדירו את שני המפתחות יחד, כי מצב בלי ממשק נקוב אינו הוראה שלמה:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND משנה את השקע, ולכך יש מחיר

BIND לא מסנן שקע wildcard; הוא קושר את פורט 53 רק לכתובות שקיימות בממשק הנקוב, ולכן הליבה מסרבת לחבילות שמגיעות למקום אחר. הוא מחמיר יותר מ-SINGLE ואינו שם נרדף לו. המחיר מופיע באתחול: אם wg0 אינה פעילה כשהדיית FTL מתחילה, ייתכן שאין כתובת לקשור, והפותר יכול לרוץ בלי מאזין עד שהממשק יופיע ו-FTL יופעל מחדש.

בחרו BIND כשאתם שולטים בסדר האתחול, למשל יחידת systemd שמסודרת אחרי ממשק WireGuard, וכשאתם רוצים שהליבה תשליך חבילות תועות לפני ש-FTL יראה אותן. בחרו SINGLE כשהמנהרה באה והולכת, או כשהממשק נוצר על ידי כלי שמתחיל אחרי FTL.

החומת אש היא השער השני

מצב FTL תקין עדיין נכשל אם חומת האש של המארח משליכה את פורט 53 ב-wg0. אפשרו את טווח מקורות ה-VPN לשני הפרוטוקולים והשאירו את צד האינטרנט סגור. ב-nftables, עם שרשרת input הקיימת בטבלת inet filter, הכללים נראים כך:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

הוסיפו כללי IPv6 תואמים אם המנהרה נושאת IPv6, והציבו אותם לפני מדיניות ההשלכה של השרשרת. אם המארח משתמש ב-ufw או ב-firewalld, הביעו את אותה התאמה באותו מנהל במקום לערבב כלים. אל תעבירו את פורט 53 מהנתב של האינטרנט; הלקוחות אמורים להגיע לכתובת ה-VPN של הפותר דרך המנהרה.

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

אמתו את התשובה ואת הסירוב

מלקוח VPN, שאלו את כתובת הפותר בשני הפרוטוקולים: dig @10.90.0.1 example.com ו-dig +tcp @10.90.0.1 example.com. אחר כך בדקו את יומן השאילתות בממשק הניהול כדי לאשר ש-FTL תיעד את השאילתה. פסק זמן של לקוח בלי רשומה ביומן מצביע על חומת האש או על מסנן הממשק; רשומה בלי תשובה מצביעה על פתרון ב-upstream.

בדקו את המסלול השלילי ממארח מחוץ ל-VPN. dig @10.90.0.1 example.com אמור לפקוע, ו-ss -lunp בפותר לא אמור להראות את פורט 53 קשור לכתובת ציבורית. הפעילו מחדש את השירות פעם אחת, אחר כך הפעילו מחדש את המארח ואשרו שהפותר עדיין משיב כש-wg0 מופיע שוב. שאילתה שעובדת רק עד האתחול הבא אינה שינוי גמור.