ip route или почему не пингуется с ключиком -I (Так пингуется,а так не пингуется! В чём разница?)

[Spider84]

Всем привет.

Имею несколько "источников" интернета. И нужно распределить трафик как мне нужно.
Немного о том как это у меня выглядит:
есть ppp0 через него прокинут tap0 с локальным адресом 10.2.0.2 и default gw 10.2.0.1.
за ppp0 тоже интернет.

таблица роутинга примерно такая:

Код: Выделить всё

# route -n
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
10.64.64.64     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
<ip-of-ovpn-server>  0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.2.0.0        0.0.0.0         255.255.0.0     U     0      0        0 tap0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0

и вот так

Код: Выделить всё

# ip rule list
0:    from all lookup local
32764:    from 10.2.0.2 lookup VPN
32765:    from 10.218.176.197 lookup PPP
32766:    from all lookup main
32767:    from all lookup default

Код: Выделить всё

# ip route list table PPP
default dev ppp0  scope link

Код: Выделить всё

# ip route list table VPN
default via 10.2.0.1 dev tap0

таком варианте всё работает.
Я специально убрал основной шлюз.
Теперь я хочу пропинговать например 4.2.2.2 через ppp0 делаю для этого:

Код: Выделить всё

ping 4.2.2.3 -I ppp0

и получаю пинги
Далее тоже самое но через tap0

Код: Выделить всё

ping 4.2.2.3 -I tap0

получаю No route to host
но если сделать так:

Код: Выделить всё

route add -host 4.2.2.3 gw 10.2.0.1 dev tap0

и выполнить

Код: Выделить всё

ping 4.2.2.3

то пинги пойдут через tap0 и уже появился route to host

Почему так?

[sash-kan]

получаю No route to host

нет маршрута через этот интерфейс. см.:
$ ip r sh dev tap0

[Spider84]

Код: Выделить всё

$ ip r sh dev tap0
10.0.0.0/24  proto kernel  scope link  src 10.0.0.10

что не так?
по сравнению с ppp0:

Код: Выделить всё

$ ip r sh dev ppp0
10.64.64.64  proto kernel  scope link  src 172.19.1.55
<ip-of-ovpn-srv>  scope link

[sash-kan]

давайте определимся, что именно вас интересует.
1. почему наличествует ответ no route to host, а не destination host unreachable?
2. почему наличествуют ответы на команду
$ ping 4.2.2.3 -I ppp0
?
3. почему нет ответов без маршрута, но наличествуют ответы после добавления маршрута?

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

[Spider84]

3. почему нет ответов без маршрута, но наличествуют ответы после добавления маршрута?
на второй и третий ответы очевидны.

С третим не понимаю. Ведь роутинга как такогового для 4.2.2.3 нет ни туда ени сюда. Его default вообще нет. но при этом пинг через -I ppp0 ходит, а через -I tap0 нет. Почему так?

[sash-kan]

пинг через -I ppp0 ходит

потому что второй конец туннеля знает, что делать с icmp-пакетами, имеющими адрес назначения 4.2.2.3 и адрес источника, который вы можете посмотреть tshark-ом.

через -I tap0 нет

потому что второй конец туннеля не знает, что делать с icmp-пакетами, имеющими адрес назначения 4.2.2.3 и адрес источника, который вы можете посмотреть tshark-ом.

[Spider]

Оживим темку?

Всё работало до поры до времени. Теперь снова поднимаю такую штуку и она не работает.
ip route add default via 10.0.0.1 dev tap0 table OVPN
ip rule add from 10.0.0.164 table OVPN

так вот с той стороны видно следующее при попытке пинговать ya.ru:
19:50:51.612806 arp who-has 77.88.21.3 tell 10.0.0.164
19:50:52.621878 arp who-has 77.88.21.3 tell 10.0.0.164
19:50:53.621969 arp who-has 77.88.21.3 tell 10.0.0.164
19:50:54.632498 arp who-has 77.88.21.3 tell 10.0.0.164

когда ожидалось:
19:52:10.119753 IP 10.0.0.164 > 77.88.21.3: ICMP echo request, id 3414, seq 1, length 64
19:52:10.152019 IP 77.88.21.3 > 10.0.0.164: ICMP echo reply, id 3414, seq 1, length 64
19:52:11.118869 IP 10.0.0.164 > 77.88.21.3: ICMP echo request, id 3414, seq 2, length 64
19:52:11.151572 IP 77.88.21.3 > 10.0.0.164: ICMP echo reply, id 3414, seq 2, length 64


Что не так?

[sash-kan]

10.0.0.164 — за каким интерфейсом какой машины этот адрес закреплён?

[Spider]

10.0.0.164 — за каким интерфейсом какой машины этот адрес закреплён?

eth0 - 10.0.254.37 (gw должен быть 10.0.254.1 )
eth0:0 - 10.0.255.1
tap0 - 10.0.0.164 (gw должен быть 10.0.0.1 )

[sash-kan]

Spider
вы не ответили на вопрос.
хорошо, сконкретизирую.
как я понял, у вас есть openvpn-сервер и есть openvpn-клиент.
покажите вывод
$ ip a; ip r sh ta all
и там и там. после поднятия туннеля, естественно.

[Spider]

я сейчас не там...
Но ситуация такая, всё что я привёл выше это для клиента.
на сервере
eth0 - динамический ip
eth1 - 192.168.0.1/24
tap0 - 10.0.0.1/24
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

[sash-kan]

спрашиваю про одно, получаю ответ про другое.
попробуем ещё разок, последний.

так вот с той стороны видно следующее при попытке пинговать ya.ru:
19:50:51.612806 arp who-has 77.88.21.3 tell 10.0.0.164
19:50:52.621878 arp who-has 77.88.21.3 tell 10.0.0.164
19:50:53.621969 arp who-has 77.88.21.3 tell 10.0.0.164
19:50:54.632498 arp who-has 77.88.21.3 tell 10.0.0.164

на каком из интерфейсов какой из машин получена такая информация? и на какой машине выполнялась команда ping (подозреваю, что на клиенте)?

[Spider]

говорю же что я не там где эта машина, а ехать туда из-за таблицы роутинга накладно...
ip a по памяти восстановил. Что другое то получил?

Это на tap0 сервера.
да, пинг был такой:
ping ya.ru -I tap0
на клиенте.

[sash-kan]

говорю же что я не там где эта машина, а ехать туда из-за таблицы роутинга накладно...

отлично. но вы хотя бы рядом с другой машиной. как я понимаю, openvpn-сервером. верно?
я у вас попросил вывод
$ ip a; ip r sh ta all
после поднятия туннеля.
к той машине, которая рядом с вами, надеюсь, не очень накладно добираться?
и информация про proxy_arp не помешает:
$ ls /proc/sys/net/ipv4/conf/*/proxy_arp
$ cat /proc/sys/net/ipv4/conf/*/proxy_arp

[Spider]

да обе они они там в одной комнате....
proxy_arp везеде 0, это я и так скажу. Я это смотрел.

Ну придётся ехать...
А можно вообще сказать на что смотреть хотите? А не тупо говорить сделай то сделай это.
Просто я кучу HOW-TO и манов перечитал за этит 2 года борьбы с этим, и кучу всего повидал.
И блин каждый раз что-то новое вылазит...
На этот раз ваще с логикой не стыкуется.

[sash-kan]

А можно вообще сказать на что смотреть хотите?

на вывод
$ ip a; ip r sh ta all
на обоих машинах.
и пытаться понять, что же у вас там неправильного.

p.s. когда будете «там», убедитесь, что та самая команда ping, выданная на клиенте, всё ещё порождает именно такие arp-запросы и именно на интерфейсе tap0 сервера.