OpenVPN, IP-Änderungen, aber einige Sites sind immer noch nicht verfügbar

OpenVPN, IP-Änderungen, aber einige Sites sind immer noch nicht verfügbar

Ich habe mit diesem Befehl einen OpenVPN-Server eingerichtet:

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

Und wenn ich dann meine IP mit diesem Befehl überprüfe:

curl ifconfig.me

Ich kann sehen, dass die IP tatsächlich geändert wurde. Ich kann auch sehen, dass Telegram (das in meinem Land zensiert wird) ordnungsgemäß funktioniert, wenn ich ihm sage, dass es „die Proxy-Einstellungen des Systems verwenden“ soll.

Und wenn ich "meine IP" in DuckDuckGo suche oder sie auf Seiten wiehttps://whatismyipaddress.com/, ich kann sehen, dass die IP geändert wurde.

Aber ich kann immer noch nicht auf Websites wie Twitter oder YouTube zugreifen (die in meinem Land zensiert sind).

Twitter öffnet sich, bleibt aber so:

Bildbeschreibung hier eingeben

Und Firefox zeigt dies für YouTube:

Bildbeschreibung hier eingeben

Wie kann ich das beheben?

Der Inhalt von England-TCP.ovpnenthält certificate keys, daher bin ich nicht sicher, ob ich ihn online teilen sollte, aber diese Zeile könnte relevant sein:

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

Ich verwende Arch Linux und mein System verwendet 192.168.1.1:

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

Hier ist außerdem die Ausgabe von 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

Ich habe die DNS-Einstellungen meines Netzwerks 8.8.8.8wie folgt geändert 1.1.1.1:

Bildbeschreibung hier eingeben

Und wieder verbunden, sodass:

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

Aber alles ist noch beim Alten.

Antwort1

Das Problem liegt wahrscheinlich an Ihrem DNS. Der angegebene DNS-Server befindet sich in Ihrem LAN und höchstwahrscheinlich auf Ihrem Router. Der Datenverkehr zu Ihrem Router läuft nicht über Ihr VPN und erhält seine DNS-Antworten wahrscheinlich von Ihrem ISP, der wahrscheinlich nicht das richtige Ergebnis zurückgibt.

Eine Lösung wäre, Ihre DNS-Server auf einen nicht lokalen Server zu ändern, beispielsweise 1.1.1.1 (Cloudflare) oder 8.8.8.8 (Google).

Ich verwende Arch nicht, Sie müssen also vielleicht googeln, aber viele Linux-Distributionen ermöglichen Ihnen die Angabe von DNS in /etc/resolve.conf (Fügen Sie über allen anderen Nameserver-Einträgen eine Zeile „nameserver 8.8.8.8“ ein und bearbeiten Sie die Datei als Root). Ihre Ergebnisse können jedoch abweichen, da dies wahrscheinlich von DHCP überschrieben wird.

Eine andere Möglichkeit könnte darin bestehen, den DNS-Server zu ändern, den Ihr Router an DHCP-Clients weitergibt (viele Router unterstützen dies) oder auf Ihrem Computer auf die Verwendung einer statischen IP-Adresse umzusteigen, damit DNS-Server nicht überschrieben werden – oder Ihren distributionsspezifischen Workaround zu verwenden.

verwandte Informationen