The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Проблемы с расширением штата нат и впн-серверов"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Оптимизация и Промышленные системы (Public)
Изначальное сообщение [ Отслеживать ]

"Проблемы с расширением штата нат и впн-серверов"  
Сообщение от Bonzo (ok) on 28-Ноя-08, 01:31 
Здравствуйте. Пишу сюда с надеждой получить совет или какое-то указание.

Есть проблема: потребление пользователями инета уже критично сказывается на текущей схеме "пограничного" участка, а именно несколько впн-серверов под управление linux и одного freebsd сервера, выполняющего роль натирования. После него циска, работающая с bgp.
Как только потребовалось увеличить количество впн/нат серверов, возникла загвоздка - текущая схема маршрутизации между ними не позволяет линейно увеличивать производительность (пропускную способность).
обычно трафик около 200мбт/с. Судя по нагрузке, одного "ната" хватает, трёх впн-серверов - нет.
Итак, схема: весь исходящий трафик идёт через впн-сервер, к которому подключился пользователь и потом на единственный нат. Возвращаются пакеты на нат, потом на крайний к нему впн-сервер (по маршрутам), если у этого впн-сервера подключён данный пользователь, пакет идёт к нему, если нет переходит на следущий впн сервер по цепочке и т.д. Получается что через ближайший впн-сервер к нату проходит весь трафик, часть которого идёт на его pptp туннели, часть маршрутизируется дальше. Получается, что нет параллельности в проходе трафика. То есть данный принцип ограничивает расширение канала, а это сейчас очень необходимо.
Ситуация, которую можно предвидеть: пусть цепочка впнов как-то работает. Наступит момент, когда не хватит натирующего сервера и придётся ставить следующий. Но, как теперь распределять впны между натами? Можно распределить часть впнов на один, часть на другой. Но это как-то вульгарно.

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

Подкиньте какую-нибудь идею, пожалуйста.

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Проблемы с расширением штата нат и впн-серверов"  
Сообщение от PavelR (??) on 28-Ноя-08, 06:53 
>[оверквотинг удален]
>маршрутизации между ними не позволяет линейно увеличивать производительность (пропускную способность).
>обычно трафик около 200мбт/с. Судя по нагрузке, одного "ната" хватает, трёх впн-серверов
>- нет.
>Итак, схема: весь исходящий трафик идёт через впн-сервер, к которому подключился пользователь
>и потом на единственный нат. Возвращаются пакеты на нат, потом на
>крайний к нему впн-сервер (по маршрутам), если у этого впн-сервера подключён
>данный пользователь, пакет идёт к нему, если нет переходит на следущий
>впн сервер по цепочке и т.д. Получается что через ближайший впн-сервер
>к нату проходит весь трафик, часть которого идёт на его pptp
>туннели, часть маршрутизируется дальше. Получается, что нет параллельности в проходе трафика.

Расскажите нам, как организована цепочка перехода пакета между серверами, думаю аудитории будет интересно.


Как, ИМХО, это должно было быть реализовано:

Сервера (в т ч и NAT-сервер) соединены между собой некоторыми интерфейсами. На интерфейсах должны быть прописаны сети, из которых выдаются адреса подключающимся клиентам. Каждое подключение формирует ARP-запись (proxy ARP), таким образом NAT-сервер будет искать подключившегося клиента сразу на том сервере, куда он подключен.


>То есть данный принцип ограничивает расширение канала, а это сейчас очень
>необходимо.
>Ситуация, которую можно предвидеть: пусть цепочка впнов как-то работает. Наступит момент, когда
>не хватит натирующего сервера и придётся ставить следующий. Но, как теперь
>распределять впны между натами? Можно распределить часть впнов на один, часть
>на другой. Но это как-то вульгарно.
>
>Поэтому у меня, не знакомого с динамической маршрутизацией и не приходящих других

Динамической маршрутизацией тут и не пахнет :)

>идей в голову, крутится вопрос: как сделать схему, по которой можно
>будет спокойно увеличивать количество впн-серверов, нат-серверов. Распределение нагрузки между впнами есть
>(новой ppp сессии отдаётся адрес наименее нагруженного сервера). Увеличивать мощность серверов
>- не выход. Требуется именно увеличение их количества. Существование впн-туннелирования и
>натирования на отдельных машинах - обязательное условие. Адреса пользователей никак не
>привязаны к конкретному впн-серверу. Поэтому маршруты на их подсети существуют на
>всех впн-серверах.
>
>Подкиньте какую-нибудь идею, пожалуйста.

Богата земля русская на хитрости всякие.. пусть и не всегда умные...


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Проблемы с расширением штата нат и впн-серверов"  
Сообщение от Bonzo (ok) on 28-Ноя-08, 15:28 
>Расскажите нам, как организована цепочка перехода пакета между серверами, думаю аудитории будет
>интересно.
>
>

ну вот минимальная физическая схема (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 (пока есть идея на разных впнах делать дефолт маршрут через разные наты)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Проблемы с расширением штата нат и впн-серверов"  
Сообщение от PavelR (??) on 29-Ноя-08, 08:26 

> С инета приходит пакет на NAT. Сначала идёт на vpn1.
>VPN1 перекидывает пакет на vpn2, дальше по впн-туннелю достигает конечного узла
>пользователя.

Вот этот момент так и остался не понятным.

1. За счет чего пакет сначала идет на vpn1.

2. За счет чего происходит перекидывание пакета с сервера впн1 на сервер впн2 если адрес на нем не найден ?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Проблемы с расширением штата нат и впн-серверов"  
Сообщение от Bonzo (ok) on 29-Ноя-08, 12:13 
>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 интерфейсы?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Проблемы с расширением штата нат и впн-серверов"  
Сообщение от PavelR (??) on 29-Ноя-08, 20:26 
>[оверквотинг удален]
>далее всё тоже самое происходит
>
>Когда-то давно стоял 1 nat и 1 vpn. Потребовался второй vpn. И
>было так реализовано
>
>Можно вопрос по proxy arp? Я эту фичу использовал только как проброс
>арпы между ppp интерфейсами для организации виртуальной сети. А проброс с
>ppp на внешний интерфейс системы даже в голову не приходил. Как
>я понимаю proxy arp начинает функционировать для всех интерфейсов в системе,
>и связь между ppp придётся рубить фаерволлом.

Да, файрволлом.

>И еще: может ли возникнуть проблема, когда вдруг два из всех vpn-серверов
>назначат одинаковые mac-адреса на какие-то ppp интерфейсы?

мак адрес - это мак соответствующей сетевой карты впн-сервера. На разных серверах - разный.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Проблемы с расширением штата нат и впн-серверов"  
Сообщение от Bonzo (ok) on 18-Дек-08, 17:58 
Итак, настало время всё переделать под описанный здесь лад.

Что сейчас имеется:
один 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)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Проблемы с расширением штата нат и впн-серверов"  
Сообщение от PavelR (??) on 18-Дек-08, 22:42 
>[оверквотинг удален]
>
>Подключаюсь к одному из впн-серверов, по впну выдаётся адрес 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 ? ;-)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Проблемы с расширением штата нат и впн-серверов"  
Сообщение от Bonzo (ok) on 19-Дек-08, 00:09 
>на сервере куда было первое подключение всё еще висит процесс pptp_client +
>pppd ?

нет не висит, а таймауты подкрутили. Только что-то страшновато, что же будет происходить, когда в arp-таблице по 2-3 тыс. записей окажется, которые будут обновляться каждые 5 секунд

>// что мы там говорили насчет использования mpd4/5 ? ;-)

обстоятельства...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру