IPsec 게이트웨이에서 보낸 ping은 다른 출발지 주소를 쓴다

IPsec 게이트웨이에서 반대편으로 ping을 보내 응답이 없으면 터널이 끊겼다고 결론 내리지만, 게이트웨이 뒤의 모든 워크로드는 트래픽을 정상적으로 보내고 있습니다. 두 결과는 모순되지 않습니다. 게이트웨이에서 시작한 ping은 로컬 출발지 패킷이고, 게이트웨이는 자기 라우팅 테이블에서 출발지 주소를 고릅니다. 그 선택은 실제 사이트 트래픽이 쓰는 주소와 다를 수 있어서 어떤 정책이 일치하고 어떤 반환 경로가 적용되는지를 바꿉니다. 결과에서 무엇을 읽어 낼지 정하기 전에 시험이 무엇을 증명해야 하는지 먼저 정하세요.

ping이 답할 수 있는 세 가지 질문

첫 번째 질문은 이 호스트에서 반대편에 애초에 도달할 수 있는가입니다. 두 번째는 터널의 셀렉터나 경로 기반 정책이 특정 출발지의 트래픽을 허용하는가입니다. 세 번째는 게이트웨이 뒤 워크로드에서 전달된 트래픽이 종단 간에 동작하는가입니다. 명령 하나로 세 가지에 모두 답할 수 없고, 이들을 구분하는 것이 출발지 주소입니다.

먼저 질문을 고르세요. 그러지 않으면 실패한 ping이 이미 갖고 있던 이론의 증거가 됩니다.

게이트웨이가 예상하지 못한 주소를 고르는 이유

목적지로 ping을 보내면 로컬 스택은 그 목적지에 맞는 경로에서 출발지를 고릅니다. 경로 기반 터널에서는 터널 인터페이스의 링크 주소일 수 있고, 많은 사이트 설계에서 이것은 지점 간 홉을 위해 고른 169.254.x.x 쌍입니다. 그 주소는 링크가 동작하도록 존재하며, 반대편에서 애플리케이션 출발지 네트워크로 광고되지 않습니다.

따라서 반대편은 반환 경로가 없는 주소나 어떤 셀렉터에도 맞지 않는 주소에서 에코 요청을 받을 수 있습니다. 터널은 건강한데 ping은 실패할 수 있고, 이것이 바로 이 글이 다루는 거짓 음성입니다.

출발지를 의도적으로 고르세요

관리하는 Linux 게이트웨이에서는 이미 로컬에 할당된 출발지를 고르세요: ping -c 4 -I 10.30.0.1 10.40.0.20. 여기 주소는 예시이므로 게이트웨이의 실제 내부 주소와 실제 원격 목적지로 바꾸고, 고른 출발지가 이 장치에 속하며 사이트 정책이 허용하는지 확인하세요.

시험을 위해 워크로드의 주소를 빌리지 마세요. 게이트웨이에 할당되지 않은 호스트를 사칭하면 아무도 재현할 수 없는 결과가 생기고, 일부 스택에서는 터널 결함처럼 보이는 방식으로 실패합니다.

요청만이 아니라 반환 경로를 읽으세요

실제로 어떤 출발지가 원격 목적지에 도착하는지, 도중의 의도적 변환까지 포함해 확인하세요. 그다음 반대편에서 그 출발지로 가는 반환 경로와 그것을 허용하는 셀렉터나 정책을 확인하세요. 예상 밖의 출발지로 도착한 요청은 암호가 아니라 라우팅과 정책의 문제입니다.

여기서는 ping을 한 번 더 하는 것보다 패킷 캡처가 더 도움이 됩니다, 반대편이 본 출발지를 보여 주고 그 주소로 반환이 도착해야 하기 때문입니다.

그다음 워크로드를 시험하세요

결정적인 시험은 게이트웨이 뒤의 일반 호스트에서 원격 게이트웨이 뒤의 일반 호스트로 ping을 보내는 것입니다. 이것이 게이트웨이의 전달 역할, 실제 애플리케이션 출발지, 진짜 반환 경로를 시험하며, 사용자가 신경 쓰는 흐름이 바로 이것입니다.

노트에는 게이트웨이에서의 도달성, 고른 출발지에 대한 정책 허용, 전달된 트래픽을 따로 기록하세요. 핀으로 고정한 ping의 성공은 터널이 무언가를 나른다는 유용한 증거이지 모든 전달 흐름이 동작한다는 증거는 아닙니다. 그리고 도달할 수 없는 자동 선택 게이트웨이 출발지는 사이트 터널이 죽었다는 증거가 아닙니다.

진단 답을 하나 얻으려고 169.254.0.0/16에 대한 포괄 경로를 추가하지 마세요. 그것은 오해를 부르는 시험을 영구적인 라우팅 결정과 맞바꾸는 일이고, 다음 사람이 맥락 없이 물려받습니다.