Шлюз+шейпер для домашней сети на Ubuntu

Моя домашняя сеть разрослась до количества трех компьютеров. В связи с чем началась дележка: кто будет качать первым. Иногда даже страничка в ФФ открывается по 2-3 минуты, так как на соседнем компе во всю качает торрент. Советом системных администраторов (то есть мной) было принято решение создать шлюз c шейпером который будет динамически делить канал на всех. Ну начнем Имеется две сетевые карты, eth0 — смотрит в интернет (модем в режиме роутера, и eth1 — смотрит в локальную сеть Я не буду описывать конфиги самих сетевых интерфейсов, но скажу, что eth0 получает IP от роутера, в то время как на eth1 выставлен статический IP, мной выбран 10.2.2.1 Для начала поднимем DHCP сервер для того, что бы оставшиеся компы могли получить IP адреса автоматом. Установим DHCP серверsudo apt-get install dhcp3-server После чего правим конфиг /etc/dhcp3/dhcp.conf я привел его вот к такому видуsubnet 10.2.2.0 netmask 255.255.255.0 { option routers 10.2.2.1; option subnet-mask 255.255.255.0; option domain-name-servers 195.54.2.1; option domain-name-servers 195.54.3.2; range 10.2.2.10 10.2.2.254; default-lease-time 21600; max-lease-time 28800; } затем правим файл /etc/default/dhcp3-server вписывая в него строкуINTERFACES=eth1 для того, что бы сервер «слушал» именно этот интерфейс После чего можем запустить серверsudo /etc/init.d/dhcp3-server start Для “раздачи” интернет во внутреннюю сеть используем IP маскарадинг (IPMASQUARADE) В сокращенном виде (без комментариев и не функциональных выводов сообщений) скрипт выглядит так:#!/bin/sh # полная версия находится здесь: lafox.net/docs/masq IPTABLES=/sbin/iptables DEPMOD=/sbin/depmod MODPROBE=/sbin/modprobe EXTIF="eth0" INTIF="eth1" $DEPMOD -a $MODPROBE ip_tables $MODPROBE ip_conntrack $MODPROBE ip_conntrack_ftp $MODPROBE ip_conntrack_irc $MODPROBE iptable_nat $MODPROBE ip_nat_ftp $MODPROBE ip_nat_irc echo "1" > /proc/sys/net/ipv4/ip_forward echo "1" > /proc/sys/net/ipv4/ip_dynaddr $IPTABLES -P INPUT ACCEPT $IPTABLES -F INPUT $IPTABLES -P OUTPUT ACCEPT $IPTABLES -F OUTPUT $IPTABLES -P FORWARD DROP $IPTABLES -F FORWARD $IPTABLES -t nat -F $IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT $IPTABLES -A FORWARD -j LOG $IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE echo -e "done.n" Сохраним это в файлик в /etc/profile.d и назовем его, к примеру masq.sh. Делаем его исполняемым и выполняемsudo chmod +x /etc/profile.d/masq.sh sudo sh /etc/profile.d/masq.sh После этих действий нужно «опустить» а потом снова «поднять» сетевой интерфейс eth1sudo ifonfig eth1 down sudo ifonfig eth1 up После чего клиенты смогут получать IP адреса и пользоваться инетом ))) А теперь мы настроим шейпер, в принципе для этого все и задумывалось, для того что бы динамически делить скорость инета. Я выбрал для шейпера скрипт htb.init который можно скачать тут sourceforge.net/projects/htbinitsudo cp htb.init /etc/init.d/htb sudo chmod +x /etc/init.d/htb sudo update-rc.d htb defaults В папке, в которую указывает HTB_PATH, (лично я поправил эту переменую и у меня получилось /etc/htb, естественно этой папки в системе нет ее нужно создать) создаем следующие файлы:eth1:R2Q=20 DEFAULT=0 R2Q — коэффициент, определяющий соотношение точности/скорости работы шейпераDEFAULT — идентификатор класса, в который попадают пакеты, если они не попадают под другие правила. Класс с идентификатором 0 существует всегда и пропускает пакеты без всякого шейпинга, то есть на полной скорости. Этим файлом мы инициализировали шейпер на интерфейсе eth0.eth1-2.root:RATE=24Mbit Этим файлом мы создали корневой класс траффика на интерфейсе eth0 и ограничили максимальную скорость отдачи через этот класс 24 мегабитами.eth1-2:2001:RATE=512Kbit CEIL=24Mbit LEAF=sfq RULE=10.2.2.10/24 Этим файлом мы создали класс для первого клиента. RATE — гарантируемая скорость для клиента. Поскольку в нашем случае не нужно гарантировать никакой скорости, но HTB этого требует, исходим из неравенства: 24000Кбит / 3 > RATE.CEIL — максимальная скорость для клиента при свободном канале.LEAF — указывает, что класс является одним из листов дерева, то есть в него попадает трафик, удовлетворяющий определенному правилу (RULE). Параметр sfq означает, что мы хотим, чтобы внутри этого класса скорость распределялась равномерно между сессиями.RULE — правило, задающее, какой трафик будет попадать в этот класс (см. Замечание 1). В данном случае в класс попадает весь трафик, имеющий IP назначения от 10.2.2.10 до 10.2.2.255. О назначении и значениях параметров, которые указываются в файлах, и о именах файлов можно узнать из скрипта htb.init — там вверху есть неплохая справка. Стартуем наш шейперsudo /etc/init.d/htb start Всё, шейпер включен. Далее, если что-то изменится в конфигруации, нужно сделать /etc/init.d/htb restart. Проверить работу скрипта htb.init, кроме спидтестов, можно просмотром конфигурации командами:tc class show dev eth1 tc qdisc show dev eth1 Ну можно еще много всего прикручивать к нашему серваку, и Clam AV и фаервол, но оставлю это вам ))) Удачи! P.S. Статья опубликована по просьбе друга, не имеющего доступ на Хабр, но желающего стать одним из Хаброюзеров (его почта — ktattoo@gmail.ru).Upd1. Спасибо за карму перенес в УбунтариумUpd2. Автор статьи теперь пользователь хабра — .

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

# /etc/iptables.sh

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

/sbin/iptables-save  > /etc/iptables.rules

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

# mcedit /etc/network/interfaces  post-up iptables-restore < /etc/iptables.rules

Для проверки перезагружаем шлюз и проверяем, все ли в порядке. По сути основная настройка программного роутера на debian завершена. Осталось сделать небольшое дополнение и настроить dhcp и dns сервер в локальной сети. Я для этих целей использую простой и легкий в настройке dnsmasq.

Установка и настройка dnsmasq в Debian

Выполним установку dnsmasq на дебиан:

# apt-get install -y dnsmasq

Сделаем минимальную настройку программы. Нам нужно просто выдавать сетевые настройки пользователям. Для этого приводим конфигурационный файл dnsmasq к следующему виду:

# mcedit /etc/dnsmasq.conf  domain-needed bogus-priv interface=eth1 dhcp-range=eth1,10.0.15.50,10.0.15.150,24h

В данном случае мы будем выдавать пользователям ip адреса в диапазоне от 10.0.15.50 до 150. Сохраняем конфиг, добавляем программу в автозагрузку и запускаем.

# insserv dnsmasq # /etc/init.d/dnsmasq start

Теперь можно запускать компьютер пользователя локальной сети, получать сетевые настройки по dhcp и проверять работу интернет шлюза.

Посмотреть выданные leases можно в файле /var/lib/misc/dnsmasq.leases. На этом настройка интернет шлюза на debian 8 закончена. Все что нужно для обеспечения доступа в интернет из локальной сети сделано. Получился программный роутер с широкими возможностями по наращиванию функционала.

Просмотр загрузки сети с помощью iftop

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

Устанавливаем iftop на debian:

# apt-get install -y iftop

Для просмотра активности сетевого интерфейса, запускаем утилиту, указывая необходимый ключ:

# iftop -i eth1

Чтобы увидеть порты, по которым идет трафик, добавляем ключ -P:

# iftop -i eth1 -P

На основе этой картинки уже можно сделать определенные выводы по использованию интернет канала. Обращаю внимание, что я смотрю загрузку локального интерфейса eth1. Если смотреть на eth0, то мы увидим только исходящие соединения сервера.

Заключение

Вот так легко и быстро можно настроить роутер, маршрутизатор или шлюз в интернет. Названия разные, а суть одна. В данном случае я использовал операционную систему Debian, но схожий функционал легко организовать на Freebsd или CentOS. Для решения текущей задачи разница в работе не будет заметна. Каждый выбирает то, что больше нравится и к чему привык.

Пройдемся быстренько по этапам того, что сделали:

1. Подготовили сервер Debian к настройке шлюза.
2. Настроили маршрутизацию, iptables, нат. Проверили, что весь функционал восстанавливается после перезагрузки.
3. Установили и настроили простой dhcp сервер и кэширующий dns сервер — dnsmasq. С его помощью автоматизировали поучение сетевых настроек пользователями.
4. Установили простое средство мониторинга сетевой активности в консоли в режиме реального времени с помощью утилиты iftop.

На этом мы закончили настройку. Как продолжение развития темы интернет шлюза можно заняться настройкой прокси сервера для управления доступам к ресурсам интернета, или сервера openvpn для подключения филиалов или удаленных сотрудников. Для примера привел ссылки на другие дистрибутивы. Со временем планирую описать реализацию этого функционала на debian. Принципиальных отличий нет, только нюансы разных дистрибутивов.

Напоминаю, что данная статья является частью единого цикла статьей про сервер Debian.

Онлайн курс по Linux

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Администратор Linux» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров. Что даст вам этот курс:

• Знание архитектуры Linux.
• Освоение современных методов и инструментов анализа и обработки данных.
• Умение подбирать конфигурацию под необходимые задачи, управлять процессами и обеспечивать безопасность системы.
• Владение основными рабочими инструментами системного администратора.
• Понимание особенностей развертывания, настройки и обслуживания сетей, построенных на базе Linux.
• Способность быстро решать возникающие проблемы и обеспечивать стабильную и бесперебойную работу системы.

Проверьте себя на вступительном тесте и смотрите подробнее программу по .

Помогла статья? Есть возможность отблагодарить автора

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

Рекомендую полезные материалы по Debian:
Настройки системы
Настройка программных комплексов
Разное

</ol></pre></pre></pre></pre></pre></pre></pre></pre></pre>

Более четырех лет назад мы опубликовали материал посвященный настройке роутера на базе Ubuntu Server. Тема оказалась весьма востребованной и популярной, но за прошедшее время некоторые настройки успели измениться, пусть и незначительно. В связи с этим мы решили вернуться к этой теме и опубликовать современную версию популярной статьи.

Мы не будем подробно останавливаться на установке системы и назначении тех или иных компонентов, об этом достаточно сказано в исходном материале, а уделим основное внимание отличиям в современных версиях Ubuntu Server и настраиваемых пакетах.

Настройка сети

В нашем примере внешний сетевой интерфейс — eth0 — имеет статические настройки, если же вы используете PPPoE или PPTP подключение, то для настройки подключения рекомендуем воспользоваться нашими материалами:

Начиная с версии 12.04 (мы рассматриваем только LTS версии и крайне не рекомендуем использовать на серверах промежуточные релизы) все сетевые настройки, в том числе и DNS-сервера указываются в одном месте, конфигурационном файле /etc/network/interfaces. Перед тем как приступать к настройке повысим права до суперпользователя:

sudo -s

затем откроем файл в штатном редакторе nano, работа с ним далека от удобства, но для изменения нескольких строк он вполне подойдет:

nano /etc/network/interfaces

Приведем его к следующему виду (настройки внешнего интерфейса приведены исключительно для примера):

auto eth0    iface eth0 inet static        address 172.18.0.106        netmask 255.255.240.0        gateway 172.18.0.1        dns-nameservers 172.18.0.1 208.67.222.222auto eth1    iface eth1 inet static        address 192.168.31.1        netmask 255.255.255.0post-up /etc/nat

Для указания DNS-серверов теперь используется директива dns-nameservers, если серверов несколько, они указываются в одну строку, через пробел.

Если вы получаете сетевые настройки от провайдера по DHCP, то настройки будут иметь вид:

auto eth0    iface eth0 inet dhcp

Последней строкой идет автоматическая загрузка правил iptables из файла /etc/nat, который мы создадим позже.

Перезапустим сеть:

service networking restart

Если все сделано правильно, на сервере должен появиться интернет. После чего следует обновить пакеты на сервере и установить необходимый минимум утилит для администрирования:

apt-get updateapt-get upgradeapt-get install mc ssh

Представлять двухпанельный менеджер с удобным редактором Midnight Commander (mc) мы думаем не нужно, как и SSH-сервер, дающий возможность удаленного администрирования.

Настройка NAT и брандмауэра

Технология сетевой трансляции адресов — NAT — позволяет организовать выход в интернет компьютеров локальной сети через один сетевой адрес. Данная технология абсолютно прозрачна для клиентских устройств и способна работать с любыми сетевыми приложениями и протоколами. За функции NAT в Ubuntu отвечает сетевой фильтр iptables, который предоставляет также функции брандмауэра.

В зависимости от политики сетевой безопасности существуют различные подходы к настройке брандмауэра. Мы предпочитаем задавать только базовые правила, исходя внутри сети из принципа: все что не запрещено — разрешено. Это позволяет свободно работать любым сетевым службам во внутренней сети и без помех выходить в интернет, обеспечивая при этом достаточный уровень безопасности. Для внешней сети запрещено все, что не разрешено и доступ к сетевым службам администратор должен разрешать явно.

Создадим файл настроек:

touch /etc/nat

и внесем в него следующее содержимое:

#!/bin/sh# Включаем форвардинг пакетовecho 1 > /proc/sys/net/ipv4/ip_forward# Сбрасываем настройки брандмауэраiptables -Fiptables -Xiptables -t nat -Fiptables -t nat -X# Разрешаем доступ из локальной сетиiptables -A INPUT -i eth1 -j ACCEPT# Разрешаем инициированные нами подключения извнеiptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT# Разрешаем подключения по SSHiptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT#Запрещаем входящие извнеiptables -A INPUT -i eth0 -j DROP# Разрешаем инициированные нами транзитные подключения извнеiptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT# Запрещаем транзитный трафик извнеiptables -A FORWARD -i eth0 -o eth1 -j DROP# Включаем NATiptables -t nat -A POSTROUTING -o eth0 -s 192.168.31.0/24 -j MASQUERADE

Сохраним изменения и дадим нашему файлу права на исполнение:

chmod +x /etc/nat

перезагрузим сервер:

reboot

Теперь если вручную задать сетевые настройки для рабочей станции, указав в качестве шлюза наш роутер и любой доступный DNS-сервер, то не ней должен появиться доступ в интернет.

Настройка DHCP и кэширующего DNS

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

Все эти функции реализованы в одном пакете dnsmasq, который предельно прост в установке и настройке:

apt-get install dnsmasq

Функции кэширующего DNS-сервера становятся доступны сразу после установки и в настройке не нуждаются, однако следует явно указать интерфейсы, которые будет обслуживать dnsmasq. Для этого откроем файл /etc/dnsmasq.conf и изменим следующую строку (не забываем раскомментировать при необходимости):

listen-address=127.0.0.1, 192.168.31.1

Для настройки DHCP сервера достаточно указать диапазон пула адресов и срок аренды:

dhcp-range=192.168.31.100,192.168.31.199,255.255.255.0,12h

Перезапустим сервис:

service dnsmasq restart

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

Настройка кэширующего прокси-сервера Squid3

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

Squid поддерживает кэширование двух типов, в оперативной памяти и на диске. Сегодня можно встретить рекомендации отказаться от дискового кэша, мол проще скачать объект заново, чем искать его на диске. Однако мы считаем, что разумный размер дискового кэша при большом количестве клиентов позволяет эффективно использовать канал за счет хранения в кэше статических элементов: картинок, скриптов, CSS-файлов для часто посещаемых ресурсов.

Сразу предостережем от распространенной ошибки — использования для хранения кэша старых медленных дисков и выделения под кэш значительного пространства. В этом случае эффект будет прямо противоположен ожиданиям, время поиска объекта на диске при большой нагрузке будет занимать значительно больше времени, чем его повторное скачивание.

Но все преимущества Squid раскрываются тогда, когда появляется необходимость тонкой фильтрации трафика, здесь богатые возможности позволяют реализовывать самые разнообразные схемы, которые просто невозможно рассмотреть в рамках одного материала, получить все материалы по данной теме вы можете выполнив поиск по тегу squid.

Внимание! Начиная с Debian 9 и Ubuntu 16.04 вместо пакета squid3 снова используется squid, также аналогичным образом следует изменить все пути, т.е. вместо /etc/squid3 использовать /etc/squid.

Для установки squid выполните команду:

apt-get install squid3

Перейдем к настройкам. Для новичка конфигурационный файл squid может показаться излишне сложным, на самом деле большую часть его занимают подробные комментарии и примеры. Поэтому мы пойдем по файлу от начала к концу, указывая какие строки надо добавить или изменить. Откроем файл конфигурации /etc/squid3/squid.conf и перейдем к указанию группы доступа (acl) для локальной сети. Раскомментируем и исправим или добавим ниже строку:

acl localnet src 192.168.31.0/24

Затем, спускаясь далее по конфигурационному файлу найдем секцию отвечающую за правила доступа и убедимся, что она содержит следующие правила:

http_access allow localnethttp_access allow localhosthttp_access deny all

Данная секция разрешает доступ для клиентов локальной сети, собственно сервера и запрещает всем остальным.

Теперь укажем порт, интерфейс и режим работы прокси-сервера.

http_port 192.168.31.1:3128 intercept

Параметр intercept указывает, что прокси работает в прозрачном режиме, т.е. не требует прямого указания прокси на клиентах.

Перейдем к указанию параметров кэша. Зададим доступный объем памяти и укажем максимальный объем кэшированного объекта в памяти:

cache_mem 1024 MBmaximum_object_size_in_memory 512 KB

При задании этих параметров исходите из доступной памяти сервера, но учтите, что кэш в памяти начинает эффективно работать только после «прогрева» и будет сброшен при перезагрузке или выключении сервера.

После чего укажем размер дискового кэша и его расположение:

cache_dir ufs /var/spool/squid3 2048 16 256

Размер кэша указывается в МБ, в нашем случае 2048 МБ — 2 Гб, следующие два числа указывают количество директорий первого и второго уровня, рекомендуем оставтить эти параметры без изменения.

Следующий параметр задает максимальный размер объекта в дисковом кэше:

maximum_object_size 4 MB

Далее по файлу укажем место хранения логов и количество ротаций:

access_log daemon:/var/log/squid3/access.log squidlogfile_rotate 31

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

Внимание! В Ubuntu Server 12.04 (Squid 3.1) указанная выше строка должна иметь вид: access_log /var/log/squid3/access.log squid

Остальные параметры оставляем без изменений, сохраняем файл настроек.

Перед тем как перезапускать службу выполним проверку файла конфигурации:

squid3 -k check

Если команда отрабатывает без вывода — ошибок нет, в противном случае изучаем вывод и исправляем допущенные ошибки. После этого перезапустим службу, чтобы применить внесенные изменения.

service squid3 restart

В том случае, когда были изменены параметры кэша следует его перестроить:

service squid3 stopsquid3 -zservice squid3 start

Затем в /etc/nat добавляем правило заворачивающее http-трафик на squid:

# Заворачиваем http на проксиiptables -t nat -A PREROUTING -i eth1 ! -d 192.168.31.0/24 -p tcp --dport 80 -j REDIRECT --to-ports 3128

Сохраняем изменения, перезагружаем сервер.

Обращаем ваше внимание, что squid3 в прозрачном режиме, в отличие от предыдущей версии, не принимает соединения, если в настройках прямо указано использование прокси.

В этом случае вы получите сообщение, что доступ запрещен:

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

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

</span>

Используемые источники:

• https://habr.com/post/73257/
• https://serveradmin.ru/nastroyka-internet-shlyuza-na-debian/
• https://interface31.ru/tech_it/2014/02/ubuntu-server-nastraivaem-router-nat-dhcp-squid3.html