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

Невозможно получить доступ к OWA из Интернета

Я не могу получить доступ к своему серверу Exchange с ноутбука, находясь вне локальной сети, используя плагин exquilla через Thunderbird.

Сервер Exchange находится во внутренней сети, и порт правила NAT перенаправляет трафик на сервер Exchange.

Когда я использую только полное доменное имя без / owa, время ожидания запроса истекает. Если я добавлю / owa, я получу:

404 Not Found

nginx 

Это происходит только тогда, когда я использую удаленное соединение. Если я подключен к локальной сети и подключаюсь к серверу Exchange, используя полное доменное имя, я могу без проблем использовать все эти ресурсы. Я уже тестировал со своего смартфона, и почта и Интернет работают нормально.

<обновлено> Этот веб-сайт находится в сети по результатам проведенного мной веб-теста. Я могу получить доступ через 4G в своем смартфоне. <обновлено>

Я действительно не могу понять, что происходит.

Характеристики сети:

Характеристики клиента для ноутбука:

Характеристики клиента для смартфона:

ОБНОВИТЬ:

Нет доступа из двух частных сетей с разными операторами связи. Я могу получить доступ только через третьего оператора в моем смартфоне, подключенном напрямую к 3 / 4G. Я тестировал этот ноутбук с Windows, MacOS и со своим смартфоном.

ОБНОВЛЕНИЕ 2:

Существует правило NAT для пересылки с общедоступного порта 443 на частный сервер x на порт 443. В этом маршрутизаторе нет ACL и конфигурации прокси.

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

ОБНОВЛЕНИЕ 3:

Я думал что nginx был моим веб-сервисом, но похоже, что это не так, я ищу его и ничего. Даже в терминале с использованием nginx -h и у меня даже Telnet Locahost 80 (prntscr.com/ekqeox). Простите за неверное предположение! Я считаю, что этот веб-сервис по умолчанию поставляется с Exchange. Эта установка была сделана не мной.

ОБНОВЛЕНИЕ 4:

Я поменял свой маршрутизатор на новый по другой причине, и эта проблема все еще сохраняется. Я также заметил, что есть пользователь, который даже не может получить доступ к этой частной сети, только через частный IP. У меня также есть еще одно полное доменное имя в запущенных dyndns, и внутри этой частной сети оно ведет на страницу конфигурации моего маршрутизатора, а с / owa - на страницу, где работает nginx. Извне эта ссылка ведет на нужный сайт.

ОБНОВЛЕНИЕ 5:

Поскольку эта проблема вызывает затруднения, я возобновлю ее.

У меня есть два FQDN, указывающих на статический IP-адрес, который используется в порту WAN. Один установлен на удаленном сервере, remote.x.pt (FQDN1), другой установлен dyndns, x.dyndns.biz (FQDN2).

В моем pfsense у меня есть правило NAT для перенаправления трафика на внутренний сервер с порта 443 на порт 443.

Я блокирую трафик каждой сети в моем маршрутизаторе pfsense, это две сети.

Я изменил GUI конфигурации маршрутизатора https на порт 8080.

Итак, это результат трех возможных сценариев, где последние два находятся внутри моего маршрутизатора pfsense:

Из Интернета:

FQDN1: может получить доступ к веб-службе. FQDN2: может получить доступ к веб-службе. Частный IP-адрес: может получить доступ к веб-службе.

Из внутренней сети, где находится сервер:

FQDN1: может получить доступ к веб-сервису. FQDN2: он показывал графический интерфейс маршрутизатора, но теперь ничего нет, а с дополнительными данными местоположения, такими как / owa, который является моей службой веб-почты, я получаю ошибку nginx, говоря, что страница не найдена. Частный IP-адрес: тот же вывод из FQDN2

Из сети посетителей:

FQDN1: невозможно получить доступ к веб-сервису, он говорил, что перед подключением отказано из-за брандмауэра, но теперь после изменения порта он ничего не показывает. FQDN2: тот же вывод из FQDN1. Частный IP: тот же вывод из полных доменных имен.

Маршрутизаторы Draytek часто используют порт 443 для своих целей - либо SSL VPN, либо удаленное управление. Зайдите в конфиг роутера, проверьте используемые порты. Даже если вы не используете SSL VPN, измените порт (например, 4433). Убедитесь, что у вас не включено управление маршрутизатором из Интернета, а также измените внутренний порт для управления маршрутизатором на HTTPS.

OWA обслуживается IIS. Я вижу ошибку nginx, проверьте перенаправление маршрутизатора.

Поскольку ошибка 404 просто означает, что ваш сервер nginx не обслуживает этот URL-адрес OWA, что является нормальным, но это означает, что веб-сервер отвечает вам, даже если он неправильный ..