即使應該接受適當的數據包，為什麼 iptables 會丟棄/記錄？
我正在設置一個執行 Debian Jessie 的伺服器，其中包含一些應用程序，如 iptables 防火牆、fail2ban、openvpn、apache ……
iptables 防火牆的配置方式是記錄每個丟棄的數據包。iptables 配置的一小段摘錄：
... -A INPUT -m comment --comment "003 accept related established rules IPv4" -m state --state RELATED,ESTABLISHED -j ACCEPT ... -A INPUT -p tcp -m multiport --dports 1194 -m comment --comment "303 allow incoming OpenVPN" -m state --state NEW -j ACCEPT ... -A INPUT -m comment --comment "900 IPv4 log dropped input chain" -j LOG --log-prefix "[IPTABLES INPUT IPv4] DROP " --log-level 6 -A INPUT -m comment --comment "910 IPv4 deny all other input requests" -j DROPOpenVPN（使用埠 1194）執行良好。我可以連接、使用連接並工作數小時，直到我需要傳輸大量數據。此時，日誌中出現如下幾行：
Mar 02 20:39:27 rs3 kernel: [IPTABLES INPUT IPv4] DROP IN=eth0 OUT= MAC=ae:12:7b:9b:5d:e4:00:15:c7:c9:45:80:08:00 SRC=<MyIPAddress> DST=<ServerIPAddress> LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=20713 DF PROTO=TCP SPT=61941 DPT=1194 WINDOW=3040 RES=0x00 ACK URGP=0 Mar 02 20:39:27 rs3 kernel: [IPTABLES INPUT IPv4] DROP IN=eth0 OUT= MAC=ae:12:7b:9b:5d:e4:00:15:c7:c9:45:80:08:00 SRC=<MyIPAddress> DST=<ServerIPAddress> LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=20718 DF PROTO=TCP SPT=61941 DPT=1194 WINDOW=3040 RES=0x00 ACK URGP=0 Mar 02 20:39:27 rs3 kernel: [IPTABLES INPUT IPv4] DROP IN=eth0 OUT= MAC=ae:12:7b:9b:5d:e4:00:15:c7:c9:45:80:08:00 SRC=<MyIPAddress> DST=<ServerIPAddress> LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=20719 DF PROTO=TCP SPT=61941 DPT=1194 WINDOW=3040 RES=0x00 ACK URGP=0$$ These logs are picked up from fail2ban and the server closes the connection to my local computer. $$ 問：為什麼這些數據包會被丟棄（並被記錄）？這意味著：為什麼那些數據包沒有被“相關，已建立”規則處理？
到目前為止我所做的：閱讀文件，考慮問題;-)，一次又一次地檢查規則，在網際網路上搜尋 - 但沒有任何結果。
編輯：也許這很重要：fail2ban 創建的 DROP 列表有大約 500 個條目。
編輯：我想知道原因（這就是我在問題中使用“為什麼”的原因）。我對解決方法不感興趣。
編輯：這種行為不限於 OpenVPN，使用其他協議（例如 ssh）也有同樣的問題。
編輯：給你一個印象，看看wireshark截圖：突出顯示的數據包被丟棄/記錄 - 截圖中的所有其他數據包都沒有。
這是適當的日誌：
Mar 03 10:16:23 rs3 kernel: [IPTABLES INPUT IPv4] DROP IN=eth0 OUT= MAC=ae:12:7b:9b:5d:e4:00:15:c7:c9:45:80:08:00 SRC=<MyIPAddress>.117 DST=<ServerIPAddress>.116 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=11550 DF PROTO=TCP SPT=63526 DPT=1194 WINDOW=32038 RES=0x00 ACK URGP=0我使用 IP ID (11550) 在 Wireshark 中查找數據包。這是唯一具有此 ID 的 IP 數據包。
編輯：伺服器IP是固定IP。我的動態分配的 IP 地址在測試期間沒有更改。LocalComputer 向伺服器發起連接。設置如下：
================= =================== =============== | LocalComputer | ---- | NAT Router .117 | ---- | Server .116 | ================= =================== =============== Private IP Dynam. Assigned Fixed IP but fixed during test
連接跟踪器不僅跟踪數據包是否來自同一個連接，還檢查一些時間（如延遲 ACK 或 SEQ 太遲）。
可以通過以下方式打開連接跟踪器日誌記錄：
echo 255 >/proc/sys/net/netfilter/nf_conntrack_log_invalid這向我表明，所有丟棄和記錄的包都屬於以下類型：
nf_ct_tcp: ACK is under the lower bound (possible overly delayed ACK) ...我在討論中找到了這些提示。
我目前不知道為什麼會發生這種情況，但這可能是另一個問題……
因為您有這些
iptables日誌條目，並且它們與您的RELATED,ESTABLISHED規則不匹配，所以連接跟踪器報告將它們視為與之前任何內容無關的新會話的開始。通常（但不總是）當會話的空閒時間超過連接跟踪器超時時間時，可能會發生這種情況。您的端點之間的其他 NAT 設備可能已超時並生成新的埠號，或者您的其他端點的 IP 地址可能已更改（可能在某些 ISP 的基於 DHCP 的網路上），因此不一定是端點連接跟踪器有問題.腦海中浮現出三種選擇，
- 在 OpenVPN 配置中啟用*ping keepalive 。*作為最低限度，請嘗試
ping 10. 如果您願意，並且根據您的客戶端/伺服器的設置方式，您可能更喜歡keepalive 10 60. 有關真正血腥的詳細資訊，請參見手冊頁。（如果端點的 IP 地址/埠對發生更改，這將無法解決問題。）- 禁用
fail2ban與 1194/tcp 上的 OpenVPN 流量匹配的配置。- 確保避免
iptables在 1194/tcp 上為 OpenVPN 流量列印日誌消息，因此fail2ban沒有可觸發的內容。