13VSX 진단과 트러블슈팅VSX Diagnostics and Troubleshooting

문제들은 보통 마주치게 되는 순서대로 정리되어 있습니다. 그래서 어떤 해결책을 시도하기 전에 그 앞 단계들이 모두 성공했는지 먼저 확인하는 것이 중요합니다. 초기의 한 문제가 뒤 단계의 여러 문제를 줄줄이 일으키는 경우가 많기 때문에, 무엇이 잘못됐는지 따질 때는 근본 원인을 찾는 데 집중해야 합니다.

VSX 설정에 문제가 의심되면 다음 흐름으로 원인을 좁혀 갑니다. 여기서 쓰는 명령들은 명령어 레퍼런스 챕터에 자세히 나옵니다.

가장 먼저 각 VSX Gateway나 클러스터 멤버에서 vsx stat -v로 기본 설정을 점검합니다. 이 한 명령으로 모든 Virtual System이 빠짐없이 있는지, 모든 가상 장치가 Active인지, 각 VS에 올바른 보안 정책이 설치됐는지, 관리 서버와 SIC 신뢰가 맺어졌는지를 한 번에 확인할 수 있습니다. 이어서 각 VSX Gateway와 클러스터 멤버, 관리 서버에서 cplic print로 적절한 라이선스가 깔려 있는지 확인하고, 각 클러스터 멤버에서 cphaprob stat로 상태를 봅니다. 이때 멤버가 Active·Standby·Backup이 아닌 다른 상태로 나오면 R82 ClusterXL Administration Guide의 트러블슈팅 챕터를 참고합니다.

특정 Virtual System의 연결에 문제가 의심되면 반드시 vsenv <VSID>로 그 VS의 컨텍스트에 먼저 들어간 다음 진단해야 합니다. 컨텍스트를 맞춘 뒤 fw getifs로 그 VS의 인터페이스 목록을 보고, ping·traceroute·tcpdump·ip route·ip link 같은 표준 OS 도구로 연결 상태를 살핍니다. 이 도구들 중 일부는 현재 컨텍스트(라우팅·출발지·목적지 IP)에 따라 다르게 동작한다는 점을 기억해야 합니다.

인터페이스와 라우터가 모두 정상으로 보이는데도 문제가 남으면, 패킷이 시스템을 통과하는 과정을 직접 들여다봅니다. fw monitor -v <VSID>로 여러 지점에서 패킷을 캡처하면 같은 패킷이 여러 캡처 지점을 지나며 여러 번 보고되는데, 이 명령은 외부 Virtual Router로 향하는 패킷을 빼면 Virtual Router에 대해서는 보고하지 않습니다. 마지막으로 tcpdump로 Warp 인터페이스를 포함한 특정 인터페이스의 송수신 패킷을 보면 연결 문제의 단서를 자주 얻을 수 있습니다.

vsx stat -v              # VS 목록·Active 여부·정책·SIC 한 번에 점검
cplic print              # 라이선스 확인
cphaprob stat            # 클러스터 멤버 상태
vsenv <VSID>             # 진단 전 대상 VS 컨텍스트로 전환
fw getifs                # 해당 VS의 인터페이스 목록
fw monitor -v <VSID>     # 여러 지점에서 패킷 캡처
tcpdump -i <interface>   # Warp 포함 특정 인터페이스 송수신 캡처

VSX Gateway나 클러스터 멤버의 SIC 신뢰가 안 맺어질 때가 첫 번째입니다. VSX Gateway를 만들 때 Certificate cannot be pushed. Connection error with wait agent. 같은 오류가 나오는 경우인데, 먼저 VSX 쪽에서 관리 서버로 ping을 날려 연결을 확인하되 반드시 컨텍스트가 vrf 0인 상태에서 해야 합니다(반대로 관리 서버에서 VSX Gateway로 보내는 ping은 기본 정책 때문에 안 됩니다). 그래도 안 되면 케이블·경로·IP·중간 장비를 다시 점검하고, cpwd_admin list로 VSX Gateway의 모든 체크포인트 프로세스가 떠 있는지(PID가 0이 아닌지) 확인합니다. 재부팅 직후라면 프로세스가 아직 올라오는 중일 수 있습니다. 끝으로 netstat -an | grep 18211로 CPD 프로세스가 신뢰 설정 포트를 LISTEN하고 있는지 봅니다.

새 가상 장치의 SIC 신뢰 문제와 VSX 생성 마법사의 정책 설치 오류는 상당수가 관리 서버와 VSX Gateway의 시간·시간대 불일치가 원인입니다. SIC가 제대로 동작하려면 두 장비의 UTC/GMT 시각이 일치해야 합니다. 모든 장비에서 /bin/date -u로 UTC 시각을 확인하고, 시간대는 서로 달라도 되지만 UTC 기준이 맞도록 맞춰 줍니다. 정책 설치 오류의 경우 라이선스도 함께 의심해야 하는데, 관리 서버에서 cplic check로, VSX Gateway에서 vsx stat의 "Number of Virtual Systems allowed by license" 값이 0보다 큰지 확인합니다.

내부 호스트가 Virtual System을 ping하지 못할 때는 원인이 여럿입니다. 가장 흔한 것은 새로 만든 Virtual System에는 모든 트래픽을 막는 기본 정책(Default Policy)이 걸려 있다는 점입니다. 통신을 허용하는 정책을 설치하고 SmartConsole의 Logs & Events에서 VS가 트래픽을 허용하는지 확인해야 합니다. 그 밖에 스위치의 VLAN 설정이나 케이블 문제, 인접 라우터의 잘못된 라우팅, VS의 VLAN 인터페이스에 잘못 지정된 IP·넷마스크도 원인이 될 수 있습니다. 이때 tcpdump를 해당 VLAN 인터페이스에 걸어 트래픽이 VSX Gateway에 도착하고 나가는지 확인하면 도움이 됩니다.

특정 가상 장치(Virtual System이나 Virtual Router)의 SIC 신뢰가 깨져 연결 문제가 생겼다면 수동으로 다시 맺을 수 있습니다(자세한 절차는 sk34098 참고). 큰 흐름은 게이트웨이 쪽에서 SIC를 리셋하고, 관리 서버 쪽에서 옛 인증서를 폐기한 뒤, SmartConsole에서 객체를 열고 OK를 눌러 새 인증서를 발급하는 것입니다.

먼저 VSX Gateway 또는 각 클러스터 멤버에 접속해 Expert 모드로 들어간 뒤 vsx stat -v로 대상 가상 장치의 ID를 확인하고 vsx sic reset <VSID>로 SIC를 리셋합니다. 그다음 관리 서버에서 Expert 모드로 들어가는데, MDS라면 mdsenv <Domain Management Server>로 해당 가상 장치를 관리하는 Target Domain Management Server로 컨텍스트를 바꿉니다. 이어서 cpca_client lscert로 가상 장치의 SIC 이름을 알아내고 cpca_client revoke_cert로 인증서를 폐기합니다. 마지막으로 그 VSX 클러스터를 관리하는 Security Management Server나 Main Domain Management Server에 SmartConsole로 접속해 가상 장치 객체를 더블클릭하고 OK를 누르면, 새 SIC 인증서가 만들어져 게이트웨이에 저장됩니다.

# VSX Gateway / 클러스터 멤버에서
vsx stat -v                  # 대상 가상 장치 ID 확인
vsx sic reset <VSID>         # SIC 리셋

# 관리 서버에서 (MDS는 먼저 컨텍스트 전환)
mdsenv <Domain Management Server>
cpca_client lscert -stat valid -kind SIC | grep -i -A 2 <장치명>
cpca_client revoke_cert -n <CN=...,O=...>
# 이후 SmartConsole에서 객체 열고 OK → 새 인증서 발급