Попробуй ip адрес пинговать, возможно проблема в DNS

Пробовал, проблема не в DNS. Пакеты в принципе не хотят идти, или не знаю как правильно это выразить :(

тогда нужен дамп с основного интерфейса и с тунеля, а лучше сам wireshark-ом посмотри куда трафик ходит, а куда отказывается

Если честно, не совсем понял. Я потыкал tcpdump на Wi-Fi интерфейс и с tun0 - выхлопа нет ни там, ни там (при подключенном VPN). Но, думаю, я сделал что-то не то.
Наблюдение - пингуется только IP VPN-сервера, никакой другой не хочет. С чем такое может быть связано?

Попробуй другой сервер

такой микрокаммент, вкину:

я тож заметил, и даже чуть раньше чем 2-нед. давности проблему с шифрованием, но у меня несколько [rand] конфиг, с мелкими машинками по хвостам, у меня это выливается, к довольно скоростному перебору подключений (где-то 3-4 захода), что я думаю было-бы критично на серьёзном файлообе.

От VPN-сервера не зависит вообще, проявляется при подключении к любому.

Похоже что трафик не отправляется в впн, в впн конфигах

push «redirect-gateway def1»

написано?

Нет, вписал в конец клиентского (сервера сторонние) - бесполезно. Но блин, ещё не так давно всё работало, и просто перестало. На втором компьютере всё прекрасно подключается, перестало именно с моей системы. Ничего не понимаю, даже не ясно, куда копать.
Приложу тут выводы ip route. Без VPN:

default via 192.168.100.1 dev wlp3s0b1  metric 303
192.168.100.0/24 dev wlp3s0b1  proto kernel  scope link  src 192.168.100.7  metric 303

default via 10.8.0.9 dev tun0  proto static  metric 50
default via 192.168.100.1 dev wlp3s0b1  proto static  metric 600
10.8.0.1 via 10.8.0.9 dev tun0  proto static  metric 50
10.8.0.9 dev tun0  proto kernel  scope link  src 10.8.0.10
10.8.0.10 dev tun0  proto kernel  scope link  src 10.8.0.10  metric 50
X.X.X.X via 192.168.100.1 dev wlp3s0b1  proto static  metric 600
192.168.100.0/24 dev wlp3s0b1  proto kernel  scope link  src 192.168.100.7  metric 600

default via 10.8.0.9 dev tun0  proto static  metric 50
default via 192.168.100.1 dev wlp3s0b1  proto static  metric 600

Проблема здесь. Убери один дефолтный маршрут (я так понимаю, второй, который через вай-фай, нужно прибить) и всё заработает.

Убрал, не заработало :(

Может в фаерволле дело? Покажи вывод iptables-save, ну и ip rule заодно.

iptables-save ничего не выводит, ip rule:

0:	from all lookup local 
32766:	from all lookup main 
32767:	from all lookup default

root-доступ у серверу есть?

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

Тогда в tun0 пакеты должны ходить. Попробуй запустить tcpdump с опцией -n на обоих интерфейсах, с резолвингом отображение может сильно задерживаться.

Нет, сервер не мой. Но дело точно не на серверной стороне.
Запустил tcpdump на интерфейсе Wi-Fi и на tun0. Куча всего и там, и там - не знаю, на что именно смотреть. При этом пинг никуда не идёт, ничего не открывается, Интернета нету :(

Попробуй сделать

ip route flush cache
echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter

Не помогло.
А вывод tcpdump с огромной скоростью увеличивается, но, в целом, однотипен. В общем виде:

IP 10.8.0.10.XXXXX > X.X.X.X.XXXXX: UDP, length X

А если, пока впн работает, выполнить

ip route del 192.168.100.0/24 metric 600 && ip route add 192.168.100.0/24 dev wlp3s0b1
ip route del X.X.X.X metric 600 && ip route add X.X.X.X via 192.168.100.1

Нет, не работает.

Пфф :(. А после ip route flush cache? Покажи еще раз вывод ip route и ip route get X.X.X.X.

После flush и Ваших манипуляций из предыдущего сообщения, ip route:

default via 10.8.0.5 dev tun0  proto static  metric 50 
default via 192.168.100.1 dev wlp3s0b1  proto static  metric 600 
10.8.0.1 via 10.8.0.5 dev tun0  proto static  metric 50 
10.8.0.5 dev tun0  proto kernel  scope link  src 10.8.0.6 
10.8.0.6 dev tun0  proto kernel  scope link  src 10.8.0.6  metric 50 
X.X.X.X via 192.168.100.1 dev wlp3s0b1 
192.168.100.0/24 dev wlp3s0b1  scope link

X.X.X.X via 192.168.100.1 dev wlp3s0b1  src 192.168.100.7 
    cache 

192.168.100.1 и 10.8.0.1 пингуются? tcpdump на tun0 показывает такой же поток, как и раньше? Никак не могу понять, в чем же дело...

Дело немного сдвинулось с мёртвой точки. Случайно набрёл на один фришный VPN-сервис, решил попытаться к нему подключиться. И всё на несколько минут заработало. Но спустя эти несколько минут - начинается та же лажа. Выхлоп ip route не меняется.

Может, дело в NetworkManager'е? Я правильно понимаю, что он используется для подключения к wifi? Попробуй отключить его (и сервис тоже - service network-manager stop) и подключиться wpa_supplicant'ом. Потом так же вручную запускай openvpn. wpa_supplicant запускать так:

wpa_supplicant -c config.conf -i wlp3s0b1 -B

network={
        ssid="YOUR_SSID"
        key_mgmt=WPA-PSK
        psk="your_pass"
}

Я пробовал отключать NM, подключался к Wi-Fi через netctl, стартовал VPN вручную - бестолку, одна и та же фигня.

Окей, попробуем отступить на пару шагов назад. Ты можешь восстановить то, что было на момент этого коммента, и сделать то, что указано здесь?

Так, оба адреса пингуются; в tun0 поток есть.

Т.е. точно такие же пакеты?

IP 10.8.0.10.XXXXX > X.X.X.X.XXXXX: UDP, length X

Нет, 10.8.0.10 сменилось на 10.8.0.6, а X.X.X.X в выхлопе от tun0 - какие-то другие адреса, и вообще много разной другой фигни, кроме этой формы.

Понятно, я все это время держался за неверное предположение :D . Думал, что каким-то образом возникает routing loop.

Попробуй добавить mssfix 1000 в конфиг openvpn. И проверяй не только пингом, попробуй выполнить nc -nv 93.158.134.3 80, и попробуй открыть какую-нибудь страницу в браузере.

mssfix 1450 есть в конфиге. Браузером также проверяю - бесполезно, не работает. В любом случае, спасибо большое за попытку помочь. Склоняюсь к мысли о смене дистрибутива или переустановки своего текущего Arch :( Очень не хочется этого делать, но другого решения проблемы с VPN я не вижу.

Переустановка может и не помочь, это же не винда. Ты все-таки попробуй заменить 1450 на 1000, ничего не теряешь ведь.

Заменил - не помогло.
Да, переустановка может и не помочь, да и не хочется мне уже хорошо подпиленную под себя систему ломать. Но блин... Всё же работало. Возможно, какое-то обновление что-то сломало... Не знаю :(