תנו ל-VPN הביתי שלכם רשומות DNS משלו עבור nas.home.arpa
פרסמו שם אחד מ-dnsmasq, נתבו את הפותר דרך WireGuard, ואז בחרו בין דחיפת DNS לכל הלקוח לבין split-DNS רק עבור home.arpa.
אחרי שהמנהרה למעלה, הצעד האחרון הוא בדרך כלל שם שעובד במקום כתובת שמדביקים לסימנייה. רשומת מארח ב-dnsmasq יחד עם כתובת פותר שהלקוח יכול להגיע אליה עושות זאת בשני קבצים ובלי multicast. ההחלטה שבאמת דורשת מחשבה צרה יותר: האם הלקוח שולח את כל ה-DNS דרך הפותר הביתי, או רק את השמות תחת home.arpa? כל מה שלמטה מניח התקנת WireGuard מאושרת עם לקוח Linux ופותר מעבדה שמנהל הבית כבר מתפעל.
שלוש דרכים לתת ללקוח פותר
| Approach | Scope | Cost |
|---|---|---|
DNS = in the wg-quick interface | the client's general DNS while the tunnel is up | every name in the house now depends on the tunnel |
Platform split-DNS for home.arpa | only that suffix | more configuration per client platform |
Manual dig @resolver | one query at a time | fine for testing, useless for applications |
עבור מחשב נייד שמצטרף למנהרה מדי פעם, split-DNS הוא ברירת המחדל הטובה יותר: הוא משאיר שמות אינטרנט רגילים אצל הפותר שהמכונה כבר סומכת עליו. עבור מכונה שקיימת כדי להגיע לשירותי הבית, דחיפת הפותר פשוטה יותר ועלות ההיקף לא משנה.
פרסמו את הרשומה בפותר שמחזיק באזור
הפרידו בין התפקידים לפני שכותבים תצורה: כתובת לקוח ה-VPN, הפותר והשירות הם שלושה מארחים שונים עם שלוש עבודות שונות. במעבדה הזו הם 10.77.0.2 ללקוח, 192.168.50.53 ל-dnsmasq ו-192.168.50.20 ל-NAS, כשהמנהרה מנתבת את ה-LAN הביתי.
listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20השורה host-record מספקת את הכתובת והשורה local= משאירה שאלות home.arpa לא מוכרות בתוך הפותר הזה במקום להעביר אותן למעלה. קראו קודם את התצורה הקיימת שלכם ויישרו כל מה שכבר מגדיר שרת, ממשק או אותו דומיין מקומי; ערימת מקטע על גבי מקטע סותר מייצרת פותר שנטען בשמחה ועונה לא נכון. המדריך של dnsmasq מגדיר את שתי ההוראות ואת בקרות ההאזנה.
ואז בדקו את השירות שרץ, לא את הקובץ. בדיקת תצורה בתוספת הפעלה מחדש היא המינימום, והתשובה האפקטיבית היא מה ששאילתה מחזירה.
נתבו את הפותר, לא רק את דף האינטרנט
AllowedIPs של WireGuard קובע אילו יעדים נכנסים למנהרה. אם כתובת הפותר נופלת מחוצה לו, השאילתה יוצאת במסלול הרגיל ולעולם לא מגיעה ל-dnsmasq, למרות שה-NAS עצמו נגיש. כללו את כתובת הפותר, או את קידומת ה-LAN שמכילה אותה, ובדקו את מדיניות ההעברה של השער בצד השני.
אפשרו UDP ו-TCP בפורט 53 מטווח המנהרה המורשה, עם מסלול חזרה לכתובת המנהרה של הלקוח. אל תעבירו את פורט 53 מה-WAN כדי להקל על הבדיקות: פותר רקורסיבי פתוח בחיבור ביתי נמצא בתוך שעות. כריכה לממשק אינה מדיניות גישה כשלעצמה.
בדקו את התשובה לפני היישום
שאלו קודם את הפותר ישירות, אחר כך את המערכת, אחר כך את היישום. כל צעד מבודד חוליה אחת בשרשרת, וההבדל ביניהם הוא האבחון.
dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'כדאי להריץ את שאילתת ה-TCP כי תשובת UDP קטועה כופה ניסיון חוזר, ומדיניות שזורקת TCP 53 מייצרת כשלים שנראים לסירוגין. הצעד getent מראה מה תצורת הפותר של המכונה באמת עושה, וזה לא תמיד מה שדחפתם.
החליטו מה קורה כשהמנהרה למטה
אם ה-DNS הכללי של הלקוח מצביע ל-192.168.50.53, כל פתרון שמות מפסיק לעבוד כשהמנהרה לא למעלה. זה מקובל במכונה שמועילה רק עם המנהרה, ובלתי מקובל במחשב נייד שמשתמש גם ב-Wi-Fi של בית קפה. split-DNS עוקף את השאלה לגמרי, כי רק חיפושי home.arpa תלויים בפותר הביתי.
זכרו מה השם: home.arpa שמור לרשתות מגורים ואינו ייחודי עולמית, כך שרשת אחרת יכולה להשתמש באותו שם באופן לגיטימי. זהו נוחות מקומית, לא מזהה מהימן. שמרו על הרשומה מעודכנת כשהשירות עובר, והסירו את מדיניות הפותר כשהמעבדה מוצאת משירות במקום להשאיר מחשב נייד שמצביע לכתובת שהוא יכול להגיע אליה רק דרך מנהרה שכבר לא קיימת.