กฎของตัวรับฟังใน firewalld เทียบกับนโยบายการส่งต่อ: แต่ละอย่างทำอะไร

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

สองนโยบาย หนึ่งอุโมงค์

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

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

อนุญาตตัวรับฟังภายนอกที่แท้จริง

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

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

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

อนุญาตปลายทางที่ถอดรหัสแล้วแยกต่างหาก

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

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

ทำไมการไว้วางใจอินเทอร์เฟซจึงเป็นทางลัดที่ผิด

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

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

ตรวจสอบสามอย่าง รวมถึงการปฏิเสธหนึ่งอย่าง

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

บันทึกโซน พอร์ต การรับส่ง และออบเจกต์นโยบายไว้ในบันทึกของเซิร์ฟเวอร์ มิฉะนั้นการเปลี่ยนแปลงครั้งถัดไปบนโฮสต์นี้จะเริ่มจากสมมติฐานเดิม