다중 인스턴스 서버에서 SSRS (SQL Server Reporting Services) IP 처리


9

Tl; Dr

다중 인스턴스 SQL Server에 전용 IP 주소와 포트 (162.xxx.xxx.51 : 1433)가있는 SQL Server 인스턴스 (SQLSERVER01-i01)가 있습니다 (Windows Server의 각 SQL Server 인스턴스에는 고유 한 IP 주소가 있음) )는 모두 하나의 Windows 서버에서 실행 중입니다 (SQLSERVER01 / 162.xxx.xxx.50).

또한 고유 한 IP 주소와 포트 (168.xxx.xxx.71 : 1433)를 가진 전용 Reporting Services 인스턴스 (SQLSERVERRS01-i01)가 있으며 고유 한 IP 주소 (168)를 가진 다른 Windows 서버 (SQLSERVERRS01)에서 실행됩니다. .xxx.xxx.70).

전용보고 서비스 서버는 응용 프로그램이 APPL1를 통해 중 하나에 도달 할 수 있습니다 http://SQLSERVERRS01-i01:80/Reports_APPL1또는 통해를 http://SQLSERVERRS01:80/Reports_APPL1.

SSRS는 *:80호스트 헤더에 대한 Reporting Services 구성 의 구성으로 인해 두 요청을 모두 선택합니다 .

각 IP 범위 사이에 여러 개의 방화벽이 있으므로 각 IP-to-IP 또는 IPrange-to-IP 연결에 대해 특정 규칙을 적용해야합니다. 그러나 두 대의 서버가 관련된 경우 보안에 따라 항상 방화벽에서 IP-IP 규칙이되어야합니다.

질문

(스크린 샷을 기반으로 아래로)

Reporting Services 서버가 데이터를 검색하기 위해 SQL Server 인스턴스 (162.xxx.xxx.51)에 연결하면 항상 Windows 서버의 기본 IP 주소 (168.xxx.xxx.70 / 선호)와 연결됩니다 ) SSRS가 실행 중이거나 SQL Server Reporting Services 인스턴스 (168.xxx.xxx.71)의 IP 주소를 사용합니까 (때로는)?

이는 IP-to-IP 접근 방식을 사용하는 방화벽 규칙 구성과 관련이 있습니다. 포트 1433을 통한 168.xxx.xxx.71 ~ 162.xxx.xxx.51 연결 또는 168.xxx.xxx.70 ~ 162.xxx.xxx.51 연결을 정의하는 규칙을 적용해야합니다. 포트 1433.

현재 두 방화벽 규칙을 모두 적용하고 싶습니다.

보너스 질문

전용 IP 주소와 통신하도록 Reporting Services 서버를 구성 할 수 있습니까? 이 경우 168.xxx.xxx.71 주소를 사용하십시오.

내가 찾지 못한 답변

방화벽 구성을 최적화하는 방법이나 네트워크에 구역화 개념을 구현하는 방법에 대한 조언을 구하고 있지 않습니다. (이미 파이프 라인에 있습니다). 또한 SQL Server와 SSRS를 동일한 서버에두면 문제가 해결 될 것이라는 의견에 관심이 없습니다. SSRS 구성 요소와 함께 실행하는 데 필요한 타사 소프트웨어에 대해서는 알고 있습니다.

효과가있다

SSRS와 SQL Server 인스턴스간에 방화벽 규칙을 모두 적용하면 구성이 작동합니다.

168.xxx.xxx.71 --> 162.xxx.xxx.51 : 1433
168.xxx.xxx.70 --> 162.xxx.xxx.51 : 1433

하나의 방화벽 규칙을 안전하게 줄이고 모든 것이 여전히 작동하는지 확인하고 싶습니다. (참조 더 아래 스크린 샷)
편집 : 내가 지금까지 읽은 기사가 난 단지 두 번째 규칙을 필요로 제안하지만 보장은 없습니다.

내가 이미 상담 한 기사

  1. SQL Server 설치
    기반 문서에 대한 보안 고려 사항

  2. SQL Server 액세스를 허용하도록 Windows 방화벽 구성
    이 문서에서는 SQL Server의 방화벽 구성과 관련된 다른 모든 문서를 설명합니다.

  3. 데이터베이스 엔진 액세스를위한 Windows 방화벽 구성
    사용 된 IP 주소가 없습니다.

  4. 보고서 서버 액세스를위한 방화벽 구성
    이 기사는 다음과 같이 매우 흥미 롭습니다.

    외부 컴퓨터의 SQL Server 관계형 데이터베이스에 액세스하거나 보고서 서버 데이터베이스가 외부 SQL Server 인스턴스에있는 경우 외부 컴퓨터에서 포트 1433 및 1434를 열어야합니다.

    ...하지만 여전히 IP 구성 / 설정 / 기본값에 대한 단어는 아닙니다.

  5. 멀티 홈 Windows 컴퓨터에서 소스 IP 주소 선택

  6. Windows Server 2008 및 Windows Vista에서 소스 IP 주소 선택 기능은 이전 버전의 Windows에서 해당 기능과 다릅니다.

제 5 조와 제 6 조는 제임스 (dba.se)에 의해 친절하게 제공되었습니다 . 그들은 현재 가장 적합한 답변 인 것 같습니다. 그러나 한 기사에서 여러 개의 NIC 사용에 대해 언급하는 반면, 여러 개의 IP가 할당 된 NIC는 하나뿐입니다. Tom (dba.se)은 또한 조언과 일반적인 의견을 가지고 있습니다.

dba.stackexchange.com에없는 이유

질문의 복잡한 특성으로 인해 처음에 serverfault.com에이 질문을 게시하는 것을 꺼려했습니다. 이 질문은 SQL Server와 관련이 있지만 Windows Server 와도 관련이 있습니다. 결국 나는 그것을 더 나은 단어의 손실을 위해 Windows Server IP 처리라고 생각하기 때문에 여기에 게시하기로 결정했습니다.

중재자가 dba.stackexchange.com에서 더 나은 응답을 얻을 것이라고 생각하면 질문을 저기로 이동하십시오.

긴 설명

우리 환경에는 여러 SQL Server 인스턴스와 여러 IP 설정을 호스팅하는 Windows 서버가 있습니다. 복잡한 방화벽 구성, 전용 SQL Server Reporting Services (SSRS) 서버를 추가하고 다음과 같은 환경을 제공합니다.

환경 개요

기본적으로 개별 IP 주소에서 최대 15 개의 15 개의 SQL Server 인스턴스를 실행하는 하나의 Windows Server를 가질 수 있습니다. 전용 Reporting Services 인스턴스에도 동일하게 적용됩니다.

방화벽 규칙

다른 IP 범위는 현재 영역으로 구성되어 있지 않으므로 각 방화벽 규칙을 IP-IP 또는 IPrange-to-IP 규칙으로 독립적으로 구성해야합니다. 두 대의 서버가 관련되면 보안에 따라 항상 IP-IP 규칙이되어야합니다. 각 SQL Server 인스턴스에는 통신과 관련된 방화벽에 대한 고유 한 규칙 집합이 있습니다 (이는 서버 간 또는 클라이언트 간 링크 임). 방화벽 규칙을 적용하면 현재 4-6 주 대기 시간이 발생합니다. 방화벽 규칙의 양을 줄이면 네트워크 보안 팀의 부담이 줄어 듭니다.

SQL Server 인스턴스 IP 구성

전용 IP 및 포트에서만 선택하도록 SQL Server 인스턴스를 구성하려면 SQL Server 구성 관리자 유틸리티의 일부 설정을 수정하십시오. 첫 번째 단계는 SQL Server 구성 관리자를 시작하고 왼쪽 섹션에서 SQL Server 네트워크 구성 | InstanceName의 프로토콜 . 왼쪽 분할 창에서 TCP / IP 프로토콜 이름을 마우스 왼쪽 단추로 클릭하고 프로토콜을 사용 하십시오. 그런 다음 프로토콜을 다시 마우스 왼쪽 단추로 클릭하고 TCP / IP 등록 정보 창을여십시오.

그런 다음 프로토콜 레지스터 에 다음 설정이 설정되어 있는지 확인하십시오 .

Enabled           : Yes
Listen All        : No

에서 IP Adresses은 (는 168.xxx.xxx.71이 될 것입니다이 예에서보고 서비스 서버 등) 문제의 IP 주소에 대한 다음 설정을 확인 등록

Active            : Yes
Enabled           : Yes
IP Address        : 168.xxx.xxx.71
TCP Dynamic Ports : 
TCP Port          : 1433

참고 : TCP 동적 포트의 설정 은 0이 아니라 비어 있어야 합니다.

이제 포트 1433을 사용하여 168.xxx.xxx.71에서 데이터베이스 연결 만 픽업하는 SQL Server 인스턴스가 있습니다.

SQL Server 인스턴스 요약

SQL Server Browser 서비스가 실행되고 있지 않으며 각 개별 SQL Server 인스턴스는 포트 1433에서 고유 한 IP 주소 만 사용하도록 구성되어 있습니다. GENERAL이라는 SQL Server 인스턴스가 있으면 호스트 이름이 SQLSERVER01이고 두 개의 IP 주소가 162.xxx 인 Windows 서버 .xxx.50 (호스트) 및 162.xxx.xxx.51 (SQL 인스턴스) 다음 구성 항목으로 끝납니다.

Windows Server      : SQLSERVER01 
Windows Server IP   : 162.xxx.xxx.50
SQL Server Instance : SQLSERVER01-i01 (DNS A record)
SQL Server Instance : GENERAL (can only be used on the host itself)
SQL Server IP/Port  : 162.xxx.xxx.51:1433

SQL Server 구성 관리자 유틸리티에서이 IP 주소를 수신하도록 구성된 SQL Server 인스턴스가 없으므로 SQL Server는 162.xxx.xxx.50 : 1433에 대한 요청을 선택하지 않습니다. SQL Server는 SQLSERVER01-i01 (포트 1433) 또는 162.xxx.xxx.51,1433에 대한 요청 만 선택합니다.

SQL Server Reporting Services 인스턴스 요약

SQL Server Browser 서비스가 실행되고 있지 않으며 각 개별 SQL Server Reporting Services 인스턴스는 포트 1433에서 고유 한 IP 주소 만 사용하도록 구성되어 있습니다. 호스트 이름이 SQLSERVERRS01 인 응용 프로그램 인 Windows Server 인 GENERAL이라는 SQL Server Reporting Services 인스턴스 SSRS라는 이름 APPL1과 두 개의 IP 주소 168.xxx.xxx.70 (호스트) 및 168.xxx.xxx.71 (SQL 인스턴스)에서 다음 구성 항목으로 끝납니다.

Windows Server      : SQLSERVERRS01 
Windows Server IP   : 168.xxx.xxx.70
SQL Server Instance : SQLSERVERRS01-i01 (DNS A record)
SQL Server Instance : GENERAL (can only be used on the host itself)
SQL Server IP/Port  : 168.xxx.xxx.71:1433
Reporting Services  : http://sqlserverrs01-i01/Reports_APPL1
                      http://sqlserverrs01/Reports_APPL1

SQL Server 구성 관리자 유틸리티에서이 IP 주소를 수신하도록 구성된 SQL Server 인스턴스가 없으므로 SQL Server는 168.xxx.xxx.70 : 1433에 대한 요청을 선택하지 않습니다. SQL Server는 SQLSERVER01-i01 (포트 1433) 또는 162.xxx.xxx.71,1433에 대한 요청 만 선택합니다.

SSRS는 호스트 헤더에 대한 Reporting Services 구성의 * : 80 구성으로 인해 http : // sqlserverrs01-i01 / Reports_APPL1 또는 http : // sqlserverrs01 / Reports_APPL1에 대한 요청을 선택합니다 .

답변을 작성하는 데 시간을 할애 할 수있는 충분한 정보를 제공해 주시길 바랍니다. 자세한 기술 정보와 링크를 기다리겠습니다.

StackEdit으로 작성 하고 나중에 수동으로 스택 교환 호환 가능하도록 수정했습니다.

역사

편집 1 : 최초 릴리스
편집 2 : 가독성을 위해 다시 포맷되었습니다. 설명 SF / DB를 아래로 이동했습니다. Windows Server
Edit 3의 호스트 이름 추가 : 방화벽 규칙 목록에서 잘못된 IP 주소를 수정했습니다.
편집 4 : 어떤 곳에서 호스팅 단어를 실행으로 변경했습니다 (가상화되지 않은 환경입니다). 한 문장으로 IP 주소 추가
편집 5 : 이미 상담하고 참조한 기사 목록 추가
편집 6 : 정리 내역 섹션


1
네트워킹 스택에서 하위 수준으로 해결할 수 있다면 SSRS와 SQL Native 클라이언트가 방해해서는 안된다고 생각합니다. 예를 들어 SSRS 서버에서 SQL Server 인스턴스에 대한 경로를 추가하여 항상 특정 NIC를 사용하는 경우 경로를 벗어날 수 있습니다.
Tom V-topanswers.xyz

1
올바르게 기억한다면 SSRS 전용 IP는 단순히 IIS 바인딩 (보고서는 기본적으로 멋진 IIS 사이트)이며 통신에 사용되지 않습니다. 이론을 테스트 할 방법이 없지만 SSRS가 전용 IP를 통해 SQL Server 데이터 원본과 통신 할 것이라고는 생각하지 않습니다.
Nathan C

답변:


6

소개

초기 연구에서 찾은 다양한 문서와 링크 및 토론으로 제공된 문서에 따르면 견고하고 신뢰할 수 있으며 호환되는 솔루션을 찾았습니다.

RFC 3484

이진 비교는 추가로 수행되었으며 적용되는 규칙은 RFC 3484 에 따른 것으로 IPv4 주소에도 유효합니다.

RFC 3484는 또한 규칙 8 직후에

Rule 8 may be superseded if the implementation has other means of
choosing among source addresses.  For example, if the implementation
somehow knows which source address will result in the "best"
communications performance.

멀티 홈 Windows 컴퓨터에서 소스 IP 주소 선택

이제 RFC 3484의 모든 규칙이 IPv4 주소에 적용되는 것은 아닙니다. 멀티 홈 Windows 컴퓨터에서 Microsoft 블로그 기사 소스 IP 주소 선택에 적용되는 규칙이 설명되어 있습니다.

Windows Vista / Windows Server 2008 동작 바로 아래에 다음과 같은 작은 섹션이 있습니다 .

프로그램이 소스 IP를 지정하지 않은 경우 XP와 유사하게 스택은 대상 IP 주소를 참조한 다음 패킷을 전송할 최상의 네트워크 어댑터를 선택할 수 있도록 전체 IP 라우팅 테이블을 검사합니다. 네트워크 어댑터를 선택한 후 스택은 RFC 3484에 정의 된 주소 선택 프로세스를 사용하고 해당 IP 주소를 아웃 바운드 패킷의 소스 IP 주소로 사용합니다.

SQL / SSRS 인스턴스에 NIC가 하나만있는 것처럼 첫 번째 부분은 무례합니다. Windows Server는 항상 사용 가능한 유일한 NIC를 선택합니다.

지금까지 RFC 3484를 Microsoft 블로그와 결합하면 두 IP 주소 모두 소스 IP 주소의 유효한 후보가됩니다. 이에 대한 설명은 답에서 더 나옵니다.

케이블 가이

Cable Guy의 기사 Cable Guy Strong 및 Weak Host Models강력한 호스트 전송 및 수신 환경과 약한 호스트 전송 및 수신 환경 에서 IP 선택이 작동하는 방법에 대해 자세히 설명 합니다. 추가 읽기는 양호하지만 소스 IP 선택 방법에 대해서는 더 이상 알 수 없습니다. 이 기사는 이미 알려진 RFC 3484와 관련이 있습니다.

설명 할 수없는 설명

솔루션을 설명하기 위해 먼저 문제의 IP 주소를 이진으로 변환해야합니다. 내 질문에 게이트웨이를 제공하지 않았으므로 두 가지 값을 가정합니다.

소스 IP 주소 및 이진 표기법

다음은 관련된 IP 주소에 대한 변환 된 이진 값 목록입니다.

10101000.00000001.00000001.01000110   168.xxx.xxx.070/128   Windows Server
10101000.00000001.00000001.01000111   168.xxx.xxx.071/128   SQL Server / SSRS Instance
10101000.00000001.00000001.00000010   168.xxx.xxx.002/128   Gateway (Assumption 1)
10101000.00000001.00000001.01100010   168.xxx.xxx.100/128   Gateway (Assumption 2)
11111111.11111111.11111111.10000000   255.255.255.128/025   Subnet Mask / CIDR

대상 IP 주소 및 이진 표기법

10101000.00000000.00000000.00110011   168.xxx.xxx.051/128   SQL Server

예 1 : SQL / SSRS 인스턴스 IP보다 낮은 게이트웨이 IP

이 예에서는 게이트웨이의 IP 주소가 SQL Server / SSRS 인스턴스의 IP 주소 (168.001.001.002)보다 낮다고 가정합니다.

Windows Server와 SQL Server / SSRS 인스턴스의 이진 주소를 모두 비교하면 다음과 같습니다.

SQL/SSRS Instance IP
10101000.00000001.00000001.00000010 (Gateway Assumption 1)
10101000.00000001.00000001.01000111 (SQL/SSRS)
-----------------------------------
xxxxxxxx.xxxxxxxx.xxxxxxxx.x------- (x=matching high order bits)

Window Server IP
10101000.00000001.00000001.00000010 (Gateway Assumption 1)
10101000.00000001.00000001.01000110 (Windows)
-----------------------------------
xxxxxxxx.xxxxxxxx.xxxxxxxx.x------- (x=matching high order bits)

결과 예 1

이 예에서 두 IP 주소는 동일한 양의 일치하는 상위 비트 (또는 가장 긴 일치 접두어)를 갖습니다. 지금까지 http.sys 프로세스는 나가는 통신에 IP 주소 중 하나를 사용합니다.

예 2 : SQL / SSRS 인스턴스 IP보다 높은 게이트웨이 IP

이 예에서는 게이트웨이의 IP 주소가 SQL Server / SSRS 인스턴스의 IP 주소 (168.001.001.100)보다 높다고 가정합니다.

Windows Server와 SQL Server / SSRS 인스턴스의 이진 주소를 모두 비교하면 다음과 같습니다.

SQL/SSRS Instance IP
10101000.00000001.00000001.00000010 (Gateway Assumption 2)
10101000.00000001.00000001.01100010 (SQL/SSRS)
-----------------------------------
xxxxxxxx.xxxxxxxx.xxxxxxxx.x------- (x=matching high order bits)

Windows Server IP
10101000.00000001.00000001.00000010 (Gateway Assumption 2)
10101000.00000001.00000001.01100010 (Windows)
-----------------------------------
xxxxxxxx.xxxxxxxx.xxxxxxxx.x------- (x=matching high order bits)

결과 예 2

게이트웨이의 IP 주소가 이제 Windows 서버 및 SQL / SSRS 인스턴스의 IP 주소보다 높더라도 상위 비트 (또는 가장 긴 일치 접 두부)와 일치하는 양은 여전히 ​​동일합니다. 지금까지 http.sys 프로세스는 나가는 통신에 IP 주소 중 하나를 사용합니다.

지금까지의 결과 요약

지금까지 Windows 서버 (.70)의 SQL / SSRS 인스턴스 (.71)에서 실행중인 발신 통신에 http.sys 프로세스가 사용할 IP 주소를 알 수 없습니다.

"불가능을 제거했을 때, 불가능한 것은 무엇이든지 진실이되어야합니다"-Sherlock Holmes

앞에서 언급 한 RFC 및 Microsoft 지식을 통해 소스 IP 주소를 정확하게 지정 / 선택 / 정의 할 수있는 상황이 있습니다. 그러나 IP 주소가 서로 너무 가까이 있고 게이트웨이 근처에 있다면 운이 좋을 것입니다. 아니면?

내가 (방화벽) 규칙을 만드는 위치에 있고 Microsoft는 ...

구현은 소스 주소 중에서 선택할 수있는 다른 방법을 가지고 있습니다. 예를 들어, 구현에서 어떤 소스 주소가 "최상의"통신 성능을 초래할 것인지 알고 있다면.

... http.sys 프로세스의 IP 주소를 결정하기 위해 해야 할 일은 원하는 IP 주소로 방화벽 규칙을 하나만 만드는 것입니다.

무슨 일이야

  1. 168.xxx.xxx.71에서 168.xxx.xxx.51 : 1433까지 방화벽 규칙을 정의합니다.
  2. SQL / SSRS 인스턴스의 http.sys 구성 요소는 RFC 3484를 준수하고 정의 된 규칙에 따라 소스 IP를 선택합니다.
  3. IP 주소 168.xxx.xxx.71 (NIC1)은 포트 1433을 통해 IP 주소 168.xxx.xxx.51에 도달하는 소스 IP 주소로 결정되어 모든 발신 패킷에 할당됩니다.

혜택

  1. 나는 RFC 3484의 구현을 방해하지 않습니다
  2. 나는 경로 또는 ARP 구성으로 저글링하지 않습니다.
  3. RFC 3484 및 Microsoft의 구현을 준수합니다.
  4. 레지스트리 설정이나 시스템 구성을 해킹하지 않습니다
  5. 하나의 방화벽 규칙이 없다

확인

방화벽 규칙에서 IP 주소를 아직 제거하지는 않았지만 설계 / 정의 된대로 작동 할 것이라고 확신합니다. 요약이 이어집니다.

역사

편집 1 초기 게시물
편집 2 정리 답변, 추가 내역 섹션


1
당신의 논리는 합리적으로 보이며, 현재 행동을 결정하기 위해 상당한 노력을 기울였습니다. 그러나 구현 세부 사항에 의존하는 것은 예고없이 변경되지 않을 것이라는 보장이 없으므로 위험합니다.
Jens Ehrich

우리는 "설계에 의한 고장"에 대해 상호 동의 할 수 있습니까? RFC 3484 및 Microsoft의 구현에 의존하고 있지만 다른 옵션에는 어떤 것이 있습니까? 안전한 측면에 이중 방화벽 규칙을 사용해야합니까?
John aka hot2use

1
예, 두 가지 규칙이 유일한 안전한 옵션입니다. 나는 그것이 올바르게 구현되지 않았거나 잘 구현되지 않았다는 것에 완전히 동의합니다.
Jens Ehrich

4

SSRS는 여러 표준 데이터 소스와 다른 .NET 데이터 소스를 지원합니다.

https://msdn.microsoft.com/en-ca/library/ms159219.aspx

데이터 소스에 SQL 기본 클라이언트를 사용한다고 가정하면 소스 IP 주소를 지정할 수있는 옵션이 없습니다.

https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring(v=vs.110).aspx

따라서 네트워크 연결을 설정할 때 클라이언트가 Bind () 메서드 중에 IPADDR_ANY를 사용하는 이유가 있습니다. 이로 인해 Windows가 결정을 내립니다.

Windows 2008 및 업 주소 선택은 다음 홉과 일치하는 비트 수가 가장 많으므로 응답이 기본 게이트웨이 (또는 정의한 특정 경로)에 따라 달라집니다.

https://blogs.technet.microsoft.com/networking/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer/

내가 얻을 수있는 한 다이어그램이나 경로에 대한 언급이 없었습니다.

행운을 빕니다!


기본 게이트웨이로 168.xxx.xxx.002 또는 168.xxx.xxx.100으로 가정 할 수 있습니다. IP 선택 프로세스에 영향을 미치지 않습니다. IP 주소 .70과 .71은 모두 가장 긴 일치 접두어를 갖습니다 .
John aka hot2use

모호하기 때문에 skipassource ( blogs.technet.microsoft.com/rmilne/2012/02/08/… )를 사용할 수 있지만 모든 발신 트래픽에 영향을 미칩니다. 그렇지 않으면 b / c 두 규칙을 모두 작성해야합니다. 시스템이 항상 동일한 IP를 선택하더라도 향후 업데이트로 인해 구성이 손상 될 수 있습니다.
Jens Ehrich

이 기사에서 SKIPASSOURCE 매개 변수에 대해 읽었으며 이후 버전의 IP 구현에서는 핫픽스와 함께 도입되었으므로 제거 될 수 있다는 결론에 도달했습니다.
John aka hot2use

1
내 경험에 따르면 (20 년 이상) 핫픽스는 일반적으로 (1) 완전히 테스트되지 않은 수정 프로그램을 신속하게 제공하거나 (2) 영구 솔루션을 개발할 임시 수정 프로그램을 제공하는 데 사용됩니다. 어느 쪽이든 나는이 기능을 제거하지 않을 것이라고 생각합니다. 그러나 다른 모든 방화벽 규칙을 조정해야하는 나머지 구성 b / c에 부정적인 영향을 줄 수 있습니다.
Jens Ehrich
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.