Написание службы регистрации в сети

[Dimka]

Есть внешняя Wi-Fi сеть провайдера.
Есть проводная локальная сеть из N машин под управлением Windows Server 2003.
Каждая машина локальной сети имеет одно беспроводное соединение для подключения к внешней сети.
На каждой машине поднят маршрутизатор, в котором прописаны: default-маршрут на собственное беспроводное соединение с меньшей статической метрикой; default-маршруты на каждую другую машину сети с большей статической метрикой, чем у беспроводного соединения, но одинаковой для всех таких маршрутов.

Задумывается следующее поведение сети. Беспроводные соединения ненадёжны, периодически падают и поднимаются случайным образом. В случае падения собственного беспроводного соединения маршрутизатор этой машины выбирает в качестве текущего какой-то другой default-маршрут для трафика. В случае подъёма собственного беспроводного соединения, маршрутизатор восстанавливает default-маршрут на собственное беспроводное соединение.

В случае подъёма Wi-Fi соединения нужно производить перерегистрацию у провайдера, которая действует в течение определённого времени, затем требуется перерегистрация. Для прохождения регистрации имеется соответствующий web-интерфейс, и написан скрипт/программа, который/ая это делает автоматически. Вопрос заключается в том, когда его/её вызывать?

В случае стабильного единственного соединения всё просто: служба вызывается каждый раз по истечении установленного провайдером периода действия. В случае первого запуска через web-интерфейс она получает оставшееся количество минут до перерегистрации.

В случае нестабильных множественных соединений возникают варианты. Служба регистрации ставится на каждый сервер, и возможны два пути:

1) Служба регистрации, которая всегда обращается к web-серверу регистрации по текущему default-маршруту. Какой бы маршрут не был установлен, служба регистрации зарегистрирует текущее беспроводное соединение на любом сервере. При этом возникает ряд проблем:
- при единственном рабочем соединении все N серверов одновременно начнут перерегистрацию соединения по истечении срока действия предыдущего - будет зафлуживание сервера регистрации у провайдера (случай маловероятный);
- в случае подъёма собственного соединения, служба регистрации должна "забыть", что работала по другому маршруту, и установить регистрацию собственного соединения;
- аналогично, в случае падения собственного соединения, служба регистрации должна "забыть", что работала через собственное соединение, и установить регистрацию по текущему default-маршруту.

2) Служба регистрации пытается обращаться к web-серверу только по собственному беспроводному соединению.

Второй вариант предпочтительней, но каким образом HTTP-трафик на определённый сервер (с известным IP) можно принудительно заставить уходить на определённый интерфейс, даже если этот интерфейс опущен? (Речь только про штатные средства Windows Server 2003, всякие там iptables не предлагать.)

Пока что попытки задать статический маршрут с высшей метрикой ни к чему не привели. Маршрутизатор находит этот маршрут, но видит, что интерфейс опущен, поэтому перебрасывает трафик по другому default-маршруту.

Первый вариант становится приемлемым лишь в том случае, когда служба регистрации сможет получить от Windows сигнал об изменении состояния интерфейса или (что вернее и надёжнее) от маршрутизатора сигнал о смене текущего default-маршрута. Каким образом этот  сигнал можно заполучить?

[Sla]

мысль шальная, а вдруг прокатит
NAT & forwarding портов

[sss]

1. То есть вопрос - как это сделать существующими средствами операционной системы, а не - как это сделать в коде ?

2. Если IP регистратора известен, почему бы не прописать постоянный маршрут на этот IP с жесткой маской ?

[Dimka]

2. Если IP регистратора известен, почему бы не прописать постоянный маршрут на этот IP с жесткой маской ?

Я же написал:

Пока что попытки задать статический маршрут с высшей метрикой ни к чему не привели. Маршрутизатор находит этот маршрут, но видит, что интерфейс опущен, поэтому перебрасывает трафик по другому default-маршруту.

В хелпах написано что-то про статические (static) и автостатические (autostatic) маршруты. Первые должны существовать вне зависимости от состояния интерфейса. Но каким образом их задать? В консоли службы маршрутизации создаваемые статические маршруты по факту работают как автостатические. Может галочка какая есть где?

мысль шальная, а вдруг прокатит
NAT & forwarding портов

А поподробнее? NAT есть и так. Что понимается под forwarding'ом портов, и как его явно задать?

1. То есть вопрос - как это сделать существующими средствами операционной системы, а не - как это сделать в коде ?

В коде чего? HTTP-клиент регистратора действует на 7-м (прикладном) уровне сети. Маршрутизация осуществляется на 3-м (сетевом) уровне. Для HTTP маршрутизация прозрачна.

Т.е. речь не о коде HTTP-клиента, а о неком addin к маршрутизатору или к службе сети операционной системе, который бы умел ловить события падения/подъёма интерфейсов или смены динамических метрик маршрутов и, обрабатывая эти события, запускал бы в нужные моменты HTTP-клиент, выполняющий регистрацию.

[sss]

Перефразирую:

1. Регистратор написан тобой?

2.
    route add 192.168.0.100 mask 255.255.255.255 192.168.0.1 /p
    , где 192.168.0.100 - адрес регистратора (провайдер WiFi);
             192.168.0.1     - адрес клиента на котором добавляется маршрут;
             /p                     -  параметр постоянного маршрута.

    Конечно, в таблицах уже должен быть маршрут подсети,  подключенной напрямую.

     192.168.0.0  255.255.255.0  192.168.0.1 192.168.0.1  1
 
Маршрутизация в сеть, подключенную напрямую не будет пересылаться в шлюз. Я не претендую, что все у тебя сразу заработает.  Регистратор в WiFi сети имеет постоянный IP ( напр. 192.168.0.100) ? Компьютер клиент, подключаемый к сети WiFi имеет постоянный IP (напр. 192.168.0.1)  ?

[Sla]

sss, в случае наличия ДВУХ! gatewayев, с разными метриками, винда в случае "потери" основного - с меньшей метрикой -, переходит на второй, а на превый и не думает возвращаться. Лечится - переинициализацией интерфейса.
Отследить потерю шлюза, мне не удалось в LANовской сети.

Можно пробовать пользуя netsh, тем более в W3K он более продвинут.

[Dimka]

sss, в случае наличия ДВУХ! gatewayев, с разными метриками, винда в случае "потери" основного - с меньшей метрикой -, переходит на второй, а на превый и не думает возвращаться. Лечится - переинициализацией интерфейса.

Подтверждаю. Более того, эта дура, если выбрала очень хороший default-маршрут (по скорости и надёжности), то даже при его явном удалении из списка статических маршрутов, продолжает слать трафик через него. И что с этим делать, я пока не понял. Помогал лишь перезапуск службы маршрутизации

2.
    route add 192.168.0.100 mask 255.255.255.255 192.168.0.1 /p
    , где 192.168.0.100 - адрес регистратора (провайдер WiFi);
             192.168.0.1     - адрес клиента на котором добавляется маршрут;
             /p                     -  параметр постоянного маршрута.

Попробую ключик /p, может, действительно, будет статический, а не автостатический маршрут.
Регистратор собственный.
IP шлюза фиксированный для всех WiFi соединений, на нём же висит web-сервер регистрации.
IP клиента динамический, получается по DHCP.

[sss]

Причем здесь два шлюза и подсеть подключенная напрямую? Пакеты, направляемые в подсеть подключенную напрямую не пересылаются в шлюз. Если происходит передача пакета в подсеть WiFi через шлюз значит надо добавить еще маршрут.

route add  192.168.0.0  mask 255.255.255.0  192.168.0.1 /p

Сложность в DHCP конечно... При исчезновении подключения, автоматический маршрут исчезнет, а статический маршрут, может ошибаться со значением шлюза. Что делать если не программировать ситуацию, а использовать системные настройки - пока не знаю...

Если регистратор твой, привяжи сокет к локальному интерфейсу, подключенному к сети WiFi.

Теперь на счет обнаружения потери соединения:

Если создается служба, то ее можно настроить на прием кодов
SERVICE_ACCEPT_NETBINDCHANGE, что позволит получать уведомления:

 SERVICE_CONTROL_NETBINDADD
 SERVICE_CONTROL_NETBINDREMOVE
 SERVICE_CONTROL_NETBINDENABLE
 SERVICE_CONTROL_NETBINDDISABLE

Я думаю что ОС > NT 4.0 ?

[Dimka]

sss, ключ /p смысла не имеет, поскольку при отсутствии интерфейса маршрут не работает. Интерфейс же имеет склонность к падению, сопровождаемому его исчезновением из списка интерфейсов. К сожалению, нет такого, чтобы интерфейс оставался в списке в состоянии down.

Ты напрасно тратишь время, объясняя мне, какие куда маршруты должны быть прописаны, и как пользоваться шлюзами. Всё давно прописано, и это к проблеме отношения не имеет. К проблеме имеет отношение тот факт, что маршруты на упавший интерфейс не работают. Это, конечно, с одной стороны, логично, но в моём случае нежелательно. Всё остальное касаемо набора необходимых маршрутов к делу не относится -- у меня десятка два разных маршрутов на разные шлюзы.

Если регистратор твой, привяжи сокет к локальному интерфейсу, подключенному к сети WiFi.

Подробнее? Я сокетами напрямую не пользуюсь, они инкапсулированы в реализации адаптера HTTP-протокола. Если только этот адаптер настраиваемый...

Я думаю что ОС > NT 4.0 ?

Если внимательно почитать первый пост темы, там можно найти множество деталей, которые устраняют кучу вопросов. В частности, версия ОС, условия работы и т.п.

Если создается служба, то ее можно настроить на прием кодов

Кто (если это важно) указанные сигналы посылает? Всякая ли служба их может перехватить и обработать, или нужна специальным образом написанная и/или запущенная служба? Каким образом в службе вешаются обработчики этих сигналов (желательно средствами чистого WinAPI).

[sss]

Только сейчас попробовал. Если сетевой кабель не подключен - добавить маршрут не удается. Подключаю провод - добавляю постоянный маршрут и отключаю провод. Маршрут на месте !!! Может все таки попробуешь понять что я хочу сказать? Что значит два десятка маршрутов ? Два десятка шлюзов??? Ладно. Служба указывает возможность приема управляющих кодов в структуре SERVICE_STATUS которую передает в вызове SetServiceStatus(...). После этого вызова, процедура Handler службы начнет получать нотификационные коды. Теперь сокет. Вначале создаешь сокет (socket), затем привязываешь его к интерфейсу (bind) и подключаешься (connect). Как получить информацию об локальных интерфейсах? Вот пример:

Код:

int ret = WSAIoctl( s, SIO_GET_INTERFACE_LIST, 0, 0, m_pInterfaces, m_uSize, &dwBytes, NULL, NULL);

[Dimka]

Маршрут на месте !!! Может все таки попробуешь понять что я хочу сказать?

Может ты попробуешь понять, что я в начале говорил? От того, что маршрут наличествует в списке, ничего не меняется, так как трафик всё равно перебрасывается на default-маршрут, вместо того, чтобы пропадать в опущенном интерфейсе.

Что значит два десятка маршрутов ? Два десятка шлюзов???

Шлюзов, конечно, поменьше. Всего 4. И чего?

По остальному сейчас посмотрю.

[Sla]

dimka,
покажи
  ipconfig
  route show