¿Una sola URL para la oficina y la VPN? Por qué falla el mito de la lista de permitidos

Conecte el túnel, abra el mismo marcador y el sitio permitido responde exactamente como lo hacía desde la oficina. Esa es la suposición sobre la que descansan en silencio la mayoría de los planes de acceso remoto, y solo se sostiene mientras tres cosas separadas siguen siendo ciertas a la vez. Ninguna de ellas es una función del cliente VPN, y ningún registro DNS puede aportar ninguna. Cuando el marcador falla en casa, el navegador le da un error genérico, ya sea la causa una ruta ausente, una dirección de salida no aprobada o un proxy que sustituyó el origen que informa. Tratar esas tres como un solo problema es como una pequeña corrección de política se convierte en una semana de ampliar listas de permitidos.

El diseño que sobrevive al contacto con una red de oficina real es más estrecho que la suposición: una tabla de decisión explícita de tres filas, un punto de aplicación que no se puede eludir y una prueba de denegación que demuestra algo. Desmontar la suposición va primero, porque todo lo que sigue depende de saber qué capa representa mal el origen.

El mito: conectar no es enrutar

Se establece un túnel y el cliente instala rutas para cierto conjunto de prefijos. Eso es todo lo que hace conectar. Si una petición HTTPS ajena viaja por el túnel y de qué dirección pública parece venir al llegar son decisiones que toman después otros componentes: la tabla de rutas elige el camino y la salida elige el origen.

Por eso la oficina y la mesa de la cocina divergen con el mismo portátil, el mismo perfil de navegador y el mismo marcador. En la oficina la petición sale por una dirección pública mantenida con la que el operador del sitio ha aceptado. Por un túnel completo puede salir por la salida VPN, que es otra dirección y, hasta que alguien la añada, no aprobada. Por un túnel dividido puede que nunca entre en el túnel. Solo dos de esos tres caminos formaron parte alguna vez del acuerdo con el propietario del sitio, y el tercero no es un defecto que haya que parchear con una entrada allow extra.

Tres estados de petición, dos salidas aprobadas

Escriba la matriz antes de tocar un cortafuegos, porque la tabla es el diseño y la regla solo una implementación suya. Las direcciones de abajo son rangos de documentación; sustitúyalas por sus propios valores mantenidos y guárdelas donde el propietario del sitio pueda auditarlas.

La fila central es donde se rompen la mayoría de estos planes. Lo que cuenta es la dirección que observa el dispositivo de aplicación, no la dirección privada que el portátil tiene dentro del túnel ni su dirección LAN. Un valor como 10.8.0.6 no significa nada para un sitio público, y 192.168.1.44 tampoco. La dirección del túnel es un detalle de direccionamiento del túnel, no una credencial que el sitio pueda comprobar.

Si su VPN no puede ofrecer una salida estable y documentada, la matriz no tiene fila central válida y ninguna cantidad de listas de permitidos inventará una. Las opciones honestas en ese punto son un sitio privado alcanzado por rutas privadas explícitas o una pasarela de acceso consciente de la identidad delante de la aplicación. Ambas tienen un contrato distinto del de una lista pública de permitidos, y ambas son más fáciles de explicar a un auditor que una lista que creció hasta que ocurrió funcionar.

Lea el origen donde se toma la decisión

Ponga la restricción en el dispositivo que termina la petición y confirme que ningún camino de origen alternativo la salta. El módulo de acceso de Nginx evalúa las directivas allow y deny en orden, gana la primera coincidencia, y las reglas heredadas de un bloque envolvente siguen aplicándose dentro de location. Un allow estrecho junto a un allow amplio en el mismo sitio suele significar que decide el amplio. Lea toda la configuración efectiva de ese location antes de editar una sola de sus líneas.

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

Detrás de un balanceador de carga o un proxy inverso, esa regla ve el proxy salvo que le diga lo contrario. Restaure la dirección del llamante solo mediante el mecanismo de proxy de confianza admitido, con una lista explícita de direcciones de proxy. Una cabecera de petición que afirma una dirección aprobada no es prueba de que el llamante la posea, y en un oyente público una cabecera reenviada sin validar convierte la lista de permitidos en adorno.

Luego revise la otra familia de direcciones. Un conjunto de reglas que solo cubre IPv4 es una decisión incompleta para un nombre de host que también responde en AAAA, y un cliente con IPv6 operativo llegará a la misma aplicación por un camino que usted nunca revisó.

Túnel dividido: la petición que nunca entra

Un túnel dividido solo transporta los prefijos de su lista. Las subredes internas de la oficina suelen estar en esa lista; un sitio web público no. El navegador resuelve el nombre, compara la dirección elegida con la tabla de rutas y aun así encuentra la pasarela local por defecto delante.

Así la petición llega desde la conexión doméstica del usuario, se rechaza, y el informe dice que la VPN está rota mientras el túnel hace exactamente aquello para lo que se configuró. Hay dos correcciones legítimas: encamine ese destino por el túnel y deje que la salida aprobada lo transporte, o acepte que el sitio se alcanza directamente y dé a los usuarios remotos otra ruta aprobada, como la pasarela de acceso. Ampliar la lista pública de permitidos del sitio hasta que por casualidad se incluya una dirección doméstica no es ninguna de las dos, y elimina la frontera que el diseño debía imponer. Las dos primeras mantienen la matriz honesta; la tercera borra en silencio una fila.

Demuestre la denegación y luego la recuperación

Pruebe con una petición que ejerza la decisión real, desde un cliente situado en cada fila de la tabla. Una comprobación de accesibilidad contra alguna página ajena que informe de la dirección no demuestra nada, porque ese destino puede seguir un camino distinto del de la aplicación.

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

Compare el registro de acceso de la frontera con lo que la tabla predijo. Luego baje el túnel y haga una petición nueva que debería ser rechazada; una página ya cargada o una conexión ya abierta no prueba absolutamente nada. Si no aparece ninguna denegación, el punto de aplicación no está donde usted cree.

Mantenga la autenticación de la aplicación tras la admisión en la red, porque una salida de oficina y una salida VPN representan cada una a muchas personas y ninguna identifica a un individuo. La instrucción para los usuarios sigue siendo corta: levante el túnel aprobado y vuelva a intentarlo. Eso es lo que mantiene una URL cómoda mientras la regla de origen sigue siendo una decisión y no una conjetura.