Комментарии 4
Как альтернативу можно было бы рассмотреть Wireguard, однако:
Запуск его конфигов несколько сложнее для пользователя.
Извините, а можно пример? Вроде и там, и там по одному клику нужно сделать...
Интересная статья. Помню был случай на ctf - использовал свой ноутбук как промежуточный сервер для других участков команды: был подключен к ctf через openvpn, а другие участники ко мне через wireguard. Не помню уже почему так было сделано, но на тот момент самый простой и главное рабочий вариант оказался
Описанная в статье сеть разворачивалась для проведения занятий у студентов. В основном на эти встречи приходили пользователи, совершенно не знакомые с Linux. Наша задача была научить их решать CTF.
Почему не Wireguard? Он по стандарту не предустановлен, например, в kali linux, а его нужно ставить дополнительно (в отличии от OpenVPN, который есть по стандарту). Да, Wireguard настроить несложно, но на это требуется время, которое было рассчитано не на настройку VPN, а на обучение. К тому же, участники, например, не знали или не могли найти место сохранения скачивания конфига в системе. Приходилось помогать каждому индивидуально, на что также затрачивалось время.
Если бы Wireguard дал какие-то значительные плюсы по сравнению с OpenVPN, то был бы смысл его ставить, но по функционалу они схожи, а в настройке проще OpenVPN. Поэтому был использован именно он, чтобы сэкономить время на занятии.
Для CTF гораздо удобней в OpenVPN вместо сертификатов использовать пароли. Нет этой волокиты сперва с генерацией сертификатов, а потом с их отзывом после окончания CTF - логично же использовать созданную инфраструктуру повторно, но вот людей со старыми ключами пускать не хотелось бы.
Ну и второй момент - это фиксированные адреса для участников. Так проще разбирать логи, в случае чего.
А еще помнится, перенаправляли все адреса, не используемые сервисами, на одну виртуалку. Чтобы nmap -sP выдавал полный диапазон и невозможно было определить, где же висит сервис, пока условие задачи не будет доступно. По этой же причине не использовались стандартные порты для сервисов.
Сеть разворачивалась для студентов с целью обучения. Из-за того, что занятия проходили на регулярной основе, отзывать сертификат не надо. Поэтому было значительно удобнее и быстрее создать один сертификат на всех и выдать его один раз. После этого все по нему работали. Система для раздачи данных, которая выдавала бы каждому пользователю индивидуальный логин и пароль для входа, в нашем случае была бы избыточной.
В самом начале у нас была попытка раздать каждому участнику заранее сгенерированный конфиг. Но моментально возникли сложности с тем, что многие студенты подключались по одному конфигу. В итоге работа на занятии приостанавливалась.
Что касается того, если участники положат сервис, то поднять его можно одной командой. Но обычно я создавал резервные копии сервисов на случай, если кому-то удастся положить сервис, что является обыденным событием для учебного процесса
Настройка OpenVPN для CTF