Доброго времени суток!
Есть задача:
Нужно объединить 2 сети с одинаковыми IP адресами в одну сеть, при этом нельзя менять IP адреса не в одной из сетей.
Например в сеть 1 входят IP адреса:
192.168.0.1
192.168.0.2
192.168.0.3
Во 2ую тоже IP адреса
192.168.0.1
192.168.0.2
192.168.0.3

Компьютеры в обоих сетях естественно разные

Нужно чтобы компьютер 1ой сети с IP 192.168.0.1 при обращении к 192.168.0.2 попадал на локальный IP адрес 192.168.0.2, а при обращении к 192.168.2.2 попадал на компьютер 192.168.0.2 из 2ой сети. На компьютерах можно прописывать только шлюз и DNS сервер, соответственно операции переадресовки и прочего можно проводить только на компе шлюзе или DNS сервере.

 Как можно решить данную задачу? Может быть есть технологии?

ИМХО поднять на сервере коннекты с этими адресами(х.х.2.х) и PortMapping всех портов

нат. туда и оттуда.

а вооще дурдом.

> нат. туда и оттуда.

как отличать в какую сетку слать? Автор топика предложил 2ой байт менять. а у тебя как?


> а вооще дурдом.

ага)

> Нужно объединить 2 сети с одинаковыми IP адресами в одну
> сеть, при этом нельзя менять IP адреса не в одной из сетей.
>  


Наверное можно извернуться и сделать
Одна из идей в [1]
НО!
Гарантированный геморой если не сразу то со временем.

Сделал бы по человечески
Откуда требование
<нельзя менять IP адреса не в одной из сетей.  ?

> Нужно объединить 2 сети с одинаковыми IP адресами в одну
> сеть


Не получится.

А как например сервер узнает кто из компов с IP адресом 192,168,0,1 из 1ой сети, а кто с тем же IP из 2ой сети? Как их разграничить, чтобы сервер понял кто есть кто, IP то одинаковые ...

> DelphiN!   (24.09.08 14:45) [6]


А никак.

Потому и не получится.

> Откуда требование
> <нельзя менять IP адреса не в одной из сетей.  ?


Компов много в каждой из сетей, в добавок много настроено внутри сети на эти IP адреса, также если сменить IP адреса то в будущем настраивать ПО придётся для каждой отдельной сети(а сетей не 2, гораздо больше). В общем если менять везде IP адреса проблем будет оооочень много и сейчас и потом,  
а объединить нужно...

> Сергей М. ©   (24.09.08 14:47) [7]


Неужели сети не объединяются скажем по VPN если имеют одинаковые IP?

хотя бы по одному компу в кажлой сетке надо сменить адрес

> Поросенок Винни-Пух ©   (24.09.08 14:53) [10]


Ну сменить IP на 1ом компе в каждой сетке это конечно можно! А можно поподробней описать вашу идею?

> DelphiN!   (24.09.08 14:52) [9]


Так ведь VPN - это другая сеть, отличная от связываемых тобой подсетей.
И клиенты VPN точно так же обязаны иметь уникальную IP-адресацию.

> Компов много в каждой из сетей, в добавок много настроено
> внутри сети на эти IP адреса,
...
сетей не 2, гораздо больше


Тем более нельзя реализовывать эту идею!
Обязательно AD с DHCP для каждой из подсетей

> DelphiN!   (24.09.08 14:56) [11]


И не надо ничего менять, нужно просто развернуть третью сеть - ту самую VPN. Тогда клиенты всех твоих физических подсетей с пересекающейся IP-адресацией станут уникальными клиентами виртуальной сети.
Главное - выбрать "правильное" место для развертывания VPN-сервера. Хост, где будет работать VPN-сервер, должен быть однозначно маршрутизируем из всех объединяемых "под его началом" физических сетей.

Лучше один раз много явных проблем, чем потом много неявного геморрроя.

А вообще вся эта котовасия со сменой IP - ну на день парализует работу от силы. Или даже меньше.

И то это будет только из-за того, что некоторые будут прикрывать свое безделие фразой "а у меня компьютер не работает!".

Можно провести превентивные меры:
а) выяснить в какой сетке меньше настроено на IP адреса других машин (а что, и правда перекрестный зоопарк?! есть же имена машин как минимум вместо IP); сетку с меньшим кол-вом перекрестных всязей и переключать.

б) попробовать пройтись и уточнить какие именно "перекрестные связи" используются. После смены IP менять и эти настройки.

в) IT-отделу (или его почетному представителю) выйти в субботу и перенастроить/протестить работоспособность хотя бы некоего необходимого минимума (выявить заранее). Остальное допиливать по потребностям в real-time

> Сергей М. ©   (24.09.08 15:05) [14]


Ничего не понял, как 3я сеть поможет сделать уникальными IP адреса 2х сетей.
Можно поподробнее

Ну сменить IP на 1ом компе в каждой сетке это конечно можно! А можно поподробней описать вашу идею?

я же сказал, что это дурдом.

К стати. для явности проблем советую поменять IP во всех сетках на другие, из других, ранее неиспользуемых диапазонов. Т.е. если кто-то ранее ходил на машинку хх.0.1 - то он гарантированно ее не найдет в сетке и увидит явную проблему. А не скрытую.

Главное - выбрать "правильное" место для развертывания VPN-сервера.

и чего? всем кому надо в соседнюю сеть устанавливать коннект с vpn сервером ?

> DelphiN!   (24.09.08 15:09) [16]


Хост, становящийся клиентом VPN, получает доступ к ней через отдельный сетевой интерфейс, который м.б. сконфигурирован (автоматически VPN-сервером через DHCP или вручную)  независимо от уже существующих сет.интерефейсов этого хоста. Тем самым соблюдается твое условие - нельзя изменять тем или иным образом IP-адресацию хостов существующих физ.сетей.

> Поросенок Винни-Пух ©   (24.09.08 15:13) [19]


В условиях, оговоренных автором, обойтись без сервиса-"координатора" нельзя.

> DelphiN!   (24.09.08 15:09) [16]
>
> > Сергей М. ©   (24.09.08 15:05) [14]
>
>
> Ничего не понял, как 3я сеть поможет сделать уникальными
> IP адреса 2х сетей.

Никак не поможет. Но зато позволит выдать каждому компьютеру в ней второй IP-адрес, и этот второй адрес уже может быть уникальным

То бишь, к примеру:

Физ.сеть  LAN1: 192.168.0.0/24
Физ.сеть  LAN2: 192.168.0.0/24
Вирт.сеть VPN:   192.168.1.0/16

Хосты LAN1_Host1 и LAN2_Host1 имеют одинаковые адреса, скажем, 192.168.0.1
Но в VPN те же самые хосты будут иметь уникальную адресацию, например

LAN1_Host1 => VPN_Host1 = 192.168.1.1
LAN2_Host1 => VPN_Host2 = 192.168.1.2

> Как можно решить данную задачу? Может быть есть технологии?

Делал как-то.

Одно из решений:
1-to-1 NATed IPSec tunnel

Для решения, необходимо, чтобы программно-аппаратный комплекс позволял установить IPSec, в котором реализуется 1-to-1 NAT mapping.
С аппаратами Watchguard это легко решается. С другими не пробовал. IPSec не обязательно должен быть шифрованным.

Пакеты с комьютера 192.168.0.1/24 отправляются на 192.168.2.1/24 через "gateway", установленный в TCP/IP параметрах (либо через IP, установленный с помощью route add).
Этот gateway устанавливает 1-to-1 NATed VPN tunnel с другим аппаратом, осуществляя mapping 192.168.2.1 -> 192.168.0.1 и обратно.

Сорри, на подробности времени нет - работаю. Вот текст из хелпа:

When you create a branch office VPN tunnel between two networks that use the same private IP address range, an IP address conflict occurs. To create a tunnel without this conflict, both networks must apply 1-to-1 NAT to the VPN. 1-to-1 NAT makes the IP addresses on your computers appear to be different from their true IP addresses when traffic goes through the VPN.
1-to-1 NAT maps one or more IP addresses in one range to a second IP address range of the same size. Each IP address in the first range maps to a unique IP address in the second range.

1-to-1 NAT and VPNs
When you use 1-to-1 NAT through a BOVPN tunnel, this occurs:
 When a computer in your network sends traffic to a computer at the remote network, the Firebox changes the source IP address of the traffic to an IP address in the masqueraded IP address range. The remote network sees the masqueraded IP addresses as the source of the traffic.
 When a computer at the remote network sends traffic to a computer at your network through the VPN, the remote office sends the traffic to the masqueraded IP address range. The Firebox changes the destination IP address to the correct address in the real IP address range and then sends the traffic to the correct destination.
1-to-1 NAT through a VPN affects only the traffic that goes through that VPN. The rules you see in Policy Manager at Network > NAT do not affect traffic that goes through a VPN.

Other reasons to use 1-to-1 NAT through a VPN
In addition to the situation described previously, you would also use 1-to-1 NAT through a VPN if the network to which you want to make a VPN already has a VPN to a network that uses the same private IP addresses you use in your network. An IPSec device cannot route traffic to two different remote networks when the two networks use the same private IP addresses. You use 1-to-1 NAT through the VPN so that the computers in your network appear to have different (masqueraded) IP addresses. However, unlike the situation described at the beginning of this topic, you need to use NAT only on your side of the VPN instead of both sides.
A similar situation exists when two remote offices use the same private IP addresses and both remote offices want to make a VPN to your Firebox. In this case, either remote must use NAT through its VPN to your Firebox to resolve the IP address conflict.

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

1) Поднимаем везде DNS и DHCP. Во всяком софте компьютеры адресуем не по ip а по именам. В этом случае смена адресации проходит легко и беззаботно.

2) Если уж очень приспичило, то можно поставить в третьей подсети VPN-сервер, к которму будут цепляться компьютеры обеих подсетей. Он им будет выдавать ip-адреса. Тогда компьютеры разных подсетей будут видеть друг друга в рамках новой третьей подсети. Если все настроить правильнь (в т.ч. что бы Ip-ки каждый раз те же выдавались, что бы DNS внутри нормальный был, что бы сессии не рвались) то должно работать. Скорость только будет низкая... Она будет определяться производительностью VPN-сервера.

3) По уму - взять вариант 1) и шаг за шагом, компьютер за компьютером реализовывать.

маршрутизатор посередине и тут бы static трансляция подошлабы
static (inside,dmz) 192.168.0.0 192.168.2.0 netmask 255.255.255.0
но насколько корректно это будет работать в промышленных маштабах - хз :)

Slym ©   (25.09.08 5:13) [27]
подумал - всеравно чето не клеится... надо рисовать...
тут получается двойной статик нужен О_о ато в обратном направлении нету связи

> Slym ©   (25.09.08 05:13) [27]


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

Да всё правильно Slym предложил. Тут только маршрутизатор и поможет и сидеть "долгими осенними вечерами" вручную прописывать таблицу маршрутизации по каждому компу. А VPN тут никак не поможет ибо "адреса менять нельзя", а в сети VPN каждый комп получит уникальный IP, на который имеющееся ПО не настроено, соответственно введение VPN = включению DHCP, только проблем больше принесёт.

> Труп Васи Доброго ©   (25.09.08 08:49) [30]


> ибо "адреса менять нельзя"


У существующих интерфейсов !

А создавать новые интерфейсы с новыми адресами никто вроде бы не запрещает)

Вот, поэтому я в новых сетках всегда даю адреса

10.random(255).random(255).0/24

А проблема нормально решается только заменой адресов. Лучше один раз помучиться.

> проблема нормально решается только заменой адресов


Ну почему же ?
Проблема вполне решаема и назначением уникальных дополнительных IP-адресов существующим интерфейсам в диапазоне вновь формируемой общей сети.

И вручную потом за ними следить еще.

Труп Васи Доброго ©   (25.09.08 8:49) [30]
сидеть "долгими осенними вечерами
маршрутизация это другое...
под статиком я имел ввиду статическую NAT трансляцию:
имеем пакет на if1:
SRC             DST
192.168.0.1     192.168.2.1 (онже 192.168.0.1 второй сети)

STATIC (if1,if2) 192.168.2.0 192.168.0.0 mask 255.255.255.0
превращает пакет в:
192.168.0.1     192.168.0.1 (онже 192.168.0.1 второй сети)

STATIC (if2,if1) 192.168.1.0 192.168.0.0 mask 255.255.255.0
превращает пакет в:
192.168.1.1     192.168.0.1 (онже 192.168.0.1 второй сети)

обратный пакет в обратном порядке статически модифицируется

> Slym ©   (25.09.08 05:13) [27]
> маршрутизатор посередине и тут бы static трансляция подошлабы

Да принцип правильный. Простым маршрутизатором не обойдешься. Недостает только деталей :)

Сеть 1: 192.168.0.0/24 с Gateway1 =, например, 192.168.0.250.
Сеть 2: 192.168.0.0/24 с Gateway2 =, например, 192.168.0.250.

На обеих gateway (IP=192.168.0.250) обоих сетей сажаем по аппарату, способный устанавливать IPSec с 1-to-1 NAT (например Watchguard Firebox): FB1 и FB2.
В Сети 1 есть комп1 с IP 192.168.0.1.
В Сети 2 есть другой комп2 с таким же IP 192.168.0.1.

Kомп1 пингует комп2 из Сети 2:



Пакетина проходит по следующей дирижке:



Для Комп2, пришедший пакет будет содержать адрес отправителя такой, какой мы укажем в правилах mapping'а на IPSec 1-то-1 NAT, например: 192.168.10.1, или даже 192.168.2.1 :)
Также, Комп2 192.168.0.1 отправит ответ на пинг Компу1 (который он видит как 192.168.10.1) через свой Gateway2 192.168.0.250 в Сети 2. Также, IPSec + 1-to-1 NAT сделают перевод адресов и переброску пакетов в нужном направлении автоматически.

Тут подумалось, наверное это единственный возможный способ решения данной проблемы. Хотя утверждать не буду.

Эпизодически пользуюсь этим, когда необходимо, например, возвести новый домэн с идентичными IP адресами серверов (так уж хочется партии и правительству:) и обсуждению не подлежит).
Как правило, базовых серверов DC + application бывает не менее 8-10. И перевод рабочих application со старых на новые может происходить в течении долгого периода, на протяжении которого пользователи должны иметь доступ как к старым серверам, так и к новым.
Либо, также при возведении нового домэна, когда заданные IP сети нового домэна клиента, совпадают с уже существующими нашими сетевыми адресами.

Сорри, забыл закрыть тэг.

> На обеих gateway (IP=192.168.0.250) обоих сетей сажаем по
> аппарату....


Одним аппаратом можно обойтись... и гейтвеев не писать ответ в [26] пункт 2.

Но одно точно: нужно тем или иным образом создавать третью сеть, с адресацией отличной от двух предыдущих, в рамках которой каждый комьютер из обеих подсетей будет иметь уникальный адрес. И видеть комьютеры будут друг друга по адресам 3-й подсети.

Как ни бейся, но если с обоих сторон есть по компьютеру 192.168.100.1, то по этому адресу они друг друга точно не увидят.

а вообще сделать одну сеть и не париться

тем более, что все должны видеть всех.

Если сейчас не сделаете одну сеть без ВПНов и маршрутизации, то в будущем можете огрести кучу невнятных проблем.