[CCNA] DNS와 ARP 프로토콜로 알아보는 패킷의 흐름

도메인 네임 시스템 (Domain Name System , DNS)

OSI 7계층의 흐름 

L7 Application Layer : 발신자(sender)가 패킷을 구성하면 Application Layer에 해당 패킷 정보를 입력한다.

L6 Presentation Layer & L5 Session Layer : 그 후 Presentation Layer & Session Layer에서 캡슐화된다.

L4 Transport : 패킷은  4계층의 헤더로 전송되며 캡슐화가 진행되는데, 여기에서는 TCP인지 UDP인지의 여부와 포트 번호가 포함된다.

L3 Network :  3계층에서 발신자(sender)는 출발지 및 목적지의 IP주소를 입력해야한다. 몇몇 어플리케이션에서는 실제 IP 주소를 바로 입력하지만, 대부분은 www.cisco.com과 같은 전체 주소 도메인 이름인 **FQDN(Fully Qualified Domain Name)을 사용한다. 그리고 FQDN을 패킷에 입력할 수 있는 IP주소로 변환하기 위해서 도메인 네임 시스템(Domain Name System,DNS)을 사용한다. 

 

FQDN(Fully Qualified Domain Name)

 소프트웨어 설치 중 도메인명을 요구하면, CISCO.COM 을 입력할지, WWW.CISCO.COM. 을 입력할지 모호하다. 이러한 모호성을 피하기 위해 FQDN이란 단어를 사용하며, 이는 Namespace 계층상에서 최종 호스트명을 포함한다.

www 이 호스트명이고 cisco.com 이 도메인명, www.cisco.com 이 FQDN이다. 

도메인 네임 시스템(Domain Name System,DNS) 

• 도메인 네임 시스템(DNS)는 www.cisco.com과 같은 FQDN(Fully Qualified Domain Name)을 IP주소로 변환해준다.
• 기업들은 일반적으로 내부 DNS서버를 가지고 있으며 내부 호스트의 IP주소를 담당한다. (예를 들어, 필자가 cisco에서 일하고 있다면, cisco는 독자적인 DNS 서버를 보유하고 www.cisco.com 도메인에 포함된 모든 호스트들의 요구를 처리한다)
• 내부 DNS 서버가 없다면 공공 DNS 서버로 요청을 보낸다. 
• DNS 요청은 주로 53번 UDP 포트를 통해 전송된다 

ping 명령어로 DNS 쿼리 결과를 확인할 수 있다 .구글 IP주소가 나왔다

google.com은 도메인만 있기 때문에 FQDN이 아니지만, DNS 시스템에서는 FQDN으로 간주하고 IP주소를 요청한다. ping 요청 중 호스트명을 명시하는 경우는 주로 로컬 네트워크 서비스 접근할 때 사용한다. 예를들어 로컬 프린터에 접근하려면 printer.local과 같은 호스트명을 사용한다. 

 

라우터의 DNS 

IP를 관활하는 라우터는 자체적으로 DNS를 사용할 수 있어야하며, DNS 클라이언트나 DNS 서버로서 설정되어야한다.

 

DNS Client로 작동하는 라우터 

• 발신자(sender)가 특정 도메인에 접근하려고 할 때, 외부의 DNS 서버에 요청을 보내 해당 도메인의 IP주소를 가져온다.
• 이후에는 해당 IP주소로 데이터를 라우팅하고 사용자에게 전달한다. 

ip domain-lookup 
ip name-server  172.23.4.1 // 라우터가 요청을 보낼 DNS 서버의 IP 주소
ip domain-name ciscoA.lab // FQDN 처리

ip domain-lookup : 사용자가 명령어를 입력할 때 도메인 이름을 호스트 이름으로 간주하고 DNS 서버에 해당 호스트 이름에 대한 IP 주소를 요청한다. 사용자가 ping router1과 같은 명령어를 입력했을 때, router1은 호스트 이름으로 간주되고 DNS 서버에 쿼리를 보내 해당 호스트 이름의 IP 주소를 찾으려 시도한다.  ip domain-name 으로 도메인이름이 추가되면, 호스트이름 + 도메인이름으로 FQDN으로 만들고 DNS 서버에 요청한다. 

ip name-server 172.23.4.1 :  라우터가 요청하는 DNS 서버 IP주소는 172.23.4.1 이다.

ip domain-name ciscoA.lab  : FQDN 처리 과정이다. 사용자가 입력한 호스트 이름(router1)을 해당 도메인 이름( ciscoA.lab )과 결합한다. 이렇게 하면 사용자가 ping router1과 같은 명령어를 입력할 떄, 라우터에서는 설정된 도메인인 ciscoA.lab과 결합하여 FQDN으로 처리된다. 따라서 실제로는 router1.ciscoA.lab으로 DNS 조회가 이루어진다. 

 

DNS 서버로 작동하는 라우터  

• 라우터 자체가 DNS 서버로 작동되는 방식이다.

ip dns server // 라우터가 DNS 서버로 작동 
ip host LinuxA 172.23.4.2 // 호스트명과 호스트의 IP주소를 맵핑 

일반적으로 라우터 자체를 DNS 서버로 사용하는 것은 흔하지 않다. 기업이나 조직에서는 전용 DNS 서버를 구축하거나, 리눅스 서버와 같은 전용 DNS 솔루션을 사용하여  라우터가 클라이언트가 되는 DNS client방식을 사용한다. 이렇게 하면 더 세부적인 설정이 가능하며, 중앙에서 DNS 관리를 용이하게 할 수 있다.

 

주소 결정 프로토콜(Address Resolution Protocol,ARP)

OSI 7계층의 흐름 

 

L7 Application Layer : 발신자(sender)가 패킷을 구성하면 Application Layer에 해당 패킷 정보를 입력한다.

L6 Presentation Layer & L5 Session Layer : 패킷을 Presentation Layer & Session Layer의 헤더로 캡슐화된다.

L4 Transport : 패킷은 4계층 헤더로 캡슐화가 진행되는데, 여기에서는 TCP인지 UDP인지의 여부와 포트 번호가 포함된다.

L3 Network : 패킷은 3계층 헤더로 캡슐화가 진행되며, 출발지 및 목적지의 IP주소가 포함된다.

L2 Data-Link : 패킷은 2계층인  데이터링크 층의 헤더에 캡슐화가 된다. 출발지 및 목적지의 MAC주소가 포함되며 실제 물리적 케이블과 연결된다. 

 

ARP(Address Resolution Protocol) 프로토콜

ARP(Address Resolution Protocol)이란, 소프트웨어적으로 할당된 논리 주소인 IP주소를 (L3, 네트워크 계층) 실제 물리 주소인 MAC주소(Media Access Control/L2, 데이터링크 계층)로 바꾸어주는 역할을 하는 '주소 해석 프로토콜'을 의미한다. 

 

 

ARP 프로토콜 동작 순서 

 

 같은 서브넷상에 있을 때 

발신자(Sender)는 스위치를 통해 목직지 IP 주소를 전달하고 ARP 프로토콜을 이용, 목적지의 MAC주소를 알아낸다 .

같은 네트워크상에서의 통신이기 때문에 스위치로 ARP 프로토콜의 사용이 가능하다. 사진예시는 다음과 같은 과정으로 그려진다. 

 

- 발신자(Sender)
IP 주소 : 172.23.4.1,  MAC주소 : 1111.2222.3333
- 수신자(Receiver)
IP 주소 : 172.23.4.2 , MAC주소 : 2222.3333.4444

1. 발신자(Sender)가 ARP 요청 생성
   • 발신자(Sender)는 자신의 IP 주소(172.23.4.1)에서 목적지 IP 주소(172.23.4.2)로 향하는 통신을 준비한다.
   • 발신자(Sender)는 로컬 네트워크에서 목적지 수신자(Receiver)의 MAC 주소를 모르기 때문에 ARP 요청을 생성한다.
2. 로컬 ARP 테이블 확인
   • 발신자(Sender)는 먼저 자신의 로컬 ARP 테이블을 확인하여 목적지 IP 주소에 대한 MAC 주소를 이미 알고 있는지 확인한다.
3. ARP 캐시 미스 (Cache Miss)
   • 만약 로컬 ARP 테이블에 도착지 MAC 주소 정보가 없으면, 발신자(Sender)는 로컬 네트워크에 ARP 요청을 한다.
   •  ARP 요청은 L2 (데이터링크 계층)에서 브로드캐스트 형식으로 전송되며, 목적지 MAC 주소는 FFFF.FFFF.FFFF(브로드캐스트 MAC주소)으로 설정된다. 이렇게 함으로써 ARP 요청은 스위치에 연결된 모든 장치에게 전송되지만 IP도 가지고 있기 때문에 해당 IP주소의 MAC 주소를 찾도록 설계되어 있다
4. 로컬 네트워크에서 ARP 요청 브로드캐스트
   • 발신자(Sender)가 ARP 요청을 브로드캐스트하면, 해당 네트워크에 있는 모든 호스트가 ARP 요청을 받는다.
5. 수신자(Receiver)가 ARP 요청 수신
   • 수신자(Receiver)는 ARP 요청을 받고, 자신의 IP 주소가 목적지 IP 주소와 일치하는지 확인한다.
6. 수신자(Receiver)가 ARP 응답 생성
   • 수신자(Receiver)는 자신의 MAC 주소를 포함한 ARP 응답을 생성한다.
7. 로컬 네트워크에서 ARP 응답 전송
   • 수신자(Receiver)는 ARP 응답을 로컬 네트워크에 브로드캐스트한다.
8. 발신자(Sender)가 ARP 응답 수신
   • 발신자(Sender)는 ARP 응답을 전달받고, 목적지 MAC 주소를 로컬 ARP 테이블에 저장한다.
9. 통신 시작
   • 발신자(Sender)는 목적지 수신자(Receiver)의 MAC 주소를 알고 있으므로, 통신을 시작할 수 있다.

 

다른 서브넷상에 있을 때 

 

두 호스트가 다른 네트워크 상이라면 트래픽은 라우터를 통과해야한다. 사진 예시는 다음과 같은 과정으로 그려진다. 

- 발신자(Sender)
IP 주소 : 172.23.4.1,  MAC주소 : 1111.2222.3333 , **DG : 172.23.4.254
- 라우터 
 인터페이스 A 
IP 주소 : 172.23.4.254
MAC 주소 : 4444.5555.6666
 인터페이스 B
IP 주소 : 192.168.10.254
MAC 주소 : 4444.5555.7777
- 수신자(Receiver)
IP 주소 : 192.168.10.1 , MAC주소 : 2222.3333.4444 , DG : 192.168.10.254

 

**DG(Default Gateway) : 해당 장치가 사용하는 기본 게이트웨이의 IP 주소이다. 기본 게이트웨이는 해당 네트워크에서 다른 네트워크로 패킷을 전송할 때 사용되는 장치이다.

 

1. 발신자(Sender)에서 수신자(Receiver)로 향하는 ARP 요청
   • 발신자(Sender)는 수신자(Receiver)의 IP 주소인 192.168.10.1을 목적지로 하는 ARP 요청을 생성한다.
   • 발신자(Sender)의 ARP 요청은 브로드캐스트로 전송되며, 발신자의 MAC 주소는 1111.2222.3333이고 목적지 MAC 주소는 FFFF.FFFF.FFFF로 설정된다.
   • 라우터의 인터페이스 B(192.168.10.254)를 향해 ARP 요청이 전송된다.
2. 라우터의 ARP 응답
   • 라우터는 ARP 요청을 받고, 자신의 인터페이스 B(192.168.10.254)의 MAC 주소인 4444.5555.7777을 발신자(Sender)에게 응답한다.
   • ARP 응답은 발신자(Sender)에게 유니캐스트로 전송되며, 발신자의 ARP 테이블에 라우터의 인터페이스 B의 MAC 주소가 매핑된다.
3. 발신자(Sender)의 ARP 테이블 업데이트
   • 발신자(Sender)는 ARP 응답을 받고, 수신자(Receiver)의 IP 주소에 해당하는 MAC 주소가 2222.3333.4444임을 알게 된다. ( ARP 요청은 브로드캐스트로 보내기 때문에 수신자(Receiver)의 MAC주소를 알 수 있음) 
   • ARP 테이블은 이 정보로 업데이트가 진행된다.
4. 발신자(Sender)에서 수신자(Receiver)로의 통신
   • 이제 발신자(Sender)는 수신자(Receiver)의 MAC 주소를 알고 있기 때문에 유니캐스트로 패킷을 전송한다.
   • 패킷은 발신자의 MAC 주소에서 라우터의 인터페이스 B(192.168.10.254)의 MAC 주소로, 그리고 수신자(Receiver)의 MAC 주소로 이동한다
5. 라우터를 통한 수신자(Receiver)로의 전달
   • 라우터는 수신자(Receiver)의 IP 주소를 확인하고, 패킷을 인터페이스 B를 통해 수신자로 전달한다.
   • 라우터는 라우팅 테이블을 참조하여 어떤 인터페이스로 전달해야 하는지 결정한다.
6. 수신자(Receiver)의 패킷 수신 및 응답
   • 수신자(Receiver)는 패킷을 받아서 해당 내용을 처리하고, 필요하면 응답을 생성하여 발신자(Sender)에게 되돌려준다.

 

호스트 ARP 명령어

• ARP 응답결과는 호스트의 ARP 캐시에 저장되기 때문에, arp 요청은 한번만한다. 

show arp  // arp 캐시 확인 

 

랩연습 

문제1. Configure the routers as DNS Client 

( 시스코 패킷 트레이서로는 라우터 자체를 DNS로 설정하는 것이 불가능하다. (ip dns server 명령어가 안먹힘) 따라서 시험에는 DNS Client로 설정하는 것이 나올 것임 )

 

위의 토폴로지에서 DNS-Server 라고 써있는 곳이 DNS 서버로 사용되는 곳이다. 

DNS 서버 IP 는 10.10.10.10인것을 확인할 수 있다.

 

우선 연결되어있는 R1,R2,R3가 10.10.10.10를 DNS 서버로서 사용할 수 있게 만들어야한다. 

라우터를 하나씩 클릭하여 10.10.10.10을 DNS 서버로 설정한다

R3>en //특권모드 전환
R3#config terminal //전역구성모드 전환
R3(config)#ip domain-lookup //DNS 활성화
R3(config)#ip name-server 10.10.10.10 //10.10.10.10을 DNS 서버로 설정 

 

설정이 완료되면 ping 명령어로 DNS 쿼리가 작동되는지 확인한다.

DNS 쿼리가 성공한 것을 볼 수 있다. R1는 DNS 요청을 할 때마다 외부 서버(10.10.10.10)에 요청을 보내는 DNS Client로 설정되었다 

 

 

문제2. Examine the ARP Cache on the Routers 

 

ARP 요청은 브로드캐스트 트래픽을 사용하기 떄문에 라우터에 의해 전달되지 않으며, 라우터는 연결된 네트워크에서 보인 모든 호스트에대한 ARP 캐시항목을 가지고 있다.

 

 

토폴로지를 다시 확인해보면,  R1은 R3와 직접적으로 연결되어 있지 않다. R1은 R2라우터의 IP를 통해 R3와 연결된다. 따라서 R1은 R3에 대한 ARP 캐시를 가지고 있지 않으며, R3에게 ARP 요청을 하여도 R2의 ARP 캐시를 가지고 있다. 

 

R1의 ARP 캐시를 확인해보자

R1에서 ping R3 요청을 한 이력이 있지만 R3(10.10.20.1)은 ARP 캐시로 남아있지 않다. DNS서버(10.10.10.10)도 스위치로 직접적으로 연결되어 있어서 ARP 캐시로 남아있다.

 

 

R2의 ARP 캐시

 R1,R3 가 모두 ARP 캐시로 남아있다.

 

R3의 ARP 캐시

 

R3는 10.10.10.0/24와는 직접적으로 연결되지 않아 R1의 ARP캐시가 나오지 않았다.

 

 

 

 

 

 

 

 

참고

 

https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-0/addr_serv/command/reference/ir40asrbook_chapter2.html

ARP Commands

https://www.stevenjlee.net/2020/06/07/%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-arp-address-resolution-protocol-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C/

[이해하기] ARP (Address Resolution Protocol) 프로토콜 | STEVEN J. LEE

https://www.flackbox.com/arp-the-address-resolution-protocol

ARP - The Address Resolution Protocol - FlackBox