Checkpoint - режим Wifi Bridge убивает запросы туда-обратно?

Я вполне уверен, что это либо вопрос NAT, либо вопрос маршрутизации, но он постоянно ставит меня в тупик.

Это аппаратный брандмауэр Checkpoint Safe@Office. Режим работы по умолчанию состоит в том, что проводные клиенты находятся в сети 192.168.10.x, а клиенты Wi-Fi - в 192.168.252.x, и что они защищены друг от друга брандмауэром.

Один компьютер на проводной стороне работает как веб-сервер; обслуживающий поддомен dev моего веб-сайта. Это доступно снаружи и внутри, и все работает нормально.

Однако мне нужно, чтобы проводные сети и сети Wi-Fi могли общаться друг с другом по другим причинам. Сделать это; Вы можете установить устройство в "режим моста", при котором как проводные, так и Wi-Fi-клиенты имеют IP -адрес 192.168.10.x и могут свободно общаться.

К сожалению, что-то о мостовом соединении таким образом серьезно подрывает производительность веб-сервера до такой степени, что он становится непригодным для использования изнутри сети - внешне все еще нормально.

Если я пингую dev.mydomain.com изнутри сети, он переходит к моему общедоступному IP -адресу - и все мои предыдущие попытки (и поиск в Google) заставить эту конфигурацию работать, предполагают, что, поскольку запрос является исходящим, а затем возвращается в сеть, он "двойной наттинг" или что-то подобное, из-за чего маршрутизатор не уверен, что с ним делать.

Есть ли способ решить это? Я нашел других людей с такими же проблемами (на разных устройствах тоже), но не видел решения, которое работает.

Обновлено 31.03.2013:

Я вполне уверен, что первый ответчик находится на правильном пути с перенаправлением трафика с использованием правил NAT.

Сначала я думал, что аппаратное обеспечение не работает, но я смог подтвердить его, успешно перенаправив весь исходящий веб-трафик с одного устройства на пустоту, при этом он работал как ожидалось.

Итак, теперь возникает вопрос - какие правила NAT должны вступить в игру, чтобы трафик направлялся во внутреннюю сеть?

Я попытался сделать то, что казалось наиболее очевидным:

КОГДА: источник - внутренние сети, пункт назначения - мой общедоступный IP -адрес, а служба - веб-сервер.

ПОТОМ: Не меняйте источник, измените IP - адрес получателя на мой внутренний сервер и не меняйте службу.

Это не работает, но я чувствую, что должно.

Обновление № 2

Я использую Microsoft Network Monitor, чтобы попытаться просмотреть пакеты данных, чтобы увидеть, предлагает ли это какую-либо информацию.

Во-первых, возникает вопрос о том, как работает трансляция NAT - потому что даже при установленных правилах я вижу, что запрос направляется на dev.mydomain.com, а внутри пакета адресат все равно читается как мой общедоступный IP -адрес. Должен ли перевод фактически ИЗМЕНИТЬ пункт назначения, или это просто, что он должен молча перенаправить его?

Во-вторых, это также подтверждает проблему. Если я смотрю на реальный веб-сайт во время захвата пакетов, шаблон выглядит примерно так, как вы ожидаете - во-первых, поиск DNS возвращается и возвращается, после чего следует ряд запросов (предположительно относящихся ко всем стандартным файлам, JS, CSS). и т.д., а также сам HTML), каждый из которых почти сразу же отвечает пакетами данных.

Если я посмотрю на моего разработчика подобласть; это очень односторонний. С правилами NAT или без них я вижу, что запрос завершается и исходные ответы возвращаются, затем запрос HTTP GET отправляется и возвращается (и фактически содержит HTML-код для страницы) - но больше ничего. Куча запросов поступает (я предполагаю) включений, и они не отвечают. В конце концов, они снова выходят, но все равно ничего не возвращается.

Можем ли мы смотреть на проблему с Apache, а не на маршрутизатор?

Обновление № 3

Поэтому я создал простую HTML-страницу с одной строкой текста и без включенных файлов, и она работает с правилами NAT или без них, иногда мгновенно, иногда это занимает несколько секунд, но всегда работает. Затем я включил изображение таким же образом, как они включены в реальные страницы, и оно загрузилось - но на это всегда уходило от нескольких до десятков секунд. Учитывая, что на реальной странице будет много запросов на изображения, а также на другие файлы, не удивительно, что если они все такие медленные, то это объясняет, почему страница перестает работать. Я не ближе, чтобы понять, почему.