Зберігаємо стану синхронізація: додавання pfsync

Остання частина конфігурування – налаштування синхронізації таблиць станів між

хостами відмовостійкій групи Синхронізація таблиць станів на резервних брандмауерах дозволить уникнути очевидних перерв в трафіку під час відмов Це досягається за допомогою групи вірно налаштованих інтерфейсів pfsync (Як вже зазначалося раніше, на момент написання глави, NetBSD не підтримувала pfsync)

Налаштування інтерфейсів pfsync є предметом деякого планування та використання команди ifconfig Можна налаштувати pfsync на конфігурованому мережевому інтерфейсі, проте, найкращою ідеее буде установка окремої мережі для синхронізації У нашому прикладі конфігурації (малюнок 7-3), ми виділили для цієї мети маленьку мережу У нашому випадку, кроссоверним кабель зєднує два Ethernet інтерфейсу, але в конфігураціях з великим числом вузлів відмовостійкій групи, ви можете використовувати окремий комутатор, концентратор або VLAN

У даному прикладі ми плануємо використовувати для синхронізації IP адреси 1001216 і 1001217 З основною конфігурацією TCP / IP, повна установка pfsync для кожного з двох інтерфейсів партнерів синхронізації виглядає наступним чином:

$ sudo ifconfig pfsync0 syncdev ep2

Тут проілюстровано преймущество використання ідентичного обладнання, а так само підтримка трафіку pfsync на окремій фізичної мережі Сам протокол pfsync практично не надає засобів забезпечення безпеки Він не має механізмів перевірки автентичності та, за замовчуванням, спілкується використовуючи багатоадресний IP трафік Однак, для випадків, коли використання фізично окремої мережі неможливо, ви можете підняти безпеку pfsync шляхом створення специфічного вузла синхронізації (syncpeer):

$ sudo ifconfig pfsync0 syncpeer 1001216 syncdev ep2

Команда призведе до створення інтерфейсу параметри якого можна переглянути використовуючи ifconfig:

pfsync0: flags=41&ltUP,RUNNING&gt mtu 1500 priority: 0

pfsync: syncdev: ep2 syncpeer: 1001216 maxupd: 128 defer: off groups: carp pfsync

Ще один варіант підвищення безпеки – створити тунель IPsec і використовувати його для захисту трафіку синхронізації Тоді команда ifconfig буде наступна:

$ sudo ifconfig pfsync0 syncpeer 1001216 syncdev enc0

Це означає, що використовуваний пристрій інкапсуляції syncdev enc0, а не фізичний інтерфейс

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

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

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

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

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

Однак, ми ввели два нових протоколу: CARP і pfsync Цілком ймовірно вам доведеться внести деякі невеликі зміни в набір правил, необхідні для того, щоб перехід на резервний ресур працював як потрібно В принципі, вам необхідно направити трафік CARP і pfsync на відповідні інтерфейси

Найбільш прийнятним способом управління трафіком CARP є введення макросів для ваших carpdevs та відповідних правил pass, наприклад:

pass on $carpdevs proto carp

Вам необхідно передати трафік pfsync на відповідні інтерфейси Аналогічно, для трафіку pfsync, можна ввести макрос для syncdev і відповідне правило pass:

pass on $syncdev proto pfsync

Якщо ви хочете вивести пристрій pfsync з системи фільтрації використовуйте наступне правило:

set skip on $syncdev

Виключити pfsync інтерфейси з фільтрації обходиться дешевше фільтрувати і пропускати

Крім того, вам слід розглянути ролі віртуальних інтерфейсів CARP та їх адреси в порівнянні з фізичним інтерфейсом

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

pass in on $int_if from $ssh_allowed to self

Для цих правил ви можете використовувати опцію no-sync для запобігання синхронізації зміни стану для зєднань, які не мають відношення до

відмовостійкості:

pass in on $int_if from $ssh_allowed to self keep state (no-sync)

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

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

ifstated був введений в OpenBSD 35 як інструменту для запуску дій заснованих на зміні стану мережного інтерфейсу ви можете думати про ifstated як про маленького помічника CARP. ifstated включений в базову систему OpenBSD і доступний за допомогою портів net / ifstated на FreeBSD У OpenBSD, файл / etc / ifstatedconf (або

/ Usr / local / etc / ifstatedconf якщо ви встановили порт на FreeBSD) містить практично готову до роботи конфігурацію, яка дає вам безліч відповідей з налаштування ifstated в навколишньому середовищі

основні контрольовані обєкти – інтерфейси і їх стану, де carp0linkup – стан, в якому інтерфейс carp0 має звязок і ви виконуєте дії у відповідь на зміну стану Вони визначаються простою мовою сценаріїв з основними особливостями подібними змінним, макросам і простим логічним умовам Зверніться до man-сторінці ifstated і ifstatedconf якщо хочете розібратися детальніше

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

Доповнюючи балансування ARP, яка працює шляхом обчислення хешів, грунтуючись на MAC адресі джерела вхідного зєднання, CARP в OpenBSD 43 і вище підтримує кілька різновидів балансування IP навантаження, де трафік розподіляється на основі обчислення хешів IP адрес джерела і призначення зєднання Оскільки балансування ARP заснована на MAC адресі джерела, вона буде працювати тільки для хостів в безпосередньо підключеному мережному сегменті Метод засновані на IP більш слушно для балансування навантаження сполук у мережею Інтернет

Який вибрати режим залежить від вашого застосування і точних специфікацій мережевого устаткування що у роботі Основний режим IP балансування використовує груповий MAC адресу для створення безпосередньо подключенногокоммутатора направляючого трафік всім хостам кластера балансування навантаження Поєднання індивідуального IP адреси і групового MAC адреси може не підтримуватися деякими системами У такому випадку, вам може знадобитися настройка балансування навантаження в режимі одноадресний IP (ip-unicast mode) (який використовує індивідуальний MAC адреса) і конфігурувати ваш комутатор для направлення трафіку відповідним хостам, або в режимі невидимого IP (ip-stealth mode), який не використовує груповий MAC Як звичайно, проблеми ховаються в деталях, а відповіді можна знайти в керівництві та іншої документації, за умови проведення ряду експериментів

Традиційно, relayd використовувався для інтелектуальної балансування навантаження в якості фронтенда для серверів які пропонували свої сервіси У OpenBSD 47, relayd придбав можливість відстежувати доступні канали і змінювати таблиці маршрутизації грунтуючись на стані лінків, використовуючи обгортку з ключовим словом router Для установки з кількома можливими каналами або варіантами таблиць маршрутизації, ви можете налаштувати relayd для вибору вашого каналу, або з деякою допомогою змінних sysctl netinetipmultipath і netinet6ip6multipath, виконувати балансування навантаження між доступними маршрутами і каналами Конкретна специфіка змінюватиметься залежно від мережевого оточення man-сторінка relaydconf включає повний приклад для початку роботи

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

Яка група і яким фізичним хостом закінчується обробка даного зєднання – визначається CARP, за допомогою значення хешу, обчислюваного на підставі MAC адреси джерела зєднання в разі вибору ARP балансування, або IP адресі джерела і призначення при виборі IP балансування Зворотною стороною цього, є те, що кожна з цих груп споживає один віртуальний ідентифікатор хоста, так що брак ідентифікаторів при використанні конфігурації балансування навантаження, буде відчуватися швидше ніж при конфігурації відмовостійкості Насправді, існує жорсткий верхня межа числа кластерів балансування навантаження основаних на CARP, встановлений в 32 віртуальних ідентифікаторів хостів

Параметр advskew грає аналогічну роль при балансуванні навантаження, проте синтаксис ifconfig (і відповідно hostnamecarp №) дещо відрізняється від режиму відмовостійкості Зміна групи відмовостійкості CARP створеної нами в попередніх розділах до кластеру балансування навантаження полягає в редагуванні конфігураційних файлів і перезавантаження У цьому прикладі ми підемо за схемою IP балансування Якщо ви обираєте відмінну схему, конфігурації будуть відрізнятися лише ключовим словом вибору режиму

На першому хості ми змінимо файл / etc/hostnamecarp0 наступним чином:

pass mekmitasdigoat 1920219 balancing ip carpnodes 5:100,6:0

Це означає, що на даному хості, інтерфейс carp0 є членом групи з vhid 5, де advskew = 100, а так само vhid 6, де він є головним кандидатом на отримання masterа, з avdskew = 0

Тепер змінимо / etc/hostnamecarp1:

pass mekmitasdigoat 192168121 balancing ip carpnodes 3:100,4:0

Для carp1, учасника vhid 3 і 4, значення advskew 100 і 0 відповідно

Для іншого хоста значення advskew відповідно міняються місцями, а конфігурації схожі Тут / etc/hostnamecarp0 виглядає так:

pass mekmitasdigoat 1920219 balancing ip carpnodes 5:0,6:100

Відповідно, він є учасником vhid 5 з advskew = 0 і учасником vhid 6 з advskew = 100 Файл / etc/hostnamecarp1 виглядає наступним чином:

pass mekmitasdigoat 192168121 balancing ip carpnodes 3:0,4:100

І знову, carp1 є учасником vhid3 і 4, з advskew 0 і 100 відповідно

Висновок ifconfig для групи інтерфейсів CARP на першому хості виглядає так:

$ ifconfig carp

carp0: flags=8843&ltUP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt mtu 1500 lladdr 01:00:5e:00:01:05

priority: 0

carp: carpdev vr0 advbase 1 balancing ip state MASTER vhid 5 advskew 0

state BACKUP vhid 6 advskew 100 groups: carp

inet 1920219 netmask 0xffffff00 broadcast 19202255

inet6 fe80::200:24ff:fecb:1c10%carp0 prefixlen 64 scopeid 0x7

carp1: flags=8843&ltUP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt mtu 1500 lladdr 01:00:5e:00:01:03

priority: 0

carp: carpdev vr1 advbase 1 balancing ip state MASTER vhid 3 advskew 0

state BACKUP vhid 4 advskew 100 groups: carp

inet 192168121 netmask 0xffffff00 broadcast 19216812255 inet6 fe80::200:24ff:fecb:1c10%carp1 prefixlen 64 scopeid 0x8 pfsync0: flags=41&ltUP,RUNNING&gt mtu 1500

priority: 0

pfsync: syncdev: vr2 syncpeer: 1001217 maxupd: 128 defer: off groups: carp pfsync

А на другому хості так:

$ ifconfig carp

carp0: flags=8843&ltUP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt mtu 1500 lladdr 01:00:5e:00:01:05

priority: 0

carp: carpdev vr0 advbase 1 balancing ip state BACKUP vhid 5 advskew 100

state MASTER vhid 6 advskew 0 groups: carp

inet 1920219 netmask 0xffffff00 broadcast 19202255

inet6 fe80::200:24ff:fecb:1c18%carp0 prefixlen 64 scopeid 0x7

carp1: flags=8843&ltUP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt mtu 1500 lladdr 01:00:5e:00:01:03

priority: 0

carp: carpdev vr1 advbase 1 balancing ip state BACKUP vhid 3 advskew 100

state MASTER vhid 4 advskew 0 groups: carp

inet 192168121 netmask 0xffffff00 broadcast 19216812255 inet6 fe80::200:24ff:fecb:1c18%carp1 prefixlen 64 scopeid 0x8 pfsync0: flags=41&ltUP,RUNNING&gt mtu 1500

priority: 0

pfsync: syncdev: vr2 syncpeer: 1001216 maxupd: 128 defer: off groups: carp pfsync

Якби ми мали три вузли в нашій схемі балансування навантаження, кожен інтерфейс CARP повинен бути членом додаткових груп, в цілому трьох Коротше кажучи, для кожної фізичної вузла ви вводите групу балансування навантаження, і кожен інтерфейс CARP стає членом додаткової групи

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

Джерело: Книга про 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>

*

*