Провайдер подключает без NAT

[teraflops]

Наш провайдер выдает клиентам серые ip-адреса 192.168.0.0/16. Так же доступна услуга белый ip-адрес. Но проблема в том, что внутри сети провайдера клиенты с белыми и серыми адресами подключаются к друг другу без NAT напрямую. Организация купила белый адрес для своего веб-сервера и шлюза для доступа к интернет. Локальные адреса организации и локальные адреса провайдера из одного и того же диапазона 192.168.0.0/16 Поэтому абоненты провайдера не могут соединяться с веб-сервером организации, т.к. ответы на пакеты с сети провайдера он посылает внутрь своей локальной сети. Если вручную прописывать маршруты возникает обратная проблема. Ответы на пакеты из своей сети сервер посылает в сеть провайдера. В принципе, решение проблемы мне известно. Либо менять все адреса самой организации, либо использовать разные таблицы маршрутизации для каждого интерфейса силами iproute2. У меня вопрос только один: Есть ли какой нибудь документ (RFC или еще что-то), который запрещает прямое подключение серых и белых адресов без участия NAT?

[vasilisc]

серые с белыми IP адресами по определению не могут работать без технологий типа NAT.
как вы себе представляете работу между 192.160.1.100 и 97.45.32.12 ??
ведь серые адреса не маршрутизируемы в Интернете и их "убивает" ближайший маршрутизатор.

[victor00000]

teraflops,
провайдера вебсервер добро пожаловать?

[teraflops]

серые с белыми IP адресами по определению не могут работать без технологий типа NAT.
как вы себе представляете работу между 192.160.1.100 и 97.45.32.12 ??
ведь серые адреса не маршрутизируемы в Интернете и их "убивает" ближайший маршрутизатор.

а маршрутизатором кто управляет? провайдер. в том-то и дело. белые и серые ип-адреса самого провайдера подключаются напрямую без NAT. во внешнюю сеть выходят как положено. через NAT. но внутри сети провайдера уже не важно какой адрес.
Пользователь решил продолжить мысль 28 Апреля 2012, 18:27:01:

teraflops,
провайдера вебсервер добро пожаловать?

ты понял что написал?

[drako]

Долго перечитывал, но так и не понял сакральной мысли о том, что пров все натит в инет, а внутри сети все мешает... Откуда такая инфа?..
Может, все-таки, конфиги настроек сети выложите?

[koshev]

Какие кон фиги? Вопрос - философский. И я сильно прозреваю, что даже если сменить адресацию корп сети, провайдреская сеть и копроративная взаимодействовать не будут, вернее будут, но в одну сторону и то, в случае использования пресловутого ната на бордере корп.сети.

[AndreyGL]

teraflops, о да - ваш провайдер знает толк в извращениях. Плюс к тому я непанимат как оно вообще работает с вашей кроп.сетью.

Давайте-ка я попробую резюмировать ситуацию для начала. Как я ее понял "от лица" вашего бордера.
Имеем 2 интерфейса: eth_uplink и eth_lan пусть будет.
На eth_uplink имеем некий адрес из сети 192.168.0.0/16 - пусть будет 192.168.5.5 - и шлюз например 192.168.0.1 с единственным маршрутом 0.0.0.0/0 через 192.168.0.1.
На eth_lan тогда что получается? Тоже 192.168.x.x? Диссонанс. Грусть.

Предположу как бы я разрулил ситуацию.

На бордере имеем 3 интерфейса: eth_uplin, eth_lan и eth_servers

eth_uplink - повторяться не буду
eth_lan - адрес 172.16.1.254/24
eth_servers - адрес 172.16.2.1/30

правила nat:
Все что приходит на eth_uplink по 80 порту натим на 172.16.2.2:80
При этом я подразумеваю, что провайдер будет натить 1:1 все что идет на ваш белый адрес в серый ип вашего бордера (тот что на eth_uplink).

для рабочих станций шлюз по умолчанию 172.16.1.254, адреса из соответствующей /24 сети. в dns прописываем домен своего вэб-сервера на 172.16.2.2. Можно и без этого, но тогда соединение из вашей корп сети к вашему же вэбсерверу будет идтьи через роутер провайдера.

Так бы оно и работало. Конкретнее? Что ж, спрашивайте мои ответы.

[teraflops]

eth0 - провайдер. адрес внешний статический 195.42.у.х
eth1 - lan 192.168.1.1/16 (сеть организации, все адреса прописаны вручную, давно так сделано).
интернет работает нормально. но абоненты провайдера подключаются к сайту организации через свой локальный адрес без NAT, который тоже из 192.168.0.0/16. Поэтому серверу неясно куда отправлять ответы (точнее ему ясно, он посылает их во внутреннюю сеть). Естественно, абоненты провайдера в ответ ничего не получают. Мне известно, как решить данную проблему. Вопрос был в другом.
И еще, если отключить локальную сеть организации (или временно поменять адрес), то я могу напрямую подключаться к адресам 192.168.х.х провайдера, получаю доступ к ихней локальной p2p сети. Т.е. имея белый адрес, я могу напрямую подключаться к серым адресам. поглядите за вашими интернет провайдерами тоже, много провайдеров так и делают.

[drako]

Ув., teraflops, Вам по теоретизировать хочется? Может всё-таки мы увидим:
ifconfig -a
route -n
cat /etc/resolv.conf

[teraflops]

Ув., teraflops, Вам по теоретизировать хочется? Может всё-таки мы увидим:
ifconfig -a
route -n
cat /etc/resolv.conf

зачем вам это? вопрос в совершенно другом. кроме того доступа у меня нет.

Есть ли какой нибудь документ (RFC или еще что-то), который запрещает прямое подключение серых и белых адресов без участия NAT?

[AnrDaemon]

зачем вам это? вопрос в совершенно другом. кроме того доступа у меня нет.

Тогда о чём вообще речь?
Кнока "сообщить модератору", тема едет в "разговоры обо всём".
Пользователь решил продолжить мысль 02 Мая 2012, 01:36:42:P.S.
http://tools.ietf.org/html/rfc1918

[teraflops]

Ув., teraflops, Вам по теоретизировать хочется? Может всё-таки мы увидим:
ifconfig -a
route -n
cat /etc/resolv.conf

и что ты там надеешься увидеть? говорю же, интернет работает без нареканий. 2 интерфейса, один смотрит в интернет, другой смотрит в локальную сеть организации.
ты суть проблемы не понимаешь. организация и провайдер использует одни и те же адреса. и при этом серые адреса подключаются к белым напрямую без NAT. говорю же, проблема легко решается через iproute2. я такое уже делал.
Пользователь решил продолжить мысль 02 Мая 2012, 06:14:37:о RFC 1918 знал давно, но теперь изучил более детально.

Public hosts can communicate
with other hosts inside the enterprise both public and private and
can have IP connectivity to public hosts outside the enterprise.
Public hosts do not have connectivity to private hosts of other
enterprises.

из этого я понял, что прямая связь между серыми и белыми адресами внутри сети провайдера все-таки разрешается.
собственно, проблему в таких случаях теперь придется решать всегда своими силами.
p.s. многие неправильно поняли суть проблемы. она простая - провайдер и организация использует одни и те же блоки адресов частных сетей.например, приходит к серверу пакет посланный узлом 192.168.54.41. куда отправлять ответ? такой адрес может иметь и узел из сети провайдера, и узел из корпоративной сети.

[AnrDaemon]

Смените адресацию в организации. Делов на 15 минут.

[Yuriy_Y]

2 интерфейса, один смотрит в интернет, другой смотрит в локальную сеть организации.
организация и провайдер использует одни и те же адреса.

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

[teraflops]

Смените адресацию в организации. Делов на 15 минут.

адреса указаны вручную на каждом хосте. узлов больше 800. расстояние между ними достигает 5 км. используется vlan.  это сделано давным-давно. еще на этапе разработки сети. в это время я еще учился в школе. кроме того про это я уже написал на первом посте.
Пользователь решил продолжить мысль 02 Мая 2012, 08:41:31:

2 интерфейса, один смотрит в интернет, другой смотрит в локальную сеть организации.
организация и провайдер использует одни и те же адреса.

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

вася пупкин из сети провайдера не видит сеть организации. вы как себе это представляете? это две разные физические сети. они не взаимодействуют друг с другом. к обеим сетям подключен только сервер.