Регистрация

Доклады

Готовые решения

Докладчики

Записи мероприятий

Обратная связь

Расширенный поиск

DevCon 11

Вход на сайт:

Альтернативные системы входа

Популярные ключевые слова

Для IT-специалистов

Для разработчиков

Важные ссылки

Построение межфилиальных сетей VPN на основе ISA Server 2006 и FreeBSD MPD5

8,53

Рейтинг доклада:

Главная

Серверные операционные системы Windows

Высокое качество (800*600) | Низкое качество (320*240)

Описание доклада

В докладе подробно показано как построить межфилиальных сетей VPN на основе ISA Server 2006 и FreeBSD MPD5. Это может быть полезно тем организациям которые вынуждены экономить бюджет или интегрировать ранее обособленные подразделения.

Переключиться в Windows Media Player

Ресурсы для дальнейшего изучения

Комментарии пользователей (27)

в начало | 1 | 2 | в конец

Пользователь be-may написал 09.06.2010 в 13:42

Спасибо! Полезно.

Пользователь aphonin@orel.ru написал 09.06.2010 в 15:14

Коротко и ясно. Спасибо!

Пользователь itsmol написал 10.06.2010 в 10:27

Отличный доклад!

Пользователь yuris написал 10.06.2010 в 13:17

Спасибо, пригодиться.

Пользователь Neon81 написал 10.06.2010 в 23:07

Отличный доклад! Доходчиво и со ссылками.

Пользователь avlapko написал 11.06.2010 в 13:46

Спасибо. Содержательно. Метод действительно минимальный по затратам.

Пользователь gichamike написал 11.06.2010 в 16:40

Коротко, ясно, полезно.

Пользователь Konstantin Leontiev написал 14.06.2010 в 23:22

Илья, доклад действительно хороший, но нет пределу совершенства, так что несколько комментариев:
1. Было бы хорошо прокомментировать, обоснование выбора протокола PPTP или любого другого протокола при создании VPN-подключения.
2. Было бы хорошо объяснить слушателям ПОЧЕМУ нужно, чтобы название Site-2-Site VPN соединения совпадало с именем пользователя (тут важно с какой стороны какие названия VPN-соединений и у.з. пользователей), под которым удаленная сторона будет аутентифицироваться при подключении с ее стороны.
3. Всегда, и в вашем конкретном случае, НАСТОЯТЕЛЬНО рекомендуется использовать у.з. с явным указанием домена, в котором размещается аккаунт. В Вашем случае это можно сделать указав UPN-имя или явно вписать имя домена в поле для воода. Если у.з. локальная, то указать имя локального хоста на котором она создана.
4. Рекомендуется для On-Demand интерфейсов создавать Connection Verifier-ы на основе ICMP.
5. Было бы хорошо при анализе настроек PPTP-подключения прокомментировать настройки безопасности соединения (аутентификации и шифрования).
6. Было бы правильно объяснить слушателям, что нельзя использовать оснастку RRAS для настройки свойств VPN/маршрутизации при установленном на сервере ISA 2004/2006/TMG за исключением некоторых ограниченных настроек.

Пользователь uconnect написал 15.06.2010 в 10:21

Константин, большое спасибо за вопросы.
Постараюсь ответить кратко:
1. PPTP реализован как "самый простой". Рассмотрю другие варианты в ч.2 :)
2. из "best practice", в т.ч. собственной, т.к. проще понимать имена «туннельных»пользователей. Со стороны mpd5 также есть возможность переименовать интерфейс с «ng0» на «office-2-filial», но FreeBSD это не требуется. Также в моём примере, в конфиге mpd5 используется параметр «set link max-redial 0». Т.е. в примере mpd5 «звонит» до бесконечности. Если нужно поднимать соединения со стороны ISA – «ноль» нужно заменить на «необходимое количество». Параметры, отвечающие за «приём» mpd5 соединений со стороны ISA – «set iface enable tcpmssfix» и «set ipcp yes vjcomp».
3. В моём случае, на стороне ISA включено «Сопоставление пользователей» с указанием моего домена => вписывать имя домена не требуется. Я не указал эту настройку в докладе. Косяк 
4. «Проверки соединений», в данном случае, не требуются, т.к. см. п.2 («звонит» mpd5)
5. «настройки безопасности соединения» описаны в конфиге mpd5. В докладе не прокомментированы. Согласен.
6. Оснастка RRAS используется при отсутствии ISA/TMG, т.к. любые изменения ISA/TMG «переписывают» настройки RRAS. Согласен. Надо было учесть.

Ещё раз спасибо за комментарии

Пользователь Konstantin Leontiev написал 15.06.2010 в 10:40

#10

:-)

1) отлично, буду ждать.
2) это более важный ммоент и из вашего ответа не очевидно, что:

Cause: A two-way initiated, demand-dial connection is being interpreted by the answering router as a remote access connection.

Solution: In order for the answering router to determine that the incoming call is a router rather than remote access client, the user name of the credentials for the calling router must match the name of a demand-dial interface that is configured on the answering router.

If the incoming caller is a router, the port on which the call was received shows a status of Active and the corresponding demand-dial interface is in a Connected state. If the name of the user name credential for the calling router appears under Remote Access Clients in Routing and Remote Access, then the calling router has been interpreted by the answering router as a remote access client.

For two-way initiated connections, either router can be the calling router or the answering router. The user names and demand-dial interface names must be properly matched. For example, two-way initiated connections would work under the following configuration:

Router 1 has a demand-dial interface called NEW-YORK which is configured to use SEATTLE as the user name when sending authentication credentials.

Router 2 has a demand-dial interface called SEATTLE which is configured to use NEW-YORK as the user name when sending authentication credentials.

This example assumes that the SEATTLE user name can be validated by Router 2 and the NEW-YORK user name can be validated by Router 1.

See also: Demand-dial routing example; Check the status of the port on the answering router; Check the status of the demand-dial interface

http://technet.microsoft.com/en-us/library/cc737009(WS.10).aspx

3) ок. хорошо, что теперь это есть в комментариях.
4) рекомендуется давать возможнность звонить с обоих сторон. для on-demand dial достаточно любого пакета, адресованного в удаленный сайт, чтобы интерфейс поднялся. Однако Connection Verifier-ы нужены в первую очередь для мониторинга соединения. Хотя если канал тарифицируется помегабайтно, это будут дополнительные мегабайты в месяц.
5) Приведите настройки в комментариях к докладу и/или в Notes презентации. Кому надо - найдут.
6) Многие этого не понимают, и большинство проблем с ISA/TMG и RRAS, из-за этого мы видим большое количество проблем у заказчиков.

Почему я некоторым авторам задаю эти вопросы. Причины две:
1) это публичная сцена и рекомендации которые даются тут моногие ассоциируют с вендором и консалтингом. Если что-то не так, страдает репутация продуктов и/или компании.
2) мне важно, чтобы у моих заказчиков мне не приходилось разгребать очевидные проблемы. Одна из целей ТехДейс прививать слушателям "правильные" практики настройки и рекомендации. И избегать сомнительных вариантов решения.

Пользователь uconnect написал 15.06.2010 в 11:12

#11

2) это более важный момент и из вашего ответа не очевидно, что:
Cause: A two-way initiated, demand-dial connection is being interpreted by the answering router as a remote access connection.
Solution: In order for the answering router to determine that the incoming call is a router rather than remote access client, the user name of the credentials for the calling router must match the name of a demand-dial interface that is configured on the answering router.
If the incoming caller is a router, the port on which the call was received shows a status of Active and the corresponding demand-dial interface is in a Connected state. If the name of the user name credential for the calling router appears under Remote Access Clients in Routing and Remote Access, then the calling router has been interpreted by the answering router as a remote access client.
For two-way initiated connections, either router can be the calling router or the answering router. The user names and demand-dial interface names must be properly matched. For example, two-way initiated connections would work under the following configuration:
Router 1 has a demand-dial interface called NEW-YORK which is configured to use SEATTLE as the user name when sending authentication credentials.
Router 2 has a demand-dial interface called SEATTLE which is configured to use NEW-YORK as the user name when sending authentication credentials.
This example assumes that the SEATTLE user name can be validated by Router 2 and the NEW-YORK user name can be validated by Router 1.
See also: Demand-dial routing example; Check the status of the port on the answering router; Check the status of the demand-dial interface
http://technet.microsoft.com/en-us/library/cc737009(WS.10).aspx

[Лисицын] В моём случае:
На стороне Windows: имя пользователя & имя интерфейса совпадают. Если я делаю туннели Windows-Windows (RRAS или ISA всё равно) я называю интерфейсы и пользователей одинаково на обеих сторонах, тем самым 100% реализую рекомендации из вышепредложенной статьи :)
mpd5, в принципе, всё равно как называется интерфейс. Т.е., как только прошла авторизация под именем пользователя и паролем указанными в конфиге + файле mpd.secret, интерфейс считается поднятым.

4) рекомендуется давать возможность звонить с обоих сторон. для on-demand dial достаточно любого пакета, адресованного в удаленный сайт, чтобы интерфейс поднялся. Однако Connection Verifier-ы нужены в первую очередь для мониторинга соединения. Хотя если канал тарифицируется помегабайтно, это будут дополнительные мегабайты в месяц.

[Лисицын] Мониторингом у меня (лично) занимается Zabbix… думаю сравнения функционала Zabbix-CMS будет интересной темой для доклада 

5) Приведите настройки в комментариях к докладу и/или в Notes презентации. Кому надо - найдут.

[Лисицын] Ок. На днях (по мере возможности сделаю). Отпишу в комментариях об обновлении презентации

6) Многие этого не понимают, и большинство проблем с ISA/TMG и RRAS, из-за этого мы видим большое количество проблем у заказчиков.

[Лисицын] Очень этим удивлён! O_O

Почему я некоторым авторам задаю эти вопросы. Причины две:
1) это публичная сцена и рекомендации которые даются тут моногие ассоциируют с вендором и консалтингом. Если что-то не так, страдает репутация продуктов и/или компании.
2) мне важно, чтобы у моих заказчиков мне не приходилось разгребать очевидные проблемы. Одна из целей ТехДейс прививать слушателям "правильные" практики настройки и рекомендации. И избегать сомнительных вариантов решения.
------------------------------------------------------------------------------------------------------
[Лисицын] Уважаемы коллеги! Данных доклад является ИСКЛЮЧИТЕЛЬНО ЛИЧНЫМ видением проблемы и вариантом ее решения АВТОРОМ (т.е. мной, Лисицыным И.), и НЕ ЯВЛЯЕТСЯ рекомендацией и «лучшей практикой» ВЕНДОРА (Microsoft)
------------------------------------------------------------------------------------------------------

Пользователь s.korotkov написал 16.06.2010 в 14:51

#12

Спасибо за доклад.
Полезно было бы нарисовать/описать схему сети с указанием соответствующих адресов серверов/подсетей, интерфейсов. А то не понятно что за ИПишники в примере.

Пользователь uconnect написал 16.06.2010 в 15:17

#13

Рисую схему [если из докладов и конфигов не понятно]
Филиал Центральный Офис

[Сеть филиала] [Сеть ЦО]
[192.168.155.0/24] [192.168.1.0/22]
| |
192.168.155.1 192.168.1.1
| |
============ =============
| FreeBSD | | ISA2006 |
============ =============
| |
192.168.3.4 192.168.3.50
| |
[сеть провайдера] [Сеть провайдера]
| |
------------------------------- [Сеть Интернет] ----------------------------

В реальности – х.х.3.х – это адреса «внешних» интерфейсов.
Подсеть х.х.3.х взята для моделирования.
[:) думаю, моя учительница по ИЗО была бы довольна :)]

Пользователь uconnect написал 16.06.2010 в 15:18

#14

... странно. в поле "добавить комментарий" всё смотрелось ОК

Пользователь uconnect написал 16.06.2010 в 15:23

#15

Описываю текстом:
Сеть филиала (192.168.155.0/24) через шлюз 192.168.1.155 имеет доступ за пределы подсети.
Сеть ЦО (192.168.1.0/22) через шлюз 192.168.1.1 имеет доступ за пределы своей подсети.
FreeBSD (Филиал):
Внутренний интерфейс – 192.168.155.1
Интерфейс, смотрящий «наружу» - 192.168.3.4
ISA 2006 (ЦО)
Внутренний интерфейс – 192.168.1.1
Интерфейс, смотрящий «наружу» - 192.168.3.50
Т.е. ip внутренних интерфейсов обоих серверов являются для рабочих станций «шлюзом по умолчанию»

Пользователь s.korotkov написал 16.06.2010 в 15:24

#16

вот спасибо, на почту тогда можно не отвечать

Пользователь nixnix написал 01.10.2010 в 11:40

#17

Спасибо очень полезная инфа !

Пользователь uconnect написал 01.10.2010 в 12:26

#18

спасибо. Будут вопросы по реализации данного решения- пишите. готов ответить

Пользователь koleban23 написал 22.10.2010 в 15:45

#19

Спасибо, оч. пригодилось