Kieruj cały ruch przez OpenVPN


39

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


Czy próbowałeś push "route 0.0.0.0 0.0.0.0"lub podążałeś za pchaniem tras? Nie zapomnij trasy z powrotem w VPN!
lub

Tak, robi się to automatycznie, gdy używany jest push „redirect-gateway def1” ... Dodaje maskę 0.0.0.0 127.0.0.0 i 127.0.0.0 maskę 127.0.0.0 (wyprzedzanie trasy domyślnej bez usuwania już tam istniejącej)
Po prostu Lucky Naprawdę

Niepokoi mnie, jeśli używasz klienta jako „Uruchom jako administrator” w systemie Windows! Ten problem może się zdarzyć, jeśli uruchomisz klienta Windows OVPN bez uruchamiania administratora.
Kousha,

Odpowiedzi:


35

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

Próbowałem tego dzisiaj ... Nadal nie ma szczęścia. Zauważyłem, że używasz adaptera TUN zamiast adaptera TAP ... Zamiast tego spróbuję i zdam raport: D
Just Lucky Naprawdę

1
Okie, używanie adaptera TUN wydaje się działać ... Chociaż trochę niepokoją mnie trasy, które muszę przypisać ... Używam 192.168.1.0/24 dla sieci VPN i 192.168.0.0/ 24 to moja sieć LAN serwera. Więc w moim config server dodałem route 192.168.1.0 255.255.255.0i push "route 192.168.0.0 255.255.255.0"ale mój klient nie jest uzyskanie dostępu do innych podsieci oprócz To 192.168.1.0/24 siatki ... będę grzebać trochę więcej
po prostu szczęśliwy Really

19

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

1
Ten krok modyfikacji NAT jest bardzo ważny. Po prostu nie mogłem tego uruchomić bez wykonania powyżej 3 poleceń.
Nitesh Kumar Anand,

6
zauważ, że te polecenia muszą być uruchamiane na serwerze openvpn, a nie na kliencie.
Kem Mason

1
Odkryłem, że tylko modyfikowanie nattabeli działało również na moim serwerze.
Ginhing,

1
Czy musimy zachować reguły iptables na wypadek ponownego uruchomienia serwera openVPN?
DWils

@DWils Tak, musisz umieścić je w skrypcie startowym. Sprawdź to pytania i odpowiedzi: askubuntu.com/questions/270693/…
Arne

1

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ę


Zapomniałem: ta metoda ma jedną niezaprzeczalną zaletę - działa, nawet jeśli serwer VPN nie obsługuje przekierowywania DNS.
xrobot

Nawiasem mówiąc, możemy zrobić jedną sztuczkę: jeśli będziemy wysyłać od czasu do czasu fałszywe, niewinne zapytania DNS, pośrednio może to być potwierdzenie naszej lojalności wobec Wielkiego Brata.
xrobot

1

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.


0

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


brak odpowiedzi na pytanie
pim

0

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.