Arch Linux VPN + L2TP: la conexión establecida a Internet funciona pero no hay acceso a la red interna

Question 1

Quiero dirigir el tráfico a aaa,bbb,ccc a través de la VPN, ¿cómo lo hago?

Supongo que se trata de direcciones locales (como afirma en el título), por ejemplo 192.168.0.2. Los paquetes a esa dirección no pasan por la interfaz del túnel porque tiene una ruta más específica que la ruta predeterminada que apunta a wlp2s0:

192.168.0.1     0.0.0.0         255.255.255.255 UH    600    0        0 wlp2s0

Con el enrutamiento estático, las rutas más específicas siempre "ganan". Para solucionar esto puedes hacer lo siguiente:

Eliminar la ruta actual usandoip route delete 192.168.0.1
Agregue una nueva ruta a ese prefijo (que direcciona los hosts aaa,bbb,cc) con la interfaz ( dev) apuntando a la interfaz del túnel. Por ejemplo: ip route add 192.168.0.1/24 via $IP_OF_TUNNELGATEWAY dev ppp0

Answer

Quiero dirigir el tráfico a aaa,bbb,ccc a través de la VPN, ¿cómo lo hago?

Supongo que se trata de direcciones locales (como afirma en el título), por ejemplo 192.168.0.2. Los paquetes a esa dirección no pasan por la interfaz del túnel porque tiene una ruta más específica que la ruta predeterminada que apunta a wlp2s0:

192.168.0.1     0.0.0.0         255.255.255.255 UH    600    0        0 wlp2s0

Con el enrutamiento estático, las rutas más específicas siempre "ganan". Para solucionar esto puedes hacer lo siguiente:

Eliminar la ruta actual usandoip route delete 192.168.0.1
Agregue una nueva ruta a ese prefijo (que direcciona los hosts aaa,bbb,cc) con la interfaz ( dev) apuntando a la interfaz del túnel. Por ejemplo: ip route add 192.168.0.1/24 via $IP_OF_TUNNELGATEWAY dev ppp0

Question 2

Finalmente, resolví mi problema. Es una larga historia. La causa principal es la configuración DNS incorrecta como resultado de que las direcciones internas (detrás del servidor VPN) no se pudieron resolver correctamente. Una suposición de por qué sucedió es la siguiente. Cada vez que me conecto a una VPN ocurre la siguiente cadena de eventos:

-> administrador de red

->cisne fuerteppp0

-> dhclient ppp0 (172.16.203.173, 192.0.2.1, dns1=xyz11, dns2=xyz12) -> resolvconf

ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel estado DESCONOCIDO grupo predeterminado qlen 3 enlace/ppp inet 172.16.203.173 peer 192.0.2.1/32 alcance global ppp0 valid_lft para siempre preferido_lft para siempre

-> dns1=xyz11, dns2=xyz12 a /etc/resolv.conf

Las direcciones DNS se tomaron de la configuración de la conexión VPN (ver captura de pantalla arriba).

default via ppp0 metric 500Se agregó una nueva ruta a la tabla de enrutamiento. Su prioridad es menor que la prioridad predeterminada enp3s0, 0.0.0.0 192.168.0.1 0.0.0.0 UG 100 0 0 enp3s0como resultado, no hay flujo de tráfico a través del ppp0.primer problema
/etc/resolv.conf que contiene dns1 y dns2 es anulado por el administrador de red en algún momento con los dns predeterminados de Google 8.8.8.8 y 8.8.4.4.Segundo problema

Para solucionar el segundo problema que instalédnsmasqque sirve como proxy y maneja dns por sí mismo. Tuve que desinstalar pacman -R openresolv netctlel cual cambió /etc/resolv.confy no contiene la única dirección de dnsmasq:

# Generated by NetworkManager
search internal.mycompany.com
nameserver 127.0.0.1
options edns0 trust-ad

Para decir que el administrador de red usa dnsmarq, también agregué esta línea en /etc/NetworkManager/conf.d/dns.conf:

[main]
dns=dnsmasq

Para solucionar el primer problema en NetworkManager, agregué una ruta más específica que tiene mayor prioridad que la ruta predeterminada enp3s0:

10.Y.X.Z    192.0.2.1       255.255.255.255 UGH   500    0        0 ppp0

Eso es todo. todo el tráfico hacia los recursos internos fluye a través de la VPN, el resto del tráfico fluye como antes.

Además, negué cualquier sobrescritura de /etc/resolve.conf

chattr +i /etc/resolv.conf ((to protect the file from write))

chattr -i /etc/resolv.conf ((para desproteger, modo predeterminado)) - para retroceder

Espero que sea útil para alguien.

Answer