 |
|
|
|
FreeBSD tips: использование ipnat
FreeBSD tips: использование ipnat В одной из предыдущих статей [1] было рассмотрено построение сервера NAT на основе FreeBSD и natd. Данная статья будет посвящена другому средству – модулю ipnat, входящему в пакет IPFilter. Сам IPFilter уже рассматривался на страницах журнала [2]. Некоторые основополагающие моменты я повторю, чтобы сохранить целостность и самодостаточность этого материала, а сосредоточимся мы именно на построении сервера NAT. Во FreeBSD 5.3 IPFilter (ipf), входящий в состав системы, может быть встроен в ядро, для чего ядро нужно пересобрать с опциями IPFILTER и IPFILTER_LOG. Так же ipf может быть запущен как модуль. Я воспользуюсь второй возможностью. Итак, ядро трогать не будем. Для работы ipnat фильтр ipf должен быть настроен и запущен. В простейшем случае достаточно запустить его с парой правил, разрешающих прохождение любых пакетов, что может быть оправдано в том случае, если регулирование пакетов вы уже осуществляете другим фильтром. Правила заносятся по умолчанию в /etc/ipf.rules: Файл /etc/ipf.rules pass in from any to any pass out from any to any Запуск фильтра можно выполнить из командной строки: # ipf -Fa -f /etc/ipf.rules Ключ -Fa очищает все ранее заданные правила и загружает те, которые перечислены в конфигурационном файле. Для автоматического запуска фильтра при перезагрузке добавьте опцию «ipfilter_enable = “YES”» в /etc/rc.conf. Если поддержка фильтра не включалась в ядро, в списке подгруженных модулей появится модуль ipl.ko. Аналогично правила трансляции адресов записываются по умолчанию в файл /etc/ipnat.rules. Запуск ipnat выполняется командой: # ipnat -CF -f /etc/ipnat.rules Ключ -C очищает таблицу правил, ключ -F удаляет записи из таблицы трансляций. Поскольку ipnat является, по сути, частью пакетного фильтра, то никакого перенаправления трафика на вход этого NAT-сервера не требуется. Входящие пакеты сначала будут подвергаться трансляции (пройдут через правила ipnat), затем поступят на вход ipf. Исходящие пакеты, наоборот, сначала фильтруются на ipf, а что будет пропущено, подвергается трансляции в соответствии с правилами ipnat. Для автоматического запуска при перезагрузке в /etc/rc.conf добавьте строчку «ipnat_enable = “YES”». Итак, приступим к рассмотрению правил трансляции. Замечу, что, в отличие от ipfw, в ipf и ipnat, правила не нумеруются, и их порядок определяется последовательностью загрузки, то есть местом в конфигурационном файле. Собственно трансляция пакетов, исходящих с машин локальной сети в Интернет (маскарадинг), осуществляется правилом map: map rl0 from 192.168.0.0/24 to any -> 100.100.100.101/32 Читать его очень просто, почти как на естественном языке: преобразовывать пакеты, проходящие через интерфейс rl0, с адресов, принадлежащих указанной подсети, на любые адреса, заменив адрес отправителя указанным реальным. Если конкретизация адресов назначения не требуется, можно использовать и упрощенный синтаксис: map rl0 192.168.0.0/24 -> 100.100.100.101/32 Правило может быть дополнено некоторыми опциями, из которых наиболее часто используется portmap. Она конкретизирует, на какие номера портов отображать пакеты. Диапазон портов, которые разрешается использовать для целей трансляции, задается в виде begin:endN. Например, следующее правило позволяет использовать только TCP-порты с 10000 по 10999: map rl0 192.168.0.0/24 -> 100.100.100.101/32 portmap tcp 10000:10999 После символов «–>» может быть указан не только один адрес, но и подсеть внешних адресов. В этом случае правило map сможет использовать любой свободный адрес из указанной подсети. Для безусловной двунаправленной трансляции между внутренним и внешним адресами используется правило bimap: bimap rl0 192.168.0.125/32 -> 100.100.100.125/32 Помимо трансляции исходящих пакетов все входящие пакеты, адресованные хосту 100.100.100.125, будут перенаправляться на «внутреннюю» машину. Это правило позволит машине с адресом 192.168.0.125 выглядеть снаружи так, как будто она имеет реальный адрес 100.100.100.125. Если нужно пропускать пакеты, приходящие на определенные порты, внутрь локальной сети, например, если там размещен Web- или FTP-сервер, используются правила перенаправления: rdr rl0 100.100.100.180/32 port 80 -> 192.168.0.80 port 8080 tcp В этом случае TCP-пакеты, адресованные на 80-й порт хоста 100.100.100.125, будут транслироваться на порт 8080 машины, расположенной внутри локальной сети. Одним из интересных свойств редиректа является возможность создавать балансировщик нагрузки между несколькими серверами, хотя и довольно примитивный. Например, следующие правила будут поочередно перенаправлять входящие запросы то на один, то на другой сервер: rdr rl0 100.100.100.180/32 port 80 -> 192.168.0.80 port 8080 tcp round-robin rdr rl0 100.100.100.180/32 port 80 -> 192.168.0.81 port 8080 tcp round-robin Опция round-robin заставляет динамически менять порядок правил таким образом, что эти правила срабатывают по очереди. Для контроля за работой ipnat используются два ключа: -s и -l. Первый выдает общую статистику работы NAT-сервера: # ipnat –s
Ipnat со вторым ключом выводит список активных правил и список активных в данный момент сеансов: # ipnat –l
Дополнительные сведения можно, как обычно, получить на страницах справочного руководства man ipnat(5), ipnat(1). Замечу, что ipfw, natd, ipf, ipnat отлично уживаются вместе. Нужно только не забывать про особенности фильтров: ipfw срабатывает по первому совпадению, а ipf (без опции quick в правиле) – по последнему. Ну и всегда следует иметь в виду порядок прохождения пакета через фильтры. Так, если поддержка ipf собрана в ядре, то независимо от того, как запущен ipfw, в первую очередь пакеты будут проходить через правила ipf, а ipfw получит на вход только то, что будет им пропущено. Если же ipfw собран в ядре, а ipf подгружен как модуль, то правом первенства будет пользоваться ipfw. Как natd, так и ipnat, отлично справляются с типовыми задачами трансляции адресов, и выбор между ними – скорее дело вкуса. В «экзотических» случаях могут понадобиться уникальные свойства того или иного сервера. Например, средства проксирования у natd более развиты, чем у ipnat, зато с помощью ipnat намного проще реализовать трансляцию различных групп адресов по разным правилам. Если ipnat способен решать те задачи, которые вам требуются, то, учитывая его «близость» к ядру и, следовательно, лучшее быстродействие, рекомендуется использовать этот сервер NAT. К тому же его конфигурация выглядит немного более удобной. Литература:
|
СЕРГЕЙ СУПРУНОВКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
