Cliente VPN incapaz de acessar a LAN

Question

Eu tenho um servidor na lan do escritório com um ip público rodando open vpn. Clientes vpn externos podem se conectar à vpn via ip público.

Mas, uma vez conectados, eles não conseguem se conectar a outros servidores na lan do escritório, mas podem acessar qualquer site por cima.

Meu openvpn.conf é como

local xx.xx.xx.xx
port 8443
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
;ifconfig-pool-persist ipp.txt
push "route 10.84.172.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.84.172.117"
push "dhcp-option DNS 9.9.9.9"
duplicate-cn
keepalive 10 120
tls-auth ta.key 0
key-direction 0
cipher AES-128-CBC
auth SHA256
comp-lzo
max-clients 10
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log         openvpn.log
log-append  openvpn.log
verb 9

o cliente conf é tão

client
dev tun
proto tcp
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-128-CBC
auth SHA256
key-direction 1
comp-lzo
verb 3
mute 20

saída de exibição de rota ip é

default via xx.xx.xx.xx dev ens19 onlink 
10.8.0.0/24 via 10.8.0.2 dev tun0 
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1 
10.84.172.0/24 dev ens18  proto kernel  scope link  src 10.84.172.76 
xx.xx.xx.xx/27 dev ens19  proto kernel  scope link  src  xx.xx.xx.xx

saída ifconfig

ens18     Link encap:Ethernet  HWaddr e2:d0:37:41:fe:62  
          inet addr:10.84.172.76  Bcast:10.84.172.255  Mask:255.255.255.0
          inet6 addr: fe80::e0d0:37ff:fe41:fe62/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:300099 errors:0 dropped:7 overruns:0 frame:0
          TX packets:813 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:45852701 (45.8 MB)  TX bytes:108772 (108.7 KB)

ens19     Link encap:Ethernet  HWaddr a2:c9:4f:0f:b3:a8  
          inet addr:xx.xx.xx.xx  Bcast:xx.xx.xx.xx  Mask:255.255.255.224
          inet6 addr: fe80::a0c9:4fff:fe0f:b3a8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:121480 errors:0 dropped:31009 overruns:0 frame:0
          TX packets:37745 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:14195083 (14.1 MB)  TX bytes:6904167 (6.9 MB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:176 errors:0 dropped:0 overruns:0 frame:0
          TX packets:176 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:13296 (13.2 KB)  TX bytes:13296 (13.2 KB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

netsat -r output link

O encaminhamento de ipv4 foi ativado

Acredito que esteja faltando algumas rotas estáticas entre a sub-rede openvpn tun e minha sub-rede local real, mas nada que eu esteja tentando rotear entre elas está funcionando.

    

Answer 1

Eu acho que você deveria descomentar a linha push route no arquivo openvpn.conf e ver se funciona.

    

Answer 2

Supondo que isso é o que você deseja:

[OVPN Clients(10.8.0.0/24)]<-tunnel->[OVPN Svr(10.84.172.76)]<-LAN->[GW(10.84.172.1)]<-LAN->[SUBNET (10.84.172.0/24)]

e você não pode simplesmente adicionar 10.8.0.0/24 - > 10.84.172.76 para a tabela de rotas do GW, você terá que adicionar manualmente uma rota persistente para cada um dos seus sistemas de LAN.

Baseado no Debian: edite /etc/network/interfaces e adicione

up route add -net 10.8.0.0/24 gw 10.84.172.76 dev [your_lan_nic (not tun!)]

Com base no RHEL: edite /etc/sysconfig/network-scripts/route-eth[your lan nic #]

10.8.0.0/24 via 10.84.172.76

Recomendamos enfaticamente que você fale com o administrador do gateway para adicionar sua rota a ele em vez de ter que se limitar a cada caixa individualmente.

Também sugiro algumas alterações nas suas configurações do OpenVPN.

server conf (com justificativa para as mudanças):

local xx.xx.xx.xx
#port 8443 isn't officially registered with iana, but it is a default for apache tomcat ssl.
#you may be better served by using a less commonly-used port.
port 8443
#proto udp generally has significantly better performance than tcp.
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
#topology subnet is recommended over the default net30.
#you should only have to use net30 if an old Windows ovpn client needs to connect.
topology subnet
server 10.8.0.0 255.255.255.0
push "route 10.84.172.0 255.255.255.0"
;push "redirect-gateway def1 bypass-dhcp"   #leave this out for now to help diagnose routing issues.
push "dhcp-option DNS 10.84.172.117"
push "dhcp-option DNS 9.9.9.9"
duplicate-cn
keepalive 10 120
tls-auth ta.key 0
#key-direction is unneccessary.
#the tls-auth setting already includes the direction (0)
;key-direction 0
cipher AES-128-CBC
auth SHA256
comp-lzo
max-clients 10
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
#Use either log or log-append, not both.
#log overwrites the log every time the service starts.
#log-append continues to write to the file when the service starts.
log openvpn.log
;log-append openvpn.log
#you'll probably want to lower the verbosity so your logs are readable.
#verb 3 is usually plenty of information.
verb 9
#mute helps keep your logs readable by suppressing floods of the same error.
mute 20
#explicit-exit-notify helps clients reconnect should the server need to restart.
explicit-exit-notify 1

configuração do cliente:

client
dev tun
#as above, proto udp has much better performance than tcp
proto udp
#remote host [port] [proto] it's useful to identify the remote server.
#host can be either the IP or FQDN if you have a DNS record.
#I continue to recommend a different port.
remote xx.xx.xx.xx 8443 udp
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-128-CBC
auth SHA256
key-direction 1
comp-lzo
verb 3
mute 20