Vladimir Skubriev -> Debian-russian@lists.debian.org @ Tue, 01 Oct 2013 11:41:16 +0400:
Начнем с того, что ты не сформулировал задачу, которую ты пытаешься решить этим способом. Поэтому совершенно непонятно, что тебе можно посоветовать. VS> Такую конфигураию мне предложил один знакомый. VS> Но я что то не совсем верю в то, что она единственная из возможных. Скорее всего, не единственная. У нас вообще довольно редко бывает единственная возможность :) VS> Есть два сайта на внутреннем сервере, оба работают по http и https сейчас на VS> apache VS> Есть шлюз с nginx proxy, который пока пробрасывает только один сайт и только VS> по http. Остальные в процессе настройки backend'a (еще не готовы). Но в VS> дальнейшем на прокси будет 4 сайта прокси. VS> Конфиг первого прокси такой на данный момент: VS> upstream backendexample { VS> server 192.168.128.11:80; VS> } VS> server { VS> listen 80; VS> server_name example1.example.com; VS> error_log /var/log/nginx/exampleproxy.error.log; VS> access_log /var/log/nginx/exampleproxy.acess.log; VS> proxy_pass http://backendexample; VS> } VS> } VS> Вебсервер один. VS> Сейчас в процессе настройки получилось, что на apache мне приходится VS> дублировать конфигурацию сайта для разных virtualhost's VS> Т.е. для одного сайта я описываю два Virtualhost: VS> # cat /etc/apache/sites-available/example1 VS> <VirtualHost example1.example.com:80> VS> # Same Config 1 VS> </VirtualHost> VS> # cat /etc/apache/sites-available/example1-https VS> <VirtualHost example1.example.com:443> VS> # Same Config 1 VS> </VirtualHost> VS> При этом конфиги nginx тоже придеться размножить на 4 файла с практически VS> одинаковой конфигурацией. Но тут вроде ни чего страшного. Так по сути конфиги VS> получаться элементарными. VS> Во первых я подозреваю, что здесь есть нагромождение. Четыре конфига по сути VS> повторяющих друг друга в apache не самый лучший вариант. Ну, для начала - если у тебя действительно одинаковые конфиги для 80 и 443 порта, то директива VirtualHost умеет несколько комбинаций хост-порт, т.е. можно сократить с 4 комбинаций до 2. Для разных сайтов, надо полагать, конфиги все-таки разные, тут никуда не денешься. Потом, обычно, если делают фронтэнд и бэкэнд, то HTTPS обслуживает фронтэнд, а к бэкэнду он ходит без шифрования. Правда, в твоем случае это будет означать, что трафик между фронтэндом и бэкэндом можно будет заснифить из локальной сети. Собственно, если хотеть, чтобы между шлюзом и бэкэндом ходил HTTPS при запросе HTTPS со шлюза (это касается и запросов извне), то на шлюзе для HTTPS лучше строить не прокси, а проброс порта. Ибо нафига расшифровывать, а потом обратно зашифровывать? VS> Во вторых меня терзают сомнения по поводу правильности того, чтобы клиенты VS> локальной сети для обращения к внутреннему серверу ходили через шлюз (ну или VS> отдельный компьютер). Просто если я на backend оставлю два конфига только с VS> http, то клиенты внутренней сети будут ходит на веб сервер без https. VS> А вдруг шлюз будет выключен - все станет? У тебя DNS, доступный внутренней сети, не на шлюзе, часом, расположен? Если на шлюзе, как это обычно и делают, то если его выключить, так и так все встанет, не парься. Гонять трафик через шлюз будет тупо проще, чем городить view в DNS-сервере. Если он расположен на веб-сервере, то шлюз, конечно, несколько лишний. Если трафик с этого веб-сервера в локальную сеть большой (сравнимый по порядку величины с пропускной способностью сети), то тоже лишний, независимо от того, где DNS (гонять через шлюз - это удвоение трафика). -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eh85766l....@wizzle.ran.pp.ru