Forza il client della rete Juniper a utilizzare il routing suddiviso

Sto usando il client Juniper per OSX ("Network Connect") per accedere alla VPN di un client. Sembra che il client sia configurato per non utilizzare il routing suddiviso. L'host VPN del client non è disposto ad abilitare il routing suddiviso.

C'è un modo per scavalcare questa configurazione o fare un po 'di tempo sulla mia workstation per ottenere il traffico di rete non client per bypassare la VPN? Questo non sarebbe un grosso problema, ma nessuna delle mie stazioni radio in streaming (ad esempio XM) funzionerà connessa alla loro VPN.

Ci scusiamo per eventuali inesattezze nella terminologia.

** modificare **

Il client Juniper modifica il file resol.conf del mio sistema da:

nameserver 192.168.0.1

per:

search XXX.com [redacted]
nameserver 10.30.16.140
nameserver 10.30.8.140

Ho tentato di ripristinare la mia voce DNS preferita nel file

$ sudo echo "nameserver 192.168.0.1" >> /etc/resolv.conf

ma questo provoca il seguente errore:

-bash: /etc/resolv.conf: Permission denied

In che modo l'account superutente non ha accesso a questo file? C'è un modo per impedire al client Juniper di apportare modifiche a questo file?

Sul problema delle autorizzazioni Marcus ha ragione nella sua risposta, ma esiste un modo più semplice di aggiungere file che richiedono privilegi di superutente:

$ echo "nameserver 192.168.0.1" | sudo tee -a /etc/resolv.conf

Il comando tee divide l'output (come una giunzione a T) sia in un file che in uno stdout. -a farà in modo che venga aggiunto al file anziché sovrascriverlo completamente (cosa che molto probabilmente non si desidera quando si manipolano i file di sistema come resol.conf o hosts). sudo farà in modo che tee venga eseguito con accesso super utente in modo che possa modificare il file.

Penso che il problema sia ciò che viene eseguito come root in questa riga:

sudo echo "nameserver 192.168.0.1" >> /etc/resolv.conf

Solo il comando "echo" viene eseguito come root e l'output della scrittura del file viene eseguito con l'utente normale, che probabilmente non ha accesso a /etc/resolv.conf.

Prova a eseguirlo in questo modo:

sudo su
echo "nameserver 192.168.0.1" >> /etc/resolv.conf
exit

Come ti hanno già spiegato, il problema è che il criterio viene applicato sul lato client ma impostato sul lato server. Questa è una funzione di sicurezza che consente alla rete di connessione di evitare che i clienti "colleghino" reti non sicure e sicure insieme.

L'unico modo è "hackerare" il client per non obbedire al comando lato server.

C'è un tutorial che puoi trovare sul web ( http://www.digitalinternals.com/network/workaround-juniper-junos-pulse-split-tunneling-restriction/447/ ) che è basato su Windows, ma in realtà richiede strumenti come IDA Pro e competenze in linguaggio assembly per correggere il binario Pulse. Questo può anche essere considerato illegale in diversi paesi.

Fondamentalmente, sebbene l'esperienza dell'utente possa essere degradata costringendo il client a instradare completamente attraverso la rete di destinazione, ciò consente agli amministratori di rete di mantenere la propria rete più sicura e semplicemente non dovresti farlo.

Spero che sia di aiuto.

Credo che la politica sia stata forzata dal server. A meno che non modifichi in qualche modo il software client Juniper Vpn, dovrai utilizzare il routing dettato.

Fa parte del set di funzionalità del software VPN che può applicare politiche di sicurezza sui client.

L'unico modo per impedirlo è non collegarsi. Questa è una funzione di sicurezza integrata nell'appliance di ginepro back-end. Il client Juniper che avvia semplicemente applica la politica configurata dagli amministratori di Juniper / rete che funzionano per l'azienda client. È molto semplice configurare l'appliance di ginepro per consentire il tunneling diviso. Se non è configurato, è una svista o una scelta. Chiedi loro di abilitarlo. Se non possono o non vogliono, allora è la loro politica di sicurezza. Avviso equo: l'hacking o lo sfruttamento di un modo per eludere tale politica viola il codice di condotta con il cliente (presupponendo che abbiano politiche di utilizzo online) e in molti casi può essere considerato criminale. Può anche distruggere qualsiasi sicurezza che hanno tentato di integrare nella propria rete da utenti remoti ... Sei diventato un vettore per loro.

So che è molto lento navigare in questo modo, lo streaming video è particolarmente divertente, per non parlare di ogni singolo passaggio registrato sull'appliance di ginepro! Fa molto male anche alla larghezza di banda dei clienti poiché richiede un morso di risorse più volte semplicemente reindirizzando il traffico in entrata e in uscita dalla propria rete.

Avvia il client VPN da una macchina virtuale ... voilà. Ovviamente devi lavorare dalla macchina virtuale.

Spero di capire la tua domanda, sei VPN in un client ma non riesci ad accedere al tuo XM o ad altri siti. Ciò potrebbe essere dovuto a un filtro Web sulla loro estremità. Suggerirei, se esiste un'opzione, di abilitare l'accesso LAN locale sul tuo client VPN. Questo potrebbe risolvere il tuo problema.

Sto usando il client Juniper NC su un client Fedora Linux e sono in grado di creare route statiche verso servizi specifici o segmenti di rete. Ad esempio, la rete a cui mi sto collegando non consente l'IMAP in uscita, quindi faccio un percorso statico al mio account di posta. È necessario l'accesso root, ovviamente. Ho anche provato a cancellare la rotta predefinita che NC crea ma ha un demone che lo aggiunge di nuovo in pochi secondi.