LINUX.ORG.RU
Форум — Admin  

Маршрутизация по нескольком iface


0

0

Доброго времени суток.

есть 2 компьютера, связанные по ОпенВПНу. сети их по внутренним адресам пингуются 

user1
ppp0 - adsl (real ip)
tun0 - openVPN (10.10.10.26)
eth1 - lan (192.168.4.x)

server1
eth0 - lan (192.168.5.1)
tun0 - openvpn (10.10.10.1)
eth1 - inet (realip)
Цель. пусть весь трафик через шлюз server'a на server1 настроен маскарад. 1 для своих 2 для тех кто будет идти с впна

-A POSTROUTING -s 192.168.0.0/255.255.0.0 -o eth1 -j MASQUERADE
-A POSTROUTING -s 10.10.10.0/255.255.255.0 -o eth1 -j MASQUERADE

на user1 Хочу проверить полетит ли пакет в инет через tun #ping google.com -I tun0

Пинг не ходит, на server1 запускаю 

#tcpdump -i tun0 -vvv
14:34:03.096423 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.10.10.26 > 74.125.232.16: ICMP echo request, id 33590, seq 8, length 64
14:34:03.150643 IP (tos 0x0, ttl 57, id 44291, offset 0, flags [none], proto ICMP (1), length 84) 74.125.232.16 > 10.10.10.26: ICMP echo reply, id 33590, seq 8, length 64
тоесть server видит пакеты с 26 и пересылает обратно. но пинг не работает.

Запускаю на client1 тот же tcpdump 

14:53:32.753770 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.10.10.26 > 74.125.232.18: ICMP echo request, id 46902, seq 1, length 64
14:53:32.841460 IP (tos 0x0, ttl 57, id 18880, offset 0, flags [none], proto ICMP (1), length 84) 74.125.232.18 > 10.10.10.26: ICMP echo reply, id 46902, seq 1, length 64
14:53:33.754347 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.10.10.26 > 74.125.232.18: ICMP echo request, id 46902, seq 2, length 64
14:53:33.837788 IP (tos 0x0, ttl 57, id 18881, offset 0, flags [none], proto ICMP (1), length 84) 74.125.232.18 > 10.10.10.26: ICMP echo reply, id 46902, seq 2, length 64
14:53:34.754352 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 10.10.10.26 > 74.125.232.18: ICMP echo request, id 46902, seq 3, length 64

Тоесть, что-то ходит.

Вопрос первый. 1 почему не работает пинг через server? 2 Как лучше организовать маршрутизацию? через дополнительную таблицу маршрутизации? или хватит основной просто дефаулт гетвей сделать на tun0 вместо ppp0?

Ответ на: комментарий от gserg

Да, в притом оба (client1 и server1) настроены шлюзами для своих локалок в инет. и оно работает.

на клиент1 делаю 

# tracert 8.8.8.8 -i tun0
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
 1  10.10.10.1 (10.10.10.1)  31.234 ms  35.157 ms  38.028 ms
 2  * * *

ilovemicrosoft
() автор топика
Ответ на: комментарий от gserg

Я так понимаю не ходит потому, что на client1 прописан дефайлт гетвей.

client1 

 # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
213.228.116.38  0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
10.10.10.25     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.5.0     10.10.10.25     255.255.255.0   UG    0      0        0 tun0
192.168.4.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.1.0     10.10.10.25     255.255.255.0   UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.10.10.0      10.10.10.25     255.255.255.0   UG    0      0        0 tun0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0

server1 - на самом деле опенвпн клиентов не мало все они имеют сети 192.168.0-5.0 

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.10.2      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
217.117.176.96  0.0.0.0         255.255.255.240 U     0      0        0 eth1
192.168.100.0   10.10.10.2      255.255.255.0   UG    0      0        0 tun0
192.168.5.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.4.0     10.10.10.2      255.255.255.0   UG    0      0        0 tun0
192.168.3.0     10.10.10.2      255.255.255.0   UG    0      0        0 tun0
192.168.2.0     10.10.10.2      255.255.255.0   UG    0      0        0 tun0
192.168.1.0     10.10.10.2      255.255.255.0   UG    0      0        0 tun0
192.168.0.0     10.10.10.2      255.255.255.0   UG    0      0        0 tun0
10.10.10.0      10.10.10.2      255.255.255.0   UG    0      0        0 tun0
0.0.0.0         217.117.176.97  0.0.0.0         UG    100    0        0 eth1

ilovemicrosoft
() автор топика
Ответ на: комментарий от ilovemicrosoft

На клиенте есть ещё есть интерфейс eth0 - это шнурок в ADSL модем

ilovemicrosoft
() автор топика
Ответ на: комментарий от ilovemicrosoft

ну так задай gw на тунель йоба!

anonymous
()
Ответ на: комментарий от nnz

Спасибо, похоже это то, что мне надо, беглое изучение темы не помогло. ЧИтаю маны.

Jul  2 19:28:52 ino ovpn-client[14465]: TUN/TAP device tun0 opened
Jul  2 19:28:52 ino ovpn-client[14465]: TUN/TAP TX queue length set to 100
Jul  2 19:28:52 ino ovpn-client[14465]: ifconfig tun0 10.10.10.26 pointopoint 10.10.10.25 mtu 1500
Jul  2 19:28:53 ino ovpn-client[14465]: NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
Jul  2 19:28:53 ino ovpn-client[14465]: route add -net 192.168.5.0 netmask 255.255.255.0 gw 10.10.10.25
Jul  2 19:28:53 ino ovpn-client[14465]: route add -net 10.10.10.0 netmask 255.255.255.0 gw 10.10.10.25
Jul  2 19:28:53 ino ovpn-client[14465]: route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.10.25
Jul  2 19:28:53 ino ovpn-client[14465]: GID set to nogroup
Jul  2 19:28:53 ino ovpn-client[14465]: UID set to nobody
Jul  2 19:28:53 ino ovpn-client[14465]: Initialization Sequence Completed
ilovemicrosoft
() автор топика
Ответ на: комментарий от ilovemicrosoft

>NOTE: unable to redirect default gateway — Cannot read current default gateway from system

До запуска openvpn у клиента должен быть дефолтный гейт. Предполагаю, что adsl. Ковыряй настройки ppp-демона.

nnz ★★★★
()
Ответ на: комментарий от nnz

Маршрутизация до поднятия ОпенВПНа

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
ksk-bbar2.ncc.s *               255.255.255.255 UH    0      0        0 ppp0
192.168.4.0     *               255.255.255.0   U     0      0        0 eth1
localnet        *               255.255.255.0   U     0      0        0 eth0
default         *               0.0.0.0         U     0      0        0 ppp0

/etc/ppp/peers/dsl-provider

# cat dsl-provider
# Minimalistic default options file for DSL/PPPoE connections

noipdefault
defaultroute
replacedefaultroute
hide-password
#lcp-echo-interval 30
#lcp-echo-failure 4
noauth
persist
#mtu 1492
#persist
#maxfail 0
#holdoff 20
plugin rp-pppoe.so eth0
user "username"
usepeerdns
ilovemicrosoft
() автор топика
Ответ на: комментарий от nnz

Мне конечно оч нравится описание, хорошо подходит к нестабильным каналам.

Изменение маршрута по умолчанию

Есть возможность установить маршрут по умолчанию (default route) через созданный туннель OpenVPN. Для этого можно использовать директиву 'redirect-gateway', в т.ч. с автоматической передачей её клиенту через механизм push-pull. Однако при работе клиента под непривилегированным пользователем и в chroot-окружении возникают проблемы с восстановлением старого маршрута при закрытии соединения, т.к. клиенту не хватает прав внести изменения в таблицу маршрутизации. Для обхода этой ситуации следует использовать параметр 'def1' директивы 'redirect-gateway'. При этом на сервере в файле конфигурации (глобальном или конкретного клиента) переназначение маршрута задаётся строкой вида

  push "redirect-gateway def1"

Получив эту директиву (при наличии 'pull' в своей конфигурации), клиент не удаляет старый маршрут, а добавляет в таблицу маршрутизации записи вида: 

 0.0.0.0/1 via 192.168.231.5 dev tun0 
 128.0.0.0/1 via 192.168.231.5 dev tun0
Оригинальный маршрут по-умолчанию при этом не используется пока существует интерфейс tun0 канала.

Но как мне быть то :(

ilovemicrosoft
() автор топика
Ответ на: комментарий от anonymous

Как я писал выше.

в конфиг клиента на сервере я добавил такую строчку.

push "redirect-gateway def1"

В клиенте прописал просто redirect-gateway

В логах запись

Jul  2 19:28:53 ino ovpn-client[14465]: NOTE: unable to redirect default gateway -- Cannot read current default gateway from system

Попытался руками убить дефаулт роут да удалённая машина не вернулась :)))

ilovemicrosoft
() автор топика
Ответ на: комментарий от ilovemicrosoft

Тогда, наверное, придется делать маршрутизацию вручную.
ip ro add 0.0.0.0/1 via 10.10.10.1 dev tun0
ip ro add 128.0.0.0/1 via 10.10.10.1 dev tun0
ip ro add <ovpn_server_realip> dev ppp0

Можно засунуть это в route-up скрипт.

А вообще, покажи полные конфиги сервера и клиента. Сдается мне, есть там ошибочки.

nnz ★★★★
()
Ответ на: комментарий от nnz

Конфиг сервера. 

# cat /etc/openvpn/server.conf

port 1194
proto udp
dev tun
;dev-node tap0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key # This file should be kept secret
dh /etc/openvpn/dh1024.pem
server 10.10.10.0 255.255.255.0 # vpn subnet
ifconfig-pool-persist ipp.txt
push "route 192.168.5.0 255.255.255.0" # home subnet
;duplicate-cn
keepalive 10 120
;cipher BF-CBC        # Blowfish (default)
;cipher AES-128-CBC   # AES
;cipher DES-EDE3-CBC  # Triple-DES
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log-append  openvpn.log
verb 4
mute 20
client-to-client
client-config-dir /etc/openvpn/ccd
route 192.168.100.0 255.255.255.0
route 192.168.0.0 255.255.255.0
route 192.168.1.0 255.255.255.0
route 192.168.3.0 255.255.255.0
route 192.168.2.0 255.255.255.0
route 192.168.4.0 255.255.255.0

тут уже експирименты ставил 

#cat /etc/openvpn/ccd/client1.conf


iroute 192.168.4.0 255.255.255.0
# роутинг на сеть западного офиса
push "route 192.168.1.0 255.255.255.0"
#push "route-gateway 10.10.10.1"
#push "dhcp-option DNS 192.168.5.1"
#push "dhcp-option WINS 192.168.1.254"
#push "redirect-gateway"
push "route add 195.111.111.111 dev ppp0"
push "route del default dev ppp0"
push "route add default dev tun0"
push "redirect-gateway def1"

Конфиг клиента. 

# cat /etc/openvpn/client.conf

Вывод 

remote xxx.xxx.176.99 1194
client
dev tun
proto udp
resolv-retry infinite # this is necessary for DynDNS
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/zapadnii.crt
key /etc/openvpn/zapadnii.key
comp-lzo
verb 4
mute 20

Вот и сюда я добавлял redirect-gateway.

ilovemicrosoft
() автор топика
Ответ на: комментарий от ilovemicrosoft

>push «route add 195.111.111.111 dev ppp0»

push «route del default dev ppp0»

push «route add default dev tun0»


Можно убрать, все равно синтаксис некорректный.
В остальном вроде правильно.

Теперь меня интересует таблица маршрутизации на клиенте в трех ситуациях:
1. До запуска vpn
2. После запуска с redirect-gateway def1
3. После перезапуска с redirect-gateway local def1

Вручную пока никаких маршрутов добавлять не надо.

nnz ★★★★
()
Ответ на: комментарий от nnz

Тот флиал, на котором всё проводил в дауне, поэтому другой, тут нет ppp0 тут сразу eth1 инет, на нём может всё само и заведётся.

1 опенвпн стоп 

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
217.111.176.96  0.0.0.0         255.255.255.240 U     0      0        0 eth1
192.168.5.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         217.111.176.97  0.0.0.0         UG    100    0        0 eth1

Да как и ожидалось, на этом филиале всё заработало. тут всё тоже самое только модем в другом режиме, ацки редком (4х адресник)

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.10.13     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
217.111.176.99  195.112.255.165 255.255.255.255 UGH   0      0        0 eth1
195.111.255.164 0.0.0.0         255.255.255.252 U     0      0        0 eth1
192.168.5.0     10.10.10.13     255.255.255.0   UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.10.10.0      10.10.10.13     255.255.255.0   UG    0      0        0 tun0
0.0.0.0         10.10.10.13     128.0.0.0       UG    0      0        0 tun0
128.0.0.0       10.10.10.13     128.0.0.0       UG    0      0        0 tun0
0.0.0.0         195.111.255.165 0.0.0.0         UG    100    0        0 eth1

После поднятия ВПНа сервер отвалился по внешнему ифейсу, но через впн доступен и здраствует - инет видит.

Другие филиалы щас опробую, может кого не выключили на выходные :(

ilovemicrosoft
() автор топика
Ответ на: комментарий от nnz

Ага удача, один из филиалов, у которого подключение через PPPoE.

И так поехали. 

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
213.111.116.38  0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0

Поднимаем опенвпн.

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.10.17     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
213.111.116.38  0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.5.0     10.10.10.17     255.255.255.0   UG    0      0        0 tun0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.1.0     10.10.10.17     255.255.255.0   UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.10.10.0      10.10.10.17     255.255.255.0   UG    0      0        0 tun0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0

Вариант3 с локал

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.10.17     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
213.111.116.38  0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.5.0     10.10.10.17     255.255.255.0   UG    0      0        0 tun0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.1.0     10.10.10.17     255.255.255.0   UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.10.10.0      10.10.10.17     255.255.255.0   UG    0      0        0 tun0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
ilovemicrosoft
() автор топика
Ответ на: комментарий от ilovemicrosoft

При этом в логе вот такая запись. 

~# tail /var/log/syslog
Jul  5 01:56:05 zur ovpn-client[9748]: TUN/TAP device tun0 opened
Jul  5 01:56:05 zur ovpn-client[9748]: TUN/TAP TX queue length set to 100
Jul  5 01:56:05 zur ovpn-client[9748]: ifconfig tun0 10.10.10.18 pointopoint 10.10.10.17 mtu 1500
Jul  5 01:56:05 zur ovpn-client[9748]: NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
Jul  5 01:56:05 zur ovpn-client[9748]: route add -net 192.168.5.0 netmask 255.255.255.0 gw 10.10.10.17
Jul  5 01:56:05 zur ovpn-client[9748]: route add -net 10.10.10.0 netmask 255.255.255.0 gw 10.10.10.17
Jul  5 01:56:05 zur ovpn-client[9748]: route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.10.17
Jul  5 01:56:05 zur ovpn-client[9748]: GID set to nogroup
Jul  5 01:56:05 zur ovpn-client[9748]: UID set to nobody
Jul  5 01:56:05 zur ovpn-client[9748]: Initialization Sequence Completed

ilovemicrosoft
() автор топика
Ответ на: комментарий от ilovemicrosoft

Хотел опыт провести, в конфиг этого клиента добавить local и посмотреть, что поменяется, в конфиг добавил, дал впн серверу рестарт, дабы обновил конфиги и пинг с филиалом оборвался :))

теперь он не по внешнему не по внутренними недоступен :))

Хотя нет, минут через 5 вышел на связь, только когда из конфига удалил local

ilovemicrosoft
() автор топика
Ответ на: комментарий от ilovemicrosoft

>После поднятия ВПНа сервер отвалился по внешнему ифейсу, но через впн доступен и здраствует - инет видит.

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

Что касается PPPoE, то это, как я понимаю, больное место. И неудивительно, потому что впн поверх впна обещает веселье по определению. Вот попалось на глаза одно решение: http://lists.altlinux.org/pipermail/sysadmins/2008-January/024452.html

nnz ★★★★
()
Ответ на: комментарий от nnz

Решение хорошее, но тогда правда, возникает косяк с отловом обрыва АДСЛя. Во первых раз в сутки сессия рвётся принудительно провайдером, + стопицот раз может рваться из-за каналов, разбросанных по пределам родной сибири :)

Пока провожу такой опыт

создам файл. 

/etc/ppp/ip-up.d/routing
в него попробую закинуть. скрипт. 
#! /bin/sh
#
route del default
route add -net default gw 213.228.116.38 dev ppp0

Потом сделаю ему вот это 

chmod ug+x /etc/ppp/ip-up.d/routing

Вот только вопрос, если я что-то сделал не правильно, как сделать так, чтоб сервер вернулся после например 30 минут, если не получилось выйти в инет?

ilovemicrosoft
() автор топика
Ответ на: комментарий от ilovemicrosoft

>Вот только вопрос, если я что-то сделал не правильно, как сделать так, чтоб сервер вернулся после например 30 минут, если не получилось выйти в инет?

Запихнуть в крон скрипт, который каждые 30 минут проверяет доступность инета, и в случае недоступности меняет дефолтный гейт.
Кстати, тут недавно мелькало что-то похожее, хотя и для немного другой ситуации http://www.linux.org.ru/jump-message.jsp?msgid=5068921&cid=5069403

nnz ★★★★
()
Ответ на: комментарий от nnz

Ещё одна беда, не просто маршрут добавить :(

я так понимаю у сибирь телекома не один брас

213.228.116.38 213.228.116.39

Может и ещё есть

ilovemicrosoft
() автор топика
Ответ на: комментарий от nnz

При реконнекте меняется дефаулт гетвей. Пока вижу, что выдаются 2 разных дефаулт гетвея.

213.228.116.38

213.228.116.39

Тоесть вариант простого изготовления скрипта не катит, надо что-то умнее писать.

Тоесть вот это не прокатит.

#! /bin/sh 
# 
route del default 
route add -net default gw 213.228.116.38 dev ppp0

А же могу указать маршрут до впн сервера без указания гетвея? прочто через интерфейс?

ilovemicrosoft
() автор топика
Ответ на: комментарий от ilovemicrosoft

Мне казалось, что параметры подключения должны передаваться скриптам через параметры или переменные окружения.

nnz ★★★★
()
Ответ на: комментарий от nnz

Ещё есть вопросик, вот зарулился весь трафик в опенвпн, всё бы ничего но сервер перестал откликаться по внешнему реальному адресу.

Как бы сделать так чтоб доступ через внешку всётаки был до сервера? 

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.10.13     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
217.117.176.99  195.112.255.165 255.255.255.255 UGH   0      0        0 eth1
195.112.255.164 0.0.0.0         255.255.255.252 U     0      0        0 eth1
192.168.5.0     10.10.10.13     255.255.255.0   UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.10.10.0      10.10.10.13     255.255.255.0   UG    0      0        0 tun0
0.0.0.0         10.10.10.13     128.0.0.0       UG    0      0        0 tun0
128.0.0.0       10.10.10.13     128.0.0.0       UG    0      0        0 tun0
0.0.0.0         195.112.255.165 0.0.0.0         UG    100    0        0 eth1

ilovemicrosoft
() автор топика
Ответ на: комментарий от ilovemicrosoft

ip ro add default via 195.112.255.165 dev eth1 table 101
ip ru add from <внешний_адрес> table 101

Как-то так.

nnz ★★★★
()
Ответ на: комментарий от ilovemicrosoft

Вышел из этой ситуации не Элегантно а влоб.

Свой ИП добавил в таблицу маршрутизации.

route add 91.100.100.200 gw 195.112.255.165 eth1
ilovemicrosoft
() автор топика
Ответ на: комментарий от ilovemicrosoft

А вообще интересная ситуация, я не знал, что существуют такие провайдеры, у которых почту можно забрать только с ИПА его сети, тоесть надо быть физически быть именно на территории провайдера

ilovemicrosoft
() автор топика
Ответ на: комментарий от nnz

Вернулся с отпусков, допилил немного систему...

Я не стал шибко умные скрипты писать, а просто отловил шлюз по умолчанию, да подменил не правильный маршрут 

0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0

gw c 0.0.0.0 на настоящий гетвей

Для этого, я создал простой скриптик

/etc/ppp/ip-up.d/routing

c содержанием

#! /bin/sh
#Определяем выданный шлюз по умолчанию
gw1=`ip route show | grep 213 | awk '{print $1}'`
# Удаляем 0.0.0.0 0.0.0.0
route del default
# Добавляем маршрут с верным шлюзом
route add -net default gw ${gw1} dev ppp0

После чего, весь трафик завернулся в ОпенВПН.

Пока не знаю как поведёт себя опенвпн при падении PPPoE Но к вечеру протестирую

ilovemicrosoft
() автор топика
Ответ на: комментарий от ilovemicrosoft

После нескольких экспериментов с обрывом ppp сессии, сервер всётаки не вернулся, точнее провайдер видит что сессия поднялась, но сервера никто не видит, ни по внешнему ни по внутренним ипам.

Видимо, что-то я не учёл

ilovemicrosoft
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin