Azure VM 인터넷 안됨 - UDR·NSG·NVA 점검 체크리스트

Azure VM에서 인터넷이 안 되는 상황은 대개 “VM 문제”가 아니라 “네트워크 경로(라우팅/보안/어플라이언스)” 문제입니다. 특히 기업 환경에서 스포크 VNet에 VM을 두고, 허브 VNet에 NVA(Azure Firewall, Palo Alto, FortiGate 등)를 두는 구조라면 UDR + NSG + NVA + DNS 중 하나만 어긋나도 바로 증상이 발생합니다.

이 글은 “VM에서 curl/apt/yum/Windows Update가 실패한다”, “외부로 ping이 안 된다”, “특정 도메인만 안 된다” 같은 케이스에서, 원인을 빠르게 좁히는 순서와 확인 포인트를 정리한 실전 가이드입니다.

문제 재현/증상 분석 관점은 OpenAI Responses API 408 타임아웃 재현과 해결 실전 가이드처럼 “재현 가능한 체크리스트”가 가장 빠릅니다. 네트워크도 동일합니다.

1) 먼저 확인할 것: VM이 ‘어디로’ 나가려 하는가

인터넷 장애 트러블슈팅의 핵심은 “이 VM의 기본 경로(0.0.0.0/0)가 어디로 향하는지”입니다. Azure에서는 다음 요소가 결합되어 실제 경로가 결정됩니다.

• 시스템 라우트(System routes): Azure가 기본 제공
• 사용자 정의 라우트(UDR): Route Table로 강제
• BGP 라우트: VPN/ExpressRoute, NVA에서 전파
• NIC 유효 NSG 규칙: 아웃바운드 차단 여부
• NVA/방화벽 정책: SNAT, 허용 규칙, 라우팅

가장 먼저 “유효 경로(Effective routes)”와 “유효 NSG(Effective security rules)”를 확인해, VM이 실제로 어떤 경로/정책을 적용받는지부터 확정해야 합니다.

2) 빠른 진단: Network Watcher로 ‘연결 확인’부터

Azure Network Watcher의 Connection troubleshoot는 “VM에서 특정 목적지로 나갈 수 있는지”를 한 번에 확인하는 데 유용합니다.

포털에서

• Network Watcher Connection troubleshoot
• Source: 문제 VM
• Destination: 8.8.8.8:53 또는 1.1.1.1:53, 혹은 특정 FQDN:443

결과에서 다음을 봅니다.

• Next hop이 NVA인지, Internet인지
• NSG에서 Drop인지
• NVA에서 drop인지(완전하게는 안 보일 수 있음)

Azure CLI 예시

# Network Watcher가 활성화되어 있어야 합니다.
# 목적지 IP/포트로 TCP 연결이 가능한지 확인
az network watcher test-connectivity \
  --source-resource /subscriptions/$SUB/resourceGroups/$RG/providers/Microsoft.Compute/virtualMachines/$VM \
  --dest-address 1.1.1.1 \
  --dest-port 443

이 단계에서 “NSG에서 막힘”이 바로 나오면 아래 NSG 파트로, “Next hop이 NVA”로 나오면 UDR/NVA 파트로 내려가면 됩니다.

3) UDR 점검: 0.0.0.0/0이 어디로 향하는지

인터넷이 안 되는 가장 흔한 원인 1순위는 스포크 서브넷에 붙은 UDR이 0.0.0.0/0을 NVA로 보내는데, NVA에서 SNAT/허용 정책/라우팅이 맞지 않는 경우입니다.

확인 포인트

• 문제 VM이 속한 서브넷에 Route Table이 연결되어 있는가
• Route Table에 0.0.0.0/0(기본 경로)가 있는가
• Next hop type이 Virtual appliance이고, Next hop IP가 NVA의 내부 IP로 되어 있는가
• NVA가 다운/스케일 인/라우팅 미적용 상태가 아닌가

Effective routes로 실제 적용 확인

포털:

• VM Networking Effective routes

CLI:

# NIC 기준으로 유효 라우트를 확인
NIC_ID=$(az vm show -g $RG -n $VM --query 'networkProfile.networkInterfaces[0].id' -o tsv)

az network nic show-effective-route-table \
  --ids $NIC_ID \
  -o table

여기서 0.0.0.0/0가 VirtualAppliance로 잡히면, VM의 모든 인터넷 트래픽은 NVA로 갑니다. 즉, NVA가 인터넷을 “대신” 내보내주는 구조가 되어야 합니다.

자주 발생하는 UDR 실수

• 0.0.0.0/0만 NVA로 보내고, NVA에서 인터넷으로 나갈 기본 경로가 없음
• NVA가 있는 서브넷에도 같은 UDR을 걸어 “자기 자신에게 라우팅”하는 루프
• 특정 대역(예: 사내 프록시, DNS, 패키지 리포지토리) 라우트가 누락되어 경로가 꼬임
• 허브/스포크 피어링에서 Use remote gateways/Allow gateway transit 설정 불일치

4) NSG 점검: 아웃바운드가 정말 열려 있는가

Azure NSG는 “인바운드만 막는 것”처럼 느껴지지만, 아웃바운드도 얼마든지 차단할 수 있습니다. 특히 보안 강화 템플릿을 적용했거나, 정책(Policy)로 NSG가 강제된 경우 아웃바운드가 막혀 인터넷이 안 됩니다.

확인 포인트

• NIC/서브넷 NSG 둘 다 확인(둘 중 하나라도 막으면 실패)
• Outbound에서 Internet으로 가는 트래픽이 허용되어 있는지
• DenyAllOutbound 같은 규칙이 높은 우선순위로 있는지
• 목적지가 Internet이 아니라 “NVA IP”로 보일 수도 있음(UDR로 인해)

Effective security rules로 실제 적용 확인

az network nic list-effective-nsg \
  --ids $NIC_ID \
  -o jsonc

결과에서 direction: Outbound 규칙을 보고, 목적지/포트(예: 443)가 허용되는지 확인합니다.

NSG Flow Logs로 드롭 확인(가능하면)

Network Watcher NSG Flow Logs를 켜두면, “어떤 5-tuple이 drop 되었는지”를 추적할 수 있습니다. 운영 환경에서는 보안/비용 고려가 필요하지만, 장애 시점 분석에는 매우 강력합니다.

5) NVA 점검: SNAT, 정책, 라우팅, 비대칭 경로

UDR로 NVA를 타게 만들었다면, 이제부터는 “NVA가 인터넷을 제대로 내보내는지”가 관건입니다. NVA는 크게 두 부류입니다.

• Azure Firewall(관리형)
• 서드파티 방화벽 VM(자체 OS/정책)

공통 체크리스트

• NVA가 인터넷으로 나갈 수 있는 공인 경로가 있는가
  • 공인 IP를 통한 SNAT
  • 또는 NAT Gateway/Load Balancer SNAT 등 설계에 맞는 구성
• 허용 정책에 VM 서브넷에서 인터넷(특히 443)이 허용되어 있는가
• 리턴 트래픽이 동일 경로로 돌아오는가(비대칭 라우팅이면 세션이 깨짐)
• NVA가 다운/헬스체크 실패/라우팅 프로세스 장애가 아닌가

Azure Firewall 사용 시 자주 막히는 지점

• Network rule/Application rule 미설정
• DNS Proxy 사용 시 DNS 설정 불일치
• Threat Intelligence/IDPS 정책으로 특정 도메인 차단
• SNAT 포트 고갈(대량 egress)

서드파티 NVA 사용 시 자주 막히는 지점

• IP forwarding 미활성화
• UDR이 NVA의 NIC가 아닌 다른 IP로 향함
• NVA 내부 라우팅 테이블/정책에 스포크 대역이 누락
• 세션 테이블/conntrack 고갈

6) DNS 문제: “인터넷 안됨”처럼 보이는 대표 원인

VM에서 ping 8.8.8.8은 되는데 curl https://example.com이 안 되면, DNS가 거의 확정입니다.

확인 포인트

• VM의 DNS 서버가 무엇인지
• 커스텀 DNS(AD DNS, BIND, Infoblox 등)가 인터넷 재귀를 허용하는지
• NVA에서 DNS를 프록시/필터링하는지

Linux에서 빠르게 확인:

cat /etc/resolv.conf

# DNS 질의 확인
nslookup example.com
# 또는
dig example.com

Windows:

ipconfig /all
Resolve-DnsName example.com

DNS가 사내로 강제되어 있고, 사내 DNS가 외부 재귀를 막거나 특정 도메인을 차단하면 “인터넷이 안 된다”로 인지됩니다.

7) VM 자체 점검: OS 방화벽/프록시/라우팅

네트워크 구성이 정상인데도 안 된다면, 마지막으로 VM 내부를 봅니다.

Linux

# 기본 라우트 확인
ip route

# 프록시 환경 변수 확인
env | grep -i proxy

# 방화벽 확인(배포판마다 다름)
sudo ufw status || true
sudo iptables -S || true
sudo nft list ruleset || true

# 실제 HTTPS egress 테스트
curl -v https://ifconfig.me

Windows

route print
netsh winhttp show proxy
Test-NetConnection 1.1.1.1 -Port 443

특히 기업망에서는 OS 프록시가 남아 있거나, 에이전트(EDR) 정책이 아웃바운드를 막는 경우도 있습니다.

8) “정답 루트”를 빠르게 찾는 추천 순서

현장에서 시간을 가장 아끼는 순서는 다음과 같습니다.

1. VM Effective routes에서 0.0.0.0/0 Next hop 확인
2. VM Effective NSG에서 Outbound 443 허용 여부 확인
3. Network Watcher test-connectivity로 목적지별 성공/실패 분리
4. NVA 로그/정책에서 drop/SNAT 여부 확인
5. DNS 분리 테스트(직접 IP 호출 vs 도메인 호출)

이 순서를 따르면 “UDR 문제인지, NSG 문제인지, NVA 문제인지, DNS 문제인지”를 대부분 10분 내로 분류할 수 있습니다.

9) 실전 시나리오 예시: UDR로 NVA를 탔는데 인터넷이 안 됨

증상:

• VM에서 curl https://example.com 타임아웃
• Effective routes에서 0.0.0.0/0가 VirtualAppliance로 NVA를 가리킴
• NSG Outbound는 Allow로 보임

이 경우 가능한 원인:

• NVA에 인터넷 허용 정책이 없음(특히 Application rule 미설정)
• NVA가 SNAT을 하지 않아 인터넷 리턴 트래픽이 돌아오지 않음
• NVA의 업링크 서브넷 UDR/기본 경로가 잘못되어 외부로 못 나감
• 허브 VNet에서 공인 egress 경로가 끊김(NAT Gateway 제거, 공인 IP 분리 등)

조치:

• NVA에서 스포크 서브넷 source에 대해 443 허용
• SNAT 동작 확인(출발지 IP가 공인 IP로 변환되는지)
• NVA 업링크의 라우팅/보안그룹 확인

10) 운영 팁: 장애를 줄이는 구성/관측 포인트

• 변경 시 “유효 경로/유효 NSG” 스냅샷을 남기기
• NVA 정책 변경은 IaC로 관리하고, 롤백 경로를 확보하기
• NSG Flow Logs, Firewall logs를 중앙(Log Analytics/SIEM)으로 모으기
• egress가 중요한 워크로드는 SNAT 포트/동시 연결 수를 용량 산정하기

Azure VM이 부팅 단계에서 장애가 나면 네트워크 이전에 VM 자체 복구가 우선입니다. 그 경우에는 Azure VM 부팅불가? Boot Diagnostics로 복구도 함께 참고하면 진단 동선이 깔끔해집니다.

마무리

Azure VM 인터넷 장애는 “UDR로 어디로 보내는지”와 “NSG/NVA가 그 트래픽을 허용하는지” 두 축으로 나누면 빠르게 정리됩니다. 특히 허브-스포크 + NVA 구조에서는 기본 경로 0.0.0.0/0의 Next hop이 NVA로 잡히는 순간, 문제의 대부분은 NVA 정책/SNAT/라우팅으로 수렴합니다.

다음 장애 때는 감으로 만지기보다, Effective routes Effective NSG test-connectivity 3종 세트로 먼저 사실을 확정하고, 그 다음에 UDR·NSG·NVA를 순서대로 좁혀가면 복구 시간이 크게 줄어듭니다.