Прозрачный туннель между интерфейсами на удаленных хостах

Question

Мне нужно сделать решение, которое будет работать как сетевой коммутатор с двумя портами: один порт расположен в одной стране, а второй порт находится в другой стране.

              +------------ Virtual switch ----------------+
+---------+   |   +-------+    +----------+    +-------+   |   +--------+
|Client A |<--+-->| BOX 1 |<-->|VPN server|<-->| BOX 2 |<--+-->|Client B|
+---------+   |   +-------+    +----------+    +-------+   |   +--------+
              +--------------------------------------------+

Клиент A и Клиент B чувствуют это как обычный переключатель уровня 2. VPN-соединение между двумя боксами - OpenVPN. Поэтому мне нужно как-то переслать кадры Ethernet через VPN-туннель между двумя блоками. На Box 1 и 2 работает Debian Джесси. Я надеюсь не писать свое собственное программное обеспечение для него :) Кто-нибудь может предложить возможные решения?

PS Необходимо подключить два устройства, предназначенных для работы только в локальной сети.

UPD: я установил 4 виртуальные машины для имитации такой настройки (vpnserver был опущен):
- Все машины являются коробками Debian
- Box 1 и Box 2 имеют GRE-туннель между ними (Ethernet через IP)
- На клиенте Локальный интерфейс, соединенный с интерфейсом gretap: мост имеет адрес 10.0.0.253
- На локальном интерфейсе клиента B, соединенном с интерфейсом gretap: мост имеет адрес 10.0.0.254
- Клиент А имеет статический IP 192.168.1.1.
- Клиент B имеет статический IP 192.168.1.2

От Клиента A я отправляю ICMP-эхо-запрос на 192.168.1.2 и вижу ARP-запрос «Кто имеет 192.168.1.2 расскажите 192.168.1.1» на мосту на Box 1, на мосту на Box 2 и на клиенте B. Но ответ ARP виден только на клиенте B. Таким образом, ответ ARP как-то не возвращается на Box2. И все сети между 10.0.0.253 и 10.0.0.254 работают хорошо. Итак, я полагаю, что проблема вызвана соединением.

UPD2: Теперь я удалил туннелирование GRE и установил обычную сеть между Box 1 и Box 2. Когда я создал мосты, пинг начал работать. Что может вызвать проблемы при выполнении GRE туннеля?

Решение: я наконец все настроил в виртуальных машинах с помощью GRE-TAP. Я использовал туннель GRE-TAP по обычной сети между Box 1 и Box 2. И тогда я соединял туннельный интерфейс с локальным интерфейсом на каждом боксе. Ниже мои шаги:

Коробка 1

ip link add tunnel0 type gretap remote 192.168.0.2 local 192.168.0.1
brctl addbr br0
brctl addif br0 eth2  # eth2 - is a local interface on Box 1
brctl addif br0 tunnel
ip addr add 10.0.0.253 dev tunnel0
ip link set br0 up
ip link set tunnel0 up

Box 2

ip link add tunnel0 type gretap remote 192.168.0.1 local 192.168.0.2
brctl addbr br0
brctl addif br0 eth2  # eth2 - is a local interface on Box 2
brctl addif br0 tunnel
ip addr add 10.0.0.254 dev tunnel0
ip link set br0 up
ip link set tunnel0 up

Спасибо всем!

Answer 1

Я сам не пробовал, но я знаю, что вы можете использовать gretap для туннелирования слоя 2 (ethernet) поверх слоя 3 (ip). Например, в соответствии с этим блоггерингом, вы устанавливаете один интерфейс gretap на каждом конце и соединяете его с вашим интерфейсом Ethernet. Если я все правильно понимаю, в примере 172.31.0.1 должен быть адрес конечной точки VPN на Box 1, а 172.31.0.2 адрес конечной точки VPN на Box 2. 10.10.10.1 - это адрес локальной сети для блока 1, а 10.10.10.2 - адрес локальной сети для блока 2.

Вставка 1:

ip link add gretap0 type gretap local 172.31.0.1 remote 172.31.0.2
ip link set dev gretap0 up
ip link set dev eth0 up
brctl addbr br0
brctl addif br0 gretap0
brctl addif br0 eth0
ip addr add 10.10.10.1/24 dev br0
ip link set br0 up

Вставка 2:

ip link add gretap0 type gretap local 172.31.0.2 remote 172.31.0.1
ip link set dev gretap0 up
ip link set dev eth0 up
brctl addbr br0
brctl addif br0 gretap0
brctl addif br0 eth0
ip addr add 10.10.10.2/24 dev br0
ip link set br0 up

Вам может понадобиться настроить параметры MTU. Я не могу проверить эту настройку, поэтому вам также может понадобиться настроить другие параметры.

Изменить: Вот статья, которая объясняет проблемы MTU, по-видимому, это немного связано. В вашем случае может быть проще, если вы можете управлять настройками VPN MTU.

Answer 2

Это не очень сложно, потому что все, что вы просите, - это чтобы весь трафик L2 мог проходить из одной сети в другую, что является стандартной функцией мостового соединения OpenVPN . Это означает, что:

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

2. или вы покончили с посредником и напрямую подключили Box1 и Box2, как описано, например, здесь или здесь.

В любом случае вам нужно работать с DHCP и маршрутизацией в обеих локальных сетях, потому что они оба должны принадлежать одному и тому же широковещательному домену. Например, мы можем решить, что используемая нами подсеть - 192.168.0.0/23, с DHCP-сервером в LAN1, выдающим адреса в диапазоне 192.168.0.0/24, а DHCP-сервер в LAN2, выдающим адреса в диапазоне 192.168. 1.0/24.

Тогда вам нужно настроить маршруты. Предположим, что Box1 - это компьютер в LAN1 с адресом 192.168.0.121, а Box2 - это компьютер в LAN2 с IP-адресом 192.168.1.173. Затем на шлюзе LAN1 вам нужно добавить маршрут:

ip route add 192.168.1.0/24 via 192.168.0.121 

в то время как на шлюзе LAN2 вам нужно добавить:

ip route add 192.168.0.0/24 via 192.168.1.173

Это генерирует некоторый объем внутрисайтового трафика L2, который может вас раздражать. У меня есть конфигурация с тремя узлами, подобная этой, и у меня нет проблем с объемом трафика и соединениями со скоростью 100 Мбит / с, но с YMMV. Если вы хотите ограничить объем трафика L2, пересекающего OpenVPN, вы можете использовать ebtables на Box1 и Box2.

Это единственный способ понять, о чем ты просил.