Mwanachama wa ZeroTier aliyeondolewa anarudi: batilisha idhini kwanza
Kifaa kilicho mtandaoni kinaweza kuomba kujiunga tena mara tu rekodi yake inapoondolewa. Batilisha idhini kwanza, kisha chukulia uondoshaji kama usafishaji wa orodha.
Unaondoa mwanachama, unafunga ukurasa, na siku moja baadaye kifaa kilekile kimerudi. Hiyo si hitilafu kwenye konsoli. Hiyo hutokea rekodi inapoondolewa wakati kifaa kingali mtandaoni na bado kinaomba kujiunga.
Shughuli mbili zinaishi kando kando na hufanya kazi tofauti. Moja huamua ufikiaji, nyingine hupanga orodha tu.
Anza na rekodi inayorudi
Fungua mtandao na uangalie ingizo lililorejea. Andika node ID yake, anwani yake ya mwisho na muda ilipoonekana tena. Linganisha na kifaa ulichokusudia kustaafisha. Jina linaloonyeshwa ni lile ambalo mtu aliandika, na anwani inaweza kubadilika kwenye ujio ujao.
Node ID ni kitambulisho thabiti. ID ya mtandao huipa mtandao jina, kwa hivyo inakuambia orodha ipi unayosoma na haisemi chochote kuhusu kifaa kilicho ndani yake. Andika zote mbili, kisha linganisha node ID na mashine uliyokusudia kustaafisha.
Ukikosea ulinganisho huo, utaondoa mashine inayofanya kazi wakati kifaa kisichotakikana kinaendelea kuomba. Orodha huonekana sawa kwa siku moja. Hiyo ni muda wa kutosha kwa hakuna mtu kuona, na ndiyo tatizo lenyewe.
Batilisha kabla ya kuondoa
Kwanza badilisha hali ya idhini kupitia mtiririko wa kazi unaoungwa mkono na kidhibiti. Kuanzia wakati huo, jaribio la kujiunga linaonekana kama lisiloidhinishwa badala ya kurejesha ufikiaji kimya kimya, na ombi linaonekana badala ya kutoonwa.
Uondoshaji huja baadaye, kamwe si badala yake. Kuondoa rekodi ya mwanachama aliyedhinishwa hakuachi kitu cha kubatilisha. Kifaa kinauliza tena, na kidhibiti hukichukulia kama kipya.
Kwa mashine unayodhibiti bado, kuondoka kwenye mtandao ni sehemu muhimu ya kustaafisha. Hii haichukui nafasi ya uamuzi wa msimamizi kuhusu kifaa kilichopotea. Mteja usiyemdhibiti tena anaweza kupuuza chochote alichoambiwa.
Shughuli hizo mbili ziko wapi
Kwenye kidhibiti kinachopangishwa, orodha ya wanachama hutoa vitendo vyote viwili na huviwekea lebo kwa uwazi wa kutosha kuvitofautisha. Kwenye kidhibiti unachojipangishia mwenyewe, tofauti hiyo hiyo inaonekana kwenye API na kwenye usanidi wa ndani, na hapo ndipo mkanganyiko huanzia.
# list members with authorization state
curl -s -H "X-ZT1-Auth: $TOKEN" \
"http://127.0.0.1:9993/controller/network/$NETWORK_ID/member" | jq 'to_entries[] | {id: .key, authorized: .value.authorized}'
# deauthorize one member by node id, then confirm
curl -s -X POST -H "X-ZT1-Auth: $TOKEN" -d '{"authorized": false}' \
"http://127.0.0.1:9993/controller/network/$NETWORK_ID/member/$NODE_ID"
Miito hiyo miwili inatosha kuonyesha kama mwanachama aliwahi kuwa bila idhini kweli. Rekodi inayorudi tena na tena ikiwa na authorized: true haikubatilishwa kamwe; iliondolewa tu.
Thibitisha kutoka kwa rasilimali, si kwenye orodha
Orodha ya wanachama iliyopangwa si ukaguzi wa ufikiaji. Jaribu rasilimali ambayo kifaa kilitumia awali, kutoka kwa kifaa hicho au kutoka kwa mashine iliyo na anwani yake ya zamani, na thibitisha kwamba muunganisho unashindikana. Kisha thibitisha kwamba mbadala ulioidhinishwa bado unafanya kazi.
Jumuisha njia na ruhusa za huduma kwenye jaribio hilo. ZeroTier inaweza kuidhinisha mwanachama na hata hivyo kumwacha ashindwe kufikia njia inayosimamiwa. Ruhusa ya programu inaweza kushindikana vivyo hivyo. Vyote viwili huonekana sawa kutoka kwenye orodha ya wanachama.
zerotier-cli listnetworks
ip route show | grep zt
ping -c 3 10.144.0.5
Kwa kidhibiti unachojipangishia mwenyewe, tunza nakala rudufu thabiti ya utambulisho na usanidi wake. Urejeshaji unaorudi kwenye hali ya awali unaweza kuleta idhini ya zamani pamoja nao, na orodha ya wanachama itaonekana sawa kabisa na kabla ya kustaafisha.
Kustaafisha kumekamilika wakati utambulisho wa zamani hauwezi kufikia chochote na rekodi imeondoka. Fanya hivyo kwa mpangilio huo na mwanachama ataacha kurudi.