Сабж.
Пытался настроить простейшие правила:
*mangle
:PREROUTING ACCEPT [7:364]
:INPUT ACCEPT [7:364]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*filter
:OUTPUT ACCEPT [0:0]
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
-A INPUT ! -i venet0:0 -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags ACK ACK -j ACCEPT
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -m state --state RELATED -j ACCEPT
-A INPUT -p udp -m udp --dport 1024:65535 --sport 53 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type echo-reply -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type destination-unreachable -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type source-quench -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type time-exceeded -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type parameter-problem -j ACCEPT
-A INPUT -p tcp -m tcp -m multiport -j ACCEPT --dports 22,80,443,10000
-A INPUT -p tcp -m tcp --dport auth -j ACCEPT
COMMIT
И неизменно получал ошибку с указанием последней строки
iptables-restore: line 39 failed
Начал подозревать проблему на стороне хоста, работа идет под openvz и возможно нет "conntrack-а"
Задал вопрос в службу поддержки и получил ответ:
От: Алексей Атаманов - 2016-07-09 04:53:56
Здравствуйте, да, ошибка возникает потому что модуль conntrack не подключен для виртуальных серверов.
--
С уважением,
Атаманов Алексей,
Консультант службы технической поддержки FirstVDS
От: - 2016-07-09 04:55:41
И какие варианты решения? )
От: Алексей Атаманов - 2016-07-09 05:02:31
Используйте KVM-виртуализацию
--
С уважением,
Атаманов Алексей,
Консультант службы технической поддержки FirstVDS
Собственно, то что хостеру пофигу на проблемы клиента и эти ограничения ни где не задокументированы понятно и бог им судья.
Но заниматься переносом сервере не хочется. Есть ли пути решения этой проблемы без переноса VDS на KVM?
Простой
