LINUX.ORG.RU
ФорумAdmin

Openvpn - подключение есть, интернета нет

 , ,


0

1

Заранее извиняюсь, не оч хорошо разбираюсь в теме

Есть удаленный сервер на хостинге, хочу на нем установить личный vpn - сервер. От хостинга есть внутренний и внешний ip, список портов, порт для ssh и пароль от рута. Устанавливал по этой инструкции. Конкретно:

  1. Поставил centos 7 (потом еще пробовал debian 12 и centos 8, не сильно помогло), заменил устаревшие репозитории на эти и сделал yum update
  2. Скачал предложенный скрипт, выдал ему права и запустил
  3. В процессе отключил ipv6, выбрал dns гугла (пробовал еще adguard и cloudflare) и сделал юзера без пароля.
  4. Скинул полученный конфиг юзера на систему клиента

На вид все системы, связанные с впном, работают правильно:

-bash-4.2# systemctl | grep VPN
  iptables-openvpn.service                                 loaded active exited    iptables rules for OpenVPN
  openvpn-server@server.service                            loaded active running   OpenVPN service for server
-bash-4.2# systemctl status iptables-openvpn.service
● iptables-openvpn.service - iptables rules for OpenVPN
   Loaded: loaded (/etc/systemd/system/iptables-openvpn.service; enabled; vendor preset: disabled)
   Active: active (exited) since Sat 2024-08-24 00:22:16 BST; 41min ago
  Process: 948 ExecStop=/etc/iptables/rm-openvpn-rules.sh (code=exited, status=0/SUCCESS)
  Process: 954 ExecStart=/etc/iptables/add-openvpn-rules.sh (code=exited, status=0/SUCCESS)
 Main PID: 954 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/iptables-openvpn.service

Aug 24 00:22:16 vpn.vrvrpersonal.com systemd[1]: Stopped iptables rules for OpenVPN.
Aug 24 00:22:16 vpn.vrvrpersonal.com systemd[1]: Starting iptables rules for OpenVPN...
Aug 24 00:22:16 vpn.vrvrpersonal.com systemd[1]: Started iptables rules for OpenVPN.
-bash-4.2# systemctl status openvpn-server@server.service
● openvpn-server@server.service - OpenVPN service for server
   Loaded: loaded (/etc/systemd/system/openvpn-server@.service; enabled; vendor preset: disabled)
   Active: active (running) since Sat 2024-08-24 00:22:30 BST; 41min ago
     Docs: man:openvpn(8)
           https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
           https://community.openvpn.net/openvpn/wiki/HOWTO
 Main PID: 968 (openvpn)
   Status: "Initialization Sequence Completed"
   CGroup: /system.slice/system-openvpn\x2dserver.slice/openvpn-server@server.service
           └─968 /usr/sbin/openvpn --status /run/openvpn-server/status-server.log --status-version 2 --suppress-timestamps --config server.conf

Aug 24 00:52:09 vpn.vrvrpersonal.com openvpn[968]: MY_CLIENT_IP:1540 [vrvrpersonal] Peer Connection Initiated with [AF_INET]MY_CLIENT_IP:1540
Aug 24 00:52:09 vpn.vrvrpersonal.com openvpn[968]: vrvrpersonal/MY_CLIENT_IP:1540 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
Aug 24 00:52:09 vpn.vrvrpersonal.com openvpn[968]: vrvrpersonal/MY_CLIENT_IP:1540 MULTI: Learn: 10.8.0.2 -> vrvrpersonal/MY_CLIENT_IP:1540
Aug 24 00:52:09 vpn.vrvrpersonal.com openvpn[968]: vrvrpersonal/MY_CLIENT_IP:1540 MULTI: primary virtual IP for vrvrpersonal/MY_CLIENT_IP:1540: 10.8.0.2
Aug 24 00:52:09 vpn.vrvrpersonal.com openvpn[968]: vrvrpersonal/MY_CLIENT_IP:1540 PUSH: Received control message: 'PUSH_REQUEST'
Aug 24 00:52:09 vpn.vrvrpersonal.com openvpn[968]: vrvrpersonal/MY_CLIENT_IP:1540 SENT CONTROL [vrvrpersonal]: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,i...S-128-GCM' (status=1)
Aug 24 00:52:09 vpn.vrvrpersonal.com openvpn[968]: vrvrpersonal/MY_CLIENT_IP:1540 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Aug 24 00:52:09 vpn.vrvrpersonal.com openvpn[968]: vrvrpersonal/MY_CLIENT_IP:1540 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Aug 24 00:56:10 vpn.vrvrpersonal.com openvpn[968]: vrvrpersonal/MY_CLIENT_IP:1540 [vrvrpersonal] Inactivity timeout (--ping-restart), restarting
Aug 24 00:56:10 vpn.vrvrpersonal.com openvpn[968]: vrvrpersonal/MY_CLIENT_IP:1540 SIGUSR1[soft,ping-restart] received, client-instance restarting
Hint: Some lines were ellipsized, use -l to show in full.

На клиенте стоит windows 10, могу подключиться через openvpn, но тогда «пропадает» интернет. Сам сервер с клиента пингуется и с сервера инет есть (по крайней мере можно, например, скачать что-нибудь через wget). Пробовал включать, пока играл с друзьями с дискордом, в результате во время работы впна я их слышу, остаюсь в игре, но они меня не слышат и я не могу открывать сайты, скачивать что-то и тд.

Конфиг сервера:

port EXTERNAL_PORT
proto udp
dev tun
user nobody
group nobody
persist-key
persist-tun
keepalive 10 120
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "redirect-gateway def1 bypass-dhcp"
dh none
ecdh-curve prime256v1
tls-crypt tls-crypt.key
crl-verify crl.pem
ca ca.crt
cert server_e91xjcnHwH1cpPqx.crt
key server_e91xjcnHwH1cpPqx.key
auth SHA256
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
tls-server
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
client-config-dir /etc/openvpn/ccd
status /var/log/openvpn/status.log
verb 3

Конфиг юзера:

client
proto udp
explicit-exit-notify
remote EXTERNAL_IP EXTERNAL_PORT
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_e91xjcnHwH1cpPqx name
auth SHA256
auth-nocache
cipher AES-128-GCM
tls-client
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
ignore-unknown-option block-outside-dns
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3
<ca>
-----BEGIN CERTIFICATE-----
SERTIFICATE
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
SERTIFICATE
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
KEY
-----END PRIVATE KEY-----
</key>
<tls-crypt>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
KEY
-----END OpenVPN Static key V1-----
</tls-crypt>

syslogа почему-то нет, откуда еще можно вытащить логи на стороне сервера - не знаю. Есть логи на стороне клиента:

[Aug 24, 2024, 02:40:56] SetupClient: signaling tun destroy event
⏎[Aug 24, 2024, 02:40:56] EVENT: DISCONNECTED ⏎[Aug 24, 2024, 02:41:10] OpenVPN core 3.10_qa win x86_64 64-bit OVPN-DCO built on Jul 17 2024 14:22:15
⏎[Aug 24, 2024, 02:41:10] Frame=512/2112/512 mssfix-ctrl=1250
⏎[Aug 24, 2024, 02:41:10] NOTE: This configuration contains options that were not used:
⏎[Aug 24, 2024, 02:41:10] Ignored by option 'ignore-unknown-option'
⏎[Aug 24, 2024, 02:41:10] 0 [block-outside-dns]
⏎[Aug 24, 2024, 02:41:10] Unsupported option (ignored)
⏎[Aug 24, 2024, 02:41:10] 0 [explicit-exit-notify]
⏎[Aug 24, 2024, 02:41:10] 1 [resolv-retry] [infinite]
⏎[Aug 24, 2024, 02:41:10] 2 [persist-key]
⏎[Aug 24, 2024, 02:41:10] 3 [persist-tun]
⏎[Aug 24, 2024, 02:41:10] EVENT: RESOLVE ⏎[Aug 24, 2024, 02:41:10] Contacting EXTERNAL_IP:EXTERNAL_PORT via UDP
⏎[Aug 24, 2024, 02:41:10] EVENT: WAIT ⏎[Aug 24, 2024, 02:41:10] WinCommandAgent: transmitting bypass route to EXTERNAL_IP
{
	"host" : "EXTERNAL_IP",
	"ipv6" : false
}

⏎[Aug 24, 2024, 02:41:10] Connecting to [EXTERNAL_IP]:EXTERNAL_PORT (EXTERNAL_IP) via UDP
⏎[Aug 24, 2024, 02:41:10] EVENT: CONNECTING ⏎[Aug 24, 2024, 02:41:10] Tunnel Options:V4,dev-type tun,link-mtu 1521,tun-mtu 1500,proto UDPv4,cipher AES-128-GCM,auth [null-digest],keysize 128,key-method 2,tls-client
⏎[Aug 24, 2024, 02:41:10] Creds: UsernameEmpty/PasswordEmpty
⏎[Aug 24, 2024, 02:41:10] Sending Peer Info:
IV_VER=3.10_qa
IV_PLAT=win
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2974
IV_MTU=1600
IV_CIPHERS=AES-128-CBC:AES-192-CBC:AES-256-CBC:AES-128-GCM:AES-192-GCM:AES-256-GCM:CHACHA20-POLY1305
IV_AUTO_SESS=1
IV_GUI_VER=OCWindows_3.5.0-3818
IV_SSO=webauth,crtext

⏎[Aug 24, 2024, 02:41:10] SSL Handshake: peer certificate: CN=server_e91xjcnHwH1cpPqx, 256 bit EC, group:prime256v1, cipher: ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128)            Mac=AEAD

⏎[Aug 24, 2024, 02:41:10] Session is ACTIVE
⏎[Aug 24, 2024, 02:41:10] EVENT: GET_CONFIG ⏎[Aug 24, 2024, 02:41:10] Sending PUSH_REQUEST to server...
⏎[Aug 24, 2024, 02:41:10] OPTIONS:
0 [dhcp-option] [DNS] [8.8.8.8]
1 [dhcp-option] [DNS] [8.8.4.4]
2 [redirect-gateway] [def1]
3 [route-gateway] [10.8.0.1]
4 [topology] [subnet]
5 [ping] [10]
6 [ping-restart] [120]
7 [ifconfig] [10.8.0.2] [255.255.255.0]
8 [peer-id] [0]
9 [cipher] [AES-128-GCM]

⏎[Aug 24, 2024, 02:41:10] PROTOCOL OPTIONS:
  cipher: AES-128-GCM
  digest: none
  key-derivation: OpenVPN PRF
  compress: NONE
  peer ID: 0
  control channel: tls-crypt enabled

⏎[Aug 24, 2024, 02:41:10] EVENT: ASSIGN_IP ⏎[Aug 24, 2024, 02:41:10] CAPTURED OPTIONS:
Session Name: EXTERNAL_IP
Layer: OSI_LAYER_3
Remote Address: EXTERNAL_IP
Tunnel Addresses:
  10.8.0.2/24 -> 10.8.0.1
Reroute Gateway: IPv4=1 IPv6=0 flags=[ ENABLE REROUTE_GW DEF1 IPv4 ]
Block IPv4: no
Block IPv6: no
Block local DNS: no
Add Routes:
Exclude Routes:
DNS Servers:
  8.8.8.8
  8.8.4.4

⏎[Aug 24, 2024, 02:41:11] SetupClient: transmitting tun setup list to \\.\pipe\agent_ovpnconnect
{
	"allow_local_dns_resolvers" : false,
	"confirm_event" : "b00f000000000000",
	"destroy_event" : "ac0f000000000000",
	"tun" : 
	{
		"adapter_domain_suffix" : "",
		"block_ipv6" : false,
		"block_outside_dns" : false,
		"dns_options" : 
		{
			"servers" : {}
		},
		"dns_servers" : 
		[
			{
				"address" : "8.8.8.8",
				"ipv6" : false
			},
			{
				"address" : "8.8.4.4",
				"ipv6" : false
			}
		],
		"layer" : 3,
		"mtu" : 0,
		"remote_address" : 
		{
			"address" : "EXTERNAL_IP",
			"ipv6" : false
		},
		"reroute_gw" : 
		{
			"flags" : 275,
			"ipv4" : true,
			"ipv6" : false
		},
		"route_metric_default" : -1,
		"session_name" : "EXTERNAL_IP",
		"tunnel_address_index_ipv4" : 0,
		"tunnel_address_index_ipv6" : -1,
		"tunnel_addresses" : 
		[
			{
				"address" : "10.8.0.2",
				"gateway" : "10.8.0.1",
				"ipv6" : false,
				"metric" : -1,
				"net30" : false,
				"prefix_length" : 24
			}
		]
	},
	"tun_type" : 0
}
POST np://[\\.\pipe\agent_ovpnconnect]/tun-setup : 200 OK
TAP ADAPTERS:
guid='{9902C2FF-200B-4944-91BB-240D651D9D24}' index=14 name='Подключение по локальной сети 2'
Open TAP device "Подключение по локальной сети 2" PATH="\\.\Global\{9902C2FF-200B-4944-91BB-240D651D9D24}.tap" SUCCEEDED
TAP-Windows Driver Version 9.27
ActionDeleteAllRoutesOnInterface iface_index=14
netsh interface ip set interface 14 metric=9000
ОК.
netsh interface ip set address 14 static 10.8.0.2 255.255.255.0 gateway=10.8.0.1 store=active
netsh interface ip add route EXTERNAL_IP/32 2 192.168.0.1 store=active
Этот объект уже существует.
netsh interface ip add route 0.0.0.0/1 14 10.8.0.1 store=active
ОК.
netsh interface ip add route 128.0.0.0/1 14 10.8.0.1 store=active
ОК.
netsh interface ip set dnsservers 14 static 8.8.8.8 register=primary validate=no
netsh interface ip add dnsservers 14 8.8.4.4 2 validate=no
NRPT::ActionCreate pid=[1012] domains=[] dns_servers=[8.8.8.8,8.8.4.4] dnssec=[0] id=[OpenVPNDNSRouting-1012]
ActionBase openvpn_app_path=C:\Program Files\OpenVPN Connect\OpenVPNConnect.exe tap_index=14 enable=1
permit IPv4 requests from OpenVPN app
permit IPv6 requests from OpenVPN app
block IPv4 requests from other apps
block IPv6 requests from other apps
allow IPv4 traffic from TAP
allow IPv6 traffic from TAP
block IPv4 DNS requests to loopback from other apps
block IPv6 DNS requests to loopback from other apps
ipconfig /flushdns
Настройка протокола IP для Windows
Кэш сопоставителя DNS успешно очищен.
TAP: ARP flush succeeded
TAP handle: 700f000000000000
⏎[Aug 24, 2024, 02:41:11] Connected via TUN_WIN
⏎[Aug 24, 2024, 02:41:11] EVENT: CONNECTED EXTERNAL_IP:EXTERNAL_PORT (EXTERNAL_IP) via /UDP on TUN_WIN/10.8.0.2/ gw=[10.8.0.1/] mtu=(default)⏎[Aug 24, 2024, 02:41:23] SetupClient: signaling tun destroy event
⏎[Aug 24, 2024, 02:41:23] EVENT: DISCONNECTED ⏎

Пробовал смотреть через tcpdump -eni any port. На 53 порту тишина, на порте, который я выбрал для впна, пакеты идут. На стороне клиента, когда я подключен к впну, появляются ipшники DNS - серверов в локальной сети 2. На всякий случай еще пробовал полностью вырубать брандмауэр на винде, не помогает

Из-за чего может быть эта проблема и что делать с ней?

Этот сервер у меня уже года 3, в начале он точно работал хорошо, когда именно начались проблемы - сказать точно не могу, но до сегодняшнего дня я по ssh-у его и не трогал



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

Ответ на: комментарий от anonymous
-bash-4.2# ip addr
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: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/void
    inet 127.0.0.1/32 scope host venet0
       valid_lft forever preferred_lft forever
    inet 10.10.52.126/32 brd 10.10.52.126 scope global venet0:0
       valid_lft forever preferred_lft forever
    inet6 2a01:4f9:2a:14e2:2f5::e7b4/80 scope global
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::2136:8f9d:bc81:d706/64 scope link flags 800
       valid_lft forever preferred_lft forever
-bash-4.2# iptables-save
# Generated by iptables-save v1.4.21 on Sat Aug 24 12:20:04 2024
*raw
:PREROUTING ACCEPT [117576:64807678]
:OUTPUT ACCEPT [61358:61182233]
COMMIT
# Completed on Sat Aug 24 12:20:04 2024
# Generated by iptables-save v1.4.21 on Sat Aug 24 12:20:04 2024
*nat
:PREROUTING ACCEPT [624:169222]
:INPUT ACCEPT [51:3974]
:OUTPUT ACCEPT [49:3831]
:POSTROUTING ACCEPT [49:3831]
-A POSTROUTING -s 10.8.0.0/24 -o venet0 -j MASQUERADE
COMMIT
# Completed on Sat Aug 24 12:20:04 2024
# Generated by iptables-save v1.4.21 on Sat Aug 24 12:20:04 2024
*mangle
:PREROUTING ACCEPT [117576:64807678]
:INPUT ACCEPT [39116:5894021]
:FORWARD ACCEPT [78442:58910644]
:OUTPUT ACCEPT [61359:61182693]
:POSTROUTING ACCEPT [139801:120093337]
COMMIT
# Completed on Sat Aug 24 12:20:04 2024
# Generated by iptables-save v1.4.21 on Sat Aug 24 12:20:04 2024
*filter
:INPUT ACCEPT [2292:210821]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [51668:58574716]
-A INPUT -i venet0 -p udp -m udp --dport 12610 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -i tun0 -o venet0 -j ACCEPT
-A FORWARD -i venet0 -o tun0 -j ACCEPT
COMMIT
# Completed on Sat Aug 24 12:20:04 2024
# Generated by iptables-save v1.4.21 on Sat Aug 24 12:20:04 2024
*security
:INPUT ACCEPT [39116:5894021]
:FORWARD ACCEPT [78442:58910644]
:OUTPUT ACCEPT [61367:61184069]
COMMIT
# Completed on Sat Aug 24 12:20:04 2024
-bash-4.2#

Не знаю, какой смысл ставить клиент на онтопике, то бишь сервере, но если чего не знаю - вот лог, само собой он залипает

-bash-4.2# sudo openvpn --config vrvrpersonal.ovpn
Sat Aug 24 12:21:27 2024 Unrecognized option or missing or extra parameter(s) in vrvrpersonal.ovpn:19: block-outside-dns (2.4.12)
Sat Aug 24 12:21:27 2024 OpenVPN 2.4.12 x86_64-redhat-linux-gnu [Fedora EPEL patched] [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 17 2022
Sat Aug 24 12:21:27 2024 library versions: OpenSSL 1.0.2k-fips  26 Jan 2017, LZO 2.06
Sat Aug 24 12:21:27 2024 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sat Aug 24 12:21:27 2024 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Aug 24 12:21:27 2024 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sat Aug 24 12:21:27 2024 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Aug 24 12:21:27 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]EXTERNAL_IP:EXTERNAL_PORT
Sat Aug 24 12:21:27 2024 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Aug 24 12:21:27 2024 UDP link local: (not bound)
Sat Aug 24 12:21:27 2024 UDP link remote: [AF_INET]EXTERNAL_IP:EXTERNAL_PORT
Sat Aug 24 12:22:27 2024 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Aug 24 12:22:27 2024 TLS Error: TLS handshake failed
Sat Aug 24 12:22:27 2024 SIGUSR1[soft,tls-error] received, process restarting
Sat Aug 24 12:22:27 2024 Restart pause, 5 second(s)
Sat Aug 24 12:22:32 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]EXTERNAL_IP:EXTERNAL_PORT
Sat Aug 24 12:22:32 2024 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Aug 24 12:22:32 2024 UDP link local: (not bound)
Sat Aug 24 12:22:32 2024 UDP link remote: [AF_INET]EXTERNAL_IP:EXTERNAL_PORT
^CSat Aug 24 12:23:00 2024 event_wait : Interrupted system call (code=4)
Sat Aug 24 12:23:00 2024 SIGTERM received, sending exit notification to peer
Sat Aug 24 12:23:01 2024 SIGTERM[soft,exit-with-notification] received, process exiting

Еще попробовал подключиться с других систем, инет есть с ноута, подключенного к домашнему wifi в той же локалке под эндевором, и нет на нем же под виндой и в лайв буте эндевора на осн компе

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

Конфиг с которым я ставил openvpn уже должен был настроить NAT. Я прописал в /etc/sysctl.conf net.ipv4.ip_forward = 1, потом sysctl -p. Firewalld и ufw у меня нет, прописал правила в iptables:

sudo iptables -A INPUT -p tcp -i venet0 --dport 12610 -j ACCEPT
sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
sudo service iptables save

Сейчас интерфейсы и правила у меня выглядят так:

-bash-4.2# iptables -L -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
MASQUERADE  all  --  10.8.0.0/24          anywhere

-bash-4.2# ip route list default
default dev venet0 scope link
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
169.254.0.0/16 dev venet0 scope link metric 1002

-bash-4.2# iptables-save
# Generated by iptables-save v1.4.21 on Sun Aug 25 19:28:10 2024
*raw
:PREROUTING ACCEPT [3778:210365]
:OUTPUT ACCEPT [6555:1803386]
COMMIT
# Completed on Sun Aug 25 19:28:10 2024
# Generated by iptables-save v1.4.21 on Sun Aug 25 19:28:10 2024
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.8.0.0/24 -o venet0 -j MASQUERADE
-A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on Sun Aug 25 19:28:10 2024
# Generated by iptables-save v1.4.21 on Sun Aug 25 19:28:10 2024
*mangle
:PREROUTING ACCEPT [3778:210365]
:INPUT ACCEPT [3770:209709]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6564:1804230]
:POSTROUTING ACCEPT [6564:1804230]
COMMIT
# Completed on Sun Aug 25 19:28:10 2024
# Generated by iptables-save v1.4.21 on Sun Aug 25 19:28:10 2024
*filter
:INPUT ACCEPT [26:2084]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [32:3104]
-A INPUT -i venet0 -p udp -m udp --dport EXTERNAL_PORT -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -i venet0 -p tcp -m tcp --dport EXTERNAL_PORT -j ACCEPT
-A FORWARD -i tun0 -o venet0 -j ACCEPT
-A FORWARD -i venet0 -o tun0 -j ACCEPT
COMMIT
# Completed on Sun Aug 25 19:28:10 2024
# Generated by iptables-save v1.4.21 on Sun Aug 25 19:28:10 2024
*security
:INPUT ACCEPT [3770:209709]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6564:1804230]
COMMIT
# Completed on Sun Aug 25 19:28:10 2024

Если верить графику в gui openvpn на клиенте, от сервера в самом начале прилетает куча пакетов, после чего он молчит. На сервере под tcpdump -eli any port EXTERNAL_PORT похожая история, когда подключаюсь от клиента, появляется куча пакетов, после чего тишина

DeadM00n
() автор топика
Ответ на: комментарий от kostik87
-bash-4.2# cat /proc/sys/net/ipv4/ip_forward
1

Если правильно понял, о чем речь, на клиенте в netstat после подключения появляются новые маршруты ipv4:

Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
...
          0.0.0.0          0.0.0.0         10.8.0.1         10.8.0.2   9001
          0.0.0.0        128.0.0.0         10.8.0.1         10.8.0.2   9256
         10.8.0.0    255.255.255.0         On-link          10.8.0.2   9256
         10.8.0.2  255.255.255.255         On-link          10.8.0.2   9256
       10.8.0.255  255.255.255.255         On-link          10.8.0.2   9256

      EXTERNAL_IP  255.255.255.255      192.168.0.1    192.168.0.107    291

        128.0.0.0        128.0.0.0         10.8.0.1         10.8.0.2   9256

        224.0.0.0        240.0.0.0         On-link          10.8.0.2   9256

  255.255.255.255  255.255.255.255         On-link          10.8.0.2   9256

Это openvz контейнер, от хоста у меня внутренний и внешний ipшник, то бишь у них стоит нат. venet0 был с самого начала как default, tun0 появился после установки сервера и судя по ip route list default является как раз его интерфейсом

DeadM00n
() автор топика

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

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

Вы сначала проверьте, что пакеты действительно блочатся. То есть начинайте с пинга тунельного адреса openvpn-сервера (10.8.0.1), потом на него должно проходить подключение по ssh и т.д.

Зачем вы добавили это правило:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Почему вы показываете маршруты выводом netstat, а не ″ip route″?

openvpn сервер вы установили, чтобы через него в инет ходить?

P.S. Не надо вывод ″iptables-save″ дублировать выводом ″iptables -L″, итак много букв.

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

Вы сначала проверьте, что пакеты действительно блочатся. То есть начинайте с пинга тунельного адреса openvpn-сервера (10.8.0.1), потом на него должно проходить подключение по ssh и т.д.

Со включенным впном шлюз не пингуется, в отличии от внешнего ipшника. По sshу туда, само собой, не подключиться, что еще тестить - не знаю

Зачем вы добавили это правило:

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

Почему вы показываете маршруты выводом netstat, а не ″ip route″?

Потому что клиент на win10

openvpn сервер вы установили, чтобы через него в инет ходить?

да

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

Ну запустите на винде ping, а сервере смотрите tcpdump'ом. Сначала просто icmp-пакеты, если их нет, тогда udp-пакеты на этом EXTERNAL_PORT.

На каждый отправляемый в тунель icmp-пакет должен возникать транспортный udp-пакет. До кучи можно ещё на винду поставить wireshark (или как его там сейчас) и там подампить пакеты. Или на шлюзе 192.168.0.1 подампить пакеты. Убедиться что винда отправляет udp-пакет, а на сервере он не приходит. Если это так, значит, провайдер/хостер режет. Тогда думать чем заменить OpenVPN, ну или хостера...

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

Попробовал, получилось так: на стороне сервера tcpdump не видел icmp пакеты вообще (в т.ч. без порта и с -i any), на внешнем порте периодически прилетали однотипные udp без зависимости от пинга. Без особой цели оставил минут на 5-10 с мониторингом icmp по всем интерфейсам, вернулся и о чудо, интернет есть, icmp летят, udp слишком много чтобы как-то разбирать их по отдельности. Методом тыка выяснил, что эти icmp на tun0. То же самое повторилось еще раза 4. Было такое, что сервер принимает пакеты, но винда ответ не получает. Без ответа лог выглядел примерно так:

22:14:18.912041 IP (tos 0x0, ttl 128, id 8520, offset 0, flags [none], proto ICMP (1), length 60)
    10.8.0.2 > vpn.vrvrpersonal.com: ICMP echo request, id 1, seq 639, length 40
22:14:18.912062 IP (tos 0x0, ttl 64, id 15010, offset 0, flags [none], proto ICMP (1), length 60)
    vpn.vrvrpersonal.com > 10.8.0.2: ICMP echo reply, id 1, seq 639, length 40
22:14:23.916718 IP (tos 0x0, ttl 128, id 8521, offset 0, flags [none], proto ICMP (1), length 60)
    10.8.0.2 > vpn.vrvrpersonal.com: ICMP echo request, id 1, seq 640, length 40
22:14:23.916732 IP (tos 0x0, ttl 64, id 15121, offset 0, flags [none], proto ICMP (1), length 60)
    vpn.vrvrpersonal.com > 10.8.0.2: ICMP echo reply, id 1, seq 640, length 40

С ответом (я разницы не вижу):

22:10:31.797016 IP (tos 0x0, ttl 128, id 45513, offset 0, flags [none], proto ICMP (1), length 60)
    10.8.0.2 > vpn.vrvrpersonal.com: ICMP echo request, id 1, seq 556, length 40
22:10:31.797037 IP (tos 0x0, ttl 64, id 27250, offset 0, flags [none], proto ICMP (1), length 60)
    vpn.vrvrpersonal.com > 10.8.0.2: ICMP echo reply, id 1, seq 556, length 40
22:10:32.802628 IP (tos 0x0, ttl 128, id 45514, offset 0, flags [none], proto ICMP (1), length 60)
    10.8.0.2 > vpn.vrvrpersonal.com: ICMP echo request, id 1, seq 557, length 40

В этот момент в логах клиента такая картина (пинг начал проходить в 00:49):

2024-08-27 00:47:25 Preserving previous TUN/TAP instance: OpenVPN Data Channel Offload
2024-08-27 00:47:25 Blocking outside dns using service succeeded.
2024-08-27 00:47:25 Initialization Sequence Completed
2024-08-27 00:47:25 MANAGEMENT: >STATE:1724708845,CONNECTED,SUCCESS,10.8.0.2,EXTERNAL_IP,EXTERNAL_PORT,,
2024-08-27 00:47:25 Data Channel: cipher 'AES-128-GCM', peer-id: 1
2024-08-27 00:47:25 Timers: ping 10, ping-restart 120
2024-08-27 00:47:25 Protocol options: explicit-exit-notify 1
2024-08-27 00:49:28 read UDP: Указанное сетевое имя более недоступно.   (fd=1a4,code=64)
2024-08-27 00:49:28 [server_ACCqQUwimJdMxzMh] Inactivity timeout (--ping-restart), restarting
2024-08-27 00:49:28 Unblocking outside dns using service succeeded.
2024-08-27 00:49:28 SIGUSR1[soft,ping-restart] received, process restarting
2024-08-27 00:49:28 MANAGEMENT: >STATE:1724708968,RECONNECTING,ping-restart,,,,,
2024-08-27 00:49:28 Restart pause, 1 second(s)
2024-08-27 00:49:29 TCP/UDP: Preserving recently used remote address: [AF_INET]EXTERNAL_IP:EXTERNAL_PORT
2024-08-27 00:49:29 UDP link local: (not bound)
2024-08-27 00:49:29 UDP link remote: [AF_INET]EXTERNAL_IP:EXTERNAL_PORT
2024-08-27 00:49:29 MANAGEMENT: >STATE:1724708969,WAIT,,,,,,
2024-08-27 00:49:29 MANAGEMENT: >STATE:1724708969,AUTH,,,,,,
2024-08-27 00:49:29 TLS: Initial packet from [AF_INET]EXTERNAL_IP:EXTERNAL_PORT, sid=4da5b932 ae15841c
2024-08-27 00:49:29 VERIFY OK: depth=1, CN=cn_0JCsUGCgK3ZRifQK
2024-08-27 00:49:29 VERIFY KU OK
2024-08-27 00:49:29 Validating certificate extended key usage
2024-08-27 00:49:29 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2024-08-27 00:49:29 VERIFY EKU OK
2024-08-27 00:49:29 VERIFY X509NAME OK: CN=server_ACCqQUwimJdMxzMh
2024-08-27 00:49:29 VERIFY OK: depth=0, CN=server_ACCqQUwimJdMxzMh
2024-08-27 00:49:29 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, peer certificate: 256 bits ECprime256v1, signature: ecdsa-with-SHA256, peer temporary key: 256 bits ECprime256v1
2024-08-27 00:49:29 [server_ACCqQUwimJdMxzMh] Peer Connection Initiated with [AF_INET]EXTERNAL_IP:EXTERNAL_PORT
2024-08-27 00:49:29 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2024-08-27 00:49:29 TLS: tls_multi_process: initial untrusted session promoted to trusted
2024-08-27 00:49:30 MANAGEMENT: >STATE:1724708970,GET_CONFIG,,,,,,
2024-08-27 00:49:30 SENT CONTROL [server_ACCqQUwimJdMxzMh]: 'PUSH_REQUEST' (status=1)
2024-08-27 00:49:30 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,redirect-gateway def1 bypass-dhcp,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-128-GCM'
2024-08-27 00:49:30 OPTIONS IMPORT: --ifconfig/up options modified
2024-08-27 00:49:30 OPTIONS IMPORT: route options modified
2024-08-27 00:49:30 OPTIONS IMPORT: route-related options modified
2024-08-27 00:49:30 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2024-08-27 00:49:30 Preserving previous TUN/TAP instance: OpenVPN Data Channel Offload
2024-08-27 00:49:30 Blocking outside dns using service succeeded.
2024-08-27 00:49:30 Initialization Sequence Completed
2024-08-27 00:49:30 MANAGEMENT: >STATE:1724708970,CONNECTED,SUCCESS,10.8.0.2,EXTERNAL_IP,EXTERNAL_PORT,,
2024-08-27 00:49:30 Data Channel: cipher 'AES-128-GCM', peer-id: 0
2024-08-27 00:49:30 Timers: ping 10, ping-restart 120
2024-08-27 00:49:30 Protocol options: explicit-exit-notify 1

В wireshark, когда пинг не проходит, видно безответные icmp и кучу черных tcp retransmission, когда проходит - по 2 icmp, много tcp, tls и еще в начале пачкой был quic. UDP, как ни странно, только у quic и dns пакетов, самих по себе udp нет

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

Не знаю, почему wireshark не показывает udp пакеты openvpn (транспортные), может это ограничение винды, может где какая настройка есть. Но без этого особо дальше не разобраться.

я разницы не вижу

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

udp слишком много чтобы как-то разбирать их по отдельности.

Видимо, на винде много софта, который в инет ломится. Если хочется дальше изучать, можете временно убрать «redirect-gateway», чтобы не прописывался default в тунель. Тогда в тунель отправится только 10.8.0.0, «левых» пакетов не будет, только icmp. Но, это имеет смысл, если на винде получится наблюдать транспортные udp-пакеты.

Как уже написал, похоже, что в какой-то момент времени udp-пакеты от OpenVPN сервера перестают проходить к клиенту. По таймауту происходит переподключение и какое-то время пакеты ходят в обе стороны. Либо какой-то хитрый/кривой фильтр у хостера, против OpenVPN, либо криво работающий NAT. Я уж не помню где видел такое поведение NAT для udp, что просто по таймауту пересатают проходить ответные пакеты. Может попробовать переключить OpenVPN на tcp.

У вас ведь два NAT'а — домашний маршрутизатор и потом ещё у провайдера? Домашний машрутизатор за три года не меняли, нагрузка на него значительно не увеличилась?

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

Видимо, мой косяк был, сейчас UDPшники показались

Для чистоты эксперимента я запускал ssh с другого устройства с мобильного инета

С точки зрения сервера ничего необычного, при подключении UDP сперва проходят пакеты туда-обратно, потом, после подключения, без ответа пакеты уходят в корбину (и на стороне винды не видны), после чего снова начинают ходить (когда инет появляется). Когда ходят туда-обратно, длины UDPшников на винде и на сервере совпадают, содержимое тоже

На клиенте в момент подключения, когда пропадает интернет, сразу после последнего запроса, пришедшего с сервера, видно несколько icmpv6 (и когда пробовал без пинга), igmpv2 (leave group, membership report, membership query), mdns, llmnr, ничего связанного с сервером среди них я не вижу. Перед появлением инета и первым UDP пакетом с сервера видно ssdp, арпы про 192.168.0.1XX (если важно, роутеры у меня на других адресах стоят) и все. Еще у UDPшек с ответом и без разные исходные порты, хотя в dst один и тот же внешний IP сервера и его порт. Никаких TLS не видно, есть TCP retransmissionы, но ни один из них не упоминает ни IP, связанные с сервером, ни используемые для связи порты, только перенаправляют 443 в 57230

Не знаю, с чего хост стал бы ставить блок на openvpn, раз они сами дают гайд по его настройке. Насчет NAT - не могу сказать точно, что на стороне провайдера, дома точно через роутер, кабель из подъезда втыкается в него и из роутера кабели идут к 2м компьютерам и еще одному роутеру в другой комнате. Правил переадресации на роутере нет вообще (то бишь виртуальные серверы, port triggering и upnp пустые), блокировка VPN выключена. За 3 года роутер не менял. Раньше между внешним миром и роутером был сыч, но он умер от перепада напряжения, с роутером проблем тогда не было, а с vpnом появились еще раньше

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

Еще у UDPшек с ответом и без разные исходные порты, хотя в dst один и тот же внешний IP сервера и его порт.

Ну, дак клиент переподключается и новое подключение открывает с нового порта. Исходя из описаного, наверное, можно принять врсию, что Корбина блочит openvpn. По нескольким пакетам их DPI определят, что по этому UDP соединению идёт openvpn и блочит его. А может более тупо, ограничивают объём, передаваемый по одном UDP-соединению. Поэтому сколько-то пакетов после подключения проходят, а дальше всё.

Какой тунельный протокол заработает через Корбину не знаю. Наверное, нужно гуглить/спрашивать на форумах истории успеха.

mky ★★★★★
()