ฮอตสปอต 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 เพราะซับเน็ตที่ทับซ้อนกันจะเปลี่ยนปัญหาการกำหนดเส้นทางให้กลายเป็นโครงการแปลที่อยู่ เขียนช่วงและพูลลงในคอนฟิกของฮอตสปอตแทนที่จะปล่อยให้เป็นค่าเริ่มต้น
ถ้าโหมดแชร์ของ NetworkManager เป็นเจ้าของฮอตสปอต ให้ตรวจสอบการเชื่อมต่อที่ใช้งานจริงก่อนเพิ่มเซิร์ฟเวอร์ DHCP โหมดแชร์เริ่มตัวช่วยของตัวเองและเปิดการส่งต่อ จึงเป็นเจ้าของแผนที่อยู่ของอินเทอร์เฟซนั้นอยู่แล้ว การเพิ่มเซิร์ฟเวอร์ตัวที่สองเพียงเพราะมีอยู่จะสร้างข้อเสนอที่แข่งขันกัน ไม่ใช่ความซ้ำซ้อน
ตัดสินใจเรื่อง IPv6 อย่างตั้งใจ ในการตั้งค่าหลายแบบ การประกาศเราเตอร์และ DHCPv6 มาจากตัวช่วยคนละตัวกับ DHCPv4 และการเปิด IPv6 ไว้ทั้งที่นโยบาย VPN ครอบคลุมเพียง IPv4 จะให้เส้นทางที่เลี่ยงอุโมงค์แก่ไคลเอนต์ วางแผนฝั่ง IPv6 หรือปิดมันบนอินเทอร์เฟซฮอตสปอตพร้อมเหตุผลเป็นลายลักษณ์อักษร
ใครตอบบนพอร์ต 53 จริง ๆ
แสดงรายการทุกโปรเซสที่ฟังพอร์ต 53 ก่อนแก้คอนฟิก บน Pi ที่รันสตับรีโซลเวอร์ในเครื่อง Pi-hole และตัวช่วยแชร์ รายการผู้ฟังคือแผนที่เดียวที่เชื่อถือได้ว่าใครตอบคำถาม:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routeคู่มืออินเทอร์เฟซของ Pi-hole อธิบายว่าโหมดรับที่จำกัดเพียงอินเทอร์เฟซเดียวยังใช้ซ็อกเก็ตไวลด์การ์ดและทิ้งสิ่งที่มาถึงที่อื่นได้ นั่นไม่เหมือนกับการผูกเฉพาะอินเทอร์เฟซที่เลือก ซึ่งเป็นรูปแบบที่ตั้งใจไว้เมื่อบริการ DNS อื่นต้องใช้เครื่องร่วมกัน
โดยปกติสองโปรเซสผูกที่อยู่และพอร์ตเดียวกันไม่ได้ แม้ SO_REUSEPORT จะทำให้การผูกแบบแชร์สำเร็จได้ และถึงอย่างนั้นผู้ฟังแบบไวลด์การ์ดก็อาจรับสิ่งที่มุ่งไปยังบริการที่แคบกว่าได้ เลือกโหมดที่มีเอกสารกำกับสำหรับบทบาทที่ต้องการ แล้วรีสตาร์ตบริการตามลำดับที่ตั้งใจ
เก็บหน้าผู้ดูแลของ Pi-hole ไว้นอกเครือข่ายฮอตสปอต ไคลเอนต์ต้องการรีโซลเวอร์ ไม่ใช่หน้าเว็บหรือ API ที่เปลี่ยนคอนฟิกของรีโซลเวอร์ได้
สองขาของ DNS หนึ่งนโยบายต่อขา
คำถามจากไคลเอนต์เดินทางจากโทรศัพท์ไปยัง Pi และคำถามอีกชุดเดินทางจาก Pi ไปยังรีโซลเวอร์ต้นทาง กฎเส้นทางที่ตรงกับทราฟฟิกฮอตสปอตที่ส่งต่อมาไม่ถูกใช้กับขาที่สองโดยอัตโนมัติ เพราะ Pi สร้างทราฟฟิกนั้นในเครื่อง ถ้า VPN ควรพา DNS ไปด้วย เส้นทางในเครื่องต้องมีนโยบายของตัวเอง
ระวังลูป การชี้ต้นทางของ Pi-hole ไปยังที่อยู่ที่ Pi เองให้บริการ ไม่ว่าจะตรงหรือผ่านพอร์ตฟอร์เวิร์ด จะสร้างคำถามที่วนจนหมดเวลา ให้ต้นทางจริงหรือฟอร์เวิร์ดเดอร์แบบมีเงื่อนไขสำหรับโดเมนที่ตอบไม่ได้
ตัดสินใจว่าเกิดอะไรขึ้นเมื่ออุโมงค์ขาด การถอยกลับไปใช้รีโซลเวอร์ในเครื่องทำให้ยังท่องเว็บได้ แต่อาจทำให้ชื่อรั่วออกนอก VPN การบล็อกทำให้แนวนโยบายคงอยู่และเปลี่ยนความขัดข้องเป็นข้อผิดพลาดที่มองเห็นได้ ทั้งสองทางเลือกป้องกันได้ แต่ต้องเลือก ไม่ใช่สืบทอดจากค่าเริ่มต้น
พิสูจน์เส้นทางและพฤติกรรมตอนขาด
ทดสอบเป็นชั้น ไคลเอนต์ได้ที่อยู่ ไคลเอนต์แปลงชื่อผ่าน Pi Pi แปลงผ่านต้นทางที่ตั้งใจ และแอปพลิเคชันทำคำขอจนสำเร็จ ping ที่ผ่านไม่ได้พิสูจน์ 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 ได้สำเร็จอาจถูกทิ้งตอนขากลับ และไคลเอนต์เป็นที่เดียวที่เห็นเส้นทางทั้งหมด