OpenVPN ฮับหนึ่งตัวกับสาม LAN: แผนที่อยู่และไฟล์ iroute

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

ทำตามขั้นตอนตามลำดับ แต่ละขั้นขึ้นอยู่กับแผนของขั้นก่อนหน้า และไม่มีขั้นใดต้องใช้หน่วยงานออกใบรับรองใหม่

เริ่มจากแผนที่ไม่มีใครต้องเดา

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

แผนตัวอย่างเก็บพูลให้ห่างจากสาม LAN พอสมควร ของคุณจะแตกต่างออกไป และกฎตายตัวข้อเดียวคือไม่มีสองช่วงที่ทับกัน

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

บอกเคอร์เนลของฮับว่าสาขาอยู่ที่ไหน

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

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

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

ให้เส้นทางที่แต่ละสาขาต้องการ

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

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

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

ทดสอบทั้งสองทิศทางก่อนประกาศว่าเสร็จ

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

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

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

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