LINUX.ORG.RU
ФорумAdmin

трансляция IP адреса

 , , ,


1

3

Прошу помощи у опытных сетевиков. Предыстория: В нашей деревне гадюкино провайдер скрипя сердцем выделил аж один IP внешний IP адрес для наших нужд. Мы установили сервер и радовались как дети, внешний айпи пробросили портами в локалку до сервера и все работает и по сей день. Теперь история :) Возникла острая необходимость в втором сервере (отдельный web сервер) для него нужен второй IP, которого нет и у нас не возьмешь. Пришла шальная мысль прикупить VPS с несколькими IP и переадресовать их на наши сервера… Но не тут то было… О как мы заблуждались и не долго радовались. Первым делом конечно, мы подняли между нашей сетью и VPS openVPN и внутри, с помощью IPTABLES портами пробросили перенаправление. Что то вроде этого: iptables -t nat -A PREROUTING -p tcp -d IP-статика –dport 29418 -j DNAT –to-destination IP-локальный:29418 iptables -t nat -A POSTROUTING -j MASQUERADE Извините, не знаю как тут выставить тег Все заработала и мы готовы были крикнуть ура, но… Тут то началось ОГРОМНОЕ НО… Новый web сервер начисто отрезал все попытки к нему подключиться… Сразу скажу, соединения отрезал fail2ban, так как оказалось, что все запросы на сервер приходят только от одного адреса - адреса тунеля openVPN. Ну, подумали мы… к нам особо стучать некому, пользователей не особо много и отключили fail2ban. Все заработало. Но возникла вторая беда. Оказалось, скорость соединения начала падать в геометрической прогрессии… Казалось бы… соединений напрямую между VPS и нашим сервером 100мегабит, а на деле передача данных не превышает 3 - 4 мегабит…
Оказалось что это двойной трафик на каждого, кто подключается к серверу, на канал до VPS/

Собственно мы поняли, что VPS где то там, со своими внешними IP не решают нашу проблему в нехватке IP/// Толку от них чуть.

Ну или поправьте или еще лучше направьте меня к руководству боевых действий. Что нужно решить: 1 - ip vps должен быть назначен серверу ( иначе на сервер приходят запросы только с одного IP и мы не можем контролировать кто к нам пришел) 2 - как избежать двойного трафика через канал VPS <–> Наш сервер? Что бы ответ клиенту шел напрямую с сервера, а не возвращался обратно на VPS и уже оттуда клиенту…

Что бы ответ клиенту шел напрямую с сервера, а не возвращался обратно на VPS

Никак.

И я не вижу проблемы в двойном трафике. Просто сделай впс поближе к себе, и протестируй скорость впс-локалка в обоих направлениях.

Зачем вам много ip? Разве нельзя замутить что-то вроде виртуального хостинга или на разные порты повесить сервисы?

Bers666 ★★★★★ ()
Ответ на: комментарий от Bers666

Поближе VPS 500р подальше 50р чувствуешь разницу? Вот если бы можно было как то завернуть трафик, что то вроде.. На VPS указать, что его ip это алиас указывающий на другой сервер. Или на VPS взять еще один ip и указать что этот ip принадлежит машине в локальной сети… Машина в локальной сети ( с внешним ip от VPS ) имеет шлюз по умолчанию через наш, уже имеющийся от провайдера. Так нельзя?

hotmax22 ()
Ответ на: комментарий от Anoxemian

выкинь openvpn и используй wireguard

И как это поможет в решении озвученных автором темы проблем? Трафик-то все равно будет идти с адреса VPS.

Serge10 ★★★★★ ()

Присоединяюсь к вопросам Bers666. На канале 100 Mb двойной трафик не должен приводить к проблемам. Хотя, конечно, это от нагрузки зависит. Вы оценивали нагрузку на Ваш сервер? Может, Вам просто не хватает имеющегося канала?

Serge10 ★★★★★ ()
Ответ на: комментарий от Anoxemian

Это про скорость хождения этого трафика

Это, IMHO, зависит от того, что узким местом является. Если сам канал, то вряд ли поможет. Или Вы думаете, проблема в том, что сами серверы не тянут нагрузку OpenVPN? Как-то сомнительно, тут же не слабые роутеры на концах туннеля используются.

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

да чего тут гадать. iperf в студию.

Да и судя по тсу, который взял vps только для ip, это скорее всего днище, для которого openvpn это жепь.

Anoxemian ★★★★★ ()
Последнее исправление: Anoxemian (всего исправлений: 1)
Ответ на: комментарий от Anoxemian

Зачем… тут и так все понятно. сервера видят входящий трафик только с одного ip - он принадлежит openVPN. 123,123,123,123 -> локалка VPN 10,8,0,6 -> сервер 192,168,10,10 192.168.10.10 видит только пакеты от 10,8,0,6, а не от 123,123,132,123. А нужно миновать 10,8,0,6

hotmax22 ()
Ответ на: комментарий от hotmax22

Можно вообще миновать vpn и пробрасывать все пакеты на наш внешний IP а там IPtables указать, что все, что приходит С 123,123,123,123 от правлять на 192,168,10,10 …

hotmax22 ()
Ответ на: комментарий от Serge10

Канал отличный.. Еще раз повторю, если с нашего IP отправлять файлы напрямую на VPS скорость 100Mb держит. Проблемы начинаются когда начинаем заворачивать трафик в локалку.

hotmax22 ()
Ответ на: комментарий от hotmax22

Канал отличный..

Тогда прислушайтесь к совету Anoxemian - возможно, Ваш VPS просто не справляется с нагрузкой, создаваемой OpenVPN.

Serge10 ★★★★★ ()
Ответ на: комментарий от hotmax22

Проблема еще в том, что на серверах нет реальных IP пользователей. Это то как организовать?

В текущей организации сети - никак. Но можно поставить на VPS http-прокси, перенаправляющий запросы на Ваш локальный сервер, и вести логи на нем.

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

а нельзя организовать без iptables? add route и указать куда.. так не будет же лишнего шага и запросы должны отправляться как есть?

hotmax22 ()

необходимость в втором сервере (отдельный web сервер)

Разделить по доменам возможности нет?

sin_a ★★★★★ ()

Возникла острая необходимость в втором сервере (отдельный web сервер) для него нужен второй IP, которого нет и у нас не возьмешь.

поэтому на public ip подключения следует принимать с помощью промежуточного сервера, который называется обычно front. Обычно в качестве фронта используется nginx.

targitaj ★★★★★ ()
Ответ на: комментарий от hotmax22

а нельзя организовать без iptables? add route и указать куда..

Маршрутизация до серых IP работает только в локальных сетях. Для доступа к серым IP из Интернет нужно манипулировть заголовками пакетов, тут без NAT никак не обойтись.

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

Да не, тс хочет выпускать из своей локалки ип пакеты с src addr=vps_ip, чтоб ответ приходил на vps, а оттуда в локалку)))

Bers666 ★★★★★ ()
Ответ на: комментарий от Bers666

Неужели такая сложная задача, отправить входящие на шлюз ip как есть до сервера в локалке? не нужно никаких VPN. Просто берем VPS, с него все запросы с помощью ?iptables отправляем на другой внешний IP (шлюз) шлюз прозрачно отдает все запросы в локалку на один внутренний IP/ У меня блин страрый древний dlink dir 300 и то умел приходящие на него из инета запросы передавать как есть в сеть на машину с функцией dmz и там я мог видеть все приходящие ip а не 192,168,0,1 роутера.

hotmax22 ()
Ответ на: комментарий от hotmax22

тебе уже пять раз спросили, ЧТО ты будешь проксировать. Ответа пока нет...

web сервер должен узнать IP клиента

X-Forwarded-For


nginx проксировать почту, ftp

умеет

и тд

??? nginx \ tcp proxy. Есть еще всякие tls sni прокси.

Bers666 ★★★★★ ()
Ответ на: комментарий от Bers666

Ничего я не буду проксировать. Еще раз повторю NGINX не умеет с почтой работать ( врать не буду, но ftp тоже вроде не работает) Не нужен тут прокси. Нужен будет прокси, я haproxy подниму. Задача отправить ( а не распроксировать по внутренним адресам ) весь трафик с одной тачки на другую без подмены IP адресов. Повторю еще раз. представьте что на VPS стоит не linux а гребанный dir 300/// я на нем укажу WAN и укажу LAN DMZ и он отправит входящий запрос до второго адреса без изменения. На втором адресе тоже стоит DIR 300 и он тоже принятый пакет отправит в DMZ без изменения. Как организовать такую схему в Linux?

hotmax22 ()

iptables -t nat -A POSTROUTING -j MASQUERADE

Вот это тебе зачем?

TheAnonymous ★★★★★ ()
Ответ на: комментарий от TheAnonymous

Он хочет чтоб ответ шёл напрямую, минуя опенвпн.

Bers666 ★★★★★ ()
Ответ на: комментарий от hotmax22

маскарад работает как SNAT, поэтому ip подменяется.
Если он нужен для раздачи интернета с впн-сервера, укажи там конкретный интерфейс, чтобы не применялось для пакетов идущих к тебе

TheAnonymous ★★★★★ ()
Последнее исправление: TheAnonymous (всего исправлений: 1)
Ответ на: комментарий от hotmax22

Для http(s) используй прокси, для почты используй релей, для ftp используй разные порты или строй свою схему. Как минимум уменьшишь количество точек отказа.

sin_a ★★★★★ ()
Ответ на: комментарий от sin_a

Короче я так понял никто из вас не знает как написать iptables, что бы он передал запрос как есть без подмены ip. Может iptables и не умеет? Может это что то другое?

Не думал, что это архи сложная задача, доставить все пакеты одного источника, через маршрут из нескольких точек в неизменном виде. Что бы получатель увидел IP отправителя….

hotmax22 ()

Возникла острая необходимость в втором сервере (отдельный web сервер) для него нужен второй IP

Можно ещё раз для тупых: почему нужен второй IP, почему нельзя использовать другой порт/домен?

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

zolden ★★★★★ ()
Ответ на: комментарий от zolden

Потому что два почтовых сервера на 25 порту в локалке не уживутся. Так понятнее? А почему нужно 2 - потому что. Это сервера разных клиентов. Разные панели управления, разные домены, разные админы их будут рулить. Моя задача пробросить до них внешние IP/

hotmax22 ()
Ответ на: комментарий от hotmax22

Я не пойму, у тебя таки vpn до сервера, или хочешь через голые интернеты это сделать?
Потому что если второе, то

что бы он передал запрос как есть без подмены ip. Может iptables и не умеет?

этого ни iptables, ни кто другой не сумеет, в принципе.

А если через vpn, то тред не жопой читать надо.
Попробую повторить - у тебя в оп-посте в правилах iptables есть MASQUERADE в POSTROUTING - оно тебе зачем-то нужно? Или ты эти команды тупо бездумно скопировал откуда-то? Если последнее, то можешь его выкинуть, это должно решить проблему

TheAnonymous ★★★★★ ()
Ответ на: комментарий от hotmax22

Потому что два почтовых сервера на 25 порту в локалке не уживутся. Так понятнее? А почему нужно 2 - потому что. Это сервера разных клиентов. Разные панели управления, разные домены, разные админы их будут рулить. Моя задача пробросить до них внешние IP

Ну так поднимите эти серверы на серых IP и укажите в качестве релея сервер на VPS, сконфигурированный для двух (или сколько Вам нужно) доменов.

Для остальных описанных Вами задач прокси подходят идеально. Объясните, пожалуйста, что именно Вас не устраивает в решении с прокси?

Serge10 ★★★★★ ()

Тебе надо прокси с несколькими virtual hosts на ВПС, которое будет кидать запрос на бекенд в твою локалку.

PunkoIvan ★★★★ ()
Ответ на: комментарий от TheAnonymous

Ага, типа сервак из локалки ответит со своего ip. Вот так инициатор коннекта офигеет, послал пакет на ip1, а ответ приходит с ip2..

Для этого и нужен маскарадинг на впн, чтоб и ответ шёл через впн.

Bers666 ★★★★★ ()
Последнее исправление: Bers666 (всего исправлений: 1)
Ответ на: комментарий от TheAnonymous

DNAT меняет dest.addr. но не меняет src.addr.
SNAT\MASQ меняет src.addr. но не меняет dst.addr.

=> соотв-но c DNAT но без SNAT сервак из локалки ответит по default gateway.

Вроде азы.

Bers666 ★★★★★ ()
Ответ на: комментарий от Bers666

Ну смотри, когда раздаёшь интернет в локалку через iptables (чтобы сервер можно было поставить шлюзом), то прописываешь только SNAT (или MASQ), без DNAT.
И для исходящих пакетов из локалки так и есть, подменяется только src.addr, но когда из локалки устанавливается TCP-соединение на внешний адрес, ответы (извне) доходят нужному адресату (который устанавливал соединение), и dest.addr подменяется правильно, хотя DNAT-правила нет.

Но если и всё так, как ты пишешь, то маскарадинг (а в конкретном случае лучше - SNAT, ip то статический) можно делать только для пакетов, уходящих «в интернет», т.е.

iptables -t nat -A POSTROUTING -s ip_из_локалки -j MASQUERADE
Тогда для входящих пакетов IP меняться не будет, как и требуется

TheAnonymous ★★★★★ ()
Ответ на: комментарий от Bers666

соотв-но c DNAT но без SNAT сервак из локалки ответит по default gateway.
Вроде азы.

А, понятно о чём речь, ну так на серваке в локалке надо указать vpn этим default gateway.
Можно кстати в отдельном namespace, в котором запустить и веб-сервер

TheAnonymous ★★★★★ ()

Твоя шальная мысль с vps говно. Вам надо белый ip ваш сделать шлюзом-прокси и проксировать всё внутрь локалки, в том числе и веб сервер и почтовые сервера, всё это возможно. VPS тут лишняя. Белый ip, я так понял, у вас только у NAT оборудования, а это не очень гуд, должен быть у мощного сервачка, который и будет проксировать трафик на другие внутренние ресурсы. Правильно тут пишут - можно nginx использовать для всех протоколов на базе TCP

menangen ★★★★★ ()
Ответ на: комментарий от Serge10

что именно Вас не устраивает в решении с прокси?

NIH-синдром, очевидно же

zolden ★★★★★ ()
Ответ на: комментарий от Bers666

Да, проблемы. Вот кто может объяснить как такое может происходить https://forum.unixm.ru:443/gallery/image.php?album_id=9&image_id=585 Именно NAT и проброшен. Исходящая скорость не поднимается выше 200Kb а на интерфейсе виртуалки мегабиты! Откуда? Я один файл лил. Все остальное отключено. iptables на VPS $IPT -t nat -A PREROUTING -p tcp -d $WAN_IP –dport 21 -j DNAT –to-destination 89.208.xxx.xx $IPT -t nat -A POSTROUTING -j MASQUERADE Без маскарадинга не работает

hotmax22 ()
Ответ на: комментарий от hotmax22

Во первых - тебе уже ответили, The Anonymous дал правильный ответ, но ты или не заметил, или не понял. Тебе нужно, на VPS, для правила с маскарадом указать исходящий в Интернет интерфейс, чтобы все ответы, для клиентов в Интернете, с твоей VPS уходили с src адресом твоей VPS, но при этом, при пересылке пакета по туннелю, адреса клиентов подменять не надо. Далее, тебе нужно указать маршрут на VPS для доступа к локальной сети, через VPN. На серваке, к которому нужен доступ, нужно шлюзом по умолчанию указать машину, на которой терминируется VPN туннель от VPS. А на этом шлюзе нужно указать что для всего что приходит от сервера - шлюз по умолчанию на другом конце VPN туннеля. Ну или если VPN туннель терминируется на сервере - просто создай маршрут что шлюз по умолчанию на другом конце туннеля.

Во вторых - можно сделать так, чтобы на сервер приходили пакеты от VPS, а уходили напрямую с сервера к клиенту, без участия VPS, и при этом src адресом в пакете будет адрес VPS’ки. Но это только в том случае если тебе провайдер позволит, ну или если провайдер раздолбай. Но я так делать крайне не советую - замучаешься дебажить если что-то пойдёт не так. Поэтому как это делается рассказывать не буду

Toten_Kopf ()
Последнее исправление: Toten_Kopf (всего исправлений: 2)
Ответ на: комментарий от hotmax22

Я один файл лил. Все остальное отключено. iptables на VPS $IPT -t nat -A PREROUTING -p tcp -d $WAN_IP –dport 21 -j DNAT –to-destination 89.208.xxx.xx $IPT -t nat -A POSTROUTING -j MASQUERADE Без маскарадинга не работает

Угу-угу , «вот правда правда» только через 21-й порт. Мы сразу верим.

anc ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.