viatoris, 인생의 잡동사니들 RSS FEED

*** 이 문서의 내용은 정확하지 않을 수 있고, 이 방법대로 해서 발생하는 문제는 각자 책임입니다.

데이터베이스쪽의 보안이 점점 강조되는 추세하에서 NAT 외부에서 NAT 내부의 DB에 접속하도록 설계되는 경우는 거의 없다. DB는 방화벽 아래에 설치하고 제한된 네트웍에만 공개하는 것이 원칙으로 되어있다. 데이터보안 측면에서 고무적인 현상이라 할 수 있다(이는 데이터 암호화와는 다른 방향에서의 접근이다. 다른 얘기지만 데이터암호화는 설사 공격자가 데이터를 가져가더라도 암호화키를 모르면 데이터의 내용을 모르도록 하는 것이다).

그러하다보니 NAT안의 오라클을 외부에서 접속하는 것은 까다롭다. 이는 오라클의 접속 절차를 살펴보면 잘 알수 있다. NAT하에서 TNSPING은 잘 가지만 접속이 잘 안되서 속이 타는 이유를 아래 그림에서 알 수 있을 것이다.

오라클이 접속할때 그림과 같은 단계(정확하진 않지만 대충은 맞다;;)를 통해 접속을 하게 되는데, 문제는 3번단계에서 발생한다. TNSPING은 리스너 단계에서 응답을 주고 끝나기 때문에 NAT에서 포워딩을 제대로 해주게 되면 문제없이 OK가 떨어진다.

하지만 실제 client를 이용해서 접속을 하려면 1~5번까지가 모두 성공해야 한다. 앞에서 3번이 문제라고 하긴 했지만, 5번단계까지 문제없이 잘 진행한다. 그럼 무엇이 문제일까? 바로 3번단계에서 주는 정보가 잘못되는 것이다. HOST IP를 TNS Packet를 통해 클라이언트에 전달을 해주어야 하는데(오라클은 리스너와 인스턴스를 별도로 분리할 수 있다는걸 생각하면, 리스너의 아이피만으로 접속못하는 이유가 나온다), NAT아래 사설아이피를 가지는 DB서버의 경우 서버IP를 사설IP를 전달해줘버리는 것이다. 따라서 5번단계에서 다시 서버에 요청을 할때 요청IP가 잘못되었으니 접속이 안되는 것이다.

이 문제를 해결하기 위해서 두가지정도의 해법이 존재한다.

첫번째 방법은 Connection Manager(이하 CMAN)을 설치하는 것이다. 이것을 설치함으로써, TNS Packet의 내용을 올바르게 client에 전달할 수 있다. CMAN은 오라클 9i Enterprise 버전에서 부터 사용할 수 있다.(8i 이하버전은 잘 모르겠다;). 대충 본 문서를 보면 Listener.ora 셋팅하고 비슷한 방법으로 셋팅한다.

두번째 방법은 USE_SHARED_SOCKET 옵션을 활성화시키는 것이다. 이것을 활성화하면 listener가 CMAN과 비슷한 역할을 해준다. 위 그림에서 listener는 4번 단계가 끝나고 나면 client와의 접속을 해제한다. USE_SHARED_SOCKET를 활성화시킴으로써 4번이후에도 연결을 해제하지 않고, 따라서 listener의 정보를 가지고 서버에 접속할수 있게 된다. 이 방법의 단점은 연결시 병목현상이 발생할 수 있다는 것이고, listener가 재시작 되면 기존의 연결이 모두 해제된다(별로 안 좋다. 결국 돈들여서 CMAN을 활용하란 뜻인가보다).

*** 이 문서의 내용은 정확하지 않을 수 있고, 이 방법대로 해서 발생하는 문제는 각자 책임입니다.