Настройка NAT: Часть 2

Итак, мы с Вами добрались до настройки NAT. Давайте рассмотрим базовый сценарий настройки. Для этого предположим что:

1. Маршрутизатор подключен к сети Интернет через интерфейс с именем WAN и имеет адрес 1.1.1.1
2. Маршрутизатор подключен к локальной сети через интерфейс LAN и имеет адрес 192.168.88.1/24
3. Необходимо опубликовать (сделать видимым из Интернет) web-сервер с адресом 192.168.88.2, протоколом tcp и портом 80.
4. Необходимо опубликовать (сделать видимым из Интернет) терминал сервер с адресом 192.168.88.3. С целью безопасности заменить внешний порт на порт 53389, оставив внутренний порт 3389 (ассиметричная публикация порта).
5. Необходимо опубликовать (сделать видимым из Интернет) телефонный сервер имеющий адрес 192.168.88.4, работающий по протоколу UDP с диапазонами портов 5060-5070 и 10000-20000
6. Так как в сети возможно появление пользователей с произвольно настроенными DNS-серверами, независимо от настроек, распознаванием имен должен заниматься маршрутизатор.

Итак поехали.

В общем и целом для реализации п. 1 достаточно создать правило вида:

Суть правила. Если исходящий интерфейс=WAN, то заменить адрес отправителя первым адресом интерфейса, назначив порт динамически. Весьма универсально, особенно, если у вас адрес на WAN выдается динамически.

Теперь опубликуем web-сервер. Это работа с цепочкой dst-nat.

Так как у нас один внешний адрес, нам для однозначного определения пакета достаточно знать порт, протокол и с какого интерфейса пакет пришел.

Усложненный вариант п.2. Публикация терминального сервера с изменением порта назначения.

Обратите внимание, что добавляется поле to-ports, которое сообщает маршрутизатору, что необходимо кроме адреса, так же изменить порт назначения.

Теперь еще более сложная задача. Нужно опубликовать два больших диапазона портов. Решение, как ни странно простое.

Вот таким образом можно публиковать большие диапазоны портов.

Ну и наконец принудительно заставляем всех пользоваться DNS-сервером маршрутизатора.

Основной ошибкой при настройке NAT является отсутствие указания адреса и/или интерфейса, с которого приходит пакет в случае dst-nat или с которого уходит пакет в случае src-nat.

Например, правило указанное в п.1, если из него убрать out-interface будет выглядеть так:

И приведет к тому, что адрес отправителя любого пакета проходящего через маршрутизатор, будет меняться на адрес маршрутизатора.

Вторым вариантом не столько ошибки, сколько потенциальной ошибкой, является использование NAT в качестве фильтра пакетов.

Например, мы хотим чтобы web-сервер опубликованный в п.2 был доступен только с адреса 2.2.2.2 и как следствие создаем правило:

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

Кроме того, в первой части статьи посвященной NAT, я обратил Ваше внимание, что NAT обрабатывает только первый пакет соединения.

В этой статье мы рассмотрели наиболее типичные конфигурации NAT. В следующих частях статьи мы рассмотрим более сложные варианты конфигураций.

Технический директор Илья Князев (MTCNA, MTCWE, MTCTCE)