การแก้ไข resolv.conf ไม่ได้แก้ DNS หลัง VPN ตัดการเชื่อมต่อ

คุณตัดการเชื่อมต่อ VPN แล้ว ping 1.1.1.1 ยังตอบอยู่ และทุกการค้นหาชื่อค้างก่อนที่หน้าจะยอมแพ้ในที่สุด จากนั้น cat /etc/resolv.conf แสดงชื่อเซิร์ฟเวอร์ที่เคยมีอยู่เพียงภายในอุโมงค์เท่านั้น โดยปกติเป็นรายการแรก การลบบรรทัดนั้นดูเหมือนแก้ไขได้ราวสิบนาที จนกว่าการพักเครื่อง การโรมมิ่ง Wi-Fi หรือการรีสตาร์ตจะใส่กลับคืน ไฟล์ที่คุณแก้ไขไม่ใช่การตั้งค่า แต่เป็นการแสดงภาพของสถานะลิงก์ที่ส่วนประกอบอื่นเป็นเจ้าของ.

ทำไมรายการเก่ารายการเดียวจึงเสียเวลาหลายวินาทีต่อการค้นหา

ตัวแปลงชื่อของ glibc เดินผ่านรายการชื่อเซิร์ฟเวอร์ตามลำดับและรอให้หมดเวลาก่อนจะลองตัวถัดไป และ resolv.conf(5) จำกัดรายการนั้นไว้ที่สามรายการ วางตัวแปลงชื่อฝั่งอุโมงค์เช่น 10.8.0.1 ไว้บนสุดหลังจากอุโมงค์หายไป แล้วทุกการค้นหาจะจ่ายเวลารอก่อนจะตกไปยังเซิร์ฟเวอร์ที่ตอบได้ นี่คือสาเหตุที่อาการดูเหมือนการเชื่อมต่อที่ตายแล้วไม่ใช่ข้อผิดพลาด DNS เบราว์เซอร์ถูกบล็อก หมดเวลา และบางครั้งให้ที่อยู่ที่แคชไว้ซึ่งจะล้าสมัยในภายหลัง

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

ความเชื่อผิด: resolv.conf เป็นไฟล์การตั้งค่า

ถามว่าเส้นทางนั้นคืออะไรจริง ๆ ก่อนจะเปลี่ยน:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

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

resolvectl status คือมุมมองที่บอกความจริง เซิร์ฟเวอร์ DNS ต่อลิงก์ โดเมนการกำหนดเส้นทาง และลิงก์อุโมงค์ยังมีอยู่หรือไม่ resolvectl query example.com ไปไกลกว่านั้นและแสดงว่าอินเทอร์เฟซใดตอบ ใช้ทั้งสองก่อนแตะไฟล์ และจำไว้ว่าเบราว์เซอร์ที่มี DNS ปลอดภัยของตัวเองจะเพิกเฉยต่อทั้งหมดนี้

หาเจ้าของก่อนแก้ไขอะไร

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

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

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

ล้างสถานะลิงก์ที่ไคลเอนต์ทิ้งไว้

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

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

อย่าเอื้อมไปหา pkill -f vpn หรือ killall vpn ก่อนอ่านรายการที่ตรงกันทั้งหมด -f ตรงกับทั้งบรรทัดคำสั่ง จึงอาจสิ้นสุดสคริปต์ตัวห่อ เซสชันของตัวแก้ไข หรือโปรเซสที่ไม่เกี่ยวข้องซึ่งเส้นทางมีสตริงนั้น การสิ้นสุดโปรเซสผิดตัวกลางงานคือวิธีที่ปัญหาตัวแปลงชื่อกลายเป็นไฟล์ที่สูญหาย

resolvectl revert รีเซ็ตการกำหนดค่า DNS ขณะรันของลิงก์นั้น ซึ่งแคบกว่าการรีสตาร์ตตัวแปลงชื่อและแคบกว่าการแก้ไฟล์ส่วนกลางมาก ถ้าลิงก์อุโมงค์หายไปทั้งหมด systemctl restart NetworkManager จะสร้างสถานะการเชื่อมต่อใหม่ และนี่คือขั้นตอนที่เธรดต้นทางกลับมาบ่อยครั้ง ระวังตัวจัดการบริการที่มี Restart=always เพราะมันอาจเอาไคลเอนต์ที่ถูกฆ่าและการตั้งค่า DNS ของมันกลับมาโดยตรง

อีกทิศทางหนึ่ง: DNS ที่ถูกผลักแต่ไม่เคยมาถึง

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

ทดสอบการส่งต่อด้วยการทำด้วยมือ ซึ่งแยก «เซิร์ฟเวอร์ผิด» ออกจาก «ไม่มีใครนำไปใช้»:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

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

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

สำหรับอุโมงค์ของบริษัทที่ควรตอบเฉพาะชื่อภายใน ให้ระบุโซนเหล่านั้นด้วยเครื่องหมายทิลเดอนำหน้าแทนการดักจับทุกอย่าง เพื่อให้ชื่อสาธารณะยังใช้ตัวแปลงชื่อภายในเครื่อง

วิธีเลี่ยงที่กลายเป็นความขัดข้องครั้งถัดไป

การคัดลอก resolv.conf ก่อนเชื่อมต่อและกู้คืนภายหลังเป็นบรรทัดที่ชอบด้วยกฎใน runbook และเป็นวิธีเลี่ยงไม่ใช่การซ่อม มันล้มเหลวตรงเวลาที่สำคัญเพราะการพังหรือการรีบูตแบบบังคับข้ามการกู้คืน จดไว้เป็นวิธีเลี่ยงเพื่อให้คนถัดไปไม่สร้างต่อยอดบนมัน

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

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