Обмен маршрутами между NAS

[Kiano 616]

Прошу помощи, камрады

 

Ситуация такова:

Есть много NAS-ов на базе зоопарка, от routeros до линуха и разных извращений.

Но сейчас о первых, на базе RouterOS. В свою очередь NAT - это сервачок, на том же нелюбимом RouterOS, который тупо натит и роутит.

 

На NAS-ах: авторизация по PPPoE, обычный роутинг, без NATа, NAS не имеет дефолт роута, абоны маркируются mangle-ом и роутятся на NAT, а дальше в интернеты.

Абонент с деньгами получает всегда один и тот же серый/белый IP, на NATе статик роуты на подсеть (для каждого NASа своя подсеть), всё в порядке.

Абонент без денег получает КАЖДЫЙ РАЗ новый серый адрес из подсети с маской /21, а NAT уже в душе не е*ёт, какой IP на какой NAS роутить, вот здесь пи*дец и наступает.

Т.е. сейчас абон получил IP 172.30.1.1 на одном NASе, через час ребутнул свою железку, получил тут же IP 172.30.123.123, а 172.30.1.1 например, получил уже совсем другой абон, на совсем другом NASе. Итого, эдакая динамика.

 

Сейчас решил через задницу (как по мне), но оно работает.

Каждый NAS все ноумани IP роутит по отдельному маршруту на NAT, у каждого NASа свой влан, своя подсеточка для обмена с NATом, в свою очередь NAT добавляет в отдельный address list все src которые пришли с каждого влана, а обратный трафик исходя dst засылает на нужный NAS. Сами address list-ы динамические, т.е. новая запись появляется там только тогда, когда абон без денег пытается куда-то ломиться. Таймаут 30сек (или около того) и всё.

Повторюсь, в принципе, всё работает, но через ж#пу. Если запросов от абона не было - то NAT снова же в душе не е*ёт, где тот абон и с каким он ипом сейчас.

 

ЗАЧЕМ ЭТО НУЖНО:

Чтобы дать возможность абонам без денег зайти в личный кабинет, пополнить счёт через приватики и прочую фигню, чтобы сайтик компании был доступен и прочие whitelist.

 

Что хочется:

Чтобы NASы волшебным образом обменивались с NATом маршрутами, чтобы NAT знал от NASa какие на нём сейчас абоны с ипами из диапазона /21.

 

Что подскажете?

[VitalyMoiseev 112]

rip

ospf

[Kiano 616]

25 минут назад, VitalyMoiseev сказал:

rip

ospf

похоже на то, что нужно. спасибо, попробую

[l1ght 377]

3 минуты назад, Kiano сказал:

похоже на то, что нужно. спасибо, попробую

лучше iBGP

вон тема была сегодня ж буквально

[Kiano 616]

Только что, l1ght сказал:

лучше iBGP

вон тема была сегодня ж буквально

можно ссылку пжл

[l1ght 377]

5 минут назад, Kiano сказал:

можно ссылку пжл

 

[Kiano 616]

Только что, l1ght сказал:

 

ага, видел, спасибо

[Kiano 616]

пока сделал RIP+Filters, как работает - устраивает.

Большое спасибо за советы.

Если кто в теме - подскажите как на оспф это реализуется

[Dimkers 1 602]

Уйти от микротов. Смотрите в сторону акселя. Там на Л4 левеле можно абонов заворачивать куда угодно(по ридеректу порта). Это архиудобно. Абону вываливает его же ИП в любом случае, кроме случая, когда абон неизвестен(только тогда -гостевой). 

И да. ОСПФ - зло, т.к. линкстейт. Так что либо иБГП, либо РИП.2.

Відредаговано 2019-02-18 18:23:54 Dimkers

[NiTr0 584]

10 минут назад, Dimkers сказал:

ОСПФ - зло, т.к. линкстейт

проблема не в том что линкстейт. проблема - в том, что он имеет свойство терять роуты (то ли дропы пакетов, то ли еще какая причина), и нет никаких механизмов синхронизации таблиц маршрутов узлов. т.е. потерялся маршрут - и с концами...

[l1ght 377]

1 час назад, NiTr0 сказал:

проблема не в том что линкстейт. проблема - в том, что он имеет свойство терять роуты (то ли дропы пакетов, то ли еще какая причина), и нет никаких механизмов синхронизации таблиц маршрутов узлов. т.е. потерялся маршрут - и с концами...

теряет роуты на моей памяти только квагга и микротики (думаю что там тоже квагга)

вообще оспф не плох, но точно не для кучи \32 очень часто меняющихся

[Dimkers 1 602]

1 час назад, NiTr0 сказал:

проблема не в том что линкстейт.

и в этом тоже. Куда там апдейты(и нет только) летают при любом чихе? На мультикаст?

Відредаговано 2019-02-18 19:57:14 Dimkers

[l1ght 377]

1 час назад, Dimkers сказал:

и в этом тоже. Куда там апдейты(и нет только) летают при любом чихе? На мультикаст?

у оспф нет апдейтов (до OSPFv3), есть лса флуд

и там может быть юникаст, мультик там что бы соседство динамическое было

[Dimkers 1 602]

Точно.

[NiTr0 584]

1 час назад, l1ght сказал:

теряет роуты на моей памяти только квагга и микротики (думаю что там тоже квагга)

птичка редко, но тоже теряет.

[KaYot 3 711]

2 часа назад, l1ght сказал:

теряет роуты на моей памяти только квагга и микротики (думаю что там тоже квагга)

Квагга перестает терять маршруты после минимальной настройки.

https://forum.nag.ru/index.php?/topic/119373-quagga-zebra/&tab=comments#comment-1493007

[Kiano 616]

у рип тоже может быть юникаст, оказывается.

а как через ibgp тогда?

[l1ght 377]

3 часа назад, Kiano сказал:

у рип тоже может быть юникаст, оказывается.

а как через ibgp тогда?

что "как?" ?

бгп тоже умеет в юникаст\мультикаст

Відредаговано 2019-02-19 08:22:36 l1ght

[Kiano 616]

спасибо всем, решение - через RIP. Понял, почему не сработало раньше и забил на эту тему - фильтровался мультикаст на уровне провайдера-транспорта, нихера не работало, вот и забил. В этот раз вник, вкурил, что это работает и по юникасту, теперь всё ок.

 

Для будущего "поколения" или для других юзернеймов, кому будет эта идея интересна.

На базе микротика это решил так:

1) На главном роутере, который будет получать маршруты от других, Routing -> RIP, добавляем в Interface новую запись.

Interface: тот интерфейс, на котором будем слушать инфу о маршрутах с других роутеров

Receive/Send: v2 (юзаем вторую версию протокола)

Authentication: none (не буду вдаваться в опции авторизации, кому интересно - разберется сам)

Passive - ставим галочку, т.к. этот роутер будет только слушать маршруты;

Neighbours - здесь добавляем ипы роутеров, с которых будем слушать маршруты;

2) На остальных роутерах, которые будут отправлять инфу о маршрутах, Routing -> RIP, добавляем в Interface новую запись.

Всё тоже самое, что и на главном, кроме галочки Passive, она не нужна.

На той же вкладке правее RIP Settings - здесь вверху never, т.к. нам не нужно ничего делать с дефолтным маршрутом

Ниже указываем какие маршруты будем отправлять (статические, оспф, бгп, кому что нужно, мне например - connected нужны были)

Далее идем в Neighbours, добавляем запись с ипом, куда будем слать инфу о маршрутах. Это как оказалось, ключевой момент, который определяет, что инфу нужно юникастом слать на определенный адрес (routeros wiki).

Теперь самое интересное. Если не задать что конкретно, то роутер будет отдавать инфу о всех подряд своих маршрутах, зачастую это нафиг не нужно, потому идем в RIP->Filters.

Добавляем новое правило, в chain указываем rip-out, а в action указываем reject. Это правило должно быть в итоге в самом конце, по окончанию настройки.

Снова добавляем правило, где в chain rip-out, prefix - указываем маску подсети для маршрутов, которые будем отправлять, ниже - длину маски, (можно указать диапазон, например 16-32, кому что нужно). В action - accept. Напомню, первое правило что мы создали должно быть последним в списке.

Такой подход мне понравился больше, чем фильтровать на входе всё подряд, а роутеры будут отправлять всё подряд. Лучше отправлять то, что полезно, а на входе вообще не фильтровать. Но это уже тонкости настройки.

 

Собственно всё. Описал своими словами, по памяти, для "чайников", иногда это нужно для общего понимания картины.

Відредаговано 2019-02-19 21:13:28 Kiano