다중 네트워크 인터페이스
이 페이지에서는 가상 머신(VM) 인스턴스의 다중 네트워크 인터페이스를 간략히 살펴보고 작동 방식 및 샘플 구성을 설명합니다. 다중 인터페이스를 사용하는 구성 만들기에 대한 자세한 내용은 다중 네트워크 인터페이스가 포함된 VM 만들기를 참조하세요.
Google Cloud Virtual Private Cloud(VPC) 네트워크는 기본적으로 격리되어 있는 비공개 네트워킹 도메인입니다. 네트워크에는 전역 범위와 리전 서브넷이 포함됩니다. VPC 네트워크 내부의 VM 인스턴스는 방화벽 규칙에서 허용하는 한 내부 IP 주소를 사용하여 서로 통신할 수 있습니다. 하지만 VPC 네트워크 피어링 또는 Cloud VPN과 같은 기능을 설정하지 않는 한, 네트워크 간 내부 IP 주소 통신은 허용되지 않습니다.
VPC 네트워크의 모든 인스턴스에는 기본 네트워크 인터페이스가 있습니다. 네트워크 인터페이스를 구성할 때 인터페이스를 연결할 VPC 네트워크와 해당 VPC 네트워크 내의 서브넷을 선택합니다. VM에 연결되는 네트워크 인터페이스를 추가로 만들 수 있지만 각 인터페이스는 다른 VPC 네트워크에 연결되어야 합니다. 다중 네트워크 인터페이스를 활용하면 인스턴스에서 다수의 VPC 네트워크에 직접 연결되는 구성을 만들 수 있습니다.
각 인스턴스는 인스턴스 유형에 따라 최대 8개의 인터페이스를 포함할 수 있습니다. 자세한 내용은 인터페이스 최대 개수를 참조하세요.
각 인터페이스는 다음 IP 주소를 구성할 수 있습니다.
- 내부 IPv4 주소(필수)
- 외부 IPv4 주소
IPv6 주소(내부 또는 외부 중 하나)
IPv6 주소를 구성하려면 IPv6 범위가 구성된 서브넷에 인터페이스를 연결해야 합니다.
일반적으로 부하 분산, 침입 감지 및 방지(IDS/IPS), 웹 애플리케이션 방화벽(WAF) 또는 네트워크 간의 WAN 최적화를 수행하는 네트워크 어플라이언스로 인스턴스를 구성하려는 경우 다중 인터페이스가 필요할 수 있습니다. 또한 인스턴스에서 실행 중인 애플리케이션에 데이터 영역 트래픽과 관리 영역 트래픽의 구분과 같은 트래픽 구분이 필요한 경우에도 다중 네트워크 인터페이스가 유용합니다.
VM의 각 인터페이스는 연결된 네트워크의 MTU에 영향을 받습니다. 인터페이스 MTU에 대한 상세 설명은 최대 전송 단위를 참조하세요.
사용 사례
개별 인스턴스가 2개 이상의 VPC 네트워크에 액세스해야 하지만, 두 네트워크에 직접 연결하지는 않으려는 경우 다중 네트워크 인터페이스를 사용할 수 있습니다.
네트워크 및 보안 기능: 다중 네트워크 인터페이스는 가상화된 네트워크 어플라이언스가 다중 네트워크 인터페이스로 구성된 부하 분산기, NAT(네트워크 주소 변환) 서버, 프록시 서버로 작동할 수 있게 해줍니다. 자세한 내용은 예시 1: 네트워킹 및 보안 가상 어플라이언스를 참조하세요.
경계 격리(DMZ 격리라고도 함): 계층형 네트워킹 아키텍처에서 중요한 권장사항은 공개용 서비스를 내부 네트워크 및 해당 서비스에서 격리하는 것입니다. 다중 네트워크 인터페이스를 사용하여 구성을 만듭니다. 여기에는 인스턴스에 개별 네트워크 인터페이스가 있으며 이 중 하나로 공개용 트래픽을 수신하고 다른 하나는 액세스 제어가 보다 제한적인 백엔드 비공개 트래픽을 처리합니다.
인터넷에서 연결할 수 있는 모든 리소스는 내부 네트워크 및 해당 서비스와 구분되어야 합니다. 이렇게 하면 보안 위반이 발생할 수 있는 범위와 손상 정도가 크게 제한됩니다. 예를 들어 애플리케이션 서버가 상주하는 중간 등급 네트워크에 연결되는 두 번째 네트워크 인터페이스를 각 웹 서버에 배치할 수 있습니다. 또한 데이터베이스 서버가 상주하는 백엔드 네트워크를 사용하여 애플리케이션 서버 네트워크를 이중으로 구성할 수 있습니다. 이중 네트워크로 구성된 각 인스턴스는 프런트엔드의 요청을 수신 및 처리하고 백엔드로 연결을 시작한 후 요청을 백엔드 네트워크의 서버로 보냅니다.
인터페이스를 공개용 하나와 비공개용 하나로 별도 구성하여 각 인터페이스에 방화벽 규칙 및 액세스 제어를 개별적으로 적용하고 공개 도메인에서 비공개 도메인으로의 통신에 보안 기능을 강제 적용할 수 있습니다. 자세한 내용은 예 2: 공유 VPC 네트워크 시나리오에서 제3자 어플라이언스 사용을 참조하세요.
구성 예
이 섹션에서는 다중 네트워크 인터페이스 사용 방법에 대한 몇 가지 일반적인 예를 살펴봅니다.
예시 1: 네트워킹 및 보안 가상 어플라이언스
웹 애플리케이션 방화벽(WAF), 보안 애플리케이션 수준 방화벽, WAN 액셀러레이터와 같은 네트워킹 및 보안 가상 어플라이언스는 일반적으로 다중 가상 인터페이스를 사용하여 구성됩니다. 각 다중 인터페이스는 자체 내부 IP 주소와 자체 외부 IP 주소(선택사항)로 구성됩니다.
그림 1은 인터넷에서 VPC 네트워크로의 트래픽을 제어하는 애플리케이션 수준 방화벽의 구성 예시입니다. 애플리케이션 수준 방화벽은 Compute Engine VM에서 구현됩니다.
이 예시에서 어플라이언스 VM의 기본 경로는 nic1을 사용하도록 구성되었습니다.
그림 1. VM 어플라이언스가 있는 인스턴스에는 3개의 네트워크 인터페이스가 있습니다. 각 인터페이스는 다른 VPC 네트워크에 있는 서브넷에 연결됩니다(확대하려면 클릭).
예시 1의 인스턴스 프로비저닝 및 구성
다음 섹션에서는 subnet0, subnet1, subnet2가 이미 존재하고 중첩 범위가 없다고 가정합니다.
이 예시에서는 VM 및 네트워크 인터페이스를 만들기 위해 다음 명령어를 사용합니다.
gcloud compute instances create vm-appliance \
--network-interface subnet=subnet0,no-address \
--network-interface subnet=subnet1 \
--network-interface subnet=subnet2,no-address \
--machine-type n1-standard-4
이 명령어는 네트워크 인터페이스가 3개 있는 인스턴스를 만듭니다.
nic0은subnet0에 연결되며 외부 IP 주소가 없습니다.nic1은subnet1에 연결되며 임시 외부 IP 주소를 갖습니다.nic2는subnet2에 연결되며 외부 IP 주소가 없습니다.
예시 2: 공유 VPC 네트워크 시나리오에서 제3자 어플라이언스 사용
이 설정은 여러 프로젝트에서 호스팅되는 워크로드 또는 애플리케이션에 중앙 집중식 제3자 어플라이언스의 단일 집합을 공유하려고 할 때 유용합니다. 그림 2에는 서로 다른 서비스 프로젝트에서 호스팅되는 App1, App2, App3, App4의 고유한 애플리케이션 4개가 있습니다. 모든 인터넷 인그레스를 보호하고 공유 VPC 호스트 프로젝트에 중앙 집중식으로 배치된 제3자 어플라이언스에서 이그레스 트래픽을 조사 및 필터링해야 합니다.
그림 2. 공유 VPC 호스트 프로젝트의 인스턴스는 VM 어플라이언스를 호스팅합니다. 인스턴스에는 4개의 서비스 프로젝트 각각에 대한 네트워크 인터페이스와 네트워크 경계 VPC 네트워크에 대한 다른 인터페이스가 있습니다(확대하려면 클릭).
예시 2의 VM과 네트워크 인터페이스 프로비저닝 및 구성
이 예시에서는 VM 및 네트워크 인터페이스를 만들기 위해 다음 명령어를 사용합니다.
gcloud compute instances create VM-appliance \
--network-interface subnet=subnet-perimeter,address='reserved-address' \
--network-interface subnet=subnet-1,no-address \
--network-interface subnet=subnet-2,no-address \
--network-interface subnet=subnet-3,no-address \
--network-interface subnet=subnet-4,no-address \
--machine-type=n1-standard-4
이렇게 하면 네트워크 인터페이스가 5개 있는 인스턴스가 생성됩니다.
nic0은 고정 주소reserved-address를 사용하여network-perimeter의 일부인subnet-perimeter에 연결됩니다.nic1은 외부 IP 주소 없이network-1의 일부인subnet-1에 연결됩니다.nic2은 외부 IP 주소 없이network-2의 일부인subnet-2에 연결됩니다.nic3은 외부 IP 주소 없이network-3의 일부인subnet-3에 연결됩니다.nic4는 외부 IP 주소 없이network-4의 일부인subnet-4에 연결됩니다.
추가 작업 세부정보
공유 VPC 환경의 다중 네트워크 인터페이스
공유 VPC를 사용하면 Google Cloud 조직의 프로젝트 간에 VPC 네트워크를 공유할 수 있습니다.
공유 VPC를 사용하면 중앙 집중식 공유 VPC 호스트 프로젝트에서 호스팅되는 공유 VPC 네트워크와 연결된 인스턴스를 만들 수 있습니다. 공유 VPC 네트워크 구성에 대한 자세한 내용은 공유 VPC 프로비저닝을 참조하세요.
하나 이상의 인터페이스가 공유 VPC 네트워크에 연결된 인스턴스를 만들려면 공유 VPC 호스트 프로젝트에 Compute 네트워크 사용자 역할(roles/compute.networkUser)이 있어야 합니다.
다중 네트워크 인터페이스에서 DNS 확인
내부 DNS 쿼리가 인스턴스 호스트 이름으로 작성된 경우, 인스턴스의 기본 인터페이스(nic0)로 확인됩니다. 인스턴스의 nic0 인터페이스가 내부 DNS 쿼리를 실행하는 인스턴스의 VPC 네트워크와 다른 VPC 네트워크에서 서브넷에 연결된 경우 쿼리가 실패합니다.
비공개 Compute Engine DNS 레코드는 인터페이스별로 생성되지 않습니다.
다중 네트워크 인터페이스의 DHCP 동작
기본 다중 인터페이스 구성에서 OS는 DHCP를 사용하도록 구성됩니다. 각 다중 인터페이스의 DHCP 및 ARP 동작은 단일 인터페이스가 있는 인스턴스의 DHCP 및 ARP와 동일합니다.
DHCP를 사용하는 다중 인터페이스 인스턴스에서 모든 인터페이스는 인터페이스가 있는 서브넷의 경로를 가져옵니다. 또한 인스턴스는 기본 인터페이스인 eth0과 연결된 단일 기본 경로를 가져옵니다. 수동으로 달리 구성하지 않는 한 직접 연결된 서브넷을 제외한 모든 대상의 인스턴스에서 나가는 모든 트래픽은 eth0의 기본 경로를 통해 나갑니다.
이 동작은 IPv6 주소가 사용한 인터페이스와 동일합니다. 이 인터페이스는 현재 위치한 IPv6 서브넷 범위의 경로와 단일 IPv6 기본 경로를 가져옵니다.
이 샘플에서 기본 인터페이스 eth0은 기본 경로(default via 10.138.0.1 dev eth0)를 가져오고, eth0 및 eth1 인터페이스 모두 해당 서브넷의 경로를 가져옵니다.
instance-1:~$ ip route default via 10.138.0.1 dev eth0 10.137.0.0/20 via 10.137.0.1 dev eth1 10.137.0.1 dev eth1 scope link 10.138.0.0/20 via 10.138.0.1 dev eth0 10.138.0.1 dev eth0 scope link
자세한 내용은 정책 라우팅 구성 섹션을 참조하세요.
커스텀 정적 경로 및 다중 네트워크 인터페이스
VM 인스턴스에 다중 인터페이스와 네트워크 태그가 있는 경우 네트워크 태그는 VM의 모든 인터페이스에 영향을 미치지 않을 수 있습니다. 일치하는 태그가 있는 커스텀 정적 경로가 포함된 VPC 네트워크에 인터페이스가 있는 경우 VM의 네트워크 태그가 인터페이스에 영향을 줍니다.
예를 들면 다음과 같습니다.
- VM에
nic0및nic1의 2개 인터페이스가 있습니다.nic0인터페이스는vpc-net-a에 있고nic1인터페이스는vpc-net-b에 있습니다. VM에는vpn-ok라는 네트워크 태그가 있습니다. 태그는 특정 인터페이스가 아닌 인스턴스의 속성입니다. vpc-net-a네트워크에는vpn-ok라는 태그가 포함된 커스텀 정적 경로가 있습니다.vpc-net-b네트워크에는vpn-123라는 태그가 포함된 커스텀 정적 경로가 있습니다.
이 번호가 매겨진 단계는 그림 3에 해당합니다.
그림 3.
vpc-net-a의 커스텀 정적 경로는 서로 공통의 태그를 갖기 때문에 nic0에 영향을 주는 반면, vpc-net-b의 커스텀 정적 경로는 nic1에 영향을 주지 않습니다(확대하려면 클릭).
vpc-net-a 네트워크는 VM과 태그를 공유하는 경로를 사용하므로 VM의 vpn-ok 태그가 vpc-net-a에 있는 VM의 nic0 인터페이스에 적용됩니다. 반면에 vpc-net-b 네트워크에는 vpn-ok 태그가 있는 정적 경로가 없으므로 VM의 vpn-ok 네트워크 태그가 VM의 nic1 인터페이스에서 무시됩니다.
다중 네트워크 인터페이스가 포함된 인스턴스에서 경로에 태그 사용
경로에 태그를 사용하도록 선택할 경우, 태그가 인스턴스 수준에서 적용되므로 가상 머신 인스턴스의 모든 인스턴스에 태그가 적용됩니다. 이렇게 하지 않으려면 경로에 적용된 태그가 각 VPC 네트워크에 대해 고유한지 확인합니다.
부하 분산기 및 다중 네트워크 인터페이스
내부 TCP/UDP 부하 분산을 제외한 모든 Google Cloud 부하 분산기는 백엔드 인스턴스의 첫 번째 인터페이스(nic0)에만 트래픽을 분산합니다.
방화벽 규칙 및 다중 네트워크 인터페이스
각 VPC 네트워크에는 자체 방화벽 규칙 집합이 있습니다. 인스턴스의 인터페이스가 특정 VPC 네트워크에 있으면 해당 네트워크의 방화벽 규칙이 이 인터페이스에 적용됩니다.
예를 들어 VM 인스턴스에 인터페이스가 2개 있다고 가정해 보겠습니다.
- VPC 네트워크
network-1에 있는nic0 - VPC 네트워크
network-2에 있는nic1
network-1에 생성한 방화벽 규칙은 nic0에 적용됩니다.
network-2에 생성한 방화벽 규칙은 nic1에 적용됩니다.
자세한 내용은 VPC 방화벽 규칙을 참조하세요.
다중 네트워크 인터페이스가 있는 인스턴스의 방화벽
인그레스 방화벽 규칙은 네트워크 태그 또는 서비스 계정을 사용하여 소스나 대상 또는 둘 다 식별할 수 있습니다.
이그레스 방화벽 규칙은 네트워크 태그 또는 서비스 계정을 사용하여 대상(소스)을 식별할 수 있습니다.
자세한 내용은 서비스 계정별 소스 및 대상 필터링을 참조하세요.
네트워크 태그 및 서비스 계정은 특정 인터페이스가 아닌 인스턴스를 식별합니다. 방화벽 규칙은 단일 VPC 네트워크와 연결되고, 다중 NIC 인스턴스의 각 인터페이스는 고유 VPC 네트워크에 있는 서브넷에 있어야 합니다.
다음 예시는 인그레스 allow 방화벽 규칙의 소스 태그를 효과적으로 사용하는 방법을 보여줍니다. vm1 인스턴스에는 네트워크 인터페이스가 2개 있습니다.
network-1의nic0network-2의nic1
vm1에서 다음 트래픽을 허용해야 한다고 가정해 보세요.
vm1에서network-1의 모든 인스턴스로 이동하는 SSH 트래픽vm1에서network-2의 모든 인스턴스로 이동하는 HTTP 및 HTTPS 트래픽
이를 완료하려면 다음 작업을 수행해야 합니다.
vm1에 2개의 네트워크 태그를 할당합니다(vm1-network1및vm1-network2).아래 구성요소로
network-1에 인그레스allow방화벽 규칙을 만들어서vm1에서network-1의 모든 VM으로 이동하는 SSH 트래픽을 허용합니다.- 작업:
allow - 방향:
ingress - 소스:
vm1-network1태그가 있는 VM - 대상: VPC 네트워크의 모든 인스턴스
- 프로토콜 및 포트:
tcp:22
- 작업:
다음 구성요소를 사용하여
network-2에 인그레스 허용 방화벽 규칙을 만들어vm1에서network-2의 모든 VM으로 이동하는 HTTP 및 HTTPS 트래픽을 허용합니다.- 작업:
allow - 방향:
ingress - 소스:
vm1-network2태그가 있는 VM - 대상: VPC 네트워크의 모든 인스턴스
- 프로토콜 및 포트:
tcp:80,443
- 작업:
그림 4는 이 방화벽 구성의 예시를 보여줍니다.
그림 4.
방화벽 규칙 1과 방화벽 규칙 2에는 각각 VM1과 연결된 소스 태그가 있습니다. network-1에 있는 방화벽 규칙 1은 둘 다 network-1에 있으므로 VM1의 nic0에만 영향을 미칩니다. 방화벽 규칙 2는 네트워크도 공유하므로 VM1의 nic1에만 영향을 미칩니다 (확대하려면 클릭).