> 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, то по этому адресу они друг друга точно не увидят.

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