В настоящее время наши пользователи получают доступ к нашему внутреннему веб-сайту, набрав «наш веб-сайт». Существует запись DNS, которая сопоставляет наш веб-сайт с IP-адресом Cisco ACE 4700. DNS-имя ourwebsite.ourcompany.org также сопоставляется с IP-адресом Cisco ACE 4700.
Мы хотим, чтобы наши пользователи начали использовать ourwebsite.ourcompany.org и лишили их возможности использовать "ourwebsite". Некоторое время мы хотим, чтобы «наш веб-сайт» по-прежнему перенаправлял их на наш веб-сайт.
Мы хотели бы знать, можно ли настроить Cisco ACE 4700 таким образом, чтобы при вводе пользователем http: // наш веб-сайт что он немедленно выполняет перенаправление на http://ourwebsite.ourcompany.org.
Это возможно? например через правило перезаписи URL?
Я знаю, что это старый вопрос (связанный с тем, когда я отвечаю), но могу сказать, что это то, что Cisco ACE может сделать с помощью нескольких простых директив конфигурации.
Предположим, ваш сайт настроен с использованием простой конфигурации, подобной этой:
rserver host HOST1
ip address 1.2.3.4
inservice
rserver host HOST2
ip address 5.6.7.8
inservice
serverfarm host OURWEBSITE
probe <your-probe>
rserver HOST1 80
inservice
rserver HOST2 80
inservice
class-map match-all VIP-OURWEBSITE
match virtual-address 1.1.1.1 tcp eq www
policy-map type loadbalance first-match LB-OURWEBSITE
class class-default
serverfarm OURWEBSITE
policy-map multi-match VIP-SERVICE-POLICY
class VIP-OURWEBSITE
loadbalance vip inservice
loadbalance policy LB-OURWEBSITE
loadbalance vip icmp-reply active
Это один из наиболее простых типов настройки балансировки нагрузки, который можно настроить в ACE. Все, что он делает, - это просто запросы обратного прокси к реальным серверам. Соглашения об именах просто, например, puroposes; вы можете назвать их как хотите.
Что вы хотите сделать, так это сопоставить заголовок хоста, который исходит от клиента - если это «наш веб-сайт», тогда запрос должен быть отправлен на серверную ферму перенаправления, которая вызывает перенаправление HTTP 30x «наш веб-сайт.ourcompany.org» на клиент.
rserver redirect REDIRECT-OURWEBSITE
webhost-redirection http://ourwebsite.ourcompany.org%p 301
inservice
serverfarm redirect REDIRECT-OURWEBSITE
rserver REDIRECT-OURWEBSITE
inservice
Вышеупомянутый настраивает объект перенаправления. В директиве «webhost-redirection» вы заметите% p и 301.% p - это переменная, которая берет путь из клиентского запроса и добавляет его к перенаправлению - таким образом, если кто-то, скажем, http: //ourwebsite/somepage.html отмечены закладками, перенаправление автоматически отправит их на http://ourwebsite.ourcompany.org/somepage.html вместо того, чтобы отправлять их на статически настроенную страницу. Это чисто необязательно, поэтому, если вы предпочитаете, чтобы они отправлялись на настроенную страницу, а не автоматически перенаправлялись, просто оставьте эту переменную% p и замените ее URL-адресом, на который вы хотите быть перенаправлены. 301 заставляет переадресацию отправлять HTTP-код 301, который сообщает запрашивающему клиенту, что страница «переместилась навсегда» на этот новый адрес.
Теперь перейдем к настройке объекта, который соответствует запросам заголовка хоста для http: // наш веб-сайт.
class-map match-all MATCH-OURWEBSITE
match http header Host header-value "ourwebsite"
policy-map type loadbalance first-match LB-OURWEBSITE
class MATCH-OURWEBSITE
serverfarm REDIRECT-OURWEBSITE
Новая карта классов создаст соответствующий класс, который ищет «наш веб-сайт» в заголовке HTTP Host. В правилах сопоставления используются простые регулярные выражения, поэтому приведенное выше не будет соответствовать "ourwebsite.ourcompany.org".
Вторая директива выше, из ранее определенной карты политик LB-НАШ ВЕБ-САЙТ, вставляет новый соответствующий класс в политику балансировки нагрузки. Если в карте политик есть только класс класс по умолчанию, этот новый класс будет вставлен над ним. Если у вас уже есть один или несколько классов выше класс по умолчанию, вы можете вставить это правило над любым из них, используя класс MATCH-OURWEBSITE вставить-перед и он вставит его над указанным вами классом.
Как только это все будет завершено, обычно хорошей практикой является цикл VIP, выполняя vip-сервис без балансировки нагрузки за которым следует loadbalance vip сервис в сервисной политике:
policy-map multi-match VIP-SERVICE-POLICY
class VIP-OURWEBSITE
no loadbalance vip inservice
loadbalance vip inservice
Это не обязательно требуется для добавления соответствия в карту политик балансировки нагрузки, но некоторые другие директивы требуют цикла политики обслуживания VIP, так что это хорошая привычка.
Полная конфигурация после настройки всего этого будет выглядеть так:
rserver host HOST1
ip address 1.2.3.4
inservice
rserver host HOST2
ip address 5.6.7.8
inservice
rserver redirect REDIRECT-OURWEBSITE
webhost-redirection http://ourwebsite.ourcompany.org%p 301
inservice
serverfarm host OURWEBSITE
probe <your-probe>
rserver HOST1 80
inservice
rserver HOST2 80
inservice
serverfarm redirect REDIRECT-OURWEBSITE
rserver REDIRECT-OURWEBSITE
inservice
class-map match-all MATCH-OURWEBSITE
match http header Host header-value "ourwebsite"
class-map match-all VIP-OURWEBSITE
match virtual-address 1.1.1.1 tcp eq www
policy-map type loadbalance first-match LB-OURWEBSITE
class MATCH-OURWEBSITE
serverfarm REDIRECT-OURWEBSITE
class class-default
serverfarm OURWEBSITE
policy-map multi-match VIP-SERVICE-POLICY
class VIP-OURWEBSITE
loadbalance vip inservice
loadbalance policy LB-OURWEBSITE
loadbalance vip icmp-reply active
Оттуда, в зависимости от процесса вывода из эксплуатации, вы можете либо отключить запись DNS через некоторое время, либо даже изменить перенаправление веб-хоста директива, указывающая на страницу, говорящую пользователям прекратить использование имени хоста для подключения к веб-сайту. Все зависит от вашей политики вывода из эксплуатации.
Надеюсь это поможет!