SMKot

Про Умный Дом с различных сторон

Два роутера — не враги, а друзья: как заставить их дружить по-соседски

Валерий Вотяков

У меня дома живёт целая сетевая экосистема — как в зоопарке, только вместо тигров и панд тут роутеры, модемы и IoT-гаджеты:
USB-модем Fibocom L860 подключён к маршрутизатору Cudy TR-3000 (прошивка OpenWRT 24.10.2, локальная сеть — 192.168.254.x), а Cudy, в свою очередь, соединён по кабелю с Keenetic Giga 1011 (прошивка 4.3.4, сеть — 192.168.0.x). Кабель вставлен в LAN-порт Cudy и WAN-порт Keenetic — как и положено в схеме «роутер за роутером».

Каждый из этих роутеров — не просто ретранслятор Wi-Fi, а полноценный маршрутизатор со своим DHCP-сервером, своими клиентами, серверами, IoT-устройствами и кучей сервисов. То есть, по сути, у меня два независимых «царства» — и каждое правит своей сетью.

Хочется, чтобы они хотя бы кивнули друг другу. Чтобы сервер на Cudy мог заглянуть в гости к камере на Keenetic или синхронизироваться с NAS’ом.

На первый взгляд — всё просто: соединил кабелем два роутера, и вуаля! А вот и нет. По умолчанию каждый роутер считает свою сеть священной и неприкосновенной. Он не просто не знает о соседе — он даже не догадывается, что тот существует. И трафик между 192.168.254.x и 192.168.0.x просто… испаряется. Как будто его и не было. Просто исчез, как бутерброд из холодильника в студенческой общаге.

По умолчанию каждый роутер считает свою сеть священной территорией. Он не просто не знает о соседе — он даже не подозревает, что тот существует.
И трафик между 192.168.254.x и 192.168.0.x благополучно теряется в цифровой пустоте.

На форумах, конечно, советуют: «Сделай один роутер мостом!»

Что ж, можно и ампутировать руку, если болит нога. Но зачем? Мне важно, чтобы оба роутера оставались автономными — чтобы Keenetic управлял своей сетью, а Cudy — своей.

Я хочу дружбы, а не поглощения.

После долгих поисков и кучи чашек кофе я нашёл простое и элегантное решение. Оно:

  • не ломает текущую работу сетей
  • не трогает DHCP-серверы
  • не требует перевода роутеров в режим моста

Итак, погнали делать хорошо!

🌐 Шаг 1. Cudy узнаёт, где живёт Keenetic

Чтобы Cudy мог отправлять трафик в сеть Keenetic, ему нужно знать: «Куда стучаться?» Для этого Keenetic должен всегда получать один и тот же IP-адрес в сети Cudy — например, 192.168.254.2.

Почему? Потому что мы будем использовать этот адрес как шлюз в статическом маршруте. Если IP изменится — маршрут сломается, и пакеты снова полетят в никуда. А нам это не надо. Мы же не телепортируем данные в параллельную вселенную.

Лучший способ — закрепить IP по MAC-адресу.

MAC-адрес — это как цифровой отпечаток пальца роутера. Уникальный, надёжный и не меняется от перезагрузки. Проще всего найти его на наклейке снизу Keenetic — ищем строку «MAC» или «WAN MAC». Выглядит он примерно так: AA:BB:CC:DD:EE:FF. 💡

Теперь заходим по SSH на Cudy и открываем конфиг DHCP:

nano /etc/config/dhcp

В самом конце этого файла вставляем такую секцию (Внимание! Обязательно подставляем реальный mac-адрес):

config host
        option name 'Keenetic'
        option mac 'AA:BB:CC:DD:EE:FF'
        option ip '192.168.254.2'

Что это даёт?
Теперь, как только Keenetic подключится, Cudy узнает его по MAC и выдаст ровно тот IP, который мы хотим.
Как старый друг, который всегда ждёт с чаем и правильным стулом.

Сохраняем файл (Мы ведь помним как это делали в прошлых статьях? Нет? Напомню: «Ctrl+O → Enter → Ctrl+X«) и перезапускаем DHCP-сервер, чтобы изменения вступили в силу:

/etc/init.d/dnsmasq restart

Теперь — самое интересное. Открываем сетевой конфиг Cudy:

nano /etc/config/network

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

config route 'to_keenetic_lan'
        option interface 'lan'
        option target '192.168.0.0'
        option netmask '255.255.255.0'
        option gateway '192.168.254.2'

Мы словно объясняем Cudy:
«Если кто-то из твоей сети (192.168.254.x) захочет попасть в 192.168.0.x — не паникуй. Не выбрасывай пакеты в корзину. Отдай их по адресу 192.168.254.2 — это Keenetic, он разберётся«.
Это и есть статический маршрут — как дорожный указатель для пакетов.

⚠️ Важно: форматирование в этом файле — святое. OpenWRT очень чувствителен к отступам.
Смотри, как оформлены другие строки. Обычно — 8 пробелов или табуляция. Если ошибиться — роутер проигнорирует настройку, и можно будет часами гадать, почему «ничего не работает». (Да, я прошёл через это. Не стоит повторять моих ошибок.)

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

/etc/init.d/network restart

Маршрут активирован. Cudy теперь знает, куда вести трафик.

Осталось убедиться, что Keenetic не хлопнет дверью.

🛠️ Шаг 2. Убеждаем Keenetic быть гостеприимным

Теперь перейдём к Keenetic. Он-то как раз и не пускает «чужаков» из сети Cudy. По умолчанию он считает: «Если ты не из моей сети — ты подозрительный». И просто молча отбрасывает пакеты. Как будто их и не было.

Чтобы это исправить, нам нужно заглянуть внутрь — в командную строку или, как её ещё называют, CLI (Command Line Interface).

Для этого воспользуемся Telnet — простым и старым, как мир, способом подключения к сетевым устройствам. Представьте, что Telnet — это обычный разговор по телефону без шифрования: всё, что вы говорите, могут подслушать, если стоят рядом. Именно поэтому старайтесь использовать его только в доверенной сети.

А чем Telnet отличается от SSH? SSH — это тот же разговор, но уже в защищённом тоннеле, как шифрованное сообщение. Безопаснее, но на Keenetic часто требует дополнительной настройки. Telnet же включается «из коробки» — как старый добрый телефон с проводом. Не самый модный, но работает.

Но у Keenetic SSH по умолчанию может быть выключен, а Telnet — уже ждёт, как старый друг.

  1. Открываем терминал: cmd, PowerShell, Terminal — не важно.
  2. Вводим: telnet 192.168.0.1 (или ваш IP Keenetic).
  3. Логин и пароль — как от веб-интерфейса.

Добро пожаловать в внутренний мир роутеров — где время течёт по-другому, каждая команда — как шаг в древнем ритуале, где байты носятся как курьеры в час пик, а каждый пакет мечтает стать частью чего-то большего. Здесь нет иконок, только слова. Но зато здесь — настоящая власть.

Теперь просто копируем и вставляем в терминал следующие строки:

access-list _WEBADMIN_ISP
permit ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
exit
system configuration save
exit

Разберём, что тут происходит:

  • access-list _WEBADMIN_ISP — открываем список правил, который по умолчанию блокирует «чужие» подключения.
  • permit ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 — говорим: «Разрешить всё. Всем. Отовсюду». Да, это как открыть дверь и крикнуть: «Заходите, у нас вечеринка!» Но в нашем случае это безопасно — мы же в локальной сети, и все устройства доверенные.
  • exit — выходим из режима редактирования.
  • system configuration save — очень важно. Сохраняем изменения навсегда. Без этого — всё пропадёт при перезагрузке.
  • exit — выходим из командной строки.

Теперь Keenetic больше не игнорирует трафик. Он его принимает, обрабатывает и, при необходимости, отвечает. Дверь открыта. Дипломатия победила.

🎉 Что у нас получилось?

  • Устройства в сети Cudy (192.168.254.x) могут обращаться к устройствам в сети Keenetic (192.168.0.x).
  • Keenetic отвечает им — без лишних подозрений. Он больше не игнорирует «чужие» пакеты — он их принимает и отвечает.
  • Оба роутера продолжают работать автономно, с собственными DHCP, настройками и зоной ответственности.

Теперь мои роутеры не просто соседи — они компаньоны по сети. И если бы они могли разговаривать, я бы слышал что-то вроде:

  • «Привет, Cudy! Как дела на той стороне кабеля?«
  • «Отлично, Keenetic! NAS у тебя на месте? У меня тут бэкап ждёт…«

И да пребудет с нами стабильное соединение! 🌐✨

Последние