Это бесконечный цикл: одни блокируют, другие ищут новые способы это обойти. А блокируют не только OpenVPN трафик, но и Wireguard, strongswang, softeather и другие. Вопрос в том, как замаскировать свой трафик так, чтобы его сложнее было распознать.
Это вторая проблема, пушить столько маршрутов на конечное устройство - многие устройства просто не потянут. Но инвертировать список это уже сложнее. Для примера нам надо чтобы по стране нашего местонахождения трафик выходил с первого сервера, а весь остальной мир со второго. А теперь считаем: в IPv4 - 4 294 967 296 адресов, в условной стране их пусть будет 200 000. Вопрос: что легче и быстрее обработать (в том числе и серверу) 200 000 адресов, а все остальное пересылать на другой сервер или оставшиеся 4 294 767 296 адресов?
потому что если пушить будет VPN1, то клиент будет ходить на эти адреса через VPN сервер, но на остальные будет ходить мимо туннеля. А VPN2 должен пушить все адреса не входящие в список.
Да, вы правы, однако: 1. Это название оригинальной статьи 2. Если это случилось, то запрос "Расшифровать файлы" и т.п. будет раньше и с большей вероятностью в гугле, чем переделать/восстановить/переписать метаданные данные и т.д.
Я уже даже представил рекламу: - Низкая самооценка из-за лишнего веса? Проблемы с противоположным полом из-за скромности и нерешительности? Боязливость и пугливость? Не беда! Ведь есть "Таксоплазмос". С "таксопласмозом" все эти проблемы пропадут. Спрашивайте в аптеках вашего города.
Интернет - самый плохой врач. Читать конечно интересно, но начинаешь думать, а нет ли чего такого у меня. А тут еще и кошка просится ее погладить. Вот как ее теперь гладить)))
После создаём SubCA и делаем запрос на подпись и подписываем у RootCA. Оба сертификата возвращаем на SubCA. Оба сертификата помещаем в easyrsa-subca/pki/ . Не забываем про символьную ссылку для сертификата SubCA.
Создаём инфраструктуру и запускаем скрипт. Выпускаем ssl сертификат для веб сервера. И помещаем его на сервер. В качестве ssl.crt указываем сертификат в имени которого есть fullchain.crt. Рестартуем веб сервер. Сертификат RootCA устанавливаем на клиентском компьютере в раздел доверенных корневых сертификатов ( как-то так, на винде он второй в списке под папкой личное). Проверяем сайт.
Возвращаемся на SubCA и запускаем скрипт и выпускаем клиентский сертификат. Сертификат с расширением .p12 отправляем на клиентский компьютер. А сами идём на веб сервер.
В конфиге прописываем авторизацию по ssl и указываем сертификат с RootCA. Он будет служить для проверки подписи.
Ещё раз перезапускаем веб.
Идём на клиентский компьютер и устанавливаем сертификат ( можно выбрать автоматический выбор, он станет в папку личное).
Обновляем страницу. Запрашивает сертификат? Выбираем. Есть доступ.
Вот краткие шаги. Если что-то не сработало, то что-то вы упустили или ошиблись. В вашем комменте например easyrsa-subca, что вы прописали в скрипте, ошибка. Если это так, а сама директория называется, как в Мане у меня. То сертификат и вовсе не должен выпуститься скриптом. Если делали все вручную, то не забывайте про полную цепочку сертификатов - RootCA на клиентском (но это конечно не обязательно), а server.crt и SubCA.crt нужно объединить в один именно в данной последовательности и это обязательно!
Скрипты писались под старую версию Easy-RSA. Сейчас используется обновленная версия, в которой при отзыве Easy-RSA сам удаляет файлы. В скрипте, который уже у вас, можете или проигнорировать (ошибки эти ни на что не влияют) или удалить в скрипте вот это строки:
Ну вариант с двухуровневой иерархией у меня тоже с 5-ого раза получился, а с одним СА было куда проще. И в первоначальном варианте я тоже использовал не голый Easy-RSA, а вперемежку с openssl.
Что касается SSLEngine - выше я вставлял это в пример. И этот параметр подразумевается сам собой т.к. все это делается сразу под https. Будет ли авторизация работать по http не знаю, не пробовал и даже не задумывался об этом. Возможно вы правы в том, что надо было явно указать этот параметр и в пункте включения авторизации.
Кнопка пропала, потому что эту функцию надо включить в конфиге джитси. А Jibri может не работать по многим причинам от слабого сервера, до неправильных/неполных настроек Jibri/Jitsi. Если внимательно будуте идти по ману, то все получится!
Если внимательно прочитать статью, то в ней говорится об этом
В процессе установки будет запрошен IP сервера или его dns имя. Если сервер должен работать с мобильными приложениями, то должно быть dns имя и ssl сертификат. Далее утилита спросит про сертификат ( первый вариант применим для автоматического подписания сертификата, при условии что IP адрес белый и есть dns-имя, второй – если уже есть сертификат, но тогда надо будет еще указать пути, где лежат сертификаты). Важное замечание: для подключения андроид устройств нужно добавить третий сертификат и прописать к нему путь в apache/nginx.
я не считаю Wireguard более популярным. Да и работал с ним я всего пару раз.
Это бесконечный цикл: одни блокируют, другие ищут новые способы это обойти. А блокируют не только OpenVPN трафик, но и Wireguard, strongswang, softeather и другие. Вопрос в том, как замаскировать свой трафик так, чтобы его сложнее было распознать.
Это вторая проблема, пушить столько маршрутов на конечное устройство - многие устройства просто не потянут. Но инвертировать список это уже сложнее. Для примера нам надо чтобы по стране нашего местонахождения трафик выходил с первого сервера, а весь остальной мир со второго. А теперь считаем: в IPv4 - 4 294 967 296 адресов, в условной стране их пусть будет 200 000. Вопрос: что легче и быстрее обработать (в том числе и серверу) 200 000 адресов, а все остальное пересылать на другой сервер или оставшиеся 4 294 767 296 адресов?
потому что если пушить будет VPN1, то клиент будет ходить на эти адреса через VPN сервер, но на остальные будет ходить мимо туннеля. А VPN2 должен пушить все адреса не входящие в список.
с долей правды)
Да, вы правы, однако:
1. Это название оригинальной статьи
2. Если это случилось, то запрос "Расшифровать файлы" и т.п. будет раньше и с большей вероятностью в гугле, чем переделать/восстановить/переписать метаданные данные и т.д.
Не знаю как comp-lzo работает с обфускацией, но во-первых, это устаревшая функция, а во-вторых, она небезопасна и имеет уязвимости.
Вместо нее теперь можно использовать “compress lz4”.
Я уже даже представил рекламу: - Низкая самооценка из-за лишнего веса? Проблемы с противоположным полом из-за скромности и нерешительности? Боязливость и пугливость? Не беда! Ведь есть "Таксоплазмос". С "таксопласмозом" все эти проблемы пропадут. Спрашивайте в аптеках вашего города.
Интернет - самый плохой врач. Читать конечно интересно, но начинаешь думать, а нет ли чего такого у меня. А тут еще и кошка просится ее погладить. Вот как ее теперь гладить)))
Создавая RootCA его сертификат будет в pki/ca.crt
После создаём SubCA и делаем запрос на подпись и подписываем у RootCA. Оба сертификата возвращаем на SubCA. Оба сертификата помещаем в easyrsa-subca/pki/ . Не забываем про символьную ссылку для сертификата SubCA.
Создаём инфраструктуру и запускаем скрипт. Выпускаем ssl сертификат для веб сервера. И помещаем его на сервер. В качестве ssl.crt указываем сертификат в имени которого есть fullchain.crt. Рестартуем веб сервер. Сертификат RootCA устанавливаем на клиентском компьютере в раздел доверенных корневых сертификатов ( как-то так, на винде он второй в списке под папкой личное). Проверяем сайт.
Возвращаемся на SubCA и запускаем скрипт и выпускаем клиентский сертификат. Сертификат с расширением .p12 отправляем на клиентский компьютер. А сами идём на веб сервер.
В конфиге прописываем авторизацию по ssl и указываем сертификат с RootCA. Он будет служить для проверки подписи.
Ещё раз перезапускаем веб.
Идём на клиентский компьютер и устанавливаем сертификат ( можно выбрать автоматический выбор, он станет в папку личное).
Обновляем страницу. Запрашивает сертификат? Выбираем. Есть доступ.
Вот краткие шаги. Если что-то не сработало, то что-то вы упустили или ошиблись. В вашем комменте например easyrsa-subca, что вы прописали в скрипте, ошибка. Если это так, а сама директория называется, как в Мане у меня. То сертификат и вовсе не должен выпуститься скриптом. Если делали все вручную, то не забывайте про полную цепочку сертификатов - RootCA на клиентском (но это конечно не обязательно), а server.crt и SubCA.crt нужно объединить в один именно в данной последовательности и это обязательно!
Скрипты писались под старую версию Easy-RSA. Сейчас используется обновленная версия, в которой при отзыве Easy-RSA сам удаляет файлы. В скрипте, который уже у вас, можете или проигнорировать (ошибки эти ни на что не влияют) или удалить в скрипте вот это строки:
Я не знаю таких. Если только webmin, но может он то, что вам надо или нет - не знаю.
Ну вариант с двухуровневой иерархией у меня тоже с 5-ого раза получился, а с одним СА было куда проще. И в первоначальном варианте я тоже использовал не голый Easy-RSA, а вперемежку с openssl.
Сделайте все как тут и сработает)
Что касается SSLEngine - выше я вставлял это в пример. И этот параметр подразумевается сам собой т.к. все это делается сразу под https. Будет ли авторизация работать по http не знаю, не пробовал и даже не задумывался об этом. Возможно вы правы в том, что надо было явно указать этот параметр и в пункте включения авторизации.
Поздравляю) По себе знаю, как неприятно долго колупаться над какой-то проблемой, а в итоге она оказывается в мелочи.
Кнопка пропала, потому что эту функцию надо включить в конфиге джитси. А Jibri может не работать по многим причинам от слабого сервера, до неправильных/неполных настроек Jibri/Jitsi. Если внимательно будуте идти по ману, то все получится!
Если внимательно прочитать статью, то в ней говорится об этом
Сертификаты ssl нужны и все заработает.
В вебе или приложение?
С переменными всегда так, сначала долго придумываешь имя, а потом ещё дольше его вспоминаешь)