The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка  RSS
"Раздел полезных советов: Прозрачный межсетевой экран с маршр..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Прозрачный межсетевой экран с маршр..."  +/
Сообщение от auto_tips (??) on 13-Фев-17, 16:47 
++ Предисловие

В этом году поменяли провайдера. Выдал он нам небольшую сетку, сказал маршрутизатор по умолчанию, находящийся в этой же сети. В общем, ситуация вполне стандартная. Сразу же столкнулись с неудобствами такого подключения, которых не было при подключении к старому провайдеру по pppoe, ведь теперь маршрутизатор не под нашим управлением:

** Все хосты с "белыми" адресами должны обзавестись собственными межсетевыми экранами.
** Маршрутизация превращается либо в динамическую (что то ещё удовольствие), либо в прописывании её на всех "белых" хостах.


[[IMG /opennews/pics_base/0_1486964773.png]]


++ Быстрые и неправильные решения

Данные проблемы можно попытаться решить наскоком, и что может ложно успокоить, "всё будет работать". Поменяв маршрут по умолчанию на белых хостах на собственный маршрутизатор создастся видимость, что всё починилось: маршрутизация до филиалов и серых сетей появилась, а межсетевой экран даже сможет срабатывать на выход. Но кому более всего нужен межсетевой экран на выход? Вот то-то же. Да и с маршрутизацией не всё на самом деле в порядке.

На каждый посланный вами из белой сети в Интернет пакет, вы будете получать ICMP redirect, говорящий, что маршрутизатор вами установлен не тот:

   PING branch.mydomain.ru (branch-IP): 56 data bytes
   From GW-IP Redirect (change route)
   84 bytes from branch-IP: icmp_seq=0 ttl=63 time=N ms

Windows машины, у которых по умолчанию применяется политика реагирования на этот код, будут бесконечно добавлять в таблицу маршрутизации записи на каждый хост в Интернете через маршрутизатор провайдера.

Хорошо, а давайте добавим все статические маршруты, а между провайдерским и своим коммутатором поставим прозрачный файервол. Ну что ж, это решение будет работать пока вам не надоест возиться с маршрутизацией и не возникнет мысль, что может сделаем управляющий интерфейс прозрачного файервола в белой сети и он и будет центральным маршрутизатором. Увы, как только вы это сделаете, всё вернётся к проблеме, описанной ранее.


++ Правильное решение

Из предыдущей главы стало понятно, что нам нужно:

** прозрачный файервол;
** управляющий интерфейс этого файервола сделать внешним для возможности включения туннелей для филиалов и домашних пользователей через Интернет;
** озаботиться хорошей фильтрацией от атак и для него, подконфигурив файрвол;
** выключить redirect;
** сконфигурить все VPN-ы либо на этом хосте, либо прописать маршрут на хосте с прозрачным файерволом - центральным маршрутизатором до сервера VPN.

Как ни странно, но в сети можно найти решение как это сделать, но это решение предлагается как совершенно странный нетипичный пример сети с запутанными условиями "из реальной жизни", совсем не похожей на рассматриваемый пример типичного подключения.

Как это делается в других ОС, отличных от Linux оставим на самостоятельный поиск читателю, а для Linux эта строчка выглядит вот так и немного странно:

   ebtables -t broute -A BROUTING -i eth-in -p ipv4 -j redirect --redirect-target DROP

Где eth-in - входящий интерфейс со стороны вашей остальной сети.

Тот, кто уже имел дела с конфигурацией файервола на Linux, взглянув на эту строчку скажет, что мы запретили совсем необходимый переброс пакета со входящего интерфейса на выход. Да, именно так. Дело в том, что ebtables имеет много точек разветвления, запрещая одно ветвление, мы заставляем пермещать пакет в другое, если политика по умолчанию или следующие правила это не запрещают. В данном случае пакет покинет L2-уровень, за который ответсвеннен ebtables и мост, а пойдёт на L3-уровень в маршрутизацию и iptables. Посмотрите на примеры использования ebtables, вы там в большинстве случаев найдёте именно правила с DROP. Такова уж судьба у L2-уровня, другие действия нужны к ну уж очень занятны и нетипичным конфигурациям, типа кластеров и др.


URL: http://www.simtreas.ru/~dzo/brouter/
Обсуждается: http://www.opennet.me/tips/info/3005.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Прозрачный межсетевой экран с маршрутизатором"  +/
Сообщение от GreyWolf (??) on 13-Фев-17, 16:47 
Полезная статья.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Прозрачный межсетевой экран с маршрутизатором"  +/
Сообщение от Romik (??) on 15-Фев-17, 20:29 
Раз уж роутер не под вашим управлением, то я бы повесил все белые адреса на одну машину (с тем же linux), и сделал бы One 2 one NAT на серые адреса. Linux машина была бы шлюзом по-умолчанию для всех во внутренней сети.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Прозрачный межсетевой экран с маршрутизатором"  +/
Сообщение от vodz (ok) on 16-Фев-17, 10:43 
Это тоже одно из нормальных решений, но нам не подходит по причине того, что у нас приличное количество клиентов, но мало того, они ВСЕ подключаются как штык в 8:00, такова специфика работы. VPN-ы начинают тормозить и глючить. Всё же NAT и мост несравнимы по потребляемым ресурсам, а тот же DNS не надо сплитовать для нормальной отдачи инетного домена.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Прозрачный межсетевой экран с маршрутизатором"  +/
Сообщение от sabakka on 17-Фев-17, 19:16 
1:1 NAT не пожрёт ресурсов, в линк упрётесь.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Прозрачный межсетевой экран с маршрутизатором"  +/
Сообщение от vodz email(ok) on 17-Фев-17, 20:31 
1:1 NAT не жрет ресурсов по портам, но это всё равно через CPU. Ведь дело в том, что это не абстрактные рассуждения, глаголы в будущем времени неуместны. Работаем же, беремся с глюками.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Прозрачный межсетевой экран с маршрутизатором"  +1 +/
Сообщение от dry email(ok) on 28-Фев-17, 21:48 
Высосаная из пальца (или из другого места) проблема. Имеем 3 практически идентичные конфигурации, никаких проблем нет. Приземляете все белые адреса на своем маршрутизатора/МЭ, дальше static nat + filtering или pat пробрасываете что куда надо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Прозрачный межсетевой экран с маршрутизатором"  +1 +/
Сообщение от DmA (??) on 03-Мрт-17, 01:14 
прям стелс-фареволл ССПТ, который так часто рекламируют на этом сайте по минимальной цене, а не за 100 тысяч рублей :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Прозрачный межсетевой экран с маршрутизатором"  +/
Сообщение от АноНимус on 10-Мрт-17, 11:09 
Решение - идиотское. Отговорка про нехватку ресурсов для НАТа из-зп большого количества клиентов - еще более идиотская. Или я неправильно понял и клиентов у вас десятки тысяч. а каналы - в десятках гигабит?

Как уже говорили выше - правильное решение это свой маршрутизатор (а лучше UTM) на которой и приземлена белая сетка.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Прозрачный межсетевой экран с маршрутизатором"  +/
Сообщение от Sergey Zhilkin email on 11-Мрт-17, 21:12 
Круто в УФК по Ульяновской области "живут" раз такие замахи :) Совершенно не понятно зачем вам VPN с маршрутизаторов. Если есть крипто-шлюзы. Я конечно подозреваю - что всё сделано согласно рекомендаций методичек. Но это костыли :(
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Прозрачный межсетевой экран с маршрутизатором"  +/
Сообщение от vodz (ok) on 16-Мрт-17, 12:44 
> что всё сделано согласно рекомендаций методичек. Но это костыли

Какие методички? С каких пор VPN-ы стали костылями? Типичный рунет, зудит сказать какую-нибудь гадость, а сказать нечего, вот и получается бред.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру