Настройка роутера на CentOS 6.0

[RXL]

Слав, первым делом стоит оглядеть список процессов, для оценки, что тут поназапущенно. Я использую "ps aux -H" - тут вся нужная информация есть. Потом посмотреть сетевые службы: "netstat -lnp" (все) или "netstat -tlnp" (только tcp). Потом протестировать вход по ssh и просмотреть правила iptables.

[Kivals]

Если у меня внешний и внутрений порты отличаются - будет ли корректным такой скрипт для форвардинга (разные внешние порты на одинаковые порты разных машин внутри сети)?

Код: (Bash)

INET_IP=1.2.3.4
INET_PORT1=8181
INET_PORT2=8182
LOCAL_IP1=192.168.0.111
LOCAL_PORT1=80
LOCAL_IP2=192.168.0.222
LOCAL_PORT2=80
LOCAL_NET=192.168.0.0/24

iptables -t nat -A PREROUTING -i eth0 -d $INET_IP -p tcp --dport $INET_PORT1 -j DNAT --to-destination $LOCAL_IP1:$LOCAL_PORT1
iptables -t nat -A PREROUTING -i eth0 -d $INET_IP -p tcp --dport $INET_PORT2 -j DNAT --to-destination $LOCAL_IP2:$LOCAL_PORT2
iptables -t nat -A POSTOUTING -o eth0 -s $LOCAL_NET -j MASQUERADE

[Kivals]

Собственно вопрос вызывает последняя строка - не будет ли в ней конфликтов?

[RXL]

Синтаксис соответствует. Собственно, он описан в man iptables.

Правила выполняются последовательно: если часть "match" срабатывает, выполняется часть "target". Одни цели терминирующие, другие - нет. Наиболее часто используемые - DNAT, SNAT, MASQUERADE, ACCEPT, DROP, REJECT - терминирующие. Т.ч. если одно терминирующее правило сработало, то никакие больше не проверяются.

Кстати, таблица nat особенная: после того, как первый (инициирующий) пакет из взаимосвязанной цепочки проходит его, в специальной структуре ядра - connection tracking - создается запись и остальные пакеты уже по таблице не проверяются. Если интересно, посмотри /proc/net/ip_conntrack.

[Kivals]

И все-таки не так это для меня просто - не работает форвардинг
Настройки в iptables добавил:

[root@router ~]# iptables-save
# Generated by iptables-save v1.4.7 on Fri Nov  4 10:11:08 2011
*nat
:PREROUTING ACCEPT [242:67518]
:POSTROUTING ACCEPT [1098:66384]
:OUTPUT ACCEPT [1100:66528]
-A PREROUTING -s XX.XX.XX.81/32 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.30.30
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.30.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Fri Nov  4 10:11:08 2011
# Generated by iptables-save v1.4.7 on Fri Nov  4 10:11:08 2011
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1930:185414]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s XX.XX.XX.81/32 -p tcp -m state --state NEW -m tcp --dport 3389 -j ACCEPT
-A INPUT -s XX.XX.XX.81/32 -p udp -m state --state NEW -m udp --dport 3389 -j ACCEPT
-A INPUT -s 192.168.30.0/24 -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
-A INPUT -s 192.168.30.0/24 -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Fri Nov  4 10:11:08 2011

Порт на внутренней машине открыт:

[root@router ~]# nmap -sT -O 192.168.30.30                                     
Starting Nmap 5.21 ( http://nmap.org ) at 2011-11-04 10:11 EET
Nmap scan report for 192.168.30.30
Host is up (0.00023s latency).
Not shown: 995 closed ports
PORT     STATE SERVICE
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
1026/tcp open  LSA-or-nterm
3389/tcp open  ms-term-serv
MAC Address: 00:0C:29:9B:E8:6E (VMware)
Device type: general purpose
Running: Microsoft Windows 2003
OS details: Microsoft Windows Server 2003 SP1 or SP2
Network Distance: 1 hop

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.14 seconds

Настройки форвардинга вроде сделаны:

[root@router ~]# cat /etc/sysctl.conf | grep -i "forward"
# Controls IP packet forwarding
net.ipv4.ip_forward = 1
[root@router ~]# cat /etc/sysconfig/network
NETWORKING=yes
GATEWAY=XX.XX.XX.1
FORWARDING=yes
HOSTNAME=router.localdomain

Обращение по порту идет:

[root@router ~]# tcpdump -i eth0 'tcp port 3389'                                tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:17:10.531281 IP home.volia.net.64263 > static-XX-XX-XX-81.washdc.fios.verizon.net.ms-wbt-server: Flags [S], seq 2090563426, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:17:13.536348 IP home.volia.net.64263 > static-XX-XX-XX-81.washdc.fios.verizon.net.ms-wbt-server: Flags [S], seq 2090563426, win 8192, options [mss 1460,nop,nop,sackOK], length 0
10:17:19.531851 IP home.volia.net.64263 > static-XX-XX-XX-81.washdc.fios.verizon.net.ms-wbt-server: Flags [S], seq 2090563426, win 8192, options [mss 1460,nop,nop,sackOK], length 0
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel

Чего еще не хватает?

Добавлено через 1 минуту и 42 секунды:
P.S. После переустановки OS на SL 6.1 "поменял местами" карточки - теперь как обычно в примерах: eth0 - мир, eth1 - внутренняя сеть

[Dimka]

Дурацкий вопрос, а на уровне ядра forwarding включен?

[RXL]

Код:

*nat
-A PREROUTING -s XX.XX.XX.81/32 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.30.30

У тебя написано правило для входящего соединения с определенного внешнего IP. Это верно? А то есть сомнения, что это ошибка.

Код:

*filter
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

Давай разберем, что тут у тебя делается.
Первое правило - для исходящих транзитных пакетов.
Второе - для входящих, отмеченных в connection tracking как "установленное соединение" или "зависимый" (например, соединения передачи данных в ftp).
Третье - отвергнуть все оставшееся, включая все инициируемые извне соединения.
Так и должно быть?

В итоге, первый кусок твоих правил не совместим со вторым куском.
Хотелось бы услышать задачу словесно.

Добавлено через 1 минуту и 45 секунд:

Дурацкий вопрос, а на уровне ядра forwarding включен?

Должон, Дим, должон. Там вон ниже iptables видно.

[Kivals]

Код:

*nat
-A PREROUTING -s XX.XX.XX.81/32 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.30.30

У тебя написано правило для входящего соединения с определенного внешнего IP. Это верно? А то есть сомнения, что это ошибка.

Это я уже пробовал варианты. Там стояло и -d XX.XX.XX.81

Код:

*filter
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

Давай разберем, что тут у тебя делается.
Первое правило - для исходящих транзитных пакетов.
Второе - для входящих, отмеченных в connection tracking как "установленное соединение" или "зависимый" (например, соединения передачи данных в ftp).
Третье - отвергнуть все оставшееся, включая все инициируемые извне соединения.
Так и должно быть?

В итоге, первый кусок твоих правил не совместим со вторым куском.
Хотелось бы услышать задачу словесно.

Код:

-A FORWARD -j REJECT --reject-with icmp-host-prohibited

Это было по умолчанию.
А 2 правила выше - это я добавлял чтобы работал, например, ping из внутренней сети. И он таки работает
https://forum.shelek.ru/index.php/topic,27823.msg270783.html#msg270783

Может я как-то некорректно открыл на вход порт? Возможно там тоже путаница с source-dest ?

Код:

-A INPUT -s XX.XX.XX.81/32 -p tcp -m state --state NEW -m tcp --dport 3389 -j ACCEPT

Хотя

Код:

-A INPUT -d XX.XX.XX.81/32 -p tcp -m state --state NEW -m tcp --dport 3389 -j ACCEPT

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


Добавлено через 35 минут и 15 секунд:
Ром, все верно - проблема оказалась в правиле запрета всего:

-A FORWARD -j REJECT --reject-with icmp-host-prohibited

Т.е. когда я его комментирую - все работает.
А теперь вопрос - как его оставить, но что при этом нужно добавить, чтобы работал проброс порта?

Добавлено через 3 минуты и 35 секунд:
Ром, еще вот на это что можешь посоветовать?

Еще вопрос: таких пробросов будет достаточно много (порядка 10-20). Хочу создать текстовый файл вида:

Код:

ExtIP	ExtPort	IntIP	IntPort

Из которого читать данные и скриптом при загрузке задавать нужные правил форвардинга.
Где (идеологически правильно) разместить этот скрипт и как настроить его вызов при загрузке / переинициализации iptables?

[RXL]

Порекомендую создать отдельную цепочку, куда добавлять разрешающие правила.
(пишу в формате iptables-save):

Код:

*filter
...
:fwd_eth0_eth1_new
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state NEW -j fwd_eth0_eth1_new
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fwd_eth0_eth1_new -d ... -p tcp -m tcp --dport 3389 -j ACCEPT

Это способ ветвления фильтра. Соотв., параметры, принятые при ответвлении, уже не нужно проверять внутри ветки.
Если ни одно правило цепочки fwd_eth0_eth1_new не сработает, сканирование вернется в точку ответвления. Для принудительного возврата в нужном правиле есть таржет RETURN.


Добавлено через 1 минуту и 46 секунд:

А 2 правила выше - это я добавлял чтобы работал, например, ping из внутренней сети. И он таки работает

Без этих двух правил - нет, т.к. третье все отвергает.

Добавлено через 2 минуты и 37 секунд:

Может я как-то некорректно открыл на вход порт? Возможно там тоже путаница с source-dest ?

Код:

-A INPUT -s XX.XX.XX.81/32 -p tcp -m state --state NEW -m tcp --dport 3389 -j ACCEPT

Хотя

Код:

-A INPUT -d XX.XX.XX.81/32 -p tcp -m state --state NEW -m tcp --dport 3389 -j ACCEPT

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

XX.XX.XX.81/32 - чей IP? Подключающегося клиента или твоего роутера?

[Kivals]

XX.XX.XX.81/32 - чей IP? Подключающегося клиента или твоего роутера?

Роутера. Мне нужно обеспечить подключение с любого клиента

-A fwd_eth0_eth1_new -d ... -p tcp -m tcp --dport 3389 -j ACCEPT

-d ... - это внешний IP?

Давай может через переменные, с учетом того, что порты отличаются:

Код:

$EXT_IP:$EXT_PORT -> $INT_IP:$INT_PORT

Сейчас у меня работает правило:

Код:

-A PREROUTING -d $EXT_IP -p tcp -m tcp --dport $EXT_PORT -j DNAT --to-destination $INT_IP:$INT_PORT

Как для этого случая записать правило обратного проброса ответа?

Код:

-A fwd_eth0_eth1_new -d $EXT_IP -p tcp -m tcp --dport $EXT_PORT -j ACCEPT

Добавлено через 23 минуты и 44 секунды:
А ветвление я могу использовать во всех таблицах?
В частности - могу ли я для NAT записать:

Код: (Bash)

* nat
...
-A PREROUTING -d XX.XX.XX.81 -p tcp -m tcp -j fwd_nat
-A fwd_nat --dport $EXT_PORT1 -j DNAT --to-destination $INT_IP1:$INT_PORT1
-A fwd_nat --dport $EXT_PORT2 -j DNAT --to-destination $INT_IP2:$INT_PORT2

[RXL]

Кстати, ICMP лучше разрешить - это все таки не сервис, а служебная информация.

Код:

-p icmp -m icmp --icmp-type any -j ACCEPT

Добавлено через 13 минут и 34 секунды:

А ветвление я могу использовать во всех таблицах?
В частности - могу ли я для NAT записать:

Код: (Bash)

* nat
...
-A PREROUTING -d XX.XX.XX.81 -p tcp -m tcp -j fwd_nat
-A fwd_nat --dport $EXT_PORT1 -j DNAT --to-destination $INT_IP1:$INT_PORT1
-A fwd_nat --dport $EXT_PORT2 -j DNAT --to-destination $INT_IP2:$INT_PORT2

Можешь, но иначе.
"-m" указывает использовать такой-то match-модуль. "--dport" - здесь, параметр модуля "tcp" и отдельно от него не работает. Если тебе нужно направить в цепочку fwd_nat только tcp-пакеты, то в правиле укажи "-p tcp".

Код:

-A PREROUTING -d XX.XX.XX.81 -p tcp -j fwd_nat
-A fwd_nat -m tcp --dport $EXT_PORT1 -j DNAT --to-destination $INT_IP1:$INT_PORT1
-A fwd_nat -m tcp --dport $EXT_PORT2 -j DNAT --to-destination $INT_IP2:$INT_PORT2

В каждой таблице свои цепочки и из имена не коррелируют.
В общем-то, man iptables дает вполне исчерпывающую информацию о системе, за исключением некоторых аспектов. Например, там не описывается порядок прохождения пакетов по таблицам, встроенным цепочкам и блокам route decision - эту информацию можно узнать из статей на сайте netfilter.org.


Добавлено через 8 минут и 40 секунд:

Как для этого случая записать правило обратного проброса ответа?

Для таблицы nat этого делать не нужно!

Кстати, таблица nat особенная: после того, как первый (инициирующий) пакет из взаимосвязанной цепочки проходит его, в специальной структуре ядра - connection tracking - создается запись и остальные пакеты уже по таблице не проверяются. Если интересно, посмотри /proc/net/ip_conntrack.

Первый пакет от клиента к серверу определяет всю судьбу дальнейших пакетов в данной цепи. как-то взаимосвязанной последовательности обмена UDP-пакетами, или обмен ICMP-сообщениями, или пакеты одного TCP-соединения. Т.е. нужно только одно NAT-правило для первого пакета - остальное отследит connection tracking.

Я уже ничего не понимаю в твоих правилах - не понятно, какие в какой таблице и для чего...
Кстати, чтобы не запутаться я и использовал сокращения в начале имен собственных цепочек:
fwd - для FORWARD
inp - для INPUT
out - для OUTPUT
pre - для PREROUTING
pst - для POSTROUTING

[Dimka]

Я как-то всегда руководствовался тем соображением, что лишний трафик отсекать на самых ранних этапах обработки. Поэтому, например, у меня в маршрутизаторе используется лишь INPUT цепочка. Другое мне не надо, ибо тоже лишь 2 интерфейса: внешний и внутренний.

Пусть eth0 внешний, а eth1 внутренний. Если надо запретить входящий трафик, делать это в INPUT для eth0. Надо установить политику по умолчанию reject и добавить правила, разрешающие исключения: трафик для established-соединений (TCP) из eth0, ICMP всюду и собственные TCP и UDP сервисы для eth0. Причём собственные сервисы разрешать не вообще, а для конкретного внешнего адреса маршрутизатора или сервера. Ну и естественно accept для всего eth1. Тонкий момент для UDP, т.к. протокол не поддерживает концепцию соединения и по established-состоянию не фильтруется; однако и протокол не так, чтобы сильно популярный (но нужный для DNS, скажем) - я открываю. Остальное оказывается по умолчанию закрытым.

Остальные цепочки пусты, и политика по умолчанию для них accept.

Городить более сложный огород можно при желании порегулировать пользователей внутренней сети (например, засадить их за прокси). Для этого годится в том же INPUT убрать правило accept для eth1 и заменить его на более детальное.

[RXL]

Dimka, цепочки INPUT и OUTPUT используются для самого хоста и к транзиту никакого отношения не имеет (в предшественнике iptables - ipchains - имело, но было это бессмысленно и работало на ядрах 2.2.х).

Добавлено через 16 минут и 16 секунд:

Пусть eth0 внешний, а eth1 внутренний. Если надо запретить входящий трафик, делать это в INPUT для eth0. Надо установить политику по умолчанию reject и добавить правила, разрешающие исключения: трафик для established-соединений (TCP) из eth0, ICMP всюду и собственные TCP и UDP сервисы для eth0. Причём собственные сервисы разрешать не вообще, а для конкретного внешнего адреса маршрутизатора или сервера. Ну и естественно accept для всего eth1. Тонкий момент для UDP, т.к. протокол не поддерживает концепцию соединения и по established-состоянию не фильтруется; однако и протокол не так, чтобы сильно популярный (но нужный для DNS, скажем) - я открываю. Остальное оказывается по умолчанию закрытым.

Дим, ты не прав. Здесь ESTABLISHED не имеет отношения к потоковым или датаграммным протоколам - это параметр состояния записи в connection tracking для данного пакета.

Where state is a comma separated list of the connection states to match. Possible states are INVALID meaning that the packet could not be identified for some reason which includes running out of memory and ICMP errors which don’t correspond to any known connection, ESTABLISHED meaning that the packet is associated with a connection which has seen packets in both directions, NEW meaning that the packet has started a new connection, or otherwise associated with a connection which has not seen packets in both directions, and RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.

И пофиг, tcp, udp или иной протокол используется.

[Dimka]

RXL, вообще у меня, конечно, ipf во FreeBSD. Наверняка есть какие-то отличия, в том числе и существенные. Поэтому выше и нижесказанное относится к ipf.

цепочки INPUT и OUTPUT используются для самого хоста и к транзиту никакого отношения не имеет

Тем не менее, правила на INPUT блокируют и транзитный трафик (в ipf). Значит в Linux правила будут в PREROUTING. Ну или трафик на сам маршрутизатор (сервер) в INPUT, а остальное в PREROUTING.

Здесь ESTABLISHED не имеет отношения к потоковым или датаграммным протоколам - это параметр состояния записи в connection tracking для данного пакета.

И опять же, для UDP не работает (в ipf).

и работало на ядрах 2.2.х

Именно это у меня и было до FreeBSD Значит устарело.

[RXL]

Дим, тема о Linux

Переход на ядра 2.4 свершился в 1999-2000 году, а с ним и переход на iptables.