Настройка шлюза

Мы используем конфигурацию простой машины которую построили в предыдущей главе в качестве  основы  для построения конфигурации фильтра  пакетов  шлюза. Предположим, что  на  машину установлена  дополнительная  сетевая  карта  (или  вы  создали  сетевое подключение из локальной сети к одной или более сетей через Ethernet, PPP или другим способом). В нашем  контексте детали настроек интерфейсов незначительны. Мы просто должны знать, что интерфейс поднят и работает.

Для последующего обсуждения и примеров,  различаются только имена  интерфейсов между настройками PPP и Ethernet, и мы сделаем всё  возможное  чтобы избавиться  от фактических имён интерфейсов как можно скорее.

Во-первых,   поскольку  пересылка  пакетов  отключена  по  умолчанию  во   всех   BSD системах, нам необходимо её включить,  чтобы машина имела  возможность  передавать

трафик  с  одного  интерфейса  в    другие  сети  с  помощью  одного  или   нескольких

интерфейсов. Первоначально, мы сделаем эту операцию в  командной строке, используя команду sysctl для традиционного IPv4:

# sysctl net.inet.ip.forwarding=1

Если нам необходимо передавать трафик IPv6, используем следующую команду:

# sysctl net.inet6.ip6.forwarding=1

Теперь  всё  прекрасно.  Однако,  чтобы  изменения  сохранились  после  перезагрузки компьютера,     вам     требуется     записать     эти     изменения     в     соответствующие конфигурационные   файлы.   В    OpenBSD    и    NetBSD,    вы    можете    сделать   это отредактировав /etc/sysctl.conf, добавив или изменив строки IP форвардинга следующим образом:

net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1

В FreeBSD, произведите изменения внеся следующие строки в /etc/rc.conf:

gateway_enable="YES" #for ipv4 ipv6_gateway_enable="YES" #for ipv6

Эффект  одинаковый;   RC   скрипт   FreeBSD  установит   два   значения   посредством выполнения   команды  sysctl.  Тем  не  менее,  большая  часть   конфигурации  FreeBSD сконцентрирована в rc.conf.

Теперь  пришло  время   проверить,   все   ли  интерфейсы,  которые  вы   собираетесь использовать,  подняты  и  работают.  Используйте  для  этого  команду  ifconfig  -a  или ifconfig <имя_интерфейса>. Вывод  ifconfig -a на  моей системе выглядит  примерно так:

$ ifconfig -a

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224 groups: lo

inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128

inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5

xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 00:60:97:83:4a:01

groups: egress

media: Ethernet autoselect (100baseTX full-duplex) status: active

inet 194.54.107.18 netmask 0xfffffff8 broadcast 194.54.107.23 inet6 fe80::260:97ff:fe83:4a01%xl0 prefixlen 64 scopeid 0x1

fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 00:30:05:03:fc:41

media: Ethernet autoselect (100baseTX full-duplex) status: active

inet 194.54.103.65 netmask 0xffffffc0 broadcast 194.54.103.127 inet6 fe80::230:5ff:fe03:fc41%fxp0 prefixlen 64 scopeid 0x2 pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33224

enc0: flags=0<> mtu 1536

Скорее всего,  ваши  установки  несколько иные. Здесь видны  физические  интерфейсы шлюза xl0 и fxp0. Логический интерфейс lo0 (интерфейс заглушка или обратная петля), enc0   (интерфейс   инкапсуляции   для   использования   IPSEC)   и   pflog0   (устройство журналирования pf) скорее всего так же присутствую в вашей системе. Если вы работаете с  модемного  соединения,  вы   вероятно   используете  какой  либо  вариант   PPP  для соединения с Интернет, и ваш внешний интерфейс – псевдоустройство tun0.

Если  подключение осуществляется  через  какое  либо  широкополосное  подключение, возможно  вы  имеете  какой  либо  Ethernet  интерфейс.  Однако,  если  вы  попадаете  в

подмножество  пользователей  ADSL  которые  используют  PPPoE,  корректным  внешним

интерфейсом будет одно из псевдо-устройств  tun0 или pppoe0 (в  зависимости  от  того, используете ли вы pppoe(8) в пространстве пользователя или pppoe(4) в режиме ядра), а не физический интерфейс Ethernet.

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

завершите  их  настройку,  можете  перейти  на  уровень  TCP/IP  и  начать  работать  с

конфигурацией пакетного фильтра.

Если  вы   всё-таки   решили  разрешить  любой  трафик,  инициированный   машинами внутренней  сети, ваш  файл конфигурации  /etc/pf.conf  для шлюза  может выглядеть

следующим образом:

ext_if = "re0" # макрос для внешнего интерфейса – используйте tun0 или pppoe0 для PPPoE

int_if = "re1" # макрос для внутреннего интерфейса localnet = $int_if:network

# ext_if IP address could be dynamic, hence ($ext_if)

match out on $ext_if from $localnet nat-to ($ext_if) block all

pass from { lo0, $localnet }

Обратите внимание на использование макросов для назначения логических имён сетевым интерфейсам. В данном случае используются Ethernet карты Realtek,  но это последний раз, когда мы обращаемся к типу интерфейса в  нашем  контексте. Для столь простой конфигурации  как  эта,  мы  не  можем  получить  видимого  эффекта  от  использования макросов,  но как только набор правил  начинает расти, вы  сможете оценить удобство чтения, привносимое использованием макросов.

Кроме того, следует обратить внимание на правило содержащее элемент nat-to. Здесь вы управляете  NAT с не маршрутизируемым адресом внутри  вашей  локальной сети, т.е. адресом   предоставленным   вам   ISP.   Если   ваша   сеть   использует   оффициальные, маршрутизируемые   адреса,   просто   уберите   эту   строку   в     вашей   конфигурации. Соответствующие   правила,   которые   были   введены   в     OpenBSD   4.6,   могут   быть использованы для применения действий к соединениям соответствующим определённым критериям безпринятия решения о блокировании или пропуске соединения.

Круглые  скобки  последней  части  правила   ($ext_if)  необходимы  для   компенсации возможности  динамического  назначения  IP  адреса  внешнего  интерфейса.  Это  будет

гарантировать,  что  при  изменение  IP  адреса  интерфейса,  трафик  вашей  сети  будет

двигаться без значительных перебоев. Если ваша система работает на базе версии pre- OpenBSD 4.7 PF, ваш набор правил для шлюза может выглядеть примерно так:

ext_if = "re0" # macro for external interface – use tun0 or pppoe0 for PPPoE int_if = "re1" # macro for internal interface

localnet = $int_if:network

# ext_if IP address could be dynamic, hence ($ext_if) nat on $ext_if from $localnet to any -> ($ext_if)

block all

pass from { lo0, $localnet } to any keep state

Здесь, правило  nat управляет  трансляцией аналогично правилу  nat-to из  предыдущего примера.

С другой стороны, этот набор правил позволяет несколько больше того, что вы хотите разрешить на выходе  из вашей  сети. В одной из сетей, с которой я  много работал, основная часть набора правил была основана на макросе названном client_out:

client_out  =  "{  ftp-data,  ftp,  ssh,  domain,  pop3,  auth,  nntp,  http,https,  446, cvspserver, 2628, 5999, 8000, 8080 }"

pass inet proto tcp from $localnet to port $client_out

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

pass in inet proto tcp to port ssh

Или используйте такую форму если вам удобно:

pass in inet proto tcp to $ext_if port ssh

Когда  вы  используете  часть  from,  по  умолчанию  используется  from  any,  которая является весьма разрешительной. Это позволяет вам входить в  систему из любого места, что весьма  удобно для доступа по SSH из неизвестного  места.  Если вы  не на столько мобильны – скажем, вы  не слишком любите  соединение  из неизвестных  мест или вы хотите бросить своих коллег на произвол судьбы, пока находитесь в отпуске – вы можете указать from с включением только тех мест, из которых администратор может входить в систему.

Наш простой набор правил до сих пор не завершён. Нам необходимо создать названия рабочих сервисов  для наших клиентов.  Мы начнём с другого макроса  в  начале нашего набора правил.

udp_services = "{ domain, ntp }"

Это дополнит правило пропускающее трафик через наш брандмауэр:

pass quick inet proto { tcp, udp } to port $udp_services

Обратите внимание на ключевое слово  quick в  этом правиле. Мы начали писать набор правил,   состоящий  из  нескольких  правил,   и  теперь  настало  время   пересмотреть отношения и взаимосвязи между ними. Как уже отмечалось в предыдущей главе, правила оцениваются  сверху вниз, в  последовательности их записи в  файле конфигурации. Для каждого    пакета    или    соединения     оцениваемого     PF,    применяется    последнее соответствующее правило набора.

Ключевое слово quick предлагает уйти от обычной последовательности проверки. Когда пакет  соответствует   правилу   quick,  он  обрабатывается   в   соответствии   с  данным правилом.Обработка правил останавливается, без учёта любых дополнительных правил, которые так же могут соответствовать  пакету.  Поскольку, со временем,  набор правил становится больше и сложнее, вы можете посчитать это удобным. Например, это весьма полезно,  когда  вам   необходимо  несколько  изолированных   исключений  для  ваших основных правил.  Это правило  quick обрабатывает  протокол NTP, который используется для  синхронизации  времени.   Общим  для  сервиса   разрешения  имён  и   протокола синхронизации времени является то, что они могут, при определённых обстоятельствах, взаимодействовать попеременно через TCP и UDP.

Тестирование вашего набора правил                                      Возможно вы ещё не можете провести формальную проверку записанного набора правил, но есть все основания проверить, что ваша конфигурация работает так как ожидалось. В силе остаются все теже основные принципы тестирования, которые мы использовали для

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

$ host nostarch.com

Она должна возвратить тот же результат , который вы получили когда тестировали набор правил для автономной машины в  предыдущей главе, а трафик для сервиса который вы указали должен быть пропущен.4

Врезка: Почему только IP адреса, а не имена хостов или доменные имена?

Если рассматривать примеры, с которыми мы работали до этого момента, можно заметить, что набор правил содержит макросы, которые развёртываются в IP дареса или диапазоны IP адресов, но никогда в имена хостов

или  доменные  имена.  Вам  наверно  интересно  почему?  В  конце  концов,  вы  видели,  что  PF  позволяет

использовать  имена сервисов  в  наборе правил,  так почему бы не включать  и имена хостов  или  доменные имена?

Ответ  таков:  если бы вы  использовали  имена хостов  или доменные имена в  своём  наборе  правил,  набор правил  был  бы  действителен  только  после  того,  как  заработает  и  станет  доступна  служба  имён.  В

конфигурации по умолчанию, PF загружается раньше чем запускаются любые сетевые службы. Это означает, что  если  вы  хотите  использовать  доменные  имена  или  имена  хостов  в   вашей  конфигурации  PF,  вам

необходимо изменить последовательность  запуска системы (путём редактирования  файла  /etc/rc.local) для загрузки  набора  правил   зависимого   от  сервиса   разрешения  имён  только   после  доступности  сервиса

разрешения имён.

Этот старый FTP                                                                        

Краткий перечень реальных портов TCP мы уже рассматривали раньше, и в том числе FTP

–   классический протокол передачи файлов.  FTP является  реликтом раннего  Интернета, времени, когда эксперименты были нормой и вопросы безопасности ещё не были столь

важными  в  современном  смысле этого слова.  Фактически FTP является  предвестником

TCP/IP5, и развитие протокола можно отследить обратившись к RFC 50. После, более чем 30 лет, FTP, одновременно является раритетной вещью и проблемным ребёнком, для тех кто пытается объединить FTP и брандмауэр. FTP старый и странный протокол, не любимый многими. Вот наиболее распространённые причины за которые его не взлюбили:

•     пароли передаются в открытом виде

•     протокол   требует   использования   по   крайней   мере   двух   TCP   соединений (управления и данных) на отдельных портах.

•     после установления сеанса, данные передаются через порты выбраные случайным образом

Все эти факторы создают проблемы с точки зрения безопасности, ещё до того, как можно начать  рассматривать  любые  потенциальные  недостатки  в  программном  обеспечение клиента и сервера. При любых обстоятельствах, существуют другие, более современные и более безопасные средства  передачи файлов,  например SFTP и SCP, которые включают возможности   аутентификации   и  передачи  данных  через  защищённое  соединение. Компетентные  специалисты  IT  всегда  должны  предпочесть  формы  передачи  файлов отличные от FTP.

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

брандмауэр, мы можем бороться с возникающими  проблемами путём  перенаправления

трафика на специальную программу. созданную именно для этих целей.

4  Если конечно информация не изменилась за прошедшее время.  некоторые системные  администраторылюбят розыгрыши, однако большую  часть  времени  информация  зоны  DNS  изменяется  только  в   связи  с  реальной  потребностью  конкретной организации или сети.

5 Ранний RFC описывающий FTP протокол – RFC 114, датированный 10 апреля 1971 года. Переключение на TCP/IP произошедшее в FTP версии 5 определяется в RFC 765 и 775, датированных июнем и декабрём 1980 года соответственно.

Наиболее лёгкий путь для управления FTP – создать в  PF перенаправление трафика на внешний сервис, который действует в качестве прокси-сервера для данного сервиса.

Далее,  прокси  будет  взаимодействовать  с  вашим  пакетным  фильтром  через  чётко определённый интерфейс.

Если мы должны: FTP-прокси с перенаправлением              Включить  передачу  FTP  через  ваш  шлюз  удивительно  просто,  благодаря  тому,  что программа FTP-прокси включена в базовую систему OpenBSD. Как вы можете догадаться,

программа называется – ftp-proxy.

Прокси  необходимо  динамически  вставлять  правила  в   ваш  набор  правил.  ftp-proxy взаимодействует  с  конфигурацией  с  помощью  якоря  (именованой  секции  в   наборе правил) в  которой прокси вставляет или удаляет правила конструируя общение с вашим трафиком FTP.

Для  включения   ftp-proxy,  вам   необходимо  добавить   эту  строку  в    ваш   файл

/etc/rc.conf.local:

ftpproxy_flags=""

Вы можете запустить прокси вручную  выполнив  /usr/bin/ftp-proxy, чтобы  убедится, что изменения в конфигурации PF, которые вы сделали принесли ожидаемый эффект.

Для базовой  конфигурации, вам  необходимо добавить  всего  три элемента в  ваш  файл

/etc/pf.conf: якорь и два правила пропуска. Якорь объявляется примерно так:

anchor "ftp-proxy/*"

В версии pre-OpenBSD 4.7, необходимо объявить два якоря:

nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*"

Сюда прокси будет вставлять  правила  сгенерированные  для сессий FTP. Так  же вам необходимо правило пропуска для FTP трафика в прокси:

pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021

Обратите внимание на часть rdr-to. Она перенаправляет трафик на локальный порт, на котором слушает прокси.

Для версии pre-OpenBSD 4.7 это правило выглядит так:

rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021

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

pass out proto tcp from $proxy to any port ftp

$proxy  расширяется  в   адрес  с  которым  связан  демон  прокси.  Перезагрузите  вашу конфигурацию PF:

$ sudo pfctl -f /etc/pf.conf

Знайте, что ваши пользователи будут благодарны вам за возможность использования FTP. Этот пример охватывает основные настройки, необходимые для доступа ваших клиентов к удалённому  FTP  серверу.  Данная  базовая  конфигурация  должна  хорошо  работать  в большинстве случаев и в различных комбинациях FTP клиентов и серверов.

Вы можете изменить поведение  прокси, добавляя  опции к строке  ftpproxy_flags  =. Вы можете  столкнуться  и  с  причудливыми  клиентами  и  серверами,  однако  большинство проблем можно компенсировать  дополнительным конфигурированием  прокси. По этим

вопросам, вам лучше всего обратится к страницам руководства. Если вы заинтересованы в способах запуска FTP сервера защищённого PF и ftp-proxy, вы можете обратить внимание на запуск отдельно ftp-proxy в  реверсном  режиме  (используя опцию -R), на отдельном порте с собственным пропускающим правилом перенаправления.

Замечание:

Если ваша версия PF более ранняя чем описано здесь, обратитесь к первому изданию этой книги и документации на вашу систему для получения более полной информации о использовании ранних версий ftp-proxy.

Сделаем решение проблем вашей сети простым                   Упрощение  разрешения  проблем  сети  –  тема  потенциально  большая.  Как  правило, отладка  и  устранение  неполадок  сети  TCP/IP  зависит  от  того,  как  вы  относитесь  к специальным протоколам созданным для отладки, и в частности к ICMP. ICMP – протокол предназначенный  для  отправки  и  приема  управляющих  сообщений между  хостами  и шлюзами, предоставляющий  обратную связь  с отправителем  информирующую о каких-

либо необычных и проблемных условиях на пути к целевому хосту.

В сети присутствует значительный объём трафика ICMP, проходящего в фоновом режиме, в  то время,  когда вы  занимаетесь сёрфингом в  Интернет, читаете  почту  или передаёте

файлы. Маршрутизаторы (один из которых вы  строите, верно?)  используют  ICMP для

сообщения размера пакетов  и  других параметров  передачи в   процессе  которй  часто называют  исследованием  MTU. Возможно вы  слышали, что  администраторы упоминают ICMP как "зло", или если их понимание работает  несколько глубже – как "необходимое зло".  Причина  такого  отношения  сложилась  исторически.  несколько  лет  назад,  при исследовании сетевых стеков некоторых операционных систем, обнаружилось содержание кода, который мог приводить к сбою, в случае отправки большого ICMP запроса. Одной из компаний сильно пострадавшей  от этой проблемы стала Microsoft, и до сих  пор,  можно найти множество  информации от так называемом  пинге смерти  (ping  of death). Тем не менее, все эти события происходили во второй половине 90-х годов и все современные операционные системы имеют откорректированный код сетевой подсистемы (по крайней мере мы хотим в это верить).

Одним из первых  решений стала блокировка  эхо-запросов  ICMP или даже  всего  ICMP трафика.  Такие  наборы  правил  существовали  примерно  10  лет,  и  люди  которые  их

создали  до  сих  пор  боятся  этой  проблемы.  Однако,  скорее  всего,  довольно  мало

оснований  беспокоиться по поводу  разрушительного ICMP трафика, по этому  здесь мы будем рассматривать только то как управлять входящим и исходящим ICMP трафиком.

Будем пропускать всё?                                                              Возникает вполне очевидный вопрос – "Если ICMP такая полезная вещь, может следует разрешить весь  трафик и всё  время?".  Ответ  таков:  в  зависимости  от обстоятельств. Разрешение движения диагностического трафика конечно упростит отладку, но и упростит другим работу по извлечению полезной информации о вашей сети. Таким образом, могут оказаться  полезными  правила  позволяющие  скрыть  внутреннюю  работу  вашей  сети подобные следующим:

pass inet proto icmp

Лёгкий путь: Остановка здесь                                                 

Самым  простым  решением  может  оказаться,  что  весь  ICMP  трафик  локальной сети останавливается на вашем шлюзе:

pass inet proto icmp icmp-type $icmp_types from $localnet pass inet proto icmp icmp-type $icmp_types to $ext_if

Остановка   тестовых   сообщений  на  уровне   шлюза  может  быть   привлекательным вариантом  в   любом случае, однако давайте  рассмотрим  несколько других вариантов, которые продемонстрируют гибкость PF.

Разрешение прохода пинга                                                      Набор правил, который мы разработали до сих пор имеет один явный недостаток: общие команды диагностики, такие как ping и traceroute не будут работать. Возможно это и не имеет  большого  значения  для  пользователей,  поскольку  большинство  пользователей никогда  не  используют  эти  команды,  но  тем  кому  они  нужны  будет  приятно  иметь возможности  диагностики.  Для  этого  понадобится  всего  пара  дополнений  в   наборе правил.  ping  использует ICMP, и для того, чтобы поддерживать  наш набор правил  в аккуратном виде, мы начнём с определения нового макроса:

icmp_types = "echoreq"

Теперь добавим правило которое будет использовать определение:

pass inet proto icmp icmp-type $icmp_types

Если вы хотите использовать другие типы пакетов ICMP, вы можете расширить icmt_types в список требуемых типов пакетов.

Поможем traceroute                                                                  traceroute  – другая команда, которая является  весьма  полезной,  особенно  в  случае когда  пользователи  заявляют  вам  что  Интернет  не  работает.  По  умолчанию,  UNIX traceroute  использует  UDP  соединения  согласно  формуле  основанной  на  назначении. следующее правило  работает с  командой traceroute на всех  формах Unix с которыми я

работал, в том числе и на Linux:

# allow out the default range for traceroute(8):

# "base+nhops*nqueries-1" (33434+64*3-1)

pass out on $ext_if inet proto udp to port 33433 >< 33626

Это даёт вам  понимание того как выглядит  диапазон портов.  Они весьма  полезны в некоторых контекстах.

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

Microsoft  Windows.  Таким  образом,  если  вы  хотите,  чтобы  трассировка  работала  в Windows, вам необходимо только первое правило, и, кроме того, необходимо разрешение

ping. Программе трассировки Unix может быть указано использование другого протокола, и она будет вести  себя аналогично трассировке  Microsoft если вы  используете опцию

командной строки -l. Для получения большей информации обратитесь к  man-странице

traceroute.

Это решение основано на образце правила, которое я нашёл в одном из постов openbsd- misc. Я обнаружил, этот список рассылки и архив списка (доступный на http://marc.info/), который может стать ценным ресурсом информации по OpenBSD или PF.

Исследование MTU                                                                     Ещё  раз хочу напомнить, что когда дело доходит до устранения  неполадок  – это путь исследования   MTU.  Протоколы  Интернет  разработаны   так,  чтобы  быть  аппаратно независимыми,  и одним из последствий  этого,  является  то, что вы  не всегда  можете предсказать  наверняка,  каков  оптимальный  размер  пакета  для  данного  соединения. Основное    ограничение    на   размер   пакета   называется    максимальным   размером передаваемого блока данных, или MTU, который устанавливает верхний предел на размер пакета  для  интерфейса.  Команда  ifconfig  может  показать  вам   MTU   для  сетевых интерфейсов. Современная реализация TCP/IP имеет возможность поределить правильный размер пакета для процесса подключения,  который включает  в  себя передачу пакетов различного  размера  в   рамках  MTU  локального  линка  с  установленным  флагом  "not fragment". Если пакет  превышает  MTU, гдето на пути следования  к назначению, хост с более низким  MTU вернёт  ICMP пакет указывающий  "type 3, code 4" при достижении локального верхнего предела.

Теперь вам не нужно сразу нырять в  RFC. type 3 означает недоступность назначения, а code  4  -требование  фрагментации,  при  установленном  флаге  "not  fragment".  Таким образом, если ваше  соединение с другими сетями,  имеющими отличные значения MTU, окажется не оптимальным, вы  можете  попытаться изменить список типов  ICMP, чтобы пропускать пакеты недоступности назначения:

icmp_types = "{ echoreq, unreach }"

Как вы можете видеть, вам не нужно менять само правило пропуска:

pass inet proto icmp icmp-type $icmp_types

Сейчас я открою вам  маленький секрет: для целей исследования  MTU эти  правила  не всегда необходимы (однако они не помешают). Хотя, по умолчанию, PF хранит состояния о поведении большинства ICMP трафика необходимого вам, он позволяет иметь фильтры на все  варианты  типов  и кодов  ICMP. Если вы  хотите подробно разобраться в  типах и кодах,  обратитесь  к  man-страницам  icmp(4)  и  icmp(6).  Дополнительную  справочную информацию можно получить из RFC6.

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

Таблицы – одна из таких возможностей.  Они полезны в  качестве  списков  IP  адресов, которыми можно манипулировать  без перезагрузки всего  набора  правил,  и кроме того, полезны для быстрого поиска. Имена таблиц всегда заключаются в < >, например:

table <clients> persist { 192.168.2.0/24, !192.168.2.5 }

Здесь  сеть  192.168.2.0/24  является  частью  таблицы  с  одним  исключением:  адрес 192.168.2.5 исключается путём использования  оператора ! (логический NOT). Ключевое слово persist гарантирует, что сама таблица будет существовать. даже если нет никаких правил,  в  настоящее время  использующих её. Кроме того, можно загрузить таблицы из файлов,  в   которых  каждый  элемент  стоит  в   отдельной  строке,  например  таких  как

/etc/clients:

192.168.2.0/24

!192.168.2.5

Он, в свою очередь, используется для инициализации таблицы в /etc/pf.conf:

table <clients> persist file "/etc/clients"

Так,  например,  вы  можете  изменить  одно  из  предыдущих  правил  для  управления исходящим трафиком компьютеров ваших клиентов:

pass inet proto tcp from <clients> to any port $client_out

Имея это вы можете уравлять содержимым таблиц вживую, подобно следующему:

$ sudo pfctl -t clients -T add 192.168.1/16

6 Основные RFC описывающие ICMP и некоторые связанные с ним методы – 792, 950, 1191, 1256, 2521 и 2765. Обновление ICMP для  IPv6  описано  в   документах  RFC  1885,  RFC  2463,  RFC  2466.  Эти  документы  можно  найти  на  http://www.ietf.org/  и

http://www.faqs.org/.

Обратите внимание, что при этом копия таблицы изменяется только в  памяти, а значит после перезагрузки или сбоя питания изменения не сохранятся. вы можете выбрать путь сохранения  копии  таблицы  на  диске,  используя  задания  cron  для  создания  дампа таблицы с регулярными интервалами, используя примерно следующую команду:

$ sudo pfctl -t clients -T show >/etc/clients

Альтернативно,  вы  можете отредактировать  файл /etc/clients и заменить  содержимое таблицы в памяти данными из файла:

$ sudo pfctl -t clients -T replace -f /etc/clients

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

Одним из распространённых примеров, является обеспечние доступа к сети с помощью заданий cron, которые заменяют содержимое таблиц в определённое время. в некоторых сетях,  могут  понадобиться  различные  правила   доступа   для  разных  дней  недели. Единственно реальные ограничения лежат в ваших потребностях и возможностях.

Мы  будем  возвращаться  к  удобству  использования  таблиц  в   дальнейших  главах  и взглянем  на несколько программ, предоставляющих  удобный  интерфейс для работы с таблицами.

Источник: Книга о PF, by Peter N.M. Hansteen, Перевод выполнил Михайлов Алексей aka iboxjo

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий