Сетевое администрирование в UNIX, 05 лекция (от 22 марта)

Материал из eSyr's wiki.

Есть две внутренние сети 10.1.1.1/24 на инт1 и 10.1.2.1/24 на инт2.

158.250.16.10/24 екст1 -- вы арендуете у провайдера небольшую сеть, класса це или меньше. В этом слечае он говорит -- вот у вас снешняя сеть и все внешние адреса должны находиться в ней.

158.250.11.2/24 екст2 -- вы арендуете несколько сетей, тогда пролвайдер вам выдает какую нибудь специальную большую сеть, напр, /30 и через неё выдает вам несколько сетей.

В случае если у нас один внешний и один внутр интерфейс, то всё весьма просто.Фв можеткак таковой полноценно отсутствовать. То есть у него могут не быть стейт правила. Достаточно, чтобы работал нат. Если злоумышленнник хочет попасть во внутренний мир, то он зарежжется на нат правиле, потому что соотв пары хост порт просто не будет. такомслучае фв может быть очень простым и примитивным, но для нескольких машин все что нудно он умеет. получаем всяки едлинки и иже с ними.

Соотв, у нас есть

int1 10.1.1.1/24

ext1 158.250.16.1/24 <-> 158.250.16-254

ext2 168.250.11.2/30 <-> 158.250.11.1

<= 158.250.10.0/24

Пусть есть машиа 10.1.1.10, которая хочет предоставлят внешние ресурсы. Пусть она будет

server.cs.msu.su 158.250.10.10

server.cmc.msu.ru 158.250.16.10

Мы хотим чтоб он был доступен по 2 внешним адресам.

Первое решение -- повесить тем или иным способом либо через нетфилтер сна-днат, либо через бинат внутреннний адрес на внешний.

Если мы используем pf правило будет выглядеть

binat1 on ext1 from 10.1.1.10 to any -> 158.250.16.10

binat2 on ext2 from 10.1.1.10 to any -> 158.250.10.10

Проблемы. Всё хорошо если у нас пришло на внеш адрес 158.250.10.10, который не требует арп запроса попал через нат в сеть 10.1.1.10, послал ответ и если маршр работает через того же провайдера, то все хорошо. Хуже будет, а оно будет, если запрос пошел от одного провайдера, а ответ вы посылаете через другого. Тут могут быть варианты

1. фв ничего не знает о стейт правилах. Тогда у второго проайдера он попадет на бинат и что с ним будет сложно сказать. Если ожидающая ответа машина доверится только сиквенс намберу и не обратит внимания на адрес, то все даже получится. Если же на той машине есть стейт фв, то она будет ждать пакеты с 10.10, а пакеты с 16.10 порежет.  Совсем плохо.
2. если стейт правила работают, но без привязки к маршруту. пришел пакет на 10.10, преобразовался в 1.1.10, потом обратно. В 16 ой сети возникнет пакет с адресом отправителя из 10 ой сети.Тогда их может порезать проайдер 16ой сети. Если они нормально относится к тому, что через него посылают такие пакеты, то всё даже пройдет.
3. Фв который смогли бы помнить от какого пров пакеты пришли и пихать ответы тому же прову лично лектору не знакомы. 

Что же делать если провайдеры пакеты не принимают, а стейт по маршруту мы щапомнитьь не можем.На самм деле исходящие пакеты мы можем перехватить. В случае pf у нас добавляется правило хотим пофиксить проход через первого прова пакетов которые изначально пришли от второго.

pass out on ext1 routeto(ext2 158.250.11.1) 

from 158.250.10.0/24 to any

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

Аналогичное правило для пакетов которые пойдут через первого, а должны были бы через второго.

на вмк исторически канал чрез нияф на 10 мегабит(радиомсу) и есть гигабит через гз, который с яндекса качает 30 мегабит сек. (Лежит до гз оптика, но железка на стороне вмк пока может только гигабит. В будущем потенциально замкнётся кольцо на 10 гигабит, но пока не все куски готовы).

Если у нас первый пров хочет послать на машину с адресом 16.10, она в его сети, он получает арп запрос. Что на него ответить? Один из вариантов повесить доп ип адрес на сетевую карту

class 158.250.16.10/32 . Если придет арп, он ответит потому что ип совпал. Если придет чтото выше, тцп или удп, то сработает нат. Это на интерфейсе ext1.

Итак, обеспечили мы работу.

Есть у нас 10.1.1.12. Она хочет пойти на server.cs.msu.su. Днс ей ответит адресом 10.10. Потребуется выход во внешнюю сеть.

Добавим еще пару правил

nat1: 10.1.1.0/24 -> 158.250.16.

nat2: -> 158.250.10.

Пакет пойдет так

10.1.1.12 -> nat1 -> binat2 -> 10.1.1.10

Всё будет работать. Но оба провайдера возьмут с вас за трафик(один за вход, другой за выход), да ещё и скорость порежется.

Одно из самых простых решений -- настроить днс. Если у нас днс сидит на DNS1(158.250.11.2 , 158.250.16.1) ответит

158.250.10.10,

а

DNS2(10.1.1.1) ответить 10.1.1.10

С 9 bind он научился разным ип зонам выдавать разную информацию, но никто не мешает повесить два днс сервера на внутр и на внеш интерфейсы.

Сложнее будет если наша машина 10.1.1.12 полезет по внешнему адреса. например люди которые контол наш 10 ый сервер прописали там зону например связанную с олимпиадами. То наш днс уже не сможет такое проконтролировать. Получится снова та же петля, которую надо разрешить.

Прероутинг может быть сработает, но если 12 ая машина посылала на 158 ой адрес изза прероутинга сервер его распознал и 10ая машна ответит напрямую, то получится что 10ая машина посылает запрос 158ой, а ответит ей 10ая. Можно попробовать загнать эти пакеты в нат. Если не обращать внимания на внеш провайдеров, то все равботает. Осованя идея состоит чтобы все это сэмулировать в пределах одной машины. Подозреваю если правильно написать правила то это может заработает. Пока это сделано с помощью бзд и нетграфа. Нетграф это чудесная штука которая позволяет строить свои устройства которая преобразует ип пакеты. Нат есть не только в ипфв и пы, но в нетграфе. В данном случае используюются два примитивных нетграф устройства, которые фактически создают трубу

ng1 <-> ng0

всё что попадает в нг1 напрямую вываливается из нг0. Все что попадает в нг0 напрямую ываливаетя из нг1.

Факультетский маршрутизатор без комментариев 450 строк. Наверняка можно сделать еще лучше. С линуксом для той же функциональноти скорей всего придется сделать длиннее.

Если у нас есть такое устройство как труба, мы легко можем повесить нат прямо на такой вот виртуальный интерфейс. Соотв прописать маршрут 158.250.16.10 -> ng1

Все что останет -- прописать что исходящие пакеты из 10.1.1.0 запихивать в нг0, а пакеты которые приходят на внешни

158.250.10.10 -> ng1

158.250.16.2 ->ng1

158.250.10.2 -> ng1

итак

10.1.1.12:158.250.10.10 = ng0 nat > 158.250.16.2:158.250.10.10 = ng1 binat > 158.250.16.2:10.1.1.10

Какая опасность есть? если у нас есть такая таблица маршр, а нат не поднят, то у нас получится вечный цикл.

В линуксе есть venet(опускается до сетевогоу вроня обработка пакет), veth опускается до мака, есть в опенвз.

Следующа сложность с внешним адресом. Если .12 хочет попасть на 16.10. Если мы использоали решение когда этот адрес виситалиасом на сетевом инетрф то ваш шлюз увидит. что направлен пакет на адрес который ему же и принадлежит, то у вас ничегоо не работает. Если мы направим пакет в трубу, он пройдет перобразование, н вылетев из нг1 он врезается в наш сетевой интерфейс. Так что алиас не пройдёт. Вместо arp spoof или arp proxy. Безопасней всего арп прокси.