Найкраща практика для сайту з подвійним наведенням з двома провайдерами?

Я підписаний на два провайдера, швидкий дорогий і дешевий, але повільніший. Вони використовують різні технології, кабель та ADSL, тому немає жодної точки поломки, і все моє обладнання для живлення комунальних мереж працює від ДБЖ.

Інтернет-провайдери у Великобританії знижуються за досить випадковою схемою. Протягом багатьох років я ще не стикався з моментом, коли обидва моїх Інтернет-провайдера одночасно знизилися, тому явно стратегія двох провайдерів корисна, якщо ви хочете тут безперебійного доступу до мережі.

Однак проблема полягає в тому, як організувати мережу вашого сайту, щоб скористатися цим покращеним доступністю. Багато провайдерів не дозволяють вам запускати власні протоколи AS та маршрутизацію, тому ви здебільшого зациклювались на розбиванні статичної маршрутизації по двох вивідних трубах за призначенням. Це менш, ніж геніально, і вимагає ручного втручання, коли один Інтернет-провайдер скидає обличчя планети. За допомогою численних сценаріїв я справляюся з відключеннями провайдера з розумним успіхом і не докладаючи великих зусиль, і це стає ділом як завжди. Хоча це і не чудово. Складається враження, що якоїсь технології не вистачає.

1. Чи є кращий спосіб, взагалі?
2. Чи є кращий спосіб лише для IPv6 (я маю подвійний стек на одному провайдері, а міг би тунель на іншому)? Це було б явною перевагою для IPv6.

Яке обладнання у вас є підключення до провайдерів? Якщо це пристрій Cisco, ви можете використовувати IP SLA для того, щоб прописати місце призначення, наприклад 8.8.8.8, через основний провайдер. Як тільки ви не отримаєте відповідь про відмову на інший статичний маршрут. Приклад конфігурації:

! 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 - це протокол, який може зробити сайт незалежним від вихідних Інтернет-провайдерів, до яких він підключається. Ви отримуєте одну або кілька IP-адрес від провайдера LISP і вони направляють їх туди, куди ви підключені. Це техніка тунелювання, але з великою кількістю класних функцій. Ви можете керувати балансуванням вхідного та вихідного навантаження через посилання, ви можете робити мультихомінг IPv6, не вдаючись до таких хак, як NPT66 (переклад префікса). Ви навіть можете переїхати на інший бік планети, не змінюючи IP-адреси ;-)

Я використовую LISP самостійно, і в моїй офісній мережі є блок / 26 IPv4 та / 48 блок IPv6 адрес, які не залежать від вхідних потоків (кабельне з'єднання UPC з однією динамічною IPv4 адресою та з'єднання DSL Solcon зі статичною IPv4 адресою і статичний блок адрес IPv6). Cisco 1841 працює в офісі LISP і використовує будь-яке посилання для підключення до іншої частини Інтернету. Поки працює одне посилання, мій офіс підключений, використовуючи власні адреси.

Повне розкриття інформації : я запускаю свій власний провайдер на базі LISP в Нідерландах, тому я упереджений. LISP - це ще класний протокол, хоча :-)

У багатоповерховому IPv6 з адресами, що агрегуються провайдером, кожен хост мережі отримає по одному префіксу адреси від кожного з провайдерів. Вибір вихідної адреси стека хостів / програми (RFC6724) та вибір пари SA / DA (RFC6555) визначають, який вихід використовується.

Тобто вибір хосту / програми вибирає адресу джерела, яка вихідна посилання використовується. Різні впровадження роблять це різними способами, і наразі це не дуже добре.

Мережа використовує маршрутизацію, залежну від джерела, для переадресації трафіку на правильний вихід. (Інакше BCP38 (вхідна фільтрація) скинув би пакет, надісланий з адресою джерела ISP B в ISP A). Дивіться http://tools.ietf.org/html/draft-troan-homenet-sadr-01 У нас є реалізація в OpenWRT. Але це також може бути розумно реалізовано на будь-якому маршрутизаторі, що підтримує маршрутизацію, засновану на політиці.

Додаток має бути досить розумним, щоб змінити з'єднання (вибрати іншу пару SA / DA), коли поточне з'єднання не вдасться. Це не так. Тим часом наша рекомендація полягає в тому, щоб встановити термін служби префікса адреси несправного посилання на 0, тобто нові з'єднання не використовуватимуть цю адресу.

Q1. Ви можете встановити маршрутизатор / брандмауер, який підтримує мультихомінг. Щодо вільного програмного забезпечення, pfSense підходить до рахунку. http://www.pfsense.org/ . Документи pfSense називають це Multi-WAN. http://doc.pfsense.org/index.php/Multi-WAN_2.0

Корисно, що pfSense має автоматичну відмову та балансування навантаження.

Що я з’ясував, це те, що невелика кількість веб-додатків не працює, коли ви багатошлюбні. Веб-додатки зазвичай є фінансовими сайтами, як банки. Чомусь програмісти веб-додатків іноді думають, що добре перевірити безпеку на основі IP-адреси. Користувачі, яким потрібен цей доступ, ви можете зарезервувати IP-адресу для свого комп’ютера та створити "правило LAN" у pfSense, щоб завжди використовувати певний шлюз, а не інший для цієї IP-адреси.

Я вважаю, що це досить добре поєднує кабельний модем і ADSL модем.

Q2. Немає причини, чому мультихомінг не працюватиме як в IPv6, так і в IPv4. Однак, у pfSense немає повністю підтримуваного випуску, який належним чином обробляє IPv6. Поточна версія pfSense - 2.0x. Після виходу 2.1, pfSense матиме хорошу підтримку IPv6 та матиме мультихомінг.

Ви можете встановити віддалений сервер / VPS в надійному центрі обробки даних, а потім ви зможете налаштувати тунелі VPN з маршрутизатора на віддалений сервер через кожен провайдер. Тепер ваш маршрутизатор вдома може маршрутизувати пакети через ці тунелі на основі коефіцієнта пропускної здатності, і тоді віддалений сервер може направляти трафік між іншою частиною Інтернету.

Недоліком є ​​те, що ви віддасте додаткові витрати на процесор, сховище та пропускну здатність для віддаленого сервера.

Перевага полягає в тому, що ви можете використовувати всю пропускну здатність, яку надають обидва провайдери, зберігаючи при цьому можливість надійності.

Я деякий час використовував OpenWRT з Multiwan ( http://wiki.openwrt.org/doc/uci/multiwan ) вдома, щоб багатофункціонально знаходитись між моїм DSL та кабельним провайдером. Це спрацювало досить непогано. Я б не радив це як корпоративне рішення, але це нормально для SOHO та домашніх налаштувань.