Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに — 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層に分かれる。

1. **L2/L3 データパス(datapath)**: eBPF、XDP、tc、OVS、kernel netfilter、DPDK

2. **K8s CNI**: Cilium、Calico、Antrea、Flannel

3. **オーバーレイVPN / メッシュ(mesh)**: WireGuard、Tailscale、Nebula、ZeroTier、Twingate、OpenZiti、Boundary

4. **サービスメッシュ(service mesh)**: Istio(ambient)、Linkerd、Consul Connect、Kuma

5. **L7プロキシ/ゲートウェイ**: Envoy、NGINX、HAProxy、Caddy 2、Traefik、KrakenD、Kong、Tyk

6. **トンネル/エッジ(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:

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:

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:

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:

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](https://cilium.io/) — eBPFベースのCNI、ServiceMesh、Hubble、Tetragon

- [WireGuard](https://www.wireguard.com/) — カーネルモジュールVPNプロトコル

- [WireGuard on kernel.org](https://www.kernel.org/doc/html/latest/networking/wireguard.html)

- [Tailscale](https://tailscale.com/) — WireGuardベースのマネージドメッシュVPN

- [Headscale on GitHub](https://github.com/juanfont/headscale) — Tailscaleコントロールプレーンの OSS再実装

- [Slack Nebula on GitHub](https://github.com/slackhq/nebula) — 自己PKIメッシュオーバーレイ

- [Defined Networking](https://www.defined.net/) — マネージドNebula

- [Istio](https://istio.io/) — サービスメッシュ(sidecar + ambient)

- [Linkerd](https://linkerd.io/) — シンプルなサイドカーメッシュ

- [Envoy Proxy](https://www.envoyproxy.io/) — L7プロキシデータプレーン標準

- [OpenZiti on GitHub](https://github.com/openziti/ziti) — フルOSS ZTNA

- [Cloudflare Tunnel](https://www.cloudflare.com/products/tunnel/) — エッジoutboundトンネル

- [ngrok](https://ngrok.com/) — デモ/開発トンネル

- [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/) — Ingressの後継標準

- [RFC 9000 - QUIC](https://datatracker.ietf.org/doc/html/rfc9000) — UDP上のマルチプレキシングトランスポート

- [RFC 8446 - TLS 1.3](https://datatracker.ietf.org/doc/html/rfc8446) — 現代TLS標準

- [RFC 8484 - DNS-over-HTTPS](https://datatracker.ietf.org/doc/html/rfc8484)

- [RFC 9250 - DNS-over-QUIC](https://datatracker.ietf.org/doc/html/rfc9250)

- [RFC 8555 - ACME](https://datatracker.ietf.org/doc/html/rfc8555) — 自動証明書管理

- [SPIFFE](https://spiffe.io/) — ワークロードアイデンティティ標準