การบล็อก IPv6 เพื่อรักษาความปลอดภัย WireGuard ทำให้โฮสต์พัง

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

สามความรับผิดชอบ ชุดกฎเดียว

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

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

เก็บไว้ในเชนแยกหรืออย่างน้อยความคิดเห็นแยก เพื่อให้คนถัดไปเห็นว่าบรรทัดใดมีอยู่เพราะอะไร

ICMPv6 ทำอะไรให้โฮสต์

IPv6 พึ่งพา ICMPv6 มากกว่าการตอบกลับ echo มาก การร้องขอและการประกาศเพื่อนบ้านแทนที่ ARP และจำเป็นต่อการส่งมอบในท้องถิ่น Packet Too Big พาข้อมูล MTU ของเส้นทาง และการเพิกเฉยจะทำให้การถ่ายโอนติดขัดกับแพ็กเก็ตขนาดใหญ่ การประกาศของเราเตอร์พาเส้นทางเริ่มต้นและข้อมูลคำนำหน้าเมื่อลิงก์ใช้การกำหนดค่าอัตโนมัติ

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

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

การแทนที่ทั้งหมดด้วยการอนุญาต ICMPv6 แบบเหมารวมแก้ปัญหาเรื่องความพร้อมใช้งานแต่ยอมสละการกรอง การแทนที่ด้วยการทิ้งแบบเหมารวมแก้ปัญหาเรื่องการกรองแต่ยอมสละโฮสต์

อนุญาต tunnels ก่อน แล้วจึงอนุญาตบริการ

ยอมรับการขนส่ง WireGuard บนที่อยู่ภายนอกและพอร์ต UDP ที่ตั้งใจ และยอมรับทราฟฟิกขากลับผ่านการติดตามการเชื่อมต่อ จากนั้นอนุญาตบริการแอปพลิเคชันผ่านอินเทอร์เฟซ tunnels จากแหล่งที่คุณอนุญาตจริง ๆ

การอนุญาตสำหรับพอร์ต UDP ภายนอกไม่ได้อนุญาตคำขอที่ถอดรหัสแล้วภายใน ความแตกต่างนี้คือเหตุผลทั้งหมดที่อินเทอร์เฟซ tunnels ปรากฏในกฎบริการ

อ่านชุดกฎตามที่มีอยู่ ไม่ใช่ตามที่ไฟล์อธิบาย:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

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

ทดสอบลิงก์ ไม่ใช่แค่ tunnels

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

ตรวจสอบการเชื่อมต่อโดยตรง แล้วตรวจว่าเส้นทางที่ยกเว้นยังล้มเหลวอยู่:

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

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

กู้คืนโฮสต์ที่คุณล็อกตัวเองออกไป

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

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

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