PavelKHTW А вот по поводу второго утверждения ну не скажи При отправке пакетов из приватной сети через NAT в сеть с реальными адресами там именно содержится информация об адресе NAT интерфейса шлюза который отправлял пакет иначе по твоему как он обратно вернется к отправителю.
Кстати если уж разбираться в этой ситуации можно было бы снифером перехватить пакеты между клиентом - сервером - cisco и посмотреть что мы имеем на каждом участке, но это уже имхо перебор
[/quote]
Я смотрю ув. domovoy с теорией работы NAT-а у вас проблемы. Об "адресе NAT интерфейса шлюза" в пакете ничего нет.
А сниффер нафиг не нужен, на cisco есть все средства
например
>show access-lists
покажет работу списков доступа.
Когда узел 10.0.1.4 сети А хочет послать пакет хосту 10.0.12.2 сети В, то для этого он указывает глобальный адрес 185.127.125.4/24 в качестве адреса назначения. Узел-отправитель направляет пакет своему маршрутизатору по умолчанию; тот знает маршрут к сети 185.127.125.0/24, так что пакет переправляется им на внешний интерфейс. Однако перед отправкой пакета устройство NAT, применяя таблицу отображения внутренних адресов во внешние, транслирует частный адрес отправителя 10.0.1.4 в соответствующий ему глобальный адрес 181.230.25.1/24. После путешествия по составной сети пакет поступает на внешний интерфейс устройства NAT сети B, а глобальный адрес назначения 185.127.125.4/24 преобразуется в частный адрес 10.0.12.2. Пакеты, передаваемые в обратном направлении, проходят аналогичную процедуру трансляции адресов.
[/quote]
нет времени разбираться — наймите того, кто знает.
PavelKHTW Нет я клюню к тому что у Armarn был приведен такой фрагмент из acl
Цитата
To All
отрезок из acl
access-list 111 permit ip host 192.168.0.97 any
access-list 111 deny ip any any
[/quote]
Как видишь в стоит разрешение серверу 192.168.0.97, а потом запрет всем, то есть прямого запрета клиенту нет, и если принять за основу то что при установке клиентом в роли шлюза сервера в загаловках пакетов адрес сервера фигурирует как адрес отправителя пакетов исходя из приведенной из RFC информации (но это в случае что он таки срабатыват как нат) то естественно правило отрабатывается только по разрешением серверу и клиент попадает в инет.
добавлено
А вообще там в загаловках есть оба адреса и приватный и адрес Nat это я могу сказать без RFC, та же гостевая на этом сайте фиксирует у себя в логах оба адреса написавшего и адрес приватный и адрес шлюза. И это уже практика, а не теория так сказать. Я по этой практике баню рекламщиков порнухи в гостевой
добавлено
А вот кстати NAT на интерфейсе сервера может помоему срабатывать если включен ICS на нем, мысль может и простовата, это должно быть проверено было в первую очередь, но рабоатет эта штука именно используя NAT так сказать.
Правильно заданный вопрос - это уже половина ответа.
Stratofortress Не важно как это называется факт в том что фигурируют, а значит и передаются оба адреса. И при прохождении через шлюз правила срабатывают именно для этих адресов.
Правильно заданный вопрос - это уже половина ответа.
Нет нужды цитировать RFC, все вы верно говоритеStratofortress, и как написано в RFC - вся информация хранится в таблице отображения адресов, а вовсе не в заголовках или в теле данных.
А почему гостевая книга может сказать мой локальный адрес - так это все просто, есть два способа
1 В заголовках HTTP запросов есть поле ForwarderFrom(за точность названия не ручаюсь), но весь прикол в том что это поле можно отключить простой опцией в squid forwarder_for в off
2. С помощью java или javascript - тут уж никак.
3. неизвестный мне способ, но никак не связанный с заголовком пакета IP
А мысль про ICS очень даже! - Но зачем тогда ув. Armarn морочил нам всем голову???
Stratofortress Не важно как это называется факт в том что фигурируют, а значит и передаются оба адреса. И при прохождении через шлюз правила срабатывают именно для этих адресов.
[/quote]
Ув. domovoy эти адреса передаются уже на уровне HTTP запросов и ответов, а не на уровне IP. Ну и естественно HTTP не маршрутизится и не натится маршрутизаторами
PavelKHTW » 16 апр 2004, 15:39 
