WireGuard ไม่ผลัก DNS: การให้บริการโซน BIND ส่วนตัว

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

อุโมงค์และตัวแก้ไขชื่อเป็นสัญญาแยกจากกัน

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

ดังนั้นอุโมงค์ที่ทำงานได้ไม่ได้บอกอะไรเกี่ยวกับการแก้ชื่อ ไคลเอนต์อาจมีเส้นทางที่สมบูรณ์ไปยัง 10.90.0.1 และยังส่งคำถามไปยังตัวแก้ไขชื่อสาธารณะ นั่นคือเหตุที่อาการดูเหมือน “VPN ทำให้ DNS พัง” ทั้งที่ DNS ไม่เคยถูกชี้ไปที่ VPN

ให้บริการโซนโดยไม่กลายเป็นตัวแก้ไขชื่อแบบเรียกซ้ำ

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

รวมค่าตั้งเหล่านี้เข้ากับบล็อก options ที่มีอยู่แทนการสร้างบล็อกที่สอง:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

จากนั้นประกาศโซนและไฟล์ของมัน:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};

$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

ตรวจสอบก่อนโหลดใหม่ เพราะข้อผิดพลาดทางไวยากรณ์ตอนโหลดจะทำให้เซิร์ฟเวอร์ทั้งหมดล่มสำหรับทุกโซนที่มันให้บริการ:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

เปิด UDP และ TCP 53 เฉพาะบนอินเทอร์เฟซ VPN การเผยแพร่ผู้มีอำนาจส่วนตัวบนอินเทอร์เฟซสาธารณะเชิญทั้งคำถามและการแจกแจง และ allow-transfer ควรปิดไว้เว้นแต่เซิร์ฟเวอร์สำรองจำเป็นจริง ๆ

ชี้ไคลเอนต์ไปที่มัน แยกตามลิงก์

สมมติว่า NetworkManager เป็นเจ้าของการเชื่อมต่อและ systemd-resolved เป็นตัวแก้ไขชื่อ อ่านนโยบายที่มีอยู่ก่อน โดยเฉพาะโดเมนเส้นทางราก เพราะรายการ ~. จะเหนือกว่าสิ่งที่คุณกำลังจะเพิ่ม

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

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

ใช้การเปลี่ยนแปลงผ่านตัวจัดการที่เป็นเจ้าของอินเทอร์เฟซ แล้วเชื่อมต่อใหม่ อย่าเริ่มอินสแตนซ์ wg-quick ที่สองสำหรับอินเทอร์เฟซเดียวกัน เพราะเจ้าของสองรายจะแย่งเส้นทางและหนึ่งในนั้นจะชนะในจังหวะที่แย่ที่สุด

ตรวจสอบเส้นทางก่อนชื่อ

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

resolvectl query portal.corp.example

หากได้ 10.60.0.20 กลับมา สัญญา DNS ก็เสร็จสมบูรณ์ หากหมดเวลา ให้ตรวจเส้นทางไปยัง 10.90.0.1 ก่อน แล้วจึงกฎไฟร์วอลล์ แล้วจึง allow-query บนเซิร์ฟเวอร์ ความล้มเหลวในการแก้ชื่อในการตั้งค่านี้เกือบทั้งหมดคือการเข้าถึงหรือ ACL ไม่ใช่ไฟล์โซน ทำงานจากไคลเอนต์ออกไปข้างนอก เพราะเซิร์ฟเวอร์บอกคุณไม่ได้ว่าทำไมคำถามไม่เคยมาถึง

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

สิ่งที่ยังไม่เป็นอัตโนมัติ

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

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

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