Первое предостережение: я не проектировал эту сеть. Большая часть моего недавнего сетевого опыта связана с ASA; Настройка NAT и ACL там довольно проста и понятна. В данном случае инженер, установивший 2911, выбрал именно его, потому что, по его словам, ASA не поддерживал те функции, которые он хотел, - хотя я так и не получил прямого ответа, когда спросил, какие именно функции. В любом случае, я пока застрял с 2911, и настройка ACL совсем не проста.
В качестве пограничного устройства у нас есть маршрутизатор Cisco 2911. NAT настроен и работает нормально. В настоящее время ACL не применяются к внешним или внутренним интерфейсам, поэтому NAT просто «работает». Однако нам нужно предоставить LDAPS на одном из наших серверов общедоступному интерфейсу и ограничить его определенным IP-адресом источника.
Правило NAT для этого - простая часть:
ip nat inside source static tcp 192.168.x.x 636 x.x.x.2x 636 extendable
Но тогда нам нужно ограничить это определенной подсетью, чтобы мы не открывали LDAP миру. И здесь я забираюсь через голову. В тот момент, когда я применяю ACL к интерфейсу, он уничтожает весь трафик, фактически закрывая интерфейс.
ip access-list extended outside-inside
permit tcp x.x.x.x 0.0.15.255 host 192.168.x.x eq 636
interface GigabitEthernet0/1.10
ip access-group outside-inside in
Я пришел к выводу, что, когда к интерфейсу не применяются списки управления доступом, маршрутизатор имеет некоторые неявные правила, разрешающие исходящий трафик и связанный с ним входящий трафик и разрешающие трафик на основе правил PAT. И что, применяя ACL к интерфейсу, я по существу отключаю эти «встроенные» неявные правила, поэтому мне приходится создавать эти правила вручную, чтобы разрешить исходящий трафик и связанный с ним входящий трафик. (Это вообще не то, как это работает на ASA, и прошло 18 лет с тех пор, как я принял CCNA, поэтому ...) Я безуспешно пробовал следующее:
ip access-list extended outside-inside
evaluate ipoutbound
ip access-list extended inside-outside
permit ip any any reflect ipoutbound
interface GigabitEthernet0/1.10
ip access-group inside-outside out
и
ip access-list extended outside-inside
permit ip any any established
но они вообще не работают, и трафик на интерфейсе останавливается.
Я пробовал читать документацию Cisco, но, конечно, она показывает только некоторые основные примеры синтаксиса для создания списков ACL и не совсем понимает, что происходит в этом случае и почему. Если я не применяю к интерфейсу какие-либо ACL, то исходящий трафик работает нормально, и единственный разрешенный входящий трафик связан либо с исходящим сеансом, либо с явным правилом PAT; но это откроет доступ к LDAP для Интернета в целом, и это не так.
Для справки: следующий стандартный acl также применяется глобально.
access-list 10 permit 192.168.x.0 0.0.0.255
Итак, с существующим правилом NAT / PAT ip nat inside source static tcp 192.168.x.x 636 x.x.x.2x 636 extendable, как мне ограничить доступ к этой услуге, не останавливая весь остальной трафик?