Неожиданный финт Cisco ASA

    Сегодня с утра неожиданно открыл для себя что-то новое, но не сильно приятное.
    Для кого-то это может быть очевидно, но я, почему-то, раньше не сталкивался. Так что, возможно, кого-то этот короткий пост предостережет от подобных проблем в будущем.

    Есть такая топология (ну, конечно, она совсем не такая, но суть отражает):

    image


    Есть ASA, в частности ASA 5520 с софтом 8.4(4), у которой множество интерфейсов и подынтерфейсов.
    В DMZ «висит» некий вебсервер, слушающий запросы на порту 8443 и доступный, благодаря правилу NAT (см. рисунок) со стороны всех остальных интерфейсов ASA через 443 порт.

    Как-то однажды, вчера вечером, оказалось что интерфейс inside2 (на деле это 802.1q подынтерфейс) нам больше не нужен и его можно удалить.
    Это и было успешно сделано (no interface inside2). Казалось бы — ну удалили один из интерфейсов, и что с того?

    Сегодня с утра, неожиданно обнаружилось что вебсервер стал недоступен для внешнего мира.
    После короткого траблшутинга и осмотра логов, оказалось, что то самое правило трансляции для вебсервера в DMZ почему-то успешно самоликвидировалось.

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

    Т.е. ASA увидела, что некто собирается лишить ее одного из интерфейсов. Осознав это она начала искать, какие правила NAT используют этот интерфейс. Ни одного такого правила она не нашла, но нашла правило, в котором в качестве destination интерфейса был указан any. Ну а так как any включает в себя все интерфейсы, она просто удалила правило целиком.

    Вывод такой: если у Вас в конфиге присутствуют правила трансляции (в моем случае это был Auto Nat, но, что-то мне кажатся, что и Manual Nat даст тот же результат), указывающие в качестве одного из интерфейсов, участвующих в трансляции, ключевое слово any, то после удаления любого из интерфейсов, все такие правила успешно исчезнут.

    Опять же, вероятно где-то об этом написано (я не встретил) но для меня было неожиданностью.
    • +23
    • 31,3k
    • 7
    Поделиться публикацией

    Комментарии 7

      +4
      Вот за что я не люблю асы — это за подобную самодеятельность. Например, если в policy nat (<8.3) нечаянно сделать вместо «permit ip» «permit ip», то она не отвергнет запись, а пропишет ее в ACL, но уберет из конфига привязку ACL к NAT. В итоге — кровь и кишки. Про это неплохо написали в virtualbacon.net/2012/04/13/error-ace-contains-port-protocol-or-deny-removing-nat-configuration/. Сам я такого косяка не допускал, но был свидетелем — то еще зрелище. В более ранних версиях сам ACL удалялся.
        0
        Описка, Вместо «permit ip» «permit tcp».
          +2
          Я не цисковед, но при исправлении "«permit ip» «permit ip»" фразой «Вместо «permit ip» «permit tcp»», мне кажется требуется указание конкретного «permit ip».
            0
            Короче:

            Можно и нужно писать — «permit ip».
            Нельзя писать, иначе граблями по лбу: «permit tcp» и тому подобное.
              0
              Видимо, фраза «вместо «permit ip» «permit ip»» превращается в «вместо «permit ip» «permit tcp»».
          +1
          Подтверждаю, как-то однажды столкнулся с таким, но ввиду огромного количества правил и немалых изменений в конфигурации так и не удалось раскопать в чём дело, просто сразу зафиксировали проблемы с натом и заново накатили всю секцию ната. Теперь причина ясна, огромное спасибо!
            0
            У нас правил тоже хватало, благо что такое, с any, было одно — посему и удалось как-то это скоррелировать.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое