¿Qué debería registrar realmente un registro de direcciones de salida VPN?
Un registro de salidas solo es útil si cada entrada declara su significado, su editor y su caducidad. La clasificación no es la identificación del suscriptor.
Los registros de salida suenan a listas, y la lista no es la parte difícil. La parte difícil es decidir qué afirma cada entrada, quién puede publicarla y qué ocurre cuando la afirmación deja de ser cierta. En estas propuestas se confunden tres roles de dirección distintos, y un registro que los mezcla no puede responder ninguna pregunta de forma fiable. Siga una entrada desde la publicación hasta la retirada y los requisitos de diseño aparecerán por sí solos.
Empiece por el registro, no por la lista
La primera pregunta no es cuántas direcciones incluir, sino qué significa una sola fila. ¿Describe dónde se conectan los clientes, qué origen puede ver un destino o quién posee una asignación en un registro? Son tres afirmaciones con tres propietarios y tres modos de fallo. Un registro que no indica cuál de ellas registra no puede validarse, corregirse ni caducarse. Acertar el significado es el trabajo de diseño, y la lista solo es el resultado.
Escriba la definición de la fila antes de escribir cualquier esquema. Si la definición necesita la palabra y, probablemente sean dos registros que fingen ser uno.
Tres roles de dirección que se parecen
Los roles son fáciles de confundir porque un despliegue puede usar los tres a la vez, y a menudo lo hace. Un servicio puede terminar conexiones en una dirección y reenviar tráfico desde otra, mientras que un registro anota un tercer hecho completamente distinto.
| Address role | Who may publish | What it does not prove | Withdrawal trigger |
|---|---|---|---|
| Forwarded exit | The operator that forwards the traffic, or a feed it authorizes | That a subscriber is behind the address, or that all its traffic is tunnelled | The address stops forwarding for that operator, or the prefix is reassigned |
| Registered allocation | The registry, or the holder of the allocation | That the resource is used as a VPN exit, or which application uses it | The allocation is returned, transferred, or the holder changes |
| Tunnel entry | The operator that terminates the tunnel | That traffic exits from the same address, or that the client is a subscriber | The endpoint is decommissioned or its address changes |
Un bloque de alojamiento puede contener salidas VPN y cargas de trabajo no relacionadas uno al lado del otro, así que una coincidencia en el registro no dice nada sobre lo que hace una dirección concreta en un momento concreto. Una entrada que no nombra su rol no es prueba de nada en particular. Nombrar el rol es lo que hace refutable el registro. Indique también la familia de direcciones, porque un registro que solo cubre IPv4 en silencio engañará a cualquiera que suponga lo contrario.
Siga una entrada desde la publicación hasta la retirada
Tome una salida hipotética y sígala. Un operador publica el prefijo y su rol en un momento de entrada en vigor declarado, los consumidores lo obtienen y, más tarde, la dirección deja de servir como salida. Cada paso necesita una regla: quién puede publicar, qué cubre realmente el prefijo, cuándo entra en vigor la entrada y cómo se retira. Un feed sin ruta de retirada acumula afirmaciones obsoletas que nadie puede distinguir de las actuales.
Separe la autoridad para publicar de la exactitud de la etiqueta. Un registro que vincula una organización con un recurso demuestra la asignación y no el uso actual, y son afirmaciones distintas con pruebas distintas. Los consumidores necesitan saber en cuál de las dos confían.
Defina también la corrección. Una dirección reasignada a un cliente, o un servicio no relacionado atrapado por una etiqueta incorrecta, necesita una ruta documentada hacia una solución en lugar de una discusión en una cola de tiquetes. El detonante de la retirada pertenece al mismo documento que la regla de publicación.
Qué puede y qué no puede respaldar un feed publicado
Los atributos de prefijo publicados son un patrón consolidado, y los ejemplos existentes describen geografía o propiedad en lugar de comportamiento. Un feed VPN necesitaría su propia semántica, sus propias reglas de prueba y su propio proceso de revisión, y renombrar una lista de países no aporta nada de eso. La guía del registro de ARIN muestra qué afirman y qué no los registros de asignación, y un feed nuevo tiene que ganarse la misma claridad sobre sus propias afirmaciones. Esa es una tarea de especificación, no de reetiquetado.
Lo que un feed así puede respaldar es una decisión de clasificación sobre un origen de red. Lo que no puede hacer es identificar a una persona detrás de una dirección compartida, demostrar que todo el tráfico de esa dirección va por un túnel o decidir si una petición concreta es abusiva. Son tres preguntas separadas con tres requisitos de prueba separados.
Mantenga la cuestión legal fuera de la especificación
Una especificación técnica no puede resolver si un requisito de registro propuesto es legal, proporcionado o sensato. Esa evaluación necesita el texto legislativo real, los derechos afectados, la jurisdicción y un análisis jurídico que un formato de datos no puede aportar. Un formato puede estar bien diseñado y aun así respaldar una mala política.
Lo que la especificación puede hacer es concretar el debate. Defina primero los datos propuestos, sus límites y sus modos de fallo, para que el argumento político verse sobre un mecanismo real y no sobre una lista indefinida que cada participante imagina de forma distinta. Eso es lo máximo que un documento técnico puede aportar a una cuestión legal.