IPIP туннелирование

Мощный поток сознания. Телепаты в отпуске. Что нужно-то?

Мда. Ну описал же все.

[qoute]Мне нужно, чтобы можно было биндить определенный IP (один из двух) и порт первой машины (под защитой) с машины без защиты.

Нужно помочь сделать все так, как надо. Или дать скрипт какой-то (сервер + клиент). Можно за деньги.

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

Много слов, а суть непонятна. Лучше объяснить более внятно и с картинкой.

Мне нужно, чтобы я мог со второго сервера повесить на IP и порт первого сервера что-либо (Апач, MySQL или другой сервер). Делают через туннель, но как?

iptables во все поля, зачем туннель? О_О

Мне нужно, чтобы я мог со второго сервера повесить на IP и порт первого сервера что-либо (Апач, MySQL или другой сервер). Делают через туннель, но как?

Не пойму зачем такой изврат? И зачем делать через туннель? Воспользуйся NAT/PAT с помощью iptables на втором сервере.

Через Iptables я смогу занять IP и порт первого сервера со второго сервера? Не охотно верится

Мне нужно именно занимать IP и порт на первом сервере со второго. Любой порт в любое время без изменений (желательно). Проще говоря, так работают многие компании по DDoS-защите серверов, но мне нужно это для личных целей.

-t nat -A PREROUTING и пробрасываешь с первого сервера под защитой на второй без защиты. Вот если нужно persistent реализовать, тут сложнее. На уровне сервисов для http rproxy делать можно. Остальное - хз.

Через Iptables я смогу занять IP и порт первого сервера со второго сервера? Не охотно верится

Не совсем так, но очень близко к этому. Так что для тебя будет ответ ДА. NAT подменит IP адрес (обращаешься на 1.2.3.4, а попадешь реально на 5.6.7.8). PAT, если надо, подменит порт (обращаешься, например на порт 123, а попадешь на порт 456)

Мне не нужно делать проксирование через NAT/PAT. Если бы мне это было нужно, я бы воспользовался xInet Redirect.

Мне нужно именно то, что я описал. И не для HTTP, а для какого-либо сервера. Да хоть игрового.

так почему нельзя сделать bind() на локалный IP и принимать коннекты прокинутые снаружи?????

Например игровой сервер Lineage 2, посылает «в ответку» IP гс'а, на который он забинден. А если он будет забинден на локальный ip, то что тогда? Отошлет локальный, клиент его не поймет.

а там точно нельзя в конфигах указать, какой IP отсылать?
ну, раз нельзя, то добавь алиасом этот IP на интерфейс lo с маской /32, на наружном сервере прокинь iptables-ами коннект на внутренний, а на внутреннем прокинь на lo.

Думается мне, проблема кроется в другом. А именно в двойной трансляции адресов. По тому, что я «нателепатил» - есть два сервера, которые глядят в интернет, вы их соединяете по ipip туннелю и пытаетесь через DNAT перенаправить запросы с сервера А на сервер Б. С этого момента начинается магия, т.к. основные маршруты у вас идут не цепочкой через туннель, а на свои локальные шлюзы. Для того, чтоб всё сработало есть два варианта:

Первый, перенаправить все потоки на сервере Б по туннелю (основной шлюз в туннель), кроме реального IP-адреса сервера А (т.к. через этот маршрут будет формироваться туннель).

Второй, более простой - двойная трансляция адреса. Непосредственно DNAT для перенаправления входящих запросов на сервер А в туннель. И SNAT в туннель на сервер Б, чтоб сервер Б не путался в маршрутах и считал, что все клиенты имеют IP сервера А в туннеле. Но в этом случае теряется возможность вести статистику айпи-адресов клиентов, вести бан-листы по IP непосредственно из вашей серверной программы, разве что фаерволом отсекать айпишники по DROP или REJECT на сервере А.

Теперь наглядно. У нас есть сервера, которые включены в интернет и имеют шлюзы. Пусть, адрес сервера А будет 192.168.0.100/24, а шлюз у него 192.168.0.1. Пусть у сервера Б адрес будет 172.18.4.100/24, а шлюз у него будет 172.18.4.254. В туннеле будем использовать подсеть 10.0.0.0/30 (только два адреса, 10.0.0.1 для сервера А и 10.0.0.2 для сервера Б). Пробрасываем tcp-порт 8888 с адресом назначения сервера А (192.168.0.100, то есть все входящие на этот айпи транслируются в туннель).

Первый вариант: Сервер А

# Делаем туннель
ip tunnel add ipip0 mode ipip remote 172.18.4.100 local 192.168.0.100
ip addr add 10.0.0.1/30 brd + dev ipip0

#Включаем трансляцию
iptables -t nat -A PREROUTING -p tcp --dport 8888 -d 192.168.0.100 -j DNAT --to-destination 10.0.0.2:8888
#разрешаем в фаерволле прохождение пакета по маршруту
iptables -A FORWARD -s 10.0.0.2 -j ACCEPT
iptables -A FORWARD -d 10.0.0.2 -j ACCEPT

# Делаем туннель
ip tuunel add ipip0 mode ipip remote 192.168.0.100 local 172.18.4.100
ip addr add 10.0.0.2/30 brd + dev ipip0

#добавляем маршрут до сервера А через наш шлюз
ip route add 192.168.0.100 via 172.18.4.254
#удаляем шлюз по-умолчанию и делаем шлюзом наш сервер А в туннеле
ip route del default
ip route add default via 10.0.0.1

Второй вариант: Сервер А

# Делаем туннель
ip tunnel add ipip0 mode ipip remote 172.18.4.100 local 192.168.0.100
ip addr add 10.0.0.1/30 brd + dev ipip0

#Включаем трансляцию
iptables -t nat -A PREROUTING -p tcp --dport 8888 -d 192.168.0.100 -j DNAT --to-destination 10.0.0.2:8888

#Включаем реверсную трансляцию, 
# т.к. сервер Б будет слать ответы на айпишники клиентов 
# через свой шлюз, а это неправильно. Поэтому мы 
# "прикидываемся", будто все запросы идут с адреса 10.0.0.1
# Сервер Б, найдёт маршрут в туннель и будет слать ответы в него.
iptables -t nat -A POSTROUTING -o ipip0 -j SNAT --to-source 10.0.0.1

#разрешаем в фаерволле прохождение пакета по маршруту
iptables -A FORWARD -s 10.0.0.2 -j ACCEPT
iptables -A FORWARD -d 10.0.0.2 -j ACCEPT

#Просто создаём туннель.
ip tunnel add ipip0 mode ipip remote 192.168.0.100 local 172.18.4.100
ip addr add 10.0.0.2/30 brd + dev ipip0

Айпишники подставите сами, как минимум, вместо 192.168.0.100 и 172.18.4.100 должны быть «реальные» маршрутизируемые адреса. Если на сервере Б нет реальника, то стоит смотреть в сторону openvpn или pptp/l2tp/ipsec туннеля вместо ipip.

Мне не нужно делать проксирование через NAT/PAT.

Это не проксирование. Теперь понятно почему «Третий день мучаемся. 2 бессонных ночи...» И год делать будете.

Огромное спасибо за столь развернутый ответ, но все же bind() на IP сервера A с сервера B производить не получится, верно? А это немного не то, что нужно.

Бинд - это всего-лишь привязка сокета к адресу-порту системы. Сейчас все программы спокойно переносят stateless NAT (простая подмена адреса, без слежения за соединениями), кроме случаев, когда серверная программа посылает свой адрес на протоколах высшего уровня, для этого умные дяди придумали connection tracking (а это уже слежение на уровне соединений, т.н. statefull NAT), который идёт модулем в ядре, отслеживает сам протокол и подменяет адреса уже в нём (например conntrack_ftp, conntrack_pptp, etc). То есть в вашем случае, нужно либо пропатчить саму серверную программу, и ввести в неё понятие «адрес трансляции», который будет посылаться по её же протоколу. Либо, накалякать conntrack модуль. Второй вариант предпочтительнее, т.к. позволит в будущем делать балансировку из нескольких frontend'ов на один backend - то есть сделать, такое себе облако с гео-распределением нагрузки и неким подобием защиты от DDoS.

Зачем все так усложнять. Все сервисы защиты от DDoS тех же самых игровых серверов работают через туннелирование и можно спокойно делать BIND на один из IP сервера «сервера» с сервера «клиента». У меня есть сервера под защитой и сервера без защиты. На «беззащитных» - игровые сервера, т.к они требуют большие хар-ки. И игровые сервера отдают IP, на который они забиндены логин-серверам, а они отдают его клиенту. Клиент подключается, а если он забинден на локальный IP - ничего не происходит....

Что-то подобное я уже встречал, по-моему у Ragnarok (eathena вроде сервер называется). Там не bind непосредственно, а адрес map-сервера указывается (который непосредственно передаётся клиенту), туда можно указать любой айпи, не обязательно локальный, тогда будет перенаправлять клиента правильно на фронтендовый айпишник.

А насчёт DDoS - в текущих реалиях, один фронтенд вряд ли выдержит >40Gbps атаку (не каждый дата-центр имеет такие входящие линии), для этого и делают распределение по земному шарику, так сказать облако.

Нет, сервер - LineAge. Никто не знает, как сделать бинд на IP сервера «сервера» с сервера «клиента»?

АнтиДДоС - >110Gbps, с этим проблем нету

1. сделай туннель, на целевом сервере добавь туда нужный IP
2. сделай туда bind() на целевом сервере демоном Lineage
3. объясни промежуточному серверу чтоб роутил этот IP в туннель и разреши форвардинг

Вам не бинд нужен, а параметр адрес гейм-сервера, отсылаемый клиенту. Тут или читать доки к вашему демону или патчить ручками. Другой вариант - писать свой conntrack модуль для фронтенда. Другими путями - никак.