OpenVPN: Can't route to private network once connected to VPN tunnel

I'm trying to setup an OpenVPN server to allow tunnelling to a private network (192.168.0.0/16) but when my VPN client is connected it cannot reach hosts on this network. No firewall is currently setup for the network/all ports are open. The server running OpenVPN is assigned the IP 192.168.0.2 on the private network

server.conf

local 1.2.3.4
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
server-ipv6 fddd:1194:1194:1194::/64
push "redirect-gateway def1 ipv6 bypass-dhcp"
push "route 192.168.0.0 255.255.0.0"
push "dhcp-option DNS 10.8.0.1"
ifconfig-pool-persist ipp.txt
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify

client.ovpn

client
dev tun
proto udp
remote 1.2.3.4 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
block-outside-dns
verb 3
<ca>
REDACTED
</ca>
<cert>
REDACTED
</cert>
<key>
REDACTED
</key>
<tls-crypt>
REDACTED
</tls-crypt>

Client connected to the OpenVPN server can ping the OpenVPN gateway as well as using its IP on the other subnet. However it can't ping a different host on the same network...

[26/10/21 19:58:32] user@client:~$ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=27.3 ms
^C
--- 10.8.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 27.276/27.276/27.276/0.000 ms
[26/10/21 19:58:49] user@client:~$ ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=27.3 ms
^C
--- 192.168.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 27.271/27.271/27.271/0.000 ms
[26/10/21 19:58:52] user@client:~$ ping 192.168.0.3
PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data.
^C
--- 192.168.0.3 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

OpenVPN server can ping a different host on the same network...

root@server:~# ping 192.168.0.3
PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data.
64 bytes from 192.168.0.3: icmp_seq=1 ttl=63 time=1.26 ms
^C
--- 192.168.0.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.262/1.262/1.262/0.000 ms

OpenVPN server route table...

root@server:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.31.1.1      0.0.0.0         UG    100    0        0 eth0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
172.31.1.1      0.0.0.0         255.255.255.255 UH    100    0        0 eth0
192.168.0.0     192.168.0.1     255.255.255.0   UG    0      0        0 ens10
192.168.0.1     0.0.0.0         255.255.255.255 UH    0      0        0 ens10

192.168.0.3 routing table...

root@server:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
_gateway        0.0.0.0         255.255.255.255 UH    100    0        0 eth0
192.168.0.0     192.168.0.1     255.255.0.0     UG    0      0        0 ens10
192.168.0.1     0.0.0.0         255.255.255.255 UH    0      0        0 ens10

Any help is appreciated.

Thanks.

Protocolul Internet se uită numai la adresa IP de destinație atunci când rutați pachetele. Nu le pasă de unde a venit un pachet. Nu le pasă că pachetul ar putea face parte dintr-o sesiune sau conexiune sau aplicație mai mare. Singurul lucru care contează este adresa IP de destinație. IP se uită apoi la tabelul de rutare pentru a determina ce să facă cu fiecare pachet, pe baza exclusivă a adresei de destinație. (Din punct de vedere tehnic, lucruri precum firewall-urile complete și rutarea de poliție pot face ca acest lucru să fie o minciună, dar va funcționa pentru scopurile actuale.)

După cum subliniază @Nikita, și rezultatul traseu (8) emisiuni, gazde ca 192.168.0.3 (și, probabil, alte gazde din rețeaua dvs.) știu doar să trimită pachete către router la 192.168.0.1. Nu au ce să le spună să trimită pachete către sistemul dumneavoastră OpenVPN la 192.168.0.2.. Asa de .3 iar prietenii își vor trimite tot traficul către routerul tău. Routerul tău nu știe despre VPN-ul tău. Routerul dvs. fie va arunca pachetele, fie le va trimite pe internetul public (unde probabil că următorul router hop le va arunca).

Sunt multiple soluții posibile.

Soluția #1 - Ușoară, dar ineficientă

Spune-i routerului tău asta 10.8.0.0/24 este accesibil prin poarta de acces la 192.168.0.2. Acest lucru va avea ca rezultat o rută în ac de păr -- pachetele vor merge de la gazde ca .3, la interfața LAN a routerului dvs. la .1, apoi retrageți aceeași interfață de router și la gateway-ul OpenVPN la .2. Acest lucru este ineficient, dar ar trebui să funcționeze.

Nu spui care este routerul tău, dar dacă ar fi Linux, comanda ar fi ceva de genul:

ruta ip adăugați 10.8.0.0/24 prin 192.168.0.2

Soluția #2 - Neintruzivă, dar plictisitoare

Puteți configura o rută statică pe fiecare gazdă LAN, spunându-le aceleași informații de rutare ca #1, dar peste tot. Aceasta ar fi o problemă minoră de configurat și întreținut, dar ar fi cea mai eficientă soluție care vă păstrează topologia rețelei existente. Aceeași comandă ca mai sus (pentru Linux), dar trebuie să o rulați pe fiecare gazdă LAN. De asemenea, trebuie să faceți acest lucru pe toate celelalte dispozitive care ar trebui să funcționeze prin VPN, inclusiv cutii Windows, imprimante, tablete, telefoane, becuri wifi etc. În cele din urmă, veți uita unul și vă veți întreba de ce nu funcționează, petreceți timp trăgând. îți ia părul și apoi simți-te ca un drog când îți amintești de ce.

Soluția #3 - sofisticată, dar perturbatoare

Puteți pune gateway-ul VPN pe calea de rutare către Internet. Există două subalternative aici.

Soluția #3A - VPN pe router

Chiar și routerele de consum pot rula uneori o implementare OpenVPN în zilele noastre, mai ales dacă utilizați firmware terță parte (OpenWRT, DD-WRT etc.). Cu toate acestea, adesea le lipsește puterea procesorului pentru o performanță adecvată. De asemenea, puteți înlocui consumatorul cu ceva mai bun -- un router comercial sau un alt Linux. S-ar putea chiar să puteți reînscrie gateway-ul VPN ca VPN+router+firewall.

În acest scenariu, VPN-ul și routerul sunt același lucru, așa că nu trebuie să vă faceți griji că routerul se înțelege cu gateway-ul VPN. Acesta este probabil cel mai eficient, în ceea ce privește proiectarea rețelei.

Soluția #3B - Stack Gateway și Router

Puteți pune gateway-ul VPN între router și restul rețelei LAN, cu subrețele IP diferite de fiecare parte a gateway-ului VPN. Toate celelalte gazde LAN trimit către gateway-ul VPN pentru a ajunge la Internet. Gateway-ul VPN trimite și redirecționează către router pentru a ajunge la Internet.

Acest lucru va necesita punerea a două interfețe de rețea în gateway-ul VPN -- una pentru LAN și una pentru transferul către rotuer. (Sau faceți o rută în ac de păr pe gateway-ul VPN, care este mai rău decât numărul 1 pentru că acum toate Traficul pe internet este acaparat).

Principalele avantaje ale acestei abordări sunt: ​​Îți poți păstra routerul existent (poate că ISP-ul tău te face să folosești echipamentul lor, poate că are o altă proprietate utilă pentru tine). Dacă cutia VPN se defectează, o puteți scoate din imagine și (poate) reconfigurați rapid routerul pentru a-i lua locul.