Назад | Перейти на главную страницу

iptables NAT с сетевым мостом, контейнерами и systemd-networkd: без пересылки

У меня возникли проблемы с настройкой iptables NAT на CentOS 7. В настоящее время клиент, находящийся за NAT, может подключиться к внешнему IP-адресу, но не к внешней сети.

Я следовал этому руководству, чтобы настроить NAT, зная, что он хорошо работает в Gentoo и Arch:

http://www.revsys.com/writings/quicktips/nat.html

чтобы схематизировать мою проблему:

когда я пингую с 192.168.2.2:

Обратите внимание, что я также установил правило переадресации портов с 192.168.1.1:80 на 192.168.2.2:80. Это работает хорошо, согласно Wireshark, мои пакеты успешно перенаправляются на 192.168.2.2. Затем ответ 192.168.2.2, но пакет отбрасывается, поэтому я вижу многократную повторную передачу TCP. Нет никаких сообщений «хост административно запрещен».

Вот сообщения Dropwatch, когда я пытаюсь подключиться к 192.168.2.2:80 извне:

1 drops at ip_error+68 (0xffffffff815c47d8)
1 drops at ip_error+68 (0xffffffff815c47d8)
1 drops at ip_error+68 (0xffffffff815c47d8)
1 drops at ip_error+68 (0xffffffff815c47d8)
1 drops at tcp_rcv_state_process+1b0 (0xffffffff815e5030)
1 drops at ip_error+68 (0xffffffff815c47d8)
1 drops at tcp_rcv_state_process+1b0 (0xffffffff815e5030)
1 drops at ip_error+68 (0xffffffff815c47d8)
2 drops at ip_error+68 (0xffffffff815c47d8)
1 drops at tcp_v4_do_rcv+80 (0xffffffff815ef160)
1 drops at ip_error+68 (0xffffffff815c47d8)
1 drops at tcp_v4_do_rcv+80 (0xffffffff815ef160)
1 drops at ip_error+68 (0xffffffff815c47d8)
2 drops at ip_error+68 (0xffffffff815c47d8)
1 drops at tcp_v4_do_rcv+80 (0xffffffff815ef160)
2 drops at ip_error+68 (0xffffffff815c47d8)
1 drops at tcp_v4_do_rcv+80 (0xffffffff815ef160)
1 drops at ip_error+68 (0xffffffff815c47d8)

Пожалуйста, есть ли у кого-нибудь представление о том, что я сделал не так? Всем спасибо.

РЕДАКТИРОВАТЬ :

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -d 192.168.2.2/32 -p tcp -m tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Chain PREROUTING (policy ACCEPT 1270 packets, 123K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   30  1696 DNAT       tcp  --  eth0 any     anywhere             anywhere             tcp dpt:http to:192.168.2.2:80

Chain INPUT (policy ACCEPT 347 packets, 42272 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 6 packets, 431 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 30 packets, 1696 bytes)
 pkts bytes target     prot opt in     out     source               destination                                             
    6   431 MASQUERADE  all  --  any    eth0  anywhere             anywhere 

РЕДАКТИРОВАТЬ :

Да IP-переадресация настроена правильно. Когда я пингую с 192.168.2.2 на 192.168.1.2, я не вижу ни одного пакета, входящего с Wireshark на 192.168.1.2. Также я не вижу пакетов, исходящих из eth0 при использовании Wireshark.

Любопытно, что когда я успешно пингую 192.168.1.1 с 192.168.2.2, я тоже не вижу ни одного ICMP-пакета, поступающего на eth0.

Я думаю, что должен добавить то, что не раскрыл, потому что не нашел в этом актуального. На самом деле я пытаюсь преобразовать сетевой мост с именем br0 (здесь мой eth1) через NAT в локальную локальную сеть. Мой сервер 192.168.2.2 находится в контейнере с вэтом, подключенным к мосту.

Я не знаю, следует ли мне редактировать весь свой пост, чтобы лучше отразить ситуацию. Я думал, что моя проблема была чисто ошибкой iptable, но похоже, что что-то не так в сетевом стеке, потому что я должен видеть входящие пакеты ICMP при пинге 192.168.1.1.

Когда я сказал, что уже сделал эту настройку на Gentoo и Arch, это тоже было с контейнерами, используя LXC. Теперь пытаюсь использовать systemd-nspawn. Selinux установлен как разрешающий. Пинг 192.168.2.2 с моего хоста CentOS в порядке, заставить его использовать eth0 не работает, но это нормальное поведение.

хост маршрутов:

default via 192.168.1.254 dev eth0 proto static metric 100 
192.168.2.0/24 dev br0 proto kernel scope link src 192.168.2.1 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1 metric 100

Контейнер маршрутов:

default via 192.168.2.1 dev host0 proto static 
192.168.2.0/24 dev host0 proto kernel scope link src 192.168.2.2

Наконец я нашел решение после очень сильной головной боли ...

Я использовал systemd-networkd для настройки своего моста. Хотя net.ipv4.ip_forward был правильно установлен на 1, и я также установил net.ipv4.conf.all.forwarding на 1, похоже, что systemd-networkd не принял во внимание мое значение по умолчанию при установке моста.

Si закончилось тем, что net.ipv4.conf.br0.forwarding был установлен на 0. Я просто установил его на 1, и теперь он работает.

Для всех, у кого есть подобная проблема, выполните эту команду:

sysctl -a | grep "\.forwarding" | grep ipv4

Убедитесь, что на всех ваших интерфейсах включена пересылка.

Хорошего дня.