Интернет шлюз на linux с web интерфейсом бесплатно

Программный интернет шлюз для уже не маленькой компании (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 я изучил еще не достаточно глубоко).

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

Источник

Пошаговая настройка роутера на Debian

Ранее я уже рассматривал настройку программных роутеров на операционных системах freebsd и centos. Сегодня я хочу настроить интернет шлюз для локальной сети на основе популярного linux дистрибутива Debian. Выполним подготовку сервера и реализуем основной функционал, необходимый для выхода в интернет из локальной сети.

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

Введение

Я буду работать со следующим сервером:

Если у вас еще нет готового сервера, то рекомендую статью на тему установки debian. Там подробно описан весь процесс от и до.

На сервере имеются 2 сетевых интерфейса:

Файл конфигурации сетевых интерфейсов выглядит следующим образом:

Как настроить сеть в debian я подробно рассказал отдельно. Если вы еще не сделали это и не выполнили предварительную настройку debian, то рекомендую ознакомиться с материалами.

Если у вас недостаточно опыта и вы не чувствуете в себе сил разобраться с настройкой шлюза самому с помощью консоли сервера — попробуйте дистрибутив на основе centos для организации шлюза и прокси сервера в локальной сети — clearos. С его помощью можно через браузер настроить весь необходимый функционал. В отдельной статье я подробно рассказал об установке clearos.

Подготовка шлюза

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

Сеть на будущем программном роутере настроили, доступ в интернет на сервере есть. Обновим его:

Установим MC, мне в нем удобнее всего работать, в том числе в редакторе mcedit:

Настроим часовой пояс, если раньше не сделали это:

Устанавливаем сервис ntp для автоматического обновления времени:

На этом основные подготовительные действия закончены. Приступаем к настройке шлюза.

Настройка маршрутизации, firewall и nat

Первым делом включим маршрутизацию пакетов между сетевыми интерфейсами. Для этого редактируем конфиг /etc/sysctl.conf:

Либо раскомментируйте эту строку, либо добавьте, если ее нет. Но она по-умолчанию быть должна, закомментированная со значением 1. Применяем эту настройку:

На выходе работы команды в консоли будет выведен измененный параметр со значением 1.

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

Я приведу здесь сразу готовый вариант файла с правилами iptables, необходимых для работы интернет шлюза в debian. В файле даны подробные комментарии ко всем значениям, так что вы без проблем разберетесь и закомментируете или наоборот раскомментируете необходимые вам значения. Качаем скрипт правил iptables — iptables-debian.sh

Копируем содержимое файла и создаем скрипт с правилами на сервере:

Вставляем в редактор правила. Редактируем их под свои нужды, обязательно заменяя переменные WAN и LAN на свои. Сохраняем файл.

Делаем файл с правилами исполняемым:

Прежде чем применить новые правила, посмотрим на текущие:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

Источник