LINUX.ORG.RU
решено Форум — Admin  

Openvpn отбрасывает пакеты из-за ip

 , , ,


0

1

Здравствуйте. Пытаюсь на VPS сделать свой vpn.

Сервер вроде как работает, клиент подключается, но на клиенте по сути пропадает интернет. В логах сервера куча подобных сообщений:

Sun Jan  5 19:15:12 2020 us=265665 CLIENT/IPnat:PORT MULTI: bad source address from client [192.168.1.183], packet dropped

Думаю, что дело в этом. Как я понимаю, клиент шлет серверу ip, который выдан сетевой карте роутером, - 192.168.1.183, а подключение как бы идет c ip роутера, точнее вообще через NAT. Сервер их и отбрасывает.

НО если подключаться ко всяким бесплатным vpn`ам, то там всё работает, так что это я где-то косякнул/недоглядел.

Подскажите пожалуйста, где поправить?

← Трудности с пробросом видеокарты в виртуалку
Dovecot - проблема с POP3 (Permission denied) →
Ответ на: комментарий от anonymous 
root@keer:/etc# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 48:ba:4e:5c:96:c7 brd ff:ff:ff:ff:ff:ff
4: outline-tun0: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 500
    link/none 
    inet 10.0.85.1/24 scope global outline-tun0
       valid_lft forever preferred_lft forever
5: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d4:6a:6a:78:73:61 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.183/24 brd 192.168.1.255 scope global dynamic noprefixroute wlo1
       valid_lft 73059sec preferred_lft 73059sec
    inet6 fe80::a682:40ed:49e5:e2bd/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

root@keer:/etc# ip r
default via 192.168.1.1 dev wlo1 proto dhcp metric 600 
10.0.85.0/24 dev outline-tun0 proto kernel scope link src 10.0.85.1 linkdown 
169.254.0.0/16 dev outline-tun0 scope link metric 1000 linkdown 
192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.183 metric 600

А текст зачеркивать - двумя тильдами ~

Мне кажется, проблема на сервере, раз я с клиента спокойно пользуюсь другими vpn`ами

Architector
() автор топика
Последнее исправление: Architector (всего исправлений: 1)
Ответ на: комментарий от Architector 
4: outline-tun0: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 500
    link/none 
    inet 10.0.85.1/24 scope global outline-tun0
       valid_lft forever preferred_lft forever

Мне не нравится то, что статус VPN интерфейса «DOWN» и я говорю не про зачёркнутый, а про подчёркнутый текст.

В lorcode есть тег [u][/u], а в markdown - нет.

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

Извините, не так прочел

Не понял, куда делась половина вывода, но вот нормальный вывод:

root@keer:/etc# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 48:ba:4e:5c:96:c7 brd ff:ff:ff:ff:ff:ff
4: outline-tun0: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 500
    link/none 
    inet 10.0.85.1/24 scope global outline-tun0
       valid_lft forever preferred_lft forever
5: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d4:6a:6a:78:73:61 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.183/24 brd 192.168.1.255 scope global dynamic noprefixroute wlo1
       valid_lft 72278sec preferred_lft 72278sec
    inet6 fe80::a682:40ed:49e5:e2bd/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel 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::7d18:9ef1:14f9:3ffd/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

И я подозреваю, что используется именно 8-ой интерфейс для vpn, а четвертый только для outline

А вот на 8-ом статус UNKNOWN…

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

Ехе - не, спасибо, это я и так знал. Не охото легких путей

Architector
() автор топика
Ответ на: комментарий от Architector 
default via 192.168.1.1 dev wlo1 proto dhcp metric 600 
10.0.85.0/24 dev outline-tun0 proto kernel scope link src 10.0.85.1 linkdown 
169.254.0.0/16 dev outline-tun0 scope link metric 1000 linkdown 
192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.183 metric 600

У тебя в таблице маршрутизации маршрутов исходящие интерфейсы для маршрутов в сети wlo1 и outline-tun0.

anonymous
()
Ответ на: комментарий от anonymous 
0.0.0.0/1 via 10.8.0.5 dev tun0 
default via 192.168.1.1 dev wlo1 proto dhcp metric 600 
IPvps via 192.168.1.1 dev wlo1 
10.0.85.0/24 dev outline-tun0 proto kernel scope link src 10.0.85.1 linkdown 
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 outline-tun0 scope link metric 1000 linkdown 
192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.183 metric 600

root@keer:/etc# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 48:ba:4e:5c:96:c7 brd ff:ff:ff:ff:ff:ff
4: outline-tun0: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 500
    link/none 
    inet 10.0.85.1/24 scope global outline-tun0
       valid_lft forever preferred_lft forever
5: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d4:6a:6a:78:73:61 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.183/24 brd 192.168.1.255 scope global dynamic noprefixroute wlo1
       valid_lft 70873sec preferred_lft 70873sec
    inet6 fe80::a682:40ed:49e5:e2bd/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
9: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel 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::38f7:b13f:6c06:b8fb/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
Architector
() автор топика
Последнее исправление: Architector (всего исправлений: 2)

Показывайте как настраивали. С учетом интерфейса outline-tun0 смею предположить это не первая попытка.
И что бы два раза не вставить.

ip ru
ip r s table all
iptables-save

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

Если что, уточню, что это всё я делаю на клиенте

А outline-tun0 это от аутлайна от гугл, приложение их.

Еще раз повторюсь, что с другими vpn`ами всё работает.

root@keer:~# ip ru
0:	from all lookup local 
32766:	from all lookup main 
32767:	from all lookup default 

root@keer:~# ip r s table all
default via 192.168.43.1 dev wlo1 proto dhcp metric 600 
169.254.0.0/16 dev wlo1 scope link metric 1000 
192.168.43.0/24 dev wlo1 proto kernel scope link src 192.168.43.183 metric 600 
broadcast 10.0.85.0 dev outline-tun0 table local proto kernel scope link src 10.0.85.1 linkdown 
local 10.0.85.1 dev outline-tun0 table local proto kernel scope host src 10.0.85.1 
broadcast 10.0.85.255 dev outline-tun0 table local proto kernel scope link src 10.0.85.1 linkdown 
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
broadcast 192.168.43.0 dev wlo1 table local proto kernel scope link src 192.168.43.183 
local 192.168.43.183 dev wlo1 table local proto kernel scope host src 192.168.43.183 
broadcast 192.168.43.255 dev wlo1 table local proto kernel scope link src 192.168.43.183 
local ::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev wlo1 proto kernel metric 256 pref medium
fe80::/64 dev wlo1 proto kernel metric 600 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::b9c:a3e0:6a48:a9a8 dev wlo1 table local proto kernel metric 0 pref medium
ff00::/8 dev wlo1 table local metric 256 pref medium

При включеном vpn от freeopenvpn.org (ну так, для сравнения)(работает)

root@keer:~# ip r
0.0.0.0/1 via 192.168.225.1 dev tun0 
default via 192.168.43.1 dev wlo1 proto dhcp metric 600 
109.248.11.138 via 192.168.43.1 dev wlo1 
128.0.0.0/1 via 192.168.225.1 dev tun0 
169.254.0.0/16 dev wlo1 scope link metric 1000 
192.168.43.0/24 dev wlo1 proto kernel scope link src 192.168.43.183 metric 600 
192.168.225.0/24 dev tun0 proto kernel scope link src 192.168.225.220 


root@keer:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 48:ba:4e:5c:96:c7 brd ff:ff:ff:ff:ff:ff
4: outline-tun0: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 500
    link/none 
    inet 10.0.85.1/24 scope global outline-tun0
       valid_lft forever preferred_lft forever
5: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d4:6a:6a:78:73:61 brd ff:ff:ff:ff:ff:ff
    inet 192.168.43.183/24 brd 192.168.43.255 scope global dynamic noprefixroute wlo1
       valid_lft 2981sec preferred_lft 2981sec
    inet6 fe80::b9c:a3e0:6a48:a9a8/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
11: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 192.168.225.220/24 brd 192.168.225.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::52b7:d90c:adee:1157/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

А не подскажете ещё, что за интерфейс eno1? Или как посмотреть…

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

Вот что заметил. При выключенной опции (строка закоментирована) ;push "redirect-gateway def1 bypass-dhcp" curl ident.me возврашает ip компьютера, а не сервера (что должно бы быть). При раскоментированной строке вообще не работает ничего (любое действие с сетью, будь то ping или curl, wget затихают после ввода команды).

Вот конфиг сервера

port 1294

proto tcp

dev tun

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/Myovpn.crt
key /etc/openvpn/keys/Myovpn.key  # This file should be kept secret

dh /etc/openvpn/keys/dh2048.pem

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist /var/log/openvpn/ipp.txt

;push "redirect-gateway def1 bypass-dhcp"

keepalive 10 120

tls-auth /etc/openvpn/keys/ta.key 0 # This file is secret

cipher AES-256-CBC

user openVPN
group openVPN

persist-key
persist-tun

status /var/log/openvpn/status.log
log-append  /var/log/openvpn/openvpn.log

verb 4

sndbuf 0
rcvbuf 0
topology subnet
auth SHA512

Конфиг клиента (.ovpn) без ключей

client

dev tun

proto tcp

remote IP 1294

resolv-retry infinite

nobind

persist-key
persist-tun

remote-cert-tls server

cipher AES-256-CBC

verb 3


sndbuf 0
rcvbuf 0
keepalive 10 120
auth SHA512
Architector
() автор топика
Последнее исправление: Architector (всего исправлений: 1)
Ответ на: комментарий от Architector

eno1 - это проводной ethernet интерфейс, при старой схеме именования сетевых интерфейсов он бы именовался eth0.

anonymous
()
Ответ на: комментарий от Architector

Выше у вас было написано про локалку 192.168.1.183/24
В этом выхлопе уже 192.168.43.183/24
Это из разных мест?

При включеном vpn от freeopenvpn.org (ну так, для сравнения)(работает)

Я просил выхлопы, не на примере где работает, а на примере где не работает.

Выше возможно был не понят «Показывайте как настраивали. » == как минимум конфиги покажите, как клиента так и сервера.

А не подскажете ещё, что за интерфейс eno1?

Ну судя по названию ethernet адаптер, а по маку если не подменен это HP

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

Да, из разных мест

Конфиги приложил сообщением выше

Вот при включеном vpn, где не работает

root@keer:/# ip r s table all
0.0.0.0/1 via 10.8.0.1 dev tun0 
default via 192.168.43.1 dev wlo1 proto dhcp metric 600 
3.134.237.109 via 192.168.43.1 dev wlo1 
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.4 
128.0.0.0/1 via 10.8.0.1 dev tun0 
169.254.0.0/16 dev wlo1 scope link metric 1000 
192.168.43.0/24 dev wlo1 proto kernel scope link src 192.168.43.183 metric 600 
broadcast 10.0.85.0 dev outline-tun0 table local proto kernel scope link src 10.0.85.1 linkdown 
local 10.0.85.1 dev outline-tun0 table local proto kernel scope host src 10.0.85.1 
broadcast 10.0.85.255 dev outline-tun0 table local proto kernel scope link src 10.0.85.1 linkdown 
broadcast 10.8.0.0 dev tun0 table local proto kernel scope link src 10.8.0.4 
local 10.8.0.4 dev tun0 table local proto kernel scope host src 10.8.0.4 
broadcast 10.8.0.255 dev tun0 table local proto kernel scope link src 10.8.0.4 
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
broadcast 192.168.43.0 dev wlo1 table local proto kernel scope link src 192.168.43.183 
local 192.168.43.183 dev wlo1 table local proto kernel scope host src 192.168.43.183 
broadcast 192.168.43.255 dev wlo1 table local proto kernel scope link src 192.168.43.183 
local ::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev wlo1 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
fe80::/64 dev wlo1 proto kernel metric 600 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::b9c:a3e0:6a48:a9a8 dev wlo1 table local proto kernel metric 0 pref medium
local fe80::5253:9ef0:824f:6e8d dev tun0 table local proto kernel metric 0 pref medium
ff00::/8 dev wlo1 table local metric 256 pref medium
ff00::/8 dev tun0 table local metric 256 pref medium

root@keer:/# ip ru
0:	from all lookup local 
32766:	from all lookup main 
32767:	from all lookup default
Architector
() автор топика
Последнее исправление: Architector (всего исправлений: 1)
Ответ на: комментарий от Architector

Конфиг клиента (.ovpn) без ключей

Как прописаны ключи? Не обязательно сами ключи выкладывать, только начало и конец тэгов

В целом у вас почти все верно. Кроме скорее всего remote-cert-tls server. Но не факт. И если они у вас все включая ключи прописаны в самом конфиге то не забыть про
key-direction 1

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

Стоп. Я не прав. Ещё раз перечитал весь топик.
Меня крайне смущает другое. Вы так и не показали выхлоп iptables-save с клиента. Исходя из того что в ip ru, ip r ничего подозрительного нет, ip 192.168.1.183 указанный в топике может на сервере оказаться только по причине snat. Я конечно могу что-то не заметить, но очень на это похоже.

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

Ключи прописаны так:

<ca>
</ca>
<cert>
</cert>
<key>
</key>
key-direction 1
<tls-auth>
</tls-auth>

key-direction 1 там присутствует

iptables-save ничего не выдаёт

root@keer:/# iptables-save
root@keer:/#
Architector
() автор топика
Ответ на: комментарий от Architector

Чего-то меня на праздники клинит. Или лыжи или я. Прогнал ваши конфиги на поддиванных тестовых, за исключением параметра remote-cert-tls server у клиента. Работает.

Но уж до кучи tcpdump -ni tun0 если выполнить с клиента ping -n 8.8.8.8 чего показывает как на сервере так и на клиенте? Это конечно с горя, но все равно надо посмотреть.

ЗЫ

iptables-save ничего не выдаёт

А что за система? Может у вас nftables ?

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

Система - Linux Mint Tricia (19.3)

А iptables-save же просто сохраняет настройки, разве оно должно что-то выводить?

tcpdump -ni tun0 при включенном vpn (который не работает) на клиенте: ссылка на dpaste.com

При закомменчивании строки remote-cert-tls server так же не работает (вроде как данная строка просто включает проверку сертификата сервера для защиты от MITM, но раз соединение уж есть, то вряд ли, мне кажется, проблема где-то здесь)

root@keer:/# ping -n 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5097ms

Пинг на сервере:

root@kali:/# ping -n 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=38 time=11.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=38 time=11.0 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=38 time=11.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=38 time=11.0 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=38 time=11.0 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 10.972/11.000/11.028/0.018 ms
Architector
() автор топика
Последнее исправление: Architector (всего исправлений: 2)
Ответ на: комментарий от anc

Я тут ещё кое-что вспомнил.

Сервер арендуется в AWS Amazon. Вот. А у них там стоит что-то наподобие NAT (хотя вроде это он и есть). Т.е. у них все машины имеют серые адреса (серые по факту), но при этом, если запросить, то они связывают с этим серым - белый ip-адрес (т.е. только мой, получается).

Так, я при подключении по ssh к серверу указываю один ip (ну который белый), но при этом ifconfig выдаёт совершенно другой ip.

Может ли из-за этого быть проблема? Просто вроде openvpn сервер ругается не на свои ip-адреса, а на клиентские.

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

Вы меня видимо не поняли.
1. На клиенте запускаем ping -n 8.8.8.8
2. Одновременно и на сервере и на клиенте запускаем tcpdump -ni tun0
3. Смотрим выхлопы пункта 2.

А iptables-save же просто сохраняет настройки,

Неа :)

разве оно должно что-то выводить?

Ага :) iptables-save выводит на stdout текущие правила.

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

Да, не понял было.

Тогда как-то так:

  • Запустил демон openvpn на сервере
  • Запустил tcpdump -ni tun0 на сервере
  • Подключился клиентом к vpn серверу
  • Запустил tcpdump -ni tun0 на клиенте
  • ping -n 8.8.8.8 на клиенте

tcpdump с сервера: ссылка

tcpdump с клиента: ссылка

Тем временем вывод ping:

kein@keer:~$ ping -n 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
42 packets transmitted, 0 received, 100% packet loss, time 41986ms

По поводу iptables-save. Команда вводится, сама ничего не выводит. Если посмотреть явно правила, то там пусто (политика ACCEPT везде):

root@keer:/# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
root@keer:/# iptables -t nat -L
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
Architector
() автор топика
Ответ на: комментарий от anc

Как написано здесь (на сайте openvpn.net):

These errors occur because OpenVPN doesn’t have an internal route for it IP. Consequently, it doesn’t know how to route the packet to this machine, so it drops the packet. Use client-config-dir and create a ccd file for your client containing the iroute option to tell OpenVPN that the IP/24 network is available behind this client.

Собственно создал директорию с клиентскими конфигами, в конфиг сервера добавил:

client-config-dir /etc/openvpn/ccd           # директория с настройками для клиентов
route 192.168.c.0 255.255.0.0     # обрабатывать пакеты из подсети 192.168.0.0/16

а в /etc/openvpn/ccd/client_name1.conf написал:

iroute 192.168.0.0 255.255.0.0    # разрешаем доступ к VPN из подсети 192.168.0.0/16

Пакеты перестали отбрасываться. Собственно моя проблема на этом исчезла, но возникла новая, точнее интернета всё еще не было. Но где-то прочитал, что надо настроить NAT на сервере. На сервере прописал:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

И всё заработало. Магия какая-то)

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

Эмм. Но по задаче вроде и не было отправлять 192.168.0.0/16 в тунель. И вопрос в том как они туда попадают?

# обрабатывать пакеты из подсети 192.168.0.0/16

Неверный комментарий, route всего лишь добавляет одну строчку в таблицу роутинга main для указанной сети через интерфейс ovpn. Формулировка «обрабатывать пакеты» тут имхо не уместна.

# разрешаем доступ к VPN из подсети 192.168.0.0/16

Не разрешаем, а сообщаем ovpn что за clientname находиться сеть 192.168.0.0/16 и пакеты для этой сети надо отправлять этому клиенту.

Но где-то прочитал, что надо настроить NAT на сервере. На сервере прописал

Да же не думал, что вы не прописали маскарад. :)

Итого ваша проблема состоит из двух частей.
1. Вы не прописали маскарад. Теперь прописали. Можно считать решенной.
Но только на подсеть ovpn 10.8.0.0/24.
2. Ругань в логах на 192.168.х.х Непонятно, кто это и зачем. То что прописан route и iroute всего-лишь избавило вас от ругани в логах. Но не ответило на вопрос «кто эти люди?». Исходя из пункта 1, они один фиг в инет не выйдут через тунель, но ведь почему-то ломятся.

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

А вот тут интересно стало

По поводу маскарада - я тут немного не знаю даже, что это и зачем, лишь смутные представления.

Но только на подсеть ovpn 10.8.0.0/24ъ

Надо ещё для какой-то?

Неверный комментарий

Здесь так же мои знания кончаются. Простите

Не разрешаем, а сообщаем ovpn что за clientname находиться сеть 192.168.0.0/16 и пакеты для этой сети надо отправлять этому клиенту.

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

кто эти люди?

Думаю, это что-то связанное с…

Ну смотрите. Адрес 192.168.x.x (на данный момент 192.168.1.6) - адрес, выданный роутером моему компьютеру. Компьютер знает лишь его и отправляет пакеты от этого ip. Разве не так?

Буду очень благодарен, если не сочтёте за труд написать поподробнее

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

По поводу маскарада - я тут немного не знаю даже, что это и зачем, лишь смутные представления.

Это SNAT замена в пакете src IP. В вашем случае (MASQUERADE) src IP будет заменен на IP интерфейса с которого улетит пакет дальше. То есть скорее всего через defgw VPS. При получении ответа, происходит обратное преобразование, благодаря записям в conntrack.
Очень хорошо описано здесь https://www.opennet.ru/docs/RUS/iptables/

Ну смотрите. Адрес 192.168.x.x (на данный момент 192.168.1.6) - адрес, выданный роутером моему компьютеру. Компьютер знает лишь его и отправляет пакеты от этого ip. Разве не так?

Нет. Ваш клиент идет через роутер, предположим это 192.168.1.1. На роутере как раз тот же SNAT, он отправляет измененный пакет уже от своего адреса на VPS. Сеть 192.168.0.0/16 не является маршрутиризируемой в инете.
У вас при подключении ovpn клиент уже использует выданный ему адрес из сети 10.8.0.0/24. Тоесть первое, нам нужно оставить маршрут до сервера ovpn, это пойдет через ваш роутер. Второе, все что внутри туннеля это уже адресация самого ovpn.
Вернемся «к нашим баранам». Что мне не понятно, откуда в туннеле берутся адреса вида 192.168. по всем выхлопам что вы скинули их там не должно от слова совсем.
PS Хотяя может какая-то приложуха биндится на локальный интерфейс при старте. Покажите выхлоп netstat -apn

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

он отправляет измененный пакет уже от своего адреса

Всегда думал, что для этого пакет оборачивается в ещё один пакет. Хорошо, буду знать.

root@keer:/$ netstat -aptun
Активные соединения с интернетом (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State       PID/Program name    
tcp        0      0 127.0.0.1:6341          0.0.0.0:*               LISTEN      1929/megasync       
tcp        0      0 127.0.0.1:6342          0.0.0.0:*               LISTEN      1929/megasync       
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      1284/smbd           
tcp        0      0 127.0.0.1:5939          0.0.0.0:*               LISTEN      1173/teamviewerd    
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      708/systemd-resolve 
tcp        0      0 127.0.0.1:8118          0.0.0.0:*               LISTEN      815/privoxy         
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      21119/cupsd         
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      1284/smbd           
tcp       84      0 127.0.0.1:56536         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp       84      0 127.0.0.1:56524         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp       84      0 127.0.0.1:56516         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp        0      0 127.0.1.1:139           127.0.0.1:56520         ESTABLISHED 18938/smbd          
tcp        0      0 127.0.1.1:139           127.0.0.1:56528         ESTABLISHED 18962/smbd          
tcp        0      0 127.0.1.1:139           127.0.0.1:56536         ESTABLISHED 18976/smbd          
tcp        0      0 192.168.1.6:59648       64.233.165.198:443      ESTABLISHED 1912/firefox        
tcp        0      0 192.168.1.6:34568       3.134.237.109:22        ESTABLISHED 20597/ssh           
tcp        0      0 127.0.1.1:139           127.0.0.1:56526         ESTABLISHED 18961/smbd          
tcp        0      0 192.168.1.6:55128       87.240.185.164:443      ESTABLISHED 1912/firefox        
tcp       84      0 127.0.0.1:56530         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp        0      0 127.0.1.1:139           127.0.0.1:56522         ESTABLISHED 18947/smbd          
tcp       84      0 127.0.0.1:56522         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp       84      0 127.0.0.1:56534         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp        0      0 127.0.1.1:139           127.0.0.1:56534         ESTABLISHED 18975/smbd          
tcp        0      0 192.168.1.6:54634       87.240.129.129:443      ESTABLISHED 1912/firefox        
tcp        0      0 192.168.1.6:43272       93.186.225.208:443      ESTABLISHED 1912/firefox        
tcp        0      0 127.0.1.1:139           127.0.0.1:56532         ESTABLISHED 18973/smbd          
tcp        0      0 192.168.1.6:42340       80.68.78.46:80          TIME_WAIT   -                   
tcp       84      0 127.0.0.1:56526         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp        0      0 127.0.1.1:139           127.0.0.1:56538         ESTABLISHED 18977/smbd          
tcp        0      0 192.168.1.6:59118       93.186.225.201:443      ESTABLISHED 1912/firefox        
tcp       84      0 127.0.0.1:56538         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp        0      0 127.0.1.1:139           127.0.0.1:56524         ESTABLISHED 18951/smbd          
tcp        0      0 192.168.1.6:42342       80.68.78.46:80          TIME_WAIT   -                   
tcp        0      0 192.168.1.6:55238       31.216.147.133:443      ESTABLISHED 1929/megasync       
tcp        0      0 192.168.1.6:37542       87.240.129.135:443      ESTABLISHED 1912/firefox        
tcp       84      0 127.0.0.1:56528         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp       84      0 127.0.0.1:56520         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp        0      0 127.0.1.1:139           127.0.0.1:56516         ESTABLISHED 18935/smbd          
tcp        0      0 192.168.1.6:50162       54.149.145.192:443      ESTABLISHED 1912/firefox        
tcp        0      0 127.0.1.1:139           127.0.0.1:56530         ESTABLISHED 18972/smbd          
tcp       84      0 127.0.0.1:56532         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp6       0      0 :::139                  :::*                    LISTEN      1284/smbd           
tcp6       0      0 ::1:8118                :::*                    LISTEN      815/privoxy         
tcp6       0      0 ::1:631                 :::*                    LISTEN      21119/cupsd         
tcp6       0      0 :::445                  :::*                    LISTEN      1284/smbd           
udp        0      0 127.0.0.53:53           0.0.0.0:*                           708/systemd-resolve 
udp        0      0 0.0.0.0:68              0.0.0.0:*                           22896/dhclient      
udp        0      0 192.168.1.255:137       0.0.0.0:*                           1129/nmbd           
udp        0      0 192.168.1.6:137         0.0.0.0:*                           1129/nmbd           
udp        0      0 0.0.0.0:137             0.0.0.0:*                           1129/nmbd           
udp        0      0 192.168.1.255:138       0.0.0.0:*                           1129/nmbd           
udp        0      0 192.168.1.6:138         0.0.0.0:*                           1129/nmbd           
udp        0      0 0.0.0.0:138             0.0.0.0:*                           1129/nmbd           
udp        0      0 0.0.0.0:631             0.0.0.0:*                           21120/cups-browsed  
udp        0      0 0.0.0.0:40034           0.0.0.0:*                           719/avahi-daemon: r 
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           719/avahi-daemon: r 
udp6       0      0 :::5353                 :::*                                719/avahi-daemon: r 
udp6       0      0 :::60810                :::*                                719/avahi-daemon: r
Architector
() автор топика
Ответ на: комментарий от Architector

Ну и бардак.
privoxy
teamviewerd
и так далее

Но похоже вы показали выхлоп не в том случае когда у вас подключен ovpn

anc ★★★★★
()
Ответ на: комментарий от anc 
kein@keer:~/Ms/WOS$ sudo netstat -aptun
Активные соединения с интернетом (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State       PID/Program name    
tcp        0      0 127.0.0.1:6341          0.0.0.0:*               LISTEN      1929/megasync       
tcp        0      0 127.0.0.1:6342          0.0.0.0:*               LISTEN      1929/megasync       
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      1284/smbd           
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      708/systemd-resolve 
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      21119/cupsd         
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      1284/smbd           
tcp      196      0 127.0.0.1:56536         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp      196      0 127.0.0.1:56524         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp        0      0 10.8.0.4:33408          176.58.123.25:80        TIME_WAIT   -                   
tcp        0      1 192.168.1.6:47264       35.222.85.5:80          SYN_SENT    743/NetworkManager  
tcp        0     71 192.168.1.6:50260       35.160.111.136:443      FIN_WAIT1   -                   
tcp      196      0 127.0.0.1:56516         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp        0    190 10.8.0.4:50774          52.41.39.5:443          ESTABLISHED 1912/firefox        
tcp        0    590 192.168.1.6:59778       93.186.225.201:443      FIN_WAIT1   -                   
tcp        0      0 127.0.1.1:139           127.0.0.1:56520         ESTABLISHED 18938/smbd          
tcp        0      0 127.0.1.1:139           127.0.0.1:56528         ESTABLISHED 18962/smbd          
tcp        0      0 127.0.1.1:139           127.0.0.1:56536         ESTABLISHED 18976/smbd          
tcp        0    103 192.168.1.6:37718       64.233.164.97:443       FIN_WAIT1   -                   
tcp        0    580 192.168.1.6:53630       3.134.237.109:1294      ESTABLISHED 27327/openvpn       
tcp        0     58 192.168.1.6:36930       89.44.168.81:443        FIN_WAIT1   -                   
tcp        0    103 192.168.1.6:44044       93.186.225.208:443      FIN_WAIT1   -                   
tcp        0     25 192.168.1.6:55954       31.216.147.133:443      FIN_WAIT1   -                   
tcp        0      0 127.0.1.1:139           127.0.0.1:56526         ESTABLISHED 18961/smbd          
tcp      196      0 127.0.0.1:56530         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp        0      0 192.168.1.6:52162       93.184.220.29:80        TIME_WAIT   -                   
tcp        0      0 127.0.1.1:139           127.0.0.1:56522         ESTABLISHED 18947/smbd          
tcp      196      0 127.0.0.1:56522         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp      196      0 127.0.0.1:56534         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp        0      0 127.0.1.1:139           127.0.0.1:56534         ESTABLISHED 18975/smbd          
tcp        0      0 10.8.0.4:51980          178.248.233.6:9000      ESTABLISHED 1912/firefox        
tcp        0    103 192.168.1.6:44640       192.0.73.2:443          FIN_WAIT1   -                   
tcp        0     58 192.168.1.6:53816       185.206.24.28:443       FIN_WAIT1   -                   
tcp        0     58 192.168.1.6:38702       94.24.36.32:443         FIN_WAIT1   -                   
tcp        0      0 192.168.1.6:35990       3.134.237.109:22        ESTABLISHED 27310/ssh           
tcp        0     58 192.168.1.6:59622       89.44.168.73:443        FIN_WAIT1   -                   
tcp        0    180 192.168.1.6:59782       93.186.225.201:443      ESTABLISHED 1912/firefox        
tcp        0      0 127.0.1.1:139           127.0.0.1:56532         ESTABLISHED 18973/smbd          
tcp        0      0 10.8.0.4:43262          31.216.147.133:443      ESTABLISHED 1929/megasync       
tcp      196      0 127.0.0.1:56526         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp        0      0 127.0.1.1:139           127.0.0.1:56538         ESTABLISHED 18977/smbd          
tcp        0      0 10.8.0.4:42058          2.16.103.90:80          TIME_WAIT   -                   
tcp      196      0 127.0.0.1:56538         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp        0      0 10.8.0.4:42056          2.16.103.90:80          TIME_WAIT   -                   
tcp        0      0 127.0.1.1:139           127.0.0.1:56524         ESTABLISHED 18951/smbd          
tcp        0     71 192.168.1.6:56464       178.248.233.6:9000      FIN_WAIT1   -                   
tcp        0      0 10.8.0.4:51984          178.248.233.6:9000      TIME_WAIT   -                   
tcp      196      0 127.0.0.1:56528         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp      196      0 127.0.0.1:56520         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp        0      0 127.0.1.1:139           127.0.0.1:56516         ESTABLISHED 18935/smbd          
tcp        0      0 10.8.0.4:42054          2.16.103.90:80          ESTABLISHED 1912/firefox        
tcp        0      0 10.8.0.4:42052          2.16.103.90:80          ESTABLISHED 1912/firefox        
tcp        0      0 127.0.1.1:139           127.0.0.1:56530         ESTABLISHED 18972/smbd          
tcp      196      0 127.0.0.1:56532         127.0.1.1:139           ESTABLISHED 18835/gvfsd-smb-bro 
tcp6       0      0 :::139                  :::*                    LISTEN      1284/smbd           
tcp6       0      0 ::1:631                 :::*                    LISTEN      21119/cupsd         
tcp6       0      0 :::445                  :::*                    LISTEN      1284/smbd           
udp        0      0 127.0.0.53:53           0.0.0.0:*                           708/systemd-resolve 
udp        0      0 0.0.0.0:68              0.0.0.0:*                           26604/dhclient      
udp        0      0 192.168.1.255:137       0.0.0.0:*                           1129/nmbd           
udp        0      0 192.168.1.6:137         0.0.0.0:*                           1129/nmbd           
udp        0      0 0.0.0.0:137             0.0.0.0:*                           1129/nmbd           
udp        0      0 192.168.1.255:138       0.0.0.0:*                           1129/nmbd           
udp        0      0 192.168.1.6:138         0.0.0.0:*                           1129/nmbd           
udp        0      0 0.0.0.0:138             0.0.0.0:*                           1129/nmbd           
udp        0      0 0.0.0.0:631             0.0.0.0:*                           21120/cups-browsed  
udp        0      0 0.0.0.0:40034           0.0.0.0:*                           719/avahi-daemon: r 
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           719/avahi-daemon: r 
udp6       0      0 :::5353                 :::*                                719/avahi-daemon: r 
udp6       0      0 :::60810                :::*                                719/avahi-daemon: r
Architector
() автор топика
Ответ на: комментарий от Architector

Кажется догадался. Клиенты забиндились на один IP но роутинг поменялся, поэтому и мат пошел, потом неспеша отваливаются. То есть мат в логах топика только первичный потом его быть не должно. Ну и пропишите verb N поменьше, что бы не раздражало. Идея с route/iroute тут лишняя.
А сама проблема конечно была только в SNAT.

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Трудности с пробросом видеокарты в виртуалку
Admin
Dovecot - проблема с POP3 (Permission denied) →