Привет, я использую Ubuntu 9.04 на VPS. Я получаю сообщение об ошибке, если применяю правило iptables. Вот что я сделал.
1. Сохранил существующие правила
iptables-save> /etc/iptables.up.rules
Создал iptables.test.rules и добавил в него несколько правил
нано /etc/iptables.test.rulesnano /etc/iptables.test.rules
Это правила, которые я добавил
*filter
# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT
# Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allows all outbound traffic
# You can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT
# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
# Allows SSH connections
#
# THE -dport NUMBER IS THE SAME ONE YOU SET UP IN THE SSHD_CONFIG FILE
#
-A INPUT -p tcp -m state --state NEW --dport 22- j ACCEPT
# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
# log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
# Reject all other inbound - default deny unless explicitly allowed policy
-A INPUT -j REJECT
-A FORWARD -j REJECT
COMMIT
После редактирования, когда я пытаюсь применить правила
iptables-restore < /etc/iptables.test.rules
Я получаю следующую ошибку
iptables-restore: ошибка строки 42
Строка 42 - COMMIT, и я комментирую, что получаю
iptables-restore: в строке 43 ожидается COMMIT
Я не уверен, в чем проблема, он ожидает COMMIT, но если COMMIT есть, он дает ошибку. Может ли это быть из-за того, что я использую VPS? Мой провайдер использует OpenVZ для виртуализации.
На данный момент очень старый пост, но это лучший результат в Google, поэтому я подумал, что обновлю свое решение ...
После COMMIT должна быть пустая строка, иначе iptables-restore завершится ошибкой с ошибкой «команда не указана» в строке, в которой включен COMMIT.
Из-за способа iptables-restore работает, почти все ошибки будут сообщаться как находящиеся на COMMIT точка. В нечетных случаях, когда у меня возникают эти ошибки, я помещаю COMMIT после каждой значимой строки (или, если я чувствую подозрение, только после строк, которые, по моему мнению, могут быть проблемой), и смотрю, какая из них barfs.
Однако беглый просмотр ваших правил показывает, что это ваша вероятная проблема:
-A INPUT -p tcp -m state --state NEW --dport 22-j ACCEPT
Отсутствие пространства между 22 и -j вероятно, причина затруднений. «Не уделяется внимания деталям», как говорят крутые ребята.
РЕДАКТИРОВАТЬ: С добавленной информацией, я собираюсь рискнуть и сказать, что это проблема OpenVZ (ваш VPS-провайдер не дал вам квоты iptables для добавления ваших собственных правил). В любом случае я сам найду нового провайдера VPS; VZ похож на игрушку виртуализации Фишера Прайса. У него есть свое место в корпоративном центре обработки данных и в сегменте рынка, чувствительного к цене 0,89 доллара за десятилетие, но для профессионального хостинга VPS это абсолютная собака.
Возможно, он не работает из-за символа пробела перед COMMIT?
Я знаю, что это старый пост, но он может решить чью-то проблему.
У меня была такая же ошибка, и это из-за опечатки.
Выдаваемая ошибка была в последней строке "COMMIT", но на самом деле это была следующая:
-A RH-Firewall-1-INPUT -p tcp -m udp --dport 161 -j ACCEPT
Ошибка заключалась в том, что в той же строке написано "tcp", а затем "udp". Итак, измените эту строку на:
-A RH-Firewall-1-INPUT -p udp -m udp --dport 161 -j ACCEPT
Решил мою проблему
Старая ветка, но также первая в результатах Google. Возможно, приведенная ниже информация поможет тому, кто рвет на себе волосы, пытаясь понять, почему iptables правила не восстанавливаются при загрузке.
Я наткнулся на эту проблему в Ubuntu 18.04. В netfilter-persistent служба случайным образом не работает при загрузке, но работает нормально при запуске вручную. Оказалось, это противоречило sshguard обслуживание из-за systemd пытаюсь загрузить все параллельно. Помогло установка ENABLE_FIREWALL=0 в /etc/default/sshguard а затем добавив sshguard цепочку и правило вручную, чтобы /etc/iptables/rules.v4 и /etc/iptables/rules.v6.