NAT не работает...

Аватар пользователя vic

стянул где-то примерчик, вот его кусок.

# Таблица NAT
$IPTABLES -t nat -F PREROUTING
$IPTABLES -t nat -F POSTROUTING
$IPTABLES -t nat -A POSTROUTING -p tcp -s $LAN --dport 110 -j SNAT --to-source $INET
$IPTABLES -t nat -A POSTROUTING -p icmp -s $ADM_IP -j SNAT --to-source $INET

фаервол то работает, да только вот NAT.... Грустный
помогите плиз незнающему. :-?

Аватар пользователя sergeil

Re: NAT не работает...

NAT требует разрешенного FORWARD.

1. Глобального включения.
2. Разрешение для адресов, которые нужно маскарадить...

то есть, я-бы добавил:
$IPTABLES -I FORWARD 1 -p tcp -s $LAN -d ! $LAN --dport 110 -j ACCEPT
$IPTABLES -I FORWARD 1 -p icmp -s $ADM_IP -d ! $LAN -j ACCEPT

Аватар пользователя vic

Re: всеравно NAT не работает...

у меня уже были следующие строки

$IPTABLES -A FORWARD -p tcp --dport 110 -s $LAN -j ACCEPT
$IPTABLES -A FORWARD -p tcp --sport 110 -d $LAN -j ACCEPT

$IPTABLES -A FORWARD -p icmp -s $ADM_IP -d 0/0 -j ACCEPT
$IPTABLES -A FORWARD -p icmp -s 0/0 -d $ADM_IP -j ACCEPT

echo 1 > /proc/sys/net/ipv4/ip_forward

но ни этот вариант ни ваш не работают... Грустный

Аватар пользователя sergeil

Re: всеравно NAT не работает...

попробуйте для начала простую схему
$IPTABLES -I FORWARD 1 -s $LAN -d ! $LAN -j ACCEPT
$IPTABLES -t nat -I POSTROUTING -s $LAN -d ! $LAN -j MASQUERADE

Аватар пользователя vic

Re: всеравно NAT не работает...

вот полный листинг

#-------------------------------------------------------------------------------------------------
#!/bin/sh
#
IPTABLES="/sbin/iptables"
INET="#.#.#.#"
LAN="#.#.#.0/24"
ADM_IP="#.#.#.#/32"
IF_LAN="eth1"
IF_INET="eth0"
LOCAL_AREA="#.#.#.0/24"
#------------------------------------------------------------------------------------------------
#
$IPTABLES -F INPUT
$IPTABLES -F FORWARD
$IPTABLES -F OUTPUT
#
$IPTABLES -F bad_tcp_packets
$IPTABLES -F icmp_packets
$IPTABLES -N bad_tcp_packets
$IPTABLES -N icmp_packets
#
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP
#
####################################################
# Отфильтровываем плохие пакеты
$IPTABLES -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "Bad"
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP
$IPTABLES -A bad_tcp_packets -i $IF_INET -s $LOCAL_AREA -j LOG --log-prefix "local-ip_in_eth1"
$IPTABLES -A bad_tcp_packets -o $IF_INET -d $LOCAL_AREA -j LOG --log-prefix "local-ip_in_eth1"
$IPTABLES -A bad_tcp_packets -i $IF_INET -s $LOCAL_AREA -j DROP
$IPTABLES -A bad_tcp_packets -o $IF_INET -d $LOCAL_AREA -j DROP
#
$IPTABLES -A INPUT -p tcp -j bad_tcp_packets
$IPTABLES -A FORWARD -p tcp -j bad_tcp_packets
$IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets
#
# Проверка ICMP пакетов
$IPTABLES -A icmp_packets -p icmp --icmp-type 0 -j ACCEPT # Если кто хочет чтобы этот сервер
$IPTABLES -A icmp_packets -p icmp --icmp-type 3 -j ACCEPT # могли пинговать, нужно
$IPTABLES -A icmp_packets -p icmp --icmp-type 5 -j ACCEPT # откоментировать эти три строки
$IPTABLES -A icmp_packets -p icmp --icmp-type 8 -j ACCEPT
$IPTABLES -A icmp_packets -p icmp --icmp-type 11 -j ACCEPT
$IPTABLES -A icmp_packets -p icmp -j DROP
$IPTABLES -A INPUT -p icmp -j icmp_packets
$IPTABLES -A OUTPUT -p icmp -j icmp_packets
#
# Цепочка INPUT
$IPTABLES -A INPUT -p tcp --dport 22 -s $ADM_IP -i $IF_LAN -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 25 -j ACCEPT # Эти четыре порта
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT # необходимо разрешить
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT # всем что бы обеспечить
$IPTABLES -A INPUT -p tcp --dport 80 -j ACCEPT # прохождение почты, ДНС, и ВЕБ
$IPTABLES -A INPUT -p tcp --dport 110 -s 127.0.0.1/32 -d 127.0.0.1/32 -i lo -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 110 -s $LAN -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 139 -s $LAN -j ACCEPT # Порты 139,445 - tcp и 137 - udp
$IPTABLES -A INPUT -p udp --dport 137 -s $LAN -j ACCEPT # нужны для работы
$IPTABLES -A INPUT -p tcp --dport 445 -s $LAN -j ACCEPT # сервиса SAMBA
$IPTABLES -A INPUT -p tcp --dport 3128 -s $LAN -j ACCEPT
# Разрешаем уже установленные соединения
$IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
#
# Цепочка OUTPUT
$IPTABLES -A OUTPUT -p tcp --sport 22 -d $ADM_IP -o $IF_LAN -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 25 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 110 -d 127.0.0.1/32 -s 127.0.0.1/32 -o lo -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 110 -d $LAN -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 139 -d $LAN -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 137 -d $LAN -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 445 -d $LAN -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 3128 -d $LAN -j ACCEPT
#
# Разрешаем хорошие исходящие пакеты
# В этом правиле небольшое различие с правилами в цепочке INPUT
# в виду того что серверу надо разрешить устанавливать и новые соединения
# кроме уже существующих
$IPTABLES -A OUTPUT -m state ! --state INVALID -j ACCEPT
#
# Цепочка FORWARD
$IPTABLES -I FORWARD 1 -s $LAN -d ! $LAN -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward
#
# Таблица NAT
$IPTABLES -t nat -F PREROUTING
$IPTABLES -t nat -F POSTROUTING
$IPTABLES -t nat -I POSTROUTING -s $LAN -d ! $LAN -j MASQUERADE

Аватар пользователя sergeil

Re: всеравно NAT не работает...

Ваш firewall написан в идеологии ipchains. Вы не используете всей мощности iptables

Вы не можете видеть что у Вас отбрасывается. Я-бы рекомендовал последнимы строками прописать

iptables -A INPUT     -j LOG --log-level info --log-prefix "INT_DEF:"
iptables -A OUTPUT -j LOG --log-level info --log-prefix "OUT_DEF:"
iptables -A FORWARD -j LOG --log-level info --log-prefix "FWD_DEF:"
Аватар пользователя DRVTiny

Re: NAT не работает...

vic, а не могли Вы хотя бы пояснить, что за конфигурация у Вашего щлюза. Дело в том, что в принципе оснащённость шлюза может варьироваться в широких пределах, а мне как человеку, пока ещё не очень понимающему внутреннюю структуру TCP/IP, понять, что за глубокий смысл заложен, например, в этом вот императиве: $IPTABLES -A INPUT -p tcp --dport 110 -s 127.0.0.1/32 -d 127.0.0.1/32 -i lo -j ACCEPT, достаточно проблематично.

В общем, хотелось бы, чтобы vic или кто-нибудь ещё из просвещённых товарищей прокомментировал следующие непонятные мне (а возможно - и автору топика) строки:

ADM_IP="#.#.#.#/32" 

Это что - IP-адрес шлюза? А зачем маску в 32 бита надо было указывать?
Вообще для ассоциативной связи с "внешним" и "внутренним" IP-адресами шлюза я предпочитаю использовать имена переменных наподобие gw_intIP, gw_extIP (с префиксами ext и int), хотя, безусловно, это дело вкуса... но и лишних сущностей при задании имён переменных тоже лучше не порождать, так что определение intIF="eth1"; extIF="eth0"; gw_intIP="192.168.1.1"; gw_extIP="192.83.62.17" кажется мне более рациональным. Вообще, многие переменные, использованные в листинге vic'а, кажутся мне загадочными. Чем, например,отличается LAN от LOCAL_AREA? И что это за переменная INET? Положим, это внешний адрес сервера, тогда возвращаемся в тому, с чего начали: что такое ADM_IP?!

$IPTABLES -F INPUT
$IPTABLES -F FORWARD
$IPTABLES -F OUTPUT
#
$IPTABLES -F bad_tcp_packets
$IPTABLES -F icmp_packets

А нельзя было вместо всего этого просто $IPTABLES -F написать? Кстати, а зачем было местоположение iptables в одноимённой переменной хранить? Неужели этот бинарник был запрятан так далеко, что его из $PATH стало не видать? Нет, я не призываю писать напрямую iptables (хотя бы из-за того, что сценарий работает быстрее, если iptables вызывается по полному путевому имени), но зачем же себе жизнь усложнять, если можно её, наоборот, за счёт использования короткого имени переменной упростить: $ipf или $ipt ?

$IPTABLES -A INPUT -p tcp --dport 22 -s $ADM_IP -i $IF_LAN -j ACCEPT

Гм, так что же такое этот ADM_IP? В этой сети ещё и демиллитаризованная зона есть или я чего-то недопонимаю?

$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT

А если шлюз не является DNS-сервером по совместительству (первичный и вторичный DNS-сервера находятся во внешней сети)? Да и зачем, собственно, в маленькой сети может понадобиться DNS-сервер, если и DHCP для комфортного администрирования вполне достаточно? Другое дело, если в локалке создана инфраструктура Интранет, или используются внутренние адреса, начинающиеся не на 192.168 (24 бита в маске), а на 172.16 (16-ти битовая маска) но... это определённо не мой случай. А кешировать DNS-запросы умеет и SQUID, и MiddleMan, и вообще любой основанный на SQUID прокси.

$IPTABLES -A INPUT -p tcp --dport 25 -j ACCEPT # Эти четыре порта
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT # необходимо разрешить
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT # всем что бы обеспечить
$IPTABLES -A INPUT -p tcp --dport 80 -j ACCEPT

OK, положим, у меня на шлюзе веб-сервер работает исключительно через loopback (для внутренних нужд), почтового сервера нет (предпочитаю не взваливать на себя ответственность абсолютно за всё и, воплощая принцип разделения администраторского труда на практике, предпочитаю пользоваться бесплатными услугами внешнего почтового сервера), домен я у себя не поднимал. Так значит мне эти 4 правила вовсе не нужны, я правильно понял?

$IPTABLES -A INPUT -p tcp --dport 110 -s 127.0.0.1/32 -d 127.0.0.1/32 -i lo -j ACCEPT

Это что и зачем? Без комментариев, поскольку не могу строить даже догадки на сей счёт. Я в полном замешательстве...

$IPTABLES -A OUTPUT -p tcp --sport 139 -d $LAN -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 137 -d $LAN -j ACCEPT

Samba на шлюзе? А какой от этого может быть прок. Нет, ну я понимаю, открывать порты 137 и 139 на файловом сервере (да и то-только адресов в локальной сети), но чтоб на шлюзе... (???)Зачем шлюзу протокол NetBIOS?

# Разрешаем уже установленные соединения
$IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

А зачкм тогда вообще цепочка bad_tcp_packets была нужна? Получается ведь какое-то масло масляное, и совершенно лишнее, на мой взгляд, правило добавляется.

# Цепочка FORWARD
$IPTABLES -I FORWARD 1 -s $LAN -d ! $LAN -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward

Для шлюза цепочка FORWARD - самая что ни на есть наиглавнейшая, а vic в неё всего одно правило добавил, да и то какое-то странное (локальный трафик итак через шлюз идти ну никак не должен).

Аватар пользователя sergeil

Re: NAT не работает...

Цитата:
DRVTiny писал:
что за глубокий смысл заложен, например, в этом вот императиве: $IPTABLES -A INPUT -p tcp --dport 110 -s 127.0.0.1/32 -d 127.0.0.1/32 -i lo -j ACCEPT, достаточно проблематично.

Ну, это действительно очень своеобразное выражение, поскольку оно разрешает принимать от IP=127.0.0.1 интерфейса lo пакеты на IP=127.0.0.1 по сервису POP3
То, что сервис сможет ответить, в данном выражении не оговаривается...

Цитата:

ADM_IP="#.#.#.#/32" 

Это что - IP-адрес шлюза? А зачем маску в 32 бита надо было указывать?

Насколько я понял, это машина администратора. Подсеть /32 - это один хост...

Цитата:

$IPTABLES -F INPUT
$IPTABLES -F FORWARD
$IPTABLES -F OUTPUT
#
$IPTABLES -F bad_tcp_packets
$IPTABLES -F icmp_packets

А нельзя было вместо всего этого просто $IPTABLES -F написать?

Если уж быть таким придирчивым, то есть еще более эффективное средство. Мало того, что оно очищает все правила, так еще и удаляет пользовательские цепочки.
root# service iptables stop

Цитата:
Кстати, а зачем было местоположение iptables в одноимённой переменной хранить? Неужели этот бинарник был запрятан так далеко, что его из $PATH стало не видать? Нет, я не призываю писать напрямую iptables (хотя бы из-за того, что сценарий работает быстрее, если iptables вызывается по полному путевому имени), но зачем же себе жизнь усложнять, если можно её, наоборот, за счёт использования короткого имени переменной упростить: $ipf или $ipt ?

Иногда сценарии выполняются в неопределенной среде окружения. И тогда нужно или определять эту среду или указывать полный путь. Как по мне, то очень правильное решение...

Цитата:

$IPTABLES -A INPUT -p tcp --dport 22 -s $ADM_IP -i $IF_LAN -j ACCEPT

Гм, так что же такое этот ADM_IP? В этой сети ещё и демиллитаризованная зона есть или я чего-то недопонимаю?

С админовской машины локальной сети можно админить этот рутер...

Цитата:

$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT

А если шлюз не является DNS-сервером по совместительству (первичный и вторичный DNS-сервера находятся во внешней сети)? Да и зачем, собственно, в маленькой сети может понадобиться DNS-сервер, если и DHCP для комфортного администрирования вполне достаточно?

Обычная практика провайдеров - первичный DNS у клиента, а вторичный - у него.
Конечно, желательно разместить у провайдера и первичный и вторичный сервер DNS (только публичные имена). В локальный сети можно поднять кэширующий DNS, который можно совместить с сервером имен для локальных адресов. Особенно полезно, если есть WAN. Тогда локальный DNS можно настроить как вторичный для удаленных сайтов. Или организовать forward.

Цитата:
А кешировать DNS-запросы умеет и SQUID, и MiddleMan, и вообще любой основанный на SQUID прокси.

А почтовая система? А еще очень часто возникает желание отвязаться он DNS провайдера. Особенно если DNS недостаточно надежный.

Цитата:

$IPTABLES -A INPUT -p tcp --dport 25 -j ACCEPT # Эти четыре порта
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT # необходимо разрешить
$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT # всем что бы обеспечить
$IPTABLES -A INPUT -p tcp --dport 80 -j ACCEPT

OK, положим, у меня на шлюзе веб-сервер работает исключительно через loopback (для внутренних нужд), почтового сервера нет (предпочитаю не взваливать на себя ответственность абсолютно за всё и, воплощая принцип разделения администраторского труда на практике, предпочитаю пользоваться бесплатными услугами внешнего почтового сервера), домен я у себя не поднимал. Так значит мне эти 4 правила вовсе не нужны, я правильно понял?

Нет. Если у Вас нет публичных сервисов, то и соответствующие службы Вам предоставлять не следует.

Цитата:

$IPTABLES -A INPUT -p tcp --dport 110 -s 127.0.0.1/32 -d 127.0.0.1/32 -i lo -j ACCEPT

Это что и зачем? Без комментариев, поскольку не могу строить даже догадки на сей счёт. Я в полном замешательстве...

Ну, это типа, я могу с рутера почтовым клиетом сам у себя просить почту (110/tcp == POP3). Но если нет правила, покрывающего
$IPTABLES -A INPUT -p tcp --sport 110 -s 127.0.0.1/32 -d 127.0.0.1/32 -i lo -j ACCEPT
то почту мне не отдадут, поскольку не разрешено Улыбка

Цитата:

$IPTABLES -A OUTPUT -p tcp --sport 139 -d $LAN -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 137 -d $LAN -j ACCEPT

Samba на шлюзе? А какой от этого может быть прок. Нет, ну я понимаю, открывать порты 137 и 139 на файловом сервере (да и то-только адресов в локальной сети), но чтоб на шлюзе... (???)Зачем шлюзу протокол NetBIOS?

Шлюз - понятие растяжимое. Он может быть совмещен с файловой помойкой.

Цитата:

# Разрешаем уже установленные соединения
$IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

А зачкм тогда вообще цепочка bad_tcp_packets была нужна? Получается ведь какое-то масло масляное, и совершенно лишнее, на мой взгляд, правило добавляется.

Ну почему? Эта проверка может отсечь некоторые виды сканирования...
Обычно tcp в состоянии NEW, но без SYN - это аномалия. Но если у Вас
цепочка firewall, то очень даже обычное явление после перезагрузки одного их них.

Цитата:

# Цепочка FORWARD
$IPTABLES -I FORWARD 1 -s $LAN -d ! $LAN -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward

Для шлюза цепочка FORWARD - самая что ни на есть наиглавнейшая, а vic в неё всего одно правило добавил, да и то какое-то странное (локальный трафик итак через шлюз идти ну никак не должен).

По поводу FORWARD на шлюзе - вопрос спорный. Шлюз приложения (PROXY) не требует пересылки пакетов. Так что, если нет маскарада и WAN, то FORWARD лучше отключить.

Аватар пользователя vic

Re: одно вот неясно...

как мне, млин, NAT организовать?????? Грустный
зы. настройки я стянул с гдето в инете, так что не судите строго (я ведь и сам в них не все понял Улыбка )

Аватар пользователя sergeil

Re: одно вот неясно...

Цитата:
vic писал:
как мне, млин, NAT организовать?????? Грустный
зы. настройки я стянул с гдето в инете, так что не судите строго (я ведь и сам в них не все понял Улыбка )

Попробуйте сначала сделать максимально просто. Позже усложните схему.

# lo, внутренний интерфейс должен быть доступен
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# LAN может делать что хочет
iptables -A INPUT -i $lanIF -j ACCEPT
iptables -A OUTPUT -o $lanIF -j ACCEPT

# С рутера можно идти в интернет, с INET на рутер нельзя.
iptables -A OUTPUT -o $inetIF -j ACCEPT
iptables -A INPUT -i $inetIF -m state --state ESTABLISHED,RELATED -j ACCEPT

# С LAN можно идти в интернет, с INET в LAN нельзя.
iptables -A FORWARD -i $lanIF -o $inetIF -j ACCEPT
iptables -A FORWARD -i $inetIF -o $lanIF -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s $LAN -o $inetIF -j MASQUERADE

# Все, что будет отброшено - протоколируем.
iptables -A FORWARD -j LOG --log-level info --log-prefix "def_fwd:"
iptables -A INPUT -j LOG --log-level info --log-prefix "def_inp:"
iptables -A OUTPUT -j LOG --log-level info --log-prefix "def_out:"

# Все остальнок отбрасываем.
iptables -A FORWARD -j DROP
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP

Аватар пользователя vic

Re: спасибо ...

... но я уже настроил почтовый сервер (не sendmail конечно Улыбка ). ведь NAT мне нужен был только для почты...

Аватар пользователя sergeil

Re: спасибо ...

Цитата:
vic писал:
... но я уже настроил почтовый сервер (не sendmail конечно Улыбка ). ведь NAT мне нужен был только для почты...

Так у Вас работает NAT, хоть какой-то, или нет?
Улыбка

Вы получите хоть какой-то результат, а дальше адапритуетесь под свою схему. Пусть даже методом проб и ошибок.

Классические схемы, которые Вам были предложены, у Вас не работают. А почему? Они не могут не работать. Чем Ваша система такая особенная?

Единственное подозрение, которое закрадывается: Ваша система младше, чем 10-а, ядро с ftp.kernel.org, а iptables - из дистрибутива, патченый. В этой комбинации NAT действительно не работает.

RSS-материал