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 {
VSserver 192.168.128.11:80;
VS }
VS server {
VSlisten 80;
VSserver_name example1.example.com;
VSerror_log /var/log/nginx/exampleproxy.error.log;
VSaccess_log /var/log/nginx/exampleproxy.acess.log;
VSproxy_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
