Разработка динамических сайтов
SEO услуги
Управление контекстной рекламой

Вход на хостинг

Имя пользователя:*

Пароль пользователя:*

IT-новости

20.04.2016 iPhone 2017 года поместят в водонепроницаемый корпус из стекла

Линейка iPhone в новом году серьезно поменяется. В этом уверен аналитический исследователь Мин Чи Ку......

подробнее

30.07.2015 Ищем уникальный контент для сайта

Ищем уникальный контент для сайта Без уникального контента Ваш сайт обречен на то, что его страницы......

подробнее

11.05.2015 Распространённые ошибки разработчиков сайтов

Не секрет, что в сети Интернет насчитывается миллионы сайтов, и каждый день появляются тысячси новых......

подробнее

Некоторые особенности настройки iptables и ещё одну маленькую хитрость я хотел бы написать сейчас, а именно о Frame Diverter, который может быть очень полезным средством при создании многофункциональных мостов, фактически являющихся прозрачными прокси-серверами с вытекающими удобствами.

У читателя может возникнуть мысль: если можно создать прозрачный МЭ, который даже по traceroute (tracert для Windows) не виден, то почему бы не сделать прозрачными и другие функции? Скажем, вы собрались почистить вентиляторы от пыли, и можете смело выключать свой сервер в рабочий день, заменив его патчкордом. Удобно, не так ли? Или если у вас 1000 и более машин, вам не надо идти и менять на всех конфигурацию. Удобства всем понятны, так что перейдём лучше к описанию их реализации.

Если вы на МЭ поднимете прокси-сервер, например, sqiud, то логично предположить, что можно сделать правило, берущее все пакеты, уходящие в Интернет на 80-е порты с интерфейса и заворачивающее их на локальный прокси:

iptables -t nat -A PREROUTING -i eth1 -p tcp -d 0/0 --dport 80 -j REDIRECT --to-ports 3128

(ipchains -A input -i eth1 -p tcp -d 0/0 80 -j REDIRECT 3128 )

Но не тут-то было – эффекта нужного не будет, так как пакеты изначально не адресованы нашему МЭ. Если бы заменить MAC-адрес в пакетах, идущих на 80 порт с MAC-адреса шлюза на MAC-адрес интерфейса Linux eth1, то тогда бы такой проблемы не было. Но счастье открытого кода в том и заключается, что если кому-то одному нужно было что-то сделать, то он это написал и выложил на всеобщее пользование – так что добро пожаловать на http://diverter.sourceforge.net.

К сожалению, на сегодня развитие данного проекта прекращено, последние версии упоминаемых ядер на сайте – 2.2.19 и 2.4.10. Возможно, это связано с тем, что принципиально нового ничего не появилось, ошибок не найдено, поэтому данную программу divert-utils-0.221.tar.gz можно использовать и для новых ядер. Завёртывание нужного нам трафика осуществляется парой команд:

# divert on eth1 proto tcp add dst 80

# divert on eth1 enable

после чего вышеуказанные правила iptables (ipchains) работают. Для реализации такого простого решения необходимо: скомпилировать ядро с поддержкой моста (мы это уже сделали с успехом), однако если у вас старые ядра, то, возможно, вам понадобится скачать патч для вашей версии. А также необходимо скомпилировать саму программу divert-командой:

 # make

Любому заинтересовавшемуся в программе, не должно это всё показаться сложным.

Замечание1: я не использую у себя frame diverter, так как нет необходимости (следовательно, не могу гарантировать вам его работу на 100%), что же касается моста, то всё работает великолепно, если что-то не так – пишите, попробуем разобраться.

Замечание 2: если в настройках iptables не привязываться к физическим интерфейсам, то должно быть абсолютно всё равно, где у моста вход, а где выход. Иногда это удобно – не думать, как подключить. Безопасность от этого, на мой взгляд, не ухудшается.

Как заставить мост разводиться, то есть пропускать нужные нам пакеты, а ненужные выбрасывать в глубоко вырытый ров? Для этого следует настроить правила фильтрации пакетов в iptables (или ipchains для старых версий).

Очень полезным будет прочтение книги «Брандмауэры в Linux» [1]. К сожалению, в ней не говорится ничего об iptables, так что всё написанное вам придётся адаптировать самим. Теория изложена автором очень грамотно. Если вы изучите эту книгу и поймёте отличия ipchains от iptables (документы об их различии легко найти в сети), то вы без труда будете писать правила как для первого, так и для второго. Набрав в поисковой системе «Packet Filtering HOWTO: применение iptables», можно найти много ссылок, содержащих русский HOWTO:

n  http://www.3ka.mipt.ru/vlib/books/OS/Linux/howto-rus/packet-filtering-HOWTO-7.html

n  http://www.fedchik.org.ua/linux/netfilter/iptables/packet-filtering-HOWTO-7.html


Предыдущая страницаОглавлениеСледующая страница
 
[001] [002] [003] [004] [005] [006] [007] [008] [009] [010] [011] [012] [013] [014] [015] [016] [017] [018] [019] [020]
[021] [022] [023] [024] [025] [026] [027] [028] [029] [030] [031] [032] [033] [034] [035] [036] [037] [038] [039] [040]
[041] [042] [043] [044] [045] [046] [047] [048] [049] [050] [051] [052] [053] [054] [055] [056] [057] [058] [059] [060]
[061] [062] [063] [064] [065] [066] [067] [068] [069] [070] [071] [072] [073] [074] [075] [076] [077] [078] [079] [080]
[081] [082] [083] [084] [085] [086] [087] [088] [089] [090] [091] [092] [093] [094] [095] [096] [097] [098] [099] [100]
[101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120]
[121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140]
[141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155]

+7 (831) 413-63-27
ООО Дельта-Технология ©2007 - 2016 год
Нижний Новгород, ул. Дальняя, 17А.
Rambler's Top100