The OpenNET Project / Index page

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

Прозрачный межсетевой экран с маршрутизатором
Предисловие

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

  • Все хосты с "белыми" адресами должны обзавестись собственными межсетевыми экранами.
  • Маршрутизация превращается либо в динамическую (что то ещё удовольствие), либо в прописывании её на всех "белых" хостах. Быстрые и неправильные решения Данные проблемы можно попытаться решить наскоком, и что может ложно успокоить, "всё будет работать". Поменяв маршрут по умолчанию на белых хостах на собственный маршрутизатор создастся видимость, что всё починилось: маршрутизация до филиалов и серых сетей появилась, а межсетевой экран даже сможет срабатывать на выход. Но кому более всего нужен межсетевой экран на выход? Вот то-то же. Да и с маршрутизацией не всё на самом деле в порядке. На каждый посланный вами из белой сети в Интернет пакет, вы будете получать 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-уровня, другие действия нужны к ну уж очень занятны и нетипичным конфигурациям, типа кластеров и др.
  •  
    07.02.2017 , Автор: Владимир Олейник , Источник: http://www.simtreas.ru/~dzo/brouter...
    Раздел:    Корень / Администратору / Сетевая подсистема, маршрутизация / Пакетные фильтры и фаерволы / Пакетные фильтры в Linux: iptables, ipchains

    Обсуждение [ RSS ]
  • 1.1, GreyWolf (??), 16:47, 13/02/2017 [ответить]  
  • +/
    Полезная статья.
     
  • 1.2, Romik (??), 20:29, 15/02/2017 [ответить]  
  • +/
    Раз уж роутер не под вашим управлением, то я бы повесил все белые адреса на одну машину (с тем же linux), и сделал бы One 2 one NAT на серые адреса. Linux машина была бы шлюзом по-умолчанию для всех во внутренней сети.
     
     
  • 2.3, vodz (ok), 10:43, 16/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Это тоже одно из нормальных решений, но нам не подходит по причине того, что у нас приличное количество клиентов, но мало того, они ВСЕ подключаются как штык в 8:00, такова специфика работы. VPN-ы начинают тормозить и глючить. Всё же NAT и мост несравнимы по потребляемым ресурсам, а тот же DNS не надо сплитовать для нормальной отдачи инетного домена.
     
     
  • 3.4, sabakka (?), 19:16, 17/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    1:1 NAT не пожрёт ресурсов, в линк упрётесь.
     

  • 1.5, vodz (ok), 20:31, 17/02/2017 [ответить]  
  • +/
    1:1 NAT не жрет ресурсов по портам, но это всё равно через CPU. Ведь дело в том, что это не абстрактные рассуждения, глаголы в будущем времени неуместны. Работаем же, беремся с глюками.
     
  • 1.6, dry (ok), 21:48, 28/02/2017 [ответить]  
  • +1 +/
    Высосаная из пальца (или из другого места) проблема. Имеем 3 практически идентичные конфигурации, никаких проблем нет. Приземляете все белые адреса на своем маршрутизатора/МЭ, дальше static nat + filtering или pat пробрасываете что куда надо.
     
  • 1.7, DmA (??), 01:14, 03/03/2017 [ответить]  
  • +1 +/
    прям стелс-фареволл ССПТ, который так часто рекламируют на этом сайте по минимальной цене, а не за 100 тысяч рублей :)
     
  • 1.8, АноНимус (?), 11:09, 10/03/2017 [ответить]  
  • +/
    Решение - идиотское. Отговорка про нехватку ресурсов для НАТа из-зп большого количества клиентов - еще более идиотская. Или я неправильно понял и клиентов у вас десятки тысяч. а каналы - в десятках гигабит?

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

     
  • 1.9, Sergey Zhilkin (?), 21:12, 11/03/2017 [ответить]  
  • +/
    Круто в УФК по Ульяновской области "живут" раз такие замахи :) Совершенно не понятно зачем вам VPN с маршрутизаторов. Если есть крипто-шлюзы. Я конечно подозреваю - что всё сделано согласно рекомендаций методичек. Но это костыли :(
     
     
  • 2.10, vodz (ok), 12:44, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > что всё сделано согласно рекомендаций методичек. Но это костыли

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




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

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