XFRM 인터페이스로 라우트 기반 IPsec이 작동하는 방식

라우트 기반 IPsec은 예전에 정책 선택자가 내리던 결정을 라우팅 테이블에 넘깁니다. Linux에서 이를 가능하게 하는 부분이 XFRM 인터페이스입니다. 선택자가 아니라 인터페이스 식별자로 트래픽이 IPsec 상태와 매칭되는 가상 장치입니다. 하나를 만드는 데 명령 하나면 충분하며, 터널이 존재하는지는 아무것도 증명하지 않습니다. 이 장치는 라우팅과 보안 정책 사이의 갈고리이고, 무언가가 보호되기 전에 그 갈고리의 양쪽을 모두 구성해야 합니다.

장치가 무엇이고 무엇이 아닌지

XFRM 인터페이스는 라우팅 핸들입니다. 그리로 라우팅된 패킷은 같은 인터페이스 식별자를 참조하는 XFRM 정책과 매칭되며, 정책과 상태가 모두 있으면 캡슐화됩니다. 그것들이 없으면 인터페이스는 존재하지만 카운터는 멈춰 있고 트래픽은 쓸모없는 곳으로 갑니다.

이것이 첫 번째 진단적 구분입니다. 장치로 들어가는 라우트는 라우팅 사실입니다 설치된 상태는 보안 사실이고, 장치에서 증가하는 카운터는 둘 다 아닙니다. 인터페이스가 UP을 보여서 터널이 올라왔다고 말할 때, 사람들은 자기 상대가 없는 가상 장치의 링크 플래그를 설명하는 것입니다. 그 플래그는 장치가 생성되고 활성화되었다는 뜻일 뿐입니다.

또 하나의 경계: 인터페이스 식별자는 이름이 아닙니다. 이름이 비슷하고 식별자가 다른 두 장치는 상태를 공유하지 않으며, 잘못된 식별자로 구성된 연결은 어떤 라우트도 절대 사용하지 않을 상태를 설치합니다.

올바른 순서로 하나 만들기

외부 장치와 데몬 구성에도 넣을 번호부터 시작합니다. 예제는 외부 인터페이스로 eth0을, 식별자로 42를 사용하며, 이 주소는 여러분의 것으로 바꿔야 합니다.

장치를 올린 다음 VPN 구성을 건드리기 전에 커널이 기록한 식별자를 확인합니다:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

이제 strongSwan에서 같은 식별자로 연결을 구성합니다. 데몬이 그것을 참조하는 정책과 상태를 설치해야 하기 때문입니다. 로컬 및 원격 트래픽 선택자를 라우팅하려는 범위로 설정한 다음 그 범위를 장치로 라우팅합니다. 데몬 구성과 라우팅 테이블은 식별자와 목적지 모두에서 일치해야 하며, 어느 쪽도 다른 쪽을 제공하지 않습니다.

IKE와 ESP를 터널 라우트 밖에 두기

XFRM 장치로 향하는 기본 라우트는 캡슐화된 패킷과 그것이 나르는 트래픽을 함께 붙잡습니다. 결과는 루프입니다. 게이트웨이가 ESP가 만들어야 할 터널을 통해 자기 ESP를 보내려 합니다.

해결책은 상대의 외부 주소에 대한 더 구체적인 라우트를 물리 인터페이스로 잡는 것입니다. 더 많은 비트에 일치하므로 기본 라우트를 이깁니다. 여러 터널이 한 테이블을 공유할 때는 마크 기반 라우팅이 같은 역할을 하며, strongSwan은 라우트 기반 배포를 위한 두 접근을 모두 문서화합니다.

무엇을 선택하든 외부 패킷이 캡슐화 없이 나가는지 확인하십시오. 빠른 확인은 터널이 올라온 뒤 상대의 외부 주소로 ping하는 것이며, 인터페이스가 올라와 있는데 실패하면 도달성이 아니라 가로채기를 의심하십시오. 같은 논리가 IKE 포트에도 적용됩니다. 데몬 자신의 UDP 트래픽이 자기가 세우려는 장치로 라우팅되어서는 안 되기 때문입니다.

암호화를 탓하기 전에 두 곳에서 카운터 확인하기

인터페이스 카운터와 상태 카운터는 서로 다른 단계를 측정합니다. 장치로 라우팅된 패킷은 어떤 상태도 일치하지 않아도 장치 카운터를 올리지만, 상태 카운터는 실제로 캡슐화된 트래픽에만 움직입니다.

둘 다 읽고, 그다음 데몬이 자식 연결을 보는 관점을 읽으십시오:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

상태 출력이 비어 있는데 장치 카운터가 오르면 라우팅은 되지만 정책이 일치하지 않는다는 뜻이며, 보통 식별자나 선택자 실수입니다. 원격 쪽이 아무것도 보고하지 않는데 상태 카운터가 오르면 패킷이 나가지만 도착하지 않거나 인증에 실패한다는 뜻이며, 경로나 상대 구성을 가리킵니다. 목록에 있는 자식 연결에 트래픽이 없으면 한쪽 끝의 선택자 문제이지 고장 난 암호가 아닙니다.

라우트를 누가 설치할지 정하기

한 라우팅 테이블에 두 주인이 있으면 플래핑의 흔한 원인입니다. 데몬이 라우트를 자동으로 설치한다면 네트워크 관리자도 같은 장치를 통해 기본 라우트를 설치해서는 안 되며, 시작 스크립트가 추가한 수동 라우트는 다음에 데몬이 재구성할 때 제거됩니다.

주인을 하나 고르고 기록하십시오. 데몬이 라우트를 소유하면 시작 스크립트를 테이블 밖에 두고 연결 정의가 트래픽 선택자를 설명하게 하십시오. 네트워크 관리자가 소유하면 자동 설치를 끄고, 재연결 시 데몬이 빠진 라우트를 고치지 않는다는 점을 받아들이십시오.

포워딩과 방화벽 규칙은 그 위에 별도의 결정입니다. 다른 호스트의 트래픽을 통과시키는 게이트웨이는 둘 다 필요하기 때문입니다. 라우트 기반 IPsec은 그 트래픽을 일반 라우팅 도구로 쉽게 표현하게 해 주지만, 정책 계층을 선택 사항으로 만들지는 않습니다.