Por que unha regra de bloqueo de cliente OpenVPN nunca chega a FORWARD

Dous clientes no mesmo servidor OpenVPN poden alcanzarse aínda que engadiches unha regra DROP para o seu conxunto de enderezos. A regra está na cadea FORWARD, o tráfico flúe con claridade e o contador desa regra segue en cero. A conclusión natural é que a devasa está rota. O máis habitual é que o paquete nin sequera entrase na cadea.

Hai dous camiños que un paquete dun par pode seguir a través dun servidor OpenVPN, e decídeos a configuración, non a devasa. Saber que camiño está en uso diche se unha regra do host está sequera no lugar correcto.

Dous camiños que pode seguir un paquete dun par

Coa opción de reenvío interno desactivada, un paquete do cliente A chega á interface do túnel cun destino dentro do enderezo asignado ao cliente B. A táboa de rutas do servidor devólveo pola mesma interface do túnel, porque o servidor é dono da ruta cara ao enderezo de B. É un fluxo de entrada e saída a través do host, e avalíao a ruta de reenvío IPv4.

Coa opción de reenvío interno activada, o proceso do servidor emparella o paquete cun cliente conectado e escríbeo de volta a ese mesmo cliente. O paquete trátase dentro do daemon e nunca volve entrar no dispositivo do túnel, así que a ruta de reenvío do host sáltase por completo. O manual de OpenVPN 2.6 describe esta opción como reenvío interno de cliente a cliente, e é exactamente por iso polo que unha regra da devasa do host non pode vela.

Existe unha terceira variante en despregamentos que descargan a canle de datos a un módulo do núcleo. A decisión de reenvío e a cifraxe saen do espazo de usuario, e que netfilter observe o fluxo depende de como estea construído o camiño de descarga. Nunca deas por feito que un conxunto de regras antigo se comporta nun servidor con descarga igual que nun de espazo de usuario. Confirma o modo a partir da configuración en execución, non da versión do paquete.

Cando o contador nunca se move

Un contador a cero significa que o paquete non coincidiu con esa regra naquel punto, e hai varias razóns. A primeira é o desvío anterior: o tráfico nunca chegou á cadea. A segunda é unha discrepancia na interface, a dirección, a orixe ou o destino, algo habitual cando o conxunto se renumerou e a regra aínda nomea o prefixo antigo.

A terceira é a posición. Unha regra anterior na cadea pode aceptar o fluxo antes de que se avalíe o teu DROP, e unha regra posterior pode ser a que realmente decide o resultado. Le a cadea en orde cos contadores visibles e despois comproba que contador aumenta cando repetes a proba.

Fai un intercambio controlado entre dous clientes cuxos enderezos reais confirmaches a partir do propio estado do servidor, non dun arrendamento que recordes. Se o contador relevante segue sen moverse, sospeita do camiño antes de reescribir a coincidencia. Se se move pero a conexión segue funcionando, o descarte estase anulando máis adiante e o problema é a orde. Esa resposta decide se a reparación é un cambio de regra ou un cambio de topoloxía, así que obténa antes de editar nada.

Escoller unha fronteira que poida filtrar

Se a política ten que vivir na devasa do host, pon o tráfico onde a devasa poida velo. Desactivar o reenvío interno é a forma admitida de facer que o tráfico entre pares atravese a interface do túnel e a ruta de reenvío, a costa de enviar cada paquete de par pola pila do host.

Despois emparella o fluxo con precisión. O tráfico chega á interface do túnel e sae por ela, en ambos os sentidos, así que as regras que só consideran a interface física non coincidirán. As regras baseadas en enderezos necesitan o conxunto actual e deben ter en conta o sentido de retorno tanto como o de ida.

Moitos despregamentos sérvense mellor filtrando a nivel de cliente ou de grupo, onde a identidade é coñecida e a política segue o usuario en lugar dun enderezo que cambia ao reconectar. Ese é un mecanismo distinto dunha cadea do host, e os dous non deberían mesturarse sen unha razón clara.

Non traslades sen cambios o conxunto de regras dunha topoloxía antiga a través dunha migración. Os conxuntos de enderezos, os nomes de interface e os modos de reenvío inflúen todos en se unha regra coincide, e unha regra copiada que antes funcionaba é o tipo de evidencia máis enganoso. Comeza polo fluxo que queres permitir e escribe a regra que coincide con el.

Probar o illamento en vez de confiar nunha regra

Proba o caso prohibido e o caso permitido na mesma execución. Inicia unha conexión nova dun cliente ao outro e confirma que falla, e logo confirma que unha conexión que debería permitirse segue funcionando. Se só se proba o primeiro, unha devasa que bloquea todo parece un éxito.

Repite despois de recargar a configuración do servidor e de que un cliente se reconecte, porque o reenvío interno e as asignacións de conxunto son estado en tempo de execución. Comproba os contadores en ambos os sentidos, xa que unha regra que coincide nun sentido e non na resposta produce un illamento parcial difícil de notar nunha proba rápida.

O illamento é o resultado observado na fronteira que realmente transporta o fluxo. Unha regra DROP nalgún lugar do host non é evidencia; unha conexión fallida máis un contador movido na regra que a causou si o é.