Skonfigurowałem serwer OpenVPN na VPS w USA i skonfigurowałem go tak, aby kierował nim cały ruch klientów. Wydaje się, że wszystko działa dobrze w odniesieniu do połączenia VPN w gerneral. Wszystkie strony wyszukiwania adresów IP pokazują mi adres IP serwera nas, a nawet hulu.com działa (nie będzie działać, jeśli nie jesteś w USA). Ale z jakiegoś powodu netflix.com mówi „Przepraszamy, Netflix nie jest jeszcze dostępny w twoim kraju”. Pomyślałem więc, że Netflix prawdopodobnie używa bardziej wyrafinowanych sposobów określania Twojej lokalizacji poza adresem IP. Ale nie mogłem znaleźć sposobu na uruchomienie go, dopóki nie porzuciłem pomysłu korzystania z VPN i zamiast tego połączyłem się z serwerem za pomocą prostego tunelu skarpetowego z ssh, uruchamiając:
ssh -D 9999 user@serverip
Musiałem tylko zmienić klucz
network.proxy.socks_remote_dns
w przeglądarce Firefox z wartości false na true, aby zapobiec wyciekom DNS i skonfigurowaniu proxy proxy. Potem mógłbym wreszcie obejrzeć netflix.com. W rezultacie doszedłem do wniosku, że w przeglądarce nie ma nic (lub coś w rodzaju systemowej strefy czasowej), która mówi netflix o lokalizacji, więc musi mieć coś wspólnego z konfiguracją OpenVPN.
Następnie użyłem tcpdump do zarejestrowania całego ruchu na interfejsie sieciowym serwera venet0 (OpenVZ VPS), odwiedziłem netflix.com na kliencie, najpierw połączony z VPN, a następnie połączony tunelem skarpetowym, a następnie porównałem oba wyjścia.
Jedyną rzeczą, która przykuła moją uwagę, było to, że podczas korzystania z tunelu skarpet serwer używał głównie protokołu IPv6 do łączenia się z serwisem Netflix, natomiast korzystał z protokołu IPv4 tylko wtedy, gdy klient był podłączony do serwera OpenVPN. Ale nie rozumiem, jak to może mieć taką różnicę.
Więc czego mi brakuje? Czy istnieje sposób na skonfigurowanie OpenVPN tak, aby korzystał z ipv6 do łączenia się ze stroną internetową, chociaż istnieje tylko połączenie ipv4 między VPS a klientem?
Oto server.conf serwera OpenVPN (OpenVZ VPS)
local serverip
port 443
proto tcp
dev tun
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/vps1.crt
key ./easy-rsa2/keys/vps1.key # This file should be kept secret
dh ./easy-rsa2/keys/dh1024.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 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
client-to-client
keepalive 10 120
tls-auth ta.key 0 # This file is secret
cipher AES-256-CBC
comp-lzo
max-clients 4
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 3
iptables forwarding
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0 -j SNAT --to-source serverip
(włączone przekazywanie IPv4)
Próbowałem wszystkiego zawsze na Win7 i kliencie Debiana z tylko połączeniami ipv4 i zawsze upewniłem się, że używają właściwego serwera DNS (testowane z ipleak.net i tcpdump / wireshark).
client.conf:
client
dev tun
proto tcp
remote serverip 443
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
tls-auth ta.key 1
cipher AES-256-CBC
comb-lzo
verb 3