オリジンサーバーへの接続を Cloudflare だけにする 

# Protect your origin server (Secure origin connections)

本家ドキュメントに記載の[オリジンサーバーを守る方法（オリジンサーバへの接続を安全にする）](https://developers.cloudflare.com/fundamentals/basic-tasks/protect-your-origin-server/#secure-origin-connections)を実際に試してみます。

|レイヤー|方法|free,pro,business|enterprise|本記事|Cloudflare からのみ接続可能|Cloudflare 自分のアカウントからのみ接続可能|備考|
|-|-|-|-|-|-|-|-|
|アプリケーション層|Cloudflare Tunnel (HTTP)|✓|✓|✓|-|✓|-|
||HTTP Basic 認証|✓|✓|✓|-|✓|-|
||JSON Web Tokens（JWT）検証|✓|✓|✓|-|✓|Eyeball-Cloudflare間の認証も必要|
|トランスポート層|Authenticated Origin Pulls|✓|✓|✓|✓（Cloudflare証明書）|✓（持ち込み証明書）|証明書に 2 つの方式<br>（Cloudflare or 持ち込み）|
|ネットワーク層|Cloudflare IPアドレス 許可リスト|✓|✓|✓|✓|-|AWS VPC を例に|
||CNI|-|✓|-|-|✓|-|
||Cloudflare Aegis|-|✓|-|-|✓|-|

## はじめに
本記事の前提についてメモしておきます。
### CLI/API で作業

IP アドレスや TLS 証明書などを接続元判別の材料として使うので、実際の運用となれば、定期的な更新作業が入ると思います。そのため、ダッシュボードではなく CLI/API を基本に操作します。

### オリジンサーバーの IP アドレスは知られる前提で

オリジンサーバーへの接続を考える場合、オリジンサーバーの IP アドレスは大事な要素になります。
クラウド型のリバースプロキシーを中間に入れた際に、オリジンサーバーの IP アドレスを隠そうとする方策はありますが、そもそもパブリックにさらされるもなので、知られる前提でいきます。
なるだけ推測されないような[手段を講じ](https://developers.cloudflare.com/fundamentals/basic-tasks/protect-your-origin-server/#secure-origin-connections)ておくのが推奨ですが、知ろうと思えば、ツールもいろいろあります。下記は、Cloudflare でプロキシー済みなホストの DNS の履歴を [SecurityTrials](https://securitytrails.com/) で参照し、 Cloudflare 変更前のオリジンサーバーの IP アドレスを見た例です。（Cloudflare 導入後もそのままなら直接接続できるかも知れません。なお、当時も今も他のホストと共有されていたり、今は違うホストに利用されいている可能性はあります。）

<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/f19b943c-ba6d-903b-9545-bbfc65aa7e40.png">

### Cloudflare の他のアカウントからの接続

Cloudflare だけからオリジンサーバーに到達できるように保護しても、Cloudflare の他のアカウントから自分のオリジンサーバーに接続される余地は残ります。

Cloudflare 側でもいくつか対策はされています。
[Origin Rules](https://developers.cloudflare.com/rules/origin-rules/) には、オリジンサーバーに接続する際の TLS SNI や HTTP host、宛先 IP アドレスを変更する機能があります（これらの書き換えは [Enterprise プランのみ](https://developers.cloudflare.com/rules/origin-rules/#availability)）。これを使えば、他のアカウントがあなたのオリジンサーバーに接続を試みる際に、あなたのドメインを SNI 指定し、正当な経路を通ったリクエストを偽装できるように思えます。
ただし、実際には他のアカウントのドメインへの SNI 指定はできないという保護機能が働きます。
<img width="400" alt="400" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/018ea805-120a-9768-53ab-2cc46e55280f.png">

また、Enterprise プラン以外でも [Workers で fetch](https://developers.cloudflare.com/workers/examples/fetch-html/)すれば、指定した fetch 先ホストに SNI と host は変更されるので、[`resolveOverride`](https://developers.cloudflare.com/workers/runtime-apis/request/#requestinitcfproperties) で自分のドメインを指定し、オリジンサーバーの IP を返せば偽装できそうに思いますが、この機能は fetch 先ホストが自分ゾーンの場合にのみ有効になるよう制限されています。

> Directs the request to an alternate origin server by overriding the DNS lookup. The value of resolveOverride specifies an alternate hostname which will be used when determining the origin IP address, instead of using the hostname specified in the URL. ... However, resolveOverride will only take effect if both the URL host and the host specified by resolveOverride are within your zone. If either specifies a host from a different zone / domain, then the option will be ignored for security reasons. ...

これらの対策が効いている場合、オリジンサーバーが自身と異なる SNI や host を受け付けないようにしておけば、他のアカウントからの接続抑止対策の一つとなります。

ここからは、オリジンサーバーが自身以外の SNI や host も受け入れるという前提にして、どんな対策がとれるか、試していきます。


## ネットワーク層で防ぐ

### Cloudflare IP アドレス許可リスト
Cloudflare の IP アドレスからのみオリジンサーバーに接続できるようにします。
オリジンサーバーやその前段のファイアウォールで制御します。
<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/96870b18-09db-0454-b4ed-eed62020ff4d.png">

オリジンサーバーに接続する Cloudflare の IP アドレス（v4/v6）は本家ページで[公開](https://www.cloudflare.com/ips/)していますが、[JSON 形式](https://api.cloudflare.com/client/v4/ips) で取れるので、こちらを利用してみます。

<details><summary>Cloudflare IPs</summary>

```shell: IP の入手
~ $ curl -s "https://api.cloudflare.com/client/v4/ips" | jq '.result'
{
  "ipv4_cidrs": [
    "173.245.48.0/20",
    "103.21.244.0/22",
    "103.22.200.0/22",
    "103.31.4.0/22",
    "141.101.64.0/18",
    "108.162.192.0/18",
    "190.93.240.0/20",
    "188.114.96.0/20",
    "197.234.240.0/22",
    "198.41.128.0/17",
    "162.158.0.0/15",
    "104.16.0.0/13",
    "104.24.0.0/14",
    "172.64.0.0/13",
    "131.0.72.0/22"
  ],
  "ipv6_cidrs": [
    "2400:cb00::/32",
    "2606:4700::/32",
    "2803:f800::/32",
    "2405:b500::/32",
    "2405:8100::/32",
    "2a06:98c0::/29",
    "2c0f:f248::/32"
  ],
  "etag": "38f79d050aa027e3be3865e495dcc9bc"
}
```
</details>

:::note info
変更されると etag が変わります。
また、過去の新規追加時は 30 日前に Email で通知されています。これからもおそらくそうでしょう。
:::


#### 初期状態（アクセス制限なし）

本家には [iptables の例](https://developers.cloudflare.com/fundamentals/setup/allow-cloudflare-ip-addresses/)がありますが、今回は AWS EC2 にオリジンサーバーを用意しているので、VPC の [Security Group](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-security-groups.html) でポリシーを適用します。

:::note 
他のクラウドプラットフォームやオンプレミスのファイアウォールでも同じような方針でいけると思います。
:::

まず、オリジンサーバーが動く[インスタンス](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-ec2-instances.html)の NIC の パブリック IP と [Security Group](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-ec2-sg.html) の ID を[得ておきます](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-instances.html)。プロファイルは[環境変数のほうに設定済み](https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-envvars.html)とします。

```shell: 【AWS】インスタンスのパブリック IP と Security Group
~/.aws $ INSTNAME="<インスタンス名>”
~/.aws $ EC2IID=`aws ec2 describe-instances | jq -r '.Reservations[].Instances[]|select(.Tags[].Value == "'$INSTNAME'")|.InstanceId'`
~/.aws $ PUBIP=`aws ec2 describe-instances |jq -r '.Reservations[].Instances[]|select (.InstanceId == "'$EC2IID'")|.PublicIpAddress'`
~/.aws $ EC2SGID=`aws ec2 describe-instances |jq -r '.Reservations[].Instances[]|select (.InstanceId == "'$EC2IID'")|.SecurityGroups[].GroupId'`
```

初期状態としては TCP 443 宛の通信を、すべての IPv4 アドレスから許可しています。
Security Group の Port 443 の設定を[確認](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-security-groups.html)します。

```shell:【AWS】TCP 443 全部許可
~/.aws $ aws ec2 describe-security-groups --group-id $EC2SGID | jq '.SecurityGroups[].IpPermissions[]|select (.FromPort == 443)'

## 応答抜粋
{
  "FromPort": 443,
  "IpProtocol": "tcp",
  "IpRanges": [
    {
      "CidrIp": "0.0.0.0/0"
    }
  ],
  "Ipv6Ranges": [],
  "PrefixListIds": [],
  "ToPort": 443,
  "UserIdGroupPairs": []
}
```
Cloudflare ではすでにプロキシー済みですので、この状態で接続を確認しておきます。
Cloudflare 経由・直接接続、どちらも接続可能です。

```shell:【Eyeball】接続テスト
~ $ MYHOST="<テスト対象ホスト>”

# Cloudflare Proxy
~ $ curl https://$MYHOST/
Hello World

# 直接接続
~ $ curl https://$MYHOST/ --resolve $MYHOST:443:$PUBIP
Hello World
```
:::note info
[/cdn-cgi/trace](https://developers.cloudflare.com/fundamentals/reference/cdn-cgi-endpoint/) で情報が見れれば Cloudflare でプロキシー中の証です。
> % curl -s https://\$MYHOST/cdn-cgi/trace | grep colo
> colo=NRT
:::

#### アクセス制限開始
それでは、制限にかかります。
VPC の [Managed Prefix List](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/managed-prefix-lists.html) という機能が使えそうです。

まず、Cloudflare の API で得た IP 一覧を [Prefix List に使えるよう](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/create-managed-prefix-list.html)に整形します。

```shell:【準備】Cloudflare IPv4 一覧を整形
# Cloudflare の IP リストを Prefix List 対応に整形
~/.aws $ CIDR=`curl -s "https://api.cloudflare.com/client/v4/ips" | jq '.result.ipv4_cidrs | map({Cidr: .})'`

# [{"Cidr":"x.x.x.x/x"},....] という形
~/.aws $ echo $CIDR
[
  {
    "Cidr": "173.245.48.0/20"
  },
  {
    "Cidr": "103.21.244.0/22"
  },
:
```
IPv6 も同様にやります。

```shell:【準備】Cloudflare IPv6 一覧を整形
~/.aws $ CIDR6=`curl -s "https://api.cloudflare.com/client/v4/ips" | jq '.result.ipv6_cidrs | map({Cidr: .})'`

~/.aws $ echo $CIDR6
[
  {
    "Cidr": "2400:cb00::/32"
  },
  {
    "Cidr": "2606:4700::/32"
  },
: 
```

作成したデータを元に Prefix List を[作ります](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/create-managed-prefix-list.html)。

```shell:【AWS】Prefix List 作成 v4 と v6
# IPv4 Prefix List 作成
~/.aws $ aws ec2 create-managed-prefix-list \
    --address-family IPv4 \
    --max-entries 30 \
    --entries $CIDR \
    --prefix-list-name CfCidr

## 応答抜粋
    "PrefixList": {
        "PrefixListId": "pl-*",
        "AddressFamily": "IPv4",

# IPv6 Prefix List 作成
~/.aws $ aws ec2 create-managed-prefix-list \
    --address-family IPv6 \
    --max-entries 15 \
    --entries $CIDR6 \
    --prefix-list-name CfCidr6

## 応答抜粋
    "PrefixList": {
        "PrefixListId": "pl-*",
        "AddressFamily": "IPv6",
        
# 内容を確認する場合、それぞれの Prefix List ID を得る
~/.aws $ PLISTID=`aws ec2 describe-managed-prefix-lists | jq -r '.PrefixLists[]|select (.PrefixListName=="CfCidr")|.PrefixListId'`
~/.aws $ PLISTID6=`aws ec2 describe-managed-prefix-lists | jq -r '.PrefixLists[]|select (.PrefixListName=="CfCidr6")|.PrefixListId'`

# 作ったものの確認
~/.aws $ aws ec2 get-managed-prefix-list-entries --prefix-list-id $PLISTID
~/.aws $ aws ec2 get-managed-prefix-list-entries --prefix-list-id $PLISTID6
```
:::note info
max-entries を適当に 100 とかにしてたら、Prefixの上限に引っかかって進めず。
>An error occurred (RulesPerSecurityGroupLimitExceeded) when calling the AuthorizeSecurityGroupIngress operation: The maximum number of rules per security group has been reached.

回避には[こちら](https://dev.classmethod.jp/articles/amazon-vpc-support-prefix-list-resize/)を参考にしました。
:::

Prefix List をインスタンスの Security Group Ingress に[追加](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/authorize-security-group-ingress.html)し、既存の全部許可のルールは[削除](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/revoke-security-group-ingress.html)します。

```shell:【AWS】Prefixl List を Security Group に追加
# Ingress Permission に Cloudflare IP TCP 443 を追加
~/.aws $ aws ec2 authorize-security-group-ingress --group-id $EC2SGID --ip-permissions PrefixListIds="[{PrefixListId=$PLISTID},{PrefixListId=$PLISTID6}]",IpProtocol=tcp,FromPort=443,ToPort=443

## 応答抜粋
    "SecurityGroupRules": [
        {
            "SecurityGroupRuleId": "sgr-*",
            "GroupId": "sg-*",
            :
            "IpProtocol": "tcp",
            "FromPort": 443,
            "ToPort": 443,
            "PrefixListId": "pl-*"
        },
        {
            "SecurityGroupRuleId": "sgr-*",
            "GroupId": "sg-*",
            :
            "IpProtocol": "tcp",
            "FromPort": 443,
            "ToPort": 443,
            "PrefixListId": "pl-*"
        }
    ]

# Ingress Permission から Any TCP 443 を削除
~/.aws $ aws ec2 revoke-security-group-ingress --group-id $EC2SGID --ip-permissions IpRanges="[{CidrIp=0.0.0.0/0}]",IpProtocol=tcp,FromPort=443,ToPort=443

```
接続確認すると、直接接続が繋がらなくなりました。

```shell:【Eyeball】接続確認
~ $ curl https://$MYHOST
Hello World

~ $ curl https://$MYHOST --resolve $MYHOST:443:$PUBIP
curl: (28) Failed to connect to $MYHOST port 443 after 75000 ms: Couldn't connect to server

```

#### 他の Cloudflare アカウントのゾーンから到達の可能性
Cloudflare の他のアカウントのゾーン経由でアクセス可能性は残ります。

#### 補足：運用へのメモ

- Managed Prefix List のアップデート（[サブネットの追加・削除](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-managed-prefix-list.html)）

Cloudflare IP リストの変更に追随する場合に利用できます。前述したように、API で入手するリストは etag が変わるので、それをキーに変更するのがいいでしょう。
ここでは一時的に作業端末の IP を追加・削除してみます。

```shell:【AWS】既存の Prefix List の変更
# 例）操作している端末の IP アドレスを一時的に追加する
# 今の自分のIPを得る
~/.aws $ MYIP=`curl -s httpbin.org/ip | jq -r '.origin'`/32

# 現行 Version を得て、サブネット（自分IP/32）を追加
~/.aws $ PLVER=`aws ec2 describe-managed-prefix-lists | jq '.PrefixLists[]|select(.PrefixListId=="'$PLISTID'").Version'`
~/.aws $ aws ec2 modify-managed-prefix-list \
    --add-entries Cidr=$MYIP,Description=DevOffice \
    --prefix-list-id $PLISTID \
    --current-version $PLVER

## 応答抜粋
    "PrefixList": {
        "PrefixListId": "pl-*",
        "AddressFamily": "IPv4",
        :
        "Version": 1,
        :
    }

# 現行 Version を得て、サブネットを削除
~/.aws $ PLVER=`aws ec2 describe-managed-prefix-lists | jq '.PrefixLists[]|select(.PrefixListId=="'$PLISTID'").Version'`
~/.aws $ aws ec2 modify-managed-prefix-list \
    --remove-entries Cidr=$MYIP\
    --prefix-list-id $PLISTID \
    --current-version $PLVER

## 応答抜粋
    "PrefixList": {
        "PrefixListId": "pl-*",
        "AddressFamily": "IPv4",
        :
        "Version": 2,
        :
    }
```

- Managed Prefix List の max-entries を[変更](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-managed-prefix-list.html)
```shell:【AWS】Prefix List の最大値調整
# IPv4 は現行のリストが 15 行、Max を 30 から 20 に減らす
~/.aws $ aws ec2 modify-managed-prefix-list --prefix-list-id $PLISTID --max-entries 20

## 応答抜粋
    "PrefixList": {
        "PrefixListId": "pl-*",
        "AddressFamily": "IPv4",
        :
        "StateMessage": "Attempting to modify maximum entries from (30) to (20).",
        :
        "PrefixListName": "CfCidr",
        "MaxEntries": 30,
        "Version": 3,
        :
    }

# IPv6 は現行のリストが 7 行、Max を 15 から10 に減らす
~/.aws $ aws ec2 modify-managed-prefix-list --prefix-list-id $PLISTID6 --max-entries 10

## 応答抜粋
    "PrefixList": {
        "PrefixListId": "pl-*",
        "AddressFamily": "IPv6",
        :
        "StateMessage": "Attempting to modify maximum entries from (15) to (10).",
        :
        "PrefixListName": "CfCidr6",
        "MaxEntries": 15,
        "Version": 1,
        :
    }

# 確認
~/.aws $ aws ec2 describe-managed-prefix-lists |jq '.PrefixLists[]|select(.OwnerId!="AWS")|.PrefixListName,.MaxEntries'

## 応答抜粋
"CfCidr"
20
"CfCidr6"
10
```

- Managed Prefix List の[削除](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-managed-prefix-list.html)
```shell:【AWS】Security Group 作成
~/.aws $  aws ec2 delete-managed-prefix-list --prefix-list-id ＄PLISTID
```

- Security Group の[作成](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-security-group.html)

```shell:【AWS】Security Group 作成
# Security Group の作成
~/.aws $ SGID=`aws ec2 create-security-group --group-name CF_HTTP_Proxy --description "Cloudflare HTTP Proxy" --vpc-id $MYVPC | jq -r '.GroupId'`

# 作成した Security Group の確認
~/.aws $ aws ec2 describe-security-groups|jq '.SecurityGroups[]|select (.GroupId == "'$SGID'")'

## 応答抜粋
  "Description": "Cloudflare HTTP Proxy",
  "GroupName": "CF_HTTP_Proxy",
  "IpPermissions": [],
:
```

## トランスポート層で防ぐ

### Authenticated Origin Pulls

TLS の[クライアント認証（mTLS）](https://www.cloudflare.com/ja-jp/learning/access-management/what-is-mutual-tls/)で保護します。
Cloudflare がクライアントとして証明書を提示し、オリジンサーバーが認証します。Cloudflare では [Authenticated Origin Pulls](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/)と呼んでます。

二つの方法があるので、どちらも試します。

- Cloudflare 発行のクライアント証明書
- ユーザー持ち込みのクライアント証明書

> Authenticated Origin Pulls を有効にしても、オリジンサーバー側が mTLS を要求しなければ、クライアント認証なく、そのまま TLS 通信が可能です。

#### Cloudflare 発行のクライアント証明書

まずは、より簡単に実装できる Cloudflare のクライアント証明書を使う方法です。
<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/27689b1b-6fcc-4ea3-1e19-7aa13560036a.png">

オリジンサーバー側の準備をします。

- Cloudflare の CA ルート証明書をオリジンサーバーに[ダウンロード](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/set-up/zone-level/#1-upload-certificate-to-origin)
    - Cloudflare が提示してくるクライアント証明書を検証するため
- mTLS を[有効化](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/set-up/zone-level/#2-configure-origin-to-accept-client-certs)

```shell:【オリジンサーバー】Nginx
# Cloudflare ルート証明書のダウンロード
$ sudo wget https://developers.cloudflare.com/ssl/static/authenticated_origin_pull_ca.pem

# 念のため、証明書の中身をチラ見（2029年まで有効の模様）
$ openssl x509 -in authenticated_origin_pull_ca.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 6310029703491235425 (0x5791ba9556c22e61)
        Signature Algorithm: sha512WithRSAEncryption
        Issuer: C = US, O = "CloudFlare, Inc.", OU = Origin Pull, L = San Francisco, ST = California, CN = origin-pull.cloudflare.net
        Validity
            Not Before: Oct 10 18:45:00 2019 GMT
            Not After : Nov  1 17:00:00 2029 GMT
        Subject: C = US, O = "CloudFlare, Inc.", OU = Origin Pull, L = San Francisco, ST = California, CN = origin-pull.cloudflare.net
        :

# Nginx の設定ファイルでルート証明書を読み込ませ、mTLS を有効化
$ vi <Nginx の server 設定ファイル>

ssl_client_certificate /etc/nginx/certs/authenticated_origin_pull_ca.pem;
ssl_verify_client on;

```
オリジンサーバー側で正常に設定が反映されればサーバーは [mTLS を要求](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/explanation/#comparison-diagrams)します。
そのため、クライアント証明書を提示しないこれまでのリクエストはエラーとなります。

```shell:【Eyeball】接続確認
# Cloudflare 経由での接続
~ $ curl https://$MYHOST
<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>nginx/1.18.0 (Ubuntu)</center>
</body>
</html>
~ $
```

:::note info
念のためでが、この mTLS は Cloudflare とオリジンサーバー間の話であり、Eyeball と Cloudflare の間のことではありません。
:::

オリジンサーバーの mTLS 要求に対応するよう、Cloudflare の Authenticated Origin Pulls 設定を[有効](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/set-up/zone-level/#3-enable-authenticated-origin-pulls-globally)にします。SSL/TLS のモードは [Full 以上が必須](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full/)です。

```shell:【Cloudflare】Authenticated Origin Pulls 設定
# TLS 設定が Full 以上のことを確認
~/.cf $ curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/ssl" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" | jq

## 応答抜粋
    "id": "ssl",
    "value": "full",

# Authenticated Origin Pulls 現状確認（off）
~/.cf $ curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/tls_client_auth" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" | jq '.result'

## 応答抜粋
  "id": "tls_client_auth",
  "value": "off",

# Authenticated Origin Pulls 有効化（on）
~/.cf $ curl -s -X PATCH "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/tls_client_auth" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" \
     -d '{
  "value": "on"
}' | jq '.result'

## 応答抜粋
  "id": "tls_client_auth",
  "value": "on",
```
Authenticated Origin Pulls が有効になったので、再度リクエストすると、mTLS が成功しコンテンツが表示されます。

```shell:【Eyeball】接続確認
~ $ curl https://$MYHOST
Hello World
```

オリジンサーバーのログでクライアント証明書の subject DN を取ると、`CN=origin-pull.cloudflare.net,OU=Origin Pull,O=Cloudflare\x5C, Inc.,L=San Francisco,ST=California,C=US` の表示となりました。

```shell:【オリジンサーバー】Nginx アクセスログ
172.68.118.56 - CN=origin-pull.cloudflare.net,OU=Origin Pull,O=Cloudflare\x5C, Inc.,L=San Francisco,ST=California,C=US - - [03/Sep/2023:05:41:45 +0000] "GET / HTTP/1.1" 200 12 "-" "curl/8.2.1" "-"
```
#### 他の Cloudflare アカウントのゾーンから到達の可能性
Cloudflare の他のアカウントのゾーンでも同じように Authenticated Origin Pulls を有効にすれば接続の可能性が残ります。

#### ユーザー持ち込みのクライアント証明書

[特定のゾーン](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/set-up/zone-level/#4-enable-authenticated-origin-pulls-for-zone)あるいは[特定のホスト名](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/set-up/per-hostname/)について、ユーザー持ち込みのクライアント証明書を使います。

<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/01f6e3f8-835b-0405-0d9b-b5dbc62c659c.png">

持ち込みの証明書を適用する範囲を、ゾーン全体あるいはホストごとで設定します。
ホストごとの設定が[優先](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/set-up/#use-specialized-certificates)されます。

##### 特定ホストで持ち込みクライアント証明書を使う
まずは特定ホストに対して設定します。
テストで利用する CA については、[easy-rsa](https://github.com/OpenVPN/easy-rsa) を使い、下記の証明書を作成しました。

```shell:【オリジンサーバー】証明書
# CA ルート（3650日）
        Issuer: CN = Private CA EC2
        Validity
            Not Before: Sep  3 02:33:26 2023 GMT
            Not After : Aug 31 02:33:26 2033 GMT
        Subject: CN = Private CA EC2

# クライアント（825日）
        Issuer: CN = Private CA EC2
        Validity
            Not Before: Sep  3 02:37:03 2023 GMT
            Not After : Dec  6 02:37:03 2025 GMT
        Subject: CN = Cloudflare Edge Servers
```

まず、作成したクライアント証明書と秘密鍵（PEM）について、改行を置換したデータを用意します。

```shell:【オリジンサーバー】API アップロードサンプルに合わせ整形
# ルート証明書とクライアントの秘密鍵（PEM）の改行を \n に置換
$ sed -z -e 's/\n/\\n/g' issued/edge.cloudflare_certonly.crt
-----BEGIN CERTIFICATE-----\nM..==\n-----END CERTIFICATE-----\n

$ sed -z -e 's/\n/\\n/g' private/client.key
-----BEGIN PRIVATE KEY-----\nM..Y=\n-----END PRIVATE KEY-----\n

```

クライアント証明書と秘密鍵を Cloudflare に[アップロード](https://developers.cloudflare.com/api/operations/per-hostname-authenticated-origin-pull-upload-a-hostname-client-certificate)します。

```shell:【Cloudflare】クライアント証明書と秘密鍵のアップロード
# 初期は設定が空
~/.cf $ curl -s -X GET  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth/hostnames/certificates" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" | jq '.'

# API でアップロード（status が pending_deployment）
~/.cf $ curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth/hostnames/certificates" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" \
     -d '{
           "certificate":"-----BEGIN CERTIFICATE-----\nM..==\n-----END CERTIFICATE-----\n",
           "private_key":"-----BEGIN PRIVATE KEY-----\nM..Y=\n-----END PRIVATE KEY-----\n"
        }' | jq '.result'

## 応答抜粋
  "id": "2*",
  "status": "pending_deployment",

# 再確認（status が active）
~/.cf $ curl -s -X GET  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth/hostnames/certificates" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" | jq '.result'

## 応答抜粋
  "id": "2*",
  "status": "active",
```

アップロードした持ち込みクライアント証明書を特定ホストに対して[適用](https://developers.cloudflare.com/api/operations/per-hostname-authenticated-origin-pull-enable-or-disable-a-hostname-for-client-authentication)します。


```shell:【Cloudflare】特定ホストに持ち込み証明書を適用
# 証明書 ID の取得
~/.cf $ CERTID=`curl -s -X GET  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth/hostnames/certificates" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" | jq -r '.result[].id'`

# ID とホスト名で有効化（status が pending_deployment）
~/.cf $ curl -s -X PUT  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth/hostnames" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" \
     -d '{
     "config":[
       {
         "cert_id": "'$CERTID'",
         "enabled": true,
         "hostname":"'$MYHOST'"
       }
      ]
     }' | jq '.result'

## 応答抜粋
    "hostname": "$MYHOST",
    "cert_id": "2*",
    "enabled": true,
    "status": "pending_deployment",

# 再確認（status が active）
~/.cf $ curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth/hostnames/$TLSHOST" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" | jq '.result.status'

## 応答抜粋
    "active"
```
オリジンサーバーでは、当該の Virtual Host が参照するルート証明書を切り替えます。

```shell:【オリジンサーバー】Nginx
# mTLS に使う CA ルート証明書を Cloudflare からオレオレに切り替え
ssl_client_certificate /etc/nginx/certs/easyrsa_ca.pem;
```

この状態で、再度接続してみます。
オリジンサーバーのアクセスログで subject DN が持ち込み証明書の `CN=Cloudflare Edge Servers` となっています。

```shell:【Eyeball】接続確認
# 切り替えられ、当該ホストへの接続が成功
~ $ curl https://$MYHOST/
Hello World

## オリジンサーバーのアクセスログ（subject DN が持ち込んだクライアント証明書）
172.68.118.3 - CN=Cloudflare Edge Servers - - [03/Sep/2023:07:28:57 +0000] "GET / HTTP/1.1" 200 12 "-" "curl/8.2.1" "-"
```

##### ゾーン全体で持ち込みクライアント証明書を使う
この状態ではゾーンに属する他のホストでは相変わらず Cloudflare のクライアント証明書が使われます。
[ゾーン全体で持ち込み証明書](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/set-up/zone-level/#4-enable-authenticated-origin-pulls-for-zone)を利用する場合は、下記の設定を[有効](https://developers.cloudflare.com/api/operations/zone-level-authenticated-origin-pulls-set-enablement-for-zone)にします。
```shell:【Cloudflare】ゾーン全体への持ち込み証明書適用
# ゾーン全体への適用状況の確認（false＝未適用）
~/.cf $ curl -s -X GET  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth/settings" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" | jq '.result'

## 応答抜粋
  "enabled": false

# オリジンサーバーのアクセスログ（subject DN は Cloudflare のクライアント証明書）
172.68.119.56 - CN=origin-pull.cloudflare.net,OU=Origin Pull,O=Cloudflare\x5C, Inc.,L=San Francisco,ST=California,C=US - - [03/Sep/2023:07:55:55 +0000] "GET / HTTP/1.1" 200 12 "-" "curl/8.2.1" "-"

# 証明書と秘密鍵のアップロード（特定ホストの場合と違う URL なので注意）
~/.cf $  curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" \
     -d '{"certificate":"'$EDGCRT'",
     "private_key":"'$EDGKEY'"
     }' | jq '.result'

## 応答抜粋
  "id": "b*",
  "status": "pending_deployment",
  "issuer": "CN=Private CA EC2",

# ゾーン全体のクライアント証明書が持ち込みに設定変更がされるが、
# "enabled": false なので その他のホストで mTLS が無効になる
~ $ curl https://<ゾーンの他のホスト>/
<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>nginx/1.18.0 (Ubuntu)</center>
</body>
</html>
~ $

# オリジンサーバーのアクセスログ（どちらのクライアント証明書も来ていない）
172.68.119.47 - - - - [03/Sep/2023:08:39:49 +0000] "GET / HTTP/1.1" 400 246 "-" "curl/8.2.1" "-"

# ゾーンでの持ち込み証明書利用を有効にする
~/.cf $ curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth/settings" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" \
     -d '{"enabled":true}' | jq '.result'

## 応答抜粋
  "enabled": true

# その他ホストも mTLS に対応し、持ち込み証明書を利用開始
# アクセスログ（subject DN が持ち込んだクライアント証明書）
172.68.118.108 - CN=cf1 - - [03/Sep/2023:08:44:12 +0000] "GET / HTTP/1.1" 400 224 "-" "curl/8.2.1" "-"
```
:::note info
機能理解の参考に、実験として簡易的な CA で作業をしました。
実際の本番環境では参照せず、証明書の更新、廃止など、管理運用は厳密に行ってください。
:::


#### 他の Cloudflare アカウントのゾーンから到達の可能性
持ち込み証明書を利用したことで、他のアカウントのゾーンからのオリジン到達が失敗しています。

```shell:【Eyeball】他のアカウントのゾーンからオリジンへつなぐ
# 他のアカウントからオリジンを向けた接続は失敗しはじめる
~ $ curl https://<他のゾーン>/
<html>
<head><title>400 The SSL certificate error</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The SSL certificate error</center>
<hr><center>nginx/1.18.0 (Ubuntu)</center>
</body>
</html>
```
## アプリケーション層で防ぐ

### Cloudflare Tunnel
オリジンサーバーに cloudflared を導入し、そのトンネル経由で接続します。
うまく動けば、オリジンサーバー側のファイアウォールでは Port 443 を閉じることができます。
<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/a3ff7e31-ff2c-8905-6a5c-9c05214ada98.png">

cloudflared は[ダッシュボード](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/install-and-setup/tunnel-guide/remote/)あるいは [CLI](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/install-and-setup/tunnel-guide/local/) で作る方法があります。
今回は API を使ってダッシュボードを CLI 風に操作してみます。


まず cloudflared トンネルを[作成](https://developers.cloudflare.com/api/operations/cloudflare-tunnel-create-a-cloudflare-tunnel)します。

:::note
cloudflared は通信宛先に [Port 7844 TCP/UDP](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/install-and-setup/ports-and-ips/#destinations-and-ports) を使います。特定の内部サーバーからのみ Port 7844 への通信を許可するなど、外向け通信のファイアウォールポリシーを定義するなど、勝手トンネルの乱立を防ぐのが推奨です。
:::

Cloudflare API へのアップロードするデータの [config_src](https://developers.cloudflare.com/api/operations/cloudflare-tunnel-create-a-cloudflare-tunnel#request-body) は 2 パターンあります（デフォルトは local）。
- local: cloudflared の稼働するサーバーで cloudflared の設定を[管理](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/install-and-setup/tunnel-guide/local/local-management/configuration-file/)（config.yaml ファイル利用）
- cloudflare: ダッシュボードで管理

今回はダッシュボード（というか [API](https://developers.cloudflare.com/api/#cloudflare-tunnel-configuration-properties)）で管理するので、cloudflare を指定します。

```shell:【Cloudflare】cloudflared トンネルの作成
~/.cf $ curl -s -X POST "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" \
     -d '{
     "config_src": "cloudflare",
     "name": "EC2 Origin"
    }' | jq '.result'

## 応答抜粋
  "id": "8*",
  "name": "EC2 Origin",
  "tun_type": "cfd_tunnel",
  "status": "inactive",
  "remote_config": true,
```
作成したトンネルに[設定](https://developers.cloudflare.com/api/operations/cloudflare-tunnel-configuration-put-configuration)を当てていきます。
具体的には、オリジンサーバーに HTTPS でプロキシーするための [Ingress rules](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/install-and-setup/tunnel-guide/local/local-management/ingress/) を定義します。

- 今回はサーバー証明書を Let's Encrypt で取ったので [noTLSVerify](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/install-and-setup/tunnel-guide/local/local-management/ingress/#notlsverify) は false でもいいですが、オレオレのときなどは true（あるいは false + [caPool](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/install-and-setup/tunnel-guide/local/local-management/ingress/#capool) でルートのパス指定）で乗り切ります。
- service を localhost で指定しているので、Nginx へリクエストする SNI が localhost になります。[originServerName](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/install-and-setup/tunnel-guide/local/local-management/ingress/#originservername) で Nginx につなぐときの SNI を元の名前に再度上書きしています。

```shell:【Cloudflare】cloudflared トンネルにルールを設定
# 作成したトンネルの ID を得る
~/.cf $ TUNID=`curl -s -X GET "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" | jq -r '.result[]|select (.name =="EC2 Origin").id'`

#トンネル ID を指定し設定を注入
~/.cf $ curl -s -X PUT "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNID/configurations" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" \
     -d '{
    "config": {
      "ingress": [
        {
          "hostname": "'$MYHOST'",
          "originRequest": {
            "noTLSVerify": true,
            "originServerName": "'$MYHOST'"
          },
          "service": "https://localhost:443"
        },
        {
            "service": "http_status:404",
            "originRequest": {}
         }
      ]
    }
  }' | jq '.result'

```

以上で Cloudflare 側のトンネル設定は完了です。
次はオリジンサーバーに cloudflared を設定します。

まず cloudflared をインストールします。

```shell:【オリジンサーバー】cloudflared インストール
# リリース確認
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.3 LTS
Release:	22.04
Codename:	jammy

# Ubuntu 22.04 なので、こちらの手順に従ってインストール
https://pkg.cloudflare.com/index.html#ubuntu-jammy
```
インストールできたら、cloudflared の起動設定を行います。

```shell:【オリジンサーバー】cloudflared 起動
# 作成済みのトンネルから Token を取り出し
~$ CFDTOKEN=`curl -s -X GET "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNID/token" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" | jq -r '.result'`

# TOKEN を指定して起動設定
~$ sudo cloudflared service install $CFDTOKEN
2023-09-03T11:06:07Z INF Using Systemd
2023-09-03T11:06:09Z INF Linux service for cloudflared installed successfully

# サービスの確認
~$ sudo systemctl status cloudflared
● cloudflared.service - cloudflared
     Loaded: loaded (/etc/systemd/system/cloudflared.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2023-09-03 11:06:09 UTC; 23s ago
   Main PID: 12732 (cloudflared)
      Tasks: 7 (limit: 1121)
     Memory: 17.0M
        CPU: 131ms
     CGroup: /system.slice/cloudflared.service
             └─12732 /usr/bin/cloudflared --no-autoupdate tunnel run --token eyJhIj
     :
```

設定を反映したトンネルが立ち上がりました。

あとはルーティング（DNS）を変更するだけです。
DNS の設定はオリジンサーバーの IP アドレスを A レコードで指定したままなので、それを CNAME レコードに変更し、ターゲットを cloudflared トンネルの名前にします。

cloudflared の名前は [\<UUID>.cfargotunnel.com](https://developers.cloudflare.com/cloudflare-one/faq/cloudflare-tunnels-faq/#what-records-are-created-for-routing-to-a-named-tunnels-hostname) という形式になります（UUID = トンネル ID）。

[ダッシュボード](https://developers.cloudflare.com/cloudflare-one/tutorials/many-cfd-one-tunnel/#associate-your-tunnel-with-a-dns-record)でのDNS のレコード変更と同じことを API で行います。

```shell:DNS レコードの変更
# 既存 DNS レコードの確認
~/.cf $ curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" | jq '.result[]|select (.name=="'$MYHOST'")'

## 応答抜粋
  "id": "92*",
  "name": "$MYHOST",
  "type": "A",
  "content": "<オリジンサーバー PUBLIC IP アドレス>",
  "proxied": true,

# DNS レコードの ID を得る
~/.cf $ DNSRRID=`curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" | jq -r '.result[]|select (.name=="'$MYHOST'")|.id'`

# ID に対して変更を加える（CNAME でトンネル名を指す）
~/.cf $  curl -s -X PATCH "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$DNSRRID" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" \
  -d '{
  "content": "'$TUNID'.cfargotunnel.com",
  "name": "'$MYHOST'",
  "proxied": true,
  "type": "CNAME"
}' | jq '.'

## 応答抜粋
    "name": "$MYHOST",
    "type": "CNAME",
    "proxied": true,
```
書き換わったようなので、接続をしてみますが、失敗します。クライアント証明書が送られてこなかった、と言われます。

```shell:【Eyeball】接続確認
# 接続
~ $ curl https://$MYHOST/
<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>nginx/1.18.0 (Ubuntu)</center>
</body>
</html>

# オリジンサーバーのアクセスログ（クライアント証明書が来ていない）
127.0.0.1 - - - - [03/Sep/2023:11:56:54 +0000] "GET / HTTP/1.1" 400 246 "-" "curl/8.2.1" "-"
```
どうやら、**cloudflared をオリジンサーバーの mTLS に対応させるオプションはなさげ**です。
オリジンサーバーで mTLS を無効にして、再度チャレンジします。

```shell:【オリジンサーバー】Nginx で mTLS 無効化
# オリジンサーバー Nginx で ssl_verify_client をコメントアウト
#ssl_verify_client on;

# 再接続
~ $ curl https://$MYHOST/
Hello World
```
無事に接続することができました。


#### オリジンサーバー側ファイアウォールで Port 443 を閉塞
AWS の Ingress Policy で Port 443 宛の通信を止めてみます。

```shell:【AWS】Security Group の Port 443 を閉塞
# Ingress Permission から Cloudflare IP TCP 443 を削除
~/.aws $ aws ec2 revoke-security-group-ingress --group-id $EC2SGID --ip-permissions PrefixListIds="[{PrefixListId=$PLISTID},{PrefixListId=$P6LISTID}]",IpProtocol=tcp,FromPort=443,ToPort=443

# 再接続
~ $ curl https://$MYHOST/
Hello World
```
オリジンサーバー側でパブリックに Port 443 を開けなくても、接続ができました。

#### 他の Cloudflare アカウントのゾーンから到達の可能性
他のアカウントのトンネルの利用はできないので、オリジンサーバーを使おうとする設定自体ができません。

#### 補足：cloudflared トンネルのデバッグ（ダッシュボード・API からの作成時）
cloudflared の[デバッグログ](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/install-and-setup/tunnel-guide/local/local-management/arguments/#logfile)は設定ファイルのオプションで[フラグを立てます](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/monitor-tunnels/logs/)。
cloudflared の systemd 設定ファイルに[一時的に設定追加](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/install-and-setup/tunnel-guide/remote/remote-management/#linux)してみます。 

```shell:【オリジンサーバー】cloudflared デバッグログ追加
# 起動コマンドに --loglevel, --logfile 追加
~$ sudo vi /etc/systemd/system/cloudflared.service
#ExecStart=/usr/bin/cloudflared --no-autoupdate tunnel run --token e*
ExecStart=/usr/bin/cloudflared --loglevel debug --logfile /var/log/cloudflared.log --no-autoupdate tunnel run --token e*

# 再読み込みと再起動
~$ sudo systemctl daemon-reload
~$ sudo systemctl restart cloudflared

# ログファイルを見ると、debug レベル以上のログが採取されています
~$ sudo tail -f /var/log/cloudflared.log

{"level":"info","version":20,"config":"{\"ingress\"...}
{"level":"debug","current_version":20,"...}
```
### 中締め

オリジンサーバーへの接続を

・Cloudflare からのみ
・Cloudflare の自分のアカウントからのみ

に制限する方法を試しました。

ここから HTTP プロトコルでの制限に移ります。
一旦初期状態に戻し、Cloudflare Proxy とその他の直接接続もできる状態に戻します。

```shell:【テスト環境全体】初期化
#【Cloudflare】 Cloudflare DNS をオリジンサーバーの A レコードに戻す
~/.cf $  curl -s -X PATCH "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$DNSRRID" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" \
  -d '{
  "content": "'$PUBIP'",
  "name": "'$MYHOST'",
  "proxied": true,
  "type": "A"
}' | jq '.'

## 応答抜粋
    "name": "$MYHOST",
    "type": "A",
    "content": "<オリジンサーバー PUBLIC IP アドレス>",
    "proxied": true,

#【オリジンサーバー】 cloudflared サービスの停止
~$ sudo systemctl stop cloudflared.service

#【オリジンサーバー】 Nginx mTLS 無効化
#ssl_verify_client on;

#【AWS】 Security Group TCP 443 全許可
~/.aws $ aws ec2 authorize-security-group-ingress --group-id $EC2SGID --ip-permissions IpRanges="[{CidrIp=0.0.0.0/0}]",IpProtocol=tcp,FromPort=443,ToPort=443

## 応答抜粋
            "IpProtocol": "tcp",
            "FromPort": 443,
            "ToPort": 443,
            "CidrIpv4": "0.0.0.0/0"

#【Eyeball】 接続（Cloudflare Proxy 経由と直接）
~/.cf $ curl https://$MYHOST/
Hello World
~/.cf $ curl https://$MYHOST/ --resolve $MYHOST:443:$PUBIP
Hello World
```

### HTTP Basic 認証
オリジンサーバー側で HTTP [Basic 認証](https://developer.mozilla.org/ja/docs/Web/HTTP/Authentication#basic_%E8%AA%8D%E8%A8%BC%E6%96%B9%E5%BC%8F)を必須とします。
認証キーを持たないリクエストは拒否されます。

<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/578f3705-0bbd-b880-1394-7e04ccd658d4.png">

まずはオリジンサーバーで Basic 認証を有効にしておきます。
認証情報を伝えないので、接続が失敗します。

```shell:【オリジンサーバー】Basic 認証
# オリジンサーバー Nginx の設定
        auth_basic	"auth area";
		auth_basic_user_file /etc/nginx/passwd/.htpasswd;

# Cloudflare 経由（認証エラー）
~/.cf $ curl https://$MYHOST/p
<html>
<head><title>401 Authorization Required</title></head>
<body>
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.18.0 (Ubuntu)</center>
</body>
</html>

# 直接接続（認証エラー）
~/.cf $ curl https://$MYHOST/p --resolve $MYHOST:443:$PUBIP
<html>
<head><title>401 Authorization Required</title></head>
<body>
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.18.0 (Ubuntu)</center>
</body>
</html>
```

次に、Basic 認証に対応するよう Cloudflare の設定を追加します。

具体的には [Transform Rules](https://developers.cloudflare.com/rules/transform/) の [Request header modification rule](https://developers.cloudflare.com/rules/transform/request-header-modification/) を使い、
オリジンサーバーにリクエストを送信する際に、Basic 認証のヘッダを[追加](https://developers.cloudflare.com/rules/transform/request-header-modification/create-api/)します。

```shell:【Cloudflare】Transform Rules（header modification）設定
# header modification ルールセットの ID を得る
~/.cf $ RSNAME="header modification"
~/.cf $ RSID=`curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/rulesets" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json"  | jq -r '.result[]|select(.name=="'$RSNAME'")|.id'`

# ルールセット ID に、Basic 認証用のヘッダを追加するルールを追加
~/.cf $ curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/rulesets/$RSID/rules" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json"  \
     -d '{
         "action": "rewrite",
         "expression": "(http.request.full_uri eq \"https://'$MYHOST'/p\")",
         "description": "basic auth",
         "enabled": true,
         "action_parameters": {
           "headers": {
             "Authorization": {
               "operation": "set",
               "value": "Basic dXNlcjE6dXNlcjE="
              }
            }
          }
         }'
```

再度接続してみます。

```shell:【Eyeball】接続確認
# Cloudflare 経由（認証 OK）
~ $ curl https://$MYHOST/p
Hello Authenticated Users

# Nginx ログ（Basic 認証のユーザー名 user1 が取れて、200 で応答）
172.70.223.94 - - - user1 [04/Sep/2023:08:05:59 +0000] "GET /p HTTP/1.1" 200 57 "-" "curl/8.2.1" "-"

# 直接接続（認証エラー）
~ $ curl https://$MYHOST/p --resolve $MYHOST:443:$PUBIP
<html>
<head><title>401 Authorization Required</title></head>
<body>
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.18.0 (Ubuntu)</center>
</body>
</html>

# Nginx ログ（認証ユーザー名が取れておらず、401 で応答）
104.28.157.52 - - - - [04/Sep/2023:08:07:52 +0000] "GET /p HTTP/1.1" 401 188 "-" "curl/8.2.1" "-"
```

Cloudflare Proxy で HTTP リクエストやレスポンスの改変をする場合、以前は [Cloudflare Workers](https://workers.cloudflare.com/) を利用するケースが多くありましたが、現在はいろいろな [Rules](https://developers.cloudflare.com/rules/) でカバーできるよう、実装が増えています。

#### 補足：Eyeball と Cloudflare 間の認証
この状態では Eyeball と Cloudflare の間には認証を入れていません。
何かしら認証したい場合、たとえばこちらの [Workers を使ったヘッダー認証](https://developers.cloudflare.com/workers/examples/auth-with-headers)と組み合わせると、Eyeball 側でも認証をつけることができます。

```shell:【参考】Workers でのヘッダー認証（Eyeball側）と Basic 認証（オリジンサーバー側）の組み合わせ
# 【Cloudflare】下記の Workers スクリプトを当該の URL にルーティングする
https://developers.cloudflare.com/workers/examples/auth-with-headers

# 【Eyeball】Workers 指定のヘッダーなしでの接続
~ $ curl https://$MYHOST/p
Sorry, you have supplied an invalid key.%

# 【Eyeball】Workers 指定のヘッダーを追加して接続
~ $ curl https://$MYHOST/p  -H "X-Custom-PSK:mypresharedkey"
Hello Authenticated Users

# 【Cloudflare】Workers ログ抜粋

      "url": "https://$MYHOST/p",
      "method": "GET",
      "headers": {
        "authorization": "REDACTED",
        "x-custom-psk": "mypresharedkey",
        :

# Nginx アクセスログ（オリジンサーバーが受け取るのは Basic 認証 user1）
172.70.222.145 - - - user1 [04/Sep/2023:09:28:43 +0000] "GET /p HTTP/1.1" 200 57 "-" "curl/8.2.1" "-"
```

Workers と Transform Rules（request header modification）の処理順を確認します。

- Workers がリクエストを受けたときには、既に  Authorization ヘッダーは付与されているので、request header modification rule でヘッダーを挿入したあとに Workers にルーティングされたことがわかります。
- これは、[シーケンシャル UI](https://blog.cloudflare.com/traffic-sequence-which-product-runs-first/) で確認できる通りです。
（トラフィックシーケンスが表示されない場合はズームアウトしたり、ブラウザの横幅を広げて見てください。右側にヒョッコリ出てくると思います。）
<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/7f6523a1-db6d-bced-da7a-4b23da7dba57.png">



この順番があるので、[Eyeball と Workers で Basic 認証](https://developers.cloudflare.com/workers/examples/basic-auth/)をする場合は、オリジンサーバーとの Basic 認証追加も Transform Rules でなく Workers で一緒にやったほうがシンプルかもしれません。

また、こういうちょっとした処理については、今後 [Cloudflare Snippets](https://blog.cloudflare.com/ja-jp/cloudflare-snippets-alpha-ja-jp/) も使えそうです。

> リソースの点において、Cloudflare SnippetsはWorkersよりも軽量です。最大実行時間は5msで最大メモリは2MB、パッケージの合計サイズは32KBとなっています。こうした制限はありますが、HTTPヘッダーの変更、URLの書き換え、Cloudflare Workersが提供する追加機能やリソースを必要としないトラフィックタスクのルーティングなど、一般的なユースケースでは困ることがないでしょう。

### JSON Web Tokens

これは Eyeball と Cloudflare 間でも認証認可をおここない、その情報をオリジンサーバー側に知らせることで、オリジンサーバーへの接続を Cloudflare で認可されたものだけに限定します。

認証認可を [Cloudflare Access](https://www.cloudflare.com/ja-jp/zero-trust/products/access/) で実施、その結果 HTTP リクエストに付与される [Access Application Token](https://developers.cloudflare.com/cloudflare-one/identity/authorization-cookie/application-token/)（JWT）をオリジンサーバーで[署名検証](https://developers.cloudflare.com/cloudflare-one/identity/authorization-cookie/validating-json/)、正当なリクエストのみ受け付ける、という連携が可能になります。

<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/1d4cd214-5d9f-541b-e814-b7c622ab8e54.png">

:::note info
なので、ここでは Eyeball と Cloudflare の認証の話も入ってきます。
:::

今回は本家にある [Python の例](https://developers.cloudflare.com/cloudflare-one/identity/authorization-cookie/validating-json/#python-example)を流用し、サーバーに適用します。
単純にリクエストすると、下記のようなメッセージを表示します。

```shell:【Eyeball】接続確認
~ $ curl https://$MYHOST/aa
missing required cf authorization token%
```
#### Eyeball をユーザー ID （IdP 連携や Email ワンタイム PIN）で認証
Access でアプリケーションのユーザー認証をする場合、[Email ワンタイム PIN](https://developers.cloudflare.com/cloudflare-one/identity/one-time-pin/) はデフォルトで利用ができます。[IdP との認証連携](https://developers.cloudflare.com/cloudflare-one/identity/idp-integration/)が必要であれば、事前に構築しておきます。（ここでは [Onelogin](https://developers.cloudflare.com/cloudflare-one/identity/idp-integration/onelogin-oidc/) との接続を構築済）

次に Access アプリケーションを[作り](https://developers.cloudflare.com/api/operations/zone-level-access-applications-add-a-bookmark-application#Request)ます。

```shell:【Cloudflare】Access アプリケーションの作成
# Access を利用するドメイン（パス）を定義
~/.cf $ ADOMAIN="$MYHOST/aa"

# Access アプリケーションの作成
~/.cf $ curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/access/apps" \
-H "Authorization: Bearer $ATOKEN" \
-H "Content-Type:application/json"  \
-d '{
    "type": "self_hosted",
    "domain": "'$ADOMAIN'"
   }'

```


作成したアプリケーションに Access のポリシーを[当て](https://developers.cloudflare.com/api/operations/zone-level-access-policies-create-an-access-policy)ます。

```shell:【Cloudflare】Access アプリケーションに接続ポリシーを適用
# Access アプリケーションの ID を得る
~/.cf $ PUID=`curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/access/apps" \
-H "Authorization: Bearer $ATOKEN" \
-H "Content-Type:application/json" | jq -r '.result[]|select(.domain=="'$ADOMAIN'")|.id'`

# Access アプリケーションに対して、ポリシーを適用
~/.cf $ curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/access/apps/$PUID/policies" \
-H "Authorization: Bearer $ATOKEN" \
-H "Content-Type:application/json"  \
-d '{
    "decision": "allow",
    "include": [
      {
        "email_domain": {
          "domain": "cloudflare.com"
        }
      }
    ],
    "name": "cf"
   }'
```
準備は完了です。接続してみます。
（今回 OpenID Connect での認証が走るので、ブラウザーで試します）

- Access のログイン画面が表示されますので、認証のアウトソース先を選択します
<img width="500" alt="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/7a427654-6683-02c9-0892-c1ab3c54a6c9.png">

- 選択した認証方式（今回 [Onelogin](https://developers.cloudflare.com/cloudflare-one/identity/idp-integration/onelogin-oidc/)）にリダイレクトされるので、認証を無事に済ませます。
- 認証が終わったら Access で認可が行われ、問題がなければオリジンサーバーにリクエストが転送されます。
- リクエストヘッダーには Applicatin Token（JWT）が含まれます。
- オリジンサーバーの検証アプリケーションは正当な JWT に含まれるユーザー名（email）を表示します。

<img width="500" alt="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/b049a976-80a1-f0b1-2ee5-a20182a3aad0.png">

#### Service Token による認証
次に、モノからのアクセスを想定して [Service Token](https://developers.cloudflare.com/cloudflare-one/identity/service-tokens/) も試してみます。

Access で作成した Token を Eyeball に事前に渡しておくことで、HTTP ヘッダーによる Access アプリケーションの認証認可を実現します。

まず、 Service Token を[作り](https://developers.cloudflare.com/api/operations/zone-level-access-service-tokens-create-a-service-token)ます。
`client_id` と `client_secret` はこれっきりの表示になるので、メモしておきます。

```shell:【Cloudflare】Access Service Token の作成
# Service Token の作成（有効期間 duration を 3 年に指定）
~/.cf $ curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/access/service_tokens" \
-H "Authorization: Bearer $ATOKEN" \
-H "Content-Type:application/json"  \
-d '{
"duration": "26280h",
"name": "AWS EC2 WEB"
}'
 
## 応答抜粋（client_id と client_secret はこれ以降表示できない）
    "client_id": "3*.access",
    "client_secret": "9*",
    "created_at": "2023-09-04T16:12:39Z",
    "expires_at": "2026-09-03T16:12:39Z",
    "id": "b*",
    "name": "AWS EC2 WEB",
    "duration": "26280h"
```
作成した Service Token で Policy を作り Access アプリケーションに追加します。

```shell:【Cloudflare】Service Token を使った Policy を Access アプリケーションに追加
# Sevice Token の TOKEN ID を得る
~/.cf $ TOKENID=`curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/access/service_tokens" \
-H "Authorization: Bearer $ATOKEN" \
-H "Content-Type:application/json"  | jq -r '.result[]|select(.name=="AWS EC2 WEB")|.id'`

# Policy の追加
~/.cf $ curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/access/apps/$PUID/policies" \
-H "Authorization: Bearer $ATOKEN" \
-H "Content-Type:application/json"  \
-d '{
    "decision": "non_identity",
    "include": [
        {
          "service_token": {
            "token_id": "'$TOKENID'"
          }
        }
      ],
    "name": "st"
   }' | jq '.'

## 応答抜粋
    "decision": "non_identity",
    "id": "0*",
    "include": [
      {
        "service_token": {
          "token_id": "b*"
        }
      }
    ],
    "name": "st",
    "precedence": 2
``` 

接続を確認します。

client_id と client_secret をそれぞれ指定のヘッダ（`CF-Access-Client-Id`、`CF-Access-Client-Secret`）に入れることで、検証アプリケーションに接続することができます。

```shell:【Eyeball】接続確認
# Service Token の場合、JWT にユーザー情報（email）は 含まれないので、サーバーは代わりに common_name を表示している

~/.cf $ curl https://$MYHOST/aa -H "CF-Access-Client-Id: $STID" -H "CF-Access-Client-Secret: $STSC"
Hello, 3*.access%
```
#### cloudflared との併用時

cloudflared と併用する場合は、[cloudflared で検証](https://developers.cloudflare.com/cloudflare-one/applications/configure-apps/self-hosted-apps/#5-validate-the-access-token)させることもできます。Cloudflare からオリジンサーバーへは `CF_Authorization` Cookie と同様の JWT が `cf-access-jwt-assertion` ヘッダーにも格納されます。cloudflared はそれを[検証](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/install-and-setup/tunnel-guide/local/local-management/ingress/#access)します。
アプリケーションでの検証をオフロードすることができます。

```shell:【オリジンサーバー】cloudflared で JWT検証
# Tame name を得る
~/.cf $ MYTEAM=`curl -s -X GET "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/organizations" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" | jq -r '.result.auth_domain' | sed -e 's/.cloudflareaccess.com//'`

# Access アプリケーションの AUD を得る
$ AUD=`curl -s -X GET "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/access/apps" \
-H "Authorization: Bearer $ATOKEN" \
-H "Content-Type:application/json" | jq -r '.result[]|select(.domain=="'$ADOMAIN'").aud'`

# Accessアプリケーションのパス（aa）を追加、検証を有効（"access"）にし、
# cloudflared トンネルに当てる設定を上書きする
~/.cf $ curl -s -X PUT "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNID/configurations" \
     -H "Authorization: Bearer $ATOKEN" \
     -H "Content-Type:application/json" \
     -d '{
          "config": {
           "ingress": [
            {
             "service": "https://localhost:443",
             "hostname": "'$MYHOST'",
             "path": "aa",
             "originRequest": {
              "access": {
               "audTag": [
                "'$AUD'"
               ],
              "required": true,
              "teamName": "'$MYTEAM'"
              },
              "noTLSVerify": true,
              "originServerName": "'$MYHOST'"
             }
            },
            {
             "service": "https://localhost:443",
             "hostname": "'$MYHOST'",
             "originRequest": {
              "noTLSVerify": true,
              "originServerName": "'$MYHOST'"
              }
            },
            {
             "service": "http_status:404",
             "originRequest": {}
            }
           ]
          }
         }' | jq '.result'
```

リクエストの検証に失敗した場合は、下記のようなエラーログが cloudflared の `--logfile` に出力されます。

```shell:【オリジンサーバー】cloudflared のエラーログ
# 不正な JWT を利用した場合のエラーログ
{"level":"error","error":"request filtered by middleware handler (AccessJWTValidator) due to: Invalid token in jwt: [d*]","cfRay":"8*-NRT","event":1,"ingressRule":"0","originService":"https://localhost:443","time":"2023-09-12T06:46:46Z"}
```


#### 補足：Access Token の違い（ユーザー ID と Service Token）
ユーザー ID ベースの認証と Service Token では Access Token に違いがあったので、メモしておきます。
```shell:【Eyeball】set-cookie に入っている CF_Authorization のデコード
# ユーザ ID による認証
{
  "alg": "RS256",
  "kid": "a*"
}
{
  "aud": [
    "d*"
  ],
  "email": "*",
  "exp": 1694055752,
  "iat": 1693969352,
  "nbf": 1693969352,
  "iss": "https://*",
  "type": "app",
  "identity_nonce": "4*",
  "sub": "a*",
  "country": "JP"
}

# Service Token による認証
{
  "kid": "a0*",
  "alg": "RS256",
  "typ": "JWT"
}
{
  "type": "app",
  "aud": "d5*",
  "exp": 1693977228,
  "iss": "https://*",
  "common_name": "3*.access",
  "iat": 1693890828,
  "sub": ""
}
```

なお、ユーザ ID の場合、リクエストヘッダーの Cookie CF_Authorization 使って、そのユーザーの[認証関連の全部の情報](https://developers.cloudflare.com/cloudflare-one/identity/authorization-cookie/application-token/#user-identity)を得ることができます。

<img width="500" alt="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/6f1fca08-b87a-6ce2-11c2-5eb372c6168d.png">

JWT にはヘッダー容量削減のためユーザー情報の一部しか含まれていませんので、トラブルシュートや他のメタ情報の利用など、必要に応じて別の URL に JWT を渡して確認します。

```shell:【Eyeball】認証済みユーザーのすべての情報を確認
~/bin $ curl -s -H "cookie: CF_Authorization=$CFTKN" https://$MYTEAM.cloudflareaccess.com/cdn-cgi/access/get-identity | jq '.'

## 応答抜粋
{
  "id": "1*",
  "name": "Foo Bar",
  "email": "foobar@cloudflare.com",
  "oidc_fields": {
    "preferred_username": "foobar",
    "given_name": "Foo",
    "family_name": "Bar"
   :

```

#### 補足：運用面

JWT 署名検証用の[公開鍵はローテーション](https://developers.cloudflare.com/cloudflare-one/identity/authorization-cookie/validating-json/#access-signing-keys)があるので、検証スクリプトでは更新に追随できるよう注意します。


## 通知
認証のあたりは、利用する情報がフレッシュか、有効か、が重要になってきまます。

今回の対象範囲では Access Sevice Token 期限や持ち込みクライアント証明書について [Notification](https://developers.cloudflare.com/notifications/)  機能を用いて Cloudflare から有効期限の近いことを通知することができます。（通知方法や通知対象の機能は[プランにより異なり](https://developers.cloudflare.com/notifications/notification-available/)ますので、確認が必要です。）
<img width="500" alt="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/32255cd0-27ef-3a19-de31-fe79aaeee9a3.png">

- Access Service Token の追加
<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/83661b2c-828d-075c-4e8e-7f2f7a181059.png">

```shell:【Cloudflare】アラート通知設定
# Access Service Token 期限切れの通知
~/.cf $ curl -s -X GET "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/alerting/v3/policies" \
-H "Authorization: Bearer $ATOKEN" \
-H "Content-Type:application/json"  | jq '.result[]|select(.alert_type=="expiring_service_token_alert")'

## 応答抜粋
{
  "id": "4*",
  "name": "Expiring Access Service Token Alert",
  "description": "",
  "enabled": true,
  "alert_type": "expiring_service_token_alert",
```
- Authentivated Origin Pulls
Authenticated Origin Pulls は設定するとデフォルトで通知が有効になっています（宛先は権限のあるメンバーのメールアドレスが含まれますが、Webhook の追加など調整が必要な場合は別途実施してください）

<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/fe36e7d0-a3f2-d0a8-6fde-4e6001281438.png">
<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/4933a568-bd71-bbb8-cfa0-b0ffe9f19485.png">

```shell:【Cloudflare】アラート通知設定
# Authenticated Origin Pulls  期限切れの通知
~/.cf $ curl -s -X GET "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/alerting/v3/policies" \
-H "Authorization: Bearer $ATOKEN" \
-H "Content-Type:application/json"  | jq '.result[]|select(.name=="Default notification")'

## 応答抜粋
  "id": "0*",
  "name": "Default notification",
  "description": "This notification is automatically set by Cloudflare",
  "enabled": true,
  "alert_type": "hostname_aop_custom_certificate_expiration_type",

  "id": "f*",
  "name": "Default notification",
  "description": "This notification is automatically set by Cloudflare",
  "enabled": true,
  "alert_type": "zone_aop_custom_certificate_expiration_type",
```

- cloudflaredトンネル の通知

<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/49206cde-0679-809d-4fea-5f3b0184a92d.png">

```shell:tunnel
【Cloudflare】アラート通知設定
# トンネル健全性の通知
~/.cf $ curl -s -X GET "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/alerting/v3/policies" \
-H "Authorization: Bearer $ATOKEN" \
-H "Content-Type:application/json"  | jq '.result[]|select(.alert_type=="tunnel_health_event")'
{
  "id": "e*",
  "name": "トンネル状況",
  "description": "",
  "enabled": true,
  "alert_type": "tunnel_health_event",
```

## その先へ

今回触れなかったものの概要です。
Enterprise プランのみですが、オリジンサーバーをより強固に守る手段が用意されています。

- [Cloudflare Aegis](https://blog.cloudflare.com/cloudflare-aegis/)
Cloudflare からオリジンサーバーへ接続する IP をユーザ専有のものにします。
<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/df08cbb6-9175-8f07-3627-c985007a76cc.png">

- [Cloudflare CNI](https://www.cloudflare.com/ja-jp/network-services/products/network-interconnect/)
Cloudflare とオリジンサーバー（のネットワーク）を直接接続します。
<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/6d658849-a736-d3f0-505a-9368d324a7ff.png">

- Access、Aegis、CNI といった[あわせ技も可能](https://blog.cloudflare.com/access-aegis-cni/)です。
<img width="700" alt="700" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2218045/a8bddf5e-f6b3-71b6-f2fb-2fcf8b3f82f9.png">


その他、

- オリジンサーバーを[ヘルスモニターする機能](https://developers.cloudflare.com/fundamentals/basic-tasks/protect-your-origin-server/#monitor-origin-health)
-  Eyeball と Cloudflare 間の認証系機能
    - mTLS
        - [Access](https://developers.cloudflare.com/cloudflare-one/identity/devices/access-integrations/mutual-tls-authentication/) 利用
        - WAF [Custom Rules](https://developers.cloudflare.com/api-shield/security/mtls/configure/) 利用
    - 署名付き URL など

あたりは別の機会にします。

## まとめ
以上、オリジンサーバーを Cloudflare Proxy 以外からの接続から保護する方法について、[本家ドキュメント](https://developers.cloudflare.com/fundamentals/basic-tasks/protect-your-origin-server/#secure-origin-connections)に記載の複数の異なるレイヤー、方法で試しました。ご参考になればと思います。