А мне вот понадобился ещё один режим поиска сервиса.
Задача: cisco ip subscriber interface
Access-Request выглядит вот так:
Код:
Packet type: Access-Request
Identifier: 88
Authenticator: {8E 77 26 98 05 C3 54 2A 9D D5 AF 06 75 6D 9D DA}
Attributes:
User-Name=nas-port:172.xx.xx.254:0/0/0/1112
NAS-Identifier=195.xxx.0xx.0xx
NAS-Port-Id=0/0/0/1112
User-Password=cisco
Event-Timestamp=1366271067
NAS-IP-Address=195.xxx.xx.xx
NAS-Port=98098
Service-Type=5
Acct-Session-Id=8000000000017F32
NAS-Port-Type=33
cisco-NAS-Port=0/0/0/1112
Identifier: 88
Authenticator: {8E 77 26 98 05 C3 54 2A 9D D5 AF 06 75 6D 9D DA}
Attributes:
User-Name=nas-port:172.xx.xx.254:0/0/0/1112
NAS-Identifier=195.xxx.0xx.0xx
NAS-Port-Id=0/0/0/1112
User-Password=cisco
Event-Timestamp=1366271067
NAS-IP-Address=195.xxx.xx.xx
NAS-Port=98098
Service-Type=5
Acct-Session-Id=8000000000017F32
NAS-Port-Type=33
cisco-NAS-Port=0/0/0/1112
Это то, что присылает циска.
Причём для обычного ip subscriber interface username выглядел бы вот так:
nas-port:195.xxx.xx.xx:0/0/0/1112
где 195.xxx.xx.xx - это NAS-IP-Address.
Но в случае, когда на интерфейсе сконфигурирован VRF, некоторые IOS подставляют management ip в соответствующем vrf.
Вот что у нас на циске:
Код:
Current configuration : 249 bytes
!
interface GigabitEthernet0/0.1112
description ---- ISG IP ----
encapsulation dot1Q 1112
ip vrf forwarding dsi-mgmt
ip verify unicast source reachable-via rx
no cdp enable
service-policy type control IP-ISG-VRF
ip subscriber interface
end
!
interface GigabitEthernet0/0.1112
description ---- ISG IP ----
encapsulation dot1Q 1112
ip vrf forwarding dsi-mgmt
ip verify unicast source reachable-via rx
no cdp enable
service-policy type control IP-ISG-VRF
ip subscriber interface
end
В биллинге в сервисе я указываю только устройство и интерфейс (Gi0/0.1112)
Как мне авторизоваться?
Сейчас я сделал следующее:
- LoginGenerator, который при сохранении сервиса на договоре формирует и прописывает ему логин в виде "nas-port:195.xxx.xx.xx:0/0/0/1112"
- Предобработка в ProtocolHandler-е, которая формирует и устанавливает username, который мне надо
Можно конечно прописать где-то в конфиге устройства все его возможные management ip-шники и генерировать логины учитывая их, но это пфф..
Текущая схема работает, но т.к. мы подменяем приходящий UserName, то при отправке CoA могут возникнуть накладки из-за разных username-ов.
Авторизоваться по порту через соответствующий servSearchMode я не могу, т.к. у меня нет цифрового идентификатора интерфейса. Вместо этого у меня в пакете приходит строковый Nas-Port-Id (не путать с именем интерфейса: viewtopic.php?f=44&t=7694&p=62007#p62007), которого в биллинге вообще в явном виде нет.
Как сопоставлять логины в такой ситуации?
Есть предложение для разработчиков - сделать ещё один режим поиска логина, по произвольному строковому параметру. Аналогично username, но без необходимости подмены стандартного username своим.
Либо сделать опцию
Код:
public static final RadiusPacket.RadiusPacketOption<String> USERNAME= new RadiusPacket.RadiusPacketOption("username");
, которая при поиске по логину будет приоритетнее, но при этом connection.getUserName() будет возвращать стандартный username соединения.
Либо в каком-то виде задавать Nas-Port-Id для интерфейса и сделать воможность поиска сервиса по устройству/интерфейсу через строковый Nas-Port-Id.
Столько вариантов, хочется сделать как можно чище, без костылей
