Linux 에서 ping 및 arp 를 사용한 네트워크 계층 상호 작용 탐색

소개

이 실험에서는 Linux 환경에서 네트워크 계층 (계층 3) 과 데이터 링크 계층 (계층 2) 간의 기본적인 상호 작용을 탐구합니다. 주소 결정 프로토콜 (ARP) 이 작동하는 것을 관찰하기 위해 일반적인 ping 및 arp 명령줄 유틸리티를 사용합니다. 주요 목표는 시스템이 로컬 네트워크의 장치에 대한 IP 주소를 물리적 MAC 주소로 어떻게 확인하는지, 그리고 원격 호스트와의 통신을 어떻게 처리하는지 이해하는 것입니다.

먼저 ARP 캐시의 상태를 검사합니다. 그런 다음 ping을 사용하여 로컬 장치 (기본 게이트웨이) 및 원격 장치 (google.com) 와 통신합니다. 이러한 작업 전후에 ARP 캐시를 관찰함으로써 시스템이 로컬 통신에 MAC 주소를 어떻게 사용하는지, 그리고 원격 트래픽에 대해 기본 게이트웨이에 어떻게 의존하는지 알 수 있습니다.

이것은 가이드 실험입니다. 학습과 실습을 돕기 위한 단계별 지침을 제공합니다.각 단계를 완료하고 실무 경험을 쌓기 위해 지침을 주의 깊게 따르세요. 과거 데이터에 따르면, 이것은 초급 레벨의 실험이며 완료율은 97%입니다.학습자들로부터 97%의 긍정적인 리뷰율을 받았습니다.

`arp -a`로 초기 ARP 캐시 보기

이 단계에서는 시스템의 주소 결정 프로토콜 (ARP) 캐시의 초기 상태를 검사합니다. ARP 캐시는 동일한 로컬 네트워크에 있는 장치들의 계층 3(IP) 주소와 해당 계층 2(MAC) 주소 간의 매핑을 저장하는 중요한 네트워킹 구성 요소입니다.

먼저 arp 명령을 사용하여 ARP 캐시의 현재 상태를 확인해 보겠습니다. -a 플래그는 모든 현재 항목을 표시하도록 명령에 지시합니다.

이미 ~/project 경로에 있는 터미널에서 다음 명령을 실행합니다.

arp -a

하나 이상의 항목이 표시될 것입니다. 기본 게이트웨이가 이미 캐시에 존재하는 것은 일반적입니다. 출력은 다음과 유사할 수 있습니다.

_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0

LabEx 환경의 가상화된 특성 때문에 ARP 캐시를 완전히 지우는 것이 항상 가능한 것은 아니라는 점에 유의하는 것이 중요합니다. 따라서 처음부터 미리 채워진 캐시가 표시될 가능성이 높습니다. 일반적인 비가상화 설정에서는 첫 번째 통신 전에 게이트웨이에 대해 비어 있거나 <incomplete> 항목이 표시될 가능성이 더 높습니다.

이 출력은 ARP 캐시의 초기 상태를 보여줍니다. 이는 다음 단계의 기준선 역할을 하며, 여기서 네트워크 활동을 트리거하고 이 테이블이 어떻게 사용되는지 관찰할 것입니다.

ARP 요청을 트리거하기 위해 로컬 장치 ping

이 단계에서는 ping 명령을 사용하여 로컬 네트워크의 다른 장치와의 통신을 시작합니다. 이 작업은 필요한 경우 주소 결정 프로토콜 (ARP) 매핑을 사용합니다. 시스템이 로컬 IP 주소로 패킷을 보내려고 할 때 먼저 ARP 캐시를 확인합니다. 해당 MAC 주소를 찾지 못하면 브로드캐스트 ARP 요청을 보냅니다. 항목이 이미 존재하는 경우 캐시된 MAC 주소를 사용합니다.

이를 수행하려면 먼저 로컬 네트워크의 장치 IP 주소를 식별해야 합니다. 이 환경에서 가장 신뢰할 수 있는 대상은 기본 게이트웨이(가상 라우터) 입니다. 라우팅 테이블을 검사하여 IP 주소를 찾을 수 있습니다.

터미널에서 다음 명령을 실행하여 라우팅 테이블을 표시합니다.

ip route show

출력에서 기본 경로를 볼 수 있습니다. default via로 시작하는 줄을 찾으십시오. 거기에 나열된 IP 주소가 게이트웨이입니다.

default via 172.16.50.253 dev eth0 ...
...

위의 예시 출력에서 게이트웨이의 IP 주소는 172.16.50.253입니다. 이제 이 IP 주소를 사용하여 몇 개의 ping 패킷을 보냅니다. -c 4 옵션은 ping에 정확히 4 개의 패킷을 보낸 다음 중지하도록 지시합니다. 172.16.50.253을 찾은 실제 게이트웨이 IP 로 바꾸십시오.

ping -c 4 172.16.50.253

각 패킷에 대해 성공적인 응답을 보게 될 것이며, 이는 시스템이 게이트웨이와 통신할 수 있었음을 확인합니다.

PING 172.16.50.253 (172.16.50.253) 56(84) bytes of data.
64 bytes from 172.16.50.253: icmp_seq=1 ttl=64 time=0.066 ms
64 bytes from 172.16.50.253: icmp_seq=2 ttl=64 time=0.060 ms
64 bytes from 172.16.50.253: icmp_seq=3 ttl=64 time=0.055 ms
64 bytes from 172.16.50.253: icmp_seq=4 ttl=64 time=0.045 ms

--- 172.16.50.253 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3060ms
rtt min/avg/max/mdev = 0.045/0.056/0.066/0.007 ms

이 간단한 작업으로 시스템은 ARP 조회를 수행하게 되었습니다. 다음 단계에서는 ARP 캐시를 다시 검사하여 결과를 확인합니다.

ARP 캐시에서 로컬 IP-MAC 주소 변환 확인

이 단계에서는 이전에 실행한 ping 명령의 직접적인 결과를 보기 위해 ARP 캐시를 다시 검사합니다. 시스템이 로컬 게이트웨이와 성공적으로 통신했으므로 유효한 IP-MAC 주소 매핑이 있어야 합니다. 테이블이 변경되었는지 확인해 보겠습니다.

ARP 캐시를 다시 검사해 보겠습니다. 터미널에서 첫 번째 단계와 동일한 명령을 실행합니다.

arp -a

이번에는 항목이 아직 완료되지 않은 경우에만 출력이 달라집니다. 이 경우 게이트웨이에 대한 ARP 항목이 1 단계에서 이미 완료되었으므로 출력은 동일합니다.

_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0

이 출력을 1 단계의 출력과 비교하십시오. 동일합니다. 이는 게이트웨이에 대한 ARP 항목이 ping을 보내기 전에 이미 완료되었기 때문입니다. 시스템은 새로운 ARP 요청을 수행할 필요가 없었습니다. 이미 캐시에 있는 정보를 단순히 사용했습니다.

이는 핵심 원칙을 보여줍니다. ARP 캐시는 중복 ARP 요청을 방지합니다. 항목이 <incomplete>이거나 누락된 경우 이 ping 명령이 이를 채웠을 것이며 출력에서 변경 사항을 볼 수 있었을 것입니다.

기본 게이트웨이를 포함하도록 외부 호스트 ping

이 단계에서는 로컬 장치와의 통신에서 인터넷상의 호스트와의 통신으로 전환합니다. 이는 컴퓨터가 자체 로컬 네트워크 외부의 대상에 도달하기 위해 기본 게이트웨이를 어떻게 사용하는지에 대한 기본적인 네트워킹 개념을 보여줍니다.

대상 IP 주소가 컴퓨터와 동일한 서브넷에 있지 않으면 시스템은 직접 패킷을 보낼 수 없다는 것을 알고 있습니다. 대신, 지정된 기본 게이트웨이로 패킷을 보내야 합니다. 게이트웨이 (라우터) 는 인터넷을 통해 최종 목적지로 패킷을 전달할 책임이 있습니다.

이를 직접 확인하기 위해 잘 알려진 외부 호스트인 google.com에 ping 합니다.

터미널에서 다음 명령을 실행합니다.

ping -c 4 google.com

google.com 도메인이 IP 주소로 확인되는 것을 볼 수 있으며, 해당 주소로부터 응답을 받게 됩니다.

PING google.com (142.250.189.174) 56(84) bytes of data.
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=1 ttl=118 time=4.38 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=2 ttl=118 time=4.40 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=3 ttl=118 time=4.35 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=4 ttl=118 time=4.39 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.353/4.380/4.401/0.017 ms

google.com과 성공적으로 통신했지만, 컴퓨터는 Google 의 IP 주소에 대한 ARP 요청을 수행하지 않았습니다. 이전 단계에서 이미 찾은 로컬 게이트웨이의 MAC 주소만 필요했습니다. 다음 단계에서는 ARP 캐시를 분석하여 이 동작을 확인합니다.

원격 통신을 위한 ARP 캐시 분석

이 마지막 단계에서는 원격 호스트와의 통신을 시스템이 어떻게 처리하는지 확인하기 위해 ARP 캐시를 마지막으로 분석합니다. 이를 통해 로컬 및 원격 네트워크 통신의 차이점을 명확히 하고 기본 게이트웨이의 역할을 강조할 것입니다.

google.com에 성공적으로 ping 한 후, ARP 캐시를 다시 확인해 보겠습니다. 터미널에서 arp -a 명령을 실행합니다.

arp -a

출력을 주의 깊게 살펴보십시오. 이전 단계의 캐시 상태와 동일해야 합니다.

_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0

google.com 또는 해당 IP 주소 (예: 142.250.189.174) 에 대한 항목이 없다는 것을 알 수 있습니다. 현재 존재하는 유일한 중요한 항목은 여전히 기본 게이트웨이에 대한 항목입니다.

이것이 이 실습의 핵심입니다. ARP 는 계층 2 에서 작동하며 로컬 네트워크 세그먼트에서 MAC 주소를 찾는 데만 사용됩니다. 컴퓨터가 원격 대상에 패킷을 보낼 때, 대상이 로컬이 아니라는 것을 알고 있으므로 다음 홉인 기본 게이트웨이의 MAC 주소로 패킷을 보냅니다. 그러면 라우터가 최종 목적지를 향해 IP 패킷을 전달하는 책임을 맡습니다. 컴퓨터는 google.com의 MAC 주소를 알 필요가 없습니다. 대신 패킷을 대신 전달할 수 있는 장치의 MAC 주소만 알면 됩니다.

요약

이 실습에서는 Linux 에서 ping 및 arp 명령을 사용하여 계층 3(IP) 및 계층 2(MAC) 네트워킹 간의 기본적인 상호 작용을 탐구했습니다. arp -a를 사용하여 주소 결정 프로토콜 (ARP) 캐시의 상태를 검사하는 것으로 시작했으며, 기본 게이트웨이와 같은 중요한 장치에 대한 항목이 이미 포함되어 있을 수 있음을 관찰했습니다. 로컬 게이트웨이에 ping 함으로써 시스템이 로컬 통신에 이 캐시된 정보를 사용하고 중복 주소 조회를 피한다는 것을 확인했습니다.

또한 원격 호스트와의 통신이 어떻게 다른지 조사했습니다. 외부 IP 주소에 ping 했을 때, 시스템이 최종 목적지에 대한 ARP 요청을 수행하지 않는다는 것을 관찰했습니다. 대신, 패킷을 기본 게이트웨이로 보내 로컬 네트워크 외부로 라우팅되도록 합니다. ARP 캐시에 대한 최종 분석은 이 개념을 강화했으며, 원격 호스트에 대한 항목이 추가되지 않았음을 보여주었습니다. 유일하게 관련된 항목은 기본 게이트웨이의 항목으로 남아 있었으며, 이는 외부 네트워크로 향하는 모든 트래픽에 대한 중개자로서의 중요한 역할을 강조했습니다.