iptables

Noob_with_cheats

Скриптер
Сообщения
41
Реакции
20
Баллы
8
При попытке разобраться с iptables, возникли проблемы с получением доступом к внешней сети из локалки.

Дано:
Имеется вычислительный узел (ВУ) №1, играющий роль межсетевого экрана (МЭ) (Далее ВУ МЭ), и ВУ №2 (Далее ВУ).
ВУ МЭ и ВУ находятся в локальной сети 1.1.1.0/24, ВУ МЭ также подключен к внешней сети 192.168.95.0/24
ВУ имеет адрес 1.1.1.91
ВУ МЭ имеет локальный адрес 1.1.1.95 и внешний 192.168.95.5
После настройки iptables, к ВУ можно пройти по 192.168.95.91
При этом с любого хоста подсети 192.168.95.0/24 можно получить доступ к ВУ МЭ и ВУ.
ВУ МЭ имеет доступ к ВУ по локальному ip и наоборот.

Проблема: Если подключиться напрямую к ВУ и сделать пинг к любому адресу 192.168.95.0/24, то ничего не получим.
Задача: Сделать возможность видеть сеть 192.168.95.0/24 из ВУ.
ip addr add 1.1.1.91/24 dev eth0
ip route add 192.168.95.0/24 via 1.1.1.95 dev eth0
ip link set eth0 up
ip addr add 1.1.1.95/24 dev eth0
ip link set eth0 up
ip addr add 192.168.95.5/24 dev eth2
ip addr add 192.168.95.91/24 dev eth2
ip link set eth2 up
Bash:
iptables -t nat -F PREROUTING
iptables -t nat -A PREROUTING -d 192.168.95.91 -j DNAT --to-destination 1.1.1.91


iptables -F FORWARD
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate NEW -d 1.1.1.91 -j ACCEPT
iptables -P FORWARD DROP

iptables -t nat -A POSTROUTING -d 1.1.1.91 -s 1.1.1.0/24 -j SNAT --to-source 1.1.1.95

iptables -t nat -A OUTPUT -d 192.168.95.91 -j DNAT --to-destination 1.1.1.91

iptables -F INPUT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT ! -i eth0 -j DROP

iptables -F OUTPUT
iptables -P OUTPUT ACCEPT
Bash:
 ### В PREROUTING осуществляется проброс к другим ВУ
        # Очистим цепочку PREROUTING
    iptables -t nat -F PREROUTING
    
        # Все пакеты, входящие в МЭ на 192.168.95.№ направляются на 1.1.1.9№.
        # Тут меняется адрес назначения пакета из внешнего на локальный
    iptables -t nat -A PREROUTING -d 192.168.95.№ -j DNAT --to-destination 1.1.1.9№

        ### FORWARD - цепочки, если узел другой
        # Очистим цепочку FORWARD
    iptables -F FORWARD

        # Разрешаем пакетам проходить по уже установленным соединениям
    iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

        # Разрешаем входящие соединения к 1.1.1.9№
    iptables -A FORWARD -m conntrack --ctstate NEW -d 1.1.1.9№ -j ACCEPT

        # Запрещаем весь остальной транзитный трафик
    iptables -P FORWARD DROP

        ### В POSTROUTING осуществляется отправка пакетов из других узлов

        # Пакет, предназначенный для 1.1.1.9№ будет проходить через шлюз 1.1.1.95
        # Таким образом, соединения из локальной сети будут выглядеть как соединения, инициированные шлюзом,
        # а соединения из внешней сети будут иметь свои оригинальные адреса.
    iptables -t nat -A POSTROUTING -d 1.1.1.9№ -s 1.1.1.0/24 -j SNAT --to-source 1.1.1.95

        ### OUTPUT — через эту цепочку проходят пакеты, сгенерированные процессами самого хоста.
        ### На данном этапе при необходимости можно повторить операции проброса,
        ### так локально сгенерированные пакеты не проходят цепочку PREROUTING

        # Все пакеты, исходящие из МЭ в 192.168.95.№ направляются на 1.1.1.9№
    iptables -t nat -A OUTPUT -d 192.168.95.№ -j DNAT --to-destination 1.1.1.9№

        ### Разрешаем исходящие и входящие сообщения к 192.168.95.№
    
        # Очистим цепочку INPUT
    iptables -F INPUT

        # Разрешаем входящие пакеты по уже установленным соединениям
    iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

        # Запрещаем остальные входящие пакеты
        # В т.ч. локальные. eth1 для пакетов м/у локальными
    iptables -P INPUT DROP
        # если хотите разрешить для eth0, тогда нужно заменить на
    iptables -A INPUT ! -i eth0 -j DROP

        # Очистим цепочку OUTPUT
    iptables -F OUTPUT

        # Разрешаем исходящие пакеты
    iptables -P OUTPUT ACCEPT
 
Код:
ip route add 192.168.95.0/24 via 1.1.1.95 dev eth0

Вы либо ходите через NAT, либо используете маршрутизацию. Одновременно настроить трансляцию сетевых адресов и промаршрутизировать одну и ту же сеть не получится..

Вам эту строку нужно заменить на:

Код:
ip route add default via 1.1.1.95

Вы говорите, что ВЕСЬ трафик не из подсети 1.1.1.0/24 отправлять на внутренний интерфейс вашего МЭ, а дальше он уже сам там будет его перебрасывать куда нужно.

Все будет работать и без NAT... Пинги до 192.168.95.5 и 192.168.95.91 должны проходить.. Затем можете на МЭ добавлять правила для NAT и смотреть правильность их работы: iptables -nvL

Код:
# Нужно включить возможность перенаправления IP пакетов между интерфейсами в ядре
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
reboot

# Добавляем правила IPTABLES на МЭ
sudo iptables -t nat -F
sudo iptables -t nat -A POSTROUTING -o eth2 -s 1.1.1.0/24 -j SNAT --to-source 192.168.95.91
sudo iptables -A FORWARD -i eth0 -o eth2 -s 1.1.1.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth2 -o eth0 -d 1.1.1.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT

Все должно работать. Но вам лучше добавить третий "компьютер" ВНЕШНИЙ_УЗЕЛв сети 192.168.95.0/24. Чтобы его сетевые интерфейсы не принадлежали МЭ и вы могли наблюдать прохождение трафика в трех точках: ВУ -> МЭ -> ВНЕШНИЙ_УЗЕЛ.
 
Последнее редактирование:
Код:
ip route add 192.168.95.0/24 via 1.1.1.95 dev eth0

Вы либо ходите через NAT, либо используете маршрутизацию. Одновременно настроить трансляцию сетевых адресов и промаршрутизировать одну и ту же сеть не получится..

Вам эту строку нужно заменить на:

Код:
ip route add default via 1.1.1.95

Вы говорите, что ВЕСЬ трафик не из подсети 1.1.1.0/24 отправлять на внутренний интерфейс вашего МЭ, а дальше он уже сам там будет его перебрасывать куда нужно.

Все будет работать и без NAT... Пинги до 192.168.95.5 и 192.168.95.91 должны проходить.. Затем можете на МЭ добавлять правила для NAT и смотреть правильность их работы: iptables -nvL

Код:
# Нужно включить возможность перенаправления IP пакетов между интерфейсами в ядре
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
reboot

# Добавляем правила IPTABLES на МЭ
sudo iptables -t nat -F
sudo iptables -t nat -A POSTROUTING -o eth2 -s 1.1.1.0/24 -j SNAT --to-source 192.168.95.91
sudo iptables -A FORWARD -i eth0 -o eth2 -s 1.1.1.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth2 -o eth0 -d 1.1.1.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT

Все должно работать. Но вам лучше добавить третий "компьютер" ВНЕШНИЙ_УЗЕЛв сети 192.168.95.0/24. Чтобы его сетевые интерфейсы не принадлежали МЭ и вы могли наблюдать прохождение трафика в трех точках: ВУ -> МЭ -> ВНЕШНИЙ_УЗЕЛ.
Попробую, но мне стоит уточнить, что в локальной сети будут подключаться и другие ВУ, которые будут иметь свой внешни ip адрес. В целом, у меня будет 4 ВУ, 1 МЭ, и кластер из 5 ВУ.
По данному примеру, у вас всё с порта будет идти на 95.91.
 
Попробую, но мне стоит уточнить, что в локальной сети будут подключаться и другие ВУ, которые будут иметь свой внешни ip адрес. В целом, у меня будет 4 ВУ, 1 МЭ, и кластер из 5 ВУ.
По данному примеру, у вас всё с порта будет идти на 95.91.
Да, вот тут:
Код:
sudo iptables -t nat -A POSTROUTING -o eth2 -s 1.1.1.0/24 -j SNAT --to-source 192.168.95.91

1.1.1.0/24 - это диаппазон который будет "маскироваться" за 192.168.95.91. Если поймете базовый принцип трансляции, в дальнейшем можно создать 5 внешний IP адресов на интерфейсе eth2 - с 192.168.95.91 по 192.168.95.95. И настроить 5 правил трансляции не для 1.1.1.0/24, а для конкретных 1.1.1.х сопоставив их конкретным IP адресам внешнего интерфейса eth2.

NAT придумали для экономии адресного пространства IPv4, поэтому здесь принцип "спрятать" большую внутреннюю сеть за 1 внешним IP, тем самым экономя "белые" IP адреса.

В ядре, любой ОС, есть просто массив буферов (mbufs aka my_array[1024]), в которых сохраняются параметры сессии трансляции:
IP_SOURCE:PORT (8+2 байта) -> IP_MASQ:PORT (8+2 байта)

Вы подключаетесь к яндесу через МЭ, на вашем компьютере открывается локальный порт 1.1.1.5:30000, поскольку адрес назначение не из вашей сети по заданному правилу маршрутизации:
Код:
ip route add default via 1.1.1.95
он попадет на внутренний интерфейс вашего МЭ, который запишет в mbuf данные об источники пакета: 1.1.1.5:30000 -> затем iptables в очереди NAT подменит исходящий адрес на 192.168.95.91, сгенерирует (откроет) локальный порт, например, тоже 192.168.95.91:30000, сохранит в mbuf вторую пару, получится что-то вроде: 1.1.1.5:30000 + 192.168.95.91:30000 и отправит ваш пакет с внешнего интерфейса eth2 (192.168.95.91:30000) -> яндексу.

Яндекс ответит на 192.168.95.91:30000, iptables найдет в mbuf элемент 1.1.1.5:30000 + 192.168.95.91:30000 и перенаправит полученный пакет на 1.1.1.5:30000. Это на пальцах.

Разница между маршрутизацией и трансляцией в "подмене" исходящего IP адреса после прохождения МЭ. Если вы не выходите в "белую" (глобальную) сеть - смысла в трансляции нет - достаточно правильно настроить правила маршрутизации. И вы получите тот же результат (связность сети) - значительно более производительную, нежели бы вы использовали трансляцию. Поскольку для последней нужно много телодвижений и ресурсов МЭ.
 
Последнее редактирование:
Да, вот тут:
Код:
sudo iptables -t nat -A POSTROUTING -o eth2 -s 1.1.1.0/24 -j SNAT --to-source 192.168.95.91

1.1.1.0/24 - это диаппазон который будет "маскироваться" за 192.168.95.91. Если поймете базовый принцип трансляции, в дальнейшем можно создать 5 внешний IP адресов на интерфейсе eth2 - с 192.168.95.91 по 192.168.95.95. И настроить 5 правил трансляции не для 1.1.1.0/24, а для конкретных 1.1.1.х сопоставив их конкретным IP адресам внешнего интерфейса eth2.

NAT придумали для экономии адресного пространства IPv4, поэтому здесь принцип "спрятать" большую внутреннюю сеть за 1 внешним IP, тем самым экономя "белые" IP адреса.

В ядре, любой ОС, есть просто массив буферов (mbufs aka my_array[1024]), в которых сохраняются параметры сессии трансляции:
IP_SOURCE:PORT (8+2 байта) -> IP_MASQ:PORT (8+2 байта)

Вы подключаетесь к яндесу через МЭ, на вашем компьютере открывается локальный порт 1.1.1.5:30000, поскольку адрес назначение не из вашей сети по заданному правилу маршрутизации:
Код:
ip route add default via 1.1.1.95
он попадет на внутренний интерфейс вашего МЭ, который запишет в mbuf данные об источники пакета: 1.1.1.5:30000 -> затем iptables в очереди NAT подменит исходящий адрес на 192.168.95.91, сгенерирует (откроет) локальный порт, например, тоже 192.168.95.91:30000, сохранит в mbuf вторую пару, получится что-то вроде: 1.1.1.5:30000 + 192.168.95.91:30000 и отправит ваш пакет с внешнего интерфейса eth2 (192.168.95.91:30000) -> яндексу.

Яндекс ответит на 192.168.95.91:30000, iptables найдет в mbuf элемент 1.1.1.5:30000 + 192.168.95.91:30000 и перенаправит полученный пакет на 1.1.1.5:30000. Это на пальцах.

Разница между маршрутизацией и трансляцией в "подмене" исходящего IP адреса после прохождения МЭ. Если вы не выходите в "белую" (глобальную) сеть - смысла в трансляции нет - достаточно правильно настроить правила маршрутизации. И вы получите тот же результат (связность сети) - значительно более производительную, нежели бы вы использовали трансляцию. Поскольку для последней нужно много телодвижений и ресурсов МЭ.
Согласен с последним выводом. Это по большой степени для понимания работы iptables. По сути, у меня в будущем будет кластер из 9 ВУ с 1 МЭ.
 
Да, вот тут:
Код:
sudo iptables -t nat -A POSTROUTING -o eth2 -s 1.1.1.0/24 -j SNAT --to-source 192.168.95.91

1.1.1.0/24 - это диаппазон который будет "маскироваться" за 192.168.95.91. Если поймете базовый принцип трансляции, в дальнейшем можно создать 5 внешний IP адресов на интерфейсе eth2 - с 192.168.95.91 по 192.168.95.95. И настроить 5 правил трансляции не для 1.1.1.0/24, а для конкретных 1.1.1.х сопоставив их конкретным IP адресам внешнего интерфейса eth2.

NAT придумали для экономии адресного пространства IPv4, поэтому здесь принцип "спрятать" большую внутреннюю сеть за 1 внешним IP, тем самым экономя "белые" IP адреса.

В ядре, любой ОС, есть просто массив буферов (mbufs aka my_array[1024]), в которых сохраняются параметры сессии трансляции:
IP_SOURCE:PORT (8+2 байта) -> IP_MASQ:PORT (8+2 байта)

Вы подключаетесь к яндесу через МЭ, на вашем компьютере открывается локальный порт 1.1.1.5:30000, поскольку адрес назначение не из вашей сети по заданному правилу маршрутизации:
Код:
ip route add default via 1.1.1.95
он попадет на внутренний интерфейс вашего МЭ, который запишет в mbuf данные об источники пакета: 1.1.1.5:30000 -> затем iptables в очереди NAT подменит исходящий адрес на 192.168.95.91, сгенерирует (откроет) локальный порт, например, тоже 192.168.95.91:30000, сохранит в mbuf вторую пару, получится что-то вроде: 1.1.1.5:30000 + 192.168.95.91:30000 и отправит ваш пакет с внешнего интерфейса eth2 (192.168.95.91:30000) -> яндексу.

Яндекс ответит на 192.168.95.91:30000, iptables найдет в mbuf элемент 1.1.1.5:30000 + 192.168.95.91:30000 и перенаправит полученный пакет на 1.1.1.5:30000. Это на пальцах.

Разница между маршрутизацией и трансляцией в "подмене" исходящего IP адреса после прохождения МЭ. Если вы не выходите в "белую" (глобальную) сеть - смысла в трансляции нет - достаточно правильно настроить правила маршрутизации. И вы получите тот же результат (связность сети) - значительно более производительную, нежели бы вы использовали трансляцию. Поскольку для последней нужно много телодвижений и ресурсов МЭ.
Да, работает. Но надо будет решить проблему, если ВУ отправляет пакет на 95.5. В изначальной моей конфигурации это работало. Как понимаю, МЭ отправляет ответ на 1.91, а не на 95.91. ну это решаемо.
Сообщение автоматически объединено:

хорошо, я немного не внимательный. Сделал не тот ip адрес у МЭ. Всё с ВУ нормально видет. Осталось сделать, что при 95.91 мы работаем с 1.91, а не .95. В целом, принцип объяснил, спасибо. Дальше уже тема про кластер с MPI)
 
Последнее редактирование:
Дальше уже тема про кластер с MPI)
Сети и MPI надо делать на FreeBSD (там есть ядерный ipfw + mpich, который со времен христа поддерживается). Все эти бубунты и прочий около Linux-овский софт не рассчитаны на серьезные нагрузки, пользуется популярностью только из-за низкого квалификационного порога вхождения "в тему".
 

Кто просматривает тему

Назад
Верх