Tag Archives: juniper

Juniper SRX IPsec Site-to-Site VPN и Split-DNS

В данной статье будет рассматриваться настройка VPN между офисами (site-to-site) и особенности, если трафик возникает на самом SRX на примере Split-DNS.

В Juniper SRX существуют два варианта организации site-to-site VPN: на основе политик (policy based) и на основе маршрутов (route based). Они отличаются способом, по которому трафик попадает в туннель. Здесь будет рассматриваться route based VPN при котором на основании маршрутов в таблице маршрутизации SRX будет принимать решение об включении трафика в туннель. Эти маршруты могут быть получены автоматически (за счет протоколов динамической маршрутизации), но здесь будет показан самый простой ручной вариант, на основе статических маршрутов.

Когда филиал соединен с центральным офисом, или, когда все серверы расположены в центре обработки данных, до которого организован site-to-site VPN, один из вопросов сетевой доступности является DNS сервер компании. В данном случае речь идет про ситуацию, когда одни и те же доменные сетевые имена для внутрисетевых клиентов и для внешних клиентов разрешаются по-разному. Этот процесс называется split-DNS, когда домен компании обслуживают два DNS сервера: один для клиентов изнутри, второй для клиентов снаружи.

Клиенты в филиале как правило получают сетевые настройки от DHCP сервера. В филиале SRX может выполнять роль DHCP сервера. В этом случае опция 6 — «DNS сервер» может содержать адрес как внутреннего DNS сервера компании, так и самого SRX. Для чего это может понадобиться? Если в VPN туннель вы направляете только трафик до внутренних серверов и сервисов, то логично, что запросы на внутренний сервер DNS отправлялись только для доменных имен внутренних ресурсов. Именно поэтому выдавать клиентам филиала адрес SRX как DNS сервера позволит регулировать на самом SRX на какой DNS сервер отправлять запрос. Это функция называется Proxy DNS.

Читать далее

Реклама

NAT не замена межсетевому экрану на примере Juniper SRX

Вы, наверное, слышали утверждение, что NAT не является системой безопасности. Оно появилось из-за того, что некоторые пользователи NAT считают, что, скрыв внутреннюю адресацию сети, можно добиться ее безопасности. На самом деле это не так и использование NAT не отменяет необходимости настраивать межсетевой экран.

Рассмотрим пример публикации внутреннего веб сервера на Juniper SRX.

Перед тем как перейти к конфигурации следует напомнить, как устройства SRX обрабатывают пакет.

На представленной картинке нас интересует порядок обработки NAT и политик безопасности. Если проследить последовательность, то можно заметить следующий порядок действий:

  1. Статический NAT
  2. NAT с преобразованием адреса получателя (Destination NAT)
  3. Применение политик безопасности
  4. Обратный статический NAT
  5. NAT с преобразованием адреса отправителя (Source NAT)

Отсюда следует, что при определении политик безопасности, адреса источника и получателя задаются как адреса конечных точек, а не промежуточного звена NAT.

Читать далее

PXE Boot на Juniper SRX

Технология PXE boot используется для загрузки по сети установочного образа операционной системы с последующей его установкой. Она является альтернативой использованию установочного диска.

Для работы PXE используются такие протоколы как DHCP и TFTP.

Протокол DHCP предназначен для автоматического присвоения IP адресов клиентам в сети, а также дополнительных сетевых параметров (опций): адреса роутера, адреса DNS серверов и т.д.

Технология PXE использует в своей работе специальные DHCP опции, которые позволяют сетевым клиентам найти загрузочный сервер в сети и загрузить с него загрузочный файл.

Работа DHCP протокола состоит из обмена сообщениями между клиентом и сервером, по завершении которого, клиент присваивает себе определенный IP-адрес, выданный сервером. Эти сообщения: DHCP Discover, DHCP Offer, DHCP Request, DHCP Response.

Поскольку клиент на начальном этапе не имеет своего IP-адреса все сообщения передаются через широковещательную рассылку на адрес 255.255.255.255. Поскольку широковещательные пакеты не передается за пределы подсети, это означает, что DHCP сервер должен быть либо в одной подсети с клиентом, либо должна быть задействована технология Relay Agent, позволяющая передавать DHCP запросы за пределы подсети.

Читать далее