概要
AWS上で Amazon FSx for OpenZFS を利用する前提で、Linux クライアント、オンプレミスの Windows 11 パソコン、S3 エンドポイントを含めた検証環境を作り、接続経路と UID / GID の整合性を確認した内容をまとめます。
今回の前提として、インターネットへ接続する経路は S3 Endpoint 関連のみ とし、それ以外のクライアントやストレージは閉域寄りの構成で扱いました。
この記事では、特に以下を整理します。
- 検証用 VPC / サブネット構成
- 各クライアント / エンドポイントの接続位置
- Windows 11 側の
AnonymousUid/AnonymousGid設定 - S3 エンドポイント側でそろえた POSIX 属性
- 実際に検証時に意識した設定ポイント
FSx for OpenZFS は NFS ベースのファイル共有を前提にするため、クライアントごとの UID / GID の扱いを最初にそろえておくと、後から権限差分でハマりにくくなります。
検証の目的
今回の検証で確認したかったのは、次の 3 点です。
- protected サブネット上の Linux から FSx for OpenZFS に問題なくアクセスできるか
- オンプレミスの Windows 11 から NFS クライアントとしてアクセスしたときに、所有者のズレを防げるか
- S3 エンドポイント側で扱う POSIX 属性を
uid=1000/gid=1000にそろえた場合、運用上の整合性を保てるか
検証環境の全体像
検証用の VPC を新規に作成し、サブネットは public、private、protected の 3 つを用意しました。
ただし、外部向けの通信は常時広く許可せず、インターネットからの接続先は S3 Endpoint のみ という前提で構成しています。
サブネットの役割
| サブネット | 主な役割 | 想定配置 |
|---|---|---|
| public | 将来の拡張や管理用途を見越したセグメント | 今回は常用なし |
| private | 将来の内部向けリソース拡張用 | 今回は常用なし |
| protected | クライアント検証用の内部セグメント | FSx for OpenZFS、Linux クライアント |
protected サブネットは、インターネットへ直接さらさず、Linux クライアントや FSx for OpenZFS を内部通信で扱うイメージです。今回の検証では、インターネットからの接続先は S3 Endpoint のみとし、S3 Endpoint から FSx for OpenZFS へ連携する構成にしました。
検証クライアント
今回アクセス元として用意したのは以下の 3 つです。
| クライアント | 配置 | 用途 |
|---|---|---|
| Linux | VPC の protected サブネット | FSx for OpenZFS への主たる NFS マウント確認 |
| Windows 11 | オンプレミス（VPN 経由で VPC 接続） | NFS クライアント利用時の UID / GID 整合性確認 |
| S3 エンドポイント | VPC 内 | インターネットからの受け口と FSx for OpenZFS への連携確認 |
Windows 11 からの疎通については、オンプレミスと VPC の間にインターネット VPN を構成し、その経路で VPC 側へ到達できる前提で検証しています。
FSx for OpenZFS 側で意識したこと
FSx for OpenZFS 自体の細かなパラメータは環境要件に依存しますが、今回の検証では最低限次の点を意識しました。
- FSx for OpenZFS は protected サブネット側に配置する
- Linux クライアントと Windows 11 から到達できるルーティングを用意する
- セキュリティグループ / ファイアウォールで NFS 通信を許可する
- オンプレミスからの接続は VPN 経由に限定する
- インターネットからの接続は S3 Endpoint のみに限定する
- S3 Endpoint から FSx for OpenZFS への連携経路を明確にする
- ファイル所有者の基準となる UID / GID を
1000:1000に寄せる
特に、Linux と Windows の間でファイル所有者が食い違うと、書き込み可否の切り分けが面倒になるため、今回は UID / GID を明示的にそろえました。
Linux クライアントの設定
protected サブネット上の Linux では、同じ protected サブネットに配置した FSx for OpenZFS を通常の NFS クライアントとしてマウントします。
確認ポイント
- NFS クライアントパッケージが入っていること
- マウント先ディレクトリを作成していること
- アプリケーション実行ユーザー、または作業ユーザーが
uid=1000/gid=1000を利用すること
設定例
sudo mkdir -p /mnt/fsx-openzfs
id
sudo mount -t nfs -o nfsvers=4.1 \
<fsx_dns_name>:/fsx /mnt/fsx-openzfs
必要に応じて、Linux 側の作業ユーザーを uid=1000 / gid=1000 にそろえておくと、Windows や S3 Endpoint 経由で FSx を参照したときの所有者差異を減らしやすくなります。
Windows 11 クライアントの設定
Windows 11 から NFS マウントする場合、所有者マッピングでハマりやすいため、今回は AnonymousUid = 1000、AnonymousGid = 1000 を設定しました。
設定方針
- Windows の「NFS クライアント」機能を有効化する
- Windows 標準の NFS クライアントを利用する
- 匿名アクセス時の UID / GID を
1000に固定する - Linux 側と同じ所有者として扱えるようにする
レジストリ設定例
PowerShell を管理者権限で開いて設定します。
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default" -Name "AnonymousUid" -PropertyType DWord -Value 1000 -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default" -Name "AnonymousGid" -PropertyType DWord -Value 1000 -Force
設定後は、NFS クライアント関連サービスの再起動、または OS 再起動を行ってからマウント確認するのが安全です。
Windows 側で AnonymousUid / AnonymousGid を設定しないまま検証すると、Linux 側で見た所有者が意図しない値になり、書き込み権限の切り分けが難しくなります。
Windows 11 からの接続でハマった点（セキュリティグループ）
Windows 11 からの接続確認時に一番ハマったのは、セキュリティグループのポート開放条件でした。
- NFS ポートだけを許可した状態では接続できなかった
- 特に
NFSv3利用時は追加ポートが必要だった
今回の検証では、以下を許可して接続できるようになりました。
| 用途 | 許可ポート/プロトコル |
|---|---|
| NFSリモートプロシージャコール | 111/tcp 111/udp |
| NFSサーバーデーモン | 2049/tcp 2049/udp |
| NFSマウント ステータスモニター UDP ロックデーモン |
20001-20003/tcp 20001-20003/udp |
2049 のような NFS の代表ポートのみを開けても、NFSv3 の場合は接続不可になるケースがあります。Windows 11 から接続する場合は、セキュリティグループで 111/tcp,111/udp と 20001-20003/tcp,20001-20003/udp の追加を先に確認しておくと切り分けが早いです。
S3 エンドポイント側の POSIX 設定
今回の検証では、S3 Endpoint から FSx for OpenZFS へ連携する際に扱う POSIX 属性も Linux / Windows とそろえて、uid=1000、gid=1000 に統一しました。
そろえた理由
- ストレージ間でファイル所有者の見え方を合わせたい
- 検証時の比較条件を単純化したい
- 後続の自動処理や連携処理で権限差異を減らしたい
設定方針
| 項目 | 値 |
|---|---|
| UID | 1000 |
| GID | 1000 |
| 目的 | Linux / Windows 11 と所有者表現をそろえる |
S3 Endpoint から FSx for OpenZFS へ流れるデータに POSIX 属性を与える場合は、FSx 側・Linux 側・Windows 側で基準となる UID / GID を一致させておくと、検証ログの読み解きがかなり楽になります。
設定内容まとめ
今回の構成で、最低限そろえた設定を表にすると次のとおりです。
| 対象 | 配置 / 接続元 | 主な設定 | 備考 |
|---|---|---|---|
| FSx for OpenZFS | protected サブネット | NFS アクセス許可、クライアントからの到達性確保 | ストレージ本体 |
| Linux クライアント | protected サブネット | NFS マウント、uid=1000 / gid=1000 を基準化 |
検証の主軸 |
| Windows 11 | オンプレミス |
AnonymousUid=1000、AnonymousGid=1000、VPN 経由で接続 |
NFS 利用時の所有者合わせ |
| セキュリティグループ（Windows 11 / NFSv3） | FSx for OpenZFS へのインバウンド |
111/tcp、1024-65535/tcp を追加許可 |
NFS ポートのみでは接続不可だったため追加 |
| VPN | On-Premises - VPC 間 | オンプレミスから protected サブネットへの接続経路 | インターネット VPN |
| S3 エンドポイント | VPC 内 | POSIX を uid=1000 / gid=1000、Internet からの接続を受けて FSx へ連携 |
属性の整合性確認 |
| VPC | 検証用に新規作成 | public / private / protected の 3 サブネット、Internet からの接続先は S3 Endpoint のみ | 責務分離 |
検証で見たかった観点
今回のような構成で確認しておくとよい観点は、次のようなものです。
- Linux から作成したファイルを別クライアントから見たときの所有者表示
- Windows 11 から作成 / 更新したファイルが Linux 側でどう見えるか
- S3 Endpoint から FSx for OpenZFS へ連携した処理で POSIX 属性が期待通りか
- protected サブネット内の Linux から FSx for OpenZFS への到達性に問題がないか
- S3 Endpoint 以外に不要な Internet 向け経路が存在しないか
- 権限エラー発生時に、ネットワーク要因か UID / GID 要因かを切り分けられるか
この構成でよかった点
- サブネットの責務が分かれていて、通信経路を整理しやすい
- Linux / Windows / S3 で UID / GID をそろえたことで、所有者の見え方を比較しやすい
- Internet -> S3 Endpoint -> FSx for OpenZFS の流れを明示でき、外部接続点を限定しやすい
- Windows 11 の匿名 UID / GID を事前設定したことで、NFS 検証時の混乱を減らせる
今後の課題
今回の検証で動作確認はできたものの、実運用に向けては以下の観点を追加で詰める必要があります。
-
各クライアントからの接続制限と権限設計
Linux / Windows 11 / S3 Endpoint のそれぞれについて、どの経路・どの送信元のみ許可するかを明確化し、セキュリティグループ・NACL・VPN 側の制御を最小権限で再設計する必要があります。あわせて、NFS エクスポートポリシーやディレクトリ単位のアクセス権を整理し、クライアントごとの操作可能範囲を定義することが課題です。
-
mount 可能な環境の制御方式
どの環境から mount を許可するかを、ネットワーク境界（サブネット / VPN / 送信元 CIDR）と端末要件（運用端末・踏み台・サーバーロール）で制御する方針を固める必要があります。運用面では、許可済みクライアント一覧の管理、変更申請フロー、定期棚卸しを含めたガバナンス設計も必要です。
-
その他のセキュリティ観点
監査ログ（接続元、失敗イベント、権限エラー）の収集、異常アクセスの検知、定期的な権限レビュー、バックアップ / リストア手順の検証、インシデント時の切り分け手順を整備する必要があります。特に、UID / GID を統一した構成では「誰が実行した操作か」を補完する仕組みを別途用意することが重要です。
まとめ
FSx for OpenZFS の検証では、ストレージ本体の設定だけでなく、クライアント側の UID / GID 設計 を早めに決めることがかなり重要でした。
今回の構成では、以下を統一したのがポイントです。
- 検証用 VPC は
public/private/protectedの 3 サブネットで分離 - On-Premises と VPC の間は VPN で接続
- Internet からの接続先は S3 Endpoint のみに限定
- FSx for OpenZFS と Linux クライアントは
protectedサブネットに配置 - Linux クライアントは protected サブネットに配置
- Windows 11 は
AnonymousUid = 1000、AnonymousGid = 1000 - S3 エンドポイント側の POSIX も
uid=1000、gid=1000
FSx for OpenZFS を複数クライアントから扱う場合は、まずネットワーク到達性、その次に UID / GID の統一という順で見ると、トラブルシュートしやすいと思います。