Пусть железку покупать не хочется (нет денег, некуда включать и т.д.) Как бы решить проблему более-менее корректно одним софтом?? Иногда покупка железа приносит больше проблем, чем решает. 
Micronet SP890 или другие варианты multihome интернета Понятно, что со стороны *nix всё это выглядит, по меньшей мере, смешно, но MS как-то гордится своим TCP/IP и даже пыталась меряться производительностью.
На самом деле сконфигурить всё достаточно просто (работать -- сложнее), но видно, что у народа проблемы с настройкой остались.
Информации же по настройке MS win для работы с двумя (и более) внешними каналами мало. Достал Гугля и других запросами -- толку никакого. Тем не менее настроил, работает некоторое время. По граблям прошелся -- хочу поделится, может полезно будет. Осталась нерешенной одна проблема (см. -- ниже), так что если кто посоветует подходящее решение -- заранее благодарен.
Я не касаюсь специальных случаев, настроек и работы дополнительного софта (почтовиков, файрволлов, проксей, DNS, WINS и т.д.) а также работы MS LanMan, NBT -- подобные вещи сложны сами по себе и работают выше TCP/IP, как правило, требуют специальных настроек. Если стек TCP/IP настроен плохо, то всё вышеупомянутое будет работать тоже плохо или не будет рабоать вообще.
Multihomed-комп, w2k3. 3 сетевые карты WAN1, WAN2 и LAN. Два внешних канала от двух разных провайдеров, локальная сеть -- простая, т.е. внутри машрутизаторов и подсетей нет.
WAN1 (ISP): IP1, NM1, DG1 -- соотв адрес, подсеть и шлюз
WAN2 (ISP): IP2, NM2, DG2
LAN: IPL, NML
В принципе, можно привязать два разных IP-адреса к одной сетевой карте и обойтись двумя физическими интерфейсами -- не принципиально, но 3 карты немножко удобнее (не надо соединять двух провайдеров и гораздо проще отключать каналы).
Простой вариант (N1) -- WAN1 работает всегда, а WAN2 включается когда на WAN1 начались проблемы (как резерв). Сложнее заставить оба канала полноценно работать одновременно (вариант N2). А если хочется QoS или управления трафиком -- то без дополнительного софта (железа), имхо, уже не обойтись.
Надо прописать параметры IP по сетевым карточкам и аккуратно вручную настроить метрики default gateway для кажлого из них. Ибо MS win сделает это сама как ей хочется http://support.microsoft.com/default.aspx?scid=kb;en-us;299540 . И при изменении конфигурации -- точно также переделает. Соответсвенно надо вручную назначить метрики для интерфейса и/или для каждого конктретного default gateway. Правильность проверить по route print... Если кабель не вставлен (link down), то конретного интерфейса может вообще не быть в таблице маршрутизации. А потом он "неожиданно" появится.
tip: при задании второго default gateway вылезет страшная коробка от MS с предупреждением о нескольких default gateways -- "ОК" её.
Если хочется иметь WAN2 в качестве backup (варинат N1) -- то его метрика его шлюза должна больше, чем у WAN1.
Если хочется использовать оба канала одновременно (вариант N2), то надо настраивать одинаковые метрики, но последовательность выбора интерфесов будет определяться уже порядком привязки (binding): Advanced Settings -> Adapters and Bindings см. http://www.microsoft.com/technet/community/columns/c…leguy/cg0903.mspx
фича: после изменения привязки w2k и w2k3 не просят перегрузиться, как это было в NT4, но изменения фактически вступят в силу только после перезагруки.
Что делать если в качестве одного из WAN VPN и PPPoE -- не знаю, имхо и для этого тоже все настраивается.
Далее обычно необходимо прописать вручную маршурты к "известным" ресурсам на каждом из интерфейсов. Поскольку у каждого провайдера обычно есть ряд сервисов, доступных только при подключении с определенного ("своего") IP-адреса (самое простое -- домашняя сеть со своими IP и ресурсами). А сама система совершенно "без понятия" что и куда нужно пускать и что находится за каждым DG1, DG2. Стоит расписать табличку нужных IP, внести их в соотв подсети (если IP-реальные, то самый простой вариант: посмотреть чья и какая это подсеть через whois). После изучения route /?
необходимо долго и нудно прописывать нужное по route add... Статические маршруты имеет смысл задать с метрикой меньшей, чем метрики WAN1 и WAN2.
tip: лучше сначала проверить работу каждого маршрута в отдельности (ошибиться очень легко), т.е. после route add посмотреть на таблицу маршрутизации по route print и проверить маршрут с помощью tracert... А когда все заработает: либо внести все route add в bat-файл и исполнять его "на бис" при каждой перезагрузке, либо добавить -p и сделать маршруты постоянными (переживающими перезагрузку), но тогда сразу стоит писать bat-файл для очистки таблицы маршрутизации с командами route delete для каждого route add или воспользоваться -f
Уже должно работать...
Но есть тонкости. При конфигурации N1 (с разными метриками) попытки TCP-подключений к WAN2 (при живом WAN1) будут неуспешными. Хотя UDP и ICMP будет ходить исправно (засада: "ну пингуется же! а подключиться невозможно"). Исходящие же подключения будут использовать WAN1 для всех случаев, кроме явно прописанных через WAN2 маршрутов с меньшей метрикой.
При конфигурации N2 действительно оба интерфейса будут адекватно реагировать на любой входящий трафик. Исходящий же будет отправляться наружу по тому инфтерфейсу, который "привязан повыше" (метрики у них одинаковые) -- т.е. WAN1. Опять же кроме явных статических маршрутов.
Но вот если с WAN1, который "основной" в обоих случаях, начинаются проблемы и механизм определения упавшего шлюза разрешен (Dead Gateway Detection), то вся эта стройная картина рассыпается.
Собственно, поведение стека TCP/IP при возниконовении проблем (и при их окончании) является основной "засадой", не зря MS категорически не советует использовать более одного default gateway и написала по этому поводу http://support.microsoft.com/kb/159168/EN-US/ и http://www.microsoft.com/technet/community/columns/c…leguy/cg0903.mspx . Рекомендации приведены там же, но они применимы далеко не всегда...
Единственный вопрос, на который я не нашел ответа: что происходит с уже уставновленными через WAN1 TCP-соединениями. Они все рвутся сразу или постепенно и если WAN1 восстановится до обрыва всех, то оставшиеся будут продолжать работу. Вроде бы по факту -- второй вариант, но я не уверен. И сюда же можно добавить: при выключенном Dead Gateway Detection трафик так и будет упорно посылаться через WAN1??? Если кто реально отслеживал -- поделитесь сюда, pls.
ICMP и UDP не вызывают смену default gateway и также на них не отражаются последствия. Как всё это происходит и как конкретные параметры реестра влияют на этот процесс -- описано MS, пересказывать нет смысла (см ниже в ссылках). Результат (тоже честно описан MS и является скорее фичей, а не багой) такой: WAN1 перестает реагировать на попытки TCP-подключений снаружи, по факту имеем функционирование системы по варианту N1, где WAN1 и WAN2 поменялись местами. Это можно заметить по route print -- там меняется default gateway на DG2 и ipconfig показывает WAN1 без DG1(?? странно, но так оно и есть). Поскольку записи в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip не меняются, то после перезагрзуки все возвращается на свои места. Перезагрузка -- это сильно, особенно если это сервер, который подключен к двум каналам (и на нем, как водится, висит туча клиентов и добрый десяток сервисов).
По идее, если не перезагружать систему, то при возникновении проблем на WAN2 опять сменится default gateway на следующий (в данном случае на DG1) и т.д. Однако система сама по себе не вернется в конфигурацию N2.
Можно легонько "с ноги" дослать систему в исходное состояние: выдернуть кабель или отключить (disable) WAN1. При подключении интерфейса обратно, видимо, перестраивается таблица маршрутизации и опять получаем работающий вариант N2 (или N1 -- ну с ним вообще как-то все попроще). Помогает также (пере-)задание статических маршрутов (просто запускаю тот самый bat-файл, где лежат все статические маршруты).
Собственно осталась одна проблема (с двух сторон):
- как корректно принудительно переключать WAN1 и WAN2 "на лету" без переконфигурации стека TCP/IP, привязки и т.д. по любой внешней неоходимости (пример: DG1 -- доступен, ISP1 жив а от интренета отвалился или его внешний канал перегружен).
- как наиболее корректно возвращать систему в исходное состояние, когда функционирование основного канала (WAN1) пришло в норму, а стек TCP/IP об этом не знает, пока с WAN2 не начались проблемы.
Интересует теория -- я не нашел, где описано и особенно(!) практика: скрипты, программы и прочее.
Самый простой вариант: если ping куда-то (куда надо) умер/восстановился (уже некоторое время), то передернуть route или netsh чего-то... Может кто поделится реально работающим скриптиком???
нарытые ссылки по теме:
настройка стека TCP/IP (w2k) с картинками:
http://www.support.psi.com/support/common/inet-serv/…/win2k_tcpip.html
детальная информация по стеку TCP/IP (работа, реестр и параметры)
Microsoft Windows Server 2003 TCP/IP Implementation Details
http://www.microsoft.com/technet/prodtechnol/windows…king/tcpip03.mspx
кое-какие детали описаны здесь
DSL Speed Test and Tweaks Guide
http://help.montanasky.net/DSL_Info.html
читать MS kb по теме:
Default Gateway Configuration for Multihomed Computers
http://support.microsoft.com/default.aspx?scid=kb;en-us;157025
Multiple Default Gateways Can Cause Connectivity Problems
http://support.microsoft.com/kb/159168/EN-US/
Expected Behavior of Multiple Adapters on Same Network
http://support.microsoft.com/kb/175767/EN-US/
Dead Gateway Detection in TCP/IP for Windows NT
http://support.microsoft.com/kb/128978/EN-US/
TCP/IP Dead Gateway Detection Algorithm Updated for Windows NT
http://support.microsoft.com/kb/171564/EN-US/
An Explanation of the Automatic Metric Feature for Internet Protocol Routes
http://support.microsoft.com/default.aspx?scid=kb;en-us;299540
How to Configure a Default Gateway for Multihomed Computer with LAN and Internet Access
http://support.microsoft.com/default.aspx?scid=kb;en-us;262397
(старье)
The Cable Guy -- две очень полезные статьи:
Default Gateway Behavior for Windows TCP/IP: The Cable Guy - September 2003
http://www.microsoft.com/technet/community/columns/c…leguy/cg0903.mspx
Microsoft TechNet: IP Routing: The Cable Guy, December 2001
http://www.microsoft.com/technet/community/columns/c…leguy/cg1201.mspx
мало??? здесь можно покопаться:
Windows 2000 TCP/IP Resources
http://labmice.techtarget.com/networking/tcp.htm
Micronet SP890 или другие варианты multihome интернета Понятно, что со стороны *nix всё это выглядит, по меньшей мере, смешно, но MS как-то гордится своим TCP/IP и даже пыталась меряться производительностью.На самом деле сконфигурить всё достаточно просто (работать -- сложнее), но видно, что у народа проблемы с настройкой остались.
Информации же по настройке MS win для работы с двумя (и более) внешними каналами мало. Достал Гугля и других запросами -- толку никакого. Тем не менее настроил, работает некоторое время. По граблям прошелся -- хочу поделится, может полезно будет. Осталась нерешенной одна проблема (см. -- ниже), так что если кто посоветует подходящее решение -- заранее благодарен.
Я не касаюсь специальных случаев, настроек и работы дополнительного софта (почтовиков, файрволлов, проксей, DNS, WINS и т.д.) а также работы MS LanMan, NBT -- подобные вещи сложны сами по себе и работают выше TCP/IP, как правило, требуют специальных настроек. Если стек TCP/IP настроен плохо, то всё вышеупомянутое будет работать тоже плохо или не будет рабоать вообще.
Multihomed-комп, w2k3. 3 сетевые карты WAN1, WAN2 и LAN. Два внешних канала от двух разных провайдеров, локальная сеть -- простая, т.е. внутри машрутизаторов и подсетей нет.
WAN1 (ISP): IP1, NM1, DG1 -- соотв адрес, подсеть и шлюз
WAN2 (ISP): IP2, NM2, DG2
LAN: IPL, NML
В принципе, можно привязать два разных IP-адреса к одной сетевой карте и обойтись двумя физическими интерфейсами -- не принципиально, но 3 карты немножко удобнее (не надо соединять двух провайдеров и гораздо проще отключать каналы).
Простой вариант (N1) -- WAN1 работает всегда, а WAN2 включается когда на WAN1 начались проблемы (как резерв). Сложнее заставить оба канала полноценно работать одновременно (вариант N2). А если хочется QoS или управления трафиком -- то без дополнительного софта (железа), имхо, уже не обойтись.
Надо прописать параметры IP по сетевым карточкам и аккуратно вручную настроить метрики default gateway для кажлого из них. Ибо MS win сделает это сама как ей хочется http://support.microsoft.com/default.aspx?scid=kb;en-us;299540 . И при изменении конфигурации -- точно также переделает. Соответсвенно надо вручную назначить метрики для интерфейса и/или для каждого конктретного default gateway. Правильность проверить по route print... Если кабель не вставлен (link down), то конретного интерфейса может вообще не быть в таблице маршрутизации. А потом он "неожиданно" появится.
tip: при задании второго default gateway вылезет страшная коробка от MS с предупреждением о нескольких default gateways -- "ОК" её.
Если хочется иметь WAN2 в качестве backup (варинат N1) -- то его метрика его шлюза должна больше, чем у WAN1.
Если хочется использовать оба канала одновременно (вариант N2), то надо настраивать одинаковые метрики, но последовательность выбора интерфесов будет определяться уже порядком привязки (binding): Advanced Settings -> Adapters and Bindings см. http://www.microsoft.com/technet/community/columns/c…leguy/cg0903.mspx
фича: после изменения привязки w2k и w2k3 не просят перегрузиться, как это было в NT4, но изменения фактически вступят в силу только после перезагруки.
Что делать если в качестве одного из WAN VPN и PPPoE -- не знаю, имхо и для этого тоже все настраивается.
Далее обычно необходимо прописать вручную маршурты к "известным" ресурсам на каждом из интерфейсов. Поскольку у каждого провайдера обычно есть ряд сервисов, доступных только при подключении с определенного ("своего") IP-адреса (самое простое -- домашняя сеть со своими IP и ресурсами). А сама система совершенно "без понятия" что и куда нужно пускать и что находится за каждым DG1, DG2. Стоит расписать табличку нужных IP, внести их в соотв подсети (если IP-реальные, то самый простой вариант: посмотреть чья и какая это подсеть через whois). После изучения route /?
необходимо долго и нудно прописывать нужное по route add... Статические маршруты имеет смысл задать с метрикой меньшей, чем метрики WAN1 и WAN2.tip: лучше сначала проверить работу каждого маршрута в отдельности (ошибиться очень легко), т.е. после route add посмотреть на таблицу маршрутизации по route print и проверить маршрут с помощью tracert... А когда все заработает: либо внести все route add в bat-файл и исполнять его "на бис" при каждой перезагрузке, либо добавить -p и сделать маршруты постоянными (переживающими перезагрузку), но тогда сразу стоит писать bat-файл для очистки таблицы маршрутизации с командами route delete для каждого route add или воспользоваться -f
Уже должно работать...
Но есть тонкости. При конфигурации N1 (с разными метриками) попытки TCP-подключений к WAN2 (при живом WAN1) будут неуспешными. Хотя UDP и ICMP будет ходить исправно (засада: "ну пингуется же! а подключиться невозможно"). Исходящие же подключения будут использовать WAN1 для всех случаев, кроме явно прописанных через WAN2 маршрутов с меньшей метрикой.
При конфигурации N2 действительно оба интерфейса будут адекватно реагировать на любой входящий трафик. Исходящий же будет отправляться наружу по тому инфтерфейсу, который "привязан повыше" (метрики у них одинаковые) -- т.е. WAN1. Опять же кроме явных статических маршрутов.
Но вот если с WAN1, который "основной" в обоих случаях, начинаются проблемы и механизм определения упавшего шлюза разрешен (Dead Gateway Detection), то вся эта стройная картина рассыпается.
Собственно, поведение стека TCP/IP при возниконовении проблем (и при их окончании) является основной "засадой", не зря MS категорически не советует использовать более одного default gateway и написала по этому поводу http://support.microsoft.com/kb/159168/EN-US/ и http://www.microsoft.com/technet/community/columns/c…leguy/cg0903.mspx . Рекомендации приведены там же, но они применимы далеко не всегда...
Единственный вопрос, на который я не нашел ответа: что происходит с уже уставновленными через WAN1 TCP-соединениями. Они все рвутся сразу или постепенно и если WAN1 восстановится до обрыва всех, то оставшиеся будут продолжать работу. Вроде бы по факту -- второй вариант, но я не уверен. И сюда же можно добавить: при выключенном Dead Gateway Detection трафик так и будет упорно посылаться через WAN1??? Если кто реально отслеживал -- поделитесь сюда, pls.
ICMP и UDP не вызывают смену default gateway и также на них не отражаются последствия. Как всё это происходит и как конкретные параметры реестра влияют на этот процесс -- описано MS, пересказывать нет смысла (см ниже в ссылках). Результат (тоже честно описан MS и является скорее фичей, а не багой) такой: WAN1 перестает реагировать на попытки TCP-подключений снаружи, по факту имеем функционирование системы по варианту N1, где WAN1 и WAN2 поменялись местами. Это можно заметить по route print -- там меняется default gateway на DG2 и ipconfig показывает WAN1 без DG1(?? странно, но так оно и есть). Поскольку записи в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip не меняются, то после перезагрзуки все возвращается на свои места. Перезагрузка -- это сильно, особенно если это сервер, который подключен к двум каналам (и на нем, как водится, висит туча клиентов и добрый десяток сервисов).
По идее, если не перезагружать систему, то при возникновении проблем на WAN2 опять сменится default gateway на следующий (в данном случае на DG1) и т.д. Однако система сама по себе не вернется в конфигурацию N2.
Можно легонько "с ноги" дослать систему в исходное состояние: выдернуть кабель или отключить (disable) WAN1. При подключении интерфейса обратно, видимо, перестраивается таблица маршрутизации и опять получаем работающий вариант N2 (или N1 -- ну с ним вообще как-то все попроще). Помогает также (пере-)задание статических маршрутов (просто запускаю тот самый bat-файл, где лежат все статические маршруты).
Собственно осталась одна проблема (с двух сторон):
- как корректно принудительно переключать WAN1 и WAN2 "на лету" без переконфигурации стека TCP/IP, привязки и т.д. по любой внешней неоходимости (пример: DG1 -- доступен, ISP1 жив а от интренета отвалился или его внешний канал перегружен).
- как наиболее корректно возвращать систему в исходное состояние, когда функционирование основного канала (WAN1) пришло в норму, а стек TCP/IP об этом не знает, пока с WAN2 не начались проблемы.
Интересует теория -- я не нашел, где описано и особенно(!) практика: скрипты, программы и прочее.
Самый простой вариант: если ping куда-то (куда надо) умер/восстановился (уже некоторое время), то передернуть route или netsh чего-то... Может кто поделится реально работающим скриптиком???
нарытые ссылки по теме:
настройка стека TCP/IP (w2k) с картинками:
http://www.support.psi.com/support/common/inet-serv/…/win2k_tcpip.html
детальная информация по стеку TCP/IP (работа, реестр и параметры)
Microsoft Windows Server 2003 TCP/IP Implementation Details
http://www.microsoft.com/technet/prodtechnol/windows…king/tcpip03.mspx
кое-какие детали описаны здесь
DSL Speed Test and Tweaks Guide
http://help.montanasky.net/DSL_Info.html
читать MS kb по теме:
Default Gateway Configuration for Multihomed Computers
http://support.microsoft.com/default.aspx?scid=kb;en-us;157025
Multiple Default Gateways Can Cause Connectivity Problems
http://support.microsoft.com/kb/159168/EN-US/
Expected Behavior of Multiple Adapters on Same Network
http://support.microsoft.com/kb/175767/EN-US/
Dead Gateway Detection in TCP/IP for Windows NT
http://support.microsoft.com/kb/128978/EN-US/
TCP/IP Dead Gateway Detection Algorithm Updated for Windows NT
http://support.microsoft.com/kb/171564/EN-US/
An Explanation of the Automatic Metric Feature for Internet Protocol Routes
http://support.microsoft.com/default.aspx?scid=kb;en-us;299540
How to Configure a Default Gateway for Multihomed Computer with LAN and Internet Access
http://support.microsoft.com/default.aspx?scid=kb;en-us;262397
(старье)
The Cable Guy -- две очень полезные статьи:
Default Gateway Behavior for Windows TCP/IP: The Cable Guy - September 2003
http://www.microsoft.com/technet/community/columns/c…leguy/cg0903.mspx
Microsoft TechNet: IP Routing: The Cable Guy, December 2001
http://www.microsoft.com/technet/community/columns/c…leguy/cg1201.mspx
мало??? здесь можно покопаться:
Windows 2000 TCP/IP Resources
http://labmice.techtarget.com/networking/tcp.htm
вставить выделенную цитату в окно ответа