라우트 기반 대 정책 기반 사이트 간 VPN: 무엇이 다른가
정책 기반 IPsec은 셀렉터로 트래픽을 고르고, 라우트 기반은 터널 인터페이스로 보냅니다. 둘 다 여전히 방화벽 규칙과 반환 경로가 필요합니다.
두 설계는 같은 IPsec 장비로 같은 트래픽을 보호하며, 어떤 패킷이 터널에 들어가는지를 무엇이 결정하는지에서 다릅니다. 정책 기반 연결에서는 협상된 트래픽 셀렉터가 그 일을 하고, 라우트 기반 연결에서는 터널 인터페이스를 가리키는 라우트가 그 일을 합니다. 둘을 혼동하면 터널은 연결됐다고 보고하는데 애플리케이션은 아무 데도 닿지 못하는 익숙한 지원 스레드가 생깁니다. 이 구분은 네트워크를 추가하거나, 라우팅 프로토콜을 운영하거나, 잘못된 출구로 조용히 빠져나가는 경로를 디버깅할 때 가장 중요합니다.
터널에 무엇이 들어가는지 결정하는 두 가지 방법
정책 기반 VPN은 출발지와 목적지 프리픽스에 일치하는 보안 정책을 만들고, 맞는 것을 모두 암호화합니다. 상대는 호환되는 셀렉터를 협상해야 하므로 실효 범위는 결국 양쪽이 제안한 것의 교집합이 됩니다. 그 교집합 밖은 라우팅 테이블이 무슨 말을 하든 보호되지 않습니다.
라우트 기반 VPN은 터널을 대표하는 인터페이스를 만들고 라우팅 테이블이 그리로 트래픽을 보내게 합니다. IKE 데몬은 여전히 상태와 인터페이스별 정책을 설치하며, 이것이 라우트가 암호화를 대체했다고 판단할 때 건너뛰는 세부 사항입니다. 두 설계 모두 IPsec으로 암호화하며 선택 메커니즘만 다릅니다.
아래 비교는 어느 열도 자체로 이기지 않으므로 점수표가 아니라 장애 징후의 모음으로 읽으십시오.
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
정책 기반: 셀렉터가 계약이다
셀렉터는 구성만 하는 것이 아니라 협상됩니다. 한쪽에서 10.10.0.0/16을, 다른 쪽에서 10.10.1.0/24를 제안하면 협상이 정한 범위를 연관이 덮고 다른 모든 호스트는 밖에 남습니다.
구성 파일이 아니라 설치된 상태를 읽으십시오. Linux 상대에서는 커널 자체의 테이블이 근본 진실이며, 협상에서 무엇이 살아남았는지 보여 줍니다. 올바른 프리픽스를 지정하지만 일치하는 상태가 없는 정책은 연관이 결코 올라오지 않았음을 뜻합니다. 잘못된 프리픽스에 대한 정책과 짝지어진 상태는 반대 문제이며, 한 서브넷이 아무 데도 닿지 못하는데 터널은 건강해 보이는 상황을 만듭니다.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sas두 출력을 보호한다고 생각하는 프리픽스와 비교하십시오. 그 한 번의 비교가 터널은 작동하는데 서버에 닿지 못한다는 보고의 대부분을 해결합니다. 또한 불일치가 보통 한 방향에서만 보이기 때문에 어느 상대를 바꿔야 하는지도 알려 줍니다.
라우트 기반: 인터페이스가 계약이다
XFRM 인터페이스는 터널에 이름과 정체성을 부여하고, 라우팅 테이블이 그렇게 말하기 때문에 트래픽이 그리로 도달합니다. 그러면 여러 원격 프리픽스가 셀렉터 문제가 아니라 라우팅 문제가 되고, 라우팅 프로토콜이 이를 광고할 수 있습니다. 그것이 진짜 이득이며 암호화가 아닙니다.
인터페이스가 정책의 필요성을 없애지는 않습니다. 데몬은 인터페이스 정체성에 묶인 규칙을 인터페이스마다 설치하므로 잘못된 인터페이스로 들어온 패킷은 여전히 실패합니다. 상대가 받아들이지 않을 출발지 주소도 완벽한 라우트가 있어도 실패합니다. 라우트 기반은 라우트가 진입을 결정한다는 뜻이지 정책이 사라졌다는 뜻이 아닙니다.
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10라우트가 자리 잡으면 인터페이스 카운터를 지켜보십시오. 라우트는 있는데 카운터가 영에 머문다면 아무것도 터널로 매칭되지 않는다는 뜻이며, 보통 라우트가 없는 것이 아니라 상태가 없는 것을 가리킵니다.
두 설계가 실제로 갈라지는 곳
네트워크 추가는 어떤 모델이 맞는지 시험하는 가장 깔끔한 방법입니다. 라우트 기반 설계는 라우트를 하나 추가하고 셀렉터를 많아야 한 번 넓히며, 정책 기반 설계는 양쪽 상대에서 프리픽스 쌍을 편집하고 다시 협상합니다. 안정적인 서브넷 두 개면 그 편집은 사소하고, 스무 개면 프로젝트가 됩니다.
어느 모델도 방화벽을 대체하지 않으며, 비교는 보통 이 지점 전에 멈춥니다. 넓은 셀렉터나 넓은 라우트는 무엇이 암호화되는지를 정하지 무엇이 허용되는지를 정하지 않습니다.
MTU 동작도 실제로 다릅니다. 캡슐화는 사용 가능한 페이로드를 줄이고 라우트 기반 인터페이스는 자체 MTU를 가지므로, 양쪽 게이트웨이에서 MSS를 클램프하면 작은 응답은 도착하고 큰 응답은 사라지는 블랙홀 증상을 피할 수 있습니다. 정책 기반 터널도 셀렉터가 패킷 크기에 대해 아무 말도 하지 않으므로 반대편에서 같은 벽에 부딪힙니다. 상대를 탓하지 말고 클램프를 의도적으로 설정하십시오.
반환 경로를 잃지 않는 마이그레이션
무엇이든 바꾸기 전에 기존 프리픽스 쌍을 기록하고, 그다음 애플리케이션 경로 하나를 옮겨 끝에서 끝까지 지켜보십시오. 설정되는 터널은 전달하는 터널이 아니며, 그 차이는 응답 방향에서 나타납니다.
상대는 연결되는데 LAN 호스트가 연결되지 않으면 반환 라우트와 원격 호스트가 사용할 출발지 주소를 점검하십시오. 인터페이스가 두 개인 호스트는 잘못된 쪽에서 응답할 수 있고, 어떤 셀렉터 변경도 그것을 고치지 못합니다. 알고리즘을 편집하기 전에 양쪽 끝에서 트래픽을 캡처하십시오.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-conns작업하는 동안 터널에 의존하지 않는 관리 경로를 유지하십시오. 게이트웨이 자체 접근이 디버깅 중인 연결을 타지 않으면 되돌리기가 더 쉽습니다.