ทำไมชื่อ DNS ส่วนตัวจึงล้มเหลวบนไคลเอนต์ VPN และควรตรวจตรงไหน

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

ก่อนแก้ไขโปรไฟล์ใด ให้ยืนยันว่าไคลเอนต์ทำอะไรกับชื่อ บน Linux resolvectl query files.corp.example แสดงว่าลิงก์ใดและตัวแปลงใดสร้างคำตอบ บน Windows Resolve-DnsName files.corp.example แสดงเซิร์ฟเวอร์ที่ตอบและที่อยู่ที่ส่งกลับ

อ่านคำตอบก่อนจะเปลี่ยนอะไร

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

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

แจกจ่ายตัวแปลงจากภายในอุโมงค์

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

OpenVPN อยู่ในกลุ่มแรก บนเซิร์ฟเวอร์ push "dhcp-option DNS 10.8.0.53" และ push "dhcp-option DOMAIN corp.example" เดินลงมาทางช่องควบคุม แต่จะเกิดผลก็ต่อเมื่อการตั้งค่าไคลเอนต์ยังเปิด pull อยู่ ไคลเอนต์ที่แก้ด้วยมือและมี pull-filter ignore "dhcp-option" จะไม่มีวันเห็นคำสั่งเหล่านั้น และบรรทัดเดียวนี้ก็อธิบายกรณี «เซิร์ฟเวอร์ผลักลงมาแต่แล็ปท็อปของผมไม่เห็นด้วย» ได้มากมายอย่างน่าประหลาด

WireGuard อยู่ในกลุ่มที่สอง เพราะโปรโตคอลไม่มีการเจรจาตัวเลือกเลย ตัวแปลงและโดเมนค้นหาจะอยู่ในบล็อก [Interface] ของไคลเอนต์เองในรูป DNS = 10.8.0.53, corp.example wg-quick นำไปใช้ผ่าน resolvconf หรือ systemd-resolved และบน Windows ไคลเอนต์อย่างเป็นทางการจะติดตั้งกฎ NRPT ที่มีอยู่เฉพาะตอนอุโมงค์เปิดอยู่: Get-DnsClientNrptPolicy แสดงรายการกฎเหล่านั้น จึงเป็นวิธีเร็ว ๆ ที่จะดูว่าไคลเอนต์เคยนำไฟล์ของคุณไปใช้หรือไม่

IPsec/IKEv2 อยู่ตรงกลาง ปลั๊กอิน attr ของ strongSwan อาจคืนเซิร์ฟเวอร์ DNS ที่ดึงมาจากพูลได้ และไคลเอนต์ Windows มักยอมรับ แต่โปรไฟล์ที่ตรึงเซิร์ฟเวอร์ชื่อของตัวเองไว้จะชนะทุกอย่างที่เกตเวย์เสนอ บนไคลเอนต์ Linux ขั้นตอนทำมือที่เทียบเท่าคือ resolvectl dns wg0 10.8.0.53 ตามด้วย resolvectl domain wg0 '~corp.example' ทั้งสองหายไปพร้อมอินเทอร์เฟซ ซึ่งเป็นสิ่งที่คุณต้องการพอดีสำหรับการตั้งค่าที่จำกัดขอบเขตตามอุโมงค์

จำกัดขอบเขตส่วนต่อท้ายแทนที่จะกลืนทุกคำถาม

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

ส่งเฉพาะส่วนต่อท้ายส่วนตัวเข้าไปข้างใน บน systemd-resolved โดเมนที่ขึ้นต้นด้วย ~ เป็นการกำหนดเส้นทางเท่านั้น ดังนั้น ~corp.example หมายความว่าคำถามภายใต้ส่วนต่อท้ายนั้นจะไปยังเซิร์ฟเวอร์ของลิงก์นั้น ขณะที่ทุกอย่างอื่นยังใช้เครือข่ายกายภาพอยู่ Windows ทำแบบเดียวกันด้วยกฎ NRPT ที่จำกัดขอบเขตตามเนมสเปซ และ macOS ด้วยไฟล์ตัวแปลงเสริมภายใต้ /etc/resolver/

ชื่อมัลติแคสต์สมควรได้รับคำตอบของตัวเอง ชื่อ .local เป็น link-local ตามการออกแบบ (RFC 6762) และอินเทอร์เฟซ tun แบบจุดต่อจุดไม่พากลุ่มมัลติแคสต์นั้นไปด้วย ดังนั้นการเพิ่มตัวแปลงสาธารณะจะไม่ประกาศชื่อเหล่านั้น และการถามตัวแปลงภายในแบบยูนิแคสต์ก็ได้ NXDOMAIN กลับมา ตัวสะท้อนอย่าง avahi ในโหมดสะท้อนสามารถเชื่อมสองเซกเมนต์ได้ แต่นั่นเป็นการตัดสินใจฝั่งเซิร์ฟเวอร์ที่ไม่มีไคลเอนต์ใดขอได้ ถ้าเครื่องพิมพ์หรือ NAS ต้องเข้าถึงได้ด้วยชื่อ ให้ใส่เรกคอร์ด A ในโซนของคุณแทน

พิสูจน์ว่าคำตอบเดินทางกลับได้

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

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

ช่วงที่ทับซ้อนกันทำให้เกิดความล้มเหลวตรงข้าม คำตอบถูกต้อง เส้นทางมีอยู่ และมันชี้ไปยังโฮสต์ผิด เพราะ 192.168.0.0/24 ที่บ้านเจาะจงกว่ากำหนดเส้นทางของอุโมงค์ไปยังช่วงเดียวกัน เปลี่ยนเลขฝั่งหนึ่งหรือผลักเส้นทางที่แคบกว่าเข้าไป แล้วยืนยันไฟร์วอลล์และเส้นทางขากลับของโฮสต์บริการ บันทึกของ strongSwan เรื่อง การส่งต่อ ครอบคลุมด้าน sysctl ของเส้นทางนั้น

ใบรับรองเป็นการตรวจสอบตัวตนอีกชั้นที่คนมักโทษ DNS ถ้าเบราว์เซอร์รายงานชื่อไม่ตรงแทนที่จะเป็นข้อผิดพลาดในการแปลง แปลว่าการค้นหาทำงานแล้ว และสิ่งที่ต้องแก้คือ SAN ในใบรับรอง ทดสอบ HTTPS ด้วยชื่อ ไม่ใช่ด้วย IP เปล่า ๆ

ทดสอบซ้ำจากไคลเอนต์ ไม่ใช่จากเกตเวย์

ทดสอบภายในแอปที่ผู้ใช้บ่นว่า เพราะการค้นหาจากบรรทัดคำสั่งไม่ได้พิสูจน์ว่าเบราว์เซอร์ไปเส้นทางเดียวกัน DNS แบบปลอดภัยของ Chrome และ network.trr.mode ของ Firefox อาจข้ามตัวแปลงของระบบไปเลย และเมื่อเป็นเช่นนั้น ชื่อส่วนตัวก็ล้มเหลวหรือรั่วไปยังตัวแปลงสาธารณะ การเทียบ resolvectl query กับ dig @10.8.0.53 files.corp.example ที่รันด้วยมือจะบอกคุณว่าเกิดกรณีไหน

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

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