Veeam v13 のリポジトリに NetApp ONTAP Select を S3 接続（Direct-to-Object）する手順
Veeam Backup & Replication（以降、VBR）のバックアップリポジトリとして NetApp ONTAP の S3 Compatible Object Storage を設定する際の構築作業メモを共有します。なお、物理的な NetApp ではなく、仮想マシンである NetApp ONTAP Select を使用しました。
最初に本記事で説明している点を列記いたします。
- ONTAP Select で S3 Compatible Object Storage を構築する方法
- Veeam v13 から Direct-to-Object で接続する方法
- HTTPS／証明書の生成と設定方法
- VBR から TLS 接続できない場合の切り分け方法
- Proxmox 環境で vhost-net のオフロードが原因だった場合の対処
また、本記事における手順は、 TLS 接続が不調だった際に紆余曲折の調査をしながらの手順となっています。正しい手順のみを参照したい方は目次の「切り分け編」をスキップして参照してください。
検証環境
- 仮想化基盤：Proxmox VE 8.4.18
- バックアップソフト/OS：Veeam Backup & Replication 13.1.1.18 試用版 / Windows Server 2025 24H2
- バックアップ対象：RockyLinux 9
- バックアップリポジトリ：NetApp ONTAP Select：9.18.1 試用版
- ネスト仮想化基盤：ESXi（VMware vSphere Hypervisor 7.0）
接続方式
VBR と NetApp ONTAP との接続方式は、主に 4種類 あります。
①SMB共有方式
ONTAP Select 上で作成した SMB 共有フォルダを、Veeamの「Network Attached Storage (SMB)」リポジトリとして直接登録する方式。②NFS共有方式
ONTAP Select 上で作成した NFS エクスポートを、Veeamの「Network Attached Storage (NFS)」リポジトリとして登録する方式。③iSCSI接続方式（Direct Attached / Block）
ONTAP Select の LUN を Windows/Linuxサーバー（リポジトリサーバー）へ iSCSI イニシエータ経由でマウントし、NTFS/ReFS や XFS 等でフォーマットして「Direct Attached Storage」として登録する方式。④S3互換オブジェクトストレージ方式（ONTAP S3）
ONTAP Select 内で S3 サーバー機能を有効化し、Veeamの「S3 Compatible Object Storage」リポジトリ（Capacity TierまたはDirect-to-Object）としてバケットを登録する方式。今回は、S3 互換オブジェクトストレージ方式の接続までを行います。この方式にはさらに二種類があります。
①Direct-to-Object（直接バックアップ）
中間ストレージを持たず、全世代・直接 ONTAP S3 にバックアップを集約します。
データーフロー：VM ⇒ Veeam Proxy/Gateway ⇒ ONTAP S3②Capacity Tier（SOBR構成）
直近データは高速な一時領域に置き、古い世代を自動でONTAP S3へ退避（階層化）します。直近数日間のバックアップ／リストア速度を向上させ、古いリストアポイントを最小化したい場合に採用します。
データーフロー：VM ⇒ ONTAP Performance Tier ⇒ ONTAP S3今回は、検証環境の制約から Direct-to-Object 方式を採用します。
設定の流れ
ONTAP S3 を提供する最小設定を記載します。初期の環境については以下の記事を参照ください。
NetApp ONTAP SelectをネストESXiへ構築する方法｜Deploy VMからの導入手順
最初に VBR のリポジトリーとして ONTAP S3 を登録するまでの流れを示しておきます。Veeam Backup & Replication から S3 Compatible Object Storage へ接続する場合、HTTPS による接続が必要です。そのため、本記事では ONTAP S3 の HTTPS リスナーと証明書を事前に構成しています。
- Step 1(ONTAP)：データ用アグリゲート（データ領域）の作成
- Step 2(ONTAP)：S3 用 SVM (Storage Virtual Machine) の作成
- Step 3(ONTAP)：S3 データアクセス用 LIF (IPインターフェース) の作成
- Step 4(ONTAP)：SVM 内での S3 サーバー機能の作成と有効化
- Step 5(ONTAP)：S3 ユーザー作成 と アクセスキー・シークレットキーの発行
- Step 6(ONTAP)：バックアップ先 S3 バケットの作成 (容量・権限の割当)
- Step 7(Linux)：TLS 接続用の自己署名 Root CA とサーバー証明書の作成
- Step 8(ONTAP)：ONTAP へのサーバー証明書の投入と動作確認
- Step 9(VBR/Windows)：Windows への証明書投入と動作確認
- Step 10(VBR)：S3 Compatible Object Storage としてリポジトリ登録
2026/9/23 追記：本記事では ONTAP 操作を全て CLI で実施していますが、SB エンジニアの方が GUI の ONTAP System Manager から S3 バケットを作成する手順を公開されています。GUI での操作も CLI と同様になりますので、そちらも並行して参照をお勧めします。
ONTAPで実現するオブジェクトストレージ『ONTAP S3』設定方法
Step1. データ用アグリゲートの作成
クラスター上で利用可能なディスクを確認します。なお、最小構成の ONTAP Select には三種の LIF（IP アドレスを付与）が存在します。
・クラスター管理IP(LIF)：運用管理用として使用する
・ノード管理IP(LIF)：ハードウェア状態確認やDeploy VMとの通信に使用される
・データIP(LIF)：バックアップデータートラフィックが流れる
設定のため、クラスター管理IP に接続し、以下のコマンドを発行します。
single-cluster::> storage disk show
Usable Disk Container Container
Disk Size Shelf Bay Type Type Name Owner
---------------- ---------- ----- --- ------- ----------- --------- --------
NET-1.1 500.0GB - - SSD spare spare single-cluster-01
NET-1.2 66.93GB - - SSD aggregate aggr0_single_cluster_01
single-cluster-01
2 entries were displayed.
single-cluster::>スペアディスク NET-1.1（ディスク数1）を指定してデータ用アグリゲート（data_aggr01）を作成します。
single-cluster::> storage aggregate create -aggregate data_aggr01 -node single-cluster-01 -diskcount 1
Info: The layout for aggregate "data_aggr01" on node "single-cluster-01" would be:
First Plex
RAID Group rg0, 1 disks (advanced_zoned checksum, raid0)
Usable Physical
Position Disk Type Size Size
---------- ------------------------- ---------- -------- --------
data NET-1.1 SSD 492.2GB 500.0GB
Aggregate capacity available for volume use would be 442.9GB.
500.0GB would be used from capacity license.
Do you want to continue? {y|n}: y
[Job 43] Job succeeded: DONE
single-cluster::>アグリゲートの作成が完了したら、State が online になっているか確認します。
single-cluster::> storage aggregate show
Aggregate Size Available Used% State #Vols Nodes RAID Status
--------- -------- --------- ----- ------- ------ ---------------- ------------
aggr0_single_cluster_01
60.22GB 2.92GB 95% online 1 single-cluster- raid0,
01 normal
data_aggr01
442.9GB 442.9GB 0% online 0 single-cluster- raid0,
01 normal
2 entries were displayed.
single-cluster::>Step2. S3 用 SVM (Storage Virtual Machine) の作成
作成した data_aggr01 を指定してオブジェクトストレージ専用の SVM（Storage Virtual Machine）を作成します。
single-cluster::> vserver create -vserver svm_s3 -subtype default -aggregate data_aggr01
[Job 44] Job succeeded:
[Job 44] Job succeeded:
Vserver creation completed.
single-cluster::>SVM が作成され、稼働状態になっているか確認します。
single-cluster::> vserver show -vserver svm_s3
Vserver: svm_s3
Vserver Type: data
Vserver Subtype: default
Vserver UUID: 22cf9af8-98a8-11f1-b3c1-00a0b8ade4d1
Root Volume: svm_s3_root
Aggregate: data_aggr01
NIS Domain: -
Root Volume Security Style: unix
LDAP Client: -
Default Volume Language Code: C.UTF-8
Snapshot Policy: default
Data Services: data-cifs, data-flexcache,
data-iscsi, data-nfs,
data-nvme-tcp
Comment:
Quota Policy: default
List of Aggregates Assigned: -
Limit on Maximum Number of Volumes allowed: unlimited
Vserver Admin State: running
Vserver Operational State: running
Vserver Operational State Stopped Reason: -
Allowed Protocols: nfs, cifs, fcp, iscsi, ndmp,
s3
Disallowed Protocols: nvme
Is Vserver with Infinite Volume: false
QoS Policy Group: -
Caching Policy Name: -
Config Lock: false
IPspace Name: Default
Foreground Process: -
Logical Space Reporting: false
Logical Space Enforcement: false
Default Anti_ransomware State of the Vserver's Volumes: disabled
Enable Analytics on New Volumes: false
Enable Activity Tracking on New Volumes: false
Total Size of the Volumes: -
Available Size: -
Used Percent: -
Number of Volumes in Recovery Queue: -
Storage Space in Recovery Queue Volumes: -
Max Storage Alert Threshold Exceeded: -
Storage Limit: -
Storage Limit Threshold Alert: -
(DEPRECATED) Anti-ransomware Auto-switch from Learning to Enabled: true
(DEPRECATED) Anti-ransomware Auto-switch Minimum Incoming Data (in percentage): 5%
(DEPRECATED) Anti-ransomware Auto-switch Duration Without New File Extension (in Days): 3
(DEPRECATED) Anti-ransomware Auto-switch Minimum Learning Period: 10
(DEPRECATED) Anti-ransomware Auto-switch Minimum File Count: 200
(DEPRECATED) Anti-ransomware Auto-switch Minimum File Extension: 10
Storage Reserved for In-flight Volume Operations: -
single-cluster::>SVM（svm_s3）が正常に作成され、running 状態で稼働しています。Allowed Protocols に s3 が含まれていることも確認できました。
Step3. S3 データアクセス用 LIF (IPインターフェース) の作成
サービスポリシーを作成するため、特権モードに変更します。
single-cluster::> set -privilege advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y
single-cluster::*>S3 サービスを含むポリシー policy_s3 を作成します。
single-cluster::*> network interface service-policy create -vserver svm_s3 -policy policy_s3 -services data-core,data-s3-server
single-cluster::*>VBR から S3 API 経由でアクセスするためのデータ用 LIF（IP: 192.168.1.82）を作成します。
single-cluster::*> network interface create -vserver svm_s3 -lif lif_s3_01 -service-policy policy_s3 -home-node single-cluster-01 -home-port e0a -address 192.168.1.82 -netmask 255.255.255.0
single-cluster::*>権限モードを標準モードに戻します。
single-cluster::*> set -privilege admin
single-cluster::>Step4. SVM 内での S3 サーバー機能の作成と有効化
S3 サーバーサービスを作成します。
single-cluster::> vserver object-store-server create -vserver svm_s3 -object-store-server s3.makorin.org -is-http-enabled true -is-https-enabled false
single-cluster::>Step5. S3 ユーザー作成とアクセスキー・シークレットキーの発行
VBR がバケットに読み書きするための S3 ユーザーを作成します。このコマンドを実行すると、画面上に Access Key と Secret Key が1度だけ表示されます。テキストファイルなどに記録しておきます。
single-cluster::> vserver object-store-server user create -vserver svm_s3 -user veeam_user -comment "Veeam Backup User"
Vserver: svm_s3
User: veeam_user
Access Key: SOJ2**********3NJPQO
Secret Key: 63cc20fzc2CBbI_**********_b32tA1Mk_UcBX5
Warning: The secret key won't be displayed again. Save this key for future use.Step6. バックアップ先 S3 バケットの作成 (容量・権限の割当)
バックアップデータを格納する S3 バケットを作成し、容量上限とアクセス権（作成した veeam_user）を紐付けます。今回は、容量をデータ用アグリゲート（約442GB）の範囲内で、検証用として 300GB を割り当てます。
まずバケットの作成。
single-cluster::> vserver object-store-server bucket create -vserver svm_s3 -bucket veeam-backup-bucket -size 300GB
[Job 45] Job succeeded: Successful
single-cluster::>veeam_user が veeam-backup-bucket に対してフルアクセス（読み書き・削除）を行えるよう、バケットポリシーステートメントを追加します。
single-cluster::> vserver object-store-server bucket policy add-statement -vserver svm_s3 -bucket veeam-backup-bucket -effect allow -action GetObject,PutObject,DeleteObject,ListBucket,GetBucketLocation,ListBucketVersions -principal veeam_user -sid "VeeamFullAccess"
single-cluster::>バケットポリシーが正しく登録されたか確認します。
single-cluster::> vserver object-store-server bucket policy show -vserver svm_s3 -bucket veeam-backup-bucket
Vserver Bucket Index Effect Action Principal Resource
----------- ---------- ----- ------ ------------ --------------- --------------
svm_s3
veeam-backup-bucket
1 allow GetObject, veeam_user veeam-backup-
PutObject, bucket,
DeleteObject veeam-backup-
, bucket/*
ListBucket,
GetBucketLoc
ation,
ListBucketVe
rsions
single-cluster::>バケットの稼働状態とサイズ上限を確認します。
single-cluster::> vserver object-store-server bucket show -vserver svm_s3
Vserver Bucket Type Volume Size Encryption Role NAS Path
----------- --------------- -------- ----------------- ---------- ---------- ---------- ----------
svm_s3 veeam-backup-bucket
s3 fg_oss_1786800611 300GB false standalone -
single-cluster::>Step7. TLS 接続用の自己署名 Root CA とサーバー証明書の作成
本作業では OpenSSL をインストールした Linux を使用します。理由となりますが、VBR から ONTAP の S3 バケットに接続する際、TLS 接続が必要になります。そのためには SSL 証明書が必要となります。
ここで NetApp の公式ドキュメントを参照すると、Root CA → CSR → 署名という手順が案内されています。
Create and install a CA certificate on an ONTAP S3-enabled SVM
このドキュメントで重要な点がわかります。FQDN（今回は s3.makorin.org ）が Subject の CN（Common Name）だけでなく、SAN（Subject Alternative Name） に含まれている必要があるという点です。そのため、SSL 証明書（サーバー証明書）に SAN を含めるために Root CA を使用する流れで説明がされています。
しかし、ONTAP の CLI のサーバー証明書の生成機能（security certificate create）では、SAN を入れられません（SAN を指定する引数がありません）。ドキュメントでは CSR を経由させるため Root CA が登場しているだけなのです。
なお、ONTAP 9.8 以降の System Manager（Web GUI）は内部的に REST API（/api/security/certificates 等）を利用して動作しているため、subject_alternative_names フィールドが使用可能です。GUI のウィザードから S3 サーバーを作成・設定する際に自動生成される証明書には、入力された FQDN やサービス IP が自動的に SAN に組み込まれる仕様となっているようです。そのため、Web GUI を使用すれば、サクッと S3 バケットを作ることが可能ですが、当記事では CLI 前提で進めます。
以下、Linux 上の OpenSSL を使用した自己署名 Root CA と SAN 入りサーバー証明書の生成手順となります。
Step1. 作業ディレクトリの作成
# mkdir -p ./s3-pki
# cd s3-pki/
# umask 077Step2. Root CA の作成
pathlen:0 は「この CA の直下にサーバー証明書しか置かない」という宣言です。中間 CA を挟ないためです。
# openssl genrsa -out s3-root-ca.key 2048
# openssl req -x509 -new -nodes -key s3-root-ca.key -sha256 -days 3650 \
-subj "/C=JP/ST=Kanagawa/O=makorin/CN=S3-Root-CA" \
-addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
-addext "keyUsage=critical,keyCertSign,cRLSign" \
-addext "subjectKeyIdentifier=hash" \
-out s3-root-ca.crtStep3. サーバー（Leaf）用の秘密鍵と CSR の生成
# openssl genrsa -out s3.makorin.org.key 2048
# openssl req -new -key s3.makorin.org.key \
-subj "/C=JP/ST=Kanagawa/O=makorin/CN=s3.makorin.org" \
-out s3.makorin.org.csrStep4. 拡張定義ファイルの作成（SAN 本体）
IP:192.168.1.82 も入れておくと、hosts が効いていない状態でも IP 直指定で疎通確認ができるので、切り分けが楽になります。
# cat > s3-leaf.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = critical,digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
subjectAltName = DNS:s3.makorin.org,IP:192.168.1.82
EOF
# ls
s3-leaf.ext s3-root-ca.crt s3-root-ca.key s3.makorin.org.csr s3.makorin.org.keyStep5. Root CA で署名
# openssl x509 -req -in s3.makorin.org.csr \
-CA s3-root-ca.crt -CAkey s3-root-ca.key -CAcreateserial \
-days 825 -sha256 \
-extfile s3-leaf.ext \
-out s3.makorin.org.crt
Certificate request self-signature ok
subject=C=JP, ST=Kanagawa, O=makorin, CN=s3.makorin.orgStep6. 自己検証（必須）
# SAN と EKU の確認
# openssl x509 -in s3.makorin.org.crt -noout -text | grep -A1 "Subject Alternative Name"
X509v3 Subject Alternative Name:
DNS:s3.makorin.org, IP Address:192.168.1.82
# openssl x509 -in s3.makorin.org.crt -noout -ext extendedKeyUsage,basicConstraints
X509v3 Basic Constraints:
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication
# チェーンの検証
# openssl verify -CAfile s3-root-ca.crt s3.makorin.org.crt
s3.makorin.org.crt: OK
# 証明書と秘密鍵のペア一致（同じハッシュが出ればOK）
# openssl x509 -noout -modulus -in s3.makorin.org.crt | openssl md5
MD5(stdin)= ab06d53e9b52d9ee3acb9edb4273f5d1
# openssl rsa -noout -modulus -in s3.makorin.org.key | openssl md5
MD5(stdin)= ab06d53e9b52d9ee3acb9edb4273f5d1Step8. ONTAP へのサーバー証明書を投入と動作確認
Linux の CLI に接続しつつ、ONTAP にも CLI 接続して実行します。
Step1. Linux で Root CA の表示と ONTAP への投入
# cat s3-root-ca.crt
-----BEGIN CERTIFICATE-----
MIIDgjCCAmqgAwIBAgIUTEikZrU4rqBsfna4Ubbf/Ztn724wDQYJKoZIhvcNAQEL
省略
AtPdhcFHz6amMXv/VsQvhjquD70xQ9eBdz0CxZony6etD5RTa2s8d3hgFaXupNv0
3TVUCAqj9mNOgFx8Ech5MmZ4CKrmHgIF7Of2ReRwf2yj2rbKpPw=
-----END CERTIFICATE-----single-cluster::> security certificate install -vserver svm_s3 -type server-ca
Enter certificate: Press <Enter> when done
-----BEGIN CERTIFICATE-----
MIIDgjCCAmqgAwIBAgIUTEikZrU4rqBsfna4Ubbf/Ztn724wDQYJKoZIhvcNAQEL
省略
AtPdhcFHz6amMXv/VsQvhjquD70xQ9eBdz0CxZony6etD5RTa2s8d3hgFaXupNv0
3TVUCAqj9mNOgFx8Ech5MmZ4CKrmHgIF7Of2ReRwf2yj2rbKpPw=
-----END CERTIFICATE-----
You should keep a copy of the CA-signed digital certificate for future reference.
The installed certificate's CA and serial number for reference:
CA: S3-Root-CA
serial: 4C48A466B538AEA06C7E76B851B6DFFD9B67EF6E
The certificate's generated name for reference: S3-Root-CA
single-cluster::>Step2. Linux でサーバー証明書の表示と ONTAP への投入
# cat s3.makorin.org.crt
-----BEGIN CERTIFICATE-----
MIIDtTCCAp2gAwIBAgIUY47Y+S7+ggX8WUrQys2R1uzlCoQwDQYJKoZIhvcNAQEL
省略
xEEFW7i843BJHeYbvlwt6JeG+DZmZNKsKcpRMWBUQ1UFuRjEv5kMRp4fTEQlv+iU
sC2WciQRfDDUhZzXXD9c2QE2E5WKwpWNZVndTMkC9E4BVnb48haDHnM=
-----END CERTIFICATE-----
# cat s3.makorin.org.key
-----BEGIN PRIVATE KEY-----
MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQC5FlMt7ZaTYmEt
省略
9CcRT/8SkNEYk7GgKPGo80VnD+aSAiG8/2zVxw96ZsfBdctdbfdBsqZV6+7PB9su
J0nCiwgPAfqldcolnbGXS/Z0HQ==
-----END PRIVATE KEY-----最後の “The certificate’s generated name for reference” の値を控えておきます。
single-cluster::> security certificate install -vserver svm_s3 -type server
Please enter Certificate: Press <Enter> when done
-----BEGIN CERTIFICATE-----
（s3.makorin.org.crt を貼付）
-----END CERTIFICATE-----
Please enter Private Key: Press <Enter> when done
-----BEGIN PRIVATE KEY-----
（s3.makorin.org.key を貼付）
-----END PRIVATE KEY-----
Do you want to continue entering root and/or intermediate certificates {y|n}: y
Please enter Intermediate Certificate: Press <Enter> when done
-----BEGIN CERTIFICATE-----
（s3-root-ca.crt を貼付）
-----END CERTIFICATE-----
Do you want to continue entering root and/or intermediate certificates {y|n}: n
You should keep a copy of the private key and the CA-signed digital certificate for future reference.
The installed certificate's CA and serial number for reference:
CA: S3-Root-CA
serial: 638ED8F92EFE8205FC594AD0CACD91D6ECE50A84
The certificate's generated name for reference: s3.makorin.org_638ED8F92EFE8205FC594AD0CACD91D6ECE50A84
single-cluster::>Step3. ONTAP の S3 サーバーへのバインドと HTTPS リスナーの確認
single-cluster::> vserver object-store-server modify -vserver svm_s3 -status-admin down
single-cluster::> vserver object-store-server modify -vserver svm_s3 -certificate-name s3.makorin.org_638ED8F92EFE8205FC594AD0CACD91D6ECE50A84
single-cluster::> vserver object-store-server modify -vserver svm_s3 -certificate-name s3.makorin.org_638ED8F92EFE8205FC594AD0CACD91D6ECE50A84 -is-http-enabled false -is-https-enabled true -secure-listener-port 443
single-cluster::> vserver object-store-server modify -vserver svm_s3 -status-admin up
single-cluster::>反映を確認します。
single-cluster::> vserver object-store-server show -vserver svm_s3 -instance
Vserver: svm_s3
Object Store Server Name: s3.makorin.org
Administrative State: up
HTTP Enabled: false
Listener Port For HTTP: 80
HTTPS Enabled: true
Secure Listener Port For HTTPS: 443
Certificate for HTTPS Connections: s3.makorin.org_638ED8F92EFE8205FC594AD0CACD91D6ECE50A84
Default UNIX User: pcuser
Default Windows User: -
Maximum Value for Key TTL: -
Maximum Object Lock Retention Period: none
Minimum Object Lock Retention Period: none
Comment:
single-cluster::>Step4. Linux から疎通確認
Windows（VBR）の Schannel を経由しない環境で先に検証します。ここが通らなければ Windows 側の作業をしても無意味になります。
# ハンドシェイクとチェーン検証（Verify return code: 0 (ok)の応答を期待）
# openssl s_client -connect 192.168.1.82:443 -servername s3.makorin.org -CAfile s3-root-ca.crt </dev/null
Connecting to 192.168.1.82
CONNECTED(00000003)
depth=1 C=JP, ST=********, O=makorin, CN=S3-Root-CA
verify return:1
depth=0 C=JP, ST=********, O=makorin, CN=s3.makorin.org
verify return:1
---
Certificate chain
0 s:C=JP, ST=********, O=makorin, CN=s3.makorin.org
i:C=JP, ST=********, O=makorin, CN=S3-Root-CA
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Sep 22 02:51:10 2026 GMT; NotAfter: Dec 25 02:51:10 2028 GMT
1 s:C=JP, ST=********, O=makorin, CN=S3-Root-CA
i:C=JP, ST=********, O=makorin, CN=S3-Root-CA
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Sep 22 02:43:14 2026 GMT; NotAfter: Sep 19 02:43:14 2036 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDtTCCAp2gAwIBAgIUY47Y+S7+ggX8WUrQys2R1uzlCoQwDQYJKoZIhvcNAQEL
省略
xEEFW7i843BJHeYbvlwt6JeG+DZmZNKsKcpRMWBUQ1UFuRjEv5kMRp4fTEQlv+iU
sC2WciQRfDDUhZzXXD9c2QE2E5WKwpWNZVndTMkC9E4BVnb48haDHnM=
-----END CERTIFICATE-----
subject=C=JP, ST=********, O=makorin, CN=s3.makorin.org
issuer=C=JP, ST=********, O=makorin, CN=S3-Root-CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Peer Temp Key: X25519, 253 bits
---
SSL handshake has read 2438 bytes and written 408 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE
[root@dolphin s3-pki]## S3 エンドポイントとしての応答確認（403の応答を期待）
# curl -v --cacert s3-root-ca.crt --resolve s3.makorin.org:443:192.168.1.82 https://s3.makorin.org/
* Added s3.makorin.org:443:192.168.1.82 to DNS cache
* Hostname s3.makorin.org was found in DNS cache
* Trying 192.168.1.82:443...
* Connected to s3.makorin.org (192.168.1.82) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: s3-root-ca.crt
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=JP; ST=********; O=makorin; CN=s3.makorin.org
* start date: Sep 22 02:51:10 2026 GMT
* expire date: Dec 25 02:51:10 2028 GMT
* subjectAltName: host "s3.makorin.org" matched cert's "s3.makorin.org"
* issuer: C=JP; ST=********; O=makorin; CN=S3-Root-CA
* SSL certificate verify ok.
* TLSv1.2 (OUT), TLS header, Unknown (23):
> GET / HTTP/1.1
> Host: s3.makorin.org
> User-Agent: curl/7.76.1
> Accept: */*
>
* TLSv1.2 (IN), TLS header, Unknown (23):
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< Server: NetApp CSS/9.18.1
< Date: Tue, 22 Sep 2026 03:34:39 GMT
< Connection: Close
< Content-Length: 143
< Content-Type: application/xml
< x-amz-request-id: 3516746658
<
* Closing connection 0
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS alert, close notify (256):
<?xml version="1.0" encoding="UTF-8"?><Error><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>3516746658</RequestId></Error>
#Linux からの TLS 接続も全く問題がないため、これで ONTAP の S3 エンドポイントの作成も正常に完了しました。次に Windows の設定と接続テストに移ります。
Step9. VBR（Windows）への証明書投入と動作確認
Windows Server 2025 上で PowerShell を使用して投入します。Root CA 証明書（s3-root-ca.crt）だけを Windows へ転送しておきます。保存パスは C:\temp としました。
# hosts への登録
PS C:\Users\Administrator> Add-Content -Path C:\Windows\System32\drivers\etc\hosts -Value "192.168.1.82`ts3.makorin.org"
# Root CA をコンピューターの「信頼されたルート証明機関」へ
PS C:\Users\Administrator> Import-Certificate -FilePath C:\temp\s3-root-ca.crt -CertStoreLocation Cert:\LocalMachine\Root
PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\Root
Thumbprint Subject
---------- -------
5EDB54C1D4D68F5343003B99057DFD4778186E61 CN=S3-Root-CA, O=makorin, S=Kanagawa, C=JP
# 検証
PS C:\Users\Administrator> Invoke-WebRequest https://s3.makorin.org/
Invoke-WebRequest : 接続が切断されました: 送信時に、予期しないエラーが発生しました。。
発生場所 行:1 文字:1
+ Invoke-WebRequest https://s3.makorin.org/
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest]、WebExce
ption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
PS C:\Users\Administrator>ここまできた人は、後述の「Step10. S3 Compatible Object Storage としてリポジトリ登録」以降の章に飛んで続きを読んでください。ネスト ESXi 上に ONTAP Select を構築しておらず、物理サーバー上の ESXi 上の VM として ONTAP Select を構築している人は、PowerShell コマンド “Invoke-WebRequest https://s3.makorin.org/” は成功するはずです。
以降の章は、Proxmox 上にネスト ESXi を導入し、ネスト ESXi 上の VM に ONTAP Select を構築した人向けの原因調査のくだりとなります。悪戦苦闘と切り分けコマンドを楽しみたい人のみご参照いただけると幸いです。
切り分け編
Linux ではうまくいくのに Windows ではうまくいかない。Windows のイベントログを参照してみます。
# ログの詳細出力を有効にします。
PS C:\Users\Administrator> New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL' -Name 'EventLogging' -Value 7 -PropertyType DWord -Force
EventLogging : 7
PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProvider
s\SCHANNEL
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProvider
s
PSChildName : SCHANNEL
PSDrive : HKLM
PSProvider : Microsoft.PowerShell.Core\Registry
# TLS 接続を試します。
PS C:\Users\Administrator> Invoke-WebRequest https://s3.makorin.org/
Invoke-WebRequest : 接続が切断されました: 送信時に、予期しないエラーが発生しました。。
発生場所 行:1 文字:1
+ Invoke-WebRequest https://s3.makorin.org/
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest]、WebExce
ption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
# ログを確認します。
PS C:\Users\Administrator> Get-WinEvent -LogName System -MaxEvents 50 | Where-Object {$_.ProviderName -eq "Schannel"} | Select-Object -First 5 -Property TimeCreated, Id, Message | Format-List
TimeCreated : 2026/09/22 13:14:19
Id : 36880
Message : TLS クライアント ハンドシェイクが完了しました。ネゴシエーション暗号化パラメーターは次のとおりです。
プロトコル バージョン: TLS 1.3
CipherSuite: 0x1302
Exchange の強度: 384 ビット
コンテキスト ハンドル: 0x241e29fda80
ターゲット名: localhost
ローカル証明書のサブジェクト名:
リモート証明書のサブジェクト名: CN=WIN-CEMAA5HFNV1
省略イベントログに該当するログが出力されていませんでした。このことから、Windows の Schannel は「ハンドシェイク失敗」のイベントすら記録していません。つまりハンドシェイクの失敗として Schannel に認識される段階まで、そもそも到達していない可能性が高いということです。
TLSより下のレイヤー、ネットワーク経路上でのパケット破損の可能性を探ります。Windows の仮想 NIC オフロードによるパケット破損を疑って、これを無効化して試します。
# 無効化します。
PS C:\Users\Administrator> Disable-NetAdapterLso -Name "*"
PS C:\Users\Administrator> Disable-NetAdapterChecksumOffload -Name "*"
# TLS 接続を試します。
PS C:\Users\Administrator> Invoke-WebRequest https://s3.makorin.org/
Invoke-WebRequest : 接続が切断されました: 送信時に、予期しないエラーが発生しました。。
発生場所 行:1 文字:1
+ Invoke-WebRequest https://s3.makorin.org/
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest]、WebExce
ption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
# オフロード機能を再び有効化します。
PS C:\Users\Administrator> Enable-NetAdapterLso -Name "*"
PS C:\Users\Administrator> Enable-NetAdapterChecksumOffload -Name "*"最後の手段、パケットキャプチャします。
# 1. 443番ポートのTCP通信をフィルタ
PS C:\Users\Administrator> pktmon filter add -p 443
フィルターが追加されました。
# 2. キャプチャ開始（.etl形式で保存される）
PS C:\Users\Administrator> pktmon start --capture --pkt-size 0 -f C:\temp\s3capture.etl
ロガー パラメーター:
ロガー名: PktMon
ログ モード: 循環
ログ ファイル: C:\temp\s3capture.etl
最大ファイル サイズ: 512 MB
使用されているメモリ: 256 MB
収集されたデータ:
パケット カウンター、パケット キャプチャ
キャプチャの種類:
すべてのパケット
監視対象コンポーネント:
すべて
パケット フィルター:
# 名前 ポート
- -- ---
1 <empty> 443
# 3. 別ウィンドウ、または少し待ってから問題の接続をテスト
PS C:\Users\Administrator> Invoke-WebRequest https://s3.makorin.org/
Invoke-WebRequest : 接続が切断されました: 送信時に、予期しないエラーが発生しました。。
発生場所 行:1 文字:1
+ Invoke-WebRequest https://s3.makorin.org/
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest]、WebExce
ption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
# 4. キャプチャ停止
PS C:\Users\Administrator> pktmon stop
ログをフラッシュしています...
メタデータを結合しています...
ログ ファイル: C:\temp\s3capture.etl (イベントは失われていません)
# 5. キャプチャファイルを pcapng 形式に変換します。
PS C:\Users\Administrator> pktmon pcapng C:\temp\s3capture.etl -o C:\temp\s3capture.pcapng
処理しています...
パケットの合計: 24
パケットのドロップ カウント: 0
書式設定されたパケット: 24
書式設定されたファイル: C:\temp\s3capture.pcapng取得したパケットを解析すると、以下の挙動であることが判明しました。
[0-5] 3-way handshake 正常完了
[6-7] Client Hello (170バイト) 送信 正常に受信されている
[8-9] サーバーは TCP ACK のみ返す（TLSデータは一切なし）
[10-11] クライアントが RST で強制切断
ネストESXi上の ONTAP Select であることを踏まえると、大きなデータを送ろうとした瞬間だけ通信が途絶えている可能性を想定しました。パケットサイズを変えて Windows から S3 エンドポイントに ICMP でパケットサイズを変更しながら疎通確認します。
PS C:\Users\Administrator> ping -f -l 1472 192.168.1.82
192.168.1.82 に ping を送信しています 1472 バイトのデータ:
192.168.1.82 からの応答: バイト数 =1472 時間 =2ms TTL=64
192.168.1.82 からの応答: バイト数 =1472 時間 =1ms TTL=64
192.168.1.82 からの応答: バイト数 =1472 時間 =1ms TTL=64
192.168.1.82 からの応答: バイト数 =1472 時間 =15ms TTL=64
192.168.1.82 の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 1ms、最大 = 15ms、平均 = 4ms
PS C:\Users\Administrator> ping -f -l 1400 192.168.1.82
192.168.1.82 に ping を送信しています 1400 バイトのデータ:
192.168.1.82 からの応答: バイト数 =1400 時間 =2ms TTL=64
192.168.1.82 からの応答: バイト数 =1400 時間 =2ms TTL=64
192.168.1.82 からの応答: バイト数 =1400 時間 =1ms TTL=64
192.168.1.82 からの応答: バイト数 =1400 時間 =2ms TTL=64
192.168.1.82 の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 1ms、最大 = 2ms、平均 = 1ms
PS C:\Users\Administrator> ping -f -l 1200 192.168.1.82
192.168.1.82 に ping を送信しています 1200 バイトのデータ:
192.168.1.82 からの応答: バイト数 =1200 時間 =1ms TTL=64
192.168.1.82 からの応答: バイト数 =1200 時間 =1ms TTL=64
192.168.1.82 からの応答: バイト数 =1200 時間 =2ms TTL=64
192.168.1.82 からの応答: バイト数 =1200 時間 =1ms TTL=64
192.168.1.82 の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 1ms、最大 = 2ms、平均 = 1ms
PS C:\Users\Administrator>全て問題なし。PMTU ブラックホールの可能性は否定されました。。
念のため、最後に ONTAP を再起動し、Linux から改めてテストします。
single-cluster::> vserver object-store-server show -vserver svm_s3 -instance
Vserver: svm_s3
Object Store Server Name: s3.makorin.org
Administrative State: up
HTTP Enabled: false
Listener Port For HTTP: 80
HTTPS Enabled: true
Secure Listener Port For HTTPS: 443
Certificate for HTTPS Connections: s3.makorin.org_638ED8F92EFE8205FC594AD0CACD91D6ECE50A84
Default UNIX User: pcuser
Default Windows User: -
Maximum Value for Key TTL: -
Maximum Object Lock Retention Period: none
Minimum Object Lock Retention Period: none
Comment:
single-cluster::>Administrative State: up で正常。次に Linux の OpenSSL から TLS1.2 と TLS1.3 の両方で試します。
# TLS1.2 でテスト
# openssl s_client -connect 192.168.1.82:443 -servername s3.makorin.org -tls1_2 -CAfile s3-root-ca.crt </dev/null
Connecting to 192.168.1.82
CONNECTED(00000003)
depth=1 C=JP, ST=********, O=makorin, CN=S3-Root-CA
verify return:1
depth=0 C=JP, ST=********, O=makorin, CN=s3.makorin.org
verify return:1
---
Certificate chain
0 s:C=JP, ST=********, O=makorin, CN=s3.makorin.org
i:C=JP, ST=********, O=makorin, CN=S3-Root-CA
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Sep 22 02:51:10 2026 GMT; NotAfter: Dec 25 02:51:10 2028 GMT
1 s:C=JP, ST=********, O=makorin, CN=S3-Root-CA
i:C=JP, ST=********, O=makorin, CN=S3-Root-CA
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Sep 22 02:43:14 2026 GMT; NotAfter: Sep 19 02:43:14 2036 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDtTCCAp2gAwIBAgIUY47Y+S7+ggX8WUrQys2R1uzlCoQwDQYJKoZIhvcNAQEL
省略
xEEFW7i843BJHeYbvlwt6JeG+DZmZNKsKcpRMWBUQ1UFuRjEv5kMRp4fTEQlv+iU
sC2WciQRfDDUhZzXXD9c2QE2E5WKwpWNZVndTMkC9E4BVnb48haDHnM=
-----END CERTIFICATE-----
subject=C=JP, ST=********, O=makorin, CN=s3.makorin.org
issuer=C=JP, ST=********, O=makorin, CN=S3-Root-CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Peer Temp Key: X25519, 253 bits
---
SSL handshake has read 2483 bytes and written 307 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Protocol: TLSv1.2
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 185FB16D908DBE66EC8FD29A0556FCF019EA0768BA28C5140C78EE8106216D8F
Session-ID-ctx:
Master-Key: 7A18D4D332AC9364571714EA820D21A915E6007A704EECB717849997D6E95BD6B67D2B210CDF4FBF53F8E44713CDA0E2
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 94 96 3b f1 90 5c ea 9f-ec 15 06 6c 68 90 c6 40 ..;..\.....lh..@
0010 - 84 0f b6 84 e1 fe 86 c7-a0 47 9e 70 f0 33 2c 28 .........G.p.3,(
省略
0080 - c1 69 36 68 82 bc f6 c6-bf 28 e3 cc d3 bf 1d 49 .i6h.....(.....I
0090 - fb 84 da 0d c3 79 f1 17-a9 fc 5f 49 25 a1 09 aa .....y...._I%...
Start Time: 1790058913
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
DONE
# TLS1.3 でテスト
# openssl s_client -connect 192.168.1.82:443 -servername s3.makorin.org -tls1_3 -CAfile s3-root-ca.
crt </dev/null
Connecting to 192.168.1.82
CONNECTED(00000003)
depth=1 C=JP, ST=********, O=makorin, CN=S3-Root-CA
verify return:1
depth=0 C=JP, ST=********, O=makorin, CN=s3.makorin.org
verify return:1
---
Certificate chain
0 s:C=JP, ST=********, O=makorin, CN=s3.makorin.org
i:C=JP, ST=********, O=makorin, CN=S3-Root-CA
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Sep 22 02:51:10 2026 GMT; NotAfter: Dec 25 02:51:10 2028 GMT
1 s:C=JP, ST=********, O=makorin, CN=S3-Root-CA
i:C=JP, ST=********, O=makorin, CN=S3-Root-CA
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Sep 22 02:43:14 2026 GMT; NotAfter: Sep 19 02:43:14 2036 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDtTCCAp2gAwIBAgIUY47Y+S7+ggX8WUrQys2R1uzlCoQwDQYJKoZIhvcNAQEL
省略
xEEFW7i843BJHeYbvlwt6JeG+DZmZNKsKcpRMWBUQ1UFuRjEv5kMRp4fTEQlv+iU
sC2WciQRfDDUhZzXXD9c2QE2E5WKwpWNZVndTMkC9E4BVnb48haDHnM=
-----END CERTIFICATE-----
subject=C=JP, ST=********, O=makorin, CN=s3.makorin.org
issuer=C=JP, ST=********, O=makorin, CN=S3-Root-CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Peer Temp Key: X25519, 253 bits
---
SSL handshake has read 2438 bytes and written 335 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE
[root@dolphin s3-pki]#これも正常接続できることを確認しました。そして Windows から。
PS C:\Users\Administrator> Invoke-WebRequest https://s3.makorin.org/
Invoke-WebRequest : 接続が切断されました: 送信時に、予期しないエラーが発生しました。。
発生場所 行:1 文字:1
+ Invoke-WebRequest https://s3.makorin.org/
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest]、WebExce
ption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
PS C:\Users\Administrator>やはりだめです。そこで VBR の Windows のブラウザから ONTAP の S3 エンドポイントにアクセスしてみました。
ここまでをまとめると以下のとおりです。
・Linux からは、再起動後は TLS 1.2・TLS 1.3の両方でハンドシェイクが成立し、Server Hello 以降のすべてが正常に届いている。
・Windows の Schannel とブラウザ（Chromium 系＝Schannel を使わない独自実装の BoringSSL ）でも、実装が全く異なる2つの TLS ライブラリが、同じ宛先に対して同じエラーとなるということは、問題は TLS ライブラリより下のレイヤー、つまりこのWindows 自体のネットワークスタック、あるいはこの経路上での通信問題と分かりました。
うーん、困った。。
問題箇所は分かったものの、これは・・Proxmox 、Proxmox 上のネスト ESXi 、ネスト ESXi 上の VM（Windows） の仮想ネットワークデバイス、または Windows OS のネットワークスタック周りの問題の可能性が高いです。それもおそらくネスト環境あるあるの TCP のオフロード機能に問題があると当たりをつけます。
ONTAP 主観で階層にすると以下のとおり。
ONTAP (nested ESXi配下)
└─ nested ESXi の仮想スイッチ（vSwitch0）
└─ nested ESXi VM自体の vNIC（vmnic0）①
└─ Proxmox の仮想ブリッジ（vmbr0）
└─ Proxmox 上の VBR VM の tap インターフェース（tap105i0）③
└─ VBR VM (Windows VM、VirtIO) ②
①ONTAP が動作するネストESXi の vNIC（vmnic0）の TSO（TCP Segmentation Offload） を無効化
# ネスト ESXi の CLI で実行。現状の確認。
[root@esxi7:~] esxcli network nic list
[root@esxi7:~] esxcli network nic tso get -n vmnic0
# TSO を無効化。
[root@esxi7:~] esxcli network nic tso set -n vmnic0 -e 0結果、事象変わらずでした。
②VBR（Windows）の OS の NICドライバ設定でオフロード機能（TSO/LSO、チェックサムオフロード）を無効化
# Windows の Powershell から実行。
# LSO（Large Send Offload）を無効化
PS C:\Users\Administrator> Disable-NetAdapterLso -Name "*"
# RSC（Receive Segment Coalescing）を無効化
PS C:\Users\Administrator> Disable-NetAdapterRsc -Name "*"
# チェックサムオフロードを無効化
PS C:\Users\Administrator> Disable-NetAdapterChecksumOffload -Name "*"
# LSO の反映結果を確認
PS C:\Users\Administrator> Get-NetAdapterLso -Name "*"
Name Version V1IPv4Enabled IPv4Enabled IPv6Enabled
---- ------- ------------- ----------- -----------
イーサネット LSO Version 2 False False False
# RSC の反映結果を確認
PS C:\Users\Administrator> Get-NetAdapterRsc -Name "*"
Name IPv4Enabled IPv6Enabled IPv4Operational IPv6Operational IPv4FailureReason IPv6FailureR
State State eason
---- ----------- ----------- --------------- --------------- ----------------- ------------
イーサネット False False False False NicPropertyDis... NicProper...
# チェックサムオフロードの結果を確認
PS C:\Users\Administrator> Get-NetAdapterChecksumOffload -Name "*"
Name IpIPv4Enabled TcpIPv4Enabled TcpIPv6Enabled UdpIPv4Enabled UdpIPv6Enabled
---- ------------- -------------- -------------- -------------- --------------
イーサネット Disabled Disabled Disabled Disabled Disabled結果、事象変わらずでした。
③Proxmox 上の VBR（Windows）VM が紐づく TAP インターフェースのオフロード機能の無効化
# Proxmox ホストの CLI で実行。
# VBR の VM の VMID を確認。
root@ve:~# qm list
VMID NAME STATUS MEM(MB) BOOTDISK(GB) PID
100 VM 100 stopped 10240 60.00 0
101 62-VBR-ENT stopped 15360 100.00 0
103 55-WP running 3072 50.00 1822
104 Win11 stopped 8192 100.00 0
105 63-VBR-ENT running 14336 100.00 637102
106 80-XFS-REPO stopped 4096 40.00 0
107 70-OT-DeployVM stopped 4096 40.00 0
108 90-ESXi running 21504 40.00 19814
# VBR VM の tap インターフェース名を確認。
root@ve:~# ip a | grep tap
5: tap103i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr103i0 state UNKNOWN group default qlen 1000
18: tap108i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
27: tap105i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr105i0 state UNKNOWN group default qlen 1000
# オフロードを無効化。
root@ve:~# ethtool -K tap105i0 tx off rx off tso off gso off gro offそして、この設定を投入後に、遂に VBR（Windows）から ONTAP S3 エンドポイントとの間の TLS 接続が成功しました。HTTP 403（AccessDenied）が正しく XML で返ってきて、TLS ハンドシェイクが成立している状態です。
PS C:\Users\Administrator> Invoke-WebRequest https://s3.makorin.org/
Invoke-WebRequest : AccessDeniedAccess Denied3522224072
発生場所 行:1 文字:1
+ Invoke-WebRequest https://s3.makorin.org/
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest]、WebExce
ption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand次のステップに即座に進みたいところですが、念のため、①と②のオフロード機能を再度有効化し、③だけの設定で通るかどうかを検証します。
# ESXi の vNIC（vmnic0）の TSO を有効化
[root@esxi7:~] esxcli network nic tso get -n vmnic0
NIC Value
------ -----
vmnic0 off
[root@esxi7:~] esxcli network nic tso set -n vmnic0 -e 1
[root@esxi7:~] esxcli network nic tso get -n vmnic0
NIC Value
------ -----
vmnic0 on
# VBR（Windows）の NIC でオフロード機能を有効化
PS C:\Users\Administrator> Enable-NetAdapterLso -Name "*"
PS C:\Users\Administrator> Enable-NetAdapterRsc -Name "*"
PS C:\Users\Administrator> Enable-NetAdapterChecksumOffload -Name "*"
# VBR VM の tap インターフェースのオフロードを無効化（上記コマンドでリセットされてしまうため）
root@ve:~# ethtool -K tap105i0 tx off rx off tso off gso off gro off最後に接続テストを実行します。
PS C:\Users\Administrator> Invoke-WebRequest https://s3.makorin.org/
Invoke-WebRequest : AccessDeniedAccess Denied3511245912
発生場所 行:1 文字:1
+ Invoke-WebRequest https://s3.makorin.org/
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest]、WebExce
ption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
PS C:\Users\Administrator>問題ありません。これで、Proxmox ホストの vmid=105 (63-VBR-ENT) の tap105i0 インターフェースにおける vhost-net 層のオフロード機能（tx/rx/tso/gso/gro）が、TLS の大きめレスポンス（Server Hello + Certificateチェーン）を破損させているものと特定できました。
問題がゲスト OS ではなく、Proxmox ホスト側の vhost-net（tapインターフェース）にあったとなります。
なお、Proxmox ホストの tap インターフェースのオフロード機能は再起動や VM 側のオフロード設定の変更などであっけなく初期化されてしまうため、恒久的な対応を講じます。
以下のスクリプトを設置し、VM 105（VBR/Windows）に紐づけます。
root@ve:~# vi /var/lib/vz/snippets/105-offload-fix.sh
#!/bin/bash
# /var/lib/vz/snippets/105-offload-fix.sh
VMID="$1"
PHASE="$2"
if [ "$VMID" == "105" ] && [ "$PHASE" == "post-start" ]; then
sleep 5
ethtool -K tap105i0 tx off rx off tso off gso off gro off
fi
root@ve:~# chmod +x /var/lib/vz/snippets/105-offload-fix.sh
root@ve:~# qm set 105 --hookscript local:snippets/105-offload-fix.sh
update VM 105: -hookscript local:snippets/105-offload-fix.sh切り分け編は以上です。
Step10. S3 Compatible Object Storage としてリポジトリ登録
まず最初に以下の二点を確認・設定しておきます。
・VBR サーバーから ONTAP S3 のデータ LIF（192.168.1.82）への疎通確認
・VBR サーバーの Windows の hosts にオブジェクトストレージサーバーのホスト名を登録
なお、Windows の hosts ファイルは以下パスにあります。
C:\Windows\System32\drivers\etc\hosts
10.1. 新規オブジェクトストレージリポジトリの追加
VBR のコンソールを開き、リポジトリ追加ウィザードを起動し、”Backup Infrastructure” ⇒ “Backup Repositories” で設定します。 さらに “Object Storage” ⇒ “S3 Compatible” を選択。
■Name
“Limit concurrent tasks to:” は、このオブジェクトストレージリポジトリに対して、同時に実行できる処理タスク（データ転送スレッド）の最大数を制限する機能です。今回は並行処理も走りませんのでチェックを外して無制限にしました。「Next」をクリックします。
■Account
“Service point” ⇒ ONTAP S3 の LIF アドレス（HTTPS）を入力します。
“Region:” ⇒ デフォルトの us-east-1 のままで進めます。
“Credentials” ⇒ “Add” をクリックし、ONTAP で発行したキー情報を入力します。なお、キー情報とは以下のものです。
single-cluster::> vserver object-store-server user regenerate-keys -vserver svm_s3 -user veeam_user
Vserver: svm_s3
User: veeam_user
Access Key: ********************
Secret Key: ****************************************
Warning: The secret key won't be displayed again. Save this key for future use.“Connection mode: Direct” ⇒ デフォルトのままにします。
「Next」をクリックします。以下のエラーが出力されます。
これは、今回使用している証明書は自己署名の Root CA（S3-Root-CA）によって発行されたサーバー証明書であり、CRL 配布先や OCSP サーバーが定義されていないため、検証が「失効しているかどうかが判定不能」と判断して本警告を表示しています。今回は意図した結果ですので、「Continue」で進めます。
■Bucket
「Browse」をクリックするとエラーが発生。これは、ONTAP に作成したアカウント “veeam_user” に許可されているリソース権限が、特定バケット（veeam-backup-bucket および veeam-backup-bucket/*）に限定されており、バケット一覧全体を取得する権限がないからです。
そのため、手動でバケットを指定します。今回は “veeam-backup-bucket” を入力し、次の “Folder” の入力に進みます。今度は「Browse」で “veeam-backup-bucket” 以下に新規のフォルダーを作成できるはずです。テスト用として “TEST” というフォルダーを作成しました。
「Limit object storage consumption to:」オプションと「Make backups immutable」オプションは、AWS の S3 バケットに接続した時と同様の機能です。今回はどちらも指定しません。
「Next」をクリックすると以下の警告が出ます。ONTAP にはすでに veeam-backup-bucket と TEST フォルダーが作成済みであり、ユーザー veeam_user にはバケット作成権限が含まれていないため、自動作成機能を無視して作成済みのバケットを利用します。そのため、「Yes」を選択します。
■Mount Server
VBR 自身が設定されていることを確認し、「Next」をクリックします。
オプション “Search the repository for existing backups and import them automatically” は、リポジトリ内の既存バックアップを検索し、自動的にインポートする機能です。今回は新規作成のためチェックしません。
■Apply
自動で設定が進行します。完了したら「Next」をクリックします。
最終的な確認を行って、問題がなければ「Finish」をクリックして完了です。
これで ONTAP S3 バケットを対象としたレポジトリー登録が完了しました。次回、バックアップ編です。
まとめ
本記事では、Proxmox VE 上のネスト ESXi 環境において、NetApp ONTAP Select 9.18.1 を Veeam Backup & Replication (VBR) 13.1 の S3 互換オブジェクトストレージ（Direct-to-Object）リポジトリとして登録する一連の流れをまとめました。
主なポイントは以下の通りです。
- ONTAP S3 の基本構成: データ用アグリゲート、S3 専用 SVM、データ LIF、S3 サーバー機能、アクセスキーを持つ S3 ユーザー、300GB のバックアップ先バケット（
veeam-backup-bucket）の作成とポリシー割り当てを実施しました。 - SAN 入りサーバー証明書の作成と適用: ONTAP 単体では生成できない SAN（Subject Alternative Name）付き証明書を Linux の OpenSSL 上で作成し、ONTAP へのインポートと HTTPS リスナーへのバインドを行いました。
- Proxmox ネスト環境における TLS 通信の切り分け: Windows の Schannel やブラウザからの TLS 接続が切断される問題に対し、Proxmox ホスト側で VBR VM の tap インターフェース（
tap105i0）におけるオフロード機能（tx/rx/tso/gso/gro）を無効化し、フックスクリプトによって設定を恒久化することで解決しました。 - VBR へのリポジトリ登録: 証明書失効確認警告（RevocationStatusUnknown）の承認、バケット名の手動入力、S3 オブジェクトストレージリポジトリとしての登録を完了しました。
これでバックアップデータを格納する基盤の準備が整いました。次回は、実際にバックアップジョブを作成してデータを取得する「バックアップ編」を予定しています
- makorin
AI を使用して情報を得ることが普通の時代になりました。その AI もウェブ上に公開されている情報を元にして動作しています。その情報の一つになればいいなという、極々ささやかな思いで気ままに更新しています。
- Veeam v13 のリポジトリに NetApp ONTAP Select を S3 接続（Direct-to-Object）する手順 2026年9月23日
- NetApp ONTAP SelectをネストESXiへ構築する方法｜Deploy VMからの導入手順 2026年8月3日
- Proxmox VEでESXi 8をネスト構築する方法｜VM作成時の設定ポイントまとめ 2026年7月25日
- Veeam V13でProxmoxのスナップショットをロールバックしたら増分バックアップは壊れるのか？ 2026年7月5日
- Veeam v13 S3 Object StorageからProxmoxへVMをリストアする手順 2026年6月28日