Ensp не запускается firewall
Обновлено: 05.07.2024
ENSP
Нужен установщик симулятора eNSP, желательной новейшей версии, или хотя бы приближенной к ней, у.
Интерфейсы в eNSP
Всем доброго дня. Начал экспериментировать с eNSP. Взял первый в списке AR201 маршрутизатор. .
Ensp потеря пакетов
Дана задача составить сеть такого типа как на картинке,только со хабами и нагрузив ее пересылками.
ENSP - не запускается роутер AR
Добрый день! Установил на Win-10 Pro x64 версию eNSP V100R002C00B510 (VitualBox v 5.1.24). В.
1. проверить, что virualbox 5й ветки (последняя 5.2.44, уже не поддерживается ораклом, но eNSP с 6й веткой не работает)
2. проверить, что у процессора есть аппаратная виртуализация и что она включена в биосе/efi
3. переставить eNSP (проверки сами по себе, естественно, не помогут, перестановка нужна)
4. вариант - можно попробовать образы руками зарегить: Menu-Tools-Register Devices - поставить все галки и нажать кнопку Register
при ошибках регистрации - гуглить ошибки
ENSP настройка первичная
День добрый. Установил eNSP - ничего, конечно, не запускается. Подскажите, как должна выглядеть.
Добавление серии коммутаторов в eNSP
Здравствуйте! Подскажите пожалуйста, возможно ли добавить в симулятор eNSP модель коммутатора haw.
ПК не видит usb девайсы
Пробовал вставлять и usb-хабы,и lightning'и,и флешки,ничего не работает,НО работают клава и мышь В.
SetupApi и COM-порты (девайсы)
Народ. Есть USB модем. 1. Кто-нибудь знает как вытянуть из него настройки его COM-порта ? 2. Как.
Девайсы не видят приложение в маркете
Такой вопрос. Есть смартфон DNS S3502 версия андройда 4.0.4 и планшет Fujitsu STYLISTIC M532 32Gb.
Игровые девайсы для Counter-Strike
Помогите выбрать качественные девайсы для игры в кс. Суть такая: играю в кс 1.6 уже лет 6.
Если кто знает как с этим бороться, прошу помочь в решении проблемы.
__________________Помощь в написании контрольных, курсовых и дипломных работ здесь
Организовать сеть Хаб - роутер - роутер - роутер - роутер. Все роутеры имели свои IP адреса и локальную сеть
Здравствуйте, помогите кто сможет. Хотел организовать сеть вот таким образом. Рисунок (Сеть.jpg).
ENSP
Нужен установщик симулятора eNSP, желательной новейшей версии, или хотя бы приближенной к ней, у.
Интерфейсы в eNSP
Всем доброго дня. Начал экспериментировать с eNSP. Взял первый в списке AR201 маршрутизатор. .
eNSP прошивки своих железяк запускает как виртуальные машины (как GNS3 делает). Соответственно:
1. На компьютере в BIOS/UEFI должна быть включена аппаратная поддержка виртуализации (если она в процессоре вообще есть. А есть не у всех).
Искать такие штуки:
Intel® Virtualization Technology (VT-x) ‡ Yes
Intel® Virtualization Technology for Directed I/O (VT-d) ‡ Yes
Intel® VT-x with Extended Page Tables (EPT) ‡
3. Где смотреть у АМД - не знаю.
4. Ну и конечно, включить в BIOS/UEFI. Тоже возможны засады. Когда вендор нужный переключатель просто не делает. У меня переключатель был. По дефолту выключен. Я его, слава богу, включил. После обновления биоса - переключатель пропал.
Ensp потеря пакетов
Дана задача составить сеть такого типа как на картинке,только со хабами и нагрузив ее пересылками.
Симулятор eNSP: из роутеров в рабочем состоянии только один, все остальные отказываются включаться
Доброго времени всем, недавно скачал eNSP, обнаружил что из роутеров там в рабочем состоянии только.
есть роутер(проводной) TL-R460, нужно подключить к нему WIFI роутер
Ребят есть роутер(проводной) TL-R460. Раздаёт инет на 2 компа. Нужно подключить к нему WIFI.
Иногда получается, что при выполнении очередного проекта, я случайно открываю какие-то обстоятельства, которые, вроде, никто не скрывает, можно даже найти документацию, поясняющую суть… Но многие, включая меня, находятся в плену заблуждений, поэтому не ищут ту документацию, полагаясь на совершенно неверную картину мира. У меня уже намечается целый цикл из статей, в которых я просто сообщаю, что всё, оказывается, не так, как многие (включая меня) думали. Была у меня статья про DMA, была статья про производительность шины PCI Express. К этому же циклу можно отнести статью про конфигурационные ПЗУ для ПЛИС Altera.
Сегодня мне хотелось бы рассказать пару слов про работу Windows Firewall, или, как его называют в русифицированной ОС – брандмауэра. В целом, это очень хорошая штука, но в частности… Оказывается, по умолчанию он работает в достаточно интересном режиме. Как говорится: «А пацаны и не знают». Итак, начинаем разбираться, что там к чему.
Введение
Сначала поясню суть задачи, которую я решал. Мне надо было проверить, насколько корректно работает очередная плата с нашим сервисом All Hardware. Но не та, которую я проверял в одной из прошлых статей, а более навороченная, с ПЛИС Xilinx.
Что представляет собой сервис All Hardware. Это сайт, на который пользователь заходит, авторизуется и получает список различных плат, физически размещённых на сервере. Зачем он это делает? Чтобы поработать с платой, не покупая её. Например, посмотреть, подойдёт ли она ему, или просто поупражняться в работе с конкретным контроллером. Платы предоставляют производители, а сервис – даёт сеанс работы с ними, ограниченный по времени. Пользователь выбирает плату из списка и получает три вещи: IP адрес, номер порта и видео с камеры, которая смотрит на эту макетку. На самом деле, там ещё можно через SSH пробрасывать порты, но в них я – не специалист. По моей части – именно адрес, порт и видео.
Дальше пользователь в среде разработки, которая стоит на его локальной машине, должен выбрать удалённый отладчик (для большинства сред это старый добрый GDB, для Кейла – более извратный, но если интересно – про это можно сделать отдельную статью, к фаерволу это не относится). Туда вбиваются выданные IP и порт, после чего можно начинать сеанс удалённой отладки, ориентируясь о происходящем с платой по картинке с камеры и по проброшенным через SSH-портам.
Таким образом, любой желающий может пощупать работу с различными отладочными платами, не покупая их. При этом, как и в случае с Redd, среда разработки и исходные коды размещаются на локальной машине. На сервер уходит только двоичный код. Но по истечении сеанса работы, автоматика стирает ПЗУ, так что следующий пользователь считать код уже не сможет.
Итак, возвращаемся к теме статьи. Каким боком здесь фаервол? Всё просто. Мне предстояло поработать с ПЛИС Xilinx. А их среда разработки совершенно официально обладает функцией WebTalk. Мне совершенно не хотелось, чтобы она сообщала о моих действиях «куда следует», поэтому среда стояла на несетевой машине. Даже если бы очень захотела – руки у неё коротки. Нет физического канала и всё тут! Но концепция сервиса All Hardware такова, что сеть быть должна. Для проверки машину пришлось временно подключать к проводу (на самом деле, отсутствие сети — это скорее привычка, на той машине всё равно ничего интересного нет). Что делать? Наступить на горло своей паранойе? Ну уж нет! Я решил ограничить среде разработки перечень разрешённых адресов, чтобы она могла работать только с localhost и сервером All Hardware. Не знаю, что будет потом, а сейчас у сервера All Hardware IP-адрес один и тот же. Просто от сеанса к сеансу выдаются новые порты. Итак, цель ясна, приступаем к реализации.
Какой фаервол взять?
На Windows XP и Windows 7 я пользовался Outpost Firewall. Это отечественная разработка. Очень надёжная и удобная. Я даже купил себе по акции пожизненную лицензию на три машины. Однажды этот фаервол помог мне выявить трояна, которого не видел ни один антивирус. Когда я сумел взять файл с телом вируса, я скормил его нескольким антивирусам, поставляющимся на LiveCD. Ни один не заметил ничего подозрительного. А фаервол у меня просто был в параноидальном режиме, откуда я и узнал о подозрительной активности программы.
Всё было хорошо, пока производитель этого фаервола не закрылся при странных обстоятельствах. После этого, я сильно загрустил. Настолько загрустил, что на основном моём ноутбуке до сих пор стоит семёрка с Outpost, так как я не стал искать ему замену. Но среда разработки Xilinx хочет десятку! Прекрасно! Значит, пришла пора осваивать работу с фаерволом, встроенным в эту ОС!
Все мы знаем, что когда какая-то программа пытается получить доступ к сети, этот стандартный фаервол спрашивает у нас, разрешить ей работу с сетью или нет. Мы можем запретить сразу, а можем снять галочку разрешения после, об этом в сети имеется масса руководств. Вот эти галочки:
Это знают все. Но какова ценность этих знаний? Я опущу свои мысли, которые одолевали меня при чтении массы однотипных статей «как запретить приложению выход в сеть», не рассказывающих, как его не запретить, а только ограничить. Лучше я покажу свои выводы на специально сделанном для этого примере. Напишем два простейших консольных приложения.
Сервер
Первое приложение будет прикидываться сервером. Оно принимает UDP-пакеты, в которых приходят строки, и отображает их на экране. Для того чтобы мы говорили об одном и том же, вот его исходный текст на С++:
Запускаем эту программу, передав в качестве аргумента номер порта (скажем, 1234) и предсказуемо получаем запрос от фаервола:
Разрешим ему сетевую активность… Пусть он пока ждёт, а мы напишем клиентскую часть в виде другого EXE-шника.
Клиент
Пусть наш клиент шлёт серверу строки с крутящейся палочкой. Вот его текст:
Запускаем, указав адрес сервера и порт, который был у сервера (у меня это 192.168.1.95 и 1234), после чего в серверном окне начинает бежать чуть иная, чем я хотел, но всё же палочка:
Но волнует меня не то, что символ “\r” не возвращает каретку в начало строки, а то, что клиент – это отдельный процесс… Запускаемый из совершенно отдельного файла. А фаервол не запросил у меня разрешения на его сетевую активность. Вместо этого, он разрешил её сам, даже не поставив меня в известность о том, что программа куда-то полезет. Как так?
Немного теории о режимах работы фаервола
По умолчанию, Windows-фаервол разрешает все исходящие соединения, если они не запрещены явно. То есть, к нам не смогут подключиться извне, но если какая-то программа проникла на нашу машину (или мы поставили её добровольно), она вполне может отсылать, что угодно, и никто ей по умолчанию это не запретит!
Собственно, вот соответствующая настройка фаервола:
Разрешено всё, что не запрещено. Приложению можно явно запретить активность. Именно этому посвящено огромное количество статей в Интернете… Но троян заберётся на нашу машину незаметно, мы и не догадаемся, что именно его надо занести в запрещённые приложения. Опять же, это не решает моей задачи, вынесенной во введение статьи. Мне надо оставить доступ к тем адресам, которые я разрешил и запретить все остальные.
Чтобы это сделать, надо перевести фаервол в режим «запрещено всё, что не разрешено» для исходящих соединений. Я вечно путаюсь, как войти в соответствующий пункт меню… Ага, нашёл…
И там сначала выбираем вкладку, соответствующую активному профилю (на моём рисунке это был «Общий профиль», а затем переключаем список выбора «Исходящие подключения» из «Разрешить (по умолчанию)» в «Блокировать».
Всё, мы можем спать спокойно? Увы, нет. Если бы всё было так просто – уверен, компания Microsoft сразу выбирала бы режим «Блокировать» для всех. Жаль, но всё только начинается.
Немного о прикладном мазохизме
Итак. Допустим, вы включили режим блокировки для исходящих… Сразу умерло всё, включая браузеры. В целом, никто не мешает в любой момент вернуть выбор в старое положение и откатиться к исходному варианту. Но давайте посмотрим, что нам вообще даёт новый режим. Мы получаем список правил. И у этих правил можно задать безусловное условие разрешения, а можно задать для приложения список открытых портов и список открытых адресов. Адреса можно задавать группой. Вот окно настройки портов:
Вот окно настройки адресов:
Мало того, никто не мешает открыть порт для любых программ, ограничив список допустимых адресов ему. То есть, мы говорим не «Программе такой-то разрешить доступ к портам таким-то», а «Всем программам, работающим через порт такой-то, разрешить работу, ограничив адреса следующей группой».
Всё замечательно, кроме одного. Если список правил для входящих соединений нам формирует система, то для исходящих всё надо добавлять самому. Как я говорил, у меня умер браузер – мне пришлось добавить его в разрешённые исходящие самостоятельно. Как настраиваются адреса, я не буду описывать, статья не об этом. Статей про настройку правил (с целью блокировки, правда) – пруд пруди. В целом, обычно я находил подходящее правило для входящих, копировал имя файла оттуда, после чего – создавал правило для исходящих, указав тот же файл. Ну, и разрешал активность этой программе.
Когда у меня возникла проблема с подключением к VPN в офисе, я поисследовал список готовых правил и нашёл вот такое (я заранее знал, что у нас VPN подключение идёт по протоколу L2TP):
Правило создано за нас, но не активировано. Я зашёл в его свойства, активировал его, после чего слева в списке появился зелёный шарик с галочкой, а VPN-соединение с офисом заработало.
Но так или иначе, а в целом, работа с таким фаерволом попахивает мазохизмом. Надо иметь железную волю, чтобы не закричать: «А надоело это всё» и не вернуться к старому режиму работы. Я уже почти дошёл до этого состояния (благо опыты с Xilinx для All Hardware уже были завершены), но один мой знакомый подсказал мне красивое решение.
Надстройка над штатным фаерволом
Оказывается, есть официально бесплатная программа Windows Firewall Control.
Она сама по себе ничего не делает, а просто управляет фаерволом, встроенным в Windows, предоставляя очень удобные интерфейсы. Теперь не надо бегать через кучу меню, чтобы что-то настроить. Все настройки удобно и компактно собраны на нескольких вкладках. Расписывать все функции этой программы я не буду. Цель статьи – не описать её, а просто отметить её существование. Дальше – все желающие смогут найти специализированные статьи, зная имя Windows Firewall Control.
Я могу разрешить ему доступ, после чего будет автоматически создано правило, я могу запретить доступ, я могу заблокировать приложение однократно.
Вот я ради интереса нашёл автоматически созданное правило в штатном списке фаервола и ограничил ему список доступных адресов:
В общем, с этим приложением жизнь стала намного проще даже при использовании штатного Windows Firewall. Настолько лучше, что эта машина с Windows 10 осталась в сети, ведь она уже не так беззащитна, как была до того.
Заключение
Штатный Windows Firewall по умолчанию работает в таком режиме, что любая программа может начать отсылать данные, о чём пользователь даже не будет проинформирован. Это никто не скрывает, но не все об этом знают. Можно, конечно, поставить сторонний фаервол, но вполне достаточно перевести штатный Windows Firewall в режим «запрещено всё, что не разрешено». К сожалению, при этом поддержка сетевой работоспособности штатными средствами превращается в ад. Но сторонняя официально бесплатная программа Windows Firewall Control устраняет это неудобство.
Будете ли вы пользоваться связкой из штатного фаервола и этой программы, либо достанете сторонний фаервол, вопрос открытый. Но то, что использовать штатный фаервол в режиме по умолчанию несколько боязно, по-моему, не подлежит сомнению.
Существует много разных программ предоставляющих 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.
С небольшой вводной закончил, далее будет расписано как все собрать с небольшими пояснениями. Все ссылки будут в конце статьи.
Установка ПО для различных ОС есть на официальном сайте.
Генерируем публичный и приватный ключи.
Все ключи лежат /etc/wireguard/
Создаем файл wg0.conf
Собираем конфигурационный файл
Во многих мануалах еще добавляют 2 строчки:
Последние строчки PostUp и PostDown верны если вы хотите клиента спрятать за NAT . В таком случае все клиенты при подключении будут иметь ip адрес внутреннего сетевого интерфейса сервера, но нам это не нужно, поэтому мы их не добавляем.
Перед включением интерфейса wg0 , разрешим серверу пересылать пакеты вперед.
Возможно после этих настроек сервер нужно будет перезагрузить, если не будет пинговаться ip wireguard.
В iptables сбросим все цепочки правил и пропустим весь трафик
Проверяем, запустим службу
Добавляем wg на запуск при загрузке
Сделаем копию файла wg0.conf в этой же папке /etc/wireguard/
Важно чтобы в копии были настройки именно [Interface] .
Создадим несколько папок где нибудь в /opt
Скопируем wg0.conf в /opt/git/wg и сделаем ссылку на файл
Для чего последние действия нужны? Скопировав настройки интерфейса в файл 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 фазу политики локальных, а с другой стороны удаленных адресов.
Что мы должны передавать клиенту после всех настроек? Создадим шаблон
Если в AllowedIPs указать 0.0.0.0/0 , то мы завернем интернет трафик клиента через VPN. Можно указывать диапазон внутренних подсетей.
Дополнительно протестируем видимость vpn клиентов из внутренней сети. Возьмем тестовый ноутбук и установим Wireguard клиента, там же создадим новое подключение и скопируем публичный ключ клиента.
На сервере выключаем интерфейс wg0
Создадим peer в файле конфигурации wg0.conf
Тестовому клиенту передаем конфигурацию подключения к серверу
Полная конфигурация wireguard у клиента должна выглядеть так
Сохраняем настройки у клиента и на сервере и запускаем интерфейс wg0
Подключаемся клиентом и пробуем запустить ping на внутренние сервера. Заходим на любой внутренний сервер и запускаем ping 192.168.30.2 к нашему тестовому vpn клиенту, ping от сервера к клиенту должен проходить. Пробуем с внутреннего сервера подключится каким-нибудь ПО для удаленного управления к нашему vpn клиенту, все должно работать и наш тестовый vpn клиент должен быть виден. Если из внутренней сети не получается увидеть vpn клиент, то еще раз проверяем настройки, перезагружаем сервер и проверяем маршруты на шлюзах.
На данный момент никаких клиентов и никаких подключений снаружи нам не нужно, поэтому созданного клиента удаляем из конфигурации wg0.conf .
Вступление есть, продолжаем.
После установки нужно добавить параметры в файл shorewall.conf и создать несколько файлов с переменными и дополнительными параметрами. Большой мануал есть на официальном сайте.
Начнем по порядку, изменим некоторые параметры shorewall.conf
Если в файл логи не будут записываться, добавьте прав на файл/папку. Не забудьте настроить ротацию лога.
Продолжаем настройку shorewall и создадим несколько файлов.
Создаем файл interfaces , в нем запишем переменные для наших интерфейсов и опции
Создадим файл с переменными подсетей и хостов и запишем все наши подсети и важные сервера в сети
Здесь нет ограничений на переменные, мы расписали все внутренние подсети, добавили контроллер домена, free ipa, внутренние DNS, подсети VPN, и административные ip адреса, добавили группу протоколов.
Добавим этот файл в общие настройки
Напишем политику и правила которые будут работать по умолчанию.
В данном примере логируются все соединения. Переменная $FW обозначает сам фаервол, т.е. любое соединение от любого интерфейса направленного на wg будет сброшено. Эти правила применяются последними.
Создадим файл и сделаем описания типа переменных
Самый большой файл получается с сервисами, создадим его и заполним
Расписываем все порты всех наших внутренних сервисов. Какие порты и какой протокол сервисом используются можно найти на официальном сейте каждого из сервисов.
Напишем правила по умолчанию для всех наших подсетей включая и подсети vpn сбрасывающих все соединения
Остался практически самый последний и самый главный файл с описанием всех правил и всех включений с определенным порядком, т.к. Shorewall поддерживает включение множества файлов из папки, для начала сделаем 2 папки в которых мы будем заполнять файлы для клиентов vpn с доступом ко внутренней сети/хостам и с доступом в интернет (да, будем выпускать пользователей в интернет через vpn )
Создаем 2 папки
Разрешим доступ к интернету
Разрешим доступ к некоторым хостам из сети (так же можно комбинировать правила)
После последнего правила не обязательно писать правило DROP , мы все соединения, которые будут сбрасываться реализуем в файле rules .
Итак, добавляем файл rules и вносим правила
- разрешаем соединение сервисов к клиенту и от клиента
- разрешаем/запрещаем соединения к сетям/хостам
- запрещаем доступ ко всем внутренним подсетям и подсетям vpn
- разрешаем доступ в интернет (при наличии файла с правилом)
Применяем правила фаервола
Зачем пропускать интернет-трафик через 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 .
Предлагаю на этом не останавливаться и продолжить, осталось немного :)
Допустим у нас уже есть selfhosted gitlab для внутреннего использования, если нет, то его не так сложно развернуть через тот-же docker-compose .
Для начала создадим новую группу и новый проект, создадим репозиторий vpn-01 и создадим следующую структуру
Переносим настройки, описанные ранее во все файлы в папке shorewall на gitlab. В README.MD можно вести учет пользователей, написать мануал для суппорта.
Файлы networks.mgmt , params.mgmt и services.mgmt копируем в репозиторий для того, чтобы не редактировать/дополнять правила или переменные на сервере, а производить все опирации с GUI gitlab.
В файле wg0.conf будут записи только клиентов. Добавляем несколько клиентов
При применении правил эти файлы будут прочитанны последовательно и правила будут применяться для конкретных wireguard клиентов.
Всё, настройки shorewall перенесли и добавили 2 клиентов. Далее настраиваем gitlab-runner , Deploy Token с правами read_repository и заполняем .gitlab-ci.yml .
Устанавливаем gitlab-runner на vpn сервере
на сайте в настройках репозитория берем token Settings -> CI/CD -> Runners и регистрируем
Создадим deploy token , заходим в настройки репозитория Settings -> Repository -> Deploy Tokens создаем с правами read_repository
На vpn сервере добавим права для gitlab-runner и добавим в sudo
Добавим побольше прав для папки /opt/git/
Переходим в репозиторий и открываем файл .gitlab-ci.yml на редактирование и вставляем следующие строчки
Запускаем скрипт с последовательными командами:
Запускаем CI/CD -> Pipelines, смотрим последний Commit и запускаем.
Не забываем выдать права кому на Merge Requests, а кому на Pull Requests.
На этом этапе мы уже полностью реализовали задуманное, но нужно идти до конца)
Допустим по счастливой случайности так оказалось, что в нашей сети есть не только GitLab, но и Elasticsearch с Kibana. Реализуем пересылку и хранение логов в Elasticsearch.
Для начала на vpn сервере исправим значение на открытие файлов
После этого нужно будет перезагрузится
Устанавливаем на vpn сервер Fluentd
Добавим строчки в /etc/td-agent/td-agent.conf или сделаем в отдельном файле (тогда нужно будет включить файл в основной конфигурации)
По сути наш лог относится к syslog , поэтому мы его просматриваем и разбираем как syslog
Смотрим в кибану на результат
Только перед этим не забываем добавить новые шаблоны индексов.
С Filebeat все еще проще. Устанавливаем на сервер.
Включаем модуль iptables
Изменяем настройки в самом модуле
И в файле /etc/filebeat/filebeat.yml добавляем наш Elasticsearch сервер
На последок хотел затронуть тему оптимизации Elasticsearch или как заставить Elasticsearch прожевать 7000 шард на одной ноде и не поперхнуться при характеристиках сервера RAM — 10 Gb и vCPU — 6.
На эту тему есть много материала и везде пишут одинаково, в файле /etc/security/limits.conf выставляем лимиты, добавляем в /etc/elasticsearch/jvm.options значение -Xms чуть больше половины RAM.
И допустим в лимитах у нас стоит значение
и подкручен конфиг /etc/elasticsearch/elasticsearch.yml
Но у нас все равно выскакивает индекс с ошибкой
Тут дело в том, что у службы свои лимиты и находятся они в /etc/systemd/system/elasticsearch.service.d/elasticsearch.conf или /etc/systemd/system/multi-user.target.wants/elasticsearch.service и здесь как раз накручиваем значения
Перезапускаем службу/сервер и смотрим как 7000 шард расфасуются за несколько десятков минут.
Вот в принципе и все чем я хотел с вами поделиться, задача поставлена весь процесс написан, и вы можете спросить так в чем отказоустойчивость? А она в том, что вас никто не ограничивает в выборе места разворачивания сервера и количества серверов, можно сделать несколько независимых точек входа на разные сервера и каждый будет со своей конфигурацией, что бы это было отказоустойчивым делайте пользователям сразу как минимум 2 конфигурации и все.
Читайте также: