Не открываются/не пингуются сайты OPENVPN

nslookup google.com 8.8.8.8

Что возвращает?

Server 8.8.8.8 Address 8.8.8.8#53

Non-authoritative answer: name google.com address 216.58.207.238

Ну значит проверяй какой DNS сервер указан в настройках.

/etc/resolv.conf.

Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

# DO NOT EDIT THIS FILE BY HAND — YOUR CHANGES WILL BE OVERWRITTEN

nameserver 77.88.8.8

nameserver 77.88.8.1

search openstacklocal

На этих IP адресах нет DNS сервера, прописывай google`овский.

Ну и выучи разметку lorcode, ссылка на неё указана в форме помещения сообщений на форум, выше кнопок «Поместить», «Предпросмотр», «Отмена».

Да и кнопку «Предпросмотр» используй перед отправкой сообщения.

На этих адресах публичные резолверы Яндекса.

Да, я неправильно ввёл команду. Уже посмотрел что это DNS от Yandex.

А кто у нас клиент?

Не получается! Я поднимал на этом серваке etherSoft VPN и не менял там DNS

Debian

cat /etc/resolv.conf с клиента покажите.

nameserver 192.168.0.1

А 192.168.0.1 в курсе, что он nameserver? А OpenVPN случайно не переопределяет маршрут к 192.168.0.0/24? Что показывает dig yandex.ru @192.168.0.1?

Предполагаю что это адрес вашего роутера, а ovpn клиент не меняет/или-ему-не-пушат адреса dns с сервера.
Для разборок, в студию, конфиги сервера и клиента +

ip a
ip r s 

root@debian:/home/deb# ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

valid_lft forever preferred_lft forever

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

link/ether 08:00:27:bb:50:2b brd ff:ff:ff:ff:ff:ff

inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3

valid_lft 61798sec preferred_lft 61798sec

inet6 fe80::a00:27ff:febb:502b/64 scope link

valid_lft forever preferred_lft forever

42: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100

link/none

inet 10.8.0.6 peer 10.8.0.5/32 scope global tun0

valid_lft forever preferred_lft forever

inet6 fe80::57d8:d484:e7df:aa86/64 scope link flags 800

valid_lft forever preferred_lft forever

root@debian:/home/deb# ip r s

0.0.0.0/1 via 10.8.0.5 dev tun0

default via 10.0.2.2 dev enp0s3 proto static metric 100

10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100

10.8.0.1 via 10.8.0.5 dev tun0

10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6

128.0.0.0/1 via 10.8.0.5 dev tun0

169.254.0.0/16 dev enp0s3 scope link metric 1000

1**.4*.3*.*** via 10.0.2.2 dev enp0s3

сервер

port 1194

proto udp

dev tun

ca ca.crt

cert server.crt

key server.key # This file should be kept secret

dh dh2048.pem

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt"

push «redirect-gateway def1 bypass-dhcp»

push «dhcp-option DNS 208.67.222.222»

push «dhcp-option DNS 208.67.220.220»

keepalive 10 120

tls-auth ta.key 0 # This file is secret

key-direction 0

cipher AES-128-CBC # AES

auth SHA256

comp-lzo

user nobody

group nogroup

persist-key

persist-tun

status openvpn-status.log

verb 3

;<<>> DiG 9.10.3-P4-Debian <<>> yandex.ru @192.168.0.1

;; global options: +cmd

;; connection timed out; no servers could be reached

client

dev tun

proto udp

remote 1**.4*.3*.*** 1194

resolv-retry infinite

nobind

user nobody

group nogroup

persist-key

persist-tun

#ca ca.crt

#cert client.crt

#key client.key

remote-cert-tls server

comp-lzo

verb 3

cipher AES-128-CBC

auth SHA256

key-direction 1

script-security 2

up /etc/openvpn/update-resolv-conf

down /etc/openvpn/update-resolv-conf

Вот и вопрос. Откуда 192.168.0.1 ? Сами прописали или с dhcp полученное? Если оно, и без ovpn все так же работает, гуглите на тему замены dns при старте ovpn клиента. Тема на самом деле старая, и другому ТС тут недавно подсказывали, только он почему-то слился.
«Вобчем» проблема только в resolv.conf, руками пропишите например 8.8.8.8 и все заробит. Но это разово.

Заработало)) Спасибо

Буду теперь искать как автоматизировать этот процесс

К кач-ве рекомендации. Ищите по версии дистра. А то все постоянно меняют, и вы опять потратите лишнее время пробуя «не ваши варианты».

Благодарю

Тут как раз не за что. Знал бы все варианты с NM &etc помог бы конкретным решением, но увы, не мое.

прибить гвозьдями 8.8.8.8 навсегда и не мучиться

sudo chattr +i /etc/resolve.conf

а еще лучше dnsmasq + dnscrypt-proxy поставить вне зависимости от openvpn

Не кошерно. И не всегда верно. Иногда бывают случаи локальных провов, которые используют всякие pptp/l2tp и для сервера (я про точку подключения, типа ppptp.myprov.ru) отдают ip только через свой днс сервер.

Раньше все делалось и делается up/down скриптами. Только вот говорят их теперь чуть больше чем много, и так правильнее.

Ну точку подключения на крайний адрес можно в hosts. Кроме того скорее всего pptp-туннель не комп а роутер делает.

А вообще в наш век цензуры и пакета Яровой слать DNS-запросы чёрти куда это моветон... Поэтому хватать «провайдерский» DNS - да ну нафиг...

Ну точку подключения на крайний адрес можно в hosts.

Не прокатит. Адрес может меняться.

Кроме того скорее всего pptp-туннель не комп а роутер делает.

А если этот комп и есть роутер?

А вообще в наш век цензуры и пакета Яровой слать DNS-запросы чёрти куда это моветон... Поэтому хватать «провайдерский» DNS - да ну нафиг...

8.8.8.8 может оказаться провайдерским, некоторые так делают.
Но речь не об этом. Прибивать гвоздями 8.8.8.8 все-таки не очень красиво, в то время как можно все сделать по уму. До кучи вариант с ноутом и всякими гостевыми wifi с web авторизацией, они могут просто не пропустить 8.8.8.8.

В целом согласен что возможны разные ситуации...

У меня просто это редкость, и я знаю что всегда могу поправить resolv.conf руками на крайний случай... Поэтому прибил и забыл ;)