Limitar unha pasarela OpenVPN a unha soa LAN con regras de UFW

Decide o permiso antes de abrir un ficheiro de cortalumes: os clientes autenticados poden abrir conexións cara a unha subrede concreta, e a pasarela debe rexeitar calquera outra ruta de tránsito mesmo cando un cliente instale rutas adicionais. Ese enunciado é o deseño, e cada regra de abaixo existe para facelo cumprir. Algo máis amplo, como todo o espazo de enderezos privados, a saída a internet polo túnel ou o tráfico entre pares, é un deseño distinto que precisa a súa propia decisión. As regras son ademais deliberadamente aburridas, porque un cortalumes enxeñoso é un que ninguén poderá auditar despois.

Escribe primeiro a topoloxía e o permiso

O exemplo usa un servidor Community OpenVPN cun dispositivo TUN en espazo de usuario chamado tun0, un conxunto de clientes 10.77.0.0/24, e unha subrede conectada 192.168.60.0/24 en lan0. O reenvío IPv4 xa funciona e a LAN xa ten unha ruta de volta ao conxunto, así que nada aquí depende da tradución entre ambos.

UFW é o dono do cortalumes neste servidor, e nin un conxunto de regras de contedor nin unha táboa nftables separada poden instalar unha ruta de aceptación anterior. Un atallo de descarga de fluxo que salte o filtro faría decorativas as cadeas de garda, así que confirma que ningunha está activa. Deixa o reenvío client-to-client propio de OpenVPN desactivado, porque o tráfico entre pares que nunca cruza o filtro do sistema operativo non se pode acoutar con el. O escoitante externo e as regras de administración quedan como están, xa que este cambio goberna o tráfico descifrado do túnel en vez de substituír o cortalumes.

Coloca os gardas antes das aceptacións temperás de UFW

Un permiso de ruta seguido dunha denegación non abonda para unha fronteira estrita. As regras before de serie aceptan o tráfico establecido e algúns ICMP antes de que se consulte calquera regra de usuario, así que un fluxo permitido a semana pasada pode quedar fóra da nova restrición de destino só porque aínda ten estado. Fai copia de seguridade dos ficheiros de UFW e mantén aberta unha consola fóra de banda antes de editar.

Na sección *filter do ficheiro /etc/ufw/before.rules, declara dúas cadeas xunto ás declaracións existentes e antes de calquera liña de regra.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Xusto despois das declaracións, e antes dos permisos de entrada e de reenvío, salta a elas e define que admiten.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Conserva o resto da sección e a súa liña COMMIT. Pegar unha segunda táboa de filtro ou borrar regras non relacionadas é como un cambio de cortalumes se converte nunha caída, e o ficheiro está a un reinicio de ser a única copia que importa.

Le o que admite e rexeita cada garda

A primeira cadea continúa o procesamento só cando a orixe está no conxunto, o destino é a única subrede, a interface de saída é a LAN e o paquete viaxa na dirección orixinal do seu fluxo. Todo o demais que chega do túnel descártase, incluído unha orixe fóra do conxunto e calquera destino máis aló da subrede permitida.

Un paquete entre pares entra e sae por tun0, así que falla a proba de interface da LAN antes mesmo de chegar a unha comprobación de destino. As conexións novas da LAN cara aos clientes tamén fallan a proba de dirección de resposta, o que pecha por defecto a ruta de chamada inversa.

O obxectivo RETURN mantén en xogo a política normal de UFW. Estas cadeas filtran, e o permiso de ruta que engadas despois segue decidindo se se acepta un paquete supervivente. Esa separación é a que che permite cambiar a subrede permitida nun só lugar máis adiante. Se os gardas aceptasen os paquetes directamente, cada regra futura tería que engadirse dúas veces.

Autoriza a subrede e pecha as portas laterais

Previsualiza primeiro o permiso de ruta e logo retira a marca de previsualización para aplicalo: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Despois revisa a orde das regras de usuario, porque unha denegación anterior segue gañando a unha autorización posterior. Un permiso para toda a subrede tamén é a forma incorrecta cando só o porto HTTPS dun servidor debe ser accesible.

Fíxate no que fai o descarte de entrada: os clientes do túnel non poden alcanzar ningún servizo na propia pasarela, incluído un escoitante DNS ligado ao seu enderezo de LAN. Aloxar DNS alí require unha excepción deliberada antes do descarte e un contrato de permiso revisado. Se UFW xestiona IPv6, engade descartes correspondentes para tun0 en before6.rules tamén, porque unha lista de destinos IPv4 non di nada sobre os paquetes IPv6.

Verifica a política cargada, non a previsualización

Previsualiza a recarga, aplícaa nunha xanela de mantemento e le o conxunto de regras vivo.

sudo ufw --dry-run reload
sudo ufw show raw

Confirma que as gardas do túnel aparecen antes dos permisos por defecto de estado e ICMP. O ufw status simple non mostra as regras before editadas a man, e por iso os operadores conclúen que falta unha regra cando en realidade está cargada. Le a listaxe en bruto de arriba abaixo en vez de buscar un fragmento. Se as gardas aparecen despois dun permiso de estado, a fronteira non fai o que suxire o ficheiro.

Despois proba o comportamento, non o texto. Abre unha conexión nova a un servidor permitido e observa a resposta, dirixe unha petición inofensiva a un destino fóra da subrede e confirma que morre, proba unha conexión entre pares, proba un servizo local á pasarela e proba unha conexión non solicitada da LAN a un cliente. Inclúe un fluxo fóra de alcance que existise antes do cambio, e borra só ese fluxo en vez de baleirar toda a táboa de seguimento da máquina.

Anota os límites xunto ás regras: isto acouta o tránsito e nada máis. Non impide que un cliente use a súa propia conexión a internet, non impide que un servidor permitido da LAN retransmita tráfico máis adiante, e non substitúe a autenticación dentro dos servizos permitidos.