OpenVPN lans roteadas

Question

Descrição da configuração:

• Um servidor VPN chamado vpn1
• Um cliente VPN chamado vpn2
• Uma rede atrás da vpn1 com endereços IP 10.0.0.0/24
• Uma rede atrás da vpn2 com endereços IP 10.0.2.0/24
• Por simplicidade agora, as caixas VPN são o gateway padrão para máquinas em suas LANs

Configuração do servidor: vpn1

mode server
tls-server
dev tun

local PUBLIC-IP-HERE
port 1194
proto udp

persist-key
persist-tun

# Certificates and encryption
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0

cipher BF-CBC        
comp-lzo            

push "route 10.0.0.0 255.255.255.0"
push "route 10.0.2.0 255.255.255.0"
push "route 10.255.254.0 255.255.255.0"
route 10.0.2.0 255.255.255.0
client-to-client
max-clients 30

user nobody
group nogroup
keepalive 10 120
status /var/log/openvpn-status.log
verb 3

ifconfig-pool-persist ipp.txt
client-config-dir ccd
server 10.255.254.0 255.255.255.0

push "explicit-exit-notify 3"

No ccd / client eu tenho:

iroute 10.0.2.0 255.255.255.0
ifconfig-push 10.255.254.9 10.255.254.10

Como "ip a" se parece:

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 10.0.0.1/24 brd 10.0.0.255 scope global eth1

172: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.255.254.1 peer 10.255.254.2/32 scope global tun0

Como se parece "ip r" (removi a rota padrão, pois não deveria ser importante):

10.0.0.0/24 dev eth1  proto kernel  scope link  src 10.0.0.1
10.0.2.0/24 via 10.255.254.2 dev tun0 
10.255.254.0/24 via 10.255.254.2 dev tun0 
10.255.254.2 dev tun0  proto kernel  scope link  src 10.255.254.1 

Configuração do cliente: vpn2

client
dev tun
remote PUBLIC-IP-HERE 1194
nobind
persist-key
persist-tun
proto udp

ca /etc/openvpn/easy-rsa/keys/client/ca.crt
cert /etc/openvpn/easy-rsa/keys/client/client.crt
key /etc/openvpn/easy-rsa/keys/client/client.key

tls-auth /etc/openvpn/easy-rsa/keys/client/ta.key 1
cipher BF-CBC
comp-lzo
ns-cert-type server
verb 3

Como "ip a" se parece:

7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    inet 10.0.2.1/24 brd 10.0.2.255 scope global br0

8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.255.254.9 peer 10.255.254.10/32 scope global tun0

Como se parece "ip r" (novamente removi o gateway padrão e os relacionados):

10.0.0.0/24 via 10.255.254.10 dev tun0 
10.0.2.0/24 dev br0  proto kernel  scope link  src 10.0.2.1 
10.255.254.0/24 via 10.255.254.10 dev tun0 
10.255.254.10 dev tun0  proto kernel  scope link  src 10.255.254.9 

Configurações gerais:

• Política Iptables é permitir tudo
O
• encaminhamento de IP está ativado
• O filtro RP está desativado

O que funciona:

• Ping de qualquer host na lan1 para a vpn2 (10.0.0.11 - > 10.255.254.9)
• Ping de qualquer host na lan2 para a vpn1 (10.0.2.11 - > 10.255.254.1)
• Ping da vpn1 para a lan2 (10.255.254.1 - > qualquer host na lan2 10.0.2.0/24 )
• Ping da vpn2 para a lan1 (10.255.254.9 - > qualquer host na lan2 10.0.0.0/24 )

O que não funciona:

• Ping de qualquer host em lan1 para lan2
• Ping de qualquer host na lan2 para a lan1

Com o NAT, consegui:

• Ping de qualquer host em lan1 para lan2
• Mas não de qualquer host em lan2 para lan1, mas não de qualquer host em lan2 para lan1

Eu deveria ser capaz de pingar qualquer host na LAN2 da LAN1 sem NAT e vice-versa. O que está errado aqui? Algo está me escapando e não consigo descobrir o quê.

    

Answer 1

É um problema de roteamento.

Eu suspeito que sua diretiva iroute não está fazendo efeito. O arquivo que você nomeou "ccd / client" deve, na verdade, ter um nome de arquivo correspondente ao nome do assunto do certificado de cliente. Portanto, se o DN do certificado do cliente for C=CA,O=Foo Ltd,CN=Example , o arquivo deverá ser "ccd / Example".

Além disso, sua configuração parece correta.