tailscale

admin console でできる設定関連はtailscale cliに載ってないけど公式クライアントライブラリにはある 例えばACL github.com/tailscale/tailscale/tree/main/client/t… ここらへんはオレオレCLIかterraformかな registry.terraform.io

WireGuard por tu cuenta o Tailscale en un homelab: qué plano de control quieres operar > En breve: Respuesta corta: Tailscale es WireGuard con el trabajo de coordinación hecho por otro. Resumen Respuesta corta: Tailscale es WireGuard con el trabajo de coordinación hecho por otro. La pregunta real no es qué cifra mejor, sino qué parte del plano de control quieres operar tú: distribución de claves, configuración de endpoints y recuperación de conexiones tras NAT. Criterio propio, apoyado en los datos de abajo: - Pocos nodos, uno con IP pública y ganas de controlarlo todo: WireGuard puro es una opción razonable, porque tú mantienes el endpoint y las claves. - Sin IP pública (CGNAT), varios usuarios o poco tiempo para mantenerlo: Tailscale, que funciona tras NAT sin abrir puertos y cuyo plan Personal es gratuito para uso no comercial. Según la documentación consultada el 2026-11-02, estos son los datos en los que se apoya la decisión. Criterios 1. Esfuerzo para llegar a un servicio desde fuera WireGuard puro. El protocolo deja fuera de su alcance la distribución de claves y la configuración empujada. Cada peer necesita la clave pública del otro, y todo se define a mano con wg/wg-quick, AllowedIPs y Endpoint. Mi inferencia: al añadir un nodo nuevo habrá que revisar la configuración de los peers con los que deba hablar. Un esquema mínimo, con marcadores donde la fuente no da valores: [Interface] PrivateKey = <clave-privada-local> Address = <ip-del-túnel> [Peer] PublicKey = <clave-pública-del-otro-peer> AllowedIPs = <ips-permitidas> Endpoint = <host-público>:<puerto> PersistentKeepalive = 25 Tailscale. Al autenticar dos o más dispositivos se crea automáticamente la tailnet con políticas de acceso por defecto. Se despliega en minutos y las conexiones funcionan a través de firewalls y NAT sin abrir puertos. También puede enrutar todo el tráfico por un exit node. 2. CGNAT, hard NAT y UDP bloqueado WireGuard puro. Un peer detrás de NAT o firewall que deba recibir paquetes tras un periodo de silencio necesita PersistentKeepalive. Está desactivado por defecto y 25 s es un valor razonable. Mi razonamiento, a partir de que cada peer se define con un Endpoint: si tu casa está tras CGNAT, nadie puede alcanzarla desde fuera, así que necesitarás un punto alcanzable (por ejemplo, un servidor externo) que tendrás que mantener tú. Las fuentes del pack no detallan este escenario. Tailscale. Usa tres tipos de conexión: directa (UDP), relé DERP y Peer Relay. Todas van cifradas con WireGuard y la diferencia es de rendimiento. Empieza por DERP e intenta subir a directa. Con UDP bloqueado o hard NAT se queda en relé, que es más lento. Para favorecer conexiones directas puedes abrir el puerto UDP 41641 o habilitar NAT-PMP/UPnP en el router. 3. Control y privacidad del plano de control Lo que cedes con Tailscale es la coordinación, no el cifrado del tráfico: los servidores DERP reenvían paquetes ya cifrados y no pueden descifrarlos. Lo que ganas con WireGuard puro es que tú mantienes el endpoint y las claves, y eso es a la vez control y trabajo. Si te preocupan los relés, Tailscale desaconseja en general los DERP propios y recomienda Peer Relays: menor latencia, sin coste de egress y sin mantener derper. Los DERP propios, además, no soportan compartir dispositivos entre tailnets. 4. Coste para un homelab personal El plan Personal de Tailscale es gratuito y de uso no comercial. Incluye dispositivos de usuario ilimitados, hasta 6 usuarios y 50 recursos etiquetados. Las tailnets creadas con dominio público (Gmail, etc.) se tratan como uso personal, y el homelab se menciona como caso típico. Con WireGuard puro, el coste que sale del pack es operativo: mantener el endpoint y las claves. 5. Medir latencia y tipo de conexión de forma equivalente En Tailscale, tailscale status indica si la conexión es direct, relay o peer-relay, y tailscale ping sirve para sondear. tailscale status tailscale ping <nodo> Para una prueba idéntica en ambos (criterio mío, no de las fuentes): lanza desde el mismo cliente, a la misma hora y hacia el mismo servicio, un ping ordinario a la IP del túnel de cada solución y compara los resultados. En Tailscale, consulta además tailscale status para saber si medías una conexión directa o un relé, ya que los tipos de conexión difieren en rendimiento. En WireGuard puro, el camino lo define el Endpoint que configures. 6. Rendimiento Hay un aviso que afecta a equipos viejos, y procede de un issue en GitHub con confianza media, no de documentación oficial. Según ese issue, en Tailscale v1.100.0, v1.102.0 y v1.98.10 wireguard-go perdió la optimización en ensamblador anterior a AVX para ChaCha20-Poly1305. En CPUs amd64 antiguas el caudal cayó: con un Xeon E5-2697 v2 y SSSE3 se pasó de 61,1 a 30,8 Gbit/s. Se prepara restaurarlo, pero no consta el estado final del arreglo. Si tu servidor es un equipo antiguo, tenlo en cuenta. WireGuard, por su parte, presume de alto rendimiento en el kernel de Linux, aunque su web indica que está en desarrollo activo. Qué dicen las fuentes Límites El pack no incluye medidas propias de latencia ni de rendimiento entre WireGuard puro y Tailscale. Tampoco cubre con detalle Headscale ni Cloudflare Tunnel. ¿Lo usas en tu homelab? Cuéntalo en los comentarios. Fuentes - What is Tailscale? · Tailscale Docs - Connection types · Tailscale Docs - DERP servers · Tailscale Docs - Tailscale pricing - WireGuard: fast, modern, secure VPN tunnel - Quick Start - WireGuard - Issue #21002 de tailscale/tailscale sobre el rendimiento de wireguard-go Este artículo se ha elaborado con asistencia automatizada

Tailscale 越しに寝ている PC は起こせない。LAN に中継を置いて、スマホから起こして休止させる 自宅の PC で AI コーディングエージェントを動かし、外出先からスマホの Tailscale 経由で操作しています。リモートデスクトップなら何でもできますが、モバイル回線では少し重いので、HTTP だけで操作できるようにしていました。 ただ、PC が寝ていると、Tailscale があっても届きません。 起こすために Wake-on-LAN を使おうとしても、スマホからマジックパケットを送るだけでは済みません。 そこで、常時起動している別の PC に中継を置き、スマホの同じ画面から「起こす」「様子を見る」「休止させる」をできるようにしました。作ったものは okiteru（Rust 製の単一バイナリ、MIT）です。 この記事では、作るときに引っかかった点を、踏んだ順に書きます。一番の引っかかりは、Tailscale から相手の LAN の IP を取るところでした。 なぜ Tailscale だけでは起こせないのか 理由は 2 つあります。 寝ている PC では Tailscale が動いていない。 tailnet の宛先に送っても、受け取る相手がいません マジックパケットは LAN のブロードキャストで届ける。 眠っている NIC が LAN 上で受け取るものなので、Tailscale の外側、つまり相手と同じ LAN から送る必要があります Tailscale 本体にも Wake-on-LAN のサポートを求める Issue があります。 構成はこうなります。 スマホ ──(Tailscale)──▶ 常時起動の PC [okiteru] ──マジックパケット(LAN)──▶ 起こしたい PC │ └──(Tailscale)「お休みなさい」──▶ 止めたい PC [okiteru --agent] └── 起動の確認: 機器ごとの TCP ポートへ接続 試作は設定を手で書いていた 最初の試作は Python の標準ライブラリだけで書いた 184 行のスクリプトで、動作はしていました。ただ、冒頭に設定が並びます。 TARGET_MAC = "AA:BB:CC:DD:EE:FF" # メインマシンの有線 NIC の MAC アドレス BROADCAST = "192.168.1.255" # LAN のブロードキャストアドレス TARGET_IP = "192.168.1.10" # メインマシンの LAN IP(起動確認に使う) これをなくしたいと考えました。Tailscale に入っている端末なら、中継 PC は相手を既に知っているはずです。tailnet の端末一覧から LAN の IP を求め、ARP で MAC を引けば、選ぶだけで登録できます。 問題は、その LAN の IP をどこから取るかでした。 外した仮説: Addrs と tailscale ping の via まず tailscale status --json を見ました。peer の Addrs が使えそうな名前ですが、手元の環境では常に null でした。 次に試したのが tailscale ping の出力です。 pong from NAME (100.x.y.z) via 192.168.x.x:41641 in 5ms via に LAN の IP が出ています。これを読む実装を書きました。ところが実機で動かすと、直接経路でも via が IPv6 になることがありました。 直接つながっていても、LAN の IPv4 が出るとは限らないわけです。 pong from NAME (100.x.y.z) via [2001:db8::1]:41641 in 5ms # アドレスは例 効いた方法: ping で直接経路を張らせ、CurAddr を読む 調べ直すと、ping の後に status --json を読むと、CurAddr に LAN の IP が入っていました。 "CurAddr": "192.168.x.x:41641" そこで手順を 2 段に分けました。ping は直接経路を張らせるためだけに打ち、結果は読みません。 /// 直接経路を張らせる。結果は status の CurAddr で読むので、出力は見ない。 pub fn warm_up(ip: Ipv4Addr) -> std::io::Result<()> { Command::new(binary()) .args(["ping", "-c", "3", "--timeout", "3s", &ip.to_string()]) .output() .map(|_| ()) } ただし、CurAddr がいつも LAN の IP とは限りません。 CurAddr の中身 意味 扱い 空 直接経路がない 候補にしない 公開 IP 別のネットワークにいる端末 候補にしない IPv6 直接経路だが LAN の IPv4 ではない 候補にしない 自分のサブネット内の IPv4 同じ LAN にいる 候補にする なので、IPv4 で、かつ送信元 NIC のサブネットに入るものだけを通します。 pub fn lan_ip(&self, in_my_subnet: impl Fn(Ipv4Addr) -> bool) -> Option<Ipv4Addr> { match self.cur_addr? { SocketAddr::V4(a) if in_my_subnet(*a.ip()) => Some(*a.ip()), _ => None, } } あとは ARP で MAC を引けば、候補が揃います。 なお、status --json の形式は変わりうると公式に注意書きがあります。ここは将来の版で壊れる可能性がある箇所です。 上の挙動も、手元の環境で確かめた範囲の話です。 送信元の NIC は自分で選ぶ マジックパケットの宛先にも落とし穴があります。255.255.255.255 へ送ると、OS の経路次第で Tailscale など別の NIC から出ることがあります。そこで、選んだ NIC に bind し、そのサブネットのブロードキャストへ送ります。 let socket = UdpSocket::bind(SocketAddr::V4(SocketAddrV4::new(nic.ip, 0)))?; socket.set_broadcast(true)?; let target = SocketAddrV4::new(nic.broadcast(), WOL_PORT); NIC の選び方にも注意が要ります。「私的アドレスを持つ NIC」では足りません。Windows では WSL の仮想 NIC も 172.28.x.x のような私的アドレスを持つからです。名前で仮想 NIC を除外したうえで、既定経路が使う NIC を優先しています。 起動の確認は ping ではなく TCP で行う Windows は既定で ping に応答しないので、起動の確認には機器ごとの TCP ポートへの接続を使います。リモートデスクトップなら 3389、ファイル共有なら 445 です。 TCP 接続は、忙しい機器だと 1 回失敗することがあります。そのため、2 回続けて失敗したときだけ「停止した」と判定します。 確認は 10 秒ごとなので、ログの時刻の精度も 10 秒程度です。 実測 手元の PC で、それぞれ 1 回ずつ計った結果です。どちらもスマホの画面でボタンをタップした時点から数えています。 操作 計測の終点 かかった時間 「お休みなさい」をタップ 電源が切れたことを目で確認できるまで だいたい 20 秒 「起きてください」をタップ（休止からの復帰） Windows Hello（顔認証）でログインが完了するまで だいたい 30 秒 なお、後者は PC の前にいるときの数字です。 外出先では顔認証ができません。また、画面に「起きています」と出るまでの時間でもありません。 それでも外出先の用途には困りません。私が使っている MulmoTerminal は基本的に Web サーバーとして動くので、PC にログインした状態にしなくても、スマホから利用できます。 休止させる側には受け口が要る 起こすのは LAN へのパケットで済みますが、止めるには相手側で動くプログラムが要ります。止めたい PC にも agent（okiteru install --agent）を入れておくと、Tailscale 経由で休止状態・スリープ・シャットダウンを頼めます。 認証は Tailscale 任せ okiteru は独自の認証を持ちません。同じ tailnet の端末なら、誰でも PC を起こしたり止めたりできます。 絞りたいときは Tailscale の ACL で、中継の 8765 と agent の 8766 を制限してください。tailscale funnel やポート転送でインターネットに公開してはいけません。 アプリ側では、localhost と Tailscale の IP でだけ待ち受け、接続元を 100.64.0.0/10 と localhost に限っています。Host と Origin の検査も入れていますが、これは認証の代わりにはなりません。 既存のツールとの違い Wake-on-LAN の Web UI には、Tailscale の公式ブログでも紹介されている UpSnap があります。README によれば、nmap を使ったネットワークスキャン、任意のコマンドでのシャットダウン、ユーザー管理、Cron での定時実行、Docker イメージなどを備えています。機能の幅とユーザー管理が必要なら、こちらが向いています。 okiteru が違うのは、次の点です。 tailnet の端末一覧から候補を見つける（nmap が要らない） Windows のサービスとして登録でき、ファイアウォール規則まで install 1 回で入る 休止・スリープ・シャットダウンを、コマンドを書かず機器ごとに選べる（代わりに相手側に agent が要る） 制限 中継のサービス登録は Windows 専用です。Linux では前面での実行だけできますが、動作は未検証です IPv4 の LAN だけが対象で、起こす相手は中継と同じ LAN にいる必要があります 起こす PC は有線 LAN でつなぎ、BIOS/UEFI と NIC の設定で Wake-on-LAN を有効にしておきます（手順は README） まとめ 寝ている PC は Tailscale では受け取れないので、同じ LAN に中継が要る tailscale status の Addrs や tailscale ping の via では、LAN の IPv4 を確実には取れなかった ping で直接経路を張らせてから CurAddr を読み、自分のサブネットに入るものだけを通すと取れた（手元の環境での結果） 認証は Tailscale に任せているので、tailnet に誰が入っているかがそのまま操作権限になる

I think this is all you need to set, but I have not tried this github.com/tailscale/tailscale/blob/1334899864168…

【実測】CVE-2026-98432、CVSSよりもまず「先に対象かどうか」を確認すべし こんにちは、もんすんです。 この記事は、Linux のサーバーやラズパイを動かしている個人開発者と、脆弱性のニュースを見て何をすればよいか迷う初学者に向けた記事です。 この記事で分かることは、次の3つです。 - Linux カーネルの脆弱性 CVE-2026-98432 の中身、影響を受ける版、直し方 - 話題の中で出てくる MPTCP が、そもそも何に使う仕組みか - 自分のマシンが対象かを、読み取りだけで確かめる手順と、私のラズパイでの結果 先に、私の言いたいことを書きます。 :::note info 最近、CVSS の数字だけを見て騒ぐ投稿が多すぎると感じています。 大事なのは、自分のサービスが対象かをすぐに確かめ、対象なら直すことだけです。 だから記事や X で書くべきなのは、点数の大きさよりも、検知から確認までを速く回す手順だと考えています。 ::: また、このCVEの対象になるのは以下のサーバです。 まず取り急ぎ確認することをお勧めします。 [CVE-2026-98432の対象](###対象) CVE-2026-98432 の概要 CVE は、公開された脆弱性につける通し番号です。 CVSS は、脆弱性の深刻さを 0 から 10 の数字で表す共通の物差しです。 この脆弱性は、Linux カーネルの IPv4 の TCP の接続開始の処理にあります[^1]。 接続を始めるときに送られる IP オプションのデータを、別の CPU がまだ読んでいる間に解放してしまう競合があります。 解放済みのメモリを使ってしまう、use-after-free と呼ばれる種類の欠陥です。 IPv6 は、オプションを複製しているため、この部分の影響を受けないと書かれています[^1]。 2026/10/27 には Anthropic が、この脆弱性を使い、認証なしで root としてコマンドを実行できることを実証したと公表しました[^2]。 root は、システムのすべての権限を持つ管理者です。 | 出典 | 内容 | | --- | --- | | CVE の記録、Linux カーネルの採番[^1] | 2026/10/15 公開。CVSS 3.1 で 9.8、Critical | | Red Hat[^3] | CVSS 3.1 で 8.1、Important。攻撃の難しさを High と評価 | | Ubuntu[^4] | CVSS 4.0 で 8.3、High。22.04 と 24.04 は影響あり、対応中 | 同じ CVSS 3.1 でも、評価する組織によって 9.8 と 8.1 に分かれました。 ただし、ここで、CVSSの点数は、自分のマシンが対象かどうかは教えてくれません。 対象と直し方 対象 影響はカーネル 4.4 以降です。 正確には、次の3つが揃ったサーバーが対象です。 1. カーネルの版が影響範囲にある。4.4 以降で、まだ修正版に更新していないもの 2. IPv4 の TCP で接続を待っている。Web・SSH・データベースなど、ほとんどのサーバーが当てはまる 3. 攻撃者のパケットがそこまで届く。インターネットに公開していなくても、同じネットワークの中から届くなら当てはまる つまり、修正前のカーネルで TCP の待ち受けがある Linux サーバーは、基本的にすべて対象です。 上流は、Linux カーネル本体の開発元のことです。 上流の修正版は 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10 と、7.3 以降です[^1]。 Debian 13 では、6.12.113-1 が DSA-6568-1 で修正済みと表示されています[^5]。 DSA は、Debian のセキュリティ勧告の番号です。 直し方 直し方は、修正を含むカーネルに更新して再起動することです。 Red Hat は、条件を満たす回避策はないとしています[^3]。 自分のカーネルが修正済みか確かめる 1. 動いているカーネルの版 uname -r これが、今動いているカーネルの版です。 パッケージを更新していても、再起動するまでは古いカーネルが動いたままです。 判断は、必ずこのコマンドの結果で行います。 2. 修正が入っているか uname -r の番号を、上流の修正版と比べます[^1]。 | 系列 | 修正版 | | --- | --- | | 5.10 | 5.10.272 | | 5.15 | 5.15.223 | | 6.1 | 6.1.190 | | 6.6 | 6.6.159 | | 6.12 | 6.12.113 | | 6.18 | 6.18.56 | | 7.2 | 7.2.10 | | 7.3 | 7.3 以降はすべて修正済み | :::note warn Ubuntu や Red Hat などのディストリビューションは、修正を独自の版番号のカーネルに取り込みます。 そのため、番号を上流と比べるだけでは判定できません。 各社の脆弱性情報のページで確認してください[^3][^4][^5]。 ::: 3. ディストリビューションのカーネルの場合 今動いているカーネルに修正が入っているかを確かめます。 どれも uname -r や uname -v を使い、入っているだけのカーネルではなく、動いているカーネルを見ます。 # Ubuntu: 変更履歴に CVE 番号か修正の件名があるか apt changelog linux-image-$(uname -r) | grep -E 'CVE-2026-98432|free inet_opt and ireq_opt' # RHEL / Rocky / Alma: 変更履歴に CVE 番号か修正の件名があるか rpm -q --changelog kernel-$(uname -r) | grep -E 'CVE-2026-98432|free inet_opt and ireq_opt' # Debian: 動いているカーネルのパッケージの版を出す。6.12.113-1 などの修正版と比べる uname -v Ubuntu と RHEL 系で何も表示されなければ、動いているカーネルにはまだ修正が入っていない可能性が高いです。 変更履歴の書き方はディストリビューションごとに違うため、最終的な判定は各社のページで行ってください。 Ubuntu と RHEL 系のコマンドは、私の環境では試していません。 :::note info ここで分かるのは、対象の条件のうちカーネルの版だけです。 修正が入っていなければ、ss -tln で TCP の待ち受けがあるかも見て、対象かを判断します。 ::: MPTCP は何に使うものか Anthropic の説明では、攻撃の相手は MPTCP で待ち受けている Linux サーバーでした[^2]。 ただし CVE の記録の本文に、MPTCP という言葉は出てきません[^1]。 MPTCP は Multipath TCP の略で、RFC 8684 で決められた TCP の拡張です[^6]。 ふつうの TCP は、1つの接続で1つの経路しか使いません。MPTCP は、Wi-Fi とモバイル回線のような複数の経路を、1つの接続で同時に使えます。 帯域を束ねたり、片方の経路が切れても通信を続けたりできます[^7]。 実は自分で使った覚えがなくても、使っている可能性があるようです。 Go 1.24 では、待ち受けの設定 ListenConfig が、Linux では既定で MPTCP を使うようになったようです[^8]。 私のラズパイで確かめる Debian 13 の Raspberry Pi で、読み取りだけの確認をしました。 uname -r apt-cache policy linux-image-rpi-v8 | sed -n '1,3p' zcat /proc/config.gz | grep '^CONFIG_MPTCP=' sysctl net.mptcp.enabled sudo ss -Mlnp ss -M は、MPTCP のソケットだけを表示するオプションです。 出力は次のとおりです。アドレスは伏せました。 6.12.47+rpt-rpi-v8 linux-image-rpi-v8: インストールされているバージョン: 1:6.12.47-1+rpt1 候補: 1:6.18.50-1+rpt1 CONFIG_MPTCP=y net.mptcp.enabled = 1 LISTEN 0 4096 x.x.x.x:443 x.x.x.x:* users:(("tailscaled",pid=1117,fd=25)) LISTEN 0 4096 x.x.x.x:61540 x.x.x.x:* users:(("tailscaled",pid=1117,fd=21)) | 確認すること | 私の結果 | 判定 | | --- | --- | --- | | 動いているカーネル | 6.12.47 | 修正版 6.12.113 より前 | | MPTCP | 組み込み済みで有効 | 使える状態 | | MPTCP で待ち受け | tailscaled の2つ | Tailscale の仮想ネットワーク側だけ | 設定した覚えのない MPTCP の待ち受けが、Tailscale の常駐プロセスにありました。 Tailscale は Go で書かれています[^9]。 上の Go の既定によるものとみられます。 :::note warn Raspberry Pi のカーネルは、Debian のカーネルとは別のパッケージです。Debian の修正済みの表示は、そのまま当てはまりません。 私の環境の更新候補は 6.18.50 で、上流の修正版 6.18.56 より番号が前でした。 パッケージの変更履歴は取得できず、修正を含むかは確認できていません。 ::: 注意: MPTCP を止めても直らない MPTCP を止める設定 net.mptcp.enabled は、新しく MPTCP のソケットを作れるかを決めるものです[^10]。 | | 対策 | 理由 | | --- | --- | --- | | ❌ | MPTCP を止めて終わりにする | 欠陥は IPv4 の TCP の処理にある。すでに動いている待ち受けにも効かない | | ✅ | 修正を含むカーネルに更新して再起動する | 欠陥そのものが直る | Anthropic の実証は MPTCP の待ち受けが相手でしたが、ふつうの TCP で同じことができないとは書かれていません[^2]。 私のラズパイでも、SSH が使う 22 番ポートは、ふつうの TCP で待ち受けていました。 まとめ flowchart LR A["検知: CVE の記録で修正版を見る"] --> B["確認: 自分の版と待ち受けを見る"] B -->|対象| C["対処: カーネルを更新する"] B -->|対象外| D["記録して終わり"] | 段階 | やること | 今回の結果 | | --- | --- | --- | | 検知 | CVE の記録で、影響する版と修正版を見る | 修正版は 6.12.113 など | | 確認 | uname -r で版を、ss -tln で TCP の待ち受けを見る。ss -M で MPTCP の待ち受けもあれば優先度を上げる | 6.12.47 で対象。MPTCP の待ち受けあり | | 対処 | 修正を含むカーネルに更新する | Raspberry Pi の修正版を待って更新する | 9.8 という数字を見てから、私の結果が出るまでにかかったのは、コマンド5つでした。 次に試すことは、Raspberry Pi のカーネルの変更履歴で、この修正の取り込みを確かめることです。 <font color="red"> CVSS の数字に驚き、拡散する前に、まずは自分が対象かを確かめましょう！<br> 対象なら直す、対象でなければ安心して次へ進む。<br> やることは、それだけです。 </font> 参考 [^1]: CVE-2026-98432 の記録 cve.org [^2]: Anthropic「Discovering and exploiting vulnerabilities in critical, real-world software with Claude」 anthropic.com [^3]: Red Hat CVE-2026-98432 access.redhat.com [^4]: Ubuntu CVE-2026-98432 ubuntu.com [^5]: Debian Security Tracker CVE-2026-98432 security-tracker.debian.org [^6]: RFC 8684 TCP Extensions for Multipath Operation with Multiple Addresses rfc-editor.org [^7]: Multipath TCP for Linux mptcp.dev [^8]: Go 1.24 Release Notes go.dev [^9]: tailscale/tailscale tailscale/tailscale [^10]: MPTCP Sysfs variables, The Linux Kernel documentation docs.kernel.org

Tailworm: Multiple Vulnerabilities in Tailscale SSH Forwarding Leading to Root Privilege Escalation 1. Basic Information - Article Title: Security Assessment Report — Tailscale v1.104.2 and headscale v0.29.5 - Publisher: Cyberdione Labs - Publication Date: Unconfirmed. The source specifies testing from 2026-10-22 to 2026-10-24; it does not identify the initial publication date. - Updated Date: 2026-10-27 - Original Source: Cyberdione Labs - Related Resources: Tailscale SSH: Investigation and remediation update, BleepingComputer: Tailscale warns of serious SSH flaws, Tailscale Security Bulletins TS-2026-014~017, Tailscale v1.104.4 release, Tailscale SSH findings and fixes - Related Malware, Threat Groups, CVEs, and Products: Tailscale 1.104.2, headscale 0.29.5, Tailscale SSH, tailscale serve, conn25 - Severity: High 2. Executive Summary Researchers reported 11 findings from laboratory testing of Tailscale 1.104.2 and headscale 0.29.5, including issues in Tailscale SSH. Because Unix socket forwarding operations execute bind, dial, and unlink actions with root privileges, an authorized low-privileged SSH user can exploit race conditions or path replacement to escalate privileges, leading to arbitrary code execution as root, theft of tailnet enrollment keys, or unauthorized deletion of root-owned files. Note that these findings include security recommendations and expected behaviors, and not all 11 items represent independent, distinct vulnerabilities. No active exploitation by third-party attackers has been confirmed, and establishing an SSH forwarding path requires SSH connection access to the target node as well as forwarding permissions. The SSH connection conditions should not be generalized to other findings such as unauthenticated DoS in headscale. This is a significant design and implementation issue allowing authorized users with low-privileged SSH access to escalate to root, directly impacting infrastructure environments that use Tailscale SSH as a management path for internal nodes. Public disclosures are based on reproduction experiments in the researchers' own environment and do not constitute evidence of incidents caused by malicious third parties. 3. Attack Flow SSH and conn25 are separate paths and do not represent sequential attack stages. The following outlines the researchers' testing conditions rather than third-party incident cases. Privilege Escalation from Tailscale SSH Forwarding 1. An attacker connects as a low-privileged user from an approved device using SSH policy rules. The Unix socket forwarding issue also requires policies to permit local or remote forwarding. 2. The attacker induces path races or replacements through Unix socket forwarding, causing tailscaled, running as root, to perform bind, dial, and unlink operations. 3. Privileged socket connections and file operations are used to advance to root code execution, key theft, and file deletion. Bypassing Destination Control via conn25 1. Using the experimental conn25 feature, a device with connector capability registers an attacker-specified actual destination. Tailscale describes conn25 as an unreleased pre-production feature, and stable App Connectors are not affected. 2. Because ACLs are not applied to the translated destination, connections can reach cloud metadata services or internal LAN services outside the tailnet. Do not generalize this result to reachability for other tailnet nodes. 3. Acquired credentials and internal reachability may be leveraged for subsequent compromises. The following table summarizes the attack flows and investigation considerations based on researchers' verification results and public disclosures. It does not indicate that the entire attack chain is established or successful across all Tailscale operational environments. The first three rows represent the SSH path, and the last row represents the independent conn25 path. Inference: The defender indicators are investigation leads to check against available endpoint, authentication, and network records. They do not specify a fixed audit log format or a process parent-child relationship that must always occur. | Attack Stage | Attacker Actions and Techniques | Tools and Communications | Defender Indicators (Prerequisites and Artifacts) | | --- | --- | --- | --- | | Authorized SSH Connection Establishment | Connects to the target node as a standard user from an approved device based on Tailscale SSH policies. | Tailscale client, tailscale ssh | Correlate obtainable SSH connection and authentication logs with SSH policies corresponding to the user, device, and target node | | Socket Forwarding Request and Path Conflict | Sends local or remote forwarding requests, inducing symbolic link replacement or race conditions on Unix socket paths. | SSH socket forwarding, race condition scripts | Forwarding must be permitted by policy; repeated suspicious creation or deletion of sockets in /tmp or specific paths | | Privileged Operations and Privilege Escalation | Forces tailscaled, running with root privileges, to bind/dial privileged paths, achieving root code execution or key theft. | Privileged socket communications such as Docker socket and tailscaled local APIs demonstrated by researchers, file replacement | Startup of root-privileged processes associated with the target SSH session (not necessarily direct children of tailscaled), modification of root-owned files, access to enrollment key files | | conn25 Destination Control Bypass (Experimental Feature) | Uses the unreleased conn25 feature, where a device with connector capability registers actual destination translation with a connector, attempting to connect to destinations outside the tailnet. | conn25 experimental flag, custom connector settings | Requires enabling the experimental feature conn25 (stable App Connectors are unaffected). Connections to IP destinations outside the tailnet or to cloud IMDS | 4. Attacker Position and Execution Location - For the Tailscale SSH path, an approved device or identity permitted to connect to the target node is required. - For headscale DoS, unauthenticated peers with network reachability to the control server are assumed. 5. Perspective from Victims and Administrators - Victims: General users may observe service disruptions or connection failures. - Administrators: Depending on the finding, indicators may include unauthorized operations on root-owned files, Unix socket connections, or increased memory use by tailscaled. The SSH findings and the separate conn25 and headscale paths have different prerequisites. 6. Success and Failure Conditions Success Conditions - The target must be using vulnerable versions and features. - The Unix socket forwarding issue in SSH requires an approved device or identity permitted by policy to execute SSH connections and local/remote forwarding to the target. - The relevant vulnerable forwarding, Serve, or conn25 code path must be enabled; the required feature and access conditions differ by finding. Failure Conditions and Mitigations - As a temporary mitigation, set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart. This mitigates the SSH forwarding path and does not patch all findings such as Serve or headscale. - Restrict SSH access policies per user-device pair. - Update to Tailscale 1.104.4 or later. SSH and Serve issues in official bulletins TS-2026-014 through 017 have been resolved. Do not assume issues in headscale 0.29.5 are resolved solely by updating the Tailscale client; verify separate remediation statuses. 7. What Happens Upon Success - Arbitrary code execution as root, enrollment key theft, and deletion of root-owned files. - Reachability to cloud metadata and internal networks. - Memory exhaustion of headscale or client agents. 8. Observable Logs Inference: The following are investigation candidates based on behaviors and identifiers in public documentation. These do not verify that each log records or provides obtainable fields on real systems. Results depend on configuration and log retention settings, and a single match does not confirm successful compromise. - Email: No unique email-based indicators were identified in public documentation. - Proxy / SWG / DNS: None specified. - Endpoint / EDR: Verify unexpected processes under tailscaled, root-privileged file modifications, and Unix socket connections. - Identity / IdP: Check Tailscale SSH audit logs for users, devices, targets, and policy rules. - SaaS / Cloud: Verify access to metadata services followed by cloud API operations. - Network: Check connections to internal destinations and cloud metadata services. Correlate SSH-related activity with the relevant SSH session; investigate the separate conn25 path independently rather than requiring a preceding SSH session. 9. Determining Attack Success - Attack Attempt Observed (Success Unconfirmed): Tailscale SSH connections or forwarding requests alone do not indicate root privilege acquisition. (Evaluated based on internal criteria.) - Privilege Escalation Confirmed: Criteria: Identify unauthorized root-owned file operations or privileged socket connections corresponding to low-privileged sessions. This alone does not confirm arbitrary root code execution; separate evidence of root-privileged process execution must be verified. (Reproduced by researchers in a lab; not evidence of third-party victimization.) 10. Investigation Playbook 1. Trigger: Unauthorized root-owned file operations associated with Tailscale SSH, or suspicious metadata access through the separate conn25 path 2. Initial Verification: Check client/headscale versions, SSH policies, and forwarding environment variables 3. Endpoint Investigation: Preserve tailscaled process trees, sockets, and file operations 4. Authentication and Cloud: Verify metadata access and credential usage 5. Subsequent Actions: Trace lateral movement using acquired credentials 6. Containment: Stop forwarding, restrict policies, isolate nodes, and update 7. Classification Boundaries: Distinguish between connections, forwarding, privilege escalation, credential access, and subsequent compromise 11. Defense and Detection Ideas - Single Event: Unexpected unlink/bind of privileged paths by tailscaled - Timeline Correlation: For the SSH path, correlate the SSH session → socket forwarding → privileged operation or root process. Separately correlate conn25 mappings and outbound connections to metadata or internal services. - Hunting: Inventory Tailscale node versions and enabled forwarding states - Log Gaps: Establishing success is difficult without payload or socket audits - Priority Actions: Prioritize stopping forwarding and applying patches 12. Facts, Inference, and Hypothesis Facts - Researchers evaluated unmodified Tailscale 1.104.2 and headscale 0.29.5, reporting 11 findings, which include configuration cautions and behavioral specifications. - File operations during Unix socket forwarding execute as root, demonstrating a path from authorized sessions to root code execution, enrollment key theft, and root file deletion. - Tailscale resolved SSH and Serve issues in version 1.104.4. The GitHub release was published on October 28, 2026, at 01:05:26 UTC. Prerequisites and fix details can be verified in TS-2026-014 through 017. - The experimental conn25 feature reported issues allowing reachability to cloud metadata, internal LANs, and Kubernetes services outside the tailnet. According to Tailscale, this is an unreleased pre-production feature, and stable App Connectors are unaffected. - No reports of active third-party exploitation were found in the reviewed documentation. Inference - Organizations permitting Tailscale SSH for jump hosts or management servers must treat forwarding feature availability, not just standard OS account permissions, as a security boundary. Hypothesis No additional hypotheses. Unconfirmed items are listed under "Unresolved Items and Further Investigation." 13. MITRE ATT&CK Mapping There are no actionable mappings with verifiable supporting evidence. 14. Unresolved Items and Further Investigation - Regarding headscale 0.29.5, the product's fixed versions and deployment status require separate verification independent of the Tailscale 1.104.4 patch scope. - Whether exploitation has occurred in real-world deployments. - Exact initial publication date of the primary source. The source does not establish that the final day of testing was also the publication date. 15. Impact on SOCs and Organizations Organizations operating Tailscale for maintenance access, development environments, or cloud management servers should inventory their SSH policies and forwarding configurations, and update to version 1.104.4 or later. Until updates are applied, disable unnecessary forwarding and evaluate Serve, experimental features, and headscale separately. 16. Summary by Target Audience - For SOCs: Correlate Tailscale SSH sessions with Unix socket operations and root-privileged processes. Investigate metadata access through conn25 separately; it does not require a preceding SSH session. - For Administrators: Update to Tailscale 1.104.4 or later. As a temporary mitigation for SSH forwarding prior to updating, set TS_SSH_DISABLE_FORWARDING=1 in the service environment and restart tailscaled. Verify separate remediation statuses for headscale. - For Users: Limit Tailscale SSH usage permissions to the minimum necessary and follow administrators' update instructions.

Tailscale SSH: antes de parchear, desactivá el forwarding Tailscale confirmó el 26 de octubre de 2026 que su función Tailscale SSH tiene fallas de escalada de privilegios: un usuario ya autorizado para conectarse por SSH podría, en ciertas configuraciones, actuar con más permisos que los asignados a su usuario local. La empresa dice que investigó el problema junto a especialistas externos de seguridad y que ya corrigió la mayoría de los casos hallados. Apunta a liberar un cliente parcheado antes de que termine el 27 de octubre de 2026, aunque aclara que la fecha depende de que las pruebas terminen a tiempo. TL;DR - Tailscale confirmó el 26 de octubre fallas de escalada de privilegios que afectan a usuarios ya autorizados por SSH. - El parche llega el 27 de octubre de 2026 si las pruebas terminan a tiempo, según la compañía. - Fijar TS_SSH_DISABLE_FORWARDING=1 en tailscaled y reiniciar el servicio mitiga gran parte del riesgo ahora mismo. - La compañía no recomienda desactivar SSH por completo: pide limitar accesos mientras prepara el parche. - Un advisory de seguridad y un post técnico detallarán las vulnerabilidades confirmadas tras liberar el parche. Qué es Tailscale SSH Tailscale SSH es la función de la VPN mesh de Tailscale que reemplaza al demonio sshd: permite conectarse a cualquier dispositivo de la red con las llaves WireGuard que ya autentican el túnel, en vez de gestionar claves SSH aparte, y aplica las reglas de acceso de la política ACL de la red. El servicio de acceso remoto de Tailscale corre sobre el mismo túnel que conecta el resto de la red: no abre un puerto 22 adicional ni depende de un agente separado. La identidad del dispositivo, verificada una sola vez al unirse a la tailnet, es la misma que decide quién puede abrir una sesión y con qué usuario del sistema operativo. Las VPN mesh evitan exponer puertos SSH tradicionales a internet. Qué pasó Según el comunicado publicado el 26 de octubre, la mayoría de las fallas encontradas en Tailscale SSH son de escalada de privilegios local. En algunos escenarios, alguien ya autorizado para conectarse puede ejecutar acciones por fuera de los permisos de su usuario configurado, incluyendo obtener privilegios más altos de los previstos. Tailscale aclara que la explotación depende de los permisos otorgados al usuario o dispositivo que se conecta, de cómo está configurado el sistema de destino y de otras condiciones específicas de cada entorno. Por eso, pese a calificar los hallazgos como serios, la compañía dice explícitamente que no recomienda que todos desactiven el servicio mientras llega el parche. El trabajo de investigación no arrancó de cero: la empresa dice que construye sobre tareas que ya tenía en marcha, aceleradas tras los reportes de los especialistas externos. No especificó cuántas fallas distintas se agrupan bajo este hallazgo ni publicó todavía una lista de versiones afectadas; eso queda para el advisory formal que promete después del parche. Contexto e historia Tailscale construyó su producto sobre WireGuard para resolver un problema conocido de las VPN tradicionales: la complejidad de configurar túneles punto a punto entre decenas de dispositivos. La idea fue simple: cada dispositivo se identifica una vez contra un proveedor de login (Google, Microsoft, GitHub o uno propio) y queda dentro de una red superpuesta sin necesidad de abrir puertos en el router. Sobre esa base, la empresa fue agregando funciones que reemplazan herramientas de administración clásicas. Tailscale SSH es una de ellas: en vez de distribuir y rotar claves SSH entre servidores, delega la autenticación a la misma identidad que ya gestiona el resto de la red y aplica permisos mediante archivos de política ACL versionables. Antes de esta función, muchos equipos resolvían el acceso remoto con bastion hosts, gestores de secretos o certificados de corta duración firmados por una CA interna. El servicio de acceso remoto de Tailscale no inventa un modelo de confianza nuevo: reutiliza el mismo esquema basado en identidad que corre detrás del túnel WireGuard. Eso explica por qué un error en el mapeo de permisos repercute en todo lo que depende de esa identidad, no solo en SSH. Ese diseño simplifica la operación diaria, pero también concentra más decisiones de seguridad en un solo sistema. Cuando algo falla ahí, como ocurrió esta semana, el radio de impacto potencial es más amplio que el de un bug aislado en un sshd tradicional, porque toca directamente cómo se mapean identidades de red contra usuarios del sistema operativo. Detalles técnicos: el mecanismo detrás del riesgo El comunicado todavía no publica el detalle técnico completo, eso llega con el advisory y el post de ingeniería prometidos, pero sí identifica el patrón general: el riesgo aparece en el límite entre la identidad de red que autoriza la conexión y el usuario local al que esa identidad queda mapeada. Cuando ese mapeo permite más de lo previsto, o cuando el reenvío de agente SSH o de puertos abre un camino lateral, un usuario autorizado para una tarea puntual puede terminar con permisos que no le correspondían. Ese tipo de falla no es exclusivo de Tailscale: cualquier sistema que combine autenticación centralizada con mapeo a usuarios locales enfrenta el mismo riesgo de diseño. La diferencia está en la escala. Una tailnet mal configurada puede abarcar cientos de servidores bajo la misma regla de acceso, así que un error de mapeo se multiplica en vez de quedar aislado a una sola máquina. La mitigación que ofrece Tailscale hoy ataca justo esa superficie: apagar el reenvío sin apagar el acceso SSH de Tailscale. La variable de entorno se fija en el servicio tailscaled y corta buena parte de los caminos laterales sin dejar a los equipos sin acceso remoto. # en el entorno del servicio tailscaled (Linux/BSD) -TS_SSH_DISABLE_FORWARDING=0 +TS_SSH_DISABLE_FORWARDING=1 Después de aplicar el cambio hay que reiniciar el servicio, por ejemplo con systemctl restart tailscaled en distribuciones con systemd. En macOS y Windows la variable de entorno del daemon todavía no está expuesta de la misma forma, así que ahí la mitigación pasa por ajustar las reglas de SSH en la política ACL desde el panel de administración. El panel de políticas ACL centraliza los permisos de SSH de toda la tailnet. flowchart TD A["Dispositivo autorizado"] --> B["Tunel WireGuard"] B --> C["Politica ACL de la tailnet"] C --> D["Acceso SSH de Tailscale"] D --> E["Usuario local del sistema"] D -. "reenvio de agente o puertos" .-> F["Posible escalada de privilegios"] AcciónCuándo aplicarlaQué mitigaLimitación Revisar políticas de acceso ACLAhora, sin esperar el parcheReduce qué usuarios y dispositivos pueden conectarseNo corrige la falla subyacente, solo achica la exposición Fijar TS_SSH_DISABLE_FORWARDING=1Si no usás reenvío de agente ni de puertosVarios de los hallazgos más serios, según TailscaleNo cubre todos los escenarios reportados Restringir acceso a sistemas sensiblesMientras dura la investigaciónLimita el radio de impacto si algo fallaPuede afectar flujos de trabajo legítimos Actualizar al cliente parcheadoEn cuanto salga, estimado 27 de octubre de 2026Corrige la mayoría de las fallas identificadasDepende de que las pruebas de Tailscale terminen a tiempo > ⚠️ Ojo: Tailscale aclara que la gravedad real depende de los permisos de cada usuario y de la configuración del sistema de destino: no todas las tailnets quedan expuestas igual. Impacto y análisis El episodio pone a prueba un argumento central del modelo de Tailscale: delegar el acceso remoto a una sola identidad de red simplifica la operación, pero también vuelve crítico cualquier error en cómo esa identidad se traduce en permisos locales. Para equipos de infraestructura que migraron servidores completos al servicio de acceso remoto de Tailscale como reemplazo de sshd, esta falla toca directamente el control de acceso a producción. Al mismo tiempo, la respuesta de la compañía funciona como caso de manual sobre cómo comunicar una vulnerabilidad sin generar pánico. Publicó lo que sabía antes de tener el parche listo, dio una mitigación concreta y evitó la recomendación extrema de apagar el servicio. Esa decisión llama la atención para una falla que la propia empresa califica de seria, y sugiere que, con el reenvío desactivado y las políticas de acceso bien acotadas, el riesgo residual es manejable para la mayoría de las configuraciones. También queda la pregunta de cuántas organizaciones corren con el reenvío de puertos o de agente habilitado sin necesitarlo, simplemente porque viene activo por defecto en algún flujo de onboarding. Esa es, en la práctica, la superficie que la mitigación de hoy apaga primero. La comparación obvia es con la gestión tradicional de claves SSH, que la VPN mesh de Tailscale prometía simplificar. Rotar y auditar claves manualmente en decenas de servidores es trabajoso, pero el radio de falla de un bug queda acotado a cada máquina. Centralizar esa decisión en una sola plataforma reduce el trabajo operativo, aunque también concentra el riesgo: si el sistema central falla, puede fallar en todas las máquinas a la vez. Qué sigue Tailscale ya aplicó correcciones para la mayoría de los hallazgos y las está probando antes de liberar el cliente parcheado. La meta es tenerlo listo antes de que termine el 27 de octubre de 2026, aunque la compañía advierte que esa fecha puede moverse si las pruebas lo requieren. Una vez publicado el parche, la empresa prometió dos documentos adicionales: un advisory de seguridad formal con las vulnerabilidades confirmadas, las versiones y configuraciones afectadas y su impacto real, y un post técnico de ingeniería que explique la causa raíz y los cambios de arquitectura que hizo para cerrarla. Hasta que eso salga, la recomendación sigue siendo revisar políticas de acceso y, si no se usa, desactivar el reenvío SSH. 📖 Resumen en Telegram: Ver resumen Probalo vos: revisá hoy mismo las políticas de acceso ACL de tu tailnet en el panel de administración y, si no usás reenvío de agente ni de puertos, fijá TS_SSH_DISABLE_FORWARDING=1 en tailscaled antes de que termine el día. Preguntas frecuentes ¿Qué es TS_SSH_DISABLE_FORWARDING y cómo se activa? Es una variable de entorno del servicio tailscaled que desactiva el reenvío de agente SSH y de puertos sin apagar el acceso remoto. Se fija en el entorno del servicio y requiere reiniciar tailscaled para que tome efecto. ¿Debo desactivar Tailscale SSH mientras llega el parche? No. La compañía dice explícitamente que, según su evaluación actual, no recomienda que todos apaguen el servicio. Tailscale SSH seguirá funcionando mientras se aplica el parche; la recomendación es acotar accesos y desactivar el reenvío si no se usa. ¿Qué dispositivos conectados por el servicio de acceso remoto de Tailscale están en riesgo? Depende de los permisos otorgados al usuario o dispositivo que se conecta y de la configuración del sistema de destino. Tailscale todavía no publicó una lista cerrada de versiones o configuraciones afectadas: eso llega con el advisory formal. ¿Cuándo publica Tailscale el advisory de seguridad sobre el cliente de Tailscale? La compañía dijo que lo publicará una vez que el parche esté disponible, con las vulnerabilidades confirmadas, las versiones afectadas y cómo solucionarlas. No dio una fecha exacta más allá de una vez disponibles los arreglos. ¿Qué significa que el riesgo dependa de la configuración de la red WireGuard de Tailscale? Significa que no hay un único escenario de explotación: una tailnet con políticas de acceso estrictas y sin reenvío habilitado queda menos expuesta que una con permisos amplios y reenvío activo para todos los usuarios. Referencias - Tailscale: actualización oficial de investigación y remediación publicada el 26 de octubre de 2026. - Tailscale Docs: documentación oficial sobre el funcionamiento del acceso SSH de Tailscale y su integración con las políticas ACL. - GitHub: repositorio open source del cliente y el daemon tailscaled. - Tailscale Docs: base de conocimiento oficial con la referencia completa de políticas de acceso. 📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

(Tailscalar) FWIW you can rebuild tailscaled to omit all the optional stuff: github.com/tailscale/tailscale/tree/main/feature e.g. % go run ./cmd/featuretags --min ts_omit_ace,ts_omit_acme,ts_omit_advertiseexitnode,ts_omit_advertiseroutes,ts_omit_androidbin,ts_omit_androiddns,ts_omit_appconnectors,ts_omit_aws,ts_omit_bakedroots,ts_omit_bird,ts_omit_c2n,ts_omit_cachenetmap,ts_omit_captiveportal,ts_omit_capture,ts_omit_cliconndiag,ts_omit_clientmetrics,ts_omit_clientupdate,ts_omit_cloud,ts_omit_colorable,ts_omit_completion,ts_omit_completion_scripts,ts_omit_conn25,ts_omit_connreject,ts_omit_dbus,ts_omit_debug,ts_omit_debugeventbus,ts_omit_debugportmapper,ts_omit_desktop_sessions,ts_omit_dns,ts_omit_dnsresolvecache,ts_omit_doctor,ts_omit_drive,ts_omit_exitnodehealth,ts_omit_favorites,ts_omit_flashappliance,ts_omit_gro,ts_omit_health,ts_omit_hujsonconf,ts_omit_identityfederation,ts_omit_ipnbus,ts_omit_iptables,ts_omit_kube,ts_omit_linkspeed,ts_omit_linuxdnsfight,ts_omit_listenrawdisco,ts_omit_logtail,ts_omit_nattraversal,ts_omit_netlog,ts_omit_netstack,ts_omit_networkmanager,ts_omit_oauthkey,ts_omit_osrouter,ts_omit_outboundproxy,ts_omit_peerapiclient,ts_omit_peerapiserver,ts_omit_portlist,ts_omit_portmapper,ts_omit_posture,ts_omit_qrcodes,ts_omit_relayserver,ts_omit_remoteconfig,ts_omit_resolved,ts_omit_routecheck,ts_omit_runtimemetrics,ts_omit_sdnotify,ts_omit_serve,ts_omit_serviceclientprefs,ts_omit_ssh,ts_omit_synology,ts_omit_syslog,ts_omit_syspolicy,ts_omit_systray,ts_omit_taildrop,ts_omit_tailnetlock,ts_omit_tap,ts_omit_tpm,ts_omit_tundevstats,ts_omit_udptransport,ts_omit_unixsocketidentity,ts_omit_useexitnode,ts_omit_useproxy,ts_omit_usermetrics,ts_omit_useroutes,ts_omit_wakeonlan,ts_omit_webbrowser,ts_omit_webclient

Was it me who actually disclosed the tailscale bug weeks ago?? 😂 tailscale#21098

There is a tiny incompatibility when using Apple containers and enable its DNS routing, that collides with MagicDNS currently. But that is so minute and special that I do not even consider this a flaw in either projects. Recommended writeup of this problem -> tailscale#17096