허용과 차단의 대조 시험

왜 실패만으로 차단 성공이라 하지 않는가

게스트의 관리 포트 연결이 실패했습니다. 방화벽이 막았을 수도 있지만 서버 리스너가 없거나 반환 경로가 깨졌을 수도 있습니다. 이번 레슨은 실패를 의도한 차단과 연결하는 대조 실험입니다. 같은 출발지·목적지·프로토콜·포트로 필터 적용 전 성공을 얻고 적용 중 실패와 규칙 카운터를 관측한 뒤 제거 후 성공을 다시 얻습니다. 세 관측을 한 행에 묶어야 다른 담당자도 정책이 실제 원인인지 판단할 수 있습니다.

검사 목록을 정책 행에서 가져옵니다

policy.csv의 id를 시험 이름으로 사용합니다. 학생 웹·교직원 웹·교직원 관리·학생 DNS·교직원 DNS·게스트 DNS·게스트 외부 웹 일곱 허용 행을 실제 요청합니다. 학생 DHCP 주소 재취득 한 건을 추가해 허용은 여덟 건입니다. 게스트 웹·게스트 관리·학생 관리·게스트 UDP·학생 UDP·교직원 UDP 여섯 차단 행을 각각 검사합니다. 역할 하나의 성공을 다른 역할에 복사하지 않고 출발지 네임스페이스를 행마다 고정합니다.

정상 리스너를 먼저 준비합니다

학교 서버에는 기존 웹 8080과 관리 모의 HTTP 2222, 임시 UDP echo 9999가 필요합니다. ss -ltn과 ss -lun으로 바인딩 주소와 포트를 읽고 readiness 조건을 만족한 뒤 요청을 시작합니다. 포트 문자열이 보인다는 사실만으로 상대 역할의 요청 성공을 대신하지 않습니다. 실제 대조 요청이 성공해야 경로와 소켓이 해당 조건에서 동작한다고 말할 수 있습니다. 실행기의 readiness timeout은 리스너 준비 실패이며 정책 음성 검사 결과가 아닙니다.

TCP는 애플리케이션 본문까지 확인합니다

curl은 --noproxy로 환경 프록시를 우회하고 --connect-timeout 1, --max-time 2로 기다림을 제한합니다. school ready 또는 policy service ready 본문을 기대합니다. 단순 TCP 연결 성공은 HTTP 응답이 올바른지 말하지 않습니다. HTTP 503도 연결 자체는 성공할 수 있으므로 실제 응답을 함께 읽습니다. 이번 정상 대조 서비스는 정해진 본문을 돌려주고, 차단 중에는 본문 대신 제한 시간 종료를 기대해 정책과 애플리케이션 실패를 섞지 않습니다.

UDP는 실제 응답을 기다립니다

UDP 포트에 데이터를 보냈다는 성공만으로 응답 서비스가 열렸다고 판단하지 않습니다. DNS는 dig가 school.test의 A 답 10.20.30.11을 받는지 확인합니다. UDP 9999는 policy-echo라는 짧은 payload를 보내고 동일한 bytes의 응답을 확인합니다. reply가 없으면 클라이언트가 1초 뒤 TIMEOUT과 종료 코드 28을 냅니다. 이 28은 실습 클라이언트가 정한 값이며 모든 UDP 도구의 공통 종료 코드가 아닙니다.

카운터는 전후 차이로 읽습니다

같은 drop 규칙의 packets를 요청 직전에 읽고 직후 다시 읽습니다. 후자가 커야 해당 검사 중 그 규칙이 실제 패킷을 처리했다는 단서가 됩니다. TCP는 재전송 때문에 한 요청이 여러 패킷으로 기록될 수 있으므로 증가량이 정확히 1이라고 요구하지 않습니다. 이름 없는 체인 전체 카운터를 보면 다른 역할의 트래픽을 섞기 쉽습니다. 이번은 rule comment를 id와 맞추고 실행을 순차 진행해 관련 행을 찾도록 구성합니다.

오류 문장의 의미를 분리합니다

curl 종료 코드 28은 지정한 제한 시간 안에 요청을 마치지 못했다는 뜻입니다. Connection refused나 종료 코드 7은 연결 실패 단서이며 리스너 부재 또는 reject 같은 원인도 검토합니다. permission 오류와 command not found는 시험 환경 문제입니다. nft 구문 오류는 정책이 설치되기 전의 실패입니다. 이 과제에서는 실제 대조 성공·정해진 timeout·대상 drop 카운터 증가가 모두 있어야 음성 시험 통과로 처리하므로 어떤 실패든 성공이라고 계산하지 않습니다.

적용 전 대조는 같은 출발지입니다

교직원이 관리 서비스에 접속된다고 게스트의 차단 전 대조가 완료된 것은 아닙니다. 출발지별 왕복 경로가 다르거나 중간 정책이 다를 수 있습니다. 실행기는 앞으로 차단할 게스트와 학생 요청도 필터가 없는 상태에서 그대로 실행해 성공 자료를 저장합니다. 같은 IP와 포트를 유지하고 필터 적용 여부만 바꿔 비교합니다. 정책 외 조건이 바뀌었다면 단일 원인 결론을 보류하고 리스너·라우팅·NAT 상태를 다시 확인합니다.

가상 외부 성공에는 NAT가 필요합니다

가상 WAN에는 학교 /24의 반환 경로가 없습니다. school_policy_nat는 게스트 외부 웹을 198.51.100.1로 SNAT하여 응답이 돌아오게 합니다. 이 NAT를 대조 단계부터 유지하고 필터만 적용·제거하므로 게스트 외부 성공을 같은 조건으로 비교합니다. NAT와 필터를 동시에 바꾸면 어느 변경이 결과를 만들었는지 분리하기 어렵습니다. 실습의 외부 주소를 실제 인터넷 접근 성공이라고 적지 않고 가상 외부 리스너 본문 수신이라고 기록합니다.

상태와 신규 요청을 구별해 관측합니다

정상 대조 요청을 끝내고 새 프로세스로 정책 중 요청을 생성합니다. 상태 추적 규칙이 남아 있어도 다른 임시 출발지 포트의 신규 요청은 해당 서비스 행을 검사해야 합니다. 오래 열린 연결을 재사용하면 새 연결 차단과 결과가 다를 수 있습니다. reply 카운터는 응답 처리의 보조 자료이며 어느 사용자에게 관리자 권한을 부여했는지 증명하지 않습니다. 테스트 목적이 신규 요청 제한인지 기존 세션 정지인지 표의 판단 칸에 명시합니다.

증거 파일을 읽는 방법

evidence/firewall/에는 행별 control.json, policy.json, 차단 행의 restored.json과 listeners.txt, counters.json, summary.json이 실제 실행에서 생성됩니다. JSON은 exit·stdout·stderr를 나눠 보관합니다. summary에는 기대 동작과 종료 코드, 카운터 전후값이 들어갑니다. 파일 이름만 존재한다고 성공이라 하지 않고 본문과 실제 숫자를 읽습니다. output이 빈 레슨 단계는 VM에서 아직 관측하지 않은 구간이며 예측 출력을 복사해 채우지 않습니다.

복원 후 시험이 말하는 것

school_filter 제거 뒤 여섯 차단 요청이 다시 성공하면 같은 리스너가 계속 살아 있고 정책 제거로 통신이 복원됐다는 근거를 더합니다. 이는 운영망에서 항상 안전하게 규칙을 제거하라는 지시가 아닙니다. 격리된 소유 공간에서 원인 분리를 위한 실험입니다. 복원 요청도 실패하면 리스너 수명·서버 반환 경로·NAT·정리 시점을 확인합니다. 실패 자료를 삭제하거나 성공했던 옛 자료로 바꾸지 않고 이번 실행의 상태를 그대로 남깁니다.

이전 진단 기록을 보존합니다

m07의 DNS 오주소·반환 경로 누락·8080 DROP 자료는 다른 원인을 비교할 출발점입니다. 이번 정책에서 게스트 웹 차단은 의도한 동작이며 학생 웹 차단은 회귀 실패입니다. 같은 timeout이라도 역할·목적·기대 결과가 다르므로 사건의 의미가 달라집니다. 정책 행의 업무 이유와 관측된 증상을 연결하면 정상 제한을 장애로 오인하는 일을 줄일 수 있습니다. 앞 단계 산출물을 지우지 않고 새 정책 증거 경로를 추가합니다.

제출과 인계 판단

실행 전 문서 검사 통과, Linux 실제 시험 여부, 관측한 허용·차단 건수, 복원과 정리 결과를 분리해 보고합니다. 네임스페이스를 실행하지 못했으면 external 대기로 남깁니다. 사람이 보는 기준은 단순 점수보다 정상 대조와 drop 근거가 같은 행에 연결됐는지입니다. 동일 VLAN 단말 간 격리·IPv6·라우터 output 정책은 범위 밖이라는 한계도 적습니다. 다음 담당자가 원인을 다시 확인할 수 있도록 명령·입력 조건·실제 JSON 경로를 한 묶음으로 전달합니다.