No adivines el prefijo de la oficina a partir de una sola dirección de servidor

Empieza por la dirección que te dieron y luego resiste la tentación de ampliarla a algo que parezca ordenado. Un servidor en 10.22.8.19 no dice nada sobre si la oficina posee 10.22.8.0/24, 10.22.0.0/16 o un puñado de /28s dispersos. Elegir 10.0.0.0/8 porque el número empieza por 10 captura redes domésticas, rangos de contenedores y enlaces de socios que no pretendías. El prefijo es una frontera que se obtiene, no que se deduce.

La longitud de un prefijo describe cuántos bits iniciales son significativos; no describe quién posee el rango.

Una dirección de servidor no es una red

Un servidor, una subred y una sede son tres cosas distintas. Un solo servicio puede estar en una subred pequeña y dedicada mientras el resto de la oficina ocupa rangos separados, y una ruta de host puede ser totalmente adecuada para un servicio que deliberadamente tiene una sola dirección. Deja de ser adecuada cuando la sede redirige a otro host, se autentica mediante un servidor aparte o cambia de dirección. Esas dependencias son el requisito real, y merece la pena preguntar por ellas antes de instalar cualquier prefijo.

Una calculadora de subredes traduce un prefijo conocido en una máscara, un rango o una lista de hosts. No puede inferir una frontera organizativa a partir de un solo nombre de host, y tratar su salida como autoridad es como redes no relacionadas acaban enrutadas.

Pide los prefijos aprobados

Obtén los rangos de destino de quien opere la VPN o la red. Puede haber varios prefijos distintos y un servidor DNS privado en otra ubicación, que a menudo se olvida hasta que fallan los nombres. Regístralos como una lista aprobada con un propietario y una fecha, no como un rango reconstruido a partir de un ejemplo. Si la lista es larga, es información sobre la red y no una invitación a resumirla en algo más amplio.

Una consulta de rutas de solo lectura en el Mac, dirigida al destino que te importa, muestra qué camino se está usando ahora mismo. Eso es comportamiento actual, no una autorización.

Comprueba el solapamiento antes de aplicar nada

Compara los prefijos aprobados con cada rango local antes de aplicarlos: LAN doméstica, puentes de contenedores, redes de máquinas virtuales y cualquier otra VPN. Una ruta precisa a la oficina todavía no puede decirte qué dispositivo de esa dirección querías cuando el mismo rango también existe localmente; la tabla no tiene ese concepto. El solapamiento produce síntomas que parecen servicios rotos más que errores de enrutamiento, y son difíciles de diagnosticar a posteriori.

Haz que el propietario que da soporte instale los prefijos, mediante la configuración del propio cliente o las rutas empujadas por el servidor, para que una reconexión los restablezca en lugar de depender de un comando que alguien escribió una vez.

Una ruta no es acceso

Enrutar un prefijo hacia el túnel no concede acceso a los servicios que hay dentro. La puerta de enlace debe permitir el tráfico, el destino debe aceptarlo y debe existir un camino de vuelta, y cada uno puede fallar con independencia de la ruta. Prueba un servicio previsto una vez colocada la ruta y luego confirma que un recurso no relacionado sigue rechazándose. Una ruta que llega a un cortafuegos no es lo mismo que una conexión que funciona.

Documenta la lista de prefijos, la comprobación de solapamiento y el propietario juntos. Cuando cambie una dirección, esos tres son lo que necesita la siguiente persona.

El prefijo es un acuerdo sobre fronteras. Trátalo así y la ruta dejará de ser una conjetura.