อนุญาตให้ DNS ผ่านตัวแก้ชื่อ VPN ของคุณเท่านั้น: คู่มือทีละขั้นตอน
ติดตามการค้นหาชื่อหนึ่งครั้งตั้งแต่เบราว์เซอร์จนถึงคำตอบ ดูว่าตัวแก้ชื่อถูกเลือกที่ใด ไฟร์วอลล์บังคับใช้ที่ใด และกฎพอร์ต 53 ไม่เคยครอบคลุมสิ่งใด
ติดตามการค้นหาชื่อหนึ่งครั้งตั้งแต่ช่วงเวลาที่คุณพิมพ์มัน เบราว์เซอร์ถามระบบปฏิบัติการ ระบบปฏิบัติการถามตัวแก้ชื่อที่เลือกโดยนโยบายของมัน และคำถามออกจากอุปกรณ์ผ่านอินเทอร์เฟซใดอินเทอร์เฟซหนึ่งด้วยการขนส่งใดการขนส่งหนึ่ง การออกแบบ VPN ของคุณกล่าวว่าคำตอบควรมาจากตัวแก้ชื่อที่เฉพาะเจาะจงผ่านเส้นทางที่เฉพาะเจาะจง ช่องว่างระหว่างสองประโยคนั้นคือสิ่งที่คุณกำหนดค่าแล้วจึงบังคับใช้
ขั้นตอนที่ 1: ตั้งชื่อตัวแก้ชื่อและเส้นทาง
เขียนสามสิ่งก่อนแตะไฟร์วอลล์: ที่อยู่ของตัวแก้ชื่อ โปรโตคอลและพอร์ตที่คุณคาดหวัง และอินเทอร์เฟซที่คำถามควรออกไป หากไม่มีรายการนี้ กฎก็เป็นการเดาเกี่ยวกับทราฟฟิก ไม่ใช่การบังคับใช้การตัดสินใจ VPN สามารถขนส่งข้อมูลของแอปพลิเคชันในขณะที่ DNS ทำตามการจัดวางแยกต่างหาก และนั่นไม่ใช่ข้อผิดพลาดในตัวเอง มันคือสิ่งที่เกิดขึ้นเมื่อไม่มีใครบอกลูกค้าเป็นอย่างอื่น
การระบุเส้นทางอย่างชัดเจนคือความแตกต่างระหว่างการออกแบบกับอุบัติเหตุ มันยังให้สิ่งที่คุณจะทดสอบในภายหลัง เพราะทุกการสังเกตสามารถเปรียบเทียบกับความคาดหวังที่เป็นลายลักษณ์อักษรได้ เก็บรายการนั้นไว้ในตั๋วเปลี่ยนแปลง ไม่ใช่ในหัวของใครคนใดคนหนึ่ง
ขั้นตอนที่ 2: วางนโยบายในที่ที่มันอยู่จริง
การเลือกตัวแก้ชื่อเป็นของไคลเอนต์: การกำหนดค่าเครือข่ายของระบบปฏิบัติการ การตั้งค่าของไคลเอนต์ VPN เอง หรือนโยบายเบราว์เซอร์ที่จัดการ วางไว้ที่นั่นก่อน ด้วยกลไกที่แพลตฟอร์มรองรับ เพราะไฟร์วอลล์ไม่สามารถบังคับไคลเอนต์ให้เลือกตัวแก้ชื่อที่ไม่เคยถูกบอกได้ บนไคลเอนต์แบบอุโมงค์แยก บอกอย่างชัดเจนว่าโดเมนใดไปยังตัวแก้ชื่อภายใน ในฟลีตที่จัดการ นโยบายเบราว์เซอร์มักเป็นคันโยกเดียวสำหรับ DoH เพราะเบราว์เซอร์สามารถเลือกตัวแก้ชื่อที่เข้ารหัสของตัวเองโดยไม่ขึ้นกับการตั้งค่าระบบ
ข้ามสิ่งนี้และไปที่ไฟร์วอลล์โดยตรง คุณจะได้กฎที่อนุญาตตัวแก้ชื่อที่ถูกต้องพร้อมกับไคลเอนต์ที่ไม่เคยใช้มัน กฎดูถูกต้องและบันทึกของตัวแก้ชื่อยังคงว่างเปล่า ซึ่งเป็นคู่ที่สับสนเมื่อต้องแก้ไขปัญหา กำหนดค่าการเลือกก่อน แล้วจึงบังคับใช้
ขั้นตอนที่ 3: บังคับใช้เส้นทางอย่างแคบ
ตอนนี้เพิ่มสิทธิ์เครือข่ายสำหรับเส้นทางที่อนุญาต: ที่อยู่ของตัวแก้ชื่อ โปรโตคอลและพอร์ต และอินเทอร์เฟซที่มันควรออกไป รักษากฎให้จำกัดอยู่ที่ตัวแก้ชื่อนั้นแทนที่จะอนุญาต DNS ขาออกทั้งหมด สามเส้นทางด้านล่างคือสิ่งที่ไคลเอนต์สมัยใหม่สามารถใช้ได้ และมีเพียงเส้นทางแรกเท่านั้นที่กฎพอร์ต 53 ครอบคลุม
| Path | Port | Who controls it |
|---|---|---|
| Classic DNS | UDP and TCP 53 | System resolver settings |
| DNS over TLS | TCP 853 | Resolver or stub configuration |
| DNS over HTTPS | TCP 443 | Browser or application policy |
การบล็อก DoH และ DoT เป็นสิ่งที่ชอบด้วยกฎหมาย การถือว่ากฎพอร์ต 53 บล็อกมันไปแล้วไม่ใช่ เบราว์เซอร์ที่ใช้ DoH แก้ชื่อผ่านเส้นทางที่กฎของคุณไม่เคยอธิบาย และแอปพลิเคชันที่นำตัวแก้ชื่อของตัวเองมาก็ทำเช่นเดียวกัน เขียนทุกเส้นทางที่คุณตั้งใจจะอนุญาตและทุกเส้นทางที่คุณตั้งใจจะปฏิเสธ กฎที่ไม่ระบุชื่อเส้นทางไม่ได้ตัดสินใจอะไรเกี่ยวกับเส้นทางนั้น
ขั้นตอนที่ 4: ติดตามชื่อส่วนตัวและชื่อสาธารณะ
DNS แบบแยกจะส่งเฉพาะเนมสเปซส่วนตัวไปยังตัวแก้ชื่อภายใน ในขณะที่ชื่อสาธารณะไปที่อื่น ดังนั้นการมีตัวแก้ชื่อมากกว่าหนึ่งตัวในการออกแบบจึงไม่ใช่การรั่วไหล การรั่วไหลคือคำถามที่ควรไปยังตัวแก้ชื่อของคุณแต่ไปถึงที่อื่น หรือเส้นทางที่ตั้งใจไว้ซึ่งเข้าถึงไม่ได้ทำให้ไคลเอนต์ถอยกลับอย่างเงียบ ๆ สองกรณีนี้คือสิ่งที่ต้องค้นหา ติดตามชื่อภายในหนึ่งชื่อและชื่อสาธารณะหนึ่งชื่อภายใต้นโยบายที่ตั้งใจไว้ และบันทึกว่าตัวแก้ชื่อใดตอบชื่อใด
ไซต์ทดสอบที่รายงานตัวแก้ชื่อของคุณเป็นเพียงเบาะแส ไม่ใช่หลักฐาน เพราะมันเห็นเพียงคำถามที่มาถึงมัน จับคำถามที่ฝั่งไคลเอนต์เมื่อคุณจำเป็นต้องรู้ว่าเส้นทางใดถูกใช้จริง แล้วเปรียบเทียบการสังเกตทั้งสอง เมื่อไม่ตรงกัน คุณพบการถอยกลับที่ไม่มีใครบันทึกไว้
หากที่อยู่ของตัวแก้ชื่อถูกต้องแต่เข้าถึงไม่ได้ ปัญหาอยู่ที่ การกำหนดเส้นทางหรือการกรอง ไม่ใช่นโยบาย ติดตามคำถามไปยังที่อยู่นั้นและยืนยันว่าคำตอบกลับมาบนอินเทอร์เฟซที่คาดหวังก่อนเปลี่ยนการตั้งค่าตัวแก้ชื่อใด ๆ
ขั้นตอนที่ 5: เก็บทางกลับไว้
ก่อนกระชับการเข้าถึง DNS ที่เกตเวย์ ยืนยันวิธีการกู้คืนที่ไม่ขึ้นกับการแก้ชื่อ ตัวแก้ชื่อที่เสียทำให้เครื่องมือซ่อมทุกอย่างเข้าถึงยากขึ้น รวมถึงสิ่งที่คุณจะใช้ย้อนการเปลี่ยนแปลงด้วย เปิด คอนโซลภายในหรือเส้นทางนอกแบนด์ ไว้จนกว่านโยบายใหม่จะได้รับการพิสูจน์ ถอดออกเฉพาะหลังจากนโยบายผ่านการเชื่อมต่อใหม่แล้ว
หลังการเชื่อมต่อใหม่หรือการอัปเดตนโยบายเบราว์เซอร์ ให้ตรวจสอบสถานะที่มีผลอีกครั้ง เพราะทั้งสองอย่างสามารถเปลี่ยนตัวแก้ชื่อโดยไม่เปลี่ยนกฎของคุณ ข้อกำหนดคือผู้รับที่รู้จักและเส้นทางที่ได้รับการป้องกันสำหรับคำถาม ไม่ใช่ป้ายตัวแก้ชื่อที่ทำให้สบายใจในภาพหน้าจอเดียว ข้อกำหนด RFC 8484 สำหรับ DNS over HTTPS เป็นเอกสารอ้างอิงสำหรับเส้นทางที่เข้ารหัสซึ่งกฎพอร์ตของคุณมองไม่เห็น