Добрый день уважаемые! Взываю к великим умам Цискарей и иже с ними.
Нужно организовать очень на мой взгляд хитрую схему сетевого доступа, либо иметь полное понимание того что так сделать совершенно нельзя.
Итак, есть cisco ASA. Схема чуть продвинутее классической. 4-ре интерфейса — inside, outside, DMZ1 и DMZ2. Хосты из DMZ1 и DMZ2 ходят в Интернет предварительно статически натируясь. То есть им доступен Интернет, Интернету доступны они.
Есть хост в DMZ1 с внутренним адресом, ну к примеру, 172.16.1.10, он статически снатирован в 66.66.66.66. Есть хост в DMZ2 с внутренним адресом 192.168.2.50, он статически снатирован в 77.77.77.77. То есть адреса из «разных DMZ» натируются в белые адреса из разных подсетей. Эти подсети снаружи роутит роутер (не ASA — роутер за outside интерфейсом).
Внимание вопрос — можно ли реализовать доступ так, чтобы с Интернета эти два хоста по прежнему прекрасно виделись по указанным белым адресам, но при этом и друг с другом могли взаимодействовать по ним — то есть 66.66.66.66 <--> 77.77.77.77?
Я прекрасно понимаю что для таких задач надо использовать DNS и не заморачиваться, но всё же надо попробовать без DNS.
Я интуитивно понимаю что так нельзя — ASA просто не сможет завернуть трафик по такой схеме, просто исходя из принципа функционирования фундаментальных технологий (роутинга и NAT).
Но может всё таки можно средствами cisco это реализовать? М.б. хитрые какие роут-мапы?
И если можно, то можно ли всё это реализовать если внешние адреса юзаются из одного диапазона?
Не совсем. Пакет может снатиться, уйти в outside (как велит таблица маршрутизации для этого префикса или для 0/0), отскочить обратно от провайдерского (или своего) роутера (так как в таблице маршрутизации все пути ведут назад), снова снатиться и попасть в цель. Немного коряво, но работать будет. Ну и какое еще есть железо?
Другая безумная идея. Статические маршруты на асашке для 6.6.6.6/32 и 7.7.7.7/32 в соответствующие интерфейсы DMZ1 и DMZ2, а также прописать вторичные адреса на адаптерах серверов. Это взаимодействие записать в nat0, чтобы не натило. Навскидку — может сработать, но надо тестировать.
Хм, то есть получается что в описанной схеме всё должно работать по умолчанию? Единственное что нужно чтобы ASA однозначно знала что пакеты например с dest 66.66.66.66 нужно отправлять в сторону роутера. По идее в моём случае ASA итак отправит их в сторону роутера, ибо туда 0/0 ведёт.
Мне такая мысль даже в голову не приходила что всё и так должно работать :) Наверное потому что оно не работает. packet-tracer АСы дропает пакеты с Drop-reason: (sp-security-failed) Slowpath security checks failed
.
Железо другое может и есть, но аппаратные изменения в схеме включения не представляются возможным :(
то есть получается что в описанной схеме всё должно работать по умолчанию?
Ключевой момент выделен жирным.
Единственное что нужно чтобы ASA однозначно знала что пакеты например с dest 66.66.66.66 нужно отправлять в сторону роутера.
Чтобы маршрут на что-либо включающее эту сеть смотрел в сторону outside.
По ошибке:
Slowpath security checks failed:
This counter is incremented and packet is dropped when the security appliance is:
1) In routed mode receives a through-the-box:
— L2 broadcast packet
— IPv4 packet with destination IP address equal to 0.0.0.0
— IPv4 packet with source IP address equal to 0.0.0.0
2) In routed or transparent mode and receives a through-the-box IPv4 packet with:
— first octet of the source IP address equal to zero
— source IP address equal to the loopback IP address
— network part of source IP address equal to all 0's
— network part of the source IP address equal to all 1's
— source IP address host part equal to all 0's or all 1's
3) In routed or transparent mode and receives an IPv4 or IPv6 packet with same source
and destination IP addresses
Нет ли ошибки в конфигурации NAT? Можно ли увидеть полный вывод packet-tracer detail (включая его вызов)?
Ну и так как я не в курсе радиуса кривизны ваших рук — обязан предложить проверить в packet-tracer доступность любого другого хоста в outside, связь с которым заведомо разрешена и работает. Например, ввести ту же команду, заменив второй адрес на 1.1.1.1 (если ACL разрешает выход в any). Если и тут будет ошибка, то надо правильно вызвать packet-tracer…
Да, действительно радиус кривизны видимо выше нуля :(
Такая ошибка возникает когда я пытаюсь запустить пакет трейсер на эмуляцию доступа к «самому себе». Если в dest указывать другой ip, то всё ок
Дмитрий, в любом случае спасибо за помощь! Буду пробовать варианты
А трансляция на outside идет в адрес интерфейса? С такой схемой не пробовал, но криминала не вижу.
В любом случае, имеет смысл сделать capture на outside и посмотреть, уходят ли пакеты наружу. Может, packet-tracer глючит? Ну и логи посмотреть — создаются ли коннекты.
У меня к собственному интерфейсу (из inside в outside) последний шаг:
Phase: 7
Type: ROUTE-LOOKUP
Subtype: output and adjacency
Result: ALLOW
Config:
Additional Information:
found next-hop 0.0.0.0 using egress ifc identity
adjacency Active
next-hop mac address 0000.0000.0000 hits 31771172
К соседнему адресу:
Phase: 10
Type: ROUTE-LOOKUP
Subtype: output and adjacency
Result: ALLOW
Config:
Additional Information:
found next-hop 9.9.9.9 using egress ifc outside
adjacency Active
next-hop mac address 001b.54с1.5203 hits 1
Извиняюсь, я видимо не правильно выразился в предыдущем комменте.
Packet-tracer показывает всё норм в описанной мною схеме.
Просто когда первый раз проверял в качестве Source указал 172.16.1.10, а в качестве Dest 66.66.66.66 (то есть тот адрес в который 172.16.1.10 собственно и транслируется), отсюда и Slowpath security checks failed.
Не, не пашет.
На ASA: Global 66.66.66.66 Local 172.16.1.10 Global 77.77.77.77 Local 192.168.2.50
Доступы:
на DMZ1 — ip host 172.16.1.10 any
на outside ip any host 77.77.77.77
packet-tracer packet-tracer input DMZ1 tcp 172.16.1.10 1000 77.77.77.77 1000 всё ок
packet-tracer packet-tracer input oitside tcp 66.66.66.66 1000 77.77.77.77 1000 всё ок
Маршруты на роутере который за outside ведут обратно на АСУ.
В общем всё вроде ок, но по факту трафик не ходит.
Не может ли ASA принимать это за какой-нить род спуффинга по своей хитрой логике? Может ли влиять на схему то, что у самой АСы на outside интерфейсе стоит 66.66.66.1 к примеру (в общем из того же диапазона)?
Я понял. Спасибо. Мне этого и нужно было, мол, «работать будет, у меня такая схема не работает».
Почему у меня не работает — буду разбираться.
Будем считать это ответом
Если все хосты в DMZ1/2 имеют назначенные публичные ip, то зачем натить? Убрать нат, сделать маршрут и будут бегать пакеты напрямую между хостами, согласно acl. Другой вопрос — если хостам в разных ДМЗ нужно взаимодействовать напрямую, то может их нужно поместить в один ДМЗ?
Вообще, это была у меня самая первая идея — отказаться от NAT в этой схеме вообще.
Сеть строилась за долго до меня, и какими соображениями была вызвана потребность в NAT я не знаю. Сейчас переделать всё на роутинг будет очень сложно. Очевидно придётся строить костыли типа «тут роутинг, тут NAT»
На другой вопрос ответ — ну так нужно :)
Я понимаю что в идеале всё должно быть не так как есть, но работать приходится с тем что есть
На самом деле, описанная выше схема с рикошетом пакета от внешнего роутера работает. У нее есть недостаток: неоптимальный путь следования трафика. Является ли это проблемой? Не факт, зависит от объемов трафика. Особых костылей нет, у большинства такая схема уже работает «нечаянно», никакой отдельной конфигурации обычно не требуется.
Но да, если системы должны постоянно обмениваться трафиком, правильнее научить их видеть друг друга по внутренним адресам. Только это тоже может потребовать множества костылей…
Простой
Простой
