Synology NASで運用する公開WebサーバをCloudflareプロキシ化する実践ガイド

以下の記事で、Synology NASで構築したWebサイトのDDNSをCloudflareのDNSで実現する設定方法について紹介しています。

参考　Synology NASで構築したWebサイトのDDNSをCloudflareのDNSで実現する設定方法

また、以下の記事で、Synology NASでacme.sh（DNS-01）を使った証明書自動更新について紹介しています。

参考　Cloudflareプロキシ有効時でも使える！Synology NASでacme.sh（DNS-01）を使った証明書自動更新

ここまでで、Synology NASをCloudflareと連携させるための下準備は整いました。
DDNSをCloudflareに統合し、Cloudflareプロキシを有効にした状態でもacme.shを用いて証明書を自動更新できる環境が構築できています。

本記事では、これらの仕組みを前提として、いよいよSynology NAS上で運用している公開WebサーバをCloudflareプロキシ配下に置く構成について解説します。
まずは、管理系アクセスと公開Webアクセスを分離した、本記事で想定する全体構成を整理していきます。

前提　本記事でのDSM（OS）バージョンはSynology DSM 7.3を用いています。

1.想定構成

本記事で想定する構成は以下のとおりです。

• DSM 管理画面・Synology Web アプリ：Synology DDNS 経由（Cloudflare 対象外）
• 公開 Web サーバ：独自ドメイン + Cloudflare プロキシ
• IPv6 優先構成
• 個人／SOHO 運用を想定

管理系のアクセス経路と公開 Web サーバの経路を分離することで、安定性とセキュリティのバランスを取る設計としています。

2.DNS 設定をプロキシ ON にする

Cloudflare ダッシュボードの「DNS」設定画面で、対象となるレコードのプロキシステータスを ON（プロキシ済み）にします。

これにより、外部から DNS 参照された際に返される IP アドレスは Cloudflare の IP アドレスとなり、クライアントからのリクエストは一度 Cloudflare が受け取った後、オリジンサーバへ中継されます。この中継処理の中で、Cloudflare のセキュリティ機能や CDN 機能が動作します。

なお、DNS レコードに登録されている IP アドレス自体は、オリジンサーバの実 IP のままで問題ありません。変更されるのは、外部から参照された際に返却される IP アドレスのみです。

3.オリジンサーバとの通信設定（SSL/TLS 暗号化）

Cloudflare ダッシュボードの「SSL/TLS」→「概要」にて、SSL/TLS 暗号化モードを「フル（厳密）」に設定します。（デフォルトでは「自動」になっているため、明示的に変更します。）

「フル（厳密）」を選択することで、Cloudflare とオリジンサーバ間の通信も TLS により暗号化され、オリジンサーバ側の証明書検証が行われます。※ここで、事前に acme.sh を用いて取得した証明書が使用されます。

なお、Cloudflare のクライアント証明書は Cloudflare とオリジンサーバ間の通信専用であり、ローカル環境などからの直接アクセスには利用できません。

ここまでの設定で、Cloudflare プロキシは有効化され、デフォルト状態でも一定のセキュリティ機能と CDN による配信が機能します。以下は、さらに運用品質を一段高めるための推奨設定です。

4.DNS の A レコード（IPv4）を削除する（推奨）

Cloudflare ダッシュボードの DNS 設定画面で、対象ドメインの A レコード（IPv4）を削除します。

目的は、Cloudflare とオリジンサーバ間の通信を IPv6 のみに限定することです。フレッツ光環境では IPv6 経由通信の方が効率的な場合が多く、通信品質の向上が期待できます。

公開 Web サイトとしての IPv4 アクセスについては、Cloudflare プロキシを有効化しているため Cloudflare 側で IPv4 アドレスが提供され、IPv4 からのアクセスも問題なくオリジンサーバへ中継されます。

5.Synology NAS の Firewall 設定（推奨）

公開 Web サーバへの入口が Cloudflare に集約されたため、Synology NAS 側では Firewall 設定により到達経路を大幅に絞ることができます。

HTTPS（443）に対して、以下のルールを設定します。

• 送信元が Cloudflare の IP アドレスの場合は許可（公開 Web サーバ用）
• 送信元が日本（JP）の場合は許可（DSM 管理画面や Synology Web アプリ用）

CloudflareのIPアドレスについては以下にて公開されています。

前述の設定により Cloudflare とオリジンサーバ間通信を IPv6 のみに限定している場合、Cloudflare の IP アドレス条件も IPv6 のみとします。

送信元を JP に限定したルールは、公開 Web サーバ以外の用途（DSM 管理画面やモバイルアプリ利用）を考慮して残しています。この構成でも、HTTPS ポートに対する不正アクセスは大幅に減少します。

6.リバースプロキシ設定（対象があれば必須）

Cloudflare プロキシ経由のアクセスでは、オリジンサーバから見る送信元 IP アドレスは Cloudflare の IP アドレスとなります。そのため、アクセス解析などでクライアントの実 IP アドレスが必要なアプリについては、HTTP ヘッダを通じて実 IP を引き渡す設定が必要です。

以下のカスタムヘッダをリバースプロキシ設定に追加します。

• CF-IPCountry : $http_cf_ipcountry
• CF-RegionCode : $http_cf_regioncode
• CF-IPCity : $http_cf_ipcity
• X-Forwarded-For : $http_cf_connecting_ip
• X-Real-IP : $http_cf_connecting_ip

これらの設定は、DSM の「コントロールパネル」→「ログインポータル」→「詳細設定」→「リバースプロキシ」から、必要なアプリごとに設定します。

すべてのアプリに一律で設定するのではなく、実 IP が必要なアプリに限定して設定することが重要です。

7.Cloudflare セキュリティルールの設定（推奨）

Cloudflare の WAF 機能を利用すると、L7 レベルで柔軟な条件指定によるアクセス制御が可能です。これを活用することで、不正アクセスや既知攻撃への耐性を高めることができます。

設定箇所はCloudflare ダッシュボードの「セキュリティ」→「セキュリティルール」→「カスタムルール」です。以下は WordPress サイトを想定した設定例です。

1. 管理画面を日本 IP のみに限定
   • 条件式: (starts_with(http.request.uri.path, "/wp-admin") and http.request.uri.path ne "/wp-admin/admin-ajax.php" and ip.src.country ne "JP")
   • アクション: ブロック
2. 高リスクエンドポイントの遮断
   • 条件式: (http.request.uri.path eq "/xmlrpc.php") or (starts_with(http.request.uri.path, "/wp-json/wp/v2/users"))
   • アクション: ブロック
3. 悪名高いファイルスキャンの遮断
   • 条件式: (http.request.uri.path contains "/.env") or (http.request.uri.path contains "/.git") or (http.request.uri.path contains "/wp-config.php")
   • アクション: ブロック
4. PHP 直叩きの抑止
   • 条件式: (ends_with(http.request.uri.path, ".php"))
   • アクション: マネージドチャレンジ

マネージドチャレンジは、正規ユーザーのブラウザアクセスを許可しつつ、Bot などの不正アクセスのみを排除できる点が特徴です。これらの設定はあくまで一例であり、利用している CMS やアプリケーションに応じて調整が必要です。

8.Cloudflare キャッシュルールの設定（推奨）

Cloudflare の CDN 機能はデフォルトではキャッシュ対象が限定的であり、HTML ドキュメントは基本的にキャッシュされません。Cache Rules を設定することで、キャッシュ対象を明示的に指定できます。

設定箇所はCloudflare ダッシュボードの「Caching」→「Cache Rules」です。
以下は WordPress サイトを想定した設定例です。

1. ログイン中ユーザーをキャッシュ除外
   • 条件式: (http.cookie contains "wordpress_logged_in_")
   • 実行内容: キャッシュをバイパス
2. 管理画面・API をキャッシュ除外
   • 条件式: (starts_with(http.request.uri.path, "/wp-admin/")) or (starts_with(http.request.uri.path, "/wp-login")) or (starts_with(http.request.uri.path, "/wp-json"))
   • 実行内容: キャッシュをバイパス
3. 静的ファイルをキャッシュ対象
   • 条件式: (starts_with(http.request.uri.path, "/wp-content/"))
   • 実行内容: キャッシュの対象
   • TTL: 1 日
   • ブラウザ TTL: オリジンをオーバーライドし 1 日
4. 一般ページをキャッシュ対象
   • 条件式: (http.host eq "masao-tec.com")
   • 実行内容: キャッシュの対象
   • TTL: 2 時間

これらの設定も例であり、サイト構成や更新頻度に応じて調整してください。

9.まとめ

本構成により、以下のような典型的な攻撃・不要アクセスをCloudflareのエッジで遮断できるようになります。

• オリジンサーバ IP の直接アクセス
• 海外 Bot による総当たりアクセス
• WordPress の既知攻撃（xmlrpc等）
• 無差別な設定ファイル・環境ファイルスキャン

Cloudflare プロキシは単に DNS を切り替えるだけでなく、Firewall や WAF、CDN と組み合わせることで真価を発揮します。Synology NAS での個人・SOHO 運用においても、現実的かつ効果的な構成の一例として参考になれば幸いです。