Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    [РЕШЕНО] Запуск трёх веб-серверов на гостевых машинах в приватной сети при одном публичном IP

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    [РЕШЕНО] Запуск трёх веб-серверов на гостевых машинах в приватной сети при одном публичном IP, Proxmox Виртуальная Среда
     
    adrian_vg
    Guest
    #1
    0
    10.03.2020 21:01:00
    Всем привет! Запустил свой первый хост Proxmox и теперь планирую создать три отдельных веб-сервера: один будет вести главную страницу, второй — Nextcloud, а третий — галерею изображений. Раньше я использовал правила переадресации на роутере, чтобы направлять весь веб-трафик на один сервер, где главная страница, Nextcloud и галерея работали как виртуальные хосты. Это было немного неудобно по разным причинам, и теперь я хочу разделить эти три сервиса на три отдельных гостевых системы.

    У меня также есть зарегистрированный домен:  
    https://adrianvg.com → виртуальный хост главной страницы  
    https://adrianvg.com/nextcloud → виртуальный хост Nextcloud  
    https://adrianvg.com/gallery → виртуальный хост галереи

    Из того, что я прочитал в интернете, предлагают использовать разный порт для каждого сервера, например, здесь: https://forum.proxmox.com/threads/multiple-vps-behind-one-public-ip.1681/post-9177  
    10.10.10.3:10991 — nextcloud  
    10.10.10.4:10992 — главная страница  
    10.10.10.5:10993 — галерея

    И тут у меня начинается проблема. Как понять, что запросы на порт 10991 должны идти в Nextcloud, если все входящие обращения идут с порта 443?  

    Входящие обращения выглядят примерно так:  
    Имя сервиса | Исходный IP | Диапазон портов | Локальный IP | Локальный порт | Протокол  
    https | *.*.*.* | 443 | 10.10.10.3 | 10991 | TCP  
    https | *.*.*.* | 443 | 10.10.10.4 | 10992 | TCP  
    https | *.*.*.* | 443 | 10.10.10.5 | 10993 | TCP

    Есть ли какой-то лучший способ сделать это на хосте Proxmox? Может, пробросить все внешние входящие подключения на порт 443 на Proxmox, где будет работать apache, который будет перенаправлять https://adrianvg.com/nextcloud на 10.10.10.3:10991, https://adrianvg.com/ на 10.10.10.4:10992 и так далее? Если использовать apache как прокси, может, вообще не придется ставить разные порты?

    Я никак не могу понять, как это настроить. Как обычно это делается? Что проще всего? Буду признателен за любые советы и подсказки! Заранее спасибо.

    Общая схема моей сети тут: https://forum.proxmox.com/threads/m...ss-proxmox-guests-from-lan.66733/#post-299871

    Мой текущий конфиг /etc/network/interfaces на Proxmox:  
    root@dragonborn:~# cat /etc/network/interfaces

    auto lo  
    iface lo inet loopback

    auto eno1  
    # "реальный" IP на skynet-tng.internal  
    iface eno1 inet static  
    address 192.168.0.9  
    netmask 255.255.255.0  
    gateway 192.168.0.1

    iface eno2 inet manual  
    iface eno3 inet manual  
    iface eno4 inet manual

    auto vmbr0  
    # приватная подсеть  
    iface vmbr0 inet static  
    address 10.10.10.1  
    netmask 255.255.255.0  
    bridge_ports none  
    bridge_stp off  
    bridge_fd 0

    post-up echo 1 > /proc/sys/net/ipv4/ip_forward  
    post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE  
    post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE

    //AvG
     
     
     
    adrian_vg
    Guest
    #2
    0
    27.03.2020 09:17:00
    Задавал вопрос на форуме Joomla. Посмотрим, смогут ли они что-нибудь предложить.
     
     
     
    Rares
    Guest
    #3
    0
    27.03.2020 11:23:00
    Мы тоже используем Apache в роли обратного прокси, примерно так, как описал @adrian_vg. Также Apache занимается SSL-терминацией с помощью letsencrypt. Дополнительно мы усилили защиту, требуя пароли или ограничивая доступ по IP для определённых путей, например, /wp-admin. В качестве защиты от перебора паролей (brute force) используем csf, который мониторит логи Apache. Если вы заходите на /login.php более 5 раз в минуту, ваш IP блокируется на сутки.
     
     
     
    adrian_vg
    Guest
    #4
    0
    07.11.2020 19:20:00
    Всем привет! С марта я сделал большую переработку, попытался починить кое-что и узнать больше о реверс-прокси. Уже добился того, что мой Joomla сайт работает на SSL и всё у меня на proxmox. Все запросы на порты 80 и 443 из интернета форвардятся в роутере на виртуалку с Joomla. В этом Joomla-вм есть блок vhost с настройками реверс-прокси, который смотрит на мою виртуалку Nextcloud. Доступ к моему Joomla сайту по зарегистрированному домену example.com работает нормально. Проблемы начинаются, когда пытаюсь зайти в Nextcloud. С внутренней сети на cloud.example.com заходит нормально, значит, реверс-прокси вроде работает, но в адресной строке показывает внутренний IP 192.168.0.10. А вот с интернета доступ к cloud.example.com не работает. Не знаю, что с этим делать или что я мог напортачить в процессе экспериментов... Буду признателен за любые советы. Ниже основные конфигурации сайтов, которые я использую. Кто-нибудь может помочь? Спасибо! * example.com, конечно, — это прикрытие настоящего домена. Я добавил субдомен "cloud" через регистратора домена, как дополнение к основному example.com. Сделал CNAME с cloud.example.com, который указывает обратно на example.com, надеюсь, сделал это правильно. И ещё, почему у меня работает всё на основном Joomla-сайте example.com, а на cloud.example.com нет? Конфиги apache vhost почти одинаковые. joomla.conf на example.com включает блок для cloud.example.com. <virtualhost cloud.example.com> #SSLProxyEngine On  # Проверял с этим и без — разницы не заметил ProxyPreserveHost On ProxyRequests off ProxyPass / https://cloud.srbu.se/ ProxyPassReverse / https://cloud.srbu.se/ </virtualhost> Nextcloud.conf на cloud.example.com содержит стандартные настройки ssl и т.д. <VirtualHost cloud.example.com:80> ServerAdmin webmaster@example.com ServerName cloud.example.com DocumentRoot /var/www/nextcloud Redirect permanent / https://cloud.example.com ErrorLog /var/log/apache2/nextcloud-80-error.log CustomLog /var/log/apache2/nexcloud-80.log common #RewriteEngine on #RewriteCond %{SERVER_NAME} =cloud.example.com #RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent] </VirtualHost> <virtualhost cloud.example.com:443> ServerAdmin webmaster@example.com ServerName cloud.example.com DocumentRoot /var/www/nextcloud SSLEngine on SSLProxyEngine on # SSLProxyVerify none # SSLProxyCheckPeerCN off # SSLProxyCheckPeerName off ProxyPreserveHost On ProxyRequests off # SetOutputFilter INFLATE;proxy-html;DEFLATE; # ProxyHTMLInterp On # ProxyHTMLExtended On # ProxyHTMLURLMap (.*)192.168..10(.*) https://cloud.example.com$2 [Rin] # ProxyVia On # <Proxy *> # Require host cloud.example.com # </Proxy> Header always set Strict-Transport-Security "max-age=63072000" # RequestHeader set X-Forwarded-Port "443" RequestHeader set X-Forwarded-Host cloud.example.com # RemoteIPHeader X-Forwarded-For RequestHeader set X-Forwarded-Proto "https" <IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains" </IfModule> ErrorLog /var/log/apache2/nextcloud-443-error.log CustomLog /var/log/apache2/nexcloud-443.log common SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA38> SSLHonorCipherOrder on <Directory "/var/www/cgi-bin"> SSLOptions +StdEnvVars </Directory> SSLCertificateFile /etc/ssl/2020-11-07/certificate.crt SSLCertificateKeyFile /etc/ssl/2020-11-07/private.key SSLCertificateChainFile /etc/ssl/2020-11-07/ca_bundle.crt #Include /etc/letsencrypt/options-ssl-apache.conf RewriteEngine On RewriteRule ^/\.well-known/carddav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L] RewriteRule ^/\.well-known/caldav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L] </virtualhost>
     
     
     
    adrian_vg
    Guest
    #5
    0
    17.02.2021 17:24:00
    Потребовался почти год, но теперь у меня есть рабочее решение. Поскольку я познакомился с Docker какое-то время назад, было лишь вопросом времени, когда я открыю для себя вот эту штуку: https://github.com/jc21/nginx-proxy-manager. Короче говоря, интегрировать её с моими уже настроенными веб-сервисами с SSL оказалось проще простого. Сейчас на Proxmox у меня работает docker-ВМ с nginx, который корректно перераспределяет весь трафик между главной страницей и ВМ-серверами облачного хранилища. Следующим этапом хочу разобраться, почему эта штука работает, а моё самодельное решение с обратным прокси — нет. Но это уже другая история, и, скорее всего, не для этого форума. Всем спасибо, кто комментировал и подсказывал!
     
     
     
    bobmc
    Guest
    #6
    0
    17.02.2021 20:45:00
    Да, это отличный способ управлять nginx — жаль, что только через Docker. Было бы здорово, если бы кто-то смог перенести это в шаблон для LXC.
     
     
     
    adrian_vg
    Guest
    #7
    0
    18.02.2021 08:12:00
    Мне показалось, что я видел гайд, где кто-то использовал это с контейнером Proxmox, когда я искал информацию о docker proxy managers. Попробую найти его снова. А пока вот симпатичная страница с инструкцией по проекту jc12's nginx proxy manager: https://nginxproxymanager.com/setup/
     
     
     
    adrian_vg
    Guest
    #8
    0
    18.02.2021 08:14:00
    Нашёл! Смотри сюда: https://nginxproxymanager.com/third-party/.
     
     
     
    KenVjn
    Guest
    #9
    0
    18.02.2021 22:28:00
    Отличная работа. Спасибо!
     
     
     
    AndyRed
    Guest
    #10
    0
    18.02.2021 22:33:00
    Привет, @adrian_vg! Пара мыслей для тебя...

    Контейнер: ubuntu 20.04  
    vCPU: 1  
    RAM: 256MB — это работает, но ты всегда можешь увеличить ресурсы, если трафик вырастет.

    ЗАМЕТКИ:  
    1. LXC-контейнер, чтобы всё было максимально легким и с возможностью динамически расширять vCPU/RAM по мере необходимости.  
    2. Ubuntu 20.04, потому что это предельно просто.  
    3. # apt install haproxy  
    4. Если все твои сайты работают через SSL (предположим, что так), и ты используешь https://letsencrypt.org/ для бесплатных сертификатов на каждом контейнере/виртуальной машине (как делаю я), тогда у тебя будет балансировка нагрузки на уровне 4-го уровня (L4) через TCP.  
    5. SSL-сессии не будут завершаться на HAProxy, а будут "пробрасываться" по их FQDN, а завершаться уже на серверах.  
    6. Такая конфигурация позволяет настроить DNS так, чтобы много разных FQDN указывали на один IP.

    Что касается использования HAProxy и примера конфигурации для достижения цели — я подготовил простой контейнер и настроил для HAProxy вот такой конфиг:

    Code:  
    root@haproxy:/etc/haproxy# more haproxy.cfg  
    global  
           log /dev/log    local0  
           log /dev/log    local1 notice  
           chroot /var/lib/haproxy  
           stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners  
           stats timeout 30s  
           user haproxy  
           group haproxy  
           daemon  

           # Default SSL material locations  
    #       ca-base /etc/ssl/certs  
    #       crt-base /etc/ssl/private  

           # See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate  
    #        ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CH  
    ACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384  
    #        ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256  
    #        ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets  

    defaults  
           log     global  
           mode    http  
           option  httplog  
           option  dontlognull  
           timeout connect 5000  
           timeout client  50000  
           timeout server  50000  
           errorfile 400 /etc/haproxy/errors/400.http  
           errorfile 403 /etc/haproxy/errors/403.http  
           errorfile 408 /etc/haproxy/errors/408.http  
           errorfile 500 /etc/haproxy/errors/500.http  
           errorfile 502 /etc/haproxy/errors/502.http  
           errorfile 503 /etc/haproxy/errors/503.http  
           errorfile 504 /etc/haproxy/errors/504.http  

    # Один VIP  
    frontend ft_ssl_vip  
     bind 192.168.1.2:443  
     mode tcp  

     tcp-request inspect-delay 5s  
     tcp-request content accept if { req_ssl_hello_type 1 }  

     default_backend bk_ssl_default  

    # Используем SNI для решения, куда направлять трафик  
    backend bk_ssl_default  
     mode tcp  

     acl app01 req_ssl_sni -i app01.domain.com  
     acl app02 req_ssl_sni -i app02.domain.com  
     acl app03 req_ssl_sni -i app03.domain.com  

     use-server app01 if app01  
     use-server app02 if app02  
     use-server app03 if app03  

     option ssl-hello-chk  
     server app01 192.168.1.10:443 check  
     server app02 192.168.1.11:443 check  
     server app03 192.168.1.12:443 check  

    Эта конфигурация работает безупречно. Надеюсь, она окажется полезной для тебя.  
    Энди
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

    Конфиденциальность Оферта
    © 2026 Proxmox.su
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры