Инструкция по пробросу портов на Juniper SRX

от автора

Этой статьей я планирую открыть серию мануалов по Juniper серии SRX. Если это кому-то будет полезно – буду очень рад. И не стесняйтесь задавать вопросы.

Отмечу, что все ниженаписанное, скорее всего, будет подходить и к любой другой модели маршрутизаторов от Juniper (вследствие их слогана «One Junos», то есть одна операционка на все железяки). Данная статья основана на официальном англоязычном мануале по настройке NAT, взятом отсюда: www.juniper.net/us/en/local/pdf/app-notes/3500151-en.pdf.

Итак, проброс портов. Или по-научному, destination NAT. Тут надо сделать одно небольшое замечание. Некоторые админы привыкли под словом NAT понимать source NAT, со всеми вытекающими. И даже не source NAT, а одну из его разновидностей — PAT. Но надо понимать отличия между разными видами ната. Здесь я не буду вдаваться в теорию, на википедии все достаточно понятно написано. Я хочу сделать лишь одно пояснение: NAT – это всего лишь подмена адресов, ничего больше. Если вы понимаете суть этой технологии по-другому, вы неправы. Ничего больше, чем замена одного адреса в заголовке IP-пакета другим, эта технология не делает. И ничего изначально страшного и ужасного в ней нет. Соответственно, если мы говорим о destination NAT, то речь идет о подмене адреса назначения. Рассмотрим пример:

Допустим, у нас есть внутренний сервис (веб-сервер, адрес 10.1.1.100), который мы хотим сделать доступным извне по нашему внешнему адресу (1.2.3.4 порт 80). Пишем:

root@jsrx# edit security nat destination

Этим самым мы попали в раздел конфигурации destination NAT. Сперва необходимо создать адресную запись (pool) нашего веб-сервера.

root@jsrx# set pool web-server address 10.1.1.100 port 80

Далее создаем rule-set, т.е. свод правил дестинейшн ната:

root@jsrx# set rule-set DNAT from zone untrust

Этим самым мы говорим, что данный свод правил работает для пакетов, пришедших из зоны untrust, т.е. в нашем случае из Интернета. В данном примере все хорошо, но иногда может потребоваться указать, с какого конкретно интерфейса должны приходить пакеты для данного свода правил. В этом случае фразу from zone untrust нужно заменить на from interface ge-0/0/0 (как в нашем примере). Можно также указать источником пакетов routing-instance, но это более редкий случай, мы не будем о нем думать.
Данный rule-set надо наполнить нужными правилами:

root@jsrx# set rule-set DNAT rule dnat_for_web match destination-address 1.2.3.4
root@jsrx# set rule-set DNAT rule dnat_for_web match destination-port 80
root@jsrx# set rule-set DNAT rule dnat_for_web then destination-nat pool web-server

В первой строке мы указываем наш внешний IP-адрес, на который будут стучаться клиенты. Во второй строке мы указываем внешний порт, а в третьей – собственно сам пул, который мы описали вначале.
Если все оставить так, как есть, то ничего не будет работать. Потому как надо создать политику доступа к нашему веб-серверу:

root@jsrx# top edit security address-book global
root@jsrx# set address web_server 10.1.1.100
root@jsrx# top edit security policies from-zone untrust to-zone trust
root@jsrx# set policy web_access match source-address any
root@jsrx# set policy web_access match destionation-address web_server
root@jsrx# set policy web_access match application any
root@jsrx# set policy web_access then permit

Делаем commit check, затем, если все прошло нормально – commit
На этом настройка destination NAT’a завершена, все достаточно просто. Итоговый конфиг приведен ниже:

root@jsrx# show security nat destination pool web-server {     address 10.1.1.100/32 port 80; } rule-set DNAT {     from zone untrust;     rule dnat_for_web {         match {             destination-address 1.2.3.4/32;             destination-port 80;         }         then {             destination-nat pool web-server;         }     } } root@JuniperSRX220# show security address-book global address web_server 10.1.1.100/32;  root@jsrx# show security policies from-zone untrust to-zone trust policy web_access {     match {         source-address any;         destination-address web_server;         application any;     }     then {         permit;     } } 

Несколько ценных дополнений.
1. Для каждого пробрасываемого порта необходимо писать данные правила (политики нужно писать только для новых добавляемых серверов). Невозможно пробросить диапазон портов одной командой. А жаль, порой хочется.
Если вам позарез необходимо пробросить дофига и больше портов, может быть стоит посмотреть в сторону Static NAT.
2. Имена правил не должны повторяться в пределах всей конфигурации NAT. Если вы станете повторяться, то commit check ругнется на имена правил.
3. Имена правил, сводов правил, пулов и т.д. можно писать любыми на ваше усмотрение. В моем случае это DNAT, web-server, dnat_for_web и т.д.
4. Посмотреть счетчик срабатываний проброса можно из операционного режима командой:

root@jsrx> show security nat destination rule имя_правила

В строке Translation hits будет показано количество срабатываний данного проброса. Очень удобный инструмент диагностики ната.
5. Если вас смущает строка match application any в конфиге политики, то вы правы. По-хорошему, в целях безопасности сюда стоит вписать имя конкретного приложения (т.е. порта), которое будет использоваться внешними клиентами, для веб-сервера можно написать match application junos-http. Подробнее о приложениях в Junos OS я буду писать позже.

Как видите, процедура создания проброса довольна проста, но и в ней есть свои нюансы. Спасибо всем за внимание, буду очень рад любым вопросам.

ссылка на оригинал статьи http://habrahabr.ru/post/166637/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *