Quais são as rotas adequadas para enviar um servidor OpenVPN com ponte?

3

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:

  1. Faça com que esses erros desapareçam
  2. Poder acessar máquinas diferentes do servidor OpenVPN na rede 10.0.0.0
  3. Encaminhar todo o tráfego (navegação na web, etc.) por meio da VPN
por pittstains 03.06.2011 / 19:43

2 respostas

1

Se você está fazendo uma ponte, provavelmente não deveria estar empurrando nenhuma rota.

    
por 04.06.2011 / 01:05
1

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.

    
por 09.06.2011 / 13:23