информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медГде водятся OGRыSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / dnet
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
У меня прокси долгое время успешно работал в таком режиме,... 17.10.05 16:30  Число просмотров: 2296
Автор: ddmitry Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Как чувствовал, что с этим кейпрокси какой-нибудь глюк
> вылезет. Не хочет софтина видеть поднятие линка, даже
> локальное. Блоки раздает, а аплинк на сервер не делает.
>
> Кому интересно: сервер Win2000, модем для физических линий
> (generic null modem), версия прокси последняя,
> свежескаченная.

У меня прокси долгое время успешно работал в таком режиме, правда под Линуксом. Линк на сетевушке был всегда, но трасса появлялась на вечер. В логах было видно, что прокси периодически долбился, а когда появлялась связь, успешно скачивал/закачивал блоки.
Даже не знаю, что посоветовать. Может скрипт какой, который будет дёргать прокси при поднятии линии...
<dnet>
Connection detect? 15.10.05 13:26  
Автор: JC Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Есть выпрос, вытекающий из вот этой ветки
http://www.bugtraq.ru/cgi-bin/forum.mcgi?type=sb&b=1&m=127215

Нужно поставить кейпрокси в сети, которая периодически подключается к инету. Вопрос: насколько успешно прокси замечает появление коннекта, если стоит не на шлюзе, а в глубине сети? Я знаю, что многие сетевые клиенты могут отследить такое событие только локально.

Подскажите, кто сам имел с этим дело. Времени на эксперименты нет, надо приехать и быстренько все сделать (ну и чтоб работало еще :) ).
Как чувствовал... 17.10.05 14:25  
Автор: JC Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Как чувствовал, что с этим кейпрокси какой-нибудь глюк вылезет. Не хочет софтина видеть поднятие линка, даже локальное. Блоки раздает, а аплинк на сервер не делает.

Кому интересно: сервер Win2000, модем для физических линий (generic null modem), версия прокси последняя, свежескаченная.
У меня прокси долгое время успешно работал в таком режиме,... 17.10.05 16:30  
Автор: ddmitry Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Как чувствовал, что с этим кейпрокси какой-нибудь глюк
> вылезет. Не хочет софтина видеть поднятие линка, даже
> локальное. Блоки раздает, а аплинк на сервер не делает.
>
> Кому интересно: сервер Win2000, модем для физических линий
> (generic null modem), версия прокси последняя,
> свежескаченная.

У меня прокси долгое время успешно работал в таком режиме, правда под Линуксом. Линк на сетевушке был всегда, но трасса появлялась на вечер. В логах было видно, что прокси периодически долбился, а когда появлялась связь, успешно скачивал/закачивал блоки.
Даже не знаю, что посоветовать. Может скрипт какой, который будет дёргать прокси при поднятии линии...
конфиг в студию 17.10.05 16:27  
Автор: J'JF <Dmytro Volhushyn> Статус: Elderman
<"чистая" ссылка>
Точнее - его секцию [KeyServer].
А вообще вот цитата из мануала:

[KeyServer]/connectivity: these modes are very much like the normal, offline, lurk, and lurkonly modes that are available on the windows clients. This option only has effect on the win32 version of the proxy.
"normal" : The proxy will attempt to connect to a server as needed.
"offline" : The proxy will not attempt to make any connections to a server automatically.
"lurk" : The proxy will automaticly send/receive blocks when it detects a network connection, but it may also initiate connection by itself if it needs to send or receive blocks. If you have autodial configured, then your modem will auto-dial.
"lurkonly" : Same as lurk, however the proxy will not attempt to make connections unless it can explicitly detect that your modem is currently connected, so it won't ever cause auto-dial.

Надеюсь, поможет.
Помню, были какие-то грабли с lurkonly в свое время. Сейчас просто им не пользуюсь, т.к. мопед только дома, а там я издавна совсем по-друому поступаю: в nnCron задачу - каждые 5 мин. делать "proxysig -reload" при наличии линка ppp. Возможно, lurkonly до сих пор толком и не работает.
Поищи в фруме по ключевому слову "lurkonly" - найдешь, что там не так было, и какие решения предлагались.
Ну а что касается случая, когда прокся не на шлюзе... Ну и что? Пусть себе работает в режиме
connectivity=normal
Если шлюз будет видеть маршрут к прокси - он пропустит. Если нет - даст отлуп. В любом случае, ничего страшного не произойдет. А верно выбрать параметр [KeyServer]/connectperiod , а также правильно настроить лимиты буферов, то проблем не будет - просто прокся будет периодически пытаться что-то отправить, но не сможет этого сделать, пока на шлюзе не будет маршрут к прокси более высокого уровня.
Дело ясное что дело темное :) 17.10.05 18:31  
Автор: JC Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Честно говоря, проблему проблемных подключений решать раньше не приходилось, поэтому в свое время поступил как считал проще всех - просто молотил рэндомы в оффлайне. Сейчас понял что был неправ, но как водится путь истины тернист :)

Про режимы работы прокси я понял, ничего там сложного нет. Сам я админ, установка серверного софта - это моя работа :) Почему установка соединения проходит незамеченной для прокси - мне неведомо. К сожалению, возможности для эксперимента у меня нет, туда можно придти, что-то сделать и уйти. Предварительно я моделировал ситуацию в домашней локалке. Здесь локальный триггер работает на ура.

Вопрос о том, как ведет себя на ненадежном соединении прокси в положении normal для меня пока открыт: первых блоков в той сети я так и не дождался. Точно установлено, что после SIGHUP в этом режиме при необходимости аплинк идет. Это радует - есть хотя бы возможность ручной синхронизации. Будет ли инициироваться аплинк сам по себе, то есть будет ли прокси "искать" коннект, мне пока неведомо. Жаль конечно, что исходников нет, можно было бы там поковырять.
Будет, конечно. Вообще модель работы прокси, насколько я... 17.10.05 22:35  
Автор: J'JF <Dmytro Volhushyn> Статус: Elderman
<"чистая" ссылка>
> Будет ли инициироваться аплинк сам по себе,
> то есть будет ли прокси "искать" коннект, мне пока
> неведомо. Жаль конечно, что исходников нет, можно было бы
> там поковырять.

Будет, конечно. Вообще модель работы прокси, насколько я помню внутреннее устройство, следующее:
1) Есть параметр [misc]/periodicperiod. Если я ничего не путаю, то этот счетчик отвечает за время, которое проходит между сравнениями фактического размера буферов с предельно допустимыми. По результатам этого сравнения прокся принимает решение - нужно ли лезть куда-то за блоками или для отправки блоков. Таким образом, даже если фактический размер буфера превысил предельно допустимый размер, то это еще не повод для прокси сломя голову бросаться что-то делать. Она подождет, пока "щелкнет" счетчик, определяемый этим параметром, сравнит буферы, и уже тогда только примет решение.
2) Есть параметр [KeyServer]/connectperiod, который определяет минимальное время между запросами на прокси более высокого уровня. То есть если прокся уже приняла решение соединиться с другой проксей, то она попробует соединиться, обнулив при этом счетчик connectperiod. В случае отсутствия маршрута (или если еще по какой-то причине не удалось соединиться), она будет ждать, пока щелкнет этот счетчик и попробует соединиться снова.
Вообще, система мутновата, но вполне логична. Оперируя этими двумя счетчиками, можно выстроить довольно таки гибкю систему. По крайней мере у меня с этим проблем не было уже давно.
Насколько я понимаю, все таки нет. 17.10.05 23:11  
Автор: JC Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> 1) Есть параметр [misc]/periodicperiod.
> Если я ничего не путаю, то этот счетчик отвечает за время,
> которое проходит между сравнениями фактического размера
> буферов с предельно допустимыми.

Насколько я понимаю, все таки нет.
this is the number of seconds between the rewriting of the proxy buffers to disk.
То есть период, через который буфера скидываются на диск. Вроде бы к сетевым апдейтам отношения не имеет.

> 2) Есть параметр
> [KeyServer]/connectperiod, который
> определяет минимальное время между запросами на прокси
> более высокого уровня.

Вот это да. Судя по наблюдениям за домашними компьютерами, прокси, если ей нужно обновить буфера, через каждый connectperiod ломится в сеть, и к облому относится довольно спокойно: просто ждет еще connectperiod. Правда, наблюдал я всего один вечер, и может быть есть тут какие-нибудь и закорюки.
И тем не менее. 18.10.05 08:54  
Автор: J'JF <Dmytro Volhushyn> Статус: Elderman
<"чистая" ссылка>
> Насколько я понимаю, все таки нет.
> this is the number of seconds between the rewriting of the
> proxy buffers to disk.
> То есть период, через который буфера скидываются на диск.
> Вроде бы к сетевым апдейтам отношения не имеет.

Как показывает практика - имеет. То, что он сбрасывает на диск - это да. Но параллельно он и сравнение производит. По крайней мере, я замечал именно такое его поведение: буфер уже больше нормы, а блоки не сливает...
Ну да... 18.10.05 08:20  
Автор: mss <Сергей> Статус: Member
<"чистая" ссылка>
Как только out-буфер полон - прокси сразу ломится в сеть.

А по поводу lurk - видимо он действительно работает именно на локальном компе - при описанном варианте толку от него мало - естественно надо normal ставить.
Переключил на normal. Пока все идет по плану 18.10.05 12:46  
Автор: JC Статус: Незарегистрированный пользователь
<"чистая" ссылка>
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach