[네트워크] 5. 서버측의 LAN에는 무엇이 있는가?

 

성공과 실패를 결정하는 1%의 네트워크 원리 | Tsutomu Tone - 교보문고

 

목차

• 웹 서버의 설치 장소
• 방화벽의 원리와 동작
• 복수 서버에 리퀘스트를 분배한 서버의 부하 분산
• 캐시 서버를 이용한 서버의 부하 분산
• 콘텐츠 배포 서비스

 

웹 서버의 설치 장소

---

1. 사내에 웹 서버를 설치하는 경우

사내의 LAN에 서버를 설치하고 인터넷에서 직접 액세스하는 경우다.

• 현재 이 방법은 주류에서 밀렸다.
  • IP 주소의 부족 : 이 형태에선 클라이언트에도 글로벌 주소를 할당해야 하는데 그럴 여유가 없다.
  • 보안 : 이 형태는 인터넷에서 도착하는 패킷을 차단하지 않아, 서버는 노출 상태로 공격자에게 방치된다.

방화벽을 두는 방법

• 현재 가장 일반화된 방법이다.
• 방화벽은 관문 역할을 해 특정 서버에서 동작하는 특정 애플리케이션에 액세스하는 패킷만 통과시킨다.
• 나머지 패킷은 다 차단시킨다.
• 위험성이 완전히 없어지진 않지만, 보안이 전부 무방비 상태가 되는 것에 비해 위험성이 크게 낮아지는 효용성이 있다.
• 현재는 빠져나가는 공격 수법이 많아져 다른 구조를 함께 사용한다.

2. 데이터센터에 웹 서버를 설치하는 경우

프로바이더 등이 운영하는 데이터센터라는 시설에 서버를 설치하거나, 프로바이더가 소유하는 서버를 빌려쓰는 형태다.

• 프로바이더 : 인터넷 및 네트워크 접속에 필요한 대역을 서비스하는 사업자
• 회사 안보다 안전성이 높다.
• 서버의 설치 장소 제공뿐만 아니라 기기의 가동 상태 감시, 방화벽 설치 운영 등 부가 서비스를 제공할 수 있다.

 

방화벽의 원리와 동작

---

1. 패킷 필터링형이 주류이다.

네트워크에는 다양한 종류의 패킷이 많이 흐른다.
이 중 통과시킬 패킷과 차단할 패킷을 선별하는 많은 방법 중 성능, 가격, 사용 편의성 등의 이유로 패킷 필터링형이 가장 많이 보급되었다.

 

2. 패킷 필터링의 조건 설정 개념

패킷의 헤더에 있는 제어 정보를 통해 패킷 필터링의 조건 설정에 사용한다.

• p.339 : 주소변환 및 패킷 필터링 조건 설정에 이용하는 항목
• 패킷 필터링의 조건을 설정할 땐, 패킷의 흐름에 착안한다.
• 수신처 IP 주소와 송신처 IP 주소에 따라 시점과 종점을 판단한다.
• 시점은 지정할 수도 있고 없을수도 있지만, 흐름의 종점은 판단할 수 있다.
• 즉, 시점(송신처 IP 주소)은 어디라도 상관 없으므로, 종점 (수신처 IP 주소)이 웹 서버의 IP 주소에 일치하는 패킷은 통과시킨다는 조건을 설정한다.
• 패킷을 받으면 정확히 도착했는지 송신측에 알릴 패킷을 보낼 때, 웹 서버에서 인터넷으로 나가는 패킷 중 시점(송신처 IP)이 웹 서버 IP인 경우 통과시킨다.

 

3. 애플리케이션을 한정할 때 포트 번호를 사용한다.

• 앞의 조건 뿐이면, 인터넷과 웹 서버 사이를 흐르는 패킷은 전부 통과해 위험한 상태가 된다.
• 그러므로, 불필요한 애플리케이션의 패킷은 전부 차단한다.
• 애플리케이션을 한정할 땐, TCP / UDP 헤더에 기록된 포트 번호를 조건으로 추가한다.
• 예를 들어, 웹 서버인 경우 포트 번호가 80인 조건이 추가된다.

 

4. 컨트롤 비트로 접속 방향을 판단한다.

• 패킷은 TCP 프로토콜을 사용해 양방향으로 흐르므로, 한 쪽을 정지시키면 다른 쪽도 정지된다.
• 따라서 TCP 헤더에 컨트롤 비트를 활용해, 허가하는 액세스 동작에서 흐르는 패킷과 그 외의 패킷을 선별할 수 있을 때까지 조건을 추가한다. ex) p.343
• 그러나, UDP를 사용하는 애플리케이션의 패킷은 통과시키는 것과 차단하는 것을 완전히 선별할 수 없는 경우도 있다.
• 이 경우 어느 정도 위험을 각오한 상태에서 애플리케이션의 패킷을 전부 통과시키거나, 불편을 감수하고 애플리케이션을 전면적으로 차단하는 방법을 선택한다.

 

5. 사내 LAN에서 공개 서버용 LAN으로 조건을 설정한다.

인터넷과 공개 서버용 LAN을 왕래하는 패킷의 조건을 설정할 뿐 아니라, 사내 LAN과 인터넷, 사내 LAN과 공개 서버용 LAN을 왕래하는 패킷의 조건도 설정해야 한다.

이때 조건이 서로 악영향을 끼친다면, LAN에 설치한 서버 전부가 위험한 상태가 되므로 이런 사태가 발생하지 않도록 신중하게 조건을 설정해야 한다.

 

6.  밖에서 사내 LAN으로 액세스할 수 없다.

• 패킷 필터링형 방화벽은 주소 변환의 기능도 가지고 있어 설정도 필요하다.
• 앞의 예에서 인터넷과 사내 LAN을 왕래하는 패킷은 주소 변환을 해야하므로, 설정이 필요하다.
• 패킷의 시점과 종점을 조건으로 지정한 후, 주소 변환이 필요한 경우 주소 변환을 하고 아니면 변환하지 않도록 설정한다.
• 주소변환을 하지 않으면, 인터넷의 라우터 경로표엔 private 주소를 등록하지 않아 인터넷의 라우터는 패킷을 중계하지 않고 버린다.

 

7. 방화벽을 통과한다.

• 방화벽에 설정된 여러가지 조건을 통햏, 패킷을 판정하고 통과시킬지 차단시킬지를 결정한다.
• 버린 기록을 남기기도 하는데, 부정 침입의 흔적을 나타내는 것을 분석해 침입자의 수법을 밝히거나, 향후 부정 침입 대책에 도움이 될 수 있기 때문이다.
• 통과시킨 후엔 라우터와 비슷하게 중계한다.
• 단, 판정 조건이 복잡해지면 라우터에 부담이 큰 작업이 되기 때문에, 전용 하드웨어나 소프트웨어를 사용한다.

 

8. 방화벽으로 막을 수 없는 공격

방화벽은 패킷 흐름의 시점과 종점을 보고 통과 여부를 판단하기 때문에 위험한 패킷을 전부 판단할 수 없다.

ex) 웹 서버에 좋지 않은 상태가 있어, 특수한 데이터를 받으면 웹 서버가 다운된다.
그러나, 시점과 종점만 조사하므로 특수한 데이터가 포함된지는 신경쓰지 않고 통과시켜 버린다.

두 가지 대처법

• 웹 서버 소프트웨어의 버그를 고쳐서 다운되지 않도록 한다.
• 패킷의 내용을 조사해 위험한 데이터가 포함되어 있는 경우 패킷을 차단하도록 장치나 소프트웨어 방화벽과는 별도로 준비한다.
  • 미지의 위험성에는 대처할 수 없지만, 버그를 고친 새로운 버전으로 업데이트를 미루거나 잊어버릴 경우 내용을 검사하는 것은 효과가 있다.

 

복수 서버에 리퀘스트를 분배한 서버의 부하 분산

---

1. 처리 능력이 부족하면 복수 서버로 부하 분산된다.

서버에 액세스가 증가할 때 회선을 고속화해도 대량의 패킷을 서버의 처리능력이 따라잡지 못할 수 있다.
서버 머신을 고성능 기종으로 교체해도, 다수의 사용자가 집중적으로 액세스하면 한 대로는 따라잡지 못할 수 있다.

이 때 복수의 서버를 사용해 처리를 분담하는 방법으로 서버 한 대당 처리량을 줄이는 처리 방법 통틀어 분산 처리라고 한다.

• 가장 간단한 방법은 단순히 여러 대의 웹 서버를 설치해 한 대가 담당하는 사용자 수를 줄이는 것이다.
• 클라이언트가 보내는 리퀘스트를 웹 서버에 분배하는 방법이 필요한데, 가장 간단한 것은 DNS 서버에서 분배하는 것이다.
• DNS 서버에 같은 이름으로 웹 서버를 등록해 조회가 있을 때마 차례대로 IP 주소를 돌려준다. (ex. 라운드로빈)
• 그러나, 웹 서버가 고장나는 경우 DNS 서버는 웹 서버가 동작하지 않는지 확인하지 못하므로, 상관 않고 IP 주소를 회답해 버린다.

 

2. 부하 분산 장치를 이용해 복수의 웹 서버로 분할된다.

앞의 좋지 않은 상태를 피하기 위해 부하 분산 장치 또는 로드 밸런서 등으로 부르는 기기를 사용한다.

• 부하 분산 장치의 IP 주소를 웹 서버 대신 DNS 서버에 등록한다.
• 부하 분산 장치에서 연결된 서버의 부하 상태를 확인하고, 요청을 분배한다.
  • 웹 서버 부하는 단시간에 증가하거나 감소하므로 꼼꼼히 조사해야하지만, 너무 자세히 조사하려 하면, 조사 동작 자체로 웹 서버 부하가 증가할 수 있다.
• 대화가 복수의 페이지에 걸쳐있는 경우, 이전 요청과 같은 서버로 요청을 보낸다.
• HTTP는 stateless해 전후 관계를 판단하기 어렵다.
• 판단을 위해 웹 서버에서 정보를 유지하면, 웹 서버에 부담이 간다.
• 현재는 HTTP 헤더 필드에 정보를 추가할 수 있도록 하거나, 데이터가 전후 관계를 확인할 수 있는 정보를 부가하는 방법을 사용한다.

 

캐시 서버를 이용한 서버의 부하 분산

---

1. 캐시 서버의 이용

• 데이터베이스 서버와 웹 서버 같은 역할에 따라 서버를 나누는 방법으로, 역할별 분산처리 방법 중 하나가 캐시 서버를 사용하는 방법이다.
• 캐시 서버 : 프록시라는 구조를 사용해 데이터를 캐시에 저장하는 서버다.
• 프록시 : 웹 서버와 클라이언트 사이에 들어가 웹 서버에 대한 액세스 동작을 중개하는 역할을 한다.
  • 액세스 동작을 중개할 때, 웹 서버에서 받은 데이터를 디스크에 저장해두고 웹 서버를 대신해 데이터를 클라이언트에 반송하는 기능을 가지고 있다.
  • 캐시 서버쪽은 웹 서버에서 받아 보존해둔 데이터를 읽어 클라이언트에 송신만 하므로 웹 서버보다 빨리 데이터를 송신한다.
• 웹 서버측에서 데이터가 변경되면 캐시의 데이터를 사용할 수 없다.
• 그러나 액세스 동작의 일정 부분은 웹 서버를 번거롭게 하지 않고 캐시 서버에서 처리할 수 있다.

 

2. 캐시 서버는 갱신일로 콘텐츠를 관리한다.

• 캐시 서버를 사용할 땐, 캐시 서버를 웹 서버 대신 DNS 서버에 등록한다.
• 사용자는 캐시 서버에 HTTP 리퀘스트 메시지를 보낸다.
• 캐시 서버는 접속을 기다리는 패킷을 만들고, 여기에 사용자가 접속하면 접속 동작을 실행해, 리퀘스트 메시지를 받는다.
• 캐시 서버는 리퀘스트 메시지를 받으면 내용을 조사하고, 데이터가 자신의 캐시에 저장되었는지 조사한다.

• 캐시 서버에 저장되지 않은 경우
  1. Via 헤더 필드를 추가해 캐시 서버를 경유한 것을 나타낸다.
  2. 웹 서버에 리퀘스트를 전송한다.
     • 여러대의 서버가 캐시 서버에 연결된 경우, URI에 따라 웹 서버로 요청을 전송한다.
  3. 웹서버에서 캐시 서버로 응답을 보내고, 캐시 서버는 Via 헤더를 추가해 클라이언트에게 응답한다.
  4. 응답에 대한 메시지를 캐시 서버에 저장하고, 저장한 일시를 기록한다.
• 캐시 서버에 저장된 경우
  1. 해당 데이터가 변경 되지는 않았는지 확인하는 If-Modified-Since 헤더 필드를 추가해 웹 서버에 전송한다.
  2. 웹 서버는 변경이 없다면, 없다는 응답 메시지를 반송한다. 이때 최종 갱신 일시를 조사하고 끝나므로, 데이터 반송의 부담이 적어진다.
  3. 서버는 캐시에서 데이터를 추출해 사용자에게 보낸다.
• 데이터가 변경된 경우는, 저장되지 않은 경우와 같다.

이렇듯 클라이언트와 웹 서버 사이를 중개하는 것이 프록시 구조다.

 

3. 프록시의 원점은 포워드 프록시이다.

앞의 예시는 웹 서버측에 캐시 서버를 두는 것이었다.

• 포워드 프록시 : 클라이언트측에 캐시 서버를 두는 것이다.
• 캐시를 이용하는 목적은 같지만, 추가로 방화벽을 실현한다는 목적이 있다.
  • 프록시에서 리퀘스트 메시지를 일단 받아 인터넷을 향해 전송하면, 필요한 것을 통과시킬 수 있다는 개념이다.
  • 이 때 프록시의 캐시를 이용하면, 사내 LAN에서 프록시에 액세스하면 데이터를 손에 놓을 수 있으므로, 저속 회선에서 인터넷에 액세스하는 것보다 매우 빨라진다.
• 포워드 프록시를 사용할 경우, 브라우저의 설정 화면에 준비된 프록시 서버라는 항목에 포워드 프록시의 IP 주소를 설정한다.
• 리퀘스트 메시지 송신 동작 다름 : 포워드 프록시를 설정하면, URL 입력 상자에 입력된 모든 문자열을 액세스 대상을 계산하지 않고, URI에 기록한다.
• 메시지 전송 동작 다름 : 서버측에 두는 캐시 서버처럼 전송 대상의 웹 서버를 사전에 설정할 필요 없이, 모든 웹 서버에 전송할 수 있다.

 

4. 포워드 프록시를 개량한 리버스 프록시

포워드 프록시는 브라우저에 대한 설정이 꼭 필요한데, 설정을 잘못할 경우 장애의 원인이 되기도 한다.
이에 따라 브라우저에 프록시를 설정하지 않아도 사용 가능하게 개량되었다.

즉, 리퀘스트 메시지의 URI에 쓰인 전체 URL이 아닌, 디렉토리명과 전송 대상의 웹 서버를 대응시켜 전송할 수 있도록 했다.
이것이 서버 측에 설치하는 캐시 서버에 채택하고 있는 방식으로, 리버스 프록시라고 부른다.

 

5. 트랜스페어런트 프록시

캐시 서버가 전송 대상을 판단하는 방법 : 패킷의 맨 앞에 있는 IP 헤더에 기록된 수신처 IP 주소를 조사해, 액세스 대상 웹 서버가 어디 있는지 알 수 있다.

이를 트랜스페어런트 프록시라고 한다.

• 이 방법은 보통의 리퀘스트 메시지를 전송할 수 있으므로, 포워드 프록시처럼 브라우저에 설정할 필요가 없다.
• 전송 대상을 캐시 서버에 설정할 필요 없이, 어느 웹 서버에나 전송 가능하다.
• 트랜스페어런트 프록시는 브라우저에 설정하지도 않고, DNS 서버에 등록하지도 않는다.
• 따라서 브라우저에서 웹 서버로 요청 메시지가 흘러가는 길에 설치해두고, 메시지가 트랜스페어런트 프록시를 지나갈 때 그것을 가로챈다.
• 때문에 보통 길이 한 개로 수렴하는 형태로 네트워크를 만들고, 수렴되는 곳에 트랜스페어런트 프록시를 설치한다.
• 길마다 설치해야할 수도 있다.

 

콘텐츠 배포 서비스

---

1. 콘텐츠 배포 서비스(CDS, Content Delivery Service)를 이용한 부하 분산

• 캐시 서버는 서버측에 두는 경우와, 클라이언트측에 두는 경우 이용효과가 차이난다.
  • 서버측에 두면, 웹 서버의 부하를 경감하는 효과가 있다.
  • 클라이언트측에 두면, 인터넷에서 들어오는 트래픽을 억제할 수 있다.
• 그러나, 클라이언트측에 캐시 서버를 두면, 웹 서버 개발자가 용량을 늘리는 등의 제어를 할 수 없다.
• 해결책으로 프로바이더와 계약해, 웹 서버 개발자가 제어할 수 있는 클라이언트와 가까이 있는 캐시 서버를 이용하는 것이다.
• 그러나, 인터넷의 어디에서 액세스하는지 서버는 알 수 없기 때문에, 프로바이더의 POP 전부에 캐시 서버를 설치해야하는데 수가 너무 많아 이는 비현실적이다.
• 따라서 중요한 프로바이더에 중점을 두어 캐시 서버 수를 줄인다. 사용자에 따라 캐시 서버에 도착하는 것이 오래걸릴 수 있지만, 웹 서버에서 직접 액세스하는 것보단 여정이 단축된다.
• 콘텐츠 배포 서비스 (CDS)
  • 캐시 서버를 설치하고, 웹서버 운영자에게 대출하는 서비스를 제공하는 사업자다.
  • 웹 서버 운영자가 스스로 프로바이더와 계약해 캐시서버를 설치하는 것은 비용, 노력면에서 어렵다.

 

2. 가장 가까운 캐시 서버의 관점

콘텐츠 배포 서비스를 사용하기 위해, 클라이언트가 가장 가까운 캐시 서버를 찾아야한다.

최초 방법

• DNS 서버가 웹 서버의 IP 주소를 회답할 때, 가장 가까운 캐시 서버의 IP 주소를 회답하도록 DNS 서버를 세밀하게 설정하는 방법이다.
  • 앞서 나온 라운드로빈에 의해, 캐시 서버의 위치 관계는 전혀 고려되지 않을 수 있다.
• 따라서 클라이언트와 캐시 서버의 거리를 판단하는 방법은 다음과 같다.
  • 캐시 서버의 설치 장소에 있는 라우터에서, 경로 정보를 모은다.
  • 경로표를 사용해 DNS의 조회 메시지의 송신처, 즉 클라이언트측의 DNS 서버에 이르는 겨올 정보를 조사한다.
  • 이것을 모든 라우터에 대해 조사하고 비교하면, 정확하지 않지만, 어느 라우터가 가장 가까운지 알 수 있다.

 

3. 리피터용 서버로 액세스 대상을 분배한다.

두 번째 방법

• HTTP 사양에서 Location 헤더를 사용해, 액세스 대상을 가까운 캐시 서버로 돌리는 리다이렉트(redirect)를 나타낸다.
• 이것을 사용해 액세스 대상을 가장 가까운 캐시 서버로 돌리는 것이 또 다른 방법이다.
  • 리다이렉트용 서버를 웹 서버측의 DNS 서버에 등록한다.
  • 리다이렉트용 서버에는 DNS 서버와 같이 라우터에서 모은 경로 정보가 있어, 가장 가까운 캐시 서버를 찾는다.
  • 그리고 캐시 서버를 나타내는 Location 헤더를 붙여 응답을 돌려보내면, 클라이언트는 캐시 서버에 다시 액세스한다.
• HTTP 메시지 대화가 증가하므로 오버헤드가 많다.
• 하지만, 리다이렉트는 클라이언트가 보내는 HTTP 메시지의 송신처 IP 주소를 바탕으로 거리를 판단해 정밀도가 높다.

+++ 더 정확한 거리를 알기 위해, 최적의 캐시 서버에 액세스하는 스크립트 프로그램을 내장한 페이지를 반송하는 방법도 있다.

 

4. 캐시 내용의 갱신 방법에서 성능의 차이가 난다.

• 최초의 액세스 동작에는 도움이 되지 않고, 캐시 서버를 이용할 때 갱신 유무를 확인하는 동작에 혼잡해질 수 있다.
• 웹 서버에서 원래 데이터를 갱신할 경우, 즉시 캐시 서버에 반영된다면 캐시 데이터는 항사 최신 상태를 유지할 수 있다.
• 따라서 원래 데이터의 갱신을 확인할 필요가 없게 되고, 최초의 액세스 동작도 캐시의 데이터를 이용할 수 있다.
• 또 동적인 부분과 아닌 부분을 구분해, 동적이지 않은 부분만 캐시에 저장해야한다.