14. 통합점 게이트웨이, 터널, 릴레이

14. 통합점: 게이트웨이, 터널, 릴레이

게이트웨이

• 서로 다른 프로토콜과 애플리케이션 간의 HTTP 인터페이스

• 인터프리터와 같이 리소스를 받기 위한 경로를 안내하는 역할

• 요청을 받고 응답을 보내는 포털 같이 동작

• 동적인 컨텐츠를 생성하거나 데이터 베이스에 쿼리를 날릴 수 있다.

  ex) HTTP 클라이언트 ↔ 게이트웨이 ↔ FTP Server

  ex) HTTP 클라이언트 ↔ 게이트웨이(클라이언트 측 보안) ↔ Web Server

  ex) HTTP 클라이언트 ↔ Application Server 게이트웨이 API (App Server ↔ Program)

클라이언트 측 게이트웨이, 서버 측 게이트웨이

• 게이트웨이는 클라이언트 측 protocol과 서버 측 protocol을 ‘ / ‘(빗금)으로 구분한다.

  ex) 게이트웨이가 HTTP 클라이언트와 NNTP 뉴스서버 사이에 있을 시 → HTTP/NNTP

• 클라이언트 측 게이트웨이

  → 서버와는 HTTP 통신

  → 클라이언트와 외래 protocol로 통신

• 서버 측 게이트웨이

  → 클라이언트와는 HTTP 통신

  → 서버와 외래 protocol로 통신

---

프로토콜 게이트웨이

• Proxy에 트래픽을 바로 보내는 것과 같이 게이트웨이에도 HTTP 트래픽을 바로 보낼 수 있다.

• 브라우저에서 명시적으로 설정하여 자연스럽게 트래픽이 게이트웨이를 거쳐가게 하거나, 게이트웨이를 대리 서버(리버스 Proxy)로 설정할 수도 있다.

  ex) 브라우저에서 서버 측 FTP 게이트웨이 설정 예시

  

HTTP/*: 서버 측 웹 게이트웨이

• 클라이언트의 HTTP 요청시 Origin Server의 영역으로 들어오는 순간 외래 prototocol로 변환한다.

  ex) HTTP/FTP

  
  1. User와 PASS 명령을 보내서 서버에 로그인 한다.
  2. Server에서 적절한 디렉터리로 변경하기 위해 CWD 명령을 내린다.
  3. 다운로드 형식을 ASCII(TYPE A)로 설정한다.
  4. MDTM으로 문서의 최근 수정 시간을 가져온다.
  5. PASV로 서버에게 수동형 데이터 검색을 하겠다고 말한다.
  6. RETR으로 객체를 검색한다. (RETRIEVE 검색하다, 읽어오다)
  7. 제어 채널에서 반환된 포트로 FTP 서버에 커넥션을 맺고 채널이 열리는 대로 게이트웨이로 전송한다.

HTTP/HTTPS: 서버 측 보안 게이트웨이

• 웹 요청을 암호화함으로써 개인 정보 보호와 보안을 제공하는 게이트웨이를 사용 할 수 있다.

  

HTTPS/HTTP: 클라이언트 측 보안 가속 게이트웨이(= SSL)

• 게이트웨이가 Web Server 앞단에 위치하고, 보이지 않는 인터셉트 게이트웨이나 리버스 Proxy역할을 한다.

• HTTPS 트래픽을 받아 복호화한 후 HTTP로 요청을 만든다.

  • Server의 과부하를 줄인다.

    

---

리소스 게이트웨이

• 어플리케이션 프로그래밍 인터페이스(API; Application Programming Interface)

  

공용 게이트웨이 인터페이스(CGI; Common Gateway Interface)

• 최초의 API

• URL에 대한 HTTP 요청에 따라 프로그램을 실행하고 출력 하는 등 표준화된 인터페이스 집합

• 사용자는 CGI가 내부적으로 어떻게 동작하는지 알 수 없다.

  • 단, 무언가를 하고 있다는 것을 알 수 있는 건 URL에 “cgi” 또는 “?”같은 단서들 뿐이다.

• Fast CGI

  → CGI와 유사하다.

  → 데몬으로 동작함으로써 요청마다 새로운 프로세스를 만들고 제거하면서 생기는 성능 저하 문제를 해결

  • 데몬

    → OS에서 사용자가 직접 조작하지않고, 백그라운드에서 스스로 동작하는 프로그램

서버 확장 API

• 프로그래머가 자신의 코드를 Server에 연결하거나 서버의 컴포넌트를 자신이 만든 것으로 교체할 수 있다.

---

어플리케이션 인터페이스

• 서로 다른 형식의 웹 애플리케이션이 통신하는 데 사용

• 웹 서비스

  • 독립형 웹 애플리케이션(빌딩 블록) 그 자체를 의미

    → 하지만, 웹 애플리케이션이 서로 통신하는데 사용할 표준과 프로토콜 집합으로써 불린다….

  • 웹 서비스는 HTTP 같은 표준 웹 기술 위에서 개발한다.

  • SOAP을 통해 XML을 사용하여 정보를 교환한다.

    • SOAP(Simple Object Access Protocol)

      → HTTP 메시지에 XML 데이터를 담는 방식에 관한 표준

    • XML(eXtensible Markup Language)

      → 데이터 객체를 담는 데이터를 생성하고 해석하는 방식을 제공

---

터널

• HTTP를 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공
• HTTP커넥션을 통해서 HTTP가 아닌 트래픽을 전송할 수 있고 다른 프로토콜을 HTTP위에 올릴 수 있다.
  • 웹 트래픽만을 허락하는 방화벽이 있더라도 HTTP가 아닌 트래픽을 전송 할 수 있다.

CONNECT로 HTTP 터널 커넥션 맺기

• 터널 게이트웨이가 임의의 목적 서버와 포트에 TCP커넥션을 맺고 클라이언트와 서버간에 오는 데이터를 무조건 전달하기를 요청한다.

• CONNECT 요청

  • 시작줄을 제외하고는 다른 HTTP 메서드와 같다.

  • 요청 URI는 호스트명이 대신하며 콜론에 이어 포트를 기술한다.

      CONNET ordrs.joes-hardware.com:433 HTTP/1.0
      User-agent: SuperBrowser: 4.2

• CONNECT 응답

  • 응답 코드 200은 성공을 뜻한다.
  • 편의상 사유 구절은 “Connection Established”로 기술한다.
  • 일반적인 HTTP응답과는 달리 Content-Type 헤더를 포함할 필요는 없다.

데이터 터널링, 시간, 커넥션 관리

• 터널로 전달되는 데이터는 게이트웨이에서 볼 수 없어서 패킷의 순서나 흐름에 대한 어떤 가정도 할 수 없다.
  • 터널이 일단 연결되면, 데이터는 언제 어디로든 흘러 갈 수 있다.
• 클라이언트는 CONNECT 요청을 보낸 후, 응답을 받기 전에 터널 데이터를 전송할 수 있다.
  • 하지만, 게이트웨이가 요청에 이어서 데이터를 적절하게 처리할 수 있어야함을 전제로 한다.
  • 게이트웨이는 네트워크 I/O 요청이 헤더 데이터만을 반환해줄 거라고 가정 할 수 없기 때문이다.
• 터널의 끝날에서 커넥션이 끊어지면, 그 끊어진 곳으로 부터 온 데이터는 반대편으로 전달된다.
  • 그 후, 커넥션이 끊어졌던 터널의 끝단 반대편의 커넥션도 프락시에 의해서 끊어질 것이다.
  • 하지만, 끊어진 이후 데이터인 아직 전송하지 않은 데이터는 버려진다.

SSL 터널링

• 웹 터널은 원래 방향벽을 통해서 암호화된 SSL 트래픽을 전달하려는 용도로 만들어 졌다.
• 터널은 HTTP가 아닌 트래픽이 포트를 제한하는 방화벽을 통과할 수 있게 해주지만, 악의적인 트래픽이 사내로 유입될 가능성이 있다.

ex) SSL같이 암호화된 프로토콜은 정보를 알 수 없어 필터링 라우터를 통해 낡은 Proxy에서 처리되지 않는다.

하지만, 터널을 사용하면 SSL트래픽을 80포트의 HTTP만을 허용하는 방화벽을 통과시킬 수 있다.

ex) 보안 웹 서버로 SSL트래픽이 바로 전송될 수도 있다.(SSL 포트인 443으로)

ex) SSL트래픽은 일반 SSL 커넥션을 통해 전송되기 전까지는 HTTP 메시지에 담겨 80 포트에 전송된다.

SSL 터널링 vs HTTP/HTTPS 게이트웨이

• HTTP/HTTPS의 단점

  1. 클라이언트 : 게이트웨이 사이에는 보안이 적용되지 않은 일반 HTTP 커넥션이 맺어져 있다.

  2. Proxy가 인증을 담당하고 있어, 클라이언트는 원격 서버에 SSL 클라이언트 인증을 할 수 없다.

     • SSL 클라이언트 인증

       → X509 인증서 기반의 인증

  3. 게이트웨이는 SSL을 완벽하게 지원해야 한다.

• SSL 터널링을 사용하면 프락시에 SSL을 구현할 필요가 없다.

터널 인증

• HTTP의 다른 기능들과 터널을 조합해서 사용 할 수 있다.

  ex) Proxy 인증 기능을 이용한 터널 사용 가능 여부

  

터널 보안에 대한 고려사항

• 보통, 터널 게이트웨이는 통신하고 있는 protocol이 올바른 용도로 사용하고 있는지 검증할 방법이 없다.

  ex) 회사 직원이 게임을 하려고 회사 방화벽에 터널을 만들어 게임 트래픽을 사내로 유입시킬 수 있다.

  ex) 회사에 텔넷 세션을 열거나 회사의 이메일 차단 장치를 우회하려고 터널을 사용할 수 있다.

• 게이트웨이는 HTTPS 전용 포트인 433 같이 잘 알려진 특정 포트만을 터널링할 수 있게 허용해야 한다.

  • 오용을 막기 위하여!!

---

릴레이

• 일종의 단순한 HTTP Proxy로, 한번에 한개의 홉에 데이터를 전달하는데 사용

• HTTP 명세를 완전히 준수하지 않는 간단한 HTTP Proxy

• 커넥션을 맺기 위한 HTTP 통신을 한 후, 바이트를 맹목적으로 전달한다.

  • 일반적인(악명 높은) 문제 중 하나는, 릴레이가 Connection헤더를 제대로 처리하지 못해 keep-alive 커넥션 행(hang)이 걸리는 것이다….

    ex) hang, hang, hang!!

    

  (위에 명시된 알파벳과 순서는 무관하다.)

  1. 클라이언트는 Connection: Keep-Alive 헤더를 보내서 릴레이에 요청 메시지를 전송 후 대기한다.
  2. 릴레이가 요청을 받지만 Connection헤더를 이해하지 못해 서버로 그냥 넘긴다.
     • BUT!! Connection 헤더는 홉바이홉 헤더이므로 문제가 여기서 발생하기 시작한다.
  3. Keep-Alive를 받은 Server는 릴레이가 Keep-Alive하기를 원한다고 잘못된 결론을 도출한다.
  4. Server는 Keep-Alive에 동의한다고 응답하지만, 릴레이는 이것을 알아듣지 못하고 전송한다.
  5. 릴레이로부터 Keep-Alive를 받은 클라이언트는 릴레이가 Keep-Alive에 동의한 것으로 간주한다.
     • 이 시점에서 클라이언트는 Server와 Keep-Alive로 통신한다고 믿지만 릴레이는 모르는 일…
  6. 릴레이는 Server가 Connection을 끊기를 기다리고 Server는 Keep-Alive를 유지하게 된다.
     • 이 과정에서 Connection을 맺고(hang) 있을 것이다.
  7. 클라이언트가 응답 메시지를 받으면, 바로 다음 요청을 Keep-Alive 커넥션을 통해 릴레이에게 전송하는데, 단순한 릴레이는 같은 커넥션으로 또 다른 요청이 오는 것을 예측하지 못한다. 브라우저는 계속 돌고있지만, 아무런 작업도 진행되지 않는 현상이 발생한다.

• 위 예시를 예방하기 위해 릴레이를 조금이나마 똑똑하게 만드는 방법이 있다.

  • 하지만, Proxy의 단순함 이면에는 상호 운용과 관련한 문제가 발생할 위험이 있다.

• 만약 단순한 HTTP 릴레이를 구축한다면, 신중히 고민하여 여러 문제를 예방해야 한다.

  • 웬만하면 HTTP를 제대로 준수하는 프락시를 사용하는게 좋다.