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

в 12:22, , рубрики: juniper, 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, то речь идет о подмене адреса назначения. Рассмотрим пример:

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

Допустим, у нас есть внутренний сервис (веб-сервер, адрес 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 я буду писать позже.

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

Автор: celebrate

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js