iptables: ให้ไคลเอนต์ VPN เข้าถึงโฮสต์เดียวเท่านั้น

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

เชนใดตอบคำถามของคุณ

แพ็กเก็ตที่ไคลเอนต์ VPN ส่งไปยังโฮสต์ใน LAN หรือต่อไปยังอินเทอร์เน็ต เคอร์เนลจะส่งต่อและประเมินใน FORWARD ส่วน INPUT และ OUTPUT เห็นเพียงทราฟฟิกที่สิ้นสุดที่เซิร์ฟเวอร์เองหรือเริ่มจากเซิร์ฟเวอร์ การปฏิเสธทุกสิ่งที่ไม่มาถึง tun0 จึงปกป้องตัวรับฟังของเซิร์ฟเวอร์เอง และจะตัดเซสชัน SSH ของคุณด้วย เว้นแต่จะอนุญาตโฟลว์ที่สร้างไว้ก่อน สิ่งนี้ไม่เปลี่ยนว่าไคลเอนต์ได้รับอนุญาตให้ไปที่ใด

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

สถานะก่อน จากนั้นจึงอนุญาต จากนั้นจึงปฏิเสธ

รายการที่อนุญาตจะได้ผลก็ต่อเมื่อสิทธิ์เฉพาะอยู่เหนือการปฏิเสธทั่วไป และเมื่อทราฟฟิกขากลับได้รับอนุญาตเหนือทั้งสอง แทรกกฎในตำแหน่งที่ชัดเจน แล้วดัมป์เชนด้วย iptables -S FORWARD เพื่อให้ลำดับมองเห็นได้แทนที่จะสันนิษฐาน

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

รายละเอียดสองอย่างตัดสินว่าสิ่งนี้จะทนต่อการปะทะกับทราฟฟิกจริงหรือไม่ หากไม่มีกฎสถานะ คำตอบสำหรับการเชื่อมต่อที่คุณเพิ่งอนุญาตจะถูกประเมินกับการปฏิเสธและถูกทิ้งไปเอง กฎ LOG ที่ไม่มีขีดจำกัดอาจเติมพาร์ทิชันเล็ก ๆ ได้ตั้งแต่สแกนครั้งแรก จึงเพิ่ม -m limit --limit 10/min ก่อนจะบันทึกต่อ REJECT คืนข้อผิดพลาดทันทีซึ่งเป็นมิตรกว่าในขณะปรับรายการ ส่วน DROP ทิ้งอย่างเงียบ ๆ ทุกความผิดพลาดจึงดูเหมือนหมดเวลา เลือกอย่างใดอย่างหนึ่งโดยตั้งใจและเขียนตัวเลือกนั้นลงในบันทึกการเปลี่ยนแปลง

การส่งต่อและ NAT ต้องทำงานอยู่แล้ว

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

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

บล็อกอีเมลอยู่ที่เชนถัดไป

การบล็อกพอร์ต 25 ใน INPUT หยุดเฉพาะอีเมลที่ส่งถึงเซิร์ฟเวอร์ VPN ไคลเอนต์ที่ถูกบุกรุกและส่งอีเมลผ่านอุโมงค์จะถูกส่งต่อ จึงต้องวางบล็อกไว้ใน FORWARD ข้างพอร์ต 465 และ 587 หากแอปพลิเคชันหนึ่งส่งต่ออีเมลอย่างชอบธรรม ให้วางปลายทางและพอร์ตไว้เหนือกฎนั้น

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

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

อ่านกลับแล้วพิสูจน์จากไคลเอนต์

อ่านชุดกฎตามที่เคอร์เนลรายงาน ไม่ใช่ตามที่สคริปต์ของคุณเขียน เริ่มด้วย iptables -S FORWARD จากนั้นตาราง NAT ด้วย iptables -t nat -L POSTROUTING -n -v จากนั้นรายการ conntrack ของโฟลว์ที่คุณกำลังทดสอบ เก็บคำสั่งย้อนกลับหรือการล้างตามกำหนดไว้ตลอดเวลาที่ทำงาน ทุกการเรียกต้องมี -w มิฉะนั้นผู้ดูแลสองคนจะชนกันที่ล็อก xtables ไม่มีข้อใดในนี้เป็นทางเลือกในช่วงหน้าต่างการเปลี่ยนแปลง

ปิดท้ายด้วยการทดสอบจากไคลเอนต์ในกลุ่มและจากไคลเอนต์นอกกลุ่ม กฎที่ทำงานได้เฉพาะจากเครื่องที่คุณพิมพ์ไม่ได้เป็นนโยบาย