Детальное информирование абонентов о причинах ошибки 691

Материал из BiTel WiKi

(Различия между версиями)
Перейти к: навигация, поиск
Строка 1: Строка 1:
-
Недавно передо мной встала задача, организовать более гибкое информирование абонента о причинах безуспешного подключения по VPN к NAS-серверу. Как мы знаем, под ошибкой 691 на клиентском компьютере, скрывается очень много разнообразных ошибок доступа, которые создают дополнительную нагрузку на абонентский отдел. Было решено организовать доступ абонента до информационной странички, на которой ему подробно будет описано причины ошибки и способы ее устранения. Для этого, не смотря на присутствие ошибки необходимо чтобы Radius-сервер биллинга передавал NAS’у разрешение на аутентификацию и также передавал некие атрибуты, с помощью которых ограничивается доступ и обеспечивается перенаправление пользователя на страницу с информацией об ошибке. В моем случае в качестве NAS’а используется Cisco 7301 с настроенным PPPoE-доступом. Для ограничения доступа и перенаправления используются следующие атрибуты:
+
Есть задача, организовать более гибкое информирование абонента о причинах безуспешного подключения по VPN к NAS-серверу. Под ошибкой 691 на клиентском компьютере, скрывается очень много разнообразных ошибок доступа, которые создают дополнительную нагрузку на абонентский отдел. Необходимо организовать доступ абонента до информационной странички, на которой ему подробно будет описано причины ошибки и способы ее устранения. Для этого, не смотря на присутствие ошибки необходимо чтобы Radius-сервер биллинга передавал NAS’у разрешение на аутентификацию и также передавал некие атрибуты, с помощью которых ограничивается доступ и обеспечивается перенаправление пользователя на страницу с информацией об ошибке. В моем случае в качестве NAS’а используется Cisco 7301 с настроенным PPPoE-доступом. Для ограничения доступа и перенаправления используются следующие атрибуты:
'''Cisco-AV-Pair=”lcp:interface-config=ip wccp web-cache redirect in”''' - обеспечивает прозрачное перенаправление клиентских HTTP-запросов на внешний прокси-сервер.
'''Cisco-AV-Pair=”lcp:interface-config=ip wccp web-cache redirect in”''' - обеспечивает прозрачное перенаправление клиентских HTTP-запросов на внешний прокси-сервер.
Строка 84: Строка 84:
Дополнения и уточнения приветствуются.
Дополнения и уточнения приветствуются.
 +
 +
Ссылки по теме:
 +
 +
[http://www.opennet.ru/base/net/squid_wccp.txt.html Статья по настройке WCCP + squid]

Версия 11:16, 8 апреля 2008

Есть задача, организовать более гибкое информирование абонента о причинах безуспешного подключения по VPN к NAS-серверу. Под ошибкой 691 на клиентском компьютере, скрывается очень много разнообразных ошибок доступа, которые создают дополнительную нагрузку на абонентский отдел. Необходимо организовать доступ абонента до информационной странички, на которой ему подробно будет описано причины ошибки и способы ее устранения. Для этого, не смотря на присутствие ошибки необходимо чтобы Radius-сервер биллинга передавал NAS’у разрешение на аутентификацию и также передавал некие атрибуты, с помощью которых ограничивается доступ и обеспечивается перенаправление пользователя на страницу с информацией об ошибке. В моем случае в качестве NAS’а используется Cisco 7301 с настроенным PPPoE-доступом. Для ограничения доступа и перенаправления используются следующие атрибуты:

Cisco-AV-Pair=”lcp:interface-config=ip wccp web-cache redirect in” - обеспечивает прозрачное перенаправление клиентских HTTP-запросов на внешний прокси-сервер.

Cisco-AV-Pair=”ip:inacl=155” – обеспечивает запрет доступа ко всем ресурсам сети кроме разрешенных.

Прокси-сервер нужен для одной единственной задачи: перенаправление с любого, введенного в браузере, адреса на страничку с описанием ошибки. В качестве прокси-сервера была использована машина с FreeBSD 6.3 и программой OOPS. Также подойдет и Squid или любой другой прокси-сервер, который поддерживает WCCP и условные редиректы.

Как это выглядит: Например у пользователя неверный MAC-адрес или номер телефона для доступа в интернет. Пользователь запускает VPN-соединение, соединение проходит успешно, пользователь в окне браузера вводит любой сайт и вместо ожидаемого сайта получает страничку оператора, на которой подробно рассказывается о причинах ошибки и действиях, которые необходимо предпринять для ее устранения. Через 15 минут соединение автоматически разрывается.

Примерный конфиг Cisco:

ip wccp web-cache redirect-list 111
! 
! Направлять все HTTP-запросы на прокси,
! кроме страниц на 192.168.0.37 (там и должна
! быть инф. страничка с подробностями об ошибке).
access-list 111 deny   tcp any host  192.168.0.37
access-list 111 permit ip any any
!
! Разрешить любые HTTP-запросы, TCP-запросы к
! портам биллинга, TCP и UDP-запросы к портам
! DNS-сервера, и соответственно ICMP-запросы на
! машины биллинга и DNS-сервера.
access-list 155 permit tcp any any eq www
access-list 155 permit tcp any host 192.168.0.11 eq 8080
access-list 155 permit tcp any host 192.168.0.11 eq 8443
access-list 155 permit tcp any host 192.168.0.3 eq domain
access-list 155 permit udp any host 192.168.0.3 eq domain
access-list 155 permit icmp any host 192.168.0.11 echo
access-list 155 permit icmp any host 192.168.0.11 echo-reply
access-list 155 permit icmp any host 192.168.0.3 echo
access-list 155 permit icmp any host 192.168.0.3 echo-reply
access-list 155 deny   ip any any

Передача ACCEPT вместо REJECT вместе с доп. аттрибутами

Примерный конфиг FreeBSD для связки с Cisco по WCCP (Cisco все данные посылает в GRE-тунелле):

/etc/rc.local:

# 192.168.100.3 – IP прокси-сервера, 192.168.100.2 – IP Cisco.
/sbin/ifconfig gre0 create
/sbin/ifconfig gre0 192.168.100.3 192.168.100.2 netmask 255.255.255.255 link2 up
/sbin/ifconfig gre0 tunnel 192.168.100.3 192.168.100.2
/sbin/route delete 192.168.100.2
/sbin/ipfw add 400 fwd 127.0.0.1,3128 tcp from any to any http via gre0
# Блок выше нужно повторить для каждого интерфейса Cisco, на котором установлен IP-адрес,
# т.к. Cisco может произвольно выбрать IP интерфейса, с которого пойдет запрос.
/bin/chmod 460 /dev/ipnat
/usr/bin/chown oops:wheel /dev/ipnat

Примерный конфиг OOPS-прокси-сервера, касательно соединения по WCCP:

/usr/local/etc/oops/oops.cfg:

module redir {
	file /usr/local/etc/oops/redir_rules
	template /usr/local/etc/oops/redir_template.html
	mode	bounce
	myport  3128
}
module	transparent {
	myport		3128
	broken_browsers	MSIE
}
module wccp2 {
        identity      cache.provider-site.ru
        service-group web-cache

        # Ниже указываем все интерфейсы Cisco
        router  192.168.100.2 192.168.0.1
}

/usr/local/etc/oops/redir_rules:

http://.*		http://error.provider-site.ru/

Естественно, вместо WCCP может быть и route-map, вместо Cisco, Linux или FreeBSD. Подгонка решения под конкретные условия остается за читателем.

Дополнения и уточнения приветствуются.

Ссылки по теме:

Статья по настройке WCCP + squid

Личные инструменты