Два VPN соединения и default route, а может что-то другое.

Покажи ip r до и после поднятия второго соединения

до поднятия
213.154.183.2 dev ppp0 proto kernel scope link src 83.69.16.111
10.0.0.1 via 10.1.14.1 dev eth0
10.1.14.0/24 via 10.1.14.1 dev eth0
10.1.14.0/24 dev eth0 proto kernel scope link src 10.1.14.2 metric 10
172.16.135.0/24 dev eth1 proto kernel scope link src 172.16.135.5 metric 10
169.254.0.0/16 dev eth1 scope link metric 10
169.254.0.0/16 dev eth0 scope link metric 10
10.0.0.0/8 via 10.1.14.1 dev eth0
default dev ppp0 scope link

после поднятия
[root@ns3 etc]# ip r
213.154.183.2 dev ppp0 proto kernel scope link src 83.69.16.111
213.154.183.2 dev ppp1 proto kernel scope link src 83.69.25.176
10.0.0.1 via 10.1.14.1 dev eth0
10.1.14.0/24 via 10.1.14.1 dev eth0
10.1.14.0/24 dev eth0 proto kernel scope link src 10.1.14.2 metric 10
172.16.135.0/24 dev eth1 proto kernel scope link src 172.16.135.5 metric 10
169.254.0.0/16 dev eth1 scope link metric 10
169.254.0.0/16 dev eth0 scope link metric 10
10.0.0.0/8 via 10.1.14.1 dev eth0
default dev ppp0 scope link

При проверках фаервол был отключен.

а что такое этот 213.154.183.2 ?

А это адрес VPN соединения со стороны сервера провайдера.

Похоже, что приподнятии pppd оно автоматически роутится как дефалт. Новот как это отключить - непонятно. Может кто подскажет.

>Похоже, что приподнятии pppd оно автоматически роутится как дефалт. Новот как это отключить - непонятно. Может кто подскажет.

В options прописать nodefaultroute.

Не помогает. На рабочем месте поднимал 2 соединения в интернет. И менял всякие параметры. Пока ответа нет. Роут работает только на последний поднятый VPN интерфейс. Помогите, если кто знает.

ну, а tcpdump на интерфейсах ppp0 и ppp1 что показывает? dns свой или провайдера?

Если проблему не удается решить, её можно обойти. Можешь после каждого подключения инета выполнять скрипт который удаляет маршрут по умолчанию.

так опыт на своей машине DNS на VPN сервере
1. Последовательно подняты ppp0 и ppp1, default route - ppp0
На одной консоли
ping www.ru
Ответа нет
На другой
tcpdump -i ppp0
[root@mnk media]# tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
14:10:52.381625 IP 172.16.131.10 > www.ru: ICMP echo request, id 6417, seq 1, length 64
14:10:53.381366 IP 172.16.131.10 > www.ru: ICMP echo request, id 6417, seq 2, length 64
14:10:54.381398 IP 172.16.131.10 > www.ru: ICMP echo request, id 6417, seq 3, length 64
14:10:55.381431 IP 172.16.131.10 > www.ru: ICMP echo request, id 6417, seq 4, length 64
Те запросы правильно идут, а ответов нет

tcpdump -i ppp1 - Ничего нет

2. Тоже самое, но default route ppp1
[root@mnk media]# tcpdump -i ppp1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp1, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
14:18:09.655792 IP www.ru > 172.16.131.39: ICMP echo reply, id 6417, seq 438, length 64
14:18:10.607603 IP 172.16.131.39 > www.ru: ICMP echo request, id 6417, seq 439, length 64
14:18:10.659427 IP www.ru > 172.16.131.39: ICMP echo reply, id 6417, seq 439, length 64
14:18:11.607638 IP 172.16.131.39 > www.ru: ICMP echo request, id 6417, seq 440, length 64
14:18:11.643614 IP www.ru > 172.16.131.39: ICMP echo reply, id 6417, seq 440, length 64

5 packets captured
5 packets received by filter
0 packets dropped by kernel

Тут видим и то и другое.

Те вывод - это сервер не отвечает на запросы клиента, которые он отправляет.

Вот еще очень интересная вещь 1 На стороне клиента [root@mnk media]# ifconfig | grep -A1 ppp ppp0 Link encap:Point-to-Point Protocol inet addr:172.16.131.10 P-t-P:172.16.132.2 Mask:255.255.255.255 -- ppp1 Link encap:Point-to-Point Protocol inet addr:172.16.131.39 P-t-P:172.16.132.2 Mask:255.255.255.255

На стороне сервера ищем теже интерфейсы [root@ns1 etc]# ifconfig | grep 172.16.131.39 inet addr:172.16.132.2 P-t-P:172.16.131.39 Mask:255.255.255.255 [root@ns1 etc]# ifconfig | grep 172.16.131.10 [root@ns1 etc]#

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

Извиняюсь, опять забыл User line brake поставить
Сделали бы они его по умолчанию
Вот еще очень интересная вещь
1 На стороне клиента
[root@mnk media]# ifconfig | grep -A1 ppp
ppp0 Link encap:Point-to-Point Protocol
inet addr:172.16.131.10 P-t-P:172.16.132.2 Mask:255.255.255.255
--
ppp1 Link encap:Point-to-Point Protocol
inet addr:172.16.131.39 P-t-P:172.16.132.2 Mask:255.255.255.255

На стороне сервера ищем теже интерфейсы
[root@ns1 etc]# ifconfig | grep 172.16.131.39
inet addr:172.16.132.2 P-t-P:172.16.131.39 Mask:255.255.255.255
[root@ns1 etc]# ifconfig | grep 172.16.131.10
[root@ns1 etc]#

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

1. Подключения точно под разными логинами?
2. Если ответ на 1-ое - "да", то почему бы серверу не брать для себя (шлюза) разные адреса, а не один 172.16.132.2. Т.к. как ты себе представляешь работу одновременно двух интерфейсов с одним и тем же ай-пи, когда клиент на одной машине. Всегда будет работать последний подключенный маршрут, перепрописывая предыдущий.
tcpdump тебе это и показывает - сервер шлет ответы icmp на второе подключение, ему все равно что запросы пришли с первого.

кстати, в чём-то похожая байда была:

eth0 -- 192.168.10.11/24

eth1 -- 192.168.10.12/24

надеялся раскидать нагрузку (наивный). однако на свиче мигал только 1 провод (щас не помню -- 1-й или 2-й). перекомпилил ядро, добавил ROUTE в iptables, запустил -- то же самое. дальнейшее исследование показало: на arp-запросы обоих адресов ядро овечало MAC'ом одного интерфейса (такая вот абстракция, понимаешь). по-быстрому решил редактирование /etc/ether на другой машине, но интересует генеральное решение (и вообще, это правильно-- такое поведение?).

2 berrywizard: я думаю проблема в чем-то другом была. Тем более не известно как свитч реагировал и что с линками было...

>. Если ответ на 1-ое - "да", то почему бы серверу не брать для себя (шлюза) разные адреса, а не один 172.16.132.2. 1. Как это осуществить? У меня не получилось Хочу еще попробовать установить вторую карточку с другим IP адресом, но из той же сети. И с помощью фаевола или iproute2 пернаправить пакеты для одного соединения через одну карту, а другого через другую. Но не совсем еще представляю, как это сделать. Возможно ли такое, и как сделать?

>. Если ответ на 1-ое - "да", то почему бы серверу не брать для себя (шлюза) разные адреса, а не один 172.16.132.2.
1. Как это осуществить? У меня не получилось
Хочу еще попробовать установить вторую карточку с другим IP адресом, но из той же сети. И с помощью фаевола или iproute2 пернаправить пакеты для одного соединения через одну карту, а другого через другую. Но не совсем еще представляю, как это сделать.
Возможно ли такое, и как сделать?