DNS ที่ OpenVPN ผลักไปถูกละเลย: ส่วนประกอบใดนำไปใช้

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

ตัวเลือกที่ผลักไปคือข้อเสนอ ไม่ใช่การติดตั้ง

บนเซิร์ฟเวอร์ คำสั่งสองรายการอธิบายเจตนา ไม่ใช่ผลลัพธ์:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

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

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

ยืนยันว่าการผลักไปถึงและหาเจ้าของให้พบ

เริ่มจากการระบุตัวเรียกใช้: คำสั่ง openvpn เปล่า อินสแตนซ์ systemd, NetworkManager หรือไคลเอนต์ของผู้จำหน่าย สิ่งนี้กำหนดว่าฮุกอยู่ที่ไหนได้ บนโฮสต์ที่มี systemd-resolved, resolvectl status จะแสดงแต่ละลิงก์พร้อมเซิร์ฟเวอร์ DNS และโดเมนค้นหาที่ใช้จริง และลิงก์ของอุโมงค์ไม่ได้ชื่อ tun0 เสมอ

ถ้าที่อยู่ที่ผลักไปปรากฏในบันทึกแต่ไม่อยู่บนลิงก์ใดเลย แปลว่าการเชื่อมต่อขาดไป ถ้าอยู่บนลิงก์แต่คำถามยังออกไปที่อื่น ปัญหาคือ คำถามใดเลือกลิงก์นั้น NetworkManager dns=dnsmasq ในไฟล์ /etc/NetworkManager/NetworkManager.conf เรียกตัวส่งต่อภายในที่ใช้ DNS แยกส่วนโดยเจตนา: ชื่อในโดเมน VPN ไปยังรีโซลเวอร์ VPN ส่วนที่เหลือคงเส้นทางเดิม พฤติกรรมนี้ดูเหมือนข้อบกพร่องเมื่อคุณคาดว่าทราฟฟิกทั้งหมดจะย้าย ตรวจสอบการตั้งค่าต่อการเชื่อมต่อด้วย nmcli connection show "My VPN" โดยที่ ipv4.dns และ ipv4.dns-search เก็บค่าที่อยู่เบื้องหลังสิ่งที่อุปกรณ์รายงาน ก่อนจะเรียกมันว่าเสีย หากทุกคำถามต้องไปถึงรีโซลเวอร์ VPN จริง ๆ ให้ลบ dns=dnsmasq ออกจาก NetworkManager.conf แล้วรีสตาร์ต NetworkManager ซึ่งคืนการแปลงชื่อให้การตั้งค่าการเชื่อมต่อ มิฉะนั้นให้เก็บ DNS แยกส่วนไว้และแก้รายการโดเมนที่ผลักไป

Linux: ส่งตัวเลือกให้รีโซลเวอร์

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

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

เมื่อมี systemd-resolved สคริปต์ resolv.conf แบบเก่าอาจไม่เปลี่ยนอะไรที่มีนัยสำคัญ เพราะรีโซลเวอร์แบบ stub เก็บสถานะแยกลิงก์ update-systemd-resolved ตัวช่วยบันทึกรูปแบบฮุกที่ใช้ up-restart และ down-preซึ่งสำคัญเมื่ออินเทอร์เฟซอยู่ยาวกว่าการพยายามเชื่อมต่อหนึ่งครั้ง เลือกอะไรก็ตาม ส่วนประกอบเดียวต้องเป็นเจ้าของสถานะ การเพิ่มฮุกที่ไม่เกี่ยวข้องข้าง NetworkManager ทำให้ลิงก์เดียวมีผู้เขียนสองราย และผลลัพธ์จะขึ้นกับลำดับ ไม่ใช่การกำหนดค่าของคุณ

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

Windows และ macOS นำไปใช้คนละส่วน

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

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

ถ้าไม่มีที่อยู่ ให้ตั้งด้วย Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1 จากนั้นเพิ่มส่วนต่อท้ายในคุณสมบัติ IPv4 ของอะแดปเตอร์เพื่อให้ fileserver กลายเป็น fileserver.corp.example ค่า SearchList ระดับเครื่องภายใต้ Tcpip\Parameters ทำแบบเดียวกัน ที่ใดชื่อยาวแปลงได้แต่ชื่อเปล่าไม่ได้ รีโซลเวอร์ถูกต้องแล้วและรายการค้นหาเป็นตัวปัญหา การแก้ไขตามลำดับ: ผลัก DOMAIN เพื่อให้ไคลเอนต์เรียนรู้ส่วนต่อท้าย เพิ่มส่วนต่อท้ายนั้นในรายการค้นหาของอะแดปเตอร์หรือการเชื่อมต่อ และเป็นมาตรการชั่วคราวให้ปักชื่อไว้ใน hosts หรือ LMHOSTS บน Windows การท่อง NetBIOS ไม่ข้ามเราเตอร์ ดังนั้นการออกอากาศที่พบชื่อสั้นบน LAN ของสำนักงานจึงไม่ถึงไคลเอนต์อุโมงค์เลย

block-outside-dns block-outside-dns เป็นพฤติกรรมของไคลเอนต์ Windows ไม่ใช่บรรทัดโปรไฟล์ที่พกพาได้ และการคัดลอกไปยังโปรไฟล์ Linux หรือ macOS ไม่ได้จำลองมันที่นั่น ถ้าชื่อสาธารณะทำงานและชื่อภายในล้มเหลวบน Windows ให้เทียบลำดับอะแดปเตอร์ในการตั้งค่าขั้นสูงกับ ipconfig /all บน macOS ลำดับรีโซลเวอร์ต่อบริการเป็นของระบบ จึงใช้ scutil --dns เพื่อดูว่ารีโซลเวอร์ใดถูกถามสำหรับโดเมนใด และถือว่าการแก้ไขโปรไฟล์เดี่ยวใด ๆ ที่รายงานมาเป็นเรื่องขึ้นกับไคลเอนต์ ไม่ใช่ทั่วไป

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

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

พิสูจน์ว่าคำถามไปที่ไหน

การดักจับระหว่างการค้นหาหนึ่งครั้งยุติข้อโต้แย้ง: tcpdump -ni eth0 port 53 แสดงคำถามบนอินเทอร์เฟซทางกายภาพ หมายความว่าพวกมันออกนอกอุโมงค์และรีโซลเวอร์ไม่เคยถูกสลับ dig @10.8.0.1 name.corp.example จากนั้นแยกสองกรณีที่เหลือ ถ้าคำถามตรงตอบกลับ รีโซลเวอร์ทำงานและไคลเอนต์ไม่ได้ใช้มัน ถ้าหมดเวลา รีโซลเวอร์เข้าถึงไม่ได้ผ่านอุโมงค์และการเปลี่ยนแปลงภายในเครื่องจะไม่ช่วย

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

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

รักษาเจ้าของไว้หนึ่งรายและตรวจสอบตามลำดับ

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

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