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