ネットワーキング 2026 完全ガイド - Cilium・WireGuard・Tailscale・Nebula・Istio・Envoy・Cloudflare Tunnel 徹底分析

はじめに — 2026年5月、ネットワーキングは「静かに標準化」した

2020年当時、K8sネットワーキングはCNIが7〜8個競合する市場であり、「チームVPN」はOpenVPN設定地獄を耐え抜くことであり、サービスメッシュ導入は「サイドカーメモリ200MB」という死刑宣告を受けることだった。2026年5月の現在、その風景はほぼすべて変わった。CiliumはK8s CNI市場で事実上の標準となり、Tailscaleは中小規模チームのVPNを席巻し、Istioのambient modeがついにプロダクション-readyとなり、サイドカーメモリ負荷を半分以下に削減した。WireGuardがLinuxメインラインに入って6年が経ち、QUIC + HTTP/3はCDNバックボーンの基本トランスポートになった。

この記事は「どのツールが良い悪い」ではなく、2026年5月時点で誰がどこでどう使っているかを正直に追う。CNI、オーバーレイVPN、サービスメッシュ、L7ゲートウェイ、ZTNA、IPv6/QUIC、そして韓国と日本のISP環境での現実まで、すべて扱う。

2026年ネットワーキングスタック — 6層に分解する

まず全体像。2026年の標準的な本番ネットワーキングスタックは次の6層に分かれる。

L2/L3 データパス(datapath): eBPF、XDP、tc、OVS、kernel netfilter、DPDK
K8s CNI: Cilium、Calico、Antrea、Flannel
オーバーレイVPN / メッシュ(mesh): WireGuard、Tailscale、Nebula、ZeroTier、Twingate、OpenZiti、Boundary
サービスメッシュ(service mesh): Istio(ambient)、Linkerd、Consul Connect、Kuma
L7プロキシ/ゲートウェイ: Envoy、NGINX、HAProxy、Caddy 2、Traefik、KrakenD、Kong、Tyk
トンネル/エッジ(edge tunneling): Cloudflare Tunnel、ngrok、frp、localtunnel、Tunnelmole

伝統的に1〜2はインフラチーム、3〜4はプラットフォームチーム、5〜6はアプリ/エッジチームの担当だった。2026年にはこの境界が曖昧になった。Ciliumは1、2、4を同時に狙う(ServiceMeshモード)。Tailscaleは3を制圧してZTNA(6の一部)まで侵食した。以下、各層を見ていく。

Cilium — K8s CNI市場の事実上の標準

Ciliumは2024年にCNCF Graduatedプロジェクトとなり、2026年現在K8s CNI採用率1位だ。コアはeBPFデータパス。iptables/netfilterチェーンを通らずカーネル内でeBPFプログラムによってパケットを処理するため、1万サービス規模でiptablesベースのkube-proxy比でレイテンシは半分以下、CPUは30%以上削減される。

2026年5月時点のCilium 1.16/1.17ラインアップの主要コンポーネントは次のとおり。

Cilium Agent: 各ノードのeBPFプログラムをロード/管理
Cilium Operator: クラスタ全体の状態調整
Hubble: L3〜L7フロー可視化 + メトリクス(OpenTelemetryでもエクスポート)
Cilium ServiceMesh: サイドカーなしメッシュモード(Envoyをノード単位で共有)
ClusterMesh: マルチクラスタサービス接続
Tetragon: eBPFベースのランタイムオブザーバビリティ + 強制(enforcement)

Cilium NetworkPolicyの典型例は次のとおり。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-api-from-frontend
  namespace: prod
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: '8080'
              protocol: TCP
          rules:
            http:
              - method: GET
                path: /v1/.*
              - method: POST
                path: /v1/orders

このポリシーはL3/L4だけでなくL7のHTTPメソッド + パスまでeBPF内で強制する。Calicoの標準モードのようにiptablesに落ちることはない。これが他CNIに対するCiliumの差別化ポイントだ。

Cilium ServiceMesh — サイドカーなしのメッシュ

従来のサービスメッシュ(Istio 1.xのsidecar mode、Linkerd)はPodごとにサイドカープロキシを立てる。Pod 1000個ならプロキシ1000個がRAMを食う。Cilium ServiceMeshは異なるアプローチを取る。

ノードあたり1つのEnvoyを共有インスタンスとして(L7ポリシーが必要なトラフィックのみ)
L4まではeBPFデータパスが直接処理(mTLS含む、SPIFFE/SPIRE ID)
サイドカーモードも併存サポート(段階的移行用)

2024〜2025年にIstioがambient modeを作った動機は完全に同じだ。「サイドカーコストはもう受け入れられない」という市場の合意があった。CiliumはeBPFを持っていたので、もう一歩進められた。

WireGuard — VPNの新しいベースライン

WireGuardは2020年にLinux 5.6へメインラインマージされて以降、2026年時点で事実上すべてのVPN製品のベースプロトコルとなった。400行ほどのカーネルモジュールに収まる軽さ、ChaCha20/Poly1305/Curve25519の固定暗号スイート、UDP単一ポート、ノードキーベースのアイデンティティモデルが核だ。

手動設定は次のように単純。

[Interface]
PrivateKey = SERVER_PRIVATE_KEY
Address = 10.10.0.1/24
ListenPort = 51820

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.10.0.2/32
PersistentKeepalive = 25

WireGuard自体にはユーザー管理、NATトラバーサル、キー配布、ACLといったものがない。それが単純さの美徳であると同時に「そのままで使うのは難しい」結論につながる。2026年WireGuardの上に積み上がったソリューションスタックは次のとおり。

Tailscale: WireGuard + コーディネーター(コントロールプレーン) + ACL + DERPリレー
Headscale: Tailscaleコントロールプレーンのオープンソース再実装
boringtun: CloudflareがRustで書き直したWireGuardユーザースペース実装
wireguard-go: 公式Goユーザースペース実装(Linux/macOS/Windows/iOS/Androidすべてカバー)

Tailscaleはこの中で最も成功した商用製品だ。Headscaleは自己ホスティングオプションが必要なチームが選ぶ。

Tailscale + Headscale — 小さなチームがVPN運用を忘れる方法

Tailscaleの価値命題は単純。VPNゲートウェイを運用するな。すべてのノードがP2Pで直接接続され、コントロールプレーン(Tailscale.com)はキー交換とACLのみ担う。NATトラバーサルのために、DERP(Designated Encrypted Relay for Packets)リレーがフォールバックとして動く。

ACLはHuJSON(コメント可能なJSON)で書く。

{
  "groups": {
    "group:devs": ["alice@example.com", "bob@example.com"],
    "group:ops": ["carol@example.com"]
  },
  "tagOwners": {
    "tag:prod": ["group:ops"]
  },
  "acls": [
    {
      "action": "accept",
      "src": ["group:devs"],
      "dst": ["tag:prod:22", "tag:prod:443"]
    },
    {
      "action": "accept",
      "src": ["group:ops"],
      "dst": ["*:*"]
    }
  ],
  "ssh": [
    {
      "action": "check",
      "src": ["group:devs"],
      "dst": ["tag:prod"],
      "users": ["ubuntu", "root"]
    }
  ]
}

Tailscale SSHのcheckアクションは、ノード接続時にTailscale自身の認証を経由させる。SSHキー配布を事実上回避できる。Headscaleは同じACLフォーマットを受け取り、自己ホスティング形式で動作する。

Nebula・ZeroTier・Twingate・OpenZiti・Boundary — その他メッシュ/ZTNA

Tailscaleが「マネージドコントロールプレーン」を強調するなら、Nebulaは逆だ。Slackが自社インフラ用に作って2019年にオープンソース化したNebulaは、自己PKI + UDPメッシュオーバーレイ。証明書ベースのアイデンティティで、lighthouseノードがNATトラバーサルを補助する。2024年にSlack社内チームがDefined Networking(defined.net)として独立し、マネージド形式でも提供している。政府/大企業の「外部コントロールプレーンは使用不可」要件があるときに、Nebula自己ホスティングが答えになる。

他陣営も整理しておく。

ZeroTier: 2014年から始まったP2P仮想イーサネット。L2エミュレーションまで提供しているのでレガシーブロードキャスト依存アプリに有利。
Twingate: マネージドZTNA。WireGuardを使わず独自プロトコル。クライアントレスオプションが強み。
OpenZiti: NetFoundryが作ったフルOSS ZTNA。アプリSDK埋め込みモデル(アプリケーションが直接ziti SDKで接続)。
HashiCorp Boundary: VPNを使わないZTNA。Vaultと統合してクレデンシャルブローカリング。

この領域の選択基準はコントロールプレーンのホスティングポリシーとエージェントレスオプションの有無だ。政府/規制産業は自己ホスティング、SaaSスタートアップはマネージドを好む。

サービスメッシュ 2026 — Istio ambient modeがついにGA

2024年までサービスメッシュ採用の最大の反対論は「サイドカーが重すぎる」だった。Podあたり50〜150MBのRAM、起動レイテンシ、デバッグの複雑さ。2025年のIstio 1.22〜1.24を経てambient modeがGAになり、この論拠は弱まった。

Istio ambientの構造は次のとおり。

ztunnel(zero-trust tunnel): ノードあたり1つの軽量L4 mTLSプロキシ(Podごとのサイドカーを代替)
waypoint proxy(Envoy): L7ポリシーが必要なトラフィックに限り、namespaceあたり1つ立てる
サイドカーモードも併存サポート(段階的移行)

Istio AuthorizationPolicyの例は次のとおり。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: api-allow-frontend
  namespace: prod
spec:
  selector:
    matchLabels:
      app: api
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ['cluster.local/ns/prod/sa/frontend']
      to:
        - operation:
            methods: ['GET', 'POST']
            paths: ['/v1/*']

principalsはSPIFFE ID形式だ。mTLSハンドシェイクで自動検証される。

Linkerd 2.16+ — 「単純さ」が武器

LinkerdはIstioに比べて意図的に小さい。独自のRustプロキシ(linkerd2-proxy)を使い、機能を制限することで運用負担を下げる。2026年5月時点でLinkerd 2.16/2.17はambientのようなマルチモードを導入せず、サイドカー単一モデルを維持している。CNCF Graduatedであり、ライセンスポリシー変更(Buoyantの商用ライセンス強化)をめぐる議論が2024〜2025年のコミュニティで話題になった。

Consul Connect・AWS App Mesh・OSM・Kuma

Consul Connect: HashiCorp。Vault/Nomadとの統合が強み。K8s外のVM環境メッシュで強い。
AWS App Mesh: 2025年sunset発表。新規採用は推奨されない。
OSM(Open Service Mesh、Microsoft): 2023年にarchive処理。事実上deprecated。
Kuma: Kongが後援するOSSメッシュ。マルチゾーン(zone)モデル。Konnect/Mesh商用も提供。

この領域は事実上Istio ambient vs Linkerd vs Cilium ServiceMeshの3つ巴になりつつある。

eBPFネットワーキング — Cilium、Calico eBPF、Antrea eBPF、bpfilter

eBPFは単に速いだけではなく、ユーザースペースコードなしにカーネル内でパケット処理を完結させる点が本質だ。2026年のK8s CNIでeBPFモードを提供しているのは次のとおり。

Cilium: eBPFが本体。XDP(ドライバ段階)、tc(traffic control)、sockops(ソケットfast path)をすべて活用。
Calico eBPF dataplane: 既存のiptables/IPVSモードの代替。kube-proxy置換可能。
Antrea eBPF mode: VMware Tanzuが後援。OVSベースに部分的eBPF加速。
bpfilter: Linuxメインラインの実験的iptables→eBPF変換層。2025年5.18+カーネルで段階的に導入。

CiliumがXDPを使う理由はNICドライバ段階でパケット処理を行いSKB割り当てコスト自体を回避できるからだ。LoadBalancer/NodePortトラフィック経路をXDPで加速すると、同じノードで100倍近いPPSを叩き出せる。

L7プロキシ比較 — Envoy・NGINX・HAProxy・Caddy 2・Traefik

L7プロキシ/ゲートウェイ市場は2026年次のように整理される。

Envoy: CNCF Graduated。サービスメッシュデータプレーンの事実上の標準。Istio/Cilium/Consulがすべて採用。
NGINX: 単一インスタンスロードバランシングの1位は依然として。F5買収後にOSSとNGINX Plusに分岐。
HAProxy: L4/L7 + 広範なプロトコル。fintech/銀行で採用率が依然として高い。
Caddy 2: 2026年にACME自動発行/更新が最も滑らかなWebサーバー。HTTP/3デフォルト有効。
Traefik: K8s Ingress + Docker フレンドリー。CRDベースのIngressRouteが強み。
KrakenD: APIゲートウェイ特化。マルチバックエンドアグリゲーションに強い。
Tyk: APIゲートウェイ + ポータル/アナリティクスのセット。エンタープライズライセンス。
Kong Gateway: K8s/オンプレ両方。Kong Ingress Controller(KIC) + Mesh(Kuma)のセット。

Envoy設定の一部(L7ルーティング + mTLS upstream)は次のとおり。

static_resources:
  listeners:
    - name: ingress
      address:
        socket_address: { address: 0.0.0.0, port_value: 8443 }
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                '@type': type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: ingress_http
                route_config:
                  virtual_hosts:
                    - name: api
                      domains: ['api.example.com']
                      routes:
                        - match: { prefix: '/v1' }
                          route: { cluster: api_v1 }
  clusters:
    - name: api_v1
      connect_timeout: 0.5s
      type: STRICT_DNS
      load_assignment:
        cluster_name: api_v1
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address: { address: api-v1.prod.svc.cluster.local, port_value: 8080 }
      transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext

これほどの設定をYAMLで手書きするチームは多くない。ほとんどはIstio/Cilium/Contourのようなコントロールプレーンが自動生成する。

Kubernetes Gateway API — Ingressを置き換える次世代標準

2024年に1.0 GAとなったGateway APIは、2026年時点でIngressの事実上の後継として定着した。主な違いは次のとおり。

GatewayClass / Gateway / HTTPRoute / TCPRoute / GRPCRouteの役割分離
インフラチーム(Gateway)とアプリチーム(HTTPRoute)の権限分離
ベンダー中立 + 標準化されたトラフィック分割(traffic split)、ヘッダーマッチング、ミラーリング

Gateway API HTTPRouteの例は次のとおり。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: prod
spec:
  parentRefs:
    - name: public-gateway
      namespace: infra
  hostnames: ['api.example.com']
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: api-v1
          port: 8080
          weight: 90
        - name: api-v2
          port: 8080
          weight: 10

Istio、Cilium、Envoy Gateway、NGINX、Kong、Traefik、ContourがすべてGateway API実装を提供している。Ingressは2026年でも動作するが、新規採用はGateway APIが推奨される。

QUIC + HTTP/3 — 2026年のプロダクション現実

QUIC(RFC 9000)とHTTP/3(RFC 9114)は2026年時点でCDNとモバイルトラフィックのデフォルトだ。Cloudflare、Google、Facebookはトラフィックの70〜80%をHTTP/3で処理している。標準化されて4年が経ち、すべてのモダンブラウザが対応している。

QUICの利点は次のとおり。

TLS 1.3を内蔵(handshake 1 RTT、0-RTT再開)
TCPのhead-of-line blocking回避(UDPの上でマルチプレキシング)
connection migration(IP変更でもセッション維持、モバイルに有利)

しかし運用の現実は甘くない。

ファイアウォール/ロードバランサーがUDP 443を遮断したりdeep inspectionできなかったりする
L4ロードバランサーのstickinessが難しい(connection IDベース)
カーネルのUDP fast pathがTCPに比べて最適化が遅れている(io_uring、UDP向けGSO/GROが比較的最近)

2026年5月時点の推奨はHTTP/3を有効化しつつ、HTTP/2フォールバックを常に維持することだ。CloudflareのようなCDNは自動で処理してくれる。Envoy/NGINX/Caddyで直接運用するなら、ALPNでh3とh2を両方アドバタイズし、UDP 443を開ける必要がある。

DNS-over-HTTPS / DNS-over-QUIC — プライバシー + 検閲回避

DoH(RFC 8484)とDoQ(RFC 9250)は2026年時点でモバイルOSの標準オプションだ。iOSはPrivate Relay経由でDoHを、AndroidはPrivate DNS設定経由でDoT/DoHをサポートする。運用観点で重要なのは次の2点だ。

社内DNSポリシーが無効化されうる: ユーザーのブラウザがCloudflare 1.1.1.1へ直接クエリすると、社内ドメインのsplit horizonが効かない。解決策はsplit-horizon DNS + DDR(Discovery of Designated Resolvers、RFC 9462)。
検閲回避ツールとして使われる: 政府レベルでDoHを遮断する事例(ロシア、イラン一部)。韓国・日本は遮断しない。

企業環境では社内リゾルバーをDoH提供(AdGuard Home、Pi-hole + Cloudflared、NextDNS)するパターンが増えた。

mTLS + ACME — 2026年証明書自動化の極み

2026年のmTLSは2方向で標準化された。外部トラフィックはACME(RFC 8555)ベースのLet's Encrypt + ZeroSSLで90日証明書を自動発行/更新する。内部トラフィックは**SPIFFE/SPIRE(またはIstio CA、Cilium ID)**でmTLSを自動発行する。

Caddy 2がACMEを最も滑らかに処理する。設定一行で自動発行される。

api.example.com {
  reverse_proxy api.prod.svc.cluster.local:8080
  encode gzip zstd
  tls admin@example.com
}

内部mTLSはSPIFFE ID形式(spiffe://cluster.local/ns/prod/sa/api)でワークロードのアイデンティティを表現する。Istio、Cilium、ConsulはすべてSPIFFE互換だ。

Cloudflare Tunnel・ngrok・frp・localtunnel — エッジトンネル

ファイアウォール背後のサービスを外部に公開するパターンは2026年次のように整理される。

Cloudflare Tunnel(cloudflared): Cloudflareエッジからoriginまでのoutboundトンネル。無料プランも強力。
ngrok: デモ/開発の1位。有料プランがマネージドドメイン/OAuthに強い。
frp: オープンソースリバースプロキシ。自己ホスティング型ngrok代替。
localtunnel: 最もシンプルなnpmベーストンネル。一時テスト用。
Tunnelmole: localtunnel類似だがセルフホスティング可能。

Cloudflare Tunnel設定例は次のとおり。

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /etc/cloudflared/6ff42ae2.json

ingress:
  - hostname: api.example.com
    service: http://localhost:8080
  - hostname: ssh.example.com
    service: ssh://localhost:22
  - service: http_status:404

エッジトンネルは公開IPがない環境(家庭NAS、社内開発機、エッジIoT)で外部アクセスを可能にする。ZTNAと組み合わせるとVPNなしのリモートアクセスモデルになる。

ZTNAマトリクス — Tailscale vs Cloudflare Zero Trust vs Twingate

ZTNA(Zero Trust Network Access)はVPNを置き換えるモデルとして定着した。代表的な3ソリューションを比較すると次のとおり。

Tailscale: WireGuardベースのメッシュ。SSH/Funnel/Subnet Routerなどモジュール豊富。100ユーザー以下無料プラン。
Cloudflare Zero Trust(旧Cloudflare for Teams): Cloudflareエッジを活用。Access(WebアプリSSO)、Tunnel、WARPクライアントのセット。50ユーザーまで無料。
Twingate: ZTNA専業。クライアントレスオプション、リソース単位の精密ACL。

選択基準はユースケースの比重だ。

チームノード間メッシュ + SSH + ファイル共有が中心 → Tailscale
WebアプリSSO + 外部公開 + WARPグローバルPoP → Cloudflare Zero Trust
精密ACL + クライアントレス強調 → Twingate

IPv6 + CGNAT — 2026年でも終わらない移行

IPv6は1998年に標準化されたが、2026年でも完全移行は終わっていない。2026年5月時点でグローバルなIPv6採用率は約45%だ。韓国は無線網でKT/SKTがIPv6 dual-stackを一部提供するが、有線網は依然としてIPv4 + NATが圧倒的だ。日本はIIJ/NTTがIPv4 over IPv6(MAP-E、DS-Lite)を積極的に導入している。

**CGNAT(Carrier-Grade NAT)**は、ISPが公開IPv4不足に耐えるために導入した二段階NATだ。家庭ルーターに100.64.0.0/10のプライベートIPが割り当てられる。問題になるケースは次のとおり。

inboundポートフォワーディングが不可能(家庭サーバー運用者に打撃)
NATトラバーサル(UDP hole punching)が難しい(P2Pゲーム/通信に影響)
ログ/セキュリティでユーザー追跡が難しい(複数ユーザーが同じ公開IPを共有)

解決策は**IPv6 dual stack + マネージドトンネル(Tailscale/Cloudflare Tunnel)**の組み合わせだ。家庭NASを外部公開する場合、CGNAT背後でもCloudflare Tunnelがoutbound接続で回避する。

BGP + Anycast — CDNバックボーンの動作原理

CDN(Cloudflare、Fastly、Akamai、Bunny、KeyCDN)の核はAnycast IPだ。同じIPを世界中の数百のPoPからBGPでアドバタイズすれば、ユーザーパケットはBGP best-pathアルゴリズムによって最も近いPoPにルーティングされる。これにより:

DNSラウンドロビンなしで地理的近接が自動
DDoSが分散吸収される(攻撃トラフィックが複数PoPに分散)
単一PoP障害時にBGP再収束で自動迂回

Anycastが動くにはAS(Autonomous System)番号とIPブロック登録が必要だ。RIPE/ARIN/APNICで取得する。一般的なSaaSはこれを直接行う必要はなく、CDNを借りて使う。

SD-WAN + ZTNA収束 — SASEの現在

2020年以降、**SASE(Secure Access Service Edge)**という用語でSD-WAN + ZTNA + SWG(Secure Web Gateway) + CASBが束ねられるトレンドがあった。2026年現在この領域の代表ベンダーは次のとおり。

Cloudflare(Cloudflare One): Zero Trust + Magic WAN + Gatewayのセット
Zscaler: ZIA(internet access) + ZPA(private access) + Posture
Cisco(Cisco+ Secure Connect、Meraki + Umbrella + Duo): マネージド統合
Palo Alto Prisma Access: エンタープライズSASE
Netskope: SSE専業

OSS/自己ホスティング陣営はTailscale + Cloudflare Tunnel + 社内IdP + DoHリゾルバーの組み合わせで類似の結果を作る。価格は1/10程度に下がる。

韓国・日本のISPコンテキスト — KT/LG U+/SKT、NTT/IIJ/SoftBank

韓国と日本でネットワーキングを運用するときに知っておくと良いこと。韓国は無線で一部dual-stackを提供するが、有線網は依然としてIPv4 + NATが圧倒的だ。日本はIPv6採用がはるかに先行している。

KT(AS4766): 韓国最大のバックボーン。国際回線多数保有。家庭用は100M〜10Gまで。
LG U+(AS3786): メディア/IDCに強み。NHN/Kakaoの一部IDC協力。
SKT/SKブロードバンド(AS9318): 無線1位。有線はSKブロードバンド。
NTT Communications(AS4713): 日本最大のバックボーン。グローバルTier-1。
IIJ(AS2497): IPv6/MAP-Eをリード。エンタープライズで強い。
SoftBank(AS17676): モバイル/有線同時。Yahoo Japanと統合。
KDDI/au(AS2516): 日本のモバイル + 有線。WIRELESS CITY PLANNINGと協力。

国際回線RTTは韓国→日本/米国が30〜40ms、日本→米国西海岸が100〜120ms程度。韓国特有の事情で**公共機関統合網(国家情報通信網)**ポリシーが別建てだ。日本はNTTのIPv6 IPoE普及が早く、家庭用もIPv6 prefix delegationを受けるケースが多い。そのため独自ドメイン + IPv6 + 動的DNSでホームサーバーを運用するユーザーが韓国より一般的だ。

比較マトリクス — どのツールをいつ使うか

サマリ表で整理すると次のとおり。

K8s CNI: Cilium(基本)、Calico(保守的運用)、Antrea(VMware環境)、Flannel(レガシー)
チームVPN: Tailscale(SaaS)、Headscale(自己ホスト)、Nebula(自己PKI)、WireGuard手動(特殊)
サービスメッシュ: Istio ambient(フル機能)、Linkerd(単純さ)、Cilium ServiceMesh(eBPF統合)、Consul Connect(HashiCorpスタック)
L7ゲートウェイ: Envoy Gateway/Istio(メッシュ統合)、NGINX/HAProxy(伝統)、Caddy 2(ACME自動化1位)、Kong/Traefik(K8s Ingress)
エッジトンネル: Cloudflare Tunnel(プロダクション)、ngrok(デモ)、frp(自己ホスト)
ZTNA: Tailscale(ノードメッシュ)、Cloudflare Zero Trust(Webアプリ + メッシュ)、Twingate(クライアントレス)、OpenZiti(アプリSDK)

選択基準は常に同じだ。既存スタックとの統合、運用人員規模、自己ホスティング強制要件、そしてライセンスポリシー。

セキュリティコンテキスト — 2026年でも生きている脅威

ネットワーキングツール自体のセキュリティ問題も指摘しておく。

WireGuardキーの漏洩: キーは単純なファイルなので、ノード奪取と同時に侵害が即時。キーローテーションを自動化していないと危険。
Cilium eBPF権限: CAP_BPF + CAP_NET_ADMINが必要。ノード奪取でカーネルの広範な可視性が得られる。
Istio CA侵害: クラスタ内のすべてのワークロードアイデンティティを偽造可能。HSM/Vaultバックエンドを推奨。
Cloudflare Tunnelトークン: トークンが即信頼。Secrets Manager + 定期ローテーションが必須。
DoH/DoQバイパス: クライアントが外部DoHに逃げると社内ログに死角ができる。DDR + ポリシー強制が必要。

2026年の侵害事例の多くはアイデンティティ喪失(キー、トークン、証明書)から始まる。ネットワークACLではなくID管理が本質だ。

おわりに — 2026年5月の推奨スタック

最後に「今新しい会社を立ち上げるなら」基準の推奨組み合わせをまとめる。

K8s CNI: Cilium 1.16+。最初からeBPF + ServiceMesh有効化。
チームVPN/ZTNA: Tailscale(またはHeadscale自己ホスト)。Cloudflare Tunnelを外部公開用の補助として。
サービスメッシュ: Cilium ServiceMeshがすでにあるならそれで。別途行くならIstio ambient。
L7ゲートウェイ: Envoy GatewayまたはIstio + Gateway API。単独はCaddy 2。
DNS: 社内DoHリゾルバー(AdGuard Home/Pi-hole/NextDNS) + Cloudflare 1.1.1.1。
証明書: 外部はLet's Encrypt + Caddy/cert-manager。内部はSPIFFE/SPIREまたはメッシュ統合。
モニタリング: Hubble(Cilium) + Prometheus + Grafana + OpenTelemetry。

この組み合わせは10人スタートアップから1000人規模までほぼそのまま拡張可能だ。2026年ネットワーキングの本質は「すでに検証済みのOSS + マネージドコントロールプレーン1〜2個」の組み合わせだ。自前でOpenVPNを運用していた時代は終わった。

References

Cilium — eBPFベースのCNI、ServiceMesh、Hubble、Tetragon
WireGuard — カーネルモジュールVPNプロトコル
WireGuard on kernel.org
Tailscale — WireGuardベースのマネージドメッシュVPN
Headscale on GitHub — Tailscaleコントロールプレーンの OSS再実装
Slack Nebula on GitHub — 自己PKIメッシュオーバーレイ
Defined Networking — マネージドNebula
Istio — サービスメッシュ(sidecar + ambient)
Linkerd — シンプルなサイドカーメッシュ
Envoy Proxy — L7プロキシデータプレーン標準
OpenZiti on GitHub — フルOSS ZTNA
Cloudflare Tunnel — エッジoutboundトンネル
ngrok — デモ/開発トンネル
Kubernetes Gateway API — Ingressの後継標準
RFC 9000 - QUIC — UDP上のマルチプレキシングトランスポート
RFC 8446 - TLS 1.3 — 現代TLS標準
RFC 8484 - DNS-over-HTTPS
RFC 9250 - DNS-over-QUIC
RFC 8555 - ACME — 自動証明書管理
SPIFFE — ワークロードアイデンティティ標準