Вопрос или проблема
Я ищу существующие инструменты, которые позволяют двум компьютерам подключаться к серверу-посреднику, и чтобы посредник передавал информацию на локальную службу на втором компьютере всякий раз, когда первый компьютер отправляет её через TCP/UDP (и передавал ответы обратно).
Длинная версия
Насколько я понимаю, это должно быть примерно так:
- Отдельные приложения для запуска на посреднике и ПК2.
- Посредник ожидает подключения от ПК1 на одном порту и от ПК2 на другом.
- Когда ПК1 подключается к посреднику по TCP, посредник просит ПК2 создать локальный TCP-сокет и подключиться к локальному ip:port (указанному на ПК2).
- Когда ПК1 отправляет пакеты на посредник по UDP, посредник перенаправляет их на ПК2, который создает локальный UDP-сокет (если его еще нет) и отправляет их на локальный ip:port.
- Ответы на локальные сокеты на ПК2 направляются обратно на ПК1 через посредник.
- Когда ПК1 отключается от посредника по TCP, посредник просит ПК2 закрыть локальный TCP-сокет.
- Когда посредник долго не получает никаких UDP-пакетов, он просит ПК2 закрыть локальный UDP-сокет.
Это не кажется особенно сложным для реализации, но я не могу отделаться от ощущения, что это уже было сделано десятки раз, и я не знаю правильного поискового термина.
Контекст и текущие попытки
У моего друга есть “домашний сервер” (читай: его предыдущий ПК), который используется для разнообразных автономных приложений и личных проектов.
Домашняя сеть находится за NAT от интернет-провайдера, поэтому я не могу напрямую подключиться к серверу.
В настоящее время мы используем различные программное обеспечение виртуальных локальных сетей (например, Radmin или ZeroTier), но они не всегда успешно делают пробивку (почему так?), и их запасные варианты реле не особенно высокоэффективны, поэтому результаты варьируются.
В то же время, аренда небольшого сервера где-то между нами двумя стоила бы мне всего несколько долларов в месяц, из-за чего я и задумываюсь об этом.
Ваше описание того, что должно происходить, не совсем правильно, но это неважно: то, что вы описываете в требованиях, действительно, виртуальная частная сеть по функциональности. И существует много VPN-сервисов!
Проблема в том, что публично доступные IPv4-адреса довольно дороги; на самых дешевых виртуальных серверах IPv4-адрес часто не включен в комплект и стоит примерно столько же, сколько вычислительная мощность!
Так что, вам действительно нужен VPN-сервис (если только повышение стоимости электроэнергии не заставляет вашего друга перенести большинство своих услуг домашнего сервера на виртуальный сервер где-то с облачным хостингом, в любом случае. Например, в прошлом году средняя стоимость электроэнергии для потребителей в Центральной Европе составляла около 0.41 € / кВт⋅ч, что означает, что 3.34 Ватт мощности сервера стоит 1€ / месяц). Существуют множество “некриминальных” (обычно не рекламируются в видеороликах на YouTube) VPN-сервисов; возможно, бесплатный тариф такого сервиса, как tailscale (нет связи, я использую часть их технологического стека, но не их услуги) подходит для вас и вашего друга.
.
Ответ или решение
Теория
Вопрос о существовании программного обеспечения, выполняющего роль реле для перенаправления трафика между двумя компьютерами через центральный сервер, касается темы, которая давно интересует пользователей, стремящихся к эффективной и безопасной передаче данных через сети с ограниченным доступом. Основное требование к системам такого рода — это надежная маршрутизация данных между компьютерами в условиях сложных сетевых конфигураций, таких как NAT.
Рассмотрим общие механизмы, которые подойдут для реализации подобной задачи:
-
VPN (Виртуальные частные сети): VPN создает защищенное соединение или "туннель" через сеть Интернет, позволяя устройствам передавать данные, как если бы они находились в одной локальной сети. VPN может обойти ограничения NAT, обеспечивая доступ к данным между устройствами.
-
UDP/TCP туннелирование: Это технологии, где данные, передаваемые одним протоколом, могут быть инкапсулированы в другую передачу. Туннелирование полезно для обхода брандмауэров и NAT.
-
Релейные серверы: Они получают данные от одной машины и передают их другой, обеспечивая связь через сложные и недоступные напрямую сетевые конфигурации.
-
P2P (Peer-to-Peer) и Hole-Punching: Эти технологии пытаются установить прямое соединение между двумя узлами в сети, которые оба находятся за NAT.
Пример
Анализируя вышеупомянутые технологии, можно привести несколько примеров существующих решений, которые уже реализовали указанные стратегии:
-
ZeroTier и Tailscale: Эти платформы используют одноранговые соединения и могут идти через NAT при помощи hole-punching, предоставляя функцию виртуальной сети, как VPN, но с меньше задержкой.
-
ngrok и LocalTunnel: Эти сервисы позволяют создавать туннели для подключения к локальным серверам через публично доступные URL, что особенно полезно для разработчиков, нуждающихся в упреждении NAT и брандмауэров для доступа к локациям.
Применение
Зная теорию и примеры, возникает вопрос, как на практике можно применить такие инструменты для решения задачи пользователя.
-
Анализ потребностей: Начните со строгого анализа требований. В вашем случае, если основная цель — наладить связь между двумя машинами через NAT без потерь производительности, имеет смысл сосредоточиться на проверенных VPN решениях или платформах типа Tailscale, которые используют технологию wireguard для шифрования данных и hole-punching для прямых соединений.
-
Эксперимент с Relay-решениями: Размещение и настройка собственного релейного сервера, напримплер на VPS, как промежуточное звено, может обеспечивать нужную маршрутизацию пакетов.
-
Экономические аспекты: Кратковременные затраты на аренду VPS могут перекрыть необходимость глубокого апгрейда инфраструктуры. Следует рассмотреть стоимость электричества, затраты на которой ваши и вашего друга сервера могут быть снижены за счет аренды ресурсов.
В действительности, архитектура подобной системы может быть сложной в реализации и вопрос о существовании целей и готовности инвестировать время и ресурсы должен быть центральным во всем процессе принятия решения. Примите во внимание также, что важным является не только функционирование системы в обычных условиях, но и ее поведение в случаях аномалий, сбоев или перегрузок, что еще раз подводит нас к важности использования проверенных решений с разработанными и протестированными стратегиями резервного копирования и отказоустойчивости.