วิธีสร้างนโยบาย VPN failover บนเราเตอร์โดยไม่ให้ข้อมูลรั่ว
ตัดสินใจว่าเมื่ออุโมงค์ที่ต้องการล่ม ทราฟฟิกควรทำอะไร: อุโมงค์สำรอง WAN ธรรมดา หรือบล็อก จากนั้นสร้างและทดสอบบนเราเตอร์
การสลับสำรองทำงานตรงตามที่กำหนดค่าไว้ และนั่นคือปัญหา เมื่ออุโมงค์หลักล่ม เราเตอร์ย้ายเส้นทางเริ่มต้นไปยังโมเด็มเคเบิล แล็ปท็อปยังคงท่องเว็บ และไม่มีใครโทรมา สองวันต่อมามีคนสังเกตว่าโฟลเดอร์การเงินเข้าถึงได้ผ่านเส้นทางอินเทอร์เน็ตแบบเปิดเป็นเวลาหกชั่วโมง นโยบาย VPN failover บนเราเตอร์ไม่ใช่กลเม็ดการกำหนดเส้นทาง แต่เป็นการตัดสินใจว่าทราฟฟิกควรทำอะไรเมื่อเส้นทางที่ต้องการหายไป และการตัดสินใจนั้นต้องมีอยู่ก่อนเส้นทางจะหายไป
ตัดสินผลลัพธ์ก่อนเลือกตัวตรวจจับ
โดยปกติมีสามผลลัพธ์บนโต๊ะ: ส่งไคลเอนต์ที่ได้รับผลกระทบผ่านอุโมงค์สำรอง ปล่อยให้ใช้ WAN ธรรมดา หรือบล็อกทั้งหมด เขียนว่าข้อใดใช้กับ VLAN, SSID หรือประเภทอุปกรณ์ใด กฎแบนๆ ข้อเดียวว่า «สลับไป WAN» คือเหตุที่โฟลเดอร์การเงินข้างต้นไปอยู่บนเส้นทางสาธารณะ
ทั้งสามไม่สามารถใช้แทนกันได้ การกลับไปที่ WAN ทำให้ฝ่ายสนับสนุนยังรับโทรศัพท์ได้ แต่เปิดเผยชื่อภายในต่อตัวแก้ชื่อภายในเครื่อง อุโมงค์สำรองรักษานโยบายไว้ แต่อาจไปลงที่อยู่ทางออกที่ฝั่งไกลไม่ยอมรับ การบล็อกเหมาะกับ VLAN เงินเดือนและไม่เหมาะกับเครือข่ายแขกที่ไม่เคยใช้อุโมงค์เลย
| Outcome | Right for | What breaks |
|---|---|---|
| Backup tunnel | Policy must hold, remote access required | New exit address, return route, slower rekey |
| Plain WAN | Guest or public-only traffic | Internal names, DNS and IPv6 exposure |
| Block | Payroll, admin, anything VPN-only | Users lose all access and call you |
จับคู่ตัวตรวจจับกับความล้มเหลวที่คุณกลัวจริงๆ
สถานะแฮนด์เชก สถานะอินเทอร์เฟซ และการส่งต่อที่ใช้งานได้เป็นสัญญาณสามอย่างที่ต่างกัน และมีเพียงอย่างสุดท้ายที่ผู้ใช้สนใจ WireGuard peer อาจแสดงแฮนด์เชกล่าสุดในขณะที่ต้นน้ำของผู้ให้บริการทิ้งแพ็กเก็ต ไคลเอนต์ OpenVPN อาจค้างที่ «เชื่อมต่อแล้ว» หลังจากเส้นทางที่มันดันไว้หยุดแก้ชื่อ
บน pfSense การจัดวางที่ใช้ได้จริงคือกลุ่มเกตเวย์ที่ป้อนโดย dpinger ซึ่งตรวจสอบที่อยู่สำหรับเฝ้าดูและทำเครื่องหมายเกตเวย์ว่าล่มเมื่อการสูญหายหรือความหน่วงเกินเกณฑ์ ตั้งเป้าการเฝ้าดูนั้นไปที่บางสิ่งนอกอุโมงค์ เช่นโฮสต์ใน LAN ไกลหรือที่อยู่สาธารณะที่เข้าถึงได้ผ่านอุโมงค์ การเล็งไปที่ที่อยู่ peer ของอุโมงค์เองจะวัดส่วนที่คุณรู้อยู่แล้วว่ายังมีชีวิต
สร้างกลุ่มเพื่อให้ตัวสำรองยังเป็นทางเลือกสุดท้าย
ใช้ชั้นแทนรายชื่อสมาชิกแบนๆ ชั้นเดียว ตัวหลักในชั้น 1 อุโมงค์สำรองในชั้น 2 WAN ในชั้น 3 เฉพาะ VLAN ที่นโยบายอนุญาต บน pfSense อยู่ใต้ System > Routing > Gateway Groups: เพิ่มเกตเวย์ทั้งสอง กำหนดชั้นต่างกัน ตั้ง Trigger Level เป็นสมาชิกล่มบวกการสูญหายของแพ็กเก็ต บันทึก แล้วใช้กลุ่มเป็นค่าเริ่มต้นของอินเทอร์เฟซหรือในช่อง Gateway ของกฎไฟร์วอลล์ที่ต้องการ
สำหรับอินสแตนซ์ไคลเอนต์ OpenVPN บน pfSense 2.5 ขึ้นไป การตั้งค่า Default Gateway ของอินสแตนซ์ตัดสินว่าอุโมงค์แทนที่เส้นทางเริ่มต้นของระบบหรือไม่ การกำหนดเส้นทางตามกฎจะทำงานอย่างที่คุณคาดหวังเฉพาะเมื่อเส้นทางที่คุณถือว่ามีอยู่ถูกติดตั้งจริง หลังการเปลี่ยนแปลงให้ตรวจสอบ Status > Gateways แทนการเชื่อไอคอนสถานะอุโมงค์
การตั้งค่าสองอย่างทำให้เกิดการกระพริบส่วนใหญ่ อย่างหนึ่งคือช่วงตรวจสอบที่สั้นกว่าการกลับมารวมตัวของผู้ให้บริการเอง อีกอย่างคือกลุ่มที่ตัวหลักและตัวสำรองใช้ชั้นเดียวกัน ทั้งคู่จึงมีสิทธิ์ตลอดเวลา เพิ่มฮิสเทอรีซิสผ่านเกณฑ์การสูญหายและความหน่วงก่อนผู้ใช้จะรู้สึกถึงการเปลี่ยนแปลงแทนคุณ
ปิดเส้นทางที่อุโมงค์ไม่เคยครอบครอง
อย่างแรกคือการรั่วของ DNS ตัวแก้ชื่อยังตอบบน WAN และส่งต่อออกไปทางนั้น ชื่อจึงยังแก้ผ่าน ISP ในขณะที่ทราฟฟิกถูกตรึงกับอุโมงค์ จำกัดอินเทอร์เฟซขาออกของตัวแก้ชื่อ ดันตัวแก้ชื่อภายในไปยังไคลเอนต์ และบล็อกพอร์ต 53 สำหรับทุกอย่างอื่นบน VLAN ที่ใช้ VPN เท่านั้น
IPv6 ต้องการการตัดสินใจของตัวเอง LAN แบบ dual-stack อาจสูญเสียอุโมงค์แต่ยังมีเส้นทางเริ่มต้น IPv6 สากลที่ใช้งานได้ เบราว์เซอร์จึงชอบ IPv6 และออกผ่าน WAN ขณะที่ IPv4 ดูถูกปิดล้อมอย่างสมบูรณ์ ไม่ว่าจะกำหนดเส้นทาง IPv6 เข้าอุโมงค์หรือหยุดประกาศคำนำหน้าสากลขณะอุโมงค์ล่ม นโยบายครึ่งๆ กลางๆ แย่กว่าไม่มีเลย เพราะมันดูเหมือนใช้งานได้
จากนั้นคือเส้นทางขากลับ หากทางออกสำรองใช้ที่อยู่ต้นทางอื่น ฝั่งไกลต้องรู้วิธีส่งทราฟฟิกกลับมาที่ที่นั่น และทุกสถานะที่ผูกกับที่อยู่เก่าก็ตายแล้ว เซสชันที่เปิดอยู่ตอนตัวหลักล่มไม่ย้ายที่ มันค้างจนหมดเวลาและแอปพลิเคชันตัดสินใจว่าจะทำอย่างไร
ทดสอบการล่ม การกระพริบ และทางกลับเข้าไป
ดึงตัวหลักออกในขณะที่มีทราฟฟิกไม่เป็นอันตรายไหลอยู่ แล้วอ่านสี่อย่าง: Status > Gateways สำหรับสถานะสมาชิกของกลุ่ม, pfctl -ss สำหรับสถานะที่ยังตรึงกับเกตเวย์เก่า, traceroute จากไคลเอนต์สำหรับเส้นทางออก และการสอบถามตัวแก้ชื่อเพื่อดูว่าเซิร์ฟเวอร์ใดตอบ
ตอนนี้ทำให้กระพริบ ยกตัวหลักขึ้นสามสิบวินาที ลดลงสามสิบ ทำสองครั้ง หากทราฟฟิกวิ่งตามทุกการเปลี่ยนแปลง เกณฑ์แน่นเกินไปหรือชั้นผิด แก้ตามตารางเวลาของคุณ เพราะไม่เช่นนั้นผู้ให้บริการจะทำตามตารางเวลาของเขา
สุดท้าย ยืนยันว่าคุณยังบริหารเราเตอร์ได้ เก็บเส้นทางนอกแบนด์ไว้ เช่นสายคอนโซล VLAN สำหรับจัดการ หรือโมเด็มเซลลูลาร์ การทดสอบ failover ที่ล็อกคุณออกไปคือการทดสอบที่คุณทำไม่จบ และเราเตอร์ที่เข้าถึงไม่ได้ก็กลับมาเองไม่ได้
ก่อนจะบอกว่านโยบายเสร็จแล้ว คุณควรตอบสี่คำถามได้โดยไม่ต้องเปิดเทอร์มินัล: VLAN ใดใช้ WAN ได้ขณะอุโมงค์ล่ม ตัวตรวจจับเฝ้าดูอะไรและรอนานเท่าใด เซิร์ฟเวอร์ชื่อและเส้นทาง IPv6 ใดเคลื่อนไปกับเส้นทาง และคุณกลับเข้าไปได้อย่างไรหากตัวสำรองล้มเหลวด้วย หากคำตอบใดเป็น «อะไรก็ตามที่เป็นค่าเริ่มต้น» นโยบายยังเป็นของเราเตอร์ไม่ใช่ของคุณ