HTTP туннель

HTTP туннели работают на всех тарифных планах, но на бесплатном тарифе доступны только туннели с динамически выделяемым именем и ограничены работой в 30 минут.

Обзор

HTTP туннель позволяет предоставить доступ к сайту, API, GraphQL и Websocket-серверам.

Примеры

примечание

Все актуальные флаги, подсказки и примеры можно посмотреть вызвав справку:

tuna http --help

Почти для всех флагов есть аналогичные переменные окружения.

Базовый пример

Запуск туннеля с динамическим именем.

tuna http 8080

С передачей IP-адреса или Host

tuna http 10.0.0.1:8080

tuna http localhost:8080

Подключение к HTTPS ресурсу

tuna http https://localhost:443

Если нужно проверять валидность сертификата, то укажите --tls-skip-verify=false, по умолчанию принимается любой самоподписанный сертификат.

С зарезервированным поддоменом

к сведению

Доступно только по подписке.

Можно резервировать адреса и после перезапуска туннеля адрес останется прежним:

tuna http 8080 --subdomain=billing

В unix системах также можно использовать переменную окружения TUNA_SUBDOMAIN:

TUNA_SUBDOMAIN="billing" tuna http 8080

Внимание

Если вы видите ошибку Domain already reserved, значит домен в этой локации уже занят другим пользователем, попробуйте другое имя.

tuna http 8080 --subdomain=any-you-name

Резервирование происходит автоматически при добавлении аргумента. Все зарезервированные вами домены можно посмотреть в личном кабинете.

С собственным доменом

Добавьте свой домен следуя инструкциям в личном кабинете, после проверки DNS и выпуска Let's Encrypt сертификата можно пользоваться:

tuna http 8080 --domain=my-api-project.example.com

к сведению

Есть подробная статья - Подключение своего домена.

Перенаправление на HTTPS

Запретить обращение по HTTP можно добавив флаг --https-redirect.

Файловый сервер

tuna http --file-server ./

Хостинг статичного SPA сайта

Хостинг одностраничных приложений:

tuna http --file-server-spa ./

WebDAV сервер

tuna http --webdav ./

Изменение заголовков запроса

Добавление заголовка перед тем, как запрос попадет в локальный сервис:

tuna http 8080 --request-header="host:tuna.am"

Изменение заголовков ответа

Добавление заголовка для передачи клиенту (пользователю):

tuna http 8080 --response-header="env:test"

Защита базовой аутентификацией

tuna http 8080 --basic-auth="login:password"

Защита API токеном

tuna http 8080 --key-auth="my-secret-key"

Доступ к ресурсу будет предоставлен только в том случае, если будет передано корректное значение заголовка X-Token.

Rate limiter

Ограничение по числу запросов в секунду, попадаемых в ваш сервис:

tuna http 8080 --rate-limit=2

При достижении лимита будет возвращена ошибка 429 Too Many Requests.

Ограничение доступа по подсетям IP

Вы можете определить белый список подсетей в CIDR-формате:

tuna http 8080 --cidr-allow="10.0.0.1/32"

Либо запретить доступ из определенных подсетей:

tuna http 8080 --cidr-deny="10.0.0.1/32"

Ограничение доступа по User-Agent

Запретить доступ с конкретного user-agent и разрешить со всех остальных, совпадение по подстроке:

--ua-deny=curl

Разрешить доступ с конкретного user-agent и запретить со всех остальных, совпадение по подстроке:

--ua-allow=Chrome

Верификация входящих Webhooks

tuna http 8080 --verify-webhook=gitlab --verify-webhook-secret=1234

С указанием токена

Можно указать специфичный токен через флаг --token или переменную окружения TUNA_TOKEN. Переопределение происходит в соответствии с политикой очерёдности конфигурации.

tuna http 8080 --token=tt_***

С указанием региона для подключения

Можно указать специфичный регион через флаг --location/-l или переменную окружения TUNA_LOCATION. Переопределение происходит в соответствии с политикой очерёдности конфигурации.

tuna http 8080 --location=nl

Генерация QR кода с ссылкой

При добавлении флага --qr для ссылки будет сгенерирован QR код и напечатан в консоли. Это может быть удобно если вы тестируете сайт на мобильном устройстве.

Политики трафика

Флаг --policy-file указывает путь файлу конфигурации с правилами (по умолчанию .tuna.yml).

CORS

Флаг --cors или переменная TUNA_CORS=true, добавит CORS заголовки ко всем ответам. По умолчанию выставляются следующие заголовки:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Accept, Accept-Language, Content-Language, Origin
Access-Control-Allow-Methods: GET, HEAD, POST
Access-Control-Allow-Origin: *

Их можно переопределить с помощью флага --response-header.

Запросы типа OPTIONS обрабатываются автоматически 200 OK, не доходя до проксируемого сервера.

примечание

Если у вас возникают сложности в работе с CORS, рекомендуем ознакомиться с данной статьёй. Так же рекомендуем CORS Tester для проверки ваших CORS заголовков.

Поведение

Hop-by-hop

НЕ поддерживаются hop-by-hop заголовки за исключением заголовка Connection: upgrade, необходимого для работы Websocket соединений.

WebSocket

Поддерживается протокол с двусторонним соединением между клиентом (например, браузером) и сервером, дополнительные настройки не требуются. Передаваемые данные НЕ будут отображены в инспекторе.

Server-sent events

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

примечание

При включенном инспекторе важно, что бы клиент отправлял заголовок Accept: text/event-stream, иначе инспектор будет пытаться перехватить запрос и это вызовет задержки. Браузер передаёт этот заголовок по умолчанию.

HTTP и HTTPS

При старте туннеля отображается ссылка на HTTPS, но обращаться можно и по HTTP. Запретить обращение по HTTP можно добавив флаг --https-redirect.

Порядок обработки флагов и правил

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

1. https-redirect
2. cors
3. cidr-allow
4. cidr-deny
5. ua-allow
6. ua-deny
7. rate-limit
8. key-auth
9. basic-auth
10. policy-file
11. verify-webhook
12. request-header
13. response-header

Самостоятельное управление CORS заголовками

Если вы хотите управлять CORS заголовками самостоятельно на нижестоящем сервере и при этом используете авторизацию в tuna при помощи --basic-auth или --key-auth. То Preflight запросы - не будут работать, так как эти OPTIONS запросы не содержат Authorization, X-Token и любые другие специфичные заголовки.

Решение на выбор:

1. Не использовать авторизацию в tuna.
2. Управлять CORS заголовками в tuna, а не самостоятельно.
3. Обрабатывать OPTIONS и авторизацию отдельно при помощи более гибких политик трафика.

❓ Как это выглядит на схеме

Случай 1

Вы управляете CORS на нижестоящем Caddy сервере и включаете авторизацию в tuna.

Случай 2

Вы управляете CORS на нижестоящем Caddy сервере и НЕ включаете авторизацию в tuna.

Случай 3

Вы управляете CORS и авторизацией в tuna.