… нужно останавливать интерфейс на сервере и т.д.?
Если руками, то да.
Но процесс автоматизирован через GitLab.
Клиент передает публичный ключ и в ответ получает остальную часть конфига для себя и все.
Тех. поддержка заходит на gitlab, в репозитории открывает на редактирование wireguard/wg0.conf и в конце списка добавляет Peer нового клиента, там же в репозитории находит shorewall/rules_network.d/ и добавляет файл tst.rule в файл вставляет например ACCEPT wg:192.168.30.2 lan:10.17.1.30 tcp 3389 сохраняет и запускает пайплайн последнего коммита.
По описанию это выглядит очень длинно, но на деле добавить 1 клиента меньше 1 минуты по времени.
Я просто решил заморочиться и все контролировать на своей стороне, как ни странно настройки заняли очень мало времени.
Так ведь лень двигатель прогресса)
Еще не дописал плейбук на это все, но то что можно конфиги shorewall переносить и ключи приватный/публичный wireguard можно тоже переносить, это как раз является плюсом. Можно сразу в плейбук подкинуть и развернуть второй сервер идентичный первому серверу, натравить runner на второй сервер и вся конфигурация восстановится за 1 проход пайплайна)
Что значит "что насчёт прямой видимости клиента?"?
По сути мы создаем внутреннюю дополнительную подсеть, где не только клиенты видят сервера, но и сервера видят клиентов.
То есть почти никогда? Тейлскейл чем и хорош, что пробивает практически любые наты и создаёт между девайсами максимально прямой канал (оказались в одной локалке — замечательно, трафик пойдёт по локалке, есть связь через интернет — будет самый быстрый прямой маршрут через интернет, все фолбэки не сработали — пойдём через прокси тейлскейла).
Здесь как раз не создается NAT, дополнительная внутренняя подсеть без посредников.
… не выглядит как "просто" и как ведущее к категорическому снижению нагрузки на техподдержку.
Как раз таки на оборот, от тех. поддержки требуется всего в gitlab дописать 2 правила в 2 файла и все. Все через удобный GUI. Уже проверенно на практике.
Настройка на сервере wireguard и shorewall это городить сверх нормы? Остальное как дополнение.
Настройка 2 серверов в неспешном режиме с учетом добавления маршрутов на шлюзах заняла не более 2 часов.
Предложенное ПО платное, в статье все ПО бесплатно и без ограничений с прямой видимостью vpn клиента.
В статье и не отрицается, что есть много разного ПО.
Если рассматривать клиентскую часть wireguard, то там тоже все в 1 клик.
По поводу выше предложенных ресурсов, не нашел кем контролируется серверная часть? И что на счет прямой видимости vpn клиента? Клиентская часть сама создает подключение при загрузке ОС и при переключении между wifi точками восстанавливает соединение?
Если сильно сжать статью и выделить только основное, то по сути нужно на сервере установить только wireguard и не прятать клиентов за NAT, что бы была прямая видимость.
Спасибо, мил человек) поправил опечатку.
Рад что помог мануалом.
Но это еще цветочки, буквально за считаные месяцы микротик обрастает огромным количеством правил))
Не забываем делать бэкапы)
ping rc1a-XXX.mdb.yandexcloud.net
Pinging rc1a-XXX.mdb.yandexcloud.net [172.16.0.32] with 32 bytes of data:
Reply from 172.16.0.32: bytes=32 time=5ms TTL=61
..........
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
.........
винда в одной VPC, зоне доступности и подсети, а managment pgsql в другой зоне, подсети и VPC
Что-бы все подсети видели друг друга, было добавлено вот это правило
Думал про апстрим nginx, но нужно было централизованное управление входящим и исходящим трафиком всех подсетей + маршруты между подсетями (разграничить prod и stage)
Каких-то особых проблем нет, только в статье забыл добавить в route rules первый маршрут по умолчанию, что-бы не было принудительного перенаправления, поправил.
Благодарю за отзыв и за список альтернативных ПО. Интересные инструменты.
Прям в точку)
Люди разные, а боль одна :)
Как бы в основном от руководителей отделов прилетают запросы, и каждый клиент подписан по фамилии. Все вопросы будут к руководителю и клиенту)
А доступ только на конкретный хост с портом, остальное обрубает
iptablesЕсли руками, то да.
Но процесс автоматизирован через GitLab.
Клиент передает публичный ключ и в ответ получает остальную часть конфига для себя и все.
Тех. поддержка заходит на gitlab, в репозитории открывает на редактирование
wireguard/wg0.confи в конце списка добавляетPeerнового клиента, там же в репозитории находитshorewall/rules_network.d/и добавляет файлtst.ruleв файл вставляет напримерACCEPT wg:192.168.30.2 lan:10.17.1.30 tcp 3389сохраняет и запускает пайплайн последнего коммита.По описанию это выглядит очень длинно, но на деле добавить 1 клиента меньше 1 минуты по времени.
это описание вот здесь идет -> "Дополнительно протестируем видимость vpn клиентов из внутренней сети...."
Все отлично, это те же яйца только в профиль))
Я просто решил заморочиться и все контролировать на своей стороне, как ни странно настройки заняли очень мало времени.
Так ведь лень двигатель прогресса)
Еще не дописал плейбук на это все, но то что можно конфиги shorewall переносить и ключи приватный/публичный wireguard можно тоже переносить, это как раз является плюсом. Можно сразу в плейбук подкинуть и развернуть второй сервер идентичный первому серверу, натравить
runnerна второй сервер и вся конфигурация восстановится за 1 проход пайплайна)По сути мы создаем внутреннюю дополнительную подсеть, где не только клиенты видят сервера, но и сервера видят клиентов.
Здесь как раз не создается NAT, дополнительная внутренняя подсеть без посредников.
Как раз таки на оборот, от тех. поддержки требуется всего в gitlab дописать 2 правила в 2 файла и все. Все через удобный GUI. Уже проверенно на практике.
Настройка на сервере wireguard и shorewall это городить сверх нормы? Остальное как дополнение.
Настройка 2 серверов в неспешном режиме с учетом добавления маршрутов на шлюзах заняла не более 2 часов.
Предложенное ПО платное, в статье все ПО бесплатно и без ограничений с прямой видимостью vpn клиента.
В статье и не отрицается, что есть много разного ПО.
Если рассматривать клиентскую часть wireguard, то там тоже все в 1 клик.
По поводу выше предложенных ресурсов, не нашел кем контролируется серверная часть? И что на счет прямой видимости vpn клиента? Клиентская часть сама создает подключение при загрузке ОС и при переключении между wifi точками восстанавливает соединение?
Если сильно сжать статью и выделить только основное, то по сути нужно на сервере установить только wireguard и не прятать клиентов за NAT, что бы была прямая видимость.
Спасибо. Согласен с shorewall, с ним главное не спешить и все изначально настроить компактно и что-бы дополнение правил не занимало много времени.
Спасибо, мил человек) поправил опечатку.
Рад что помог мануалом.
Но это еще цветочки, буквально за считаные месяцы микротик обрастает огромным количеством правил))
Не забываем делать бэкапы)
Согласен
эта схема тоже рабочая
да, она самая)
add chain=dstnat ...без
netmapпорты на хост не перекидываютсяЗачем объяснять? СБ сказали мы сделали))
на момент написания статьи группа безопасности VPC находилась в стадии Preview
И еще один момент, чтобы хосты внутренних подсетей не определялись как
ipроутера ставим первым правиломsnatподсетей которые мы связываемда как бы нет с этим проблем
винда в одной
VPC, зоне доступности и подсети, аmanagment pgsqlв другой зоне, подсети иVPCЧто-бы все подсети видели друг друга, было добавлено вот это правило
если его не сделать первым в таблице, то да все рухнет ...
Думал про апстрим
nginx, но нужно было централизованное управление входящим и исходящим трафиком всех подсетей + маршруты между подсетями (разграничитьprodиstage)Каких-то особых проблем нет, только в статье забыл добавить в
route rulesпервый маршрут по умолчанию, что-бы не было принудительного перенаправления, поправил.