Похоже, что SessionID MikroTik для аутентификации через RADIUS сбрасывается при перезагрузке, и поэтому не может считаться уникальным идентификатором внутри одного устройства. К тому же стартовое значение SessionID не уникально между разными роутерами, из-за чего могут возникать коллизии идентификаторов сессий у совершенно разных устройств. Это время от времени вызывает проблемы с нашей RADIUS-базой, которая создаёт дублирующиеся записи.
Корень проблемы в сетевых сбоях, из-за которых пакеты подтверждения не доходят до MikroTik. Роутер не знает, что пакет уже достиг базы, поэтому пытается отправить его повторно, что в некоторых случаях создаёт дубликат записи, а не обновляет существующую.
RADIUS также генерирует свой собственный “AcctUniqueID”, однако он тоже не является глобально уникальным! По умолчанию он формируется на основе MikroTik SessionID и нескольких других элементов, но поскольку уникальность этих элементов не гарантирована, весь ID не может считаться глобально уникальным. Усиливает проблему и то, что «уникальный» ID RADIUS — это MD5-хеш. К сожалению, возможно (хоть и с небольшой вероятностью) получить одинаковые MD5-хеши от совершенно разных данных!
В MikroTik и на стороне RADIUS-сервера есть несколько тайминговых параметров, которые я настраивал максимально эффективно, но полностью избавиться от проблем не удалось. Дело в том, что значения на сервере глобальные, и приходится искать компромисс. У нас на линиях сильно варьируется задержка из-за использования спутникового соединения и перегруженных xDSL DSLAM. Найти значения, которые подходят для всех случаев, сложно.
Было бы здорово, если бы MikroTik сделал SessionID действительно уникальным — например, генерировал стартовое значение, используя несколько параметров, уникальных для конкретного роутера, и сохранял его в NVRAM, чтобы после перезагрузки его можно было восстановить. Единственная оставшаяся проблема — замена роутера. Если не будет способа вручную ввести стартовое значение SessionID, снова могут появиться дубликаты.
Сейчас я рассматриваю возможность использовать поле Location ID в RADIUS (RADIUS WISPr-Location-ID), чтобы передавать серверу значение, гарантированно уникальное в глобальном масштабе. В него будет входить уникальный RouterID и счётчик, увеличивающийся скриптом при каждой перезагрузке роутера. Это значение в сочетании с SessionID на сервере должно обеспечить глобально уникальный идентификатор сессии, который можно будет использовать в базе данных с индексом SessionID и уникальным ограничением.
Мне было бы интересно узнать, сталкиваются ли другие с дублирующимися записями в своих RADIUS-базах и какие меры, если таковые есть, они принимали для устранения или хотя бы смягчения этой проблемы.
Корень проблемы в сетевых сбоях, из-за которых пакеты подтверждения не доходят до MikroTik. Роутер не знает, что пакет уже достиг базы, поэтому пытается отправить его повторно, что в некоторых случаях создаёт дубликат записи, а не обновляет существующую.
RADIUS также генерирует свой собственный “AcctUniqueID”, однако он тоже не является глобально уникальным! По умолчанию он формируется на основе MikroTik SessionID и нескольких других элементов, но поскольку уникальность этих элементов не гарантирована, весь ID не может считаться глобально уникальным. Усиливает проблему и то, что «уникальный» ID RADIUS — это MD5-хеш. К сожалению, возможно (хоть и с небольшой вероятностью) получить одинаковые MD5-хеши от совершенно разных данных!
В MikroTik и на стороне RADIUS-сервера есть несколько тайминговых параметров, которые я настраивал максимально эффективно, но полностью избавиться от проблем не удалось. Дело в том, что значения на сервере глобальные, и приходится искать компромисс. У нас на линиях сильно варьируется задержка из-за использования спутникового соединения и перегруженных xDSL DSLAM. Найти значения, которые подходят для всех случаев, сложно.
Было бы здорово, если бы MikroTik сделал SessionID действительно уникальным — например, генерировал стартовое значение, используя несколько параметров, уникальных для конкретного роутера, и сохранял его в NVRAM, чтобы после перезагрузки его можно было восстановить. Единственная оставшаяся проблема — замена роутера. Если не будет способа вручную ввести стартовое значение SessionID, снова могут появиться дубликаты.
Сейчас я рассматриваю возможность использовать поле Location ID в RADIUS (RADIUS WISPr-Location-ID), чтобы передавать серверу значение, гарантированно уникальное в глобальном масштабе. В него будет входить уникальный RouterID и счётчик, увеличивающийся скриптом при каждой перезагрузке роутера. Это значение в сочетании с SessionID на сервере должно обеспечить глобально уникальный идентификатор сессии, который можно будет использовать в базе данных с индексом SessionID и уникальным ограничением.
Мне было бы интересно узнать, сталкиваются ли другие с дублирующимися записями в своих RADIUS-базах и какие меры, если таковые есть, они принимали для устранения или хотя бы смягчения этой проблемы.
