LINUX.ORG.RU
решено Форум — Admin  

Проблема с маршрутизацией в Debian 7.3


0

1

Привет всем!

Нужна помощь, ибо не понимаю что именно происходит.

Вкратце, есть домашняя сеть, есть два сервера: один в роли NAS с кучей VLANов (VLAN per client), название сервера - NAS1BHV.

Есть сервер в роли DNS и биллинга, название - сервера BILL1BHV.

Настройки сети отдаются клиентам по DHCP. DHCP-сервер установлен на NAS1BHV, запросы от клиентов перенаправляются с коммутатора аггрегации с помощью dhcp-relay.

Конфигурация сети на NAS1BHV: 

root@NAS1BHV:~# ip link ls
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000
    link/ether 2c:59:e5:9a:ac:ac brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 2c:59:e5:9a:ac:ad brd ff:ff:ff:ff:ff:ff
4: eth0.1201@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP mode DEFAULT 
    link/ether 2c:59:e5:9a:ac:ac brd ff:ff:ff:ff:ff:ff
5: eth0.1202@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether 2c:59:e5:9a:ac:ac brd ff:ff:ff:ff:ff:ff
6: eth0.1203@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether 2c:59:e5:9a:ac:ac brd ff:ff:ff:ff:ff:ff
7: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether 2c:59:e5:9a:ac:ac brd ff:ff:ff:ff:ff:ff

...

72: eth0.342@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
    link/ether 2c:59:e5:9a:ac:ac brd ff:ff:ff:ff:ff:ff

root@NAS1BHV:~# ip addr ls
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet 172.16.0.254/32 scope global lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 2c:59:e5:9a:ac:ac brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2e59:e5ff:fe9a:acac/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 2c:59:e5:9a:ac:ad brd ff:ff:ff:ff:ff:ff
4: eth0.1201@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP 
    link/ether 2c:59:e5:9a:ac:ac brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.1/24 brd 10.1.1.255 scope global eth0.1201
    inet6 fe80::2e59:e5ff:fe9a:acac/64 scope link 
       valid_lft forever preferred_lft forever
5: eth0.1202@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 2c:59:e5:9a:ac:ac brd ff:ff:ff:ff:ff:ff
    inet 10.2.2.1/24 brd 10.2.2.255 scope global eth0.1202
    inet6 fe80::2e59:e5ff:fe9a:acac/64 scope link 
       valid_lft forever preferred_lft forever
6: eth0.1203@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 2c:59:e5:9a:ac:ac brd ff:ff:ff:ff:ff:ff
    inet 10.3.3.1/24 brd 10.3.3.255 scope global eth0.1203
    inet6 fe80::2e59:e5ff:fe9a:acac/64 scope link 
       valid_lft forever preferred_lft forever
7: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 2c:59:e5:9a:ac:ac brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2e59:e5ff:fe9a:acac/64 scope link 
       valid_lft forever preferred_lft forever

...

72: eth0.342@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 2c:59:e5:9a:ac:ac brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2e59:e5ff:fe9a:acac/64 scope link
       valid_lft forever preferred_lft forever

root@NAS1BHV:~# ip r ls
default via 10.1.1.253 dev eth0.1201 
10.1.1.0/24 dev eth0.1201  proto kernel  scope link  src 10.1.1.1 
10.2.2.0/24 dev eth0.1202  proto kernel  scope link  src 10.2.2.1 
10.3.3.0/24 dev eth0.1203  proto kernel  scope link  src 10.3.3.1 
unreachable 172.16.0.0/24 
172.16.0.2 dev eth0.2  scope link  src 172.16.0.254

...

172.16.0.89 dev eth0.342  scope link  src 172.16.0.254

Конфигурация сети на BILL1BHV: 

root@BILL1BHV:~# ip r
default via 10.3.3.254 dev eth0.1203 
10.3.3.0/24 dev eth0.1203  proto kernel  scope link  src 10.3.3.253 
172.16.0.0/22 via 10.3.3.1 dev eth0.1203

Вывод комманд, выполненных на BILL1BHV. 172.16.0.2 и 172.16.0.89 два разных клиента, к тому же они без проблем обращаются с dns, http-запросами к BILL1BHV, настройки сети у этих клиентов идентичны, основным шлюзом: 172.16.0.254, то есть NAS1BHV. Вот проблема: 

root@BILL1BHV:~# tracepath -n 172.16.0.2
 1:  10.3.3.253                                            0.101ms pmtu 1500
 1:  10.3.3.1                                              0.215ms
 1:  10.3.3.1                                              0.226ms
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
...
30:  no reply
31:  no reply
     Too many hops: pmtu 1500
     Resume: pmtu 1500

root@BILL1BHV:~# tracepath -n 172.16.0.89
 1:  10.3.3.253                                            0.095ms pmtu 1500
 1:  10.3.3.1                                              0.212ms
 1:  10.3.3.1                                              0.293ms
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 ...
30:  no reply
31:  no reply
     Too many hops: pmtu 1500
     Resume: pmtu 1500

root@BILL1BHV:~# ping -R 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(124) bytes of data.
64 bytes from 172.16.0.2: icmp_req=1 ttl=63 time=0.826 ms
RR:     10.3.3.253
        172.16.0.254
        172.16.0.2
        172.16.0.2
        10.3.3.1
        10.3.3.253

64 bytes from 172.16.0.2: icmp_req=2 ttl=63 time=0.693 ms       (same route)
64 bytes from 172.16.0.2: icmp_req=3 ttl=63 time=0.717 ms       (same route)
64 bytes from 172.16.0.2: icmp_req=4 ttl=63 time=0.693 ms       (same route)
64 bytes from 172.16.0.2: icmp_req=5 ttl=63 time=0.699 ms       (same route)
64 bytes from 172.16.0.2: icmp_req=6 ttl=63 time=0.719 ms       (same route)
64 bytes from 172.16.0.2: icmp_req=7 ttl=63 time=0.690 ms       (same route)
64 bytes from 172.16.0.2: icmp_req=8 ttl=63 time=0.714 ms       (same route)

root@BILL1BHV:~# ping -R 172.16.0.89
PING 172.16.0.89 (172.16.0.89) 56(124) bytes of data.
^C
--- 172.16.0.89 ping statistics ---
29 packets transmitted, 0 received, 100% packet loss, time 27999ms

Чувствую, что где-то накосячил, но не вижу где именно.

P.S. С сервера NAS1BHV все клиенты пингуются без проблем.


← Чем (и как) правильно синхронизиоровать 1М (4гб) мелких файлов?
«Красиво» ли складывать свои бэкапы в /var/backups? →
Ответ на: комментарий от af5

Да, маска /24.

В том то и дело, что трафик от клиентов бегает и в интернеты, и на NAS и на DNS-сервер, с которого их пингануть и трассировать не удаётся.

maxt_t
() автор топика
Ответ на: комментарий от af5

На картинке это означает, что для клиентов выделено адресное пространство 172.16.0.0/22. То есть на один NAS запланировано 1022 клиента.

Вот как заводятся клиенты на NASe:

ip route add unreachable 172.16.0.0/24
ip addr add 172.16.0.254/32 dev lo

vconfig add eth0 2
ip link set eth0.2 up
ip route add 172.16.0.2/32 dev eth0.2 src 172.16.0.254

vconfig add eth0 342
ip link set eth0.342 up
ip route add 172.16.0.89/32 dev eth0.342 src 172.16.0.254

ip route add unreachable 172.16.1.0/24
ip addr add 172.16.1.254/32 dev lo

vconfig add eth0 1000
ip link set eth0.1000 up
ip route add 172.16.1.1/32 dev eth0.1000 src 172.16.1.254

и т.д.

maxt_t
() автор топика
Ответ на: комментарий от maxt_t

Всегда одни и те же не доступны или меняется картина? Сколько процентов из всех недоступны? Что если сделать down/up бажного vlan интерфейса?

af5 ★★★★★
()
Последнее исправление: af5 (всего исправлений: 1)
Ответ на: комментарий от af5

Кхм... Сложно сказать. Сегодня только заметил.

Если взять два VLANа, который приводил в «простыне» в начале поста, то пробовал удалять/создавать эти VLAN, картина не поменялась.

Завтра буду на объекте, буду посмотреть более детально. Правда нет идей, куда именно смотреть.

maxt_t
() автор топика
Ответ на: комментарий от af5

Просто ping не работает также.

iptables на NAS и BILL в default policy ACCEPT, никаких правил фильтрации и шейпинга.

На клиентах, чёрт его знает. Делаю предположение: если с NAS клиент пингуется, если трафик от клиента проходит на BILL (вижу, что BILL ресолвит dns имена на запросы клиента, вижу соединения на 53-ем порту от клиента), то как-бы на клиенте (в основном виндовые) фаервол либо отключён, либо с облегчёнными настройками.

Такое впечатление, что косяк именно с NAS. Поскольку с RB (роутер, который непосредственно уже натит клиентов в интернет) та же ситуация, что и с BILL.

maxt_t
() автор топика
Ответ на: комментарий от af5

К нормальным клиентам выглядит так -

от BILL:

root@BILL1BHV:~# tracepath -n 172.16.0.91
 1:  10.3.3.253                                            0.156ms pmtu 1500
 1:  10.3.3.1                                              0.215ms
 1:  10.3.3.1                                              0.152ms
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
31:  no reply
     Too many hops: pmtu 1500
     Resume: pmtu 1500
     
root@BILL1BHV:~# ping -R 172.16.0.91
PING 172.16.0.91 (172.16.0.91) 56(124) bytes of data.
64 bytes from 172.16.0.91: icmp_req=1 ttl=127 time=0.455 ms
NOP
RR:     10.3.3.253
        172.16.0.254
        172.16.0.91
        10.3.3.1
        10.3.3.253

64 bytes from 172.16.0.91: icmp_req=2 ttl=127 time=0.550 ms
NOP     (same route)
64 bytes from 172.16.0.91: icmp_req=3 ttl=127 time=0.453 ms
NOP     (same route)
64 bytes from 172.16.0.91: icmp_req=4 ttl=127 time=0.518 ms
NOP     (same route)
64 bytes from 172.16.0.91: icmp_req=5 ttl=127 time=0.471 ms
NOP     (same route)
64 bytes from 172.16.0.91: icmp_req=6 ttl=127 time=0.475 ms
NOP     (same route)
64 bytes from 172.16.0.91: icmp_req=7 ttl=127 time=0.450 ms
NOP     (same route)
64 bytes from 172.16.0.91: icmp_req=8 ttl=127 time=0.455 ms
NOP     (same route)
64 bytes from 172.16.0.91: icmp_req=9 ttl=127 time=0.491 ms
NOP     (same route)
^C
--- 172.16.0.91 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 7999ms
rtt min/avg/max/mdev = 0.450/0.479/0.550/0.042 ms

root@BILL1BHV:~# mtr -n -c 5 -r 172.16.0.91
HOST: BILL1BHV                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.3.3.1                   0.0%     5    0.3   0.2   0.1   0.3   0.1
  2.|-- 172.16.0.91                0.0%     5    0.4   0.5   0.4   0.5   0.0

От RB. Там Cisco 2911, я в цисках не силён, поэтому привожу только ping и traceroute. Да, на ней ip route 172.16.0.0 255.255.252.0 10.1.1.1 10.1.1.1 - это NAS:

RB1BHV#traceroute ip 172.16.0.91
Type escape sequence to abort.
Tracing the route to 172.16.0.91
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.1.1 0 msec 0 msec 0 msec
  2  *  *  * 
  3  *  *  * 
  4  *  *  * 
  5  *  *  * 
  6  *  *  *
  7  *  *  *
  8  *  *  *
  9  *  *  *
 10  *  *  *
 11  *  *  *
 12  *  *  *
 13  *  *  *
 14  *  *  *
 15  *  *  *
 16  *  *  *
 17  *  *  *
 18  *  *  *
 19  *  *  *
 20  *  *  *
 21  *  *  *
 22  *  *  *
 23  *  *  *
 24  *  *  *
 25  *  *  *
 26  *  *  *
 27  *  *  *
 28  *  *  *
 29  *  *  *
 30  *  *  *
 
RB1BHV#ping ip 172.16.0.91
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.91, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Теперь от NAS (уже интересно стало):

root@NAS1BHV:~# tracepath -n 172.16.0.91
 1:  172.16.0.254                                          0.076ms pmtu 1500
 1:  no reply
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
31:  no reply
     Too many hops: pmtu 1500
     Resume: pmtu 1500
     
root@NAS1BHV:~# ping -R 172.16.0.91
PING 172.16.0.91 (172.16.0.91) 56(124) bytes of data.
64 bytes from 172.16.0.91: icmp_req=1 ttl=128 time=0.309 ms
NOP
RR:     172.16.0.254
        172.16.0.91
        172.16.0.254

64 bytes from 172.16.0.91: icmp_req=2 ttl=128 time=0.307 ms
NOP     (same route)
64 bytes from 172.16.0.91: icmp_req=3 ttl=128 time=0.281 ms
NOP     (same route)
64 bytes from 172.16.0.91: icmp_req=4 ttl=128 time=0.254 ms
NOP     (same route)
64 bytes from 172.16.0.91: icmp_req=5 ttl=128 time=0.304 ms
NOP     (same route)
64 bytes from 172.16.0.91: icmp_req=6 ttl=128 time=0.293 ms
NOP     (same route)
^C
--- 172.16.0.91 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 4998ms
rtt min/avg/max/mdev = 0.254/0.291/0.309/0.023 ms

root@NAS1BHV:~# mtr -n -c 5 -r 172.16.0.91
HOST: NAS1BHV                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.0.91                0.0%     5    0.3   0.3   0.3   0.3   0.0

Кстати, настораживает очень NOP в пинге. Что за флаг?

И если повторить все команды для другого «нормального» клиента 172.16.0.10, то картина с tracepath и mtr идентична, но с пингом иначе:

root@BILL1BHV:~# ping -R 172.16.0.10
PING 172.16.0.10 (172.16.0.10) 56(124) bytes of data.
64 bytes from 172.16.0.10: icmp_req=1 ttl=63 time=0.622 ms
RR:     10.3.3.253
        172.16.0.254
        172.16.0.10
        172.16.0.10
        10.3.3.1
        10.3.3.253

64 bytes from 172.16.0.10: icmp_req=2 ttl=63 time=0.724 ms      (same route)
64 bytes from 172.16.0.10: icmp_req=3 ttl=63 time=0.535 ms      (same route)
64 bytes from 172.16.0.10: icmp_req=4 ttl=63 time=0.602 ms      (same route)
^C
--- 172.16.0.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.535/0.620/0.724/0.074 ms

root@NAS1BHV:~# ping -R 172.16.0.10
PING 172.16.0.10 (172.16.0.10) 56(124) bytes of data.
64 bytes from 172.16.0.10: icmp_req=1 ttl=64 time=0.343 ms
RR:     172.16.0.254
        172.16.0.10
        172.16.0.10
        172.16.0.254

64 bytes from 172.16.0.10: icmp_req=2 ttl=64 time=0.348 ms      (same route)
64 bytes from 172.16.0.10: icmp_req=3 ttl=64 time=0.334 ms      (same route)
64 bytes from 172.16.0.10: icmp_req=4 ttl=64 time=0.330 ms      (same route)
^C
--- 172.16.0.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.330/0.338/0.348/0.023 ms
maxt_t
() автор топика
Ответ на: комментарий от maxt_t

Честно говоря первый раз вижу такую странную адресацию, клиенты в разных VLAN но в одной подсети и с одним шлюзом... Не уверен, что она вообще корректна, может проще сделать 30 бит на подсеть каждому клиенту?
P.S.
Покажи mtr ping tracepath между серваками

af5 ★★★★★
()
Последнее исправление: af5 (всего исправлений: 1)
Ответ на: комментарий от af5

Честно говоря первый раз вижу такую странную адресацию, клиенты в разных VLAN но в одной подсети и с одним шлюзом... Не уверен, что она вообще корректна, может проще сделать 30 бит на подсеть каждому клиенту?

Насколько я знаю, это симуляция цисковского IP Unnumbered, чтобы экономить «белые» адреса на броадкастах и основновных шлюзах.

Сеть досталась кхм... по «наследству», стараюсь разобраться с ней.

Между NAS, BILL и RB коммутатор L3 (10.3.3.254 IP), но, он не при делах, только выступает основным шлюзом для BILL.

Теперь, что между серваками:

BILL <=> NAS 

root@BILL1BHV:~# ping -R 172.16.0.254
PING 172.16.0.254 (172.16.0.254) 56(124) bytes of data.
64 bytes from 172.16.0.254: icmp_req=1 ttl=64 time=0.169 ms
RR:     10.3.3.253
        172.16.0.254
        172.16.0.254
        10.3.3.253

64 bytes from 172.16.0.254: icmp_req=2 ttl=64 time=0.131 ms     (same route)
64 bytes from 172.16.0.254: icmp_req=3 ttl=64 time=0.132 ms     (same route)
64 bytes from 172.16.0.254: icmp_req=4 ttl=64 time=0.165 ms     (same route)
64 bytes from 172.16.0.254: icmp_req=5 ttl=64 time=0.188 ms     (same route)
64 bytes from 172.16.0.254: icmp_req=6 ttl=64 time=0.109 ms     (same route)
64 bytes from 172.16.0.254: icmp_req=7 ttl=64 time=0.130 ms     (same route)
^C
--- 172.16.0.254 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 5999ms
rtt min/avg/max/mdev = 0.109/0.146/0.188/0.027 ms

root@BILL1BHV:~# tracepath -n 172.16.0.254
 1:  10.3.3.253                                            0.112ms pmtu 1500
 1:  172.16.0.254                                          0.207ms reached
 1:  172.16.0.254                                          0.282ms reached
     Resume: pmtu 1500 hops 1 back 64


root@BILL1BHV:~# mtr -n -c 5 -r 172.16.0.254
HOST: BILL1BHV                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.0.254               0.0%     5    0.2   0.2   0.1   0.2   0.0

NAS <=> BILL приводить не буду, ибо они в одном VLAN в 10.3.3.0/24 подсети. Надо пробовать «прикинувшись» клиентом с хоста, который в 172.16.0.0/24 подсети.

Ок. Спасибо за помощь! Завтра буду на объекте, буду как-то решать.

maxt_t
() автор топика

Может я не правильно понял, но похоже, что эти ваши некоторые клиенты отвечают на пинги только с src-адресом из своей подсети. То есть если их пинговать с NAS1BHV, но с адресом из сети 10.x.x.x пинг тоже не будет проходить. Это нормальное для винды поведение.

mky ★★★★★
()
Ответ на: комментарий от mky

Действительно, очень похоже: 

root@NAS1BHV:~# ping 172.16.0.57
PING 172.16.0.57 (172.16.0.57) 56(84) bytes of data.
64 bytes from 172.16.0.57: icmp_req=1 ttl=128 time=2.16 ms
64 bytes from 172.16.0.57: icmp_req=2 ttl=128 time=1.73 ms
^C
--- 172.16.0.57 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.734/1.947/2.160/0.213 ms

root@NAS1BHV:~# ping -I 10.3.3.1 172.16.0.57
PING 172.16.0.57 (172.16.0.57) from 10.3.3.1 : 56(84) bytes of data.
From 10.3.3.1 icmp_seq=1 Destination Host Unreachable
From 10.3.3.1 icmp_seq=3 Destination Host Unreachable
From 10.3.3.1 icmp_seq=4 Destination Host Unreachable
^C
--- 172.16.0.57 ping statistics ---
6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5000ms

Это обьясняет проблемы с пингом и трассировкой. Не знал о таком поведении винды.

Огромное спасибо!

maxt_t
() автор топика
Ответ на: комментарий от maxt_t

Если я правильно нагуглил, то за такое поведение винды отвечает ″BFE, Служба базовой фильтрации″. Я не знаю, почему на одних винозах она включана, а на других нет. Я уже давно не администрирую сети и по настройкам винды мне сказать нечего, но раньше сталкивался с таким не однократно.

Если вам нужен просто ping он BIL1BHV до любого включенного компа, то может просто сделать SNAT-правила или MASQURADE-правило на NAS1BHV для icmp-пакетов от BIL1BHV .

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Чем (и как) правильно синхронизиоровать 1М (4гб) мелких файлов?
Admin
«Красиво» ли складывать свои бэкапы в /var/backups? →