터널을 통해 10.20.0.5로 ping을 보내면 아무것도 돌아오지 않는데, 라우팅 테이블은 그 서브넷에 도달할 수 있다고 주장합니다. 라우팅과 IPsec은 서로 다른 질문에 답하며, 둘 중 하나만 도달 가능성에 관한 것입니다. 포워드 조회가 경로를 고르고, 그다음 보안 정책 데이터베이스가 그 경로를 보호해야 하는지, 그대로 두어야 하는지, 거부해야 하는지 결정합니다. 둘이 어긋나면 패킷은 조용히 죽으므로, 이 순서로 읽으십시오.

테이블이 아니라 조회부터 시작하십시오

커널이 실제로 무엇을 할지 물어보십시오: ip route get 10.20.0.5는 선택된 경로, 나가는 인터페이스, 사용할 원본 주소를 출력합니다. 접두사, 정책 규칙, 표시, 선호 원본 모두 그 답을 바꿀 수 있으므로 살아 있는 조회가 눈으로 테이블을 읽는 것보다 낫습니다.

보호 범위 안의 목적지를 시험하고 게이트웨이 주소는 시험하지 마십시오. 반대편 게이트웨이에 도달하는 것은 어떤 경로가 존재한다는 것만 증명하며, 실제로 필요한 서브넷에 대해서는 아무것도 말하지 않습니다. 그다음 조회가 고른 인터페이스가 터널이 사용하리라 기대하는 것인지 확인하십시오.

양쪽에서 선택자를 맞추십시오

정책 데이터베이스에는 자체 항목이 있고, 각 항목은 방향, 원본, 목적지, 프로토콜을 지정한 뒤 일치하는 패킷에 무슨 일이 일어나야 하는지 말합니다. 목록을 보려면 ip xfrm policy를 사용하십시오; 플래그는 동작이 보호인지, 우회인지, 차단인지 보여 줍니다. 선택자가 테스트 흐름보다 넓거나 좁은 정책은 그것과 일치하지 않으며, 패킷은 보호 없이 나갑니다. 찾고 있는 고장은 그것이지, 없는 경로가 아닙니다.

실제 값을 비교하십시오: 원본, 목적지, 프로토콜, 포트입니다. 조회가 한 주소 쌍을 해석했는데 정책 항목이 다른 쌍을 포함한다면, 두 화면은 서로 다른 트래픽을 설명합니다. 결론을 내리기 전에 같은 튜플로 둘 다 다시 실행하십시오, 그렇지 않으면 경로에 없었던 정책을 편집하게 됩니다.

정책 일치는 설치된 상태가 아닙니다

일치하는 정책은 패킷을 보호해야 한다고 말할 뿐이고, 보호를 수행하려면 커널에 아직 보안 연결이 필요합니다. ip xfrm state로 나열하거나, strongSwan이 협상을 맡을 때는 swanctl --list-sas로 나열하고, 각 항목의 선택자와 카운터를 읽으십시오.

정책이 일치하는데 같은 선택자를 포함하는 연결이 없으면, 패킷은 평문으로 보내지는 대신 버려집니다. 터널은 올라와 있는데 한 서브넷만 실패할 때 찾아야 할 버림이 그것입니다. 카운터가 나머지를 말합니다: 전혀 늘지 않는 연결은 선택된 적이 없고, 늘어나는데도 버림으로 끝나는 연결은 원격 쪽을 가리킵니다. 선택자를 고치는 것과 키를 갱신하는 것은 다른 수리이므로, 설정을 건드리기 전에 어느 쪽이 필요한지 결정하십시오.

경로 기반 터널에 여전히 필요한 것

XFRM 인터페이스는 터널을 라우팅할 수 있는 장치처럼 보이게 합니다, 이는 정말 유용합니다. 다만 패킷이 그곳에 도착한 뒤 무슨 일이 일어나는지 결정하는 정책과 상태를 없애지는 않습니다. 경로가 기여하는 것은 다음 홉뿐입니다.

장치가 있고 경로가 그 안을 가리키는데 내부 선택자와 일치하는 연결이 없다면, 패킷은 버려지고, 경로를 아무리 편집해도 키나 선택자는 생기지 않습니다. 라우팅한 것과 같은 원본과 목적지로 인터페이스를 확인하고, 그것을 상태 목록과 비교하십시오.

무엇이든 편집하기 전에 소유권을 정하십시오

호스트 방화벽은 두 데이터베이스 어느 쪽도 모르는 세 번째 결정을 추가합니다. 올바른 경로와 일치하는 정책과 설치된 연결이 모두 있어도 버려진 패킷으로 끝날 수 있고, 애플리케이션은 시간 초과만 보고합니다. IPsec을 탓하기 전에 방화벽이 보호 트래픽을 허용하는지 확인하십시오. 터널 장치와 물리 인터페이스에서 캡처하면 암호화의 어느 쪽에서 패킷이 사라졌는지 보여 줍니다.

설정 소유권은 수정이 재시작 후에도 살아남는지 결정합니다. 한 구성 요소가 상태를 설치하고 다른 구성 요소가 경로를 관리할 수 있으며, 후자에 대한 수동 편집은 터널이 다음에 올라올 때 덮어써집니다. 소유 설정을 바꾸고, 그다음 두 화면을 다시 읽으십시오; RFC 4301은 그 분할을 다른 사람에게 설명해야 할 때 두 데이터베이스를 분리해 둡니다.

관련 글