โซน Shorewall สำหรับสองเส้นทางของแพ็กเก็ต OpenVPN
แยกการขนส่ง OpenVPN ที่เข้ารหัสออกจากทราฟฟิกไคลเอนต์ที่ถอดรหัสแล้ว ให้โซนของตัวเองแก่ทันเนล และอนุญาตเฉพาะบริการเดียวที่ไคลเอนต์ต้องการ
กระแสแพ็กเก็ตสองสายผ่านเกตเวย์ Shorewall ที่สิ้นสุด OpenVPN และมีเพียงสายเดียวเท่านั้นที่เข้ารหัส สายแรกคือการขนส่งของไคลเอนต์ไปยังตัวรับฟัง VPN บนอินเทอร์เฟซที่หันสู่อินเทอร์เน็ต สายที่สองคือคำขอที่ถอดรหัสแล้วซึ่งออกจากอินเทอร์เฟซของทันเนลไปยังเซิร์ฟเวอร์สำนักงานหรือบริการบนเกตเวย์ วาดทั้งสองสายก่อนแก้ไขนโยบาย เพราะกฎที่ตอบสนองสายแรกไม่ทำอะไรกับสายที่สอง
วาดกระแสทั้งสองสายก่อนแก้ไขนโยบาย
เขียนกระแสเป็นแถวที่มีต้นทาง ปลายทาง โพรโทคอล และพอร์ต บนเส้นทางภายนอก ต้นทางคือที่อยู่สาธารณะของไคลเอนต์และปลายทางคือพอร์ตรับฟังของเกตเวย์ Shorewall ถือว่าสิ่งนั้นเป็นทราฟฟิกจากอินเทอร์เน็ตไปยังไฟร์วอลล์ บนเส้นทางภายใน ต้นทางคือช่วงที่อยู่ของทันเนลและปลายทางคือบริการที่อนุมัติแล้ว สองแถวมีเจ้าของต่างกันแม้ผู้ดูแลคนเดียวจะดูแลทั้งสอง
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
เพิ่มแถวเฉพาะเมื่อคำขอสิ้นสุดที่เกตเวย์เอง เช่น การเข้าถึงตัวแก้ไขชื่อหรือการจัดการ บริการบนโฮสต์เป็นไปตามนโยบายขาเข้าของโฮสต์ ไม่ใช่เส้นทางที่ส่งต่อ การผสมทั้งสองอย่างนี้เองที่ทำให้กฎทันเนลที่แคบเปิดเผยอินเทอร์เฟซการจัดการ
กำหนดโซนของทันเนลและขอบเขตของอินเทอร์เฟซ
โซนของนักเดินทางถูกประกาศใน /etc/shorewall/zones อินเทอร์เฟซของทันเนลถูกผูกใน /etc/shorewall/interfaces และการเชื่อมต่อภายนอกถูกอธิบายใน /etc/shorewall/tunnels ปรับให้เข้ากับไวยากรณ์ของรุ่นที่ติดตั้ง เพราะลำดับคอลัมน์และชื่อตัวเลือกเปลี่ยนไประหว่างรุ่นหลัก พอร์ตตัวอย่างในคู่มือไม่ใช่เหตุผลให้อนุญาตพอร์ตอื่นนอกจากพอร์ตที่แดมอนรับฟังจริง TCP และ UDP ใช้แทนกันไม่ได้เพียงเพราะตัวเลขตรงกัน
คู่มือจัดกลุ่มอินเทอร์เฟซด้วย tun+ บนโฮสต์ที่มีทันเนลมากกว่าหนึ่ง สัญลักษณ์ไวลด์การ์ดนั้นอาจวาง VPN ที่สองซึ่งมีระดับความเชื่อถือต่างกันไว้ในโซนเดียวกัน ตรวจสอบขอบเขตเทียบกับอินเทอร์เฟซที่มีอยู่จริง และรักษาการตั้งชื่อไว้ภายใต้วงจรชีวิตของผู้จัดการการเชื่อมต่อแทนการแก้ไขชื่ออินเทอร์เฟซด้วยมือ
คู่มือเชิงประวัติมีตัวอย่างการกำหนดค่า OpenVPN ที่เก่ากว่ามาก และคำแนะนำด้านการเข้ารหัสไม่ควรถูกคัดลอกไปยังการติดตั้งปัจจุบัน ยืมรูปแบบโซนและกระแสแทน นำพื้นฐานการเข้ารหัสมาจากนโยบาย OpenVPN ที่ดูแลอยู่บนเกตเวย์
อนุญาตเฉพาะเส้นทางที่คุณจำแนกแล้ว
การยอมรับแบบกว้างจากโซน VPN ไปยัง LAN เป็นแผนภาพเริ่มต้น ไม่ใช่นโยบายที่เสร็จแล้ว เขียนต้นทางไคลเอนต์ที่อนุญาต ที่อยู่จริงของบริการ โพรโทคอล และพอร์ต จากนั้นอ่านกฎที่อยู่เหนือขึ้นไปและค่าเริ่มต้นของโซน เพราะการเพิ่มแบบแคบไม่ยกเลิกการอนุญาตแบบกว้างที่ตรงอยู่แล้ว ทราฟฟิกไปยังโฮสต์ของเกตเวย์เป็นความสัมพันธ์แยกจากทราฟฟิกที่ส่งต่อผ่านมัน
ทราฟฟิกระหว่างไคลเอนต์ต้องมีการตัดสินใจของตัวเอง client-to-client ของ OpenVPN และ routeback ของ Shorewall ต่างส่งผลว่าไคลเอนต์จะเข้าถึงกันได้หรือไม่ และไม่ควรเปิดใช้งานใด ๆ เพียงเพื่อให้แอปพลิเคชัน LAN หนึ่งทำงาน ตัดสินใจว่าจะบังคับใช้การแยกที่ใดก่อนทดสอบ
เก็บเส้นทางตอบกลับไว้ในแผนเดียวกัน บริการหรือเราเตอร์ของบริการต้องรู้วิธีส่งทราฟฟิกกลับไปยังช่วงของทันเนล หรือการออกแบบต้องแปลงต้นทางอย่างตั้งใจและภายในขอบเขตที่ตั้งใจ
ตรวจสอบ แล้วพิสูจน์ทั้งสองเส้นทาง
ตรวจสอบการกำหนดค่าก่อนรีสตาร์ตสิ่งใด และเปิดเซสชันการจัดการที่เป็นอิสระไว้ในกรณีที่นโยบายใหม่ผิด
shorewall checkหลังการตรวจสอบที่สะอาดแล้ว ให้ใช้การกำหนดค่าและอ่านกลับสิ่งที่ Shorewall โหลด การอ่านเหล่านี้บรรยายนโยบายที่กำลังทำงาน ไม่ใช่สิ่งที่ไฟล์ดูเหมือนจะพูด
shorewall show zones
ip route get 192.168.10.20ทดสอบคำขอที่อนุญาตใหม่หนึ่งรายการและคำขอที่ถูกปฏิเสธโดยตั้งใจหนึ่งรายการจากไคลเอนต์เดียวกัน การจับมือ OpenVPN ที่สำเร็จพิสูจน์เพียงการแลกเปลี่ยนภายนอก บริการที่อนุญาตและทรัพยากรที่ถูกปฏิเสธพิสูจน์นโยบายภายในที่คุณตั้งใจ จากนั้นเชื่อมต่อไคลเอนต์ใหม่และทำซ้ำ เพราะชื่อและที่อยู่ของอินเทอร์เฟซทันเนลอาจเปลี่ยนระหว่างเซสชัน หากผลลัพธ์ต่างออกไป ให้แก้ขอบเขตของโซนแทนการขยายกฎ