הפניית לקוחות OpenVPN לרזולבר Pi-hole במארח אחר

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

מה אפשרות ה-DNS הנדחפת עושה ומה היא לא עושה

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

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

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

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

נתיב החזרה מ-Pi-hole אל הבריכה

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

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

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

מצב ההאזנה של Pi-hole ללקוחות מנותבים

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

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

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

התאם את התשובה ליומן השאילתות

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

resolvectl query intranet.example.lan
resolvectl dns

התשובה הצפויה מפרטת את 192.168.50.53 כשרת ומחזירה כתובת שרק הרזולבר הזה היה מכיר. ואז הבט בתצוגה של ה-Pi-hole עצמו: pihole -t עוקב אחר יומן השאילתות בזמן אמת, וכל שורה נושאת את כתובת המקור. אם המקור הוא כתובת המנהרה של הלקוח, נתיב הבריכה שלם. אם זו כתובת ה-LAN של השער, תרגום המקור פועל וכתובתו של הלקוח עצמו לא תופיע לעולם.

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

בדוק את כלל ההעברה של השער

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

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

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

בכל כלי שהמארח משתמש בו, שמור על הבדיקה צרה: הבריכה כמקור, פורט 53 כיעד ו-Pi-hole כיעד המותר היחיד. כלל העברה רחב שמתיר גם את פורט 80 הוא בעיה אחרת שמחכה לקרות.