>список доступа на интерфейсе:
>access-list dynamic_access permit 192.168.0.0 0.0.255.255 172.16.0.0 0.0.255.255
>access-list dynamic_access permit host 192.168.1.1 any
нету у меня такого.. :(
Если я правильно понял:ip nat pool p1 xxx.xxx.xxx.111 xxx.xxx.xxx.111 netmask 255.255.255.248
ip nat inside source list 100 pool p1 overload
interface FastEthernet0/1/0
...
ip access-group 156 in
ip nat inside
service-policy output Global
ip route-cache policy
no ip mroute-cache
full-duplex
no cdp enable
end
access-list 100 remark Global-NAT - internet access
access-list 100 permit ip host 10.111.2.3 any
access-list 100 permit ip host 10.111.2.4 any
access-list 100 permit ip host 10.111.4.1 any
.. (для "заначенных" правится именно этот ACL сейчас.. по идее нужно вписать
сюда только одну строчку permit ip 10.0.0.0 0.255.255.255 any и рулить уже именно доступом или роутингом... но как правильнее? так как сейчас изменяется 100-й ACL и он уже довольно большой.. меняется роботом довольно часто)
а доступ для прямый айпишников рулится действительно с списке доступа - 156 у меня:
access-list 156 remark For incoming packets to f1
access-list 156 permit ip host 0.0.0.0 host 255.255.255.255
access-list 156 deny ip any host 255.255.255.255
access-list 156 deny ip any host 10.255.255.255
access-list 156 permit icmp 10.0.0.0 0.255.255.255 any
access-list 156 deny tcp any any range 135 139
access-list 156 deny tcp any any eq 445
access-list 156 permit ip 10.0.0.0 0.255.255.255 any
access-list 156 permit ip host xxx.xxx.xxx.200 any
access-list 156 permit ip host xxx.xxx.xxx.205 any
access-list 156 permit ip host xxx.xxx.xxx.215 any
Соответственно робот прописывает прямые айпишники именно сюда (и выписывает их тоже).
Почему я так не сделал для "заначенных" - потому что помню опыт вешанья такого листа на 1600 циске еще (сейчас 7500) - если список доступа на интерфейса превышал 20 записей - циска загиналась. Поэтому сейчас применяю этот метод только для прямых айпишников - так как кол-во их очень большое.
>т.е. чел 192,168,1,1 выйдет в инет т.к. его через интерфейс пропустили -
>никто другой нет. хотя правила ната есть... вот что имелось в
>виду - банальный ACL на интерфейсе...
>он будет работать сразу после применения и отрубать тоже сразу.
ммм.. ну у тебя он динамический - у меня почему-то нет возможности даже делать их динамическими и, насколько я понял, динамическая запись сама по себе грохается (по какому-то таймауту), что в моем случае не применимо вообще идеологически - само оно не должно грохаться, а именно тогда, когда нужно - вытираться. Я пока не придумал, как это сделать красиво и эффективно :(
>
>
>
>>>только это все кривовато ИМХО. если правил/пользователей много - не проще сделать
>>>AUTH-прокси или downloaded ACL что бы пользователь авторизовался на циске и
>>>его пускало в инет. А вот на радиусе будете решать -
>>>авторизовать пользователя сейчас или нет...
>>А какая разница - кем авторизовывается пользователь? Или я чего-то не понимаю?
>>Ведь главное то, как предоставлется ему инет, т.е. каким образом происходит
>>изменение "конфига" циски, чтоба она стала предоставлять трафик для человека.. или
>>не стала.
>>
>>Да, а чем отличается ручное прописывание маршрута для конкретного IP от того,
>>что RADIUS говорит кого пускать а кого нет. Т.е. я никак
>>не пойму - как Radius это делает. Т.е. как можно обойтись
>>без RADUISa, но по сути делая так же, как Raidus -
>>запрещаем или пускаем пользователя (без каких-либо subinterfac'ов).
>>
>>Т.е. честно - хочется уйти от ACL'ов для НАТа, особенно с большим
>>кол-вом записей. Хочется как-то красиво.. например (мечтательно): route scr host next-hop
>>global-int..
>>МОжно ли так реализовать? При чем с условием, что изначально роутинг не
>>делается для всех пользовательских айпишников..
>
>гм. завтра скажу.
Буду очень признателен.
