progmike

Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору butch9383 Цитата: Хорошо. Тогда можете разъяснить, например, по этому разделу из документации http://manuals.kerio.com/control/adminguide/en/sect-usersinrules.html В каком порядке применяются правила? Сперва применяется первое правило, разрешающее не ограниченый доступ по http. Соответственно, после совпадения, идет проверка по HTTP policy. После этого проверка должна, по идее, прекратится. НО она продолжается, и снова проверяется по 2-му правилу из Traffic Policy. Поясните алгоритм, не совсем понятно. И, опять же, проверка идет явно не до 1-го совпадения. Иначе мы бы получили следующее - пользователь ломится по http. Происходит проверка по правилу в Traffic Policy, получаем совпадение, идет проверка в HTTP policy, получаем совпадению по юзеру - его пускает по http. при чем тут тогда второе правило в Traffic Policy? И еще вопрос. Вот раздел http://manuals.kerio.com/control/adminguide/en/sect-rulesex.html В самом низу - Exclusions. Объясните, нахрена второе правило, если первое и так запрещает всем пользователям кроме тех, кто входит в группу Telnet allowed доступ по telnet? PS Может немного сумбурно - просто пытаюсь разобраться. PPS Либо я чего-то не понимаю, либо документация по керио написана, как минимум, не однозначно. | все очень просто по первой ссылке: первое правило в Traffic Policy дает понять керио, что любой локальный хост может попытаться соединиться с любым веб-сайтом на порту HTTP (80). когда пользователь запрашивает удаленную страницу (скажем, ya.ru) керио по первому правилу Traffic Policy этот запрос пропускает, но так как это поток HTTP (и Protocol Inspector это знает) в игру вступают политики трафика URL Rules. Этот же самый поток проходит проверку по политикам HTTP, в которых указано, что его можно разрешить, только если пользователь авторизован и имеет одно из перечисленных имен. Если в данный момент с запрашивающего хоста пользователь еще не авторизовался на керио, или имеет имя, отлично от списка, первая политика URL не сработает - критерии не соответствуют. Керио продолжит просмотр политик, т.к. соответствий еще не найдено, и дойдет до второй политики. Во второй политике четко указано: "Кто бы это ни был - отказать". Т.к. пакет полностью соответствует этой политике (поток является трафиком HTTP, исходит от "Кто бы ни был"), то именно эта политика срабатывает, заставляя керио применить Deny. Стоит понимать, что действие Deny и Drop - разные вещи. По команде Drop пакет просто удаляется без объяснения причин. В браузере это выглядит как "не могу отобразить страницу". А вот по команде Deny керио запрещает передачу пакетов И выполняет переадресацыю для браузера на свою собственную страничку с описанием причин (там же и есть кнопочка "Авторизоваться"). Таким образом, получаем: - только что включенный локальный хост, еще не авторизован и пытается получить доступ к ya.ru - срабатывает первое разрешающее правило Traffic Policy и вторая запрещающая политика URL rules - пользователь получает страничку с текстом отказа (что-то вроде, "Вы не авторизованы") и имеет возможность авторизоваться прямо на этой странице. - при успешной авторизации керио выполняет вторую переадресацию с исходным запростом (т.е. введи имя и пароль на странице отказа, следующей загруженной страницей для пользователя будет ранее запрошенная - ya.ru) - после авторизации керио чОтко знает, кто за компом, поэтому для всего последующего трафика HTTP будет срабатывать первое правило Traffic Policy и первая политика URL rules. Для всего остального трафика (ICQ, mail, ... ) будет срабатывать второе правило Traffic Policy. По второй ссылке. Тут немного путаница в словах вышла... Первое правило вовсе ничего не запрещает, только разрешает выбранной группе доступ по телнет. Все, кто не входит в эту группу, и выполнят попытку подключения попадут на самое нижнее правило Traffic Policy, которое по умолчанию имеет действие Drop. Когда к пакету применяется действие Drop, приложение, отправившее этот пакет не подозревает, куда он делся и ждет его возвращения до тайм-аута. Естественно, не получив ответа многие программы выполняют повторную попытку (и даже не одну). Как итог - при действии дроп программа, создавшее эти пакеты, "подвисает" на некоторое время. Если же к пакету применено действие Deny, то программе возвращается пакетик TCP с, грубо говоря, сообщением о запрете. В этом случае программа сразу понимает, что ничего не получится и останавливает запросы. Так вот, второе правило в этом примере действительно избыточно - в нем нет особой необходимости. Но действие по правилу - Deny - более "гуманно" поступает с пакетами. Telnet, при потере пакетов при Drop, реально подвисает. Зато при Deny сразу дает ошибку подключения. |