Странного хочу: выдать реальный ip с одного сервера на другой через тоннель

Вторую часть посыла не распарсил - объясни подробнее. С айпишниками врядли выйдет, а вот с доменными именами - можно.

фильтровать на входе второго сервера айпишник первого сервера и заменять его на реальный айпи второго сервера.

Самое простое - сделать 1:1 нат-трансляцию всего траффика с реального айпи на туннельный.

Не до конца понятно, чего ты хочешь. Объясни, какую задачу ты решаешь, скорее всего это делается проще.

Можешь сделать полный NAT c второго сервера на первый, как предлагает blind_oracle. Запросы будут приходить на IP второго, но перенаправляться на первый.

Можешь поднять на первом сервере оба IP, с policy-based routing, чтобы он правильно отвечал на запросы с обоих. Запихнуть оба сервера с собственную AS, и так по-хитрому накрутить routing, чтобы изнутри AS по IP отзывался первый сервер, а снаружи - второй.

Если между серверами есть доп. канал связи, то не проблема.

Проще, конечно же, 1:1 NAT.

Чтобы его сделать, нужно установить xtables и использовать ct --notrack в RAWNAT.

Не до конца понятно, чего ты хочешь. Объясни, какую задачу ты решаешь, скорее всего это делается проще.

Задача очень простая. На сервере A есть IP адрес, на который куплена лицензия для «панельки».

Есть желание запустить эту «панельку» на сервер B.

Проблема в том, что сменить IP для лицензии невозможно согласно самой лицензии, а перенести IP с сервера A на сервер B тоже невозможно, так как это разные сервера в разных ДЦ. Никакой AS нет. IP арендованые.

Уж не ISPmanager ли настраиваешь?

P. S. Вариант поднятия на сервере A VPN, и роутинг нужных соединений от B к А в этот VPN не подойдёт в данном случае?

Панелька крутится локально и проверяет лицензию? Можно попробовать как-нибудь по-хитрому обмануть, типа поднять на втором сервере нужный ip, трафик с него snat-ить и пускать в vpn-тоннель до первого сервера, а с него опять snat-ить и пускать туда, где оно проверится хочет. И соотв. policy-based routing на втором: до сетей, куда панелька проверятся ходит - ходить с src=нужный ip.

Уж не ISPmanager ли настраиваешь?

ISPmanager позволяет смену ip.

Да, но и там есть свои лимиты на то как часто IP можно менять.

Я не думаю, что ему надо менять каждый день ip.

Панелька крутится локально и проверяет лицензию?

Да. GRE тунель я поднял, с этим проблем нет. Проблема в том, как заставить трафик правильно ходить между серверами, при условии что у них одинаковый IP. При этом еще надо на сервере A, где этот IP реален, учитывать то, что там еще и реальный трафик ходит.

Я бы на твоём месте решал всё-таки организационными методами: свяжись с менеджерами панельки, пусть одну лицензию заберут, а вместо неё выдадут другую, на новый ip. А если бы у тебя этот ip вообще пропал - ну, продали кому другому - типа всё, панельки больше не видать? Бред какой-то.

Реализовать наверное можно, но достаточно сложно и долго. Какие именно условия проверяет панелька? Наличие этого ip на сервере или достаточно, чтобы с этого ip пришёл запрос на сервер лицензий? Если второе - то VPN-туннель, SNAT на сервере с нужным ip и немного policy-based routing:

ip rule add to <ip_lic_serv> lookup 100
ip route add default via <ip_vpn> table 100

Если первое - то очень много секса с SNAT, policy based routing и не факт, что в итоге заработает

У панелек часто есть защита от хитрожопости. Даже если её удастся установить, не факт, что она не будет переодически связываться с домом и проверять лицензию, как это сделано в cPanel. Если с одного ип будут приходить 2 запроса, панельковладелец может связаться с хостером, а тот уже будет разбираться что к чему (и выставлять счёта если панельки две, а лицензия одна).

В той же сипанели на пример, есть проверка на контент. Если есть что-то Иранское, хостер получает письмо от панелькоконторы и обязан разобраться в установленный срок (обычно 2 недели), что для клиента геморрой, бабки и нервы.

Так-что если удастся обойти лимит с ип, не факт, что тебя все равно, не вычислят.

Большинство хостеров идут на встречу клиентам, тем более что замена лицензии для них не убыток. Я бы доставала аккаунт манагера по этому поводу.

Да и неизвестно кто после тебя этот велосипед получит. Строить такую бяку в продакшене нехорошо; велосипеды всегда перестают ехать когда уходит старый админ. Зачем теме негатив в карму и проблемы с хостером?

Поддерживаю - тоже считаю, что задача бессмысленная и очень уж кривая. А если такие проблемы с хостерскими панельками, то стоит посмотреть на ISPManager - их вечная лицензия стоит всего 1-2к рублей.

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

Не только хостерские панельки каверзные, просто хостер может провести дисциплинарные работы, которые обойдутся дороже.

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

Но самое смешное то, как начинают местные реагировать на найденный недостаток в Linux, как будто бы что-то личное.

Поднимаешь openvpn и даешь клиенту через ccd реальный ип.
Миллион раз так делал.

Самое простое - сделать 1:1 нат-трансляцию всего траффика с реального айпи на туннельный.

нат говно и лишний оверхед.

А я в тебя верил! И ты херню предлагаешь!

Ну я потом всё-таки написал

Я бы на твоём месте решал всё-таки организационными методами: свяжись с менеджерами панельки, пусть одну лицензию заберут, а вместо неё выдадут другую, на новый ip. А если бы у тебя этот ip вообще пропал - ну, продали кому другому - типа всё, панельки больше не видать? Бред какой-то.

А так чё - придумал херню, предложи товарищу :)

А причём тут ccd(client-config-dir)? Если этот ip один, и уже висит на сетевом интерейсе сервера?

Клиенту ты можешь позволить ходить с него через NAT. Или присобачить к интерфейсу бридж, запихать туда клиента, и раздать ему этот ip, но тогда самому от этого ip придётся отказаться. Или вариант с помощью кучи policy-based routing, SNAT и чьей-то там матери.

Расскажи подробнее, как именно ты предлагаешь сделать, интересно же

А причём тут ccd(client-config-dir)? Если этот ip один, и уже висит на сетевом интерейсе сервера?
Клиенту ты можешь позволить ходить с него через NAT. Или присобачить к интерфейсу бридж, запихать туда клиента, и раздать ему этот ip, но тогда самому от этого ip придётся отказаться. Или вариант с помощью кучи policy-based routing, SNAT и чьей-то там матери.
Расскажи подробнее, как именно ты предлагаешь сделать, интересно же

Не, конечно это в случае когда на основном сервере два ипа. Жопой таск прочитал :)

1:1 NAT вполне себе окей, там даже коннекшн трекинга нет. Тупо один адрес на другой меняется и обратно. Что тут плохого?

Предложи более оптимальное решение, чо.

1:1 NAT вполне себе окей, там даже коннекшн трекинга нет. Тупо один адрес на другой меняется и обратно. Что тут плохого?

Плохого тут то, что у меня нет «другого» адреса.

На обоих серверах один и тот же IP.

На обоих серверах не может быть одного и того же айпи. Он либо там либо сям, иначе будет бо-бо.

Если тебе нужно перенести его на другой сервер - то тут уже предлагали как это сделать: 1. Делаешь L2 тоннель через openvpn или l2tp pseudowire

2. Вешаешь на новом сервере этот айпи адрес на туннельный интерфейс

3. На старом сервере айпи адрес снимаешь и бриджуешь туннельный интерфейс и езернет.

4. Профит!

На обоих серверах один и тот же IP.

Стандартный способ решения — два промежуточных шлюза со SNAT + DNAT трансляцией на каждом. Создаешь отдельное адрессное пространство на 3 сети (L, T, R). которое с реальным вообще никак не связано. L - образ одного центра, R  — второго, T - промежуточная сеть между шлюзами. Каждый шлюз сидит в своем дата центре и для каждого из них проблем с конфликтом адресов адресов не возникает.

Может и можно извратится с метками, но это ОЧЕНЬ геморно. (Пример задачи по-проще)

http://darkk.net.ru/redsocks/doc/iptables-packet-flow-ng.png

Надо для начала позаботится о пробросе меток соединения в метки пакета и обратно. Разметить пакеты в mangle (обязательно) таблице. Завести две разные таблицы маршрутизации. Написать правила, когда какую смотреть. Кстати, вопреки докементации, правило «from all lookup local pref 0» удаляется.

Как уже сказали: проще решить проблему административными методами (уволив админа, который такое предлагает)

На обоих серверах не может быть одного и того же айпи. Он либо там либо сям, иначе будет бо-бо.

У меня на всех серверах есть IP 127.0.0.1

И никакого бобо :)

Очень умно, да.