Для доступа к конечному оборудованию (сервер ssh/rdp/https, сетевое оборудование и т.д. )использую как VPN так и белые списки (iptables and etc). Т.к. гарантировать работу сразу нескольких туннелей представляется сложным, я вынужден, в некоторых случаях (выход с неразрешенного ip), подключаться к конечной точке через промежуточную, подключенную через VPN. Порой хоуп получается тройной или даже четверной вложенности. По сути это получается что-то типа ssh-jump-server. Это очень неудобно для вариантов RDP или же банального веб интерфейса.
Последние два месяца я нахожусь за пределами физического расположения разрешенных IP адресов, и т.к. основной IP у меня белый динамический, я вынужден прописывать по новой каждый раз. Это противоречит цели белых списков, т.к. мы не знаем кому потом будет принадлежать этот ip, так еще и вечные трудозатраты на настройку.
Мне тут предложили использовать SSO и keykloak, но мне показалось что это не то что надо, плюс очень громоздко.
Я почесал репу и решил использовать домашний RB2011 в качестве jump server для всего трафика проходящего через определенный VPN сервис. А трафик отправлять не весь, а только к нужным узлам, а список узлов регулировать банальными маршрутами. В итоге выбор пал на OpenVPN, из-за push route (не поддерживается RouteOS 6.x) и кроссплатформенности.
В интернетах инструкций по настройке OpenVPN сервера куча, единственное отклонение, в моем случае, это автоматическое добавление и удаление нового интерфейса в список интерфейсов LAN, для разрешения трафика по правилу:
;;; defconf: drop all not coming from LAN
chain=input action=drop in-interface-list=!LAN
Сами "скрипты"
On up
:local interfaceName
:set interfaceName [/interface get $interface name]
/interface list member add interface=$interface list=LAN comment=$interfaceName
On down
:local interfaceName
:set interfaceName [/interface get $interface name]
/interface list member remove [find where comment=$interfaceName]
А на стороне клиента в конфигурационном файле указываем маршруты к интересующим хостам в туннель (10.66.4.1 - адрес Mikrotik)
Остальные правила на роутере правим по своему вкусу. Хотелось бы конечно иметь push route, т.к. иногда хочется с телефона открыть тот же заббикс, который закрыт. Но увы. На этом все
Другие заметки:
Некоторый костыль для Linux подобных систем можно приделать:
- создаем на роутере ssh ключ
- добавляем ключ на нашу машину (клиент, не сервер, мы с него будем стучаться к другим хостам)
- в скриптах On up и On Down добавляем команду ssh, через которую добавляем список маршрутов на клиенте. Маршруты одинаковые, меняется только IP хоста, поэтому IP хостов можно записать в Address List и перебирать его
- Создаем ssh ключ на главном Mikrotik
- Распространяем публичную часть по хостам с поддержкой ssh
- Создаем адрес лист со списком нужных хостов (в будущем надо только добавить ip сюда и пуб часть ключа туда)
- Настраиваем port knocking (допустим 2 промежуточных листа и один конечный (назовем его accept_list_for_distribution)
- Создаем шедуллер (раз в пять минут) со скриптом:
- Скрипт смотрит accept_list_for_distribution, если появился новый адрес, то запускает процесс
- Добавляет на конечные узлы в листы или конкретно разрешающие правила для нового IP посредством ssh
- Перемещает IP в address_list_common, с указанием даты или порядкового номера в комментарии
- После запускается проверка на выбывание IP, допустим ставим правило - не больше 3 IP в листе address_list_common, если их больше то запускается процесс удаления
- Удаляем с конечных узлов из листов или разрешающие правила с указанным IP
- Удаляем IP из address_list_common
- Оповестить на почту или настроить заббикс на оповещение (мониторить определенный комментарий)
Комментариев нет:
Отправить комментарий