El inicio de sesión SSH a través de IPv6 correctamente mientras se usa IPv4 en el mismo host produce "Permiso denegado"

Question 1

Después de que las cosas se volvieran cada vez más extrañas (ver el hilo de comentarios en mi pregunta), finalmente lo descubrí. Lo primero es lo primero: el proceso de autenticaciónhizofalla en pam_access.so, sin embargo, no se debe a una mala configuración /etc/security/access.confcomo se sugirió.

Para entender por qué, debemos observar la configuración de esta caja en particular: actúa como un enrutador hacia IPv4 que va de forma nativa a través del enlace PPP y hacia IPv6 que está a través de un túnel 6 en 4. Además, este cuadro actúa como un solucionador recursivo de DNS, y aquí se está poniendo interesante. Configuré el solucionador de manera que las búsquedas inversas de IPv4 se resuelvan de forma recursiva comenzando con los servidores raíz de IPv4 y las búsquedas inversas de IPv6 comiencen con los servidores raíz de IPv6. Esta configuración funcionó cuando la instalé por primera vez.

Ahora mi ISP entra en escena y la gente que no entiende cómo funcionan los ataques de amplificación de DNS. Para resumir: estoy seguro de que mi ISP interfiere aleatoriamente con los paquetes DNS entrantes, es decir, algunas cosas deben resolverse a través de sus propios solucionadores desde hace algún tiempo, mientras que otras direcciones DNS se resuelven de forma recursiva por su cuenta: el oficial La razón es mitigar los ataques de amplificación de DNS, pero entonces lo están haciendo mal ^1.

Como no quería cambiar en gran medida mi configuración, simplemente lancé los solucionadores de DNS de mi ISP al final de mi solucionador de DNS local como avance no recursivo, de modo que si el intento de resolución recursiva se agota, prueba los solucionadores de mi ISP. Esto funciona hasta ahora. Pero cuando configuré esto cometí un pequeño error: ingresé a los solucionadores DNS del ISP para que funcionen solo desde hosts dentro de mi alcance local, es decir, 192.168.0.0/16, pero me olvidé del localhost, también conocido como mi enrutador, que es el host que intenté. SSH en, para lo cual el solucionadornotener en cuenta los resolutores del ISP.

pam_access.so intenta realizar una búsqueda inversa en la dirección de sus pares; y esto cierra el círculo: debido a que para la búsqueda inversa de IPv6 se accedería a los servidores raíz DNS IPv6, los paquetes pasarían por el túnel 6in4 sin que mi ISP se metiera con ellos y obtuviera una respuesta. Pero yo no realizaría la búsqueda inversa de IPv4 a través de los solucionadores del ISP, lo que no recibiría respuesta y, en última instancia, informaría un NXHOST (o se ejecutaría en un tiempo de espera). De todos modos, pam_access.so no verá algo que le guste y simplemente dice "no pasarás".

Después de arreglar la configuración del solucionador, ahora todo vuelve a funcionar a las mil maravillas.Pero ahora realmente tengo que pisar los dedos de mi ISP...

¿En cuanto a cómo lo resolví? Bueno, aumentando la verbosidad del registro estudiando intensamente /var/log/everythingpara ver en qué orden se desarrollaron las cosas. Cuando vi que mi solucionador registraba los intentos de búsqueda inversa, supe lo que estaba pasando.

1: desde el punto de vista de la mitigación de la amplificación de DNS, esto es una completa tontería, porque probé y los paquetes DNS salientes pasan bien; sin embargo, esos son los paquetes que deben filtrar. De hecho, cada ISP de cliente final debería descartar todos los paquetes UDP cuya dirección del remitente no coincida con la de sus clientes.

Answer