Различия между версиями 2 и 3
Версия 2 от 2014-05-23 11:15:56
Размер: 3742
Редактор: FrBrGeorge
Комментарий:
Версия 3 от 2014-05-23 11:30:16
Размер: 4667
Редактор: FrBrGeorge
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 27: Строка 27:
 * Потому (и в процессе) этими ключами надо управлять
=== OpenVPN ===
Базовая статья [[WikiPedia:OpenVPN]]
 * Простая клиент-сервернеая структура
 * Авторизация по PSK или паролю
 * Протокол прост в реализации (см. поддерживаемые архитектуры)
 * Наких RFC не написано
 * Примеры настройки: [[https://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html|простейший]], [[https://openvpn.net/index.php/open-source/documentation/examples.html|ещё]]
Строка 34: Строка 42:
  * l7filter   * [[http://l7-filter.clearfoundation.com/|l7filter]] (дохленький?)
Строка 38: Строка 46:
  * FTP   * FTP (например, [[BSDMan:ftp-proxy]])
Строка 43: Строка 51:
 * Эффективные сетевые подсистемы (netgraph, netmap, …)  * Эффективные сетевые подсистемы ([[http://www.opennet.ru/docs/RUS/netgraph_freebsd/|netgraph]], [[http://info.iet.unipi.it/~luigi/netmap/|netmap]], …)
Строка 45: Строка 53:
 * Высокоуровневые МЭ: shorewall  * Высокоуровневые МЭ: [[http://shorewall.net/|shorewall]]

МЭ на прикладном уровне, а также что не попало в лекции

Туннеллирование (продолжение)

Протоколы туннелирования: тысячи их

L2TP

Основной RFC — 2661. Базовая статья — Layer_2_Tunneling_Protocol

  • Развитие PPTP:
    • Предназначен для туннелирования PPP через «любую» среду передачи данных (UDP, IP, ATM, Frame Relay, …)
  • Разделяются понятия «туннель» и «сеанс внутри туннеля»
  • Управляющий протокол создания туннеля и установления сеанса надёжен, а надёжность данных не гарантируется
  • Поддерживаются «входящие звонки», «исходящие звонки», простой туннель и даже какой-то «multihop»
  • Не имеет механизма аутентификации ⇒ используется пара L2TP + IPSec ESP Transport

Пример простого L2TP-туннеля с помощью iproute2: ip l2tp (без задействования управляющего протокола) Управляющий протокол реализуется специальным демоном (вариантов много)

IPSec

См. предыдущую лекцию.

Ключи и обмен ими

  • Аутентификация в IPSec использует HMAC (симметричное шифрование) ⇒ нужен т. н. shared secret.

  • IPSec «поддерживает любые механизмы аутентификации» ⇒ сложный протокол IKE для устаноления т. н. security association (SA) (используемого набора механизмов шифрования и аутентификации).

  • Потому (и в процессе) этими ключами надо управлять

OpenVPN

Базовая статья OpenVPN

  • Простая клиент-сервернеая структура
  • Авторизация по PSK или паролю
  • Протокол прост в реализации (см. поддерживаемые архитектуры)
  • Наких RFC не написано
  • Примеры настройки: простейший, ещё

МЭ на прикладном уровне

Проблема: многообразие протоколов.

Общие задачи:

  • Контентная фильтрация/ограничение
    • Антиспам/Антивирус
    • l7filter (дохленький?)

  • Ретрансляция (возможно, с изменением полей прикладного протокола)
    • «Классический» прокси (например, squid)
    • FTP (например, BSDMan:ftp-proxy)

    • TLS и разное жульничество с ним

Не вошло

  • Эффективные сетевые подсистемы (netgraph, netmap, …)

  • Взаимодействие с packer processors (для большой загрузки)
  • Высокоуровневые МЭ: shorewall

  • Проксирование и иная ретрансляция
  • Антиспам/антивирус/скоринг контента
  • Подсчёт статистики

LecturesCMC/UnixFirewalls2014/12_ApplicationAndOthers (последним исправлял пользователь FrBrGeorge 2014-05-23 11:31:50)