Oracle Cloud Infrastructure의 기본 네트워크 문제 해결

소개

OCI(Oracle Cloud Infrastructure)에서 네트워크 연결 문제를 진단하려면 여러 구성요소 간의 트래픽 구성 및 플로우에 대한 가시성이 필요합니다. Network Visualizer, Network Path Analyzer, VCN Flow Log와 같은 OCI Network Command Center 도구는 네트워크 리소스의 레이아웃, 라우팅 및 흐름 동작에 대한 심층적인 통찰력을 제공합니다. 이러한 도구를 사용하면 OCI 네트워크 환경에서 가상 클라우드 네트워크(VCN), 서브넷 및 게이트웨이 전반에 걸쳐 잘못된 구성, 누락된 경로 및 통신 실패를 신속하게 식별할 수 있습니다.

이 자습서에서는 일반적인 연결 문제에 대한 기본적인 문제 해결 기술에 중점을 둡니다. 이러한 도구를 효과적으로 사용하여 문제 해결을 단순화하고 문제를 효율적으로 해결하는 방법을 설명하지만, 목표는 도구 자체를 사용하는 방법뿐만 아니라 연결 문제에 접근하고 분석하는 방법에 대한 광범위한 이해를 개발하는 것입니다.

목표

Network Visualizer 툴을 사용하여 지역, VCN 및 서브넷 레벨에서 네트워크 레이아웃을 탐색할 수 있습니다.
네트워크 경로 분석기 툴을 사용하여 트래픽 플로우 경로를 분석하여 패킷이 네트워크를 통과하고 오류를 식별하는 방법을 이해합니다.
VCN 플로우 로그 도구를 해석하여 트래픽 플로우 레코드를 검사하고 접속 문제 또는 비정상적인 동작을 감지합니다.
네트워크 잘못된 구성, 누락된 경로 및 통신 실패를 식별하고 해결합니다.

필수 조건

VCN, 서브넷, 게이트웨이, 보안 목록 및 라우팅 테이블과 같은 기본 OCI 네트워킹 구성요소를 잘 알고 있습니다.
네트워크 리소스가 구성된 OCI 테넌시에 액세스할 수 있습니다.
사용자 계정에는 VCN 구성요소를 관리하고 네트워크 시각화 처리기, 네트워크 경로 분석기 및 VCN 플로우 로그를 사용하려면 OCI IAM(Oracle Cloud Infrastructure Identity and Access Management) 정책이 필요합니다.

예정된 예제와 함께 따라가려면 테스트 Oracle Linux VM(가상 머신)에서 다음 명령을 실행하여 간단한 Apache 웹 사이트를 구축합니다.

sudo dnf install httpd --assumeyes
sudo systemctl enable httpd
sudo systemctl start httpd
sudo firewall-offline-cmd --add-service=http
sudo systemctl restart firewalld
sudo vi /var/www/html/index.html

'<!doctype html><html><body><h1>Test Apache Website.. it's reachable!</h1></body></html>'

작업 1: Network Visualizer를 사용하여 네트워크 설정 보기

깨진 것을 파기하기 전에 한 걸음 물러서서 네트워크 환경을 명확하게 파악하는 데 도움이 됩니다. OCI의 Network Visualizer는 VCN 토폴로지의 그래픽 표현을 제공합니다. 문제를 직접 해결하지는 않지만 선택한 특정 구획의 전체 네트워크 아키텍처에 대한 명확하고 통합된 뷰를 제공합니다.

이 시각적 컨텍스트는 모든 항목이 한 곳에서 연결(VCN, 서브넷, 게이트웨이, 라우팅 테이블, 보안 목록)되는 방식을 보여줍니다. 따라서 누락된 경로나 DRG(동적 경로 지정 게이트웨이)와 연관되지 않은 VCN과 같이 보이는 모든 항목을 쉽게 찾을 수 있습니다. 복잡한 설정에서는 추측을 많이 줄일 수 있습니다. 항상 고치는 것은 아니지만 세부 사항에 들어가기 전에 올바른 방향으로 안내 할 수있는 견고한 첫 번째 단계입니다.

이 자습서에서는 다음 다이어그램에서 Network Visualizer의 작동 방식을 요약했습니다. 자세한 내용은 네트워크 시각화 처리기를 참조하십시오.

예

다음 아키텍처를 예로 사용하겠습니다.

이 예제에서는 환경에 두 가지 문제가 발생했습니다. Network Visualizer가 이를 식별하고 해결하는 데 어떻게 도움이 되는지 살펴보겠습니다.

문제 1: VM-1에서 VM-2를 ping할 수 없습니다.
문제 2: VM-2가 인터넷에 연결할 수 없습니다.

OCI 콘솔에서 Network Visualizer를 사용하여 구조를 간단히 살펴보겠습니다.

첫번째 레벨: 지역 네트워크 토폴로지

이 토폴로지에는 DRG, VCN, CPE 및 다양한 유형의 게이트웨이가 포함됩니다.

OCI 콘솔에 로그인합니다.
1. 당신이 올바른 지역에 있는지 확인하십시오.
2. 왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭하십시오.
3. 네트워킹을 누릅니다.
4. 네트워크 시각화 처리기를 누릅니다.

Network Visualizer에 액세스하면 표시되는 첫번째 뷰입니다. 그것을 무너뜨리자.
1. 네트워크 구성요소가 상주하는 컴파트먼트를 선택합니다. 리소스가 어디에 있는지 확실하지 않으면 상위 컴파트먼트(또는 루트 컴파트먼트)를 선택하고 하위 컴파트먼트 포함을 선택합니다.
2. VCN-1 및 VCN-2가 있는 VCN과 각 VCN에 대한 IPv4 주소 블록에 유의하십시오.
3. 다음과 같은 네트워크 게이트웨이를 확인합니다.
  - 여러 연결(VCN, RPC 및 IPSec)이 있는 DRG입니다.
  - VCN-2의 NAT 게이트웨이입니다.
4. 리야드 지역의 VCN을 다른 지역(리야드)과 연결하는 RPC(원격 피어링 연결)도 표시됩니다.
5. 온프레미스 네트워크에 대한 IPSec 접속도 있습니다. 고객의 CPE 디바이스(210.20.x.x)의 공용 IP와 VCN(172.16.16.10/32)과 비공개로 통신할 온프레미스 네트워크 주소 블록을 확인할 수 있습니다.

VCN-2을 누릅니다.
이제 라우팅 맵부터 시작하여 VCN 토폴로지를 자세히 살펴보겠습니다.

두번째 레벨: VCN 토폴로지

이 토폴로지에는 서브넷, VLAN 및 다른 리소스에 대한 게이트웨이가 포함됩니다. 서브넷에서 사용하는 보안 규칙(보안 목록 또는 NSG) 외에.

현재 VCN 경로 지정 맵 뷰에 있습니다.
VCN-2는 하나의 전용 서브넷으로 구성됩니다.
서브넷의 라우트 테이블에서 다음 홉으로 VCN-1로 향하는 트래픽을 DRG로 보내는 규칙을 볼 수 있습니다.

VCN 보안 맵 뷰로 전환합니다.
이 뷰에서 VCN-2는 하나의 전용 서브넷으로 구성됩니다.
또한 개인 서브넷에 연결된 보안 목록 및 NSG(네트워크 보안 그룹)도 이 모드에서 볼 수 있습니다.

전용(private) 서브넷을 누릅니다.
이제 인벤토리 맵부터 시작하여 서브넷 토폴로지를 자세히 살펴보겠습니다.

세번째 레벨: 서브넷 토폴로지

이 토폴로지는 OCI 컴퓨트 인스턴스, OCI 로드 밸런서, OCI 파일 스토리지 서비스 및 서브넷의 OCI Kubernetes 엔진(OKE) 클러스터에 대한 리소스 정보와 리소스가 사용하는 보안 규칙을 보여줍니다.

우리는 서브넷 Inventory 맵 뷰에 있습니다.
이 서브넷(VM-2)에는 하나의 컴퓨트 인스턴스만 있습니다. 해당 인스턴스를 누르십시오.
컴파트먼트, IP 등과 같은 VM에 대한 일부 정보를 확인할 수 있습니다.

서브넷 보안 맵 뷰로 전환합니다.
이 서브넷에는 하나의 컴퓨트 인스턴스만 있습니다(VM-2).
VM-2에서 사용 중인 보안 목록 및 NSG가 표시됩니다.

요약:

네트워크 환경과 관련된 구성 요소가 어떻게 보이는지 살펴보았습니다. 앞에서 언급한 문제의 근본 원인은 무엇이라고 생각하십니까?

문제 1: VM-1에서 VM-2를 ping할 수 없습니다.

첫번째 레벨: 지역 네트워크 토폴로지에서 VCN-1가 DRG에 연결되지 않았으므로 VM-1와 VM-2 사이에 통신 플로우가 발생하려면 VCN-1를 연결하고 필요한 경로 규칙을 추가하여 트래픽 플로우를 사용으로 설정해야 합니다.

VCN-1를 연결하고 다음 경로 규칙(대상: VCN-2, 다음 홉: DRG)을 추가하면 문제가 해결됩니다. 즉, VCN-2의 경로 지정이 이미 제대로 구성되어 있고 ICMP 유형 8이 두 보안 목록에서 모두 허용된다고 가정합니다.
문제 2: VM-2가 인터넷에 연결할 수 없습니다.

두 번째 레벨: VCN 토폴로지에서 VCN-2의 전용 서브넷에는 DRG에 대한 경로가 하나만 있지만 NAT 게이트웨이에 대한 경로가 없으므로 VM-2에 인터넷 연결이 설정되지 않습니다.

다음 경로 규칙(대상: 0.0.0.0/0, 다음 홉: NAT 게이트웨이)을 추가하면 문제가 해결됩니다. 송신 트래픽이 보안 목록에서 이미 허용된다고 가정합니다.

Network Visualizer를 사용하면 예제에서 보듯이 잘못된 구성으로 인한 명백한 문제를 발견할 수 있습니다. 그러나 명확한 문제를 밝히지 않더라도 실제 가치는 환경에 대한 전체적인 시각을 제공하는 데 있습니다. 이 큰 그림의 관점은 현재 설정을 검증하는 데 도움이 되며 보다 복잡한 문제를 더 깊이 파고들기 전에 확실한 출발점을 제공합니다.

작업 2: 네트워크 구성 검증

네트워크 환경과 보유한 구성 요소를 명확하게 파악한 후 다음 필수 단계는 실제 구성을 검증하는 것입니다. 많은 연결 문제는 경로 누락, 지나치게 엄격한 보안 규칙 또는 단순히 잘못된 경로 테이블이나 보안 목록에 연결된 서브넷 등 단순한 문제로 이어집니다.

로그 확인 또는 패킷 캡처 실행과 같은 보다 심층적인 문제 해결을 시작하기 전에 모든 것이 예상대로 구성되었는지 확인해야 합니다. 이 단계는 종종 근본 원인을 조기에 드러내고 나중에 불필요한 조사를 피할 수 있습니다.

예

다음 아키텍처를 예로 사용하겠습니다.

먼저 구성 검증에 핵심적인 역할을 하는 핵심 라우팅 및 보안 구성 요소에 대해 간략하게 설명하겠습니다.

절차순서 규칙:
- 온프레미스:
  - RT-0: FastConnect 또는 IPSec 연결의 경우 온프레미스 CPE(Customer Premises Equipment) 장치(또는 멀티클라우드)의 라우팅(공급업체: Cisco, Fortinet 등 참조).
- OCI VCN 라우트 테이블: VCN에 존재하며 VCN에서 트래픽을 전송하는 데 사용됩니다(예: 인터넷, 온프레미스 네트워크 또는 피어링된 VCN으로). 이러한 라우트 테이블에는 이미 익숙한 기존 네트워크 라우트 규칙과 유사한 규칙이 있습니다.
  - RT-1-2-3: 송신 트래픽 경로를 지정하기 위해 서브넷 레벨에 지정된 VCN 경로 지정 테이블입니다.
  - RT-2a: 전송 경로 지정 시나리오에 필요한 DRG VCN-2 연결에 지정된 VCN 경로 지정 테이블입니다. 이 예에서는 송신 경로 테이블로 사용되어 검사를 위해 방화벽을 통해 DRG에서 오는 트래픽을 경로 지정합니다.
  - RT-2b: NAT 게이트웨이에 연결된 VCN 경로 지정 테이블입니다. 이 예에서는 검사를 위해 인터넷에서 방화벽으로 수신되는 응답 트래픽을 경로 지정하는 송신 경로 테이블로 사용됩니다.
- OCI DRG 라우트 테이블: DRG에 존재하며 연결을 통해 DRG로 들어가는 패킷의 경로를 지정하는 데 사용됩니다.
  - RT-10-20-30: VCN 연결에 대한 DRG 경로 지정 테이블로, VCN에서 오는 트래픽을 경로 지정합니다.
  - RT-40-50: RPC 연결에 대한 DRG 경로 지정 테이블로, 다른 지역에서 오는 트래픽을 경로 지정합니다.
  - RT-60: IPSec 연결용 DRG RT, 온프레미스 또는 멀티클라우드 네트워크에서 오는 트래픽 경로 지정
보안 규칙
- 온프레미스:
  - FW-0: FastConnect 또는 IPSec 연결(공급업체: Cisco, Fortinet 등)의 경우 온프레미스 CPE 장치(또는 멀티클라우드)에서 OCI로의 트래픽 플로우 제어 및 제한
- OCI VCN 보안 목록: 허용되는 트래픽 유형을 지정하는 수신 및 송신 규칙과 함께 VCN 기반 리소스에 대한 가상 방화벽 역할을 합니다. 보안 목록은 서브넷 레벨에서 구성됩니다. 즉, 서브넷의 모든 VNIC에는 동일한 보안 목록 세트가 적용됩니다.
  - SL-1-2-3: 각 서브넷의 수신 및 송신 트래픽을 제어하기 위해 서브넷 레벨에 지정된 보안 목록입니다.
주: NSG는 OCI에서 사용할 수 있는 또 다른 유형의 가상 방화벽입니다. 보안 목록과 유사하게 작동하지만 리소스 레벨에서 적용되므로 보다 세분화된 제어를 제공합니다. 이는 동일한 서브넷의 두 리소스에 다른 보안 상태가 필요한 경우에 유용합니다. 그러나 이 튜토리얼에서는 NSG가 사용되지 않습니다. 자세한 내용은 보안 목록 및 네트워크 보안 그룹 비교를 참조하십시오.
- OCI Network Firewall 또는 서드파티 방화벽(Third-Party Firewall): 서브넷, VCN, 외부 네트워크 간의 트래픽을 위한 중앙화된 상태 저장 검사 지점 역할을 수행하며, 기본 보안 목록 규칙을 뛰어넘는 고급 보안 정책을 시행합니다.
  - FW-2: OCI 네트워크 환경에서 남북 및 동서 트래픽을 모두 제어하고 검사합니다.

환경 전반에서 라우팅 및 보안이 어떻게 적용되는지 이해하여 다음 샘플 사례에 대해 자세히 살펴보겠습니다. 네 가지 문제가 발생했습니다. 몇 가지 상식을 적용하여 각 문제 해결 시나리오에 대해 어떤 구성을 확인하고 어디에 있는지 파악합니다.

참고:

NSG가 사용되는 경우 모든 VM에 연결된 각 VNIC에 적용된 구성을 검토합니다.

이 예에서 VM-2는 타사 방화벽(FortiGate)으로 작동합니다. 트래픽을 제대로 라우팅하도록 이미 구성되어 있습니다.

문제 1: VM-1가 VM-3를 ping할 수 없습니다(영역마다 방화벽이 트래픽을 검사하지 않아야 함).
- 경로 지정:
  - 요청: RT-1 > RT-10 > RT-40.
  - 응답: RT-3 > RT-30 > RT-50
- 보안: ICMP 유형 8은 성공적인 핑을 가질 수 있어야 합니다.
  - 요청: SL-1(송신 규칙) > SL-3(송신 규칙)
  - 응답: SL-3(송신 규칙) > SL-1(송신 규칙)
문제 2: VM-1가 인터넷에 연결할 수 없습니다(VM-2 방화벽이 트래픽을 검사해야 함).
- 경로 지정:
  - 요청: RT-1 > RT-10 > RT-2a > FW-2 내부 경로 지정 > RT-2.
  - 응답: RT-2b > FW-2 라우팅 > RT-2 > RT-20
- 보안:
  - 요청: SL-1(송신 규칙) > SL-2(송신 및 송신 규칙) > FW-2(송신 및 송신 규칙)
  - 응답: SL-2(수신 및 송신 규칙) > FW-2(수신 및 송신 규칙) > SL-1(수신 규칙)
문제 3: VM2가 인터넷에 연결할 수 없습니다.
- 경로 지정:
  - 요청: RT-2.
  - 응답: 공정순서가 필요하지 않습니다.
- 보안:
  - 요청: SL-2(송신 규칙).
  - 응답: SL-2(수신 규칙).
문제 4: 온프레미스가 VM-1를 ping할 수 없습니다(방화벽이 트래픽을 검사해야 함).
- 경로 지정:
  - 요청: RT-0(온프레미스 CPE) > RT-60 > RT-2a > FW-2 내부 라우팅 > RT-2 > RT-20
  - 응답: RT-1 > RT-10 > RT-2a > FW-2 내부 경로 지정 > RT-2 > RT-20
- 보안:
  - 요청: FW-0(송신 규칙) > SL-2(송신 및 송신 규칙) > FW-2(송신 및 송신 규칙) > SL-1(송신 규칙)
  - 응답: SL-1(송신 규칙) > SL-2(수신 및 송신 규칙) > FW-2(수신 및 송신 규칙) > FW-0(수신 규칙)

네트워크 전체에서 트래픽이 관리되고 제어되는 방식을 이해하는 것이 중요합니다. 트래픽을 추적하면 문제가 발생할 수 있는 위치와 문제 해결 시 검토해야 하는 설정을 빠르게 식별할 수 있습니다.

작업 3: 네트워크 경로 분석기 활용

전체 네트워크 설정을 검토하고 경로 지정 및 보안 규칙 구성을 수동으로 확인했습니다. 그러나 문제가 지속되고 일부 구성 세부 정보가 간과되었을 수 있으므로 다음 단계는 무엇입니까?

네트워크 경로 분석기가 들어오는 위치입니다. OCI 네트워크 라우팅 및 보안 구성을 실시간으로 검사하도록 설계된 가상 네트워크 탐정으로 생각해 보십시오. 이를 수집 및 분석하여 소스와 대상 간의 경로가 작동하거나 실패하는 방식을 결정합니다. 실제 트래픽은 전송되지 않고 구성을 검사하여 연결성을 확인하는 데 사용됩니다.

Network Path Analyzer는 개별 VM 또는 데이터베이스에서 ping 또는 telnet과 같은 수동 연결 테스트를 수행하는 대신 OCI 콘솔 내에서 직접 통신 경로 구성을 확인하여 보다 효율적이고 중앙화된 문제 해결 접근 방식을 제공합니다.

네트워크 경로 분석기는 다음 시나리오를 지원합니다.

OCI에서 OCI로.
OCI에서 온프레미스로 지원
온프레미스에서 OCI로
인터넷에서 OCI로
OCI에서 인터넷으로

예제 1

다음 아키텍처를 예로 사용하겠습니다.

네트워크 문제가 발생했으며 Network Path Analyzer를 사용하여 근본 원인을 추적하고 해결할 것입니다.

문제: VM-1는 VM-2(OCI to OCI)에서 호스팅된 웹사이트에 액세스할 수 없습니다.

OCI 콘솔에 로그인하고 VM-2으로 이동하여 다음 명령을 실행하여 웹 사이트가 로컬에서 실행 중인지 확인합니다.
```
curl localhost
```
OCI 콘솔로 이동하여 VM-1로 이동하고 동일한 명령을 실행하여 VM-2에 대한 연결을 테스트합니다.
```
curl 192.168.0.20
```
그러면 요청이 실패하는 것을 볼 수 있습니다. 다음 단계에서는 네트워크 경로 분석기를 사용하여 원인을 조사합니다.
OCI 콘솔로 이동합니다.
1. 당신이 올바른 지역에 있는지 확인하십시오.
2. 왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭하십시오.
3. 네트워킹을 누릅니다.
4. 네트워크 경로 분석기를 누릅니다.
경로 분석 생성을 누릅니다.
이제 테스트할 네트워크 플로우의 세부정보를 구성해 보겠습니다.
1. Name을 test-vm1-to-vm2-port80으로 입력합니다.
2. Protocol(프로토콜)을 TCP로 선택합니다.
먼저 소스 정보(이 경우 VM-1)를 채웁니다.
1. OCI 리소스 찾기를 선택합니다.
2. 소스 유형을 컴퓨트 인스턴스(VNIC)로 선택합니다.
3. 목록에서 VM-1을 선택합니다.
4. 트래픽을 생성할 VNIC를 선택합니다(VM에 VNIC가 하나만 있는 경우 이미 자동 채워짐).
5. 소스 IPv4 주소 10.0.0.10를 선택합니다(IPv4 주소가 하나만 있는 경우 자동으로 채워짐).
1. 고급 옵션을 표시합니다를 누릅니다.
2. 여기서 필요한 경우 소스 포트를 지정할 수 있습니다. 이 예에서는 Use any port로 설정된 상태로 둡니다.
다음으로 대상 정보를 입력합니다. 이 경우 VM-2입니다.
1. OCI 리소스 찾기를 선택합니다.
2. 소스 유형을 컴퓨트 인스턴스(VNIC)로 선택합니다.
3. 목록에서 VM-2를 선택합니다.
4. 트래픽을 생성할 VNIC를 선택합니다(VM에 VNIC가 하나만 있는 경우 이미 자동 채워짐).
5. 소스 IPv4 주소를 192.168.0.20로 선택합니다(IPv4 주소가 하나만 있는 경우 자동으로 채워짐).
6. Destination port에 80을 입력합니다.
1. 순방향 및 역방향 트래픽을 모두 분석하려면 방향을 양방향으로 유지합니다.
2. 분석 실행을 누릅니다.
1. 분석이 실행되면 연결 세부 정보가 표시됩니다.
2. 아래로 스크롤하여 분석 진행률을 추적하고 분석이 완료될 때까지 기다립니다. 이 작업은 1-2분 정도 걸릴 수 있습니다.
분석이 완료되었습니다. 전달 경로 결과 확인을 시작하겠습니다.
1. 분석에 따르면 두 개의 성공한 홉 이후에는 VM-2에 연결할 수 없습니다.
2. DRG와 VM-2 사이에 드롭이 발생합니다.
3. 자세한 내용을 보려면 다이어그램 정보 보기를 누릅니다.
4. 이 표에서는 경로의 각 단계에서 경로 지정 플로우 및 보안 검사를 분석합니다.
5. 확대하면 트래픽이 DRG와 VM-2 간에 거부되는 것을 확인할 수 있습니다.
1. 자세한 내용을 보려면 동일한 세그먼트를 확장하십시오.
2. 경로 지정이 성공적으로 전달되었습니다.
3. 그러나 누락된 보안 규칙으로 인해 트래픽이 거부됩니다.
  1. (3.a) 송신 트래픽이 허용되며 여기에는 문제가 없습니다.
  2. (3.b) 수신 트래픽은 허용되는 규칙이 없기 때문에 거부됩니다. VM-2 서브넷과 연관된 보안 목록(VCN-2에 대한 기본 보안 목록)이 표시되고, 다음 단계에서 검토할 예정이므로 기록해 둡니다. 이 시점에서 문제의 원인을 확인했습니다.
1. 전달 경로 검사를 실패했으므로 반환 경로가 분석되지 않았습니다.
2. 분석 저장를 누릅니다.
3. 언제든지 분석을 다시 방문하고 재실행할 수 있습니다. 문제를 해결한 후 이 자습서의 뒷부분에서 다시 실행합니다.
1. 대상 VM이 있는 VCN-2로 이동합니다.
2. 보안을 누릅니다.
3. VCN-2의 기본 보안 목록을 누릅니다.
주: 보안 목록은 서브넷 레벨에서 작동합니다. 즉, 이러한 규칙에 따라 허용되는 트래픽은 해당 서브넷 내의 모든 VNIC에 적용됩니다.
1. 보안 규칙을 누릅니다.
2. 테이블에는 허용되는 트래픽이 표시됩니다. HTTP를 포함 하는 다른 모든 것은 그것을 허용 하는 규칙이 없기 때문에 기본적으로 거부 됩니다. 그래서 VM-1는 VM-2에서 호스팅되는 웹 사이트에 액세스 할 수 없습니다.
3. 이 문제를 해결하려면 수신 규칙 추가를 누릅니다.
1. 소스 CIDR 필드에 10.0.0.0/16을 입력합니다(VCN-1에 대한 CIDR).
2. IP Protocol에 대해 TCP를 선택합니다.
3. 80을 Destination Port로 설정합니다.
4. 수신 규칙 추가를 누릅니다.
VM-1에 로그인하고 동일한 명령을 실행하여 VM-2에 대한 연결을 테스트합니다.
```
curl 192.168.0.20
```
이제 웹 사이트에 연결할 수 있음을 알 수 있습니다.
분석으로 돌아가서 다른 실행을 수행하고 문제가 해결되었는지 확인합니다.
분석을 누릅니다.
분석이 완료될 때까지 기다립니다.
분석이 완료되었습니다. 전방 경로 결과를 확인해 보겠습니다.
1. 이제 상태에 접근 가능이 표시됩니다.
2. 홉 3은 HTTP 트래픽을 허용하는 보안 규칙을 추가했기 때문에 이제 성공했습니다.
3. 다이어그램 정보 보기를 누릅니다.
4. 홉 3에 대한 보안 상태가 이제 허용됨(이전에는 거부됨)임을 확인할 수 있습니다.
반환 경로를 확인하면 성공적임을 확인할 수 있습니다.

예제 2

다음 아키텍처를 예로 사용하겠습니다.

네트워크 문제가 발생했으며 Network Path Analyzer를 사용하여 근본 원인을 추적하고 해결할 것입니다.

문제: VM-2가 텔넷 패키지(OCI to Internet)를 설치할 수 없습니다.

주: Telnet은 네트워크를 통해 원격으로 장치에 액세스하고 관리하는 데 사용되는 네트워크 프로토콜 및 명령줄 도구입니다. 기본 네트워크 테스트에도 사용됩니다(예: 포트가 열려 있는지 확인).

VM-2에 telnet를 설치할 수 있는지 확인합니다.
1. VM-2에 로그인하고 다음 명령을 실행하여 telnet를 설치합니다.
```
sudo yum install telnet
```
2. 계속하려면 y을 입력하고 Enter를 누릅니다.
3. 설치를 실패했습니다. VM-2가 지역 YUM 저장소(yum.me-jeddah-1.oci.oraclecloud.com)에 연결하려고 시도했지만 연결할 수 없습니다.
1. 아래 명령을 실행하여 yum 저장소의 IP를 찾습니다.
```
dig yum.me-jeddah-1.oci.oraclecloud.com
```
2. IP 주소를 기록합니다. VM-2는 이러한 공용 IP에 연결할 수 없습니다. 즉, 서비스 게이트웨이를 통해 NAT 게이트웨이 또는 Oracle Services Network에 대한 전용 액세스를 통해 인터넷에 액세스할 수 없거나 yum 저장소에 도달할 때 송신 트래픽이 차단되고 있음을 나타냅니다. 문제의 최하위에 도달하기 위해 다음 단계에서 NPA 분석을 진행할 것입니다.
OCI 콘솔로 이동합니다.
1. 당신이 올바른 지역에 있는지 확인하십시오.
2. 왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭하십시오.
3. 네트워킹을 누릅니다.
4. 네트워크 경로 분석기를 누릅니다.
경로 분석 생성을 누릅니다.
이제 테스트할 네트워크 플로우의 세부정보를 구성해 보겠습니다.
1. Name을 test-vm2-to-internet-port443으로 입력합니다.
2. Protocol(프로토콜)을 TCP로 선택합니다.
먼저 소스 정보(이 경우 VM-2)를 채웁니다.
1. OCI 리소스 찾기를 선택합니다.
2. 소스 유형을 컴퓨트 인스턴스(VNIC)로 선택합니다.
3. 목록에서 VM-2을 선택합니다.
4. 트래픽을 생성할 VNIC를 선택합니다(VM에 VNIC가 하나만 있는 경우 이미 자동 채워짐).
5. 소스 IPv4 주소를 192.168.0.20로 선택합니다(IPv4 주소가 하나만 있는 경우 자동으로 채워짐).
1. 고급 옵션을 표시합니다를 누릅니다.
2. 여기서 필요한 경우 소스 포트를 지정할 수 있습니다. 이 예에서는 Use any port로 설정된 상태로 둡니다.
다음으로 대상 정보를 입력합니다. 이 경우 인터넷, 특히 yum 저장소(192.29.119.92 및 192.29.125.93)의 공용 IP인 대상 정보 중 하나만 사용하여 테스트합니다.
1. Enter IP address(IP 주소 입력)를 선택합니다.
2. 대상 IPv4 주소 192.29.119.92를 입력합니다.
3. 저장소에 대한 액세스가 HTTPS를 통해 이루어지므로 대상 포트를 443으로 입력합니다.
1. 순방향 및 역방향 트래픽을 모두 분석하려면 방향을 양방향으로 유지합니다.
2. 분석 실행을 누릅니다.
1. 분석이 실행되면 연결 세부 정보가 표시됩니다.
2. 아래로 스크롤하여 분석 진행률을 추적하고 분석이 완료될 때까지 기다립니다. 이 작업은 1-2분 정도 걸릴 수 있습니다.
분석이 완료되었습니다. 전달 경로 결과 확인을 시작하겠습니다.
1. 분석은 VM-2가 인터넷에 도달 할 수 없음을 보여줍니다.
2. 이 세그먼트는 트래픽이 VCN-2를 종료하지 못하도록 하는 누락된 구성을 강조 표시합니다.
3. 자세한 내용을 보려면 다이어그램 정보 보기를 누릅니다.
4. 이 표에서는 경로의 각 단계에서 경로 지정 플로우 및 보안 검사를 분석합니다. 알 수 있듯이 흐름은 그 사이에 중간 홉이 없기 때문에 직접적입니다.
5. 확대하면 이 트래픽에 대해 정의된 경로 없음이 표시됩니다.
1. 자세한 내용을 보려면 동일한 세그먼트를 확장하십시오.
2. 인터넷을 통해 트래픽을 전송하도록 구성된 경로 지정이 없습니다. 이를 해결하려면 VM-2 서브넷 경로 테이블(VCN-2에 대한 기본 경로 테이블)에 규칙을 추가하고 다음 작업에서 검토하므로 기록해 두어야 합니다. 이 시점에서 문제의 원인을 확인했습니다.
3. 보안은 허용됨입니다.
  1. (3.a) 송신 트래픽이 허용되며 여기에는 문제가 없습니다.
  2. (3.b) 시나리오가 아웃바운드 트래픽에만 중점을 두므로 이 경우 수신 트래픽은 관련이 없습니다.
1. 전달 경로 검사를 실패했으므로 반환 경로가 분석되지 않았습니다.
2. 분석 저장를 누릅니다.
3. 언제든지 분석을 다시 방문하고 재실행할 수 있습니다. 문제를 해결한 후 이 자습서의 뒷부분에서 다시 실행합니다.
1. 소스 VM이 있는 VCN-2로 이동합니다.
2. 공정순서를 누릅니다.
3. VCN-2의 기본 경로 테이블을 누릅니다.
주: 경로 테이블은 서브넷 레벨에서 작동합니다. 즉, 테이블에 정의된 모든 규칙이 해당 서브넷 내의 모든 리소스에 적용됩니다. 경로 테이블은 리소스별 경로 지정을 사용하여 특정 VNIC 또는 IP 주소와 연관될 수도 있습니다. 그러나 이것은 우리의 튜토리얼과 관련이 없습니다. 자세한 내용은 자원별 경로 지정을 참조하십시오.
1. 경로 규칙을 누릅니다.
2. 현재는 트래픽을 VCN-1로 라우팅하도록 구성된 라우트 규칙이 하나만 있습니다.
3. 인터넷 액세스를 사용으로 설정하려면 경로 규칙 추가를 누릅니다.
1. NAT 게이트웨이를 대상 유형으로 선택합니다.
2. 0.0.0.0/0를 대상 CIDR 블록으로 입력합니다.
3. 이전에 생성한 NAT Gateway를 선택합니다.
4. 순로 규칙 추가를 누릅니다.
VM-2에 로그인하고 telnet를 다시 설치해 보십시오.
1. 다음 명령을 실행합니다.
```
sudo yum install telnet
```
2. 설치가 완료되었습니다!.
분석으로 돌아가서 다른 실행을 수행하고 문제가 해결되었는지 확인합니다.
분석을 누릅니다.
분석이 완료될 때까지 기다립니다.
분석이 완료되었습니다. 전방 경로 결과를 확인해 보겠습니다.
1. 이제 상태에 접근 가능이 표시됩니다.
2. NAT 게이트웨이로 트래픽을 전송하는 경로 규칙을 추가했기 때문에 이제 홉 2가 성공했습니다.
3. 다이어그램 정보 보기를 누릅니다.
4. 이제 홉 2에 대한 경로 지정 상태가 전달됨(이전에는 경로 없음)임을 확인할 수 있습니다.
반환 경로를 확인하면 성공적임을 확인할 수 있습니다.

작업 4: VCN 흐름 로그 분석

VCN 플로우 로그는 트래픽 동작에 대한 추가적인 가시성 계층을 제공합니다. 이 서비스를 사용하면 각 VNIC를 공격하는 실제 트래픽으로 드릴다운하여 보안 목록 및 NSG 규칙에 따라 수락 또는 거부되었는지 여부를 표시하여 보안 관련 문제를 해결할 수 있습니다.

문제 해결 외에도 VCN 플로우 로그는 네트워크 작업을 모니터링하고 소스/대상 IP, 포트, 프로토콜 및 시간 기록을 캡처하여 감사 및 보안 조사에 필요한 세부 원격 측정을 제공하는 데 중요합니다.

예

다음 아키텍처를 예로 사용하겠습니다.

주: 이 예에서는 대상이 있는 Y 지점에서만 로깅하는 데 중점을 둡니다. 그러나 동일한 단계를 적용하여 X 지점(트래픽 소스)에서 로그를 사용으로 설정하고 분석하여 전체 트래픽 플로우에 대한 추가 가시성을 확보할 수 있습니다.

네트워크 문제가 발생했으며 VCN 플로우 로그를 사용하여 근본 원인을 추적하고 해결할 것입니다.

문제: VM-1가 VM-2에 호스트된 웹 사이트에 액세스할 수 없습니다.

VM-2에 로그인하고 다음 명령을 실행하여 웹 사이트가 로컬에서 실행 중인지 확인합니다.
```
curl localhost
```
VM-1에 로그인하고 동일한 명령을 실행하여 VM-2에 대한 연결을 테스트합니다.
```
curl 192.168.0.20
```
그러면 요청이 실패하는 것을 볼 수 있습니다. 다음 단계에서는 VCN-2 플로우 로그를 사용하여 원인을 조사합니다.
이제 로그를 사용으로 설정합니다. 먼저 OCI에서 로깅을 위해 캡처하거나 VTAP(가상 테스트 액세스 지점)에 미러링할 네트워크 트래픽을 결정하기 위해 사용되는 간단한 규칙 집합인 캡처 필터를 생성합니다.
1. OCI 콘솔에 로그인하여 오른쪽 리전에 있는지 확인합니다.
2. 왼쪽 상단 모서리에서 햄버거 메뉴 (≡)를 클릭하십시오.
3. 네트워킹을 누릅니다.
4. 캡처 필터를 누릅니다.
캡처 필터 생성을 누릅니다.
1. vcn-2-private-sn-logs에 Name(이름)을 입력합니다.
2. 플로우 로그 캡처 필터를 필터 유형으로 선택합니다.
3. 샘플링 속도를 100%로 설정합니다. 캡처할 네트워크 플로우의 백분율을 정의합니다. 이 경우 모든 트래픽을 기록하려고 합니다.
1. 다른 설정은 모두 기본값으로 둡니다.
2. 캡처 필터 생성을 누릅니다.
캡처 필터가 생성되면 복사를 눌러 OCID를 복사합니다. OCID는 다음 단계에서 필요합니다.
이제 로그를 사용으로 설정할 준비가 완료되었습니다.
1. VCN-2로 이동하십시오.
2. 전용 서브넷을 엽니다. 여기서 VM-2은 상주합니다.
3. 모니터링을 누릅니다.
4. 아래로 스크롤하여 Logs 섹션을 찾습니다.
5. 플로우 로그 범주 옆에 있는 3개의 점(••)을 누릅니다.
6. 로그 사용을 누릅니다.
1. 로그 그룹을 선택합니다. 아직 로그 그룹이 없으면 새 로그 그룹을 생성합니다.
2. 로그 이름은 자동으로 채워집니다.
3. 이전에 복사한 캡처 필터 OCID를 붙여넣습니다.
4. 로그 사용을 누릅니다.
플로우 로그가 이제 활성 상태입니다.
VM-1에서 다음 명령을 실행하여 동일한 테스트를 반복하여 트래픽을 생성합니다.
```
curl 192.168.0.20
```
로그 섹션으로 돌아가서 이전에 생성한 로그 이름을 누릅니다.
1. 아래로 스크롤하면 네트워크에 들어가거나 나가는 트래픽을 보여주는 로그가 표시됩니다.
2. 작업을 누릅니다.
3. 고급 필터를 적용하고 로그 결과 범위를 좁히려면 로그 검색으로 탐색을 누릅니다.
1. 테스트 연결과 일치하도록 다음 필터를 적용합니다.
  - 소스 IP(VM-1): data.sourceAddress = '10.0.0.10'.
  - 대상 IP(VM-2): data.destinationAddress = '192.168.0.20'.
  - 대상 포트(HTTP): data.destinationPort = 80.
2. 필요한 경우 시간별 필터링에서 시간 범위를 조정하거나 기본값인 지난 5분으로 둡니다.
3. 검색을 누릅니다.
1. 검색 기준과 일치하는 결과를 검토합니다.
2. 레코드 세부 사항을 확장합니다.
이 특정 레코드에 대해 이 트래픽 플로우에 대한 자세한 정보를 볼 수 있습니다. 참고할 주요 필드는 다음과 같습니다.
1. 시간 기록: 트래픽이 서브넷에 도달한 정확한 날짜 및 시간입니다.
2. 접속 세부정보: 소스 IP 주소, 대상 IP 주소 및 포트 번호와 같은 정보입니다.
3. 조치: 트래픽이 처리된 방법을 보여줍니다. 이 경우 REJECT입니다. 따라서 문제의 근본 원인을 확인하고 VM-2에 대한 HTTP 트래픽을 허용하는 보안 규칙이 없습니다.
HTTP 트래픽이 VM-2에 도달하도록 허용하려면 다음 두 가지 옵션이 있습니다.
- 보안 목록: 서브넷 레벨에서 적용됨. 즉, 서브넷의 모든 VNIC에 동일한 보안 목록 집합이 적용됩니다.
- NSG: 리소스 레벨(VNIC 레벨)에서 적용됩니다.
여기서는 이미 VM-2 서브넷과 연관된 기본 보안 목록에서 허용하려고 합니다.
1. 대상 VM이 있는 VCN-2로 이동합니다.
2. 보안을 누릅니다.
3. VCN-2의 기본 보안 목록을 누릅니다.
1. 보안 규칙을 누릅니다.
2. 테이블에는 허용되는 트래픽이 표시됩니다. HTTP를 포함 하는 다른 모든 것은 그것을 허용 하는 규칙이 없기 때문에 기본적으로 거부 됩니다. 그래서 VM-1는 VM-2에서 호스팅되는 웹 사이트에 액세스 할 수 없습니다.
3. 이 문제를 해결하려면 수신 규칙 추가를 누릅니다.
1. 10.0.0.0/16에 Source CIDR(VCN-1에 대한 CIDR)을 입력합니다.
2. TCP를 IP Protocol로 선택합니다.
3. 80을 Destination Port로 설정합니다.
4. 수신 규칙 추가를 누릅니다.
VM-1에 로그인하고 동일한 명령을 실행하여 VM-2에 대한 연결을 테스트합니다.
```
curl 192.168.0.20
```
이제 웹 사이트에 연결할 수 있음을 알 수 있습니다.
로그로 돌아가서 새 검색을 수행하기 전과 동일한 단계를 반복합니다.
1. 테스트 연결과 일치하도록 다음 필터를 적용합니다.
  - 소스 IP(VM-1): data.sourceAddress = '10.0.0.10'.
  - 대상 IP(VM-2): data.destinationAddress = '192.168.0.20'.
  - 대상 포트(HTTP): data.destinationPort = 80.
2. 필요한 경우 시간 범위를 조정하거나 기본값으로 둡니다(지난 5분).
3. 검색을 누릅니다.
1. 검색 기준과 일치하는 결과를 검토합니다.
2. 레코드 세부 사항을 확장합니다.
이 특정 레코드에 대해 이 트래픽 플로우에 대한 자세한 정보를 볼 수 있습니다. 참고할 주요 필드는 다음과 같습니다.
1. 시간 기록: 트래픽이 서브넷에 도달한 정확한 날짜 및 시간입니다.
2. 접속 세부정보: 소스 IP, 대상 IP 및 포트 번호와 같은 정보입니다.
3. 조치: 트래픽 처리 방법을 보여줍니다. 문제를 해결한 후 이제 트래픽이 ACCEPT 상태임을 확인할 수 있습니다.

다음 단계

아키텍처, 라우팅 및 보안 구성을 검토하여 OCI의 기본적인 네트워킹 문제를 해결하는 방법을 모색했습니다. 이러한 핵심 검사는 가장 일반적인 연결 문제를 해결하는 데 도움이 됩니다. 다음 튜토리얼에서는 고급 시나리오와 실제 사용 사례에 대해 중점적으로 다룹니다.

승인

Authors - Anas Abdallah(클라우드 네트워킹 전문가), Sachin Sharma(클라우드 네트워킹 전문가)

추가 학습 자원

docs.oracle.com/learn에서 다른 랩을 탐색하거나 Oracle Learning YouTube 채널에서 더 많은 무료 학습 콘텐츠에 액세스하세요. 또한 education.oracle.com/learning-explorer를 방문하여 Oracle Learning Explorer가 되십시오.

제품 설명서는 Oracle Help Center를 참조하십시오.

제목 및 저작권 정보

Troubleshoot Basic Network Issues in Oracle Cloud Infrastructure

G40744-01

Oracle and/or its affiliates.