Почему после настройки VPN-соединения в Linux добавляется конкретное правило маршрутизации?

После настройки VPN-соединения по умолчанию добавляется следующее правило маршрутизации:

vpn_server_ip previous_default_gateway

Мне это правило кажется бесполезным. Почему добавлено?

Примечание:

VPN-соединение - это не соединение, которое используется для подключения к Интернету.
vpn_server_ip не принадлежит к виртуальной сети.

Пример:

В примере я буду использовать нотацию «$ route -n». Перед установкой VPN-соединения у меня было

0.0.0.0 192.168.0.1

После этого таблица маршрутизации выглядит следующим образом:

193.196.65.76 192.168.0.1
0.0.0.0 192.168.0.1
147.38.45.1 0.0.0.0 iface ppp0

Так что я могу понять почему

147.38.45.1 0.0.0.0 iface ppp0

добавлен. 147.38.45.1 IP-адрес сервера в VPN. Но я не понимаю почему

193.196.65.76 192.168.0.1

добавлен, 193.196.65.76 - IP сервера дозвона. Может быть, это всего лишь мера предосторожности на случай, если IP dialin-сервера находится в сети VPN ?!

vpn route

При объяснении этого важно имя интерфейса. Я создам пример и объясню здесь.

Это таблица маршрутизации перед подключением к VPN. У нас есть основной интерфейс в сети 10.0.2.0/24, IP-адрес 10.0.2.15, маршрут по умолчанию -> 10.0.2.2. Все происходит на eth1.

k@workstation:~$ ip r
10.0.2.0/24 dev eth1  proto kernel  scope link  src 10.0.2.15  metric 1 
default via 10.0.2.2 dev eth1  proto static

Это таблица маршрутизации после подключения к VPN. Первая добавленная запись соответствует вашему вопросу; Конечная точка VPN через наш бывший первичный шлюз через eth1. Он также добавляет локальную сеть для нового IP-адреса, который я только что получил. А затем он меняет шлюз по умолчанию на VPN.

k@workstation:~$ ip r
123.123.123.123 via 10.0.2.2 dev eth1  proto static 
10.8.0.21 dev tun0  proto kernel  scope link  src 10.8.0.22 
10.8.0.1 via 10.8.0.21 dev tun0  proto static 
10.0.2.0/24 dev eth1  proto kernel  scope link  src 10.0.2.15  metric 1 
default via 10.8.0.21 dev tun0  proto static

Маршрут гарантирует, что трафик к конечной точке VPN проходит через физический сетевой интерфейс, и не пытается направить его через VPN - это было бы невозможно, поскольку этот трафик туннелируется через физическую сеть.

Даже если основной шлюз не изменен - программное обеспечение VPN часто делает это на случай, если конечная точка VPN находится в той же подсети, что и ваш новый IP-адрес. Вот почему вы не можете разговаривать с конечной точкой VPN на том же IP-адресе и ожидать «локального подключения» после того, как соединение будет установлено.

(Пример сделан с использованием OpenVPN)