Windows 패킷 캡처 실무 ── pktmon·netsh trace·Wireshark 역할 나누기

「업무 앱의 서버 통신이 한 달에 몇 번 실패한다. 앱 로그에는 “타임아웃”만 나온다. 서버 쪽 로그에도 해당 시각의 오류가 없다. 재현 조건은 모른다」── 장애 조사 상담에서 이 형태는 정말 자주 만납니다.

앱 로그에는 앱이 「쓰기로 한 것」만 남습니다. 타임아웃이라는 결과는 알아도, 연결 요청(SYN)에 응답이 없었는지, 연결은 됐는데 서버가 도중에 침묵했는지, RST로 강제 종료됐는지, 애초에 패킷이 목적지까지 도달했는지는 로그의 한 단계 아래 ── 실제로 네트워크에 흐른 패킷에만 남아 있습니다. 파일이나 레지스트리 접근을 한 단계 아래에서 보는 수단이 Process Monitor라면, 통신을 한 단계 아래에서 보는 수단이 패킷 캡처입니다.

flowchart TB
    accTitle: 앱 로그의 한 단계 아래에 있는 패킷
    accDescr: 앱 로그에는 쓰기로 한 것만 남고, SYN에 응답이 없었는지, 수립 후 침묵했는지, RST로 끊겼는지, 애초에 도착했는지는 실제로 네트워크에 흐른 패킷에만 남는다는 것을 나타낸다
    log["앱 로그"] --> dec["쓰기로 한 것만 남는다"]
    dec --> to["결과는 「타임아웃」 한 마디"]
    to -->|한 단계 아래를 본다| pkt["실제로 네트워크에 흐른 패킷"]
    pkt --> q1["SYN에 응답 없음?"]
    pkt --> q2["수립 후 침묵?"]
    pkt --> q3["RST로 절단?"]
    pkt --> q4["목적지에 도착했나?"]

그림 1: 로그에 남는 것은 결과뿐이고, 타임아웃의 내역은 한 단계 아래의 패킷에만 남는다.

여기서 손이 멈추는 전형이 「고객 서버에 Wireshark를 설치할 수 없다」는 제약입니다. 변경 관리나 보안 정책의 승인이 나지 않아, 조사용 소프트웨어 추가가 현실적이지 않은 현장은 드물지 않습니다. 그러나 Windows에는 pktmon과 netsh trace라는 두 가지 패킷 캡처 수단이 표준으로 들어 있습니다. 캡처는 OS 표준 도구로 하고, 얻은 파일을 자사 PC로 가져와 Wireshark로 읽는다 ── 이 분업이면 설치가 불가능한 현장에서도 패킷을 볼 수 있습니다.

이 글에서는 중소기업 IT 담당자와 Windows 앱 개발자를 대상으로, pktmon·netsh trace·Wireshark의 역할 나누기와 각각의 실무 절차를 정리합니다. 루프백 통신의 함정, 클라이언트와 서버 중 어디에서 캡처할지, TLS로 내용이 보이지 않는 문제에 대한 태도, 앱 로그와의 대조까지, 2026년 8월 시점의 1차 정보를 바탕으로 설명합니다.

1. 먼저 결론

• 「캡처는 표준 도구, 읽기는 Wireshark」가 현장의 기본형입니다. 고객 서버에 소프트웨어를 넣을 수 없어도 pktmon과 netsh trace는 Windows 표준입니다. 캡처한 로그는 pcapng로 변환해 자사 PC의 Wireshark에서 분석합니다.¹²
• pktmon은 Windows 10 / Windows Server 2019 이후 OS에 표준으로 들어 있는 패킷 캡처 도구입니다. 필터 등록→시작→중지→변환의 네 단계로 쓰며, 네트워크 스택의 어느 구성 요소가 패킷을 버렸는지(드롭 이유)까지 알 수 있는 점이 독자적인 강점입니다.³⁴
• netsh trace는 더 오래전부터 있는 표준 도구로, 「시나리오」로 ETW 공급자 묶음을 한 번에 캡처할 수 있습니다. 패킷에 더해 Windows 구성 요소 내부 이벤트도 남고, persistent=yes면 재부팅을 넘는 캡처도 됩니다.⁵⁶
• 두 도구의 출력은 모두 ETL이라 Wireshark에서 그대로 열리지 않습니다. pktmon은 pktmon etl2pcap으로, netsh trace는 Microsoft 오픈 소스 etl2pcapng로 pcapng로 변환합니다.¹²
• Microsoft 자신도 「먼저 pktmon, 부족하면 netsh trace, 프로토콜 분석은 Wireshark」를 안내합니다. 이 글의 역할 나누기는 그 공식 권고와 같은 순서입니다.⁷
• pktmon 기본값에서는 각 패킷의 앞 128바이트만 기록됩니다. 내용까지 읽을 계획이면 시작 시 --pkt-size 0(전체 기록)을 빼먹지 마십시오.⁸
• localhost로 가는 통신은 일반 캡처에 나타나지 않습니다. NIC를 거치지 않기 때문입니다. Wireshark라면 Npcap의 루프백 어댑터, 표준 도구라면 pktmon의 스택 내부 캡처를 씁니다.⁹
• TLS로 내용이 보이지 않아도 알 수 있는 것이 많습니다. 연결 수립, TLS 핸드셰이크 성패, RST, 어느 쪽이 침묵했는지는 암호화되어 있어도 보입니다. SSLKEYLOGFILE 복호화는 개발 환경 전용입니다.¹⁰
• 캡처에는 통신 내용 그 자체가 들어갑니다. 자격 증명이나 개인정보가 포함될 수 있다는 전제로, 필요 최소 캡처와 사외 전달 전 좁히기를 절차에 넣으십시오.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 21건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 캡처의 세 가지 도구와 역할 나누기

먼저 세 도구의 역할을 한 장의 표로 정리합니다.

역할 나누기를 한 마디로 말하면, pktmon과 netsh trace는 「캡처하는」 도구, Wireshark는 「읽는」 도구입니다. Wireshark에도 캡처 기능은 있지만, 설치할 수 없는 환경에서는 쓸 수 없습니다. 반대로 표준 도구의 ETL을 텍스트로 변환해 읽을 수는 있으나, 표시 필터도 TCP 분석도 없는 환경에서 눈으로 따라가는 것은 고역입니다. 「현장에서 표준 도구로 캡처하고, pcapng로 변환해, 자사 PC의 Wireshark에서 읽는다」가 제약이 있는 현장의 최단 경로입니다.

flowchart TB
    accTitle: 캡처는 표준 도구, 읽기는 Wireshark
    accDescr: 현장에서는 pktmon 또는 netsh trace로 ETL을 캡처하고, 각각의 변환 도구로 pcapng로 바꾼 뒤, 자사 PC의 Wireshark에서 분석하는 분업을 나타낸다
    pk["pktmon(표준)"] --> etla["ETL 파일"]
    ns["netsh trace(표준)"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["자사 PC의 Wireshark에서 분석"]

그림 2: 현장에서는 표준 도구로 ETL을 캡처하고, pcapng로 변환해 자사 PC의 Wireshark에서 읽는다.

Microsoft의 패킷 손실 조사 가이드도 같은 구도입니다. 먼저 pktmon으로 캡처와 원인 분리를 하고, 그것으로 부족하면 netsh trace start scenario=InternetClient 같은 구성 요소 수준 추적으로 나아가며, 프로토콜 동작은 Wireshark로 분석한다는 순서를 보여 줍니다.⁷

아울러, 패킷에 무엇이 찍혀 있는지를 읽는 전제로 Ethernet·IP·TCP·애플리케이션 데이터라는 계층이 겹쳐 있다는 그림을 갖고 있으면 이해가 빨라집니다. 계층 해부는 「OSI 참조 모델을 선명하게 그려 보기」에서 도해합니다.

3. pktmon 실무 ── 필터→시작→중지→변환

pktmon의 기본 흐름은 네 단계입니다. 관리자 권한 터미널에서 실행합니다.

:: 1. 먼저 필터를 등록해 대상을 좁힌다(대상 서버 192.168.10.20의 TCP 8443)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. 캡처 시작. 패킷 전체를 기록하고, 1GB 링 버퍼로 덮어쓴다
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. 현상을 재현한다. 기다리는 동안 카운터로 유량과 폐기를 확인할 수 있다
pktmon counters --drop-reason

:: 4. 중지한 뒤, Wireshark용 pcapng로 변환
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. 등록한 필터를 정리한다(필터는 명시적으로 지울 때까지 남는다).
::    주의: filter remove는 이름을 지정할 수 없으며, 등록된 필터를 「모두」 삭제한다.
::    다른 조사의 필터가 남아 있는 환경에서는 먼저 pktmon filter list로 확인한다
pktmon filter remove

flowchart TB
    accTitle: pktmon의 기본 절차
    accDescr: 필터 등록으로 대상을 좁힌 뒤 캡처를 시작하고, 현상을 재현한 다음 중지하고, etl2pcap으로 pcapng로 변환한 뒤 마지막으로 등록한 필터를 삭제하는 흐름
    fa["1. filter add로 대상을 좁힌다"] --> st["2. start --capture로 캡처 시작"]
    st --> re["3. 현상을 재현한다"]
    re -.-> ct["counters로 유량과 폐기를 확인"]
    re --> sp["4. stop으로 중지"]
    sp --> cv["etl2pcap으로 pcapng로 변환"]
    cv --> rm["5. filter remove로 정리"]

그림 3: pktmon은 필터 등록에서 시작해, 캡처·중지·변환 뒤에 필터를 명시적으로 정리한다.

짚어 둘 포인트입니다.

• 필터는 캡처 시작 전에 등록합니다. Microsoft 문서도 전체 트래픽 캡처는 노이즈가 너무 많다고 하여, 시작 전 필터 적용을 강하게 권합니다. 필터는 IP 주소, 포트, MAC 주소, 프로토콜, VLAN ID 등으로 지정할 수 있고, 최대 32개까지 등록할 수 있습니다. 여러 필터는 「어느 하나에 맞으면 기록」이라는 OR 조건입니다.³
• pktmon 필터는 송신 측과 수신 측을 구분하지 않습니다. -i 192.168.10.20은 「이 주소가 송신 측 또는 수신 측인 패킷」을 뜻합니다. 방향 좁히기는 변환 후 Wireshark 표시 필터로 합니다.³
• 기본 패킷 크기는 128바이트입니다. 헤더 분석만이면 이것으로 충분하지만, 애플리케이션 데이터까지 읽으려면 --pkt-size 0으로 전체를 기록합니다.⁸
• 로그 기본은 circular(링 버퍼) 모드이고, 기본 크기는 512MB입니다. --file-size로 상한을 바꿀 수 있고, --log-mode real-time으로 바꾸면 화면에 실시간 표시되며 로그 파일은 만들지 않습니다. 먼저 실시간 표시로 「대상 통신이 보이는지」를 확인한 뒤 본 캡처를 시작하면 허탕을 줄입니다.⁸

flowchart TB
    accTitle: pktmon 필터가 동작하는 방식
    accDescr: 등록한 여러 필터는 어느 하나에 맞으면 기록이라는 OR 조건으로 동작하고, 지정한 주소는 송신 측과 수신 측을 구분하지 않으므로 방향 좁히기는 변환 후 Wireshark 표시 필터로 한다는 것을 나타낸다
    f1["필터 1"] --> orc["어느 하나에 맞으면 기록"]
    f2["필터 2"] --> orc
    f3["필터 3(최대 32개)"] --> orc
    orc --> rec["캡처 로그에 기록(OR 조건)"]
    rec -.-> nodir["송신 측과 수신 측은 구분하지 않는다"]
    nodir -.-> ws["방향은 변환 후 Wireshark에서 좁힌다"]

그림 4: 여러 필터는 OR 조건으로 동작하고, 송신 측인지 수신 측인지는 변환 후 Wireshark에서 좁힌다.

3.1. pktmon만의 강점 ── 어디에서 버려졌는지 알 수 있다

Wireshark와 다른 pktmon의 독자적 가치는, NIC의 한 지점이 아니라 네트워크 스택 안의 여러 지점에서 패킷을 잡아, 폐기(드롭)된 장소와 이유를 보고할 수 있다는 점입니다. 패킷이 어느 구성 요소까지 도달했고 어디에서 사라졌는지를 알 수 있으므로, 「MTU 불일치」「VLAN 필터」 같은 드롭 이유에서 전수 조사 없이 원인으로 갈 수 있습니다.⁴

flowchart TB
    accTitle: pktmon은 스택 안의 여러 지점에서 캡처한다
    accDescr: pktmon은 NIC의 한 지점이 아니라 네트워크 스택 안의 여러 지점에서 패킷을 잡으므로, 어느 구성 요소까지 도달했고 어디에서 폐기됐는지를 이유와 함께 보고할 수 있다는 것을 나타낸다
    pin["패킷"] --> p1["지점 1에서 캡처"]
    p1 --> p2["지점 2에서 캡처"]
    p2 --> p3["지점 3에서 폐기"]
    p3 -.-> rz["폐기 장소와 드롭 이유를 보고"]
    rz -.-> ex["예: MTU 불일치나 VLAN 필터"]

그림 5: 스택 안의 여러 지점에서 캡처하므로, 어디까지 도달했고 어디에서 버려졌는지를 이유와 함께 알 수 있다.

• pktmon list로 감시 대상이 되는 네트워크 구성 요소(NIC, 프로토콜 스택, 필터 드라이버 등)의 목록과 ID를 확인할 수 있습니다.
• pktmon counters --drop-reason으로 구성 요소별 통과/폐기 카운터와 직전 드롭 이유를 나열할 수 있습니다. 로그를 분석하기 전의 1차 원인 분리에 편리합니다.¹¹
• pktmon etl2txt로 텍스트 변환하면, 폐기된 패킷에는 drop과 dropReason(폐기 이유)이 붙어 출력됩니다.³

「앱에 닿기 전에 OS 어딘가에서 버려지고 있는 것은 아닌가」라는 의심은 Wireshark만 들여다봐서는 결론이 나지 않습니다. 예를 들어 수신 규칙 미비로 방화벽에 떨어지는 경우(「Windows 방화벽과 업무 앱」)를 가를 때 이 기능이 먹힙니다.

한 가지만 주의합니다. pktmon은 같은 패킷을 스택 안의 여러 지점에서 기록하므로, 그대로 pcapng로 변환하면 같은 패킷이 중복되어 보일 수 있습니다. pcapng 형식에는 「어느 구성 요소에서 잡았는지」 정보가 이어지지 않기 때문이며, Wireshark에서 읽을 목적이면 pktmon etl2pcap의 --component-id로 지점을 좁혀 변환하거나, 드롭만 --drop-only로 별도 파일에 넣는 것이 정석입니다.¹

flowchart TB
    accTitle: pcapng 변환에서 같은 패킷이 중복되어 보이는 이유
    accDescr: pktmon은 같은 패킷을 스택 안의 여러 지점에서 기록하고, pcapng에는 어느 구성 요소에서 잡았는지 정보가 이어지지 않아 중복되어 보일 수 있으므로, component-id로 지점을 좁히거나 drop-only로 드롭만 별도 파일로 변환하는 것이 정석임을 나타낸다
    same["같은 패킷을 여러 지점에서 기록"] --> conv["그대로 pcapng로 변환"]
    conv --> lost["캡처 지점 정보는 이어지지 않는다"]
    lost --> dup["같은 패킷이 중복되어 보인다"]
    dup --> c1["--component-id로 지점을 좁힌다"]
    dup --> c2["--drop-only로 별도 파일에"]

그림 6: 캡처 지점 정보가 pcapng에 이어지지 않으므로, 지점을 좁힌 뒤 변환하는 것이 정석이다.

4. netsh trace 실무 ── 시나리오와 ETL, 재부팅을 넘는 캡처

netsh trace는 pktmon보다 오래전부터 Windows에 들어 있는 추적 캡처 구조입니다. 특징은 「시나리오」라는 단위로, 그 문제에 관계하는 ETW 공급자 묶음을 한꺼번에 켤 수 있다는 점입니다.⁶

:: 사용할 수 있는 시나리오 목록과, 시나리오에 포함된 공급자 확인
netsh trace show scenarios
netsh trace show scenario netconnection

:: 캡처 시작. 패킷 캡처 포함, 1GB 순환 버퍼
netsh trace start scenario=netconnection capture=yes tracefile=C:\temp\nettrace.etl maxSize=1024 filemode=circular

:: 현상을 재현한 뒤 중지(병합 처리에 시간이 조금 걸린다)
netsh trace stop

• capture=yes를 붙이면 패킷 캡처가 켜지고, ipv4.address=192.168.10.20 같은 캡처 필터로 대상을 좁힐 수 있습니다. 필터 목록은 netsh trace show capturefilterHelp로 확인할 수 있습니다.⁶
• 중지하면 ETL 파일에 더해 .cab 파일이 생성됩니다. .cab에는 어댑터 구성이나 OS 빌드 등 시스템 정보가 들어 있어, 환경 정보 수집을 겸할 수 있습니다.⁶
• 추적 세션은 동시에 하나만 실행할 수 있습니다. 다른 캡처를 시작하기 전에, 계속 돌아가는 세션이 없는지 netsh trace show status로 확인합니다.⁶
• persistent=yes를 붙이면 재부팅을 넘어 세션이 유지됩니다. 「재부팅 직후 한순간만 통신이 실패한다」「시작 시 서비스 연결이 실패한다」처럼, 수동으로는 시작이 따라가지 못하는 현상의 캡처는 netsh trace만이 할 수 있는 영역입니다.⁵

flowchart TB
    accTitle: netsh trace의 시나리오 캡처
    accDescr: 시나리오를 지정해 시작하면 ETW 공급자 묶음이 한꺼번에 켜지고, capture=yes를 붙이면 패킷도 캡처되며, 중지하면 ETL 파일과 .cab 파일이 생성되는 흐름을 나타낸다
    sc["시나리오를 지정해 시작"] --> pv["공급자 묶음을 켠다"]
    sc -->|capture=yes| pc["패킷도 캡처"]
    pv --> re["현상을 재현한다"]
    pc --> re
    re --> sp["stop으로 중지"]
    sp --> etl["ETL 파일"]
    sp --> cab[".cab(시스템 정보)"]

그림 7: 시나리오로 시작하면 공급자 묶음이 한꺼번에 켜지고, 중지하면 ETL과 .cab가 생성된다.

4.1. ETL을 Wireshark에서 읽을 수 있는 형태로 ── etl2pcapng

netsh trace의 ETL은 그대로는 Wireshark에서 열리지 않습니다. Microsoft가 GitHub에 공개한 오픈 소스 도구 etl2pcapng를 쓰면, netsh trace start capture=yes로 캡처한 ETL 안의 패킷을 pcapng로 변환할 수 있습니다.²

etl2pcapng.exe C:\temp\nettrace.etl C:\temp\nettrace.pcapng

etl2pcapng는 변환할 때, 패킷에 관여한 프로세스 ID를 패킷 주석으로 써 넣습니다. 「어느 프로세스의 통신인지」를 Wireshark에서 확인할 수 있어, 같은 서버에서 여러 앱이 통신하는 환경을 가를 때 도움이 됩니다.²

다만 ETW 이벤트 쪽(시나리오 공급자가 기록한 Windows 내부 이벤트)은 pcapng로 변환되지 않습니다. 이벤트까지 읽으려면 netsh trace convert input=C:\temp\nettrace.etl로 텍스트 등으로 변환하거나, Windows Performance Analyzer 등으로 엽니다.⁵⁷

flowchart TB
    accTitle: netsh trace ETL을 읽는 길은 둘로 갈린다
    accDescr: ETL 안의 패킷은 etl2pcapng로 pcapng로 변환해 Wireshark에서 읽고, ETW 이벤트는 pcapng로 변환되지 않으므로 netsh trace convert나 Windows Performance Analyzer로 읽는다는 것을 나타낸다
    etl["netsh trace의 ETL"] --> pk["패킷"]
    etl --> ev["ETW 이벤트"]
    pk -->|etl2pcapng| pc["pcapng로 변환"]
    pc --> ws["Wireshark에서 읽는다"]
    pc -.-> pid["프로세스 ID가 주석에 남는다"]
    ev -.-> no["pcapng로는 변환되지 않는다"]
    no --> alt["convert나 WPA로 읽는다"]

그림 8: ETL 가운데 패킷은 pcapng로 변환해 읽고, ETW 이벤트는 다른 수단으로 읽는다.

5. Wireshark에서 읽는 법 입문 ── 표시 필터와 TCP 분석

캡처한 pcapng를 열면, 먼저 표시 필터로 노이즈를 깎습니다. 자주 쓰는 것을 표로 정리합니다.¹²¹³

tcp.analysis.*는 Wireshark가 TCP 시퀀스 번호를 추적해 자동 판정하는 분석 플래그입니다. 재전송, 중복 ACK, 순서 뒤바뀜, ZeroWindow 등을 기계적으로 집어 주므로, 먼저 tcp.analysis.flags를 넣어 「문제처럼 보이는 지점」을 나열하는 것이 읽기 시작의 정석입니다.¹³

타임아웃 조사에서는 다음 형태를 순서대로 찾습니다.

1. 3-way handshake는 성립했는가. SYN→SYN/ACK→ACK 세 발이 갖춰져 있는지. SYN을 반복하는데 응답이 없으면, 상대에게 닿지 않았거나 도중에 조용히 폐기된 것입니다(방화벽의 전형 패턴).
2. RST는 어느 쪽에서 날아왔는가. SYN에 대해 즉시 RST면 목적지 포트에서 아무도 대기하지 않는 상태, 수립 후의 RST면 어느 쪽이 연결을 강제 절단한 상태입니다. RST의 송신 IP가 「어느 쪽이 끊었는지」의 직접 증거가 됩니다.
3. 재전송이 이어지지 않는가. 같은 세그먼트의 재전송이 반복되는 것은 송신 측에 확인 응답(ACK)이 돌아오지 않는다는 신호입니다. 가는 데이터가 사라졌는지, 돌아오는 ACK가 사라졌는지는 한쪽 캡처만으로는 확정할 수 없습니다(그래서 다음 장의 「양쪽에서 캡처」가 먹힙니다). 재전송과 타임아웃의 심화는 「TCP 재전송으로 산업용 카메라 통신이 멈추는 원인과 구분」에서 자세히 다룹니다.
4. ZeroWindow가 나오지 않는가. 수신 측 앱이 소켓에서 데이터를 읽지 않아 수신 버퍼가 가득 찬 신호입니다. 네트워크가 아니라 수신 측 앱 설계(「TCP에서 Send한 단위마다 Receive할 수 있다는 오해」)를 의심하는 근거가 됩니다.

flowchart TB
    accTitle: 타임아웃 조사에서 찾는 형태의 순서
    accDescr: 3-way handshake 성립, RST 유무와 송신 측, 재전송 지속, ZeroWindow 순으로 확인해 원인 후보를 좁히는 흐름
    hs{"SYN에 응답이 돌아왔나?"} -->|아니요| ng["닿지 않고 폐기된 의심(FW의 전형)"]
    hs -->|예| rs{"RST가 날아왔나?"}
    rs -->|예| who["RST의 송신 측이 끊은 쪽"]
    rs -->|아니요| rt{"재전송이 이어지나?"}
    rt -->|예| ack["ACK가 돌아오지 않는 신호"]
    rt -->|아니요| zw{"ZeroWindow가 나왔나?"}
    zw -->|예| app["수신 앱이 읽지 않는 신호"]

그림 9: 핸드셰이크, RST, 재전송, ZeroWindow 순으로 형태를 찾으면, 다음에 볼 곳이 좁혀진다.

패킷을 하나씩 읽기 전에 통계 기능으로 전체를 조망하는 것도 유효합니다. [통계]→[대화(Conversations)]는 「어느 IP 쌍·포트 쌍이, 언제부터 언제까지, 얼마나 말했는지」의 목록이며, 목적 통신을 특정한 뒤 그 대화만 필터할 수 있습니다. [통계]→[입출력 그래프(I/O Graph)]는 시간 축의 유량 그래프라 「이 시각부터 한쪽 방향만 무음이 됐다」 같은 형태가 한눈에 보입니다. 대상 TCP 대화를 오른쪽 클릭해 [추적]→[TCP 스트림]을 고르면, 그 연결의 주고받음만 평문으로 이어서 읽을 수 있습니다.

flowchart TB
    accTitle: 통계로 조망한 뒤 대화를 좁힌다
    accDescr: Conversations로 어느 통신이 언제 얼마나 말했는지 나열해 목적 대화를 특정하고, I/O Graph로 무음이 된 시간대를 잡은 뒤, 대상 대화만 필터해 TCP 스트림으로 이어서 읽는 흐름을 나타낸다
    ov["통계로 전체를 조망"] --> cv["Conversations로 대화 목록"]
    ov --> io["입출력 그래프로 유량을 본다"]
    cv --> flt["목적 대화만 필터"]
    io -.-> mute["무음이 된 시각을 알 수 있다"]
    flt --> fs["TCP 스트림으로 이어서 읽는다"]

그림 10: 패킷을 하나씩 읽기 전에 통계로 조망하고, 목적 대화로 좁힌 뒤 이어서 읽는다.

6. 루프백 통신의 함정 ── localhost 목적지는 NIC를 거치지 않는다

같은 PC 안의 앱끼리 통신 ── 예를 들어 업무 앱에서 localhost:8080의 중간 서비스로 가는 연결 ── 을 조사하려다 「Wireshark에 아무것도 안 나온다」에서 막히는 것은 단골 함정입니다.

원인은 분명합니다. localhost(127.0.0.1)로 가는 통신은 물리 NIC를 거치지 않고, OS 내부 루프백 경로에서 되돌아가기 때문입니다. 물리 어댑터를 대상으로 한 일반 캡처에는 처음부터 나타나지 않습니다.⁹

flowchart TB
    accTitle: localhost로 가는 통신이 캡처에 나타나지 않는 이유
    accDescr: localhost로 가는 통신은 물리 NIC를 거치지 않고 OS 내부 루프백 경로에서 되돌아가므로, 물리 어댑터 대상의 일반 캡처에는 나타나지 않는다는 것을 나타낸다
    app["앱"] --> stack["네트워크 스택"]
    stack -->|외부 목적지| nic["물리 NIC"]
    nic --> seen["일반 캡처에 나타난다"]
    stack -->|localhost 목적지| lo["OS 내부에서 되돌아감"]
    lo -.-> miss["일반 캡처에는 나타나지 않는다"]
    lo -.-> alt["Npcap 루프백 또는 pktmon으로 캡처"]

그림 11: localhost 목적지는 NIC 앞에서 되돌아가므로, 물리 어댑터 캡처에는 처음부터 나타나지 않는다.

대응은 두 가지입니다.

• Wireshark로 캡처하는 경우: Npcap이 제공하는 「Adapter for loopback traffic capture」를 캡처 대상으로 고릅니다. Windows판 Wireshark(3.0 이후) 설치 프로그램에는 Npcap이 포함되어 있으므로, Wireshark가 있는 환경이면 추가 작업 없이 쓸 수 있습니다.⁹
• 표준 도구로 캡처하는 경우: pktmon은 NIC 바깥이 아니라 네트워크 스택 내부의 여러 지점에서 캡처하므로⁴ 루프백 통신 관측에도 쓸 수 있습니다. 확실하게 하려면, 본 재현 대기를 걸기 전에 pktmon start -c -m real-time의 실시간 표시로 목적 루프백 통신이 실제로 보이는지를 그 환경에서 확인하십시오.

함께 두 가지 혼동에도 주의합니다.

• 「localhost」는 IPv6의 ::1로 해석되는 경우가 있습니다. 앱은 IPv6의 ::1에 연결하는데, 조사하는 쪽은 127.0.0.1(IPv4)만 보고 「통신이 없다」고 오판하는 패턴입니다. 표시 필터는 ip.addr == 127.0.0.1 || ipv6.addr == ::1처럼 양쪽을 걸거나, 앱의 연결 대상을 주소로 명시합니다.⁹
• 자기 자신의 실제 IP로 가는 통신도 선에는 나오지 않습니다. 같은 PC의 192.168.10.5에서 192.168.10.5로 연결하는 경우, 목적지가 실제 IP여도 OS 내부에서 되돌아갑니다. 「실제 IP를 지정했으니 NIC를 지날 것이다」는 보장되지 않는다고 기억해 두십시오.

flowchart TB
    accTitle: localhost가 IPv6로 해석되는 혼동
    accDescr: 앱의 localhost는 IPv6의 ::1로 해석되어 연결되는 경우가 있고, 조사하는 쪽이 127.0.0.1만 보면 통신이 없다고 오판하므로, 표시 필터를 양쪽 주소에 걸거나 연결 대상을 주소로 명시해 확인한다는 것을 나타낸다
    app["앱이 localhost로 연결"] --> v6["실제로는 ::1(IPv6)로 해석"]
    look["조사하는 쪽은 127.0.0.1만 본다"] --> none["화면에 아무것도 안 나온다"]
    v6 --> none
    none --> fix1["양쪽 주소에 필터를 건다"]
    none --> fix2["연결 대상을 주소로 명시"]

그림 12: localhost가 ::1로 해석되어, 127.0.0.1만 보고 「통신이 없다」고 오판하는 혼동에 주의한다.

7. 어디에서 캡처할 것인가 ── 한쪽인가, 양쪽인가, 시각 동기

캡처의 가치는 「어디에서 캡처했는가」로 정해집니다. 판단 기준은 다음과 같습니다.

한쪽 캡처로 알 수 있는 것은 「자기 위치에서 본 사실」뿐입니다. 클라이언트 측에서 재전송이 이어져도, 보낸 패킷이 경로에서 사라졌는지, 서버에 도착했는데 응답이 사라졌는지는 구분할 수 없습니다. 양쪽에서 캡처해 대조하면, 「클라이언트는 보냈다·서버에는 도착하지 않았다」처럼 어느 쪽이 침묵했는지를 확정합니다. 책임 분계(앱인지, OS인지, 네트워크 장비인지, 상대 측인지)를 확정하고 싶은 국면에서는, 처음부터 양쪽 캡처를 준비할 가치가 있습니다.

flowchart TB
    accTitle: 한쪽 캡처와 양쪽 캡처로 알 수 있는 것
    accDescr: 한쪽 캡처만으로는 가는 패킷이 사라졌는지 돌아오는 응답이 사라졌는지 구분하지 못하고, 양쪽에서 캡처해 대조하면 어느 쪽이 침묵했는지를 확정한다는 것을 나타낸다
    one["한쪽에서만 캡처"] --> fact["자기 위치에서 본 사실만"]
    fact --> und["가는 쪽이 사라졌는지 돌아오는 쪽이 사라졌는지 구분 불가"]
    both["양쪽에서 동시에 캡처"] --> mt["대조"]
    mt --> fix["어느 쪽이 침묵했는지 확정"]
    mt -.-> pre["전제는 두 머신의 시각 동기"]

그림 13: 한쪽에서는 본 사실만 알고, 양쪽을 대조해야 비로소 책임 분계가 확정된다.

7.1. 대조의 전제는 시각 동기

양쪽 캡처를 대조하려면 두 머신의 시계가 맞아야 합니다. 캡처를 시작하기 전에 시각 어긋남을 확인하고 기록해 둡니다.

:: 시각 동기 상태(동기 대상·마지막 동기 시각)를 확인
w32tm /query /status

:: 상대 서버와의 시각 차를 실측한다(5샘플)
w32tm /stripchart /computer:sv-app01 /dataonly /samples:5

w32tm /stripchart는 자신과 상대 컴퓨터의 시각 오프셋을 표시하는 명령이며, 대조 때 「서버 측 시각이 +0.8초 어긋나 있었다」고 보정하는 근거가 됩니다.¹⁴ 어긋남이 큰 환경에서는, 먼저 시각 동기를 고친 뒤 캡처하는 편이 결국 지름길입니다.

flowchart TB
    accTitle: 대조 전 시각 차 확인 절차
    accDescr: w32tm으로 자신의 시각 동기 상태를 확인하고, stripchart로 상대 서버와의 시각 차를 실측해 기록한 뒤, 대조 때 그 어긋남을 보정의 근거로 쓰는 흐름과, 어긋남이 큰 환경에서는 먼저 시각 동기를 고친 뒤 캡처한다는 것을 나타낸다
    st["query로 동기 상태를 확인"] --> mc["stripchart로 시각 차를 실측"]
    mc --> rc["어긋남을 기록해 둔다"]
    rc --> use["대조 때 보정의 근거"]
    mc -.-> big["어긋남이 크면 먼저 동기를 고친다"]

그림 14: 캡처 전에 시각 차를 실측해 기록하고, 대조 때 보정의 근거로 쓴다.

7.2. 「언제 일어날지 모른다」에는 링 버퍼

재현 조건이 불분명한 현상은, 링 버퍼로 계속 캡처해 두고 발생하면 멈추는 것이 기본입니다.

• pktmon: 기본이 circular 모드입니다. --file-size로 상한(MB)을 지정하고, 오래된 패킷부터 덮어씁니다.⁸
• netsh trace: maxSize=1024 filemode=circular처럼 지정합니다.⁵
• Wireshark: [캡처]→[옵션]→[출력]에서 「여러 파일+링 버퍼」를 구성할 수 있습니다. 파일 크기나 시간으로 전환하면서 최신 N개만 유지하므로, 디스크 사용량에 상한을 둔 채로 장시간 돌릴 수 있습니다.¹⁵

어느 경우든, 현상이 일어나면 「발생 시각을 메모한 뒤」 캡처를 멈춘다는 운용을 현장 담당자와 공유해 두십시오. 링 버퍼는 기다릴수록 과거가 사라지므로, 발생부터 중지까지의 절차가 길면 정작 필요한 구간이 덮어씌워집니다.

flowchart TB
    accTitle: 링 버퍼로 기다려 잡는 운용
    accDescr: 재현 조건이 불분명한 현상은 링 버퍼로 계속 캡처해 기다리다가, 현상이 발생하면 발생 시각을 메모한 뒤 곧바로 중지하는 운용과, 중지가 늦으면 오래된 패킷부터 덮어써 정작 필요한 구간이 사라진다는 것을 나타낸다
    st["링 버퍼로 캡처 시작"] --> wt["계속 캡처하며 기다린다"]
    wt --> ev["현상이 발생"]
    ev --> memo["발생 시각을 메모"]
    memo --> sp["곧바로 중지"]
    wt -.-> ow["오래된 패킷부터 덮어씀"]
    ow -.-> late["중지가 늦으면 정작 필요한 구간이 사라진다"]

그림 15: 링 버퍼는 기다릴수록 과거가 사라지므로, 발생 시각을 메모하면 곧바로 멈춘다.

8. TLS로 내용이 보이지 않는 문제 ── 보이지 않아도 알 수 있는 것

요즘 업무 통신의 상당수는 TLS(HTTPS)입니다. 「암호화되어 있으면 캡처해도 소용없지 않은가」라고 생각하기 쉽지만, 타임아웃 조사에서 알고 싶은 것의 대부분은 암호화된 채로도 알 수 있습니다.

• TCP 연결이 수립됐는지(3-way handshake)
• TLS 핸드셰이크가 어디까지 진행됐는지 ── ClientHello에 대해 ServerHello가 돌아왔는지, 핸드셰이크 중에 RST나 알림으로 끊겼는지
• ClientHello에 실리는 연결 대상 호스트 이름(SNI)과, 협상된 TLS 버전
• 수립 후, 어느 쪽이 송신을 멈췄는지. 무응답의 위치, 재전송, RST, 정상 종료(FIN)인지

즉 「연결되지 않는다」「도중에 끊긴다」「응답이 돌아오지 않는다」를 가를 때, 내용 복호화는 거의 필요 없습니다. 암호화로 잃는 것은 “무엇을 말했는지”이고, “누가 언제 침묵했는지는” 남습니다.

flowchart TB
    accTitle: TLS 캡처에서 보이는 것과 보이지 않는 것
    accDescr: 암호화로 보이지 않게 되는 것은 애플리케이션 데이터 내용뿐이고, TCP 연결 수립, TLS 핸드셰이크 성패, SNI나 TLS 버전, RST와 어느 쪽이 침묵했는지는 암호화된 채로도 알 수 있다는 것을 나타낸다
    tls["TLS 통신의 캡처"] --> vis["보이는 것"]
    tls --> hid["보이지 않는 것"]
    vis --> v1["TCP 연결 수립"]
    vis --> v2["TLS 성패와 SNI"]
    vis --> v3["RST와 어느 쪽이 침묵했는지"]
    hid --> h1["앱 데이터의 내용"]

그림 16: 암호화로 잃는 것은 내용뿐이고, 통신의 뼈대는 TLS 그대로도 읽을 수 있다.

그래도 내용이 필요하면, Wireshark에는 SSLKEYLOGFILE 환경 변수로 내보낸 세션 키로 TLS를 복호화하는 구조가 있습니다. 다만 대응하는 것은 Firefox·Chrome·Chromium 계열 Edge 브라우저나 OpenSSL 계열 라이브러리 등 일부 구현이고, Windows 표준 SChannel(WinHTTP나 WinINET을 쓰는 앱)은 이 구조에 대응하지 않습니다.¹⁰ 세션 키가 파일로 써진다=그 파일을 손에 넣은 사람이 통신을 모두 복호화할 수 있다는 성질상, 프로덕션에서 쓸 수단이 아니라 개발 환경에서의 재현·디버그용으로 자리매김해야 합니다.

flowchart TB
    accTitle: SSLKEYLOGFILE 복호화의 구조와 제약
    accDescr: SSLKEYLOGFILE로 내보낸 세션 키를 쓰면 Wireshark에서 TLS를 복호화할 수 있지만, 대응하는 것은 Firefox나 Chrome 계열 등 일부 구현이고 SChannel은 비대응이며, 키 파일을 가진 사람은 통신을 복호화할 수 있으므로 개발 환경 한정 수단임을 나타낸다
    env["SSLKEYLOGFILE을 설정"] --> key["세션 키를 파일로 내보낸다"]
    key --> ws["Wireshark에서 복호화해 읽는다"]
    key -.-> risk["키를 가진 사람은 전부 복호화할 수 있다"]
    risk -.-> dev["개발 환경 한정으로 자리매김"]
    env -.-> sup["대응은 일부 TLS 구현만"]
    sup -.-> sch["SChannel은 비대응"]

그림 17: 세션 키 내보내기로 복호화할 수 있지만, 대응 구현이 한정되고, 키의 성질상 개발 환경 한정 수단이다.

참고로, 사내 프록시를 거치는 통신에서는 캡처에 찍히는 목적지가 프록시 서버가 되고, CONNECT 터널 안을 TLS가 흐르는 형태가 됩니다. 애초에 앱이 어느 프록시로 향하는가라는 앞단의 문제는, 같은 날 공개한 자매 글 「사내 프록시와 Windows 앱 ── WinINET, WinHTTP, .NET의 프록시 해석을 정리한다」에서 정리합니다.

9. 앱 로그와의 대조 ── 시각을 같은 축에 늘어놓는다

캡처만으로 결론이 나는 일은 사실 많지 않습니다. 실무의 결정타는 앱 로그의 한 줄과 패킷의 한 왕복을, 같은 시간 축 위에 늘어놓는 것입니다.

절차는 다음 형태입니다.

1. 앱 로그에서 현상의 시각을 특정합니다(예: 10:23:41에 타임아웃 예외). 타임아웃 값이 30초라면 시작은 10:23:11경이어야 합니다.
2. Wireshark의 시각 표시를 [표시]→[시각 표시 형식]→[날짜 시간]으로 바꾸고, 해당 구간을 표시 필터로 좁힙니다(frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00"처럼 시각으로도 좁힐 수 있습니다).
3. 그 구간에서 5장의 순서(핸드셰이크→RST→재전송→ZeroWindow)를 확인합니다. 「로그의 타임아웃 시각 30초 전에 SYN을 보냈고, 이후 SYN 재전송만」까지 대조되면, 로그의 “타임아웃”이 「이 캡처 지점에는 응답이 전혀 돌아오지 않았다」는 관측 사실로 바뀝니다(SYN이 상대에게 닿지 않았는지, 응답 SYN/ACK가 돌아오는 길에서 사라졌는지는 이 캡처 지점만으로는 확정할 수 없습니다. 확정하려면 서버 측 캡처와 대조합니다).
4. 캡처 시각과 로그 시각의 어긋남(7.1절에서 잰 시각 차, 로그의 타임존 표기)을 반드시 보정합니다. 대조 오차가 몇 초면 다른 통신을 범인으로 만듭니다.

flowchart TB
    accTitle: 앱 로그와 패킷의 대조 절차
    accDescr: 앱 로그에서 현상 시각을 특정하고, 타임아웃 값에서 시작 시각을 역산하고, Wireshark에서 해당 구간을 좁혀 형태를 순서대로 확인한 뒤, 시각 어긋남을 보정하여 같은 시간 축에 늘어놓는 절차를 나타낸다
    lg["1. 로그에서 현상 시각을 특정"] --> rev["타임아웃 값에서 시작을 역산"]
    rev --> flt["2. 해당 구간을 표시 필터로 좁힌다"]
    flt --> chk["3. 5장의 순서로 형태를 확인"]
    chk --> adj["4. 시각 어긋남을 보정"]
    adj --> done["로그의 한 마디가 관측 사실로 바뀐다"]

그림 18: 로그 시각에서 구간을 좁히고, 형태를 확인하고, 시각 차를 보정하여 같은 축에 늘어놓는다.

조사 결과를 제3자(벤더, 회선 사업자, 고객의 네트워크 담당)에게 넘길 때는, 필터로 노이즈를 깎은 뒤 넘기는 것이 예절이자 안전책입니다. Wireshark에서 대상 대화만 표시 필터로 좁히고, [파일]→[지정 패킷 내보내기]에서 「표시된 패킷만」을 저장하면, 필요한 범위만의 작은 pcapng를 만들 수 있습니다.

마지막으로 취급 주의입니다. 캡처 파일에는 통신 내용 그 자체가 들어갑니다. 평문 프로토콜의 자격 증명, HTTP의 Cookie나 API 키, 메일이나 전표의 내용, 개인정보가 포함될 수 있습니다. 다음 세 가지를 캡처 절차와 세트로 정해 두십시오.

• 필요 최소 캡처: 캡처 전 필터(3장·4장)로 대상을 좁히고, 기간도 최소로 한다. 「일단 전부」를 고객 환경에서 하지 않는다
• 넘기기 전 좁히기: 대상 대화만 내보내고, 무관한 제3자 통신을 넣지 않는다. 기밀 부분이 남으면 마스킹이나 다른 수단을 수신 측과 합의한다
• 보관과 삭제: 캡처 파일의 보관 장소·기한·삭제를 정하고, 조사 완료 후 지운다

flowchart TB
    accTitle: 캡처 파일을 넘기기 전의 세 가지 결정
    accDescr: 캡처에는 통신 내용 그 자체가 들어가므로, 캡처 전 필터와 기간으로 필요 최소로 좁히고, 넘기기 전에 대상 대화만 추출해 무관한 통신을 넣지 않으며, 보관 장소와 기한을 정해 조사 완료 후 삭제한다는 세 가지를 캡처 절차와 세트로 정한다는 것을 나타낸다
    cap["캡처에는 통신 내용이 들어간다"] --> p1["캡처는 필요 최소로"]
    cap --> p2["넘기기 전에 대상만 추출"]
    cap --> p3["보관 기한을 정해 삭제"]
    p2 -.-> exp["표시 필터로 좁혀 내보내기"]

그림 19: 최소 캡처, 넘기기 전 좁히기, 보관과 삭제의 세 가지를 캡처 절차와 세트로 정한다.

10. 정리

• 앱 로그의 「타임아웃」 한 단계 아래에는, 실제로 네트워크에 흐른 패킷이라는 사실이 있습니다. SYN에 응답이 없는지, RST로 끊겼는지, 재전송이 이어졌는지, ZeroWindow인지에 따라 다음에 볼 곳이 바뀝니다.
• Wireshark를 넣을 수 없는 현장에서도 Windows 표준 pktmon과 netsh trace로 캡처할 수 있습니다. 캡처는 표준 도구, 읽기는 자사 PC의 Wireshark라는 분업이 기본형입니다.
• pktmon은 필터 등록→pktmon start --capture→pktmon stop→pktmon etl2pcap의 네 단계. 기본값에서는 128바이트로 잘리므로 내용까지 읽으려면 --pkt-size 0을 빼먹지 마십시오. 드롭 지점과 이유를 알 수 있는 것은 pktmon만의 강점입니다.
• netsh trace는 시나리오로 ETW 공급자를 묶어 캡처하고, persistent=yes로 재부팅을 넘길 수 있습니다. ETL은 etl2pcapng로 pcapng로 변환해 읽습니다.
• Wireshark에서는 tcp.analysis.flags부터 읽기 시작해, 핸드셰이크·RST·재전송·ZeroWindow 순으로 형태를 찾습니다. Conversations와 I/O Graph로 조망한 뒤 좁히면 빠릅니다.
• localhost 목적지는 NIC를 거치지 않으므로 보통은 캡처되지 않습니다. Npcap의 루프백 어댑터나 pktmon의 스택 내부 캡처를 씁니다.
• 양쪽에서 캡처해 대조하면 「어느 쪽이 침묵했는지」가 확정됩니다. 그 전제는 시각 동기(w32tm)입니다. 재현 조건이 불분명한 현상은 링 버퍼로 기다려 잡습니다.
• TLS에서도 통신의 뼈대는 보입니다. 복호화(SSLKEYLOGFILE)는 개발 환경 한정 수단으로 자리매김하고, 캡처 파일 자체도 기밀로 최소 캡처·좁히기·삭제까지 운용에 넣으십시오.

패킷 캡처는 「네트워크 전문가의 도구」로 보이기 쉽지만, 실제로는 앱 로그와 대조해야 비로소 의미가 나는, 앱 측 조사 도구입니다. 다음에 “타임아웃” 한 마디에서 조사가 멈추면, 그 한 단계 아래를 보러 가십시오.

관련 글

• TCP 재전송으로 산업용 카메라 통신이 멈추는 원인과 구분
• TCP에서 Send한 단위마다 Receive할 수 있다는 오해 ── 바이트 스트림으로 다루기 위한 수신 설계
• OSI 참조 모델을 선명하게 그려 보기 ── HTTP 요청 1개를 7계층으로 해부한다
• Process Monitor(ProcMon) 실전 가이드 ── 「설정이 읽히지 않는다」「ACCESS DENIED」를 10분 만에 특정한다
• Windows 방화벽과 업무 앱 ── 인바운드 규칙은 인스톨러에서 등록한다
• 사내 프록시와 Windows 앱 ── WinINET, WinHTTP, .NET의 프록시 해석을 정리한다

관련 상담 영역

합동회사 코무라소프트에서는, 「업무 앱 통신이 가끔 실패하는데 원인을 모른다」「고객 환경에서만 일어나는 연결 오류의 원인을 가르고 싶다」와 같은 통신에서 비롯된 장애 조사를 다룹니다. 패킷 캡처의 캡처 설계(어디에서·무엇을·얼마나 캡처할지)부터 Wireshark 분석, 앱 로그와의 대조, 앱 측 수정까지를 한 흐름으로 대응합니다.

• Windows 앱 개발
• 결함 조사·원인 분석
• 기술 상담·설계 리뷰
• 문의

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

Wireshark를 설치할 수 없는 고객 서버에서 패킷 캡처를 하려면 어떻게 하면 되나요?

Windows 표준 pktmon 또는 netsh trace를 쓰면 소프트웨어를 추가로 설치하지 않고 캡처할 수 있습니다. pktmon이라면 관리자 권한 터미널에서 필터를 등록하고, pktmon start --capture로 캡처를 시작한 뒤 pktmon stop으로 중지합니다. 얻은 ETL 파일은 pktmon etl2pcap으로 pcapng 형식으로 변환할 수 있으므로, 분석은 자사 PC로 가져와 Wireshark에서 하면 됩니다. 「캡처는 표준 도구, 읽기는 Wireshark」라는 역할 나누기가, 설치 제약이 있는 현장의 기본형입니다.

pktmon과 netsh trace 중 어느 쪽을 써야 하나요?

pktmon을 쓸 수 있는 OS(Windows 10 / Windows Server 2019 이후)라면 먼저 pktmon을 권합니다. 명령이 단순하고, 네트워크 스택의 어느 구성 요소에서 패킷이 폐기됐는지(드롭 이유)까지 확인할 수 있으며, pcapng 변환도 단독으로 끝나기 때문입니다. netsh trace가 유리한 경우는 pktmon이 없는 구형 OS에서 캡처할 때, 시나리오 형태로 Windows 구성 요소의 ETW 이벤트까지 한꺼번에 남기고 싶을 때, persistent=yes로 재부팅을 넘어 캡처하고 싶을 때입니다. Microsoft의 문제 해결 자료도 먼저 pktmon, 부족하면 netsh trace라는 순서를 안내합니다.

localhost(127.0.0.1)로 가는 통신이 Wireshark에 나타나지 않는 이유는 무엇인가요?

localhost로 가는 통신은 물리 NIC를 거치지 않고 OS 내부 루프백 경로에서 되돌아가기 때문입니다. 물리 어댑터를 대상으로 한 일반 캡처에는 처음부터 나타나지 않습니다. Wireshark에서는 Npcap이 제공하는 「Adapter for loopback traffic capture」를 고르면 루프백 통신을 캡처할 수 있습니다. pktmon은 네트워크 스택 내부에서 캡처하므로 루프백 통신 관측에도 쓸 수 있습니다. 또한 「localhost」가 IPv6의 ::1로 해석되어, 127.0.0.1만 보고 있던 화면에 아무것도 나오지 않는 혼동도 흔하니 주소를 명시해 확인하십시오.

HTTPS(TLS) 통신은 패킷 캡처로 내용을 볼 수 있나요?

애플리케이션 데이터의 내용은 암호화되어 보이지 않습니다. 다만 TCP 연결의 수립과 종료, TLS 핸드셰이크의 성패, RST에 의한 절단, 어느 쪽이 응답을 멈췄는지와 같은 「통신의 뼈대」는 암호화되어 있어도 알 수 있으므로, 타임아웃 조사의 대부분은 TLS 그대로 진행할 수 있습니다. 내용까지 필요하면 SSLKEYLOGFILE로 복호화하는 수단이 있지만, 대응하는 것은 Firefox나 Chrome 계열 등 일부 TLS 구현이고 Windows 표준 SChannel은 비대응입니다. 비밀 키 정보를 파일로 쓰는 구조이므로, 쓰더라도 개발 환경 한정으로 생각하십시오.

캡처한 파일을 사외 지원 창구에 보내도 되나요?

그대로 보내는 것은 위험합니다. 캡처에는 통신 내용 그 자체가 들어가며, 평문 프로토콜의 자격 증명, Cookie, API 키, 개인정보가 포함될 수 있습니다. 먼저 캡처 단계에서 필터와 기간을 좁혀 필요 최소로 만들고, 넘기기 전에 Wireshark 표시 필터로 대상 통신만 추출해 내보내십시오. 그래도 남는 내용은 수신 측과 상의한 뒤 기밀 부분의 처리(마스킹, 다른 수단으로 제공)를 정한 다음에 넘겨야 합니다. 캡처 파일의 보관 기한과 삭제도 미리 정해 두는 것을 권합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.