Клієнти ISA - Частина 1. Основна конфігурація ISA Server
Основна конфігурація ISA Server.
Примітка:
Всі скріншоти в цій статті зроблені з консолі управління ISA в розширеному режимі (Advanced mode).
визначення:
Auto-detection. Це функція ISA (WPAD), яка дозволяє браузерам Internet Explorer (v 5.0 або вище) налаштовуватися для нормальної роботи з ISA Server.
DNS. Доменні служби імен (Domain Name Services). Служби працюють на комп'ютері, і відповідають на запити з дозволу імен.
GUID. Глобально унікальний ідентифікатор (Globally Unique IDentifier); Це дуже велике число, що гарантує його унікальність. ISA використовує його, щоб визначати різні сторони власної конфігурації.
LAT host. Це комп'ютер, який працює в підмережі, визначеної в LAT. Весь вхідний і вихідний трафік цього комп'ютера транслюється за допомогою NAT через ISA.
Ім'я NetBIOS. см. "Unqualified name".
Record. Це елемент в DNS-зоні, який представляє єдиний елемент, такий як хост, поштовий сервер або сервер в іншій зоні.
Secondary Protocol. Будь-протокол, який використовується додатком, який відрізняється від протоколу, призначеного для створення початкового (первинного) з'єднання через ISA вважається вторинним (Secondary) протоколом.
TTL. Час існування (Time-to-live); показує як довго (в секундах) запис імені може існувати в кеші запитів імен, перш ніж вона повинна бути оновлена.
Unqualified name. Це ім'я хоста без загальноприйнятої форми. Так само відомо як NetBIOS-ім'я або WINS-ім'я.
WINS. Служби Інтернет-імен Windows (Windows Internet Name Services); це служба дозволу імен, схожа на DNS, за винятком того, що вона працює строго з NetBIOS-іменами.
WPAD. Автовизначення проксі Windows (Windows Proxy Auto Detection); функція ISA, яка підтримується Internet Explorer 5.0 або вище. Коли налаштоване правильно, дозволяє IE конфигурироваться динамічно.
Режими роботи ISA:
Cache. Це режим з мінімальними можливостями, тому тільки Web Proxy і, вибірково, служби кешування можуть бути встановлені і запущені. А також, тільки в цьому режимі ISA може працювати з однією NIC ([network interface card] мережевий адаптер). В цьому режимі підтримуються тільки клієнти Web Proxy. Щоб працювати з клієнтами SecureNAT і Firewall для ISA потрібен LAT. Так само, це єдиний режим, в якому не підтримується служба H.323 Gatekeeper
Firewall. Це поєднання служб Firewall і Web Proxy, без служби Web Cache. Всі основні функції ISA підтримуються в цьому режимі, а так само підтримуються всі типи клієнтів. Але для роботи в цьому режимі необхідно як мінімум дві мережевих карти, одна зовнішня, інша внутрішня (LAT).
Integrated. Це найповніший, самий функціональний режим. Web Proxy, Firewall і Web Caching - все разом вони найкращим способом "пережовують" пакети. Відмінність режиму Firewall від цього полягає тільки в службі Web Caching
Клієнти ISA:
Firewall. Це LAT-хост, у якого встановлено програмне забезпечення клієнта ISA Firewall і додаток, що використовує його.
Web Proxy. Це просте звичайна програма (IE або інше Web-додаток) на LAT-хості, яке використовує проксі-запити і порт для доступу в Інтернет.
Конфігурація ISA Server:
Функціональність клієнта ISA в великій мірі залежить від правильного налаштування самого ISA Server. Якщо ISA має проблеми при перетворенні (дозволі) імен або проблеми з доступом в Інтернет, то це відіб'ється і на клієнтах. Перевіряйте ISA неодноразово при установці і настройці. Це спосіб, за допомогою якого можна дізнатися, що змінилося в поведінці ISA і результат ваших останніх дій
Auto Discovery listener. Це основний головний біль для народу, що намагається "посадити" IIS і ISA на один сервер. Тому що не можуть два додатки або сервісу розділяти одні й ті ж ресурси TCP / IP. Від цього виходить "гонка на виживання" і програв просто забороняють. Це так само є джерелом жахливої роботи WPAD.
Перейдіть на закладку Auto Discovery і побачите наступні настройки:
Site and Content Rules. Тут ми можемо контролювати вміст HTTP і FTP, що проходить через сервіс Web Proxy. За визначенням, ISA створює єдине правило "Allow rule", що дозволяє пропускати будь-який запит. Тут можна пограти з заборонами та дозволами, але будьте гранично обережними, тому що можете створити суперечать правила, які зроблять ISA повністю заблокованою.
Protocol Rules. Це лише один з багатьох ділянок контролю за ISA, але найбільш легко проглядається. Самий мінімум, який повинен бути - це дозволені протоколи HTTP і HTTPS для того щоб LAT-хости мали Web-доступ. Там ще багато всяких протоколів, але без цих не можна буде переглядати Web-сторінки. Ви можете подивитися, скільки "протокольних правил" можна використовувати для LAT. Деякі з них мають окремі (нестандартні) визначення.
IP Routing. Наступне, в чому ми переконуємося, що весь трафік SecureNAT-клієнта проходить безперешкодно (звичайно, при належних настройках правил). У ISA є така настройка, звана "Enable IP Routing" (включити маршрутизацію IP), яка відключена за замовчуванням. Коли вона включена, то дозволяє ISA передавати ICMP-трафік (ping) з LAT в Інтернет.
Відкрийте консоль управління ISA і перейдіть до IP Packet Filtering. Правий клік на ньому і виберіть Properties і побачите наступне вікно
HTTP Redirector. Тут ми здійснюємо контроль над усіма (Firewall і SecureNAT)-запит на Web-сервіси. Відкрийте консоль управління ISA: Servers and Arrays => Extensions => Application Filters. Правий клік на HTTP Redirector Filter і виберіть Properties. Перейдіть на закладку Options:
Тут ми можемо визначити як будуть керовані (SecureNAT і Firewall) -кліентскіе Web-запити. Якщо ви хочете насильно пустити всіх користувачів через сервіс Web Proxy, то виберіть Redirect to local Web Proxy service. Ви повинні мати на увазі, що ця опція також надає можливість обійти сервіс Web Proxy якщо той не відповідає. У цей є своя перевага, яке дозволить (SecureNAT і Firewall)-клієнтів залишатися на зв'язку з Інтернет, але так само дозволяє їм обходити фільтрацію Web Proxy.
Send to requested Web Server дозволяє (SecureNAT і Firewall) -кліентскім Web-запитам весь час обходити сервіс Web Proxy. Це усувається використанням браузерних налаштувань проксі для клієнтів SecureNAT і Firewall.
Reject HTTP requests from Firewall and SecureNAT clients дозволяє насильно встановити настройки проксі у користувачів. Ні налаштувань, немає Web.
Local Domain Table. Це дуже важлива інформація як для IE, так і для Firewall клієнта. Кожен домен, вказаний тут може викликати дві речі:
- (Web Proxy і Firewall)-клієнти дозволяють доменне ім'я самостійно (не через ISA сервіс), якщо у них є DNS сервер для запиту.
- Web Proxy клієнти роблять запити навпростець до будь-якого сервера в домені, ігноруючи сервіси ISA.
Name Resolution. Точні настройки IP для ISA сервера дуже важливі. Найменше, ви повинні для ISA надати DNS сервер для дозволу зовнішніх FQDN на вимогу Web Proxy і Firewall клієнтів, і так само ви повинні надати внутрішній DNS сервер для локальної мережі. ISA працює на W2k Server, а W2k воліє DNS, ніж будь-яку іншу систему розпізнавання імен. При використанні розпізнавання імен за допомогою WINS або NetBIOS періодично будуть виникати проблеми. ISA надає свій власний DNS створенням DNS Lookup Packet Filter. Залиште цю опцію включеною, інакше ISA може не змогти вирішувати зовнішні імена коректно
Web Proxy and Firewall DNS cache.
Web Proxy і Firewall служби надають зовсім базові DNS "сервіси", які повністю залежать від DNS-налаштувань, зроблених в конфігураціях IP ISA. Вони будуть вирішувати FQDN-запити для Web і Firewall клієнтів, використовуючи DNS сервера як визначено в конфігурації IP ISA. Помилки в цих настройках створять в дозволі імен великі заворушення для Web і Firewall клієнтів. Перевірте, щоб ISA Server міг вирішувати імена правильно і швидко!
Дійсно цікава річ - це те, що вони мають унікальну можливість ігнорувати TTL, нормально взаємодіє з DNS-записом, отриману від DNS сервера. За визначенням, все записи, утримувані в DNS-кеші Web Proxy і Firewall, мають TTL 6 годин, незалежно від діючого TTL, пов'язаного з записом. Зрозуміло, що не потрібно говорити, що при цьому можуть виникнути заворушення в клієнтському вирішенні імен. Будь-яке, пов'язане з DNS тестування, має виконуватися.
Що можна зробити для цього. є два записи в реєстрі (або в Active Directory для Enterprise-масивів) для кожного сервісу в кожному масиві, які визначають розмір DNS-кешу і TTL. це:
Значення представлені в шістнадцятковому форматі. Калькулятор Windows може їх конвертувати якщо він переключено в режим "scientific". При перекладі вийде, що за замовчуванням розмір кешу 3к байт кожен, що дозволяє кожному записі мати TTL 21,600 секунд (6 годин). Цей спосіб ефективний, щоб зробити дозвіл імен Інтернету дійсно живим для Web і Firewall клієнтів.
- msFPCDnsCacheSize - повідомляє кожному сервісу його обсяг кеша. Якщо це значення = 0, то такий запис в реєстрі ігнорується і сервіс не накопичує імен. Давайте змінимо його на 0. Тепер кожен запит на ім'я від клієнта буде заново дозволений DNS сервером і TTL буде правильним для того запису.
- msFPCDnsCacheTtl - повідомляє кожному сервісу скільки (в секундах) утримувати кожну запис, яку він приймає. Якщо в попередньому записі ви поставите значення, відмінне від нуля, то значення введене тут буде використано. Якщо ж попереднє значення реєстру дорівнює 0, то ЦЕ значення не буде врахована.
Тепер запустіть Web і Firewall сервіси, щоб вони могли застосувати нові настройки.