Кратко — самое вероятное: проблема с NAT-петлёй (hairpin NAT / NAT reflection) или с правилами маршрутизации/фаервола на шлюзе: из локальной сети запросы на внешний (белый) IP домена уходят на шлюз, но он не «заворачивает»/не форвардит TCP‑сессии обратно во внутреннюю сеть. Почему ICMP проходит, а сервисы — нет: шлюз может отвечать на пинг сам или пропускать ICMP, но блокировать/неправильно обрабатывать TCP DNAT/SNAT для трафика с внутренней сети к своему же публичному IP.
Причины, кратко:
- Нет или выключен hairpin NAT на маршрутизаторе/фаерволе.
- Правила DNAT/port‑forward настроены только для трафика из внешнего интерфейса, не для внутренних источников.
- Conntrack/таблица трансляций переполнена или есть stateful‑правила, которые сбрасывают сессии.
- Изменение маршрута/обновление прошивки/правил на шлюзе, либо изменение DNS (кэш).
- Сервер слушает только на внешнем интерфейсе/имеет неадекватные сетевые настройки (если у него нет локального адреса, ответы могут некорректно маршрутизироваться).
Что проверить (порядок и команды; подставьте ваш внешний IP вместо $...$):
1) На клиенте:
- ping $...$ - traceroute -n $...$ или tracert $...$ - telnet $...$ $...$ или curl -v http://domain.company.ru
2) На шлюзе/фаерволе — смотрите логи и правила NAT/DNAT, включён ли hairpin NAT (варианты зависят от производителя).
3) На сервере:
- netstat/ss: netstat -tulpn | grep :$...$ - tcpdump: sudo tcpdump -nni any host $...$ and port $...$ (смотреть, доходят ли SYN от локальных клиентов)
4) На шлюзе — делайте tcpdump параллельно, чтобы понять, где теряется TCP‑пакет.
Варианты решения:
- Включить/настроить hairpin NAT на маршрутизаторе/фаерволе (если поддерживается).
- Сделать split‑horizon / внутреннюю DNS‑запись для domain.company.ru, чтобы внутри возвращался локальный IP сервера (лучшее решение).
- Добавить запись hosts на клиентах или использовать внутренний маршрут к серверу.
- Если серверу нужен локальный адрес — добавить внутр. IP на интерфейс сервера и использовать лок. адрес внутри сети.
- Проверить и поправить правила DNAT/SNAT/INPUT/FORWARD на шлюзе и лимиты conntrack.
Резюме: наиболее вероятно — отсутствие или сбой NAT‑рефлексии на шлюзе. Самый надёжный и чистый путь — настроить внутри DNS, чтобы домен резолвился во внутренний адрес, либо включить hairpin NAT на оборудовании.