Дано:

маршрутизатор Cisco 2801
2 wan (1 lan)

1й wan  - смотрит в сеть Большого провайдера, там маршрут по умолчанию 0/0, через него же подключается бОльшая часть внешних клиентов

2й wan - смотрит в сеть Малого провайдера, ч/з него прописаны статические маршруты до нескольких внешних стат. адресов

                        
Б-internet 0/0 - МСЭ -  /1       \
                                     | Router | -- lan
М-internet x/x - МСЭ -  \2       /

Надо:
подключиться к маршрутизатору ч/з 2й wan (из сети Малого пров-ра) с динамического адреса про протоколу VPN (конкретный протокол пока не принципиален, но наиболее вероятны Виндовые клиенты, т.е. РРТР).
Получается, что дефолтный маршрут - это один интерфейс, а организовать надо подключение с динамического адреса ч/з другой интерфейс.

Маршрутизацию по адресу клиента использовать нельзя (зная, например, подсети Малого пров-ра) (т.к. есть клиенты, которые из сети того же провайдера ходят ч/з 1й wan по основному маршруту)
Через этот машрутизатор уже ходят транзитом РРТР пакеты.

На мой взгляд, из признаков, по которым можно определить next hop для ответного VPN пакета, можно использовать только РРТР и тот факт, что ответный пакет формирует сам маршрутизатор.

Допустим, РРТР пакет, адресованный маршрутизатору, прилетает ч/з 2й WAN на ip=loopback1.
Как его отправить обратно в ту же сторону (в сторону нужного шлюза)?

• policy-routing для трафика маршрутизатора,AlexDv, 17:45 , 30-Май-12
• policy-routing для трафика маршрутизатора,KostyaK, 01:53 , 31-Май-12
  • policy-routing для трафика маршрутизатора,Sergey Bogdanov, 10:37 , 31-Май-12
• policy-routing для трафика маршрутизатора,Gromophon, 05:34 , 31-Май-12
  • policy-routing для трафика маршрутизатора,Sergey Bogdanov, 10:40 , 31-Май-12

>[оверквотинг удален]
> с динамического адреса ч/з другой интерфейс.
> Маршрутизацию по адресу клиента использовать нельзя (зная, например, подсети Малого пров-ра)
> (т.к. есть клиенты, которые из сети того же провайдера ходят ч/з
> 1й wan по основному маршруту)
> Через этот машрутизатор уже ходят транзитом РРТР пакеты.
> На мой взгляд, из признаков, по которым можно определить next hop для
> ответного VPN пакета, можно использовать только РРТР и тот факт, что
> ответный пакет формирует сам маршрутизатор.
> Допустим, РРТР пакет, адресованный маршрутизатору, прилетает ч/з 2й WAN на ip=loopback1.
> Как его отправить обратно в ту же сторону (в сторону нужного шлюза)?

А ничего делать не надо. У меня схема похожая, PPTP работает через любой интерфейс.

ip local policy route-map BLABLABLA

должно помочь...

> ip local policy route-map BLABLABLA
> должно помочь...

Ок, спасибо, кажись оно самое. Хотел бы уточнить: если я делаю acl, то в нем надо отлавливать лишь РРТР или еще что?

>[оверквотинг удален]
> с динамического адреса ч/з другой интерфейс.
> Маршрутизацию по адресу клиента использовать нельзя (зная, например, подсети Малого пров-ра)
> (т.к. есть клиенты, которые из сети того же провайдера ходят ч/з
> 1й wan по основному маршруту)
> Через этот машрутизатор уже ходят транзитом РРТР пакеты.
> На мой взгляд, из признаков, по которым можно определить next hop для
> ответного VPN пакета, можно использовать только РРТР и тот факт, что
> ответный пакет формирует сам маршрутизатор.
> Допустим, РРТР пакет, адресованный маршрутизатору, прилетает ч/з 2й WAN на ip=loopback1.
> Как его отправить обратно в ту же сторону (в сторону нужного шлюза)?

vrf вам в помощь, если умрет интерфейс через который настроен дефолтный маршрут, работать ничего не будет, а два дефолтных маршрута через разные интерфейсы не работает одновременно, local policy не работает при шифровании

> local policy не работает при шифровании

ага... а если в свойствах шифрования в команде
ppp encrypt mppe auto
вместо auto поставить none это тоже будет шифрование?