Преобразование одного интерфейса в туннельный интерфейс
У меня есть сервер с 2-мя WAN-интерфейсами, eth1 и eth2. К каждому из них подключен один маршрутизатор, который дает им следующие IP-адреса: 192.168.3.101 и 192.168.1.101.
Дело в том, что я хочу полностью избежать трафика через eth1 и вместо этого создайте tun0 который будет туннелировать весь трафик eth1 должен получить.
У меня есть полный контроль над тем, какой интерфейс должны использовать мои программы (MPTCP будет использовать все интерфейсы, которые могут подключаться к серверу), поэтому я подготовил простую конфигурацию клиент / сервер OpenVPN (привязка к local 192.168.3.101), с IP сервера 192.168.99.1 и клиентский IP 192.168.99.2. Благодаря этому у меня есть рабочий интерфейс, в котором я могу отправлять / получать данные на 192.168.99.1 без проблем.
Теперь проблема возникает, когда я хочу отправить / получить данные на ifconfig.co (например) с помощью интерфейса tun0. Я думал, что он будет отправлять данные через eth1 на мой сервер, то мой сервер перенаправляет трафик на ifconfig.co, но это не то, что происходит. Он просто разрывает соединение:
Если я попробую с интерфейсами eth1 и eth2 все работает как положено.
Я читал / пробовал много чего около 7 часов без перерыва, и теперь я действительно потерялся. Я не уверен, что происходит или что делаю не так.
Я думаю, что это проблема маршрутизации, потому что, когда я пытаюсь выполнить команду выше, tcpdump ничего не показывает на сервере. Получено нулевых пакетов. Вот что у меня есть сейчас:
Я вижу все равными друг другу, но eth0/eth1 работают и tun0 не является.
На всякий случай это моя конфигурация OpenVPN (простая конфигурация точка-точка):
;SERVER
dev tun
ifconfig 192.168.99.1 192.168.99.2
secret /etc/openvpn/static.key
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
;CLIENT
dev tun
remote XXXXXXXXXXXX
resolv-retry infinite
local 192.168.3.101
lport 0
ifconfig 192.168.99.2 192.168.99.1
secret /etc/openvpn/static.key
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
ПРИМЕЧАНИЕ. Я знаю, что соглашение для IP-адресов VPN 10.*, но я изменил на 192.168.* как отчаянный шаг к тому, чтобы иметь конфигурацию, аналогичную двум другим интерфейсам.
Причина всего этого в том, чтобы решить эту проблему: https://github.com/Ysurac/openmptcprouter/issues/670#issuecomment-533816813
Вы пытаетесь реализовать решение, основанное на туннельном режиме маршрутизации, но мне кажется, что описание вашей проблемы идеально подходит для режима мостового перехода.
OpenVPN может не только туннелировать IP-пакеты. Он также может туннелировать все пакеты Ethernet. Короче говоря, вы можете заменить «mode tun» на «mode tap» и удалить любые назначения IP-адресов в конфигурации OpenVPN. Также удалите все правила маршрутизации, отличные от правил по умолчанию. Затем с помощью вашей ОС вы создаете мост между eth1 и интерфейсом Tap.
В Debian (/ etc / network / interfaces):
iface eth1 inet manual
auto br0
iface br0 inet manual
bridge_ports eth1
bridge_stp off
bridge_fd 0
Затем нам нужно указать OpenVPN добавить tapX в br0 после его запуска (это идет в конфигурацию OpenVPN):
script-security 2
up up.sh
Зачем нужна безопасность скриптов см. https://community.openvpn.net/openvpn/wiki/OpenVPNBridging
Скрипт up.sh:
#!/bin/sh
bridge=br0
brctl addif "$bridge" "$1"
ip link set "$1" up
Он использует bridge-utils brctl, потому что эта конфигурация была сделана на debian 7. Современные системы должны использовать утилиту ip из современного пакета iproute2 вместо устаревших bridge-utils, iputils и так далее; Я оставлю это как домашнее задание, как добавить интерфейс к мосту с помощью ip, это несложно.
Понимаете, я даже не настраиваю IP-адреса. Это связано с тем, что мой ящик OpenVPN будет просто передавать пакеты Ethernet от физического интерфейса к виртуальному и обратно. В сетевой модели OSI это считается мостом уровня 2, то есть как если бы у вас был коммутатор Ethernet.
Удаленная система («КЛИЕНТ»), на которой запущен OpenVPN, будет иметь свой интерфейс подключения, как если бы он был подключен к тому же коммутатору Ethernet, к которому подключен eth1 «СЕРВЕР»:
(LAN) - [switch] ---ethernet-cable--- [eth1 tapX] ---virtual-ethernet-cable--- [tapY]
"switch" OpenVPN tunnel remote system
Вы можете запустить DHCP-клиент на удаленной системе («КЛИЕНТ»), и он должен получить IP-адрес от DHCP-сервера в локальной сети. Вы также можете использовать мост там, и это будет работать так, как если бы вы подключили свои удаленные сайты с помощью кабеля Ethernet. Думайте об этом, как если бы вы проложили длинную оптическую линию от одного объекта к другому и соединили с ним эти сети.
Если вы хотите, чтобы «СЕРВЕР» также участвовал в этой сети, вы настраиваете IP-адреса на самом br0, для этого вы заменяете «manual» на «static» или даже на «dhcp», это никак не повлияет на его функцию переключения.
Особое внимание следует уделять настройке Linux Netfilter (брандмауэру). Некоторое время назад была переменная sysctl, которая контролирует, проходят ли мостовые пакеты через цепочку «filter FORWARD», net.bridge.bridge-nf-call-iptables = 1. В современных системах, AFAIK, по умолчанию 0. Если он у вас есть, либо установите для него значение 0 (в /etc/sysctl.conf), либо задайте правила, которые передают пакеты между портами коммутатора. См. «Physdev match» в руководстве по iptables.
Обратите внимание, обозначения «СЕРВЕР» и «КЛИЕНТ», которые вы дали своим системам, носят чисто косметический характер и не отражают их роль в протоколе. С точки зрения OpenVPN обе системы равны, потому что вы настроили OpenVPN в «устаревшем» режиме точка-точка. В OpenVPN также есть выделенный режим «клиент-сервер», в котором действительно есть две разные роли, и несколько клиентов могут подключаться к одному серверу OpenVPN. Идея, которую я представил здесь, применима и к этому режиму.
Также обратите внимание, что не существует такого соглашения, чтобы всегда использовать 10. * для OpenVPN. Такой договоренности быть не может ни для одного зрелого промышленного решения VPN. Вы всегда используете сетевую нумерацию, которая требуется для вашего сетевого дизайна.
UPD: при тестировании моста внутри виртуальных машин убедитесь, что гипервизор позволяет использовать несколько MAC-адресов на порту виртуальной машины. В Hyper-V эта функция называется MAC Spoofing и должна быть включена.