Проблема монтирования CIFS через IPsec VPN

Question

Я пытаюсь подключить клиент под управлением Ubuntu 13.04 к общему сетевому ресурсу, размещенному на файловом сервере, который недавно был обновлен с Windows Server 2003 до 2012.

В настоящее время я могу подключить удаленный общий ресурс при подключении к локальной сети, используя:

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

Однако у меня возникают проблемы при подключении общего ресурса через VPN Cisco (IPsec/Xauth). До обновления сервера у меня не было проблем с этим, но теперь я получаю следующее сообщение:

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

dmesg | tail дает мне [ 1975.651346] CIFS VFS: cifs_mount failed w/return code = -112

Хост определенно не отключен - я все еще могу подключиться к тому же ресурсу через VPN с помощью 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: \>

Я не уверен в значимости ошибки « session request to MYSERVER.MYDOMAIN failed (Called name not present) », так как я все еще могу просматривать структуру каталогов.

Любые предложения о том, что попробовать дальше?

Answer 1

Вы можете подключиться к SMB Client, потому что вы можете подключиться как "анонимный". Но возможность подключения как анонимного не означает, что сервис аутентификации для обычных пользователей работает.

Возможно, у вас проблема с брандмауэром. Откройте эти 4 порта:

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

Убедитесь, что вы разрешаете службе Netlogon на стороне Windows также общаться.

Answer 2

Можете ли вы получить доступ к порту 445/ TCP при подключении через VPN. использование

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

Если бы это сработало.

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

Единственная проблема, с которой вы можете столкнуться, заключается в том, что брандмауэр прокси-соединения, который может произойти, все равно будет успешным. Затем вы захотите сделать захват пакета и посмотреть, отправляет ли сервер Windows что-нибудь.

Answer 3

Ну а через год я наконец-то понял это!

Основной причиной оказалась проблема с разрешением имени хоста. Подсказка появилась, когда я пытался решить другую проблему с SSHing на машине в той же удаленной сети через VPN.

Из вывода ssh -v:

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

Я обнаружил, что OpenSSH пытался подключиться к бессмысленному IP-адресу (фактически он преобразовывал имя хоста моего сервера в IP-адрес сетевого принтера!). Я обнаружил, что ping также не может правильно разрешить имена хостов, в то время как host кажется, работает. Это в конечном итоге привело меня к этой теме на Ask Ubuntu.

Оказывается, что ping и ssh используют решатель glibc, как и mount.cifs . Источники, из которых glibc получает информацию службы имен, настроены в /etc/nsswitch.conf .

Содержимое моего nsswitch.conf изначально выглядело так:

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

Важной строкой является строка, которая начинается с hosts: которой указан порядок источников, которые glibc запрашивает при выполнении разрешения имени хоста. Обратите внимание, что в моей версии dns идет после [NOTFOUND=return] в порядке поиска.

Моя интерпретация заключается в том, что если glibc не сможет разрешить имя хоста в соответствии с первыми четырьмя источниками, он вернется до того, как фактически запросит какие-либо DNS-серверы! Я понятия не имею, почему nsswitch.conf был настроен таким образом (я, конечно, не настроил его так), но изменил строку на:

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

внезапно заставил все работать правильно, включая ping , ssh и mount.cifs .