Монтирование NFS-сервера, работающего в ВМ: Тайм-аут соединения

Кажется, я наткнулся на эту общую проблему с NFS на виртуализированных машинах. Короче говоря, я попытался развернуть FOG-сервер, который использует NFS.

• VM-хост NFS-сервера находится в мостовом режиме с IP: 10.0.0.136
• может монтировать NFS-общий ресурс с других виртуальных машин на физическом хосте, но не с других LAN-устройств.
• Виртуальная машина находится в режиме NAT-моста независимо от того, какую виртуальную платформу я использую.
• Брандмауэр отключен - порты .. открыты ..
• Физическая машина, на которой работает платформа VM, - это Windows 10 Home, отключенный брандмауэр и сетевой адаптер Intel.

Проблема: Когда я подключаюсь с других LAN-устройств, я получаю сообщение «Время ожидания соединения истекло», но showmount отвечает через 2 минуты 10 секунд. Этот тест выполняется с Synology-NAS в той же локальной сети.

# mount -v -t nfs nfsserver:/images /volume1/test
mount.nfs: timeout set for Tue Jan 30 23:43:55 2018
mount.nfs: trying text-based options 'vers=3,tcp,soft,nolock,addr=10.0.0.136'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.0.0.136 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=6
mount.nfs: trying 10.0.0.136 prog 100005 vers 3 prot TCP port 56755
mount.nfs: mount(2): Connection timed out
mount.nfs: trying text-based options 'vers=3,tcp,soft,nolock,addr=10.0.0.136'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.0.0.136 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=6
mount.nfs: trying 10.0.0.136 prog 100005 vers 3 prot TCP port 56755
mount.nfs: mount(2): Connection timed out
mount.nfs: trying text-based options 'vers=3,tcp,soft,nolock,addr=10.0.0.136'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.0.0.136 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=6
mount.nfs: trying 10.0.0.136 prog 100005 vers 3 prot TCP port 56755

# showmount -e nfsserver
Export list for 10.0.0.136:
/images/dev 10.0.0.0/24
/images     10.0.0.0/24

Он работает должным образом, когда я подключаюсь с другого виртуального хоста на той же платформе VM - в данном случае Debian 9 / VirtualBox: Мгновенное монтирование и мгновенный ответ "showmount -e".

# mount -vt nfs nfsserver:/images /mnt/test
mount.nfs: timeout set for Wed Jan 31 01:03:30 2018
mount.nfs: trying text-based options 'vers=4.2,addr=10.0.0.136,clientaddr=10.0.0.108'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'addr=10.0.0.136'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.0.0.136 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 10.0.0.136 prog 100005 vers 3 prot UDP port 33485

Это мой / etc / exports на nfsserver:

# cat /etc/exports
/images 10.0.0.0/24(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev 10.0.0.0/24(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

Это брандмауэр (отключен):

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Службы прослушивают:

# rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp  48327  mountd
    100005    1   tcp  47113  mountd
    100005    2   udp  50106  mountd
    100005    2   tcp  46029  mountd
    100005    3   udp  38832  mountd
    100005    3   tcp  46131  mountd
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049
    100227    3   tcp   2049
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049
    100227    3   udp   2049
    100021    1   udp  36259  nlockmgr
    100021    3   udp  36259  nlockmgr
    100021    4   udp  36259  nlockmgr
    100021    1   tcp  45767  nlockmgr
    100021    3   tcp  45767  nlockmgr
    100021    4   tcp  45767  nlockmgr

Сканирование портов от тайм-аута LAN-устройства показывает открытые порты:

# nmap -p 111,2049 -T4 -A nfsserver
Starting Nmap 7.40 ( https://nmap.org ) at 2018-01-31 00:22 CET
Nmap scan report for nfsserver (10.0.0.136)
Host is up (0.00079s latency).
rDNS record for 10.0.0.136: nfsserver
PORT     STATE SERVICE VERSION
111/tcp  open  rpcbind 2-4 (RPC #100000)
| rpcinfo:
|   program version   port/proto  service
|   100000  2,3,4        111/tcp  rpcbind
|   100000  2,3,4        111/udp  rpcbind
|   100003  2,3,4       2049/tcp  nfs
|   100003  2,3,4       2049/udp  nfs
|   100005  1,2,3      38832/udp  mountd
|   100005  1,2,3      46131/tcp  mountd
|   100021  1,3,4      36259/udp  nlockmgr
|   100021  1,3,4      45767/tcp  nlockmgr
|   100227  2,3         2049/tcp  nfs_acl
|_  100227  2,3         2049/udp  nfs_acl
2049/tcp open  nfs_acl 2-3 (RPC #100227)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.33 seconds

/etc/hosts.allow и /etc/hosts.deny оба пусты:

# cat /etc/hosts.allow /etc/hosts.deny
#

Пока что я реплицировал проблема на:

• RHEL 7 / VirtualBox
• Debian 9 / VirtualBox
• Fedora 13 / VirtualBox
• Debian 9 / VMWare Workstation Player 14
• Ubuntu 16 / VMWare Workstation Player 14

Это странно ! Пробуя это почти неделю, я сдаюсь вам, могущественные Боги Serverfault

Я невежественный и скромный!

Как мне подключиться к NFS-серверу, работающему на виртуальной машине, без тайм-аута?

] Edit: Спасибо за форматирование. Я пробовал tcpdumping на обоих концах, и кажется, что некоторые пакеты никогда не приходят на NFS-сервер внутри виртуальной машины. Похоже, проблема с сетью глубоко внутри виртуального бокса. Тем не менее, все еще невежественен ..