Маршрутизация трафика для двух белых IP на одном интерфейсе Ubuntu Server

[Kanabiz]

Дано:

• VPS у OVH.
• Ubuntu Server (сейчас стоит 24.10 "пощупать", потом верну 24.04 ... думаю, это вряд ли что-то поменяет в моём случае).
• У VPS есть один интерфейс, на котором изначально был только один белый IP вида 135.XXX.XXX.XXX.
• Был приобретён второй белый IP вида 51.XXX.XXX.XXX. Как понятно из названия темы, "висеть" ему суждено на том же единственном интерфейсе. Это и было настроено согласно инструкции OVH:

Код: [Выделить]

network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true
      addresses:
        - 51.XXX.XXX.XXX/32
Для чего нужно два белых IP?
Есть необходимость, чтобы Nginx слушал на 80 и 443 портах два разных белых IP. И, соответственно, отвечал клиентам по принципу:

• При запросе через IP 135.XXX.XXX.XXX ответ должен произойти тоже с IP 135.XXX.XXX.XXX.
• При запросе через IP 51.XXX.XXX.XXX ответ должен произойти тоже с IP 51.XXX.XXX.XXX.

Сейчас же при запросе через любой из этих IP ответ всегда приходит с IP 135.XXX.XXX.XXX, что для меня неприемлемо.
Я находил информацию, как можно решить мою проблему через настройку routing policy для двух интерфейсов, но не для одного (как в моём случае).
Собственно, прошу подсказать, возможно ли это вообще?
И, если возможно, то каким образом?
Обычно я стараюсь осваивать неизвестные для меня моменты изучением документации и рассмотрением похожих ситуаций, но, похоже, не в этот раз. Сам я зашёл в тупик, поэтому прошу помощи.




P. S.:

• У VPS есть ещё IPv6 на том же единственном интерфейсе, но по факту пока он не используется.
• Вывод ip a :

Код: [Выделить]

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether fa:YY:YY:YY:YY:YY brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 51.XXX.XXX.XXX/32 scope global ens3
       valid_lft forever preferred_lft forever
    inet 135.XXX.XXX.XXX/32 metric 100 scope global dynamic ens3
       valid_lft 80355sec preferred_lft 80355sec
    inet6 2001:YYYY:YYYY:YYYY::YYYY/56 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:YYYY:YYYY:YYYY/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

• Вывод ip r show :

Код: [Выделить]

default via 135.XXX.XXX.1 dev ens3 proto dhcp src 135.XXX.XXX.XXX metric 100
135.XXX.XXX.1 dev ens3 proto dhcp scope link src 135.XXX.XXX.XXX metric 100
213.XXX.XXX.XXX via 135.XXX.XXX.1 dev ens3 proto dhcp src 135.XXX.XXX.XXX metric 100


• Выдержка из переписки с поддержкой OVH:

The aliasing configuration uses the VPS's network settings to connect to the public network, so the gateway IP for the alias is the same as the VPS's.
Unfortunately, it is not possible to add another network interface for the VPS service.

[Elias292]

dhcp4: true
Это как вообще ?

Ответ приходит...
Это как ?

Если с удаленного компютера сделать
telnet 51.XXX.XXX.XXX 80
откроется tcp сессия ?
Тогда ответ приходит точно с нужного ip. По другому ... не бывает.

Или ты пытаешься пинговать 51.XXX.XXX.XXX а отвечает другой ip
так это как то настройки пингов крутить нужно.

routing policy ... аккуратнее с термином.
Он понимается по разному циской, хуавеем, микротиком и линуксом.

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

[Kanabiz]

dhcp4: true
Это как вообще ?

Вот так.
Всё точно по инструкции OVH, как я и писал выше. Более того, оно, кажется, работает.
Сегодня я специально ещё раз всё перепроверил, "повешав" через Nginx на разных IP (135.XXX.XXX.XXX и 51.XXX.XXX.XXX) два разных простеньких сайта. Запросил для них сертификаты Let's Encrypt (на домены типа test1.example.com и test2.example.com). Всё, как ни странно, оказалось OK.

Если с удаленного компютера сделать
telnet 51.XXX.XXX.XXX 80
откроется tcp сессия ?
Тогда ответ приходит точно с нужного ip. По другому ... не бывает.

Да, всё открывается.

Или ты пытаешься пинговать 51.XXX.XXX.XXX а отвечает другой ip
так это как то настройки пингов крутить нужно.

На пинги на любой из IP-адресов отвечает именно пингуемый IP-адрес. Здесь проблемы нет.

Ответ приходит...
Это как ?

(Нажмите, чтобы показать/скрыть)

После выше упомянутой проверки я пошёл уточнять, кто и что там пытался настроить, так как после самостоятельной перепроверки проблема у меня не повторилась ... кстати, извиняюсь, что изначально ввёл в заблуждение относительно проблемы маршрутизации трафика на разных IP на одном VPS конкретно с/на Nginx. Написал с чужих слов, не перепроверив.

Как выяснилось, там пытались настроить сервер Xray с маскировкой через Reality под сайт, расположенный на этом же VPS (для друзей и знакомых в России).
Сегодня и я познакомился, что это такое ... и даже попытался настроить.

Сервер Xray (без сайта на Nginx на той же VPS) работает на ура (с маскировкой под сайт на другом сервере) при использовании основного IP (135.XXX.XXX.XXX), маскируясь под него же (135.XXX.XXX.XXX). Однако, при прослушивании на Xray дополнительного IP (51.XXX.XXX.XXX), маскировка происходит тоже под основной IP (135.XXX.XXX.XXX).

Если вернуть на тот же VPS сайт (и "натравить" маскировку Xray на него), то клиент Xray (любой) подключается с основным IP (135.XXX.XXX.XXX), но быстро теряет соединение (практически всегда в течении двух-трёх секунд).
При этом совершенно не важно, на каком из IP "висят" Xray и Nginx ... результат один: клиент Xray (любой) подключается с основным IP VPS (135.XXX.XXX.XXX), но быстро теряет соединение (практически всегда в течении двух-трёх секунд).

Правильно ли я понимаю, что, исходя из поведения XRay, можно сделать вывод, что он пытается "ходить" строго через основной IP VPS (135.XXX.XXX.XXX)?
И можно ли это как-то решить?

Собственно, как оказалось, в этом и заключается проблема с маршрутизацией трафика для двух белых IP на одном интерфейсе Ubuntu Server ...

routing policy ... аккуратнее с термином.
Он понимается по разному циской, хуавеем, микротиком и линуксом.

Ну, в теме я прямо упоминаю Ubuntu Server

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

Я и упомянул routing policy для Ubuntu Server поэтому, что, чувствовал, именно в ней и заключается решение этой проблемы. И видел описание решение я только для двух интерфейсов, а не для одного.

Если я правильно понял службу поддержки OVH:

The aliasing configuration uses the VPS's network settings to connect to the public network, so the gateway IP for the alias is the same as the VPS's.

шлюзом для дополнительного IP является тот же шлюз, что используется и для основного IP этого VPS.

Исходя из вывода ip r show :

Код: [Выделить]

default via 135.XXX.XXX.1 dev ens3 proto dhcp src 135.XXX.XXX.XXX metric 100
135.XXX.XXX.1 dev ens3 proto dhcp scope link src 135.XXX.XXX.XXX metric 100
213.XXX.XXX.XXX via 135.XXX.XXX.1 dev ens3 proto dhcp src 135.XXX.XXX.XXX metric 100речь о 135.XXX.XXX.1

Если это так, то и по шлюзам маршрутизировать трафик не получится ...

Есть ещё какие-то варианты?
Или нет смысла с этим заморачиваться?

[ALiEN]

он пытается "ходить" строго через основной IP

Ходит он с того ip, на который пришел запрос. Иначе соединения не будет. Elias292 вам уже намекнул.
Ну или это какая-то фича непосредственно xray.

Как вариант, пропишите listen address не 0.0.0.0, а тот, через который он должен ходить.

[Kanabiz]

Ходит он с того ip, на который пришел запрос. Иначе соединения не будет. Elias292 вам уже намекнул.

На примере Nginx я даже спорить не собираюсь, Сам убедился.
Но касаемо Xray ... в общем, читайте чуть ниже.

Как вариант, пропишите listen address не 0.0.0.0, а тот, через который он должен ходить.

Я так и тестировал на двух сайтах на двух разных IP на Nginx. Всё работало чётко.
Потом попробовал на Xray + сайт на Nginx (каждый "слушал" свой IP). Не работало так, как ожидалось.

Аналогична ситуация и с Xray отдельно:

• Сервер Xray слушает 51.XXX.XXX.XXX, при использовании этого "VPN" определяется мой IP как 135.XXX.XXX.XXX вместо ожидаемого 51.XXX.XXX.XXX.
• Сервер Xray слушает 135.XXX.XXX.XXX, при использовании этого "VPN" определяется мой IP как 135.XXX.XXX.XXX, что и ожидалось.

Если нагляднее, описанная ситуация выглядит так:

• Чистый Ubuntu 24.10 (с выше упомянутыми двумя IP - 135.XXX.XXX.XXX и 51.XXX.XXX.XXX - на одном интерфейсе).
• Установлен и настроен только чистый Xray (без всяких панелей):

(Нажмите, чтобы показать/скрыть)

• Клиент NekoBox подключается к серверу Xray тоже по 51.XXX.XXX.XXX:

(Нажмите, чтобы показать/скрыть)

• При всём при этом мой IP при использовании такого "VPN" определяется как 135.XXX.XXX.XXX (вместо ожидаемого 51.XXX.XXX.XXX):

(Нажмите, чтобы показать/скрыть)

Это всё я и пытался донести в сообщении выше. И, подозреваю, где-то здесь и кроется проблема того, что Xray ("слушающий" 51.XXX.XXX.XXX) не может подружиться с Nginx (который "слушает" 135.XXX.XXX.XXX). Как результат, клиент Xray быстро теряет соединение с сервером Xray ...

Сразу уточню:

• Если IP, которые "слушают" Xray и Nginx, поменять местами, то это ничего не меняет: клиент Xray по-прежнему быстро теряет соединение с сервером Xray.
• При этом сайт на Nginx работает чётко, в логах никаких проблем нет.
• Сам сервер Xray тоже работает нормально, в логах ничего аномального нет.

Ну или это какая-то фича непосредственно xray.

Либо это действительно фича такая у Xray, либо я не правильно объяснил, из-за чего меня недопоняли.
Если честно, я до сих пор подозреваю, что дело в маршрутизации трафика, и он (трафик) тупо уходит с VPS по маршруту по умолчанию. Хотя и могу запросто ошибаться. Да, я помню, что вы и Elias292 писали мне выше, но по другому описанную выше картину я объяснить не могу.

[AnrDaemon]

Это надо настраивать сам xray.
Объясняю на пальцах.
Клиент подключается к xray. Соединение устанавливает на том IP, к которому подключился клиент, всё о'кей.
Клиент отправляет на xray запрос. XRay(!) переправляет этот запрос в интернет от своего имени. Используя настройки роутинга, прописанные в системе, если только не прописано иное в настройках самого xray.

[Kanabiz]

Это надо настраивать сам xray.
Объясняю на пальцах.
Клиент подключается к xray. Соединение устанавливает на том IP, к которому подключился клиент, всё о'кей.
Клиент отправляет на xray запрос. XRay(!) переправляет этот запрос в интернет от своего имени. Используя настройки роутинга, прописанные в системе, если только не прописано иное в настройках самого xray.

Большое вам спасибо, так как это ваше объяснение оказалось подсказкой в правильном направлении.

Проштудировал ещё раз документацию по Xray ... и здесь кое-что всё же нашёл.

Оказалось, что в массив outbounds конфигурации Xray всего лишь необходимо было добавить "sendThrough": "origin".
Согласно документации Xray, при использовании специального значения origin запросы будут отправляться с IP-адреса, через который было установлено соединение с локальной машиной.

(Нажмите, чтобы показать/скрыть)

После корректировки файл конфигурации Xray стал выглядеть так:

(Нажмите, чтобы показать/скрыть)

{
    "log": {
        "loglevel": "warning"
    },
    "inbounds": [
        {
            "tag": "VLESS XTLS Reality",
            "listen": "51.XXX.XXX.XXX",
            "port": 443,
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
                        "flow": "xtls-rprx-vision"
                    }
                ],
                "decryption": "none"
            },
            "streamSettings": {
                "network": "tcp",
                "security": "reality",
                "realitySettings": {
                    "dest": "example.com:443",
                    "serverNames": [
                        "example.com",
                        "www.example.com"
                    ],
                    "privateKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxx",
                    "shortIds": [
                        "xxxxxxxxxxxx",
                        "yyyyyyyyyyyy",
                        "zzzzzzzzzzzz"
                    ]
                }
            },
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls"
                ]
            }
        }
    ],
    "outbounds": [
        {
            "sendThrough": "origin",
            "protocol": "freedom",
            "tag": "direct"
        }
    ]
}

Проблема решена.
После корректировки выше упомянутой конфигурации Xray и сам сервер Xray (на одном IP), и Nginx (на другом IP) теперь стали дружить и прекрасно между собой общаться. При этом и клиент Xray тоже стал замечательно себя чувствовать.

Я был почти близок, ибо дело было всё же в маршрутизации трафика. Но не на самом Ubuntu Server, а непосредственно в outbounds Xray-сервера.

Ещё раз спасибо AnrDaemon за подсказку.






P. S.:

Пойду "ковырять", что такое steal_oneself у Xray на одном белом IP ... вычитал в примерах на GitHub проекта.