Najlepsza praktyka dla witryny z podwójnym bazowaniem z dwoma dostawcami usług internetowych?

Subskrybuję dwóch dostawców usług internetowych, szybki i drogi, ale tani, ale wolniejszy. Używają różnych technologii, kabli i ADSL, więc nie ma jednego punktu awarii, a wszystkie moje urządzenia komunikacyjne są zasilane z UPS.

Dostawcy usług internetowych w Wielkiej Brytanii mają dość losowy charakter. Przez wiele lat nie spotkałem się jeszcze z chwilą, gdy obaj moi dostawcy usług internetowych upadli jednocześnie, więc strategia dwóch dostawców usług internetowych jest przydatna, jeśli chcesz mieć tutaj nieprzerwany dostęp do sieci.

Problemem jest jednak sposób organizacji sieci witryny, aby skorzystać z tej ulepszonej dostępności. Wielu dostawców usług internetowych nie pozwala na uruchomienie własnego AS i protokołów routingu, więc najczęściej utkniesz w dzieleniu statycznego routingu na dwie rury wyjściowe według miejsca docelowego. Jest to mniej niż genialne i wymaga ręcznej interwencji, gdy jeden ISP spadnie z powierzchni planety. Przy pomocy licznych skryptów radzę sobie z przerwami w dostawie usług internetowych z rozsądnym sukcesem i bez większego wysiłku, i stało się to normalne. To nie jest świetne. Wydaje się, że brakuje jakiejś technologii.

1. Czy jest ogólnie lepszy sposób?
2. Czy jest lepszy sposób tylko dla IPv6 (mam podwójny stos na jednym ISP i mogę tunelować na drugim)? Byłoby to oczywistym dobrodziejstwem dla IPv6.

Jakiego rodzaju sprzęt łączysz z dostawcami? Jeśli jest to urządzenie Cisco, możesz skorzystać z umowy SLA IP, aby wysłać polecenie ping do miejsca docelowego, takiego jak 8.8.8.8, za pośrednictwem głównego usługodawcy internetowego. Gdy tylko nie otrzymasz odpowiedzi na przełączenie awaryjne na inną trasę statyczną. Przykładowa konfiguracja:

! 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

Być może będziesz musiał ustawić trasę statyczną dla wersji 8.8.8.8 przez ISP1, aby zawsze wychodził z tej ścieżki. Oczywiście, jeśli naprawdę używasz wersji 8.8.8.8, wybierz inny adres IP, ponieważ w przeciwnym razie nie będziesz mieć do niego dostępu, jeśli ISP1 ulegnie awarii.

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

Możesz sprawdzić, czy jest dostępny dostawca LISP . LISP to protokół, który może uniezależnić witrynę od dostawców usług internetowych, z którymi się łączy. Otrzymujesz jeden lub więcej adresów IP od LISP ISP i oni kierują je do dowolnego miejsca połączenia. Jest to technika tunelowania, ale z wieloma fajnymi funkcjami. Możesz kontrolować równoważenie obciążenia przychodzącego i wychodzącego za pomocą łączy, możesz wykonywać IPh6 multihoming bez konieczności uciekania się do hacków takich jak NPT66 (tłumaczenie prefiksu). Możesz nawet przenieść się na drugą stronę planety bez zmiany adresów IP ;-)

Sam korzystam z LISP, a moja sieć biurowa ma blok adresów / 26 IPv4 i / 48 adresów IPv6, które są niezależne od nadrzędnych połączeń (połączenie kablowe UPC z jednym dynamicznym adresem IPv4 i połączenie Solcon DSL z zarówno statycznym adresem IPv4 oraz blok statyczny adresów IPv6). Cisco 1841 uruchamia LISP w biurze i korzysta z dowolnego dostępnego łącza, aby połączyć się z resztą Internetu. Tak długo, jak działa jeden link, moje biuro jest połączone za pomocą własnych adresów.

Pełne ujawnienie : prowadzę własnego usługodawcę internetowego opartego na LISP w Holandii, więc jestem stronniczy. LISP jest wciąż fajnym protokołem :-)

W przypadku wielokrotnego bazowania IPv6 z zagregowanymi adresami dostawcy każdy host w sieci otrzyma jeden prefiks adresu od każdego dostawcy. Wybór adresu źródłowego stosu hosta / aplikacji (RFC6724) i wybór pary SA / DA (RFC6555) określa, które wyjście jest używane.

Czyli wybór hosta / aplikacji przez wybór źródła adresu wybiera, który link wyjściowy jest używany. Różne implementacje robią to na różne sposoby i żadne z nich obecnie nie robi tego zbyt dobrze.

Sieć wykorzystuje routing zależny od adresu źródłowego, aby przekazać ruch do właściwego wyjścia. (W przeciwnym razie BCP38 (filtrowanie wejścia) upuściłby pakiet wysłany z adresem źródłowym ISP B do ISP A). Zobacz http://tools.ietf.org/html/draft-troan-homenet-sadr-01 Mamy implementację w OpenWRT. Ale można go również dobrze wdrożyć na dowolnym routerze obsługującym routing oparty na zasadach.

Aplikacja powinna być wystarczająco inteligentna, aby zmienić połączenie (wybierz inną parę SA / DA), gdy obecne połączenie nie powiedzie się. To nie jest Tymczasem naszym zaleceniem jest ustawienie czasu życia prefiksu adresu łącza powodującego błąd na 0, co oznacza, że ​​nowe połączenia nie będą używać tego adresu.

Pytanie 1 Możesz zainstalować router / zaporę, która obsługuje multihoming. Jeśli chodzi o darmowe oprogramowanie, pfSense pasuje do rachunku. http://www.pfsense.org/ . Dokumenty pfSense nazywają to Multi-WAN. http://doc.pfsense.org/index.php/Multi-WAN_2.0

Na szczęście pfSense ma automatyczne przełączanie awaryjne i równoważenie obciążenia.

Odkryłem, że niewielka liczba aplikacji internetowych nie działa, gdy jesteś multihomed. Aplikacje internetowe to zazwyczaj witryny finansowe, takie jak banki. Z jakiegoś powodu programiści aplikacji internetowych czasami uważają, że testowanie bezpieczeństwa na podstawie adresu IP jest w porządku. Dla użytkowników, którzy potrzebują tego dostępu, możesz zarezerwować adres IP dla swojego komputera i utworzyć „regułę LAN” w pfSense, aby zawsze używać określonej bramy, a nie drugiej dla tego adresu IP.

Uważam, że działa to całkiem dobrze w połączeniu modemu kablowego i modemu ADSL.

Q2 Nie ma powodu, dla którego multihoming nie działałby zarówno w IPv6, jak i IPv4. To powiedziawszy, pfSense nie ma w pełni obsługiwanej wersji, która poprawnie obsługuje IPv6. Obecna wersja pfSense to 2.0x. Po wydaniu 2.1 pfSense będzie dobrze obsługiwać IPv6 i będzie obejmować multihoming.

Możesz skonfigurować zdalny serwer / VPS w niezawodnym centrum danych, a następnie możesz skonfigurować tunele VPN z routera do zdalnego serwera za pośrednictwem każdego usługodawcy internetowego. Teraz router w domu może kierować pakiety przez te tunele na podstawie współczynnika przepustowości, a następnie zdalny serwer może kierować ruchem między resztą Internetu.

Wadą jest to, że ponosisz dodatkowe koszty związane z procesorem, pamięcią masową i przepustowością dla zdalnego serwera.

Zaletą jest to, że można wykorzystać całą szerokość pasma zapewnianą przez obu dostawców, a jednocześnie mieć opcję przełączania awaryjnego dla niezawodności.

Korzystałem z OpenWRT z Multiwan ( http://wiki.openwrt.org/doc/uci/multiwan ) od pewnego czasu w domu, aby korzystać z multihome między moim DSL i Cable ISP. Działa całkiem nieźle. Nie radziłbym tego jako rozwiązania korporacyjnego, ale jest OK dla SOHO i domowych konfiguracji.