Interruptor de seguridade pf de macOS para OpenVPN: regras que pechan

En macOS, un interruptor de seguridade vale tanto como a política do filtro de paquetes que ten detrás, e pf é a peza que aplica esa política. A política debe facer dúas cousas opostas á vez: deixar que o cliente chegue ao seu servidor para que poida existir un túnel, e deter todo o demais para que non saia directamente. A maioría dos conxuntos de regras publicados resolven o segundo e esquecen o primeiro, así que a máquina perde conectividade en lugar de gañar protección. A versión que funciona nomea o punto final, o resolutor e o túnel, e nada máis.

Que pode decidir un filtro de paquetes e que non

pf mira interfaces, enderezos, números de protocolo e portos, e alí detense. Nunca sabe que proceso abriu un socket, así que un permiso escrito para un programa convértese en permiso para cada programa que poida chegar ao mesmo porto. Así é como unha excepción UDP xenerosa devolve un interruptor de seguridade a unha rede corrente. O bloqueo consciente da aplicación pertence ao cliente ou a unha extensión do sistema, non a este ficheiro.

O filtro tampouco crea rutas. Cando o cliente cae, a ruta por defecto pode seguir apuntando a un túnel morto, e pf converte iso en paquetes bloqueados en lugar dunha volta silenciosa ao Wi-Fi. O bloqueo é o resultado buscado, non un fallo que haxa que rodear.

A orde decide o resultado máis a miúdo que o texto da regra. Sen quick, pf segue avaliando tras unha coincidencia e gaña a última regra que coincide, así que un paso amplo preto do final anula as excepcións coidadas de arriba. Marcar os pasos con quick fai que a primeira coincidencia sexa definitiva, que é o que adoita querer dicir un autor de políticas.

Le primeiro os datos da interface e do punto final

As interfaces sen fíos non se numeran igual en cada Mac, e o dispositivo de túnel recibe un número que pode cambiar entre arranques. Unha regra que nomea un dispositivo inexistente falla ao analizarse, o cal é ruidoso e fácil de detectar, mentres que unha regra que nomea o dispositivo existente equivocado se analiza limpiamente e permite tráfico que querías deter.

Recolle os datos mentres o cliente está conectado, porque o dispositivo de túnel só existe entón. Necesitas a interface que ten a ruta por defecto, o dispositivo que creou o cliente, e o enderezo e o porto do servidor ao que marca. Ese último valor é o que máis conxuntos de regras omiten, e omitilo é por que un conxunto copiado bloquea o seu propio túnel.

route -n get default
ifconfig -l
scutil --nc list

O primeiro comando nomea a interface que gaña agora, o segundo enumera cada dispositivo que coñece o núcleo, e o terceiro mostra as configuracións VPN que o sistema pode iniciar. Apunta esas respostas e despois le o enderezo e o porto do servidor desde a propia configuración do cliente.

Escribe o conxunto de regras arredor da ruta do túnel

O ficheiro de abaixo denega por defecto e volve admitir cinco cousas: loopback, o dispositivo de túnel, a ruta do cliente ata o seu servidor, o resolutor usado antes de que exista o túnel, e os dous intercambios que manteñen utilizable unha ligazón sen fíos. Os nomes de interface e o enderezo do servidor veñen da túa máquina, así que substitúe os valores que confirmaches. O número de túnel tampouco coincidirá co teu.

set skip on lo0
block all
pass out quick on utun0
# maintain this line when the server address changes
pass out quick on en1 inet proto udp to 203.0.113.10 port 1194
# only the resolver the client uses before the tunnel exists
pass out quick on en1 inet proto udp to 192.0.2.53 port 53
pass out quick on en1 inet proto udp from any port 68 to any port 67
pass out quick on en1 inet proto udp to 224.0.0.251 port 5353

A liña DHCP existe porque un Mac pide un enderezo antes de telo, así que a petición sae do porto 68 cara ao porto 67 sen un enderezo de orixe utilizable. A liña de multicast permite ao sistema xulgar se paga a pena usar a ligazón sen fíos, e quitala produce unha máquina que informa de que non hai conexión nunha rede que funciona. A liña do punto final é o que permite a OpenVPN chegar ao seu servidor; sen ela, block all descarta o saúdo exterior e o túnel nunca sobe. A liña do resolutor é máis estreita que un permiso DNS xeral, porque nomea un enderezo e un porto en lugar de cada consulta que fai a máquina.

Esas excepcións do punto final e do resolutor son as dúas que deben existir; todo o demais segue bloqueado. Se o cliente marca un enderezo literal, quita a liña do resolutor e mantén a do punto final. Se o enderezo do servidor cambia, actualiza esa liña antes da seguinte conexión, ou enche unha táboa de pf desde o propio gancho do cliente e fai coincidir a táboa no seu lugar.

Baixa o túnel e despois reinicia

Analiza antes de cargar, porque un erro de sintaxe é barato nunha proba en seco e caro nunha sesión remota. Despois carga o ficheiro, activa o filtro se estaba apagado, e rele o que está realmente en vigor. A relectura non é cerimonia: outra áncora pode engadir regras que non escribiches, así que compara o conxunto impreso co teu ficheiro.

sudo pfctl -n -v -f /etc/pf.conf
sudo pfctl -f /etc/pf.conf
sudo pfctl -e
sudo pfctl -s rules
sudo pfctl -s Anchors
sudo pfctl -a <anchor> -s rules
sudo pfctl -s info

Coas regras cargadas, baixa o túnel e tenta cargar unha páxina. O tráfico corrente debería deterse, e debería seguir detido despois de que a máquina durma e esperte, porque é nesa transición onde volve o estado obsoleto. Reconecta e confirma que o tráfico se retoma sen tocar o conxunto de regras. Se un navegador segue funcionando co túnel baixado, algunha regra é máis ampla do que pensabas, e a relectura adoita nomeala.

O reinicio é a parte que a xente salta. macOS le /etc/pf.conf ao arrancar, pero ler o ficheiro non é o mesmo que activar o filtro, así que un conxunto de regras que funciona agora pode quedar inactivo tras un reinicio. Executa despois sudo pfctl -s info e confirma que a liña de estado informa o filtro como activado.

Mantén honestos a saída e a ruta de reinicio

Un conxunto de regras que bloquea todo tamén pode deixarte fóra dunha máquina que administras en remoto. Edita desde unha sesión local cando poidas, ten o ficheiro anterior xunto ao novo, e coñece a reversión antes de necesitala. Os comandos de abaixo desactivan o filtro e recargan a copia que gardaches, e é a secuencia para executar desde unha consola, non polo túnel que acabas de cortar. Unha reversión de cinco segundos gaña a unha regra enxeñosa cada vez.

sudo pfctl -d
sudo pfctl -f /etc/pf.conf.previous
sudo pfctl -s rules

A persistencia esixe un demonio de arranque que execute pfctl -e e cargue o teu ficheiro ao inicio. Trátao como calquera outro traballo privilexiado: rutas absolutas, un rexistro que poidas ler despois, e unha proba nunha máquina que poidas tocar fisicamente. Un demonio que falla en silencio deixa a máquina desprotexida e con aspecto normal.

Documenta os ocos, empezando por un segundo cliente VPN que crea o seu propio dispositivo de túnel. As túas regras nomean unha interface de túnel, así que a segunda queda bloqueada ou a captura unha regra ampla engadida máis tarde. As interfaces de tethering e punto de acceso só aparecen ás veces e merecen a mesma nota. Ningún deses ocos é razón para saltar a política; son as condicións baixo as que aínda se mantén.