Borttaget ZeroTier-medlem kommer tillbaka: återkalla behörigheten först

En enhet som är online kan begära att få gå med igen så snart posten tas bort. Återkalla behörigheten och behandla sedan borttagningen som städning av listan.

Du tar bort medlemmen, stänger sidan och en dag senare är samma enhet tillbaka. Det är inte en bugg i konsolen. Det är vad som händer när en post tas bort medan enheten fortfarande är online och fortfarande begär att få gå med.

Två operationer ligger bredvid varandra och gör olika jobb. Den ena avgör åtkomst, den andra städar bara listan.

Börja med posten som kommer tillbaka

Öppna nätverket och titta på posten som kom tillbaka. Notera dess node ID, senaste adress och tiden då den dök upp igen. Jämför med enheten du ville fasa ut. Ett visningsnamn är vad någon har skrivit, och adressen kan ändras vid nästa anslutning.

Node ID är den stabila identifieraren. Ett nätverks-ID namnger nätverket, så det berättar vilken lista du läser och inget om vilken enhet som finns i den. Notera båda och jämför sedan node ID med maskinen du ville fasa ut.

Gör du fel i den jämförelsen tar du bort en maskin som fungerar medan den oönskade fortsätter att fråga. Listan ser då korrekt ut i en dag. Det är tillräckligt länge för att ingen ska märka det, och det är precis problemet.

Återkalla innan du tar bort

Ändra först behörighetsstatusen via det arbetsflöde som styrenheten stöder. Från den punkten visas ett anslutningsförsök som obehörigt i stället för att tyst återställa åtkomst, och begäran är synlig i stället för osynlig.

Borttagningen kommer efteråt, aldrig i stället. Tar du bort posten för en behörig medlem finns inget kvar att återkalla. Enheten frågar igen, och styrenheten behandlar den som ny.

För en maskin du fortfarande kontrollerar är det en nyttig del av utfasningen att lämna nätverket. Det ersätter inte administratörens beslut om en förlorad enhet. En klient du inte längre kontrollerar kan ignorera vad den än har fått höra.

Var de två operationerna ligger

På en driftad styrenhet erbjuder medlemslistan båda åtgärderna och märker dem tydligt nog för att skiljas åt. På en egen driftad styrenhet visas samma skillnad i API:et och i den lokala konfigurationen, och det är där förvirringen brukar börja.

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

De två anropen räcker för att visa om medlemmen någonsin verkligen var obehörig. En post som ständigt kommer tillbaka med authorized: true återkallades aldrig; den bara togs bort.

Bekräfta från resursen, inte listan

En städad medlemslista är inte en åtkomstkontroll. Prova resursen enheten använde tidigare, från den enheten eller från en maskin som har dess gamla adress, och bekräfta att anslutningen misslyckas. Bekräfta sedan att en godkänd ersättning fortfarande fungerar.

Ta med rutter och tjänstebehörigheter i det testet. ZeroTier kan behöriga en medlem och ändå lämna den oförmögen att nå en hanterad rutt. En applikationsbehörighet kan misslyckas på samma sätt. Båda ser likadana ut från medlemslistan.

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

För en egen driftad styrenhet, håll en konsekvent säkerhetskopia av dess identitet och konfiguration. En återställning som rullar tillbaka till ett tidigare tillstånd kan ta med sig en gammal behörighet, och medlemslistan kommer att se exakt ut som före utfasningen.

Utfasningen är klar när den gamla identiteten inte kan nå något och posten är borta. Gör det i den ordningen och medlemmen slutar komma tillbaka.

Relaterade artiklar