Я пытаюсь удалить роутер из нашего продукта и заменить все его функциональные возможности на iptables.
Система требуется для выполнения общего управления трафиком, а также для пересылки данных на определенные серверы, расположенные за локальной сетью. Текущая настройка -
eth0 получает IP через DHCP.
eth1, eth2 и eth3 составляют часть моста (br0), который имеет статический адрес 10.0.1.1.
Есть сервер, сидящий на 10.0.1.2, которому нужно обслуживать трафик HTTP и MySQL. Нет гарантии, куда этот сервер будет подключен (eth1 / 2/3), но IP статический.
Я попытался установить правила iptables, которым, кажется, легко следовать только с одним устройством eth, но я завязываюсь узлами, когда требуется пересылка.
Вот что я пробовал до сих пор:
# clear and flush everything
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -t raw -F
iptables -t raw -X
iptables -t security -F
iptables -t security -X
# DROP packets unless covered by rules
iptables -P FORWARD DROP
iptables -P INPUT DROP
# No intention of filtering any outgoing traffic
iptables -P OUTPUT ACCEPT
# Handle our routing
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 10.0.1.2:80
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3306 -j DNAT --to 10.0.1.2:3306
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# Input Chain
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT # ssh
iptables -A INPUT -s 10.0.1.2 -p tcp --dport 3306 -j ACCEPT # ssh
# Forward Chain
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 10.0.1.2 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp --dport 3306 -d 10.0.1.2 -j ACCEPT
# enable ipv4 forwardning for the system
echo 1 > /proc/sys/net/ipv4/ip_forward
Это дает мне результирующую настройку цепочки / правила -
Chain INPUT (policy DROP 1 packets, 49948 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
1 52 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- * * 10.0.1.2 0.0.0.0/0 tcp dpt:3306
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 10.0.1.2 tcp dpt:80
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 10.0.1.2 tcp dpt:3306
Chain OUTPUT (policy ACCEPT 1 packets, 196 bytes)
pkts bytes target prot opt in out source destination
Однако я не могу войти на свой внутренний сервер MySQL через клиента, подключенного через внешний интерфейс (за пределами брандмауэра).
Я читал, что пакеты проходят только через каждую ОДНУ цепочку (либо INPUT / FORWARD / OUTPUT), но это все еще так? Должны ли мои пакеты FORWARD снова обрабатываться как INPUT на отдельном интерфейсе?
Есть ли что-нибудь, что выделяется как неправильное в любой из приведенных выше конфигураций?
Детали конфигурации -
Выход netstat -rn
От клиента, которого я ЖЕСТЯНАЯ БАНКА подключиться из ...
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.0.0.139 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br0
Telnet подключается должным образом.
От клиента, которого я НЕ МОЖЕТ подключиться из ...
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.0.0.139 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wlan0
Telnet просто отображает Trying 10.0.0.17...
и никогда не добивается успеха ...
Описание сети -
10.0.0.0 - это обычная офисная сеть, и здесь подключается интерфейс eth0 на брандмауэре. Его IP-адрес в настоящее время 10.0.0.17 ...
10.0.1.0 - это сеть, которая должна находиться за межсетевым экраном eth1 / 2/3.
Я хочу получить доступ к серверам, находящимся за брандмауэром, используя IP-адрес, присвоенный eth0 (10.0.0.17).
Поскольку вы указываете клиента, который может подключиться, с вашим iptables
настроить. Однако это еще не все: у клиентов должен быть маршрут для достижения перенаправленного адреса сервера, а у сервера должен быть обратный маршрут, чтобы пакеты доходили до перенаправления.
Работающий клиент имеет некоторое физическое присутствие в сети 10.0.1.0/24 и, следовательно, путь к ней:
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
Клиент, который не только не имеет маршрута к 10.0.1.0/24, но и имеет более общий маршрут к 10.0.0.0/16, отправляя трафик со своей беспроводной карты.
Вы не сказали нам геометрию сети, в которой все это происходит; из-за путаницы между сетевыми масками / 24 и / 16 из-за перекрытия пространства, я предполагаю, что все это немного запутано (это не гарантия; есть законные причины для этого, но, эй, их обычно меньше, чем глупых). Кроме того, детали вашей сети интересны только вам.
Но в результате любой клиент, который хочет дойти до 10.0.1.2
в первую очередь должен иметь представление о том, как добраться до 10.0.1.0/24, и, кроме того, это должно быть правильное представление.
Исправьте таблицы маршрутизации на своих клиентах в соответствии с геометрией вашей сети, и все должно улучшиться.