Конфигурация Tailscale

Chute включает встроенную нативную поддержку Tailscale. После настройки вы можете ссылаться на встроенную политику TAILSCALE из правил или групп политик, чтобы направлять трафик через ваш tailnet — обращаться к другим устройствам в tailnet, выходить через exit node или обращаться к подсетям, объявленным пирами.

В отличие от обычных прокси-протоколов, Tailscale — это не политика, заданная построчно в [Proxy]; он настраивается через единственный глобально уникальный раздел [Tailscale]. Он регистрирует узел на контрольном сервере с помощью auth key, без интерактивного входа через браузер.

Раздел Tailscale

Раздел [Tailscale] определяет всё, что нужно устройству для подключения к tailnet:

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
control-server = https://controlplane.tailscale.com
hostname = my-device
exit-node = 100.101.102.103
accept-routes = true
force-derp = false

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

Параметры

Логические значения принимают следующие написания (без учёта регистра): true/false, 1/0, yes/no, on/off.

Примечание: неизвестные ключи игнорируются с предупреждением (они не блокируют загрузку конфигурации). Опечатка в ключе (например, force-derp, записанный как force_derp) незаметно отключит эту опцию — сверьтесь с таблицей выше.

Встроенная политика TAILSCALE

После настройки раздела [Tailscale] становится доступным встроенный идентификатор политики TAILSCALE — он стоит в одном ряду с DIRECT и REJECT и может напрямую использоваться в правилах и группах политик. Когда раздел [Tailscale] не настроен или Tailscale выключен, правила, ссылающиеся на TAILSCALE, обрабатываются как REJECT (fail-closed).

[Proxy Group]
Mesh = select, TAILSCALE, DIRECT

[Rule]
IP-CIDR,100.64.0.0/10,TAILSCALE,no-resolve
FINAL,DIRECT

Автоматическая маршрутизация

При включённом Tailscale Chute автоматически инжектирует следующие три правила перед всеми вашими правилами, поэтому обычно не нужно вручную писать правила для доступа к tailnet:

DOMAIN-SUFFIX,ts.net,TAILSCALE
IP-CIDR,100.64.0.0/10,TAILSCALE,no-resolve
IP-CIDR6,fd7a:115c:a1e0::/48,TAILSCALE,no-resolve

Эти инжектированные правила действуют только во время выполнения и никогда не изменяют ваш файл конфигурации. Если установлено accept-routes = true, подсети, объявленные пирами, также автоматически добавляются как соответствующие правила IP-CIDR / IP-CIDR6 и обновляются автоматически при добавлении или отзыве подсетей пирами.

Использование

Доступ к устройствам в tailnet

После настройки раздела [Tailscale] для обращения к другим устройствам в tailnet не нужны дополнительные правила — инжектированные правила уже покрывают диапазоны tailnet и суффикс MagicDNS. Вы можете адресовать пиры напрямую по MagicDNS-имени или IP tailnet:

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
hostname = my-iphone

[Rule]
FINAL,DIRECT

Теперь такие цели, как my-pc.<tailnet>.ts.net или 100.101.102.103, будут автоматически идти через Tailscale.

Выход через exit node

Установите TAILSCALE как цель FINAL, чтобы направить весь трафик, не подпавший под более конкретное правило, через exit node:

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
exit-node = 100.101.102.103

[Rule]
FINAL,TAILSCALE

Примечание: сам по себе параметр exit-node не направляет трафик через выходной узел — необходимо также добавить правило, отправляющее трафик в TAILSCALE (например, FINAL,TAILSCALE). Без такого правила выходной узел настроен, но не используется; редактор конфигурации приложения сообщает об этом.

Приём подсетевых маршрутов

Когда устройство в tailnet выступает как subnet router и объявляет локальные подсети, включите accept-routes = true, чтобы получить доступ к этим подсетям; соответствующие правила маршрутизации инжектируются автоматически:

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
accept-routes = true

Собственный контрольный сервер (Headscale)

Помимо официальной контрольной плоскости, Chute поддерживает самохостинг контрольных серверов Headscale / Ionscale. Просто укажите соответствующий URL:

[Tailscale]
auth-key = your-headscale-preauth-key
control-server = https://headscale.example.com
hostname = my-device

Сторонние контрольные серверы не требуют префикса tskey- и принимают собственные auth key. Использование адреса http:// в открытом виде рекомендуется только в доверенной сети (например, для локального самохостинга Headscale).

Известные ограничения и рекомендации

Реализация Tailscale сосредоточена на возможностях, наиболее часто используемых в прокси-сценариях; некоторые функции официального клиента пока не поддерживаются. Обратите внимание на следующие поведенческие различия:

1. Используйте force-derp = true только для диагностики. Обычно Chute предпочитает прямые UDP-соединения с пирами (disco hole-punching), которые, как правило, обеспечивают меньшую задержку и большую пропускную способность, чем DERP-ретрансляция. Если в конкретной сети прямые соединения постоянно нестабильны или медленнее DERP, сравните оба режима и включайте force-derp только для этой среды.

2. Поддерживается только вход по auth key. SSO / интерактивный вход через браузер, Tailscale SSH, Taildrop и Funnel / serve не поддерживаются. Chute также не может объявлять маршруты локальных подсетей или предоставлять это устройство как exit node; оно подключается только как потребитель.

3. При использовании exit node обычные DNS-запросы разрешаются локально. Chute не отправляет обычные DNS-запросы через выбранный exit node. Имена MagicDNS разрешаются локально по карте tailnet. Глобальные резолверы и удалённые split-DNS-резолверы не поддерживаются; используйте IP-адрес, если частное имя можно разрешить только в удалённой сети.

4. MagicDNS поддерживает только записи A / AAAA. Глобальные Resolvers, split-DNS-маршруты (записи с выделенным резолвером) и не-адресные ExtraRecords (TXT / CNAME / SRV) игнорируются; при обнаружении в лог записывается предупреждение.

5. Внутренний MTU прямого пути фиксирован на 1280. Обнаружения Path MTU нет; это консервативное значение предотвращает чёрные дыры на PPPoE / составных туннельных каналах. Путь через DERP-ретрансляцию не затрагивается.

6. Tailnet Lock (сетевая блокировка) не поддерживается. В tailnet с включённой сетевой блокировкой ключ этого узла не будет подписан, а заблокированные пиры будут незаметно отбрасывать трафик от этого устройства.

7. Mullvad-exit и другие сценарии с перезаписью источника недоступны. Функции exit node, требующие перезаписи локального адреса источника, пока не реализованы.

8. Восстановление после смены сети зависит от системного уведомления. При переключении Wi-Fi / сотовой связи Chute оперативно перестраивает соединения; в редком случае, когда уведомление о смене сети не получено, восстановление откатывается к переподключению по watchdog примерно через 3 минуты.