Вопросы Теги

Ошибка, применяющаяся iptables правила с помощью iptables-восстановления

Да - это должно быть довольно возможно, пока у Вас нет требования для наблюдения того же устройства хранения данных на компьютере, как Вы делаете в сети.

Если бы Вы действительно хотите видеть то же самое, такая конфигурация потребовала бы своего рода файловой системы мультимонтирования. Вы пытаетесь экспортировать те же данные и с помощью протокола сетевой файловой системы и с помощью блочного уровня.

Вы смогли выходить сухим из воды (более или менее), если устройство хранения только позволило компьютеру монтировать свое устройство хранения данных, только для чтения. Это работало бы большую часть времени :)

2
задан 9 January 2010 в 06:35
5 ответов

Из-за пути iptables-restore работы, о почти всех ошибках сообщат как являющийся в COMMIT точка. В нечетном случае у меня есть эти ошибки, я иду, помещая ФИКСАЦИИ после каждой значительной строки (или, если я чувствую себя подозрительным, после того, как просто строки, я думаю, могли бы быть проблемой), и видящий, какой блюет.

Однако краткий контроль Ваших правил указывает, что это - Ваша вероятная проблема:

-A INPUT -p tcp -m state --state NEW --dport 22-j ACCEPT

Недостаток места между 22 и -j вероятно, причина трудности. "Сбой внимания к деталям", как спокойные дети говорят.

Править: С добавленной информацией я собираюсь рискнуть и сказать, что это - проблема OpenVZ (Ваш поставщик VPS не дал Вам iptables квоты для добавления собственных правил). Я нашел бы нового поставщика VPS так или иначе, сам; VZ похож на игрушку Fisher Price виртуализации. Это имеет, это - место в корпоративном информационном центре и "чувствительном к цене" конце за $0.89/десятилетия рынка, но для профессионального VPS хостинг это - абсолютная собака.

4
ответ дан 3 December 2019 в 09:12
  • 1
    I' m извините, которые располагают с интервалами, я случайно поместил при вводе здесь. Это - сценарий, который я использовал в качестве ссылки. articles.slicehost.com/assets/2007/9/4/iptables.txt –   9 January 2010 в 06:37
  • 2
    Я пытался добавить правила к iptables непосредственно при подсказке. Когда я выполнил вторую строку, т.е. iptables-A ВВОДЯТ-i! lo-d 127.0.0.0/8-j ОТКЛОНЯЮТ, я получил следующую ошибку " iptables: Никакая цепочка/цель/соответствие этим name" –   9 January 2010 в 06:39
  • 3
    Вы серьезно выводили ту целую вещь вручную? I' m безмолвный. Кто знает, сколько дополнительных опечаток Вы добавили (я замечаю, что Ваша опечатка порта SSH превратилась). Учитывая, что what' s в том URL isn' t что-либо как Ваш сценарий, I' d просят, чтобы Вы поместили точно что you' ve вошел в Ваш вопрос так, чтобы мы могли на самом деле помочь Вам. О, и Вы могли бы хотеть выйти из этого ! на командной строке. Bash становится раздражительным иначе. –  womble♦ 9 January 2010 в 08:51
  • 4
    Нет я didn' t вводят все это, я сделал некоторые дополнительные пространства, только поднимая вещь в serverfault.com, я на самом деле загрузил сценарий с помощью wget и затем внес некоторые изменения. Но можете Вы говорить мне почему эта строка " iptables-A ВВОДЯТ-i! lo-d 127.0.0.0/8-j REJECT" дает ошибку " Никакая цепочка/цель/соответствие этим name" –   9 January 2010 в 10:30
  • 5
    Поскольку you' ре с помощью OpenVZ VPS, согласно моему отредактированному ответу. –  womble♦ 9 January 2010 в 11:53

Возможно, это перестало работать из-за пробела, который Вы имеете перед ФИКСАЦИЕЙ?

0
ответ дан 3 December 2019 в 09:12
  • 1
    Nah it' s не, что, пространство случайно прибыло, когда я ввел код здесь. Из-за чего еще это могло произойти? –   9 January 2010 в 01:54
  • 2
    Как Вам удается получить пространство посреди блока вставляемого кода? Если what' s в Вашем вопросе isn' t, что Вы действительно имеете, затем отредактируйте свой вопрос заставить его соответствовать действительности. –  womble♦ 9 January 2010 в 04:26

Я знаю, что это старый пост, но он может решить чью-то проблему.

У меня была та же ошибка, но это произошло из-за опечатки.

Ошибка, которая была выброшенный был в "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

Моя проблема решена

0
ответ дан 3 December 2019 в 09:12

На данный момент очень старый пост, но это лучший результат в Google, поэтому я решил, что обновлю свое решение ...

После COMMIT или iptables-restore должна быть пустая строка завершится ошибкой "команда не указана" в строке "COMMIT".

3
ответ дан 3 December 2019 в 09:12

Старая ветка, но также первая в результатах Google. Возможно, приведенная ниже информация поможет тому, кто рвет на себе волосы, пытаясь понять, почему правила iptables не восстанавливаются при загрузке.

Я наткнулся на эту проблему в Ubuntu 18.04. Служба netfilter-persistent произвела сбой при загрузке, но при ручном запуске работала нормально. Оказалось, что это конфликт со службой sshguard из-за того, что systemd пытается загрузить все параллельно. Что помогло, так это установка ENABLE_FIREWALL = 0 в / etc / default / sshguard , а затем добавление цепочки sshguard и правила вручную в / etc / iptables / rules.v4 и /etc/iptables/rules.v6 .

0
ответ дан 3 December 2019 в 09:12

Теги

Похожие вопросы