Проблема с брандмауэром с помощью autofs с экспортируемым из NFS монтированием
Я успешно настроил рабочую систему сервера/клиента NFS на своих машинах локальной сети.Мне очень нравится!
Но, став утомленным от длительной задержки, когда монтирование не доступно в течение времени начальной загрузки, я решил поднять @ridgy на его предложении для использования autofs для монтирования долей вместо этого - использование информации из этого сообщения.
У меня были проблемы брандмауэра прежде, Так, я сразу подозревал, что ufw мог бы быть причиной таймаута монтирования. Так, я отключил ufw на сервере и клиенте. И, конечно же; Это получило autofs, работающий приятно. Так, я уверен, что базовая конфигурация корректна.
Единственные другие правила в ufw в этой точке, ПОЗВОЛЯЮТ правила для портов 2078 и 6589. Нет никаких настроенных правил БЛОКА. И, так как NFS хорошо работает с ufw на во время fstab-управляемого монтирования, я немного смущен как, туда, где блокировка происходит.
До сих пор я не нашел документацию относительно того, какие порты/протоколы уникальны для autofs помимо обычного TCP/UDP NFS 111,2049.
Каждый раз, когда я повторно включаю ufw. Доли становятся недоступными снова.
Какие-либо идеи?
@ridgy
После следования Вашему совету ниже для редактирования общий для nfs и сервер ядра nfs.. Я трижды проверил, и редактирования были сделаны точно как показано. Я перезагрузил и работал...
$sudo netstat -nalp | grep rpc... Вывод был;
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1220/rpcbind
tcp 0 0 0.0.0.0:32767 0.0.0.0:* LISTEN 4158/rpc.mountd
tcp6 0 0 :::111 :::* LISTEN 1220/rpcbind
tcp6 0 0 :::32767 :::* LISTEN 4158/rpc.mountd
udp 0 0 0.0.0.0:972 0.0.0.0:* 1220/rpcbind
udp 0 0 0.0.0.0:32767 0.0.0.0:* 4158/rpc.mountd
udp 0 0 0.0.0.0:111 0.0.0.0:* 1220/rpcbind
udp6 0 0 :::972 :::* 1220/rpcbind
udp6 0 0 :::32767 :::* 4158/rpc.mountd
udp6 0 0 :::111 :::* 1220/rpcbind
unix 2 [ ACC ] STREAM LISTENING 15939 1/init /run/rpcbind.sock
unix 2 [ ] DGRAM 49175 4158/rpc.mountd
unix 3 [ ] STREAM CONNECTED 48294 1220/rpcbind /run/rpcbind.sock
unix 3 [ ] STREAM CONNECTED 16984 1220/rpcbind
unix 3 [ ] STREAM CONNECTED 48275 4157/rpc.idmapd
unix 3 [ ] STREAM CONNECTED 48276 4157/rpc.idmapd
Хорошо... Так, интересно... Где rpc.statd??? Кроме того, мои доли NFS (autofs был все еще отключен) были все еще видимы от клиента. даже при том, что брандмауэр не был обновлен с новым rpc.mountd портом 32767.
1 ответ
В конце itwas не, который усложнил, после подсказок в Обеспечении NFS. Я изменил файлы /etc/default/nfs-common и /etc/default/nfs-kernel-server соответственно:
общий для nfs:
.
.
# Options for rpc.statd.
# Should rpc.statd listen on a specific port? This is especially useful
# when you have a port-based firewall. To use a fixed port, set this
# this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
# For more information, see rpc.statd(8) or http://wiki.debian.org/SecuringNFS
STATDOPTS="--port 32765 --outgoing-port 32766"
.
.
сервер ядра nfs:
.
.
# Options for rpc.mountd.
# If you have a port-based firewall, you might want to set up
# a fixed port here using the --port option. For more information,
# see rpc.mountd(8) or http://wiki.debian.org/SecuringNFS
# To disable NFSv4 on the server, specify '--no-nfs-version 4' here
RPCMOUNTDOPTS="--manage-gids --port 32767"
.
.
Почему те порты? Как 32767 самое высокое 15bit-количество, очень маловероятно, что эти порты уже используются чем-то еще.
Я не использую квоты, таким образом, я не изменил /etc/default/quota как предложено. И я должен был перезагрузить после того, как я внес эти изменения. Затем я видел результат с
$ sudo netstat -nalp | grep rpc
tcp 0 0 0.0.0.0:32767 0.0.0.0:* LISTEN 1018/rpc.mountd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 735/rpcbind
tcp 0 0 0.0.0.0:32765 0.0.0.0:* LISTEN 806/rpc.statd
tcp6 0 0 :::32767 :::* LISTEN 1018/rpc.mountd
tcp6 0 0 :::111 :::* LISTEN 735/rpcbind
tcp6 0 0 :::32765 :::* LISTEN 806/rpc.statd
udp 0 0 0.0.0.0:875 0.0.0.0:* 735/rpcbind
udp 0 0 127.0.0.1:982 0.0.0.0:* 806/rpc.statd
udp 0 0 0.0.0.0:32765 0.0.0.0:* 806/rpc.statd
udp 0 0 0.0.0.0:32767 0.0.0.0:* 1018/rpc.mountd
udp 0 0 0.0.0.0:111 0.0.0.0:* 735/rpcbind
udp6 0 0 :::875 :::* 735/rpcbind
udp6 0 0 :::32765 :::* 806/rpc.statd
udp6 0 0 :::32767 :::* 1018/rpc.mountd
udp6 0 0 :::111 :::* 735/rpcbind
unix 2 [ ACC ] STREAM LISTENING 11412 735/rpcbind /run/rpcbind.sock
unix 2 [ ] DGRAM 9521 806/rpc.statd
unix 2 [ ] DGRAM 9614 1018/rpc.mountd
unix 3 [ ] STREAM CONNECTED 11721 862/rpc.idmapd
unix 3 [ ] STREAM CONNECTED 11722 862/rpc.idmapd
Как Вы видите, порты rpc.mountd и rpc.statd слушают теперь статичны.
При вводе showmountна клиенте (здесь 192.168.192.20), Wireshark показывает коммуникацию (сервер 192.168.192.111). Важный здесь: GETPORT Call и GETPORT reply, который возвращается Port:32767. Коммуникация затем использует этот порт.
Теперь необходимо смочь изменить правила брандмауэра соответственно и затем использовать showmountи autofs через брандмауэр.
Только для справки
После подсказок в комментариях и моем собственном опыте, я нашел другое поведение в различных дистрибутивах:
- В токе
raspbian jessie(на основеdebian), существует сервисnfs-common(файл/etc/init.d/nfs-common), который при включении запускается, например.rpc.statdпри начальной загрузке, уважая параметры порта в/etc/default/nfs-common. - В токе
Ubuntu 16.04нет такого сервиса.rpc.statdне запускается при начальной загрузке, поскольку это не нужно с NFS V4. Но как толькоmount .... -o nfsvers=3сделан,rpc.statdзапускается, уважая параметры порта в/etc/default/nfs-common.
Я не нашел последовательную документацию относительно этого; в том, Как настроить NFS файл /etc/init.d/nfs-common явно упоминается, хотя это не находится в пакете. Если бы у кого-либо есть подсказки/ссылки, на которых это было бы богато заслужено.
Еще один комментарий: man rpc.mountd и man rpc.statd скажите (для опции --port):
"Если эта опция не будет указана, то rpc.statd попытается консультироваться с/etc/services, если доберется, порт следуют, устанавливают тот же порт для всего сокета слушателя, иначе выбирает случайный эфемерный порт для каждого сокета слушателя".
Устанавливая порты в /etc/services (как предложено в вышеупомянутой Wiki), это не работало. Так изменяя файлы в /etc/default кажется обязательным - страницы справочника не корректны в той точке.