4

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

Я хотел бы вперед порт 1234 от x.x.x.x к y.y.y.y (как в Интернете , в разных местах , то есть y.y.y.y не является внутренними IP , как 10.a.b.c и т.д.) таким образом , что y.y.y.y способен получить исходный IP при подключении к x.x.x.x

Прямо сейчас он видит x.x.x.x в качестве исходного IP-адреса, используя обычные правила SNAT или MASQUERADE. Если y.y.y.y - это какой-то внутренний IP-адрес (например, контейнер lxc, работающий на x.x.x.x), действуют те же правила, и контейнер может видеть фактический исходный IP-адрес, но только если y.y.y.y является внешним.

Может ли это быть достигнуто каким-либо образом?

|источник

3 ответа3

4

Только с NAT - нет. IP-пакеты имеют только одно поле «источник».

  • Если вы заставите iptables сохранить исходный адрес клиента (только DNAT), то yyyy попытается отправить ответы непосредственно этому исходному клиенту (который думает, что он разговаривает с xxxx и не ожидает никаких пакетов от yyyy).

  • Если вы сделаете так, чтобы iptables указывал ваш адрес в качестве нового источника (DNAT+SNAT), то yyyy не будет знать исходный адрес источника.

(Это на самом деле та же проблема, что и при попытке перенаправить порт из локальной сети в ту же локальную сеть, и второй метод называется «закрепление NAT» или «отражение NAT».)

Чтобы это работало, вам нужен туннель /VPN между xxxx и yyyy - оберните исходные пакеты, которые вы получаете, без каких-либо изменений, в другой IP-пакет, который отправляется в yyyy (который затем развернет туннельный пакет и увидит исходный источник),

Конечно, это означает, что вам нужны права суперпользователя в обеих системах для настройки туннеля. Кроме того, пункт назначения (гггг) должен поддерживать "маршрутизацию политик" - Linux и FreeBSD pf способны на это. Требуется правило, которое будет направлять все через VPN, если адрес источника является адресом VPN.

Вам все еще нужно правило DNAT iptables, но его «пунктом назначения» будет VPN-адрес, а не публичный адрес. Для этого вы можете использовать любой тип туннеля /VPN, от базового «IP-in-IP» до GRE, от OpenVPN до WireGuard. Например:

  • хххх

    Поднимите туннель:

    ip link add gre-y type gre local x.x.x.x remote y.y.y.y ttl 64
ip link set gre-y up
ip addr add 192.168.47.1/24 dev gre-y

    Добавьте правило переадресации портов, как в локальной сети:

    iptables -t nat -I PREROUTING -p tcp --dport 1234 -j DNAT --to-destination 192.168.47.2

  • гггг

    Поднимите туннель:

    ip link add gre-x type gre local y.y.y.y remote x.x.x.x ttl 64
ip link set gre-x up
ip addr add 192.168.47.2/24 dev gre-x

    Убедитесь, что это работает:

    ping 192.168.47.1

    Настройте политику маршрутизации, чтобы ответы (и только ответы) проходили через туннель:

    ip route add default via 192.168.47.1 dev gre-x table 1111
ip rule add pref 1000 from 192.168.47.2 lookup 1111

(Чтобы использовать другой тип туннеля /VPN, замените только часть "Bring up the tunnel".)

|источник
3

Нет, ты не можешь этого достичь. Проблема в том, что маршрутизация не будет работать.

Узел E (внешний) отправляет пакет на узел F (сервер пересылки). F отправляет этот пакет с тем же источником на хост D (пункт назначения). Эта часть работает, является ли D внутренним или внешним.

Теперь D должен вернуть ответ и отправить его по адресу источника в пакете, который является E

  • Если D является внутренним хостом, а F является шлюзом по умолчанию для D , то пакет проходит F , где источник D в ответном пакете изменяется на F Хост E видит пакет от F , и все в порядке.
  • Если D является внешним хостом, то F не будет шлюзом по умолчанию для D , и поэтому D будет отправлять ответ непосредственно в E Хост E получит ответ от D , но ожидает ответа от F , и поэтому отбрасывает пакет от D Хост E попытается повторить несколько раз, снова откажется от ответа с неправильного адреса источника и в конечном итоге истечет время ожидания.
|источник
2

Вы, вероятно, не можете достичь этого, потому что адрес источника используется для возвращаемого пакета - таким образом, если адрес источника находится за NAT, он не может быть достигнут из более широкого Интернета.

Обычно используется как минимум 2 обходных пути (которые требуют дополнительного программного обеспечения и конфигурации). Первый - использовать VPN для обхода маршрутизатора или, в качестве альтернативы, использовать между маршрутизатором и пунктом назначения, чтобы пункт назначения мог знать, как добраться до источника.

В случае HTTP и HTTPS не используйте правила брандмауэра IPTABLES, вместо этого используйте (прозрачный или обычный) прокси-сервер на маршрутизаторе и попросите прокси-сервер добавить заголовок X-FORWARDED-FOR, к которому внешнее приложение может обращаться и обрабатывать ,

В зависимости от вашего конкретного приложения и брандмауэра, также возможно пометить "относительный" внутренний IP-адрес, изменив порт источника, с которого поступает запрос (он все равно будет поступать с адреса маршрутизатора, но вы можете получить подсказка о том, какая система за маршрутизатором отправила его на основе порта источника). Я не видел, чтобы это использовалось на практике.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .