ASA FirePOWER 모듈에 FMC로 가는 관리 경로가 없습니다

FMC는 모듈을 도달 불가로 표시하고, 등록은 대기 상태에 머물며, ASA 내부에서 보낸 ping은 완벽하게 동작합니다. 기존 ASA FirePOWER 구축에서는 이 조합이 정상입니다. 모듈은 자체 관리 주소와 자체 기본 게이트웨이, 자체 라우팅 결정을 가지며, 일부 플랫폼에서 ASA와 물리 관리 연결을 공유한다고 해서 그것들이 하나의 네트워크 스택으로 합쳐지지는 않습니다. 같은 선로에서 두 장비가 서로 다른 관점으로 응답하는 것입니다.

다음 내용은 이미 운영 중인 모듈에 적용됩니다. 안내서의 포트 구성도를 적용하기 전에 섀시 모델, 모듈 유형, 지원 소프트웨어 릴리스를 확인하십시오.

모듈을 별도 호스트로 그리십시오

모듈의 관리 IP, 마스크, 기본 게이트웨이, 그 연결을 실제로 전달하는 VLAN, 도달해야 하는 FMC 주소로 도해를 시작하십시오. 그다음 별도 상자에 ASA의 인터페이스 주소와 전체 라우팅 테이블을 적으십시오. 두 상자가 결국 서로 다른 소유자의 주소로 같은 서브넷을 공유한다면 문제의 흥미로운 부분을 찾은 것입니다.

ASA FirePOWER 모듈 안내서는 플랫폼마다 포트 배치가 어떻게 다른지 보여 주며, ASA와 모듈이 같은 세그먼트에서 별도 주소를 갖는 공유 관리 배선도 포함합니다. 그 하드웨어 도해는 설계의 입력이지 각주가 아닙니다.

반환 경로가 끊기는 지점을 찾으십시오

코어를 경유하는 배치를 가정하십시오. 모듈은 FMC로 향하는 트래픽을 Layer 3 코어로 보내고, 코어는 원격 관리 목적지를 ASA 내부 인터페이스 쪽으로 전달하며, 사이트 VPN이 그것을 반대편으로 운반합니다. 그러면 원격 사이트에는 모듈의 관리 서브넷으로 돌아가는 경로가 필요합니다. 그 사슬의 모든 구간이 올바르면서 마지막 경로만 빠질 수 있고, 그래서 장애가 흔히 끊긴 터널처럼 보입니다.

무엇이든 바꾸기 전에 ASA 자체의 시야를 읽으십시오.

show interface ip brief
show route
show running-config interface

세 번째 명령이 중요한 이유는 잊고 있던 인터페이스 주소가 바로 반환 경로를 엉뚱한 장비에 착륙시키기 때문입니다.

ASA가 무엇을 연결됨으로 보는지 확인하십시오

ASA가 모듈의 관리 서브넷에 주소를 가지고 있으면 그 연결 경로가 해당 접두사를 소유합니다. 코어 쪽 정적 경로는 연결 경로의 소유권을 밀어내지 않으므로 패킷은 ASA로 돌아와 거기서 멈춥니다. 그러면 등록은 자격 증명과 아무 관련이 없는 지점에서 실패합니다.

특정 스푸핑 방지 검사가 패킷을 버렸다고 단정하지 마십시오. 장비 자체의 관측이 눈앞에 없을 때는 특히 그렇습니다. 대신 인그레스 인터페이스, 선택된 목적지 경로, 그리고 해당 플랫폼에서 지원되는 관리와 데이터 간 전달 경계를 비교하십시오. 이 세 가지 사실이 보통 누군가 등록 키를 재설정하기 시작하기 전에 토폴로지 충돌을 드러냅니다.

모듈을 연결된 상태로 유지하는 수정을 고르십시오

그 세그먼트에서 ASA 주소를 제거하는 것과 공유 포트를 물리적으로 비활성화하는 것은 같은 조치가 아닙니다. 모듈이 같은 물리 관리 연결을 타는 플랫폼에서는 포트를 비활성화하면 모듈의 유일한 링크가 사라집니다. 라우팅 문제를 죽은 장비로 바꾸는 셈입니다. 관리 라우팅 소유권을 재배치하는 변경을 우선하고, 네트워크 소유자가 참석한 가운데 단계적으로 진행하십시오.

지원되는 두 번째 선택지는 ASA의 관리 경로에 자체 세그먼트를 주어 모듈의 관리 서브넷에 소유자가 하나만 있게 하는 것입니다. 주소 하나와 약간의 문서가 들고 모호성을 영구히 없앱니다. 어느 경로를 택하든 이후에 모듈이 여전히 FMC와 DNS 또는 NTP 원본 모두에 도달하는지 확인하십시오.

경로가 일관된 뒤에만 등록하십시오

반환 경로가 깨끗해지면 해당 FMC와 모듈 릴리스 안내서에 따라 관리 연결과 등록 매개변수를 계획하십시오. 등록 비밀은 공유 메모와 티켓 밖에 두고, 진단 단계로서 재등록하려는 유혹을 물리치십시오. 끊긴 경로에 새 키를 넣으면 더 새로운 타임스탬프로 같은 실패가 날 뿐입니다.

경로는 ASA에서 시작한 ping이 아니라 모듈 자체 관리 스택에서 받아들이십시오. 시험의 출처가 바로 의심 대상이기 때문입니다. 모듈의 다음 홉, ASA의 VPN 선택, FMC의 응답 경로를 기록하고 두 관리 역할 모두에 독립적인 복구 수단을 유지하십시오. 그 기록이 수리된 전송과 성공한 등록을 구분합니다.

모듈이 마침내 FMC에 나타나면 같은 세 명령을 다시 실행하고 출력을 도해 옆에 저장하십시오. 그 관리 세그먼트를 만지는 다음 사람에게는 바로 그 비교가 필요합니다.