Slettet ZeroTier-medlem vender tilbage: tilbagekald godkendelsen først

Du sletter medlemmet, lukker siden, og en dag senere er den samme enhed tilbage. Det er ikke en fejl i konsollen. Det er, hvad der sker, når en post slettes, mens enheden stadig er online og stadig beder om at komme med.

To handlinger ligger side om side og gør forskellige ting. Den ene afgør adgang, den anden rydder bare op i listen.

Start ved posten, der vender tilbage

Åbn netværket, og se på den post, der kom tilbage. Notér dens node ID, dens sidste adresse og det tidspunkt, hvor den dukkede op igen. Sammenlign det med den enhed, du ville udfase. Et vist navn er, hvad nogen har skrevet, og adressen kan ændre sig ved næste tilslutning.

Node ID er den stabile identifikator. Et netværks-ID navngiver netværket, så det fortæller dig, hvilken liste du læser, og intet om, hvilken enhed der er i den. Notér begge, og sammenhold derefter node ID med den maskine, du ville udfase.

Tager du fejl af den sammenligning, fjerner du en maskine, der virker, mens den uønskede bliver ved med at spørge. Listen ser så rigtig ud i en dag. Det er længe nok til, at ingen opdager det, og det er netop problemet.

Tilbagekald, før du sletter

Skift først godkendelsestilstanden via den arbejdsgang, controlleren understøtter. Fra det punkt vises et tilslutningsforsøg som uautoriseret i stedet for stille at genoprette adgang, og anmodningen er synlig i stedet for usynlig.

Sletningen kommer bagefter, aldrig i stedet. Fjerner man posten for et godkendt medlem, er der intet tilbage at tilbagekalde. Enheden spørger igen, og controlleren behandler den som ny.

For en maskine, du stadig styrer, er det en nyttig del af udfasningen at forlade netværket. Det er ikke en erstatning for administratorens beslutning om en mistet enhed. En klient, du ikke længere styrer, kan ignorere, hvad den end har fået at vide.

Hvor de to handlinger ligger

På en hostet controller tilbyder medlemslisten begge handlinger og mærker dem tydeligt nok til at skelne. På en selvhostet controller vises den samme forskel i API'et og i den lokale konfiguration, og det er der, forvirringen normalt starter.

# 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 to kald er nok til at vise, om medlemmet nogensinde reelt var uautoriseret. En post, der bliver ved med at vende tilbage med authorized: true, blev aldrig tilbagekaldt; den blev kun slettet.

Bekræft ud fra ressourcen, ikke listen

En ryddelig medlemsliste er ikke en adgangskontrol. Prøv den ressource, enheden brugte før, fra den enhed eller fra en maskine, der har dens gamle adresse, og bekræft, at forbindelsen fejler. Bekræft derefter, at en godkendt erstatning stadig virker.

Tag ruter og tjenestetilladelser med i den test. ZeroTier kan godkende et medlem og alligevel efterlade det ude af stand til at nå en administreret rute. En applikationstilladelse kan fejle på samme måde. Begge ser ens ud fra medlemslisten.

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

Til en selvhostet controller skal du holde en konsistent sikkerhedskopi af dens identitet og konfiguration. En gendannelse, der ruller tilbage til en tidligere tilstand, kan bringe en gammel godkendelse med tilbage, og medlemslisten vil se præcis ud som før udfasningen.

Udfasningen er færdig, når den gamle identitet ikke kan nå noget, og posten er væk. Gør det i den rækkefølge, og medlemmet holder op med at vende tilbage.