A Internet não está funcionando quando a VPN está ativa

Question

A Internet não está funcionando quando a VPN está ativa

Navegue suas respostas

#1 resposta do (0 votos)

1

Gostaria de redirecionar todo o tráfego por meio da VPN, mas não funciona de maneira alguma.

servidor : RT-N16 [TomatoUSB v1.28.0000 MIPSR2-112 K26 USB AIO]

client : Ubuntu 14.04.1

configuração do servidor:

# Automatically generated configuration
daemon
server 10.8.0.0 255.255.255.0
proto tcp-server
port 9999
dev tun21
cipher AES-256-CBC
comp-lzo no
keepalive 15 60
verb 3
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 192.168.1.1"
push "redirect-gateway def1"
ca ca.crt
dh dh.pem
cert server.crt
key server.key
status-version 2
status status
# Custom Configuration (these section appears to be main FIX):
client-to-client
push "comp-lzo"
push "redirect-gateway"

servidor: iptables -L -t nat -n (apenas a cadeia de saída POSTROUTING)

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0           
SNAT       all  --  192.168.1.0/24       192.168.1.0/24      to:192.168.1.1

log do servidor:

Feb  4 21:19:38 r daemon.notice openvpn[1072]: TCP connection established with [AF_INET]192.168.1.4:58170
Feb  4 21:19:39 r daemon.notice openvpn[1072]: 192.168.1.4:58170 TLS: Initial packet from [AF_INET]192.168.1.4:58170, sid=00fe6a02 33820233
Feb  4 21:19:39 r daemon.notice openvpn[1072]: 192.168.1.4:58170 VERIFY OK: XXXXXXXXXXXXXXXX
Feb  4 21:19:39 r daemon.notice openvpn[1072]: 192.168.1.4:58170 VERIFY OK: XXXXXXXXXXXXXXXX
Feb  4 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Feb  4 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Feb  4 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Feb  4 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Feb  4 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Feb  4 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 [client] Peer Connection Initiated with [AF_INET]192.168.1.4:58170
Feb  4 21:19:40 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Feb  4 21:19:40 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 MULTI: Learn: 10.8.0.6 -> client/192.168.1.4:58170
Feb  4 21:19:40 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 MULTI: primary virtual IP for client/192.168.1.4:58170: 10.8.0.6
Feb  4 21:19:43 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 PUSH: Received control message: 'PUSH_REQUEST'
Feb  4 21:19:43 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 send_push_reply(): safe_cap=940
Feb  4 21:19:43 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 SENT CONTROL [client]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,dhcp-option DNS 192.168.1.1,redirect-gateway def1,route 10.8.0.1,topology net30,ping 15,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5' (status=1)

configuração do cliente:

client
remote 192.168.1.1 9999
ca ca.crt
cert client.crt
key client.key
cipher AES-256-CBC
dev tun
proto tcp
nobind
auth-nocache
script-security 2
persist-key
persist-tun
user nobody
group nogroup

cliente: netstat -nr (com vpn up):

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.8.0.5        128.0.0.0       UG        0 0          0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 wlan0
10.8.0.1        10.8.0.5        255.255.255.255 UGH       0 0          0 tun0
10.8.0.5        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
128.0.0.0       10.8.0.5        128.0.0.0       UG        0 0          0 tun0
192.168.1.0     10.8.0.5        255.255.255.0   UG        0 0          0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan0
192.168.1.1     192.168.1.1     255.255.255.255 UGH       0 0          0 wlan0

log do cliente:

Wed Feb  4 21:32:24 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec  1 2014
Wed Feb  4 21:32:24 2015 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Wed Feb  4 21:32:24 2015 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Wed Feb  4 21:32:24 2015 Attempting to establish TCP connection with [AF_INET]192.168.1.1:9999 [nonblock]
Wed Feb  4 21:32:25 2015 TCP connection established with [AF_INET]192.168.1.1:9999
Wed Feb  4 21:32:25 2015 TCPv4_CLIENT link local: [undef]
Wed Feb  4 21:32:25 2015 TCPv4_CLIENT link remote: [AF_INET]192.168.1.1:9999
Wed Feb  4 21:32:26 2015 [zais.dnsd.me] Peer Connection Initiated with [AF_INET]192.168.1.1:9999
Wed Feb  4 21:32:29 2015 TUN/TAP device tun0 opened
Wed Feb  4 21:32:29 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Feb  4 21:32:29 2015 /sbin/ip link set dev tun0 up mtu 1500
Wed Feb  4 21:32:29 2015 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5
Wed Feb  4 21:32:29 2015 GID set to nogroup
Wed Feb  4 21:32:29 2015 UID set to nobody
Wed Feb  4 21:32:29 2015 Initialization Sequence Completed
Wed Feb  4 21:32:43 2015 write to TUN/TAP : Invalid argument (code=22)
Wed Feb  4 21:32:58 2015 write to TUN/TAP : Invalid argument (code=22)
Wed Feb  4 21:33:13 2015 write to TUN/TAP : Invalid argument (code=22)
Wed Feb  4 21:33:28 2015 write to TUN/TAP : Invalid argument (code=22)

UPDATE: obrigado pela ajuda. VPN está funcionando agora (não tenho certeza, mas eu preciso esperar cerca de 5 minutos após a conexão para realmente levá-lo ao estado de trabalho, pode ser os limites do meu roteador, como não o suficiente CPU / MEM)

openvpn router

por zais 04.02.2015 / 19:40

1 resposta

Tags openvpn router

Por que a implementação do Linux IPSec não suporta fragmentação antes da criptografia? Configurar um “servidor” de som

score 0 · Accepted Answer

Por algum motivo, seu cliente não pode excluir a rota padrão atual quando o túnel é aberto, fazendo com que duas rotas padrão existam na tabela de roteamento.

O que você terá que fazer é dar à rota atual uma métrica mais baixa (maior número) antes do túnel aparecer. Você pode ver a métrica com o comando route -n:

# route -n 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.4.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.3.0     10.8.1.2        255.255.255.0   UG    0      0        0 tun0
9.15.64.0       0.0.0.0         255.255.252.0   U     0      0        0 eth0
0.0.0.0         9.15.64.1       0.0.0.0         UG    0      0        0 eth0

Por exemplo, dê à sua interface wlan uma métrica de 20 e deixe a rota do túnel aparecer com uma métrica de zero. Seu tráfego será enviado pela rota do túnel.

Para configurar a métrica na interface, basta abrir o arquivo da interface wlan no diretório / etc / sysconfig / network-scripts e adicionar um parâmetro chamado METRIC = 20.

Isso deve ser feito. Certifique-se de verificar isso depois com o comando route -n.

ATUALIZAÇÃO:

Agora que você tem a rota padrão adequada, é hora de solucionar problemas com tcpdump e pings. Por exemplo, tente o comando abaixo e faça algum ping para a rede remota.

# 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
09:59:13.591764 IP 192.168.4.190 > 192.168.3.1: ICMP echo request, id 3154, seq 4, length 64
09:59:13.681290 IP 192.168.3.1 > 192.168.4.190: ICMP echo reply, id 3154, seq 4, length 64
09:59:14.592829 IP 192.168.4.190 > 192.168.3.1: ICMP echo request, id 3154, seq 5, length 64
09:59:14.680878 IP 192.168.3.1 > 192.168.4.190: ICMP echo reply, id 3154, seq 5, length 64

Meu palpite é que você verá a solicitação de eco, mas não a resposta de eco. Isso significa que o terminal remoto não está roteando os pacotes de volta. Você precisa corrigir as rotas lá também no arquivo de configuração do servidor.

UPDATE2

A partir do seu tcpdump, é claro que o seu cliente está roteando os pacotes através do túnel, portanto, seu problema está no terminal remoto, porque não está montando os pacotes de volta.

listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
09:19:28.964361 IP 10.8.0.6.57394 > 192.168.1.1.domain: 60317+ A? daisy.ubuntu.com.localdomain. (46)
09:19:28.964382 IP 10.8.0.6.57394 > 8.8.8.8.domain: 60317+ A? daisy.ubuntu.com.localdomain. (46)
09:19:28.964398 IP 10.8.0.6.57394 > 8.8.4.4.domain: 60317+ A? daisy.ubuntu.com.localdomain. (46)

Você deve examinar cada salto para ver como é a tabela de roteamento. Comece com 192.168.1.1. Sabe para onde encaminhar pacotes enviados para 10.8.0.6?