Два телефони, еден профил и шема што изгледа натприродно додека некој не го погледне порталот. Еден уред го држи тунелот, вториот се поврзува, а првиот го губи во рок од секунди. Првиот повторно се поврзува, вториот отпаѓа. Се обвинуваат штедењето батерија, 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 листата треба да покаже два идентитети. Потоа заклучете и отклучете го секој телефон за да потврдите дека случајот на мирување сѐ уште се однесува правилно.

Ако една сесија сѐ уште паѓа еднаш дневно без ништо друго да се поврзува, идентитетот повеќе не е осомничениот. Преминете на тајмери за мирување и ограничувања на сесии на серверот наместо повторно да го уредувате профилот.

Поврзани статии