Собственный координационный сервер.
Карту — вот что стоит держать у себя.

На вопрос «я хочу, чтобы мои устройства приватно связывались друг с другом» есть три честных ответа, и это руководство — только про один из них. Обычный WireGuard — самый минималистичный: модуль ядра, один конфигурационный файл на узел, никакого демона, кроме самого интерфейса, и ничего не нужно поддерживать в актуальном состоянии, кроме операционной системы. Если ваши устройства — это серверы с фиксированными адресами и их можно пересчитать по пальцам одной руки, остановитесь здесь и читайте вместо этого руководство по WireGuard. В итоге у вас будет меньше кода и короче список того, что может сломаться.

Tailscale — самый масштабный вариант: тот же WireGuard внутри, плюс служба координации, обход NAT, который работает практически из-за любого препятствия, парк ретрансляторов на нескольких континентах, веб-консоль, единый вход и договор поддержки. Это по-настоящему отличное программное обеспечение, и его бесплатного тарифа с запасом хватает на домохозяйство. Цена здесь не в деньгах — она в том, что карта всех ваших устройств и записи о том, откуда каждое из них подключается, живут в базе данных чужой компании.

Headscale — третий ответ, и он более узкий, чем оба предыдущих: независимая реализация координационного сервера с открытым исходным кодом, которую запускаете вы сами, а обращается к ней тот же официальный клиент. Вы сохраняете автоматизацию и обход NAT, но берёте на себя небольшой сервис в эксплуатации, неполный набор функций и обновления, которые нужно читать, а не просто ставить. Не стоит делать вид, что это бесплатно. Взамен вы получаете ровно одну вещь — ту самую, которая важна для этого сайта: карту не держит никто, кроме вас.

Ещё одна вещь, которую стоит решить сейчас, а не потом, потому что она влияет на то, что именно вы будете устанавливать: предназначена ли эта сеть только для вас или к ней присоединятся другие люди. Tailnet для одного человека может внутри оставаться полностью открытым, и ничего страшного не случится. Tailnet, в котором есть коллега, подрядчик или член семьи, нуждается в письменных правилах доступа с первой же недели — это шаг 05 — и в том, чтобы у пользователей были раздельные учётные записи, а не один логин на всех. Решить это заранее стоит один абзац; переделывать потом — уже полдня работы.

Headscale и Caddy — и больше ничего. Headscale слушает обычный HTTP внутри сети Docker; Caddy терминирует TLS, получает сертификат при первом запуске и обновляет его без напоминаний. Слушатель метрик остаётся на localhost, потому что это внутренняя отладочная поверхность, а не публичная.

Одно правило прежде, чем открывать файл: закрепите образ на точной версии. Headscale — это программа с версией ниже 1.0, в которой не раз переименовывались ключи конфигурации и подкоманды CLI между минорными релизами. Плавающий тег превращает рутинный перезапуск контейнера в простой сервиса, чья единственная задача — дать вам доступ ко всему остальному.

/srv/headscale/docker-compose.yml

services:
  headscale:
    image: docker.io/headscale/headscale:0.26            # pin it; never :latest
    container_name: headscale
    command: serve
    volumes:
      - ./config:/etc/headscale
      - ./data:/var/lib/headscale
    ports:
      - "3478:3478/udp"                                  # STUN, for your own DERP
    restart: unless-stopped

  caddy:
    image: caddy:2-alpine
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
    restart: unless-stopped

volumes:
  caddy_data:

/srv/headscale/Caddyfile

vpn.example.com {
    reverse_proxy headscale:8080
}

Это и есть вся конфигурация прокси. Caddy говорит по HTTP/2 и без дополнительных указаний повышает уровень долгоживущих соединений, что здесь важно, поскольку каждый клиент держит одно такое соединение открытым для получения обновлений карты. Возьмите пример конфигурационного файла, который поставляется вместе с версией, которую вы закрепили, и отредактируйте его, а не пишите с нуля — файл длинный, большая часть в нём — разумные значения по умолчанию, а важные ключи — вот эти:

/srv/headscale/config/config.yaml — the lines that matter

server_url: https://vpn.example.com          # exactly what clients will dial
listen_addr: 0.0.0.0:8080                    # inside the Docker network only
metrics_listen_addr: 127.0.0.1:9090          # debug surface, keep it local

prefixes:
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48

noise:
  private_key_path: /var/lib/headscale/noise_private.key

database:
  type: sqlite                               # postgres for a large fleet
  sqlite:
    path: /var/lib/headscale/db.sqlite

dns:
  magic_dns: true
  base_domain: ts.example.com                # NOT a parent or child of server_url
  nameservers:
    global:
      - 1.1.1.1                              # replaced by your own in step 05

Запустите его и затем читайте лог, а не гадайте. Если при первом запуске не удаётся получить сертификат или отклоняется DNS-суффикс, потому что он пересекается с именем хоста сервера, — сервис ясно сообщит об этом и остановится.

docker compose up -d
docker compose logs -f headscale

# From your laptop — a control server that is up answers this:
curl -s https://vpn.example.com/health

При первом запуске в /srv/headscale/data генерируется закрытый ключевой материал. Скопируйте его в надёжное место прямо сейчас, до того как зарегистрируется хотя бы одно устройство, и ещё раз — после первой регистрации: потеря этого ключа означает, что каждое устройство отвергнет сервер, которому доверяло, и единственное решение — вручную перерегистрировать их все. Шаг 06 превращает эту копию в настоящую резервную копию.

Tailnet, в котором каждое устройство достаёт до любого другого, уже полезен сам по себе. Три дополнения превращают его из набора туннелей в настоящую сеть, и все три объединяет одна особенность, о которую спотыкаются: клиент анонсирует возможность, а сервер должен её одобрить. Маршрут, который анонсирован, но не одобрен, просто не существует — молча, без предупреждений, — и симптом такой: вы можете пропинговать роутер, но ничего за ним не отвечает.

Маршрутизатор подсети — выводит в tailnet целую локальную сеть. Одна машина в домашней или офисной сети анонсирует диапазон адресов этой сети; после этого любое другое устройство получает доступ к принтерам, NAS и интерфейсам управления за ней — без установки чего-либо ещё там же. Сначала включите форвардинг в ядре, иначе пакеты будут останавливаться на роутере без какого-либо сообщения об ошибке.

# On the machine that sits inside the LAN:
echo 'net.ipv4.ip_forward = 1'          | sudo tee /etc/sysctl.d/99-ts.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-ts.conf
sudo sysctl -p /etc/sysctl.d/99-ts.conf

sudo tailscale up --login-server https://vpn.example.com \
  --advertise-routes=192.168.1.0/24 --accept-routes

# On the control server — approve it, or it does not exist.
# The subcommand moved between releases; check `hs nodes --help` first.
hs nodes list
hs nodes approve-routes --identifier 3 --routes 192.168.1.0/24

Выходной узел — отправляет весь трафик наружу через VPS. Тот же механизм, только с более широким маршрутом: устройство, которое анонсирует себя как выходной узел, предлагает взять на себя весь интернет-трафик другого устройства целиком. В недоверенной сети кафе или отеля это именно то, что нужно, — и это ближайший аналог личного VPN во всём этом руководстве.

# On the VPS that will do the exiting (forwarding must be on, as above):
sudo tailscale up --login-server https://vpn.example.com --advertise-exit-node

# Approve it on the control server, then on the laptop:
tailscale set --exit-node=100.64.0.1 --exit-node-allow-lan-access
tailscale set --exit-node=                    # turn it off again

Выходной узел — это не коммерческий VPN, и не стоит убеждать себя в обратном. Его адрес принадлежит только вам и остаётся стабильным, что отлично работает против слежки в кафе с Wi-Fi, но бесполезно против долгосрочной корреляции активности на разных сайтах — этот компромисс подробно разобран в основном руководстве. Обратите также внимание, что выходной узел можно вынести на второй, более дешёвый VPS и полностью избавить координационный сервер от транзитного трафика.

Правила доступа — напишите их до того, как в сеть войдёт второй человек. Политика по умолчанию — «разрешено всё», и это правильно для tailnet из одного человека, но становится ошибкой, как только в нём появляется кто-то ещё. Политика — это небольшой документ в формате HuJSON: группы пользователей, теги для машин и список правил, которые определяют, какие источники могут достигать каких получателей на каких портах. Укажите в конфигурации путь к файлу, храните файл под системой контроля версий и перезагружайте сервис после каждой правки.

{
  "groups": {
    "group:admin":     ["alice"],
    "group:contractor":["bob"]
  },
  "tagOwners": {
    "tag:server": ["group:admin"],
    "tag:exit":   ["group:admin"]
  },
  "acls": [
    // Admins reach everything.
    { "action": "accept", "src": ["group:admin"], "dst": ["*:*"] },

    // The contractor reaches one machine, on two ports, and nothing else.
    { "action": "accept", "src": ["group:contractor"],
      "dst": ["tag:server:22,443"] }
  ],
  "autoApprovers": {
    "routes":   { "192.168.1.0/24": ["tag:server"] },
    "exitNode": ["tag:exit"]
  }
}

Об этом файле стоит сказать ещё две вещи. Язык политики принадлежит Tailscale, а Headscale реализует лишь большое и постоянно растущее подмножество этого языка, а не весь целиком, — прежде чем полагаться на экзотическое правило, проверяйте документацию для своей версии. И место, где хранится политика, тоже переезжало: в старых релизах путь к ней указывался в конфигурации верхнего уровня, в новых — она сгруппирована в отдельной секции policy с режимом, который умеет хранить правила и в базе данных. Задокументированы оба варианта; важен тот, который поставляется вместе с закреплённой у вас версией.

MagicDNS — короткие имена и собственный резолвер повсюду. Когда MagicDNS включён, каждое устройство откликается на короткое имя внутри суффикса, который вы выбрали на шаге 02, так что ssh nas работает откуда угодно без файла hosts. Вторая половина — куда интереснее: координационный сервер также рассылает каждому клиенту список нейм-серверов, а это значит, что резолвер, который вы построили в руководстве по приватному DNS-резолверу, может обслуживать ваш телефон на мобильном интернете — фильтруя, кэшируя и ничего не логируя, — при этом слушая на адресе tailnet, который вообще не достижим из интернета.

dns:
  magic_dns: true
  base_domain: ts.example.com
  override_local_dns: true          # beat whatever DHCP handed the device
  nameservers:
    global:
      - 100.64.0.5                  # your resolver, on the tailnet

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

Координационный сервер — это публичная именованная точка входа. К нему обращается каждое устройство, поэтому у него есть имя хоста, и это имя хоста попадает в логи certificate transparency в момент выпуска сертификата. Оно обнаруживаемо, даже если вы никогда на него не ссылались, а его адрес — единственная константа, общая для всех ваших устройств. Используйте поддомен имени, которое вы уже публикуете, а не тот, что описывает назначение сервера.

Headscale — это альтернативная реализация, и он этого не скрывает. Его не создаёт и не поддерживает Tailscale, паритет функций изначально неполный, а часть того, что входит в состав их облачного сервиса, — веб-консоль, публичный парк ретрансляторов, отточенные сценарии единого входа, — либо здесь отсутствует вовсе, либо реализована сторонним проектом, который никто не аудировал. Прежде чем строить план вокруг какой-то функции, проверяйте по документации проекта, существует ли она, и относитесь к обновлениям как к отдельной задаче, а не как к фоновому процессу.

Ретрансляторы по умолчанию всё ещё чужие. Пока вы не включите встроенный сервер DERP, соединение, которое не может установиться напрямую, откатывается к публичному парку ретрансляторов. Полезная нагрузка всё так же зашифрована сквозным образом, и прочитать её не может никто, — но сам факт того, что два ваших устройства общаются, и объём этого общения, проходит через инфраструктуру, которая вам не принадлежит. Это та часть цепочки доверия, которую большинство упускает из виду в первый же день.

Выходной узел — это стабильный адрес, а не толпа. Маршрутизация трафика через собственный VPS нейтрализует угрозу со стороны сети кафе и профиля, который строит провайдер. Но она не нейтрализует корреляцию, потому что этот адрес принадлежит только вам и не меняется. Общий адрес коммерческого VPN хуже во всём, кроме одного — того самого, что имеет значение именно для этой угрозы.

Машина всё равно стоит в здании. Арендованный сервер работает на железе в дата-центре с дверями и персоналом. Меняется вот что: не существует индекса ваших устройств на уровне продукта, нет базы данных компании, фиксирующей, откуда подключается каждое устройство, и нет политики конфиденциальности, которую можно переписать в следующем квартале. Не меняется то, что диск физический и находится не у вас дома.

Что вы на самом деле купили, если точно: список всех ваших устройств, запись о том, откуда подключается каждое из них, и полномочие добавлять новые устройства — всё это хранится на машине, которую вы арендуете, не привязывая её ни к какому конкретному имени. Это узкое утверждение, но верное. Оно стоит потраченных денег только в том случае, если шаг 06 выполнен, — уровень управления на собственном хостинге без проверенного восстановления из резервной копии не является улучшением приватности, это просто единая точка отказа с более красивым брендингом.