Acesse uma sub-rede atrás de um servidor openvpn

3

Eu tenho um servidor Ubuntu OpenVPN configurado. Tudo funciona muito bem, os clientes VPN podem se conectar com sucesso ao servidor VPN. O desafio é que não consigo me conectar aos computadores por trás do servidor VPN

tcp dump no tun0 root @ gtway-sr-s: ~ # tcpdump -i tun0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
15:10:45.785732 IP 10.8.0.6 > 192.168.33.2: ICMP echo request, id 7, seq 48841, length 40
15:10:50.469529 IP 10.8.0.6 > 192.168.33.2: ICMP echo request, id 7, seq 48850, length 40

E isso é para em2 [192.168.33.2]

root@gtway-sr-s:~# tcpdump -i em2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em2, link-type EN10MB (Ethernet), capture size 65535 bytes
15:15:15.460870 ARP, Request who-has 192.168.33.2 tell 192.168.33.1, length 28
15:15:15.461025 ARP, Reply 192.168.33.2 is-at e4:1f:13:bb:0f:f2 (oui Unknown), length 46
15:15:15.464351 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49287, length 40
15:15:15.464544 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49287, length 40
15:15:16.187506 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:20.448006 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49296, length 40
15:15:20.448207 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49296, length 40
15:15:21.491924 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:25.450927 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49304, length 40
15:15:25.451132 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49304, length 40
15:15:26.823644 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:30.459822 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49315, length 40
15:15:30.460016 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49315, length 40
15:15:32.148672 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:35.143425 ARP, Request who-has 192.168.33.1 (b0:83:fe:e3:2e:1a (oui Unknown)) tell 192.168.33.2, length 46
15:15:35.143431 ARP, Reply 192.168.33.1 is-at b0:83:fe:e3:2e:1a (oui Unknown), length 28
15:15:35.453679 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49324, length 40
15:15:35.453861 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49324, length 40
15:15:37.485259 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:40.455035 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49333, length 40
15:15:40.455220 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49333, length 40
15:15:40.468865 ARP, Request who-has 192.168.33.2 tell 192.168.33.1, length 28
15:15:40.469000 ARP, Reply 192.168.33.2 is-at e4:1f:13:bb:0f:f2 (oui Unknown), length 46
15:15:42.827137 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:45.461731 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49343, length 40
15:15:45.461919 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49343, length 40
    
por chico ahmad 06.07.2015 / 12:39

1 resposta

3

Modifique o arquivo de configuração do servidor para incluir uma linha como a seguinte:

  push "route 192.168.73.0 255.255.255.0"

onde 192.168.73.0/24 é a LAN por trás do servidor. Substitua com o que você usa. Aspas duplas must devem ser mantidas, não descartadas.

AVISO :

Os itens acima falharão se a LAN atrás do servidor e a LAN à qual o cliente pertence se sobrepuserem até certo ponto, e especialmente se eles usarem a mesma sub-rede : no exemplo acima, ele falharia se a LAN do cliente e a LAN do servidor fossem 192.168.73.0/255. Isso é um problema porque a maioria das LANs configuradas automaticamente é 192.168.1.0/24 ou 192.168.0.0/24, de modo que há muitas chances de encontrar uma colisão.

Esta é a razão pela qual eu configurei a LAN da minha casa como 192.168.73.0/24. Mudar a LAN para uma sub-rede incomum é o único remédio possível para tal colisão.

EDITAR:

Em resposta ao seu comentário:

  1. a colisão não é entre a LAN atrás do servidor e os números IP distribuídos para os clientes openvpn, mas entre as duas LANs: seu cliente deve ter, em sua interface ethernet / wifi, um número IP que < strong> must não colidir com a LAN remota. Esqueça a sub-rede dos clientes openvpn.

  2. Uma vez que o acima foi configurado, uma coisa que resta verificar é se o servidor pode transferir pacotes da interface virtual (estou pronto para apostar que é tun0 no seu caso, não tap0 , estou certo ) para a interface normal do servidor (aposto que é eth0, não br0). Isso pode acontecer por dois motivos:

    a. você não permitiu o encaminhamento IPv4. Como sudo,

     echo 1  /proc/sys/net/ipv4/ip_forward
    

    cuidará disso.

    b. Você tem um firewall que bloqueia o encaminhamento de pacotes.

    sudo iptables -F 
    

    limpará suas regras de firewall.

  3. Por fim, lembre-se de usar o MASQUERADE, da seguinte forma:

       iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -d 192.168.33.0/24 -j MASQUERADE
    
por 06.07.2015 / 12:59

Tags