Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | |
Насколько я понимаю, все таки нет. 17.10.05 23:11 Число просмотров: 2410
Автор: JC Статус: Незарегистрированный пользователь
|
> 1) Есть параметр [misc]/periodicperiod.
> Если я ничего не путаю, то этот счетчик отвечает за время,
> которое проходит между сравнениями фактического размера
> буферов с предельно допустимыми.
Насколько я понимаю, все таки нет.
this is the number of seconds between the rewriting of the proxy buffers to disk.
То есть период, через который буфера скидываются на диск. Вроде бы к сетевым апдейтам отношения не имеет.
> 2) Есть параметр
> [KeyServer]/connectperiod, который
> определяет минимальное время между запросами на прокси
> более высокого уровня.
Вот это да. Судя по наблюдениям за домашними компьютерами, прокси, если ей нужно обновить буфера, через каждый connectperiod ломится в сеть, и к облому относится довольно спокойно: просто ждет еще connectperiod. Правда, наблюдал я всего один вечер, и может быть есть тут какие-нибудь и закорюки.
|
|
<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 Статус: Незарегистрированный пользователь
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
