AZ-104 네트워킹 문제에서 가장 까다로운 유형은 "VM1에서 VM2로 연결이 안 된다. 원인은 무엇이고, 무엇으로 확인해야 하는가"입니다. 공식 출제 범위에도 "네트워크 연결 문제 해결"과 "NSG의 유효 보안 규칙 평가"가 따로 적혀 있고, 모니터링 도메인에는 "Azure Network Watcher와 연결 모니터 사용"이 들어 있습니다. 이런 문제는 NSG, 경로, 피어링, DNS 중 한 군데만 잘못되어도 증상이 똑같이 "연결 안 됨"으로 나타나기 때문에, 확인 순서를 정해 두지 않으면 보기 사이에서 헤매게 됩니다.
이 글은 연결 문제를 바깥에서 안으로 좁혀 가는 다섯 단계 점검 순서와, 단계마다 쓰는 Network Watcher 도구를 정리합니다. NSG가 서브넷과 NIC에서 두 번 평가되는 순서, 경로 선택 규칙과 다음 홉, 피어링의 비전이성과 게이트웨이 전송, 프라이빗 DNS의 연결과 자동 등록까지 다룹니다. NSG·UDR·피어링의 기본 개념은 초보자도 이해하는 VNet, NSG, DNS, Load Balancer에서 먼저 정리했습니다.
---
연결 문제는 다섯 단계로 좁혀 간다
택배가 도착하지 않았다면 주소가 맞는지, 배송 경로가 맞는지, 건물 출입 통제에 막혔는지, 지역 간 배송망이 연결되어 있는지, 받는 사람이 집에 있는지를 차례로 확인합니다. VM 간 연결 문제도 같은 순서로 확인하면 원인을 빠르게 찾을 수 있습니다.
!VM 연결 문제를 바깥에서 안으로 좁혀 가는 다섯 단계
| 단계 | 질문 | 확인 도구 | |------|------|------| | 1. 이름 해석 | 이름이 올바른 IP로 바뀌는가? | nslookup, 프라이빗 DNS 영역의 가상 네트워크 연결 | | 2. 경로 | 패킷이 올바른 다음 홉으로 가는가? | 다음 홉, NIC의 유효 경로 | | 3. 보안 규칙 | NSG가 허용하는가? | IP 흐름 확인, NSG 진단, 유효 보안 규칙 | | 4. 연결 구조 | VNet끼리, 온프레미스와 연결되어 있는가? | 피어링 상태, VPN 문제 해결, 연결 문제 해결 | | 5. VM 내부 | 앱이 포트를 수신하고 OS 방화벽이 허용하는가? | 연결 문제 해결, 패킷 캡처, VM 안의 진단 |
시험 팁: 문제에 "어떤 규칙이 트래픽을 막는지 확인"이라고 나오면 IP 흐름 확인, "트래픽이 어디로 라우팅되는지 확인"이면 다음 홉, "VM과 대상 사이 연결을 한 번 테스트하고 지연과 홉을 확인"이면 연결 문제 해결, "시간에 따라 계속 감시"면 연결 모니터입니다.
---
Network Watcher 도구 한눈에 보기
Network Watcher는 VM, VNet, 부하 분산 장치, Application Gateway 같은 IaaS 네트워크 리소스를 진단하는 도구 모음입니다. PaaS 모니터링용은 아니라는 점도 함께 기억하세요.
| 도구 | 하는 일 | 결과에서 얻는 것 | |------|------|------| | IP 흐름 확인 (IP flow verify) | VM 기준으로 특정 5-튜플 패킷이 허용되는지 확인 | 허용/거부 + 결정한 보안 규칙 이름 | | NSG 진단 | VM·확장 집합·Application Gateway 기준으로 IP·접두사·서비스 태그 트래픽 확인 | 허용/거부 + 규칙, 우선순위가 높은 규칙 추가 가능 | | 다음 홉 (Next hop) | 특정 대상 IP로 가는 경로 확인 | 다음 홉 종류, IP 주소, 경로 테이블 ID | | 유효 보안 규칙 | NIC에 실제로 적용되는 규칙 표시 | NIC의 NSG, 서브넷의 NSG, 둘을 합친 결과 | | 연결 문제 해결 | VM 등에서 VM·FQDN·URI·IP로 연결을 한 번 테스트 | 연결 여부, 지연, 홉, 발견된 문제 | | 연결 모니터 | Azure와 하이브리드 엔드포인트 간 연결을 지속 감시 | 시간에 따른 지연·손실, 경고 | | 패킷 캡처 | VM·확장 집합의 트래픽을 원격으로 캡처 | 패킷 단위 분석 | | VPN 문제 해결 | 가상 네트워크 게이트웨이와 연결 진단 | 게이트웨이·연결 상태와 로그 | | 흐름 로그 | IP 트래픽 정보를 스토리지에 기록, 트래픽 분석으로 시각화 | 허용·거부된 흐름 기록 | | 토폴로지 | 여러 구독·지역의 네트워크 리소스 관계를 시각화 | 구성 이해 |
흐름 로그는 이제 가상 네트워크 흐름 로그를 써야 합니다. NSG 흐름 로그는 새로 만들 수 없고, 2027년 9월 30일에 사용 중지됩니다.
---
NSG 규칙은 두 번, 정해진 순서로 평가된다
건물 정문 경비(서브넷 NSG)와 사무실 문 잠금장치(NIC NSG)가 둘 다 있으면, 둘 다 통과해야 들어갈 수 있습니다. Azure는 방향에 따라 순서를 다르게 평가합니다.
| 방향 | 평가 순서 | 결과 | |------|------|------| | 인바운드 | 서브넷 NSG → NIC NSG | 서브넷에서 거부되면 NIC NSG는 평가하지 않음 | | 아웃바운드 | NIC NSG → 서브넷 NSG | NIC에서 거부되면 서브넷 NSG는 평가하지 않음 | | 같은 서브넷 안의 VM 간 | 위와 같은 순서 적용 | 같은 서브넷이라도 서브넷 NSG가 적용됨 |
각 NSG 안에서는 우선순위 숫자(100~4096)가 작은 규칙부터 평가하고, 일치하는 규칙을 만나면 거기서 멈춥니다. NSG는 상태 저장 방식이라 허용된 연결의 응답 트래픽은 따로 규칙이 없어도 돌아옵니다. 직접 만든 규칙이 없을 때 적용되는 기본 규칙은 다음과 같습니다.
| 방향 | 기본 규칙 (우선순위) | 의미 | |------|------|------| | 인바운드 | AllowVNetInBound (65000) | VNet 안과 피어링된 VNet에서 오는 트래픽 허용 | | 인바운드 | AllowAzureLoadBalancerInBound (65001) | 부하 분산 장치 상태 프로브 허용 | | 인바운드 | DenyAllInBound (65500) | 나머지 모두 거부 | | 아웃바운드 | AllowVnetOutBound (65000) | VNet 안으로 나가는 트래픽 허용 | | 아웃바운드 | AllowInternetOutBound (65001) | 인터넷으로 나가는 트래픽 허용 | | 아웃바운드 | DenyAllOutBound (65500) | 나머지 모두 거부 |
표 문제로 확인하기
서브넷 NSG에는 "우선순위 200, TCP 3389 허용" 규칙이, VM1의 NIC NSG에는 "우선순위 100, 인터넷에서 오는 모든 트래픽 거부" 규칙이 있습니다. 인터넷에서 VM1로 RDP를 시도하면 서브넷 NSG는 통과하지만 NIC NSG에서 거부됩니다. 유효 보안 규칙을 보면 두 NSG의 규칙이 함께 표시되고, IP 흐름 확인을 실행하면 NIC NSG의 거부 규칙 이름이 결과로 나옵니다.
시험 팁: 해결책을 고를 때는 "어느 NSG에, 어떤 우선순위로" 규칙을 추가하는지까지 확인하세요. NIC NSG의 우선순위 100 거부 규칙을 이기려면 같은 NIC NSG에 100보다 작은 숫자의 허용 규칙을 넣어야 합니다. 서브넷 NSG에 아무리 작은 숫자의 규칙을 넣어도 NIC NSG의 거부는 바뀌지 않습니다.
---
경로: 패킷은 어디로 가는가
NSG가 허용해도 패킷이 엉뚱한 곳으로 가면 연결되지 않습니다. Azure는 서브넷마다 시스템 경로를 자동으로 만들고, 사용자 정의 경로(UDR)와 BGP 경로로 이를 덮어쓸 수 있습니다.
경로 선택 규칙은 두 가지입니다. 먼저 대상 IP와 가장 길게 일치하는 접두사(longest prefix match)를 고릅니다. 10.0.0.0/16과 10.0.0.0/24가 모두 있으면 10.0.0.5로 가는 트래픽은 /24 경로를 따릅니다. 접두사가 똑같다면 사용자 정의 경로 → BGP 경로 → 시스템 경로 순서로 우선합니다.
| 다음 홉 종류 | 의미 | 기억할 점 | |------|------|------| | 가상 네트워크 | VNet 주소 공간 안에서 직접 전달 | 시스템 경로 | | 인터넷 | 인터넷으로 전달 | 0.0.0.0/0 시스템 경로의 기본값 | | 가상 어플라이언스 | 방화벽 같은 NVA의 사설 IP로 전달 | 그 NVA의 NIC에서 IP 전달(IP forwarding)을 켜야 함 | | 가상 네트워크 게이트웨이 | VPN·ExpressRoute 게이트웨이로 전달 | 온프레미스로 가는 트래픽 | | 없음 | 트래픽을 버림 | 특정 대역을 의도적으로 차단할 때 |
시험 팁: "UDR로 0.0.0.0/0을 NVA로 보냈더니 모든 인터넷 트래픽이 끊겼다"면 NVA NIC의 IP 전달 설정이나 NVA 안의 라우팅을 의심하세요. 다음 홉 도구로 확인하면 다음 홉 종류가 "가상 어플라이언스"이고 적용된 경로 테이블 ID까지 보입니다.
---
피어링과 게이트웨이: 연결 구조 문제
NSG와 경로가 모두 정상이어도 VNet끼리 연결 구조가 없으면 통신할 수 없습니다. 가장 많이 나오는 함정은 피어링이 전이되지 않는다는 점입니다. VNet A와 B, B와 C를 피어링해도 A와 C는 직접 통신할 수 없습니다.
| 해결 방법 | 방식 | |------|------| | A와 C를 직접 피어링 | 가장 단순, VNet 수가 늘면 피어링 수가 급증 | | 허브의 NVA·Azure Firewall 경유 | 스포크 서브넷에 UDR로 허브의 방화벽을 다음 홉으로 지정, 피어링에서 전달된 트래픽 허용 | | 허브의 게이트웨이 공유 | 게이트웨이 전송으로 스포크가 허브의 VPN·ExpressRoute 게이트웨이를 사용 |
게이트웨이 전송은 허브 쪽 피어링에서 "게이트웨이 전송 허용"을, 스포크 쪽 피어링에서 "원격 게이트웨이 사용"을 켜는 설정입니다. 최신 포털에서는 각각 "게이트웨이 또는 Route Server가 트래픽을 전달하도록 허용", "원격 게이트웨이 또는 Route Server 사용"이라는 문구로 표시됩니다. 원격 게이트웨이를 쓰는 VNet은 자기 게이트웨이를 가질 수 없습니다.
피어링할 두 VNet의 주소 공간은 겹치면 안 됨 피어링 상태가 "시작됨(Initiated)"이면 반대쪽 피어링이 아직 없음 한쪽 피어링을 지우면 반대쪽은 "연결 끊김(Disconnected)"이 되고, 지우고 다시 만들어야 함 VPN 게이트웨이는 이름이 정확히 GatewaySubnet인 서브넷에 배포하며, 이 서브넷에는 다른 리소스를 두지 않음
시험 팁: "스포크 VNet의 VM이 허브의 VPN 게이트웨이를 통해 온프레미스에 접근해야 한다"는 허브 피어링에 게이트웨이 전송 허용, 스포크 피어링에 원격 게이트웨이 사용입니다. 스포크에 게이트웨이를 새로 만드는 보기는 오답입니다.
---
DNS: 이름이 풀리지 않을 때
IP로는 연결되는데 이름으로는 안 된다면 DNS 문제입니다. Azure 프라이빗 DNS 영역은 VNet 안에서만 쓰는 내부 전화번호부인데, 영역을 만들기만 해서는 아무 VNet도 그 전화번호부를 볼 수 없습니다.
| 설정 | 동작 | 기억할 점 | |------|------|------| | 가상 네트워크 연결 | 연결된 VNet이 영역의 레코드를 조회 | 여러 VNet을 한 영역에 연결 가능 | | 자동 등록 | 연결된 VNet의 VM A 레코드를 자동 생성·삭제 | 한 VNet은 자동 등록을 켠 영역 하나에만 연결 가능, VM만 대상 | | 사용자 지정 DNS 서버 | VNet이나 NIC에 지정한 DNS 서버 사용 | NIC 설정이 VNet 설정보다 우선, 바꾼 뒤 VM에서 DHCP 임대 갱신 필요 |
시험 팁: "VNet2의 VM이 contoso.internal 이름을 풀지 못한다"면 프라이빗 DNS 영역에 VNet2의 가상 네트워크 연결이 있는지 확인하세요. "VM을 만들면 레코드가 자동으로 생기게"는 자동 등록, "부하 분산 장치의 레코드"는 자동 등록 대상이 아니므로 직접 만들어야 합니다.
---
시험 핵심 정리
시험장 가기 전 마지막으로 확인할 핵심 포인트입니다.
| 구분 | 핵심 암기 사항 | |------|------| | 점검 순서 | DNS → 경로 → NSG → 연결 구조 → VM 내부 | | IP 흐름 확인 | 허용/거부와 결정한 규칙 이름 | | 다음 홉 | 다음 홉 종류, IP, 경로 테이블 ID | | 유효 보안 규칙 | NIC NSG + 서브넷 NSG를 합친 실제 규칙 | | 연결 문제 해결 vs 연결 모니터 | 한 번 테스트 vs 지속 감시 | | 흐름 로그 | 가상 네트워크 흐름 로그 사용, NSG 흐름 로그는 2027년 9월 30일 종료 | | NSG 평가 순서 | 인바운드 서브넷 → NIC, 아웃바운드 NIC → 서브넷, 둘 다 허용해야 통과 | | NSG 우선순위 | 작은 숫자부터, 일치하면 중단, 기본 규칙은 65000~65500 | | 경로 선택 | 가장 긴 접두사 일치, 같으면 UDR → BGP → 시스템 | | 가상 어플라이언스 | NVA NIC에서 IP 전달 사용 필요 | | 피어링 | 전이되지 않음, 주소 공간 겹침 불가, 게이트웨이 전송 + 원격 게이트웨이 사용 | | 프라이빗 DNS | 가상 네트워크 연결 필요, 자동 등록은 VNet당 영역 하나·VM만 |
---
다음 단계
연결 문제를 단계별로 좁히는 법을 익혔다면, 트래픽을 받는 쪽인 부하 분산 장치의 문제 해결은 AZ-104 공용 IP와 부하 분산 서비스 고르기에서 이어서 확인하세요. 메트릭·로그·경고 같은 모니터링 기본기는 내 클라우드가 지금 어떤 상태인지 한눈에 파악하기에 정리되어 있습니다.
네트워크 문제는 "어느 단계에서 막혔나"를 먼저 정하면 도구 선택이 따라옵니다. AZ-104 모의고사에서 연결 문제를 풀며 다섯 단계 순서로 보기를 걸러 보세요.