DNS ของ OpenVPN บนเกตเวย์: dnsmasq และขอบเขตของไฟร์วอลล์

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

ตัวรับฟังคือบริการภายในเครื่องที่มีสองทิศทาง

ขาเข้า ไคลเอนต์ส่งคิวรีไปยังที่อยู่ของอุโมงค์บนเกตเวย์ที่พอร์ต 53 ขาออก เดมอนส่งต่อคิวรีนั้นไปยังอัปสตรีมที่กำหนดไว้ สองครึ่งต้องทำงานทั้งคู่ และมันล้มเหลวต่างกัน

การหมดเวลาที่ไคลเอนต์รายงานกับการหมดเวลาที่เห็นบนเกตเวย์ไม่ใช่ความผิดพลาดเดียวกัน

ผูกที่อยู่ของอุโมงค์ ไม่ใช่ทุกที่อยู่

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

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic ผูกที่อยู่แต่ละรายการและรับมือเมื่อ tun0 ปรากฏขึ้นภายหลัง ซึ่งสำคัญบนโฮสต์ที่บริการ VPN รีสตาร์ต การระบุ loopback ทำให้เครื่องมือภายในเครื่องยังทำงานได้โดยไม่เพิ่มตัวรับฟังสาธารณะ no-resolv ป้องกันไม่ให้เดมอนสืบทอดอัปสตรีมจากการตั้งค่าตัวแก้ไขชื่อของโฮสต์ และ no-hosts ป้องกันไม่ให้อินสแตนซ์นี้เผยแพร่ไฟล์ hosts ของเกตเวย์ ไม่มีตัวเลือกใดให้สิทธิ์ใครในการคิวรีบริการ

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

อนุญาตขาเข้าของ DNS ไม่ใช่การผ่านของอุโมงค์

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

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS ทำงานบน TCP เช่นเดียวกับ UDP ดังนั้นกฎสำหรับ UDP อย่างเดียวจึงทำให้คำตอบขนาดใหญ่ล้มเหลวในลักษณะที่ดูเหมือนเป็นช่วง ๆ สิ่งเหล่านี้ไม่ใช่ ufw route สิทธิ์ และไม่ควรกลายเป็นสิทธิ์กว้างบน tun0 ลำดับสำคัญพอ ๆ กับเนื้อหา: กฎก่อนหน้าที่ทิ้งขาเข้าทั้งหมดจาก tun0 ยังชนะอยู่ดี และการเพิ่มสิทธิ์ใต้การทิ้งขั้นสุดท้ายไม่ได้สร้างอะไร

หาก DNS ของเกตเวย์เป็นส่วนหนึ่งของการออกแบบแล้ว ให้ทบทวนนโยบายเดิมนั้นอย่างตั้งใจและบันทึกเหตุผล

ครึ่งอัปสตรีมเป็นเส้นทางแยก

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

อย่าเพิ่มขาออกของอุโมงค์แบบไม่จำกัดเพื่อให้คำตอบทำงาน คำตอบที่ติดตามอยู่ไม่ต้องการสิ่งนั้น

ดันตัวเลือกออกไป แล้วตรวจสอบการส่งต่อ

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

push "dhcp-option DNS 10.90.0.1"

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

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

ทดสอบสิ่งที่คุณสร้างจริง

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

หากคิวรีโดยตรงทำงานแต่แอปยังล้มเหลว แสดงว่าความผิดพลาดอยู่ที่การส่งต่อ ไม่ใช่ที่เซิร์ฟเวอร์:

• ไคลเอนต์ไม่เคยนำตัวเลือกที่ดันออกไปไปใช้
• มีตัวแก้ไขชื่ออื่นถูกตั้งภายหลังและชนะการแข่ง
• แอปใช้ไลบรารีตัวแก้ไขชื่อของตัวเองหรือคำตอบที่แคชไว้

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