📡 Что мы строили
Связать три сети через VPN:
- Центр: VPN-сервер pfSense (10.88.33.0/24, 172.30.99.1)
- Офис Строгино: Keenetic за pfSense (192.165.10.0/24)
- Офис Жуково: UDM (192.165.40.0/24, 172.30.99.140)
- Транзитная VPN-сеть: 172.30.99.0/24
⚠️ Важно: В статье про UDM Pro, но на самом деле устройство — UDM (Dream Machine), не Pro. Но суть та же.
🔧 Основные действующие лица
| Устройство | Роль | IP в VPN | Локальная сеть |
|---|---|---|---|
| pfSense (центр) | Сервер WireGuard | 172.30.99.1 | 10.88.33.0/24 |
| UDM (Жуково) | Клиент WireGuard | 172.30.99.140 | 192.165.40.0/24 |
| Keenetic (Строгино) | Клиент WireGuard за pfSense | 172.30.99.11 | 192.165.10.0/24 |
🗺️ Маршрут наших мучений
Шаг 1. Базовые настройки WireGuard на UDM
На UDM создали WireGuard-клиента:
- Endpoint: 188.127.243.55:8279 (внешний IP pfSense)
- Внутренний IP: 172.30.99.140/24
- DNS: 172.30.99.1 (pfSense внутри VPN)
💡 Важно: В интерфейсе UDM нет поля AllowedIPs — оно заменяется "Связанными политиками" (политики маршрутизации). Но для работы достаточно, чтобы на pfSense в пире были прописаны нужные сети.
Шаг 2. Настройка AllowedIPs на pfSense
В Peer для UDM прописываем:
AllowedIPs = 172.30.99.140/32, 192.165.40.0/24, 10.88.33.0/24
В Peer для Keenetic (Строгино):
AllowedIPs = 172.30.99.11/32, 192.165.10.0/24, 10.88.33.0/24, 192.165.40.0/24
Шаг 3. Правила файрвола на UDM (главная боль 🔥)
Создали несколько правил, но работает только одно:
Правило: Allow VPN to LAN all
Action: Разрешить
Protocol: Все
Source Zone: Внешняя зона (где интерфейс wireguard)
Source IP: Любое (или 172.30.99.0/24)
Destination Zone: Внутренние (marshalajukova)
Destination Network: 192.165.40.0/24
Priority: 8000
⚠️ Критический момент: Правила с конкретным IP-источником (например, 172.30.99.1) могут НЕ РАБОТАТЬ! UDM не всегда сопоставляет IP с зоной правильно. Используйте подсети (172.30.99.0/24) вместо отдельных IP.
Шаг 4. Статический маршрут на UDM
Добавили маршрут до офиса Строгино:
Сеть: 192.165.10.0/24
Шлюз: 172.30.99.1 (pfSense)
Интерфейс: wireguardtopfsense
Шаг 5. Проблема с ICMP Redirect от pfSense
При пинге с Keenetic (172.30.99.11) на устройство в Жуково (192.165.40.213) получали:
"Redirect message" ICMP packet received from 172.30.99.1 (type = 5, code = 1).
Причина: pfSense говорил Keenetic'у «шпи пакеты напрямую на UDM (172.30.99.140)», но Keenetic не мог пинговать UDM, потому что на UDM не было разрешения для ICMP от 172.30.99.11.
Шаг 6. Решение проблемы Redirect
Вариант А (рабочий): Добавить на UDM правило, разрешающее ICMP от всей подсети 172.30.99.0/24:
Правило: Allow ICMP from VPN
Action: Разрешить
Protocol: ICMP
Source Zone: Внешняя зона
Source Network: 172.30.99.0/24 # !!! именно подсеть, а не отдельный IP
Destination Zone: Внутренние
Destination Network: 192.165.40.0/24
Priority: 8000
Вариант Б (альтернативный): Отключить ICMP Redirect на pfSense:
System → Advanced → Network Optimizer → Disable ICMP Redirect
# или через консоль:
sysctl net.inet.ip.redirect=0
echo "net.inet.ip.redirect=0" >> /etc/sysctl.conf
💡 Инсайт: В нашем случае помогло просто расширение правила с 172.30.99.1 до 172.30.99.0/24. После этого Keenetic смог пинговать UDM, и Redirect перестал мешать.
Шаг 7. Неожиданный финал
После всех плясок с бубном оказалось, что правило ykhyjk (ICMP от 172.30.99.1) вообще не нужно — его отключение ничего не сломало, а пинги продолжали работать.
⚡ Вывод: На UDM лучше не создавать лишних правил. Часто достаточно одного широкого правила между зонами, а остальное закрывается системными правилами (Allow Return Traffic и т.д.).
✅ Финальная конфигурация
На pfSense (сервер, центр):
- Порт UDP 8279 открыт на WAN
- В Peer UDM: AllowedIPs = 172.30.99.140/32, 192.165.40.0/24, 10.88.33.0/24
- В Peer Keenetic: AllowedIPs = 172.30.99.11/32, 192.165.10.0/24, 10.88.33.0/24, 192.165.40.0/24
- На интерфейсе WireGuard: правило Pass для трафика между всеми сетями
- ICMP Redirect: оставлен включённым (не критично после настройки UDM)
На UDM (Жуково):
- WireGuard подключен (статус: Подключено)
- Статический маршрут: 192.165.10.0/24 → 172.30.99.1 (wireguardtopfsense)
- Статический маршрут: 10.88.33.0/24 → 172.30.99.1 (wireguardtopfsense)
- Правило файрвола (единственное рабочее): Allow VPN to LAN all (Source: Внешняя зона, Destination: Внутренние, 192.165.40.0/24)
На Keenetic (Строгино):
- WireGuard: AllowedIPs = 10.88.33.0/24, 192.165.0.0/16, 172.30.99.0/24
- Статический маршрут: 192.165.40.0/24 → 172.30.99.140 (UDM) - опционально
🎯 Результат
✅ UDM пингует офис Строгино (192.165.10.1)
✅ pfSense пингует UDM (172.30.99.140) и устройство в Жуково (192.165.40.213)
✅ Keenetic (Строгино) пингует устройство в Жуково (192.165.40.213)
✅ Устройство в Жуково пингует Keenetic (192.165.10.1)
✅ ICMP Redirect больше не мешает
💡 Главные выводы (из реального опыта)
- AllowedIPs должны быть прописаны на всех пирах и включать все сети с обеих сторон. Иначе пакеты не будут уходить в туннель.
- На UDM правила с конкретным IP-источником могут не работать. Всегда используйте подсети (/24), даже если источник один.
- ICMP Redirect от pfSense — не ошибка, а подсказка. Он появляется, когда есть более прямой путь. Решается либо настройкой этого пути, либо отключением Redirect.
- Не создавайте лишних правил. Иногда одно широкое правило между зонами решает все проблемы.
- Проверяйте пинг от каждого узла до каждого. Это быстро локализует проблему.
- На Keenetic в AllowedIPs обязательно добавлять 172.30.99.0/24, иначе он не сможет общаться с другими пирами в VPN-сети.
🔍 Полезные команды для проверки
# На UDM (SSH)
wg show
ping 192.165.10.1
ping 10.88.33.1
ip route show | grep -E "192.165.10|10.88.33"
# На pfSense (Diagnostics → Ping)
ping 172.30.99.140
ping 192.165.40.213
ping 192.165.10.1
# На Keenetic (через CLI или веб-интерфейс)
ping 172.30.99.140
ping 192.165.40.213
# Проверка логов на UDM
tcpdump -i wgclt1 -n icmp
iptables -L -n -v | grep -E "192.165.40|172.30.99"
📚 Словарик терминов
| Термин | Значение |
|---|---|
| ICMP Redirect | Сообщение от роутера: «есть более прямой путь, шли туда» |
| AllowedIPs | В WireGuard — список сетей, которые доступны через этого пира |
| UBIOS | Система файрвола на UDM (цепочки iptables с префиксом UBIOS_) |
| Зоны (Firewall Zones) | Группировка интерфейсов на UDM для правил файрвола |
✏️ Послесловие: Эта статья родилась из реального 3-часового сражения с маршрутами, файрволами и ICMP Redirect. Надеемся, она сэкономит вам несколько часов жизни и пару нервных клеток. 🚀
Комментарии
Пока нет комментариев. Будьте первым!