Не работает фильтрация HTTPS через NAT

Kerio Control 7.2.0
Не отрабатывает правила URL по HTTPS,
например deny [Для просмотра данной ссылки нужно зарегистрироваться] ТОЛЬКО при выходе пользователей через NAT.
Инспектор протокола в правиле трафика(локальный IP - интернет permit NAT) ставил и по умолчанию и http,
если по умолчанию не работает фильтрация, если в этом правиле трафика инспектор протокола http - то вообще не открываются страницы https.
Но если пользователь выходит через непрозрачный прокси то фильтрация работает. Т.е. правила URL не меняю - но они начинают работать.

Скрины правил приложу позже, но нужно ли это вообще - на форуме проскакивали подобные проблемы но четкого результата не было. Также вскользь об этом упоминает geneg(что фильтрация https только для непрозрачного прокси).
Если это баг Kerio прошу подтвердить опытных камрадов, чтобы не тратить время, если нет выложу скрины для дальнейших вопросов и возможных ответов.
Непрозрачный прокси не желателен - не авторизует пользователей с кириллицей, не учитывается трафик по пользователям.

[Marrab]

Согласно мануалу, HTTPS через NAT не фильтруется вообще. При использовании непрозрачного прокси можно запретить доступ ко всему сайту, но нельзя фильтровать отдельные объекты на сайте.

Спасибо за подтверждение.
Но как же понимать официальный ответ на сайте Kerio([Для просмотра данной ссылки нужно зарегистрироваться]
When you use NAT, winroute is already filtering traffic through the transparent proxy. This is the recommended method.

The non-transparent proxy should be used only in the following circumstances:
-WinRoute is not the default gateway
-Clients connect from a Terminal Server and you want to be able to separately authenticate each user that is connecting from the terminal server.

Т.е. Kerio говорит всегда используйте NAT - он лучше, тоже фильтрует, и т.д. - proxy рекомендуют только в двух случаях - но у меня их нет(этих случаев).
Но оказывается при NAT не выполняются правила URL типа
deny *[Для просмотра данной ссылки нужно зарегистрироваться], это же достаточно существенный функционал, почему бы его не унифицировать и для NAT и для прокси - ВЕСЬ трафик то все равно проходит через Kerio, а получается что при NAT он не видит адреса страниц типа: [Для просмотра данной ссылки нужно зарегистрироваться].

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

[Valery12]

Vadim_Pr, это ограничение связано с работой протокола HTTPS,
принцип: клиент, установив соединение с сервером, получает с него сертификат и шифрует им свой запрос
при непрозрачном прокси между керио и клиентом информация идет не зашифрованной (потому что сертификат от имени клиента получает сам керио)
при прозрачном - сертификат получает клиент и запросы через керио идут уже зашифрованные

Понял, спасибо.
Но все же, правила URL ДОЛЖНЫ отрабатываться ДО УСТАНОВЛЕНИЯ любого соединения, т.е. пользователь запросил в своем браузере (ввел адрес или перешел по ссылке) какой-то КОНКРЕТНЫЙ АДРЕС(в контексте правил URL не должно быть важно, что адрес [Для просмотра данной ссылки нужно зарегистрироваться] или [Для просмотра данной ссылки нужно зарегистрироваться], так как для правил URL это всего лишь строчная переменная, которая должна сравниваться с заданными админом в правилах URL на совпадение) - И ТОЛЬКО после ВСЕХ проверок, заявленных в функционале продукта(а к ним относятся в случае KERIO: правила трафика, правила URL, IPS, антивирус, Web фильтр) firewall ДОЛЖЕН разрешать или запрещать соединение. Понятно, что после установления зашифрованного соединения firewall не может фильтровать, но кто ему мешает НЕ РАЗРЕШИТЬ установить соединение, адрес то браузер клиента запрашивает просто как строку [Для просмотра данной ссылки нужно зарегистрироваться], и в случае непрозрачного прокси таки Kerio отрабатывает запрет URL c https

Мануал по Kerio:

HTTP Policy

The main purpose of HTTP rules is control of access to web pages and filtering of downloaded objects (files). These rules cannot be applied to secured HTTPS traffic.

URL Rules

These rules allow the administrator to limit access to Web pages with URLs that meet certain criteria.
URL
URL to which the rule applies:
· URL beginning with — any URL starting with the specified string. It is possible to use wildcards * (asterisk) and ? (question mark).
Example: *.kerio.com
· URL from the group — any URL belonging to the selected [Для просмотра данной ссылки нужно зарегистрироваться].
· URL rated by Kerio Web Filter rating system — all pages sorted in the selected categories by the [Для просмотра данной ссылки нужно зарегистрироваться].
· any URL where server is specified by an IP address (experienced users may use this method to get through URL rules).



Т.е. заявляют, что https:// не фильтруют. Хотя если дословно, то правила не могут быть применены к уже зашифрованному, а речь то о том, чтобы не дать соединиться. И про непрозрачный прокси ни слова. А почему же непрозрачный прокси прекрасно блокирует [Для просмотра данной ссылки нужно зарегистрироваться] Это каприз одного из художников в Kerio? Правила то URL одно. И в любом случае браузер клиента обращается к Kerio, а уже Kerio, в зависимости от того как он настроен выпускает через NAT, через прокси, либо вообще не выпускает. Или я неправильно понял написанное в мануале?

[Valery12]

Цитата

Сообщение от Vadim_Pr

Но все же, правила URL ДОЛЖНЫ отрабатываться ДО УСТАНОВЛЕНИЯ любого соединения, т.е. пользователь запросил в своем браузере (ввел адрес или перешел по ссылке) какой-то КОНКРЕТНЫЙ АДРЕС(в контексте правил URL не должно быть важно, что адрес [Для просмотра данной ссылки нужно зарегистрироваться] или [Для просмотра данной ссылки нужно зарегистрироваться],

неверное утверждение,
сначала клиент устанавливает TCP соединение с сервером (тут работает трафик полиси можно контролировать адрес или днс имя отправителя и получателя, а так же порт назначения), если в этом правиле включен протокол инспектор керио извлекает и анализирует содержимое пакета и может понять что что это запрос к вэб серверу, проверяет извлеченное содержимое в HTTP полиси и заворачивает пакет на прозрачный прокси
в нашем случае (применительно к HTTPS) после установления соединения клиент посылает серверу команду CONNECT, если нужно авторизуется, получает сертификат и только после этого отправляет зашифрованный запрос в котором и есть хедер *[Для просмотра данной ссылки нужно зарегистрироваться]
тоесть керио не сможет прочитать содержимое зашифрованного пакета, а значит не завернет его на прокси и отправит напрямую через НАТ

Спасибо, теперь все понятно.