ゲートウェイ サーバをセットアップする

この記事では、スタジオで設定されたインターネット制限ポリシーを順守しながら、ホストされた Shotgun サイトにアクセスする方法について説明します。

適用範囲と前提条件

このドキュメントはシステムと Shotgun の管理者を対象にしています。

読者には、プロキシ、ネットワーキング、HTTP プロトコルに関する基本的な知識が必要です。

免責事項

このドキュメントは、ゲートウェイサーバのセットアップをサポートするためのクライアント向けガイドとして提供しています。 いくつかのヘルプを紹介していますが、ゲートウェイ サーバはクライアントが管理するものであり、Shotgun によって実装されるものではありません。

また、このドキュメントには外部リソースがリンクされているため、参照する場合は自己責任でご使用ください。

ゲートウェイ サーバを使用してクラウドの Shotgun にアクセスする

ゲートウェイ サーバを使用すると、インターネットの他の部分にアクセスせずに、ホストしている Shotgun サイトにアクセスできます。フィルタリングされた要求を Shotgun エンドポイントに転送し、他のすべての要求はブロックします。つまり、*.shotgunstudio.com を要求した場合は通過します。ただし、無許可のサイトを要求すると通過できません。

SGCS_-_Shotgun_Ecosystem___Gateway.png

ゲートウェイ サーバを使用する理由

  • ネットワークをインターネットから分離しても、Shotgun がホストするインスタンスにユーザがアクセスできるようにする必要がある。
  • 廃止予定の接続/暗号化プロトコルを使用して Shotgun に接続する必要がある(この操作はユーザの責任で行ってください)。

Shotgun のプロキシ サーバをセットアップする代わりに、ゲートウェイ サーバを使用することをお勧めします。 ゲートウェイ サーバを使用すると、次のようになります。

  • 時間の経過とともに変化する複雑な IP 範囲のホワイトリスト登録が不要になります。
  • Shotgun でホストされるサイトに含まれるすべての Web アクセラレーション機能を引き続き活用できます。
  • Amazon S3 により、S3 プロキシ ソリューションに比べて優れたパフォーマンスが得られます。
  • すべての再生とアップロードについて、S3 プロキシ ソリューションよりも優れたパフォーマンスが得られます。

スタートアップ

ゲートウェイ サーバを配置するには 3 つの主な手順が必要です。

  1. スプリット ホライズン ドメイン ネーム システム(DNS)を配置する。
  2. HAProxy を使用してゲートウェイ サーバをセットアップする。
  3. 独自のゲートウェイを使用するようにユーザ環境を設定する。

手順 0: 準備

ゲートウェイ サーバを正しく設定するには、次の情報が必要になります。

  • サイト名(<your_site_name>.shotgunstudio.com)
  • パフォーマンスを最適化する地域に基づいた特定のメディア バケットの名前。この情報の取得方法については、次の記事を参照してください。https://support.shotgunsoftware.com/hc/ja/articles/115000022554-Selecting-a-storage-location-for-uploaded-files-overview. この情報についてさらに詳しい説明が必要な場合は、Shotgun サポートまでお問い合わせください
  • ゲートウェイ サーバには 2 つの異なる内部 IP アドレスが割り当てられます。1 つは <your_site_name>.shotgunstudio.com をリッスンし、もう 1 つは S3 url をリッスンします。Toolkit を使用している場合は、3 つ目の IP が必要になることがあります。 IP アドレスの範囲は、スタジオのネットワーク設定方法によって異なります。

手順 1: スプリット ホライズン DNS

スプリット ホライズン DNS は、クエリーのソースに応じて、異なる応答をクエリーに返します(この場合は URL の解決)。スタジオのユーザがスプリット ホライズン DNS を使用して、Shotgun パブリック IP を解決する代わりに、Shotgun URL を内部 IP アドレス(ゲートウェイ サーバ)に解決します。

このゲートウェイ サーバはすべての要求を Shotgun の IP に転送します。ゲートウェイ サーバは要求がインターネットに送信されるようにアクセスを制限しないこともできますが、アーティストに表示されるのは内部サーバであり、アクセスできるのは Shotgun インターネット リソースに限定されます。

このような構成内で DNS を設定するには、いくつかの基本的な IT スキルが必要になります。次に、この設定方法の例をいくつか示します。

DNS サーバがまだ配置されていない場合は、注文するか、または特定のサーバをこのタスク専用にすることができます。この記事の例は、Linux システムの場合です。

手順 2: HAProxy を Shotgun ゲートウェイとして設定する

ゲートウェイ サーバを実装する場合は、HAProxy を使用することをお勧めします。HAProxy とは、ゲートウェイを簡単に実装できるシンプルで信頼性に優れた高性能な TCP/HTTP ロード バランサです。バージョン 1.6 以降を使用することをお勧めします。HAProxy のハードウェア要件については、こちらを参照してください。

付録 2 には HAProxy 設定ファイルのサンプルがあります。

手順 3: ユーザの環境を設定する

自己署名証明書を使用している場合は、次の手順が適用されます。

ネットワーク環境で信頼できる証明書を使用できる場合は(信頼できるプロバイダに問い合わせる必要がある)、使用することを強くお勧めします。

注: 信頼できない自己署名証明書を使用すると、セキュリティ上のリスク(wikipedia.org/wiki/Self-signed_certificate#Security_issues を参照)が発生するため、代替方法がない場合に限り使用するようにしてください。

すべてのユーザ

新しい DNS サーバをアドバタイズするようにルータまたはユーザのマシンを更新します。

ブラウザのユーザ

キーチェーンに認証局を追加します。そうしないと、Chrome は安全でない証明書を適切に処理しなくなります。

Python API ユーザ

キーチェーンに認証局を追加するか、SHOTGUN_API_CACERTS を設定します。

REST API ユーザ

キーチェーンに認証局を追加するか、認証局をリクエストまたは使用中のライブラリに渡します。

ツールキットのユーザ キーチェーンに認証局を追加するか、SHOTGUN_API_CACERTS を設定します。
確認事項 toolkit.ini に shotgun_api_cacerts 設定を含めることができるため、環境変数は不要になります。

追加の確認事項:

  • toolkit.ini に shotgun_api_cacerts 設定を含めることができるため、環境変数は不要になります。

フォローアップ手順

Shotgun サイトによる IP アクセス制限

ゲートウェイ サーバをセットアップする場合、スタジオの IP から送られる要求のみを受け入れるように Shotgun サイトを設定します。詳細については、Shotgun ヘルプ センターの「IP のホワイトリスト登録」を参照してください。

FAQ

ゲートウェイ サーバによりアーティストのセットアップが複雑になりますか?

いいえ。ゲートウェイ サーバにより、アーティストのインターネット アクセスが変わることはありません。現在、アーティストが制限された方法で特定のサイトを閲覧していても、そのまま閲覧を続けることができます。アーティストの観点から見ると、変更はごくわずかです。

すべての URL は以前と同じように機能します。電子メールや Shotgun が生成した電子メールについても同じです。

ゲートウェイ サーバはサイトの速度に影響しますか?

いいえ。直接アクセスする場合と速度は同じです。ゲートウェイの接続キャッシングによりさらに高速になる場合もあります。

転送内容を監視できますか?

はい。転送エージェントを通過するすべてのトラフィックをログに記録できます。外部からアクティビティを監視したり、Shotgun を使用している IP や作成された要求の数などを管理したりすることができます。ただし、トラフィックは HTTPS 経由で暗号化されるため、要求の内容も暗号化されます。

他のツールとゲートウェイ サーバを組み合わせて使用できますか?

はい。他のすべてのツールを使用し続けることができます。これには、Toolkit、Shotgun API、RV などが含まれます。

tank.shotgunstudio.com も転送する必要があるのはなぜですか?

tank.shotgunstudio.com は Toolkit アプリ ストアです。Toolkit はこのサイトがなくても動作しますが、Toolkit の更新を正常に実行するには、このサイトの呼び出しも転送する必要があります。

付録 1: スプリット ホライズン DNS (Ubuntu)

Debian で次の手順を実行します。手順と設定ファイルの場所は、プラットフォームごとに異なることがあります。

sudo apt-get install bind9

/etc/bind/named.conf を開いて、設定します。次に、bind9 の最低限の DNS 設定ファイルを示します。

options { 
    directory "/var/cache/bind"; 
    # tells the dns that zones it doesn't understand should be handled by another DNS 
    forwarders { 
        8.8.8.8; # Google's DNS. 
         //you can add here other DNS servers 
    }; 
    dnssec-validation auto; 
    dnssec-enable yes; 
    auth-nxdomain no;    # conform to RFC1035 
    listen-on-v6 { any; }; 
}; 
logging { 
    channel bind.query.log { 
        file "/var/log/dns.query.log" versions 600 size 30m; 
        print-time yes; 
        print-category yes; 
        print-severity yes; 
        severity debug 3; 
    }; 
    // IF YOU DO NOT HAVE SYSLOG, REMOVE THIS. 
    channel default_syslog { 
        print-time yes; 
        print-category yes; 
        print-severity yes; 
        syslog daemon; 
        severity info; 
    }; 
    channel default_log { 
        file "/var/named/log/default" versions 3 size 20m; 
        print-time yes; 
        print-category yes; 
        print-severity yes; 
        severity info; 
    }; 
    channel client_security_log { 
        file "/var/named/log/client_security" versions 3 size 20m; 
        print-time yes; 
        print-category yes; 
        print-severity yes; 
        severity info; 
    }; 
    // IF YOU DO NOT HAVE SYSLOG, PLEASE REMOVE `default_syslog;` FROM LINES BELLOW 
    category default  { default_syslog; default_log; }; 
    category config   { default_syslog; default_log; }; 
    category dispatch { default_syslog; default_log; }; 
    category network  { default_syslog; default_log; }; 
    category general  { default_syslog; default_log; }; 
    category client   { default_syslog; client_security_log; };        
    category security { default_syslog; client_security_log; }; 
    category queries { bind.query.log; }; 
}; 
# Defines a zone we want to answer DNS query for 
zone "shotgunstudio.com" { 
    type master; 
    file "/etc/bind/db.shotgunstudio.com"; 
}; 

/etc/bind/db.shotgunstudio.com を開いて、shotgunstudio.com の bind9 ゾーンにこの最低限の設定ファイルを貼り付けます(mysite をスタジオの URL で置き換えます)。

$TTL    1
# This is the SOA header. I lifted this from somewhere and put very small TTL
@       IN      SOA     ns.shotgunstudio.com. root.shotgunstudio.com. (
                  4     ; Serial
                  5     ; Refresh
                  5     ; Retry
                  5     ; Expire
                  5 )   ; Negative Cache TTL

@       IN              NS              ns.shotgunstudio.com.
ns.shotgunstudio.com.      IN      A       192.168.1.174 ;A Server IP...
# This is where we are mapping our internal site to our HAProxy server address
mysite.shotgunstudio.com.  IN      A       192.168.1.174 ;Another Server IP

 

付録 2: HAProxy をゲートウェイとして設定する

Haproxy をインストールします。Docker ユーザは最新バージョンの haproxy:alpine コンテナ(https://hub.docker.com/_/haproxy/)を使用できます:

apt-get install haproxy

/etc/haproxy/haproxy.cfg を開いて、HAProxy を設定します。次に、HAProxy 1.6 の設定例を示します。<> で囲まれた部分を、<> 記号を含めて、独自の情報で置き換えます。

global
 maxconn 4096
 pidfile /tmp/haproxy-queue.pid
  
defaults
 log global
 timeout connect 300000
 timeout client 300000
 timeout server 300000

# handle external ip changes
resolvers external_dns
nameserver dns1 <external_dns_ip>:53
resolve_retries 3
timeout retry 1s
hold valid 10s # in case someone enters SG address without https listen http_redirect
bind <internal_ip_address_1>:80 mode http redirect scheme https code 301 if !{ ssl_fc } listen shotgun_proxy
bind <internal_ip_address_1>:443 mode tcp server app1 <your_site_name>.shotgunstudio.com:443 listen shotgun_s3_proxy
bind <internal_ip_address_2>:443 mode tcp server app1 sg-media-usor-01.s3-accelerate.amazonaws.com:443

listen shotgun_tank_proxy
bind <internal_ip_address_3>:443
 mode tcp
 server app1 tank.shotgunstudio.com:443

サービスを開始します。

sudo service haproxy start

何らかの理由でトラフィックを再暗号化する必要がある場合は、プロキシ モードを tcp から http に切り替え、自己署名証明書を使用して、古い TLS トラフィックを復号化して再暗号化することができます。新しい証明書を信頼するには、自己署名証明書を生成するために使用される CA を各クライアント システムに追加する必要があります。また、トラフィックの暗号化/再暗号化はスタジオのセキュリティ上のリスクをもたらす可能性があるため、細心の注意を払って作業を進めてください。

この記事は役に立ちましたか?
2人中1人がこの記事が役に立ったと言っています
フォローする