Вариант произвольного доступа к настройкам и записям автомобильного регистратора из любой точки интернета

Автомобильные видеорегистраторы уже достаточно давно стали одним из обязательных атрибутов для любого автомобилиста. Лично я без тени преувеличения могу заключить, что не могу чувствовать себя в безопасности за рулём без такого простого гаджета. Разумеется, за последние 10 лет прогресс серьёзно продвинулся: сегодня на рынке уже достаточно много производителей, выпускающих достойные модели, и нам, водителям, уже есть из чего выбрать.

Мой выбор пал на регистратор Neoline G-Tech X53, и тому было несколько причин:

• он укомплектован двумя камерами, одна из которых даёт настоящую FullHD картинку,
• он спроектирован специально для скрытной установки,
• он полностью управляется по WiFi через приложение на смартфоне, что немаловажно в контексте данной статьи, и кроме прочего это даёт возможность по-настоящему скрытной установки без потребности периодически лазить или доставать блок (например, чтобы скопировать запись с флешки).

Затем, как это часто бывает, аппетит пришёл во время еды. После установки регистратора в машину я оценил его удобство, вошёл во вкус, и мне захотелось, чтобы доступ к его записям у меня был не только рядом с машиной, где ловится сигнал его WiFi, а вообще везде. Ну, или хотя бы дома, для начала.

Конечно, в природе существуют модели регистраторов, которые по команде сливают записи в облако, но они привязывают пользователя к этому облаку и вынуждают платить за него, а это не мой вариант. Кроме того, моя хотелка хорошо накладывалась на планы установки в машину WiFi роутера с модемом, так что задача выглядела вполне выполнимой.

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


То есть мне предстояло понять, чего хочет приложение от WiFi, и заставить его «увидеть» регистратор, расположенный совсем в другом месте, с решением всех сопутствующих технических загвоздок — в общем, всё, как я люблю.

В качестве маршрутизатора, раздающего в машине интернет через WiFi, я использовал Mikrotik RBmAP2nD (mAP) с модемом Huawei e3372h (если вы знаете другие бюджетные варианты, на которых можно реализовать конфигурации, описанные ниже — напишите в комментариях). Поскольку регистратор умеет только раздавать свой WiFi и не умеет подключаться к уже имеющейся AP, пришлось настраивать AP-Client, который должен к нему подключаться. И тут достаточно быстро выяснилось, что работа Mikrotik в качестве одновременно AP и AP-Client (на slave-интерфейсе) приводит к нестабильной раздаче WiFi, поэтому было решено поставить в пару к основному роутеру ещё один — Mikrotik RBmAPL-2nD (mAP lite).

Обманываем приложение

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

Не буду подробно описывать десятки экспериментов, в ходе которых я пришёл к рабочему решению, просто опишу это решение. Итак, что нужно, чтобы приложение опознало WiFi регистратора:

1. SSID должен иметь вид "G-Tech X5X-120...", где вместо последних точек — произвольные цифры (маленькие буквы) в шестнадцатеричной системе счисления. Для примера, я устанавливал "G-Tech X5X-120aaa" и так далее. Возможно, вместо «120» тоже можно ставить что-то своё, я не пробовал.
2. Адрес клиента должен быть получен по DHCP, должен находиться в подсети 192.168.100.0/24, адрес сервера (регистратора) = 192.168.100.1.

Остальное не принципиально. Многое другое не пробовал, но точно знаю, что:

1. MAC-адрес AP и сервера не имеют значения.
2. Если на пути следования трафика есть участки с пониженным MTU (например, тоннели), связь работает нормально.
3. TCP Window достаточно широкое, чтобы скачивание записей не замедлялось при пингах даже под 300мс и выше.

Итак, что в сухом остатке?

• Приложение хочет иметь адрес в сети 192.168.100.0/24 и соединяться с адресом 192.168.100.1.
• У регистратора адрес тоже 192.168.100.1 и он хочет, чтобы клиент был в сети 192.168.100.0/24 (на другие у него просто нет маршрутов).

Это не поменять, но мы ведь хотим научиться разносить приложение и регистратор. Значит надо присвоить роутеру, раздающему WiFi, адрес 192.168.100.1, а для решения возникающих проблем с маршрутизацией трафика надо ввести стыковочную подсеть и добавить немного сетевой магии. Например, так:


Описание:

• Приложение работает на смартфоне, который подключен к маршрутизатору R1. Смартфон получает адрес по DHCP, в нашем примере это 192.168.100.100.
• IP-адрес R1 на интерфейсе WiFi — 192.168.100.1 (как хочет приложение), на Ethernet-интерфейсе — 192.168.99.1 (это стыковочная подсеть).
• IP-адрес R2 на Ethernet-интерфейсе — 192.168.99.2, на WiFi интерфейсе — получается по DHCP от регистратора, в нашем примере это 192.168.100.150.
• Каждый маршрутизатор выполняет DNAT на входе и SNAT на выходе, таким образом пакеты в каждой подсети имеют адреса источника и назначения, совпадающие с адресами граничных маршрутизаторов этой сети.

Как происходит соединение:

1. Приложение убеждается в том, что оно подключено к WiFi регистратора, и инициирует соединение с адресом 192.168.100.1, полагая, что это адрес регистратора.
2. R1 принимает запрос на соединение, выполняя на входящем интерфейсе DNAT с подменой адреса назначения на 192.168.99.2, а на исходящем интерфейсе — SNAT с подменой адреса источника на 192.168.99.1.
3. R2 принимает запрос на соединение, выполняя на входящем интерфейсе DNAT с подменой адреса назначения на 192.168.100.1, а на исходящем интерфейсе — masquerade с подменой адреса источника на адрес, полученный по DHCP от регистратора.
4. Регистратор принимает и обрабатывает запрос на соединение, пришедший от адреса, который он ранее выдал по DHCP. Что и требовалось.

У вдумчивого читателя уже возник вопрос: для какого именно трафика делать перенаправление? Начав со «всего трафика, кроме ssh» и включив логирование, я дознался, что достаточно перенаправлять tcp-порты 7777, 7778 и 7779. Ничего другого приложению для работы с регистратором не нужно.

Пропускаем трафик через интернет

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

Дома, как вы наверное уже догадались, у меня тоже стоит Mikrotik. У внешнего маршрутизатора — «белый» ip-адрес, и я этим воспользовался, чтобы создать L2TP-тоннель между автомобильным и домашним роутерами и организовать между ними ещё одну стыковочную подсеть. В схему, которую я описал выше, добавился ещё один маршрутизатор, и теперь она упрощённо выглядит так:


Описание:

• Приложение работает на смартфоне, который подключен к домашнему маршрутизатору R0. Смартфон получает адрес по DHCP, в нашем примере это 192.168.100.100.
• IP-адрес R0 на интерфейсе WiFi — 192.168.100.1 (как хочет приложение), на L2TP-интерфейсе — 192.168.98.1 (стыковочная подсеть 0).
• IP-адрес R1 на интерфейсе L2TP — 192.168.98.2, на Ethernet-интерфейсе — 192.168.99.1 (стыковочная подсеть 1).
• IP-адрес R2 на Ethernet-интерфейсе — 192.168.99.2, на WiFi интерфейсе — получается по DHCP от регистратора, в нашем примере это 192.168.100.150.
• Каждый маршрутизатор выполняет DNAT на входе и SNAT на выходе, таким образом пакеты в каждой подсети имеют адреса источника и назначения, совпадающие с адресами граничных маршрутизаторов этой сети.

Как происходит соединение:

1. Приложение убеждается в том, что оно подключено к WiFi регистратора, и инициирует соединение с адресом 192.168.100.1, полагая, что это адрес регистратора.
2. R0 принимает запрос на соединение, выполняя на входящем интерфейсе DNAT с подменой адреса назначения на 192.168.98.2, а на исходящем интерфейсе — SNAT с подменой адреса источника на 192.168.98.1.
3. R1 принимает запрос на соединение, выполняя на входящем интерфейсе DNAT с подменой адреса назначения на 192.168.99.2, а на исходящем интерфейсе — SNAT с подменой адреса источника на 192.168.99.1.
4. R2 принимает запрос на соединение, выполняя на входящем интерфейсе DNAT с подменой адреса назначения на 192.168.100.1, а на исходящем интерфейсе — masquerade с подменой адреса источника на адрес, полученный по DHCP от регистратора.
5. Регистратор принимает и обрабатывает запрос на соединение, пришедший от адреса, который он ранее выдал по DHCP. Что и требовалось.

А откуда берём питание?

Маршрутизаторы и модем потребляют немного, но достаточно, чтобы за 3-4 дня высосать автомобильный аккумулятор в ноль. Поэтому включать их лучше по требованию. А чтобы это вписывалось в концепцию «доступа в произвольный момент времени», я воспользовался тем фактом, что установленная в моей машине сигнализация Starline A96 имеет кроме прочего GSM-модуль, запрограммировал включение доп.канала по команде с пульта или приложения смартфона и запитал маршрутизатор mAP с доп.канала, а mAP lite — через PoE с первого. Рассказывать об этом здесь я подробно не буду, всё это легко гуглится, но если интересно — напишите в комментах.

Итоги

Сделав всё это, я получил возможность не только копировать записи регистратора, сидя при этом дома, а ещё и смотреть картинки с камер в режиме реального времени. И всё это вне зависимости от того, где находится автомобиль, главное — чтобы у его маршрутизатора была связь с интернетом. Разве это не прекрасно?

А ещё приятным бонусом получил более высокую скорость копирования видеозаписей, нежели сидя в машине: 1.2-1.5 мб/с против 1 мб/с. Не знаю, почему.

А конфиги будут?

Честно признаться, не думаю, что кому-нибудь придёт в голову делать в точности то, что описано. В любом случае будет некая адаптация решения к тому, что уже имеется. Но если сильно нужно — ниже вы найдёте правила nat, на которых реализовано 99% всего того, о чём шла речь выше.