통신을 도와주는 네트워크 주요 기술

이 글은 고재성, 이상훈 저 - "IT 엔지니어를 위한 네트워크 입문"를 공부하고 정리하여 작성하였습니다.

 

1. NAT/PAT

• 하나의 네트워크 주소에 다른 하나의 네트워크 주소로 변환하는 1:1 변환이 기본
• IP 주소가 고갈되는 문제를 해결하기 위해 여러 개의 IP를 하나의 IP로 변환하기도 함
• 공식 용어는 NAPT(Network Port Address Translation) ,실무에서는 PAT라는 용어로 많이 사용
• 가장 많이 사용되는 NAT는 사설 IP주소에서 공인 IP 주소로 전환하는 경우이다.

“NAT는 IP 주소를 다른 IP 주소로 변환해 라우팅을 원활히 해주는 기술”
- 인터넷 표준 문서 -

1.1. NAT/PAT의 용도와 필요성

1. IPv4 주소 고갈 문제의 솔루션으로 사용
2. 보안을 강화하는 데 사용
   • 외부와 통신할 때 내부 IP를 다른 IP로 변환해 외부에 사내 IP주소 체계를 숨길 수 있음
3. IP 주소 체계가 같은 같은 두 개의 네트워크 간 통신을 가능하게 함
   • 사용하는 사설 IP 대역이 같은 회사끼리의 통신을 위해 출발지와 도착지를 한꺼번에 변환하는 더블 NAT를 사용
4. 불필요한 설정 변경을 줄일 수 있음
   • 보통은 통신사업자나 IDC 쪽에서 IP를 할당받아 사용
   • NAT/PAT를 사용할 경우 공인 IP 주소 변경 시 네트워크 장비의 설정만 변경하고 PC 설정 변경은 최소화 할 수 있음

1.2. NAT 동작 방식

1. 사용자는 웹 서버에 접근하기 위해 출발지 IP: 10.10.10.10, 목적지: 20.20.20.20, 서비스 포트: 80
2. NAT 장비에서 사용자가 보낸 패킷을 수신한 후 NAT 정책에 따라 공인 IP 11.11.11.11로 주소 변경 후 NAT 테이블에 저장
3. NAT 장비에서 출발지를 11.11.11.11로 변경해 웹 서버로 전송
4. 패킷을 수신한 웹 서버에서 사용자에게 응답을 보냄 (출발지 IP: 20.20.20.20, 목적지: 11.11.11.11)
5. 응답 패킷을 수신한 NAT는 원래 패킷을 발생시킨 출발지 IP 주소가 10.10.10.10임을 확인
6. 원래 패킷 출발지 IP(10.10.10.10)로 변경해 사용자에게 전송되면 최종 수신

1.3. PAT 동작 방식

• PAT는 NAT 테이블에 출발지 IP 주소와 출발지 서비스 포트가 모두 변경되고 NAT 테이블에 기록됨
• 하나의 IP만으로 다양한 포트 번호를 사용해 사용자를 구분할 수 있음
• 서비스 포트의 개수가 제한되어 재사용이 됨
• 동시 사용자가 많은 경우 정상 동작하지 않을 수 있고 공인 IP 주소를 하나가 아닌 풀(Pool)로 구성
• 다수의 IP가 있는 출발지에서 목적지로 갈 때 NAT 테이블이 생성되고 응답에 대해 NAT 테이블을 참조할 수 있음
• 하지만 PAT IP가 목적지인 경우 해당 IP가 어느 IP에 바인딩되는지 확인할 수 없음

1.4. SNAT와 DNAT

• 어떤 IP 주소를 변환하는지에 따라 두 가지로 구분함
  • SNAT(Source NAT): 출발지 주소를 변경하는 NAT
  • DNAT(Destination NAT): 도착지 주소를 변경하는 NAT
• 트래픽이 출발하는 시작 지점을 기준으로 구분함.
• NAT 장비를 처음 통과할 때 NAT 테이블을 사용해 기록됨
• 이후 응답 패킷이 NAT 장비에 들어오면 별도의 설정 없이 반대로 패킷을 변환하는 역 NAT가 수행

1. SNAT
   1. 사설 → 공인으로 통신할 때 많이 사용
   2. 보안상 SNAT를 사용할 때 사용
   3. 로드 밸런서의 구성에 따라 SNAT를 사용
      1. 같은 대역일 때 로드밸런서를 거치지 않고 응답하는 경우가 있어 SNAT를 통해 로드 밸런서를 거치게 함
2. DNAT
   1. 로드 밸런서에서 많이 사용
   2. 사내가 아닌 대외망 네트워크 구성에 사용

1.5. 동적 NAT와 정적 NAT

• 정적 NAT
  • 출발지와 목적지 IP를 미리 매핑해 고정해놓은 NAT
  • 1:1 NAT라 부르기도 하며 방향성 없이 서비스 흐름을 고려할 필요가 없음
• 동적 NAT
  • 출발지나 목적지가 사전에 정해지지 않고 NAT를 수행할 때 IP를 동적으로 변경하는 것
  • 출발지와 목적지가 다수의 IP 풀이나 레인지(Range)로 설정
  • NAT가 필요할 때 어떻게 매핑할 것인지 판단해 NAT를 수행하는 시점에 NAT 테이블을 만들어 관리
  • NAT 테이블은 일정 시간 통신이 없는 경우 다시 사라지므로 서비스 흐름을 고려해 적용해야 함

정적 NAT 설정

• 지정한 방향으로만 1:1 NAT가 적용되는 장비도 있음
• 이런 장비에서는 방향성을 고려해 두 개의 NAT를 각각 설정해야 함

 

2. GSLB

• DNS에서 동일한 레코드 이름으로 서로 다른 IP 주소를 동시에 설정할 수 있음
• 이렇게 설정하면 도메인 질의에 따라 응답받는 IP 주소를 나누어 로드밸런싱할 수 있음
• 하지만 DNS 로드밸런싱만으로는 정상적인 서비스를 할 수 없음
• DNS는 설정된 서비스 상태의 정상 여부를 확인하지 않고 질의에 무조건 응답함.
• 특정 서비스에 문제가 있을 때는 DNS 서버가 인지하지 못하여 비정상 상태의 서비스 IP 주소를 응답해버리는 문제가 발생
• GSLB(Global Server/Service Load Balancing)는 DNS의 이런 문제를 해결해 도메인을 이용한 로드밸런싱 구현을 도와줌
• GSLB는 DNS와 동일하게 도메인 질의에 응답해주는 역할과 동시에 밸런서처럼 등록된 도메인에 연결된 서비스의 헬스 체크를 수행

2.1. GSLB 동작 방식

1. 사용자가 web.zigispace.net에 접속하기 위해 DNS에 질의
2. LDNS는 web.zigispace.net을 관리하는 NS 서버를 찾기 위해 root부터 순차 질의
3. zigispace.net을 관리하는 NS 서버로 web.zigispace.net에 대해 질의
4. DNS 서버는 GSLB로 web.zigispace.net에 대해 위임했으므로 GSLB 서버가 NS 서버라고 LDNS에 응답
5. LDNS는 다시 GSLB로 web.zigispace.net에 대해 질의
6. GSLB는 web.zigispace.net에 대한 IP 주소값 중 현재 설정된 분산 방식에 따라 서울 혹은 부산 데이터 센터의 IP 주소값을 DNS에 응답
7. GSLB에서 결괏값을 응답받은 LDNS는 사용자에게 web.zigispace.net가 1.1.1.1로 서비스한다고 최종 응답

• DNS와 거의 동일하게 동작하지만 서비스 IP 정보에 대한 헬스체크와 다양한 분산 방법을 사용하는 차이가 있다.

2.2. GSLB 구성 방식

1. 도메인 자체를 GSLB로 사용
   • 해당 도메인에 속하는 모든 레코드 설정을 GSLB 장비에서 관리
   • 도메인에 대한 네임 서버를 GSLB로 지정하고 GSLB에서 도메인에 대한 모든 레코드를 등록해 처리하는 방식
   • 이 경우 모든 레코드에 대한 질의가 GSLB를 통해 이루어져 GSLB에 부담을 줌
2. 도메인 내의 특정 레코드만 GSLB를 사용
   • DNS에서 도메인 설정 시 GSLB를 사용하려는 레코드에 대해서만 GSLB로 처리하도록 설정
   • 도메인 내의 특정 레코드에 대해서만 GSLB로 처리를 이관하는 방식을 사용
   • 처리를 이관하는 방식
     1. 별칭(Alias) 사용(CNAME 사용)
        • 실제 도메인과 다른 별도의 도메인 레코드로 등록
        • 외부 CDN을 사용하거나 회사 내부에 GSLB를 사용해야 할 도메인이 많은 경우 한꺼번에 관리하기 위해 사용
          

          

          
          
          1. 사용자가 web.zigispace.net을 LDNS(1.1.1.1)로 질의
          2. LDNS는 web.zigispace.net을 관리하는 NS 서버를 찾기 위해 root부터 순차적으로 질의
          3. zigispace.net을 관리하는 DNS(2.2.2.2)에 web.zigispace.net의 주소 질의
          4. DNS 서버는 LDNS에게 별칭으로 web.zigispace.net은 web.zigispace.gslb.net이 관리하고 있다는 응답 수신
          5. 다시 LDNS(1.1.1.1)는 gslb.net을 관리하는 NS 서버를 root부터 순차 질의
          6. LDNS(1.1.1.1)는 zigispace.gslb.net을 관리하는 NS 서버인 GSLB(3.3.3.3)에 web.zigispace.gslb.net에 대해 질의
          7. GSLB(3.3.3.3)는 LDNS(1.1.1.1)에 web.zigispace.gslb.net의 IP(10.10.10.10)를 응답
          8. LDNS(1.1.1.1)는 해당 결괏값(10.10.10.10)을 사용자에게 최종 응답
     2. 위임(Delegation) 사용(NS 사용)
        • 실제 도메인과 동일한 도메인 레코드를 사용하여 도메인 전체를 위임함

        

        
        
        1. 사용자가 web.zigispace.net을 LDNS(1.1.1.1)로 질의
        2. LDNS는 web.zigispace.net을 관리하는 NS 서버를 찾기 위해 root부터 순차적으로 질의
        3. zigispace.net을 관리하는 DNS(2.2.2.2)에 web.zigispace.net의 주소 질의
        4. DNS(2.2.2.2)는 GSLB(3.3.3.3)가 web.zigispace.net을 관리한다고 응답
        5. 다시 LDNS(1.1.1.1)는 web.zigispace.net을 관리하는 NS 서버인 GSLB(3.3.3.3)에게 web.zigispace.net을 질의
        6. GSLB(3.3.3.3)는 LDNS(1.1.1.1)에 web.zigispace.net의 IP를 응답
        7. LDNS(1.1.1.1)는 해당 결괏값을 사용자에게 최종 응답
   • 결론
     • 별칭을 이용해 GSLB를 사용하는 경우
       • CDN처럼 GSLB를 운영해주는 외부 사업자가 있는 경우
       • GSLB를 사용해야 하는 도메인이 많거나 별도의 GSLB를 운영해야 하는 경우
     • 위임해서 GSLB를 사용하는 경우
       • DNS와 같은 도메인으로 GSLB를 운영하면서 계층적으로 GSLB를 이용한 FQDN을 관리할 때 사용
       • FQDN(Full Qualified Domain Name): 인터넷에서 특정 컴퓨터, 장치 또는 자원을 고유하게 식별할 수 있는 완전한 도메인 이름

 

 

2.3. GSLB 분산 방식

• GSLB 분산의 목적
  • 서비스 제공의 가능 여부를 체크해 트래픽 분산
  • 지리적으로 멀리 떨어진 다른 데이터 센터에 트래픽 분산
  • 지역적으로 가까운 서비스에 접속해 더 빠른 서비스 제공이 가능하도록 분산
• GSLB의 헬스 체크 모니터링 요소
  • 서비스 응답 시간/지연 (RTT/Latency)
  • IP에 대한 지리 정보
• 해당 정보들을 활용해 서비스를 분산 처리함.
• 사용자가 바라보는 Local DNS와 GSLB 간 값이므로 국가 설정을 잘 해야 함

 

3. DHCP

• DHCP(Dynamic Host Configuration Protocol): IP를 동적으로 할당하는 데 사용하는 프로토콜
• DHCP를 사용하면 사용자가 직접 입력해야 하는 IP 주소, 서브넷 마스크, 게이트웨이, DNS 정보를 자동으로 할당받아 사용

3.1. DHCP 프로토콜

• BOOTP(Bootstrap Protocol)라는 프로토콜을 기반으로 하며 호환도 됨
• BOOTP와 유사하게 동작하지만 몇 가지 기능이 추가된 확장 프로토콜
• DHCP는 서버와 클라이언트로 동작
  • 클라이언트 서비스 포트: 68(bootpc)
  • 서버 서비스 포트: 67(bootps)

3.2. DHCP 동작 방식

1. DHCP Discover
   • DHCP 클라이언트는 DHCP 서버를 찾기 위해 DHCP Discover 메시지를 브로드캐스트로 전송
   • 출발지는 Zero IP 주소(0.0.0.0) , 목적지는 브로드캐스트 주소(255.255.255.255)
   • IP 할당 중이기 때문에 UDP를 사용
2. DHCP Offer
   • 수신한 DHCP 서버는 클라이언트에 할당할 IP 주소, 서브넷, 게이트웨이, DNS 정보, Lease Time 등의 정보를 포함한 DHCP 메시지를 클라이언트로 전송
   • 특정 클라이언트의 MAC주소와 IP 주소를 사전에 정의하면 설정된 대로 할당 가능
3. DHCP Request
   • DHCP 서버로부터 제안 받은 IP 주소와 DHCP 서버 정보를 포함한 DHCP 요청 메시지를 브로드캐스트로 전송
   • DHCP 서버 여러 대가 동작하는 환경을 위해 브로드캐스트로 전송
4. DHCP Ack
   • DHCP 클라이언트로부터 IP 주소를 사용하겠다는 요청을 받으면 DHCP 서버에
     • 해당 IP를
     • 어떤 클라이언트가
     • 언제부터 사용하기 시작했는지
   • 정보를 기록하고 DHCP Request 메시지를 정상적으로 수신했다는 응답 전송
   • 이것도 브로드캐스트로 해당 네트워크 내에 전체 전송

• DHCP를 통해 IP를 할당 받을 때는 IP 임대 시간이 있음
• 만약 임대 시간이 다한 경우, 갱신 과정을 거쳐 IP 주소가 IP 풀에 다시 반환하지 않고 계속 사용함
• DHCP 갱신 절차
  

  

  • IP를 할당한 후 임대 시간의 50%가 지나면 갱신 과정을 수행
  • DHCP Request와 DHCP ACK를 주고 받으면서 갱신 과정을 진행
  • 갱신 시에는 유니캐스트로 진행
  • 만약 갱신이 실패하면 남은 시간의 50%가 지난 시점에서 다시 갱신을 시도함.

DHCP 메시지 타입과 항목

• 4가지 타입의 DHCP 메시지 외 더 다양한 메시지들이 존재함

메시지 타입	내용
DHCP Discover	클라이언트가 사용한 DHCP 서버를 찾는 메시지
DHCP Offer	DHCP 서버가 IP 설정값에 대해 클라이언트에게 제안하는 메시지
DHCP Request	DHCP 서버에서 제안받은 설정값을 요청하는 메시지
DHCP Decline	현재 IP가 사용 중임을 클라이언트가 서버에 알려주는 메시지
DHCP Ack	DHCP 서버가 클라이언트에 받은 요청을 수락하는 메시지
DHCP Nak	DHCP 서버가 클라이언트에 받은 요청을 수락하지 않는다는 메시지
DHCP Release	클라이언트가 현재 IP를 반납할 때 사용하는 메시지
DHCP Inform	클라이언트가 서버에 IP 설정값을 요청하는 메시지

※ DHCP Starvation 공격 : IP 풀에서 관리하는 모든 IP 주소를 소진시켜 IP를 할당받을 수 없도록 하는 공격 방식

3.3. DHCP 서버 구성

• DHCP 서버는 윈도 서버의 DHCP 서비스나 리눅스의 DHCP 데몬을 이용해 구성할 수 있음
• DHCP 서버 설정값
  • IP 주소풀(IP 범위)
  • 예외 IP 주소 풀(예외 IP 범위)
  • 임대 시간
  • 서브넷 마스크
  • 게이트웨이
  • DNS

3.4. DHCP 릴레이

• DHCP 서버에서 IP 주소를 할당받기 위해 모두 브로드캐스트를 사용함
• 동일 네트워크에서만 전송되므로 각 네트워크마다 DHCP 서버가 있어야 함
• DHCP 릴레이 에이전트 기능을 사용하면 DHCP 서버 한 대로 여러 네트워크 대역에서 IP 풀을 관리할 수 있음
• DHCP 패킷을 중간에서 중계하는 역할을 수행함
  

  

 

1. DHCP Discover(클라이언트 → 릴레이 에이전트)
   1. DHCP 클라이언트는 DHCP 서버를 찾기 위해 브로드캐스트로 패킷을 전송
2. DHCP Discover(릴레이 에이전트 → DHCP 서버)
   1. 출발지와 목적지를 릴레이 에이전트 IP 주소와 DHCP 서버 IP 주소로 재작성
   2. 이때는 주소가 DHCP 서버가 되었기 때문에 유니캐스트로 보냄
   3. 출발지 주소 ≠ 릴레이 에이전트 IP 주소
   4. 출발지 주소: DHCP 서버로 가기 위한 방향의 인터페이스 IP 주소
   5. 릴레이 에이전트 IP 주소: DHCP 클라이언트가 속한 내부 인터페이스 IP 주소
3. DHCP Offer(DHCP 서버 → 릴레이 에이전트)
   1. Discover를 수신한 DHCP 서버는 클라이언트에 할당할 주소와 서브넷, 게이트웨이,DNS 정보, 임대 시간(Lease Time) 등의 정보를 포함한 DHCP 메시지를 DHCP 릴레이 에이전트로 다시 전송
   2. DHCP Server Identifier는 DHCP 서버 자신이 됨
4. DHCP Offer(릴레이 에이전트 → 클라이언트)
   1. DHCP Offer 메시지를 DHCP 클라이언트에 브로드캐스트로 다시 전송
   2. DHCP Server Identifier는 실제 DHCP 서버의 IP 주소 → 릴레이 에이전트의 외부 인터페이스 IP 주소로 변경되어 전송
5. DHCP Request(클라이언트 → 릴레이 에이전트)
   1. DHCP 서버로부터 제안받은 IP 주소와 DHCP 서버 정보를 포함한 DHCP 요청 메시지를 브로드캐스트로 전송
6. DHCP Request(릴레이 에이전트 → DHCP 서버)
   1. DHCP 클라이언트에서 보낸 DHCP 요청 메시지를 유니캐스트로 다시 변환해 DHCP 서버로 전달
7. DHCP ACK(DHCP 서버 → 릴레이 에이전트)
   1. 해당 IP를 어떤 클라이언트가 언제부터 사용하기 시작했는지 정보를 기록
   2. DHCP Request 메시지를 정상적으로 수신했다는 응답을 전송
   3. 마찬가지로 유니캐스트 형태로 전송
8. DHCP ACK(릴레이 에이전트 → 클라이언트)
   1. DHCP 서버에서 받은 Ack 메시지를 클라이언트에 브로드캐스트로 다시 전달합니다.

 

자료

• IT 엔지니어를 위한 네트워크 입문 (고재성, 이상훈 저, 2020.10)