Назад |
Перейти на главную страницу
Требования к брандмауэру Lync 2013 / Skype для бизнеса 2015
Мы планируем развернуть единую консолидированную границу в кластере vSphere. Из документации Microsoft кажется, что вам нужно два уровня брандмауэра.
Internet <--> Firewall <--> Edge Server/Reverse Proxy <--> Firewall <--> Front End/LAN
На практике, учитывая виртуальную среду, только с одним внешним брандмауэром, действительно ли вам нужен другой брандмауэр между Edge (который будет иметь два NICS, один в DMZ и один в локальной сети со статическими маршрутами / без шлюза по умолчанию ) и Frontend-сервер в локальной сети?
В связи с этим - что касается обратного прокси, почему вы не можете просто использовать NAT напрямую из WAN в интерфейс LAN внешнего интерфейса для веб-служб Lync?
Рекомендации и рекомендации Microsoft по разработке для развертываний Lync / SfB предлагают:
- Использование обратного прокси для публикации внешних веб-сервисов Front-End серверов.
- Размещение пограничных серверов в таком положении, чтобы они были заблокированы между двумя брандмауэрами, один из которых отделяет их общедоступные интерфейсы от Интернета, а другой - их внутренние интерфейсы от локальной сети.
Тем не менее, на самом деле довольно часто используются более простые конфигурации:
- Обратный прокси-сервер действительно может быть заменен простым NAT, но вам необходимо переназначить TCP-порты, потому что внешние веб-службы должны быть опубликованы на TCP-порту 443, но они фактически прослушивают серверы Front-End на TCP-порту 4443 (порт 443 используется для внутренний веб-сервисы).
- Внутренние интерфейсы пограничных серверов могут быть напрямую подключены к вашей локальной сети; однако имейте в виду, что это потенциальная угроза безопасности: если пограничный сервер будет скомпрометирован, он может (и будет) использоваться в качестве плацдарма в вашей сети; это основная причина создания межсетевого экрана между ним и вашей локальной сетью.