Rede OpenVPN Inacessível

1

Estou trabalhando para configurar um acesso VPN para um grupo de máquinas virtuais no Linode., a topologia é algo como isto: %código% E mais servidores na LAN com endereços no mesmo intervalo. O servidor utility está hospedando o OpenVPN

Aqui está a configuração do OpenVPN do meu servidor, a configuração do cliente não está disponível porque estou usando o Shimo para o OSX: %pr_e%

Quando conectado à VPN, posso executar o ping no gateway da VPN e efetuar o logon no SSH e em todas as operações normais sem problemas, %pr_e% confirma que esses pacotes estão ultrapassando o dispositivo tcpdump no meu Mac. / p>

A tentativa de pingar tun0 pela VPN não funciona, 192.168.154.127 confirma que não há atividade no dispositivo tcpdump .

Eu compreendo ao ler este que preciso adicionar uma configuração tun0 ao meu route , ao adicionar a linha:

db.example.com       LAN: (eth0:0) 192.168.154.127/255.255.128.0
utility.example.com  LAN: (eth0:0) 192.168.164.229/255.255.128.0

o servidor lança um erro ao inicializar, inline aqui: server.conf

dev tun
mode server
tls-server
proto udp
port 1194
server 10.77.22.0 255.255.255.0
push "route 10.77.22.0 255.255.255.0"
push "route 192.168.154.0 255.255.128.0"
ifconfig-pool-persist ipp.txt
persist-key
persist-tun
client-to-client
ca ca.crt
dh dh1024.pem
cert server.crt
key server.key
tls-auth ta.key 0
cipher BF-CBC
comp-lzo
user nobody
group nogroup
keepalive 10 120
status openvpn-status.log
verb 3 

= Use '-A' ou '-'; padrão: inet   Lista de possíveis famílias de endereços (que suportam o roteamento):     inet (Internet DARPA) inet6 (IPv6) ax25 (AMPR AX.25)     netrom (AMPR NET / ROM) ipx (Novell IPX) ddp (Appletalk DDP)     x25 (CCITT X.25)

Suspeito que, se eu resolvesse esse problema %pr_e% , a situação funcionaria como esperado, mas não entendo por que isso está falhando.

O cliente geralmente recebe um endereço como este:

route 192.168.154.0 255.255.128.0
    
por Lee Hambley 16.05.2011 / 19:06

2 respostas

2

Sua declaração route no arquivo de configuração precisa fazer referência ao ID da rede 192.168.128.0 , não 192.168.154.0 . route é vomitar porque você está dando-lhe uma máscara ID de rede e sub-rede que, quando tomados em conjunto, tem 1 de na parte ID de host.

192.168.154.0 em binário é:

11000000.10101000.10011010.00000000

A máscara de sub-rede 255.255.128.0 se parece com:

11111111.11111111.10000000.00000000

A máscara de sub-rede aplicada ao "ID de rede" 192.168.154.0 se parece com:

    11000000.10101000.10011010.00000000
AND 11111111.11111111.10000000.00000000
---------------------------------------
    11000000.10101000.10000000.00000000 = 192.168.128.0

Você pode ver que 192.168.154.0 mascarada por A / 17 resultados máscara de sub-rede em 1 de após o fim da máscara de sub-rede. O id da rede 192.168.154.0/17 "é realmente 192.168.128.0/17. Altere sua instrução route no arquivo de configuração e o comando route parará o barfing.

    
por 17.05.2011 / 05:32
1

A ativação de ip_forward é obrigatória. Uma caixa linux não será roteada, a menos que seja. No Ubuntu, a maneira mais fácil de corrigir isso é ajustar o /etc/sysctl.conf, apenas descomente a linha ip_forward. Em seguida, reinicie o sistema ou execute sysctl -p .

    
por 16.05.2011 / 21:05