Firebox 지리 위치 거부: 먼저 VPN 진입 단계를 찾으십시오

다른 국가에 있는 사용자가 연결하지 못할 때, 첫 직감은 내부 리소스에 대한 접근을 부여하는 규칙을 보는 것입니다. 그 규칙은 허용 이후에 실행되므로 터널을 거부하는 대상이 될 수 없습니다. 차단 단계는 진입 경로 어딘가에 있으며, Firebox는 VPN 서비스에 따라 하나 이상의 진입 경로를 가집니다. 점검을 순서대로 수행하고 그중 하나가 거부를 설명하는 즉시 멈추십시오.

점검 1: 들어오는 서비스를 특정하십시오

SSL을 사용하는 Mobile VPN, Access Portal, TLS 기반 BOVPN의 경우 들어오는 진입점은 WatchGuard SSLVPN 정책입니다. 의도한 제한은 나중에 실행되는 사용자 접근 규칙에서 추론하는 대신, 실제로 구성된 서비스에 적용하십시오.

IPsec은 다른 경로를 갑니다. 내장 IPSec 정책은 해당 지사 및 모바일 VPN 서비스에 대해 외부 IPsec 트래픽이 Firebox로 들어오도록 허용하며, 수동으로 만든 IPSec 정책보다 우선합니다. 클라이언트가 IKEv2라면 여러분은 그 두 번째 경로에 있고, SSLVPN 정책은 무관합니다.

여기서 실수하는 것이 이 분야에서 가장 흔히 낭비되는 오후입니다. 패킷을 전혀 보지 않는 정책을 편집한 뒤 제한이 작동하지 않는다고 결론 내리는 것입니다.

점검 2: 이론이 아니라 거부를 읽으십시오

통제된 허용 시도를 한 번 수행하고 다음 네 가지를 연결하십시오. 클라이언트의 공인 소스 주소, 도달한 진입 서비스, 일치한 정책, 로그에 있는 모든 거부 사유입니다. WatchGuard의 IKEv2 문제 해결 지침은 지리 위치와 기본 패킷 처리가 내장 정책 허용 전에 트래픽을 거부할 수 있다고 언급하며, 이는 보이는 거부가 고려하지 않은 단계를 가리킬 수 있음을 의미합니다.

국가 분류는 관측된 네트워크 소스를 따릅니다. 로밍 사용자, 상위 NAT 또는 다른 승인 경로는 Firebox가 보는 것을 바꿀 수 있으므로 사용자가 어디에 있는지에 대한 설명이 아니라 주소를 확인하십시오. 클라이언트가 보는 공인 주소를 요청하고 Firebox 로그의 소스와 비교하십시오. 둘이 다르면 분류는 아무도 언급하지 않은 경로를 따르고 있는 것입니다.

점검 3: 내장 정책이 여전히 소유자인가?

수동 IPSec 정책이 무시되는 것처럼 보이면 내장 정책이 여전히 활성화되어 있는지 확인하십시오. 우선순위가 높은 내장 규칙에 가려진 수동 규칙과 유일한 허용인 수동 규칙은 겉보기 인터페이스가 같은 서로 다른 구성입니다.

어느 쪽이 경로를 소유해야 하는지 결정하십시오. 수동 정책이라면 해당 트래픽에 대해 내장 정책을 비활성화해야 하며, 다음 점검은 그 지점에서 시작됩니다.

점검 4: 비활성화 전에 교체를 계획하십시오

내장 IPSec 정책을 비활성화하면 영향을 받는 VPN 서비스에 대한 허용이 사라집니다. 모바일 사용자 한 명의 연결을 고치는 동안 생각하지 못한 지사 터널도 여기에 포함됩니다.

먼저 어떤 서비스에 허용이 필요한지, 어떤 소스 범위가 부여되는지, 변경이 잘못될 경우 장비를 어떻게 관리할지까지 포함해 완전한 교체를 계획하십시오. 여기서의 실수는 문제를 고치는 데 쓰려던 터널을 제거할 수 있으므로 독립적인 관리 및 복구 경로를 열어 두십시오. 변경 기록에 복구 단계를 적고, VPN 경로가 사라졌을 때 장비에 도달하는 방법도 포함하십시오. 그런 다음 첫 연결만이 아니라 갱신도 시험하십시오.

활성 연결과 이후의 재협상 모두 허용에 의존할 수 있습니다. 시험한 세션에서는 작동하지만 다음 키 교환에서 실패하는 변경은 갱신을 시험하지 않고 허용을 교체한 전형적인 결과입니다.

점검 5: 신원과 위치를 분리하십시오

지리 위치는 진입 결정에 맥락을 더합니다. 사용자가 누구인지 확립하지 않으며, 게이트웨이 신원 확인, 계정 권한 부여, MFA를 대체해서는 안 됩니다.

비즈니스 요구가 승인된 장소의 승인된 사용자뿐이라면 두 가지 통제가 모두 필요합니다. 국가 전체를 허용하는 위치 규칙은 인증을 대체하지 않으며, 차단된 국가의 인증된 사용자는 정책 문제이지 버그가 아닙니다.

점검 6: 기록하고 두 경로를 모두 검증하십시오

서비스, 진입 정책, 의도한 위치 범위, 예외, 복구 담당자를 적으십시오. 그런 다음 변경 후 모바일 경로와 최소 하나의 사이트 경로를 시험하여 제한이 원래 제어하려던 서비스에 계속 붙어 있게 하십시오.

마지막으로 처음 시작한 거부를 다시 읽으십시오. 그것이 위치 거부에서 인증 또는 권한 부여 실패로 바뀌었다면 진입 문제는 해결되었고 이제 다른 문제가 보이는 것입니다. 위에서 설명한 단계 순서에 대해서는 IKEv2 거부에 관한 WatchGuard 지침이 참고 자료입니다.