변경 실패와 복구 리허설

복구는 이전 결과를 다시 얻는 작업입니다

백업을 복사하고 명령이 끝났다는 이유로 복구 성공을 선언할 수 없습니다. 학생이 이름으로 학교 웹을 읽고 게스트는 내부 웹에 접근하지 못하는 이전 동작이 돌아왔는지 확인해야 합니다. 이번 리허설은 변경 전 학교망 시험, 정적 파일 백업, 임시 사본의 잘못된 대체 게이트웨이, 오류 탐지, 새 폴더 복원, 같은 통신 시험 재실행 순서입니다. 복구된 파일과 실제 통신이라는 두 층의 완료 기준을 분리해 기록합니다.

오류 주입 위치를 좁힙니다

실습은 임시 source의 resilience.json에서 backup_gateway_suffix를 2에서 9로 바꿉니다. r2는 .2를 사용하므로 .9는 준비된 대체 경로를 가리키지 않습니다. test_resilience.py가 backup gateway must be .2라는 메시지로 거절해야 합니다. 이 단계는 잘못된 설정을 적용 전에 찾는 검사입니다. 패킷 시간 초과를 직접 관측한 것이 아닙니다. 원본 작업 폴더와 신뢰한 backup의 내용은 바꾸지 않으므로 실패 원인과 복구 대상이 하나로 좁혀집니다.

파일 전용 리허설로 순서를 익힙니다

file-rehearsal.py는 임시 폴더에 resilience.json과 설정 검사 파일만 복사합니다. 백업을 만든 뒤 게이트웨이를 손상시키고 설정 검사가 실패하는지 확인합니다. 그다음 새 restored 폴더를 만들고 변경 목록이 비어 있는지, 설정 검사가 다시 통과하는지 확인합니다. 마지막 NETWORK_NOT_TESTED는 파일 검사만 했다는 범위 표시입니다. 실행 시 얻은 종료 코드와 목록 크기를 보고하되 이 작은 예제로 DNS나 TCP가 정상이라고 말하지 않습니다.

검증 실패를 증거로 보존합니다

설정 검사의 비정상 종료는 오류 주입 단계에서 기대한 결과입니다. handover_run.py는 stderr에 backup gateway must be .2가 있는지도 확인하여 우연한 Python 환경 오류를 성공으로 오인하지 않습니다. injected-failure.txt에는 실제 실패 출력이 저장됩니다. 같은 종료 코드 1이어도 파일이 없거나 권한이 없으면 계획한 결함이 아닐 수 있습니다. 원인 문구와 주입 전후 configuration-diff.json을 함께 읽으면 어떤 변경을 탐지했는지 설명할 수 있습니다.

무결성을 먼저 확인합니다

복원 전 manifest의 파일 집합·SHA-256·권한을 대조합니다. CHECKSUM_OR_MODE가 나오면 백업 파일이 기준선과 달라졌으므로 복원을 멈춥니다. 문제 파일에 맞춰 manifest를 다시 생성하면 원래 기준선의 신뢰를 없애게 됩니다. 독립적으로 보관한 사본과 변경 기록을 확인하고 정상 백업을 확보한 뒤 진행합니다. 이 도구는 백업 목록 자체의 위조를 막는 서명 시스템이 아니므로 목록도 접근 권한과 보관 절차로 보호한다는 전제가 있습니다.

복원 폴더에서 망을 다시 구성합니다

최종 check.sh는 첫 m09 기준선을 끝내고 정리한 뒤 정적 루트 파일을 백업합니다. 복원 폴더에는 m09-check.sh와 그 아래 이전 모듈 검사기들이 함께 들어 있습니다. m09-check.sh를 새 폴더에서 실행하면 구성 스크립트로 학교망을 만들고 이전 정책과 서비스 시험, v30 장애 전환 및 복귀 시험을 다시 수행합니다. 설정 파일만 검사한 순수 단계와 실제 네임스페이스에서 새 소켓을 만든 단계가 구분되어 있습니다. 이미 남은 소유 망이 있으면 충돌을 해결하기 전 새 시험을 시작하지 않습니다.

허용과 차단을 둘 다 비교합니다

학생 DNS 답이 예상 주소이고 TCP 연결·HTTP 본문이 성공하는지 확인합니다. 게스트가 내부 웹에 접근하지 못하는 동작도 이전처럼 유지되어야 합니다. 허용 검사만 보면 복구 과정에서 방화벽이 빠져 모든 접근이 열린 것을 정상으로 판단할 수 있습니다. m09 회귀는 같은 VLAN과 다른 VLAN의 링크 분리, policy.csv의 전달 행, 주·대체 경로의 새 연결을 확인합니다. restored-evidence의 단계별 경로와 정책 카운터를 요청 결과와 연결합니다.

연결 상태는 파일 복원 범위 밖입니다

파일 백업에는 기존 TCP 소켓과 NAT 연결 상태를 넣지 않습니다. m09는 WAN 기존 소켓과 신규 소켓 결과를 별도로 기록하며 두 SNAT 주소가 다르고 상태를 공유하지 않습니다. 최종 인계에는 session-after.json의 실제 관측을 적습니다. 새 웹 요청이 성공했다는 사실로 진행 중이던 다운로드가 유지됐다고 주장하지 않습니다. DNS와 DHCP도 r1에 남아 있으므로 r2가 모든 서비스를 승계했다고 설명할 수 없습니다. 리허설에서 보호한 장애 범위를 좁혀 적습니다.

같은 조건으로 다시 시험합니다

앞에서 실패했던 요청과 복구 뒤 요청은 출발지·목적지·포트·이름을 맞춰야 합니다. route 사건은 서버 로컬 웹 대조와 학생의 반환 경로 복원 후 요청을 묶습니다. policy 사건은 정상 학생 요청과 차단 주입, 제거 후 재검사를 연결합니다. 다른 출발지에서 성공한 결과로 같은 사건이 해결되었다고 쓰지 않습니다. 복원 뒤 DNS·route·policy 사건의 실패·대조·복구·캡처 파일이 실제 생성됐는지도 검사하므로 다음 담당자가 원인 판단을 다시 확인할 수 있습니다.

정리 상태도 완료 기준입니다

소유 서버는 제한 시간 또는 stop 파일을 통해 스스로 닫습니다. 실습은 프로세스에 종료 신호를 보내지 않으며 앞 모듈의 제한 시간 때문에 기다릴 수 있습니다. 네임스페이스 pids가 비고 .owned.json이 제거되며 호스트 snapshot이 실행 전후 같아야 합니다. 정리가 실패하면 통신 시험이 성공해도 다음 리허설을 바로 진행하지 않습니다. ENV 메시지는 도구나 VM 권한 준비 실패이므로 네트워크 정책 결함과 분리해서 보고합니다.

최종 결과의 상태를 정확히 씁니다

live-result.json은 새 실제망 실행 시작에 지우고 모든 복원·회귀·증거 검사가 끝난 뒤에만 passed로 만듭니다. 이번 맥 검증에서는 그 파일을 생성하지 않습니다. change.md에 external 대기와 파일 검사 통과를 각각 적고 Linux 실행 뒤 UTC 시각·담당자·종료 상태·중단 판단을 추가합니다. elapsed_seconds는 첫 기준선 이후의 리허설 측정값이며 전체 작업 창과 다릅니다. 이 레슨의 목표는 오류를 발견하고 복원과 통신 재검사를 재현하는 것이며 시간을 꾸며 채우는 것이 아닙니다.