LINUX.ORG.RU
ФорумAdmin

Помогите понять работу iptables

 ,


0

1

Привет. Есть на сервере VPN Wireguard, в docker запущен DNS сервер pi-hole. Наружу проброшены порты 53 и 80 из докера, что бы DNS был доступен и его админка. Мне нужно что бы днс и админка были доступны только внутри VPN сети. Сейчас VPN отключен. Делаю с своего локалхоста

dig -t A ya.ru @<pi-hole-server-ip>

он отвечает нормально, резолвит адрес. Но я не понимаю почему, в правилах все кроме VPN и SSH закрыто вроде. При этом делаю на самом серваке куда я по ssh подключился

dig -t A ya.ru @<wireguard-interface-ip>
dig -t A ya.ru @<pi-hole-server-ip>
dig -t A ya.ru @127.0.0.1

не овечает. Одновременно такое

curl http://<pi-hole-server-ip>:80

один раз ответило и затихло когда вызывал с своего локалхоста, при этом изнутри сервера не отвечало никогда. Помогите разобраться в правилах, я только начал вникать как они работают и вероятно не понимаю чего то. Сами правила.

# Generated by iptables-save v1.8.7 on Thu Aug 10 08:30:46 2023
*filter
:INPUT DROP [195:10870]
:FORWARD DROP [26:1870]
:OUTPUT ACCEPT [6821:537827]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
-A INPUT -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp ! --dport 56777 -j DROP
-A INPUT -i eth0 -p udp -m udp ! --dport 51820 -j DROP
-A INPUT -i eth0 -p tcp -m tcp --dport 56777 -m recent --update --seconds 60 --hitcount 6 --name SSH --mask 255.255.255.255 --rsource -j DROP
-A INPUT -i eth0 -p tcp -m tcp --dport 56777 -m recent --set --name SSH --mask 255.255.255.255 --rsource -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 51820 -j ACCEPT
-A INPUT -i wg0 -j ACCEPT
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o br-a34535bd1500 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-a34535bd1500 -j DOCKER
-A FORWARD -i br-a34535bd1500 ! -o br-a34535bd1500 -j ACCEPT
-A FORWARD -i br-a34535bd1500 -o br-a34535bd1500 -j ACCEPT
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wg0 -j ACCEPT
-A DOCKER -d 172.18.0.2/32 ! -i br-a34535bd1500 -o br-a34535bd1500 -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER -d 172.18.0.2/32 ! -i br-a34535bd1500 -o br-a34535bd1500 -p tcp -m tcp --dport 53 -j ACCEPT
-A DOCKER -d 172.18.0.2/32 ! -i br-a34535bd1500 -o br-a34535bd1500 -p udp -m udp --dport 53 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i br-a34535bd1500 ! -o br-a34535bd1500 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o br-a34535bd1500 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Thu Aug 10 08:30:46 2023
# Generated by iptables-save v1.8.7 on Thu Aug 10 08:30:46 2023
*nat
:PREROUTING ACCEPT [68541:9815794]
:INPUT ACCEPT [41:2701]
:OUTPUT ACCEPT [2043:106845]
:POSTROUTING ACCEPT [2014:104848]
:DOCKER - [0:0]
-A PREROUTING -i eth0 -p udp -m multiport --dports 123,1194 -j REDIRECT --to-ports 51820
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.18.0.0/16 ! -o br-a34535bd1500 -j MASQUERADE
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -s 172.18.0.2/32 -d 172.18.0.2/32 -p tcp -m tcp --dport 80 -j MASQUERADE
-A POSTROUTING -s 172.18.0.2/32 -d 172.18.0.2/32 -p tcp -m tcp --dport 53 -j MASQUERADE
-A POSTROUTING -s 172.18.0.2/32 -d 172.18.0.2/32 -p udp -m udp --dport 53 -j MASQUERADE
-A DOCKER -i br-a34535bd1500 -j RETURN
-A DOCKER -i docker0 -j RETURN
-A DOCKER ! -i br-a34535bd1500 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.18.0.2:80
-A DOCKER ! -i br-a34535bd1500 -p tcp -m tcp --dport 53 -j DNAT --to-destination 172.18.0.2:53
-A DOCKER ! -i br-a34535bd1500 -p udp -m udp --dport 53 -j DNAT --to-destination 172.18.0.2:53
COMMIT
# Completed on Thu Aug 10 08:30:46 2023

На всякий случай маршрутизация

default via 193.42.36.1 dev eth0 onlink 
10.156.12.0/24 dev wg0 proto kernel scope link src 10.156.12.1 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.18.0.0/16 dev br-a34535bd1500 proto kernel scope link src 172.18.0.1 
193.42.36.0/24 dev eth0 proto kernel scope link src 193.42.36.76 

Там еще wireguard запущен, так что есть таблицы маршрутизации его стандартные.

★★

Последнее исправление: leave (всего исправлений: 1)

При создании контейнера docker добавить network параметр(если не ошибаюсь)
«Мне нужно что бы днс и админка были доступны только внутри VPN сети»
сделайте проброс портов с этой сети в ваш контейнер с доп ключом network
После проверить через вывод списка правил iptables

Vlad-76 ★★★★
()
Ответ на: комментарий от Vlad-76

Суть вопроса состояла в том, почему при текущей таблице такое поведение. Мне в первую очередь надо понять причину и суть работы. Остальное сделать будет не сложно.

Поясню, контейнер я поднимаю docker-compose

version: "3"

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    # For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
      # - "53:53/tcp"
      # - "53:53/udp"
      #- "67:67/udp" # Only required if you are using Pi-hole as your DHCP server
      # - "80:80/tcp"
    environment:
      TZ: 'UTC+02:00'
      FTLCONF_LOCAL_IPV4: "{{ vpn_net }}.1"
      # WEBPASSWORD: 'set a secure password here or it will be random'
    # Volumes store your data between container upgrades
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq.d:/etc/dnsmasq.d'
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    # cap_add:
    # - NET_ADMIN # Required if you are using Pi-hole as your DHCP server, else not needed
    restart: unless-stopped
i3draven ★★
() автор топика
Последнее исправление: i3draven (всего исправлений: 2)
Ответ на: комментарий от i3draven

Буквально пару недель назад потратил время на ролик в интернет по docker. Автор ролика при конфигурировании сети не разъяснял что происходит под капотом (с бриджами , с iptables, с ТМ в linux) но мне подумалось что скорее всего как и у других (openvz,lxc и др). Но автор объяснял (на мой взглад не очень глубоко) про то какие сети бывают в docker и как это делается через команду docker.
Все же я подсмотрел командой iptables список правил и ничего для себя интересного не увидел и решил, что разрабы докер-а знают как правильно конфигурить iptables, bridges и т.д. от меня нужно правильно формулировать команде docker ключи с параметрами
ролик про сети в docker https://youtu.be/O8N1lvkIjig?t=6523
Автор ролика в некоторых местах объясняет некоторые вещи некорректно - допустим нужно сказать о пробросе портов с использованием NAT - вместо этого он говорит «мостик», хотя мостик,мост,бридж в Linux имеет свое значение

root@secure:~/docker# brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242ef105826       no              veth83b063b
                                                        veth8629061
                                                        veth9d330fc
                                                        vethcbdfb4d
                                                        vethff1430b
root@secure:~/docker#
ВОбщем к чему я написал, сеть в docker это не сложно, потратьте время на этот ролик станет многое понятнее.
есть интересные ключи для понимания сущностей которыми оперирует docker
docker network ls[br]
root@secure:~# docker network ls
NETWORK ID     NAME                   DRIVER    SCOPE
f5303ce6d3c0   bridge                 bridge    local
8e771da8f2c7   host                   host      local
9064fe04205a   my-8021q-macvlan-net   macvlan   local
689755f80129   none                   null      local


docker inspect <NETWORK ID>
Есть даже руководства для конфигурирования того чего Вам нужно
https://www.procustodibus.com/blog/2022/02/wireguard-remote-access-to-docker-...

Vlad-76 ★★★★
()
Последнее исправление: Vlad-76 (всего исправлений: 1)
Ответ на: комментарий от Vlad-76

Да причем тут докер то? Выше я привел полный конфиг таблиц. Мне надо понять как он работает, даже если я его руками написал бы. Я написал ситуацию с сетью, мне нужно понять каким образом так получилось из этой таблицы, что порт 53 торчит наружу и порт 80 ответил лишь однажды. Мне докер вообще в данном случае не важен.

Мало того я написал уже, что композом конфигурю все. Но это повторю не имеет значения.

Мне нужно что бы человек, который соображает в работе iptables объяснил как эта таблица приводит к такому поведению. Если кто из соображающих время найдет.

i3draven ★★
() автор топика
Последнее исправление: i3draven (всего исправлений: 2)
Ответ на: комментарий от i3draven

выключайте систему от сети чтобы в нее не долбился кто попало, затем выполняйте Ваши команды диагностики по одной и смотрите счетчики и трассировку iptables после каждой команды
я так думаю

Vlad-76 ★★★★
()
Ответ на: комментарий от Vlad-76

https://backreference.org/2010/06/11/iptables-debugging/index.html
в обсуждении поста


noname says:	
May 29, 2018 at 10:22	

On 4.4.0 I had to do:

modprobe nf_log_ipv4
sysctl net.netfilter.nf_log.2=nf_log_ipv4

And if you get nothing in /var/log/kern.log, check if you have kernel logging enabled in syslog and if LOG_KERN facility exists.
Chris says:	
May 29, 2015 at 00:08	

With Kernel 4.0.4, I had to use:

sysctl 'net.netfilter.nf_log.2=nf_log_ipv4
tudor says:	
November 6, 2013 at 11:33	

Works after configure this:
sudo sysctl net.netfilter.nf_log.2=ipt_LOG

Thanks!
Yanis Guenane says:	
May 30, 2013 at 18:12	

Thank you for this post. Really informative and actually straigh to the point. Exactly what I needed

Vlad-76 ★★★★
()

Что как то все сложно. С либвирт проще, там внутри ВМ полноценный стек сети и просто запрещаешь INPUT и все.

Что касаеться докера может просто пробросить нужные порты на адрес wg ?

mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 1)
Ответ на: комментарий от anc

Я про то что внутри ВМ, полноценный ящик (свое ядро со своим ип стеком), он ставит в той ОС в его iptables принимать только с сетки WG (хз какой там у него ip) и все.

P.S. Не к вам а так … до сих пор удивляюсь людям которые думают что бридж это уровень не л2 а л3.

mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 2)
Ответ на: комментарий от Vlad-76

Очень удобная штука. В итоге быстро удалось понять, что

iptables -t nat -L -nv
Chain PREROUTING (policy ACCEPT 47 packets, 4732 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REDIRECT   udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            multiport dports 123,1194 redir ports 51820
   31  2070 DOCKER     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL

до всяких правил докер берет и исполняет свои

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     all  --  br-5a1dd2d5018c *       0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  docker0 *       0.0.0.0/0            0.0.0.0/0           
    0     0 DNAT       tcp  --  !br-5a1dd2d5018c *       0.0.0.0/0            10.156.12.1          tcp dpt:80 to:172.19.0.2:80

Насколько я понимаю свой трафик бриджа он отбросит, а вот трафик от любого интерфейса, идущий на 10.156.12.1 (это wireguard vpn интерфейс) он пропустит к порту 80, перенаправив его на докер контейнер.

При этом для wireguard поведение по умолчанию все, что в дефолт роутинг прилетело, отправить на интерфейс 10.156.12.1. Во всяком случае для клиента так, думаю и для сервера тоже, коим и является эта машина. И цепочка получается такая eth0->default route->wg0->DOCKER->docker:80 В итоге VPN+docker открыли 80 порт наружу слившись в экстазе. Судя по всему простое решение сделать тип сети в docker = host, все упростится в сто раз и просто будет работать filter цепочка.

Но это если я верно понял то, что прочитал. Изучаю еще.

i3draven ★★
() автор топика
Ответ на: комментарий от i3draven

если у Вас wireguard своей жизнью живет, то как будет работать docker контейнер связанный с VPN сетью wireguard если остановить и старатануть wireguard ? Перезапускать docker контейнер? или связать интерфейс wg0 через независимый от docker и wireguard bridge?
точнее все будет зависимо, но должна быт очевидна логика, как система восстановит свою работу если ее ребутнуть полность, или ее подсистемы.

Это единственный вопрос мне не давал покоя после того как я прочитал Ваш первый пост.

Vlad-76 ★★★★
()
Последнее исправление: Vlad-76 (всего исправлений: 1)
Ответ на: комментарий от Vlad-76

Судя по всему мои теории были ложными. Я обнаружил, что то, что я проверял через dig @myip ya.ru отвечало потому, что у моего провайдера vps на этой же айпишнике сидит кто то еще и держит DNS сервер :) Уже написал им вопрос «какого хрена». У меня логирование трафика от этого сказочное, море его на моем eth0. 80 порт именно поэтому закрыт, а 53 загадочно был открыт, он открыт не у меня. Так что все обошлось проще чем я думал. Спасибо большое за помощь, трейсер прям очень помог.

i3draven ★★
() автор топика
Ответ на: комментарий от i3draven

Как такое возможно я не понимаю, вот их и спросил. Причем я просто снес VPS с нуля и попробовал, порт открыт.

i3draven ★★
() автор топика
Последнее исправление: i3draven (всего исправлений: 1)
Ответ на: комментарий от i3draven

потому, что у моего провайдера vps на этой же айпишнике сидит кто то еще

Погодите, у вашей VPS именно этот IP прописан? Если да, то когда вы её остановите этот ip продолжит быть доступным?

anc ★★★★★
()
Ответ на: комментарий от anc

Именно так, вырубил

nmap -Pn -p 53 <myip>
Starting Nmap 7.80 ( https://nmap.org ) at 2023-08-12 17:13 CEST
Nmap scan report for mail0.zoxcompany.com (<myip>)
Host is up (0.0061s latency).

PORT   STATE SERVICE
53/tcp open  domain

Статус в админке провадера

Status 	Offline
IP Address 	<myip>

Такие дела.

i3draven ★★
() автор топика
Ответ на: комментарий от i3draven

Причем айпишник был в спам базах раньше, они написали владельцам базы, что бы убрали. Но оказывается, судя по всему он не зря там был :) Так как для меня это развлекалово, то разбираюсь с интересом и с ними переписываюсь. Но судя по всему для серьезного дела hostzealot.com плохой выбор :)

i3draven ★★
() автор топика