Здравствуйте. Пишу сюда с надеждой получить совет или какое-то указание.Есть проблема: потребление пользователями инета уже критично сказывается на текущей схеме "пограничного" участка, а именно несколько впн-серверов под управление linux и одного freebsd сервера, выполняющего роль натирования. После него циска, работающая с bgp.
Как только потребовалось увеличить количество впн/нат серверов, возникла загвоздка - текущая схема маршрутизации между ними не позволяет линейно увеличивать производительность (пропускную способность).
обычно трафик около 200мбт/с. Судя по нагрузке, одного "ната" хватает, трёх впн-серверов - нет.
Итак, схема: весь исходящий трафик идёт через впн-сервер, к которому подключился пользователь и потом на единственный нат. Возвращаются пакеты на нат, потом на крайний к нему впн-сервер (по маршрутам), если у этого впн-сервера подключён данный пользователь, пакет идёт к нему, если нет переходит на следущий впн сервер по цепочке и т.д. Получается что через ближайший впн-сервер к нату проходит весь трафик, часть которого идёт на его pptp туннели, часть маршрутизируется дальше. Получается, что нет параллельности в проходе трафика. То есть данный принцип ограничивает расширение канала, а это сейчас очень необходимо.
Ситуация, которую можно предвидеть: пусть цепочка впнов как-то работает. Наступит момент, когда не хватит натирующего сервера и придётся ставить следующий. Но, как теперь распределять впны между натами? Можно распределить часть впнов на один, часть на другой. Но это как-то вульгарно.Поэтому у меня, не знакомого с динамической маршрутизацией и не приходящих других идей в голову, крутится вопрос: как сделать схему, по которой можно будет спокойно увеличивать количество впн-серверов, нат-серверов. Распределение нагрузки между впнами есть (новой ppp сессии отдаётся адрес наименее нагруженного сервера). Увеличивать мощность серверов - не выход. Требуется именно увеличение их количества. Существование впн-туннелирования и натирования на отдельных машинах - обязательное условие. Адреса пользователей никак не привязаны к конкретному впн-серверу. Поэтому маршруты на их подсети существуют на всех впн-серверах.
Подкиньте какую-нибудь идею, пожалуйста.
>[оверквотинг удален]
>маршрутизации между ними не позволяет линейно увеличивать производительность (пропускную способность).
>обычно трафик около 200мбт/с. Судя по нагрузке, одного "ната" хватает, трёх впн-серверов
>- нет.
>Итак, схема: весь исходящий трафик идёт через впн-сервер, к которому подключился пользователь
>и потом на единственный нат. Возвращаются пакеты на нат, потом на
>крайний к нему впн-сервер (по маршрутам), если у этого впн-сервера подключён
>данный пользователь, пакет идёт к нему, если нет переходит на следущий
>впн сервер по цепочке и т.д. Получается что через ближайший впн-сервер
>к нату проходит весь трафик, часть которого идёт на его pptp
>туннели, часть маршрутизируется дальше. Получается, что нет параллельности в проходе трафика.Расскажите нам, как организована цепочка перехода пакета между серверами, думаю аудитории будет интересно.
Как, ИМХО, это должно было быть реализовано:Сервера (в т ч и NAT-сервер) соединены между собой некоторыми интерфейсами. На интерфейсах должны быть прописаны сети, из которых выдаются адреса подключающимся клиентам. Каждое подключение формирует ARP-запись (proxy ARP), таким образом NAT-сервер будет искать подключившегося клиента сразу на том сервере, куда он подключен.
>То есть данный принцип ограничивает расширение канала, а это сейчас очень
>необходимо.
>Ситуация, которую можно предвидеть: пусть цепочка впнов как-то работает. Наступит момент, когда
>не хватит натирующего сервера и придётся ставить следующий. Но, как теперь
>распределять впны между натами? Можно распределить часть впнов на один, часть
>на другой. Но это как-то вульгарно.
>
>Поэтому у меня, не знакомого с динамической маршрутизацией и не приходящих другихДинамической маршрутизацией тут и не пахнет :)
>идей в голову, крутится вопрос: как сделать схему, по которой можно
>будет спокойно увеличивать количество впн-серверов, нат-серверов. Распределение нагрузки между впнами есть
>(новой ppp сессии отдаётся адрес наименее нагруженного сервера). Увеличивать мощность серверов
>- не выход. Требуется именно увеличение их количества. Существование впн-туннелирования и
>натирования на отдельных машинах - обязательное условие. Адреса пользователей никак не
>привязаны к конкретному впн-серверу. Поэтому маршруты на их подсети существуют на
>всех впн-серверах.
>
>Подкиньте какую-нибудь идею, пожалуйста.Богата земля русская на хитрости всякие.. пусть и не всегда умные...
>Расскажите нам, как организована цепочка перехода пакета между серверами, думаю аудитории будет
>интересно.
>
>ну вот минимальная физическая схема (1 нат, 2 впна). Хотя необходимая и достаточная схема должна быть 2 ната и 3 впна.
(cisco с bgp)
|
|
---------
| NAT |
---------
|
(свитч)
| \
| \
(vpn1) (vpn2)
\ /
\ /
(свитч)
|
|
(лок. сеть)Допустим, к vpn1 подключается человек, получает ip-адрес 172.16.1.1
к vpn2 подключается 172.16.1.2
Между 172.16.1.2 и 172.16.1.1 пакеты ходить не должны
Итак, идёт пакет с 172.16.1.2 по впн туннелю до vpn2, на обоих впн-серверах default gateway это внутренний интерфейс NAT'a. Пакет удачно уходит в инет. С инета приходит пакет на NAT. Сначала идёт на vpn1. VPN1 перекидывает пакет на vpn2, дальше по впн-туннелю достигает конечного узла пользователя.
Если приходит пакет с инета для 172.16.0.1, он по умолчанию идёт на vpn1, а там сразу попадает на нужный ppp интерфейс.
Получается, что входящий трафик для "впнщиков" проходит цепочку впн-серверов.Задача 1: приходящий трафик сразу направлять на конкретный впн.
Задача 2: при наличии более одного nat'a исходящий трафик от конкретного vpn-сервера или от конкретного ppp-интерфейса любого из vpn-серверов направлять конкретному nat'у (еще возникает вопрос как балансировать трафик идущий до nat'ов)
>Как, ИМХО, это должно было быть реализовано:
>Сервера (в т ч и NAT-сервер) соединены между собой некоторыми интерфейсами. На >интерфейсах должны быть прописаны сети, из которых выдаются адреса подключающимся >клиентам. Каждое подключение формирует ARP-запись (proxy ARP), таким образом NAT-сервер >будет искать подключившегося клиента сразу на том сервере, куда он подключенкажется понял, спасибо) Буду реализовывать. Вроде, это решение задачи №1.
Теперь как быть с решением задачи 2 (пока есть идея на разных впнах делать дефолт маршрут через разные наты)
> С инета приходит пакет на NAT. Сначала идёт на vpn1.
>VPN1 перекидывает пакет на vpn2, дальше по впн-туннелю достигает конечного узла
>пользователя.Вот этот момент так и остался не понятным.
1. За счет чего пакет сначала идет на vpn1.
2. За счет чего происходит перекидывание пакета с сервера впн1 на сервер впн2 если адрес на нем не найден ?
>1. За счет чего пакет сначала идет на vpn1.
>
>2. За счет чего происходит перекидывание пакета с сервера впн1 на сервер
>впн2 если адрес на нем не найден ?всё на уровне маршрутизации:
пакет приходит с инета на nat. там есть маршрут 172.16.0.0/16 через внутренний интерфейс на внешний адрес vpn1
если на vpn1 есть ppp сессия с ip 172.16.0.1 то и есть маршрут на этот адрес через ppp
если такого ip нет, пакет пойдёт по другому маршруту с меньшим приоритетом 172.16.0.0/16 через внешний интерфейс vpn1 на внешний интерфейс vpn2
далее всё тоже самое происходитКогда-то давно стоял 1 nat и 1 vpn. Потребовался второй vpn. И было так реализовано
Можно вопрос по proxy arp? Я эту фичу использовал только как проброс арпы между ppp интерфейсами для организации виртуальной сети. А проброс с ppp на внешний интерфейс системы даже в голову не приходил. Как я понимаю proxy arp начинает функционировать для всех интерфейсов в системе, и связь между ppp придётся рубить фаерволлом.
И еще: может ли возникнуть проблема, когда вдруг два из всех vpn-серверов назначат одинаковые mac-адреса на какие-то ppp интерфейсы?
>[оверквотинг удален]
>далее всё тоже самое происходит
>
>Когда-то давно стоял 1 nat и 1 vpn. Потребовался второй vpn. И
>было так реализовано
>
>Можно вопрос по proxy arp? Я эту фичу использовал только как проброс
>арпы между ppp интерфейсами для организации виртуальной сети. А проброс с
>ppp на внешний интерфейс системы даже в голову не приходил. Как
>я понимаю proxy arp начинает функционировать для всех интерфейсов в системе,
>и связь между ppp придётся рубить фаерволлом.Да, файрволлом.
>И еще: может ли возникнуть проблема, когда вдруг два из всех vpn-серверов
>назначат одинаковые mac-адреса на какие-то ppp интерфейсы?мак адрес - это мак соответствующей сетевой карты впн-сервера. На разных серверах - разный.
Итак, настало время всё переделать под описанный здесь лад.Что сейчас имеется:
один NAT (pfnat) FreeBSD с нижнем интерфейсом 172.17.1.254, маской /12
4 впн сервера на linux с включенным proxy_arp на внешних интерфейсах с адресами 172.17.1.1 - 172.17.1.4 (маска /16)
на нижних (смотрящих в локальную сеть) интерфейсах адреса с 172.16.0.1 - 172.16.0.4 (маска /16)
маска /12 поставлена, чтобы в arp-таблице на нате появлялись адреса из впн подсеть (172.29, 172.30, 172.31) и не штомповать алиасы на нате из этих подсетей.
Подключаюсь к одному из впн-серверов, по впну выдаётся адрес 172.30.100.100в arp-таблице и таблице маршрутизации на NAT'e появляется запись с ip 172.30.100.100 и мак-адресом внешнего интерфейса впн-сервера. Вроде всё работает
Но если переподключиться через другой впн-сервер, с клиентского компьютера ничего не работает - на nat'e еще живёт старая arp запись и соответственно запись в таблице маршрутизации. Если руками очистить arp-таблицу, то появляется правильная запись.
Также наблюдаются аномалии: 172.30.100.100 начинает "скокать" с одного мака на другой (в таблице на NAT'e)
>[оверквотинг удален]
>
>Подключаюсь к одному из впн-серверов, по впну выдаётся адрес 172.30.100.100
>
>в arp-таблице и таблице маршрутизации на NAT'e появляется запись с ip 172.30.100.100
>и мак-адресом внешнего интерфейса впн-сервера. Вроде всё работает
>
>Но если переподключиться через другой впн-сервер, с клиентского компьютера ничего не работает
>- на nat'e еще живёт старая arp запись и соответственно запись
>в таблице маршрутизации. Если руками очистить arp-таблицу, то появляется правильная запись.
>ну мож там какие таймауты покрутить ?
>
>Также наблюдаются аномалии: 172.30.100.100 начинает "скокать" с одного мака на другой (в
>таблице на NAT'e)на сервере куда было первое подключение всё еще висит процесс pptp_client + pppd ?
// что мы там говорили насчет использования mpd4/5 ? ;-)
>на сервере куда было первое подключение всё еще висит процесс pptp_client +
>pppd ?нет не висит, а таймауты подкрутили. Только что-то страшновато, что же будет происходить, когда в arp-таблице по 2-3 тыс. записей окажется, которые будут обновляться каждые 5 секунд
>// что мы там говорили насчет использования mpd4/5 ? ;-)
обстоятельства...