ARP와 기본 게이트웨이
90분 안팎
학습 목표
같은 망과 다른 망 목적지의 ARP 대상과 다음 홉을 실습망에서 비교합니다.
개념
ARP보다 먼저 다음 홉을 결정합니다
학교 주소표를 승인해도 실제 전달은 단말이 선택한 경로에 달려 있습니다. 이 레슨에서는 s1이 같은 학생망의 s2와 다른 서버망의 server1으로 보낼 때 누구의 MAC을 찾는지 비교합니다. 단말은 먼저 목적지에 대한 경로를 선택하고 그 경로의 다음 홉 IPv4를 링크 주소로 해석합니다. 최종 목적지와 다음 홉이 같을 수도 다를 수도 있다는 사실을 실제 이웃 캐시와 경로 조회로 확인합니다.
이번 망은 s1 10.20.10.11/24, s2 10.20.10.12/24와 학생 게이트웨이 10.20.10.1입니다. 서버는 10.20.30.11/24, 서버 게이트웨이는 10.20.30.1입니다. 단말에는 연결된 /24 경로와 r1을 향한 기본 경로가 있습니다. 정책 라우팅이나 더 구체적인 예외 경로가 없는 실습 조건에서 같은 학생망은 연결 경로로, 서버망은 기본 경로로 선택됩니다. 주소 포함 검사만을 모든 환경의 경로 선택 규칙으로 일반화하지 않습니다.
기본 경로는 다른 일치 경로가 없을 때 사용하는 후보입니다. default가 있다는 사실은 인터넷 접근이 된다는 증거가 아닙니다. 이 격리망의 단말 default는 내부 r1로만 향하고 r1에는 외부 기본 경로가 없습니다. 따라서 서버망으로 전달할 수 있어도 외부망 연결은 아직 구현되지 않았습니다. 호스트의 관리 인터페이스를 이 브리지에 연결하거나 VM 기본 공간의 경로를 바꾸지 않습니다.
같은 망에서는 목적지 IPv4의 MAC을 찾습니다
s1에서 s2로 보낼 때 10.20.10.12는 연결된 학생 /24에 속합니다. 이웃 캐시가 비어 있다면 s1은 해당 링크에 그 주소의 MAC을 묻는 ARP 요청을 보냅니다. s2가 응답하면 10.20.10.12와 s2 eth0 MAC의 대응이 생기고 s1은 그 MAC을 목적지로 Ethernet 프레임을 보낼 수 있습니다. ARP는 이름을 IPv4로 바꾸는 DNS도, IP를 자동 배정하는 DHCP도 아닙니다.
여기서 같은 링크를 만드는 것은 r1 네임스페이스 안의 brstudent입니다. s1과 s2의 veth 상대 포트 p1·p2를 그 브리지에 넣고 10.20.10.1/24는 브리지 인터페이스에 한 번만 붙입니다. 같은 /24를 라우터의 분리된 p1·p2에 따로 배정하면 단말은 직접 ARP하려는데 링크가 나뉘어 응답을 못 받을 수 있습니다. 주소표와 링크 구조를 같이 검토해야 같은 망이라는 설명이 실제로 성립합니다.
이 실습의 brstudent는 일반 브리지이고 역할별 VLAN 태그를 아직 사용하지 않습니다. 두 학생 단말은 직접 프레임을 주고받으며 IP 라우팅을 거치지 않습니다. 교직원·서버·게스트 포트는 이 학생 브리지에 넣지 않습니다. 다음 스위칭 모듈에서 역할별 포트와 VLAN 설정으로 구조를 확장할 수 있도록 현재 포트 이름과 장비 ID를 유지합니다. 지금 브리지 연결 성공을 VLAN 검증 완료로 보고하지 않습니다.
다른 망은 첫 링크의 게이트웨이를 찾습니다
s1이 server1의 10.20.30.11로 보낼 때 최종 IP 목적지는 그대로 서버입니다. 첫 Ethernet 구간에서는 게이트웨이 10.20.10.1의 MAC을 해석합니다. r1은 서버망에 직접 연결된 p4로 전달하고 이 구간에서 server1의 MAC을 찾습니다. 일반 ARP 요청을 학교 모든 서브넷에 퍼뜨려 먼 서버의 MAC을 직접 가져오는 방식이 아닙니다. 라우터는 각 연결된 링크에서 필요한 해석을 수행합니다.
서버의 응답은 반대 방향의 별도 경로 선택입니다. server1은 10.20.10.11이 자기 /24 밖이므로 게이트웨이 10.20.30.1을 사용합니다. r1은 학생 브리지로 프레임을 새로 만들어 s1에 전달합니다. 서버에 기본 경로가 빠져 있으면 요청만 도착하고 응답이 돌아오지 않을 수 있습니다. 그래서 검사기는 학생에서 서버로 보내는 시험과 서버에서 학생으로 새로 시작하는 시험을 모두 수행합니다.
게이트웨이는 단말과 같은 망의 사용 가능한 주소여야 한다는 이번 계약을 지킵니다. .1 자체에 신비한 의미가 있는 것은 아니며 관리자가 예약한 값입니다. 라우터 주소가 .254로 바뀌면 표·구성·단말 경로를 함께 바꿔야 합니다. 이번 예시는 재현 가능하게 .1로 고정합니다. 대역 밖 게이트웨이를 onlink 옵션으로 강제로 넣는 방식은 설계 검사를 피해 가므로 사용하지 않습니다.
경로 조회와 이웃 상태를 함께 읽습니다
ip -n bcnet-s1 route get 10.20.10.12는 선택된 인터페이스와 출발지 주소를 보여 줍니다. 원격 서버 조회에는 via 10.20.10.1이 나타나야 합니다. route get은 로컬 커널의 선택을 보는 명령으로 실제 응답 성공을 보장하지 않습니다. 다음으로 허가된 실습 대상에 ping을 보내고 ip -n bcnet-s1 neigh show dev eth0에서 다음 홉과 lladdr을 읽습니다. 이 세 관측의 의미를 각각 기록합니다.
이웃 상태 REACHABLE은 최근 도달 확인이 있는 항목이며 STALE은 유효한 MAC 대응이 있지만 최근 도달 확인이 부족한 상태입니다. STALE이라는 이름만 보고 연결 장애라고 결론 내리지 않습니다. INCOMPLETE는 해석 진행 중이고 FAILED는 이웃 확인 실패입니다. FAILED 원인은 잘못된 대역·단절된 링크·대상 부재·응답 차단 등으로 좁혀야 하며 단말 전원이 꺼졌다고 확정할 수는 없습니다.
캐시가 이미 있으면 새 ARP 요청이 보이지 않을 수 있습니다. 제공 검사기는 자신이 만든 bcnet-s1의 eth0 이웃 캐시만 비워 시험 조건을 맞춥니다. VM 기본 공간의 캐시를 지우지 않습니다. 같은 망 시험에서는 s2 MAC과 대조하고 원격 시험에서는 r1 brstudent MAC과 대조합니다. 임의로 정한 MAC을 출력 예시에 쓰지 않고 커널이 만든 실제 인터페이스의 값을 읽어 비교합니다.
오류를 읽고 안전하게 실습 공간을 정리합니다
로컬 starter에는 주소표 중복이 남아 있습니다. 먼저 s2 주소를 .12로 고쳐 문서 검사를 통과시킵니다. Linux VM에서 sudo bash check.sh를 실행하면 문서 검사 뒤 공간을 구성하고 ARP·왕복·격리를 검사한 다음 정리합니다. macOS에서 ENV: Linux VM에서 실행하세요가 나오면 주소 계산 오류가 아니라 실행 환경이 다르다는 뜻입니다. 권한 오류는 전용 VM에서만 관리자 권한을 사용해 해결합니다.
RTNETLINK answers: File exists는 같은 객체나 주소·경로가 이미 있을 가능성을 보여 줍니다. 제공 구성기는 기존 bcnet-* 이름을 발견하면 삭제하지 않고 중단합니다. 이전 실행의 .owned.json이 남았다면 파일과 네임스페이스 소유를 확인한 뒤 cleanup.sh를 사용합니다. 자동으로 남의 실습 공간을 지우거나 프로세스를 종료하지 않습니다. Invalid gateway는 주소·마스크·직접 연결 경로를 대조할 출발점이지 서버 응용 코드부터 고칠 신호가 아닙니다.
검증 결과에는 실행 환경, 문서 검사, 같은 망 경로·이웃 MAC, 다른 망 via·이웃 MAC, 왕복 결과, 정리 후 호스트 설정 비교를 남깁니다. 이 작성 환경에서는 Linux 네임스페이스 명령을 실행하지 않았으므로 해당 steps output은 비워 둡니다. 외부 검증자는 check.sh의 성공과 실제 로그를 확인합니다. ICMP 왕복은 DNS나 HTTP 성공을 뜻하지 않으며 서비스 허용·차단은 후속 모듈에서 별도 시험합니다.
사실 확인 참고: RFC 826 ARP. 실습 설명과 예제는 학교 프로젝트에 맞춰 직접 작성했습니다.
사실 확인 참고: ip-neighbour 설명. 실습 설명과 예제는 학교 프로젝트에 맞춰 직접 작성했습니다.
따라하기
예외 경로 없는 다음 홉 모형
일반 경로 조건을 계산하는 모형입니다. 실제 패킷은 보내지 않습니다.
import ipaddress as ip
source=ip.ip_interface('10.20.10.11/24')
gateway=ip.ip_address('10.20.10.1')
for text in ['10.20.10.12','10.20.30.11']:
dst=ip.ip_address(text)
hop=dst if dst in source.network else gateway
print('destination',dst,'arp-target',hop)실행 결과
destination 10.20.10.12 arp-target 10.20.10.12 destination 10.20.30.11 arp-target 10.20.10.1
문서와 격리 준비
starter.zip을 새 폴더에 풀고 addresses.csv의 s2 중복을 .12로 고칩니다. topology.json과 일치하는지 확인합니다. Python 검사 통과 후 전용 Linux VM에서 수동 관찰용 공간을 만듭니다. 기존 이름이 있으면 중단하고 다른 실습의 소유를 확인합니다. Linux 출력은 외부 확인 대기입니다.
python3 test_docs.py
sudo bash setup.sh직접 목적지 관측
직접 경로에 via가 없는지, ping 이후 .12의 lladdr이 s2 eth0 MAC과 같은지 확인합니다. uid나 MAC과 시간 값은 환경마다 달라 결과 원문을 별도 보관합니다.
sudo ip -n bcnet-s1 route get 10.20.10.12
sudo ip netns exec bcnet-s1 ping -c 1 -W 2 10.20.10.12
sudo ip -n bcnet-s1 neigh show dev eth0
sudo ip -n bcnet-s2 link show dev eth0게이트웨이와 응답 경로 관측
via .1과 이웃 .1의 lladdr을 r1 brstudent MAC과 대조합니다. server1에서 s1으로 시작한 ping도 확인합니다. 실패하면 주소와 경로를 확인하고 관측하지 않은 구간을 성공으로 쓰지 않습니다.
sudo ip -n bcnet-s1 route get 10.20.30.11
sudo ip netns exec bcnet-s1 ping -c 1 -W 2 10.20.30.11
sudo ip -n bcnet-s1 neigh show dev eth0
sudo ip -n bcnet-r1 link show dev brstudent
sudo ip netns exec bcnet-server1 ping -c 1 -W 2 10.20.10.11정리 후 전체 재현 검사
수동 관찰 공간을 정리한 뒤 자동 검사로 새 구성과 호스트 전후 비교를 실행합니다. 실제 Linux 로그에는 두 ARP 대상과 MAC 일치, 왕복, 호스트 설정 유지가 확인돼야 합니다. 이 작성 단계는 external로 확인 대기입니다.
sudo bash cleanup.sh
sudo bash check.sh확인 문제
실습
addresses.csv의 s2 중복 주소를 .12로 고치고 topology와 일치시킵니다. python3 test_docs.py를 실행합니다. 전용 Linux VM에서 sudo bash check.sh로 s1→s2와 s1→server1의 route get 및 이웃 캐시를 검사합니다. 같은 망 ARP .12의 MAC은 s2, 다른 망 ARP .1의 MAC은 r1 브리지여야 합니다. 수동 관찰은 README의 명령으로 진행하고 마지막에 cleanup.sh를 실행합니다. path.md에 요청·응답 IP와 Ethernet 다음 홉을 표시하고 실제 로그·환경·정리 결과를 제출합니다. 검사기는 주소·veth·브리지·격리·왕복·호스트 전후도 확인합니다. external로 Linux 실행 확인 대기입니다.
실행 명령
sudo bash check.sh
기대 결과
문서·오류 주입 통과, 두 다음 홉 MAC 일치, 역방향 ping 및 호스트 설정 유지. 실제 Linux 출력은 확인 대기입니다.
모범 답안
모범 답안 내려받기더 읽기
면접 질문
- 같은 서브넷과 다른 서브넷으로 통신하는 흐름을 설명합니다.