LINUX.ORG.RU

OpenVPN не работает. Возможно, устаревший конфиг?

 ,


0

1

Вот такой вот конфиг дал провайдер, вместе с ключами и сертификатами. На самом деле, конфигов больше одного, и со многими пробовал: не работает. Скорее всего, устаревший конфиг(ибо что ещё может быть?). Ядро дефолтное арчевское, т.ч. поддержка всего там есть.

client

#connect to VPN server
remote 188.64.170.189 443
proto tcp

#socket buffer size
sndbuf 262144
rcvbuf 262144

#DNS server to use
dhcp-option DNS 8.8.8.8

#remove to use your ISP's gateway
redirect-gateway def1

#your access keys
ca in_ca.crt
cert in_<my_id>.crt
key in_<my_id>.key
ns-cert-type server

#cipher to use
cipher AES-256-CBC

#use virtual interface 'tap'
dev tap

#keep trying indefinitely to resolve the host name of the OpenVPN server.
resolv-retry infinite

#most clients don't need to bind to a specific local port number.
nobind

#try to preserve some state across restarts
persist-key
persist-tun

#enable compression on the VPN link
comp-lzo

#set log file verbosity.
verb 4

#silence repeating messages
mute 20
traceroute: во всех тестируемых случаях выдаёт единственный hop: 10.119.96.38
ping: потери пакетов 100%
dig и nslookup работают нормально. Смотрел через wireshark: DNS передаётся в открытом виде. Наверное, так и должно быть.

Вот логи: https://pastebin.com/6rX6xpUK

P.S. Видимо, проблема где-то на моей стороне... Пытался к другому VPN подключиться через OpenVPN, результат тот же самый.

★

Последнее исправление: letni (всего исправлений: 4)

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

fehhner ★★★★★
()

Я не думаю, что у тебя в папке лежат файлы с этими именами:

cert in_<my_id>.crt
key in_<my_id>.key

Скорее, там другое название с заменённым айди. И укажи вручную их.

fehhner ★★★★★
()
Последнее исправление: fehhner (всего исправлений: 1)
Ответ на: комментарий от fehhner

Само собой, я сам заменил. Кстати, пробовал на убунту с livecd — тоже не работает. Хз ваще

letni ★
() автор топика
Ответ на: комментарий от fehhner

Заметил одну такую интересную вещь: при НЕ использовании https всё работает нормально. Адреса пингуются, сайты(example.com, например) грузятся. А как только я получаю https ответ или отправляю запрос — интернет отваливается и приходится перезагружать VPN.

Когда у меня открыт какой-то сайт вроде ЛОР'а, где, я как понимаю, в фоне происходит обмен данными, то я успеваю сделать 1-2 запроса на пинг и интернет отваливается. Мне кажется, именно поэтому у меня сложилось вчера впечатление, что ничего не работает, кроме запроса на DNS. А по факту, не работает только HTTPS.

Буду дальше разбираться...

letni ★
() автор топика
Ответ на: комментарий от letni

При «падении» интернета пингуются только 10.119.96.38 и 188.64.170.189(из всех ip, которые я пинговал):

>ping 10.119.96.38
PING 10.119.96.38 (10.119.96.38) 56(84) bytes of data.
64 bytes from 10.119.96.38: icmp_seq=1 ttl=64 time=0.056 ms
64 bytes from 10.119.96.38: icmp_seq=2 ttl=64 time=0.046 ms
64 bytes from 10.119.96.38: icmp_seq=3 ttl=64 time=0.047 ms
64 bytes from 10.119.96.38: icmp_seq=4 ttl=64 time=0.049 ms
64 bytes from 10.119.96.38: icmp_seq=5 ttl=64 time=0.048 ms
64 bytes from 10.119.96.38: icmp_seq=6 ttl=64 time=0.044 ms
>ping 188.64.170.189
PING 188.64.170.189 (188.64.170.189) 56(84) bytes of data.
64 bytes from 188.64.170.189: icmp_seq=1 ttl=57 time=87.7 ms
64 bytes from 188.64.170.189: icmp_seq=2 ttl=57 time=88.6 ms
64 bytes from 188.64.170.189: icmp_seq=3 ttl=57 time=87.8 ms
64 bytes from 188.64.170.189: icmp_seq=4 ttl=57 time=87.4 ms
Эти адреса был в логах подключений https://pastebin.com/PTy5HUBi(время сбилось, т.к. сижу с livecd)

traceroute вообще без результата... просто звездочки идут.

letni ★
() автор топика
Последнее исправление: letni (всего исправлений: 1)

Вот вывод route -n:

Без openvpn:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    600    0        0 wls1
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wls1
192.168.1.0     0.0.0.0         255.255.255.0   U     600    0        0 wls1
С openvpn:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.119.64.1     128.0.0.0       UG    0      0        0 tap0
0.0.0.0         192.168.1.1     0.0.0.0         UG    600    0        0 wls1
10.96.0.0       0.0.0.0         255.224.0.0     U     0      0        0 tap0
128.0.0.0       10.119.64.1     128.0.0.0       UG    0      0        0 tap0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wls1
188.64.170.189  192.168.1.1     255.255.255.255 UGH   0      0        0 wls1
192.168.1.0     0.0.0.0         255.255.255.0   U     600    0        0 wls1

Вывод одинаковый как при рабочем openvpn, так и при «отвалившемся».

Но стоит еще раз упомянуть, что при «отвалившемся» я всё же могу успешно пинговать, походу, внутренние адреса моего vpn-провайдера.

letni ★
() автор топика

Проблема в размере, а не в HTTPS. Это точно

Интернет «отваливается» только при загрузке больших страниц: https://pastebin.com/FEf3LK35

letni ★
() автор топика

Провел пару тестов. В принципе, каких-то закономерностей, кроме ранее обнаруженных, найти не удалось. Иногда грузится, иногда дропается соединение. Но всё же, чем больше размер загружаемого файла, тем выше вероятность, что дропнется. Сложно провести четку границу, но я бы выделил зону в 30-40.

Здесь не всё, но основное: https://pastebin.com/ePGACpC8

letni ★
() автор топика

Сейчас зашел с другого компьютера, и уже по проводному подключению. Связь вроде также плохая, но немного лучше.

Удалось посмотреть немножко в hd видео, а потом опять отвалилась. Второй раз мучаться и поднимать смысл нет. В любом случае, качество соединения плохое.

letni ★
() автор топика
Ответ на: комментарий от fehhner

В общем, купил я vpn у prostovpn. Там шло 2 конфига: для tcp и udp. С tcp проблема была такая же, как описано выше. Я уже расстроился. Включил udp и всё заработало как надо.

Я не знаю почему это, возможно как-то с роутером связано. Было бы интересно узнать

letni ★
() автор топика

И hidemy vpn мне удалось починить =D

Нужно «proto tcp» заменить на «proto udp» и с remote удалить 443 порт, оставив только адрес.
___
Только теперь осталась небольшая проблема: при отправке пакетов, они не всегда доходят. Вот сейчас я этот комментарий, например, отправил без проблем, а повторная отправка после корректирования невозможна — пришлось отключать. Видимо, по какой-то причине пакеты не дошли.

И это проблема не конкретно hidemy, ибо я уже на наскольких провайдерах сравнивал.

letni ★
() автор топика
Последнее исправление: letni (всего исправлений: 1)
Ответ на: комментарий от letni

1. определил через ping максимальный размер(1330 в моем случае)
2. ip link set dev wls1 up mtu 1330
3. ip link set dev tap0 up mtu 1330

Это делается уже после подключения

letni ★
() автор топика
Последнее исправление: letni (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему: топик перемещен в архив.