게이트웨이 서버 설정

이 문서에서는 스튜디오의 인터넷 제한 정책을 적절하게 충족하면서 호스트된 Shotgun 사이트에 액세스할 수 있도록 설정하는 방법에 대해 설명합니다.

범위 및 가정

이 문서는 시스템 및 Shotgun 관리자를 위해 작성되었으며,

이 문서를 참조하는 사람에게 프록시, 네트워킹 및 HTTP 프로토콜에 대한 기본 지식이 있다고 가정합니다.

고지 사항

이 문서는 고객이 게이트웨이 서버를 설정하는 것을 지원하기 위한 안내 목적으로 제공됩니다. 일부 지원을 제공할 수는 있지만, 게이트웨이 서버 구현은 고객의 책임이며 Shotgun에서 구현하지 않습니다.

이 문서에서는 외부 소스 링크도 제공하므로 참조 시 각자 적절하게 판단하십시오.

게이트웨이 서버를 사용하여 클라우드에서 Shotgun에 액세스

게이트웨이 서버를 통해 호스트된 Shotgun 사이트에 액세스하지만 인터넷의 다른 부분에는 액세스할 수 없도록 설정할 수 있습니다. 필터링된 요청은 Shotgun 엔드포인트로 전달하지만 다른 모든 요청은 차단합니다. 즉, 사용자가 *.shotgunstudio.com을 요청하면 이 요청은 통과합니다. 그러나 사용자가 인증되지 않은 사이트를 요청하면 이 요청은 통과하지 못합니다.

SGCS_-_Shotgun_Ecosystem___Gateway.png

게이트웨이 서버를 사용하는 이유는 무엇입니까?

  • 사용자가 Shotgun에서 호스트되는 인스턴스에 액세스할 수 있도록 하면서 사용 중인 네트워크를 인터넷에서 분리할 수 있습니다.
  • 사용되지 않는 연결/암호화 프로토콜을 사용하여 Shotgun에 연결할 수 있습니다(이 작업은 사용자의 책임 하에 수행되어야 함).

Shotgun의 프록시 서버를 설정하는 대신 게이트웨이 서버를 사용하는 것이 좋습니다. 게이트웨이 서버를 사용하면 다음과 같은 이점이 있습니다.

  • 시간에 따라 변경될 수 있는 복잡한 IP 범위를 화이트리스트로 처리할 필요가 없습니다.
  • Shotgun에서 호스트되는 각 사이트에 포함된 웹 가속화 기능을 계속해서 활용할 수 있습니다.
  • S3 프록시 솔루션과 비교하여 Amazon S3에서 성능이 향상되는 것을 확인할 수 있습니다.
  • S3 프록시 솔루션과 비교하여 모든 재생 및 모든 업로드에서 성능이 향상되는 것을 확인할 수 있습니다.

시작하기

게이트웨이 서버 설정에는 세 가지 주요 단계가 있습니다.

  1. 분할 수평 DNS(도메인 이름 시스템)를 설정합니다.
  2. HAProxy를 사용하여 게이트웨이 서버를 설정합니다.
  3. 게이트웨이를 사용할 사용자 환경을 구성합니다.

0단계: 준비

게이트웨이 서버를 올바르게 구성하려면 다음과 같은 정보가 필요합니다.

  • 사이트 이름(<your_site_name>.shotgunstudio.com)
  • 성능 최적화를 위해 지역을 기반으로 하는 특정 미디어 버킷의 이름입니다. 이 정보를 얻는 방법에 대한 자세한 내용은 다음 문서를 참조하십시오. https://support.shotgunsoftware.com/hc/ko/articles/115000022554-Selecting-a-storage-location-for-uploaded-files-overview. 이 정보를 파악하는 데 문제가 있을 경우 Shotgun 지원 팀에 문의하십시오.
  • 서로 다른 두 가지 내부 IP 주소가 게이트웨이 서버에 할당되는데, 하나는 <your_site_name>.shotgunstudio.com에서 수신 대기하고 다른 하나는 S3 URL에서 수신 대기합니다. 툴킷을 사용 중인 경우 세 번째 IP가 필요할 수 있습니다. IP 주소 범위는 스튜디오의 네트워크 설정 방식에 따라 달라집니다.

1단계: 분할 수평 DNS

분할 수평 DNS를 사용하면 쿼리 소스에 따라 다양한 답변을 쿼리(이 경우 URL 확인)에 제공할 수 있습니다. 분할 수평 DNS는 스튜디오에 있는 작업자를 위해 Shotgun URL을 Shotgun 공용 IP로 변환하는 대신 내부 IP 주소(게이트웨이 서버)로 변환합니다.

게이트웨이 서버는 모든 요청을 Shotgun IP로 전달합니다. 게이트웨이 서버에는 인터넷에 요청을 보낼 수 있는 무제한 액세스 권한이 있지만 모든 아티스트에게는 내부 서버만 표시되고 Shotgun 인터넷 리소스로만 액세스가 제한됩니다.

이러한 구성으로 DNS를 설정하려면 몇 가지 기본적인 IT 기술이 필요합니다. 다음은 설정 방법의 몇 가지 예입니다.

DNS 서버가 아직 없는 경우 서버 순서를 지정하거나 이를 위한 전용 서버를 지정할 수 있습니다. 이 문서에서는 Linux 시스템의 예를 소개합니다.

2단계: HAProxy를 Shotgun 게이트웨이로 구성

게이트웨이 서버 구현을 위해 HAProxy를 사용하는 것이 좋습니다. HAProxy는 단순하고 신뢰할 수 있는 고성능 TCP/HTTP 부하 분산 장치로, 게이트웨이를 쉽게 구현할 수 있습니다. 버전 1.6 이상을 사용하는 것이 좋습니다. HAProxy에 대한 하드웨어 요구 사항은 여기에서 찾을 수 있습니다.

HAProxy 구성 파일에 대한 예는 부록 2에서 확인할 수 있습니다.

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 액세스 제한

게이트웨이 서버를 설정한 경우에는 Shotgun 사이트에서 스튜디오 IP의 요청만 허용할 수 있습니다. 자세한 정보는 Shotgun 도움말 센터의 "IP 화이트리스트"를 참조하십시오.

FAQ

게이트웨이 서버는 아티스트의 설정을 복잡하게 만듭니까?

아니요, 게이트웨이 서버는 아티스트의 인터넷 액세스를 변경하지 않습니다. 현재 아티스트가 제한된 방식으로 특정 사이트를 탐색할 수 있는 경우 계속 그렇게 할 수 있습니다. 아티스트 관점에서는 변경 사항을 알아챌 수 없습니다.

모든 URL은 이전처럼 계속 작동합니다. 이메일 및 Shotgun에서 생성된 이메일에 있는 URL도 마찬가지입니다.

게이트웨이 서버는 사이트 속도에 영향을 줍니까?

아니요, 직접 액세스할 때의 속도와 동일합니다. 오히려 게이트웨이의 커넥션 캐싱 때문에 속도가 더 빨라졌다고 느껴질 수도 있습니다.

전달된 트래픽을 모니터링할 수 있습니까?

예, 전달 에이전트를 통해 라우팅된 모든 트래픽을 기록할 수 있습니다. 외부에서 해당 액티비티를 모니터링하고 Shotgun에서 사용하는 IP, 이루어진 요청 수 등을 트래킹할 수 있습니다. 그러나 트래픽은 HTTPS를 통해 암호화되기 때문에 요청 내용도 암호화됩니다.

다른 도구를 게이트웨이 서버와 함께 사용할 수 있습니까?

예, 다른 모든 도구를 계속 사용할 수 있습니다. 여기에는 툴킷, Shotgun API, RV 등이 포함됩니다.

tank.shotgunstudio.com도 전달해야 하는 이유는 무엇입니까?

tank.shotgunstudio.com은 툴킷 App Store입니다. tank.shotgunstudio.com이 없어도 툴킷을 작동할 수 있지만 툴킷 업데이트가 성공하려면 해당 사이트가 전달되어야 합니다.

부록 1 - 분할 수평 DNS(Ubuntu)

다음 단계는 Debian에서 수행되었습니다. 단계 및 구성 파일 위치는 플랫폼에 따라 달라질 수 있습니다.

sudo apt-get install bind9

/etc/bind/named.conf를 열고 named를 구성합니다. 다음은 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를 각 클라이언트 시스템에 추가해야 할 수 있습니다. 또한 트래픽 암호화/재암호화 시 스튜디오의 보안이 취약해질 수 있으므로 매우 주의하여 진행해야 합니다.

팔로우