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

Openvpn сервер не видит локальную сеть клиента

 ,


0

1

Настраиваю VPNсервер на Ubuntu 22.04 и клиент на winxp (знаю что старая но задача такая) все на VirtualBOX.
Локальный ip сервера 10.0.2.2
ip туннеля 10.8.0.1
Локальный ip клиента 10.0.3.4
ip туннеля 10.8.0.2
Защищенный канал устанавливается без проблем, с клиента до локального интерфейса сервера (10.0.2.2) пинг ходит, а вот с сервера локальный интерфейс клиента не пингуется, пакеты на стороны сервера в тоннель попадают (tcpdump логи приложу), а на стороне клиента пакеты не появляются. При этом в обратную сторону (пинг с клиента на сервер) все четко ходит по тоннелю в обе стороны. на сервере выставлена net.ipv4.ip_forward=1. на клиенте в винде ветра реестра стоит 1 и служба маршрутизации вкл (хотя и без нее пинги до сервера шли)

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

local 10.0.2.2
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
push «redirect-gateway def1 bypass-dhcp»
ifconfig-pool-persist ipp.txt
#client-config-dir /etc/openvpn/ccd
push «dhcp-option DNS 1.1.1.1»
push «dhcp-option DNS 1.0.0.1»
push «block-outside-dns»
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log

/etc/openvpn/ccd/client1 (по факту не использую)
#iroute 10.0.3.0 255.255.255.0 (когда строка раскомментирована клиент перестает подключаться к серверу)
#ifconfig-push 10.0.3.0 255.255.255.0

конфиг клиента

client
dev tun
proto udp
remote 10.132.56.42 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
verb 3
remote-metod exe
route-delay 5

ip сервера

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: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000  
    link/ether 08:00:27:32:58:3c brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.2/24 brd 10.0.2.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet 192.168.56.2/24 brd 192.168.56.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe32:583c/64 scope link
       valid_lft forever preferred_lft forever

3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500  
    link/none
    inet 10.8.0.1/24 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::c9b3:ae95:6103:dbac/64 scope link stable-privacy
       valid_lft forever preferred_lft forever

ip клиента

локальный 10.0.3.4/24
VPN-tun 10.8.0.2/24

таблица маршрутов сервера

Destination     Gateway         Genmask         Flags   MSS
 Window  irtt Iface  
0.0.0.0         10.0.2.1        0.0.0.0         UG        0 0          0 enp0s3  
10.0.2.0        0.0.0.0         255.255.255.0   U         0 0          0 enp0s3  
10.0.3.0        10.8.0.1        255.255.255.0   UG        0 0          0 tun0  
10.8.0.0        0.0.0.0         255.255.255.0   U         0 0          0 tun0  
192.168.56.0    0.0.0.0         255.255.255.0   U         0 0          0 enp0s3

Таблица клиента

Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 10.0.3.1 10.0.3.4 1
0.0.0.0 128.0.0.0 10.8.0.1 10.8.0.2 1
10.0.3.0 255.255.255.0 10.0.3.4 10.0.3.4 10
10.0.3.4 255.255.255.255 127.0.0.1 127.0.0.1 10
10.8.0.0 255.255.255.0 10.8.0.2 10.8.0.2 3
10.8.0.2 255.255.255.255 127.0.0.1 127.0.0.1 3
10.132.56.42 255.255.255.255 10.0.3.1 10.0.3.4 1
10.255.255.255 255.255.255.255 10.0.3.4 10.0.3.4 10
10.255.255.255 255.255.255.255 10.8.0.2 10.8.0.2 3
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
128.0.0.0 128.0.0.0 10.8.0.1 10.8.0.2 1
224.0.0.0 240.0.0.0 10.0.3.4 10.0.3.4 10
224.0.0.0 240.0.0.0 10.8.0.2 10.8.0.2 3
255.255.255.255 255.255.255.255 10.0.3.4 10.0.3.4 1
255.255.255.255 255.255.255.255 10.8.0.2 10.8.0.2 1
Основной шлюз: 10.8.0.1

tcpdump с сервера при пинге ip клиента 10.0.3.4

 tcpdump -i tun0 -n -nn -ttt 'ip proto \icmp' -vv

tcpdump: listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes

 00:00:00.000000 IP (tos 0x0, ttl 64, id 12046, offset 0, flags [DF], proto ICMP (1), length 84)
    10.8.0.1 > 10.0.3.4: ICMP echo request, id 22, seq 2251, length 64

 00:00:01.024808 IP (tos 0x0, ttl 64, id 12142, offset 0, flags [DF], proto ICMP (1), length 84)

    10.8.0.1 > 10.0.3.4: ICMP echo request, id 22, seq 2252, length 64
 00:00:01.023688 IP (tos 0x0, ttl 64, id 12213, offset 0, flags [DF], proto ICMP (1), length 84)

    10.8.0.1 > 10.0.3.4: ICMP echo request, id 22, seq 2253, length 64
 00:00:01.024084 IP (tos 0x0, ttl 64, id 12254, offset 0, flags [DF], proto ICMP (1), length 84)

    10.8.0.1 > 10.0.3.4: ICMP echo request, id 22, seq 2254, length 64

tcpdump c клиента пустой.

видно что пакеты в тунель уходят, но до клиента не доходят

iptables-save  
 
*filter  
:INPUT ACCEPT [0:0]  
:FORWARD ACCEPT [0:0]  
:OUTPUT ACCEPT [0:0]  
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT  
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT  
-A FORWARD -s 10.8.0.0/24 -j ACCEPT  
COMMIT  

*nat  
:PREROUTING ACCEPT [0:0]  
:INPUT ACCEPT [0:0]  
:OUTPUT ACCEPT [0:0]  
:POSTROUTING ACCEPT [0:0]  
COMMIT

Кучу форумов пересмотрел с похожей проблемой. В основном все пишут про настройку нат на сервере. Пробовал добавить правило в Iptables, как советуют:

iptables -t nat -A POSTROUTING -o enp0s3 -j SNAT --to-source 192.168.56.2 или 10.0.2.2

подставлять не помогает.

Уже кучу времени убил. Помогите пожалуйста.



Последнее исправление: testik777 (всего исправлений: 6)
← Postgresql не удаляет таблицу
Не работает dns в netns →
Ответ на: комментарий от Flotsky

это я вручную прописал. без него пинги идут через 10.0.2.2.

tcpdump -i enp0s3 -n -nn -ttt 'ip proto \icmp' -vvtcpdump: listening on enp0s3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
 00:00:00.000000 IP (tos 0x0, ttl 64, id 29033, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.2.2 > 10.0.3.4: ICMP echo request, id 23, seq 53, length 64
 00:00:00.047239 IP (tos 0x0, ttl 243, id 21737, offset 0, flags [none], proto ICMP (1), length 56)
    10.0.253.2 > 10.0.2.2: ICMP time exceeded in-transit, length 36
        IP (tos 0x0, ttl 64, id 29033, offset 0, flags [DF], proto ICMP (1), length 84)

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

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

это я вручную прописал.

Удали, в сервер добавь route 10.0.3.0 255.255.255.0 и перезапусти сервер.

#iroute 10.0.3.0 255.255.255.0 (когда строка раскомментирована клиент перестает подключаться к серверу)

iroute нужен, на клиента влиять не должен. Раскомментируй, проверь ещё раз, посмотри на ошибки при подключении у клиента и сервера.

Если понятнее не станет, ошибки сюда покажи

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

строку в конфиг сервера добавил, службу openvpn перезагрузил (systemctl restart openvpn) но маршрут не появляется

netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.2.1        0.0.0.0         UG        0 0          0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U         0 0          0 enp0s3
10.8.0.0        0.0.0.0         255.255.255.0   U         0 0          0 tun0
192.168.56.0    0.0.0.0         255.255.255.0   U         0 0          0 enp0s3

строку в сcd раскомментировал. Клиент стал цепляться. пинги на 10.0.3.4 так и не идут tcpdump такой же как в прошлом ответе.

лог сервера

10.132.56.42:59464 Outgoing Control Channel Encryption: Cipher 'AES-
256-CTR' initialized with 256 bit key
10.132.56.42:59464 Outgoing Control Channel Encryption: Using 256 bit message ha
sh 'SHA256' for HMAC authentication
10.132.56.42:59464 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' ini
tialized with 256 bit key
10.132.56.42:59464 Incoming Control Channel Encryption: Using 256 bit message ha
sh 'SHA256' for HMAC authentication
10.132.56.42:59464 TLS: Initial packet from [AF_INET]10.132.56.42:59464, sid=fe8
13fe0 04d3f24c
10.132.56.42:59464 VERIFY OK: depth=1, CN=Easy-RSA CA
10.132.56.42:59464 VERIFY OK: depth=0, CN=client1
10.132.56.42:59464 peer info: IV_VER=2.5.4
10.132.56.42:59464 peer info: IV_PLAT=win
10.132.56.42:59464 peer info: IV_PROTO=6
10.132.56.42:59464 peer info: IV_NCP=2
10.132.56.42:59464 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-256-CBC
10.132.56.42:59464 peer info: IV_LZ4=1
10.132.56.42:59464 peer info: IV_LZ4v2=1
10.132.56.42:59464 peer info: IV_LZO=1
10.132.56.42:59464 peer info: IV_COMP_STUB=1
10.132.56.42:59464 peer info: IV_COMP_STUBv2=1
10.132.56.42:59464 peer info: IV_TCPNL=1
10.132.56.42:59464 peer info: IV_GUI_VER=OpenVPN_GUI_11
10.132.56.42:59464 peer info: IV_SSO=openurl,crtext
10.132.56.42:59464 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA3
84, peer certificate: 2048 bit RSA, signature: RSA-SHA256
10.132.56.42:59464 [client1] Peer Connection Initiated with [AF_INET]10.132.56.4
2:59464
MULTI: new connection by client 'client1' will cause previous active sessions by
 this client to be dropped.  Remember to use the --duplicate-cn option if you wa
nt multiple clients using the same certificate or username to concurrently conne
ct.
MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/client1
MULTI: Learn: 10.8.0.2 -> client1/10.132.56.42:59464
MULTI: primary virtual IP for client1/10.132.56.42:59464: 10.8.0.2
MULTI: internal route 10.0.3.0/24 -> client1/10.132.56.42:59464
MULTI: Learn: 10.0.3.0/24 -> client1/10.132.56.42:59464
Data Channel: using negotiated cipher 'AES-256-GCM'
Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
SENT CONTROL [client1]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-optio
n DNS 1.1.1.1,dhcp-option DNS 1.0.0.1,block-outside-dns,route-gateway 10.8.0.1,t
opology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0,peer-id
0,cipher AES-256-GCM' (status=1)

лог клиента

10.132.56.42:59464 Outgoing Control Channel Encryption: Cipher 'AES-
256-CTR' initialized with 256 bit key
10.132.56.42:59464 Outgoing Control Channel Encryption: Using 256 bit message ha
sh 'SHA256' for HMAC authentication
10.132.56.42:59464 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' ini
tialized with 256 bit key
10.132.56.42:59464 Incoming Control Channel Encryption: Using 256 bit message ha
sh 'SHA256' for HMAC authentication
10.132.56.42:59464 TLS: Initial packet from [AF_INET]10.132.56.42:59464, sid=fe8
13fe0 04d3f24c
10.132.56.42:59464 VERIFY OK: depth=1, CN=Easy-RSA CA
10.132.56.42:59464 VERIFY OK: depth=0, CN=client1
10.132.56.42:59464 peer info: IV_VER=2.5.4
10.132.56.42:59464 peer info: IV_PLAT=win
10.132.56.42:59464 peer info: IV_PROTO=6
10.132.56.42:59464 peer info: IV_NCP=2
10.132.56.42:59464 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-256-CBC
10.132.56.42:59464 peer info: IV_LZ4=1
10.132.56.42:59464 peer info: IV_LZ4v2=1
10.132.56.42:59464 peer info: IV_LZO=1
10.132.56.42:59464 peer info: IV_COMP_STUB=1
10.132.56.42:59464 peer info: IV_COMP_STUBv2=1
10.132.56.42:59464 peer info: IV_TCPNL=1
10.132.56.42:59464 peer info: IV_GUI_VER=OpenVPN_GUI_11
10.132.56.42:59464 peer info: IV_SSO=openurl,crtext
10.132.56.42:59464 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA3
84, peer certificate: 2048 bit RSA, signature: RSA-SHA256
10.132.56.42:59464 [client1] Peer Connection Initiated with [AF_INET]10.132.56.4
2:59464
MULTI: new connection by client 'client1' will cause previous active sessions by
 this client to be dropped.  Remember to use the --duplicate-cn option if you wa
nt multiple clients using the same certificate or username to concurrently conne
ct.
MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/client1
MULTI: Learn: 10.8.0.2 -> client1/10.132.56.42:59464
MULTI: primary virtual IP for client1/10.132.56.42:59464: 10.8.0.2
MULTI: internal route 10.0.3.0/24 -> client1/10.132.56.42:59464
MULTI: Learn: 10.0.3.0/24 -> client1/10.132.56.42:59464
Data Channel: using negotiated cipher 'AES-256-GCM'
Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
testik777
() автор топика
Последнее исправление: testik777 (всего исправлений: 1)
Ответ на: комментарий от Flotsky

Вообщем я как-то не правильно openvpn перезагружаю. Решил весь сервер перезагрузить. после этого новый конфиг подхватился. Маршрут прописался, но Пинги с сервера все также не идут, вывод tcpdump изменился.

tcpdump -i tun0 -n -nn -ttt 'ip proto \icmp' -vv
tcpdump: listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
 00:00:00.000000 IP (tos 0x0, ttl 64, id 50728, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.2.2 > 10.0.3.4: ICMP echo request, id 1, seq 26, length 64
 00:00:01.023978 IP (tos 0x0, ttl 64, id 50936, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.2.2 > 10.0.3.4: ICMP echo request, id 1, seq 27, length 64
 00:00:01.023671 IP (tos 0x0, ttl 64, id 51008, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.2.2 > 10.0.3.4: ICMP echo request, id 1, seq 28, length 64
 00:00:01.024521 IP (tos 0x0, ttl 64, id 51223, offset 0, flags [DF], proto ICMP (1), length 84)

лог сервера

DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (
AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher
 negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-C
BC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [
MH/PKTINFO] [AEAD] built on Jul 14 2022
library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
net_route_v4_best_gw query: dst 0.0.0.0
net_route_v4_best_gw result: via 10.0.2.1 dev enp0s3
Diffie-Hellman initialized with 2048 bit key
WARNING: Your certificate is not yet valid!
CRL: loaded 1 CRLs from file crl.pem
Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 b
it key
Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMA
C authentication
Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 b
it key
Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMA
C authentication
net_route_v4_best_gw query: dst 0.0.0.0
net_route_v4_best_gw result: via 10.0.2.1 dev enp0s3
ROUTE_GATEWAY 10.0.2.1/255.255.255.0 IFACE=enp0s3 HWADDR=08:00:27:32:58:3c
TUN/TAP device tun0 opened
net_iface_mtu_set: mtu 1500 for tun0
net_iface_up: set tun0 up
net_addr_v4_add: 10.8.0.1/24 dev tun0
net_route_v4_add: 10.0.3.0/24 via 10.8.0.2 dev [NULL] table 0 metric -1
Could not determine IPv4/IPv6 protocol. Using AF_INET
Socket Buffers: R=[212992->212992] S=[212992->212992]
UDPv4 link local (bound): [AF_INET]10.0.2.2:1194
UDPv4 link remote: [AF_UNSPEC]
GID set to nogroup
UID set to nobody
MULTI: multi_init called, r=256 v=256
IFCONFIG POOL IPv4: base=10.8.0.2 size=253
ifconfig_pool_read(), in='client1,10.8.0.2,'
succeeded -> ifconfig_pool_set(hand=0)
IFCONFIG POOL LIST
client1,10.8.0.2,
Initialization Sequence Completed
testik777
() автор топика
Ответ на: комментарий от testik777

Не вижу чтобы тут клиент подключился.

Раз с сервера пинги уходят куда надо, то может теперь посмотреть wireshark на стороне клиента? windows firewall по умолчанию режет пинги не из локальной сети.

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

а это разве правильный траффик? Мне кажется он должен с туннельного интерфейса (10.8.0.1) идти а нет с 10.0.2.2. у меня tcpdump консольный на виндовом клиенте тоже стоит. он молчит при всех тестах, что я делал. если я пинг с клиента запускаю то в нем начинают пакеты фиксироваться. фаервол виндовый сейчас отключен, включать тоже пробовал. Одинаковый эффект.

че-то не вложился лог клиента прошлый раз. выкладываю свежий.

Fri Jun  2 22:34:25 2023 MANAGEMENT: CMD 'signal SIGHUP'
Fri Jun  2 22:34:25 2023 C:\WINDOWS\system32\route.exe DELETE 10.132.56.42 MASK 255.255.255.255 10.0.3.1
Fri Jun  2 22:34:25 2023 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Fri Jun  2 22:34:25 2023 C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 128.0.0.0 10.8.0.1
Fri Jun  2 22:34:25 2023 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Fri Jun  2 22:34:25 2023 C:\WINDOWS\system32\route.exe DELETE 128.0.0.0 MASK 128.0.0.0 10.8.0.1
Fri Jun  2 22:34:25 2023 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Fri Jun  2 22:34:25 2023 Closing TUN/TAP interface
Fri Jun  2 22:34:25 2023 TAP: DHCP address released
Fri Jun  2 22:34:27 2023 SIGHUP[hard,init_instance] received, process restarting
Fri Jun  2 22:34:27 2023 MANAGEMENT: >STATE:1685720067,RECONNECTING,init_instance,,,,,
Fri Jun  2 22:34:27 2023 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
Fri Jun  2 22:34:27 2023 OpenVPN 2.5.4 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Jan 23 2022
Fri Jun  2 22:34:27 2023 Windows version 5.1 (Windows XP) 32bit
Fri Jun  2 22:34:27 2023 library versions: OpenSSL 1.1.1m-dev  xx XXX xxxx, LZO 2.10
Fri Jun  2 22:34:27 2023 Restart pause, 5 second(s)
Fri Jun  2 22:34:32 2023 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Fri Jun  2 22:34:32 2023 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Fri Jun  2 22:34:32 2023 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Fri Jun  2 22:34:32 2023 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Fri Jun  2 22:34:32 2023 TCP/UDP: Preserving recently used remote address: [AF_INET]10.132.56.42:1194
Fri Jun  2 22:34:32 2023 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Jun  2 22:34:32 2023 UDP link local: (not bound)
Fri Jun  2 22:34:32 2023 UDP link remote: [AF_INET]10.132.56.42:1194
Fri Jun  2 22:34:32 2023 MANAGEMENT: >STATE:1685720072,WAIT,,,,,,
Fri Jun  2 22:34:32 2023 MANAGEMENT: >STATE:1685720072,AUTH,,,,,,
Fri Jun  2 22:34:32 2023 TLS: Initial packet from [AF_INET]10.132.56.42:1194, sid=89fd652a 362ac8bb
Fri Jun  2 22:34:32 2023 VERIFY OK: depth=1, CN=Easy-RSA CA
Fri Jun  2 22:34:32 2023 VERIFY KU OK
Fri Jun  2 22:34:32 2023 Validating certificate extended key usage
Fri Jun  2 22:34:32 2023 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Jun  2 22:34:32 2023 VERIFY EKU OK
Fri Jun  2 22:34:32 2023 VERIFY OK: depth=0, CN=server
Fri Jun  2 22:34:32 2023 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
Fri Jun  2 22:34:32 2023 [server] Peer Connection Initiated with [AF_INET]10.132.56.42:1194
Fri Jun  2 22:34:32 2023 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 1.1.1.1,dhcp-option DNS 1.0.0.1,block-outside-dns,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-256-GCM'
Fri Jun  2 22:34:32 2023 OPTIONS IMPORT: timers and/or timeouts modified
Fri Jun  2 22:34:32 2023 OPTIONS IMPORT: --ifconfig/up options modified
Fri Jun  2 22:34:32 2023 OPTIONS IMPORT: route options modified
Fri Jun  2 22:34:32 2023 OPTIONS IMPORT: route-related options modified
Fri Jun  2 22:34:32 2023 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Jun  2 22:34:32 2023 OPTIONS IMPORT: peer-id set
Fri Jun  2 22:34:32 2023 OPTIONS IMPORT: adjusting link_mtu to 1624
Fri Jun  2 22:34:32 2023 OPTIONS IMPORT: data channel crypto options modified
Fri Jun  2 22:34:33 2023 Data Channel: using negotiated cipher 'AES-256-GCM'
Fri Jun  2 22:34:33 2023 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Fri Jun  2 22:34:33 2023 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Fri Jun  2 22:34:33 2023 interactive service msg_channel=0
Fri Jun  2 22:34:33 2023 ROUTE_GATEWAY 10.0.3.1/255.255.255.0 I=2 HWADDR=08:00:27:9d:0c:79
Fri Jun  2 22:34:33 2023 open_tun
Fri Jun  2 22:34:33 2023 tap-windows6 device [Подключение по локальной сети 6] opened
Fri Jun  2 22:34:33 2023 TAP-Windows Driver Version 9.9 
Fri Jun  2 22:34:33 2023 Set TAP-Windows TUN subnet mode network/local/netmask = 10.8.0.0/10.8.0.2/255.255.255.0 [SUCCEEDED]
Fri Jun  2 22:34:33 2023 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.2/255.255.255.0 on interface {AA335737-5E09-4A24-A728-482A2539A9EA} [DHCP-serv: 10.8.0.254, lease-time: 31536000]
Fri Jun  2 22:34:33 2023 NOTE: FlushIpNetTable failed on interface [3] {AA335737-5E09-4A24-A728-482A2539A9EA} (status=259) : Aiiieieoaeuiua aaiiua ionoonoao?o.  
Fri Jun  2 22:34:33 2023 MANAGEMENT: >STATE:1685720073,ASSIGN_IP,,10.8.0.2,,,,
Fri Jun  2 22:34:33 2023 IPv4 MTU set to 1500 on interface 3 using SetIpInterfaceEntry()
Fri Jun  2 22:34:45 2023 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Fri Jun  2 22:34:45 2023 C:\WINDOWS\system32\route.exe ADD 10.132.56.42 MASK 255.255.255.255 10.0.3.1
Fri Jun  2 22:34:45 2023 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Fri Jun  2 22:34:45 2023 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.1
Fri Jun  2 22:34:45 2023 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Fri Jun  2 22:34:45 2023 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.8.0.1
Fri Jun  2 22:34:45 2023 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Fri Jun  2 22:34:45 2023 Initialization Sequence Completed
Fri Jun  2 22:34:45 2023 MANAGEMENT: >STATE:1685720085,CONNECTED,SUCCESS,10.8.0.2,10.132.56.42,1194
testik777
() автор топика
Ответ на: комментарий от targitaj

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

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

Из сообщения выше

tcpdump -i tun0 -n -nn -ttt 'ip p...

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

#client-config-dir /etc/openvpn/ccd

Это всё ещё так на сервере? Надо раскомментировать чтобы ccd файлики применились и перезапустить vpn сервер соотв.

Flotsky ★★
()

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

route 10.0.3.0 255.255.255.0

push «route 10.0.2.0 255.255.255.0»

в ccd клиента на сервера (прочти в man openvpn!)

iroute 10.03.0 255.255.255.0

В нормальной ситуации у сервера и клиента под два IP - локальный и внешний (по которым коннектятся OpenVPN сервер с клиентом). Поскольку они у тебя совпадают, то надо еще добавить отдельные маршруты на IP клиента на шлюз сервера, типа такого:

На сервере: route add host 10.0.3.3 gw 10.0.2.1

на клиенте: route add host 10.0.2.2. gw 10.0.3.1

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

Если так и скопипастит то так ему и надо. С другой стороны тогда клиент не будет подключаться - сервер будет его валить из-за кривого значения параметра и писать в лог это, так что разберется

С кривыми опциями бороться намного проще, чем с кривыми маршрутами, к счастью

no-dashi-v2 ★★★
()
Ответ на: комментарий от no-dashi-v2

По-моему как какое-то масло масленное. в конфиг строку route 10.0.3.0 255.255.255.0 в ccd iroute 10.0.3.0 255.255.255.0. Это же по факту одно и тоже действие. только в первом случае маршрут пропишется при запуске службы openvpn во втором при подключении client1.

Зачем push «route 10.0.2.0 255.255.255.0» если пинги от клиента до локального интерфейса сервера отлично ходят? Но для теста добавил. Не помогло.

route add host 10.0.3.3 gw 10.0.2.1 -это что за строка? у меня клиент на IP 10.0.3.4 сидит наверное все таки route add host 10.0.3.4 gw 10.0.2.1. но я не понимаю зачем мне пакеты на 10.0.3.4 направлять на внешний IP шлюз по умолчанию для сервера, который о туннеле ничего не знает о подсети 10.0.3.0/24 route add host 10.0.2.2. gw 10.0.3.1 Аналогично предыдущему маршруту?

А совпадает что у клиента и сервера? внешний IP 10.132.56.42

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

когда эту строку раскоменнтировал, перестал клиент подключаться. почему

лог клиента

Sun Jun  4 11:22:32 2023 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun  4 11:22:32 2023 TLS Error: TLS handshake failed
Sun Jun  4 11:22:32 2023 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun  4 11:22:32 2023 MANAGEMENT: >STATE:1685852552,RECONNECTING,tls-error,,,,,
Sun Jun  4 11:22:32 2023 Restart pause, 5 second(s)
Sun Jun  4 11:22:37 2023 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sun Jun  4 11:22:37 2023 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun Jun  4 11:22:37 2023 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sun Jun  4 11:22:37 2023 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun Jun  4 11:22:37 2023 TCP/UDP: Preserving recently used remote address: [AF_INET]10.132.56.42:1194
Sun Jun  4 11:22:37 2023 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sun Jun  4 11:22:37 2023 UDP link local: (not bound)
Sun Jun  4 11:22:37 2023 UDP link remote: [AF_INET]10.132.56.42:1194
Sun Jun  4 11:22:37 2023 MANAGEMENT: >STATE:1685852557,WAIT,,,,,,

лог сервера

Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
SENT CONTROL [client1]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-opti>
event_wait : Interrupted system call (code=4)
SENT CONTROL [client1]: 'RESTART' (status=1)
net_route_v4_del: 10.0.3.0/24 via 10.8.0.2 dev [NULL] table 0 metric -1
sitnl_send: rtnl: generic error (-1): Operation not permitted
ERROR: Linux route delete command failed
Closing TUN/TAP interface
net_addr_v4_del: 10.8.0.1 dev tun0
sitnl_send: rtnl: generic error (-1): Operation not permitted
Linux can't del IP from iface tun0
SIGTERM[hard,] received, process exiting

я так понимаю проблема где-то здесь sitnl_send: rtnl: generic error (-1): Operation not permitted ERROR: Linux route delete command failed не совсем понятно какая операция не разрешена?

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

По-моему как какое-то масло масленное. в конфиг строку route 10.0.3.0 255.255.255.0 в ccd iroute 10.0.3.0 255.255.255.0.

Это же по факту одно и тоже действие

Нет. route пропишет маршрут на интерфейс ovpn и на этом всё, но кому из клиентов отправлять пакетики ovpn не знает. Для этого и нужен iroute.

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

Вообщем клиент перестал подключаться когда строку push «route 10.0.2.0 255.255.255.0» добавил с кривыми кавычками.странно что служба на сервере вообще поднялась, и в логе про это ничего нет. но на мысль вы меня натолкнули. Сейчас конфиг сервера выглядит так:

local 10.0.2.2
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
route 10.0.3.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "route 10.0.2.0 255.255.255.0"
ifconfig-pool-persist ipp.txt
client-config-dir /etc/openvpn/ccd
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 1.0.0.1"
push "block-outside-dns"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log

в ccd строка iroute 10.0.3.0 255.255.255.0 раскомментирована. Сейчас подключение происходит и Пинги от сервера до локального интерфейса клиента идут.

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

tcpdump сервера

tcpdump -i tun0 -n -nn -ttt 'ip proto \icmp' -vv
tcpdump: listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
 00:00:00.000000 IP (tos 0x0, ttl 64, id 15908, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.2.2 > 10.0.3.1: ICMP echo request, id 4, seq 17, length 64
 00:00:01.023854 IP (tos 0x0, ttl 64, id 16162, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.2.2 > 10.0.3.1: ICMP echo request, id 4, seq 18, length 64
 00:00:01.024181 IP (tos 0x0, ttl 64, id 16168, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.2.2 > 10.0.3.1: ICMP echo request, id 4, seq 19, length 64
 00:00:01.023904 IP (tos 0x0, ttl 64, id 16383, offset 0, flags [DF], proto ICMP (1), length 84)
testik777
() автор топика
Ответ на: комментарий от anc

понял. странно лет 6 назад настраивал openvpn этой фукнции ccd не было, но все как-то работало. В любом случае спасибо.

Эти сроки я пока на сервере не применял. Пока так и не понял зачем они.

route add host 10.0.3.3 gw 10.0.2.1
route add host 10.0.2.2. gw 10.0.3.1
testik777
() автор топика
Ответ на: комментарий от anc

ну не знаю. я вот по этой инструкции на страивал (https://www.anfes.ru/e107_plugins/content/content.php?content.6), специально ее сохранил как рабочую, потому что только по ней получилось настроить. Там ничего про ccd не было.

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

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

Пробую нат настроить на клиенте с помощью данных команд:

netsh routing ip nat show global (если в ответ видим “NAT должен быть установлен первым” – ребутимся, если нет – идём дальше.)
netsh routing ip nat add interface “Internet connection” full (где “Internet connection” — vpn интерфейс с IP 10.8.0.2
netsh routing ip nat add interface “Local Area Connection” private (Local Area Connection - интерфейс в локалку который смотрит, 10.0.3.4)

Все равно пинги от сервера до 10.0.3.1 не идут.

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

tcpdump на клиенте 10.0.3.4 показывает что пакет от сервера доходит до клиента, Но ответа нет.

1. 031250 IP 10.0.2.2 > 10.0.3.1: ICMP echo request, id 26, seq 1644, length 64
1. 015625 IP 10.0.2.2 > 10.0.3.1: ICMP echo request, id 26, seq 1645, length 64
1. 031250 IP 10.0.2.2 > 10.0.3.1: ICMP echo request, id 26, seq 1646, length 64
1. 015625 IP 10.0.2.2 > 10.0.3.1: ICMP echo request, id 26, seq 1647, length 64
1. 031250 IP 10.0.2.2 > 10.0.3.1: ICMP echo request, id 26, seq 1648, length 64
1. 015625 IP 10.0.2.2 > 10.0.3.1: ICMP echo request, id 26, seq 1649, length 64
1. 031250 IP 10.0.2.2 > 10.0.3.1: ICMP echo request, id 26, seq 1650, length 64
testik777
() автор топика
Ответ на: комментарий от testik777

Всё правильно. Клиент 10.0.3.1 отвечает, но не в тоннель, а согласно своей таблице маршрутизации куда-то в «мир».

Только недавно была помню похожая тема, где всё разжевали, но найти не смог.

Надо или обратный маршрут на всех ПК за vpn клиентом прописать соответствующий, или nat у клиента включить, или поднимать vpn клиента силами маршрутизатора. Выбирайте исходя из возможностей/потребностей

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

ну нат я пытаюсь поднять. в винде не понятно как посмотреть толи он заработал, толи нет. я подключил к сети клиента еще один вирт комп. настроил на нем сеть 10.0.3.6/24 шлюз 10.0.3.1. И в какой-то момент у меня заработало. все пинги стали ходить. Но после того как я переподключил впн, опять все пропало. я пробовал строку в конфиг сервера добавить

push "route 10.0.3.0 255.255.255.0"

Пробовал на третьем компе выставить шлюз по умолчанию 10.0.3.4. и в какой момент все заработало я пока не понял.

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

Че-то у меня уже руки опускаются это понять. Сейчас снова перестал пинговаться локальный интерфейс клиента. Хотя я вроде все настройки откатил. Неужели каждый админ так возится с впном, чтобы простейшую сеть настроить. Совсем не дружественное к пользователю ПО, как будто разрабы для себя его писали.

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

не могу понять какого обратного маршрута не хватает компу в сети клиента? если я шлюз по умолчанию на нем прописываю 10.0.3.4 то он начинает пинговать и впн сервер и локальный интерфейс сервера и сеть за сервером. а вот с сервера я до него достучаться не могу.

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

удалось снова добиться пинга до локального интерфейка клиента.

сейчас видно что не ходят пинги: 1 - с компа из клиентской подсети до компьютера в сети сервера и 2 - с сервера до компьютера из подсети клиента.

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

В таком случае берут блокнотик/paint и рисуют все узлы сетей, подписывая относящиеся к узлам сети, ip и важные маршруты на узлах.

По полученной схеме становится понятно кто-как может общаться и обычно видно куда что добавить.

Я уже запутался где там у тебя что.

Можно попробовать посмотреть https://www.youtube.com/watch?v=-xxO5jdLvcE&list=PLHN9m7XN8U8HQ4KdjaLlWtSHQ3PYgQzmV&index=5, вдруг всё станет понятнее

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

Смог я победить данную задачу. Пинги на локальный интерфейс перестали ходить. Из-за того, что какой-то момент эксперементирования с натом на винде пропала галка ключ “IPEnableRouter” из ветки HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\Tcpip\Parameters

Короче когда поднял нат на винде:

netsh routing ip nat install

Проверяем:

netsh routing ip nat show global (если в ответ видим “NAT должен быть установлен первым” – ребутимся, если нет – идём дальше.)

Возможно необязательно:

netsh routing ip nat add interface “Internet connection” full (где “Internet connection” — tun-интерфейс.)
netsh routing ip nat add interface “Local Area Connection” private (где “Local Area Connection” – интерфейс локальной сети клиента.)

Перезагрузить ОС.

Заработал пинг с сервера до компа в сети клиента. Но не работал пинг с компа клиента до сети сервера.

Добавляем правило для ната в VPN сервер убунту:

iptables -t nat -A POSTROUTING -o enp0s3 -j SNAT --to-source 10.0.2.2

Установить прогу для сохранения правил iptables

apt-get install iptables-persistent

Далее команда на сохранение правила

netfilter-persistent save

После этого вроде во все стороны пинги забегали. Дрочево конечно знатное получилось.

Единственно меня правило ната в убунте смущает, наверняка не такое широкое можно сделать. Может подскажите как более узко сделать? в винде уже ничего не сделать, там нат ущербный.

testik777
() автор топика
← Postgresql не удаляет таблицу
Admin
Не работает dns в netns →