リモートシステムでファイアウォールがオンになっている場合、pingコマンドは受け入れられません
Pingコマンドを使用して、リモートマシンがオンになっているかどうかを確認しています。ただし、ファイアウォールがオンの場合、リモートマシンでpingコマンド（ICMP Packect）が受け入れられず、pingステータスがfalseを返すため、リモートマシンがオフであると想定されるという問題があります。リモートマシンがオンになっているか、ファイアウォールがオンになっていると想定していないことを知る別の方法はありますか？.
ファイアウォールの構成によっては、TCP SYNpingを使用できる場合があります。
事実上、ポートでリッスンしている場合はACKが返され、そうでない場合はRSTが返されます。
これを行うさまざまなツールが存在します。特に [〜＃〜] nmap [〜＃〜]
他のコンピューターが同じローカルエリアネットワーク上にある場合は、pingをブロックしていても、ARP要求に応答する必要があります。この場合、arpingのようなものを使用してみることができます。 ウィキペディアの詳細情報 。
大規模なネットワークでは、ホストがオンになっているかどうかを、その協力なしに確実に判断する方法は考えられません。
ファイアウォールに問題がない場合、これを確認する方法はありません。ファイアウォールの要点は、送信したパケットが拒否された場合、受信サーバーの状態に関する手がかりがまったく得られないということです。基本的な考え方は、ケースを区別できないということです。の
1）サーバーが存在せず、
2）ファイアウォールがあなたをブロックしました。
リモートサーバーがオンになっているかどうかを確認するには、サーバーが応答するポートを決定し、ファイアウォールに適切な穴を開ける必要があります。
（コメントするにはまだ十分な評判がないので、これを回答として追加します）
これが、ICMPを削除してもマシンの存在が実際に隠されているわけではないため、通常、すべてのマシンで少なくともいくつかのicmpタイプ（エコー要求、エコー応答、超過時間が頭に浮かぶ）を許可することをお勧めする理由です（マシンの場合もあります）。ただし、その背後にあります）が、ほとんどの場合、監視とネットワークデバッグを妨げます。
Pingflood攻撃について本当に偏執的である場合は、何らかのレート制限が行われる可能性があります（またはネットワークの境界側でのみフィルタリングします）。
エコー要求に応答しないことは、マシンが存在しないことを示すものではないことに注意してください。これは通常、最後のルーターがICMPパケットタイプ3、コード1（ホストに到達できません）で応答することによって通知されるため、マシンを実際に非表示にすることは見た目よりも複雑です。
元の質問に関しては、通常、nmapスキャンの1つがその役割を果たします（多くの場合、いわゆる「tcpping」スキャン）。
これを行う方法は、既知の開いているポートへのTCP接続を開始することです。Webサーバーの場合、ポート80（または443）で応答します。肯定的な応答は、否定応答は、ネットワークを介した接続、ファイアウォール構成の誤り、サービスの停止、マシンのダウンなど、考えられる多くの問題の1つを示します。
監視を設定していて、いつマシンに注意を払うべきかを知りたいだけの場合は、既知のオープンポートに依存してください。少なくとも応答が停止した場合は、何かが起きていることがわかります。
最新のファイアウォールのほとんどは、最初のSYN-SYN/ACK-ACKを傍受して、リソース枯渇タイプの攻撃を防ぐこともできます（つまり、サーバーに接続テーブルにエントリを入力させ、接続を継続しないように強制する多くのSYNを送信します。このタイプの攻撃はより攻撃的であり、これらの接続はスプーフィングされたIPアドレスからのものである可能性があります。
サーバーが実際に稼働していることをより確実にするために、接続を開いて実際にデータを要求する必要がある場合があります（もちろん、サーバーのキャッシュやその他のものはこれさえ失敗する可能性があります）。
それはどのタイプのサーバーですか？接続タイプは、サーバーが提供するサービスに合わせて調整できます。 nmap（ http://nmap.org/ ）のようなツールは、たとえばhttpヘッダーを要求できます。
これはWindowsの質問ではありませんか？ Windowsは、デフォルトでpingをブロックするのに十分な遅延がある唯一のOSです。
私は本当にこれが嫌いです。 pingが機能しなかったという理由だけで、ネットワークのトラブルシューティングを行う人々によって何人年が浪費されたのだろうか。