このサーバーが属するネットワークの組織は、ISP を変更しています。このサーバーの IP、ゲートウェイなどを新しい値に切り替えると、SSH 経由で接続できなくなります。ポート チェック ツールの 1 つを使用してポート 22 をチェックすると、「ポート 22 の _new_IP_value_ でサービスが見つかりません」というメッセージが返されました。
新しい IP は静的です。問題のサーバーにはルーターはなく、ポート転送もありません。ネットワーク ケーブルはサーバーに直接接続されます。
当然、組織のネットワークか新しい ISP がポート 22 をブロックしていると思ったので、ネットワーク管理者に電話して、ポートを開けるか、ISP にポートを開けるように伝えてもらうように頼みました。管理者はそうすると言いましたが、何も変わりませんでした。1 日後に同じ質問をして管理者に電話しましたが、忙しかったのは明らかで、私の要求に応じたとだけ言って電話を切りました。
それで、結局サーバーの設定に何か問題があるのではないかと考えています。しかし、lsof、netstat、nmap などのすべての Linux ツールは、sshd が起動して実行されており、ポート 22 でリッスンしており、ポート 22 が開いているなどと表示しています。また、古い ISP のネットワークに切り替えても、サーバーに ssh で接続できます。切り替えるのは IP、ゲートウェイ、DNS だけで、それ以上は何もありません。
サーバーが新しい ISP のネットワーク上にあるのに、古い ISP のネットワーク上にない場合、このサーバー上で ssh 接続をブロックする何かがある可能性がありますか? OS は Linux Mint です。
答え1
クライアントでパケット キャプチャを実行し、サーバーでパケット キャプチャを実行します。最も一般的なツールは Wireshark と tcpdump です。
tcpdump -n -i eth0 "(tcp port 22 or 3389) or icmp or icmp6"
TCP SYN パケットがクライアントから送信されているのにサーバーに到着しない場合は、通常、ネットワークに問題があります。オンライン ポート チェック ツールによって、クライアント側の ISP が問題である可能性が排除されているため、サーバーの ISP に問題がある可能性が最も高くなります。
(管理者がポートをまったく開かなかったか、正しいアドレスに対して開かなかった可能性があります。ポート 3389 が ISP レベルで閉じられていることも珍しくありません。)
tcptracerouteパケットが消える前にどのくらいの距離を移動するかを発見するのに役立つ可能性があると思います。TCP SYNパケットがサーバーに到着したが、応答がない場合はまったく問題はサーバーにあります。サーバーの内部ファイアウォールである可能性があります（tcpdumpはパケットを取得します前にファイアウォールにヒットする可能性があるため、iptablesルールがあるかどうかを確認してくださいそしてNFT ルール。
また、サーバーに帰り道クライアントに送信され、正しいインターフェースを介して正しいゲートウェイに送信されることを確認します。
ip -4 route get <client_ip> ip -4 route show match <client_ip>systemctl cat sshdまた、cgroup レベルの IP アドレス ホワイトリストがあるかどうかを確認するためにも実行します。また、IPsec ポリシーがあるかどうかを確認するためにも実行しますip xfrm policy。TCP SYNパケットが到着しているのにTCP RST応答が生成される場合、ファイアウォールの問題か、SSHデーモンが次のように設定されている可能性があります。聞く間違った住所に。（何を書いたかは書いていません）ローカルアドレスlsof/netstat では「ポート 22」の横に表示されます。0.0.0.0:22 または [::]:22 が表示された場合は問題ありませんが、古いアドレスが表示された場合は、sshd_config で変更する必要があります。
TCP SYN パケットが到着し、SYN/ACK 応答がサーバーから送信されているのに、クライアントがそれらの応答を受信しない場合も、ネットワークの問題であり、この場合もサーバー ISP 側にある可能性が最も高くなります。