Не ясный в Вашем третьем абзаце извините, так или иначе я остановил доверчивое 'значение по умолчанию '/native VLAN давным-давно, они просто не всегда играют приятно при конфигурировании, как Вы имеете, почему Вы только не заявили бы правильный VLAN, это не трудно сделать и разрешает вещи приятно. Теперь на Вашу проблему, Вы проверили конфигурации порта коммутатора и таблицу CAM? Что Вы видите?
Здесь есть множество проблем, которые делают это не так просто, как должно быть.
Во-первых, я думаю, что лучший способ справиться с этим:
www.somedomain.com
. www2.somedomain.com
. www2.somedomain.com/web -app
на www.somedomain.com/web-app
. Теперь о деталях.
DNS-серверы разрешают fqdn в IP-адрес. Они не могут помочь вам ни в чем ниже (например, в пути). Запросы DNS даже не содержат путь запроса.
На общем сервере почти наверняка используются протоколы HTTP 1.1 и виртуальные хосты на основе имен. Другими словами, у блока есть один IP-адрес, и он смотрит на заголовок HOST в запросе, чтобы определить, какой сайт обслуживать. Следовательно, если вы выполняете перенаправление на основе IP-адреса, сервер A просто получит HTTP-запрос на 123.123.123.123/web-app/foo
, и, имея gajillion сайтов на этом сервере, он не будет знать, какие
Поскольку ваши серверы имеют разный контент (по крайней мере, для одного пути), и вы не можете использовать переадресацию на основе IP-адреса, вам придется использовать разные fqdn, чтобы различать их.
Поскольку старый сайт является вероятно, уже настроен с www.somedomain.com
в качестве ServerName
, и похоже, что вы не можете его изменить, ваш единственный вариант - создать новое имя сервера.
Вы также можете рассмотреть этот вариант:
Настройте свой веб-сервер на serverB для работы в обратном направлении прокси, который обращается к ServerA для определенного местоположения / web-app / и загружает контент из других местоположений с serverB.
Конфигурация довольно проста и понятна, вы найдете множество доступных примеров.