Arch Linux VPN + L2TP: соединение установлено, интернет работает, но нет доступа к внутренней сети

Question 1

Я хочу направить трафик на aaa,bbb,ccc через VPN. Как это сделать?

Я предполагаю, что это локальные адреса (как вы утверждаете в заголовке), например 192.168.0.2. Пакеты на этот адрес не проходят через туннельный интерфейс, потому что у вас есть более конкретный маршрут, чем маршрут по умолчанию, указывающий на wlp2s0:

192.168.0.1     0.0.0.0         255.255.255.255 UH    600    0        0 wlp2s0

При статической маршрутизации более конкретные маршруты всегда «выигрывают». Чтобы решить эту проблему, можно сделать следующее:

Удалить текущий маршрут с помощьюip route delete 192.168.0.1
Добавьте новый маршрут к этому префиксу (который адресует хосты aaa,bbb,cc) с интерфейсом ( dev), указывающим на интерфейс туннеля. Например: ip route add 192.168.0.1/24 via $IP_OF_TUNNELGATEWAY dev ppp0

Answer

Я хочу направить трафик на aaa,bbb,ccc через VPN. Как это сделать?

Я предполагаю, что это локальные адреса (как вы утверждаете в заголовке), например 192.168.0.2. Пакеты на этот адрес не проходят через туннельный интерфейс, потому что у вас есть более конкретный маршрут, чем маршрут по умолчанию, указывающий на wlp2s0:

192.168.0.1     0.0.0.0         255.255.255.255 UH    600    0        0 wlp2s0

При статической маршрутизации более конкретные маршруты всегда «выигрывают». Чтобы решить эту проблему, можно сделать следующее:

Удалить текущий маршрут с помощьюip route delete 192.168.0.1
Добавьте новый маршрут к этому префиксу (который адресует хосты aaa,bbb,cc) с интерфейсом ( dev), указывающим на интерфейс туннеля. Например: ip route add 192.168.0.1/24 via $IP_OF_TUNNELGATEWAY dev ppp0

Question 2

Наконец, я решил свою проблему. Это долгая история. Основная причина — неправильная конфигурация DNS, в результате которой внутренние (за VPN-сервером) адреса не могли быть правильно разрешены. Предположение, почему это произошло, следующее. Каждый раз, когда я подключаюсь к VPN, происходит следующая цепочка событий:

-> сетевой менеджер

->strongswanппп0

-> 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 state UNKNOWN group default qlen 3 link/ppp inet 172.16.203.173 peer 192.0.2.1/32 scope global ppp0 valid_lft forever preferred_lft forever

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

DNS-адреса были взяты из конфигурации VPN-подключения (см. скриншот выше).

Новый маршрут default via ppp0 metric 500был добавлен в таблицу маршрутизации. Его приоритет меньше приоритета по умолчанию enp3s0, 0.0.0.0 192.168.0.1 0.0.0.0 UG 100 0 0 enp3s0в результате чего трафик не проходит через ppp0.первая проблема
/etc/resolv.conf, содержащий dns1 и dns2, в какой-то момент времени переопределяется сетевым менеджером на DNS-серверы Google по умолчанию 8.8.8.8 и 8.8.4.4.второй выпуск

Чтобы исправить вторую проблему, я установилdnsmasqкоторый служит прокси и обрабатывает dns самостоятельно. Мне пришлось удалить, pacman -R openresolv netctlкоторый изменился /etc/resolv.confи не содержит единственный адрес dnsmasq:

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

чтобы указать сетевому менеджеру использовать dnsmarq, я также добавил эту строку в /etc/NetworkManager/conf.d/dns.conf:

[main]
dns=dnsmasq

Чтобы исправить первую проблему в NetworkManager, я добавил более конкретный маршрут, имеющий более высокий приоритет, чем маршрут enp3s0 по умолчанию:

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

Вот и все. Весь трафик к внутренним ресурсам идет через VPN, остальной трафик идет как и прежде.

Также я запретил любую перезапись /etc/resolve.conf

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

chattr -i /etc/resolv.conf ((для снятия защиты, режим по умолчанию)) - для отката

Надеюсь, это будет кому-то полезно.

Answer