VPN 서브넷이 ASA 인터페이스의 보안 수준을 물려받을까?

복호화된 VPN 서브넷은 인터페이스의 보안 수준을 절대 물려받지 않습니다. sysopt connection permit-vpn, 그룹 필터, 관리 접근을 각각 확인하세요.

누군가 지사의 VPN 서브넷이 ASA에서 «보안 수준 0 또는 100»인지 묻지만, 그 질문에는 이미 오류가 들어 있습니다. 보안 수준은 로컬 인터페이스의 속성이며 인터페이스 설정에서 0에서 100까지 부여됩니다. 터널을 통해 도착하는 원격 서브넷은 crypto map이 어떻게 작성되었든 아무 수준도 얻지 못합니다. 그래서 그 질문에는 숫자로 된 답이 없습니다.

실용적인 다음 질문이 더 낫습니다. 어떤 정책이 지사를 서버로 들여보내고, 어떤 정책이 지사를 방화벽 자체에서 멀리 두는가입니다. 그것은 두 가지 답이며, 아래 절차가 둘을 분리합니다.

보안 수준은 인터페이스의 것

show running-config interface 를 실행하면 각 물리 인터페이스나 VLAN 인터페이스 아래에 security-level 가 표시되며, 터널 그룹이나 crypto map 아래에는 표시되지 않습니다. 상위에서 하위로의 기본 허용은 그 인터페이스들 사이에서 평가되므로, 그 숫자는 자신이 속한 경로에서 검사와 암시적 ACL의 동작을 바꿉니다.

복호화된 VPN 흐름에서 입구는 여전히 터널이 종료되는 outside 인터페이스이고, 출구는 서버 쪽 inside 인터페이스입니다. 무엇이든 만지기 전에 둘 다 적어 두세요. 그 한 단계가 혼란의 대부분을 없앱니다. 추상적인 신뢰 질문을 인터페이스 쌍으로 바꾸기 때문입니다.

ACL 우회에는 이름 붙은 경계가 있다

sysopt connection permit-vpn 는 VPN 트래픽이 ACL을 무시한다고 말할 때 사람들이 반쯤 기억하는 설정입니다. 실제로 VPN 트래픽으로 자격을 갖춘 트래픽에 대해 인터페이스 ACL을 건너뛰지만, 9.x 매개변수 안내서는 전역 예외를 선언하는 대신 인터페이스와 방향으로 범위를 한정합니다.

기억으로 추론하기 전에 무엇이 구성되어 있는지 확인하세요:

  • show running-config all sysopt 로 기본값이 아닌 줄만이 아니라 실제 값을 봅니다.
  • show running-config access-group 로 어떤 ACL이 어떤 인터페이스와 방향에 적용되는지 봅니다.
  • show vpn-sessiondb detail l2l 로 세션이 실제로 어떤 터널 그룹과 필터를 쓰는지 확인합니다.

VPN 접근을 강화하려고 그 설정을 끄는 것은 영향 범위가 큰 변경입니다. 자격을 갖춘 모든 VPN 흐름을 다시 외부 ACL에 종속시키므로, 보통 질문받은 지사와 무관한 방식으로 작동 중인 터널이 깨집니다.

세션에 연결된 필터를 읽어라

터널별 실제 제어는 VPN 필터입니다. 그룹 정책이나 사용자 이름이 참조하는 ACL이며, 복호화 후와 암호화 전에 적용됩니다. 사용자 수준 필터는 그룹 수준 값을 덮어쓰므로, 같은 터널 그룹의 두 사람이 서로 다른 실효 접근 권한을 가질 수 있습니다.

우선순위를 가정하지 말고 확인하세요. show running-config group-policy <name> 는 그룹 값을 보여 주고, show running-config username <name> 는 사용자별 값이 있는지 보여 줍니다. 둘 다 있으면 사용자 값이 이깁니다. 그다음 그 ACL의 항목을 관심 있는 흐름과, 필터가 평가하는 방향으로 비교하세요.

애플리케이션 서버를 허용하는 필터는 관리에 대해 아무것도 말하지 않습니다. 그것들은 별도 경로의 별도 규칙입니다.

허용 하나와 거부 하나를 검증하라

사용자의 보고를 기다리지 않고 결정을 보는 가장 빠른 방법은 Packet-tracer입니다. 복호화 측 흐름을 주고, 통과하는 ACL, NAT, 검사 단계를 이름으로 지목하게 하세요.

  1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
  2. 결과 줄을 읽으세요. 패킷을 허용하거나 버린 ACL을 지목합니다.
  3. inside 인터페이스에서 관리 목적지로 반복하고 거부를 확인하세요.
  4. 변경이 있을 때마다 한 번 더 반복해, 변경 전과 후 상태를 모두 기록하세요.

그다음 실제 트래픽으로 검증하세요. 지사에서 애플리케이션 요청 하나를 성공시키고, ASA로의 SSH 시도 하나를 실패시키세요. Packet-tracer는 경로를 모델링하고, 실제 흐름은 모델이 맞았음을 증명합니다.

작동하게 만든 변경을 되돌려라

수정이 ACL 우회를 끄거나 필터를 넓히는 것이었다면 이전 구성을 보관하세요. 변경 전에 저장한 영향받는 객체의 show run 캡처로 복원할 수 있습니다. ASA 구성은 줄 단위이므로 되돌리기는 옛 줄을 다시 입력하는 것이지 파일을 복원하는 것이 아닙니다.

인터페이스 쌍, 실효 필터, Packet-tracer에서 나온 ACL 이름, 변경한 정확한 명령을 기록하세요. 그 기록은 다음 검토를 신뢰 수준에 대한 또 한 번의 논쟁이 아니라 오 분짜리 점검으로 바꿉니다.

관련 글