แนวปฏิบัติที่เหมาะสมที่สุดสำหรับไซต์คู่กลับบ้านที่มีสอง ISP หรือไม่

ฉันสมัครเป็นสมาชิก ISP สองรายซึ่งเป็นผู้ให้บริการที่รวดเร็วและราคาถูก แต่ช้ากว่า พวกเขาใช้เทคโนโลยีสายเคเบิลและ ADSL ที่แตกต่างกันดังนั้นจึงมีความล้มเหลวเพียงจุดเดียวและอุปกรณ์ comms ของฉันทั้งหมดนั้นใช้พลังงานจาก UPS

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

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

1. มีวิธีที่ดีกว่าโดยทั่วไป?
2. มีวิธีที่ดีกว่าสำหรับ IPv6 เท่านั้น (ฉันมีสองสแต็คใน ISP หนึ่งและสามารถสร้างอุโมงค์อื่น ๆ ) นั่นจะเป็นประโยชน์อย่างชัดเจนสำหรับ IPv6

อุปกรณ์ประเภทใดที่คุณเชื่อมต่อกับผู้ให้บริการ หากเป็นอุปกรณ์ของ Cisco คุณสามารถใช้ IP SLA เพื่อ ping ปลายทางเช่น 8.8.8.8 ผ่าน ISP หลัก ทันทีที่คุณไม่ได้รับการตอบกลับล้มเหลวไปยังเส้นทางแบบคงที่อื่น ตัวอย่างการกำหนดค่า:

! ISP1
ip route 0.0.0.0 0.0.0.0 x.x.x.x track 1
! ISP2
ip route 0.0.0.0 0.0.0.0 y.y.y.y 250
ip sla 1
icmp-echo 8.8.8.8 source-interface <ISP1_interface>
frequency 3
timeout 1000
ip sla schedule 1 life forever start-time now

คุณอาจต้องวางเส้นทางแบบคงที่สำหรับ 8.8.8.8 บน ISP1 เพื่อให้ออกจากเส้นทางนั้นเสมอ เห็นได้ชัดว่าถ้าคุณใช้ 8.8.8.8 เลือก IP อื่นเพราะมิฉะนั้นคุณจะไม่สามารถเข้าถึงได้หาก ISP1 หยุดทำงาน

!x.x.x.x is next-hop to ISP1
ip route 8.8.8.8 255.255.255.255 x.x.x.x

คุณอาจต้องการตรวจสอบว่ามีผู้ให้บริการLISPหรือไม่ LISP เป็นโปรโตคอลที่สามารถทำให้ไซต์เป็นอิสระจาก ISP ต้นน้ำที่เชื่อมต่อด้วย คุณได้รับที่อยู่ IP อย่างน้อยหนึ่งรายการจาก LISP ISP และจะกำหนดเส้นทางไปยังทุกที่ที่คุณเชื่อมต่อ มันเป็นเทคนิคการขุดอุโมงค์ แต่มีคุณสมบัติเจ๋ง ๆ มากมาย คุณสามารถควบคุมสมดุลภาระทั้งขาเข้าและขาออกผ่านลิงก์คุณสามารถทำ IPv6 multihoming ได้โดยไม่ต้องเปลี่ยนไปใช้แฮ็กอย่าง NPT66 (การแปลคำนำหน้า) คุณสามารถย้ายไปยังอีกด้านหนึ่งของโลกโดยไม่ต้องเปลี่ยนที่อยู่ IP ;-)

ฉันใช้ LISP ด้วยตัวเองและสำนักงานเครือข่ายของฉันมีบล็อกของ / 26 IPv4 และ a / 48 บล็อกของที่อยู่ IPv6 ที่ไม่ขึ้นอยู่กับการ upstreams (การเชื่อมต่อสายเคเบิล UPC กับที่อยู่ IPv4 แบบไดนามิกหนึ่งและการเชื่อมต่อ Solcon DSL พร้อมทั้งที่อยู่ IPv4 แบบคงที่ และบล็อกคงที่ของที่อยู่ IPv6) Cisco 1841 ทำงาน LISP ในสำนักงานและใช้ลิงก์ใดก็ได้ที่มีอยู่เพื่อเชื่อมต่อกับอินเทอร์เน็ตที่เหลือ ตราบใดที่ลิงค์เดียวใช้งานได้สำนักงานของฉันก็เชื่อมต่อโดยใช้ที่อยู่ของตัวเอง

การเปิดเผยอย่างเต็มรูปแบบ : ฉันใช้ ISP ที่ใช้ LISP ในประเทศเนเธอร์แลนด์ดังนั้นฉันจึงลำเอียง LISP ยังคงเป็นโปรโตคอลเด็ด ๆ :-)

ใน IPv6 multi-homing พร้อมที่อยู่รวมของผู้ให้บริการแต่ละโฮสต์ในเครือข่ายจะได้รับคำนำหน้าหนึ่งที่อยู่จากผู้ให้บริการแต่ละราย การเลือกที่อยู่ต้นทางของสแต็ค / แอปพลิเคชัน (RFC6724) และตัวเลือกของคู่ SA / DA (RFC6555) เป็นตัวกำหนดว่าจะใช้ทางออกใด

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

เครือข่ายใช้การกำหนดเส้นทางขึ้นอยู่กับแหล่งที่มาเพื่อส่งต่อการรับส่งข้อมูลไปยังทางออกที่ถูกต้อง (มิฉะนั้น BCP38 (การกรองทางเข้า) จะทำให้แพ็กเก็ตที่ส่งมาพร้อมกับที่อยู่แหล่งที่มาของ ISP B ไปยัง ISP A) ดูhttp://tools.ietf.org/html/draft-troan-homenet-sadr-01 เรามีการนำไปใช้ใน OpenWRT แต่ก็สามารถใช้งานได้ดีพอสมควรกับเราเตอร์ที่รองรับการกำหนดเส้นทางตามนโยบาย

แอปพลิเคชันควรฉลาดพอที่จะเปลี่ยนการเชื่อมต่อ (เลือกคู่ SA / DA อื่น) เมื่อการเชื่อมต่อปัจจุบันล้มเหลว มันไม่ใช่ ในระหว่างนี้คำแนะนำของเราคือการตั้งค่าอายุการใช้งานของคำนำหน้าที่อยู่ลิงก์ที่ล้มเหลวเป็น 0 ซึ่งหมายความว่าการเชื่อมต่อใหม่จะไม่ใช้ที่อยู่นั้น

ไตรมาสที่ 1 คุณสามารถติดตั้งเราเตอร์ / ไฟร์วอลล์ที่รองรับ multihoming ในแง่ของซอฟต์แวร์ฟรี pfSense เหมาะกับการเรียกเก็บเงิน http://www.pfsense.org/ เอกสาร pfSense อ้างถึงสิ่งนี้ว่า Multi-WAN http://doc.pfsense.org/index.php/Multi-WAN_2.0

มีประโยชน์ pfSense มีการ failover อัตโนมัติและการทำ load balance

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

ฉันพบว่ามันใช้งานได้ดีสำหรับการผสมผสานระหว่างเคเบิลโมเด็มและโมเด็ม ADSL

ไตรมาสที่ 2 ไม่มีเหตุผลใดที่การใช้มัลติแฮงค์จะไม่ทำงานใน IPv6 เช่นเดียวกับ IPv4 ที่กล่าวว่า pfSense ไม่มีการรองรับอย่างเต็มที่ที่รองรับ IPv6 รุ่นปัจจุบันของ pfSense คือ 2.0x เมื่อปล่อย 2.1 แล้ว pfSense จะมีการสนับสนุน IPv6 ที่ดีและจะรวมถึงการใช้หลายสาย

คุณสามารถตั้งค่าเซิร์ฟเวอร์ระยะไกล / VPS ในศูนย์ข้อมูลที่เชื่อถือได้และจากนั้นคุณสามารถตั้งค่า VPN tunnels จากเราเตอร์ของคุณไปยังเซิร์ฟเวอร์ระยะไกลผ่าน ISP แต่ละเครื่อง ตอนนี้เราเตอร์ของคุณที่บ้านสามารถกำหนดเส้นทางแพ็กเก็ตผ่านช่องสัญญาณเหล่านี้ตามอัตราส่วนแบนด์วิดท์จากนั้นเซิร์ฟเวอร์ระยะไกลสามารถกำหนดเส้นทางการรับส่งข้อมูลระหว่างอินเทอร์เน็ตที่เหลือ

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

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

ฉันใช้ OpenWRT กับ Multiwan ( http://wiki.openwrt.org/doc/uci/multiwan ) หลายครั้งที่บ้านกับ multihome ระหว่าง DSL และ Cable ISP ของฉัน มันทำงานได้ค่อนข้างดี ฉันจะไม่ให้คำแนะนำว่าเป็นโซลูชันขององค์กร แต่มันก็ใช้ได้สำหรับการติดตั้ง SOHO และการติดตั้งที่บ้าน