手当たり次第に書くんだ

飽きっぽいのは本能

OpenVPN の Use-after-free 脆弱性 CVE-2026-40215 と実務上の対応

作者: si62512548投稿日: カテゴリー: OpenVPNタグ: , , , , , , OpenVPN の Use-after-free 脆弱性 CVE-2026-40215 と実務上の対応 へのコメントはまだありません

OpenVPN に、 TLS セッションの切り替え処理に起因する Use-after-free 脆弱性「 CVE -2026-40215」が公表されました。

この脆弱性が悪用されると、 OpenVPN サーバーのクラッシュや VPN トンネルの停止、ヒープメモリの漏えいが発生する可能性があります。

今回確認した環境では、 OpenVPN のパッケージバージョンが次の状態でした。

参考
書籍
参考書籍

マスタリング TCP/IP 入門編 第 6 版

VPN、TLS、TCP/IP、ネットワーク通信の前提を確認する際の参考書籍です。価格や在庫はリンク先で確認してください。

Amazon で見る

このリンクは Amazon アソシエイトリンクです。

2.6.3-1+deb12u4

このバージョンは、 CVE -2026-40215 の修正版より古いため、影響を受けると判断できます。

ただし、2026 年 7 月時点では、 CVE -2026-40215 を最初に修正したバージョンへ更新するだけでは十分ではありません。その後、 OpenVPN の TLS ・制御チャネル処理周辺で別の Use-after-free を含む複数の脆弱性が公表されているためです。

本記事では、 CVE -2026-40215 の内容と影響を確認した上で、個別 CVE の修正版と、実務上採用すべき更新先を分けて整理します。

結論

CVE -2026-40215 は、 OpenVPN 内部における TLS セッションの寿命管理に関する脆弱性です。

TLS 1.3、 AES -256-GCM、 UDP、 DCO などの設定では解消できません。暗号方式の強度不足ではなく、 OpenVPN プログラム内部におけるメモリ参照とセッション切り替え処理に問題があるためです。

CVE -2026-40215 単体は、次のバージョンで修正されています。

配布系列CVE -2026-40215 の最初の修正版
OpenVPN 上流 2.6 系2.6.20
OpenVPN 上流 2.7 系2.7.2
Debian 12 Bookworm2.6.14-0+deb12u1

OpenVPN 2.6.20 と 2.7.2 のリリース情報には、 CVE -2026-40215 に対する修正が明記されています。 Debian でも、2026 年 5 月 21 日の DSA -6289-1 により、 Bookworm では2.6.14-0+deb12u1で修正されています。

しかし、これはあくまで CVE -2026-40215 単体に対する最初の修正版です。

その後、2026 年 7 月 2 日に OpenVPN 2.6.21 と 2.7.5 が公開され、 CVE -2026-12996 と CVE -2026-13117 という別の Use-after-free を含む、複数のセキュリティ問題が修正されました。

Debian 12 Bookworm では、これらの後続脆弱性も修正した2.6.14-0+deb12u2が提供されています。

したがって、2026 年 7 月時点での実務上の更新基準は次のようになります。

配布系列実務上採用すべき更新先
OpenVPN 上流 2.6 系2.6.21 以上
OpenVPN 上流 2.7 系2.7.5 以上
Debian 12 Bookworm2.6.14-0+deb12u2 以上

CVE -2026-40215 を最初に修正したバージョンで止めるのではなく、更新時点で利用可能なセキュリティ修正版まで上げる必要があります。

CVE -2026-40215 の概要

CVE -2026-40215 は、 OpenVPN の TLS セッション昇格処理に存在する競合状態です。

影響を受ける上流バージョンは、次の範囲です。

  • OpenVPN 2.6.0 から 2.6.19
  • OpenVPN 2.7_alpha1 から 2.7.1

TLS セッションの昇格中に Use-after-free が発生し、リモートの攻撃者によってサーバーのクラッシュまたはヒープメモリの漏えいが引き起こされる可能性があります。

OpenVPN 2.6.20 および 2.7.2 のリリース情報では、特定の条件下で以前の TLS ハンドシェイクに属するパケットデータが漏えいする可能性があったと説明されています。

OpenVPN 内部では何が起こるのか

OpenVPN は、再接続や鍵更新に伴って複数の TLS セッションを内部的に管理します。

概念的には、次のような状態があります。

INITIAL
新しいTLSセッションを確立中
    ↓

ACTIVE
現在使用しているTLSセッション
    ↓

LAME_DUCK
置き換え後の終了処理中セッション

通常、新しい TLS セッションの認証や鍵生成が完了すると、新しいセッションがACTIVEへ昇格します。

それまで使用されていた古いセッションはLAME_DUCKへ移され、終了処理が行われます。

問題は、古い TLS セッションがパケット送信処理を続けているタイミングで、新しい TLS セッションへの置き換えが発生することです。

上流の修正コミットでは、古い TLS セッションがパケットを送信しようとしている一方で、新しいセッションによって置き換えられた場合、送信バッファがセッション内部の領域を参照した状態で残る競合状態が説明されています。

その後、セッション領域が移動または再利用されても送信処理が古い参照を使い続けると、すでに有効ではないメモリ領域を参照する Use-after-free になります。

修正では、 TLS セッションを移動する直前に、次の関数による検査が追加されています。

check_session_buf_not_used()

概念的には、次の処理です。

check_session_buf_not_used(to_link, session);
move_session(multi, TM_LAME_DUCK, TM_ACTIVE, true);
check_session_buf_not_used(to_link, &multi->session[TM_ACTIVE]);
move_session(multi, TM_ACTIVE, TM_INITIAL, true);

送信バッファが移動対象の TLS セッション領域を参照していないことを確認した上で、セッションを移動するように変更されています。

つまり、この脆弱性は暗号処理そのものではなく、 TLS セッションを保持するメモリ領域と、送信処理が参照しているバッファの寿命が一致しないことによって発生します。

想定される影響

公表されている主な影響は、次のとおりです。

  • OpenVPN プロセスまたは接続処理のクラッシュ
  • VPN トンネルの停止
  • VPN サービスの一時的な停止
  • ヒープメモリの一部漏えい
  • 以前の TLS ハンドシェイクに属するパケットデータの漏えい

Debian Security Tracker では、 TLS セッション昇格中の Use-after-free により、サーバーのクラッシュまたはヒープメモリの漏えいが発生する可能性があると説明されています。

Debian の DSA -6289-1 でも、サービス拒否または以前のハンドシェイクに属するパケットデータの漏えいにつながる問題として扱われています。

一方、現時点で公表されている影響には、次の内容は含まれていません。

  • VPN 認証の回避
  • サーバー秘密鍵の直接取得
  • VPN 通信の任意改ざん
  • OpenVPN サーバー上での任意コード実行
  • ルーター全体の遠隔操作

したがって、公表情報に基づけば、主な影響は可用性侵害と情報漏えいです。

ただし、 Use-after-free はメモリ安全性に関する問題です。

「公表資料で任意コード実行が確認されていない」ことと、「理論上も任意コード実行が絶対に不可能である」ことは同じではありません。公式資料で確認されている影響と、それ以上の可能性は分けて扱う必要があります。

TLS 1.3 や AES -GCM では防げない

次の設定や構成は、 CVE -2026-40215 の修正にはなりません。

  • TLS 1.3 の使用
  • AES -256-GCM の使用
  • UDP の使用
  • TCP への変更
  • DCO の有効化
  • 待ち受けポート番号の変更
  • 証明書の鍵長を増やすこと
  • 再接続間隔や鍵更新間隔の変更

この脆弱性は、暗号アルゴリズムを解読するものではありません。

OpenVPN 内部で TLS セッションを移動する際、送信中のバッファが移動対象のメモリ領域を参照していないかを適切に確認していなかったことが原因です。

実際の修正も、暗号方式の変更ではなく、ssl.c のセッション移動処理へバッファ参照の検査を追加するものです。

暗号設定を強化しても、 OpenVPN 内部の無効なメモリ参照は修正されません。

待ち受けポート番号の変更も、無差別なスキャンを多少避ける効果はあるかもしれませんが、脆弱性そのものを防ぐものではありません。

tls-authは緩和策になるのか

OpenVPN でtls-authを使用している場合、tls-auth鍵を持たない第三者が TLS ハンドシェイク処理へ到達することは難しくなります。

tls-authは、 TLS 制御チャネルの各パケットへ HMAC を付加します。正しい HMAC を持たないパケットは、 TLS ハンドシェイクを開始する前に破棄されます。

OpenVPN の公式マニュアルでは、この仕組みを一種の「 HMAC firewall」と説明しています。 TLS スタックへの攻撃や DoS 攻撃に対する追加の防御層として機能します。

したがって、tls-authは次のような攻撃に対する緩和策になります。

  • インターネット上からの無差別なスキャン
  • tls-auth鍵を持たない送信元からのパケット
  • OpenVPN ポートへ不正なパケットを送り続ける攻撃
  • TLS ハンドシェイクを大量に開始させる単純な DoS 攻撃

ただし、tls-authは CVE -2026-40215 そのものを修正する機能ではありません。

次のような主体に対するリスクは残ります。

  • tls-auth鍵を保有する正規クライアント
  • 侵害された正規クライアント端末
  • tls-auth鍵を不正に取得した攻撃者
  • 有効なクライアント証明書を保有する悪意ある利用者
  • 廃止されていない古い接続資格情報の保有者

また、tls-auth鍵だけで VPN の証明書認証を突破できるわけではありません。

しかし、正しい HMAC を持つ制御チャネルパケットを送信し、 TLS ハンドシェイクの入口へ到達するための条件の一つを満たすことになります。

したがって、tls-authは有効な防御層ではありますが、修正済み OpenVPN への更新を代替するものではありません。

CVE 単体の修正版と実務上の更新先を分ける

脆弱性対応では、次の二つを区別する必要があります。

CVE 単体の修正版

対象 CVE を最初に修正したバージョンです。

CVE -2026-40215 の場合は次のとおりです。

OpenVPN 2.6系：2.6.20
OpenVPN 2.7系：2.7.2
Debian 12：2.6.14-0+deb12u1

OpenVPN 2.6.20 と 2.7.2 は 2026 年 4 月 22 日に公開され、リリース情報へ CVE -2026-40215 の修正が記載されています。

Debian では、2026 年 5 月 21 日に DSA -6289-1 が公開され、 Bookworm では2.6.14-0+deb12u1で CVE -2026-40215 と CVE -2026-35058 が修正されました。

更新作業時点で実際に採用すべきバージョン

実際の更新先は、対象 CVE だけではなく、その後に公表された既知脆弱性も修正したバージョンから選定します。

OpenVPN 2.6.21 と 2.7.5 は、2026 年 7 月 2 日に公開されました。

これらのリリースでは、次の脆弱性などが修正されています。

  • CVE -2026-12996
  • CVE -2026-13117
  • CVE -2026-13122
  • CVE -2026-12932
  • CVE -2026-11771
  • CVE -2026-13698

これらは、すべてが同じ種類の脆弱性というわけではありません。

このうち、 CVE -2026-12996 と CVE -2026-13117 は、 CVE -2026-40215 と同様に、 OpenVPN の TLS ・制御チャネル処理周辺で発生する Use-after-free です。

CVE -2026-12996 は、ack_write_buf()における Use-after-free です。制御チャネルパケットと認証パケットの処理タイミングによって発生する可能性があります。

CVE -2026-13117 は、tls_wrap_reneg()における Use-after-free です。動的tls-cryptを使用している場合に、特定の制御チャネルパケット列によって発生する可能性があります。

一方、 CVE -2026-13122 は、特定の不正なauth-tokenを受信した際にサーバーがクラッシュする問題です。 CVE -2026-12932 と CVE -2026-13698 はメモリリークによるメモリ枯渇、 CVE -2026-11771 は NTLMv2 プロキシ応答処理における 1 バイトのバッファオーバーランです。

したがって、後続の 6 件をすべて「 CVE -2026-40215 と同じ Use-after-free 」と扱うのは正確ではありません。

Use-after-free という技術的な共通点を持つのは、 CVE -2026-12996 と CVE -2026-13117 です。

ただし、実際の更新判断では脆弱性の種類にかかわらず、 OpenVPN 2.6.20 の公開後に判明した既知のセキュリティ問題が、2.6.21 でまとめて修正されていることが重要です。

そのため、 CVE -2026-40215 だけを見て OpenVPN 2.6.20 へ更新しても、2026 年 7 月時点では別の既知脆弱性が残ります。

Debian 12 Bookworm では、これらの後続脆弱性が2.6.14-0+deb12u2で修正されています。

実務上は次のように判断します。

CVE-2026-40215単体の修正確認
    ↓
2.6.20、2.7.2またはdeb12u1で修正済み

実際の更新先の選定
    ↓
後続の既知脆弱性も確認
    ↓
2.6.21、2.7.5またはdeb12u2以上を採用

「対象 CVE が修正されているか」と「現在、そのバージョンへ更新するのが適切か」は、別の問いです。

Debian パッケージのバージョン比較

今回確認したパッケージは、次のバージョンです。

2.6.3-1+deb12u4

CVE -2026-40215 を最初に修正した Bookworm パッケージは、次のバージョンです。

2.6.14-0+deb12u1

さらに、2026 年 7 月時点で採用すべき Bookworm の更新先は、次のバージョンです。

2.6.14-0+deb12u2

ここで注意すべきなのは、末尾のu4とu1またはu2だけを比較してはいけないことです。

パッケージバージョン全体は、概念的に次のような要素で構成されています。

2.6.3-1+deb12u4
│     │       └ Debian 12向け更新番号
│     └ Debianリビジョン
└ 上流バージョン
2.6.14-0+deb12u2
│      │       └ Debian 12向け更新番号
│      └ Debianリビジョン
└ 上流バージョン

deb12u4の数字がdeb12u2より大きくても、前者の上流ベースは 2.6.3、後者は 2.6.14 です。

Debian Bookworm の OpenVPN パッケージは、上流 2.6.3 をベースとした系列から、上流 2.6.14 をベースとした系列へ切り替わっています。

したがって、末尾のuNだけではなく、上流ベースを含むパッケージバージョン全体を比較する必要があります。

なお、これは Debian の epoch が設定されたという意味ではありません。

Debian の epoch は、バージョン文字列の先頭へ1:などの形式で明示されます。今回のパッケージにはその形式はなく、上流ベースバージョン自体が変更されています。

Debian のパッケージ情報では、2026 年 7 月時点の Bookworm 向け OpenVPN として2.6.14-0+deb12u2が掲載されています。

2.6.3-1+deb12u4は影響を受けるのか

結論として、影響を受けると判断できます。

理由は二つあります。

一つ目は、上流バージョンの 2.6.3 が、 CVE -2026-40215 の影響範囲である 2.6.0 から 2.6.19 に含まれることです。

二つ目は、 Debian Bookworm における CVE -2026-40215 の修正開始バージョン2.6.14-0+deb12u1より古いことです。

さらに、2026 年 7 月時点では、後続の OpenVPN 脆弱性も修正した2.6.14-0+deb12u2が提供されています。

したがって、更新先を2.6.14-0+deb12u1に限定する理由はありません。

恒久対応

恒久対応は、修正済み OpenVPN を含むソフトウェアへ更新することです。

今回の環境が Debian 12 Bookworm を基盤としている場合、2026 年 7 月時点では次のバージョン以上を基準とします。

2.6.14-0+deb12u2

上流の OpenVPN を直接使用している場合は、次のバージョン以上です。

OpenVPN 2.6系：2.6.21
OpenVPN 2.7系：2.7.5

VyOS などのアプライアンス型ディストリビューションでは、 OpenVPN パッケージだけを独自に差し替えるのではなく、使用しているリリース系列の正式な更新方法に従い、修正済み OpenVPN を含むイメージへ更新するのが基本です。

OpenVPN パッケージだけを個別に変更すると、アプライアンスとしての依存関係やイメージ管理、将来の更新との整合性を損なう可能性があります。

重要なのは、 VyOS 自体のバージョン名だけで判断しないことです。

更新候補のイメージに、実際にどの OpenVPN パッケージが含まれているかを確認します。

openvpn --version

Debian パッケージとしての正確なバージョンは、次のコマンドで確認できます。

dpkg-query -W -f='${Package} ${Version}\n' openvpn

パッケージ候補を確認できる環境では、次のコマンドも使用できます。

apt-cache policy openvpn

イメージ更新後にも同じコマンドを実行し、実際に修正済みパッケージへ置き換わったことを確認します。

更新後の動作確認

今回の脆弱性は、 TLS セッションの初回確立だけではなく、再接続やセッション更新時の処理に関係します。

そのため、単に「 VPN が接続できた」だけでは確認として不十分です。

更新後は、少なくとも次の内容を確認します。

  • OpenVPN プロセスが正常に起動すること
  • すべての VPN トンネルが確立すること
  • 双方向通信が可能であること
  • ルーティングが正常に反映されること
  • トンネルを一度切断しても再接続できること
  • 対向装置の再起動後に自動復旧できること
  • 鍵更新後も通信が継続すること
  • OpenVPN ログに異常終了が記録されていないこと
  • 監視システムでトンネル断と復旧を検知できること

特に、再接続と鍵更新を含む試験が重要です。

また、更新前に正常性確認の基準を決めておきます。

「接続済みと表示されること」だけではなく、実際の経路疎通、アプリケーション通信、再接続時間、監視通知まで確認する必要があります。

更新までの暫定対応

すぐに更新できない場合は、攻撃可能な範囲を狭めます。

ただし、次の対策は脆弱性そのものを修正するものではありません。

VPN の送信元を制限する

サイト間 VPN で対向側のグローバル IP アドレスが固定されている場合は、 OpenVPN の待ち受けポートへ到達できる送信元を、対向拠点の IP アドレスに限定します。

これにより、インターネット上の不特定多数から OpenVPN へパケットを送信される可能性を下げられます。

動的 IP アドレスを利用するリモートアクセス VPN では、同じ方法を適用できない場合があります。

tls-authを維持する

tls-authは、正しい HMAC を持たない制御チャネルパケットを TLS 処理の前に破棄します。

そのため、更新までの緩和策として有効です。

ただし、tls-authを設定していることを理由に、ソフトウェア更新を延期してはいけません。

不要なクライアント証明書を失効する

使用していないクライアント証明書、紛失した端末の証明書、管理対象外となった証明書を失効させます。

有効な接続資格を持つ主体を減らすことで、脆弱な TLS 処理へ到達できる範囲を縮小できます。

証明書を失効した場合は、 CRL が各 OpenVPN インスタンスで実際に読み込まれていることも確認します。

不要な VPN を停止する

検証用 VPN や、すでに使用していない VPN 設定が残っている場合は停止します。

外部公開している OpenVPN インスタンスを減らすことは、攻撃対象領域の縮小につながります。

異常な再接続を監視する

更新までの間は、次のような事象を監視します。

  • OpenVPN プロセスの異常終了
  • 短時間で繰り返される再接続
  • 想定外の TLS ハンドシェイク増加
  • VPN トンネルの瞬断
  • プロセス再起動後の自動復旧
  • コアダンプやメモリエラー
  • メモリ使用量の継続的な増加

ただし、ログに異常がないことは、脆弱性が悪用されていないことの証明にはなりません。

tls-auth鍵の交換

tls-auth鍵の交換は、 CVE -2026-40215 の修正とは別の対応です。

次の条件に該当する場合は、鍵を交換します。

  • 鍵をチャットやチケットへ貼り付けた
  • 鍵を公開リポジトリーへ登録した
  • 鍵をメールで平文送信した
  • 管理対象外の端末に鍵が残っている
  • 複数の独立した VPN で同じ鍵を共用している
  • 鍵を保有していた端末が侵害された可能性がある
  • 誰が鍵を保有しているか把握できない

tls-auth鍵だけで VPN の証明書認証を突破できるわけではありません。

しかし、正しい HMAC を生成し、 OpenVPN の TLS ハンドシェイクを開始するための条件の一つを満たすことになります。

複数の VPN で一つのtls-auth鍵を共用している場合、一つの鍵の流出が複数の OpenVPN インスタンスへ波及します。

そのため、独立した VPN ではtls-auth鍵も分離し、侵害時の影響範囲を限定する方が適切です。

ただし、鍵交換後も正規の対向装置は新しい鍵を保有します。

脆弱な OpenVPN を使い続ける限り、ソフトウェア内部の Use-after-free は残ります。

対応の優先順位

今回の対応は、次の順序で実施します。

  1. 修正済み OpenVPN を含む VyOS イメージへ更新する
  2. 更新後の OpenVPN パッケージバージョンを確認する
  3. 再接続と鍵更新を含む動作試験を行う
  4. 外部から OpenVPN への到達範囲を制限する
  5. 不要なクライアント証明書を失効する
  6. 管理境界外へ出たtls-auth鍵を交換する
  7. VPN ごとにtls-auth鍵を分離する
  8. OpenVPN プロセスと再接続の監視を強化する

重要なのは、鍵交換やファイアウォール設定だけで対応を完了したと判断しないことです。

CVE -2026-40215 の恒久対応は、修正済み OpenVPN への更新です。

設定だけで完全に回避することは難しい

今回の脆弱性について、設定変更だけで完全に回避する方法を探すのは適切ではありません。

再接続や TLS セッションの更新を抑制すれば、脆弱性が発生する機会を減らせる可能性はあります。

しかし、再接続、鍵更新、障害復旧といった VPN 本来の機能へ別の問題を生じさせます。また、脆弱なコード自体は残ります。

セキュリティ設定は、脆弱性が悪用される条件を狭めることはできます。しかし、脆弱なメモリ管理処理を修正することはできません。

したがって、今回の対応では、次の二つを分けて考える必要があります。

  • 恒久対応: 修正済み OpenVPN への更新
  • 暫定対応: 送信元制限、tls-auth、証明書失効、鍵交換、不要な VPN の停止、監視強化

暫定対応が充実していても、恒久対応の代わりにはなりません。

個別 CVE の修正版だけを見てはいけない

脆弱性管理では、対象 CVE がどのバージョンで修正されたかを確認することが重要です。

一方で、修正開始バージョンをそのまま更新先にしてはいけません。

今回の例では、 CVE -2026-40215 単体は OpenVPN 2.6.20、2.7.2 または Debian の2.6.14-0+deb12u1で修正されています。

しかし、その後に OpenVPN 2.6.21、2.7.5 および Debian の2.6.14-0+deb12u2が公開され、別の Use-after-free や DoS につながる複数の脆弱性が修正されています。

したがって、脆弱性対応では次の二段階で判断する必要があります。

1. 対象CVEが修正されているか
2. 更新時点で残る既知脆弱性がないか

CVE ごとの修正開始バージョンは、調査と影響判定の基準です。

実際に導入するバージョンは、その後に公表された脆弱性、ディストリビューションの最新セキュリティ更新、製品のサポート状況まで確認して選定します。

まとめ

CVE -2026-40215 は、 OpenVPN の TLS セッション昇格時に発生する競合状態によって、 Use-after-free が引き起こされる脆弱性です。

公表されている影響は、 OpenVPN サーバーのクラッシュ、 VPN サービスの停止、ヒープメモリや以前の TLS ハンドシェイクに属するデータの漏えいです。

CVE -2026-40215 単体は、次のバージョンで修正されています。

OpenVPN 2.6.20
OpenVPN 2.7.2
Debian 12の2.6.14-0+deb12u1

しかし、2026 年 7 月時点では、これらを最終的な更新基準にするべきではありません。

OpenVPN 2.6.21 と 2.7.5 では、 CVE -2026-12996 と CVE -2026-13117 という別の Use-after-free を含む複数のセキュリティ問題が修正されています。 Debian 12 Bookworm では、これらの修正が2.6.14-0+deb12u2へ取り込まれています。

したがって、2026 年 7 月時点の実務上の更新基準は次のとおりです。

OpenVPN上流2.6系：2.6.21以上
OpenVPN上流2.7系：2.7.5以上
Debian 12 Bookworm：2.6.14-0+deb12u2以上

tls-authは、鍵を持たない無差別な攻撃者に対する有効な防御層です。

しかし、正規クライアントや鍵を取得した主体に対する防御にはならず、脆弱性そのものも修正しません。

TLS 1.3、 AES -GCM、 UDP、 DCO、ポート番号の変更でも解消できません。

今回の対応で重要なのは、対象 CVE の最初の修正版を確認するだけで終わらず、実際に更新する時点で提供されている最新のセキュリティ修正版まで確認することです。

参考資料

関連する記事

関連する記事
OpenVPN の Use-after-free 脆弱性 CVE-2026-40215 と実務上の対応

関連記事

OpenVPN のパケット構造 – TLS 制御チャネルとデータチャネルを理解する OpenVPN tls-auth の役割 – 制御チャネル保護、key-direction、tls-crypt との違い OpenVPN の MTU 設定 – mssfix / fragment / tun-mtu の考え方

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。（スパム対策）

トップへ戻る