Cómo planificar un conjunto de direcciones de clientes VPN que encaje

Empiece en el campo del conjunto en el servidor VPN, no en una hoja de cálculo. Lo que escriba allí se convierte en el espacio de direcciones interno para cada cliente que se conecte después, y debe convivir con la LAN a la que llegan esos clientes, los sitios enrutados detrás de ella y cualquier dirección que el cliente ya tenga en casa. Conecte un cliente en cuanto se guarde el conjunto, porque esa primera conexión le dice si el valor funciona en la práctica. Desde ahí el recorrido avanza hacia fuera: la dirección que recibió el cliente, el camino que sigue una respuesta y el registro que deja atrás.

Empiece en el campo del conjunto, antes de que se conecte ningún cliente

Cada producto lo expone de forma distinta, así que encuentre el objeto que realmente asigna direcciones. OpenVPN tiene una directiva de conjunto del lado del servidor que reparte la siguiente dirección libre, una pasarela IKEv2 tiene una sección de conjunto ligada a la configuración del par, y WireGuard no tiene ninguna de las dos porque cada par lleva su propia dirección en su archivo de configuración. Una directiva de conjunto y una dirección por par no son intercambiables, y editar la incorrecta desperdicia el resto del recorrido.

Una vez tenga el campo, enumere los rangos que ya existen: la LAN de la oficina, cada sitio enrutado, la VPC de la nube y cualquier otro conjunto que siga en servicio. El solapamiento se decide por aritmética de prefijo, no por si los números de host parecen familiares, así que compare el agregado con cada uno de esos rangos. Dos rangos que ambos parecen 10.x son inofensivos cuando sus agregados no se cruzan y un incidente de soporte cuando se cruzan.

Luego decida si la dirección es función de quién se conecta o de cuándo se conecta. La asignación dinámica reparte lo que está libre, mientras que la asignación por identidad vincula una dirección fija a una credencial. Anote la elección, porque cambia cómo debe verse una reconexión más adelante.

Lea la dirección que el cliente recibió realmente

Conecte un cliente y lea lo que informa el túnel, no lo que prometió el conjunto. El cliente muestra su dirección interna en el estado de la conexión, y en Linux la interfaz la lleva directamente.

Compare esa dirección con el rango que guardó. Si está fuera del rango, está viendo una ruta de asignación distinta de la que editó. Compruebe también la longitud del prefijo, ya que un cliente con un /32 no tiene par en el enlace y envía cada destino por su ruta predeterminada.

ip -4 addr show tun0
ip route get 192.168.50.20

Un cliente que se conecta desde un router doméstico que usa el mismo rango se conectará y luego no alcanzará casi nada. El cliente conserva su ruta local para ese prefijo, así que la dirección del túnel choca con la red que hay detrás y el tráfico sale por la interfaz equivocada. Ese caso no se puede reparar en el servidor; el remedio documentado es renumerar la red doméstica o elegir un rango de conjunto lo bastante remoto para que las colisiones sigan siendo raras. Registre tanto el fallo como el remedio, porque el servicio de ayuda lo volverá a encontrar.

Vuelva a conectar el mismo cliente y observe la dirección. Un conjunto dinámico puede devolver el mismo valor o uno distinto y ambos son correctos, mientras que un conjunto por identidad que cambia la dirección no está respetando el vínculo. Esa comprobación tarda segundos y resuelve si el modo que anotó en la primera sección es el modo vigente.

Siga una respuesta de vuelta desde el servicio

El conjunto solo funciona cuando las respuestas pueden viajar de vuelta hacia él. Un servicio en la LAN responde a la dirección interna, así que su puerta de enlace necesita una ruta para el conjunto o una traducción delante del servicio. Cuando una petición llega por el túnel y la respuesta sale por un camino distinto, un cortafuegos con estado o una comprobación de ruta inversa la descarta, y el cliente ve un servicio que se conecta y luego se cuelga. Coloque el conjunto en el diseño de enrutamiento como un solo bloque resumible en lugar de añadir rutas por host.

La traducción cambia lo que ve el resto del sistema. Cuando se reescribe el origen, la dirección en el cortafuegos del host y en el registro de la aplicación es la traducida, así que una regla escrita contra la dirección del conjunto no coincide con nada y una línea de registro no se puede rastrear hasta un cliente. La documentación de reenvío de strongSwan cubre la mitad del lado del servidor de ese camino para una pasarela IKEv2. El DNS lleva la misma restricción, porque un nombre que se resuelve a una dirección que el cliente no puede alcanzar falla más tarde y en otro lugar.

Dos clientes, luego una revocación

Conecte dos clientes a la vez y lea ambas direcciones. Deben ser distintas, utilizables y estar dentro del conjunto, y cada una debe alcanzar el servicio al que está destinada. Un conjunto que reparte direcciones duplicadas suele mostrarse aquí y no en la primera prueba con un solo cliente.

Revoque una credencial mientras el otro cliente sigue conectado, luego pruebe el servicio desde el cliente que sobrevive. Una revocación que perturba la otra sesión apunta a estado compartido, muy a menudo una credencial o una dirección reutilizada entre dispositivos. Vuelva a conectar el cliente revocado y confirme que se le deniega en lugar de entregarle la dirección liberada.

Termine con un destino que debería denegarse. Un cliente que alcanza todo ha sido conectado, no probado.

Escriba los cuatro valores donde los encontrará el próximo cambio

El registro es corto: el rango y el prefijo del conjunto, el modo de asignación, el camino de vuelta o la traducción en uso y el alcance de DNS que responde por esos destinos. Póngalo junto a la configuración del servidor en lugar de en un ticket, y fírmelo con fecha. Quien cambie uno de los cuatro más adelante necesita los otros tres delante, porque un cambio de tamaño del conjunto rompe la ruta y un cambio de ruta rompe la respuesta DNS.

Guarde junto a él la nota de propiedad: el rango del túnel pertenece al servidor VPN, y una reserva hecha en el alcance DHCP de la LAN no reserva nada para un cliente dentro del túnel. Esa sola línea evita el retrabajo más común, en el que alguien añade una reserva y espera que la dirección del túnel la siga.