VPN เชื่อมต่อแล้วแต่ชื่อล้มเหลว: DNS พังจริงตรงไหน

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

การค้นหาต้องการอะไรจริง ๆ

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

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

Linux และ macOS ตอบคำถามเดียวกันด้วยคำสั่งต่างกัน และคำตอบก็ควรอ่านแบบเดียวกัน resolvectl status และ scutil --dns ทั้งคู่แสดงรายการเซิร์ฟเวอร์ตามอินเทอร์เฟซ เปรียบเทียบรายการนั้นกับที่อยู่ที่โปรไฟล์อ้างว่าส่งไป ความไม่ตรงกันตรงนี้อธิบายทุกอย่างที่เหลือ ดังนั้นจัดการให้เรียบร้อยก่อนทดสอบชื่อ

ทดสอบชื่อสาธารณะหนึ่งชื่อและชื่อส่วนตัวหนึ่งชื่อ

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

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

nslookup พิมพ์ทั้งเซิร์ฟเวอร์ที่ถามและคำตอบที่ได้รับ และนั่นคือคู่ที่คุณต้องการ รันสองครั้งในเชลล์เดียวกันแล้วเขียนที่อยู่ที่ตอบข้าง ๆ คำตอบแต่ละอัน

nslookup example.com
nslookup host.corp.example 10.20.30.53

ยืนยันว่าไคลเอนต์เข้าถึงเซิร์ฟเวอร์นั้นได้จริง

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

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

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

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

จำไว้ว่าเบราว์เซอร์ข้ามรีโซลเวอร์ของระบบได้

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

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

ล้างแคชและทดสอบงานจริงอีกครั้ง

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

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

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

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