Linux шлюз сделай сам

Интернет-шлюз на базе Ubuntu Server / Internet Connection Sharing + Squid, Firestarter

Содержание

Имеется сервер и подключенные к нему клиенты по локальной сети. Сервер имеет выход в интернет. Необходимо устроить раздачу интернета сервером.

Основная часть

Собственно, установка шлюза на базе Ubuntu Server занимает не больше 10-15 минут.

PPPoE

Если Вы используете для подключения по локальной сети PPPoE, вам необходимо просто-напросто ввести в терминале команду:

и дать ответы на вопросы. По окончании работы pppoeconf соединение должно быть установлено.

Если Вы используете для подключения к провайдеруL2TP, то для этого понадобится установить xl2tpd — демон l2tp и pppd — демон ppp. 1)

Редактируем файл настроек xl2tpd:

Записываем в файл chap-secrets логин и пароль:

соединение должно быть установлено.

На установленной машине Интернет появился. Теперь надо добавить включить все репозитарии в /etc/apt/source.list и выполнить:

Для доступа с других машин вашей локальной сети необходимо поставить всего лишь навсего два малюсеньких пакета:

Или, вы можете использовать DNS провайдера.

Прокси-сервер squid

Squid — программный пакет, реализующий функцию кэширующего прокси-сервера для протоколов HTTP , FTP , Gopher и HTTPS.

Для установки прокси-сервера squid необходимо выполнить команду:

Теперь редактируем конфигурационный файл. Открываем /etc/squid/squid.conf , ищем нужные строки и корректируем следующим образом:

Перезапускаем прокси-сервер командой:

Настраиваем браузеры на клиентских машинах на использование прокси: адрес прокси — пишем IP адрес интерфейса, обращенного в локальную сеть. Скорее всего,это будет 192.168.0.1, порт прокси — указанный в конфигурационном файле 3128.

Желающим сделать прозрачное проксирование необходимо изменить в файле настроек squid.conf одну строчку:

Затем для заворачивания нужных портов на прокси-сервер прописывается правило:

Раздача Интернета в локальную сеть c помощью firestarter

Firestarter – это средство для создания межсетевых экранов для Linux, использующее GNOME. С помощью мастера можно создать базовый межсетевой экран, в дальнейшем его возможности расширяются с помощью динамических правил. Несколькими щелчками мыши можно открывать и закрывать порты или скрывать сервисы, оставляя доступ только к некоторым из них. В программе имеется монитор, который в режиме реального времени показывает попытки поиска злоумышленниками открытых портов.

Для начала установим firestarter :

При настройке указываем интерфейс с Интернетом — ppp0 раздавать на eth1 2)

Раздача Интернета в локальную сеть (ICS: Internet Connection Sharing)

Для организации совместного доступа в Интернет с помощью общего доступа к подключению Интернета на сервере должна быть одна сетевая карта для подключения к внутренней сети и еще одна карта или модем для подключения к Интернету.

На сервере

Для настройки общего доступа к подключению Интернета необходимо выполнить на сервере указанные ниже действия.

Исходные данные: Оба компьютера соединены по сети. На сервере установлено две сетевые карты:

Это можно сделать вручную или используя терминал:

Разрешите направление пакетов. Чтобы сделать это, отредактируйте /etc/sysctl.conf . Откройте сам файл командой:

А затем вставьте следующую строчку:

Для того, чтобы применить это правило до перезагрузки выполните:

Затем добавляем правило для NAT:

Где eth0 название вашего интерфейса через который выходите в интернет. Измените его если используете другой интерфейс (напрмер ppp0) тогда команда будет выглядит иначе:

Установите и запустите пакет для раздачи пакетов по сети:

Или, вы можете использовать DNS провайдера.

Чтобы NAT работал после перезагрузки сохраняем настройки iptables в файл:

И добавляем в конец файла:

Эту строчку, для автоматической подгрузки правил:

Также в этот файл добавляем правила роутинга:

Источник

Шлюз+шейпер для домашней сети на 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

После этих действий нужно «опустить» а потом снова «поднять» сетевой интерфейс eth1
sudo ifonfig eth1 down
sudo ifonfig eth1 up

После чего клиенты смогут получать IP адреса и пользоваться инетом )))
А теперь мы настроим шейпер, в принципе для этого все и задумывалось, для того что бы динамически делить скорость инета.
Я выбрал для шейпера скрипт htb.init который можно скачать тут sourceforge.net/projects/htbinit
sudo 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. Автор статьи теперь пользователь хабра — KTATTOO.

Источник

Программный интернет шлюз для уже не маленькой компании (Shorewall, OpenVPN, OSPF). Часть 1

Представляю пока две статьи, ориентированных на «продолжающих» системных администраторов, для опытных я вряд ли открою что-то новое.
В этих статьях мы рассмотрим построение интернет шлюза на linux, позволяющего связать несколько офисов компании, и обеспечить ограниченный доступ в сеть, приоритезацию трафика (QoS) и простую балансировку нагрузки с резервированием канала между двумя провайдерами.
Конкретно в этой части:

• Простейшая настройка Shorewall
• Ужасно сложная настройка dnsmasq
• Не менее сложная настройка OpenVPN
• И для многих продолжающих админов нетипичная, динамическая маршрутизация, на примере OSPF

А во второй части будут рассмотрены:

• Более подробная настройка Shorewall
• Страшный и не понятный QoS
• Балансировка нагрузки и резервирование

В третьей части:

• QoS во всю ширь в Shorewall
• Более подробная настройка Shorewall
• Раскидывание трафика по каналам в соответствии с протоколами
• Костыли, без них, никуда

В четвертой части:

• Автоматические события
• Макросы

Все описанное ниже справедливо для CentOS 7.1 (и выше, 6 серия тоже подойдет, но с небольшими особенностями)

Исходим из того, что у нас:

• Локалка первого филиала: 172.16.0.0/23
• Подсеть OpenVPN первого филиала: 172.16.3.0/25
• Второй филиал соответственно: 172.16.8.0/23 и 172.16.11.0/25

Вообще мой ip план подразумевал резервацию /21 сети для каждого филиала из диапазона 172.16.0.0/12. Каждый диапазон /21 нарезается на подсети для различных нужд (подробнее в следующей статье).

Простейшая настройка Shorewall

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

В Shorewall все вертится вокруг понятия «зона». В зону включаются хосты (путем задания интерфейсов или непосредственно сетей и/или отдельных адресов).

Ключевые слова значат следующие:

• ACCEPT — принимать (в том числе форвардить) пакеты
• REJECT — Отбросить пакет, а отправителю сообщить, что писем мы от него не ждем
• DROP — Отбросить пакет, и загадочно осмотревшись, никому ничего не сказать

В третий столбец можно прописать еще несколько параметров, один из которых info, задаст логирование данной политики (имеет смысл для DROP и REJECT, а то ACCEPT завалит вас логами).

Заданная политика примитивна и не годится для серьезных проектов, соответствует настройке большинства домашних роутеров, но для самого старта она нам подойдет.
Осталось чуть чуть, а именно настроить маскарадинг (чего в эпоху IPv6 делать будет не надо):

Очевидно, все что идет в сторону интерфейса $IF_RED1 из сети $NET_GRN нужно замаскировать. Третий столбец ADDRESS используется для SNAT.

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

Дав команду «systemctl enable shorewall.service && systemctl restart shorewall.service», мы применим настройки нашего файрвола, и у нас ничего (ну почти), не заработает, нам не хватает самой малости: нет кэширующего DNS И DHCP серверов (не будем же мы сами все клиентские машины настраивать).

Простейшая настройка dnsmasq

Эта служба очень неплохо справляется со своей задачей, и сеть /23 для неё не является проблемой, а простота и гибкость настроек делает её очень подходящей для нашей ситуации.
Так как файл настроек большой, приведу и его тоже в урезанном виде:

Думаю пояснять тут ничего особо не надо, задали интерфейс, на котором обслуживать DNS и DHCP запросы, задали диапазон раздаваемых адресов, задали некоторые передаваемые в DHCP параметры и задали авторитарный режим работы.
Теперь после «systemctl enable dnsmasq.service && systemctl restart dnsmasq.service» у нас заработает доступ в интернет с внутренних клиентов (как только аренду DHCP получат).

Настройка OpenVPN

Думаю это часть не составит особого труда вообще никому, но приведем эти шаги:

1. Из epel установим пакеты: openvpn easy-rsa
2. Скопируем из /usr/share/easy-rsa папку в /etc/openvpn и переименуем её в easy-rsa
3. Перейдем в /etc/openvpn/easy-rsa и при необходимости отредактируем файл vars
4. Выполним: «. ./vars && ./clean-all && ./build-dh && openvpn —genkey —secret ./keys/ta.key &&./build-ca && ./build-key-server server #привет от гентушника (как установить Gentoo одной командой, да и такое возможно)!

Еще нам понабиться файл конфигурации сервера:

Я использую интерфейс типа tap, потому, что tun маршрутизируется ядром OpenVPN, и конфигурируется это все директивой iroute. И печаль такова, если за одним сервером, будет еще один, к которому нам нужен маршрут, этот маршрут нам надо в явном виде прописывать в ccd, той самой директивой iroute, что помимо обычных маршрутов создаст лишние трудности (о каких трудностях я говорю, написано в разделе OSPF).

Теперь сгенерим конфигурацию для клиента:
./build-ovpn.sh -r
Создадим файл ccd для клиента:

После надо скопировать файл из каталога /etc/openvpn/ovpn/ / .ovpn на клиентский компьютер (шлюз) и поместить его в /etc/openvpn/ с расширением «.conf»
Запускаем openvpn на клиенте и сервере:

А результат есть только на сервере! Клиент в непонятках. Во всем виноват shorewall, а точнее, наша политика, мы не разрешили соединения из интернета (red зона)!
Внесем разрешающее правило в файл:

Выполняем «shorewall restart» и видим, что клиент успешно подключился.
Попробуем попинговать ip клиента, выданный OpenVPN, все Ok. Теперь сеть за клиентом (172.16.8.0/23), и опять облом, ip в туннеле пингуется, а сеть нет, так как нет маршрутов, их нам и предоставит OSPF.

Настройка протокола динамической маршрутизации OSPF в quagga

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

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

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

Теперь нам понабиться настроить ip адрес на loopback интерфейсе, который помимо прочего (смысл вы найдете в других статьях), будет выполнять роль router-id.
В файл /etc/sysconfig/network-scripts/ifcfg-lo добавим строки:

И повторно подымим интерфейс: ifup lo
Теперь подключимся к службе ospfd и проведем её настройку:

Итоговый файл конфигурации:

Скопировав этот файл на другой шлюз (который связан с этим по OpenVPN) и внеся туда соответствующие правки, мы получим рабочую конфигурацию между двумя шлюзами (службу ospfd на втором шлюзе тоже надо запустить).
Теперь команда «ip route list» должна показать нам нечто подобное:

Маршруты с «proto zebra» как раз добавлены с помощью OSPF.

Я рекомендую всем, используйте динамическую маршрутизацию, даже если у вас всего два филиала. Когда их станет больше, вам не составит труда добавить еще один узел в сеть.
И конечно, предложенная конфигурация OSPF довольна примитивна, более сложные варианты с примерами ждите в следующей статье (или читайте статьи более компетентных товарищей, по сути, OSPF я изучил еще не достаточно глубоко).

Источник