Комментарии 12
Это из разряда "ненормальное программирование". Офигенно, мне нравится. А если ассиметричный канал сделать, чтобы ответ от ВМ отправлялся сразу клиенту? ВМ сеть поднятая с macvtap, пакет не инкапсулируется в тунель хоста и с сетевой карты уходит на маршрутизатор, который отправляет пакет клиенту согласно таблице маршрутизации (без ната и других обработчиков). Возможно провайдер заблокирует за спуфинг адресов?
Возможно надо будет адрес с петли перевесить на eth0.
Почему бы для проброса лишь одного порта не использовать ngrok? В таком случае отдельная VM с публичным адресом вовсе не понадобилась бы, а проброс осуществился бы в одно действие (не считая настройки ингресса).
Плюс за жесть. )
А вообще идея - на сеньор девопса давать такую задачу на собеседовании )
Это, конечно, очень интересно, но почему не банальный reverse proxy на nginx, поднятый на vps?
Есть ощущение, что решение вот прямо сильно прибито гвоздями к методу выдачи внешнего ip у данного, конкретного хостера.
Или вообще где-то под капотом включается dnat.
Не совсем понятно каким образом шлюз провайдера/хостера "согласился" идти за внешним адресом внутрь туннеля, который совсем не L2, а обычный L3.
Ну или я что не понимаю.
Чтобы перенести адрес его нужно убирать с интерфейса, иначе маршрутизация в туннель не заработает. farpd - ключевой элемент схемы, позволяет говорить, что ip адрес никуда не делся, а когда пакет приходит в vps, он обрабатывается правилами маршрутизации.
Более подробно. farpd -d -i eth0 89.108.76.161 отвечает на arp запросы гипервизора провайдера и говорит, что 89.108.76.161 находится на таком-то мак адресе. Гипервизор направляет фреймы с адреcом назначения 89.108.76.161 на это мак, т.е. в мою VPS. Далее линукс отбрасывает L2 часть, а L3 просто маршрутизирует через туннель. Дальше пакеты маршрутизируются уже на ноуте до финального контейнера, в котором и есть 89.108.76.161.
Если провайдер использует что-то типа обычного kvm, то у него есть бридж в который подключены veth от виртуальных маших. И поиск нужного ip адреса в подсети бриджа осуществляется через arp. Я вначале проверял аналогичную схему на виртуалке внутри гипервизора kvm на своем ноуте, все работало.
Если провайдер использует openstack, то там все по другому (в виртуалке нет этого адреса на интерфейсе, он находится у провайдера, который делает DNAT на непубличный адрес на интерфейсе виртуалки), и скорее нужно отвязывать этот непубличный адрес.
Reg.ru я выбрал, потому что там можно взять виртуалку с почасовой оплатой и добавить еще один ip адрес. Так получилось, что у этого провайдера схема заработала. Скрытых DNATов не использовал. Всегда можно проверить, виртуалка там стоит меньше руб. в час.
Сюда бы еще схему для наглядности, было бы вообще супер.
Постараюсь нарисовать, если время будет..
Запускаем Kubernetes Ingress-контроллер c публичным ip на домашнем ноутбуке