Чи може апаратний балансир навантажень маршрутувати SSL-трафік за допомогою SNI?


9

Зараз у нас є ферма веб-серверів, на якій розміщено 2 програми - обидва додатки працюють на всіх серверах. Ми хочемо розділити це, щоб у нас була спеціальна ферма серверів для кожного додатка (у нас є вагомі причини для цього).

Ми сподівалися мати єдиний балансир навантаження перед усіма серверами, який би направляв трафік до правильної ферми на основі імені хоста, але ми хочемо підтримувати SSL для веб-серверів.

Здається, маршрутизатори, які нам пропонують, не роблять цього. Я розумію, що без SNI це неможливо, але ми очікуємо показники SNI практично на всьому нашому трафіку.

Тепер я програміст, а не хлопець у мережі, але коли надходить новий запит на з'єднання SSL, маршрутизатор не може перевірити заголовок SNI та перейти до правильної ферми. Я припускаю, що вхідне з'єднання SSL ідентифікується за допомогою {source IP: source port}, тож чи не міг він запам'ятати це для подальших вхідних пакетів (якщо SNI присутній лише у першому пакеті)?

Наскільки я можу сказати, що Haproxy це робить, але, схоже, апаратні балансири навантаження не роблять. Чи є якась причина для цього, чи це щось, на що ми повинні наполягати?

(Для останнього охоронця, що використовує IE на XP, який не включає SNI, ми хочемо відправити трафік на стару ферму, і ми будемо керувати наближенням до нової ферми, коли це необхідно).

Відповіді:


10

Відповідно до їх веб-сайту, балансові навантаження F5 мають підтримку SNI:

https://devcentral.f5.com/articles/ssl-profiles-part-7-server-name-indication

Ви навіть можете робити iRules на основі SNI.

Відмова:

  • Я не підтвердив, що вони стверджують на своєму веб-сайті
  • Я не працюю на F5, і жодного разу не використовував у виробництві протягом 3+ років.

Дякуємо за Ваш відповідь. Я можу помилитися з цього приводу, але я думаю, що на цій сторінці йдеться про веб-сервери, а не про маршрутизацію трафіку SSL. Це говорить про використання SNI для вибору правильного сертифіката, тому я думаю, що це в кінці з'єднання SSL, а не в середині.
potato

1
AFAIK, на цій сторінці йдеться про маршрутизацію SSL-трафіку "..., BIG-IP дозволяє призначити декілька SSL-профілів віртуальному серверу для підтримки використання функції TLS SNI. Функція TLS SNI недоступна в попередніх BIG- Версії IP, тому ви хочете оновити, якщо ви не перебуваєте на версії 11.11 або вище! Профіль SSL використовується, коли ім'я сервера не відповідає запиту клієнта або коли браузер не підтримує розширення SNI. "
bgtvfr

"віртуальні сервери" - це шлях великого ip-маршруту http / https-трафік до бекенд-серверів (= apache, tomcat, websphere ...)
bgtvfr

Більшість великих гравців (cisco, big-IP) роблять це, як було сказано вище. Я не впевнений, чому інша відповідь була позначена як відповідь.
Джим Б

@JimB Я позначив іншого як відповідь, тому що я програміст, який намагається узгодити мережеві апаратні можливості! Далі я розглянув статтю і досі не можу розробитись, якщо пристрій вирішив пересилати трафік на різні фізичні сервери на основі розширення SNI (як нам потрібно). Це здається актуальним: devcentral.f5.com/questions/…
помато

9

не може маршрутизатор вивчити заголовок SNI,

Роутер зазвичай працює лише на рівні 3 OSI, тобто не перевіряє вміст пакету, а лише цільовий IP. Для маршрутизації на основі SNI потрібно розуміння TCP та TLS, яке є і складнішим, і значно дорожчим (щодо продуктивності), а просто маршрутизацією на основі IP-адреси. І це також зазвичай не називається маршрутизацією.

Haproxy робить це .. Балансири завантаження обладнання не роблять.

Ви змішуєте маршрутизатор (шар 3), балансир завантаження обладнання (рівень 4 і, можливо, вище) і Haproxy (балансир завантаження програмного забезпечення). Апаратний балансир навантаження - це не що інше, як пристрій з деяким програмним балансиром навантаження, а також, можливо, також деяким прискоренням обладнання для певних дій. Немає нічого, що по суті не дозволяє зробити балансування (а не маршрутизацію) на основі інформації SNI неможливо на апаратному балансирі навантаження, і, як і інша відповідь, можна сказати, що є продукти, які це підтримують. Але, звичайно, це потрібно реалізувати, і це вимагає продуктивності - чим глибше ви дивитесь на трафік, тим повільніше він отримує.


Гаразд настільки технічно можлива, але не гарна ідея з міркувань продуктивності, тому це не робиться. Дякую.
potato
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.