Comments 11
Ох как люди без FMC мучаются
Мое скромное мнение - в enterprise таких решений быть не должно. Ну и давать доступ внутрь сети условно говоря на основе файлика, расположенного на внешнем ресурсе (или у вас git где-то локально поднят?) - это очень плохая идея. Неужели у такого вендора как Cisco нет нормального решения по централизованному менеджменту? Если дело было уже после санкций - тогда еще ладно.
Речь идет про внутренний корпоративный гитлаб, а не файлик на внешнем ресурсе, чем это плохо?
У Cisco есть ISE, но к нему — масса вопросов. Управление политиками там реализовано, мягко говоря, своеобразно.Мы были в похожей ситуации, и дело кончилось заменой VPN-решения.
Вообще же, etnerprise-подход должен выглядеть так: помещаем пользователей в группы AD, и далее все VPN-шлюзы сами на основе членства в группах формируют при подключении пользователя персональные политики доступа. Связка ASA+ISE, PaloAlto, Fortinet — умеют такое в каком-то виде, но, как всегда, «не совсем так как хочется».
Когда я в последний раз видел ISE - он не умел объединять списки из разных групп, то есть если пользователь А состоит в группах А и Б и на каждом из них висит список доступа - он должен получить один список, смерженный из А и Б автоматически. Вот раньше так было нельзя сделать, возможно что-то изменилось.
>помещаем пользователей в группы AD, и далее все VPN-шлюзы сами на основе членства в группах формируют при подключении пользователя персональные политики доступа.
Да, именно так тут всё в итоге и происходит.
Решение: добавляем в конец ACE комментарий с FQDN указанного IP адреса, после чего пишем небольшой скрипт, который будет […]
А почему бы не писать FQDN вместо IP адреса, и резолвить при деплое?
Меня зовут Василий и я сетевой инженер.
Здравствуй Василий!
if len(task.host['commands']) > 0:таких примеров несколько в снипетах, достаточно `if task.host['commands']`: пустой список будет интерперетирован как False. Аналоично `if args.deploy == True:` достаточно `if args.deploy:`.
В этой процедуре можно избежать ветвления:
def download_and_compare_xml(task):
...
if ...станет
def download_and_compare_xml(task):
...
task.host['need_xml'] = task.host['xml_dict'] != task.host['xml_on_device_dict']
# с принтом тоже можно пошаманить - {net: '10.0.1.1/32', fqdn: 'server_1.domain.local.'}
а в чем смысл хранить и адрес и домен? Достаточно домена, который в любом случае резолвим каждый раз в список (несколько А-записей) адресов
Кстати, если уж критиковать код — то надо бы меньше полагаться на словарь task.host и научиться использовать хотя бы локальные переменные. И лучше бы ещё и параметры кроме task тоже использовать…
И тебе здравствуй! :)
Спасибо за комментарий, по последнему: потому что в DNS какого-то адреса может не быть, потому что в ACL адрес первичен и если писать везде FQDN (к хорошему быстро привыкаешь), то это не избваит от проверки соотношений по крону и нужно будет где-то складировать текущей резолвинг (что бы кто-то без доступа на ASA мог увидеть какие именно адреса открыты).
Плюс, если FQDN не отрезолвился, то он отрезолвится в *-запись и это несколько осложнит разбирательство кто что кому открыл. А еще у нас может появится еще какая-нибудь площадка, куда будет инсталлирована такая же ASA с аниконнектом, но о зонах этой площадки наша dns-ручка знать еще не будет.
В общем тут есть своя пачка "но" и в каких-то местах всё равно придется писать ip, так что поле fqdn скорее преследует логику "хочешь что б запись была актуальна - укажи домен".
Как я Anyconnect на GitLab натягивал