Сборник статей Handbook inside ! : Linux не для идиотов inside ! : Версия 1 от 15. 07. 2007 2007



Pdf просмотр
страница48/50
Дата14.11.2016
Размер5.65 Mb.
Просмотров7981
Скачиваний0
ТипСборник статей
1   ...   42   43   44   45   46   47   48   49   50
Device mapper
В ядрах линейки 2.6 появилась еще одна подсистема по некоторым функциям аналогичная подсистеме MD, и называемая device-mapper. Это модульная компонентная подсистема, позволяющая с помощью специальных команд создать одно блочное устройство из нескольких кусков других блочных устройств, а также определить правила, по которым производится запись на эти «нижележащие» блочные устройства.
LVM работает именно через подсистему device mapper, и на самом деле все утилиты
LVM на самом деле просто передают инструкции о том из каких фрагментов каких блочных устройств состоит какой том LVM в драйвер device mapper, в каком порядке осуществляется запись и чтение данных, и впоследствии при записи на том LVM или чтении с него, работа на самом деле ведется с устройствами, обслуживаемыми драйвером device mapper, который и делает всю работу.
Данная многоуровневая архитектура позволяет значительно упростить и таким образом значительно повысить стабильность работы системы, поскольку реализация нескольких небольших узкофункциональных компонентов в общей сложности содержит меньше ошибок, чем реализация всех этих функций в одной подсистеме.
Host-RAID, или дешевых RAID-контроллеров не бывает
Сегодня даже для дешевых современных материнских плат фирмы-производители часто декларируют «аппаратную поддержку RAID» и у многих пользователей этот факт вызывает недоумение – как же так, мой Linux не умеет работать с RAID?! На
самом деле все проще – задекларированная и разрекламированная поддержка
RAID-массивов на материнских платах для офисных и домашних
компьютеров – это миф.
Вся поддержка RAID в таких «контроллерах» на самом деле представляют собой просто небольшое расширение в BIOS и без специальных драйверов в 32/64-битных операционных системах не работают, а все функции RAID для них выполняются драйвером. Если в Windows для каждого из таких контроллеров фирма- производитель пишет драйвер, то в Linux ситуация немного иная.
Для реализации возможности работы с такими псевдо-RAID контроллерами (иногда называемыми fake-RAID) была разработана утилита dmraid. При запуске она сканирует жесткие диски в поисках специальных блоков (функционально аналогичных суперблокам уже знакомых нам md-устройств), записываемых такими fake-RAID контроллерами, и если ей удалось распознать формат этого специального блока, то dmraid инструктирует подсистему device-mapper о том, в каком порядке следует считывать блоки с жестких дисков.
После этого device-mapper создает блочное устройство, при записи или чтение данных с которого данные автоматически читаются и пишутся так, как сделал бы это драйвер от производителя материнской платы или контроллера.
739

Сетевая подсистема
Ключевым (с нашей точки зрения) объектом сетевой подсистемы Linux является интерфейс. Сетевой интерфейс в Linux – это абстрактный именованный объект, используемый для передачи данных через некоторую линию связи без привязки к ее
(линии связи) реализации. Конечно, сказано мудрено – но попробуем объяснить «на пальцах».
Например, если в системе существует интерфейс eth0, то в большинстве случаев на современных компьютерах он сопоставлен Ethernet-адаптеру, встроенному в материнскую плату. Интерфейс с именем ppp0 отвечает за некоторое соединение
«точка-точка» с другим компьютером. Интерфейс с именем lo является виртуальным и представляет как бы замкнутый сам на себя (вход непосредственно подключен к выходу) сетевой адаптер.
Основная задача интерфейса – абстрагироваться от физической составляющей канала. То есть программы и система будут использовать один и тот же метод
«отправить пакет» для отправки данных через любой интерфейс – хоть lo, хоть ethX, хоть pppY, и точно так же использовать один и тот же метод «принять пакет» - то есть создается унифицированный API передачи данных, независимый от носителя.
Для того, чтобы ознакомиться с интерфейсами, можно воспользоваться командой ifconfig:
$ ifconfig -a eth0 Link encap:Ethernet HWaddr 00:11:2F:A8:DE:A4
inet addr:172.23.2.114 Bcast:172.23.2.255
Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:11 Base address:0x4000
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:60 errors:0 dropped:0 overruns:0 frame:0
TX packets:60 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4707 (4.5 KiB) TX bytes:4707 (4.5 KiB)
В данном случае мы видим в системе два активных интерфейса, eth0 и lo, а также некоторую информацию об их состоянии, настройках и параметрах и состоянии аппаратуры для интерфейса eth0. В частности, поле Link encap характеризует тип интерфейса, HWAddr – аппаратный адрес устройства (например, MAC-адрес для
Ethernet), MTU – максимальный размер передаваемого пакета. Также могут представлять интерес поля статистики – они сообщают, какой объем данных был передан и получен через соответствующий интерфейс.
Наиболее часто встречающиеся типы интерфейсов:

eth (Ethernet) – обычно соответствует отдельному сетевому адаптеру

ppp (Point-To-Point) – соединение точка-точка, например при коммутируемом доступе, но очень часто используется и при организации VPN

slip (Serial Line IP) – соединение точка-точка, устаревший протокол

wl (Wireless) – беспроводной интерфейс, обычно сопоставлен соответствующему адаптеру

lo (Loopback) – интерфейс-«петля», то есть что послал, то и получил - используется для общения между сетевыми приложениями в рамках одного компьютера
740

Команда ifconfig может также использоваться для остановки или активации интерфейса, а также изменения его параметров, связанных с протоколом IP:
# ifconfig eth0 down
# ifconfig eth0 up
# ifconfig eth0 inet 192.168.2.210 netmask 255.255.255.0
# ifconfig eth0 mtu 296
Для управления параметрами других протоколов используются другие команды – например, ipx_config для управления параметрами, связанными с протоколом IPX.
Рассмотрим также картинку, на которой приведена приблизительная схема взаимодействия различных драйверов и сетевых подсистем ядра:
П
ред пол ожи м, что приложение пытается отправить пакет. Перед отправкой через системные вызовы группы socket (bind, connect и пр.) приложение настраивает специальный файловый дескриптор. После окончания настройки каждый записанный в этот дескриптор пакет должен быть отправлен по сети получателю. Как движется пакет в нашей системе?
Прежде всего, пакет попадает в драйвер протокола. Этот драйвер определяет через какой интерфейс должна производиться отправка, дописывает к пакету необходимые заголовки и отдает пакет на обработку соответствующему интерфейсу
(точнее, ставит пакет в очередь, связанную с этим интерфейсом).
Что драйвер сделает с пакетом, это уже его дело. Например, драйвер интерфейса loopback этот пакет вынет из очереди и сразу поставит в очередь «принятых», откуда его впоследствии заберет драйвер протокола (левая цепочка на схеме).
Драйвер интерфейса eth0 допишет к пакету заголовки Ethernet и передаст пакет драйверу сетевого адаптера, и уже тот непосредственно проинструктирует сетевой адаптер, откуда взять и как отправить пакет (правая цепочка). В средней же цепочке мы видим схему работы PPP, когда пакет помещается в очередь интерфейса ppp0, откуда его заберет демон pppd. Демон допишет в пакет нужные заголовки, и через символьный специальный файл /dev/ttyS0 передаст пакет драйверу COM-порта, а тот непосредственно будет работать с аппаратурой. Соответственно, при приемке данных цепочки проходятся в обратном порядке.
741
Интерфейс ppp0
Приложение
Интерфейс eth0
Драйвер сетевой карты
Системный вызов socket, send, recv
Драйвер протокола
Демон поддержки PPP
/dev/ttyS0
Драйвер COM-порта
Интерфейс lo

Маршрутизация IP и форвардинг
Маршрутизация транзитных IP-пакетов (не предназначенных для этого компьютера), или IP-форвардинг, является опциональной возможностью IP-стека Linux. По умолчанию функция форвардинга не активируется, и система не пересылает транзитные пакеты через свои интерфейсы, а только обрабатывает адресованные ей пакеты. Включение форвардинга IP-пакетов производится через параметр
net.ipv4.ip_forward интерфейса sysctl. Если значение этого параметра равно 0, то форвардинг отключен, если же значение параметра не равно 0, форвардинг включен:
[dalth@viking dalth]$ sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 0
[dalth@viking dalth]$
Кроме того, возможно разрешать или запрещать участие в форвардинге для каждого интерфейса индивидуально:
[dalth@viking dalth]$ sysctl -a | grep forward | grep v4
net.ipv4.conf.vmnet1.mc_forwarding = 0
net.ipv4.conf.vmnet1.forwarding = 0
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.eth0.forwarding = 0
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.lo.forwarding = 0
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.default.forwarding = 0
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.all.forwarding = 0
net.ipv4.ip_forward = 0
[dalth@viking dalth]$
По умолчанию форвардинг включается и выключается для всех интерфейсов одновременно, но для отдельных интерфейсов возможно сменить флаг участия в форвардинге. Изменять параметры форвардинга может только системный администратор или пользователь, который имеет право записи в необходимые файлы интерфейса sysctl. Следующий листинг демонстрирует включение форвардинга через все интерфейсы путем вызова программы sysctl:
[root@viking dalth]# sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
[root@viking dalth]# sysctl -a | grep forward | sort net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.vmnet1.forwarding = 1
net.ipv4.conf.vmnet1.mc_forwarding = 0
net.ipv4.ip_forward = 1
[root@viking dalth]#
В процессе маршрутизации для выбора интерфейса и следующего узла для доставки пакета (next hop) ядро использует таблицу маршрутизации. Эта таблица представляет список критериев, в соответствии с которыми выбирается следующий узел. В частности, в таблице маршрутизации фигурируют следующие условия: адрес сети получателя пакета, маска подсети получателя пакета, IP-адрес следующего узла, метрика маршрута и служебные поля (например, тип и возраст записи).
Таблица маршрутизации используется не только в IP-форвардинге, но и даже при простой отсылке IP-пакета для выбора интерфейса, через который будет производиться отсылка пакета.
742

Запись о сети с адресом 0.0.0.0 и маской подсети 0.0.0.0 называют маршрутом по умолчанию, или default route. Узел, чей адрес указан в поле gateway для маршрута по умолчанию, называют маршрутизатором по умолчанию, или default gateway или
default router. В системе может быть произвольное количество маршрутов по умолчанию, но они должны быть как минимум с разными метриками. Для просмотра таблицы маршрутизации можно воспользоваться командой route. Эта команда позволяет оперировать с таблицей маршрутов, добавляя и удаляя из нее записи.
[root@inferno dalth]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
10.80.1.113 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.80.1.113 0.0.0.0 UG 0 0 0 ppp0
[root@inferno dalth]# route del default
[root@inferno dalth]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
10.80.1.113 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
[root@inferno dalth]# route add default dev ppp0
[root@inferno dalth]#
В данном выводе таблица упорядочена по маске подсети, что соответствует порядку ее просмотра ядром. Столбцы Destination и Genmask содержат адрес и маску сети получателя пакета, столбец Metric фактически указывает приоритет маршрута
(маршрут с меньшей метрикой более приоритетен), поле Gateway указывает IP- адрес следующего узла для передачи пакета. Некоторые типы интерфейсов (в частности, интерфейсы типа точка-точка, или point-to-point) подразумевают, что на принимающем конце линии связи всегда находится не более одного узла, и поэтому в этой ситуации IP-адрес следующего узла можно не указывать. В данном случае мы видим, что в приведенном примере некоторые узлы доступны через интерфейс ppp0 типа точка-точка. В частности, именно из-за этого свойства приведенная выше таблица оказывается эквивалентна следующей ниже. Жирным шрифтом помечена измененная строка, демонстрирующая “точечную” природу PPP-соединения:
[root@inferno dalth]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
10.80.1.113 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0
ppp0
Специфика использования протокола PPP (обычно используемого при модемых соединениях) такова, что любой PPP-интерфейс является интерфейсом типа точка- точка, более того – PPP и расшифровывается как Point-to-Point Protocol. Также интерфейсами точка-точка являются интерфейсы SLIP (Serial Line IP) и практически все разновидности туннельных интерфейсов.
При деактивизации интерфейса из таблицы маршрутизации автоматически исключаются все маршруты, для которых в поле Iface был указан отключившийся интерфейс. Для некоторых типов интерфейсов при активизации в таблице маршрутизации также создаются служебные записи о маршрутах, которые нельзя удалить.
В большинстве случаев таблица маршрутизации имеет не слишком большой размер, но в некоторых ситуациях (в частности, на шлюзовых машинах в больших сетях) таблица может иметь весьма значительный размер и изменяется не
743

“вручную” с помощью команды route, а специальными программами – демонами поддержки протоколов динамической маршрутизации. С некоторыми упрощениями алгоритм работы этих демонов можно описать следующим образом: демон
“слушает” приходящие пакеты для обслуживаемых протоколов динамической маршрутизации, и по получении (или неполучении) такого пакета отдает ядру команду на изменение таблицы маршрутизации.
Следует также заметить, что команда route в режиме вывода таблицы маршрутизации фактически просто фильтрует и форматирует данные, содержащиеся в специальном файле, называемом /proc/net/route, используемом для доступа к таблице маршрутизации, ведущейся ядром.
Фильтры пакетов
Возможность инсталляции фильтров пакетов является очень интересной возможностью, предоставляемой стеком TCP/IP ядра Linux. Не углубляясь в детали просто отметим, что IP-стек Linux позволяет различным модулям установить
“ловушки” (hooks) для пакетов. При этом каждый пакет, попадающий в такую ловушку, передается для обработки драйверу, установившему эту ловушку.
Драйвер, в свою очередь, может проанализировать пакет, проделать какие-либо действия с пакетом, после чего вернуть код обработки, инструктируя таким образом ядро о том, что следует делать с пакетом дальше – вернуть ли отправителю сообщение об ошибке, прервать ли обработку и уничтожить пакет, либо продолжать обработку пакета обычным образом.
В настоящее время для фильтрации пакетов наиболее часто используются средства
iptables. iptables – это название утилиты, которая позволяет настроить множество драйверов сетевой подсистемы NETFILTER ядра Linux, позволяющих осуществить анализ, произвести преобразование, или изменить обработку IP-пакетов. Основным объектом в iptables является цепочка правил (chain). Каждое правило в цепочке содержит набор условий совпадения (condition matches) и действие (action). Цепочки сгруппированы в таблицы (tables).
Действий есть две разновидности – прерывающие обработку пакета в цепочке, например действия DROP или ACCEPT, и не прерывающие обработку пакета цепочкой – например, LOG или MARK.
Цепочки используются для проверки пакетов – то есть пакет поочередно последовательно сравнивается с каждым из правил цепочки, и если он удовлетворяет всем условиям в правиле, к пакету применяется действие, указанное в этом правиле. Если действие является прерывающем, то на этом обработка пакета этой цепочкой заканчивается, если действие не прерывающее, то пакет продолжает проверяться этой же цепочкой.
Стандартные цепочки также содержат специальное неявное действие по умолчанию, называемое политикой цепочки (chain policy). Действие, указанное как политика цепочки, применяется ко всем пакетам, которые не попали ни под одно правило с “прерывающим” действием.
Стандартные таблицы и цепочки
Подсистема пакетного фильтра содержит три таблицы, в каждой из которых содержатся несколько цепочек (наборов правил). Кроме того, администратор может создавать собственные цепочки правил. Ниже перечисляются стандартные таблицы и цепочки:
744

Таблиц а
Назначение
Цепочки
Назначение mangle Модификация пакетов
PREROUTING
Модификация всех пришедших пакетов
INPUT
Модификация пакетов, пришедших на адрес компьютера
FORWARD
Модификация пакетов, которые должны быть отмаршрутизированы (пересланы на другой хост)
OUTPUT
Модификация пакетов, сгенерированных процессами данного хоста
POSTROUTING Модификация всех переданных пакетов filter
Фильтрация пакетов – принятие решения об их дальнейшей обработке или отказе от обработки)
INPUT
Фильтрация адресованных этому компьютеру пакетов
OUTPUT
Фильтрация сгенерированных этим компьютером пакетов
FORWARD
Фильтрация маршрутизируемых
(транзитных) пакетов nat
Трансляция адресов
PREROUTING
Трансляция адресов всех принимаемых пакетов
FORWARD
Трансляция адресов транзитных пакетов
POSTROUTING Трансляция адресов всех передаваемых пакетов
Таблица nat обладает “двойственным” действием, т.е. если вы включите преобразование для входящих пакетов, исходящие пакеты также будут модифицироваться, и наоборот. Таблицы mangle и nat изменяют пакеты, но mangle не ведет список изменений, т.е. является “однонаправленной” таблицей.
Порядок применения стандартных таблиц и цепочек
Рассмотрим, какой путь проходит пакет в цепочках и таблицах iptables. Для входящих пакетов (адресованных компьютеру, на котором активизирована поддержка iptables) верна следующая последовательность применения цепочек:
1. mangle.PREROUTING
2. nat.PREROUTING
3. mangle.INPUT
4. filter.INPUT
Для пакетов, отправляемых с компьютера, реализуется следующая цепочка обработки:
745

1. filter.OUTPUT
2. mangle.OUTPUT
3. nat.POSTROUTING
4. mangle.POSTROUTING
Пакеты, являющиеся транзитными (маршрутизируемыми), т.е. не адресованные фильтрующему компьютеру и не сгенерированные фильтрующим компьютером, проходят по следующей последовательности цепочек и таблиц:
1. mangle.PREROUTING
2. nat.PREROUTING
3. mangle.FORWARD
4. filter.FORWARD
5. nat.FORWARD
6. nat.POSTROUTING
7. mangle.POSTROUTING
Стандартные действия
Каждое правило в любой цепочке может ссылаться на одно из стандартных или дополнительных действий, либо на какую-либо пользовательскую цепочку.
Основное различие между стандартными и дополнительными действиями в том, что стандартные действия могут указываться в правилах любых цепочек любых таблиц, а дополнительные действия можно указывать только для некоторых цепочек некоторых таблиц. Перечислим стандартные действия:
ACCEPT
Прервать проверку пакета цепочкой и перейти к следующей в порядке обработки пакета стандартной цепочке
DROP
Прервать обработку пакета, сам пакет удалить
RETURN
Прервать проверку пакета цепочкой и вернуться к проверке вышестоящей цепочкой, а если действие встретилось в одно из стандартных цепочек, поступить с пакетом так, как предписано в политике цепочки (chain policy)
QUEUE
Передать пакет некоторому процессу для дальнейшей обработки
Интересной особенностью также является то, что существуют так называемые target extensions, которые реализованы как модули и также могут использоваться для указания проводимого над пакетом действия. В частности, к таким действиям, например, относятся действия LOG – запротоколировать факт получения пакета,
MASQUERADE – подменить IP-адрес отправителя пакета, MARK – пометить пакет и многие другие. Некоторые действия могут встречаться не во всех цепочках, а только в некоторых цепочках некоторых таблиц.
Еще одним специфическим действием можно назвать переход к пользовательской цепочке. При этом, если пакет в процессе обработки попадает под действие правила, у которого в качестве действия указан переход к другой цепочке, то пакет начинает проверяться ее правилами. Это часто используется, чтобы сходным образом обрабатывать некоторые виды пакетов.
Условия отбора
Условия отбора делятся на две группы – стандартные условия, которые применимы ко всем пакетам, и расширенные условия, называемые также match extensions.
Расширенные условия могут применяться не для всех пакетов, а только для некоторых из них – например, дополниетельные условия для протокола UDP включают в себя адреса портов отправителя и получателя, а для ICMP – тип и код
ICMP-сообщения.
746

Примеры конфигураций iptables
Попробуем рассмотреть несколько простых примеров, достаточно часто используемых в реальных конфигурациях. Стоит заметить, что самостоятельная конфигурация пакетного фильтра требует некоторых (точнее, достаточно значительных) знаний сетевых протоколов, поскольку в конфигурации необходимо задавать множество критериев, которые сильно зависят от ситуации и от используемых сервисов.
Пример 1: простейшая конфигурация iptables для домашнего компьютера, подключенного к Internet. В этой конфигурации мы запретим все входящие соединения, а также все исходящие пакеты UDP кроме тех, которые необходимы для нормальной работы в Internet с использованием PPP-соединения. В этой конфигурации мы разрешаем передачу всех пакетов в рамках локальной машины, разрешаем исходящие TCP-пакеты, разрешаем входящие пакеты TCP для уже установленных соединений, и разрешаем передачу и прием UDP-пакетов для службы DNS и пакетов автоматической конфигурации соединения PPP (пакетов
DHCP). Кроме того, следует разрешить прием управляющих пакетов ICMP и отправку запросов и прием ответов PING:
# iptables -P INPUT DROP
# iptables -A INPUT -j ACCEPT -i lo
# iptables -A INPUT -j ACCEP -p tcp ! --syn
# iptables -A INPUT -j ACCEPT -p udp --source-port 53
# iptables -A INPUT -j ACCEPT -p udp --source-port 67 --destination-port 68
# iptables -A INPUT -j ACCEPT -p icmp --icmp-type destination-unreachable
# iptables -A INPUT -j ACCEPT -p icmp --icmp-type time-exceeded
# iptables -A INPUT -j ACCEPT -p icmp --icmp-type parameter-problem
# iptables -A INPUT -j ACCEPT -p icmp --icmp-type echo-reply
# iptables -P OUTPUT DROP
# iptables -A OUTPUT -j ACCEPT -p tcp
# iptables -A OUTPUT -j ACCEPT -p udp --destination-port 53
# iptables -A OUTPUT -j ACCEPT -p udp --destination-port 67 --source-port
68
# iptables -A OUTPUT -j ACCEPT -p icmp --icmp-type echo-request
Пример 2: то же самое, что в примере 1, но все “отбитые” пакеты протоколируются.
Для того, чтобы добиться такого эффекта, нужно создать дополнительную цепочку, которая будет протоколировать и удалять пакеты. Эту цепочку мы назовем KILLER – вполне обоснованно, не так ли? Кроме того, мы исправим политики стандартных цепочек так, чтобы запрещенные пакеты не удалялись, а “забрасывались” в созданную нами цепочку KILLER, а нашей основной цели (сначала протоколировать, потом удалить пакет) можно добиться просто указав два действия – сначала LOG, затем DROP. Поскольку действие LOG не является прерывающим обработку, мы получим требуемый нам эффект:
747

# iptables -N KILLER
# iptables -A KILLER -j LOG
# iptables -A KILLER -j DROP
# iptables -P INPUT KILLER
# iptables -A INPUT -j ACCEPT -i lo
# iptables -A INPUT -j ACCEP -p tcp ! --syn
# iptables -A INPUT -j ACCEPT -p udp --source-port 53
# iptables -A INPUT -j ACCEPT -p udp --source-port 67 --destination-port 68
# iptables -A INPUT -j ACCEPT -p icmp --icmp-type destination-unreachable
# iptables -A INPUT -j ACCEPT -p icmp --icmp-type time-exceeded
# iptables -A INPUT -j ACCEPT -p icmp --icmp-type parameter-problem
# iptables -A INPUT -j ACCEPT -p icmp --icmp-type echo-reply
# iptables -P OUTPUT KILLER
# iptables -A OUTPUT -j ACCEPT -p tcp
# iptables -A OUTPUT -j ACCEPT -p udp --destination-port 53
# iptables -A OUTPUT -j ACCEPT -p udp --destination-port 67 --source-port
68
# iptables -A OUTPUT -j ACCEPT -p icmp --icmp-type echo-request

Каталог: pub -> docs books -> Linux -> Linux 2
pub -> Буланов С. В. Кудрявцева Е. Л. Развитие креативности билингвов: путь от интеркультурности к формированию «человека мира»
pub -> «октябрьский лицей»
pub -> Самообследование гоу сош «Школа надомного обучения» №196 по направлениям деятельности. Общие вопросы
pub -> Занятие для математического кружка. Задачи работы
pub -> Доклад муниципальное образовательное
pub -> Публичный доклад. 2013 год Общая характеристика образовательного учреждения. Место расположения
pub -> Публичный доклад муниципального общеобразовательного учреждения средней общеобразовательной школы №13


Поделитесь с Вашими друзьями:
1   ...   42   43   44   45   46   47   48   49   50


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал