Problema de montagem do CIFS sobre VPN IPsec

Question

Estou tentando conectar um cliente que executa o Ubuntu 13.04 a um compartilhamento de rede hospedado por um servidor de arquivos que foi recentemente atualizado do Windows Server 2003 para o 2012.

Atualmente, posso montar o compartilhamento remoto enquanto estiver conectado à LAN usando:

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

No entanto, estou tendo problemas para montar o compartilhamento por meio de uma VPN Cisco (IPsec / Xauth). Antes da atualização do servidor eu não tive nenhum problema com isso, mas agora recebo a seguinte mensagem:

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

dmesg | tail me dá [ 1975.651346] CIFS VFS: cifs_mount failed w/return code = -112

O host definitivamente não está desativado - ainda posso me conectar ao mesmo compartilhamento pela 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: \>

Não tenho certeza da importância do erro " session request to MYSERVER.MYDOMAIN failed (Called name not present) ", pois ainda posso navegar na estrutura de diretórios.

Alguma sugestão para o que tentar em seguida?

    

Answer 1

Bem, um ano depois eu finalmente descobri!

A causa raiz acabou sendo um problema com a resolução do nome do host. A pista surgiu quando eu estava tentando resolver um problema diferente com o SSHing em uma máquina na mesma rede remota via VPN.

Da saída de ssh -v :

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

Descobri que o OpenSSH estava tentando se conectar a um endereço IP sem sentido (na verdade, estava resolvendo o nome do host do meu servidor para o endereço IP de uma impressora de rede!). Descobri que ping também não estava solucionando corretamente nomes de host, enquanto host parecia funcionar. Isso eventualmente me levou a este tópico no Ask Ubuntu.

Acontece que ping e ssh usam o resolvedor glibc, assim como mount.cifs . As fontes das quais a glibc obtém informações de serviço de nome são configuradas em /etc/nsswitch.conf .

O conteúdo do meu nsswitch.conf originalmente ficou assim:

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

A linha importante é aquela que começa com hosts: , que lista a ordem das fontes que as consultas glibc ao executar a resolução do nome do host. Observe que na minha versão, dns vem depois de [NOTFOUND=return] na ordem de pesquisa.

Minha interpretação é que, se a glibc não conseguir resolver o nome do host de acordo com as quatro primeiras fontes, ele retornará antes de realmente ter consultado qualquer servidor DNS! Eu não tenho ideia do porquê o nsswitch.conf foi configurado dessa forma (eu certamente não configurei assim), mas alterando a linha para:

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

de repente fez tudo funcionar corretamente, incluindo ping , ssh e mount.cifs .

    

Answer 2

Você pode se conectar ao SMB Client porque pode se conectar como "anônimo". Mas ser capaz de se conectar como anônimo não significa que o serviço de autenticação para os usuários regulares esteja funcionando.

Você provavelmente tem um problema de firewall. Abra estas 4 portas:

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

Verifique se você está permitindo que o Serviço Netlogon no Windows Side se comunique também.

    

Answer 3

Você pode acessar a porta 445 / tcp quando conectar via VPN. Use

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

Se funcionou.

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

O único problema que você pode ver é se o firewall faz proxy na conexão que pode ser bem-sucedida de qualquer maneira. Então você iria querer fazer uma captura de pacotes e ver se o servidor Windows está enviando alguma coisa.