なぜ起こるのか
pingはICMPを使い、SSHとHTTPSはTCPポートを使います。これらは別々のトラフィックなので、ファイアウォールは一方を破棄してもう一方を通過させることができます。多くのネットワークやクラウドのセキュリティグループは、初期設定でICMPエコーを遮断しています。そのため、応答がないからといってサーバーが停止しているとは限らず、応答があってもサービスの動作を証明することにはなりません。
pingではなくサービスをテストする
実際に必要なポートとプロトコルを確認してください。これらのテストが成功すれば、そのサービスについてはサーバーに到達できています。pingの失敗は、経路のどこかにフィルターがあることを示しているだけです。
nc -vz -w 5 server.example 22
nc -vz -w 5 server.example 443
curl -sSI https://server.example/TCPで経路を調べる
ICMPやUDPがフィルタリングされていると、通常のtracerouteはアスタリスクしか表示しないことがあります。開いているポート宛てにTCPを使うと、さらに先まで調べられる場合がよくあります。これにはrootが必要です。また、最小構成のシステムにはtracerouteが含まれないため、先にインストールが必要な場合があります。
sudo traceroute -T -p 443 server.exampleサーバー上のフィルターを探す
自分が管理するサーバーであれば、ファイアウォールと、エコー要求を無視するカーネル設定を確認してください。遮断箇所がサーバー外部のセキュリティグループやルーターである可能性もあります。また、プロバイダーがネットワーク上でICMPをフィルタリングしていても、そのルールは見えないことがあります。
sysctl net.ipv4.icmp_echo_ignore_all
sudo nft list ruleset | grep -i icmp
sudo ufw status verboseICMPの遮断が障害を起こすケース
エコーの遮断はほとんどの場合問題ありませんが、すべてのICMPを遮断するのは問題です。経路MTU探索は、パケットが大きすぎることを通知するメッセージに依存しています。それが届かないと、小さなデータのやり取りはできても、大きなものは止まってしまいます。例えば、SSHのログインには成功しても、大量の出力で接続が止まることがあります。IPv6はICMPv6への依存がさらに強くなります。2つ目のコマンドは、LinuxでMTUが1500バイトの経路をテストします。
ip route get 192.0.2.10
ping -M do -s 1472 -c 3 192.0.2.10CH-J Server Managerで比較する
Server Diagnosticsはrootを使わずにシステムのツールでpingを実行し、TCP、SSH識別、HTTP、TLSをそれぞれ別にテストするため、他の結果と合わせてpingの失敗を判断できます。ここでのpingの失敗は、応答が届かなかったことを意味します。パケットがどこで破棄されたかは分からず、tracerouteでも特定できるとは限りません。