Geskrapte ZeroTier-lid keer terug: trek eers die magtiging terug

Jy skrap die lid, maak die bladsy toe, en 'n dag later is dieselfde toestel terug. Dit is nie 'n fout in die konsole nie. Dit is wat gebeur wanneer 'n rekord geskrap word terwyl die toestel nog aanlyn is en nog steeds vra om aan te sluit.

Twee bewerkings staan langs mekaar en doen verskillende take. Een besluit oor toegang, en die ander maak net die lys skoon.

Begin by die rekord wat terugkeer

Maak die netwerk oop en kyk na die inskrywing wat teruggekom het. Let op sy node ID, sy laaste adres en die tyd toe dit weer verskyn het. Vergelyk dit met die toestel wat jy wou aftree. 'n Vertoonnaam is wat iemand ingetik het, en die adres kan by die volgende aansluiting verander.

Die node ID is die stabiele identifiseerder. 'n Netwerk-ID benoem die netwerk, so dit sê vir jou watter lys jy lees en niks oor watter toestel daarin is nie. Teken albei aan en pas dan die node ID by die masjien wat jy wou aftree.

Kry daardie vergelyking verkeerd en jy verwyder 'n werkende masjien terwyl die ongewenste een aanhou vra. Die lys lyk dan 'n dag lank korrek. Dit is lank genoeg dat niemand dit opmerk nie, en dit is juis die probleem.

Trek die magtiging terug voordat jy skrap

Verander eers die magtigingstoestand deur die werkvloei wat die kontroleerder ondersteun. Van daardie punt af verskyn 'n aansluitpoging as ongemagtig pleks daarvan om toegang stilweg te herstel, en die versoek is sigbaar eerder as onsigbaar.

Skrapping kom daarna, nooit in plaas daarvan nie. Om die rekord van 'n gemagtigde lid te verwyder laat niks oor om terug te trek nie. Die toestel vra weer, en die kontroleerder behandel dit as nuut.

Vir 'n masjien wat jy nog beheer, is om die netwerk te verlaat 'n nuttige deel van aftrede. Dit is nie 'n plaasvervanger vir die administrateur se besluit oor 'n verlore toestel nie. 'n Kliënt wat jy nie meer beheer nie, kan ignoreer wat ook al aan hom gesê is.

Waar die twee bewerkings woon

Op 'n gehuisvesde kontroleerder bied die ledelys albei aksies en etiketteer hulle duidelik genoeg om te onderskei. Op 'n self-gehuisvesde kontroleerder verskyn dieselfde onderskeid in die API en in die plaaslike konfigurasie, en dit is waar die verwarring gewoonlik begin.

# 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"

Daardie twee oproepe is genoeg om te wys of die lid ooit werklik ongemagtig was. 'n Rekord wat aanhou terugkeer met authorized: true, is nooit teruggetrek nie; dit is net geskrap.

Bevestig vanaf die hulpbron, nie die lys nie

'n Netjiese ledelys is nie 'n toegangscontrole nie. Probeer die hulpbron wat die toestel vantevore gebruik het, vanaf daardie toestel of vanaf 'n masjien met sy ou adres, en bevestig dat die verbinding misluk. Bevestig dan dat 'n goedgekeurde plaasvervanger steeds werk.

Sluit roetes en diensregte by daardie toets in. ZeroTier kan 'n lid magtig en steeds nie in staat stel om 'n bestuurde roete te bereik nie. 'n Toepassingsreg kan op dieselfde manier misluk. Albei lyk identies vanaf die ledelys.

zerotier-cli listnetworks
ip route show | grep zt
ping -c 3 10.144.0.5

Vir 'n self-gehuisvesde kontroleerder, hou 'n konsekwente rugsteun van sy identiteit en konfigurasie. 'n Herstel wat na 'n vroeër toestand terugrol, kan 'n ou magtiging saambring, en die ledelys sal presies lyk soos voor die aftrede.

Aftrede is voltooi wanneer die ou identiteit niks kan bereik nie en die rekord weg is. Doen dit in daardie volgorde en die lid hou op om terug te kom.