Intune에서 Microsoft Tunnel의 필수 조건

  • 아티클

Microsoft Intune 위한 Microsoft Tunnel VPN Gateway를 설치하기 전에 필수 구성 요소를 검토하고 구성합니다. 사전 요구 사항에는 Tunnel 서버 소프트웨어를 호스트하는 데 컨테이너를 실행하는 Linux 서버 사용이 포함됩니다. 또한 Microsoft Tunnel에 대한 통신을 지원하도록 네트워크, 방화벽 및 프록시를 구성할 계획입니다.

높은 수준에서 Microsoft Tunnel에는 다음이 필요합니다.

  • Azure 구독.

  • Microsoft Intune 플랜 1 구독.

  • 컨테이너를 실행하는 Linux 서버. 서버는 온-프레미스 또는 클라우드에 있을 수 있으며 다음 컨테이너 유형 중 하나를 지원합니다.

    • RHEL(Red Hat Enterprise Linux)용 Podman. Linux 서버 요구 사항을 참조하세요.
    • 다른 모든 Linux 배포판용 Docker입니다.

  • 디바이스에서 Tunnel 게이트웨이 서버로의 연결을 보호하기 위한 Linux 서버용 TLS(전송 계층 보안) 인증서입니다.

  • Android 또는 iOS/iPadOS를 실행하는 디바이스

필수 구성 요소를 구성한 후 준비 도구를 실행하여 성공적인 설치를 위해 환경이 잘 구성되어 있는지 확인하는 것이 좋습니다.

다음 섹션에서는 Microsoft Tunnel의 필수 조건에 대해 자세히 설명하고 준비 도구 사용에 대한 지침을 제공합니다.

참고

터널 및 GSA(전역 보안 액세스)는 동일한 디바이스에서 동시에 사용할 수 없습니다.

Linux 서버

Microsoft Tunnel Gateway를 설치할 Linux 기반 가상 머신 또는 물리적 서버를 설정합니다.

참고

다음 표에 나열된 운영 시스템 및 컨테이너 버전만 지원됩니다. 나열되지 않은 버전은 지원되지 않습니다. 테스트 및 지원 가능성을 확인한 후에만 이 목록에 추가된 최신 버전이 있습니다. 보안 업데이트와 함께 OS를 최신 상태로 유지합니다.

  • 지원되는 Linux 배포 - 다음 표에서는 Tunnel 서버에 대해 지원되는 Linux 버전과 필요한 컨테이너에 대해 자세히 설명합니다.

    배포 버전 컨테이너 요구 사항 고려 사항
    CentOS 7.4 이상 Docker CE 지원은 2024년 6월에 종료됩니다. CentOS 8 이상은 지원되지 않습니다.
    Red Hat(RHEL) 7.4 이상 Docker CE 지원 종료 2024년 6월
    Red Hat(RHEL) 8.6 Podman 4.0 (기본값)
    Podman 3.0    		 이 버전의 RHEL은 ip_tables 모듈을 Linux 커널에 자동으로 로드하지 않습니다. 이 버전을 사용하는 경우 Tunnel이 설치되기 전에 수동으로 ip_tables가 로드하도록 계획합니다.

    Podman v3 및 이전 버전에서 만든 컨테이너 는 Podman v4.0에서 사용할 수 없습니다. 컨테이너를 v3에서 v4.0으로 업그레이드하고 변경하는 경우 새 컨테이너를 만들고 Microsoft Tunnel을 제거한 다음 다시 설치할 계획입니다.
    RED Hat(RHEL) 8.7 Podman 4.2 (기본값) 이 버전의 RHEL은 ip_tables 모듈을 Linux 커널에 자동으로 로드하지 않습니다. 이 버전을 사용하는 경우 Tunnel이 설치되기 전에 수동으로 ip_tables가 로드하도록 계획합니다.

    Podman v3 및 이전 버전에서 만든 컨테이너 는 Podman v4.2 이상에서는 사용할 수 없습니다. 컨테이너를 업그레이드하고 변경하는 경우 새 컨테이너를 만들고 Microsoft Tunnel을 제거한 다음 다시 설치하도록 계획합니다.
    RHEL(Red Hat) 8.8 Podman 4.4.1 이 버전의 RHEL은 ip_tables 모듈을 Linux 커널에 자동으로 로드하지 않습니다. 이 버전을 사용하는 경우 Tunnel이 설치되기 전에 수동으로 ip_tables가 로드하도록 계획합니다.

    Podman v3 및 이전 버전에서 만든 컨테이너 는 Podman v4.2 이상에서는 사용할 수 없습니다. 컨테이너를 업그레이드하고 변경하는 경우 새 컨테이너를 만들고 Microsoft Tunnel을 제거한 다음 다시 설치하도록 계획합니다.
    RED Hat(RHEL) 8.9 Podman 4.4.1 이 버전의 RHEL은 ip_tables 모듈을 Linux 커널에 자동으로 로드하지 않습니다. 이 버전을 사용하는 경우 Tunnel이 설치되기 전에 수동으로 ip_tables가 로드하도록 계획합니다.

    Podman v3 및 이전 버전에서 만든 컨테이너 는 Podman v4.2 이상에서는 사용할 수 없습니다. 컨테이너를 업그레이드하고 변경하는 경우 새 컨테이너를 만들고 Microsoft Tunnel을 제거한 다음 다시 설치하도록 계획합니다.
    RED Hat(RHEL) 9.0 Podman 4.4.1 (기본값) 이 버전의 RHEL은 ip_tables 모듈을 Linux 커널에 자동으로 로드하지 않습니다. 이 버전을 사용하는 경우 Tunnel이 설치되기 전에 수동으로 ip_tables가 로드하도록 계획합니다.

    Podman v3 및 이전 버전에서 만든 컨테이너 는 Podman v4.2 이상에서는 사용할 수 없습니다. 컨테이너를 업그레이드하고 변경하는 경우 새 컨테이너를 만들고 Microsoft Tunnel을 제거한 다음 다시 설치하도록 계획합니다.

    지원은 2024년 2월에 종료됩니다.
    RHEL(Red Hat) 9.1 Podman 4.4.1 (기본값) 이 버전의 RHEL은 ip_tables 모듈을 Linux 커널에 자동으로 로드하지 않습니다. 이 버전을 사용하는 경우 Tunnel이 설치되기 전에 수동으로 ip_tables가 로드하도록 계획합니다.

    Podman v3 및 이전 버전에서 만든 컨테이너 는 Podman v4.2 이상에서는 사용할 수 없습니다. 컨테이너를 업그레이드하고 변경하는 경우 새 컨테이너를 만들고 Microsoft Tunnel을 제거한 다음 다시 설치하도록 계획합니다.
    RED Hat(RHEL) 9.2 Podman 4.4.1 (기본값) 이 버전의 RHEL은 ip_tables 모듈을 Linux 커널에 자동으로 로드하지 않습니다. 이 버전을 사용하는 경우 Tunnel이 설치되기 전에 수동으로 ip_tables가 로드하도록 계획합니다.

    Podman v3 및 이전 버전에서 만든 컨테이너 는 Podman v4.2 이상에서는 사용할 수 없습니다. 컨테이너를 업그레이드하고 변경하는 경우 새 컨테이너를 만들고 Microsoft Tunnel을 제거한 다음 다시 설치하도록 계획합니다.
    RED Hat(RHEL) 9.3 Podman 4.6.1. (기본값) 이 버전의 RHEL은 ip_tables 모듈을 Linux 커널에 자동으로 로드하지 않습니다. 이 버전을 사용하는 경우 Tunnel이 설치되기 전에 수동으로 ip_tables가 로드하도록 계획합니다.

    Podman v3 및 이전 버전에서 만든 컨테이너 는 Podman v4.2 이상에서는 사용할 수 없습니다. 컨테이너를 업그레이드하고 변경하는 경우 새 컨테이너를 만들고 Microsoft Tunnel을 제거한 다음 다시 설치하도록 계획합니다.
    Ubuntu 20.04 Docker CE
    Ubuntu 22.04 Docker CE

    중요

    2023년 4월에 Ubuntu는 Ubuntu 18.04에 대한 지원을 종료합니다. Ubuntu의 지원이 종료되면 Intune Microsoft Tunnel에서 사용할 Ubuntu 18.04에 대한 지원도 종료됩니다. 자세한 내용은 https://wiki.ubuntu.com/Releases을 참조하세요.

  • Linux 서버 크기 조정: 다음 지침에 따라 예상 사용량을 충족할 수 있습니다.

    디바이스 수 CPU 수 메모리(GB) 서버 수 사이트 수 디스크 공간(GB)
    1,000 4 4 1 1 30
    2,000 4 4 1 1 30
    5,000 8 8 2 1 30
    10,000 8 8 3 1 30
    20,000 8 8 4 1 30
    40,000 8 8 8 1 30

    선형적인 확장을 지원합니다. 각 Microsoft Tunnel은 최대 64,000개의 동시 연결을 지원하지만 개별 디바이스는 여러 연결을 열 수 있습니다.

  • CPU: 64비트 AMD/Intel 프로세서.

  • Docker CE 또는 Podman 설치: Tunnel 서버에 사용하는 Linux 버전에 따라 서버에 다음 중 하나를 설치합니다.

    • Docker 버전 19.03 CE 이상.
    • RHEL 버전에 따라 Podman 버전 3.0 또는 4.0.

    Microsoft Tunnel에서 컨테이너에 대한 지원을 제공하려면 Linux 서버에 Docker 또는 Podman이 설치되어 있어야 합니다. 컨테이너는 일관된 실행 환경, 상태 모니터링 및 사전 수정, 깔끔한 업그레이드 환경을 제공합니다.

    Docker 또는 Podman 설치 및 구성에 대한 자세한 내용은 다음을 참조하세요.

    • CentOS 또는 Red Hat Enterprise Linux 7에 Docker 엔진을 설치합니다.

      참고

      앞의 링크를 선택하면 CentOS 다운로드 및 설치 지침으로 이동합니다. RHEL 7.4에 대해 동일한 지침을 사용합니다. RHEL 7.4에 설치된 버전은 기본적으로 너무 오래되어 Microsoft Tunnel Gateway를 지원할 수 없습니다.

    • Ubuntu에 Docker 엔진을 설치합니다.

    • Red Hat Enterprise Linux 8.4 이상에 Podman을 설치합니다(RHEL8까지 아래로 스크롤).

      해당 버전의 RHEL은 Docker를 지원하지 않습니다. 대신 Podman을 사용하고 podman은 "container-tools"라는 모듈의 일부입니다. 이 컨텍스트에서 모듈은 구성 요소를 나타내는 RPM 패키지 집합이며 일반적으로 함께 설치됩니다. 일반적인 모듈에는 애플리케이션이 포함된 패키지, 애플리케이션별 종속성 라이브러리가 있는 패키지, 애플리케이션에 대한 설명서가 포함된 패키지 및 도우미 유틸리티가 포함된 패키지가 포함됩니다. 자세한 내용은 Red Hat 설명서의 모듈 소개를 참조하세요.

      참고

      루트 없는 Podman: Microsoft Tunnel은 루트 없는 Podman 컨테이너 사용을 지원합니다.

      루트 없는 Podman을 사용하려면 이 문서에 자세히 설명된 필수 구성 요소 와 터널 설치 스크립트를 시작할 때 수정된 명령줄을 사용해야 합니다. 추가 필수 구성 요소 및 설치 명령줄에 대한 자세한 내용은 Intune 위해 Microsoft Tunnel 구성 문서에서 루트 없는 Podman 컨테이너 사용을 참조하세요.

  • TLS(전송 계층 보안) 인증서: Linux 서버에서 디바이스와 터널 게이트웨이 서버 간의 연결을 보호하려면 신뢰할 수 있는 TLS 인증서가 필요합니다. Tunnel Gateway를 설치하는 동안 TLS 인증서 및 완전히 신뢰할 수 있는 인증서 체인을 서버에 추가합니다.

    • Tunnel Gateway 엔드포인트를 보호하는 데 사용되는 TLS 인증서의 SAN(주체 대체 이름)은 Tunnel Gateway 서버의 IP 주소 또는 FQDN과 일치해야 합니다.

    • TLS 인증서의 만료 날짜는 2년 이내여야 합니다. 날짜가 2년보다 길면 iOS 디바이스에서 허용되지 않습니다.

    • 와일드카드 지원은 제한됩니다. 예를 들어 *.contoso.com 지원되지만 cont*.com 지원되지 않습니다.

    • Tunnel Gateway 서버를 설치하는 동안 신뢰할 수 있는 인증서 체인 전체를 Linux 서버에 복사해야 합니다. 설치 스크립트는 인증서 파일을 복사할 위치를 제공하고 사용자에게 인증서 파일을 복사할지 묻습니다.

    • 공개적으로 신뢰할 수 없는 TLS 인증서를 사용하는 경우 Intune 신뢰할 수 있는 인증서 프로필을 사용하여 전체 신뢰 체인을 디바이스에 푸시해야 합니다.

    • TLS 인증서는 PEM 또는 pfx 형식일 수 있습니다.

    • TLS 인증서 해지 상태 검사 지원하려면 서버에서 TLS 인증서에 정의된 대로 OCSP(온라인 인증서 상태 프로토콜) 또는 CRL(인증서 해지 목록) 주소에 액세스할 수 있는지 확인합니다.

  • TLS 버전: 기본적으로 Microsoft Tunnel 클라이언트와 서버 간의 연결은 TLS 1.3을 사용합니다. TLS 1.3을 사용할 수 없는 경우 연결이 다시 대체되어 TLS 1.2를 사용할 수 있습니다.

기본 브리지 네트워크

Podman과 Docker 컨테이너는 모두 브리지 네트워크를 사용하여 Linux 호스트를 통해 트래픽을 전달합니다. 컨테이너 브리지 네트워크가 회사 네트워크와 충돌하는 경우 Tunnel Gateway는 트래픽을 해당 회사 네트워크로 성공적으로 라우팅할 수 없습니다.

기본 브리지 네트워크는 다음과 같습니다.

  • Docker: 172.17.0.0/16
  • Podman: 10.88.0.0/16

충돌을 피하기 위해 지정한 브리지 네트워크를 사용하도록 Podman과 Docker를 모두 다시 구성할 수 있습니다.

중요

브리지 네트워크 구성을 변경하려면 먼저 터널 게이트웨이 서버를 설치해야 합니다.

Docker에서 사용하는 기본 브리지 네트워크 변경

Docker는 /etc/docker/daemon.json 파일을 사용하여 새 기본 브리지 IP 주소를 구성합니다. 파일에서 브리지 IP 주소는 연결된 서브넷 마스크 및 라우팅 접두사와 함께 IP 주소를 나타내는 간결한 방법인 CIDR(Classless Inter-Domain Routing) 표기법으로 지정해야 합니다.

중요

다음 단계에서 사용되는 IP 주소는 예시입니다. 사용하는 IP 주소가 회사 네트워크와 충돌하지 않는지 확인하세요.

  1. 다음 명령을 사용하여 MS 터널 게이트웨이 컨테이너를 중지합니다. sudo mst-cli server stop ; sudo mst-cli agent stop

  2. 다음으로 다음 명령을 실행하여 기존 Docker 브리지 장치를 제거합니다. sudo ip link del docker0

  3. /etc/docker/daemon.json 파일이 서버에 있는 경우 vi 또는 nano와 같은 파일 편집기를 사용하여 파일을 수정합니다. 루트 또는 sudo 권한으로 파일 편집기를 실행합니다.

    • "bip": 항목에 IP 주소가 있는 경우 CIDR 표기법으로 새 IP 주소를 추가하여 수정합니다.
    • "bip": 항목이 없으면 값 "bip": 및 CIDR 표기법의 새 IP 주소를 모두 추가해야 합니다.

    다음 예제에서는 "192.168.128.1/24"의 수정된 IP 주소를 사용하는 항목인 업데이트된 "bip"가 있는 daemon.json 파일의 구조를 보여줍니다.

    daemon.json의 예:

    {
"bip": "192.168.128.1/24"
}

  4. / etc/docker/daemon.json 파일이 서버에 없는 경우 다음 예제와 유사한 명령을 실행하여 파일을 만들고 사용하려는 브리지 IP를 정의합니다.

    예: sudo echo '{ "bip":"192.168.128.1/24" }' > /etc/docker/daemon.json

  5. 다음 명령을 사용하여 MS 터널 게이트웨이 컨테이너를 시작합니다. sudo mst-cli agent start ; sudo mst-cli server start

자세한 내용은 Docker 문서에서 브리지 네트워크 사용을 참조하세요.

Podman에서 사용하는 기본 브리지 네트워크 변경

Podman은 /etc/cni/net.d 파일을 87-podman-bridge.conflist로 사용하여 새 기본 브리지 IP 주소를 구성합니다.

  1. 다음 명령을 사용하여 MS 터널 게이트웨이 컨테이너를 중지합니다. sudo mst-cli server stop ; sudo mst-cli agent stop

  2. 다음으로 다음 명령을 실행하여 기존 Podman 브리지 장치를 제거합니다. sudo ip link del cni-podman0

  3. 루트 권한 및 vi 또는 nano와 같은 파일 편집기를 사용하여 /etc/cni/net.d를 87-podman-bridge.conflist로 수정하여 Podman 기본값을 원하는 서브넷 및 게이트웨이 주소로 대체하여 "subnet:" 및 "gateway:" 의 기본값을 업데이트합니다. 서브넷 주소는 CIDR 표기법으로 지정해야 합니다.

    Podman 기본값은 다음과 같습니다.

    • 서브넷: 10.88.0.0/16
    • 게이트웨이: 10.88.0.1

  4. 다음 명령을 사용하여 MS 터널 게이트웨이 컨테이너를 다시 시작합니다. sudo mst-cli agent start ; sudo mst-cli server start

자세한 내용은 Red Hat 문서에서 Podman으로 컨테이너 네트워킹 구성을 참조하세요.

네트워크

  • IPv4에 대해 패킷 전달 사용: 터널 서버 소프트웨어를 호스트하는 각 Linux 서버는 IPv4에 대해 IP 전달을 사용하도록 설정해야 합니다. IP 전달 상태를 확인하려면 서버에서 다음 일반 명령 중 하나를 루트 또는 sudo로 실행합니다. 두 명령 모두 사용하지 않도록 설정한 경우 값 0을 반환하고, 사용하도록 설정한 경우 값 1을 반환합니다.

    • sysctl net.ipv4.ip_forward
    • cat /proc/sys/net/ipv4/ip_forward

    사용하도록 설정하지 않은 경우 서버에서 다음 일반 명령 중 하나를 루트 또는 sudo로 실행하여 IP 전달을 일시적으로 사용하도록 설정할 수 있습니다. 이러한 명령은 서버가 다시 시작될 때까지 IP 전달 구성을 변경할 수 있습니다. 다시 시작하면 서버가 IP 전달 동작을 이전 상태로 반환합니다. 두 명령 모두 값 1을 사용하여 전달을 사용하도록 설정합니다. 값 0 은 전달을 사용하지 않도록 설정합니다. 다음 명령 예제에서는 값 1을 사용하여 전달을 사용하도록 설정합니다.

    • sysctl -w net.ipv4.ip_forward=1
    • echo 1 > /proc/sys/net/ipv4/ip_forward

    IP 전달을 영구적으로 설정하려면 각 Linux 서버에서 /etc/sysctl.conf 파일을 편집하고 #net.ipv4.ip_forward=1에서 선행 해시태그(#)를 제거하여 패킷 전달을 사용합니다. 편집한 후에는 항목이 다음과 같이 표시됩니다.

    # Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

    이 변경 내용을 적용하려면 서버를 다시 부팅하거나 sysctl -p을(를) 실행해야 합니다.

    필수 항목이 sysctl.conf 파일에 없는 경우 설명서에서 IP 전달을 사용하도록 설정하는 방법에 사용하는 배포에 대해 참조하세요. 일반적으로 sysctl.conf에서 파일 끝에 누락된 줄을 추가하여 IP 전달을 영구적으로 사용하도록 설정할 수 있습니다.

  • 서버당 여러 NIC 구성(선택 사항) : Linux 서버당 두 개의 NIC(네트워크 인터페이스 컨트롤러)를 사용하여 성능을 개선하는 것이 좋습니다. 두 NIC를 사용하는 것은 선택 사항입니다.

    • NIC 1 - 이 NIC는 관리 디바이스의 트래픽을 처리하며, 공용 IP 주소를 사용하는 공용 네트워크에 있어야 합니다.  이 IP 주소는 사이트 구성에 지정된 주소입니다. 이 주소는 단일 서버 또는 부하 분산 장치를 나타낼 수 있습니다.

    • NIC 2 - 이 NIC는 온-프레미스 리소스에 대한 트래픽을 처리하며 네트워크 조각화가 없는 프라이빗 내부 네트워크에 있어야 합니다.

  • 클라우드 기반 Linux VM이 온-프레미스 네트워크에 액세스할 수 있는지 확인: 클라우드에서 VM으로 Linux를 실행하는 경우 서버에서 온-프레미스 네트워크에 액세스할 수 있는지 확인합니다. 예를 들어 Azure에서 실행되는 VM의 경우 Azure ExpressRoute 또는 이와 유사한 항목을 사용하여 액세스를 제공할 수 있습니다. 온-프레미스 VM에서 서버를 실행하는 경우에는 Azure ExpressRoute가 필요하지 않습니다.

  • 부하 분산 장치(선택 사항): 부하 분산 장치를 추가하도록 선택하는 경우 공급업체 설명서에서 구성 세부 정보를 참조하세요. Intune 및 Microsoft Tunnel과 관련된 네트워크 트래픽 및 방화벽 포트를 고려하세요.

    Tunnel 서버는 정적 페이지를 사용하여 GET 요청에 응답합니다. 응답은 터널 서버의 활성화를 위해 검사 방법으로 부하 분산 장치에 의해 프로브로 사용됩니다. 응답은 정적이며 중요한 정보를 포함하지 않습니다.

  • 앱별 VPN 및 최상위 도메인 지원 - 로컬 최상위 도메인의 내부 사용과 함께 앱별 VPN 사용은 Microsoft Tunnel에서 지원되지 않습니다.

방화벽

기본적으로 Microsoft Tunnel 및 서버는 다음 포트를 사용합니다.

인바운드 포트:

  • TCP 443 – Microsoft Tunnel에 필요합니다.
  • UDP 443 – Microsoft Tunnel에 필요합니다.
  • TCP 22 – 선택 사항입니다. Linux 서버에 대한 SSH/SCP 연결에 사용됩니다.

아웃바운드 포트:

  • TCP 443 – Intune 서비스에 액세스하는 데 필요합니다. Docker 또는 Podman에서 이미지를 끌어오는 데 필요합니다.

터널의 서버 구성을 만들 때 기본값 443이 아닌 다른 포트를 지정할 수 있습니다. 다른 포트를 지정하는 경우 해당 구성을 지원하도록 방화벽을 구성해야 합니다.

추가 요구 사항:

프록시

Microsoft Tunnel에 프록시 서버를 사용할 수 있습니다.

참고

프록시 서버 구성은 버전 10 이전의 Android 버전에서 지원되지 않습니다. 자세한 내용은 해당 Android 개발자 설명서의 VpnService.Builder 를 참조하세요.

참고

Android LOB 애플리케이션이 MDM 및 MAM 모두에 대해 직접 프록시 또는 PAC(프록시 자동 구성)를 지원하는지 확인합니다.

참고

알려진 문제: 개인 또는 회사 계정을 사용하여 Edge에 로그인하려는 사용자는 PAC(프록시 자동 구성)가 구성되면 문제가 발생할 수 있습니다. 이 시나리오에서는 로그인 프로세스가 실패하여 사용자가 내부 리소스에 액세스하지 못할 수 있습니다.

해결 방법: 이 문제를 resolve 위해 Microsoft Tunnel은 분할 터널링을 옵션으로 제공합니다. 분할 터널링을 사용하면 터널을 통한 라우팅에서 로그인 서버 및 인증 경로를 제외하면서 프록시가 필요한 경로만 포함할 수 있습니다. 이 해결 방법을 사용하면 로그인 프로세스가 PAC 구성의 영향을 받지 않으므로 사용자가 내부 리소스에 액세스하고 인터넷을 탐색할 수 있습니다.

직접 프록시는 회사 계정을 사용하여 Edge에서 로그인할 수 있도록 분할 터널링이 없는 옵션이기도 합니다. 여기에는 PAC URL 대신 직접 프록시를 사용하도록 Microsoft Tunnel을 구성하는 작업이 포함됩니다.

Edge에서 사용자 로그인이 필요하지 않은 경우 PAC는 일반적인 검색 및 내부 리소스 액세스에 지원됩니다.

다음 고려 사항을 참조하여 Linux 서버와 사용자 환경을 성공적으로 구성할 수 있습니다.

Docker에 대한 아웃바운드 프록시 구성

  • 내부 프록시를 사용하는 경우 환경 변수를 사용하여 프록시 서버를 사용하도록 Linux 호스트를 구성해야 할 수 있습니다. 변수를 사용하려면 Linux 서버에서 /etc/environment 파일을 편집하고 다음 줄을 추가합니다.

    http_proxy=[address]
    https_proxy=[address]

  • 인증된 프록시는 지원되지 않습니다.

  • Linux 서버는 Intune 연결할 때 TLS 상호 인증을 사용하므로 프록시가 중단을 수행하고 검사할 수 없습니다.

  • 프록시를 사용하여 이미지를 가져오도록 Docker를 구성합니다. 이렇게 하려면 Linux 서버에서 /etc/systemd/system/docker.service.d/http-proxy.conf 파일을 편집하고 다음 줄을 추가합니다.

    [Service]
Environment="HTTP_PROXY=http://your.proxy:8080/"
Environment="HTTPS_PROXY=https://your.proxy:8080/"
Environment="NO_PROXY=127.0.0.1,localhost"

    참고

    Microsoft Tunnel은 Microsoft Entra 애플리케이션 프록시 또는 유사한 프록시 솔루션을 지원하지 않습니다.

Podman에 대한 아웃바운드 프록시 구성

다음 세부 정보는 Podman을 사용할 때 내부 프록시를 구성하는 데 도움이 될 수 있습니다.

  • 인증된 프록시는 지원되지 않습니다.

  • Linux 서버는 Intune 연결할 때 TLS 상호 인증을 사용하므로 프록시가 중단을 수행하고 검사할 수 없습니다.

  • Podman은 /etc/profile.d/http_proxy.sh에 저장된 HTTP 프록시 정보를 읽습니다. 이 파일이 서버에 없으면 새로 만듭니다. http_proxy.sh를 편집하여 다음 두 줄을 추가합니다. 다음 줄에서 10.10.10.1:3128은 주소:포트 항목의 예입니다. 이러한 줄을 추가하면 10.10.10.1:3128를 프록시 IP 주소:포트 값으로 바꿉니다.

    export HTTP_PROXY=http://10.10.10.1:3128
    export HTTPS_PROXY=http://10.10.10.1:3128

    Red Hat 고객 포털에 액세스할 수 있는 경우 이 솔루션과 관련된 기술 자료 문서를 볼 수 있습니다. Podman - Red Hat 고객 포털의 HTTP 프록시 변수 설정을 참조하세요.

  • mstunnel-setup을 실행하여 Microsoft Tunnel Gateway를 설치하기 전에 http_proxy.sh 두 줄을 추가하면 스크립트는 /etc/mstunnel/env.sh Tunnel Gateway 프록시 환경 변수를 자동으로 구성합니다.

    Microsoft Tunnel Gateway 설정이 완료된 후 프록시를 구성하려면 다음 작업을 수행합니다.

    1. /etc/profile.d/http_proxy.sh 파일을 수정하거나 만들고 이전 중요 항목 중 두 줄을 추가합니다.

    2. /etc/mstunnel/env.sh를 편집하고 파일 끝에 다음 두 줄을 추가합니다. 이전 줄과 마찬가지로 10.10.10.1:3128의 예제 address:port 값을 프록시 IP 주소:port의 값으로 바꿉니다.

      HTTP_PROXY=http://10.10.10.1:3128
      HTTPS_PROXY=http://10.10.10.1:3128

    3. Tunnel Gateway 서버 다시 시작: mst-cli server restart 실행

    RHEL은 SELinux를 사용합니다. http_port_t에 대한 SELinux 포트에서 실행되지 않는 프록시에는 추가 구성이 필요할 수 있으므로 http에 대한 SELinux 관리 포트의 사용을 확인합니다. 구성을 보려면 다음 명령을 실행합니다. sudo semanage port -l | grep "http_port_t"

    포트 확인 명령의 결과 예시입니다. 이 예시에서 프록시는 3128을 사용하며 나열되지 않습니다.

    포트 검사 결과를 표시하는 스크린샷

    • 프록시가 http_port_t에 대한 SELinux 포트 중 하나에서 실행되는 경우 Tunnel Gateway 설치 프로세스를 계속할 수 있습니다.

    • 프록시가 이전 예제와 같이 http_port_t 대한 SELinux 포트에서 실행되지 않는 경우 추가 구성을 수행해야 합니다.

      프록시 포트가 http_port_t 대해 나열되지 않은 경우 프록시 포트가 다른 서비스에서 사용되는지 검사. 의미 체계 명령을 사용하여 먼저 프록시에서 사용하는 포트를 검사 다음, 필요한 경우 나중에 변경합니다. 프록시에서 사용하는 포트를 확인하려면 sudo semanage port -l | grep "your proxy port"을(를) 실행합니다.

      포트를 사용할 수 있는 서비스를 확인한 결과의 예시입니다.

      서비스 검사 결과를 표시하는 스크린샷

      • 예제에서 예상 포트(3128)는 OSS 프록시 서비스인 오징어가 사용하고 있습니다. 오징어 프록시 SELinux 정책은 여러 일반적인 배포의 일부입니다. 오징어 포트 3128(예제 포트)을 사용하므로 http_port_t 포트를 수정하고 Tunnel에서 사용하는 프록시에 대해 SELinux를 통해 허용되도록 포트 3128을 추가해야 합니다. 포트 사용을 수정하려면 다음 명령을 실행합니다. sudo semanage port -m -t http_port_t -p tcp "your proxy port"

        포트를 수정하는 명령의 예시입니다.

        포트 수정 명령의 예를 보여 주는 스크린샷.

        명령을 실행하여 포트를 변경한 후 다음 명령을 실행하여 포트가 다른 서비스에서 사용되는지 확인합니다. sudo semanage port -l | grep "your proxy port"

        포트를 수정한 후 포트를 확인하는 명령의 예시입니다.

        수정 후 포트를 확인하는 스크린샷.

        이 예제에서 포트 3128은 이제 http_port-t 및 squid_port_t 모두에 연결됩니다. 이러한 결과가 예상됩니다. sudo semanage port -l | grep "your_proxy_port" 명령을 실행할 때 프록시 포트가 나열되지 않으면 semanage 내의 -m을 -a로 수정하는 경우를 제외하고 명령을 실행하여 포트를 다시 수정합니다.sudo semanage port -a -t http_port_t -p tcp "your proxy port"

프록시를 사용하여 이미지 업데이트를 다운로드하도록 Podman 구성

프록시를 사용하여 Podman에 대해 업데이트된 이미지를 다운로드(끌어오기)하도록 Podman을 구성할 수 있습니다.

  1. 터널 서버에서 명령 프롬프트를 사용하여 다음 명령을 실행하여 Microsoft Tunnel 서비스의 재정의 파일에 대한 편집기를 엽니다.

    systemctl edit --force mstunnel_monitor

  2. 파일에 다음 네 줄을 추가합니다. [주소]의 각 instance 프록시 DN 또는 주소로 바꾼 다음 파일을 저장합니다.

    [Service]
Environment="http_proxy=[address]"
Environment="https_proxy=[address]"

  3. 다음으로 명령 프롬프트에서 다음을 실행합니다.

    systemctl restart mstunnel_monitor

  4. 마지막으로 명령 프롬프트에서 다음을 실행하여 구성이 성공적인지 확인합니다.

    systemctl show mstunnel_monitor | grep http_proxy

    구성에 성공하면 결과는 다음 정보와 유사합니다.

    Environment="http_proxy=address:port"
Environment="https_proxy=address:port"

터널 서버에서 사용 중인 프록시 서버 업데이트

터널 서버의 Linux 호스트에서 사용 중인 프록시 서버 구성을 변경하려면 다음 절차를 따르세요.

  1. 터널 서버에서 /etc/mstunnel/env.sh를 편집하고 새 프록시 서버를 지정합니다.

  2. mst-cli install을(를) 실행합니다.

    이 명령은 새 프록시 서버 세부 정보로 컨테이너를 다시 빌드합니다. 이 프로세스 중에 는 /etc/mstunnel/env.sh 콘텐츠를 확인하고 인증서가 설치되어 있는지 확인해야 합니다. 인증서는 이전 프록시 서버 구성에 이미 있어야 합니다.

    둘 다 확인하고 구성을 완료하려면 예를 입력합니다.

플랫폼

Microsoft Tunnel에서 지원되려면 디바이스를 Intune에 등록해야 합니다. 다음 디바이스 플랫폼만 지원됩니다.

  • iOS/iPadOS

  • Android Enterprise:

    • 완전 관리형
    • 회사 소유 회사 프로필
    • 개인 소유 회사 프로필

    참고

    Android Enterprise 전용 장치는 Microsoft Tunnel에서 지원되지 않습니다.

모든 플랫폼은 다음 기능을 지원합니다.

  • 사용자 이름 및 암호를 사용하여 Tunnel에 인증을 Microsoft Entra.
  • 사용자 이름과 암호를 사용하여 터널에 대한 AD FS(Active Directory Federation Services) 인증.
  • 앱별 지원
  • Tunnel 앱을 통한 수동 전체 디바이스 터널(사용자가 VPN을 시작하고 연결 선택)
  • 분할 터널링. 그러나 iOS의 경우 VPN 프로필이 앱별 VPN을 사용하면 분할 터널링 규칙이 무시됩니다.

프록시에 대한 지원은 다음 플랫폼으로 제한됩니다.

  • Android 10 이상
  • iOS/iPadOS

사용 권한

Microsoft Tunnel을 관리하려면 Intune의 Microsoft Tunnel Gateway 권한 그룹에 포함된 권한이 사용자에게 있어야 합니다. 기본적으로 Intune 관리자 및 Microsoft Entra 관리자에게 이러한 권한이 있습니다. 이러한 권한은 Intune 테넌트에 대해 만든 사용자 지정 역할에 추가할 수도 있습니다.

역할을 구성하는 동안 사용 권한 페이지에서 Microsoft Tunnel Gateway를 확장하고 부여할 권한을 선택합니다.

Microsoft Intune 관리 센터의 터널 게이트웨이 권한 스크린샷

Microsoft Tunnel Gateway 권한 그룹은 다음 권한을 부여합니다.

  • 만들기 - Microsoft Tunnel Gateway ‘서버’ 및 ‘사이트’를 구성합니다. 서버 구성에는 IP 주소 범위, DNS 서버, 포트, 분할 터널링 규칙에 대한 설정이 포함됩니다. 사이트는 Microsoft Tunnel을 지원하는 여러 서버의 논리적 그룹화입니다.

  • 업데이트(수정) - Microsoft Tunnel Gateway 서버 구성 및 사이트를 업데이트합니다. 서버 구성에는 IP 주소 범위, DNS 서버, 포트, 분할 터널링 규칙에 대한 설정이 포함됩니다. 사이트는 Microsoft Tunnel을 지원하는 여러 서버의 논리적 그룹화입니다.

  • 삭제 - Microsoft Tunnel Gateway 서버 구성 및 사이트를 삭제합니다. 서버 구성에는 IP 주소 범위, DNS 서버, 포트, 분할 터널링 규칙에 대한 설정이 포함됩니다. 사이트는 Microsoft Tunnel을 지원하는 여러 서버의 논리적 그룹화입니다.

  • 읽기 - Microsoft Tunnel Gateway 서버 구성 및 사이트를 봅니다. 서버 구성에는 IP 주소 범위, DNS 서버, 포트, 분할 터널링 규칙에 대한 설정이 포함됩니다. 사이트는 Microsoft Tunnel을 지원하는 여러 서버의 논리적 그룹화입니다.

준비 도구 실행

서버 설치를 시작하기 전에 최신 버전의 mst-readiness 도구를 다운로드하고 실행하는 것이 좋습니다. 이 도구는 Linux 서버에서 실행되는 스크립트이며 다음 작업을 수행합니다.

  • Microsoft Tunnel을 설치하는 데 사용하는 Microsoft Entra 계정에 등록을 완료하는 데 필요한 역할이 있는지 확인합니다.

  • 네트워크 구성에서 Microsoft Tunnel이 필요한 Microsoft 엔드포인트에 액세스하도록 허용하는지 확인합니다.

  • Linux 서버에 ip_tables 모듈이 있는지 확인합니다. 이 검사는 RHEL 8.5 지원이 추가된 2022년 2월 11일에 스크립트에 추가되었습니다. RHEL 8.5는 기본적으로 ip_tables 모듈을 로드하지 않습니다. Linux 서버를 설치한 후 누락된 경우 수동으로 ip_tables 모듈을 로드해야 합니다.

중요

준비 도구는 일반적으로 잘못 구성되어 있는 인바운드 포트의 유효성을 검사하지 않습니다. 준비 도구를 실행한 후 방화벽 필수 구성 요소를 검토하고 방화벽에서 인바운드 트래픽을 전달하는지를 수동으로 확인합니다.

mst-readiness 도구는 명령줄 JSON 프로세서인 jq에 대한 종속성을 갖습니다. 준비 도구를 실행하기 전에 jq가 설치되어 있는지 확인합니다. jq를 다운로드하고 설치하는 방법에 대한 자세한 내용은 사용 중인 Linux 버전에 대한 설명서를 참조하세요.

준비 도구를 사용하려면 다음을 수행합니다.

  1. 다음 방법 중 하나를 사용하여 준비 도구의 최신 버전을 가져옵니다.

    • 웹 브라우저를 사용하여 도구를 직접 다운로드합니다. https://aka.ms/microsofttunnelready로 이동하여 mst-readiness라는 파일을 다운로드합니다.

    • Microsoft Intune 관리 센터>테넌트 관리>Microsoft Tunnel Gateway에 로그인하고, 서버 탭을 선택하고, 만들기를 선택하여 서버 만들기 창을 연 다음, 준비 도구 다운로드를 선택합니다.

    • Linux 명령을 사용하여 준비 도구를 직접 받습니다. 예를 들어 wget 또는 curl을 사용하여 https://aka.ms/microsofttunnelready 링크를 열 수 있습니다.

      예를 들어 다운로드 중에 wget을 사용하고 세부 정보를 mst-readiness에 로깅하려면 wget --output-document=mst-readiness https://aka.ms/microsofttunnelready를 실행합니다.

    스크립트는 설치하려는 서버와 동일한 네트워크에 있는 모든 Linux 서버에서 실행할 수 있으므로 네트워크 관리자는 스크립트를 사용하여 네트워크 문제를 독립적으로 해결할 수 있습니다.

  2. 네트워크 및 Linux 구성의 유효성을 검사하려면 다음 명령을 사용하여 스크립트를 실행합니다. 이러한 명령은 스크립트에 대한 실행 권한을 설정하고 Tunnel이 올바른 엔드포인트에 연결할 수 있는지 유효성을 검사한 다음 Tunnel에서 사용하는 유틸리티가 있는지 검사.

    • sudo chmod +x ./mst-readiness

    • sudo ./mst-readiness network - 이 명령은 다음 작업을 실행한 다음 두 가지 모두에 대해 성공 또는 오류를 보고합니다.

      • 터널에서 사용할 각 Microsoft 엔드포인트에 연결을 시도합니다.
      • 필요한 포트가 방화벽에 열려 있는지 확인합니다.

    • sudo ./mst-readiness utils - 이 명령은 Docker 또는 Podman 및 ip_tables 같은 Tunnel에서 사용하는 유틸리티를 사용할 수 있는지 확인합니다.

  3. Microsoft Tunnel을 설치하는 데 사용할 계정에 등록을 완료하는 데 필요한 역할 및 권한이 있는지 확인하려면 다음 명령줄을 사용하여 스크립트를 실행합니다. ./mst-readiness account

    스크립트는 웹 브라우저에서 다른 컴퓨터를 사용하라는 메시지를 표시합니다. 이 컴퓨터는 Microsoft Entra ID 인증하고 Intune 데 사용합니다. 도구는 성공 또는 오류를 보고합니다.

이 도구에 대한 자세한 내용은 Microsoft Tunnel에 대한 참조 문서에서 mst-cli에 대한 참조를 확인하세요.

수동으로 ip_tables 로드

대부분의 Linux 배포는 ip_tables 모듈을 자동으로 로드하지만 일부 배포는 그렇지 않을 수 있습니다. 예를 들어 RHEL 8.5는 기본적으로 ip_tables 로드하지 않습니다.

이 모듈이 있는지 확인하려면 Linux 서버에서 최신 버전의 mst-readiness 도구를 실행합니다. ip_tables 유무 검사는 2022년 2월 11일에 준비 도구 스크립트에 추가되었습니다.

모듈이 없는 경우 도구는 ip_tables 모듈 검사 중지합니다. 이 시나리오에서는 다음 명령을 실행하여 모듈을 수동으로 로드할 수 있습니다.

수동으로 ip_tables 모듈 로드

sudo와 관련하여 Linux 서버에서 다음 명령을 실행합니다.

  1. 서버에 ip_tables(lsmod |grep ip_tables)가 있는지 확인합니다.

  2. ip_tables가 없는 경우 /sbin/modprobe ip_tables를 실행하여 다시 시작하지 않고 즉시 모듈을 커널에 로드합니다.

  3. 유효성 검사를 다시 실행하여 lsmod |grep ip_tables 테이블이 로드되었는지 확인합니다.

중요

Tunnel 서버를 업데이트할 때 수동으로 로드된 ip_tables 모듈이 유지되지 않을 수 있습니다. 이런 경우 업데이트가 완료된 후 모듈을 다시 로드해야 할 수 있습니다. 서버 업데이트가 완료되면 서버에 ip_tables 모듈이 있는지 검토합니다.

테이블이 없는 경우 이전 단계를 따라 모듈을 다시 로드하고 추가 단계로 모듈이 로드된 후 서버를 다시 시작합니다.

부팅 시 ip_tables를 로드하도록 Linux 구성

sudo의 컨텍스트에서 Linux 서버에서 다음 명령을 실행하여 부팅 시간 동안 ip_tables 커널로 로드하는 구성 파일을 만듭니다. echo ip_tables > /etc/modules-load.d/mstunnel_iptables.conf

툰 모듈 수동으로 로드

Microsoft Tunnel에는 툰 모듈이 필요하지만 일부 Linux 배포판은 기본적으로 툰 모듈을 로드하지 않습니다.

서버에서 툰 모듈의 현재 유효성을 검사하려면 다음을 실행합니다. lsmod |grep tun

  1. 툰이 없는 경우 다음을 실행하여 모듈을 다시 시작하지 않고 즉시 커널에 로드합니다./sbin/modprobe tun

  2. 유효성 검사를 다시 실행하여 이제 툰 모듈이 로드되어 있는지 확인합니다. lsmod |grep tun

중요

Tunnel 서버를 업데이트할 때 수동으로 로드된 툰 모듈이 유지되지 않을 수 있습니다. 이렇게 하려면 업데이트가 완료된 후 모듈을 다시 로드해야 할 수 있습니다. 서버 업데이트가 완료되면 서버에서 툰 모듈이 있는지 검토합니다.

없는 경우 이전 단계를 사용하여 모듈을 다시 로드하고 모듈이 로드된 후 서버를 다시 시작하는 추가 단계를 수행합니다.

부팅 시 툰을 로드하도록 Linux 구성

sudo의 컨텍스트에서 Linux 서버에서 다음 명령을 실행하여 부팅 시간 동안 툰 을 커널로 로드하는 구성 파일을 만듭니다. echo tun > /etc/modules-load.d/mstunnel_tun.conf

다음 단계

Microsoft Tunnel 구성