Задача всё еще актуальная

Тут нужно понимать для чего это все? это web? что там на 80 ом порту предполагается? и для чего нужен именно белый ip дальше?

Увидел в другой ветке ответ что это не веб и nginx не подходит. Так все-же нужно более подробное тз, возможно у этой задачи есть более простое решение чем вы пытаетесь сделать. Опишите для чего вам там реальный ип и чего хотите получить.

А куда вы ждёте отклик? Лички тут нет, контакт укажите.

Это веб и NGINX не подходит в данном случае. Контакт для связи - https://t.me/reptoxxxxx телега

почему не подходит, в чем заключается проблема? опишите задачу (именно задачу а не вариат её решения который не выходит реализовать) более подробно, возможно кто-то предложит решение.

Необходимо пробросить порт 80 и 443 с сервера №1 на сервер №2, сохраняя при этом адрес источника (реальный IP того кто подключается).

IPIP/GRE не подходит в данном случае из-за технических ограничений в ДЦ.

Без маскарада что приходит?

sbin/iptables -t nat -A PREROUTING -p tcp –dport 80 -j DNAT –to-destination 10.8.0.1:80

Сейчас проверил. Этого достаточно.

Только 1 команда и всё? Проверю завтра

при условии что нет vpn тунеля, там тс в задаче вроде сказал что у него там несколько серверов соеденены vpn’ом, ну и как было сказано source адрес при этом становится тем что стоит на интерфейсе vpn

неплохо было бы понимать что там на backend’е предполагается? хотелось бы так же знать почему неподходит вариант с nginx’ом и адресом в header’ах?

вообще это задача решается с использованием прокси, если вариант с nginx’ом не подходит можно использовать например haproxy и proxy_protocol там информация об source адресах передается после установки tcp соединения и на принимающем стороне должна быть поддержка proxy_protocol’а, nginx его так же поддерживает..

• haproxy - все варианты

• haproxy - proxy_protocol

• на стороне nginx’а

Представьте задачу, что у вас 1000 доменов на которых выпущен SSL.

Как вы представляете себе таскать каждый раз при смене proxy IP эти все 1000 доменов? У меня такой возможности нет, тем более что задача как раз в том чтобы быстро и легко без труда развернуть новый ipv4 у домена и я не тратил кучу времени на это дело. При этом же, я могу менять хоть каждый день (этого еще не было конечно, но всё же) и мне что каждый раз покупать сервер под эти мощности? Потому мне задача нужна которая выполняет всё вышесказанное с передачей ip источника без каких-то там L7 приложений

вообще имелось ввиду tcp проксирование порта… т.е. идентично пробросу…

ну и автоматизацию для переконфигурации никто не отменял

При пробросе порта на NGINX все соединения на себя будет брать NGINX и инициализации SSL не будет в данном случае.

Понимаете что такое машина с 1000 доменами и какая она должна быть по хар-кам? Мне что каждый раз покупать новый сервер под это дело?

Я же описал правильно и грамотно свой вопрос (задачу), не нужно ничего другого придумывать.

в данном случае имеется ввиду haproxy, c nginx предполагаю возможно тоже. Прокси просто проксирует к 443 порту на нем у вас веб сервер обрабатывающий tls соединения.

хоть сколько у вас там доменов, сам прокси только проксирует и все

*.example1.com, exampleN.com —> [tcp proxy] – vpn – [backend]

*.example.com, *.exampleN.com - ваши домены

tcp proxy - для входящих соединений он просто проксирует на backend и сохраняет src адреса передавая их с использованием proxy_protocol веб серверу

vpn - ваш vpn тунель

backend - ваша машина с 1000 доменов, принимающая src адреса через proxy_protocol все сертификаты и ключи для tls здесь

На сетевом уровне эта задача не решается, если вы считаете иначе флаг вам в руки.

Если вам нужен именно OpenVPN, то настройте его в режиме L2 (TAP), либо настройте в режиме одного клиента (iroute 0.0.0.0 у единственного клиента).

Многопользовательские L3-туннели (в т.ч. OpenVPN TUN, WireGuard) не позволяют указывать IP-адрес, через который происходит маршрутизация (ip route … via 10.2.0.100) — эта опция требует L2-связности. Многопользовательские L3-серверы требуют конфигурации внутренней маршрутизации (опция iroute в OpenVPN, AllowedIPs в WireGuard), поэтому новичку для связи серверов/маршрутизаторов лучше использовать простые Peer-to-peer L3-туннели без собственных подсистем маршрутизации и проверок адреса источника: IPIP, GRE, L2TP, либо L2-туннели (но это может добавить проблем с маршрутизацией и безопасностью).

IPIP/GRE не подходит в данном случае из-за технических ограничений в ДЦ.

Ограничений по протоколам? Ну тогда заверните IPIP или GRE в UDP через fou, например:

https://www.man7.org/linux/man-pages/man8/ip-gue.8.html
https://gist.github.com/ciis0/b7c7b179978fa8b5b907b9abedeb6092

Либо настройте L2TPv3 статично (через ip l2tp, а не через xl2tpd сотоварищи).

The ip l2tp commands are used to establish static, or so-called unmanaged L2TPv3 ethernet tunnels. L2TPv3 is suitable for Layer-2 tunneling. L2TPv3 defines two packet encapsulation formats: UDP or IP.

ano , ну что хоть какое-то из предложенных решений подошло?

А тут и не предложили ни одного решения, только проксирование, но оно ортогонально вопросу. Для общего случая вводных не достаточно. Если у http сервера монопольный ответ на входящие соединения - одно решение, если нет, то все немного сложнее.

А тут и не предложили ни одного решения, только проксирование, но оно ортогонально вопросу.

если вы видите еще какое либо решение, предлагайте…

но с прокси провереное рабочее решение, тс же хочет чтоб все решалось без использования какого-либо софта средствами ядра.

Прокси - это уровнем сильно повыше. На уровне tcp/ip предлагаю навскидку, должно работать:

# хороним входящее подключение от проброса
iptables -t filter -A INPUT -i vpn_iface0 -p tcp --dport 443 -m recent --name FROMVPN --set -j ACCEPT
# проверяем ответный пакет на наличие в схороненном месте и метим
iptables -t mangle -A OUTPUT -p tcp --sport 443 -m recent --name FROMVPN --rcheck -j MARK --set-mark 100
# пхаем меченые пакеты в тоннель
ip rule add fwmark 100 lookup 100
ip route add 0.0.0.0 via vpn_iface0 table 100

На машине с пробросом, естественно, кроме DNAT надо еще и SNAT включить, чтобы до клиентов пакеты долетали.

Можно через ipset придумать. Ну, идея понятна, надеюсь.

но с pbr и заворачиванием трафика в туннель тут ясно, а вот как здесь source адреса будут сохранятся и далее сервер за впн на них будет отвечать несовсем

хороним входящее подключение от проброса

iptables -t filter -A INPUT -i vpn_iface0 -p tcp –dport 443 -m recent –name FROMVPN –set -j ACCEPT

здесь видимо вместо vpn_iface0 внешний интерфейс сервера?

маскарад надо выключить, естественно. нет, я все правильно указал именно интерфейс тоннеля.

Короче, на фронте:

iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT....
iptables -t nat -A POSTROUTING -o eth0 -j SNAT....

а на бэке - то что выше. я бы еще –rcheck уточнил и –remove добавил, чтобы совсем без side эффектов было, универсально. ну и побенчить надо recent vs ipset что быстрее будет, то и использовать.

тогда получается что эти правила за впн подключением на втором сервере к которому идет проброс… т.е. туда нужно на первом сервере настроить еще и dnat,snat (к серверу за впн). правильно я понимаю вашу идею?

я телепат) ответил до вопроса)))

только snat надо на исходящий трафик wan. не надо тоннель натить, это все поломает.

Сервер2 (default gateway указывает на интернет провайдера), принимает пакеты на порт 80 и перенаправляет их на Сервер1 (через openvpn туннель)

Сервер1 (default gateway указывает на !!! Сервер2 через openvpn туннель !!!) – автоматически возвращает клиенту из интернета пакеты через Сервер2.

Сервер2 роутит пакеты клиентам в интернет, делая MASQUERADE (SNAT)

Всё!

А если это не так? А если сервер за тоннелем самостоятелен?

Мы на это плюём, для решения задачи. Ведь это сервер с 1000 доменов, всё остальное неважно!!!

Там где-то затерялся сарказм, но я не помню где

Я тут подумал, и решил - решение рабочее и годное, но решение - говно. Слишком много side-effects. Надо метить всю сессию с помощью connmark. Тогда волосы станут шелковистыми.

поднял на тестовом стенде из виртуалок, данное решение (не c connmark, а предложенное выше) - но увы с использованием recent/ipset не взлетело… что-то не заворачивается в туннель Однако если просто сделать iptables -t mangle -A OUTPUT -p tcp –sport 443 -j MARK –set-mark 100 и далее ip rule как описано выше то работает. с ipset таже ситуация. есть идеи почему может не работать?

Э. Ну ты просто пустил весь трафик в тоннель (это норм, просто не универсально). Кек, я другой вопрос решал)))

будет время, выкачу статью, кастану тебя

есть идеи почему может не работать?

не идеи, а точные знания: где-то не включен ip_forward, где-то не отключен rp_filter

неа, не совсем точные, этож мой стенд точно могу только я знать что у меня там )

эти варианты проверял, но однако что-то не работало… допускаю что-то мог упустить, надо будет протестировать еще раз..

а чем решение с проксированием плохо? да там все решается прокси софтом. ну и что? производительность, ну так этож универсальное решение используемое на всяких хайлоад проектах. Вон взять тот-же кубер там входной точкой является балансировщик тот же nginx, openresty или haproxy. почему-то никто не городит всякие костыльные решения на основе принципа делать все ниже прикладного уровня. Тут вот мне непонятно желание тс принципиально не использовать софт. Разве что он это на на крайне слабом железе/виртуалках хочет сделать. Но он это не комментирует. Создается впечатление что это исключительно принцип и не более.

Да ничем не плохо, просто находится вне заданного вопроса)