Maeneo matatu yanaweza kushikilia anwani ya ndani isiyobadilika kwa mteja wa VPN, na ni moja tu kati yao inapaswa kuimiliki. RADIUS inaweza kurudisha anwani katika Access-Accept, lango linaweza kuweka ramani tuli kwa akaunti, na adapta ya mteja inaweza kuwekwa kwa mkono. Mawili ya kwanza ni sera na ya tatu ni dhana ya ndani ambayo lango liko huru kuipuuza au kuandika juu yake. Kuchagua kati ya mawili ya kwanza ndiyo uamuzi halisi, na inategemea kile seva ya ufikiaji wa mtandao inatekeleza kwa kweli.

Maeneo matatu ambapo anwani isiyobadilika inaweza kuwa

RADIUS inamiliki anwani wakati jibu linabeba Framed-IP-Address na lango linatumia thamani hiyo kwenye kikao. Lango linamiliki wakati msimamizi anaweka ramani ya akaunti kwenye anwani tuli ndani ya dimbwi. Mteja hamiliki chochote, hata wakati adapta yake inaonyesha anwani ya mkono, kwa sababu seva inagawa anwani ya ndani wakati wa majadiliano na mpangilio wa ndani unajali tu wakati seva haitumi chochote. Wote watatu wanaonekana sawa kwenye muunganisho unaofanya kazi, ndiyo sababu migongano huibuka kwa kuchelewa. Tofauti inaonekana wakati wa kuunganisha upya, kwenye kifaa cha pili na baada ya mabadiliko ya sera.

Wamiliki wawili ndiyo usanidi unaovunjika. Jibu la RADIUS linalogawa 172.28.4.77 wakati lango linashikilia ramani tuli ya 172.28.4.90 hutoa thamani ambayo msimbo wa msambazaji hukagua kwanza, na aliyeshindwa hutupwa bila mstari wa kumbukumbu. Akaunti hiyo hiyo kwenye kifaa cha pili hupokea anwani ya nakala, na dalili husomwa kama hitilafu ya uelekezaji badala ya mgongano wa ugawaji. Amua mmiliki kabla ya kuongeza utaratibu wa pili.

Chaguo la upande wa mteja linafaa kutajwa tu ili liweze kuondolewa. Anwani ya adapta ya mkono ni upendeleo ambao mfumo wa uendeshaji unaweza kuonyesha, si akiba, na hauwezi kuzuia kikao kingine kupokea anwani hiyo hiyo.

Jibu la RADIUS linaweza kuahidi nini na haliwezi kuahidi nini

RFC 2865inafafanua Framed-IP-Address kama anwani ya IPv4 inayopaswa kusanidiwa kwa mtumiaji, na ni ya Access-Accept. Sifa hiyo hiyo katika Access-Request ni kidokezo tu ambacho seva inaweza kupuuza, na hilo ni muhimu wakati mteja au lango linatoa anwani inayopendelewa. Hakuna kitu katika itifaki kinacholazimisha lango kuheshimu jibu, kwa sababu seva ya ufikiaji wa mtandao ndiyo sehemu inayolitumia kwenye kikao.

Msaada ni swali la bidhaa na si la itifaki. Baadhi ya lango hutumia anwani zilizofungwa kwa chaguo-msingi, zingine zinahitaji swichi ya ngazi ya kikundi iwashwe kabla ya kufanya hivyo, na zingine zinakubali sifa hiyo na kamwe hazitumii kwa vikao vya ufikiaji wa mbali. Kisa cha mwisho ni hatari, kwa sababu rekodi ya uhasibu inaweza kuonyesha jibu wakati mteja anapokea anwani ya dimbwi. Thibitisha tabia kwenye modeli kamili ya lango na firmware unayoiendesha, si kwenye nyaraka za bidhaa dada.

Jibu ambalo lango hulipuuza linaonekana sawa kabisa na jibu ambalo halikutumwa kamwe. Kusoma Access-Accept na anwani ya kikao kando kando ndiyo njia pekee ya kutenganisha hali hizi mbili.

Akibisha anwani ndani ya dimbwi unaloelekeza tayari

Chagua anwani isiyobadilika kutoka subnet ya dimbwi ambayo lango linaielekeza tayari na ambayo firewall inaamini tayari. Anwani nje ya wigo huo hubadilisha mabadiliko ya sera kuwa mradi wa uelekezaji, na VPN itainuka wakati hakuna kitu nyuma yake kinachoweza kujibu. Ikiwa kuna kanuni za ufikiaji kwa kila anwani, ongeza anwani isiyobadilika kwa hizo katika mabadiliko hayo hayo.

Amua kikao cha pili cha wakati mmoja kinapaswa kufanya nini. Kugawa anwani moja mara mbili si usimamizi wa vifaa, na mgongano unaotokea unaonekana kama muunganisho wa vipindi kwa vikao vyote viwili. Ama toa utambulisho tofauti kwa kila kifaa, au ugawaji tofauti, au lazisha ushirikiano wa wakati mmoja kwa ukaguzi unaotumika, kama vile Simultaneous-Use, badala ya kutumaini kuwa mteja hataunganisha upya kabla ya kikao cha zamani kuisha.

Njia za kurudi zinastahili umakini sawa na ugawaji. Lango linahitaji njia kuelekea dimbwi, vipanga njia vya ndani vinahitaji njia ya kurudi kwenye lango, na anwani isiyobadilika inarithi zote mbili. Mteja mmoja anayefanya kazi wakati wengine wote wanashindwa kwa kawaida humaanisha kuwa njia ya dimbwi ipo lakini njia ya mwenyeji kwa anwani iliyohifadhiwa haipo.

Jaribu jibu kabla ya kuamini akiba

Jaribu upande wa AAA na upande wa kikao kwa tofauti, kwa sababu wanashindwa kwa sababu tofauti. radtest ya ndani inaonyesha kile seva inarudisha kwa akaunti bila kuhusisha lango, na ingizo la faili ya watumiaji linaonyesha kile seva inapaswa kulinganisha. Kisha unganisha mteja upya na linganisha anwani aliyopokea na sifa iliyo kwenye jibu.

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77
survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

Access-Accept bila sifa inamaanisha seva haikulinganisha ingizo au sifa haikutumika kwa mtumiaji huyo. Access-Accept yenye sifa na mteja anayepokea bado anwani ya dimbwi inamaanisha lango liliipuuza. Access-Reject inakurudisha kwenye vitambulisho au sera ya kikundi, na hakuna moja ya matokeo haya inapaswa kutatuliwa kwa kuhariri adapta ya mteja.

Rudia ukaguzi baada ya kuunganisha upya na baada ya kuingia mara ya pili kutoka kifaa kingine. Akiba inayoshikilia kikao cha kwanza tu ni mgongano wa dimbwi unaosubiri kutokea, na ni rahisi kuipata sasa kuliko wakati wa ukaguzi.

Chagua mmiliki mmoja na uandike

Ikiwa lango linatumia anwani zilizofungwa kwa kuaminika, acha RADIUS imiliki ugawaji na uondoe ramani yoyote tuli kwa akaunti hiyo hiyo. Ikiwa sivyo, acha lango liimiliki na uondoe sifa kwenye jibu, ili vyanzo viwili visiweze kutofautiana. Kuweka vyote viwili kwa sababu kila kimoja kinakaribia kufanya kazi kunahakikisha kikao cha baadaye chenye anwani isiyo sahihi na bila sababu dhahiri.

Andika mmiliki aliyechaguliwa, anwani iliyohifadhiwa na dimbwi ilikotoka kwenye rekodi ya akaunti. Mtu anayefuata kuongeza kifaa ataweza kuona kama anwani ni sera ya AAA au ramani ya lango kabla ya kubadilisha yoyote kati ya hizo.

Makala zinazohusiana