Почему Test-NetConnection показывает, что подключение возможно, но я не могу зайти на сайт?

Мне нужно определить, доступен ли конкретный сайт через определенный порт, учитывая, что в сети существуют ограничения брандмауэра.

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

Я хотел знать, могу ли я получить репозиторий из Гитхаб используя URL-адрес https репо. Пример URL-адреса https: https://github.com/git-for-windows/git.git. Это можно использовать с клон и другие инструменты.

Чтобы увидеть, смогу ли я достичь Гитхаб и, в дополнение, клонировать репо, я выполнил следующую команду: Test-NetConnection -ComputerName github.com -Port 443 |findstr "TcpTestSucceeded"

В системе эта команда вернула следующее, указывающее, что мне удалось связаться github.com через порт 443 (https).

TcpTestSucceeded: Истина

Однако затем я открыл веб-браузер и посетил https://github.com, и веб-браузер указал, что соединение не может быть установлено. https через порт 443 и домен github.com так же, как то, что я положил в тесте.

Мои вопросы:

• Почему такое несоответствие между двумя тестами?
• Как я могу точно проверить CMD или же PowerShell есть ли у меня доступ к определенному домену через определенный порт?

Очевидно, Тест-NetConnection команда не дала точных результатов, так как веб-браузер не смог получить github.com.

Очевидно, что команда Test-NetConnection не дала точного результата. результаты, так как веб-браузер не смог получить доступ к github.com.

Это не точное утверждение.

Test-NetConnection действительно установил TCP-соединение с портом 443 целевого сервера, убедившись, что TCP-порт 443 на удаленном сервере находится в состоянии прослушивания. Test-NetConnection не проверяет, какое приложение/служба работает/прослушивает порт 443.

По сути, Test-NetConnection не может сказать вам, что работает/прослушивается на уровне 7, он может только сказать вам, что порт 443 находится в состоянии прослушивания.

Два утверждения «соединение может быть установлено» и «я могу продолжить то, что я намереваюсь сделать» далеко не эквивалентны, и простой тест TCP-соединения, такой как Тест-NetConnection совсем не проверяет то же самое, что и фактическое git клон.

Возможность открыть TCP-соединение с портом не означает доступа к службе, прослушивающей этот порт. Существует много этапов после первоначального подключения, на которых может произойти сбой, например согласование TLS, аутентификация, авторизация или обмен протоколами на уровне приложения.

Кроме того, ограничения брандмауэра — не единственная возможная причина сбоя соединения TCP, а сбои соединения TCP — не единственное возможное последствие ограничений брандмауэра. Итак, ваши заявления:

Если я не могу получить доступ к сайту через определенный порт, это означает, что мне нужно изменить брандмауэр, прежде чем продолжить.

и

В противном случае, если я смогу добраться до сайта, я смогу продолжить то, что намереваюсь сделать.

оба неправы. Это означает, что вместо того, чтобы задаваться вопросом, почему ваш Тест-NetConnection test не обнаружил проблему, которая позже привела к сбою вашего доступа к GitHub, вам следует проанализировать, в чем на самом деле была эта проблема, а затем оценить, принесет ли обнаружение этой конкретной проблемы какую-либо пользу заранее. Если ответ да, вы можете разработать тест, чтобы сделать именно это.

На практике часто наиболее эффективным способом действий является простое выполнение намеченной операции без каких-либо предварительных тестов и обработка любых ошибок по мере их возникновения. Заблаговременная проверка на наличие проблем имеет смысл только в том случае, если они могут быть устранены автоматически или если попытка и неудача фактической операции сопряжены со значительными затратами или риском.

В частности, операции GitHub терпят неудачу довольно изящно и с достаточно четким указанием причины сбоя, поэтому я не вижу прямой выгоды в том, чтобы сначала протестировать соединение, а не просто попробовать выполнить предполагаемую операцию напрямую.