Google IP がルーターに TCP (ACK、PSH) を送信します。理由はわかりますか?

Question 1

この現象はやや複雑です。私は対応するログを調査し、同じように疑問に思っているすべての人のために私の推測をここで共有したいと思います。

ACK関連するログエントリは、TCP フラグと(push)を持つ入力チェーンのドロップを示していますPSH。これは、ネットワーク内の一部のサービスが Google サーバーからのメッセージを待機していることを示しています (push 経由)。しかし、待ってください。なぜパッケージが入力チェーンに記録されているのでしょうか。これは簡単に説明できます。ルーター (または @chexum が既に述べたように、conntrack) にNATed/ PATed トラフィックに関する接続情報がない場合、パッケージはルーターのトラフィックのように見え、その背後にあるデバイスのトラフィックのように見えません。そのため、「Google がルーターにトラフィックを送信している」理由が説明できます。

しかし、問題は、なぜルーターにこれらのパッケージの接続情報がないのかということです。そして、ここでは今のところ推測することしかできません。ドロップは、ほとんどのユーザーがインターネットを使用しているときに発生します。私の推測では、Google の応答に時間がかかりすぎたため (おそらく、他のものよりもトラフィックを低くプッシュしたため)、接続がタイムアウトしたと考えられます。この特定のルーターのタイムアウトは、TCP パッケージの場合は約 10 秒、5 秒ですSYN。さらにしばらくすると、conntrack は古い「無効な」トラフィックに関するメモリを削除し、それ以降、この接続からのすべてのトラフィックは入力トラフィックのように見えます。これは、無効なルールがトリガーされない理由の 1 つでもあります。

@samuel はもう少し観察して、パターンが認識できるかどうかを確認する必要があると思います。しかし、一般的には、これらのドロップは無視できるという @chexum の意見に同意します。

Answer

この現象はやや複雑です。私は対応するログを調査し、同じように疑問に思っているすべての人のために私の推測をここで共有したいと思います。

ACK関連するログエントリは、TCP フラグと(push)を持つ入力チェーンのドロップを示していますPSH。これは、ネットワーク内の一部のサービスが Google サーバーからのメッセージを待機していることを示しています (push 経由)。しかし、待ってください。なぜパッケージが入力チェーンに記録されているのでしょうか。これは簡単に説明できます。ルーター (または @chexum が既に述べたように、conntrack) にNATed/ PATed トラフィックに関する接続情報がない場合、パッケージはルーターのトラフィックのように見え、その背後にあるデバイスのトラフィックのように見えません。そのため、「Google がルーターにトラフィックを送信している」理由が説明できます。

しかし、問題は、なぜルーターにこれらのパッケージの接続情報がないのかということです。そして、ここでは今のところ推測することしかできません。ドロップは、ほとんどのユーザーがインターネットを使用しているときに発生します。私の推測では、Google の応答に時間がかかりすぎたため (おそらく、他のものよりもトラフィックを低くプッシュしたため)、接続がタイムアウトしたと考えられます。この特定のルーターのタイムアウトは、TCP パッケージの場合は約 10 秒、5 秒ですSYN。さらにしばらくすると、conntrack は古い「無効な」トラフィックに関するメモリを削除し、それ以降、この接続からのすべてのトラフィックは入力トラフィックのように見えます。これは、無効なルールがトリガーされない理由の 1 つでもあります。

@samuel はもう少し観察して、パターンが認識できるかどうかを確認する必要があると思います。しかし、一般的には、これらのドロップは無視できるという @chexum の意見に同意します。

Question 2

送信元ポートが 443 の Google IP から受信したパケットが明確に表示されています。

もちろん、誰かがGoogleのIPアドレスを使って中間者攻撃をしたり、Googleの誰か（または侵入者）がパケットを送信したりする可能性はありますが、これは非常に、とてもありそうにない。

おそらく、パケットフィルターや conntrack サブシステム (またはルーターや ISP の同様の機能) が、google:443 と yourip:40382 間のパケットフローからのパケットをすでに確認しており、接続がすでに閉じられていることを示していると考えられます。

通常、ユーザーが開始した接続はパケットフィルターによってログに記録されませんが、これは確立された接続にのみ当てはまります。

FIN両側またはどちらか一方からで接続が閉じられるとRST、その接続はとはみなされなくなりますESTABLISHED。どちらか一方によって遅延または再送されたパケットは、特に削除された conntrack エントリによってパケットが適切な宛先にデネートされない場合は、パケットフィルタによって新規とみなされ、ログに記録する価値があるものになります。

これは非常に一般的なことであり、心配する必要はまったくありません。通常、ログに記録されたパケットは無視しても問題ありません。

何らかのパターンが見つかり、調査したい場合は、tcpdumpシステム上でを実行し、類似の IP アドレスからのすべてのパケットをログに記録し、類似のログがもう 1 つ見つかったら、tcpdump を停止し、ローカルポートをフィルタリングして、イベントのほんの数秒前に実際に接続が開いていたかどうかを確認できます。

上記のサンプル tcpdump は次のようになります。

tcpdump -ieth0 -s0 -w /var/tmp/allssl.cap port 443

Answer