วิธีตรวจสอบตัวแก้ไข DNS ที่ Mac ของคุณใช้บน VPN

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

อ่านลำดับบล็อกก่อนที่อยู่

ทุกรายการเริ่มด้วย resolver #N และแสดง nameserver[0] บางครั้ง if_index บรรทัด flags reach และเมื่อบล็อกไม่ใช่ค่าเริ่มต้นธรรมดา ก็มี domain และรายการ search domain ตัวแก้ไขหมายเลข 1 ที่ไม่มีโดเมนคือค่าเริ่มต้นที่จัดการชื่อสาธารณะ อะไรก็ตามที่มี Scoped ในแฟล็กจะผูกกับอินเทอร์เฟซที่ if_index ระบุ และอะไรก็ตามที่ทำเครื่องหมาย Supplemental ใช้ได้เฉพาะกับโดเมนที่ระบุไว้ใต้บล็อกนั้น

การเลือกคือการจับคู่ส่วนต่อท้าย สำหรับชื่ออย่าง intranet.corp.example macOS เลือกตัวแก้ไขที่มีรายการ domain เป็นส่วนต่อท้ายที่ตรงกันยาวที่สุด ดังนั้นบล็อกที่มี domain : corp.example ชนะค่าเริ่มต้นแม้จะอยู่ลึกในเอาต์พุต order ตัดสินเสมอระหว่างโดเมนที่ยาวเท่ากัน การดูครั้งแรกแทบไม่ต้องมากไปกว่านี้: เอาต์พุตทั้งหมดเมื่อต้องการอ่านบล็อกเดียวตั้งแต่ต้นจนจบ บรรทัดเปิดเพื่อเรียนรู้ลำดับบล็อก และรอบที่กรองแล้วซึ่งพิมพ์หัวบล็อกข้างบรรทัดฟิลด์ บล็อกที่มีขอบเขตปรากฏใต้หัวของตัวเองและอ่านเหมือนส่วนต่อของรายการด้านบน จึงควรเก็บหัวไว้ในสายตาทุกครั้งที่อ้างอิงเอาต์พุต

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

จับคู่ if_index กับอินเทอร์เฟซของอุโมงค์

ดัชนีมีประโยชน์ก็ต่อเมื่อระบุอินเทอร์เฟซข้างหลังได้ scutil --nwi แสดงข้อมูลเครือข่ายที่ระบบถืออยู่ รวมถึงอินเทอร์เฟซหลักและการเข้าถึง ขณะที่ ifconfig -l ให้ชื่อแก่คุณ โดย utun0 ถึง utun9 คือผู้สมัครอุโมงค์ที่ไคลเอนต์มักสร้าง Apple ใช้ scutil --dns เป็นตัวอย่างการตรวจสอบของตัวเองในคู่มือการปรับใช้และจัดทำเอกสารว่า Network Extension ส่งต่อโดเมนที่เลือกไปยังตัวแก้ไขที่เลือกได้อย่างไร ซึ่งเป็นกลไกที่บล็อกที่มีขอบเขตเหล่านั้นเปิดเผย

การตรวจสอบที่ชี้ขาดคือตัวแก้ไขอยู่บนเส้นทางที่อุโมงค์ติดตั้งหรือไม่:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

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

ถามตัวแก้ไขของระบบ แล้วจึงถามเซิร์ฟเวอร์

เครื่องมือสามตัวตอบคำถามต่างกันสามข้อ และการสับสนระหว่างกันทำให้เกิดข้อสรุปผิดส่วนใหญ่ในด้านนี้ dscacheutil -q host -a name ผ่านตัวแก้ไขระบบเดียวกับที่แอปพลิเคชันทั่วไปใช้ บล็อกที่มีขอบเขตและบล็อกเสริมจึงมีผล dig ที่ไม่มีอาร์กิวเมนต์เซิร์ฟเวอร์อ่าน /etc/resolv.conf ซึ่งไม่ใช่แหล่งความจริงของการแก้ไขแบบมีขอบเขตบน macOS และข้ามกฎรายโดเมนไปทั้งหมด dig @address ไปถึงเซิร์ฟเวอร์เดียวเท่านั้นและไม่บอกอะไรเกี่ยวกับการเลือก

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

เมื่อคำสั่งแรกตอบและคำสั่งที่สองคืน NXDOMAIN คุณพบการแยกที่ตามหาและไม่มีอะไรเสียหาย เมื่อคำสั่งแรกหมดเวลาในขณะที่ dig @10.20.0.53 ตอบ ตัวแก้ไขทำงานแต่เข้าถึงไม่ได้บนเส้นทางที่อุโมงค์เลือก ดังนั้นขั้นถัดไปคือ route -n get ไม่ใช่การแก้ไขการตั้งค่า DNS เก็บชื่อส่วนตัวไว้นอกทุกสิ่งที่คุณวางในตั๋วหรือโน้ตที่แชร์

สิ่งที่เอาต์พุตบอกคุณไม่ได้

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

คำตอบเก่าเป็นสิ่งที่ตัดออกได้ถูกที่สุดและถูกข้ามบ่อยที่สุด:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

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

คู่มือสั้น ๆ สำหรับก่อนและหลัง

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

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

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

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

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