Natd и Routed(Gated)

[Serega]

Есть несколько внешних интерфейсов с одной стороны и локальная сеть с другой
Нужно поднять NAT на всех внешних интерфейсах
и настронить маршрутизацию так, что бы нагрузка на них распределялась равномерно (или хотябы если падает один то трафик идет по другому интерфейсу)

С маршрутизацией хотябы ясно куда копать (думаю настроить OSPF)

А вот как заставить natd работать на нескольких внешних интерфейсах ?

[RXL]

Serega, сомневаюсь, что тебе нужны такие премудрости, да и врятли они тебе помогут. Как я понимаю, у тебя просто N провайдеров и каждый выделяет тебе IP адреса, а в локалке адреса типа 192.168, 172.16..172.31 или 10.  Если я не прав - скажи.
Куча вопросов:
1) какая ОС, версия? (помоч смогу только по Linux-у)
2) Внешние адреса у тебя есть на каждого клиента в локалке, или один на всех? Вопрос этот о каждом интерфейсе.
3) Будут ли входящие соединения, или только исходящие (без серверов)?

[Serega]

Есть 3-5 VPN подключений к провайдеру, у каждого лимит по траффику
Есть 20-30 внутренних VPN подключений тоже с лимитами

с натом я разобрался, а вот с нагрузкой на внешние интерфейсы пока нет
я вижу два варианта:

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

2. распределять траффик по всем интерфейсам чтобы избежать наступления лимита


ось у меня FreeBSD 5.2.1 но это не столь важно, у меня есть поддержка Linux
в локалке все адреса внутренние
соединения только исходящие

[RXL]

Serega, сделать распределение просто так нельзя - каждому провайдеру надо слать пакеты только с source IP из выделенных им адресов. Т.е., соединения TCP, а так же связанные серии UDP пакетов надо слать и принимать только с одного IP в течении соединения. Просто так переключить проброс трафика на другой интерфейс нельзя - порвутся все текущие соединения.

Мне видится логика работы следующая (то, что надо в итоге получить): при подходе (но не по достижении) к лимиту, суметь каким-то макаром (я не в курсе сетевых возможностей FreeBSD) направлять уже существующие соединения в старый интерфейс, а новые в другой. Выдержать так какое-то время, или до полного истечения лимита на старом интерфейсе, или до того момента, когда трафик за некий период (напр. 5 минут) не будет равен нулю, и отключить (если надо старый интерфейс), либо просто направить весь трафик в новый.
С VoIP труднее - трафик там в основном UDP, но что делать...
в общем, задачка не из легких.
Простейшее решение: при подходе к лимиту поднять новый интерфейс заранее и в некий момент просто переключить маршрут. Конечно, все текущие соединения посыпятся, но новые пойдут сразу.

[vasyav]

Я сам непробовал, где-то читал есть такая фишка лоад балансинг. Смотри в сторону www.zebra.org.

[RXL]

vasyav, при различных IP на разных каналах балансировка нагрузки работать не будет.

[Serega]

vasyav, щас какраз квагу и изучаю, это продолжение зебры

RXL, балансировку думаю делать на уровне соединений, иначе действительно не получится, и просто ронять интерфейс при достижении лимита
Если использовать одновременно лишь одно соединение то менять их придется часто, лимит 20Mb, а значит у пользователей часто будет падать инет, а это плохо так как разрыв соединения может оказаться очень не к стати в телефонии и играх

[vasyav]

Спросил у админа. Посоветовал почитать RFC по протоколам динамической маршрутизации. Там есть на этот вопрос ответ.

[RXL]

vasyav, протоколы маршрутизации занимаются распростронение информации о маршрутах, а если информация с твоего компьютера другим нафиг не нужна (не поддерживают, или отвергают), то это пустой труд.

[vasyav]

Прочто про стоимость маршрутов. RTFM

[Serega]

Дай линк на этот FM

[vasyav]

google.com.ua : rfc bgp rip

[Serega]

тока rfc это писец, я за..сь его читать =)

[RXL]

Я уж думал более не напоминать, но видимо стоит. RFC вешь полезная, но более полезно знать более простые вещи. И так, повторяю: никакой пользы от rip, bgp и прочих подобных протоколов в данной ситуации не будет!
Давайте разберем некоторые вопросы.

Что мы имеем?
Роутер, который может иметь несколько каналов для маршрута default и делает nat для исходящих соединений.

Что есть vpn соединение?
Это ppp сессия поверх некого канала.

Как работает nat?
Есть следующие варианты работы: статичный и с отслеживанием последовательности пакетов. Статичный работает просто: срабатывает некое правило трансляции и ip заменяется на другой. Этот метод годится только для трансляции 1:1 . Метод с отслеживанием последовательности пакетов позволяет по некому правилу трансляции транслировать пару ip+port (причем как src так и dst) для первого пакета из последовательности, а потом обнаруживать другие пакеты последовательности и применять к ним то же самое правило трансляции. Это означает, что правило для последовательности задается только один раз и поменять его нельзя. Да и не нужно менять - это да же вредно.

Что произойдет, если мы сделаем балансировку _исходящего_ трафика на несколько ppp каналов, подключенных к _одному_ провайдеру?
Фигня получится. Для multilink ppp и балансировки должны быть одинаково сконфигурены обе стороны.
Рассмотрим случай работы tcp-подключения. Причем возможны варианты:
1) провайдер принимает пакеты с любым src_ip с любого интерфейса (любой ppp сессии), а входящие пакеты направляет только в один, соответствующий dst_ip (согласно таблице маршрутизации), интерфейс. Итог: никакой балансировки по входящему трафику нет - только по исходящему, а т.к. лимит ставится, обычно, на входящий, то получаем фигню.
2) провайдер принимает пакеты только с src_ip, выданым клиенту при подключении. Некоректно направленные исходящие он будет отбрасывать, а входящие, опять же, будет кидать только в соотв. dst_ip интерфейс. Опять фигня получилась.

Что будет, если мы запустим rip и будем сообщать провайдеру о наших маршрутах?
Посути, ничего не будет, да же если провайдер будет принимать наши rip-сообщения. о каких таких маршрутах мы будем сообщать? - только о default и о локальной сетке. Сам провайдер то нам ничего о своих маршрутах сообщать не будет - нафиг ему это надо? Так какой смысл городить rip?

Что будет, если мы запустим bgp, ospf или подобный протокол?
Ничего не будет. Такие протоколы предназначены для работы на стыках сети, имеющей несколько стыков с _разными_ сетями. Кроме того, как правило, обмен между роутерами идет на доверительной основе - чужому тут не место.

Так что же спасло бы нас? Статичный ip, независимый от интерфейсов! Но это опять же возможно только при поддержке провайдера - он должен прописать у себя маршрут для ip на все соединения с нашим роутером. Тогда, при пропадании любого из этих интерфейсов, трафик автоматом пойдет по другому.

[Serega]

Не нужны никакие протоколы маршрутизации, комп работает автономно, и никому ничего сообщать не станет

Проблема такая:
есть несколько ppp соединений с провайдером, у каждого свой IP и никаких извратов с маршрутизацией провайдер делать не станет

Нужно чтобы эти соединеия использовались одновременно

Нашел в ipnat возможность сделать round robbin, в примере делается балансировка входящих соединений, не знаю возможно ли сделать то же с исходящими

В принципе можно сделать чтобы интерфейсы использовались по очереди, но лучше одновременно

[Dimka]

Вот я всё выше читаю и перечитываю давно, и терзают меня смутные сомнения. У меня почему-то сильное ощущение, что сессия не зависит от маршрута пакетов. По крайней мере это разные уровни сетевой организации. Смущает лишь VPN (это уточню). Так что циклическая смена default маршрута по всем провайдерам не должна рвать сессии в случае общего IP.

Нельзя ли иметь некий внутренний IP-адрес (но не локальной сети, а Internet), стоящий за всеми адресами провайдеров? Тогда сессия между двумя IP (внешним и эти общим внутренним) будет установлена, а маршрут будет выбираться произвольный (по алгоритму балансировки). Если один из провайдеров предоставляет статический IP, то всю работу вести через него, а default-маршрут задавать поочерёдно на каждый из внешних интерфейсов, убирая из маршрута все остальные внешние интерфейсы. Проблема лишь в разрыве соединения с провайдером для общего для сессий IP, тогда адрес сбросится, все соединения порвутся. Можно его будет восстановить не на ppp интерфейсе, а на eth и держать, пока не восстановится ppp, вместе с тем исключив его из списка перебираемых default-маршрутов до восстановления ppp.

Надеюсь, понятно выразился... Сам до конца ещё не уверен в жизнеспособности подхода...  

[RXL]

Вот я всё выше читаю и перечитываю давно, и терзают меня смутные сомнения. У меня почему-то сильное ощущение, что сессия не зависит от маршрута пакетов. По крайней мере это разные уровни сетевой организации. Смущает лишь VPN (это уточню). Так что циклическая смена default маршрута по всем провайдерам не должна рвать сессии в случае общего IP.

dimka, Serega,  пакеты, к сожалению. двигаются не в одном направлении, и по этому как на своей строне не крути, а, т.к. учет идет по входящему трафику, никакой равномерности не будет. RR не поможет.

dimka, задать одинаковые IP на все PPP сессии в принципе можно (конечно зависит от системы и правил работы провайдера), но сомнительно практически (в смысле того, что пров это разрешит). Я это делал на Linux-е - в этой ОС можно иметь несколько одинаковых маршрутов - входящий трафик идет с обеих интерфейсов, а исходящий только в первый по расположению в памяти (при прочих одинаковых парметрах).

Эх, мужики, с вами видно хорошо пиво пить - за такой дисскусией можно ящик усидеть

[Dimka]

http://klug.org.ua/advt/detail.php?cat=54&de=2

во второй половине статьи, случаем, не искомое решение описано?

для VPN использовать предложенный метод: 1 внешний IP в качестве source, а остальные лишь как маршрутизаторы для него;

[vasyav]

RXL: Если посчитать сначала. То задача не стояла равномерно использовать лимит от провайдера, а использовать одновременно имеющиеся каналы.

Читай поставленный вопрос. Об учете трафика не чего сказано не было. Поэтом я и придложил использовать лоад балансинг через динамическую маршрутизацию. Причем необязательно отдавать маршруты провайдерам.

[RXL]

vasyav, я тему уж не раз перечитывал, и не в учете дело, а в лимите. О провайдерах читай опять же выше. У провайдера одна забота - чтобы клиент бабки платил, а навороты делать ему выгоды ни какой.

[Serega]

RXL, провайдер дейстительно ничего делать не станет, ему нужны только бабки, поэтому и приходится крутиться самому

RR действительно далеко не идеальное решение, но все же лучше чем ничего

dimka, решение описаное в статье и есть round-robbin
только у меня FreeBSD, таблица тут только одна, соответственно и iproute2 в портах нет

В ipnat потребуется по одной строчке для каждого интерфейса, чтобы это сделать

vasyav, можешь рассказать более конткретно как реализовать динамическую маршрутизацию, и какое отношение к ней имеет учет трафика(какие ограничения он может наложить)

[vasyav]

Я в начале написал, что сам я это не делал, а подсказал куда рыть. Динамическая маршрутизация - веса маршрутов.

[.]

Serega, а mrouted(8) не является решением твоей задачи?
я не вчитывался, но похоже именно то, что тебе нужно.
При попытке использовать, не забудь вкомпиллять в ядро