【世界最速】Windows Server 2025でSMB over QUICを実装してみた(非ドメイン環境)

今年最初に書いた記事でも言及している
外部からファイルサーバーへのアクセスがVPN経由ではなく証明書認証を用いたQUIC経由でできるようになるという部分の記事です。
機能名はSMB over QUICといい、VPN無しで社内のファイルサーバにアクセスできる機能です。

機能名の通りファイルサーバの根幹機能であるファイル共有、このファイル共有のプロトコルSMBをQUIC経由で使う、というものになります。
元々Azure上でしかデプロイできないWindows Server OSエディションWindows Server 2022 Azure Editionでしか使えなかった機能が、次期WindowsサーバOSであるWindows Server 2025ではオンプレミスでも使えるようになったということです。
通常SMBはTCPの445番ポートを使って通信しますが、over QUICなのでQUIC通信プロトコルとして使います。
QUICはhttps通信でUDPの443番ポートを利用して通信します。
記事執筆時点(2024年6月27日3時46分)ではWindows Server 2022 Azure Editionでの記事はありますが、Windows Server 2025ではまだ誰もやってないみたいなのでやってみます。

記事執筆時点(2024年6月27日)ではWindows Server 2025はプレビューです。
正式リリース時は仕様変更の可能性があります。

記事執筆時点(2024年6月27日)ではWindows Server 2025でSMB over QUICの設定はPower Shellでしか実装されていません。
Windows Server 2022 Azure EditionはWAC(Windows Admin Center)での設定が可能なので、Windows Server 2025正式リリース時はWACでの設定が可能になるかもしれません。

本記事の全体の構成としては以下の通りです。

1. Windows Server 2025側の準備
2. Windows 11側の準備
3. DNSの準備
4. ルーターの設定変更
5. 接続確認

では進めていきましょう。

Windows Server 2025におけるSMB over QUIC

ドメイン環境での構成と非ドメイン環境での構成と2種類できるのですが、今回は非ドメイン環境、NTLM認証で実装してみます。

Windows Server 2025側の準備

Windows Server 2025を立ててみる

これはもう今年最初に書いた記事で構築済みなのでスキップします。
念のため作業対象のWindows Server 2025の基本情報くらいは貼っておきましょう。

エビデンスの画像情報をまとめると

項目	設定値
OS	Windows Server 2025
ホスト名	win2k25-02
IP Address	172.16.0.68
ドメイン参加	していない(非ドメイン環境)

という感じですね。

Windows Server 2025にファイルサーバ機能を実装する

KVM上のWindows Server 2025にディスクを追加してそこにファイルサーバ領域を展開します。
ディスク構成は以下のようになっていて、

赤枠で囲んだ部分がファイルサーバの領域です。
テストなので容量はさほど必要でないので10GiBにしました。

その上のディスクがOS領域ですね。
別にOSディスクにファイルサーバ領域を展開しても良かったんですが、VPN無しでファイルサーバ領域をインターネット公開する恐怖に抗えず、リスクヘッジとしてOS領域と別にファイルサーバ領域を構築しました。
QUICなのでhttps、認証は証明書認証＋NTLM認証(非ドメイン環境なのでKerberosではなくNTLM)なので安全なのですが、構築前はちゃんと動くかどうかわかんないのでこんな構成にしました。
KVM上でディスク作成してマウントしたらOSで認識させましょう。
ディスクマネージャーから色々操作してください。

こんな感じですね。

証明書作成

自己証明書でやっちゃいます。
Power Shellでちゃちゃっと作りましょう。
Power Shellは管理者権限で実行しましょう。
Windows Server 2025と別環境で作成しても良いのですが、証明書の移動の手間が面倒なので私はSMB over QUICを実装するWindows Server 2025内で作成しました。
(有効期限は無駄に100年です。こんなに長い有効期限は非推奨ですよ！)

サンプルコード.ps1

$serverCert = New-SelfSignedCertificate -DnsName [DNS名] -CertStoreLocation "Cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(100) -KeyAlgorithm "RSA" -KeyLength "2048"

[DNS名]の部分はご自身の環境に合わせて実装してください。
私の環境で実際に実行したコマンドは以下の通りです。

cert_create01.ps1

$serverCert = New-SelfSignedCertificate -DnsName win2k25-02.sh-style.info -CertStoreLocation "Cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(100) -KeyAlgorithm "RSA" -KeyLength "2048"

またしても検証環境とはいえ実際に使えるドメインをインターネット上に晒してしまいましたね。
コマンド実行結果は以下の通りです。

エラーなくコマンドが終了していればOKですね。

作成された証明書の確認

作成された自己証明書はコンピューター証明書内の個人の領域に配置されます。
Windowsキー + Rで[ファイル名を指定して実行]を開き、certlm.mscと入力してエンターキーを押してください。

certlmの画面が以下のように開きます。

このように表示されればOKです。
証明書作成のために開いたPower Shellの画面は閉じずにそのまま置いておきましょう。

証明書をSMB認証に関連付ける

この関連付けの作業をマッピングと言います。
これもPower Shellで実行します。
変数の関係でさっき証明書を作成したPower Shell画面にそのまま貼り付けてください。

smb_mapping.ps1

New-SmbServerCertificateMapping -Name win2k25-02.sh-style.info -Thumbprint $serverCert.Thumbprint -Store My

Power Shell画面を閉じてしまった場合はcertlm.mscの画面から作成した証明書のThumbprint情報をコピーしてください。

このように表示されればOKです。
ここまでくればPower Shell画面を閉じてOKです。

証明書をエクスポートする

Windows Server 2025側の最後の作業です。
Windowsキー + Rで[ファイル名を指定して実行]を開き、certlm.mscと入力してエンターキーを押してください。
開いてきたcertlmの画面内左ペインから[個人]→[証明書]内にある先ほど作成した証明書を選択し、[右クリック]→[すべてのタスク]→[エクスポート]をクリックしてください。

[証明書のエクスポート ウィザード]が開きますので[次へ]をクリックします。

秘密鍵はエクスポートしなくて良いです。

(なんか急に手順書みたいになってきたな・・・)
[Base 64 encode X.509(.CER)]を選択し、[次へ]をクリックします。

任意の場所を指定し証明書ファイルに任意の名前を付けて[次へ]をクリックします。
(冗談で任意の名前.cerにしてますが、日本語名は個人的には非推奨です。)

これまで設定した出力する証明書のパラメーターを確認し、[完了]をクリックします。

以下のように証明書が出力されます。

出力された証明書(今回の例だと[任意の名前.cer])をSMBクライアントに相当するWindows 11の任意の場所にコピーしましょう。

Windows Server 2025側の準備はこれで完了です。
続いてWindows Clinet OS側の作業です。
今回はWindows 11 Proで行います。

Windows Cient OS(Windows 11 Pro)側の準備

準備といってもWindows Server 2025で出力した証明書を指定の場所にインポートするだけです。
もう一点の準備を敢えて言うならWindows Server 2025と違うネットワークに配置することくらいですね。

証明書をインポートする

はい。
もうこれは何回もやってる手順ですね。
Windows 11の荷にの場所に配置した証明書ファイルをダブルクリックしましょう。
証明書の画面が開きますので、[証明書のインストール]をクリックします。

[保存場所]を[ローカルコンピューター]を選択し、[次へ]をクリックします。

UACを聞いてくるので[はい]を選択してください。
次に証明書ファイルのデフォルトの配置位置から任意の場所に配置位置を指定します。
[証明書をすべて次のストアに配置する]を選択し、[参照]をクリックします。

[信頼されたルート証明機関]を選択して[OK]をクリックします。

[証明書のインポートウィザード]の画面で以下のように証明書配置位置が[信頼されたルート証明機関]に指定できるので、確認の上[次へ]をクリックします。

これまでの手順で指定した証明書配置位置、[信頼されたルート証明機関]が[ユーザーが選択した証明書ストア]内に正しく反映されていることを確認して[完了]をクリックします。

証明書が正しくインポートされたと確認できるダイアログボックスが出てきますので[OK]をクリックします。

インポートされた証明書が指定位置に配置されているか確認する

Windows 11 ProでWindowsキー + Rを押して[ファイル名を指定して実行]を開き、certlm.mscと入力してエンターキーを押してください。

[信頼されたルート証明機関]→[証明書]をクリックし、先ほどインポートした証明書が存在するか確認します。

存在していればOKです。

Windows 11側の準備は以上です。

DNSの準備

今回利用するDNSはNamed ServerをAzure DNSに向けていますので、Azure DNSで設定します。
Azure Portalにログインし、左ペインに(出していれば)[DNS ゾーン]のアイコンをクリックし設定したいDNSゾーンをクリックし、[追加]をクリックします。

[名前]の項目には前の設定項目のコマンドで指定した[-DnsName]です。

サンプルコード.ps1

$serverCert = New-SelfSignedCertificate -DnsName [DNS名] -CertStoreLocation "Cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(100) -KeyAlgorithm "RSA" -KeyLength "2048"

の[DNS名]ですね。
私の環境では以下のコマンドになるので、

cert_create01.ps1

$serverCert = New-SelfSignedCertificate -DnsName win2k25-02.sh-style.info -CertStoreLocation "Cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(100) -KeyAlgorithm "RSA" -KeyLength "2048"

win2k25-02.sh-style.infoがインターネットで名前解決可能(≒アクセス可能)なFQDNになります。
大事な部分なのでもうちょっと言及するとSMB over QUICが動作するWindows Server 2025のインターネットからアクセス可能なFQDNになるのですが、このFQDNの命名は通常[ホスト名].[ドメイン]となると思います。
今回であれば[ホスト名]が前述の通りwin2k25-02、ドメインがsh-style.infoなのですが、Azure DNS上の設定値はホスト名部分のみになります。(ドメイン部分は当たり前ですが補完されてますね。)
[種類]はDNSレコードの種類です。
今回のSMB over QUIC環境はYAMAHA RTXシリーズの配下にありますのでネットボランチサービスを利用しています。
このネットボランチサービスで使っているFQDNにCNAMEで名前解決を行う、という設定です。
[エイリアス]はネットボランチで使っているFQDNです。
この辺りは読者の皆様の環境に合わせてチューニングを行って下さい。
設定を確認して[追加]をクリックします。
[TTL]の単位も検証なので短くしています。
勘の良い読者の皆様は既にお気づきかと思いますが。ネットボランチサービスを利用しているということからRTXのグローバルIPアドレスがDynamicですので、仮にDynamicのグローバルIPアドレス環境下でCNAMEを利用するのであればTTLは1分でも良いかもしれません。

FQDNの確認

nslookupコマンドで確認しましょうかね。

サンプルコード.bat

nslookup [DNS名]

私の環境では

smb_over_quic_ns_lookup.bat

nslookup win2k25-02.sh-style.info

ですね。
結果は以下の通りです。

はい。
ちゃんと結果が返ってきてますね。

DNSの設定は以上です。
続いてルーターの設定です。

ルーターの設定

今回QUICでの通信を許可しますので、UDPの443番ポートへの通信をWindows Server 2025にポートフォワーディングします。
ルーターは前述の通りYAMAHAのRTXシリーズですので、以下のコマンドで一発です。

rtx_smb_over_quic.config

administrator
ip filter 1047 pass * * udp * 443
pp select 1
 ip pp secure filter in 1020 1030 1040 1041 1042 1043 1044 1045 1047 2000
no pp select 1
nat descriptor masquerade static 1 10 172.16.0.68 udp 443
save
exit
exit

はい。
ip filterの後にあるフィルタ番号や、ip pp secure filter inに設定している各種フィルタ番号などは読者の皆様の環境に合わせてチューニングしてください。
ip filterはすべてのIPアドレスからUDPの443番ポートへの通信を許可しており、ip pp secure filter inでこの許可フィルタをPPPoEでのインバウンド通信として許可しています。
nat descriptor masquerade static 1 10 172.16.0.68 udp 443こちらはRTXのPPPoEインターフェースにUDPの443番ポート宛の通信が来た場合、Windows Server 2025に転送するつまりポートフォワーディングする設定です。
このコマンドのstaticの後にある1や10なども読者の皆様の環境依存です。

接続確認

はい。
最後の作業ですね。
接続確認してみます。

まずはエクスプローラーで接続確認

Windows 11 ProでWindowsキー + Rを押して[ファイル名を指定して実行]を開き、\\win2k25-02.sh-style.info\shared_folder01と入力してエンターキーを押してください。

この接続方式だと最初にTCPの445番ポートで接続し、接続できなかったらQUICの通信、UDPの443番ポートに切り替わります。
この挙動のせいで接続まで少し時間がかかります。
しばらくするとNTML認証を聞いてきます。
ここではWindows Server 2025のユーザーIDとパスワードを入力します。(デフォルト設定なのはご愛敬！)

認証が完了すると以下のようにファイルサーバーの領域が通常のエクスプローラーで確認できます。

できることは頭ではわかっていても、実際に目の当たりにするとやっぱりすごいですね。

次にパケットキャプチャでホンマにQUICで通信してるか確認

はい。
ホンマにQUICで通信してるか確認しましょう。
私がこの記事のためにエビデンスを偽装していないかどうかも併せて確認できますしね。
コマンドプロンプトを管理者権限で実行し、以下のコマンドを実行します。

パケットキャプチャ_開始.bat

netsh trace start capture=yes

実行すると以下の画面が出てきます。

パケットを保存してる場所やキャプチャファイルの最大値を出力してくれますね。
パケットキャプチャを開始してSMB over QUICのファイルサーバにファイルを書き込みましょう。

書き込みが終わったらパケットキャプチャを停止します。

パケットキャプチャ_停止.bat

netsh trace stop

パケットキャプチャのファイル作成にしばらく時間がかかります。

正常に処理が終了すると以下のようになります。

以下はパケットキャプチャの中身です。

ちゃんとUDPの443番ポートで通信していますね。
Azure DNSに登録したFQDNからネットボランチのDNS名が解決された後、更にRTXのグローバルIPアドレスまで変換されているところも確認できます。

はい！
これでWindows Server 2025のSMB over QUICの検証は完了です！

SMB over QUICの使いどころ

やはりファイルサーバアクセスにわざわざVPNを張らなくて良いところでしょうか。
BOXやSPOみたいなSaaSのクラウド型ストレージサービスもありますが、データ移行が大変ですし、従来のファイルサーバをお使いのお客様がWindows Server 2025にアップグレードする際は是非本機能の実装を検討してみてはいかがでしょうか？

5時間もかかっちゃいましたね。

本日はこれまで。