IPsec 터널 인터페이스 모니터링: 무엇을 읽어야 하는가

경로 기반 IPsec 설계는 가상 인터페이스를 설치하며, 그 인터페이스는 이름, 카운터, 그리고 거기에 연결된 경로를 가진 구체적인 객체를 모니터링에 제공합니다. 그것 자체로는 상태 신호가 아닙니다. 사용 가능한 연결이 설치되지 않아도 인터페이스는 존재할 수 있고, 관심 있는 트래픽을 그쪽으로 보내는 경로가 없어도 연결은 건강할 수 있습니다. 네 가지 상태를 함께 읽는 것이 패킷 카운터를 진단으로 바꿉니다.

순서대로 확인하고 처음 실패하는 상태에서 멈추십시오.

인터페이스가 그림에 더하는 것

정책 기반 설계에서는 선택이 IPsec 정책 테이블에 있고 커널이 트래픽 선택자를 기준으로 무엇을 보호할지 결정합니다. 경로 기반 설계는 인터페이스와 경로를 추가하므로 tcpdump와 인터페이스 카운터는 선택자 집합이 아니라 하나의 경계를 봅니다. 이것은 진단과 peering을 위해 인터페이스가 필요한 라우팅 프로토콜 모두에 실제 이점입니다.

이점은 운영상의 것이지 암호학적인 것이 아닙니다. 인터페이스는 자신이 나르는 트래픽을 보고할 뿐 상대방의 보호가 현재 사용 가능한지는 말하지 않습니다.

터널을 탓하기 전에 네 가지 상태를 읽으십시오

인터페이스와 경로에서 시작해 다음으로 연결, 다음으로 애플리케이션을 보십시오. 각각 고유한 명령과 고유한 실패 징후가 있습니다. 한 계층의 깨끗한 결과가 다음 계층의 깨끗한 결과는 아닙니다. 결론을 내리기 전에 네 가지를 모두 실행하십시오. 초록색 한 줄이 무언가를 결정하는 경우는 드뭅니다.

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

카운터는 오르는데 대응하는 상태 항목이 없는 인터페이스는 아무것도 보호하지 않는 경로로 트래픽이 들어가고 있음을 뜻하며, 이는 단순히 내려간 터널보다 나쁩니다. 인터페이스를 선택하는 경로가 없는 상태 항목은 암호가 준비되었지만 사용되지 않음을 의미합니다.

애플리케이션 테스트가 마지막에 오는 것은 의도적이며, 터널 반대편으로의 성공적인 ping은 그 뒤의 서비스가 연결을 받아들인다는 것을 증명하지 않습니다.

안쪽 카운터를 바깥쪽 카운터와 비교하십시오

터널 인터페이스의 카운터는 안쪽 트래픽을 측정하고, 물리 인터페이스의 카운터와 캡처는 캡슐화된 교환을 보여 줍니다. 둘은 캡슐화가 헤더를 더하고, 재전송이 일부 패킷을 복제하며, 구현의 계산이 자체 규칙을 따르기 때문에 일대일로 일치하지 않습니다. 같음이 아니라 비율을 기대하십시오.

캡처 위치는 어떤 개인 데이터를 수집하는지도 결정하므로, 운영 트래픽을 전부 캡처하는 대신 좁은 필터와 무해한 테스트 주소를 사용하십시오.

안쪽 카운트가 늘고 바깥쪽이 늘지 않는다면, 빠진 단계는 대개 패킷을 터널로 보내는 경로나 정책이며 터널 자체가 아닙니다.

키 갱신과 장애 조치를 거치며 관찰하십시오

같은 네 가지 상태를 지켜보면서 키 갱신, 죽은 피어 감지 이벤트, 링크 장애 조치를 관찰하십시오. 결코 완료되지 않는 키 갱신 동안에도 인터페이스는 남아 있을 수 있고, 장애 조치는 더 이상 도달할 수 없는 피어 주소를 가리키는 상태 항목을 남길 수 있습니다.

실제로 의존하는 서비스 경로에 대해, 단일 업/다운 플래그가 아니라 연결 상태를 맥락으로 삼아 경보를 내십시오. 인터페이스 이름, 피어 주소, 경로를 경보 페이로드에 남겨 대응하는 사람이 다시 구성하지 않도록 하십시오.

strongSwan은 자체 XFRM 인터페이스 모델을 문서화하며, 다른 플랫폼은 동등한 객체를 다른 이름과 방식으로 구현합니다. 다른 구현에서 가정을 옮기기 전에 눈앞의 장치에 대한 경로 기반 비교를 읽으십시오. 한 공급업체의 카운터에 맞는 모니터링 템플릿은 다른 공급업체에서 조용히 오해를 부릅니다.