נקודת גישה Pi עם Pi-hole ו-VPN: הקצו לכל שירות משימה משלו
החליטו מי הבעלים של DHCP, DNS והעברת מנות לפני שמפעילים שלושה עוזרים על Pi אחד. בעלים כפולים יוצרים חכירות מתחרות ולולאות ברזולבר.
טלפון מתחבר לנקודת הגישה של ה-Pi, מקבל כתובת, והדף עדיין לא נטען. ה-Pi מריץ עוזר נקודת גישה, Pi-hole ולקוח VPN, וכל אחד מהם חושב שהוא הבעלים של חלק מהנתיב. רוב הבניות האלה נכשלות לא בגלל רכיב מקולקל, אלא בגלל שני רכיבים שעושים את אותה עבודה. הקצו בעלים אחד לכל פונקציה לפני שמכווננים כל אחד מהם.
הקצו בעלים אחד לכל פונקציה
ארבע פונקציות חשובות כאן, וכל אחת זקוקה בדיוק לבעלים אחד. הטבלה שלהלן מפרטת את הפונקציה, בעלים מעשי ומה משתבש כששני שירותים תובעים אותה.
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
החפיפה מגיעה בדרך כלל מנה אחת בכל פעם. עוזר נקודת הגישה מתקין מופע dnsmasq משלו, Pi-hole רוצה את פורט 53, ולקוח ה-VPN מוסיף נתיבים. כל צעד נראה סביר לבדו, וביחד הם יוצרים מכונה שבה השירות השני שעולה משנה בשקט את התנהגות הראשון.
רשמו את הבעלים לפני שמפעילים כל דבר אחר. טבלה קצרה בהערות הבנייה מונעת מהתקנה מאוחרת להשתלט על פונקציה שכבר היה לה בעלים.
בחרו טווח אחד והרחיקו אותו מהמנהרה
בחרו את טווח נקודת הגישה, את כתובת ה-Pi בתוכו, את מאגר ה-DHCP ואת הרזולבר שהלקוחות מקבלים. החזיקו את הטווח הזה בנפרד מה-LAN העליון ומטווח מנהרת ה-VPN, מפני שתת-רשתות חופפות הופכות בעיית ניתוב לפרויקט תרגום כתובות. טווח שחופף למנהרה הופך את ה-Pi לנתב מקרי בין שני קידומות זהות. כתבו את הטווח והמאגר בתצורת נקודת הגישה במקום להשאיר אותם לערך ברירת מחדל.
אם המצב המשותף של NetworkManager הוא הבעלים של נקודת הגישה, בדקו את החיבור האפקטיבי לפני שמוסיפים שרת DHCP. המצב המשותף מפעיל עוזרים משלו ומאפשר העברה, ולכן הוא כבר הבעלים של תוכנית הכתובות עבור הממשק הזה. הוספת שרת שני רק מפני שהוא זמין יוצרת הצעות מתחרות ולא יתירות.
החליטו על IPv6 במכוון. הודעות נתב ו-DHCPv6 מגיעות בהגדרות רבות מעוזר אחר מאשר DHCPv4, והשארת IPv6 דלוק כשמדיניות ה-VPN מכסה רק IPv4 נותנת ללקוחות נתיב שעוקף את המנהרה. או שתכננו את צד ה-IPv6 או השביתו אותו בממשק נקודת הגישה עם סיבה כתובה.
מי באמת עונה בפורט 53
פרטו כל תהליך שמאזין בפורט 53 לפני שינוי תצורה. ב-Pi שמריץ stub רזולבר מקומי, Pi-hole ועוזר שיתוף, רשימת המאזינים היא המפה האמינה היחידה של מי עונה לשאילתות:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routeמדריך הממשקים של Pi-hole מסביר שמצב קליטה המוגבל לממשק אחד עדיין יכול להשתמש בסוקט wildcard ולזרוק הגעות במקום אחר. זה לא אותו דבר כמו לקשור רק ממשקים נבחרים, שהוא הסידור המיועד כששירות DNS אחר צריך לחלוק את המכונה.
שני תהליכים בדרך כלל לא יכולים לקשור את אותה כתובת ופורט, אם כי SO_REUSEPORT יכול לגרום לקשירה משותפת להצליח; גם אז מאזין wildcard יכול לקחת הגעות שנועדו לשירות הצר יותר. בחרו את המצב המתועד לתפקיד הרצוי והפעילו מחדש את השירותים בסדר המיועד.
החזיקו את דף הניהול של Pi-hole מחוץ לרשת נקודת הגישה. ללקוחות דרוש רזולבר, לא ממשק האינטרנט או ה-API שיכולים לשנות את תצורת הרזולבר.
שני רגלי DNS, מדיניות אחת לכל אחת
שאילתת לקוח עוברת מהטלפון ל-Pi, ושאילתה נפרדת עוברת מה-Pi לרזולבר העליון שלו. כלל ניתוב שמתאים לתעבורת נקודת הגישה המועברת לא חל אוטומטית על הרגל השנייה, מפני שה-Pi מייצר את התעבורה הזו מקומית. אם ה-VPN אמור לשאת DNS, הנתיב המקומי צריך מדיניות משלו.
היזהרו מלולאה. הפניית הרזולבר העליון של Pi-hole לכתובת שה-Pi עצמו משרת, ישירות או דרך port-forward, מייצרת שאילתות שמסתובבות עד שפג תוקפן. תנו לו רזולבר עליון אמיתי או forwarder מותנה עבור הדומיינים שאינו יכול לענות עליהם.
החליטו מה קורה כשהמנהרה נופלת. נפילה חזרה לרזולבר המקומי משאירה גלישה חיה אבל עלולה להדליף שמות מחוץ ל-VPN; חסימה שומרת על המדיניות שלמה והופכת את התקלה לשגיאה גלויה. שתי האפשרויות מוצדקות, אבל צריך לבחור אותן ולא לרשת אותן מערך ברירת מחדל.
הוכיחו את הנתיב ואת ההתנהגות בזמן תקלה
בדקו בשכבות: הלקוח מקבל כתובת, הלקוח מפענח שם דרך ה-Pi, ה-Pi מפענח דרך הרזולבר העליון המיועד, ואפליקציה משלימה בקשה. פינג מוצלח לא אומר דבר על DNS, ופיענוח מוצלח לא אומר דבר על העברה.
dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1ואז עצרו את המנהרה וחזרו על הבדיקה. ההתנהגות המיועדת אמורה להופיע תוך שניות ספורות, ולא אחרי הפעלה מחדש ידנית של Pi-hole או של שירות נקודת הגישה. בדקו את הגדרת הרזולבר של הלקוח בזמן התקלה, מפני שרזולבר ציבורי משני ימשיך לענות גם כשהמדיניות ציפתה לכשל.
החזיקו בעלים אחד להעברה ול-NAT ואמתו אותו מלקוח, לא מה-Pi עצמו. בקשה שיוצאת מה-Pi בהצלחה עלולה עדיין להיזרק בדרך חזרה, והלקוח הוא המקום היחיד שבו כל הנתיב נראה.