>>погодите.
>>что мешает сделать следующую схему:
>>НАТ разрешаем всем, какой нужно - или нат, или без ната -
>>вам виднее.
>>а вот пускаем за роутер только тех кого можно - списком доступа
>>на интерфейсе. запись удалили - инет сразу пропал... я про это
>>говорил в предыдущем посте.
>Можно небольшим примерчиком набросать - чтоб мне наглядней было? Если не трудно,
>конечно.
гм.access-list for_nat permit 192.168.0.0 0.0.255.255 any
далее в natе используете этот список доступа
список доступа на интерфейсе:
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
т.е. чел 192,168,1,1 выйдет в инет т.к. его через интерфейс пропустили - никто другой нет. хотя правила ната есть... вот что имелось в виду - банальный ACL на интерфейсе...
он будет работать сразу после применения и отрубать тоже сразу.
>>только это все кривовато ИМХО. если правил/пользователей много - не проще сделать
>>AUTH-прокси или downloaded ACL что бы пользователь авторизовался на циске и
>>его пускало в инет. А вот на радиусе будете решать -
>>авторизовать пользователя сейчас или нет...
>А какая разница - кем авторизовывается пользователь? Или я чего-то не понимаю?
>Ведь главное то, как предоставлется ему инет, т.е. каким образом происходит
>изменение "конфига" циски, чтоба она стала предоставлять трафик для человека.. или
>не стала.
>
>Да, а чем отличается ручное прописывание маршрута для конкретного IP от того,
>что RADIUS говорит кого пускать а кого нет. Т.е. я никак
>не пойму - как Radius это делает. Т.е. как можно обойтись
>без RADUISa, но по сути делая так же, как Raidus -
>запрещаем или пускаем пользователя (без каких-либо subinterfac'ов).
>
>Т.е. честно - хочется уйти от ACL'ов для НАТа, особенно с большим
>кол-вом записей. Хочется как-то красиво.. например (мечтательно): route scr host next-hop
>global-int..
>МОжно ли так реализовать? При чем с условием, что изначально роутинг не
>делается для всех пользовательских айпишников..
гм. завтра скажу.
