Recientemente, durante la configuración del servidor VPN, lo único que enfrenté fue que no tengo acceso a Internet conectándome a través de mi servidor VPN. En realidad uso el VPS (Debian 8), donde instalé una VPN. El cliente se conecta normalmente. He utilizado el comando trace route para detectar dónde se detiene el tráfico y, obviamente, se detiene en mi servidor VPN. Realmente no sé cómo lidiar con eso. Alguien me ayuda por favor :) Aquí está mi configuración de servidor y mi configuración de cliente. Y sí, mi lado cliente es Windows 7 y 10.
Configuración del servidor.
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
Configuración del cliente. Nota: La IP del servidor está oculta.
client
dev tun
proto udp
remote 107.155.1x4.1x2 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca "C:\\OVPN\\ca.crt"
cert "C:\\OVPN\\client1.crt"
key "C:\\OVPN\\client1.key"
ns-cert-type server
comp-lzo
verb 3
Desde el lado del cliente intenté probar el servidor DNS 8.8.8.8 de Google, pero aún así no funciona. Creo que el problema radica en algunas de las interfaces del lado del servidor que acceden a Internet. Entonces, cualquiera que sugiera algo, ayúdeme con consejos útiles.
"Agregue la salida de los siguientes comandos: sysctl net.ipv4.ip_forward, iptables-save, ip route show. En el cliente tal vez: route print. – rda "
1) La salida para sysctl net.ipv4.ip_forward
es
net.ipv4.ip_forward = 1
2) La salida para ip route show
es
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
10.8.0.0/24 via 10.8.02 dev tun0
default dev venet0 scope link
3) Y la salida para iptables-save
es
*mangle
:PREROUTING ACCEPT [241673:29858781]
:INPUT ACCEPT [232866:29385621]
:FORWARD ACCEPT [8803:472884]
:OUTPUT ACCEPT [250884:4018010]
:POSTROUTING ACCEPT [259688:40653794]
COMMIT
*filter
:INPUT ACCEPT [232866:29385621]
:FORWARD ACCEPT [8804:472884]
:OUTUPUT ACCEPT [250884:40180910]
COMMIT
*nat
:PREROUTING ACCEPT [20668:1262348]
:POSTROUTING ACCEPT [14826:1006759]
:OUTPUT ACCEPT [10970:791257]
COMMIT
*raw
:PREROUTING ACCEPT [241673:29858781]
:OUTPUT ACCEPT [250884:40180910]
COMMIT
Junio 11
Creo que el problema radica en las tablas de enrutamiento, ejecuté el comando - netstat -nr
y, sorprendentemente, descubrí que en mi tabla de enrutamiento tengo una dirección IP extraña que está asignada solo para uso de VPN.**
Aquí, echa un vistazo:
Tabla de enrutamiento IP del kernel (Nota: los parámetros de la tabla de enrutamiento van de la siguiente manera en la columna (!), Ej.: la IP de la tabla de enrutamiento toma todos los primeros parámetros de la primera columna. Y los últimos tres parámetros MSS Window irtt
son los mismos para cada valor de la tabla de enrutamiento.
Destination face 10.8.0.2 un0 10.8.0.0 un0 0.0.0.0 enet0
Gateway face 0.0.0.0 un0 10.8.0.2 un0 0.0.0.0 enet0
Genmask face 255.255.255.255 un0 255.255.255.0 un0 0.0.0.0 enet0
Flags face UH un0 UG un0 U enet0
MSS Window irtt face 0 0 0 un0 0 0 0 un0 0 0 0 enet0
15 de Junio
¡Hey amigo! ¡Gracias por tu respuesta nuevamente!
la salida para ip route show
es:
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1 10.8.0.0/24 via
10.8.0.2 dev tun0 default dev venet0 scope link
el resultado del siguiente comando en VPS ip route get 8.8.8.8
es (Nota: la dirección IP está oculta):
8.8.8.8 dev venet0 src 107.155.1x4.1x2
cache mtu 1500 advmss 1460 hoplimit 64
En el lado del cliente, utilicé este comando route print
. Obtuve una gran página de direcciones IP, pero no sé qué es importante aquí para resolver este problema...
¿Cuáles son los siguientes pasos?
Muchas gracias de nuevo por tu ayuda, de verdad.
Actualización 15 de junio
Así que aquí está el resultado del comando route print
en el cliente de Windows:
IPv4 Route Table
===========================================================================
Active routes:
Network address Subnet mask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.88.1 192.168.88.208 20
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.50.0 255.255.255.0 On-link 192.168.50.1 276
192.168.50.1 255.255.255.255 On-link 192.168.50.1 276
192.168.50.255 255.255.255.255 On-link 192.168.50.1 276
192.168.56.0 255.255.255.0 On-link 192.168.56.1 266
192.168.56.1 255.255.255.255 On-link 192.168.56.1 266
192.168.56.255 255.255.255.255 On-link 192.168.56.1 266
192.168.88.0 255.255.255.0 On-link 192.168.88.208 276
192.168.88.208 255.255.255.255 On-link 192.168.88.208 276
192.168.88.255 255.255.255.255 On-link 192.168.88.208 276
192.168.100.0 255.255.255.0 On-link 192.168.100.1 276
192.168.100.1 255.255.255.255 On-link 192.168.100.1 276
192.168.100.255 255.255.255.255 On-link 192.168.100.1 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.88.208 276
224.0.0.0 240.0.0.0 On-link 192.168.100.1 276
224.0.0.0 240.0.0.0 On-link 192.168.50.1 276
224.0.0.0 240.0.0.0 On-link 192.168.56.1 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.88.208 276
255.255.255.255 255.255.255.255 On-link 192.168.100.1 276
255.255.255.255 255.255.255.255 On-link 192.168.50.1 276
255.255.255.255 255.255.255.255 On-link 192.168.56.1 266
===========================================================================
Permanent routes:
Actualización 17 de junio
Hola amigo, intenté usar esos comandos que habilitan NAT en el servidor, desafortunadamente nuevamente no funciona. La salida ip route show
es la misma que antes:
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
10.8.0.0/24 via 10.8.0.2 dev tun0
default dev venet0 scope link
Esos comandos que me diste se ejecutaron sin problemas, pero no produjeron ningún resultado. Entonces, ¡la nueva ruta IP simplemente no aparece en la salida! Intenté agregar la misma ruta de diferentes maneras, incluso cambié la máscara de /16 a /24, pero nada.
El únicoimportanteLo que me hizo sentir extraño es que ejecuté mi OVPN Gui en el lado del cliente y sé que Internet no funciona, y lo que veo es que desde el principio mi página de Facebook comienza a cargarse, pero otras como Google. com o linkedin.com, o cualquier otro sitio web, simplemente no se abren...
Algunas cosas menores sobre mi proveedor de VPS, en la página de preguntas frecuentes dicen lo siguiente:
**22
Do you support TUN/TAP? IPSEC?
Yes, TUN/TAP and IPSEC are enabled on all VPS by default.**
**2
What kind of virtualization is offered/used?
We utilize OpenVZ on our infrastructure. If you require KVM virtualization we recommend SpeedyKVM.**
¿Cuál puede ser este problema y cómo podemos superarlo?
¡Nuevamente muchas gracias a ti!
Respuesta1
Tienes que habilitar NAT en el servidor.
SNAT para dirección IP estática:
iptables -t nat -A POSTROUTING -s 10.8.0.0/16 -o <if> -j SNAT --to <ip>
O si tiene una dirección IP asignada dinámicamente MASQUERADE
(más lenta):
iptables -t nat -A POSTROUTING -s 10.8.0.0/16 -o <if> -j MASQUERADE
mientras
<if>
es el nombre de la interfaz externa (es decirvenet0
)<ip>
es la dirección IP de la interfaz externa