Поясню підхід. З моєї точки зору, за забезпечення сеансового, і тим більше транспортного рівня (з точки зору OSI) повинен відповідати не клієнт, а маршрутизатор. У нашому випадку - ISA Server (так, у нас все ще MS ISA). Для клієнта все повинно бути просто і прозоро - відкриваємо сеанс і використовуємо той протокол сервера, який нам необхідний. Що при цьому відбувається на сеансовому і транспортному рівні - не проблема клієнта. Хто, де і що буде перехоплювати, "загортати", кодувати, підписувати - не повинно хвилювати ні клієнта, ні навіть сервер. Іншими словами, ні про які VPN на робочих станціях і замислюватися не слід - і не безпечно, та й софт ставити, ключі видавати співробітниками, а в разі падіння workstation - все це довго переставляти ... Я постараюся привести рішення з мінімальними проблемами для адміністраторів.
Що нам говорить FAQ (ми так робити не будемо :-)):
СБ РФ від нас вимагає організувати захищений канал до їх сервера за допомогою ФПСУ-IP / Клієнта і МСЕ (брандмауера) на їхньому боці, що логічно. Іншими словами, ні клієнт-банк, ні сервер не замислюються про те, хто, що, і як (і де) їх захищає, що й логічно. Але ставити при цьому ФПСУ-IP / Клієнта на робочі станції - це не для нас.
Схема взаємодії представлена на сайті Аміконі:
Автоматичне визначення MTU через ICMP ФПСУ-IP / Клієнт явно виконати не в змозі. За MTU в нашому випадку відповість операційна система з підтримкою автоматичного визначення "чорних дірок" (на них натрапив при організації VPN каналу з іншим банком - ISA не вміє загортати ICMP трафік в створений RRAS вихідний VNP канал, але це тема іншої статті).
Судячи з опису, слід "боятися" наступного: Клієнт встановлює фільтрацію TCP UDP з'єднань (точніше - може встановлювати). Але, так як він реалізований як фільтр, блокувати з'єднання він буде тільки на тих інтерфейси, до яких прив'язаний (bindings). Про це слід пам'ятати в разі мережевих проблем.
Для шифрування використовується рішення ЗКЗІ "Тунель / клієнт", воно вбудовано в ФПСУ IP клієнт. Отже,
Встановлюємо ФПСУ-IP / Клієнт
Встановлюємо клієнта на ISA Server.
Однак, з термінальною сесії ставитися клієнт відмовився геть. Так що будемо пробувати ставити, сидячи за консоллю. А не хотів так ставитися з однієї причини - RDP відвалюється під час установки, так як встановлюється драйвер мережевого рівня.
Локальна установка пройшла штатно. Після цього, природно, потрібно на ISA Server описати IP packet filter, що дозволяє UDP (dynamic) -> UDP (87) send receive.
Після установки піднімається сервіс: "Amicon FPSU-IP / Client service" (Amicon FPSU-IP / Client service for Amicon FPSU-IP) ( "C: \ Program Files \ Amicon \ Client FPSU-IP \ ip-client.exe" RunAsService ). Запуск - автоматичний. Саме цей сервіс відстежує "поява" ключа в USB, і намагається відразу встановити з'єднання.
Чи може «ФПСУ-IP / Клієнт» відновлювати з'єднання при використанні Dial-Up? Так, починаючи з версії 1.42. І мова не тільки про dial-up. При перепідключенні мережевого інтерфейсу теж все в ажурі.
Починаючи з версії 1.42 доступна можливість з'єднатися і роз'єднатися за допомогою командного рядка: ip-client connect і ip-client disconnect (програма вже має бути запущена).
Бачимо новий мережевий фільтр в стекупротоколів (праворуч). Нагадую, на зовнішньому інтерфейсі цей фільтр повинен бути прив'язаний (на зображенні видно, що галка варто), і TCP / IP також. Все інше - одв'язуємо. А на внутрішніх інтерфейсах фільтр Amicon NDIS IM Filter Driver одв'язуємо. P.S. Пізніше ми взагалі відчепися фільтр від всіх інтерфейсів, які нам необхідні для функціонування нашої мережевої інфраструктури і залишимо його прив'язаним тільки до спеціально створеному заради Аміконі інтерфейсу, але про це пізніше.
Запускаємо службу, потім ПО (через меню Аміконі). Отримуємо в результаті щось в system tray. Активуємо додаток.
Детально на налаштуванні зупинятися не буду, в документації докладно. Тільки на особливостях.
Отже, в локальних настройках обов'язково ставимо галку "Пам'ятати введений PIN код, поки VNP-key НЕ від'єднаний". Ми ж не збираємося постійно руками "піднімати" канал, встромили ключ і забули про сервер.
Роз'єдналися і з'єдналися успішно. Пробуємо пінгувати "хост" 213.148.164.75 - все в порядку.
Налаштовуємо ISA Server
Що ще цікаво:
Зверху - клієнт відключений, знизу - включений. Звідси видно, що ICMP трафік, в тому числі і з локальної машини при ФПСУ клієнта, встановленому на isa, чудово загортається в тунель (маршрут стає коротшим, адже трафік "пролітає" ряд маршрутизаторів мережі по тунелю, для нього цей тунель - один hop) .
Icmp трафік, судячи з усього, успішно загортається в тунель.
Сам клієнт зв'язується успішно (ФПСУ ip клієнт), тобто з 87udp проблем немає.
Мабуть, проблеми з tcp трафіком. Причому - після упаковки fwc клієнтом. Звідси: потрібно експериментувати з fwc клієнтом, ftp Командлети і разрешающими правилами на isa.
налаштовуємо FWC
P.S. Можна було б і не уникати, якби ми поставили ФПСУ-IP / Клієнт на маршрутизатор за ISA сервером (скажімо - на зовнішній ISA firewall, вже за DMZ), при цьому на внутрішньому (до DMZ) ніякого ФПСУ-IP / Клієнта. У цій конфігурації і FWC можна було б в спокої залишити.
Дивимося настройки FWC (application.ini) і дописуємо виняток для клієнт-банку:
Звертаю увагу. Налаштування можуть бути як глобальними (через mspclnt) так і специфічними для додатка (wspcfg.ini в каталозі програми). Порядок і пріоритети:
The Firewall Client software looks for a Wspcfg.ini file in the folder in which the client WinSock program is installed. If this file is found, Firewall Client looks for a [WSP_Client_App] section, where WSP_Client_App is the name of the WinSock program without the .exe file name extension. If this section does not exist, Firewall Client looks for the [Common Configuration] section. If this section also does not exist, Firewall Client looks for the same sections in the Mspclnt.ini file. Firewall Client uses only the first section that it finds during this search to apply the program-specific configuration settings.
Зараз створив файл wspcfg.ini з зазначеним вище вмістом в каталозі клієнт-банку поряд з виконуваним файлом. Перезапустив клієнт-банк. Пробуємо зв'язок. Неуспішно. Тому як "клієнт" в даному випадку - в system32. Тому такий варіант конфігурації використовувати не будемо. Будемо пробувати глобальну конфігурацію.
Вніс зміни безпосередньо в консолі ISA. Після цього перезапустив клієнт файрволу (FWC) на машині, сеанс зв'язку клієнт-банку - і все йде.
Але при цьому абсолютно всі пакети (і tcp1024, і tcp21) я бачу в логах Firewall service на ISA.
Додаткові матеріали
Отже, ми забезпечили функціонування клієнт-банку РБ РФ через ФПСУ-IP / Клієнта Аміконі і ISA Server, при цьому не встановлюючи VPN з'єднання з машини, а поклавши всі мережеві тонкощі на ISA хост, що і було потрібно.
Післямова
Історія на цьому не закінчилася ... Про чергові підступи СБ РФ читаємо тут.