[Network] 네트워크 원리(5) 서버측의 LAN에는 무엇이 있는가?

개요

성공과 실패를 결정하는 1% 네트워크 원리를 공부하고 정리한 글이다.

Chapter 5 - 방화벽과 캐시 서버의 탐험

 

---

 

 

STORY 1 | 웹 서버의 설치 장소

---

1-1) 사내에 설치

클라이언트의 POP/프로바이더로부터 오는 패킷을 방화벽에서 한 번 거르는 방법이 보편화되어 있다.

• 특정 서버에서 동작하는 특정 애플리케이션에 액세스하는 패킷만 통과시키고, 그 외 패킷은 모두 차단한다.
• 액세스를 허가한 애플리케이션에 보안 구멍이 있을 수 있지만, 클 to 서구조에 비하면 위험성이 낮다.
• 현재는 이 구조를 빠져나가는 다양한 수법이 많이 생겨셔 더불어서 바이러스 검사, 부정 침입 검사 등의 구조를 함께 사용한다.

 

1-2) 데이터 센터에 설치

데이터 센터로부터 서버를 빌리는 형식

• 데이터 센터는 프로바이더의 중심인 NOC에 접속되어 있거나, IX와 직접 연결되어 있기도 해서 고속 접근이 가능하다.
• 내진 구조의 건물 / 자가 발전 장치 / 24시간 관리되는 시설이 많으므로 안정성이 높다.

 

STORY | 방화벽의 원리와 동작

---

2-1) 패킷 필터링형이 주류이다

네트워크 상에는 다양한 패킷이 흐르므로… 이를 분별하는게 쉽진 않았다.
→ 패킷 필터링이 성능, 가격, 편의성 등에서 가장 많이 보급되었다.

 

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

패킷의 헤더 통신과 관련한 여러 제어 정보가 있다. 이 헤더로 필터링한다.

 

■ 사내 랜과 공개 랜이 분리되어 있고, 웹 서버에서 인터넷측에 액세스하는 것을 금지하고 있는 상황에서 패킷의 움직임

1. 송수신처 IP 주소로 시종점을 판단한다.
2. 인터넷 → 웹 서버로 보내는 패킷의 송신처(시작점)은 정확히 알 수 없다. 하지만 종점이 웹 서버라는 점이 명확하므로, 시점이 어디든 상관없이 웹 서버의 IP 주소에 일치하는 패킷은 통과시킨다는 조건을 설정하면 된다.
3. 받은 패킷에 대한 ACK(수신 확인 응답)을 보낸다.

 

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

수선처의 IP 주소 + 포트 번호를 함께 확인해서 일치하는 패킷만 통과하도록 한다. 

 

2-4) 컨트롤 비트로 접속 방향을 판단한다 - TCP의 SYN, ACK

TCP를 사용하는 웹은 양방향으로 패킷이 흐른다.

그래서 단순히 웹 서버 → 인터넷으로 흐르는 패킷을 정지시키면, 인터넷 → 웹 서버 액세스 동작도 정지된다.

 

 

■ 웹 서버 → 인터넷 통신 막기

패킷의 액세스 방향을 판단하여 정지시켜야 하는데, 이를 TCP 헤더의 컨트롤 비트로 판단한다.

TCP의 최초의 패킷만 SYN=1, ACK=0이 헤더에 설정된다. 따라서 이 헤더의 컨트롤비트 값을 확인하고, 최초의 패킷이면서 수신처가 인터넷, 송신처가 웹 서버라면 이것을 차단하도록 설정한다. 그럼 최초의 패킷에 대한 전송이 실패하고 그에 따라 두 번째 SYN, ACK를 받을 수 없으므로 TCP connection에 실패하여 통신이 불가능해진다.

 

■ 인터넷 → 웹 서버 패킷은?

최초의 패킷은 수신처가 웹 서버이고 컨트롤 비트를 확인했을 때 최초의 패킷이므로 패킷 필터링을 통과한다. 두 번째 패킷은 송신처가 웹 서버이지만 컨트롤 비트 값이 바뀌었기에 최초값으로 추정되지 않고 패킷 필터링을 잘 통과하여 통신에 성공한다.

 

■ UDP는 TCP와 달리 접속관계(SYN, ACK)가 없어서 액세스 방향 판단이 불가능하다.

• 어느 정도 위험을 각오한 상태에서 애플리케이션의 패킷을 전부 통과
• 불편을 감수하고 애플리케이션을 전면적으로 차단

 

2-5) 사내 LAN에서 공개 서버용 LAN으로 조건 설정

사내 LAN ↔ 공개 서버용 LAN 각각의 IP 주소를 양쪽 모두 잘 설정해주어야 한다.

 

❓ 2-6) 밖에서 사내 LAN으로 액세스 할 수 없다

■ 패킷 필터링형 방화벽은 주소 변환의 기능도 가지고 있다.

사내 LAN ↔ 인터넷을 왕래하는 패킷은 주소 변환이 필요하다. 인터넷에 있는 라우터는 Private 주소를 테이블에 등록하지 않기 때문이다. 따라서 이 구조의 패킷 통신에서는 주소 변환이 필요하다. → 주소 변환을 할 지/ 하지않을 지에 대해 설정해주면 된다.

• 패킷 필터링형 방화벽의 내장 라우터는 Private 주소도 OK.

 

2-7) 방화벽을 통과한다

• 조건에 따라 차단 대상이 된 패킷은 버리고, 버린 기록을 남긴다. 이를 분석하여 침입자의 수법 확인, 향후 부정 침입에 대한 대책 등으로 보안을 강화한다.
• 통과된 패킷의 중계 동작은 라우터의 동작과 같다. → 라우터에 부가기능을 넣은 것과 같다고 생각하자.

 

2-8) 방화벽으로 막을 수 없는 공격

■ 웹 서버에 취약점이 있어 특수한 데이터를 포함한 패킷을 받으면 서버가 다운되는 상황일 때

방화벽에 설정한 송수신 IP와 포트만 확인한다. 패킷의 데이터는 전혀 고려하지 않기에 방화벽은 이러한 구조에 대처할 수 없다.

 

대처법은?

1. 웹 서버의 취약점/버그 고치기
2. 패킷 내용을 조사하여 해당 데이터가 포함된 패킷을 차단하는 장치를 별도로 두기
3. 미지의 위험성은 완벽히 대처하기 어렵다

 

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

---

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

■ 서버에 액세스가 증가할 때

1. 회선을 빠르게 하기 → 서버의 처리 능력이 따라잡지 못할 수 있다.
2. 서버 머신을 고성능으로 교체하기 → 한계가 있다.
3. ⇒ 복수 서버를 사용하여 서버 한 대당 처리량을 줄인다.

 

■ 여러 대의 웹 서버를 설치하고 한 대가 담당하는 사용자 수를 줄인다.

 

DNS 서버에서 분배

• DNS 서버에 같은 이름으로 여러 대의 웹 서버를 등록한다. DNS 서버는 조회가 있을 때마다 차례대로 IP 주소를 되돌려 준다. ⇒ 라운드 로빈
  1. 192.0.2.60 → 192.0.2.70 → 192.0.2.80
  2. 192.0.2.70 → 192.0.2.80 → 192.0.2.60
  3. 192.0.2.80 → 192.0.2.60 → 192.0.2.70
• DNS는 웹 서버의 상태를 확인하지 않고 중계만 하므로, 웹 서버가 중단/고장된 상황에 대응하기 어렵다.
• 라운드 로빈을 통해 웹 서버를 분배하면 웹 사이트의 연속성이 끊긴다. 예를 들어서, 첫 번째 페이지에서 성명 입력 후에 두 번째 페이지에서 신용카드 번호를 입력하는 케이스가 있다.
• TO-DO : GCP LB 라운드 로빈….

 

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

부하 분산 장치 IP를 웹 서버 IP 대신 DNS에 등록한다.

 

■ 대화가 복수의 페이지에 걸쳐있다면…

HTTP stateless: HTTP의 기본 동작은 먼저 Request Message를 보내기 전에 TCP 연결을 하고, 전송이 끝나면 연결을 끊는다.
Cookie: HTTP 전후 관계를 파악하기 위한 값을 HTTP 헤더 필드에 부가하는 방법이 고안되었다.

 

 

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

---

4-1) 캐시 서버의 이용

■ 캐시 서버는 프록시 구조를 사용하여 데이터를 캐시에 저장하는 서버다.

캐시 서버는 웹 서버의 데이터를 디스크에 저장한다. 이후, 클라이언트에서 요청이 오면 이를 확인해서 바로 송신한다. 즉 데이터를 읽고 송신만 하므로 서버보다 빠르다.

 

■ 캐시 서버 또한, 부하 분산처럼 웹 서버 대신 DNS에 캐시 서버 IP를 등록한다.

 

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

■ 두 가지 케이스

저장되어 있든 없든, 일단 리퀘스트를 전송하는 것까진 동일하다!

 

■ 데이터가 캐시 서버에 저장되어 있지 않은 경우

• 헤더 중에 Via 필드 & URI의 디렉토리(어떤 웹 서버에 캐시 정보를 요청해야 할 지 판단)→ URI의 디렉토리를 보고, 리퀘스트 주인이 어느 웹 서버인지 판단하여 소켓 통신을 한다. → 캐시 서버는 요청을 받으면 ‘Via’ 헤더 필드를 추가하여 웹 서버에 리퀘스트를 보낸다.

• 캐시에 데이터가 없으면 ‘If-Modified-Since’를 추가하지 않고 그대로 요청을 보내서 웹 서버는 데이터를 그대로 전송해준다. 이후, 캐시 서버는 이 내용들을 캐시로 저장해둔다.

 

■ 데이터가 캐시 서버에 저장되어 있는 경우

 

‘If-Modified-Since’ 필드를 통해서 캐시: “이때의 값을 디스크에 저장하고 있다.” 라고 알린다. 서버는 이 값을 확인하고, 변경이 없었던 경우에는 304 Not Modified를 보내준다. → 이때 서버는 데이터의 최종 갱신 일시를 조사하는 것으로 끝나고, 응답 메시지 내용도 짧아서 부담이 훨씬 적어진다.

데이터가 변경된 경우, 웹 서버는 최신 데이터를 반송한다. 캐시서버는 ‘Via’ 헤더를 추가하여 사용자에게 전송하고 데이터를 캐시에 저장한다.

 

4-3) 프록시의 원점은 포워드 프록시다

■ 포워드 프록시는 클라이언측에 두는 캐시 서버로, 프록시 서버의 원형이다.

처음 포워드 프록시가 등장했을 때는 방화벽을 실현하는 목적이 있었다. 앞서 패킷 필터링형 방화벽은 단순히 IP주소와 포트로 패킷 송수신을 제어한다. 그러면 패킷의 내용 등에 대한 보안 설정을 하기에 어려움이 있다. 이를 해결하기 위해서 포워드 프록시를 방화벽으로 사용한 것이다.

 

→ 프록시는 리퀘스트의 내용을 조사한 후 전송하므로 리퀘스트의 내용에 따라 액세스가 가능한지 판단할 수 있다.

 

 

■ 포워드 프록시를 사용할 때에는 브라우저 설정 화면으로 세팅한다.

보통 브라우저의 설정 화면에 준비되어 있는 프록시 서버라는 항목에 포워드 프록시의 IP 주소를 설정한다.

1. 포워드 프록시를 설정하면 URL과 상관없이 모든 요청이 포어드 프록시로 들어오며, http://….를 그대로 request에 작성한다. → 캐시 서버와 같이 어느 서버에 보낼 지 판단하지 않아도 되고, 모든 웹 서버에 전송할 수 있다.
2. 포워드 프록시를 설정하지 않으면 http://…..에서 웹 서버의 이름을 제외하고, 파일이나 프로그램의 경로명의 일부를 추출하여 이것을 리퀘스트의 URI 부분에 기록한다.
3. URL과 URI의 차이 ⇒ URL은 요청을 보낼 서버의 주소를 찾는 거고, URI는 해당 주소에서 이 요청을 처리하는 방을 찾는 것

 

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

■ 포워드 프록시를 사용하기 위해 반드시 해야하는 브라우저 설정은 수고나 장애의 원인 및 제약사항이 된다.

이에 따라 브라우저에 프록시를 설정하지 않아도 사용할 수 있도록 개량되었다. 즉, URI에 http:// … 이 부분을 모두 적지 않아도 리퀘스트 메시지를 보낼 수 있다.

 

■ 포워드 프록시 vs. 리버스 프록시

목록 포워드 프록시 리버스 프록시

설정	브라우저에 직접	프록시 서버 IP를 DNS에 등록
URI 형식	‘http://….’ 모두	URI 경로만 → 클라이언트가 URI의 세부 정보를 입력하지 않고도 서비스에 접근할 수 있도록 도움. 즉, 서버의 요청 중개
위치	클라이언트와 서버 사이에	서버 측에
활용	보안, 캐싱 등	부하 분산, 종료, SSL 등

 

 

4-5) 트랜스페어런트 프록시

■ 패킷의 IP 헤더를 조사하여 액세스 대상 웹서버를 알아내는 방법을 트랜스페어런트 프록시라고 한다.

보통의 리퀘스트 메시지와 같이 요청값을 작성할 수 있어서, 포워드 프록시처럼 브라우저에 설정할 필요가 없다. 또한, 리버스 프록시처럼 프록시 서버 IP를 DNS에 등록하는 것이 아니다. 따라서 브라우저에서 웹 서버로 리퀘스트 메시지가 흘러가는 길에 트랜스페어런트 프록시를 설치한다.

 

 

STORY 5 | 콘텐츠 배포 서비스

---

5-1) 콘텐츠 배포 서비스를 이용한 부하 분산

■ 캐시 서버를 놓는 장소가 어디인지에 따라 장단점이 있다.

• 서버 쪽에 배치
  • 웹 서버 부하만 억제, 인터넷 트래픽 X
• 클라이언트 쪽에 배치
  • 혼잡에 휘말려드는 일이 없으므로, 패킷의 흐름이 안정된다.
  • 클라이언트 측의 네트워크 관리자가 소유하므로, 웹 서버 관리자가 접근할 수 없다.
• 양쪽의 장점을 활용
  • 클라이언트 측의 프로바이더에 캐시 서버를 두고, 이를 서버 관리자가 컨트롤 할 수 있다.
  • 인터넷 트래픽을 억제하는 효과 + 웹 서버 관리자가 캐시 서버를 관리할 수 있다
  • 인터넷에 공개하는 서버는 인터넷의 어디에서 액세스하는지 알 수 없다. 따라서 이 방법을 실행하기 위해 프로바이더의 POP 전부에 캐시 서버를 설치해야 하므로 비현실적이다. 이를 해결하기 위해 CDS 방법을 쓴다.

 

■ CDS(Content Delivery Service)

캐시 서버를 설치하고, 웹 서버 운영자에게 대출하는 서비스다. 이 서비스를 제공하는 사업자는 프로바이더와 계약해서 캐시 서버를 설치하고, 이를 판매한다. CDSP가 설치한 캐시 서버는 여러 웹 서버 운영자가 공동으로 이용 가능하다.

 

5-2) 가장 가까운 캐시 서버의 관점

■ DNS 동작 방식과 라우팅 테이블을 활용한다.

1. 인터넷에 총 4개의 캐시 서버가 있다고 가정했을 때, 각각 장소의 라우터에서 경로 정보를 모아둔다. 이 각각의 라우터에서 경로 정보를 모아 DNS 서버에 저장한다.
2. 이 테이블로 DNS 메시지의 송신처(클라이언트)에 이르는 경로를 조사한다. (DNS 연대로 조사)
3. 모든 라우터에 대해 조사하고 비교하면 어느 캐시 서버의 라우터가 클라이언트와 가까운지 알 수 있다.

 

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

■ 리다이렉트 서버와 HTTP Location 요청 헤드

Location:  그 데이터는 이쪽 서버에 있으므로, 그쪽으로 다시 액세스하세요. 이런 접근을 리다이렉트라고 한다.

1. 클라이언트가 웹 서버의 IP 주소를 조회하면 DNS 서버는 라다이렉트용 서버의 IP 주소를 회답한다.
   • 리다이렉트용 서버를 웹 서버 측의 DNS 서버에 등록해야 한다.
2. 리다이렉트용 서버가 가장 가까운 캐시 서버를 찾아서 Location 헤더를 붙여 응답을 돌려 보내면 클라이언트는 캐시 서버에 다시 액세스 한다.
   • 리다이렉트용 서버도 DNS 서버와 같이 라우터 정보를 모은 테이블이 있다.
   • 리다이렉트는 클라이언트가 보내는 HTTP 메시지의 송신처 IP 주소를 바탕으로 거리를 판단하므로 정밀도가 높다.

패킷의 왕복시간을 계산하여 최적의 캐시 서버에 액세스 하도록 스크립트 프로그램을 내장한 페이지를 반송하는 방법도 있다.

 

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

• 최초에 저장 후, 두 번째에 갱신 → 비효율
• 이를 방지하기 위해서 웹 서버에서 데이터를 갱신할 경우, 즉시 캐시 서버도 갱신하는 구조
• 이때 동적인 부분과 정적인 부분을 구분하고 변하지 않는 부분만 캐시에 저장