VPN เปลี่ยน DNS ของฉันหรือไม่? เทียบก่อนและหลัง
โปรไฟล์สามารถย้ายการค้นหาของคุณได้โดยเจตนา เทียบทั้งนโยบายของตัวแก้ไขชื่อและคำตอบจริงก่อนและหลังการเชื่อมต่อ VPN โดยคงตัวแปรไว้หนึ่งอย่าง
คุณเชื่อมต่ออุโมงค์ เปิดแดชบอร์ดส่วนตัว แล้วชื่อก็ถูกแปลงเป็นที่อยู่ที่ไม่เคยเห็นมาก่อน หรือเกิดตรงกันข้าม คือเบราว์เซอร์ยังทำงานต่อไปแต่เครื่องมือบรรทัดคำสั่งกลับแปลงอะไรไม่ได้เลย ทั้งสองผลลัพธ์มาจากการเปลี่ยนแปลงเดียวกัน และผู้คนมักอธิบายด้วยประโยคเดียวว่า VPN "ใช้ DNS ของตัวเอง" ซึ่งไม่ละเอียดพอที่จะแก้ปัญหาหรือตรวจสอบ ในประโยคนั้นมีคำถามซ่อนอยู่สองข้อ คือนโยบายนี้ควรรับช่วงการค้นหาใด และเครื่องของคุณส่งคำค้นเหล่านั้นไปยังตัวแก้ไขชื่อที่ได้รับมาจริงหรือไม่ การแยกสองข้อนี้ออกจากกันคือวิธีการทั้งหมด เพราะการทดสอบที่ปนกันจะให้คำตอบที่ผิดอย่างมั่นใจทั้งสองทิศทาง
ทำไมโปรไฟล์จึงให้ตัวแก้ไขชื่อ
ภายในอุโมงค์ ชื่อที่อยู่หลังปลายทางไกลมักถูกแปลงเป็นที่อยู่ที่มีอยู่เฉพาะในเครือข่ายนั้น โซนส่วนตัวอย่าง corp.internal ไม่มีการมอบอำนาจสาธารณะ ตัวแก้ไขชื่อที่ตอบโซนนี้จึงต้องเข้าถึงได้จากภายในอุโมงค์ กลไกเดียวกันยังรองรับจุดประสงค์ที่สอง เมื่อการค้นหาจะออกผ่านผู้ให้บริการของคุณ ตัวแก้ไขชื่อฝั่งไกลจะเก็บคำค้นไว้ในเส้นทางที่เข้ารหัส นี่คือเหตุผลที่ที่อยู่เซิร์ฟเวอร์ DNS มาเป็นส่วนหนึ่งของนโยบายการเชื่อมต่อ ไม่ใช่การตั้งค่าระดับโลกที่คุณเลือกครั้งเดียวสำหรับเครื่อง
ที่อยู่เพียงอย่างเดียวไม่ได้ตัดสินอะไร ตัวแก้ไขชื่อจะตอบได้ก็ต่อเมื่อมีเส้นทางไปถึง และความล้มเหลวที่พบบ่อยที่สุดคือตัวแก้ไขชื่อที่เข้าถึงได้เฉพาะขณะอุโมงค์เปิดอยู่ เมื่ออุโมงค์ล่มและนโยบายยังอยู่ การค้นหาจะไปยังที่อยู่ที่ไม่มีเส้นทาง และอาการคือหมดเวลา ไม่ใช่ข้อผิดพลาดที่ชัดเจน ความต่างนี้สำคัญเมื่อคุณอ่านผลการทดสอบถัดไป เพราะการหมดเวลาทำให้คนไปปรับการตั้งค่าการรับส่งที่ไม่เกี่ยวข้องเลย
เทียบการออกแบบสองแบบก่อนเทียบคำตอบ
อุโมงค์เต็มและ DNS แบบแยกให้ความคาดหวังตรงกันข้าม และทั้งสองไม่ใช่ความผิดปกติ ภายใต้อุโมงค์เต็ม ทุกการค้นหาอาจย้ายไปยังผู้ให้บริการหรือตัวแก้ไขชื่อองค์กร การที่ชื่อสาธารณะตอบต่างออกไปหลังเชื่อมต่อจึงเป็นเรื่องคาดหมาย ภายใต้ DNS แบบแยก มีเพียงโดเมนที่ระบุไว้เท่านั้นที่ไปยังตัวแก้ไขชื่อส่วนตัว ขณะที่อย่างอื่นยังอยู่ภายในเครื่อง บน Windows รายการโดเมนอยู่ใน Name Resolution Policy Table บน macOS อยู่ในโดเมนที่ตรงกันของการตั้งค่า DNS และบนโฮสต์ systemd-resolved อยู่ในโดเมนเส้นทางต่อลิงก์
นี่คือการเปรียบเทียบที่ต้องทำก่อน เพราะเป็นตัวกำหนดว่าอะไรนับเป็นข้อบกพร่อง กับ DNS แบบแยก ชื่อสาธารณะที่ตอบจากตัวแก้ไขชื่อใหม่คือสิ่งที่ควรตรวจสอบ ขณะที่ชื่อภายในที่ตอบถูกต้องคือระบบที่กำลังทำงาน กับอุโมงค์เต็ม สิ่งผิดปกติคือชื่อสาธารณะที่ยังตอบจากตัวแก้ไขชื่อของผู้ให้บริการของคุณ เอกสารของ Microsoft เกี่ยวกับการแปลงชื่อ VPN อธิบายลำดับของ Windows สำหรับกฎเหล่านี้ รวมถึงวิธีที่รายการนโยบายที่ตรงกันถูกพิจารณาก่อนเซิร์ฟเวอร์ของอะแดปเตอร์เอง
ยังมีตัวแก้ไขชื่อตัวที่สามในห้องที่ลืมได้ง่าย DNS แบบปลอดภัยของเบราว์เซอร์แปลงชื่อด้วยตนเองและอาจตอบต่อไปได้หลังจากอุโมงค์เปลี่ยนนโยบายของระบบปฏิบัติการ ดังนั้นหน้าที่โหลดได้จึงพิสูจน์ว่าตัวแก้ไขชื่อของเบราว์เซอร์ทำงาน ไม่ได้พิสูจน์ว่าโปรไฟล์ถูกนำไปใช้ หากคุณเทียบเฉพาะสิ่งที่เบราว์เซอร์แสดง ครึ่งหนึ่งของเวลาคุณกำลังทดสอบชั้นที่ผิด
บันทึกเส้นฐานด้วยตัวแปรเดียว
เปลี่ยนอุโมงค์ อย่าเปลี่ยนชื่อ เครื่องมือ หรือคำต่อท้ายการค้นหาในขั้นตอนเดียวกัน เลือกชื่อที่คุณได้รับอนุญาตให้สอบถาม บันทึกว่าใช้แอปพลิเคชันใด และเขียนที่อยู่ที่ได้กลับมาหรือข้อผิดพลาดที่แน่นอน บน Windows Get-DnsClientServerAddress -AddressFamily IPv4 พิมพ์เซิร์ฟเวอร์ต่ออะแดปเตอร์ และ Get-DnsClientNrptPolicy พิมพ์รายการนโยบาย บน Linux ที่ใช้ systemd-resolved resolvectl status แสดงเซิร์ฟเวอร์ DNS และโดเมนเส้นทางต่อลิงก์ บน macOS scutil --dns พิมพ์ลำดับตัวแก้ไขชื่อที่ระบบจะปฏิบัติตามจริง
จากนั้นเชื่อมต่อผ่านการควบคุมปกติของไคลเอนต์และทำคำสั่งเดิมซ้ำให้เหมือนเดิม เก็บผลลัพธ์แรกไว้แทนการจดจำ เพราะการเปรียบเทียบคือประเด็นทั้งหมด และการอ่านครั้งที่สองหลังล้างแคชเป็นการวัดอีกอย่างหนึ่งแล้ว หากเส้นฐานถูกบันทึกโดยมีเบราว์เซอร์อยู่ด้านหน้าและการรันหลังเชื่อมต่อเกิดในเทอร์มินัล คุณกำลังเทียบตัวแก้ไขชื่อสองตัว ไม่ใช่สองสถานะของตัวแก้ไขชื่อเดียว
การสอบถามโดยตรงและการค้นหาของแอปพลิเคชันเป็นการทดสอบต่างกัน
การถามเซิร์ฟเวอร์หนึ่งตัวที่ระบุ ด้วย nslookup name 10.20.0.1 หรือ dig @10.20.0.1 name พิสูจน์เพียงอย่างเดียวว่าเซิร์ฟเวอร์ที่คุณระบุชื่อตอบเมื่อเข้าถึงได้ มันข้ามตรรกะการเลือกทั้งหมด จึงบอกไม่ได้ว่าระบบจะเลือกเซิร์ฟเวอร์นั้นสำหรับชื่อนี้หรือไม่ ใช้เพื่อทดสอบว่าตัวแก้ไขชื่อที่ได้รับมอบหมายเข้าถึงได้หรือไม่ และอย่าใช้เพื่อทดสอบนโยบาย
การค้นหาผ่านตัวแก้ไขชื่อภายในเครื่องใช้การเลือกจริง resolvectl query name เดินตามกฎโดเมนเส้นทางเดียวกันและรายงานว่าโปรโตคอลใดตอบ Resolve-DnsName บน Windows ผ่านตารางนโยบายและแคชของไคลเอนต์ และ scutil --dns แสดงลำดับที่การค้นหาจะตาม รันทั้งสองแบบและเก็บไว้ในคอลัมน์แยกกันในบันทึกของคุณ การสอบถามโดยตรงที่สำเร็จข้างการค้นหาของแอปพลิเคชันที่ล้มเหลวคือปัญหาการกำหนดเส้นทางหรือการเลือก ไม่ใช่ตัวแก้ไขชื่อที่ปฏิเสธทำงาน
แคชอยู่ระหว่างคุณกับคำตอบ ระบบปฏิบัติการ ตัวแก้ไขชื่อแบบสตับภายในเครื่อง เบราว์เซอร์ และแคชเชิงลบต่างเก็บผลลัพธ์ไว้ การค้นหาจึงอาจสำเร็จได้โดยไม่มีแพ็กเก็ตใดออกจากเครื่อง บันทึกผลลัพธ์ก่อนล้างสิ่งใด ipconfig /flushdns resolvectl flush-caches หรือ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder บน macOS ข้ามการรีเซ็ตเครือข่ายแบบกว้างในขั้นนี้ เพราะมันทำลายหลักฐานที่คุณยังเก็บอยู่
ความต่างหมายถึงอะไร
เทียบสองแถวที่บันทึกไว้และจำแนกการเปลี่ยนแปลงก่อนแตะการตั้งค่าใด
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
แถวหนึ่งควรเน้น ชื่อที่แปลงได้ไม่ใช่บริการที่ทำงาน และความสำเร็จของ DNS บอกเพียงว่าพบที่อยู่ ไม่ได้บอกอะไรเกี่ยวกับการส่งต่อ กฎไฟร์วอลล์ หรือว่าบัญชีของคุณใช้บริการนี้ได้หรือไม่ จบด้วยการทดสอบแอปพลิเคชันจริงแทนการสันนิษฐานว่าข้อบกพร่องจากไปเอง
คืนเส้นฐานและตรวจสอบ
ตัดการเชื่อมต่อผ่านการควบคุมของไคลเอนต์เองแทนการฆ่าโปรเซส แล้วอ่านสามคำสั่งเดิมอีกครั้ง เซิร์ฟเวอร์ต่อลิงก์ รายการนโยบาย และคำตอบสำหรับชื่อทดสอบของคุณควรกลับไปยังเส้นฐานที่เขียนไว้ก่อนหน้า รายการนโยบายที่หลงเหลือหลังตัดการเชื่อมต่ออย่างสะอาดเป็นข้อบกพร่องจริงที่ควรบันทึก และนี่คือเหตุผลที่การแก้ไฟล์ตัวแก้ไขชื่อที่สร้างขึ้นด้วยมือเป็นนิสัยที่ไม่ดี ไฟล์จะถูกเขียนใหม่และการแก้ไขหายไป หรือการแก้ไขอยู่ต่อและตรึงตัวแก้ไขชื่อที่ไม่มีเส้นทางอีกแล้ว
ทำตามรายการนี้หนึ่งครั้งตามลำดับ ตัดสินว่าโปรไฟล์ใช้การออกแบบใดก่อนตัดสินผลใด คงชื่อ เครื่องมือ และคำต่อท้ายไว้ทั้งสองรอบ แยกการสอบถามโดยตรงจากการค้นหาของแอปพลิเคชัน อ่านนโยบายที่มีผล ไม่ใช่แค่คำตอบ ล้างแคชเป็นขั้นสุดท้ายหลังเขียนการเปรียบเทียบแล้ว ตรวจสอบด้วยแอปพลิเคชันจริง แล้วรีบูตหนึ่งครั้งและยืนยันว่าสถานะตัดการเชื่อมต่อยังสะอาด