«Debian сертификаты openvpn» и «HAPROXY. Работаем ssl to ssl с генерацией сертификатов отдельно на каждом сервере»: разница между страницами

Материал из support.qbpro.ru
(Различия между страницами)
imported>Vix
Нет описания правки
 
imported>Vix
(Новая страница: «'''В рамках данного туториала настроим реверс прокси для работы наших сайтов в прозрачно...»)
 
Строка 1: Строка 1:
Описаний установки и настройки системы Open VPN в интернете очень много, но как правило все рекомендации сводятся или к общему описанию того как должна быть организована эта система или пошаговая настройка какого то конкретного дистрибутива Linux или BSD зачастую без толковых описаний своих действий.
'''В рамках данного туториала настроим реверс прокси для работы наших сайтов в прозрачном режиме за 10 минут. Поехали.'''
  Все что здесь будет описано выполнялось на '''Linux Debian Squeeze'''. Все действия я буду подробно описывать, что и зачем выполняется,
  в случае если кто то воспользуется этой статьей для настройки на другом дистрибутиве '''Linux''' или операционной системе.
* Первый этап это установка необходимых пакетов, в моем случае из стандартного репозитария: '''openvpn и openvpn-blacklist''', с подтверждением всех необходимых зависимостей которые запросит программа '''aptitude'''.
* Вторым этапом установка программы '''tinyca''', с помощью которой мы будем генерировать ключи и сертификаты для своего сервера и клиентов, так же я объясню почему предпочтительнее  использование именно этой программы, а не встроенных средств пакета '''openvpn'''.
* В каталоге /etc/openvpn/ создаем каталог easy-rsa а в нем keys (тут будут находиться наши ключи):
  mkdir /etc/openvpn/easy-rsa
  mkdir /etc/openvpn/easy-rsa/keys
* Генерируем 2048 битный ключ с помощью алгоритма '''Диффи Хеллмана''' в /etc/openvpn/easy-rsa/keys
  cd  /etc/openvpn/easy-rsa/keys
  openssl dhparam -out dh2048.pem 2048
* Следующим шагом будет генерация ключей с помощью  '''tinyca''', запускаем программу:
[[Файл:Tiny1.png]]
* Пример заполнения полей для создания открытого ключа:
'''tinyca - генерация основного сертификата'''
[[Файл:Tiny2.png]]
* Пример создания сертификатов для сервера и клиента:
'''tinyca - создание сертификатов для сервера и клиента'''
[[Файл:Tiny5.png]]
* Пример экспорта ключа для сервера и клиента - клик правой кнопкой мышки на сертификат или иконку вверху '''export''':
'''tinyca - экспорт сертификатов в формате PKCS#12'''
[[Файл:Tiny3.png]]
*'''tinyca - экспорт сертификатов пароль основного ключа!'''
[[Файл:Tiny4.png]]
* Теперь копируем ключ сервера в  /etc/openvpn/easy-rsa/keys и настраиваем /etc/openvpn/server.conf по примеру:
  mode server
  tls-server
  daemon
  local 83.221.170.103
  port 1194
  proto tcp-server
  # - используемый тип устройства и номер
  dev tap0
  #указываем файл с ключем сервера
  pkcs12 /etc/openvpn/easy-rsa/keys/server_crt.p12
  #указываем файл Диффи Хельман
  dh /etc/openvpn/easy-rsa/keys/dh2048.pem
  #задаем IP-адрес сервера и маску подсети
  ifconfig 10.10.10.1 255.255.255.0
  #### clients ip
  client-config-dir ccd
  push "route 10.10.10.0 255.255.255.0 10.10.10.1"
  keepalive 10 120 # пинг каждые 10 секунд для поддержания канала связи
  client-to-client
  #########
  #auth MD5
  # включаем шифрацию пакетов
  cipher BF-CBC
  keepalive 10 120
  # сжатие трафика
  comp-lzo
  # максимум клиентов
  max-clients 100
  # Не перечитывать ключи после получения
  # SIGUSR1 или ping-restart
  persist-key
  # Не закрывать и переоткрывать TUN\TAP
  # устройство, после получения
  # SIGUSR1 или ping-restart
  persist-tun
  # логгирование (не забудьте создать эту дирректорию /var/log/openvpn/)
  status /var/log/openvpn/openvpn-status.log
  log /var/log/openvpn/openvpn.log
  # Уровень информации для отладки
  verb 5
* Выполняем команду разрешающую dh 2048
  touch /usr/share/openssl-blacklist/blacklist.RSA-2048


* Разрешаем трансляцию ip адресов openvpn
    mcedit /etc/sysctl.conf


    net.ipv4.conf.default.rp_filter=1
Мною была поставлена задача что бы на моем сервере под руководством Proxmox с пулом сайтов работала без проблем прозрачная маршрутизация между посетителем и конечным сайтом. Т.к. в инете полно мануалов по базовой настройке Haproxy я столкнулся с проблемой что 99% этих статей описывают работ прокси сервера в режиме терминации а дальше информация идет по не защищенному варианту (от прокси до конечной ВМ). Меня это не устроило и я начал искать по крупицам информацию в сети. К сожалению в нашем русскоязычном сегменте ее мало (читай нет) пришлось шерстить буржуйский сегмент. Конечный результат предлагаю вашему вниманию, думаю кому ни будь он точно сгодится.
    net.ipv4.conf.all.rp_filter=1


* Фиксируем размер MTU не больше основного канала..
<syntaxhighlight lang="shell" line='line'>
  echo "1">/proc/sys/net/ipv4/ip_no_pmtu_disc
global
log /dev/log    local0
log /dev/log    local1 notice
stats socket /haproxy-admin.sock mode 660 level admin
stats timeout 30s
daemon
defaults
maxconn 2000
mode http       
log global
option dontlognull # bind *:443 ssl crt .
option http-server-close
timeout http-request 10s
timeout connect        5000
timeout client          50000
timeout server        50000
frontend stats
bind *:5000
stats enable
stats uri /stats
stats refresh 10s
stats auth admin:mysupersecretpassword #поменяйте на свой пароль
</syntaxhighlight>
Блок отвечающий за работу ssl на ssl
<syntaxhighlight lang="shell" line='line'>
frontend env_ssl_frontend
bind *:443
mode tcp
option tcplog
tcp-request inspect-delay 10s
tcp-request content accept if { req_ssl_hello_type 1 }
use_backend bk_app1 if { req.ssl_sni -m end site1.ru }
use_backend bk_app2 if { req.ssl_sni -m end counter.site1.ru }
use_backend bk_app3 if { req.ssl_sni -m end site2.com } 
use_backend bk_app4 if { req.ssl_sni -m end site3.msk.ru }
use_backend bk_app5 if { req.ssl_sni -m end site4.ru }
use_backend bk_app6 if { req.ssl_sni -m end site5.msk.ru }


* Теперь необходимо прописать то, что будут получать клиенты по dhcp, когда пройдет авторизация, файлы должны лежать в /etc/openvpn/ccd
backend bk_app1
  echo >klient.crt
mode tcp
  mcedit /etc/openvpn/ccd/klient.crt (имя файла - это имя common name сертификата в программе '''tinyca'''; по нему и происходит присвоение...)
balance leastconn
  ### далее настройки в файле klient.crt
option tcp-check
  # приcваиваем ip-адрес
server main 192.168.1.26:443 send-proxy check
  ifconfig-push 10.10.10.11 255.255.255.0
  # присваиваем наш внутренний dns server
  push dhcp-option DNS 10.10.10.1
  # присваиваем dns domain suffix - для win машин очень актуально
  push dhcp-option DOMAIN org
  # роутинг на сети центрального офиса
  push "route 10.10.10.0 255.255.255.0 10.10.10.1"
  # если необходимо то и на другие сети..
  push "route 192.168.5.0 255.255.255.0 10.10.10.1"


* теперь запуск сервера в работу:
backend bk_app2
    /etc/init.d/openvpn start
mode tcp
* следующий этап, настройка клиента openvpn.
balance leastconn
option tcp-check
server main 192.168.1.38:443 send-proxy check


'''Пример конфигурационного файла клиента:'''
backend bk_app3
mode tcp
balance leastconn
option tcp-check
server main 192.168.1.37:443 send-proxy check


client
backend bk_app4
# Use the same setting as you are using on
mode tcp
# the server.
balance leastconn
# On most systems, the VPN will not function
option tcp-check
# unless you partially or fully disable
server main 192.168.1.100:443 check
# the firewall for the TUN/TAP interface.
##;dev tap
dev tap0
# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
#proto udp
proto tcp  
# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
#remote my-server-1 1194
##;remote my-server-2 1194
remote 83.221.170.103 1194
# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite
# Most clients don't need to bind to
# a specific local port number.
nobind
# Downgrade privileges after initialization (non-Windows only)
#user nobody
#group nobody
# Try to preserve some state across restarts.
persist-key
persist-tun
# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
#;http-proxy-retry # retry on connection failures
#;http-proxy [proxy server] [proxy port #]
# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
#;mute-replay-warnings
# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
#ca ca.crt
#cert client.crt
#key client.key
dh dh2048.pem
### - сертификат клиента!
pkcs12 client-crt.p12
# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server".  This is an
# important precaution to protect against
# a potential attack discussed here:
#  http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server".  The build-key-server
# script in the easy-rsa folder will do this.
ns-cert-type server
# If a tls-auth key is used on the server
# then every client must also have the key.
#;tls-auth ta.key 1
# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
#;cipher x
#cipher AES-128-CBC
# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo
# Set log file verbosity.
verb 4
# Silence repeating messages
mute 20


и на последок, канал внутри канала необходимо также настраивать, например если у вас MTU на внешнем 1500,
backend bk_app5
значит внутренний канал VPN MTU не должен быть больше, а рекомендуемый параметр в данном случае 1496 или 1442
mode tcp
выставляется на клинете параметром '''tun-mtu'''
balance leastconn
tun-mtu 1496
option tcp-check
server main 192.168.1.31:443 send-proxy check


опыт показывает, что при соединении по 3G MTU канала как правило не выше 1400, чаще 962 - 1276
backend bk_app6
соответственно берем параметр внешнего канала и отнимаем 62.
balance leastconn
полученное значение присваиваем подключаемому клиенту.
mode tcp
option tcp-check
server main 192.168.1.200:443 check
</syntaxhighlight>
Блок отвечающий за работу сайтов на 80 порту
<syntaxhighlight lang="shell" line='line'>
frontend public
        bind *:80
 
        # бок сайтов
        acl host_subdomain1 hdr(host) -i site1.ru
        acl host_subdomain2 hdr(host) -i counter.site1.ru
        acl host_subdomain3 hdr(host) -i site2.com
        acl host_subdomain4 hdr(host) -i site3.msk.ru
        acl host_subdomain5 hdr(host) -i site4.ru
        acl host_subdomain6 hdr(host) -i site5.msk.ru
        ## блок acl
        use_backend subdomain1 if host_subdomain1
        use_backend subdomain2 if host_subdomain2
        use_backend subdomain3 if host_subdomain3
        use_backend subdomain4 if host_subdomain4
        use_backend subdomain5 if host_subdomain5
        use_backend subdomain6 if host_subdomain6
 
backend subdomain1
        option httpclose
        option forwardfor
        cookie JSESSIONID prefix
        server subdomain-1 192.168.1.26:80 check
 
backend subdomain2
        option httpclose
        option forwardfor
        cookie JSESSIONID prefix
        server subdomain-2 192.168.1.37:80 check
 
backend subdomain3
        option httpclose
        option forwardfor
        cookie JSESSIONID prefix
        server subdomain-3 192.168.1.31:80 check
 
backend subdomain4
        option httpclose
        option forwardfor
        cookie JSESSIONID prefix
        server subdomain-4 192.168.1.100:80 check
 
backend subdomain5
        option httpclose
        option forwardfor
        cookie JSESSIONID prefix
        server subdomain-5 192.168.1.200:80 check
 
backend subdomain6
        option httpclose
        option forwardfor
        cookie JSESSIONID prefix
        server subdomain-6 192.168.1.38:80 check   
</syntaxhighlight>
Что мы получили в итоге:
 
Генерация ssl сертификатов происходит на каждом сайте отдельно. Терминации на прокси сервере нет, идет прозрачное перенаправление на конечную машину которая и отдает посетителю свой ssl сертификат.
Проблем с Яндексом и его роботом дятлом (который мониторит сайт на доступность) не имеем.
Имеем быстрый и корректный отклик конечной машины для посетителей и поисковиков.
В качестве небольшого бонуса, имеем страничку с статистикой работы прокси сервера и сайтов которые он обслуживает. Для этого перейдите на ip (например у меня 192.168.1.150:5000) на котором он работает с портом 5000 и наслаждайтесь. Логин admin а пароль который вы сами установили в верхней секции этого конфига.
 
* Отдельно хочу сделать замечание касаемо этого файла конфигурации Haproxy.
 
Весьма вероятно, что когда вы добавите в свой пул сайтов на PROXMOKS-e еще N кол-во виртуальных машин и вам понадобится получить сертификат с Letsencrypt, у вас может не получится это, тк Haproxy не сможет корректно отработать запрос и от вашей машины и к вашей машине.
В таком случае (под диванного сервера) сделайте выход c роутера (или что там у вас) проброс портов на новую ВМ, хотя бы 80 порт и после получения сертификата верните обратно. По крайней мере я так вышел из этой ситуации. Подробнее о проблеме описано по ссылке
 
 
Как всегда, приветствуются конструктивные предложения и замечания.
 
Всем успехов!
 
 
PS Сам реверс прокси у меня поднят и прекрасно себя чувствует на Ubuntu 18.04 которая идет в шаблонах Proxmox-a. По началу я его запускал в режиме полноценной виртуалки но это решение себя не оправдало тк потребляло изрядную процессорную и прочие ресурсы хост машины. С переводом прокси сервера на LXC контейнер потребление по ресурсам упало почти до пары единиц процентов ресурсов хост машины и можно сказать что ничего не потребляет.
 
* [https://habr.com/ru/post/540212/ взято тут]

Текущая версия от 19:27, 30 ноября 2021

В рамках данного туториала настроим реверс прокси для работы наших сайтов в прозрачном режиме за 10 минут. Поехали.


Мною была поставлена задача что бы на моем сервере под руководством Proxmox с пулом сайтов работала без проблем прозрачная маршрутизация между посетителем и конечным сайтом. Т.к. в инете полно мануалов по базовой настройке Haproxy я столкнулся с проблемой что 99% этих статей описывают работ прокси сервера в режиме терминации а дальше информация идет по не защищенному варианту (от прокси до конечной ВМ). Меня это не устроило и я начал искать по крупицам информацию в сети. К сожалению в нашем русскоязычном сегменте ее мало (читай нет) пришлось шерстить буржуйский сегмент. Конечный результат предлагаю вашему вниманию, думаю кому ни будь он точно сгодится.

global
log /dev/log    local0
log /dev/log    local1 notice
stats socket /haproxy-admin.sock mode 660 level admin
stats timeout 30s
daemon
defaults
maxconn 2000
mode http        
log global
option dontlognull # bind *:443 ssl crt .
option http-server-close
timeout http-request 10s
timeout connect         5000
timeout client          50000
timeout server         50000
frontend stats
bind *:5000
stats enable
stats uri /stats
stats refresh 10s
stats auth admin:mysupersecretpassword #поменяйте на свой пароль

Блок отвечающий за работу ssl на ssl

frontend env_ssl_frontend
bind *:443
mode tcp
option tcplog
tcp-request inspect-delay 10s
tcp-request content accept if { req_ssl_hello_type 1 }
use_backend bk_app1 if { req.ssl_sni -m end site1.ru }
use_backend bk_app2 if { req.ssl_sni -m end counter.site1.ru }
use_backend bk_app3 if { req.ssl_sni -m end site2.com }  
use_backend bk_app4 if { req.ssl_sni -m end site3.msk.ru }
use_backend bk_app5 if { req.ssl_sni -m end site4.ru }
use_backend bk_app6 if { req.ssl_sni -m end site5.msk.ru }

backend bk_app1
mode tcp
balance leastconn
option tcp-check 
server main 192.168.1.26:443 send-proxy check

backend bk_app2
mode tcp
balance leastconn
option tcp-check
server main 192.168.1.38:443 send-proxy check

backend bk_app3
mode tcp
balance leastconn
option tcp-check
server main 192.168.1.37:443 send-proxy check

backend bk_app4
mode tcp
balance leastconn
option tcp-check
server main 192.168.1.100:443 check

backend bk_app5
mode tcp
balance leastconn
option tcp-check
server main 192.168.1.31:443 send-proxy check

backend bk_app6
balance leastconn
mode tcp
option tcp-check
server main 192.168.1.200:443 check

Блок отвечающий за работу сайтов на 80 порту

frontend public
        bind *:80

        # бок сайтов
        acl host_subdomain1 hdr(host) -i site1.ru 
        acl host_subdomain2 hdr(host) -i counter.site1.ru
        acl host_subdomain3 hdr(host) -i site2.com
        acl host_subdomain4 hdr(host) -i site3.msk.ru
        acl host_subdomain5 hdr(host) -i site4.ru
        acl host_subdomain6 hdr(host) -i site5.msk.ru
        ## блок acl 
        use_backend subdomain1 if host_subdomain1
        use_backend subdomain2 if host_subdomain2
        use_backend subdomain3 if host_subdomain3
        use_backend subdomain4 if host_subdomain4
        use_backend subdomain5 if host_subdomain5
        use_backend subdomain6 if host_subdomain6

backend subdomain1
        option httpclose
        option forwardfor
        cookie JSESSIONID prefix
        server subdomain-1 192.168.1.26:80 check

backend subdomain2
        option httpclose
        option forwardfor
        cookie JSESSIONID prefix
        server subdomain-2 192.168.1.37:80 check

backend subdomain3
        option httpclose
        option forwardfor
        cookie JSESSIONID prefix
        server subdomain-3 192.168.1.31:80 check

backend subdomain4
        option httpclose
        option forwardfor
        cookie JSESSIONID prefix
        server subdomain-4 192.168.1.100:80 check

backend subdomain5
        option httpclose
        option forwardfor
        cookie JSESSIONID prefix
        server subdomain-5 192.168.1.200:80 check

backend subdomain6
        option httpclose
        option forwardfor
        cookie JSESSIONID prefix
        server subdomain-6 192.168.1.38:80 check

Что мы получили в итоге:

Генерация ssl сертификатов происходит на каждом сайте отдельно. Терминации на прокси сервере нет, идет прозрачное перенаправление на конечную машину которая и отдает посетителю свой ssl сертификат. Проблем с Яндексом и его роботом дятлом (который мониторит сайт на доступность) не имеем. Имеем быстрый и корректный отклик конечной машины для посетителей и поисковиков. В качестве небольшого бонуса, имеем страничку с статистикой работы прокси сервера и сайтов которые он обслуживает. Для этого перейдите на ip (например у меня 192.168.1.150:5000) на котором он работает с портом 5000 и наслаждайтесь. Логин admin а пароль который вы сами установили в верхней секции этого конфига.

  • Отдельно хочу сделать замечание касаемо этого файла конфигурации Haproxy.

Весьма вероятно, что когда вы добавите в свой пул сайтов на PROXMOKS-e еще N кол-во виртуальных машин и вам понадобится получить сертификат с Letsencrypt, у вас может не получится это, тк Haproxy не сможет корректно отработать запрос и от вашей машины и к вашей машине. В таком случае (под диванного сервера) сделайте выход c роутера (или что там у вас) проброс портов на новую ВМ, хотя бы 80 порт и после получения сертификата верните обратно. По крайней мере я так вышел из этой ситуации. Подробнее о проблеме описано по ссылке


Как всегда, приветствуются конструктивные предложения и замечания.

Всем успехов!


PS Сам реверс прокси у меня поднят и прекрасно себя чувствует на Ubuntu 18.04 которая идет в шаблонах Proxmox-a. По началу я его запускал в режиме полноценной виртуалки но это решение себя не оправдало тк потребляло изрядную процессорную и прочие ресурсы хост машины. С переводом прокси сервера на LXC контейнер потребление по ресурсам упало почти до пары единиц процентов ресурсов хост машины и можно сказать что ничего не потребляет.