Por que nftables non ve o tráfico entre clientes de OpenVPN

Dous clientes nun mesmo servidor intercambian ficheiros, a transferencia ten éxito e cada regra de reenvío que apuntades ao túnel informa de cero paquetes. As regras non están rotas e a cadea non está mal colocada. Co reenvío entre pares activado, o paquete entrégase dentro do proceso do servidor e a pila do host nunca se converte no encamiñador, así que o cortalumes do núcleo non ten nada que contar. Entender esa separación decide se conservades o atallo ou reconstruídes a ruta a través do núcleo.

Siga un paquete a través do servidor

Nun túnel encamiñado, o daemon entrega o paquete descifrado de cada cliente ao dispositivo de túnel. Desde alí o host encamíñao, execútase o gancho de reenvío e unha regra que coincida co dispositivo de túnel pode contar ou descartar o tráfico. Ese é o camiño que supoñen a maioría dos exemplos de cortalumes.

O atallo saca o host do medio. O paquete descifrado dunha sesión entrégase a outra sesión dentro do daemon, e o paquete interior nunca se emite no dispositivo de túnel nin o encamiña o host. O tráfico encapsulado segue cruzando a interface física, así que unha captura externa parece ocupada mentres as regras internas calan. Unha captura tomada no dispositivo de túnel non mostra absolutamente nada, o que sorprende a quen espera ver alí a transferencia. Esa asimetría é a forma máis rápida de recoñecer o atallo desde fóra do daemon.

A proba do contador que decide que camiño se percorreu

Engada un contador á regra que debería aplicarse, execute unha transferencia entre dous clientes que esa regra debería bloquear e lea o contador despois.

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

Se a transferencia ten éxito e o contador segue en cero, o núcleo nunca xestionou eses paquetes, e ningunha cantidade de edición de regras o cambiará. Repita a mesma proba contra un servizo do propio servidor, porque ese fluxo si atravesa a pila do host e o seu contador móvese. Comparar os dous resultados é o que produce a resposta.

Dous detalles evitan unha lectura falsa. Un nome de interface escrito nunha etiqueta de cadea non filtra nada por si só, porque a coincidencia ocorre nos campos de interface dentro das regras. E un deseño ponte de capa 2 compórtase doutra forma: alí os clientes comparten un dominio de difusión, así que o descubrimento de pares é o esperado e non un fallo de encamiñamento.

Un conmutador non é unha lista de acceso

Esta é a parte que custa unha tarde. O reenvío entre pares é un único axuste de acendido ou apagado, e mentres está acendido o daemon é o único punto de reenvío. O cortalumes do host non pode expresar quen pode chegar a quen, e os ficheiros por cliente non converten o conmutador nunha matriz de políticas.

Se necesita regras por par, a elección é entre renunciar ao atallo e renunciar ao cortalumes do host como control. Apagalo restaura o reenvío do núcleo, que esixe reenvío IP no servidor e regras explícitas para os fluxos que desexa. Mantelo acendido significa que a política vive na configuración do daemon, que na práctica é todos os pares ou ningún.

Procesos de servidor separados cos seus propios rangos de enderezos e portos son o termo medio viable. Cada proceso leva exactamente unha decisión de acceso, así que dous grupos poden ter regras distintas sen unha matriz de políticas. O host pode encamiñar entre os rangos cando iso é o previsto, e entón o cortalumes ve eses fluxos porque cruzan o host. O custo son portos extra, certificados extra e un perfil por grupo.

Elixir o punto de reenvío

Elixa o reenvío do núcleo cando o cortalumes sexa o motor de políticas, cando necesite rexistro por fluxo ou cando a contabilidade importe. O custo é o rendemento a través da pila do host e máis regras que manter. A vantaxe é que cada ferramenta existente, dos contadores aos exportadores de fluxos, volve describir o tráfico. Nun servidor pequeno ese custo é invisible; nun repetidor ocupado non o é.

Elixa o reenvío dentro do proceso cando o tráfico entre pares estea todo permitido ou todo denegado e o servidor estea dimensionado para iso. O custo é que os contadores, as disciplinas de cola e o seguimento de conexións xa non describen os fluxos internos; iso só é aceptable se despois ninguén depende deles.

Elixa o que elixa, anóteo xunto ás regras do cortalumes. Un conxunto de regras que parece permitir o tráfico entre pares mentres o daemon decide igualmente engana a seguinte persoa que depure unha transferencia fallida. Quen só lea as regras asumirá que o núcleo é a porta.

Que comprobar antes de cambiar regras

Lea a configuración que o servidor cargou realmente, non o ficheiro que recorda ter editado, e confirme se a opción de pares está presente. Se a cambiou, asegúrese de que o servizo recargou e non só reescribiu un ficheiro no disco.

Despois repita a proba cun fluxo de cliente a servidor para demostrar que a regra coincide cando menos, e revise as rutas enviadas, porque unha ruta ausente parece exactamente un bloqueo do cortalumes desde o lado do cliente. Cambie a orde das regras só cando saiba que punto de reenvío posúe a decisión.