IoT 센서를 VPN 뒤에 두기 전에 결정할 세 가지 주소
세 주소가 세 역할을 합니다. 공개 허브, 인증된 사이트 피어, 센서의 사설 주소입니다. 공개 주소를 할당하기 전에 각각을 계획하세요.
IoT를 VPN 너머로 연결하는 모든 계획에서 세 주소가 얽히며, 그것들은 같은 종류의 결정이 아닙니다. 하나는 원격 운영자가 터널 끝점을 찾는 방법이고, 다른 하나는 사이트가 자신이 그 사이트임을 증명하는 방법이며, 또 하나는 센서 서비스가 실제로 어디에서 수신하는지입니다. 이 순서대로 답하면 설계는 대부분 저절로 나옵니다. 하나의 질문으로 답하면 한 번도 필요하지 않았던 장치에 공개 주소를 할당하는 결과가 됩니다. 나가는 사이트 터널 뒤의 센서는 센서를 향한 인바운드 규칙이 전혀 없어도 권한 있는 운영자가 접근할 수 있습니다.
누가 시작하는지부터 정하라
누가 연결을 시작하는지가 이후의 거의 모든 것을 결정합니다. 사이트가 허브로 연결하면 사이트에는 인바운드 도달성이 필요 없고, 허브에는 사이트가 해석할 수 있는 이름이나 주소가 필요합니다. 이 하나의 선택으로 정적 공개 주소 지정 논쟁의 대부분이 시작되기도 전에 사라집니다.
그다음 세 역할이 깔끔하게 분리되며, 아래 표가 결정의 가장 짧은 형태입니다.
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
각 행의 소유자가 다르고, 그것이 핵심입니다. 허브는 VPN 서비스를 운영하는 사람의 것이고, 사이트 피어는 네트워크 팀의 것이며, 센서 주소는 장치를 소유한 사람의 것입니다.
허브 주소는 부트스트랩이며 목적지가 아니다
유지되는 공개 주소로 해석되는 이름이면 허브에 충분합니다. DNS 레코드는 끝점이 이동할 때 그것을 따라갈 수 있으며, 사이트 구성마다 손으로 고칠 필요가 없습니다. DNS가 하지 않는 일은 도달성을 만들거나 이전 응답을 캐시한 클라이언트를 새로 고치는 것이고, 이는 각각 다른 해결책이 필요한 별개의 문제입니다.
허브 없이 사이트 간 터널을 운영한다면 한쪽에 도달 가능한 끝점이 필요하거나 양쪽이 제삼자에게 연결하는 같은 논리가 다른 형태로 성립합니다. 그 주소와 갱신의 소유자는 어쨌든 필요합니다.
사이트 피어는 프리픽스가 붙은 정체성
피어는 먼저 정체성이고 다음이 프리픽스입니다. WireGuard 용어로 피어는 키 쌍을 보유하고 허브의 AllowedIPs 항목이 그 키를 사이트의 프리픽스에 묶습니다. IKEv2 용어로 인증서나 사전 공유 키가 사이트를 식별하고 트래픽 선택자가 무엇을 실을 수 있는지 말합니다. 한쪽만 바꾸면 배열이 깨지므로, 주소 변경을 정체성 변경으로 다루어서는 안 됩니다.
키나 인증서의 소유권을 허브 운영자가 아니라 사이트에 두어, 공급자 변경이 정체성 변경이 되지 않게 하세요.
프리픽스는 사람들이 계획하기를 잊는 부분입니다. 허브는 센서 서브넷을 올바른 피어에 연결해야 하고, 운영자의 클라이언트에는 그곳으로 가는 경로가 필요하고, 클라이언트에만 존재하는 경로는 트래픽을 조용히 버리는 터널로 보냅니다. 키 지문 옆 사이트 레코드에 프리픽스를 적어, 교체된 게이트웨이가 알아채지 못한 채 다른 커버리지로 올라오지 못하게 하세요.
센서 주소는 애플리케이션의 것
사이트 계획의 사설 주소로 충분하며, 필요한 것은 공개 도달성이 아니라 안정성이며, DHCP 예약, 정적 할당, 사이트 자체 영역의 이름 등으로 확보합니다. 장치를 다시 번호 매길 수 없다면 사이트 게이트웨이에서의 변환이 정당한 답이며, 변환이 문서화되고 반환 트래픽이 그것을 따르는 조건입니다.
계속 지킬 만한 습관이 하나 더 있는데, 공개 허브 주소를 센서 호스트의 다음 홉 필드에 붙여 넣지 마세요. VPN은 자체 경로를 설치하며, 공개 끝점에 대한 평범한 이더넷 인접성은 그럴듯해 보이는 구성을 만드는 허구입니다.
응답은 빠뜨리기 쉬운 절반입니다. 장치는 응답을 터널 쪽으로 되돌려 보내야 하며, 운영자 클라이언트로 가는 경로를 통해서든 요청을 변환한 같은 게이트웨이를 통해서든 상관없습니다. 기본 게이트웨이가 잘못된 센서는 요청을 받아들이고 아무 데도 답하지 않으며, 포워딩 관련 노트가 도착과 응답 라우팅이 하나가 아니라 두 개의 요구 사항인 이유를 설명합니다.
결정한 다음 경계를 적으라
누구든 연결하기 전에 접근 경계를 적어 두세요. 동작하는 경로는 사고로 일반 접근이 되기 쉬우므로, 게이트웨이를 IoT 세그먼트와 운영자가 필요로 하는 특정 서비스로 제한해야 합니다. 읽기 전용 모니터링과 구성 권한을 서로 다른 정체성을 가진 별도 역할로 유지하고, 계약이 끝날 때 접근을 제거할 사람을 지명하세요.
승인은 네트워크 소유자의 것이며, DMZ에 있다는 것은 접근 정책이 아닙니다.
배포 후 시험은 지루하지만 결정적이며, 허용된 프리픽스 안의 요청 하나가 성공하고, 게이트웨이에서 카운터가 증가하며, 프리픽스 밖의 의도적 시도 하나가 실패해야 합니다.