บล็อกช่วงปลายทางหนึ่งช่วงสำหรับทุกพูลไคลเอนต์ VPN
กฎ nftables เพียงข้อเดียวสามารถปฏิเสธคำนำหน้าปลายทางสำหรับพูล VPN ที่ได้รับอนุญาตได้โดยไม่กระทบการรับส่งของเกตเวย์เอง จับคู่ hook และตำแหน่งให้ถูก
กฎเดียวสามารถกันพูล VPN ที่ได้รับอนุญาตออกจากช่วงปลายทางได้โดยไม่รบกวนอย่างอื่นที่เกตเวย์ทำ กฎเองนั้นสั้น ส่วนที่ตัดสินว่ามันจะได้ผลหรือไม่คือ hook ที่มันอาศัยอยู่และตำแหน่งของมันในเชน หากผิดพลาดสองข้อนี้จะได้ไฟร์วอลล์ที่ดูถูกต้องแต่ทำงานไม่สม่ำเสมอ เริ่มจากสิ่งที่แพ็กเก็ตกำลังทำเมื่อกฎมองเห็นมัน
กฎจับคู่อะไรจริง ๆ
กฎจับคู่สามสิ่งพร้อมกัน คือ อินเทอร์เฟซขาเข้า คำนำหน้าต้นทาง และคำนำหน้าปลายทาง ทั้งสามต้องเป็นจริงก่อนที่ drop จะถูกใช้ และนั่นคือสิ่งที่ทำให้มันแคบ การอ่านเป็นนิพจน์เดียวง่ายกว่าการอ่านเป็นสามนโยบายแยกกัน
การจับคู่อินเทอร์เฟซคือสิ่งที่แยกการรับส่งของไคลเอนต์ที่ถูกส่งต่อออกจากการเชื่อมต่อของเกตเวย์เอง หากไม่มี กฎที่ระบุเพียงพูลต้นทางก็จะกระทบแพ็กเก็ตที่เกตเวย์สร้างเองจากที่อยู่นั้นด้วย หากเกิดขึ้น คำนำหน้าต้นทางจำกัดนโยบายไว้ที่ไคลเอนต์ที่ได้รับอนุญาต และคำนำหน้าปลายทางจำกัดไว้ที่หนึ่งช่วง อ่านกฎเป็นส่วนตัด ไม่ใช่เป็นรายการ
จดค่าทั้งสามไว้ก่อนแก้ไขอะไร คือ ชื่ออินเทอร์เฟซอุโมงค์ พูลที่เซิร์ฟเวอร์แจกจ่าย และคำนำหน้าที่คุณตั้งใจจะปฏิเสธ การพิมพ์ผิดในข้อใดข้อหนึ่งจะได้กฎที่แยกวิเคราะห์ได้สะอาดแต่ไม่ได้ป้องกันอะไรเลย เก็บค่าทั้งสามไว้ในบันทึกการเปลี่ยนแปลงข้างกฎ
hook เป็นตัวกำหนดว่ากฎใช้กับใคร
เชน netfilter ผูกกับ hook และ hook เป็นตัวกำหนดว่าเชนเห็นแพ็กเก็ตใดจริง ๆ hook forward เห็นการรับส่งที่ถูกกำหนดเส้นทางผ่านเกตเวย์ ซึ่งก็คือการรับส่งจากไคลเอนต์ไปยังปลายทางนั่นเอง สิ่งอื่นทั้งหมดในเชนมุ่งไปยังผู้ชมที่ต่างกัน
hook input เห็นการรับส่งที่ส่งถึงเกตเวย์เอง ดังนั้นกฎที่วางไว้ที่นั่นจึงควบคุมการเข้าถึงบริการของมันเอง ไม่ใช่การผ่านทาง ส่วน hook output เห็นการรับส่งที่เกตเวย์สร้างขึ้นเอง ซึ่งตรงข้ามกับสิ่งที่พูลไคลเอนต์ต้องการ ชื่อเชนเป็นป้ายกำกับตามอำเภอใจที่ผู้เขียนชุดกฎเลือกไว้ จึงอย่าเดา hook จากชื่อ ตรวจสอบว่าเชนผูกอยู่ที่ใดก่อนสันนิษฐานว่ามันจับคู่อะไรได้
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
การอ่านจุดผูกคือการตรวจสอบหนึ่งบรรทัดที่กันไม่ให้กฎไปตกในเชนที่ไม่เคยเห็นแพ็กเก็ต
วางกฎไว้ก่อน accept แบบกว้าง
กฎถูกประเมินตามลำดับ และคำตัดสินแรกชนะ accept แบบกว้างที่อยู่ก่อนหน้าในเชนจะจบการประเมินสำหรับแพ็กเก็ตที่มันจับคู่ ดังนั้น drop ที่เพิ่มเข้ามาทีหลังจะไม่ถูกเรียกใช้กับแพ็กเก็ตเหล่านั้นเลย กฎเรื่องลำดับนี้คือเหตุผลทั้งหมดที่กฎซึ่งดูถูกต้องอาจไม่มีผลใด ๆ
แทรกกฎไว้ก่อน accept แทนที่จะต่อท้าย หากเชนมี accept ทั่วไปสำหรับอินเทอร์เฟซอุโมงค์อยู่แล้ว กฎใหม่ต้องอยู่ก่อนหน้ามัน ไม่เช่นนั้นก็เป็นเพียงของประดับ ตรวจสอบลำดับที่ได้ ไม่ใช่ไฟล์ที่คุณแก้ไข เพราะชุดกฎที่ประกอบจากหลายไฟล์อาจไม่ตรงกับไฟล์ใดไฟล์หนึ่ง จากนั้นยืนยันด้วยแพ็กเก็ตทดสอบจากพูล
sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.confคำสั่งที่สามแยกวิเคราะห์ไฟล์โดยไม่นำไปใช้ ซึ่งจับข้อผิดพลาดทางไวยากรณ์ก่อนที่จะกลายเป็นเหตุขัดข้อง ใช้พร้อมแผนย้อนกลับ เพราะกฎที่ผิดในเชน forward อาจตัดอุโมงค์ที่คุณกำลังทำงานอยู่
โฟลว์ที่มีอยู่ไม่สนใจกฎใหม่ของคุณ
รายการ conntrack ที่สร้างก่อนมีกฎจะยังคงตรงกับการยอมรับเดิม นั่นคือเหตุผลที่บางครั้ง drop ใหม่ดูเหมือนได้ผลกับ connection ใหม่ และไม่ทำอะไรกับอันที่กำลังทดสอบ
อ่านการจับคู่สถานะที่ด้านบนของเชน หากมันยอมรับการรับส่ง established และ related ก่อนกฎของคุณ ทุกโฟลว์ที่กำลังดำเนินอยู่จะไหลต่อไปจนกว่าจะปิด โดยปกติแล้วนี่คือพฤติกรรมที่คุณต้องการสำหรับกฎฉุกเฉิน และมันสับสนเมื่อคุณคาดว่าจะตัดขาดทันที ตัดสินใจว่าต้องการผลแบบไหนก่อนติดตั้ง การทดสอบที่ใช้ connection ที่เปิดอยู่ซ้ำจะเล่าเรื่องผิดให้คุณฟัง
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'คำสั่งแรกแสดงว่ามีโฟลว์อยู่หรือไม่ และคำสั่งที่สองแสดงว่ากฎสถานะช่วงต้นยังคงยอมรับมันหรือไม่ ทั้งสองเป็นแบบอ่านอย่างเดียวและปลอดภัยที่จะรันระหว่างเหตุการณ์
สิ่งที่กฎนี้ไม่ใช่
กฎนี้ไม่ใช่บัญชีดำโดเมน ไม่ใช่นโยบาย IPv6 และไม่ใช่ข้อจำกัดของบัญชีแอปพลิเคชันใดบัญชีหนึ่ง
แต่ละอย่างต้องใช้กลไกของตัวเอง การบล็อกโดเมนต้องแปลงชื่อ ซึ่งตัวกรองแพ็กเก็ตไม่ได้ทำ การรับส่ง IPv6 ต้องมีการจับคู่ของตัวเอง เพราะนิพจน์ ip ไม่ได้บอกอะไรเกี่ยวกับแพ็กเก็ต ip6 ข้อจำกัดระดับแอปพลิเคชันเป็นของบริการหรือพร็อกซีที่ผ่านการพิสูจน์ตัวตน ไม่ใช่ของการจับคู่คำนำหน้า การแยกข้อกำหนดเหล่านี้ออกจากกันคือสิ่งที่กันไม่ให้กฎแคบ ๆ ข้อเดียวถูกขอให้ทำงานสี่อย่าง
สัญญาที่กฎนี้ให้มานั้นแม่นยำ คือ การรับส่งจากพูลที่ได้รับอนุญาตไปยังคำนำหน้าปลายทางหนึ่งช่วงจะถูกปฏิเสธ ขณะที่การรับส่งของเกตเวย์ที่ไม่เกี่ยวข้องยังคงนโยบายเดิม เขียนประโยคนั้นไว้ข้างกฎ แล้วคนถัดไปจะรู้ว่ามันมีไว้เพื่ออะไร