Я не могу получить доступ к своему серверу 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, что является нормальным, но это означает, что веб-сервер отвечает вам, даже если он неправильный ..