Центр удаленного доступа- Использование различных методов подключения сервера к сети  (раздел целиком)  (26.07.2026)
Использование различных методов подключения сервера к сети

1. Использование NAT

Механизм NAT описан в rfc1631 и в rfc3022 .

Работа через NAT полностью поддерживается, и не должна вызывать каких-либо затруднений. Рассмотрим пример.
NAT

Допустим, на сервере, обозначенном как "наш сервер", установлен наш сервис. "Наш сервер" слушает IP-адрес внутренней сети 192.168.4.110, порт 8090. В таком случае он доступен пользователям во внутренней сети через url http://192.168.4.110:8090. NAT-сервер, имеющий внешний IP 212.158.161.21, устанавливает соответствие своего порта 8099 и порта 8090 локального хоста 192.168.4.110. На рисунке показано это правило для одного из "бытовых" роутеров (нас интересует последнее правило в списке):
NAT на роутере
Благодаря этому, сервис доступен "снаружи" через url http://212.158.161.21:8099.

При настройке удаленного доступа приложений Win32 к этому серверу, вам необходимо указать в поле " Хост сервера " строку " 212.158.161.21:8099 " (без кавычек), поле "Путь серверного proxy" оставить пустым. Во всех случаях номера стандартных портов можно не указывать, а IP-адреса заменить соответствующими им доменными именами.

При использовании механизма "Restricted NAT", "Наш сервер" будет лишен возможности получить реальные IP-адреса удаленных пользователей, все запросы он будет видеть приходящими с одного и того же адреса. Если вы используете Restricted NAT, то вы

  • лишаетесь возможности протоколировать IP-адреса
  • в поле "Способ идентификации сессии" на странице " Параметры сетевых настроек " не сможете использовать способы, опирающиеся на IP-адрес (фактически, вам доступен только способ "Использовать идентификатор"). Это приведет к невозможности работы с сервисом пользователей, не имеющих соединения с постоянным IP-адресом.

2. Использование серверного proxy

Допустим, мы имеем следующую схему подключения:
Proxy

Допустим, на сервере, обозначенном как "наш сервер", установлен наш сервис. "Наш сервер" слушает IP-адрес внутренней сети 192.168.4.110, порт 8090. В таком случае он доступен пользователям во внутренней сети через url http://192.168.4.110:8090. На сервере, обозначенном как "Proxy-сервер", установлен web-сервер apache, конфигурационный файл которого содержит, помимо прочего, следующие строки:

01Listen 8099
02  ...
03  LoadModule proxy_module modules/mod_proxy.so
04  ...
05  ProxyPass /mysite/mysite1/mysite2/ http://192.168.4.110:8090/
06  ...
07  <Proxy /mysite/mysite1/mysite2/*>
08    Order allow,deny
09    Allow from all
10    ...
11  </Proxy>
12  ....
Proxy-сервер имеет внешний IP 212.158.161.21. То есть, все обращения, поступающие на proxy-сервер на url вида http://212.158.161.21:8099/mysite/mysite1/mysite2/.... будут перенаправлены им на наш сервер, а ответ нашего сервера будет возвращен удаленному клиенту (в этом смысл работы механизма proxy). Благодаря этому, сервис доступен "снаружи" через url http://212.158.161.21:8099/mysite/mysite1/mysite2/parusproxyjs/index.html (вам придется указывать полный путь именно в таком виде, иначе мы не сможем разрешить относительные ссылки на страницах).

При настройке удаленного доступа приложений Win32 к этому серверу, вам необходимо указать в поле " Хост сервера " строку " 212.158.161.21:8099 " (без кавычек), в поле " Путь серверного proxy " указать строку " /mysite/mysite1/mysite2 " (без кавычек). Во всех случаях номера стандартных портов можно не указывать, а IP-адреса заменить соответствующими им доменными именами.

При использовании серверного proxy "Наш сервер" будет лишен возможности получить реальные IP-адреса удаленных пользователей, все запросы он будет видеть приходящими с одного и того же адреса. Если вы используете серверный proxy, то вы

  • лишаетесь возможности протоколировать IP-адреса (протоколирование должно быть возложено на proxy-сервер)
  • в поле "Способ идентификации сессии" на странице " Параметры сетевых настроек " не сможете использовать способы, опирающиеся на IP-адрес (фактически, вам доступен только способ "Использовать идентификатор"). Это приведет к невозможности работы с сервисом пользователей, не имеющих соединения с постоянным IP-адресом.

2.1. Поддержка соединения для запросов выполняющихся длительное время (более 1-2 мин)

При работе сервиса через серверный прокси, запросы, выполняющиеся на сервере СУБД, продолжительное время (более 1-2 мин), могут быть расценены серверным прокси как запросы, на которые не поступил ответ (серверный прокси не дождался ответа сервера приложений за отведенное время), и ответить клиенту ошибкой.

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

Пример
В nginx, в его конфиге нужно указать - proxy_read_timeout 300s; #вместо 300 сек укажите свое значение, по умолчанию nginx использует 1 мин.