VPN ของคุณเข้ารหัส DNS หรือแค่ฮอปถัดไป?

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

จดไว้ว่าใครได้รับคำถามในแต่ละขั้นก่อนแตะไฟล์กำหนดค่า

การตั้งค่าสองแบบดูเหมือนกันบนหน้าตั้งค่า

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

ความแตกต่างวัดได้ ไม่ใช่ปรัชญา มองหา TLS session ที่ไคลเอนต์หรือที่เซิร์ฟเวอร์ แล้วคุณจะรู้ว่าจริง ๆ แล้วคุณมีการตั้งค่าแบบไหน

ทำแผนที่ห่วงโซ่ตัวแปลงชื่อก่อนแก้ไข

นับตัวแปลงชื่อบนเส้นทางและระบุบทบาทของแต่ละตัว องค์ประกอบส่งต่อส่งคำขอไปยังตัวแปลงชื่ออื่น ขณะที่ตัวแปลงชื่อแบบเรียกซ้ำทำงานค้นหาคำตอบและอาจพูดคุยกับเซิร์ฟเวอร์ที่มีอำนาจโดยตรง บทบาทเหล่านี้ถูกนิยามแยกจากกันด้วยเหตุผลนี้เอง และนิยามตัวแปลงชื่อใน RFC 9076คุ้มค่าที่จะอ่านก่อนสันนิษฐานว่ามีปลายทางต้นน้ำเพียงแห่งเดียว โฮสต์ที่รันตัวแปลงชื่อแบบเรียกซ้ำของตัวเองไม่มี "ต้นน้ำ" เดียวให้เข้ารหัส ซึ่งทำให้แผนทั้งหมดใช้ไม่ได้

จากนั้นถามว่าไคลเอนต์ถูกกำหนดค่าให้ใช้องค์ประกอบใด ที่อยู่ DNS ที่โปรไฟล์ VPN ส่งมา บอกว่าคำถามไปที่ไหน ไม่ได้บอกว่ากระบวนการใดตอบ

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

ตรวจสอบว่าฮอปใดถูกเข้ารหัส

เริ่มที่ไคลเอนต์และยืนยันว่ามี TLS session ไปยังพอร์ต 853 หรือไม่ คำถามที่แก้ได้อย่างถูกต้องผ่านพอร์ต 53 ไม่ได้พิสูจน์อะไรเกี่ยวกับการเข้ารหัส

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

จากนั้นไปที่โฮสต์ VPN และมองหาการเชื่อมต่อขาออกที่เข้ารหัสซึ่งตัวส่งต่อเปิดไว้ ตารางซ็อกเก็ตบอกว่ามี TLS session ต้นน้ำอยู่หรือไม่ และกระบวนการใดเป็นเจ้าของ:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

ถ้าไคลเอนต์แสดง TLS session แต่เซิร์ฟเวอร์ไม่แสดง แสดงว่าคุณอยู่ในการตั้งค่าแบบแรก และเซิร์ฟเวอร์อ่านคำถามที่ส่งต่อในชั้น IP ไม่ได้ ถ้าเซิร์ฟเวอร์แสดง TLS session และไคลเอนต์แสดงทราฟฟิกพอร์ต 53 ปกติภายในอุโมงค์ คุณอยู่ในการตั้งค่าแบบที่สอง: ฮอปถัดไปได้รับการปกป้อง และตัวส่งต่อยังคงอ่านทุกชื่อที่อุปกรณ์ร้องขอ ผลลัพธ์ที่สองนั้นไม่ใช่ความล้มเหลว แต่การเรียกมันว่าการเข้ารหัสตั้งแต่ต้นจนจบนั้นผิด

บันทึกเจ้าของและพฤติกรรมเมื่อล้มเหลว

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

ก่อนเปิดใช้งานอะไร ตรวจสอบการตั้งชื่อภายใน การส่งชื่อขององค์กรไปยังตัวแปลงชื่อสาธารณะไม่ใช่การออกแบบที่เทียบเท่า และโซน split-horizon ที่มีอยู่เฉพาะในเครือข่ายจะไม่ถูกแปลงที่ต้นน้ำเลย ทดสอบชื่อภายในหนึ่งชื่อและชื่อสาธารณะหนึ่งชื่อหลังการเปลี่ยนแปลง และเก็บผลลัพธ์ไว้กับการแก้ไขกำหนดค่า หากเส้นทางที่เข้ารหัสทำให้การแปลงชื่อสำหรับโฮสต์ภายในเสียหาย วิธีแก้คือกฎตัวแปลงชื่อที่มีขอบเขตจำกัด ไม่ใช่อุโมงค์ที่กว้างขึ้น

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