Step 6. 네트워크 확인 — 내 컴퓨터의 대외 연락망 점검

Level 0 — 컴퓨터 조작과 구조의 이해 | 난이도 ★★☆☆☆ | 예상 소요 시간: 2–3시간

전제: Step 5 완료. Windows PowerShell 5.1 또는 Windows의 PowerShell 7, 인터넷 연결이 필요합니다.

• 실습 범위: 내 PC의 설정·연결을 조회하고, 아래 명시된 대상에 소량의 ICMP·DNS·TCP 진단 요청을 보냅니다. 네트워크 설정을 바꾸거나 임의의 주소 대역을 탐색하지 않습니다.
• 결과물: 주소·게이트웨이·DNS 메모와 성공·실패를 함께 기록한 network-report.txt.
• 핵심: IP, 기본 게이트웨이, DNS를 구별하고, 한 가지 검사로 인터넷 전체를 정상·고장이라고 단정하지 않습니다.

내 PC가 어디와 통신하는지 확인하는 일은 장애와 침해 사고 조사의 출발점입니다. 다만 주소나 연결 개수만으로 악성 여부를 판단할 수는 없습니다. 오늘은 무엇을 관찰했고 어디까지 확인했는지 설명하는 연습을 합니다. 회사·학교에서는 허용된 진단 대상과 정책을 따르세요. 보고서의 IP·MAC·장치 이름은 로컬에 보관하고 공개 캡처에서는 가리세요.

1. 학습 목표

• 내 PC의 IP 주소, 기본 게이트웨이, DNS 서버를 찾아 역할을 설명합니다.
• ICMP 응답, DNS 조회, TCP 연결 검사를 나눠 읽습니다.
• netstat에서 로컬·상대 주소와 TCP 상태를 해석합니다.
• 정상 결과와 예상한 이름 조회 실패가 모두 남는 보고서를 만듭니다.

2. 배경 지식 — 주소와 경로

2-1. IP 주소와 사설 주소

192.168.0.15는 IPv4 주소의 예입니다. IPv6는 ::1처럼 다른 표기를 씁니다. IP 주소는 인터페이스에 설정되며 한 PC에 여러 개가 있을 수 있습니다. IPv4 사설 대역은 10.0.0.0/8, 172.16.0.0/12(172.16~172.31), 192.168.0.0/16입니다. 집뿐 아니라 회사·실습망·VPN 연결망에서도 사용합니다.

가정용 IPv4 NAT 환경에서는 공유기가 내부 주소를 변환해 통신을 중계합니다. 통신사 NAT를 한 번 더 거칠 수도 있어 공유기의 외부 주소가 항상 공인 IP인 것은 아닙니다. Tailscale에서 볼 수 있는 100.64.0.0/10은 공유 주소 공간으로, 100으로 시작하는 모든 주소를 뜻하지 않으며 RFC 1918 사설 대역과도 구별합니다.

2-2. 기본 게이트웨이와 DNS

기본 게이트웨이는 더 구체적인 경로가 없을 때 패킷을 넘길 다음 홉입니다. 가정에서는 흔히 공유기지만 주소는 환경마다 다릅니다. VPN과 여러 어댑터가 있으면 목적지마다 사용 경로가 달라질 수 있습니다.

DNS는 이름에 대한 레코드를 조회하는 체계입니다. A는 IPv4, AAAA는 IPv6 주소 레코드입니다. 응답 주소는 여러 개일 수 있고 시점·지역·VPN의 DNS 설정에 따라 달라집니다. 이름으로 핑이 성공해도 캐시 등으로 주소를 얻었을 수 있으므로 DNS 서버를 방금 직접 조회했다는 증거는 아닙니다. 브라우저의 보안 DNS 설정은 운영체제 조회와 다를 수도 있습니다.

2-3. 포트와 검사 범위

TCP·UDP 포트는 통신의 끝점을 구분합니다. 443은 흔히 HTTPS, 22는 흔히 SSH에 쓰이지만 포트 번호가 앱의 정체나 안전성을 보증하지 않습니다. ICMP에는 TCP·UDP와 같은 포트 개념이 없습니다.

3. 따라 하기

3-1. 주소·게이트웨이·DNS 확인

ipconfig /all

어댑터 이름과 함께 IPv4 주소, 기본 게이트웨이, DNS 서버를 메모합니다. 아래는 가상 예시입니다. Windows 표시 언어와 어댑터 종류에 따라 줄 이름이 달라집니다.

IPv4 address:   192.168.0.15
Default gateway: 192.168.0.1
DNS server:      192.168.0.1

사설 IP가 있다고 인터넷 연결이 확인된 것은 아닙니다. 연결 상태, 기본 게이트웨이와 목적지 경로를 함께 봅니다. MAC 주소는 링크 계층 주소이며 변경·무작위화될 수 있어 영구적인 장치 일련번호로 취급하지 않습니다.

3-2. PowerShell 객체로 보기

Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, InterfaceAlias, PrefixLength, AddressState

이번에는 필요한 속성을 명시해 표로 고릅니다. 이 명령만으로 게이트웨이와 DNS 서버까지 조회되는 것은 아닙니다. 다음 명령을 함께 사용합니다:

Get-NetIPConfiguration

127.0.0.1은 IPv4 루프백으로 내 PC 안을 가리킵니다. localhost는 이름이며 IPv6 루프백 ::1로도 해석될 수 있습니다. vEthernet이나 VPN 어댑터가 여러 개 있는 것은 가능한 구성입니다. 주소만 보고 하나를 무조건 ‘진짜 카드’로 고르지 마세요.

3-3. ICMP 응답 확인 — Test-Connection

먼저 내 PC의 루프백에 두 번 요청합니다:

Test-Connection 127.0.0.1 -Count 2 -Quiet

-Quiet는 표 대신 True/False를 반환합니다. 한 대상에 대해 True이면 보낸 요청 중 하나 이상에 응답이 왔다는 뜻입니다. 모든 요청 성공이나 인터넷 연결을 뜻하지 않습니다. 다음은 외부 ICMP 대상 한 곳입니다:

Test-Connection 8.8.8.8 -Count 2 -Quiet

8.8.8.8은 Google Public DNS 주소이지만 핑은 그 DNS 서비스를 질의하지 않습니다. False나 시간 초과는 ICMP 차단·응답 정책·경로 문제 등으로 생길 수 있습니다. 반대로 True여도 다른 사이트의 DNS·TCP·TLS는 실패할 수 있습니다. PowerShell 5.1과 7은 상세 출력 형식과 매개변수가 다르므로 여기서는 두 버전에 공통인 위치 인자·Count·Quiet를 씁니다.

3-4. DNS와 TCP를 따로 확인

Resolve-DnsName google.com -Type A -DnsOnly

A 레코드가 반환되는지, 오류라면 이름 없음인지 시간 초과인지 확인합니다. 응답 IP나 개수는 예시와 같을 필요가 없습니다. 이어 같은 이름의 TCP 443 연결을 검사합니다:

Test-NetConnection -ComputerName google.com -Port 443 -InformationLevel Detailed

TcpTestSucceeded와 실제 선택된 RemoteAddress를 읽습니다. 이 명령에서 PingSucceeded가 False여도 TcpTestSucceeded는 True일 수 있습니다. 서로 다른 대상인 8.8.8.8 핑과 google.com 핑을 비교해 DNS 고장이라고 단정했던 방식은 올바르지 않습니다.

3-5. 연결 목록 읽기 — netstat

netstat -an | Select-String ESTABLISHED

이것은 ESTABLISHED 상태의 TCP 행입니다. 인터넷뿐 아니라 LAN·VPN·루프백 통신도 포함될 수 있습니다. UDP 및 HTTP/3의 QUIC 트래픽 전체를 이 필터로 볼 수는 없습니다. 다음 행은 해석용 가상 예시이며 실행 대상이 아닙니다:

TCP  192.168.0.15:51234  203.0.113.10:443  ESTABLISHED

왼쪽은 로컬 IP와 포트, 오른쪽은 상대 IP와 포트, 마지막은 TCP 상태입니다. 443이라고 해서 특정 회사·브라우저·정상 HTTPS 연결이라고 판정할 수 없습니다. 국내·해외 주소라는 분류만으로도 신뢰 여부를 알 수 없습니다.

문자열 443 검색은 1443·임시 로컬 포트 등도 잡습니다. 상대 포트가 정확히 443인 항목은 객체 속성으로 고릅니다:

Get-NetTCPConnection |
  Where-Object {$_.State -eq 'Established' -and $_.RemotePort -eq 443} |
  Select-Object -First 20 LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess

OwningProcess는 소유 프로세스 ID입니다. 조회 시점에는 이미 프로세스나 연결이 사라졌을 수도 있습니다. 최대 20개 표시이며 0개도 가능한 결과입니다. 브라우저는 연결을 재사용하거나 유지하고 QUIC를 사용할 수 있어 탭 하나를 열고 닫을 때 행 하나가 반드시 생기고 사라지는 것은 아닙니다.

3-6. 설정을 바꾸지 않고 이름 조회 실패 관찰

없는 주소라고 임의의 사설 IP를 고르면 실제 장비에 요청할 수 있습니다. 실패 연습에는 용도가 예약된 .invalid 이름을 사용합니다. 끝의 점은 완전한 DNS 이름임을 나타냅니다.

try {
  Resolve-DnsName no-such-host.invalid. -Type A -DnsOnly -ErrorAction Stop
  "Unexpected answer: inspect the resolver; do not treat this as the expected result."
} catch {
  "Name query failed: $($_.FullyQualifiedErrorId)"
}

일반적인 결과는 이름 없음 오류이며 현재 검증 환경에서는 DNS_ERROR_RCODE_NAME_ERROR가 나왔습니다. 시간 초과나 다른 오류라면 그 결과를 그대로 읽으세요. 응답이 나온다면 예상과 다른 resolver 동작을 확인해야 합니다. try/catch는 오류를 잡아 메시지로 바꾸는 준비된 패턴입니다. 오류 처리 자체는 뒤 수업에서 더 배웁니다.

4. 미션과 연습문제

미션 — 내 네트워크 관찰 보고서

새 전용 폴더 안에 network-report.txt를 만드세요. 수집 시각, 어댑터 설정, 외부 ICMP 응답, DNS A 조회, TCP 443 검사, .invalid 조회 실패, ESTABLISHED 행 수를 기록합니다. 성공과 실패 모두 학습 결과입니다. 핑 실패를 감추거나 네트워크 설정을 바꿔 억지로 성공시킬 필요는 없습니다.

연습문제

1. 8.8.8.8 핑은 성공하고 google.com 핑은 실패했습니다. DNS 고장이라고 확정할 수 있나요?
2. 위 가상 netstat 행에서 로컬·상대 끝점과 상태를 말해 보세요. 정상 웹 방문이라고 확정할 수 있나요?
3. 127.0.0.1 핑 성공이 증명하는 범위는 어디까지인가요?
4. 169.254.x.x 주소를 발견하면 무엇을 확인해야 하나요?
5. 화면에 보인 오류가 명령 | Out-File 파일에도 자동 저장되나요?

$netlab = Join-Path $HOME ('infosec-step06-' + [guid]::NewGuid().ToString('N'))
New-Item -ItemType Directory -Path $netlab -ErrorAction Stop
$networkReport = Join-Path $netlab 'network-report.txt'
Get-Date -Format o | Out-File -LiteralPath $networkReport -Encoding UTF8
"=== Local adapter configuration ===" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8
ipconfig /all | Out-File -LiteralPath $networkReport -Append -Encoding UTF8 -Width 4096
"ipconfig exit code: $LASTEXITCODE" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8

"=== ICMP to 8.8.8.8 (not a DNS test) ===" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8
try {
  $icmpResult = Test-Connection 8.8.8.8 -Count 2 -Quiet -ErrorAction Stop
  "At least one echo reply: $icmpResult" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8
} catch {
  "ICMP query failed: $($_.FullyQualifiedErrorId)" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8
}

"=== DNS A query for google.com ===" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8
try {
  Resolve-DnsName google.com -Type A -DnsOnly -ErrorAction Stop |
    Format-List Name, Type, IPAddress |
    Out-File -LiteralPath $networkReport -Append -Encoding UTF8 -Width 4096
  "DNS query completed" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8
} catch {
  "DNS query failed: $($_.FullyQualifiedErrorId)" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8
}

"=== TCP to google.com port 443 (not an HTTPS test) ===" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8
try {
  Test-NetConnection -ComputerName google.com -Port 443 -InformationLevel Detailed -ErrorAction Stop |
    Format-List ComputerName, RemoteAddress, RemotePort, TcpTestSucceeded |
    Out-File -LiteralPath $networkReport -Append -Encoding UTF8 -Width 4096
} catch {
  "TCP query failed: $($_.FullyQualifiedErrorId)" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8
}

"=== Reserved invalid-name query ===" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8
try {
  Resolve-DnsName no-such-host.invalid. -Type A -DnsOnly -ErrorAction Stop | Out-Null
  "Unexpected answer for .invalid: inspect the resolver" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8
} catch {
  "Name query failed: $($_.FullyQualifiedErrorId)" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8
}

"=== Observed ESTABLISHED TCP rows (includes local traffic) ===" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8
$tcpRows = @(netstat -an)
"netstat exit code: $LASTEXITCODE" | Out-File -LiteralPath $networkReport -Append -Encoding UTF8
($tcpRows | Select-String ESTABLISHED | Measure-Object).Count |
  Out-File -LiteralPath $networkReport -Append -Encoding UTF8
$networkReport

Get-Content -LiteralPath $networkReport -Encoding UTF8

6. 흔한 실수와 해결

가상 어댑터가 많음: VPN과 가상화 도구는 추가 인터페이스·경로·DNS를 만들 수 있습니다. 이 실습 때문에 Tailscale을 끄거나 설정을 초기화하지 마세요. 사용하는 목적지와 경로에 따라 결과를 읽습니다.

핑 실패인데 브라우저는 됨: ICMP 제한이나 프록시 등 경로 차이를 고려합니다. Test-NetConnection도 브라우저의 프록시·TLS·로그인 과정을 대신 검사하지 않습니다.

169.254.x.x가 보임: 링크 로컬 주소이며 보통 같은 링크 안의 통신에 쓰입니다. 다른 어댑터나 IPv6를 통해 인터넷이 되는지도 구별하세요.

보고서가 비거나 항목이 빠짐: 파일을 다시 읽고 조회 오류·False·종료 코드를 확인하세요. 오류 스트림은 기본 파이프에 자동 포함되지 않습니다. 새 PowerShell 창을 열었다면 미션 블록부터 다시 실행합니다.

연결 수가 예상과 다름: 실시간으로 변하는 관찰값입니다. 개수·국가·포트 하나로 안전하거나 악성이라고 판단하지 마세요.

7. 정리

설정 확인 → ICMP·DNS·TCP 개별 검사 → 연결 목록 관찰 → 성공과 실패를 함께 기록 순서로 진행했습니다. 다음 단계로 넘길 핵심은 ‘어떤 검사에서 무엇이 확인됐는가’를 분명히 말하는 습관입니다. Step 7에서는 오늘 사용한 변수와 자료형을 배웁니다.

실습 검증 기록

2026-09-10, Windows PowerShell 5.1.26100.9444와 PowerShell 7.6.5에서 실행 코드 전체를 순서대로 수행했습니다. 로컬 설정 조회, 루프백과 외부 ICMP, DNS A 조회, TCP 443 연결, .invalid 이름 실패, 보고서 저장을 확인했습니다. 별도 로컬 TCP 연결로 netstat에 루프백도 포함됨을 재현했습니다. 원본 네트워크 상세 정보는 공개하지 않았으며, 방화벽·DNS·VPN 설정을 바꾸지 않았습니다. 다른 시간·환경의 네트워크 상태와 TLS·웹 앱의 정상 여부까지 검증한 기록은 아닙니다.

Microsoft: Test-Connection · Resolve-DnsName · Test-NetConnection · netstat · RFC 6761: special-use names · RFC 1918: private addresses · RFC 3927: IPv4 link-local · Tailscale addresses