UNИX, весна 2009, 05 лекция (от 25 марта)
Материал из eSyr's wiki.
- Презентация: ODP PDF
- Диктофонная запись: http://esyr.org/lections/audio/uneex_2009_summer/uneex_09_03_25.ogg
Лекцию читает Александр «GQ» Герасёв.
Лектор расскажет немного про iptables.
До этого мы лсушали про ipfw, это BSD, а в линуксе никакогно ipfw нет, в илнуксе всё по-другому. Точно также, как и в BSD, фильтрация в линуксе может быть разбита на неск. уровней:
- Вся фильтрация происх. в пространстве ядра, поск. выносить её в us клайне накладно. Система фильтрации в linux называется netfilter. iptables лишь один из вариантов реализации настройки его. Был ещё ipchains
- точно также, как в ipfw были divert-сокеты, здесь тоже есть us-фльитрация, тоже в виде сокетов. Кроме того, есть некоторые возм. доступа к настр. стека TCP/IP и netfilter. Доступны он в /proc
Кроме того, в us рабоатют инструменты.
какие задачи решает iptables:
IT — фильтр 2-го, 3-го уровня. Что касается ост. уровней, тут сложнее. Есть зацепки для нижележащих уровней, например, можно узнать mac-адреса. Но для фильтрации на первом уровне есть другие инструменты: arptables и ebtables.
iptables работает в терминах ip. Про то, что внутри пакетов, он может знать, но поск. любое сообщ. внутри пакета может быть разбито произвольно, то целостную инф. iptables получить не может. Есть расширения, позв. искать подстроки в tcp-пакетах, но это не та еиша, где необх. исп. iptables. Для фильтр. на уровне приложений необх. использовать прокси, понимающий соотв. протокол и в нём всё настраивать. В то же время, часто бывает, что для нек-рого взаимодействия по сети кроме как из 4 уровня получить нельзя, например, ftp. FTP использует два соединения, и нам нужна доп. информацуия, чтобы пропустить второе.
При помощи iptables можно настр. фильтрацию без учёта сост. соединения. Сущ. ряд случаев, когда этого либо недост., либо неэффективно, и, также как в ipfw, есть stateful фильтрация, назыв. conntrack.
какие ещё задачи можно решать: packet mangling
Что такое iptables: точно также, как в ipfw, в iptables вся логика фильтрации описывается при помощи набора правил. Правило сост. из двух частей: первая часть — matches, условие, при вып. которого правило срабатывает, и вторая часть — target, то, что делается при вып. условие.
Цели бывают двух видов: те, которые прекращают обр. пакета, и не прекращаются (примеры: drop, log). Часть правил iptables не прерывает выполнение фильтрации, оставляет его в живых.
iptables ---- достаточно модульный firewall, значит. часть даже базовой функциональности вынесена в отдельные подсистемы, в терминах iptables они наз. модулями, и дост. часто, если мы хотим исп. нек-рые условия или цели, то необх. явно сказать, что эти условия или цели отн. к опр. модулю. Это в нек. смысле тоже характеристика правил.
Все ти правила объед. в цепочки. Это примерно то же, что одна большая таблица в ipfw, но цепочек в нём очень много, и логика прохода по цепочкам нетривиальна, в частности, у нас может быть цепочка, одно из правил которой — переход на другую цепочку. То есть, мы брабатываем пакет, и какую-то проверку в таблицу не хзочется: она сложная, состоит из большого количества правил, и если мы будем смотреть на таблицу, то она удет мешать, поэтому хорошо бы вынести эту проверку в отдельную цепочку. точно также, как в прогр. подпрограмму можно как-то назвывать, точно также эти цепочки можно именовать.
Правила в цепочки обр. по одному по алгоритму first wins. Если правило terminating, то обр. пакета в данной цепочке прекратится, иначе продолжится.
Что происх., если ни одно из правил не применилось: если это была вложенная цепочка, то обр. вернётся в род. цепочку, если это одна из стандартных цепочек, то у цепочки есть политика по умолчанию, что делать с пакетом, дял которого не работало ни одно из правил, то можнт быть вердикт как выбросить пакет, так и разрешить его, по аналогии с посл. правилом ipfw.
Теперь начинается самое неприятное: при помощи iptables можно решать ряд задач: фильтрация, трансляция, изм. пакетов. Так как эти задачи специфич. каждая сама по себе, то объед. из все вместе в одну большую таблицу, как это сделано в ipfw, не выгодно с т. з. производительности, так как вполне может быть, что одно из правил будет применяться только для входящих пакетов, то непонятно, зачем его проверять для исходящих пакетов, поэтому держ. одну большую таблицк доаольно накладно. Поэтому хрошо бы задачи несколько разделить, в том числе для того, чтобы аставить пользхователя отдельно опис. трансл., изм., фильтрацию. Для этого сущ. 4 таблицы: filter, nat, mnagle, raw (появилась не так давно, она ост. специфическая; пример, зачем она нужна, лектор покажет позже).
Общая схема: есть три пути пакета: транзитный, входящ., исходящ. . Предлагается след. понимание этой схемы: пакет проходит сначала через цепочки PREROUTING, потом FORWARD, потом POSTROUTING. С этим есть одна единственная проблема: если мы созд. новую цепочку, то мы её созд. в рамках таблицы, и переход из цепочки в цепочку осущ. только в пределах таблицы. Поэтому, совсем забывать про орг. нельзя.
Теперь перейдём к тому, что можно делать в iptables:
Какие виды условий можно задавать: можно задать в качестве условия протокол, к которому относится давнный пакет. Можно в кач. условий исп. адрес или диапазон адресов источника/назначения, можно исп. имена интерфейсов входячщих/исходящих. Тут есть один момент: дело в том, что имя out интерфейса до принятия реш., через какой инт. будет отпр. пакет, неизвестно, поэтому на многие условия в правилах может быть наложено огр., они не все и не всегда могут применяться. Для tcp|udp можно указывать порт, для icmp можно указывать его тип. Что ещё можно в кач. правил использовать: раздличные хар=ки tcp-пакета: его флаги, поля в заголовке. Можно получить инф. о mac-адресе отправителя. Кроме того, можно указывать нек. сложные условия (atddrtype).
Что мы можем делать в пакетами: мы можем скзаать, что либо это ороший пакет (ACCEPT), либо плохой (DROP). Это фильтрация пакетов. Поэтому эти правила имеют смысл в таблице filter, в других таблицах не факт, что оно сработает. В старых версиях iptables был не очень критичен к пользователю, сейчас вот он на это ругается. Кроме просто выбрасывания пакет считается зорошим тоном сообщить о том, что мы не хотим видеть этот пакет по той или иной причине (для этого и нужен ICMP): при помощи REJECT можно сказать, что не так.
Эти три правила заканчивают пакеты в цепочке. Но кроме этого, есть правила для протоколирования: LOG/ULOG. LOG выводит сообщ. ядра, а ULOG выводится более настраиваемо (мы можем вывести не только что пакет прошёл через такое правило с такими характеристиками), и выводим мы их не в syslog, а в сокет, например, это может быть исп. для аккаунтинга.
Ещё есть вердикт TRACE: при прохождении пакета срабатывает
MIRROR: отпр. обратно такой же пакет. Одно время Гоша/Рома рассказывали, что когда они замечали, что кто-то начинал ломать их ssh, то они разворачивали трафик и люди начинали ломать сами себя.
QUEUE: аналог divert socket. Понятно, что копирование в us не есть хорошо, и на них под нагрузкой просаживается производительность.
iptables в качестве statelessfw исп. крайне неэфф. и сложно. Простой пример: кто-то из нашей сети пытается подкл. к хосту вовне. Например, мы разреш. эти подкл.. Но тот хост выключен и в рез-те получается icmp-ответ. Тогда нам необюх. разрешить те или иные сообщ. icmp. Но тогда мы разреш. пропускать произв. icmp-пакеты извне. Следовательно, нужен мезанизм, который позв. понять, что опр. пакет отн. к опр. трафику. Для этого исп. conn. track. У любого пакета есть такая вещь, как STATE. Если уст. новое соед., то fw про него ничего не знает, если это пакет с уст. SYN, то логично предп., что это уст. нового соед. и SYN=NEW. Как понять, что пакет. отн. к сущ. соед: у него STATE=ESTABLISHED. Если соед. отн. к сущ., то у него STATE=RELATED. Эти состояния опр. подсистема conntrack, это отдельный модуль, который может анализировать в том числе ур. приложений (например, для FTP).
Пожтому часто одним из первых правил ставится проверка на state=ESTABLISHED,RELATED и пропуск такизх пакетов
Кроме того, есть пакет patch-o-matic, это набор дополн. функц. к iptables, там есть дополн. модули, которые пред. доп. условия, дополн. targets и дополн. модули для conntrack.
У каждого модуля есть свои ручки, но он также сост. из двух частей: реализ. модуля в kernelspace, и утилита в userspace, которая позв. настр. эту функц.
Все эти моудил выполн. в виде модулей ядра. Если отдельный модуль (напр., для отслеж FTP) не загруж, то эти соед. не будут отслеживаться.
FTP conntrack очень тупой: он считает, что ftp- соед только на 21 порт, и один из параметров модуля — на каких портах нах. ftp-трафик. Эти параметры передаются в момент загрузки модуля.
STATE+INVALID уст. для некорр. пакетов (напр., для новых пакетов со сбр. SYN)
Для протокола udp если вдруг нам приходит пакет на тот адрес, с которого недавно ушёл udp, то мы можем с высокой долей вероятности сказать, что они отн. к одному соед.
Иногда может возн. необх, чтобы система conntrack не отслеж. опр. пакеты. Для этого введена таблица raw: conntrack начяинает работать после неё, и в ней можно указать для опр. пакетов NOTRACK.
Иногда ывает необх. в самом начале произвести сравнр. пакетов с неск. условиями., после чего мы можем понять, что это пакеет опр. типа. Во-первых, может оказаться, что мы не хотим применять его каждый раз, но мы можем выделить отдельную цепочку, в котором происх. возврат в род. цепочку., после этого мы поняли, что это интерес. нас пакет. Вместо того, чтобы проверять это каждый раз, можно пометить пакет неим числовм: MARK. Посел этого в другой таблице/цепочке можно посмотреть, что данный пакет помечен. Тут всё грустнее, чем ipfw, посе. mark только один. Но тут есть хитрость: можно использовать маски при сравнении.
Возникает такая ситуация: мы одни пакет пометили, но хотим помечать не пакеты, а соединения. Для этого сущ. CONNMARK, который хранит отметку в табл. conntrack, и можно специальной проверкой их выявлять.
Как всем этим управляют: самая главная утилита — iptables. Формат её простой: iptalbes [-t table] (по умолчанию filter). Можно:
- Создать цепочку — -N
- Задать политику по умолч.: -P
- Очистить цепочку: -F
- -A — добавить правило в конец цепочки
- -D — удалить правило (по спеку или номеру)
- -I — вставить правило в середину
Что такое првавило: [[-m module] [!] match] -j TARGET [--target-options]
- ! — отрицание match
- -m module — явная загрузка модуля, если исп. неядерный match
match'ей может быть много
Пример:
- дропаем всё по умолчанию
- Разр. установленные соед.
- Разрешаем всё на lo
- Разр. входящие на 80 порт
- Исх. установленные разрешаются
- Разр. все исх. с lo
- Разр. исх. на 53, 25 порты (dns, почта)
Для рбаоты со списком правил есть iptables{-save|-restore}
При сохр. iptables-save пишет для цепочек количество прошедших байт через разл. цепочки.
Для включения forwarding необх. включить /proc/sys/net/ipv4/ip_forward
Чем лучше save|restore: оно применяется сразу.
Для того, чтобы посмотреть павила в таблице с номерами: iptables -L -nv --line-numbers . Ключик -v служит для показа доп. параметров, про него не стоит забывать.
Не стоит забывать, что модули iptables/conntrack должны ыть загружены.
Для ipv6 есть ip6tables, он исп. единую инфраструктуру, но чуть-чуть другой.
Ещё есть такой замеч. таргет TCPMSS, про который лектор хочет расск., поск может спасти некое количество нервов. Иногда бывает такая ситуация: есть некий хост, он подключен к интернету, есть интернет-сервер. В случае, если мы скачиваем с сервера что-то маленькое, как только скачиваем что-то болшое, оказывается, что висит, маленькие письма ходят, большие — нет.
Может оказаться так, что если посылаются большие пакеты, то они где-то проходят из-за маленького mtu. В случае eth это 1500, если он в pppoe, то там часть съедается на его заголовки. По идее, нам должно вернуться сообщение fragmentation needed. Но может оказаться так, что до нас он не доходит. Это может быть неприятно, и бороться ним непонятно как. Но в TCP есть специальное поле, MSS (maximum sement size), и та инф., которую мы туда запишем, будет инф. для удалённого узла, какой максимальный размер пакета можно пропускать. На роутере крайне желательно включать такое правило: для tcp-пакетов с SYN|RST SYN прописывать в поле MSS значение (можно указать --clamp-mss-to-pmtu).
Возможности patch-o-matcic:
- Списки портов
- Фильтрация по времени
- Вроятность срабатывания
практ. вся инф. почерпнута из iptables tutorial.
Содержание |
[править] Конспект Kda
[править] Вступление
Георгий Курячий уехал на конференцию. Сегодня рассказ про iptables.
Возможно, кто-то по теме знает больше лектора. Рассказ, что это такое и как работает. Сегодня, скорее всего, не будет про MAC.
[править] Что такое iptables?
До этого мы слушали про ipfw. Это BSD, а в Linux все по-другому. Точно так же, как и в BSD, фильтрацию можно разбить на несколько частей. Фильтрация происходит в пространстве ядра, потому что в userspace это накладно. Netfilter. Iptables — одна из реализаций системы реализации в рамках netfilter. Точно так же, как в ipfw есть divert socket, здесь есть возможность фильтрации в userspace.
Нужно упомянуть, что есть некоторые возможности доступа к настройках стека TCP/IP и netfilter. В userspace работают инструменты. Основной — утилита iptables. Помимо него, некоторые настройки выполняются в файловой системе
/proc/sys/net/ipv{4|6}
[править] Уровни работы iptables
Фильтр второго уровня — IP. Та база, которая работает, т.к. третий уровень достаточно стандартизован, все используют TCP или UDP, появились и другие протоколы. На третьем уровне тоже возможна работа. Касательно других уровней все сложнее. Мы можем узнать некоторые характеристики пакетов с первого уровня. Как уже было ранее, iptables не фильтрует на первом уровне, для этого есть arptables, ebtables.
Iptables работает в терминах пакетов ip. Любое сообщение уровня приложений может быть по-разному разбито на пакеты, получить целостную информацию iptables не может. Есть расширения, ищущие подстроки в содержимом пакета, но это не та ниша, где нужно использовать iptables. Нужно ставить прокси, понимающий конкретный протокол. В то же время достаточно часто бывает, что некоторое взаимодействие по сети, и информацию получить кроме как с 4 уровня, нельзя. Одно соединение для команд управления, а данные по другому соединению. Файрвол должен разобраться в ftp. Иначе он должен пропускать все соединения, но среди них могут быть ненужные.
[править] Connection tracking
Можно настроить фильтрацию без учета состояния соединения. Каждый пакет оцениваем и принимаем решение. Существует ряд случаев, когда этого недостаточно или это неэффективно. Средства фильтрации есть в iptables. Есть connection tracking.
[править] Задачи
Какие еще задачи? Были задачи фильтрации, перенаправления, изменения. Про перенаправление опустим. Это, скорее всего, тема следующей лекции. Что касается изменения пакетов, то iptables может вносить изменения, связанные с маршрутизацией. NAT.
[править] Правила
Что такое iptables? Так же, как и ipfw, вся логика фильтрации описывается с помощью набора правил. Правило состоит из двух частей. Первая часть — matching, а вторая часть — то, что делает правило, если сработало условие.
[править] Виды целей
Надо отметить, что цели двух видов. Прекращающие обработку — например, пакет нужно отправить в /dev/null. Часть правил не прекращает обработку. Другой пример — нужно сохранить информацию о пакете для статистики.
[править] Модульность
Файрвол модульный. Базовая функциональность вынесена в подсистемы. Они называются модули. Достаточно часто, если мы хотим использовать некоторые условия или цели, необходимо сказать, что условия или цели относятся к модулю. Правила объединяются в цепочки. Цепочка — то, же что большая таблица в ipfw. Но цепочек очень много. Логика прохода пакетов по цепочке нетривиальна. В частности, у нас может быть цепочка с переходом на другую цепочку. Обрабатываем пакет и какую-то сложную проверку не хочется вставлять в общую таблицу. Мы не поймем, если вставить 25 правил, где именно эта проверка. В такой ситуации хорошо вынести часть проверок в отдельную цепочку и вызывать из основной. Как в программировании функцию можно вызывать неоднократно, так и здесь можно вызывать из разных мест.
[править] Рекурсия
iptables более линеен. Было бы странно, если был бы разрешен рекурсивный вызов.
[править] Работа файрвола
Работает стратегия first wins. Если правило сработало и оно является завершающим, то правило применится. Иначе будет применяться следующее правило. Правила другой цепочки будут применяться последовательно. Если обработка дошла до конца и ничего не произошло, то: если цепочка вложенная, обработка вернется. Если цепочка основная, то сработает политика по умолчанию. Может быть выброс пакета, либо его разрешение.
Либо может сработать какое-то из правил, либо вернется в родительскую цепочку. Можно принудительно вернуться.
[править] Разделение
Самое неприятное. В iptables можно решать разные задачи. И фильтрация, и изменение полей пакета, и трансляция адресов. Эти задачи достаточно специфичны каждая сама по себе, и объединять в одну большую таблицу невыгодно с точки зрения производительности. Может быть, одно правило применяется только для входящих пакетов. Зачем его применять для исходящих? Можно просто поставить одно из условий. Но держать одну большую таблицу правил может быть сильно накладно. Эти задачи, по-хорошему, лучше разделить. Отдельно описывать трансляцию, отдельно модификацию, отдельно фильтрации.
[править] Таблицы
Есть 4 таблицы. Таблица filter, nat, mangle, raw. Raw — она появилась не так давно и она достаточно специфична. Пример будет позже. Mangle — модификация, filter и nat — понятно. Картинка есть на презентации. В начале пакет существует в сети. Он приходит на интерфейс и проходит различные цепочки. Проходит Prerouting: raw, mangle, nat; routing. Затем разветвление, потом пути сходятся.
В документации сказано, что есть таблицы, в таблицах есть цепочки. С одной стороны правильно, с другой стороны сильно путает. Понять, что как, сложно.
[править] Понимание Георгия Курячего
Пакет проходит через цепочки разных таблиц, затем дальше. Объединение вершин графа по цепочкам. Есть одна проблема. Если создаем руками цепочку, мы ее создаем в рамках таблицы. В одну и ту же цепочку мы можем перейти как из Input, так и из Output. Забывать про то, что цепочки сгруппированы по таблицам, нельзя. Отказаться от этого не получается.
[править] Условия
Можно задать в качестве условия протокол. Можно использовать адрес, диапазон адресов источника, назначения. Имена интерфейсов, с которых пришел пакет. Имя выходного интерфейса неизвестно. На многие условия в правилах могут быть наложены ограничения. Не все и не всегда могут применяться.
Для протоколов TCP, UDP можно указывать порт. Для ICMP — тип. Помимо этого, можно указывать не один порт. Различные характеристики пакета — флаги и т.п.
Есть целое семейство правил, условие с несколькими вариантами. Нас могут интересовать пакеты, адресованные одному из наших адресов. Или пакеты, адресованные на unicast/broadcast адрес.
[править] Правила
[править] Accept
Мы можем сказать, что это хороший пакет. Фильтрация пакета.
[править] Drop
Правило drop имеет смысл в таблице фильтров. В других таблицах не факт, что оно сработает. Сейчас как минимум есть ругание на то, что он делается не там.
Передача пакета дальше процессу. Передача дальше по цепочкам.
[править] Reject
Помимо выброса пакета, хорошим тоном считается сообщить тому, кто прислал пакет, что мы не хотим этот пакет видеть. Для этого используется ICMP. При помощи reject мы можем сказать host unreachable, network unreachable и пр. Все три правила прерывают обработку.
[править] Log, Ulog
Log — информация. Ulog — не только вывод информации о пакете с характеристиками, но и вывести первые n байт пакета. Вывод в специальный сокет, который могут слушать userspace демоны. Подсчет трафика. Мониторинг. При перекидывании пакетов целиком, не факт, что выведутся все пакеты.
[править] Trace
Есть замечательное правило Trace. Можно использовать в raw. Эта таблица выполняется в самом начале работы, до какой-то другой работы. Пакет пришел из сети или из локального процесса. Trace — проходя каждую цепочку, если сработало правило, будет записано в лог. Если все пакеты, это плохо, а если определенные, то сможем увидеть, как что работает.
[править] Return
Возврат из вложенной цепочки.
[править] Mirror
Отправляет назад идентичный пакет. В случае, если они обнаруживают, что кто-то сканирует ssh на серверах, они разворачивают трафик и сканирующий брутфорсит сам себя. Там другие механизмы. В реальной жизни использовать не стоит. Если будут ддосить, возникнет перегрузка.
Еще одно — аналог divert socket. Так же, как и в BSD, перехода нет.
[править] Connection tracking
iptables как stateless использовать неэффективно и сложно. Простой пример — кто-то из нашей сети пытается подключиться к хосту. Мы разрешаем какие-то подключения. Мы можем сказать, что разрешаем ICMP наружу всегда. Это нехорошо. Можем разрешить типа destination host unreachable. Есть еще некоторое количество ситуаций. Разрешаем другие типы ICMP. Разрешаем ото всех всегда, это нехорошо. Нам нужен какой-то механизм, который бы позволял понять, что входящий пакет относится к нашему трафику. Для этого используется connection tracking. У любого пакета есть match state. В случае нового соединения, про него ничего неизвестно. Кто-то из нашей сети пытается подключиться.
Когда пойдет пакет назад, как понять, что он относится к установленному соединению? state established. Когда приходит пакет, не относящийся к установленному соединению, но он не левый, а ожидаемый. В iptables есть модуль, который умеет анализировать проходящие пакеты, если пакет ftp, там установление соединения, то он извлекает информацию и заносит в таблицу информацию. Если проходит пакет со state established или related, то его пропускаем. Снижение нагрузки.
[править] «Ручки»
У каждого модуля есть свои ручки.
При помощи параметров модуля ядра — еще одна ручка. Соединения на 21 порт — ftp. Если есть сервер не на 21 порту, то соединение не пройдет.
Возможность узнать состояние пакета. Возможность проверить, что данный проходящий пакет принадлежит к сессии, которая описана в таблице. Для каждого протокола свои таблицы. Может возникнуть необходимость, чтобы система не отслеживала какие-то пакеты. Для UDP нет установления соединения. Если нам приходит пакет, то мы можем предполагать, что это работает прикладной протокол UDP. И он относится к тому, что мы отправили.
[править] NOTRACK
Таблица raw для NOTRACK. В таблице можем отключить учет пакета в системе connection tracking. Что еще стоит упомянуть? В самом начале произвести какие-то сложные сравнения пакета. Если условие выполнено, то это пакет интересного нам типа. Мы можем хотеть применять условия каждый раз. Может быть проверка условий растянута на несколько правил. Если не является тем-то, тем-то и тем-то, то он нам интересен. Выделяем в одну цепочку.
Берем и помечаем пакет каким-то числом. В другой цепочке, в другой таблице при помощи connmark match проверить отметку.
[править] Метка пакета
В ipfw пакет можно помечать несколькими тегами. Здесь только один mark. mark — 32 разряда. Если нужно пометить пакет по двум характеристикам, два марка нельзя. Но мы можем применять некоторую маску и сравнить результаты. Для остальных пакетов хотим отслеживать изменения.
[править] Управление
Самая главная утилита управления — iptables.
iptables [-t table]
Мы можем создать цепочку, применить политику, удалить, посмотреть список правил, добавить правило в цепочку. См. презентацию. Удаляются цепочки так же. Если мы знаем номер правила в цепочке, можно удалить его по номеру. Можем вставить в середину.
Формат правила см. презентацию. Пример конфигурации см. презентацию.
В принципе, есть такой хитрый таргет, с помощью которого можем вставить правило в цепочку. Что это даст? Он только для того, чтобы в каком-то виде сохранять комментарии.
Надо не забывать, что модули как iptables, так и connection tracking должны быть загружены. Для ipv6 существует отдельный инструмент ip6tables. Он использует единую инфраструктуру. Что-то общее есть, но структура пакетов другая. По тому, как с ним работать, он похож на iptables.
Может быть еще что-то. Есть еще немного времени.
[править] TCPMSS
Есть target TCPMSS. Вдруг спасет какое-то количество нервов. Есть некоторый хост. Он подключен к Интернет. Есть сервер. В случае, если мы скачиваем что-то маленькое, все хорошо. Если большое, соединение устанавливается и висит.
Это может быть связано с тем, что когда посылаем большие пакеты или приходят, пакеты не доходят из-за того, что посередине маленький MTU. Полтора килобайта, а посередине есть MTU 1300. Большой пакет не пролезет. Есть такой механизм, как фрагментация. Но некоторые узлы не умеют выполнять фрагментацию. Тупые, или считают, что не барское это дело.
Понятно, что пакет не пройдет. Вернется ICMP сообщение. Есть аналог с большим пакетом. Мы умные, и считаем, что все нужно пропускать. Провайдер же не пропускает входящие ICMP пакеты, говорящие об уменьшении пакетов. Есть поле MSS. Maximum segment size.
Та информация, которую запишем — информация об узле, которую будет посылать. На роутере крайне желательно включать правило. Для пакетов с флагами syn, rst можно задать поле, описывающее ширину канала. С этим лектор сталкивался дважды.
На этом все.
[править] Литература
Информация почерпнута в основном из iptables tutorial. Есть старый перевод, тем не менее, в основном актуальный. Есть man iptables (8).
[править] Завершение
В следующий раз будет Георгий Курячий, расскажет про NAT и еще что-нибудь.
