ปิด IPv6 เพื่อแก้การรั่วไหลของ VPN งั้นหรือ? ควรกำหนดนโยบายแทน
ที่อยู่ link-local ไม่ใช่การรั่วไหล และเส้นทาง IPv6 แบบทั่วโลกก็ไม่ใช่เช่นกัน เลือกก่อนว่าจะบล็อก พาไป หรือปล่อยไว้
ที่อยู่จากช่วง IPv6 ปรากฏบนหน้าทดสอบ อุโมงค์เห็นได้ชัดว่าไม่ได้พามันไป และคำแนะนำยอดนิยมที่สุดบนอินเทอร์เน็ตคือปิด IPv6 ทุกที่ คำสั่งนั้นทำให้แผงเงียบลงจริง แต่ก็ลบโปรโตคอลที่เครือข่ายการเข้าถึงอาจต้องพึ่งพา และทิ้งให้คุณไม่รู้ว่าที่อยู่นั้นคือการรั่วไหลจริง ที่อยู่Interfaceแบบ link-local หรือตัวแก้ไขชื่อที่กำลังทำงานของมัน สามเงื่อนไขกำหนดการควบคุมที่ถูกต้อง และมีเพียงหนึ่งเดียวเท่านั้นที่นำไปสู่การบล็อก
ระบุว่าเครื่องมือวัดอะไรจริง ๆ
การเตือนผิดที่พบบ่อยที่สุดคือที่อยู่ link-local ซึ่งเริ่มต้นด้วย fe80: และมีอยู่บนทุกInterfaceที่รองรับ IPv6 ไม่ว่าเครื่องจะเข้าถึงอินเทอร์เน็ตผ่าน IPv6 หรือไม่ มันปรากฏในรายการInterfaceและในการวินิจฉัยแอปพลิเคชันบางตัว และไม่ได้บอกอะไรเกี่ยวกับเส้นทางเดินของทราฟฟิกคุณ
การเตือนผิดตัวที่สองคือที่อยู่ภายในเฉพาะใน fc00::/7 ซึ่งเป็นช่วงส่วนตัวที่ใช้ภายในเครือข่าย เครื่องมือที่พิมพ์ทุกที่อยู่ของโฮสต์จะจัดมันไว้อย่างยินดีข้างที่อยู่สาธารณะ ใครอ่านเร็วก็เรียกมันว่าการรั่วไหล แล้วใช้เวลาหนึ่งชั่วโมงกับปัญหาที่ไม่มีอยู่จริง
ตัวที่สามไม่ใช่การเตือนผิดเลย ที่อยู่ทั่วโลกที่เข้าถึงอินเทอร์เน็ตนอกอุโมงค์คือการรั่วไหลจริง และคุ้มค่าที่จะวัดก่อนตัดสินใจอะไร:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coหากคำสั่งแรกพิมพ์ที่อยู่ทั่วโลกและคำสั่งที่สามคืนที่อยู่ IPv6 สาธารณะที่ไม่ใช่ของอุโมงค์ คุณมีเส้นทางจริงนอกอุโมงค์ หากคำสั่งแรกไม่พิมพ์อะไรเลยนอกจากรายการ link-local ก็ไม่เคยมีการรั่วไหลให้แก้
สามเงื่อนไขกำหนดการควบคุม
การตัดสินใจไม่ใช่ "IPv6 ดี" หรือ "IPv6 แย่" แต่คือคุณอยู่ในสถานการณ์ใดในสามสถานการณ์ และแต่ละอย่างมีคำตอบที่ถูกต้องต่างกันด้วยต้นทุนที่ต่างกันหากคุณตัดสินใจผิด
| Situation | Correct control | Cost if you disable IPv6 instead |
|---|---|---|
| Exit has no IPv6, host does | Block IPv6 deliberately in the tunnel policy | Same visible result, no documentation of intent |
| Exit carries IPv6, host leaks | Route IPv6 into the tunnel and verify | You lose IPv6 reachability entirely |
| Access network is IPv6-only | Change nothing; use the tunnel's IPv6 | Machine loses connectivity completely |
แถวแรกคือสิ่งที่คนมักหมายถึง และมันชอบด้วยเหตุผล ลูกค้าที่ทางออกไม่รองรับ IPv6 ไม่ควรปล่อยทราฟฟิก IPv6 ดั้งเดิมของโฮสต์ออกไปอย่างเงียบ ๆ เพราะนั่นคือการรั่วไหลแบบสองสแตกที่มีเอกสารระบุไว้ ประเด็นคือบล็อกมันเป็นนโยบายที่ประกาศไว้ ไม่ใช่ปิดโปรโตคอลในเคอร์เนล ผลลัพธ์ที่มองเห็นเหมือนกันและมีเพียงหนึ่งเดียวที่ตรวจสอบย้อนหลังได้
แถวที่สามคือจุดที่คำแนะนำแบบเหมารวมกลายเป็นอันตรายจริง ๆ ผู้ให้บริการมือถือและการเชื่อมต่อบ้านบางแห่งเดินเครือข่าย IPv6-only พร้อมการแปลสำหรับปลายทาง IPv4 ถอด IPv6 ที่นั่นออกคุณก็ถอดการขนส่งเดียวที่เครือข่ายมีให้ ซึ่งสร้างความล้มเหลวที่แย่กว่าสิ่งที่คุณกำลังดีบักอยู่มาก
หากทางออกไม่มี IPv6 ให้บล็อกโดยเจตนา
เลือกกลไกของลูกค้าเองเพราะมันใช้ได้ตรงในช่วงที่อุโมงค์ขึ้นและย้อนกลับเมื่ออุโมงค์ล่มOpenVPNมีตัวเลือกสำหรับเรื่องนี้ และ iptables มีกฎที่เทียบเท่าสำหรับลูกค้าอื่น:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableคำสั่งอยู่ในโปรไฟล์ ส่วนกฎอยู่ในไฟร์วอลล์ที่คุณตรวจสอบและถอดออกได้ ทั้งสองล้มเหลวแบบปิด ซึ่งเป็นสิ่งที่คุณต้องการ และทั้งสองมองเห็นได้ใน diff ของการกำหนดค่า ซึ่ง sysctl ของเคอร์เนลที่ฝังในสคริปต์เริ่มต้นไม่เป็นเช่นนั้น
บันทึกว่าเหตุใดมันจึงอยู่ที่นั่น กฎบล็อกที่ไม่มีคอมเมนต์จะถูกถอดออกโดยคนถัดไปที่ต้องการ IPv6 ไปใช้เรื่องอื่น แล้วการรั่วไหลก็กลับมาอย่างเงียบ ๆ
หากทางออกพา IPv6 ไป ให้กำหนดเส้นทางและทดสอบทั้งสองตระกูล
การพา IPv6 ไปเป็นคำตอบที่ดีกว่าเมื่อเซิร์ฟเวอร์รองรับ และไม่ได้ยากขึ้นมากนัก ข้อกำหนดคือInterfaceของอุโมงค์มีที่อยู่ในตระกูลนั้นและเส้นทางเริ่มต้นชี้เข้าไปในอุโมงค์ไม่ใช่ ออกนอกInterfaceกายภาพ:
ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.coการค้นหาเส้นทางคือการทดสอบชี้ขาด หากมันระบุชื่อInterfaceของอุโมงค์ แสดงว่าทราฟฟิก IPv6 ถูกพาไป จากนั้นการเรียก curl สองครั้งยืนยันว่าแต่ละตระกูลเห็นอะไร และการเปรียบเทียบทั้งสองคือวิธีพิสูจน์ว่าทั้งสองเส้นทางออกผ่านทางออกเดียวกันแล้ว
อย่าหยุดเพียงเพราะเชื่อมต่อสำเร็จเชื่อมต่ออุโมงค์ใหม่และตรวจสอบอีกครั้งเพราะเส้นทาง IPv6 ที่ถูกผลักอาจหายไปเมื่อสร้างใหม่หากเซิร์ฟเวอร์ส่งมาเฉพาะในการกำหนดค่าเริ่มต้น จากนั้นตรวจสอบปลายทางที่ถูกยกเว้นหนึ่งแห่ง เพราะกฎ split-tunnel คือจุดที่สองตระกูลเห็นต่างกันบ่อยที่สุด
หากเครือข่ายการเข้าถึงเป็น IPv6 เท่านั้น ให้ปล่อยไว้
บางเครือข่ายให้เฉพาะ IPv6 และคาดว่าอุปกรณ์จะเข้าถึงบริการ IPv4 ผ่านกลไกการแปลทางฝั่งผู้ให้บริการ การปิด IPv6 บนเครื่องเช่นนั้นไม่ใช่การปรับปรุงความปลอดภัย แต่เป็นการถอดเส้นทางเดียวที่จะไปถึงสิ่งใด ๆ นั่นคือความล้มเหลวที่คุณก่อขึ้นเองเพื่อผลการทดสอบที่ไม่มีใครต้องการ
อาการของการทำผิดตรงนี้ชัดเจนและไม่น่าพอใจ อุโมงค์ดูเหมือนจะสร้างขึ้น การแก้ชื่อทำงาน และไม่มีอะไรโหลด หากคุณเห็นสิ่งนี้หลังการเปลี่ยน IPv6 ให้คืนค่าการตั้งค่าทันทีและวินิจฉัยต่อที่อื่น
ไม่ว่าคุณจะเลือกอะไร ให้เก็บการตัดสินใจไว้อย่างชัดเจนในโปรไฟล์หรือไฟร์วอลล์ ผูกมันกับสิ่งที่ทางออกรองรับจริง และบันทึกพฤติกรรมสองสแตกที่การอภิปรายเรื่องสองสแตกของ RFC 7359อธิบายไว้ การบล็อกที่ประกาศไว้คือนโยบาย โปรโตคอลที่ถูกปิดคือทางอ้อมที่ไม่มีใครตรวจสอบได้ และจากหน้าทดสอบทั้งสองดูเหมือนกัน