Цель: маршрутизировать весь интернет-трафик от eth0 -> tun0 -> tun1 для VPN с двойным переходом. Подходит ли следующая таблица маршрутизации для этой цели?
$ ip route show:
0.0.0.0/1 via 10.8.1.1 dev tun1
default via 10.8.3.1 dev tun0 proto static metric 50
10.8.1.0/24 dev tun1 proto kernel scope link src 10.8.1.6
10.8.3.0/24 dev tun0 proto kernel scope link src 10.8.3.4 metric 50
101.133.213.73 via 10.8.3.1 dev tun0
127.0.0.0/8 dev lo scope link
128.0.0.0/1 via 10.8.1.1 dev tun1
191.72.65.45 via 182.160.0.1 dev eth0 proto static metric 100
182.160.0.0/24 dev eth0 proto kernel scope link src 182.160.0.19 metric 100
182.160.0.0/24 dev eth0 proto dhcp scope link src 182.160.0.19 metric 208
182.160.0.1 dev eth0 proto static scope link metric 100
Предполагая, что желаемая последовательность - трафик из вашей локальной сети должен идти с локального компьютера -> tun0 -> tun1, это, вероятно, то, что происходит, однако это происходит способом, который не виден на tracreroute.
Давайте возьмем пакет, предназначенный для произвольного интернет-адреса - в этом примере я буду использовать 8.8.8.8.
Компьютер принимает пакет и ищет, как его отправить. Он видит, что он должен быть отправлен через tun1 (потому что 2 маршрута ниже эквивалентны маршруту по умолчанию, но более ограничены, поэтому предпочтительнее по сравнению с маршрутом по умолчанию - в этом случае используется первый маршрут) -
0.0.0.0/1 via 10.8.1.1 dev tun1
128.0.0.0/1 via 10.8.1.1 dev tun1
Но вот часть, которая может быть неочевидной. Если вы посмотрите на конфигурацию tun1, вы обнаружите, что у него есть конечная точка 101.133.213.73. Для этого IP-адреса существует определенный маршрут, который проходит через tun0
101.133.213.73 via 10.8.3.1 dev tun0
Точно есть еще один маршрут
191.72.65.45 via 182.160.0.1 dev eth0 proto static metric 100
Этот маршрут делает трафик, отправленный через tun0, напрямую доступным через интерфейс Ethernet.
Поскольку это очень специфический маршрут, трафик на 101.133.213.73 будет проходить через tun0. Таким образом, весь трафик, идущий в Интернет (через tun1), должен проходить через 101.133.213.73, который сам по себе является туннелем, так что да, данные будут проходить через оба туннеля.
Трассировка не показывает этого, потому что пакет не знает, что он туннелируется через туннель. Тем не менее, вы все равно можете проверить, что это происходит, посмотрев на более низкие уровни - Генерация трафика в другом окне, выполняющая «sudo tcpdump -n -i any». Вы увидите, что всякий раз, когда пакет отправляется в более широкий Интернет, пакет будет отправлен через каждый из eth0, tun0, tun1, и то же самое будет верно для возвращенных пакетов. Все пакеты, связанные с tun0, будут иметь цель 101.133.213.73.
eth0 : 182.160.0.19/24 (GW: 182.160.0.1)
tun0 : 10.8.3.4/24 (GW: 10.8.3.1 / VPN endpoint : 191.72.65.45 via eth0)
tun1 : 10.8.1.6/24 (GW: 10.8.1.1 / VPN endpoint : 101.133.213.73 via tun0)
Таким образом, весь трафик (включая входящий от tun0) будет маршрутизироваться через tun1, за исключением локального трафика в сети Ethernet (182.160.0.0/24) и локального трафика в tun0 / "VPN1" (10.8.3.0/24).
С этой таблицей маршрутизации также весь трафик, исходящий от eth0, будет маршрутизироваться через tun1 который не упоминается / не запрашивается в вопросе ... Подходит ли вам такая ситуация? В случае положительного ответа вы можете оставить эту настройку.
В случае, если это нежелательная ситуация (вы не хотите маршрутизировать трафик с eth0 на tun1 / tun0), у вас есть (по крайней мере) два варианта, как с этим справиться.
Может быть несколько таблиц маршрутизации, и на основе правила / политики вы можете управлять тем, какой трафик будет обрабатывать другая таблица, а не таблица по умолчанию. Таким образом, вы можете установить настраиваемую таблицу маршрутизации, где GW по умолчанию будет tun1, и только трафик, исходящий от tun0, будет указываться на эту настраиваемую таблицу маршрутизации.
Таким образом, вы можете изолировать целые интерфейсы tun от eth0 (с внутренней маршрутизацией между пространствами имен), чтобы вы могли настроить простую (по умолчанию) таблицу маршрутизации в пространстве имен, чтобы только трафик от tun0 мог достигать tun1.