Документація українською/ Адміністрування/ Iptables - мережевий екран netfilter firewall/ Дії та переходи
← Критерії | Iptables - мережевий екран netfilter firewall | Приклади →

Дії і переходи повідомляють правилу, що необхідно зробити, якщо пакет задовільняє вказаному критерію. Найчастіше вживаються дії ACCEPT і DROP. Проте, давайте коротко розглянемо поняття переходів.

Опис переходів в правилах виглядає точно як і і опис дій, тобто дадається параметр -j з назвою ланцюжка правил, до якого потрібно перейти. На переходи накладаються обмеження: перше - ланцюжок, до якого виконується перехід, повинен перебувати у тій же таблиці, що і ланцюжок, з якого перехід виконується, друге - цільовий ланцюжок має бути створено перед його використанням у переходах. Наприклад, створимо ланцюжок tcp_packets в таблиці filter з допомогою команди

iptables -N tcp_packets

Тепер ми можемо виконувати переходи до цього ланцюжка подібно:

iptables -A INPUT -p tcp -j tcp_packets

Тобто. зустрівши пакет протоколу tcp, iptables зробить перехід на ланцюжок tcp_packets і продовжить рух пакета у цій ланцюжку. Якщо пакет досяг кінця ланцюжка він буде повернуто в що викликає ланцюжок (у разі це ланцюжок INPUT) і рух пакета продовжиться з правила, наступного за правилом, що викликає перехід. Якщо до пакету у вкладеною ланцюжку буде застосовано дію ACCEPT, то автоматично пакет вважатиметься прийнятим й у викликає ланцюжку вже нічого очікувати продовжувати рух щодо що викликають цепочкам. Проте пакет піде іншим цепочкам за іншими таблицях. Додаткову інформацію про порядок проходження ланцюжків і таблиць ви дістанете у розділі [#TRAVERSINGOFTABLES Порядок проходження таблиць і ланцюжків].

Дія - це визначена команда, яка описувала дію, що слід виконати, якщо пакет припала на заданим критерієм. Наприклад, можна застосувати дію DROP чи ACCEPT до пакету, залежно від потреб. Є й низка інших дій, які описуються нижчий за цьому розділі. У вико 3D;ання одних дій, пакет припиняє проходження ланцюжком, наприклад DROP і ACCEPT, внаслідок інших, після виконання якихось операцій, продовжує перевірку, наприклад, LOG, внаслідок роботи третіх навіть видозмінюється, 3D;априклад DNAT і SNAT, TTL і TOS, але як і продовжує просування ланцюжком.

Дія ACCEPT

Ця операція немає додаткових ключів. Якщо над пакетом виконується дію ACCEPT, то пакет припиняє рух щодо ланцюжку (та знайоме всім що викликало цепочкам, якщо поточна ланцюжок була вкладеною) й вважається ПРИЙНЯТИМ (тобто пропускається), тим щонайменше, пакет продовжить рух щодо цепочкам за іншими таблицях і то, можливо відкинутCE; там. Дія задається з допомогою ключа -j ACCEPT.

Дія DNAT

DNAT (Destination Network Address Translation) використовується для перетворення адреси місця призначення до IP заголовку пакета. Якщо пакет підпадає під критерій правила, виконує DNAT, цей пакет, всі наступні пакунки з цього ж потоку, зазнають перетворенню адреси призначення й передані на необхідну пристрій, хост чи мережу. Дане дія може, приміром, успішно використовуватися надання доступу до вашого web-серверу, що у локальної мережі, і має реального IP адреси. І тому ви будуєте правило, яке перехоплює пакети, на HTTP порт брендмаудера і виконуючи DNAT передаєте їх у локальний адресу web-сервера. І тому дії як і можна вказати діапазон адрес, тоді вибір адреси призначення кожному за нового потоку здійснюватиметься случайнам чином.

Дія DNAT може виконуватися лише у ланцюжках PREROUTING і OUTPUT таблиці nat, й у вкладених под-цепочках. Важливо запам'ятати, що вкладені подцепочки, реалізують DNAT нічого не винні викликатися з деяких інших ланцюжків, крім PREROUTING і OUTPUT.

Таблиця 6-16. Дія DNAT

--to-destination : Ключ --to-destination вказує, якиC9; IP адресу може бути підставлений як адреси місця призначення. У вище наведеному прикладі переважають у всіх пакетах, котрі відвідують адресу 15.45.23.67, адресу призначення буде змінено однією з діапазону від 192.168.1.1 до 192.168.1.10. Як вказувалося вище, все пакунки з одного потоку спрямовуватимуться однією і хоча б адресу, а кожної нової потоку буде вибиратися одне із адрес у зазначеному діапазоні випадково. Можна ще визначити єдиний IP адресу. Можна додатково вказати порт чи діапазон портів, який (які) буде 3F;ереспрямований трафік. І тому після ip адреси через двокрапка зазначте порт, наприклад --to-destination 192.168.1.1:80, а вказівку діапазону портів така: --to-destination 192.168.1.1:80-100. Як багато можете бачити, синтаксис дій DNAT і SNAT багато в D7;ому схожий. Майте на увазі, що одержав вказівку портів можлива тільки під час роботи з протоколом TCP чи UDP, за наявності опції --protocol критеріям.

Приклад

    iptables -t nat -A PREROUTING -p tcp -d 15.45.23.67 --dport 80 -j DNAT --to-destination 192.168.1.1-192.168.1.10

Дія DNAT дуже складно у використанні та має потребу пояснення. Розглянемо пD0;остий приклад. Ми маємо WEB сервер і хочемо дозволити доступу до нього з Інтернет. Ми маємо лише одне реальний IP адресу, а WEB-сервер лежить у локальної мережі. Реальний IP адресу $INET_IP призначений брендмаудеру, HTTP сервер має локальний адресу $HTTP_IP і, нарешті брендмаудер має локальний алрес $LAN_IP. Спочатку додамо просте правило в ланцюжок PREROUTING таблиці nat:

iptables -t nat -A PREROUTING --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP

Відповідно до це правило, все пакети, вступники на 80-й порт адреси $INET_IP перенаправляются на наш внутрішній WEB-сервер. Якщо тепер звернутися до WEB-серверу з Інтернет, то ми все працюватиме чудово. Але що станеться, якщо спробувати з'єднатися з нею з локаль 3D;ої мережі? Поєднання просто більше не встановиться. Погляньмо як маршрутизируются пакети, що йдуть з Інтернет на наш WEB-сервер. Для простоти викладу приймемо адресу клієнти на Інтернет рівним $EXT_BOX.

  1. Пакет залишає клієнтський вузол з адресою $EXT_BOX і направляється на $INET_IP
  2. Пакет приходять наш брендмаудер.
  3. Брандмауэр, відповідно до вищенаведеним правилом, підміняє адресу призначення і передає його далі, до інших ланцюжка.
  4. Пакет передається на $HTTP_IP.
  5. Пакет надходить на HTTP сервер і сервер передає відповідь через брендмаудер, тоді як таблиці маршрутизації вона як шлюз для $EXT_BOX. Зазвичай, його призначають шлюзом по-умолчанию для HTTP серверу.
  6. Брандмауэр виробляє зворотний підстановку адреси у пакеті, що тепер така, начебто пакет було сформовано на брендмаудере.
  7. Пакет передається клієнту $EXT_BOX.

Нині ж подивимося, що буде, якщо запит посилається з вузла, що за тієї ж локальної мережі. Для простоти викладу приймемо адресу клієнти на локальної мережі рівним $LAN_BOX.

  1. Пакет залишає $LAN_BOX.
  2. Надходить на брендмаудер.
  3. Виробляється підстановка адреси призначення, проте адресу відправника не підміняється, тобто. вихідний адресу залишається у пакеті без зміни.
  4. Пакет залишає брендмаудер і вирушає на HTTP сервер.
  5. HTTP сервер, готуючись вилетіти відповіді, виявляє, що тут клієнта перебуває у локальної мережі (оскільки пакет запиту містив оригінальний IP адресу, що тепер перетворився на адресу призначення) і тому відправляє пакет безпосередньо на $LAN_BOX.
  6. Пакет надходить на $LAN_BOX. Клієнт "плутається", оскільки відповідь прийшов ні з того вузла, який вирушав запит. Тому клієнт "скидає" пакет відповіді і продовжує чекати "справжній" відповідь.

Проблема вирішується досить просто з допомогою SNAT. Нижче наводиться правило, яке виконує цю функцію. Це змушує HTTP сервер передавати відповіді наш брендмаудер, які потім передадуть клієнту.

iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT \
--to-source $LAN_IP

Запам'ятайте, ланцюжок POSTROUTING обробляється останній і на цей момент пакет пройшла процедуру перетворення DNAT, тому критерій будується з урахуванням адреси призначення $HTTP_IP.

Якщо ви вважаєте, що у цьому можна зупинитися, ви помиляєтеся! Уявімо ситуацію, коли як клієнта виступає сам брендмаудер. Тоді, на жаль, пакети передаватимуться на локальний порт з номером 80 самого брендмаудера, а чи не на $HTTP_IP. Щоб вирішити цієї проблеми, додамо правило:

iptables -t nat -A OUTPUT --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP

Тепер ніяких проблем, з доступом до нашого WEB-серверу, не має виникати.

Кожен має зрозуміти, що це правила призначені тільки до коректною обробки адресації пакетів. На додачу до цих правилам вам може знадобитися написати додаткові правила для ланцюжка FORWARD таблиці filter. Не забудьте у своїй, що пакети мали ланцюжок PREROUTING і тому їх адреси призначення вже змінені дією DNAT.

Дія DROP

Дане дію просто "скидає" пакет і iptables "забуває" про існуванні. "Скинуті" пакети припиняють свій рух повністю, тобто. де вони передаються до інших таблиці, як що стосується дією ACCEPT. Слід пам'ятати, що це дія може відбуватися мати негативні наслідки, оскільки не може залишати незакриті "мертві" сокети як у боці серверу, і за клієнта, найкращий спосіб захисту буде використання дії REJECT особливо в захисту від сканування портів.

Дія LOG

LOG -- дію, яке слугує для журналирования окремих пакетів і подій. У журнал можуть заноситися заголовки IP пакетів й інша яка цікавить вас інформація. Інформація журналу то, можливо потім прочитане з допомогою dmesg чи syslogd або з допомогою інших програм. Чудове засіб для налагодження ваших правил. Непогано було на період налагодження правил замість дії DROP використовувати дію LOG, щоб остаточно переконатися, що ваша брендмаудер працює бездоганно. Зверніть вашу увагу як і на дію ULOG, яке напевно зацікавить вас зі своїх можливостей, оскільки це дозволяє виконувати запис журналируемой інформації над системний журнал, а базі даних MySQL тощо..

Зверніть увагу - якщо в вас є проблеми із записом в системний журнал, це проблеми не iptables чи netfilter, а syslogd. По інформацію по конфигурированию syslogd звертайтеся до man syslog.conf.

Дія LOG має п'ять ключів, вказаних нижче.

Таблиця 6-17. Ключі дії LOG

--log-level : Використовується для завдання рівня журналирования (log level). Повний список рівнів ви знайдете у керівництві (man) по syslog.conf. Зазвичай, можна поставити такі рівні: debug, info, notice, warning, warn, err, error, crit, alert, emerg і panic. Ключове слово error означає той самий, як і err, warn - warning і panic - emerg. Важливо: на минулих трьох парах слів годі було використовувати error, warn і panic. Пріоритет визначає різницю у цьому як заноситимуться сполучення журнал. Усі повідомлення заносять у журнал засобами ядра. Якщо ви хоч встановіть рядок kern.=info /var/log/iptables в файлі syslog.conf, то ми все ваші повідомлення з iptables, використовують рівень info, заноситимуться в файл /var/log/iptables Проте, у цей файл потраплять й інші повідомлення, які з інших підсистем, що використовують рівень info. За додаткової інформацією по syslog і syslog.conf я рекомендую звертатися до manpages і HOWTO.

Приклад

    iptables -A FORWARD -p tcp -j LOG --log-level debug

--log-prefix : Ключ задає текст (префікс), яким буде випереджатися все повідомлення iptables. Повідомлення зі специфічним префіксом потім легко можна знайти, приміром, з допомогою grep. Префікс може містити до 29 символів, зокрема й прогалини.

Приклад

   iptables -A INPUT -p tcp -j LOG --log-prefix "INPUT packets"

--log-tcp-sequence : Цей ключ дозволяє заносити до наукового журналу номер TCP Sequence пакета. Номер TCP Sequence ідентифікує кожен пC0;кет серед яких і визначає порядок "складання" потоку. Цей ключ потенційно дуже небезпечна безпеки системи, якщо системний журнал дозволяє доступ "НА ЧИТАННЯ" всім користувачам. Як людина інший журнал, у якому повідомлення від iptables.

Приклад

    iptables -A INPUT -p tcp -j LOG --log-tcp-sequence

--log-tcp-options : Цей ключ дозволяє заносити в системний журнал різні дані з заголовка TCP пакета. Така можливість зовсім може бути корисною при налагодженні. Цей ключ немає додаткових параметрів, як більшість ключів дії LOG.

Приклад

    iptables -A FORWARD -p tcp -j LOG --log-tcp-options

--log-ip-options : Цей ключ дозволяє заносити в системний журнал різні дані з заголовка IP пакета. Багато в чому схожий із ключем --log-tcp-options, але працює тільки з IP заголовком.

Приклад

    iptables -A FORWARD -p tcp -j LOG --log-ip-options

Дія MARK

Використовується для установки міток для певних пакетів. Це може виконуватися в межах таблиці mangle. Установка міток зазвичай використовується потреб маршрутизації пакетів різноманітні маршрутам, обмеження трафіку тощо.. За додаткової інформацією ви можете звернутися до [#LARTC Linux Advanced Routing and Traffic Control HOW-TO]. Майте на увазі, що "мітка" пакета існує лише у період поки пакет не залишив брендмаудер, тобто. мітка не передається через мережу. Якщо потрібно якось позначити пакети, щоб використовувати маркірування в інший машині, то можете спробувати маніпулювати бітами поля TOS.

Таблиця 6-18. Ключі дії MARK

--set-mark : Ключ --set-mark встановлює мітку на пакет. Після ключа --set-mark повинно бути ціле беззнаковое число.

Приклад:

    iptables -t mangle -A PREROUTING -p tcp --dport 22 -j MARK --set-mark 2

Дія MASQUERADE

Маскарадинг (MASQUERADE) основу своєї представляє той самий, як і SNAT тільки має ключа --to-source. Причиною цього те, що маскарадинг може працювати, наприклад, з dialup підключенням чи DHCP, тобто. у випадках, коли IP адресу присвоюється влаштуванню динамічно. Коли ви є динамічний підключення, потрібно використовувати маскарадинг, Якщо ж ви статична IP підключення, то безперечно найкращим виходом буде використання дії SNAT.

Маскарадинг передбачає отримання IP адреси від заданого мережного інтерфейсу, замість прямого його вказівки, як це робиться з допомогою ключа --to-source діє SNAT. Дія MASQUERADE має хороше властивість - "забувати" сполуки під час зупинки мережного інтерфейсу. У разі SNAT, у цій ситуації, в таблиці трассировщика залишаються даних про втрачених з'єднаннях, й інші дані можуть зберігатися до діб, поглинаючи цінну пам'ять. Ефект "забудькуватості" пов'язаний із тим, що з зупинці мережного інтерфейсу з динамічним IP адресою, є можливість ось на чому запуску отримати інший IP адресу, але нинішнього разі будь-які сполуки однаково втрачені, і було б нерозумно зберігати трассировочную інформацію.

Як багато зрозуміли, дію MASQUERADE можна використовувати замість SNAT, навіть коли ви маєте постійний IP адресу, проте, попри позитивні риси, маскарадинг годі було вважати кращим у разі, оскільки вона дає велике змістове навантаження на систему.

Дія MASQUERADE допускається вказувати лише у ланцюжку POSTROUTING таблиці nat, як і і дію SNAT. MASQUERADE має ключ, описуваний нижче, використання якого необов'язково.

Таблиця 6-19. Дія MASQUERADE

--to-ports : Ключ --to-ports використовується для вказівки порту джерела чи діапазону портів вихідного пакета. Можна вказати один порт, наприклад: --to-ports 1025, чи діапазон портів як: --to-ports 1024-3000. Цей ключ можна використовувати лише у правилах, де критерій містить явне вказівку на протокол TCP чи UDP з допомогою ключа --protocol.

Приклад:

    iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE --to-ports 1024-31000

Дія MIRROR

Дія MIRROR можна використовувати вами лише експериментів й у демонстраційних цілях, оскільки це дія може призвести до "зацикливанию" пакета і цього до "Отказу до обслуговування". Унаслідок MIRROR у пакеті, поля source і destination змінюються місцями (invert the source and destination fields) і пакет вирушає до мережу. Використання цієї команди може мати дуже потішний результат, напевно, із боку досить потішно спостерігати, як який нибудь кульхацкер намагається "зламати" свій власний комп'ютер!

Дане дію допускається використовувати лише у ланцюжках INPUT, FORWARD і PREROUTING, й у ланцюжках, що викликаються з цих. Пакети, відправлені до мережі дією MIRROR большє нє піддаються фільтрації, трассировке чи NAT, уникаючи цим "зациклення" та інших неприємностей. Але це значить, що проблеми з цим дією немає. Давайте, приміром, уявімо, що у хосте, использующем дію MIRROR фабрикується пакет, з TTL рівним 255, цей самий самий хост і пакет підпадає під критерій "зеркалирующего" правила. Пакет "відбивається" цей самий хост, а бо між "приймачем" і "передавачем" лише 1 хоп (hop) то пакет стрибатиме туди, й назад 255 раз. Непогано для крякера, адже, при величині пакета 1500 байт, ми втратимо до 380 Кбайт трафіку!

Дія QUEUE

ействие QUEUE ставить пакет у чергу на обробку користувальницькому процесу. Вона може бути використано п 3E;треб обліку, проксирования чи додаткової фільтрації пакетів.

Від перекладача: Далі автор докладно розмірковує у тому, що обговорення цієї теми далеко за межі документи й ін., тому, не роздумуючи, наведу тут цитату з http://antonio.mccinet.ru/protection/iptables_howto.html у перекладі Євгена Данильченко aka virii5, eugene@kriljon.ru

"...Щоб ця мета була корисна, необхідні решта 2 компонента:

  1. "queue handler" - оброблювач черги, який працює про передачу пакетів між ядром і користувальницьким додатком; і
  2. користувальницьке додаток яке, можливо обробляти, і вирішувати долю пакетів.

Стандартний оброблювач черги для IPv4 - модуль ip-queue, який поширюється з ядром і помечен як експериментальний. Нижче дано приклад, як і використовувати iptables передачі пакетів в користувальницьке додаток:

 # modprobe iptable_filter
 # modprobe ip_queue
 # iptables -A OUTPUT -p icmp -j QUEUE

З цією правилом, створені локально пакети ICMP типу (такі, що створюються скажімо з допомогою команди ping) потрапляють у модуль ip_queue, і потім намагається передати в користувальницьке додаток. Якщо жоден з таких додатків не знайдено, пакети скидаються. Щоб написати користувальницьку програму обробки пакетів, використовуйте libipq АПІ. Воно поширюється з пакетом iptables. Приклади можна знайти у testsuite tools (наприклад redirect.c) на CVS. Статус ip_queue можна перевірити з допомогою: /proc/net/ip_queue Максимальну довжину черги (тобто, число пакетів що передаються у користувальницьке додаток без підтвердження обробки) можна контролювати з допомогою: /proc/sys/net/ipv4/ip_queue_maxlen За умовчанням - максимальна довга черги дорівнює 1024. Щойно цю межу досягається, нові пакети будуть скидатися, поки черга знизитися нижче даного краю. Хороші протоколи, такі як TCP інтерпретують скинуті пакети як переобтяженість каналу передачі, й з цим справляються (наскільки я пам'ятаю, пакет буде просто пересланий наново віддаленій стороною, прим. переклад.). Проте, може знадобитися деякого роду эксперементирование, щоб визначити оптимальну довжину черги, у кожному конкретному випадку, коли з вмовчанням чергу занадто низька..."

Дія REDIRECT

Виконує перенапрямок пакетів і потоків в інший порт тієї ж самої машини. Приміром, можна пакети, вступники на HTTP порт переспрямувати на порт HTTP proxy. Дія REDIRECT зручне до виконання "прозорого" проксирования (transparent proxying), коли машини в локальної мережі навіть мають про існування прокси.

REDIRECT може використовуватися лише в ланцюжках PREROUTING і OUTPUT таблиці nat. І це дію можна виконувати в подцепочках, що викликаються і вищевказаних. Для дії REDIRECT передбачено лише одне ключ.

Таблиця 6-20. Дія REDIRECT

--to-ports : Ключ --to-ports визначає порт чи діапазон портів призначення. Без вказівки ключа --to-ports, перенаправлення немає, тобто. пакет йде той порт, куди й призначили. У прикладі, наведеному вище, --to-ports 8080 зазначений один порт призначення. Якщо потрібне вказати діапазон портів, ми повинні написати щось схоже --to-ports 8080-8090. Цей ключ можна використовувати лише у правилах, де критерій містить явне вказівку на протокол TCP чи UDP з допомогою ключа --protocol.

Приклад:

    iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080

Дія REJECT

REJECT використовується, зазвичай, у тих-таки самих ситуаціях, як і DROP, та на відміну від DROP, команда REJECT видає повідомлення про помилку на хост, який передав пакет. Дія REJECT нині може використовуватися лише в ланцюжках INPUT, FORWARD і OUTPUT (й у вкладC5;них у них ланцюжках). Поки що лише єдиний ключ, управляючий поведінкою команди REJECT.

Таблиця 6-21. Дія REJECT

--reject-with : Вказує, яке повідомлення необхідно передати у відповідь, якщо пакет припала на заданим критерієм. При застосуванні дії REJECT до пакету, спочатку на хост-отправитель буде відісланий зазначений відповідь, та був пакет буде "скинуто". Допускається використовувати такі типи відповідей: icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited і icmp-host-prohibited. По-умолчанию передається повідомлення port-unreachable. Усі вищевказані типи відповідей є ICMP error messages. Додаткову інформацію з типам ICMP повід 3E;млень ви можете отримати у додатку [#ICMPTYPES Типи ICMP]. На закінчення зазначимо іще одна тип відповіді - tcp-reset, що використовується лише протоколу TCP. Якщо зазначено значення tcp-reset, то дію REJECT передасть у відповідь пакет TCP RST, пакети TCP RST йдуть на закриття TCP сполук. За додаткової інформацією звертайтеся до [#RFC793 RFC 793 - Transmission Control Protocol]. (Список типів ICMP відповідей та їх алиасов ви дістанете запровадивши команду iptables -j REJECT -h прим. перев.).

Приклад:

    iptables -A FORWARD -p TCP --dport 22 -j REJECT --reject-with tcp-reset

Дія RETURN

Дія RETURN припиняє рух пакета за поточною ланцюжку правив і виробляє повернення у що викликає ланцюжок, якщо поточна ланцюжок була вкладеною, чи, якщо поточна ланцюжок лежить на жіночих найвищому рівні (наприклад INPUT), чи до пакету буде застосована політика по-умолчанию. Зазвичай, як політики по-умолчанию призначають дії ACCEPT чи DROP .

Наприклад, скажімо, що пакет йде з ланцюжку INPUT і зустрічає правило, яке виробляє і у вкладену ланцюжок - --jump EXAMPLE_CHAIN. Далі, в ланцюжку EXAMPLE_CHAIN пакет зустрічає правило, яке виконує дію --jump RETURN. Тоді станеться повернення пакета в ланцюжок INPUT. Інший приклад, нехай пакет зустрічає правило, яке виконує дію --jump RETURN в ланцюжку INPUT. Тоді до пакету буде застосована політика по-умолчанию ланцюжка INPUT.

Дія SNAT

SNAT використовується для перетворення мережевих адрес (Source Network Address Translation), тобто. зміна вихідного IP адреси в IP заголовку пакета. Наприклад, це дію можна використовуватиме надання виходу до Інтернету іншим комп'ютерів з локальної мережі, маючи лише одне унікальний IP адресу. І тому. необхідно включити пересилку пакетів (forwarding) в ядрі і далі створити правила, які транслювати вихідні IP адреси нашої локальної мережі на реальний зовнішній адресу. Через війну, світ щось знатиме про нашу локальної мережі, він вважати, що запити прийшли з нашої брендмаудера.

SNAT допускається виконувати лише у таблиці nat, в ланцюжку POSTROUTING. Інакше кажучи, тільки тут допускається перетворення вихідних адрес. Якщо Сталін перший пакет у поєднанні піддався перетворенню вихідного адреси, то ми все наступні пакети, від цього ж сполуки, будуть перетворені автоматично і підуть цю ланцюжок правил.

Таблиця 6-22. Дія SNAT

--to-source : Ключ --to-source використовується для вказівки адреси, присваемового пакету. Усі просто, ви вказуєте IP адресу, який підставлений в заголовок пакета як вихідного. Якщо ви і збираєтеся перерозподіляти навантаження між кількома брендмаудерами, можна вказати діапазон адрес, де початковий і кінцевий адреси діапазону поділяються дефісом, наприклад: 194.236.50.155-194.236.50.160. Тоді, конкретний IP адресу буде вибиратися з діапазону випадково кожному за нового потоку. Додатково можна вказати діапазон портів, які використовуватимуться лише потреб SNAT. Усі вихідні порти будуть після цього перекартироваться у заданий діапазон. iptables намагається, за можливості, уникати перекартирования портів, проте все можливо, і тоді виробляється перекартирование . Якщо діапазон портів не заданий, то вихідні порти нижче 512 перекартируются буде в діапазоні 0-511, порти буде в діапазоні 512-1023 перекартируются буде в діапазоні 512-1023, і, нарешті порти з діапазону 1024-65535 перекартируются буде в діапазоні 1024-65535. Що ж до портів призначення, то не піддаються перекартированию.

Приклад:

    iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to-source 194.236.50.155-194.236.50.160:1024-32000

Дія TOS

Команда TOS використовується для установки битов на полі Type of Service IP заголовка. Поле TOS містить 8 біт, що використовуються маршрутизації пакетів. Це з кількох полів, використовуваних iproute2. Також важливо пам'ятати, що це полі може оброблятися різними маршрутизаторами із єдиною метою вибору маршруту руху пакета. Як вказувалося вище, це полі на відміну від MARK, зберігає свою значення під час руху через мережу, тож можна використовувати вами для маршрутизації пакета. Сьогодні, більшість маршрутизаторів з Інтернету неможливо обробляють це полі, проте і такі, котрі дивляться нею. Якщо ви і використовуєте це полі своїх потреби, такі маршрутизатори можуть скласти неправильне рішення у виборі маршруту, тому, найкраще використати це полі на свої потреб лише доти вашої WAN чи LAN.

Дія TOS сприймає лише визначені числові значення й мнемоніки, що ви можете знайти у linux/ip.h. Якщо до вас справді потрібне встановлювати довільні значення полі TOS, можна скористатися "латкою" FTOS із російського сайту [#PAKSECURED Paksecured Linux Kernel patches], підтримуваного Matthew G. Marsh. Проте, будьте вкрай обережні з цим "латкою". Не варто використовувати нестандартні значення TOS інакше як і особливих ситуаціях.

Дане дію допускається виконувати лише доти таблиці mangle.

У деяких старих версіях iptables (1.2.2 і від) це дію реалізовано з помилкою (не виправляється контрольна сума пакета), але це веде спричиняє порушення протоколу обміну і цього такі сполуки обриваються.

Команда TOS має сенс тільки один ключ, який описаний нижче.

Таблиця 6-23. Дія TOS

--set-tos : Ключ --set-tos визначає числове значення в десятковому чи шестнадцатиричном вигляді. Оскільки полі TOS є 8-бітним, ви можете вказати число буде в діапазоні від 0 до 255 (0x00 - 0xFF). Проте, більшість значень цього поля неможливо використовуються. Цілком можливо, що у майбутніх реалізаціях TCP/IP числові значення можуть змінитися, тому, во-избежание помилок, краще використовувати мнемонічні позначення: Minimize-Delay (16 чи 0x10), Maximize-Throughput (8 чи 0x08), Maximize-Reliability (4 чи 0x04), Minimize-Cost (2 чи 0x02) чи Normal-Service (0 чи 0x00). По-умолчанию більшість пакетів мають ознака Normal-Service, чи 0. Список мнемоник ви дістанете, виконавши команду iptables -j TOS -h.

Приклад:

    iptables -t mangle -A PREROUTING -p TCP --dport 22 -j TOS --set-tos 0x10

Дія TTL

Дія TTL використовується зміни вмісту поля Time To Live в IP заголовку. Одне з варіантів застосування цієї дії - це визначте поля Time To Live В УСІХ вихідних пакетах за одну і те значення. Навіщо це?! Є певні провайдери, які не люблять, коли одним підключенням користується кілька комп'ютерів, коли ми починаємо встановлювати попри всі пакети один і той ж значення TTL, тим самим ми позбавляємо провайдера однієї з критеріїв визначення те, що підключення до Інтернету поділяється кількома комп'ютерами. Наприклад, можна привести число TTL = 64, що є стандартним для ядра Linux.

За додаткової інформацією встановлення значення по-умолчанию звертайтеся до [#IP-SYSCTLTXT ip-sysctl.txt], що ви знайдете при застосуванні [#OTHERRESOURCES Посилання інші ресурси].

Дія TTL можна вказувати лише у таблиці mangle і більше. Для даного дії передбачено 3 ключа, описуваних нижче.

Таблиця 6-24. Дія TTL

--ttl-set : Встановлює полі TTL в заданий значення. Оптимальним вважається значення близько 64. Не занадто багато, але й замало Не ставте дуже велике значення, це може мати неприємні наслідки для вашої мережі. Уявіть собі, що пакет "зациклюється" між двома неправильно налаштованими роутерами, тоді, на великих значеннях TTL, є "втратити" значну частину пропускну здатність каналу.

Приклад:

    iptables -t mangle -A PREROUTING -і eth0 -j TTL --ttl-set 64

--ttl-dec : Зменшує значення поля TTL на заданий D7;исло. Наприклад, нехай вхідний пакет має значення TTL однакову 53 і ми виконуємо команду --ttl-dec 3, тоді пакет залишить наш хост з полем TTL рівним 49. Майте на увазі, що мережевий код автоматично зменшить значення TTL на 1, тому, фактично ми маємо 53 - 3 - 1 = 49.

Приклад:

    iptables -t mangle -A PREROUTING -і eth0 -j TTL --ttl-dec 1

--ttl-inc : Збільшує значення поля TTL на заданий число. Візьмемо попередній приклад, нехай до нас потрапляє пакет з TTL = 53, тоді, після виконання команди --ttl-inc 4, не вдома з нашої хоста, пакет матиме TTL = 56, пам'ятаймо про автоматичному зменшенні поля TTL мережним кодом ядра, тобто. фактично ми маємо вираз 53 + 4 - 1 = 56. Збільшення поля TTL можна використовувати у тому, щоб зробити наш брендмаудер менш "помітним" для трассировщиков (traceroutes). Програми трасування люблять за цінну інформацію у пошуку проблемних ділянок мережі, і ненавидять у цей, оскільки цю інформацію можна використовувати крякерами в непорядних цілях. Приклад використання ви можете знайти у сценарії [#TTL-INCTXT Ttl-inc.txt].

Приклад:

    iptables -t mangle -A PREROUTING -і eth0 -j TTL --ttl-inc 1

Дія ULOG

Дія ULOG дає можливість журналирования пакетів в користувальницьке простір. Воно заміняє традиційне дію LOG, що базується на системному журналі. З використанням цього дії, пакет, через сокети netlink, передається спеціальному демону котрі можуть виконувати дуже детальне журналирование у різних форматах (звичайний текстовий файл, база даних MySQL тощо.) і при цьому підтримує можливість додавання надбудов (плагинов) на формування різних вихідних форматів і методи обробки мережевих протоколів. Пользовательскую частина ULOGD ви можете дістати домашньої сторінці [#ULOGDSITE ULOGD project page].

Таблиця 6-25. Дія ULOG

--ulog-nlgroup : Ключ --ulog-nlgroup повідомляє ULOG у яку групу netlink має бути переданий пакет. Усього існує 32 групи (від 1 до 32). Якщо ви хоч хочете передати пакет в 5-ту групу, можна просто вказати --ulog-nlgroup 5. По-умолчанию використовується 1-ша група.

Приклад:

    iptables -A INPUT -p TCP --dport 22 -j ULOG --ulog-nlgroup 2

--ulog-prefix : Ключ --ulog-prefix має хоча б сенс, як і аналогічна опція діє LOG. Довжина рядки префікса має перевищувати 32 символу.

Приклад:

    iptables -A INPUT -p TCP --dport 22 -j ULOG --ulog-prefix "SSH connection attempt: "

--ulog-cprange : Ключ --ulog-cprange визначає, яку частку пакета, в байтах, треба передавати демону ULOG. Якщо вказати число 100, як показано в прикладі, то демону передають лише 100 байт з пакету, це, що демону буде передано заголовок пакета і певна частину Одеської області даних пакета. Якщо вказати 0, він передC0;ний весь пакет, незалежно з його розміру. Значення по-умолчанию одно 0.

Приклад:

    iptables -A INPUT -p TCP --dport 22 -j ULOG --ulog-cprange 100

--ulog-qthreshold : Ключ --ulog-qthreshold встановлює величину буфера у сфері ядра. Наприклад, якщо поставити величину буфера рівної 10, як і прикладі, то ядро накопичуватиме журналируемналаштованимие пакети у внутрішньому буфері і передавати їх у користувальницьке простір групами по 10 пакетів. По-умолчанию розмір буфера дорівнює 1 через збереження зворотної сумісності з ранніми версіями ulogd, які могли приймати групи пакетів.

Приклад:

    iptables -A INPUT -p TCP --dport 22 -j ULOG --ulog-qthreshold 10