D-Link • Просмотр темы - Странная проблема DI-804HV (+)

Сообщения без ответов | Активные темы

Список форумов » Маршрутизаторы и Firewall

Часовой пояс: UTC + 3 часа

Странная проблема DI-804HV (+)

Модераторы: Sergei Asmankin, Sergik, Vitaliy Korkunov

Страница 1 из 1

[ Сообщений: 6 ]

Предыдущая тема | Следующая тема

Автор

Сообщение

aster

Заголовок сообщения: Странная проблема DI-804HV (+)

Добавлено: Пт июл 08, 2005 17:06

Зарегистрирован: Пт июл 08, 2005 15:56
Сообщений: 19
Откуда: С. - Петербург

Странная проблема, никак не могу понять в каком месте грабли: не работает терминальный клиент (или telnet.exe) до тех пор пока не обратишься каким либо образом (ping например) к требуемому узлу.
Итак исходные данные:
две сети:
192.168.77.0/24 - внешний ip 81.3.178.2 (например) - основная сеть
192.168.78.0/24 - внешний ip 2.178.3.81 (например) - удалённая сеть
В основной сети в роли vpn роутера выступает FreeBSD 5.4, в удалённой - DI-804HV
Настройка между ними - по доке http://www.dlink.ru/technical/faq_vpn_11.php

Пытаюсь с удалённой сети подключиться к терминальному серверу в основной сети:
(сразу оговорюсь, если вместо имён хостов использовать ip-адреса - ничего не меняется - дело не в резолвинге имён)

Код:

mstsc.exe -v server1

в ответ получаю:

Код:

The client could not connect to the remote computer

аналогичный ответ и если дать команду

Код:

telnet server1 3389
или, например, telnet server1 25

А вот если дать

Код:

ping server1

а затем

Код:

mstsc -v server1

то тогда всё замечательно.

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

Таким образом если написать bat-файлик start_term.bat:

Код:

ping server1 && mstsc -v server1

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

Вместо пинга можно использовать, например:
- найти и открыть server1 в "сетевом окружении"
- дать команду nbtstat -a ip_сервера
- WIN+R, \\server1\share

Прошивка в DI-804HV:
Current Firmware Version: V1.40b04
Firmware Date: Wed, Oct 06 2004

Проблема только со стороны удалённой подсети (со стороны DI-804HV)

Лог tcpdump на FreeBSD когда "нет связи":

Код:

vpn# tcpdump host 192.168.78
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes
17:50:32.295475 IP 192.168.78.24.1624 > 192.168.77.8.rdp: S 3458539821:3458539821(0) win 16384 <mss 1460,nop,nop,sackOK>
17:50:35.206906 IP 192.168.78.24.1624 > 192.168.77.8.rdp: S 3458539821:3458539821(0) win 16384 <mss 1460,nop,nop,sackOK>
17:50:41.216053 IP 192.168.78.24.1624 > 192.168.77.8.rdp: S 3458539821:3458539821(0) win 16384 <mss 1460,nop,nop,sackOK>
^C
3 packets captured
233 packets received by filter
0 packets dropped by kernel
vpn#

А теперь лог "пинга":

Код:

vpn# tcpdump host 192.168.78
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes
17:53:31.483641 IP 192.168.78.24 > 192.168.77.8: icmp 40: echo request seq 35073
17:53:31.484016 IP 192.168.77.8 > 192.168.78.24: icmp 40: echo reply seq 35073
17:53:32.486428 IP 192.168.78.24 > 192.168.77.8: icmp 40: echo request seq 35329
17:53:32.486799 IP 192.168.77.8 > 192.168.78.24: icmp 40: echo reply seq 35329
17:53:33.487934 IP 192.168.78.24 > 192.168.77.8: icmp 40: echo request seq 35585
17:53:33.488142 IP 192.168.77.8 > 192.168.78.24: icmp 40: echo reply seq 35585
17:53:34.489448 IP 192.168.78.24 > 192.168.77.8: icmp 40: echo request seq 35841
17:53:34.489694 IP 192.168.77.8 > 192.168.78.24: icmp 40: echo reply seq 35841
^C
8 packets captured
235 packets received by filter
0 packets dropped by kernel
vpn#

И теперь лог повторно "mstsc -v server1":

Код:

vpn# tcpdump host 192.168.78
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes
17:56:19.102119 IP 192.168.78.24.1628 > 192.168.77.8.rdp: S 4269411022:4269411022(0) win 16384 <mss 1460,nop,nop,sackOK>
17:56:19.102552 IP 192.168.77.8.rdp > 192.168.78.24.1628: S 3455605305:3455605305(0) ack 4269411023 win 16384 <mss 1460,nop,nop,sackOK>
17:56:19.104022 IP 192.168.78.24.1628 > 192.168.77.8.rdp: . ack 1 win 17520
17:56:19.104541 IP 192.168.78.24.1628 > 192.168.77.8.rdp: P 1:38(37) ack 1 win 17520
=================SKIPPED=====================
17:56:23.588309 IP 192.168.78.24.1628 > 192.168.77.8.rdp: . ack 15003 win 17253
17:56:23.589717 IP 192.168.78.24.1628 > 192.168.77.8.rdp: F 10454:10454(0) ack 15003 win 17253
17:56:23.589868 IP 192.168.77.8.rdp > 192.168.78.24.1628: . ack 10455 win 64936
17:56:23.590009 IP 192.168.77.8.rdp > 192.168.78.24.1628: R 15003:15003(0) ack 10455 win 0
^C
113 packets captured
208 packets received by filter
0 packets dropped by kernel
vpn#

У кого какие мысли, куда рыть?....

Вернуться наверх

Alexander Shebaronin

Заголовок сообщения:

Добавлено: Пт июл 08, 2005 17:22

Сотрудник D-LINK

Зарегистрирован: Чт апр 22, 2004 09:33
Сообщений: 2037
Откуда: D-Link Moscow

Любопытно... Однако судя по пакетикам запрос со стороны 804ого благополучно проходит и доходит до БСД. А вот ответы начинают идти только после пинга. Проверьте правила на БСД -- может там что...

_________________
С уважением -- Александр Шебаронин.

Вернуться наверх

uktus

Заголовок сообщения:

Добавлено: Вс июл 10, 2005 17:49

Зарегистрирован: Пт мар 25, 2005 21:39
Сообщений: 53
Откуда: Ёburg

Статью я писал. Схема идеально работает с Firmware Version: V1.38, Wed, Jun 23 2004.

Тоннель надо поднять со стороны BSD пингом. Далее он сам переподнимается при истечении времени жизни. Иногда рвется тоннель, если между офисами связь оборвалась на несколько секунд.
Но это только в одном офисе бывает у меня, там провайдер не очень качественный.

Вернуться наверх

aster

Заголовок сообщения:

Добавлено: Пн июл 11, 2005 09:58

Зарегистрирован: Пт июл 08, 2005 15:56
Сообщений: 19
Откуда: С. - Петербург

Alexander Shebaronin писал(а):

всё тестируется при таком раскладе:
vpn# ipfw show
150 458342 44493152 allow ip from any to any

uktus писал(а):

Статью я писал. Схема идеально работает с Firmware Version: V1.38, Wed, Jun 23 2004.

Попробовал "проапгрейдиться вниз" - не помогло...
а вот ежели прошить 1.41b07 - то туннель вообще не поднимается - ID type error пишет

Цитата:

Тоннель надо поднять со стороны BSD пингом. Далее он сам переподнимается при истечении времени жизни.

Что значит "поднять со стороны BSD"? не очень понял

==========

Вернуться наверх

aster

Заголовок сообщения:

Добавлено: Пн июл 11, 2005 19:54

Зарегистрирован: Пт июл 08, 2005 15:56
Сообщений: 19
Откуда: С. - Петербург

Ну что ж... продолжаем дальше, вот логи tcpdump c терминального сервера:

Это если при запуске tcpdump выключить (-n) преобразование ip-адресов в имена:

Код:

C:\tcpdump>tcpdump -n -i \Device\{B4961EAF-0F0E-408B-8EB4-844D493C2295} host 192.168.78.24
tcpdump: listening on \Device\{B4961EAF-0F0E-408B-8EB4-844D493C2295}
11:50.685017 IP 192.168.78.24.2534 > 192.168.77.36.3389: S 3565848961:3565848961(0) 
11:50.685017 IP 192.168.77.36.3389 > 192.168.78.24.2534: S 1450323104:1450323104(0) ack 3565848962 
11:52.903710 IP 192.168.77.36.3389 > 192.168.78.24.2534: S 1450323104:1450323104(0) ack 3565848962 
11:53.684940 IP 192.168.78.24.2534 > 192.168.77.36.3389: S 3565848961:3565848961(0) 
11:53.684940 IP 192.168.77.36.3389 > 192.168.78.24.2534: S 1450323104:1450323104(0) ack 3565848962 
11:59.466042 IP 192.168.77.36.3389 > 192.168.78.24.2534: S 1450323104:1450323104(0) ack 3565848962 
11:59.684787 IP 192.168.78.24.2534 > 192.168.77.36.3389: S 3565848961:3565848961(0) 
11:59.684787 IP 192.168.77.36.3389 > 192.168.78.24.2534: S 1450323104:1450323104(0) ack 3565848962 
packets captured
packets received by filter
packets dropped by kernel
C:\tcpdump>

Естесственно, что клиент при этом не законнектился.
Но стоит только отключить запрет (убрать -n) пребразования адресов в имена - как тут же всё начинает работать:

Код:

C:\tcpdump>tcpdump -i \Device\{B4961EAF-0F0E-408B-8EB4-844D493C2295} host 192.168.78.24
tcpdump: listening on \Device\{B4961EAF-0F0E-408B-8EB4-844D493C2295}
15:09.851793 IP ASTERNB.2647 > server1.DOMAIN.local.3389: S 2274685851:2274685851(0) 
15:09.851793 IP server1.DOMAIN.local.3389 > ASTERNB.2647: S 2159642992:2159642992(0) ack 2274685852 
15:09.898667 IP server1.DOMAIN.local.137 > ASTERNB.137: UDP, length 50
15:09.898667 IP ASTERNB.137 > server1.DOMAIN.local.137: UDP, length 229
15:11.398629 IP server1.DOMAIN.local.137 > ASTERNB.137: UDP, length 50
15:11.398629 IP ASTERNB.137 > server1.DOMAIN.local.137: UDP, length 229
15:12.726720 IP server1.DOMAIN.local.3389 > ASTERNB.2647: S 2159642992:2159642992(0) ack 2274685852 
15:12.726720 IP ASTERNB.2647 > server1.DOMAIN.local.3389: . ack 1 win 17520
===========skipped=========
15:15.195407 IP server1.DOMAIN.local.3389 > ASTERNB.2647: R 17712:17712(0) ack 9266 win 0
packets captured
packets received by filter
packets dropped by kernel
C:\tcpdump>

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

Аналогично (не коннектится) всё проходит, также если вместо rdc использовать просто telnet server1 3389 (или на smtp - telnet server1 25)

Теперь можно посмотреть что же там на самом деле происходит - логи tcpdump на клиенте, роутере, сервере:
состояние до пинга - клиент:

Код:

C:\tcpdump>tcpdump -n -i \Device\{7F9E35CD-3601-4456-A9B3-231008DDEA2A}
tcpdump: listening on \Device\{7F9E35CD-3601-4456-A9B3-231008DDEA2A}
19:57:28.419876 IP 192.168.78.24.3973 > 192.168.77.8.3389: S 75132533:75132533(0) 
19:57:31.414182 IP 192.168.78.24.3973 > 192.168.77.8.3389: S 75132533:75132533(0) 
19:57:37.422822 IP 192.168.78.24.3973 > 192.168.77.8.3389: S 75132533:75132533(0) 
3 packets captured
3 packets received by filter
0 packets dropped by kernel
C:\tcpdump>

состояние до пинга = роутер

Код:

vpn# tcpdump host 192.168.78
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes
19:55:53.186856 IP 192.168.78.24.4102 > 192.168.77.8.rdp: S 888597714:888597714(0) 
19:55:53.682025 IP 192.168.78.24.1038 > 192.168.77.33.snmp:  GetRequest(39)  25.3.2.1.5.1 25.3[|snmp]
19:55:56.115551 IP 192.168.78.24.4102 > 192.168.77.8.rdp: S 888597714:888597714(0) 
19:56:02.124676 IP 192.168.78.24.4102 > 192.168.77.8.rdp: S 888597714:888597714(0) 
19:56:07.833557 IP 192.168.78.24.3915 > 192.168.77.19.microsoft-ds: P 1743054524:1743054577(53) ack 4039746638 win 17312
19:56:07.833754 IP 192.168.77.19.microsoft-ds > 192.168.78.24.3915: P 1:54(53) ack 53 win 16756
19:56:08.033579 IP 192.168.78.24.3915 > 192.168.77.19.microsoft-ds: . ack 54 win 17259
^C
7 packets captured
95 packets received by filter
0 packets dropped by kernel
vpn#

состояние до пинга = терминальный сервер:

Код:

C:\tcpdump>tcpdump -n -i \Device\{895DF720-AF22-487A-BAD9-38722508DA59} host 192.168.78
tcpdump: listening on \Device\{895DF720-AF22-487A-BAD9-38722508DA59}

57:27.991360 IP 192.168.78.24.3973 > 192.168.77.8.3389: S 75132533:75132533(0) 

57:27.991360 IP 192.168.77.8.3389 > 192.168.78.24.3973: S 1256221334:1256221334(0) ack 75132534 
57:30.905550 IP 192.168.77.8.3389 > 192.168.78.24.3973: S 1256221334:1256221334(0) ack 75132534 

57:30.975651 IP 192.168.78.24.3973 > 192.168.77.8.3389: S 75132533:75132533(0) 

57:30.975651 IP 192.168.77.8.3389 > 192.168.78.24.3973: S 1256221334:1256221334(0) ack 75132534 
57:36.914190 IP 192.168.77.8.3389 > 192.168.78.24.3973: S 1256221334:1256221334(0) ack 75132534 

57:36.994305 IP 192.168.78.24.3973 > 192.168.77.8.3389: S 75132533:75132533(0) 

57:36.994305 IP 192.168.77.8.3389 > 192.168.78.24.3973: S 1256221334:1256221334(0) ack 75132534 
packets captured
packets received by filter
packets dropped by kernel
C:\tcpdump>

отсюда видим, что клиент передал, роутер передал пакеты, сервер принял и отдал пакеты обратно, но роутер их уже не увидел, НО:
если мы запустим пинг до сервера, и после этого повторим:

Код:

vpn# tcpdump host 192.168.78
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes
20:09:27.262041 IP 192.168.78.24.4527 > 192.168.111.8.rdp: S 3475209352:3475209352(0) 
20:09:27.262499 IP 192.168.111.8.rdp > 192.168.78.24.4527: S 4160636091:4160636091(0) ack 3475209353 
20:09:27.264002 IP 192.168.78.24.4527 > 192.168.111.8.rdp: . ack 1 win 17520
=========skipped=========
20:09:30.796916 IP 192.168.111.8.rdp > 192.168.78.24.4527: R 17675:17675(0) ack 9210 win 0
^C
109 packets captured
233 packets received by filter
0 packets dropped by kernel
vpn#

то всё нормально - пакеты ходят туда-сюда...

Коллеги! поможите кто может, что за ерундистика такая творится? Всю башку себе поломал уже...

Вернуться наверх

Alexander Shebaronin

Заголовок сообщения:

Добавлено: Вт июл 12, 2005 10:46

Сотрудник D-LINK

Зарегистрирован: Чт апр 22, 2004 09:33
Сообщений: 2037
Откуда: D-Link Moscow

Объяснить почему -- не смогу, но туннель у вас получает "проходимость" только после установления соединения со стороны БСД. Отключение ресолвинга выключает посылку пакетов на удаленную сторону для определения имен, а его включение эту посылку инициирует, и после нее уже появляется двустронняя связь...

_________________
С уважением -- Александр Шебаронин.

Вернуться наверх

Страница 1 из 1

[ Сообщений: 6 ]

Список форумов » Маршрутизаторы и Firewall

Часовой пояс: UTC + 3 часа

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 254

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения