プロバイダーのサブスクリプションから生成された設定ファイルを開いたことがあれば、数百行にも及ぶ rules リストを見たことがあるはずです。これらのルールの多くは、プロバイダー自身が書いたものではなく、コミュニティが維持している公開ルールセット(有名なものにACL4SSRやblackmatrix7シリーズがあります)を参照しています。ルールセット自体はリモートでホストされており、設定ファイルには「どのルールセットを参照するか」だけが記述されています。
Rule Providerは何を解決するのか
Rule Providerがなければ、特定のアプリやサイトの振り分けを細かく制御するには、DOMAIN-SUFFIX / DOMAIN-KEYWORD を1件ずつ手書きするしかなく、ドメインの変化や新サービスへの対応のため、ルールベースを継続的にメンテナンスする必要がありました。Rule Providerはこのメンテナンス作業をルールベースを管理するコミュニティに委ねる仕組みで、利用者は参照するだけでよく、内容はリモートファイル側で自動的に更新されます。
3つの重要なフィールド
| フィールド | 役割 | よくある値 |
|---|---|---|
| type | ルールセットの取得方式 | http(リモートサブスクリプション、自動更新)、file(ローカルファイル) |
| behavior | ルールセットに格納されているデータの種類で、解析方法を決定する | domain(ドメインのみのリスト)、ipcidr(IPレンジのリスト)、classical(完全なルール構文の行) |
| interval | typeがhttpの場合の自動更新チェック間隔(秒) | よくある値は43200(12時間)~86400(24時間) |
完全な設定例
rule-providers: reject: type: http behavior: domain url: https://example.com/reject.txt path: ./ruleset/reject.yaml interval: 86400 direct: type: http behavior: classical url: https://example.com/direct.txt path: ./ruleset/direct.yaml interval: 86400 rules: # ルールセットを参照する書き方は RULE-SET,ルールセット名,ポリシー に固定 - RULE-SET,reject,REJECT - RULE-SET,direct,DIRECT - GEOIP,CN,DIRECT - MATCH,PROXY
path はローカルキャッシュの保存先を指定します。コアが初めてルールセットを取得すると、ローカルに1部保存され、その後は interval の周期で更新をチェックします。一時的にオフラインになってもローカルキャッシュで正常に動作するため、取得に失敗してもルール全体が使えなくなることはありません。
よくある落とし穴
- behaviorと実際の内容が一致していない:ルールセットの内容が実際には完全な構文行(例:DOMAIN-SUFFIX,example.com)であるにもかかわらず、behaviorが domain(ドメインのみを想定)になっていると、解析に失敗したりルールが機能しなくなったりします。ルールセットを参照する前に、ソースファイルの実際の形式を確認しておくのがおすすめです。
- ルールの並び順を間違える:ルールは上から順にマッチングされます。範囲が非常に広いルールセット(ほとんどすべてのサイトにマッチしてしまう大きなリストなど)を先頭に置くと、その後に続くより細かいルールが永久にマッチしなくなる可能性があります。一般的には、ブロック系ルールを最初に、細かい例外ルールを次に、範囲の広いフォールバック用ルールを最後に置くのがよいでしょう。
- intervalを短すぎる値に設定する:ルールセットは頻繁に変わるものではないため、数分おきに更新する必要はありません。むしろ不要なネットワークリクエストが増えるだけです。12~24時間程度が適切な範囲です。
- ローカルファイルのパスが競合する:複数のルールセットの path が同じファイルを指していると、互いに上書きしてしまいます。ルールセット名自体をファイル名に使うなど、命名規則を統一しておくとよいでしょう。
ルールセットは自分で維持すべきか
大多数のユーザーにとっては、コミュニティが維持している公開ルールセットを参照するだけで十分で、車輪の再発明をする必要はありません。社内システムのドメインリストや、自分だけが使う特殊なサイト群など、非常に具体的で個別のニーズがある場合に限り、type: file でローカルルールセットを作成し、公開ルールセットと組み合わせて、それぞれ異なる範囲を担当させる価値があります。
Rule Providerが解決するのは「メンテナンスコスト」の問題であり、「機能」の問題ではありません。通常のルール記法でできることは、ルールセットでもすべて実現できます。単にメンテナンス作業を外部に委託しているだけです。
ルールセットをどう組み合わせるか
実際の運用では、1つの設定内で複数のルールセットを同時に参照し、それぞれ異なるカテゴリを担当させることが多くなります。よくある階層構成は、まずブロック系(広告・トラッキング)を置き、次にプロキシを経由させたいアプリカテゴリ(例えば地域制限のあるストリーミングサービスやソーシャルアプリなど)を置き、続いてローカル/直接接続用の大きなリストを置き、最後に MATCH でフォールバックする、という形です。各層の役割が単一であるほど、問題が起きたときにどの層のルールセットが原因かを特定しやすくなります。
参照しているルールセット同士でルールが重複している場合(例えば、2つのルールセットが同じドメインを含んでいても異なるポリシーを指定している場合)、実際に有効になるのは、先に置かれていて先にマッチした方のルールです。つまりルールセットの参照順序自体が優先度の宣言であり、順序を調整するだけでルールセットの内容を変更するより早く問題が解決することもあります。
ルールセットが機能しているかどうかの確認方法
ルールセットを設定した後、機能しているかどうかを推測に頼る必要はありません。以前の記事で紹介したダッシュボードの「Connections」ビューでは、各接続が実際にどのルール名にマッチしたかが表示されます。「未マッチ」ではなくルールセットの名前が表示されていれば、そのルールセットは正常に機能しています。これはルールのトラブルシューティングにおいて最も直接的で時間のかからない方法で、設定を何度も修正してテストを繰り返すより効率的です。