준비 오류 및 경고 정정

준비 상태 오류 및 경고는 준비 상태 검사를 성공적으로 완료하는 데 방해가 될 수 있습니다. 이 주제에서는 여러 유형의 오류 및 경고 정정에 대한 정보를 제공합니다.

오류 로그에서 자세한 정보 보기

자세한 오류 메시지를 보려면 SSH로 Ubuntu 호스트에 연결하고 tail 또는 less 를 사용하여 /home/vSRX/precheck.log 파일을 살펴보세요.

root@vsrx:~# tail -f /home/vSRX/precheck.log
br1.         8000.f6fb18672503  no       bond1
virbr0       8000.5254009fc6e7  yes
[2025-08-11 11:10:27.909405] The remote node control link is down
[2025-08-11 11:10:27.909501] Error: the control link of other node is down
=========================
Host: vsrx FAILURE - Return code:1126

연결 오류에 대한 세부 정보 확인

연결 오류에 대해 제공되는 정보가 충분하지 않은 경우, vSRX Ubuntu 하이퍼바이저에서 생성되는 상세 진단 출력을 검토할 수 있습니다. 해당 precheck.log 파일은 준비 상태 검증 점검에 대한 상세한 진단 정보를 제공합니다. 이 정보를 검토하여 연결 오류를 추가로 분석하고 추가 구성 변경이 필요한지 판단하십시오.

  1. 준비 상태 확인 오류 메시지에 언급된 Ubuntu 하이퍼바이저에 로그인하십시오. 준비 상태 확인 작업 중 오류 세부 정보에 하이퍼바이저 이름이 표시됩니다.
  2. vSRX 디렉터리로 이동하세요.
    cd /home/vSRX
    
  3. 준비 상태 확인 로그 파일을 검토하십시오 precheck.log.
    tail -f precheck.log
    

연결 오류 정정

준비 상태 확인을 수행할 때 다음 두 가지 범주의 연결 오류가 발생할 수 있습니다:

  • 호스트(Ubuntu) SSH 연결 오류
  • 게이트웨이(vSRX) SSH 연결 오류

이러한 오류의 대부분은 호스트 OS( Ubuntu ) 또는 vSRX 게이트웨이의 비공개 IP 주소에 대한 루트 SSH 액세스 권한이 필요하기 때문에 발생합니다. SSH 연결 확인에 실패하면 조치를 진행할 수 없습니다.

SSH 세션 설정에 대한 자세한 내용은 ‘SSH를 사용하여 장치에 액세스하기’를 참조하십시오. 3단계에서 제공되는 예제는 admin 사용자를 대상으로 한다는 점에 유의하세요. 준비 확인의 경우 vSRX 및 하드웨어(호스트)의 root 사용자를 대체하십시오. 또한 이 프로시저에 공인 IP가 아닌 사설 IP를 사용해야 합니다.

연결 상태를 확인하려면, Gateway Appliance 상세 정보 페이지의 하드웨어 섹션( Ubuntu 호스트의 경우) 또는 vSRX 섹션(게이트웨이의 경우)에 나열된 루트 자격 증명을 사용하여 Ubuntu 호스트나 vSRX's 의 사설 IP 중 하나에 SSH 세션을 연결하십시오. SSH 세션을 설정할 수 있는지 확인하십시오.

세션을 설정할 수 없는 경우 다음 잠재적 문제를 확인하십시오.

호스트(Ubuntu) SSH 연결 오류의 경우:

  • Ubuntu 방화벽이 사설 IP에 대한 SSH 액세스를 차단합니까? 방화벽 규칙은 사설 10.0.0.0/8 서브넷에 대한 SSH 액세스를 허용해야 합니다. 서비스 네트워크에 대한 자세한 정보는 IBM Cloud IP 범위를 참조하십시오.
  • 게이트웨이 어플라이언스 세부사항 페이지에 나열된 루트 비밀번호가 루트 사용자의 올바른 비밀번호입니까? 그렇지 않은 경우 하드웨어 섹션 아래의 디바이스 링크를 클릭하여 비밀번호로 이동하십시오. ‘작업(Actions)’ > ‘인증 정보 편집(Edit credentials )’을 선택한 다음, Ubuntu 호스트의 실제 루트 비밀번호와 일치하도록 비밀번호를 변경하십시오.
  • SSH 서버에 대한 루트 로그인을 사용할 수 없습니까?
  • SSH 서버가 사용 불가능하거나 중지되었습니까?
  • Ubuntu 호스트에서 루트 사용자 계정을 사용할 수 없습니까?

게이트웨이(vSRX) SSH 연결 오류의 경우:

  • vSRX 방화벽이 사설 IP에 대한 SSH 액세스를 차단합니까? 방화벽 규칙은 사설 10.0.0.0/8 서브넷에 대한 SSH 액세스를 허용해야 합니다. 서비스 네트워크에 대한 자세한 정보는 IBM Cloud IP 범위를 참조하십시오.
  • 게이트웨이 어플라이언스 세부사항 페이지에 나열된 루트 비밀번호가 루트 사용자의 올바른 비밀번호입니까? 그렇지 않은 경우, 루트 비밀번호 옆에 있는 편집 아이콘 편집 아이콘을 클릭하고 vSRX의 실제 루트 비밀번호와 일치하도록 비밀번호를 변경하십시오.
  • vSRX에 대한 SSH 액세스를 위해 루트 사용자 계정을 사용할 수 없습니까?

오류 1119 수정

vSRX 에 텔넷을 통한 로컬 콘솔 액세스를 차단하는 구성이 있을 수 있습니다. 사전 확인 작업을 다시 시도하기 전에 다음 구성을 확인하고 제거하세요:

set system ports console disable set system ports console insecure

다른 문제로는 잘못된 vSRX 비밀번호가 있을 수 있습니다.

때로는 시스템 포트 구성( vSRX )이 유효해 보이고 예상되는 콘솔 설정(set system ports console disable 또는 insecure)이 구성되지 않은 경우에도 준비 상태 검사 오류 1119가 발생할 수 있습니다. 이 문제는 Ubuntu 호스트의 불완전하거나 잘못 구성된 /etc/hosts 파일로 인해 발생할 수 있으며, 이는 텔넷 테스트 중 localhost의 성공적인 확인을 방해할 수 있습니다. Localhost가 IP 주소 127.0.0.1 에 명시적으로 매핑되어 있는지 확인합니다. 매핑이 누락되거나 잘못된 경우 준비 스크립트가 vSRX 콘솔 포트에 연결하지 못할 수 있습니다.

다음 명령은 etc/hosts 파일을 올바르게 구성하고 로컬 호스트에 매핑하는 방법을 설명합니다.

로컬호스트를 매핑하기 전에 /etc/hosts 파일은 다음 명령에 표시된 것처럼 보이며, 여기서 IP 주소 127.0.0.1 는 호스트 시스템의 이름에만 매핑됩니다.

root@test:~# cat /etc/hosts
127.0.0.1 test
127.0.1.1 ubuntu

로컬호스트를 올바르게 매핑하면 다음 명령에 표시된 것처럼 /etc/hosts 파일이 나타나고 로컬호스트가 IP 주소 127.0.0.1 에 올바르게 매핑됩니다.

root@test:~# cat /etc/hosts
127.0.0.1 test localhost
127.0.1.1 ubuntu

호스트 시스템에서 이러한 변경 사항으로 /etc/hosts 파일을 업데이트하고 telnet localhost (port-number) 명령을 실행하면 로컬 호스트에 대한 텔넷 연결이 성공하고 사전 확인 오류가 해결됩니다.

텔넷 연결의 포트 번호를 확인하려면 호스트 시스템에서 virsh dumpxml (VM-Instance-Name) | grep service 명령을 실행하고 서비스에 대해 표시되는 값을 사용합니다. VM 의 -Instance-Name을 확인하려면 virsh list 명령을 사용하십시오.

오류 1124 정정

vSRX 18.4R1-S1 은 이 Juniper 문제점 보고서에 문서화된 비호환성을 도입했습니다. 이 보고서에 액세스하려면 Juniper 계정이 필요합니다.

중복 이더넷(reth) 인터페이스에 vlan-tagging(기본값임)이 있는 경우, 인터페이스에 vlan-id 태그도 포함되어야 합니다. 18.4R1-S1에서는 vlan-id 태그가 없는 구성을 커미트할 수 있습니다. 19.4R2-S3과 같은 최신 버전에서는 이 구성을 사용할 수 없습니다.

vlan-id 없는 구성 예:

set interfaces reth2 vlan-tagging
set interfaces reth2 mtu 9000
set interfaces reth2 redundant-ether-options redundancy-group 1
set interfaces reth2 unit 2058 family inet address xx.xx.xxx.1/26
commit check

이 구성의 출력은 다음과 같습니다.

root@vSRX-Node0# commit check
[edit interfaces reth2]
 ‘unit 2058’
   VLAN-ID must be specified on tagged ethernet interfaces
error: configuration check-out failed

이 오류를 처리하려면 구성에 vlan-id 태그를 추가하고 준비 검사를 재시도하십시오.

set interfaces reth2 unit 2058 vlan-id 2058

오류 1125 정정

vSRX 18.4R1-S1은 syslog 구성에 structure-dataexplicit-priority 레이블이 둘 다 포함될 수 있게 허용하는 비호환성을 도입했습니다. 버전 19.4R2-S3 이상에서는 이러한 레이블이 더 이상 허용되지 않습니다.

예를 들어, 다음 syslog 구성에 두 레이블(set system syslog file messages structured-dataset system syslog file default-log-messages explicit-priority)이 모두 포함됩니다.

set system syslog file messages any info
set system syslog file messages authorization warning
set system syslog file messages archive size 10m
set system syslog file messages archive files 10
set system syslog file messages archive world-readable
set system syslog file messages structured-data
set system syslog file interactive-commands interactive-commands info
set system syslog file interactive-commands archive size 1m
set system syslog file interactive-commands archive files 10
set system syslog file interactive-commands archive world-readable
set system syslog file interactive-commands structured-data
set system syslog file default-log-messages any warning
set system syslog file default-log-messages authorization info
set system syslog file default-log-messages user info
set system syslog file default-log-messages firewall any
set system syslog file default-log-messages interactive-commands info
set system syslog file default-log-messages explicit-priority
set system syslog file default-log-messages structured-data
set system syslog file kmd-logs daemon info
commit check

이 구성의 출력은 다음과 같습니다.

[Stage 3 - Build_vSRX][2021-01-11 15:38:00.623323] Commit check failed: CommitError(edit_path: [edit system syslog file default-log-messages], bad_element: explicit-priority, message: error: ‘explicit-priority’ cannot be configured if ‘structured-data’ is configured
error: configuration check-out failed: (statements constraint check failed))

이 문제를 해결하려면 구성에서 syslog 레이블 중 하나를 제거하고 준비 검사를 재시도하십시오.

지원되지 않는 vSRX 구성 명령 수정

Juniper vSRX에는 문서화되지 않거나 숨겨진 CLI 명령이 포함되어 있습니다. vSRX 의 구성에서는 이러한 명령어 중 일부를 지원하지 않는데, 일부 릴리스에서는 해당 명령어를 커밋할 수 있음에도 불구하고 그렇습니다. 때로는 릴리스 버전 간에 예기치 않게 동작이 변경될 수 있습니다. 다음 정보는 이전 버전의 vSRX 에서 업그레이드할 때 지원되지 않는 것으로 알려진 일부 구성 명령어에 대해 자세히 설명합니다. 버전을 업그레이드하기 전에 vSRX 구성에서 지원되지 않거나 숨겨진 명령을 반드시 제거해야 합니다. 준비 상태 확인에서 감지되지 않는 명령어에 대해서도 이 과정을 수행하십시오.

오류 1145 정정

IDP 관련 정책 및 구성을 제거합니다. 다음 명령을 실행하여 모든 종속 항목을 수집하십시오.

show security policies | match idp | display set
show system scripts | display set
show security idp | display set

그런 다음 이러한 각 종속 항목에 대한 구성 스탠자를 삭제하십시오.

예:

delete security policies from-zone <$zone1> to-zone <$zone2> policy
<$policy> then permit application-services idp
delete system scripts commit file templates.xsl
delete security idp

오류 1147 정정

이전 섹션과 유사하게 보안 섹션에서 Junos가 구성을 구문 분석하는 방법을 변경하면 다음과 같은 오류가 발생할 수 있습니다.

error: Bad url pattern: *.googleapis.com/(*)

이 구성의 예로는 다음과 같은 것들이 있습니다:

set security utm custom-objects url-pattern AZURE value *.googleapis.com/*
set security utm custom-objects url-pattern website value *services.site.com

* 를 후미 문자 및 접두부로 사용하는 것은 더 이상 유효하지 않습니다. 대체 구성은 다음과 같습니다.

set security utm custom-objects url-pattern AZURE value *.googleapis.com
set security utm custom-objects url-pattern website value *.services.site.com

이 문제를 수정하려면 필요에 따라 vSRX 구성을 수정하고 커미트한 후 준비 상태 검사를 재시도하십시오.

tcp-mss를 사용하는 명령 set interfaces..

다음과 같은 문서화되지 않은 구성은 20.4R2-S2 이전 버전에서는 커밋될 수 있지만, 20.4R2-S2 에서는 실패합니다. 19.4R3-S2의 show configuration에서 unsupported platform 출력을 확인하십시오.

[edit]
root@asloma-vsrx-sa-sng0102-vsrx-vSRX# set interfaces st0 unit 0 family inet tcp-mss 1372
[edit]
root@asloma-vsrx-sa-sng0102-vsrx-vSRX# commit
commit complete
[edit]
.......
...
root@asloma-vsrx-sa-sng0102-vsrx-vSRX> show configuration interfaces st0
unit 0 {
    family inet {
        ##
        ## Warning: statement ignored: unsupported platform (vsrx)
        ##
        tcp-mss 1372;
    }
}

20.4R2-S2에서는 동일한 구성이 허용되지 않으며 다음 구문 오류와 함께 실패합니다.

{primary:node0}[edit]
root@asloma-tc1-10g-csb-ha1-vsrx-vSRX# set interfaces st0 unit 0 family inet tcp-mss
                                                                             ^
syntax error.

pre-20.4R2-S2 버전에서 20.4R2-S2 로 업그레이드할 때 이 상황으로 인해 문제가 발생합니다. 이전 구성이 새 릴리스에 커밋되지 않아 업그레이드도 실패하게 되기 때문입니다.

명령 set security datapath-debug..

set security datapath-debug 구성 명령은 업그레이드할 때 오류를 일으키는 것으로 알려져 있습니다. config 에서 모든 datapath-debug 명령을 제거하고 준비 상태 검사를 재시도하십시오. 예를 들어, 다음과 같은 명령을 제거하십시오.

set security datapath-debug capture-file pcap001
set security datapath-debug capture-file format pcap
set security datapath-debug capture-file size 10m
set security datapath-debug capture-file files 5
set security datapath-debug maximum-capture-size 1500

경고 1176 정정

establish-tunnelsimmediately로 설정되지 않은 VPN 구성이 발견되었습니다. 업그레이드 후, 원격 피어 게이트웨이와의 협상 결과 및 데이터 트래픽이 실제로 흐르고 있는지 여부에 따라 IKE가 즉시 활성화되지 않을 수 있습니다. establish-tunnels immediately가 없는 경우 터널은 on-traffic으로 설정됩니다. establish-tunnels immediately 문을 사용하면 구성이 커미트된 후에 바로 터널이 설정됩니다. 하지만 establish-tunnels immediately는 터널의 양 끝에 구성된 경우 원하지 않는 결과를 트리거할 수도 있습니다.

자세한 내용은 주니퍼 지식베이스의 (SRX)“SRX-A가 이니시에이터일 때는 IPsec이 정상 작동하지만, SRX-A가 응답자가 되면 실패한다” 문서를 참조하십시오. 이러한 설정에 대한 자세한 내용은 VPN(보안)을 참조하세요.

경고 1177 정정

dynamic-application any 로 구성된 하나 이상의 보안 영역 정책 규칙이 감지되었습니다. vSRX가 CSB(Content Security Bundle) 라이센스 및 애플리케이션 서명 데이터베이스와 함께 설치되지 않은 경우, 이 구성에서는 최신 vSRX 릴리스(예: 19.4R2-S3)의 변경으로 인해 트래픽이 중단될 수 있습니다.

예를 들어, 다음 보안 정책 구성에는 dynamic-application any 레이블이 포함됩니다.

set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL match dynamic-application any
set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL match source-address SL8
set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL match destination-address SL8
set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL then permit

유사한 구성을 사용하는 경우, CSB 라이센스 및 애플리케이션 서명 데이터베이스를 설치하거나 dynamic-application any 규칙을 제거하는 것이 좋습니다.

경고 1179 수정

게이트웨이에서 실행되는 vSRX 버전은 IBM Cloud 에서 인증되지 않았으며 지원되지 않습니다. ‘OS 재설치’ 및 ‘클러스터 재구축’과 같은 작업은 현재 지원되지 않는 vSRX 버전을 ‘게이트웨이 세부 정보’ 페이지에 나열된 버전으로 덮어씁니다. vSRX 버전은 IBM Cloud 에서 인증되지 않았으므로, IBM 지원팀에 문의하여 다음 링크( IBM Cloud Juniper vSRX supported versions )에서 확인할 수 있는 인증된 버전으로 마이그레이션하는 것이 좋습니다.

경고 1180 수정

게이트웨이에서 발견된 ‘ vSRX ’ 라이선스는 IBM Cloud 을 통해 구매된 것이 아니므로 지원 대상에서 제외됩니다. ‘OS 재설치’ 및 ‘클러스터 재구축’과 같은 작업은 현재 라이선스를 ‘게이트웨이 세부 정보’ 페이지에 표시된 버전으로 덮어씁니다. 지원되는 vSRX 라이센스는 vSRX 라이센스 보기 및 변경에서 확인할 수 있습니다. IBM Cloud 을 통해 라이선스를 구매하지 않은 경우, 해당 구매처에 문의하여 지원을 받으시기 바랍니다. 그렇지 않은 경우 지원되는 vSRX 라이선스로 마이그레이션하려면 IBM 지원팀에 문의하세요.

경고 1181 수정

게이트웨이의 vSRX 라이센스 및 버전이 모두 지원되지 않습니다. 이러한 경고 해결에 대한 도움말은 경고 1179정정경고 1180정정 을 참조하십시오.