Zonas de Shorewall para los dos caminos de paquetes de OpenVPN
Separe el transporte cifrado de OpenVPN del tráfico de cliente descifrado, dé al túnel su propia zona y permita solo el servicio que el cliente necesita.
Dos flujos de paquetes cruzan una puerta de enlace Shorewall que termina OpenVPN, y solo uno de ellos va cifrado. El primero es el transporte del cliente hasta el oyente de VPN en la interfaz orientada a internet. El segundo es la petición descifrada que sale de la interfaz del túnel hacia un servidor de oficina o un servicio en la puerta de enlace. Dibuje ambos antes de editar la política, porque una regla que satisface el primero no hace nada por el segundo.
Dibuje los dos flujos antes de editar la política
Escriba los flujos como filas con origen, destino, protocolo y puerto. En el camino exterior, el origen es la dirección pública del cliente y el destino es el puerto del oyente de la puerta de enlace; Shorewall lo trata como tráfico de internet al cortafuegos. En el camino interior, el origen es el rango de direcciones del túnel y el destino es el servicio aprobado. Las dos filas tienen propietarios distintos incluso cuando un solo administrador mantiene ambas.
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
Añada una fila solo si la petición termina en la propia puerta de enlace, como el acceso al resolutor o a la administración. Un servicio en el host sigue la política de entrada del host, no el camino reenviado. Mezclar ambos es como una regla estrecha del túnel acaba exponiendo una interfaz de administración.
Asigne la zona del túnel y el alcance de la interfaz
La zona del viajero se declara en /etc/shorewall/zones, la interfaz del túnel se asocia en /etc/shorewall/interfaces y la conexión exterior se describe en /etc/shorewall/tunnels. Ajústese a la sintaxis de la versión instalada, porque el orden de las columnas y los nombres de las opciones han cambiado entre versiones principales. El puerto de ejemplo de la guía no es motivo para permitir un puerto distinto del que el demonio escucha realmente. TCP y UDP no son intercambiables solo porque los números coincidan.
La guía agrupa las interfaces con tun+. En un host con más de un túnel, ese comodín puede colocar una segunda VPN de distinto nivel de confianza en la misma zona. Revise el alcance frente a las interfaces que existen realmente y mantenga el nombrado bajo el ciclo de vida del gestor de conexiones en lugar de editar los nombres de las interfaces a mano.
La guía histórica contiene muestras de configuración de OpenVPN mucho más antiguas, y sus consejos criptográficos no deben copiarse en un despliegue actual. Tome prestado en su lugar el modelo de zonas y flujos. Tome la base criptográfica de la política de OpenVPN mantenida en la puerta de enlace.
Permita solo el camino que ha clasificado
Una aceptación amplia de la zona VPN a la LAN es un esquema inicial, no una política terminada. Escriba el origen de cliente permitido, la dirección real del servicio, el protocolo y el puerto. Después lea las reglas que hay por encima y el valor por defecto de la zona, porque una adición estrecha no cancela un permiso amplio que ya coincide. El tráfico hacia el host de la puerta de enlace es una relación distinta del tráfico reenviado a través de ella.
El tráfico entre clientes necesita su propia decisión. El client-to-client de OpenVPN y el routeback de Shorewall afectan ambos a si los clientes pueden alcanzarse, y ninguno debería activarse solo para que funcione una aplicación de LAN. Decida dónde se aplica el aislamiento antes de probarlo.
Mantenga el camino de respuesta en el mismo plan. El servicio o su enrutador debe saber cómo devolver el tráfico al rango del túnel, o el diseño debe traducir el origen de forma deliberada y dentro del alcance previsto.
Valide y luego demuestre ambos caminos
Valide la configuración antes de reiniciar nada y mantenga abierta una sesión administrativa independiente por si la nueva política es incorrecta.
shorewall checkTras una comprobación limpia, aplique la configuración y relea lo que Shorewall ha cargado. Esas lecturas describen la política en ejecución y no lo que un archivo parece decir.
shorewall show zones
ip route get 192.168.10.20Pruebe una petición permitida nueva y una petición denegada a propósito desde el mismo cliente. Un protocolo de enlace de OpenVPN correcto solo demuestra el intercambio exterior; el servicio permitido y el recurso denegado demuestran la política interior que pretendía. Después reconecte el cliente y repita, porque el nombre y la dirección de la interfaz del túnel pueden cambiar entre sesiones. Si el resultado difiere, corrija el alcance de la zona en lugar de ampliar la regla.