++ Предисловие

В этом году поменяли провайдера. Выдал он нам небольшую сетку, сказал маршрутизатор по умолчанию, находящийся в этой же сети. В общем, ситуация вполне стандартная. Сразу же столкнулись с неудобствами такого подключения, которых не было при подключении к старому провайдеру по 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.dev/tips/info/3005.shtml