Несколько IP-адресов через один и тот же интерфейс и iptables

Question

Системный администратор не моя сильная сторона. Моя ситуация такова, что у нас есть 1 веб-сайт с 4 доменами. Сам сайт обслуживает разные шаблоны / контент в зависимости от того, какой домен используется, имитируя 4 разных сайта.

Мы хотим SSL для каждого домена (в настоящее время у нас все правильно настроено с Apache, и он работает на 3 сайтах).

У нас есть 3 физических сетевых интерфейса: eth5, eth6, eth7. Прошлый сотрудник написал эти правила IP-маршрутизации, чтобы помочь настроить IP-адреса наших виртуальных хостов. Я не очень понимаю, что происходит, за исключением того, что с этими 3 доменами работают должным образом SSL, что соответствует виртуальным хостам для каждого IP-адреса * .95

Eth5
ip route add *.*.*.0/24 dev eth5 proto kernel scope link src *.*.*.95 table 20
ip route add default via *.*.*.1 dev eth5 table 20
ip rule add from *.*.*.95 lookup 20 

Eth6
ip route add *.*.*.0/24 dev eth6 proto kernel scope link src *.*.*.12 table 40
ip route add default via *.*.*.1 dev eth6 table 40
ip rule add from *.*.*.12 lookup 40

Eth7
ip route add *.*.*.0/24 dev eth7 proto kernel scope link src *.*.*.11 table 30
ip route add default via *.*.*.1 dev eth7 table 30
ip rule add from *.*.*.11 lookup 30

Эти правила сработали для 3 из 4 веб-сайтов, которым нужен SSL. У нас есть другой IP-адрес * .14, который мы указали нашему внутреннему (bind9) и добросовестному DNS (соотносящемуся с общедоступным IP-адресом для * .14, который равен * .70). Но я чувствую, что мне нужно добавить еще одно правило.

Я хочу знать, что делают эти правила, зачем мне нужно правило и как я могу заставить .14 реально работать.

Домен, на который я хочу указать 14, указывает на 12 (на нашем внутреннем сайте). Внешне он указывает на 70, то есть 14, так что ничего не появляется, потому что эта часть не работает!

---

Редактировать, чтобы ответить на комментарий Флоренц:

Наш сервер работает под управлением Ubuntu 12.10. У нас есть apache, который обрабатывает наши виртуальные хосты с помощью папки с именем sites-available и с поддержкой других сайтов. У меня эта часть все работает правильно, где есть четыре сайта, доступных и включенных, содержащих виртуальные хосты.

В тех, у нас есть <virtualhost> который содержит IP-адреса, которые соответствуют .95, .11, .12 и один не работает .14 Поскольку они используют SSL, они используют порт:443

Все сертификаты SSL работают и связаны там же. Я не думаю, что Apache сторона виртуальных хостов не сделано правильно. Я думаю, что это связано с этими правилами IP Route. Я не очень много знаю об этом, поэтому мне сложно это объяснить.

Answer 1

Поэтому я разобрался с решением этой проблемы.

Есть два способа, которыми я мог бы это исправить, один из способов, который я здесь просил, - создать новый интерфейс, отражающий IP xxx14.

Ранее я определил новый Virtualhost для запуска SSL на оставшемся домене. Проблема в том, что определения Virtualhost с одним из наших IP-адресов недостаточно. Нам нужно было связать этот IP с одним из наших интерфейсов. Учитывая, что я не знаком с написанием интерфейсов или созданием виртуальных - и у нас уже есть сложные интерфейсы - для меня это был нелегкий путь (без каламбура).

Я исправил это так: виртуальные хосты работали на одном IP-адресе и порте - одном из IP-адресов, уже связанных с работающим интерфейсом. Все, что мне нужно было сделать, это добавить директиву NameVirtualhost, чтобы перекрытие не вызывало предупреждение с Apache. Было прекрасное описание этого здесь.

Пример, приведенный выше, демонстрирует идею, которую я адаптировал к своему случаю:

NameVirtualHost x.x.x.12:433

<VirtualHost x.x.x.12:433>
ServerName www.domain.tld
ServerAlias domain.tld *.domain.tld
DocumentRoot /www/domain
</VirtualHost>

<VirtualHost x.x.x.12:433>
ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain
</VirtualHost>

Мы используем apache sites-available и sites-enabled, поэтому каждый виртуальный хост определяется в своем собственном соответствующем файле. Я включил директиву NameVirtualhost только в одну из них, и она сработала.

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