ARP авторизация [Документация VAS Experts]

ARP авторизация

Авторизация абонентов со статикой по ARP-запросам является наименее надежным видом L2-авторизации, так как очень зависит от времени жизни записи в ARP-кеше клиента. Время жизни варьируется в очень широких пределах - от 5 минут на Linux-утсройствах до нескольких часов (Cisco). Из-за этого для абонентов, авторизованных по ARP, могут приходить также запросы L3-авторизации.

Советуем не применять ARP-авторизацию, вместо нее рассмотреть возможность использования Радиус VSA VasExperts-L2-User для абонентов со статическими IP-адресами

[СКАТ-7.5+] Режим ARP-авторизации предназначен для решения проблемы статических IP-адресов. Абоненты со статическими IP-адресами не посылают DHCP-запросов, соответственно, СКАТ не может авторизовать таких абонентов по DHCP-запросам. Но статические абоненты периодически посылают ARP-запросы к своему шлюзу. СКАТ может перехватывать такие запросы к шлюзам и отправлять Radius-запрос Access-Request, основываясь на содержимом ARP-запроса.

Включение режима ARP-авторизации производится fastdpi.conf-параметром bras_arp_auth:

  • 0 - ARP-авторизация отключена
  • 1 - режим ARP-авторизации для /30-подсетей
  • 2 - режим ARP-авторизации для шлюза
Авторизация по ARP работает только для локальных автономных систем.

При включенном режиме терминации по автономным системам ARP-авторизация применяется только для таких ARP-запросов, у которых IP-адрес инициатора (sender protocol address) относится к терминируемой автономной системе (с флагами local и term).

Для абонентов со статическим адресом полезно включить режим контроль активности
Авторизация для /30-подсетей

В этом режиме предполагается, что каждый статический IP-адрес находится в своей /30-подсети. При получении ARP-запроса, в котором target protocol address равен шлюзу /30-подсети, СКАТ запрашивает авторизацию у Радиус-сервера для sender hardware address (MAC-адреса источника ARP-запроса).

Авторизация для шлюза

В этом режиме Радиус-запрос авторизации Access-Request посылается, если поле target protocol address содержит адрес шлюза, известный СКАТу (напомним, что адреса шлюзов выделяются из DHCP-ответов и сохраняются в UDR СКАТа).

Формат Radius Access-Request
User-Name = "a0:b1:c2:d3:00:0a"
User-Password = "VasExperts.FastDPI"
Calling-Station-Id = "a0:b1:c2:d3:00:0a"
Acct-Session-Id = "AF620A00D3C2B1A0"
Service-Type = Framed-User
NAS-Identifier = "FastPCRF"
VasExperts-Service-Type = ARP
VasExperts-ARP-SourceIP = 192.168.201.1
VasExperts-ARP-TargetIP = 192.168.1.1

По умолчанию, в качестве атрибута User-Name выступает MAC-адрес источника ARP-запроса (поле sender hardware address). Тот же самый MAC-адрес передается в атрибуте Calling-Station-Id. Для всех пользователей пароль один и тот же и задается fastpcrf.conf-параметром radius_user_password. Не следует рассматривать это поле как пароль абонента, - это пароль системы.

[СКАТ 8.2+] fastpcrf.conf-параметром radius_user_name_arp можно задать, что помещать в атрибут User-Name. Параметр задает список идентификаторов в порядке предпочтения: первый самый предпочтительный, затем - менее предпочтительный. Допустимые значения идентификаторов:

  • mac: User-Name = MAC-адрес источника ARP-запроса в строковом виде «XX:XX:XX:XX:XX:XX»
  • qinq: если сеть QinQ, то User-Name = «outerVlan.innerVlan»
  • ip: User-Name = IP-адрес источника ARP-запроса в виде строки

Примеры:

   # Значение параметра radius_user_name_arp по умолчанию 
   # В этом случае User-Name будет содержать MAC-адрес, так как для ARP он всегда известен:
radius_user_name_arp=mac,qinq
 
   # Для QinQ-сетей можно явно указать, чтобы User-Name содержал значения qinq-тегов
   # В этом случае, если ARP-запрос тегирован outerVlan=100, innerVlan=200, то User-Name = "100.200"
   # для нетегированных ARP-запросов User-Name будет содержать MAC-адрес источника запроса
radius_user_name_arp=qinq,mac

Различить тип авторизации можно по значению VSA-атрибута VasExperts-Service-Type: для ARP-авторизации этот атрибут содержит значение 6 (ARP).

VSA-атрибуты VasExperts-ARP-SourceIP и VasExperts-ARP-TargetIP содержат значения полей sender protocol address (IP-адрес инициатора запроса) и target protocol address (целевой IP-адрес) ARP-запроса.

Access-Request может содержать и другие атрибуты, описанные в L3-авторизации: NAS-Port-Type, NAS-Port (номер VLAN, если есть), NAS-Port-Id (QinQ, если есть) и пр.

Ответ на авторизацию

Если Access-Request авторизован, Радиус-сервер должен вернуть Access-Accept с атрибутом Framed-IP-Address, - авторизованным IP-адресом. Если Framed-IP-Address не равен значению поля sender protocol address (IP-адрес инициатора) ARP-запроса, то такой ARP-запрос считается неавторизованным и СКАТ его дропает. Если Радиус-сервер не смог авторизовать MAC-адрес, то в ответе не должно быть атрибута Framed-IP-Address; в этом случае исходный ARP-запрос также дропается СКАТом.

Помимо Framed-IP-Address, Access-Accept может содержать следующие атрибуты:

  • Framed-IP-Netmask - маска подсети для абонента;
  • Session-Timeout - время действия авторизации в секундах. Если этого атрибута нет - авторизация бессрочна (не рекомендуется)
  • VasExperts-DHCP-Gateway - шлюз абонента

Помимо этих атрибутов, Access-Accept может содержать атрибуты L3-авторизации, задающие свойства абонента: полисинг и подключенные услуги, см. атрибуты L3-авторизации.

Access-Reject обрабатывается аналогично Access-Accept: если есть атрибут Framed-IP-Address, значит, источник ARP-запроса авторизован по MAC-адресу, Access-Reject должен содержать те же самые атрибуты Framed-IP-Netmask, Session-Timeout и VasExperts-DHCP-Gateway, как описано выше, также могут быть заданы reject-атрибуты L3-авторизации.

Примечание: если bras_dhcp_auth_mix=0, то атрибуты L3-авторизации абонента (полисинг и подключенные услуги) не учитываются в Access-Accept/Access-Reject.

Пример ответа Access-Accept:

Framed-IP-Address = 192.168.201.1
Framed-IP-Netmask = 255.255.0.0
Session-Timeout = 14400
VasExperts-DHCP-Gateway = 192.168.1.1
VasExperts-Policing-Profile = "rate_100M"
VasExperts-Service-Profile = "1:test1"
VasExperts-Enable-Service = "9:on"
При указании Session-Timeout следует учитывать, что время жизни записи в ARP cache у разных ОС разное, - от нескольких минут до 4 часов у Cisco iOS. Так как ARP-авторизация призводится только по запроосу абонента к шлюзу, указание слишком малого Session-Timeout может привести к недоступности интернета у абонента: Session-Timeout уже закончился, а ARP-запроса к шлюзу от абонента еще и не было