nftables: แทรกกฎอนุญาต VPN ก่อนแฮนเดิล drop

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

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

สองตำแหน่ง สองผลลัพธ์ที่ต่างกัน

insert วางกฎไว้ก่อนกฎที่อ้างถึง add วางไว้หลังจากนั้น หากกฎที่อ้างถึงคือ drop สุดท้ายของโฟลว์ สองคำสั่งนี้ให้ผลตรงกันข้ามแม้ข้อความของกฎจะเหมือนกัน

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

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

แฮนเดิลระบุกฎ ไม่ใช่หมายเลขบรรทัด

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

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

iptables --version
nft -a list ruleset

เวอร์ชันของ iptables บอกว่าใช้แบ็กเอนด์ใด ชุดกฎ iptables-nft กับตารางเนทีฟที่จัดการแยกกันสามารถอยู่ร่วมกันได้ ดังนั้นรายการจากฟรอนต์เอนด์เดียวจึงไม่ใช่ภาพการกรองที่สมบูรณ์โดยอัตโนมัติ ตรวจทั้งสองมุมมองก่อนเลือกเชน

ค้นหาเชนและกฎที่ drop จริง

อ่าน hook ขาเข้า ลำดับความสำคัญของเชน และกฎที่ปฏิเสธโฟลว์ของผู้ฟังนี้ ตาราง inet อาจมีทั้งสองตระกูลแอดเดรส แต่กฎแต่ละข้ออาจยังตรงกับ IPv4 เท่านั้น

เลือกเพียร์ที่อนุมัติแล้วหนึ่งตัว โดยใช้ 198.51.100.25 จากช่วงเอกสารเป็นตัวอย่าง ไฟล์เนทีฟที่ตรวจทานแล้วอาจวางการอนุญาตภายนอกไว้ก่อนแฮนเดิล 42:

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

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

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

การอนุญาตมีขอบเขต drop เป็นจุดสิ้นสุด

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

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

กฎนั้นครอบคลุมเฉพาะการแลกเปลี่ยนของผู้ฟังภายนอก ESP ที่ห่อหุ้มด้วยการขนส่ง ESP แบบเนทีฟ เพียร์ IPv6 และทราฟฟิกที่ถอดรหัสแล้วภายในอุโมงค์ต่างต้องมีนโยบายของตนเอง นี่ไม่ใช่ไฟร์วอลล์ VPN ของไซต์ที่สมบูรณ์.

ตรวจไฟล์ แล้วยืนยันผลลัพธ์ที่ทำงานอยู่

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

nft -c -f reviewed-vpn-rule.nft

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

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