ping·traceroute의 한계

왜 ping부터 결론 내리면 위험한가

교무실에서 학교 웹 화면이 열리지 않는다고 신고했습니다. 학생 단말에서 ping이 실패하자 서버 전원을 의심하기 쉽습니다. 그러나 ping은 ICMP Echo 요청과 응답을 시험합니다. 웹은 TCP와 HTTP를 사용하므로 정책과 처리 경로가 다를 수 있습니다. 이번에는 같은 출발지와 목적지에서 ICMP만 막은 뒤 HTTP가 계속 성공하는지 대조하여, 어떤 검사로 어느 범위까지 확인했는지 적습니다.

이 모듈의 실습 준비

로컬 압축 파일에는 앞 NAT 미션 solution이 들어 있습니다. Python 문서 검사는 맥에서 python3 test_diagnosis.py로 실행합니다. 실제 망은 Ubuntu 24.04 Linux VM에서 sudo bash check.sh로 구성합니다. iproute2, nftables, ping, dig, curl, traceroute, tcpdump가 필요하며 첫 모듈의 설치 안내를 따릅니다. 호스트 실제 회선과 실습 브리지를 연결하지 않습니다. 이 맥에서는 Linux 네임스페이스를 실행하지 않아 external 확인 대기로 표시합니다.

관측 대상부터 고정합니다

이 학교망의 학생 s1 현재 주소는 DHCP 예약 10.20.10.111이고 학교 서버는 10.20.30.11입니다. 예전 주소표의 .11을 현재 학생 주소로 쓰지 않습니다. 실행기는 lease.json과 앞 서비스 검사를 먼저 확인합니다. 출발지 공간은 bcnet-s1입니다. 호스트에서 같은 IP를 대상으로 명령을 실행하면 실습망이 아니라 호스트 경로를 검사할 수 있으므로 명령 앞의 ip netns exec를 확인합니다.

ping 결과가 말하는 범위

Echo 응답이 도착하면 해당 시점의 ICMP 왕복 전달을 확인합니다. TCP 8080 수신 소켓이나 웹 본문이 정상이라는 증거는 아닙니다. 응답이 없으면 요청이 못 갔거나 응답이 못 왔거나 대상 또는 정책이 Echo를 처리하지 않았을 수 있습니다. 손실이라는 이름도 이 검사에서 정한 대기 시간 안에 응답을 얻지 못했다는 뜻으로 읽습니다. 장애 후보를 좁히려면 서비스 요청을 같은 조건으로 추가합니다.

의도적으로 다른 결과 만들기

제공 실행기는 r1의 실습 전달 체인에 ICMP Echo 요청 DROP만 추가합니다. 학생에서 ping을 두 번 보내고 각 응답을 1초 기다립니다. 같은 동안 curl로 school.test를 서버 .11에 고정하여 TCP 8080 HTTP를 요청합니다. 이때 이름 해석을 우회하므로 DNS 상태와 섞이지 않습니다. DROP 테이블을 제거한 뒤 ping도 다시 확인합니다. 주입 전·중·후를 비교해야 단순한 우연 실패와 통제 실험을 구분할 수 있습니다.

종료 코드와 오류 문장 읽기

실행 자료의 exit, stdout, stderr를 함께 읽습니다. 이 Linux iputils ping 조건에서 응답을 받지 못하면 종료 코드 1을 기대하고 도구나 권한 오류는 별도 실패로 취급합니다. curl의 28은 정해진 제한 안에 요청을 완료하지 못했다는 단서이지 방화벽의 직접 증거는 아닙니다. Connection refused는 거절 응답을 받은 단서입니다. Network is unreachable는 로컬 경로 선택부터 확인할 이유가 됩니다.

traceroute의 질문

traceroute는 TTL을 달리한 탐사에 대한 응답으로 홉을 관측합니다. 일반 UDP 방식과 TCP SYN 방식은 탐사 프로토콜과 포트가 다릅니다. UDP 고포트가 차단되면 웹 포트 탐사와 다른 결과가 나올 수 있습니다. 제공 검사기는 UDP 방식과 TCP 8080 방식을 각각 기록합니다. -n은 주소를 이름으로 바꾸는 조회를 생략하여 이름 서비스의 지연을 경로 측정에 섞지 않게 합니다.

별표를 장애 위치로 읽지 않습니다

별표는 해당 탐사에 대해 대기 시간 안에 응답을 받지 못했다는 표시입니다. 그 홉이 데이터 전달을 중단했다는 뜻은 아닙니다. 중간 장비가 ICMP 오류 응답을 제한하거나 응답의 귀환 경로가 다를 수 있습니다. 뒤 홉의 응답이 보이면 적어도 그 탐사는 더 멀리 갔다는 단서입니다. 끝까지 별표여도 웹 요청 결과를 함께 확인하기 전에는 서비스 중단을 확정하지 않습니다.

홉 시간은 구간 시간을 뜻하지 않습니다

홉마다 표시된 시간은 탐사 출발부터 그 응답이 돌아오기까지의 시간입니다. 서로 다른 탐사이고 응답 처리 우선순위도 다를 수 있으므로 인접 홉 값의 차이를 링크 지연이라고 부르지 않습니다. 중간 홉만 큰 수치이고 목적지 응답은 작다면 해당 장비의 응답 생성 조건을 후보로 남깁니다. 한 번의 값으로 회선 혼잡을 확정하지 않고 같은 방법과 시간대의 반복 자료를 확보합니다.

TCP 탐사도 웹 전체 검사는 아닙니다

서비스 포트로 SYN 탐사를 보내면 UDP와 다른 정책 조건을 확인할 수 있습니다. 하지만 TLS 인증서, HTTP 상태, 본문 내용까지 검증한 것은 아닙니다. TCP 탐사가 목적지 응답을 얻었어도 curl의 HTTP 결과를 별도로 보관합니다. 이 레슨은 평문 학교 웹 8080을 대상으로 하고 HTTPS 검증 범위는 앞 서비스 모듈에 있습니다. 도구 이름보다 시험한 프로토콜과 경계를 적는 습관이 필요합니다.

비교표를 만드는 방법

증거마다 출발지 공간, 대상 주소, 프로토콜과 포트, 시도 수, 대기 제한, 주입 상태, 종료 코드를 한 행에 적습니다. ICMP 차단 자료와 HTTP 성공 자료의 시간이 겹치는지도 확인합니다. 다른 단말의 웹 성공을 학생 단말 성공처럼 쓰지 않습니다. trace-udp.json과 trace-tcp.json은 실제 실행에서 생성되며 지금 예측 홉을 채워 넣지 않습니다. 별표 개수 대신 다음에 확인할 후보를 기록합니다.

흔한 실행 실수

Operation not permitted는 네임스페이스나 raw 소켓 권한이 부족할 수 있습니다. 이를 원격 서버 장애로 보고하지 않습니다. traceroute: command not found는 VM에 도구가 없다는 뜻입니다. ENV: Linux VM required는 실행 환경 문제입니다. 기존 bcnet 이름 충돌이면 실행기가 중단하며 남의 공간을 지우지 않습니다. 소유 파일과 첫 모듈의 정리 절차를 확인한 뒤 자기 실습을 다시 준비합니다.

검사 완료와 정리

check.sh는 앞 경로·서비스·NAT를 회귀 검사한 뒤 진단 실험을 수행합니다. 캡처는 8초, 제공 서비스는 최대 120초에 스스로 종료하며 실행기는 wait로 기다립니다. 실행 시간이 남아 있다고 프로세스를 강제 종료하지 않습니다. finally에서 임시 정책을 제거하고 소유 공간만 정리합니다. 호스트 전후 스냅샷이 다르면 정상 완료로 제출하지 않고 남은 설정을 확인합니다.

제출할 판단

진단 문장을 ICMP 요청은 제한 시간 내 응답 없음, 같은 출발지의 TCP 8080 HTTP 본문은 수신 성공처럼 나눕니다. 두 관측으로 웹 서버가 항상 정상이라는 장기 결론은 내리지 않습니다. 다음 담당자가 동일 조건으로 재실행할 수 있도록 명령과 실제 자료 경로를 붙입니다. diagnosis.json의 두 단정 값을 false로 고치는 것만으로 실제 망이 검증되지는 않으며 VM 증거를 함께 제출합니다.

도구 동작 참고: ping 문서, traceroute 문서에서 종료 상태와 탐사 응답 표시를 확인할 수 있습니다.