[IT-инфраструктура, *nix] WireGuard без NAT, внутренняя сеть и клиенты с обратной связью
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Приветствую, уважаемые читатели. В этой статье, я хотел бы рассказать о своем опыте постройки внутренней сети не привязанной к офисному оборудованию и функционирующий при единственном условии, что доступен интернет. С добавлением в настройки vpn сервера возможности обратной связи к клиенту и управлением доступа в сеть для каждого клиента. И управлять всем этим из одного места через веб интерфейс или удобный GUI.
Существует много разных программ предоставляющих vpn соединение клиент-сервер, как платные многофункциональные с разными возможностями, так и бесплатные. Но что если стоит задача реализовать комплекс функций, таких как:
- подключение клиента автоматически при загрузке ОС
- автоматически восстанавливать соединение при переключении между WiFi точками
- VPN клиент должен быть виден из офисной сети
- кросплатформенность vpn клиента и ПО для удаленного управления
- минимальное участие пользователя в настройках vpn клиента
- доступ клиента к хостам и подсетям ограничивается правилами ACL
- настройка клиентов и ACL из одного удобного GUI
- отказоустойчивость VPN серверов
Как дополнение
- логирование (минимум Layer 3)
- передавать логи в поисковую систему (например ELK стек)
Наблюдая за повседневными тяжбами тех. поддержки удаленного администрирования клиентов, уже давно зрела мысль сделать сотрудников работающих удаленно и внутреннюю инфраструктуру как одно целое и легко управляемое. В условиях, когда все больше сотрудников переходят на удаленную работу, это все больше становится актуально.
Присматривался и тестировал ПО с которым можно было построить такой монолит. Нужно было что-то, что имеет минимум настроек и параметров с возможностью быстро восстановить работоспособность. После долгих поисков, для реализации задачи пришел к определенному набору ПО.
За основу, где будет развернут vpn сервер была выбрана ОС Ubuntu 18.04.5 LTS.
Для vpn сервера был выбран WireGuard, всем характеристикам он соответствует. Он легковесный, имеет минимум настроек. Клиентская часть запускается при старте ОС, сама поднимает канал и кросплатформенная. Работает через udp протокол. При шифровании канала потеря скорости всего в районе 20%.
В качестве firewall был выбран iptables и его управление через ПО Shorewall. Даже первоначальные настройки Shorewall не вызвали никаких затруднений и в работе он легок для восприятия.
Удаленное управление пользователями в ОС Windows было осуществлено через TightVNC, msi файл которой можно пере собрать по своему усмотрению. Серверная часть ПО не прожорливая, служба не падает, передает только jpeg скриншеты и управление клавиатурой/мышкой. Защищена паролем на подключение и администрирование. Для других ОС есть разные реализации серверной части VNC.
Управление настройками, добавление настроек/клиентов было реализовано через развернутый в инфраструктуре GitLab и CI Pipelines. Все редактирование/создание файлов можно осуществлять через веб интерфейс не используя команду git которую не до конца могут понимать коллеги из поддержки. К тому-же через веб интерфейс визуально будет понятнее.
Сбор логов был реализован через Fluentd и/или Filebeat и все отправлялось в Elasticsearch.
С небольшой вводной закончил, далее будет расписано как все собрать с небольшими пояснениями. Все ссылки будут в конце статьи.
Устанавливаем wireguard на Ubuntu 18.04.5 LTS
Установка ПО для различных ОС есть на официальном сайте.
Ubuntu ≥ 18.04
sudo apt install wireguard
Настройка сервера.
Генерируем публичный и приватный ключи.
Запускаем
wg genkey | sudo tee /etc/wireguard/privatekey | wg pubkey | sudo tee /etc/wireguard/publickey
Все ключи лежат /etc/wireguard/
Создаем файл wg0.conf
sudo nano /etc/wireguard/wg0.conf
Собираем конфигурационный файл
[Interface]
Address = 192.168.30.1/24 <- выбираем любой диапазон
SaveConfig = true
ListenPort = 5505 <- выбираем любой порт
PrivateKey = SERVER_PRIVATE_KEY
Во многих мануалах еще добавляют 2 строчки:
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
Последние строчки PostUp и PostDown верны если вы хотите клиента спрятать за NAT. В таком случае все клиенты при подключении будут иметь ip адрес внутреннего сетевого интерфейса сервера, но нам это не нужно, поэтому мы их не добавляем.
Перед включением интерфейса wg0, разрешим серверу пересылать пакеты вперед.
Добавим ip_forward
sudo nano /etc/sysctl.conf
# ищем строку и убираем комментарий
net.ipv4.ip_forward=1
Возможно после этих настроек сервер нужно будет перезагрузить, если не будет пинговаться ip wireguard.
Сохраняем изменения
sudo sysctl -p
Отключаем ufw
systemctl disable ufw
В iptables сбросим все цепочки правил и пропустим весь трафик
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
Проверяем, запустим службу
sudo wg-quick up wg0
Проверим статус
sudo wg
Добавляем wg на запуск при загрузке
sudo systemctl enable wg-quick@wg0
Сделаем копию файла wg0.conf в этой же папке /etc/wireguard/
cp /etc/wireguard/wg0.conf /etc/wireguard/wg0.sempl
Важно чтобы в копии были настройки именно [Interface].
Создадим несколько папок где нибудь в /opt
mkdir /opt/git
mkdir /opt/git/wg
Скопируем wg0.conf в /opt/git/wg и сделаем ссылку на файл
cp /etc/wireguard/wg0.conf /opt/git/wg/wg0.conf
ln -sf /opt/git/wg/wg0.conf /etc/wireguard/wg0.conf
Для чего последние действия нужны? Скопировав настройки интерфейса в файл wg0.sempl мы вынесли приватный ключ сервера в отдельный файл, при написании CI в .gitlab-ci.yml мы будем это учитывать. Перенесли конфиг в папку /opt/git/wg и сделали ссылку для того, чтобы с последствии собирать целый конфигурационный файл в папке отличной от /etc/wireguard. Сам конфигурационный файл будет собираться из 2 частей, часть с настройками [Interface] и часть с [Peer] клиентов, которые будут добавляться из gitlab.
Настраиваем пограничный маршрутизатор пропускать входящие подключения по порту udp: 5505 на наш сервер. Так-же не забываем указать статический маршрут подсети 192.168.30.0/24 на внутренний сетевой интерфейс нашего сервера. При поднятии интерфейса wg0.conf адрес 192.168.30.1 должен пинговаться с любого хоста в нашей внутренней подсети, если не пингуется советую на этом моменте остановится и решить этот вопрос. Проверьте правила фаервола на маршрутизаторе. Чтобы подсеть 192.168.30.0/24 заработала через ipsec достаточно эту подсеть добавить во 2 фазу политики локальных, а с другой стороны удаленных адресов.
Что мы должны передавать клиенту после всех настроек? Создадим шаблон
Address = 192.168.30.X/24
DNS = 10.15.1.10, 10.16.1.252
[Peer]
PublicKey = <server_public_key>
AllowedIPs = 0.0.0.0/0
Endpoint = 1.2.3.4:5505
Если в AllowedIPs указать 0.0.0.0/0, то мы завернем интернет трафик клиента через VPN. Можно указавать диапазон внутренних подсетей.
На данный момент никаких клиентов и никаких подключений с наружи нам не нужно.
Вступление есть, продолжаем.
Устанавливаем и настраиваем Shorewall
Установка shorewall
apt update
apt install -y shorewall
После установки нужно добавить параметры в файл shorewall.conf и создать несколько файлов с переменными и дополнительными параметрами. Большой мануал есть на официальном сайте.
Начнем по порядку, изменим некоторые параметры shorewall.conf
nano /etc/shorewall/shorewall.conf
STARTUP_ENABLED=Yes
LOG_LEVEL="info(tcp_options,tcp_sequence,macdecode,ip_options)"
BLACKLIST_LOG_LEVEL="$LOG_LEVEL"
INVALID_LOG_LEVEL="$LOG_LEVEL"
LOG_MARTIANS=Yes
LOG_VERBOSITY=2
LOGALLNEW="$LOG_LEVEL"
LOGFILE=/opt/logs/shorewall/firewall.log
LOGFORMAT="ip-tables %s %s "
LOGTAGONLY=No
Создадим несколько папок в /opt и перенесем логирование. В LOGFORMAT добавляем префикс по которому будем фильтровать системные сообщения от iptables и складировать в /opt/logs/shorewall/firewall.log.
mkdir /opt/logs
mkdir /opt/logs/shorewall
touch /opt/logs/shorewall/firewall.log
Сделаем сразу фильтр системных сообщений от iptables. Создаем правило и добавим фильтр по нашему префиксу ip-tables
nano /etc/rsyslog.d/10-my_iptables.conf
# Log kernel generated iptables log messages to file
:msg,contains,"ip-tables" /opt/logs/shorewall/firewall.log
& ~
Если в файл логи не будут записываться, добавьте прав на файл/папку. Не забудьте настроить ротацию лога.
Перезапустим службу
service rsyslog restart
Продолжаем настройку shorewall и создадим несколько файлов.
Создаем файл interfaces, в нем запишем переменные для наших интерфейсов и опции
nano /etc/shorewall/interfaces
?FORMAT 2
###############################################################################
#ZONE INTERFACE OPTIONS
lan eth0 tcpflags,nosmurfs,routefilter,logmartians
wg wg0 tcpflags,nosmurfs,routefilter,logmartians
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
Создадим файл с переменными подсетей и хостов и запишем все наши подсети и важные сервера в сети
nano /etc/shorewall/params.mgmt
# protocols
ALL_T_U=tcp,udp
# all services, networks and subnets
AD_DS=10.15.1.10,10.17.2.2
IPA=10.16.1.252
DNS_INT=10.15.1.10,10.16.1.252,192.168.0.253
KASPER=10.15.1.55
####
NET_OFFICE=10.15.1.0/24
NET_OFFICE_PRINTERS=10.15.14.0/24
##
NET_CLOUD_PROD=172.16.0.0/20,172.16.16.0/20,172.16.32.0/20
NET_CLOUD_DEV=192.168.128.0/24,192.168.1.0/24
####
VPN_01=192.168.30.0/24
VPN_02=192.168.40.0/24
####
ADM_IP=10.17.1.9
ADM_IP_VPN=192.168.30.3,192.168.40.3
VNC_SERVERS=10.15.1.10
###END###
Здесь нет ограничений на переменные, мы расписали все внутренние подсети, добавили контроллер домена, free ipa, внутренние DNS, подсети VPN, и административные ip адреса, добавили группу протоколов.
Добавим этот файл в общие настройки
nano /etc/shorewall/params
INCLUDE params.mgmt
Напишем политику и правила которые будут работать по умолчанию.
nano /etc/shorewall/policy
##
#SOURCE DEST POLICY LOGLEVEL LIMIT
$FW lan ACCEPT $LOG_LEVEL
$FW wg DROP $LOG_LEVEL
wg $FW DROP $LOG_LEVEL
# THE FOLOWING POLICY MUST BE LAST
all all REJECT $LOG_LEVEL
##
В данном примере логируются все соединения. Переменная $FW обозначает сам фаервол, т.е. любое соединение от любого интерфейса направленного на wg будет сброшено. Эти правила применяются последними.
Создадим файл и сделаем описания типа переменных
nano /etc/shorewall/zones
###############################################################################
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
FW firewall
lan ipv4
wg ipv4
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
Самый большой файл получается с сервисами, создадим его и заполним
nano /etc/shorewall/services.mgmt
# add default rules for all connections
# AD DS & LDAP
ACCEPT lan:$AD_DS wg $ALL_T_U 42
ACCEPT wg lan:$AD_DS $ALL_T_U 42
ACCEPT lan:$AD_DS wg $ALL_T_U 88
ACCEPT wg lan:$AD_DS $ALL_T_U 88
ACCEPT lan:$AD_DS wg $ALL_T_U 135
ACCEPT wg lan:$AD_DS $ALL_T_U 135
.....
# Free IPA ports
ACCEPT lan:$IPA wg $ALL_T_U 88
.....
# internal DNS
ACCEPT lan:$DNS_INT wg $ALL_T_U 53
ACCEPT wg lan:$DNS_INT $ALL_T_U 53
# kastersky
ACCEPT lan:$KASPER wg $ALL_T_U 13000
ACCEPT wg lan:$KASPER $ALL_T_U 13000
.....
# admin all access
ACCEPT lan:$ADM_IP wg
ACCEPT wg:$ADM_IP_VPN wg
ACCEPT lan:$ADM_IP_VPN wg
# vnc
ACCEPT lan:$VNC_SERVERS wg tcp 7900
#
###END###
Расписываем все порты всех наших внутренних сервисов. Какие порты и какой протокол сервисом используются можно найти на официальном сейте каждого из сервисов.
Напишем правила по умолчанию для всех наших подсетей включая и подсети vpn сбрасывающих все соединения
nano /etc/shorewall/networks.mgmt
# drop internal networks to clients and from client
DROP lan:$NET_OFFICE wg
DROP lan:$NET_OFFICE_PRINTERS wg
DROP lan:$NET_CLOUD_PROD wg
DROP lan:$NET_CLOUD_DEV wg
DROP wg lan:$NET_OFFICE
DROP wg lan:$NET_OFFICE_PRINTERS
DROP wg lan:$NET_CLOUD_PROD
DROP wg lan:$NET_CLOUD_DEV
# wireguard networks
DROP lan:$VPN_01 wg
DROP lan:$VPN_02 wg
DROP wg lan:$VPN_01
DROP wg lan:$VPN_02
DROP wg:$VPN_01 wg
DROP wg:$VPN_02 wg
DROP wg wg:$VPN_01
DROP wg wg:$VPN_02
#
###END###
Остался практически самый послелний и самый главный файл с описанием всех правил и всех включений с определенным порядком, т.к. Shorewall поддерживает включение множества файлов из папки, для начала сделаем 2 папки в которых мы будем заполнять файлы для клиентов vpn с доступом ко внутренней сети/хостам и с доступом в интернет (да, будем выпускать пользователей в интернет через vpn)
Создаем 2 папки
mkdir /etc/shorewall/rules_internet.d
mkdir /etc/shorewall/rules_networks.d
В папках будем создавать файлы с расширением .rule, имя можно выбрать например <ip_username>, в итоге все файлы будут выглядеть по шаблону <ip_username>.rule. Создадим 2 файла для примера и потом перейдем к последнему основному файлу.
Разрешим доступ к интернету
nano /etc/shorewall/rules_internet.d/192.168.30.2_tst-client.rule
###########################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK
# PORT PORT(S) DEST LIMIT GROUP
ACCEPT wg:192.168.30.2 lan
#
###END###
Разрешим доступ к некоторым хостам из сети (так же можно комбинировать правила)
nano /etc/shorewall/rules_networks.d/192.168.30.2_tst-client.rule
###########################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK
# PORT PORT(S) DEST LIMIT GROUP
ACCEPT wg:192.168.30.2 lan:$NET_OFFICE
DROP wg:192.168.30.2 lan:10.15.1.69
ACCEPT wg:192.168.30.2 lan:10.16.1.252 tcp 80
#
###END###
После последнего правила не обязательно писать правило DROP, мы все соединения которые будут сбрасываться реализуем в файле rules.
Итак добавляем файл rules и вносим правила
nano /etc/shorewall/rules
###########################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK
# PORT PORT(S) DEST LIMIT GROUP
ACCEPT lan $FW
ACCEPT wg $FW icmp
ACCEPT wg $FW tcp 22
#
#####
# add services
INCLUDE services.mgmt
#
####
# add internal hosts/networks to clients
SHELL cat /etc/shorewall/rules_networks.d/*.rule
#
#####
# drop all internal networks to wireguard from clients and to clients
INCLUDE networks.mgmt
#
####
# add internet to clients
SHELL cat /etc/shorewall/rules_internet.d/*.rule
#
###END###
По порядку:
- разрешаем соединение сервисов к клиенту и от клиента
- разрешаем/запрещаем соединения к сетям/хостам
- запрещаем доступ ко всем внутренним подсетям и подсетям vpn
- разрешаем доступ в интернет (при наличии файла с правилом)
Структура файлов:
/etc/shorewall/
├── conntrack
├── interfaces
├── networks.mgmt
├── params
├── params.mgmt
├── policy
├── README.MD
├── rules
├── rules_internet.d
│ └── 192.168.30.2_tst-client.rule
├── rules_networks.d
│ └── 192.168.30.2_tst-client.rule
├── services.mgmt
├── shorewall.conf
└── zones
Применяем правила фаервола
shorewall reload
Во всей этой легкости написания правил доступа клиентов во внутреннюю сеть есть одно "но", shorewall сбрасывает цепочку правил и применяет новые только если увидит в корневой папке /etc/shorewall/ изменения хотя-бы в одном файле, т.е. изменения в папке rules_internet.d/rules_networks.d не изменят правил iptables. Мы учтем это когда будем собирать все в gitlab.
На этом этапе можно создать тестового пользователя и тестовое подключение через Wireguard, разрешить все правилами Shorewall и пингануть с любого хоста внутренней сети vpn клиента. Пинги должны проходить и к клиенту должен быть доступ по всем портам. Если vpn клиент не виден из внутренней сети, значит не добавили правила маршрутизации или есть ограничения фаервола как на vpn сервере, так и на маршрутизаторе. Все vpn скиенты должны быть доступны с административных ip адресов, которые мы указывали в переменной ADM_IP и ADM_IP_VPN.
Предлагаю на этом не останавливаться и продолжить, осталось немного :)
Реализация VPN доступа через CI Pipelines в GitLab
Допустим у нас уже есть selfhosted gitlab для внутреннего использования, если нет то его не так сложно развернуть через тот-же docker-compose.
Для начала создадим новую группу и новый проект, создадим репозиторий vpn-01 и создадим следующую структуру
vpn-01
├── .gitlab-ci.yml
├── README.md
├── shorewall
│ ├── networks.mgmt
│ ├── params.mgmt
│ ├── README.MD
│ ├── rules_internet.d
│ │ └── 192.168.30.2_tst-client.rule
│ ├── rules_networks.d
│ │ └── 192.168.30.2_tst-client.rule
│ └── services.mgmt
└── wireguard
├── README.MD
└── wg0.conf
Переносим настройки описанные ранее во все файлы в папке shorewall на gitlab. В README.MD можно вести учет пользователей, написать мануал для суппорта.
В файле wg0.conf будут записи только клиентов. Добавляем одного клиента
[Peer]
PublicKey = <client_public_key>
AllowedIPs = 192.168.30.2/32
Всё, настройки shorewall перенесли и добавили 1 клиента. Далее настраиваем gitlab-runner, Deploy Token с правами read_repository и заполняем .gitlab-ci.yml.
Устанавливаем gitlab-runner на vpn сервере
apt install gitlab-runner -y
на сайте в настройках репозитория берем token Settings -> CI/CD -> Runners и регестрируем
sudo gitlab-runner register
указываем url сайта, вставляем токен, указываем executor: shell и не забываем поставить tag: vpn-01, если даже где-то ошиблись конфигурацию можно поправить /etc/gitlab-runner/config.toml.
Создадим deploy token, заходим в настройки репозитория Settings -> Repository -> Deploy Tokens создаем с правами read_repository
На vpn сервере добавим права для gitlab-runner и добавим в sudo
#1
sudo usermod -a -G sudo gitlab-runner
#2
nano /etc/sudoers.d/gitlab-runner
#3
gitlab-runner ALL=(ALL) NOPASSWD:/usr/bin/wg-quick,/usr/bin/git,/sbin/shorewall,/bin/cp,/bin/rm,/bin/cat,/bin/touch,/bin/chmod
Добавим побольше прав для папки /opt/git/
Переходим в репозиторий и открываем файл .gitlab-ci.yml на редактирование и вставляем следующие строчки
stages:
- all
task-all:
stage: all
script:
- sudo /bin/cp -f /etc/wireguard/wg0.sempl /opt/git/wg/wg0.conf
- sudo /usr/bin/wg-quick up wg0 || if [ $? -ne 0 ]; then echo "wg0 is up"; fi
- sudo /usr/bin/wg-quick down wg0
- sudo /bin/rm -rf /opt/git/vpn-01
- cd /opt/git
- sudo /usr/bin/git clone https://gitlab+deploy-token:<token>@gitlab.company.net/infra/vpn-01.git
- sudo /bin/rm -rf /etc/shorewall/rules_networks.d/*
- sudo /bin/rm -rf /etc/shorewall/rules_internet.d/*
- sudo /bin/cp -rf /opt/git/wgvpn-02/shorewall/* /etc/shorewall/
- sudo /bin/rm -rf /opt/git/wg/wg0.conf
- sudo /bin/cp /etc/wireguard/wg0.sempl /opt/git/wg/wg0.conf
- sudo /bin/chmod 0666 /opt/git/wg/wg0.conf
- sudo /bin/cat /opt/git/vpn-01/wireguard/wg0.conf >> /opt/git/wg/wg0.conf
- sudo /usr/bin/wg-quick up wg0
- sudo /sbin/shorewall reload
- sudo /usr/bin/wg-quick down wg0
- sleep 60 && sudo /usr/bin/wg-quick up wg0
tags:
- 'vpn-01'
allow_failure: true
when: manual
Запускаем скрипт с последовательными командами:
- копируем шаблон конфигурации wg0, в отсутствии файла wg0.conf запущенный/выключенный интерфейс нельзя выключить или включить
- запускаем интерфейс и добавляем условие вывода сообщения, что-бы при ошибке команды продолжали выполнятся
- новые настройки интерфейса применяются только когда интерфейс wg0 выключен, тогда можно редактировать файл wg0.conf
- удаляем папку vpn-01 и сразу клонируем свежию копию репозитория
- очищаем папки с правилами доступа клиентов и копируем новые вместе с новыми файлами сервисов и переменных, вот здесь при перезапуске правил shorewall увидит измененные файлы и запустит очистку всех правил и потом применит новые
- собираем wg0.conf из 2 частей, копируем часть настроек интерфейса с приватным ключем сервера и в конец файла вставляем список клиентов, тем самым делая файл полной конфигурации
- при выключеном интерфейсе wg0 правила shorewall не смогут применится, поэтому включаем, применяем правила и выключаем интерфейс wg0
- выключаем на 60 секунд, чтобы точно разорвать все установленные соединения, потому-что если есть правило ACCEPT и мы его убираем, то при применении правил без разрыва всех соединений канал клиента с сервером останется и доступ тоже
Запускаем CI/CD -> Pipelines, смотрим последний Commit и запускаем.
Не забываем выдать права кому на Merge Requests, а кому на Pull Requests.
На этом этапе мы уже полностью реализовали задуманное, но нужно идти до конца)
Сбор логов
Допустим по счастливай случайности так оказалось, что в нашей сети есть не только GitLab, но и Elasticsearch с Kibana. Реализуем пересылку и хранение логов в Elasticsearch.
Для начала на vpn сервере исправим значение на открытие файлов
nano /etc/security/limits.conf
root soft nofile 65536
root hard nofile 65536
* soft nofile 65536
* hard nofile 65536
После этого нужно будет перезагрузится
Устанавливаем на vpn сервер Fluentd
# td-agent 4
curl -L https://toolbelt.treasuredata.com/sh/install-ubuntu-bionic-td-agent4.sh | sh
Добавим строчки в /etc/td-agent/td-agent.conf или сделаем в отдельном файле (тогда нужно будет включить файл в основной конфигурации)
'<source>
@type tail
path /opt/logs/shorewall/firewall.log
pos_file /var/log/td-agent/pos-firewall.pos
<parse>
@type syslog
</parse>
tag firewall.raw
</source>
<match firewall.raw.**>
@type elasticsearch
host <server_ip>
port <server_port>
logstash_format true
logstash_prefix infra-vpn-01
flush_interval 10s
flush_thread_count 2
</match>
По сути наш лог относится к syslog, поэтому мы его просматриваем и разбираем как syslog
Смотрим в кибану на результат
Только перед этим не забываем добавить новые шаблоны индексов.
С Filebeat все еще проще. Устанавливаем на сервер.
#1
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
#2
sudo apt-get install apt-transport-https
#3
sudo apt-get update && sudo apt-get install filebeat
#4
sudo systemctl enable filebeat
Включаем модуль iptables
filebeat modules enable iptables
Изменяем настройки в самом модуле
nano /etc/filebeat/modules.d/iptables.yml
- module: iptables
log:
enabled: true
var.input: "file"
var.paths: ["/opt/logs/shorewall/firewall.log"]
И в файле /etc/filebeat/filebeat.yml добавляем наш Elasticsearch сервер
output.elasticsearch:
hosts: ["<ip_address>:9200"]
На последок хотел затронуть тему оптимизации Elasticsearch или как заставить Elasticsearch прожевать 7000 шард на одной ноде и не поперхнуться при характеристиках сервера RAM — 10 Gb и vCPU — 6.
На эту тему есть много материала и везде пишут одинаково, в файле /etc/security/limits.conf выставляем лимиты, добавляем в /etc/elasticsearch/jvm.options значение -Xms чуть больше половины RAM.
И допустим в лимитах у нас стоит значение
elasticsearch - nofile 200000
elasticsearch memlock 200000
или даже так
* soft nofile 265536
* hard nofile 265536
и подкручен конфиг /etc/elasticsearch/elasticsearch.yml
cluster.max_shards_per_node: 15000
xpack.ml.max_open_jobs: 100
cluster.routing.allocation.node_initial_primaries_recoveries: 10
thread_pool.search.queue_size: 100000
thread_pool.search.max_queue_size: 150000
thread_pool.search.size: 35
thread_pool.search.auto_queue_frame_size: 10000
Но у нас все равно выскакивает индекс с ошибкой
"type" : "file_system_exception",
"reason" : "/mnt/elk/data/nodes/0/indices/SNMMbQeLRlW0y4Vi_V9L1Q/3/_state: Too many open files"
Тут дело в том что у службы свои лимиты и находятся они в /etc/systemd/system/elasticsearch.service.d/elasticsearch.conf или /etc/systemd/system/multi-user.target.wants/elasticsearch.service и здесь как раз накручиваем значения
LimitNOFILE=200000
LimitNPROC=4096
LimitAS=infinity
LimitFSIZE=infinity
Перезапускаем службу/сервер и смотрим как 7000 шард расфасуются за несколько десятков минут.
Вот в принципе и все чем я хотел с вами поделится, задача поставлена весь процесс написан и вы можете спросить так в чем отказоустойчивость? А она в том, что вас никто не ограничивает в выборе места разворачивания сервера и количества серверов, можно сделать несколько независимых точек входа на разные сервера и каждый будет со своей конфигурацией, что бы это было отказоустойчивым делайте пользователям сразу как минимум 2 конфигурации и все.
На этом, пожалуй, и закончу.
Всем спасибо за внимание!
Используемые источники:
WireGuard — https://www.wireguard.com
Shorewall — https://shorewall.org
TightVNC — https://www.tightvnc.com/download.php
GitLab runners — https://docs.gitlab.com/ee/ci/runners/
Linux firewall log format — http://www.stearns.org/doc/william_stearns_gcia.html#iptablesformat
Проверка регулярных выражений — https://rubular.com/
Fluentd — https://docs.fluentd.org/installation/before-install
Filebeat Iptables module — https://www.elastic.co/guide/en/beats/filebeat/master/filebeat-module-iptables.html
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-инфраструктура, Разработка под e-commerce, Хранение данных, Управление продажами] Умные кассы для «ВкусВилла»
- [IT-инфраструктура, Облачные сервисы, Научно-популярное, Kubernetes] Детям о Кубернете, или приключения Фиппи в космосе
- [IT-инфраструктура, Big Data, IT-компании] 25 петабайт данных: как устроена BigData в Почте России
- [IT-инфраструктура, DevOps, Микросервисы] Деплой на стороне разработчиков: как мы создавали Heroku для внутренних нужд
- [IT-инфраструктура, Сетевые технологии, Сетевое оборудование] Пьеса об СКС в трех действиях, или Как мы создавали систему из 70 тысяч оптических волокон
- [IT-инфраструктура, Управление продажами, Управление персоналом] ТОП-4 зависимости между KPI входящей линии контакт-центра, которые должен знать каждый руководитель
- [Open source, *nix] FOSS News №41 – дайджест новостей и других материалов о свободном и открытом ПО за 2-8 ноября 2020 года
- [Системное администрирование, IT-инфраструктура, Управление разработкой, DevOps] Как Лёха стал инженером по SRE: выдуманная история про невыдуманные проблемы
- [Open source, IT-инфраструктура, IT-компании] МТС выбрала OpenStack и Canonical для своей облачной инфраструктуры нового поколения
- [Системное администрирование, IT-инфраструктура, Серверное администрирование, DevOps] Распутывая Ansible Loops (перевод)
Теги для поиска: #_itinfrastruktura (IT-инфраструктура), #_*nix, #_wireguard, #_shorewall, #_vpnserver (vpn-сервер), #_logging, #_itinfrastruktura (
IT-инфраструктура
), #_*nix
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 20:14
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Приветствую, уважаемые читатели. В этой статье, я хотел бы рассказать о своем опыте постройки внутренней сети не привязанной к офисному оборудованию и функционирующий при единственном условии, что доступен интернет. С добавлением в настройки vpn сервера возможности обратной связи к клиенту и управлением доступа в сеть для каждого клиента. И управлять всем этим из одного места через веб интерфейс или удобный GUI.  Существует много разных программ предоставляющих vpn соединение клиент-сервер, как платные многофункциональные с разными возможностями, так и бесплатные. Но что если стоит задача реализовать комплекс функций, таких как:
Как дополнение
 Наблюдая за повседневными тяжбами тех. поддержки удаленного администрирования клиентов, уже давно зрела мысль сделать сотрудников работающих удаленно и внутреннюю инфраструктуру как одно целое и легко управляемое. В условиях, когда все больше сотрудников переходят на удаленную работу, это все больше становится актуально. Присматривался и тестировал ПО с которым можно было построить такой монолит. Нужно было что-то, что имеет минимум настроек и параметров с возможностью быстро восстановить работоспособность. После долгих поисков, для реализации задачи пришел к определенному набору ПО. За основу, где будет развернут vpn сервер была выбрана ОС Ubuntu 18.04.5 LTS. Для vpn сервера был выбран WireGuard, всем характеристикам он соответствует. Он легковесный, имеет минимум настроек. Клиентская часть запускается при старте ОС, сама поднимает канал и кросплатформенная. Работает через udp протокол. При шифровании канала потеря скорости всего в районе 20%. В качестве firewall был выбран iptables и его управление через ПО Shorewall. Даже первоначальные настройки Shorewall не вызвали никаких затруднений и в работе он легок для восприятия. Удаленное управление пользователями в ОС Windows было осуществлено через TightVNC, msi файл которой можно пере собрать по своему усмотрению. Серверная часть ПО не прожорливая, служба не падает, передает только jpeg скриншеты и управление клавиатурой/мышкой. Защищена паролем на подключение и администрирование. Для других ОС есть разные реализации серверной части VNC. Управление настройками, добавление настроек/клиентов было реализовано через развернутый в инфраструктуре GitLab и CI Pipelines. Все редактирование/создание файлов можно осуществлять через веб интерфейс не используя команду git которую не до конца могут понимать коллеги из поддержки. К тому-же через веб интерфейс визуально будет понятнее. Сбор логов был реализован через Fluentd и/или Filebeat и все отправлялось в Elasticsearch. С небольшой вводной закончил, далее будет расписано как все собрать с небольшими пояснениями. Все ссылки будут в конце статьи. Устанавливаем wireguard на Ubuntu 18.04.5 LTS Установка ПО для различных ОС есть на официальном сайте. Ubuntu ≥ 18.04 sudo apt install wireguard
Настройка сервера. Генерируем публичный и приватный ключи. Запускаем wg genkey | sudo tee /etc/wireguard/privatekey | wg pubkey | sudo tee /etc/wireguard/publickey
Все ключи лежат /etc/wireguard/ Создаем файл wg0.conf sudo nano /etc/wireguard/wg0.conf
Собираем конфигурационный файл [Interface]
Address = 192.168.30.1/24 <- выбираем любой диапазон SaveConfig = true ListenPort = 5505 <- выбираем любой порт PrivateKey = SERVER_PRIVATE_KEY Во многих мануалах еще добавляют 2 строчки: PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE Последние строчки PostUp и PostDown верны если вы хотите клиента спрятать за NAT. В таком случае все клиенты при подключении будут иметь ip адрес внутреннего сетевого интерфейса сервера, но нам это не нужно, поэтому мы их не добавляем. Перед включением интерфейса wg0, разрешим серверу пересылать пакеты вперед. Добавим ip_forward sudo nano /etc/sysctl.conf
# ищем строку и убираем комментарий net.ipv4.ip_forward=1 Возможно после этих настроек сервер нужно будет перезагрузить, если не будет пинговаться ip wireguard. Сохраняем изменения sudo sysctl -p
Отключаем ufw systemctl disable ufw
В iptables сбросим все цепочки правил и пропустим весь трафик iptables -F
iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT Проверяем, запустим службу sudo wg-quick up wg0
Проверим статус sudo wg
Добавляем wg на запуск при загрузке sudo systemctl enable wg-quick@wg0
Сделаем копию файла wg0.conf в этой же папке /etc/wireguard/ cp /etc/wireguard/wg0.conf /etc/wireguard/wg0.sempl
Важно чтобы в копии были настройки именно [Interface]. Создадим несколько папок где нибудь в /opt mkdir /opt/git
mkdir /opt/git/wg Скопируем wg0.conf в /opt/git/wg и сделаем ссылку на файл cp /etc/wireguard/wg0.conf /opt/git/wg/wg0.conf
ln -sf /opt/git/wg/wg0.conf /etc/wireguard/wg0.conf Для чего последние действия нужны? Скопировав настройки интерфейса в файл wg0.sempl мы вынесли приватный ключ сервера в отдельный файл, при написании CI в .gitlab-ci.yml мы будем это учитывать. Перенесли конфиг в папку /opt/git/wg и сделали ссылку для того, чтобы с последствии собирать целый конфигурационный файл в папке отличной от /etc/wireguard. Сам конфигурационный файл будет собираться из 2 частей, часть с настройками [Interface] и часть с [Peer] клиентов, которые будут добавляться из gitlab. Настраиваем пограничный маршрутизатор пропускать входящие подключения по порту udp: 5505 на наш сервер. Так-же не забываем указать статический маршрут подсети 192.168.30.0/24 на внутренний сетевой интерфейс нашего сервера. При поднятии интерфейса wg0.conf адрес 192.168.30.1 должен пинговаться с любого хоста в нашей внутренней подсети, если не пингуется советую на этом моменте остановится и решить этот вопрос. Проверьте правила фаервола на маршрутизаторе. Чтобы подсеть 192.168.30.0/24 заработала через ipsec достаточно эту подсеть добавить во 2 фазу политики локальных, а с другой стороны удаленных адресов. Что мы должны передавать клиенту после всех настроек? Создадим шаблон Address = 192.168.30.X/24
DNS = 10.15.1.10, 10.16.1.252 [Peer] PublicKey = <server_public_key> AllowedIPs = 0.0.0.0/0 Endpoint = 1.2.3.4:5505 Если в AllowedIPs указать 0.0.0.0/0, то мы завернем интернет трафик клиента через VPN. Можно указавать диапазон внутренних подсетей. На данный момент никаких клиентов и никаких подключений с наружи нам не нужно. Вступление есть, продолжаем. Устанавливаем и настраиваем Shorewall Установка shorewall apt update
apt install -y shorewall После установки нужно добавить параметры в файл shorewall.conf и создать несколько файлов с переменными и дополнительными параметрами. Большой мануал есть на официальном сайте. Начнем по порядку, изменим некоторые параметры shorewall.conf nano /etc/shorewall/shorewall.conf
STARTUP_ENABLED=Yes LOG_LEVEL="info(tcp_options,tcp_sequence,macdecode,ip_options)" BLACKLIST_LOG_LEVEL="$LOG_LEVEL" INVALID_LOG_LEVEL="$LOG_LEVEL" LOG_MARTIANS=Yes LOG_VERBOSITY=2 LOGALLNEW="$LOG_LEVEL" LOGFILE=/opt/logs/shorewall/firewall.log LOGFORMAT="ip-tables %s %s " LOGTAGONLY=No Создадим несколько папок в /opt и перенесем логирование. В LOGFORMAT добавляем префикс по которому будем фильтровать системные сообщения от iptables и складировать в /opt/logs/shorewall/firewall.log. mkdir /opt/logs
mkdir /opt/logs/shorewall touch /opt/logs/shorewall/firewall.log Сделаем сразу фильтр системных сообщений от iptables. Создаем правило и добавим фильтр по нашему префиксу ip-tables nano /etc/rsyslog.d/10-my_iptables.conf
# Log kernel generated iptables log messages to file :msg,contains,"ip-tables" /opt/logs/shorewall/firewall.log & ~ Если в файл логи не будут записываться, добавьте прав на файл/папку. Не забудьте настроить ротацию лога. Перезапустим службу service rsyslog restart
Продолжаем настройку shorewall и создадим несколько файлов. Создаем файл interfaces, в нем запишем переменные для наших интерфейсов и опции nano /etc/shorewall/interfaces
?FORMAT 2 ############################################################################### #ZONE INTERFACE OPTIONS lan eth0 tcpflags,nosmurfs,routefilter,logmartians wg wg0 tcpflags,nosmurfs,routefilter,logmartians #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE Создадим файл с переменными подсетей и хостов и запишем все наши подсети и важные сервера в сети nano /etc/shorewall/params.mgmt
# protocols ALL_T_U=tcp,udp # all services, networks and subnets AD_DS=10.15.1.10,10.17.2.2 IPA=10.16.1.252 DNS_INT=10.15.1.10,10.16.1.252,192.168.0.253 KASPER=10.15.1.55 #### NET_OFFICE=10.15.1.0/24 NET_OFFICE_PRINTERS=10.15.14.0/24 ## NET_CLOUD_PROD=172.16.0.0/20,172.16.16.0/20,172.16.32.0/20 NET_CLOUD_DEV=192.168.128.0/24,192.168.1.0/24 #### VPN_01=192.168.30.0/24 VPN_02=192.168.40.0/24 #### ADM_IP=10.17.1.9 ADM_IP_VPN=192.168.30.3,192.168.40.3 VNC_SERVERS=10.15.1.10 ###END### Здесь нет ограничений на переменные, мы расписали все внутренние подсети, добавили контроллер домена, free ipa, внутренние DNS, подсети VPN, и административные ip адреса, добавили группу протоколов. Добавим этот файл в общие настройки nano /etc/shorewall/params
INCLUDE params.mgmt Напишем политику и правила которые будут работать по умолчанию. nano /etc/shorewall/policy
## #SOURCE DEST POLICY LOGLEVEL LIMIT $FW lan ACCEPT $LOG_LEVEL $FW wg DROP $LOG_LEVEL wg $FW DROP $LOG_LEVEL # THE FOLOWING POLICY MUST BE LAST all all REJECT $LOG_LEVEL ## В данном примере логируются все соединения. Переменная $FW обозначает сам фаервол, т.е. любое соединение от любого интерфейса направленного на wg будет сброшено. Эти правила применяются последними. Создадим файл и сделаем описания типа переменных nano /etc/shorewall/zones
############################################################################### #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS FW firewall lan ipv4 wg ipv4 #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE Самый большой файл получается с сервисами, создадим его и заполним nano /etc/shorewall/services.mgmt
# add default rules for all connections # AD DS & LDAP ACCEPT lan:$AD_DS wg $ALL_T_U 42 ACCEPT wg lan:$AD_DS $ALL_T_U 42 ACCEPT lan:$AD_DS wg $ALL_T_U 88 ACCEPT wg lan:$AD_DS $ALL_T_U 88 ACCEPT lan:$AD_DS wg $ALL_T_U 135 ACCEPT wg lan:$AD_DS $ALL_T_U 135 ..... # Free IPA ports ACCEPT lan:$IPA wg $ALL_T_U 88 ..... # internal DNS ACCEPT lan:$DNS_INT wg $ALL_T_U 53 ACCEPT wg lan:$DNS_INT $ALL_T_U 53 # kastersky ACCEPT lan:$KASPER wg $ALL_T_U 13000 ACCEPT wg lan:$KASPER $ALL_T_U 13000 ..... # admin all access ACCEPT lan:$ADM_IP wg ACCEPT wg:$ADM_IP_VPN wg ACCEPT lan:$ADM_IP_VPN wg # vnc ACCEPT lan:$VNC_SERVERS wg tcp 7900 # ###END### Расписываем все порты всех наших внутренних сервисов. Какие порты и какой протокол сервисом используются можно найти на официальном сейте каждого из сервисов. Напишем правила по умолчанию для всех наших подсетей включая и подсети vpn сбрасывающих все соединения nano /etc/shorewall/networks.mgmt
# drop internal networks to clients and from client DROP lan:$NET_OFFICE wg DROP lan:$NET_OFFICE_PRINTERS wg DROP lan:$NET_CLOUD_PROD wg DROP lan:$NET_CLOUD_DEV wg DROP wg lan:$NET_OFFICE DROP wg lan:$NET_OFFICE_PRINTERS DROP wg lan:$NET_CLOUD_PROD DROP wg lan:$NET_CLOUD_DEV # wireguard networks DROP lan:$VPN_01 wg DROP lan:$VPN_02 wg DROP wg lan:$VPN_01 DROP wg lan:$VPN_02 DROP wg:$VPN_01 wg DROP wg:$VPN_02 wg DROP wg wg:$VPN_01 DROP wg wg:$VPN_02 # ###END### Остался практически самый послелний и самый главный файл с описанием всех правил и всех включений с определенным порядком, т.к. Shorewall поддерживает включение множества файлов из папки, для начала сделаем 2 папки в которых мы будем заполнять файлы для клиентов vpn с доступом ко внутренней сети/хостам и с доступом в интернет (да, будем выпускать пользователей в интернет через vpn) Создаем 2 папки mkdir /etc/shorewall/rules_internet.d
mkdir /etc/shorewall/rules_networks.d В папках будем создавать файлы с расширением .rule, имя можно выбрать например <ip_username>, в итоге все файлы будут выглядеть по шаблону <ip_username>.rule. Создадим 2 файла для примера и потом перейдем к последнему основному файлу. Разрешим доступ к интернету nano /etc/shorewall/rules_internet.d/192.168.30.2_tst-client.rule
########################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK # PORT PORT(S) DEST LIMIT GROUP ACCEPT wg:192.168.30.2 lan # ###END### Разрешим доступ к некоторым хостам из сети (так же можно комбинировать правила) nano /etc/shorewall/rules_networks.d/192.168.30.2_tst-client.rule
########################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK # PORT PORT(S) DEST LIMIT GROUP ACCEPT wg:192.168.30.2 lan:$NET_OFFICE DROP wg:192.168.30.2 lan:10.15.1.69 ACCEPT wg:192.168.30.2 lan:10.16.1.252 tcp 80 # ###END### После последнего правила не обязательно писать правило DROP, мы все соединения которые будут сбрасываться реализуем в файле rules. Итак добавляем файл rules и вносим правила nano /etc/shorewall/rules
########################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK # PORT PORT(S) DEST LIMIT GROUP ACCEPT lan $FW ACCEPT wg $FW icmp ACCEPT wg $FW tcp 22 # ##### # add services INCLUDE services.mgmt # #### # add internal hosts/networks to clients SHELL cat /etc/shorewall/rules_networks.d/*.rule # ##### # drop all internal networks to wireguard from clients and to clients INCLUDE networks.mgmt # #### # add internet to clients SHELL cat /etc/shorewall/rules_internet.d/*.rule # ###END### По порядку:
Структура файлов: /etc/shorewall/
├── conntrack ├── interfaces ├── networks.mgmt ├── params ├── params.mgmt ├── policy ├── README.MD ├── rules ├── rules_internet.d │ └── 192.168.30.2_tst-client.rule ├── rules_networks.d │ └── 192.168.30.2_tst-client.rule ├── services.mgmt ├── shorewall.conf └── zones Применяем правила фаервола shorewall reload
Во всей этой легкости написания правил доступа клиентов во внутреннюю сеть есть одно "но", shorewall сбрасывает цепочку правил и применяет новые только если увидит в корневой папке /etc/shorewall/ изменения хотя-бы в одном файле, т.е. изменения в папке rules_internet.d/rules_networks.d не изменят правил iptables. Мы учтем это когда будем собирать все в gitlab. На этом этапе можно создать тестового пользователя и тестовое подключение через Wireguard, разрешить все правилами Shorewall и пингануть с любого хоста внутренней сети vpn клиента. Пинги должны проходить и к клиенту должен быть доступ по всем портам. Если vpn клиент не виден из внутренней сети, значит не добавили правила маршрутизации или есть ограничения фаервола как на vpn сервере, так и на маршрутизаторе. Все vpn скиенты должны быть доступны с административных ip адресов, которые мы указывали в переменной ADM_IP и ADM_IP_VPN. Предлагаю на этом не останавливаться и продолжить, осталось немного :) Реализация VPN доступа через CI Pipelines в GitLab Допустим у нас уже есть selfhosted gitlab для внутреннего использования, если нет то его не так сложно развернуть через тот-же docker-compose. Для начала создадим новую группу и новый проект, создадим репозиторий vpn-01 и создадим следующую структуру vpn-01
├── .gitlab-ci.yml ├── README.md ├── shorewall │ ├── networks.mgmt │ ├── params.mgmt │ ├── README.MD │ ├── rules_internet.d │ │ └── 192.168.30.2_tst-client.rule │ ├── rules_networks.d │ │ └── 192.168.30.2_tst-client.rule │ └── services.mgmt └── wireguard ├── README.MD └── wg0.conf Переносим настройки описанные ранее во все файлы в папке shorewall на gitlab. В README.MD можно вести учет пользователей, написать мануал для суппорта. В файле wg0.conf будут записи только клиентов. Добавляем одного клиента [Peer]
PublicKey = <client_public_key> AllowedIPs = 192.168.30.2/32 Всё, настройки shorewall перенесли и добавили 1 клиента. Далее настраиваем gitlab-runner, Deploy Token с правами read_repository и заполняем .gitlab-ci.yml. Устанавливаем gitlab-runner на vpn сервере apt install gitlab-runner -y
на сайте в настройках репозитория берем token Settings -> CI/CD -> Runners и регестрируем sudo gitlab-runner register
указываем url сайта, вставляем токен, указываем executor: shell и не забываем поставить tag: vpn-01, если даже где-то ошиблись конфигурацию можно поправить /etc/gitlab-runner/config.toml. Создадим deploy token, заходим в настройки репозитория Settings -> Repository -> Deploy Tokens создаем с правами read_repository На vpn сервере добавим права для gitlab-runner и добавим в sudo #1
sudo usermod -a -G sudo gitlab-runner #2 nano /etc/sudoers.d/gitlab-runner #3 gitlab-runner ALL=(ALL) NOPASSWD:/usr/bin/wg-quick,/usr/bin/git,/sbin/shorewall,/bin/cp,/bin/rm,/bin/cat,/bin/touch,/bin/chmod Добавим побольше прав для папки /opt/git/ Переходим в репозиторий и открываем файл .gitlab-ci.yml на редактирование и вставляем следующие строчки stages:
- all task-all: stage: all script: - sudo /bin/cp -f /etc/wireguard/wg0.sempl /opt/git/wg/wg0.conf - sudo /usr/bin/wg-quick up wg0 || if [ $? -ne 0 ]; then echo "wg0 is up"; fi - sudo /usr/bin/wg-quick down wg0 - sudo /bin/rm -rf /opt/git/vpn-01 - cd /opt/git - sudo /usr/bin/git clone https://gitlab+deploy-token:<token>@gitlab.company.net/infra/vpn-01.git - sudo /bin/rm -rf /etc/shorewall/rules_networks.d/* - sudo /bin/rm -rf /etc/shorewall/rules_internet.d/* - sudo /bin/cp -rf /opt/git/wgvpn-02/shorewall/* /etc/shorewall/ - sudo /bin/rm -rf /opt/git/wg/wg0.conf - sudo /bin/cp /etc/wireguard/wg0.sempl /opt/git/wg/wg0.conf - sudo /bin/chmod 0666 /opt/git/wg/wg0.conf - sudo /bin/cat /opt/git/vpn-01/wireguard/wg0.conf >> /opt/git/wg/wg0.conf - sudo /usr/bin/wg-quick up wg0 - sudo /sbin/shorewall reload - sudo /usr/bin/wg-quick down wg0 - sleep 60 && sudo /usr/bin/wg-quick up wg0 tags: - 'vpn-01' allow_failure: true when: manual Запускаем скрипт с последовательными командами:
Запускаем CI/CD -> Pipelines, смотрим последний Commit и запускаем. Не забываем выдать права кому на Merge Requests, а кому на Pull Requests. На этом этапе мы уже полностью реализовали задуманное, но нужно идти до конца) Сбор логов Допустим по счастливай случайности так оказалось, что в нашей сети есть не только GitLab, но и Elasticsearch с Kibana. Реализуем пересылку и хранение логов в Elasticsearch. Для начала на vpn сервере исправим значение на открытие файлов nano /etc/security/limits.conf
root soft nofile 65536 root hard nofile 65536 * soft nofile 65536 * hard nofile 65536 После этого нужно будет перезагрузится Устанавливаем на vpn сервер Fluentd # td-agent 4
curl -L https://toolbelt.treasuredata.com/sh/install-ubuntu-bionic-td-agent4.sh | sh Добавим строчки в /etc/td-agent/td-agent.conf или сделаем в отдельном файле (тогда нужно будет включить файл в основной конфигурации) '<source>
@type tail path /opt/logs/shorewall/firewall.log pos_file /var/log/td-agent/pos-firewall.pos <parse> @type syslog </parse> tag firewall.raw </source> <match firewall.raw.**> @type elasticsearch host <server_ip> port <server_port> logstash_format true logstash_prefix infra-vpn-01 flush_interval 10s flush_thread_count 2 </match> По сути наш лог относится к syslog, поэтому мы его просматриваем и разбираем как syslog Смотрим в кибану на результат  Только перед этим не забываем добавить новые шаблоны индексов. С Filebeat все еще проще. Устанавливаем на сервер. #1
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add - #2 sudo apt-get install apt-transport-https #3 sudo apt-get update && sudo apt-get install filebeat #4 sudo systemctl enable filebeat Включаем модуль iptables filebeat modules enable iptables
Изменяем настройки в самом модуле nano /etc/filebeat/modules.d/iptables.yml
- module: iptables log: enabled: true var.input: "file" var.paths: ["/opt/logs/shorewall/firewall.log"] И в файле /etc/filebeat/filebeat.yml добавляем наш Elasticsearch сервер output.elasticsearch:
hosts: ["<ip_address>:9200"] На последок хотел затронуть тему оптимизации Elasticsearch или как заставить Elasticsearch прожевать 7000 шард на одной ноде и не поперхнуться при характеристиках сервера RAM — 10 Gb и vCPU — 6. На эту тему есть много материала и везде пишут одинаково, в файле /etc/security/limits.conf выставляем лимиты, добавляем в /etc/elasticsearch/jvm.options значение -Xms чуть больше половины RAM. И допустим в лимитах у нас стоит значение elasticsearch - nofile 200000
elasticsearch memlock 200000 или даже так * soft nofile 265536
* hard nofile 265536 и подкручен конфиг /etc/elasticsearch/elasticsearch.yml cluster.max_shards_per_node: 15000
xpack.ml.max_open_jobs: 100 cluster.routing.allocation.node_initial_primaries_recoveries: 10 thread_pool.search.queue_size: 100000 thread_pool.search.max_queue_size: 150000 thread_pool.search.size: 35 thread_pool.search.auto_queue_frame_size: 10000 Но у нас все равно выскакивает индекс с ошибкой "type" : "file_system_exception",
"reason" : "/mnt/elk/data/nodes/0/indices/SNMMbQeLRlW0y4Vi_V9L1Q/3/_state: Too many open files" Тут дело в том что у службы свои лимиты и находятся они в /etc/systemd/system/elasticsearch.service.d/elasticsearch.conf или /etc/systemd/system/multi-user.target.wants/elasticsearch.service и здесь как раз накручиваем значения LimitNOFILE=200000
LimitNPROC=4096 LimitAS=infinity LimitFSIZE=infinity Перезапускаем службу/сервер и смотрим как 7000 шард расфасуются за несколько десятков минут. Вот в принципе и все чем я хотел с вами поделится, задача поставлена весь процесс написан и вы можете спросить так в чем отказоустойчивость? А она в том, что вас никто не ограничивает в выборе места разворачивания сервера и количества серверов, можно сделать несколько независимых точек входа на разные сервера и каждый будет со своей конфигурацией, что бы это было отказоустойчивым делайте пользователям сразу как минимум 2 конфигурации и все. На этом, пожалуй, и закончу. Всем спасибо за внимание! Используемые источники: WireGuard — https://www.wireguard.com Shorewall — https://shorewall.org TightVNC — https://www.tightvnc.com/download.php GitLab runners — https://docs.gitlab.com/ee/ci/runners/ Linux firewall log format — http://www.stearns.org/doc/william_stearns_gcia.html#iptablesformat Проверка регулярных выражений — https://rubular.com/ Fluentd — https://docs.fluentd.org/installation/before-install Filebeat Iptables module — https://www.elastic.co/guide/en/beats/filebeat/master/filebeat-module-iptables.html =========== Источник: habr.com =========== Похожие новости:
IT-инфраструктура ), #_*nix |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 20:14
Часовой пояс: UTC + 5