DNS สำรองของ VPN คุณ: คำถามไปถึงไหนกันแน่

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

เส้นทางสำรองคือนโยบาย ไม่ใช่พฤติกรรมเดียว

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

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

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

ใครได้รับคำถามหลังการสลับ

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

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

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

ตรวจสอบเส้นทางและผู้รับไปพร้อมกัน

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

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

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

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

ตัดสินใจว่าควรอนุญาตเส้นทางสำรองหรือไม่

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

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

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