LINUX.ORG.RU
решено ФорумAdmin

Динамическая маршрутизация

 , , , ,


0

3

Всем привет.

Имеется, для простоты, 3 сервера.

1: border-сервер; получает по BGP full-view от вышестоящего провайдера и по OSPF раздает другим двум (access servers) дефолтный маршрут, а также готов принимать от них маршруты.

2,3: сервера доступа; с них пакет уходит по дефолтному маршруту на принятый по OSPF от border'а. На них стоит PPTP, а при подключении к нему на border-сервер анонсируется маршрут с маской /32, чтобы пакет дошел обратно до клиента.

Эта схема отлично.

В нее нужно добавить 4-ый сервер, через который бы проходили некоторые сети. OSPF здесь сразу отпадывает, ибо на зоны не поделить (слишком мало серверов, все друг другу соседи), а без зон у всех серверов одинаковые таблицы маршрутизации, и пакет напрямую пойдет в border, как бы мы не старались. Поэтому на AS-ках были подняты BGP, которые принимают маршруты с этого 4-го сервера.

В итоге если туда анонисировать какую-нибудь сеть, то с AS пакет пойдет не по дефолтному маршруту до border-сервера, а по bgp-шному до 4-го сервера, откуда уже по дефолтному уйдет на border-сервер. А обратно возвратится другим путем: напрямую от border'а до AS, т.к., как я говорил в начале, туда по OSPF анонсируются маршруты поключившихся клиентов.

И эта схема тоже работает отлично!

Но тут ВНЕЗАПНО потребовалось установить squid+tproxy на этот 4-ый сервер, которому просто жизненно необходимо, чтобы пакет вернулся обратно.

Собственно, вопрос: как сделать так, чтобы пакет возвращался обратно?

У меня есть идея анонсировать на этот 4-ый сервер по OSPF те же маршруты, что и на border. А на border-сервере каким-то образом сделать так, чтобы пакет уходил (уже входящий для border'а) туда, откуда пришел. Пока что не очень понимаю, как это можно сделать. В какую сторону копать?

Еще раз на всякий случай поясню.

Идет транзитный пакет через border-сервер, приходит на него ответ, который проходит по маршруту типа x.x.x.x/32 в таблице маршрутизации. Нужно, чтобы так и было, но при этом, например, если транзитный пакет пришел от такого-то ip/iface, то ответ отправить на тот же роутер, не взирая на x.x.x.x/32.

Пока что нет идей как сделать так. Всякие NAT'ы и т.п. на 4-ом сервере - не решение. Наоборот, от них пытаемся уйти.

Linux, quagga.


Появилась идея использовать connmark.

Маркировать исходящие соединения с интерфейса/адреса 4-го сервера. Принятые соединения с connmark маркировать mark'ом (если нужно) и ip rule ... в таблицу маршрутизации для 4-го сервера..

Попробую потестить это.

fillo
() автор топика

Что-то много написано, но мало, что понятно. Нарисуй лучше.
Что значит «нужно добавить 4-ый сервер, через который бы проходили некоторые сети» ?

а по bgp-шному

Это совсем не понял. BGP же на бордере только, а остальное же OSPF ?

AS ★★★★★
()
Ответ на: комментарий от AS

http://imageshack.us/photo/my-images/580/ayll.jpg/

Вот как-то так. Не стал рисовать культурно в Gia или еще где, на коленке.

Вот border получает по BGP от провайдеров full-view. С AS'ками связан по OSPF. Они ему там анонсируют IP-адреса клиентов, а он им - default gw.

А четвертый сервер с AS'ками связан по BGP, чтобы пропихнуть к ним некоторые сети (допустим, x.x.x.x/32 какой-нибудь) и чтобы они пошли через 4-ый сервер, где с этим трафиком будет что-нибудь производиться. В моем случае нужен squid/tproxy.

Так вот пакеты, прошедшие через 4-ый сервер, обратно вернутся напрямую с border'а до AS. И это нормально. А нужно (для работы tproxy), чтобы вернулись на 4-ый.

Выше я написал про connmark, и это будет работать, но уж как-то костыльно на border'е такое замутить.

p.s. Почему 4-ый сервер связан по BGP, думаю, понятно: OSPF просто не позволил бы трафику так пойти, все бы ушло напрямую в border, минуя 4-ый сервер.

fillo
() автор топика
Ответ на: комментарий от fillo

В моем случае нужен squid/tproxy

Так пакет уйдет в мир с адреса сквида, а значит и вернется обратно, ибо прокси директом виден бордеру. Разве нет?

baka-kun ★★★★★
()
Последнее исправление: baka-kun (всего исправлений: 1)
Ответ на: комментарий от baka-kun

Да, именно так. Поэтому и придумали люди такую штуку - TPROXY. http://wiki.squid-cache.org/Features/Tproxy4

В итоге пакет в мир уйдет с адреса клиента, вот такое тру проксирование.

Сейчас именно так и работает - светится адрес сквида, что не круто, так не надо. Надо, чтобы был прокси и чтобы этого не было. TPROXY уже работает, однако ему нужно, чтобы пакет обязательно назад вернулся, иначе оно работать не может. Такова суть проксирования.

fillo
() автор топика
Ответ на: комментарий от fillo

Поэтому и придумали люди такую штуку - TPROXY.

Я знаю, что такое tproxy. Но если бордер не циска с WCCP, то единственный способ использовать не транзитный, а стоящий рядом прокси ты уже упомянул: вести стейтфул записи, маркировать флоу от прокси, редиректить ответные пакеты.

Делать придется на бордере, больше негде.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Эх, да, видимо, да.

А может есть какая-то инфа насчет линуксового connmark? Ссылки на тесты, как он по ресурсам? Или из личного?

fillo
() автор топика
Ответ на: комментарий от fillo

p.s. Почему 4-ый сервер связан по BGP, думаю, понятно: OSPF просто
не позволил бы трафику так пойти, все бы ушло напрямую в border,
минуя 4-ый сервер.

Можно параметром ip ospf cost скорректировать вес маршрута между бордером и AS1/AS2 так, чтобы маршруты через сервер N4 были лучшими. Но вот если вопрос в том, чтобы не каждого клиента так выпускать... А если Linux везде, может, на каждом AS свой tproxy сделать ?

AS ★★★★★
()
Ответ на: комментарий от AS

Можно параметром ip ospf cost скорректировать вес маршрута между бордером и AS1/AS2 так, чтобы маршруты через сервер N4 были лучшими. Но вот если вопрос в том, чтобы не каждого клиента так выпускать...

Логично, потестирую. Как-то в эту сторону не думал. Насчет клиентов такой проблемы нет.

А если Linux везде, может, на каждом AS свой tproxy сделать ?

Не вариант. Во-первых, хочется централизованности, а во-вторых, там 2.6.18 xen, в итоге патч от Balabit не встанет, а обновить ядро - нереально, ибо паравиртуализация. С N4 была та же проблема, так и не обновил там ядро - не хотело запускаться, разного рода kernel panic, связанные с памятью. Делал все и по мануалу и сам собирал с нуля и чего только не пытался. В итоге там теперь HVM. Плюс еще CentOS, где пришлось пересобрать iptables/iproute, т.к. по дефолту в 6.4 стоит 1.4.7 iptables, в доках по TPROXY советуют от 1.4.10. Ну и ядро тоже обновил. Все, конечно, в пакетах, но делать то же самое на AS'ках - не-не. Лучше уж connmark/mark на бордере.

fillo
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.