Instrada tutto il traffico attraverso OpenVPN

39

Sì, questa domanda è stata posta un centinaio di volte e ho cercato dappertutto, senza risultati.

Il titolo dice tutto davvero.

Ho un server OpenVPN (su Ubuntu) e posso collegarmi tramite il mio client (Windows 8) ...

Il problema inizia quando provo a instradare TUTTO il traffico attraverso la VPN.

Ho aggiunto le pushbandiere in server.conf:

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

Quando mi connetto dal client, il client genera:

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

Ho provato a usare i flag sul lato client quando ho aperto la connessione:

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

Ma comunque, quando vado su whatsmyip.org, dice ancora i miei clienti ip.

Qualcuno ha avuto questo problema ed è riuscito a risolverlo?

Grazie molto

vpn openvpn

— Solo Lucky Davvero
fonte

Hai provato push "route 0.0.0.0 0.0.0.0"o simile a spingere percorsi? Non dimenticare il percorso di ritorno nella VPN!

— lub

Sì, questo viene fatto automaticamente quando si usa il push "reindirizzamento-gateway def1" ... Aggiunge la maschera 0.0.0.0 127.0.0.0 e la maschera 127.0.0.0 127.0 (superando il percorso predefinito senza eliminare quello già presente)

— Solo Lucky davvero

Sono preoccupato se stai eseguendo il client come "Esegui come amministratore" in Windows! Questo problema può verificarsi se si esegue il client OVPN Windows senza eseguire l'amministratore.

— Kousha,

35

Ho provato questo usando un server OpenVPN e impostando l'opzione def1 redirect-gateway nel client e la configurazione del server funziona bene. Quando accedo a whatismyip.org vedo l'IP del mio server OpenVPN. Di seguito è la configurazione client che uso:

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

Ho testato anche con l'aggiunta dell'opzione def1 redirect-gateway al comando openvpn e ho ottenuto lo stesso risultato. La configurazione del server è:

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

— cioby23
fonte

Ho provato che oggi ... Ancora niente fortuna. Ho notato che stai usando un adattatore TUN piuttosto che un adattatore TAP ... Ci proverò invece e riferirò: D

— Just Lucky Really

1

Ok, l'utilizzo di un adattatore TUN sembra funzionare ... Anche se mi sento un po 'turbato dalle rotte che devo assegnare ... Sto usando 192.168.1.0/24 per la rete VPN e 192.168.0.0/ 24 è la mia LAN del server. Quindi nella mia configurazione del server, ho aggiunto route 192.168.1.0 255.255.255.0e push "route 192.168.0.0 255.255.255.0"ma il mio client non ha accesso ad altre sottoreti a parte la sua rete 192.168.1.0/24 ... Ne prenderò in giro un po 'di più

— Solo Lucky Davvero

20

Forse hai dimenticato di modificare il tuo NAT? Esegui questi 3 comandi come root

comandi:

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

Didascalia:

tun0: la tua scheda di rete VPN virtuale
eth0: la tua normale scheda di rete
10.8.0.0: blocco IP della rete VPN

— chickahoona
fonte

1

Questo passaggio di modifica NAT è molto cruciale. Non riuscivo a farlo funzionare senza eseguire sopra i 3 comandi.

— Nitesh Kumar Anand,

6

si noti che questi comandi devono essere eseguiti sul server openvpn, non sul client.

— Kem Mason,

1

Ho scoperto che solo la modifica della nattabella funzionava anche sul mio server.

— Ginhing,

1

Dobbiamo persistere nelle regole di iptables nel caso in cui il server openVPN venga riavviato?

— DWils,

@DWils Sì, è necessario inserirli in alcuni script di avvio. Dai un'occhiata a

— Arne,

1

Dopo una ricerca intensa della risposta sembra che io abbia risolto questo, forse parzialmente, ma almeno molto semplicemente:

Uso Xubuntu 14.04 e il pacchetto OpenVPN dalla fonte principale. In Impostazioni> Sistema> Rete , ho sostituito l'indirizzo DNS preinstallato 127.0.1.1con quello di Google 8.8.8.8e ora posso vedere tutto il traffico che passa attraverso il server VPN.

Nella tabella di Wireshark è assente una stringa come DNS: tutti i dati passano come TCP attraverso il canale crittografato. Riesco a vedere il traffico DHCP e DNS quando guardo tun0(interno del notebook). Quando esploro il wlan0traffico (esterno tra notebook e router WiFi) ricevo solo pacchetti TCP grigi.

Penso che stia accadendo perché la query DNS non è necessaria nella decodifica da caratteri a numeri e va nello stream comune come un normale pacchetto di dati.

Sarò felice di conoscere le tue considerazioni, non sarà una sorpresa se sbaglio completamente

— xrobot
fonte

Ho dimenticato: questo metodo ha un vantaggio indiscutibile: funziona anche se un server VPN non supporta il reinstradamento DNS.

— Xrobot,

A proposito, potremmo fare un trucco: se di tanto in tanto invieremo false query DNS innocenti e visibili, indirettamente potrebbe essere la conferma della nostra lealtà al Grande Fratello.

— Xrobot,

1

Aggiungi la seguente direttiva al file di configurazione del server:

push "redirect-gateway def1"

Se la tua configurazione VPN è su una rete wireless, dove tutti i client e il server si trovano sulla stessa sottorete wireless, aggiungi il flag locale:

push "redirect-gateway local def1"

L'invio dell'opzione di reindirizzamento-gateway ai client farà sì che tutto il traffico di rete IP proveniente dai computer client passi attraverso il server OpenVPN. Il server dovrà essere configurato per gestire in qualche modo questo traffico, ad esempio NATing su Internet o instradandolo attraverso il proxy HTTP del sito server.

Su Linux, è possibile utilizzare un comando come questo per NAT il traffico del client VPN verso Internet:

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

Questo comando presuppone che la sottorete VPN sia 10.8.0.0/24 (presa dalla direttiva server nella configurazione del server OpenVPN) e che l'interfaccia Ethernet locale sia eth0.

Quando viene utilizzato il gateway di reindirizzamento, i client OpenVPN instraderanno le query DNS attraverso la VPN e il server VPN dovrà gestirle. Ciò può essere ottenuto spingendo un indirizzo del server DNS ai client di connessione che sostituiranno le loro normali impostazioni del server DNS durante il periodo in cui la VPN è attiva. Per esempio:

push "dhcp-option DNS 10.8.0.1"

configurerà i client Windows (o client non Windows con alcuni script sul lato client extra) per utilizzare 10.8.0.1 come server DNS. Qualsiasi indirizzo raggiungibile dai client può essere utilizzato come indirizzo del server DNS.

— Pol Hallen
fonte

0

Se il tuo client OpenVPN si trova su Windows 10 (o simile), c'è un altro problema a cui prestare attenzione, l'ordine di associazione delle schede NIC. Le impostazioni del server DNS esistenti sull'adattatore LAN o Wifi potrebbero avere la priorità sulle impostazioni del server DNS per l'interfaccia del tunnel, quindi anche se tutto è impostato correttamente dal punto di vista di OpenVPN, Windows continua a utilizzare il server DNS originale.

È possibile risolvere questo problema come descritto in questo post del 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- loro-vpn-adattatore-non-la-dnsserver-da-loro? forum = winserverNIS

— JudgedByDredd
fonte

non una risposta alla domanda

— pim

0

Ho riscontrato lo stesso problema e ho scoperto quando si utilizza lo script di installazione PiVPN per Open VPN, la configurazione del server contiene la riga:

push "redirect-gateway def1 bypass-dhcp"

già. Sul client IOS tutto viene instradato automaticamente attraverso il tunnel (questo è ciò che dice il registro).

Sul client Tunnelblick è necessario aggiungere questa riga nel client.ovpn la riga:

redirect-gateway def1 bypass-dhcp

e dovrebbe funzionare perfettamente. Almeno lo ha fatto sul mio Mac.

— Peter
fonte