2 ポイント 投稿者 GN⁺ 2024-07-28 | 1件のコメント | WhatsAppで共有
  • Tailscaleは、開発者が不要なスケーラビリティ偏重の構造に縛られないよう、すべてのデバイスが安全に直接接続される新しいOSIレイヤー3を作ろうとしている
  • 多くのプログラムは実際には大規模スケールを必要としないが、Kubernetes、コンテナデプロイ、クラウドログ収集が標準になったことで、開発と運用が遅くなったと見ている
  • IPv4不足、NAT、ファイアウォール、動的IP、TLS証明書の仕組みはクライアントとサーバーを分断し、AWSのような中央クラウドプロバイダーを接続性の中心に据えている
  • Tailscaleは各デバイスに証明書、IPアドレス、DNS名、エンドツーエンド暗号化、IDを与え、ファイアウォールの背後でも安全に接続し、すべてのデバイスをピアにしようとしている
  • TaildropのHTTP PUTベースのファイル転送は、中間クラウド層を減らせることを示しているが、この種のアプリのエコシステムが生まれるには、まず十分な普及が必要になる

Tailscaleビジョンの出発点

  • Tailscaleは短期的な機能より大きなビジョンを公に多く語ってこなかったが、一部の企業は現在の機能だけでなく、将来可能になる接続性を理由にTailscaleを導入している
  • 初期の問題意識はネットワーキング企業になることではなく、開発者がスケールさせる必要のないものまでスケールさせようとすることで、開発体験が悪化している点にあった
  • 1990年代のLAN体験を覚えている世代がTailscale創業の文脈にあり、その体験が現在の技術的複雑さを比較する基準になっている
  • コンピュータ性能、プログラミングの敷居、アプリストア、決済システム、グラフィックスは改善したが、開発者の日常作業のうち、以前は簡単だった多くのことがむしろ難しくなったと見ている

不要なスケーラビリティが生んだ開発オーバーヘッド

  • 現代の開発者は、最初のコードを書く前から10億ユーザー規模を考慮するよう訓練されており、アルゴリズムやアーキテクチャの選択でもスケーラビリティを優先しがちである
  • big-O記法を誤って当てはめると、ハッシュテーブルが配列より常に速いように見えるが、10項目程度なら配列のほうが速くシンプルな場合がある
  • スケーラブルな構造を選ぶと、実際にはスケールしないケースで、より遅く作りにくいシステムになることがある
  • 月500,000ページビューをKubernetesで処理したという事例は、秒間約0.2リクエストの水準であり、1990年代の遅いコンピュータでもPerlやPythonのプログラムはミリ秒単位で起動し、それより多くのリクエストを処理できたと比較している
  • 長いビルド、Dockerビルド、コンテナレジストリへのアップロード、数十秒から数分単位のデプロイ、遅れて届くログは、"すべてがスケールしなければならない"という前提から生まれたオーバーヘッドとしてまとめられている
  • Tailscaleは、すべての開発者がかなりの時間を費やすダッシュボードやミーム生成器のような、スケールさせる必要のないロングテール作業を簡単に作るためのツールという位置づけになっている

現在のインターネットが複雑さを増やす仕組み

  • 多くの複雑さは本質的な複雑さではなく、単純に解ける問題に複雑な解法を重ねた結果だと見なされている
    • ログシステムは一か所から別の場所へテキストをストリーミングするだけの作業なのに、結果が5分後に見えることがある
    • オーケストレーションシステムは別のプログラムを実行するプログラムにすぎないが、Unixカーネルはこれを数十年にわたりミリ秒単位で処理してきた
  • ネットワーキングは現代ソフトウェアに不可欠だが、現在のインターネットは多くの問題を難しくしている
  • Tailscaleは既存のOSIスタックの最上位にレイヤーを追加して問題を隠すのではなく、別の前提の上に新しいOSIレイヤー3を作ろうとしている

クラウドの中央集権化と接続性のレント

  • 技術業界で誰がレントを取れるかを見ればボトルネックが分かり、現在のソフトウェア配布ではAWSがその位置にあると見ている
  • クラウドはスケーラブルな計算資源を提供するが、中級クラスのMacBookでもSSD上ではクラウドのローカルディスクより10倍または100倍多い毎秒トランザクションを処理できると比較している
  • 自分のコンピュータがサーバーになりにくい理由は、場所と接続性にある
    • ファイアウォール、NAT、動的IP、非対称なネットワークリンクがある
    • ポートフォワーディング、静的IP、冗長インターネット回線を自分で構成することはできるが、多くの作業と専門性が必要になる
  • 結局、IPアドレスと帯域幅を持つホスティングプロバイダーに費用を支払うことになり、本格的な企業であれば、機器へのアクセス権を信頼できる大手プロバイダーを選ぶことになる
  • 「AWSを選んでクビになる人はいない」という構図は、かつてIBMについて語られた表現につながっている

オペレーティングシステムからHTTPSへ移ったゲートキーパー

  • IBMは中央集権型コンピューティングでレントを取ることができ、MicrosoftはPCベースの分散コンピューティングによってその構図を揺るがした
  • 現在のクラウドとスマートフォン中心の世界は、再び中央集権型に戻ったと見ている
    • 机の上やポケットの中のデバイスは20年前の基準ではスーパーコンピュータ級だが、AWSが落ちれば使えない文鎮のようになってしまう
    • サーバーのマルチインスタンスや分散合意システムがあっても、その大半は中央クラウドプロバイダーの上で動いている
  • 1990年代にはオペレーティングシステムがプログラム間の互換性と接続を左右していたが、Web以後はJavaScriptとHTTPS接続性のほうが重要になった
  • HTTPSは基本的にクライアントとサーバーの中央集権的な構造を持つ
    • サーバーは静的IP、DNS名、TLS証明書、開いたポートを持つ
    • クライアントは通常そうした要素を持たない
    • サーバーが消えれば、クライアントは何もできない
  • セキュリティ問題とIPv4アドレス不足のためにファイアウォールとNATが追加され、接続はクライアントからサーバーへ向かう一方向の構造になった

TailscaleのNew Internet

  • Tailscaleは過去5年間、この問題の解決策として製品を作ってきた
  • 各デバイスは証明書、IPアドレス、DNS名、エンドツーエンド暗号化、IDを持ち、ファイアウォールを安全に越える
  • すべてのデバイスはサーバーとクライアントという固定された役割ではなく、相互に接続されるピアになれる
  • Tailscaleはこれをレイテンシやオーバーヘッドの追加なしに実現すると見ている
  • Tailscaleユーザーはすでに、何層もの複雑なレイヤーが取り除かれた環境を体験しており、インターネットが本来期待されていたあり方により近く動作している

Taildropが示す単純化

  • Taildropは、Tailscaleが可能にする構造の小さな一例である
  • Tailscaleがすでにインストールされている状態では、Taildropの中核はHTTP PUTを1回行うだけである
    • 送信側が受信側にHTTPリクエストを送る
    • 「Xというファイルを送る」と通知する
    • ファイルを転送する
  • 従来のインターネットでは、受信デバイスがファイアウォールの背後にあり、開いたポートやIDを持たないため、クラウドにアップロードしてから再度ダウンロードする方式が必要だった
  • クラウド経由の方式は、いくつもの追加レイヤーを生む
    • ネットワーク送信コスト、保存コスト、サーバーCPUコストが発生する
    • ダウンロードされていないファイルをいつ削除するか決めなければならない
    • 使っていないときでもサーバーをオンラインに保つ必要がある
    • クラウド事業者の従業員が理論上ファイルにアクセスできるため、暗号化が必要になる
    • 暗号化のためには送信者と受信者の間で鍵交換が必要になる
    • 受信者にファイルが待機中だと知らせるには、プラットフォームごとのプッシュ通知システムが必要になる場合がある
  • Taildropは、こうしたコストのオーバーヘッドが消えるため無料のファイル転送を可能にしており、これはTailscaleの無料プランという文脈にもつながっている

普及が必要な理由

  • Taildropは些細な例ではあるが、Tailscaleがあれば10倍簡単になるプログラムのカテゴリが存在することの存在証明として機能している
  • 接続性の不足は中央集権化を生み、中央集権化は小さなプログラムにまでレントを払わせ、遅く複雑でデバッグしにくい構造を作る
  • Tailscale上でのみ動作するアプリが生まれるには、十分な人数がTailscaleを使っている必要がある
  • 普及が十分でなければ、誰もそのようなアプリを作らないという鶏と卵の問題が生じる
  • このためTailscaleは無料提供に大きな努力を注ぐ一方で、職場への導入やFortune 500企業全体への展開を容易にするエンタープライズ機能にも力を入れている

目標と現在地

  • インターネットはすべての人のためのものであり、過去には複数のinternetworkがあったが、最も多様で包摂的なInternetが勝利したと見ている
  • New Internetも、自宅の開発者、大学の開発者、企業の従業員、最終的にはすべての人が使えるものでなければならない
  • 現在、世界の人々のおよそ30,000人に1人がNew Internet、つまりTailscaleを使っている
  • Tailscaleは、すべての人が使うようになるまで止まらないという目標を掲げている
  • Microsoftがすべての机の上にコンピュータを置くという目標で嘲笑されていた時代や、TCP/IPがサードパーティから購入するオプション機能だった時代を振り返り、技術の世界は30年の間にも急速に変わりうることを強調している

1件のコメント

 
GN⁺ 2024-07-28
Hacker News のコメント
  • Tailscale、Cloudflare、Google のような企業の永遠の問題は、インターネットが本来みずから解決しているべき問題、たとえば単純なエンドツーエンドの安全な接続を代わりに解決することで、その問題が残り続けるインセンティブが生まれる点にある
    インターネットに必要なのは、DNSSEC が提供する公開鍵基盤と IPsec の自動暗号化を備えた IPv6 のようなものだが、そうしたものが広く互換性を持って実装されると、Tailscale の事業は崩れる
    結局、彼らの事業は問題が存在し続けることに依存している
    再投稿: https://news.ycombinator.com/item?id=38570370

    • もっともらしい指摘に聞こえるが、考えれば考えるほどデジタル苦行のように感じる
      IPv6 は 1998 年に登場し、Tailscale が 2019 年にリリースされるまでの 21 年間にも、言われている方式は実装されなかった
      そのとき誰が妨げていて、今は誰が妨げているのか。Google、Cloudflare、Tailscale は実際の問題を解決したからこそ、お金や個人情報のようなお金に準じる対価を受け取ったのだ
      インターネットをみんなにとってより悪くしなければ本当に良い解決策は出てこない、というような逆加速主義には同意しにくい
      Tailscale のせいでそうした解決策が出てこないのではなく、それを作るのに必要な膨大な作業量のせいであり、WireGuard がなければ Tailscale もなかった可能性が高い
      Tailscale が生まれたことで Headscale も生まれ、それは言及された「何か」を作るためのもう一つの足場になっている
    • さらに悪いことに、Tailscale には NAT とファイアウォール越えを助ける調整サーバーを使わせるインセンティブがある
      話は長いが、要点はデバイス同士が互いを見つける途中に Tailscale が座る構造だということ
      別のやり方もある。一時的な IP しか持たないデバイスに恒久的な名前を付ける動的 DNS は何十年も前からあったが、評判はあまり良くない
      互いを知っている複数の調整ノードと公開ノード一覧を使う方式も可能だ。一覧が古くなっても、生きているノードが一つでもあれば接続して更新できるし、Ethereum ネットワークや一部のファイル共有システムの基盤である Kademlia はこのように動作する
      検索と転送を分離する折衷案も可能だ。Peertube は通常の Web 検索で見つけたサーバーから HTTP でストリーミングするファイルを見つけ、実際の転送は現在の視聴者同士がブロックを送り合う分散方式なので、動画が口コミで広がってもうまくスケールする
      だから、誰かが途中で酸素チューブを断ち切れない方式でも十分に可能だ
    • 「自動 IPsec」、特にIPsec の自動化は望んでいない。ネットワーク層で強制暗号化を入れるのも、今の基準では WireGuard のようにまともなものであっても危険だ
      古い VPN プロトコルや RADIUS のような認証方式は、深刻なセキュリティホールがあっても互換性のために直しにくく、それらもインターネット全体よりはるかに小さい規模で動いている
      業界が TCP の硬直化問題を、TCP を捨てて UDP 上に再実装する形で解決しているという事実が、多くを物語っている
    • Zerotier がある程度その役割を果たしている。トンネルではあるがトラフィックは直接流れ、二重 NAT でなければエンドポイント IP に直接ルーティングできるときは zt を飛ばすこともできる
      ロケーションサービスも望めばセルフホストできるので、そのサービスを必ず使わなければならないわけではない
      DNSSEC を除けば、求めているものにかなり近い
    • それは過度に否定的な解釈だ。Tailscale の価値提案は「どこからでもネットワークへ安全に接続でき、他人は入ってこられない」ということでもある
      この価値は IPsec ができても消えない
  • レントを吸い上げる中央集権的な統制への非常に長い不満から始まっていて、それ自体は妥当な不満だ
    しかし、クライアント・サーバーコンピューティングに意味があるのか、あるいはそれがレントシーキングの原因なのかといった別の論点に迷い込んだ末に、結局「明日は Tailscale を持つ人と持たない人に分かれる」という結論にたどり着く
    王は死んだ、新王万歳という感じだ

    • 独占的なピアツーピアシステムでもレントを吸い上げられるという話には同意するが、今でも Tailscale より古く、OpenVPN でもない非独占ツールを使っている
      プログラマーではない自分でも直せるほど小さく単純だ
      みんながインターネットから直接到達可能な、ファイアウォールのない IP を持っているわけではないので、ピアツーピアを実現するためにクライアント・サーバーを使うこともある
      ホスティング会社のサーバーに「スーパーノード」を置く必要があるかもしれないが、ランデブーサーバーとしてだけ使えばトラフィックは通らず、費用は小さい
      「無料」と競争しようとする会社にはいつも強い疑いを抱く。無料ソフトウェアをやめて私たちにお金を払え、その代わり不要な機能を 100 個付けた、というようなものだ
      Slack のように、こうした企業戦略は短期的には成功し得るだろうが、この手のサブスクリプションは自分の好みではない
      核心はクライアント・サーバー対ピアツーピアではなく、独占対非独占だと思う
    • Tailscale の CEO が「明日は Tailscale を持っているかどうかで分かれ、持っていなければポスト Tailscale の世界でしか動かないアプリを動かせない」と説教しているのだろうか?
      10 年以内に Microsoft 級の大物になれなければ、好意的には受け止められにくそうだ
    • この数十年、Hamachi がかなり懐かしかった
      当時は個人用プライベートネットワークを設計して設定するのに、本当に優れていて簡単なツールだった。ファイル共有、ローカルゲームの LAN、開発協業、さらにはメディアストリーミングまで簡単にできた
      ピアツーピアの未来は Tailscale というより、異なる NAT や ASN の向こう側にあるノードを一般的に束ね、NAT traversal 技法、STUN/TURN、タートルルーティングを理解するセルフホスト版 Hamachi の派生形に近い気がする
      中央 VPN ゲートウェイなしにリモートユーザーが簡単に参加できるツールなら、現代の環境で強力な機能になるだろう
    • レントシーキングをする者は悪いと言いながら、今払っているレントに加えて自分にもレントを払えと言っている構造に聞こえる
    • 「ものすごく長い導入部」という点には同意する
      私たち全員が Iceberg Articles を学んで適用するとよさそうだ: https://john.kozubik.com/pub/IcebergArticle/tip.html
  • 実際に Tailscale を本番システムで使っている。サーバーは物理的に近い場所か、管理された別の場所にあり、数百キロ離れた数百人のユーザーが全員 Tailscale で作業している。
    2つ言っておきたい。Tailscale は驚くほど素晴らしく、本当に良い。このシステムは Tailscale なしでは存在できなかったか、24時間運用のためにチームに少なくとも10人は追加で必要だったはずだ。
    ただし期待値は下げるべき。「インターネット」ほど良くはない。レイテンシが周期的に跳ね、接続が時々切れ、MagicDNS が文字どおり魔法のように止まったり、システムと衝突したりする。
    ユーザーが多いので、起こり得る問題はほぼすべて経験してきたし、明日また新しい問題が出てくるかもしれない。
    それでも Tailscale とそのビジョンを信じている。ハードウェアの制御権を与えつつ、コストを下げ、セキュリティを高める、まったく新しいアプローチだ。
    最初の大規模な本番サーバーは 4コアの Linux ノートPC だった。

    • Tailscale 経由で4コアの Linux ノートPCを本番サーバーとして使った構成について、もっと詳しく聞きたい。
      自分も内部向けのセルフホスティングには Tailscale をよく使っているが、公開本番サービスに使うことは考えたことがないので、設定が気になる。
    • 数百キロ離れた数百人のユーザーが Tailscale で作業しているなら、ユーザーに Tailscale のインストール を求めているということか?
  • Tailscale は好きだが、この記事は不気味だ。
    インターネットが成功したのは、標準の上に作られ、完全に自由だったからだ。
    Tailscale では WireGuard がオープンソースで、Headscale のようなものもあるが、「全員が IP を持つ」という構造は、Tailscale が巨大な IP アドレス空間を所有していることに依存しているのではないか?
    完全な IPv6 普及 を待つか、中央集権的な IPv4 とサーバーと独占的なものに依存しなければならないなら、少し偽善的に見える。

    • Headscale で Tailscale の制御サーバーをセルフホストできる: https://github.com/juanfont/headscale
      Tailscale と完全に機能が同等というわけではないが、現在の機能の大半をサポートしており、日々改善されている。
      記憶が正しければ、コア開発者の一人は Tailscale から報酬を受けて作業している。
      個人のセルフホストインフラで使っているが、とてもよく動作する。カスタム制御サーバー URL の設定も、Windows と Android では比較的簡単だった。
      taildrop も使っているし、Docker コンテナを tailnet に提供するなど、Headscale は十分うまく動くので試してみる価値がある。
    • 100.64.0.0/10 はキャリアグレード NAT 用の予約 IP ブロックだ。
    • Tailscale は「インターネット」ではなく、互いに離れた複数のの束なので、巨大な IP 空間は必要ない。
      必要な IP 空間は最大の堀の大きさだけでよく、一度に接続できる堀は1つだけだ。
    • Tailscale から移行しなければならないなら、どこへ移るのか?
  • Tailscale は好きだが、この記事はあまりに自己誇示的に読める。
    付加サービスを載せたメッシュ VPN 製品であり、それ自体は優れているが、新しい、あるいは唯一のアイデアではない。
    なぜこの解決策が他の代替案ではなく、新しいインターネット でなければならないのか?
    いずれにせよ、インターネットインフラ全体を一社に依存したくはない。だから複雑でも従来のインターネットを使い続ける。
    大きな問題は技術よりも社会的なもので、新技術がそれらを解決するわけではない。

    • 現在のインターネットの大きな問題は本当に社会的なのか? 初期の約束だった100%分散型ネットワークが現実には管理するには複雑すぎて、サービスが本質的に中央集権化してしまうことが核心的な問題なら、それは深く技術的な問題に見える。
      ソーシャルメディアを例に、Facebook/Twitter/TikTok/YouTube/Reddit/HN などが BitTorrent のようにシームレスに動作する世界を想像できる。
      自分のコンピューター上のアプリが「Facebook」ネットワークに参加し、友人たちはそれぞれのアプリインスタンスを通じて自分がオンラインであることを見て、フィードやウォールは自分のデバイスから直接提供される。
      中央サーバーなしに、2人、1000人、数百万人が直接通信する構造だ。
      BitTorrent、Soulseek、Bitcoin など、すでに複数のピアツーピアネットワークが可能性を示している。
      しかし facebook.com にアクセスするのと同じくらいシームレスにするには、すべて技術的な問題が噴き出す。ポートフォワーディング、動的 DNS、高度なネットワーク・セキュリティ・システム管理の知識なしで実現できるシームレスなピアツーピア接続が最初の大きな壁だ。
      ノードがオフラインならどうするのか、フィードを取得するために何千、何万、何百万台に接続しなければならないときの遅延と負荷はどうなるのか、キャッシュはどうするのか、更新と通知はどうプッシュするのか、非常に古いノード同士はどう通信するのか、データはどこに保存するのか、発見可能性とセキュリティはどうするのか、すべて技術的な問題だ。
      ほとんどは解けるが、中央集権型サービスのように馬鹿みたいに簡単な体験に到達するには、問題を一つずつ解く膨大な努力が必要になる。
      Fediverse もこの問題の小さな一部を10年以上解いているが、それでも twitter.com と同程度か少し悪いくらいの体験を提供するには、かなり有能なシステム管理者が必要だ。
    • Tailscale の価値提案は何なのか? 複数の大物級の自由・オープンソースソフトウェアをつなぎ合わせたその場しのぎではないのか?
  • Yggdrasil が新しいインターネットになろうとしていたのではないか? https://yggdrasil-network.github.io
    そうでないなら、なぜよりによって Tailscale で、Netbird、Nebula、Netmaker や他の競合ではないのか?
    文章は非常によく書けているが、買収、移行、スピンアウト、終了のような何かが近づいているような妙な感じがする。「まだ始まったばかり」という言葉も、有名な最後の言葉のように聞こえる。
    バランスを取るために付け加えると、Tailscale ユーザーとしては満足しているし、あまり気にしなくてもそのまま動く点には感心している。

    • 説明だけを見ると Yggdrasil のほうがよく合っている。
      ただし、うまく動くとはいえ、まだ研究プロジェクトである点は考慮すべきだ。
  • Tailscale のサービスは本当に楽しく、ありがたく使っているが、この記事はしっくりこなかった
    刺激を与える CEO の結集スピーチも好きだし、コンピューティングには開発者にとっての摩擦や複雑さが途方もなく多いという点には同意するが、Tailscale にも独自の摩擦があり、大局的な問題をまったく解決する方向には進んでいない
    数週間前、父を自分の tailnet に招待して、リモートデスクトップでコンピューターの問題を直そうとした。父は招待を受け入れ、TS ドメインの Web インターフェイスにはデバイスが見えていたが、ping が通らなかった
    今では父は Tailscale を嫌っていて、私がすごいものだと言っていたせいで私への信頼度も下がった。父の目には、時間を無駄にする「まともに動かない」ものだった

    • お父さんは Windows を使っているのだろうか? Windows ファイアウォールは ICMP トラフィックをブロックすることで知られており、これは Tailscale や他のピアツーピア VPN では解決できない問題だ
    • 同じ問題かは分からないが、Gmail アドレスだけを使っている家族環境で、動作の仕組みを誤解して問題が起きたことがある
      かなり直感に反している。組織機能はそういう用途のものではなく、代わりに各自が自分の tailnet を作り、それらを接続する必要がある
      参考: https://github.com/tailscale/tailscale/issues/10731
    • おそらく新しいネットワークインターフェイスが作られ、父親か Windows がそれを ping や RDP に応答してよい信頼済みのホーム/プライベート接続と見なさなかった可能性が高い
      こういう用途なら TeamViewer や AnyDesk のようなツールが適している
    • ACL の問題という可能性もある?
  • 筆者は問題の診断を誤っており、提案している解決策は中央集権化を取り除くのではなく隠しているだけだと思う
    AWS が高い理由は IPv4 やデータセンターではなく、主にソフトウェア、マネージドサービス、サーバーを素早く追加できる能力にある
    「本気の会社」が AWS や同様の会社にお金を払いたくないなら、ラックを借りて自社サーバーをコロケーションすることは可能で、多くの会社が実際にそうしている
    証明書が中央集権化を生んだという点には同意しない。証明書は持つ者と持たざる者を分けるものでもなく、メインフレームを所有しているかどうかと比べるようなものでもない
    HTTPS が事実上必須になったから人々が自分のドメインやサブドメインを持つようになったのではなく、利便性のためにすでにそうなっていたのだ
    もう一つの中央集権化ポイントとして DNS が出てくるが、Tailscale は DNS をまったく回避していない。MagicDNS も ICANN ルートに依存しており、Tailscale のコントロールプレーンも同様だ
    無料のサブドメインが必要なだけなら、提供しているところはたくさんある
    CGNAT の背後にいるなら、tailnet も特に中央集権性が低いわけではない。トラフィックが DERP サーバーを通らなければならないからだ
    トラフィック規模が Gbps ではなく Tbps になったとき、Tailscale がこれを無料で提供し続けられるかは疑わしい
    Tailscale に似た解決策が、NAT 背後のコンピューターへアクセスする最後に残ったケースでは役に立つという点には同意するし、数千万ユーザーまで行く可能性もあると思う
    だが、それだけで新しいインターネットという称号を主張するには不十分だ

    • これは、ほとんどのアプリケーションがサーバーを素早く増やさなければならないほどの規模を必要とする、という誤った前提の上に成り立っている
      記事でもその前提は間違っていると指摘している
  • こうしたアイデアが新しくないのは当然だ
    IPv6 はすべての人にエンドツーエンド接続性を与えるためのものであり、もともと IPsec は IPv6 の必須構成要素として、各インターネットホストに暗号学的なアイデンティティを与えようとしていた

    • 記事で IPv6 にまったく触れていないのが気になった。Tailscale も IPv6 をサポートしているからだ
      IPv6 と WireGuard を一緒に使えば、プライバシー、セキュリティ、性能が得られる。欠点は設定の複雑さだ
      Tailscale は巨人の肩の上に立っている。IPv4、WireGuard、Samy Kamkar の NAT パンチング、OpenSSH など、ほかにも多いはずだ
      利点は、それらを組み合わせ、管理インターフェイスが概して簡単なことだ
      ただし、認証局についての話は Tailscale にも当てはまる。どちらも自由なオープンソースソフトウェアを使いながら、最終的には独占的なサービスを提供している
      それでも、ほぼすべてが自由なオープンソースの上にあり、Headscale も存在し、Tailscale がそれを好意的に見ているため、大きな問題ではない
      欠点ではあるが主要な欠点ではなく、実質的なベンダーロックインもほとんどない。ビジネスとサポートの観点では、むしろ利点かもしれない
  • 記事の前提は最後の段落までは本当に良かったが、そこで読み直すことになった
    Tailscale がインターネットを再び簡単にしてくれるのは確かだが、それでも地主に依存しなければならない
    インターネットではその必要はなかったし、今でも必ずしも必要ではない。多くのものが中央集権化されたとはいえ、現在でもリンク一つあれば世界中のどのサーバーにも接続できる

    • 「地主に依存しなければならない」という点は非常に良い指摘だ
      反論は、他でも言及されている Headscale のセルフホスティングだ: https://github.com/juanfont/headscale
      いくつか設定を変えるだけで標準の Tailscale クライアントと動作し、私自身も使っている