LINUX.ORG.RU
Форум — General  

Перестал работать OpenVPN на VPS

 , , ,


0

4

Пару месяцев работал, и вдруг перестал. Конфиги не менялись, обновления вроде тоже не ставил. Хост ubuntu 16.04. Клиент подключается, но страницы не открываются.

Какие логи-то смотреть? В journalctl всё пучком.

Ответ на: комментарий от h578b1bde

Такого лога нет.
В server.conf у меня пусто в этом плане, видимо используется дефолт.
В openvpn-status.log тоже ничего криминального, да и вообще по сути ничего.

server.conf:

server 10.8.0.0 255.255.255.0
verb 3
key server-key.pem
ca ca.pem
cert server-cert.pem
dh dh.pem
keepalive 10 120
persist-key
persist-tun
comp-lzo
push "redirect-gateway def1 bypass-dhcp"
push "route 10.8.0.0 255.255.255.0"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
user nobody
group nogroup
proto udp
port 1194
dev tun1194

openvpn-status.log:
OpenVPN CLIENT LIST
Updated,Sat Jul  1 23:38:44 2017
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
GLOBAL STATS
Max bcast/mcast queue length,0
END

syslog:
Jul 01 23:24:42 vps ovpn-server[872]: ******:60197 TLS: Initial packet from [AF_INET]******:60197, sid=5f746d0e 1876c04d
Jul 01 23:24:42 vps ovpn-server[872]: ******:60197 VERIFY OK: depth=1, CN=OpenVPN-CA
Jul 01 23:24:42 vps ovpn-server[872]: ******:60197 VERIFY OK: depth=0, CN=OpenVPN-Client
Jul 01 23:24:42 vps ovpn-server[872]: ******:60197 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jul 01 23:24:42 vps ovpn-server[872]: ******:60197 WARNING: this cipher's block size is less than 128 bit (64 bit).  Consider using a --cipher with a larger block size.
Jul 01 23:24:42 vps ovpn-server[872]: ******:60197 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jul 01 23:24:42 vps ovpn-server[872]: ******:60197 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jul 01 23:24:42 vps ovpn-server[872]: ******:60197 WARNING: this cipher's block size is less than 128 bit (64 bit).  Consider using a --cipher with a larger block size.
Jul 01 23:24:42 vps ovpn-server[872]: ******:60197 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jul 01 23:24:42 vps ovpn-server[872]: ******:60197 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Jul 01 23:24:42 vps ovpn-server[872]: ******:60197 [OpenVPN-Client] Peer Connection Initiated with [AF_INET]******:60197
Jul 01 23:24:42 vps ovpn-server[872]: MULTI: new connection by client 'OpenVPN-Client' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn op
Jul 01 23:24:42 vps ovpn-server[872]: MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Jul 01 23:24:42 vps ovpn-server[872]: MULTI: Learn: 10.8.0.6 -> OpenVPN-Client/******:60197
Jul 01 23:24:42 vps ovpn-server[872]: MULTI: primary virtual IP for OpenVPN-Client/******:60197: 10.8.0.6
Jul 01 23:24:43 vps ovpn-server[872]: OpenVPN-Client/******:60197 PUSH: Received control message: 'PUSH_REQUEST'
Jul 01 23:24:43 vps ovpn-server[872]: OpenVPN-Client/******:60197 send_push_reply(): safe_cap=940
Jul 01 23:24:43 vps ovpn-server[872]: OpenVPN-Client/******:60197 SENT CONTROL [OpenVPN-Client]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,route 10.8.0.0 255.255.255.0,dhcp-option
Jul 01 23:30:27 vps ovpn-server[872]: OpenVPN-Client/******:60197 [OpenVPN-Client] Inactivity timeout (--ping-restart), restarting
Jul 01 23:30:27 vps ovpn-server[872]: OpenVPN-Client/******:60197 SIGUSR1[soft,ping-restart] received, client-instance restarting

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

Судя по логу OpenVPN работает.

Клиент подключается, но страницы не открываются.
Конфиги не менялись, обновления вроде тоже не ставил.

push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

Ну ты понял.

h578b1bde ★☆
()
Ответ на: комментарий от Inshallah

Не понял. Убрать гугловские днски?

Ну если ты на своей стороне ничего не менял — тогда вероятнее всего твой провайдер забанил гуглоднс. Если же нет — выкладывай пинги, трасировки и телнеты к хосту, на котором крутится проблемный сайт.

h578b1bde ★☆
()

Офигенно приложил всю необходимую инфу. Логи, конфигурацию, настройки fw, роутинг. Прекрасно!

Классическое «у меня в подвале стук».

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

Ну если ты на своей стороне ничего не менял — тогда вероятнее всего твой провайдер забанил гуглоднс

Нет, с чего бы.

Если же нет — выкладывай пинги, трасировки и телнеты к хосту, на котором крутится проблемный сайт.

C:\Windows\system32>ping linux.org.ru

Обмен пакетами с linux.org.ru [178.248.233.6] с 32 байтами данных:
Ответ от 178.248.233.6: число байт=32 время=131мс TTL=59
Ответ от 178.248.233.6: число байт=32 время=131мс TTL=59
Ответ от 178.248.233.6: число байт=32 время=131мс TTL=59
Ответ от 178.248.233.6: число байт=32 время=131мс TTL=59

Статистика Ping для 178.248.233.6:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 131мсек, Максимальное = 131 мсек, Среднее = 131 мсек

C:\Windows\system32>TRACERT.EXE linux.org.ru

Трассировка маршрута к linux.org.ru [178.248.233.6]
с максимальным числом прыжков 30:

  1    84 ms    84 ms    85 ms  10.8.0.1
  2    84 ms    84 ms    84 ms  91.92.128.1
  3    84 ms    93 ms    84 ms  ae1-203.RT.TLP.SOF.BG.retn.net [87.245.240.132]
  4   131 ms   131 ms   131 ms  ae6-4.RT.MR.MSK.RU.retn.net [87.245.233.25]
  5   131 ms   131 ms   131 ms  GW-Xtend.retn.net [87.245.253.194]
  6   131 ms   131 ms   131 ms  178.248.233.6

Трассировка завершена.


Но в браузере страница не открывается - «создание безопасного подключения», и всё.

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

Но в браузере страница не открывается - «создание безопасного подключения», и всё.

А напрямую открывается? Что в правилах iptables?

h578b1bde ★☆
()
Ответ на: комментарий от Inshallah

Упс. Дальше первого поста не смотрел.

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

А напрямую открывается?

В смысле напрямую? С впс? Да.

Что в правилах iptables?

iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

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

После шаманства

root@vps:~# iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
root@vps:~# sed -i 's|#net.ipv4.ip_forward=1|net.ipv4.ip_forward=1|' /etc/sysctl.conf
root@vps:~# echo 1 > /proc/sys/net/ipv4/ip_forward
root@vps:~# service openvpn restart

Заработало на мобильном клиенте, на венде всё то же самое.

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

Мобилка обратно отвалилась. Нихера не понимаю.

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

1. iptables -nvL
2. запускай tcpdump на tun и внешнем интерфейсе сервера, смотри что за пакеты и куда доходят, когда ты пытаешься открыть порты 80/443

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

1. 

Chain INPUT (policy ACCEPT 193K packets, 13M bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain FORWARD (policy ACCEPT 11178 packets, 5290K bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 167K packets, 16M bytes)
 pkts bytes target     prot opt in     out     source               destination

2. https://pastebin.com/bKFS9x7W

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

Да, с клиента всё хорошо. И с самого сервера всё хорошо. А с впн нехорошо.

У тебя там NAT судя по всему через какую-то задницу настроен.

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

iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all  — 10.8.0.0/24 0.0.0.0/0 to:91.92.128.198
MASQUERADE all  — 10.8.0.0/24 0.0.0.0/0

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

По правилам iptables срабатывает только первое правило, которому удовлетворяет пакет.

То есть, срабатывает SNAT all — 10.8.0.0/24 0.0.0.0/0 to:91.92.128.198

Не срабатывает MASQUERADE all — 10.8.0.0/24 0.0.0.0/0

У твоего опенвпн сервера внешний адрес точно 91.92.128.198 ???

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

Вендовым и андроидным, раньше работали оба

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

В общем, смотри:

TCP/IP стек венды _НЕ_ умеет /31 и /32 сети. Минимальная сеть, которую оно умеет - /30 То есть, ей нужно номер подсети, IP1, IP2, броадкаст.

Потому в документации опенвпн рекомендуется разбивать весь пул адресов сервера на /30 подсети. То есть, в твоем случае:

10.8.0.0 - подсеть 0

10.8.0.1 - дефолтный IP сервера

10.8.0.2 - пусто

10.8.0.3 - броадкаст 0

10.8.0.4 - подсеть 1

10.8.0.5 - клиент 1

10.8.0.6 - сервер 1

10.8.0.7 - броадкаст 1

10.8.0.8 - подсеть 2

10.8.0.9 - клиент 2

10.8.0.10 - сервер 2

10.8.0.11 - броадкаст 2

... и так далее ...

И потому обязательно должен быть настроен CCD, чтобы раздавать клиентам ПРАВИЛЬНЫЕ адреса!!!

Скажи мыло, я тебе скину свои работающие конфиги.

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