Я предполагаю, что вы говорите о двух стандартных жилых или коммерческих интернет-соединениях (а не об арендованной линии или двух сайтах, связанных VPN или подобными).
В приведенном ниже примере сети у нас есть два здания и сервер (в любой точке мира), которые подключены через Интернет. У нас есть два маршрутизатора - R1
и R2
- каждый из которых имеет различный общественный IP - адрес (или « внешний » IP - адрес).
Внутри зданий все маршрутизаторы и устройства имеют общие IP-адреса - маршрутизаторы ( R1
и R2
) используют частный IP-адрес 192.168.0.1
, а устройства ( DA
и DB
) используют частный IP-адрес 192.168.0.10
.
Внешне к зданиям маршрутизаторы имеют разные публичные IP-адреса - 203.0.113.5
и 203.0.113.219
. Сервер доступен по общедоступному IP-адресу 203.0.113.42
.
Здесь есть важное различие между двумя типами IP-адресов, дополнительную информацию можно найти на вики-странице « Зарезервированные IP-адреса ».
- Публичная сеть - они доступны прямо в интернете
- Примечание: я фактически использовал набор сетевых адресов, которые зарезервированы для документации вместо реальных публичных адресов здесь
- Частная сеть - они предназначены только для использования в сети
Чтобы DA
получить доступ к серверу или хосту в Интернете (например, 203.0.113.42
), он должен получить помощь от маршрутизатора, поскольку 203.0.113.42
он недоступен в локальной сети. Таким образом, он отправит пакеты настроенному маршрутизатору ( R1
), который затем перенаправит пакеты в Интернет.
В этом случае маршрутизатор будет слегка перезаписывать пакет, помечая « Адрес источника » как R1
public address ( 203.0.113.5
), а не DA
address ( 192.168.0.10
). Когда пакет затем возвращается R1
, он проверяет таблицы соединений, переписывает пакет так, чтобы пункт назначения DA
снова был, и перенаправляет пакет в локальную сеть.
Это называется преобразованием сетевых адресов (NAT), а перезапись исходящих пакетов для использования собственного адреса маршрутизатора называется « маскарадингом », т. Е. Все исходящие пакеты, по-видимому, исходят от маршрутизатора, а не от устройства, находящегося за ним.
Это позволяет осуществлять связь между устройствами в частной сети (например, DA
и DB
) и общедоступным сервером в Интернете.
Чтобы представить некоторые услуги, предоставляемые внутри сети здания А, нам нужно R1
больше походить на сервер на 203.0.113.42
... Для этого мы вводим переадресацию портов .
Это метод, который позволяет нам настраивать R1
прием входящих запросов на соединение через порт (например, 22
для SSH ) и пересылать их на другой хост в частной сети, которую он обслуживает.
В этом случае DA
SSH-сервер работает на порту 22
, поэтому мы настраиваем R1
переадресацию порта 22 на его внешнем интерфейсе (т. Е. 203.0.113.5:22
) На сервер на его внутреннем интерфейсе (т. Е. 192.168.0.10:22
).
Теперь, когда мы настроили переадресацию портов, DB
можем получить доступ DA
к SSH-серверу, подключившись к R1
общему публичному адресу ... то есть к 203.0.113.5
порту 22
. Примечание: DB
не использует или никогда не должен знать DA
частный IP-адрес, и наоборот.
Трансляция сетевых адресов позаботится о вас, и вся цепочка будет выглядеть примерно так:
DB
отправляет пакет вR2
- Source:,192.168.0.10
Destination:203.0.113.5
R2
переписывает пакет - Источник:,203.0.113.219
Пункт назначения:203.0.113.5
R2
отправляет пакет через Интернет иR1
получает его
R1
переписывает пакет - Источник:,203.0.113.219
Пункт назначения:192.168.0.10
R1
отправляет пакет по локальной сети иDA
получает его
Обратный путь / ответ обратный:
DA
отправляет пакет вR1
- Source:,192.168.0.10
Destination:203.0.113.219
R1
переписывает пакет - Источник203.0.113.5
, Назначение:203.0.113.219
R1
отправляет пакет через Интернет иR2
получает его
R2
переписывает пакет - Источник:,203.0.113.5
Пункт назначения:192.168.0.10
R2
отправляет пакет по локальной сети иDB
получает его
Как видите, конфликтующие частные адреса вообще не имеют значения - ни одно устройство не находится в ситуации, когда 192.168.0.10
он рассматривается как источник и пункт назначения, или может быть доступно через два интерфейса. Если бы это было правдой, то ссылка явно не работала бы.
Некоторые заметки:
- Интерфейс конфигурации для маршрутизаторов значительно различается, поэтому мы не сможем выполнить настройку переадресации портов, не зная, какой у вас маршрутизатор.
- Подобная настройка переадресации портов сделает вашу службу доступной для всего Интернета (если только вы не настроите правила брандмауэра).
- Я настоятельно рекомендую не настраивать незашифрованные службы (например, Telnet / FTP) таким способом. Предпочитаю SSH / SFTP.
- Вы должны убедиться, что ваши услуги защищены соответствующим образом - например, аутентификация, ограничение скорости и т. Д.