Кілька IP-адрес через один інтерфейс та iptables


1

Системний адміністратор не є моїм сильним моментом. Моя ситуація у нас є 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 веб-сайтів, які нам потрібні. У нас є ще одна IP-адреса * .14, про яку ми сказали нашим внутрішнім (bind9) та godaddy DNS (що стосується загальнодоступного IP для * .14, що є * .70). Але я відчуваю, що мені потрібно додати ще одне правило.

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

Домен, який я хочу вказати на 14, вказує на 12 (на нашому внутрішньому веб-сайті). Зовні він вказує на 70, що становить 14, тому нічого не відображається, тому що ця частина не працює!


Змінити, щоб відповісти на коментар Флоренца:

Наш сервер працює під керуванням Ubuntu 12.10. У нас є апаш, який обробляє наших віртуальних хостів із папкою під назвою "Доступні сайти" та з іншими веб-сайтами. У мене ця частина працює належним чином, де доступні та включені чотири сайти, що містять віртуальних хостів.

У нас є такі, <virtualhost>що містять IP-адреси, відповідні до .95, .11, .12 та непрацюючі .14 Оскільки вони використовують SSL, вони використовують порт: 443

Усі сертифікати SSL запущені і пов'язані також там. Я не думаю, що апашана сторона віртуальних хостів виконана неправильно. Я думаю, що це стосується цих правил маршруту IP-маршруту. Я насправді мало знаю про ці речі, тому важко пояснити це.


ваш опис мене трохи бентежить. Чи можете ви спробуйте більш детально описати, що у вас є у "шарах" матеріалів, та із відповідними записами файлу конфігурації? Який тип розгортання? ОС? Веб-сервер? екземпляри сервера? інші залежності? Погляньте на httpd.apache.org/docs/2.4/vhosts/ip-based.html для документів Apache на віртуальних хостах на базі IP (огляд конфігурації говорить про щось у цьому напрямку)
Флоренц Клі

Редагував моє запитання. Сподіваємось, це допомагає? Що ви маєте на увазі під шарами?
amurrell

шари = які компоненти повинні бути там, щоб він працював. Зазвичай діаграмують як шари. Мені спокусити сказати, що знову наймаю хлопця :-). Погляньте на свою ifconfig - де закінчується новий IP? Залежно від способу його входу (VLAN?), Ви можете опинитися на тестуванні з віртуальним інтерфейсом, а не фізичним. Подивіться на ip, netstat та маршрут, що показує вам налаштування маршруту (саме тут входить команда route). Перевірте iptables (якщо ви використовуєте брандмауер). Перевірте QOS / дроселювання (tc та ін.)
Флоренц Клі

Наймати його назад - це не варіант чи бажання. Я згадав, що це не моє поле. Мені потрібен крок за кроком. Можливо, ви можете надати посилання на те, як налаштувати віртуальний інтерфейс. І як подивитися на iptables, тому що саме ми, як видається, використовуємо.
amurrell

Відповіді:


0

Тож я придумав рішення цієї проблеми.

Я можу це виправити двома способами - один із способів, про який я тут попросив - створити новий інтерфейс для відображення IP xxx14.

Раніше я визначив новий Virtualhost для запуску SSL на решті домену. Проблема полягає в тому, що визначення Virtualhost за допомогою одного з наших IP-адрес недостатньо. Нам потрібно було зв’язати цей IP з одним із наших інтерфейсів. Зважаючи на те, що я не знайомий з написанням інтерфейсів або створенням віртуальних - а у нас вже є складні інтерфейси - це був непростий шлях для мене, щоб пройти (жоден каламбур не передбачався).

Я виправив це запуск обох Virtualhosts на одній і тій же 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>

Ми використовуємо доступні для сайтів апачі та сайти з включеним, тому кожен віртуальний хост визначається у власному файлі. Я включив директиву NameVirtualhost лише в одну з них, і вона спрацювала.

Висновок: я просто використав ту саму IP-адресу, яка вже мала робочий інтерфейс, щоб уникнути проблем із з'ясуванням способу створення нової.


Я хотів додати, що оскільки ми використовуємо декілька SSL на 1 IP-адресу, зараз використовується SNI (Вказівка ​​імені сервера) ... який SNI не підтримується у Windows XP. Запуск цих двох сайтів за допомогою SNI призвів до того, що SSL-сертифікат одного з сайтів не працює в IE 8 для Windows XP. Оскільки Windows XP більше не підтримуватиметься за допомогою microsoft - ми не збираємось змінювати цю налаштування, але я вважав, що люди повинні знати про це, якщо вони приймуть це рішення.
amurrell
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.