Impossibile modificare i percorsi con il client VPN

La mia connessione VPN forza tutto il traffico Internet attraverso il tunnel e questo è molto lento. Voglio essere in grado di eseguire il tunneling solo di determinati indirizzi IP e di farlo al mio fianco (lato client).

Mi sto collegando a una VPN con FortiSSL Client , la tabella di routing è simile alla seguente prima che venga stabilita una connessione:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.101     40
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.0.0    255.255.255.0         On-link     192.168.0.101    276
    192.168.0.101  255.255.255.255         On-link     192.168.0.101    276
    192.168.0.255  255.255.255.255         On-link     192.168.0.101    276
    192.168.119.0    255.255.255.0         On-link     192.168.119.1    276
    192.168.119.1  255.255.255.255         On-link     192.168.119.1    276
  192.168.119.255  255.255.255.255         On-link     192.168.119.1    276
    192.168.221.0    255.255.255.0         On-link     192.168.221.1    276
    192.168.221.1  255.255.255.255         On-link     192.168.221.1    276
  192.168.221.255  255.255.255.255         On-link     192.168.221.1    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link     192.168.119.1    276
        224.0.0.0        240.0.0.0         On-link     192.168.221.1    276
        224.0.0.0        240.0.0.0         On-link     192.168.0.101    276
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link     192.168.119.1    276
  255.255.255.255  255.255.255.255         On-link     192.168.221.1    276
  255.255.255.255  255.255.255.255         On-link     192.168.0.101    276

Dopo il collegamento è simile al seguente:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.101   4265
          0.0.0.0          0.0.0.0         On-link        172.16.0.1     21
        127.0.0.0        255.0.0.0         On-link         127.0.0.1   4531
        127.0.0.1  255.255.255.255         On-link         127.0.0.1   4531
  127.255.255.255  255.255.255.255         On-link         127.0.0.1   4531
       172.16.0.1  255.255.255.255         On-link        172.16.0.1    276
      192.168.0.0    255.255.255.0         On-link     192.168.0.101   4501
    192.168.0.101  255.255.255.255         On-link     192.168.0.101   4501
    192.168.0.255  255.255.255.255         On-link     192.168.0.101   4501
    192.168.119.0    255.255.255.0         On-link     192.168.119.1   4501
    192.168.119.1  255.255.255.255         On-link     192.168.119.1   4501
  192.168.119.255  255.255.255.255         On-link     192.168.119.1   4501
    192.168.221.0    255.255.255.0         On-link     192.168.221.1   4501
    192.168.221.1  255.255.255.255         On-link     192.168.221.1   4501
  192.168.221.255  255.255.255.255         On-link     192.168.221.1   4501
   200.250.246.74  255.255.255.255      192.168.0.1    192.168.0.101   4245
        224.0.0.0        240.0.0.0         On-link         127.0.0.1   4531
        224.0.0.0        240.0.0.0         On-link     192.168.119.1   4502
        224.0.0.0        240.0.0.0         On-link     192.168.221.1   4502
        224.0.0.0        240.0.0.0         On-link     192.168.0.101   4502
        224.0.0.0        240.0.0.0         On-link        172.16.0.1     21
  255.255.255.255  255.255.255.255         On-link         127.0.0.1   4531
  255.255.255.255  255.255.255.255         On-link     192.168.119.1   4501
  255.255.255.255  255.255.255.255         On-link     192.168.221.1   4501
  255.255.255.255  255.255.255.255         On-link     192.168.0.101   4501
  255.255.255.255  255.255.255.255         On-link        172.16.0.1    276

Il client VPN inserisce un percorso generale con una metrica inferiore rispetto a tutti i miei altri percorsi e questo instrada tutto il traffico Internet attraverso il tunnel. Ho provato a modificare la metrica della mia route Internet predefinita su un valore inferiore:

C:\Windows\system32>route change 0.0.0.0 mask 0.0.0.0 192.168.0.1 metric 10 if 13
OK!

Ma nulla è cambiato.

Quindi ho provato a eliminare il percorso "catch-all" della VPN, quello con la metrica 21 sopra:

C:\Windows\system32>route delete 0.0.0.0 mask 0.0.0.0 if 50
OK!

E ha rotto tutto:

C:\Windows\system32>ping 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
PING: transmit failed. General failure.

Ho provato a modificare la metrica anche sugli adattatori, ma il client FortiSSL ignora tutte le impostazioni quando si connette, quindi non ha aiutato.

La correzione deve venire dalla mia parte, poiché la gente dall'altra parte impiega giorni a rispondere.

Sto usando Windows 7 x64 se questo aiuta.

- AGGIORNAMENTO (24-12-2013) -

Grazie al consiglio di mbrownnyc , ho esaminato il problema con Rohitab e ho scoperto che il client FortiSSL controlla la tabella delle rotte con la NotifyRouteChangechiamata dell'API IP Helper.

Ho impostato un punto di interruzione prima delle NotifyRouteChangechiamate e ho usato l'opzione "Salta chiamata" per impedire a FortiSSL di ripristinare le metriche del percorso e ora ho:

Percorsi con metriche che favoriscono il mio adattatore Wifi

Tuttavia, quando eseguo tracert, il mio percorso continua a uscire attraverso la VPN:

C:\Windows\system32>tracert www.google.com

Tracing route to www.google.com [173.194.118.83]
over a maximum of 30 hops:

  1    45 ms    47 ms    45 ms  Jurema [172.16.0.1]

C'è qualche aspetto della rete Windows di cui non sono a conoscenza che può favorire un determinato percorso anche se le metriche di route route dicono diversamente?

windows vpn

— Juliano
fonte

Non è forse il punto per il tuo client VPN applicare questa politica? La società probabilmente ha una politica di sicurezza che richiede di non utilizzare il tunneling diviso e aggirare tale politica costituirebbe un rischio per la sicurezza.

— Ryan Ries,

Al contrario. Ora ho accesso ai servizi Web con restrizioni di proprietà intellettuale dei partner di questa società, poiché il mio traffico web viene espulso tramite il loro indirizzo IP Internet. È una configurazione molto pigra da parte loro, come in "Tunnelerò tutto attraverso la VPN, quindi non dovrò mai aggiungere un altro IP o sottorete alla tabella di instradamento".

@Juliano Il punto di evitare il tunneling diviso è impedire agli utenti di entrare in un tunnel e quindi avere accesso ai dati sull'altro tunnel. Mi aspetto che tu abbia lo stesso accesso alla rete a cui stai effettuando il tunneling, che avresti se tu fossi sulla rete. Tuttavia, non si desidera utilizzare un tunnel diviso per garantire tale accesso al mondo.

— BillThor il

In realtà se fossi su quella rete sarei in grado di impostare i miei percorsi e le mie metriche per dare priorità alla connessione Internet che desideravo (3g / 4g cioè.). Avrei questa opzione perché non sarei soggetto a un client VPN ridicolmente restrittivo. Prevenire il tunneling diviso suona bene in teoria, ma mi limita molto più che se fossi effettivamente fisicamente su quella rete. Voi ragazzi state giustificando un'implementazione della sicurezza che mi fa male invece di aiutarmi a trovare una via d'uscita, che è la domanda a portata di mano. Come posso bypassarlo?

Esistono anche metriche di interfaccia: ncpa.cpl> Proprietà NIC> Proprietà voce stack IP v4> scheda Generale / Avanzate> Metrica automatica. Guarda lì su entrambe le interfacce. Vedi anche questo post sul blog su Windows multihomed .

— Mbrownnyc,

Nota che non sto usando la normale notazione di rete per indirizzarmi qui (come CIDR o anche host/masknotazione, per non confondere il richiedente).

Invece di eliminare la route "gateway predefinito" ( 0.0.0.0 mask 0.0.0.0) in modo che lo stack di rete non abbia idea di dove inviare la maggior parte dei pacchetti, prova ad aumentare la metrica della route VPN al di sotto di quella predefinita (in questo caso 4265).

Dopo aver effettuato la connessione con il client Fortigate:

route change 0.0.0.0 mask 0.0.0.0 172.16.0.1 metric 4266 if N

Dove N è il numero di interfaccia per l' fortisslinterfaccia restituita all'inizio di route print.

Lo stack di rete dovrebbe trattare correttamente questo:

La route che "include gli indirizzi di destinazione" gestirà i pacchetti (la route indica allo stack di rete di inviare i pacchetti destinati this IPa this gatewayun ulteriore routing).
Tutti i pacchetti con un IP di destinazione 172.16.*.*verranno inviati alla VPN; perché lo stack di rete di Windows sa che se c'è un indirizzo collegato a un'interfaccia, quell'interfaccia è il modo in cui si accede ad altri IP in quell'intervallo di indirizzi. Posso diventare più esplicito con l'intervallo se pubblichi la "Subnet Mask" per il 172.16.0.1.

È necessario determinare gli indirizzi IP delle risorse a cui è necessario accedere tramite la VPN. Puoi farlo facilmente usando nslookup [hostname of resource]quando connesso senza aver modificato i percorsi.

[Rant]

Non ho alcun problema a consentire il split-tunneling su VPN, in particolare a causa del problema di utilizzo che citi. Se il reparto IT considera il split tunneling un meccanismo di sicurezza, deve ripensare a ciò che sta facendo:

L'accesso alle risorse da parte dei client VPN deve essere isolato e fortemente limitato come se si accedesse via Internet (poiché le risorse in cui non si asserisce il controllo completo presentano un rischio più elevato rispetto alle risorse in cui è possibile affermarne alcune).
Dovrebbero integrare un meccanismo di controllo dell'accesso alla rete per i client VPN. Ciò potrebbe consentire loro di applicare alcune politiche sui computer client (come "sono aggiornate le definizioni antivirus?", Ecc.).
Prendi in considerazione l'utilizzo di una soluzione rigida come Fortigate SSL VPN Virtual Desktop (che è abbastanza facile da configurare e gratuito [me think] con la licenza SSL VPN).

[/ Rant]

— mbrownnyc
fonte

Quando provo a modificare la metrica della route 0.0.0.0 della VPN su un valore superiore alla route Internet, FortiSSL Client imposta la mia route Internet su una metrica ancora più elevata.

— Juliano,

Sulla tabella "dopo" c'erano due route gateway predefinite. La 0.0.0.0 della VPN e la 0.0.0.0 della scheda wifi. Ho eliminato il gateway predefinito della VPN ma ho lasciato quello della scheda wifi, che dovrebbe renderlo come prima, ma ha rotto tutto. O fortissl fa qualcosa in pila per impedire alle persone di fare ciò che sto cercando di fare, o sto sbagliando.

— Juliano,

Sono interfacce diverse, quindi dovresti essere in grado di regolare i costi del percorso separatamente. Se il client osserva la tabella di routing, nulla ti aiuterà lì. Il client Cisco VPN è configurato con un file PRF che può essere controllato sul sistema. Il client Fortigate SSL è probabilmente lo stesso, sia nel registro che nel file. Non sono sicuro di dove sia l'impostazione. Cerca un po 'e potresti trovare qualcosa che ti consente di configurare il client. Inoltre, il "supporto per il tunneling diviso" è la configurazione "lato server" / sull'unità Fortigate.

— Mbrownnyc,

Guardare dentro: HKEY_CURRENT_USER\Software\Fortinet\SslvpnClient. Tunneldovrebbe essere interessante. Ti preghiamo di postare ciò che trovi. O rispondi e segna come un community wikimodo da poter aiutare gli altri.

— Mbrownnyc,

Peccato. Non sei sicuro della tua situazione, ma vale la pena presentare una richiesta per il tunneling diviso? Altrimenti, sembra che dovrai dirottare alcune chiamate API con qualcosa come rohitab o le deviazioni di MSFT. Potrebbe essere un progetto weekend divertente!

— Mbrownnyc,