Налаштування шлюзу

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

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

По-перше, оскільки пересилка пакетів відключена за замовчуванням у всіх BSD системах, нам необхідно її включити, щоб машина мала можливість передавати

трафік з одного інтерфейсу в інші мережі за допомогою одного або декількох

інтерфейсів Спочатку, ми зробимо цю операцію в командному рядку, використовуючи команду sysctl для традиційного IPv4:

# sysctl netinetipforwarding=1

Якщо нам необхідно передавати трафік IPv6, використовуємо таку команду:

# sysctl netinet6ip6forwarding=1

Тепер все прекрасно Однак, щоб зміни збереглися після перезавантаження компютера, вам потрібно записати ці зміни до відповідних конфігураційні файли У OpenBSD і NetBSD, ви можете зробити це відредагувавши / etc / sysctlconf, додавши або змінивши рядки IP форвардинга наступним чином:

netinetipforwarding=1 netinet6ip6forwarding=1

У FreeBSD, зробіть зміни внісши наступні рядки в / etc / rcconf:

gateway_enable=&quotYES&quot #for ipv4 ipv6_gateway_enable=&quotYES&quot #for ipv6

Ефект однаковий RC скрипт FreeBSD встановить два значення за допомогою виконання команди sysctl Тим не менш, велика частина конфігурації FreeBSD сконцентрована в rcconf

Тепер прийшов час перевірити, чи всі інтерфейси, які ви збираєтеся використовувати, підняті і працюють Використовуйте для цього командуifconfig  -a  або ifconfig <імя_інтерфейса> Висновокifconfig -a на моїй системі виглядає приблизно так:

$ ifconfig -a

lo0: flags=8049&ltUP,LOOPBACK,RUNNING,MULTICAST&gt mtu 33224 groups: lo

inet 127001 netmask 0xff000000 inet6 ::1 prefixlen 128

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

xl0: flags=8843&ltUP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt mtu 1500 lladdr 00:60:97:83:4a:01

groups: egress

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

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

fxp0: flags=8843&ltUP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt mtu 1500 lladdr 00:30:05:03:fc:41

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

inet 1945410365 netmask 0xffffffc0 broadcast 19454103127 inet6 fe80::230:5ff:fe03:fc41%fxp0 prefixlen 64 scopeid 0x2 pflog0: flags=141&ltUP,RUNNING,PROMISC&gt mtu 33224

enc0: flags=0&lt&gt mtu 1536

Швидше за все, ваші установки дещо інші Тут видно фізичні інтерфейси шлюзу xl0 і fxp0 Логічний інтерфейс lo0 (інтерфейс заглушка або зворотна петля), enc0 (інтерфейс інкапсуляції для використання IPSEC) і pflog0 (пристрій журналирования pf) швидше за все так же присутствую у вашій системі Якщо ви працюєте з модемного зєднання, ви ймовірно використовуєте який або варіант PPP для зєднання з Інтернет, і ваш зовнішній інтерфейс – псевдопристроїв tun0

Якщо підключення здійснюється через яке або широкосмугове підключення, можливо ви маєте який або Ethernet інтерфейс Однак, якщо ви потрапляєте в

підмножина користувачів ADSL які використовують PPPoE, коректним зовнішнім

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

Залежно від вашої конкретної установки, вам може знадобитися створити специфічні налаштування для пристроїв вашого інтерфейсу Після того, як ви

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

конфігурацією пакетного фільтра

Якщо ви все-таки вирішили дозволити будь-який трафік, ініційований машинами внутрішньої мережі, ваш файл конфігурації/etc/pfconf  для шлюзу може виглядати

наступним чином:

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 46, можуть бути використані для застосування дій до зєднань відповідним певним критеріям безпрінятія рішення про блокування чи пропуску зєднання

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

гарантувати, що при зміна IP адреси інтерфейсу, трафік вашої мережі буде

рухатися без значних перебоїв Якщо ваша система працює на базі версії pre-OpenBSD 47 PF, ваш набір правил для шлюзу може виглядати приблизно так:

ext_if = &quotre0&quot # macro for external interface – use tun0 or pppoe0 for PPPoE int_if = &quotre1&quot # 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 -&gt ($ext_if)

block all

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

Тут, правило nat управляє трансляцією аналогічно правилу nat-to з попереднього прикладу

З іншого боку, цей набір правил дозволяє дещо більше того, що ви хочете дозволити на виході з вашої мережі В одній з мереж, з якою я багато працював, основна частина набору правил була заснована на макросе названому client_out:

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

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 = &quot{ domain, ntp }&quot

Це доповнить правило пропускає трафік через наш брандмауер:

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

Зверніть увагу на ключове словоquick в цьому правилі Ми почали писати набір правил, що з кількох правил, і тепер настав час переглянути відносини і взаємозвязки між ними Як уже зазначалося в попередньому розділі, правила оцінюються зверху вниз, в послідовності їх запису у файлі конфігурації Для кожного пакета або зєднання оцінюваного PF, застосовується останнім відповідне правило набору

Ключове слово quick пропонує піти від звичайної послідовності перевірки Коли пакет відповідає правилуquick, Він обробляється відповідно з даним правіломОбработка правил зупиняється, без урахування будь-яких додаткових правил, які так само можуть відповідати пакету Оскільки, з часом, набір правил стає більше і складніше, ви можете порахувати це зручним Наприклад, це досить корисно, коли вам необхідно декілька ізольованих винятків для ваших основних правил Це правило quick обробляє протокол NTP, який використовується для синхронізації часу Спільним для сервісу дозволу імен та протоколу синхронізації часу є те, що вони можуть, при певних обставин, взаємодіяти поперемінно через TCP і UDP

Тестування вашого набору правилМожливо ви ще не можете провести формальну перевірку записаного набору правил, але є всі підстави перевірити, що ваша конфігурація працює так як очікувалося У силі залишаються всі теже основні принципи тестування, які ми використовували для

автономного прикладу з попередньої глави Однак, тепер вам необхідно провести перевірку з інших хостів мережі, і з вашого шлюзу фільтрації пакетів Необхідно переконається, що для кожного з сервісів, котриє ми вказали в нашому правилі пропуску, машини в локальній мережі отримають позитивний результат З будь-якого компютера, що перебуває у вашій локальній мережі, введіть команду подібну наступною:

$ host nostarchcom

Вона повинна повернути той же результат, який ви отримали коли тестували набір правил для автономної машини в попередньому розділі, а трафік для сервісу який ви вказали повинен бути пропущен4

Врізка: Чому тільки IP адреси, а не імена хостів або доменні імена

Якщо розглядати приклади, з якими ми працювали до цього моменту, можна помітити, що набір правил містить макроси, які розгортаються в IP Дареса або діапазони IP адрес, але ніколи в імена хостів

або доменні імена Вам напевно цікаво чому Зрештою, ви бачили, що PF дозволяє

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

Відповідь така: якщо б ви використовували імена хостів або доменні імена в своєму наборі правил, набір правил був би дійсний тільки після того, як запрацює і стане доступна служба імен У

конфігурації за замовчуванням, PF завантажується раніше ніж запускаються будь-які мережеві служби Це означає, що якщо ви хочете використовувати доменні імена або імена хостів у вашій конфігурації PF, вам

необхідно змінити послідовність запуску системи (шляхом редагування файлу / etc / rclocal) для завантаження набору правил залежного від сервісу дозволу імен тільки після доступності сервісу

дозволу імен

Короткий перелік реальних портів 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, Вам необхідно додати цей рядок у ваш файл

ftpproxy_flags=&quot&quot

Ви можете запустити проксі вручну виконавши/usr/bin/ftp-proxy, Щоб переконається, що зміни в конфігурації PF, які ви зробили принесли очікуваний ефект

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

/etc/pfconf: Якір і два правила пропуску Якір оголошується приблизно так:

anchor &quotftp-proxy/*&quot

У версії pre-OpenBSD 47, необхідно оголосити два якоря:

nat-anchor &quotftp-proxy/*&quot rdr-anchor &quotftp-proxy/*&quot

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

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

Зверніть увагу на частину rdr-to Вона перенаправляє трафік на локальний порт, на якому слухає проксі

Для версії pre-OpenBSD 47 це правило виглядає так:

rdr pass on $int_if proto tcp from any to any port ftp -&gt 127001 port 8021

Нарешті, додамо пропускає правило для дозволу руху пакетів від проксі в зовнішній світ:

pass out proto tcp from $proxy to any port ftp

$proxy  розширюється на адресу з яким повязаний демон проксі Перезавантажте вашу конфігурацію PF:

$ sudo pfctl -f /etc/pfconf

Знайте, що ваші користувачі будуть вдячні вам за можливість використання 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 = &quotechoreq&quot

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

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):

# &quotbase+nhops*nqueries-1&quot (33434+64*3-1)

pass out on $ext_if inet proto udp to port 33433 &gt&lt 33626

Це дає вам розуміння того як виглядає діапазон портів Вони дуже корисні в деяких контекстах

Досвід показує, що реалізації трасування на інших операційних системах працюють приблизно аналогічним чином Помітним винятком є ​​лише

Microsoft Windows Таким чином, якщо ви хочете, щоб трасування працювала в Windows, вам необхідно тільки перше правило, і, крім того, необхідно дозвіл

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

командного рядка -l Для отримання більшої інформації зверніться до man-сторінці

Це рішення засноване на зразку правила, яке я знайшов в одному з постів openbsd-misc Я виявив, цей список розсилки і архів списку (доступний на http://marcinfo/), який може стати цінним ресурсом інформації по 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 = &quot{ echoreq, unreach }&quot

Як ви можете бачити, вам не потрібно міняти саме правило пропуску:

pass inet proto icmp icmp-type $icmp_types

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

Таблиці зроблять ваше життя простішеЗараз ви можете вирішити, що конфігурація занадто статична і жорстка Зрештою, тут будуть некотрие види даних, що мають відношення до фільтрації і перенаправлення трафіку, однак вони не заслуговують того, щоб знаходиться в конфігураційному файлі Це цілком справедливо, і PF пропонує механізм для вирішення цієї ситуації

Таблиці – одна з таких можливостей Вони корисні в якості списків IP адрес, якими можна маніпулювати без перезавантаження всього набору правил, і крім того, корисні для швидкого пошуку Імена таблиць завжди полягають у &lt &gt, Наприклад:

table &ltclients&gt persist { 19216820/24, 19216825 }

Тут мережу 19216820/24 є частиною таблиці з одним винятком: адреса 19216825 виключається шляхом використання оператора (Логічний NOT) Ключове слово persist гарантує, що сама таблиця буде існувати навіть якщо немає ніяких правил, в даний час використовують її Крім того, можна завантажити таблиці з файлів, в яких кожен елемент коштує в окремому рядку, наприклад таких як

19216820/24

!19216825

Він, у свою чергу, використовується для ініціалізації таблиці в /etc/pfconf:

table &ltclients&gt persist file &quot/etc/clients&quot

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

pass inet proto tcp from &ltclients&gt to any port $client_out

Маючи це ви можете уравлять вмістом таблиць наживо, подібно наступного:

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

6 Основні RFC описують ICMP і деякі повязані з ним методи – 792, 950, 1191, 1256, 2521 і 2765 Оновлення ICMP для IPv6 описано в документах RFC 1885, RFC 2463, RFC 2466 Ці документи можна знайти на http://wwwietforg/ і

http://wwwfaqsorg/

Зверніть увагу, що при цьому копія таблиці змінюється тільки в памяті, а значить після перезавантаження або збою живлення зміни не збережуться ви можете вибрати шлях збереження копії таблиці на диску, використовуючи завданняcron  для створення дампа таблиці з регулярними інтервалами, використовуючи приблизно таку команду:

$ sudo pfctl -t clients -T show &gt/etc/clients

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

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

Для тих операцій, які ви плануєте виконувати частину, рано чи пізно, справа закінчиться написанням скриптів Цілком імовірно, що рутинні операції, такі як вставка або видалення елементів, заміна вмісту таблиці або інші, стануть в найближчому часі метою написання деяких скриптів

Одним з поширених прикладів, є обеспечнних доступу до мережі за допомогою завдань cron, Які замінюють вміст таблиць в певний час в деяких мережах, можуть знадобитися різні правила доступу для різних днів тижня Єдино реальні обмеження лежать у ваших потребах і можливостях

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

Джерело: Книга про PF, by Peter NM Hansteen, Переклад виконав Михайлов Олексій aka iboxjo

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*