Как разделить веб-службу, локальный listener, Windows Firewall и внешний NAT или firewall, не отключая защиту и не предполагая конкретного облака.
Нарисуйте путь одного соединения
Запишите источник теста, публичный адрес, возможный балансировщик или NAT, адрес виртуальной машины и процесс, который должен принимать HTTP. Если один из узлов неизвестен, оставьте его как отдельную границу, а не угадывайте поставщика. Microsoft советует начинать сетевую диагностику с топологии и устройств между источником и назначением: firewall, средства инспекции и другие промежуточные узлы могут остановить пакет независимо от Windows. Проверяйте TCP/80 с внешней сети, которая не использует тот же локальный маршрут. Ping для этого недостаточен: ICMP может иметь другую политику, а тест конкретного TCP-порта проверяет именно нужную транспортную границу.
Подтвердите приложение и listener локально
На самой VM откройте локальный адрес веб-службы и сохраните HTTP-статус либо точную ошибку соединения. Затем сопоставьте TCP/80 с состоянием LISTENING, локальным адресом и PID через штатный netstat или Get-NetTcpConnection. Listener только на loopback объяснит локальный успех и внешний отказ; отсутствие listener означает, что менять внешний firewall рано. Сопоставьте PID с ожидаемой службой, не публикуя полный список процессов. Если локальный запрос не проходит или порт не слушается, остановитесь на приложении: правило доступа не создаёт процесс и не исправляет его привязку.
Проверьте активное правило без отключения защиты
Сверьте активный сетевой профиль VM и входящее правило именно для TCP/80, нужной программы или службы и ожидаемых удалённых адресов. Не выключайте Windows Firewall «для проверки»: это расширяет поверхность атаки и смешивает несколько условий. Включите на короткое контролируемое окно журнал отброшенных пакетов, повторите один внешний запрос и сопоставьте UTC-время. Microsoft указывает, что блокирующее правило имеет приоритет над разрешающим, а в узле Monitoring видны только реально активные правила. Отсутствие записи об отклонении не доказывает пропуск пакета: возможно, он вообще не дошёл до гостевой ОС.
Локализуйте внешний маршрут и остановитесь
Если приложение отвечает локально, listener корректен и host firewall не фиксирует отказ, проверьте привязку публичного адреса, DNAT или port-forward и upstream ingress-rule у владельца инфраструктуры. Нужен точный протокол TCP, внешний и внутренний порт 80, правильная VM и обратный маршрут. Сравните один внешний тест с журналом гостевой системы: пакет виден на VM — исследуйте локальный ответ; пакета нет — граница выше Windows. Для эскалации достаточно схемы без реальных IP, UTC-времени, внешнего результата, локального HTTP-статуса, listener/PID и признака записи firewall. Не прикладывайте учётные данные, полный дамп трафика или конфигурацию облачного аккаунта.
Материал подготовлен редакцией VOne с применением ИИ для структурирования; факты о TCP-проверках и Windows Firewall вручную сверены с Microsoft Learn, а публичная ветка использована только как обезличенный сигнал.
Источники и проверка
- Microsoft Learn — TCP/IP communication troubleshooting guidance проверено 2026-08-03
- Microsoft Learn — Windows Firewall with Advanced Security troubleshooting проверено 2026-08-03
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.