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을 관리하는 사람은 누구인가, 터널을 패치하는 사람은 누구인가. 세 답이 모두 워크로드 하나를 가리키면 게스트 클라이언트가 정직한 설계입니다. 하나라도 서브넷을 가리키면 지금 네트워크 계층을 설계하십시오.

관련 글