synology.forum архив спільноти · 2005–2022
ai.synology.forum →
ГлавнаяУправление Системой › Управление Synology за прокси (прямой доступ)

Управление Synology за прокси (прямой доступ)

mugz · 22.02.2015

В общем суть такова, что стандартная настройка DSM меня совершенно не устраивает. Особенно вариант, что все службы (или приложения) разбросаны по разным портам (от 5000 до 9000) и приходится эти порты пробрасывать на роутере. Так-же не устраивает, что все службы доступны по любому адресу привязанному к DSM (особенно если у вас там есть несколько различных сайтов). Получается примерно следующая картинка:

 

Вы можете попасть на свой DSM и нужную службу по любому из адресов и только так:

- site1.mydomain.com:5000

- site2.mydomain.com:7000

и т.д.

 

Учитывая еще тот факт, что на корпоративном прокси у нас закрыто всё, кроме 80 и 443 порта - данный вариант мне совершенно не подходил.

Хотелось больше возможностей виртуальных хостов и вынести все ресурсы на стандартные порты.

Стандартными средствами - сделать этого я не смог. Ибо все службы жестко настроены и мы, кроме как поменять номер порта, больше ничего и не можем. А, ну и в 5.1 DSM заметил, что можно назначить приложения на виртуальную папку, которая всё равно перебросит вас на адрес: site:port.

Идея у меня была проста. Чтобы при обращении к site1.domain.com открывалась сразу панель управления DSM

Прошерстив форумы, нашел вариант использования reverse proxy (mod_proxy) встроенного в apache DSM.

 

Взяв полученную информацию за основу, удалось добиться следующего:

http://site1.mydomain.com (стандартный 80 порт) - открывает панель управления DSM (которая весит на 5000 порту)

https://site1.mydimain.com (443 порт) - открывает тоже самое, но на 5001 порту.

 

Дальше - больше. Хотел сделать что-то типа:

https://site2.mydomain.com - открывает Photostation

https://site3.mydomain.com - открывает Downloadstation

и всё в таком духе…

 

Но тут столкнулся с тем, что на каждый такой сайт - нужен свой сертификат (а платить кучу денег за multidomain возможности нет)

 

Тогда я решил попробовать сделать всё таким образом:

 

https://site1.mydomain.com/ - DSM admin

https://site1.mydomain.com/photo - PhotoStation

https://site1.mydomain.com/download - DownloadStation

https://site1.mydomain.com/webdav - WebDav

https://site1.mydomain.com/music - AudioStation

https://site1.mydomain.com/file - FileStation

 

И я сделал это! Ниже идут конфиги и небольшая инструкция, как всё это сделано. Решение не идеальное и есть некоторое количество мелких проблем, которые не смог решить. Например:

- По другому адресу, всё-же можно открыть PhotoStation

- Запуск из DSM Admin Photostation - ведёт на локальный адрес.

 

Но у этого решения есть и плюсы:

- Не надо делать проброску портов во внутреннюю сеть (кроме 80 и 443)

- Всё прекрасно работает с рабочего места за прокси

- Переключение между службами идет не вбиванием соответствующего порта, а простой ссылкой на папку.

 

Итак. Приступим.

 

Для начала нам надо создать файл, где будут лежать наш конфиг. Идеальным местом для меня - это папка в home пользователя admin (файл не пропадет при следующем обновлении DSM)

 

Создаём файл:

/home/admin/configs/httpd_vhosts.conf

 

Дальше, необходимо добавить его в конфиг httpd сервера.

Редактируем файл:

/etc/httpd/conf/httpd.conf-user

 

и добавляем в конец строку:

include /var/services/homes/admin/configs/httpd_vhosts.conf

 

Важный момент: Мы прописываем путь /var/services/homes вместо /volume1/homes потому, что у вас может быть более одного тома и папка homes может находится по другому адресу. /var/services/homes всегда ссылается на верный адрес.

 

Затем дописываем в файл httpd_vhosts.conf следующее:

 

# Загружаем модули, если они не загружены
<IfModule !proxy_module>
    LoadModule proxy_module modules/mod_proxy.so
</IfModule>
<IfModule !proxy_connect_module>
    LoadModule proxy_connect_module modules/mod_proxy_connect.so
</IfModule>
<IfModule !proxy_http_module>
    LoadModule proxy_http_module modules/mod_proxy_http.so
</IfModule>
<IfModule !proxy_ftp_module>
    LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
</IfModule>

# Определяем виртуальный HTTP хост
NameVirtualHost *:80
<VirtualHost *:80>
  ServerName site1.mydomain.com

# Добавляем / в конец запроса (если слэша там нет). Без этого, при запросе типа http://site1.mydomain.com/video - откроется пустая страница.
# В нашем случае перебросит на страницу http://site1.mydomain.com/video/
  RewriteEngine On
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^/?download$ /download/ [r]
  RewriteRule ^/?webdav$ /webdav/ [r]
  RewriteRule ^/?photo$ /photo/ [r]
  RewriteRule ^/?music$ /music/ [r]
  RewriteRule ^/?video$ /video/ [r]
  RewriteRule ^/?surv$ /surv/ [r]
  RewriteRule ^/?mail$ /mail/ [r]
  RewriteRule ^/?file$ /file/ [r]

# Настраиваем reverse proxy
  ProxyRequests Off
  ProxyVia Off
    <Proxy *>
      Order deny,allow
      Allow from all
  </Proxy>
  ProxyPass /download/ http://localhost:8000/
  ProxyPass /webdav/ https://localhost:5005/
  ProxyPass /photo/ http://localhost/photo/
  ProxyPass /music/ http://localhost:8800/
  ProxyPass /video/ http://localhost:9007/
  ProxyPass /surv/ http://localhost:9900/
  ProxyPass /mail/ http://localhost/mail/
  ProxyPass /file/ http://localhost:7000/
  ProxyPass / http://localhost:5000/
  ProxyPassReverse / http://localhost:5000/
</VirtualHost>

# Здесь настраивает всё тоже самое, но для HTTPS
<IfDefine SSL>
NameVirtualHost *:443
<VirtualHost *:443>
  ServerName site1.mydomain.com
  SSLEngine on
  SSLProxyEngine on
  SSLProtocol all -SSLv2

#  Обязательно убедитесь в наличии файлов сертификатов
  SSLCertificateFile /usr/syno/etc/ssl/ssl.crt/server.crt
  SSLCertificateKeyFile /usr/syno/etc/ssl/ssl.key/server.key
  SSLCACertificateFile /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt
  RewriteEngine On
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^/?download$ /download/ [r]
  RewriteRule ^/?webdav$ /webdav/ [r]
  RewriteRule ^/?photo$ /photo/ [r]
  RewriteRule ^/?music$ /music/ [r]
  RewriteRule ^/?video$ /video/ [r]
  RewriteRule ^/?surv$ /surv/ [r]
  RewriteRule ^/?mail$ /mail/ [r]
  RewriteRule ^/?file$ /file/ [r]
  ProxyRequests Off
  ProxyVia Off
    <Proxy *>
      Order deny,allow
      Allow from all
  </Proxy>
  ProxyPass /download/ https://localhost:8001/
  ProxyPass /webdav/ https://localhost:5006/
  ProxyPass /photo/ https://localhost/photo/
  ProxyPass /music/ https://localhost:8801/
  ProxyPass /video/ https://localhost:9008/
  ProxyPass /surv/ https://localhost:9901/
  ProxyPass /mail/ https://localhost/mail/
  ProxyPass /file/ https://localhost:7001/
  ProxyPass / https://localhost:5001/
  ProxyPassReverse / https://localhost:5001/
</VirtualHost>
</IfDefine>

 

ADD1: Также, для функционирования https host - надо закоментить две строки в /etc/httpd/conf/extra/httpd-ssl.conf-user

 

#    ServerName *
#    ServerAlias *

 

Без этого работать не будет.

 

После того, как сохраним файл, перезапускаем web службы командой:

synoservicectl --restart httpd-user

Если ошибок не будет - то можете пользоваться!

 

P.S. С удовольствием жду замечания/дополнения/исправления/вопросы

Тимур Рахимов · 23.02.2015

У меня есть несколько вопросов, если позволите.

 

1. Скажите, а в чём состоят эти проблемы (по вашему описанию я это не понял):

Решение не идеальное и есть некоторое количество мелких проблем, которые не смог решить. Например:

- По другому адресу, всё-же можно открыть PhotoStation

- Запуск из DSM Admin Photostation - ведёт на локальный адрес.

 

2. Вот вы пишете, что на каждый сайт (виртуальный хост в рамках конфигурации) нужен свой сертификат. А почему бы не оставить один сертификат на все хосты или использовать самоподписанные сертификаты? Конечно, при этом браузеры будут предупреждать при подключении, что сертификатам нет доверия, и пользователя это может напугать, но если всё это нужно только для вас самих или круг пользователей ограничен, то почему бы нет? В конце концов, есть startssl.com, где с некоторыми ограничениями, но всё-таки можно получить сколько угодно бесплатных доверенных сертификатов на поддомены вашего домена.

 

3. Скажите, а зачем вы подгружаете модули mod_proxy_connect и mod_proxy_ftp? В них была какая-то необходимость?

 

4. А зачем у вас ProxyVia Off там стоит? Без него не работает? Вроде бы эта опция и так «off» по умолчанию.

 

И ещё мне немного странным показалось, зачем потребовалось целую гирлянду редиректов вида RewriteRule ^/?download$ /download/ [r] вешать. Apache-то редиректы на адрес с конечным слэшем, если он опущен, автоматически делает (ну, если за какой-то важной надобностью директивой DirectorySlash Off не предписано обратное). Могу, правда, предположить, почему без слэша не работает — директива ProxyPassReverse, которая как раз служит для того, чтобы редиректы в обратную сторону через прокси корректно проходили, почему-то только для одного ProxyPass написана, а надо для всех. И, кстати, пользоваться директивами RewriteRule без веской причины документация к Apache настоятельно не рекомендует, она низкоуровневая и очень капризная, поведение кода начинает зависеть от разных мелочей (сам на эти грабли наступил однажды — после перехода с DSM 4.3 на DSM 5.0 у меня всё перестало работать, пришлось всю конфигурацию переписывать, выкинув не по делу применяемые RewriteRule и заменив их, в том числе, директивами Redirect, в крайнем случае, RedirectMatch).

 

Да, и верная команда для перезапуска пользовательского экземпляра Apache в DSM (так, чтобы сама DSM была в курсе, что сервис перезапускается), это synoservicectl --restart httpd-user (httpd -k restart тоже перезапустит веб-сервер, но уверенности в том, что перезапущен будет именно нужный экземпляр — их там три, и что это будет сделано корректно, с учётом «интересов» зависимых процессов, нет).

mugz · 23.02.2015
У меня есть несколько вопросов, если позволите.

 

1. Скажите, а в чём состоят эти проблемы (по вашему описанию я это не понял):

 

Ну например у меня не работает https на все сервисы с работы. Там прокси стоит.

 

2. Вот вы пишете, что на каждый сайт (виртуальный хост в рамках конфигурации) нужен свой сертификат. А почему бы не оставить один сертификат на все хосты или использовать самоподписанные сертификаты? Конечно, при этом браузеры будут предупреждать при подключении, что сертификатам нет доверия, и пользователя это может напугать, но если всё это нужно только для вас самих или круг пользователей ограничен, то почему бы нет? В конце концов, есть startssl.com, где с некоторыми ограничениями, но всё-таки можно получить сколько угодно бесплатных доверенных сертификатов на поддомены вашего домена.

Самоподписанные требуют подтверждения, на каждый хост подписывать сертификат и потом его ручками в коняги добавлять - долго.

 

3. Скажите, а зачем вы подгружаете модули mod_proxy_connect и mod_proxy_ftp? В них была какая-то необходимость?

Это наследие от экспериментов и сторонних конфигов. Особенно не разбирался.

 

4. А зачем у вас ProxyVia Off там стоит? Без него не работает? Вроде бы эта опция и так «off» по умолчанию.

 

Рекомендовали так сделать;

 

И ещё мне немного странным показалось, зачем потребовалось целую гирлянду редиректов вида RewriteRule ^/?download$ /download/ [r] вешать. Apache-то редиректы на адрес с конечным слэшем, если он опущен, автоматически делает (ну, если за какой-то важной надобностью директивой DirectorySlash Off не предписано обратное). Могу, правда, предположить, почему без слэша не работает — директива ProxyPassReverse, которая как раз служит для того, чтобы редиректы в обратную сторону через прокси корректно проходили, почему-то только для одного ProxyPass написана, а надо для всех.

 

Если не ставить слэш в конец - то открывается пустая страница, однако если руками закрыть слэшом - то всё ок. ProxyPassReverse для каждого адреса - не помогло в моём случае.

 

И, кстати, пользоваться директивами RewriteRule без веской причины документация к Apache настоятельно не рекомендует, она низкоуровневая и очень капризная, поведение кода начинает зависеть от разных мелочей (сам на эти грабли наступил однажды — после перехода с DSM 4.3 на DSM 5.0 у меня всё перестало работать, пришлось всю конфигурацию переписывать, выкинув не по делу применяемые RewriteRule и заменив их, в том числе, директивами Redirect, в крайнем случае, RedirectMatch).

 

С удовольствием приму ваши рекомендации для упрощения/оптимизации конфигурации с подробным описанием

 

Да, и верная команда для перезапуска пользовательского экземпляра Apache в DSM (так, чтобы сама DSM была в курсе, что сервис перезапускается), это synoservicectl --restart httpd-user (httpd -k restart тоже перезапустит веб-сервер, но уверенности в том, что перезапущен будет именно нужный экземпляр — их там три, и что это будет сделано корректно, с учётом «интересов» зависимых процессов, нет).

 

Я не нашел в инструкции как правильно перезапускать в Syno apache. Перезапускал первым попавшим под руку способом. Спасибо за замечание.

 

P.S. Там еще надо кое что подправить и дописать, сейчас сделаю.

Тимур Рахимов · 28.02.2015

Прошу прощения, небыстро у меня получается ответить (понадобилось провести кое-какие эксперименты, а я тут несколько сейчас ограничен). Потребовалось понять, как на самом деле работает веб-сервер в этом случае (почему он не делает редирект, добавляя слеш в конец автоматически, как в других случаях, и что нужно учесть, чтобы сделать редирект без использования Rewrite).

 

1. Оказалось, что случай с прокси отличается от других конфигураций: во-первых, автоматическое добавление слеша в конец Apache при этом и не должен делать, так задумано (директива DirectorySlash на него не распространяется, она действует только на адреса, соответствующие каталогам на диске), а во-вторых, чтобы применить директиву Redirect для добавления слеша в конец адреса, если его там нет, нужно учитывать, что все директивы ProxyPass отрабатываются раньше всех Redirect (а все директивы Alias, соответственно, позже, после всех них). Выглядеть это всё будет примерно так:

     ProxyPassMatch ^/download$ !
    RedirectMatch ^/download$ /download/

    RedirectMatch ^/download/(.*)$ http://localhost:8000/$1
    ProxyPassReverse /download/ http://localhost:8000/

 

Использовать варианты директив на основе регулярных выражений, RedirectMatch и ProxyPassMatch, здесь потребовалось, чтобы различить случаи со со слешом на конце и без (простые Redirect и ProxyPass с адресом без слеша их объединяют). Можно заметить, что такая конфигурация, без использования Rewrite, несколько более многословная, чем с использованием Rewrite, но зато, как я уже почувствовал на собственном опыте (и говорится в руководстве к Apache, о чём я уже упоминал), более устойчивая, предсказуемая в поведении и надёжная.

 

2. Далее (об этом я хотел сказать ещё в прошлый раз, но забыл). Делать вот так — ProxyPass /photo/ https://localhost/photo/ — означает перенаправлять запрос на себя, выполнять рекурсию. Не знаю уж, как в конкретном случае с этим разбирается Apache (раз у вас работает, то, наверное, как-то с этим справляется осмысленным образом, но, кажется, вы упоминали, что с некоторыми странными эффектами), однако, правильным было бы в этом случае вместо использования прокси просто направлять запрос /photo/ к соответствующей папке на диске (/var/packages/PhotoStation/target/photo). Ведь зачем мы вынуждены использовать reverse proxy в нашем случае? Потому что нам нужно перенаправлять запросы к другому веб-серверу (на устройствах Synology их работает аж три: для веб-интерфейса DSM и ряда служб один, так называемый «системный», для пользовательского веб-сайта, Photo Station, Mail Station и некоторых прочих — другой, так называемый «пользовательский», и отдельно ещё один для WebDAV). Photo Station же, например, работает в рамках того же экземпляра веб-сервера и представляет собой обычное веб-приложение в виде набора файлов, поэтому его нужно просто сопоставить с папкой на диске.

Но обратите внимание на строчку ProxyPass /php-fpm-handler.fcgi !, предусмотреть это исключение оказалось необходимым при переходе к версии DSM 5.XX, потому что с этого момента там стал применяться внешний обработчик PHP-скриптов, и прокси начал перехватывать обращения к нему (напомню ещё раз очень важную вещь: сначала в рамках одного виртуального хоста обрабатываются все ProxyPass, потом только все редиректы, и потом лишь алиасы, если, конечно, очередь к этому моменту до них дойдёт).

 

 

Из других соображений по поводу конкретной конфигурации:

 

3. Модули proxy_connect_module и proxy_ftp_module в нашем случае не нужны, они не используются. Да и два действительно в этом случае нужных модуля, proxy_module и proxy_http_module, подгружать специально не надо, в конфигурации Synology по умолчанию они есть.

 

3. Делать два набора одинаковых настроек, для http и https виртуальных хостов, на мой взгляд, ни к чему. Гораздо практичнее, полагаю, будет в виртуальном хосте на 80-м порту оставить только редирект на 443-й, а всю работу делать там (это тем более важно из соображений безопасности).

 

4. Делать ProxyPass на https-сайт внутри своей локальной сети не вижу особого смысла, внутри неё (а тем более в рамках одной машины, localhost) угрозы безопасности минимальны. Проще и надёжнее будет осуществлять коммуникацию прокси-сервера с локальным веб-сервером по простому http, при этом (прокси сервер принимает запрос по https, расшифровывает его, и передаёт далее уже в открытом виде). Да и нагрузка на процессор при этом снизится, в каких-то случаях это тоже имеет значение.

 

5. Выполнять назначение прав внутри контейнера <Proxy *>...</Proxy> нет необходимости. По умолчанию здесь у Synology и так Allow from all.

 

6. В директиве ProxyVia Off здесь точно так же нет нужды (об этом я, кажется, уже упоминал).

 

7. Единственная необходимая директива, относящаяся к SSL/TLS здесь — это SSLEngine on. Настройки сертификатов, способов шифрации и т. п. вполне можно взять общие (задаются файлом /etc/httpd/conf/extra/httpd-ssl.conf-user), для этого вообще ничего не надо делать, в конфигурации Synology они используются по умолчанию (ну, если соответствующие галочки в настройках включены). Единственное, что нужно сделать, чтобы поправить стандартную конфигурацию, чтобы заставить её работать с нашими виртуальными хостами, это закомментировать строки ServerName * и ServerAlias * в названном файле, о чём вы написали выше, причина этого в том, что виртуальный хост, объявленный там с использованием этих директив, будет перехватывать обращения к любым нашим виртуальным хостам на 443 порту, потому что этот их виртуальный хост находится «выше» по конфигурации (звёздочка означает, что он соответствует любому имени сайта).

 

8. Директива SSLProxyEngine on нужна только для перенаправления запросов на https-адреса, что в нашем случае излишне (см п. 4 выше).

 

 

Таким образом, я бы предложил следующую конфигурацию для нашего случая (указал только одну Download Station для примера, чтобы не перечислять все службы):

 

<VirtualHost *:80>

    ServerName site1.mydomain.com
    Redirect permanent / https://site1.mydomain.com/

</VirtualHost>


<VirtualHost *:443>

    ServerName site1.mydomain.com

    SSLEngine on    
    
    # у нас только reverse прокси, обслуживание запросов со стороны отключаем в целях безопасности
    ProxyRequests Off

    # иначе не будут корректно работать алиасы ниже (обработка их PHP-скриптов будет перехвачена прокси)
    ProxyPass /php-fpm-handler.fcgi !

    
    # кроме обращений на определенные адреса, их следует не передавать через прокси, а направлять в нужный каталог

    ProxyPass /phpMyAdmin !
    Alias /phpMyAdmin /volume1/web/phpMyAdmin

    ProxyPass /mail !
    Alias /mail /var/packages/MailStation/target/roundcubemail
    
    ProxyPass /photo !
    Alias /photo /var/packages/PhotoStation/target/photo

    ProxyPass /webalizer !
    Alias /webalizer /volume1/web/webalizer


    # чтобы ярлык Photo Station на рабочем столе DSM указывал не на IP адрес из  ProxyPass ниже, 
    # а на доменное имя из настроек Photo Station (Настройки/Порт маршрутизатора)
    ProxyPreserveHost On


    # для Download Station (для других служб, работающих от системного экземпляра Apache, добавить аналогичные группы)

    ProxyPassMatch ^/download$ !
    RedirectMatch ^/download$ /download/

    ProxyPassMatch ^/download/(.*)$ http://localhost:8000/$1
    ProxyPassReverse /download/ http://localhost:8000/


    # для веб-интерфейса DSM (необходимо также для перечисленных выше служб, потому что они обращаются к некоторым системным функциям отсюда)

    ProxyPass / http://localhost:5000/
    ProxyPassReverse / http://localhost:5000/
    
</VirtualHost>

mugz · 03.03.2015
Таким образом, я бы предложил следующую конфигурацию для нашего случая (указал только одну Download Station для примера, чтобы не перечислять все службы):

 

Большое спасибо за такой большой и развернутый ответ! Но проблема в том, что ничего не работает с таким конфиком. Ниодна ссылка не открывается, на https не перебрасывает. Вот такие вот дела

Тимур Рахимов · 03.03.2015

А поточнее проблему вы могли бы описать, чтобы мне можно было понять, в чём дело? Я ведь, как сами понимаете, прежде чем публиковать, сначала у себя протестировал. Возможно, в чём-то ваша конфигурация отличается от моей (за пределами перечисленного).

Тимур Рахимов · 03.03.2015

Особенно вот это вот — «на https не перебрасывает» — странно. Там ломаться нечему, один редирект в описании виртуального хоста и всё, ошибиться практически негде. Может быть, у вас имя открываемого сайта с указанным в ServerName не совпадает? И кэш браузера на всякий случай надо бы очистить.

mugz · 03.03.2015
Особенно вот это вот — «на https не перебрасывает» — странно. Там ломаться нечему, один редирект в описании виртуального хоста и всё, ошибиться практически негде. Может быть, у вас имя открываемого сайта с указанным в ServerName не совпадает? И кэш браузера на всякий случай надо бы очистить.

 

Ну при обращении на http://mysite.domain.com не происходит автоматический переход на https://mysite.domain.com, как и открытия админки

 

При попытке загрузить страницу /downloads выдает "сайт не найден" даже при форсированном https подключении

Тимур Рахимов · 03.03.2015

Это выглядит довольно странным, как я уже сказал, и причины здесь, думаю, не в перечисленных строчках, а где-то вне этой конфигурации (иначе бы по крайней мере редирект работал). Покажите, пожалуйста, что у вас выдаёт команда ps|grep httpd?

mugz · 03.03.2015

Держите =)

 

6807 root     15068 S    /usr/bin/httpd -DSSL -DSPDY -DAPPARMOR -f /etc/httpd/conf/httpd.conf-sys
6810 root     71460 S <  /usr/bin/httpd -DSSL -DSPDY -DAPPARMOR -f /etc/httpd/conf/httpd.conf-sys
8179 root     15572 S <  /usr/bin/httpd -DSSL -DSPDY -DAPPARMOR -f /etc/httpd/conf/httpd.conf-sys
8272 root     20144 S    /usr/bin/httpd -DSSL -f /etc/httpd/conf/httpd.conf-webdav
9871 root     26376 S    /var/packages/MediaServer/target/sbin/lighttpd -f /var/packages/MediaServer/target
10388 root     15144 S    /usr/bin/httpd -DSSL -DSPDY -DHAVE_PHP
10391 http     14380 S    /usr/bin/httpd -DSSL -DSPDY -DHAVE_PHP
10581 http      321m S    /usr/bin/httpd -DSSL -DSPDY -DHAVE_PHP
15579 root     19640 S    /usr/bin/httpd -DSSL -f /etc/httpd/conf/httpd.conf-webdav
15606 root     44732 S    /usr/bin/httpd -DSSL -f /etc/httpd/conf/httpd.conf-webdav
15607 root     44732 S    /usr/bin/httpd -DSSL -f /etc/httpd/conf/httpd.conf-webdav

Тимур Рахимов · 03.03.2015

Спасибо. Это потребовалось для подготовки к следующему шагу: показать список виртуальных хостов пользовательского экземпляра веб-сервера, сделайте это тоже, пожалуйста. Для вашего случая команда будет такой (добавляется ключ -S):

 

/usr/bin/httpd -DSSL -DSPDY -DHAVE_PHP -S

mugz · 03.03.2015
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:443                  is a NameVirtualHost
         default server * (/etc/httpd/conf/extra/httpd-ssl.conf:9)
         port 443 namevhost * (/etc/httpd/conf/extra/httpd-ssl.conf:9)
         port 443 namevhost mysite.domain.com (/var/services/homes/admin/configs/httpd_vhosts.conf:48)
*:80                   is a NameVirtualHost
         default server * (/etc/httpd/conf/httpd.conf:189)
         port 80 namevhost * (/etc/httpd/conf/httpd.conf:189)
         port 80 namevhost mysite.domain.com (/var/services/homes/admin/configs/httpd_vhosts.conf:15)
Syntax OK

Тимур Рахимов · 07.03.2015

Опять быстро не получилось ответить, извините. Ваша конфигурация виртуальных хостов выглядела вполне нормально, так что, чтобы не изобретать экзотических причин того, что не работает, пришлось ещё немножко поэкспериментировать. Я восстановил у себя конфигурацию как «из коробки», и довольно быстро обнаружил, что не учёл одной детали. Исходная конфигурация пользовательского экземпляра веб-сервера Synology (в которой не включены виртуальные хосты средствами веб-интерфейса DSM) имеет необходимое объявление NameVirtualHost для порта 443, но почему-то не имеет его для порта 80 (а я на это полагался). Поэтому в начало своего дополнительного конфигурационного файла следует включить (и для наглядности в том числе) эти объявления пространства именованных виртуальных хостов:

 

NameVirtualHost *:80

NameVirtualHost *:443

 

Объявление для порта 443 при этом повторится, но ничего страшного, это допускается синтаксисом.

 

Таким образом, чтобы дополнить стандартную конфигурацию приведённым ниже кодом, необходимо сделать, как минимум, две вещи: 1) поместить его в свой файл и добавить в конец системного конфигурационного файла /etc/httpd/conf/httpd.conf-user строку Include с именем этого своего файла, например, Include /volume1/web/httpd-vhosts.conf и 2) в системном файле /etc/httpd/conf/extra/httpd-ssl.conf-user закомментировать строку ServerAlias * (интересно, что себе там думал тот, кто её туда включал?). Всё. Я проверил это на конфигурации как «из коробки» версии DSM 5.1-5022, работает.

 

Вот код для добавления (замените строку имя.вашего.сайта на реальный доменный адрес):

 

NameVirtualHost *:80
NameVirtualHost *:443


<VirtualHost *:80>

    ServerName имя.вашего.сайта
    Redirect permanent / https://имя.вашего.сайта/

</VirtualHost>


<VirtualHost *:443>

    ServerName имя.вашего.сайта
    SSLEngine on    
    
    # у нас только reverse прокси, обслуживание запросов со стороны отключаем в целях безопасности
    ProxyRequests Off

    # иначе не будут корректно работать алиасы ниже (обработка их PHP-скриптов будет перехвачена прокси)
    ProxyPass /php-fpm-handler.fcgi !

    
    # кроме обращений на определенные адреса, их следует не передавать через прокси, а направлять в нужный каталог

    ProxyPass /phpMyAdmin !
    Alias /phpMyAdmin /volume1/web/phpMyAdmin

    ProxyPass /mail !
    Alias /mail /var/packages/MailStation/target/roundcubemail
    
    ProxyPass /photo !
    Alias /photo /var/packages/PhotoStation/target/photo

    ProxyPass /webalizer !
    Alias /webalizer /volume1/web/webalizer


    # чтобы ярлык Photo Station на рабочем столе DSM указывал не на IP адрес из  ProxyPass ниже, 
    # а на доменное имя из настроек Photo Station (Настройки/Порт маршрутизатора)
    ProxyPreserveHost On


    # для Download Station (для других служб, работающих от системного экземпляра Apache, добавить аналогичные группы)

    ProxyPassMatch ^/download$ !
    RedirectMatch ^/download$ /download/

    ProxyPassMatch ^/download/(.*)$ http://localhost:8000/$1
    ProxyPassReverse /download/ http://localhost:8000/


    # для веб-интерфейса DSM (необходимо также для перечисленных выше служб, потому что они обращаются к некоторым системным функциям отсюда)

    ProxyPass / http://localhost:5000/
    ProxyPassReverse / http://localhost:5000/
    
</VirtualHost>

mugz · 09.03.2015
Опять быстро не получилось ответить, извините.

 

Да! Заработало! У меня были сомнения на счет объявления NameVirtualHost, но думал у вас это специально убрано.

 

Вопрос у меня теперь такой. Возможно лучше будет сделать все сервисы (downloadstation, videostation,webdav и иже с ними) не проксированием, а указав ссылки на root дериктории? Будет работать?

 

Тимур Рахимов · 09.03.2015

Нет, не будет. Дело в том, что работа перечисленных вами сервисов управляется другим экземпляром веб-сервера, и если вы хотите изменить их поведение, вам нужно будет вносить изменения в конфигурацию этого экземпляра. Или полностью воссоздавать конфигурацию этих сервисов внутри нашего, «пользовательского» экземпляра (тогда системный, в общем, станет не нужным). Но это сложно, ведь для того, чтобы ненароком при этом что-то не поломать, потребуется вникать в детали работы этих сервисов очень глубоко, идя по следам программистов Synology. А главное, зачем?

 

mugz · 09.03.2015

Да, еще одна проблема. При переброске, таким образом (в моем варианте и в вашем) почему-то не показывает весь список доступных папок. Только одну папку и все. Не поможете понять в чем сложность?

Тимур Рахимов · 09.03.2015

Извините, я не понял, о каком «списке доступных папок» идёт речь. Не могли бы вы объяснить подробнее?

mugz · 09.03.2015
Извините, я не понял, о каком «списке доступных папок» идёт речь. Не могли бы вы объяснить подробнее?

 

Да, извините. Давайте подробней расскажу.

 

У меня на Synology создано несколько пользовательских сетевых папок (share) доступных как по CIFS/AFP так и по WEBDAV.

Примерно список выглядит так:

- backup

- home

- music

- video

 

Если мы подключаемся к webdav используя подключение по имени:порт (типа http://our.synology.name:5005) то мы видим все доступные нам пользовательские папки.

 

Если же мы подключаемся по нашему виртуальному хосту (http://mysite.domain.com/webdav) - то видим только одну папку (например backup) и все. Остальных в списке нет.

 

Доступы ко всем папкам предоставленны. Подозреваю что проблема в проксировании. Что-то упустили из виду. А что, понять не могу.

mugz · 09.03.2015

И еще один вопросик в довесок. Можно сказать апачу, чтобы он была не case sensitivy для запросов?

 

А то вот для него mysite.domain.com/phpMyAdmin и mysite.domain.com/phpmyadmin - разные вещи

Тимур Рахимов · 10.03.2015

Насчёт WebDAV: я не знаю. Для начала разумно было бы понять, в чём тут дело на уровне запросов и что за ошибки при этом возникают. Смотрите логи (/var/log/httpd/user-access_log и /var/log/httpd/user-error_log в конфигурации «из коробки»). Сравните также записи в логах для случаев, когда работает «правильно» и когда «неправильно», чтобы выявить, в чём разница. Это аналитический путь, он не всегда короткий, но зато более надёжный, при должном упорстве рано или поздно приводит к решению. Но можно попытаться и наугад, конечно, у модуля mod_proxy много разных настроек, попробуйте их (смотрите директивы, начинающиеся на ProxyPass). Я бы начал с ProxyPassReverseCookiePath, например.

 

Что касается регистронезависимых адресов. Замените директиву Alias на более гибкий вариант, AliasMatch, и включите в начало строки поиска модификатор регулярных выражений (?i) «сравнивать без учёта регистра», вот так:

 

ProxyPassMatch (?i)^/phpMyAdmin !

AliasMatch (?i)^/phpMyAdmin(.*)$ /volume1/web/phpMyAdmin$1

 

ProxyPass тоже придётся заменить на ProxyPassMatch, чтобы не отправлял на прокси не только строку в том регистре, в котором она написана, но и в любых сочетаниях прописных и строчных букв.

mugz · 11.03.2015
Насчёт WebDAV: я не знаю. Для начала разумно было бы понять, в чём тут дело на уровне запросов и что за ошибки при этом возникают. Смотрите логи (/var/log/httpd/user-access_log и /var/log/httpd/user-error_log в конфигурации «из коробки»). Сравните также записи в логах для случаев, когда работает «правильно» и когда «неправильно», чтобы выявить, в чём разница. Это аналитический путь, он не всегда короткий, но зато более надёжный, при должном упорстве рано или поздно приводит к решению. Но можно попытаться и наугад, конечно, у модуля mod_proxy много разных настроек, попробуйте их (смотрите директивы, начинающиеся на ProxyPass). Я бы начал с ProxyPassReverseCookiePath, например.

 

Что касается регистронезависимых адресов. Замените директиву Alias на более гибкий вариант, AliasMatch, и включите в начало строки поиска модификатор регулярных выражений (?i) «сравнивать без учёта регистра», вот так:

 

ProxyPassMatch (?i)^/phpMyAdmin !

AliasMatch (?i)^/phpMyAdmin(.*)$ /volume1/web/phpMyAdmin$1

 

ProxyPass тоже придётся заменить на ProxyPassMatch, чтобы не отправлял на прокси не только строку в том регистре, в котором она написана, но и в любых сочетаниях прописных и строчных букв.

 

 

Спасибо. Будем копать дальше.

mugz · 07.05.2016

Ребят. Тут в DSM 6 ничего не работает теперь. Куда копать? Как переделать так, чтобы все работало?

schel4ok · 15.11.2020

А как сделать правило для приложений, работающих в докере? Сейчас они у меня тоже запускаются по адресу IP:port

У них же непонятно где находится папка приложения, к которой прописывать Alias