☰

OpenVPN, cambios de IP, pero algunos sitios aún no están disponibles

tag-icon • tag-icon firefox vpn proxy openvpn
OpenVPN, cambios de IP, pero algunos sitios aún no están disponibles

Configuré un servidor OpenVPN, usando este comando:

sudo openvpn --config OpenVPN/England-TCP.ovpn

Y si luego verifico mi IP usando este comando:

curl ifconfig.me

Puedo ver que la IP efectivamente ha sido cambiada. También puedo ver que Telegram (que está censurado en mi país) funciona correctamente cuando le digo que "use la configuración de proxy del sistema".

Y si busco "mi ip" en DuckDuckGo o la busco en sitios comohttps://whatismyipaddress.com/, puedo ver que la IP ha sido cambiada.

Pero todavía no puedo acceder a sitios como Twitter, YouTube (que están censurados en mi país)

Twitter se abre, pero permanece así:

ingrese la descripción de la imagen aquí

Y Firefox muestra esto para YouTube:

ingrese la descripción de la imagen aquí

¿Cómo puedo arreglar esto?

El contenido de England-TCP.ovpncontiene certificate keys, por lo que no estoy seguro de si debo compartirlo en línea, pero estas líneas pueden ser relevantes:

client
dev tun

remote uk.ovadd.com 443 tcp

persist-key
persist-tun
resolv-retry infinite
route-metric 1

nobind
pull

verb 3

auth-user-pass

Utilizo Arch Linux y mi sistema usa 192.168.1.1:

╰─ nmcli dev show | grep DNS
IP4.DNS[1]:                             192.168.1.1

Además, aquí está el resultado de ip addr:

╰─ ip addr                                                                                                 ─╯
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 54:42:49:ec:36:64 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 4c:0f:6e:df:2e:3e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.5/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 75921sec preferred_lft 75921sec
    inet6 fe80::5aed:4888:9ec5:ce88/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 10.7.2.146 peer 10.7.2.145/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::341b:f484:9cd1:a004/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

Cambié la configuración de DNS de mi red a 8.8.8.8(o incluso 1.1.1.1) así:

ingrese la descripción de la imagen aquí

Y reconectado para que:

╰─ cat /etc/resolv.conf                                                                                   
# Generated by NetworkManager
search Home
nameserver 192.168.1.1
nameserver 8.8.8.8

Pero todo sigue igual.

Respuesta1

Es probable que el problema sea su DNS. El servidor DNS especificado está en su LAN y, muy probablemente, en su enrutador. El tráfico a su enrutador no pasa a través de su VPN y probablemente obtenga respuestas DNS de su ISP, quien probablemente no devuelva el resultado correcto.

Una solución sería cambiar sus servidores DNS a algo que no sea local, como 1.1.1.1 (Cloudflare) o 8.8.8.8 (Google).

No uso Arch, por lo que es posible que necesites buscarlo en Google, pero muchas distribuciones de Linux te permiten especificar DNS en /etc/resolve.conf (inserta una línea "nameserver 8.8.8.8" encima de cualquier otra entrada del servidor de nombres y edita el archivo como root ). Sin embargo, YMMV ya que es probable que DHCP lo sobrescriba.

Otra posibilidad podría ser cambiar el servidor DNS que su enrutador entrega a los clientes DHCP (muchos enrutadores lo admiten) o cambiar el uso de una dirección IP estática en su computadora para que los servidores DNS no se sobrescriban, o usar una solución alternativa específica de su distribución.

información relacionada