LINUX.ORG.RU
решено Форум — Admin  

OpenVPN recursive routing

 


0

1

Недавно openvpn туннель на одной из машин перестал подниматься после потери соединения, помогает только ручной рестарт демона. В лог при этом сыплется ругань на рекурсивную маршрутизацию: 

Recursive routing detected, drop tun packet to [AF_INET]$SERVER_IP:$SERVER_PORT
Конфиг клиента: 
client
dev tun
port $SERVER_PORT
proto tcp
remote $SERVER_IP
nobind
persist-key
persist-tun
redirect-gateway def1 bypass-dhcp
comp-lzo
script-security 2
ping-restart 30
up /usr/share/openvpn/update-resolv-conf
down /usr/share/openvpn/update-resolv-conf
verb 4
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/$HOST.crt
key /etc/openvpn/keys/$HOST.key
Конфиг сервера: 
port $SERVER_PORT
proto tcp
dev tun
cert    /etc/openvpn/keys/$HOST.crt
dh      /etc/openvpn/keys/dh2048.pem
server 10.9.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-to-client
duplicate-cn
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
verb 4
Раньше всё работало как надо, но потом у клиента переехал в другую подсеть в локалке, и начались проблемы с постоянным падением туннеля.

★★★★★

Последнее исправление: Axon (всего исправлений: 2)
← apt-listchanges segmentation fault
Проверка пары логин/пароль на IP телефонах Yealink, CISCO →

Раньше всё работало как надо, но потом у клиента переехал в другую подсеть в локалке

И другая подсеть внезапно пересекается с роутами выдаваемыми openvpn сервером?

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

В принципе, подсеть-то даже и не поменялась, только хабов на пути до коммутатора меньше стало. 

$ ip route sh
0.0.0.0/1 via 10.9.0.5 dev tun0
default via 192.168.1.1 dev br0 src 192.168.1.72 metric 203
10.9.0.0/24 via 10.9.0.5 dev tun0
10.9.0.5 dev tun0 proto kernel scope link src 10.9.0.6
128.0.0.0/1 via 10.9.0.5 dev tun0
$VPN_SERVER_IP via 192.168.1.1 dev br0
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.72 metric 203

Axon ★★★★★
() автор топика
Последнее исправление: Axon (всего исправлений: 2)
Ответ на: комментарий от Axon

Странно. Такого не должно быть т.к. есть строка 

$VPN_SERVER_IP via 192.168.1.1 dev br0
Хорошо бы убедиться, что это строка не исчезает.

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

Нужно понять какая !@#$%^&* убирает этот маршрут.

А там на br0 адрес статиком или dhcp ?

Смысл в том, что кто-то делает down/up br0, а при этом теряются все маршруты через этот интерфейс.

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

Ищи способ предотвращения down/up если нет смены адреса интерфейса. Возможно другой dhcp-клиент ведет себя менее ублюдочно.

Либо нужно найти способ восстановления машрута. IMHO запустив zebra/quagga можно прописать этот маршрут статиком и оно восстанавливало бы его.

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

Да можно и через тот же netctl маршрут прописать. К сожалению, проверю только в понедельник, так как в выходные связь с хостом через злополучный VPN...

Axon ★★★★★
() автор топика
Последнее исправление: Axon (всего исправлений: 1)
Ответ на: комментарий от vel

Попробовал вручную рестартнуть профиль через netctl, проблема воспроизвелась. Прописал в профиле маршрут вручную, рестартнул ещё раз, и туннель поднялся даже без рестарта демона. Похоже, проблема решена.

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

А, нет, ни фига. Всё равно маршрут пропадает. Видимо, при отвале связи не происходит перезапуска профиля netctl.

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

А вот смена DHCP-клиента с dhcpcd на dhclient действительно помогла. Интересно, почему.

Axon ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← apt-listchanges segmentation fault
Admin
Проверка пары логин/пароль на IP телефонах Yealink, CISCO →