«Lightdm - после входа пользователя просит ввести пароль для разблокировки связки ключей...» и «HAPROXY. Работаем ssl to ssl с генерацией сертификатов отдельно на каждом сервере»: разница между страницами

Материал из support.qbpro.ru
(Различия между страницами)
imported>Vix
(Новая страница: «У меня настроен автологин в графический терминал пользователя, от имени которого далее …»)
 
imported>Vix
(Новая страница: «'''В рамках данного туториала настроим реверс прокси для работы наших сайтов в прозрачно...»)
 
Строка 1: Строка 1:
У меня настроен автологин в графический терминал пользователя, от имени которого далее пускаются некоторые графические программы. Для удаленного контроля в Debian Lenny я настроил VNC-подключение стандартными средствами Gnome с доступом по паролю.
'''В рамках данного туториала настроим реверс прокси для работы наших сайтов в прозрачном режиме за 10 минут. Поехали.'''


В Debian Squeeze этот метод работает, но после ввода правильного пароля вместо изображения отображается черный экран. При этом, если посмотреть на настоящем мониторе, Gnome выдает следующее сообщение:


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


<syntaxhighlight lang="shell" line='line'>
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 }


Таким образом, подключиться удаленно к системе по VNC можно только после того, как пользователь помимо автологина с паролем вводит еще раз свой пароль на клавиатуре для разблокировки связки ключей. Опять же, это стандартное "нововведение" Gnome Keyring дает проблемы тут. Что удивительно, так это то, что галочки "разблокировать при входе в систему" тут нет. С другой стороны, при подключении по SSH такого желания у системы нет.
backend bk_app1
mode tcp
balance leastconn
option tcp-check
server main 192.168.1.26:443 send-proxy check


Решение:
backend bk_app2
Установить пустой мастер-пароль на брелок в seahorse:
mode tcp
balance leastconn
option tcp-check
server main 192.168.1.38:443 send-proxy check


удалить содержимое папки
backend bk_app3
~/.gnome2/keyrings
mode tcp
запустить
balance leastconn
seahorse
option tcp-check
создать связку ключей без пароля: Файл→Создать→Связка ключей для паролей и создаём брелок с именем "login"
server main 192.168.1.37:443 send-proxy check
заново установить пароль для подключений по VNC.


Для LXDE:
backend bk_app4
mode tcp
balance leastconn
option tcp-check
server main 192.168.1.100:443 check


заходим в
backend bk_app5
  ./local/share/keyring
mode tcp
удаляем там все файлы, после чего по запросу gnomekeyring создаем пустой пароль.
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
  </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 контейнер потребление по ресурсам упало почти до пары единиц процентов ресурсов хост машины и можно сказать что ничего не потребляет.