непонятная проблема с доступом к серверу

black-box · May 5, 2010, 11:16am

вопрос:
крутить настройки у себя на сервере
или теребить провайдера???

схема сети

до тех пор пока с opensuse не обратишься (пинг, трасерт) к w2k3, то с w2k3 никакие пакеты не доходят до opensuse.
после установления связи если нет активности то пакеты перестают опять ходить.
при этом с w2k3 пакеты свободно доходят до других
компов (winxp) из сети 192.168.14.0/24.

шлюзами является оборудование провайдера.
сетевые настройки серверов во вложеных файлах.

Gankov · May 5, 2010, 4:51pm

1 - Попробуйте включить эту опцию.
FW_ALLOW_PING_FW=“yes”

2 - А если попробовать отключить защиту внутреннго интерфейса, FW_PROTECT_FROM_INT=“no”
До суси тоже не достучатся?

Lazy_Kent · May 5, 2010, 8:04pm

Отключить на openSuse firewall и посмотреть, как будет работать. Поиск сузится. Или логи поизучать тщательно.
Слишком много правил написано.

black-box · May 6, 2010, 9:30am

спасибо за участие.

2 Gankov
не помогло.

2 Lazy_Kent
не помогло.

странно другое, сегодня наблюдаю вот такое

tracepath 192.168.11.15
 1:  serv-v (192.168.14.40)                                 0.152ms pmtu 1500
 1:  192.168.13.50 (192.168.13.50)                         88.718ms
 2:  192.168.11.15 (192.168.11.15)                         85.999ms reached
     Resume: pmtu 1500 hops 2 back 2

раньше вместо 192,168,13,50 было , но трасерт до цели проходил.
192,168,13,50 - это тоже какой то шлюз провайдера
вроде мы его даже не должны видеть. но видим
причём только с одной стороны… (192,168,14,)

да…
вырисовывается другая картина:
существует ещё одна машина winxpsp2 С ДВУМЯ сетевухами - ТОЧНО такая же история с доступом…

в какую сторону смотреть??? :’(

black-box · May 6, 2010, 10:28am

UPD
почти точно такая же - winxp пока связи не теряет
трасерт нормально проходит…

Lazy_Kent · May 6, 2010, 10:20pm

black-box, если я вас правильно понял, отключение файервола на openSUSE ничего не изменило? В таком случае можно сделать вывод, что проблема не в SUSE, а где-то на промежуточном этапе.

black-box · May 7, 2010, 7:58am

да. отключение файрвола не помогло.
(если под отключением понимается команда susefirewall2 stop)

вопрос - в каком месте?
провадер - такой (тут неразборчиво). нормальной поддержки трудно добиться.

тем более виндовые машины между собой БЕЗ проблем соединяются.
кроме ОДНОЙ, тоже с двумя сетвухами.
но тоже странно - вчера сделал трасерт с неё - и со вчерашнего дня спокойно до неё пакеты ходят.
(как будто чего то запомнила)

а опенсусе через некоторое время перестает отвечать…

может это связано с тем, что ответ идёт
не от 192.168.14.50 а 192.168.13.50???

Gankov · May 7, 2010, 10:33am

Я бы предложил попробовать поменять IP адрес SUSE на адрес машины для которой все работает и проверить, если проблемы не будет, то скорей всего что то у провайдера прописано лишнее для конкретных IP.

black-box · May 7, 2010, 11:47am

2 Gankov
ну как вариант конечно надо попробывать.

просто не до конца был уверен, что у меня всё правильно настроено.
поэтому не стал метаться и переделывать.

мысль крутится вокруг того, что у них по две сетевухи… может тут проблема…

Gankov · May 9, 2010, 8:44am

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

black-box · May 11, 2010, 12:53pm

вот


C:\>route print
===========================================================================
Список интерфейсов
0x1 ........................... MS TCP Loopback interface
0x2 ...00 1a 4d 38 d4 8e ...... Realtek RTL8169/8110 Family Gigabit Ethernet NIC
 - ¦шэшяюЁЄ яырэшЁют•шър яръхЄют
===========================================================================
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0    192.168.14.50   192.168.14.32       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
     192.168.14.0    255.255.255.0    192.168.14.32   192.168.14.32       20
    192.168.14.32  255.255.255.255        127.0.0.1       127.0.0.1       20
   192.168.14.255  255.255.255.255    192.168.14.32   192.168.14.32       20
        224.0.0.0        240.0.0.0    192.168.14.32   192.168.14.32       20
  255.255.255.255  255.255.255.255    192.168.14.32   192.168.14.32       1
Основной шлюз:       192.168.14.50
===========================================================================
Постоянные маршруты:
  Отсутствует

Gankov · May 11, 2010, 5:53pm

Ок предложу попробовать, на SUSE на время сделать шлюз по умолчанию провайдерский то есть 192.168.14.50 вдруг у провайдера не просто маршрутизация но какой нибудь NAT присутствует.

А вообще попробуйте понять приходят ли пакеты. например командой tcpdump ‘ip proto \icmp’ Может просто ответ уходит не туда.

black-box · May 12, 2010, 8:57am

хм, там у меня шлюз по умолчанию в интернет, при поднятии dsl0…
вот tcpdump’ы


трасерт от w2k3 до 192,168,14,40 (связи нет)

TCPDUMP.EXE -i 3 -f ip proto \icmp

TCPDUMP.EXE: listening on \Device\{487C9037-C6DC-4B7F-BBD0-974721D81EBF}
10:27:21.500000 IP w2k3 > 192.168.14.40: ICMP echo request, id 768, seq 28700, length 72
10:27:21.531250 IP 192.168.11.50 > w2k3: ICMP time exceeded in-transit, length 36
10:27:21.531250 IP w2k3 > 192.168.14.40: ICMP echo request, id 768, seq 28956, length 72
10:27:21.562500 IP 192.168.11.50 > w2k3: ICMP time exceeded in-transit, length 36
10:27:21.562500 IP w2k3 > 192.168.14.40: ICMP echo request, id 768, seq 29212, length 72
10:27:21.593750 IP 192.168.11.50 > w2k3: ICMP time exceeded in-transit, length 36
10:27:27.078125 IP w2k3 > 192.168.14.40: ICMP echo request, id 768, seq 29468, length 72
10:27:31.109375 IP w2k3 > 192.168.14.40: ICMP echo request, id 768, seq 29724, length 72
10:27:35.609375 IP w2k3 > 192.168.14.40: ICMP echo request, id 768, seq 29980, length 72
10:27:40.109375 IP w2k3 > 192.168.14.40: ICMP echo request, id 768, seq 30236, length 72
^C


трасерт от 192,168,14,40 до 192,168,11,15

tracepath 192.168.11.15
 1:  serv-v (192.168.14.40)                                 0.149ms pmtu 1500
 1:  192.168.13.50 (192.168.13.50)                         90.448ms
 2:  192.168.11.15 (192.168.11.15)                         86.816ms reached
     Resume: pmtu 1500 hops 2 back 2

tcpdump -i eth0 -n -nn -v 'ip proto \icmp'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
10:31:49.665725 IP (tos 0xc0, ttl 255, id 33357, offset 0, flags [none], proto ICMP (1), length 56) 192.168.13.50 > 192.168.14.40: ICMP time exceeded in-transit, length 36
        IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 1500) 192.168.14.40.15904 > 192.168.11.15.44444: UDP, length 1472
10:31:49.876894 IP (tos 0x0, ttl 127, id 34111, offset 0, flags [none], proto ICMP (1), length 176) 192.168.11.15 > 192.168.14.40: ICMP 192.168.11.15 udp port 44445 unreachable, length 156
        IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 1500) 192.168.14.40.15904 > 192.168.11.15.44445: UDP, length 1472|icmp]
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel


трасерт от w2k3 до 192,168,14,40 (связь есть)

tracert 192.168.14.40

Трассировка маршрута к 192.168.14.40 с максимальным числом прыжков 30

  1    32 ms    31 ms    31 ms  192.168.11.50
  2    62 ms    62 ms    62 ms  192.168.14.40

Трассировка завершена.

TCPDUMP.EXE: listening on \Device\{487C9037-C6DC-4B7F-BBD0-974721D81EBF}
10:35:24.156250 IP w2k3 > 192.168.14.40: ICMP echo request, id 768, seq 30492, length 72
10:35:24.187500 IP 192.168.11.50 > w2k3: ICMP time exceeded in-transit, length 36
10:35:24.187500 IP w2k3 > 192.168.14.40: ICMP echo request, id 768, seq 30748, length 72
10:35:24.218750 IP 192.168.11.50 > w2k3: ICMP time exceeded in-transit, length 36
10:35:24.218750 IP w2k3 > 192.168.14.40: ICMP echo request, id 768, seq 31004, length 72
10:35:24.250000 IP 192.168.11.50 > w2k3: ICMP time exceeded in-transit, length 36
10:35:29.734375 IP w2k3 > 192.168.14.40: ICMP echo request, id 768, seq 31260, length 72
10:35:29.796875 IP 192.168.14.40 > w2k3: ICMP echo reply, id 768, seq 31260, length 72
10:35:29.796875 IP w2k3 > 192.168.14.40: ICMP echo request, id 768, seq 31516, length 72
10:35:29.859375 IP 192.168.14.40 > w2k3: ICMP echo reply, id 768, seq 31516, length 72
10:35:29.859375 IP w2k3 > 192.168.14.40: ICMP echo request, id 768, seq 31772, length 72
10:35:29.906250 IP 192.168.14.40 > w2k3: ICMP echo reply, id 768, seq 31772, length 72
^C

Gankov · May 12, 2010, 10:32am

tcpdump запустить на SUSE и желательно без интерфейса -i eth0 мало ли ответы на другой уходять. а трайсерт делать с w2k3. Посмотреть когда “нет связи” пакеты на SUSE приходят или нет и откуда и куда уходят ответы.

black-box · May 12, 2010, 12:51pm

tcpdump -i any -n -nn -v 'ip proto \icmp'
tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

:shame:
и вот тут я попробывал после остановки файрвола
передёрнуть eth0 (ифдавн ифап)

и пакетики забегали :shame:

но наверно это не совсем правильно:

tcpdump -i any -n -nn -v 'ip proto \icmp'
tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
14:33:45.349664 IP (tos 0xc0, ttl 64, id 41844, offset 0, flags [none], proto ICMP (1), length 106) 192.168.14.40 > 192.168.11.15: ICMP 192.168.14.40 udp port 137 unreachable, length 86
        IP (tos 0x0, ttl 127, id 36921, offset 0, flags [none], proto UDP (17), length 78) 192.168.11.15.137 > 192.168.14.40.137: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
14:33:46.847969 IP (tos 0xc0, ttl 64, id 41845, offset 0, flags [none], proto ICMP (1), length 106) 192.168.14.40 > 192.168.11.15: ICMP 192.168.14.40 udp port 137 unreachable, length 86
        IP (tos 0x0, ttl 127, id 37695, offset 0, flags [none], proto UDP (17), length 78) 192.168.11.15.137 > 192.168.14.40.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
14:33:48.347112 IP (tos 0xc0, ttl 64, id 41846, offset 0, flags [none], proto ICMP (1), length 106) 192.168.14.40 > 192.168.11.15: ICMP 192.168.14.40 udp port 137 unreachable, length 86
        IP (tos 0x0, ttl 127, id 37827, offset 0, flags [none], proto UDP (17), length 78) 192.168.11.15.137 > 192.168.14.40.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
14:33:55.421613 IP (tos 0x0, ttl 1, id 38626, offset 0, flags [none], proto ICMP (1), length 92) 192.168.11.15 > 192.168.14.40: ICMP echo request, id 768, seq 51484, length 72
14:33:55.421651 IP (tos 0x0, ttl 64, id 41847, offset 0, flags [none], proto ICMP (1), length 92) 192.168.14.40 > 192.168.11.15: ICMP echo reply, id 768, seq 51484, length 72
14:33:55.532758 IP (tos 0x0, ttl 1, id 38635, offset 0, flags [none], proto ICMP (1), length 92) 192.168.11.15 > 192.168.14.40: ICMP echo request, id 768, seq 51740, length 72
14:33:55.532794 IP (tos 0x0, ttl 64, id 41848, offset 0, flags [none], proto ICMP (1), length 92) 192.168.14.40 > 192.168.11.15: ICMP echo reply, id 768, seq 51740, length 72
14:33:55.674876 IP (tos 0x0, ttl 1, id 38646, offset 0, flags [none], proto ICMP (1), length 92) 192.168.11.15 > 192.168.14.40: ICMP echo request, id 768, seq 51996, length 72
14:33:55.674902 IP (tos 0x0, ttl 64, id 41849, offset 0, flags [none], proto ICMP (1), length 92) 192.168.14.40 > 192.168.11.15: ICMP echo reply, id 768, seq 51996, length 72
14:33:55.860426 IP (tos 0xc0, ttl 64, id 41850, offset 0, flags [none], proto ICMP (1), length 106) 192.168.14.40 > 192.168.11.15: ICMP 192.168.14.40 udp port 137 unreachable, length 86
        IP (tos 0x0, ttl 127, id 38698, offset 0, flags [none], proto UDP (17), length 78) 192.168.11.15.137 > 192.168.14.40.137: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
14:33:57.346243 IP (tos 0xc0, ttl 64, id 41851, offset 0, flags [none], proto ICMP (1), length 106) 192.168.14.40 > 192.168.11.15: ICMP 192.168.14.40 udp port 137 unreachable, length 86
        IP (tos 0x0, ttl 127, id 40748, offset 0, flags [none], proto UDP (17), length 78) 192.168.11.15.137 > 192.168.14.40.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
14:33:58.845857 IP (tos 0xc0, ttl 64, id 41852, offset 0, flags [none], proto ICMP (1), length 106) 192.168.14.40 > 192.168.11.15: ICMP 192.168.14.40 udp port 137 unreachable, length 86
        IP (tos 0x0, ttl 127, id 46169, offset 0, flags [none], proto UDP (17), length 78) 192.168.11.15.137 > 192.168.14.40.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

Gankov · May 12, 2010, 2:07pm

Сдаюсь, больше толковых идей нет, только всякие глупости в голову приходят. Попробуйте все таки определится связана ли проблема с включенным фаерволом на openSUSE. Насколько я помню у вас в настройках влючено логирование отбрасываемых пакетов, может логи стоит проверить, может что нужное отбрасывается. Вобщем картина странная.

black-box · May 12, 2010, 2:27pm

в логах /var/log/firewall


cat firewall | grep "192.168.11.15"

May 12 10:34:36 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=2728 PROTO=UDP SPT=137 DPT=137 LEN=58
May 12 10:34:37 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=2746 PROTO=UDP SPT=137 DPT=137 LEN=58
May 12 10:34:39 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=2758 PROTO=UDP SPT=137 DPT=137 LEN=58
May 12 10:34:46 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=2842 PROTO=UDP SPT=137 DPT=137 LEN=58
May 12 10:34:48 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=2871 PROTO=UDP SPT=137 DPT=137 LEN=58
May 12 14:46:09 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=12442 PROTO=UDP SPT=137 DPT=137 LEN=58
May 12 14:46:10 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=14135 PROTO=UDP SPT=137 DPT=137 LEN=58
May 12 14:46:12 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=14255 PROTO=UDP SPT=137 DPT=137 LEN=58
May 12 14:46:19 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=16621 PROTO=UDP SPT=137 DPT=137 LEN=58
May 12 14:46:21 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=16681 PROTO=UDP SPT=137 DPT=137 LEN=58
May 12 14:46:41 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=17955 PROTO=UDP SPT=137 DPT=137 LEN=58
May 12 14:46:43 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=17974 PROTO=UDP SPT=137 DPT=137 LEN=58
May 12 14:46:44 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=18107 PROTO=UDP SPT=137 DPT=137 LEN=58
May 12 14:46:52 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=21198 PROTO=UDP SPT=137 DPT=137 LEN=58
May 12 14:46:53 serv-v kernel: SFW2-INint-DROP IN=eth0 OUT= MAC=6c:f0:49:52:f8:65:00:18:74:2e:13:80:08:00 SRC=192.168.11.15 DST=192.168.14.40 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=21588 PROTO=UDP SPT=137 DPT=137 LEN=58

black-box · May 12, 2010, 2:51pm

:посыпаю голову пеплом:

если сделать susefirewall2 stop и подождать некоторое время, то пакеты начинаю ходить.
ума не хватило подождать подольше, ну или передёрнуть eth0 (тогда пакеты бегают сразу).

тогда вопрос другой получается -
как настроить susefirewall2 чтобы работало при включенном файерволе?

ведь в логах из отброшенных пакетов от 192,168,11,15 только UDP 137.

может проблемы с icmp из-за опции

FW_KERNEL_SECURITY=“yes” ???

black-box · May 12, 2010, 3:07pm

2 all

всем большое спасибо за то, что пытались разобраться.

в общем так себя вела опция FW_KERNEL_SECURITY=“yes”
поставил no - всё стало работать.

насколько она нужна именно в практическом смысле?

black-box · May 12, 2010, 3:44pm

чёт рано порадовался, сейчас опять трасерт не проходит…

буду разбираться… не закрывайте пока!