Хабр·Russia·Friday, September 18, 2026 at 01:00 PM

# Как протянуть домашнюю сеть и цифровое ТВ на дачу через LTE

Translate

Manfred1514 минут назад

Это продолжение моей статьи «OpenWrt в Proxmox как домашний умный шлюз: DHCP, DNS, sing-box и выборочный VPN для всей сети». В первой части я собрал домашний шлюз на OpenWrt. Здесь займемся удаленной точкой: дачным MikroTik, LTE, WireGuard до дома и автоматическим возвратом на мобильный интернет, если туннель перестал работать.

Зачем я вообще в это полез

На даче у меня нет городского проводного провайдера. Есть LTE, MikroTik и локальная сеть. В городе при этом есть нормальная домашняя сеть, OpenWrt и цифровое ТВ от провайдера. На даче у меня стоит MikroTik SXT LTE kit. Это важно уточнить, потому что дальше я периодически буду писать просто MikroTik, но речь именно об этой модели. LTE-модем и направленная антенна у SXT находятся в одном корпусе, поэтому когда ниже я говорю “поворачиваем антенну”, на самом деле я физически поворачиваю весь SXT в сторону нужной базовой станции. RouterOS у меня 7.x. На других LTE-моделях MikroTik названия интерфейсов, доступные LTE-команды и работа с фиксацией соты могут немного отличаться.

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

При этом делать конструкцию, которая полностью зависит от WireGuard, не хотелось. Если дома выключился свет, сломался интернет, перезагрузился OpenWrt или просто умер туннель, обычный интернет на даче должен продолжать работать через LTE.

Получились две задачи:

Пока WireGuard жив, основной трафик дачной сети идет домой через OpenWrt.
Если домашняя сторона недоступна, MikroTik автоматически возвращается на LTE.

И еще одна вещь выяснилась довольно быстро. Начинать с WireGuard было рано. LTE-модем иногда выбирал не самую удачную соту, качество плавало, а направленная антенна была выставлена скорее по принципу «ну вроде сигнал есть». Поэтому сначала пришлось привести в порядок сам мобильный канал.

Важно: если цифровое ТВ конкретного провайдера работает через multicast, отдельный VLAN или жестко завязано на IGMP, одного L3-туннеля WireGuard может быть недостаточно. Здесь я строю транспорт между дачей и домом и заворачиваю дачный интернет через домашнюю сторону. Для OTT-приложения или ТВ-сервиса, которому достаточно домашнего выхода провайдера, этого уже может хватить. Multicast IPTV лучше рассматривать отдельным этапом после того, как сама связность работает стабильно.

Что в итоге собираем

Рисунок 1. Дачный MikroTik выходит в интернет через LTE и держит WireGuard до домашнего OpenWrt.

Схема у меня получилась такая:

Дача:
  LAN MikroTik:       192.168.1.0/24
  MikroTik:           192.168.1.1
  LTE-интерфейс:      lte1
  WireGuard:          wg-openwrt
  WG IP MikroTik:     10.10.10.2/24

Дом:
  Основная сеть:      192.168.0.0/24
  Основной роутер:    192.168.0.1
  OpenWrt:            192.168.0.2
  WG IP OpenWrt:      10.10.10.1/24
  WireGuard UDP:      51830

Маршрутизация на даче:
  <HOME_PUBLIC_IP>/32 -> lte1
  192.168.0.0/24      -> WireGuard
  0.0.0.0/0           -> 10.10.10.1, distance 1, check-gateway=ping
  0.0.0.0/0           -> LTE, distance 2

Главный смысл отдельного маршрута <HOME_PUBLIC_IP>/32 -> lte1 в том, что сам WireGuard endpoint всегда должен быть доступен через LTE. Иначе после переключения default route в туннель можно случайно попытаться построить WireGuard через самого себя.

Что понадобится

MikroTik с RouterOS 7 и LTE-интерфейсом;
рабочий LTE-интернет на даче;
внешняя LTE-антенна, если она у вас используется;
домашний OpenWrt с WireGuard;
публично доступный UDP-порт на домашней стороне или другой способ сделать endpoint доступным из интернета;
доступ к MikroTik по WinBox/терминалу;
желательно возможность попасть в OpenWrt через локальную консоль, если во время настройки маршрутов что-то пойдет не так.

В моем случае используется MikroTik SXT LTE kit со встроенной направленной антенной. Отдельной внешней антенны у меня нет. Поэтому поиск лучшей БС сводился к тому, чтобы смотреть параметры LTE и понемногу менять направление самого SXT.

В примерах ниже использую плейсхолдер <HOME_PUBLIC_IP>, <OPENWRT_WG_PUBLIC_KEY> и <MIKROTIK_WG_PUBLIC_KEY>. Реальные ключи и публичный адрес в статью, понятное дело, лучше не выкладывать.

Шаг 1. Сначала проверяем LTE

Когда WireGuard начинает работать нестабильно, очень легко полезть в firewall, маршруты или MTU. Но если в этот момент сам LTE прыгает между сотами или сидит на плохой базовой станции, отладка быстро превращается в угадайку.

Поэтому сначала проверяем именно радио.

/interface lte monitor lte1 once

В моем случае один из нормальных замеров выглядел примерно так:

operator:       YOTA
access-tech:    LTE
phy-cellid:     131
earfcn:         1575
band:           B3 @ 15 MHz
cqi:            8
rsrp:           -81 dBm
rsrq:           -15 dB

Тут полезно смотреть не на одну цифру, а на набор параметров.

RSRP показывает уровень полезного сигнала. Чем ближе значение к нулю, тем лучше. RSRQ больше говорит о качестве радиообстановки. SINR, если модем его показывает, хорошо отражает отношение полезного сигнала к шуму и помехам. CQI тоже полезен как дополнительный индикатор качества канала.

При этом я бы не пытался выбирать направление антенны по одному замеру. Сотовая сеть живая, нагрузка меняется, модем может переехать на соседнюю соту, поэтому важнее повторяемость результата.

Шаг 2. Смотрим соседние соты

Для этого у RouterOS есть cell-monitor:

/interface lte cell-monitor lte1

Например, в одном из проходов у меня было примерно так:

PHY-CELLID   BAND   EARFCN   RSRP       RSRQ
90           B3     1575     -90 dBm    -19.5 dB
373          B7     2850     -115 dBm   -19 dB

В этот момент очень хорошо видно, почему нельзя выбирать соту только по номеру диапазона. B7 звучит красивее и теоретически может дать больше полосы, но с RSRP около -115 dBm он в конкретной точке может работать хуже нормального B3.

Поэтому мой алгоритм получился простой:

Запоминаю текущую соту и параметры.
Смотрю соседей через cell-monitor.
Немного поворачиваю антенну.
Жду, пока модем стабилизируется.
Снова смотрю lte monitor и cell-monitor.
После удачного положения проверяю уже обычный интернет.

Рисунок 2. Сначала добиваемся стабильного LTE, только потом поднимаем WireGuard.

Для проверки самого канала:

/ping 1.1.1.1 interface=lte1 count=5
/tool fetch url=https://ifconfig.me/ip output=user

И заодно смотрим, что LTE-интерфейс действительно получил адрес и участвует в маршрутизации:

/interface lte print detail
/ip address print detail where interface=lte1
/ip route print detail where dst-address=0.0.0.0/0

У мобильного оператора адрес на lte1 вполне может быть серым, например из 10.0.0.0/8. Для этой схемы это нормально. MikroTik сам инициирует WireGuard-соединение до дома, поэтому белый IP на даче не нужен.

Шаг 3. Если модем прыгает между сотами

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

Сначала в такой ситуации лучше несколько раз посмотреть:

/interface lte monitor lte1 once
/interface lte cell-monitor lte1

Если видно, что проблема именно в reselection, для некоторых модемов можно зафиксировать конкретную соту через AT*Cell.

Пример:

/interface lte at-chat lte1 input="AT*Cell=2,3,,1575,90"

Здесь:

3     LTE Band 3
1575  EARFCN
90    PHY Cell ID / PCI

Снять фиксацию:

/interface lte at-chat lte1 input="AT*Cell=0"

Важно: AT*Cell не является универсальной командой для любого LTE-модема. Сначала убедитесь, что ваш модем ее поддерживает. Я бы не фиксировал соту после одного удачного замера. Сначала несколько проверок, потом обычный ping и реальная работа интернета, и только после этого lock.

После фиксации снова проверяем:

/interface lte monitor lte1 once
/interface lte cell-monitor lte1
/ping 1.1.1.1 interface=lte1 count=5

Если стало хуже, снимаем lock и возвращаемся к поиску нормального положения антенны.

Шаг 4. Перед маршрутами включаем Safe Mode и делаем бэкап

Маршруты на удаленном MikroTik лучше не менять без страховки. Одной неверной командой довольно легко отрезать себе доступ.

В терминале RouterOS Safe Mode включается:

Ctrl + X

Перед изменениями я еще сохраняю конфигурацию:

/export hide-sensitive file=before-openwrt-wg
/system backup save name=before-openwrt-wg

У Safe Mode есть обратная сторона. Если настройка уже заработала, а вы забыли выйти из него и сессия оборвалась, RouterOS откатит последние изменения. У меня такое было. Туннель уже работал, потом ноутбук перезагрузился, и часть конфигурации исчезла.

Поэтому порядок такой: включили Safe Mode, настроили, проверили, еще раз нажали Ctrl + X и только после этого считаем изменения сохраненными.

Шаг 5. Смотрим, нет ли старых хвостов WireGuard

На моем MikroTik уже оставались старый wg-client, отдельная routing table, routing rules и NAT. Я сначала ничего не удалял, а просто посмотрел состояние:

/interface print detail
/interface wireguard print detail
/interface wireguard peers print detail
/ip address print detail
/ip route print detail
/ip route print detail where dst-address=0.0.0.0/0
/routing table print
/routing rule print
/ip firewall nat print detail
/interface list member print

Старую схему безопаснее сначала отключить:

/interface wireguard disable [find name="wg-client"]
/interface wireguard peers disable [find interface=wg-client]
/ip route disable [find routing-table=via-wg]
/routing rule disable [find table=via-wg]
/ip firewall nat disable [find out-interface=wg-client]

Если новый туннель не взлетит, вернуть старый вариант намного проще, чем вспоминать, что именно было удалено.

Шаг 6. Проверяем WireGuard на домашнем OpenWrt

Домашний OpenWrt у меня уже был настроен по первой статье. На нем WireGuard слушает UDP 51830 и имеет адрес 10.10.10.1/24.

Проверяем:

wg show
ip a show wg_in

Публичный ключ OpenWrt:

cat /etc/wireguard/wg_in_public.key

На основном домашнем роутере нужен проброс:

UDP 51830 -> 192.168.0.2:51830

Если домашний интернет тоже находится за CG-NAT и входящего публичного адреса нет, обычная схема с прямым endpoint не заработает. Тогда нужен внешний сервер, обратная схема или другой способ сделать домашний WireGuard доступным снаружи.

Шаг 7. Создаем WireGuard на MikroTik

На даче создаем отдельный интерфейс:

/interface wireguard
add name=wg-openwrt mtu=1420

/ip address
add address=10.10.10.2/24 interface=wg-openwrt comment="WG to OpenWrt"

Сразу проверяем, что адрес действительно появился:

/ip address print detail where interface=wg-openwrt
/interface wireguard print detail where name=wg-openwrt

Это кажется мелочью, но я на этом уже попадался. После отката Safe Mode peer показывал handshake, а /ping 10.10.10.1 возвращал ошибку. Причина была банальная: адрес 10.10.10.2/24 на интерфейсе исчез.

Шаг 8. Добавляем домашний OpenWrt как peer

/interface wireguard peers
add interface=wg-openwrt \
    public-key="<OPENWRT_WG_PUBLIC_KEY>" \
    endpoint-address=<HOME_PUBLIC_IP> \
    endpoint-port=51830 \
    allowed-address=0.0.0.0/0 \
    persistent-keepalive=25s

persistent-keepalive=25s здесь полезен из-за LTE и NAT. Туннель инициируется с дачи и периодический keepalive не дает NAT-состоянию тихо протухнуть.

Публичный ключ самого MikroTik можно получить так:

:put [/interface wireguard get [find name="wg-openwrt"] public-key]

Шаг 9. Добавляем MikroTik как peer на OpenWrt

На OpenWrt:

uci add network wireguard_wg_in
uci set network.@wireguard_wg_in[-1].description='mikrotik'
uci set network.@wireguard_wg_in[-1].public_key='<MIKROTIK_WG_PUBLIC_KEY>'
uci add_list network.@wireguard_wg_in[-1].allowed_ips='10.10.10.2/32'
uci add_list network.@wireguard_wg_in[-1].allowed_ips='192.168.1.0/24'
uci set network.@wireguard_wg_in[-1].route_allowed_ips='1'
uci commit network
/etc/init.d/network restart

Здесь 192.168.1.0/24 нужен потому, что эта сеть реально находится за MikroTik.

Проверяем маршруты:

ip route | grep -E '10.10.10|192.168.1'

Ожидаемо:

10.10.10.0/24 dev wg_in
10.10.10.2 dev wg_in
192.168.1.0/24 dev wg_in

Шаг 10. Firewall OpenWrt

Для wg_in я сделал отдельную зону:

uci add firewall zone
uci set firewall.@zone[-1].name='wg_in'
uci set firewall.@zone[-1].network='wg_in'
uci set firewall.@zone[-1].input='ACCEPT'
uci set firewall.@zone[-1].output='ACCEPT'
uci set firewall.@zone[-1].forward='ACCEPT'

uci add firewall rule
uci set firewall.@rule[-1].name='Allow-WireGuard-Internet'
uci set firewall.@rule[-1].src='wan'
uci set firewall.@rule[-1].proto='udp'
uci set firewall.@rule[-1].dest_port='51830'
uci set firewall.@rule[-1].target='ACCEPT'

uci add firewall forwarding
uci set firewall.@forwarding[-1].src='wg_in'
uci set firewall.@forwarding[-1].dest='wan'

uci add firewall forwarding
uci set firewall.@forwarding[-1].src='wg_in'
uci set firewall.@forwarding[-1].dest='lan'

uci add firewall forwarding
uci set firewall.@forwarding[-1].src='wan'
uci set firewall.@forwarding[-1].dest='wg_in'

uci commit firewall
/etc/init.d/firewall restart

В моей домашней схеме OpenWrt уже является gateway для клиентов, поэтому обратный маршрут до 192.168.1.0/24 появляется естественно. Если домашние устройства используют другой gateway, на нем понадобится статический маршрут:

192.168.1.0/24 -> 192.168.0.2

Шаг 11. Проверяем туннель до изменения default route

Вот здесь лучше не спешить. Пока обычная site-to-site связность не работает, заворачивать весь интернет в туннель рано.

На MikroTik:

/interface wireguard peers print detail where interface=wg-openwrt
/ping 10.10.10.1 src-address=10.10.10.2
/ping 192.168.0.2

На OpenWrt:

wg show
ping -c 3 10.10.10.2
ping -c 3 192.168.1.1

Нас интересуют четыре вещи:

есть свежий latest-handshake;
растут rx/tx счетчики;
MikroTik пингует 10.10.10.1;
OpenWrt видит 10.10.10.2 и 192.168.1.1.

Если handshake есть, а IP-связности нет, отдельно проверяем адрес на wg-openwrt, allowed-address, маршруты и firewall. Сам факт handshake еще не означает, что L3 настроен правильно.

Шаг 12. Endpoint WireGuard всегда оставляем через LTE

Перед тем как менять default route, добавляем отдельный маршрут до домашнего публичного адреса:

/ip route
add dst-address=<HOME_PUBLIC_IP>/32 gateway=lte1 comment="Keep OpenWrt WG endpoint via LTE"

Проверяем:

/ip route print detail where dst-address=<HOME_PUBLIC_IP>/32

Это правило должно оставаться через lte1 всегда.

Если его не сделать, после появления default route через WireGuard можно получить петлю: пакеты к endpoint пытаются пойти в туннель, для работы которого сначала надо достучаться до этого же endpoint.

Шаг 13. Сначала добавляем только домашние сети

До переключения всего интернета я сначала сделал обычный site-to-site:

/ip route
add dst-address=192.168.0.0/24 gateway=wg-openwrt comment="Main LAN via OpenWrt"

Если используется тестовая сеть OpenWrt:

/ip route
add dst-address=192.168.50.0/24 gateway=wg-openwrt comment="OpenWrt test LAN via WG"

Проверяем с дачи:

/ping 192.168.0.2
/ping 192.168.0.1

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

Шаг 14. Заворачиваем основной интернет домой

Первый вариант у меня был самым очевидным:

/ip route
add dst-address=0.0.0.0/0 gateway=wg-openwrt distance=1 comment="Default via OpenWrt WG"

Трафик через дом действительно пошел. Но позже выяснилась неприятная деталь: существование интерфейса wg-openwrt еще не означает, что удаленная сторона реально доступна. При проблеме на домашней стороне MikroTik мог продолжать считать маршрут нормальным.

Поэтому этот вариант я заменил.

Старый маршрут удаляем:

/ip route remove [find comment="Default via OpenWrt WG"]

Финальный маршрут:

/ip route
add dst-address=0.0.0.0/0 \
    gateway=10.10.10.1 \
    distance=1 \
    check-gateway=ping \
    comment="Default via OpenWrt WG checked"

LTE default route оставляем с большей distance, например 2.

В результате логика такая:

<HOME_PUBLIC_IP>/32 -> lte1
0.0.0.0/0          -> 10.10.10.1 distance=1 check-gateway=ping
0.0.0.0/0          -> lte1      distance=2

Пока 10.10.10.1 отвечает, основной маршрут идет через дом. Если адрес внутри туннеля перестает отвечать, MikroTik снимает этот маршрут с активного состояния и остается LTE.

Рисунок 3. WireGuard является основным маршрутом, LTE остается рабочим резервом.

Шаг 15. DNS тоже должен переживать падение туннеля

На этом легко получить ситуацию, когда маршрутизация уже переключилась на LTE, ping до 1.1.1.1 идет, а сайты у клиентов все равно не открываются.

Причина простая: если раздать клиентам DNS только на домашней стороне, после падения туннеля он станет недоступен.

Поэтому на даче я использую сам MikroTik как DNS для клиентов:

/ip dns set allow-remote-requests=yes servers=1.1.1.1,8.8.8.8
/ip dhcp-server network set [find address=192.168.1.0/24] dns-server=192.168.1.1

Клиенты всегда обращаются к 192.168.1.1. А уже MikroTik отправляет DNS-запрос через текущий активный default route. Есть WireGuard, запрос идет домой. Туннель упал, DNS уходит через LTE вместе с остальным интернетом.

Шаг 16. Проверяем доступ к интерфейсам из дома

Мне хотелось не только отправлять трафик через дом, но и нормально администрировать дачный MikroTik из городской сети.

С OpenWrt проверяем:

ping -c 3 10.10.10.2
ping -c 3 192.168.1.1

Если пинги идут, пробуем WebFig или WinBox:

http://10.10.10.2
http://192.168.1.1
WinBox: 10.10.10.2

Если IP доступен, а WebFig или WinBox нет, смотрим input firewall MikroTik.

Один из простых вариантов:

/interface list member
add list=LAN interface=wg-openwrt comment="Allow management from home via WG"

Либо можно открыть только нужные сервисы:

/ip firewall filter
add chain=input action=accept in-interface=wg-openwrt protocol=tcp dst-port=80,443,8291,22 comment="Allow management from home via WG"

Если ниже уже есть общий drop, разрешающее правило должно стоять выше него.

Сами сервисы проверяем так:

/ip service print

На этом же этапе полезно проверить обратную доступность дачной LAN с домашней стороны:

ping -c 3 192.168.1.1

Если OpenWrt пингует MikroTik, а обычный домашний ПК нет, почти всегда проблема в том, что ПК использует другой gateway. Тогда на основном домашнем роутере нужен маршрут:

192.168.1.0/24 -> 192.168.0.2

Шаг 17. Проверяем внешний IP

Теперь уже можно проверить не только связность, но и реальный путь трафика.

На MikroTik:

/tool fetch url=https://ifconfig.me/ip output=user

Когда WireGuard работает, внешний IP должен соответствовать домашнему выходу. Если на домашнем OpenWrt дальше используется своя выборочная маршрутизация из первой статьи, конкретный адрес может зависеть от того, куда OpenWrt отправляет этот запрос.

После падения WireGuard внешний IP должен стать адресом LTE-оператора.

Именно этот тест оказался удобнее простого ping. Ping показывает, что интернет есть, а внешний IP сразу показывает, через какую сторону он сейчас идет.

Шаг 18. Ломаем WireGuard специально

Проверять failover лучше не ждать до настоящей аварии. Я просто отключил peer руками.

Перед тестом:

/interface wireguard peers print detail where interface=wg-openwrt
/ip route print detail where dst-address=0.0.0.0/0
/tool fetch url=https://ifconfig.me/ip output=user

Должен быть свежий handshake, основной маршрут через 10.10.10.1 и домашний внешний IP.

Отключаем peer:

/interface wireguard peers disable [find interface=wg-openwrt]

check-gateway=ping срабатывает не мгновенно. У меня на переключение уходило порядка 20-40 секунд.

После этого проверяем:

/ip route print detail where dst-address=0.0.0.0/0
/ping 1.1.1.1 count=5
/tool fetch url=https://ifconfig.me/ip output=user

Ожидаемый результат:

WireGuard недоступен
маршрут через 10.10.10.1 перестал быть основным
интернет продолжает работать
внешний IP стал адресом LTE

Теперь возвращаем peer:

/interface wireguard peers enable [find interface=wg-openwrt]

Ждем появления свежего handshake:

/interface wireguard peers print detail where interface=wg-openwrt

И снова:

/ip route print detail where dst-address=0.0.0.0/0
/tool fetch url=https://ifconfig.me/ip output=user

После восстановления 10.10.10.1 снова становится доступен, маршрут с distance=1 возвращается, а трафик снова идет через дом.

Рисунок 4. Проверять лучше слоями: LTE, WireGuard, маршруты, доступность и фактический внешний IP.

Что это дает для цифрового ТВ

Главная причина всей этой конструкции у меня была не только в красивой site-to-site схеме. Хотелось пользоваться дачной сетью так, будто она подключена к дому, в том числе смотреть цифровое ТВ городского провайдера.

После того как default route дачной сети идет через OpenWrt, для обычного unicast-трафика дачные устройства выходят в интернет с домашней стороны. Если ТВ-приложение провайдера проверяет именно адрес домашнего подключения или доступность своих сервисов через домашнюю сеть, это уже дает нужную основу.

При этом я специально не смешивал настройку самого ТВ с настройкой транспорта. Сначала сеть должна стабильно переживать LTE, WireGuard и failover. Если конкретный ТВ-сервис использует multicast, IGMP, отдельный VLAN или приставку с привязкой к L2, это уже следующая задача. И отлаживать ее намного проще, когда базовая связность между дачей и домом уже не вызывает вопросов.

Грабли, на которые я наступил

LTE «подключен» не означает, что с радио все хорошо

Регистрация в сети еще не гарантирует нормальный канал. lte monitor и cell-monitor дали намного больше пользы, чем индикатор уровня сигнала в интерфейсе.

B7 не всегда лучше B3

Номер диапазона сам по себе ничего не гарантирует. Слабый B7 легко проигрывает нормальному B3 по стабильности и реальной скорости.

Cell lock лучше делать только после нескольких замеров

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

Safe Mode может откатить уже рабочую настройку

Он полезен, но после успешной проверки из него надо выйти.

Handshake еще не означает рабочую IP-связность

Отдельно проверяем адрес 10.10.10.2/24, маршруты и firewall.

Endpoint WireGuard нельзя отправлять в сам WireGuard

Маршрут <HOME_PUBLIC_IP>/32 -> lte1 лучше добавить до переключения default route.

Default route через имя интерфейса оказался недостаточным для failover

Рабочий вариант у меня получился через gateway=10.10.10.1 и check-gateway=ping.

DNS тоже участвует в резервировании

Если после падения WG клиенты продолжают использовать DNS только с домашней стороны, внешне это выглядит так, будто LTE fallback не работает.

Финальная схема маршрутов

После всех экспериментов ядро конфигурации стало довольно небольшим:

LTE:
  lte1
  транспорт для WireGuard endpoint
  резервный интернет

WireGuard:
  wg-openwrt
  10.10.10.2/24
  peer -> <HOME_PUBLIC_IP>:51830
  persistent-keepalive=25s

Маршруты:
  <HOME_PUBLIC_IP>/32 -> lte1
  192.168.0.0/24      -> wg-openwrt
  192.168.50.0/24     -> wg-openwrt
  0.0.0.0/0           -> 10.10.10.1 distance=1 check-gateway=ping
  0.0.0.0/0           -> LTE distance=2

DNS клиентов:
  192.168.1.1

Короткий чек-лист

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

# 1. LTE зарегистрирован и параметры выглядят нормально
/interface lte monitor lte1 once

# 2. LTE сам по себе дает интернет
/ping 1.1.1.1 interface=lte1 count=5

# 3. На WireGuard-интерфейсе есть адрес
/ip address print detail where interface=wg-openwrt

# 4. Есть свежий handshake
/interface wireguard peers print detail where interface=wg-openwrt

# 5. MikroTik видит домашний WG-адрес
/ping 10.10.10.1 src-address=10.10.10.2

# 6. Доступна домашняя сеть
/ping 192.168.0.2

# 7. Endpoint WireGuard закреплен через LTE
/ip route print detail where dst-address=<HOME_PUBLIC_IP>/32

# 8. Основной и резервный default route на месте
/ip route print detail where dst-address=0.0.0.0/0

# 9. Смотрим фактический внешний IP
/tool fetch url=https://ifconfig.me/ip output=user

# 10. Отключаем peer и проверяем переход на LTE
/interface wireguard peers disable [find interface=wg-openwrt]

# 11. Возвращаем peer и проверяем возврат домой
/interface wireguard peers enable [find interface=wg-openwrt]

Что получилось в итоге

Дачный MikroTik перестал быть отдельным островом. LTE теперь выполняет сразу две понятные роли: дает транспорт до дома и остается резервным интернетом. Пока WireGuard работает, основной трафик идет через домашний OpenWrt. Если туннель или домашняя сторона пропадают, MikroTik сам возвращается на LTE. Когда WireGuard восстанавливается, основной маршрут снова становится активным.

Плюс домашняя сеть видит дачный MikroTik, поэтому за WebFig или WinBox больше не надо ехать на дачу. А сама связка стала нормальной основой для главной бытовой задачи, ради которой все и начиналось: дать даче доступ к домашним сервисам и цифровому ТВ городского провайдера.

View the original on Хабр →

KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.