クライアントの1つがサーバーへのTCP接続を開始しようとしましたが、失敗する問題が発生しました。
tcpdump
クライアントデバイスがSYN
パケットを送信し、サーバーが正しく応答していることを確認しましたSYN ACK
。その直後にサーバーはRST
パケットを受信します。数秒後にプロセスが繰り返されます。不思議に接続がきちんとなることが時々あります(約2日に一度ずつ午前8時30分頃)。
パケットを別のサーバーにリダイレクトしようとしましたが、そのサーバーにも同じ問題がありました。
今日は逆につなげてみました。私たちのクライアントは現在、ファイアウォールにポートが開いていませんが、何が起こっているのかを確認するためにとにかく接続しようとしました。ssh
別のコンピュータから接続しようとしましたが、これが私が見つけたものです。
私のパソコン(Mac OS X 10.10)では:ssh: connect to host x.x.x.x port 22: Connection refused
パケットを受信するサーバーSYN
(Debian 8):ssh: connect to host x.x.x.x port 22: No route to host
他のホスティングセンターの他のサーバー(Debian 7)から:ssh: connect to host x.x.x.x port 22: No route to host
大企業の他のサーバー(Debian 7)から:ssh: connect to host x.x.x.x port 22: Operation timed out
自宅のPCからの応答は、ファイアウォールでポートが開いていない場合に期待したものと正確に一致しますが、他のサーバーからの出力が異なるため、混乱します。
これらのコンピュータの1つでクライアントのIPをpingすると正常に動作します。
SYN-ACK
私のパッケージが間違ってルーティングされ、(ほぼ)クライアントに到達できないルーティングの問題はありますか?この問題を解決する方法に関する提案はありますか?顧客のISPまたはサーバープロバイダに連絡する必要がありますか?
ご協力ありがとうございます。
アップデート1:
私はジェフの質問についてもう少し調べてみました。私の結果は次のとおりです。
IP TTL SYN: 55 IP TTL RST: 59
現在、クライアントが自分のネットワークへのアクセスを許可するのを待っているため、クライアントがそれを受信したかどうかを確認SYN-ACK
できません。RST
Traceroute:
1 x.x.x.x 25.793 ms 5.516 ms 5.516 ms 2 x.x.x.x 4.140 ms 4.172 ms 4.166 ms 3 x.x.x.x 4.158 ms 4.147 ms 4.139 ms 4 x.x.x.x 9.855 ms 9.877 ms 9.874 ms 5 x.x.x.x 15.506 ms !X 15.753 ms !X 15.970 ms !X
私のコンピュータのTracerouteは最後の2つのホップで同じです。両方のトレースパスには5つのホップがあります。
サーバー側にはファイアウォールやロードバランサーはありません。
ルーティングテーブルはno route to host
主にデフォルトルートとローカルサブネットルートで構成され、他のすべての場合にはうまく機能します。
答え1
質問するのに十分な評判がないので、答えではなく質問に近いです。ただし、正しい方向性を提供するか、他の人が問題についてより多くの洞察を提供できるようにする必要があります。
-What is the IP TTL (or hop limit if IPv6) in the SYN and RST?
-What does a capture from the client show?
-Does it receive the SYN-ACK, and does it send the RST?
-What does a traceroute look like?
-How many hops between the server and the client?
-Is there a firewall, load balancer or other network
device fronting (NAT, VIP) the server?
-What do the routing tables look like for the servers
receiving the No Route to Host?
答え2
すべては構成の問題に帰結します。今日、ある顧客は自分のネットワークへのアクセスを許可し、基本的に彼のネットワークでルーティングの問題を引き起こす同じIPアドレスを持つ2つのデバイスがあることを発見しました。
IPアドレスの1つが変更されました。解決しました。
ご協力ありがとうございます。