Редактирование: UNИX, весна 2009, 09 лекция (от 22 апреля)
Материал из eSyr's wiki.
Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.
Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.
Текущая версия | Ваш текст | ||
Строка 108: | Строка 108: | ||
Каждый выпуск openbsd сопровождается музыкой и комиксами. Обычно они довольно злобные. В этот раз у них была описана история bsd. | Каждый выпуск openbsd сопровождается музыкой и комиксами. Обычно они довольно злобные. В этот раз у них была описана история bsd. | ||
- | |||
- | = Конспект Kda = | ||
- | Весна в разгаре, на улице еще холодно. | ||
- | Станет теплее, народу будет еще меньше. | ||
- | |||
- | == Тенденция == | ||
- | Поверхность обманчивая, об этом было раньше. | ||
- | Тенденция, как было в прошлый раз. | ||
- | Все правила во фре стали state по умолчанию. | ||
- | Еще одно подвтерждение. | ||
- | В pf отменили слово scrab (пересборка проходящих пакетов). | ||
- | Основная задача scrab — превратить пакеты в bsd-шные. | ||
- | Говорить о кривости стека bsd нельзя, потому что он используется в большинстве случаев. | ||
- | Теперь scrab включается автоматически, а раньше была строгая рекомендация включать. | ||
- | |||
- | == Якорь == | ||
- | Что такое якорь? | ||
- | Это похоже на пользовательскую цепочку iptables. | ||
- | Свод правил, существующий в дополнение к основному линейному, и может быть вызван. | ||
- | Можно оформить в виде якоря и ссылаться на него. | ||
- | Главное достоинство не в сокращении, а в том, что правила в якоре не лежат в основном своде правил, и есть достаточно | ||
- | гибкий механизм эти правила менять. | ||
- | Якорь нужен, чтобы помещать туда правила, которые часто меняются. | ||
- | Например, состояние системы, логин пользователя, которому нужно что-то разрешить. | ||
- | |||
- | === Нет блокировки === | ||
- | Есть ненулевая вероятность, что, когда мы меняем свод правил, блокировки на него не будет вообще. | ||
- | Только если содержимое якоря потребовалось проходящему пакету, будет блокировка. | ||
- | |||
- | === Типы === | ||
- | Какие они бывают? | ||
- | Правила фильтрующие, подмены адресов. | ||
- | Чаще используются фильтрующие. | ||
- | Еще одно забавное свойство якорей. | ||
- | Поскольку якорь можно менять по ходу, | ||
- | anchor goodguys | ||
- | Происходит что-то среднее между переключением на свод правил и вставлением его. | ||
- | Макросы подставляются в момент компиляции. | ||
- | Точно так же подставляется адрес интерфейса, если он не в скобках. | ||
- | block on 8ext_if all | ||
- | Как меняется userspace? | ||
- | pfctl -a goodguys -f - | ||
- | Можно в файле написать что-то вроде | ||
- | pass in proto tcp from 10.20.30.40 port 80 | ||
- | |||
- | === Вложенность === | ||
- | Якоря могут быть вложенными. | ||
- | Можем включить все подъякори из текущего якоря без рекурсивного обхода | ||
- | anchor "spam/*" | ||
- | |||
- | Возвращаемся к сказанному Евгением. | ||
- | anchor "spam/*" on $ext_if proto tcp from any to any port 25 | ||
- | Может случиться, что обновление не приведет к потере производительности ввиду ненужности в данный момент. | ||
- | |||
- | === pfctl === | ||
- | С помощью pfctl можно манипулировать якорями. | ||
- | Все оказалось гораздо проще, чем могло быть. | ||
- | |||
- | == Traffic shaping == | ||
- | Мы переходим к еще одной теме. | ||
- | pf — это штука для крутых перцев, если вы не высокий профессионал, он будет у вас работать, хоть это и странно. | ||
- | Мы возвращаемся к теме traffic shaping. | ||
- | Можно поговорить о том, как это делается в линуксе. | ||
- | В pf это поражает своей простотой. | ||
- | Одно непонятно, почему этого так боятся. | ||
- | По умолчанию алгоритм включен, просто используется fifo. | ||
- | |||
- | === Schedule (планировщик) === | ||
- | Какие еще есть планировщики? | ||
- | Можно подключить другой планировщик и он будет работать по другим правилам. | ||
- | Для входящих пакетов это бесполезно. | ||
- | Вдруг такая необходимость есть, нужно будет создать связку виртуальных интерфейсов. | ||
- | В pf есть только на выходе из интерфейса. | ||
- | |||
- | Какие бывают планировщики кроме fifo? | ||
- | В pf два нерекомендуемых. | ||
- | Они соответствуют двум диссертациям, защищенным на эту тему. | ||
- | DRIQ, CBQ. | ||
- | В pf DRIQ пользоваться необязательно. | ||
- | Вылезают пакеты. | ||
- | Организуем несколько очередей. | ||
- | Не одно fifo, как было раньше, а несколько вариантов. | ||
- | Пакет попадает в одну очередь, другую или третью и по разным правилам попадает на выход. | ||
- | Указываем пропускную способность (например, 2 Мбит/сек). | ||
- | Указываем приоритет очередь (например, 1, 2, 3 и 4). | ||
- | Пока есть неотосланные пакеты в очереди с более высоким приоритетом, очереди с низким приоритетом будут ждать. | ||
- | Очередь для тех, кто без очереди. | ||
- | Следующий уровень — для тех, кто без очереди в очереди тех, кто без очереди. | ||
- | |||
- | Команда | ||
- | altq on fxp0 bw 2Mb queue {stdout, dns_out} | ||
- | На интерфейсе альтернативная организация очереди. | ||
- | В случае приоритетной очереди не обязательно ограничивать пропускную способность. | ||
- | В интерфейсе вешается альтернативный планировщик. | ||
- | queue std_out priq (default) | ||
- | queue dns_out priority 5 priq(red) | ||
- | pass out on fxp0 inet proto {udp tcp} from (fxp0) to any | ||
- | port domain keep-state queue dns_out | ||
- | |||
- | === Дерево === | ||
- | Поскольку приоритет — штука жесткая, могут быть проблемы. | ||
- | Если мы не будем пользоваться приоритетными очередями, а сделаем некое дерево, то если одна ветвь заполнится одним | ||
- | процессом, это не страшно, другие ветви будут работать. | ||
- | alt on fxp0 cbq bw 2Mb queue {std, ssh, ftp} | ||
- | У нас есть некий ftp-трафик, про который известно, что он то есть, то нету. | ||
- | Если есть, не нужно давать воли. | ||
- | Если никого больше нет, можно давать волю. | ||
- | Есть ssh, который нужно пускать приоритетно. | ||
- | queue std bw 50% cbq(default) | ||
- | queue ssh bw 25% { ssh_login, ssh_bulk } | ||
- | Это вторая очередь. В нее вложено две. | ||
- | queue ssh_login bw 25% priority 4 cbq(ecn) | ||
- | queue ssh_bulk bw 75% cbq(ecn) | ||
- | |||
- | === FTP === | ||
- | Наконец, ftp | ||
- | queue ftp bw 500Kb priority 3 cbq(borrow red) | ||
- | Ситуация, когда пакеты выбрасываются из очереди до того, как канал переполнен. | ||
- | Если нет поддержки ecn, а есть обычное соединение. | ||
- | Для того, чтобы не жрало трафик, достаточно выкинуть один пакет. | ||
- | Принимающая сторона скажет о пропаже, скорость снизится. | ||
- | Если поддерживается прием сообщений о том, что канал издыхает, файрвол будет слать ecn еще до реального переполнения канала. | ||
- | Что касается borrow, это то, о чем говорили в начале. | ||
- | Если больше никто не занимает канал, дайте ему больше. | ||
- | Чем быстрее скачает, тем быстрее освободится. | ||
- | |||
- | === Дополнительно === | ||
- | Получили неплохое описание очереди. | ||
- | Осталось написать что-то вроде | ||
- | pass out on fxp0 from any to any port 22 queue(ssh_bulk, ssh_login) | ||
- | Есть замечательная фича. | ||
- | Есть queue, можно вписать не одну очередь, а две. | ||
- | Если у нас есть трафик, определяемый одним пакетом, и он делится на быстрый и медленный. | ||
- | Медленный — передача файлов по ssh. | ||
- | |||
- | Такое ощущение, что нас обманули, traffic shaping, а ничего особенного. | ||
- | |||
- | == Iptables, tc == | ||
- | iptables и tc сфокусированы вокруг трафика, а не пользовательских задач. | ||
- | Нужно иметь в голове представление о задаче и теорию и проецировать задачу. | ||
- | |||
- | == NAT == | ||
- | Когда есть распределение адресов, можно сделать подмену сети с оставлением адреса компьютера. | ||
- | /24 bi nat on $ex_if iren from $int_net to any bitmask | ||
- | |||
- | Есть внешний и внутренний диапазоны адресов, они не равны. | ||
- | Как сделать так, чтобы при подмене последних двух октетов генерировался один адрес, чтобы по внутреннему адресу | ||
- | однозначно генерировался внутренний. | ||
- | Если внутри завелся хулиган, можно сильно сузить круг поиска. | ||
- | Лектор написал на питоне хэш-функцию по мак-адресу. | ||
- | Не используется динамическое выделение адресов. | ||
- | --``-- / source-hash | ||
- | pf обладает тем свойством, что легко решает пользовательские задачи при сохранении низкоуровневости. | ||
- | Люди много занимались файрволами. | ||
- | Метка у пакета может быть только одна. | ||
- | Метки в pf текстовые, длина текста 63 символа. | ||
- | Политика раздачи простая. | ||
- | При входе мы можем пометить пакет, а при выходе на основании метки поступить с ним правильно. | ||
- | Если пакет был помечен меткой, она остается. | ||
- | |||
- | Помечание пакетов — технический инструмент. | ||
- | Задача может решаться другим способом. | ||
- | |||
- | == Журнализация == | ||
- | Ситуация такая. | ||
- | У вас есть специальный интерфейс log all. | ||
- | Либо в правиле слово log, тогда пакет пойдет в интерфейс. | ||
- | logd. | ||
- | Он формирует лог tcpdump. | ||
- | |||
- | == FTP == | ||
- | Ftp — классическое двунаправленное соединение. | ||
- | Через файрвол не пролезают. | ||
- | В pf есть работа с ним. | ||
- | Basic Ftp — два соединения для легкого определения, что передавать мало и быстро, а что много и медленно. | ||
- | Пассивное соединение требует подключения к серверу по произвольному порту. | ||
- | Если и клиент, и сервер за файрволом, то в одном файрволе нужно выковыривать дырки. | ||
- | Как правило, в серверном. | ||
- | Внутрь протокола Ftp входит понятие адреса сервера. | ||
- | Ftp на прикладном уровне передает адрес, по которому нужно подсоединяться. | ||
- | Клиент лезет на внутренний адрес. | ||
- | Некоторые клиенты понимают, что бывают идиоты, например, файрфокс может подконтачиться на тот же адрес, что и основной. | ||
- | Другой вариант — использовать замороченные ftp-серверы. | ||
- | Третий вариант — ftp-proxy. | ||
- | На сервере запущена программа, которая подменяет все, что надо. | ||
- | |||
- | == Userspace == | ||
- | Две вещи. | ||
- | |||
- | === authpf === | ||
- | Раз уж перешли к userspace, программа authpf. | ||
- | Что это? | ||
- | Такой шелл. | ||
- | Пользователь логинится и запускается программа. | ||
- | Определение, откуда залогинился пользователь. | ||
- | Включается нужный анкор, после логофа отключается. | ||
- | Точнее, ip добавляется в таблицу и потом убирается. | ||
- | authpf. | ||
- | Когда пользователь заходит в систему, это обрабатывается. | ||
- | |||
- | Что можно сделать? | ||
- | Ну, например, не хотим чтобы всем давался доступ, и все могли попытаться захакать движок. | ||
- | Http доступен, а https не всем разрешить. | ||
- | Для всех пользоватей из таблицы разрешить доступ на 443 порт. | ||
- | Логинимся — есть 443 порт, разлогиниваемся — отключается. | ||
- | В браузере у лектора стоит расширение. | ||
- | Хотим, чтобы были на сервере. | ||
- | Anti-social bookmarks. | ||
- | Syncplaces. | ||
- | Лень заводить WebDav. | ||
- | По ftp закачивать и скачивать. | ||
- | Пароль передается открытым текстом. | ||
- | Пользователь bookmarks_george, пароль bookmarks_george. | ||
- | |||
- | Открывается ssh, логинится, синхронизируются закладки через развесистый порт, разлогиниваемся. | ||
- | Попыток взломать не было. | ||
- | |||
- | === Common address redundancy protocol === | ||
- | Технология, позволяющая держать несколько однотипных серверов, с одними адресами на интерфейсах. | ||
- | Есть три файрвола, абсолютно одинаковых. | ||
- | Работает один. | ||
- | Если сломается, второй тут же подхватит, даже соединения не порвутся. | ||
- | |||
- | Cisco Systems вышли со своим изделием, аналогичным, только для роутеров, а не файрволов. | ||
- | Протокол запатентован, для реализации нужно платить деньги. | ||
- | А BSDшники сказали, что они делали то же самое, только денег не хотят. | ||
- | Сайт OpenBSD, там интересный аудиофайл. | ||
- | В 3.5 длинный скетч про покупателя, который хочет купить лицензию. | ||
- | |||
- | == Следующий раз == | ||
- | В следующий раз разговор про traffic shaping отдельно. | ||
{{UNИX, весна 2009}} | {{UNИX, весна 2009}} | ||
{{Lection-stub}} | {{Lection-stub}} |