LINUX.ORG.RU
решено Форум — Admin  

bridge, iptables forward


0

0

hi! Есть bridge br1 

br1		8000.0011955d362d	no		eth0
							tap_local1
							tap_local2

На tap_local1 висит ОС, которая по DHCP получает настройки из локальной сети, к которой физичеcки подключен eth0. Все идеально работает при условии iptables -P FORWARD ACCEPT.

При этом конфиге iptables настройки по дхцп не принимаются. 

LAN_NET="192.168.1.0/24"
local_nic="br1"
iptables -F -t nat
iptables -F -t filter
iptables -P FORWARD DROP
  
  #									   forward между интерфейсами

iptables -A FORWARD -i $local_nic	-o tap_local1		-j ACCEPT
iptables -A FORWARD -o $local_nic	 -i tap_local1		 -j ACCEPT
iptables -A FORWARD -i $local_nic	 -o eth0				   -j ACCEPT
iptables -A FORWARD -o $local_nic	 -i eth0			   -j ACCEPT

iptables -A FORWARD -i tap_local1	 -o eth0			   -j ACCEPT
iptables -A FORWARD -o tap_local1	 -i eth0			   -j ACCEPT
 
iptables -A FORWARD -d $LAN_NET					  -j ACCEPT
iptables -A FORWARD -s $LAN_NET					   -j ACCEPT

tcpdump на br1,tap_local1 и eth0 во время неудачной попытки показывает 

15:11:24.429490 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
15:11:27.579696 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
15:11:35.689911 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
15:11:50.739974 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]

в случаи успеха 

5:34:20.384272 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
15:34:20.385270 IP 192.168.1.1.67 > 192.168.1.140.68: BOOTP/DHCP, Reply, length 320
15:34:20.387549 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
15:34:20.390299 IP 192.168.1.1.67 > 192.168.1.140.68: BOOTP/DHCP, Reply, length 320
Совсем опух понимать, какое правило не дает получить ответ от dhcp сервера. У кого-нибудь есть идея?

← Как сбалансировать нагрузку между серверами
Postfix + Active Directory →

>Совсем опух понимать, какое правило не дает получить ответ от dhcp сервера. У кого-нибудь есть идея?

iptables -P FORWARD DROP <<< Вот это // К.О.

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

Ну да, я просто не правильно поставил вопрос. Где видна ошибка в правилах FORWARD -J ACCEPT ?

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

Все полностью 

Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
2        0     0 ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           
3        0     0 ACCEPT     all  --  tap2   *       0.0.0.0/0            0.0.0.0/0           
4        0     0 ACCEPT     all  --  tap1   *       0.0.0.0/0            0.0.0.0/0           
5        0     0 ACCEPT     all  --  tap0   *       0.0.0.0/0            0.0.0.0/0           
6        0     0 ACCEPT     all  --  tap_den *       0.0.0.0/0            0.0.0.0/0           
7        0     0 ACCEPT     all  --  tap_local1 *       0.0.0.0/0            0.0.0.0/0           
8        0     0 ACCEPT     all  --  tap_local2 *       0.0.0.0/0            0.0.0.0/0           
9        0     0 ACCEPT     all  --  br1    *       0.0.0.0/0            0.0.0.0/0           
10       1   123 ACCEPT     icmp --  br0    *       0.0.0.0/0            0.0.0.0/0           
11       3   487 ACCEPT     udp  --  br0    *       0.0.0.0/0            0.0.0.0/0           
12     561  596K ACCEPT     tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0           ctstate RELATED,ESTABLISHED 
13       0     0 ACCEPT     tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0           ctstate NEW multiport dports 20,21,555,10522,51413 

Chain FORWARD (policy DROP 6 packets, 796 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     all  --  br1    tap_local1  0.0.0.0/0            0.0.0.0/0           
2        0     0 ACCEPT     all  --  tap_local1 br1     0.0.0.0/0            0.0.0.0/0           
3        0     0 ACCEPT     all  --  br1    eth0    0.0.0.0/0            0.0.0.0/0           
4        0     0 ACCEPT     all  --  eth0   br1     0.0.0.0/0            0.0.0.0/0           
5        0     0 ACCEPT     all  --  tap_local1 eth0    0.0.0.0/0            0.0.0.0/0           
6        0     0 ACCEPT     all  --  eth0   tap_local1  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 386 packets, 20531 bytes)
num   pkts bytes target     prot opt in     out     source               destination

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

Hint

В качестве имени интерфейса можно написать любую лабуду, и netfilter схавает. Собственно, ты так и сделал.
С точки зрения netfilter'а, входящий и исходящий интерфейс для всех пакетов один — br1, а всякие tap_local и eth — просто левая лабуда.

Если хочешь, чтобы netfilter проверял, через какой порт моста входит или выходит пакет, используй критерий physdev.

nnz ★★★★
()
Ответ на: комментарий от anton_jugatsu 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:01:02:26:1e:79 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:11:95:5d:36:2d brd ff:ff:ff:ff:ff:ff
    inet6 fe80::211:95ff:fe5d:362d/64 scope link 
       valid_lft forever preferred_lft forever
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:24:1d:16:07:46 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::224:1dff:fe16:746/64 scope link 
       valid_lft forever preferred_lft forever
5: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/ether 52:55:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5055:ff:fe12:3456/64 scope link 
       valid_lft forever preferred_lft forever
6: tap1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/ether 58:65:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5a65:ff:fe12:3456/64 scope link 
       valid_lft forever preferred_lft forever
8: tap_local1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/ether c6:c2:81:e1:9e:b9 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::c4c2:81ff:fee1:9eb9/64 scope link 
       valid_lft forever preferred_lft forever
9: tap_local2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/ether 58:65:00:21:43:56 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5a65:ff:fe21:4356/64 scope link 
       valid_lft forever preferred_lft forever
10: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 00:24:1d:16:07:46 brd ff:ff:ff:ff:ff:ff
    inet 210.49.35.136/26 brd 210.49.35.191 scope global br0
    inet6 fe80::224:1dff:fe16:746/64 scope link 
       valid_lft forever preferred_lft forever
11: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 00:11:95:5d:36:2d brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.12/24 brd 192.168.2.255 scope global br1
    inet6 fe80::211:95ff:fe5d:362d/64 scope link 
       valid_lft forever preferred_lft forever
12: tap_den: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/ether 58:65:00:10:04:56 brd ff:ff:ff:ff:ff:ff
    inet 192.168.50.1/24 brd 192.168.50.255 scope global tap_den
    inet6 fe80::5a65:ff:fe10:456/64 scope link 
       valid_lft forever preferred_lft forever
macumazan ★★
() автор топика
Ответ на: Hint от nnz

Добавлю, что если нужно фильтровать трафик, идущий между забридженными интерфейсами, то использовать нужно не iptables, а ebtables.

Deleted
()

Спасибо, что-то уже вырисовывается. Почитал про ebtables и погуглил про physdev. Возник вопрос, ebtables и iptables -m physdev можно использовать или это или это, по вкусу? Вот тут http://bwachter.lart.info/linux/bridges.html увидел, что для моста юзают iptables -m physdev, хотя про ebtables пишут, что он тоже как раз под мой случай попадает.

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

Юзай то, что для тебя более удобно.
При желании ip_tables на мостах можно вообще отключить.

Только учти, что ebtables является stateless фаерволом, и никаких ESTABLISHED,RELATED там не будет. С другой стороны, ip_tables не умеет проверять mac-адрес назначения и не понимает в L3 ничего, кроме своего IP.

nnz ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Как сбалансировать нагрузку между серверами
Admin
Postfix + Active Directory →