Kieruj cały ruch przez OpenVPN

Tak, to pytanie zostało zadane sto razy, a ja szukałem wszędzie, bezskutecznie.

Tytuł mówi wszystko naprawdę.

Mam serwer OpenVPN (na ubuntu) i mogę się z nim połączyć przez mojego klienta (Windows 8) ...

Problem zaczyna się, gdy próbuję przekierować CAŁY ruch przez VPN.

Dodałem pushflagi w server.conf:

push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"

Kiedy łączę się z klientem, klient generuje:

Wed May 07 21:38:40 2014 SENT CONTROL [StretchVPN-CA]: 'PUSH_REQUEST' (status=1)
Wed May 07 21:38:41 2014 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 8.8.8.8,route-gateway <Remote Router IP>,ping 10,ping-restart 120,ifconfig 192.168.0.201 255.255.255.0'
Wed May 07 21:38:41 2014 OPTIONS IMPORT: timers and/or timeouts modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: --ifconfig/up options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: route options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: route-related options modified
Wed May 07 21:38:41 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed May 07 21:38:41 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed May 07 21:38:41 2014 open_tun, tt->ipv6=0
Wed May 07 21:38:41 2014 TAP-WIN32 device [Local Area Connection 4] opened: \\.\Global\{1F145805-92FC-454E-8FD9-0A6017DD4AD1}.tap
Wed May 07 21:38:41 2014 TAP-Windows Driver Version 9.9
Wed May 07 21:38:41 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.0.201/255.255.255.0 on interface {1F145805-92FC-454E-8FD9-0A6017DD4AD1} [DHCP-serv: 192.168.0.0, lease-time: 31536000]
Wed May 07 21:38:41 2014 Successful ARP Flush on interface [35] {1F145805-92FC-454E-8FD9-0A6017DD4AD1}
Wed May 07 21:38:46 2014 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD <Remote Router IP> MASK 255.255.255.255 172.20.10.1
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 192.168.0.3
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 192.168.0.3
Wed May 07 21:38:46 2014 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed May 07 21:38:46 2014 Route addition via IPAPI succeeded [adaptive]
Wed May 07 21:38:46 2014 Initialization Sequence Completed

Podczas otwierania połączenia próbowałem użyć flag po stronie klienta:

openvpn --config "C:\Program Files\OpenVPN\config\client.ovpn" --redirect-gateway def1 --route-method exe

Ale mimo to, kiedy wchodzę na whatsmyip.org, nadal mówi ip moich klientów.

Czy ktoś miał ten problem i zdołał go rozwiązać?

Wielkie dzięki

Przetestowałem to za pomocą serwera OpenVPN i ustawienie opcji def1-gateway def1 w konfiguracji klienta i serwera działa dobrze. Kiedy uzyskuję dostęp do whatismyip.org , widzę adres IP mojego serwera OpenVPN. Poniżej znajduje się konfiguracja klienta, której używam:

client
dev tun
proto udp
# THE IP OF THE REMOTE OPENVPN SERVER:
remote ip_address port
resolv-retry infinite
nobind
persist-key
persist-tun
# THE CSR FILE:
pkcs12 certificate.p12
ns-cert-type server
cipher AES-256-CBC
comp-lzo
redirect-gateway def1
verb 3

Testowałem również z dołączeniem opcji def1 przekierowania-bramy do komendy openvpn i osiągnąłem ten sam wynik. Konfiguracja serwera to:

port 1194
proto udp
dev tun

dh /etc/openvpn/easy-rsa/keys/dh1024.pem
ca /etc/openvpn/easy-rsa/keys/ca.crt
# ENSURE THE DOMAIN NAME/FILENAME IS CORRECT:
cert /etc/openvpn/easy-rsa/keys/cert.crt
key /etc/openvpn/easy-rsa/keys/cert.key

server 10.5.3.0  255.255.255.0
# YOUR LOCAL SERVER IP HERE:
client-config-dir ccd
route 10.5.3.0 255.255.255.0
ifconfig-pool-persist ipp.txt
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun

status log/openvpn-status.log 5
status-version 2
log-append log/openvpn.log
verb 3  # verbose mode
management localhost port /etc/openvpn/management-password

# ROUTE THE CLIENT'S INTERNET ACCESS THROUGH THIS SERVER:
push "redirect-gateway def1"
push "remote-gateway vpn_server_ip"
push "dhcp-option DNS 8.8.8.8"
keepalive 10 60

Może zapomniałeś zmodyfikować swój NAT? Uruchom te 3 polecenia jako root

Polecenia:

iptables -I FORWARD -i tun0 -o eth0 \
         -s 10.8.0.0/24 -m conntrack --ctstate NEW -j ACCEPT

iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED \
         -j ACCEPT

iptables -t nat -I POSTROUTING -o eth0 \
          -s 10.8.0.0/24 -j MASQUERADE

Podpis:

• tun0: twoja wirtualna karta sieci VPN
• eth0: twoja normalna karta sieciowa
• 10.8.0.0: blok IP twojej sieci VPN

Po ciężkim poszukiwaniu odpowiedzi wydaje się, że rozwiązałem to, być może częściowo, ale przynajmniej bardzo prosto:

Używam Xubuntu 14.04 i pakietu OpenVPN z głównego źródła. W Ustawienia> System> Sieci , Wymieniłem preinstalowanego DNS-adres 127.0.1.1z Google 8.8.8.8, a teraz widzę, cały ruch przechodzący przez VPN-serwer.

W tabeli Wiresharka nie ma takiego ciągu jak DNS: wszystkie dane przesyłane są jak TCP przez zaszyfrowany kanał. Widzę ruch DHCP i DNS, kiedy patrzę tun0(wewnętrzny notebook). Kiedy eksploruję wlan0ruch (zewnętrzny między notebookiem a routerem WiFi), dostaję tylko szare pakiety TCP.

Wydaje mi się, że tak się dzieje, ponieważ zapytania DNS nie są potrzebne w dekodowaniu znaków do liczb i są wspólne, jak zwykły pakiet danych.

Z przyjemnością poznam twoje uwagi, nie będę zaskoczony, jeśli całkowicie się mylę

Dodaj następującą dyrektywę do pliku konfiguracyjnego serwera:

push "redirect-gateway def1"

Jeśli konfiguracja VPN odbywa się za pośrednictwem sieci bezprzewodowej, w której wszyscy klienci i serwer znajdują się w tej samej podsieci bezprzewodowej, dodaj flagę lokalną:

push "redirect-gateway local def1"

Przekazywanie opcji bramy przekierowania klientom spowoduje, że cały ruch sieciowy IP pochodzący z komputerów klienckich będzie przechodził przez serwer OpenVPN. Serwer należy skonfigurować w taki sposób, aby w jakiś sposób poradził sobie z tym ruchem, na przykład poprzez translację NAT do Internetu lub kierowanie go przez serwer proxy HTTP witryny.

W systemie Linux można użyć takiego polecenia, aby NAT NAT ruch klienta VPN do Internetu:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

To polecenie zakłada, że ​​podsieć VPN to 10.8.0.0/24 (wzięta z dyrektywy serwera w konfiguracji serwera OpenVPN), a lokalny interfejs Ethernet to eth0.

Gdy używana jest brama przekierowania, klienci OpenVPN będą kierować zapytania DNS przez VPN, a serwer VPN będzie musiał je obsłużyć. Można to osiągnąć poprzez przekazanie adresu serwera DNS łączącym się klientom, którzy zastąpią ich normalne ustawienia serwera DNS w czasie, gdy VPN jest aktywny. Na przykład:

push "dhcp-option DNS 10.8.0.1"

skonfiguruje klientów Windows (lub klientów innych niż Windows z dodatkowymi skryptami po stronie klienta) do używania 10.8.0.1 jako serwera DNS. Dowolny adres dostępny dla klientów może być wykorzystany jako adres serwera DNS.

Jeśli Twój klient OpenVPN działa w systemie Windows 10 (lub podobnym), należy zwrócić uwagę na inny problem - kolejność wiązania kart sieciowych. Istniejące ustawienia serwera DNS na karcie LAN lub Wi-Fi mogą mieć wyższy priorytet niż ustawienia serwera DNS dla interfejsu tunelu, więc nawet jeśli wszystko jest skonfigurowane poprawnie z punktu widzenia OpenVPN, Windows nadal korzysta z oryginalnego serwera DNS.

Możesz to naprawić zgodnie z opisem w tym poście na forum Microsoft.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/1cc5b647-6e51-482b-8998-ac5c3900938c/how-to-force-vpn-clients-to-use-the-dnsserver-from- ich-vpn-adapter-not-the-dnsserver-from-their? forum = winserverNIS

Napotkałem ten sam problem i dowiedziałem się, że używając skryptu instalacyjnego PiVPN dla Open VPN, konfiguracja serwera zawiera wiersz:

Wciśnij „redirect-gateway def1 bypass-dhcp”

już. Na kliencie IOS wszystko jest automatycznie kierowane przez tunel (tak mówi dziennik).

Na kliencie Tunnelblick musisz dodać tę linię do pliku client.ovpn:

redirect-gateway def1 bypass-dhcp

i powinno działać idealnie. Przynajmniej na moim komputerze Mac.