Но адрес то тыкаем не тот. Кто-то роуты не знает

причем на tun0 на клиенте имеет ip 10.0.0.2 и я его пингую

То есть пинг клиент/сервер работает с 10.0.0.1 на 10.0.0.2?

да

172.16.11.10 на клиенте или на сервере висит?

на клинете

на сервер 172.16.10.10

ip ro default via 192.168.19.254 dev ens32 proto dhcp metric 100 10.0.0.0/24 dev tun0 proto kernel scope link src 10.0.0.2 172.16.10.0/24 via 10.0.0.1 dev tun0 172.16.11.0/24 dev ens32 proto kernel scope link src 172.16.11.10 metric 100 192.168.10.0/24 via 10.0.0.1 dev tun0 192.168.19.128/25 dev ens32 proto kernel scope link src 192.168.19.132 metric 100

На сервере ip r get 172.16.11.10 что говорит при включенном туннеле?

вот с клиента

На клиенте тоже форвард включен?

ip r get 172.16.11.10 172.16.11.10 via 10.0.0.2 dev tun0 src 10.0.0.1 cache

На клиенте тоже форвард включен?

да

Меня ещё мту смутил в логе 1625

Зачем если можно дороже?)

Знаешь какие пары опасны?

Когда у кого-то горит

ip r get 172.16.11.10 172.16.11.10 via 10.0.0.2 dev tun0 src 10.0.0.1 cache

Окей, коннект есть, роуты вроде тоже есть. Tcpdump -i tun0 -n на клиенте, с сервера пингуем 172.16.11.10, смотрим что приходит

ip r get 172.16.11.10 172.16.11.10 via 10.0.0.2 dev tun0 src 10.0.0.1 cache

У вас 172.16.х.х адреса висят на интерфейсах которые публичные?

Знаешь какие пары опасны?

Говорят опасны па́ры по философии. Приводят к алкоголизму.

У вас 172.16.х.х адреса висят на интерфейсах которые публичные?

Да пофиг

Это условности же: паблик, приват

Ну вот, сам видишь

Это условности же: паблик, приват

Не пофиг, пакет по другому пойдет же, что за интерфейс ens32:0

Не пофиг, пакет по другому пойдет же, что за интерфейс ens32:0

Не, роуты честные

Если уж тестировать надо поднять dummy /32

И направить в них роуты

Сервер видит правильно куда слать. Клиент видит правильно куда слать

Если уж тестировать надо поднять dummy /32

чем :0 не годится ?

чем :0 не годится ?

Наверное годится, но у меня предрассудки

Mtu при пинге со штатными параметрами тоже не влияет пока он больше 64

Сделайте два дамми по сторонам и пустите пинг между ними через тоннель

Окей, коннект есть, роуты вроде тоже есть. Tcpdump -i tun0 -n на клиенте, с сервера пингуем 172.16.11.10, смотрим что приходит

ничего не говорит

а на вервере вижу в tun0

Не пофиг, пакет по другому пойдет же, что за интерфейс ens32:0

В линуксе роуты не на дырку вешаются, а на ядро. Там всё сложно короче, но ens32:0 канает

ничего не говорит

С сервера улетает, на клиент не прилетает в tun0?

tcpdump -i tun0 -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes 15:56:36.941695 IP 10.0.0.1 > 172.16.11.10: ICMP echo request, id 13587, seq 17, length 64 15:56:37.941726 IP 10.0.0.1 > 172.16.11.10: ICMP echo request, id 13587, seq 18, length 64 15:56:38.941716 IP 10.0.0.1 > 172.16.11.10: ICMP echo request, id 13587, seq 19, length 64 15:56:39.941711 IP 10.0.0.1 > 172.16.11.10: ICMP echo request, id 13587, seq 20, length 64

вот с сервера улетает

В линуксе роуты не на дырку вешаются, а на ядро. Там всё сложно короче, но ens32:0 канает

Я в курсе, но предпочитаю явно тестировать

вот с сервера улетает

На ens32 видите эти же пакеты?

То что они в тун0 не значит что они вышли в мир

tcpdump -n -i tun0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes

На ens32 видите эти же пакеты?

нет

нет

Ну то есть ядро их не выпустило получается в следующий интерфейс

гм

я на сервре не виду на eth0

получается он на внешку пакен не передает

получается он на внешку пакен не передает

Ну выходит что так

Конечный интерфейс на сервере это физический адаптер

Из него вылететь должно

да

конечно

вот и думаю

как так

Sysctl -a grep forward

grep rp_filter

Пайп на телефоне хз где :)

sysctl -a | grep forward net.ipv4.conf.all.forwarding = 1 net.ipv4.conf.all.mc_forwarding = 0 net.ipv4.conf.default.forwarding = 1 net.ipv4.conf.default.mc_forwarding = 0 net.ipv4.conf.eth0.forwarding = 1 net.ipv4.conf.eth0.mc_forwarding = 0 net.ipv4.conf.lo.forwarding = 1 net.ipv4.conf.lo.mc_forwarding = 0 net.ipv4.conf.tun0.forwarding = 1 net.ipv4.conf.tun0.mc_forwarding = 0 net.ipv4.ip_forward = 1 net.ipv4.ip_forward_use_pmtu = 0 net.ipv6.conf.all.forwarding = 0 net.ipv6.conf.all.mc_forwarding = 0 net.ipv6.conf.default.forwarding = 0 net.ipv6.conf.default.mc_forwarding = 0 net.ipv6.conf.eth0.forwarding = 0 net.ipv6.conf.eth0.mc_forwarding = 0 net.ipv6.conf.lo.forwarding = 0 net.ipv6.conf.lo.mc_forwarding = 0 net.ipv6.conf.tun0.forwarding = 0 net.ipv6.conf.tun0.mc_forwarding = 0

sysctl -a | grep rp_filter net.ipv4.conf.all.arp_filter = 0 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.arp_filter = 0 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.eth0.arp_filter = 0 net.ipv4.conf.eth0.rp_filter = 0 net.ipv4.conf.lo.arp_filter = 0 net.ipv4.conf.lo.rp_filter = 0 net.ipv4.conf.tun0.arp_filter = 0 net.ipv4.conf.tun0.rp_filter = 0

Default rp_filter в 0

sysctl -a | grep rp_filter net.ipv4.conf.all.arp_filter = 0 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.arp_filter = 0 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.eth0.arp_filter = 0 net.ipv4.conf.eth0.rp_filter = 0 net.ipv4.conf.lo.arp_filter = 0 net.ipv4.conf.lo.rp_filter = 0 net.ipv4.conf.tun0.arp_filter = 0 net.ipv4.conf.tun0.rp_filter = 0

И на всякий случай iptables -L -n -v

Мало ли что :)

Default rp_filter в 0

Оно не влияет И лучше в 2 выставлять всегда всё

Оно не влияет И лучше в 2 выставлять всегда всё

ну я кстати тоже за 2

И на всякий случай iptables -L -n -v

вообще iptabes выключен

Оно не влияет И лучше в 2 выставлять всегда всё

влияет

As of Kernel version 2.6.31 the highest value set in either the interface specific subtree or the all subtree will be effective setting. If we needed to disable rp_filtering, which uses a value of 0, then we would need to do this in the both in the interface specific key and the all key to ensure that there is not a higher value in any configuration key effecting the interface. The highest value becomes the effective value!

As of Kernel version 2.6.31 the highest value set in either the interface specific subtree or the all subtree will be effective setting. If we needed to disable rp_filtering, which uses a value of 0, then we would need to do this in the both in the interface specific key and the all key to ensure that there is not a higher value in any configuration key effecting the interface. The highest value becomes the effective value!

Это логика между all и interface specific Default это по сути темплейт для новых дырок

А если подумать, то инертными газами дышать тоже неудобно)

Причем засада в том, что до удушья не понимаешь что нечем дышать - ни запаха, ни вкуса.

самое забавное что клинет серверный ip пингует

На какую ось ставим VCSA? public poll Windows 2016 x64 bit – 5 👍👍👍👍👍👍👍 45% @dracon64, @xProtosx, DnB, @Kurtash08, Miroslav Ubuntu 14.04 – 5 👍👍👍👍👍👍👍 45% @ThePanaceya, @TarasChernev, @MAPKC, @ewcha, @Allowedusername SUSE 12 – 1 👍 9% @horseinthesky 👥 11 people voted so far.

vcsa это vcenter? или чо ваще

vcsa это vcenter? или чо ваще

VMware VCenter новый

чот странное.. там же вроде какой-то юниксовый эплаенс готовый замутили?

чот странное.. там же вроде какой-то юниксовый эплаенс готовый замутили?

он как оказалось ставится сверху на одну из этих осей

т.е он таки не самодостаточный ova образ, а точно так же разворачивается

веселуха

ну оно всегда было виндоус

щас бы в 21 веке пруфы требовать

Да решим на что ставить и развернём