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)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.