Claude が書いた記事
DTLS とは ── UDP に TLS を載せた高速トンネル
Azure VNet 暗号化のドキュメントに出てくる『DTLS トンネル』ってなんや？ から、TLS (TCP) と DTLS (UDP) の違い・なぜ UDP に暗号を載せ替えるのか・カプセル化で外側だけ平文になる仕組みまで掘った学習ログ。
俺の最初の疑問
Azure の VNet 暗号化のドキュメントを読んでたら「DTLS トンネル」という言葉が出てきた。TLS なら HTTPS で知ってるけど、DTLS ってなんや？ その仲間か？
まず一言でいうと
DTLS (Datagram Transport Layer Security) は、TLS を UDP の上で使えるようにしたもの。HTTPS の TLS が TCP を土台にしてるのを、UDP に載せ替えた版や。暗号の中身 (AES などの暗号スイート) は TLS と同じ。IETF が標準化していて、いまの主流は DTLS 1.2 (RFC 6347) と DTLS 1.3 (RFC 9147)。
なんで UDP 版が要るかというと、TCP の「確実だけど遅い」性質が、リアルタイム通信や基盤の暗号化トンネルには重すぎる場面があるから。DTLS は確認のやり取りを削って、低遅延で暗号化する。
何と比べるとわかるか
TLS と DTLS のちがいは、土台のトランスポートの差に尽きる。
| TLS | DTLS | |
|---|---|---|
| 土台 | TCP | UDP |
| 順序・欠け | 順序どおり・欠けなく届く (TCP が保証) | 落ちる・入れ替わりうる |
| 速さ・遅延 | 確認と再送があり遅延が出やすい | 確認を省いて低遅延 |
| 暗号の中身 | 暗号スイート (AES 等) | 同じ |
| 主な使い所 | HTTPS など「確実さ」重視 | リアルタイム・トンネルなど「速さ」重視 |
何が問題なのか
「暗号化したいだけなら、TLS のパケットを UDP で送ればええやん」と思うけど、それでは壊れる。
TLS は TCP を前提にしている。TCP が「バイトを順序どおり・欠けなく」届けてくれるから、TLS はその連続した流れを前から順に暗号化・復号できる。ここに UDP を持ってくると、UDP はパケットを 落とすし、順序も入れ替わる。TLS のレコードをそのまま流すと、1 個落ちた瞬間に「続き」が復号できなくなって崩れる。
DTLS はここを作り替えた。各レコードに 明示的なシーケンス番号を持たせ、1 個ずつ独立に復号できるようにした。だから前のパケットが落ちても次を復号できる ── TCP の「確認して再送する」に頼らずに暗号化が成立する (RFC 6347)。これが「UDP に TLS を載せる」の実装上の肝や。
図で見る
まず、TLS と DTLS の位置関係。積み重ねると、ちがいは土台の 1 段だけやと分かる。
次に、トンネルにしたときのパケットの中身。元のパケットを丸ごと包んで、外側に新しいヘッダーを付ける。
この「外側は素通しの宛名、内側は暗号化された中身」という形は、クラウドや大規模データセンターのネットワークがそのまま使っているやり方でもある。
- 外側の IP (アンダーレイ) … 物理ホストどうしの住所、いわゆるプロバイダーアドレス。データセンターの物理網はこれだけ見てパケットを運ぶ。
- 内側の IP (オーバーレイ) … その上に載る VM (テナント) の住所。
外側 (物理) の上に内側 (VM) を載せて運ぶので、別々の顧客が同じ 10.0.0.0/16 を使っても物理網で衝突しない。ここに DTLS を重ねると、VM 同士の通信が、物理網を流れる間ずっと丸ごと暗号化される。しかも DTLS は UDP ベースで遅延が小さいから、速度をあまり落とさずにかけられる。これをハードで高速にやっているのが Azure の VNet 暗号化 (解説)。
混乱しやすいポイント
① TLS と別物ではない
暗号スイートも証明書の考え方も TLS ゆずり。DTLS は「TLS を datagram (UDP) 向けに適応した版」で、別系統の暗号やない。だから TLS で使える AES などがそのまま効く。
② トンネルにすると外側ヘッダーは平文
DTLS で中身を暗号化しても、それを運ぶ 外側の IP / UDP ヘッダーは平文。でないと途中の物理ルーターが宛先を読めず、ルーティングできない。暗号化されるのは「中身 (ペイロード)」だけで、宛名は見える (図 2)。
③ UDP でも「投げっぱなし」ではない
土台の UDP は投げっぱなしやが、DTLS 自身は最小限の順序管理と、通信を始める前の鍵合わせ (ハンドシェイク) はやる。「何も管理しない」わけやなく、「TCP の重い再送・順序保証を省いた」が正確や。
たとえ話
金庫入りの手紙で一気通貫できる。
- 内側 (元のパケット) ＝ 手紙そのもの。誰から誰へ、何が書いてあるか。
- DTLS ＝ 手紙を入れて鍵をかける金庫。
- 外側の IP / UDP ＝ 金庫に貼る宛名ラベル。配達員 (ルーター) はこれだけ見て運ぶ。
配達員は宛名は読めるが、金庫の中の手紙は開けられない。これが「外側は平文、中身は暗号」の姿や。
用語の早見表
| 言葉 | つまり何の話？ |
|---|---|
| DTLS | Datagram TLS。UDP の上で TLS の暗号化をやる版。RFC 6347 (1.2) / 9147 (1.3) |
| TLS | HTTPS で使う暗号化。TCP を土台にする |
| TCP | 順序保証・再送で「確実に」届けるトランスポート。確認が多く遅延が出やすい |
| UDP | 確認を省いて「投げっぱなし」で速いトランスポート |
| カプセル化 | 元のパケットを丸ごとペイロードにして、外側に別のヘッダーをかぶせること |
| ペイロード | ヘッダーの後ろの「中身」。外側から見れば中身が何でもただのデータ |
| ハンドシェイク | 通信を始める前に暗号方式と鍵を決める最初のやり取り |
この記事の続きとして、未来の自分が次に掘るといいトピック。
- Azure VNet 暗号化の裏側 ── この DTLS を、Azure が SmartNIC のハードで自動でかける実装。基盤エンジニア視点で一番効く続き。
- MACsec (IEEE 802.1AE) ── DTLS とは別に、Azure がデータセンター間の物理リンクで常時かける L2 の暗号化。「どの層で暗号化するか」の地図が広がる。
- IPsec のトンネルモード ── 同じ「元パケットを丸ごと包んで外側ヘッダーを付ける」カプセル化の代表格。DTLS トンネルと比べると腹落ちする。