Compare commits
6 Commits
f357571bbf
...
b726f0997d
| Author | SHA1 | Date |
|---|---|---|
|
|
b726f0997d | |
|
|
32433545fc | |
|
|
587ee1468d | |
|
|
45ab71cceb | |
|
|
13d3381fae | |
|
|
06edef55d7 |
Binary file not shown.
|
After Width: | Height: | Size: 204 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 131 KiB |
|
|
@ -0,0 +1,78 @@
|
|||
---
|
||||
title: Выпускаем свой сертификат через свой CA
|
||||
description:
|
||||
published: true
|
||||
date: 2024-04-24T09:45:43.127Z
|
||||
tags: ssl
|
||||
editor: markdown
|
||||
dateCreated: 2024-04-24T09:45:43.127Z
|
||||
---
|
||||
|
||||
Сейчас без HTTPS не хотят работать многие сервисы. А даже если и работают, то браузеры не дадут спокойно пользоваться. Поэтому приходится получать и настраивать сертификаты, даже если большой нужды в этом нет. Особенно если ты работаешь с ним один в локальной сети, либо вообще поднимаешь временно. Я обычно получаю сертификаты let's encrypt и копирую на нужный сервер, если к нему не проброшен доступ из интернета.
|
||||
|
||||
Решил подготовить пошаговую инструкцию, чтобы быстро выпустить свой сертификат через свой CA, добавив его к себе в доверенные, чтобы браузеры не ругались. Во многих ситуациях это будет удобнее, чем постоянно обновлять доверенные сертификаты через интернет. Свой можно выпустить вечным. Покажу на примере настройки сертификата в Nginx.
|
||||
|
||||
Будем выпускать сертификат для доменного имени zabbix.internal и IP адреса 172.30.245.222. Будет работать и так, и эдак.
|
||||
|
||||
Выпускаем ключ и сертификат для своего CA:
|
||||
```
|
||||
# mkdir ~/tls && cd ~/tls
|
||||
# openssl ecparam -out myCA.key -name prime256v1 -genkey
|
||||
# openssl req -x509 -new -nodes -key myCA.key -sha256 -days 9999 -out myCA.crt
|
||||
```
|
||||
Вам зададут серию вопросов. Отвечать можно всё, что угодно. В данном случае это не важно. Выпускаем ключ и сертификат для сервера:
|
||||
```
|
||||
# openssl genrsa -out zabbix.internal.key 2048
|
||||
# openssl req -new -key zabbix.internal.key -out zabbix.internal.csr
|
||||
```
|
||||
Тут тоже зададут похожие вопросы. Отвечать можно всё, что угодно. Готовим конфигурационный файл:
|
||||
```
|
||||
# mcedit zabbix.internal.ext
|
||||
|
||||
authorityKeyIdentifier=keyid,issuer
|
||||
basicConstraints=CA:FALSE
|
||||
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
|
||||
subjectAltName = @alt_names
|
||||
|
||||
[alt_names]
|
||||
IP.1 = 172.30.245.222
|
||||
DNS.1 = zabbix.internal
|
||||
```
|
||||
Генерируем сертификат на его основе:
|
||||
```
|
||||
# openssl x509 -req -in zabbix.internal.csr -CA myCA.crt -CAkey myCA.key \
|
||||
-CAcreateserial -out zabbix.internal.crt -days 9999 -sha256 -extfile zabbix.internal.ext
|
||||
```
|
||||
Копируем сертификат и ключ в директорию веб сервера:
|
||||
```
|
||||
# mkdir /etc/nginx/certs
|
||||
# cp zabbix.internal.crt /etc/nginx/certs/.
|
||||
# cp zabbix.internal.key /etc/nginx/certs/.
|
||||
```
|
||||
Создаём файл dhparam, который понадобится для конфигурации Nginx:
|
||||
```
|
||||
# openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
|
||||
```
|
||||
Добавляем в конфиг Nginx в целевом виртуальном хосте:
|
||||
```
|
||||
listen 443 http2 ssl;
|
||||
server_name zabbix.internal 172.30.245.222;
|
||||
ssl_certificate /etc/nginx/certs/zabbix.internal.crt;
|
||||
ssl_certificate_key /etc/nginx/certs/zabbix.internal.key;
|
||||
ssl_dhparam /etc/ssl/certs/dhparam.pem;
|
||||
```
|
||||
Перезапускаем Nginx:
|
||||
```
|
||||
# nginx -t
|
||||
# nginx -s reload
|
||||
```
|
||||
Передаём на свой компьютер файл myCA.crt и добавляем его в хранилище корневых доверенных центров сертификации. Настройка будет зависеть от операционной системы. Если нужно тут же, локально на сервере с Debian 12 настроить доверие этому CA, то делаем так:
|
||||
```
|
||||
# cp myCA.crt /usr/local/share/ca-certificates/.
|
||||
# update-ca-certificates
|
||||
```
|
||||
Теперь можно браузером заходить по доменному имени или IP адресу, будет работать самоподписанный сертификат на 9999 дней без каких-либо предупреждений.
|
||||
|
||||
Получилась готовая инструкция для копипаста, которую можно сохранить и пользоваться.
|
||||
|
||||

|
||||
|
|
@ -0,0 +1,69 @@
|
|||
---
|
||||
title: Обход блокировок через VPN (privoxy)
|
||||
description:
|
||||
published: true
|
||||
date: 2024-04-24T09:54:39.876Z
|
||||
tags: privoxy, vpn
|
||||
editor: markdown
|
||||
dateCreated: 2024-04-24T09:54:39.876Z
|
||||
---
|
||||
|
||||
Западные блокировки в интернете добавляют лишнюю суету в повседневную работу. Я вам покажу очень простой и быстрый способ, как их обходить на примере загрузки и запуска продуктов elastic. Как известно, с территории РФ их скачать невозможно, как и воспользоваться репозиторием docker образов.
|
||||
|
||||
Для этого нам понадобится любая VPS и доступ к ней по SSH. Главное, чтобы с неё ничего не блокировалось. Ставим туда локальную прокси privoxy:
|
||||
|
||||
`# apt install privoxy`
|
||||
|
||||
Больше можно ничего не настраивать. Нам подойдут настройки по умолчанию. Прокси сама запустится на локальном интерфейсе 127.0.0.1:8118. Можно тут её оставить на постоянную работу.
|
||||
|
||||
Теперь идём на сервер, куда мы хотим установить elasticsearch. Если мы просто попытаемся скачать пакет, у нас ничего не выйдет:
|
||||
|
||||
`# wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.13.2-amd64.deb`
|
||||
HTTP request sent, awaiting response... 403 Forbidden
|
||||
|
||||
Доступ заблокирован. Подключимся по SSH к серверу с privoxy и пробросим её порт 8118 локально на машину на порт 3128:
|
||||
|
||||
`# ssh -L 3128:localhost:8118 root@1.2.3.4`
|
||||
|
||||
Проверяем, что порт проброшен:
|
||||
|
||||
`# ss -tulnp | grep 3128`
|
||||
```
|
||||
tcp LISTEN 0 128 127.0.0.1:3128 0.0.0.0:* users:(("ssh",pid=1350,fd=5))
|
||||
```
|
||||
Теперь сделаем так, чтобы wget работал через прокси. Для этого рисуем конфиг ~/.wgetrc:
|
||||
```
|
||||
use_proxy=yes
|
||||
http_proxy=127.0.0.1:3128
|
||||
https_proxy=127.0.0.1:3128
|
||||
```
|
||||
И снова скачиваем пакет. Теперь он успешно загрузится, можно устанавливать.
|
||||
|
||||
Если хочется запустить elasticsearch в докере из официального образа, то подключаем прокси докеру. Для этого передаём ему переменные через systemd. Все возможные варианты настройки прокси в докере описаны в документации (https://docs.docker.com/config/daemon/systemd/).
|
||||
|
||||
`# mkdir -p /etc/systemd/system/docker.service.d`
|
||||
`# mcedit /etc/systemd/system/docker.service.d/http-proxy.conf`
|
||||
```
|
||||
[Service]
|
||||
Environment="HTTP_PROXY=http://127.0.0.1:3128"
|
||||
Environment="HTTPS_PROXY=http://127.0.0.1:3128"
|
||||
```
|
||||
` # systemctl daemon-reload`
|
||||
` # systemctl restart docker`
|
||||
|
||||
Обращаю внимание, что в качестве HTTPS_PROXY я передаю http подключение. Это важно. Privoxy не настроен на работу по https, а Docker хочет именно по https забирать образы. Проверим, что переменные объявлены:
|
||||
|
||||
`# systemctl show --property=Environment docker`
|
||||
```
|
||||
Environment=HTTP_PROXY=http://127.0.0.1:3128 HTTPS_PROXY=http://127.0.0.1:3128
|
||||
```
|
||||
Теперь можно забрать образ последней версии и запустить его:
|
||||
|
||||
`# docker pull docker.elastic.co/elasticsearch/elasticsearch:8.13.2`
|
||||
`# docker run -d -e "discovery.type=single-node" -p 9200:9200 -p 9300:9300 docker.elastic.co/elasticsearch/elasticsearch:8.13.2`
|
||||
|
||||
После того, как всё скачано и запущено, настройки прокси можно отключить.
|
||||
|
||||
Такой простой и быстрый метод с использованием своего прокси. Не надо искать сторонние репозитории или настраивать свои. Не надо подключать VPN и что-то ставить дополнительно на исходный сервер. Забрали всё с репозитория разработчиков, сделав минимум движений на сервере, куда всё устанавливали.
|
||||
|
||||

|
||||
Loading…
Reference in New Issue