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
