LINUX.ORG.RU
ФорумAdmin

Разные сети, одинаковые адреса


0

1

«Суть токова» (с)
Есть сервер, который воткнут в сети двух провайдеров.
И у этих провайдеров есть внутренние ресурсы, к которым этот сервер периодически должен обращаться. Проблема в том, что у этих провайдеров ресурсы оказались с одинаковыми айпишниками (192.168.0.0/16) и менять их они не собирается.
В результате пакеты для 192.168.226.8 в сети прова №2 уходят для 192.168.226.8 прова №1, ибо маршрут по умолчанию.
Как можно разрулить эту ситуацию?

★★★

Один из интерфейсов подключить к виртуальной машине. Когда виртуалка не нужна фризать её. Для виртуалки сойдёт микро floppy дистробутив.

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

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

yirk ★★★
() автор топика

Это можно разрулить на уровне policy-based routing'а: все, что пришло с ethN или уходит с его айпишника, маршрутизируется согласно таблице N, в которой подсети 192.168.0.0/16 соответствует ethN.

Если нужен stateful-фаервол, то эта фича (conntrack zones) поддерживается только с 34-го ведра.

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

>а сами целевые ИП тоже одинаковые чтоли?)
Именно.
У обоих провайдеров есть ресурсы с адресами 192.168.Х.Х и, как минимум, у 4-х айпишники совпадают.

yirk ★★★
() автор топика

Если сервер САМ должен обращаться к этим ресурсам, то имхо только менять маршрут или политики. В скрипте, например.

Т.е.

IP=192.168.226.8/32
IF1=eth0
IF1=eth1

while : do
/sbip/ip r d $IP dev $IF1
/sbip/ip r a $IP dev $IF2
<тут обращаемся к ресурсам серевера у Провайдера2>
sleep 60
/sbip/ip r d $IP dev $IF2
/sbip/ip r a $IP dev $IF1
<тут обращаемся к ресурсам серевера у Провайдера1>
sleep 60;
done

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

Хотя...

Присваиваем им собственые уникальные IP, по которым и будем к ним обращаться (из неиспользуемого диапазона, причём внутренние), маршрутизуем исходя из IP по разными интерфейсам, в цепочке POSTROUTING таблицы nat делаем DNAT

:)

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

При этом даже политики не потребуются

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

Интересный вариант. Попробуем:)

yirk ★★★
() автор топика

Ethernet bridge.

Хм-м, ethernet bridge, кажися, умеет всякие хитрые штуки с преобразованием адресов сетей. Посмотрите документацию, не исключаю что возможно реализовать такое: сеть одного из провайдеров объединяется в ethernet bridge, который с одной стороны виден как 192.168.222.22, а с другой 172.16.222.22. Тогда ресурсы одного провайдера будут видны в сети 192.168.0.0/16, а другого в 172.16.0.0/16. Хитрый план, но я совсем не уверен что это можно реализовать.

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

маршрутизуем исходя из IP по разными интерфейсам, в цепочке POSTROUTING таблицы nat делаем DNAT


Заманчивая идея, проблема только в том, что в nat POSTROUTING можно делать только SNAT/MASQUERADE, а DNAT - это как раз OUTPUT цепочка (для исходящих локально сгенерированных пакетов), после которой может снова проходить перемаршрутизация, если в ядре включена фича «маршрутизация на основе firewall-ных маркировок».
Думаю лучше в этом случае просто менять маршруты «вручную» и не заморачиваться.

spirit ★★★★★
()
Ответ на: Ethernet bridge. от Camel

Brouting.

Вот оно, brouting.

Brouting: decide which traffic to bridge between two interfaces and which traffic to route between the same two interfaces. The two interfaces belong to a logical bridge device but have their own IP address and can belong to a different subnet.

Я понимаю не совсем о чём идёт речь, возможно о том что надо, а возможно что и нет.

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

Нужно экспериментировать, можно MARK использовать вместе с DNAT, или и то, и другое - terminating target. Если можно, то в iptables по источнику отправлять пакет в отдельную таблицу, там делать DNAT и ставить метку, а в iproute2 через политики маршрутизовать пакеты через разные интерфейсы

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

По источнику - это если программа умеет делать bind на заданный интерфейс, но тогда и маркировать ничего не надо, тогда голая маршрутизация по src IP прокатит. А если не умеет, тогда никакие firewall-ы, маркировки и правила маршрутизации не помогут, ибо имеем задачу «послать пакет на IP x.x.x.x», который находится по 2-м направлениям - ни firewall, ни маршрутизация не угадают куда же в данный момент надо было слать.

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

>По источнику - это если программа умеет делать bind на заданный интерфейс, но тогда и маркировать ничего не надо

Всё гениальное просто :) Снимаю шляпу

А если не умеет, тогда никакие firewall-ы, маркировки и правила маршрутизации не помогут


В общем случае - нет, т.к. сервер может возвращать свой ip в явном виде (redirect в http, passive ftp и т.п.). Но в большинстве случаев можно подключаться по фиктивным адресам, фиктивные адреса маршрутизовать по разным интерфейсам, а за интерфейсами маршрутизатор/виртуалка с DNAT.

router ★★★★★
()

ситуация разруливается техникой называемой double nat (в google легко ищется, да и в LARTC кажется описано). Вкратце - на уровне ip делается отображение (stateless подмена адресов) одной из сетей в незанятый диапазон, а на уровне iptables -t NAT уже докручивается всё необходимое.

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