Site-to-site vpn, используя удаленный шлюз для интернет-трафика?
Мы перемещаем небольшой удаленный офис в новое место, что означает новое интернет-соединение и новый маршрутизатор. Я заметил, что в настоящее время они настроены на использование удаленного шлюза через VPN, поэтому весь их интернет-трафик проходит через соединение в центральном офисе, которое мне кажется медленным и неэффективным.
Я подумываю о настройке их для использования их локального шлюза для трафика не-VPN. Есть ли причина, почему я не должен делать это? Мне кажется, это лучший способ сделать это. К сожалению, парня, который это создал, давно уже нет, и я не уверен, какое оправдание вы бы сделали для этого.
3 ответа
Обычно есть две причины, по которым я это вижу.
Как отметил Роберт Каучер, фильтрация контента, ведение журналов и принудительное применение на "узловом сайте" - одна из главных причин. Многие продукты для фильтрации содержимого позволяют развертывать "ведомые" серверы на удаленных сайтах для фильтрации и ведения журнала на основе центрального "сервера политики". Однако для удаленного сайта, где нет серверного компьютера, и организация может просто направить весь этот трафик обратно на центральный сервер фильтрации.
Централизованные правила брандмауэра и мониторинг - еще одна распространенная причина, по которой я это делал (в частности, для VPN типа "пользователь-сайт", но я видел это и для сайта "сайт-сайт"). "Разделенное туннелирование" (то есть предоставление удаленной конечной точке VPN прямой связи с Интернетом и отправка только трафика в корпоративную сеть по каналу VPN) рассматривается некоторыми как серьезная угроза безопасности. В среде "сайт-сайт" вы могли бы сделать звонок, что брандмауэр в удаленном офисе должен быть настроен для обеспечения безопасного прямого доступа в Интернет, но я встречал ситуации, когда это считалось "лучшим" (я полагаю, потому что брандмауэр правила на удаленном сайте в итоге оказались "разрешать только VPN-трафик") для маршрутизации всего этого интернет-трафика на "узловой" сайт.
Вы должны увидеть улучшение использования полосы пропускания на узле-концентраторе и улучшение скорости отклика на удаленном узле при переходе к разделенному туннелю. Пока у вас есть надежные правила брандмауэра на удаленном сайте (и какую бы инфраструктуру мониторинга, контент-фильтра и т. Д. Вы ни выбрали), не должно быть никаких причин не позволять ему иметь прямой доступ к Интернету и экономить пропускную способность на " хаб "сайт.
Единственная реальная причина, по которой вы, возможно, захотите сделать это для фильтрации контента - по крайней мере, насколько я знаю. Это было бы проще для вас, так как нужно беспокоиться только об одном фильтре контента.
Это, вероятно, вряд ли, но как вещи, чтобы исключить:
- Скрыть ветку, в которой находятся люди
- Скрыть низкоуровневые соединения на сайте филиала
- Публичные IP-адреса, выделенные из пула основного сайта
- К некоторому серверу нужно получить доступ извне, и что NAT должен происходить на главном сайте
- Доступ к некоторому ресурсу, связанному с источником ИС (к сожалению, распространенным в образовании)
Как упоминал Эван, я подозреваю, что настоящая причина - это правила брандмауэра, возможно потому, что у старого оборудования не было хорошего брандмауэра с сохранением состояния. Предполагая, что он есть сейчас, я не вижу каких-либо общих причин не отправлять их интернет-трафик напрямую. Так всегда работали удаленные сайты моего рабочего места.