Два телефони, один профіль і картина, що здається надприродною, доки хтось не подивиться на шлюз. Один пристрій тримає тунель, другий підключається, і перший втрачає його за секунди. Перший перепідключається, другий відпадає. Звинувачують економію батареї, роумінг Wi-Fi і NAT оператора, а справжня причина сидить у текстовому полі, скопійованому разом з усім іншим. IKEv2 ідентифікує peer за іменем, і обидва телефони пред'являють те саме ім'я.

Ідентифікатор — це ключ, під яким сервер зберігає вас

Усередині обміну IKEv2 кожна сторона заявляє, ким вона є: ініціатор надсилає локальний ідентифікатор, відповідач відповідає своїм і також перевіряє заявлену ініціатором особу щодо політики. Шлюз зберігає стан за особою, а не за пристроєм, бо пристрій — не те, що він може побачити. Тому два телефони з одним ідентифікатором приходять як один peer, і другий обмін має перезаписати перший. Проблема виявляється лише тоді, коли обидва використовуються, тому тест з одним телефоном ніколи її не відтворює.

Ніщо з цього не є помилкою клієнта. Клієнт надіслав рівно те, що звелів профіль.

Як колізія виглядає з боку шлюзу

Дивіться на список peer, поки обидва телефони не сплять і використовуються. Колізія показує один запис, адреса якого змінюється, коли телефони змінюються, а лічильник активних сесій ніколи не сягає двох. Відключення на вимогу виглядає інакше, і щоб їх розрізнити, потрібне одне спостереження, а не теорія.

ObservationShared identityIdle teardown
Peer entries while both are awakeOne, with a changing addressOne per phone, or none
What triggers the dropThe other device connectingTime without traffic
What restores itThe other device disconnectingAny app needing the tunnel

Запишіть обидві події з позначками часу, поки це відбувається. Обрив, що збігається з підключенням іншого апарата, вказує на ідентифікатор, а обрив, що приходить через один інтервал простою після останнього пакета, — на таймер.

Звідки беруться дублікати

Експорт однієї робочої конфігурації та редагування лише адреси сервера створюють другий файл, у якому все ще є особа першого. Це звичайний шлях до такої несправності, і зазвичай він трапляється під час поспішного підключення невеликої групи.

Назви полів дозволяють легко це проґавити. Віддалений ідентифікатор називає шлюз, якого чекає телефон, і копіювати його правильно. Локальний ідентифікатор називає цей апарат для шлюзу, і копіювання цього значення — уся проблема.

Видавайте значення для кожного пристрою

Використовуйте щось унікальне для апарата й стабільне протягом усього його життя, наприклад ідентифікатор пристрою з інвентаризації або значення, яке ваша система керування генерує для кожного запису. Мітка відділу, спільна назва сервісного облікового запису або адреса електронної пошти користувача конфліктують, щойно в цієї людини з'являється другий пристрій.

Генеруйте корисне навантаження для кожного пристрою, а не розповсюджуйте один файл. Записуйте, яке значення належить якому апарату, щоб заміна не відновила старий профіль і не повернула новий телефон прямо в ту саму колізію.

Перевірте й серверний бік. Шлюз, який зіставляє особу з фіксованою адресою тунелю, усе ще може конфліктувати, коли два різні ідентифікатори отримують одне й те саме призначення, тому переконайтеся, що в пулі є місце і призначення не закріплені за користувачем.

Перевірте, коли обидва телефони не сплять

Підключіть перший, дійдіть до приватного ресурсу, потім підключіть другий і залиште обидва в спокої на хвилину. Обидві сесії мають зберегтися, а список peer — показувати дві особи. Потім заблокуйте й розблокуйте кожен телефон, щоб підтвердити, що сценарій простою поводиться правильно.

Якщо одна сесія все ще падає раз на день, коли більше нічого не підключається, особа більше не підозрюваний. Переходьте до таймерів простою й обмежень сесій сервера, замість того щоб знову редагувати профіль.

Схожі статті