VLAN Gateway ก่อน แล้วจึงตัดสินใจทางออก VPN

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

ขั้นแรก: หาเกตเวย์ที่แต่ละ VLAN ใช้

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

ip route show default
show ip interface brief

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

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

ขั้นที่สอง: ตัดสินใจว่านโยบายภายในอยู่ที่ใด

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

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

สิ่งที่สำคัญคือนโยบายที่เลือกอยู่บนเส้นทางที่แพ็กเก็ตไปจริงหรือไม่

ขั้นที่สาม: ให้อุปกรณ์ทั้งสองมีทรานซิตเดียว

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

# on the switch
ip route 0.0.0.0/0 10.255.0.2
# on the firewall
ip route add 10.20.10.0/24 via 10.255.0.1
ip route add 10.20.20.0/24 via 10.255.0.1

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

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

ขั้นที่สี่: เลือกทางออกจากแหล่งที่มาที่มาถึง

ด้วยการกำหนดเส้นทางปกติและไม่มีการแปลแหล่งที่มาในระหว่าง ไฟร์วอลล์ได้รับที่อยู่เดิมของพนักงานหรือแล็บบนอินเทอร์เฟซทรานซิต ทั้งสอง VLAN มาถึงผ่านลิงก์เดียว และอัตลักษณ์ IP ของทั้งคู่ยังคงอยู่

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

เก็บปลายทางภายในไว้นอกกฎทางออกที่กว้างเกินไป และตรวจสอบรุ่นเกตเวย์ที่รองรับสำหรับรีลีสที่คุณใช้งาน

ขั้นที่ห้า: พิสูจน์ทั้งสองเส้นทาง

เขียนผลลัพธ์เป็นสองประโยค: ทราฟฟิกพนักงานไปยังปลายทางที่อนุมัติออกผ่านทางออก A และทราฟฟิกแล็บไปยังปลายทางที่อนุมัติออกผ่านทางออก B เพิ่มเส้นทางย้อนกลับ กฎการแปล และพฤติกรรมที่ตั้งใจเมื่อทางออกหนึ่งล่ม

traceroute -n 198.51.100.10

จากนั้นทดสอบบริการภายในระหว่าง VLAN แยกต่างหาก เพราะมันฝึกการตัดสินใจอีกอย่างในดีไซน์เดียวกัน

โฟลว์ใหม่จากแต่ละ VLAN บริการภายในที่ทำงานได้ และเส้นทางความล้มเหลวที่มีเอกสารประกอบ ร่วมกันพิสูจน์ดีไซน์ ping ที่สำเร็จเพียงครั้งเดียวพิสูจน์เพียงว่ามีเส้นทางหนึ่งอยู่ในขณะนั้น