MikroTik Dual-WAN Failover สำหรับ ISP

สรุป MikroTik dual-WAN failover ทำให้ไซต์ออนไลน์อยู่เสมอด้วยการย้ายทราฟฟิกไปยังอัปลิงก์สำรองโดยอัตโนมัติเมื่อลิงก์หลักล้มเหลว RouterOS มอบส่วนประกอบพื้นฐานสามอย่างให้คุณ — การกำหนดเส้นทางแบบเรียกซ้ำด้วย check-gateway, Netwatch และ NAT ต่อ WAN — และการผสมผสานที่ถูกต้องขึ้นอยู่กับว่าการตรวจจับของคุณต้องเร็วและฉลาดเพียงใด สำหรับฟลีต ISP ปัญหาที่ยากกว่าไม่ใช่ตัวคอนฟิก แต่คือการยืนยันข้ามไซต์ระยะไกลหลายร้อยแห่งหลัง CGNAT ว่า failover ทำงานจริง คู่มือนี้ครอบคลุมทั้งสองอย่าง

MikroTik Dual-WAN Failover คืออะไร?

MikroTik dual-WAN failover คือการกำหนดค่า RouterOS ที่ให้อัปลิงก์อินเทอร์เน็ตสองเส้นแก่เราเตอร์ — หลักและสำรอง — และย้ายทราฟฟิกไปยังสำรองโดยอัตโนมัติเมื่อลิงก์หลักหยุดส่งแพ็กเก็ต แล้วย้ายกลับเมื่อฟื้นตัว มันไม่เหมือนกับการกระจายโหลด: failover ทำให้ลิงก์หนึ่งว่างไว้เป็นประกัน ในขณะที่การกระจายโหลดกระจายทราฟฟิกไปทั้งสองเส้น เป้าหมายคือความต่อเนื่อง ไม่ใช่แบนด์วิดท์เพิ่ม ซึ่งเป็นเหตุผลที่มันเป็นรูปแบบความซ้ำซ้อนเริ่มต้นสำหรับไซต์ที่ดับไม่ได้เลย

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

ขั้นตอนที่ 1 — ทำแผนผัง WAN ทั้งสองก่อนแตะเส้นทาง

เริ่มด้วยการจดว่าอัปลิงก์แต่ละเส้นเป็นอะไรจริง ๆ ลิงก์หลักไฟเบอร์คงที่หรือ PPPoE ที่มีเกตเวย์แบบสแตติกหรือกำหนดผ่าน PPP มีพฤติกรรมต่างจากสำรอง Starlink หรือ LTE ที่อยู่หลัง Carrier-Grade NAT และให้ที่อยู่แบบไดนามิกแก่คุณ สิ่งนี้สำคัญเพราะ การกำหนดเส้นทางแบบเรียกซ้ำใช้ได้เฉพาะกับเกตเวย์ IP ที่เสถียร ไม่ใช่กับชนิดอินเทอร์เฟซแบบไดนามิกอย่าง PPPoE หรือ DHCP ที่ที่อยู่อาจเปลี่ยนได้ (เอกสาร MikroTik — Failover (WAN Backup)) ตัดสินใจว่าลิงก์ใดเป็นหลัก ลิงก์ใดเป็นสำรอง และมีลิงก์ใดเปลี่ยน IP เมื่อเชื่อมต่อใหม่หรือไม่ — ข้อเท็จจริงเดียวนี้กำหนดวิธีตรวจจับที่คุณใช้ได้

ขั้นตอนที่ 2 — เพิ่มเส้นทางเริ่มต้นแบบเรียกซ้ำด้วย check-gateway

วิธีคลาสสิกใช้ การกำหนดเส้นทางแบบเรียกซ้ำ: แทนที่จะชี้เส้นทางเริ่มต้นไปยัง next hop โดยตรง คุณชี้ไปยังเป้าหมายตรวจสอบ (เช่น รีโซลเวอร์สาธารณะที่รู้จักกันดี) และเพิ่มเส้นทางสแตติกที่บอก RouterOS ให้เข้าถึงเป้าหมายนั้นผ่านเกตเวย์ WAN ที่กำหนดเท่านั้น จากนั้นคุณสร้างเส้นทางเริ่มต้นสองเส้นที่แก้ไขแบบเรียกซ้ำผ่านเป้าหมายเหล่านั้น — ลิงก์หลักด้วยระยะที่เล็กกว่าและเปิดใช้ check-gateway=ping ลิงก์สำรองด้วยระยะที่ใหญ่กว่า (Scoop — Basic ISP Failover with MikroTik)

พฤติกรรมที่ต้องวางแผนรอบ ๆ คือเรื่องเวลา Check-gateway ปิดใช้งานเส้นทางหลังจากการตรวจสอบล้มเหลวสองครั้งติดต่อกัน และการตรวจสอบทำงานทุก ๆ ประมาณ 10 วินาที ดังนั้นการสลับจริงจึงตกอยู่ราว 20 ถึง 30 วินาที — และมันไม่ตอบสนองต่อการสูญเสียแพ็กเก็ตเป็นช่วง ๆ ตอบสนองเฉพาะเกตเวย์ที่ตายสนิทเท่านั้น (เอกสาร MikroTik — Failover (WAN Backup)) สำหรับไซต์ลูกค้า ISP จำนวนมากนั่นยอมรับได้ สำหรับเทอร์มินัลเสียงหรือชำระเงินมักไม่ได้ ซึ่งเป็นจุดที่ขั้นตอนที่ 4 เข้ามา

ขั้นตอนที่ 3 — กำหนดค่า NAT สำหรับอัปลิงก์ทั้งสอง

เราเตอร์ dual-WAN ต้องการ กฎ masquerade (หรือ src-nat) แยกต่อแต่ละอินเทอร์เฟซ WAN เพื่อให้ลิงก์ใดก็ตามที่ใช้งานอยู่แปลทราฟฟิกขาออกอย่างถูกต้อง กฎเดียวที่ผูกกับอินเทอร์เฟซเดียวจะตัดการเชื่อมต่ออย่างเงียบ ๆ ในวินาทีที่ failover ย้ายทราฟฟิกไปยังลิงก์อีกเส้น เพิ่มกฎ masquerade หนึ่งในเชน srcnat สำหรับ out-interface หลัก และกฎที่สองสำหรับสำรอง หากคุณเผยแพร่บริการขาเข้าใด ๆ จำไว้ว่ากฎ dst-nat ที่ผูกกับที่อยู่ของลิงก์หลักจะหยุดทำงานเมื่อลิงก์นั้น — และ IP สาธารณะของมัน — หายไป ความเปราะบางขาเข้านี้คือกับดักทางสถาปัตยกรรมเดียวกับที่กล่าวถึงในกรณีศึกษาการเปลี่ยน IP ของ Starlink ของเรา และเป็นเหตุผลที่การเข้าถึงแบบยึดขาออกขยายตัวได้ดีกว่าการ forward พอร์ต สำหรับพื้นฐาน NAT ดูคู่มือการกำหนดค่า NAT บน MikroTik ของเรา

ขั้นตอนที่ 4 — ใช้ Netwatch เมื่อคุณต้องการตรวจจับที่เร็วหรือฉลาดขึ้น

เมื่อ 20–30 วินาทีช้าเกินไป หรือคุณต้องดำเนินการกับลิงก์ที่เสื่อมแต่ยังมีชีวิต Netwatch เป็นเครื่องมือที่ยืดหยุ่นกว่า ใน RouterOS v7 Netwatch ได้พารามิเตอร์ type ที่สามารถตรวจสอบด้วย icmp, tcp-conn, http-get, https-get หรือ simple และคุณตั้งช่วงตรวจสอบของคุณเองได้แทนที่จะอยู่กับจังหวะคงที่ของ check-gateway (เอกสาร MikroTik — Failover (WAN Backup)) แต่ละโฮสต์มีสคริปต์ up และ down ดังนั้นเมื่อมีการเปลี่ยนคุณสามารถปิดใช้งานเส้นทางเริ่มต้นหลัก ปลุกการแจ้งเตือน หรือบันทึกเหตุการณ์ได้

ผู้ให้บริการหลายรายรวมทั้งสองอย่าง: การกำหนดเส้นทางแบบเรียกซ้ำจัดการการตายของลิงก์อย่างสะอาด ในขณะที่ Netwatch ครอบคลุมกรณีที่ยุ่งเหยิงกว่าและส่งการแจ้งเตือน กระทู้ชุมชนที่ยาวนานถกเถียงเรื่องการแลกเปลี่ยนนี้พอดี และควรอ่านก่อนที่คุณจะกำหนดมาตรฐานวิธีเดียวข้ามฟลีต (ฟอรัม MikroTik — netwatch instead of recursive routing) ไม่ว่าคุณเลือกอะไร ให้คอนฟิกเหมือนกันทุกไซต์ — ฟลีตของสคริปต์ failover ที่ทำเองเป็นการล่มที่รอจะเกิดในตัวมันเอง

ขั้นตอนที่ 5 — ตรวจสอบ failover ที่ทุกไซต์ระยะไกล

นี่คือส่วนที่บทช่วยสอนคอนฟิกข้ามไป การเพิ่มเส้นทางบนเราเตอร์ทดสอบเครื่องเดียวนั้นง่าย การพิสูจน์ว่า failover ทำงานบน CPE ที่ติดตั้งหลายร้อยเครื่องคือปัญหา ISP ที่แท้จริง — และยากขึ้นเมื่อลิงก์สำรองเป็น Starlink หรือ LTE หลัง CGNAT เพราะอุปกรณ์มักไม่มี IP สาธารณะที่เข้าถึงได้เพื่อจัดการหลังจากสลับ หากคุณยืนยัน failover ได้เพียงด้วยการรอให้ลูกค้าโทรมา คุณก็ไม่ได้มี failover จริง ๆ คุณมีสคริปต์ที่หวังว่ามันจะทำงาน

นี่คือจุดที่การจัดการแบบรวมศูนย์เปลี่ยนเศรษฐศาสตร์ MKController ทำให้เราเตอร์แต่ละเครื่องเข้าถึงได้ผ่านทันเนลขาออกที่ผ่านการยืนยันตัวตน ดังนั้นคุณสามารถยืนยันว่าเส้นทางสำรองรับทราฟฟิก เฝ้าดูการเปลี่ยน failover ในการมอนิเตอร์ และพุชคอนฟิกที่แก้ไขแล้ว — โดยไม่ต้องพึ่ง IP สาธารณะที่อาจไม่มีอยู่บนลิงก์สำรอง จับคู่กับเทเลเมทรี: คู่มือของเราเรื่องการมอนิเตอร์ MikroTik จากระยะไกลด้วย Zabbix และการมอนิเตอร์ SNMP สำหรับ MikroTik แสดงวิธีแจ้งเตือนต่อเหตุการณ์ failover เอง เพื่อให้การสลับเงียบ ๆ ไปยังลิงก์สำรองราคาแพงไม่เคยผ่านไปโดยไม่ถูกสังเกต

เคล็ดลับ

• ให้โพรบ check-gateway ของลิงก์สำรองชี้ไปยังเป้าหมายที่คุณเข้าถึงได้ ผ่านลิงก์นั้น ไม่ใช่ผ่านลิงก์หลัก มิฉะนั้นการทดสอบของคุณไร้ความหมาย
• แท็กการเปลี่ยน failover ในการมอนิเตอร์ของคุณ เพื่อให้ไซต์ที่ทำงานบนอัปลิงก์สำรองเป็นวัน ๆ สร้างทิกเก็ต — failover ที่ไม่มีใครสังเกตคือต้นทุนที่เกิดซ้ำ ไม่ใช่การช่วยชีวิต
• ทดสอบสายจริง ไม่ใช่แค่เส้นทาง: ถอดขั้วต่อของลิงก์หลักและจับเวลาการสลับจริง

นำ failover มาอยู่ใต้คอนโทรลเพลนเดียว

Dual-WAN failover บน MikroTik เครื่องเดียวเป็นปัญหาที่แก้แล้ว การทำให้เชื่อถือได้ข้ามฟลีต — ด้วยคอนฟิกที่สอดคล้องและความสามารถในการ พิสูจน์ ว่าสำรองทำงานบนเราเตอร์ที่คุณเข้าถึงผ่าน IP สาธารณะไม่ได้ — คือจุดที่ผู้ให้บริการส่วนใหญ่เสียเงิน การจัดการแบบรวมศูนย์ที่ยึดขาออกปิดช่องว่างนั้น

เริ่มทดลองใช้ MKController ฟรี