OpenVPN, IP-адрес меняется, но некоторые сайты по-прежнему недоступны

OpenVPN, IP-адрес меняется, но некоторые сайты по-прежнему недоступны

Я настроил сервер OpenVPN с помощью этой команды:

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

А если я затем проверю свой IP с помощью этой команды:

curl ifconfig.me

Я вижу, что IP действительно был изменен. Я также вижу, что Telegram (который цензурирован в моей стране) работает нормально, когда я говорю ему «использовать системные настройки прокси».

А если я ввожу в поиск "мой IP" в DuckDuckGo или ищу его на таких сайтах, какhttps://whatismyipaddress.com/, я вижу, что IP-адрес был изменен.

Но я по-прежнему не могу получить доступ к таким сайтам, как Twitter, YouTube (которые подвергаются цензуре в моей стране).

Twitter открывается, но остается таким:

введите описание изображения здесь

А Firefox показывает это для YouTube:

введите описание изображения здесь

Как я могу это исправить?

Содержимое England-TCP.ovpnсодержит certificate keys, поэтому я не уверен, стоит ли публиковать его в сети, но эти строки могут быть актуальны:

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

Я использую Arch Linux, и моя система использует 192.168.1.1:

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

А вот и вывод 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

Я изменил настройки DNS моей сети на 8.8.8.8(или даже 1.1.1.1) так:

введите описание изображения здесь

И снова подключились так, что:

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

Но все осталось по-прежнему.

решение1

Проблема, скорее всего, в вашем DNS. Указанный DNS-сервер находится в вашей локальной сети, и, скорее всего, в вашем маршрутизаторе. Трафик к вашему маршрутизатору не проходит через ваш VPN и, скорее всего, получает свои DNS-ответы от вашего интернет-провайдера, который, скорее всего, не возвращает правильный результат.

Решением может стать изменение DNS-серверов на что-то не локальное, например, 1.1.1.1 (Cloudflare) или 8.8.8.8 (Google).

Я не использую Arch, поэтому вам, возможно, придется поискать в Google, но многие дистрибутивы Linux позволяют указывать DNS в /etc/resolve.conf (вставьте строку «nameserver 8.8.8.8» выше любых других записей сервера имен и отредактируйте файл как root). YMMV, хотя это, скорее всего, перезаписывается DHCP.

Другой возможностью может быть изменение DNS-сервера, который ваш маршрутизатор раздает DHCP-клиентам (многие маршрутизаторы поддерживают эту функцию), или переход на использование статического IP-адреса на вашем компьютере, чтобы DNS-серверы не перезаписывались, или использование обходного пути, специфичного для вашего дистрибутива.

Связанный контент