Правила iptables при разрыве сервера динамическая переадресация порта ssh (прокси SOCKS) на локальную машину

Question

Я использую Debian 9 на арендованном VPS. На моем ноутбуке я использую динамическую переадресацию порта ssh (используя протокол SOCKS) для туннелирования трафика некоторых приложений. Все работает нормально, но когда я загружаю правила iptables на сервер (VPS), любое приложение на моем ноутбуке, использующее локальную переадресацию портов, перестает работать.

Эта команда используется для пересылки локального порта 8080 моего ноутбука (debian 8) на мой VPS:

ssh -D 8080 -N username@30.123.234.6

Приведенная выше команда начинает возвращать ошибки, подобные следующим:

channel 7: open failed: connect failed: Connection timed out
channel 8: open failed: connect failed: Connection timed out
channel 9: open failed: connect failed: Connection timed out
channel 3: open failed: connect failed: Connection timed out
etc...

Вот вывод iptables -L на VPS. Кто-нибудь может понять, почему эти правила могут вызвать эту проблему? Любая идея высоко ценится.

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  google-public-dns-a.google.com  anywhere            
ACCEPT     all  --  resolver3.opendns.com  anywhere            
ACCEPT     all  --  resolver1.opendns.com  anywhere            
SYN_FLOOD_LOG_DROP  tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN
UDP_FLOOD_LOG_DROP  udp  --  anywhere             anywhere            
ICMP_FLOOD_LOG_DROP  icmp --  anywhere             anywhere            
       tcp  --  anywhere             anywhere             tcp dpt:ssh     state NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
SSH_LOG_DROP  tcp  --  anywhere             anywhere             tcp dpt:ssh state NEW recent: UPDATE seconds: 60 hit_count: 4 name: DEFAULT side: source mask: 255.255.255.255
       tcp  --  anywhere             anywhere             tcp dpt:xmpp-client state NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
XMPP_LOG_DROP  tcp  --  anywhere             anywhere             tcp dpt:xmpp-client state NEW recent: UPDATE seconds: 60 hit_count: 8 name: DEFAULT side: source mask: 255.255.255.255
       tcp  --  anywhere             anywhere             tcp dpt:http state NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
HTTP_LOG_DROP  tcp  --  anywhere             anywhere             tcp dpt:http state NEW recent: UPDATE seconds: 60 hit_count: 8 name: DEFAULT side: source mask: 255.255.255.255
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:xmpp-client
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  localhost            anywhere             tcp dpt:5582

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain HTTP_LOG_DROP (1 references)
target     prot opt source               destination         
LOG        all  --  anywhere             anywhere             LOG level warning prefix "IPTables DROP:HTTPATTACK  "
DROP       all  --  anywhere             anywhere            

Chain ICMP_FLOOD_LOG_DROP (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere             limit: avg 1/sec burst 3
LOG        all  --  anywhere             anywhere             LOG level warning prefix "IPTables DROP:ICMPFLOOD  "
DROP       all  --  anywhere             anywhere            

Chain SSH_LOG_DROP (1 references)
target     prot opt source               destination         
LOG        all  --  anywhere             anywhere             LOG level warning prefix "IPTables DROP:SSHATTACK  "
DROP       all  --  anywhere             anywhere            

Chain SYN_FLOOD_LOG_DROP (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere             limit: avg 1/sec burst 3
LOG        all  --  anywhere             anywhere             LOG level warning prefix "IPTables DROP:SYNFLOOD  "
DROP       all  --  anywhere             anywhere            

Chain UDP_FLOOD_LOG_DROP (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere             state NEW recent: UPDATE seconds: 1 hit_count: 20 name: DEFAULT side: source mask: 255.255.255.255
LOG        all  --  anywhere             anywhere             LOG level warning prefix "IPTables DROP:UDPFLOOD  "
DROP       all  --  anywhere             anywhere            

Chain XMPP_LOG_DROP (1 references)
target     prot opt source               destination         
LOG        all  --  anywhere             anywhere             LOG level warning prefix "IPTables DROP:XMPPATTACK  "
DROP       all  --  anywhere             anywhere           

Спасибо.

Answer 1

Я принял предложение eckes и попытался записать, что DROPped политикой INPUT. Поэтому я добавил следующее правило как последнее в цепочке INPUT:

iptables -A INPUT -j LOG --log-prefix "IPTables DROP: wrong drop " --log-level 4

Это показало, что на самом деле отбрасывается много вещей, чего, вероятно, не следует. Примером является эта строка из журнала:

12 декабря 22:45:13 myservername kernel: [41817.875804] IPTables 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

Я был подключен к IRC-серверу 149.56.134.238 (cherryh.freenode.net) во время теста с моего ноутбука с использованием переадресации динамического порта ssh, как описано. Я потерял соединение после того, как правила iptables были загружены на сервер (VPS).

Итак, я снова воспользовался советом eckes и попытался принять ESTABLISHED, RELATED пакеты, добавив эту строку в качестве последнего правила цепочки (но до упомянутого выше правила отладки LOG).

iptables -A INPUT -m conntrack --cstate ESTABLISHED,RELATED -j ACCEPT

Задача решена. Я полагаю, что извлеченный урок заключается в том, что первый шаг к проблемам с iptables - проверить, что на самом деле удаляется