VPN 전용 주소에 실제로 응답하는 것은 무엇인가

조직의 할당 안에서 사용되지 않은 채 놓여 있는 주소는 리스너가 아니며, 방화벽에 추가한다고 해서 리스너가 생기지도 않는다. 그 주소에서 IKE를 종료하는 무언가가 필요하며, 그 방식은 게이트웨이가 주소를 소유하는지 아니면 상위 장치가 변환하는지에 따라 달라진다. 두 경우를 구분하는 것은 패킷 경로이고, 누군가 변경 요청을 열기 전에 어떤 플랫폼 기능이 필요한지를 결정하는 것도 이 경로다. 먼저 경로를 모델링하고, 그다음 선택한다.

주소 뒤의 패킷 경로

피어는 부여받은 주소로 UDP 500을 통해, NAT 통과가 관여하면 UDP 4500을 통해 IKE를 보낸다. 경로에서 그 주소를 가진 장치는 데이터그램을 로컬에서 받아 응답하거나, 다른 곳으로 전달한다. 가능성은 이 둘뿐이며, 이 글의 나머지는 어느 쪽이 참인지에서 나온다.

로컬 수신은 그 장치에 그 주소로 바인딩된 소켓이 있다는 뜻이다. 전달은 데이터그램이 다시 쓰여 다른 종단점으로 보내지고, 그 종단점이 소켓을 갖게 된다는 뜻이다. UDP 500을 허용하는 방화벽 규칙은 둘 중 어느 일이 벌어지는지 알려주지 않는다.

무언가를 건드리기 전에, 피어가 접속하는 주소, 상위 네트워크가 그것을 전달하는 방식, 그것을 받는 로컬 인터페이스나 논리 종단점, 그리고 IKE에 응답하는 프로세스라는 기록을 쓴다. 네 줄이며, 각 줄은 검증할 수 있다. 그중 하나가 불명이라면 그 불명이 바로 설계 작업이며 나중에 정리할 구현 세부가 아니다. 변경 요청이 승인된 뒤에 이 줄들을 채우는 것이 바로 변환 규칙이 엉뚱한 장치에 붙는 경로다.

모델 A: 게이트웨이가 주소를 소유한다

첫 번째 모델에서는 게이트웨이가 기존 인터페이스의 보조 주소로, 전용 인터페이스의 주소로, 또는 플랫폼이 터널 종단점으로 지원하는 loopback으로 주소를 직접 갖는다. 이들은 설정 경로가 각각 다른 세 가지 기능이며, 하나를 지원하는 플랫폼이 나머지를 지원하지 않을 수 있다.

그것을 전제로 설계하기 전에 플랫폼과 릴리스가 정확히 이 구성을 지원하는지 확인한다. 라우팅된 블록, 인터페이스의 추가 주소, loopback 종단점은 서로 바꿀 수 없고, 한 릴리스의 문서가 다음 릴리스의 동일한 동작을 약속하지도 않는다.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

수신 대기 중인 소켓이 증거다. 주소에 아무것도 바인딩되어 있지 않다면 라우팅 테이블이 무엇이라 하든 게이트웨이는 종료자가 아니며, 패킷 캡처에는 응답하는 것이 없는 데이터그램이 도착하는 모습이 잡힌다.

토폴로지의 다른 곳에 이미 존재하는 서브넷에 두 번째 인터페이스를 넣고 플랫폼이 알아서 하리라 기대하지 않는다. 인터페이스 서브넷이 겹치면 소스 선택이 모호해지고, 많은 플랫폼에서는 설정 자체를 거부한다.

모델 B: 상위 장치가 변환한다

두 번째 모델에서는 상위 방화벽이 전용 주소를 갖고 트래픽을 다른 VPN 게이트웨이로 전달한다. 이것은 되돌아오는 경로가 있는 목적지 변환이며, 그렇게 문서화되어 있는 한 완전히 타당한 설계다.

그것이 아닌 것은 상위 장치가 로컬 VPN 소켓을 얻었다는 증거다. 변환은 패킷을 전달할 뿐이며, 상위 상자를 IKE 응답자로 만들지 않는다. 상위 규칙이 제거되거나 되돌아오는 경로가 끊기면 게이트웨이가 건강하고 자체 리스너가 온전해도 VPN은 멈춘다.

피어가 접속하는 주소와 게이트웨이가 실제로 보는 주소, 두 주소를 모두 기록한다. 다음으로, UDP 500에는 통하지만 캡슐화된 ESP에는 통하지 않는 변환은 연결은 되고 트래픽은 나르지 못하는데 이는 나중에 디버깅하기 까다로운 장애이므로 전송 방식과 되돌아오는 경로를 기록한다.

ID는 바깥 주소가 아니다

IPsec은 터널 종단점을 그것이 보호하는 트래픽과 분리하고, 아키텍처는 그 결정들을 서로 다른 위치에 둔다. 피어가 접속하는 주소를 바꾼다고 해서 어떤 내부 프리픽스가 허용되는지, 어떤 경로가 설치되는지, 세션이 어떤 자원에 닿을 수 있는지가 자동으로 바뀌지는 않는다.

인증된 ID는 다시 별개다. IKEv2는 바깥 패킷 주소와 일치할 필요가 없는 ID 페이로드와 인증 교환을 나르므로, 변환된 설계도 여전히 올바르게 인증할 수 있다.

그 독립성은 유용하면서 동시에 함정이다. 평범한 리스너 하나로 해석되는 두 DNS 이름이 서로 다른 VPN 백엔드를 선택하지는 않으며, 한 ID를 지정한 인증서는 다른 ID를 기대하는 피어를 만족시키지 못한다. 주소만이 그것을 결정한다고 가정하기 전에 피어가 무엇을 검증하는지 확인한다.

연결 하나를 관찰해 설계를 받아들인다

새로 승인된 연결이 실제로 어디로 전달되는지, 어떤 ID가 응답하는지, 그다음 어떤 사설 흐름이 허용되는지 확인한다. 세 가지 관찰, 세 가지 다른 계층이며, 주소의 공개 조회가 성공해도 그중 어느 것도 시험하지 않는다.

부정적인 경우, 즉 받아들여서는 안 되는 피어나 도달해서는 안 되는 내부 프리픽스도 변경 후에 검증해 남긴다. 처음에 쓴 기록이 있기에 설계를 기억에서 재구성하지 않고 그 시험을 할 수 있다.

이 모든 것의 요점은 네트워크 소유자가 추가 주소로 모든 방화벽이 무엇을 할 수 있는지에 대한 일반적 주장에 기대는 대신 지원되는 할당 방식을 고르게 하는 것이다. 그 주장이야말로 어느 플랫폼에서나 그럴듯하게 들리지만 일반적으로 어디에서도 참이 아니기에 이런 설계가 어긋나는 지점이다. 네 줄짜리 기록이 당신의 플랫폼에 대해 십 분 만에 결론을 낸다.