프라이빗 WAN에서의 IPsec: 확인해야 할 SRX 정책 경계

프라이빗 WAN은 IPsec 터널의 외부 패킷을 운반할 수 있으므로 피어 주소가 공인 인터넷 주소일 필요는 없습니다. 달라지는 것은 그 외부 패킷이 지나는 경로와 이를 수신하는 인터페이스의 권한입니다. SRX에서 외부 제어 경로, 터널 인터페이스 바인딩, 전달 트래픽 정책은 세 개의 별도 객체입니다. 나머지 둘이 잘못된 상태에서 하나만 문제를 찾는 것이 터널이 계속 다운되는 흔한 이유입니다.

먼저 외부 IKE 경로를 기록하세요

정책을 건드리기 전에 네 가지 값을 적으세요. 피어 주소, IKE를 수신하는 로컬 인터페이스, 피어에 도달하는 라우팅 컨텍스트, 그 인터페이스를 선택하는 경로입니다. IKE 패킷은 SRX 자체를 향하므로 수신 존에서 host-inbound 권한이 필요하며, 전달 트래픽 정책이 아니고, 패킷이 여전히 장비에서 종료되므로 프라이빗 WAN 주소라고 해서 이 요구 사항이 사라지지는 않습니다.

설치된 상태는 다음으로 확인하세요: show security ike sa 그리고 구성은 다음으로 확인하세요: show configuration security ike. 첫 번째는 페이즈 1이 있는지 알려 주고, 두 번째는 장비가 무엇을 해야 한다고 생각하는지 알려 줍니다.

터널 인터페이스를 올바른 정책에 바인딩하세요

라우팅 기반 VPN은 터널 인터페이스를 VPN 객체에 바인딩하며, 보호된 프리픽스는 그 인터페이스로 라우팅됩니다. 어떤 인터페이스, 어떤 경로, 어떤 정책이 관련 존 사이의 애플리케이션을 허용하는지 기록하세요. trust라는 존은 정책 컨테이너이며, 이름이 필요한 제어 또는 데이터 패킷이 허용된다는 것을 증명하지는 않습니다.

오래된 다이어그램 대신 실제 바인딩을 읽으세요: show configuration security ipsec vpn 은 인터페이스 바인딩 설정을 보여 주고, show configuration security policies 은 터널 존을 참조하는 규칙을 보여 줍니다.

보호된 경로가 다른 곳을 가리키면 터널은 올라가 있어도 트래픽이 전혀 들어가지 않을 수 있습니다. 이것은 IPsec 옷을 입은 라우팅 문제입니다.

피어 경로를 underlay에 유지하세요

외부 피어로 가는 경로는 underlay를 통해 해석되어야 하며, 그것이 만든 터널을 통해 재귀적으로 해석되어서는 안 됩니다. 피어 경로가 터널 인터페이스를 가리키면 IKE 패킷이 자기 터널을 쫓아가고 페이즈 1은 절대 완료되지 않습니다. 보호된 트래픽의 응답 경로에는 자체의 올바른 경로와 정책이 필요하며, 한 방향만 동작할 때 보통 빠진 절반이 바로 이것입니다. 피어 주소에 대한 라우팅 테이블 항목을 읽고 출력 인터페이스가 WAN 인터페이스인지 확인하세요.

다음으로 확인하세요: show route 198.51.100.10, 실제 피어 주소를 넣고, 다음 홉이 터널 인터페이스가 아님을 확인하세요.

제어와 서비스를 순서대로 검증하세요

위로 올라가며 작업하세요: 페이즈 1 상태, 페이즈 2 상태, 그다음 실제 애플리케이션 흐름입니다. show security ipsec sa 보안 연관을 나열하고, show security flow session destination-prefix 10.60.0.0/16 보호된 네트워크에 대한 전달 세션이 생성되는지 보여 줍니다.

건강한 제어 관계와 작동하는 데이터 경로는 서로 다른 두 결과입니다, 페이즈 2 통과는 정책이 애플리케이션을 허용하는지에 대해 아무것도 말하지 않습니다. 허용된 흐름 하나와 정책이 거부해야 하는 흐름 하나를 시험해 차이가 드러나게 하세요.

피어 경로, host-inbound 권한, 터널 바인딩, 내부 경로, 애플리케이션 정책을 함께 기록하세요. 이 다섯 기록은 포트 레이블에 의존하지 않고 향후 장애가 어느 계층의 것인지 보여 줍니다.