перехват http прокси - недостатки по сравнению с обычным прокси - PullRequest
Новая
       42

перехват http прокси - недостатки по сравнению с обычным прокси

1 голос
/ 14 февраля 2012

Я хотел бы знать, насколько «реалистично» рассмотреть возможность реализации перехватывающего прокси-сервера (с поддержкой кэша) для цели веб-фильтрации . Я хотел бы также поддерживать IPv6, аутентификацию клиентов и кэширование.

Чтение списка недостатков из вики squid http://wiki.squid -cache.org / SquidFaq / InterceptionProxy , который реализует перехватывающий прокси-сервер, упоминает некоторые вещи, которые следует учитывать как недостатки при его использовании (которые я хочу уточнить):

  1. Требуется IPv4 с NAT - перехват прокси не поддерживает IPv6, почему?
  2. это приводит к возможному сбою path-MTU (PMTUD) - почему?
  3. Проверка подлинности прокси-сервера не работает - клиент думает, что он общается напрямую с исходным сервером, есть ли способ выполнить проверку подлинности в этом случае?
  4. Кэширование перехвата поддерживает только протокол HTTP, но не Gopher, SSL или FTP. Вы не можете настроить правило перенаправления на прокси-сервер для других протоколов, отличных от HTTP, так как он не будет знать, как с ним работать - это выглядит вполне правдоподобным, поскольку способ перенаправления трафика на прокси-сервер в этом случае заключается в изменении брандмауэра. адрес назначения пакета от исходного сервера к собственному адресу прокси-сервера (NAT назначения). Как бы в этом случае, если я хочу перехватить другие протоколы, кроме http, узнать, где должно быть установлено соединение, чтобы я мог передать его этому месту назначения?

1 Ответ

1 голос
/ 14 февраля 2012

  1. Трафик может быть перехвачен разными способами. Для этого необязательно использовать NAT (который не поддерживается в IPv6). Прозрачный перехват, безусловно, не будет использовать NAT, например (прозрачный в том смысле, что Прокси-сервер не будет генерировать запросы со своим собственным адресом, а с клиентским адресом, подделывая IP-адрес).

  2. PMTUD используется для определения наибольшего размера MTU, доступного на пути между клиентом и сервером, и наоборот, он полезен для предотвращения фрагментации пакетов Ip на пути между клиентом и сервером. Если вы используете прокси-сервер в середине, даже если MTU обнаружен, он не обязательно совпадает с прокси-сервером клиента и прокси-сервера. Но это не всегда актуально, это зависит от того, какой трафик обслуживается и как ведет себя прокси.

  3. Если прокси-сервер аутентифицируется от имени клиента, ему необходимо знать о способе аутентификации, и ему, вероятно, потребуются некоторые файлы cookie, которые существуют на клиенте. Подумайте об этом так ... Если прокси-сервер может аутентифицировать доступ к ограниченному ресурсу от вашего имени, это означает, что любой может сделать это от вашего имени, и цель хорошей аутентификации - защитить вас от таких возможностей.

  4. Полагаю, это был очень старый пост от ребят из Squid, но технология существует для перенаправления всего, что вы хотите, на конкретный сервер. Одним из простых способов сделать это является размещение вашего сервера в качестве шлюза по умолчанию для сети, после чего все пакеты проходят через него, и вы можете перенаправить пакеты, которые вам нравятся, в ваше приложение (или другой сервер). И вы не ограничены HTTP, НО вы ограничены тем, как работает протокол приложения.

...