사이트 VPN을 통한 원격 ASA SSH: 단계별 안내

SSH 클라이언트를 원격 ASA의 내부 주소로 향하게 하면 연결 단계에서 세션이 끊깁니다. 방화벽은 자기 사이트에서 응답하고 터널도 보이는데, 22번 포트에서는 아무것도 수신하지 않습니다. 이런 경우 대부분 패킷이 관리 허용 단계에 도달하지 못합니다. 시험 중인 경로가 관리 경로로 설계된 적이 없기 때문입니다. 아래 흐름을 순서대로 따라가면 장애가 옮겨 다니지 않습니다.

실제로 관리하는 주소를 고르십시오

세 가지 설계는 비슷해 보이지만 다르게 동작합니다. ASA의 공인 VPN 주소에 도달하는 경우, IPsec을 통해 내부 인터페이스에 도달하는 경우, 전용 관리 인터페이스에 도달하는 경우입니다. 권한을 건드리기 전에 관리자 출발지 주소, 정확한 목적지 주소, TCP 22를 적어 두십시오. 이후의 모든 것은 이 짝에 달려 있습니다.

서버 VLAN 두 개를 실어 나르는 터널이 방화벽 인터페이스 주소나 관리자 관리 서브넷을 전혀 싣지 않을 수 있습니다. 사이트 간 정책의 관심 트래픽 목록을 확인하고, ASA 자체 주소가 목적지로 나타나는지 확정하십시오. 통과하는 서브넷만으로는 부족합니다.

목적지가 방화벽 자체이므로 관리 허용은 전달 트래픽 규칙과 별개입니다. 클라이언트가 ASA 뒤의 서버에 도달하도록 허용하는 ACL이 장비의 SSH 관리를 따로 켜 주지는 않으며, 전달 규칙을 고쳐도 이 장애는 옮겨지지 않습니다.

management-access는 인터페이스별입니다

management-access 명령은 VPN을 통해 들어오는 관리 연결을 지정한 인터페이스에서 받아들이라고 ASA에 지시합니다. 경로를 만들지 않고, SSH 권한을 추가하지 않으며, 모든 인터페이스에 한꺼번에 적용되지도 않습니다. 목적지 인터페이스가 지정한 것과 다르면 인증 전에 연결이 버려집니다.

여기서 두 가지 예외가 걸립니다. 관리 전용 인터페이스는 이 방식에서 빠지며, ASA 9.20 관리 안내서는 기본 CiscoSSH 스택이 VPN을 통한 인터페이스 간 SSH를 지원하지 않지만 ASA SSH 스택은 지원한다고 밝힙니다. 경로에 시간을 쓰기 전에 배포된 릴리스에서 활성 스택을 확인하십시오.

로그인 프롬프트 앞의 네 관문

클라이언트와 사용자 이름 프롬프트 사이에는 네 개의 독립된 관문이 있습니다. 관리 짝에 대한 경로와 터널 일치, ASA 주소로 TCP 22를 허용하는 인터페이스 ACL, 관리자 출발지를 포괄하는 ssh 권한, 해당 사용자에 대한 AAA 인증입니다. 어느 것이든 어떤 관문이 닫혔는지 클라이언트에 알리지 않고 패킷을 떨어뜨릴 수 있습니다.

무엇이든 바꾸기 전에 packet-tracer로 어느 관문이 실패하는지 확인하십시오: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. 추적은 ACL, NAT 단계, to-the-box 결정을 알려 주므로 보통 라우팅 문제와 허용 문제를 갈라내기에 충분합니다.

넓은 권한이 아니라 좁은 권한을 쓰십시오

권한을 승인된 관리 서브넷과 터널 트래픽을 받는 인터페이스로 한정하십시오: ssh 10.10.5.0 255.255.255.0 inside. 외부 인터페이스에서 모든 출발지를 여는 대신 aaa authentication ssh console LOCAL 같은 인증 방식과 이름 있는 로컬 계정을 함께 두십시오.

인터페이스 ACL과 ssh 권한을 일관되게 유지하십시오. ACL이 막는 서브넷에 대한 권한은 여전히 실패하고, 일치하는 ssh 항목 없이 서브넷을 허용하는 ACL은 다음 관문에서 실패합니다. 두 진술은 같은 경로를 다른 계층에서 설명하므로 실행 중인 구성에서 함께 검토하십시오.

지정한 호스트에서 확인하고 다시 좁히십시오

책상이 아니라 지정된 관리 호스트에서 새 세션을 열고, 연결이 어느 출발지 주소와 인터페이스를 썼는지 ASA에서 확인하십시오. 세션이 열려 있는 동안 활성 세션과 실행 중인 구성의 SSH 절을 확인한 뒤, 세션을 닫고 시험용으로 추가한 임시 권한을 제거하십시오. 세션이 나타나지만 로그인 직후 끊긴다면 남은 문제는 도달성이 아니라 권한 부여입니다. 다음 사람이 진단을 되풀이하지 않도록 변경 기록에 인터페이스와 출발지를 남기십시오.

변경 내내 콘솔이나 독립적으로 승인된 다른 복구 경로를 사용할 수 있게 두십시오. 전용 경로가 동작하면 공인 출발지와 무관한 VPN 사용자가 같은 접근을 얻지 않았는지 확인하십시오. 누구에게나 통하는 관리 경로는 처음의 문제와 다른 문제입니다.