このネットワークからのすべての接続がSYN_RECV状態でスタックし、自宅または電話からの接続が適切に確立される
私のサーバー（linode VPS）は昨日すべてのリクエストで突然タイムアウトし始めました。
私はネットワーキングにかなりの経験がなく、これらの接続の問題をデバッグするプロセスを学びたいと思っています。
私を混乱させるのは、昨日、何人かの人々（私の電話、自宅にいる私、自宅にいる友人）が常にサイトにアクセスでき、netstatで接続が確立されていることがわかりました。 firwallsを無効にし、すべての接続を受け入れるようにiptablesを設定して、IPをブラックリスト化する奇妙な自動ルールを除外しました。関連があるかどうかはわかりませんが、ローカルネットワークからのtracerouteがタイムアウトします。外部のマシンからのtracerouteがサーバーを見つけます。
正常に機能している開発サーバーの設定と比較して、さまざまな設定が正しいことを確認しました。
次のファイルは私の開発環境に一致します（それぞれのIPアドレスを除く）：
/etc/hosts
/etc/hosts.allow
/etc/hosts.deny
/etc/networking/interfaces
ifconfig
Apacheはポート80でリッスンしており、セットアップは機能しているサーバーとまったく同じに見えます。
# server that doesn't work:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 22008/Apache2
tcp 0 0 69.164.201.172:80 71.56.137.10:57487 SYN_RECV -
# server that does work
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3334/Apache2
tcp 0 0 72.14.189.46:80 71.56.137.10:57490 ESTABLISHED 20931/Apache2
私の理解の試み
ページを1回読み込むたびに、netstat -an | grep :80は、SYN_RECV状態のすべての接続を明らかにします。
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 69.164.201.172:80 71.56.137.10:56657 SYN_RECV
tcp 0 0 69.164.201.172:80 71.56.137.10:56669 SYN_RECV
tcp 0 0 69.164.201.172:80 71.56.137.10:56671 SYN_RECV
したがって、SYN_RECVは、サーバーがACKがクライアントから送り返されるのを待っていることを意味します。
ACKが送り返されているかどうかをデバッグするにはどうすればよいですか？この通信が失敗している場所をデバッグするにはどうすればよいですか？
ページを1回ロードしようとすると、tcpdumpは次のようになります。
下の貼り付けでは、私のサーバーは常にクライアントにパケットを送信しており、応答を受信していません。
これは何を意味するのでしょうか？クライアントが応答を受け取っていないのですか？または、サーバーのどこかで応答を飲み込んでいますか？犯人をさらに絞り込むにはどうすればよいですか？
tcpdump -i eth0 -n -tttt port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
2011-05-25 20:12:54.627417 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
2011-05-25 20:12:54.627512 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:54.814463 IP 69.164.201.172.80 > 71.56.137.10.57157: Flags [S.], seq 604630211, ack 496040070, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:55.214482 IP 69.164.201.172.80 > 71.56.137.10.57158: Flags [S.], seq 998358186, ack 2224730755, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:57.624737 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
2011-05-25 20:12:57.624793 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:59.014477 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:13:03.618790 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,nop,sackOK], length 0
2011-05-25 20:13:03.618866 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:13:05.014514 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:13:17.014504 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
機能サーバーのtcpdump
機能しているサーバーのtcpdumpを見ると、サーバーとクライアント間の通信が4回目に戻ります。
00:00:00.000000 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [S], seq 34114118s [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
00:00:00.000110 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [S.], seq 2454858 win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0
00:00:00.061827 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [.], ack 1, win 100:00:00.004292 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [P.], seq 1:597, ngth 596
00:00:00.000074 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], ack 597, win00:00:00.493990 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], seq 1:2921, ngth 2920
00:00:00.000024 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [P.], seq 2921:30, length 98
00:00:00.065135 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [.], ack 3019, wi00:00:00.034766 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [P.], seq 597:12925, length 699
00:00:00.000035 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], ack 1296, wi00:00:00.000457 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [P.], seq 3019:328, length 211
00:00:00.019196 IP 71.56.137.10.57262 > 72.14.189.46.80: Flags [S], seq 10674886s [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
TCPをもう少し理解できるように、提案や説明、コメントをいただければ幸いです。次回はこのような問題をデバッグする必要があるときに、もう少し役立つと思います。
ありがとうございました！
このぎこちない目には、問題のサーバーの近くにある種のルーティングの問題があるように見えます。パケットは1つのパスに沿って到着しますが、別のパスを経由して出発するようで、そのパス上にステートフルな何かがあり、奇妙な「SYNなしのACK」パケットをドロップします。
私はこれを一度経験しました。結局のところ、サーバーのネットワークマスクが不良だったため、サブネット外からのトラフィックが着信すると、ARP要求を発行してノードのMACアドレスを取得していました。残念ながら、ルーターとロードバランサーの両方でプロキシARPが有効になっており、ロードバランサーはルーターよりもトリガーが少し高速でした。そのため、SYNパケットはルーター経由で着信しましたが、ロードバランサー経由でサブネットから出ようとしました。 LBにはそのACkパケットへの接続がなかったため、LBを床に落としました。
あなたの場合、いくつかの賢明なトレースルートがネットワークパスの問題を明らかにするかもしれません。影響を受けるサーバーから、問題の原因となっているIPへのtracerouteを試み、同じIPから同じことを行います。別のパスを取得している場合、それはそれがあるかもしれません。