ทำไม nslookup แก้ชื่อผ่าน VPN ได้ แต่เบราว์เซอร์ทำไม่ได้

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

การตรวจสอบด้านล่างไล่ตามเส้นทางเหล่านั้นจากระบบออกไปด้านนอก อย่าแก้โปรไฟล์ VPN จนกว่าจะรู้ว่าเส้นทางใดตอบและเส้นทางใดล้มเหลว

นโยบายสามข้อเป็นตัวตัดสินคำตอบ

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

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

ทำไมเบราว์เซอร์จึงถามคำถามอื่น

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

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

อ่านรายการตัวแก้ชื่อและกฎ

บน Windows ให้พิมพ์สิ่งที่ระบบถืออยู่ก่อนตั้งสมมติฐาน Get-DnsClientServerAddress แสดงเซิร์ฟเวอร์ตามอินเทอร์เฟซ Get-DnsClientNrptRule แสดงรายการกฎเนมสเปซ และ Resolve-DnsName ตอบชื่อที่แน่นอนผ่านเส้นทางของระบบ เปรียบเทียบคำตอบนั้นกับคำถามตรงไปยังเซิร์ฟเวอร์ของ VPN ตามที่อยู่ เมื่อ Resolve-DnsName ล้มเหลวแต่คำถามตรงสำเร็จ ตัวน่าสงสัยคือรายการตัวแก้ชื่อหรือกฎเนมสเปซ

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

ตัวแก้ชื่อที่ถูกดันมาและเข้าถึงไม่ได้

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

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

DNS ที่เข้ารหัสข้ามเส้นทางทั้งหมด

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

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

การซ่อมที่ตรงกับความล้มเหลว

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

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

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