วิธีตรวจสอบสถานะ IPv6 ของ Mac หลัง VPN ตัดการเชื่อมต่อ

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

เริ่มจากตระกูลที่เสียจริง

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

ใช้เครือข่าย Wi-Fi และจุดเชื่อมต่อเดิมตลอดการเปรียบเทียบ เครือข่ายคาเฟ่ที่เคยให้ IPv6 เมื่อวานไม่ได้บอกอะไรเกี่ยวกับเครือข่ายที่คุณใช้อยู่ตอนนี้

อ่านที่อยู่ก่อนดูเส้นทาง

ในระบบตั้งค่า แผง TCP/IP ของบริการที่ใช้งานอยู่แสดงว่า IPv6 เป็นแบบอัตโนมัติ แบบกำหนดเอง หรือเฉพาะภายในลิงก์ เปรียบเทียบกับสิ่งที่คุณคาดไว้ โดยจำว่าองค์กรอาจเลือกกำหนดค่าเองโดยเจตนา จากนั้นรัน ifconfig แล้วอ่านอินเทอร์เฟซที่เกี่ยวข้อง ที่อยู่ fe80:: เพียงอย่างเดียวหมายความว่าอินเทอร์เฟซคุยกับเพื่อนบ้านได้และไม่มากไปกว่านั้น การมีที่อยู่ภายในลิงก์จึงไม่ใช่หลักฐานของเส้นทางที่ใช้งานได้

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

อ่านตารางเส้นทางสำหรับปลายทางที่ล้มเหลว

ถามเคอร์เนลเกี่ยวกับปลายทางที่ล้มเหลว ไม่ใช่เส้นทางเริ่มต้น route -n get 2001:db8::25 พิมพ์อินเทอร์เฟซและเกตเวย์ที่เลือกสำหรับที่อยู่นั้น และ netstat -rn -f inet6 แสดงตารางทั้งหมดเพื่อเปรียบเทียบ เส้นทางเริ่มต้นบอกว่ามีค่าเริ่มต้นอยู่ แต่ไม่ได้บอกว่าปลายทางนี้ใช้ค่านั้น

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

แยกนโยบายบล็อกของไคลเอนต์ออกจากสิ่งที่ตกค้าง

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

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

เก็บหลักฐาน แล้วเปลี่ยนเพียงอย่างเดียว

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

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