DNS ส่วนตัวของ Pritunl ล้มเหลว? เพิ่มเส้นทาง resolver แบบแคบ

ชื่อส่วนตัวจะถูกแก้ไขสำหรับทุกคนบนเครือข่ายองค์กรและหมดเวลาสำหรับทุกคนบน VPN resolver ตอบเกตเวย์ เส้นทางไปยังที่นั่นมีอยู่ และคำค้นก็ยังไม่เคยได้รับคำตอบ สิ่งที่ขาดหายไม่ใช่ resolver สาธารณะอีกรายหรือเส้นทางที่กว้างขึ้น แต่เป็นที่อยู่ต้นทางที่เซิร์ฟเวอร์ DNS ส่วนตัวยินดีตอบ

ยืนยันว่า resolver ปฏิเสธพูลไคลเอนต์ของคุณ

เริ่มด้วยการพิสูจน์ว่าความล้มเหลวเกี่ยวกับต้นทาง ไม่ใช่การเข้าถึง จากไคลเอนต์ที่เชื่อมต่ออยู่ ให้สอบถาม resolver ส่วนตัวโดยตรงและสังเกตว่าคำขอหมดเวลาหรือกลับมาเป็นคำปฏิเสธ dig @10.40.0.53 intranet.example.net +time=2 +tries=1 ที่หมดเวลาในขณะที่คำค้นเดียวกันจากเกตเวย์สำเร็จ ชี้ไปที่นโยบายการเข้าถึงบน resolver คำตอบ SERVFAIL ชี้ไปที่อื่นโดยสิ้นเชิง โดยปกติคือโซนหรือฟอร์เวิร์ดเดอร์ต้นน้ำ

บันทึกที่อยู่ของไคลเอนต์ก่อนทดสอบ ip -4 addr show tun0 บนไคลเอนต์ หรือลีสที่แสดงในคอนโซล บอกคุณว่า resolver มองเห็นพูลใด

จากนั้นยืนยันว่าเส้นทางมีอยู่จริง เส้นทางที่ส่งที่อยู่ resolver เข้าไปในอุโมงค์เป็นข้อกำหนดเบื้องต้น ไม่ใช่การแก้ไข หากแพ็กเก็ตไม่เคยมาถึง นโยบายต้นทางก็ไม่ถูกพิจารณาเลย ตรวจสอบด้วย ip route get 10.40.0.53 บนไคลเอนต์

เพิ่มเส้นทางโฮสต์หนึ่งเส้นแทนการแปลทุกอย่าง

แนวทาง DNS ส่วนตัวของ Pritunl อธิบายวิธีแก้แบบแคบ: เส้นทาง /32 ที่เปิด NAT สำหรับที่อยู่ resolver โดยเลือกที่อยู่นั้นเป็นเซิร์ฟเวอร์ DNS ของไคลเอนต์ เส้นทางเปลี่ยนต้นทางที่ resolver มองเห็นเฉพาะทราฟฟิก DNS ทราฟฟิกแอปพลิเคชันยังคงการออกแบบที่รักษาต้นทางซึ่งคุณเลือกไว้

กำหนดค่าผ่านเจ้าของเส้นทางที่เซิร์ฟเวอร์รองรับ หลังจากตรวจสอบเส้นทางที่มีอยู่เพื่อหาการทับซ้อน ในตัวอย่างข้างต้นปลายทางคือ 10.40.0.53/32 ที่เปิด NAT และพูลไคลเอนต์ยังคงเป็น 10.90.0.0/24 อย่าแปลช่วงส่วนตัวทั้งหมดเพื่อแก้บริการเดียว เพราะทุกนโยบายปลายน้ำที่พึ่งพาที่อยู่จริงของไคลเอนต์จะเริ่มเห็นเกตเวย์แทน ยืนยันที่อยู่ที่ resolver ได้รับจริงโดยดูบันทึกคำค้นระหว่างการค้นหาทดสอบ เส้นทางโฮสต์เพียงอย่างเดียวไม่ได้พิสูจน์อะไรเกี่ยวกับการแปลหรือการอนุญาต

resolver ยังต้องอนุญาตต้นทางที่แปลแล้วบน UDP และ TCP และคำตอบต้องกลับมาได้ การเปลี่ยนต้นทางไม่สามารถสร้างโซนหรือเรกคอร์ดที่หายไปได้

ตัดสินใจว่าเซิร์ฟเวอร์หรือไคลเอนต์เป็นผู้ส่งคำค้น

Pritunl ยังบันทึกการจัดวาง DNS พร็อกซี่ที่ผูกกับ VPN Client DNS Mapping ซึ่งเซิร์ฟเวอร์ส่งต่อคำค้นต้นน้ำแทนไคลเอนต์ ในแบบจำลองนั้นต้นทางต้นน้ำเป็นของบริบทเครือข่ายของเซิร์ฟเวอร์เอง และข้อยกเว้นฝั่งไคลเอนต์เป็นการแก้ไขที่ผิด

ระบุว่าแบบจำลองใดทำงานอยู่ก่อนเพิ่มสิ่งใด การซ่อมแซมที่ทับซ้อนกันสามอย่าง พร็อกซี่ การเขียนทับ resolver บนไคลเอนต์ และสคริปต์ NAT ด้วยมือ มักหมายความว่าไม่มีใครกำหนดได้ว่าองค์ประกอบใดควรเป็นผู้ส่งคำค้น ตรวจสอบ bootstrap ด้วย: resolver แบบส่วนตัวเท่านั้นไม่สามารถเป็นวิธีเดียวในการหาปลายทางก่อนที่อุโมงค์จะมีอยู่ และการแก้ไข resolver แบบถาวรไม่ควรมีอายุยืนกว่าการเชื่อมต่อ

ทดสอบการค้นหาส่วนตัว ไม่ใช่หน้าเว็บสาธารณะ

หลังจากใช้การเปลี่ยนแปลงและเชื่อมต่อใหม่ ให้ตรวจสอบการกำหนดค่า resolver ที่มีผลของไคลเอนต์ จากนั้นแก้ชื่อที่คุณรู้ว่ามีอยู่เฉพาะในโซนส่วนตัว dig intranet.example.net โดยไม่ระบุเซิร์ฟเวอร์ชัดเจนจะแสดงว่าไคลเอนต์ใช้สิ่งใดจริง ๆ ตามด้วยคำขอไปยังที่อยู่ที่การค้นหานั้นส่งคืน เพราะการแก้ชื่อและการเข้าถึงบริการเป็นขั้นตอนแยกกัน เบราว์เซอร์ที่โหลดไซต์สาธารณะผ่าน DNS-over-HTTPS ไม่ได้พิสูจน์อะไรเกี่ยวกับเส้นทาง resolver ส่วนตัวของระบบปฏิบัติการ resolver ทุติยภูมิสาธารณะก็ไม่ใช่ผู้มีอำนาจสำหรับโซนภายในเช่นกัน

บันทึกที่อยู่ resolver เส้นทาง /32 และการตั้งค่า DNS ของไคลเอนต์ไว้ด้วยกันในบันทึกของเซิร์ฟเวอร์ การกู้คืนการกำหนดค่าเพียงครึ่งเดียวจะทำให้เกิดความล้มเหลวเดิมซ้ำ

สุดท้าย ยืนยันว่าอุโมงค์ยังคงเส้นทางไปยังปลายทางของแอปพลิเคชันหลังจาก DNS สำเร็จ เส้นทาง การเข้าถึงบริการ และการรับรองความถูกต้องยังคงเป็นอิสระจากการแก้ชื่อ และการค้นหาที่ใช้งานได้ไม่ได้บอกอะไรเกี่ยวกับทรูพุต หากหน้าส่วนตัวช้าแต่แก้ชื่อได้ resolver ก็ทำหน้าที่ของมันแล้ว และปัญหาก็ย้ายไปที่เส้นทาง