NAT traversal (постановка)

Текущая версия на 20:24, 8 февраля 2016

Описанная ниже схема не отменяет действующего механизма, когда на мобильном устройстве прописан адрес с портом, а на файрволле предприятия настроен статический роут на внутренний компьютер.

Терминология:

• Сервер предприятия -- gedemin.exe в качестве веб-сервера, обслуживающий запросы мобильных приложений.
• Хаб -- gedemin.exe в качестве веб-сервера, где регистрируются серверы предприятий и куда мобильные приложения обращаются за адресами серверов предприятий.
• Мобильное приложение -- android приложение, которое обращается к серверу предприятия за данными. Адрес сервера предприятия мобильное приложение узнает, послав запрос на хаб.
• Внешний адрес сервера предприятия -- адрес и порт сервера предприятия, под которым он виден из сети интернет.
• Внутренний адрес сервера предприятия -- адрес и порт сервера предприятия в локальной сети предприятия.

[править] Хаб

Один из серверов выступает в роли хаба, где регистрируются сервера предприятий и куда обращаются мобильные приложения за адресами.

Только сервера предприятий, прописанные в таблице WEB_HUB, обслуживаются хабом. Таблица служит основой для бизнес-класса TgdcWebHub и имеет структуру:

 ...
 allowedip   -- Список допустимых внешних адресов. Может указываться как только 
                адрес, так и адрес с номером порта. Если пустой, то мы разрешаем
                регистрацию сервера предприятия с любым внешним адресом.
 aliases     -- Список алиасов, через запятую, обслуживаемых данным сервером 
                предприятия. Если пустой, то мобильные приложения смогут 
                подключиться только по адресу. Алиасы не чувствительны к регистру.
 companyruid -- РУИД организации.
 computerid  -- id компьютера сервера.
 waittimeout -- Промежуток времени, в течение которого мы не будем беспокоиться, 
                если сервер не отозвался. По истечении этого промежутка сервер
                считается неактивным.
 primaryserver- Если флаг установлен, то сигнализируем администраторам как только
                данный сервер станет неактивным. Если флаг не установлен, то 
                сигнализируем только в том случае, если неактивными стали ВСЕ
                сервера для данного предприятия.
 lastactive  -- Дата и время последней регистрации (обновления) сервера на хабе.
 lastip      -- Внешний адрес и порт сервера предприятия из последней
                регистрации (обновления). 
 sessionid   -- ИД сессии, который был присвоен в момент последней регистрации 
                сервера предприятия.
 accessdenied-- Флаг "отказано в доступе". Адрес сервера предприятия не будет 
                передан в мобильное приложение. Вместо этого будет передан 
                код и текстовое сообщение.
 usermessage -- Сообщение, которое будет передано пользователю.
                Мобильное приложение отображает это сообщение на экране.
                Используется в коомбинации с флагом accessdenied.
                Пример сообщения: "Сервер находится на плановом обслуживании.
                С 14:00 до 16:00".
 adminemail  -- Адреса электронной почты, через запятую, для уведомления о 
                недоступности сервера.
 ...
 

Таблица WEB_HUB_LIMIT задает ограничение на количество устройств, имеющих доступ к серверу предприятия.

 ...
 companyruid
 maxcount
 ...

Таблица WEB_HUB_DEVICE содержит список устройств подключавшихся к серверу предприятия. Используется для контроля максимального количества.

 ...
 companyruid
 deviceid
 ...  
 

При запуске хаб считывает всю информацию в оперативную память и в дальнейшем обращается к базе данных только для обновления информации.

[править] Сервер предприятия

Сервер предприятия активируется через файл gedemin.ini. В рамках решения данной задачи добавляем или расширяем следующие параметры:

 [WEB SERVER]
 ...
 Bindings        = адрес, к которому будет привязан сервер предприятия.
 Register        = 1 -- флаг указывает, что веб сервер должен 
                   зарегистрироваться на хабе. По умолчанию равен 0.
 RegisterPeriod  = 580 -- период в секундах, через который сервер
                   обновляет информацию о себе на хабе. По умолчанию
                   580 сек, так как есть информация, что на некоторых
                   свитчах и файрволах используется 10-ти минутный
                   интервал времени, в течение которого сохраняется
                   информация о соответствии внутреннего адреса и
                   внешнего порта. 

Допустимые значения для Bindings:

• адрес:порт
• адрес -- будет использован порт 80
•  :порт -- будет использован локальный адрес и заданный номер порта
• пустое значение -- локальный адрес и порт 80

Если на компьютере несколько локальных адресов и в Bindings адрес не прописан, то будет взят любой из них.

Узнать к какому именно адресу и номеру порта привязан сервер можно в окне О программе.

[править] Сценарий регистрации

1. Запускается сервер предприятия.
2. Если параметры из gedemin.ini указывают что сервер активен, но не должен регистрироваться на хабе, то работает старый механизм.
3. Если параметры из gedemin.ini указывают на необходимость регистрации на хабе, то шлется запрос на зашитый в экзешник адрес (например, gs.selfip.biz:47002/web_register).
4. На хаб передается id компьютера и ruid текущей рабочей организации.
5. Если хаб недоступен, то сервер переходит в неактивное состояние. На экран и в лог выдается сообщение о полученной ошибке. Для повторной попытки подключиться к хабу Гедымин должен быть перезапущен, о чем должно быть сказано в сообщении.
6. Хаб сверяет переданный ид компьютера и руид организации с информацией в WEB_HUB.
7. Если сервер предприятия не прописан на хабе то возвращается соответствующий код. Сервер предприятия выдает на экран и в лог сообщение.
8. Хаб регистрирует сервер предприятия и возвращает ИД сессии. Данные регистрации сохраняются в таблице WEB_HUB и в структуре в оперативной памяти.

[править] Сценарий обновления

1. Сервер предприятия с заданным периодом обращается на хаб с запросом обновления, передавая id компьютера, ruid текущей рабочей организации и id сессии.
2. Если переданные параметры и внешний адрес совпадают, то хаб обновляет значение lastactive и возвращает код успеха.
3. Если параметры совпадают, но внешний адрес отличается, то мы имеем проблему с организацией NAT на файрволе предприятия. Обновляем параметры в таблицеи структуре в памяти. Пишем сообщение в лог и выводим на экран. Возможно стоит уменьшить интервал автоматического обновления на сервере предприятия.
4. Если пришел запрос на обновление, но регистрации такого сервера не было, то имеем сбой в нашей программе. Заносим в лог и выводим на экран.

[править] Контроль состояния сервера предприятия

1. Хаб периодически просматривает список серверов.
2. Если с момента регистрации (обновления) сервера прошло времени больше, чем указано в waittimeout, то сервер считается неактивным.
3. Если для сервера установлен флаг primaryserver, то по списку email администраторов из записи этого сервера рассылаются уведомления.
4. Если флаг не установлен, то уведомления рассылаем если неактивны ВСЕ сервера для данного предприятия. Список email формируется из всех записей неактивных серверов.
5. Если хаб был перезагружен, то время проверки отсчитываем не от времени регистрации (обновления), которое берем из таблицы БД, а от времени загрузки.

[править] Мобильное приложение

Если адрес прописан пользователем непосредственно или используется алиас, прошитый в коде, то все работает по-старому. Алгоритм, описанный ниже, относится только к связи с использованием хаба.

1. Приложение помнит адрес, порт и время последнего сеанса связи с сервером предприятия.
2. Если с момента последней связи прошло времени меньше, чем установлено константой, то пытаемся связаться по сохраненному адресу, не запрашивая хаб.
3. Если мы не можем связаться с сервером предприятия по сохраненному адресу (тайм аут или иной код ошибки), то не выдаем никаких сообщений пользователю, а идем на хаб за новым адресом.
4. Если хаб недоступен, выводим соответствующее сообщение об ошибке.
5. Если хаб вернул код ошибки (алиас неизвестен или отказано в доступе), то выдаем пользователю соответствующее сообщение.
6. Если мы не можем соединиться с сервером предприятия по полученному от хаба адресу (тайм аут или код ошибки), то выдаем пользователю сообщение.
7. Важно, чтобы сообщения пользователю позволяли однозначно идентифицировать проблему. Т.е. при жалобе пользователя мы должны сразу идентифицировать что произошло: недоступен хаб, подключение запрещено, недоступен сервер предприятия и т.п.
8. Хаб ведет учет ИД подключенных устройств и, если превышено ограничение на их количество, то устройству возвращается не адрес сервера предприятия, а соответствующий код и сообщение.