Azure VM 하나에 터널이 필요할 때: 게스트 클라이언트인가 VPN 게이트웨이인가
단일 Azure VM이 자체 VPN 클라이언트를 실행해야 하는지, 아니면 연결이 네트워크 계층에 속하는지를 세 가지 조건이 결정합니다.
Azure VM 하나의 워크로드 하나가 터널을 통해 사설 네트워크에 도달해야 합니다. 설계를 결정하는 질문은 어떤 VPN 제품이 더 나은가가 아니라, 다른 머신이 그 경로를 언젠가 필요로 할 것인가입니다. 이 질문에 먼저 답하면 나머지 아키텍처는 대개 스스로 정해집니다. 여기서 틀리면 아무도 문서화하지 않은 라우터가 조용히 되어버린 VM을 물려받게 됩니다.
비슷해 보이는 두 가지 역할
VM은 엔드포인트가 될 수도, 중계 지점이 될 수도 있습니다. 차이는 설치하는 소프트웨어가 아니라 터널을 누가 소비하는가입니다. 엔드포인트로서 게스트는 자기 프로세스를 위해 클라이언트를 실행합니다. 중계 지점으로서 다른 워크로드의 패킷을 전달하므로 VM은 네트워크 토폴로지의 일부가 됩니다.
| 역할 | VM이 하는 일 | 라우팅 소유자 |
|---|---|---|
| 워크로드 엔드포인트 | 자기 프로세스를 위해 지원되는 클라이언트를 실행한다 | 게스트 경로가 승인된 목적지를 선택한다 |
| 중계 어플라이언스 | 다른 워크로드를 사이트 연결로 전달한다 | 서브넷 경로 테이블, NIC 전달, 게스트 정책, 반환 경로 |
단일 VM 요청의 대부분은 두 번째 역할의 언어를 입은 첫 번째 역할입니다. 누군가 “VM이 우리 VPN이다”라고 말하지만, 실제로는 그 위의 애플리케이션 하나가 반대편 데이터베이스에 닿아야 한다는 뜻입니다.
조건 하나: 다른 무언가가 반대편을 필요로 하는가
답이 아니오라면 게스트에 클라이언트를 설치하고 설계를 멈추십시오. 그 선택에 관리형 게이트웨이가 필요한 것도 아니고, 그 때문에 VM이 이웃의 게이트웨이가 되는 것도 아닙니다. 운영 체제 하나 안에 경로를 추가하는 일입니다.
답이 예라면, 또는 일 년 안에 아마 예라면 지금 네트워크 설계로 다루십시오. 다른 VM이 중계 VM에 도달하는 것은 서브넷 경로 테이블이 그쪽으로 보내고 NIC가 전달 트래픽을 받아들일 때뿐이므로, 작업은 경로 테이블과 전달 권한이며 클라이언트를 하나 더 설치하는 일이 아닙니다.
조건 둘: 관리 경로를 유지할 수 있는가
넓은 경로를 설치하는 VPN 클라이언트는 VM을 관리하는 경로를 점유할 수 있습니다. 터널의 목적지 목록이 관리 네트워크와 겹치면 클라이언트가 연결되는 순간 SSH나 RDP 세션이 끊기고, 수정은 시리얼 콘솔이나 재구축을 통해서만 가능합니다.
전과 후를 확인하십시오. Linux에서는 ip route get <management-ip> 가 커널이 지금 어떤 인터페이스와 소스를 쓸지 보여줍니다. 터널이 올라간 상태의 답과 비교하십시오. 목적지를 명시한 분할 터널이 기본 경로보다 설명하기 쉬우며, 보통 워크로드가 실제로 필요로 하는 것입니다.
조건 셋: 자정에 누가 패치하는가
게스트 클라이언트는 곧 여러분의 운영 체제, 클라이언트 버전, 인증서입니다. 이미 VM과 그 패치 주기를 운영하고 있다면 괜찮습니다. VM이 터널을 유지하려고만 존재한다면 나쁜 거래입니다. 게스트 클라이언트가 더 싸다고 말하기 전에 패치 시간을 세어 보십시오. 재부팅이 필요한 클라이언트 업그레이드는, 터널을 유지하려고 존재하는 머신에 여러분이 직접 잡아둔 중단입니다.
관리형 게이트웨이는 그 유지 관리를 플랫폼으로 옮깁니다. ID, 권한 부여, 그 뒤의 네트워크 경로는 여전히 여러분의 몫이지만, 클라이언트 업데이트를 적용하려고 머신을 재부팅하지는 않습니다.
관리형 게이트웨이가 하지 않는 일
Azure VPN Gateway는 VNet 연결 서비스이며 자체 사이트 간 및 지점 간 구성을 가집니다. 게스트의 VPN 소프트웨어를 금지하는 규칙이 아니고, 애플리케이션 하나가 필요로 하는 클라이언트를 그대로 대체하는 것도 아닙니다.
이것이 주는 것은 네트워크 계층의 연결이며, 많은 워크로드가 라우팅을 통해 도달할 수 있습니다. 주지 않는 것은 한 VM의 한 프로세스만 사용하고 그 프로세스의 ID로 한정된 터널입니다. 이 한정은 사과할 결함이 아니라 게스트 클라이언트 설계의 핵심입니다. 애플리케이션 하나, 경로 하나, 자격 증명 한 세트, 서브넷의 다른 VM에는 영향이 없습니다.
따라서 비교는 관리형 대 소프트웨어가 아닙니다. 네트워크 범위 연결 대 프로세스 범위 연결이며, 후자는 프로세스 하나만 필요로 할 때 정당합니다.
필요해지기 전에 성장 경로를 계획하십시오
요구가 VM 하나에서 서브넷으로 커진다면 클라이언트의 허용 접두사를 넓히는 대신 설계를 다시 만드십시오. 편리한 세션을 문서화되지 않은 라우터로 재사용하면 모든 사용자가 그 VM의 수명, 자격 증명, 패치 창에 묶입니다.
연결이 워크로드 범위가 아니라 네트워크 범위가 되면 올바른 출발점은 Azure VPN Gateway 개요 입니다.
고르기 전에 세 줄을 쓰십시오. 반대편을 필요로 하는 것은 무엇인가, VM을 관리하는 사람은 누구인가, 터널을 패치하는 사람은 누구인가. 세 답이 모두 워크로드 하나를 가리키면 게스트 클라이언트가 정직한 설계입니다. 하나라도 서브넷을 가리키면 지금 네트워크 계층을 설계하십시오.