🛡️ День 11 — Настройка сети дома и на участке: устойчивый туннель WireGuard + мониторинг

В этом материале я описываю реальный кейс: как связал две площадки HomeLab (дом и участок) в единую L3-сеть через WireGuard, навёл порядок в админ-доступе к MikroTik и подготовил базовый мониторинг канала.

🧩 Исходная схема

Две независимые площадки:

• 🏠 Дом: 192.168.xx.0/24
• шлюз: home-gate (192.168.xx.1)
• WG-узел: vpn01 (192.168.xx.xx, интерфейс wg0)
• 🌲 Участок: 192.168.yy.0/24
• шлюз: elovaya-gate (192.168.yy.1)

🎯 Задача: обеспечить полноценную L3-связность между подсетями без "костылей", с предсказуемой маршрутизацией и безопасным управлением.

Схема (L3 топология)

         Площадка 1 (Дом)                          Площадка 2 (Участок)

   [LAN 192.168.xx.0/24]                      [LAN 192.168.yy.0/24]
            |                                           |
        +---+----+                                 +----+---+
        | home-gate|                               | elovaya |
        |  (gw)    |                               |  -gate  |
        +---+----+-+                               +--+----+-+
            |    |                                     |    |
            |    +--> mgmt/ssh (key only)              |    +--> mgmt/ssh (key only)
            |
        +---+-------------------+   WireGuard   +-------------------+---+
        |        vpn01 (wg0)    |<=============>|    elovaya-gate   |
        |   routes xx<->yy      |              |   routes yy<->xx  |
        +-----------------------+              +-----------------------+

Ключевая идея: прозрачная L3-маршрутизация между подсетями (без L2-мостов).

✅ Что было сделано

1) 🔐 Поднят site-to-site WireGuard

• Поднят туннель между домашней и удалённой площадкой.
• На обеих сторонах настроены AllowedIPs так, чтобы маршрутизация была прозрачной.
• Прописаны маршруты между 192.168.xx.0/24 и 192.168.yy.0/24.
• Проверена двусторонняя доступность:
• ping между подсетями
• доступность ключевых сервисов

2) 🧭 Исправлены маршруты и доступ с узлов

Классика: туннель поднялся, ping есть, а часть трафика ведёт себя странно.

Что проверял и правил в первую очередь:

• корректный next-hop до удалённой подсети
• где именно должен жить маршрут (на шлюзе или на отдельном WG-узле)
• чтобы обратный маршрут существовал на обеих сторонах

Мини-чеклист для диагностики:

1) Пинг до удалённого шлюза
2) Пинг до удалённого хоста
3) Проверка TCP к нужному порту (curl/nc)
4) Проверка маршрутов на обеих сторонах
5) Проверка forward/firewall и fasttrack

3) 🔑 Безопасный SSH-доступ к MikroTik

Дальше я привёл управление в нормальный вид:

• добавил ed25519 ключ для админ-учётки
• включил strong-crypto
• отключил парольный SSH там, где это подтверждено
• ограничил доступ к управлению доверенными источниками

Это сильно снижает риск "пароль утёк" и упрощает сопровождение.

4) 🧹 Наведён порядок во временных правилах

Во время диагностики обычно появляются временные правила (логирование, temp-allow, быстрые исключения).
Я сознательно дочистил их после стабилизации:

• удалил диагностические temp/log-правила
• проверил, что рабочая связность не потерялась

5) 💾 Сделаны финальные бэкапы и оформлена документация

С каждого роутера снял:

• export (.rsc)
• бинарный backup (.backup)

И всё это оформил как документируемое состояние (отдельный git-репозиторий под сеть).

Публичные ссылки на репозитории здесь не привожу, но смысл простой:

• бэкапы
• описание топологии
• состояние по каждому MikroTik
• чеклист следующих шагов

🧪 Практический вывод: "пингуется, но сервис не открывается"

Очень частая ловушка: ping есть, значит "всё работает". Но ping проверяет только базовую связность, а не реальную работу сервисов.

Случаи из практики:

• TCP соединение устанавливается, но сервис отвечает нестабильно
• сервис закрывает соединение из-за своих правил/ACL
• есть fasttrack / firewall policy, которая ломает stateful-трафик поверх туннеля

В таких ситуациях лечится не сменой туннеля, а точечной настройкой:

• правила forward
• исключение нужного трафика из fasttrack
• при необходимости узкий SNAT под конкретный источник/порт (лучше точечно, чем "всё подряд")

🧠 Почему WireGuard, а не L2TP/IPsec

WireGuard оставлен как основной канал, потому что:

• ✅ схема проще
• ⚡ производительность выше
• 🧭 маршрутизация прозрачнее
• 🧰 сопровождение удобнее

L2TP/IPsec в этом кейсе не решает прикладные проблемы на конечных устройствах, если они упираются в firewall/сервисную часть.

📈 Мониторинг: что добавил и что планирую

Минимальная цель мониторинга: быстро понять, что "канал жив", и где именно деградирует.

Что полезно мониторить в первую очередь:

• 🟢 доступность удалённой стороны (ping до ключевых IP)
• 🧷 состояние WireGuard (есть ли handshake / обновляется ли)
• ⏱️ задержка и потери (latency / packet loss)
• 📊 трафик по интерфейсу WG (rx/tx)

Как я это делаю без лишнего усложнения:

• добавляю host/endpoint в мониторинг (на базе того, что уже есть в HomeLab)
• использую простые проверки (icmp + tcp)
• для WireGuard фиксирую факт handshake и возраст последнего обмена

📌 Текущий статус

• ✅ Дом ↔ участок: работает стабильно по WireGuard
• ✅ Управление MikroTik: переведено на ключи
• ✅ Бэкапы и документация: оформлены и закоммичены
• 🔜 Следующий этап: подключение следующей площадки и расширение мониторинга