Компания Интернет Контроль Сервер временно не ведёт блог на Хабре Оригинал: https://klarasystems.com/articles/exploring-swap-on-freebsd/  Свободная память = память, потраченная впустую? Как использовать swap наилучшим образом. Для современных Unix-систем, таких как FreeBSD, термин “swapping” (подкачка памяти) означает операции по выгрузке данных из памяти на диск (устройство подкачки) и обратно, осуществляемые по требованию.  Процесс вывода происходит в ответ на отсутствие свободной памяти в системе: ядро пытается вычислить страницы памяти, к которым возможно не будет производиться доступ в ближайшем будущем, и копирует их данные на диск, чтобы сохранить до востребования.  Процесс выгрузки данных запускается при нехватке свободной памяти в системе: ядро системы вычисляет страницы памяти, которые скорее всего не будут нужны в ближайшем будущем, и  копирует их содержимое на диск, на котором данные хранятся до востребования. Если приложение пытается получить доступ к данным, выгруженным на устройство подкачки, этот процесс блокируется до тех пор, пока ядро системы не извлечет необходимые данные с диска. После этого, работа приложения возобновляется в обычном режиме. Описанная технология выглядит весьма рациональной. Объем памяти дисков обычно больше объема RAM, так почему бы не использовать их для кэширования редко используемых страниц памяти? Однако, для многих опытных администраторов процесс подкачки памяти до сих пор воспринимается как некорректное поведение системы. И этому есть объяснение: до недавнего времени диски, используемые для подкачки памяти, имели задержки доступа в миллионы раз выше, чем у RAM. Привет всем, кому интересна ОС FreeBSD! После летне-отпускного отсутствия начинаю новый цикл статей. Надеюсь, будет занимательно и полезно. Для тех, кто тут впервые, поясню, что являюсь разработчиком российского Интернет-шлюза Интернет Контроль Сервер, реализованного на базе FreeBSD. А потому, изнанка этой операционки, ее фишки и тонкости администрирования - то, с чем я сталкиваюсь ежедневно и делюсь с вами. В предыдущей серии статей мы рассмотрели файрвол PF. Оценили возможности и настроили его для разных ролей. В новом цикле сделаем то же для файрвола IPFW. Как и с PF, начнем с краткого обзора и создания простой конфигурации для защиты веб сервера. В следующий статьях будем погружаться и усложнять конфигурацию постепенно, вводя новые типы правил и добавляя "мяса". В прошлых статьях мы разобрали PF, его основные возможности, и попробовали применить этот файрвол в различных ситуациях. Однако, простого знания, какие правила и в какой последовательности надо поставить в конфигурации, для достижения цели не всегда достаточно. Многое становится понятно только если взглянуть чуть глубже: на уровень ядра ОС, и того, как файрволы с ним взаимодействуют. Мы не будем разбирать уровни драйвера сетевой карты (2 уровень модели OSI), а сразу поднимемся на 3 уровень, где работает tcp/ip стек ядра. В предыдущих статьях мы разобрали базовые элементы конфигурации PF. Создали конфигурации, способные защитить сервер в Интернет и простейший офис.  В этой статье разберем возможности PF и FreeBSD в части продвинутой маршрутизации. Policy Based Routing (PBR), Source Based Routing (SBR), условная маршрутизация, маршрутизация на основе политик, все эти понятия, по сути, равнозначны и описывают одну возможность. Выбирать маршруты, либо таблицы маршрутизации для трафика на основе правил фаервола.  Можно, к примеру, отправить разные локальные сети через разных провайдеров, либо устроить распределение трафика между ВПН каналами. Рассмотрим оба эти варианта. Для уменьшения файлов конфигурации и большей наглядности, в этой статье правила фильтрации будут максимально упрощены. В прошлых статьях мы разобрали, что такое PF вообще, общие принципы построения правил. Узнали о таблицах и способах фильтрации трафика PF. И создали конфигурационные файлы, которые способны защитить сервер в Интернет. В этой статье попробуем разобраться с NAT трансляциями и тэгами (tags). Еще пройдемся по якорям (anchors), их иногда называют еще закладками.  Думаю, объяснять, что такое NAT трансляции в общем случае не стоит. PF поддерживает три вида трансляций. Anchors — это отдельные наборы правил PF, которыми, подобно таблицам, можно управлять динамически. Tag — это способ пометить пакет, чтобы потом обработать в другом правиле. Удобно, например, метить пакеты, проходящие через проброс, чтобы потом их разрешить скопом в одном правиле. В прошлой статье мы разобрали, что такое вообще PF, его основные возможности и создали простенький конфиг, использующий правила фильтрации и макросы. Сегодня разберемся с метками и научимся более продвинуто фильтровать трафик по различным условиям. Спасибо пользователям, комментировавшим предыдущую статью, за проявленный интерес. В этот раз попробуем различные варианты более продвинутой фильтрации: