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

Question

[DreamingKitten]

Ситуация: есть VPS с белым IP и есть некий студенческий проект, живущий глубоко в кампусной сети аж под двумя NATами, т.е. снаружи никак не доступный.

Задача: возможность доступа к проекту снаружи из Интернет (из дому, например).
Общая стратегия решения: докупить ещё 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 и на другом конце туннеля. Но там его нет.
Что-то я забыл, пропустил или не так понял... Вот только что?

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

Comments

[АртемЪ]

DreamingKitten, Что-то странное написано, вообще логики не увидел.
Вроде заявляете что задача обеспечить доступ к проекту находящемуся на сервере за NAT через тоннель до VPS с белым адресом. Ну поднять VPN сервер на VPS, и настроить проброс нужных портов.

[DreamingKitten]

Вроде все просто.

вроде и просто, но не работает.
АртемЪ, я хочу заходить на сервер проекта напрямую, минуя промежуточный логин на VPS. И при этом обойтись без NAT, поэтому и белые адреса задействованы.

[АртемЪ]

DreamingKitten, А, так вы белый адрес серверу хотите выдать через тоннель?

[DreamingKitten]

АртемЪ, именно так

Answer 1

[iddqda]

Вопрос понял, а вот ваше решение осознать не осилил
я бы вообще не стал делать 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 динамикой
   

Answer 2

[DreamingKitten]

Да, красиво вышло. То есть всё-таки оказалось можно поднять всю эту конструкцию на L3, а не L2.
Пришлось немного подшаманить ваш метод и он таки заработал. Оказывается, статический proxyARP поднимается вполне себе штатными средствами OS, кот бы мог подумать.
Во-первых, создавать dummy-интерфейсы не понадобилось -- я навесил оба белых IP на оба конца tun0/tun0.
Во-вторых, статический маршрут на сервере B OpenVPN прописывает сам, если указать в его настройках топологию p2p
В-третьих, скорее всего, придётся использовать redirect-gateway на клиентской стороне без def1, т.к. там ещё интерфейс с локалочным адресом, у которого смена дефолтного шлюза вызывает недопонимание. Буду экспериментировать.
Спасибо большое!