Test-NetConnection では接続可能であることが示されていますが、サイトにアクセスできないのはなぜですか?

Test-NetConnection では接続可能であることが示されていますが、サイトにアクセスできないのはなぜですか?

ネットワークにファイアウォールの制限が存在する場合、特定のサイトが特定のポートでアクセス可能かどうかを判断する必要があります。

特定のポートでサイトにアクセスできない場合は、続行する前にファイアウォールを変更する必要があることを意味します。それ以外の場合、サイトにアクセスできれば、目的の作業を進めることができます。

リポジトリの https URL を使用してリポジトリを取得できるかどうかを知りたいですGithub。 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

しかし、その後 Web ブラウザを開いて にアクセスしたところhttps://github.com、Web ブラウザには接続できないと表示されました。https はポート 443 経由で、ドメインはgithub.comテストで入力したものと同じです。

私の質問は次のとおりです:

  • なぜ 2 つのテストの間にこのような矛盾があるのでしょうか?
  • 特定のポートを介して特定のドメインにアクセスできるCMDかどうかを正確にテストするにはどうすればよいですか?PowerShell

明らかに、Test-NetConnectionWeb ブラウザが にアクセスできなかったため、コマンドは正確な結果を生成しませんでしたgithub.com

答え1

明らかに、Web ブラウザーが github.com にアクセスできなかったため、Test-NetConnection コマンドは正確な結果を生成しませんでした。

それは正確な発言ではありません。

Test-NetConnection は実際に宛先サーバーのポート 443 に TCP 接続し、リモート サーバーの TCP ポート 443 がリスニング状態であることを確認しました。Test-NetConnection は、ポート 443 で実行/リスニングしているアプリケーション/サービスについてはテストしません。

基本的に、Test-NetConnection はレイヤー 7 で何が実行/リッスンされているかを伝えることはできず、ポート 443 がリッスン状態にあることだけを伝えることができます。

答え2

「接続を確立できる」と「意図した操作を続行できる」という 2 つのステートメントは同等とはほど遠く、 のような単純な TCP 接続テストはTest-NetConnection実際の と同じことをテストするものではありませんgit clone

ポートへの TCP 接続を開くことができても、そのポートでリッスンしているサービスにアクセスできるとは限りません。最初の接続の後には、TLS ネゴシエーション、認証、承認、アプリケーション レベルのプロトコル交換など、失敗する可能性のある段階が多数あります。

また、ファイアウォールの制限は TCP 接続が失敗する唯一の理由ではなく、TCP 接続の失敗はファイアウォールの制限の唯一の影響でもありません。したがって、あなたの発言は次のようになります。

特定のポートでサイトにアクセスできない場合は、続行する前にファイアウォールを変更する必要があることを意味します。

そして

そうでなければ、サイトにアクセスできれば、自分がやろうとしていることを進めることができるでしょう。

どちらも間違っています。つまり、Test-NetConnectionGitHub アクセスの失敗の原因となった問題がテストで検出されなかった理由を考えるのではなく、その問題が実際に何であったかを分析し、その特定の問題を事前に検出することでメリットが得られるかどうかを評価する必要があります。答えが「はい」であれば、そのためのテストを考案できます。

実際には、事前のテストを行わずに意図した操作を試し、エラーが発生したらそれを処理するのが最も効率的な方法であることがよくあります。問題を事前にチェックするのは、ほとんどの場合、問題を自動的に修正できる場合、または実際の操作を試して失敗すると多大なコストやリスクが発生する場合にのみ意味があります。

具体的には、GitHub の操作は、失敗の原因がかなり明確に示されながら、かなりスムーズに失敗するため、意図した操作を直接試すのではなく、最初に接続をテストすることには直接的なメリットはないと思います。

関連情報