pfSense 2.4.4 nfs client

CB55

у меня как-то по другому дамп выглядит
tcpdump -i hn0 host 192.168.1.13
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on hn0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:58:31.149580 IP v-gw.enisey.local.930 > 192.168.1.13.sunrpc: UDP, length 56
18:58:31.151472 IP 192.168.1.13.sunrpc > v-gw.enisey.local.930: UDP, length 28
18:58:31.151500 ARP, Request who-has v-gw.enisey.local tell 192.168.1.13, length 46
18:58:31.151525 ARP, Reply v-gw.enisey.local is-at 00:15:5d:01:2c:09 (oui Unknown), length 28
18:58:31.152459 IP v-gw.enisey.local.735 > 192.168.1.13.nfsd: Flags [S], seq 366827208, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 3267976 ecr 0], length 0
18:58:34.176301 IP v-gw.enisey.local.735 > 192.168.1.13.nfsd: Flags [S], seq 366827208, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 3271002 ecr 0], length 0

Konstanti

@CB55

Ну , вот что видно
Что SYN пакет есть , а вот ответа от сервера нет
Возможно , на сервере NFS настроен контроль доступа с определенных адресов
Если не секрет , а зачем подключать файрвол к nfs серверу ?

werter

Если не секрет , а зачем подключать файрвол к nfs серверу ?

Предположу, для того, чтобы не давать прямо доступ извне к NFS на Вин-сервере (?) Или же на nfs периодически сбрасываются бэкапы чего-то, что живет на пф.

@CB55
(Если есть возможность) "Правильный" NFS (и не только NFS) - это NFS развернутый на *nix.
Xigmanas https://2gusia.livejournal.com/30360.html, FreeNAS, OMV в помощь. У самого nfs, ftp, win-шары 3-й год живут на Xigmanas. Сам Xigmanas грузится с флешки + 4 HDD в ZFS RAID-Z2 (двойная избыточность, позволяет пережить выход из строя ЛЮБЫХ 2-ух hdd из массива (в отличие от raid10) )

CB55

извините за молчание, на выезде был
@Konstanti на Win адреса машинки добавлены , когда стоит запрет - Вин в лог пишет, что была попытка соединения с запрещенного адреса .. В любом случае - спасибо. Буду еще ее ковырять.

@werter - спасибо, подумаю о смене ..

Задача, с удаленных точек заливать объемные файлы рсинхом поверх SSH с ключем
на толстый ресурс виндовый и далее с ними работа идет на винде, при этом Не выставлять винду напрямую в инет. Думал что NFS будет более правильнее , чем Samba..

Буду дальше думать, как вариант прокидывать на другой линукс и мапить ресурсы на нем уже..

smils

@CB55 said in pfSense 2.4.4 nfs client:

18:58:31.149580 IP v-gw.enisey.local.930 > 192.168.1.13.sunrpc: UDP, length 56
18:58:31.151472 IP 192.168.1.13.sunrpc > v-gw.enisey.local.930: UDP, length 28
18:58:31.151500 ARP, Request who-has v-gw.enisey.local tell 192.168.1.13, length 46
18:58:31.151525 ARP, Reply v-gw.enisey.local is-at 00:15:5d:01:2c:09 (oui Unknown), length 28
18:58:31.152459 IP v-gw.enisey.local.735 > 192.168.1.13.nfsd: Flags [S], seq 366827208, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 3267976 ecr 0], length 0
18:58:34.176301 IP v-gw.enisey.local.735 > 192.168.1.13.nfsd: Flags [S], seq 366827208, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 3271002 ecr 0], length 0

gw.enisey.local -это WAN ?

CB55

@smils дамп на самом шлюзе смотрел, на нем же
nslookup v-gw.enisey.local
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: v-gw.enisey.local
Address: 192.168.1.14
т.е. LAN

Konstanti

@CB55 покажите вывод команды
ifconfig -m

какая сетевая на lan интерфейсе ???

CB55

@Konstanti
ifconfig -m

enc0: flags=0<> metric 0 mtu 1536
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: enc
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        capabilities=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: lo
pflog0: flags=100<PROMISC> metric 0 mtu 33160
        groups: pflog
pfsync0: flags=0<> metric 0 mtu 1500
        groups: pfsync
        syncpeer: 224.0.0.240 maxupd: 128 defer: on
        syncok: 1
hn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
 options=48001b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,LINKSTATE,TXCSUM_IPV6>
        capabilities=48071b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,TSO6,LRO,LINKSTATE,TXCSUM_IPV6>
        ether 00:15:5d:01:2c:09
        hwaddr 00:15:5d:01:2c:09
        inet6 fe80::215:5dff:fe01:2c09%hn0 prefixlen 64 scopeid 0x5
        inet 192.168.1.14 netmask 0xfffffe00 broadcast 192.168.1.255
        inet 192.168.5.254 netmask 0xffffff00 broadcast 192.168.5.255
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect (10Gbase-T <full-duplex>)
        status: active
        supported media:
                media autoselect
hn1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=48001b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,LINKSTATE,TXCSUM_IPV6>
        capabilities=48071b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,TSO6,LRO,LINKSTATE,TXCSUM_IPV6>
        ether 00:15:5d:01:2c:0b
        hwaddr 00:15:5d:01:2c:0b
        inet6 fe80::215:5dff:fe01:2c0b%hn1 prefixlen 64 scopeid 0x6
        inet 95.156.aaa.aaa netmask 0xfffffffc broadcast 95.156.aaa.aab
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect (10Gbase-T <full-duplex>)
        status: active
        supported media:
                media autoselect
hn1.400: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        capabilities=80000<LINKSTATE>
        ether 00:15:5d:01:2c:0b
        inet6 fe80::215:5dff:fe01:2c0b%hn1.400 prefixlen 64 scopeid 0x7
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect (10Gbase-T <full-duplex>)
        status: active
        supported media:
                media autoselect
        vlan: 400 vlanpcp: 0 parent interface: hn1
        groups: vlan

Живет на виртуалке под управлением Hyper-V Server 2016 10.0.14393

Konstanti

@CB55 Попробуйте сделать так
Разумное объяснение происходящему я вижу только одно
Адаптер lan ( hn0) неверно считает контрольные суммы tcp - у Вас это включено , и сетевой стек клиента отбрасывает эти пакеты
Попробуйте отключить это в настройках
/Advanced/ networking

werter

@CB55
Хто ж те мануалы читает ) https://docs.netgate.com/pfsense/en/latest/virtualization/index.html

Живет на виртуалке под управлением Hyper-V Server 2016 10.0.14393

О, нет (
С VLAN-ами я на Гипер-в "натанцевался" в волю. Спасибо, не надо. Только никсы в качестве гипера.

CB55

@werter А что не так с VLAN ? в 2016 весьма аккуратно работает.
по ссылке, я так понимаю посыл к поколению VM?
2.4.4 --1поколения, так как получилась после обновления 2.3
Сейчас , новую версию, рекомендуют ставить на 2 поколение
"If you’re installing pfSense software version 2.3.x, select Generation 1. If you are installing pfSense software version 2.4.x, select Generation 2."

CB55

@Konstanti что-то сразу не отписался,
НЕ помогло..
попробую чистую установку тестовую сделать...

Винда запросы видит и шлет ответ, а вот он, похоже, не долетает

CB55

Что-то чудеса совсем, на тот же сервер раскатал свежую версию.
Не пашет NFS .. думать дальше, буду искать что режет :( Похоже, где-то "по пути"..

Konstanti

@CB55 Здр
Находясь в одной сети хосты общаются "напрямую" . Со стороны PF ,если первый пакет прошел через все правила файрвола успешно, то ответный пакет уже не проверяется на соответствие правилам. Те проблем с этой стороны быть не должно
Попробуйте запустить tcpdump на хосте windows и посмотрите , что он покажет