Неработает vpn-тоннель между linuxmint и AWS ubuntu 14.04.5

вывод команды route в студию

Это до запуска openvpn? Перезапустите сервер потом клиент, потом вывод route на клиенте. И что бы два раза не ходить: конфиг и логи клиента, конфиг и логи сервера, вывод iptables -t nat -S на сервере. Желательно все это закинуть на какой-нибудь pastebin закинуть, т.к. на лоре спойлеров нет.

Это после запуска openvpn на сервере, вот конфиги и вывод route после запуска клиента: https://pastebin.com/AnvKQbkM

И ещё было бы неплохо спросить: а с какого перепуга на сервере первый тун создаётся, а не нулевой? Это может быть из-за уже присутствующей другой настройки. Например, когда сервер одновременно работает и сервером, и клиентом для другого сервера. Впрочем, лично я с убунтами не возился. Может, они так устроены? - считают с единицы. Это любопытно и надо бы уточнить у владельца сервера. Я не говорю, что «нельзя» так. Можно и нужно. Но для общего понимания ситуёвины хотелось бы узнать: какие ещё сервисы-демоны крутятся на сервере, которые отбирают tun0, если убунта не считает с единицы?

tun0 создается на клиенте, tun1 на сервере, на сервере больше ничего нет это чистый ново установленный сервер на amazon'е.

интересует как раз вывод route на клиенте

У него в конфиге сервера указано

dev tun1

Так это еще и на роутере с заводской прошивкой? Там разве есть клиент openvpn?

Логи сервера и клиента после последнего перезапуска

Да роутер с заводской прошивкой, но я так понимаю там клиент и не нужен, тоннель же создается между локальной машиной и сервером точка-точка. Вот логи после запуска https://pastebin.com/Qvw01iN8

Вот syslog с сервера

Nov  7 11:02:02 ip-172-31-31-197 ovpn-openvpn[18379]: TCP connection established with [AF_INET]5.164.89.149:45964
Nov  7 11:02:02 ip-172-31-31-197 ovpn-openvpn[18379]: TCPv4_SERVER link local (bound): [undef]
Nov  7 11:02:02 ip-172-31-31-197 ovpn-openvpn[18379]: TCPv4_SERVER link remote: [AF_INET]5.164.89.149:45964
Nov  7 11:02:03 ip-172-31-31-197 ovpn-openvpn[18379]: Peer Connection Initiated with [AF_INET]5.164.89.149:45964
Nov  7 11:02:03 ip-172-31-31-197 ovpn-openvpn[18379]: Initialization Sequence Completed
Nov  7 11:08:23 ip-172-31-31-197 dhclient: DHCPREQUEST of 172.31.31.197 on eth0 to 172.31.16.1 port 67 (xid=0x1eacb481)
Nov  7 11:08:23 ip-172-31-31-197 dhclient: DHCPACK of 172.31.31.197 from 172.31.16.1
Nov  7 11:08:23 ip-172-31-31-197 dhclient: bound to 172.31.31.197 -- renewal in 1693 seconds.

Судя по логам все хорошо. Теперь вывод команды на роутере.

iptables -t nat -S

iptables -t nat -S
iptables -S

Насколько я понял надо таблицу nat на роутер показать, вот она, iptables там с такими параметрами не работает.

KEENETIC LITE> lan nat status
Now: Server off
==================================================
ID      IP Address      Protocl Bcast   Port Range
==================================================

Server
$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 0.0.0.0/2 -o eth0 -j MASQUERADE

$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 1194 -j ACCEPT

Похоже что проблема все-таки в роутере. Попробуй подключиться к серверу с другого клиента, с мобилы например(openvpn для Android у меня заработал). Подключишься, проверишься на каком-нибудь myip.ru, если все удачно - кури настройку роутера. У меня keenetic lite rev b с прошивкой openwrt, там openvpn в за 2 минуты настраивается есть хороший мануал от разрабов.

А почему у вас маска /2 ?

Я всегда путаю: /2 - это маска подсети или обозначение длины маски подсети? Вы уж наверняка знаете. Не подскажете?

Префикс, маска, их длина - суть разные формулировки одного и тогоже.

Спасибо. )) Вернёмся к самому первому сообщению. Было так:

netstat -nlpt
(No info could be read for "-p": geteuid()=1000 but you should be root.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      - 

А должно быть вот с этим:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:1194            0.0.0.0:*               LISTEN      -         

В принципе ничего страшного. Серверок влёгкую выдаёт наружу, но почему-то никак не хочет принять «во внутрь». Право, я тут не советчик. Это надо бывалого по амазону поспрашивать.

Что интересно после перезапуска openvpn на сервере картинка такая

$ netstat -nlpt
(No info could be read for "-p": geteuid()=1000 but you should be root.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:1194            0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22   

Подключился на прямую, получил такую таблицу в route

$ route
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
default         10.4.0.1        128.0.0.0       UG    0      0        0 tun0
default         10.83.255.126   0.0.0.0         UG    0      0        0 ppp0
10.4.0.1        *               255.255.255.255 UH    0      0        0 tun0
10.83.255.126   *               255.255.255.255 UH    0      0        0 ppp0
52.15.118.78    10.83.255.126   255.255.255.255 UGH   0      0        0 ppp0
128.0.0.0       10.4.0.1        128.0.0.0       UG    0      0        0 tun0

Что значит «напрямую»? С виду все правильно. 10.83.255.126 - это внешний адрес AWS?

На прямую с ноутбука без роутера. Теперь пинги пошли до внешних ресурсов, но имена DNS не разрешает.

ping google.com
ping: unknown host google.com

Внешний AWS это 52.15.118.78

Что в resolv.conf на ноуте?
Удали с сервера

ifconfig 10.4.0.1 10.4.0.2

topology subnet
server 10.4.0.0 255.255.255.0
push "route 0.0.0.0 0.0.0.0 vpn_gateway"
push "route 52.15.118.78  255.255.255.255 net_gateway"
push "dhcp-option DNS 8.8.8.8"

redirect-gateway def1
ifconfig 10.4.0.2 10.4.0.1

push «route 0.0.0.0 0.0.0.0 vpn_gateway»

Енто вы запиливаете второй defroute, умно что тут еще сказать.
Да и последовательность push route тоже забавляет.
Вы бы хоть ман к ovpn почитали, все придумано до вас и описано в мане.

что тут еще сказать

Можно например сказать как надо правильно, раз уж вы такой умный. А посылать в маны и разбрасываться язвительными высказываниями любой дурачек может.
Я же пытаюсь помочь человеку вспоминая как сам часами это все настраивал. И все то что я насоветовал работает у меня более полугода, но раз вы говорите что это не правильно, то мы с ТС ждем ваших ЦУ и идем настраивать по-вашему.

1. Для того что вы описали у ovpn есть redirect-gateway - его поведение с разными параметрами описано в мане. Если вам по какой-то причине не понравился def1 ( кстати чем хоть не понравился?) оставьте без параметров.
2. push "route 52.15.118.78 255.255.255.255 net_gateway" - будьте уж последовательны, а то у вас что-то странное, net_gateway но при этом явно ip 52.15.118.78
3. push "route 0.0.0.0 0.0.0.0 vpn_gateway" - вы добавляете еще один defgw, понимаете еще один, и где, и как оно будет работать, тот еще вопрос, зависит от метрик.
4. Последовательность

push "route 0.0.0.0 0.0.0.0 vpn_gateway"
push "route 52.15.118.78  255.255.255.255 net_gateway"

Посмотрел ссылку наискосок, у чувака каша в голове минимум на вот эту тему iptables -t nat -A POSTROUTING -s 10.4.0.1/2 -o eth0 -j MASQUERADE, так что могут быть и еще какие-нибудь ошибки. Берите любую другую статью по настройке openvpn и не заморачивайтесь на этой.
ЗЫ Вы у себя случайно маску /2 не от туда же взяли?

Спасибо.

Я смотрю что ман вы все-таки принципиально не читаете

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

Почитал чуток ман, попробовал конфиг поправить.

кстати чем хоть не понравился?

У меня vpn в ssl туннель завернут, если добавлять маршруты с помощью redirect-gateway, то во-первых у меня почему-то так же добавляется второй маршрут по-умолчанию (а первый меняется с маршрута до провайдера на маршрут до внутреннего ip vpn «10.10.0.1» который при остановке ovpn так же удаляется и в итоге система остается вообще без def gw). А во-вторых, внешний ip сервера выставляется как 127.0.0.1 соотв. маршрут до сервера такой:

127.0.0.1 via 10.64.64.64 dev ppp0

будьте уж последовательны, а то у вас что-то странное, net_gateway но при этом явно ip 52.15.118.78

По той же причине. Можно было указать remote_host вместо 52.15.118.78, но т.к. ssl тоннель, то remote_host = 127.0.0.1

вы добавляете еще один defgw, понимаете еще один, и где, и как оно будет работать, тот еще вопрос, зависит от метрик.

Выдержка из мана:

metric default — taken from --route-metric otherwise 0.

Т.е. машрут до vpn будет приоритетней т.к. метрика gw от провайдера у меня всегда 1024.

Понимаю что все это к ТС не относится ни коим образом, но мой вариант получился универсальней.

P.S. пуши местами поменял, вывод команды ip r не изменился.

Понял. В вашем случае (тунель) действительно redirect-gateway отработает не правильно. Но ваш случай отдельно специфичен. Кстати вот чем хорош ман к ovpn он расписывает что делает при некоторых опциях, в данном случае redirect-gateway.

Т.е. машрут до vpn будет приоритетней т.к. метрика gw от провайдера у меня всегда 1024.

Конкретно у вас - да, но это не повод советовать тоже самое остальным. Если уж на то пошло, то лучше советовать вариант поведения redirect-gateway def1 с двумя маршрутами 0/1 и 128/1

P.S. пуши местами поменял, вывод команды ip r не изменился.

Кажется вы не поняли, дело не в отображении а в последовательности выполнения двух команд. Предположим что команды прилетают с сервера последовательно, прилетела смена defgw, маршрут поменялся, вторую вы уже не получите. Или тот же же вариант но вы выполняете эти команды на удаленной машине.

прилетела смена defgw, маршрут поменялся, вторую вы уже не получите.

Понял, спасибо.