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

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

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

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

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

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

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

TcpTestSucceeded : True

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

У меня есть вопросы:

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

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

решение1

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

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

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

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

решение2

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

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

Кроме того, ограничения брандмауэра не являются единственной возможной причиной сбоя TCP-соединения, а сбои TCP-соединения не являются единственным возможным результатом ограничения брандмауэра. Поэтому ваши утверждения:

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

и

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

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

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

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

Связанный контент