Настройка 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 находясь не за клавиатурой самого сервера. Ведь если вы случайно запретите себе доступ, то придется ноги-в-руки-и-на-работу 🙂 Если вы уже знаете, что делаете, это к вам не относится.

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

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Linux. Настройка роутера (NAT + DHCP + Squid)

Linux. Настройка роутера (NAT + DHCP + Squid)

Наиболее частым применением Linux серверов является организация общего доступа в интернет. Это обусловлено низкой стоимостью такого решения и невысокими требованиями к железу. Во многих случаях это бывает первый Linux сервер в организации, что способно вызвать у администраторов определенные сложности. В данной статье мы пошагово рассмотрим настройку роутера (NAT + DHCP + Squid) на базе Ubuntu Server 9.04

Внимание! Данный материал устарел, при настройке роутера на базе Ubuntu Server 12.04 и старше рекомендуем воспользоваться обновленной статьей.

Установка и первоначальная настройка

Ubuntu Server отличается от своей настольной версии отсутствием графической оболочки и пользовательских приложений, а также возможностью предустановки заранее выбранных ролей сервера. Несмотря на это, все сказанное будет справедливо для любой версии Ubuntu и, с некоторыми поправками, для любого Linux дистрибутива. Установка Ubuntu Server происходит в текстовом режиме на русском языке и, как правило, не вызывает сложностей. Отдельно стоит только остановится на списке ролей: из предложенного нас, пожалуй, может заинтересовать только OpenSSH, для удаленного доступа, однако воспользовавшись пунктом Manual package selection опытный пользователь может сразу установить необходимые ему пакеты.

Если же это ваш первый сервер, то лучше всего продолжить не выбирая никакого варианта, все необходимые пакеты мы установим позже. Это позволит иметь более четкое представлении о назначении того или иного пакета и позволит успешно справляться с возможными неполадками. По окончании установки система перезагрузится и встретит нас черным экраном командной строки. Непривычного к консоли Windows-администратора это может неприятно удивить, однако ситуация на сегодняшний день такова, что все серверные роли Linux настраиваются исключительно через консоль и файлы конфигурации.

В первую очередь настроим сетевые соединения. Вводим в консоли:

Эта команда откроет в консольном редакторе nano конфигурационный файл с сетевыми интерфейсами, аналогичный рисунку ниже.

Пока там прописан единственный интерфейс eth0, настроенный на работу по DHCP. К eth0 у нас подключен ADSL модем (или любая сеть провайдера), а eth1 смотрит во внутреннюю сеть. IP адрес на внешнем интерфейсе 192.168.1.2, шлюз (ADSL модем) 192.168.1.1, внутренняя сеть лежит в диапазоне 10.0.0.1 — 254. Тогда настройки будут выглядеть следующим образом:

Сохраняем изменения Ctrl+O и выходим Ctrl+X. Теперь нужно настроить DNS, для этого выполняем:

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

Сохраняем. Теперь нужно перезапустить сетевые службы (либо перезагрузиться):

Собственно сеть настроена, можно переходить к следующему этапу, однако мы рекомендуем установить еще несколько пакетов для удобства администрирования. Сначала обновим список доступных пакетов:

Также рекомендуем обновить версии пакетов до актуальных:

Теперь установим Midnight Commander (mc), файловый менеджер по образу и подобию Norton Commander или Far:

Для запуска Midnight Commander достаточно набрать в консоли его краткое имя: mc. Сразу рекомендуем включить встроенный редактор, более удобный чем nano: F9 — Настройки — Конфигурация — Встроенный редактор.

Для удаленного управления сервером (не бегать же к нему каждый раз) установим OpenSSH, что позволит подключаться к нему из любого места, даже из дома, по защищенному протоколу:

Для подключения с Windows станций можно использовать программу PuTTY (скачать), для корректного отображения символов перед подключением необходимо на закладке Window — Translation выбрать кодировку UTF8.

Для ограничения доступа к серверу можно дописать в файл /etc/ssh/sshd_config параметр AllowUsers с указанием пользователя имеющего доступ по SSH, например для пользователя admin:

Также можно разрешить доступ определенной группе пользователей используя параметр AllowGroups, либо запретить доступ определенным пользователям / группам использовав DenyUsers и DenyGroups.

Настраиваем NAT

Для организации общего доступа к интернет необходимо настроить трансляцию сетевых адресов (NAT), что позволит сетевым службам внутренней сети получать доступ к внешней сети. Для этого достаточно выполнить всего одну команду, но есть одна тонкость: все будет работать только для перезагрузки. На настоящий момент в Linux нет механизма, который бы сохранял настойки iptables при перезагрузке сервера или сети. Поэтому мы пойдем другим путем и вынесем эти настройки в отдельный скрипт, запускаемый при загрузке системы. Сначала создадим файл скрипта:

Потом откроем его в редакторе Midnight Commander (F4) и внесем следующий текст:

Сохраняем (F2), для автоматического запуска скрипта снова открываем /etc/network/interfaces и в самый конец файла дописываем:

Также не забываем дать нашему скрипту права на исполнение:

Если нигде не допущено ошибок все должно работать. Для проверки укажем на машинах внутренней сети в качестве шлюза и DNS адрес нашего роутера: 10.0.0.1 и пропингуем любой внешний адрес, например один из OpenDNS серверов: 208.67.222.222. Но интернет пока работать не будет. Почему? Да потому, что мы указали в качестве DNS сервера наш роутер, который пока таковым не является. Можно конечно явно прописать DNS на клиентской машине,однако, это не наш метод, если вдруг DNS сервера изменятся, нам что, бегать перепрописывать?

Одно из решений: поднять на нашем роутере полноценный DNS сервер, но в большинстве случаев это избыточно, поэтому мы ограничимся простым кеширующим DNS (а также и DHCP) сервером Dnsmasq.

После установки открываем /etc/dnsmasq.conf, находим, раскомментируем и изменяем следующим образом строку, чтобы разрешить серверу принимать DNS запросы из внутренней сети.:

Перезапускаем DNS сервер:

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

Настраиваем DHCP

Теперь, когда наш сервер работает, нужно настроить клиентские машины. Можно, конечно, прописать все параметры вручную, но как быть если клиентских машин много и расположены они по всему зданию? Здесь нам на выручку приходит протокол DHCP, который позволяет клиентским машинам получать сетевые настройки автоматически. В качестве DHCP сервера выступит уже установленный Dnsmasq. Настроить его не просто, а очень просто, для чего снова открываем /etc/dnsmasq.conf.

Все что нам надо, это задать диапазон выдаваемых адресов (в нашем случае 10.0.0.100-150), сетевую маску и время, на которое выдается IP адрес:

Адреса DNS сервера и шлюза сервер берет автоматически из системных настроек. Еще раз перезапускаем Dnsmasq:

Теперь можно выставить на клиенте автоматическое получение IP адреса и убедиться, что все работает нормально.

Просмотреть выданные адреса можно командой:

В выдаче будут перечислены выданные IP адреса и MAC адреса которым они выданы.

Настраиваем кеширующий прокси-сервер Squid

В любой большой сети определенная часть трафика повторяется от пользователя к пользователю и порой его доля доходит до 50%. Логично бы было кешировать наиболее повторяющиеся запросы и тем самым снизить нагрузку на канал, сэкономить входящий трафик и ускорить выдачу страниц конечному пользователю. Для этих задач мы используем Squid — кеширующий прокси с широчайшими возможностями.

Останавливаем прокси-сервер и приступаем к настройке:

Открываем /etc/squid/squid.conf, находим и корректируем следующие строки, не забыв их раскомменитровать:

Указываем порт и адрес на котором squid будет принимать соединения:

Указываем внутренние сети, лишние комментируем:

Разрешаем доступ из внутренних сетей (найти и раскомменитровать):

Устанавливаем лимит использования памяти:

Задаем язык вывода ошибок для пользователя

Важное замечание! В Ubuntu 9.10 эта строка может выглядеть так, рекомендуем проверить правильность пути: error_directory /usr/share/squid/errors/ru

Сохраняем файл конфигурации. Теперь строим кэш и запускаем:

Для проверки указываем в браузере на клиентской машине использование прокси-сервера с адресом 10.0.0.1 и портом 3128, убеждаемся что все работает. Остается настроить прозрачную работу прокси-сервера, чтобы http трафик заворачивался на Squid автоматически, без прописывания прокси на клиенте. Для этого открываем /etc/nat и дописываем в конец строку:

Все. В нашем распоряжении рабочий сервер, позволяющий организовать общий доступ к интернет, кешируюший http трафик и DNS запросы, а также умеющий раздавать клиентским машинам необходимые для работы в сети настройки.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник