จำกัดเกตเวย์ OpenVPN ให้อยู่เพียง LAN เดียวด้วยกฎ UFW

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

เขียนโครงสร้างเครือข่ายและการอนุญาตลงไปก่อน

ตัวอย่างใช้อุปกรณ์ TUN ในพื้นที่ผู้ใช้ชื่อ ในเซิร์ฟเวอร์ Community OpenVPNtun0 พูลไคลเอนต์ 10.77.0.0/24 และซับเน็ตที่เชื่อมต่อหนึ่งซับเน็ต 192.168.60.0/24 บน lan0 การส่งต่อ IPv4 ทำงานอยู่แล้วและ LAN มีเส้นทางกลับไปยังพูลอยู่แล้ว ดังนั้นไม่มีสิ่งใดที่นี่ขึ้นกับการแปลระหว่างทั้งสอง

ไฟร์วอลล์บนโฮสต์นี้เป็นของ UFW และไม่มีชุดกฎของคอนเทนเนอร์หรือตาราง nftables แยกใดติดตั้งเส้นทางยอมรับที่เร็วกว่าได้ เส้นทางลัดแบบถ่ายทราฟฟิกออกจะข้ามตัวกรองและทำให้กฎลูกโซ่เฝ้าระวังเป็นเพียงของประดับ ดังนั้นตรวจสอบว่าไม่มีตัวใดทำงานอยู่ ปล่อยการส่งต่อ client-to-client ของ OpenVPN เองให้ปิดอยู่ เพราะ ทราฟฟิกระหว่างเพียร์ที่ไม่เคยผ่านตัวกรองของระบบปฏิบัติการ ไม่สามารถจำกัดได้ด้วยการส่งต่อนั้น ตัวรับฟังภายนอกและกฎการบริหารยังคงอยู่ตามเดิม เนื่องจากการเปลี่ยนแปลงนี้ควบคุมทราฟฟิกทันเนลที่ถอดรหัสแล้วแทนที่จะแทนที่ไฟร์วอลล์

วางตัวเฝ้าระวังไว้ก่อนการยอมรับช่วงต้นของ UFW

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

ในส่วน *filter ของไฟล์ /etc/ufw/before.rules ประกาศสองลูกโซ่ข้างการประกาศที่มีอยู่และก่อนบรรทัดกฎใด ๆ

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

ทันทีหลังการประกาศ และก่อนการอนุญาตสำหรับขาเข้าและการส่งต่อ ให้กระโดดเข้าไปและกำหนดว่าอนุญาตสิ่งใด

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

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

อ่านว่าตัวเฝ้าระวังแต่ละตัวอนุญาตและปฏิเสธสิ่งใด

ลูกโซ่แรกจะประมวลผลต่อก็ต่อเมื่อต้นทางอยู่ในพูล ปลายทางคือซับเน็ตเดียวนั้น อินเทอร์เฟซขาออกคือ LAN และแพ็กเก็ตเดินทางในทิศทางเดิมของทราฟฟิกนั้น สิ่งอื่นทั้งหมดที่มาจากทันเนลจะถูกทิ้ง รวมถึงต้นทางนอกพูลและปลายทางใดที่อยู่เกินซับเน็ตที่อนุญาต

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

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

อนุญาตซับเน็ตและปิดประตูด้านข้าง

ดูตัวอย่างการอนุญาตเส้นทางก่อน แล้วจึงถอดแฟล็กดูตัวอย่างเพื่อนำไปใช้: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. หลังจากนั้นตรวจทานลำดับกฎของผู้ใช้ เพราะการปฏิเสธที่มาก่อนยังชนะการอนุญาตที่มาทีหลัง การอนุญาตทั้งซับเน็ตก็เป็นรูปแบบที่ผิดเมื่อ ควรเข้าถึงได้เฉพาะพอร์ต HTTPS ของโฮสต์เดียวเท่านั้น

สังเกตว่าการทิ้งขาเข้าทำอะไร: ไคลเอนต์ของทันเนลเข้าถึงบริการใดบนเกตเวย์เองไม่ได้ รวมถึงตัวรับฟัง DNS ที่ผูกกับแอดเดรส LAN ของมัน การโฮสต์ DNS ที่นั่นต้องมีข้อยกเว้นที่ตั้งใจก่อนการทิ้ง และสัญญาการอนุญาตที่ปรับปรุงใหม่ หาก UFW จัดการ IPv6 ให้เพิ่มการทิ้งที่สอดคล้องสำหรับ tun0 ในไฟล์ before6.rules ด้วย เพราะรายการปลายทาง IPv4 ไม่ได้บอกอะไรเกี่ยวกับแพ็กเก็ต IPv6

ตรวจสอบนโยบายที่โหลดแล้ว ไม่ใช่ตัวอย่าง

ดูตัวอย่างการโหลดใหม่ นำไปใช้ในช่วงเวลาบำรุงรักษา และอ่านชุดกฎที่ใช้งานจริง

sudo ufw --dry-run reload
sudo ufw show raw

ยืนยันว่าตัวเฝ้าระวังทันเนลปรากฏก่อนการอนุญาตสถานะและ ICMP ตามค่าเริ่มต้น ufw status ธรรมดาไม่แสดงกฎ before ที่แก้ด้วยมือ ซึ่งเป็นเหตุให้ผู้ดูแลสรุปว่ากฎหายไปทั้งที่โหลดอยู่จริง อ่านรายการดิบจากบนลงล่างแทนการค้นหาชิ้นส่วน หากตัวเฝ้าระวังปรากฏหลังการอนุญาตสถานะ เขตแดนไม่ได้ทำอย่างที่ไฟล์บอก

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

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