В сучасних умовах обмін даними між комп’ютерами став невід’ємною частиною життя. Мережні засоби застосовуються у всіх сферах діяльності. В навчальних закладах всіх рівнів, починаючи від початкових і закінчуючи спеціальними, комп’ютерні мережі дозволяють студентам і викладачам отримати миттєвий доступ до інформації в бібліотеках всього світу. На даний час зростає потреба у використанні інформаційних технологій в управлінні навчальним процесом у всіх навчальних закладах.
З розширенням комп’ютерних систем і їх взаємодії з різними за структурою мережами спостерігається щораз більша залежність як організацій, так і окремих людей від інформації, що передається по мережі, і зберігається в таких системах. Це, у свою чергу, дозволяє зрозуміти необхідність захисту даних і ресурсів від можливого несанкціонованого доступу, важливість використання спеціальних засобів для забезпечення достовірності отриманих даних та повідомлень, а також захисту систем від мережних атак.
Із появою та поширенням комп’ютерів і засобів автоматизованої обробки інформації виникла потреба в автоматизованих засобах захисту файлів та іншої інформації, що зберігається на комп’ютерах. Особливо гостро потреба в засобах захисту відчувається в багатокористувацьких системах, таких як системи, до яких можна отримати доступ по звичайних телефонних лініях зв’язку або відкритих комп’ютерних мережах.
Для встановлення з’єднання з окремою мережею чи Internet за допомогою модему, чи для відкриття доступу до власного комп’ютера необхідно використовувати протокол РРР.
PPP (Point to Point Protocol) – протокол двоточкового зв'язку, як правило, використовується для підключення до Інтернет за допомогою модему.
В FreeBSD РРР можна налаштовувати на рівні ядра – демон pppd, що використовує вбудований в ядро системи код PPP-протоколу, або на рівні користувача – ррр, що запускається, як програма користувача і самостійно реалізовує PPP-протокол.
Так як РРР при роботі використовує тунельний пристрій, що знижує швидкість роботи, то використаємо Kernel РРР, який використовує демон pppd.
У всіх доступних джерелах описано з’єднання на основі протоколу РРР з використанням додзвону та наступною аутентифікацією, а здійснення з’єднання без додзвону та без наступної аутентифікації не описано.
Файли конфігурації РРР знаходяться в директорії /etc/ppp. Створимо свій власний конфігураційний файл up-d0.conf:

# вказуємо порт, до якого підключений модем і його швидкість
/dev/ttyd0 115200
# вмикаємо апаратний контроль за прийомом або передачею даних
Crtscts
# налаштовуємо демон pppd таким чином, щоб він перевіряв наявність
# сигналу CD (Carrier Detect) від модему, після чого відбувається
# відкриття порту
modem
# вимикаємо РАР аутентифікацію
-pap
# вимикаємо СНАР аутентифікацію
-chap
# встановлюємо максимальну одиницю передачі даних
mtu 1500
# встановлюємо максимальну одиницю прийому даних
mru 1500
# вмикаємо динамічне призначення ІР-адреси нашому шлюзу
noipdefault
# задаємо DNS для користувачів Windows-систем
ms-dns 195.5.29.11
# включаємо маршрут РРР, як маршрут за замовчуванням
defaultroute

Так як при розриві зв’язку з провайдером демон рррd зупинявся, то його потрібно було щоразу перезапускати. Саме тому, щоб автоматизувати процес встановлення чи відновлення РРР-з’єднання з провайдером потрібно створити файл up-d0.sh наступного вмісту:

#!/bin/sh
while true
do
/usr/sbin/pppd -detach ttyd0 115200 file /etc/ppp/up-d0.conf
sleep 3
done

Файл up-d0.sh потрібно зробити виконуваним за допомогою команди:

# chmod + x up-d0.sh

і розмістити його в каталозі /usr/local/etc/rc.d, який за замовчуванням є автозавантажуваним, тобто з нього завантажуються виконувані файли при старті системи.
Якщо з’єднання з DNS-сервером відбулося, то в таблицю маршрутизації повинен додатися новий маршрут.
Firewall – це захисна стіна, що стоїть між мережним адаптером і операційною системою. Будь-який IP-пакет, перш ніж потрапити на обробку операційної системи (наприклад, для маршрутизації або передачі його web-серверу) проходить через строгий контроль. Будь-який витікаючий пакет також натрапляє на цю стіну, і може бути пропущений, відкинутий злічений або змінений. Якщо пакет проходить через операційну систему наскрізь (маршрутизується), то його перевірка відбувається як на вході так і на виході. При складній обробці пакету він може проходити через firewall і більше число разів.
Перевірка пакету проводиться за впорядкованим списком правил, які задаються адміністратором. Кожному правилу привласнюється номер (або вручну адміністратором, або автоматично), і правила перевіряються строго в порядку зростання номерів. Декілька правил можуть мати один і той же номер – в цьому випадку вони перевіряються в тому порядку, в якому вони були занесені в список. Кожне правило містить умову і дію.
Firewall дозволяє не тільки вирішувати або забороняти проходження IP-пакетів, але і обмежувати швидкість їх проходження. Для цього використовується вбудована в ядро FreeBSD система dummynet – емулятор “поганої” лінії зв'язку з такими характеристиками, як абсолютна затримка проходження пакету, обмеження швидкості проходження даних по лінії, втрата деякого числа пакетів. Для підтримки своєї роботи система dummynet вимагає обов’язкової перебудови ядра операційної системи з наступними опціями:
• options DUMMYNET;
• options IPFIREWALL.
Dummynet складається з каналів (pipe) і черг (queue). Канал характеризується прoпускною спроможністю (біти за секунду), затримкою проходження пакету (у секундах), розміром черги (скільки даних може одночасно “знаходиться” в каналі), відсотком втрат.
Всі налаштування каналів та черг слід включити у конфігураційний файл firewall.
При попаданні в канал пакет “стає в кінець” черги, як в магазині. Dummynet певну кількість разів в секунду (задається параметром HZ при збірці ядра операційної системи) перевіряє наявність пакетів в черзі, і, якщо не перевищений ліміт швидкості виходу даних з каналу, випускає пакет. Підраховується саме швидкість сходу пакетів з каналу – тому якщо пакети надходять до черги з більшою швидкістю, ніж дозволена для даного каналу швидкість виходу з черги, то пакети, що не “помістилися” в чергу, просто втрачаються.
Для користувача, якщо він працює по протоколу TCP, втрати пакетів не помітні – сервер перестає надсилати пакети, якщо клієнт не надсилає підтвердження прийому. Проте, очікування підтвердження на кожен пакет знижує продуктивність – канал зв'язку може забезпечувати велику пропускну спроможність при чималому часі проходження пакету, і якщо чекати відповіді на кожен пакет, то канал буде простоювати. Тому в протоколі TCP використовується метод вікна – надсилаються відразу декілька пакетів підряд без очікування підтвердження і посилка пакетів припиняється тільки в тому випадку, якщо підтвердження не прийшло ще на поза-поза-минулий пакет.
Щоб робота по протоколу TCP через канал dummynet відбувалася без необхідності повторної пересилки пакету, необхідно щоб всі пакети “вікна” могли вміститися в черги. Черги стандартного розміру (50 пакетів) вистачає для одночасної роботи приблизно 10 TCP-з'єднань (це число дуже сильно залежить від настройок протоколу TCP на машинах клієнтів і на серверах, а також від середнього розміру пакету, що генерується програмами). При перевищенні цього числа пакети почнуть втрачатися, тому їх потрібно буде надіслати повторно. Якщо Ви платите за трафік, то ця особливість може боляче вдарити Вас по кишені, так як Ваш провайдер порахує всі передані Вашій системі пакети, у тому числі і втрачені в dummynet, тому, якщо Ви пропускаєте через один канал dummynet велику кількість з'єднань, то пропорційно збільшуйте і розмір черги. Причому підрахунок пікової кількості одночасних з’єднань зовсім не такий простий – користувачі із обмеженою пропускною спроможністю каналу мають звичку відкривати набагато більше одночасних з'єднань, ніж власники високошвидкісних каналів. Крім того, користувачі менеджерів завантаження швидко виявлять, що завантаження файлу в декілька потоків відбувається швидше, ніж в один, тому що адресовані ними пакети, кількість яких більша, будуть “витісняти” з черги чужі з'єднання, та й тривалість одного з'єднання також зросте.
Вирішенням цих проблем може бути як обмеження числа з’єднань через pipe, так і грамотне налаштування всієї системи обмеження, зокрема з використанням пріоритетів трафіку: кожен канал може мати і більше однієї черги пакетів, при цьому пакети з черг “виходять” відповідно до пріоритетів заданими чергам.
Якщо потрібно встановити однакові обмеження для великої кількості користувачів, то не слід вводити сотні правил, що відрізняються лише адресою, бо це не є ефективним вирішення даної задачі. Для спрощення таких завдань FreeBSD пропонує додатковий параметр mask, що дозволяє згрупувати клієнтів на основі їх IP-адрес. Якщо маска вказана в параметрах каналу, то для кожної групи адрес буде створений окремий канал з тими ж налаштуваннями пропускної спроможності, що і базовий (з маскою 0x00000001) сумарна пропускна спроможність для користувачів буде рівною 128 кілобіт. Якщо маска вказана в параметрах черги, то для кожної групи адрес буде створена черга з тим самим пріоритетом, що і базова черга, але всі ці черги потраплять в один і той самий канал, тобто сумарна пропускна спроможність каналу не зміниться.
Якщо обмеження пропускної спроможності для кожного конкретного користувача не самоціль, а тільки засіб “справедливо” розділити між ними наявний канал, то коректнішою буде робота з одним каналом і декількома чергами (можливо, з різним пріоритетом). При цьому слід розмежувати вхідні та вихідні адреси, щоб не створювалось безліч черг, в яких трафік поділяється по Інтернет адресам, протоколам та місцевим адресам. Саме з цієї причини бажано створити дві черги: одну для вхідних адрес, другу – для вихідних, наприклад:

# створюємо канал:
${fwcmd} pipe 1 config bw 1000Kbit/s
# cтворюємо дві черги для вхідного та вихідного трафіку відповідно:
${fwcmd} queue 1 config pipe 1 weight 50 queue 20 mask dst-ip 0xffffffff
${fwcmd} queue 11 config pipe 1 weight 50 queue 20 mask src-ip 0xffffffff
# запускаємо в ці черги трафік:
${fwcmd} add queue 1 ip from any to 192.168.0.0/24
${fwcmd} add queue 11 ip from 192.168.0.0/24 to any

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

# простим користувачам
${fwcmd} queue 1 config pipe 1 weight 50 queue 20 mask dst-ip 0xffffffff
${fwcmd} queue 11 config pipe 1 weight 50 queue 20 mask src-ip 0xffffffff
# привілейованим користувачам
${fwcmd} queue 3 config pipe 1 weight 80 queue 20 mask dst-ip 0xffffffff
${fwcmd} queue 33 config pipe 1 weight 80 queue 20 mask src-ip 0xffffffff
# привілейованим користувачам
${fwcmd} add queue 3 ip from any to 192.168.10.50
${fwcmd} add queue 33 ip from 192.168.10.50 to any
# простим користувачам
${fwcmd} add queue 1 ip from any to 192.168.0.0/24
${fwcmd} add queue 11 ip from 192.168.0.0/24 to any

Це непоганий інструмент для VIP-обслуговування деяких абонентів мережі без “глобального” утиску прав рядових користувачів: якщо нікому з VIP-групи в даний момент канал не потрібний, то звичайні користувачі ділять між собою пропускну здатність порівну, але якщо VIP-клієнту (хост з адресою 192.168.10.50) знадобилися послуги – прості користувачі автоматично посуваються.