Готовое решение интернет шлюз linux

Программный интернет-шлюз для небольшой организации

Любой бизнесмен стремится к сокращению расходов. То же самое касается и IT-инфраструктуры.

При открытии нового офиса у кого-то начинают шевелиться волосы. Ведь надо организовать:

локальную сеть;
выход в интернет. Лучше ещё с резервированием через второго провайдера;
VPN до центрального офиса (или до всех филиалов);
HotSpot для клиентов с авторизацией по sms;
фильтрацию трафика так, чтобы сотрудники не сидели в соцсетях и не трещали в скайпе;
защиту сеть от вирусов и атак. Обеспечить защиту от вторжений (IDS/IPS);
свой почтовый сервер (если не доверяете всяким pdd.yandex.ru) с антивирусом и антиспамом;
файловую помойку;
Вероятно Вам нужна телефония, т.е. организовать АТС, подключить к SIP провайдеру и другие плюшки.

Но поднять сеть предприятия с такими требованиями эникейщик не сможет… Нанимать дорогого сисадмина?
Вырисовывается очень крупное, по грядущим затратам, рублёвое число.

Но эти расходы можно существенно сократить, если обратить внимание на UTM-решения, которых сейчас огромное количество. А так как я придерживаюсь стратегии «чем проще — тем лучше» в решениях своих задач, то мой взор пал на UTM Интернет Контроль Сервер (ИКС).

Чем эта система поможет сохранить бюджет компании и почему для её обслуживания не нужен дорогой сисадмин — расскажу ниже.

Но забегая вперёд скажу — это специфический продукт и имеет свои ограничения. Более детально оценить возможности шлюза можно изучив документацию на оф.сайте.
Я же настраивал для статьи «по-русски», то есть не заглядывая в маны, чтобы понять на сколько всё интуитивно понятно.

Начальная установка

ИКС можно установить как на реальное железо, так в гипервизор. Можно задействовать какой-нибудь безвентиляторный ПК.

Система базируется на FreeBSD 11.3 и на большинстве оборудования должно взлететь без проблем.

Установка производится на чистый диск.

Всё! Можно заходить в вэб-интерфес по ip, который указали в настройках, и порту 81. DHCP на этом этапе пока не включен, поэтому на своём ПК придётся назначить ip из этой же сети вручную.

Подключаем к интернету и соединяем офисы.

Далее лезем в настройки сети

и настраиваем подключение к нашему провайдеру и роли всех сетевых интерфейсов.

Провайдеров можно настроить несколько и организовать балансировку.

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

Если требуется подключить офис, например, к головному офису.

Только о динамической маршрутизации можете забыть — её тут нет.
Может я сильно придираюсь, но ИМХО это большой недостаток…

Доступ в интернет сотрудников

Чаще всего основная задача шлюза — контроль доступа сотрудников в интернет.
Идентифицировать сотрудников можно как по ip/mac, так и по логину/паролю через агента или captive portal.

Также если в Вашей организации используется Active Directory, то ИКС можно интегрировать и с ним.

Настройки фильтрации (куда сотруднику можно и куда нельзя) очень обширны.

Огромное количество готовых шаблонов правил:

Но можно не ограничивать и ИКС всё равно расскажет куда кто и куда ходил своими обширными отчётами:

А как же гостевой Wi-Fi?

И гостевой вай-фай можно организовать с соблюдением требования законов РФ об обязательной идентификации пользователей.
ИКС поддерживает отправку смс по протоколу SMPP через любого SMS-провайдера.

Телефония.

Да-да! Не надо ставить отдельный сервер с Asterisk. Он уже есть в ИКС.
Я успешно подключил SIP от Мегафона (emotion, мультифон).

Как получить SIP от Мегафона по сотовым тарифам физлиц можно почитать в статье «SIP от Мегафона по домашнему тарифу».

Безопасность.

В ИКС есть много инструментов, которые позволят настроить уровень безопасности по Вашим требованиям: от бесплатных антивирусов ClamAV и систем обнаружение вторжений Suricata до продуктов Евгения Касперского, настраивая только через понятны вэб-интерфейс.

Даже тот же незаменимый fail2Ban настраивается в несколько кликов

Так же ИКС может мониторить трафик по netflow протоколу с сетевого оборудования, не пропуская через себя трафик.

Коммуникационные плюшки

Коммуникацию сотрудников можно организовать не только телефонией и почтой

но и через jabber. Правда мало уже кто помнит о таком протоколе.

Web-server:
На ИКС есть даже web-server c поддержкой PHP. HTTPS сертификат можно установить свой, если есть приобретённый, или указать, чтобы ИКС получил бесплатный Let’s Encrypt.

Этого достаточно для размещения сайта-визитки или рекламного лендинга. Но впилить тяжёлый портал с кастомными модулями у Вас не выйдет. И по мне — это глупо. Всё-таки шлюз должен оставаться шлюзом.

Гибкая настройка мониторинга и уведомлений.
Алярмы можно слать даже в Телеграм. А в реалиях РФ есть даже возможность слать сообщения через прокси.

В заключение

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

Несмотря на то, что система построена ни FreeBSD, доступа по ssh к нему нет. То есть без костылей доустановить модули PHP у Вас не получится. Придётся довольствоваться тем, что есть… Или просить саппорт допилить.

При любом раскладе в начале скачайте триал на 35 дней и проверьте на сколько этот шлюз Вам подходит.

Лицензия не имеет срока действия, но несмотря на это стоимость является вполне демократичной.

На стенде в синтетических тестах система показала себя адекватно.

Если заказчик одобрит и Вам будет интересно как данная система поведёт себя в «бою», то месяцев через 3-6 напишу отзыв со всеми возникшими задачами и сложностями. Если получится, то проверим качество технической поддержки.

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

Источник

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

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

Из epel установим пакеты: openvpn easy-rsa
Скопируем из /usr/share/easy-rsa папку в /etc/openvpn и переименуем её в easy-rsa
Перейдем в /etc/openvpn/easy-rsa и при необходимости отредактируем файл vars
Выполним: «. ./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 я изучил еще не достаточно глубоко).

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