Своя self-hosted двухсерверная VPN-архитектура. Подробный путь разработки и ошибки, с которыми вы можете столкнуться

В сфере искусственного интеллекта произошло заметное событие. ITsuperiorRF 5 минут назад Своя self-hosted двухсерверная VPN-архитектура. Подробный путь разработки и ошибки, с которыми вы можете столкнуться Сложный 19 мин 44 DevOps * Системное администрирование * Серверное администрирование * Программирование * Linux * Кейс Из песочницы Всё началось с того, что меня перестал устраивать мой подход к развертыванию личных сервисов. Я решил переписать всё с нуля.

К тому же это был отличный повод получить новые навыки и попробовать инструменты, до которых давно не доходили руки. Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

Технические детали

Пройдя путь от простых Bash-скриптов и сторонних туннелей до полностью автоматизированной инфраструктуры, я создал проект ServeHub-2. В этой статье я подробно разберу, как эволюционировала сеть проекта, почему декларативный подход победил императивный и с какими неочевидными багами пришлось столкнуться в процессе автоматизации. История настройки сетевой архитектурыИспользование TunaВ самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система.

Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка.

Однако для полноценной независимой архитектуры он не подошел по двум причинам:Сервера Tuna находятся вне контроля пользователя. На удаленном сервере нельзя развернуть свои сопутствующие сервисы. В целом сервис действительно удобный, но для моих задач он оказался слишком ограничивающим.

Отраслевые последствия

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):tuna_matrix: container_name: tuna_matrix image: yuccastream/tuna:latest restart: always environment: - TUNA_TOKEN=${TUNA_TOKEN} - SYNAPSE_SERVER_NAME=${SYNAPSE_SERVER_NAME} command: http nginx:80 --domain=${SYNAPSE_SERVER_NAME} --https-redirect depends_on: - nginx tuna_ssh: container_name: tuna_ssh image: yuccastream/tuna:latest restart: always network_mode: "host" environment: - TUNA_TOKEN=${TUNA_TOKEN} command: tcp 22 --port=${TUNA_SSH_PORT} В поисках гибкости: тесты Pangolin и переход к FRPПосле Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами.

Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна. На смену пришел FRP (Fast Reverse Proxy).

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.