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...
    Ключи: ebtables, iptables, route, linux, firewall / Лицензия: CC-BY
    Раздел:    Корень / Администратору / Сетевая подсистема, маршрутизация / Пакетные фильтры и фаерволы / Пакетные фильтры в Linux: iptables, ipchains

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

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




      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor TopList