4G 지사 VPN: IP가 바뀌어도 정체성을 안정적으로 유지하기

지사 자체에서 시작하라, 4G 라우터의 WAN 상태 페이지에서. 보이는 주소가 공인 대역이 아니라 통신사의 사설 대역에 있다면, 그 장비에서 어떤 포트 포워딩도 허브가 안으로 접속하게 해 주지 못하며, 터널은 지사에서 바깥쪽으로 만들어야 한다. 이 한 가지 관찰이 설계를 결정한다. 나머지 작업은 허브가 몇 시간마다 바뀌는 주소보다 나은 무언가로 지사를 인식하게 만드는 것이다.

터널이 시작되어야 하는 지점

주소를 통신사가 자체 NAT에 쓰는 공유 주소 공간 100.64.0.0/10과 일반 사설 대역에 대조하라. 모바일 업링크에서 그중 하나가 보인다면 보통 통신사 등급 NAT가 지사와 인터넷 사이에 있다는 뜻이고, 인바운드 연결은 지사가 지불할 수 있는 어떤 가격으로도 얻을 수 없다. WAN 주소가 공인이지만 바뀐다면 다른, 더 쉬운 문제다.

동적 DNS는 두 번째 경우에만 도움이 된다. 바뀌는 공인 주소에 접속할 안정적인 이름을 주고, 통신사가 제공한 적 없는 매핑을 만들어 내지는 못한다. 공인 경우에는 재번호 부여에서 유일한 수동 단계를 없애 주므로 설정해 둘 가치가 있다. 그것이 되어서는 안 되는 것은 통신사가 애초에 도달 가능하게 만들지 않은 지사에 대한 답이다.

접속하는 주소와 대조하는 정체성을 분리하라

허브에는 승인된 고정 주소나 유지 관리되는 호스트 이름처럼 발견될 안정적인 무언가가 필요하다. 지사에는 인식될 안정적인 방법이 필요하고, IKEv2에서는 그것이 인증 중에 제시하는 정체성 페이로드이며, 패킷이 우연히 지니는 출발지 주소와 무관하다. @branch-a.vpn.example 같은 문자열은 모바일 주소가 매시간 바뀌어도 그 정체성으로 동작한다.

그 문자열은 정책과 대조되며 DNS로 해석되지 않으므로, 터널 설정 시 조회가 일어난다고 기대하지 마라. 허브 구성은 기대하는 정체성을 명시적으로 지명해야 하고, 인증서 인증에서는 정체성이 인증서가 실제로 주장하는 것과도 일치해야 한다.

출발지 주소가 그럴듯해 보인다는 이유로 아무 정체성이나 받아들이는 것이 피해야 할 실패 방식이다. 응답자에서는 정체성 와일드카드와 공유 비밀로 아무 피어나 받아들이는 것이며, 이는 장치가 아니라 문자열을 인증하는 것이다.

허브 쪽을 이름 있는 피어로 작성하라

strongSwan 용어로 응답자 쪽은 right=%any을 가진 연결로 어떤 출발지 주소에서든 피어를 받아들이며, 여기에 [email protected]을 더해 그 피어가 자신을 무엇이라고 주장해야 하는지 고정한다. 지사 LAN을 위해 rightsubnet=10.20.0.0/16을, 연결이 접속 없이 로드되도록 auto=add을, 생존성 확인을 위해 dpd_delay=30s을, 주소 변경이 새 피어로 취급되지 않고 흡수되도록 mobike=yes을 추가하라.

다른 업체들은 같은 객체를 보통 정체성 필드와 보호 서브넷 필드를 가진 동적 또는 지사 피어 유형이라는 다른 이름으로 표현한다. 둘 다 채워라(일반적인 동적 체크박스는 호환성 계획이 아니다).

지사를 시작자로 유지하라

지사에는 거울 이미지가 적용되어, 로컬 모바일 주소를 지금 그대로 쓰도록 left=%defaultroute, 정체성을 제시하도록 [email protected], 안정적인 허브 이름을 위해 right=hub.example.com, 사람 없이 터널이 올라오도록 auto=start. 모바일 링크가 다시 연결되면 지사가 다시 시작하고 허브는 같은 정체성을 같은 정책 객체에 대조한다.

양쪽에서 UDP 500의 IKE, UDP 4500의 NAT 통과, 뒤따르는 캡슐화된 ESP를 허용하고 그대로 두라. 업무 시간에만 열리는 규칙은 간헐적으로 끊기는 터널처럼 보일 것이다.

주소 변경을 시험하라, 첫 핸드셰이크만이 아니라

터널을 올리고 확인한 다음, 잠시 동안 모바일 데이터나 비행기 모드를 껐다 켜서 지사를 새 주소로 몰아넣어라. 허브의 보안 연관 목록을 보며 피어 주소는 바뀌고 정체성은 바뀌지 않았는지 확인하라. 통신사의 첫 재할당까지만 동작하는 터널은 전혀 시험되지 않은 것이다.

그다음 보호 서브넷을 따로 확인하라. 설정된 SA는 피어가 인증되었다고 말할 뿐, 허브에 지사 LAN으로 가는 경로가 있는지나 지사가 허브 쪽 트래픽을 받아들이는지는 말하지 않는다. 라우팅 테이블과 방화벽 정책을 따로 읽고, ping은 게이트웨이가 아니라 호스트에서 보내라(게이트웨이는 어떤 네트워크에서든 가장 대표성이 낮은 장치이기 때문이다).

안정적인 정체성은 지사를 허브가 이름 붙일 수 있는 정책 객체로 만든다. 통신사 NAT 주소를 도달 가능하게 만들지는 않으며, 그 자체로 조직의 나머지에 지사 접근 권한을 주지도 않는다.