2 votos

Cómo abrir un puerto de servidor fuera de un túnel OpenVPN con un firewall pf en OSX (BSD)

Tengo un Mac mini que utilizo como servidor multimedia que ejecuta XBMC y sirve los medios de comunicación de mi NAS a mi equipo de música y TV (que ha sido calibrado el color con un Spyder3Express, feliz). El Mac ejecuta OSX 10.8.2 y la conexión a Internet está tunelizada para la privacidad general sobre OpenVPN a través de Tunnelblick. Creo que mi proveedor de VPN anónima empuja "redirect_gateway" a OpenVPN/Tunnelblick porque cuando está activada, efectivamente tunela todo el tráfico no-LAN de entrada y salida. Como un efecto secundario no deseado que también abre los puertos del servidor de cajas sin protección al mundo exterior y pasa por alto mi firewall-router (Netgear SRX5308). He ejecutado nmap desde fuera de la LAN en la IP de la VPN y los puertos del servidor en el mini son claramente visibles y conectables.

El mini tiene los siguientes puertos abiertos: ssh/22, ARD/5900 y 8080+9090 para el cliente XBMC iOS Constellation.

También tengo un NAS de Synology que, además de servir archivos en la LAN a través de AFP y WebDAV, sólo sirve un servidor OpenVPN/1194 y PPTP/1732 a la WAN. Cuando estoy fuera de la LAN me conecto a esto desde mi portátil a través de OpenVPN y a través de PPTP desde mi iPhone. Sólo quiero conectarme a través de AFP/548 desde el mini al NAS.

El cortafuegos de frontera (SRX5308) funciona de forma excelente, estable y con un rendimiento muy alto cuando se transmite desde varios servicios VOD. Mi conexión es un 100/10 con un rendimiento máximo cercano al teórico. El conjunto de reglas es el siguiente

Inbound:
PPTP/1723        Allow always to 10.0.0.40 (NAS/VPN server)
                 from a restricted IP range matching the cell phone provider range
OpenVPN/1194     Allow always to 10.0.0.40 (NAS/VPN server) from any

Outbound: Default outbound policy: Allow Always
OpenVPN/1194     TCP Allow always from 10.0.0.30 (mini) to a.b.8.1-a.b.8.254 (VPN provider)
OpenVPN/1194     UDP Allow always to 10.0.0.30 (mini) to a.b.8.1-a.b.8.254 (VPN provider)
Block always from 10.0.0.30 (mini) to any

En el Mini he desactivado el Firewall de Nivel de Aplicación de OSX porque lanza ventanas emergentes que no recuerdan mis elecciones de una vez a otra y eso es molesto en un servidor de medios. En su lugar, ejecuto Little Snitch, que controla muy bien las conexiones salientes a nivel de aplicación. He configurado el excelente firewall incorporado en OSX pf (de BSD) como sigue

pf.conf (Se eliminan los vínculos con el cortafuegos de aplicaciones de Apple)

### macro names for external interface.
eth_if = "en0"
vpn_if = "tap0"
### wifi_if = "en1"
### %usb_if = "en3"

ext_if = $eth_if

LAN="{10.0.0.0/24}"

### General housekeeping rules ###
### Drop all blocked packets silently
set block-policy drop

### all incoming traffic on external interface is normalized and fragmented
### packets are reassembled.
scrub in on $ext_if all fragment reassemble
scrub in on $vpn_if all fragment reassemble

scrub out all

### exercise antispoofing on the external interface, but add the local
### loopback interface as an exception, to prevent services utilizing the
### local loop from being blocked accidentally.
### set skip on lo0
antispoof for $ext_if inet
antispoof for $vpn_if inet

### spoofing protection for all interfaces
block in quick from urpf-failed

#############################

block all

### Access to the mini server over ssh/22 and remote desktop/5900 from LAN/en0 only
pass in on $eth_if proto tcp from $LAN to any port {22, 5900, 8080, 9090} 

### Allow all udp and icmp also, necessary for Constellation. Could be tightened.
pass on $eth_if proto {udp, icmp} from $LAN to any

### Allow AFP to 10.0.0.40 (NAS)
pass out on $eth_if proto tcp from any to 10.0.0.40 port 548

### Allow OpenVPN tunnel setup over unprotected link (en0) only to VPN provider IPs
### and port ranges
pass on $eth_if proto tcp from any to a.b.8.0/24 port 1194:1201 

### OpenVPN Tunnel rules. All traffic allowed out, only in to ports 4100-4110 (rtorrent)
### Outgoing pings ok
pass in on $vpn_if proto {tcp, udp} from any to any port 4100:4110
pass out on $vpn_if proto {tcp, udp, icmp} from any to any 

Entonces, ¿cuáles son mis objetivos y qué consigue la configuración anterior? (hasta que me digan lo contrario :)

1) Acceso total de la LAN a los puertos mencionados en el mini/servidor multimedia (incluso a través de mi propio servidor VPN) 2) Todo el tráfico de Internet desde el mini/servidor multimedia es anónimo y se tuneliza a través de la VPN

3) Si OpenVPN/Tunnelblick en el mini cae la conexión, no se filtra nada tanto por pf como por el conjunto de reglas de salida del router. Ni siquiera puede hacer una búsqueda de DNS a través del router.

¿Qué tengo que ocultar con todo esto? En realidad no mucho, sólo me dejé llevar por el intento de detener los escaneos de puertos a través del túnel VPN :)

En cualquier caso esta configuración funciona perfectamente y es muy estable.

¡El problema por fin!

Me gustaría ejecutar un servidor de minecraft y lo instalé en una cuenta de usuario separada en el mini servidor (user=mc) para mantener las cosas divididas. No quiero que este servidor sea accesible a través del túnel VPN anónimo porque hay muchos más escaneos de puertos e intentos de hacking a través de eso que a través de mi IP regular y además no confío en java en general. Así que añadí la siguiente regla pf en el mini:

### Allow Minecraft public through user mc
pass in on $eth_if proto {tcp,udp} from any to any port 24983 user mc
pass out on $eth_if proto {tcp, udp} from any to any user mc

And these additions on the border firewall:
Inbound: Allow always TCP/UDP from any to 10.0.0.30 (mini with mc server)
Outbound: Allow always TCP port 80 from 10.0.0.30 to any (needed for online account checkups)

Esto funciona bien, pero sólo cuando el túnel OpenVPN/Tunnelblick está caído. Cuando está levantado no es posible la conexión con el servidor de minecraft desde fuera de la LAN, el acceso dentro de la LAN siempre está bien. Todo lo demás funciona como está previsto. Creo que el empuje redirect_gateway podría estar cerca de root del problema, pero quiero mantener ese proveedor de VPN específica debido a la fantástica rendimiento, el precio y el servicio.

¿La solución?

¿Cómo puedo abrir el puerto del servidor de minecraft fuera del túnel para que sólo esté disponible a través de en0 y no del túnel VPN?

¿Debo utilizar una ruta estática? Pero no sé qué IPs de la WAN se conectarán... tropieza

¿Qué grado de seguridad estimas que tiene esta configuración y tienes otras mejoras que compartir?

-1voto

pawneebill Puntos 31

Este artículo -- Parece responder a su pregunta principal. Explica cómo se puede ignorar el Redirect_Gateway Push de su ISP.

Ignorar redirect-gateway

Si está ejecutando OpenVPN como cliente, y el servidor que utiliza está usando push " redirect-gateway ", entonces su cliente redirige todo el tráfico de Internet a través de la VPN. A veces los clientes no quieren esto, pero no pueden cambiar la configuración del servidor. Esta página explica cómo anular redirect-gateway para que el cliente no tenga que redirigir internet aunque el servidor lo diga.

Método 1: ignorar

Hay dos opciones que se pueden utilizar para ignorar las rutas enviadas por el servidor:

--route-noexec

No añadir o eliminar rutas automáticamente. En su lugar, pasa las rutas a --route-up script utilizando variables de entorno.

 --route-nopull

Cuando se utiliza con --client o --pull aceptar las opciones empujadas por el servidor EXCEPTO las rutas y las opciones dhcp como los servidores DNS. Cuando se utiliza en el cliente, esta opción impide efectivamente que el servidor añada rutas a la tabla de enrutamiento del cliente, sin embargo, tenga en cuenta que esta opción todavía permite al servidor establecer las propiedades TCP/IP de la interfaz TUN/TAP del cliente.

Método 2: anulación

Aquí simplemente añadiremos rutas que anulen --redirect-gateway . Esto funcionará como el def1 flag a --redirect-gateway obras. Esto puede ser diferente si el servidor utiliza el def1 a la flag --redirect-gateway o no (comprobando el registro mientras se conecta). Tenga en cuenta que net_gateway es una variable interna de openvpn y no necesita ser cambiada por nada. Si no sabe si su servidor utiliza def1 y no quieren comprobar los registros para averiguarlo, simplemente asumen que SI usan def1 y utilizar las 4 rutas. Eso funcionará sea como sea.

def1 -- Utilice esta flag para anular la puerta de enlace por defecto utilizando 0.0.0.0/1 y 128.0.0.0/1 en lugar de 0.0.0.0/0 . Esto tiene la ventaja de anular pero no borrar la puerta de enlace original por defecto. Si el servidor NO utiliza def1 añada las siguientes opciones a la configuración de los clientes:

route 0.0.0.0 128.0.0.0 net_gateway
route 128.0.0.0 128.0.0.0 net_gateway

Si el servidor SÍ utiliza def1 o si no lo sabe, añada las siguientes opciones a la configuración de los clientes:

route 0.0.0.0 192.0.0.0 net_gateway
route 64.0.0.0 192.0.0.0 net_gateway
route 128.0.0.0 192.0.0.0 net_gateway
route 192.0.0.0 192.0.0.0 net_gateway

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: