실패 지점 분리

원인을 맞히기보다 후보를 줄입니다

학생의 학교 웹 실패를 DNS, 서버 반환 경로, 전달 정책 세 사건으로 나누어 재현합니다. 증상은 비슷해도 수정할 위치는 다릅니다. 이번 목표는 정상 기준을 확인한 다음 한 가지 고장만 주입하고 실패 검사·성공 대조·캡처·복구를 연결한 사건 기록을 만드는 것입니다. 어느 시험이 가설을 지지했는지 설명하지 않은 설정 변경은 진단 완료로 보지 않습니다.

정상 기준을 준비합니다

제공 실행기는 앞 모듈의 학교 서비스와 NAT를 회귀 검사합니다. 학교 DNS는 .30.1에서 school.test를 .30.11로 답하며 웹은 서버 TCP 8080에서 school ready 본문을 보냅니다. 학생의 현재 주소는 .10.111입니다. baseline-dns.json과 baseline-http.json을 주입 전에 저장합니다. 이전부터 실패하던 구성을 새 고장 사례로 제출하면 고장 하나의 영향을 분리할 수 없습니다.

첫 갈래는 이름입니다

이름 요청이 실패하면 실제로 어떤 resolver에 무슨 이름을 질의했는지 먼저 확인합니다. NXDOMAIN과 시간 초과, 정상 코드에 잘못된 주소가 든 경우는 다릅니다. 이 사건은 정상 DNS를 건드리지 않고 r1의 단기 5353번 DNS가 .30.99를 답하도록 만듭니다. dig에 -p 5353을 붙인 주입 조건을 기록합니다. 이를 표준 53번 서비스에서 실측한 장애로 표현하지 않습니다.

DNS 가설을 대조합니다

잘못된 응답 주소로 웹을 요청하면 실패하고, 정상 서버 주소를 --resolve로 지정하면 같은 학생에서 성공하는지 비교합니다. 단순 IP URL로 요청하면 Host 헤더와 TLS 이름 조건이 달라질 수 있으므로 이름을 유지하며 주소만 바꿉니다. 이 레슨은 HTTP 8080이고 TLS 인증 검증을 우회하는 실험이 아닙니다. DNS를 복구한 뒤 정상 53번 답과 웹을 함께 재검사합니다.

다음 갈래는 연결입니다

이름 답이 .30.11이고 학생에서 SYN이 반복되는데 연결이 완료되지 않으면 경로와 정책, 수신 상태 후보가 남습니다. DNS가 맞다는 이유로 서버가 정상이라고 확정하지 않습니다. 서버 ss -ltn에 8080이 있는지 확인하고 서버 자체 요청을 대조합니다. 이 성공은 서버 프로세스 동작의 단서이며 학생에서 서버까지의 모든 경로를 증명하지는 않습니다.

반환 경로 고장을 만듭니다

server1은 기본 경로 대신 명시적인 학생 대역 반환 경로를 사용합니다. 실행기는 10.20.10.0/24 경로 하나만 제거하고 나머지 역할 경로는 보존합니다. 학생에서 SYN이 서버에 도착하는지 양 끝 캡처를 비교하고 서버 경로표를 저장합니다. 반환 경로가 없으면 연결이 완료되지 않을 수 있지만 어떤 응답 패킷이 보일지는 실제 커널 결과를 읽습니다. SYN-ACK을 관측하지 않았는데 있었다고 적지 않습니다.

반환 경로의 증거를 묶습니다

route-fault-server.pcap의 SYN, route-fault-table.txt의 학생 경로 부재, route-local.json의 서버 자체 HTTP 성공을 함께 봅니다. 이 조합은 서비스가 수신 중인데 학생으로의 응답 경로가 달라졌다는 가설을 지지합니다. 서버가 응답을 생성하지 않은 후보도 단일 캡처만으로는 남으므로 경로 복원 후 동일 학생 요청이 성공하는지 확인합니다. 변경과 재검사 사이에 다른 설정은 바꾸지 않습니다.

정책 고장은 다른 관측을 만듭니다

r1의 실습 전달 체인에 학생 .111에서 서버 .11의 TCP 8080으로 가는 요청만 counter drop을 추가합니다. DNS UDP 질의는 계속 성공하며 학생 SYN이 서버 eth0에는 도착하지 않는지 확인합니다. 정책 카운터가 증가했는지 자료를 읽습니다. 서버 캡처가 비어 있다는 이유만으로 정책을 확정하지 않고 수집 준비와 정확한 인터페이스를 먼저 검증합니다.

정책의 범위를 확인합니다

방화벽은 출발지·목적지·프로토콜·포트와 방향을 함께 보아야 합니다. NAT가 성공했다고 학교 내부 정책까지 허용되지는 않습니다. 이번 DROP은 학교 서버 8080만 대상으로 하고 가상 WAN NAT 테이블은 별도로 남겨 둡니다. policy-counter.txt와 baseline-http.json을 대조하고 테이블 제거 후 policy-repaired-http.json을 확인합니다. 상세 통신 정책 작성과 허용·차단 행렬은 다음 모듈에서 이어갑니다.

오류 메시지를 원인명으로 바꾸지 않습니다

curl 28은 제한 시간 초과입니다. DNS 오주소와 반환 경로 누락, DROP 모두 연결 시간 초과로 보일 수 있어 출력 하나를 원인으로 쓰지 않습니다. Could not resolve host는 클라이언트 이름 해석 경계를 조사할 단서이고 Connection refused는 거절 응답을 받은 단서입니다. 각 문장에 해당 명령, 대상, 종료 코드와 성공 대조를 붙여 다음 시험을 고릅니다.

사건 기록의 구조

incidents.json은 id, stage, symptom, hypothesis, failed, control, capture, fix, retest를 갖습니다. symptom에는 관측한 실패를, hypothesis에는 아직 확인 중인 원인을, fix에는 실제 바꾼 항목을 적습니다. 파일 이름만 나열하지 말고 해당 파일에서 읽은 시각과 행을 설명에 덧붙입니다. test_diagnosis.py는 단계와 자료 연결 계약을 확인하며 캡처 내용을 사람 대신 모두 해석하는 검사가 아닙니다.

한 건씩 주입하고 복구합니다

DNS 단기 서버는 스스로 종료하며 정상 resolver는 유지됩니다. 반환 경로와 DROP 테이블은 각각 finally에서 복원·제거합니다. 두 고장을 동시에 남기면 첫 복구 뒤에도 연결이 실패하여 진단 순서가 흐려집니다. 각 사건 뒤 정상 DNS와 웹, 수신 소켓을 회귀 검사합니다. 복구 후 한 번의 성공을 모든 사용자의 정상화로 과장하지 않고 이 실습 대상의 동일 요청이 회복됐다고 씁니다.

증거가 충분하지 않을 때

학생 SYN만 있고 서버 캡처에 없지만 카운터도 없으면 전달 경로나 캡처 오류 후보를 남깁니다. 평균 지연이 늘었다고 경로 고장으로 단정하지 않습니다. 다음 검사로 어느 후보를 분리할지 문서에 적고 필요하면 양 끝 경로표와 수집 준비를 다시 확인합니다. 확인하지 않은 설정을 정상이라고 채우기보다 미확인 범위를 명시하는 것이 다른 담당자의 재현 시간을 줄입니다.

미션으로 완성합니다

m06 solution을 출발점으로 세 사건 기록과 도구 한계, 손실·지연 표를 추가합니다. 문서 시험의 starter 실패를 고친 뒤 VM 검사로 실제 pcap과 JSON을 생성합니다. 같은 실행에서 나온 자료만 묶고 구성도와 현재 주소가 다른 부분을 설명합니다. 최종 제출에는 복구 명령, DNS·TCP·HTTP 회귀 결과, 남은 불확실성을 포함합니다. 원인 단계와 근거를 연결할 수 있어야 다음 정책 모듈의 판단 자료로 사용할 수 있습니다.