задача в том, чтобы iptables на сервере ограничивал доступ к определённым портам, для всех кто подключается НЕ с IP этого сервера, то есть не из под VPN
там сверху вниз -проброс портов и masquerade в таблице NAT, а цепочка FORWARD в таблице FILTER. Нет никакой разницы, заполните вы сперва NAT, затем FILTER или сперва FILTER, затем NAT.
Accept
проброс портов
masquerade
и в самый низ я пихаю эти 3 правила, мы же дропаем FORWARD этих пакетов ? или их надо пихать до правила masquerade ?Никакой разницы между этими вариантами не будет, они эквивалентны. Либо оба эти варианта будут работать, либо оба варианта работать не будут. Зависит от того, что у вас раньше в цепочке FORWARD.
Возможно необходимо прописать какие-то правила в iptables?Разве что через iptables покрасить (маркировать) ssh-трафик, и потом на основе покраски маршрутизировать его мимо туннеля.
Обычный BitrixVM с дефолтными настройкамиПредставьте, как будто я ничего не знаю об архитектуре Bitrix, зато неплохо разбираюсь в iptables. Можете описать чуть подробнее? Web-сервер находится на виртуальной машине? И эти правила iptables применяете на той же виртуальной машине? Сетевой интерфейс один, не считая lo? (вопрос связан с правилом, блокирующим весь FORWARD)
iptables -L -n -v
почему моя настройка неправильна и не соответствует тз ?Потому что в первом правиле вы разрешаете NEW, независимо от портов, так что второе и третье правила становятся бесполезны, и без них уже открыты все порты. Уберите NEW в первом правиле.
а также позволял устанавливать исходящие соединенияА в последнем правиле лучше бы вообще убрать -m conntrack --ctstate NEW,ESTABLISHED,RELATED.
-A INPUT -p tcp -m tcp --dport 8291 -j LOG --log-prefix "MIKROTIK: "
Не сработает, потому что этот трафик попадёт в FORWARD, а не в INPUT.-A POSTROUTING -d 192.168.42.11/32 -p tcp -m tcp --dport 8291 -j SNAT --to-source 10.0.1.4
-A POSTROUTING -d 192.168.42.11/32 -p tcp -m tcp --dport 8291 -j MASQUERADE
Второе из этих двух правил не может сработать, потому что срабатывает первое. Уберите первое, оставьте только MASQUERADE, и есть шанс, что заработает, как надо. Возможно, Микротик не знает маршрута до 10.0.1.4 (если вы не прописали такой маршрут). Пробовал так:Ошибка в имени интерфейса - в правиле ens0, а выше показан ens0.
и так:А так должно работать, по идее.
iptables до изменений имеет вид:Проверьте после изменений, появляются ли новые правила. А то я столкнулся с тем, что именно в Ubuntu 22.04 поломали iptables (отработанный годами набор правил, работавший на Ubuntu 20.04, просто выдавал ошибки при попытке их добавления на Ubuntu 22.04). Я не знаю, может быть, уже починили это, а может быть и нет.
Существуют ли способы узнать какие порты и протоколы пытается использовать какая-либо сущность в ос?Есть старая команда
netstat
(кучу ключей, определяющих, что именно она показывает, смотрите в man netstat или в гугле). Есть более новая команда ss
.а при обращение к subdomain.site.com перенаправило на 44.44.44.44 (почтовый сервер)Почтовому серверу пофиг домен при установке соединения, так что ориентруйтесь по номерам портов.
iptables -A PREROUTING -d 22.22.22.22 -p tcp --dport 25 -j DNAT --to-destination 44.44.44.44
iptables -A PREROUTING -d 22.22.22.22 -p tcp --dport 465 -j DNAT --to-destination 44.44.44.44
iptables -A PREROUTING -d 22.22.22.22 -p tcp --dport 587 -j DNAT --to-destination 44.44.44.44
iptables -A PREROUTING -d 22.22.22.22 -p tcp --dport 80 -j DNAT --to-destination 33.33.33.33
iptables -A PREROUTING -d 22.22.22.22 -p tcp --dport 443 -j DNAT --to-destination 33.33.33.33
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp --icmp-type 4 -j ACCEPT
-A INPUT -p icmp --icmp-type 11 -j ACCEPT
-A INPUT -p icmp --icmp-type 12 -j ACCEPT
-A INPUT -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp --dport 1194 -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A INPUT -i tap+ -j ACCEPT
-A INPUT -j DROP
-A OUTPUT -j ACCEPT
но как сделать чтобы он еще и отправлял в список ipsetСредствами iptables никак, наверное. Но можно написать скрипт, который будет периодически парсить файл
/proc/net/xt_recent/get_packets
и засовывать результат в ipset.