我正在監控我的流量並注意到幾個TCP（ACK、PSH） 我的路由器輸入鏈上的連線嘗試，被我的防火牆丟棄。
日誌看起來像這樣：
Dropping input: src-mac 9c:80:df:a0:8a:dd, proto TCP (ACK,PSH), 172.217.16.78:443 (google ip) ->192.168.1.2:40382 (my router IP), len 115
顯然，這是被丟棄的，因為我輸入鏈上的最後一條規則是丟棄資料包。
我不太了解 TCP 協議，很抱歉，如果這有點天真，但為什麼請求會定向到我的路由器？
我有各種使用Google服務的設備，可能還有第三方軟體，但這讓我很困惑，為什麼資料包實際上會被發送到路由器而不是自然到我網路中的設備（這將是前向鏈，對吧？）。
我還沒有註意到我的裝置在 Google 產品方面的體驗下降。軟體更新、推播通知等似乎都正常運作。
答案1
這種現像有些複雜。我在相應的日誌中做了一些研究，並想在這裡為所有也想知道的人分享我的猜測。
相關日誌條目顯示輸入鏈中帶有 TCP 標誌ACK和PSH（推送）的丟棄。這表示網路中的某些服務正在等待來自Google伺服器的消息（透過.push）。但是等等 - 為什麼包會記錄在輸入鏈中？這很容易解釋 - 如果路由器（或@chexum已經提到的 - conntrack）沒有有關NATed/ PATed 流量的連接信息，則該包看起來像是路由器的流量，而不是其後面的任何設備的流量。這就解釋了為什麼「Google正在向路由器發送流量」。
但問題是為什麼路由器沒有這些包的連接資訊。在這裡，我現在只能推測：在大多數用戶上網的時候觀察到下降。我的猜測是谷歌的回覆花了很長時間（可能是因為它之前的推播流量低於其他），因此連接超時。此特定路由器上的逾時對於 TCP 封包約為 10 秒，對於SYN.再過一段時間後，conntrack 將刪除有關舊的「無效」流量的記憶，從那時起，來自該連接的每個流量看起來都像輸入流量。這也是為什麼不觸發無效規則的一種可能的解釋。
我認為@samuel 應該多觀察一下，看看是否有任何模式可以識別。但總的來說，我@chexum 認為這些下降是可以忽略的。
答案2
它清楚地顯示了從 Google IP 收到的資料包，來源連接埠為 443。
當然，有可能有人使用 Google IP 位址進行中間人攻擊，甚至來自（或闖入）Google 的人正在向您發送資料包，是的，但這非常，非常不太可能。
更有可能的是，您的資料包過濾器和/或conntrack 子系統（或路由器和/或ISP 上的類似功能）已經看到google:443 和yourip:40382 之間的資料包流中的資料包，顯示了到已經關閉了。
通常，資料包過濾器不會記錄您發起的連接，但這僅適用於已建立的連接。
FIN當從兩側或任意一側關閉連接時RST，不再考慮該連接ESTABLISHED。任何一方延遲或重新發送的任何資料包都將被視為新資料包，並且值得資料包過濾器記錄，特別是如果刪除的 conntrack 條目阻止將資料包發送到正確的目的地。
這很常見，可能根本沒有理由擔心，您通常可以安全地忽略那些記錄的資料包。
如果您看到任何模式並想要進行調查，您可以tcpdump在系統上執行一個程序，記錄來自相似IP 位址的所有資料包，然後當您看到更多相似的日誌時，您可以停止tcpdump，並過濾本地連接埠以查看如果您確實在事件發生前幾秒鐘打開了連接。
上述範例 tcpdump 類似於：
tcpdump -ieth0 -s0 -w /var/tmp/allssl.cap port 443