Zona VPN de OpenWrt, reenvío e enmascaramento: cal necesitas?

Tres cambios mestúranse cada vez que unha VPN se atopa con OpenWrt: abrir un porto, permitir o reenvío e activar o enmascaramento. Responden a preguntas distintas, e normalmente só un deles é o requisito real. Ler cada control segundo o papel do tráfico que goberna converte unha suposición nunha decisión, e tamén di que síntoma esperar cando o cambio é incorrecto. Comece por nomear o papel que fallou, non a caixa que recorda.

Nomee o papel do tráfico antes de tocar un control

A entrada de zona decide que pode chegar ao propio router. A saída de zona cobre o tráfico que orixina o router, o reenvío de zona é o valor predeterminado para o tráfico que atravesa unha zona, e o enmascaramento decide se a dirección de orixe se reescribe á saída. Son catro preguntas distintas, e unha política de zona responde a todas á vez co mesmo valor, por iso un cambio en toda a zona é un instrumento groseiro. Unha regra con nome pode responder a unha delas sen tocar as demais.

O mapa útil é por papel do tráfico, porque iso é o que pode observar cando algo falla. Cada papel de abaixo ten un control que o decide e un síntoma que apunta a el:

Un servizo á escoita no router necesita unha soa regra de entrada estreita

Un servidor OpenVPN no router recibe tráfico dirixido ao router, así que a súa conexión exterior depende da política de entrada da zona que o transporta. Permita o transporte e o porto configurados e deixe todo o demais desa zona en rexeitamento. Unha soa regra de porto é un cambio moito menor ca unha aceptación en toda a zona, e é a que aínda poderá explicar dentro dun ano.

Dúas cousas fan que esa regra sexa segura de manter: nomea o porto que o servizo usa de verdade e está xunto á definición da zona para que a seguinte persoa vexa por que existe. As liñas de abaixo son a forma, co porto no lugar do que estea configurado no servidor. Cambie ese porto nos dous sitios cando o servizo se mova, porque unha regra que queda no antigo é invisible ata unha auditoría.

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

Valide antes de recargar, porque un erro de sintaxe nun ficheiro de devasas pode deixar o router sen un conxunto de regras funcional. Nunha versión que usa fw4 a comprobación é un comando aparte, e falla ruidosamente en lugar de aceptar en silencio un bloque roto. Recargue só despois de que a comprobación pase e garde o ficheiro anterior onde poida devolvelo.

fw4 check
service firewall reload

A petición dun cliente cruza o reenvío, non a entrada

Despois da autenticación, a petición dun cliente de túnel a un servizo da LAN produce un fluxo reenviado, así que o control que a decide é a relación de reenvío entre a zona do túnel e a zona LAN. Asigne a interface do túnel á zona prevista e logo declare a dirección, as fontes e o servizo. A asignación de zona é o que dá sentido á regra de reenvío, e ambas só se entenden lidas xuntas. Unha relación de reenvío que nomea a zona do túnel como orixe e a zona LAN como destino lise como unha decisión deliberada, mentres que dúas aceptacións en toda a zona lisen como un accidente.

Chegar ao propio router segue usando a ruta de entrada, por iso un ping á pasarela non di nada sobre o recurso compartido que hai detrás. Esas dúas fallas viven en bloques distintos e corríxense con edicións distintas. Escriba ambas as rutas por separado antes de cambiar calquera delas.

O enmascaramento é unha decisión de encamiñamento, non un permiso

O enmascaramento reescribe a dirección de orixe do tráfico de saída seleccionado. Pode rescatar un deseño de saída no que o lado remoto non ten ruta de volta, e tamén oculta as direccións dos clientes individuais a calquera servizo que rexistre ou autorice por dirección. Desactivalo é unha elección de encamiñamento sobre a ruta de volta, non un interruptor de seguridade que pecha un burato de entrada. Un túnel que funciona coa tradución activada e falla no momento de desactivala adoita ter unha ruta de volta que falta, non unha regra de devasas que falta.

A alternativa encamiñada necesita unha ruta de volta no lado remoto en lugar da tradución. Ningunha das dúas opcións proporciona o permiso das devasas nin a conta da aplicación, por iso desactivar o enmascaramento case nunca arranxa un cliente de túnel que non pode chegar a nada. Trate tamén a política IPv4 e a IPv6 por separado, porque un só axuste de tradución non describe as dúas familias.

Demostre a decisión cunha petición permitida e outra rexeitada

Envíe unha petición que debería permitirse e outra que debería rexeitarse, e logo identifique o control que tomou cada decisión. Unha páxina que se carga por casualidade non é proba; a proba é a regra que coincidiu, na cadea onde coincidiu. O rexeitamento importa tanto como o éxito, porque mostra que a política fai algo en lugar de que todo estea permitido.

Dous comandos danlle esa proba nunha versión actual. O contador da regra correspondente móvese cando a petición se acepta, e o rexistro mostra o descarte se activou o rexistro para a regra:

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

Conserve unha ruta de administración que aínda poida usar antes de cambiar calquera política de devasas, e siga o proceso de validación e reversión do propietario da configuración. Un cambio que o deixa fóra do router non é un resultado de proba, é un segundo incidente. Anote a zona e o papel do tráfico xunto a cada observación, para que o par de resultados explique a política en lugar de describir unha carga de páxina afortunada.