Se você está fazendo uma ponte, provavelmente não deveria estar empurrando nenhuma rota.
Eu configurei um servidor OpenVPN em uma máquina com um endereço IP privado de 10.0.0.13. O gateway está em 10.0.0.2 e distribui endereços 10.0.0. * Para outras máquinas na rede. A VPN está configurada com bridging. Meu arquivo / etc / network / interfaces é assim:
# Bring these interfaces up automatically
auto lo br0
# The loopback network interface
iface lo inet loopback
# The bridge connection
iface br0 inet static
address 10.0.0.13
bridge_ports eth0
bridge_stp on
broadcast 10.0.0.255
gateway 10.0.0.2
netmask 255.255.255.0
network 10.0.0.0
# The primary network interface
iface eth0 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ifconfig $IFACE down
O arquivo de configuração do servidor (/etc/openvpn/server.conf) se parece com isto:
port 1194
proto udp
dev tap0
up "/etc/openvpn/up.sh br0"
down "/etc/openvpn/down.sh br0"
ca ca.crt
cert VPNserver.crt
key VPNserver.key
dh dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 10.0.0.13 255.255.255.0 10.0.0.200 10.0.0.219
push "route 10.0.0.2 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
client-to-client
keepalive 10 120
tls-auth ta.key 0
comp-lzo
max-clients 20
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log-append /var/log/openvpn.log
verb 3
crl-verify crl.pem
Acho que a ponte do servidor e a linha abaixo dela podem precisar de ajustes. O OpenVPN deveria estar criando uma sub-rede para si mesmo e para conectar clientes? No começo eu estava com a impressão de que eu poderia simplesmente ter o OpenVPN para atribuir endereços IP na mesma sub-rede, desde que eles estivessem fora do alcance DHCP do roteador; agora eu não tenho tanta certeza.
De qualquer forma, aqui estão os sintomas da configuração atual. A máquina cliente (que mora em uma rede 10.6.0.0 - você verá isso na saída a seguir) é capaz de se conectar, mas somente o IP do servidor OpenVPN é pingável e não consigo navegar na web. Estou me conectando de uma CLI do Linux; Eis algumas das saídas que recebo, o que me leva a acreditar que o roteamento é o problema. Eu corrijo a saída que parece relevante para mim.
Fri Jun 3 12:54:51 2011 [VPNserver] Peer Connection Initiated with [AF_INET]SERVER.PUBLIC.IP.ADDRESS:1194
Fri Jun 3 12:54:53 2011 SENT CONTROL [VPNserver]: 'PUSH_REQUEST' (status=1)
Fri Jun 3 12:54:53 2011 PUSH: Received control message: 'PUSH_REPLY,route 10.0.0.2 255.255.255.0,redirect-gateway def1 bypass-dhcp,route-gateway 10.0.0.13,ping 10,ping-restart 120,ifconfig 10.0.0.201 255.255.255.0'
Fri Jun 3 12:54:53 2011 OPTIONS IMPORT: timers and/or timeouts modified
Fri Jun 3 12:54:53 2011 OPTIONS IMPORT: --ifconfig/up options modified
Fri Jun 3 12:54:53 2011 OPTIONS IMPORT: route options modified
Fri Jun 3 12:54:53 2011 OPTIONS IMPORT: route-related options modified
Fri Jun 3 12:54:53 2011 ROUTE default_gateway=10.6.0.1
Fri Jun 3 12:54:53 2011 TUN/TAP device tap0 opened
Fri Jun 3 12:54:53 2011 TUN/TAP TX queue length set to 100
Fri Jun 3 12:54:53 2011 /sbin/ifconfig tap0 10.0.0.201 netmask 255.255.255.0 mtu 1500 broadcast 10.0.0.255
Fri Jun 3 12:54:53 2011 /sbin/route add -net SERVER.PUBLIC.IP.ADDRESS netmask 255.255.255.255 gw 10.6.0.1
**SIOCADDRT: File exists
Fri Jun 3 12:54:53 2011 ERROR: Linux route add command failed: external program exited with error status: 7**
Fri Jun 3 12:54:53 2011 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.0.0.13
Fri Jun 3 12:54:53 2011 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.0.0.13
**Fri Jun 3 12:54:53 2011 /sbin/route add -net 10.0.0.2 netmask 255.255.255.0 gw 10.0.0.13
route: netmask doesn't match route address**
Usage: route [-nNvee] [-FC] [<AF>] List kernel routing tables
route [-v] [-FC] {add|del|flush} ... Modify routing table for AF.
route {-h|--help} [<AF>] Detailed usage syntax for specified AF.
route {-V|--version} Display version/author and exit.
-v, --verbose be verbose
-n, --numeric don't resolve names
-e, --extend display other/more information
-F, --fib display Forwarding Information Base (default)
-C, --cache display routing cache instead of FIB
<AF>=Use '-A <af>' or '--<af>'; default: inet
List of possible address families (which support routing):
inet (DARPA Internet) inet6 (IPv6) ax25 (AMPR AX.25)
netrom (AMPR NET/ROM) ipx (Novell IPX) ddp (Appletalk DDP)
x25 (CCITT X.25)
**Fri Jun 3 12:54:53 2011 ERROR: Linux route add command failed: external program exited with error status: 4**
Fri Jun 3 12:54:53 2011 GID set to nogroup
Fri Jun 3 12:54:53 2011 UID set to nobody
Fri Jun 3 12:54:53 2011 Initialization Sequence Completed
Então, eu acho que estou procurando:
Se você está fazendo uma ponte, provavelmente não deveria estar empurrando nenhuma rota.
OK, então tecnicamente @Zoredache está correto. Minha pergunta foi: "Quais são as rotas adequadas para empurrar para um servidor OpenVPN em ponte?" e eu não deveria estar empurrando route 10.0.0.2 255.255.255.0
(que provavelmente deveria ser route 10.0.0.0 255.255.255.0
de qualquer maneira). Remover essa linha resolveu a primeira parte do meu problema.
A segunda parte do meu problema (não ser capaz de fazer ping em outras máquinas na rede 10.0.0.0) estava relacionada a um detalhe que não mencionei, que é que esse servidor reside em uma máquina virtual VMWare. Graças a esta postagem do blog , descobri que "o O switch virtual ESXi, por padrão, descarta pacotes promíscuos ", e eu aprendi a configurar a VM para não fazer isso.
Não consegui alcançar o terceiro objetivo de rotear todo o tráfego pela VPN, mas decidi que não era crucial para essa implantação específica. Os comentários na configuração padrão sugerem que, descomentando push "redirect-gateway def1 bypass-dhcp"
, eu "configuraria todos os clientes para redirecionar seu gateway de rede padrão através da VPN, fazendo com que todo o tráfego IP, como navegação na Web e DNS, passasse pela VPN", mas Eu não me lembrava que não conseguiria sair da rede.
Tags networking openvpn