» Microsoft ISA Server 2006/2004/2000 (Часть III)

Markes
Я использую nnCron http://forum.ru-board.com/topic.cgi?forum=5&topic=2900 , можно использовать любой не большой прокси типа HandyCache, главное порт на нем изменить с 8080

Anik777

Цитата:

А то есть у меня сетка С, а клиенты выходят наружу только под одним адресом (внешнего инт. ISA), подскажите как полечит?

никак, когда включен nat иса транслирует только через один адрес, тот что указан первым на том интерфейсе с которого она шлет пакеты (в банальной конфигурации с внутреним и внешним интерфейсами это будет первый ип на внешнем)

Добавлено:
интересно было бы поглядеть на "NAT pool для VPN соединений", впервые вижу такое на винде особенно )

коллеги!
прошу совета
наша компания входит в большой холдинг, инет нам раздает управляющая компания через свой прокси.
мы сейчас хотим поставить свой прокси (т.к. управляющая компания купила лицензии на MS - то ставить будем ISA), но ИСА нам по большому счету нужна для контроля трафика и чтобы рубить юзерам то что им не положено.
я на виртуалке попробывал поствить ИСА и настроил web chaining - инет ходит, трафик считается, правила работают... НО т.к. получается что инет раздается через два прокси, т.е. через наш и + еще через корпоративный - то заметно упала скорость.
можно ли как нить настроить ИСА чтобы она просто считала трафик и работала на основании правил?

north_crow
Скорость упала из-за виртуального сервера, сам с этим сталкивался

Вопрос такого плана: Иса 2006\2004 тра ля ля ля
1. Как скажем обубликовать сервер (ну например dns) на исе что бы она слушала сразу все ip-шники на всех интерфейсах (а не только на внешнем скажем)? Добавлять что ли правила публикации для всех ip на интерфейсах? Или просто тупо вместо правила публикации зарамсить обычное правило доступа с указанием сети localhost в дестинатион?
2. Скорее философский вопрос: имеем сеть, внутри веб-сервера с реальными ip (при чём все работают на 80 порту и изменить это нельзя - для клиентов всё должно быть в простом формате аля www.ya.ru), соот-но встал вопрос о том как их разместить в совокупности с исой? Вроде в отдельную подсеть не выделить, остаётся организовать DMZ с доступом к сервакам через ису из внутренней сети или вешать на ису разные белые ip и говорить слушать ей их всех с соот-й публикайией на каждом из них веб-серверов (соот-но веб-сервера стоят внутри лана за исой с серыми айпи), что вобщем то как то не есть гуд тоже... У папы шиндлера что-то простенько расписано, кто-н сталкивался с подобной ситуацией?
3. Может ли иса2006 сделлать Site-to-Site VPN с CheckPoint -ом?

north_crow
так вся работа исы заключается в том чтобы работать на основе правил и логировать все )

greenfox
1 публикация для того и нужна чтобы снаружи прокинуть нужный протокол на нужный внутрениий (!!!!) сервак который спрятан за nat и из-за этого его просто так не видно снаружи. если у тебя dns стоит на самой исе то просто обычным правилом разреши доступ к localhost, публикация тут не нужна, иса то всем и так видна.
2 не вижу никакой проблемы, если серваки имеют реальные ип (и за nat не прячутся) то просто обычными правилами разреши доступ снаружи на эти серваки по http и все.
3. а почему бы и нет.

hardhearted
1. Ок, понял. Меня ещё просто смутило что в отношении исы при публикации определяешь протокол как "входящий" а при простом доступе как "исходящий" ииз-за чего некоторая путаница... В юниксе как то логичнее - input, output, forwarding...
2. Проблема в том как роутинг между сетями устроить - у них тогда в нашей локальной сети (серенькой) будут только реальные белые адреса... сооот-но как иса зарутит пакеты на них (у них ip из той же подсети что и у исы на внеш интерфейсе)... На подсети не разбить - нету соот-х адресов...
3. А дока есть?

Есть ISA 2006 с принудительной авторизацией юзеров на прокси. Есть брокерский клиент QUIK, работающий по портам 208, 210 и поддерживающий авторизацию на прокси. Проблема вроде бы известна - ISA не авторизует клиентов по нестандартному SSL порту, решение известно - скриптик isa_tpr.js, добавляющий нужные порты в список туннельных.
НО: скриптик не помог, QUIK выдаёт, что соединение с прокси обрывается по таймауту. То ли скриптик не поддерживает ISA 2006, то ли ещё какая лажа, может кто-нибудь поможет?

greenfox
1. у исы вполне четкая своя терминология. outbound это все обычные протоколы, считается исходящим для источника. inbound это только для публикации, подразумевается что это входящие соединения с точки зрения сети публикуемого исой сервиса, то есть порт слушает уже сама иса и перенаправляет внутрь
2. если сеть не поделишь то через ису ты эти серваки с белыми ип не пропустишь, либо "голышом" в инете выставлять, либо публиковать на разных портах
собственно в чем проблема поделить на две сети, попроси прова разделить и все.
3. любая книжка или хелп по исе, там написано как создавать pptp, l2tp и ipsec между сетями. ipsec как раз в исе и нужен для соединения с "другими", насколько я знаю с циской работает, думаю и чекпоинтом будет.

Добавлено:
Elaniel
ну для начала не авторизация а аутенфикация, это разные слова.
а вообще смотри логи, реально ли этот клиент аутенфикацию проходит, и по каким правилам его отбрасывает.

2. Вот тут собственно ряд вопросов: во-первых иса при создании какой то сети (ещё одной внутренней скажем) просит указать диапазон. У меня в притык получается, т.е. без стандартных адреса подсети и широковещательного - прокатит ли? (просто белых ip впритык по серверам). Во-вторых как будут внутренние клиенты обращаться в этим серверам (они ещё и в домене) так что бы напрямую? прописывать всем routing table с указанием соот-го интерфейса на сервера? Тут бы доки надыбать по организации такой схемы....

Подскажите решение проблемы. Поднят VPN сервер на ISA 2006. Домен. Адреса клиентам раздаются из подсети 10.20.42.0 / 24. Рабочая сеть 10.20.41.0 /24. Адреса раздаются статически. Клиенты нормально вяжутся. Но не видят внутреннюю сеть. Пингуется только ISA интерфейс. Создано правило - Разрешить весь исх. трафик от VPN клиентов во внутренняя и локальный компьютер. В чем можежт быть проблема ? Ощущение что не отрабатывает маршрутизация.

lokiSSE
лог смотрел? И почему правило только во внутреннюю сеть? А назад?

greenfox
В журнале все чисто. СТавил в журнале фильтр по IP. Назад пробовал тоже открыть - разрешить всем по всем протоколам от внутренней к VPN клиентам. Тот же результат. Не пингует вообще сеть 10.20.41.0 /24 Кроме адреса из этой сети ISA сервера. Попробовал сменить подсети для чистоты эксперемента. Сеть для VPN клиентов 10.2.5.0 /24. То же самое. Пингует адрес ISA из сети 10.20.41.0 и адрес ISA из 10.2.5.0. А больше ничего. Если пингуем компьютер по имени с VPN к внутренней то есть разрешенный запрос DNS и все.

lokiSSE

Цитата:

В журнале все чисто

если запросы доходят до исы то по идее как минимум какие-то записи быть должны... + у тебя иса стоит дефолтным гейтвеем для клиентов во внутренней сети?

greenfox
нет, для внутренних не стоит дефолтным. Суть дать внешним клиентам подключающимся по VPN доступ к одному из SQL серверов внутреннего пользования. Вот лог одного из сеансов если поможет hxxp://slil.ru/24772011. Посмотрел log , почему то DNS запросы отправляются на адрес 10.0.4.1 и 10.0.2.1. - dns сервера с первого интерфейся клиента.

lokiSSE

Цитата:

нет, для внутренних не стоит дефолтным.

ну и как внутрение клиенты узнают куда рутить запросы в подсеть 10.20.42.0 / 24 ? Логично что ответные пакеты будут уходить на дефолтный гейт, который не есть иса...

greenfox
Попробовал с DG на иса. Та же песня. Стоял там FWC пробовал и с ним и без. Все равно не работает.

greenfox

Цитата:

Тут бы доки надыбать по организации такой схемы....

какой такой схемы, обычная элементарная 3-leg: external, internal и dmz. совершенно ничего сложного. у тебя есть три подсетки, две реальных и одна виртуальная, external и dmz реальные, internal виртуальная. между internal и external nat, между external и dmz route, между internal и dmz сам решай что больше подходит.
но сеть если делишь должна быть полноценной, то есть сейчас отнято 4 адреса: первый последний, на шлюз прова и собственно иса. если поделишь на две то отдашь еще 3 адреса: первый и последний на вторую подсетку и еще один адрес на dmz интерфейс исы.
а не проще ли отпаблишить эти серваки на разных портах?

Добавлено:
lokiSSE

Цитата:

Адреса клиентам раздаются из подсети 10.20.42.0 / 24. Рабочая сеть 10.20.41.0 /24.

у тебя впн клиенты и внутренняя сетка - есть разные сетки, на клиенте есть маршрут в 41 ю сетку через впн интерфейс? есть network rule между vpn clients и internal ?

hardhearted
Вооот, подошли к тому что мне и не понятно. Сетевое правило есть - VPN клиенты и VPN карантинные клиенты - маршрут - внутренная. Как я понимаю после подключения клиента у него должен прописываться маршрут из его адресного пространства к внутренней сети , и вносить запись ISA через RAS винды и основной шлюз - VPN канал. По крайней мере так должно быть судя по документации.
Таблица до подключения VPN
0.0.0.0 0.0.0.0 10.20.41.3 10.20.41.77     10
10.20.41.0 255.255.255.0 10.20.41.77 10.20.41.77     10
10.20.41.77 255.255.255.255 127.0.0.1 127.0.0.1     10
10.255.255.255 255.255.255.255 10.20.41.77 10.20.41.77     10
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1     1
192.168.11.0 255.255.255.0 192.168.11.1 192.168.11.1     20
192.168.11.1 255.255.255.255 127.0.0.1 127.0.0.1     20
192.168.11.255 255.255.255.255 192.168.11.1 192.168.11.1     20
192.168.64.0 255.255.255.0 192.168.64.1 192.168.64.1     20
192.168.64.1 255.255.255.255 127.0.0.1 127.0.0.1     20
192.168.64.255 255.255.255.255 192.168.64.1 192.168.64.1     20
224.0.0.0 240.0.0.0 10.20.41.77 10.20.41.77     10
224.0.0.0 240.0.0.0 192.168.11.1 192.168.11.1     20
224.0.0.0 240.0.0.0 192.168.64.1 192.168.64.1     20
255.255.255.255 255.255.255.255 10.20.41.77 10.20.41.77     1
255.255.255.255 255.255.255.255 192.168.11.1 192.168.11.1     1
255.255.255.255 255.255.255.255 192.168.64.1 192.168.64.1     1
255.255.255.255 255.255.255.255 192.168.64.1 5     1
Ћб-®ў-®© и«о§: 10.20.41.3

Таблица после подключения

0.0.0.0 0.0.0.0 10.2.5.5 10.2.5.5     1
0.0.0.0 0.0.0.0 10.20.41.3 10.20.41.77     11
10.2.5.5 255.255.255.255 127.0.0.1 127.0.0.1     50
10.20.41.0 255.255.255.0 10.20.41.77 10.20.41.77     10
10.20.41.3 255.255.255.255 10.20.41.77 10.20.41.77     10
10.20.41.77 255.255.255.255 127.0.0.1 127.0.0.1     10
10.255.255.255 255.255.255.255 10.2.5.5 10.2.5.5     50
10.255.255.255 255.255.255.255 10.20.41.77 10.20.41.77     10
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1     1
192.168.11.0 255.255.255.0 192.168.11.1 192.168.11.1     20
192.168.11.1 255.255.255.255 127.0.0.1 127.0.0.1     20
192.168.11.255 255.255.255.255 192.168.11.1 192.168.11.1     20
192.168.64.0 255.255.255.0 192.168.64.1 192.168.64.1     20
192.168.64.1 255.255.255.255 127.0.0.1 127.0.0.1     20
192.168.64.255 255.255.255.255 192.168.64.1 192.168.64.1     20
224.0.0.0 240.0.0.0 10.20.41.77 10.20.41.77     10
224.0.0.0 240.0.0.0 192.168.11.1 192.168.11.1     20
224.0.0.0 240.0.0.0 192.168.64.1 192.168.64.1     20
224.0.0.0 240.0.0.0 10.2.5.5 10.2.5.5     1
255.255.255.255 255.255.255.255 10.2.5.5 10.2.5.5     1
255.255.255.255 255.255.255.255 10.20.41.77 10.20.41.77     1
255.255.255.255 255.255.255.255 192.168.11.1 192.168.11.1     1
255.255.255.255 255.255.255.255 192.168.64.1 192.168.64.1     1
255.255.255.255 255.255.255.255 192.168.64.1 5     1
Ћб-®ў-®© и«о§: 10.2.5.5

hardhearted

Цитата:

обычная элементарная 3-leg

дело в том что у меня DMZ и Internal сейчас суть физически одна и та же подсеть - серваки стоят внутри конторы, на них работают юзвери, они входят в домен и т.д. Всё по марксу так сказать... Далее понадобилось на нек-х из них поднимать www-сервера и выпускать в инет... Вот тут и началось - физически они работают с серыми адресами моей внутренней сети - с контроллерами там, почтовиками и т.д. Выдали мне реальные ip - что делать? Прописать их на реальные сервера? Тогда возникнут проблемы во взаимодействии их с внутренними клиентами наск я понимаю? (ip то у них из разных диапазонов будут и т.д.). Можно бы ло бы конечно вынести их в DMZ за внешний интерфейс исы - но тут опять ряд сложностей, на части машинах физически работают юзвери, как они будут с Д взаимодействовать и т.д.? Так что оставили самый простой вариант - понавешали на внеш интерфейс исы кучу белых ip и прописали кучу паблишинков с одинаковыми портами 80\443 на разные адреса. но тут соот-но свой гемор начился...

lokiSSE
это чьи таблицы то ? исы чтоли? на клиенте маршрут пропишется тока в ту сеть из которой раздаются адреса, клиент понятия не имеет что за исой есть какие то "рабочие" сети в которые тоже надо маршруты вписывать. так что либо на клиенте писать маршрут в рабочую сеть через выданный по впн ип либо ставить на этом впн подключении галку про DG
greenfox
не вижу никаких трудностей, делаешь dmz и internal разными сетями, на разных интерфейсах исы (третий понядобится), проблем с ад не должно быть, как работали так и будут просто ипшники у серваков сменятся и все.

Хм. Перегрузил ISa - один раз соединилось и нормально заработало. Потом снова та же песня. ..

lokiSSE
еще раз говорю, проверь маршруты на клиенте
если диапазон впн клиентов не совпадает с диапазоном внутренней сетки то маршруты просто так не появятся нужные

Спецы, подскажите, пожалуйста, почему-то в последнее время встречается часто в моей сети софт, который не умеет/не хочет аутентифицироваться, не смотря на то, что компьютеры являются одновременно всеми клиентами - ну и файервол клиент установлен разумеется тоже. Вот есть некоторый софт, который ни фига не может аутентифицироваться и всё тут. Подскажите, пожалуйста, как с ним быть? Я вот не совсем понимаю почему некоторый софт Firewall Client не аутентифицирует. Может можно как-то заставить аутентифицироваться?

PIL123
наверно что-н старое досовское типа дипоста? Он винсокс не использует и соот-но fwc с ним работать не может...

greenfox, да нет - софт новый, но просто писал какой-то гавнюк, который недавно научился программить - "создатель" мать его программы. А что надо ему сказать, чтобы он сделал с воей программе какие изменения, чтобы аутентификация проходила нормально?

PIL123
логично предположить что самый простой вариант в этом случае это сказать ему про ису и соот-го клиента к ней и поставить задачу приладить_соот-й_функционал_к_его_софтине\подправить_баги
это в случае если вина лежит именно на софтине и всё остальное с fwc работает нормально
imho

greenfox

Цитата:

приладить_соот-й_функционал_к_его_софтине\подправить_баги

Вот здесь можно подробнее немного, а то я так подозреваю, что там "профи высшего пилотажа" и хотелось бы более разжёвано ему информацию предоставить. Ещё вопрос осложняется тем, что в этом как бы мы больше заинтересованы, а не он.


Цитата:

и всё остальное с fwc работает нормально

Всё остальное работает ОК.

PIL123

Цитата:

Вот здесь можно подробнее немного

ну ты спросил, тут все такие по большей части вовсем не программеры сидят. иди на msdn и смотри как пишутся програмы поддерживающие winsocks

ps кстати а по каким протоколам эта чудопрога работает? возможно ей уже и переделка не поможет )

hardhearted

Цитата:

кстати а по каким протоколам эта чудопрога работает?

80 и 110 порты.