PfSense многое и не по порядку Печать
30.12.10 09:26
Снова * * *
22.2 Статус системы

Основная страница системы pfSense -это страница Статус системы (Status >> System, показанная на рисунке 22.2, "Статус Системы"). Она содержит некоторую информацию о базовой системе, например имя маршрутизатора, версию pfSense, платформа (Раздел 1.6, "Платформы"), время работы, размер таблицы состояния (Раздел 4.5.9.6, "Firewall Maximum States"), использование MBUF, использование CPU, использование памяти, использование своп пространства и использование диска. Счётчики на странице обновляются автоматически, каждые несколько секунд, потому нет необходимости в обновлении страницы.


Рисунок 22-2

22.3 Статус интерфейсов


Статус сетевых интерефйсов можно наблюдать на странице Status >> Interfaces. ...

продолжение следует...

Метки: pfsense, нЭмного пА РусскЕ

 

Догонялки...
Из-за отсутствия домашнего интернета (очередная финансовая пропасть в которую можно падать вечно) все дела застопорились. Сегодня выкладываю небольшой перевод в продолжение 22 главы pfSense TheDefinitiveGuide.

***

22.1.3 Удалённое журналирование с использованием Syslog

Прочие опции меню Status >> Systems Logs на закладке Settings необходимы для настройки демона syslog, позволяющего копировать записи журналов на удалённый сервер. Поскольку журналы хранимые pfSense на самом маршрутизаторе имеют конечный ( и достаточно малый) размер, их копирование на syslog-сервер обеспечивает, как возможность поиска и устранения неисправностей, так и возможность длительного хранения записей в случае необходимости. Журналы марщрутизатора очищаются при перезагрузке, а наличие удалённой копии журналов позволяет диагностировать события происходящие непосредственно перед перезагрузкой. Некоторые корпоративный и законодательные политики определяют, сколько времени должны храниться файлы журналов брандмауэров или аналогичных устройств. Если ваша организация требует долгосрочного хранения журналов, вам придётся заняться конфигурирование syslog-сервера.
Для запуска удалённого журналирования, установите Enable sysloging для удалённого syslog-сервера и заполните IP адрес для вашего syslog-сервера Remote Syslog Server. Если вы хотите отключить локальное журналирование, вы можете отметить Disable writing log files to the local ram disk, но обычно этого делать не рекомендуется.
Обычно, syslog-сервер, это сервер напрямую связанный с локальным интерфейсом системы pfSense. Журналирование может осуществляться на сервер через VPN, но для этого могут потребоваться некоторые дополнительные настройки (смотрите раздел 13.4.4 "Трафик инициируемый pfSense и IPsec"). Вы не должны передавать данные syslog непосредственно через WAN интерфейс, поскольку эти данные являются простым текстом и могут содержать значимую информацию.
Установите флаги для типов записей, которые вы хотите копировать на syslog-сервер. Вы можете выбрать удалённую регистрацию системных событий, событий брандмауэра, событий службы DHCP, аутентификации, события VPN либо все виды событий сразу.
Убедитесь, что нажали кнопку Save после изменения настроек.
Если у вас нет syslog-сервера, его достаточно просто установить. Смотрите раздел 24.3 "Syslog-сервер для Windows с использованием Kiwi Syslog". Практически любой UNIX или его клон могут использоваться в качестве syslog-сервера. FreeBSD syslog-сервер описан в следующем разделе, для иных систем настройки могут несколько отличаться.

22.1.3.1 Конфигурирование syslog-сервера на базе FreeBSD

Установка syslog-сервера на основе FreeBSD потребует буквально пары шагов. В следующих примерах, замените192.168.1.1 на IP адрес вашего брандмауэра, замените exco-rtr именем хоста брандмауэра и замените exco-rtr.example.com полным именем хоста и доменом вашего брандмауэра. Я использовал в данных примерах 192.168.1.1, поскольку рекомендуется работать с внутренним адресом вашего маршрутизатора, а не интерфейм WAN.
Во-первых, вам понадобится запись в /etc/hosts, содержащая адрес и имя вашего брандмауэра, например:

192.168.1.1 exco-rtr exco-rtr.example.com

Затем, вам необходимо настроить флаги запуска syslogd, чтобы принимать сообщения syslog от брандмауэра. Отредактируйте /etc/rc.conf и добавьте следующую строку:

syslogd_flags ="-a 192.168.1.1"

И, наконец, вам необходимо добавить некоторые строки в /etc/syslog.conf которые будут описывать захват записей для нашего узла. В конец файла необходимо добавить:

! *
+*
+exco-rtr
*.* /var/log/exco-rtr.log

Эти строки сбрасывают программу и фильтры хостов, а затем установят фильтр хоста для вашего брандмауэра (используя его краткое наименование как описано в /etc/hosts). Если вы знакомы с syslog, вы можете рассмотреть /etc/syslog.conf на маршрутизаторе pfSense.
После внесения изменений необходимо перезапустить syslogd. На FreeBSD это действие выполняется одной командой:

# /etc/rc.d/syslogd restart

Теперь вы можете наблюдать log-файл на syslog сервере и видеть, что он заполняется записями действий производимых брандмауэром.

Продолжение следует...
Метки: pfsense, нЭмного пА РусскЕ
pfSense 1.2.3 Глава 22 Начало
п.п. Не удалось перейти к первой главе - приходится выполнять актуальный перевод. Потому перехожу к главе 22.

Глава 22 Системный мониторинг
Столь же важной частью, как и предоставление основных сервисов, является информация и данные о текущих процессах и состоянии системы, которые предоставляет pfSense. Иногда кажется, что коммерческие маршрутизаторы стараются максимально скрывать от пользователей значительную часть информации, но pfSense позволяет предоставить пользователю практически любой объём информации.

22.1 Системные журналы
По умолчанию, pfSense регистрирует довольно малый объём данных, который позволяет избежать переполнения хранилища маршрутизатора. Журналы можно обнаружить на вкладке Status >> System Logs в web интерфейсе, и в каталоге /var/log файловой системы. Некоторые компоненты, такие как DHCP и IPsec генерируют достаточно объёмную информацию, поэтому вынесены на отдельные вкладки, в целях улучшения читаемости журналов и поиска требуемой информации. Чтобы увидеть эти журналы, выберите вкладку соответствующей подсистемы.

Журналы pfSense ведутся в циркулярном бинарном логе или в clog-формате. Они имеют фиксированные размеры и никогда не разрастаются. Как следствие - журнал содержит только определённое количество записей, и устаревшие записи удаляются из журнала с приходом новых. Если для вас это проблема - можно скорректировать поведение журнала, позволив копировать записи на удалённый syslog-сервер, где они могут храниться постоянно и ротироваться с меньшей скоростью. Смотрите раздел 22.1.3 "Удалённое журналирование с syslog" более подробно рассматривающий настройки данной возможности.

22.1.1 Просмотр системных журналов
Системные журналы могут быть найдены на вкладке Status >> System Log, меню System. Они содержат записи журнала, непосредственно сгенерированные узлом, некоторыми службами и пакетами, которые не перенаправляются на другие вкладки системного журнала. Как показано на рисунке 22.1 "Пример записей системного журнала" здесь есть записи демона SSH, пакета avahi и клиента динамического DNS. Здесь же региструются и множество других систем, но большинство сервисов не будет загружать системный журнал. Обычно, если служба ведёт объёмный журнал, она перемещает его на собственную вкладку.

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

Рисунок 22.1

22.1.2 Изменение настроек журналов
Настройки журналов могут изменяться в меню Status >> System Logs на вкладке Settings. Здесь вы обнаружите несколько опций определяющих, как журналы будут отображаться на экране. Первая опция <Показать записи журналов в обратном порядке> (Show log entries in reverse order), управляет порядком, в котором записи журнала выводятся на экран. Установка этой опции приводит к тому, что новые записи журнала выводятся ввеху. При отключении этой опции новые записи будут выводится в низ журнала. Многие пользователи считают что оба метода вывода информации полезны в различных ситуациях.

Следующая опция <Число отображаемых записей журнала> (Number of log entires to show), позволяет задать число выводимых записей журнала на каждой из вкладок. Фактически, журналы могут содержать больший объём данных и данная опция позволяет ограничить или расширить визуальную информативность журнала.

Обычно, каждый пакет блокированный правилом по умолчанию брандмауэра подлежит регистрации в журнале. Если вы не хотите видеть эти записи, снимите флаг <Вести журнал блокировки пакетов правилом по умолчанию> (Log packets bloked by rule).

Опция <Показывать журнал raw-фильтра> (Show raw filter logs) контролирует вывод закладки журнала <Брандмауэр> (Firewall). Когда она установлена, вывод журнала не будет интерпретироваться синтаксическим парсером, а будет осуществляться в необработаном (сыром) формате. Иногда, это позволяет легче идентифицировать неисправность, либо предоставит службе поддержки больший объём информации, чем предоставляет стандартный вывод брандмауэра. Сырые журналы более сложно читать и интерпретировать и в большинстве случаев опция остаётся неиспользованной.

После изменения настроек нажмите Save. Оставшиеся опции мы обсудим в следующем разделе.

продолжение скорее всего вечером...
Метки: pfsense, НЭмного пА РусскЕ
pfSense 1.2.3 Глава 14 - Окончание

14.8 Перенаправление PPTP
Перенаправление PPTP позволяет передавать трафик PPTP предназначенный вашему WAN IP адресу на внутренний PPTP сервер. Чтобы задействовать эту функцию, выберите <Перенаправление входящего PPTP соединения> (Redirect incoming PPTP connections) и введите IP адрес вашего внутреннего сервера в строку ввода . Функционально, это действие эквивалентно добавлению записи перенаправления порта 1723 и GRE протокола к вашему внутреннему PPTP серверу, который вы предпочитаете использовать. Существование данного функционала - историческое наследие m0n0wall, в котором базовый IP фильтр не поддерживал передачу протокола GRE. Возможность была сохранена, поскольку многие пользователи привыкли пользоваться этой функцией и многие предпочитают использование одной записи вместо двух прямых прописываний портов. Правила брандмауэра для протокола GRE и порта 1723 добавляются автоматически для WAN. Вам нет необходимости вводить правила брандмауэра при использовании перенаправления PPTP, если у вас не отключено опция <Отключать все авто добавления правил VPN> (Disable all auto-added VPN rules) в меню System >> Advanced.

14.9 Проблемы PPTP.
Этот раздел рассматривает диагностику проблемных ситуаций возникающих при использовании PPTP.

14.9.1 Невозможно установить соединение
Для начала убедитесь, что клиентский компьютер соединён с интернетом. Если это верно, обратите внимание на ошибки, которые выдаёт клиент. Windows (кроме Vista) информирует кодом ошибки, который поможет локализовать проблемы. Windows Vista такой информации не предоставляет, и следовательно, затрудняет диагностику отказов соединения, но к счастью, эта проблема решена в Windows 7. Проводить поиск и устранение неисправностей в Vista не рекомендуется. Для тех кто использует не Windows клиенты диагности проблем примерно такая же, но со своими подходами.

14.9.1.1 Error 619
Ошибка 619 сообщает о том, что происходит повреждение GRE трафика. Практически всегда это результат работы брандмауэра за которым находится клиент. Если клиент находится так же за pfSense, убедитесь, что ни один из сценариев описанных в разделе 14.4 "Ограничения PPTP" не имеет место. Если брандмауэр, за котором находится клиент представляет собой какой-то другой продук или оборудование, возможно требуется специальная настройка. В некоторых случаях, например при использовании беспроводных провайдеров 3G, клиентам присваиваиваются частные IP адреса, и вам придётся выбрать другую форму VPN.

14.9.1.2 Error 691
Данная ошибка вызывается недопустимым именем пользователя или паролем. Это означает, что пользователь ввёл некорректное имя или пароль для клиента PPTP. Исправьте имя и/или пароль в соответствии с конфигурацией пользователя в базе данных PPTP или на RADIUS сервере.

14.9.1.3 Error 649
Проходя аутентификацию на RADIUS сервере Microsoft Windows с использованием IAS можно встретить ошибку 649. Она означает, что учётная запись не имеет разрешения набора и вероятной причиной этого может быть:
1. Установка "Deny access" на разрешение набора - в свойствах пользовательского аккаунта Active Directory Users and Computers на владке Набор (Dial-in). В зависимости от требуемой конфигурации IAS вы можете установить разрешение доступа (Allow access) или предоставить доступ через политику удалённого доступа (Control access through remote access policy).
2. Истёк срок действия пароля пользователя - соответственно пользователь не может использовать PPTP.
3. Неправильная конфигурация IAS - возможно вы неверно сконфигурировали правила политик и пользователи не могут соединится.

14.9.2 Соединение PPTP не передаёт трафик
Убедитесь, что вы добавили правила брандмауэра для интерфейса VPN PPTP как было описано в разделе 14.5.5 "Конфигурирование правил брандмауэра для клиентов PPTP". Так же, следует убедится, что удалённая подсеть работающая через VPN отличается от лакальной подсети. Если вы пытаетесь соединиться с сетью 192.168.1.0/24 через VPN, а локальная подсеть клиента имеет адресацию 192.168.1.0/24, трафик предназначенный для удалённой сети никогда не будет пересекать VPN, поскольку находится в окальной сети. Именно поэтуму следует выбирать заведомо несвязанную подсеть при использовании VPN, о чём уже говорилось в разделе 4.2.4 "Конфигурация LAN интерфейса".

14.10 Хитрости марсшрутизации PPTP
Если вы хотите, чтобы выбранные подсети маршрутизировались через туннель PPTP, это можно сделать путём маршрутизации на клиенте. Следующие методы работают на Windows XP, Vista и Windows 7, и возможно могут работать на любой другой платформе. Предполагается, что уже сконфигурировали клиентскую часть не передавать весь трафик через соединение ( т.е. не использовать удалённый шлюз).

Во-первых, клиенту PPTP должен быть присвоен статический адрес в профиле пользователя. Это можно сделать используя встроенную аутентификацию, или посредством RADIUS. Статический адрес должен находится за пределами общего пула адресов. Данный способ должен направить трафик предназначенный для удалённых подсетей к адресу присвоенному PPTP. Мы заставим трафик для этих подсетей двигаться по туннелю на другой стороне. Способ не ограничивается подсетями, которые сразу достижимы с другой стороны, поскольку могут использоваться любые подсети. Это весьма удобно, если вы хотите пткрыть доступ к стороннему сайту через тунель VPN. Команды могут быть введены в командной строке, но в нашем примере мы запишем их в командный файл:

@echo off
route add 192.168.210.0 mask 255.255.255.0 192.168.1.126
route add 10.99.99.0 mask 255.255.255.0 192.168.1.126
route add 172.16.1.0 mask 255.255.252.0 192.168.1.126
pause

В этом примере, 192.168.1.126 - статический IP, присвоенный пользователю клиента PPTP. Команды направляют три указанных подсети через PPTP соединение, дополнительно к подсети соединённой непосредственно. Пауза опциональна, но она может помочь убедится, что все маршруты добавлены успешно. Пакетный файл должен выполняться каждый раз при установлении соединения.

NOTE
На Windows VIsta и WIndows 7, эти команды должны выполняться с правами администратора. Если вы создали ярлык на данный пакетный файл, измените его свойства предоставив ему эти права. Аналогично щёлкнув правой кнопкой на файле вы можете выбрать опцию <Выполнить в роли администратора>.

14.11 Логи PPTP
Запись событий авторизации и выхода пользователей хранятся в Status >> System Logs, закладка PPTP.

Рисунок 14.35

Как вы можете видеть на рисунке 14.35 "Журнал PPTP", каждый вход и выход пользователя записываются с указанием метки времени, имени пользователя и IP адресом присвоенным клиенту PPTP.

Продолжение следует ... вечерком
Метки: pfsense, НЭмного пА РусскЕ
pfSense 1.2.3 Глава 14 - продолжение

14.5.2 Аутентификация
Можно производить аутентификацию пользователей по локальной базе пользователей, или посредством RADIUS-сервера. RADIUS позволяет соеденяться с другим сервером в вашей сети, для целей аутентификации. Такая возможность может использоваться для аутентификации пользователей PPTP с помощью Microsoft Active Directory (см. раздел 24.1 "Аутентификация RADIUS с Windows Server"), или другими RADIUS совместимыми серверами. Для использования RADIUS, установите флаг <Использовать сервер RADIUS> (Use a RADIUS server) и заполните поля во вкладках и . Для аутентификации с использованием локальной базы данных пользователей, снимите данный флаг. Если вы используете RADIUS вам не нужно вам не нужно добавлять пользователей на вкладке Users VPN >> PPTP. Смотрите раздел 14.5.6, "Добавление пользователей" более подробно рассматривающий встроенную систему аутентификации.

14.5.3 Необходимость 128 битного шифрования.
Используйте 128 битное шифрование везде где это возможно. Большинство клиентов PPTP поддерживают 128 битное шифрование, таким образом, оно прекрасно работает в большинстве сетевых сред. PPTP достаточно слабо защищён даже при использовании 128 битного шифрования и тем более при 40 и 56 битном. Если специальных требований нет, недопустимо использовать шифрование ниже чем 128 бит для PPTP.

14.5.4 Сохранение изменений для запуска PPTP сервера
После заполнения вышеописанных настроек, нажмите Save. При этом ваша конфигурация будет сохранена и PPTP сервер запустится. Если вы аутентифицируете своих пользователей по локальной базе, перейдите на вкладку Users и введите данные своих пользователей.

14.5.5 Конфигурирование правил брандмауэра для клиентов PPTP
Открываем Firewall >> Rules и выбираем закладку PPTP VPN. Эти правила управляют трафиком клиентов PPTP. Пока вы не добавите правила брандмауэра, весь трафик инициируемый клиентами PPTP будет блокироваться. Трафиком исходящим от внутреннего LAN до клиентов PPTP управляют правила брандмауэра LAN. Для начала можно добавить правило разрешающие весь трафик, как показано на рисунке 14.2, "Правила брандмауэра VPN PPTP", но после тестирования работы следует ввести более жёсткие ограничения на данные правила.

Рисунок 14.2

14.5.6 Добавление пользователей
Добавление пользователей для сервера RADIUS может меняться от версии к версии. Эта процедура выходит за рамки контекста этого раздела, и рассматривается в документации на RADIUS сервер.
Добавление пользователей во встроенную базу pfSense производится достаточно просто. Во-первых, выберите VPN >> PPTP и перейдите на вкладку Users. Вы увидите пустую таблицу пользователей показанную на рисунке 14.3, "Вкладка Пользователи PPTP". Нажмите кнопку для добавления пользователя.

Рисунок 14.3

После нажатия иконки [+] появится страница редактирования пользователя. Заполните имя и пароль пользователя как показано на рисунке 14.4 "Добавление пользователя PPTP". При желании можно ввести статический IP присваиваемый пользователю.

Рисунок 14.4

Нажмите Save и вы вернётесь на страницу списка пользователей (рисунок 14.5 "Применение параметров PPTP"), и нажмите кнопку Apply Changes для применения изменений.

Рисунок 14.5

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

Рисунок 14.6

Если вам необходимо отредактировать данные пользователя нажмите иконку [e]. Пользователь может быть удалён нажатием иконки [x].

14.6 Конфигурирование PPTP клиента

Теперь, когда ваш PPTP сервер сконфигурирован, вам необходимо настроить клиент PPTP. В следующих разделах рассказывается как конфигурировать клиентов Windows XP, Windows Vista и Mac OS X для соединения с сервером PPTP.

14.6.1 Windows XP

Откройте Панель управления и дважды щёлкните иконку Сетевые подключения (рисунок 14.7 "Сетевые подключения").

Рисунок 14.7

В панели задач выберите Создать новое соединение (рисунок 14.8 "Сетевые задачи"). На экране приветствия мастера соединений нажмите Далее.

Рисунок 14.8

Выберите <Соединиться с сетью на рабочем месте> как показано на рисунке 14.9 и нажмите Далее.

Рисунок 14.9

Выберите соединение Виртуальная Частная Сеть, как показано на рисунке 14.10, "Соединение с VPN" и нажмите Далее. Введите название соединения в поле Название компании, как показано на рисунке 14.11 "Имя соединения" и нажмите далее. Введите IP адрес WAN удалённого маршрутизатора pfSense в поле Имя хоста или IP адрес, как показано на рисунке 14.12 и нажмите Далее, затем нажмите Завершить (рисунок 14.13 "Завершение создания соединения").

Теперь, у вас есть коммутируемое соединение PPTP, работающее аналогично любому другому коммутируемому соединению. При попытке установления соединения будет запрошен логин и пароль как показано на рисунке 14.14 "Диалоговое окно соединения". Пока вам лучше дочитать данную главу, и только затем реально использовать соединение.

Существует ряд других нстроек, которые необходимо проверить и возможно скорректировать. Щёлкните правой кнопкой мыши на значке соединения PPTP и выберите пунк меню Свойства. (рисунок 14.15, "Свойства соединения".

Выберите вкладку Безопасность (рисунок 14.16 "Безопасность"). В выпадающем меню <При проверке использовать> выберите пункт <Безопасный пароль>. Так же убедитесь, установлен флаг <Требуется шифрование (иначе рассоединяться)>.
Теперь, перейдите на вкладку Сеть. Здесь вы можете видеть что тип VPN установлен в значение Автоматический. В действительности это означает, что Windows будет пробовать установить соединение по различным признакам. PPTP - последнее что попробует Windows и соответственно может возникнуть задержка до 30 секунд или более, связанная с определением различных опций соединения, поэтому лучше сразу выбрать тип VPN как PPTP. По умолчанию, весь трафик соединения будет передаваться используя в качестве шлюза PPTP соединение. Это может быть необходимо или ненужно в зависимости от вашей конфигурации. Как бы то ни было - поведение соединения конфигурируемо. Выберите протокол TCP/IP и нажмите кнопку Дополнительно. Снимите флаг <Использовать основной шлюз в удалённой сети> и закройте все окна нажав <ОК>. Если этот флаг снят, то только трафик направленный в подсеть соединения PPTP пересечёт туннель. Теперь PPTP соединение отправляет трафик предназначенный только для этой подсети через VPN. Если вам требуется выборочная пересылка трафика, обратитесь к разделу
14.10 "Приемы маршрутизации PPTP".

Следующие несколько подразделов пропущены по причине содержания близкого к предыдущему разделу. Возможно, для полноты картины я займусь ими позже. Авторам похоже тоже всё это не нравилось и они не стали рисовать много картинок
/*
14.6.2 Windows Vista
14.6.3 Windows 7
14.6.4 Mac OS X
*/


14.7.1 Увеличение предела одновременно работающих пользователей.

Возможно увеличение ограничения одновременно работающих пользователей выше жёстко установленного предела 16, через скрытые опции config.xml. Для увеличения предела, перейдите в Diagnostics >> Backup/Restore и нажмите Загрузить конфигурацию (Download Configuration). Откройте загруженный XML бэкап и в текстовом редакторе найдите строку <pptp>.

<pptp>
<n_pptp_units>16</n_pptp_units>
<pptp_subnet>28</pptp_subnet>

Как вы уже видели, по умолчанию, установлено 16 клиентов в подсети /28. Чтобы использовать больше клиентов, вам необходимо скорректировать число соединений и подсеть. В следующем примере используется 32 клиентских соединения и используется блок из 32 IP-адресов. Следует заметить, что по существу это не традиционная подсеть, а скорее средство определения диапазона в большей подсети. Из-за этого все IP адресаопределяемые "подсетью" применимы.

<pptp>
<n_pptp_units> 32 </n_pptp_units>
<pptp_subnet> 27 </pptp_subnet>

продолжение завтра....
Метки: pfsense, НЭмного пА РусскЕ
pfSense 1.2.3: Глава 14
Глава 14 PPTP VPN
pfSense может использоваться в качестве сервера VPN PPTP (как один из вариантов организации VPN). Это весьма привлекательная возможность, поскольку клиент PPTP имеется практически в любой версии Windows или OS X выпущенной за последние 10 лет. Кроме того вы можете предоставить услуги по передачи сервиса внутреннему PPTP серверу. Общее обсуждение VPN, доступных в pfSense, их достоинства и недостатки описываются в главе 12 "Виртуальные частные сети".

14.1 PPTP предупреждение безопасности
Если вы не использовали PPTP раньше, вам следует обратиться к разделу 12.2.7 "Криптографическая защита" рассказывающему о безопасности VPN. PPTP достаточно широко используется, однако это не самое безопасное решение VPN.

14.2 PPTP и правила брандмауэра
По умолчанию, когда вы используете перенаправление PPTP или включаете сервер PPTP, для WAN будут автоматически добавлены скрытые правила брандмауэра, разрешающие TCP 1723 и трафик GRE от любого источника до адреса получателя. Вы можете отключить поведение по умолчанию на pfSense 1.2.3 и более поздних версиях отметив чекбокс <Отключить все авто добавления VPN правил> (Disable all auto-added VPN rules) в меню Система >> Дополнительно (System >> Advanced). Вы можете захотеть использовать эту возможность, если точно знаете, что ваши PPTP слиенты будут соединяться только с определённых удалённых сетей. Это позволит предотвратить потенциальные злоупотребления с произвольных узлов, хотя в тех развертываниях системы, где пользователи мобильны и соединения производятся с различных узлов, знать все подключения невозможно и не практично использовать сжатый набор правил, в итоги приводящий к проблемам пользователей.

14.3 PPTP и multi-WAN
К сожалению, из-за способа работы PPTP и способа работы PF с протоколом GRE, возможность запуска PPTP сервера реализована только для основного WAN интерфейса.

update 14/11/2010


14.4 Ограничения PPTP
Код отслеживания состояния лежащий в основе брандмауэра PF для протокола GRE позволяет отслеживать только единственную сессию на публичном IP внешнего сервера. Это означает, что если вы используете соединение PPTP VPN, только одна внутренняя машина одновременно может соединиться с PPTP сервером в интернет. Тысяча машин может одновременно соединиться с тысячей различных серверов PPTP, но только одна машина может присоединяться к одному серверу одновременно. Единственная возможность - использовать множество публичных IP на вашем брандмауэре, один на клиент, или использовать множество публичных IP на внешнем PPTP сервере. С другими типами VPN соединений таких проблем нет.
Это же ограничение означает, что если вы добавляете функции PPTP сервера или перенаправления PPTP, никакие клиенты подключенные через NAT к вашему WAN IP адресу не смогут соединиться с внешним PPTP сервером. Рабочее решение - доступ клиентов в интернет через NAT реализуется с различных публичных IP адресов.
Оба этих ограничения позволяют работу в большинстве сред, однако их устранение имеет высокий приоритет для релиза pfSense 2.0. Во время написания этой книги, ведутся разработки позволяющие устранить эти ограничения, хотя говорить о их успехе пока ещё рано.

14.5 Конфигурирование сервера PPTP
Для конфигурирования PPTP сервера, перейдите в меню VPN >> PPTP. Выберите Включить PPTP сервер (Enable PPTP server).

14.5.1 IP адресация
Вам необходимо решить, какие IP адреса использовать для сервера PPTP и клиентов.Обычно, удалённое пространство адресов - часть подсети LAN например такой как 192.168.1.128/28 (т.е. с .128 до .143). Затем вам следует выбрать IP адрес за пределами данного диапазона для адреса сервера, например 192.168.1.144, как показано на рисунке 14.1, "IP адресация PPTP".

Рис.14.1 IP адресация PPTP
NOTE:
Эта подсеть может не входить в пределы существующей подсети вашего маршрутизатора. При желании вы можете использовать различный набор IP адресов.

продолжение будет....
Метки: pfsense, НЭмного пА РусскЕ
pfSense 1.2.3 Глава 1: Продолжение

1.5 Версии
Этот раздел описывает различные версии pfSense, доступные на текущий момент и в прошлом.

1.5.1 Релиз 1.2.3
Данный релиз является рекомендуемым для всех новых инсталляций. Он широко тестируется и разворачивается, а поскольку это последний выпуск он имеет все исправления ошибок и необходимые патчи безопасности. Релиз 1.2.3 включает исправления предыдущих ошибок и множество улучшений по сравнению с релизом 1.2.2, кроме того использует обновленную версию ОС FreeBSD 7.2. Большая часть материала книги относится ко всем версиям релиза 1.2.х, однако некоторые части акцентированы именно на версии 1.2.3. и возможно последующих релизах.

1.5.2 Релизы 1.2, 1.2.1, 1.2.2
Релиз 1.2 был первой стабильной версией ряда релизов и стал доступен 25 февраля 2008 года. Обновления 1.2.1 реализовали множество исправлений и некоторые незначительные патчи безопасности, и кроме того был осуществлён перезод к ОС FreeBSD 7.0. Релиз 1.2.2 имел несколько дополнительных исправлений.

1.5.3 Релиз 1.0
Данный релиз стал первым релизом pfSense классифицированным как стабильный. Он был выпущен 4 октября 2006 года и его развитием стал релиз 1.0.1 вносящий ряд исправлений, который появился 20 октября 2006 года . Хотя до сих пор существуют работающие версии 1.0, данный релиз больше не поддерживается и мы строго рекомендуем обновление до версии 1.2.3. Релиз 1.0.1 содержит несколько незначительх уязвимостей безопасности, исправленных в версиях 1.2 или 1.2.1.

1.5.4 Снапшоты
Снапшоты pfSense создаются в репозитории исходного кода каждые два часа. Они предназначены прежде всего для разработчиков и пользователей занимающихся тестированием системы. Снапшоты могут быть не всегда доступны. Вскоре после релиза 1.2 его снимки ушли в off-line поскольку инфраструктура сборки была обновлена до FreeBSD 7.0 и был подготовлен релиз 1.3 (теперь нумеруемый как 2.0). Подобная ситуация скорее всего будет существовать и далее. Доступные снапшоты можно обнаружить на сервере http://snapshots.pfsense.org.

1.5.5 Релиз 2.0
pfSense релиз 2.0 (ранее известный как 1.3) в настоящее время доступен для тестирования и в момент написания книги представляется alpha-версией. Он содержит множество улучшений, многие из которых всё ещё находятся в статусе текущих. Стабильная версия, или по крайней мере рабочий релиз ожидается в конце 2009 или начале 2010 года. Он будет базироваться на версии FreeBSD 8.0 и время выхода будет зависеть от выпуска релиза FreeBSD.

1.6 Платформы
pfSense предлагает три платформы, подходящие для трёх различных типов развёртывания. Этот раздел рассматривает каждую из них и потребности в их выборе.

1.6.1 Live CD
Live CD позволяет работу непосредственно с CD, не производя установку на жёсткий диск или Flash носитель. Конфигурация может сохраняться на дискете или USB-flash. После начальной загрузки доступ к CD практически не требуется, поскольку вся система работает в RAM памяти, однако CD диск не должен удаляться из системы. В большинстве случаев этот вариант должен использоваться при проведении оценки системы на ваших аппаратных средствах. Многие используют такой вариант как рабочий, однако, мы рекомендуем использовать установку системы. Пользователи LiveCD не могут использовать дополнительные пакеты и потеряют историю графиков производительности при перезагрузке системы.

1.6.2 Полная установка
Live CD включает установщик, позволяющий установить pfSense на жёсткий диск вашей системы. Это рекомендуемый режим работы pfSense. Весь жёсткий диск будет перезаписан; множественная загрузка ОС не поддерживается. По статистике загрузки мы можем предположить, что 80% всех установок системы - полные инсталляции. Большинство, если не все разработчики используют полные установки. Следовательно, этот вариант наиболее протестированный, наиболее поддерживаемый и не имеющий ограничения других платформ.

1.6.3 Встроенные системы
Версия для встроенных систем адаптируется для использования с любыми аппаратными средствами, и использует в качестве носителя CF (CompactFlash) а не жёсткий диск. Карты CF позволяют ограниченное количество записей, и следовательно встроенные версии используют CF только в режиме чтения, с файловыми системами чтения/записи RAM диска. Даже при таких условиях, CF широко поддерживается во встроенном оборудовании с использованием переходников IDE-CF. Хотя карты CF меньше чем стандартный разъём IDE, они имеют то же число контактов и являются совместимыми. Это облегчает их использование в IDE совместимых устройствах. Поскольку CF являются твердотельными носителями, вы, потенциально, избавляетесь от отказа механической поломки. Встроенные системы популярны по различным причинам, но самое главное - отсутствие механических приводов, малое потребление питания при достаточно эффективной работе. Соответственно они более отказоустойчивы и работают тихо. Исторически встроенный вариант платформы был второй по значимости платформой pfSense, после полной установки. Это притерпело некоторые изменения после появления следующих поколений встроенных устройств на базе NanoBSD.
Единственный недостаток встроенных систем - потеря данных истории графиков RRDtool при полном отключении энергоснабжения. Это конечно не влияет на производительность, но несколько неприятно.

1.6.3.1 Старая платформа встроенных систем (релизы до 1.2.3)
На старых embedded-платформах не поддерживались пакеты (это относится к версиям 1.2.2 и более ранним). Обновление так же работало несколько некорректно. 100% гарантию надёжного обновления давало только сохранение настроек конфигурации, очистка CF, и востановление конфигурации. В новой установке эти ограничения были устранены.

1.6.3.2 Встроенные системы на базе NanoBSD
NanoBSD является стандартным средством создания встроенных дистрибутивов FreeBSD. Оно поддерживает двойной микрокод и надёжное обновление. В момент написания книги дистрибутив на NanoBSD был полностью функциональным и реально используемым. Релиз 1.2.х использует эту технологию, и через некоторое время старые методы будут полностью устранены. Релиз 2.0 будет использовать только новый способ. В дополнение к множествам микрокода поддерживается переключение между двумя различными инсталляциями, что способствует двум важным плюсам. Так же будут поддерживаться пакеты для встроенной среды. Это позволит, в будущем, создавать кросс-сборки для архитектур отличных от x86, например MIPS и возможно ARM.

1.7. Сетевые концепции
Хотя это не введение к части книги о сетях, существуют определённые сетевые термины, которые важно правильно понимать. Мы не будем подробно освещать все темы. Если вам недостаёт каких то знаний по сетям и работой с ними, вам следует обратиться к дополнительной литературе. Читатели имеющие достаточные знания о IP адресации, IP подсетях, CIDR нотации могут перейти к следующей главе.

1.7.1 Понятия о публичных и частных IP адресах
В большинстве сетей присутствуют два типа IP адресов - публичные и частные.

1.7.2 Частные IP адреса
Частные IP адреса являются адресами зарезервированными в пределах подсетей, только для внутреннего использования. Стандарт RFC 1918 определяет подсети IP зарезервированные для использования в частных сетях (см. Таблицу 1.1."RFC 1918 пространство частных IP адресов") В большинстве сетевых сред частные подсети по RFC 1918 используются для всех устройств внутри сети, которые соединяются с интернет посредством брандмауэра или маршрутизатора реализующих NAT (преобразование сетевых адресов), например как pfSense. NAT будет разбираться в главе 7, Преобразование сетевых адресов.

Таблица 1.1
CIDR Range IP Address Range
10.0.0.0/8 10.0.0.0-10.255.255.255
172.16.0.0/12 172.16.0.0 - 172.31.255.255
192.168.0.0/16 192.168.0.0 - 192.168.255.255

Существуют и другие зарезервированные диапазоны адресов, например 1.0.0.0/8 и 2.0.0.0/8, однако они не попадают под RFC1918. Хотя было бы заманчиво использовать эти диапазоны, вероятность того, что они были выделены для каких либо реальных целей весьма высока, в связи с сокращением пространства адресов IPv4. Следует так же избегать использования диапазона 169.254.0.0/16 который согласно RFC 3927 резервируется для "Link-Local" автоконфигурации - но не должен присваиваться DHCP или вручную. Согласно RFC 1918 выделено достаточно большое пространство адресов для частных сетей, поэтому нет особого смысла отклоняться от рекомендаций стандарта. Если вы работаете с сетью не соответсвующей стандарту на частные IP адреса - лучше заняться исправлением адресации не дожидаясь проблем. Полный список сетей IPv4 выделенных для специального использования может быть найден в RFC 3330.

1.7.1.2 Публичные IP адреса
Публичные IP адреса присваиваются вашим ISP для всех, кроме самых крупных сетей. Сетям требующим сотен или тысяц публичных адресов обычно присваивается адресное пространство непосредственно Региональным Интернет Регистратором (RIR) обслуживающим данную область. RIR - организация которая контролирует выделение и регистрацию публичных IP адресов в выделенном регионе. Большинство постоянных интернет соединений работает с простым публичным IP адресом, в то время, как большинство бизнес структур при необходимости работает с опцией множественных публичных IP. Единственный публичный IP в совокупности с NAT может использоваться для присоединения сотен частных систем к интернет. Содержание этой книге поможет вам определить число публичных IP необходимых для вашей сети.

1.7.2 Концепция IP подсетей
Когда конфигурируется настройка TCP/IP для устройства, определяется маска подсети. Эта маска позволяет системе определить, какие IP адреса находятся в локальной сети, а какие могут разрешаться шлюзом в системной таблице маршрутизации. По умолчанию LAN IP 192.168.1.1 с маской 255.255.255.0 или /24 в CIDR нотации, записывается как 192.168.1.0/24. CIDR обсуждается в разделе 1.7.4 "Понятие нотации CIDR маски подсети"

1.7.3 Конфигурирование IP адреса, подсети и шлюза
Конфигурация TCP/IP состоит из трех основных вещей - адрес, маска подсети и шлюз. Объединённая маска подсети и шлюз определяет то, как узел узнаёт какие IP адреса находятся в его локальной сети. Для любых адресов вне локальной сети трафик перенаправляется к шлюзу по умолчанию, который должен знать как трафику достигнуть места назначения. Исключение из этого правила - статический маршрут, который сообщает маршрутизатору или системе о том, как связаться с определёнными не локальными сетями. Список шлюзов и статических маршрутов сохраняется на каждом узле в его таблице маршрутизации. Чтобы просмотреть таблицу маршрутизации используемую pfSense смотрите раздел 8.4.1, "Обзор маршрутов". Больший объём информации о маршрутизации можно найти в главе 8 "Маршрутизация".
В типичном применении pfSense узлам присваиваются IP адреса в пределах диапазона LAN pfSense, маска подсети LAN pfSense и IP LAN pfSense будет использоваться как шлюз по умолчанию. Те же правила применяются к узлам соединённым с другими интерфейсами кроме LAN, используя соответствующую конфигурацию интерфейса, с которым соединено устройство. Узлы в пределах единственной сети связываются непосредственно друг с другом без участия шлюза по умолчанию. Это означает, что никакой брандмауэр, в том числе и pfSense, не может контролировать коммуникацию типа хост-хост в сетевом сегменте. Если эта функциональность требуется, хосты должны быть сегментированы использованием множества свичей или VLANs, или должна использоваться эквивалентная функциональность свичей подобная PVLAN. VLAN рассматриваются в главе 10 "Виртуальные LAN (VLANs)"

продолжение следует... позже
Метки: pfsense, НЭмного пА РусскЕ

Запланирован перевод

pfSense: The Definitive Guide: The Definitive Guide to the pfSense
Open Source Firewall and Router Distribution

by Christopher M. Buechler and Jim Pingle
Based on pfSense Version 1.2.3
Publication date 2009
Copyright © 2009 Christopher M. Buechler

Я конечно в курсе что проект несколько староват - но для заказчика важна документация на русском языке. Может и ещё кому польза будет... уж мне то точно ;)





pfSense: Полное руководство
Полное руководство по Open Source дистрибутиву
брандмауера и маршрутизатора
.

Глава 1 Введение

pfSense - свободный специализированный дистрибутив FreeBSD с открытым исходным кодом, адаптированный для использования в качестве брандмауера и маршрутизатора, с удобным web-интерфейсом. Этот web-интерфейс известен как WebGUI. Для развёртывания и использования pfSense не требуется знание FreeBSD и фактически большинство пользователей никогда не будет использовать FreeBSD за пределами pfSense. Кроме того, что платформа является гибкой и мощной, она включает значительный набор связанных функций и системных пакетов, позволяющих расширить возможности системы не внося потенциальных уязвимостей в систему и увеличения её размера. pfSense - популярный проект скачаный более чем 1 миллион раз со времени своего выхода и доказавший свою эффективность в множестве инсталляций - от малых домашних сетей до сетей крупных корпораций, университетов и организаций с тысячами сетевых хостов.


1.1. Основание проекта

Этот проект был основан в 2004 году Крисом Буечлером и Скотом Аллричем. Несколько ранее, Крис занимался дистрибутивом m0n0wall и обнаружил, что это было отличным решением. Однако в то время многие пользователи ждали больших возможностей, чем можно было реализовать в проекте разработанном для целей создания встроенных устройств. И тогда появился pfSense. Современные аппаратные средства прекрасно поддерживаются pfSense и сегодня. В 2004 году существовало множество устройств с RAM 64 Мбайт, которые не могли обеспечить набор функций реализуемый сегодня pfSense.

1.2 Как становился pfSense

В течении пары месяцев проект существовал без имени. Фактически, FreeBSD jail в которой работает наш север CVS всё ещё называют projectx. Мы проверили множество возможных названий, основной трудностью стало находжение доменного имени. Скотт придумал pfSense, поскольку pf использовался в качестве фильтрующего пакета. В течении пары недель мы не смогли придумать ничего лучше. Было решено "что мы всегда сможем изменить название". Поскольку большинству пользователей и разработчиков было безразлично название, всё осталось без изменений. В середине 2007 года было инициировано обсуждение наименования проекта и большинство голосов сообщества изрекли "сохранить имя!".

1.3 Почему FreeBSD?

Поскольку многие из компонентов pfSense появились из OpenBSD, можно спросить, почему мы выбрали FreeBSD, а не OpenBSD. Мы рассматривали различные факторы выбирая ОС для данного проекта. Этот раздел в общих чертах объясняет причины выбора FreeBSD.

1.3.1 Поддержка беспроводных сетей

Мы знали, что поддержка беспроводных сетей будет критически важной для многих пользователей. В то время когда был основан проект (в 2004 году), поддержка беспроводных сетей в OpenBSD была сильно ограничена. Поддержка беспроводных сетей в FreeBSD была гораздо шире, к тому же, OpenBSD не имела поддержки таких важных моментов как WPA и WPA2 (даже не было планов реализации этой поддержки). С 2004 года ситуация конечно изменилась, но по возможностям работы с беспроводными устройствами FreeBSD остаётся впереди.

1.3.2 Производительность сети

Производительность сетевого стэка FreeBSD значительно лучше чем OpenBSD. Для малого и среднего масштаба развёртывания это не имеет большого значения, однако слоожность масштабирования - основная проблема OpenBSD. Один из разработчиков pfSense управляет несколькими сотнями брандмауеров PF OpenBSD, и ему потребовалось реализовать переход на PF FreeBSD для обработки огромного числа пакетов. Эта проблема была частично решена OpenBSD с 2004 года, но всё ещё ощущается.

1.3.4 Знакомый и непринуждённый fork.

С самого начала pfSense использовал кодовую базу m0n0wall, основанную на FreeBSD - соответственно проще было остаться на FreeBSD. Измение ОС потребовали бы внесения изменений в каждую часть проекта. Скотт и Крис в значительной мере более глубоко были знакомы с FreeBSD и ранее работали вместе над прошлыми коммерческим решениями брандмауеров на базе FreeBSD. Хотя это не было основным доводом, но в совокупности с двумя другими факторами указало направление работы.

1.3.5 Поддержка альтернативных ОС

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

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

1.4.1 Периметровый брандмауэр
Наиболее распространённый способ применения pfSense - в образе периметрового брандмауэра, интернет соединение ->WAN и внутренняя сеть -> LAN. pfSense предоставляет сетям более комплексные возможности, например такие как множественные интернет соединения, множество LAN сетей, множество DMZ сетей и пр. Некоторые пользователи добавляют возможности BGP (Border Gateway Protocol) реализующий избыточность соединений и балансировку нагрузки. Более подробно читайте главу 8, Маршрутизация.

1.4.2 LAN или WAN маршрутизатор
Второй, наиболее частый способ использования pfSense - в качестве маршрутизатора WAN или LAN. Эта роль выделяется из периметрового брандмауэра в средних и крупных сетях, но может интегрироваться с ним в малых сетевых средах.

1.4.2.1 Маршрутизатор LAN

В крупных сетях, имеющих множество сегментов внутренней сети, pfSense - испытанное решение позволяющее соеденить эти сегменты. Развёртывание обычно осуществляется посредством VLAN с транкингом 802.1Q, который будет описан в главе 10, Виртуальные LAN (VLANs). В некоторых средах используются множественные интерфейсы Ethernet.

Замечание:
В средах требующих длительной пропускной способности более чем 3Гбит/сек или более чем 500 000 пакетов в секунду, ни какие маршрутизаторы, основанные на дешёвом оборудовании (commodity hardware) применяться не могут. Такие среды должны разворачиваться на коммутаторах 3-го уровня (маршрутизация на аппаратных свичах) или основываться на базе ASIC маршрутизаторах. Поскольку производительность "дешёвого оборудования" возрастает, а ОС общего назначения, например такие как FreeBSD улучшает возможности обработки пакетов в соответствии с новым оборудованием, их масштабируемость продолжает улучшаться.

1.4.2.2 Маршрутизатор WAN

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

1.4.3 Беспроводная точка доступа

Многие развёртывают pfSense исключительно в качестве точки доступа. Имейте в виду: беспроводные возможности могут быть добавлены к любому типу развёртывания.

1.4.4 Устройства особого назначения
Многие развёртывают pfSense как устройство особого назначения. Существуют четыре сценария которые мы знаем и наверно боьше тех о которых мы не знаем. Большинство фукций pfSense могут быть использованы при развёртывании такого устройства. Вы можете выбрать нечто уникальное для своей среды. Некоторые устройства особого назначения будут доступны во второй версии дистрибутива.

1.4.4.1 VPN устройство

Некоторые пользователи используют pfSense в качестве устройства VPN за существующим брандмауэром, добавляя возможности VPN и не внося разрушений в существующую схему. Некоторые VPN устройства на pfSense работают и как периметровые брандмауэры - но это отдельные случаи.

1.4.4.2 Серверы DNS
pfSense позволяет реализовать сервер DNS, на базе TinyDNS - маленьком, быстром и безопасном DNS сервере. Получается сервер не перегруженный множеством лишних функций, который не может применяться для различных задач подобно Microsoft AD, но это прекрасное решение для того, чтобы реализовать доступный DNS....

1.4.4.3 Реализация сниффера

Один пользователь искал реализацию сниффера для развёртывания сети филиалов. Коммерческие снифферы доступны со всеми свистелками, однако их характеризует существенная стоимость, особенно при использовании значительной структуры. pfSense предлагает web-интерфейс для tcpdump, который позволяет загрузку результирующего файла pcap по завершению захвата. Это позволиляет получит пакеты из сети филиалов, загрузить результирующий файл захвата и открыть его в Wireshark для анализа. Конечно pfSense не обладает такой же функциональностью, как коммерческие снифферы, однако предлагает соответствующий функционал по значительно меньшей стоимости. Для получения дополнительной информации о использовании функции захвата пакетов в pfSense смотрите главу 25, Захват пакетов.

1.4.4.4 Реализация сервера DHCP
Некоторые пользователи разворачивают pfSense как DHCP сервер, с целью раздачи IP адресов для собственных сетей. Возможно, для большинства сред это не имеет практического значения, но в данном случае сотрудники были хорошо знакомы с pfSense и довольны его работой, поэтому использовали его возможности без дополнительного обучения администратора, что было весьма важно в данном случае.

продолжение следует....
Последнее обновление 12.09.11 08:09