Вот проблема, которую я затрудняюсь диагностировать:
Наши домашние каталоги пользователей обслуживаются через NFS с сервера Apple XServe под управлением Mac OS X 10.5.7. Обычно они экспортируются в нашу офисную подсеть по умолчанию, «lan». Недавно строил новую подсеть "ферма". Компьютеры на «ферме» работают под той же ОС (openSUSE 11.1 и Gentoo), что и на «lan», и версии программного обеспечения такие же.
Проблема в том, что когда мои пользователи какое-то время использовали машину на «ферме» (5 минут, иногда 30, иногда целый час), монтирование NFS, кажется, просто зависало. Попытка сделать ls в каталоге или что-либо еще (например, логин и т. д.), которое пытается получить доступ к домашнему каталогу пользователя, просто застревает. Монтирование других серверов NFS с "зависшей" машины работает, как ожидалось.
В журналах клиента или сервера нет ничего, что указывает на какую-либо проблему. Те же типы клиентов отлично работают в подсети "lan" по умолчанию.
Я пробовал всевозможные конфигурации сервера и клиента NFS (отключение / включение Kerberos, различные параметры монтирования), но, похоже, ничего не изменилось.
Я сильно подозреваю, что между этими двумя подсетями есть проблемы на уровне сети, возможно, некоторая ошибка брандмауэра / маршрутизатора (OpenBSD с pf в качестве фильтра пакетов). Связь между двумя наборами машин довольно проста: x serve --> switch --> router --> switch --> clients
Я в значительной степени не понимаю, какие методы отладки попробовать дальше или какое может быть возможное решение. Есть идеи, как подойти к этой проблеме с этого момента?
Обновить:
До сих пор не удалось решить эту проблему. Я думал, что пресек его в зародыше, когда отключил scrub на внутренних интерфейсах, но проблема снова проявилась. Что странно, похоже, что pf все еще изменяет некоторые пакеты.
Пример разговора на ферма сторона vlan:
09:17:39.165860 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472382:2887472382(0) win 5840 <mss 1460,sackOK,timestamp 236992843 0,nop,wscale 6> (DF)
09:17:39.166124 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 43 win 65535 <nop,nop,timestamp 316702204 236992843> (DF)
09:17:54.164490 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472385:2887472385(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:54.164760 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 1441270809:1441270809(0) ack 43 win 65535 (DF)
09:17:54.164776 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 4243886205:4243886205(0) ack 46 win 0 (DF)
09:17:54.164989 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:57.164066 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236997343 0,nop,wscale 6> (DF)
09:17:57.164330 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 49 win 65535 <nop,nop,timestamp 316702384 236997343> (DF)
09:18:03.163468 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236998843 0,nop,wscale 6> (DF)
09:18:03.163732 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 49 win 65535 <nop,nop,timestamp 316702444 236998843> (DF)
и то же самое на лан vlan:
09:17:39.165876 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472382:2887472382(0) win 5840 <mss 1460,sackOK,timestamp 236992843 0,nop,wscale 6> (DF)
09:17:39.166110 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702204 236992843> (DF)
09:17:54.164505 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472385:2887472385(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:54.164740 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 1:1(0) ack 1 win 65535 (DF)
09:17:54.164745 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 2802615397:2802615397(0) ack 4 win 0 (DF)
09:17:54.165003 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF)
09:17:54.165239 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702354 236996593,sackOK,eol> (DF)
09:17:55.123665 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702363 236996593,sackOK,eol> (DF)
09:17:57.124839 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702383 236996593,sackOK,eol> (DF)
09:17:57.164082 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236997343 0,nop,wscale 6> (DF)
09:17:57.164316 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702384 236997343> (DF)
09:18:01.126690 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702423 236997343,sackOK,eol> (DF)
09:18:03.163483 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236998843 0,nop,wscale 6> (DF)
09:18:03.163717 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702444 236998843> (DF)
Я также должен упомянуть, что у нас есть другой трафик NFS, проходящий через эту же машину, но с другого сервера NFS. Мы используем это в течение многих лет и не имели никаких проблем. Точно так же эти XServes долгое время обслуживали NFS для клиентов Linux в своей собственной подсети и продолжают это делать.
Просто хотел обновить это на случай, если кто-то столкнется с той же проблемой.
По сути, это сводится к государственным правилам в Pf. По умолчанию Pf сохраняет состояние и использует S / SA в качестве маски. Однако похоже, что реализация сервера NFS в OS X пытается начать диалог с клиентом, используя нестандартный набор флагов. Это приводило к сбою, потому что Pf просто отбрасывал пакеты. Я собрал это с помощью tcpdumping как интерфейса локальной сети, так и фермы. После настройки флагов состояния для правил между подсетями соединение было установлено правильно.
Однако, похоже, что Pf продолжал фильтровать некоторые пакеты из-за какой-то другой формы внутренней нормализации, и никакое количество настроек параметров, которые я пытался, не помогло заставить его работать.
В конце концов, я создал еще один интерфейс на файловом сервере и разместил его прямо в vlan фермы, полностью обойдя маршрутизатор.
Я не использовал pf; но я думаю, что это был один из первых фильтров с отслеживанием состояния. Может быть, это учет «связей» и их сброс?
Я бы поискал любое правило фильтра, зависящее от состояния. В Linux iptables обычно фильтр начинается с
ACCEPT all state RELATED,ESTABLISHED
потому что в этом случае не придется повторно проверять все соответствующие правила для каждого пакета после первого. Но поскольку NFS основан на UDP и не заботится о длительных (даже часах) периодах молчания, возможно, маршрутизатор теряет ESTABLISHED состояние, и новые пакеты для начала недействительны.
проверьте, есть ли какой-либо параметр keepalive, чтобы клиент отправлял пакеты подтверждения после минуты или около того молчания. если нет, попробуйте NFS через TCP. (у которого есть контрольные пакеты).
Первое, что нужно сделать, это убедиться, что брандмауэр действительно является виновником.
Для этого установите правила блокировки по умолчанию для ведения журнала. В моих брандмауэрах это две строки в верхней части правил фильтрации:
block in log
block out log
Подождите, пока монтирование NFS снова зависнет, и проверьте интерфейс журнала:
tcpdump -eeni pflog0 'host <client ip> and host <nfs server ip>'
Если вы видите, что эти пакеты заблокированы брандмауэром, опубликуйте свой pf.conf. Если нет, нам нужно начать смотреть дальше брандмауэра.