4

Я пытаюсь направить трафик, предназначенный для общедоступного Интернета, через сеть OpenVPN, где трафик будет выходить из VPN через другого клиента в сети (например, виртуальной машины VirtualBox).

Чтобы объяснить топологию, я буду использовать клиента A в качестве источника трафика и клиента E в качестве желаемой точки выхода / предполагаемой исходной точки трафика. И клиенты, и сервер являются машинами Linux.

Клиенты A и E оба подключены к серверу OpenVPN и имеют локальные адреса в подсети, созданной сервером; скажем, 10.8.0.0/16, где сервер имеет 10.8.0.1, а клиенты A, E, имеют ... 2 и ... 3. Клиенты могут связаться друг с другом через сервер. Сервер OpenVPN также имеет GRE-туннель к клиенту E, который работает поверх соединения OpenVPN.

В настоящее время абстрактная топология / поток выглядит следующим образом:

(A) ={OpenVPN}=> (OpenVPN Server) ={GRE in OpenVPN}=> (E) -> ...

У меня проблема в том, что как только трафик достигает клиента E, он не отправляется через шлюз E по умолчанию и в общедоступный Интернет.

Соответствующая конфигурация клиентов выглядит следующим образом:

A:

default gateway is the OpenVPN server (10.8.0.1)  

Сервер OpenVPN:

ip rule add from 10.8.0.2 lookup node  

Таблица маршрутизации 'узел' имеет маршруты:

default dev gre5  scope link  
10.8.0.0/16 dev tun0  proto static  scope link  src 10.8.0.1  

E:

default gateway is the VirtualBox nat network (through which it has a working Internet connection)

net.ipv4.ip_forward = 1  
net.ipv4.conf.all.forwarding = 1  
net.ipv4.conf.default.forwarding = 1  
iptables -t nat -A POSTROUTING -s 10.8.0.0/16 -o eth0 -j MASQUERADE

The iptables policy for E's filter table is to accept everything.

Используя tcpdump, я могу видеть пакеты от A, выходящие из туннельного интерфейса GRE GRE, но они, кажется, падают на E. Я смог убедиться, что они не перенаправляются через интерфейсы E (loopback, виртуальные туннели или сетевой интерфейс VBox nat; eth0 выше).

Я пропускаю какую-то дополнительную / специальную конфигурацию для туннеля GRE, или что-то связанное с этим? Связана ли эта проблема с тем, что клиент конечной точки является виртуальной машиной?
Опционально, есть ли лучший способ направлять трафик, предназначенный для внешних сетей, через сеть OpenVPN и вне клиента?

Я рад предоставить дополнительную информацию, если это необходимо.

Таблица маршрутизации E, запрошенная @MariusMatutiae

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use     Iface
default         10.0.2.2        0.0.0.0         UG    0      0        0 eth0
10.0.2.0        *               255.255.255.0   U     0      0        0 eth0
10.8.0.0        *               255.255.0.0     U     0      0        0 tun0
10.10.5.0       *               255.255.255.0   U     0      0        0 gre5
192.168.56.0    *               255.255.255.0   U     0      0        0 eth1

Когда eth0 подключен к сети VBox nat, eth1 подключен к сети только для хоста, которую я использую для подключения ssh к виртуальной машине, tun0 - это интерфейс OpenVPN, а gre5 - интерфейс к туннелю GRE.

0