информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаВсе любят медЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / beginners
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Господа, будьте снисходительны, не бросайтесь сразу штрафовать за, как вам кажется, глупые вопросы - beginners на то и beginners.
Те, кто с этой бедой боролся, утверждают, что сложнее... 13.06.06 13:06  Число просмотров: 2503
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Действительно, ipsecу небоходим ip адрес для
> шифрования\расшифровки.
> А можно ли в таком случае объяснить винде штатными
> средствами, какой адрес подствалять как свой (в данном
> случае реальник модема, находящийся "впереди" машины с
> политикой, так как на той стороне именно он указан как
> конечная точка туннеля), оставляя конечной точкой туннеля
> машину из моей локалки, на которой разёрнута политика?

Те, кто с этой бедой боролся, утверждают, что сложнее заставить АйПиСек использовать принудительный адрес для шифрования, поскольку он "сидит" близко к модулям, занимающимися сетевыми протоколами. Да и для повышения устойчивости к взломам авторы, похоже, как смогли заткнули подобные возможности. Проще НАТ заставить не менять адрес отправителя, хотя в Виндах это неочевидно.
<beginners>
IpSec tunnel over NAT 13.06.06 10:30  
Автор: Ustin <Ustin> Статус: Elderman
<"чистая" ссылка>
Жизненно важно настроить ipsec туннель между виндовой локалкой и внешней машиной. Перед внешней машиной в её подсети стоит маршрутизатор CISCO IOS, точнее не говорят, являющийся конечной точкой туннеля. У меня подключение через ADSL модем в режиме route, то есть модем с одной из сетёвок прокси сидит в одной подсети, другая сетёвка смотрит в локалку. При попытках настройки политики IPSEC пакеты ISAKMP ходят туда-сюда вроде нормально, но на той стороне маршрутизатор говорит incrementing error counter on sa, attempt 3 of 5: retransmit phase 1 и соединения не происходит. Ихний гуру сказал, что необходимо убирать nat как в локалке, так и на модеме, cryptoclient должен висеть на реальном IP. Насколько это справедливо? Заранее спасибо
IPSec прекрасно работает из-за NATа. Для этого надо... 13.06.06 10:53  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
IPSec прекрасно работает из-за NATа. Для этого надо пробрасывать 50 и 51 протокол и еще какой-то портик по протоколу TCP. Самое сложное побороть подмену адреса. Похоже он использует адрес при шифровании, а НАТ его как правило меняет. Однако ничего страшного не произойдет, если адрес отправителя будет не подмененый.
Это все, что помню. Подробности рекомендуется найти в соответствующей документации.
Спасибо. 13.06.06 11:33  
Автор: Ustin <Ustin> Статус: Elderman
<"чистая" ссылка>
> IPSec прекрасно работает из-за NATа. Для этого надо
> пробрасывать 50 и 51 протокол и еще какой-то портик по
> протоколу TCP. Самое сложное побороть подмену адреса.
> Похоже он использует адрес при шифровании, а НАТ его как
> правило меняет. Однако ничего страшного не произойдет, если
> адрес отправителя будет не подмененый.
> Это все, что помню. Подробности рекомендуется найти в
> соответствующей документации.
Спасибо.
Действительно, ipsecу небоходим ip адрес для шифрования\расшифровки.
А можно ли в таком случае объяснить винде штатными средствами, какой адрес подствалять как свой (в данном случае реальник модема, находящийся "впереди" машины с политикой, так как на той стороне именно он указан как конечная точка туннеля), оставляя конечной точкой туннеля машину из моей локалки, на которой разёрнута политика? Микрософт на эту тему молчит, там есть несколько примеров, но все они относятся к случаю прямого IP криптоклиента.
Может, для этого необходимо использовать для этого какой-нить сторонний софт?
Те, кто с этой бедой боролся, утверждают, что сложнее... 13.06.06 13:06  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Действительно, ipsecу небоходим ip адрес для
> шифрования\расшифровки.
> А можно ли в таком случае объяснить винде штатными
> средствами, какой адрес подствалять как свой (в данном
> случае реальник модема, находящийся "впереди" машины с
> политикой, так как на той стороне именно он указан как
> конечная точка туннеля), оставляя конечной точкой туннеля
> машину из моей локалки, на которой разёрнута политика?

Те, кто с этой бедой боролся, утверждают, что сложнее заставить АйПиСек использовать принудительный адрес для шифрования, поскольку он "сидит" близко к модулям, занимающимися сетевыми протоколами. Да и для повышения устойчивости к взломам авторы, похоже, как смогли заткнули подобные возможности. Проще НАТ заставить не менять адрес отправителя, хотя в Виндах это неочевидно.
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach