Site-To-Site vpn между ISA 2006 и Linux
 

Привет!

Ребят, подскажите, кто-нибудь делал такое? Оно может работать? Очень нужна помощь. На линуксовых форумах так и не дождался ответов :(

Гетерогенные комбинации крайне тяжелы в развертывании.
Я, честно говоря, не припомню примеров внятной работы:
Пробовал:
Cisco - ISA
BSD - ISA

Рекомендую выделить самую старую, чахлую и никому не нужную машину и поднять на ней Linux VPN-шлюз.
Либо купить две аппартные коробочки D-Link только для этих целей.

Дело в том, что ISA сейчас стоит в центральном офисе. Там созданы достаточно сложные правила доступа в интернет (по пользователям домена, по ип-адресам, разрешения на уровне протоколов и т.п.), плюс ко всему собраны ВПНы со всех филлиалов (получается звезда). Не уверен, что такое нормально можно сделать на линуксе (просто я начинающий в *NIX системах). Иса вполне обеспечивает этот функционал, к тому же она куплена. Не хотелось бы ее выбрасывать. А вот на филлиалы покупать дорогостоящую ису для 10-20 компов в каждом накладно. Вот и появилось желание перевести на Linux, который обеспечит только выход в интернет и связь с офисом по ВПН. Больше от него задач не требуется.

kim-aa, а Вы написали, что был опыт использования связки BSD - ISA. С какими проблемами Вы столкнулись? И почему именно BSD, а не Linux?

VladDV, а, что такое VPN? подозреваю, что это pptp или ipsec.
Linux это умеет.

На данный момент использую pptp для связи между исами. Пробовал ставить Debian и поднимать на нем pptpd, клиенты в лице Windows Server 2003 коннектятся без проблем, а вот иса ругается на пользователя/пароль (их сто раз проверил и перебил). Собственно почему возник вопрос о возможности.

Про IPSec только сейчас подумал. Вот сижу курю гугл на эту тему. Правда про связь с исой опять же ничего нет.

Тут проблема в сквозной аутентификации. ISA признает только NTLM.
Base- аутентификация (даже если бы она была) не подходит так как хеши поразному формируются в разных системах

У Debian-клиентов какие режимы шифрования и аутентификации присутствуют?

Для шифрования использую - MPPE.
Для аутентификации - MS-CHAPv2.

Это для Debian?

2) Для ISA какие свойства выставлены для PPTP?

4) При идентификации используются локальные учетные записи или доменные?

Ага, для Debian. Даже правильнее сказать - для службы pptpd, которая может работать под разными дистрибутивами линукса.

Для ISA выставлена аутентификация только MS-CHAPv2. Протокол pptp. Пользователь и пароль локальные. В качестве домена в настройка соединения ISA указываю внешний ip debian (по аналогии, когда windows машина не в домене, можно указывать ip\username).

Те же самые. Я пробовал IPSec. Соединения нет, как отлаживать - не понятно. Настройки разные.
FreeBSD я лучше знал. Есть Русский хелп (правда обычно от прошлой ветки :)
Система портов, устранаяет проблемы с зависимостями.
Вообще сетевой стек более внятный.

Вообще же, обычно я рекомендую для этих целей сетевые дистрибутивы типа vyatta
http://forum.oszone.net/thread-172176.html

2)Вообще, класической схемой является выделение отдельного устройства - VPN-концентратора.
Совмещение фаервола и VPN-концентратора - это по бедности.
Я настойчиво рекомендую, повесить таковой на отдельную "ногу" (сетевую карту) к ISA, и собирать VPN-тунели на однотипных средствах.

Каюсь, не совсем понял, зачем нужна отдельная сетевая карта на исе для подключения ВПН-сервера?

Смотрите рисунок. Изображены два варианта:
- VPN концентратор в отдельном сегменте
- VPN-Концентратор в общем сегменте

Во-втором случае ISA не сможет контролировать трафик, т.к будет видеть только шифрованную часть.

О, блин. Прикольно. А VPN-концентратор разве может работать с одной сетевой картой? Это как? На карту 2 IP вешать?

А зачем ему вторая карта?

Реально будут существовать следующие интерфейсы:
Физический
Виртуальный IPSec

Будут установлены следующие соединения:

VPN-шлюз филиала <--IPSec--> VPN-шлюз Офиса

Клиент---->[физ. интерфейс]{VPN-шлюз филиала}[Вирт. интерфейс]----->[Вирт.интерфейс]{VPN-шлюз офиса}[Физ.интерфейс] --->Сервер

Кстати, если нет требований, что весь филиал должен ходить в центральный офис, то можно использовать стандартного VPN-клиента на рабочей станции. Соответственно у вы можете не мучатся, а просто коннектить Windows c ISA

Получается, что мне нужно на исе опубликовать порты IPSec моего VPN-сервера, чтобы к нему могли подключиться филлиалы, а на физическом интерфейсе задать ip из подсети офиса. А как иса-шлюз узнает, что пакеты от VPN-сервера нужно слать в локальную сеть? Ведь я не могу прописать маршрут, в котором было бы сказано, что пакеты с адресом назначения из своей подсети пересылать на другой интерфейс. Теперь если клиент по VPNу отсылает пакет в офис допусти на адрес 192.168.1.10, то каким образом пакет с офисного VPN-сервера передастся в локальную сеть?

У вас будет:

Сеть филиала внутренняя
Сеть офиса внутренняя
Сеть (IP) филиала внешний
Сеть (IP) офиса внешний

Не обязательно:
Сеть VPN-тунеля
--------------------------------------------
А теперь расшифруйте предложение:
Из какой сети в какую должен идти пакет для которого нужно прописать правило на ISA?

[Клиент филлиала (отправка для ip-локальной сети офиса)] -> VPN -> {Внутренний ip}[Шлюз]{внешний ip} -> {внешний ip}[ISA офиса]{карта для сервера VPN} -> {внутренний ip VPN-сервера} -> [тут пакет расшифровался и у него адрес назначения - локальная сеть офиса] -> *** путь только на ISA, но физический адрес сервера VPN тоже из подсети офиса, отсюда вопрос - куда дальше идти пакету? Нужно, чтобы он прошел через ISA и попал во внутреннюю сеть офиса.

Из офиса соответственно пакеты должны маршрутизироваться через ISA сервер на VPN-сервер. Опять же, если подсети совпалают, то пакет не выйдет за пределы локально сети офиса.

Надеюсь не сильно перемудрил с описанием?

Кто сказал?
На рисунке 1 изображено, что VPN концентратор находится в отдельном сегменте 3-го уровня (сети).
Хотя это и не важно.

Даже если, VPN-концентратор находится в общей сети, то все равно будет работать.

На ISA просто прописывается простое правило маршрутизации
route add <внутренняя сеть филиала> <интерфейс VPN-концентратора>

На VPN-концентраторе офиса прописывается
route add <внутренняя сеть филиала> <виртуальный интерфейс>

На VPN-шлюзе филиала прописывается
route add <внутренняя сеть офиса> <виртуальный интерфейс>

Это я понял. Просто думал, что адреса там нужно задавать такие же, как в локальной сети. Теперь вроде ясно, что достаточно поиграться с маршрутами, чтоб все заработало. Думаю, чтобы лучше понять, нужно попробовать. Завтра на работе разверну виртуалки по такой схеме и проверю, если что-то непонятно, то сразу всплывет :)
В роли VPN концентратора все таки использую Debian, т.к. в филлиалах планирую его и как шлюз использовать (разделять VPN и шлюз в филлиалах не вижу особой надобности). Как что-то получится/не получится - отпишусь. Если кому-то это интересно, могут потом выложить сюда все конфиги, вдруг кому еще пригодится.

Такое требование обязательное. Ради этого все и делается :)

Сразу хочется обратить внимание, что задавать вопросы по маршрутизации в этот раздел не стоит, т.к. иса не занимается маршрутизацией этим занимается Windows. :smirk:

Когда на сервере стоит ISA, то настройки RRAS трогать нельзя — всё нужно настраивать через ису.

Вот что еще не пойму - в настройках VPN на обеих сторонах нужно прописывать внешние адреса источника и назначения туннеля. Сейчас я для филлиала поставил шлюз и впн-сервер в одном, а в офисе - опубликовал через ISA-шлюз VPN-концентратор, висящий на третьем сетевом интерфейсе. Так вот, в филлиальном VPN-сервер я для пары "источник-получатель" указываю внешние адреса. А вот как быть с офисным концентратором? У него получается адрес получателя внешний, а вот адрес приемника (то бишь его адрес) я не могу указать внешний, т.к. физический интерфейс имеет внутренний адрес. А если я укажу внутренний, скорее всего возникнет несогласованность туннеля...

1) IP адрес VPN-концентратора выводится наружу при помощи NAT (Port/IP Mapping).
Для использования IPSec должна поддерживаться технология NAT traversal

2) С точки зрения маршрутизации VPN концентратор является практически полным аналогом RAS сервера (особенно при работе по ppp), по этому для организации VPN-сети, на нем выделяется отдельный виртуальный IP сегмент/сеть.

В общем поднял туннель на OpenVPN. Пингую по порядку. С клиентской машины филлиала (КФ) шлюз филлиала (ШФ) - проходит. С КФ виртуальный интерфейс филлиала - проходит. С КФ виртуальный интерфейс офисного VPN-хаба - проходит. С КФ физический интерфейс офисного VPN-хаба - проходит. С КФ физ. интерфейс ISA (который подключен к VPN-хабу) - не проходит. В мониторе ISA ошибка "0xc0040014 FWX_E_FWE_SPOOFING_PACKET_DROPPED Denied Connection". В правилах исы разрешено полное подключение для всех сетей. Что не так делаю?

Я понял, откуда ошибка берется. У меня на сетевой интерфейс 192.168.200.1 (DMZ-сеть) приходят пакеты 192.168.10.2 (клиент филлиала после расшифровки VPN-хабом). Естественно иса считает, что адрес подделан. Но вот как обойти эту проблему?

Сам спросил - сам ответил :)

Последнюю проблему решил следующим образом:

1) В сеть DMZ добавил все сети удаленных офисов и сеть VPN
2) Прописал постоянные маршруты на добавленные сети с GW = физ. адрес VPN-хаба.

Сейчас все заработало. Все спасибо. Огромная благодарность kim-aa! Вы мне очень помогли.

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

Конфиги (backup) исы Вы выкладывать можете только нужно убрать из них (перед сохранением) всю конфиденциальную информацию (как то внешние IP, сертификаты, слушатели опубликованных серверов, логины пользователей и т.п.). В качестве учебного материала для виртуальной машины сгодится. :up