Obligar al cliente de Juniper-network a usar enrutamiento dividido

Estoy usando el cliente Juniper para OSX ('Network Connect') para acceder a la VPN de un cliente. Parece que el cliente está configurado para no usar enrutamiento dividido. El host VPN del cliente no está dispuesto a habilitar el enrutamiento dividido.

¿Hay alguna forma de anular esta configuración o hacer algo en mi estación de trabajo para que el tráfico de red que no es del cliente evite la VPN? Esto no sería un gran problema, pero ninguna de mis estaciones de transmisión de radio (por ejemplo, XM) funcionará conectada a su VPN.

Disculpas por cualquier imprecisión en la terminología.

** editar **

El cliente Juniper cambia el archivo resolve.conf de mi sistema de:

nameserver 192.168.0.1

a:

search XXX.com [redacted]
nameserver 10.30.16.140
nameserver 10.30.8.140

He intentado restaurar mi entrada DNS preferida en el archivo

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

pero esto da como resultado el siguiente error:

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

¿Cómo la cuenta de superusuario no tiene acceso a este archivo? ¿Hay alguna manera de evitar que el cliente Juniper realice cambios en este archivo?

Sobre el problema de permisos Marcus es correcto en su respuesta, pero hay una manera más simple de agregar archivos que requieren privilegios de superusuario:

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

El comando tee dividirá la salida (como una unión en T) tanto en un archivo como en stdout. -a se asegurará de que se anexe al archivo en lugar de sobrescribirlo por completo (lo que probablemente no desee al manipular archivos del sistema como resolve.conf o hosts). sudo se asegurará de que tee se ejecute con acceso de superusuario para que pueda cambiar el archivo.

Creo que el problema es lo que se ejecuta como root en esta línea:

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

Solo el comando "echo" se ejecuta como root y la salida de escritura del archivo se realiza con su usuario habitual, que probablemente no tiene acceso a /etc/resolv.conf.

Intenta ejecutarlo de esta manera:

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

Como ya le han explicado, el problema es que la política se aplica del lado del cliente pero se configura del lado del servidor. Esta es una característica de seguridad, que permite que la red de conexión evite que los clientes "conecten" redes no seguras y seguras juntas.

La única forma es "piratear" al cliente para que no obedezca el comando del lado del servidor.

Hay un tutorial que puede encontrar en la web ( http://www.digitalinternals.com/network/workaround-juniper-junos-pulse-split-tunneling-restriction/447/ ) que está basado en Windows, pero en realidad requiere herramientas tales como IDA Pro y habilidades de lenguaje ensamblador para parchear el binario Pulse. Esto también puede considerarse ilegal en varios países.

Básicamente, aunque la experiencia del usuario puede verse afectada al obligar a su cliente a enrutar completamente a través de la red de destino, esto permite a los administradores de red mantener su red más segura, y simplemente no debe hacerlo.

Espero que esto ayude.

Creo que la política se ve obligada a abandonar el servidor. A menos que de alguna manera piratee el software de cliente Juniper vpn, tendrá que usar el enrutamiento dictado.

Es parte del conjunto de características del software VPN que puede aplicar políticas de seguridad en los clientes.

La única forma de evitar esto es no conectarse. Esta es una característica de seguridad integrada en el dispositivo de back-end juniper. El cliente de enebro que se inicia simplemente aplica la política configurada por los administradores de enebro / red que trabajan para su empresa cliente. Es muy fácil configurar el dispositivo juniper para permitir el túnel dividido. Si no está configurado, es un descuido o una elección. Pídales que lo habiliten. Si no pueden o no quieren, entonces es su política de seguridad. Advertencia justa: piratear o explotar una forma de eludir esa política infringe su código de conducta con su cliente (suponiendo que tengan políticas de uso en línea) y en muchos casos puede considerarse criminal. También puede destruir cualquier seguridad que intentaron construir en su red de usuarios remotos ... Te has convertido en un vector para ellos.

Sé que es muy lento para navegar de esta manera, la transmisión de video es particularmente divertida, ¡sin mencionar que cada paso se registra en el dispositivo enebro! Realmente también perjudica el ancho de banda de los clientes, ya que le quita un mordisco a los recursos varias veces, simplemente al enrutar el tráfico hacia adentro y hacia afuera de su red.

Inicie el cliente vpn desde una máquina virtual ... voilà. Obviamente necesita trabajar desde la máquina virtual.

Espero entender tu pregunta, eres un VPN en un cliente pero no puedes acceder a tu XM u otros sitios. Esto puede deberse a un filtro web en su extremo. Sugeriría, si hay una opción para ello, habilitar el acceso LAN local en su cliente VPN. Esto puede resolver su problema.

Estoy usando el cliente Juniper NC en un cliente Linux de Fedora y puedo crear rutas estáticas a servicios específicos o segmentos de red. Por ejemplo, la red a la que me estoy conectando no permite IMAP saliente, así que hago una ruta estática a mi cuenta de correo. Necesita acceso root, por supuesto. También intenté eliminar la ruta predeterminada que crea NC, pero tiene un demonio que la vuelve a agregar en cuestión de segundos.