Назад | Перейти на главную страницу

проблемы с несколькими WAN с веб-сервисами

Я недавно установил соединение с несколькими глобальными сетями для небольшой компании, потому что они находятся в конце очереди для любого возможного интернет-провайдера, службы действительно перестают работать, и они действительно зависят от их подключения к Интернету. Я использую CISCO RV042, который может работать либо в режиме аварийного переключения, либо в режиме балансировки нагрузки. Кажется логичным использовать балансировку нагрузки - если у вас два соединения, почему бы не использовать их. Однако балансировка нагрузки приводит к проблеме, которую я собираюсь описать.

Удивительное количество веб-сервисов, по-видимому, устанавливает несколько TCP-соединений, а затем выходит из строя, когда эти соединения поступают с разных IP-адресов (как это происходит при балансировке нагрузки через несколько интерфейсов WAN). Совсем недавно новый интерфейс eBanking от банка этой компании, по-видимому, делает это. В случае подключения к eBanking, например, просто невозможно войти в сервис. Другие службы выдают странные ошибки или просто не работают должным образом.

Есть много компаний с несколькими глобальными подключениями. Неужто есть решение получше? Кто-нибудь?

Это невозможно без отслеживания соединений. Обычно маршрутизатор должен уметь:

  1. отслеживать входящие и исходящие соединения
  2. отметьте их
  3. напрямую через различные таблицы маршрутизации на основе метки подключения.

Проверьте, поддерживает ли это ваш маршрутизатор. Если нет и вы действительно хотите сбалансировать нагрузку трафика), вы можете заменить его маршрутизаторами Mikrotik (подойдет практически любая модель). На них относительно легко настроить балансировку нагрузки (см. маркировку брандмауэра в Wiki)

Также у Mikrotik есть версия для ПК (с 24-часовой пробной версией), поэтому вы можете проверить, подойдет ли она для вашей установки.

PS. На самом деле это не проблема веб-сервисов. TCP-соединение в большинстве случаев идентифицируется по IP-адресам источника и назначения, а также по исходному и целевому портам, поэтому при изменении IP-адреса это считается другим сеансом TCP.