여러 서브넷을 쓰는 IPsec에서 반환 트래픽이 사라지나요? reqid를 세어 보세요

트래픽이 한 사이트를 떠난 뒤 돌아오지 않고, 두 게이트웨이 모두 협상이 완료되었다고 보고하며, 유일한 단서는 응답이 없는 아웃바운드 패킷 더미입니다. Linux 엔드포인트에서 흔한 원인은 암호화 강도나 MTU, 라우팅 테이블이 아닙니다. 정책 항목의 세밀함과 각 정책을 보안 연계에 연결하는 번호입니다. 아래 절차는 다른 무엇을 건드리기 전에 이 두 데이터베이스를 읽습니다.

무엇이든 바꾸기 전에 증상을 분리하십시오

협상이 완료되었는데 한 방향만 실패하면 문제는 데이터 경로로 좁혀집니다. 아웃바운드 정책이 일치했는데 응답이 버려졌거나, 반대편에 보낼 수단이 없어 응답이 아예 도착하지 않은 것입니다. 애플리케이션에서는 둘이 똑같이 보이지만 xfrm 데이터베이스는 구분합니다.

MTU부터 시작하지 마십시오. 잘못된 MTU는 멈춤과 단편화 증상을 만들 뿐, 아웃바운드 카운터가 계속 늘어나는 깔끔한 방향 분리는 아닙니다.

정책 데이터베이스와 상태 데이터베이스를 읽으십시오

Linux에서는 정책 항목이 암호화를 결정하므로 패킷을 터널로 넣는 것은 일치하는 정책이고 경로가 아닙니다. ip xfrm policy을 실행해 각 항목의 선택자, 방향, 우선순위, 템플릿을 보고, ip xfrm state로 확립된 보안 연계와 그 reqid를 확인하십시오. 정책과 연계는 그 reqid로 연결됩니다.

세 방향을 모두 보십시오. 아웃바운드와 인바운드는 이 호스트와 주고받는 트래픽을 다루고, 호스트가 다른 곳을 위해 라우팅할 때는 포워드 방향이 중요합니다. 한 방향에서 항목이 없거나 어긋나면 암호학적 결함 없이 단방향 결과가 설명됩니다.

전형적인 비대칭: 여러 서브넷에 하나의 reqid

흔한 고장은 협상한 모든 서브넷의 정책을 하나의 reqid 아래 설치하는 피어에서 옵니다. racoon의 generate_policy require가 그렇게 동작합니다. 그러면 트래픽은 마지막으로 만들어진 연계로 나가고, 반대편은 서브넷마다 별도 연계를 유지합니다. 응답은 마땅히 받아야 할 정책을 reqid가 가리키지 않는 연계로 도착하고, 커널은 복호화 후 이를 버립니다.

해법은 방화벽 규칙이 아니라 설정 변경입니다. generate_policy unique;는 각 정책에 고유한 reqid를 주어 피어의 정책별 연계에 짝이 맞는 상대가 생기게 합니다. 적용하고 다시 협상한 뒤, 성공을 선언하기 전에 예상 서브넷의 서로 다른 reqid를 세십시오.

두 서브넷이 여전히 하나의 reqid를 공유하는데 반대편이 둘을 기대한다면 비대칭을 찾은 것입니다. 대응 관계를 기록하십시오. 다음 변경이 그것을 고쳤는지 유지했는지를 보여 주는 증거입니다.

선택자는 협상에서 나오며 설정에서 나오지 않습니다

보호되는 범위는 양 끝이 합의한 것이지 한쪽이 요구한 것이 아닙니다. 넓은 원격 범위에 호스트 쌍을 제안하는 클라이언트는 게이트웨이가 좁힌 버전을 받고, 클라이언트는 그것을 넓힐 수 없습니다. 로컬 파일이 아니라 설치된 선택자를 읽으십시오.

목표가 반대여서 한 목적지를 터널 밖에 두려면 우선순위 번호가 더 작은 우회 정책을 추가해 자동 설치된 항목을 이기게 하십시오. 템플릿이 없는 정책은 평문을 허용하므로, 이는 문제 해결 단계가 아니라 변경 기록을 위한 의도적 예외가 됩니다.

이 순서로 검증하고, 되돌리는 방법도 알아 두십시오

양방향으로 서브넷마다 정책을 나열하고, 호스트가 라우팅하면 포워드 방향도 포함하십시오. 서로 다른 reqid를 세고 기대하는 쪽에서 정책마다 하나인지 확인하십시오. 설치된 선택자를 합의된 것과 비교하십시오. 키 갱신 후 연계별 카운터를 다시 읽으십시오. 확인한 연계가 이미 사라졌을 수 있습니다. 경로는 마지막에 확인하십시오. 원격 서브넷으로 가는 경로가 없으면 정책 카운터는 깨끗한 채 비슷한 단방향 증상이 생깁니다.

피어를 바꾸기 전에 두 xfrm 명령의 현재 출력을 저장하십시오. 새 설정이 반환 방향을 되살리지 못한다면 그 출력을 되돌리는 것이 기억으로 터널을 다시 만드는 것보다 빠른 롤백이며, 비교를 정직하게 유지합니다.