Problema de montaje CIFS sobre VPN IPsec

Problema de montaje CIFS sobre VPN IPsec

Estoy intentando conectar un cliente que ejecuta Ubuntu 13.04 a un recurso compartido de red alojado en un servidor de archivos que se actualizó recientemente de Windows Server 2003 a 2012.

Actualmente puedo montar el recurso compartido remoto mientras estoy conectado a la LAN usando:

sudo mount -t cifs //myserver.mydomain.co.uk/myshare /media/myshare/ -o user=myself,domain=myworkgroup,pass=**********

Sin embargo, tengo problemas para montar el recurso compartido a través de una VPN de Cisco (IPsec/Xauth). Antes de la actualización del servidor no tenía ningún problema con esto, pero ahora aparece el siguiente mensaje:

mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

dmesg | tailme da[ 1975.651346] CIFS VFS: cifs_mount failed w/return code = -112

El host definitivamente no está inactivo; todavía puedo conectarme al mismo recurso compartido a través de la VPN usando smbclient:

smbclient //myserver.mydomain.co.uk/myshare -U myself -W myworkgroup
Enter myself's password: 
session request to MYSERVER.MYDOMAIN failed (Called name not present)
Domain=[MYWORKGROUP] OS=[Windows Server 2012 Standard 9200] Server=[Windows Server 2012 Standard 6.2]
smb: \>

No estoy seguro del significado del session request to MYSERVER.MYDOMAIN failed (Called name not present)error " ", ya que todavía puedo explorar la estructura del directorio.

¿Alguna sugerencia sobre qué probar a continuación?

Respuesta1

Puede conectarse con SMB Client porque puede conectarse como "anónimo". Pero poder conectarse de forma anónima no significa que el servicio de autenticación para los usuarios habituales esté funcionando.

Probablemente tengas un problema con el firewall. Abra estos 4 puertos:

- UDP&TCP/137
- UDP&TCP/138
- UDP&TCP/139
- TCP/445

Compruebe que está permitiendo que el servicio Netlogon en el lado de Windows también se comunique.

Respuesta2

¿Puedes acceder al puerto 445/tcp cuando te conectas a través de VPN? Usar

nc -v myserver.mydomain.co.uk 445.  

Si funcionó.

Connection to myserver.mydomain.co.uk 445 port [tcp/microsoft-ds] succeeded! 

El único problema que puede ver es si el firewall representa la conexión que podría surgir de todos modos. Entonces querrás hacer una captura de paquetes y ver si el servidor de Windows envía algo.

Respuesta3

Bueno, ¡un año después finalmente lo descubrí!

La causa principal resultó ser un problema con la resolución del nombre de host. La pista surgió cuando intentaba resolver un problema diferente con SSH en una máquina en la misma red remota a través de la VPN.

De la salida de ssh -v:

debug1: Connecting to myserver2.mydomain.ox.ac.uk [163.1.21.182] port 22.

Descubrí que OpenSSH estaba intentando conectarse a una dirección IP sin sentido (¡en realidad estaba resolviendo el nombre de host de mi servidor en la dirección IP de una impresora de red!). Descubrí que pingtampoco podía resolver correctamente los nombres de host, mientras que hostparecía funcionar. Eso finalmente me llevó aeste hiloen Preguntar a Ubuntu.

Resulta que pingambos sshusan el solucionador glibc, al igual que mount.cifs. Las fuentes de las cuales glibc obtiene información del servicio de nombres se configuran en/etc/nsswitch.conf.

El contenido de mi nsswitch.conforiginalmente se veía así:

passwd:         compat
group:          compat
shadow:         compat

hosts:          files myhostname mdns4_minimal [NOTFOUND=return] dns wins mdns4
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

La línea importante es la que comienza con hosts:, que enumera el orden de las fuentes que glibc consulta al realizar la resolución de nombres de host. Tenga en cuenta que en mi versión, dnsaparece después [NOTFOUND=return]en el orden de búsqueda.

Mi interpretación es que si glibc no logra resolver el nombre de host de acuerdo con las primeras cuatro fuentes, regresará antes de haber consultado ningún servidor DNS. No tengo idea de por qué nsswitch.confse configuró de esta manera (ciertamente no lo configuré así), pero cambié la línea a:

hosts:          files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

De repente hizo que todo funcionara correctamente, pingincluidos sshy mount.cifs.

información relacionada