요청 흐름 캡처

화면 오류를 패킷 질문으로 바꿉니다

학생이 학교 웹 화면을 열 때 이름 질의가 나갔는지, 서버에 SYN이 갔는지, 응답이 돌아왔는지를 구분합니다. 브라우저 오류 문장만으로는 이 세 경계가 잘 보이지 않습니다. 이번 목표는 허가된 학생 인터페이스와 학교 서버 인터페이스에서 동일 요청을 캡처하고, 시간순 기록으로 전달의 마지막 확인 지점을 설명하는 것입니다. 캡처가 없다는 말에는 관측 위치와 필터 조건이 따라야 합니다.

캡처 위치가 증거의 범위를 정합니다

학생 bcnet-s1의 eth0는 학생이 송수신하는 프레임을 보여 주고 서버 bcnet-server1의 eth0는 서버 경계 프레임을 보여 줍니다. 호스트의 eth0는 이 흐름의 관측 위치가 아닙니다. 라우터 VLAN 인터페이스도 사용할 수 있지만 동일 프레임이 여러 위치에 보이면 별개 요청으로 세지 않습니다. 제공 실행기는 양 끝 파일을 이름으로 구분해 저장하여 요청의 도착 여부를 서로 대조할 수 있게 합니다.

ARP가 먼저 필요한 이유

다른 서브넷의 서버에 가는 학생은 서버 MAC이 아니라 자기 게이트웨이 MAC을 알아야 합니다. IPv4 목적지는 서버 .30.11이어도 학생 링크의 다음 홉은 .10.1입니다. 이 관계를 보려면 학생 eth0의 이웃 캐시를 비우고 새 요청을 보냅니다. 실행기는 소유 학생 공간에서만 ip neigh flush를 사용합니다. ARP가 안 보였다고 항상 문제가 있는 것은 아니며 이미 캐시에 정보가 있으면 조회를 생략할 수 있습니다.

DNS는 별개의 왕복입니다

이 실습은 학생이 .30.1의 DNS에 school.test A 질의를 보내 .30.11을 받습니다. DNS 질의와 응답은 거래 ID와 질문 이름, 주소·포트를 대조합니다. 단순히 53번 패킷 하나가 보인다는 이유로 조회가 성공했다고 쓰지 않습니다. 정상 응답 코드와 답 주소를 함께 확인합니다. TCP 웹 연결의 목적지가 답 주소와 맞는지도 확인해야 이름 해석과 연결 요청을 같은 사건으로 묶을 수 있습니다.

캐시와 요청 생성 조건

제공 flow 검사에서는 먼저 dig로 명시적 질의를 보내고 다음 curl은 --resolve로 같은 답 주소를 지정합니다. curl이 그 dig의 결과를 자동으로 소비하는 구조가 아닙니다. 이름 조회와 웹 연결의 두 왕복을 관측하기 위해 통제한 순서입니다. 실제 브라우저는 자체 캐시나 운영체제 캐시 때문에 질의를 생략할 수 있으므로 DNS 패킷 부재를 즉시 애플리케이션 오류로 판정하지 않습니다.

TCP의 시작을 읽습니다

새 연결에서는 학생 SYN, 서버 SYN-ACK, 학생 ACK를 같은 끝점 쌍으로 찾습니다. tcpdump에서 [S]는 SYN, [S.]는 SYN과 ACK를 함께 가진 패킷의 표시입니다. 숫자 주소와 포트를 유지하는 -nn을 쓰면 이름 조회와 서비스명 변환을 피할 수 있습니다. 응답 방향의 출발지 포트는 8080이고 목적지 포트는 학생의 임시 포트입니다. 포트를 방향 없이 읽으면 별개 흐름을 잘못 붙일 수 있습니다.

연결 이후 확인할 것

핸드셰이크가 관측되면 그 연결 수립 구간을 확인했습니다. 이후 요청 데이터와 서버 응답, 종료까지는 따로 봅니다. 연결만 되고 본문이 오지 않는 경우도 있으므로 flow-http.json의 실제 본문과 종료 상태를 캡처와 연결합니다. HTTP 상태가 오류여도 TCP 연결은 성공했을 수 있습니다. 이 레슨에서는 school ready 본문을 수신한 흐름을 대상으로 하며 연결 정상과 앱 정상이라는 표현을 구분합니다.

필터를 넓힌 뒤 좁힙니다

수집 시 ARP·DNS·TCP를 함께 담고 읽을 때 arp or udp port 53 or tcp port 8080으로 선택합니다. 처음부터 tcp port 8080만 저장하면 앞선 ARP와 DNS를 복구할 수 없습니다. 논리식을 셸의 작은따옴표로 감싸 or를 한 필터 인자로 전달합니다. DNS 장애 전용 5353번 자료는 이 필터 밖이므로 udp port 5353으로 다시 읽습니다. 목적지가 달라졌다면 host .11만 찾는 필터도 단서를 놓칩니다.

저장과 읽기의 차이

pcap은 바이너리 자료이며 cat으로 읽는 문서가 아닙니다. -r 파일로 해석하고 -tttt로 시각을 표시합니다. 제공 capture.py는 Ethernet 프레임을 8초 동안 저장하는 단기 수집기입니다. 준비 파일을 만든 뒤 요청을 시작하므로 요청 전에 수집이 켜졌는지 확인할 수 있습니다. txt는 원본 pcap에서 파생된 보기이며 원본은 편집하지 않습니다. 본문을 출력하는 옵션은 학습용 평문 요청에만 사용합니다.

시간순 표 작성

표의 열은 파일명, 관측 시각, 출발지 끝점, 목적지 끝점, 프로토콜, 사건, 해석으로 정합니다. ARP는 IP 포트가 아니라 요청 대상과 MAC 관계를 기록합니다. DNS 답 뒤에 SYN이 나갔는지 같은 VM의 시각으로 정렬합니다. 두 파일에 같은 패킷이 있는 것은 양 끝 관측이지 두 요청이라는 뜻이 아닙니다. 반복 SYN은 동일 흐름의 재시도인지 끝점을 먼저 대조합니다.

패킷 부재의 해석

클라이언트에 SYN이 있지만 서버에 없으면 중간 전달 문제 후보가 생깁니다. 그러나 먼저 서버 캡처의 인터페이스, 시작 시각, 필터, 수집 성공을 확인합니다. 빈 파일은 관측 실패일 수도 있습니다. 서버에 SYN이 있어도 응답 부재만으로 로컬 방화벽과 반환 경로를 모두 구분하지 못합니다. 경로표, 소켓 상태, 정책 카운터가 필요한 이유를 진단 기록에 남깁니다.

수집 자체의 제한

캡처 프로세스가 패킷을 놓칠 수 있고 짧은 저장 길이는 헤더 뒤 데이터를 잘라 낼 수 있습니다. NIC 처리에 따라 송신 체크섬 표기가 이상해도 실제 회선 손상이라고 단정하지 않습니다. 이번 수집기는 전체 프레임을 읽지만 운영망 수집 성능을 검증한 도구는 아닙니다. TLS에서는 암호문만 보여 요청 본문을 바로 읽을 수 없으며 암호화 실패 여부도 연결·인증 자료로 따로 확인합니다.

권한과 자료 취급

AF_PACKET 권한 오류는 수집기 기동 실패입니다. No such device는 지정한 공간에서 인터페이스 이름이 맞는지 볼 이유가 됩니다. 파일이 존재해도 헤더만 있는 pcap이면 요청 수집에 성공한 것이 아닙니다. 학생 역할 이름은 가상이며 로그인 쿠키가 포함될 수 있어 자료를 공개 게시하지 않습니다. 캡처 범위를 실습 eth0로 한정하고 운영망이나 다른 사용자의 트래픽을 수집하지 않습니다.

제출물의 완성 조건

flow-client.pcap과 flow-server.pcap에서 요청·응답의 끝점을 찾아 여섯 사건을 기록합니다. ARP, DNS 질의·답, TCP 연결, HTTP 흐름의 관측 범위를 구분합니다. diagnosis.json의 flow_order는 학습용 새 요청 순서이지 모든 앱에서 강제되는 순서가 아닙니다. 결과가 다르면 캐시와 수집 시작 조건부터 재확인합니다. 서재의 도구 옵션 목록은 더 읽기로 보내고 제출물에는 이 요청을 설명하는 필터만 남깁니다.

필터와 파일 읽기 참고: tcpdump 문서를 사용하며, 실제 원인 판단은 이 실습의 대조 자료로 제한합니다.