Double_W 10 ноя 2020 в 19:40

WireGuard без NAT, внутренняя сеть и клиенты с обратной связью

18 мин

63K

Приветствую, уважаемые читатели. В этой статье, я хотел бы рассказать о своем опыте постройки внутренней сети не привязанной к офисному оборудованию и функционирующий при единственном условии, что доступен интернет. С добавлением в настройки vpn сервера возможности обратной связи к клиенту и управлением доступа в сеть для каждого клиента. И управлять всем этим из одного места через веб интерфейс или удобный GUI.

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

подключение клиента автоматически при загрузке ОС
автоматически восстанавливать соединение при переключении между WiFi точками
VPN клиент должен быть виден из офисной сети
кросплатформенность vpn клиента и ПО для удаленного управления
минимальное участие пользователя в настройках vpn клиента
доступ клиента к хостам и подсетям ограничивается правилами ACL
настройка клиентов и ACL из одного удобного GUI
отказоустойчивость VPN серверов

Как дополнение

логирование (минимум Layer 3)
передавать логи в поисковую систему (например ELK стек)

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

Основная задача была сделать дополнительную внутреннюю подсеть без NAT и посредников, чтобы vpn клиент видел внутреннюю подсеть и из внутренней подсети можно было видеть vpn клиента на прямую и чтобы администратор подключенный к одному vpn серверу видел и мог подключатся к vpn клиенту подключенному к другому vpn серверу.

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

За основу, где будет развернут vpn сервер была выбрана ОС Ubuntu 18.04.5 LTS.

Для vpn сервера был выбран WireGuard, всем характеристикам он соответствует. Он легковесный, имеет минимум настроек. Клиентская часть запускается при старте ОС, сама поднимает канал и кросплатформенная. Работает через udp протокол. При шифровании канала потеря скорости всего в районе 20%. Каждый клиент получает свой собственный ip адрес, что позволяет управлять доступом каждого клиента через iptables.

В качестве 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. Можно указывать диапазон внутренних подсетей.

Дополнительно протестируем видимость vpn клиентов из внутренней сети. Возьмем тестовый ноутбук и установим Wireguard клиента, там же создадим новое подключение и скопируем публичный ключ клиента.

На сервере выключаем интерфейс wg0

wg-quick down wg0

Создадим peer в файле конфигурации wg0.conf

nano /opt/git/wg/wg0.conf

[Interface]
Address = 192.168.30.1/24
SaveConfig = true
ListenPort = 5505
PrivateKey = SERVER_PRIVATE_KEY

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 192.168.30.2/32

Тестовому клиенту передаем конфигурацию подключения к серверу

Address = 192.168.30.2/24
DNS = 10.15.1.10, 10.16.1.252

[Peer]
PublicKey = <server_public_key>
AllowedIPs = 10.15.1.0/24, 10.17.1.0/24   <- добавляем внутренние подсети
Endpoint = 1.2.3.4:5505

Полная конфигурация wireguard у клиента должна выглядеть так

[Interface]
PrivateKey = CLIENT_PRIVATE_KEY
Address = 192.168.30.2/24
DNS = 10.15.1.10, 10.16.1.252

[Peer]
PublicKey = <server_public_key>
AllowedIPs = 10.15.1.0/24, 10.17.1.0/24   <- добавляем внутренние подсети
Endpoint = 1.2.3.4:5505

Сохраняем настройки у клиента и на сервере и запускаем интерфейс wg0

wg-quick up wg0

Подключаемся клиентом и пробуем запустить ping на внутренние сервера. Заходим на любой внутренний сервер и запускаем ping 192.168.30.2 к нашему тестовому vpn клиенту, ping от сервера к клиенту должен проходить. Пробуем с внутреннего сервера подключится каким-нибудь ПО для удаленного управления к нашему vpn клиенту, все должно работать и наш тестовый vpn клиент должен быть виден. Если из внутренней сети не получается увидеть vpn клиент, то еще раз проверяем настройки, перезагружаем сервер и проверяем маршруты на шлюзах.

На данный момент никаких клиентов и никаких подключений снаружи нам не нужно, поэтому созданного клиента удаляем из конфигурации wg0.conf.

#1
wg-quick down wg0

#2 удаляем [Peer]
nano /opt/git/wg/wg0.conf

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 192.168.30.2/32

#3
wg-quick up wg0

Вступление есть, продолжаем.

Устанавливаем и настраиваем 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
# kaspersky
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

Зачем пропускать интернет-трафик через WireGuard сервер?

Допустим у нас веб-сервер на определенную локацию пропускает только определенный диапазон ip внешних адресов в этот диапазон допустим входит и внешний ip адрес офиса/облака, а т.к. трафик идет через WG сервер и на прямую через пограничный маршрутизатор который выпускает в интернет, то клиент при выходе в интернет будет получать внешний ip офиса/облака и не обязательно заворачивать весь интернет трафик через WG, достаточно просто указать внешний ip адрес пограничного веб-сервера/балансировщика. Для этого у клиента в AllowedIPs необходимо прописать внешний ip (например — AllowedIPs = 10.15.1.0/24, 10.17.1.0/24, 4.3.2.1) на который мы хотим выпускать трафик через WG и в rules_internet.d в shorewall добавить правило для клиентского ip.

Во всей этой легкости написания правил доступа клиентов во внутреннюю сеть есть одно "но", 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 можно вести учет пользователей, написать мануал для суппорта.

Файлы networks.mgmt, params.mgmt и services.mgmt копируем в репозиторий для того, чтобы не редактировать/дополнять правила или переменные на сервере, а производить все опирации с GUI gitlab.

В файле wg0.conf будут записи только клиентов. Добавляем несколько клиентов

[Peer]
PublicKey = <client_public_key>
AllowedIPs = 192.168.30.3/32

[Peer]
PublicKey = <client_public_key>
AllowedIPs = 192.168.30.4/32

Переходим в rules_networks.d и создаем 2 файла 192.168.30.3_i.ivanov.rule и 192.168.30.4_p.petrov.rule. Все файлы должны быть с расширением .rule, если доступ клиента больше не нужен, то можно переименовать в .bk и он не будет считываться и правила не будут применяться, файл можно оставить для истории.

В файл 192.168.30.3_i.ivanov.rule добавим например доступ к терминальному серверу по tcp 3389

###########################################################################################
#ACTION           SOURCE                     DEST                        PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/   MARK
#                                                                                PORT    PORT(S)         DEST            LIMIT           GROUP
ACCEPT           wg:192.168.30.3            lan:10.16.1.250              tcp     3389
#
###END###

В файл 192.168.30.4_p.petrov.rule добавим доступ в офисную сеть, запретим пинги в офисную сеть и доступ к одному серверу

###########################################################################################
#ACTION           SOURCE                     DEST                        PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/   MARK
#                                                                                PORT    PORT(S)         DEST            LIMIT           GROUP
DROP              wg:192.168.30.4            lan:$NET_OFFICE            icmp
ACCEPT           wg:192.168.30.4            lan:$NET_OFFICE
DROP              wg:192.168.30.4            lan:10.15.1.115
#
###END###

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

В папку rules_internet.d добовляем файлы только тех клиентов кому хотим сделать выход в интернет через наш vpn сервер. Например, создадим правила для 192.168.30.3_i.ivanov.rule.

В папке rules_internet.d создаем файл 192.168.30.3_i.ivanov.rule и записываем правила доступа в интернет, правило там одно

###########################################################################################
#ACTION           SOURCE                     DEST                        PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/   MARK
#                                                                                PORT    PORT(S)         DEST            LIMIT           GROUP
ACCEPT           wg:192.168.30.3            lan
#
###END###

Всё, настройки shorewall перенесли и добавили 2 клиентов. Далее настраиваем 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 конфигурации и все.

На этом, пожалуй, и закончу.

Всем спасибо за внимание!