Tres decisiones de dirección antes de poner sensores IoT detrás de una VPN
Tres direcciones cumplen tres funciones: el concentrador público, el par del sitio autenticado y la dirección privada del sensor. Planifique cada una antes de asignar algo público.
Tres direcciones se enredan en todo plan de IoT sobre VPN, y no son el mismo tipo de decisión. Una es cómo un operador remoto encuentra el extremo del túnel, otra es cómo el sitio demuestra que es el sitio, y otra es dónde escucha realmente el servicio del sensor. Respóndalas en ese orden y el diseño casi sale solo. Respóndalas como una sola pregunta y acabará asignando direcciones públicas a dispositivos que nunca necesitaron una. Un sensor detrás de un túnel de sitio saliente es accesible para un operador autorizado sin ninguna regla de entrada que apunte al sensor.
Empiece por quién inicia
Quién marca determina casi todo lo demás. Cuando el sitio marca hacia un concentrador, el sitio no necesita accesibilidad de entrada, y el concentrador necesita un nombre o una dirección que el sitio pueda resolver. Esa única elección elimina la mayor parte del debate sobre direccionamiento público estático antes de que empiece.
Los tres roles se separan entonces con claridad, y la tabla de abajo es la forma más corta de la decisión.
| 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 |
Cada fila tiene un propietario distinto, y ese es el punto real. El concentrador pertenece a quien opera el servicio de VPN, el par del sitio al equipo de red, y la dirección del sensor a quien posee el dispositivo.
La dirección del concentrador es de arranque, no un destino
Un nombre que resuelve a una dirección pública mantenida basta para el concentrador. Un registro DNS puede seguir al extremo cuando se mueve, sin editar a mano cada configuración de sitio. Lo que el DNS no hace es crear accesibilidad ni refrescar a un cliente que cachea la respuesta antigua, y esos son problemas separados con soluciones separadas.
Si ejecuta túneles de sitio a sitio sin concentrador, la misma lógica se mantiene en otra forma: un lado necesita un extremo accesible, o ambos lados marcan a un tercero. Alguien tiene que seguir siendo dueño de esa dirección y de sus renovaciones.
El par del sitio es una identidad con un prefijo adjunto
El par es primero una identidad y segundo un prefijo. En términos de WireGuard el par guarda un par de claves y la entrada AllowedIPs del concentrador vincula esa clave al prefijo del sitio. En términos de IKEv2 un certificado o una clave precompartida identifica el sitio y sus selectores de tráfico dicen qué puede transportar. Cambiar solo una mitad rompe el arreglo, y por eso un cambio de dirección nunca debe tratarse como un cambio de identidad.
Mantenga la propiedad de la clave o del certificado en el sitio y no en el operador del concentrador, para que un cambio de proveedor no se convierta en un cambio de identidad.
El prefijo es la parte que la gente olvida planificar. El concentrador tiene que asociar la subred del sensor con el par correcto, y el cliente del operador necesita una ruta hacia ella; una ruta que solo existe en el cliente envía tráfico a un túnel que lo descarta en silencio. Escriba el prefijo en el registro del sitio junto a la huella de la clave, para que una puerta de enlace de reemplazo no pueda aparecer con una cobertura distinta sin que nadie lo note.
La dirección del sensor pertenece a la aplicación
Una dirección privada del plan del sitio es suficiente, y lo que necesita es estabilidad y no accesibilidad pública: una reserva DHCP, una asignación estática o un nombre en la zona propia del sitio. Si el dispositivo no se puede renumerar, la traducción en la puerta de enlace del sitio es una respuesta legítima siempre que la traducción esté documentada y el tráfico de retorno la siga.
Otra costumbre que vale la pena mantener: nunca pegue la dirección pública del concentrador en un campo de siguiente salto en el host del sensor. La VPN instala su propia ruta, y una adyacencia Ethernet ordinaria con un extremo público es una ficción que produce una configuración de apariencia convincente.
Las respuestas son la mitad que se omite. El dispositivo tiene que enviar su respuesta de vuelta hacia el túnel, ya sea por una ruta al cliente del operador o por la misma puerta de enlace que tradujo la petición. Un sensor con la puerta de enlace predeterminada equivocada acepta la petición y responde al vacío, y las notas de reenvío explican por qué la llegada y el enrutamiento de la respuesta son dos requisitos y no uno.
Decida y luego escriba el límite
Escriba el límite de acceso antes de que alguien se conecte. Restrinja la puerta de enlace al segmento de IoT y a los servicios concretos que el operador necesita, porque una ruta que funciona tiende a convertirse en acceso general por accidente. Mantenga la supervisión de solo lectura y la autoridad de configuración como roles separados con identidades separadas, y nombre a la persona que retira el acceso cuando termina el contrato.
La aprobación pertenece al propietario de la red, y estar en una DMZ no es una política de acceso.
La prueba después del despliegue es aburrida y concluyente: una petición dentro del prefijo permitido que tiene éxito, un contador que se incrementa en la puerta de enlace y un intento deliberado fuera del prefijo que falla.