Да, у нас есть ядро и плагины, для ядра есть версии. Все хранится в гитлабе. Есть наш внутренний сервис обновления, который устанавливает патчи на все или выбранные серверы, все или выбранные магазины.
Некоторые магазины могут пользоваться определенными версиями ядра, это указывается в настройках магазина. Кроме того, можно переопределять классы ядра и плагинов в выбранных проектах. Так что у нас нет жесткой привязки всех магазинов к версии ядра.
Собственно, мы начинали уже давно с индивидуальных проектов, и только потом уже собрали клонирующего робота, поэтому возможность кастомизации отдельных проектов заложена изначально. В том числе переноса на выделенные серверы или кластеры серверов. Но это уже, конечно, на заказ…
Облачные решения хороши тем, что позволяют экономить, и это особенно важно, если компания только начинает работать. Но риски действительно есть, так же как они есть и в том случае, когда предприниматель доверяется своей ИТ-компании.
Что касается обновлений, то это, конечно, у всех по разному. Мы, например, относимся к этому с осторожностью, обновления выпускаем в виде патчей с возможностью отката на предыдущую версию.
В основном предубеждения против использования SAAS-сервисов возникают из-за опасения, что провайдер SAAS получит доступ к данным компании. Однако, во-первых, есть договор, по которому SAAS-сервис не может использовать данные клиента, а во-вторых, гораздо большая опасность исходит от инсайдеров.
Сотрудники компании, имеющие доступ, например, к данным о клиентах и поставщиках, обладающие навыками ведения определенного бизнеса, могут использовать эти данные для открытия собственного бизнеса, и такие случаи реально бывают.
С другой стороны, создание собственного ИТ-отдела может обойтись в весьма крупную сумму, и ежемесячный фонд зарплаты тоже получится немаленьким.
Решение тут за предпринимателем — есть ли у него средства на создание своего ИТ отдела, доверяет ли он своим ИТ-сотрудникам, или же таких средств нет, и разумнее воспользоваться SAAS-сервисом. С учетом того, что свои инсайдеры могут оказаться опаснее сотрудников провайдера SAAS.
Зависит от того, куда именно, может в какие-нибудь гос. учреждения и можно. Я и говорю, дополнительно нужны административные меры и работа с кадрами. А вот если гос. учреждение должно работать с гражданами через интернет, то придется что-нибудь придумывать.
Отключение — надежный способ. Но можно, например, сфотографировать экран рабочего компьютера на смартфон и тут же отправить снимок через интернет. Даже если не разрешать использовать флешки, утечки возможны. А еще можно сломать интранет и получить доступ к другому компьютеру в этой сети, отключенной от интернета. Т.е. еще нужны административные меры и работа с кадрами.
Импортируйте запрос в PKI, используя в качестве короткого имени developer1:
$ cd /home/ca/easy-rsa-master/easyrsa3
$ ./easyrsa import-req /mnt/flash/client.req developer1
Далее подпишите запрос на получение сертификата:
$ ./easyrsa sign-req client developer1
После ввода подтверждения и пароля приватного ключа CA будет создан сертификат:
/home/ca/easy-rsa-master/easyrsa3/pki/issued/developer1.crt
Запишите файл developer1.crt на USB флэш-диск, чтобы перенести его на хост клиента OpenVPN.
Т.е. вам нужно на машине CA сделать из запроса сертификат и перенести сертификат на рабочую станцию.
Процесс создания сертификата многоступенчатый, любая ошибка приведет к неудаче.
Постарайтесь следовать инструкции из статьи как можно точнее.
Опишите в деталях, как именно вы создаете запрос на подпись и как создаете сертификат. Я пробовал это на Windows 7 по инструкции из статьи, все получилось.
port 1194
proto udp
dev tun
user openvpn
group openvpn
cd /etc/openvpn
persist-key
persist-tun
tls-server
tls-timeout 120
dh /etc/openvpn/dh.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/vpn-server.crt
key /etc/openvpn/server.key
...
А вот фрагмент файла server.conf для клиента:
dev tun
proto udp
remote 192.168.0.54 1194
client
resolv-retry infinite
ca "/etc/openvpn/ca.crt"
cert "/etc/openvpn/developer1.crt"
key "/etc/openvpn/client.key"
tls-auth "/etc/openvpn/ta.key" 1
...
Как видите, там прописаны пути к разным ключам. На сервере — это путь к файлу ключа сервере server.key, а на клиенте — к файлу ключа client.key.
Да, у нас файл конфигурации для клиента называется server.conf, как и для сервера.
Но в версии для клиента в нем нет пути до server.key. Вместо этого там есть: key "/etc/openvpn/client.key".
Т.е. когда вы создаете файл конфигурации для клиента, в нем должен быть путь к файлу ключа клиента, а не сервера. Именно такие примеры конфигураций для клиента приведены в статье.
Название файла конфигурации server.conf для клиента, возможно, не слишком удачное, но так уже мы сделали в нашем примере.
Еще раз, файл server.conf содержит:
— для сервера — путь к ключу сервера;
— для клиента — путь к ключу клиента.
Да, у нас этот файл называется одинаково и на сервере, и на клиенте:
«Файл openssl.cnf, определяющий конфигурацию OpenSSL, используйте точно такой же, как и для сервера OpenVPN. Что касается файла server.conf для клиента OpenVPN, то для начала возьмите его из нашей статьи.»
Секретный ключ должен оставаться на сервере, а клиенту передается только публичный ключ.
У каждого клиента на своем хосте должен быть сгенерирован свой секретный ключ, и он не должен никуда передаваться.
На самом деле файл /usr/local/etc/openvpn/server.key не упоминается в конфигурации клиента:
dev tun
proto udp
remote 192.168.0.54 1194
client
resolv-retry infinite
ca "/etc/openvpn/ca.crt"
cert "/etc/openvpn/developer1.crt"
key "/etc/openvpn/client.key"
tls-auth "/etc/openvpn/ta.key" 1
remote-cert-tls server
persist-key
persist-tun
comp-lzo
verb 3
status /var/log/openvpn/openvpn-status.log 1
status-version 3
log-append /var/log/openvpn/openvpn-client.log
Ага. Вот я тоже как-то сходил к кардиологу, чуть не госпитализировали. Пришлось обследовать сосуды.
Теперь стараюсь бороться с зависимостью от кофе. Тяжело, но деваться некуда…
Пожалуй) Кстати, мы используем ImageMagick для изменения размера фотографий. Избыточно, но он делает это довольно качественно.
Мне давно хотелось попробовать Squid на какой-нибудь задаче, т.к. обычно мы используем Nginx.
В Squid настроить проксирование HTTPS и FTP оказалось для меня проще.
На самом деле мы используем авторизацию по ключам для упрощения доступа обычных пользователей-разработчиков, и в некоторых других случаях, но ограничение по IP для SSH применяем тоже для большей защищенности и запрета сканирования.
Считаю, что незачем открывать то, что можно не открывать — принцип минимального доступа )
Что касается radius, tacacs и AD, то мы этим не пользуемся, нам просто незачем.
Некоторые магазины могут пользоваться определенными версиями ядра, это указывается в настройках магазина. Кроме того, можно переопределять классы ядра и плагинов в выбранных проектах. Так что у нас нет жесткой привязки всех магазинов к версии ядра.
Собственно, мы начинали уже давно с индивидуальных проектов, и только потом уже собрали клонирующего робота, поэтому возможность кастомизации отдельных проектов заложена изначально. В том числе переноса на выделенные серверы или кластеры серверов. Но это уже, конечно, на заказ…
Что касается обновлений, то это, конечно, у всех по разному. Мы, например, относимся к этому с осторожностью, обновления выпускаем в виде патчей с возможностью отката на предыдущую версию.
В основном предубеждения против использования SAAS-сервисов возникают из-за опасения, что провайдер SAAS получит доступ к данным компании. Однако, во-первых, есть договор, по которому SAAS-сервис не может использовать данные клиента, а во-вторых, гораздо большая опасность исходит от инсайдеров.
Сотрудники компании, имеющие доступ, например, к данным о клиентах и поставщиках, обладающие навыками ведения определенного бизнеса, могут использовать эти данные для открытия собственного бизнеса, и такие случаи реально бывают.
С другой стороны, создание собственного ИТ-отдела может обойтись в весьма крупную сумму, и ежемесячный фонд зарплаты тоже получится немаленьким.
Решение тут за предпринимателем — есть ли у него средства на создание своего ИТ отдела, доверяет ли он своим ИТ-сотрудникам, или же таких средств нет, и разумнее воспользоваться SAAS-сервисом. С учетом того, что свои инсайдеры могут оказаться опаснее сотрудников провайдера SAAS.
$ cd /home/ca/easy-rsa-master/easyrsa3
$ ./easyrsa import-req /mnt/flash/client.req developer1
Далее подпишите запрос на получение сертификата:
$ ./easyrsa sign-req client developer1
После ввода подтверждения и пароля приватного ключа CA будет создан сертификат:
/home/ca/easy-rsa-master/easyrsa3/pki/issued/developer1.crt
Запишите файл developer1.crt на USB флэш-диск, чтобы перенести его на хост клиента OpenVPN.
Т.е. вам нужно на машине CA сделать из запроса сертификат и перенести сертификат на рабочую станцию.
Процесс создания сертификата многоступенчатый, любая ошибка приведет к неудаче.
Постарайтесь следовать инструкции из статьи как можно точнее.
Оказывается, ошибка была в разделе «Файлы конфигурации OpenVPN», а я смотрел в первой части статьи.
А вот фрагмент файла server.conf для клиента:
Как видите, там прописаны пути к разным ключам. На сервере — это путь к файлу ключа сервере server.key, а на клиенте — к файлу ключа client.key.
Но в версии для клиента в нем нет пути до server.key. Вместо этого там есть: key "/etc/openvpn/client.key".
Т.е. когда вы создаете файл конфигурации для клиента, в нем должен быть путь к файлу ключа клиента, а не сервера. Именно такие примеры конфигураций для клиента приведены в статье.
Название файла конфигурации server.conf для клиента, возможно, не слишком удачное, но так уже мы сделали в нашем примере.
Еще раз, файл server.conf содержит:
— для сервера — путь к ключу сервера;
— для клиента — путь к ключу клиента.
Иначе оно вообще работать не будет.
«Файл openssl.cnf, определяющий конфигурацию OpenSSL, используйте точно такой же, как и для сервера OpenVPN. Что касается файла server.conf для клиента OpenVPN, то для начала возьмите его из нашей статьи.»
Возможно, не лучшее решение.
У каждого клиента на своем хосте должен быть сгенерирован свой секретный ключ, и он не должен никуда передаваться.
На самом деле файл /usr/local/etc/openvpn/server.key не упоминается в конфигурации клиента:
dev tun
proto udp
remote 192.168.0.54 1194
client
resolv-retry infinite
ca "/etc/openvpn/ca.crt"
cert "/etc/openvpn/developer1.crt"
key "/etc/openvpn/client.key"
tls-auth "/etc/openvpn/ta.key" 1
remote-cert-tls server
persist-key
persist-tun
comp-lzo
verb 3
status /var/log/openvpn/openvpn-status.log 1
status-version 3
log-append /var/log/openvpn/openvpn-client.log
При установке OpenVPN на Linux с новыми ядрами, начиная с 2.6, интерфейс TUN может не появится. При этом в логах появляется ошибка:
Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-tun insteadЧтобы избавиться от проблемы, добавьте в файл /etc/modprobe.d/dist.conf строку:
alias netdev-tun tunЕсли такого файла нет, его следует создать. После внесения изменений в файл /etc/modprobe.d/dist.conf перезагрузите ОС.
Теперь стараюсь бороться с зависимостью от кофе. Тяжело, но деваться некуда…
Мне давно хотелось попробовать Squid на какой-нибудь задаче, т.к. обычно мы используем Nginx.
В Squid настроить проксирование HTTPS и FTP оказалось для меня проще.
Считаю, что незачем открывать то, что можно не открывать — принцип минимального доступа )
Что касается radius, tacacs и AD, то мы этим не пользуемся, нам просто незачем.