Close Topic Options

[valja]

QUOTE (FiL @ 20-02-2015, 20:03)

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

Каждая инсталлируемая Management Center имеет свой License Key (саязанный с MAC ID и чем то еще) и все рабочие лицензии генерируются с привязкой к этому ключу. Можеть быть ключ сохранится и такой перенос сработает, но рисковать лицензией не хочется. Иначе Камасутра с запросом новых лицензий и уверениями, что я не использую дупликат центра (они за каждый центр отдельно денежки хотят).

"Внешняя" сеть должна быть также напрямую доступна снаружи, иначе тяжело проверять работу например "Security Intelligence", которая использует базы данных о "плохишах". То есть все равно нужен static NAT наружу и свободный внешний адрес.

Сейчас у меня внешний и внутренний адреса подменены, но они оба в реальных рабочих сетях и я могу тестирвать практически любой трафик в реале. А для замены файервола достаточно убить старый, сменить адреса двух итерфейсов на освободившиеся рабочие, перебросить 3 кабеля остальных внутренних интерфейсов на новы й файервол и создать 3-4 ststic NAT и ФСЕ! Делов ровно на пять минут. Ошибиться тяжело и не надо ничего перезапускать, все идет практически на ходу.

[valja]

QUOTE (valja @ 20-02-2015, 20:54)

А для замены файервола достаточно убить старый, сменить адреса двух итерфейсов на освободившиеся рабочие, перебросить 3 кабеля остальных внутренних интерфейсов на новы й файервол и создать 3-4 ststic NAT и ФСЕ! Делов ровно на пять минут. Ошибиться тяжело и не надо ничего перезапускать, все идет практически на ходу.

А вот тут то я и "ошибился", делов не на 5 минут оказалось. И причина опять этот NAT При переходе ASA 8.2->8.3 не только убрали принудительный NAT (что хорошо), но к сожаленю NAT крупно переделали (что для меня очень плохо )

Дело в том, что из за внутернних интерфейсов нужен статический NAT на внешний адрес внешнего интерфейса (типа доступ извне к серверу). Если делать NAT на внешний интерфейс, но на другой адрес, то все пучком и работает:

CODE

object network dmz_NAT_to_outside subnet 192.168.10.0 255.255.255.0 object network dmz_mailer host 192.168.10.8 object network dmz_mailer-outside host xxx.xxx.xxx.xxx object network dmz_NAT_to_outside nat (dmz,outside) dynamic interface object network dmz_mailer nat (dmz,outside) static dmz_mailer-outside service tcp 3389 3389

Но если пустить NAT на адрес внешнего интерфейса, т.е. заменить последнюю строчку на

CODE

nat (dmz,outside) static interface service tcp 3389 3389

то ругани нет, но пакеты где то зависают. В логе такие строчки (таймаут 30 сек):

CODE

6 Feb 24 2015 12:11:34 213.184.43.215 29888 192.168.10.8 3389 Teardown TCP connection 2472 for outside:213.184.43.215/29888 to dmz:192.168.10.8/3389 duration 0:00:30 bytes 0 SYN Timeout 6 Feb 24 2015 12:11:04 213.184.43.215 29888 192.168.10.8 3389 Built inbound TCP connection 2472 for outside:213.184.43.215/29888 (213.184.43.215/29888) to dmz:192.168.10.8/3389 (213.184.43.218/3389)

На старом файерволе (с ASA) несколько статических натов на внешний интерфейс, на разные адреса, в том числе и на адрес самого интерфейса . конфигурируются все одинаково и работают без проблем.

Вопрос: как на ASA 9.2 сделать статический NAT конкретных портов из внутренних сетей на адрес внешнего интерфеса?

[valja]

Ситуция оказалось чуть интереснее. Статический NAT конкретных портов из внутренних сетей на адрес внешнего интерфеса все же работает. Но работает как то странно. В случае, если к порту на адресе интерфейса обращаться с адреса, НЕ нахожящегося в однй сети с адресом внешнего интерфейса, то все вроде бв работает. Но ксли обращаться из той же сетки, где и сам интерфейс, то соединение тихо зависает (вышеупомянутый таймаут).

Т.е, если адрес внешнего интерфейса 123..123.123.1/24 и изнутри делать статический NAT порта на 123.123.123.1, то для адресов 123.123.123.0/24 это NAT будет недоступен, но будет доступен для всех других адресов. Если же делать статический NAT порта на другой адрес в той же сети (например 123.123.123.2 или 123.123.123.10) то все работает с любого адреса,

Это не есть хорошо, так как на нашем старом файерволе на адресе внешнего интерфейса сидит мейлер это будет очень плохо, если он будет недоступен для устройств из своей же сети.

Как сие лечить???

[FiL]

на самом деле это очень распространенная проблема.
Я с ней многократно встречался на различных софтовых фаерволах. Причем в зависимости от софтовости фаервола проблема или решается просто или решается сложно или не решается совсем. А вот на железных рутерах я с этой проблемой не встречался. Правда с железными решениями я только с домашними встречался.

[FiL]

Ой, перечитал и понял, что неправильно тебя понял.

Обычно проблема возникает с NAT-ом при обращении к внешнему адресу из внутренней сети, а у тебя проблема при обращении из внешней сети, локальной к самому интерфейсу. Тут я даже не представляю с чего вдруг такой косяк. С точки зрения что НАТ-а, что фаервола - внешний он и есть внешний. И проблем быть не должно. Я-бы сказал, что косяк где-то в фаерволе в принципе. Но... дьявол в детялях. И, как я понял, аналогичная конфигурация на старой версии работает. Так что вообще не ясно что и где.

[valja]

QUOTE (FiL @ 25-02-2015, 05:14)

а у тебя проблема при обращении из внешней сети, локальной к самому интерфейсу.

Именно так,

На старом файерволе, где ASA 8.2, такой NAT настраивается очень просто и нет никакой разницы, какой внешний адрес ставится для внутреннего сервера, лишь бы он был в пределах сетки внешнего интерфейса. И у меня большинство таких натов идут именно на адрес интерфейса.

Начиная с ASA 8.3 (у меня 9.2) не только убрали принудительный NAT (что хорошо), но к сожаленю NAT крупно переделали и чего-то там нахимичили. Похоже, что сетка внешнего интерфейса в чем то особенная и в Cisco об этом знают.

Например, в ASDM есть "Configuration > Firewall > Public Servers pane", где легко создать доступ к внутреннему серверу - укажи внутренний интерфейс, адреса (внутренний и внешний) и порт и все будет сделано. Внешний адрес может быть любой (внутри сетки), кроме IP внешнего интерфейса. Если попытаться это сделать, получим ошибку - "адрес перекрывается с адресом внешнего интерфейса". Если же идти в раздел конфигурации NAT, то можно выстаить и внешний интерфейс (но будем иметь вышеозвученные проблемы).

Кстати, попутно выплыла и другая проблема - оказываеьтся, что при обращениях из такого сервера к внешинм серверам в сети внешнего интерфейса тоже есть глюки: например FTP зависает, но работат с адресами вне сетки интерфеса, но SCP работает. Похоже, что с начиная с ASA 8.3, статический NAT на адрес внешнего интерфейса толком не работает (или же требует каких то дополнительных телодвижений, которых я не знаю). Повторюсь, что со старым ASA 8.2 все работает на ура.

[FiL]

ftp в passive mode должен-бы работать. в active - понятно почему не работает,
но почему они так жестко обрубили сеть внешнего интерфейса - это вопрос интересный.

Мне вот что интересно, ты говоришь, что для NAT-а можно указать любой адрес в качестве внешнего (понятно, что из своей сети) кроме адреса на интерфейсе. А где тогда должен быть этот адрес? Нигде? То есть фаервол слушает пакеты в promiscuous mode? странно оно...

[valja]

QUOTE (FiL @ 25-02-2015, 08:06)

ftp в passive mode должен-бы работать. в active - понятно почему не работает, но почему они так жестко обрубили сеть внешнего интерфейса - это вопрос интересный.

"Login prompt" должен быть виден так и так, да и логин должен срабатывать. Просто в "active" я не получу даже листинга. А сейчас после задержки 20-25 получаю сообщение (фтп клиент из досовского промпта)

> ftp: connect :Unknown error number

Причем фтп сервер видит запрос на логин, который через 20-25 секунд умирает. В то же время например ftp.funet.fi работает на ура. И кстати, это фтп обращение никоим образом не связано со статическим NAT - тут работает уже dynamic NAT для всей внутренней сетки. И я не могу обращаться к собственному же фтп серверу во внешней сети! В то же время www, SCP

QUOTE (FiL @ 25-02-2015, 08:06)

Мне вот что интересно, ты говоришь, что для NAT-а можно указать любой адрес в качестве внешнего (понятно, что из своей сети) кроме адреса на интерфейсе. А где тогда должен быть этот адрес? Нигде? То есть фаервол слушает пакеты в promiscuous mode? странно оно...

Не совсем понял вопрос. А по ASA я понимаю так, что по умолчанию ASA слушает только по адресу интерфейса. Если при конфигурации NAT указывается другой адрес, то ASA начинает слушать и по этому адресу. Этот адрес прописывется в правиле/правилах NAT и открывается "на лету" вместе с активацией правила, отдельно его нигде прописывать не надо. Самое забавное, что я могу прописать там вообще любой адрес, например 123.123.123.123 (сообщения об ошибке не будет) и скорее всего он будет слушать по этому адресу. Правда, неясно, как он на такие запросы отвечать будет.

Похоже, что у ASA это весьма обычная практика. У ASA5545-X на Management0/0 интерфейсе по умолчанию активны три адреса - 192.168.1.1, 192.168.1.2 и 192.168.45.45

[valja]

Поигрался я с этими натами. Карина выглядит следующим образом:

Если NAT (PAT), все равно, динамический или статический, делается на свободный адрес в сетке внешнего интрефейса, то все работает как в аптеке.

Если на адрес внешнего интерфейса сделать динамический NAT (доступ внутренней сети наружу) , то все работает при обращении к адресам вне сетки внешнего интерфейса. При обращении к сайтам в сетке внешнего интерфейса работает выборочно - с частью сайтов большинство протоколов не работают, причем эти сайты друг с другом (и другими сайтами) работают без проблем.
На сайте, куда делается соединение, видно, что несколько раз приходит SYN пакет, на что отвечают SYN ACK, который до цели, похоже, не доходит.

Если на адрес внешнего интерфейса сделать статический NAT (доступ снаружи к внутреннему серверу), то все работает, если обращаться из за пределов сети внешнего интерфейса. Если же обращаться из сетки внешнего интерфейса, то в основном не работает (см. предыдущие посты). Возможно, что что-то и работает, но все я не проверял.

Короче: если NAT (PAT), все равно, динамический или статический, делается на адрес внешнего интрефейса, то все работает для сайтов вне сетки внешнего интерфейса, но с сайтами внути этой сетки нерпедсказуемые заморочки.

К сожалению я так и не понял, это фича такая или NAT (PAT), все равно, динамический или статический, на адрес внешнего интрефейса делать нельзя. Или можно, но нужны дополнительные пляски с бубном.

[FiL]

ага, понимаю.
видимо (я тут вместо штатного телепата выступаю) эта хрень при описании правила NAT таки поднимает на внешнем интерфейсе очередной виртуальный интерфейс с этим самым адресом. Но при наличии там еще одного виртуального интерфейса с таким-же адресом система не ругается, а просто впадает в ступор. Ибо там получается два виртуальных интерфейса с одним адресом. И пакеты приходят... а куда хотят - туда и приходят. Но с большей вероятностью на статический, а не на тот, который от НАТ-а. Просто потому, что тот раньше поднят.
Забавная бага. Но, подозреваю, вручную не лечится.

Вопрос, а если система сама вполне себе умная и поднимает интерфейс с нужным адресом в момент описания правила НАТ, то зачем тебе этот адрес поднимать на интерфейсе статически?

[valja]

Я думаю, не совсем так. Если я делаю новый NAT, то я могу указать либо новый адрес, либо сам внешний интерфейс. Если попытаться ввести адрес внешнего интерфейса, выдается ошиба - "address overlapping with address of interface". То есть, новые правила пришиваются либо к существующему объекту (виртуальному интерфейсу) либо нужно предварительно создать новый объект с новым адресом.

И на один и тот же интерфейс/фдрес можно вешать несколько натов, лишь бы порты не перекрывались. Все статические обрабатываются ДО динамических, то есть на том же интерфейсе/адресе может бвть и входящий порт для внутреннего сервера и выход динамического ната всей внутреней сети - входящие пакркты проверяются прежде всго на статический порт.

У меня сейчас все вообще раздельно:
адрес интерфейса вообще не используется.
серверы (разные порты) . статический NAT на АДРЕС-1
внутренняя сеть - динамический NAT на АДРЕС-2

И с виду все работает (полностью еще не проверил). Но стоит использовать для (любого) NAT адрес интерфейса, начинаются заморочки того или другого рода с хостами в сети внешнего интерфейса А на старом ASA на внешнем интерфейсе куча натов (как статических на разные порты, так и динамических от разных внутренних сетей, и все пашет).

[valja]

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

А если подробнее, то это немного удивляет. CSC-SSM использует Trend Micro InterScan for CSC SSM. Анти-спам основан на собственном RBL листе, который дополнен динамичным, т.е. очень бстро меняющимся листом. В дополнение к этому собственный движок распознавания спама с постоянно обновляемыми правилами. Имеются black и white листы как по ИП-адресам так и по e-mail адресам и доменам. Эта система блокирует у нас 2000-2500 спамов в сутки, до меня доходило меньше одного спама в сутки.

ASA FirePOWER Service (Security Intelligence) использует Security Intelligence Feed (Sourcefire Intelligence Feed), где данные (ИП-адреса) обновляются каждые два часа, и лист спамеров только часть фида (там есть еще ботнеты, фишинг, атакеры, malware итд), в дополнение имеются black и white листы по ИП-адресам. Првила с почтовыми адресами и доменами пришлось переводить на почтовый сревер, что слегка увеличило его нагрузку. Слегка смущало малое число спамерских ИП-адресов в фиде (2000-4000) - очень мало по сравнению с RBL листами. Поэтому ожидалось увеличение проходящего спама и предполагалось использование дополнительных RBL листов. Однако роста спама не произошло, хотя по логам за сутки блокируется только 250 сайтов (вместо 2000 у Trend Micro). Trend Micro записывал на "свой счет" и блокировки по почтовым адресам и доменам, которые теперь блокирует сервер, но все равно это не объясняет столь большой разницы в числе блокировок (250 vs 2000). Возможно, что разница в системе регистраци - например, Trend Micro показывает в логе все обращения спамера а Security Intelligence только первое обращение и последуюшие (в течении какого то времени) в лог не записываются.

Как бы то ни было, анти-спам Security Intelligence оказался вполне эффективным, хотя и не является специальной анти-спам системой.