Un único extremo VPN a través de Squid: una excepción estrecha de CONNECT

Squid responde a una solicitud CONNECT con la primera línea http_access que coincide, y esa línea puede ser una denegación. Este único hecho explica por qué una excepción para un extremo VPN suele fallar al primer intento, porque la solicitud nunca llega al permiso que alguien añadió al final. Una corrección estrecha conserva las protecciones de puerto existentes y les enseña una fuente, un destino y un puerto revisados. Todo lo demás en el proxy se comporta exactamente como antes.

Cómo decide Squid una solicitud CONNECT

Una solicitud CONNECT nombra un host y un puerto, y Squid recorre las líneas http_access en orden hasta que una coincide. Una denegación coincidente termina la evaluación de inmediato y el cliente recibe un 403 del proxy. Por eso la posición de una regla importa más que su redacción. Mover la misma línea un paso hacia arriba puede cambiar por completo el resultado.

Las protecciones convencionales deniegan todo lo que queda fuera de Safe_ports y deniegan CONNECT fuera de SSL_ports. Esos nombres son ACL definidas en su propia configuración, así que su contenido es suyo y no del protocolo. Una distribución puede permitir un intervalo amplio de puertos como Safe_ports mientras restringe CONNECT por separado. Lea los valores vivos antes de suponer que un puerto está bloqueado por diseño.

Confirme que el proxy es el componente que rechaza la solicitud. Un 403 generado por Squid no se parece en nada a una alerta TLS del servidor VPN, y fusionar ambos en un solo problema cuesta la primera hora. Revise la línea del registro de acceso de la solicitud, porque registra tanto la acción como la regla que la produjo.

Construya una coincidencia combinada en lugar de tres ACL sueltas

Construya la excepción a partir de tres hechos: un rango de origen aprobado, una dirección de destino aprobada y el único puerto en el que escucha el extremo. Dos ACL sueltas y una coincidencia combinada producen una política muy distinta, porque lo que se evalúa es la combinación. Nombre la ACL combinada por lo que permite, no por el método que lleva.

La forma de abajo usa rangos de documentación que deben sustituirse por valores revisados. Squid no reserva ninguno de estos nombres, así que son suyos para elegirlos y suyos para mantenerlos coherentes. Esta receta está acotada a Squid 6 y 7, cuya configuración documentada admite el grupo all-of. La referencia actual marca esas directivas como no disponibles en Squid 8, así que trátelo como una receta ligada a una versión y no como una ruta de migración, y compruebe la directiva en la referencia de su propia versión antes de aplicarla.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

El grupo all-of coincide solo cuando coincide cada miembro, lo que significa que origen, destino y puerto se comprueban en una sola línea. El grupo no concede nada por sí mismo, y una solicitud que solo coincide con dos de los tres hechos no puede satisfacerlo. Esa propiedad mantiene la excepción estrecha cuando alguien añade después una segunda puerta de enlace. O bien el nuevo destino se añade a propósito, o bien la solicitud vuelve a las protecciones originales.

Flexione las protecciones de puerto sin eliminarlas

En sus posiciones actuales, las dos líneas de protección convencionales se ven así. Suelen situarse después de la autenticación y antes de las líneas de política que lo permiten todo.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Añada la coincidencia combinada negada a cada una, de modo que una excepción coincidente sobreviva a una protección que de otro modo la denegaría. Solo cambian las líneas de protección, y solo con un término adicional cada una.

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

Los términos de una línea de acceso se combinan, así que la línea ahora solo deniega las solicitudes que fallan tanto la comprobación original como la excepción. Una solicitud para el extremo aprobado pasa, y cualquier otra solicitud conserva el comportamiento antiguo del puerto. Esto es más estrecho que añadir el puerto a una lista global SSL_ports, lo que permitiría ese puerto a cualquier destino. Si el puerto ya está en esa lista, esta ACL no estrecha nada y el permiso más antiguo y amplio sigue aplicándose a otros destinos, así que lea la lista viva antes de afirmar que la excepción abrió el puerto. También es reversible, porque dos líneas vuelven a su forma anterior. La referencia de control de acceso documenta el orden y las protecciones convencionales de las que depende este cambio.

Dónde no debe colocarse la excepción

La tentación es poner un permiso por encima de las protecciones y darse por terminado. Esa colocación también se salta las protecciones de autenticación y de destino local que suelen estar cerca de la parte superior de una configuración operativa. El resultado no es una excepción estrecha, es un agujero con un comentario encima. Mantenga cualquier permiso nuevo en la misma etapa revisada que el resto de la política de clientes.

Compruebe qué necesita aún la solicitud después de las protecciones de puerto. Una cuenta autenticada, una dirección de cliente permitida y una política de destino siguen aplicándose, y la excepción no cambia ninguna de ellas. Si su proxy ya deja que la cuenta aprobada llegue a destinos arbitrarios, la protección de puerto nunca fue el control real.

Piense si el extremo es TCP siquiera. Una excepción CONNECT transporta flujos TCP, y un perfil de OpenVPN que use UDP no se volverá alcanzable a través de ella. Cambie el perfil a TCP solo si el servidor escucha así y el operador acepta la diferencia de comportamiento.

Compruebe el límite con el analizador y una solicitud real

Analice la configuración antes de recargar, y mantenga una segunda sesión abierta mientras lo hace. Un error de sintaxis al recargar puede dejar el proxy en la configuración antigua o rechazar la nueva de plano. El analizador informa de la línea rechazada, lo que es más de lo que le dirá el error del cliente.

Luego recargue y envíe una CONNECT real a través del proxy desde una fuente aprobada. La ejecución del analizador va primero, porque una recarga con una errata no le enseña nada sobre la política.

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

Pruebe tres casos: una fuente y una cuenta aprobadas, una fuente no aprobada y un destino distinto en el mismo puerto. El tercer caso es el que demuestra que la excepción es estrecha, porque ejercita el puerto sin la coincidencia de destino. Lea el registro de acceso para los tres en lugar de confiar en el mensaje del cliente. Una CONNECT correcta establece un flujo TCP y nada más, así que el handshake de VPN sigue siendo una prueba aparte.