Недавно меня попросили разобраться в настройке L2 туннеля для моста между двумя удалёнными локальными сетями, и я был поражён, насколько мало удобных решений мне удалось найти. Раньше я не интересовался этой темой и наивно полагал, что любой адекватный VPN-протокол умеет ловить широковещательные пакеты и пересылать их по обычному L3 туннелю. К сожалению, доступных «из коробки» универсальных решений нет. Есть несколько протоколов и инструментов для них, большинство из которых работает в очень ограниченных условиях или вовсе объявлено deprecated. Самым приятным вариантом я поделюсь дальше.
Почему именно L2?
Этим вопросом я задался в первую очередь: я довольно редко работаю с сетевой периферией, и мне казалось что довольно давно уже всё оборудование умеет ходить по L3. Как бы не так: кому-то нужен доступ к офисным принтерам, кому-то к видеорегистраторам, а кто-то просто хочет зарубиться с другом в LAN-дуэли — не выходя из дома, разумеется. Также очень привлекательной выглядит идея общих/сетевых папок в офисе, доступных из дома, особенно в период повальной удалёнки.
При этом среди разработчиков VPN-клиентов L2-бриджи почему-то считаются чем-то вроде странного каприза одного-двух процентов пользователей, который по большому счёту никому не нужен. Совсем иначе обстоят дела в промышленных сетях, где много устаревшего или плохо совместимого оборудования, и концепция L2VPN (представленная кучей других аббревиатур) реализована на уровне сети и оборудования провайдера.
Технологии
Их много, и они все работают со странностями и ограничениями:
- Например, протокол Layer 2 Tunneling Protocol (L2TP) должен, судя по названию, обеспечивать поддержку OSI L2 и в том числе проброс broadcast'a. Но нет, общепринятая связка L2TP + IPsec не позволяет бриджевать сети на уровне L2!
- PPTP — стал мемом из-за крупных уязвимостей, сейчас кое-как починен, но к L2 уже не имеет отношения.
- MPLS — жутко запутанный «промышленный» протокол на основе меток. Изучить его сложно, а поднять можно только на специализированном железе или RouterOS (с ограничениями, куда ж без них).
- PPPoE и феерический PPPoEoE тоже работают, но на проприетарных железках. Режим PPPoE вообще есть на многих роутерах, но как его правильно готовить известно по большей части только на фирменном оборудовании типа Cisco.
- EoIP должен быть стать тем самым L2VPN made right, но он тоже работает только на микротиках, что существенно сужает круг применения. Как и PPTP, используя GRE, не проходит через NAT.
И тут я с удивлением обнаружил, что настоящий Ethernet Bridging умеет… OpenVPN!
Мы часто пользуемся личным или рабочим VPNом, у многих он вообще включён на постоянной основе для обхода блокировок (хотя эта тенденция идёт на спад после снятия блокировки Telegram). В своих рабочих задачах я тоже постоянно пользуюсь удаленными хостами для разработки, и почти всегда использую OpenVPN. Долгое время я не понимал, зачем нужна связка OpenVPN Access Server + OpenVPN Connect на клиенте. Для моих задач мне всегда хватало классической версии с ручной правкой конфигов, и выделенные админки и GUI казались неуместными в стройном тонком клиенте. Но оказалось, что для настройки бриджа интерфейс гораздо удобнее чем простыни конфигов в терминале, хотя и с ним не всё идеально.
Настройка
Дело в том, что Access Server (AS) выходил как платный и довольно дорогой продукт, поэтому в него старательно напихали всевозможных плюшек, лишь бы купили. Таким образом в веб-админке появился подпункт меню, позволяющий выбрать режим сети (L2 bridging/L3 routing), а через какое-то время тихонько был оттуда выпилен по всё той же причине «это никому не нужно». Тем не менее, сам функционал бриджинга и соответствующие скрипты не удаляли и их по-прежнему можно настроить.
Установка
Нам потребуется сервер или виртуальная машина. Образ для неё находится на странице загрузки, а мы будем дальше разбирать кейс с установкой на сервер под Ubuntu 18.04:
apt update && apt -y install ca-certificates wget net-tools gnupg
wget -qO - https://as-repository.openvpn.net/as-repo-public.gpg | apt-key add -
echo "deb http://as-repository.openvpn.net/as/debian bionic main">/etc/apt/sources.list.d/openvpn-as-repo.list
apt update && apt -y install openvpn-as
После установки сервер поднимется самостоятельно, вы увидите такое сообщение:
+++++++++++++++++++++++++++++++++++++++++++++++
Access Server 2.8.4 has been successfully installed in /usr/local/openvpn_as
Configuration log file has been written to /usr/local/openvpn_as/init.log
Access Server Web UIs are available here:
Admin UI: https://185.209.31.165:943/admin
Client UI: https://185.209.31.165:943/
+++++++++++++++++++++++++++++++++++++++++++++++
Сразу нужно указать пароль для админской учётки:
passwd openvpn
Затем можно открывать админку в браузере (на :943/admin, как указано выше), логиниться под пользователем openvpn с указанным паролем и настраивать сервер.
AS бесплатна для использования двумя пользователями, дальше можно добавлять только за $18/месяц за одного пользователя, так что лучше сразу спроектировать свои процессы под использование туннеля двумя клиентами.
Возвращаем бриджинг
cd /usr/local/openvpn_as/scripts
./sacli --key "von.general.osi_layer" --value "2" ConfigPut
./sacli start
Если всё прошло успешно, в выведенном json'е будет такое:
{
"errors": {},
"last_restarted": "Thu Jul 2 00:07:37 2020",
"service_status": {
"api": "on",
"auth": "on",
"bridge": "on",
...
}
}
В админке статус «OSI Layer: 3 (routing/NAT)» поменяется на «2 (bridging)»
NB: в последних версиях может оставаться информация о L3 при включённом bridge. Почему — не разбирался, безопасные в этом плане версии около 2.4
Собственно на этом ноу-хау заканчивается, дальше вам нужно просто настроить под себя сервер, завести второго пользователя через тот же веб-интерфейс и залогиниться на пользовательскую страницу на 943 порту (без /admin). Там будут ссылки на скачивание клиентов OpenVPN Connect под все платформы с запечённым конфигом для подключения (кроме мобильных приложений, там придется вбить адрес вручную, а дальше всё само установится).
После успешного подключения и бриджевания клиентов, будет доступен L2-туннель с TCP/UDP трафиком. Клиенты могут выступать натом для внутренней сети, это всё тоже настраивается в админке.
Yuri_M
«насколько мало удобных решений мне удалось найти»
Конкретно для задачи соединения сетей — лучше, чем Softether, вряд ли что-то еще есть.
PeterZha
И причем SoftEther по производительности кроет OpenVPN как бык овцу. По одному и тому же каналу 25Mbps/5Mbps в пользу SoftEther. И нет геморроя с MTU.