[бред][openvpn] левые arp-запросы в туннель

Когда ты обращаешь внимание что трафик не туда побежал что говорит " ip r g 192.168.12.1" ?

>убунта пытается посылает arp who-has 192.168.12.1(это не гейт, но гейт посылает next hop на этот хост) в интерфейс openvpn где таких адресов отродясь не было

в таких случаях надо делать ip route flush cache и затем сразу ip route get 192.168.12.1 чтобы выяснить - все ли ок с таблицей маршрутов.

Насчет MTU - можешь не париться - в данном случае пакеты ИСХОДЯЩЕГО с сервера трафика разберутся и соберутся верно. Если нужно через сервак делать forward, а вышестоящий провайдер/сетка не пропускает MTU нужного размера, то гугли как использовать TCPMSS(проблему заметишь сразу tcpdump-ом по сообщения ICMP fragmentation needed с вышестоящих хостов)

Tok, Pinkbyte спасибо за помощь. Вечером как вернусь в отель обязательно проверю. По ip route list проблем не было, но может что-то там хитро закэшировалось...(всё равно не понимаю КАК). Но подозрения о кэше оправданы потому что ребут иногда помогал в этой проблеме.

по ip route show проблема не всегда видна. Надо зрить в ip route get - там будет маршрут, который выбрало ядро и причина выборка(cached как минимум намекнет, что маршрут из кеша, а в ip route show его может и не быть)

Ты прав, есть вот такая байда:

# ip r g 172.16.0.1
172.16.0.1 via 192.168.12.1 dev vpn  src 172.16.0.109 
    cache <redirected>  ipid 0x4508

Только откуда она? Маны показывают что <redirected> случается от ICMP, однако снифер молчит. Т.е. я делал ip r f cache, открывал окно снифера, делал ping 172.16.0.1 и смотрел на снифер, там на счёт icmp глухо.

ip r monitor показывает 192.168.12.1 dev vpn FAILED Кстати, что такое ipid(который меняется после сброса кэшей)? Оно как-то с RTNETLINK_HAVE_PEERINFO, судя по сырцам, связано. Я даже блочил icmp, не помогает.

У меня есть подозрения что ip route flush cache не все кэши сбрасывает. Это бы всё объяснило, т.к. пока туннель не поднялся пакеты падают в wlan0 и роутер шлёт icmp redirect. Ну или какой-то роутинговый демон что-то страшное делает, но ничего такого не запущено.

Копаю в сторону ip neigh, ip link итп. Кстати, ip link show показывает для туннеля вместо статуса UP статус UNKNOWN.

# ip r show cache
172.16.0.1 from 172.16.0.109 via 192.168.12.1 dev vpn
    cache <redirected>  ipid 0x498b
local 127.0.0.1 from 127.0.0.1 dev lo
    cache <local>
local 172.16.0.109 dev lo  src 172.16.0.109
    cache <local>  ipid 0x64e2
79.91.228.18 from 192.168.12.235 via 192.168.12.1 dev wlan0
    cache  ipid 0x30fb rtt 3.031s rttvar 3.119s ssthresh 7 cwnd 9
local 192.168.12.235 from 79.91.228.18 dev lo  src 192.168.12.235
    cache <local>  iif wlan0
172.16.0.1 from 172.16.0.109 via 192.168.12.1 dev vpn
    cache <redirected>  ipid 0x498b
local 172.16.0.109 from 172.16.0.1 dev lo  src 172.16.0.109
    cache <local,src-direct>  iif vpn
local 192.168.12.235 from 192.168.12.1 dev lo  src 192.168.12.235
    cache <local,src-direct>  iif wlan0
192.168.12.1 from 192.168.12.235 dev wlan0
    cache  ipid 0x498a rtt 5.521s rttvar 7.384s ssthresh 5 cwnd 8
172.16.0.1 via 192.168.12.1 dev vpn  src 172.16.0.109
    cache <redirected>  ipid 0x498b

Кстати, ip link show показывает для туннеля вместо статуса UP статус UNKNOWN.

так, это, похоже, не тот UP о котором я думаю, т.е. это не состояние nic а состояние линка или типа того.

Да, поигрался и понял что маршрут реально «залипает». Стоит только пингануть тунельный гейт раньше чем поднимется туннель и запрос улетает во внутреннюю сетку отеля, оттуда гейт радостно шлёт icmp redirect(вообще дебилизм, по dhcp гейт 192.168.12.2, но он всех через icmp redirect посылает в 192.168.12.1). И после поднятия туннеля ведро всё равно пытается слать пакеты в сторону 192.168.12.1 . Есть идеи как бороться с этим? Кроме как ребутаться.

net.ipv4.conf.all.accept_redirects=0 и ипись оно всё конём.

а, редиректы, да. Это зло...

Прикинь, маршруты сохраняются до перезагрузки. Т.е. никакими ip r flush all|cache мне не удалось избавится от них. Я принёс ноут в другую сеть, а маршрут всё равно сам появлялся. Прошёлся по /proc в поисках рычагов на это дело, но не нашёл ничего подходящего. Пришлось ребутаться. Имхо баг.

Всё хуже. Я только что провёл 6 часов в попытках вынести из кэша маршрут на удалённый хост, который заворачивается ядром на loopback.

Откуда он взялся? - хз. После холодного старта в кэше его нет и маршрут отрабатывает верно - через default gw. Но после нескольких тычков пингом и telnet'ом появляется маршрут в кэше и его уже никак не вынести. ip route flush вроде всё чистит, но при первом же пакете на этот хост - всё возвращается.

net.ipv4.conf.all.accept_redirects=0 не помог.

Решилось откатом на 2.6.38 ядро. Час - стабильно. Посмотрим завтра.

net.ipv4.conf.all.accept_redirects=0 не помог

как оказалось, мне тоже не помог :(. Я покопался в сырцах, но безуспешно. Дальше ковырять времени нет.

Попробуй на фаерволе заблочить icmp redirect.

Да, когда я писал что блокирование icmp не помогает я имел в виду что оно post factum не помогает.

Я добавлял
-I INPUT -j DROP
-I FORWARD -j DROP
reboot
ping на хост
хост в кэше на lo)

Впечатление, что у меня его ядро вешает как direct на lo.

В любом случае откат на ядро ветки 2.6 помог.

А какое до этого ведро было?

У меня на убунту 11.10 такой косяг с ведром 3.0

3.0
В федоре оно с нумерацией 2.6.40

Не ты запостил?

http://permalink.gmane.org/gmane.linux.network/211710

Нет, но глядя на этот и твой пост решил, что походу бага и попробовал откатить ядро.