Вопрос или проблема
Я замечаю странное/разочаровывающее поведение iptables в Pop!_OS, которое мне сложно понять. Во-первых, у меня есть сервер, на котором я хочу включить входящие ssh-соединения. Следующий набор правил iptables, похоже, не работает (я не могу подключиться по ssh с удаленной машины):
Chain INPUT (policy DROP 434 пакетов, 243K байт)
pkts bytes target prot opt in out source destination
854 85718 ACCEPT all -- lo any anywhere anywhere
0 0 ACCEPT icmp -- any any anywhere anywhere icmp echo-reply
5 420 ACCEPT icmp -- any any anywhere anywhere icmp echo-request
183 27170 ACCEPT udp -- any any anywhere anywhere udp spt:domain
75 9853 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh
706 528K ACCEPT tcp -- any any anywhere anywhere tcp spt:https
183K 472M ACCEPT tcp -- any any anywhere anywhere tcp spt:http
0 0 ACCEPT tcp -- any any anywhere anywhere tcp spt:ssh state ESTABLISHED
Chain FORWARD (policy DROP 0 пакетов, 0 байт)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 129K пакетов, 7005K байт)
pkts bytes target prot opt in out source destination
Однако, если я выполню следующую команду, соединение ssh с удаленной машины начинает работать:
$ sudo iptables -A INPUT -i lo -j ACCEPT
Chain INPUT (policy DROP 434 пакетов, 243K байт)
pkts bytes target prot opt in out source destination
854 85718 ACCEPT all -- lo any anywhere anywhere
0 0 ACCEPT icmp -- any any anywhere anywhere icmp echo-reply
5 420 ACCEPT icmp -- any any anywhere anywhere icmp echo-request
183 27170 ACCEPT udp -- any any anywhere anywhere udp spt:domain
75 9853 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh
706 528K ACCEPT tcp -- any any anywhere anywhere tcp spt:https
183K 472M ACCEPT tcp -- any any anywhere anywhere tcp spt:http
0 0 ACCEPT tcp -- any any anywhere anywhere tcp spt:ssh state ESTABLISHED
0 0 ACCEPT all -- lo any anywhere anywhere
Chain FORWARD (policy DROP 0 пакетов, 0 байт)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 129K пакетов, 7005K байт)
pkts bytes target prot opt in out source destination
Это особенно запутывает, учитывая, что, казалось бы, у меня была точно такая же строка фильтра, разрешающая соединения петли ранее. Имеет ли значение порядок правил в этом случае?
Во-вторых, у меня включена служба systemd netfilter-persistent, но, похоже, она не сохраняет/не перезагружает настройки iptables правильно при загрузке. Когда я перезагружаю, правила возвращаются к первому примеру.
Может кто-нибудь помочь объяснить эти проблемы? Мне нужно, чтобы входящие ssh-соединения были включены на сервере, а настройки брандмауэра сохранялись при перезагрузке.
Ответ или решение
Судя по вашему описанию, вы сталкиваетесь с двумя основными проблемами в настройках iptables на вашем сервере с Pop!_OS. Давайте внимательно рассмотрим каждую из этих проблем и предложим решения.
Проблема 1: Неправильное поведение правил iptables
Определенно, порядок правил в iptables имеет значение. Правила обрабатываются в том порядке, в котором они перечислены, и если соединение не совпадает ни с одним из правил, то оно отклоняется. Основная причина, по которой соединение по SSH не работает в первом случае, заключается в том, что часовой блок tcp dpt:ssh (порт 22) может не срабатывать должным образом, если правило для локального интерфейса (loopback interface, lo) находится в неправильном порядке или если нет правила для принятия входящих соединений из внешних интерфейсов.
Ваши правила работают корректно, когда вы добавляете следующее правило:
sudo iptables -A INPUT -i lo -j ACCEPTЭто правило разрешает весь трафик на локальном интерфейсе (т.е. с самого сервера), что важно, если вы, например, используете какие-либо локальные службы, которые могут требовать связи по SSH. Однако, оно не должно влиять на правило SSH, если оно правильно настроено. Возможно, стоит переместить правило для SSH выше в списке, чтобы гарантировать, что оно обрабатывается до правил, блокирующих входящие соединения.
Предложение по изменению вашего набора правил:
- Убедитесь, что правило для SSH находится на самом верху списка правил, например:
iptables -I INPUT -p tcp --dport 22 -j ACCEPTЭтот подход ставит правило для SSH в начале цепочки, что дает ему более высокий приоритет по сравнению с правилами, которые могут блокировать трафик.
- Если у вас уже есть правило для локального интерфейса, убедитесь, что оно добавлено прежде, чем правило для SSH. Это правило
-A INPUT -i lo -j ACCEPTдолжно быть последним, если ваше намерение — заблокировать все другие входящие соединения.
Проблема 2: Постоянство правил после перезагрузки
Для того чтобы ваши настройки iptables сохранялись и загружались при перезагрузке, необходимо правильно настроить сервис netfilter-persistent.
Решения:
- Убедитесь, что вы устанавливаете правила, которые хотите сохранить. Например, если вы хотите сохранить текущие правила, выполните следующую команду:
sudo netfilter-persistent saveЭто сохранит ваши текущие правила iptables в файловую систему, и они будут применены при следующей загрузке.
- Убедитесь, что служба
netfilter-persistentвключена:
sudo systemctl enable netfilter-persistent- Перезагрузите систему и проверьте статус правил iptables:
sudo iptables -L -v -nЕсли правило не сохраняется, возможно, стоит проверить логи или конфигурацию самого netfilter-persistent. Можно попробовать переустановить пакет или дополнительно изучить документацию на предмет специфических конфигураций для Pop!_OS.
Заключение
Основные шаги, которые стоит предпринять, чтобы решить ваши проблемы, заключаются в упорядочивании правил iptables и убедительности в том, что netfilter-persistent правильно сохраняет и загружает ваши настройки при перезагрузке. Вы также можете изучить использование ufw (Uncomplicated Firewall), который является более простым интерфейсом для работы с iptables и может автоматически управлять многими из этих аспектов для вас.