คิลสวิตช์บล็อกเฉพาะ IPv4: ทำไม IPv6 ยังหลุดออกไป

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

อุปกรณ์ dual-stack มีทางออกสองทางที่เป็นอิสระจากกัน การบล็อกเพียงทางเดียวคือการบล็อกครึ่งเดียว

สองชุดกฎ สองค่าเริ่มต้น

บน Linux นั้น iptables และ ip6tables เป็นตารางแยกกันที่มีนโยบายแยกกัน การตั้งเชน INPUT และ OUTPUT ของตาราง IPv4 เป็น DROP ไม่ได้เปลี่ยนอะไรในตาราง IPv6 ซึ่งค่าเริ่มต้นมักเป็น ACCEPT การแยกแบบเดียวกันมีอยู่ใน nftables ซึ่งคุณสามารถตรวจสอบตระกูลหนึ่งและพบว่ามีเพียงตระกูลเดียวที่บรรทุกกฎของคุณ ความไม่สมมาตรนี้เป็นเรื่องปกติ และนั่นคือปัญหาทั้งหมด

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

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

สิ่งที่การกำหนดค่าอินเทอร์เฟซบอกคุณ

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

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

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

หากคำสั่งที่สองพิมพ์นโยบายที่อนุญาตในขณะที่คำสั่งแรกพิมพ์ DROP คุณก็พบคำตอบโดยไม่ต้องแตะไคลเอนต์ ความไม่สมมาตรนั้นคือบั๊ก

ทำไมการค้นหาครั้งเดียวจึงไม่ใช่เรื่องทั้งหมด

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

การเปลี่ยนเครือข่ายก็เปลี่ยนคำตอบเช่นกัน การเชื่อมต่อกับเครือข่าย Wi-Fi อื่น การตื่นจากโหมดสลีป หรือการสลับไปใช้เซลลูลาร์อาจให้คำนำหน้า IPv6 ใหม่แก่อุปกรณ์ และนโยบายที่ดูเพียงพอใน LAN ของสำนักงานอาจไม่ครอบคลุมมัน

ทดสอบสถานะที่อุโมงค์ปิดอยู่

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

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

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

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