Конфигурация 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 остается локальным, но имена хостов, соединения с которыми идут через TAILSCALE, разрешаются через exit node. Имена MagicDNS разрешаются локально по карте tailnet. Для соединений, маршрутизируемых через exit node, имена хостов разрешаются через DNS выходного узла (peerapi ExitDNS или резолвер, заданный через exit-dns); установите exit-dns = off, чтобы оставить разрешение локальным. Глобальные резолверы и удалённые split-DNS-резолверы не поддерживаются.

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 минуты.