gRPC, базы данных и сырые сокеты: Проброс TCP-портов в TunnelHunt

Большинство туннелей работают только с HTTP/HTTPS. Рассказываем, как с помощью TunnelHunt пробросить сырой TCP-порт для отладки баз данных (PostgreSQL, Redis) и тестирования gRPC-сервисов.

Большинство статей про туннелирование и проброс портов (включая инструкции к Ngrok или Localtunnel) крутятся вокруг веб-разработки. Нам показывают, как пробросить порт 80 или 3000, чтобы получить красивую ссылку https://my-site.tunnelhunt.ru и показать ее клиенту или протестировать простой API-интерфейс.

Но реальная разработка — это не только веб-страницы. Что делать, если вам нужно:

Подключиться к локальной базе данных PostgreSQL на домашнем компьютере, находясь в коворкинге?
Отладить микросервисное взаимодействие по протоколу gRPC?
Протестировать работу IoT-устройства, передающего данные по кастомному бинарному протоколу поверх TCP?

Обычные HTTP-туннели здесь бессильны, так как они ожидают стандартные HTTP/1.1 заголовки и ломаются при попытке передать сырой поток байт. В этой статье мы разберем, как пробрасывать сырые TCP-порты с помощью TunnelHunt без боли и установки лишнего софта.

🛠 Чем TCP-туннели отличаются от HTTP?

Когда вы пробрасываете HTTP-туннель:

[Клиент] ---> [HTTPS: Nginx Edge Proxy] ---> [Go SSH Server] ---> [Ваш localhost:3000]

Nginx парсит HTTP-запрос, считывает Host-заголовок (например, sleepy-owl.tunnelhunt.ru) и понимает, какому именно SSH-соединению передать этот трафик. На одном IP-адресе сервера могут жить тысячи HTTP-туннелей, использующих стандартные порты 80 и 443.

С сырым TCP так сделать нельзя. В TCP-пакетах нет прикладного заголовка вроде “Host”. Сервер не знает, кому адресован пришедший поток байт, пока не посмотрит на номер входящего порта.

Поэтому для TCP-туннелирования TunnelHunt выделяет вам персональный выделенный порт на своем сервере (например, 15432). Любой трафик, пришедший на tunnelhunt.ru:15432, будет перенаправлен на указанный вами локальный порт.

💾 Сценарий 1: Проброс базы данных (PostgreSQL / Redis)

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

Шаг 1. Резервирование TCP-порта

Поскольку порты — ограниченный ресурс, в TunnelHunt резервирование TCP-порта происходит через дашборд.

Зайдите в личный кабинет.
Перейдите во вкладку TCP Ports.
Нажмите Reserve Port. Сервер выделит вам порт (допустим, 15432).

Шаг 2. Запуск туннеля через SSH

Теперь свяжем выделенный порт на сервере с локальным портом вашей базы данных (для PostgreSQL по умолчанию это 5432):

ssh -p 2222 -R 15432:localhost:5432 tunnelhunt.ru

Шаг 3. Подключение

Теперь ваша локальная БД доступна из любой точки мира. Вы можете подключиться к ней с помощью любой утилиты (например, DBeaver или pgAdmin), указав параметры:

Host: tunnelhunt.ru
Port: 15432
User/Password: ваши локальные доступы к PostgreSQL.

[!WARNING] Открывая доступ к базе данных во внешний мир, убедитесь, что у вас установлен надежный пароль и в файле pg_hba.conf включена безопасная авторизация.

📡 Сценарий 2: Отладка gRPC-сервисов

gRPC завоевал мир микросервисов благодаря производительности и кодогенерации. Он работает поверх протокола HTTP/2.

Большинство обычных HTTP-туннелей (работающих по схеме HTTP/1.1 -> HTTP/2) не умеют корректно обрабатывать стриминг, специфичные gRPC-заголовки и постоянные TCP-соединения. Из-за этого при попытке пробросить gRPC-сервер через стандартный HTTP-туннель вы будете получать ошибки протокола.

Решение — пробросить gRPC как сырой TCP-трафик.

Допустим, ваш gRPC-сервер запущен локально на порту 50051.

Запустите туннель (используя зарезервированный на шаге 1 порт 15432):
```
ssh -p 2222 -R 15432:localhost:50051 tunnelhunt.ru
```
В коде вашего gRPC-клиента на удаленной машине укажите адрес подключения:
```
conn, err := grpc.Dial("tunnelhunt.ru:15432", grpc.WithInsecure())
```

Теперь gRPC-клиент и сервер общаются напрямую, транслируя чистый HTTP/2 поток без искажений со стороны промежуточных прокси-серверов.

🎮 Сценарий 3: Локальный игровой сервер или IoT

Вы разрабатываете сетевую игру (например, на Unity или Unreal Engine) и хотите протестировать мультиплеер с другом, не собирая билд под выделенный сервер в облаке?

Или вы пишете прошивку для микроконтроллера ESP32, которая отправляет пакеты по TCP на ваш локальный сервер сбора метрик?

Схема остается прежней:

Запускаете локальный сервер (например, порт 7777 для игры).
Поднимаете туннель: ssh -p 2222 -R 15432:localhost:7777 tunnelhunt.ru.
Друг указывает в настройках подключения tunnelhunt.ru:15432 и мгновенно подключается к вашей игре.

💡 Резюме

TunnelHunt доказывает, что стандартный SSH-клиент способен решать сложнейшие задачи сетевой инфраструктуры. Больше не нужно настраивать VPN, мучаться с DDNS или покупать статические IP-адреса у провайдера.

Проброс сырого TCP открывает возможности для тестирования баз данных, gRPC, веб-сокетов и любых кастомных протоколов в один клик.

Попробуйте TCP-туннелирование в дашборде TunnelHunt.