Ich folgte dem Vorschlag von eckes und versuchte zu protokollieren, was durch die INPUT-Richtlinie DROPped ist. Also habe ich folgende Regel als letzte in der INPUT-Kette hinzugefügt:
iptables -A INPUT -j LOG --log-prefix "IPTables DROP: wrong drop " --log-level 4
Dies zeigte, dass eine Menge Material tatsächlich fallen gelassen wurde, was wahrscheinlich nicht der Fall sein sollte. Ein Beispiel ist diese Zeile aus dem Protokoll:
12. Dez. 22:45:13 MyServername-Kernel: [41817.875804] IPTables DROP: falscher Drop IN = ens18 OUT = MAC = aa: 43: 9d: 07: 06: a7: 00: 1b: 21: ad: d0: 5d: 08 : 00 SRC = 149.56.134.238 DST = 30.123.234.6 LEN = 113 TOS = 0x00 PREC = 0x00 TTL = 49 ID = 471 DF PROTO = TCP SPT = 6667 DPT = 47054 WINDOW = 227 RES = 0x00 ACK PSH URGP = 0
Ich war zum Zeitpunkt des Tests von meinem Laptop aus mit dem IRC-Server 149.56.134.238 (cherryh.freenode.net) verbunden, wobei die dynamische Portweiterleitung von ssh wie beschrieben verwendet wurde. Ich habe die Verbindung verloren, nachdem iptables-Regeln auf dem Server (VPS) geladen wurden.
Also folgte ich erneut dem Rat von eckes und versuchte, ESTABLISHED, RELATED-Pakete zu akzeptieren, indem ich diese Zeile als letzte Regel der Kette hinzufügte (jedoch vor der oben genannten Debugging-LOG-Regel).
iptables -A INPUT -m conntrack --cstate ESTABLISHED,RELATED -j ACCEPT
Problem gelöst. Ich denke, die Lektion ist, dass der erste Schritt bei iptables-Problemen ist, zu prüfen, was tatsächlich fallen gelassen wird!