私はLinux Mintユーザーです。Linuxではtraceroute、Windowsではtracertを実行しました。Linuxでは、アスタリスクが表示されます。Windowsではすべてが正常に動作するようです。ここに出力があります
ウィンドウズ:
Linux Mint:
なぜこれが起こっているのですか?この問題を解決するために私ができることはありますか?
私はLinux Mintユーザーです。Linuxではtraceroute、Windowsではtracertを実行しました。Linuxでは、アスタリスクが表示されます。Windowsではすべてが正常に動作するようです。ここに出力があります
ウィンドウズ:
Linux Mint:
なぜこれが起こっているのですか?この問題を解決するために私ができることはありますか?
回答:
tracert
Linuxのtraceroute
デフォルトはUDP であるのに対し、違いの可能性のある理由は、デフォルトでWindow がICMPを使用していることです。-I
traceroute のオプションを使用すると、次と同じ結果が生成されtracert
ます。
traceroute -w 10 -I google.it
traceroute
ドキュメントから:
現代のネットワーク環境では、ファイアウォールが広く使用されているため、従来のtraceroute方式を常に適用できるとは限りません。このようなファイアウォールは、「ありそうもない」UDPポート、またはICMPエコーさえもフィルタリングします。これを解決するために、いくつかの追加のトレースルーティングメソッド(tcpを含む)が実装されています。以下の利用可能なメソッドのリストを参照してください。このような方法は、ファイアウォールをバイパスするために、特定のプロトコルと送信元/宛先ポートを使用しようとします(ファイアウォールからは、許可されたタイプのネットワークセッションの開始と見なされます)。
利用可能なメソッドのリスト
一般に、特定のtracerouteメソッドは-M名で選択する必要がありますが、ほとんどのメソッドには単純なcmdlineスイッチがあります(メソッド名がある場合は、メソッド名の後に表示されます)。
デフォルト
トレースルーティングの伝統的な古代の方法。デフォルトで使用されます。
プローブパケットは、いわゆる「ありそうにない」宛先ポートを持つudpデータグラムです。最初のプローブの「可能性が低い」ポートは33434で、次のプローブごとに1ずつ増加します。ポートは未使用であることが想定されているため、宛先ホストは通常、最終応答として「icmp unreach port」を返します。(ただし、一部のアプリケーションがそのようなポートをリッスンしたときに何が起こるかは誰にもわかりません)。
これを試して:
traceroute -M icmp google.it
ping
、そのまま使用することもでき、は必要ありませんtraceroute -M
)。HTTP接続を評価しようとする場合(質問で使用した名前に基づいていると思います)、TCP / 80またはTCP / 443を通常使用するHTTPクエリを実行する必要があります。したがって、そのために使用tpctraceroute
します。