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

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

(Различия между версиями)
Перейти к: навигация, поиск
м (Правки OfoPoofo (обсуждение) откачены к версии Victor)
 
(13 промежуточных версий не показаны.)
Строка 1: Строка 1:
-
Недавно передо мной встала задача, организовать более гибкое информирование абонента о причинах безуспешного подключения по VPN к NAS-серверу. Как мы знаем, под ошибкой 691 на клиентском компьютере, скрывается очень много разнообразных ошибок доступа, которые создают дополнительную нагрузку на абонентский отдел. Было решено организовать доступ абонента до информационной странички, на которой ему подробно будет описано причины ошибки и способы ее устранения. Для этого, не смотря на присутствие ошибки необходимо чтобы Radius-сервер биллинга передавал NAS’у разрешение на аутентификацию и также передавал некие атрибуты, с помощью которых ограничивается доступ и обеспечивается перенаправление пользователя на страницу с информацией об ошибке. В моем случае в качестве NAS’а используется Cisco 7301 с настроенным PPPoE-доступом. Для ограничения доступа и перенаправления используются следующие атрибуты:
+
'''В BGBilling версий от 4.6 функционал Reject-To-Accept может быть реализован штатными средствами http://www.bgbilling.ru/v4.6/doc/ch03s09s04.html#d0e8815, однако данный пример более гибок и полезен в качестве наглядного пособия по разработке сложных решений на базе скриптов BGBilling.'''
-
'''Cisco-AV-Pair=”lcp:interface-config=ip wccp web-cache redirect in”''' - обеспечивает прозрачное перенаправление клиентских HTTP-запросов на внешний прокси-сервер.
+
Есть задача организовать более гибкое информирование абонента о причинах безуспешного подключения по VPN к NAS-серверу. Под ошибкой 691 на клиентском компьютере скрывается очень много разнообразных ошибок доступа, которые создают дополнительную нагрузку на абонентский отдел. Необходимо организовать доступ абонента до информационной странички, на которой ему подробно будут описаны причины ошибки и способы ее устранения.
-
'''Cisco-AV-Pair=”ip:inacl=155”''' – обеспечивает запрет доступа ко всем ресурсам сети кроме разрешенных.
+
Для этого, несмотря на фактическую невозможность предоставления доступа (например, из-за нехватки денег), необходимо чтобы RADIUS-сервер биллинга передавал NAS’у разрешение на аутентификацию, а также некие атрибуты, с помощью которых ограничивается доступ клиента и обеспечивается перенаправление его HTTP-запросов на страницу с информацией об ошибке.
-
Прокси-сервер нужен для одной единственной задачи: перенаправление с любого, введенного в браузере, адреса на страничку с описанием ошибки. В качестве прокси-сервера была использована машина с FreeBSD 6.3 и программой OOPS. Также подойдет и Squid или любой другой прокси-сервер, который поддерживает WCCP и условные редиректы.
+
В моем случае в качестве NAS’а используется Cisco 7301 с настроенным PPPoE-доступом. Для ограничения доступа и перенаправления используются следующие атрибуты:
-
Как это выглядит: Например у пользователя неверный MAC-адрес или номер телефона для доступа в интернет. Пользователь запускает VPN-соединение, соединение проходит успешно, пользователь в окне браузера вводит любой сайт и вместо ожидаемого сайта получает страничку оператора, на которой подробно рассказывается о причинах ошибки и действиях, которые необходимо предпринять для ее устранения.
+
'''Cisco-AV-Pair=”lcp:interface-config=ip wccp web-cache redirect in”''' - обеспечивает прозрачное перенаправление клиентских HTTP-запросов на внешний WEB-сервер.
-
Примерный конфиг Cisco:
+
'''Cisco-AV-Pair=”ip:inacl=155”''' – обеспечивает запрет доступа ко всем ресурсам сети кроме разрешенных.
 +
Как это выглядит: Например у пользователя неверный MAC-адрес или номер телефона для доступа в интернет. Пользователь запускает VPN-соединение, соединение проходит успешно, пользователь в окне браузера вводит любой сайт и вместо ожидаемого сайта получает страничку оператора, на которой подробно рассказывается о причинах ошибки и действиях, которые необходимо предпринять для ее устранения. Через 15 минут соединение автоматически разрывается.
 +
 +
Примерный конфиг Cisco:
<pre>
<pre>
 +
ip wccp version 1
ip wccp web-cache redirect-list 111
ip wccp web-cache redirect-list 111
!  
!  
Строка 36: Строка 40:
</pre>
</pre>
-
[[Передача ACCEPT вместо REJECT вместе с доп. аттрибутами]]
+
Для того чтобы заработал WCCP, и NAS знал, куда перенаправлять запросы, я использую самописную программку (wccp-client), которая поддерживает связь с Cisco, отправляя ей нужную информацию по протоколу WCCP. Исходники можно взять [http://forum.bgbilling.ru/download/file.php?id=3637 здесь]. Не забудьте поменять адрес NAS (ROUTER_ADDR) в начале кода.
 +
Компилируется так:
 +
 
 +
<pre>
 +
gcc -o wccp-client -s -O2 wccp_client.c
 +
</pre>
 +
 
 +
Продиагностировать подключение wccp-client с Cisco можно командой:
 +
<pre>
 +
show ip wccp web-cache detail
 +
</pre>
 +
на NAS-е.
-
Примерный конфиг FreeBSD для связки с Cisco по WCCP (Cisco все данные посылает в GRE-тунелле):
+
Все перенаправленные запросы NAS отсылает через GRE-туннель в адрес компьютера, на котором запущен wccp-client, поэтому нужно настроить туннель на компьютере.
 +
Я использую FreeBSD, поэтому для меня эта настройка выглядит так:
'''/etc/rc.local:'''
'''/etc/rc.local:'''
Строка 44: Строка 60:
# 192.168.100.3 – IP прокси-сервера, 192.168.100.2 – IP Cisco.
# 192.168.100.3 – IP прокси-сервера, 192.168.100.2 – IP Cisco.
/sbin/ifconfig gre0 create
/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 192.168.100.3 192.168.100.2 netmask 255.255.255.255 up
/sbin/ifconfig gre0 tunnel 192.168.100.3 192.168.100.2
/sbin/ifconfig gre0 tunnel 192.168.100.3 192.168.100.2
/sbin/route delete 192.168.100.2
/sbin/route delete 192.168.100.2
 +
# 127.0.0.1,3128 - адрес и порт, куда будут направляться запросы клиентов.
/sbin/ipfw add 400 fwd 127.0.0.1,3128 tcp from any to any http via gre0
/sbin/ipfw add 400 fwd 127.0.0.1,3128 tcp from any to any http via gre0
 +
# Блок выше нужно повторить для каждого интерфейса Cisco, на котором установлен IP-адрес,
# Блок выше нужно повторить для каждого интерфейса Cisco, на котором установлен IP-адрес,
-
# т.к. Cisco может произвольно выбрать IP интерфейса, с которого пойдет запрос.
+
# т.к. Cisco может произвольно выбрать IP интерфейса, с которого пойдет запрос. (Точнее
-
/bin/chmod 460 /dev/ipnat
+
# Cisco выберет последний созданный интерфейс в системе, которому присвоен IP)
-
/usr/bin/chown oops:wheel /dev/ipnat
+
# Не забудьте дать разные имена интерфейсам (gre1, gre2 и т.д.)
 +
 
 +
/sbin/ipfw add 350 allow tcp from 192.168.100.3 to any
</pre>
</pre>
-
Примерный конфиг OOPS-прокси-сервера, касательно соединения по WCCP:
+
В качестве HTTP-сервера я использовал nginx + php через fastcgi.
 +
Вот примерная настройка:
-
'''/usr/local/etc/oops/oops.cfg:'''
+
'''/usr/local/etc/nginx/nginx.conf:'''
<pre>
<pre>
-
module redir {
+
worker_processes  3;
-
file /usr/local/etc/oops/redir_rules
+
error_log  /dev/null;
-
template /usr/local/etc/oops/redir_template.html
+
events {
-
mode bounce
+
    worker_connections 100;
-
myport 3128
+
}
}
-
module transparent {
+
http {
-
myport 3128
+
    include      mime.types;
-
broken_browsers MSIE
+
    default_type  application/octet-stream;
-
}
+
    sendfile        on;
-
module wccp2 {
+
    tcp_nodelay    on;
-
         identity      cache.artem-catv.ru
+
    gzip  on;
-
         service-group web-cache
+
    server {
-
 
+
         listen  127.0.0.1:3128;
-
         # Ниже указываем все интерфейсы Cisco
+
         charset windows-1251;
-
         router 192.168.100.2 192.168.0.1
+
         access_log  /dev/null;
 +
         location / {
 +
            root  /usr/local/www/nginx_blackhole;
 +
            index index.html index.htm index.php;
 +
            rewrite ^/(.*) /index.php last;
 +
        }
 +
        location ~ \.php$ {
 +
            fastcgi_pass  unix:/var/tmp/nginx/php5.sock;
 +
            fastcgi_index  index.php;
 +
            fastcgi_param  SCRIPT_FILENAME  /usr/local/www/nginx_blackhole$fastcgi_script_name;
 +
            include        /usr/local/etc/nginx/fastcgi_params;
 +
        }
 +
        location ~ /\.ht {
 +
            deny  all;
 +
        }
 +
        location ~* ^.+.(jpg|jpeg|gif|ico|css|js)$ {
 +
            root  /usr/local/www/nginx_blackhole;
 +
        }
 +
    } 
}
}
</pre>
</pre>
-
'''/usr/local/etc/oops/redir_rules:'''
+
Про настройку fastcgi на nginx можно почитать [http://blog.kovyrin.net/2006/05/30/nginx-php-fastcgi-howto/lang/ru/ здесь].
-
<pre>
+
 
-
http://.* http://error.provider-site.ru/
+
В /usr/local/www/nginx_blackhole кладется index.php, в котором размещен весь код для генерации странички с ошибкой пользователю.
-
</pre>
+
 
 +
В BGBilling нужно настроить передачу нужных атрибутов для инициирования PP(P/TP/OE)-сессии с клиентом:
 +
 
 +
[[Передача ACCEPT вместо REJECT вместе с доп. аттрибутами]]
 +
 
Естественно, вместо WCCP может быть и route-map, вместо Cisco, Linux или FreeBSD. Подгонка решения под конкретные условия остается за читателем.
Естественно, вместо WCCP может быть и route-map, вместо Cisco, Linux или FreeBSD. Подгонка решения под конкретные условия остается за читателем.
Дополнения и уточнения приветствуются.
Дополнения и уточнения приветствуются.
 +
 +
Ссылки по теме:
 +
 +
[http://www.cisco.com/en/US/products/sw/conntsw/ps547/products_configuration_guide_chapter09186a008007f7e3.html WCCP v2 (англ. язык)]
 +
[http://www.unixdoc.ru/index.php?mode=2&podmode=1&arcicle_id=152&theme=Cisco+Oops FreeBSD: transparent proxy Cisco + WCCPv2 + Oops]
 +
[http://www.opennet.ru/base/net/squid_wccp.txt.html Статья по настройке WCCP + squid]
 +
[http://www.opennet.ru/base/net/transparent_proxy.txt.html Прозрачный кеширующий прокси на Linux]
 +
[http://wiki.squid-cache.org/SquidFaq/InterceptionProxy InterceptionProxy (англ. язык)]

Текущая версия на 12:39, 28 марта 2013

В BGBilling версий от 4.6 функционал Reject-To-Accept может быть реализован штатными средствами http://www.bgbilling.ru/v4.6/doc/ch03s09s04.html#d0e8815, однако данный пример более гибок и полезен в качестве наглядного пособия по разработке сложных решений на базе скриптов BGBilling.

Есть задача организовать более гибкое информирование абонента о причинах безуспешного подключения по VPN к NAS-серверу. Под ошибкой 691 на клиентском компьютере скрывается очень много разнообразных ошибок доступа, которые создают дополнительную нагрузку на абонентский отдел. Необходимо организовать доступ абонента до информационной странички, на которой ему подробно будут описаны причины ошибки и способы ее устранения.

Для этого, несмотря на фактическую невозможность предоставления доступа (например, из-за нехватки денег), необходимо чтобы RADIUS-сервер биллинга передавал NAS’у разрешение на аутентификацию, а также некие атрибуты, с помощью которых ограничивается доступ клиента и обеспечивается перенаправление его HTTP-запросов на страницу с информацией об ошибке.

В моем случае в качестве NAS’а используется Cisco 7301 с настроенным PPPoE-доступом. Для ограничения доступа и перенаправления используются следующие атрибуты:

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

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

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

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

ip wccp version 1
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

Для того чтобы заработал WCCP, и NAS знал, куда перенаправлять запросы, я использую самописную программку (wccp-client), которая поддерживает связь с Cisco, отправляя ей нужную информацию по протоколу WCCP. Исходники можно взять здесь. Не забудьте поменять адрес NAS (ROUTER_ADDR) в начале кода. Компилируется так:

gcc -o wccp-client -s -O2 wccp_client.c

Продиагностировать подключение wccp-client с Cisco можно командой:

show ip wccp web-cache detail

на NAS-е.

Все перенаправленные запросы NAS отсылает через GRE-туннель в адрес компьютера, на котором запущен wccp-client, поэтому нужно настроить туннель на компьютере. Я использую FreeBSD, поэтому для меня эта настройка выглядит так:

/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 up
/sbin/ifconfig gre0 tunnel 192.168.100.3 192.168.100.2
/sbin/route delete 192.168.100.2
# 127.0.0.1,3128 - адрес и порт, куда будут направляться запросы клиентов.
/sbin/ipfw add 400 fwd 127.0.0.1,3128 tcp from any to any http via gre0

# Блок выше нужно повторить для каждого интерфейса Cisco, на котором установлен IP-адрес,
# т.к. Cisco может произвольно выбрать IP интерфейса, с которого пойдет запрос. (Точнее
# Cisco выберет последний созданный интерфейс в системе, которому присвоен IP)
# Не забудьте дать разные имена интерфейсам (gre1, gre2 и т.д.)

/sbin/ipfw add 350 allow tcp from 192.168.100.3 to any

В качестве HTTP-сервера я использовал nginx + php через fastcgi. Вот примерная настройка:

/usr/local/etc/nginx/nginx.conf:

worker_processes  3;
error_log  /dev/null;
events {
    worker_connections  100;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    tcp_nodelay    on;
    gzip  on;
    server {
        listen  127.0.0.1:3128;
        charset windows-1251;
        access_log  /dev/null;
        location / {
            root   /usr/local/www/nginx_blackhole;
            index  index.html index.htm index.php;
            rewrite ^/(.*) /index.php last;
        }
        location ~ \.php$ {
            fastcgi_pass   unix:/var/tmp/nginx/php5.sock;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /usr/local/www/nginx_blackhole$fastcgi_script_name;
            include        /usr/local/etc/nginx/fastcgi_params;
        }
        location ~ /\.ht {
            deny  all;
        }
        location ~* ^.+.(jpg|jpeg|gif|ico|css|js)$ {
            root   /usr/local/www/nginx_blackhole;
        }
    }   
}

Про настройку fastcgi на nginx можно почитать здесь.

В /usr/local/www/nginx_blackhole кладется index.php, в котором размещен весь код для генерации странички с ошибкой пользователю.

В BGBilling нужно настроить передачу нужных атрибутов для инициирования PP(P/TP/OE)-сессии с клиентом:

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


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

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

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

WCCP v2 (англ. язык) FreeBSD: transparent proxy Cisco + WCCPv2 + Oops Статья по настройке WCCP + squid Прозрачный кеширующий прокси на Linux InterceptionProxy (англ. язык)

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