📋 시나리오 1 — 정책 생성 및 접근 검증 가이드
이전 실습에서 Service를 생성했고, 이번에는 누가 접근할 수 있는지 권한을 정의하고 실제로 접속을 검증합니다.
1. 왜 Policy가 필요한가?
“서비스를 정의했지만, 어떤 Identity도 접근하거나 호스팅하도록 허용하지 않았습니다. 이 Identity들을 허용하려면 정책을 생성해야 합니다.”
OpenZiti는 Zero Trust 원칙을 따르므로 명시적으로 허용하지 않으면 모든 접근이 차단됩니다.
| 상태 | 결과 |
|---|---|
| Service만 생성, Policy 없음 | ❌ 아무도 접근 불가 |
| Service + Policy 생성 완료 | ✅ 허용된 Identity만 접근 가능 |
2. DIAL vs BIND 개념
“기본적으로 다이얼은 출발지 측에 있고 바인드는 목적지 측에 있습니다.”
| 구분 | DIAL | BIND |
|---|---|---|
| 위치 | 소스 측 (클라이언트) | 대상 측 (서버/호스팅) |
| 의미 | 서비스에 연결할 수 있다 | 서비스를 호스팅할 수 있다 |
| 실습 | OP-PRIVATE-ER, Remote PC | AZ-PRIVATE-ER |
💡 전화 비유
DIAL = 전화를 거는 사람 (발신자)
BIND = 전화를 받는 사람 (수신자)
→ 둘 다 있어야 통화(연결)가 성립3. STEP 1 — DIAL 정책 생성
설정값:
| 항목 | 값 |
|---|---|
| 정책 이름 | AZ-WEB-ACCESS-DIAL |
| 유형 | DIAL |
| 서비스 | AZ-WEB-SERVICE |
| Identity | OP-PRIVATE-ER, Remote PC |
ZAC 설정 순서
항목 값
정책 이름 AZ-WEB-ACCESS-DIAL
유형 DIAL
서비스 AZ-WEB-SERVICE
Identity OP-PRIVATE-ER, Remote PC4. STEP 2 — BIND 정책 생성
“바인드용으로, Azure Private Edge Router 를 지정하고 있죠.”
설정값:
| 항목 | 값 |
|---|---|
| 정책 이름 | AZ-WEB-ACCESS-BIND |
| 유형 | BIND |
| 서비스 | AZ-WEB-SERVICE |
| Identity | AZ-PRIVATE-ER |
ZAC 설정 순서
ZAC → Policies → + 클릭
→ Name: AZ-WEB-ACCESS-BIND
→ Type: Bind
→ Service: AZ-WEB-SERVICE
→ Identities: AZ-PRIVATE-ER 선택
→ Save 클릭💡 Posture Check(포스처 체크)란?
접속 기기의 OS 버전, 백신 설치 여부 등 보안 상태를 검사하는 추가 조건입니다. 이번 실습에서는 설정하지 않습니다.
5. STEP 3 — 서비스가 Identity에 복제되었는지 확인
“이 서비스가 우리의 아이덴티티에 복제되었는지 확인해 봅시다. 이 Identity에 하나의 서비스가 연결되어 있는 것을 볼 수 있고.”
ZAC → Identities → "Remote PC" 클릭
→ Services 탭 확인
→ AZ-WEB-SERVICE가 목록에 표시되는지 확인 ✅또는 Remote PC의 ZT Client에서 Services 항목에 ztnginx.ivo, 10.20.0.4 표시 확인.
💡 Policy 생성 후 Controller가 해당 Identity에 서비스 정보를 자동으로 전달(복제)합니다. Ziti Client는 이 정보를 받아 Intercept 주소로 오는 트래픽을 자동으로 가로챕니다.
6. STEP 4 — AZ-WEB-APP에 Nginx 설치
# AZ-WEB-APP VM에 SSH 접속 후 실행
sudo apt-get install nginx -y
# 서비스 상태 확인
sudo systemctl status nginx
# → Active: active (running) 확인 ✅7. STEP 5 — Remote PC에서 접근 검증
Remote PC에서:
1. ZT Client가 실행 중이고 🟢 Online 상태인지 확인
2. 브라우저 시크릿 창 열기
3. 주소창 입력: http://kpcweb.local
4. Nginx 기본 페이지 표시 확인 ✅💡 kpcweb.local가 작동하는 원리
이 URL은 실제 DNS 서버에 없습니다. Ziti Client가 Intercept 설정을 보고 로컬에서 해석하여 OpenZiti 오버레이로 트래픽을 가로챕니다.
8. STEP 6 — 온프레미스 PC 라우트 추가 및 검증
온프레미스 PC(Ubuntu Desktop)는 Ziti Client 없이 네트워크 레벨 라우팅 방식으로 접근합니다. Azure 네트워크(10.20.0.0/24)로 가는 트래픽이 OP-PRIVATE-ER을 통하도록 정적 라우트를 추가해야 합니다.
[라우트 없을 때]
OP-PC1 → 10.20.0.4 → 기본 게이트웨이(인터넷) → 도달 불가 ❌
[라우트 추가 후]
OP-PC1 → 10.20.0.4 → OP-PRIVATE-ER → OpenZiti 오버레이 → AZ-WEB-APP ✅라우트 설정값:
| 항목 | 값 |
|---|---|
| 목적지 | 10.20.0.0 |
| 서브넷 마스크 | 255.255.0.0 |
| 게이트웨이 (다음 홉) | 10.10.1.140 (OP-PRIVATE-ER) |
Linux 명령어:
sudo ip route add 10.20.0.0/16 via 10.10.1.140GUI (Ubuntu NetworkManager):
네트워크 설정 → 연결 편집 → IPv4 → Routes
→ 주소: 10.20.0.0 / 넷마스크: 255.255.0.0 / 게이트웨이: 10.10.1.140
→ Apply 클릭검증
curl -k http://10.20.0.4
# → Nginx HTML 출력 ✅9. 시나리오 1 전체 체크리스트
✅ 1. Private 라우터 Traversal OFF (AZ-PRIVATE-ER, OP-PRIVATE-ER)
✅ 2. Azure 방화벽 포트 10080 인바운드 허용 (AZ-PUBLIC-ER)
✅ 3. Remote PC Identity 생성 → JWT → ZT Client 등록
✅ 4. 서비스 생성 (Intercept: ztnginx.ivo + Host: 10.20.0.4)
✅ 5. DIAL 정책 생성 (OP-PRIVATE-ER, Remote PC → AZ-WEB-SERVICE)
✅ 6. BIND 정책 생성 (AZ-PRIVATE-ER → AZ-WEB-SERVICE)
✅ 7. Nginx 설치 (AZ-WEB-APP)
✅ 8. Remote PC 검증: http://ztnginx.ivo → Nginx 페이지
✅ 9. OP-PC1 라우트 추가 후 curl 10.20.0.4 → Nginx HTML