@DreamingKitten

Статические IP через L2 туннель OpenVPN -- чего не хватает и почему не работает?

Ситуация: есть VPS с белым IP и есть некий студенческий проект, живущий глубоко в кампусной сети аж под двумя NATами, т.е. снаружи никак не доступный.
5db2c0eeb85ea385383042.png
Задача: возможность доступа к проекту снаружи из Интернет (из дому, например).
Общая стратегия решения: докупить ещё 2 белых IP адреса для VPS и пробросить хотя бы один из них с помощью OpenVPN на сервер проекта.
Этапы решения:Два белых IP адреса из диаапзона IP1 и IP2 куплены. Они в одной подсети /24, то есть, видимо, VPS просто включили в такой VLAN, где водятся резервные адреса. IP Forwarding на VPS включен.
Поначалу я поднял OpenVPN туннель в режиме dev tun (l3), назначив эти белые адреса на оба его конца. Туннель сам по себе работал, но проблема возникла в том, что в этот VLAN, в котором оба этих адреса сидели, роутер постоянно слал ARP who-has на оба адреса (и другие) и ответить на такие запросы, естественно, мог только тот конец туннеля, который был на самой VPS. Второй не мог, поскольку ARP по L3 туннелям не ходит, и без этого роутер не знал MAC и не мог посылать ему IP пакеты.
Ладно... Поднимаю туннель в режиме dev tap (L2). Вот серверный конфиг
proto           tcp4-server
bind            XXX.9.71.223
cipher          AES-256-CBC
dev             tap
secret          /etc/openvpn/static.key

Вот клиентский
proto           tcp4-client
remote          XXX.9.71.223
cipher          AES-256-CBC
dev             tap
secret          /etc/openvpn/static.key

Всё минималистично. Проверяю туннель -- работает. Ну то есть, начинает бросаться IPv6 NDP и ещё чем-то с обоих концов. Далее -- на VPS делаю бридж из eth0 и tap0, переношу все настройки с eth0 на br0 чтобы всё работало как раньше. Поднимаю tap0 на стороне VPS -- и на tap0 с другой стороны туннеля начинает идти много ARP запросов, в том числе и на IP1 и IP2. Хорошо! Значит, надо проверить, возвращаются ли ответы. Вешаю tcpdump на оба конца туннеля и настраиваю тот его конец, что на стороне проекта, на адрес IP1. Вижу в дампах, что ARP-ответы пошли. Роутер по прежнему не отправляет IP-пакеты на адрес IP1 в этот влан. То есть как -- я делаю пинг снаружи на этот адрес, зная что ответа не будет (потому что на сервере проекта выход в инет через два NATа с другим совсем адресом) но эхо-запрос, по логике вещей я должен видеть и на VPS и на другом конце туннеля. Но там его нет.
Что-то я забыл, пропустил или не так понял... Вот только что?

Прошу прощения за не очень понятную формулировку задачи, но -- да, я хочу пробросить белый адрес через туннель чтобы выдать его серверу проекта.
  • Вопрос задан
  • 197 просмотров
Решения вопроса 1
@iddqda
network engineer, netdevops
Вопрос понял, а вот ваше решение осознать не осилил
я бы вообще не стал делать tap и прочие br0

все можно просто промаршрутизировать
по такой схеме:
A --link1--> B --link2-> С

  • A - это шлюз провайдера
  • B - VPS
  • С - ваш сервер с проектом
  • link1 это тот VLAN куда вам адреса сгрузили
  • link2 - тунель openvpn


все решается простой маршрутизацией
на своем сервере C вешаете IP1 на интерфейс lo1
sudo ip link add name lo1 type dummy
поднимаете туннель openvpn (B сервер, C клиент и не забыть push "redirect-gateway def1" в конфиге)
на хосте B указываете статический маршрут на IP1 в туннель

Дальше спросить того кто выдал IP1 адрес как он смашрутизирован на A.
если как хостовый маршрут где next-hop указывает на хост B то все уже должно работать.
если его просто для вас зарезервировали в VLAN (link1) без отдельного маршрута, то тут два пути
  1. proxy-arp т.е. интерфейс B должен отвечать на arp для хоста IP1 своим mac-ом
  2. анонсировать IP1 динамикой
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@DreamingKitten Автор вопроса
Да, красиво вышло. То есть всё-таки оказалось можно поднять всю эту конструкцию на L3, а не L2.
Пришлось немного подшаманить ваш метод и он таки заработал. Оказывается, статический proxyARP поднимается вполне себе штатными средствами OS, кот бы мог подумать.
Во-первых, создавать dummy-интерфейсы не понадобилось -- я навесил оба белых IP на оба конца tun0/tun0.
Во-вторых, статический маршрут на сервере B OpenVPN прописывает сам, если указать в его настройках топологию p2p
В-третьих, скорее всего, придётся использовать redirect-gateway на клиентской стороне без def1, т.к. там ещё интерфейс с локалочным адресом, у которого смена дефолтного шлюза вызывает недопонимание. Буду экспериментировать.
Спасибо большое!
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы