SYN ACK後のTCPリセットは、「ホストへのパスなし」と関連付けることができます。

SYN ACK後のTCPリセットは、「ホストへのパスなし」と関連付けることができます。

クライアントの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つが変更されました。解決しました。

ご協力ありがとうございます。

関連情報