Tailscaleに関する技術的な指摘を、DNS、netfilter、MTU、アクセス制御、認証の観点から再検証するイメージ

「Tailscaleやめたい」の7つの技術的指摘を2026年9月時点で再検証

修正された問題、現在も残る問題、RFC解釈を一次情報で確認する


著者: 竹洞 陽一郎

2026年5月5日に公開された「Tailscaleやめたい」という記事では、Tailscaleについて、LinuxのDNS設定、EDNS、100.64.0.0/10、netfilter、MTU、アクセス制御、SSOという7つの観点から具体的な問題点が指摘されています。
元記事の著者自身も、冒頭で「既に修正されたものもありますし、自分の設定が悪いだけのものも混ざっているかもしれません」と述べ、修正済みの問題や設定に起因する可能性がある問題が含まれることを明記しています。

元記事には、EDNS処理の不具合のように実在し、その後修正された問題や、resolv.confのoptionsの扱い、CGNAT drop ruleの範囲指定、fwmarkの競合のように、現在も設計上の制限として残る問題が含まれています。
実際に運用して問題を踏み、その事実を公開してくださったことは、Tailscaleを利用するすべての人にとって価値があります。
一方で、元記事には、公開時点の実装や一次資料と照合すると事実と異なる記述や、Tailscaleの意図的な設計判断を不具合として扱っている箇所も含まれています。
元記事を参考にTailscaleの導入を検討する企業が、修正済みの問題や誤った解釈を前提に判断すれば、判断そのものを誤ることになります。
Velumeshは株式会社Spelldataが運営するTailscaleの日本正規代理店であり、導入を支援する立場から、正確な情報を提示する責任があります。
そのため本記事では、元記事の指摘のどれが事実で、どれが修正済みで、どれが見解の違いなのかを、一次資料に基づいて明確にします。

本記事では、元記事で扱われた事象と現在のTailscaleの実装を、現在確認できる一次資料と照合し、各指摘を個別の主張に分解して、2026年9月現在どの分類に当たるのかを再検証します。

検証では、Tailscaleの公式ドキュメント、TailscaleのGitHub上のIssue・Pull Request・現行ソースコード（mainブランチ）、RFC Editorが公開しているRFCを優先して確認しています。
2026年9月16日時点の最新安定版は、2026年9月10日に公開されたTailscale v1.102.4です。

判定の分類

本記事では、元記事の7つの指摘を、それぞれ個別の主張に分解し、次の5つに分類して判定します。

先に結論

7つの指摘に含まれる主張の判定内訳（2026年9月時点）
指摘主張数判定の内訳
1. /etc/resolv.confの扱い3事実誤認・解釈の間違い 3件
2. RFC違反のDNS実装7当時は正しかったが修正済み 1件、事実誤認・解釈の間違い 5件、現在も未解決事項 1件
3. 100.64/10を全部drop5Tailscaleとの考え方の違い 1件、事実誤認・解釈の間違い 2件、現在も未解決事項 2件
4. iptables・netfilterへの介入4当時は正しかったが修正済み 1件、Tailscaleとの考え方の違い 1件、事実誤認・解釈の間違い 1件、現在も未解決事項 1件
5. MTU 12802Tailscaleとの考え方の違い 1件、事実誤認・解釈の間違い 1件
6. ACLでDenyを書けない2Tailscaleとの考え方の違い 2件
7. SSOを強制3Tailscaleとの考え方の違い 3件

1. /etc/resolv.confの扱い

元記事では、tailscaledが起動するたびに/etc/resolv.confを書き換え、MagicDNSの100.100.100.100を挿入すると説明しています。
この表現は、現在のTailscaleの一般的な動作を説明するものとしては広すぎます。

Tailscaleの公式ドキュメント「resolv.confが上書きされるのはなぜですか？」では、Tailscaleが/etc/resolv.confを直接書き換えるのは、次の3つの条件をすべて満たす場合であると説明しています。

systemd-resolvedなどと協調できる環境では、直接書き換えは行われません。
また、tailscale set --accept-dns=falseを使えば、デバイス単位でTailscaleによるDNS設定の受け入れを無効にできます。
なお、同文書によれば、--accept-dns=falseにしてもtailnetでMagicDNSが有効である限り、100.100.100.100のresolver自体はtailscaled内で応答を続けます。

一方で、元記事が「systemd-resolvedとの相性が破滅的に悪い」と表現している事象は、公式の「Linux DNSの設定」では、Amazon Linux（特にAmazon Linux 2023）に限定された既知の問題として説明されています。
Tailscaleが退避したresolv.confへsystemd-resolvedが100.100.100.100を追加し、Tailscaleがそれを上流DNSとして再読み込みすることで、自分自身へ問い合わせるループが発生するというものです。
公式文書は、その原因をAmazonのカスタム設定によってsystemd-resolvedがレガシーモードで動作していることと説明し、Amazonの設定をマスクして/etc/resolv.confをスタブリゾルバへ向け直す回避手順を示しています。
つまり、一般的なsystemd-resolved環境で発生する問題ではなく、特定ディストリビューションの設定に起因する事象であり、公式に対処手順が文書化されています。
「LinuxのDNS管理との組み合わせに注意が必要」という問題提起自体は妥当ですが、systemd-resolved全般との非互換として一般化した点と、公式の回避手順に触れていない点は正確ではありません。

また、現行ソースコード（net/dns/manager_linux.go）では、systemd-resolvedの稼働状態とResolvConfModeをD-Bus（org.freedesktop.resolve1）経由で確認しており、symlink先のファイル名は判定材料の一つにすぎません。
そのため、「symlink先のファイル名だけでsystemd-resolvedを判定している」という説明は、少なくとも現行実装全体には当てはまりません。

第1節の判定
元記事の主張検証結果分類
tailscaledは起動するたび/etc/resolv.confを書き換えるDNS managerを検出できない場合に限り直接書き換える。--accept-dns=falseで無効化も可能事実誤認・解釈の間違い
systemd-resolvedに100.100.100.100が混入してDNSが停止するAmazon Linuxのレガシー設定に限定された既知問題で、公式文書に回避手順あり。systemd-resolved全般の話としては裏付けなし事実誤認・解釈の間違い
symlink先のファイル名だけでsystemd-resolvedを判定している現行実装はD-Bus経由で稼働状態とResolvConfModeを確認事実誤認・解釈の間違い

2. 「RFC違反のDNS実装」

この項目は、元記事が記録した挙動と現在の実装との差が最も大きい部分です。
ただし、元記事が指摘したEDNS処理の問題そのものは実在していました。

EDNSのUDP payload sizeを無視していた問題は修正済み

TailscaleのGitHub Issue「Tailscale DNS completely ignores EDNS metadata #18107」では、クライアントがEDNSで広告したUDP payload sizeを超える応答を返し、TC（Truncated）bitも設定しない問題がBugとして扱われました。
この問題に対するPull Request #18157は2026年1月31日にmergeされています。
現在の実装は、UDP応答がEDNSで広告されたサイズ、またはEDNSを使わない場合の512 bytesを超えたとき、TC bitを設定してクライアントへTCPでの再問い合わせを促します。

Issue #18107はPR mergeの通知と同じ2026年2月2日にcloseされています。
その後、2026年2月24日時点でTailscale 1.94.2ではまだ問題が再現するとの報告がありましたが、2026年3月23日には同じ報告者から、1.96.2へ更新した結果、UDP応答のTC bitを認識してTCPへfallbackする動作が確認できたと報告されています。
したがって、元記事にある「Tailscale DNSはTC bitすらセットしない」という指摘は、現在のTailscaleには当てはまりません。

なお、現行コードはサイズ超過時にTC bitを設定する方式であり、応答本体を広告サイズ内に収める実装ではありません。
PR作者自身も2026年2月2日のコメントで、「完全な解決ではないが、クライアントがTC flagを認識してTCPで再試行する限り挙動は改善する」と述べています。
相互運用性は大きく改善されていますが、Tailscale側もこれを最終形とは位置づけていない点は押さえておく必要があります。

RFC 6891の「MUST NOT違反」という説明は正確ではない

元記事では、RFC 6891が「responder MUST NOT exceed the requestor's buffer size」と規定しているとして、Tailscaleの挙動をMUST NOT違反と評価しています。
しかし、RFC 6891 Section 6.2.3は、requestor's UDP payload sizeを「requestorのネットワークスタックが再構成して受け取れる最大UDP payload」と定義し、requestorに対して実際に受信できる値を広告するようSHOULDとしています。
RFC 6891には、元記事に記載された文言そのもののMUST NOTはありません。

ただし、元記事の結論そのものに規格上の根拠がなかったわけではありません。
RFC 1035 Section 4.2.1は、UDPで運ばれるDNS messageを512 bytesに制限し、それより長いmessageはtruncateしてTC bitを設定すると規定しています。
修正PR #18157の説明文も、EDNSの広告サイズに加えて「RFC 1035のdefault 512-byte limit」を根拠としています。
つまり、元記事のRFC番号と引用文は誤りですが、「サイズ超過時にTC bitを設定すべき」という要求自体はRFC 1035に基づくものです。

DNS over UDPでIP fragmentationを避けるための現在の直接的な文書としては、2025年1月公開のRFC 9715があります。
RFC 9715はInformational RFCですが、UDP responderに対して、requestorが提示した最大UDP payload size、インターフェースMTU、ネットワークMTU、RECOMMENDEDとされる最大値1400 bytesの最小値に収まるよう応答を構成することをshouldとしています。
なお、RFC 9715 Section 3は、これらの推奨事項がグローバルIPアドレスを持つノードを対象とし、プライベートネットワークやローカルネットワークは対象外であると明記しています。
端末内のstub resolverである100.100.100.100に直接適用する文書ではないため、あくまで参考として扱う必要があります。

また、DNS Flag Day 2020が提案した1232 bytesは重要な運用上の目安ですが、1232 bytesを超えたこと自体をRFC上の一律な「違反」と表現するのは適切ではありません。
RFC 9715は、Appendix AでDNS Flag Day 2020の1232 bytesを経緯として紹介したうえで、現在は1400 bytesを推奨最大値としています。

EDNS有無によるsplit-brain cacheの原因

元記事では、EDNSの有無によってキャッシュが分かれ、digとnslookupで異なる結果が返る問題もTailscaleの問題として挙げています。
この件を扱ったIssue #17381（2025年10月1日起票）では、報告者の環境はtailnetのDNS設定でQuad9を上流として指定していました。
Tailscale側との確認の結果、TailscaleのDNS resolverはキャッシュを持たず、問い合わせをそのまま転送するだけであることが分かり、報告者は2025年10月2日に「対処すべき点はない」としてIssueをcloseしています（Closed as not planned）。
同日、報告者は9.9.9.9自体がEDNS有無で別々にキャッシュする挙動を示すことを確認し、tailscaledは原因ではなかったと結論づけています。

上流からのTC bit応答に対するTCPフォールバック

元記事は、「上流からTC bit付きで返ってきても自分自身がTCPフォールバックできない」とも述べています。
しかし、現行のnet/dns/resolver/forwarder.goには、上流からのUDP応答にTC bitが設定されていた場合にTCPで再試行する処理があり、無効化するには環境変数TS_DNS_FORWARD_SKIP_TCP_RETRYまたはコントロールプレーン側の設定を明示する必要があります。
この処理は少なくともv1.60.0（2024年）のソースコードに既に存在しており、元記事公開時点でも実装されていました。
したがって、この主張は元記事公開時点でも事実と異なります。

EDNS Client Subnetとndotsについて

元記事は、「EDNS Client Subnetを勝手にstripして米国IPに置換する挙動があり、日本から繋いでいるのにCDNが米国エッジへ誘導し、MagicDNSを通すだけで約100msの遅延が乗る」と述べています。
EDNS Client Subnet（ECS、RFC 7871）は、上流のリカーシブリゾルバが権威DNSサーバへ問い合わせる際に、クライアントのサブネット情報を付加する仕組みであり、CDNはこれを使って近いエッジサーバを返します。
ECSを付加するのはリカーシブリゾルバであって、端末側のスタブリゾルバや転送器ではありません。

現行ソースコードでは、net/dns/resolver/tsdns.goのResolver.Queryが受け取ったDNSパケットをそのままforwarder.forwardWithDestChanへ渡し、sendUDP、sendTCP、sendDoHはいずれもfq.packetを無加工で上流へ送信しています。
経路上でパケットに手を加えるのはclampEDNSSizeのみで、この関数はオプションコードを持たないOPTレコードのUDPペイロードサイズだけを書き換え、ECSのようにオプションを含むOPTレコードは処理対象外としています。
net/dns/配下にECSを解釈、生成、削除、置換するコードは存在せず、元記事公開時点に近いv1.96.2およびv1.98.1のforwarder.goにも該当する処理はありません。

一方、元記事が観測した症状そのものは、Tailscaleと無関係に発生する既知の現象です。
Cloudflareの1.1.1.1公式FAQは、1.1.1.1がプライバシー重視のリゾルバであり、権威DNSへの問い合わせにクライアントのIP情報を含めず、ECSヘッダを送信しないと明記しています。
この場合、CDNの権威DNSはCloudflareのリゾルバの送信元IPアドレスからクライアントの位置を推定するため、anycastで分散したリゾルバの所在地によってエッジ選択がクライアントの実際の所在地とずれることがあります。
Quad9も標準の9.9.9.9はECSを送らず、ECS対応版として9.9.9.11を別に提供しています。
Tailscaleのnet/dns/publicdns/publicdns.goは、tailnetやOSのDNS設定で1.1.1.1や8.8.8.8などの既知のリゾルバが指定されている場合にDoHへ自動的に切り替えますが、ECSには関与しません。
同ファイルには9.9.9.11を「+ECS +DNSSEC」と注記するコメントがあり、Tailscale自身がリゾルバごとのECS対応の違いを認識したうえで、ECSに手を加えずに転送していることが分かります。

したがって、「MagicDNSを通すだけで」という元記事の表現の実態は、「tailnetまたはOSのDNS設定で指定されたECS非対応のリゾルバで解決した」ということであり、Tailscaleを使わずにOSのDNSを1.1.1.1にしても同じ結果になります。
Exit Node経由でDNS解決を行っていた場合には、Exit Nodeの所在地とそのDNS設定によっても同じ症状が起こります。
元記事はこれらの構成を示しておらず、原因として挙げたECSの改変処理は当時のコードにも現行コードにも存在しないため、この主張は事実誤認と判定します。

一方、resolv.confをTailscale自身が直接生成するdirect modeでは、現行コードのwriteResolvConf関数はnameserverとsearch domainのみを書き出す構造になっています。
これは、Tailscaleの内部表現であるOSConfig構造体（net/dns/osconfig.go）がNameservers、SearchDomains、MatchDomains、Hostsしか持たず、glibcのresolv.conf(5)に固有のoptionsを表現する場所がないためです。
OSConfigはsystemd-resolved、NetworkManager、Windows、macOSなどOSごとに異なるDNS管理機構へ同じ設定を渡すための共通の抽象であり、direct modeはDNS managerが見つからない場合にこの抽象からresolv.confを生成する経路です。
既存ファイルを編集する経路ではないため、バックアップした元ファイルからもreadResolvが読み取るのはnameserverとsearch domainだけです。

この挙動は、Tailscale社内からも問題として起票されています。
「Tailscale with MagicDNS enabled removes pre-existing resolv.conf options #13245」は、2024年8月23日にTailscaleのKubernetes Operator開発者が起票したもので、Kubernetes環境でoptions ndots:5が消えるとサービス名の短縮形（kuard.defaultなど）が解決できなくなることを、再現手順付きで報告しています。
起票者は、optionsの保持は技術的には容易だが、既存のoptionsをTailscaleのDNSと組み合わせても問題が起きないことを確認できることが前提だと述べています。
このIssueは「Closed as not planned」でcloseされており、現時点で対応予定はありません。
したがって、options ndots:5などに依存する環境では注意が必要という元記事の指摘は、現在も有効です。

第2節の判定
元記事の主張検証結果分類
EDNSで広告されたUDP payload sizeを無視し、TC bitも設定しないIssue #18107で確認され、PR #18157（2026年1月31日merge）で修正。1.96.2で動作確認の報告あり当時は正しかったが修正済み
RFC 6891のMUST NOT違反RFC 6891に該当する文言は存在しない。TC bit設定の要求自体はRFC 1035 Section 4.2.1に基づく事実誤認・解釈の間違い
1232 bytes超過はDNS Flag Day 2020違反1232 bytesは運用上の目安であり規範ではない。RFC 9715の推奨最大値は1400 bytes事実誤認・解釈の間違い
上流のTC bit応答をTCPでフォールバックできないv1.60.0以降のソースコードにTCP再試行処理が存在事実誤認・解釈の間違い
EDNS Client Subnetをstripして米国IPへ置換するECSは上流リゾルバが付加するもので、Tailscaleの転送コードはECSに関与しない。1.1.1.1がECSを送らないのはCloudflareの公式仕様であり、症状はTailscaleと無関係に発生する事実誤認・解釈の間違い
EDNS有無でsplit-brain cacheが発生するTailscaleのDNS resolverはキャッシュを持たない。報告者自身が上流Quad9の挙動と確認しIssueをclose事実誤認・解釈の間違い
options ndots:5が剥がされる内部表現OSConfigにoptionsを保持する場所がなく、direct modeはnameserverとsearchのみを書き出す。Tailscale社内起票のIssue #13245は「Closed as not planned」現在も未解決事項

3. 100.64.0.0/10をハードコードでdropする問題

この指摘の中心部分は、そのまま当てはまります。
Tailscaleの公式「Tailscaleのnetfilterモード」には、Linuxのデフォルトon modeでは、tailscale0以外から到着した、送信元がCGNAT rangeの100.64.0.0/10であるトラフィックをdropすると明記されています。
これは、他のインターフェースからTailscale IPアドレスをspoofされることを防ぐためのセキュリティポリシーです。
なお、このdrop ruleを実装しているのはLinuxクライアントのみで、WindowsやmacOSには存在しません。

ただし、元記事にはiptables出力の読み方に一つ重要な誤りがあります。
例示されているDROP all -- !tailscale0 * 100.64.0.0/10 0.0.0.0/0では、100.64.0.0/10は宛先ではなく送信元です。
現行ソースコード（util/linuxfw/iptables_runner.go）でも、生成されるルールは! -i tailscale0 -s 100.64.0.0/10 -j DROPです。
したがって、「tailscale0以外から来た100.64/10宛のパケットを全部drop」ではなく、「tailscale0以外から来た、送信元が100.64/10のパケットをdrop」が正しい説明です。

とはいえ、ホストがISPのCGN配下にあり、WAN側インターフェースに100.64.0.0/10のアドレスが割り当てられている場合や、LAN側でこの範囲を利用している場合には、まさにその送信元アドレスを持つパケットがdropされるため、実害は発生します。
RFC 6598（BCP 153）はこの範囲をService ProviderのCGN用途として割り当てており、企業LANでの使用は本来の用途ではありませんが、同じ範囲が2つのインターフェースに現れてもアドレス変換できる機器であれば、RFC 1918相当の非グローバル空間として使うことを条件付きで認めています（Section 4）。
ただし、Tailscaleをインストールしたホストはこの条件を満たさず、Tailscale自身がtailnetのアドレスに同じ範囲を使っていることも含めて、衝突は設計段階で確認する必要があります。
「Installing tailscale on a machine connected to a CGNAT network can brick it #12829」は2026年9月現在もopenです。
CGN配下のホストや既存の100.64/10ネットワークとTailscaleを共存させる場合には、導入前の設計確認が必要です。

一方、回避策については元記事公開時から大きく整理が進んでいます。
公式の「CGNATとの相互運用性」では、tailnetポリシーファイルのnodeAttrsでdisable-linux-cgnat-drop-rule属性を対象デバイスに付与することで、CGNAT drop ruleを無効化できると説明しています。
無効化すると、ts-input chainの100.64.0.0/10に対するルールはDROPからRETURNに置き換わり、属性を外せば自動的に元へ戻ります。
同文書は、この属性が提供される前は--netfilter-mode=nodivertが推奨されていた回避策であったと位置づけており、「Tailscaleのnetfilterモード」の文書も、nodivertを使う前にこの属性で要件を満たせるか検討するよう案内しています。
元記事が回避策として挙げていた--netfilter-mode=offまで落とす必要はありません。

ただし、この属性には注意点もあります。
drop ruleを無効化するとローカルネットワークからのIP spoofingに対する保護が外れるため、公式文書はReverse Path Filtering（rp_filter）が有効であることを確認するよう求めています。
また、範囲の部分指定はできず、無効化は100.64.0.0/10全体に対して行われます。
元記事が指摘していた「tailnet policyで利用範囲を狭く指定しても、生成されるルールは100.64.0.0/10全域である」という点は、公式文書の「制限事項」にある「範囲の一部だけを対象にする制御はできません」という記述と整合しており、正しい指摘です。

第3節の判定
元記事の主張検証結果分類
ts-inputに100.64.0.0/10全域のDROPが挿入される公式文書に明記された、他インターフェースからのIP spoofing対策Tailscaleとの考え方の違い
tailscale0以外から来た「100.64/10宛」のパケットをdropするDROP対象は宛先ではなく送信元事実誤認・解釈の間違い
tailnetポリシーで範囲を狭めてもルールは/10全域公式文書のLimitationsに「No partial range control」として明記現在も未解決事項
Issue #12829がopenのまま2026年9月時点でもopen現在も未解決事項
回避策は--netfilter-mode=offのみdisable-linux-cgnat-drop-rule属性とnodivertが公式に案内されている事実誤認・解釈の間違い

4. iptables・netfilterへの介入

TailscaleがLinuxのnetfilterへ積極的にルールを追加する点は、仕様です。
デフォルトのon modeでは、iptablesを使う場合、INPUTとFORWARDの先頭にjump ruleを挿入し、POSTROUTINGにも必要なルールを設定します。
さらにTailscaleは、自身のルールが早い順序で評価されるよう定期的に確認し、他のソフトウェアによって順序が変わった場合には元へ戻します。

したがって、「ファイアウォールルールの評価順序へTailscaleが強く関与する」という問題提起そのものは正しいです。
一方、元記事にある「--netfilter-mode=nodivertを指定しても周期再配置が止まらない」という説明は現在の公式仕様とは異なります。
公式ドキュメント「Tailscaleのnetfilterモード」は、nodivertを使う目的の一つとして、tailscaledによるperiodic repositioningを防ぐことを明示しています。
また、Changelogによれば2026年5月21日公開のv1.98.3で、netfilter modeの変更に失敗した後にルールが不整合になる問題が修正されています。

また、元記事が引用している「old hack that works for approximately nobody」というGitHub Issue「Auto-added iptables rules on Linux refer to eth0 and are otherwise nonsense #320」は、2020年4月24日に起票され、2020年5月28日にcloseされています。
当時のeth0前提やwildcard MASQUERADEの実装を、そのまま現在のLinuxサポートの実装として扱うことはできません。

ただし、fwmark競合については無視できません。
「Tailscale and Calico netfilter packet marks conflict with each other #591」は2020年7月に起票され、2026年9月現在もopenです。
2026年4月にはUniFiのUBIOSも同じmark bitと衝突するという報告が追加され、2026年7月10日にはCalicoの開発者から、kube-proxyのmark bitとも衝突しないデフォルト値（0x00000c00）を採用すれば利用者側の設定なしに共存できるという提案が投稿されています。
Issue上ではfwmarkを設定可能にする要望も出ており、KubernetesやeBPF CNI、UniFi機器などとTailscaleを同一network namespaceで組み合わせる場合には、fwmarkやfirewall hookの競合を事前に確認する必要があります。

第4節の判定
元記事の主張検証結果分類
Issue #320の「old hack that works for approximately nobody」引用は正確だが、2020年5月にcloseされた当時の実装への言及であり、現行実装には当てはまらない当時は正しかったが修正済み
INPUT／FORWARDの先頭にjump ruleを挿入し、周期的に再配置する公式文書に明記された現行仕様Tailscaleとの考え方の違い
--netfilter-mode=nodivertでも周期再配置が止まらない公式文書はnodivertの目的の一つとしてperiodic repositioningの防止を明記事実誤認・解釈の間違い
Calicoとfwmarkが衝突するIssue #591は2026年9月時点でもopen。UniFi UBIOSでも同様の報告あり現在も未解決事項

5. MTU 1280

Tailscale公式の「2つのデバイス間のTCP接続の問題のトラブルシューティング」には、TailscaleがMTU 1280を使用すると明記されています。
現行ソースコード（net/tstun/mtu.go）でも、path MTUに関する十分な情報がない場合に利用するsafeTUNMTUは1280です。

1280は保守的な設計値である

1280という値は、RFC 8200 Section 5が定めるIPv6の最小リンクMTUと一致します。
同節は、インターネット上のすべてのリンクは1280 octets以上のMTUを持つことを要求し、Path MTU Discoveryを実装しない最小限のIPv6実装は、単に1280 octets以下のパケットだけを送るという選択も可能であると述べています。
TailscaleがTUNインターフェースのデフォルトMTUに1280を採用しているのは、この「どの経路でも到達する」ことが仕様上保証された値を出発点にしているためです。

mtu.goのコメントによれば、WireGuardが付加するヘッダの最悪値（IPv6の場合）は80 bytesであり、TUN MTU 1280のパケットはワイヤ上では1360 bytesになります。
一般的な1500 bytesの経路に対して140 bytesの余裕があるため、PPPoE（8 bytes）やVXLAN（50 bytes）といった追加のカプセル化が1段入っても収まります。
また、同ファイルには1360、1400、1500、8000、9000 bytesのprobeサイズが定義されており、経路がより大きなパケットを通す場合にはprobeによってMTUを引き上げる設計になっています。

つまり、1280はスループットを犠牲にして到達性を優先した保守的な値です。
1500 MTUの経路で1280に固定すると、大きなパケットのペイロード効率は約85%に下がりますが、特定サイズのパケットだけが届かなくなる障害は原因の特定が難しいため、Tailscaleは後者を避ける側に判断を振っています。
元記事の「多段トンネルでMTUが足りなくなる」という指摘は、この保守的な値でも不足するほど深いカプセル化が重なる場合に限られます。

そのため、VXLAN、WireGuard、クラウドネットワーク、Kubernetes CNIなど、複数のencapsulationが重なる環境では、effective MTUがさらに低下する可能性があります。
Tailscaleの公式ドキュメント自身も、パケットサイズが原因となる接続問題に対して、LAN側MTUの調整またはTCP MSS clampingを案内しています。
元記事の「多段tunnel環境ではMTU設計が必要」という問題提起は妥当です。

ただし、「MTUを変更する手段は存在しない」という表現は正しくありません。
mtu.goのコメントは、ユーザーがOSのツール（ifconfig、ipなど）でTUNインターフェースのMTUをいつでも変更できることを明記しており、TUN作成時の初期値を上書きするデバッグ用途の環境変数TS_DEBUG_MTUも用意されています。
一方で、Tailscaleの管理画面やCLIの通常の設定項目としてMTUが提供されているわけではないため、この不満の背景は理解できます。

また、Changelogでは2026年5月29日（Kubernetes Operator v1.98.4）と2026年8月11日（同v1.102.2）に、ProxyGroup podのMTU clampの修正と、入出力両インターフェースへのclamp適用が記録されています。
Kubernetes環境のMTU問題については、Tailscale側も継続的に対処しています。
Path MTUのprobe機構に関する実装も進んでいますが、通常時の安全側のdefaultは1280のままです。
したがって、複雑なオーバーレイネットワークでは「Tailscaleを入れればMTUを意識しなくてよい」と考えない方が安全です。

第5節の判定
元記事の主張検証結果分類
MTUが1280に固定されているRFC 8200のIPv6最小リンクMTUに合わせた保守的なデフォルト値。probeで引き上げる設計もあるTailscaleとの考え方の違い
MTUを変更する手段が存在しないOSのツールで変更可能なことをソースコードが明記。TS_DEBUG_MTUでも初期値を上書き可能事実誤認・解釈の間違い

6. ACLでDenyを明示できない

Tailscaleは現在、新規のアクセス制御には従来のACLよりGrantsを推奨しています。
しかしGrantsもdeny-by-defaultである一方、個々のruleはallow-onlyかつadditiveです。

グラントの構文リファレンスでは、複数のgrantがmatchした場合、許可されるcapabilityはunionとして結合され、よりspecificなgrantが広いgrantを上書きしないことが明記されています。
つまり、従来型ファイアウォールのように「広く許可したあとで一部だけdenyする」、あるいは「一部をdenyしたあとで別ruleを評価する」というordered rule modelではありません。

たとえば、「SSHはtrusted groupからだけ許可するが、それ以外のportは全員に許可する」という要件を、allow SSH、deny SSH、allow anyという順序依存のruleで表現することはできません。
広いallowが存在すれば、そのallowが持つ権限は他のruleによって差し引かれないため、必要な許可範囲を最初から狭く構成する必要があります。

従来ACLについても、公式の「ACLポリシーの例」は、aclsフィールドを省略した場合にはデフォルトの全許可ポリシーが適用されると明記しています。
deny allにしたい場合には、"acls": []を明示する必要があります。
この点についての元記事の指摘は正しいです。

なお、denyをルールとして書くことはできませんが、tailnetポリシーファイルのtestsセクションでは、特定の送信元が特定の宛先へ到達できないことをdenyとして検証できます。
「ACLポリシーの例」の「ネットワークのマイクロセグメンテーション」では、セグメント間の到達不可をtestsで確認する例が示されています。
意図しない許可が混入していないかをポリシー保存時に検出する手段として、denyルールの代わりに活用できます。

第6節の判定
元記事の主張検証結果分類
個別ルールでdenyを書けないACL、Grantsともにallow-onlyかつadditiveな設計。testsでdenyを検証する手段はあるTailscaleとの考え方の違い
aclsを省略するとdefault allow all公式の「ACLポリシーの例」に明記。"acls": []でdeny allTailscaleとの考え方の違い

7. SSOを強制する設計

Tailscaleが独自のメールアドレスとパスワードによるsign-upを提供せず、外部のidentity providerを利用するという基本設計は変わっていません。
公式の「サポートされているSSOアイデンティティプロバイダ」でも、Tailscaleは設計上アイデンティティプロバイダではないため、Tailscaleのパスワードというものは存在しないと説明しています。

なぜ独自のパスワードを持たない設計なのか

Tailscale自身は、同じ文書でこの設計の理由を次のように説明しています。
アイデンティティプロバイダは、セキュリティの中核であり複雑な領域であるアイデンティティと認証を扱うための堅牢なインフラを構築しており、Tailscaleはその専門性を理由にユーザー認証をアイデンティティプロバイダに委ね、セキュアなネットワーキングに集中している。
また、アイデンティティプロバイダの利用はメールアドレスとパスワードより安全であるだけでなく、接続暗号鍵の自動ローテーションや、多要素認証などチームが定めたセキュリティポリシーの適用を可能にする。
以下では、この公式の説明を、Tailscaleの脅威モデルと公開統計の側面から補強します。
ここからの評価はVelumeshのものです。

この設計は、Tailscaleにとって最大のリスクが「認証情報の漏洩」であることを前提にしています。
Tailscaleでは、各デバイスはIdPで認証されたユーザーに紐づいてtailnetへ参加し、通信相手はコントロールプレーンが配布したキーとポリシーによって決まります。
従来型VPNのようにインターネットへ公開されたログイン画面や管理画面を持たないため、攻撃者が最初に狙う対象は「公開されたVPN機器の脆弱性」から「正規ユーザーの認証情報」へ移ります。
つまり、Tailscaleにおいて認証情報が漏洩すれば、それはtailnetへの入場券が漏洩したことと同義です。

この前提に立つと、Tailscale自身がメールアドレスとパスワードの組を保管することは、守るべき認証情報の保管場所を一つ増やすことを意味します。
パスワードを保持しなければ、Tailscaleからパスワードが漏洩することはなく、多要素認証、パスワードポリシー、退職者のアカウント停止、条件付きアクセスといった認証に関する統制は、組織がすでに運用しているIdPに集約されます。
「SSOを強制する」という設計は、利便性のための制約ではなく、認証情報の保管と管理を一箇所に限定するためのセキュリティ上の判断です。

統計が示す認証情報漏洩の実態

認証情報の漏洩が主要な侵入経路であることは、複数の一次資料が示しています。

警察庁「令和７年におけるサイバー空間をめぐる脅威の情勢等について」（2026年3月）によれば、2025年のランサムウェア被害報告は226件で、被害組織へのアンケートでは侵入経路の6割以上をVPN機器が占めています。
同報告書は、攻撃者が「未修正のぜい弱性、漏えいした認証情報や簡易なパスワード、設定不備等を悪用して組織のネットワークへ侵入する」と説明し、2025年10月の通販大手の事案では、攻撃者が認証情報を窃取して複数のサーバへアクセスした経緯を記載しています。
また、「令和７年上半期」の報告書は、VPNやリモートデスクトップ機器からの侵入が感染経路の8割以上を占め、その原因として「当該機器のID・パスワード等が非常に安易であったこと」「不必要なアカウントが適切に管理されずに存在していたこと」を挙げています。
日本国内では、VPN機器という「公開された入口」と、そこに設定された「弱い認証情報」「管理されていないアカウント」の組み合わせが、ランサムウェア被害の主因になっています。

Verizonの「2026 Data Breach Investigations Report」（2026年5月19日公表）では、脆弱性の悪用が侵害の31%を占めて初期侵入経路の1位となりましたが、Verizon自身が、これは19年の報告書の歴史で初めて盗まれた認証情報を上回ったものだと説明しています。
つまり2025年までの18年間、盗まれた認証情報は一貫して最大の侵入経路でした。
同報告書は、第三者（サプライチェーン）が関与する侵害が前年比60%増の48%に達したことも示しており、外部委託先やSaaSに付与した認証情報の管理が、自組織の境界の外側にまで広がっていることを示しています。

Microsoftの「Digital Defense Report 2025」は、観測したID関連攻撃の97%がパスワードスプレー攻撃であったと報告しています。
同社の公式ブログによれば、2025年上半期のID関連攻撃は32%増加し、攻撃に使われる認証情報の多くは漏洩した認証情報リストとインフォスティーラー（情報窃取型マルウェア）から供給されている一方、多要素認証はID関連攻撃の99%以上を防ぐとしています。
パスワードという認証手段そのものが大量攻撃の対象であり、多要素認証を「例外なく」適用できるかどうかが防御の成否を決めています。

認証基盤の統合はモダンなITシステムの必須要件

上記の統計は、次の3点を示しています。

この3点に対して、システムごとに個別のID・パスワードを持つ構成では、多要素認証の適用漏れとアカウントの棚卸し漏れが、システムの数だけ発生します。
IdPに認証を集約すれば、多要素認証の強制、パスワードレス認証への移行、入退社に連動したアカウントの有効化と無効化、認証ログの一元的な監査を、すべてのシステムに対して一箇所で実施できます。
これは、ゼロトラストの考え方において「ネットワークの境界」ではなく「ユーザーとデバイスの認証」を信頼の根拠に置くための前提条件でもあります。

Tailscaleが独自パスワードを提供せずIdPを必須としているのは、この統合を前提とした設計です。
元記事が「SSOの強制」を制約として捉えたのに対し、Tailscaleは、VPN製品が独自の認証情報を保持すること自体を、上記の統計が示すリスクの再生産とみなしています。
「メールアドレスとパスワードで手軽に始めたい」という要望と、「認証情報の保管場所を増やさない」という設計は両立せず、Tailscaleは後者を選んでいます。

想定される反論: 認証が分散している方が安全ではないか

認証基盤の統合に対しては、「認証情報を一箇所に集めれば、そこが破られたときの被害が最大になる。分散していれば、どこかで漏れても他は無事ではないか」という反論が考えられます。
この反論には、暗黙の前提が3つあり、いずれも前節までの統計と整合しません。

漏れた認証情報は、そのシステムにしか使えないという前提
パスワードの使い回しにより、1つのシステムから漏れた認証情報は他のシステムへの攻撃に転用されます。
ID関連攻撃の97%がパスワードスプレーであるというMicrosoftの観測は、攻撃者が「どこかで漏れた認証情報」を「別のどこか」で試すことを前提に動いている事実を示しています。
分散は被害を局所化せず、攻撃者の試行先を増やします。
分散した各システムが同等に守られているという前提
警察庁が侵入原因として挙げた「不必要なアカウントが適切に管理されずに存在していた」という状況は、認証が分散しているからこそ生じます。
システムが10あれば、多要素認証の適用漏れ、退職者アカウントの残存、パスワードポリシーの不統一が10箇所で独立に発生します。
防御側はすべての箇所で正しくなければならず、攻撃側は1箇所の漏れで足ります。
1つのシステムへの侵入はそのシステム内で止まるという前提
VPNの認証情報は「ネットワークへの入口」です。
認証が分散していても、VPNの認証情報が1つ漏れれば、その先のネットワーク全体が侵入経路になります。
警察庁の統計でVPN機器が侵入経路の6割以上を占めているのは、この構造によるものです。

統合が優位である理由は2つあります。
第一に、認証情報の保管場所と認証ロジックの実装箇所が減れば、脆弱性、設定不備、運用漏れが発生し得る箇所、すなわち攻撃対象領域（Attack Surface）が減ります。
第二に、集約した一点は、分散していた個々の点より格段に強く守れます。
フィッシング耐性のある多要素認証、パスワードレス認証、デバイス状態に基づく条件付きアクセス、異常なサインインの検知、入退社に連動したアカウント無効化は、IdPに集約すれば1回の実装ですべてのシステムへ適用されます。
これらを分散した個々のシステムに実装することは、コスト面でも運用面でも現実的ではありません。

なお、反論側が守りたい「1つ漏れても全体は無事」という性質は、認証情報を分散させることではなく、認証後の権限を最小化することで実現します。
Tailscaleでは、ACLやGrantsによって「そのユーザーのそのデバイスが到達できる範囲」を明示的に限定するため、1つのアイデンティティが侵害されても、被害はポリシーで許可された範囲に留まります。
第6節で扱ったallow-only、additiveなポリシーモデルは、この観点では利点として働きます。

ただし、統合に単一障害点のリスクがあること自体は事実です。
IdPそのものが攻撃対象になる事例は現実に存在し、Microsoft Digital Defense Report 2025も、クラウドID基盤に対する不正なOAuthアプリ、レガシー認証の悪用、Adversary-in-the-Middle攻撃を主要な脅威として挙げています。
したがって正しい結論は「統合すれば安全」ではなく、「統合したうえで、集約した一点への補償統制を置く」です。
Tailscaleの文脈では、次の3つが補償統制になります。

Passkey管理者
IdP障害やアカウント喪失時の復旧手段（次項で扱います）。
Tailnet Lock
新しいノードの公開鍵は、tailnet内の信頼済み署名ノードによる署名がなければ他のノードから受け入れられません。
署名キーはコントロールプレーンが生成・保存・閲覧しないため、ホワイトペーパーが述べるとおり、コントロールプレーンが侵害されても不正なノードを挿入できず、盗まれた認証情報で新しいデバイスを登録しようとする攻撃も、署名がなければ通信できません。
一方、すでに署名済みのデバイスが乗っ取られた場合には効果がないことも公式文書に明記されています。
ACL/Grantsによる最小権限
アイデンティティ侵害時の被害範囲を、ポリシーで許可された範囲に限定します。

IdP依存のリスクとその対策

したがって、「認証基盤をIdPへ依存する」という元記事の指摘自体は正しいです。
一方で、「IdPが使えなくなれば管理者もtailnetへ入れなくなる」というリスクと、「tailnet全体のidentityが特定のIdPに固定される」という制約には、明確な対策があります。

Tailscaleは「パスキーでログインできる管理者アカウント」で、SSO IdP障害時に備えて、事前にPasskeyでログインできる管理者を作成することを推奨しています。
PasskeyでログインするユーザーはSSO identity providerへ依存せず、Admin roleがあればユーザー招待、デバイス承認、ポリシー変更などの復旧作業を行えます。
そのため、企業利用ではbreak-glass用Passkey管理者を用意することが重要です。

さらに、2026年7月6日のChangelogによれば、Owner roleのユーザーはAdmin consoleから対応するidentity providerを切り替えられるようになっています（beta）。
元記事が懸念する「VPNにIdPの寿命を縛られる」という構造は、少なくとも対応IdP間の移行という形では緩和されています。

コントロールプレーンが非公開である点について

また、元記事が指摘している「Tailscaleのhosted coordination serverがclosed source」である点は事実です。
Tailscale自身も「Tailscaleにおけるオープンソース」で、クライアントのコアコードとDERPはopen sourceである一方、hosted coordination serverはproprietaryであると説明しています。
HeadscaleはTailscaleとは独立したopen-sourceのcoordination server implementationです。

ただし、coordination serverへ接続できなくなった瞬間に既存のVPN通信が停止するわけではありません。
公式の「What happens if the coordination server is down?」では、既存デバイスはローカルに保持しているキーとポリシーを使って通信を継続できる一方、新しいデバイスの追加、キー更新、ポリシー更新などができなくなると説明しています。

第7節の判定
元記事の主張検証結果分類
メールアドレスとパスワードによる登録がないTailscaleはidentity providerではないと公式が明記。認証情報の保管場所を増やさず、多要素認証とアカウント管理をIdPへ集約するための設計Tailscaleとの考え方の違い
IdPアカウントを失うとtailnetから締め出されるPasskey管理者で緩和可能。2026年7月からはOwnerによるIdP切り替えも可能（beta）Tailscaleとの考え方の違い
コントロールプレーンがclosed source公式がhosted coordination serverをproprietaryと明記Tailscaleとの考え方の違い

この記事から現在も学ぶべきこと

26件の主張のうち、「当時は正しかったが修正済み」が2件、「事実誤認・解釈の間違い」が12件、「Tailscaleとの考え方の違い」が8件、「現在も未解決事項」が4件でした。「根拠不足」に該当する主張はありませんでした。
事実誤認が最も多い一方で、Tailscaleの設計思想に由来する制約と、未解決の問題も確かに存在します。
すべてを「古い記事」として退けるのは適切ではありません。

Tailscaleの「It just works」は、複雑なnetworkingを隠蔽することで実現しています。
しかし、隠蔽されているからといって、OSのrouting、DNS、ファイアウォール、MTUとの相互作用がなくなるわけではありません。
特に既存ネットワークが複雑な企業環境では、導入前にこれらの相互作用を理解し、必要な例外設計を行うことが重要です。
Velumeshの導入支援では、初回技術ミーティングで既存ネットワーク構成を共有いただく際に、100.64.0.0/10の重複、Linux DNS managerの構成、多段トンネルによるMTUへの影響、IdP障害時の復旧手段を確認項目として扱います。

一方で、今回の再検証から分かるように、Tailscale側もEDNS処理、CGNAT drop ruleの制御、netfilterの制御方法などを継続的に改善しています。
技術記事を参照して製品を評価する際には、その記事が書かれた時点の実装だけでなく、現在の公式文書、Issueの最終結論、修正されたPull Requestまで確認する必要があります。

参考資料

本記事では、Tailscaleに有利な情報だけでなく、現在も残る設計上の注意点も含めて整理しました。
Tailscaleの導入前設計、既存VPNからの移行、Subnet Router、Exit Node、Kubernetes、アクセス制御などについてのご相談は、お問い合わせからご連絡ください。