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

เส้นทางข้อมูลและเส้นทางตัวแปลงแยกจากกัน

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

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

หาให้ได้ว่ากระบวนการใดเป็นผู้ถามคำถาม

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

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

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

ตัดสินว่าใครเห็นชื่อใด

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

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

อย่าเขียนทุกฟิลด์ DNS ใหม่เพื่อให้ป้ายทดสอบหนึ่งป้ายเป็นสีเขียว ป้ายอธิบายคำถามหนึ่งคำถามจากกระบวนการหนึ่ง ณ ขณะหนึ่ง

ตรวจสอบคำถามและการเชื่อมต่อแยกกัน

ทดสอบสองเส้นทางแยกกัน การทดสอบการเชื่อมต่อแสดงเส้นทางข้อมูล และการทดสอบตัวแปลงแสดงว่าใครได้รับชื่อ

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

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

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

บทความที่เกี่ยวข้อง