Показать полную графическую версию : [решено] 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 только сейчас подумал. Вот сижу курю гугл на эту тему. Правда про связь с исой опять же ничего нет.
Пробовал ставить Debian и поднимать на нем pptpd, клиенты в лице Windows Server 2003 коннектятся без проблем, а вот иса ругается на пользователя/пароль (их сто раз проверил и перебил). »
Тут проблема в сквозной аутентификации. ISA признает только NTLM.
Base- аутентификация (даже если бы она была) не подходит так как хеши поразному формируются в разных системах
У Debian-клиентов какие режимы шифрования и аутентификации присутствуют?
Для шифрования использую - MPPE.
Для аутентификации - MS-CHAPv2.
Для шифрования использую - MPPE.
1) Для аутентификации - MS-CHAPv2. »
Это для Debian?
2) Для ISA какие свойства выставлены для PPTP?
4) При идентификации используются локальные учетные записи или доменные?
Ага, для Debian. Даже правильнее сказать - для службы pptpd, которая может работать под разными дистрибутивами линукса.
Для ISA выставлена аутентификация только MS-CHAPv2. Протокол pptp. Пользователь и пароль локальные. В качестве домена в настройка соединения ISA указываю внешний ip debian (по аналогии, когда windows машина не в домене, можно указывать ip\username).
kim-aa, а Вы написали, что был опыт использования связки BSD - ISA. С какими проблемами Вы столкнулись? И почему именно BSD, а не Linux? »
Те же самые. Я пробовал IPSec. Соединения нет, как отлаживать - не понятно. Настройки разные.
FreeBSD я лучше знал. Есть Русский хелп (правда обычно от прошлой ветки :)
Система портов, устранаяет проблемы с зависимостями.
Вообще сетевой стек более внятный.
Вообще же, обычно я рекомендую для этих целей сетевые дистрибутивы типа vyatta
http://forum.oszone.net/thread-172176.html
2)Дело в том, что ISA сейчас стоит в центральном офисе. Там созданы достаточно сложные правила доступа в интернет (по пользователям домена, по ип-адресам, разрешения на уровне протоколов и т.п.), плюс ко всему собраны ВПНы со всех филлиалов (получается звезда). »
Вообще, класической схемой является выделение отдельного устройства - VPN-концентратора.
Совмещение фаервола и VPN-концентратора - это по бедности.
Я настойчиво рекомендую, повесить таковой на отдельную "ногу" (сетевую карту) к ISA, и собирать 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-тунеля
--------------------------------------------
А теперь расшифруйте предложение:
А как иса-шлюз узнает, что пакеты от VPN-сервера нужно слать в локальную сеть? »
Из какой сети в какую должен идти пакет для которого нужно прописать правило на ISA?
[Клиент филлиала (отправка для ip-локальной сети офиса)] -> VPN -> {Внутренний ip}[Шлюз]{внешний ip} -> {внешний ip}[ISA офиса]{карта для сервера VPN} -> {внутренний ip VPN-сервера} -> [тут пакет расшифровался и у него адрес назначения - локальная сеть офиса] -> *** путь только на ISA, но физический адрес сервера VPN тоже из подсети офиса, отсюда вопрос - куда дальше идти пакету? Нужно, чтобы он прошел через ISA и попал во внутреннюю сеть офиса.
Из офиса соответственно пакеты должны маршрутизироваться через ISA сервер на VPN-сервер. Опять же, если подсети совпалают, то пакет не выйдет за пределы локально сети офиса.
Надеюсь не сильно перемудрил с описанием?
[Клиент филлиала (отправка для ip-локальной сети офиса)] -> VPN -> {Внутренний ip}[Шлюз]{внешний ip} -> {внешний ip}[ISA офиса]{карта для сервера VPN} -> {внутренний ip VPN-сервера} -> [тут пакет расшифровался и у него адрес назначения - локальная сеть офиса] -> *** путь только на ISA, но физический адрес сервера VPN тоже из подсети офиса, »
Кто сказал?
На рисунке 1 изображено, что VPN концентратор находится в отдельном сегменте 3-го уровня (сети).
Хотя это и не важно.
Даже если, VPN-концентратор находится в общей сети, то все равно будет работать.
На ISA просто прописывается простое правило маршрутизации
route add <внутренняя сеть филиала> <интерфейс VPN-концентратора>
На VPN-концентраторе офиса прописывается
route add <внутренняя сеть филиала> <виртуальный интерфейс>
На VPN-шлюзе филиала прописывается
route add <внутренняя сеть офиса> <виртуальный интерфейс>
На рисунке 1 изображено, что VPN концентратор находится в отдельном сегменте 3-го уровня (сети). »
Это я понял. Просто думал, что адреса там нужно задавать такие же, как в локальной сети. Теперь вроде ясно, что достаточно поиграться с маршрутами, чтоб все заработало. Думаю, чтобы лучше понять, нужно попробовать. Завтра на работе разверну виртуалки по такой схеме и проверю, если что-то непонятно, то сразу всплывет :)
В роли VPN концентратора все таки использую Debian, т.к. в филлиалах планирую его и как шлюз использовать (разделять VPN и шлюз в филлиалах не вижу особой надобности). Как что-то получится/не получится - отпишусь. Если кому-то это интересно, могут потом выложить сюда все конфиги, вдруг кому еще пригодится.
Кстати, если нет требований, что весь филиал должен ходить в центральный офис, то можно использовать стандартного VPN-клиента на рабочей станции. Соответственно у вы можете не мучатся, а просто коннектить Windows c ISA »
Такое требование обязательное. Ради этого все и делается :)
Теперь вроде ясно, что достаточно поиграться с маршрутами, чтоб все заработало. Думаю, чтобы лучше понять, нужно попробовать. Завтра на работе разверну виртуалки по такой схеме и проверю, если что-то непонятно, то сразу всплывет »
Сразу хочется обратить внимание, что задавать вопросы по маршрутизации в этот раздел не стоит, т.к. иса не занимается маршрутизацией этим занимается Windows. :smirk:
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.