Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

애플리케이션 QoS

AppQoS를 사용하면 특정 애플리케이션에 대한 액세스를 식별하고 제어할 수 있으며, 애플리케이션 계층에서 QoS(서비스 품질)를 적용하기 위한 stateful 방화벽 규칙 기반의 세분성을 제공합니다. 자세한 내용은 다음 항목을 참조하십시오.

AppQoS(Application Quality of Service) 이해

AppQoS(Application 서비스 품질) 기능은 Layer-7 애플리케이션 유형에 기반한 DSCP 값을 마킹하고, 손실 우선 순위 설정을 통해 애플리케이션 기반 트래픽을 보호하며, Layer-7 애플리케이션 유형에 따라 egress PICs에서 전송률을 제어하는 등 CoS(Junos OS 서비스 등급서비스 등급)의 기능을 확장합니다.

보안 장비에 DSCP 값을 마킹하는 방법은 4가지가 있습니다.

  • 침입 탐지 및 방지(IDP) 공격 조치 기반 DSCP 재조정기

  • Layer 7 애플리케이션 기반 DSCP 재라이터

  • ALG 기반 DSCP 재시도자

  • 방화벽 필터기반 DSCP 재라이터

침입 탐지 및 방지(IDP) 리마킹은 규칙에 따라 ingress 포트에서 침입 탐지 및 방지(IDP) 수행됩니다. 애플리케이션 리마킹은 애플리케이션 규칙에 따라 egress 포트에서 수행됩니다. 인터페이스 기반 리마킹은 방화벽 필터 규칙에 따라 egress 포트에서도 발생합니다. (CoS 기능에 대한 자세한 설명은 서비스 사용자 가이드(보안 장비 Junos OS 참조하십시오.)

이들 3개 재시도자들의 의사 결정은 다를 수 있습니다. 패킷이 3개 모두를 트리거하는 경우, 우선 순위를 선점하는 방법은 해당 패킷이 수행되는 패킷 컨텐트 깊이에 따라 결정됩니다. 침입 탐지 및 방지(IDP) 설명은 인터페이스 기반 리마킹보다 우선되는 애플리케이션 리마킹보다 우선합니다.

패킷이 AppQoS 및 ALG 기반 DSCP 재리터 모두를 트리거하는 경우 AppQoS가 ALG 기반 DSCP 재조정기보다 우선적으로 실행됩니다.

AppQoS DSCP 재라이터는 서비스 품질 우선 순위를 통해 패킷의 패킷 패킷 전송을 전달합니다. AppQoS 속도 제한 매개변수는 관련 큐에 대한 전송 속도와 볼륨을 제어합니다.

애플리케이션 QoS의 이점

AppQoS는 애플리케이션 트래픽에 우선 순위를 지정하고 측정하여 우선 순위가 높은 애플리케이션 트래픽에 더 나은 비즈니스 크리티컬 기능을 제공합니다.

고유의 포링 클래스 및 큐 할당

포링 클래스는 다음 세 가지 기능을 제공합니다.

  • 같은 특성을 가지는 그룹 패킷

  • 출력 큐 할당

  • 기존 방화벽 필터 기반 Junos OS 대한 충돌 해결

고유의 포워드 클래스 이름을 통해 AppQoS 레마킹이 인터페이스 기반 재선정 규칙에 의해 덮어링되는 것을 방지합니다. 패킷의 포우링 클래스가 이 재라이터를 위해 특별히 정의된 클래스와 일치하는 경우 방화벽 필터 기반 재라이터가 패킷의 DSCP 값을 재마킹합니다. 패킷의 포링 클래스가 방화벽 필터 기반 재라이터 클래스와 일치하지 않는 경우 DSCP 값을 리마킹하지 않습니다. 따라서 AppQoS 값이 덮어링되지 못하게 보호하기 위해 방화벽 필터 기반 재조정기에 알려지지 않은 포워더 클래스 이름을 사용합니다.

각 포우링 클래스는 적절한 수준의 향상된 또는 표준 프로세싱을 제공하는 egress 큐에 할당됩니다. 많은 포링 클래스를 단일 큐에 할당할 수 있습니다. 따라서 디바이스에 대해 정의된 큐는 침입 탐지 및 방지(IDP), AppQoS 및 방화벽 필터 기반 재리리터를 사용할 수 있습니다. 이는 전송 우선 순위를 구분하는 큐가 아닌 포링 클래스 이름입니다. (대기열 및 스케줄러 구성에 대한 정보는 서비스 등급 사용자 가이드(보안 디바이스)를 참조하십시오.)

디바이스SRX5400, SRX5600 및 SRX5800 디바이스의 경우, AppQoS 포우링 클래스 이름 및 큐 할당은 CLI class-of-service 구성 명령으로 정의됩니다.

SRX300, SRX320, SRX340, SRX345, SRX380, SRX550M, SRX1500, SRX4100, SRX4200 및 SRX4600 디바이스 및 vSRX 인스턴스의 경우 AppQoS 포우링 클래스 이름과 큐 할당은 CLI 구성 명령으로 class-of-service 정의됩니다.

애플리케이션 인식 DSCP 코드-포인트 및 손실 우선 순위 설정

AppQoS의 경우 정의된 포우링 클래스와 선택한 애플리케이션을 연관하는 규칙을 기반으로 트래픽을 그룹화합니다. 규칙에 대한 일치 기준에는 하나 이상의 애플리케이션이 포함됩니다. 일치하는 애플리케이션의 트래픽이 규칙에 발생하면 규칙 조치는 포링 클래스를 설정하고 DSCP 값 및 손실 우선 순위를 애플리케이션에 적합한 값으로 나타냅니다.

DSCP(Differentiated Services) 코드 지점(DSCP) 값은 6비트 비트맵 값 또는 사용자 정의 또는 기본 별칭에 의해 규칙에 지정됩니다. 표 1에는 기본 DSCP Junos OS 및 비트맵 값의 목록을 제공합니다.

표 1: 표준 CoS Aliases 및 Bit Values

별칭

비트 가치

Ef

101110

af11

001010

af12

001100

af13

001110

af21

010010

af22

010100

af23

010110

af31

011010

af32

011100

af33

011110

af41

100010

af42

100100

af43

100110

수치화할 수

000000

cs1

001000

cs2

010000

cs3

011000

cs4

100000

Cs5

101000

nc1/cs6

110000

nc2/cs7

111000

자세한 내용은 Default CoS Values 및 Aliases를 참조합니다.

큐의 스케줄러는 손실 우선 순위를 사용하여 특정 손실 우선 순위 값에 프로파일 드롭을 연결하여 혼잡 기간 동안 패킷 폐기를 제어합니다. (대기열 및 스케줄러 구성에 대한 정보는 서비스 등급 사용자 가이드(보안 디바이스)를 참조하십시오.)

이 규칙은 트래픽 그룹에 손실 우선 순위를 적용합니다. 손실 우선 순위가 높다는 것은 혼잡 기간 동안 패킷이 떨어질 가능성이 높은 것입니다. 손실 우선 순위에는 4개가 있습니다.

  • high

  • medium-high

  • medium-low

  • low

규칙 세트는 구성 명령에 class-of-service application-traffic-control 정의됩니다.

속도 제한 설정(Rate Limiters) 및 프로파일

혼잡이 발생하면 AppQoS는 장비의 모든 egress PICs에 속도 제한을 구현합니다. 패킷이 할당된 제한을 초과하면 드롭됩니다. 속도 제한기(rate limiters)는 여러 트래픽 클래스에 대해 일관된 수준의 처리량과 패킷 손실 민감도를 유지합니다. 모든 egress PIC는 동일한 속도 제한 체계를 사용합니다.

PIC의 총 대역폭은 약 10Gbps입니다. PIC에 대한 속도 제한 하드웨어는 최대 2Gbps를 프로비저닝할 수 있습니다. 따라서 속도 제한에 대한 상한 대역폭 제한은 231bps입니다.

속도 제한 프로파일은 한계를 정의합니다. 이는 다양한 사양을 bandwidth-limit burst-size-limit 결합한 독보적인 제품입니다. 포트를 통해 전달할 수 있는 초당 최대 킬로비트 수를 bandwidth-limit 정의합니다. 단일 버스트에서 포트를 통해 전달할 수 있는 최대 bytes 수를 burst-size-limit 정의합니다. 각 버스트에 대한 제한 크기를 보장함으로써 우선 순위가 낮은 트래픽의 burst-size-limit 기하급수적 감소

AppQoS를 사용하면 디바이스당 최대 16개 프로필과 최대 1000개 속도 제한 기능을 사용할 수 있습니다. 여러 속도 제한기에서 동일한 프로파일을 사용할 수 있습니다. 다음 예제에서는 5개의 속도 제한선이 2개의 프로파일을 사용하여 정의됩니다.

Rate Limiter 이름

프로필

대역폭 제한

버스트 크기 제한

Limiter-1

200

26000

Limiter-2

200

26000

Limiter-3

200

26000

Limiter-4

400

52000

Limiter-5

400

52000

속도 제한은 구성 명령으로 class-of-service application-traffic-control 정의됩니다.

Rate-Limiter 할당

속도 제한은 트래픽 애플리케이션에 따라 규칙에 적용됩니다. 각 세션에 대해 2개의 속도 제한 설정(rate limiters)이 client-to-server server-to-client 적용됩니다. 이를 통해 각 방향의 트래픽을 별도로 프로비저닝할 수 있습니다.

속도 제한기(rate limiters)에 따라 트래픽 대역폭의 처리는 트래픽 방향에 관계없이 패킷 수준에서 수행됩니다. 예를 들어, 10G의 속도 제한어(rate limiter)만 구성된 경우, ingress 및 egress 트래픽이 동일한 라인 카드에서 나타났을 경우,(ingress and egress directions를 결합한 최대 트래픽)은 20G가 아닌 최대 10G에 불과합니다. 그러나 디바이스가 IOC를 지원하고(SRX5000 라인 디바이스 및 SRX4600 디바이스의 경우) 및 ingress 트래픽이 다른 IOC를 통해 하나의 IOC 및 egress 트래픽을 통과하는 경우, 10G의 단일 속도 제한기(rate-limiter)를 구성하면 20G의 스루루(throughput)를 기대할 수 있습니다.

동일한 규칙 세트 내에 있는 서로 다른 AppQoS 규칙이 속도 제한(rate limiter)을 공유할 수 있습니다. 이 경우 해당 규칙의 애플리케이션이 동일한 대역폭을 공유합니다. 동일한 속도 제한어를 할당할 수 있는 한 규칙 세트에 규칙 수에는 제한이 없습니다.

다음 예제는 앞 섹션에 정의된 속도 제한어를 할당할 수 있는 방법을 보여주고 있습니다. 예를 들어, 규칙 세트는 여러 규칙과 한 또는 두 플로우 방향에서 속도 제한기(rate limiter)를 재사용할 수 있습니다.

  • 규칙 설정-1

    • 규칙-1A

      • 클라이언트-서버 리미터-1

      • 서버 대 클라이언트 리미터(limiter-1)

    • 규칙-1B

      • 클라이언트-서버 리미터-1

      • 서버 대 클라이언트 리미터(limiter-1)

여러 규칙 집합에서 동일한 프로파일이 필요한 경우, 충분한 수의 속도 제한기(rate limiters)를 동일 및 를 지정해 정의해야 bandwidth-limit burst-size-limit 합니다. 다음 예제의 두 규칙 세트는 동일하지만 비교 가능한 속도 제한기(rate limiters)를 할당하여 동일한 프로필을 구현합니다.

  • 규칙-2

    • 규칙-2A

      • 클라이언트-서버 리미터-2

      • 서버 대 클라이언트 리미터-2

    • 규칙-2B

      • 클라이언트-서버 리미터-2

      • 서버 대 클라이언트 리미터-4

  • 규칙-3

    • 규칙-3A

      • 클라이언트-서버 리미터-3

      • 서버 대 클라이언트 리미터-3

    • 규칙-3B

      • 클라이언트-서버 리미터-3

      • 서버-클라이언트 리미터-5

속도 제한기(rate limiter)는 포링 클래스, DSCP 값 및 손실 우선 순위가 설정된 동일한 방식으로 명령을 edit class-of-service application-traffic-control rule-sets 사용하여 적용됩니다.

AppQoS 및 방화벽 필터 기반 속도 제한이 모두 egress PIC에 구현된 경우 두 가지 모두를 고려합니다. AppQoS 속도 제한이 먼저 고려됩니다. 방화벽 필터 기반 속도 제한은 그 이후에 발생합니다.

참고:

패킷이 PIC에서 드롭된 경우 디바이스는 클라이언트 또는 서버로 알림을 전송하지 않습니다. 클라이언트와 서버 장치의 상위 수준 애플리케이션은 재전신과 오류 처리를 담당합니다.

속도 제한 조치

보안 장비의 유형에 따라 AppQoS 규칙을 서로 다른 속도 제한 장치 작업으로 구성할 수 있습니다.

  • 삭제

    • 이 옵션이 선택되면 프로필을 떨어뜨리는 패킷은 방금 삭제됩니다.

    • 이는 기본 작업 유형으로 구성할 필요가 없습니다.

    • 이 옵션은 모든 SRX 시리즈 디바이스에서 지원됩니다.

  • 손실 우선 순위가 높음

    • 이 옵션을 선택하면 손실 우선 순위를 최대로 상승합니다. 즉, 지연된 드롭입니다. 폐기 결정은 egress 출력 큐 수준에서 결정됩니다. 정체가 없는 경우, 최대 손실 우선 순위가 있는 트래픽도 허용합니다. 그러나 혼잡이 발생하면 이러한 최대 손실 우선 순위 패킷이 먼저 드롭됩니다.

    • 이 옵션은 다음 명령을 사용하여 AppQoS 규칙 내에서 구성해야 합니다(기본 작업의 까다로워지기).

    • 이 옵션은 디바이스, SRX300, SRX320, SRX345 디바이스에서만 지원됩니다.

AppQoS 보안 정책 구성

AppQoS 규칙 집합은 기존 정책 또는 특정 애플리케이션 정책에서 구현할 수 있습니다.

예: 애플리케이션 서비스 품질 구성

이 예에서는 정책 내에서 AppQoS 우선 순위 지정 및 속도 제한을 활성화하는 방법을 보여줍니다.

요구 사항

이 기능을 구성하기 전에 장비 초기화 이외에는 특별한 구성이 필요하지 않습니다.

개요

이 예에서는 AppQoS가 구현되어 FTP 애플리케이션이 지정된 수준 이하로 제한되는 반면, 다른 애플리케이션은 보다 일반적인 속도 및 손실 우선 순위 수준에서 전송됩니다.

구성

절차

이 예제를 신속하게 구성하려면 다음 명령을 복사하여 텍스트 파일에 붙여넣기하고, 라인 끊기를 제거하고, 네트워크 구성과 일치하는 데 필요한 세부 정보를 변경한 다음, [편집] 계층 수준에서 명령을 복제하여 CLI 입력합니다.

단계별 절차

보안 디바이스에서 AppQoS를 구성하려면

  1. AppQoS 마킹 전용 포링 클래스를 하나 이상 정의합니다. 이 예에서는 단일 포우링 클래스인 my-app-fc가 정의되어 큐 4에 할당됩니다.

    디바이스 SRX5400, SRX5600 SRX5800 명령을 set class-of-service forwarding-classes class my-app-fc queue 4 사용하여

    주니퍼 네트웍스 디바이스는 8개의 대기열(0-7)을 지원합니다. 기본 큐 0 ~3은 기본 포우링 클래스에 할당됩니다. 4~7 큐는 FC에 대한 기본 할당이 아니며 매핑되지 않습니다. 4~7 큐를 사용하려면 사용자 지정 파이버 채널(FC) 이름을 생성하고 큐에 매핑해야 합니다. 자세한 내용은 포링 클래스 개요 를 참조하십시오.

  2. 속도 제한기(rate limiters)를 정의합니다. 이 예에서는 2개의 속도 제한 설정(rate limiters)이 정의되어 있습니다.

    SRX5400, SRX5600 및 SRX5800 디바이스의 경우 장치에 대해 최대 1000개 속도 제한 기능을 정의할 수 있지만 단 16개 프로필만 정의할 수 있습니다(고유한 대역폭 제한 및 버스트 크기 제한 조합).

  3. AppQos 규칙 및 애플리케이션 일치 기준을 정의합니다.

    이 예에서 일치하는 패킷에는 포링 클래스 my-app-fc, af22의 DSCP 값, 낮은 손실 우선 순위로 표시됩니다. 양방향 모두에서 동일한 속도 제한 설정(rate limiter)을 지정했습니다.

    단일 규칙으로 하나 또는 두 트래픽 방향에 속도 제한자를 할당할 수 있습니다. 또한 규칙 세트 내의 다른 규칙에 동일한 속도 제한어를 할당할 수도 있습니다. 그러나 서로 다른 규칙 세트에 동일한 속도 제한어를 할당할 수는 없습니다.

  4. 이전 규칙과 일치하지 않는 애플리케이션 패킷을 처리하는 또 다른 규칙을 정의합니다. 이 예에서는 두 번째 및 최종 규칙이 나머지 모든 애플리케이션에 적용됩니다.

  5. 보안 정책에 AppQoS 설정을 추가합니다.

결과

구성 모드에서 and command를 입력하여 정책 show security policies 구성을 show class-of-service 확인 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 지침을 반복하여 구성을 수정합니다.

이 명령 출력에는 이 예제와 관련된 구성만 show 포함됩니다. 시스템의 다른 구성은 타원(...)로 대체되었습니다.

디바이스 구성이 완료되면 commit 구성 모드에서 입력합니다.

확인

구성이 제대로 작동하고 있는지 확인합니다.

플로우 세션 구성 검증

목적

AppQoS가 활성화되어 있는지 확인

작업

작동 모드에서 명령어를 show security flow session application-traffic-control extensive 입력합니다.

의미

애플리케이션 트래픽 제어의 엔트리는 현재 세션의 규칙 세트 및 규칙을 식별합니다.

세션 통계 검증

목적

AppQoS 세션 통계가 각 Egress 노드에서 누적되고 있는지 검증합니다.

작업

작동 모드에서 명령어를 show class-of-service application-traffic-control counter 입력합니다.

의미

AppQoS 통계는 애플리케이션 트래픽 제어 서비스를 활성화한 경우만 유지 관리됩니다. 처리, 표시 및 존중되는 세션의 수는 구성된 AppQoS 기능을 기반으로 세션이 지정되고 있는지를 보여준 것입니다. 속도 제한 통계는 속도 제한을 이행하는 방향 세션 플로우의 수를 계산합니다.

속도 제한기 통계 검증

목적

FTP 애플리케이션에 문제가 발생하면 대역폭이 예상대로 제한되는지 확인

작업

작동 모드에서 명령어를 show class-of-service application-traffic-control statistics rate-limiter 입력합니다.

의미

각 PIC에 대한 실시간 애플리케이션 대역폭 제한 정보는 규칙 세트에 따라 표시됩니다. 이 명령은 속도 제한되는 애플리케이션과 적용 프로파일을 표시해 제공합니다.

규칙 통계 검증

목적

규칙이 규칙 통계와 일치하는지 확인

작업

작동 모드에서 명령어를 show class-of-service application-traffic-control statistics rule 입력합니다.

의미

이 명령은 각 규칙 세트에 있는 규칙에 대한 (세션) 히트 수에 대한 정보를 제공합니다.

통합된 정책에 대한 애플리케이션 서비스 품질 지원

릴리스 Junos OS 릴리스부터 18.2R1 및 vSRX 인스턴스는 통합 정책을 지원하기 때문에 기존 보안 정책 내에서 동적 Layer 7 애플리케이션을 세부적으로 제어하고 적용할 수 있습니다.

통합 정책은 기존 5-tuple 또는 6-tuple(사용자 방화벽과 함께 5-tuple) 조건의 일부로 동적 애플리케이션을 사용할 수 있도록 하여 시간이 경과에 따라 애플리케이션 변경을 탐지할 수 있는 보안 정책입니다.

보안 서비스 품질 구성 시 AppQoS(Application 서비스 품질)가 지원됩니다. 여러 보안 정책이 트래픽과 일치하는 경우 통합 정책 충돌을 관리하도록 기본 AppQoS 규칙을 구성할 수 있습니다.

AppQoS 규칙 집합은 애플리케이션 인식 서비스 품질 제어를 구현하기 위해 통합 정책에 포함되어 있습니다. 옵션에 있는 규칙으로 규칙 집합을 구성하고 AppQoS 규칙 세트를 애플리케이션 서비스로 통합 보안 정책에 연결할 application-traffic-control 수 있습니다. 트래픽이 지정된 동적 애플리케이션과 일치하고 정책 조치가 허용되는 경우 애플리케이션 인식 서비스 품질 적용됩니다.

통합 정책의 다음 AppQoS 기능을 참고하십시오.

  • 기존 보안 정책에서 통합 정책으로 업그레이드 —통합 정책에서 으로 옵션을 구성하면 보안 정책과 일치되는 동안 AppQoS 규칙 집합이 적용되고 dynamic-application AppQoS는 식별된 트래픽에 대한 해당 규칙을 none 검색합니다. 이는 릴리스 릴리스 이전의 Junos OS AppQoS 기능과 18.2R1.

  • 통합 정책과 함께 AppQoS 규칙—애플리케이션 트래픽 제어 구성에서 AppQoS 규칙 세트는 통합 정책의 일치 조건과 일치 조건으로 구성되면 특정 동적 애플리케이션이 일치 조건으로 사용되면 AppQoS 기능은 통합 정책의 규칙에 따라 application-any 작동합니다.

통합 정책에 대한 기본 애플리케이션의 서비스 품질 규칙 이해

보안 정책 충돌을 관리하도록 AppQoS 기본 규칙을 구성할 수 있습니다.

초기 정책 룩업 단계는 동적 애플리케이션을 식별하기 전에 발생합니다. 서로 다른 AppQoS 규칙 집합을 포함하는 여러 정책이 잠재 정책 목록에 있는 경우, 보안 디바이스는 보다 명시적인 일치가 발생할 때까지 기본 AppQoS 규칙 집합을 적용합니다.

AppQoS를 계층 수준에서 설정된 기본 AppQoS 규칙으로 edit security ngfw 설정할 수 있습니다. 기본 AppQoS 규칙 집합은 계층 수준으로 구성된 기존 AppQoS 규칙 세트 중 하나에서 [edit class-of-service application-traffic-control] 활용됩니다.

표 2에는 통합 정책의 여러 시나리오에 따라 설정된 기본 AppQoS 규칙의 사용이 요약되어 있습니다.

표 2: 통합 정책에서 AppQoS 규칙 설정 사용

애플리케이션 식별 상태

AppQoS 규칙 설정 사용

작업

보안 정책이 충돌하지 않습니다.

[ ] 계층에 설정된 AppQoS 규칙은 트래픽이 보안 정책과 일치하면 edit class-of-service application-traffic-control 적용됩니다.

AppQoS는 AppQoS 규칙 세트에 적용됩니다.

보안 정책 충돌과 충돌하는 정책에는 서로 다른 AppQoS 규칙 집합이 있습니다.

기본 AppQoS 규칙 집합이 구성되지 않은 경우 또는 찾지 못합니다.

기본 AppQoS 프로필이 구성되지 않은 경우 세션이 무시됩니다.

따라서, 정책 충돌 시나리오의 최종 일치 정책이 AppQoS 규칙 집합인 경우에도 이 규칙 집합은 적용되지 않습니다. 보안 정책 충돌을 관리하기 위해 기본 AppQoS 규칙을 구성하는 것이 좋습니다.

기본 AppQoS 규칙 집합이 구성됩니다.

AppQoS는 기본 AppQoS 규칙 세트에 적용됩니다.

최종 애플리케이션이 식별됩니다.

일치하는 보안 정책에는 기본 AppQoS 규칙 세트와 동일한 AppQoS 규칙 세트가 있습니다.

AppQoS는 기본 AppQoS 규칙 세트에 적용됩니다.

일치하는 보안 정책은 AppQoS 규칙 집합이 없습니다.

기본 AppQoS 규칙 세트가 적용되지 않습니다. AppQoS는 해당 세션에 적용되지 않습니다.

매칭 보안 정책에는 이미 적용된 기본 AppQoS 규칙 세트와 다른 AppQoS 규칙이 있습니다.

기본 AppQoS 규칙 집합은 기본 AppQoS 규칙 집합으로 유지됩니다.

기본 AppQoS 규칙 집합이 트래픽에 적용되고 최종 보안 정책에 다른 AppQoS 규칙 세트가 있는 경우, 기본 AppQoS 규칙 세트를 AppQoS 규칙 세트에서 최종 보안 정책에서 설정된 AppQoS 규칙으로 스위칭하는 것은 지원되지 않습니다.

다양한 시나리오에서 설정된 기본 애플리케이션 서비스 품질 규칙

다음 링크는 다양한 시나리오에서 기본 AppQoS 규칙 집합을 설명하는 예제입니다.

표 3에는 동적 애플리케이션을 사용하는 통합 정책에 대해 구성된 서로 다른 AppQoS 규칙 세트가 일치 조건으로 표시되어 있습니다.

표 3: 통합 정책의 서로 다른 AppQoS 규칙 집합

보안 정책

소스 존

소스 IP 주소

대상 존

대상 IP 주소

포트 번호

프로토콜

동적 애플리케이션

서비스

AppQoS 규칙 세트

정책-P1

S1

50.1.1.1

D1

모든

모든

모든

페이스 북

AppQoS

AppQoS-1

정책-P2

S1

50.1.1.1

D1

모든

모든

모든

Google

AppQoS

AppQoS-2

정책-P3

S1

50.1.1.1

D1

모든

모든

모든

Youtube

AppQoS

AppQoS-3

이 예에서는 모든 AppQoS 규칙 세트(AppQoS-1, AppQoS-2, AppQoS-3)를 계층 수준에서 설정된 기본 AppQoS 규칙으로 구성할 수 [security ngfw] 있습니다. 보안 정책 구성의 일부로 설정된 기본 규칙이 필요하지 않습니다. 계층 수준에 설정된 모든 AppQoS 규칙을 기본 AppQoS 규칙 집합으로 [edit class-of-service application-traffic-control] 할당할 수 있습니다.

정책 충돌 없음—모든 정책에 동일한 AppQoS 규칙 세트가 있습니다.

모든 매칭 정책은 표 4와 동일한 AppQoS 규칙 집합을 가고 있습니다.

표 4: 모든 매칭 정책에 동일한 AppQoS 규칙 세트가 있습니다.

보안 정책

소스 존

소스 IP 주소

대상 존

대상 IP 주소

포트 번호

프로토콜

동적 애플리케이션

서비스

AppQoS 규칙 세트

정책-P1

S1

모든

D1

모든

모든

모든

페이스 북

AppQoS

AppQoS-1

정책-P2

S1

모든

D1

모든

모든

모든

Google

AppQoS

AppQoS-1

이 시나리오에서는 정책-P1 및 Policy-P2에 동일한 AppQoS 규칙 집합이 있습니다. AppQoS-1입니다. AppQoS-1 규칙 세트가 적용됩니다. 이 시나리오에서는 Policy-P3가 구성되지 않습니다.

AppQoS-2 규칙을 기본 규칙 집합으로 구성한 경우 해당 규칙은 적용되지 않습니다. 그 이유는 상충된 정책(Policy-P1 및 Policy-P2)에서 AppQoS 규칙 집합이 충돌하지 못하기 때문이다.

정책 충돌 없음—모든 정책은 동일한 AppQoS 규칙 집합을 사용하며 최종 정책에는 AppQoS 규칙 집합이 없습니다.

모든 매칭 정책은 표 5와 동일한 AppQoS 규칙 집합을 사용하며, 최종 정책에는 AppQoS 규칙 집합이 없습니다.

표 5: 모든 일치 정책은 동일한 AppQoS 규칙 집합을 가지며 최종 정책에는 AppQoS 규칙 집합이 없습니다.

보안 정책

소스 존

소스 IP 주소

대상 존

대상 IP 주소

포트 번호

프로토콜

동적 애플리케이션

서비스

AppQoS 규칙 세트

정책-P1

S1

모든

D1

모든

모든

모든

페이스 북

AppQoS

AppQoS-1

정책-P2

S1

모든

D1

모든

모든

모든

Google

AppQoS

AppQoS-1

정책-P3

S1

50.1.1.1

D1

모든

모든

모든

Youtube

다른

없음

이 시나리오에서는 Policy-P1과 Policy-P2 모두 동일한 AppQoS 규칙 집합이 있습니다. 즉, AppQoS-1입니다. 이 경우 AppQoS-1 규칙 세트가 적용됩니다.

최종 정책 정책-P3이 일치하면 AppQoS 규칙 집합이 Policy-P3에 대해 구성되지 않습니다.

최종 보안 정책에 AppQoS 규칙 세트가 없는 경우, AppQoS는 트래픽에 적용되지 않습니다. 사전 단계에 적용된 모든 AppQoS 설정은 원래 값으로 변경됩니다.

정책 충돌—최종 정책에 대해 AppQoS 규칙 세트가 구성되지 않습니다.

기본 AppQoS 규칙 세트(이 시나리오에서는 AppQoS-1)가 표 6과같이 잠재적 정책과 일치하는 동안 적용됩니다. 최종 정책 정책-P3에는 AppQoS 규칙 세트가 없습니다.

표 6: 서로 다른 AppQoS 규칙 세트가 있으며, 최종 정책에는 AppQoS 규칙 세트가 없습니다.

보안 정책

소스 존

소스 IP 주소

대상 존

대상 IP 주소

포트 번호

프로토콜

동적 애플리케이션

서비스

AppQoS 규칙 세트

정책-P1

S1

50.1.1.1

D1

모든

모든

모든

페이스 북

AppQoS

AppQoS-1

정책-P2

S1

50.1.1.1

D1

모든

모든

모든

Google

AppQoS

AppQoS-2

정책-P3

S1

50.1.1.1

D1

모든

모든

모든

Youtube

다른

NA

AppQoS는 최종 일치 정책 정책-P3이 적용될 경우 세션을 무시합니다.

최종 보안 정책에 AppQoS 규칙 세트가 없는 경우, AppQoS는 트래픽에 적용되지 않습니다. 이 경우, 예비 단계에 적용된 모든 AppQoS 설정은 원래 값으로 변경됩니다.

정책 충돌—기본 AppQoS 규칙 세트 및 최종 정책에 대한 다른 AppQoS 규칙 세트

AppQoS-1 규칙 세트는 기본 규칙 세트로 구성되고 최종 애플리케이션이 아직 식별되지 않을 때 적용됩니다. 최종 정책 정책-P3에는 표 7과같이 서로 다른 AppQoS 규칙 세트(AppQoS-3)가 있습니다.

표 7: 최종 정책에 대한 서로 다른 AppQoS 규칙 세트

보안 정책

소스 존

소스 IP 주소

대상 존

대상 IP 주소

포트 번호

프로토콜

동적 애플리케이션

서비스

AppQoS 규칙 세트

정책-P1

S1

50.1.1.1

D1

모든

모든

모든

페이스 북

AppQoS

AppQoS-1

정책-P2

S1

50.1.1.1

D1

모든

모든

모든

Google

AppQoS

AppQoS-2

정책-P3

S1

50.1.1.1

D1

모든

모든

모든

Youtube

AppQoS

AppQoS-3

최종 애플리케이션이 확인되면 정책-P3을 일치하고 적용합니다. 이 경우 AppQoS-3 규칙 집합은 적용되지 않습니다. 대신, AppQoS-1은 기본 규칙 세트로 적용되고 기본 규칙 세트로 유지됩니다.

통합 정책으로 AppQoS의 제한

보안 정책이 매칭 트래픽에 적용될 때 AppQoS 규칙 집합은 허용된 트래픽에 적용됩니다. 보안 정책과 적용된 AppQoS 규칙 세트에 서로 다른 동적 애플리케이션이 있는 경우, 다음 예제와 같이 충돌이 발생할 수 있습니다.

이 예제에서 애플리케이션 트래픽 제어 규칙은 junos:GOOGLE에 대해 구성됩니다. 동적 애플리케이션에 대한 보안 정책 일치 조건은 junos: FTP입니다. 이러한 경우 최종 정책이 적용될 때 충돌이 발생할 수 있습니다.

예: 통합 정책으로 애플리케이션 서비스 품질 구성

이 예에서는 통합 정책 내에서 AppQoS(Application 서비스 품질)를 활성화하여 트래픽에 대한 우선 순위 지정 및 속도 제한을 제공하는 방법을 보여줍니다.

요구 사항

이 예에서는 다음과 같은 하드웨어 및 소프트웨어 구성 요소를 활용합니다.

  • SRX 시리즈 디바이스는 Junos OS 이상에서 18.2R1 디바이스를 제공합니다. 이 구성 예는 Junos OS Release 18.2R1.

이 기능을 구성하기 전에 장비 초기화 이외에는 특별한 구성이 필요하지 않습니다.

개요

이 예에서는 AppQoS 규칙 세트를 구성하고 Facebook 애플리케이션에 대한 보안 정책에서 AppQoS를 애플리케이션 서비스로 호출합니다.

[ ] 계층 수준에 설정된 기본 AppQoS 규칙을 정의하여 보안 정책 충돌을 edit security ngfw 관리합니다.

구성

절차

단계별 절차

통합 정책으로 AppQoS를 구성하는 경우:

  1. AppQoS 규칙 집합을 정의합니다.

  2. 기본 AppQoS 규칙 집합을 구성합니다. 애플리케이션 트래픽 제어 하에서 생성된 규칙 세트를 RS1 기본 AppQoS 규칙 집합으로 선택합니다.

  3. 서비스 등급 규칙을 통합 정책에 연결합니다.

결과

구성 모드에서 명령을 입력하여 정책 구성을 show security policies 확인 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 지침을 반복하여 구성을 수정합니다.

이 명령 출력에는 이 예제와 관련이 있는 구성만 show 포함됩니다. 시스템의 다른 구성은 타원(...)로 대체되었습니다.

디바이스 구성이 완료되면 commit 구성 모드에서 입력합니다.

확인

구성이 제대로 작동하고 있는지 확인합니다.

플로우 세션 구성 검증

목적

AppQoS 세션 통계를 표시합니다.

작업

작동 모드에서 명령어를 show class-of-service application-traffic-control counter 입력합니다.

샘플 출력
명령 이름
의미

출력은 처리, 표시 및 처리된 세션의 수를 표시합니다. 속도 제한 통계는 속도 제한을 이행하는 방향 세션 플로우의 수를 계산합니다.

규칙 통계 검증

목적

AppQoS 규칙 통계를 표시합니다.

작업

작동 모드에서 명령어를 show class-of-service application-traffic-control statistics rule 입력합니다.

의미

출력은 각 AppQoS 규칙 세트에 있는 규칙에 따라 일치되는 세션 수에 대한 정보를 제공합니다.