информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеПортрет посетителяСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / networking
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Некоторые подробности по VPN на Kerio WinRoute 6.0 17.04.06 16:53  Число просмотров: 17289
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Поразбирался немного с субжем и мануалом к нему... Может, кому поможет.


IPSec-VPN через Kerio WinRoute 6.0

Судя по мануалу WinRoute не имеет средств для установления IPSec тунеля, но может работать с IPSec в режиме сквозного прохода (IPSec Pass-through).

Немного смыслового перевода из мануала к Kerio WinRoute 6.0

Функция IPSec Pass-through гарантирует полную функциональность существующих IPSec клиента и сервера после размещения WinRoute на интернет шлюзе.

Если IPSec клиент находится на интернет шлюзе с работающим WinRoute, он должен быть настроен так, чтобы использовать внешний IP адрес. Трафик такого клиента не транслируется NAT'ом и использование функции IPSec Pass-through для такого клиента не требуется.

Если IPSec клиент находится во внутренней (локальной) сети за WinRoute и не поддерживает функцию NAT Traversal, то на WinRoute для него необходимо включить функцию IPSec Pass-through. Такой IPSec клиент во внутренней сети может быть только один.

Если IPSec клиент находится во внутренней сети за WinRoute и поддерживает функцию NAT Traversal, то поддержку IPSec Pass-through на WinRoute необходимо отключить во избежании коллизий и настроить для его трафика служб IKE и IPSec трансляцию IP адреса на внешнем интерфейсе (NAT).

Если IPSec сервер находится на интернет шлюзе с работающим WinRoute, то он может использовать внешний IP адрес шлюза.

Если IPSec сервер находится во внутренней сети, то на WinRoute необходимо настроить мапирование служб IKE и IPSec с внешнего IP адреса интернет шлюза на IP адрес IPSec сервера во внутренней сети. Для каждого IPSec сервера во внутренней сети необходимо мапирование отдельного внешнего IP адреса интернет шлюза.

ПРИМЕЧАНИЕ: Для всех вышеперечисленных случаев, необходимо в правилах фильтрации WinRoute разрешить клиентам подключения к IPSec серверам по сервисам IKE и IPSec.


---------------------
SSL-VPN средствами Kerio WinRoute 6.0

При настройке VPN соединения на стороне сервера или клиента необходимо, чтобы DHCP клиент функционировал. Наличие в сети DHCP сервера не обязательно.

В поле "IP address assignment" настройки VPN сервера, к которому будут подключаться VPN клиенты и/или другие VPN серверы, задается свободная подсеть, отличная от внутренней, из которой будут назначаться IP адреса "Kerio VPN" соединению VPN сервера, а также подключившихся VPN клиентов и/или дальних конечных точек VPN тунеля.

Грабли №1:
При регистрации в DNS дальней коненой точки VPN соединения с VPN сервером, на DNS сервере будет зарегистрирован недоступный из внутренней сети IP адрес, что сделает бессмысленным разименование зарегистрированного имени в IP адрес. Этот IP адрес (обычно 169.254.*), назначенный "Kerio VPN" соединению DHCP клиентом, используется в качестве "внутренней стенки" VPN тунеля и делается недоступным из внутренней сети реализацией VPN соединения. Второй же IP адрес, назначнный "Kerio VPN" соединению VPN сервером, доступный из внутренней сети и использующийся как шлюз для маршрутизации трафика во внутреннюю сеть VPN сервера, не регистрируется в DNS сервере.
Если для установления VPN соединения используется Kerio VPN клиент, то проблему можно обойти. Для этого, после установления VPN соединения, командой "ipconfig /all" необходимо выяснить первый IP адрес, назначенный VPN соединению DHCP клиентом, и второй IP адрес, назначенный этому же соединению VPN сервером. Далее, вручную прописать протоколу TCP/IP в качестве первого IP адреса - адрес назначенный VPN сервером, в качестве второго IP адреса - адрес назначенный DHCP клиентом, а также, в соответствующем поле, указать IP адрес DNS сервера. В WinRoute необходимо привязать к подключенному пользователю, для которого производится настройка, внесенный вручную первый IP адрес - адрес шлюза во внутреннюю сеть VPN сервера.
<networking>
IPSec over NAT (Win2003) 05.04.06 19:35  
Автор: catlion <catlion> Статус: Member
<"чистая" ссылка>
Кто-нибудь сталкивался, нужно настроить безопасное соединение к RDP с аутентификацией по preshared key с помощью IPSec. И клиент и сервер - Win2003. Проблема в том, что клиент находится за NAT'ом (DSL модем), и что-то этот нат такого гадкого делает, что не позволяет соединению успешно установиться.

Для тех, кто решит мне посоветовать использовать аутентификацию и шифрование самого терминал сервера 2003 винды, также вопрос, где должен лежать сертфифкат, чтобы его можно было использовать в терминал сервере? Я положил его в Personal контейнер терминал сервера, но в списке доступных сертификатов он не появляется.

Ссылки на конкретные доки приветствуются, ибо то, что я нешел на сайте майкрософта, не очень то помогает...
Может сделать тунелинг по tcp/ip сквозь nat с инкапсуляцией ipsec? 06.04.06 14:56  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Полноценный туннель не получается настроить из-за... 06.04.06 15:13  
Автор: catlion <catlion> Статус: Member
<"чистая" ссылка>
Полноценный туннель не получается настроить из-за динамического IP клиента. Хотя, возможно я неправильно вас понял...
Не понял... Клиент подключается по диалапу? 06.04.06 16:30  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
По DSL. В роли NAT выступает модем 06.04.06 16:39  
Автор: catlion <catlion> Статус: Member
<"чистая" ссылка>
Прокидывание UDP портов 500, 4500 и TCP 50 прописывал, не помогло. Говорят, девайс может модифицировать заголовки, из-за этого нестыковки.
Однозначно шлюз модифицирует заголовок (это по умолчанию,... 06.04.06 17:10  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Прокидывание UDP портов 500, 4500 и TCP 50 прописывал, не
> помогло. Говорят, девайс может модифицировать заголовки,
> из-за этого нестыковки.
Однозначно шлюз модифицирует заголовок (это по умолчанию, можно выключить), хотя адрес отправителя большой роли не играет. При настойке АйПиСека все прописывается и пакеты посылаются на тот адрес, который прописан, а приниматься они должны с вполне определенного, чтоб никакой другой комп не связался вместо того, что нужно.
Проблема использования других протоколов в том, чтоб не использовать запихивания одного пакета в другой. В этом случае может возникнуть трудность, связанная с увеличением размера пакета, превышающяа МТУ. Пэтому и используют другой протокол, полностью повторяющий ТиСиПи, только зашифрованый.
Не знаю как, но КЕРИО работает - рекомендую попробовать, чтоб не биться головой об стену. Мало того, в КЕРИО есть еще много "вкусностей", например - удобная конфигурация клиента.

Kerio VPN
Некоторые подробности по VPN на Kerio WinRoute 6.0 17.04.06 16:53  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Поразбирался немного с субжем и мануалом к нему... Может, кому поможет.


IPSec-VPN через Kerio WinRoute 6.0

Судя по мануалу WinRoute не имеет средств для установления IPSec тунеля, но может работать с IPSec в режиме сквозного прохода (IPSec Pass-through).

Немного смыслового перевода из мануала к Kerio WinRoute 6.0

Функция IPSec Pass-through гарантирует полную функциональность существующих IPSec клиента и сервера после размещения WinRoute на интернет шлюзе.

Если IPSec клиент находится на интернет шлюзе с работающим WinRoute, он должен быть настроен так, чтобы использовать внешний IP адрес. Трафик такого клиента не транслируется NAT'ом и использование функции IPSec Pass-through для такого клиента не требуется.

Если IPSec клиент находится во внутренней (локальной) сети за WinRoute и не поддерживает функцию NAT Traversal, то на WinRoute для него необходимо включить функцию IPSec Pass-through. Такой IPSec клиент во внутренней сети может быть только один.

Если IPSec клиент находится во внутренней сети за WinRoute и поддерживает функцию NAT Traversal, то поддержку IPSec Pass-through на WinRoute необходимо отключить во избежании коллизий и настроить для его трафика служб IKE и IPSec трансляцию IP адреса на внешнем интерфейсе (NAT).

Если IPSec сервер находится на интернет шлюзе с работающим WinRoute, то он может использовать внешний IP адрес шлюза.

Если IPSec сервер находится во внутренней сети, то на WinRoute необходимо настроить мапирование служб IKE и IPSec с внешнего IP адреса интернет шлюза на IP адрес IPSec сервера во внутренней сети. Для каждого IPSec сервера во внутренней сети необходимо мапирование отдельного внешнего IP адреса интернет шлюза.

ПРИМЕЧАНИЕ: Для всех вышеперечисленных случаев, необходимо в правилах фильтрации WinRoute разрешить клиентам подключения к IPSec серверам по сервисам IKE и IPSec.


---------------------
SSL-VPN средствами Kerio WinRoute 6.0

При настройке VPN соединения на стороне сервера или клиента необходимо, чтобы DHCP клиент функционировал. Наличие в сети DHCP сервера не обязательно.

В поле "IP address assignment" настройки VPN сервера, к которому будут подключаться VPN клиенты и/или другие VPN серверы, задается свободная подсеть, отличная от внутренней, из которой будут назначаться IP адреса "Kerio VPN" соединению VPN сервера, а также подключившихся VPN клиентов и/или дальних конечных точек VPN тунеля.

Грабли №1:
При регистрации в DNS дальней коненой точки VPN соединения с VPN сервером, на DNS сервере будет зарегистрирован недоступный из внутренней сети IP адрес, что сделает бессмысленным разименование зарегистрированного имени в IP адрес. Этот IP адрес (обычно 169.254.*), назначенный "Kerio VPN" соединению DHCP клиентом, используется в качестве "внутренней стенки" VPN тунеля и делается недоступным из внутренней сети реализацией VPN соединения. Второй же IP адрес, назначнный "Kerio VPN" соединению VPN сервером, доступный из внутренней сети и использующийся как шлюз для маршрутизации трафика во внутреннюю сеть VPN сервера, не регистрируется в DNS сервере.
Если для установления VPN соединения используется Kerio VPN клиент, то проблему можно обойти. Для этого, после установления VPN соединения, командой "ipconfig /all" необходимо выяснить первый IP адрес, назначенный VPN соединению DHCP клиентом, и второй IP адрес, назначенный этому же соединению VPN сервером. Далее, вручную прописать протоколу TCP/IP в качестве первого IP адреса - адрес назначенный VPN сервером, в качестве второго IP адреса - адрес назначенный DHCP клиентом, а также, в соответствующем поле, указать IP адрес DNS сервера. В WinRoute необходимо привязать к подключенному пользователю, для которого производится настройка, внесенный вручную первый IP адрес - адрес шлюза во внутреннюю сеть VPN сервера.
Сталкивался, настраивал не сам, а провы. С Микрософтовым ВПН... 06.04.06 10:13  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Кто-нибудь сталкивался, нужно настроить безопасное
> соединение к RDP с аутентификацией по preshared key с
> помощью IPSec. И клиент и сервер - Win2003. Проблема в
> том, что клиент находится за NAT'ом (DSL модем), и что-то
> этот нат такого гадкого делает, что не позволяет соединению
> успешно установиться.

Сталкивался, настраивал не сам, а провы. С Микрософтовым ВПН проще, но почти те же геморы. КериоВПН просто лучше, но от сетевых правил не уйти. Не смотря на то, что логически соединение может открываться из внутренней сети, ВПНы, особенно АйПиСек использует безсокетные/безсессионные протоколы. Короче ТиСиПи работает, поскольку пришедший пакет снаружи несет еще и информацию о портике, по которой НАТ может понять куда этот пакет прокинуть во внутреннюю сеть. В случае АйПи такой возможности нет.
Предлагаются варианты:
Самый простой, если есть свободный внешний АйПишник, то на шлюзе настроить мостик ВнешнийАйПи=ВнутреннийАйПи.
Посложнее, нужно настроить прокидывание 50 и 51 протокола и не помню какого-то еще порта, использующегося для синхронизации, обменом сессиоными ключами и еще чем-то на соответствующую машинку внутри.

На новом месте у нас используется нечто среднее - всего один адрес, на модеме проброс этого на адреса на внутренний, всего один сегмент АДСЛ_модем=сервер, у сервера вторая карточка на внутреннюю сеть. КЕРИО работает. АйПиСек мог бы и не заработать, он при бОльшей надежность более требователен, он может потребовать, чтоб шлюз не подменял адрес отправителя.
1




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


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