Aqui está o meu problema:
Estou tentando configurar o OpenVPN em minha rede doméstica, para usá-lo como um túnel seguro para tráfego de redes inseguras quando estiver longe de casa e também para acessar máquinas na minha LAN doméstica. O servidor OpenVPN na minha LAN é uma máquina que executa o Arch Linux e é separado do meu firewall, que atualmente está executando o M0n0wall. O cliente que eu gostaria de usar é um laptop, também rodando o Arch Linux.
Estou tentando usar o modo de ponte, que daria ao meu laptop um endereço em minha LAN doméstica, permitindo que ele funcionasse exatamente como se estivesse realmente conectado à minha LAN.
Atualmente, estou tentando testar a configuração colocando meu laptop atrás de um gateway, por isso, ele está em uma sub-rede separada da minha sub-rede LAN principal (estou fazendo isso porque não tenho acesso fácil a uma rede externa, e eu prefiro depurar problemas aqui do que esperar até que eu esteja em um hotel a milhas de distância).
Parâmetros relevantes:
Main LAN subnet: 192.168.77.0/24
VPN server IP: 192.168.77.203
Gateway: 192.168.77.2
Testing subnet: 192.168.0.0/24
Laptop (client) IP: 192.168.0.100
Testing gateway (to main LAN): 192.168.0.1
Aqui está o arquivo de configuração do meu servidor:
port 1194
proto udp
dev tap0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/caliborn.crt
key /etc/openvpn/caliborn.key # This file should be kept secret
dh /etc/openvpn/dh2048.pem
server-bridge 192.168.77.203 255.255.255.0 192.168.77.9 192.168.77.19
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0 # This file is secret
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
log /etc/openvpn/openvpn.log
verb 4
E aqui está a configuração do cliente:
client
dev tap0
proto udp
remote 192.168.77.203 1194
resolv-retry infinite
nobind
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
log /etc/openvpn/openvpn.log
ca /etc/openvpn/ca.crt
cert /etc/openvpn/rama.crt
key /etc/openvpn/rama.key
ns-cert-type server
tls-auth ta.key 1
comp-lzo
verb 4
Eu uso o script bridge-start do link para configurar uma ponte no servidor antes de iniciar a VPN.
Quando a VPN não está conectada, posso fazer o ping do servidor (192.168.77.203) do cliente (192.168.0.100) muito bem, mas assim que eu conecto a VPN, perco toda a conectividade do cliente. A VPN parece estar conectada ao servidor, mas não consigo nem fazer ping no servidor!
Aqui está a saída da rota no cliente enquanto a VPN está conectada:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 202 0 0 enp0s25
192.168.0.0 * 255.255.255.0 U 202 0 0 enp0s25
192.168.77.0 * 255.255.255.0 U 0 0 0 tap0
E os resultados da rota ip no cliente:
default via 192.168.0.1 dev enp0s25 metric 202
192.168.0.0/24 dev enp0s25 proto kernel scope link src 192.168.0.100 metric 202
192.168.77.0/24 dev tap0 proto kernel scope link src 192.168.77.9
Saída do ip addr no cliente, enquanto conectado:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
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: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:1c:25:93:93:50 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.100/24 brd 192.168.0.255 scope global enp0s25
valid_lft forever preferred_lft forever
inet6 fe80::21c:25ff:fe93:9350/64 scope link
valid_lft forever preferred_lft forever
3: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether 00:21:5c:08:7d:37 brd ff:ff:ff:ff:ff:ff
17: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
link/ether 8a:f4:df:21:a6:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.77.9/24 brd 192.168.77.255 scope global tap0
valid_lft forever preferred_lft forever
inet6 fe80::88f4:dfff:fe21:a62d/64 scope link
valid_lft forever preferred_lft forever
E aqui está a saída do ip addr no servidor, enquanto a VPN está ativa:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
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: enp3s0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000
link/ether 00:1c:c0:b5:de:b0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21c:c0ff:feb5:deb0/64 scope link
valid_lft forever preferred_lft forever
3: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 100
link/ether 86:50:bb:c1:46:91 brd ff:ff:ff:ff:ff:ff
inet6 fe80::8450:bbff:fec1:4691/64 scope link
valid_lft forever preferred_lft forever
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:1c:c0:b5:de:b0 brd ff:ff:ff:ff:ff:ff
inet 192.168.77.203/24 brd 192.168.77.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::21c:c0ff:feb5:deb0/64 scope link
valid_lft forever preferred_lft forever
Portanto, parece que os pacotes endereçados à sub-rede LAN principal devem passar pelo túnel, mas quando eu executo o tcpdump -i tap0 no cliente enquanto tento fazer ping no servidor, tudo que vejo são solicitações ARP, sem respostas. Eu acho que pelo menos conseguiria fazer o ping no servidor, ao qual estou conectado.
Mais uma coisa que pode ser relevante: no log do cliente, vejo o seguinte:
Thu Jul 11 20:54:18 2013 us=872367 OPTIONS IMPORT: --ifconfig/up options modified
Thu Jul 11 20:54:18 2013 us=872423 OPTIONS IMPORT: route-related options modified
Thu Jul 11 20:54:18 2013 us=872480 WARNING: --remote address [192.168.77.203] conflicts with --ifconfig subnet [192.168.77.9, 255.255.255.0] -- local and remote addresses cannot be inside of the --ifconfig subnet. (silence this warning with --ifconfig-nowarn)
Thu Jul 11 20:54:18 2013 us=877646 TUN/TAP device tap0 opened
Thu Jul 11 20:54:18 2013 us=877701 TUN/TAP TX queue length set to 100
Thu Jul 11 20:54:18 2013 us=877726 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Jul 11 20:54:18 2013 us=877768 /usr/bin/ip link set dev tap0 up mtu 1500
Thu Jul 11 20:54:18 2013 us=878607 /usr/bin/ip addr add dev tap0 192.168.77.9/24 broadcast 192.168.77.255
Thu Jul 11 20:54:18 2013 us=880894 Initialization Sequence Completed
Thu Jul 11 20:56:18 2013 us=649132 [caliborn] Inactivity timeout (--ping-restart), restarting
Thu Jul 11 20:56:18 2013 us=649823 TCP/UDP: Closing socket
Thu Jul 11 20:56:18 2013 us=649917 SIGUSR1[soft,ping-restart] received, process restarting
Thu Jul 11 20:56:18 2013 us=649966 Restart pause, 2 second(s)
Thu Jul 11 20:56:20 2013 us=650168 Re-using SSL/TLS context
Thu Jul 11 20:56:20 2013 us=650308 LZO compression initialized
Thu Jul 11 20:56:20 2013 us=651988 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ]
Thu Jul 11 20:56:20 2013 us=652071 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Jul 11 20:56:20 2013 us=652124 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Thu Jul 11 20:56:20 2013 us=652192 Local Options String: 'V4,dev-type tap,link-mtu 1574,tun-mtu 1532,proto UDPv4, comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
Thu Jul 11 20:56:20 2013 us=652228 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1574,tun-mtu 1532, proto UDPv4,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
Thu Jul 11 20:56:20 2013 us=652285 Local Options hash (VER=V4): '13a273ba'
Thu Jul 11 20:56:20 2013 us=652335 Expected Remote Options hash (VER=V4): '360696c5'
Thu Jul 11 20:56:20 2013 us=652377 UDPv4 link local: [undef]
Thu Jul 11 20:56:20 2013 us=652420 UDPv4 link remote: [AF_INET]192.168.77.203:1194
Thu Jul 11 20:57:20 2013 us=211669 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Jul 11 20:57:20 2013 us=211761 TLS Error: TLS handshake failed
Thu Jul 11 20:57:20 2013 us=211938 TCP/UDP: Closing socket
Thu Jul 11 20:57:20 2013 us=212012 SIGUSR1[soft,tls-error] received, process restarting
Portanto, parece que, além do erro sobre o conflito de sub-rede, o cliente está expirando e se reconectando uma vez por minuto. Parece que estar conectado à VPN para qualquer fluxo de tráfego entre o cliente e qualquer outro host na rede, e que após o tempo limite da VPN ter sido interrompido por causa disso, ele pode se reconectar e iniciar todo o processo.
Terei todo o prazer em fornecer informações adicionais a qualquer pessoa que pense que possa saber qual é o problema.