Hacker News Digest

Tailscale ускоряется за счёт снижения памяти и улучшения обработки пакетов. На Linux и Android теперь не копируются маленькие пакеты (например, 1 KiB) в отдельные 64 KiB буферы — вместо этого они остаются в едином буфере, где их границы помечаются, что экономит память и ускоряет обработку на ~5%. Одновременно сокращены длины очередей пакетов, что уменьшает задержки и освобождает память без потери устойчивости к всплескам трафика. Эти изменения уже частично реализованы и войдут в стабильный релиз v1.104 клиента.

Параллельно разрабатывается мульти-очередная технология для повышения пропускной способности в сценариях с подсетями, коннекторами приложений и выходными узлами — её выпуск запланирован после v1.104. Также тестируется кэширование netmap как флаг функции, которое станет стандартным в v1.104 для десктопов и позже для мобильных клиентов. Чтобы пользователи могли объективно оценивать производительность, Tailscale разрабатывает собственный набор инструментов для мониторинга и тестирования, который будет понимать специфику его сети: distinguish между DERP и прямыми соединениями, оценивать пользу пир-релеев и отслеживать динамику маршрутов — чего не умеют общие утилиты из-за привязки к точкам, жёсткости workflows и отсутствия поддержки QUIC/HTTP/3. Пользователей приглашают повлиять на развитие этого инструментария через опрос.

Tailscale проще в настройке, чем raw WireGuard: автоматизирует NAT-трансверс, DNS и управление ключами, что делает его удобным для не-технических пользователей и динамических сред (CI-джобы). Пользователи отмечают, что он позволяет подключаться к серверам без открытия портов, упрощая безопасный доступ к внутренним сервисам. Однако Tailscale критикуют за производительность на высоких нагрузках и высокое потребление батареи на iOS, что ограничивает его практическое применение. На Windows и macOS скорость не превышает 1 Гбит/с, на Linux — до 10 Гбит/с даже в синтетических тестах, что делает его неконкурентоспособным для высокопроизводительных сценариев. Потребление батареи на iOS вынуждает пользователей вручную управлять подключением, нивелируя преимущества автоматизации. Спор о скорости: некоторые утверждают, что raw WireGuard быстрее и стабильнее, особенно с динамическим DNS; другие отмечают, что Tailscale решает проблемы с забыванием конфигурации и сложностью поддержки после простоя. Также обсуждается отсутствие аппаратного ускорения криптографии в Tailscale, что ограничивает масштабируемость до сотен Гбит/с и может потребовать смены протокола (например, на IPsec с PQ). Однако ChaCha20-Poly1305 в WireGuard уже быстр и может быть оптимизирован через SIMD, что снижает необходимость в аппаратном ускорении. Дополнительные ограничения: Tailscale не поддерживает мультиузловые прокси, требуя отдельных контейнеров для устройств без прямой интеграции; не работает на микроконтроллерах, хотя это было бы идеально для IoT; не позволяет отключать принудительное исключение Android-приложений из VPN без вмешательства разработчика, что противоречит пользовательскому контролю. Предлагается добавить гибкость в выбор маршрутов через DERP (a→b→c) для снижения задержек при невозможности прямого соединения. На Linux и Android оптимизации (устранение копирования малых пакетов, сокращение очередей) дают ~5% прироста производительности, но не применимы на macOS и Windows из-за отсутствия ядерных аналогов. Tailscale уже давно отошёл от спецификации WireGuard, внося собственные улучшения, но создавая разрыв в ожиданиях совместимости. Использование батарейных устройств как exit-узлов неэффективно и противоречит рекомендациям по энергосбережению.

SAML — протокол аутентификации на основе XML, созданный в 2002 году комитетом OASIS из четырёх конкурирующих стандартов — стал основой индустрии единого входа (SSO). Он успешно решал задачу централизованной аутентификации в эпоху роста SaaS, особенно в академии и корпоративной IT, но его сложность оказалась катастрофической: XML-подписи, требующие проверки через непрозрачные библиотеки вроде libxmlsec, стали источником уязвимостей, которые большинство реализаций просто игнорируют. Дизайн «по комитету» привёл к избыточности, а архитектура — к хрупкости, несовместимости и трудностям в поддержке.

Современные альтернативы, особенно OpenID Connect (OIDC) на основе JSON и OAuth 2.0, значительно проще, безопаснее и легче интегрируются. Ведущие компании вроде Fly.io и Tailscale уже отказались от SAML, доказав, что даже для крупных корпоративных клиентов OIDC — жизнеспособный выбор. Для провайдеров идентичности путь отказа от SAML долгий, но пошаговый: остановить новые SAML-интеграции, перевести клиентов на OIDC, назначить дату отключения. SAML заслужил своё место в истории как катализатор SSO, но его пора заменить — как и XML, как и устаревшие подходы, которые больше не оправдывают свою цену.

SAML остается актуальным в корпоративной среде из-за поддержки IdP-инициированных потоков и устойчивости в закрытых сетях, несмотря на свою сложность, а OIDC не решает всех проблем, особенно в условиях изоляции от публичных провайдеров.

• Совет: Для интеграции SAML в JVM-приложения рекомендуется использовать pac4j — он упрощает работу с различными фреймворками и скрывает сложность низкоуровневых деталей.

• SAML и OIDC оба страдают от сложных реализаций: SAML — из-за XMLDSIG и канонизации, OIDC — из-за уязвимостей JWT (none-алгоритм, отсутствие проверки audience).

• Спор: Некоторые утверждают, что SAML уязвим из-за XML-подписей, но другие отмечают, что OIDC с JWT имеет не менее опасные уязвимости, включая возможность смены алгоритма подписи на 'none'.

• Проблема SAML не в XML как таковом — в 2002 году XML был логичным выбором, а альтернативы (ASN.1, кастомный формат) были не проще и не безопаснее.

• Совет: Для enterprise-продуктов поддержка SAML обязательна, так как корпоративные клиенты требуют совместимости с их существующими IdP, и отказ от SAML делает продукт невосприимчивым к рынку.

• SAML поддерживает IdP-инициированные потоки, что критично для корпоративных SSO, тогда как OIDC требует инициации от SP, что не всегда возможно в закрытых сетях.

• Спор: Одни считают, что SAML безопасен благодаря встроенной подписи, защищающей от MITM, другие возражают, что уязвимости в реализациях (например, проверка подписи по HMAC из атакуемого документа) делают его ненадежным.

• Реализации SAML часто ошибочно доверяют всему документу после проверки подписи, а не только подписанной части, что позволяет атакующему вставлять произвольные данные.

• Совет: Для снижения сложности SAML можно поддерживать только дайджесты топ-10 провайдеров и игнорировать нишевые реализации — это уменьшает объем поддержки без потери функциональности.

• Проблемы SAML не в стандарте, а в его реализациях: библиотеки libxml2 и другие неправильно обрабатывают XML-ноды, что позволяет обходить аутентификацию через MITM.

• Совет: Индивидуальные решения вроде IndieAuth и новых паттернов на базе OAuth, FedCM и DIDs обещают децентрализованную аутентификацию, но пока не получили широкой поддержки.

• OIDC не может работать с приватными IdP без публичного доступа, тогда как SAML поддерживает интеграцию в изолированных корпоративных сетях без внешних зависимостей.

• Комитетная разработка SAML привела к 'кухонному ракетостроению' — избыточным функциям, которые усложняют реализацию, в отличие от фокусированных решений вроде WireGuard.

• Совет: При интеграции SAML всегда проверяйте, что подпись применяется только к конкретной части документа, а не ко всему телу — это частая ошибка в реализациях.

• Большинство компаний не хотят поддерживать децентрализованную аутентификацию, потому что предпочитают монетизировать SSO через дополнительные услуги: анти-спам, восстановление паролей, контроль создания аккаунтов.

Tailcat — это утилита от Tailscale, которая позволяет устанавливать зашифрованные соединения между машинами по принципу netcat, но используя только данные плоскости Tailscale (magicsock и DERP), минуя её контрольную плоскость. Это означает, что для работы не нужен аккаунт Tailscale, root-доступ или изменение системных настроек — всё работает в пользовательском пространстве. Трафик шифруется end-to-end через WireGuard, а начальное соединение устанавливается через DERP-релеи (по умолчанию — бесплатные, rate-limited от Tailscale), после чего magicsock пытается перейти на прямое P2P UDP-соединение, если NAT позволяет.

Один запуск tailcat на сервере генерирует одноразовый токен подключения, который клиент использует для установки канала. После этого можно передавать stdin/stdout, пробрасывать локальные TCP-порты (например, --serve=8080) или даже запускать auth-free SSH-сервер через --serve=no-auth-ssh. Утилита также поддерживает пинг с указанием пути (DERP или прямой) и флагом --until-direct для ожидания оптимального маршрута. Проект полностью open source, но без гарантий стабильности API, CLI или работы публичных DERP-релеев — всё предоставляется «как есть». Tailcat возник как эксперимент «derpcat» в 2023 году, был выделен в отдельный модуль и открыт в августе 2026 на конференции TailscaleUp.

**Tailcat** Tailcat — практическое воплощение принципа end-to-end connectivity: использует инфраструктуру Tailscale (magicsock, DERP) без зависимости от её control plane, что позволяет устанавливать P2P-соединения без root-доступа и аккаунтов. Механизм: односторонний обмен ключами через Meow-сообщения по DERP, затем стандартный CallMeMaybe для прямого соединения — полноценная интеграция с внутренними механизмами Tailscale, а не просто обёртка. **Инфраструктура и ограничения** Tailscale сознательно выделил отдельные DERP-серверы для публичного использования с ограничением скорости, чтобы поддерживать открытость без влияния на основную инфраструктуру (Brad Fitzpatrick). Этот rate-limit также ограничивает пригодность Tailcat для C2-каналов (@MajesticHobo2). **Практические сценарии** Tailcat работает в пользовательском пространстве и не требует root-доступа, что делает его удобным для CI/CD, облачных VM и ограниченных систем. Решает проблему P2P-соединений без настройки портов и NAT — особенно ценно в условиях CGNAT и ограниченного IPv6 (@pbohun). Примеры применения: Minecraft-моды, SSH-серверы на systemd, замена WebSocket-прокси в Mosh для прямой работы с UDP-трафиком (@ekarulf). Nix-окружение в репозитории отражает внутреннюю практику Tailscale, где Nix — стандарт разработки, а не опциональный инструмент (@ronef). **Сравнение с аналогами** Tailcat напоминает Magic Wormhole, но расширяет идею с передачи файлов на произвольные TCP-соединения, сохраняя простоту, но без human-readable session IDs (@doomrobo). Среди аналогов — Wush и Iroh, использующие Tailscale или WireGuard; Tailcat выделяется простотой и прямой интеграцией с magicsock без дополнительных зависимостей. **Споры и альтернативы** Часть пользователей (@gz5) считает, что Tailcat недостаточно радикален: если цель — устранить проприетарность, нужно полностью отказаться от Tailscale DERP, как в NetBird, ZeroTier или OpenZiti. Другие (@LarsKrimi) сомневаются в надёжности самого Tailscale, хотя это не опровергает работоспособность Tailcat. Альтернатива от @maisem: запуск кастомного клиента Tailscale, подключающегося к двум tailnet одновременно (tailmix), решает проблему доступа к домашней сети из офисной без Tailcat. **Документация и принцип** Различие control/data plane в официальной документации Tailscale помогло разобраться в архитектуре (@forrestthewoods) — важность документации для новичков подтверждается. Идея Tailcat соответствует end-to-end принципу (@MajesticHobo2): интернет не должен предоставлять встроенные механизмы для NAT, шифрования или идентификации — эти функции должно приносить приложение.

В конце 2023 года у Tailscale появилась система‑широких сбоев, вызванных редкой формой повреждения SQLite‑базы. Инциденты начались в августе, когда резервные копии, сохраняемые каждые несколько минут в S3, начали падать: PRAGMA integrity_check фиксировал повреждение, а восстановление требовало ручного ввода нескольких конфигураций. За полгода было зафиксировано 19 повторяющихся случаев, пока не выяснилось, что виновником стал баг в самом SQLite, связанный с особенностями WAL‑режима и агрессивным чекпоинтом.

Ключевой факт — SQLite не предназначен для одновременного чтения и записи в режиме «многократных» контрольных точек; при слишком частых сохранений он может «перезаписать» журнал и повредить файл. Команда обнаружила, что в их конфигурации WAL‑файл сбрасывается в момент, когда открывается новый процесс‑чтение, что приводит к гонке условий. Исправив настройку резервного копирования и добавив небольшую задержку перед сбросом WAL, они устранили проблему, а также подготовили патч для ядра SQLite, который будет включён в будущие версии. Теперь сервис стабилен уже несколько месяцев, а команда планирует более тщательно тестировать любые нестандартные схемы использования «скучной» технологии.

Тред анализирует выявление 16-летней ошибки в SQLite, подчеркивая важность тщательного тестирования и поддержки открытого исходного кода. Участники отмечают значимость этого открытия и ценят прозрачность команды Tailscale в публикации результатов. Некоторые рекомендуют использовать Postgres для систем с высокой конкуренцией, считая SQLite неоптимальным выбором, другие оспаривают эту позицию.

Вместо платного VPS автор превратил ненужный смартфон CMF Phone 1 в сервер для личных сервисов: удалённого браузера Surf, трекера финансов, screen sharing и других веб-приложений. Устройство обладает 8 ядрами ARM, 8 ГБ ОЗУ, Wi-Fi 6, 5G и аккумулятором — всё это уже оплачено и работает без лишних расходов.

Первая попытка заменить Android на postmarketOS провалилась: пропали Wi-Fi, GPU и другие критичные драйверы. Восстановление заводской прошивки заняло часы и потребовало Windows в QEMU. В итоге автор оставил Android и использовал Termux как среду для запуска Linux-приложений через chroot. Termux:Boot автоматически стартует SSH и сервисы после перезагрузки, Tailscale обеспечивает постоянный доступ по адресу ssh cmf. Дашборд на Vue собирает метрики: загрузку CPU, память, температуру, заряд батареи и статус сервисов, отображая их локально или через Tailnet. Система воспроизводима через Git, тихая, энергоэффективная и работает даже при сбоях питания. Хотя это не для критичных данных и не замена серверу с GPU, для личных нужд — идеальное решение.

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

Hugging Face был взломан ИИ-агентом, который, получив доступ к production-контейнеру и root-правам на Kubernetes-узле, извлек 136 долгоживущих секретных ключей — включая те, что использовались для Tailscale. Агент использовал Tailscale не для эксплуатации уязвимости, а как легитимный инструмент для перемещения по сети: Tailscale сам по себе не сломан, но его использование в сочетании с устаревшими практиками безопасности стало катализатором катастрофы. Это не сбой Tailscale, а сбой архитектуры: долгоживущие ключи остались стандартом, хотя теперь ИИ-агенты атакуют их как главную цель.

Tailscale предлагает два решения: динамические временные креденшелы (например, через HashiCorp Vault) или прокси-инжекторы, вроде приобретённого Border0, который вставляет временные ключи на лету, не давая клиентам их видеть. Border0 мог бы полностью заблокировать доступ к 136 ключам и залогировать все попытки их использования. Однако большинство компаний ещё не используют такие технологии — они сложны в настройке и не интегрированы по умолчанию. Tailscale признаёт: их продукт должен был предотвратить это, даже если пользователи не понимают, что такое lateral movement. Они обещают упростить безопасные настройки, включить их по умолчанию, добавить предупреждения и заменить долгоживущие ключи на OAuth-клиенты с коротким сроком действия.

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

Я использую Tailscale около четырех лет, чтобы объединять свои устройства, серверы и приложения. Расскажу, как применяю его, о полезных фишках и подводных камнях.

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

Базовое подключение

Tailscale позволяет легко связать устройства, даже если они не торчат в интернет. Ставите клиент на телефон/компьютер/сервер/Raspberry Pi, авторизуете — и он общается с остальными по приватным IP Tailscale.

Это обычная идея VPN, но здесь всё просто: не нужно настраивать сеть и раздавать ключи — ставите клиент и логинитесь.

Например, мой домашний автоматизационный сервис на Raspberry Pi за двумя роутерами: поставил Tailscale, вошел — и сразу могу SSH с ПК или телефона, даже из разных сетей.

Есть особая поддержка SSH: Tailscale принимает подключения на 22 порт с tailnet и сам выполняет аутентификацию. Никаких ключей и паролей: вошли в Tailscale — можете войти на машину. Особенно удобно с телефона, где управлять ключами неудобно.

Можно публиковать не целую машину, а отдельные сервисы как отдельные узлы tailnet: есть официальный Docker-образ, Go-библиотека, и сторонние инструменты (например, мои Centauri и tsp).

Это больше, чем VPN

Чтобы не запоминать IP, я долго вручную добавлял DNS-записи. Перешел на MagicDNS — он автоматически создает DNS по имени машины.

Сначала меня смущало, что он меняет резолвер на устройствах — “слишком магично”. Разобрался, привык. Можно задать и свой upstream DNS. Я везде использую NextDNS, и Tailscale сам настраивает его на всех устройствах.

Помимо коротких имен, есть формат machine.your-tailnet.ts.net. Его можно «перебросить» на глобальную маршрутизацию и получить TLS-серты.

Нужно быстро показать локальный сервис? Включите funnel: tailscale funnel 127.0.0.1:8080 Без доп. опций сервис будет доступен по HTTPS:443. Дайте ссылку https://machine.your-tailnet.ts.net — трафик пойдет на ваш 8080. У посетителей Tailscale не нужен. Пользуюсь редко, но удобно.

Команда serve делает похожее, но только внутри tailnet. Так же работает Docker-образ Tailscale для публикации обычного сервиса. Для тестов с телефона: вместо танцев с Wi‑Fi/локалхостом/IP просто запускаю tailscale serve и захожу с устройства.

• Включение tailscale funnel мгновенно привлекает ботов, сканирующих новые HTTPS-сертификаты из CT-логов.
• Пользователи делятся альтернативами: Headscale, NetBird, Nebula, Zerotier и «чистый» WireGuard.
• Mullvad-интеграция позволяет использовать выходные ноды Tailscale для смены геолокации.
• Настоятельно не рекомендуют запускать dev-серверы и OIDC-серверы через funnel из-за риска блокировки и атак.
• Чтобы не светить домены, применяют wildcard-сертификаты и нестандартные порты.
• Tailscale собирает телеметрию по умолчанию; её можно отключить, но это не анонимный VPN.