Настройка iptables и NAT

Задача: настроить шлюз в интернет для офиса на основе обычного компьютера с установленной Linux с двумя сетевыми картами.

Условимся, что внутренняя сетевая карта называется eth1, внешняя — eth0.

Чуть-чуть ликбеза. Мы настроим (1) forwarding (маршрутизацию) и (2) NAT (netowrk address translation).

(1) Маршрутизация (forwarding) в данном случае означает, что когда пакет из локальной сети в поисках «ya.ru» (или иного сайта или внешнего IP) попадает на наш шлюз, то шлюз должен знать, что такие пакеты надо передать на внешний интерфейс (eth0) — мол, летите, соколы, дальше. Дальше точно так же (ну, пусть не точно также, ну пусть и совсем не так же) от одного узла до другого провайдеры перекидывают наш пакет все дальше от нас и все ближе к цели.

(2) NAT. Как много в этом слове. Пример. Вася открывает сайт ya.ru (IP: 213.180.193.3). Т.к. в локальной сети IP-адреса локальные (не маршрутизируются в интернет, ну никак), то наш шлюз подменяет адрес источника пакета (ноутбук Васи, src=192.168.1.134) на свой собственный IP адрес (src=1.2.3.4), выданный провайдером. Сайт ya.ru будет считать, что IP Васи не 192.168.1.134, а 1.2.3.4. И ответный пакет ya.ru отправит нашему шлюзу. При получении ответа от удаленного сервера наш шлюз вспомнит, какая локальная машина запрашивала 213.180.193.3 и в ответном пакете поменяет dst с 1.2.3.4 на 192.168.1.134.

Такой NAT еще называют SNAT (Source NAT), т.к. изначально меняется адрес источника (src, source). Есть другой NAT — DNAT (destination nat, dst nat). Но морочить себе голову сейчас мы не дадим, не так ли 😉

Если в дальнейшем будет нужна статистика и пр., то настроить Squid будет не так и сложно.

Для простоты обозначений, наш шлюз будем называть сервер. Поехали.

1. Создаем скрипт правил iptables iptables.sh

Например, в директории /root создадим файл iptables.sh, дадим ему права на исполнение:

chmod +x /root/iptables.sh

Теперь поместим в этот файл следующий текст:

# Define vars
IF_EXT=»eth0″
IF_INT=»eth1″
IPT=»/sbin/iptables»

# flush
$IPT —flush
$IPT -t nat —flush
$IPT -t mangle —flush
$IPT -X

# loopback
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

# default
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

# allow forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

$IPT -N bad_packets
$IPT -P bad_packets ACCEPT

$IPT -A bad_packets -i $IF_EXT -s 10.0.0.0/8 -j DROP
$IPT -A bad_packets -i $IF_EXT -s 172.16.0.0/12 -j DROP
$IPT -A bad_packets -i $IF_EXT -s 192.168.0.0/12 -j DROP
$IPT -A bad_packets -i $IF_EXT -s 127.0.0.0/8 -j DROP
$IPT -A bad_packets -i $IF_EXT -s 0.0.0.0/8 -j DROP
$IPT -A bad_packets -i $IF_EXT -s 169.254.0.0/16 -j DROP
$IPT -A bad_packets -i $IF_EXT -s 192.0.2.0/24 -j DROP
$IPT -A bad_packets -i $IF_EXT -s 204.152.64.0/23 -j DROP
$IPT -A bad_packets -i $IF_EXT -s 224.0.0.0/3 -j DROP
$IPT -A bad_packets -i $IF_EXT -s 240.0.0.0/5 -j DROP

$IPT -A INPUT -j bad_packets
$IPT -A OUTPUT -j bad_packets
$IPT -A FORWARD -j bad_packets

# allow new connections from local net to out
$IPT -A FORWARD -i $IF_INT -o $IF_EXT -m state —state NEW,ESTABLISHED,RELATED -j ACCEPT
# do not allow new connections from internet, but support established connections from local network
$IPT -A FORWARD -i $IF_EXT -o $IF_INT -m state —state ESTABLISHED,RELATED -j ACCEPT

# SNAT — local users to out internet
$IPT -t nat -A POSTROUTING -o $IF_EXT -j MASQUERADE

$IPT -A INPUT -p tcp ! —syn -m state —state NEW -j DROP
$IPT -A INPUT -m state —state ESTABLISHED,RELATED -j ACCEPT

$IPT -A INPUT -i $IF_INT -p tcp —dport 22 -j ACCEPT

# new local connections
$IPT -A OUTPUT -m state —state NEW,ESTABLISHED,RELATED -j ACCEPT

2. Комментарии к скрипту iptables.sh

1. Все секции снабжены минимальными комментариями, поэтому в них не запутается даже новичок.
2. Наиболее «туманная» секция — # PROTECT FIREWALL, но во-первых, временно вы можете ее вообще убрать, а во-вторых, если задуматься, там всё просто. Мы защищаем наш сервер от атак, когда из внешней сети пытаются «прикинуться» внутренними адресами. Вот и все.
3. Чтобы наш сервер в принципе мог выпускать во внешний мир клиентов локальной сети, обязательно надо включить forwarding (почти в самом начале скрипта):

# allow forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

Данный параметр также может быть задан через параметр:

net.ipv4.ip_forward = 1 в файле /etc/sysctl.conf.

Чтобы изменения в файле sysctl.conf вступили в силу, выполните следующую команду:

sysctl -p /etc/sysctl.conf

В секции # INPUT chain мы разрешаем клиентам локальной сети подключаться к серверу по ssh. Обратите внимание, несмотря на то, что к самому серверу можно обратиться только по ssh, клиенты локальной сети не будут ограничены в выходе в интернет. Цепочка INPUT не для них!

В цепочке # OUTPUT chain мы разрешаем серверу обращаться во внешний мир (скачивать обновления, например). Для упрощения считаем, что мы доверяем нашему серверу и разрешаем ему любые исходящие соединения.

Еще раз отмечу — цепочки INPUT и OUTPUT работают только для тех пакетов, которые адресованы локальной машине, в нашем случае это сам сервер.

Фактически, пакет из локальной сети в интернет проходит две (упрощенно) цепочки: FORWARD -> POSTROUTING. Более детальное описание этапов прохождения пакетов через iptables смотрите в статье «Порядок прохождения таблиц и цепочек IPTABLES». Поэтому все ограничения клиентов локальной сети (разрешить ли ICQ, WWW, POP3 и т.п.) настраиваются правилами FORWARD (секция #FORWARD chain). Например, для того, чтобы разрешить доступ только к сайтам, пишем:

$IPT -A FORWARD -i $IF_INT -o $IF_EXT -dport 80 -m state —state NEW,ESTABLISHED,RELATED -j ACCEPT

Правило по-умолчанию ($IPT -A FORWARD -i $IF_INT -o $IF_EXT -m state —state NEW,ESTABLISHED,RELATED -j ACCEPT) естественно, удаляем либо комментируем символом #.
Для того, чтобы после перезагрузки правила iptables не стирались, после того, как выполните скрипт iptables.sh и убедитесь, что все работает так, как надо, выполните команду:

service iptables save

Эта команда сохранит настройки iptables. Эта команда подойдет для RHEL-основанных дистрибутивов. Для других не знаю. Если нужен универсальный метод — поместите запуск этого скрипта в автозагрузку.

Пожалуй, все. Естественно, если вы новичок, НИКОГДА не настраивайте правила iptables находясь не за клавиатурой самого сервера. Ведь если вы случайно запретите себе доступ, то придется ноги-в-руки-и-на-работу 🙂 Если вы уже знаете, что делаете, это к вам не относится.

Если есть вопросы, пишите!

Источник

Настройка NAT, DNAT в Linux с помощью iptables

Настройка NAT, DNAT в Linux с помощью iptables

О чем же пойдёт речь

Всё очень просто, в очередной раз объясняя на форуме новичкам в мире Linux, что да как я понял, что на просторах интернет не найти собранную воедино статью с объяснением не только настройки iptables, но и некоторых сетевых основ.

Так что вашему вниманию я представляю небольшой экскурс по настройке firewall в Linux. Углубимся лишь в настройку netfilter/iptables, остальных прикладных вопросов мы несомненно тоже коснёмся, ведь нам не хватает именно комплексных ответов на наши вопросы… И я постараюсь ка можно более доходчиво здесь все изложить.

Как это выглядит

Мы будем рассматривать типичную схему для офисов и для квартир, да-да именно квартир! Мало у кого есть собственный маленький сервачок дома под столом, но у большинства интернет дома раздается через роутер и в большинстве своём они тоже прошиты Linux.
Это типичная схема малого офиса. Когда к интернет подключен 1 компьютер(сервер), а остальные подключаются к интернет уже через этот сервер.
Поехали, потихонечку…

И так что же мы имеем:
сервер с 2мя сетевыми картами и установленным на нём Debian Lenny
имеющийся по умолчанию в Debian Lenny firewall — netfilter/iptables
локальную сеть из N компьютеров, все соединены через коммутатор, в том числе и сервер

Для начала нам нужно понять, что настраивать мы будем самый обыкновенный NAT(Network Address Translation). Для жаждущих, я в конце упомяну и о проксе сервере на примере squid. Как я уже сказал разжёвывать будем практически всё.
Что же такое NAT? На самом деле все просто, все компьютеры имеют физический (MAC) и сетевой (IP) адреса. Нас в данный момент интересуют IP адреса. IP адрес в пределах одной сети должен быть уникальным! А при нынешнем стандарте IPv4 уникальными могут быть всего-то 4 294 967 296 (232), что совсем не много и они практически кончились. но не переживайте вот вот вступит в широкое распространение IPv6, а там адресов навалом!
Но тут вы можете заметить, компьютеров значительно больше того числа, что позволяет IPv4 или скажете, что у друга дома такой же адрес как и у вас! И вот тут-то и заходит речь о NAT — он позволяет соединять компьютерные сети между собой используя единственный, свой IP адрес, действия фаервола при этом называется SNAT(Source NAT или подмена адреса источника). Т.е. в 99% случаев вся ваша контора выходит в интернет под 1 IP адресом, при этом внутри офиса у каждого он свой. О классах IP адресов вы сможете прочесть в интерне.

Теперь, когда мы знаем что такое NAT и для чего он нужен, можно приступать непосредственно к настройке сервера.
транзитный трафик

Все команды выполняются от имени root(суперпользователь). В Debian по умолчанию отключен так называемый транзитный трафик, т.е. по умолчанию предусмотрена работа только как единичная машина. Как вы уже догадались, без транзитного трафика нету и NAT. Для его включения достаточно изменить 1 цифру — $ echo 1 > /proc/sys/net/ipv4/ip_forward, но данная настройка слетит после перезагрузки, так что лучше поправить конфиг — $ nano /etc/sysctl.conf далее ищем строчку #net.ipv4.ip_forward=1 и убираем «решётку»(символ комментария) в начале строки и проверяем что значения равно 1! Теперь можно приступать непосредственно к конфигурированию iptables.
настраиваем iptables

В интернет, есть много статей о том как писать правила в iptables и что с их помощью можно творить, наиболее полным и приятным для чтения мне показалась статья на wikipedia.org.
И так приступим. Для начала очистим таблицы от лишних правил, вдруг там что было лишнего…
$ iptables -F
$ iptables -t nat -F
$ iptables -t mangle -F
Лишнее почистили. Очень важно понять и помнить, что правила в iptables применяются иерархически, т.е. правило стоящее выше выполнится раньше. Все цепочки по умолчанию имеют политику ACCEPT — разрешают всё. что не попало под правила данной цепочки.
Условимся, что интерфейс смотрящий в локальную сеть — eth0, а в интернет — eth1, локальная сеть имеет адреса 192.168.0.0/24, а провайдер выдал нам статический адрес 10.188.106.33(пускай и не «белый» — о типах ip адресов вы также можете посмотреть в интернет). И так пишем:
$ iptables -A FORWARD -i eth0 -o eth1 -s 192.168.0.0/24 -j ACCEPT
$ iptables -A FORWARD -i eth1 -o eth0 -d 192.168.0.0/24 -j ACCEPT
$ iptables -P FORWARD DROP
тем самым разрешили ходить транзитным пакетам через firewall для нашего диапазона ip адресов, а всё остальное запрещаем.
Теперь сам NAT:
$ iptables -A POSTROUTING -s 192.168.0.0/24 -o eth1 -j SNAT —to-source 10.188.106.33
Этого достаточно для того что бы у вас заработал NAT.
по мелочам…

На клиентах указываем ip из выбранного диапазона и указываем в качестве шлюза ip адрес нашего сервера(обычно его назначают первым из подсети — я оставлю это на ваше усмотрение). Все сетевые настройки на сервере можно провести так:
$ nano /etc/network/interfaces в нём указываются настройки ваших сетевых интерфейсов.
доступ в недры сети через шлюз или DNAT

И тут вы поняли, что в сети у вас есть Windows Server к которому у вас всегда был простой доступ по RDP, а тут вылез это назойливый шлюз на Debian! Всё очень просто — надо всего лишь добавить DNAT правило в наш iptables.
Что за зверь DNAT? DNAT (Destination NAT или подмена адреса получателя) — сетевые карты работают в таком режиме, что они принимают только пакеты адресованные именно им, а зайти на наш сервер если ip под которым он выходит в интернет сидят еще десяток машин в вашем офисе? Как запрос дойдёт именного до него? На самом деле все запросы такого рода упираются в наш шлюз. И всё что нам надо сделать это задать правила для работы с такими пакетами.
$ iptables -A PREROUTING -i eth1 -p tcp -m tcp —dport 3389 -j DNAT —to-destination 192.168.0.2
Это простое правило будет переадресовывать все пакеты приходящие на шлюз из интернет на порт TCP 3389(именно его использует RDP протокол) на ваш внутренний Windows Server. И, вуаля, у вас все работает.
итак что там с любимым squid

И хотя сейчас все работает, у всех есть интернет и все работает, некоторым всё же нужен прокси сервер. Я не буду рассказывать о настройке squid, я покажу правило которое позволит сделать его «прозрачным». В сквид надо лишь прописать волшебное слово transparent в нужном месте и он начнём корректно обрабатывать свалившееся на него запросы.
Пишем

$ iptables -A PREROUTING -d! 192.168.0.0/24 -i eth0 -p tcp -m multiport —dports 80,443 -j REDIRECT —to-ports 3128 .

И что же нам это даёт? Теперь все запросы на web страницы с ваших рабочих мест по http((80) и https(443) протоколам будут перенаправляться на порт который слушает squid. Вы получает контентную фильтрацию, информацию о том кто где был и что делал в интернет, пользователь ни чего не подозревая работает как и раньше…
немного безопасности

Следует хоть минимально защитить свой шлюз поэтому добавим еще пару правил
$ iptables -A INPUT -i lo -j ACCEPT
$ iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j ACCEPT
$ iptables -A INPUT -i eth1 -m conntrack —ctstate RELATED,ESTABLISHED -j ACCEPT
$ iptables -P INPUT DROP
Тем самым запретили любое общение непосредственно с шлюзом, кроме уже установленных соединений, т.е. те что были инициированы вами и вы просто получаете на них ответы. Не бойтесь наш DNAT до этих правил просто не доходит…
почему так мало?

Статья не резиновая и обо всем все-равно не расскажешь… Я привел минимальный набор действий и понятий что бы вы могли начать осваивать такую махину как шлюз на Linux. Здесь можно говорить очень и очень долго, обсуждая многие аспекты и возможности netfilter.
Итого

Как мы видим все действительно просто! Главное это понять принцип функционирования сети и не боятся настраивать и читать большие мануалы.
Надеюсь мне удалось собрать воедино информацию достаточную для начала вашей дружбы с программными маршрутизаторами на основе Linux.

Источник