И совсем уж специфический вопрос. Но вдруг есть ответ: известны ли приоритеты операций модема. например, сейчас было установлено telnet соединение с модемом, параллельно поставил в flashget задание в очередь на закачку - почему-то не качается.. в telnet набрал "exit", после завершения сеанса - файлик тут же шустро побежал качаться. установленная telnet сессия резко ограничивает скорость обработки данных модемом ? или вообще не рекомендуется пересылать данные через модем в момент его настройки ? или, возможно, есть какая-то система приоритетов и у telnet сессии приоритет выше чем у процесса (не знаю как аппаратно реализован процессор модема поэтому оперирую терминами windows), который с ATM интерфейса на Eth интерфейс данные преобразовывает и поэтому пока я не закрыл telnet сессию данные не шли ? хотя может никаких приоритетов (в преобразовании / одидании команды администрирования) нету, а просто одно на другое наложилось.

Похоже на то.



Как я понял поле Log option включает фичу логгирования срабатывания данного правила. При этом в лог будет писаться Log tag.


1. Уход интерфейса в даун не влияет на счетчик.
2. Посмотрите в сторону 1.3.6.1.2.1.2.2.1.9

так и непонятно что за типа "net" и куда пишется при выборе типа логов "stdout" (точнее, "modify trace cfg module all [net | stdout]"), но зато прекрасно работает syslog trace. Единственное - каков формат syslog сообщений ? например, периодически получаю следующие:
===
<134>PPP;8;4753;PPP_Input(): LCP packet received.
<134>PPP;8;4753;PPP_LCP_Interpret(): Current LCP State: <9>. Input Pkt Type: <9>.
<134>PPP;8;4753;LCP_Open_State(): LCP Echo Req received.
<134>PPP;8;4753;LCP_Send_Echo_Reply(): Sending Echo Reply.
===
насколько я понял ("методом тыка") формат такой (для сообщения "<a>B;C;D;E"):

<a> - код сообщения ("важность" сообщения), где бы достать полный список возможных кодов ?
B - название модуля (в данном случае PPP). список модулей можно посмотреть по "get trace cfg"
C - уровень сообщения. что-то типа уровня детализации, используется для фильтров. например, по-дефолту для всех модулей задана фильтрация сообщений с уровнем больше 0x25f (т.е. модем рассылает trace-логи только для тех сообщений у которых level меньше или равен 0x25f). Например, чтобы не получать сообщения с уровнем "8" и выше для модуля PPP нужно указать "modify trace cfg module ppp level 0x7". Это практические выводы - методом тыка получены и не знаю верны ли
D - какое-то инкрементируемое поле. есть подозрение, что поле содержит некое число которое показывает что обрабатывает определённое действие (например, для вышеуказанного примера число 4753 имеют все действия по обработке пришедшего конкретного пакета с LCP echo req, следующий echo req будет иметь число бОльшее чем 4753)
E - текстовое сообщение с разъяснением что за событие произошло.

это были догадки. есть ли информация как на самом деле устроены syslog сообщения от dsl-500G ?

Я не понимаю необходимости иметь DMZ на внешнем интерфейсе. Ну не понимаю. Это может иметь хоть какой-то смысл только если можно иметь несколько виртуальных внешних интерфейсов. Например, EoA и PPPoA. Тогда один мог бы быть Public, а другой - DMZ. А так - не понимаю.

Вопрос: если я удалю все правила с DMZ (которые мне нафиг не нужны, исходя из вышеизложенного), то по логике обработка пакетов должна происходить быстрее, что повлечет за собой уменьшение задержек. Так? Тем более, что правила с DMZ стоят до правил с I/F = Public.

И еще вопрос: у меня при настройках по умолчанию после покупки модема стоит "Public Default Action: Accept" и "Private Default Action: Deny", т.е полная противоположность

написанному в Руководстве и процитированному здесь выше Виктором Платовым. Если я выставляю значения "по бумажке", т.е. в соответствии с Руководством, то связь с Интернетом пропадает. У меня: EoA, Static IP, Mode=Routing. Кто не прав и что делать?

PS. Странно читать ответы типа и от, как я понимаю, официального представителя D-Link на официальном, опять же, форуме техподдержки. Весьма странно...

модем динамически назначает правила для интерфейса при поднятии этого интерфейса, т.е. при поднятии ppp-0 (если он задан как public, например), к ppp-0 выполняется привязка правил для public и для ppp-0 и привязка выполняется в порядке следования ruleid. Т.е. то, что видно в IP filter, это лишь общий набор правил ни к чему в данный момент не привязанный. Т.е если интерфейс с указанным (в качестве типа интерфейса) типом DMZ в роутере в данный момент не поднят, то правила для DMZ не будут использоваться и, соответственно, никакой задержки не будет.

Мне кажется, ты заблуждаешься. Правила активизируются или деактивируются только в зависимости от глобального значения Security Level и Security Levels, назначенных правилам. Т.е. если у тебя глобальный Security Level = High, к примеру, то все правила, также имеющие собственный Security Level = High, будут активизированы. Интерфейсы проверяются уже на этапе прохождения (фильтрации) пакета сквозь правила. Об этом говорит, помимо здравого смысла, хотя бы данная цитата из Руководства:

Это единственный критерий [де]активации правил, который я нашел.

Я полагаю достаточно проблематичным заметить "на глаз" изменение в задержках прохождения пакетов.

Во встроенном Help-е неточность. Надо оставить значения, используемые по умолчанию.

Возможно ты и прав. В твоих словах также есть логика. По крайней мере это не противоречит моим знаниям в области брандмауэров, основанном на многолетнем опыте работы с такими яркими их представителями, как ipchains/iptables из linux, ipf из мира BSD и различных производных, а также прочим зоопарком в Windows. О большем судить пока не берусь из-за скудности данных. Как ты получаешь свои логи, кстати? Включаешь протоколирование в каждом правиле-фильтре?

Почему nmap при сканировании со стороны Public интерфейса мне говорит:
PORT STATE SERVICE
68/udp open dhcpclient
69/udp open tftp
137/udp open netbios-ns
138/udp open netbios-dgm
139/udp open netbios-ssn
161/udp open snmp
49953/udp open unknown
64512/udp open unknown

а `get udp listen`:
Local Addr Local Port
------------------------------
0.0.0.0 53
0.0.0.0 69
0.0.0.0 161
0.0.0.0 49953
0.0.0.0 64512


Что такое порты 49953/udp и 64512/udp? Откуда появились 137-139 порты в выводе nmap'а и кто их слушает?

Почему у меня вообще видны снаружи UDP-сокеты, если все перечисленное в выводе nmap сверху закрыто правилами типа:

Rule id : 540 Interface : Public
Rule Admin Status : Enable Rule Oper Status : Enable
In Interface : ALL Direction : IN
Security Level : Low Medium High Blacklist Status : Disable
Logging : Disable Action : Deny
Log Tag : -
IP Frag Pkt : Ignore IP Opt Pkt : Ignore
TCP Flag : Any Store State : Disable
Src Addr : Any
Dest Addr : Any
Src Port : Any
Dest Port : Equal 68
ICMP Code : Any
ICMP Type : Any
TransProt : Equal UDP
IP Pkt Size : Any
TOD Rule : Enable Between 00:00:00 23:59:59


Про то, что Default Actions я должен выставлять с точностью до наоборот от рекомендованого в Руководстве и справочной системе, я вообще понять не могу. Где логика?

В общем, много пока странностей и непонятного.

PS. Свой конкретный наезд на российскую службу техподдержки D-Link, который я написал тут ранее, поскипал нафиг. Впрочем, немного все-таки оставлю.
Удивляет и возмущает ваше отношение к пользователям, уважаемые представители службы техподдержки. Вместо профессиональных, четких ответов, вы общаетесь с пользователями в панибратском стиле форумов по интересам, оставляя 9/10 вопросов без ответов. Вместо вас работу по техподдержке фактически вынуждены проводить другие пользователи. Почему вы не выполняете работу, за которую взялись, и которая, как я полагаю, в конечном итоге оплачивается деньгами потребителей продукции D-Link? Тех самых, кто обращается к вам с вопросами по функционированию этой самой продукции? Почему вы считаете возможным просто игнорировать наши вопросы или отвечать в стиле "не знаю" и "если бы вы читали форум и знали стандарты"? Почему множество конкретных вопросов, заданных на этом форуме, осталось без внимания? Почему представитель службы техподдержки на один и тот же вопрос на одной странице дает ответ "А", а на другой, без объяснения причин, -- "Б"? И т.д. и т.п. Определитесь в конце-концов, это форум сообщества пользователей продуктов D-Link или официальный форум техподдержки. Если это все же официальный форум техподдержки, как я полагаю, то если бы меня попросили охарактеризовать двумя словами вашу работу, то я бы выбрал: "пренебрежение" и "непрофессионализм", что конечно же не может являться аттрибутами настоящей службы техподдержки. Я, работая руководителем IT сектора одного из представительств крупной международной организации (оперирующей в более 70 стран мира) и общаясь со всевозможными службами техподдержки по всему миру если не регулярно, то всяко чаще рядовых пользователей, имею представление о том, что такое действительно профессиональные службы техподдержки. К сожалению, похоже, что в России еще не научились работать по-настоящему профессионально. Искренне жаль... Надеюсь это поможет вам выявить слабые стороны в вашей работе и в конечном итоге улучшить качество вашего сервиса на благо всем нам.

"Default action" - это то, как обработается пакет если данные пакета не удовлетворяют ни одному правилу. default action для public интерфейса: accept. Т.е. если из и-нета придёт траффик, не указанный в правилах (а большинство пакетов таким траффиком и являются при дефолтовых настройках модема), то такой пакет примется. если поставим deny - пакет дропнется. вывод: deny ставить не нужно, т.к. в противном случае траффик до компа (подключенного к модему) вообще не дойдёт.

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



Спасибо.


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


Обидно, по умолчанию открыт порт 161 на модеме. Читай не хочу по SNMP статистику


P.S. И вот чего еще хотел сказать. Давайте небудем давить на профессионализм (других пользователей может просто оскорблять это давление)
Он конечно хорошо помогает , в решении проблем но это не повод давить на него в каждом слове, есть случае с новыми непонятными железками, когда опыт от общения с прошлым железом только мешает.
Как знать, может логика разрабочика не сильно ушла от логики простого пользователя, а может и слишком извращена.

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

_________________
D-Link DSL-500G + Стрим Супер

Помнится я спрашивал что за порт открытый по UDP:49951

49951 - порт отправки syslog сообщений как оказалось.

_________________
D-Link DSL-500G + Стрим Супер

Запрос в штаб-квартиру отправлен, ждем ответа.

Если есть варианты - подскажите почему может быть такая ерунда: есть правило
----
$get ipf rule entry ruleid 310

Rule id : 310
Interface : Public
In Interface : ALL
Direction : IN
Security Level : Medium High
Blacklist Status : Disable
Logging : Disable
Action : Deny
Dest Addr : Self
TransProt : Equal ICMP
---
должно ли оно, если у меня установлено security: high (и до этого правила нет правил, разрешающих приход "icmp, type any, code any")выполнять deny всех icmp пакетов, полученных на public интерфейс ? Если "да", то почему этого может не происходить (например, на тот же ping я ответ получаю => icmp доходят) ? Сомнения вызывает строчка "Dest Addr : Self" - это означает IP-адреса любого из интерфейсов модема (в отличии от All или конкретного адреса) ? Если "да" - получается, что сам модем на ping или tracert "извне" (с public интерфейса) уже не ответит, но через себя icmp-пакеты будет пропускать без проблем (тот же NAPT) ?

Вот это верно.

ooptimum, unk


Предлагаю вынести Ваши разборки за пределы этого форума.