Por qué Samba rechaza clientes VPN que sí llegan al servidor

Un cliente VPN hace ping al servidor de archivos, resuelve su nombre y aun así no puede abrir un recurso compartido. La política de hosts de Samba es una de las cuatro capas que pueden rechazar esa conexión, y es la que la gente edita en último lugar. La lista de permitidos se evalúa contra la dirección de origen que smbd recibe realmente, que puede no ser la dirección que el cliente cree tener. Acertar con ese origen convierte un problema vago de permisos en un cambio de configuración de una línea.

Cuatro capas que fallan con el mismo mensaje

Un rechazo puede venir de la ruta, del cortafuegos del host, de la política de hosts de Samba o de la identidad SMB. Cada capa produce en el cliente un mensaje que dice más o menos lo mismo, por eso adivinar consume una tarde. Ordenar las comprobaciones de la red hacia dentro elimina la mayor parte de las conjeturas.

Empiece por el transporte. Si el puerto 445 nunca llega al servidor, ningún ajuste de Samba importa, y una captura en la interfaz del servidor lo resuelve en segundos. Después viene el cortafuegos del host en el propio servidor, que puede descartar un origen permitido antes de que smbd lo vea. Solo después de que esas dos pasen, la lista de permitidos se convierte en candidata. La autenticación va al final, porque un fallo de inicio de sesión y un rechazo de host se ven distintos en el registro del servidor, incluso cuando el cliente presenta ambos como acceso denegado. El orden importa más que las herramientas, porque cada capa tiene un comando que la responde.

Encuentre la dirección de origen que smbd ve realmente

Con acceso enrutado el servidor suele ver la dirección del cliente del grupo VPN. Con traducción de origen en la pasarela ve en su lugar la dirección LAN de la pasarela, y cada cliente detrás de esa pasarela se vuelve indistinguible.

Esa diferencia decide si una entrada de la lista de permitidos es política o un agujero. Permitir una dirección de pasarela traducida admite a todos los que están detrás, que es lo que una regla por cliente rara vez quería expresar. Lea el origen en el servidor y no en la idea que el cliente tiene de su propia dirección. Una captura en la interfaz del servidor es la forma más barata de verla, y la misma captura demuestra si el paquete llegó siquiera. Limite la captura con un recuento de paquetes y añada un filtro de host cuando sepa qué cliente sigue. La tabla de sesiones de Samba es la otra mitad de la respuesta: en smbstatus -b la columna de cliente de cada fila de sesión es el par que smbd registró, y es la confirmación más rápida de la dirección que llegó realmente al servicio.

sudo tcpdump -ni any -c 20 'tcp port 445'
sudo smbstatus -b
ss -tnp | grep ':445'

Lea la lista de permitidos como la lee Samba

El ajuste hosts allow toma una lista de direcciones, redes o nombres, y puede aparecer globalmente o dentro de un recurso compartido. Dos entradas que a usted le parecen equivalentes pueden no serlo para el analizador, así que la configuración efectiva es lo que hay que inspeccionar. Eso significa la vista fusionada y no el archivo que editó por casualidad.

Un par ilustrativo de prefijos se parece a la línea de abajo, y es un ejemplo y no un reemplazo de las entradas que ya existen. Conserve los clientes administrativos y de aplicaciones que hoy se conectan legítimamente, y lea cualquier lista de denegación en la misma pasada. Que un host sea admitido depende de la política en conjunto, así que pruebe el cliente exacto en lugar de razonar sobre la precedencia. El permiso de host tampoco dice nada sobre permisos de recurso compartido o modos del sistema de archivos, que son puertas separadas. Un éxito de las herramientas de prueba significa que la política de hosts admite ese origen, y nada más.

hosts allow = 192.168.50.0/24 10.90.0.0/24
testparm -s
testparm -s /etc/samba/smb.conf client.example 10.90.0.14

Cambie el archivo que sobrevive a un reinicio

En un host Linux normal la ruta de configuración es fija y el servicio la relee al reiniciar. En un enrutador o aparato el smb.conf en ejecución a menudo se genera al arrancar, y una edición manual desaparece en el siguiente reinicio. Use el mecanismo de personalización admitido del aparato, que suele ser un archivo de configuración propio.

La tentación en este punto es flashear un firmware alternativo porque un hilo informó de que funcionaba. Eso es un cambio grande para un problema pequeño de política, y saca el dispositivo de su estado admitido. Identifique primero el control admitido, ya que la mayoría de aparatos exponen la lista de permitidos mediante su propia interfaz. Si de verdad no lo hacen, esa limitación es un argumento para otro hardware y no para una compilación no admitida.

Anote qué archivo cambió y qué lo vuelve a generar, para que la siguiente persona no repita el diagnóstico.

Pruebe un cliente permitido y uno excluido

Pruebe ambos resultados, no solo el que quería. Un cliente permitido que se conecta demuestra que el cambio funciona; un cliente excluido que sigue rechazado demuestra que la regla no abrió simplemente todo.

smbclient -L //fileserver -U alice
sudo testparm -s /etc/samba/smb.conf alice-laptop 10.90.0.14
sudo tail -n 40 /var/log/samba/log.smbd

Cuando la conexión nunca llega a smbd, la respuesta está en el enrutamiento o en el cortafuegos del servidor. Si el host está admitido y el inicio de sesión falla, el problema es la identidad y ampliar la lista de permitidos no ayudará. Mantenga la salida de diagnóstico en privado, porque un registro detallado de Samba puede exponer rutas de recursos compartidos y nombres de cuentas. Cambie una capa por intento, o el siguiente resultado no le dirá nada.