gatewayInternalNetworksとは — 自社IPのgatewayへのログイン許可
自社のパブリックIPv4ブロックで採番した内部ネットワークにあるClaude apps gatewayへ、Claude Codeの/loginを許可する管理設定を解説します。
gatewayInternalNetworksでできること
gatewayInternalNetworksは、組織がパブリックIPv4ブロックで内部ネットワークを採番しているとき、/loginがそこにあるClaude apps gatewayへの接続を許可するための管理設定です。Claude Code v2.1.268以降が必要で、対象は開発者マシン側のバージョンになります。
この設定を入れなければ、/loginはプライベートアドレス(RFC 1918・リンクローカル・CGNAT・loopback等)のgatewayしか受け付けません。キャリア資産の/8のような、正規に割り当てられたパブリックIPv4を社内ネットワークの採番に使っている組織は、この既定挙動のままではgatewayにサインインできません。gatewayInternalNetworksはその例外を、宣言したブロックに限定して開けます。
設定方法
managed-settings.jsonに、対象のCIDRブロックを配列で指定します。
{
"gatewayInternalNetworks": ["203.0.113.0/24"]
}例の203.0.113.0/24はドキュメント用レンジで、実際には拒否されます。自社が保有するブロックに置き換えてください。
設定後、/loginは次の条件をすべて満たすときだけ、リスト内のgatewayへの接続を許可します。
- gatewayのアドレスが、宣言したブロックのいずれかに含まれる
- 開発者マシン自身の接続元アドレスも、同じブロックに含まれる
- 接続が直接接続であること(公式の表現は
direct connection only)
スコープと読み込み元
gatewayInternalNetworksのスコープはManagedです。読み込まれるのは、マシン上にあるmanaged-settings.json(およびmanaged-settings.d/のドロップインファイル)、macOSのplistまたはWindowsのHKLMレジストリ、ポリシーヘルパーの4経路に限られます。HKCU(ユーザー単位のレジストリ)とserver-managed settings(claude.aiの管理コンソールやセルフホストgatewayが配信する設定)からは読み込まれず、開発者自身のsettings.jsonに書いても無視されます。
managed settingsのドキュメントでは、この4分類のうちforceLoginGatewayUrl・gatewayInternalNetworks・forceLoginMethodの"gateway"値を「Gateway login keys」としてひとまとめに分類し、対応する配布経路が限られることを示しています。ログインの経路を決める鍵は、開発者が触れないファイルに置く設計です。
managed-settings.jsonを置く場所はOSごとに決まっています。macOSは/Library/Application Support/ClaudeCode/managed-settings.json、LinuxとWSLは/etc/claude-code/managed-settings.json、WindowsはC:\Program Files\ClaudeCode\managed-settings.jsonです。配置後は1台のマシンで/statusコマンドを実行し、Setting sourcesの行にEnterprise managed settings (file)のようにファイル経由で読み込まれた設定が表示されることを確認してから、残りのマシンへ展開してください。
値のバリデーションルール
配列で指定できるCIDRブロックは最大4つ、プレフィックス長は/8から/32です。/loginは接続前に次のルールでチェックします。
| チェック項目 | 内容 |
|---|---|
| ブロック数 | 内容最大4つ、重複不可 |
| プライベート空間との重複 | 内容10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 127.0.0.0/8 169.254.0.0/16 100.64.0.0/10と重複してはならない(これらは本設定なしでも許可済み) |
| VPN/NAT64のローカルアドレス | 内容198.18.0.0/15 192.0.0.0/24は不可 |
| ドキュメントレンジ | 内容192.0.2.0/24 198.51.100.0/24 203.0.113.0/24は不可 |
| 予約領域 | 内容0.0.0.0/8 192.88.99.0/24、マルチキャストの224.0.0.0/4は不可 |
240.0.0.0/4のような、一部の大規模ネットワークが内部ユニキャスト用途に使うレンジは宣言できます。managed-settings.json本体とドロップインファイルのブロックは1つのリストに結合され、この上限とルールは結合後のリストに適用されます(ドロップインで重複するブロックを追加したときの挙動は「つまずきやすい点」を参照してください)。
値が不正な場合(ルール違反、または文字列の配列でない値)は、そのマシン上で新規のgateway sign-inがすべて拒否され、/loginが問題箇所を名指しするメッセージを出します。プライベートアドレスのgatewayへの新規サインインも同時に失敗します。すでに完了しているサインインは維持されます。展開前に1台のマシンで値を検証しておくと安全です。
gatewayInternalNetworksは、不正な値を無視して落とすのではなく、より厳しい既定へ寄せて動かし続ける「fail-closed」型のキーの一つです。ただしこの寄せ方が働くのは、マシン上で最も優先度の高い管理ソースが不正な値を持っているときに限られます。優先度の低いソースの値が不正でも、上位のソースが正しい値を供給していれば/loginは通常どおり動作します。不正な値を持つこのキーは、Claude Codeが報告する「fail-closedとなる管理設定」の一覧にも記録されます。
接続時に行われる追加チェック
設定した値がバリデーションを通過しても、宣言したブロックに含まれるアドレスを持つgatewayに接続しようとするとき、/loginは接続の直前にもう一段のチェックを行います。
- gatewayのホスト名が解決するすべてのアドレスが、その1つのブロックの内側にあること。ブロック外のアドレス(プライベートアドレスやIPv6アドレスを含む)も持つホスト名は拒否されます
- 開発者マシンが同じブロックの内側から接続していること。NATの内側・コンテナやWSL2の中・アドレスプールがブロック外のVPN経由での接続は拒否され、実際に接続してきたアドレスがメッセージに示されます
- 接続が直接接続であること。
HTTPS_PROXYがgatewayのホストに適用されている場合は拒否され、追加すべきNO_PROXYのエントリがメッセージに示されます
3つとも通過すると、トラスト確認画面に開発者マシンのアドレス・gatewayのアドレス・該当するブロックの3点が表示されます。このチェックが働くのは宣言したブロック内のgatewayに接続するときだけです。プライベートアドレスのgatewayへの接続や、宣言したブロックの外にあるパブリックアドレスのgatewayへの接続の扱いは、このキーを設定しても変わりません。
これらのチェックが絞るのは「誰がサインインできるか」であって、「マシンが本当にどこにあるか」の証明ではありません。クラウド事業者の公開レンジのように複数のテナントで共有されているブロックを宣言すると、同じブロックにいる無関係な第三者も同じチェックを通過してしまいます。宣言するブロックは、自社が単独で管理しているアドレス空間に限定してください。
3つの設定の役割の違い
gatewayInternalNetworks・forceLoginGatewayUrl・access_control.allow_cidrsは、gatewayのログイン周りでまとめて語られがちですが、担う役割は別々です。混同すると、片方だけ設定して安全になったと誤解しがちなので、役割を分けて確認します。
| 設定 | 主体 | 決めること | 設定場所 |
|---|---|---|---|
gatewayInternalNetworks | 主体開発者マシン | 決めること/loginがどのアドレス帯のgatewayへ接続してよいか | 設定場所managed-settings.json / MDM / HKLMレジストリ |
forceLoginGatewayUrl | 主体開発者マシン | 決めること/loginをgateway専用にし、接続先URLを固定するか | 設定場所managed-settings.json / MDM / HKLMレジストリ |
access_control.allow_cidrs | 主体gateway | 決めることどのクライアントアドレス帯からのリクエストを受け付けるか | 設定場所gatewayの設定ファイル |
公式ドキュメントは、gatewayInternalNetworksに宣言したブロックを、そのままgateway側のaccess_control.allow_cidrsにも設定するよう案内しています。gatewayInternalNetworksは、gatewayをインターネットに公開しても安全にする設定ではありません。信頼されたgatewayは開発者マシン上でコマンドを実行する設定を配布できるためです。ファイアウォールやロードバランサでgateway自体を外部から到達不能にしたうえで、両方の設定を揃える構成が前提になります。ロードバランサやIngressの配下にgatewayを置く場合は、gateway側のlisten.trusted_proxiesもそのフロントエンドに設定してください。設定しないと、allow_cidrsはフロントエンド自身のアドレスと照合されてしまい、開発者マシンの実アドレスでは判定されません。
gatewayInternalNetworksを設定しても、gateway側のaccess_control.allow_cidrsが空のままなら、gatewayは宣言していないアドレスからのリクエストも受け付け続けます。逆にaccess_control.allow_cidrsだけを絞っても、パブリックIPv4上のgatewayに対して/login側がそのアドレス帯を許可していなければ、開発者はサインインできません。両方を同じCIDRブロックで揃えて、初めて意図した範囲に閉じます。2つの設定を片方だけ入れたときの気づきやすさには差があります。access_control.allow_cidrsだけを絞ると開発者がサインインできず気づきやすい一方、gatewayInternalNetworksだけを設定してaccess_control.allow_cidrsを空のままにすると、gatewayは想定外のクライアントからの接続を静かに受け入れ続けるため、設定漏れに気づきにくくなります。gateway自体が晒すリスクの範囲はClaude apps gatewayの脅威モデルに、この構成をTerraformで組む場合の勘所はClaude apps gatewayをTerraformで構築するにまとまっています。
forceLoginGatewayUrl・forceLoginMethodとの関係
gatewayInternalNetworksは、gatewayへのログインを強制するforceLoginGatewayUrl・forceLoginMethodの"gateway"値と合わせて使われることが多い設定です。forceLoginGatewayUrlによるgateway強制ログインの構成では、開発者側で手動設定する経路はありません。ログインピッカーにgatewayの選択肢は表示されず、forceLoginGatewayUrlを開発者自身のsettingsファイルに書いても無視されます。
つまずきやすい点
古いバージョンのClaude Codeを使っている開発者マシンは、gatewayInternalNetworksを無視してプライベートアドレスのルールをそのまま適用します。エラーは出ず、単に接続できないだけなので、「設定は入れたのに一部のマシンだけサインインできない」という形で気づくことが多いポイントです。展開前にv2.1.268以降へ更新されているかを確認してください。
ドロップインファイルでブロックを追加するときも注意が必要です。managed-settings.json本体で203.0.113.0/24を宣言済みの状態で、ドロップイン側に203.0.113.0/25のような重複するブロックを追加すると、/loginは結合後のリストが重複していると判断して拒否します。範囲を狭めたいときは、ドロップインに追加するのではなく、本体側のエントリを書き換えます。
まとめ
gatewayInternalNetworksは、キャリア資産の/8のようなパブリックIPv4を内部ネットワークの採番に使っている組織向けの例外設定です。Claude Code v2.1.268以降が前提で、宣言できるのは最大4つのCIDRブロック、直接接続かつ開発者マシン側も同じブロック内にあることが条件になります。読み込み元はmanaged-settings.jsonやMDM・HKLMレジストリポリシーに限られる管理系の設定で、開発者自身の設定やserver-managed settingsからは反映されません。導入するときは、gateway側のaccess_control.allow_cidrsも同じブロックに揃え、ロードバランサ配下に置く場合はlisten.trusted_proxiesにそのフロントエンドを設定したうえで運用を始めてください。