☰

サーバーがTCP SYNパケットへの応答を遅らせる

tag-icon • tag-icon tcp
サーバーがTCP SYNパケットへの応答を遅らせる

次のネットワークトポロジがあります。 ワークステーションおよびサーバーネットワークトポロジ

いつワークステーションHTTPSサーバーに接続仕える人、それから一般的に仕える人約60秒遅れてSYN + ACKパケットを送信します。サーバーからパケットをキャプチャする方法は次のとおりです。

10:15:21.310878 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503046494 0,nop,wscale 7>
10:15:23.102826 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503046942 0,nop,wscale 7>
10:15:23.326801 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503046998 0,nop,wscale 7>
10:15:27.230802 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503047974 0,nop,wscale 7>
10:15:27.486804 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503048038 0,nop,wscale 7>
10:15:35.422853 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503050022 0,nop,wscale 7>
10:15:35.678797 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503050086 0,nop,wscale 7>
10:15:51.550815 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503054054 0,nop,wscale 7>
10:15:51.806784 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503054118 0,nop,wscale 7>
10:16:24.062769 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503062182 0,nop,wscale 7>
10:16:24.062832 00:11:25:8c:7a:1a > 1c:87:2c:5a:43:e2, ethertype IPv4 (0x0800), length 74: 10.10.10.16.443 > 10.10.10.160.38256: S 561747608:561747608(0) ack 3411497796 win 5792 <mss 1460,sackOK,timestamp 3558683637 2503062182,nop,wscale 2>
10:16:24.062843 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503062182 0,nop,wscale 7>
10:16:24.062860 00:11:25:8c:7a:1a > 1c:87:2c:5a:43:e2, ethertype IPv4 (0x0800), length 74: 10.10.10.16.443 > 10.10.10.160.38244: S 562554685:562554685(0) ack 3008273870 win 5792 <mss 1460,sackOK,timestamp 3558683637 2503062182,nop,wscale 2>
10:16:24.063075 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 66: 10.10.10.160.38256 > 10.10.10.16.443: . ack 1 win 229 <nop,nop,timestamp 2503062182 3558683637>
10:16:24.063116 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 66: 10.10.10.160.38244 > 10.10.10.16.443: . ack 1 win 229 <nop,nop,timestamp 2503062182 3558683637>

ARP関連の問題を排除するために、静的ARPエントリをインストールしました。ワークステーション存在する仕える人:

# ip neigh show 10.10.10.160                               
10.10.10.160 dev eth0 lladdr 1c:87:2c:5a:43:e2 PERMANENT                      
#

最後に重要なのは、常に10.10.10.16から10.10.10.160にpingを送信できることです。例えば、私はwhile :; do ping -c 1 -I 10.10.10.16 10.10.10.160 &>/dev/null || date; sleep 2; done走った仕える人一日中たった1回のpingも失敗しませんでした。

最後に、クライアントが送信したTCP SYNパケットを比較すると10:15:51.806784（クライアントから何も受信されません）仕える人）と10:16:24.062769（から仕える人）Wiresharkでは、チェックサムを除いて同じです。

さらに、仕える人サイドファイアウォールを設定する方法が最初のルールです。入力するチェーンは10.10.10.160（）のiptables -I INPUT -s 10.10.10.160 -d 10.10.10.16 -p tcp --syn --dport 443 -j LOGTCP SYNパケットを記録し、2番目の規則は10.10.10.160のすべてのトラフィックを受け入れることです。たとえば、次の行はカーネルリングバッファに書き込まれます。

IN=eth0 OUT= MAC=00:11:25:8c:7a:1a:00:19:e2:9e:df:f0:08:00 SRC=10.10.10.160 DST=10.10.10.16 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=65477 DF PROTO=TCP SPT=40066 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0

すでに述べたように、次のルールで許可されています。これはtcすべての関連問題を排除する必要がありますnetfilter。

他のクライアント（例：10.10.10.170）は正常に動作します。

この動作の原因は何ですか？

ベストアンサー1

ここで重要な問題が見られます。サーバーの応答がサーバーに送信されたパケットとは異なるパスを使用することです。

ワークステーションは、WS と同じ LAN セグメントにある 10.10.10.148 アドレスを使用する代わりに、ルーター 10.10.10.190 を使用して、対応する 10.10.10.16/32 アドレス (/32? 図面には /28 が表示されます) を介してサーバーにアクセスします。

ただし、サーバーからWSへのTCPパケットは、サーバーがWSに直接接続できるため、ルーターを使用しません。

これはなぜ重要ですか？

その結果、ルーターはサーバーからの応答を見ることができず、接続状態について誤った考えを持っています（サーバーはSYN + ACKで応答しましたが、ルーターの観点からは接続状態はまだ初期のSYNにあります）。 。

今日、ほとんどのルーターと同様に、サーバーでSYN + ACKが確認されるまで（発生しない）、WSからサーバーに向かうすべての後続のTCPパケットをブロックします。

したがって、実際の問題は、サーバーがSYN + ACKを送信する前に60秒を待つのではなく、ルーターが最初のSYN以降のWSからサーバーへのTCPトラフィックをブロックすることです。

それでは、なぜトラフィックダンプが発生するのでしょうか？

私の理論が正しい場合、あなたの質問に投稿したトラフィックダンプは完全なダンプがないため不正です。

  • サーバーはすでに最初の要求に応答しており、これらの要求は重複した要求と見なされるため、SYN​​要求に応答しません。
  • 10:16:24.062769 と 10:16:24.062860 で見ることができるのは、おそらくサーバーが WS から何も受信せず、少しの遅延後に SYN+ACK 応答を再送信することです。

この問題をどのように解決しますか？

いくつかのオプションがあります。

  • 10.10.10.148 IPアドレスを介して直接サーバーに接続する（実際には修正ではありません）
  • サーバーから10.10.10.148 IPアドレスを削除します。 （オプションではないようです。）
  • ルータでファイアウォール接続トレースを無効にします。 （これはオプションではなく、決して理想的ではないようです。）
  • ルータのMACアドレス00:19:e2:9e:df:f0をサーバの10.10.10.160のARPテーブルに入力します。 （IMHOこれは10.10.10.148 IPを介してサーバーに直接接続するときに見苦しいハッキングです。最終的には別の同様の問題が発生します。アドレス（SYNパケットはルーターを使用しませんが、サーバーからの応答はルーターを使用するため）
  • 送信元ベースのルーティング（ポリシールーティング）を使用して発信パケットの送信元アドレスが10.10.10.16の場合は、宛先アドレスに関係なくルータを使用するようにサーバーに通知します。

もちろん、実際には実際のオプションではなくオプションも提示し、私の理論を実験して検証してみることができます。ソースベースのルーティングがあなたがしなければならないことです。

おすすめ記事