Как я превратил сетевое хранилище в маршрутизатор подсети Tailscale для удаленного доступа

Подробности изложены в материале первоисточника. Я перепробовал множество виртуальных частных сетей вроде NetBird, ZeroTier и Headscale, однако во всех моих конфигурациях сохранялась одна и та же проблема. Если на определенном оборудовании не установлен клиентский софт, достучаться до него удаленно не получалось. Настройка маршрутизатора подсети в Tailscale наконец-то помогла мне решить эту задачу во время поездок.

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

Почему именно сетевое хранилище стало шлюзом

Моя домашняя сетевая топология довольно проста: пара интернет-провайдеров заведена на маршрутизатор TP-Link ER605, от которого сигнал идет на коммутатор TP-Link SG108E, раздающий интернет на сервер, хранилище, ПК и роутер TP-Link Archer C6. Устройства с установленным клиентом доступны отовсюду, а вот прочая периферия оставалась изолированной. После того как мое хранилище превратилось в маршрутизатор подсети Tailscale, мне стали доступны сетевой экран, коммутаторы и даже административная панель ONT-терминала провайдера.

Такой эффект достигнут благодаря тому, что узел хранилища начал рекламировать весь локальный пул IP-адресов в общей ячеистой сети. Теоретически роль шлюза мог бы взять на себя домашний сервер с более производительным «железом», но я постоянно провожу на нем рискованные эксперименты, способные надолго уронить систему. Напротив, NAS в моем домашнем лабораторном стенде выполняет лишь роль хранилища данных, работает стабильно, а официальный пакет Synology Tailscale существенно упрощает его администрирование.

Трудности при первичной настройке

Инсталляция клиентского приложения занимает минимум времени, однако запуск NAS в качестве маршрутизатора подсети потребовал преодоления нескольких мелких препятствий. Сперва я столкнулся с тем, что стандартная страница конфигурации Tailscale в веб-интерфейсе DSM по умолчанию открывается исключительно в режиме просмотра. Раздел Subnet Router там присутствовал, но изменить параметры или добавить новые маршруты через него не получалось.

Проблема решалась быстро: достаточно было подключиться к Tailscale с персонального компьютера, а затем открыть эту же панель по внутреннему IP-адресу сети. Альтернативным и еще более простым методом для меня стало подключение к хранилищу через SSH с последующим вводом команды рекламного маршрута нужной подсети. После добавления подсети ее потребовалось вручную подтвердить в консоли управления Tailscale.

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

Производительность, нюансы и скрытые издержки

Тестирование реальной работы в повседневных сценариях выявило определенные издержки. В частности, проверка скорости копирования крупного медиафайла объемом около 1,7 ГБ через SMB-шар при включенном мобильном интернете заняла почти девять минут, в то время как по локальному Wi-Fi та же операция завершилась менее чем за минуту. При этом замеры на мобильном устройстве демонстрировали более высокую скорость входящего и исходящего соединения, чем домашняя сеть, исключая ограничения со стороны канала связи.

Статус подключения показывал прямое соединение iPhone с хранилищем без промежуточных релейных серверов, однако нагрузка на процессор NAS во время передачи данных возрастала до семидесяти процентов. Кроме того, при открытии медиасервера Jellyfin через мобильный браузер система стала фиксировать все сеансы с IP-адресом самого сетевого хранилища, что затрудняет идентификацию конкретных клиентских устройств в логах.

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