Коротко — скорее всего проблема не в «маршруте на клиенте», а в том, что трафик либо не доходит до сервера (или доходит, но ответы к клиенту теряются), либо сервер/пограничное устройство начали блокировать IP/подсеть «Работы». Ниже — список причин и конкретных шагов для проверки и локализации проблемы.
Что проверить в первую очередь (приоритетно)
1. Проверка имени vs IP
- На проблемном ПК: nslookup <имя_сервера> — совпадает ли разрешение имени в сетях «Дом» и «Работа»?
- Попробуйте подключиться по IP сервера (чтобы исключить DNS).
2. Проверить доступность и порт
- ping <IP_сервера>
- tracert <IP_сервера> (Windows) — где обрывается маршрут?
- Test-NetConnection/PowerShell: Test-NetConnection -ComputerName <IP> -Port <порт> (или telnet <IP> <порт>) — слушает ли нужный порт?
3. Маршрут и исходный адрес на клиенте
- route print / ipconfig /all — правильно ли уходит трафик по ожидаемому шлюзу и какой у клиента исходный IP?
- Если вы пытались «направлять через Дом» (VPN/маршруты) — убедитесь, что сервер видит IP клиента именно из этого VPN. Частая ошибка: клиент отправил пакет через VPN, а сервер отвечает на исходный (Work) IP и ответ теряется.
4. Трассировка от сервера к клиенту
- С сервера: traceroute/tracepath к IP клиента. Возвращается ли ответ? Это покажет асимметричный маршрут.
5. Захват пакетов
- На сервере: tcpdump -i any host <IP_клиента> and port <порт> — приходят ли SYN-пакеты от Work? Сервер посылает RST/SYN-ACK?
- На клиенте: Wireshark — уходит ли SYN, приходят ли ответы?
Если клиент отправляет, а на сервер не приходит — проблема в промежуточной сети/фильтрах. Если сервер получает, но не отвечает/ответ не доходит — проблема в ответном пути / stateful-файрволе.
6. Проверка файлов и блокировок на сервере
- firewall (iptables/ufw/Windows Firewall) — есть ли блок по IP/сети «Работа»?
- fail2ban / denyhosts / IDS — не заблокировали ли подсеть «Работа» массовыми попытками?
- Логи сервера (auth, application, firewall) на время первых проблемных соединений.
7. Проверка пограничных устройств (маршрутизатор/файрвол)
- Нельзя исключать, что админ сети «Работа» внес правило блокировки внешнего хоста/подсети, или провайдер/ISP фаервол начал фильтровать.
- Проверьте ACL на роутере/файрволе, NAT/policy routing, списки блокировок.
8. VPN/КВН (если имели в виду VPN)
- Убедитесь, что VPN не ломает маршрут и что исходный IP, видимый серверу, корректен. Проверьте политики VPN (split-tunnel, source NAT).
- Если вы «перенаправляли через Дом», возможно ответы сервера идут напрямую на Work-IP и теряются — нужно настроить NAT исходящих пакетов через тот же интерфейс.
Возможные основные причины
- Блокировка на сервере по IP/подсети (правила файрвола, fail2ban).
- Изменение правил на пограничном маршрутизаторе/корпоративном фаерволе (ACL).
- Ассиметричная маршрутизация / NAT: пакеты идут по одному пути, ответы — по другому и теряются на stateful-файрволе.
- DNS-различия (имя разрешается в разный IP в разных сетях).
- Провайдер/корпоративный прокси/фильтр блокирует доступ.
- IP-конфликт или проблема с ARP/коммутатором на стороне «Работы».
Что я рекомендую сделать дальше (шаги, которые пришлите мне для помощи)
1. С клиентской машины (Работа) пришлите вывод:
- ipconfig /all
- route print
- nslookup <имя_сервера>
- tracert <IP_сервера>
- результат Test-NetConnection/Telnet к порту сервиса
2. На сервере — проверить логи, firewall и запустить tcpdump (или прислать вывод tcpdump при попытке подключения).
3. Если можно, проверьте с внешней сети (мобильный интернет) — работает ли сервер; если работает, значит блокировка направлена именно на подсеть «Работа».
Если пришлёте результаты указанных команд (или скриншоты), помогу проанализировать и скажу, где именно «теряется» трафик и что править.