Предисловие

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