19 votos

Prevenir el tráfico saliente a menos de OpenVPN conexión se activa el uso de pf.conf en Mac OS X

He sido capaz de denegar todas las conexiones a redes externas, a menos que mi conexión OpenVPN se activa el uso de pf.conf. Sin embargo, voy a perder la conectividad Wi-Fi si la conexión se ha interrumpido por el cierre y la apertura de la tapa de la laptop o activando Wi-Fi apagado y encendido de nuevo.

  • Estoy en Mac OS 10.8.1.
  • Me conecto a la Web a través de Wi-Fi (de distintos lugares, incluyendo los cafés Internet).
  • El OpenVPN que se configure la conexión con la Viscosidad.

Tengo el siguiente conjunto de reglas de filtrado de paquetes en /etc/pf.conf

# Deny all packets unless they pass through the OpenVPN connection
wifi=en1
vpn=tun0

block all

set skip on lo
pass on $wifi proto udp to [OpenVPN server IP address] port 443
pass on $vpn

Empiezo el filtro de paquetes de servicio con sudo pfctl -e de carga y las nuevas reglas sudo pfctl -f /etc/pf.conf.

También he editado /System/Library/LaunchDaemons/com.apple.pfctl.plist y cambió la línea <string>-f</string> lectura <string>-ef</string> , de modo que el filtro de paquetes lanza en el inicio del sistema.

Todo esto parece que funciona muy bien en la primera: las aplicaciones sólo se pueden conectar a la web si la conexión OpenVPN está activo, así que yo nunca voy a fugas de datos a través de una conexión insegura.

Pero, si he de cerrar y volver a abrir mi la tapa de la laptop o desactivar Wi-Fi y de nuevo, la conexión Wi-Fi está perdido, y veo un signo de exclamación en el icono de Wi-Fi en la barra de estado. Hacer clic en el icono de Wi-Fi muestra una "Alerta: No hay conexión a Internet" mensaje:

No Internet connection message

Para recuperar la conexión, tengo que desconectar y volver a conectar el Wi-Fi, a veces cinco o seis veces, antes de la "Alerta: No hay conexión a Internet" mensaje desaparece y yo soy capaz de abrir la conexión VPN de nuevo. Otras veces, el Wi-Fi de alerta desaparece de su propio acuerdo, el signo de exclamación se borra, y yo soy capaz de conectar de nuevo. De cualquier manera, se puede tomar de cinco minutos o más para obtener una conexión de nuevo, lo cual puede ser frustrante.

La eliminación de la línea block all resuelve el problema (pero permite conexiones inseguras), así que parece que hay un servicio que yo soy el bloqueo que Apple necesita para recuperar y confirmar una conexión Wi-Fi. He intentado:

  • La habilitación de icmp agregando pass on $wifi proto icmp all a pf.conf
  • La habilitación de la resolución de DNS mediante la adición de pass on $wifi proto udp from $wifi to any port 53
  • Tratando de aprender más por el registro de los paquetes bloqueados (cambiando block all a block log all), pero el registro parece estar deshabilitado en OS X, ya que de sudo tcpdump -n -e -ttt -i pflog0 para ver el registro de los resultados en "tcpdump: pflog0: No existe el dispositivo existe".

Nada de esto ayuda a re-establecer una conexión Wi-Fi más rápido.

¿Qué más puedo hacer para determinar qué servicio debe estar disponible para recuperar la conectividad Wi-Fi, o lo que la regla debería añadir a la pf.conf para hacer la conexión Wi-Fi gratuita reconexiones más fiable?

14voto

tim Puntos 504

Por la red de monitoreo de conexiones con Little Snitch, me he encontrado con que Apple utiliza el mDNSResponder aplicación en segundo plano para comprobar si la conexión Wi-Fi está disponible. mDNSResponder envía paquetes UDP a los servidores de nombres para comprobar la conectividad y resolver nombres de host a direcciones ip.

El cambio de la UDP regla tuve anteriormente para permitir que todos los paquetes UDP a través de Wi-Fi permite a los mDNSResponder para conectarse, lo que significa que la conexión Wi-Fi gratuita ahora se vuelve a conectar por primera vez después de una desconexión. En caso de que ayuda a otros en el futuro, mi final pf.conf incluyendo el Apple reglas predeterminadas para el León de la Montaña se parece a esto:

#
# com.apple anchor point
#
scrub-anchor "com.apple/*"
nat-anchor "com.apple/*"
rdr-anchor "com.apple/*"as
dummynet-anchor "com.apple/*"
anchor "com.apple/*"
load anchor "com.apple" from "/etc/pf.anchors/com.apple"

#
# Allow connection via Viscosity only
#
wifi=en1 #change this to en0 on MacBook Airs and other Macs without ethernet ports
vpn=tun0
vpn2=tap0

block all

set skip on lo          # allow local traffic

pass on p2p0            #allow AirDrop
pass on p2p1            #allow AirDrop
pass on p2p2            #allow AirDrop
pass quick proto tcp to any port 631    #allow AirPrint

pass on $wifi proto udp # allow only UDP packets over unprotected Wi-Fi
pass on $vpn            # allow everything else through the VPN (tun interface)
pass on $vpn2           # allow everything else through the VPN (tap interface)

Esto significa que los datos pueden ahora ser filtrado a través de Wi-Fi por un pequeño número de aplicaciones que utilizan el protocolo UDP, por desgracia, tales como ntpd (para la sincronización de tiempo) y mDNSResponder. Pero esto parece aún mejor de lo que permite que los datos lleguen sin protección a través de TCP, que es lo que la mayoría de las aplicaciones de uso. Si alguien tiene alguna sugerencia para mejorar esta configuración, comentarios o más respuestas son bienvenidos.

11voto

smashingly Puntos 103

Usted no necesita para permitir que todos UDP. La 'm' en el mDNS significa "multidifusión", y se utiliza un multidifusión específica dirección IP de destino se llama el "enlace local de la dirección de multidifusión", y un UDP el número de puerto 5353.

Esto significa que en la solución anterior, que innecesariamente se permite el tráfico a todos los 65535 puertos UDP para todos los 3.7 mil Millones de direcciones IP enrutables en el mundo para la derivación de su VPN. Usted se sorprendería de la cantidad de aplicaciones que utilizan UDP, por lo que son significativamente derrotando el propósito de su original idea para evitar el tráfico de salida cuando el VPN es hacia abajo.

Por qué no utilizar esta regla en su lugar:

pass on $wifi proto udp to 224.0.0.251 port 5353

Una regla muy importante del pulgar con la configuración del firewall - al hacer excepciones a través de su firewall, siempre trate de usar la regla más específica posible. La especificidad viene a veces a expensas de la comodidad y la facilidad de uso, es decir, usted podría encontrar que hay algunos otros locales de vínculo protocolo que debe dejar pasar, y añadir otra regla específica.

Si usted intercambia en la regla anterior, y encontrar que el original wifi problema regresa, entonces su PF pueden ser el bloqueo de DHCP, el protocolo utilizado para autoconfigurar sus dispositivos de red las direcciones IP. (en una red doméstica, por lo general su router de banda ancha sería su servidor DHCP). La regla tendría que permitir DHCP, sería:

pass on $wifi proto udp from 0.0.0.0 port 68 to 255.255.255.255 port 67

*Nota: puede que tenga que sustituir 0.0.0.0 para any. El DHCPREQUEST de paquetes de tu ordenador envía primero, tiene una dirección de origen 0.0.0.0 porque en esa etapa, el equipo no tiene una dirección IP todavía.
Para ser honesto, me inclino más hacia el uso de any. Otra opción es sacar cualquier especificación de origen, es decir, pass on $wifi proto udp to 255.255.255.255 port 67, pero eso significa que perdemos la fuente-puerto de la parte de la regla, y de ser tan específico como sea posible es siempre la opción más segura.

Espero que ayude. Aquí están algunos enlaces útiles:

mDNS: http://en.wikipedia.org/wiki/Multicast_DNS#Packet_structure

DHSP: http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_discovery

0voto

Alen Puntos 1

Esto me dio la suficiente información de fondo para dar el gran salto y el uso de pf.conf. Aquí es lo que yo uso en mi 10.8 para hacer que se vuelva a conectar después de que cae la conexión VPN :

(Yo sólo uso de ethernet, pero puede cambiar a $lan $wifi y debería funcionar)

lan=en0
wifi=en1
vpn=tun0
block all
set skip on lo
pass on $lan proto { udp,tcp } to 8.8.8.8
pass on $lan proto tcp to vpn.btguard.com port 1194
pass on $vpn

0voto

user263367 Puntos 11

-- Además --

Es posible que desee añadir esta línea: pass on $wifi inet6 proto udp from any to FF02:0000:0000:0000:0000:0000:0000:00FB port 5353

para permitir mDNS para operar en ipv6

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: